Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

Time for action – applying PSU on a physical standby database

Disable log transport and stop MRP in the standby database. Before disabling log transport in standby, cross-check the synchronization between the primary and standby database, as shown in the following screenshot:
Now cancel MRP using the broker; you can perform this step from any site as shown in the following screenshot:
Stop the database services of the primary and standby and perform a backup of ORACLE_HOME. Prior to shutting down all the services, gather the invalid objects of each schema to check the invalid objects after the patch has been applied using the following script:
```
SQL> select owner,object_name,object_type,status from dba_objects  where status <> 'VALID' and OWNER !='PUBLIC' and OBJECT_TYPE!='SYNONYM';
```

Ensure that there is a latest and valid Cold/RMAN backup available prior to applying the patch. Also ensure that all the applications are down. You can check for active sessions from v$session as follows:

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> 
[oracle@oracle-primary ~]$ lsnrctl stop
LSNRCTL for Linux: Version 11.2.0.1.0 - Production on 15-DEC-2012 22:52:16
Copyright (c) 1991, 2009, Oracle.  All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1521)))
The command completed successfully

If no Oracle-related services are running, perform a backup of ORACLE_HOME and of the inventory using the tar command as follows:

[oracle@oracle-primary backup]$ tar -zcpvf  /home/oracle/backup/11.2.0_Home_Inventory_Backup_$(date +%Y%m%d).tar.gz /u01/home/oracle/product/11.2.0/db_1 /u01/app/oraInventory
/u01/home/oracle/product/11.2.0/db_1/
/u01/home/oracle/product/11.2.0/db_1/uix/
............................
/u01/app/oraInventory/ContentsXML/inventory.xml
/u01/app/oraInventory/ContentsXML/comps.xml
/u01/app/oraInventory/ContentsXML/libs.xml
[oracle@oracle-primary backup]$

Tip

You can use the tar ball in case there are any libraries that are corrupted and you are unable to access the Oracle home after applying a patch. The Tar command is applicable for UNIX systems. For Windows, the zip option can be used to compress.

Apply a patch on both primary and standby. We apply the PSU July 2012 (12419378) Patch in the Data Guard environment of both primary and physical standby databases. After applying the patch, the PSU version will be (11.2.0.1.6). Now perform the prerequisite check for any conflicts; if any conflicts are found, you have to get the merge patch on top of 11.2.0.1.6 as follows:

[oracle@oracle-primary 12419378]$ opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir  /home/oracle/patches/12419378
Oracle Interim Patch Installer version 11.2.0.3.0
.......................
Invoking prereq "checkconflictagainstohwithdetail"
ZOP-40: The patch(es) has conflicts with other patches installed in the Oracle Home (or) among themselves.
Prereq "checkConflictAgainstOHWithDetail" failed.
Summary of Conflict Analysis:
There are no patches that can be applied now.
Following patches have conflicts. Please contact Oracle Support and get the merged patch of the patches :
9711859, 12419378
Following patches will be rolled back from Oracle Home on application of the patches in the given list :
9711859
Conflicts/Supersets for each patch are:
Patch : 12419378
        Conflict with 9711859
        Conflict details:
/u01/home/oracle/product/11.2.0/db_1/lib/libserver11.a:/ktsx.o
OPatch succeeded.
[oracle@oracle-primary 12419378]$

The prerequisite applied failed because of Patch 9711859: ORA-600 [KTSPTRN_FIX-EXTMAP] DURING EXTENT ALLOCATION that was applied in the previous scenario. To resolve this conflict we have to request the merge patch to be applied. Now the action plan is shown as follows:
- Rollback the 9711859 Patch
- Apply PSU July 2012 12419378
- Apply Merge Patch 9711859 of 11.2.0.1.6
The following screenshot illustrates the action plan as discussed:

A rollback is applied on 9711859 of 11.2.0.1.0 using the OPatch utility as follows:

