# #------------------------------------------------------------------------- # BUNDLE Patch for Base Bug 9294403 #------------------------------------------------------------------------- # # DATE: 5:26:50 Mar 19 2010 # ------------------------------- # Platform Patch for : AIX5L Based Systems (64-bit) (212) # Product Version # : 10.2.0.4.0 # Product Patched : CRS/RDBMS # #------------------------------------------------------------------------- # # Introduction: # ============= # # NOTE: Please refer to the following technote for information # regarding any known issues with the patch: Metalink Note 405820.1 # # http://metalink.oracle.com # # WARNING: Failure to carefully read and understand these requirements may # result in your applying a patch that can cause your Oracle Server to # malfunction, including interruption of service and/or loss of data. # # Requirements: # ============= # # If you do not meet all of the following requirements, please log an # iTAR, so that an Oracle Support Analyst may review your situation. The # Oracle analyst will help you determine if this patch is suitable for you # to apply to your system. We recommend that you avoid applying any # temporary patch unless directed by an Oracle Support Analyst who has # reviewed your system and determined that it is applicable. # # - You must use the OPatch utility release 10.2.0.4.7 or later. # You can download it from OracleMetaLink with patch 6880880 for all # platforms. # NOTE: Download the version for the 10.2.0.3 release, not # 10.2.0.1 or 10.2.0.2. # # - Your system configuration (Oracle Server version and patch # level, OS Version) must exactly match those in the bug # database entry. Any one-off patches you installed since # applying the 10.2.0.4.0 patchset will need to be removed # or will be superseded by this patch. # # If you do NOT meet these requirements, or are not certain that you meet # these requirements, please log an iTAR requesting assistance with this # patch and Support will make a determination about whether you should # apply this patch. # # Bugs Fixed: # =========== # # The bugs fixedby this bundle patch can be found in Metalink Note 405820.1. # # # Known Issues: # ============= # # For patch updates on Solaris clusters, the following must be verified: # The UDLM must be upgraded to have the appropriate version of # libskgxn2.so to avoid node reboots. To determine whether the proper # version of libskgxn2.so is installed, execute the following command: # /usr/bin/pkginfo -l ORCLudlm # The output of this command includes a VERSION line that should look # like: # VERSION: Dev Release 03/09/06, 64bit 3.3.4.9 reentrant, async # libskgxn2.so version 1 with bug 6404642 fix # # If the libskgxn2.so is not at version 1 in the UDLM package, the # UDLM must be upgraded # # Patch Installation Instructions: # ================================ # This patch can be applied to the CRS Home and the associated RAC RDBMS # homes in an automated manner using the "opatch auto" command. If you use the # "opatch auto" command, you will have the benefit of streamlined patching # for both Clusteware and RAC homes.Automatic patching will minimize the # number of steps you need to execute,and will provide rollback capabilities # if you need them. Please refer to AUTOMATIC PATCHING section below for # detailed steps for automatic patching.You can also apply the patch manually # by following the steps in MANUAL PATCHING section. # # AUTOMATIC PATCHING # ================== # # NOTE : The CRS stack *must* be *running* in order to apply the patch # automatically using the steps provided below . # # Prerequisites : # =============== # 1) Get Opatch 10.2.0.4.7 from Metalink and unzip this to the CRS_HOME on all # the cluster nodes, prior to executing the following commands. # It's must to update the CRS home on all cluster nodes with Opatch 10.2.0.4.7 # prior to using "opatch auto" command. # 2) In a Non-Shared CRS home environment, this command should be executed on # all the Cluster nodes serially # 3) In a Shared CRS Home environment, this command should be executed on any # one node # 4) The "opatch auto" command *must* be executed as *root* user. # 5) When you run the "opatch auto" command, it prompts the user to enter the # OCM (Oracle Configuration Manager) response file path. If the OCM (NOT OCR) # response file is already created in your environment, enter the absolute file # path of the OCM responsefile. Otherwise, you can create the OCM response file # with the command <CRS_HOME>/Opatch/ocm/bin/emocmrsp # 6) Ensure that the directory containing the opatch script appears in # your $PATH. Execute "which opatch" to confirm. # # How does it work : # ================== # The "opatch auto" command stops all the dependent databases and # all CRS resources before applying the patch, stops the CRS stack,applies the # patch to the CRS Home and all applicable RDBMS homes, starts up the CRS stack # and the CRS Resources and databases that were stopped earlier. The automatic # procedure replaces all the previous manual steps which were needed for the # application of the CRS bundle patch. # # # Instructions for installing the patch using the "opatch auto" option: # ===================================================================== # ########################################################################### # # 1. Verify that the Oracle Inventory is properly configured. # # # As the Oracle Clusterware (CRS) software owner: # # % opatch lsinventory -detail -oh <CRS_HOME> # # # As the RDBMS server owner: # # % opatch lsinventory -detail -oh <RDBMS_HOME> # # # This should list the components the list of nodes. # # If the Oracle inventory is not setup correctly this utility will # fail. # ########################################################################### # # 2. Unzip the PSE container file # # % unzip 9294403.zip # ########################################################################### # 3.Apply the patch to the CRS Home and all applicable RDBMS homes. # # % opatch auto <top level directory of unzipped patch> # ########################################################################### # # 4. On success you can determine whether the patch has been installed by # using the following command; # # # As the Oracle Clusterware (CRS) software owner: # # % opatch lsinventory -detail -oh <CRS_HOME> # # # As the RDBMS server owner: # # % opatch lsinventory -detail -oh <RDBMS_HOME> # # # This should list the components the list of nodes. # ########################################################################### # # Patch Deinstallation Instructions: # ================================== # To rollback the patch from the CRS Home and all applicable RDBMS homes, # follow steps 1 and 2 above and invoke the following command # # % opatch auto -rollback <top level directory of unzipped patch> # # Afterwards, continue with step 4 above to complete the procedure. # ########################################################################### # # Additional Command options for "opatch auto": # ============================================= # # To apply to patch to selective list of oracle homes # # % opatch auto <top level directory of unzipped patch> -oh <oraclehome1_path, # oraclehome2_path> # # To rollback patch from selective list of oracle homes # # % opatch auto -rollback <top level directory of unzipped patch> -oh # <oraclehome1_path, #oraclehome2_path> # # To apply patch only to the crs home with CRS stack down # # % opatch auto <top level directory of unzipped patch> -och <crshome_path> # # To rollback patch only from the crs home with CRS stack down # # % opatch auto -rollback <top level directory of unzipped patch> -och # <crshome_path> # # To get help on "opatch auto" # # % opatch auto -h # ############################################################################# # # Known Issues/Restrictions/Workaround with "opatch auto" # ======================================================= # # 1. When "opatch auto" is used with "oh" option to patch/rollback patch only # the crs home, the patch application to crs home succeedes, but it display the # following message after the execution of postrootpatch.sh # # -------------------------------------------------------------------- # verify failure: exit code 256 for srvctl_config_p # # Action failed, do you want to retry it? (y/n/abort/N/N1-N2/help): # -------------------------------------------------------------------- # # Enter "n" and complete the patching process. # # # 2. When the Clusterware Stack is down, you can only patch the Clusterware # Home with "-och" option. The RDBMS homes cannot be patched automatically when # Clusterware stack is down. After the Clusterware home is patched, you can # use the "-oh" option to patch the RDBMS homes. # # # 3. If opatch 10.2.0.4.7 is not installed on all the nodes at same location # then while applying patch, it generates below error message which can be # ignored. # # ---------------------------------------------------------------------- # verify failure: exit code 32512 for cat # # Action failed, do you want to retry it? (y/n/abort/N/N1-N2/help): # --------------------------------------------------------------------- # # Enter "n" and complete the patching process. # # # 4. When using "opatch auto" , if some of the cluster nodes or down,it # generates the following message which can be ignored. # # --------------------------------------------------------------------- # verify failure: exit code 65280 for cat # # Action failed, do you want to retry it? (y/n/abort/N/N1-N2/help): # --------------------------------------------------------------------- # # Enter "n" and complete the patching process. # ########################################################################## # # MANUAL PATCHING # =============== # # Make sure all instances running under the ORACLE_HOME being patched # are cleanly shutdown before installing this patch. Also ensure that # the tool used to terminate the instance(s) has exited cleanly. # # Ensure that the directory containing the opatch script appears in # your $PATH. Execute "which opatch" to confirm. # # CRS_HOME = the full path to the crs home. # RDBMS_HOME = the full path to the server home. # # If the owner of these homes are different ensure you execute the # following steps as the correct owner in the correct environment. # # Configuration A: With a shared CRS Home, a full cluster outage must # be planned. The patch will update the shared copy of the binaries, # and no daemons can be online while the binaries are modified. # # Configuration B: When each node of the cluster has its own CRS Home, # the patch should be applied as a rolling upgrade. All of the following # steps should be followed for each node. Do not patch two nodes at once. # ########################################################################### # # 1. Verify that the Oracle Inventory is properly configured. # # # As the Oracle Clusterware (CRS) software owner: # # % opatch lsinventory -detail -oh <CRS_HOME> # # # As the RDBMS server owner: # # % opatch lsinventory -detail -oh <RDBMS_HOME> # # # This should list the components the list of nodes. # # If the Oracle inventory is not setup correctly this utility will # fail. # ########################################################################### # # 2. Unzip the PSE container file # # % unzip 9294403.zip # ########################################################################### # # 3.1 In configuration A, shut down the RDBMS and ASM instances, listeners # and nodeapps on all nodes before shutting down the CRS daemons on # all nodes. Note that these setps must be run in the order specified. # # 3.1.1 To shutdown RDBMS on all nodes run the following command: # # % $ORACLE_HOME/bin/srvctl stop database -d dbname # # 3.1.2 To shutdown ASM instances run the following command on each node: # # % $ORACLE_HOME/bin/srvctl stop asm -n <node_name> # # 3.1.3 To shutdown nodeapps run the following comand on each node: # # % $ORACLE_HOME/bin/srvctl stop nodeapps -n <node_name> # # 3.1.4 Now shutdown CRS daemons on each node by running as root: # # crsctl stop crs # # 3.1.6 If the oprocd is running, as root stop the oprocd # # % $ORA_CRS_HOME/bin/oprocd stop # # 3.2 In configuration B, shut down the RDBMS and ASM instances, listeners # and nodeapps followed by CRS daemons on the local node. # # 3.2.1 To shutdown RDBMS instance on the local node run the # following command: # # % $ORACLE_HOME/bin/srvctl stop instance -d dbname -i instance_name # # Then run commands (3.1.2) through (3.1.4) mentioned above. Finally # as root, issue the following command to stop the CRS daemons. # # crsctl stop crs # ########################################################################### # # 4. Prior to applying this part of the fix, you must invoke this script # as root to unlock protected files. # # <username> is the software installer/owner for the CRS Home. # # # custom/scripts/prerootpatch.sh -crshome <CRS_HOME> -crsuser <username> # # Note: In configuration A, invoke this only on one node. # # ########################################################################### # # 5. Now invoke an additional script as the crs software installer/owner. # This script will save important configuration settings. # # % custom/scripts/prepatch.sh -crshome <CRS_HOME> # # Note: In configuration A, invoke this only on one node. # # Alert: The RDBMS portion can only be applied to an RDBMS home that # has been upgraded to 10.2.0.4.0. # # If the CRS Version and RDBMS version are the same, # as the RDBMS software owner; # # % custom/server/9294403/custom/scripts/prepatch.sh -dbhome <RDBMS_HOME> # ########################################################################### # # 6. Patch the Files # # 6.1 Patch the CRS home files # # After unlocking any protected files and saving configuration settings # you are now ready to run opatch using the following command. # # As the Oracle Clusterware (CRS) software owner, # from the directory where the patch was unzipped; # # % opatch napply -local -oh <CRS_HOME> -id 9294403 # # Note: In configuration A, invoke this only on one node. # # # 6.2 Patch the RDBMS home files. # # Alert: The RDBMS portion can only be applied to an RDBMS home that # has been upgraded to 10.2.0.4.0. # # For additional information please read Note.363254.1; # Applying one-off Oracle Clusterware patches in a mixed version home # environment # # As the RDBMS software owner, # from the directory where the patch was unzipped; # # % opatch napply custom/server/ -local -oh <RDBMS_HOME> -id 9294403 # # Note: In configuration A, invoke this only on one node. # ########################################################################### # # 7. Configure the HOME # # 7.1 Configure the CRS HOME # # After opatch completes, some configuration settings need to be applied # to the patched files. As the Oracle Clusterware (CRS) software owner # execute the following; # # % custom/scripts/postpatch.sh -crshome <CRS_HOME> # # Note: In configuration A, invoke this only on one node. # # 7.2 Configure the RDBMS HOME # # Alert: The RDBMS portion can only be applied to an RDBMS home that # has been upgraded to 10.2.0.4.0. # # After opatch completes, some configuration settings need to be applied # to the patched files. As the RDBMS software owner execute the following; # # % custom/server/9294403/custom/scripts/postpatch.sh -dbhome <RDBMS_HOME> # # Note: In configuration A, invoke this only on one node. # ########################################################################### # # 8. Now security settings need to be restored on the CRS Home. This script # will also restart the CRS daemons. Invoke this script as root. # # # custom/scripts/postrootpatch.sh -crshome <CRS_HOME> # # Note: This script should only be invoked as part of the patch process. # # Note: In configuration A, invoke this on each node. Do not invoke this # in parallel on two nodes. # ########################################################################### # # 9. On success you can determine whether the patch has been installed by # using the following command; # # # As the Oracle Clusterware (CRS) software owner: # # % opatch lsinventory -detail -oh <CRS_HOME> # # # As the RDBMS server owner: # # % opatch lsinventory -detail -oh <RDBMS_HOME> # # # This should list the components the list of nodes. # ########################################################################### # # Additional Special Notes: # ------------------------- # If there are multiple RDBMS Homes in your configuration, then # in step 6.2, apply the patch to each home before continuing. # # If you later install an additional Server home, or if you skip a # server home, then applying the patch to additional homes is easier. # 1. Shut down all instances using that Server home # 2. Invoke opatch as described in step 6.2. # 3. Restart the instances in that Server home # This can be done while CRS is active. # # ########################################################################### # # Special Instruction for AIX # --------------------------- # # During the application of this PSE should you see any errors with regards # to files being locked or opatch being unable to copy files then this # # could be as result of a process which requires termination or an additional # # file needing to be unloaded from the system cache. # # # To try and identify the likely cause please execute the following commands # # and provide the output to your support representative, who will be able to # # identify the corrective steps. # # # genld -l | grep <CRS_HOME> # # genkld | grep <CRS_HOME> ( full or partial path will do ) # # # Simple Case Resolution: # # If genld returns data then a currently executing process has something open in # the <CRS_HOME> directory, please terminate the process as required/recommended. # # # If genkld return data then please remove the enteries from the # OS system cache by using the slibclean command as root; # # # slibclean # ########################################################################### # # Patch Deinstallation Instructions: # ---------------------------------- # # To roll back the patch, follow all of the above steps 1-5. In step 6, # invoke the following opatch commands to roll back the patch in all homes. # # % opatch rollback -id 9294403 -local -oh <CRS_HOME> # # % opatch rollback -id 9294403 -local -oh <RDBMS_HOME> # # Afterwards, continue with steps 7-9 to complete the procedure. # ########################################################################### # # If you have any problems installing this PSE or are not sure # about inventory setup please call Oracle support. # ###########################################################################
© 2010, www.oracledatabase12g.com. 版权所有.文章允许转载,但必须以链接方式注明源地址,否则追究法律责任.
相关文章 | Related posts:
- Patch 9352164 – 10.2.0.4.4 Patch Set Update Readme
- Patch 9352164 – 10.2.0.4.4 Patch Set Update
- Data Gathering for Troubleshooting CRS Issues
- Diagnosability for CRS / EVM / RACG
- How to Proceed from Failed 11gR2 Grid Infrastructure (CRS) Installation [ID 942166.1]
- ORA-00600 [kcblasm_1] May Occur After Applying The Patch 7523755
- Wrong Results from a RANGE-LIST PARTITIONED TABLE- Bug 5882821
- How to Verify Application of Patch 2896876 (rootpre.sh) on AIX 5L
- Diagnosing Unsuccessful CRS root.sh Issues
最新评论