Running Subsets of Checks

3.1.7 Running Subsets of Checks

Run a subset of compliance checks where necessary.

These subsets can be a logical grouping determined by Oracle Autonomous Health Framework based on what the check is about.

You can also determine the subsets at an individual check level where you want to exclude or run only specific checks.

Upgrade Readiness Mode (Oracle Clusterware and Oracle Database Upgrade Checks)
You can use Upgrade Readiness Mode to obtain an Upgrade Readiness Assessment.
Running Checks on Subsets of the Oracle Stack
Run checks on subsets of Oracle stack such as, database, cell, switch, and so on.
Using Profiles with Oracle Autonomous Health Framework
Profiles are logical groupings of related checks. These related checks are grouped by a particular role, a task, or a technology.
Excluding Individual Checks
Excluding checks is recommended in situations where you have reviewed all check output and determined a particular check is not relevant for some particular business reason.
Running Individual Checks
There are times when you may want to run only specific checks.
Finding Which Checks Require Privileged Users
Use the Privileged User filter in the Health Check Catalogs to find health checks that must be run by privileged users, such as root.
Option to Run Only the Failed Checks
Option that enables Oracle Orachk and Oracle Exachk to run only the failed checks.

3.1.7.1 Upgrade Readiness Mode (Oracle Clusterware and Oracle Database Upgrade Checks)

You can use Upgrade Readiness Mode to obtain an Upgrade Readiness Assessment.

Upgrade Readiness Mode helps you plan the upgrade process for Oracle Cluster and Oracle RAC Database by automating many of the manual pre-checks and post-checks listed in the upgrade documentation.

There are two Upgrade Readiness modes:

Pre-upgrade check: Run this check during the planning phase of the upgrade process. Running this check helps you ensure that you have enough time to correct potential issues before the upgrade.
Post-upgrade check: Run this check after the upgrade to help you ensure the health of Oracle Grid Infrastructure and Oracle Database upgrades.

The Upgrade Readiness report provides the following information:

The target Clusterware and database versions. The report can only provide information for releases later than 11.2.0.3.
In pre-upgrade mode, the tool automatically detects all databases that are registered with Oracle Clusterware. It displays a list of these databases on which you can perform pre-upgrade checks.
In post-upgrade mode, the tool detects all databases registered with Oracle Clusterware. It displays a list of databases on which you can perform post-upgrade checks. If you select any release 11.2.0.3 or earlier releases, then the tool does not perform post-upgrade checks on these databases.
In both the modes, the tool checks the Oracle Clusterware stack and the operating system.

After the tool completes running, you are referred to the report. The report contains the upgrade readiness report and links where you can obtain additional information.

Oracle Clusterware and Oracle Database Pre-Upgrade Checks
During your pre-upgrade planning phase, run Oracle Autonomous Health Framework in pre-upgrade mode as the Oracle Database owner or as root.
Oracle Clusterware and Oracle Database Post-Upgrade Checks
After performing the upgrade, you can run in post-upgrade mode as the Oracle Database software owner or root to see further recommendations.

Parent topic: Running Subsets of Checks

3.1.7.1.1 Oracle Clusterware and Oracle Database Pre-Upgrade Checks

During your pre-upgrade planning phase, run Oracle Autonomous Health Framework in pre-upgrade mode as the Oracle Database owner or as root.

To start pre-upgrade checking, use the –preupgrade option:

$ orachk –preupgrade

$ exachk –preupgrade

The tool prompts you to specify the version that you are planning to upgrade to, and then runs all of the applicable checks for that specific version.

Output is similar to a standard HTML report output. However, the report shows checks that are relevant to upgrading Oracle Clusterware and Oracle Database to the version that you have specified.

Parent topic: Upgrade Readiness Mode (Oracle Clusterware and Oracle Database Upgrade Checks)

3.1.7.1.2 Oracle Clusterware and Oracle Database Post-Upgrade Checks

After performing the upgrade, you can run in post-upgrade mode as the Oracle Database software owner or root to see further recommendations.

To start post-upgrade checks, use the –postupgrade option:

$ orachk –postupgrade

$ exachk –postupgrade

Output is similar to a standard but shows only the checks that are relevant after upgrading the Clusterware and database.

Related Topics

HTML Report Output

Parent topic: Upgrade Readiness Mode (Oracle Clusterware and Oracle Database Upgrade Checks)

3.1.7.2 Running Checks on Subsets of the Oracle Stack

Run checks on subsets of Oracle stack such as, database, cell, switch, and so on.