[oracle@oracle-primary patches]$ opatch rollback -id 9711859                         Oracle Interim Patch Installer version 11.2.0.3.0
Copyright (c) 2012, Oracle Corporation.  All rights reserved.
...........
RollbackSession rolling back interim patch '9711859' from OH '/u01/home/oracle/product/11.2.0/db_1'
Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = '/u01/home/oracle/product/11.2.0/db_1')
Is the local system ready for patching? [y|n]
y
User Responded with: Y
Patching component oracle.rdbms, 11.2.0.1.0...
RollbackSession removing interim patch '9711859' from inventory
Log file location: /u01/home/oracle/product/11.2.0/db_1/cfgtoollogs/opatch/9711859_Dec_16_2012_12_12_51/rollback2012-12-16_12-12-49PM_1.log
OPatch succeeded.
[oracle@oracle-primary patches]$

Now apply PSU July 2012 Patch 12419378 as follows:

[oracle@oracle-primary 12419378]$ pwd
/home/oracle/patches/12419378
[oracle@oracle-primary 12419378]$ ls
custom  etc  files  patchmd.xml  README.html  README.txt
[oracle@oracle-primary 12419378]$ opatch apply
Oracle Interim Patch Installer version 11.2.0.3.0
Copyright (c) 2012, Oracle Corporation.  All rights reserved.
Oracle Home       : /u01/home/oracle/product/11.2.0/db_1
...........
Patch 12419378: Optional component(s) missing : [ oracle.client, 11.2.0.1.0 ]
All checks passed.
....................
Do you wish to remain uninformed of security issues ([Y]es, [N]o) [N]:  Y
Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = '/u01/home/oracle/product/11.2.0/db_1')

Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files...
Patching component oracle.rdbms.rsf, 11.2.0.1.0...
..............
Verifying the update...
Patch 12419378 successfully applied
OPatch Session completed with warnings.
Log file location: /u01/home/oracle/product/11.2.0/db_1/cfgtoollogs/opatch/12419378_Dec_16_2012_12_18_09/apply2012-12-16_12-18-09PM_1.log
OPatch completed with warnings.
[oracle@oracle-stby 12419378]$
 [Dec 16, 2012 12:21:46 PM]   UtilSession: Backup area for restore has been cleaned up. For a complete list of files/directories
                             deleted, Please refer log file.
[Dec 16, 2012 12:21:46 PM]   Patch 12419378 successfully applied

Now apply Merge Patch 9711859 of 11.2.0.1.6 as follows:

[oracle@oracle-primary 9711859]$ ls
etc  files  README.txt
[oracle@oracle-primary 9711859]$ 
opatch apply
Oracle Interim Patch Installer version 11.2.0.3.0
Copyright (c) 2012, Oracle Corporation.  All rights reserved.
Oracle Home       : /u01/home/oracle/product/11.2.0/db_1
Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = '/u01/home/oracle/product/11.2.0/db_1')
Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files...
Patching component oracle.rdbms, 11.2.0.1.0...
Verifying the update...
Patch 9711859 successfully applied
Log file location: /u01/home/oracle/product/11.2.0/db_1/cfgtoollogs/opatch/9711859_Dec_16_2012_12_37_13/apply2012-12-16_12-37-13PM_1.log
OPatch succeeded.
[oracle@oracle-primary 9711859]$

The previous steps must be performed on both primary and standby databases and on all the instances if it is RAC.

Start the primary and standby databases and execute the post scripts of Catbundle.sql in the primary database. Start both primary and standby (in the Mount status if no Active Data Guard is enabled) databases including listener services. In the primary database run the Catbundle.sql script that is located at $ORACLE_HOME/rdbms/admin, which determines the last bundle in the series that was loaded in the database by the information stored in the dba_registry_history view. It processes the information in bundle_<bundle_series>.xml, which is present in each bundle patch. The following script can be used:

SQL> @?/rdbms/admin/catbundle.sql psu apply
PL/SQL procedure successfully completed.
PL/SQL procedure successfully completed.
.................
Generating apply and rollback scripts...
Check the following file for errors:
/u01/home/oracle/product/11.2.0/db_1/cfgtoollogs/catbundle/catbundle_PSU_ORCL_GENERATE_2012Dec16_12_58_39.log
  6    (SYSTIMESTAMP, 'APPLY',
  7     SYS_CONTEXT('REGISTRY$CTX','NAMESPACE'),
  8     '11.2.0.1',
  9     6,
 10     'PSU',
 11     'PSU 11.2.0.1.6'),
