Getting Started with Running Compliance Checks

Running Oracle Orachk or Oracle Exachk as a Non-Root User

You can run Oracle Orachk or Oracle Exachk as a non-root user.

When AHF is installed as root, non-root users can specify their own output location for Oracle Orachk or Oracle Exachk results. However, because of directory permissions, a non-root user might not be able to list the contents of directories in the path leading to their output directory.

For example:

$ cd /u01/app/crsusr/oracle.ahf/data/<host_name>/

$ ls -ltra
ls: cannot open directory .: Permission denied

$ cd orachk

The user might also be unable to list the contents of the orachk directory:

$ ls
ls: cannot open directory .: Permission denied

However, if the user knows the complete path to their output directory and has the required permissions on that directory, they can change directly to it.

For example:

$ cd user_racusr

$ ls -l
total 7456
-r-xr-xr-x 1 root   root     6836 Jun 1 13:37 cgrep
-rw-r--r-- 1 root   root     5481 Jun 1 13:37 cgrep.pyc
drwxr-xr-x 7 racusr oinstall 274432 Jun 1 14:05 orachk_<host_name>_ratcdb_060120_133414
-rw-r----- 1 racusr oinstall 7323951 Jun 1 14:05 orachk_<host_name>_ratcdb_060120_133414.zip
drwx-----T 2 racusr root     4096 Jun 1 14:05 output
drwx-----T 4 racusr root     4096 Jun 1 14:05 work

Non-root users can access their Oracle Orachk results by using the complete output path provided after the Oracle Orachk run.

Alternatively, use the following command to identify the repository location where the results are stored:

ahfctl showrepo

Example output:

<<output truncated>>

orachk repository:
/u01/app/crsusr/oracle.ahf/data/<host_name>/orachk/user_racusr/output

Use the displayed repository path to access the Oracle Orachk results directly.

Non-Root Users Running Root Privileged Checks on Database Servers

Non-root users can run root-privileged Oracle Orachk checks on database servers without requiring the root password or sudo access.

The Oracle Trace File Analyzer (TFA) daemon must be running on all database servers in the cluster.

As the root user, grant the non-root user permission to run root-privileged compliance checks:
```
tfactl access grant -user <user_name> -role privileged-compliance-checks
```

Verify that the non-root user has been granted the required access:

tfactl access lsusers

Example output:

.-------------------------------------------.
|            TFA Users in Node1             |
+-----------+---------+----------+----------+
| User Name | Status  | Promoted | Roles    |
+-----------+---------+----------+----------+
| dbusr     | Allowed | false    | n/a      |
| giusr     | Allowed | true     | n/a      |
| orarom    | Allowed | n/a      | platinum |
'-----------+---------+----------+----------'

After the non-root user is assigned the privileged-compliance-checks role, run Oracle Orachk with the -runasroot option to include checks that require root privileges:
```
orachk -runasroot
```

The non-root user can now run root-privileged compliance checks without providing the root password or using sudo.

Automatic Compliance Checking

Use the Oracle Trace File Analyzer (TFA) scheduler daemon to run Oracle Orachk or Oracle Exachk compliance checks automatically at scheduled intervals.

When Oracle Autonomous Health Framework (AHF) is installed as root on Linux or Solaris, Oracle Orachk or Oracle Exachk is automatically configured to use the TFA scheduler daemon.

By default, the scheduler:

Runs a full local Oracle Orachk compliance check once a week at 3 AM.
Runs a partial compliance check containing the most impactful checks every day at 2 AM using the oratier1 or exatier1 profile.
Automatically purges daily oratier1 or exatier1 profile results after one week.
Automatically purges full local compliance check results after two weeks.

You can modify the default scheduling and notification settings after enabling automatic compliance checking.

Note:

Daemon mode is supported only on Linux and Solaris.
For Oracle Engineered Systems, follow any additional system-specific configuration requirements.
You must run the -autostart and -autostop commands as the root user. Non-root users cannot manage the TFA Scheduler.

Configure the scheduler properties.