Running Database Checks
During Oracle Autonomous Health Framework system checks, all Oracle Database logins are performed by using local connections.
Running Cell Checks
Limit the scope of compliance checks to a subset of storage servers by using the –cell cell option.
Running Switch Checks
Limit the scope of compliance checks to a subset of switches by using the –ibswitches switch option.
Running Checks on Other Elements of the Oracle Stack
The compliance checks are available for large parts of the Oracle software and hardware stack. The compliance check coverage is expanding with each new release.
Oracle Autonomous Health Framework Support for Oracle Grid Infrastructure with no Oracle Database
Oracle Autonomous Health Framework supports Oracle Grid Infrastructure stand-alone checks where no database is installed.

Parent topic: Running Subsets of Checks

3.1.7.2.1 Running Database Checks

During Oracle Autonomous Health Framework system checks, all Oracle Database logins are performed by using local connections.

The user running the tool must have operating system authenticated system privileges in the databases where you are running the tool.

Oracle software is installed by using an Oracle software installation owner, which is commonly referred to in Oracle documentation as the Oracle user. Your system can contain multiple Oracle Database homes all owned by the same Oracle user, for example, oracle. Your system can also contain multiple database homes owned by different Oracle users, for example, oracle1, oracle2, oracle3. If you have multiple Oracle Database homes configured, and these homes are owned by different Oracle users, then you must either run the tool as root user, or you must log in as the Oracle user for each Oracle database that you want to check. Use that Oracle user to run the tool on the Oracle Database instance on which the user is the software installation owner.

By default, Oracle Autonomous Health Framework presents a list of running databases that are registered with Oracle Grid Infrastructure. You can run the tools on one database, run the tools on all databases, or run the tool with a comma-delimited list of numbers that designate the databases listed. When you check multiple nodes running on the cluster, you do not need to stage the tool on the other nodes in the cluster to check the database instances running on those nodes.

To prevent prompting for which database to run against and check all databases, use the –dball option.
```
$ orachk -dball
```
```
$ exachk -dball
```
To prevent prompting and skip all database checks, use the –dbnone option.
```
$ orachk –dbnone
```
```
$ exachk –dbnone
```
To run checks against a subset of databases, use the –dbnames database_name option.
You can check multiple database instances by listing them in a comma-delimited list.
```
$ orachk –dbnames db1,db2,db3
```
```
$ exachk –dbnames db1,db2,db3
```
By default, Oracle Autonomous Health Framework runs checks on all database nodes in the cluster.
To run checks against a subset of PDBs, use the -pdbnames pdb_name option.
You can check multiple PDBs by listing them in a comma-delimited list.
```
$ orachk –pdbnames pdb1,pdb2,pdb3
```
```
$ exachk –pdbnames pdb1,pdb2,pdb3
```
By default, Oracle Autonomous Health Framework runs checks on all PDBs in the cluster.
To run checks against a subset of cluster nodes, use the -clusternodes node option.
You can check multiple cluster nodes by listing them in a comma-delimited list.
```
$ orachk –clusternodes node1,node2,node3
```
```
$ exachk –clusternodes node1,node2,node3
```
To run checks against the local node, use the -localonly option.
```
$ orachk -localonly
```
```
$ exachk -localonly
```

Parent topic: Running Checks on Subsets of the Oracle Stack

3.1.7.2.2 Running Cell Checks

Limit the scope of compliance checks to a subset of storage servers by using the –cell cell option.

To limit the scope to one cell, use the -cell option.
```
orachk -cell
```
```
exachk -cell
```
To limit the check to a set of cells, use a comma-delimited list of cells.
```
$ orachk –cell cell1,cell2,cell3
```
```
$ exachk –cell cell1,cell2,cell3
```

Parent topic: Running Checks on Subsets of the Oracle Stack

3.1.7.2.3 Running Switch Checks

Limit the scope of compliance checks to a subset of switches by using the –ibswitches switch option.

To limit the scope to one switch, use the –ibswitches option.
```
$ orachk –ibswitches
```
```
$ exachk –ibswitches
```
To limit the check to a set of switches, use a comma-delimited list of switches.
```
$ orachk –ibswitches switch1,switch2
```
```
$ exachk –ibswitches switch1,switch2
```

Parent topic: Running Checks on Subsets of the Oracle Stack

3.1.7.2.4 Running Checks on Other Elements of the Oracle Stack

The compliance checks are available for large parts of the Oracle software and hardware stack. The compliance check coverage is expanding with each new release.

The compliance checks are organized into logical groupings, which are called profiles. You can run subsets of checks for different areas of the Oracle stack by the applicable profile.

