DBA Hub

📋Steps in this guide1/8

Patching : Apply a Grid Infrastructure (GI) Release Update (RU) to Existing ORACLE_HOMEs

This article gives an example of applying a Grid Infrastructure (GI) Release Update (RU) to existing ORACLE_HOMEs for a Real Application Clusters (RAC) installation.

oracle miscconfigurationintermediate
by OracleDba
14 views
1

Assumptions

This article makes some assumptions.
2

Environment

Set up the environment. This includes the OPatch and patch file names, and the paths. Notice how OPatch has been added to the environment variable. Remember to reset these if switching between users.

Code/Command (click line numbers to comment):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
export SOFTWARE_DIR=/u01/software
export ORACLE_BASE=/u01/app/oracle

# 19c
export GRID_HOME=/u01/app/19.0.0/grid
export DB_HOME=${ORACLE_BASE}/product/19.0.0/dbhome_1
export OPATCH_FILE="p6880880_190000_Linux-x86-64.zip"
export PATCH_FILE="p34130714_190000_Linux-x86-64.zip"
export PATCH_TOP=${SOFTWARE_DIR}/34130714

# 21c
export GRID_HOME=/u01/app/21.0.0/grid
export DB_HOME=${ORACLE_BASE}/product/21.0.0/dbhome_1
export OPATCH_FILE="p6880880_210000_Linux-x86-64.zip"
export PATCH_FILE="p34155589_210000_Linux-x86-64.zip"
export PATCH_TOP=${SOFTWARE_DIR}/34155589

export ORACLE_HOME=${GRID_HOME}
export PATH=${ORACLE_HOME}/OPatch:${PATH}
3

Apply the Patch

Issue to following commands as the grid owner user, unless otherwise stated. Keep a copy of the existing OPatch, and unzip the latest version of OPatch on all nodes of the cluster. You may have to do this as the root user for the grid home, but make sure the ownership of the resulting OPatch directory matches the original ownership once unzipped. Unzip the GI release update patch software on all nodes of the cluster. Check for patch conflicts by running the following commands as the grid owner. The patch numbers will vary depending on the GI release update you are using. Check there is space to complete the patching. Create a file called "/tmp/patch_list_gihome.txt" containing the list of patches, then run the space check as the grid owner. The patch numbers will vary depending on the GI release update you are using. It should report the "Prereq "checkSystemSpace" passed." message. If not, make more free space available. Run the patch as the root user on the first node of the cluster. We could also add the "-inplace" flag, but this is not necessary. Assuming this completes without errors, run the patch on the remaining nodes of the cluster. The remaining nodes can be patched at the same time. Only the first node must be patched on its own. Once complete, make sure all the services are running as expected. At this point your patching should be complete. Check the PDBs are running as expected on all nodes.

Code/Command (click line numbers to comment):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
cd ${GRID_HOME}
mv OPatch OPatch.`date +"%Y"-"%m"-"%d"`
unzip -oq ${SOFTWARE_DIR}/${OPATCH_FILE}

cd ${DB_HOME}
mv OPatch OPatch.`date +"%Y"-"%m"-"%d"`
unzip -oq ${SOFTWARE_DIR}/${OPATCH_FILE}

cd ${SOFTWARE_DIR}
unzip -oq ${PATCH_FILE}

# 19c
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ${PATCH_TOP}/34133642
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ${PATCH_TOP}/34160635
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ${PATCH_TOP}/34139601
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ${PATCH_TOP}/34318175
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ${PATCH_TOP}/33575402

# 21c
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ${PATCH_TOP}/34160444
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ${PATCH_TOP}/34172227
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ${PATCH_TOP}/34172231
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ${PATCH_TOP}/34174046
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ${PATCH_TOP}/34320616
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ${PATCH_TOP}/34327014

# 19c
cat > /tmp/patch_list_gihome.txt <<EOF
${PATCH_TOP}/34133642
${PATCH_TOP}/34160635
${PATCH_TOP}/34139601
${PATCH_TOP}/34318175
${PATCH_TOP}/33575402
EOF

# 21c
cat > /tmp/patch_list_gihome.txt <<EOF
${PATCH_TOP}/34160444
${PATCH_TOP}/34172227
${PATCH_TOP}/34172231
${PATCH_TOP}/34174046
${PATCH_TOP}/34320616
${PATCH_TOP}/34327014
EOF

opatch prereq CheckSystemSpace -phBaseFile /tmp/patch_list_gihome.txt

opatchauto apply ${PATCH_TOP}

opatchauto apply ${PATCH_TOP}

${GRID_HOME}/bin/crsctl stat res -t

sqlplus / as sysdba

show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
SQL>
4

Datapatch on Closed PDBs

