RSDBSCPY on EHPI

[Former Member]

Hi,

I´m makink the ehpi netweaver 7.0 installation but in the phase MAIN_SHDCRE/RUN_RSDBSCPY ,the job has been launched but not doing anything.The stage is now about 5 hours. In the logs i can see this:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Clone shadow tables ERRORS and RETURN CODE in DBCLONEDISP.NW4

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1EETG011 "Job DBCLONE1 : error in function JOB_CLOSE"

1EETG011 "Job DBCLONE2 : error in function SHOW_JOBSTATE"

Other log:

Starting of Clone shadow tables in batch (job RSUPG_PARCLONE)

working ...

What can i do???

More thanks

[Former Member · Accepted solution]

Hello Ruben, Did you updated you system with the latest kernel and the R3trans latest available.

ALso if you could send the output of SLOG files and Alog files.

Please check if any SP has ended with RC=12.

Check for the table spaces too as some times it creates problem.

Hope it helps ..

Regards, Amber S

[Former Member]

Hello Folks,

Please do not alter / trunket any table from DB level, Here is the ultimate solution for your problem.

goto RSA1 transaction> Source systems>SAP system (below BI), right click on that, click on "Transfer global settings"

A new window will open for transferring global settings,

in that select each check box one for "Factory calender" & other for "Rebuild Tables"

and now just execute it.

It will rebuild the table THOLT and other necessary tables which are used while upgrade.

After you have finished it, resume your EHP installation.

regards,

Shishir

[Former Member]

Hello All,

I did run in the same issue as mentioned in this thread.

The job RSUPG_PARCLONE in my Netweaver 7.0 system was running for more than 30 hours in status on hold.

No DBCLONE jobs were started.

I checked my hostname on the windows 2003 server where SAP is running in my case.

start -> run -> cmd and enter hostname.

In my case the hostname is shown in upper case. But when i looked in SM51 the hostname was shown in lower case.

I changed all references to the hostname in the SAP profiles and hosts file to uppercase and restarted the SAP system (i did also restart the SAP services under windows).

After the restart the hostname in SM51 was shown in uppercase and the job RSUPG_PARCLONE did now start directly two other jobs DBCLONE1 and 2 and CPU usage on the server was increasing and the database and database log are being filled.

So, make sure that if your hostname (under start -> run -> cmd -> hostname) is uppercase every reference to the hostname is also in uppercase and viceversa.

Greetings,

Geert van den Heuvel

[Former Member]

The comments made by Geert van den Heuvel also apply for a MaxDB on OS Win x64 installation.

It's obviously a bug in the RSDBSCPY program.

[Former Member]

We had the same problem in Aix/Oracle/ECC6 when updating to ECC6 EHP4.

In instance profile, I made all entries concerningt hostanme in Upper case, but in SM51, the hostname always displayed in lower case. In Aix level, the command hostname returns the hostname in upper case and there is no problem.

We found that it is the problem from network setting, when we modified /etc/netsvc.conf by adding a line

hosts =local,bind4

Then when SAP restarts, SAP got the hostname from local setting (not dns resolution), so the hostname displayed in SM51 is in upper case and it is ok to restart EHPInstaller.

[Former Member]

Hi,

My installation of EHP4 stopped at the same phase that is MAIN_SHDCRE/RUN_RSDBSCPY

The error log says to increase the table space PSAPSR3701, i have increased the table space to enough space and repeated the phase and again it stopped, so i have increased nearly to 25 gb and again it stopped and the same thing is happening and the tablespace is eating up space like anything which has now eaten up to 174gb space even though there is no data(as this is a new dev system). I don't understand what to do now. I have raised an OSS, sap says to increase the table space, but what is the use it eating up all the space.

We have also increased each datafile from 50gb more additional space.

In DB02 i could critical table space issue.

Can some one help me.

Thanks,

kris

[Former Member]

Hi Kris,

I think it's better to calculate the space and do the necessary space settings first before you start the EHP4 upgrade.

As per my experience with 4 EHP4 Upgrade, i have noticed that, Two major Tablespaces, needs to adjusted before you start the EHP4 upgrade.

PSAPSR3 / PSAP<SID> - Increase atleast to 50% more of the Present Size.

PSAPSR701 / PSAP<SID>701 - This size is calculated by the ehpi tool based on the components you have selected to install with ehpi.

I am very sure, this space size settings will be sufficient to complete you EHP4 upgrade.

Best Regards,

Anwar

[Former Member]

Hi All,

Need help...

I had the same problem on phase RUN_RSDBDCPY. The RSUPG_PARCLONE job run on that phase and then I'll check on sm50 it show me that the process on status SLEEP. Then I'll check on sm37 and I found there is no DBCLONEn program was listed there, just the RSUPG_ PARCLONE in state ACTIVE.

I resolved it by restart the EHPI installation and repeat the phase. Now I can see 3 jobs generate is this phase. There are RSUPG_PARCLONE, DBCLONE1, and DBCLONE2. The RSUPG_PARCLONE and DBCLONE1 is ACTIVE and running. But if I see on sm50 the status of RSUPG_PARCLONE is SLEEP. DBCLONE2 still in RELEASED state. The problem is DBCLONE1 already run for 62000 s and still running. Isn't it normally ? Then how long will it take til' this phase finished ? My archivelog directory is full. May this could be the problem ?

Best Regards,