1 row created.
SQL> COMMIT;
Commit complete.
SQL> SPOOL off
SQL> SET echo off
Check the following log file for errors:
/u01/home/oracle/product/11.2.0/db_1/cfgtoollogs/catbundle/catbundle_PSU_ORCL_APPLY_2012Dec16_12_58_51.log
SQL>

For any errors related to post scripts you can refer to the following logs:
```
[oracle@oracle-primary catbundle]$ pwd
/u01/home/oracle/product/11.2.0/db_1/cfgtoollogs/catbundle
[oracle@oracle-primary catbundle]$ ls
catbundle_PSU_ORCL_APPLY_2012Dec16_12_58_51.log
catbundle_PSU_ORCL_GENERATE_2012Dec16_12_58_39.log
[oracle@oracle-primary catbundle]$
```
Tip
If in case you want to rollback the patch applied with the bundle script, use the following script:
$opatch rollback -id 12419378
Start every instance dependent to ORACLE_HOME that has been patched and execute as follows:
sql> @$ORACLE_HOME/rdbms/admin/catbundle_PSU_<database SID>_ROLLBACK.sql

Verify the patch status from OPatch and the database registry. Once we have applied the patch on the binaries using OPatch, we can verify the patch with an ID from the OS level as follows:

[oracle@oracle-primary ~]$ opatch lsinventory -bugs_fixed | grep -i 'DATABASE PSU'
9352237    12419378  Sun Dec 16 12:21:15 IST 2012   DATABASE PSU 11.2.0.1.1
9654983    12419378  Sun Dec 16 12:21:15 IST 2012   DATABASE PSU 11.2.0.1.2 (INCLUDES CPUJUL2010)
9952216    12419378  Sun Dec 16 12:21:15 IST 2012   DATABASE PSU 11.2.0.1.3 (INCLUDES CPUOCT2010)
10248516   12419378  Sun Dec 16 12:21:15 IST 2012   database psu 11.2.0.1.4 (includes cpujan2011)
11724930   12419378  Sun Dec 16 12:21:15 IST 2012   database psu 11.2.0.1.5 (includes cpuapr2011)
12419378   12419378  Sun Dec 16 12:21:15 IST 2012   DATABASE PSU 11.2.0.1.6 (INCLUDES CPUJUL2011)
[oracle@oracle-primary ~]$

We can check the database registry using registry$history. This script can be executed from the standby database even in the OPEN status if the archives have been applied after running the catbundle.sql script as follows:

SQL> select namespace,version,id, comments from registry$history;
NAMESPACE       VERSION             ID COMMENTS
--------------- ---------- ----------- ---------------
SERVER          11.2.0.1             6 PSU 11.2.0.1.6

Enable redo transport in the primary, start MRP in the standby database, and verify the synchronization. After verifying the latest patch level from the primary, we can now enable the redo transport in the primary database using the Data Guard broker, as shown in the following screenshot:
To start redo apply services in the standby, you can give the following commands either in the primary or standby database using the Data Guard broker, as shown in the following screenshot:
When the MRP service starts on the standby and broker configuration, the status is SUCCESS. Now check the archives that are generated in the primary and applied in the standby using v$archived_log with the column sequence#, as shown in the following screenshot:
In both the databases, the valid destination archived sequences are matching. Hence, the standby is in sync with the primary database.

Pop quiz

Q1. What is a terminal patch?

What just happened?

We have seen how to apply PSU Patch (11.2.0.1.6) in a Data Guard environment of a physical standby database using a Data Guard broker.

How to apply patch set on physical standby (11.2.0.1 to 11.2.0.3)?

To upgrade a database of a patch set from 11.2.0.1 to 11.2.0.3, we have to perform a complete installation of ORACLE_HOME for 11.2.0.3, and then we have to detach the old home. This procedure is called out-of-place upgrade and is introduced from 11gR2 onwards. In 10gRx versions, we definitely have to do in-place upgrade on the same home. Even if your requirement is to create a new database of 11.2.0.3, there is no need to install 11.2.0.1 anymore.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.

Table of Contents for Time for action – applying PSU on a physical standby database

Create new playlist

Sign In

Sign Up

Time for action – applying PSU on a physical standby database

Tip

Tip

Pop quiz

What just happened?

How to apply patch set on physical standby (11.2.0.1 to 11.2.0.3)?

Table of Contents for
Time for action – applying PSU on a physical standby database