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

["John Kanagaraj" <john.kanagaraj@gmail.com>]

Njad,

You didnt mention OS but if this is *NIX then you can easily determine
the effect of context switching which is one of the main reasons that
Oracle recommends 2*cpu. If CS is not an issue then you can easily up
the no of workers.

Also, monitor db waits via Statspack or AWR (10g) to determine if you
can do something on that tier. We can help with that.

John



On 5/27/08, James Morrow <morrow.james@gmail.com> wrote:
> The simple answer is to use a "Staged APPL_TOP" (MetaLink
> Note:  242480.1).
>
> This will allow you to take "as long as you'd like" for the
> "binaries" portion of the patch/upgrade.  Your downtime will,
> effectively, be the "database" portion of the upgrade.
> (plus some copying time).
>
>
>
> As to the "number of workers":
>
> The general rule-of-thumb of 2-3 times the number of CPUs is
> correct.  However, keep in mind that most of that is geared
> towards the database tier (where the bulk of the "heavy lifting"
> is typically done).  The rationale there is that, at a certain
> point, if you have too many serious things going on at once the
> system will spend more time managing the processes than actually
> getting work done.
>
> On the larger-scale end of things, having a large number of workers
> (say, on a 24 or 36-way box) doesn't always help as dramatically as
> you might think.  The large part of the reason is the "phases" of a
> patch may not really have enough work to keep all of those threads
> busy.  (If you have a phase that has 500 tasks, it's a great help.
> If you have a phase with 10, not so much).  Also, if one of those
> tasks takes a long time to complete at the end of the phase, then
> all of the other workers will sit idle until the next phase.
>
> If you're having an issue with the forms/web tier, you may be able
> to go higher there.  Keep in mind that all of the patches are
> structured in "phases" that are designed to properly deal with
> dependencies amongst the tasks.  On the forms/web tier, you're
> largely doing things like generating JAR files and Forms.  These
> are (typically) fairly independent activities.
>
> The number of threads relative to the number of CPUs should not
> cause a "problem" by itself.  Certainly not one that would require
> correcting.  If the patch works without error on a 24-way box
> running with 96 threads, it should work the same on a 2-way box.
> At a certain point (again, threads relative to CPU), you will
> actually start to overwhelm the system, thus slowing yourself
> down (possibly dramatically).
>
> So, assuming that your issue is mostly on the Forms/Web tier and
> the CPU utilizationis only running 13%.  Also assuming that this
> means you're >50% idle (and not spending alot of time doing I/O
> or doing "system" tasks), then you could probably go up to 6
> workers without much worry.
>
> Also, "borrowing" a CPU and/or memory to throw into the box should
> be fairly transparent.  (no special configuration necessary, as
> long as the box can support it).
>
> -- James
>
> On Tue, May 27, 2008 at 10:46 AM,  <oraapps@carolina.rr.com> wrote:
>> 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>
>>
>>
> ----------------------------------------------------------------------
> James J. Morrow | Senior Oracle Applications DBA
> morrow.james <at> gmail <dot> 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>
>
>

-- 
Sent from Gmail for mobile | mobile.google.com

John Kanagaraj <><
DB Soft Inc
http://www.linkedin.com/in/johnkanagaraj
http://jkanagaraj.wordpress.com (Sorry - not an Oracle blog!)
** The opinions and facts contained in this message are entirely mine
and do not reflect those of my employer or customers **

#############################################################
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>