At a minimum, configure:
- AUTORUN_SCHEDULE
- NOTIFICATION_EMAIL
For example, to run Oracle Exachk at 3 AM every Sunday and send the results to some.body@example.com:
```
exachk -set "AUTORUN_SCHEDULE=3 * * 0;NOTIFICATION_EMAIL=some.body@example.com"
```
To configure the same schedule for Oracle Orachk:
```
orachk -set "AUTORUN_SCHEDULE=3 * * 0;NOTIFICATION_EMAIL=some.body@example.com"
```
You can optionally specify a profile name by using the -id option. If you do not specify an ID, the configuration uses id=DEFAULT.

For example, to configure a profile named dba for Oracle Exachk:
```
exachk -id dba -set "AUTORUN_SCHEDULE=3 * * 0;NOTIFICATION_EMAIL=some.body@example.com"
```
To configure a profile named dba for Oracle Orachk:
```
orachk -id dba -set "AUTORUN_SCHEDULE=3 * * 0;NOTIFICATION_EMAIL=some.body@example.com"
```
Configure the compliance check daemon for automatic compliance checking.
As the root user, start automatic compliance checking.

For Oracle Orachk:
```
orachk -autostart
```
For Oracle Exachk:
```
exachk -autostart
```
To start automatic compliance checking and load the default schedulers, use the reset option.

For Oracle Orachk:
```
orachk -autostart reset
```
For Oracle Exachk:
```
exachk -autostart reset
```
To stop automatic compliance checking, run the appropriate command as the root user.

For Oracle Orachk:
```
orachk -autostop
```
For Oracle Exachk:
```
exachk -autostop
```
To remove all default schedulers that have not been modified, use the unset option.

For Oracle Orachk:
```
orachk -autostop unset
```
For Oracle Exachk:
```
exachk -autostop unset
```

If a non-root user attempts to run -autostart or -autostop, the command exits with a message similar to the following:

Commands -autostart and -autostop can not be run as non root user.
Switch to root user and try again.

Running Oracle Orachk or Oracle Exachk Scheduler with the Oracle Trace File Analyzer Daemon

The Oracle Trace File Analyzer (TFA) daemon runs and manages the Oracle Orachk or Oracle Exachk scheduler.

The TFA scheduler:

Determines the master node in the cluster.
Selects Oracle Orachk or Oracle Exachk scheduler entries on the master node.
Runs scheduled checks from the master node.
Runs Oracle Orachk or Oracle Exachk checks across the cluster.
Consolidates the results on the master node.
Records the master node in the logs.
Sends an email notification identifying the master node where the report output is stored.

To view the current scheduler and daemon configuration, use the -autostatus option.

For Oracle Orachk:

orachk -autostatus

For Oracle Exachk:

exachk -autostatus

The following example shows the default Oracle Orachk scheduler and daemon configuration:

# orachk -autostatus

Master node = testserver
orachk daemon version = 221000
Install location = /opt/oracle.ahf/orachk
Started at = Wed Jun 22 20:56:51 UTC 2022
Scheduler type = TFA Scheduler
Scheduler PID: 1766980

------------------------------------------------------------
ID: orachk.autostart_client_oratier1
------------------------------------------------------------
AUTORUN_FLAGS = -usediscovery -profile oratier1 -dball -showpass -tag autostart_client_oratier1 -readenvconfig
COLLECTION_RETENTION = 7
AUTORUN_SCHEDULE = 3 2 * * 1,2,3,4,5,6
------------------------------------------------------------

------------------------------------------------------------
ID: orachk.autostart_client
------------------------------------------------------------
AUTORUN_FLAGS = -usediscovery -tag autostart_client -readenvconfig
COLLECTION_RETENTION = 14
AUTORUN_SCHEDULE = 3 3 * * 0
------------------------------------------------------------

Next auto run starts on Jun 23, 2022 02:03:00
ID: orachk.AUTOSTART_CLIENT_ORATIER1

The -autostatus output provides information about:

The current master node.
The Oracle Orachk or Oracle Exachk daemon version.
The installation location.
The time when the scheduler started.
The scheduler type and process ID (PID).
Configured scheduler IDs.
Options used for scheduled runs.
Collection retention periods.
Automatic run schedules.
The next scheduled run.

Email Notification and Report Overview

The following sections provide a brief overview about email notifications and sections of the HTML report output.

First Email Notification

After completing compliance check runs, the daemon emails the assessment report as an HTML attachment to all users that you have specified in the NOTIFICATION_EMAIL list.

What does the Compliance Check Report Contain?

Compliance check reports contain the health status of each system grouped under different sections of the report.

