Compliance Checking with Oracle Orachk and Oracle Exachk

Oracle Orachk and Oracle Exachk share a common compliance check framework and a large portion of their features and tasks are common.

Getting Started with Running Compliance Checks

Oracle Orachk and Oracle Exachk support non-root execution, including authorized root-privileged checks through TFA access roles, direct access to user-specific repositories, scheduled and on-demand compliance assessments, remote synchronous or asynchronous runs using passwordless SSH, custom check profiles, sensitive-data redaction through ACR, automated problem repairs, DBSAT security assessments, AutoUpgrade readiness checks, and enhanced activity logging. TFA manages scheduled cluster-wide runs, notifications, retention, and master-node coordination, while reports provide health scores, findings, recommendations, comparisons, and MAA scorecards. A dynamic load-aware Exachk scheduler can additionally recommend lower-impact execution windows based on system telemetry.

Running Compliance Checks Automatically

Oracle Orachk and Oracle Exachk daemon mode, supported on Linux and Solaris, automates recurring checks, notifications, collection purging, password validation, multiple scheduling profiles, and restart behavior. Administrators configure schedules, run flags, recipients, retention periods, password-check intervals, and profile-specific settings with -set, inspect them with -get or -autostatus, and manage execution with -autostart, -autostop, and optional monthly or randomized run windows. The daemon can be configured for automatic startup and reboot recovery, while status commands show scheduler details and the next run; on-demand checks may use or bypass the daemon, and reports can be emailed directly.

Running Compliance Checks On-Demand

On-demand Oracle Orachk and Oracle Exachk runs assess system health outside scheduled intervals, including before or after upgrades, after hardware or network changes, during troubleshooting, and for go-live validation. The tools discover components, evaluate SSH equivalency, collect local and remote data, handle required credentials interactively or through the daemon and Expect utility, execute checks, and provide HTML and ZIP output locations. Pre- and post-upgrade modes use -u -o pre or -u -o post, while -nodaemon forces independent interactive execution; results can be emailed with -sendemail, and runtime depends on cluster size, database topology, hardware, and workload.

Running Compliance Checks in Silent Mode

Silent mode provides legacy automated compliance execution for backward compatibility and is less capable than daemon mode. The -s option runs silent checks, including root-dependent checks when executed with appropriate privileges, but excludes storage-server and switch checks; -S additionally excludes database checks requiring root access. Passwordless SSH is needed for remote collection, while local single-instance checks may not require it. Silent-mode output resembles on-demand reports, and engineered-system storage or InfiniBand checks require suitable environment configuration.

Understanding and Managing Reports and Output

Oracle Orachk and Oracle Exachk use configurable temporary and output directories, with locations controlled by RAT_TMPDIR, RAT_ROOT_SH_DIR, RAT_OUTPUT, and related options. Generated collections include logs, scripts, reports, upload data, HTML output, and ZIP archives containing health scores, findings, recommendations, security results, MAA assessments, skipped checks, timing data, and platform-specific sections. Reports can be tagged, filtered, compared, merged, selectively hidden, or generated in chosen formats; file-attribute snapshots support baseline tracking and change detection. Output growth can be managed through RAT_PURGE_SIZE, COLLECTION_RETENTION, or manual cleanup, while Exachk additionally supports format-specific collections, Exadata Live Update status, and structured System Overview data for Exadata environments.

Compare Configuration Across Two Different Systems

Oracle Orachk and Oracle Exachk can compare configuration data from two different systems, such as primary and standby, test and production, or healthy and unhealthy environments. Run the checks on both systems, then use the -diff option with their collection ZIP files; adding -force and -showallcomparison compares all applicable database servers, storage servers, switches, ASM, patches, and other discovered targets. The resulting report identifies differing values, system-specific values, and common configurations.

Running Subsets of Checks

Oracle Orachk and Oracle Exachk support targeted compliance runs through upgrade-readiness modes, component-selection options, profiles, individual check IDs, and failed-check reruns. Pre-upgrade and post-upgrade modes assess Oracle Clusterware, databases, and operating systems, while options such as -dball, -dbnone, -dbnames, -pdbnames, -clusternodes, -localonly, -cell, and -ibswitches restrict checks to selected resources. Profiles run, include, or exclude logical check groups; individual checks can be selected or persistently excluded, and -failedchecks reruns only checks that failed in a previous result. The tools also support standalone Grid Infrastructure checks, privileged-user identification, and the netperf profile for RAC network bandwidth testing.

