Understanding and Managing Reports and Output

Temporary Files and Directories

During compliance check runs, Oracle Orachk and Oracle Exachk create temporary files and directories for data collection and assessment. These temporary files and directories are deleted after the compliance check completes.

By default, Oracle Orachk and Oracle Exachk create temporary files and directories in the following locations:

/opt/oracle.SupportTools/orachk for Oracle Orachk, if the directory exists.
/opt/oracle.SupportTools/exachk for Oracle Exachk, if the directory exists.
The $HOME directory of the user running the tool if the applicable Oracle Support Tools directory does not exist.

To use a different temporary working directory, set the RAT_TMPDIR environment variable before running Oracle Orachk or Oracle Exachk.

For example, to use /tmp with Oracle Orachk:

export RAT_TMPDIR=/tmp
orachk

To use /tmp with Oracle Exachk:

export RAT_TMPDIR=/tmp
exachk

Note:

The directory specified by RAT_TMPDIR must exist on every host in the cluster.

If you use sudo to run checks that require root privileges and change the temporary directory using RAT_TMPDIR, update the /etc/sudoers file on each applicable server to reference the root script in the new temporary directory.

For Oracle Orachk:

oracle ALL=(root) NOPASSWD:/tmp/root_orachk.sh

For Oracle Exachk:

oracle ALL=(root) NOPASSWD:/tmp/root_exachk.sh

Alternatively, use the RAT_ROOT_SH_DIR environment variable to change only the directory where the root script is created.

For example:

export RAT_ROOT_SH_DIR=/mylocation

Then add the corresponding entry to /etc/sudoers.

For Oracle Orachk:

oracle ALL=(root) NOPASSWD:/mylocation/root_orachk.sh

If you use Oracle Exachk, configure the corresponding root_exachk.sh path for the selected location.

Output Files and Directories

Oracle Orachk and Oracle Exachk create an output directory that contains various files for you to examine.

The name format of the output directory is:

utility_name host_name database date time_stamp

where,

`*utility* is either orachk or exachk`
`*host_name*` is the host name of the node on which Oracle Orachk or Oracle Exachk was run
`*database*` is the name of the database or one of the databases against which compliance checks were performed, if applicable
`*date*` is the date the compliance check was run
`*timestamp*` is the time the compliance check was run

By default, Oracle Orachk and Oracle Exachk create output in the directory from where they are run. To change the location of the output directory, use the -output option as follows:

$ orachk -output output_dir

$ exachk -output output_dir

Alternatively, set the output directory using the RAT_OUTPUT environment variable as follows:

$ export RAT_OUTPUT=output_dir
$ orachk

$ export RAT_OUTPUT=output_dir
$ exachk

The contents of this directory is available in a zip file with the same name.

After completing the compliance checks, Oracle Orachk and Oracle Exachk report the location of this zip file and the HTML report file.

...
Detailed report (html) - /orahome/oradb/orachk/orachk_myhost_rdb11204_041816_055429/orachk_myhost_rdb11204_041816_055429.html

UPLOAD(if required) - /orahome/oradb/orachk/orachk_myhost_rdb11204_041816_055429.zip

$ ls -la
total 61832
drwxr-xr-x  4 oradb oinstall     4096 Apr 18 05:55 .
drwx------ 34 oradb oinstall     4096 Apr 18 05:58 ..
drwxr--r--  3 oradb oinstall     4096 Mar 28 17:36 .cgrep
-rw-r--r--  1 oradb oinstall  4692868 Mar 28 17:35 CollectionManager_App.sql
-rw-r--r--  1 oradb oinstall 41498425 Apr 18 05:54 collections.dat
-rwxr-xr-x  1 oradb oinstall  2730651 Mar 28 17:35 orachk
drwxr-xr-x  7 oradb oinstall     4096 Apr 18 05:55 orachk_myhost_rdb11204_041816_055429
-rw-r--r--  1 oradb oinstall    36141 Apr 18 05:55 orachk_myhost_rdb11204_041816_055429.zip
-rw-r--r--  1 oradb oinstall  9380260 Mar 28 19:02 orachk.zip
-rw-r--r--  1 oradb oinstall     3869 Mar 28 17:36 readme.txt
-rw-r--r--  1 oradb oinstall  4877997 Apr 18 05:54 rules.dat
-rw-r--r--  1 oradb oinstall    40052 Mar 28 17:35 sample_user_defined_checks.xml
-rw-r--r--  1 oradb oinstall     2888 Mar 28 17:35 user_defined_checks.xsd
-rw-r--r--  1 oradb oinstall      425 Mar 28 17:36 UserGuide.txt

The output directory contains several other directories and the main HTML report file.

$ cd orachk_myhost_rdb11204_041816_055429
$ ls -la
total 60
drwxr-xr-x 7 oradb oinstall  4096 Apr 18 05:55 .
drwxr-xr-x 4 oradb oinstall  4096 Apr 18 05:55 ..
drwxr-xr-x 2 oradb oinstall  4096 Apr 18 05:55 log
-rw-r--r-- 1 oradb oinstall 30815 Apr 18 05:55 orachk_myhost_rdb11204_041816_055429.html
drwxr-xr-x 4 oradb oinstall  4096 Apr 18 05:55 outfiles
drwxr-xr-x 2 oradb oinstall  4096 Apr 18 05:55 reports
drwxr-xr-x 2 oradb oinstall  4096 Apr 18 05:55 scripts
drwxr-xr-x 2 oradb oinstall  4096 Apr 18 05:55 upload

Oracle Oracle Orachk and Oracle Exachk each creates an output directory containing the following information depending on which tool you use:

