So the other day I was doing an install of the Clusterware binaries and came around that with the cluvfy tool in comes now with a health check option for the Database. For this option to work you have to install or setup the cvusys user as well as the cvusapp role, a script for this, is in the CLUVFY_HOME/cv/admin directory

As the oracle user run the $CLUVFY_HOME/cv/admin/cvusys.sql script to setup the mentioned user and role as well as the grants needed. This user will use the Database default tablespace, so if you want to set it up in a different tablespace you would need to modify this script.

oracle@servidor1.localdomain [TESTDB1] /home/oracle
oracle $ id
uid=54321(oracle) gid=54321(oinstall) groups=54321(oinstall),501(vboxsf),54322(dba)

TESTDB1> @cvusys.sql

User dropped.

Role dropped.

Enter password for user cvusys
'Creating user cvusys...'

User created.

Grant succeeded.

Role created.

Grant succeeded.


Once you have setup the cluvfy healthcheck user, as the grid user, verify that your environment is setup for the correct $GRID_HOME.

grid@servidor1.localdomain /home/grid
oracle $ id
uid=54324(grid) gid=54321(oinstall) groups=54321(oinstall),501(vboxsf),54322(dba),54323(asmadmin),54325(asmoper)

grid@servidor1.localdomain /home/grid
oracle $ echo $ORACLE_HOME

As I came up that if the $GRID_HOME is setup incorrectly or that you pass the database name in the wrong letter case you can receive the following error PRVG-11005, even though that you will see that in the $CLUVFY_HOME/cv/log the srvctl config database is finishing successfully.

grid@servidor1.localdomain /home/grid
oracle $ cluvfy comp healthcheck -collect database -db TESTDB -deviations -save -savedir /home/grid/audit

PRVG-11005 : Database "TESTDB" is not defined in this cluster

grid@servidor1.localdomain /home/grid/cv/log
root $ more cvutrace.log.0
[17455@servidor1.localdomain] [Worker 0] [ 2012-11-04 22:41:33.595 EST ] [VerificationCommand.execute:232] Formatted exectask output is:
<CV_CMD>/mount/oracle/ config database -d TESTDB -a </CV_CMD><CV_VAL>Database unique name: TESTDB
Database name: TESTDB
Oracle home: /mount/oracle/
Oracle user: oracle
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools: TESTDB
Database instances: TESTDB1,TESTDB2
Disk Groups: DATA
Mount point paths:
Type: RAC
Database is enabled
Database is administrator managed
</CV_VAL><CV_VRES>0</CV_VRES><CV_LOG>Exectask: runexe was successful</CV_LOG><CV_ERES>0</CV_ERES>

Also you can run this against all the Databases in the cluster by leaving out the out, but just take in mind that you will need to setup the cvusys user for all the Databases in the cluster, as well you can verify the best practices or what is mandatory for the Database and how does your Database deviates from this [-bestpractice|-mandatory] [-deviations].

So in this case I run it with the lower case name and with the option of deviations from the best practice, and it finished successfully.

grid@servidor1.localdomain /home/grid/cv/log
root $ cluvfy comp healthcheck -collect database -db testdb -bestpractice -deviations -save -savedir /home/grid/audit/

Verifying Database "testdb"

Please specify password for user "cvusys" :

Verifying Database Best Practice for "testdb"

Verifying JVM configuration for database ...not met
Verifying Java Role Count ...not met
Verifying Duplicate SYS or SYSTEM Schema Objects ...not met
Verifying Users Granted CONNECT Role ...not met
Verifying DB Log Mode ...not met

Summary of environment

Date (mm/dd/yyyy) : 11/05/2012
Time (hh:mm:ss) : 22:37:28
Cluster name : cluster-test
Clusterware version :
Grid home : /mount/oracle/
Grid User : grid
Operating system : Linux2.6.18-238.el5
Database1 : Database name - testdb
Database version -
Database home -

Database recommendation checks for "testdb"

Now just head over to the location where you saved your report and see the deviations from Oracle’s best practice, now here is where I would have to say that you need to verify before doing some of these changes as a recommendation I got was that I was running in ARCHIVELOG_MODE vs recommended NONARCHIVELOG mode, I hope you see the irony here. But if you are not doing a health check of your databases after you do a fresh install, this is a great start and will get you thinking how I can make my environment better.


Verification Check : Duplicate SYS or SYSTEM Schema Objects
Verification Description : Checks for duplicate SYS or SYSTEM schema objects
Verification Result : NOT MET
Verification Summary : Check for Duplicate SYS or SYSTEM Schema Objects failed
Additional Details : If any duplicate objects were found in the SYS and SYSTEM
schemas, refer to articles in the references section. Read
the exceptions carefully before taking action.
References (URLs/Notes) :

Node Status Expected Value Actual Value

testdb FAILED sys_duplicate_obj = 0 sys_duplicate_obj = 4


Verification Check : INVALID objects in the application related schemas
Verification Description : Checks for the presence of INVALID objects in the
application related schemas (non SYS and SYSTEM)
Verification Result : NOT MET
Verification Summary : Check for INVALID objects in the application related
schemas failed
Additional Details : Investigate invalid objects in the application related
schemas (non SYS and SYSTEM).

Node Status Expected Value Actual Va lue

testdb FAILED app_invalid_obj = 0 app_invalid_obj = 5