The HTML report output contains the following:

Health score
Summary of compliance check runs
Table of contents
Controls for report features
Findings
Recommendations

Details of the report output are different on each system. The report is dynamic, and therefore the tools display certain sections only if applicable.

System Health Score and Summary

System Health Score and Summary report provide:

A high-level health score based on the number of passed or failed checks
A summary of compliance check run includes:
Name, for example, Cluster Name
Version of the operating system kernel
Path, version, name of homes, for example, CRS, DB, and EM Agent
Version of the component checked, for example, Exadata
Number of nodes checked, for example, database server, storage servers, InfiniBand switches
Version of Oracle Orachk and Oracle Exachk
Name of the collection output
Date and time of collection
- Duration of the check
- Name of the user who ran the check, for example, root
- How long the check is valid

Table of Contents and Report Feature

The Table of Contents section provides links to major sections in the report:

Database Server
Storage Server
InfiniBand Switch
Cluster Wide
Maximum Availability Architecture (MAA) Scorecard
Infrastructure Software and Configuration Summary
Findings needing further review
Platinum Certification
System-wide Automatic Service Request (ASR) compliance check
Skipped Checks
Top 10 Time Consuming Checks

The Report Feature section enables you to:

Filter checks based on their statuses
Select the regions
Expand or collapse all checks
View check IDs
Remove findings from the report
Get a printable view

Report Findings

The Report Findings section displays the result of each compliance check grouped by technology components, such as Database Server, Storage Server, InfiniBand Switch, and Cluster Wide.

Each section shows:

Check status ( FAIL , WARNING , INFO , or PASS )
Type of check
Check message
Where the check was run
Link to expand details for further findings and recommendation

Click View for more information about the compliance check results and the recommendations.

What to do to solve the problem
Where the recommendation applies
Where the problem does not apply
Links to relevant documentation or My Oracle Support notes
Example of data on which the recommendation is based

Maximum Availability Architecture (MAA) Score Card

Maximum Availability Architecture (MAA) Score Card displays the recommendations for the software installed on your system.

The details include:

Outage Type
Status of the check
Description of the problem
Components found
Host location
Version of the components compared to the recommended version
Status based on comparing the version found to the recommended version

Subsequent Email Notifications

For the subsequent compliance check runs after the first email notification, the daemon emails the summary of differences between the most recent runs.

Specify a list of comma-delimited email addresses in the NOTIFICATION_EMAIL option.

The email notification contains:

System Health Score of this run compared to the previous run
Summary of number of checks that were run and the differences between runs
Most recent report result as attachment
Previous report result as attachment
Diff report as attachment

Generating a Diff Report

The diff report attached to the previous email notification shows a summary of differences between the most recent runs.

To identify the changes since the last run:

Run the following command:
```
$ orachk -diff report_1report_2
```
Review the diff report to see a baseline comparison of the two reports and then a list of differences.

Recommended On-Demand Usage

In addition to scheduled compliance checks, run Oracle Orachk or Oracle Exachk on demand when you need to assess the health and compliance of your environment.

To run an on-demand compliance check with Oracle Orachk:

orachk

To run an on-demand compliance check with Oracle Exachk:

exachk

Oracle recommends running compliance checks on demand in the following scenarios:

Before or after an upgrade.
When relocating a machine from one subnet to another.
After a hardware failure or repair.
When troubleshooting a problem.
As part of go-live testing.

For upgrades, run compliance checks both before and after the upgrade to identify potential issues and verify the environment after the upgrade completes.

When you run pre-upgrade or post-upgrade checks, Oracle Autonomous Health Framework (AHF) automatically detects databases registered with Oracle Clusterware and presents the databases that are available for checking.

Run the pre-upgrade checks during the upgrade planning phase. AHF prompts you to specify the database version to which you plan to upgrade.

For Oracle Orachk:

orachk -u -o pre

For Oracle Exachk:

exachk -u -o pre

After completing the upgrade, run the post-upgrade checks.

For Oracle Orachk:

orachk -u -o post

For Oracle Exachk:

exachk -u -o post

Running Compliance Checks on a Remote Node

Run compliance checks on remote nodes using RSA/DSA SSH private and public keys.

Generate RSA/DSA SSH private and public keys on each of the remote nodes as root user.
Add the content of the above generated public key to the authorized_keys file for each of the remote nodes.

