Upgrade - Poor performance during SHADOW_IMPORT_INC

[former_member571457]

We are upgrading from 4.6C to ECC 6.0.

The phases have processed with acceptable times until we got to the SHADOW_IMPORT_INC which has been running for 30 hours. Is there a way to tell if the process is hung up? This phase started on 11/12/06 at 4:01AM. The last entry in the SAPup.ECO was on 11/12/06 at 13:02PM. WRKACTJOB shows 1 R3TRANS and 1 TP.

Is there a way to tell if it is indeed working or just looping?

Best Regards,

Melisa Fountain

[former_member571457 · Accepted solution]

Hi Volker,

Yes, we'd like to check out your workaround in DEV. The Prepare is complete and we are ready to run the Upgrade.

Thanks very much,

Melisa

[Former Member · Accepted solution]

Hi Melisa,

I created 2 DDS LFs as follows on the ATAB table:

EDTF FILE(SAPTEST/QDDSSRC) MBR(T031_ATAB)  
CRTLF FILE(R3sidDATA/T030_ATAB) SRCFILE(SAPTEST/QDDSSRC) SRCMBR(T030_ATAB) 

 ***************Datenanfang*****************           
     A          R ATAB                                                           <-Satzende 
     A                                      PFILE(R3sidDATA/ATAB)                <-Satzende 
     A*                                                                          <-Satzende 
     A            TAB             G  I      SST(TABNAME 01 10)                   <-Satzende 
     A            MANDT           G  I      SST(VARKEY 01 03)                    <-Satzende 
     A            KTOPL           G  I      SST(VARKEY 07 04)                    <-Satzende 
     A            KTOSL           G  I      SST(VARKEY 15 03)                    <-Satzende 
     A            BWMOD           G  I      SST(VARKEY 21 04)                    <-Satzende 
     A            KOMOK           G  I      SST(VARKEY 29 03)                    <-Satzende 
     A            BKLAS           G  I      SST(VARKEY 35 04)                    <-Satzende 
     A                                                                           <-Satzende 
     A          K TAB                                                            <-Satzende 
     A          K MANDT                                                          <-Satzende 
     A          K KTOPL                                                          <-Satzende 
     A          K KTOSL                                                          <-Satzende 
     A          K BWMOD                                                          <-Satzende 
     A          K KOMOK                                                          <-Satzende      
     A          K BKLAS                                                          <-Satzende     
**************Datenende*******************              
     

EDTF FILE(SAPTEST/QDDSSRC) MBR(T031_ATAB)  
CRTLF FILE(R3sidDATA/T031_ATAB) SRCFILE(SAPTEST/QDDSSRC) SRCMBR(T031_ATAB) 

 ***************Datenanfang*****************           
     A          R ATAB                                                           <-Satzende 
     A                                      PFILE(R3sidDATA/ATAB)                <-Satzende 
     A*                                                                          <-Satzende 
     A            TAB             G  I      SST(TABNAME 01 10)                   <-Satzende 
     A            MANDT           G  I      SST(VARKEY 01 03)                    <-Satzende 
     A            KTOPL           G  I      SST(VARKEY 07 04)                    <-Satzende 
     A            KTOSL           G  I      SST(VARKEY 15 03)                    <-Satzende 
     A            BWMOD           G  I      SST(VARKEY 21 04)                    <-Satzende 
     A            KOMOK           G  I      SST(VARKEY 29 03)                    <-Satzende 
     A            BKLAS           G  I      SST(VARKEY 35 04)                    <-Satzende 
     A            VIRT            G  I      SST(VARKEY 39 10)                    <-Satzende 
     A                                                                           <-Satzende 
     A          K TAB                                                            <-Satzende 
     A          K MANDT                                                          <-Satzende 
     A          K KTOPL                                                          <-Satzende 
     A          K KTOSL                                                          <-Satzende 
     A          K BWMOD                                                          <-Satzende 
     A          K KOMOK                                                          <-Satzende      
     A          K BKLAS                                                          <-Satzende     
     A          K VIRT                                                           <-Satzende     
**************Datenende*******************              

After that the phase was REALLY fast )

Regards

Volker Gueldenpfennig, consolut.gmbh

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

Message was edited by:

Volker Gueldenpfennig

[wilian_segatto]

I had this problem and found out that the oracle was using 100% of the disk space because of the archive logs.

You can remove all archive logs (make sure you have backups in case you need to restore something later in case of a failed backup or crash) from /oracle/<sid>/oraarch.

I used "rm -R *" in this folder.

The oracle system freezes in this situation but the db is still up. When you remove the files, it takes a while but the execution later continues by itself (give it like 5 minutes and double check).

[Former Member]

Helo,

We are facing an issue in the same phase SHADOW_IMPORT_INC - running quiet long time.R3trans and TP are running and the shadow system is down.

Please advice whether shadow system would be down in this phase.

OS : windows 2003 -64bit

mssql -2005

upgrading from ecc6 - ehp5

regards

mathew

[Former Member]

Hi Mathew,

