Reduce downtime required for support patch application

[Former Member]

Dear Experts,

I would like to know if there are any tips / notes we need to follow during application of

support patches to reduce the downtime window ( as during patch application , system is not

usable for normal users ) , any temparary parameter changes to Oracle RDBMS which we can

activate before appication of support patch and then revert the same once Patches are loaded

for normal Day operations.

Is there any note which talks specific settings which could enhance the performance

of support patch application process on Oracle RDBMS.

Regards,

RR

[Former Member · Accepted solution]

Ganesh,

In addition to above please check below SAP notes. This may help you

Note 1223360 - Composite SAP Note: Performance optimization during import

Note 1127194 - R3trans import with parallel processes

Thanks,

sushil

[Former Member · Accepted solution]

Allow me to direct you to this blog, it might give you some further brain food

[Comparison Support Packages downtime minimized to standard method|https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/12248] [original link is broken] [original link is broken] [original link is broken];

Regards, Michael

[Former Member · Accepted solution]

Dear all,

Thanks you very much for your views.

I have reviewed notes 1309506 and 1127194

As per note 1309506 , we have implemented correction and found option for 'Parallel R3trans' in SPAM

settings tab.

Is note 1127194 talks about same paralle R3trans process through parameter option ? or it is

different from note 1309506 ?

I do not understand where we need to set "parallel = n" as per note 1127194 ? and does it related

to support package only ? , what this parameter would exactly do ? ,what are the adverse effects of this parameter ?

Does weblog /people/michael.hofmnner/blog/2008/12/17/comparison-support-packages-downtime-minimized-to-standard-method talks about some different

aproach , since i have never tried this " Downtime minimized " option ,

appreciate if ' mho ' could list down some step by step procedure to follow for " Downtime minimized " option , as i do not understand in weblog , how we can start inactive import: start support packages (with SPDD)

and resume support packages until the downtime phase ends which are listed steps in weblog

Regards,

RR

Edited by: ganesh rr on Jun 4, 2009 2:20 PM

[Former Member · Accepted solution]

how we can start inactive import: start support packages (with SPDD)

Basically you do everything in transaction SPAM as usual, you only have to activate the 'downtime minimized option'. You start applying your queue and you will be notified, when the downtime phase starts.

Regards, Michael

[former_member204746 · Accepted solution]

I am presently using downtime minimized option on an ERP 6.0 system.

without that option, I needed about 10 hours of downtime, I have cut that down to about 5 hours (I have over 100 support packs to install).

[Former Member · Accepted solution]

Gentlemen , Thanks for your answers.

To my understanding if i select Downtime minimized some phases of Patch application could

be carried out when users are online and for others would get notified in SPAM for downtime

, so we just need to lock users and perform start for those rest of Import phases.

( I hope written above is not applicable for single patch but is applicable for queue of patches )

I would like to understand more options to finetune i.e note 1309506 ( would parallel 4 R3trans process

give me benefit as far as processing of patches are concerned )

What about "parallel = n" as per note 1127194 , where we need to set this parameter ?

does it have any adverse effects ? is this parameter is temparary settings for SPAM and should

be reverted after patch application ? Is this parameter is different from what is mentioned in note 1309506

Also as per weblog /people/michael.hofmnner/blog/2008/12/17/comparison-support-packages-downtime-minimized-to-standard-method , would increase

in parameter db_cache_size=2000M would give performance benefit even if i have not selected

Downtime minimized option ?

Regards

RR

[Former Member · Accepted solution]

To my understanding if i select Downtime minimized some phases of Patch application could
be carried out when users are online and for others would get notified in SPAM for downtime
, so we just need to lock users and perform start for those rest of Import phases.

Yes this is correct, theoretically you can apply single patches with downtime minimized one after another. But this does not make a lot of sense obviously, because you will have several distinct downtimes then. So to apply one queue containing all packages is the way to go.

Regarding your questions on the benefits, i am afraid the answer here is: it depends, as for most performance tuning options you will have to test carefully if the are working.

For the db_cache_size consider:

- is my db_cache_size smaller than 1000M?

- do i have enough free memory on my server?

- am i seeing low buffer hit ratio while applying support packages?

If all questions are a yes, then i recommend you increase it to 2000M, it is easy to do. But if you don't have free memory on the server, then you will severly hurt performance by causing paging. If you don't have low buffer hit ratio (or you have lightspeed disks , then the tuning will not speed up anything.

As you see, you have options, but there isn't a single speed button that solves your problem.

Regards, Michael

[markus_doehr2 · Accepted solution]

The parameter "parallel = X" in the TMS profile and the settings in SPAM are different. If you change the parallelism in SPAM then parallelism will only be used in SPAM and SAINT for support package application and AddOn installation. If you set it in the TMS profile it will also be used for your normal transport also. They don't exclude each other.

And about setting db_cache_size - yes, of course; the lesser I/O the database needs to do and the more data it can hold in the memory the faster it will be. An access to memory is up to 100 times faster than doing I/O on disk.

If you have the memory I would increase that parameter even more (and sga_max_size).

Markus

[markus_doehr2]

The question is: Where is your bottleneck?

As a first shot you can try to activate parallel importing of packages:

Note 1309506 - SPAM/SAINT with parallel R3trans

This can significantly improve the speed that is needed for patch applications.

Apart from that you would need to analyze your system and check where most of the time is spent.

Markus