Comments on: Oracle patching: The bane of the DBA’s existence http://itknowledgeexchange.techtarget.com/eye-on-oracle/oracle-patching-the-bane-of-the-dbas-existence/ A SearchOracle.com blog Sun, 29 Nov 2009 03:43:44 +0000 http://wordpress.org/?v=2.6.2 By: Wisdom http://itknowledgeexchange.techtarget.com/eye-on-oracle/oracle-patching-the-bane-of-the-dbas-existence/#comment-1241 Wisdom Fri, 08 Feb 2008 10:34:46 +0000 http://eyeonoracle.blogs.techtarget.com/2007/10/22/oracle-patching-the-bane-of-the-dbas-existence/#comment-1241 I agree, patching is a pain. However we recently moved some databases over to 10g and installed grid control. First GC was a pain, but finally getting the hang of it. Without getting blogged down in GC topics( which are plenty), the focus of this note is how GC was used in my test environment to apply the latest round of Critical patches for January. It actually worked. From the GC main page, go to target, select databases, select a database then select maintenance. Search for the patch number on metalink (you must have a valid metalink account). Down load the patch to the patch repository which if not specified will install to the Oracle Home/emsstagedpatches. You may want to specify a pre and post job to to stop and start the databases/listeners/opmn etc. I was surprised that it actually worked. After reviewing the output form the job I check the opatch inventory and wow la....it was properly updated. I think this is the roadmap for the future. My team and I are very pleased that finally...finally we may have a tool to help with the drugery of patching each quarter. Here is a link that can help with OEM Grid Control http://download-west.oracle.com/docs/cd/B16240_01/doc/em.102/b40002/deploy_proc.htm I agree, patching is a pain. However we recently moved some databases over to 10g and installed grid control. First GC was a pain, but finally getting the hang of it. Without getting blogged down in GC topics( which are plenty), the focus of this note is how GC was used in my test environment to apply the latest round of Critical patches for January.

It actually worked. From the GC main page, go to target, select databases, select a database then select maintenance.
Search for the patch number on metalink (you must have a valid metalink account).

Down load the patch to the patch repository which if not specified will install to the Oracle Home/emsstagedpatches.
You may want to specify a pre and post job to to stop and start the databases/listeners/opmn etc.

I was surprised that it actually worked.

After reviewing the output form the job I check the opatch inventory and wow la….it was properly updated.

I think this is the roadmap for the future.
My team and I are very pleased that finally…finally we may have a tool to help with the drugery of patching each quarter.

Here is a link that can help with OEM Grid Control <a href="http://download-west.oracle.com/docs/cd/B16240_01/doc/em.102/b40002/deploy_proc.htm" title="http://download-west.oracle.com/docs/cd/B16240_01/doc/em.102/b40002/deploy_proc.htm" target="_blank">http://download-west.oracle.com/docs/cd/…</a>

]]> By: robert tien http://itknowledgeexchange.techtarget.com/eye-on-oracle/oracle-patching-the-bane-of-the-dbas-existence/#comment-1240 robert tien Mon, 19 Nov 2007 17:44:29 +0000 http://eyeonoracle.blogs.techtarget.com/2007/10/22/oracle-patching-the-bane-of-the-dbas-existence/#comment-1240 Has anyone experienced in scripting Oracle CPU patches? I meant handoff approach and let it rips through the CPU patch process including pre patch and post patch steps (from backing up the current db, ORACLE_HOME directory and inventory directory to post install script like catcpu.sql to verify patch has been install successfully). Are there any risks of doing this way espcially in a production environment versus doing manually to watch every steps and correct any errors in the way. Any thoughts and feedbacks??? Thanks, Robert Has anyone experienced in scripting Oracle CPU patches? I meant handoff approach and let it rips through the CPU patch process including pre patch and post patch steps (from backing up the current db, ORACLE_HOME directory and inventory directory to post install script like catcpu.sql to verify patch has been install successfully). Are there any risks of doing this way espcially in a production environment versus doing manually to watch every steps and correct any errors in the way.

Any thoughts and feedbacks???

Thanks,

Robert

]]> By: Praveen http://itknowledgeexchange.techtarget.com/eye-on-oracle/oracle-patching-the-bane-of-the-dbas-existence/#comment-1239 Praveen Wed, 07 Nov 2007 09:56:59 +0000 http://eyeonoracle.blogs.techtarget.com/2007/10/22/oracle-patching-the-bane-of-the-dbas-existence/#comment-1239 It is with both amusement (to some extent) and a sense of relief that I went through the comments on this blog! Amusement because when Core DBAs managing only Oracle databases complain so much of patching, I really wonder what Oracle Applications DBAs like me should say!! I am left speechless! A sense of relief because it is good to know that you are not all alone in this world (you must know what I mean)! Well, bugs are a bit of a headache but also seem to be a steady revenue earner for Oracle as well as for DBAs. It is with both amusement (to some extent) and a sense of relief that I went through the comments on this blog!

