Has anyone seen a direct slowdown from applying patches from 10.2.0.4.0 to 10.2.0.4.11 on solaris 9 sparc 64, Patches 9352164 (10.2.0.4.4) and 12879929 (10.20.4.11)? Coincidence is suggesting that this one database is affected by the patch. Getting ready to trace before rolling back: (one database creates a file and another gets the file and processes it). If anyone has a good start on this let me know. Joel Patterson Database Administrator 904 727-2546 -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Martin Berger Sent: Saturday, September 01, 2012 2:40 AM To: mdinh235@xxxxxxxxx Cc: oracle-l Subject: Re: To patch or not to patch? Michaei, For any action (so also for patching) please find out the need/reason first. Is anything broken? (fix it) Is there a corporate ruleset (like "apply all security patches within x days")? Either follow it or question it n a formal base - there should be change/review prozesses for such policies. There might be other reasons, just make sure they are defined before executed. For Patching you can either create a new ORACLE_HOME for every new patset(s) you want to run (and change , or patch existing OHs. Both methods have (dis)advantages. If you have several environments make soure you have any kind of revision vontrol sytem for your patch-bundles and document which Instances are running with them - otherwise it can lead to a big mess. Just my ideas, Martin On Fri, Aug 31, 2012 at 7:36 PM, Michael Dinh <mdinh235@xxxxxxxxx> wrote: > Hello everyone, > Will anyone please share your ideas on patching process? I have worked > for company who seldom patch and then for company who patch everything. > > I am trying to find a happy medium and determine how people in the > real word like you do this. > > Thanks so much. > > -Michaei. > > > -- > //www.freelists.org/webpage/oracle-l -- //www.freelists.org/webpage/oracle-l -- //www.freelists.org/webpage/oracle-l