A Cluster Verification Utility Reference

Installation Requirements

CVU installation requirements are:

• At least 30 MB free space for the CVU software on the node from which you run CVU

• A work directory with at least 25 MB free space on each node. The default location of the work directory is /tmp on Linux and UNIX systems, and the value specified in the TEMP environment variable on Windows systems. You can specify a different location by setting the CV_DESTLOC environment variable.

  When using CVU, the utility attempts to copy any needed information to the CVU work directory. It checks for the existence of the work directory on each node. If it does not find one, then it attempts to create one. Make sure that the CVU work directory either exists on all nodes in your cluster or proper permissions are established on each node for the user running CVU to create that directory.

Usage Information

CVU includes two scripts: runcluvfy.sh (runcluvfy.bat on Windows), which you use before installing Oracle software, and cluvfy (cluvfy.bat on Windows), located in the Grid_home/bin directory. The runcluvfy.sh script contains temporary variable definitions which enable it to run before you install Oracle Grid Infrastructure or Oracle Database. After you install Oracle Grid Infrastructure, use the cluvfy command to check prerequisites and perform other system readiness checks.

Before installing Oracle software, run runcluvfy.sh from the mountpoint path of the software installation media, as follows:

cd /mountpoint
./runcluvfy.sh options

In the preceding example, the options variable represents CVU command options that you select. For example:

$ cd /mnt/dvdrom
$ ./runcluvfy.sh comp nodereach -n node1,node2 -verbose

When you enter a CVU command, it provides a summary of the test. During preinstallation, Oracle recommends that you obtain detailed output by using the -verbose argument with the CVU command. The -verbose argument produces detailed output of individual checks. Where applicable, it shows results for each node in a tabular layout.

Run the CVU command-line tool using the cluvfy command. Using cluvfy does not adversely affect your cluster environment or your installed software. You can run cluvfy commands at any time, even before the Oracle Clusterware installation. In fact, CVU is designed to assist you as soon as your hardware and operating system are operational. If you run a command that requires Oracle Clusterware on a node, then CVU reports an error if Oracle Clusterware is not yet installed on that node.

The node list that you use with CVU commands should be a comma-delimited list of host names without a domain. CVU ignores domains while processing node lists. If a CVU command entry has duplicate node entries after removing domain information, then CVU eliminates the duplicate node entries.

For network connectivity verification, CVU discovers all of the available network interfaces if you do not specify an interface on the CVU command line. For storage accessibility verification, CVU discovers shared storage for all of the supported storage types if you do not specify a particular storage identification on the command line. CVU also discovers the Oracle Clusterware home if one is available.

CVU Configuration File

You can use the CVU configuration file to define specific inputs for the execution of CVU. The path for the configuration file is Grid_home/cv/admin/cvu_config (or Staging_area\clusterware\stage\cvu\cv\admin on Windows platforms). You can modify this file using a text editor. The inputs to CVU are defined in the form of key entries. You must follow these rules when modifying the CVU configuration file:

• Key entries have the syntax name=value

• Each key entry and the value assigned to the key only defines one property