Jeffry

[Former Member]

Hi Jeffry,

Not to worry, if both the DBCLONE* jobs are active then it will definately finish after completing all it's required process and the time can depened on the amount of Packages you have selected for EHP4.

RSUPG_PARCLONE is a control job which will remain in sleep mode as this job is required to get the status of both the DBCLONE jobs, so that it can inform the EHPI tool accordingly.

As for the Archive logs, you can run a job to save and delete the archive logs hourly in some other mount points or disk space.

You should always keep the archive directory with enough space so that the DBCLONE jobs and the EHPI tool can run without geting into a Archive stuck situation.

Regards,

Anwar

[Former Member]

Hi Anwar,

Thanks for your detailed info about RSUPG_PARCLONE job. Finally I resolved my problem by turn off the archivelog and add some background wp. When I restarted the phase again, these three jobs running together and it takes time around 3 hours until finished.

Regards,

Jeffry

[Former Member]

Hi Ruben,

I am not sure if your issue has already been resolved.

Nevertheless, I also faced the same issue and so I wanted to share my experience of the same.

The real cause of the issue was the inconsistency in the hostname.

Check the hostnames consistency in the SAP system (Profile values and DNS/Hostfile entry should be similar) as per Note 129997 and hopefully your problem will also be resolved.

Thanks and Regards,

Anwar

[Former Member]

This is a bug in the program RSUPG_PARCLONE.

There are two cloning jobs, DBCLONE1,DBCLONE2.

RSUPG_PARCLONE waits 10 seconds and checks the jobs.

If one succeed and one fails, RSUPG_PARCLONE goes into an endless loop. This is an obvious bug.

I did the following:

I fixed the reason that made DBCLONEn to fail.

I canceled the job RSUPG_PARCLONE.

I canceled the EHPI program (it didn't see that RSUPG_PARCLONE was no longer running)

I restarted EHPI and retried the step.

I also opened a message to SAP about the bug

Did you by any chance contact SAP about this and got an answer?

Good luck

Gal Bahar

[Former Member]

Hi,

thanks for yours answers.

What part of slog and alog you needs?(amber)

I don´t have any sp ended wit RC=12

How can i see the phase table space?

How do you fixed the problem of the DBCLONE fails? (GAL)

More thanks

[Former Member]

The DBCLONE phase can be very heavy. It clones tables using insert from select which causes a lot of writing to transaction log and locks in the DB. You can check the DBCLONEn logs, there might be a database error in there, or check you DB for sufficient space and transaction logs.

hope this helps you

[Former Member]

Hi:

i have a similar error....

When i was installing EHP1 for BI 7.0, the installation shows the following error in the RUN_RSDBSCPY phase.

In DBCLONE1.UWD log we found this:

3 ETG011 "ORA-00001: unique constraint (SAPSR3.TFAIT^0) viol"

3 ETG011 "ORA-00001: unique constraint (SAPSR3.THOLT^0) viol"

I contact SAP AGS and they send this note: 23237. Is about duplicate keys, duplicate rows, duplicate records. I run a query to found the duplicated records and i found 904 matches. Now, i don't now what to do... is confusing...

About the space and archiving in this process, i choose to put the database in noarchivelog mode, and the space left is about a 20% of total database size.

I going to run this process again, i think this is an bug from EHPI....

[sunny_pahuja2]

Hi Javier,

3 ETG011 "ORA-00001: unique constraint (SAPSR3.TFAIT^0) viol"

3 ETG011 "ORA-00001: unique constraint (SAPSR3.THOLT^0) viol"

From this error, it looks like some of your tables has duplicate entries. I think some of *VERS (e.g. SVERS, AVERS etc.) tables already has entries of 701. Because upgrade try to change 700 entries to 701. If 701 is already there then it will give this error.

Please check *VERS tables and let me know. Don't delete any data from these tables without SAP consultantion as these are control tables.

Thanks

Sunny

[jonathon_sells3]

Hi everyone,

I am getting the exact same error as Ruben Torres. Our database is SQL Server 2005 SP3.

A couple things to note:

We let our EHP sit at the RUN_RSDBSCPY step for over 72 hours. Nothing happened. The DB or TLOGS never grew. All the disk drives had sufficient space.

I tried canceling the job RSUPG_PARCLONE using sm37. The job never cancels. I had to use SM50 after after waiting for an hour for it to cancel. I then re-started the EHPI. It still behaves the same. It doesnt resolve the problem. RSUPG_PARCLONE sits in an On Hold / SLEEP status according to SM50.

I noticed in SM37 that the regular scheduled jobs are put into a Released/Susp. status. Almost as if the EHPI is running the program BTCTRNS1.

How do I get past the bug ithat Gal Bahar claims to have?

Regards,

Jon Sells

[jonathon_sells3]

I opened a customer message and the e Note: 23538 "Problems due to inconsistent host name syntax" has resolved my issue.

Beleive it or not, the host names of the instances are case sensitive in the SAP profile parameters. The entries must be in lower case within a windows system. After those were adjusted and the instance restarted, the job RSUPG_PARCLONE took off and triggered DBCLONE1 & DBCLONE2. and the CPU was heavily utilized!

[Former Member]

Kudus to Gal Bahar. I could see that DBCLONE1 job had failed due to disk space. After adding disk space, restarting SAP to kill the RSUPG_PARCLONE job, everything resumed.