For example:
```
cat $HOME/.ssh/id_dsa.pub >> $HOME/.ssh/authorized_keys
```
Copy the private keys of all the remote nodes where you want to run the checks, for example, in the PRIVATEKEYDIR directory.
Rename each of the private keys as id_ encryption . remote_hostname . remote_user.

Where:
- remote_user is the Linux user who created the key
- encryption can be RSA/DSA
- remote_host is the hostname (not FQDN) of the remote node
For example:
```
id_dsa.node1.root
```
```
id_rsa.node2.oradb
```

Ensure that passwordless SSH between the local node and remote node is present. `ssh -i id_*encryption*.*remote_host*.*remote_user* *remote_user*@*remote_host* must be able to log in to the remote_host` without any password.

Synchronous Remote Run

This is a blocking-call. Outputs the stdout of the remote run. User gets the prompt or control only when the remote run is completed. Once completed, the collection will be available at the working directory.

# orachk -remotehost remote_host remote_args -remoteuser remote_user -remotedestdir remote_dest_dir -identitydir PRIVATEKEYDIR

# exachk -remotehost remote_host remote_args -remoteuser remote_user -remotedestdir remote_dest_dir -identitydir PRIVATEKEYDIR

For example:

orachk -remotehost node2 -profile asm -remoteuser root -remotedestdir /scratch/user/ -identitydir /scratch/user/privatekeys/

exachk -remotehost node1 -localonly -c X4-2,MAA -remoteuser oracle -remotedestdir /scratch/user/ -identitydir /scratch/user/privatekeys/

$ orachk -remotehost node2 -profile asm -remoteuser root -remotedestdir /scratch/user1/ -identitydir .privatekeys/

Starting orachk run on node2. For more detail about run check /scratch/user1/orachkremote/orachk_node2_112818_040034_run.log

Clusterware stack is running from /scratch/app/11.2.0.4/grid. Is this the correct Clusterware Home?[y/n][y]

Checking ssh user equivalency settings on all nodes in cluster for root

Asynchronous Remote Run

This is a non-blocking-call. Oracle Orachk and Oracle Exachk initiate the remote run, display a _run.log file, and give control to the user. Check the _run.log file to ensure the completion of the remote run. Once completed, the collection will be available at the working directory

# orachk -remotehost remote_host remote_args -remoteuser remote_user -remotedestdir remote_dest_dir  -identitydir PRIVATEKEYDIR -asynch

# exachk -remotehost remote_host remote_args -remoteuser remote_user -remotedestdir remote_dest_dir -identitydir PRIVATEKEYDIR -asynch

Where:

remote_host is the host name of the remote node.
remote_args are the arguments that needs to be passed to the Oracle Orachk and Oracle Exachk run in the remote node.
remote_user is the remote user who runs Oracle Orachk and Oracle Exachk .
remote_dest_dir is the remote directory where orachk.zip or exachk.zip is extracted.
PRIVATEKEYDIR is the directory contains the private keys of the remote nodes in the specified format.

Note:

If you use DSA keys, then set the RAT_SSH_ENCR environment variable to dsa before running the Oracle Orachk and Oracle Exachk remote run commands.

For example:

orachk -remotehost node2 -remoteuser oradb -remotedestdir /scratch/user/ -identitydir /scratch/user/privatekeys/ -asynch

exachk -remotehost node1 -cells node1 -c X4-2,MAA -remoteuser root -remotedestdir /scratch/user/ -identitydir /scratch/user/privatekeys/ -asynch

$ orachk -remotehost node2 -localonly -remoteuser root -identitydir .privatekeys/ -asynch

Starting orachk run on node2. For more detail about run check /scratch/user1/orachkremote/orachk_node2_112818_041037_run.log

Private key files

$ ls PRIVATEKEYDIR/
id_dsa.node1.oracle    id_dsa.node4.root    id_dsa.node6.oracle    id_dsa.node8.root    id_dsa.node11.oracle
id_dsa.node2.root      id_dsa.node5.oracle  id_dsa.node6.root      id_dsa.node9.root
id_dsa.node3.root      id_dsa.node5.root    id_dsa.node7.root      id_dsa.node10.oracle

Creating, Modifying, and Deleting User-Defined Profiles

Specify a comma-delimited list of check IDs to create and modify custom profiles.

