A person would think (silly me) that a sites like that would (I would say should) have some level of redundancy build (either as standby or replicated database or copy of the database) as a part of their DR policy. That redundancy would help to minimise (even possibly eliminate) downtime. That way all work on upgrades can be done behind the scene. I worked on site where redundancy was build in application itself, so there was effectively no downtime (OK, we called all users that were using application at 3 a.m. [both of them] to get in and out of application). Maybe an idea that you may share with all CIOs and VPs next time a critical update/patch needs to be applied Kind Regards Kresimir Fabijanic Jared.Still@xxxxxxxxxxx wrote: >In addition, when your company has offices in time zones all over the >globe, >the idea of 'after hours' gets a bit muddy. > > > > > >Mladen Gogala <mladen@xxxxxxxxxxxxxxx> >Sent by: oracle-l-bounce@xxxxxxxxxxxxx > 02/12/2004 01:36 PM > Please respond to oracle-l > > > To: oracle-l@xxxxxxxxxxxxx > cc: > Subject: Re: installing security patches on a Windows database > server (was "Oracle >10g for Windows") > > >On 02/12/2004 03:04:08 PM, Paula_Stankus@xxxxxxxxxxxxxxx wrote: > > >>Don't do the patch until after hours!!!!!!!!!!!!!!! >> >> > >Define "after hours". When working at OXHP, after hours was 2 hours >a week, on Saturday afternoon. Everything that required downtime had >to be done then. Restarting database at any other time required an >explicit approval from the CIO himself or coordination between >VP of shared services, VP of development and representatives of >the business side. Restarting system is actually a very, very big >deal. I know a guy who used to work at the site which managed >911 calls for the state of NY. They had downtime window of 1 hour >a month. The phrase "after hours" can be radically different from >one place to another. For instance, I doubt that Rajendra can >restart database which follows the scores of the sport events >after 5 PM. That would be a bigger scandal then the unrehearsed >wardrobe malfunction during the recent sport mega-event. > > >---------------------------------------------------------------- >Please see the official ORACLE-L FAQ: http://www.orafaq.com >---------------------------------------------------------------- >To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx >put 'unsubscribe' in the subject line. >-- >Archives are at //www.freelists.org/archives/oracle-l/ >FAQ is at //www.freelists.org/help/fom-serve/cache/1.html >----------------------------------------------------------------- > > > > >---------------------------------------------------------------- >Please see the official ORACLE-L FAQ: http://www.orafaq.com >---------------------------------------------------------------- >To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx >put 'unsubscribe' in the subject line. >-- >Archives are at //www.freelists.org/archives/oracle-l/ >FAQ is at //www.freelists.org/help/fom-serve/cache/1.html >----------------------------------------------------------------- > > > ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------