When we invoke opatchauto, opatch will patch both the GI stack and the database software stack. Since we do not have a database running,patch will skip the database software stack and only apply the PSU to the GI Home. Before we invoke the opatchauto command,let’s create the ocm.rsp response file by executing the OCM Installation Response Generator (emocmrsp).
As per oracle Doc id: 1591616.1:
Till the above doc id, while we applying PSU or one off patches, we used to pass -ocmrf parameter. After installing latest opatch p6880880_122010_.zip (12.2.0.1.5 release and later), unable to create ocm.rsp,when checked, OPatch/ocm/bin, It was empty and binary emocmrsp was missing.
OPatch/ocm/bin>ls -lrt
total 0
As OCM is no longer packaged with OPatch, the -ocmrf is no longer needed in the command line.
as latest opatch doesn’t contain OCM , the option “-ocmrf” is unnecessary if latest opatch is being used.
When using OPatch version 12.2.0.1.5 or later, No need of ocm.rsp file for Grid Patching i.e following Opatch Option -ocmrf not needed.
AUTO Patching:
AUTO patching option is the enhancement from Oracle in the recent times which automates the entire patching procedure smoothly and more importantly without much DBA intervene.
Auto patching doesn’t go well when multiple Oracle homes exists with different software owners.
If you have multiple versions of Oracle databases running.
During the course of patching, if any of the files fail to copy/rollback the backup copy due to file busy with flag on the OS (for example, Error in writing to file'/u00/app/11.2.0.2/grid/bin/adctrl' (Text file busy)) the patch will be automatically rolled back and subsequently cluster and all services will be restarted.
In the above circumstances, one may choose going with the AUTO patch separately for GI and then to the RDBMS homes.
###
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.
In general, when we invoke opatchauto will patch both the GI stack and the database software stack. Since we have mentioned the -oh it will apply the PSU to the specified home.
To apply a patch using opatchauto,we need to run as a root user.
Steps in details as below:
Set the GI home environment and verify it.
echo $ORACLE_HOME
echo $ORACLE_SID
Check opatch version in GI home:
opatchauto version
opatch lsinventory
opatch lsinventory -detail -oh $ORACLE_HOME
opatch lsinventory -detail -oh /u05/app/12.1.0.2/grid
Check conflicts:
NOTE: opatchauto is running in ANALYZE mode. There will be no change to your system.
sudo $GRID_HOME/OPatch/opatchauto apply $Patch_location/25434003 -analyze
As root user:
/u05/app/12.1.0.2/grid/OPatch/opatchauto apply /int/fs/B/roll_patch/28349311 -analyze -oh /u05/app/12.1.0.2/grid
APPLYING PATCH:
It’s needed a response file to use opatchauto hence create the response file and apply the patch in GI HOME,User oracle with proper env values set:
cd $GRID_HOME/OPatch/ocm/bin
$ ls -ltr
dummy
emocmrsp
$ ./emocmrsp
$ ls -ltr
dummy
emocmrsp
ocm.rsp <= RESPONSE FILE CREATED
INSTALL:
stops instance+listener+ASM+ (if it deppends of $ORACLE_HOME )
sudo $GRID_HOME/OPatch/opatchauto apply $Patch_location/25434003 -ocmrf $RESPONSE_FILE_PATH/ocm.rsp –oh $GRID_HOME
opatchauto for GID_HOME:
/u05/app/12.1.0.2/grid/OPatch/opatchauto apply /int/fs/B/roll_patch/28349313 -oh /u05/app/12.1.0.2/grid
opatchauto for ORACLE_HOME:
/u05/app/oracle/product/12.1.0.2/db_2/OPatch/opatchauto apply /int/fs/B/roll_patch/27468958 -oh/u05/app/oracle/product/12.1.0.2/db_2
Datapatch is the new tool that enables automation of post-patch SQL actions for RDBMS patches. In 12c we don’t use carbundle psu apply, all this will be done using datapatch. OPatchAuto calls datapatch to complete post patch actions upon installation of the binary patch and restart of the database.
select BUNDLE_SERIES,PATCH_UID,PATCH_ID,
VERSION,ACTION,STATUS,ACTION_TIME ,DESCRIPTION
from dba_registry_sqlpatch;
Post-patch:
Start services
Below direct command will aslo help in same purpose.
As Root User execute command
$ORACLE_HOME/OPatch/ocm/bin/emocmrsp -no_banner -output $ORACLE_HOME/ocm.rsp
$ORACLE_HOME/OPatch/opatch auto <patch loc.> -oh $ORACLE_HOME -ocmrf $ORACLE_HOME/ocm.rsp
https://updates.oracle.com/Orion/Services/download?type=readme&aru=20990697
DEINSTALL PATCH:
Stop all services
opatchauto rollback Patch_location/25434003 –oh $GRID_HOME
Difference between CPU and PSU:
CPU stands for critical patch update & PSU for patch set update.
Critical Patch Update (CPU) is overall release of security fixes each quarter rather than the cumulative database security patch for the quarter.
CPU are built on patch set version e.g 10.2.0.3 where as PSU are built on base of prevoius version e.g. 10.2.0.3.1.
Patch Set Updates (PSU) are the same cumulative patches that include both the security fixes and priority fixes. The key with PSUs is they are minor version upgrades (e.g., 11.2.0.1.1 to 11.2.0.1.2). Once a PSU is applied, only PSUs can be applied in future quarters until the database is upgraded to a new base version.
PSU can always be applied over any CPU.
CPU is subset of PSU(PSU contain CPU)
To check Applied PSU patched you need to run :
opatch lsinventory -bugs_fixed | grep -i 'DATABASE PSU'
and if you need to check CPU :
Select * from registry$history;
Apply Patch PSU:
$ORACLE_HOME/Opatch/opatch apply
1. cd $ORACLE_HOME/rdbms/admin
2. sqlplus /nolog
3. SQL> CONNECT / AS SYSDBA
4. SQL> startup
5. SQL> @catbundle psu apply
6. SQL>@?/rdbms/admin/utlrp.sql
Check the following log files in $ORACLE_HOME/cfgtoollogs/catbundle or $ORACLE_BASE/cfgtoollogs/catbundle for any errors:
catbundle_PSU_<database SID>_APPLY_<TIMESTAMP>.log
catbundle_PSU_<database SID>_GENERATE_<TIMESTAMP>.log
OJVM COMPONENT:
Shutdown all services (Recommend stop OMS agent too)
$ORACLE_HOME/Opatch/opatch apply
1. cd $ORACLE_HOME/sqlpatch/25434033
2. sqlplus /nolog
3. SQL> CONNECT / AS SYSDBA
4. SQL> STARTUP UPGRADE
5. SQL> @postinstall.sql
6. SQL> shutdown
7. SQL> startup
8. SQL> @?/rdbms/admin/utlrp.sql
As per oracle Doc id: 1591616.1:
Till the above doc id, while we applying PSU or one off patches, we used to pass -ocmrf parameter. After installing latest opatch p6880880_122010_.zip (12.2.0.1.5 release and later), unable to create ocm.rsp,when checked, OPatch/ocm/bin, It was empty and binary emocmrsp was missing.
OPatch/ocm/bin>ls -lrt
total 0
As OCM is no longer packaged with OPatch, the -ocmrf is no longer needed in the command line.
as latest opatch doesn’t contain OCM , the option “-ocmrf” is unnecessary if latest opatch is being used.
When using OPatch version 12.2.0.1.5 or later, No need of ocm.rsp file for Grid Patching i.e following Opatch Option -ocmrf not needed.
AUTO Patching:
AUTO patching option is the enhancement from Oracle in the recent times which automates the entire patching procedure smoothly and more importantly without much DBA intervene.
Auto patching doesn’t go well when multiple Oracle homes exists with different software owners.
If you have multiple versions of Oracle databases running.
During the course of patching, if any of the files fail to copy/rollback the backup copy due to file busy with flag on the OS (for example, Error in writing to file'/u00/app/11.2.0.2/grid/bin/adctrl' (Text file busy)) the patch will be automatically rolled back and subsequently cluster and all services will be restarted.
In the above circumstances, one may choose going with the AUTO patch separately for GI and then to the RDBMS homes.
###
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.
In general, when we invoke opatchauto will patch both the GI stack and the database software stack. Since we have mentioned the -oh it will apply the PSU to the specified home.
To apply a patch using opatchauto,we need to run as a root user.
Steps in details as below:
Set the GI home environment and verify it.
echo $ORACLE_HOME
echo $ORACLE_SID
Check opatch version in GI home:
opatchauto version
opatch lsinventory
opatch lsinventory -detail -oh $ORACLE_HOME
opatch lsinventory -detail -oh /u05/app/12.1.0.2/grid
Check conflicts:
NOTE: opatchauto is running in ANALYZE mode. There will be no change to your system.
sudo $GRID_HOME/OPatch/opatchauto apply $Patch_location/25434003 -analyze
As root user:
/u05/app/12.1.0.2/grid/OPatch/opatchauto apply /int/fs/B/roll_patch/28349311 -analyze -oh /u05/app/12.1.0.2/grid
APPLYING PATCH:
It’s needed a response file to use opatchauto hence create the response file and apply the patch in GI HOME,User oracle with proper env values set:
cd $GRID_HOME/OPatch/ocm/bin
$ ls -ltr
dummy
emocmrsp
$ ./emocmrsp
$ ls -ltr
dummy
emocmrsp
ocm.rsp <= RESPONSE FILE CREATED
INSTALL:
stops instance+listener+ASM+ (if it deppends of $ORACLE_HOME )
sudo $GRID_HOME/OPatch/opatchauto apply $Patch_location/25434003 -ocmrf $RESPONSE_FILE_PATH/ocm.rsp –oh $GRID_HOME
opatchauto for GID_HOME:
/u05/app/12.1.0.2/grid/OPatch/opatchauto apply /int/fs/B/roll_patch/28349313 -oh /u05/app/12.1.0.2/grid
opatchauto for ORACLE_HOME:
/u05/app/oracle/product/12.1.0.2/db_2/OPatch/opatchauto apply /int/fs/B/roll_patch/27468958 -oh/u05/app/oracle/product/12.1.0.2/db_2
Datapatch is the new tool that enables automation of post-patch SQL actions for RDBMS patches. In 12c we don’t use carbundle psu apply, all this will be done using datapatch. OPatchAuto calls datapatch to complete post patch actions upon installation of the binary patch and restart of the database.
select BUNDLE_SERIES,PATCH_UID,PATCH_ID,
VERSION,ACTION,STATUS,ACTION_TIME ,DESCRIPTION
from dba_registry_sqlpatch;
Post-patch:
Start services
Below direct command will aslo help in same purpose.
As Root User execute command
$ORACLE_HOME/OPatch/ocm/bin/emocmrsp -no_banner -output $ORACLE_HOME/ocm.rsp
$ORACLE_HOME/OPatch/opatch auto <patch loc.> -oh $ORACLE_HOME -ocmrf $ORACLE_HOME/ocm.rsp
https://updates.oracle.com/Orion/Services/download?type=readme&aru=20990697
DEINSTALL PATCH:
Stop all services
opatchauto rollback Patch_location/25434003 –oh $GRID_HOME
Difference between CPU and PSU:
CPU stands for critical patch update & PSU for patch set update.
Critical Patch Update (CPU) is overall release of security fixes each quarter rather than the cumulative database security patch for the quarter.
CPU are built on patch set version e.g 10.2.0.3 where as PSU are built on base of prevoius version e.g. 10.2.0.3.1.
Patch Set Updates (PSU) are the same cumulative patches that include both the security fixes and priority fixes. The key with PSUs is they are minor version upgrades (e.g., 11.2.0.1.1 to 11.2.0.1.2). Once a PSU is applied, only PSUs can be applied in future quarters until the database is upgraded to a new base version.
PSU can always be applied over any CPU.
CPU is subset of PSU(PSU contain CPU)
To check Applied PSU patched you need to run :
opatch lsinventory -bugs_fixed | grep -i 'DATABASE PSU'
and if you need to check CPU :
Select * from registry$history;
Apply Patch PSU:
CHECK CONFLICTS
[oracle@hostname 26027154]$ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./
Stop instance and associated listener (if it’s rdbms dependant)$ORACLE_HOME/Opatch/opatch apply
1. cd $ORACLE_HOME/rdbms/admin
2. sqlplus /nolog
3. SQL> CONNECT / AS SYSDBA
4. SQL> startup
5. SQL> @catbundle psu apply
6. SQL>@?/rdbms/admin/utlrp.sql
Check the following log files in $ORACLE_HOME/cfgtoollogs/catbundle or $ORACLE_BASE/cfgtoollogs/catbundle for any errors:
catbundle_PSU_<database SID>_APPLY_<TIMESTAMP>.log
catbundle_PSU_<database SID>_GENERATE_<TIMESTAMP>.log
OJVM COMPONENT:
Shutdown all services (Recommend stop OMS agent too)
$ORACLE_HOME/Opatch/opatch apply
1. cd $ORACLE_HOME/sqlpatch/25434033
2. sqlplus /nolog
3. SQL> CONNECT / AS SYSDBA
4. SQL> STARTUP UPGRADE
5. SQL> @postinstall.sql
6. SQL> shutdown
7. SQL> startup
8. SQL> @?/rdbms/admin/utlrp.sql
No comments:
Post a Comment