PSU for 11.1.0.7.1
Posted by John Hallas on October 29, 2009
One of the most read entries on this site is about the PSU release for 10.2.0.4 http://jhdba.wordpress.com/2009/07/28/applying-the-10-2-0-4-1-patch-set-update-psu/
On 20th October, 2009 the first PSU for 11.1.0.7 was released. This also incorporates the Oct 2009 CPU as well as a Dataguard Broker patchset bundle. Bug 7628357 – 11.1.0.7 Data Guard Recommended Patch Bundle #1.
Oracle have maintained consistency with the 10.2.0.4 PSU by retaining the misinformation in the patch instructions. I did originally think that there was no need to update opatch as there was in 10g but I was wrong. Opatch should be upgraded but the PSU does apply even if it is not upgraded.
Ensure that the latest Opatch version is installed
opatch version
Invoking OPatch 11.1.0.6.2
OPatch Version: 11.1.0.6.2
If it is not 11.1.0.6.7 or later then upgrade
cd $ORACLE_HOME
cp /shared/oracle/rdbms_patches/PSU_patches/11.1.0.7/p6880880_111000_HPUX-IA64.zip .
unzip p6880880_111000_HPUX-IA64.zip
rm p6880880_111000_HPUX-IA64.zip
opatch version
Invoking OPatch 11.1.0.6.8
OPatch Version: 11.1.0.6.8
Basic steps for a new build server are as follows
1) Install 11.1.0.6 and upgrade to 11.1.0.7
2) ensure opatch is in the path, an Oracle Home is set and the patcheset (8833297) is unzipped
3) Run the pre-check
Following the README notes I would use this command
$cd /shared/oracle/rdbms_patches/PSU_patches/11.1.0.7
$opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ./8833297
which then fails
Oracle Interim Patch Installer version 11.1.0.6.2 Copyright (c) 2007, Oracle Corporation. All rights reserved. PREREQ session Oracle Home : /app/oracle/product/11.1.0/db_1 Central Inventory : /app/oraInventory from : /var/opt/oracle/oraInst.loc OPatch version : 11.1.0.6.2 OUI version : 11.1.0.7.0 OUI location : /app/oracle/product/11.1.0/db_1/oui Log file location : /app/oracle/product/11.1.0/db_1/cfgtoollogs/opatch/opatch2009-10-28_14-16-33PM.log Invoking prereq "checkconflictagainstohwithdetail" <span style="color: #ff0000;">The location "./8833297/README.html" is not a directory or a valid patch zip file. Prereq "checkConflictAgainstOHWithDetail" not executed PrereqSession failed: Invalid patch location.</span> <span style="color: #ff0000;">OPatch failed with error code 73
Then use the corrected syntax
opatch prereq CheckConflictAgainstOHWithDetail -ph ./8833297
Invoking OPatch 11.1.0.6.2 Oracle Interim Patch Installer version 11.1.0.6.2 Copyright (c) 2007, Oracle Corporation. All rights reserved. PREREQ session Oracle Home : /app/oracle/product/11.1.0/db_1 Central Inventory : /app/oraInventory from : /var/opt/oracle/oraInst.loc OPatch version : 11.1.0.6.2 OUI version : 11.1.0.7.0 OUI location : /app/oracle/product/11.1.0/db_1/oui Log file location : /app/oracle/product/11.1.0/db_1/cfgtoollogs/opatch/opatch2009-10-28_14-16-57PM.log Invoking prereq "checkconflictagainstohwithdetail" Prereq "checkConflictAgainstOHWithDetail" passed. OPatch succeeded.
This is very quick, less than one minute
4) Now apply the PSU
$cd 8833297
$opatch apply
The patchset took 28 minutes to apply
Afterwards an opatch lsinventory command shows
Oracle Home : /app/oracle/product/11.1.0/db_1 Central Inventory : /app/oraInventory from : /var/opt/oracle/oraInst.loc OPatch version : 11.1.0.6.2 OUI version : 11.1.0.7.0 OUI location : /app/oracle/product/11.1.0/db_1/oui Log file location : /app/oracle/product/11.1.0/db_1/cfgtoollogs/opatch/opatch2009-10-28_15-55-41PM.log Lsinventory Output file location : /app/oracle/product/11.1.0/db_1/cfgtoollogs/opatch/lsinv/lsinventory2009-10-28_15-55-41PM.txt -------------------------------------------------------------------------------- Installed Top-level Products (2): Oracle Database 11g 11.1.0.6.0 Oracle Database 11g Patch Set 1 11.1.0.7.0 There are 2 products installed in this Oracle Home. Interim patches (1) : Patch 8833297 : applied on Wed Oct 28 14:54:39 GMT 2009 Created on 7 Oct 2009, 23:52:06 hrs PST8PDT Bugs fixed: 6870937, 7627743, 7652888, 7299153, 8242410, 6059178, 8563946, 6955744 7497788, 6840740, 8244217, 8702276, 6981690, 8450529, 7432556, 7719143 7523787, 8251486, 8367827, 7613481, 8341623, 7515145, 7348847, 8416414 8250643, 8284633, 8230457, 8563948, 6900214, 7044551, 7318049, 8940197 7013124, 7432514, 7393258, 7553884, 7639121, 8563944, 8860821, 7606362 7426959, 7330434, 7708340, 7352414, 6452375, 7356443, 7341598, 8213302 7196532, 7446163, 8409848, 8236851, 8342506, 7593835, 7340448, 7309458 8290478, 8391256, 7462112, 7013817, 8499600, 7411865, 7331867, 7527650 6977167, 8855565, 6501490, 6598432, 7524944, 7706138, 6941717, 8402555 7494333, 7586451, 8402551, 7499353, 8408887, 7496908, 7511040, 7719148 7311601, 7497640, 7373196, 7424804, 7452373, 7597354, 6882739, 7366290 8543737, 6851669, 7318276, 8284438, 8324760, 7420394, 7834195, 7350127 7475055, 8563942, 7122161, 8361398, 7451927, 7705669, 7676737, 8301559 8224083, 8658581, 8211920, 8462173, 7206858, 8563945, 8855553, 8402637 8257122, 8199266, 7454752, 7516536, 7345904, 8352304, 7416901, 7426336 8352309, 6812439, 7219752, 8534338, 8542307, 8413059, 7572069, 7436280 7432601, 7311909, 7506785, 7460818, 7276960, 8855559, 7013835, 7378322 8402548, 7189645, 8563947, 8306933, 7477246, 7263842, 7480809, 8855575 8433270, 7556778, 8836375, 7330611, 8339352, 7225720, 8563943, 7036453 7628387, 8419383, 6970731, 7719668, 7203349, 8402562, 7680907, 7438445 8855577, 8243648, 7630416, 6851110, 6980597, 6618461, 7357609, 8855570 8369094, 8318050, 8306934, 7434194, 8833297, 7486595, 7716219, 8362693 6599920, 7628866, 7183523, 7412296, 7135702, 7720494, 7436152, 7175513 7602341, 6679303, 8339404, 7393804, 8856696, 7650993, 6980601, 7830065 7462709, 8563941, 8226397, 7515779
Note that if you already have databases built then you need to run a catbundle script and check for invalid objects. Check the documentation for full details that but a quick summary is to run
cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL CONNECT / AS SYSDBA
SQL STARTUP
SQL @catbundle.sql psu apply
SQL QUIT
Peter Wiseman said
I just tried applying the 10.2.0.4.2 PSU for HPUX IA-64. It took 2 hours !!! The time was spent replacing object files (.o) in an archive (libserver10.a) using “ar -r” – a separate command for each file. That was 2 hours worth of 30MB/s I/O writes. And it wasn’t taking a backup of the .a file, it was the “ar” command that took the time. Then, I did the same thing on an AIX system which got past this same section in seconds. I don’t know the cause yet – i.e. system configuration or a different code path on HPUX compared to AIX.
John Hallas said
Thanks for the note Peter. On the various PSU installation I have done (all on HPUX IA64) I see the same thing a line at a time for ar but it generally takes around 40 minutes in total.
You aren’t using VMs are you. We have a few Superdomes and a lot of the development/test servers are created as VMs and we are seeing a lot of problems with really bad performance on one VM because of something happening on another VM. Of course we cannot tell that so it is all very frustrating.
PS I would be interested to hear if this is consistent on all your servers, as I say, ours all seem to take about 40 minutes, which is still a long time to watch files being copied line by line.
John
Peter Wiseman said
Thanks John. Good to know it’s not just me then. I suspect you have more disks – we’re using a single internal disk for the software so it will be maxing out at 30MB/s. The database itself is on a nice fast san. I suspect you may have more disks, hence why your installation is faster. This system isn’t VM. Our next step is to test this on another system – which is VM. I’ve raised an SR with oracle but nothing eventful.
Matthias Hoys said
Hi,
The patch set updates can indeed take a long time to install. I recently installed PSU 10.2.0.4.2 for Linux 64-bit and it took around 35 minutes in total.
Also something I noticed: after the installation the database version number has not been increased in the dba_registry view or via opatch lsinventory. But there were no errors during the psu installation so I expect this to be “normal”.
Matthias
John Hallas said
Hi Mathias,
I cannot find a 10.2.0.4 database with the PSU applied at the moment as we are converting most databases to 11g. However the 11g databases that have a PSU patch applied retain their original database verions in both opatch and dba_registry
John
Monu Koshy said
thanks for the -ph tip.