Under normal circumstances this step should not be necessary as it is run automatically as part of . If you have some PDBs that are closed, or in mounted mode, you may have to apply datapatch to them separately. Perform the following action on a single node as the database owner. Make sure we are pointing to the database home. Recompile any invalid objects. Check the PDBs on all nodes to make sure they are running as expected. If any are down or marked as mounted, it's worth checking the view, which may tell us why. Typically we can just restart them to fix the status. Clean up the patch software. We can check the patch history by running the following command on the relevant home on the nodes. Run the following command on each node of the cluster as the root user. Once complete, make sure all the services are running as expected. Check the PDBs on all nodes to make sure they are running as expected. If any are down or marked as mounted, it's worth checking the view, which may tell us why. Typically we can just restart them to fix the status. Pros: - We don't have an additional s, so this reduces the space needed to complete the patching. - Since the isn't changing, we don't need to worry about altering any configuration files to point at the new home. Cons: - Patching the existing requires more downtime, as the services must be offline while the home is being patched. This is offset by the fact that the RAC nodes are patched one at a time, so the database remains up for the whole of the operation. - If something goes wrong that can't be fixed by rolling back the patch, we may have to recover the from a backup to restore the original running instance. For more information see: - Critical Patch Updates, Security Alerts and Bulletins - Patching : Apply a Grid Infrastructure (GI) Release Update (RU) to New ORACLE_HOMEs (Out-Of-Place Patching) Hope this helps. Regards Tim...

Code/Command (click line numbers to comment):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
export ORACLE_SID=cdbrac1
export ORACLE_HOME=${DB_HOME}
export PATH=${ORACLE_HOME}/bin:$PATH

sqlplus / as sysdba <<EOF
alter pluggable database all open;
exit;
EOF

cd $ORACLE_HOME/OPatch
./datapatch -verbose

$ORACLE_HOME/perl/bin/perl \
    -I$ORACLE_HOME/perl/lib \
    -I$ORACLE_HOME/rdbms/admin \
    $ORACLE_HOME/rdbms/admin/catcon.pl \
    -l /tmp/ \
    -b postpatch_${ORACLE_SID}_recompile \
    -C 'PDB$SEED' \
    $ORACLE_HOME/rdbms/admin/utlrp.sql

sqlplus / as sysdba

show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
SQL>

alter pluggable database pdb1 close;
alter pluggable database pdb1 open;

show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
SQL>

cd ${SOFTWARE_DIR}
rm -Rf ${PATCH_TOP}
rm -Rf ${OPATCH_FILE}
rm -Rf ${PATCH_FILE}
rm -Rf PatchSearch.xml

opatch lsinventory

opatchauto rollback ${PATCH_TOP}

${GRID_HOME}/bin/crsctl stat res -t

sqlplus / as sysdba

show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
SQL>

sqlplus / as sysdba

alter pluggable database pdb1 close;
alter pluggable database pdb1 open;

show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
SQL>
5

Clean Up

Clean up the patch software.

Code/Command (click line numbers to comment):

1
2
3
4
5
cd ${SOFTWARE_DIR}
rm -Rf ${PATCH_TOP}
rm -Rf ${OPATCH_FILE}
rm -Rf ${PATCH_FILE}
rm -Rf PatchSearch.xml
6

Check the Patch History

We can check the patch history by running the following command on the relevant home on the nodes.

Code/Command (click line numbers to comment):

1
opatch lsinventory
7

Rollback the Patch

Run the following command on each node of the cluster as the root user. Once complete, make sure all the services are running as expected. Check the PDBs on all nodes to make sure they are running as expected. If any are down or marked as mounted, it's worth checking the view, which may tell us why. Typically we can just restart them to fix the status.

Code/Command (click line numbers to comment):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
opatchauto rollback ${PATCH_TOP}

${GRID_HOME}/bin/crsctl stat res -t

sqlplus / as sysdba

show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
SQL>

sqlplus / as sysdba

alter pluggable database pdb1 close;
alter pluggable database pdb1 open;

show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
SQL>
8

Pros and Cons

Pros: - We don't have an additional s, so this reduces the space needed to complete the patching. - Since the isn't changing, we don't need to worry about altering any configuration files to point at the new home. Cons: - Patching the existing requires more downtime, as the services must be offline while the home is being patched. This is offset by the fact that the RAC nodes are patched one at a time, so the database remains up for the whole of the operation. - If something goes wrong that can't be fixed by rolling back the patch, we may have to recover the from a backup to restore the original running instance. For more information see: - Critical Patch Updates, Security Alerts and Bulletins - Patching : Apply a Grid Infrastructure (GI) Release Update (RU) to New ORACLE_HOMEs (Out-Of-Place Patching) Hope this helps. Regards Tim...

Comments (0)

Please to add comments

No comments yet. Be the first to comment!