Oracle RAC数据库升级补丁技术难度比较大,而且需要区分GRID和ORACLE软件的补丁升级,需要注意的细节很多,下面介绍ORACLE12C RAC数据库GRID和ORACLE补丁升级的方法,根据官方指导说明实操验证通过,可在正式环境放心实施。


1.2.1.3Download and Unzip the Patch  

下载并解压补丁

To apply the patch, it must be accessible from all nodes in the Oracle cluster. Download the patch and unzip it to a shared location, this is called the <UNZIPPED_PATCH_LOCATION>. This directory must be empty and not be /tmp. Additionally, the directory should have read permission for the ORA_INSTALL group.

$ cd <UNZIPPED_PATCH_LOCATION>

Check that the directory is empty.

$ ls

Unzip the patch as grid home owner except for installations that do not have any grid homes. For installations where this patch will be applied to the Database home only, the patch needs to be unzipped as the database home owner.

$ unzip p30501932_122010_Linux-x86-64.zip

1.2.1.4 Run OPatch Conflict Check

Determine whether any currently installed one-off patches conflict with this patch 30501932 as follows:

诊断当前GI或ORACLE软件与各补丁集是否存在冲突:

  • For Grid Infrastructure Home, as home user:

    % $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/30501932/30593149
    % $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/30501932/30585969
    % $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/30501932/30586063
    % $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/30501932/26839277
    % $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/30501932/30591794
  • For Database home, as home user:

    % $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/30501932/30593149
    % $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/30501932/30585969
    

The report will indicate the interim patches that conflict with the patch 30501932 and the interim patches for which patch 30501932 is a superset.

Note:

When OPatch starts, it validates the patch and ensures that there are no conflicts with the software already installed in the ORACLE_HOME. OPatch categorizes conflicts into the following types:

  • Conflicts with a patch already applied to the ORACLE_HOME.

    In this case, stop the patch installation and contact Oracle Support Services.

  • Conflicts with subset patch already applied to the ORACLE_HOME.

    In this case, continue with the patch installation because as the new patch contains all the fixes from the existing patch in the ORACLE_HOME. And, in any case, the subset patch will automatically be rolled back prior to the installation of the new patch.

1.2.1.5 Run OPatch SystemSpace Check

Check if enough free space is available on the ORACLE_HOME filesystem for the patches to be applied as given below:

检查GI和ORACLE补丁包所需的空间是否足够(如果你分区足够大,这一步可以忽略)

  • For Grid Infrastructure Home, as home user:

    1. Create file /tmp/patch_list_gihome.txt with the following content:

      % cat /tmp/patch_list_gihome.txt
      
      <UNZIPPED_PATCH_LOCATION>/30501932/30593149
      <UNZIPPED_PATCH_LOCATION>/30501932/30585969
      <UNZIPPED_PATCH_LOCATION>/30501932/30586063
      <UNZIPPED_PATCH_LOCATION>/30501932/26839277
      <UNZIPPED_PATCH_LOCATION>/30501932/30591794
    2. Run the opatch command to check if enough free space is available in the Grid Infrastructure Home:

      % $ORACLE_HOME/OPatch/opatch prereq CheckSystemSpace -phBaseFile /tmp/patch_list_gihome.txt
      
  • For Database home, as home user:

    1. Create file /tmp/patch_list_dbhome.txt with the following content:

      % cat /tmp/patch_list_dbhome.txt
      <UNZIPPED_PATCH_LOCATION>/30501932/30593149
      <UNZIPPED_PATCH_LOCATION>/30501932/30585969
      
    2. Run opatch command to check if enough free space is available in the Database Home:

      % $ORACLE_HOME/OPatch/opatch prereq CheckSystemSpace -phBaseFile /tmp/patch_list_dbhome.txt
      

The command output reports pass and fail messages as per the system space availability:

  • If OPatch reports Prereq "checkSystemSpace" failed., then cleanup the system space as the required amount of space is not available.

  • If OPatch reports Prereq "checkSystemSpace" passed., then no action is needed. Proceed with patch installation.

1.2.2 One-off Patch Conflict Detection and Resolution

