[OAUGNetDBA]-Re: 5 day 11.5.10 upgrade (why so long?)

["Apparao Kandru" <Apparao.Kandru@imminet.com>]

Hi,

Most of us have upgraded a year or two ago. I recall the database portion has 70K jobs or so for this upgrade where the bulk of the time is spent. Make sure you have all the AD patches,(some bugs in
how ad splits work to parallel workers, where jobs continue to spin even if there is no work) and there are a few site specific things you can do. This will need some functional experience and module domain knowledge. An e.g.: Since Oracle creates this patch for all customers(say 11.0 to 11.5.10.2) they have scripts in here that are not relevant to some customers(from 11.5.9 to 10). One such example is wshupios.sql. There is a bug here where it will  spin for a long time even if there are no records that meet the criteria due ad parallelization. In my case, I replaced the sql with a null.  Given your limited hardware, the best thing for you would be to capture your top time consumers from OAM and logs and look at to see what can be done to speed those big guys. There will be some you won't be able to make any faster, such as recompiles. Our 11.5.10.2 upgrade 2 yrs ago, only took 18 hrs with 200+ recommended patches on top of cu2.

Regards,
-Apparao



>>> <oraapps@carolina.rr.com> 5/27/2008 12:25 PM >>>
Ron,

The CPU on the Database box is never taxed -- it doesn't ever get to over 7% utilization (just eyeballing it).  The forms/web box is where all the work is going on and I don't ever ped this box more than 40%.

I'm sure more CPU's will allow me to add more workers but there really has to be something else to do ---besides just throw processors at it.

If I do temporarily add processors -- will there be any impact or ramiphications when I remove the processors?  Is there a guide or anything from a tuning perspective I can folllow to do this?

Thanks,

NJAD
---- "McRaney wrote: 
> 1 CPU will be a long July 4th holiday... we took 30 hours with 6 CPU and 12 workers on DB server.  I wouldn't trust more 4x, it is a mess when they get out of sync to clean up, not worth the effort.
> 
> Other option is to lease/borrow CPU modules and memory for the upgrade, if server can handle more.
> 
> Ron
> 
> -----Original Message-----
> From: OAUG Net DBA listserver [mailto:OAUGNetDBA@oaug.com] On Behalf Of oraapps@carolina.rr.com 
> Sent: Tuesday, May 27, 2008 8:46 AM
> To: OAUG Net DBA listserver
> Subject: [OAUGNetDBA]-5 day 11.5.10 upgrade (why so long?)
> 
> Hello DBA's,
> 
> We completed two 11.5.9 to 11.5.10 upgrades on our test boxes. 
> Sad to say the patch 3480000  with 2 workers and 4 workers and chunk size of 2000 takes about 120 hours to run.
> 
> Does anyone have any tips for how to speed up the process?
> 
> We have a two tier configuration Apps/Forms on one box and Database Concurrent manager on the other.  Each box has the ulimits set to unlimited for the applmgr account.  The database is not in archivelog mode.  When using a tool like topas I show two to four java processes never taking up more than 13% of the CPU and only on my forms/web tier.  Which is where I'm applying the patch from.  On the forms/web Tier when the patch is working away -- I almost always see java processes that never seem to take more the 13% of the CPU.  Memomory is avaialbe on both boxes and CPU -- is there any way to push these processes to take up more resources?  Also -- is there any guidelines for adding more worker processes -- we only have 1 CPU and as a rule of thumb we see never to more than 4 X the number of CPU's.  
> 
> Does anyone have experience with the workers being higer than 4 times the number of CPU's.  ( Sort of worried about jobs getting completed out of sequence).
> 
> Appreciate any help you can provide in making the big patch go faster.  
> 
> Thanks,
> 
> NJAD
> 
> 
> #############################################################
> This message is sent to you because you are subscribed to the mailing list <OAUGNetDBA@oaug.com>.
> To unsubscribe, E-mail to: <OAUGNetDBA-off@oaug.com> To switch to the FEED mode, send any message to <OAUGNetDBA-feed@oaug.com> To switch to the DIGEST mode, E-mail to <OAUGNetDBA-digest@oaug.com> To switch to the INDEX mode, E-mail to <OAUGNetDBA-index@oaug.com> Send administrative queries to  <OAUGNetDBA-request@oaug.com>
> 
>  
#############################################################
This message is sent to you because you are subscribed to the mailing list <OAUGNetDBA@oaug.com>.
To unsubscribe, E-mail to: <OAUGNetDBA-off@oaug.com>
To switch to the FEED mode, send any message to <OAUGNetDBA-feed@oaug.com>
To switch to the DIGEST mode, E-mail to <OAUGNetDBA-digest@oaug.com>
To switch to the INDEX mode, E-mail to <OAUGNetDBA-index@oaug.com>
Send administrative queries to  <OAUGNetDBA-request@oaug.com>




#############################################################
This message is sent to you because you are subscribed to the mailing list <OAUGNetDBA@oaug.com>.
To unsubscribe, E-mail to: <OAUGNetDBA-off@oaug.com>
To switch to the FEED mode, send any message to <OAUGNetDBA-feed@oaug.com>
To switch to the DIGEST mode, E-mail to <OAUGNetDBA-digest@oaug.com>
To switch to the INDEX mode, E-mail to <OAUGNetDBA-index@oaug.com>
Send administrative queries to  <OAUGNetDBA-request@oaug.com>


****************************Confidential****************************
This correspondence is intended solely for the person or 
entity to which it is addressed and contains confidential
information. Any review, reproduction, dissemination, or 
other use of this correspondence by persons or entities 
other than the addressee is prohibited.
**********************************************************************


#############################################################
This message is sent to you because you are subscribed to the mailing list <OAUGNetDBA@oaug.com>.
To unsubscribe, E-mail to: <OAUGNetDBA-off@oaug.com>
To switch to the FEED mode, send any message to <OAUGNetDBA-feed@oaug.com>
To switch to the DIGEST mode, E-mail to <OAUGNetDBA-digest@oaug.com>
To switch to the INDEX mode, E-mail to <OAUGNetDBA-index@oaug.com>
Send administrative queries to  <OAUGNetDBA-request@oaug.com>