Tuesday, July 29, 2014

Resizing Redo Logs in a DataGuard Environment

Primary Database: DCPROC
Standby database: DRPROC

Primary Database Server: OPDB1
Standby Database Server: OPDB2

Database version: 11.2.0.2

I have my physical standby database in sync with the primary database with the logs being applied in the form of real time apply. As you might be aware, for the “Real Time Apply” implementation, we need to make sure that we have created the Standby Redo Logs on the standby database with the size same as that of the Online Redo logs. The Standby Redo Logs also needs to be created on the primary database, but this is not mandatory. The Standby Redo Logs would not be used on the Primary database until there is a switchover operation performed and the primary database starts behaving as a standby database. Here is a snippet of the size of the redo logs (Online and Standby Redo logs) on the primary and standby database

Primary Database:

[oracle@dev ~]$ sqlplus sys/oracle@DCPROC as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Sat Sep 29 16:32:37 2012
Copyright (c) 1982, 2010, Oracle. All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, DataMining
and Real Application Testing options

SQL> select status,instance_name,database_role from v$database,v$instance;

STATUS INSTANCE_NAME DATABASE_ROLE
------ ------------- --------------
OPEN   DCPROC        PRIMARY

SQL> select group#,sum(bytes/1024/1024)"Size in MB" from v$log group by group#;

GROUP#     Size in MB
-------    ----------
1          50
2          50
3          50

SQL> select group#,sum(bytes/1024/1024)"Size in MB" from v$standby_log group by group#;

GROUP#   Size in MB
-------  ----------
 6       50
 4       50
 5       50
 7       50

Standby Database:

[oracle@uat ~]$ sqlplus sys/oracle@DRPROC as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Sat Sep 29 16:47:11 2012
Copyright (c) 1982, 2010, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, DataMining
and Real Application Testing options

SQL> select status,instance_name,database_role from v$database,v$Instance;

STATUS  INSTANCE_NAME  DATABASE_ROLE
------- -------------- ----------------
MOUNTED DRPROC         PHYSICAL STANDBY

SQL> select group#, sum(bytes/1024/1024)"Size in MB" from v$loggroup by group#;

GROUP# Size in MB
------ -------------
 1     50
 2     50
 3     50

SQL> select group#,sum(bytes/1024/1024)"Size in MB" from v$standby_log group by group#;

GROUP# Size in MB
------ ----------
 4     50
 5     50
 6     50
 7     50

Check if the parameter standby_file_management is set to AUTO or MANUAL on standby database. If it is not set to MANUAL, then set it.

SQL> show parameter standby_file_management

NAME                    TYPE    VALUE
----------------------- ------- -------
standby_file_management string  AUTO

SQL>
SQL>
SQL> alter system set standby_file_management=manual;

System altered.

SQL> show parameter standby_file_management

NAME                     TYPE    VALUE
-----------------------  ------- -------
standby_file_management  string  MANUAL

On the primary database, check the status of the Online Redo Logs and resize them by dropping the INACTIVE redo logs and re-creating them with the new size.
Primary:

SQL> select group#,status from v$log;

GROUP# STATUS
------ -------------------
1      INACTIVE
2      INACTIVE
3      CURRENT

Here you can see that Online Redo Log groups 1 and 2 are INACTIVE. Hence we can drop them and re-create with the new size.

SQL> alter database drop logfile group 1;

Database altered.

SQL> alter database add logfile group 1 size 100M;

Database altered.

SQL> select group#,status from v$log;

GROUP# STATUS
------ -------
1      UNUSED
2      INACTIVE
3      CURRENT

SQL> alter database drop logfile group 2;

Database altered.

SQL> alter database add logfile group 2 size 100M;

Database altered.

SQL> select group#,status from v$log;

GROUP# STATUS
------ -------
1      UNUSED
2      UNUSED
3      CURRENT

Now that Online Redo Log Groups 1 and 2 are resized and the status of Group 3 is CURRENT, switch logfiles manually until Group 3 becomes INACTIVE