Specify valid check IDs and descriptive unique profile name.

To create a profile:
```
orachk -createprofile profile_namecheck_ids
```
```
exachk -createprofile profile_namecheck_ids
```
```
orachk -createprofile customprofile1 E94AC6ACDA502F3BE04312C0E50A290A,
F01E3FEDBD2B243EE04312C0E50A4DC5, 
F02293F7261D1BCAE04312C0E50A4118,
F9370B4F5707076DE04312C0E50A78AE

Validating checks...
```
Oracle Orachk and Oracle Exachk validate profile names and check IDs before creating the profile and print appropriate messages if any discrepancies found. Oracle Orachk and Oracle Exachk create the profiles only if the profile names are unique and check IDs are valid.

To modify a profile:

orachk -modifyprofile profile_namecheck_ids

exachk -modifyprofile profile_namecheck_ids

exachk -modifyprofile customprofile1 21B57D4065DDEA3DE0530D98EB0A8205,
39128FBB540C098AE0530D98EB0AFB1A,
9AD8AF3966FB3027E040E50A1EC0308F,
019F5085951978CAE05313C0E50A4FCB
Validating checks...
Modifying profile customprofile1...
Profile customprofile1 modified successfully...
Added Checks:
21B57D4065DDEA3DE0530D98EB0A8205
9AD8AF3966FB3027E040E50A1EC0308F
019F5085951978CAE05313C0E50A4FCB

You cannot modify the profile name. You can only add to or remove check IDs form the profile.

If the check IDs are in the profile, then Oracle Orachk and Oracle Exachk remove them from the profile.

If the check IDs are not in the profile, then Oracle Orachk and Oracle Exachk add them to the profile.

To delete a profile:
```
orachk -deleteprofile profile_name
```
```
exachk -deleteprofile profile_name
```
```
orachk -deleteprofile customprofile1
Deleting profile customprofile1...
```
Oracle Orachk and Oracle Exachk delete the profile by removing the profile entry ID from the profiles.dat file, and deleting the corresponding profiles.prf file.

Sanitizing Sensitive Information in the Diagnostic Collections

Oracle Autonomous Health Framework uses Adaptive Classification and Redaction (ACR) to sanitize sensitive data.

Note:

The -sanitize parameter has been deprecated and removed in 23.3. Oracle recommends using the ahfctl redact command instead.

After collecting copies of diagnostic data, Oracle Orachk and Oracle Exachk use Adaptive Classification and Redaction (ACR) to sanitize sensitive data in the collections. ACR uses a machine learning based engine to redact a pre-defined set of entity types in a given set of files. ACR also sanitizes or masks entities that occur in path names.

Sanitization replaces a sensitive value with random characters.
Masking replaces a sensitive value with a series of asterisks ("*").

ACR currently sanitizes the following entity types:

Host names
IP addresses
MAC addresses
Oracle Database names
Tablespace names
Service names
Ports
Operating system user names

ACR also masks Personally Identifiable Information (PII), that is, user data from the database appearing in block and redo dumps. There is no separate command for it.

To sanitize sensitive information:

orachk -sanitize comma_delimited_list_of_collection_IDs

exachk -sanitize comma_delimited_list_of_collection_IDs

Block dumps before redaction:

14A533F40 00000000 00000000 00000000 002C0000 [..............,.]
14A533F50 35360C02 30352E30 31322E37 380C3938 [..650.507.2189.8]
14A533F60 31203433 37203332 2C303133 360C0200 [34 123 7310,...6]

Block dumps after redaction:

14A533F40 ******** ******** ******** ******** [****************]
14A533F50 ******** ******** ******** ******** [****************]
14A533F60 ******** ******** ******** ******** [****************]

Redo dumps before redaction:

col 74: [ 1] 80
col 75: [ 5] c4 0b 19 01 1f
col 76: [ 7] 78 77 06 16 0c 2f 26

Redo dumps after redaction:

col 74: [ 1] **
col 75: [ 5] ** ** ** ** **
col 76: [ 7] ** ** ** ** ** ** **

To print the reverse map of sanitized elements:

orachk -rmap all|comma_delimited_list_of_element_IDs

exachk -rmap all|comma_delimited_list_of_element_IDs

Sanitizing Sensitive Information in Oracle Orachk or Oracle Exachk Output

Note:

The -sanitize parameter has been deprecated and removed in 23.3. Oracle recommends using the ahfctl redact command instead.

If you specify a file name that does not follow the naming convention:

For example:

$ orachk -sanitize orachk_invalid.html
/scratch/testuser/may31/orachk_invalid.html is not a valid orachk collection

If you specify a file that does not exist:

For example:

$ orachk -sanitize /tmp/orachk_invalid.html
/tmp/orachk_invalid.html does not exist

If you sanitize a file that exists with valid Oracle Autonomous Health Framework naming convention, but the file is not generated by Oracle Autonomous Health Framework:

For example:

$ orachk -sanitize orachk_invalidcollection.zip
orachk is sanitizing /scratch/testuser/may31/orachk_invalidcollection.zip. Please
wait...
ACR error occurred while sanitizing orachk collection

To sanitize a file with relative path:

For example:

$ orachk -sanitize new/orachk_node061919_053119_001343.zip 
orachk is sanitizing
/scratch/testuser/may31/new/orachk_node061919_053119_001343.zip. Please wait...

$ orachk -sanitize .orachk_node061919_053119_001343.zip 
orachk is sanitizing
/scratch/testuser/may31/.orachk_node061919_053119_001343.zip. Please wait...

To sanitize Oracle Autonomous Health Framework debug log:

For example:

$ orachk -sanitize new/orachk_debug_053119_023653.log
orachk is sanitizing /scratch/testuser/may31/new/orachk_debug_053119_023653.log.
Please wait...

To run full sanity check:

For example:

$ orachk -localonly -profile asm -sanitize -silentforce
Detailed report (html) - 
/scratch/testuser/may31/orachk_node061919_053119_04448/orachk_node061919_053119_04448.html
orachk is sanitizing /scratch/testuser/may31/orachk_node061919_053119_04448.
Please wait...
Sanitized collection is: /scratch/testuser/may31/orachk_aydv061919_053119_04448

To print the reverse map of sanitized elements:

For example:

orachk -rmap pu406jKxg,kEvGFDT

| Entity Type | Substituted Entity Name | Original Entity Name |

orachk -rmap all

Setting up Staging Server for Adaptive Classification and Redaction (ACR)

Adaptive Classification and Redaction (ACR) is a CPU intensive task as it examines data in each file to redact sensitive entities. ACR spawns multiple processes to redact the files across these processes. Whenever an ACR process is scheduled on a CPU, it may utilise the CPU fully (can reach ~100% CPU utilisation). But, since ACR does not run at an elevated priority, it does not starve other processes on the system. However, since ACR is sharing the resources with other processes running on the production environment, it can affect those processes. Hence, to not affect the processes and applications on the production environment, it is recommended to set up a staging server dedicated for redacting the collections using ACR.

For more information about setting up staging server for Adaptive Classification and Redaction (ACR), see My Oracle Support note 2882798.1.

Problem Repair Automation Options

Starting with Oracle Autonomous Health Framework (AHF) 19.3, Oracle Orachk and Oracle Exachk can automatically repair certain problems detected by compliance checks.

Some compliance checks have an associated repair command. Before applying a repair, review the repair action to understand the changes that it will make.

To display the repair command associated with a specific check, use the -showrepair option.

For Oracle Orachk:

orachk -showrepair <check_id>

For Oracle Exachk:

exachk -showrepair <check_id>

To apply available repairs, use the -repair option.

To repair all checks that have an available repair action:

orachk -repair all

or:

exachk -repair all

To repair a specific check or a comma-separated list of checks:

orachk -repair <check_id>[,<check_id>,...]

or:

exachk -repair <check_id>[,<check_id>,...]

To repair the checks listed in a file:

orachk -repair <file>

or:

exachk -repair <file>

Where:

<check_id> specifies the ID of a compliance check that you want to repair. Specify a single check ID or a comma-separated list of check IDs.
<file> specifies a text file containing the check IDs to repair. Specify one check ID per line.

For example:

check_ID1
check_ID2
check_IDn

Before applying automated repairs, use -showrepair to review the repair action associated with each check.

Integration of Oracle DBSAT into Oracle Autonomous Health Framework

DBSAT is a lightweight utility that will not impair system performance in a measurable way.

The Oracle Database Security Assessment Tool (Oracle DBSAT):