Output Files and Directories

Output	Description
`log (directory)`	Contains several log files recording details about the compliance check, including: Oracle Orachk : `orachk.log`: Main log for the compliance check. `orachk_error.log`: `std_error` log for the compliance check. `orachk_debug_datetime.log`: Debug output when run with `-debug`, which is useful for troubleshooting. Oracle Exachk : `exachk.log`: Main log for the compliance check. `exachk_error.log`: `std_error` log for the compliance check. `exachk_debugdate_time.log`: Debug output when run with `-debug`, which is useful for troubleshooting.
`outfiles (directory)`	Contains several the collection results.
`reports (directory)`	Contains subreports used to build the main report.
`scripts (directory)`	Contains scripts used during collection.
`upload (directory)`	Contains files to upload collection results to a database for the Oracle Health Check Collections Manager to consume, integrate the results into your own application, or integrate into other utilities.
`orachk_*.html`	Oracle Orachk : Main HTML report output using the same name format as the output directory: `orachk_host_namedatabasedate_timestamp.html`.
`exachk_*.html`	Oracle Exachk : Main HTML report output using the same name format as the output directory: `exachk_host_namedatabasedate_timestamp.html`.

HTML Report Output

The compliance check HTML report contains the following:

High level health score
Summary of the run
Table of contents that provides easy access to findings
Findings and recommendations to resolve the issues

System Health Score and Summary

Oracle Orachk and Oracle Exachk calculate a high-level System Health Score based on the results of compliance checks.

The report summary provides information about the compliance check run, including:

Where the compliance check was run.
When the compliance check was run.
Oracle Orachk or Oracle Exachk version used.
Time taken to complete the run.
User who ran the compliance check.

The System Health Score provides an overall indication of system compliance based on passed and failed checks.

Click detail in the System Health Score section to view additional information about how the score is calculated.

To generate an HTML report without the System Health Score section, use the -noscore option.

For Oracle Orachk:

orachk -noscore

For Oracle Exachk:

exachk -noscore

HTML Report Table of Contents and Features

The Oracle Orachk and Oracle Exachk HTML reports include a Table of Contents and Report Features to help you navigate, filter, and customize the displayed compliance check results.

Table of Contents

The Table of Contents provides links to the major sections of the HTML report.

The sections displayed in the Table of Contents depend on the Oracle stack components discovered during the compliance check run.

Use the Table of Contents to navigate directly to a specific section of the report.

Report Features

Use the Report Features to customize how compliance check results are displayed.

You can:

Filter checks by status.
Select the report regions to display.
Expand or collapse all checks.
Display check IDs.
Remove findings from the report.
Generate a printable view of the report.

By default, checks with a Pass status are hidden. To display passed checks, select Pass under Show Checks with the following status.

To exclude passed checks entirely when generating the HTML report, use the -nopass option.

For Oracle Orachk:

orachk -nopass

For Oracle Exachk:

exachk -nopass

Security Checks Section in Oracle Orachk and Oracle Exachk Reports

Starting with Oracle Autonomous Health Framework (AHF) 24.5, Oracle Orachk and Oracle Exachk reports include a Security section that consolidates best practice checks related to system security.

The Security section contains selected security controls that can affect the overall security posture of the system. These controls help identify configurations and conditions that might require further review.

Security controls are commonly evaluated based on their impact on the following security objectives:

Confidentiality - Protects information from unauthorized access and disclosure, including personal, sensitive, and proprietary information.
Integrity - Protects information from unauthorized modification or destruction and helps maintain its authenticity and trustworthiness.
Availability - Helps ensure that information and systems are accessible and usable when required.

These objectives are commonly referred to as the Confidentiality, Integrity, and Availability (CIA) triad.

Review the findings in the Security section and address applicable recommendations based on your organization's security requirements and policies.

For additional security guidance, see Oracle Exadata Database Machine Security FAQ (Doc ID 2751741.1).

HTML Report Findings

Oracle Orachk and Oracle Exachk group report findings by Oracle stack component to help you identify and review compliance issues across the environment.

Each finding provides information such as:

Check status: FAIL, WARNING, INFO, or PASS
Check type
Check message
Location where the check was run
A link to view additional details, findings, and recommendations

Click view details for a finding to display additional diagnostic information and recommendations.

The detailed information can include:

A solution for resolving the identified problem.
Applicable recommendations.
Conditions under which the finding does not apply.
Links to relevant Oracle documentation or My Oracle Support notes.
Example data on which the recommendation is based.

Use the detailed findings and recommendations to evaluate the issue and determine the appropriate corrective action for your environment.

CRITICAL and FAIL Findings

CRITICAL and FAIL findings are displayed by default in the report view. The report summary also highlights the CRITICAL and FAIL counts, making urgent findings easier to identify.

Maximum Availability Architecture (MAA) Scorecard

The Maximum Availability Architecture (MAA) Scorecard appears after the findings in the Oracle Orachk and Oracle Exachk HTML reports.

The MAA Scorecard evaluates the environment against Oracle Maximum Availability Architecture best practices and provides results related to system availability.

The scorecard can identify areas such as:

Compliance with MAA best practices.
Installed software versions that are not current.
Use of incompatible features.
Configuration conditions that can affect maximum availability.

Use the MAA Scorecard to review the environment against recommended availability practices and identify areas that might require corrective action.

To generate an HTML report without the MAA Scorecard section, use the -m option.

For Oracle Orachk:

orachk -m

For Oracle Exachk:

exachk -m

Findings Needing Further Review