Amusement because when Core DBAs managing only Oracle databases complain so much of patching, I really wonder what Oracle Applications DBAs like me should say!! I am left speechless!

A sense of relief because it is good to know that you are not all alone in this world (you must know what I mean)!

Well, bugs are a bit of a headache but also seem to be a steady revenue earner for Oracle as well as for DBAs.

]]> By: RayB http://itknowledgeexchange.techtarget.com/eye-on-oracle/oracle-patching-the-bane-of-the-dbas-existence/#comment-1238 RayB Tue, 06 Nov 2007 14:42:53 +0000 http://eyeonoracle.blogs.techtarget.com/2007/10/22/oracle-patching-the-bane-of-the-dbas-existence/#comment-1238 My problem with patching is the process. Why does OUI or Opatch require a separate, unmovable, directory for inventory. Why wasn't that inventory placed directly inside the database. There is no mobility. My problem with patching is the process.

Why does OUI or Opatch require a separate, unmovable, directory for inventory. Why wasn’t that inventory placed directly inside the database.
There is no mobility.

]]> By: John http://itknowledgeexchange.techtarget.com/eye-on-oracle/oracle-patching-the-bane-of-the-dbas-existence/#comment-1237 John Tue, 06 Nov 2007 11:40:30 +0000 http://eyeonoracle.blogs.techtarget.com/2007/10/22/oracle-patching-the-bane-of-the-dbas-existence/#comment-1237 Patching every 12 weeks is simply a pain. 24*7*365 is a fantasy with this. All it means is failure to meet uptime SLRs and that Oracle has a predictable cornucopia of faults every 3 months. Bah! Humbug! Bob Cratchit... your're fired! An early Merry Xmas to you all! Patching every 12 weeks is simply a pain. 24*7*365 is a fantasy with this. All it means is failure to meet uptime SLRs and that Oracle has a predictable cornucopia of faults every 3 months. Bah! Humbug! Bob Cratchit… your’re fired! An early Merry Xmas to you all!

]]> By: Sparkle http://itknowledgeexchange.techtarget.com/eye-on-oracle/oracle-patching-the-bane-of-the-dbas-existence/#comment-1236 Sparkle Tue, 06 Nov 2007 06:32:05 +0000 http://eyeonoracle.blogs.techtarget.com/2007/10/22/oracle-patching-the-bane-of-the-dbas-existence/#comment-1236 Grid Control is only half the answer. We used to get Oracle alerts but we were more often likely to need a patch for a bug than a standard patch set. Which brings me to the real problem at our site. Patches breaking other currently working code. Exhaustive testing for every patch is not feasible. Complete unit tests for every piece of code and function will allow faster exhaustive testing but that is still far off for my site. We have too much legacy code. We have had too many patches break other code. We use a lot of Oracle's Db functionality. Our solution has been to only patch when absolutely needed and work around bugs. Faster than rolling out and testing to dozens of databases with different apps using different functionality. It still comes down to a lack of confidence in Oracle's patches. Bummer but true. Grid Control is only half the answer. We used to get Oracle alerts but we were more often likely to need a patch for a bug than a standard patch set. Which brings me to the real problem at our site. Patches breaking other currently working code.
Exhaustive testing for every patch is not feasible. Complete unit tests for every piece of code and function will allow faster exhaustive testing but that is still far off for my site. We have too much legacy code. We have had too many patches break other code. We use a lot of Oracle’s Db functionality. Our solution has been to only patch when absolutely needed and work around bugs. Faster than rolling out and testing to dozens of databases with different apps using different functionality.
It still comes down to a lack of confidence in Oracle’s patches. Bummer but true.

]]> By: Brian Fedorko http://itknowledgeexchange.techtarget.com/eye-on-oracle/oracle-patching-the-bane-of-the-dbas-existence/#comment-1235 Brian Fedorko Thu, 25 Oct 2007 10:50:50 +0000 http://eyeonoracle.blogs.techtarget.com/2007/10/22/oracle-patching-the-bane-of-the-dbas-existence/#comment-1235 Personally, I really like the scheduled, consistent way the CPUs are made available by Oracle. It is much easier to get buy-in from above when you can detail a controlled process, planned out well into the next year. This is actually a great boon for our sysadmins, who double-up on our downtime to perform maintenance activities of their own. As for the actual implementations, we've had a lot of success on our 'vanilla' systems, requiring some basic testing & a thorough scouring of the patch notes for surprises. Streams and Advanced Rep. have never experienced any difficulties in testing or production during the application of a CPU. Of course, patching a system utilizing Data Guard is very sensitive to following an exact process as well, but it really isn't a big deal. However, RAC and HAA have had a small share of irregularities in testing - And of course, these are generally the systems you want to be the most bulletproof. It takes a bit more headwork, but we've never had a CPU that we couldn't get to work well. Personally, I really like the scheduled, consistent way the CPUs are made available by Oracle. It is much easier to get buy-in from above when you can detail a controlled process, planned out well into the next year. This is actually a great boon for our sysadmins, who double-up on our downtime to perform maintenance activities of their own.
As for the actual implementations, we’ve had a lot of success on our ‘vanilla’ systems, requiring some basic testing & a thorough scouring of the patch notes for surprises. Streams and Advanced Rep. have never experienced any difficulties in testing or production during the application of a CPU. Of course, patching a system utilizing Data Guard is very sensitive to following an exact process as well, but it really isn’t a big deal.
However, RAC and HAA have had a small share of irregularities in testing - And of course, these are generally the systems you want to be the most bulletproof. It takes a bit more headwork, but we’ve never had a CPU that we couldn’t get to work well.

]]> By: Stephen Windsor http://itknowledgeexchange.techtarget.com/eye-on-oracle/oracle-patching-the-bane-of-the-dbas-existence/#comment-1234 Stephen Windsor Wed, 24 Oct 2007 19:58:02 +0000 http://eyeonoracle.blogs.techtarget.com/2007/10/22/oracle-patching-the-bane-of-the-dbas-existence/#comment-1234 creation of a gold Oracle home sounds wonderful. however, there might be an issue here -- my databases run on Linux Red Hat SMP, and kernel patches are applied haphazardly by the systems group, which *should* not make any difference with Oracle, but then again...so the servers on which my database software reside, will always be out of sync as far as the kernel goes. however I think it's a great idea to at least have a separate software area you can patch. creation of a gold Oracle home sounds wonderful. however, there might be an issue here — my databases run on Linux Red Hat SMP, and kernel patches are applied haphazardly by the systems group, which *should* not make any difference with Oracle, but then again…so the servers on which my database software reside, will always be out of sync as far as the kernel goes. however I think it’s a great idea to at least have a separate software area you can patch.

]]> By: Bilwesh Jani http://itknowledgeexchange.techtarget.com/eye-on-oracle/oracle-patching-the-bane-of-the-dbas-existence/#comment-1233 Bilwesh Jani Tue, 23 Oct 2007 18:30:30 +0000 http://eyeonoracle.blogs.techtarget.com/2007/10/22/oracle-patching-the-bane-of-the-dbas-existence/#comment-1233 Manageability of Quarterly CPU patching is relative to the number of databases, high availability requirements, etc. in your environment, as also a need to patch development and QA environments before rolling it out to production. I would think Oracle testing their products better to ensure fewer security related bugs before they release their products would make sense from a customer standpoint. This will perhaps reduce the frequency of CPUs to half-yearly instead of quarterly. Also, ease of installing only what your environment really needs would help. This will reduce applicability of certain security patches. I like the idea of having a standard Gold copy of a release, patching it and then cloning to reduce time. But again, if your footprint is large, and you've been applying one-off patches in certain environments to fix bugs, it'll just make maintenance of that gold copy a nightmare :) ..My two cents. Bottomline, life would be much easier as a DBA if the products undergo extensive security tests and fixes before release. Manageability of Quarterly CPU patching is relative to the number of databases, high availability requirements, etc. in your environment, as also a need to patch development and QA environments before rolling it out to production. I would think Oracle testing their products better to ensure fewer security related bugs before they release their products would make sense from a customer standpoint. This will perhaps reduce the frequency of CPUs to half-yearly instead of quarterly. Also, ease of installing only what your environment really needs would help. This will reduce applicability of certain security patches. I like the idea of having a standard Gold copy of a release, patching it and then cloning to reduce time. But again, if your footprint is large, and you’ve been applying one-off patches in certain environments to fix bugs, it’ll just make maintenance of that gold copy a nightmare :) ..My two cents. Bottomline, life would be much easier as a DBA if the products undergo extensive security tests and fixes before release.

]]> By: John Palinski http://itknowledgeexchange.techtarget.com/eye-on-oracle/oracle-patching-the-bane-of-the-dbas-existence/#comment-1232 John Palinski Tue, 23 Oct 2007 13:05:29 +0000 http://eyeonoracle.blogs.techtarget.com/2007/10/22/oracle-patching-the-bane-of-the-dbas-existence/#comment-1232 Patching was a real pain until we came up with a technique for creating a Gold Oracle home and cloning this home. This technique saves a LOT of DBA time, reduces system downtime, and makes patches easy. Here is a link to an article I wrote on the subject: http://www.dba-oracle.com/t_patching_cloning_oracle_home.htm Patching was a real pain until we came up with a technique for creating a Gold Oracle home and cloning this home. This technique saves a LOT of DBA time, reduces system downtime, and makes patches easy. Here is a link to an article I wrote on the subject:
 <a href="http://www.dba-oracle.com/t_patching_cloning_oracle_home.htm" title="http://www.dba-oracle.com/t_patching_cloning_oracle_home.htm" target="_blank">http://www.dba-oracle.com/t_patching_clo…</a>

]]>