主题:	Oracle Clusterware: Patch installation
	文档 ID:	557934.1	类型:	REFERENCE
	Modified Date:	30-JUL-2009	状态:	PUBLISHED

In this Document
Purpose
Scope
Oracle Clusterware: Patch installation
How Oracle Clusterware is Different from the RDBMS
Types of patches
Applying PatchSets
Applying Bundle Patches (CRSBP/MLR)
Conclusion
References

---

Applies to:

Oracle Server - Enterprise Edition - Version: 10.1.0.4 to 11.1.0.6
Information in this document applies to any platform.
Oracle Server Enterprise Edition - Version: 10.1.0.4 to 11.1.0.6

Purpose

This document explains the considerations and concepts needed to apply a patch (bundle patch or patch set). It also documents the generic steps followed when Oracle Clusterware (CRS) is patched.

This note also describes the different components present when CRS is installed and how these are updated while patching.

This note is intended for patch installation on Unix. Please check Note 743126.1 for patch installations on Windows platforms.

Scope

This note lists the generic steps to apply a patch and clarifies how the Oracle Clusterware components are updated through patching.

Please note that this article is meant as a supplement and not as a replacement for the README for any patch. This information should prove helpful for troubleshooting potential issues encountered while patching.

Oracle Clusterware: Patch installation

How Oracle Clusterware is Different from the RDBMS

Before going to the main topic, lets take some time to understand which parts or components are included in a typical Oracle Clusterware installation on Unix. Included is just a brief explanation for those components that will be touched when a patch is installed. For more details please consult Note 556976.1.

When Oracle Clusterware is installed, there are some components (such as daemons, files, or directories) that belong to root and others that belong to the user under which CRS has been installed (referred to as the Oracle user for the remainder of this document). Here are those components:

Component	Purpose/Location	Owner
Daemons	These are the processes providing the different services, all of them are located under $CRS_HOME	crsd* is the only file that belongs to root
Wrappers (or Scripts)	Those are shell scripts used to run the real executables,daemons and other commands like crs_* , mainly to set the correct environment. These files are located under the $CRS_HOME/bin.	Some of them belongs to root and others to the oracle user
Scripts init.* (init.cssd, init.crsd, etc)	The location depends on the Unix flavor,on Linux they are located under /etc/init.d. These files are used to start the daemons (aka CRS stack).	root is the owner of the files
inittab entries	Here is where the scripts init.* are registered. Oracle Clusterware is started by init.	/etc/inittab belongs to root
libraries and executables	As any other Oracle installation we have libraries and some other executables. The former are under $CRS_HOME/lib and the later under $CRS_HOME/bin	Most of the libraries are owned by oracle, but some by root.
oraInventory and inventory	For any Oracle product we have those two parts. The oraInventory can be under any location. But the inventory is located under $CRS_HOME	Both are owned by oracle.

It is worth reiterating that there are components of CRS that belong to root and others that belong to oracle. Also, note that we have some parts of the Oracle Clusterware installation contained elsewhere than in the $CRS_HOME.

This is a significant difference compared to the RDBMS (or RAC) home and is the main reason why we need additional steps when patching Oracle Clusterware. Traditionally, the Oracle Universal Installer (OUI) and OPatch can only operate on files which are owned by oracle.

Types of patches

Related to Oracle Clusterware we have the following types of patches:

• Patch sets

This is a consolidated set of patches provided on top of a base release (Eg. 10.2.0.1 or 11.1.0.6). The patch set currently includes the fixes relevant for both the RDBMS (or RAC) and CRS homes.

Note that patch sets are cumulative (each patchset contains its own fixes plus the fixes of any patchsets that precede it). Application of a patchset increments the fourth digit of the release.

• Bundle patches.

Since 10.1.0.4, bundle patches have been provided for CRS. Since 10.2.0.3 there are two types of bundle patches provided which may cause some confusion.

First and foremost these bundle patches for Oracle Clusterware (or CRS) are fixes for the Oracle Clusterware (CRS) only. Having said that, when the RDBMS (or RAC) home is the same version as the Oracle Clusterware, then there is a component in the bundle patch that can be applied to the RDBMS ORACLE_HOME. Therefore, if we have a mixed configuration where the Oracle Clusterware is on release X and the RDBMS is on release Y, then the bundle patch should not be applied to the RDBMS installation.

