Re: Non-technical query about patching databases

Obviously for a task like that it depends on what tools you have available. The OEM Cloud control provisioning and patching pack can make patching much easier and faster, assuming all of your instances are configured identically with regard to file locations and such. If you are set up properly and consistently, it can be done with 2-3 people without a lot of work.

On Wed, Jan 17, 2018 at 3:36 PM, Stefan Knecht <knecht.stefan_at_gmail.com> wrote:

> I agree with what was said. It also depends on the databases. A lot.
>
> There are Oracle databases out there which are mostly idle, see very
> little activity and with the application doing virtually nothing, patching
> also has a very small chance of actually breaking anything. Databases like
> that you can patch with very little effort, even fully automated.
>
> But there are also wholly different beasts out there, which require weeks
> of testing (which will consume DBA time to support the testing efforts) and
> it can be a full-time job for one guy to just plan, test, and finally
> deploy the patch through development, QA and production for a single
> database.
>
> What I would do if I had to get a realistic approximate is try and get the
> following data:
>
> - Database size and concurrent sessions during peak and off-hours (a
> larger more active database may be more vulnerable to behavior changes
> introduced in the new patch)
> - Data dictionary size of each database (a larger dictionary may take
> longer to patch, but it depends on the patch)
> - Type of application that runs on it. Third party? Java? In-database
> PL/SQL? etc (this-party apps are often treating the database a bit like a
> black box and are less affected by patches. If the entire app is written in
> PL/SQL and Oracle SQL it may be more affected).
> - Another big factor are one-off patches. If any database has a one-off
> patch on top of the current PSU applied, it must be checked against the new
> PSU to make sure that there is a one-off available for that version as well
> (otherwise it needs to be requested which may take a week or two and also
> consumes someone's time to keep up with the request). It's also possible
> that the one-off is already included in the new PSU. It's another thing
> that can take quite a bit of time
>
>
> Another point to plan for is failure handling - if you're patching 50 DBs,
> odds are one will fail. That'll take time to handle as well. It doesn't
> happen a lot, but it does happen.
>
> Stefan
>
>
>
>
> --
> //
> zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework!
> Visit us at zztat.net | Support our Indiegogo campaign at igg.me/at/zztat
> | _at_zztat_oracle
>

-- 
Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

--
http://www.freelists.org/webpage/oracle-l