• Lines beginning with the number sign (#) are comment lines and are ignored

• Lines that do not follow the syntax name=value are ignored

The following is the list of keys supported by CVU:

• CV_NODE_ALL: If set, it specifies the list of nodes that should be picked up when Oracle Clusterware is not installed. By default, this entry is commented out.

• CV_ORACLE_RELEASE: If set, it specifies the specific Oracle release (10.1, 10.2, 11.1, 11.2, or 12.1) for which the verifications have to be performed. If set, you do not have to use the -r release option wherever it is applicable. The default value is 12.1.

• CV_RAW_CHECK_ENABLED: If set to TRUE, it enables the check for accessibility of shared disks on Linux and UNIX systems. This shared disk accessibility check requires that you install the cvuqdisk RPM Package Manager (rpm) on all of the nodes. By default, this key is set to TRUE and shared disk check is enabled.

• CV_ASSUME_DISTID: This property is used in cases where CVU cannot detect or support a particular platform or a distribution. Oracle does not recommend that you change this property as this might render CVU non-functional.

• CV_XCHK_FOR_SSH_ENABLED: If set to TRUE, it enables the X-Windows check for verifying user equivalence with ssh. By default, this entry is commented out and X-Windows check is disabled.

• ORACLE_SRVM_REMOTECOPY: If set, it specifies the location for the scp or rcp command to override the CVU default value. By default, this entry is commented out and CVU uses /usr/bin/scp and /usr/sbin/rcp.

• ORACLE_SRVM_REMOTESHELL: If set, it specifies the location for ssh command to override the CVU default value. By default, this entry is commented out and the tool uses /usr/sbin/ssh.

• CV_ASSUME_CL_VERSION: By default, the command line parser uses crs activeversion for the display of command line syntax usage and syntax validation. Use this property to pass a version other than crs activeversion for command line syntax display and validation. By default, this entry is commented out.

If CVU does not find a key entry defined in the configuration file, then CVU searches for the environment variable that matches the name of the key. If the environment variable is set, then CVU uses its value, otherwise CVU uses a default value for that entity.

Privileges and Security

Because of a lack of user equivalence for the root user, most CVU commands cannot be run as root to perform any remote node operations, except for the following:

• cluvfy comp dhcp

• cluvfy comp dns

However, using privilege delegation, you can specify the -method parameter and choose one of two methods (sudo or root) to enable the checks and run the fixup scripts that require root privileges to be performed on remote nodes. You will be prompted for a password but the password is used dynamically while the CVU commands run, rather than being stored on a storage device.

Specifying the -method parameter is advantageous in the context of fixup scripts. If you choose privilege delegation, then all the fixup scripts can be run at one time from the local node. If you do not choose privilege delegation, then you must log onto each relevant node as root and run the fixup script.

Using CVU Help

The cluvfy commands have context sensitive help that shows their usage based on the command-line arguments that you enter. For example, if you enter cluvfy, then CVU displays high-level generic usage text describing the stage and component syntax. The following is a list of context help commands:

• cluvfy -help: CVU displays detailed CVU command information.

• cluvfy -version: CVU displays the version of Oracle Clusterware.

• cluvfy comp -list: CVU displays a list of components that can be checked, and brief descriptions of how the utility checks each component.

• cluvfy comp -help: CVU displays detailed syntax for each of the valid component checks.

• cluvfy stage -list: CVU displays a list of valid stages.

• cluvfy stage -help: CVU displays detailed syntax for each of the valid stage checks.

You can also use the -help option with any CVU command. For example, cluvfy stage -pre nodeadd -help returns detailed information for that particular command.

If you enter an invalid CVU command, then CVU shows the correct usage for that command. For example, if you type cluvfy stage -pre dbinst, then CVU shows the correct syntax for the precheck commands for the dbinst stage. Enter the cluvfy -help command to see detailed CVU command information.

Generating Fixup Scripts

You can use the -fixup flag with certain CVU commands to generate fixup scripts before installation. Oracle Universal Installer can also generate fixup scripts during installation. The installer then prompts you to run the script as root in a separate terminal session. If you generate a fixup script from the command line, then you can run it as root after it is generated. When you run the script, it raises kernel values to required minimums, if necessary, and completes other operating system configuration.

Alternatively, you can specify the -method parameter with certain CVU commands to enable privilege delegation and enable you to run fixup scripts as root on remote nodes from the local node.

Using CVU to Determine if Installation Prerequisites are Complete

You can use CVU to determine which system prerequisites for installation are completed. Use this option if you are installing Oracle Database 12c software on a system with a pre-existing Oracle software installation. In using this option, note the following:

• You must run CVU as the user account you plan to use to run the installation. You cannot run CVU as root, and running CVU as another user other than the user that is performing the installation does not ensure the accuracy of user and group configuration for installation or other configuration checks.

• Before you can complete a clusterwide status check, SSH must be configured for all cluster nodes. You can use the installer to complete SSH configuration, or you can complete SSH configuration yourself between all nodes in the cluster. You can also use CVU to generate a fixup script to configure SSH connectivity.

• CVU can assist you by finding preinstallation steps that must be completed, but it cannot perform preinstallation tasks.

Use the following syntax to determine what preinstallation steps are completed, and what preinstallation steps you must perform; running the command with the -fixup flag generates a fixup script to complete kernel configuration tasks as needed:

$ ./runcluvfy.sh stage -pre crsinst -fixup -n node_list

In the preceding syntax example, replace the node_list variable with the names of the nodes in your cluster, separated by commas. On Windows, you must enclose the comma-delimited node list in double quotation marks ("").

For example, for a cluster with mountpoint /mnt/dvdrom/, and with nodes node1, node2, and node3, enter the following command:

$ cd /mnt/dvdrom/
$ ./runcluvfy.sh stage -pre crsinst -fixup -n node1,node2,node3

Review the CVU report, and complete additional steps as needed.

Using CVU with Oracle Database 10g Release 1 or 2

You can use CVU included on the Oracle Database 12c media to check system requirements for Oracle Database 10g release 1 (10.1) and later installations. To use CVU to check Oracle Clusterware installations, append the command -r release_code flag to the standard CVU system check commands.

For example, to perform a verification check before installing Oracle Clusterware version 10. 2 on a system where the media mountpoint is /mnt/dvdrom and the cluster nodes are node1, node2, and node3, enter the following command:

$ cd /mnt/dvdrom
$ ./runcluvfy.sh stage -pre crsinst -n node1,node2,node3 -r 10.2

Entry and Exit Criteria

When verifying stages, CVU uses entry and exit criteria. Each stage has entry criteria that define a specific set of verification tasks to be performed before initiating that stage. This check prevents you from beginning a stage, such as installing Oracle Clusterware, unless you meet the Oracle Clusterware prerequisites for that stage.

The exit criteria for a stage define another set of verification tasks that you must perform after the completion of the stage. Post-checks ensure that the activities for that stage have been completed. Post-checks identify stage-specific problems before they propagate to subsequent stages.

Verbose Mode and UNKNOWN Output

Although by default CVU reports in nonverbose mode by only reporting the summary of a test, you can obtain detailed output by using the -verbose argument. The -verbose argument produces detailed output of individual checks and where applicable shows results for each node in a tabular layout.

If a cluvfy command responds with UNKNOWN for a particular node, then this is because CVU cannot determine whether a check passed or failed. The cause could be a loss of reachability or the failure of user equivalence to that node. The cause could also be any system problem that was occurring on that node when CVU was performing a check.

The following is a list of possible causes for an UNKNOWN response:

• The node is down

• Executables that CVU requires are missing in Grid_home/bin or the Oracle home directory

• The user account that ran CVU does not have privileges to run common operating system executables on the node

• The node is missing an operating system patch or a required package

• The node has exceeded the maximum number of processes or maximum number of open files, or there is a problem with IPC segments, such as shared memory or semaphores

CVU Node List Shortcuts

To provide CVU a list of all of the nodes of a cluster, enter -n all. CVU attempts to obtain the node list in the following order:

1. If vendor clusterware is available, then CVU selects all of the configured nodes from the vendor clusterware using the lsnodes utility.

2. If Oracle Clusterware is installed, then CVU selects all of the configured nodes from Oracle Clusterware using the olsnodes utility.

3. If neither the vendor clusterware nor Oracle Clusterware is installed, then CVU searches for a value for the CV_NODE_ALL key in the configuration file.

4. If vendor clusterware and Oracle Clusterware are not installed and no key named CV_NODE_ALL exists in the configuration file, then CVU searches for a value for the CV_NODE_ALL environmental variable. If you have not set this variable, then CVU reports an error.

To provide a partial node list, you can set an environmental variable and use it in the CVU command. For example, on Linux or UNIX systems you can enter:

setenv MYNODES node1,node3,node5
cluvfy comp nodecon -n $MYNODES [-verbose]

Syntax

cluvfy comp acfs [-n node_list] [-f file_system] [-verbose]

Parameters

-n node_list

-f file_system

-verbose

Syntax

On Linux and UNIX platforms:

cluvfy comp admprv [-n node_list] -o user_equiv [-sshonly] |
  -o crs_inst [-asmgrp asmadmin_group] [-asmdbagrp asmdba_group] [-orainv orainventory_group]
  [-fixup] [-fixupnoexec] [-method {sudo -user user_name [-location directory_path] | root}] 
  | -o db_inst [-osdba osdba_group] [-fixup] [-fixupnoexec]
  [-method {sudo -user user_name [-location dir_path] | root}] | 
  -o db_config -d oracle_home [-fixup] [-fixupnoexec]
  [-method {sudo -user user_name [-location directory_path] | root}] [-verbose]

On Windows platforms:

cluvfy comp admprv [-n node_list] | -o user_equiv | -o crs_inst [-fixup] [-fixupnoexec]
  | -o db_inst [-fixup] [-fixupnoexec] | -o db_config -d oracle_home [-fixup] [-fixupnoexec]
 [-verbose]

Parameters

-n node_list

-o user_equiv [-sshonly]

-o crs_inst [-asmgrp asmadmin_group]
[-asmdbagrp asmdba_group]
[-orainv orainventory_group]

-o db_inst [-osdba osdba_group]

-o db_config -d oracle_home

-fixup

-fixupnoexec

-method {sudo -user user_name
 [-location dir_path] | root}

-verbose

Usage Notes

• By default, the equivalence check does not verify X-Windows configurations, such as whether you have disabled X-forwarding, whether you have the proper setting for the DISPLAY environment variable, and so on.

  To verify X-Windows aspects during user equivalence checks, set the CV_XCHK_FOR_SSH_ENABLED key to TRUE in the configuration file that resides in the CV_HOME/cv/admin/cvu_config directory before you run the cluvfy comp admprv -o user_equiv command.

Examples

Example 1: Verifying Permissions Required to Install Oracle Clusterware

You can verify that the permissions required for installing Oracle Clusterware have been configured on the nodes racnode1 and racnode2 by running the following command:

cluvfy comp admprv -n racnode1,racnode2 -o crs_inst -verbose

Example 1: Verifying Permissions Manage Oracle RAC Databases

You can verify that the permissions required for creating or modifying an Oracle RAC database using the C:\app\oracle\product\11.2.0\dbhome_1 Oracle home directory, and generate a script to configure the permissions by running the following command:

cluvfy comp admprv -n racnode1,racnode2 -o db_config -d C:\app\oracle\product\11.2.0\dbhome_1 -fixup -verbose

Syntax

cluvfy comp asm [-n node_list] [-verbose]

Parameters

-n node_list

-verbose

Examples

Verifying the Integrity of Oracle ASM on All Nodes

To verify the integrity of Oracle ASM on all of the nodes in the cluster, use the following command:

cluvfy comp asm –n all

This command produces output similar to the following:

Verifying ASM Integrity

Task ASM Integrity check started...

Starting check to see if ASM is running on all cluster nodes...

ASM Running check passed. ASM is running on all specified nodes

Starting Disk Groups check to see if at least one Disk Group configured...
Disk Group Check passed. At least one Disk Group configured

Task ASM Integrity check passed...

Verification of ASM Integrity was successful.

Syntax

cluvfy comp baseline -collect {all | cluster | database} [-n node_list]
  [-d Oracle_home] [-db db_unique_name] [-bestpractice | -mandatory] [-binlibfilesonly
  [-reportname report_name] [-savedir save_dir]

cluvfy comp baseline -compare baseline1,baseline2,... [-deviations]

Parameters

-collect {all | cluster |
 database}

-n node_list

-d Oracle_home

-db db_unique_name

-bestpractice | -mandatory

-binlibfilesonly

-report report_name

-savedir save_dir

-compare baseline1,baseline2,...

-deviations

Usage Notes

• Specify either the -collect or -compare parameter.

• Items that CVU collects when running this command include:

  
  Physical memory
  Available memory
  Swap space
  Free space
  Required packages
  Recommended kernel parameters
  /etc/inittab permissions
  Domain sockets under /var/tmp/.oracle
  Oracle Clusterware software file attributes
  Network MTU size
  OCR permissions, group, and owner (if OCR is stored on a shared file system)
  OCR disk group (if OCR is stored on Oracle ASM
  System requirement pluggable tasks (Zeroconf settings, /boot mount, Huge Pages existence, 8888 port availability, Ethernet jumbo frames)
  Oracle Clusterware post-check pluggable tasks (css miscount, reboottime, disktimeout)
  Database best practices

Examples

The following examples illustrate usage for both -collect and -compare command parameters:

$ cluvfy comp baseline -collect all -n all -db orcl -bestpractice -report bl1
   -savedir /tmp

$ cluvfy comp baseline -compare bl1,bl2

Syntax

cluvfy comp clocksync [-noctss] [-n node_list] [-verbose]

Parameters

-noctss

-n node_list

-verbose

Syntax

cluvfy comp clumgr [-n node_list] [-verbose]

Parameters

-n node_list

-verbose

Syntax

cluvfy comp crs [-n node_list] [-verbose]

Parameters

-n node_list

-verbose

Syntax

cluvfy comp dhcp -clustername cluster_name [-vipresname application_vip_resource_name]
  [-port dhcp_port] [-n node_list] [-method {sudo -user user_name [-location directory_path] | root}]
  [-networks network_list] [-verbose]

Parameters

-clustername cluster_name

-vipresname application_vip_resource_name

-port dhcp_port

-n node_list

-method {sudo -user user_name
 [-location directory_path] | root}

-networks network_list

-verbose

Usage Notes

• You must run this command as root.

• Do not run this check while the default network Oracle Clusterware resource, configured to use a DHCP-provided IP address, is online (because the VIPs get released and, since the cluster is online, DHCP has provided IP, so there is no need to double the load on the DHCP server).

• Run this check on the local node. This is unlike other CVU commands, which run on all nodes specified in node list. As a result, even though the local node is not included in the node list you specify with the -n option, the error messages get reported to the local node.

• Before running this command, ensure that the network resource is offline. Use the srvctl stop nodeapps command to bring the network resource offline, if necessary.

  See Also:

  Oracle Real Application Clusters Administration and Deployment Guide for more information about the srvctl stop nodeapps command

Syntax

cluvfy comp dns -server -domain gns_sub_domain -vipaddress gns_vip_address [-port dns_port]
  [-method {sudo -user user_name [-location directory_path] | root}] [-verbose]

cluvfy comp dns -client -domain gns_sub_domain -vip gns_vip [-port dns_port]
  [-last] [-method {sudo -user user_name [-location directory_path] | root}] [-verbose]

Parameters

-server

-client

-domain gns_sub_domain

-vipaddress gns_vip_address

-vip gns_vip

-port dns_port

-last

-method {sudo -user user_name
 [-location directory_path] | root}

-verbose

Usage Notes

• You must run this command as root.

• Run cluvfy comp dns -server on one node of the cluster.

• Run cluvfy comp dns -client on each node of the cluster to verify DNS server setup for the cluster.

• On the last node, specify the -last option to terminate the cluvfy comp dns -server instance.

• Do not run this command while the GNS resource is online.

Syntax

cluvfy comp freespace [-n node_list]

If you choose to include the -n option, then enter a comma-delimited list of node names on which to run the command.

Syntax

cluvfy comp gns -precrsinst {-vip gns_vip [-domain gns_domain] | -clientdata file_name}
  [-networks network_list] [-n node_list] [-verbose]

cluvfy comp gns -postcrsinst [-verbose]

Parameters

-precrsinst

-vip gns_vip

-domain gns_domain

-clientdata file_name

-networks network_list

-n node_list

-postcrsinst

-verbose

Syntax

cluvfy comp gpnp [-n node_list] [-verbose]

Parameters

-n node_list 

-verbose

Syntax

cluvfy comp ha [-verbose]

If you include the -verbose option, then CVU prints detailed output.

Syntax

cluvfy comp healthcheck [-collect {cluster|database}] [-db db_unique_name]
  [-bestpractice|-mandatory] [-deviations] [-html] [-save [-savedir directory_path]]

Parameters

-collect {cluster|database}

-db db_unique_name

[-bestpractice|-mandatory]
 [-deviations]

-html

-save [-savedir directory_path]

Syntax

cluvfy comp nodeapp [-n node_list] [-verbose]

Parameters

-n node_list

-verbose

Syntax

cluvfy comp nodecon [-n node_list] [-networks network_list] [-verbose]

Parameters

-n node_list

-networks network_list

-verbose

Usage Notes

• You can run this command in verbose mode to identify the mappings between the interfaces, IP addresses, and subnets.

• On Solaris platforms, this command skips testing IP addresses that are marked as deprecated.

• Use the nodecon command without the -networks option and with -n set to all to use CVU to:

  • Discover all of the network interfaces that are available on the cluster nodes

  • Review the interfaces' corresponding IP addresses and subnets

  • Obtain the list of interfaces that are suitable for use as VIPs and the list of interfaces to private interconnects

  • Verify the connectivity between all of the nodes through those interfaces

Examples

Example 1: Verifying the connectivity between nodes through specific network interfaces:

You can verify the connectivity between the nodes node1 and node3 through interface eth0 by running the following command:

cluvfy comp nodecon -n node1/node3 –networks eth0 -verbose

Example 2: Discovering all available network interfaces and verifying the connectivity between the nodes in the cluster through those network interfaces:

Use the following command to discover all of the network interfaces that are available on the cluster nodes. CVU then reviews the interfaces' corresponding IP addresses and subnets. Using this information, CVU obtains a list of interfaces that are suitable for use as VIPs and a list of interfaces to private interconnects. Finally, CVU verifies the connectivity between all of the nodes in the cluster through those interfaces.

cluvfy comp nodecon -n all -verbose

Syntax

cluvfy comp nodereach -n node_list [-srcnode node] [-verbose]

Parameters

-n node_list

-srcnode node

-verbose

Example

Verifying the network connectivity between nodes in the cluster:

To verify that node3 is reachable over the network from the local node, use the following command:

cluvfy comp nodereach -n node3

This command produces output similar to the following:

Verifying node reachability

Checking node reachability...
Node reachability check passed from node ”node1”


Verification of node reachability was successful.

Syntax

cluvfy comp ocr [-n node_list] [-method {sudo -user user_name [-location directory_path] | root}]
   [-verbose]

Parameters

-n node_list

-method {sudo -user user_name
 [-location directory_path] | root}

-verbose

Usage Notes

This command does not verify the integrity of OCR contents. You must use the OCRCHECK utility to verify the contents of OCR.

Example

Verifying the integrity of OCR on the local node

To verify the integrity of OCR on the local node, run the following command:

cluvfy comp ocr

This command produces output similar to the following:

Verifying OCR integrity

Checking OCR integrity...

Checking the absence of a non-clustered configurationl...
All nodes free of non-clustered, local-only configurations


ASM Running check passed. ASM is running on all specified nodes

Checking OCR config file ”/etc/oracle/ocr.loc”...

OCR config file ”/etc/oracle/ocr.loc” check successful


Disk group for ocr location ”+DATA” available on all the nodes


NOTE:
This check does not verify the integrity of the OCR contents. Execute ’ocrcheck' as a privileged user to verify the contents of OCR.

OCR integrity check passed

Verification of OCR integrity was successful.

Syntax

cluvfy comp ohasd [-n node_list] [-verbose]

Parameters

-n node_list

-verbose

Example

Verifying the integrity of the Oracle High Availability Services daemon on all nodes in the cluster

To verify that the Oracle High Availability Services daemon is operating correctly on all nodes in the cluster, use the following command:

cluvfy comp ohasd -n all -verbose

This command produces output similar to the following:

Verifying OHASD integrity

Checking OHASD integrity...
ohasd is running on node ”node1”
ohasd is running on node ”node2”
ohasd is running on node ”node3”
ohasd is running on node ”node4”

OHASD integrity check passed

Verification of OHASD integrity was successful.

Syntax

cluvfy comp olr [-n node_list] [-verbose]

Parameters

-n node_list

-verbose

Usage Notes

This command does not verify the integrity of the OLR contents. You must use the ocrcheck -local command to verify the contents of OCR.

Example

Verifying the integrity of the OLR on a node

To verify the integrity of the OLR on the current node, run the following command:

cluvfy comp olr -verbose

This command produces output similar to the following:

Verifying OLR integrity

Checking OLR integrity...

Checking OLR config file...

OLR config file check successful


Checking OLR file attributes...

OLR file check successful

WARNING:
This check does not verify the integrity of the OLR contents. Execute ’ocrcheck -local' as a privileged user to verify the contents of OLR.

OLR integrity check passed

Verification of OLR integrity was successful.

Syntax

cluvfy comp peer -n node_list [-refnode node]
  [-r {10.1 | 10.2 | 11.1 | 11.2 | 12.1}] [-orainv orainventory_group]
  [-osdba osdba_group] [-verbose]

Parameters

-refnode

-n node_list

-r {10.1 | 10.2 | 11.1 |
 11.2 | 12.1}

-orainv orainventory_group

-osdba osdba_group

-verbose

Usage Notes

Peer comparison with the -refnode option compares the system properties of other nodes against the reference node. If the value of the other node is not greater than the value for that of the reference node, then CVU flags that comparison as a deviation from the reference node. If a group or user exists on neither the reference node nor on the other node, then CVU reports a match to indicate that there is no deviation from the reference node. Similarly, CVU reports as mismatched a comparison with a node that has less total memory than the reference node.

Example

Comparing the configuration of select cluster nodes

The following command lists the values of several preselected properties on different nodes from Oracle Database 12c:

cluvfy comp peer -n node1,node2,node4,node7 -verbose

Syntax

cluvfy comp scan [-verbose]

If you include the -verbose option, then CVU prints detailed output.

Example

Verifying the SCAN configuration

To verify that the SCAN and SCAN listeners are configured and operational on all nodes in the cluster, use the following command:

cluvfy comp scan

This command produces output similar to the following:

Verifying scan

Checking Single Client Access Name (SCAN)...

Checking TCP connectivity to SCAN Listeners...
TCP connectivity to SCAN Listeners exists on all cluster nodes

Checking name resolution setup for ”node1.example.com”...

Verification of SCAN VIP and Listener setup passed

Verification of scan was successful.

Syntax

cluvfy comp software [-n node_list] [-d oracle_home] 
  [-r {10.1 | 10.2 | 11.1 | 11.2 | 12.1}] [-allfiles] [-verbose]

Parameters

-n node_list

-d oracle_home

-r {10.1 | 10.2 | 11.1 |
 11.2 | 12.1}

-allfiles

-verbose

Example

Verifying the software configuration on all nodes in the cluster for the Oracle Clusterware home directory

To verify that the installed files for Oracle Clusterware 12c are configured correctly, use a command similar to the following:

cluvfy comp software -n all -verbose

This command produces output similar to the following:

Verifying software

Check: Software

 1021 files verified

Software check passed

Verification of software was successful.

Syntax

cluvfy comp space [-n node_list] -l storage_location 
  -z disk_space {B | K | M | G} [-verbose]

Parameters

-n node_list

-l storage_location

-z disk_space {B|K|M|G}

-verbose

Usage Notes

The space component does not support block or raw devices.

Examples

Verifying the availability of free space on all nodes

You can verify that each node has 5 GB of free space in the /home/dbadmin/products directory by running the following command:

cluvfy comp space -n all -l /home/dbadmin/products –z 5G -verbose

Syntax

cluvfy comp ssa [-n node_list | -flex -hub hub_list [-leaf leaf_list]]
  [-s storage_path_list] [-t {software | data | ocr_vdisk}]  [-asm] [-asmdev asm_device_list]
  [-r {10.1 | 10.2 | 11.1 | 11.2 | 12.1}] [-verbose]

Parameters

-n node_list | -flex -hub
hub_list -leaf leaf_list

-s storage_path_list

-t {software | data | 
ocr_vdisk}

-asm

-asmdev asm_device_list

-r {10.1 | 10.2 | 11.1 | 11.2 | 12.1}

-verbose

Usage Notes

• The current release of cluvfy has the following limitations on Linux regarding shared storage accessibility check.

  • Currently NAS storage and OCFS2 (version 1.2.1 or higher) are supported.

    See Also:

    Oracle Grid Infrastructure Installation Guide for more information about NAS mount options

  • When checking sharing on NAS, cluvfy commands require that you have write permission on the specified path. If the cluvfy user does not have write permission, cluvfy reports the path as not shared.

• To perform discovery and shared storage accessibility checks for SCSI disks on Linux systems, CVU requires the CVUQDISK package. If you attempt to use CVU and the CVUQDISK package is not installed on all of the nodes in your Oracle RAC environment, then CVU responds with an error. See "Shared Disk Discovery on Red Hat Linux" for information about how to install the CVUQDISK package.

Examples

Example 1: Discovering All of the Available Shared Storage Systems on Your System

To discover all of the shared storage systems available on your system:

cluvfy comp ssa -n all -verbose

Example 2: Using the Oracle ASM Discovery String Check

To verify the Oracle ASM discovery string:

cluvfy comp ssa -n node1,node2 -asm -asmdev "/dev/xda*"

Example 3: Verifying the Accessibility of a Specific Storage Location

You can verify the accessibility of specific storage locations, such as an Oracle ASM disk group called OCR13, for storing data files for all the cluster nodes by running a command similar to the following:

cluvfy comp ssa -n all -s OCR13

This command produces output similar to the following:

Verifying shared storage acessibility

Checking shared storage accessibility...

"OCR13" is shared


Shared storage check was successful on nodes "node1,node2,node3,node4"

Verification of shared storage accessibility was successful.

Parameters

-n node_list

-r {10.1 | 10.2 | 11.1 | 11.2 | 12.1}

-osdba osdba_group

-orainv orainventory_group

-fixup

-fixupnoexec

-method {sudo -user user_name
 [-location directory_path] | root}

-verbose

Syntax

cluvfy comp sys [-n node_list | -flex -hub hub_list [-leaf leaf_list]]
  -p {crs | ha | database}  [-r {10.1 | 10.2 | 11.1 | 11.2 | 12.1}] [-osdba osdba_group]
  [-orainv orainventory_group] [-fixup] [-fixupnoexec] [-method {sudo -user user_name
  [-location directory_path] | root}] [-verbose]

Examples

Verifying the system requirements for installing Oracle Clusterware

To verify the system requirements for installing Oracle Clusterware 12c on the cluster nodes node1,node2 and node3, run the following command:

cluvfy comp sys -n node1,node2,node3 -p crs -verbose

Syntax

cluvfy comp vdisk [-n node_list] [-verbose]

Parameters

-n node_list

-verbose

Syntax

cluvfy stage -pre acfscfg -n node_list [-asmdev asm_device_list] [-verbose]

cluvfy stage -post acfscfg -n node_list [-verbose]

Parameters

-n node_list

-asmdev asm_device_list

-verbose

Syntax

cluvfy stage -pre cfs -n node_list -s storageID_list [-verbose]

cluvfy stage -post cfs -n node_list -f file_system [-verbose]

Parameters

-n node_list

-s storageID_list

-verbose

Example

To check that a shared device is configured correctly before setting up OCFS2, use a command similar to the following, where you replace /dev/sdd5 with the name of the shared device on your system:

cluvfy stage -pre cfs -n node1,node2,node3,node4 -s /dev/sdd5

Syntax

cluvfy stage -pre crsinst -file config_file [-fixup] [-fixupnoexec] 
  [-method {sudo -user user_name [-location directory_path] | root}] [-verbose]

cluvfy stage -pre crsinst -n node_list | -flex -hub hub_list [-leaf leaf_list]
  [-r {10.1 | 10.2 | 11.1 | 11.2 | 12.1}] [-c ocr_location_list] [-q voting_disk_list]
  [-osdba osdba_group] [-orainv orainventory_group] [-asm [-presence {local | flex}
  | -asmcredentials client_data_file] [-asmgrp asmadmin_group] [-asmdev asm_device_list]]
  [-crshome Grid_home] [-fixup] [-fixupnoexec]
  [-method {sudo -user user_name [-location directory_path] | root}]
  [-networks network_list] [-dhcp -clustername cluster_name [-dhcpport dhcp_port]]
  [-verbose]

crsinst -upgrade [-rolling] [-src_crshome src_crshome] -dest_crshome dest_crshome
  -dest_version dest_version [-fixup] [-fixupnoexec] [-method {sudo -user user_name
  [-location directory_path] | root}] [-verbose]

cluvfy stage -post crsinst -n node_list
  [-method {sudo -user user_name [-location directory_path] | root}] [-verbose]

Parameters

-file config_file

-n node_list

-flex -hub hub_list
 [-leaf leaf_list]

-r {10.1 | 10.2 | 11.1 |
11.2 | 12.1}

-c ocr_location_list

-q voting_disk_list

-osdba osdba_group

-orainv orainventory_group

-asm [-presence {local | flex} |
 -asmcredentials client_data_file]

-asmgrp asmadmin_group

-asmdev asm_device_list

-crshome Grid_home

-networks [network_list]

-dhcp -clustername
 cluster_name [-dhcpport
 dhcp_port]

-rolling

-src_crshome src_crshome

-dest_crshome dest_crshome

-dest_version dest_version

-fixup

-fixupnoexec

-method {sudo -user user_name
 [-location dir_path] | root}

-verbose

Usage Notes

• To perform checks for a new installation, specify either the -file or -n parameters, and use -upgrade for performing checks for upgrading to another version.

• CVU performs additional checks on OCR and voting files if you specify the -c and -q options with the -n parameter.

Syntax

On Linux and UNIX platforms:

cluvfy stage -pre dbcfg -n node_list -d Oracle_home [-fixup] [-fixupnoexec]
  [-method {sudo -user user_name [-location directory_path] | root}]
  [-servicepwd] [-verbose]

On Windows platforms:

cluvfy stage -pre dbcfg -n node_list -d oracle_homew [-fixup] [-fixupnoexec]
  [-verbose] [-servicepwd]

Parameters

-n node_list

-d Oracle_home

-fixup

-fixupnoexec

-method {sudo -user user_name
 [-location dir_path] | root}

-servicepwd

-verbose

Syntax

On Linux and UNIX platforms:

cluvfy stage -pre dbinst -n <node_list> [-r {10.1 | 10.2 | 11.1 | 11.2 | 12.1}]
  [-osdba osdba_group] [-osbackup osbackup_group] [-osdg osdg_group]
  [-oskm oskm_group] [-d oracle_home] [-fixup] [-fixupnoexec]
  [-method {sudo -user user_name [-location directory_path] | root}]
  [-verbose]

cluvfy stage pre dbinst -upgrade -src_dbhome src_dbhome [-dbname dbname-list]
  -dest_dbhome dest_dbhome -dest_version dest_version
  [-fixup] [-fixupnoexec] [-method sudo -user user_name [-location directory_path]

On Windows platforms:

cluvfy stage -pre dbinst -n node_list [-r {10.1 | 10.2 | 11.1 | 11.2 | 12.1}]
  [-d Oracle_home] [-fixup] [-fixupnoexec] [-serviceuser user_name [-servicepasswd]]]
  [-verbose]

cluvfy stage -pre dbinst -upgrade -src_dbhome src_dbhome [-dbname dbname-list
  -dest_dbhome dest_dbhome -dest_version dest_version [-fixup] [-fixupnoexec]
  [-verbose]]

Parameters

-n node_list

-r {10.1 | 10.2 | 11.1 | 11.2 | 12.1}

-osdba osdba_group

-d Oracle_home

-osbackup osbackup_group

-osdg osdg_group

-oskm oskm_group

-fixup

-upgrade

-src_dbhome src_dbhome

-dbname dbname-list

-dest_dbhome dest_dbhome

-dest_version dest_version

-fixupnoexec

-method {sudo -user user_name
 [-location dir_path] | root}

[-serviceuser user_name [-servicepwd]]

-verbose

Syntax

cluvfy stage -pre hacfg [-osdba osdba_group] [-orainv orainventory_group]
  [-fixup] [-fixupnoexec] [-method {sudo -user user_name [-location directory_path] | root}]
[-verbose]

cluvfy stage -post hacfg [-verbose]

Parameters

-osdba osdba_group

-orainv orainventory_group

-fixup

-fixupnoexec

-method {sudo -user user_name
 [-location dir_path] | root}

-verbose

Syntax

cluvfy stage -post hwos -n node_list [-s storageID_list] [-verbose]

Parameters

-n node_list

-s storageID_list

-verbose

Syntax

cluvfy stage -pre nodeadd -n node_list [-vip vip_list] | -flex [-hub hub_list
  [-vip vip_list]] [-leaf leaf_list] [-fixup] [-fixupnoexec]
  [-method {sudo -user user_name [-location directory_path] | root}] [-verbose]

cluvfy stage -post nodeadd -n node_list [-verbose]

Parameters

-n node_list

-vip vip_list

-flex [-hub hub_list
 [-vip vip_list]]

-leaf leaf_list

-fixup

-fixupnoexec

-method {sudo -user user_name
 [-location dir_path] | root}

-verbose

Syntax

cluvfy stage -post nodedel -n node_list [-verbose]

Parameters

-n node_list

-verbose

Usage Notes

If the cluvfy stage -post nodedel check fails, then repeat the node deletion procedure.

Database Versions Supported by Cluster Verification Utility

The current CVU release supports only Oracle Database 10g or higher, Oracle RAC, and Oracle Clusterware; CVU is not backward compatible. CVU cannot check or verify Oracle Database products for releases before Oracle Database 10g.

Linux Shared Storage Accessibility (ssa) Check Reports Limitations

The current release of cluvfy has the following limitations on Linux regarding shared storage accessibility check.

• OCFS2 (version 1.2.1 or higher) is supported.

• For sharedness checks on NAS, cluvfy commands require you to have write permission on the specified path. If the user running the cluvfy command does not have write permission, then cluvfy reports the path as not shared.

Shared Disk Discovery on Red Hat Linux

To perform discovery and shared storage accessibility checks for SCSI disks on Red Hat Linux 5.0 (or higher) and Oracle Linux 5.0 (or higher), and SUSE Linux Enterprise Server, CVU requires the CVUQDISK package. If you attempt to use CVU and the CVUQDISK package is not installed on all of the nodes in your Oracle RAC environment, then CVU responds with an error.

Perform the following procedure to install the CVUQDISK package:

1. Login as the root user.

2. Copy the package, cvuqdisk-1.0.9-1.rpm (or higher version) to a local directory. You can find this rpm in the rpm subdirectory of the top-most directory in the Oracle Clusterware installation media. For example, you can find cvuqdisk-1.0.9-1.rpm in the directory /mountpoint/clusterware/rpm/ where mountpoint is the mount point for the disk on which the directory is located.

   # cp /mount_point/clusterware/rpm/cvuqdisk-1.0.9-1.rpm /u01/oradba
   

3. Set the CVUQDISK_GRP environment variable to the operating system group that should own the CVUQDISK package binaries. If CVUQDISK_GRP is not set, then, by default, the oinstall group is the owner's group.

   # set CVUQDISK_GRP=oinstall
   
   

4. Determine whether previous versions of the CVUQDISK package are installed by running the command rpm -q cvuqdisk. If you find previous versions of the CVUQDISK package, then remove them by running the command rpm -e cvuqdisk previous_version where previous_version is the identifier of the previous CVUQDISK version, as shown in the following example:

   # rpm -q cvuqdisk
   cvuqdisk-1.0.2-1
   # rpm -e cvuqdisk-1.0.2-1
   
   

5. Install the latest CVUQDISK package by running the command rpm -iv cvuqdisk-1.0.9-1.rpm.

   # cd /u01/oradba
   # rpm -iv cvuqdisk-1.0.9-1.rpm