Another important feature of these bundle patches is that they are applied using the OPatch patching utility, therefore, in order to apply bundle patches successfully, we will need to take additional steps to prepare the components listed above owned by root, to allow the oracle user to modify them.

It is advisable to use the latest opatch version available (see the opatch faq Note 242993.1).

Currently, if a customer needs a patch for Oracle Clusterware, the request will be grouped with others, made around the same time, and the patch will be merged with the previous bundle patch (either CRSBP# MLR# or MLR#).

We can find these type of bundle patches:

1. CRSBP#n (CRS Bundle Patch). Those were initially introduced in 10.1.0.4.0 (Eg. CRSBP#1 for 10.2.0.4.0). Development periodically takes the decision of which CRS fixes will be included on each CRSBP.
2. MLR#n. These are merges including several CRS patches and were introduced in 10.2.0.3.0. These patches are cumulative, this means that the patches that exist in MLR#7 are included in MLR#8 as well. Note that the MLR patches were created on top of a patchset or a full release, but they are not related to a CRSBP.
3. CRSBP#n MLR#n. These are merges of CRS patches, but created on top of a CRSBP#n.

You need to keep in mind that a MLR#n patch cannot be merged with a CRSBP#.

At this point you may ask which one you need to install. Well, as many other things, this depends. Here is some information about those:

• CRSBP# is more tested than a MLR#
• CRSBP#n has many more fixes than a MLR#n .
• A CRSBP#n is preferred over the MLR# patch. But the later contains the most recently fixes.
• If you need a fix and is present on both bundles then use CRSBP#
• If you need a fix that is in a MLR# but not in a CRSBP#, then either apply the MLR# or request a merge on top of the CRSBP#.
• If there is no need for a specific patch then install the CRSBP#

Applying PatchSets

Special Considerations

Some important considerations before installing the patchsets on top of the Oracle Clusterware:

1. As mentioned previously, currently patchsets contain fixes for both Oracle Clusterware and RDBMS(RAC) homes. So one need only download one file from Metalink.
2. To install the patchset on either the Oracle Clusterware or RDBMS installation you just need to choose the correct ORACLE_HOME in OUI.
3. Because it is required to run a CRS version that is the same or higher than your RDBMS(RAC) version, you must always apply any patchset (or patch) to the Oracle Clusterware home first.
4. Applying a patchset to a CRS home can be accomplished in a rolling fashion. This means that the patch can be applied on one node at a time.
5. Read the complete README file included with the patchset for details about contents and installation.
6. At the end of the patchset installation, root102.sh must be executed even when the installer was executed using silent mode.

How components will be modified

When the patchset is installed, initially the installer (runInstaller or OUI) will only copy the new binaries and libraries under the directory $CRS_HOME:/install/patch (Eg. patch102). Thus, Oracle Clusterware can be running while the OUI is running / installing the new binaries, which includes propagating the files to the rest of the nodes and updating the oraInventory.

Note that the correct values for the variables in the wrappers (or shell scripts) are also updated at this time.

At the end of the OUI session, a screen is presented, prompting you to stop CRS and execute root102.sh (located under $CRS_HOME/install) on each node in turn. Running this script will:

1. Verifies that we have the correct $CRS_HOME
2. Confirms that the daemons for Oracle Clusterware are stopped
3. Creates a copy of the current binaries and libraries under $CRS_HOME/install/prepatch (Eg. prepatch10204)
4. Move the new files from $CRS_HOME/install/patch to the correct location under the $CRS_HOME
5. Reapply the permissions for the executables (Eg. crsd.bin must belong to root) and directories
6. Remove and add the entries in /etc/inittab after the correct scripts init.* (Eg. init.cssd) are copied to the correct location (Eg. /etc/init.d)
7. Execute ocrcheck, before attempting to start Oracle Clusterware
8. Start Oracle Clusterware

As you can see, the root102.sh script will update the current installation. If this script is not executed, then Oracle Clusterware will remain in the previous release, even if OPatch or OUI reports that the patchset has been successfully installed.

Patchset installation StepsThe required steps when applying a patchset are:

1. Download the patchset from Metalink and uncompress the file to any directory
2. Start OUI (or runInstaller)
3. Specify the ORACLE_HOME where CRS is installed
4. The list of nodes will be displayed
5. The Summary screen is shown
6. After the software is installed and propagated to the nodes you will get a screen which indicates to execute the following steps on each node:
   • Stop CRS
   • while logged in as root, execute the script $CRS_HOME/install/root102.sh

Remember that if root102.sh is not executed, then CRS will continue running on the older version. One way to confirm that you're using the new version is by running 'crsctl query crs activeversion':

Or check the version for the daemons as per their log files located under $CRS_HOME/log//*.

Applying Bundle Patches (CRSBP/MLR)

Special Considerations

Here are some important point to keep in mind when a Bundle Patch is installed:

1. The CRS executables are not relinked (unlike RDBMS executables). Actually, only some shared libraries can be relinked (Eg. libclntsh.*).
2. A Bundle Patch is applied using the OPatch utility, which must be executed as the user oracle. This is the main reason why we need to execute some scripts before and after the execution of OPatch. These scripts prepare the components to ready them for updating and restore their state (permissions, contents, etc) at the end of the patch application.
3. These patches contain additional components for the RDBMS, which should be applied only if the RDBMS and Oracle Clusterware have the same version. Therefore, normally we will need to execute OPatch at least two times, once for each ORACLE_HOME.
4. Normally Bundle Patches can be applied in a rolling fashion, to accomplish this, you will notice that the patch README recommends to execute OPatch using the -local parameter.
5. In the most recent Bundle Patches, it's required to use OPatch with the option napply instead of apply. This is because the CRS patches may include shared libraries and only the more recent versions of OPatch execute a modified verification step, which is executed after the shared libraries are regenerated. These changes produce errors when the patch is applied to the RDBMS ORACLE_HOME. Check the README for further details.

How Components are updated

As mentioned before, we need to run some scripts before and after the OPatch execution. Remember that the oraInventory belongs to the Oracle user. Thus the scripts are needed, so that the patch can be installed. Here is a brief description of these scripts, which help to modify the different Oracle Clusterware components, listed in the same order as they are listed in the Bundle Patch README:

1. prerootpatch.sh. This script:
   • Confirms that the script is executed as root
   • Checks that the correct parameters were specified correctly (CRS_HOME and owner of the installation)
   • Verifies that the Oracle Clusterware is stopped on the local node
   • Unlocks the CRS_HOME setting ownership to the Oracle user and changes permissions for some files
2. prepatch.sh is executed once per each ORACLE_HOME, but there are two different scripts, one for the CRS_HOME and the other for the RDBMS ORACLE_HOME. The script basically:
   • Checks that the parameters are correct
   • Changes the permissions to some files (Eg. crs_stat, etc)
   • Searchs for the variables, already included in certain files during the installation (Eg. rootconfig,racgwrap) or when running commands like olsnodes and crsctl
   • Verifies that the values for the variables were obtained
   • Saves the variables and their values in the file $CRS_HOME/install/params.crs. This information is needed to restore the variables in the scripts (wrappers and init.*)
3. postpatch.sh. At this point OPatch has already replaced the files (scripts, executables, and libraries). As with the previous script, this one is executed one per each ORACLE_HOME. We also have two different versions, one for the CRS_HOME and one for the RDBMS ORACLE_HOME. This script:
   • Verifies that the file params.crs has the correct format
   • Parses and replaces the correct values for the variables included in the params.crs file
   • Resets the permissions for some files
4. postrootpatch.sh. This is the last script executed, until now all the new files updated under the $CRS_HOME should have the correct information. When this script is run, the rest of the files that exist in the $CRS_HOME are replaced. Running postrootpatch.sh:
   • Locks the executables and directories, changing the ownership to root
   • Copies the scripts init.* (Eg init.cssd) to the correct location (Eg. /etc/init.d/).
   • Updates the /etc/inittab so that the new files are used to start Oracle Clusterware.
   • Waits for Oracle Clusterware to start

If for some reason, the patch needs to be deinstalled (which requires OPatch execution) then the same scripts must be run. For further details, refer to the Bundle Patch README.

@ If the patch fails for any reason, it's fine to execute it again.

Patch Installation

This section provides a general outline of the patching steps, most of which were already mentioned above. For additional details about the parameters mentioned, check the README included in the Bundle Patch:

1. Ensure that OPatch can access the oraInventory for the Oracle Clusterware and RDBMS installation
2. Stop the CRS managed resources (DB, ASM, NODEAPPS) on the node along with Oracle Clusterware
3. Run prerootpatch.sh as root to unlock the Oracle Clusterware
4. Run prepatch.sh against the Oracle Clusterware installation
5. Run prepatch.sh against the RDBMS ORACLE_HOMES if they the same version as the Oracle Clusterware
6. Install the patch running OPatch against the Oracle Clusterware home and the RDBMS ORACLE_HOME
7. Execute postpatch.sh against the Oracle Clusterware installation.
8. Run postrootpatch.sh to lock the Oracle Clusterware

To verify that the installation was successful, you can execute OPatch and list the oraInventory for the ORACLE_HOME(s) you have patched.

Conclusion

An Oracle Clusterware installation is different than the RDBMS installation; in the way the software is installed and the different components created, etc. Because of this, patchset installations and/or bundle patch applications require additional steps.

This note discussed different Oracle Clusterware components and mentioned special considerations aimed at providing a clear idea of the whole patch installation process.

References

Note 259301.1 - CRS and 10g Real Application Clusters
Note 399031.1 - Step by step installation of Oracle Clusterware one-off and bundle patches for 10.1 and 10.2
Note 405820.1 - 10.2.0.X CRS Bundle Patch Information
Note 556976.1 - Oracle Clusterware: Components installed.
Note 743126.1 - RAC on Windows: How to Apply Oracle Windows Mini Patch Bundles in a Rolling Fashion
Note 242993.1 - OPATCH FAQ

安装的组件介绍：

主题:	Oracle Clusterware: Components installed.
	文档 ID:	556976.1	类型:	REFERENCE
	Modified Date:	19-DEC-2008	状态:	PUBLISHED

In this Document
Purpose
Scope
Oracle Clusterware: Components installed.
What is the Oracle Clusterware?
Components.
Components creation.

Conclusion.
References

---

Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.3 to 11.1.0.6
Information in this document applies to any platform.

Purpose

This document is aimed to explain the different parts of the Oracle Clusterware (sometimes also referred to as Cluster Ready Services or CRS) created during a typical installation on Unix. This note can be considered as an introduction for other available notes that deal with Oracle Clusterware.

Scope

This document is meant as a supplement to and not a replacement of the installation documentation for Oracle Clusterware.

Oracle Clusterware: Components installed.

What is the Oracle Clusterware?

The Oracle Clusterware was introduced in 10.1 (initially called CRS ) and is the product that lies under RAC. Oracle Clusterware provides different services to RAC including:

- Group Services
- Node Monitor
- Locking services
- HA Resource management
- Event framework, etc

Oracle Clusterware is different compared to RAC (or RDBMS) and thus its components are different as well.

Components.

Several components are needed to have CRS running on Unix machine. Here is a brief description of each:

1. Daemons and init.* scripts

Oracle Clusterware is formed of several daemons, each one of which have a special function inside the stack. The daemons are located inside the directory $CRS_HOME/bin. Here is a list of the
daemons, for 10.2.0.3 and later, note that depending on the platform and whether or not there is a 3rd-party vendor clusterware installed, some of the following processes may not be present:

When the daemons are running, we can say that CRS is fully started. Daemons are executed via the init.* scripts (init.cssd, init.crsd and init.evmd). Note that we do not have as many init.* scripts as we have daemons, this is because init.cssd starts more than one daemon:

Note that some links for the scripts exist under rc.d which are used to manipulate the control files (see point 3), which at the end will help to start and stop the whole stack.

2. Oracle Cluster Registry (OCR) and Voting Disk (VD)

The OCR contains the configuration information for the clusterware, like the network endpoints where the daemons (ocssd.bin, crsd.bin,etc) will be listening, cluster interconnect information for RAC, location for VD, etc.

The VD is a communication mechanism where every node reads and writes its heartbeat information. The VD is also used to kill the node(s) when the network communication is lost between one or several nodes in the cluster to prevent a split-brain and protect the database information.

3. Control files (also know as SCLS_SRC files)

These files are used to control some aspects of Oracle Clusterware like:

In a Linux installation those files are located as follows:

The control files must not be manipulated manually, some files are changed via init.cssd or crsctl and the location can differ depending on the Unix OS (Linux, Solaris, etc).

4. inittab entries

In order to start the Oracle Clusterware daemons, the init.* scripts first need to be run. These scripts are executed by the daemon init. To accomplish this some entries must be created in the file /etc/inittab.

These are:

Note: Check the manual for a detailed description of each field

Some important clarifications:

a. Stopping Oracle Clusterware will stop the daemons (ocssd.bin, crsd.bin, etc) but the init.* scripts will remain running.
b. The init.* are needed to start Oracle Clusterware manually (this was introduced in 10.1.0.4)
c. if the scripts init.* are not running then the daemons will not be started.
d. it's not supported to execute the scripts init.* manually.

5. Wrappers.

The wrappers are shell scripts created under the $CRS_HOME/bin, which are used to set the correct environment variables such as: CRS_HOME, LD_LIBRARY_PATH, etc, and run the real executables.

The daemons and other tools are executed in such a way. One example is ocssd:

#!/bin/sh

ORA_CRS_HOME=/u01/64bit/A203/crs
ORACLE_HOME=$ORA_CRS_HOME
export ORA_CRS_HOME ORACLE_HOME

case `/bin/uname` in
Linux) LD_LIBRARY_PATH=$ORA_CRS_HOME/lib
export LD_LIBRARY_PATH
;;
..
case $0 in
*.bin) exec $ORA_CRS_HOME/bin/`basename $0 .bin` "$@" ;;
*) exec $0.bin "$@" ;;
esac