After a couple of log switches, we can check the Status of Group 3

SQL> select group#,status from v$log;

GROUP# STATUS
------ -------
1      ACTIVE
2      CURRENT
3      INACTIVE

Now that Group 3 is INACTIVE, we can drop it and re-create it with the new size.

SQL> alter database drop logfile group 3;

Database altered.

SQL> alter database add logfile group 3 size 100M;

Database altered.

Now, we have resized all the Online Redo Logs on the Primary Database from 50M to 100M.

SQL> select group#,sum(bytes/1024/1024)"size in MB" from v$log group by group#;

GROUP# size in MB
------ -------------
1      100
2      100
3      100

Moving on to the Standby Redo Logs on the Primary Database:

SQL> select group#,sum(bytes/1024/1024)"size in MB" from v$standby_log group by group#;

GROUP# size in MB
------ -------------
6      50
4      50
5      50
7      50

SQL> select group#,status from v$standby_log;

GROUP# STATUS
------ ------------
4      UNASSIGNED
5      UNASSIGNED
6      UNASSIGNED
7      UNASSIGNED

The status of the Standby Redo Logs (SRL) on the Primary database would be UNASSIGNED as they would be used only when the primary database starts behaving as a Standby (Switchover)

We can easily drop the UNASSIGNED SRLs and re-create them with the new size.

SQL> alter database drop standby logfile group 4;

Database altered.

SQL> alter database add standby logfile group 4 size 100M;

Database altered.

Repeat this for the remaining SRLs on the primary database and we can see below that all the SRL on the Primary database have been resized.

SQL> select group#,sum(bytes/1024/1024)"size in MB" from v$standby_log group by group#;

GROUP# size in MB
------ -------------
6      100
4      100
5      100
7      100

Moving on to the standby database:

Standby:

SQL> select group#,status from v$log;

GROUP# STATUS
------ -------------------
1      CURRENT
3      CLEARING
2      CLEARING

Lets try to drop Online Redo Log Group 2 as Group 1 is CURRENT status and it cannot be
dropped.

SQL> alter database drop logfile group 2;
alter database drop logfile group 2
*
ERROR at line 1:

ORA-01156: recovery or flashback in progress may need access to files
Here above, we faced ORA-01156 error, which is self-explainatory. The recovery (MRP process) on the standby database is active and it needs to be cancelled before we drop any Redo log groups.

SQL> alter database recover managed standby database cancel;

Database altered.

Since the status of Group 2 is still clearing, lets clear it manually before dropping the group.

SQL> alter database clear logfile group 2;

Database altered.

SQL> alter database drop logfile group 2;

Database altered.

SQL> alter database add logfile group 2 size 100M;

Database altered.

SQL> select group#,status from v$log;

GROUP# STATUS
------ -------------------
1      CURRENT
3      CLEARING
2      UNUSED

The same is the case with Group 3 whose status is CLEARING. We’ll clear it manually, drop it and create with the new size.

SQL> alter database clear logfile group 3;

Database altered.

SQL> alter database drop logfile group 3;

Database altered.

SQL> alter database add logfile group 3 size 100M;

Database altered.

To drop online redo log group 1 that is in status CURRENT, generate an archive on the primary database by switching logfile, and then clear the CURRENT online redo log group on the standby database, drop it and re-create it with the required size as done for groups 2 and 3 earlier.

SQL> select group#,sum(bytes/1024/1024)"size in MB" from v$log group by group#;

GROUP# size in MB
------ -------------
1      100
2      100
3      100

Resizing Standby Redo Logs on standby database:

SQL> select group#,sum(bytes/1024/1024)"size in MB" from v$standby_log group by group#;

GROUP# size in MB
------ --------------
4      50
5      50
6      50
7      50

SQL> select group#,status from v$standby_log;

GROUP# STATUS
------ -------------
4      ACTIVE
5      UNASSIGNED
6      UNASSIGNED
7      UNASSIGNED