The fastest and easiest way to determine whether you have one-off patches in the Oracle home that conflict with the patch, and to get the necessary conflict resolution patches, is to use the Patch Recommendations and Patch Plans features on the Patches & Updates tab in My Oracle Support. These features work in conjunction with the My Oracle Support Configuration Manager. Recorded training sessions on these features can be found in Document 603505.1.

However, if you are not using My Oracle Support Patch Plans, the My Oracle Support Conflict Checker tool enables you to upload an OPatch inventory and check the patches that you want to apply to your environment for conflicts.

If no conflicts are found, you can download the patches. If conflicts are found, the tool finds an existing resolution to download. If no resolution is found, it will automatically request a resolution, which you can monitor in the Plans and Patch Requests region of the Patches & Updates tab.

For more information, see Knowledge Document 1091294.1, How to use the My Oracle Support Conflict Checker Tool.

Or, manually determine whether any currently installed one-off patches conflict with the PSU patch as follows:

  • In the unzipped directory as described in Download and Unzip the Patch.

  • The following commands check for conflicts in both the 12.1 GI home and the 12.1 DB homes.

    下面是模拟执行,建议用下面方式-analyze先模拟执行,如没有报错再正式实施:

    • In case you are applying the patch, run this command:

      #GRID_HOME/OPatch/opatchauto apply <UNZIPPED_PATCH_LOCATION>/30501932 -analyze
      
    • In case you are rolling back the patch, run this command:

      #GRID_HOME/OPatch/opatchauto rollback <UNZIPPED_PATCH_LOCATION>/30501932 -analyze
      

Note that Oracle proactively generates interim patches for common conflicts.

See My Oracle Support Document 1061295.1 Patch Set Updates - One-off Patch Conflict Resolution to determine, for each conflicting patch, whether a conflict resolution patch is already available, and if you need to request a new conflict resolution patch or if the conflict may be ignored.

1.2.3 opatchauto

The Opatch utility has automated the patch application for the Oracle Grid Infrastructure (GI) home and the Oracle RAC database homes. It operates by querying existing configurations and automating the steps required for patching each Oracle RAC database home of same version and the GI home.

The utility must be executed by an operating system (OS) user with root privileges, and it must be executed on each node in the cluster if the GI home or Oracle RAC database home is in non-shared storage. The utility should not be run in parallel on the cluster nodes.

Depending on command line options specified, one invocation of opatchauto can patch the GI home, Oracle RAC database homes, or both GI and Oracle RAC database homes of the same Oracle release version as the patch. You can also roll back the patch with the same selectivity.

Add the directory containing the opatchauto to the $PATH environment variable. For example:

从上面的详细说明可知,12C的grid补丁升级比较方便智能,直接用opatchauto apply命令执行即可,而且无需关闭CRS和数据库实例,这一点比11G方便很多,用root用户分别在GRID和ORACLE的HOME目录下运行即可,补丁会自动检测哪些属于GI_HOME哪些属于ORACLE_HOME的补丁包:

# export PATH=$PATH:<GI_HOME>/OPatch

To patch the GI home and all Oracle RAC database homes of the same version:

# opatchauto apply <UNZIPPED_PATCH_LOCATION>/30501932

To patch only the GI home:

# opatchauto apply <UNZIPPED_PATCH_LOCATION>/30501932 -oh <GI_HOME>

To patch one or more Oracle RAC database homes:

# opatchauto apply <UNZIPPED_PATCH_LOCATION>/30501932 -oh <oracle_home1_path>,<oracle_home2_path>

To roll back the patch from the GI home and each Oracle RAC database home:

# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/30501932 

To roll back the patch from the GI home:

# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/30501932 -oh <path to GI home>  

To roll back the patch from the Oracle RAC database home:

# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/30501932 -oh <oracle_home1_path>,<oracle_home2_path> 

For more information about opatchauto, see Oracle® OPatch User's Guide.

For detailed patch installation instructions, see Patch Installation.

1.2.4 Patch Installation

The patch instructions will differ based on the configuration of the Grid infrastructure and the Oracle RAC database homes. Patching instructions for Oracle RAC Database Homes and GI together are listed below.

The most common configurations are listed as follows:

  • Case 1: Oracle RAC, where the GI Home and the Database Homes are not shared and ACFS file system is not configured

  • Case 2: Oracle RAC, where the GI Home is not shared, Database Home is shared, ACFS may be used

  • Case 3: Non-Oracle RAC Database homes