The Findings needing further review section displays findings for which Oracle Orachk or Oracle Exachk has only partial information and cannot determine conclusively whether the identified condition applies to your environment.

These findings require manual review to determine their relevance and whether corrective action is necessary.

Review each finding to:

Determine whether the identified condition applies to your environment.
Evaluate the potential impact.
Review the available recommendations and supporting information.
Determine whether corrective action is required.

Platinum Certification

The Platinum Certification section displays the compliance status of requirements associated with the Oracle Platinum service.

For existing Oracle Platinum customers, use this section to review the current compliance status of the environment.

For customers who are not currently participating in Oracle Platinum, use the results to assess the environment's readiness for Oracle Platinum.

Note:

The Platinum Certification section is displayed when compliance checks are run on Oracle Engineered Systems.

Viewing Clusterwide Linux Operating System Compliance Check (VMPScan)

On Linux systems, the Oracle Orachk compliance check report includes a Clusterwide Linux Operating System Health Check (VMPScan) section.

This section provides a summary of the VMPScan results for the Linux systems in the cluster.

The complete VMPScan report is also available in the following locations within the diagnostic collection:

<collection>/reports

and:

<collection>/outfiles/vmpscan

Use the summary in the compliance check report for a high-level assessment and the full VMPScan report when you need more detailed information.

Note:

The VMPScan report is included only when Oracle Orachk is run on Linux systems.

"Systemwide Automatic Service Request (ASR) healthcheck" Section

The Systemwide Automatic Service Request (ASR) Health Check section provides information about the configuration and connectivity of Automatic Service Request (ASR).

The asrexacheck utility checks and tests ASR configurations to verify that communication with the ASR Manager is possible.

asrexacheck is non-invasive. It checks existing configurations and does not modify system or configuration files.

The health check identifies:

Known ASR configuration issues.
Communication issues with the ASR Manager.
Previous hardware faults that might not have been reported by ASR because of a configuration issue.

Use the results to identify ASR configuration problems that could prevent hardware faults from being reported correctly.

Note:

The Systemwide Automatic Service Request (ASR) Health Check section is included only when compliance checks are run on Oracle Engineered Systems.

File Attribute Changes

The File Attribute Changes section displays changes detected in file attributes during an Oracle Orachk or Oracle Exachk compliance check.

This section is included in the HTML report only when you run Oracle Orachk or Oracle Exachk with the -fileattr option.

For Oracle Orachk:

orachk -fileattr

For Oracle Exachk:

exachk -fileattr

Use the File Attribute Changes section to review file attribute changes identified during the compliance check.

Skipped Checks

The Skipped Checks section lists compliance checks that Oracle Orachk or Oracle Exachk could not run and therefore skipped during the compliance check.

Review this section to identify checks that were not performed and determine whether additional configuration, permissions, or other corrective actions are required before running the checks again.

Component Elapsed Times

The Component Elapsed Times section provides a breakdown of the time Oracle Orachk or Oracle Exachk takes to check individual components during a compliance check run.

Use this information to identify components that require more time to process and to help diagnose performance issues associated with compliance check runs.

Top 10 Time Consuming Checks

The Top 10 Time Consuming Checks section lists the 10 compliance checks that took the longest to complete during an Oracle Orachk or Oracle Exachk run.

Use this information to identify checks that contribute the most to the overall run time and to help diagnose performance issues associated with compliance check runs.

How to Find a Check ID

Each Oracle Orachk and Oracle Exachk compliance check has a unique 32-character check ID.

You might need a check ID when:

Communicating with Oracle Support or internal teams about a specific compliance check.
Excluding one or more specific checks from a compliance check run.
Running only one or more specific checks.

To find a check ID in a generated Oracle Orachk or Oracle Exachk report:

Open the generated HTML report.
Click Show Check Ids.

The report displays an additional Check Id column next to the findings. Use the value in this column to identify the corresponding compliance check.

Finding Execution Time (in Seconds) for Checks

Starting with Oracle Autonomous Health Framework (AHF) 26.1, Oracle Orachk and Oracle Exachk reports can display the execution time, in seconds, for each compliance check.

Use this information to understand how time is distributed across checks during a compliance check run and to identify checks that take longer to complete and might require further investigation or tuning.

To view the execution time for individual checks:

Open the generated HTML report.
In the left pane, locate Other Settings.
Select Show Check Timings.

The report displays the execution time for each check.

For easier identification and correlation of checks, use Show Check Timings together with Show Check IDs. This enables you to associate each execution time with the unique ID of the corresponding compliance check.

How to Remove Checks from an Existing HTML Report

You can hide individual findings from an existing Oracle Orachk or Oracle Exachk HTML report.

To hide a finding:

Open the generated HTML report.
Click Remove finding from report.
An X appears next to each finding.
Click the X next to the finding that you want to hide.

The finding is hidden from the current view.

Note:
Hiding a finding does not remove it from the source data of the HTML report. If you reload the original report, the finding appears again.
To preserve the report with the selected findings hidden, use your browser's Save Page option after hiding the findings.

If there are checks that you never want to include in a report, exclude those checks from the compliance check run instead. Excluded checks are not run and therefore do not appear as findings in the generated report.

Tagging Reports

Oracle Orachk and Oracle Exachk generate HTML report names using information such as the host, database, date, and timestamp.

The default report names follow formats similar to:

orachk_<host_name>_<database>_<date>_<timestamp>.html

or:

exachk_<host_name>_<database>_<date>_<timestamp>.html

Use the -tag option to add a custom tag to the report name. Tags can help you differentiate and identify reports for specific activities, environments, or purposes.

To add a tag to an Oracle Orachk report:

