This
document addresses some of the frequently asked questions and common concerns
regarding the Cluster Verification Framework and the cluvfy tool.
General concept
What
is CVU? What are its objectives and features?
What
is a stage?
What
is a component?
What
is nodelist?
What
is a configuration file?
Do
I have to be root to use CVU?
What
about discovery? Does CVU discover installed components?
What
about locale? Does CVU support other languages?
How
do I report a bug?
What
version of Oracle Clusterware or RAC is supported by CVU?
Installation
What
are the requirements for CVU?
How
do I install CVU from OTN?
What
is 'cvuqdisk' rpm? Why should I install this rpm?
How
do I install 'cvuqdisk' package?
Usage
How
do I know about cluvfy commands? The usage text of cluvfy does not show
individual commands.
What
are the default values for the command line arguments?
Do
I have to type the nodelist every time for the CVU commands? Is there any
shortcut?
How
do I get detailed output of a check?
How
do I check network or node connectivity related issues?
How
do I check whether OCFS or OCFS2 is properly configured?
How
do I check the Oracle Clusterware stack and other sub-components of it?
How
do I check user accounts and administrative permissions related issues?
How
do I check if SSH is configured properly on my cluster?
How
do I check minimum system requirements on the nodes?
Can
I check if the storage is shared among the nodes?
Is
there a way to compare nodes?
Why
the peer comparison with -refnode says "matched" when the
group or user does not exist?
Is
there a way to verify that the Oracle Clusterware is working properly before
proceeding with RAC install?
At
what point cluvfy is usable? Can I use cluvfy before installing Oracle
Clusterware?
How
do I turn on tracing?
Where
can I find the CVU trace files?
Why
cluvfy reports "unknown" on a particular node?
Why
does CVU complain "ERROR:
Could not find a suitable set of interfaces for VIPs"?
Limitations:
What
are the known issues with this release?
Platform Specific:
What
OS versions and distributions are supported?
_________________________________________________________________________________________________________________
What is Cluster
Verification Utility (CVU)? What are its objectives and features?
CVU is a utility that is distributed with Oracle Clusterware. It was developed
to assist in the installation and configuration of Oracle Clusterware as well
as RAC. CVU will verify all the important components that are needed at
different stages in configuring a RAC environment. The wide domain of
verification provided by CVU ranges from initial hardware setup through fully
operational cluster for RAC deployment and covers all the intermediate stages
of installation and configuration of various components. The command line tool
is cluvfy. Cluvfy is a non-intrusive utility and will not
adversely affect the system or operational stack.
[
go to the top ]
What is a stage?
CVU supports the notion of Stage verification. It identifies all the important
stages in RAC deployment and provides each stage with its own entry and exit
criteria. The entry criteria for a stage define a specific set of verification
tasks to be performed before initiating that stage. This pre-check saves the
user from entering into a stage unless its pre-requisite conditions are met.
The exit criteria for a stage define another specific set of verification tasks
to be performed after completion of the stage. The post-check ensures that the
activities for that stage have been completed successfully. It identifies any
stage specific problem before it propagates to subsequent stages; thus making
it difficult to find its root cause. An example of a stage is "pre-check
of database installation", which checks whether the system meets the
criteria for RAC install.
[
go to the top ]
What is a component?
CVU supports the notion of Component verification. The verifications in this
category are not associated with any specific stage. The user can verify the
correctness of a specific cluster component. A component can range from a basic
one, like free disk space to a complex one like Oracle Clusterware Stack. The
integrity check for the Oracle Clusterware stack will transparently span over
verification of multiple sub-components associated with Oracle Clusterware
stack. Bundling of several relevant tasks as a component is of great use to the
user for verifying a specific cluster component.
[
go to the top ]
What is nodelist?
A nodelist is a comma separated list of hostnames without domain. Cluvfy will
run the requested verification on all nodes in the nodelist provided. Cluvfy
will ignore any domain while processing the nodelist. If duplicate entities
after removing the domain exist, cluvfy will eliminate the duplicate names
while processing. Wherever supported, you can use '-n all' to check on
all the cluster nodes. Check "Do
I have to type the nodelist every time for the CVU commands? Is there any
shortcut?" for more information on nodelist and shortcuts.
[
go to the top ]
What is a configuration file?
CVU supports a configuration file called cvu_config under
CV_HOME/cv/admin folder. This file supports property-value style preferences in
a persistent way. This might vary depending upon the platform. Here is a brief
description of some of those properties:
CV_ORACLE_RELEASE:
This property can take a value of the Oracle release that should be assumed
when –r option is not specified in the command line. The valid values that can
be set are 10gR1, 10gR2 or 11gR1. If this property is not set then the default
is 11gR1.
CV_NODE_ALL:
This property stores a comma separated list of nodes to be used for all the
nodes in the cluster. This value will be used for "-n all" argument
on the command line. For detail refer to "Do
I have to type the nodelist every time for the CVU commands? Is there any
shortcut?".
CV_RAW_CHECK_ENABLED:
If this property is set to TRUE, then CVU will perform scsi disk discovery and
sharedness checks. For Linux platforms, CVU requires the cvuqdisk rpm installed
on all nodes if this property is set. For detail refer to "What
is 'cvuqdisk' rpm? Why should I install this rpm?".
CV_ASSUME_DISTID:
This property is used in cases where CVU can not detect or support a particular
platform or a distribution. It is not recommend to change this property as this
might render CVU non-functional.
CV_XCHK_FOR_SSH_ENABLED:
If this property is set to TRUE, CVU will also check whether X-Windows is
configured with SSH for user equivalence. For detail, refer to "How
do I check if SSH is configured properly on my cluster?".
ORACLE_SRVM_REMOTESHELL:
This property stores alternative remote shell command location.
ORACLE_SRVM_REMOTECOPY:
This property stores alternative remote copy command location.
[
go to the top ]
Do I have to be root to use
CVU?
No. CVU is intended for database and system administrators. CVU assumes the
current user as oracle user.
[
go to the top ]
What about discovery?
Does CVU discover installed components?
At present, CVU's discovery is limited to the following components. CVU
discovers available network interfaces if you do not specify any interface in
its command line. For storage related verification, CVU discovers all the
supported storage types if you do not specify a particular storage. CVU
discovers CRS HOME if one is available. CVU also discovers the statically
configured nodelist for the cluster if an Oracle supported vendor clusterware
or Oracle Clusterware is available.
[
go to the top ]
What about locale? Does CVU
support other languages?
Yes. CVU complies to Oracle's NLS guidelines and supports locale.
[
go to the top ]
How do I report a bug?
Please refer to the "What
are the known issues with this release?" section of ths document and
the README file before filing a bug. If the issue is not covered in those
documents, open a TAR through Oracle Support.
[
go to the top ]
What version of Oracle
Clusterware or RAC is supported by CVU?
On Linux x86 and x86_64: The current CVU release supports Oracle Clusterware,
Oracle RAC 10g, and Oracle RAC 11g. In other words, "the current
version" of CVU can check 10g as well as 11g releases of Oracle
Clusterware or RAC. However, it can not check or verify pre-10g(Oracle 9i)
products.
On Solaris SPARC64, AIX, HPUX (PARISC and IA64): CVU is limitedly backward
compatible to the previous Oracle Clusterware releases up to Oracle Database
10g Release 1. It works on the operating system versions supported by 11gR1,
that would be Solaris 9, Solaris 10, AIX 5.3, HPUX 11.23 and HPUX 11.31 only.
[
go to the top ]
What are the requirements for
CVU?
CVU requires:
1. An area with at least 35MB (on Linux
x86 and Linux x86_64), 55MB (on Solaris SPARC64), 100MB (on AIX), 105MB (on
HPUX IA64) and 60MB (on HPUX PARISC) of free space for containing software bits
on the invocation node.
2. A work directory with at least 5MB
on all the nodes. CVU will attempt to copy the necessary bits as
required to this location. Make sure, the location exists on all nodes and it
has write permission for CVU user. This directory is set through the CV_DESTLOC
environment variable. If this variable is not set, CVU will use the common
temporary location such as "/tmp" for Linux and
"C:\Temp" for Windows as the work dir.
3. An optional package
'cvuqdisk' is required on all the nodes for Linux distributions. This assists
CVU in finding scsi disks and helps CVU to perform storage checks on disks.
Please refer to What
is 'cvuqdisk' rpm? for detail. Note that, this package should be installed
only on RedHat Linux 3(or higher), or Enterprise
Linux 4(or higher) or SuSE 9(or higher) distribution or on other Linux flavors
of comparable versions.
[
go to the top ]
How do I install CVU from OTN?
Here is how one can install CVU from a zip file(cvupack_<platform>.zip)
downloaded from OTN:
1. Create a CV home( say /home/username/mycvhome ) directory. It should
have at least 35M of free disk space.
2. cd /home/username/mycvhome
3. copy the cvupack_<platform>.zip file to /home/username/mycvhome
4. unzip the file:
> unzip cvupack<platform>.zip
5. (Optional) Set the environmental variable CV_DESTLOC. This should point to a
writable area on *all* nodes. When invoked, the tool will attempt to copy the
necessary bits as required to this location. Make sure the location exists on
all nodes and it has write permission for CVU user. It is strongly recommended
that you should set this variable. If this variable has not been set, CVU will
use "/tmp" as the default.
> setenv CV_DESTLOC /tmp/cvu_temp
To verify, run cluvfy from <CV Home>/bin directory (typically
/home/username/mycvhome/bin/cluvfy). This should show the usage.
For Linux platforms, an optional rpm package 'cvuqdisk' is required on all the
nodes. Please refer to How
do I install 'cvuqdisk' package? for detail.
[
go to the top ]
What is 'cvuqdisk' rpm? Why
should I install this rpm?
cvuqdisk is applicable on Linux platforms only.
CVU requires root privilege to gather information about the scsi disks
during discovery. A small binary uses the setuid mechanism to query disk
information as root. Note that this process is purely a read-only process with
no adverse impact on the system. To make this secured, this binary is packaged
in the cvuqdisk rpm and need root privilege to install on a machine.
When this package is installed on all the nodes, CVU performs discovery and
shared storage accessibility checks for scsi disks. Otherwise, it complains
about the missing package 'cvuqdisk'. You can disable the scsi device check
feature by setting the CV_RAW_CHECK_ENABLED to FALSE in $CV_HOME/cv/admin/cvu_config
file. CVU will not complain about the missing rpm if this variable is set to
false.
Discovery of SCSI disks for RedHat Linux 2.1 is not supported.
Hence this package should not be installed on Redhat 2.1 AS.
[
go to the top ]
How do I install 'cvuqdisk'
package?
Here are the steps to install cvuqdisk package.
1. Become root user
2. Copy the rpm ( cvuqdisk-1.0.1-1.rpm or the latest version ) to a local
directory. You can find the rpm in <CV-HOME>/rpm directory where
<CV-HOME> is the directory in which you have installed CVU from OTN.
3.Set the environment variable to a group, who should own this binary.
Typically it is the "dba" group.
export CVUQDISK_GRP=dba
4. Erase any existing package
rpm -e cvuqdisk
5. Install the rpm
rpm -iv cvuqdisk-1.0.1-1.rpm
6. Verify the package
rpm -qa | grep cvuqdisk
[
go to the top ]
How do I know about cluvfy
commands? The usage text of cluvfy does not show individual commands.
Cluvfy has context sensitive help built into it. Cluvfy shows the most
appropriate usage text based on the cluvfy command line arguments.
If you type 'cluvfy' on the command prompt, cluvfy displays the high level
generic usage text, which talks about valid stage and component syntax.
If you type 'cluvfy comp -list', cluvfy will show valid components with
brief description on each of them. If you type 'cluvfy comp -help',
cluvfy will show detail syntax for each of the valid components. Similarly,
'cluvfy stage -list' and 'cluvfy stage -help' will list valid stages and their
syntax respectively.
If you type an invalid command, cluvfy will show the appropriate usage for
thatparticular command. For example, if you type 'cluvfy stage -pre dbinst',
cluvfy will show the syntax for pre-check of dbinst stage.
[
go to the top ]
What are the default
values for the command line arguments?
Here are the default values and behavior for different stage and component
commands:
For component nodecon:
If no -i arguments is provided, then cluvfy runs in the
discovery mode.
For component nodereach:
If no -srcnode is provided, then the local(node of
invocation) will be used as the source node.
For components ssa:
If no -n argument is provided, then the local node will be
used.
If no -s argument is provided, then cluvfy runs in the storage
discovery mode.
For components clu:
If no -n argument is provided, then all the nodes in the
cluster will be used for verification.
For components cfs, ocr, crs, space, clumgr, nodeapp :
If no -n argument is provided, then the local node will be
used.
For components sys :
If no -n argument is provided, then the local node will be
used.
If no -r argument is provided, then 11gR1 will be used.
If no -osdba argument is provided, then 'dba' will be used.
If no -orainv argument is provided, then 'oinstall' will be
used.
For components admprv:
If no -n argument is provided, then the local node will be
used.
If no -osdba argument is provided, then 'dba' will be used.
If no -orainv argument is provided, then 'oinstall' will be
used.
For component peer:
If no -r argument is provided, then 11gR1 will be used.
If no -osdba argument is provided, then 'dba' will be used.
If no -orainv argument is provided, then 'oinstall' will be
used.
For stage -post hwos:
If no -s argument is provided, then cluvfy runs in the
discovery mode.
For stage -pre crsinst:
If no -r argument is provided, then 11gR1 will be used.
If no -c argument is provided, then cluvfy will skip OCR
related checks.
If no -q argument is provided, then cluvfy will skip voting
disk related checks.
If no -osdba argument is provided, then 'dba' will be used.
If no -orainv argument is provided, then 'oinstall' will be
used.
For stage -pre dbinst:
If no -r argument is provided, then 11gR1 will be used.
If no -osdba argument is provided, then 'dba' will be used.
NOTE:
For each verification command
that supports the optional -r option to specify the supported Oracle release,
the default release is assumed to be 11gR1 if -r option is not specified. To
perform verifications for any previous release, ‘-r 10gR1’ or ‘-r 10gR2’ must
be specified. If the verifications are to be performed for a specific release
earlier than 11gR1 then use of -r option can be avoided by setting the intended
release value (10gR1 or 10gR2) for CV_ORACLE_RELEASE property in CVU’s
configuration file (located under <CVU installation root dir>/cv/admin
directory).
[
go to the top ]
Do I have to type the
nodelist every time for the CVU commands? Is there any shortcut?
You do not have to type the nodelist every time for the CVU commands. Typing
the nodelist for a large cluster is painful and error prone. Here are few
shortcuts.
To provide all the nodes of the cluster, type '-n all'. Cluvfy will
attempt to get the nodelist in the following order:
1. If a vendor clusterware is available, it will pick all
the configured nodes from the vendor clusterware using lsnodes utility.
2. If CRS is installed, it will pick all the configured
nodes from Oracle clusterware using olsnodes utility.
3. It will look for the CV_NODE_ALL property in the cvu_config
file under $CV_HOME/cv/admin.
4. If none of the above, it will look for the CV_NODE_ALL
environmental variable.
5. Otherwise, it will complain.
To provide a partial list(some of the nodes of the cluster) of nodes, you can
set an environmental variable and use it in the CVU command. For example:
export MYNODES=node1,node3,node5
cluvfy comp nodecon -n $MYNODES
[
go to the top ]
How do I get detail
output of a check?
Cluvfy supports a verbose mode. By default, cluvfy reports in non-verbose mode
and just reports the summary of a test. To get detailed output of a check, use
the flag '-verbose' in the command line. This will produce detail output of
individual checks and where applicable will show per-node result in a tabular
fashion.
[
go to the top ]
How do I check network or node
connectivity related issues?
Use component verifications commands like 'nodereach' or 'nodecon' for this
purpose. For detailed syntax of these commands, type comp -help command
on the command prompt.
If the 'comp nodecon' command is invoked without -i, cluvfy will attempt to
discover all the available interfaces and the corresponding IP address &
subnet. Then cluvfy will try to verify the node connectivity per subnet. You
can run this command in verbose mode to find out the mappings between the
interfaces, IP addresses and subnets. Cluvfy will suggest interfaces for VIP
and private interconnect if suitable interfaces are available.
You can check the connectivity among the nodes through specific interfaces
by specifying the interface name(s) through -i argument.
[
go to the top ]
Can I check if the storage
is shared among the nodes?
Yes, you can use 'cluvfy comp ssa' command to check the sharedness of the
storage. Please refer to the known
issues section for the type of storage supported by cluvfy.
[
go to the top ]
How do I check whether
OCFS or OCFS2 is properly configured?
OCFS or OCFS2 is applicable on Linux platforms only.
You can use the component command 'cluvfy comp cfs' to check this. Provide the
OCFS or OCFS2 file system you want to check through the -f argument. Note that,
the sharedness check for the OCFS file system is supported for OCFS version
1.0.14 or higher.
[
go to the top ]
How do I check the
Oracle Clusterware stack and other sub-components of it?
Cluvfy provides commands to check a particular sub-component of the Oracle
Clusterware stack as well as the whole Oracle Clusterware stack. You can use
the 'comp ocr' command to check the integrity of OCR. Similarly, you can use
'comp crs' and 'comp clumgr' commands to check integrity of Oracle Clustereare
and clustermanager sub-components.
To check the entire Oracle Clusterware stack, run the stage command 'cluvfy
stage -post crsinst'.
[
go to the top ]
How do I check user accounts
and administrative permissions related issues?
Use admprv component verification command. Refer to the usage text for
detail instruction and type of supported operations. To check whether the
privilege is sufficient for user equivalence, use '-o user_equiv'
argument. You can force CVU to check user equivalence using SSH only by
the '-sshonly' flag. Similarly, the '-o crs_inst' will verify
whether the user has the correct permissions for installing Oracle Clusterware.
The '-o db_inst' will check for permissions required for installing RAC
and '-o db_config' will check for permissions required for creating a
RAC database or modifying a RAC database configuration.
[
go to the top ]
How do I check if SSH is
configured properly on my cluster?
You can use CVU's admprv component verification command 'comp admprv -n
<nodelist> -o user_equiv -sshonly -verbose' to verify this. To check
whether X-Windows is configured to work with SSH for user equivalence as per
Oracle's requirement, set the following property
"CV_XCHK_FOR_SSH_ENABLED=TRUE" in the $CV_HOME/cv/admin/cvu_config
file.
[
go to the top ]
How do I check minimum system
requirements on the nodes?
The component verification command sys is meant for that. Note that, CVU
can check the minimum system requirements for Oracle Clusterware versions
10gR1, 10gR2 and 11gR1. Use the '-p crs' argument to check requirements for Oracle
Clusterware and -r argument for the desired version. Similarly, CVU can check
the minimum system requirements for RAC versions 10gR1, 10gR2 and 11gR1. For
RAC, you have to use the '-p database' argument.
[
go to the top ]
Is there a way to compare nodes?
You can use the peer comparison feature of cluvfy for this purpose. The command
'comp peer' will list the values of different nodes for several pre-selected
properties. You can use the peer command with -refnode argument
to compare those properties of other nodes against the reference node.
[
go to the top ]
Why the peer comparison
with -refnode says matched when the group or user does not exist?
Peer comparison with the -refnode feature acts like a baseline feature. It
compares the system properties of other nodes against the reference node. If
the value does not match( not equal to reference node value ), then it flags
that as a deviation from the reference node. If a group or user does not exist
on reference node as well as on the other node, it will report this as
'matched' since there is no deviation from the reference node. Similarly, it
will report as 'mismatched' for a node with higher total memory than the
reference node for the above reason.
[
go to the top ]
Is there a way to verify
that the Oracle Clusterware is working properly before proceeding with RAC
install?
Yes. You can use the post-check command for cluster services setup(-post
crsinst) to verify Oracle Clusterware status. A more appropriate test would
be to use the pre-check command for database installation(-pre dbinst).
This will check whether the current state of the system is suitable for RAC
install.
[
go to the top ]
At what point cluvfy is
usable? Can I use cluvfy before installing Oracle Clusterware?
You can run cluvfy at any time, even before Oracle Clusterware installation. In
fact, cluvfy is designed to assist the user as soon as the hardware and OS is
up. If you invoke a command which requires Oracle Clusterware or RAC on local
node, cluvfy will report an error if those required products are not yet
installed.
[
go to the top ]
How do I turn on tracing?
The tracing is turned on by default. Set the environmental variable SRVM_TRACE
to false if you do not want tracing. For example, in bash "export
SRVM_TRACE=false" or “export SRVM_TRACE=FALSE” will switch off tracing.
[
go to the top ]
Where can I find the CVU
trace files?
CVU log files can be found under $CV_HOME/cv/log directory. The log files are
automatically rotated and the latest log file has the name cvutrace.log.0.
It is a good idea to clean up unwanted log files or archive them to reclaim
disk place.
[
go to the top ]
Why cluvfy reports
"unknown" on a particular node?
Cluvfy reports unknown when it can not conclude for sure if the check passed or
failed.
[
go to the top ]
Why does CVU complain
"WARNING: Could
not find a suitable set of interfaces for VIPs"?
CVU checks for the following criteria before considering a set of
interfaces for VIP:
-- the interfaces should have the same name across nodes
-- they should belong to the same subnet
-- they should have the same netmask
-- they should be on public(and routable) network.
Oftentimes, the interfaces planned for the VIPs are configured on 10.*,
172.16.* - 172.31.* or 192.168.* networks, which are not routable. Hence CVU
does not consider them as suitable for VIPs. If none of the available
interfaces satisfy this criteria, CVU complains "WARNING: Could not find a suitable set of interfaces
for VIPs.". It is worth noting that, such addresses will actually
work if they're public, but CVU just thinks they're private and reports
accordingly.
[
go to the top ]
What are the known issues with this release?
Linux:
1. Shared storage accessibility(ssa)
check reports
Current release of cluvfy has the following limitations on Linux regarding
shared storage accessibility check.
a. Currently NAS storage (
r/w, no attribute caching), OCFS( version 1.0.14 or higher ), OCFS2 and scsi
disks(if cvuqdisk package is installed) are supported. Note that, discovery of
scsi disks for RedHat Linux 2.1 is not supported.
b. For sharedness check on
NAS, cluvfy requires the user to have write permission on the specified path.
If the cluvfy user does not have write permission, cluvfy reports the path as
not-shared.
2. CVU does not recongnize the raw device paths ( e.g. /dev/raw/raw1
) as valid storage paths or identifiers. Please use the underlying disk( e.g.
/dev/sdm etc ) for the storage path or storage identifier. On Windows, use
"\Device\Harddisk<n>" notation such as
"\Device\Harddisk1" for the storage path or identifier.
3. Bug 4393736: CLUVFY SHOULD ENSURE A PARTITION EXISTS. DESCRIPTION:
On Linux, a partition like /dev/sda9 may not exist, but the file /dev/sda9
exists anyways. cluvfy comp ssa -n all -s /dev/sda9 reports this partition as
shared if the disk it belongs to (/dev/sda) is shared.
4. On Linux x86_64, Bug 6495320: On RHEL and OEL distributions, CVU
complains for missing 32-bit glibc package although i686 based glibc package
exist on the system. While checking for 32-bit glibc package existence, CVU
checks only for i386 based glibc package.
Solaris SPARC64
1. Shared storage accessibility(ssa)
check reports
Current release of cluvfy has the following limitations on Solaris regarding
shared storage accessibility check.
a. Currently NAS storage (
with required mount options) and SCSI disks are supported. Note that, discovery
of SCSI disks is possible if the "Serial No:" is available for the
shared disk when command ‘/usr/bin/iostat -En’ is issued.
b. For sharedness check on
NAS, cluvfy requires the user to have write permission on the specified path.
If the cluvfy user does not have write permission, cluvfy reports the path as
not-shared.
2. CVU does not recongnize the raw device paths ( e.g. /dev/raw/raw1 )
as valid storage paths or identifiers. Please use the underlying disk( e.g.
/dev/dsk/c0t1d0s0 etc ) for the storage path or storage identifier.
AIX
1. Shared storage accessibility(ssa)
check reports
Current release of cluvfy has the following limitations on AIX regarding shared
storage accessibility check.
a. Currently NAS storage (
with required mount options), GPFS and SCSI disks are supported.
b. For sharedness check on
NAS, cluvfy requires the user to have write permission on the specified path.
If the cluvfy user does not have write permission, cluvfy reports the path as
not-shared.
HPUX
1. Shared storage accessibility(ssa)
check reports
Current release of cluvfy has the following limitations on HPUX regarding
shared storage accessibility check.
a. Currently NAS storage (
with required mount options) is supported.
b. For sharedness check on
NAS, cluvfy requires the user to have write permission on the specified path.
If the cluvfy user does not have write permission, cluvfy reports the path as
not-shared.
2. On HPUX.PARISC, the following (ignorable) warning appears when cluvfy
is invoked with -verbose option:
warning: invalid plugin directory
‘<CVhome>/jdk15/jre/lib/PA_RISC2.0%/plugins/’
[
go to the top ]
What
OS versions and distributions are supported?
CVU is supported on all the OS versions and distributions on which Oracle
Clusterware 10g and Oracle Clusterware 11g are supported.
[
go to the top ]
________________________________________________________________________
Bookmark
