Oracle Database extension

• Latest Dynatrace
• Extension
• Published Oct 27, 2025

Observe, analyze and optimize the usage, health and performance of your database

Get started

Overview

This extension is a remote extension that runs on an ActiveGate within your environment. It connects to each Oracle Database you want to monitor, executes a series of queries on various views, and sends the collected data back to Dynatrace

Dynatrace automatically detects all applications and microservices deployed in your system and how your system uses Oracle Database.

Dynatrace diagnoses anomalies in real time with AI and pinpoints the root cause in slow-performing or erroneous SQL statements. Deep code-level insights combined with cloud-native database server monitoring help you ensure a robust production environment.

The Oracle Database extension complements the client-side database usage insights by providing server-side observability starting with availability and performance statistics, down to individual SQL statements and log insights.

Use cases

Compatibility information

The following Oracle versions are supported:

The following architectures are supported:

Activation and setup

Get started for Oracle Database clients

If the application connecting to the Oracle Database server runs on a virtual machine or bare-metal, install OneAgent on that machine to get started.

If the application that connects to the Oracle Database server runs as a workload in Kubernetes or OpenShift, set up Dynatrace on Kubernetes or OpenShift. If the application runs as a workload in Kubernetes, set up Dynatrace on Kubernetes.

Activate the following OneAgent features to gain full tracing insights:

Get started with Oracle Database servers

If your Oracle Database server runs on a virtual machine or bare-metal, install OneAgent on it to start collecting system performance metrics.

To gain full visibility into the Oracle Database server’s health and performance, activate the remote Oracle Database extension. This extension gathers metrics and events by directly querying the database’s performance views, which requires a connection to the database.

Authentication

We recommend using a dedicated user account for monitoring. For convenience, you can find user creation scripts on GitHub. These scripts create a user with the CREATE_SESSION role and SELECT permissions on the following performance views:

Alternatively, you can assign the SELECT_CATALOG_ROLE to the monitoring user.

For multitenant Oracle DB setups, ensure the extension is configured to point to the CDB. PDB discovery and monitoring occur automatically. In this case, explicit permissions to access data across all containers are required:

alter user <your_username> set container_data=all container = current;

These privileges are already included in the user creation scripts.

Users of the Databases who want to make use of Query Execution Plans, will also need to provide permission for the V$SQL_PLAN, V$SESSION, V$SQL_PLAN_STATISTICS_ALL and V$SQL views. These permissions are included in the user creation scripts. See the execution plan monitoring section for more details.

Logs

Finally, activate log monitoring to get full log insight.

Details

This extension package contains:

Licensing and cost

The metrics collected through this extension consume Dynatrace Davis Data Units (see DDUs for metrics).

A rough estimation of the amount of DDUs consumed by metric ingest can be obtained through the following formula:

(55 * number of instances * 525.6) + (7 * number of databases * 525.6) + (8 * number of backup jobs per year * 0.005) + (5 * number of ASM disks * 525.6) + (3 * number of ASM disk groups * 525.6)

For logs, regular DDU consumption for log monitoring applies. Depending on your licensing model, refer either to DDU consumption for Log Management and Analytics or DDUs for Log Monitoring Classic.

Execution plan monitoring

For SaaS customers with access to the Databases, the execution plan monitoring functionality is also available when analyzing statement performance.

For this feature to work, the DBMS_XPLAN package needs to be available, and the user configured in the Dynatrace extension needs to have permissions to call the DISPLAY_CURSOR function. As per the official documentation this means that SELECT or READ permissions are required on the following views:

In addition to this, the SELECT permission is also required for V$SQL_PLAN.

Sensitive data masking

Query performance tracking may expose sensitive data in reported statements. Dynatrace provides an optional mechanism that allows masking selected attributes. For details, see Log processing examples.

The configurations below provide an example of how sensitive data can be masked within tracked statements:

DQL and Logs

Audit log files tracking

Check log file's location

Add OneAgent Log module security rules

Configure OneAgent Log module security rules to allow access to local files, by adding the oracle.json file:

{
    "@version": "1.0.0",
    "allowed-log-paths-configuration": [
        {
            "directory-pattern": "/u01/app/oracle/admin/oracle_standalone/adump/",
            "file-pattern": "*.aud",
            "action": "INCLUDE"
        }
    ]
}

OneAgent restart is not required, this configuration is applied within 1 minute.

Configure custom log source and log ingest rules

Custom log source

Use the log file location fetched via the query executed in the first step, for example, /u01/app/oracle/admin/oracle_standalone/adump/*.

Log ingest rules

An example configuration that includes only ORA-01017 that reports invalid username or password logon attempts could be configured using:

Log content is any of: (.*)RETURNCODE:\[(\d+)\] "1017 AND Log source is any of:
/u01/app/oracle/admin/oracle_standalone/adump/*

Accessing logs

Logs collected the way described above can be accessed using following DQL query:

fetch logs
| filter matchesValue(log.source, "/u01/app/oracle/admin/oracle_standalone/adump/*")

Metrics extraction

Log processing rule

Configure log processing rule to extract log attributes out of the log content:

Metric extraction

Extract metrics from log entries to enable alerting:

FAQ

Troubleshooting

Feature sets

When activating your extension using monitoring configuration, you can limit monitoring to one of the feature sets. To work properly the extension has to collect at least one metric after the activation.

In highly segmented networks, feature sets can reflect the segments of your environment. Then, when you create a monitoring configuration, you can select a feature set and a corresponding ActiveGate group that can connect to this particular segment.

All metrics that aren't categorized into any feature set are considered to be the default and are always reported.

Explore in Dynatrace Hub

Observe, analyze and optimize the usage, health and performance of your database