orachk -tag <tag_name>

To add a tag to an Oracle Exachk report:

exachk -tag <tag_name>

The generated report name includes the custom tag.

For Oracle Orachk:

orachk_<host_name>_<database>_<date>_<timestamp>_<tag_name>.html

For Oracle Exachk:

exachk_<host_name>_<database>_<date>_<timestamp>_<tag_name>.html

For example, to identify a report generated before an upgrade:

orachk -tag pre_upgrade

The resulting report name is similar to:

orachk_<host_name>_<database>_<date>_<timestamp>_pre_upgrade.html

Tracking File Attribute Changes and Comparing Snapshots

Use the Oracle Orachk and Oracle Exachk -fileattr option and command flags to record and track file attribute settings, and compare snapshots.

Changes to the attributes of files such as owner, group, or permissions can cause unexpected consequences. Proactively monitor and mitigate the issues before your business gets impacted.

Using the File Attribute Check with the Daemon

Use the Oracle Orachk file attribute check with the daemon to capture and compare file attribute information.

Oracle Grid Infrastructure must be installed and running before you use the -fileattr option.

Start the Oracle Orachk daemon:
```
orachk -d start
```
Create an initial file attribute snapshot.

Use -includedir to specify the files or directories to include. Use -excludediscovery when you want to exclude files discovered automatically by Oracle Orachk.

For example:
```
orachk -fileattr start -includedir "/root/myapp,/etc/oratab" -excludediscovery
```
After making changes to the monitored files or directories, run the file attribute check:
```
orachk -fileattr check -includedir "/root/myapp,/etc/oratab" -excludediscovery
```
To specify where Oracle Orachk stores the snapshots, use the -output option.

For example:
```
orachk -fileattr start -output "/tmp/mysnapshots"
```
To assign a descriptive name to a snapshot, use the -tag option.

For example:
```
orachk -fileattr start -tag "BeforeXYZChange"
```
The generated snapshot directory is similar to:
```
orachk_myserver65_20160329_052056_BeforeXYZChange
```

Use descriptive tags to distinguish snapshots captured before and after configuration or system changes.

Taking File Attribute Snapshots

Use the -fileattr start option to capture a snapshot of file attributes.

By default, Oracle Orachk and Oracle Exachk include the Oracle Grid Infrastructure home and all installed Oracle Database homes in the snapshot.

To create the initial file attribute snapshot, run one of the following commands.

For Oracle Orachk:

orachk -fileattr start

For Oracle Exachk:

exachk -fileattr start

The following example shows Oracle Orachk creating a file attribute snapshot:

$ orachk -fileattr start

CRS stack is running and CRS_HOME is not set.
Do you want to set CRS_HOME to /u01/app/11.2.0.4/grid?[y/n][y]

Checking ssh user equivalency settings on all nodes in cluster

Node mysrv22 is configured for ssh user equivalency for oradb user
Node mysrv23 is configured for ssh user equivalency for oradb user

List of directories(recursive) for checking file attributes:

/u01/app/oradb/product/11.2.0/dbhome_11202
/u01/app/oradb/product/11.2.0/dbhome_11203
/u01/app/oradb/product/11.2.0/dbhome_11204

orachk has taken snapshot of file attributes for above directories at:

/orahome/oradb/orachk/orachk_mysrv21_20160504_041214

The generated snapshot records file attributes for the selected directories and can be used as a baseline for identifying subsequent file attribute changes.

Including Directories to Check

Use the -includedir option to include additional directories in the file attribute check.

Specify the directories as a comma-separated list:

-includedir "<directory1>,<directory2>,..."

For example, to include /home/oradb and /etc/oratab when creating a file attribute snapshot with Oracle Orachk:

orachk -fileattr start -includedir "/home/oradb,/etc/oratab"

For Oracle Exachk:

exachk -fileattr start -includedir "/home/oradb,/etc/oratab"

The specified directories are included in addition to the directories discovered by default.

The following example includes /root/myapp/config/ in an Oracle Orachk file attribute snapshot:

$ orachk -fileattr start -includedir "/root/myapp/config/"

CRS stack is running and CRS_HOME is not set.
Do you want to set CRS_HOME to /u01/app/12.2.0/grid?[y/n][y]

Checking for prompts on myserver18 for oragrid user...
Checking ssh user equivalency settings on all nodes in cluster

Node myserver17 is configured for ssh user equivalency for root user

List of directories(recursive) for checking file attributes:

/u01/app/12.2.0/grid
/u01/app/oradb/product/12.2.0/dbhome_1
/u01/app/oradb2/product/12.2.0/dbhome_1
/root/myapp/config/

orachk has taken snapshot of file attributes for above directories at:

/root/orachk/orachk_myserver18_20160511_032034

Oracle Orachk recursively checks file attributes in the specified directories and includes them in the generated snapshot.

Excluding Directories from Checks

Use the -excludediscovery option to exclude automatically discovered directories from file attribute checks.

When you specify -excludediscovery with -includedir, Oracle Orachk or Oracle Exachk checks only the directories explicitly specified by -includedir. Directories that the tool normally discovers automatically, such as Oracle Grid Infrastructure and Oracle Database homes, are excluded.

For example, to check only /root/myapp/config/:

orachk -fileattr start -includedir "/root/myapp/config/" -excludediscovery

The following example shows Oracle Orachk creating a snapshot that contains only the explicitly specified directory:

$ orachk -fileattr start -includedir "/root/myapp/config/" -excludediscovery

CRS stack is running and CRS_HOME is not set.
Do you want to set CRS_HOME to /u01/app/12.2.0/grid?[y/n][y]

