on 05-12-2015 3:45 PM
We are performing PI upgrade from 7.0 to 7.4 . During downtime phase, we are observing that offline migration
Issue: During upgrade execution phase "Run Offline Migration" Following error is coming
Warning: validation was turned on but an org.xml.sax.ErrorHandler was not
set, which is probably not what is desired. Parser will use a default
ErrorHandler to print the first 10 errors. Please call
the 'setErrorHandler' method to fix this.
Error: URI=null Line=2: cvc-elt.1: Cannot find the declaration of element 'migration'.
Warning: validation was turned on but an org.xml.sax.ErrorHandler was not
set, which is probably not what is desired. Parser will use a default
ErrorHandler to print the first 10 errors. Please call
the 'setErrorHandler' method to fix this.
Error: URI=null Line=2: cvc-elt.1: Cannot find the declaration of element 'migration'.
Warning: validation was turned on but an org.xml.sax.ErrorHandler was not
set, which is probably not what is desired. Parser will use a default
ErrorHandler to print the first 10 errors. Please call
the 'setErrorHandler' method to fix this.
Error: URI=null Line=2: cvc-elt.1: Cannot find the declaration of element 'migration'.
Warning: validation was turned on but an org.xml.sax.ErrorHandler was not
set, which is probably not what is desired. Parser will use a default
ErrorHandler to print the first 10 errors. Please call
the 'setErrorHandler' method to fix this.
Error: URI=null Line=2: cvc-elt.1: Cannot find the declaration of element 'migration'.
Warning: validation was turned on but an org.xml.sax.ErrorHandler was not
set, which is probably not what is desired. Parser will use a default
ErrorHandler to print the first 10 errors. Please call
the 'setErrorHandler' method to fix this.
Error: URI=null Line=2: cvc-elt.1: Cannot find the declaration of element 'migration'.
Warning: validation was turned on but an org.xml.sax.ErrorHandler was not
set, which is probably not what is desired. Parser will use a default
ErrorHandler to print the first 10 errors. Please call
the 'setErrorHandler' method to fix this.
Error: URI=null Line=2: cvc-elt.1: Cannot find the declaration of element 'migration'.
Warning: validation was turned on but an org.xml.sax.ErrorHandler was not
set, which is probably not what is desired. Parser will use a default
ErrorHandler to print the first 10 errors. Please call
the 'setErrorHandler' method to fix this.
Error: URI=null Line=2: cvc-elt.1: Cannot find the declaration of element 'migration'.
"JMT_FRAMEWORK_08.ERR" 35 lines, 2310 characters
Our OS is AIX 7.1 and Database is Oracle 11g.
Kindly let us know if you have any workaround or solution for same.
Hello All
I got response from SAP about this issue and following
1.
SELECT count(*), STATUS from XI_AF_MSG GROUP by STATUS;
(instead of it "select count(*) from SAPSR3DB.XI_AF_MSG_AUDIT GROUP by
STATUS;")
2.
If result shows in table XI_AF_MSG there are 1 866 546 non-final messages
that are being migrated - and the migration takes almost 5 hours. Now
according to the DB queries you have 116 222 575 entries in the
XI_AF_MSG_AUDIT. The migration fails during the migration of that
table. This most probably is caused by the huge number of entries in
it (e.g. not enough memory, etc).
3.
3.1) Is the upgraded system is production or development/test system?
Will you need the information for the XI messages in the new system?
3.2) Do you archive the XI messages on the system or only delete them?
3.3) Have you run the housekeeping jobs to delete/archive the XI
messages before the upgrade?
In order to run the upgrade successfully you will need to clean up the
XI messages and their audit logs. During the migration only non final
messages are migrated. So you need to finalize and delete these
messages - e.g. you need to cancel or reprocess the messages in case
you need to. Would that be possible?
If you can not revert back the system and start the upgrade from initial then use following workaround:
In this case the only option is to 'cancel' the messages on DB level.
This means setting status 'FAIL' for all messages with non-final
state. These messages will not be migrated in the upgraded system as
well as their audit logs. As this is development system you have
confirmed that this is ok (you do not need the XI messages).
However, for the production system you need to ensure that the tables
are cleaned up before running the upgrade. This is very important step
in order to keep the business data consistent.
For the dev system you can change the status with the following query:
UPDATE XI_AF_MSG SET STATUS='FAIL' WHERE STATUS='TBDL' OR
STATUS='DLNG' OR STATUS='NDLV' OR STATUS='WAIT' OR STATUS='HOLD'
Please be very careful not to change any other table. I would also
recommend that you backup the table before that.
Then run the following statement to check that there are messages only
with status DLVD and FAIL:
SELECT count(*), STATUS from XI_AF_MSG GROUP by STATUS;
After that you can re-run the migration step. It should take
significantly less time than before.
Let me know if this solution works for you or not.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
105 | |
8 | |
6 | |
6 | |
5 | |
5 | |
3 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.