Understanding Oracle Exachk specifics for Oracle Exadata and Zero Data Loss Recovery Appliance

Oracle Exachk operation on Oracle Exadata and Zero Data Loss Recovery Appliance depends on interface selection, virtualization, execution privileges, collection mode, and component access. Management interfaces can be selected with -clusternodes, while virtualized environments require root execution in DOM0 for hardware and operating-system checks and separate runs in applicable DOMU clusters. Data collection can be made serial through component-specific environment variables, and role-separated environments may require installations on multiple database servers followed by report merging. Alternative storage-server and InfiniBand switch users can be configured, with reduced checks based on privileges; troubleshooting guidance covers unsupported environments causing RC-003 and expected execution times.

Integrating Compliance Check Results with Other Tools

Oracle Orachk and Oracle Exachk results can be integrated with Oracle Enterprise Manager, third-party analytics platforms, syslog, and custom applications. Enterprise Manager integrations provide compliance standards, dashboards, target views, violations, scores, and drill-down access to individual checks, while JSON files in each collection’s upload directory support filtering and visualization in tools such as Elasticsearch and Kibana. Results can also be uploaded to centralized database tables for collections, compliance findings, and patch data; upload status is recorded in check_env.out, failed uploads can be listed and retried, and successfully uploaded collections cannot be duplicated because of database uniqueness constraints.

Using Oracle Orachk to Confirm System Readiness for Implementing Application Continuity

Oracle Orachk provides Application Continuity readiness checking to support transparent deployment, but beginning with Oracle Database 19.10, the Application Continuity Protection Check replaces the legacy orachk acchk command.

Running Oracle ZFS Storage Appliance Compliance Checks

Oracle Orachk can assess one or more Oracle ZFS Storage Appliances using the -zfssa option, with appliance names supplied individually or as a comma-separated list for multiple targets.

Using Oracle Exachk on Oracle Big Data Appliance

Oracle Exachk for Oracle Big Data Appliance versions later than 2.0.1 audits CPU, hardware, firmware, BIOS, operating-system settings, network switches, memory, disks, and installed software to assess appliance health and recommend corrective actions. Run it after deployment, before and after environmental changes, and at least quarterly, preferably during low system load. From node1, run as root; use exachk -h to view options and exachk -a to perform all supported checks, including best-practice recommendations. Review FAIL, WARNING, and INFO statuses to prioritize remediation. For switch communication timeouts, increase the SSH timeout with export RAT_PASSWORDCHECK_TIMEOUT=40 and rerun exachk -a; consult My Oracle Support for unresolved issues and known problems.

Easily Manage Cell Switches Databases and exacli Passwords

Oracle Autonomous Health Framework provides commands for managing Exadata cell, switch, database, and exacli passwords. The tfactl setpassword, checkpassword, and unsetpassword commands are deprecated from AHF 21.1, so new configurations should use the corresponding ahfctl commands. The deprecated setpassword syntax supports selecting nodes, databases, users, and exacli credentials through the -nodes, -dbs, -user, and -exacli options.

Using the exadcli Utility to Collect Cell Metric Data for Guest VMs

The exadcli utility runs ExaCLI commands across remote nodes identified by host name or IP address to collect cell metrics for guest VMs on cloud systems. Before use, accept each cell or database node’s identity certificate with ExaCLI, save authentication cookies, install Java 1.8 or later, and set JAVA_HOME; cookies remain valid for 24 hours and may need renewal after upgrades or certificate changes. Run exachk -profile workload-capacity to collect metrics, which are written to capacity_exadcli.out in the Oracle Exachk collection directory.

Query AHF Message Codes to Understand More About the Context and Next Steps

AHF message codes provide additional context and recommended next steps for Oracle Orachk and Oracle Exachk findings. Locate the four-digit code in the JSON results file, then query it from the AHF installation directory with $AHF_HOME/bin/oerr AHF <code>, such as $AHF_HOME/bin/oerr AHF 4040, and review the returned guidance.

Improved Resource Usage During Compliance Checking

Oracle Orachk and Oracle Exachk improve compliance-check efficiency through the SQL Agent, a daemon that maintains reusable database connection pools. If the SQL Agent fails, the tools automatically use SQL*Plus, creating a new connection for each query. To troubleshoot connection errors, unexpected results, or possible false positives or negatives associated with the SQL Agent, bypass it with orachk -use_sqlplus or exachk -use_sqlplus; if problems continue, provide the relevant logs and output to My Oracle Support.
Read More: Improved Resource Usage During Compliance Checking