Solved: ERP (6.0) patch take very log tome.

Hi all.

I have planning to patch oures ECC 6.0 (ERP 6.0) form sp 13 to sp 19 on HP-UX ia64 and DB oracle 10.2.0.4. We have the latest kernel, TP and R3trans and more than 500 GB disk space. We have a new copy of production installation for test this patch. We started with test system. But the import fase take long time over 50 hours. At last patch stop with following syntax error on st22.:

Database error text.: "ORA-01555: snapshot too old: rollback segment number 10 with name "_SYSSMU10$" too small"

Internal call code....: "[RSQL/FTCH/BSEG ]"

Is it normal this import take so long time.

I did read this Note 618868 - FAQ: Oracle performance.

Any help I did used a lot of time for this process.

Regards

SAP Managed Tags:
Oracle Database

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Accepted Solutions (1)

Have you completed all the post system copy steps? also make sure you execute the database stats for all the object.

refer note 838725, and schedule stats in db13.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Hello Sunil,

I do not know what you mean with post system copy steps! I am going to Patch ERP form sp 13 tp sp 19 by using TCO SPAM. And not system copy.

Would you please explain what you min?

Thanks for reply

Hi,

first things first;

What hardware you on?

CPU

Memory

Disk array.

What's in your init ora file..

Mark

I thought you have done a system copy to test the patches. I wrongly read your message.

It taking long time may be you are only using one R3trans process to apply SPs. There is a option in SPAM -> Extra -:> setting.

Is your syntax error resolved? haev you tried to restart SPAM again?

Hello Sunil,

CPU is itanium processor.

Yes I did rester SPAM servel time but each time take long time to stope with this error. And still I have the same problem.

Can I use more than one paralle Import processe per R3trans? Is it help for make import porcess faster?

Thanks

Hi,

Since you are using single R3trans process that is one of the reason for slow performance. Use parallel R3trans process to update patches which will be very fast. But you can use parallel processing if your SPAM version is 35 at least. You can check SAP note 1309506 and 1127194 for more information.

Thanks

Sunny

Whats your DB size and the UNDO tablespace size? are you using AUM (Automatic Undo Management) check the database parameter undo_retention.

Check note 600141

Once you are in SPAM is running then you are not allowed to change the SPAM settings.

Thanks for help.

How many parallel process can I use for update this patch?

I will stop my this patch and start new one. Any idea how many parallel process can I use

It's patch has run for 26 hours and I am sure it will stop again with error.

I have spam version 42.

I am not sure about AUM but undo_retention i2 about 87987.

Regards

Please update disp+work package to the latest level.

Similar problem was observed with Kernel patch level 278, after updating disp+work package it was resolved.

With regards

SAP recommends to use max R3trans process upto 5. You have to set this before you start importing/scheduling the queue. In your case you won't be able to change as you are in middle of importing queue.

If your psapundo table is small then try to extend and retry SPAM queue.

Hi Sunil,

Thanks for help again.

I have a lot of space on psapundo table, so problem is not table space.

I have a batch job running for scheduling the import queue.

Is it possible to stop the batch job on sm50 and start a new one with 3 or 4 R3trans process?

what about VijayIngle id. I have already last R3trans and tp patch. Can it help to updating dis+work pakages?

Regards

I asume you have checked the PSAPUNDO tablespace history (as the vaulue will not change in DB)2 if you don't refresh)

Whats the size of your Database and psapundo tablespace?

You won't be able to change the parallel process until you complete the current queue.

There is no harm to update the R3trans, TP and disp+work to latest version. You can individually download these files from marketplace (not from stack)

About taking long time, Is your hardware is upto the mark? mean have you checked the CPU, memory and SWAP usage?

Hi,

After refresh on DB02, I can see we have over 10 GB left for psapundo table. and 240 GB for psapsr3 table. My import now runung for 41 houres. Yes oures hardware is op todate and I did checked CPU, memory and swap and ...

Is it normal take so long time?

Regards

As you mentioned you are going from SP13 to SP19 mean there are almost more than 200 patches in one go. I think thats too much. Is you system is ABAP or ABAP+JAVA? If you had java add-in then few more patches. I think this will more long time and as you are running only one R3trans process. Make sure you increase the R3trans process before you apply in Prod.