Checking for prompts on myserver18 for oragrid user...
Checking ssh user equivalency settings on all nodes in cluster

Node myserver17 is configured for ssh user equivalency for root user

List of directories(recursive) for checking file attributes:

/root/myapp/config/

orachk has taken snapshot of file attributes for above directories at:

/root/orachk/orachk_myserver18_20160511_032209

In this example, Oracle Orachk checks /root/myapp/config/ recursively and does not include directories discovered automatically.

Rechecking Changes

Use the -fileattr check option to take a new file attribute snapshot and compare it with the previous snapshot.

The comparison identifies file attribute changes that occurred between the two snapshots. Oracle Orachk or Oracle Exachk also performs a normal health check collection.

To compare the current file attributes with the previous snapshot, run one of the following commands.

For Oracle Orachk:

orachk -fileattr check

For Oracle Exachk:

exachk -fileattr check

Note:

To obtain an accurate comparison, use the same file attribute options with -fileattr check that you used when creating the baseline snapshot with -fileattr start.

For example, if you created the baseline snapshot using:

orachk -fileattr start -includedir "/somedir" -excludediscovery

use the same options when checking for changes:

orachk -fileattr check -includedir "/somedir" -excludediscovery

The following example compares the current file attributes in /root/myapp/config with the previous snapshot:

$ orachk -fileattr check -includedir "/root/myapp/config" -excludediscovery

CRS stack is running and CRS_HOME is not set.
Do you want to set CRS_HOME to /u01/app/12.2.0/grid?[y/n][y]

Checking for prompts on myserver18 for oragrid user...
Checking ssh user equivalency settings on all nodes in cluster

Node myserver17 is configured for ssh user equivalency for root user

List of directories(recursive) for checking file attributes:

/root/myapp/config

Checking file attribute changes...

"/root/myapp/config/myappconfig.xml" is different:

Baseline : 0644 oracle root /root/myapp/config/myappconfig.xml
Current  : 0644 root   root /root/myapp/config/myappconfig.xml
...

In this example, the comparison shows that the ownership of myappconfig.xml changed between the baseline and current snapshots.

The results of the comparison are included in the File Attribute Changes section of the generated HTML report.

Designating a Snapshot as a Baseline

Use the -baseline option to designate a specific file attribute snapshot as the baseline for comparison.

This option is useful when you have multiple snapshots and want to compare the current file attributes against a specific baseline rather than the previous snapshot.

Specify the path to the baseline snapshot using the following syntax.

For Oracle Orachk:

orachk -fileattr check -baseline <path_to_snapshot>

For Oracle Exachk:

exachk -fileattr check -baseline <path_to_snapshot>

For example, to use /tmp/Snapshot as the baseline with Oracle Orachk:

orachk -fileattr check -baseline "/tmp/Snapshot"

Oracle Orachk compares the current file attributes with those recorded in the specified baseline snapshot and reports any detected changes.

Restricting System Checks

Use the -fileattronly option to run only file attribute change checks without performing a full system health check.

By default, the -fileattr check option compares file attributes and also performs a full health check run.

To restrict the run to file attribute checks only, use the following commands.

For Oracle Orachk:

orachk -fileattr check -fileattronly

For Oracle Exachk:

exachk -fileattr check -fileattronly

The resulting report contains the file attribute comparison results without running the additional system health checks.

Removing Snapshots

Use the -fileattr remove option to remove file attribute snapshots and related files that are no longer required.

Remove snapshots carefully to ensure that you do not delete a baseline or other snapshot that is still required for future comparisons.

For Oracle Orachk:

orachk -fileattr remove

For Oracle Exachk:

exachk -fileattr remove

The following example shows Oracle Orachk removing file attribute-related files:

$ orachk -fileattr remove

CRS stack is running and CRS_HOME is not set.
Do you want to set CRS_HOME to /u01/app/12.2.0/grid?[y/n][y] y

Checking for prompts on myserver18 for oragrid user...
Checking ssh user equivalency settings on all nodes in cluster

Node myserver17 is configured for ssh user equivalency for root user

List of directories(recursive) for checking file attributes:

/u01/app/12.2.0/grid
/u01/app/oradb/product/12.2.0/dbhome_1
/u01/app/oradb2/product/12.2.0/dbhome_1

Removing file attribute related files...

Comparing Two Reports

Oracle Autonomous Health Framework (AHF) can compare Oracle Orachk or Oracle Exachk compliance check reports and generate an HTML report that summarizes the differences.

When compliance checks run in automated daemon mode, AHF automatically compares the two most recent HTML reports and generates a comparison report.

To compare two reports manually, use the -diff option.

For Oracle Orachk:

orachk -diff <report_1> <report_2>

For Oracle Exachk:

exachk -diff <report_1> <report_2>

<report_1> and <report_2> can specify the path and name of any of the following:

HTML reports
Output directories
Output ZIP files

For example:

exachk -diff exachk_myhost07_scao1007_040716_090013.zip exachk_myhost07_scao1007_040716_100019.zip

Example output:

Summary

Total   : 278
Missing : 0
New     : 0
Changed : 3
Same    : 275

Check comparison is complete.

The comparison report can be viewed in:
/opt/oracle.SupportTools/exachk/exachk_040716090013_040716100019_diff.html

The command displays a summary of the comparison and the location of the generated diff HTML report.

The diff report provides a summary of both reports and organizes the comparison into sections that help you identify changed, unique, and common findings.

Table of Contents

The Table of Contents provides quick access to the major sections of the comparison report.

Use Show Check Ids to display the unique check IDs associated with the findings.