Clear the SRL group whose status is ACTIVE as done earlier, drop the group and re-create them with the size same as that of the Online Redo Logs.

For the SRL groups whose status is UNASSIGNED, just drop the group and recreate them with the size same as that of the Online Redo Logs.

SQL> select group#,sum(bytes/1024/1024)"size in MB" from v$log group by group#;

GROUP# size in MB
------ ------------
1      100
2      100
3      100

SQL> select group#,sum(bytes/1024/1024)"size in MB" from v$standby_log group by group#;

GROUP# size in MB
------ -------------
4      100
5      100
6      100
7      100

Once all the Standby Redo Logs and Online Redo Logs have been resize on both Primary and standby database, set the STANDBY_FILE_MANAGEMENT to AUTO on the standby database and start the recovery (MRP) on standby database.

SQL> alter system set standby_file_management=auto;

System altered.

SQL> alter database recover managed standby database disconnectfrom session using current logfile;

Database altered.

SQL> select process,status,sequence# from v$managed_standby;

PROCESS STATUS         SEQUENCE#
------- -------------- -------------
ARCH    CONNECTED      0
ARCH    CLOSING        66
ARCH    CONNECTED      0
ARCH    CLOSING        63
RFS     IDLE           0
RFS     IDLE           0
MRP0    WAIT_FOR_LOG   71
RFS     IDLE           71
RFS     IDLE           0

9 rows selected.

Primary:

SQL> select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)
--------------
70

Standby:

