Re: Non-technical query about patching databases

I would say at least 2 case you want to take vacation. 3 is better so you don't have to juggle time off between you two. We have 2.5 DBA's for about 50+ Oralce/SQL databases. The .5 is mainly there in case the two of us are gone and can provide basic support and is trustworthy to where he is not going to do something he shouldn't or doesn't know. It also depends on projects you working. We are DBA's then end up doing a lot of pl/sql development for systems and reports (something any other sql developer could do), so therefore sometimes not enough "DBA" stuff. It also depends on how many application developers you have and how needy they are. We have 17 and they are pretty needy as we develop almost all our own software and constantly having new code go to production. They key is to automate as much as you can.

On Wed, Jan 17, 2018 at 1:47 PM, Andrew Kerber <andrew.kerber_at_gmail.com> wrote:

> 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