How reliable is SAPupStat.log?

[former_member1012268]

Hello World,

got the EHP5ERP6 -> EHP7ERP6 upgrade from hell going here, and step Preprocessing has been churning away for three days straight(!)

SAP is, as usual, of next to no help in figuring out reliable ETA estimates.

I want to know how reliable the time stats in SAPupStat.log are for predicting the ETA on this roaster.

We got mild swapping on OpSys level (~300MB), a ~600GB MaxDB DB and an 8CPU Server with 15GB RAM.

The hardware isn't too fascinatingly fast, but the claim of that SAPupStat.log file that it plans to keep on going like this for another three days (2014/08/12 11:56:36:  55.51% LEFT: 78:24:51 END: 2014/08/15 18:21:27) is just ludicrous.

I set MaxCPUs to 4 in the database and the cache buffers show 98%-99% hit ratio.

For the life of me I can't figure out why this thing is crawling like that, but this delay gets us close to meltdown "speed".

Anybody got any suggestions on this one?

[willi_eimler]

Hi Donaldo,

we determine the runtime of an upgrade in the sandbox phase of a project. My last ERP upgrade to erp 6.0 to EHP6 ran 4 days.

Best regards

Willi Eimler

[former_member1012268]

Was that 4 days for the entire upgrade or just for Step "Preprocessing"?

[willi_eimler]

Hi Donaldo,

1. the stack.ini is responsible for the imported packages.

2. the entire update ran 4 days (HP-UX 16 CPU 67GM memory).

The long runtime results in the fact, that the most time of the upgrade the user are able to work in the system.

Best regards

Willi Eimler

[former_member1012268]

Just a late follow up, after lots of burned midnight oil (much of it could have been spared with better documentation and more reasonable error messages), I was able to nail the ERP Upgrade process down so smoothly that I am now upgrading two systems in parallel.

But that story about "most time of the upgrade the user are able to work in the system", only holds true for end users.

Step "Preprocessing", as harmless as it sounds, takes up almost half the processing time, and during all that the system is locked for changes.

So our developers are up in arms, and I end up having to manually unlock the systems here and there.

Its not the way its supposed to be done, but that "minimum downtime" in Preprocessing lasts over three days(!), even on our fastest servers.

[former_member1012268]

Follow up to the follow up.

Having come to mistrust many of the defaults presented in the upgrade process, I increased the suggested values for almost all parameters (Work Process assignments, R3load processes and so on) by almost threefold, and the effect was that the system finished all the way to & including step Preprocessing in just three days, where before it took almost 5(!)

It was a kind of gamble, but the system had plenty of CPUs and RAM to spare, and I was befuddled by the extremely low preset values for many of those parameters.

So in conclusion, those defaults are *not* based on any ad-hoc analysis by SUM done on the target system, but seem to cover just the bare essentials.

Not too smart, in my humble opinion.

[madasamy_arunachalam]

Hi Donaldo

Sometime noticed that the "stats update"  performing manually helps (before upgrade/SUM tool start) considerable % of the time during upgrades &  we should  not select option like  "stats update" and  "ABAP load generation during upgrade"

Also, have you selected below under "selection of parameters"  during "configuration" phase ?

"Automated batch job distribution (system will decide where to run the jobs)

"Memory Optimized activator" (Yes or No)

Refer OSS Note 1387739 - Out of memory errors during shadow system operation

This note has interesting (weird ?)  point "Be aware that usage of memory-optimized activator can cause the activation phase to run very long!",

"memory optimized" means activation time should be quicker ?

regards

Swami

[Former Member]

Hi Donaldo,

I'm really not a fan of the SAP estimates for the upgrades.  For me, it's just a case of doing it and recording the time taken.  Are you saying that it's stuck in one phase for the last 3 days?  Not good, if that's true.  Is this a Production copy or a Dev system?  Have you got this EHP applied in any of your landscape currently?

Regards,

Graham

[former_member1012268]

Yup, its just finishing up step "Preprocessing" - after three days solid(!)

Its sooo frustrating not to be able to give the business a reliable estimate on the ETA.

Also, I am (desperately) trying to figure out when/where (Source or Shadow) CVERS and UVERs are updated, as the first test run bumped out in Post(!)processing, because three entries in CVERs didn't match up with UVERS.

SAP's genius tool SUM had simply "forgotten" to upgrade three basis components, I assume it was because of a faulty stack file, but SUM never complained about it, and since it wasn't my SolMan setup, I can only prove that indirectly (that old stack file lists EHP6 as a "replaced product", even so we started out with EHP5-ERP6).

WTF SUM didn't catch that at the beginning is beyond me, I simply trusted what MOPz had calculated and went for it (just got these systems handed over to me a few weeks ago).

In any case, I am trying to figure out if I am on the safe side now, or in for another bad surprise.

But I can't get a straight answer from SAP to that, and now it seems like I'll have to wait another three days(!) before I'll find out "the hard way", if that stack file was any better than the last one.

This is ridiculous, a whole week and SAP replies once a day to the help ticket I opened up about this.

We already had to postpone the Prod switchover, because everybody is now behind on testing 😞