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@xxxxxxxxx>
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@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.'