Differences Between Report 1 and Report 2

The Differences between Report 1 and Report 2 section lists checks whose results changed between the two reports.

Use this section to identify changes in compliance status between the two runs.

Unique Findings

The Unique Findings section lists findings that occur in only one of the two reports.

Use this section to identify:

Findings that appear only in Report 1.
Findings that appear only in Report 2.

Common Findings in Both Reports

The Common Findings in Both Reports section lists checks that have the same results in both reports.

Use this section to identify findings that remained unchanged between the two compliance check runs.

Configurations Comparison

The Configurations Comparison section compares system configuration information captured in the two collections.

Each subsection organizes configuration information into categories such as:

Configuration differences
Common configurations
Configurations unique to Report 1
Configurations unique to Report 2

Use the configuration comparison to identify changes in the environment that occurred between the two compliance check runs.

Merging Reports

Merge Oracle Orachk or Oracle Exachk reports to combine results from multiple compliance check runs into a single HTML report.

Merging reports is useful in role-separated environments where different users run different subsets of compliance checks. For example, a DBA and a system administrator can run checks appropriate to their respective roles and then merge the results into a consolidated report.

Use the -merge option followed by a comma-separated list of collection directories or ZIP files.

For Oracle Orachk:

orachk -merge <collection_1>,<collection_2>

For example:

orachk -merge orachk_myhost_mydb_041916_033322_dba,orachk_myhost_mydb_041916_035448_sysadmin

For Oracle Exachk:

exachk -merge <collection_1>,<collection_2>

For example:

exachk -merge exachk_myhost_mydb_041916_033322_dba,exachk_myhost_mydb_041916_035448_sysadmin

The generated merged HTML report:

Identifies the source collections from which the report was created.
Combines findings from the source collections.
Provides a consolidated view of the compliance check results.

Use the merged report to review findings from different role-specific or separately executed compliance check runs in a single report.

Note:

For Oracle Exachk, use the -force option when you need to force the merging of collections from dom0 and domU, or from global and local zones.

Maintaining Temporary Files and Directories

Oracle Orachk and Oracle Exachk create temporary files and directories while running compliance checks.

Each compliance check run also creates an output directory containing reports and other files that you can review. Typically, the combined size of the output directory and its corresponding .zip file is less than 5 MB. The actual size varies depending on the number of Oracle stack components evaluated during the run.

How you manage accumulated output depends on how compliance checks are run:

Automated daemon mode - Configure COLLECTION_RETENTION to automatically remove older collections.
On-demand or silent mode - Implement your own process for periodically removing output that is no longer required.

Note:

Uploading results to Oracle Health Check Collections Manager or tfa_web does not automatically reduce accumulated data files.

Reducing Accumulated Data Files

Oracle Orachk and Oracle Exachk provide the following methods for managing accumulated output:

Set the RAT_PURGE_SIZE environment variable when running without the daemon.
Configure the daemon option COLLECTION_RETENTION.
Manually remove files that are no longer required.

Using RAT_PURGE_SIZE Without the Daemon

Use the RAT_PURGE_SIZE environment variable to limit accumulated output when Oracle Orachk or Oracle Exachk is run without the daemon.

Specify the target size in MB:

export RAT_PURGE_SIZE=<size_in_MB>

For example:

export RAT_PURGE_SIZE=2048

When RAT_PURGE_SIZE is set, Oracle Orachk or Oracle Exachk evaluates files in the working directory after the current run completes.

Files are eligible for removal when both of the following conditions are met:

The total size of the working directory exceeds the configured RAT_PURGE_SIZE threshold.
Files in the working directory are more than 24 hours older than the current Oracle Orachk or Oracle Exachk run.

When these conditions are met, the tool removes eligible date-and-timestamp output directories and their corresponding .zip files.

For example, check the current working directory size:

du -hs .

Example output:

1.6G    .

The directory might contain multiple Oracle Exachk runs:

drwxr-x--- 9 root root 282624 Mar 26 09:46 exachk_randomclient02_PDB1_032619_090342
drwxr-x--- 9 root root 278528 Mar 26 10:33 exachk_randomclient02_PDB1_032619_095101
drwxr-x--- 9 root root 270336 Mar 26 11:16 exachk_randomclient02_PDB1_032619_103421
...
drwxr-x--- 9 root root 282624 Mar 26 15:03 exachk_randomclient02_PDB1_032619_141952
drwxr-x--- 9 root root 294912 Mar 26 15:48 exachk_randomclient02_PDB1_032619_150534
drwxr-x--- 9 root root 286720 Mar 27 08:00 exachk_randomclient02_PDB1_032719_071614

Set the target size to 1024 MB and run Oracle Exachk:

export RAT_PURGE_SIZE=1024
exachk

After the run completes, eligible older collections are removed.

For example:

$ du -hs .
1.5G    .

The remaining directories might include:

drwxr-x--- 9 root root 270336 Mar 26 11:16 exachk_randomclient02_PDB1_032619_103421
drwxr-x--- 9 root root 290816 Mar 26 11:59 exachk_randomclient02_PDB1_032619_111713
...
drwxr-x--- 9 root root 294912 Mar 26 15:48 exachk_randomclient02_PDB1_032619_150534
drwxr-x--- 9 root root 286720 Mar 27 08:00 exachk_randomclient02_PDB1_032719_071614
drwxr-x--- 9 root root 282624 Mar 27 10:36 exachk_randomclient02_PDB1_032719_094859

In this example, the following two older runs were removed:

exachk_randomclient02_PDB1_032619_090342
exachk_randomclient02_PDB1_032619_095101

Note:

RAT_PURGE_SIZE is a target rather than a guarantee that the working directory will be reduced to the exact configured size. Only files old enough to be eligible for removal can be purged. If insufficient files are more than 24 hours old, the directory can remain larger than the configured target.

Using the COLLECTION_RETENTION Daemon Option

Use the COLLECTION_RETENTION daemon option to automatically remove collections based on their age.

Specify COLLECTION_RETENTION in days.

Unlike RAT_PURGE_SIZE, which considers both directory size and file age, COLLECTION_RETENTION removes eligible files based on their dates. At the end of a daemon-initiated Oracle Orachk or Oracle Exachk run, files older than the configured retention period are removed.

For example, configure an Oracle Exachk profile named fname to run the switch profile every hour and retain collections for one day:

exachk -id fname -set "AUTORUN_SCHEDULE=* * * *;NOTIFICATION_EMAIL=fname.lname@somewhere.com;COLLECTION_RETENTION=1;AUTORUN_FLAGS=-profile switch"

To verify the configuration:

exachk -id fname -get all

Example output:

------------------------------------------------------------
ID: exachk.testuser
------------------------------------------------------------
AUTORUN_FLAGS = -profile switch
NOTIFICATION_EMAIL = fname.lname@somewhere.com
COLLECTION_RETENTION = 1
AUTORUN_SCHEDULE = * * * *
------------------------------------------------------------

After the daemon has run for more than one day, the retained output stabilizes at approximately one day's worth of hourly collections.

For example:

drwxr-x--- 8 root root 20480 Mar 27 15:03 exachk_randomclient02_032719_150039
...
drwxr-x--- 8 root root 20480 Mar 28 04:03 exachk_randomclient02_032819_040026
drwxr-x--- 8 root root 20480 Mar 28 15:03 exachk_randomclient02_032819_150022
drwxr-x--- 8 root root 20480 Mar 28 16:03 exachk_randomclient02_032819_160022

Note:

The exact files removed can vary slightly because eligibility depends on the timestamps of the existing files and the time of the current daemon-initiated run.

Manually Reducing Accumulated Data Files

If automatic retention is not configured, periodically review and remove Oracle Orachk or Oracle Exachk files that are no longer required.

Consider removing the following files:

Remove the original exachk.zip installation file after extracting it if you no longer require it. The file can consume approximately 250 MB.

Remove debug logs after they have been uploaded to an Oracle Support Service Request (SR) or bug and are no longer required locally.

For example:

du -hc *debug*

Example output:

18M     exachk_debug_120418_195653.log
19M     exachk_debug_120418_201543.log
24M     exachk_debug_120418_202357.log
24M     exachk_debug_120418_205003.log
22M     exachk_debug_120418_211816.log
105M    total

Remove date-and-timestamp output directories and their corresponding .zip files after they are no longer required.

For example:

drwxr-x--- 9 root root 4.0K Dec  4 20:39 exachk_randomadm01_120418_202357
-r--r----- 1 root root 7.0M Dec  4 20:39 exachk_randomadm01_120418_202357.zip

drwxr-x--- 9 root root 4.0K Dec  4 20:04 exachk_randomclient01_120418_195653
-r--r----- 1 root root 6.4M Dec  4 20:04 exachk_randomclient01_120418_195653.zip

drwxr-x--- 9 root root 4.0K Dec  4 20:23 exachk_randomclient01_120418_201543
-r--r----- 1 root root 6.4M Dec  4 20:23 exachk_randomclient01_120418_201543.zip

drwxr-x--- 8 root root 4.0K Nov 29 20:29 exachk_randomclient01_PDB1_112918_202702
-r--r----- 1 root root 47K  Nov 29 20:28 exachk_randomclient01_PDB1_112918_202702.zip

drwxr-x--- 9 root root 4.0K Dec  4 22:48 exachk_randomclient01_sing11g_120418_224719
-r--r----- 1 root root 113K Dec  4 22:48 exachk_randomclient01_sing11g_120418_224719.zip

Remove *_error.log files after they have been uploaded to an SR or bug and are no longer required.

For example:
```
-rw-r--r-- 1 root root 4.4K Nov 27 22:51 exachk112718_223504_error.log
```
Remove manually created backup directories after they are no longer required.

For example:
```
/opt/oracle.SupportTools/exachk/back_up_exachk_111618_184655/build
```

Free-Space Threshold

Oracle Orachk and Oracle Exachk use a default free-space threshold for their working area.

The default remaining free-space requirement is 5%, reduced from the previous threshold of 15%.

A compliance check run can continue when the minimum absolute free-space requirement is satisfied, even when the percentage of free space available on the file system is below the configured percentage threshold.

Consuming Multiple Results in Other Tools

Optionally integrate compliance check results into various other tools.

For more information, see Integrating Compliance Check Results with Other Tools.

Generate Reports Only in the Formats You Need

Starting with Oracle Autonomous Health Framework (AHF) 25.11, Oracle Exachk enables you to specify the report formats to generate. You can select JSON, HTML, XML, or a combination of these formats.

By default, Oracle Exachk generates a comprehensive collection that can include:

JSON, XML, and HTML reports
Logs
.out files
Scripts
Additional diagnostic data

Depending on the environment, the resulting ZIP archive can grow to several gigabytes, while the reports themselves might account for only a small portion of the total collection.

If you require only specific report formats, use the -output_format option to reduce the collection size and avoid generating unnecessary output.

Specify one or more formats as a comma-separated list:

exachk -output_format <type1>,<type2>,...

For example, to generate only JSON and HTML reports:

exachk -output_format json,html

