Re: Non-technical query about patching databases

  • From: Andrew Kerber <andrew.kerber@xxxxxxxxx>
  • To: Stefan Knecht <knecht.stefan@xxxxxxxxx>
  • Date: Wed, 17 Jan 2018 15:47:16 -0600

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@xxxxxxxxx>
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
| @zztat_oracle




-- 
Andrew W. Kerber

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

Other related posts: