Re: Database Outages - Best Practices
- From: stephen booth <stephenbooth.uk@xxxxxxxxx>
- To: Michael Fontana <mfontana@xxxxxxxxx>
- Date: Mon, 14 Feb 2005 22:10:39 +0000
On Mon, 14 Feb 2005 15:25:08 -0600, Michael Fontana <mfontana@xxxxxxxxx> wrote:
> This is interesting, but it seems to dispel the notion that this very same
> management is going to have to do quite a bit of coordination to accommodate
> you. For example, customers must be notified, application support personnel
> may be needed to shutdown and restart services and applications.
What's easier? Agree with the customers that the applications won't
be available from 00:01 Sunday to 07:00 Sunday (or whatever period you
agree) for the forthcoming year (and with the expectationt hat such a
state shall continue beyond that). Or call round at 15:30 on Friday
afternoon to get an outage for that weekend because a new hyperurgent
security patch has come out or you're running into an undocumented
feature that needs a patch now (from what I understand the quarterly
patchset release schedule is just that, patchsets, individual patches
will be released as and when, you might sometimes need to apply an
individual patch to fix a problem), also scheduling the application
support people who had all planned to go surfing this weekend. Or
telling the customer that they're going to have to go to the previous
night's backup because the server/NAS/SAN/database just ate itself due
to lack of preventative maintenence.
Scheduled periods, with the option to use it or not, means that
customers can plan around them, it also means that the application
support team can set up a rota for who will come in if the application
needs to be bounced. I'm not talking about some theoretical ideal
here, I'm talking about what companies that I have worked for have
done and found to work well.
Stephen
--
It's better to ask a silly question than to make a silly assumption.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