This command generates an Oracle Exachk collection containing the requested JSON and HTML report output.

Using -output_format provides the following benefits:

Smaller collections - Includes only files relevant to the requested report formats.
Faster execution - Avoids generating report formats that are not required.
Reduced storage usage - Minimizes unnecessary files in the resulting ZIP archive.

Oracle Exachk ZIP Contents

The contents of the generated Oracle Exachk ZIP file depend on the report formats specified with -output_format.

When json is specified, the collection has a structure similar to:

exachk_<collection_name>/
|-- exachk.log
|-- upload/
    |-- *.json

When html is specified, the collection has a structure similar to:

exachk_<collection_name>/
|-- exachk_<collection_name>.html
|-- exachk.log
|-- reports/
    |-- *.html

When xml is specified, the collection has a structure similar to:

exachk_<collection_name>/
|-- exachk.log
|-- upload/
    |-- *.xml

When you specify multiple formats, Oracle Exachk includes the applicable report files and directories for each requested format in the resulting collection.

Exadata Live Update Status Integration in exachk Reports

Starting with Oracle Autonomous Health Framework (AHF) 26.2, Oracle Exachk reports include Exadata Live Update status information in the Infrastructure and Configuration Summary for the Oracle Database Server component.

The status is available in both HTML and JSON reports.

Note:

This feature applies only to Exadata systems running in KVM Host or Guest VM environments.

Oracle Exachk determines the Exadata Live Update status by running the imagehistory command on each compute node and analyzing the output to determine the current patching state.

Exadata Live Update Status Values

The Exadata Live Update Status field can display one of the following values:

Not Applicable (No Software Updates Applied)

Indicates that the system has never been patched and remains in its original fresh image state.

The imagehistory output shows:
```
Exadata Live Update Version: n/a
Imaging mode: fresh
```
Not Applicable (Traditional Updates Applied)

Indicates that the most recent software update was applied using the traditional patching method rather than Exadata Live Update.

The latest imagehistory entry shows:
```
Exadata Live Update Version: n/a
```
Exadata Live Update Pending Reboot to Finalize Outstanding Work

Indicates that an Exadata Live Update was successfully applied, but the system has not yet been rebooted to complete the finalization process.

The latest imagehistory entry contains:
```
Live Update applied. Reboot at any time to finalize outstanding items.
```
Exadata Live Update Applied Successfully and Finalized at Reboot Time
Indicates that an Exadata Live Update was successfully applied and subsequently finalized by rebooting the system.

The <timestamp> value indicates when the Live Update was finalized.

Oracle Exachk derives this value from the subsequent imagehistory entry that no longer contains the pending reboot message.

Infrastructure and Configuration Summary

Oracle Exachk adds an Exadata Live Update Status row to the Oracle Database Server component table in the Infrastructure and Configuration Summary.

The report:

Groups compute nodes that have the same Exadata Live Update status.
Displays the corresponding status for each group.
Helps identify nodes that require additional action, such as a reboot to finalize an Exadata Live Update.

System Overview Section Added to ISC Report

Starting with Oracle Autonomous Health Framework (AHF) 26.3, the Oracle Exachk report includes a System Overview section within the Infrastructure Software and Configuration (ISC) summary.

The System Overview automatically identifies key characteristics of the Exadata environment and makes them available in both HTML and JSON output.

Previously, the ISC section did not provide consolidated information about important Exadata topology characteristics such as the deployment model, virtualization type, storage engine, and interconnect fabric. Determining this information during health checks or incident investigation could therefore require additional manual verification.

The System Overview consolidates this information to provide DBAs and support engineers with an immediate view of the Exadata environment.

System Overview Attributes

The System Overview includes the following attributes:

Attribute	Possible Values	Description
Deployment Type	On-Premises, Cloud (ExaDB-D, ExaDB-C@C, ExaDB-XS, and others)	Identifies whether the Exadata system is deployed in a customer data center or through an Oracle Cloud service.
Infrastructure Type	Bare Metal, OVM (Host or Guest), KVM (Host or Guest)	Identifies the virtualization technology used on each compute node or indicates that the node runs on bare metal.
Storage Engine	ASM, Exascale, ASM on EDV	Identifies the storage engine used to provide storage for database instances.
Interconnect	InfiniBand, RoCE	Identifies the cluster interconnect fabric used for Oracle RAC communication and storage traffic.

The System Overview appears as the first section in the Infrastructure Software and Configuration Summary table.

By presenting these system characteristics together, the System Overview:

Reduces manual environment discovery during troubleshooting.
Provides consistent, structured system information.
Helps reduce the risk of operational decisions based on incorrect environment assumptions.
Provides data that can be consumed by automation and integrations.
Enables faster initial assessment of an Exadata environment.

JSON Output

Oracle Exachk also generates the System Overview information as structured JSON.

The following file is created in the collection upload directory:

systemOverview.json

The file contains the discovered System Overview attributes and associated metadata.

Example:

{
  "snapshotTimestamp": "2026-02-10 08:17:45.160942",
  "systemOverview": [
    {
      "deployment": "On-Premises",
      "infrastructure_type": "KVM (Host)",
      "storage": "Exascale",
      "switch_type": "RoCE"
    }
  ],
  "metadata": {
    "deployment": {
      "label": "Deployment Type",
      "preformattedText": false
    },
    "infrastructure_type": {
      "label": "Infrastructure Type",
      "preformattedText": false
    },
    "storage": {
      "label": "Storage Engine",
      "preformattedText": false
    },
    "switch_type": {
      "label": "Interconnect",
      "preformattedText": false
    }
  }
}