In this article we will present how to apply and reverse a PSU
applied to Database Home on a node with the conflict resolution
method. To do this you need to have at least a 2-node RAC Database.
If you want to patch on Grid Infrastructure Home in Oracle 12c
Our test environment:
We need to initially download the desired PSU and My Oracle Support compatible OPatch utility (support.oracle.com).
Our scenario:
After unpacking the new OPatch utility, check the version.
There are 3 main steps to applying the PSU:
Now you need to unzip the PSU and make sure that the directory where you are unpacking is accessible to DBOwner and there is enough space in / tmp.
Conflict Detection and Resolution
This step must be performed before the PSU is applied in any environment.
The easiest and quickest way to determine if you have a patch already applied that will conflict with another patch that will still be applied is through the One-off Patch ConflictDetectionandResolution method.
If no conflict is found you can apply the patch, otherwise you need to resolve the conflicts.
Execute:
Output Example:
Applying the Patch in the Database Home
The OPatch utility automates the patch application for Oracle Grid Infrastructure Home and Oracle RAC Database Home. It operates by consulting the existing configuration and automating the steps required to patch both DB Home and GI Home.
The utility must be run by an Operating System user with root privileges and must still be run on each cluster node for GI Home or RAC DB Home if the latter is not on shared filesystem. The utility should not run in parallel on other nodes in the cluster.
Run:
Output Example:
After applying the PSU to the DB Home you can consult the list of patchsets applied using OPatch’s “lsinvetory”.
Run:
Output example:
Removing the Database Home Patch
At this point we apply the PSU in the Database Home on only one cluster node. After verifying the performance we identified some problems in our environment and decided to reverse the PSU that was applied.
The patch rollback instructions will be different for GI and DB Home. The steps required for rollback in DB Home are listed below.
Run:
Note:The opatchauto utility must be run as root.
Output Example:
Thanks for reading and hope you find this article useful. We invite you to continue following up on Oracle RAC publications.
If you want to patch on Grid Infrastructure Home in Oracle 12c
Our test environment:
- Grid Infrastructure Home is 12.1.0.2.0
- Oracle Home is 12.1.0.2
- 2 Node RAC
We need to initially download the desired PSU and My Oracle Support compatible OPatch utility (support.oracle.com).
- Doc ID 1454618.1 -> Quick References to Patch Numbers for Database / GI PSU, SPU (CPU), Bundle Patches and Patchsets.
- Doc ID 274526.1 -> How To Download And Install The Latest OPatch (6880880) Version.
Our scenario:
- P24412235 -> Oct 2016 PSU for DB
- P6880880 -> latestOPatchUtility
- Find the DB Home;
- Back up the old OPatch utility;
- Unzip the new OPatch.
After unpacking the new OPatch utility, check the version.
There are 3 main steps to applying the PSU:
- Detect and resolve conflicts.
- Apply Patch to DB Home.
- Uninstall Patch if necessary.
Now you need to unzip the PSU and make sure that the directory where you are unpacking is accessible to DBOwner and there is enough space in / tmp.
Conflict Detection and Resolution
This step must be performed before the PSU is applied in any environment.
The easiest and quickest way to determine if you have a patch already applied that will conflict with another patch that will still be applied is through the One-off Patch ConflictDetectionandResolution method.
If no conflict is found you can apply the patch, otherwise you need to resolve the conflicts.
Execute:
Applying the Patch in the Database Home
The OPatch utility automates the patch application for Oracle Grid Infrastructure Home and Oracle RAC Database Home. It operates by consulting the existing configuration and automating the steps required to patch both DB Home and GI Home.
The utility must be run by an Operating System user with root privileges and must still be run on each cluster node for GI Home or RAC DB Home if the latter is not on shared filesystem. The utility should not run in parallel on other nodes in the cluster.
Run:
After applying the PSU to the DB Home you can consult the list of patchsets applied using OPatch’s “lsinvetory”.
Run:
Removing the Database Home Patch
At this point we apply the PSU in the Database Home on only one cluster node. After verifying the performance we identified some problems in our environment and decided to reverse the PSU that was applied.
The patch rollback instructions will be different for GI and DB Home. The steps required for rollback in DB Home are listed below.
Run:
Output Example:
Thanks for reading and hope you find this article useful. We invite you to continue following up on Oracle RAC publications.
How to roll back (Revert) Oracle 12c database patch (PSU) – (de-install PSU)
Sometimes you need to roll back the applied Oracle database PSU
(Patch Set Update) for whatever the reason is. So you need to know how
to de-install the patch applied in quick and swift way especially if you are doing it in production environment.
On the other hand, a DBA shouldn’t resort to this unless there is a big impact on production applications since in a controlled IT change environments patches are usually applied first in test, QA, and then production and tested during these stages.
Also, another important information to mention is that Oracle is now releasing 2 patches ( 1 database, and 1 for JAVA component) every quarter. And the Java Component patch sometimes could lead to application problems with specific vendors so you need to be careful.
The following is general overview procedure in how to roll back a database patch (either for database or Java component), in my example I am referring to JULY 2015 Oracle release quarterly security patch. It’s very important that you read the (readme.html) accompanied with the patches downloaded.
1.de-installing the database patch:
sqlplus ‘/as sysdba’
SQL> shutdown immediate
**** Then run the Opatch utility to roll back the applied patch:
cd /app/oracle/downloaded_patch/july2015/20831110
opatch rollback -id 20831110
You should receive message similar “OPatch completed successfully”
If you have warning then you can check the logs in the directory specified in the output.
startup
cd $ORACLE_HOME/OPatch
./datapatch –verbose
*** To verify that the patch is rolled back successfully:
select * from dba_registry_sqlpatch where PATCH_ID=20831110;
Important Remark:
My recommendation is to use utilrip after that to re-compile all database objects:
@$ORACLE_HOME/rdbms/admin/utlrp.sql
Also checking that all database components are vaild post de-instillation:
Select * from dba_registry;
lsnrctl start LISTENER_TESTDB
********************************************************************
2.de-installing the Java patch:
SQL> shutdown immediate
*** Then run the Opatch utility to roll back the applied patch:
cd /app/oracle/downloaded_patch/july2015/JAVA/21068507
opatch rollback -id 21068507
SQL> startup upgrade ;
SQL>exit
cd $ORACLE_HOME/OPatch
./datapatch –verbose
You will receive a message similar to this:
Patch 21068507 rollback: SUCCESS
SQL> shutdown immediate;
SQL> startup
Don’t forget to startup the listener:
lsnrctl start LISTENER_TESTDB
*** To verify that the patch is rolled back successfully:
select * from dba_registry_sqlpatch where PATCH_ID=21068507;
Important Remark:
My recommendation is to use utilrip after that re-compile all database objects:
@$ORACLE_HOME/rdbms/admin/utlrp.sql
Also checking that all database components are valid post de-instillation:
Select * from dba_registry;
I hope this would help…..
On the other hand, a DBA shouldn’t resort to this unless there is a big impact on production applications since in a controlled IT change environments patches are usually applied first in test, QA, and then production and tested during these stages.
Also, another important information to mention is that Oracle is now releasing 2 patches ( 1 database, and 1 for JAVA component) every quarter. And the Java Component patch sometimes could lead to application problems with specific vendors so you need to be careful.
The following is general overview procedure in how to roll back a database patch (either for database or Java component), in my example I am referring to JULY 2015 Oracle release quarterly security patch. It’s very important that you read the (readme.html) accompanied with the patches downloaded.
1.de-installing the database patch:
- Shtudwon the database and the listener of your database using the commands:
sqlplus ‘/as sysdba’
SQL> shutdown immediate
**** Then run the Opatch utility to roll back the applied patch:
cd /app/oracle/downloaded_patch/july2015/20831110
opatch rollback -id 20831110
You should receive message similar “OPatch completed successfully”
If you have warning then you can check the logs in the directory specified in the output.
- Now the Post De-instillation will take place:
startup
cd $ORACLE_HOME/OPatch
./datapatch –verbose
*** To verify that the patch is rolled back successfully:
select * from dba_registry_sqlpatch where PATCH_ID=20831110;
Important Remark:
My recommendation is to use utilrip after that to re-compile all database objects:
@$ORACLE_HOME/rdbms/admin/utlrp.sql
Also checking that all database components are vaild post de-instillation:
Select * from dba_registry;
lsnrctl start LISTENER_TESTDB
********************************************************************
2.de-installing the Java patch:
- Shtudwon the database and the listener of your database using the commands:
SQL> shutdown immediate
*** Then run the Opatch utility to roll back the applied patch:
cd /app/oracle/downloaded_patch/july2015/JAVA/21068507
opatch rollback -id 21068507
- Now the Post De-instillation will take place:
SQL> startup upgrade ;
SQL>exit
cd $ORACLE_HOME/OPatch
./datapatch –verbose
You will receive a message similar to this:
Patch 21068507 rollback: SUCCESS
SQL> shutdown immediate;
SQL> startup
Don’t forget to startup the listener:
lsnrctl start LISTENER_TESTDB
*** To verify that the patch is rolled back successfully:
select * from dba_registry_sqlpatch where PATCH_ID=21068507;
Important Remark:
My recommendation is to use utilrip after that re-compile all database objects:
@$ORACLE_HOME/rdbms/admin/utlrp.sql
Also checking that all database components are valid post de-instillation:
Select * from dba_registry;
I hope this would help…..
No comments:
Post a Comment