Patch 9352164 – 10.2.0.4.4 Patch Set Update Readme

Oracle

1 comment to Patch 9352164 – 10.2.0.4.4 Patch Set Update Readme

• admin

  August 31, 2010 at 12:18 PM · Reply

  10.2.0.4.4 CRS Patch Set Update Readme
  #
  #————————————————————————-
  # 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 /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
  #
  #
  # As the RDBMS server owner:
  #
  # % opatch lsinventory -detail -oh
  #
  #
  # 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
  #
  ###########################################################################
  #
  # 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
  #
  #
  # As the RDBMS server owner:
  #
  # % opatch lsinventory -detail -oh
  #
  #
  # 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
  #
  # 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 -oh # oraclehome2_path>
  #
  # To rollback patch from selective list of oracle homes
  #
  # % opatch auto -rollback -oh
  #
  #
  # To apply patch only to the crs home with CRS stack down
  #
  # % opatch auto -och
  #
  # To rollback patch only from the crs home with CRS stack down
  #
  # % opatch auto -rollback -och
  #
  #
  # 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
  #
  #
  # As the RDBMS server owner:
  #
  # % opatch lsinventory -detail -oh
  #
  #
  # 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
  #
  # 3.1.3 To shutdown nodeapps run the following comand on each node:
  #
  # % $ORACLE_HOME/bin/srvctl stop nodeapps -n
  #
  # 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.
  #
  # is the software installer/owner for the CRS Home.
  #
  # # custom/scripts/prerootpatch.sh -crshome -crsuser
  #
  # 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
  #
  # 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
  #
  ###########################################################################
  #
  # 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 -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 -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
  #
  # 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
  #
  # 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
  #
  # 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
  #
  #
  # As the RDBMS server owner:
  #
  # % opatch lsinventory -detail -oh
  #
  #
  # 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
  #
  # genkld | grep ( full or partial path will do )
  #
  #
  # Simple Case Resolution:
  #
  # If genld returns data then a currently executing process has something open in
  # the 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
  #
  # % opatch rollback -id 9294403 -local -oh
  #
  # 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.
  #
  ###########################################################################

Copyright © 2012 Oracle Clinic – Maclean Liu的个人技术博客 - All Rights Reserved
Powered by WordPress & Atahualpa