PSU oracle
Before we download the required patch, we need to verify if we have java user objects in use in the database. This helps us determine if we need the OJVM patch or not. If Multimedia, Spatial, and/or OLAP features/components are installed and used in the database then the OJVM patch will be required.
OJVM PSU/Update patches: are packaged separately from the Database PSU/Update (or equivalent) as they cannot be installed in a RAC Rolling manner, nor in Standby First manner.
Beginning with OJVM Release Update 18.4 and later (including 19c and beyond) the OJVM Release Updates are now Oracle RAC Rolling installable.
SQL> select name, version ,detected_usages, currently_used, first_usage_date, last_usage_date, feature_info, last_sample_date, description from dba_feature_usage_statistics where name like '%Java%';
NAME VERSION DETECTED_USAGES CURRE FIRST_USAGE_DATE LAST_USAGE_DATE FEATURE_INFO LAST_SAMPLE_DATE DESCRIPTION
-------------------------------------------------- ----------------- --------------- ----- ------------------ ------------------ -------------------------------------------------------------------------------- ------------------ --------------------------------------------------
Oracle Java Virtual Machine (user) 12.1.0.2.0 0 FALSE 11-SEP-16 20:36:46 OJVM has been used by at least one non-system user
Oracle Java Virtual Machine (system) 12.1.0.2.0 2 TRUE 13-JUL-16 22:10:37 11-SEP-16 20:36:46 System users: MDSYS with 646 classes, 4 resources, 0 sources. ORDSYS with 2490 c 11-SEP-16 20:36:46 OJVM default system users
How to Check or Verify if the Oracle JVM is Installed in the Database (Doc ID 397770.1)
Steps for PSU apply
1,Take the backup of existing Opatch and update the opatch GRID and ORACLE_HOME on both nodes
cd $GRID_HOME
mv OPatch/ OPatch_bkp
unzip p6880880_122010_Linux-x86-64.zip
chown -R oracle:oinstall OPatch
chmod -R 755 OPatch
cd $ORACLE_HOME
mv OPatch/ OPatch_bkp
unzip p6880880_122010_Linux-x86-64.zip
chown -R oracle:oinstall OPatch
chmod -R 755 OPatch
2 Validation of Oracle Inventory
Before beginning patch application, check the consistency of inventory information for GI home and each database home to be patched.
For database home:
$ORACLE_HOME/OPatch/opatch lsinventory -detail -oh $ORACLE_HOME
For Grid home:
$ $GRID_HOME/OPatch/opatch lsinventory -detail -oh $GRID_HOME
OPatch 12.2.0.1.5 or later, the following Opatch Option -ocmrf <ocm response file> does not need to be provided.
3 As root user,
Use -analyse to One-off Patch Conflict Detection and Resolution:
$GRID_HOME/OPatch/opatchauto apply /mnt/hgfs/E/roll_patch/28349311 -analyze -oh $GRID_HOME
$ORACLE_HOME/OPatch/opatchauto apply /mnt/hgfs/E/roll_patch/28349311 -analyze -oh $ORACLE_HOME
Analyse will tell if any patch needs to rollback before applying PSU
for eg,
Patch “/stage/PSUpatch/22191349/21948354” is already installed on “/u01/app/oracle/12.1.0.2/grid”. Please rollback the existing identical patch first.
So rollback patch "21948354" before applying GRID PSU using
$opatch rollback -id 21948354 -local -oh /u01/app/oracle/12.1.0.2/grid
OPatchauto automatically patch the typical Grid Infrastructure (GI) and RAC home directories with minimal intervention.
The main advantage of opatchauto utility was automatically down the CRS and database services and restart the services after apply patching.
$GRID_HOME/OPatch/opatchauto apply /mnt/hgfs/E/roll_patch/28349311 -oh $GRID_HOME
$ORACLE_HOME/OPatch/opatchauto apply /mnt/hgfs/E/roll_patch/27468957 -oh $ORACLE_HOME
Repeat above steps in all nodes , in the last node Opatchauto will apply the datapatch in every databaes instance.
Note:- Make sure the above applies both OCW and PSU patches.
Rolllback -
To roll back the patch from the GI home and each Oracle RAC database home:
# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/22646084
To roll back the patch from the GI home:
# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/22646084 -oh <path to GI home>
To roll back the patch from the Oracle RAC database home:
# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/22646084 -oh <oracle_home1_path>,<oracle_home2_path>
DATAPATCH :-
Datapatch is the new tool that enables automation of post-patch SQL actions for RDBMS patches. So, In 12c you don’t use carbundle psu apply now this is all done using datapatch.
Datapatch resides in the opatch directory i.e $ORACLE_HOME/OPatch folder
datapatch is integrated with Opatchauto
OPatchAuto calls datapatch to complete post patch actions upon installation of the binary patch and restart of the database.
Datapatch integration with normal OPatch is not possible as OPatch is executed when the database is down and
datapatch requires the database to be opened to complete its activity.
RAC specific: For a RAC environment, after the binary patch has been applied on all nodes run Datapatch to complete the post-install SQL deployment for the PSU only from one node. Datapatch need not be run on all the nodes.
To rollback dataptch
#datapatch -rollback 26609783 -force -verbose
To check the Oct PSU 2018 applied to your database using the following SQL statement,
Query dba_registry_sqlpatch;
select PATCH_ID,
ACTION,
ACTION_TIME,
DESCRIPTION,
STATUS,
BUNDLE_SERIES
from registry$sqlpatch
If you are using Opatch you can check the conflicts using "CheckConflictAgainstOHWithDetail"
eg,
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph /u01/staging/patch_jvm/23177536
Oracle JavaVM Component Database PSU/Update is released as part of the Critical Patch Update program from October 2014 onwards.
The OJVM patch is a non-rolling patch and it requires a full shutdown of everyting on the cluser
OJVM PATCH normally applied using opatch
SQL> select name, version ,detected_usages, currently_used, first_usage_date, last_usage_date, feature_info, last_sample_date, description from dba_feature_usage_statistics where name like '%Java%';
NAME VERSION DETECTED_USAGES CURRE FIRST_USAGE_DATE LAST_USAGE_DATE FEATURE_INFO LAST_SAMPLE_DATE DESCRIPTION
-------------------------------------------------- ----------------- --------------- ----- ------------------ ------------------ -------------------------------------------------------------------------------- ------------------ --------------------------------------------------
Oracle Java Virtual Machine (user) 12.1.0.2.0 0 FALSE 11-SEP-16 20:36:46 OJVM has been used by at least one non-system user
Oracle Java Virtual Machine (system) 12.1.0.2.0 2 TRUE 13-JUL-16 22:10:37 11-SEP-16 20:36:46 System users: MDSYS with 646 classes, 4 resources, 0 sources. ORDSYS with 2490 c 11-SEP-16 20:36:46 OJVM default system users
How to Check or Verify if the Oracle JVM is Installed in the Database (Doc ID 397770.1)
Steps for PSU apply
1,Take the backup of existing Opatch and update the opatch GRID and ORACLE_HOME on both nodes
cd $GRID_HOME
mv OPatch/ OPatch_bkp
unzip p6880880_122010_Linux-x86-64.zip
chown -R oracle:oinstall OPatch
chmod -R 755 OPatch
cd $ORACLE_HOME
mv OPatch/ OPatch_bkp
unzip p6880880_122010_Linux-x86-64.zip
chown -R oracle:oinstall OPatch
chmod -R 755 OPatch
2 Validation of Oracle Inventory
Before beginning patch application, check the consistency of inventory information for GI home and each database home to be patched.
For database home:
$ORACLE_HOME/OPatch/opatch lsinventory -detail -oh $ORACLE_HOME
For Grid home:
$ $GRID_HOME/OPatch/opatch lsinventory -detail -oh $GRID_HOME
OPatch 12.2.0.1.5 or later, the following Opatch Option -ocmrf <ocm response file> does not need to be provided.
3 As root user,
Use -analyse to One-off Patch Conflict Detection and Resolution:
$GRID_HOME/OPatch/opatchauto apply /mnt/hgfs/E/roll_patch/28349311 -analyze -oh $GRID_HOME
$ORACLE_HOME/OPatch/opatchauto apply /mnt/hgfs/E/roll_patch/28349311 -analyze -oh $ORACLE_HOME
Analyse will tell if any patch needs to rollback before applying PSU
for eg,
Patch “/stage/PSUpatch/22191349/21948354” is already installed on “/u01/app/oracle/12.1.0.2/grid”. Please rollback the existing identical patch first.
So rollback patch "21948354" before applying GRID PSU using
$opatch rollback -id 21948354 -local -oh /u01/app/oracle/12.1.0.2/grid
4 Apply the patch using Opatchauto
The main advantage of opatchauto utility was automatically down the CRS and database services and restart the services after apply patching.
$GRID_HOME/OPatch/opatchauto apply /mnt/hgfs/E/roll_patch/28349311 -oh $GRID_HOME
$ORACLE_HOME/OPatch/opatchauto apply /mnt/hgfs/E/roll_patch/27468957 -oh $ORACLE_HOME
Repeat above steps in all nodes , in the last node Opatchauto will apply the datapatch in every databaes instance.
Note:- Make sure the above applies both OCW and PSU patches.
Rolllback -
To roll back the patch from the GI home and each Oracle RAC database home:
# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/22646084
To roll back the patch from the GI home:
# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/22646084 -oh <path to GI home>
To roll back the patch from the Oracle RAC database home:
# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/22646084 -oh <oracle_home1_path>,<oracle_home2_path>
DATAPATCH :-
Datapatch is the new tool that enables automation of post-patch SQL actions for RDBMS patches. So, In 12c you don’t use carbundle psu apply now this is all done using datapatch.
Datapatch resides in the opatch directory i.e $ORACLE_HOME/OPatch folder
datapatch is integrated with Opatchauto
OPatchAuto calls datapatch to complete post patch actions upon installation of the binary patch and restart of the database.
Datapatch integration with normal OPatch is not possible as OPatch is executed when the database is down and
datapatch requires the database to be opened to complete its activity.
RAC specific: For a RAC environment, after the binary patch has been applied on all nodes run Datapatch to complete the post-install SQL deployment for the PSU only from one node. Datapatch need not be run on all the nodes.
To rollback dataptch
#datapatch -rollback 26609783 -force -verbose
To check the Oct PSU 2018 applied to your database using the following SQL statement,
Query dba_registry_sqlpatch;
select PATCH_ID,
ACTION,
ACTION_TIME,
DESCRIPTION,
STATUS,
BUNDLE_SERIES
from registry$sqlpatch
If you are using Opatch you can check the conflicts using "CheckConflictAgainstOHWithDetail"
eg,
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph /u01/staging/patch_jvm/23177536
Comments
Post a Comment