You can check the current patch being applied and logs under <drive>\usr\sap\trans\tmp

Thanks a lot for reply.

My system is abap SAP R3 ERP 6.0.

I will keep it ind my mind next time I will increase the R3trans process.

I can not see any error on /trans/ temp files. it will kom when it run for 55 hours.

I will refresh my table space in DB02 to see what is happeninig

Regards

There should be a log file under <drive>\usr\sap\trans\tmp for current patch being applied. Just sort by date and time.

Also check <drive>\usr\sap\trans\log

> I have already last R3trans and tp patch. Can it help to updating dis+work pakages?

Updating disp+work will not harm if not help.

If the import is taking too long time and your filesystems and tablespace are fine, then dispwork and dbsl (lib_dbsl) patch are suspects and you should update R3trans, tp, dispwork and dbsl to latest patch levels or if you have backup of previous working kernel use that one.

Regards

If you could post the action log of the queue, it would be helpful for use to help you.

Edited by: VijayIngle on Jun 22, 2011 1:05 PM

Edited by: VijayIngle on Jun 22, 2011 1:07 PM

Hello

Yesterdag we had som problem with oures server hardwar problem. So my import was stopet. I am going to restart my import.

I did update R3trans_304, tp_305, disp+work_306 and dbsl_307 to latest patch levels.

From DB02 I have this information:

PSAPSR3 free(MB) 571.066,81

PSAPSR370 free(MB) 8.999,81

PSAPSR3700 free(MB) 29.624,44

PSAPSR3USR free(MB) 9.245,88

PSAPTEMP free(MB) 38.720,00

PSAPUNDO free(MB) 19.137,44

SYSAUX free(MB) 636,31

SYSTEM free(MB) 70,00

I am will waite to see what happening.

Thanks again for help.

regards.

Hello all,

I am still have problem with my ERP 6.0 patch.

I have did patch kernal to SP291 and reimport my queue on spam.

After 40 hours I can see.

*OCS_QUEUE_IMPORT* job is activ but *RDDGEN0L* job has status Canceled.

I have this log file for SAPM, ST22, SM21 and al11.

Verzeichnis: */usr/sap/trans/log*

Name: SLOG1125.RSX

WARNING: (This warning is harmless if no further warnings follow.)

WARNING: System RSX. Warning. 20110627134420 :

ERROR: The following call returned with exit code 127:

ERROR: sapevt SAP_TRIGGER_RDDIMPDP -t name=RSX

ERROR: Background jobs cannot be started.

ERROR: Please check trace file dev_evt.

*Dev_evt* form al11:

RSTR0006: Display Developer Traces

Fri Jun 24 09:12:17 2011

Trace File of External Event Raiser (Level=0, Append=0)

EventID: SAP_TRIGGER_RDDIMPDP

SAP message server host: sapux24

SAP message server service (new): 3902

SAP message server service (old): sapmsRSX

ERROR ***: MsAttach (host=sapux24, serv=3902), rc = -100
ERROR ***: MsAttach (host=sapux24, serv=sapmsRSX), rc = -100

*St22*:

ow to correct the error

Database error text........: "ORA-01555: snapshot too old: rollback segment

number 3 with name "_SYSSMU3$" too small"

Internal call code.........: "[RSQL/FTCH/BSEG ]"

Please check the entries in the system log (Transaction SM21).

*SM21*:

Date : 27.06.2011

Time Type Nr Clt User TKode Priority Grp N Text

13:09:04 DIA 000 000 SAP* Q0 I Operating system call gethostbyname failed (error no. 0 )

13:13:05 BTC 009 000 REZ BY 4 Database error 1555 at FET access to table

13:13:05 BTC 009 000 REZ BY 0 > ORA-01555: snapshot too old: rollback segment number 3 with

13:13:05 BTC 009 000 REZ BY 0 > name "_SYSSMU3$" too small

13:13:06 BTC 009 000 REZ AB 0 Run-time error "DBIF_RSQL_SQL_ERROR" occurred

13:13:06 BTC 009 000 REZ AB 1 > Short dump "110627 131306 sapux24_ RSX_02 " generated