As can be seen, ocssd sets the environment and will call ocssd.bin. During the installation, these scripts are parsed and the correct values for the variables are set.

Components creation.

When exactly during the installation process are these components created? The Installation manual contains a complete list of installation requirements that must be fulfilled even before invoking the Installer
(runInstaller). This can prevent a lot of potential issues with installation.

After fulfilling the pre-installation requirements, the basic installation steps to follow are:

1. Invoke the Oracle Universal Installer (OUI)

2. Enter the different information for some components like:

- name of the cluster
- public and private node names
- location for OCR and Voting Disk
- network interfaces used for RAC instances
-etc.

3. After the Summary screen, OUI will start copying under the $CRS_HOME (this is the $ORACLE_HOME for Oracle Clusterware) in the local node the libraries and executables.

- here we will have the daemons and scripts init.* created and configured properly.

- note that for CRS only some client libraries are recreated, but not all the executables (as for the RDBMS).

4. Later the software is propagated to the rest of the nodes in the cluster and the oraInventory is updated.

5. The installer will ask to execute root.sh on each node. Until this step the software for Oracle Clusterware is inside the $CRS_HOME. Running root.sh will create several components outside the $CRS_HOME:

- OCR and VD will be formated

- control files (or SCLS_SRC files ) will be created with the correct contents to start Oracle Clusterware.