Analyzes database configurations
Users and their entitlements
Security policies
Identifies where sensitive data resides to uncover security risks (not executed in Oracle Autonomous Health Framework)
Improves the security posture of Oracle Databases within your organization

Oracle Autonomous Health Framework always includes the latest DBSAT and runs DBSAT on all databases if you use the -security profile. For example, orachk -profile security.

To generate an AHF best practice report including security recommendations, you can also run:

ahfctl compliance -profile security

You can use Oracle DBSAT report findings to:

Fix immediate short-term risks
Implement a comprehensive security strategy
Support your regulatory compliance program
Promote security best practices

Integration of AutoUpgrade utility into Oracle Autonomous Health Framework

The AutoUpgrade utility identifies issues before upgrades, performs pre- and postupgrade actions, deploys upgrades, performs postupgrade actions, and starts the upgraded Oracle Database.

Before the upgrade, in Analyze mode, the AutoUpgrade utility performs read-only analysis of databases before upgrade, so that it can identify issues that require fixing.

When you run Oracle Orachk in pre-upgrade mode, Oracle Orachk in turn runs the AutoUpgrade utility to check if each database is ready to upgrade or not.

Enhanced Activity Logging Framework for Oracle Exachk/Oracle Orachk

AHF 25.11 introduces a new activity logging framework designed to improve diagnostics, observability, and automated analysis across Oracle Exachk and Oracle Orachk executions.

This enhancement enables the collection, storage, and correlation of detailed execution logs, making it easier to identify unhealthy systems, and analyze long-term trends.

These activity logs will be automatically collected during Oracle Exachk/Oracle Orachk runs, updated in predefined locations, and included as part of Oracle Trace File Analyzer collections for streamlined troubleshooting.

Objectives

Capture insightful and structured logs from every Oracle Exachk/Oralce Orachk run.
Maintain metadata activity logs, check activity logs, environment logs, and runtime logs across multiple runs.
Provide users with accessible activity logs, ensuring that all registered Exachk users can view logs from their own runs.

What this logging enhances

Identify unhealthy systems
Highlight high-severity, high-frequency failures
- Correlate check failures with system degradation
Detect persistent issues across multiple runs
Spot increasing error counts indicating system decline

Who can access activity logs?

All registered users authorized to run Oracle Exachk can access the activity logs associated with their runs.

Platform support

This capability is available on all platforms supported by Oracle Exachk/Oracle Orachk.

Log management and lifecycle

Activity logs will be stored and maintained using standard log management practices:

Log rotation
Activity log files will be rotated when they exceed 250 KB.
Retention policy
Logs from the latest 10 runs will be retained.
When the count exceeds 10, the oldest log will be deleted.

Summary of benefits

Improves system health monitoring through historical context
Enables proactive identification of recurring or escalating issues

Oracle Exachk Dynamic Load-Aware Scheduler

AHF 26.3 introduces the Dynamic Load-Aware Scheduler, an intelligent enhancement that optimizes the timing of Exachk executions to minimize impact on system performance.

This feature analyzes historical operational telemetry, including CPU and memory usage, to identify recurring low-load periods on Exadata Database Machines and recommend the most suitable time for daily Exachk runs.

Unlike traditional static scheduling, the Dynamic Load-Aware Scheduler uses machine learning-driven pattern recognition combined with heuristic logic to determine a consistent and optimal execution window. By continuously learning from workload behavior, it enables Exachk to run during the most stable and least disruptive periods, improving operational efficiency and reducing potential interference with business-critical activities.

The scheduler functions as an advisory mechanism, allowing administrators to make informed, data-driven scheduling decisions tailored to their environment. It also supports customization through configurable parameters such as defining "busy hours", ensuring that Exachk runs are automatically excluded from critical workload periods. Time ranges spanning midnight are fully supported.

In scenarios where ideal low-load windows are not available, the scheduler ensures continuity by selecting the best possible time based on predefined safety thresholds. This guarantees that Exachk executions are not skipped, maintaining consistent system health checks while balancing performance considerations.

This feature requires minimal configuration, as model training, clustering, and recency weighting are handled automatically. Administrators only need to define practical constraints, such as excluded time ranges or preferred execution windows.

The Dynamic Load-Aware Scheduler enhances reliability and compliance by ensuring regular, low-impact Exachk runs. The feature is optional and can be adopted based on operational requirements.