SQL> select max(sequence#) from v$archived_log where applied='YES';

MAX(SEQUENCE#)
--------------
70

PSU Patch in DataGuard Environment

Here is a brief explanation on how to apply PSU (Patch Set Update) in a dataguard environment

In this demo, I am applying PSU 11.2.0.2.4 on the Primary and standby databases.

Primary database Server : OPDB1
Standby database Server : OPDB2
Primary database : DCPROC
Standby database : DRPROC

Primary Server: DCPROC

[oracle@dev ~]$ sqlplus sys/oracle@DCPROC as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Tue Sep 18 10:43:50 2012

Copyright (c) 1982, 2010, Oracle. All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, DataMining and Real Application Testing options

SQL> select status,instance_name,database_role from v$database,v$instance;

STATUS INSTANCE_NAME DATABASE_ROLE
------ ------------- ---------------
OPEN   DCPROC        PRIMARY

SQL> select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)
--------------
10

Standby Server: DRPROC

[oracle@uat ~]$ sqlplus sys/oracle@DRPROC as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Tue Sep 18 10:46:35 2012

Copyright (c) 1982, 2010, Oracle. All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, DataMining and Real Application Testing options

SQL> select status,instance_name,database_role from v$database,v$instance;

STATUS   INSTANCE_NAME  DATABASE_ROLE
-------- -------------- ----------------------
MOUNTED  DRPROC         PHYSICAL STANDBY

SQL> select max(sequence#) from v$archived_log where applied='YES';

MAX(SEQUENCE#)
--------------
10

Step 1:

Disable the log shipping from primary database to the standby database by setting the log_archive_dest_state_2 to “defer” on the primary database. Here log_archive_dest_state_2 is deferred because parameter log_archive_dest_2 is set on my primary database to point to the Standby Database.

SQL> alter system set log_archive_dest_state_2=defer;

System altered.

Step 2:

On the standby database cancel the Managed Recovery Process.

SQL> alter database recover managed standby database cancel;

Database altered.

Step 3:

PSU (Patch Set Update)/CPU (Critical Patch Update)/ Patch Set patches  always needs to be applied first on the standby database and then on the primary database. In order to apply it on the standby database, shutdown the standby database and also the listener running on the standby server.

SQL> shutdown immediate
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.

[oracle@uat ~]$ lsnrctl stop

[oracle@uat ~]$ ps -ef | grep tns
oracle 6958 5107 0 10:52 pts/1 00:00:00 grep tns
[oracle@uat ~]$
[oracle@uat ~]$ ps -ef | grep pmon
oracle 4788 1 0 09:56 ? 00:00:00 asm_pmon_+ASM
oracle 6960 5107 0 10:52 pts/1 00:00:00 grep pmon

Step 4:

Now apply the PSU on the standby database.

[oracle@uat ~]$ export PATH=$PATH:/u01/app/oracle/product/11.2.0.2/db_1/OPatch
[oracle@uat ~]$ opatch version

OPatch Version: 11.2.0.3.0

OPatch succeeded.

[oracle@uat ~]$ opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /opt/12827726
Oracle Interim Patch Installer version 11.2.0.3.0
Copyright (c) 2012, Oracle Corporation. All rights reserved.

PREREQ session

Oracle Home : /u01/app/oracle/product/11.2.0.2/db_1
Central Inventory : /u01/home/oraInventory
from : /u01/app/oracle/product/11.2.0.2/db_1/oraInst.loc
OPatch version : 11.2.0.3.0
OUI version : 11.2.0.2.0
Log file location : /u01/app/oracle/product/11.2.0.2/db_1/cfgtoollogs/opatch/opatch2012-09-18_11-11-40AM_1.log

Invoking prereq "checkconflictagainstohwithdetail"

Prereq "checkConflictAgainstOHWithDetail" passed.

OPatch succeeded.

[oracle@uat ~]$ opatch apply /opt/12827726/
Oracle Interim Patch Installer version 11.2.0.3.0
Copyright (c) 2012, Oracle Corporation. All rights reserved.

Oracle Home : /u01/app/oracle/product/11.2.0.2/db_1
Central Inventory : /u01/home/oraInventory
from : /u01/app/oracle/product/11.2.0.2/db_1/oraInst.loc
OPatch version : 11.2.0.3.0
OUI version : 11.2.0.2.0
Log file location : /u01/app/oracle/product/11.2.0.2/db_1/cfgtoollogs/opatch/12827726_Sep_18_2012_11_12_36/apply2012-09-18_11-12-35AM_1.log

Applying interim patch '12827726' to OH '/u01/app/oracle/product/11.2.0.2/db_1'
Verifying environment and performing prerequisite checks...
All checks passed.
Provide your email address to be informed of security issues, install and initiate Oracle Configuration Manager. Easier for you if you use your My Oracle Support Email address/User Name.
Visit http://www.oracle.com/support/policies.html for details.
Email address/User Name:

You have not provided an email address for notification of security issues.

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/app/oracle/product/11.2.0.2/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.2.0...

Patching component oracle.rdbms, 11.2.0.2.0...

Patching component oracle.sysman.console.db, 11.2.0.2.0...

Patching component oracle.sysman.oms.core, 10.2.0.4.3...

Patching component oracle.ldap.rsf, 11.2.0.2.0...

Patching component oracle.rdbms.dv, 11.2.0.2.0...

Patching component oracle.rdbms.dbscripts, 11.2.0.2.0...

Patching component oracle.sysman.plugin.db.main.repository, 11.2.0.2.0...

Patching component oracle.rdbms.rman, 11.2.0.2.0...

Patching component oracle.sdo.locator, 11.2.0.2.0...

Verifying the update...
Patch 12827726 successfully applied
Log file location: /u01/app/oracle/product/11.2.0.2/db_1/cfgtoollogs/opatch/12827726_Sep_18_2012_11_12_36/apply2012-09-18_11-12-35AM_1.log

OPatch succeeded.

Step 5:

Once the patch has been applied on the standby database, start the listener and the standby database.

[oracle@uat ~]$ lsnrctl start

[oracle@uat ~]$ sqlplus sys/oracle@DRPROC as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Tue Sep 18 11:40:02 2012

Copyright (c) 1982, 2010, Oracle. All rights reserved.

Connected to an idle instance.

SQL> startup mount
ORACLE instance started.

Total System Global Area 684785664 bytes
Fixed Size 2229640 bytes
Variable Size 197134968 bytes
Database Buffers 482344960 bytes
Redo Buffers 3076096 bytes
Database mounted.

Note: Do not run any patching scripts on the standby database (Example: catbundle.sql). We are done with the patching on the standby database. Now lets move to the primary database.

Step 6:

Shutdown the Primary database and stop the listener running on the primary database server.

[oracle@dev ~]$ sqlplus sys/oracle@DCPROC as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Tue Sep 18 11:48:26 2012

Copyright (c) 1982, 2010, Oracle. All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, DataMining and Real Application Testing options

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, DataMining and Real Application Testing options

[oracle@dev ~]$ lsnrctl stop

[oracle@dev ~]$ ps -ef | grep pmon
oracle 4618 1 0 09:53 ? 00:00:00 asm_pmon_+ASM
oracle 10233 4998 0 11:50 pts/1 00:00:00 grep pmon
[oracle@dev ~]$
[oracle@dev ~]$ ps -ef | grep tns
oracle 10237 4998 0 11:50 pts/1 00:00:00 grep tns

Step 7:

Now apply the PSU patch on the Primary database.

[oracle@dev ~]$ export PATH=$PATH:/u01/app/oracle/product/11.2.0.2/db1/OPatch
[oracle@dev ~]$ opatch version

OPatch Version: 11.2.0.3.0

OPatch succeeded.

[oracle@dev ~]$ opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /opt/12827726/
Oracle Interim Patch Installer version 11.2.0.3.0
Copyright (c) 2012, Oracle Corporation. All rights reserved.

PREREQ session

Oracle Home : /u01/app/oracle/product/11.2.0.2/db1
Central Inventory : /u01/home/oraInventory
from : /u01/app/oracle/product/11.2.0.2/db1/oraInst.loc
OPatch version : 11.2.0.3.0
OUI version : 11.2.0.2.0
Log file location : /u01/app/oracle/product/11.2.0.2/db1/cfgtoollogs/opatch/opatch2012-09-18_11-56-11AM_1.log

Invoking prereq "checkconflictagainstohwithdetail"

Prereq "checkConflictAgainstOHWithDetail" passed.

OPatch succeeded.

[oracle@dev ~]$ export PATH=$PATH:/u01/app/oracle/product/11.2.0.2/db1/OPatch
[oracle@dev ~]$ opatch apply /opt/12827726/
Oracle Interim Patch Installer version 11.2.0.3.0
Copyright (c) 2012, Oracle Corporation. All rights reserved.

Oracle Home : /u01/app/oracle/product/11.2.0.2/db1
Central Inventory : /u01/home/oraInventory
from : /u01/app/oracle/product/11.2.0.2/db1/oraInst.loc
OPatch version : 11.2.0.3.0
OUI version : 11.2.0.2.0
Log file location : /u01/app/oracle/product/11.2.0.2/db1/cfgtoollogs/opatch/12827726_Sep_18_2012_12_17_40/apply2012-09-18_12-17-39PM_1.log

Applying interim patch '12827726' to OH '/u01/app/oracle/product/11.2.0.2/db1'
Verifying environment and performing prerequisite checks...
All checks passed.
Provide your email address to be informed of security issues, install and initiate Oracle Configuration Manager. Easier for you if you use your My Oracle Support Email address/User Name.
Visit http://www.oracle.com/support/policies.html for details.
Email address/User Name:

You have not provided an email address for notification of security issues.
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/app/oracle/product/11.2.0.2/db1')

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.2.0...

Patching component oracle.rdbms, 11.2.0.2.0...

Patching component oracle.sysman.console.db, 11.2.0.2.0...

Patching component oracle.sysman.oms.core, 10.2.0.4.3...

Patching component oracle.ldap.rsf, 11.2.0.2.0...

Patching component oracle.rdbms.dv, 11.2.0.2.0...

Patching component oracle.rdbms.dbscripts, 11.2.0.2.0...

Patching component oracle.sysman.plugin.db.main.repository, 11.2.0.2.0...

Patching component oracle.rdbms.rman, 11.2.0.2.0...

Patching component oracle.sdo.locator, 11.2.0.2.0...

Verifying the update...
Patch 12827726 successfully applied
Log file location: /u01/app/oracle/product/11.2.0.2/db1/cfgtoollogs/opatch/12827726_Sep_18_2012_12_17_40/apply2012-09-18_12-17-39PM_1.log

OPatch succeeded.

Step 8:

Start the listener on the primary database server and also start the Primary database.

[oracle@dev ~]$ lsnrctl start

[oracle@dev ~]$ sqlplus sys/oracle@DCPROC as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Tue Sep 18 12:28:35 2012

Copyright (c) 1982, 2010, Oracle. All rights reserved.

Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area 684785664 bytes
Fixed Size 2229640 bytes
Variable Size 222300792 bytes
Database Buffers 457179136 bytes
Redo Buffers 3076096 bytes
Database mounted.
Database opened.
SQL>

Step 9:

Now enable log shipping on the primary database by setting the log_archive_dest_state_2 to “enable”. As I said earlier, parameter log_archive_dest_2 on my primary database is set to point to the standby database.

SQL> alter system set log_archive_dest_state_2=enable;

System altered.

Step 10:

Start the Managed Recovery Process (MRP) on the standby database.

[oracle@uat ~]$ sqlplus sys/oracle@DRPROC as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Tue Sep 18 12:33:03 2012

Copyright (c) 1982, 2010, Oracle. All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, DataMining and Real Application Testing options

SQL> alter database recover managed standby database disconnect;

Database altered.

SQL> select process,status,sequence# from v$managed_standby;

PROCESS STATUS        SEQUENCE#
------- ------------- -----------
ARCH    CONNECTED     0
ARCH    CONNECTED     0
ARCH    CONNECTED     0
ARCH    CONNECTED     0
RFS     IDLE          0
RFS     IDLE          13
RFS     IDLE          0
RFS     IDLE          0
MRP0    WAIT_FOR_LOG  13

9 rows selected.

Step 11:

On the primary database, run the patching scripts like “catbundle.sql” in this case.
The script run generates archives and these archives would be shipped and applied to the standby database. So, there is no requriement to run the patching scripts on the standby database.

[oracle@dev ~]$ sqlplus sys/oracle@DCPROC as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Tue Sep 18 12:31:52 2012

Copyright (c) 1982, 2010, Oracle. All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, DataMining and Real Application Testing options

SQL> @?/rdbms/admin/catbundle.sql psu apply

SQL> select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)
--------------
14

Step 12:

Check if the PSU applied shows up in the primary database by querying the registry$history or dba_registry_history view.

SQL> select * from registry$history order by action_time desc;

ACTION_TIME ACTION NAMESPACE VERSION ID COMMENTS BUNDLE_SER
------------------------------ ---------- ---------- --------------- ---------- ------------------------- ----------
18-SEP-12 12.32.44.728562 PM APPLY SERVER  11.2.0.2 4 PSU 11.2.0.2.4 PSU
Step 13:

Make sure that the latest archive applied on the standby database is the latest archive generated on the primary database. You can see below that the latest archive sequence applied on the standby database is sequence 14 and the latest sequence generated on the primary database too is 14. Now, check if the PSU applied shows up in the standby database by querying the registry$history or dba_registry_history view.

[oracle@uat ~]$ sqlplus sys/oracle@DRPROC as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Tue Sep 18 12:44:25 2012

Copyright (c) 1982, 2010, Oracle. All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, DataMining and Real Application Testing options

SQL> select max(sequence#) from v$archived_log where applied='YES';

MAX(SEQUENCE#)
--------------
14

SQL> select * from registry$history order by action_time desc;

ACTION_TIME ACTION NAMESPACE VERSION ID COMMENTS BUNDLE_SER
----------- ------ --------- ---------- ---------- ------------------------- ----------
18-SEP-12 12.32.44.728562 PM APPLY SERVER 11.2.0.2 4 PSU 11.2.0.2.4 PSU

We can see that the PSU is applied successfully on both Primary and standby databases.