- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: Reducing downtime for database patching
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-30-2003 12:03 PM
тАО06-30-2003 12:03 PM
Clara
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-30-2003 12:10 PM
тАО06-30-2003 12:10 PM
Re: Reducing downtime for database patching
After we bring good working system we
try to not make patch update.
If we have no other option so we preparing
every thing for update and choose the best
time for and do it fast!
Another option is work in cluster so you
update one server, sync it and the you work
on the other.
Caesar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-30-2003 12:13 PM
тАО06-30-2003 12:13 PM
Solution1) Quickly down the databse, split the mirror its sitting, on bring it back up.
2) Handle the database upgrade on a non-production server.
3) Down the database again.
4) Transfer in the revised version of the database to production, along with all system tables and such that were modified for the upgrade. We don't transfer back the data which has gotten out of date due to new transactions while we were working. Only database instance system data is migrated back in.
5) Bring the database up, resynch the mirrors.
The two down times for the production database are only for how long it takes to bounce the instance.
This doesn't work if a patch or process requires all data to be upgraded, but it works for most patches that change the executables and data in the oracle database systems tables.
I don't think oracle supports this methodology, but we actually have done it, so it does work.
SEP
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-30-2003 12:19 PM
тАО06-30-2003 12:19 PM
Re: Reducing downtime for database patching
Sound's like an infra structure issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-30-2003 12:23 PM
тАО06-30-2003 12:23 PM
Re: Reducing downtime for database patching
On our production systems, as a general rule we do not make patch changes unless it is absolutely necessary. If we find that it is, the patch or patches are installed on our development and QA boxes first. Then those systems are monitored for any fluctuations in operation. If everything is sucessful then we perform the install on our production app servers first, if they are in need of the patch(s). Then we perform the install on our production box. As far as the time to do that, we have the luxury of a four hour maintenance window starting at 7pm every Sunday night. If there is no maintenance to be done, then we just reboot all of our boxes and let them go back to humming along. We the system was constructed and put into place, a maintenance window was one of the provisions that was bargained into the deal. That way we do not have to fight to schedule a downtime. We are supporting operations around the globe...so I am sure it is an inconvenience at some locations.
That is our spin on it.
-Bryan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-30-2003 12:26 PM
тАО06-30-2003 12:26 PM
Re: Reducing downtime for database patching
Sorry Clara,
I missed the Oracle patches part! duhhhhh!!!
I apologize...but I think we handle the Oracle patches in roughly the same manor I described. We are an extremely conservative crew here, so we only make changes if it is absolutely necessary. No ifs ands or buts about it. The Oracle changes are handled during our Sunday night outage also.
-Bryan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-30-2003 07:35 PM
тАО06-30-2003 07:35 PM
Re: Reducing downtime for database patching
patch only if it is necessary!
We prefer to install the patch on a test (development) server first. Test everything. After that, identify a suitable downtime period that would less affect our 24x7 operations. Then proceed as Mr. Protter mentioned about (well, in our own way ;) ).
We take no risks since our business depends on it.
regards
Yogeeraj
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-30-2003 08:32 PM
тАО06-30-2003 08:32 PM
Re: Reducing downtime for database patching
and migrate 8.1.7.3 to 9i.
If you have enough hardware resources I would suggest one thing - Create a new database with the patched up software. Then export the running database and import into the new database. This would not require a downtime for the live database.But you'll have to plan to incorporate the changes that are made in the source after the export has been taken into the new database.And it'll involve more work also though it descreases the downtime required.
If you are migrating to 9i this is infact one of the migration methods.
Further patching time depends on your processor speed and all.If you can upgrade to a more powerful processor that'll help in reducing the downtime.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-30-2003 11:38 PM
тАО06-30-2003 11:38 PM
Re: Reducing downtime for database patching
apart from others suggestion, each time we need to apply a patch we take all the time needed.
We know this means night or week-end, of even more easy on holidays, but we feel patch very risky and data alignig even more risky.
So, in case of updates, we take a test on develop and test, measure the time, and then we decide with the cutomer an appropriate time-frame.
This shall include, for every server if a cluster:
- backup offline of DB- executables
- install patch O.S. if needed
- kernel recompile if needed
- DB executable patching
- DB data (catalog, For example) updating
- DB backup tools test of backup POST- ACTIVITY
- test from key users
We cannot risk to forgot some data or to have some non-updated cluster.
You said that you cannot afford downtime for the patching.
The patch is necessary? Than take your time.
HTH,
Massimo
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-01-2003 04:38 AM
тАО07-01-2003 04:38 AM