it would be helpful, when you would let us know, what "quite long" means ... in your case I would call 18-24 "quite normal" 😉

... keep in mind, you are still in the uptime ...

Regards

Volker Gueldenpfennig

[Former Member]

Hi Volker,

Running morethan 10 hrs.Shadows server is down and can see in the log that updation is going on .

I think shadow system will be stopped during these steps...

regards

mathew

[former_member189725]

I suggest you have a look at the threads

http://scn.sap.com/message/13344391#13344391

http://scn.sap.com/thread/1834278

For the phase SHADOW_IMPORT_INC, the TPP file is SHDALLIMP.TPP .

You can stop the running R3trans processes and edit the file SHDALLIMP.TPP .

Change the parameter mainimp_proc to a value less than 8 .( Set it to the number of CPUs kind of a thumb-rule)

Check increasing the R3trans processes does make any difference.

Regards

Ratnajit

[christian_bartels]

In the meantime we have understood the root cause of this problem at SAP. It can happen when upgrading to an SAP release based on kernel release 7.00 on i5/OS V5R3. The problem and possible solutions or workarounds are documented in SAP Note 1017718.

Kind regards,

Christian Bartels.

[former_member571457]

Hi Volker,

We applied your fix and started the Production upgrade Tuesday afternoon with the option "downtime minimized". The SHADOW_IMPORT_INC phase took only 4 hours. Things are looking good so far.

Thanks for your help!

Melisa

[former_member571457]

Hi Volker,

Thanks for the info. We are upgrading Dev now and will upgrade Production this weekend (12/15-12/17). I'll keep you posted on processing times.

Thanks,

Melisa

[Former Member]

Hi Melisa,

do you want to implement my workaround for DEV already ? It is not really complicated ...

It would be possible as long you are before this long phase ...

... I typically do not like changing anything for PRD upgrades only ...

Regards

Volker Gueldenpfennig, consolut.gmbh

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

[former_member571457]

Hi Volker,

Thanks for the comments on your upgrades

Our upgrade finished Monday night...have been busy with Post upgrade activities. The two bad phases for us are the ones you mentioned - SHADOW_IMPORT_INC and TABIM_UPG. I am hopeful that it will go much better on our i5 hardware in a few weeks.

Thanks,

Melisa

[Former Member]

Hi Melisa,

at the moment you can only expect factor 2 up to perhaps 3 in these phases. If this is ok with you, that's fine. Otherwise, we should talk on speeding it up in a special way which is not that easy, but the only idea, that I do have in mind before the final fix is out.

Regards

Volker Gueldenpfennig, consolut.gmbh

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

[Former Member]

Hi Melisa,

do you still have this issue or is your PRD system upgraded already ?

I was able to find a workaround for this problem with creating a DDS logical file on ATAB - it reduced one transport from 4:10h down to 0:15 (on i5) - I didn't test a full upgrade yet, if this is sufficient or needs some more improvement ...

Regards

Volker Gueldenpfennig, consolut.gmbh

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

[former_member571457]

Hi Volker,

Have you done any upgrades from 4.6C to ECC 6.0 and if so, how long did the upgrade take? At this point, I can't imagine performing a Production upgrade (with i5 hardware) over a normal weekend. Our problem here is we are going to have to make decisions soon about how to proceed with the Production upgrade that is set for the weekend of Dec. 9th.

Our 810 QAS is progressing very slowly. It started the phase TABIM_POST Friday at 21:00 and is still running that phase right now. I have a note open with SAP and they are working on this issue right now.

Any feedback on system size and upgrade times is most appreciated.

Thanks,

Melisa

[Former Member]

Hi Melisa,

yes, I did several upgrades to ECC 6 (mostly from 4.6C). The point of runtime is NOT the DB size => this will not really be interesting for you.

The downtime I have seen - running downtime minimized - in these systems was 7-24h depending on different things (a bit db size as well).

I checked for the phase TABIM_POST and had ALWAYS runtimes from 5-18 minutes! I had performance issues in SHADOW_IMPORT_INC & TABIM_UPG - where the first one is before the downtime.