- /etc/inittab will be updated and the init process is notified

- the different processes init.* (init.cssd, init.crsd, etc) will start the daemons (ocssd.bin, crsd.bin, etc). When all the daemons are running then we can say that the installation was successful

- On 10.2 and later, running root.sh on the last node in the cluster also will create the nodeapps (VIP, GSD and ONS). On 10.1, VIPCA is executed as part of the RAC installation.

Note that root.sh MUST be executed on each node at a time and after the installation is finished successfully root.sh must not be executed again. If an error is produced and
Oracle Clusterware is not fully started then is valid to execute root.sh again.

6. After running root.sh on each node, we need to continue with the OUI session. After pressing the 'OK' button OUI will include the information for the public and cluster_interconnect interfaces. Also CVU (Cluster Verification Utility) will be executed.

Conclusion.

Oracle Clusterware is different than the RDBMS and as such it's important to keep in mind the different parts needed and created during a typical installation on a Unix OS. Note that this document is not a replacement for the Installation manual, which includes the complete information for the installation of the product. Anyone preparing to install Oracle Clusterware must follow the Installation Manual and ensure that the requirements are in place, before starting the OUI.

References

Keywords

INSTALLATION; OCR; RAC; SPLIT-BRAIN; CLUSTERWARE; CRS;[@more@]