13:13:06 BTC 009 000 REZ D0 1 Transaction Canceled 00 671 ( DBIF_RSQL_SQL_ERROR )

From *DB02*:

Tablespace-- SIZE(MB) -

FREE(MB)

PSAPSR3--

4.028.000,00---- 224.124,75 94

PSAPTEMP~~- 38.720,00~~-- 38.720,00

*PSAPUNDO*-- 62.000,00---- 17.855,31

Is it any body have the same problem on ERP patch19.

Regards

Hi Reza,

Why don't you open an OSS message, about this case? It is obvious that this issue requires an on site check.

Best regards,

Orkun Gedik

Oh dear,

you are obviously facing a BSEG conversion !


Database error text........: "ORA-01555: snapshot too old: rollback segment
number 3 with name "_SYSSMU3$" too small"
Internal call code.........: "[RSQL/FTCH/BSEG ]"
Please check the entries in the system log (Transaction SM21).

either you did

a) a wrong SPDD adjustment for BSEG which is now trying to get rid of some customer fields

b) or you did not apply note 1283197 before(!) the start of the patchqueue

c) dependig on if you have patch 14 included or a split before the action of note 1227677 might be needed.

What's your status on this?

Did you restore and start over or did you increase undo to finish the conversion ?

Volker

Hello Volker,

Thanks a lot for reply.

At last I did increase undo.But I sill could not finish my import.

I got this error on ST22.

Syntax error in program "SAPLFACG ".

...

The following syntax error occurred in program "SAPLFACG " in

include "LFACGU02 " in line 301:

"The data object "T_BSEG" does not have a component called

"TAXPS"."

There is this SAP note 1385914, But I am not sure where can I add this field on BESG table.

Can you help me on it?

Best Regards

Hum,

this looks, like the note might already have been applied before your patchqueue, and in this case

the conversion of BSEG took the field out again (so that data is lost).

It might be possible to reenter the field, but the data will be lost, and I am sure this would not be a desired solution.

Did you had a SPDD stop?

Was BSEG in that SPDD list?

If yes, did you adjust BSEG in that stop? How?

As you are talking about ST22, what is the status of your queue now?

Are you finished and the application is dumping or is this in some XPRA-execution phase ?

You might be able to get some conclusions from transaction SE11 -> Version management

by comparing the last version before the queue against what you have now.

But you might need developer help, if you are not familiar with SE11.

Volker

Hello Volker,

Yes I had SPDD stop. I can not remember BSEG was in the SPDD list. Is it some way I can find out?

When I use SE11 There is "TAXPS" on BSEG table.

The status of my queue is XPRA-execution phase. I can not continue

If the conversion of BSEG har took the field out again it some way to save data?

Any idea how can I finish this import?

Thanks agin

Besdst regards


Hello Volker,
> Yes I had SPDD stop. I can not remember BSEG was in the SPDD list. Is it some way I can find out?
> When I use SE11  There is "TAXPS" on BSEG table.

Hi,

well, the note you mentioned is included in SP19.

So the changes of that note should all be present in your system.

Not sure how to proceed from here, as BSEG obviously has the required field.

The problem seems to be T_BSEG and there are quite a couple of notes for T_BSEG.

You might need to consult the version management to compare pervioue current and interim Versions.

Still not sure why BSEG was converted, but this XPRA problem might be triggered by someting else ?!?!?

Volker

Hi Volker.

After I check and compare pervioue version of BSEG table with interim Versions I can see my import has add "TAXPS" on BSEG table.

As I know the T_BSEG is a local table a copy of BSEG i program. Is it possible there is some problem with my SP19 stack? Or there is a program fejl?

Thanks again

Reza

This message was moderated.

Answers (0)

Ask a Question

Top Q&A Solution Author

User

Count

ERP (6.0) patch take very log tome.

Accepted Solutions (1)

Accepted Solutions (1)

Answers (0)

Re: reading external (OData) API from cap

Re: reading external (OData) API from cap

Re: SSO using OKTA - launches FLP twice

Re: SSO using OKTA - launches FLP twice

SSO using OKTA - launches FLP twice