Refer to the Using Profiles section for a list of available profiles.

Parent topic: Running Checks on Subsets of the Oracle Stack

3.1.7.2.5 Oracle Autonomous Health Framework Support for Oracle Grid Infrastructure with no Oracle Database

Oracle Autonomous Health Framework supports Oracle Grid Infrastructure stand-alone checks where no database is installed.

To run Oracle Grid Infrastructure checks in an environment where Oracle Database is not installed, use the option:

-nordbms

For example:

$ orachk -nordbms

$ exachk -nordbms

Parent topic: Running Checks on Subsets of the Oracle Stack

3.1.7.3 Using Profiles with Oracle Autonomous Health Framework

Profiles are logical groupings of related checks. These related checks are grouped by a particular role, a task, or a technology.

The following table describes the profiles that you can use:

Table 3-5 List of Available Profiles for Oracle Autonomous Health Framework Checks

Profile	Description
`asm`	Oracle Automatic Storage Management checks.
`exatier1`	Exadata only checks with a critical alert level. These represent the top tier of problems with the most severe likely impact. You must fix the problems marked as critical as soon as possible.
`patches`	Oracle patch checks.
`bi_middleware`	Oracle Business Intelligence checks.
`clusterware`	Oracle Clusterware checks.
`compute_node`	Compute Node checks (Oracle Exalogic only).
`control_VM`	Checks only for Oracle Virtual Machine Control VM (`ec1-vm`, `ovmm`, `db`, `pc1`, `pc2`). No cross-node checks.
`corroborate`	Oracle Exadata checks, which you must review to determine pass or fail.
`dba`	Database Administrator (DBA) Checks.
`ebs`	Oracle E-Business Suite checks.
`el_extensive`	Extensive EL checks.
`el_lite`	Exalogic-Lite Checks(Oracle Exalogic Only).
`el_rackcompare`	Data Collection for Exalogic Rack Comparison Tool (Oracle Exalogic Only).
`emagent`	Oracle Enterprise Manager Cloud Control agent checks.
`emoms`	Oracle Enterprise Manager Cloud Control management server.
`em`	Oracle Enterprise Manager Cloud Control checks.
`goldengate`	Oracle GoldenGate checks.
`hardware`	Hardware-specific checks for Oracle Engineered systems.
`maa`	Maximum Availability Architecture Checks.
`nimbula`	Nimbula checks for Oracle Exalogic.
`oam`	Oracle Access Manager checks.
`obiee`	OBIEE Checks (Oracle Exalytics Only)
`oim`	Oracle Identity Manager checks.
`oud`	Oracle Unified Directory server checks.
`ovn`	Oracle Virtual Networking.
`peoplesoft`	Peoplesoft best practices.
`platinum`	Platinum certification checks.
`preinstall`	Preinstallation checks.
`prepatch`	Checks to complete before patching.
`security`	Security checks.
`siebel`	Siebel Checks.
`solaris_cluster`	Oracle Solaris Cluster Checks.
`storage`	Oracle Storage Server Checks.
`switch`	InfiniBand switch checks.
`sysadmin`	System administrator checks.
`timesten`	Oracle TimesTen checks (Oracle Exalytics Only).
`user_defined_checks`	Run user-defined checks from `user_defined_checks.xml`.
`virtual_infra`	Oracle VM Server (OVS), Control VM, network time protocol (NTP), and stale virtual network interface cards (VNICs) check (Oracle Exalogic Only).
`zfs`	Oracle ZFS Storage Appliances checks (Oracle Exalogic Only).

You can run the command with an inclusion list, so that it runs only the checks in particular profiles. Run the command with the option –profile profile_name. You can run multiple profiles by running the command with a comma-delimited inclusion list. The inclusion list contains only the profiles that you want to run.

$ orachk –profile dba,clusterware

$ exachk –profile dba,clusterware

The output of inclusion list profile checks is similar to the standard HTML Report Output format. However, profile inclusion check reports show only output of checks that are in the specific profiles that you specify in the check.

Excluding profiles

You can also run the command with exclusion list. Run the command with the option –excludeprofile profile_name. When you run the command with an exclusion list, all profile checks are performed except for the checks in the profile that you list. You can list multiple profiles to exclude by running the command with a comma-delimited exclusion list.

$ orachk –excludeprofile dba,clusterware,ebs

$ exachk –excludeprofile dba,clusterware,ebs

The output of exclusion list profile checks is similar to the standard HTML Report Output format. However, profile exclusion check reports show only the checks that are not in the profiles that you specify to exclude in the check.