For other configurations listed below, see My Oracle Support Document 2246888.1:

  • GI Home is not shared, the Database Home is not shared, ACFS may be used.

  • Patching Oracle RAC Database Homes.

  • Patching GI Home alone.

  • Patching Oracle Restart Home.

  • Patching a software only GI Home installation or before the GI Home is configured.

Patching Oracle RAC Database Homes and GI Together

  • Case 1: Oracle RAC, where the GI Home and the Database Homes are not shared and ACFS file system is not configured.

    As root user, execute the following command on each node of the cluster:

    # <GI_HOME>/OPatch/opatchauto apply <UNZIPPED_PATCH_LOCATION>/30501932

    1.2.6.2 Loading Modified SQL Files into the Database

    The following steps load modified SQL files into the database. For a RAC environment, perform these steps on only one node.

    Datapatch is run to complete the post-install SQL deployment for the PSU. For further details about Datapatch, including Known Issues and workarounds to common problems, see: Database 12c Post Patch SQL Automation (Doc ID 1585822.1).

    下面是打好软件补丁后,升级数据库,12C也很方便,直接./datapatch -verbose即可

    1. For each separate database running on the same shared Oracle home being patched, run the datapatch utility as described in Table 1-3.

      Table 1-3 Steps to Run the Datapatch Utility for Standalone DB Versus Single/Multitenant (CDB/PDB) DB

      StepsStandalone DBStepsSingle/Multitenant (CDB/PDB) DB

      1

      % sqlplus /nolog

      1

      % sqlplus /nolog

      2

      SQL> Connect / as sysdba

      2

      SQL> Connect / as sysdba

      3

      SQL> startup

      3

      SQL> startup

      4

      SQL> quit

      4

      SQL> alter pluggable database all open;Foot 1

      5

      % cd $ORACLE_HOME/OPatch

      5

      SQL> quit

      6

      % ./datapatch -verbose

      6

      % cd $ORACLE_HOME/OPatch



      7

      % ./datapatch -verbose

      Footnote 1

      It is recommended the Post Install step be run on all pluggable databases; however, the following command (SQL> alter pluggable database PDB_NAME open ) could be substituted to only open certain PDBs in the single/multitenant database. Doing so will result in the Post Install step only being run on the CDB and opened PDB's. To update a pluggable database at a later date (skipped or newly plugged in), open the database using the alter pluggable database command mentioned previously and rerun the datapatch utility. See My Oracle Support Document 1935365.1 Multitenant Unplug/Plug Best Practices for more information about the procedure for unplugging/plugging with different patch releases (in both directions).

      The datapatch utility will then run the necessary apply scripts to load the modified SQL files into the database. An entry will be added to the dba_registry_sqlpatch view reflecting the patch application. In the dba_registry_sqlpatch view, verify the Status for the APPLY is "SUCCESS". For any other status, refer to the following My Oracle Support note for additional information and actions: Document 1609718.1 Datapatch Known Issues.

    2. Check the following log files in $ORACLE_BASE/cfgtoollogs/sqlpatch/30593149/<unique patch ID> for errors:

      30593149_apply_<database SID>_<CDB name>_<timestamp>.log
      

      where database SID is the database SID, CDB name is the name of the multitenant container database, and timestamp is of the form YYYYMMMDD_HH_MM_SS.

    3. If the OJVM RU or RUR is also installed, you may see invalid objects after execution of datapatch in the previous step. If this is the case, run utlrp.sql to revalidate these objects.

      cd $ORACLE_HOME/rdbms/admin
      sqlplus /nolog
      SQL> CONNECT / AS SYSDBA
      SQL> @utlrp.sql
      
    4. This patch now includes the OJVM Mitigation patch (Patch:19721304). If an OJVM RU is installed or planned to be installed, no further actions are necessary. Otherwise, the workaround of using the OJVM Mitigation patch can be activated. As SYSDBA do the following from the admin directory:

      SQL > @dbmsjdev.sql
      SQL > exec dbms_java_dev.disable
      

      For more information on the OJVM mitigation patch, see Document 1929745.1 Oracle Recommended Patches -- "Oracle JavaVM Component Database PSU and RU" (OJVM PSU and OJVM RU) Patches.