So, you seem to have a little bit other issue here ... what is the system doing right now (have a look at /usr/sap/trans/tmp into the file that is frequently changed ?

If you need more information, please let me know.

Regards

Volker Gueldenpfennig, consolut.gmbh

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

[gfarmer]

Hey

Only Info that you have not alone poor performance.

We do also a Upgrade from 4.6C to erp2005 ecc 6.0 on a 570 (11 CPU 60 GB mem). And we work on this since 2 Weeks. Very long runtimes, and some errors(2 times Development support) now we hang in the Unicode Upgrade Phase. It seems that ERP2005 SR1 is not a good start with ERP2005.

But in the next days come out SR2 which should include some performance improvment.Which need some updates in OS400 too.

Lg.

Gerhard

[Former Member]

Hi Gerhard,

I did several upgrades already with ECC 6 SR0 & SR1. I have to say, that the general quality is not bad, the runtimes are really long - but in my eyes because of an optimizer error which is now at SAP for checking.

I don't expect a lot more stable things in SR2, because you will include all SPs in SR1 as well and my errors are "pretty random" - on the other hand all "solvable".

If you have special questions, just let me know.

Regards

Volker Gueldenpfennig, consolut.gmbh

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

[former_member571457]

After opening a note with SAP, they logged onto the OS and checked the job. They said the R3TRANS was looping and they ended it. Had me do a retry and the upgrade progressed past that phase.

Now I'm stuck in JOB_DBDIF_UPG with the following error:

BATCHJOB RADDBDIF FAILED

SEVERE ERROR: code -1 during analysis of logfiles matching

RADDBDIF\.QAS

I am able to log on as DDIC and SM37 shows the job RADDBDIF finished with no errors. I tried to repeat the phase a couple of times but it still errors out while showing in SM37 that the job finished normally. I've got a note in with SAP but haven't gotten a response from them.

Thanks,

Melisa

[Former Member]

Hi Melissa,

we have the same problem with the phase JOB_DBDIF_UPG;

can you describe your troubleshooting?

Now I'm stuck in JOB_DBDIF_UPG with the following error:

BATCHJOB RADDBDIF FAILED

SEVERE ERROR: code -1 during analysis of logfiles matching

RADDBDIF\.QAS

I am able to log on as DDIC and SM37 shows the job RADDBDIF finished with no errors. I tried to repeat the phase a couple of times but it still errors out while showing in SM37 that the job finished normally. I've got a note in with SAP but haven't gotten a response from them.

Thanks,

Johannes

[Former Member]

Hi Johannes,

did you check all log files in the put directory ?

Do you see new jobs in SM37 when you repeat ?

Sounds like a "special issue", that needs to be investigated ;-(

Regards

Volker Gueldenpfennig, consolut international ag

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

[Former Member]

Hi Volker,

the PADDBDIF.LOG writes "Error code "-1" during analysis of logfiles matching "RADDBDIF\.E11

Upgrade phase "JOB_DBDIF_UPG" aborted with severe errors ("20071023102310")"

and the CONNECT.LOG say's "Upgrade phase "JOB_DBDIF_UPG" completed sucessfully ("20071023110858")".

Whenever the phase was restarted a new Job RADDBDIF has been created and had run without error's.

I 've opend a SAP-Call with high priority but till now there is no response.

Best regards

Johannes

[Former Member]

Hi Johannes,

then I don't have a clou right now ...

Regards

Volker Gueldenpfennig, consolut international ag

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

[Former Member]

Hello,

we are performing an upgrade from R/3 4.6C to ECC6 and we are stuck in the phase JOB_DBDIF_UPG. We have the same error you described:

*****************************************************************************************************************************************************

.......problem with the phase JOB_DBDIF_UPG;

can you describe your troubleshooting?

Now I'm stuck in JOB_DBDIF_UPG with the following error:

BATCHJOB RADDBDIF FAILED

SEVERE ERROR: code -1 during analysis of logfiles matching

RADDBDIF\.QAS

I am able to log on as DDIC and SM37 shows the job RADDBDIF finished with no errors. I tried to repeat the phase a couple of times but it still errors out while showing in SM37 that the job finished normally. I've got a note in with SAP but haven't gotten a response from them.

*****************************************************************************************************************************************************

Can you help us to solve the problem, please? Thanks in advance for your understanding and cooperation.

Kind regards

Luca Manduzio

[Former Member]

This occurs if you have the DIR_TRANS set in DEFAULT.PFL, There are two solutions for this.

1. Remove the DIR_TRANS from the DEFAULT.PFL and run the phase once again so that /usr/sap/put is taken during the upgrade.

2. Copy the RADDBDIF.<SID> from /usr/sap/trans/tmp to /usr/sap/put/tmp.

Regards,

Ravi

[Former Member]

Ravi,

Thanks for your solution. your solution was very helpfull.

Thanks and Regards,

[former_member571457]

Hi Volker,

Thanks for your reply. I've opened a note with SAP. This is an 810 box. Our other machines are i5 hardware. Are you saying that the i5 will perform much better with the upgrade than the old 810?

Also, can you point me to the message you've opened with a reproducible scenario that you mentioned?

Thanks,

Melisa

[Former Member]

Hi Melissa,

good performance ? no, not really but factor 2-3 times faster ... that's at least good hope. I hope, you opened the ticket with componente BC-DB-DB4 => it will soon worked on that (even when the solution might take some time with a PTF)

As this is not "my" SAP message, but one of a customer of mine, I do not like to mail the message around here.

Regards

Volker Gueldenpfennig, consolut.gmbh

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

[Former Member]

Hi Melissa,

unfortunately you are facing a bad performance issue with most likely full table scans on table ATAB ... it it not looping, but as said doing a full table scan :-((

I guess you are on 830 or similar (not i5 HW) and I would assume, that with 30 hours you are " nearly through". You should open an SAP message on this. I do have a message open with this with a reproducible scenario here. Hopefully this helps. The problem was that it sometimes happens, but was really not reproducible, so it is really hard to catch.

Regards

Volker Gueldenpfennig, consolut.gmbh

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de