Including profiles

Use -includeprofile to specify a comma-delimited list of profiles to add profile specific checks to the existing checks list.

ahfctl compliance -includeprofile profile1, profile2...
orachk -includeprofile profile1, profile2...
exachk -includeprofile profile1, profile2...

Note:

You cannot:

use -includeprofile and -profile options together
use -includeprofile and -excludeprofile options together

Use the -profile option to specify a comma-delimited list of profiles to run only the checks in the specified profiles.

Use the -excludeprofile option to specify a comma-delimited list of profiles to exclude from the compliance check run.

Related Topics

HTML Report Output

Parent topic: Running Subsets of Checks

3.1.7.4 Excluding Individual Checks

Excluding checks is recommended in situations where you have reviewed all check output and determined a particular check is not relevant for some particular business reason.

This allows the compliance check HTML report to be streamlined to show only the problems you need to fix.

You can exclude checks in two different ways. Both the methods require you to find the check IDs.

The first method is to use the –excludecheck check_id option. To exclude multiple check IDs, use the comma-delimited list of check IDs:

$ orachk –excludecheck 0829D67E8B1549AFE05312C0E50AD04F,CB95A1BF5B1160ACE0431EC0E50A12EE

$ exachk –excludecheck 0829D67E8B1549AFE05312C0E50AD04F,CB95A1BF5B1160ACE0431EC0E50A12EE

All excluded files are shown in the Excluded Checks section of the report.

Figure 3-29 Excluding Checks - Method I

Description of "Figure 3-29 Excluding Checks - Method I"

The second method of excluding individual checks is as follows:

You must create a file called excluded_check_ids.txt and put all the check IDs that you want to exclude in the file one check per line.
You must place the file in the following directory depending on your exachk version:
- For version 23.5 and down: $AHF_HOME/exachk/.
  Run the exachk -showahfhome commaned to get AHF_HOME.
- For version 23.6 and up: $EXACHK_DATA_DIR/.
  Run the exachk -showdatadir command to get EXACHK_DATA_DIR.
This will affect exachk being run manually or being called from another utility.

The excluded_check_ids.txt file remains in this directory. Each time the tool is run, all applicable compliance checks are run except those specified in the file.

All excluded files are shown in the Excluded Checks section of the report.

Figure 3-30 Excluded Checks

Description of "Figure 3-30 Excluded Checks"

Parent topic: Running Subsets of Checks

3.1.7.5 Running Individual Checks

There are times when you may want to run only specific checks.

Running individual check can particularly be useful in situations such as:

Quickly verify if a particular issue has been fixed
Troubleshoot performance or run specific checks
Develop and test user-defined checks

Find the check ids before you run individual checks.

To run only specific checks use the –check check_id option.

To run multiple check ids, use the comma-delimited list of check ids:

$ orachk –check 0829D67E8B1549AFE05312C0E50AD04F,CB95A1BF5B1160ACE0431EC0E50A12EE

$ exachk –check 0829D67E8B1549AFE05312C0E50AD04F,CB95A1BF5B1160ACE0431EC0E50A12EE

Related Topics

How to Find a Check ID

Parent topic: Running Subsets of Checks

3.1.7.6 Finding Which Checks Require Privileged Users

Use the Privileged User filter in the Health Check Catalogs to find health checks that must be run by privileged users, such as root.

Enable Javascript before you view the Health Check Catalogs.

To filter health checks by privileged users:

Go to My Oracle Support note 2550798.1.
Click the Health Check Catalog tab.
Click Open Oracle Orachk Health Check Catalog to open or download the ORAchk_Health_Check_Catalog.html file.
Click the Privileged User drop-down list and then clear or select the check boxes appropriately.

Figure 3-31 Oracle Orachk - Privileged User

Description of "Figure 3-31 Oracle Orachk - Privileged User"

Figure 3-32 Oracle Exachk - Privileged User

Description of "Figure 3-32 Oracle Exachk - Privileged User"

Related Topics

https://support.oracle.com/epmos/faces/DocumentDisplay?cmd=show&type=NOT&id=2550798.1

Parent topic: Running Subsets of Checks

3.1.7.7 Option to Run Only the Failed Checks

Option that enables Oracle Orachk and Oracle Exachk to run only the failed checks.

To run only the checks that failed previously:

Generate a compliance check report
Fix the issues identified
Generate another compliance check report verifying only the issues that failed before

Use the failed checks option by passing in the HTML report, zip, or directory.

-failedchecks previous_result

Parent topic: Running Subsets of Checks