7715304

#
#-------------------------------------------------------------------------
#  BUNDLE Patch for Base Bug 7715304
#-------------------------------------------------------------------------
#
#  DATE: 6:21:29 Feb 18 2009
#  -------------------------------
#  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.3.3 or later.
#      You can download it from OracleMetaLink with patch 4898608.
#      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:
#  ================================
#
#  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 7715304.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/7715304/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 7715304
#
#    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 7715304
#
#    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/7715304/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 7715304 -local -oh
#
#  % opatch rollback -id 7715304 -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.
#
###########################################################################

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/66233/viewspace-691952/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/66233/viewspace-691952/