Oracle Database extension

  • Latest Dynatrace
  • Extension

Collect Oracle Database metrics and audit logs to monitor performance and security.

Get started

Overview

This remote extension 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 to Dynatrace.

Dynatrace automatically detects all applications and microservices in your system and their Oracle Database usage.

Dynatrace uses AI to diagnose anomalies in real time and identify root causes in slow-performing or erroneous SQL statements. Code-level insights combined with database server monitoring provide full-stack observability.

The Oracle Database extension provides server-side monitoring with availability and performance statistics, SQL statements, and log insights.

Use cases

  • Understand all database dependencies of your applications, which statements they execute, and their performance.
  • Improve the performance of your application by reducing or optimizing typical database patterns like the 1+N query problem.
  • Understand the resource impact that your applications have on your database.
  • Understand the impact that resource shortages or other database issues have on your application by observing the database server itself.
  • Manage and analyze Oracle Database audit logs to spot invalid login attempts.
  • Track the health and performance of Oracle Database servers (either standalone or multi-tenant).
  • Track the performance of the most time-consuming queries.
  • Speed up application-problem diagnosis when it's caused by the database.

Requirements

  • Decide which Oracle Database server to monitor. The extension supports Oracle Database 12.2+ with the following setups:
    • Oracle standalone servers
    • Oracle Multitenant (CDB/PDB)
    • Oracle RAC
    • Oracle AWS RDS
  • Designate an ActiveGate group or groups that connect to your Oracle Database server to collect data. All ActiveGates in each group must connect to your Oracle Database server.
  • Create a dedicated database user in your database instance with the necessary permissions as described below. Dynatrace uses this user to run monitoring queries against your Oracle database.

    • Authenticate user accounts

      Use a dedicated user account for monitoring. 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:

      Performance views
      • CDB_DATA_FILES
      • CDB_TABLESPACE_USAGE_METRICS
      • CDB_TABLESPACES
      • CDB_TEMP_FILES
      • GV_$ARCHIVE_DEST
      • GV_$ARCHIVE_DEST_STATUS
      • V_$ASM_DISK_STAT
      • V_$ASM_DISKGROUP_STAT
      • V_$BACKUP_SET_DETAILS
      • GV_$CLUSTER_INTERCONNECTS
      • GV_$CONTAINERS
      • V_$CONTAINERS
      • GV_$CON_SYS_TIME_MODEL
      • GV_$CON_SYSSTAT
      • GV_$DATABASE
      • V_$DATABASE
      • V_$DATABASE_BLOCK_CORRUPTION
      • GV_$DATAFILE
      • V_$DATAFILE
      • GV_$DATAGUARD_STATUS
      • GV_$INSTANCE
      • V_$INSTANCE
      • GV_$INSTANCE_PING
      • GV_$LIBRARYCACHE
      • V_$LOG
      • GV_$METRIC
      • GV_$METRICGROUP
      • GV_$PARAMETER
      • GV_$PDBS
      • GV_$PGASTAT
      • V_$RECOVER_FILE
      • V_$RECOVERY_FILE_DEST
      • GV_$RESOURCE_LIMIT
      • V_$RMAN_BACKUP_JOB_DETAILS
      • GV_$SESSION
      • V_$SESSION
      • GV_$SGASTAT
      • GV_$SQL
      • V_$SQL
      • GV_$SQLAREA
      • V_$SQL_PLAN
      • GV_$SQL_PLAN
      • V_$SQL_PLAN_STATISTICS_ALL
      • GV_$SYSSTAT
      • GV_$SYSTEM_EVENT
      • GV_$SYSTEM_WAIT_CLASS
      • V_$TABLESPACE
      • V_$TEMPFILE

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

      From version 3.9.2+, the extension queries the local IP of each node on RAC setups using the UTL_INADDR.get_host_address function. As such, the following Access Control List permission is required:

      BEGIN
      DBMS_NETWORK_ACL_ADMIN.create_acl (
      acl => 'dynatrace.xml',
      description => 'Allow DNS resolution checks to get RAC node IP addresses',
      principal => '<DYNATRACE_USER>',
      is_grant => TRUE,
      privilege => 'resolve',
      start_date => SYSTIMESTAMP,
      end_date => NULL);
      FOR instance_host IN (
      SELECT DISTINCT host_name
      FROM gv$instance -- Retrieves all RAC node hostnames
      ) LOOP
      DBMS_NETWORK_ACL_ADMIN.assign_acl (
      acl => 'dynatrace.xml',
      host => instance_host.host_name, -- Assign ACL to each instance host
      lower_port => NULL,
      upper_port => NULL
      );
      END LOOP;
      COMMIT;
      END;
      /

      This applies only to RAC databases or other multi-instance setups. The UTL_INADDR.get_host_address query runs only if the rac feature set is enabled. These permissions are already included in the user creation scripts.

      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 Databases who want to use Query Execution Plans must also 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. For more details, see the execution plan monitoring section.

Compatibility information

The following Oracle versions are supported:

  • Oracle DB 12.2+

The following architectures are supported:

  • Oracle standalone servers
  • Oracle Multitenant (CDB/PDB)
    • Configure monitoring for CDB to detect all PDBs.
  • Oracle AWS RDS
  • Oracle RAC
    • Configure monitoring for the SCAN listener to detect all instances and databases.

Activation and setup

Follow these steps to set up server-side monitoring for Oracle databases.

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

To monitor Oracle Database server health and performance, activate the Oracle Database extension. The extension queries database performance views to collect metrics and events.

Add DB instance

  1. Go to Dynatrace Hub Hub.

  2. Select and install Oracle Database extension. This enables the extension in your monitoring environment.

    • Required permission: Change monitoring settings
  3. Select Add DB Instance in Databases Databases. This opens the Add DB Instance wizard.

  4. Select Oracle section in the wizard.

Select hosting type

Select a hosting type from the options. This choice determines which script generates the necessary database objects later in the process.

  1. From the Add DB Instance wizard, select the host type that matches your requirement.
  2. Select Next.

Select ActiveGate group

  1. Select the ActiveGate group to determine which ActiveGates will run the extension.
  2. Select Next step.

Accept license agreement

The Oracle Database extension requires that you accept the Dynatrace redistribution license agreement for Oracle JDBC Driver.

Create a connection

Set up the connection to your database instance. Provide the required credentials directly in the wizard or use secure alternatives:

  1. Name the connection, so you can identify it later.
  2. Add the details in the Configure connection section.
    1. Select connection. Use Select from existing hosts or Enter manually to add connection details.
    2. Add Database identifier, either Service Name or SID.
    3. Add Service name.
  3. Provide the Authenticate credentials for the dynatrace monitoring user you have created directly or use secure alternatives.
    • Basic credentials: Dynatrace masks the authentication details you provide to prevent them from being retrieved.
    • Credential vault: Use vault credentials to securely store and retrieve database credentials.
  4. Select Next.

Install instance

  1. Add manual configurations based on the monitoring requirements.
  2. Select Create DB instance monitoring.

Get started for Oracle Database clients

Follow these steps to set up client-side monitoring for Oracle databases.

Activate the following OneAgent features to gain full tracing insights:

  • Node.js Oracle DB
  • PHP Oracle

Activate log monitoring

Activate log monitoring to get full log insight.

With the TopN feature set, the extension reports the most time-consuming queries on the Oracle Instance entity page, in a Logs card. Enabling this feature may expose sensitive data in the reported queries.

Details

Extension package

This extension package contains:

  • Topology and relationship definitions for RAC Clusters, Backup Jobs, Databases, Instances, ASM Disks, and ASM Disk Groups.
  • Classic and New Dashboard offering a monitoring overview for the Oracle Database environment.
  • Alerts for failed backups, unavailable PDBs, unavailable instances, high tablespace usage, and more.
  • Unified Analysis page for the above-mentioned topology.

Licensing and cost

There is no charge for obtaining the extension, only for the data (metrics and logs) that the extension ingests. The details of license consumption depend on which licensing model you are using: either Dynatrace classic licensing or the Dynatrace Platform Subscription (DPS) model.

Dynatrace Platform Subscription

With a Dynatrace Platform Subscription (DPS) license:

  • For metrics, license consumption is based on the number of metric data points ingested. This is billed as Metrics powered by Grail.

    The following formula provides the approximate annual data points ingested assuming all feature sets are enabled. Actual ingested metric data point volumes depend heavily on your specific Oracle Database environment.

    (
    (55 * number of instances)
    + (7 * number of databases)
    + (8 * number of backup jobs per year)
    + (5 * number of ASM disks)
    + (3 * number of ASM disk groups)
    )
    * 60 minutes * 24 hours * 365 days data points per year
  • For logs, regular consumption for Log Analytics applies, see Log Analytics overview (DPS).

Classic licensing

With a Dynatrace classic license:

Execution plan monitoring

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

For this feature to work, the DBMS_XPLAN package must be available, and the monitoring user must have permission to call the DISPLAY_CURSOR function. Per the official documentation, SELECT or READ permissions are required on the following views:

  • V$SQL_PLAN
  • V$SESSION
  • V$SQL_PLAN_STATISTICS_ALL
  • V$SQL

Sensitive data masking

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

The following configurations show how to mask sensitive data in tracked statements:

  • Create a new processing rule under Settings > Log Monitoring > Processing.

    • Processor definition: USING(INOUT content) | FIELDS_ADD(content: REPLACE_PATTERN(content, "(\"'\"):p1 (LD):p2 (\"'\"):p3", "${p1}${p2|sha1}${p3}"))
  • Alternatively, create/modify your custom extension to distribute such rules across your environment.

    logProcessingRules:
    - ruleName: TopN statements masking
    query: event.group="query_performance"
    enabled: true
    ProcessorDefinition:
    rule: |
    USING(INOUT content) | FIELDS_ADD(content: REPLACE_PATTERN(content, "(\"'\"):p1 (LD):p2 (\"'\"):p3", "${p1}${p2|sha1}${p3}"))
    RuleTesting:
    sampleLog: |
    {
    "event.group": "query_performance",
    "content": "/*dt:ownQuery*/SELECT DECODE(name, 'sessions', value) AS sessions_limit, DECODE(name, 'processes', value) AS processes_limit FROM v$parameter WHERE name IN('sessions', 'processes')"
    }

DQL and logs

Audit log files tracking

Check log file's location
  • SELECT name, value FROM v$parameter WHERE name = 'audit_trail';
    OS means that the audit logs are stored locally on the file system.
  • SELECT value FROM v$parameter WHERE name = 'audit_file_dest';
    Specifies the 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:

  • on Linux/UNIX: /var/lib/dynatrace/oneagent/agent/config/logmodule
  • on Windows: %PROGRAMDATA%\dynatrace\oneagent\agent\config\logmodule
{
"@version": "1.0.0",
"allowed-log-paths-configuration": [
{
"directory-pattern": "/u01/app/oracle/admin/oracle_standalone/adump/",
"file-pattern": "*.aud",
"action": "INCLUDE"
}
]
}

No OneAgent restart is required. The configuration takes effect within 1 minute.

Configure custom log source and log ingest rules
Custom log source

Use the log file location from the first query, for example, /u01/app/oracle/admin/oracle_standalone/adump/*.

Log ingest rules

To capture only ORA-01017 (invalid username or password login attempts), configure the log ingest rule as follows:

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

Access the collected logs using the following DQL query:

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

Metrics extraction

Log processing rule

Configure the log processing rule to extract log attributes from the log content:

  • Rule name: preferred name
  • Matcher: matchesValue(log.source, "/u01/app/oracle/admin/oracle_standalone/adump/*")
  • Processor definition:
    PARSE(content, "
    DATA ' RETURNCODE:['INT']' SPACE '\"' INT:ora.returncode LD") |
    PARSE(content, "
    DATA ' USERID:['INT']'SPACE CSVDQS:ora.userid LD") |
    PARSE(content, "
    DATA ' USERHOST:['INT']'SPACE CSVDQS:ora.userhost LD")
Metric extraction

Extract metrics from log entries to enable alerting:

  • Metric key: for example, log.oracle.invalid_credentials
  • Matcher: matchesValue(log.source, "/u01/app/oracle/admin/oracle_standalone/adump/*")
  • Metric measurement: Occurence of logs records
  • Dimensions: specify the log attributes to be used as metric dimensions

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.

A metric inherits the feature set of a subgroup, which in turn inherits the feature set of a group. Also, the feature set defined on the metric level overrides the feature set defined on the subgroup level, which in turn overrides the feature set defined on the group level.

waitEvents (detailed)
Metric nameMetric keyDescription
Number of wait eventscom.dynatrace.extension.sql-oracle.wait.events.countTotal number of waits by wait event, excluding 'Idle' events. Only collects the top 20 most time consuming events.
Seconds waitedcom.dynatrace.extension.sql-oracle.wait.events.time.countTotal amount of time waited by wait event, excluding 'Idle' events. Only collects the top 20 most time consuming events.
tablespaces
Metric nameMetric keyDescription
Total sizecom.dynatrace.extension.sql-oracle.tablespaces.totalSpaceTotal size of tablespace, including extensibility. This covers both allocated an unallocated space as large as the tablespace can expand.
Free spacecom.dynatrace.extension.sql-oracle.tablespaces.freeSpaceTotal free space available in the tablespace, in bytes. This includes space that is currently allocated and available for reuse and space that is currently unallocated.
Used spacecom.dynatrace.extension.sql-oracle.tablespaces.usedSpaceTotal space in use within the tablespace, in bytes.
Tablespace usagecom.dynatrace.extension.sql-oracle.tablespaces.usageThe percentage of tablespace in use, relative to the total size (including extensibility).
rac
Metric nameMetric keyDescription
Instance pingcom.dynatrace.extension.sql-oracle.rac.instance_pingRepresents the current inter-instance ping of 8K messages as provided in GV$INSTANCE_PING.
com.dynatrace.extension.sql-oracle.rac.interconnects
default
Metric nameMetric keyDescription
Cluster topologycom.dynatrace.extension.sql-oracle.cluster_topologyA state metric whose dimensions represent all Oracle clusters and their linked instances and hosts
Database topologycom.dynatrace.extension.sql-oracle.database_topologyA state metric whose dimensions represent all Oracle instances and their linked databases
Instance statuscom.dynatrace.extension.sql-oracle.statusA state metric representing the details of the connected Oracle instance.
Instance Uptimecom.dynatrace.extension.sql-oracle.uptimeThe uptime of the Oracle instance in seconds.
Database statuscom.dynatrace.extension.sql-oracle.db_statusA state metric representing details of the connected Oracle database.
asm (detailed)
Metric nameMetric keyDescription
Free spacecom.dynatrace.extension.sql-oracle.asm.disk.free_mbFree disk space available on this Oracle ASM Disk
Total spacecom.dynatrace.extension.sql-oracle.asm.disk.total_mbTotal disk space available on this Oracle ASM Disk
Used spacecom.dynatrace.extension.sql-oracle.asm.disk.usagePercentage of disk space used on this Oracle ASM Disk
Readscom.dynatrace.extension.sql-oracle.asm.disk.reads.countNumber of reads from this Oracle ASM Disk
Writescom.dynatrace.extension.sql-oracle.asm.disk.writes.countNumber of writes to this Oracle ASM Disk
TopN
Metric nameMetric keyDescription
Datafiles
Metric nameMetric keyDescription
Datafile statuscom.dynatrace.extension.sql-oracle.datafile.statusState metric representing the status of Datafiles and Tempfiles across containers (database and any PDBs).
Datafile number of corrupted blockscom.dynatrace.extension.sql-oracle.datafile.corrupted_blocksMetric representing the number of corrupted blocks reported by V$DATABASE_BLOCK_CORRUPTION for each Datafile
waitEvents
Metric nameMetric keyDescription
Number of wait events by wait classcom.dynatrace.extension.sql-oracle.wait.countTotal number of waits by wait class, excluding 'Idle' events
Seconds waited by wait classcom.dynatrace.extension.sql-oracle.wait.time.countTotal amount of time waited by wait class, excluding 'Idle' events
io
Metric nameMetric keyDescription
Physical bytes readcom.dynatrace.extension.sql-oracle.io.bytesRead.countTotal size in bytes of disk reads by all database instance activity including application reads, backup, recovery, and other utilities
Physical bytes writtencom.dynatrace.extension.sql-oracle.io.bytesWritten.countTotal size in bytes of all disk writes for the database instance including application activity, backup, recovery, and other utilities
Total wait timecom.dynatrace.extension.sql-oracle.io.wait.countTotal time spent in all wait states except for Idle class
Data guard
Metric nameMetric keyDescription
Dataguard severe eventscom.dynatrace.extension.sql-oracle.dataguard.severeEventsCounts the number of fatal and severe Data guard events occurred in the last day. If this count is greater than 0, check its dimensions to take action for the specific events.
NOLOGGING activitycom.dynatrace.extension.sql-oracle.dataguard.nologgingActivityCounts the number of files which contain NOLOGGING activity in the last day. If the count is greater than 0 then the standby database is vulnerable; check the dimensions to find out which files must be refreshed on the standby.
Archive destination statuscom.dynatrace.extension.sql-oracle.dataguard.archiveDestErrStatusCounts the number of invalid or errored statuses of archive destinations. If the count is greater than 0, use the dimensions to understand the status and destination it refers to.
Seq. differencecom.dynatrace.extension.sql-oracle.dataguard.seqDifferenceTracks the difference in sequence number between the latest archived and applied redo log. Use this count along with the dimensions to identify gaps between the primary and archive destination.
tablespaces (detailed)
Metric nameMetric keyDescription
Total sizecom.dynatrace.extension.sql-oracle.tablespaces.totalSpaceTotal size of tablespace, including extensibility. This covers both allocated an unallocated space as large as the tablespace can expand.
Free spacecom.dynatrace.extension.sql-oracle.tablespaces.freeSpaceTotal free space available in the tablespace, in bytes. This includes space that is currently allocated and available for reuse and space that is currently unallocated.
Used spacecom.dynatrace.extension.sql-oracle.tablespaces.usedSpaceTotal space in use within the tablespace, in bytes.
Allocated spacecom.dynatrace.extension.sql-oracle.tablespaces.allocatedSpaceTotal space in use within the tablespace, in bytes.
Tablespace usagecom.dynatrace.extension.sql-oracle.tablespaces.usageThe percentage of tablespace in use, relative to the total size (including extensibility).
Blocked sessions
Metric nameMetric keyDescription
multitenancy
Metric nameMetric keyDescription
Total sizecom.dynatrace.extension.sql-oracle.pdb-total_sizeShows the disk space (in bytes) used by the PDB, including both data and temp files.
Block sizecom.dynatrace.extension.sql-oracle.pdb-block_sizeThe current block size for the PDB
Diagnostic sizecom.dynatrace.extension.sql-oracle.pdb-diagnostic_sizeShows the current disk space usage (in bytes) of the diagnostic traces generated in the PDB.
Audit files sizecom.dynatrace.extension.sql-oracle.pdb-audit_files_sizeShows the current disk space usage (in bytes) by Unified Audit files (.bin format) in the current PDB.
Max sizecom.dynatrace.extension.sql-oracle.pdb-max_sizeShows the maximum amount of disk space (in bytes) that can be used by data and temp files in the PDB. If the value is 0 then there is no limit.
Max diagnostic sizecom.dynatrace.extension.sql-oracle.pdb-max_diagnostic_sizeShows the maximum amount of disk space (in bytes) that can be used by diagnostic traces generated in the PDB. If the value is 0 then there is no limit.
Max audit sizecom.dynatrace.extension.sql-oracle.pdb-max_audit_sizeShows the maximum amount of disk space (in bytes) that can be used by Unified Audit files (.bin format) in the PDB. If the value is 0 then there is no limit.
asm
Metric nameMetric keyDescription
Free spacecom.dynatrace.extension.sql-oracle.asm.disk_group.free_mbFree disk space available on this Oracle ASM Disk Group
Total spacecom.dynatrace.extension.sql-oracle.asm.disk_group.total_mbTotal disk space available on this Oracle ASM Disk Group
Used spacecom.dynatrace.extension.sql-oracle.asm.disk_group.usagePercentage of disk space used on this Oracle ASM Disk Group
backupJob
Metric nameMetric keyDescription
Input bytescom.dynatrace.extension.sql-oracle.backup-input_bytesSum of all input file sizes backed up.
Output bytescom.dynatrace.extension.sql-oracle.backup-output_bytesOutput size of all pieces generated.
Elapsed secondscom.dynatrace.extension.sql-oracle.backup-elapsed_secondsNumber of elapsed seconds.
Compression ratiocom.dynatrace.extension.sql-oracle.backup-compression_ratioCompression ratio.
Input bytes per secondcom.dynatrace.extension.sql-oracle.backup-input_bytes_per_secondInput read-rate-per-second.
Output bytes per secondcom.dynatrace.extension.sql-oracle.backup-output_bytes_per_secondOutput write-rate-per-second.
Auto - backup countcom.dynatrace.extension.sql-oracle.backup-autobackup_count_numberNumber of autobackups performed by this job.
Backup statecom.dynatrace.extension.sql-oracle.backup.stateA state metric representing the details of a Backup Job.
Time since last backupcom.dynatrace.extension.sql-oracle.backup.time_sinceThe time elapsed since the last backup completed successfully.
memory
Metric nameMetric keyDescription
PGA aggregate limitcom.dynatrace.extension.sql-oracle.memory.pga.size.pgaAggregateLimitLimit on the aggregate PGA memory consumed by the instance
PGA aggregate targetcom.dynatrace.extension.sql-oracle.memory.pga.size.pgaAggregateTargetTarget aggregate PGA memory available to all server processes attached to the instance
PGA memory usedcom.dynatrace.extension.sql-oracle.memory.pga.usedPGA memory consumed by work areas
Allocated PGAcom.dynatrace.extension.sql-oracle.memory.pga.allocatedCurrent amount of PGA memory allocated by the instance
Shared pool freecom.dynatrace.extension.sql-oracle.memory.sga.cacheBuffer.sharedPoolFreeAmount of free system global area (SGA) memory available in shared pool
Redo log space wait timecom.dynatrace.extension.sql-oracle.memory.sga.redoBuffer.redoLogSpaceWaitTime.countTotal elapsed time of waiting for redo log space request
Redo size increasecom.dynatrace.extension.sql-oracle.memory.sga.redoBuffer.redoSizeIncrease.countTotal amount of redo generated in bytes
Redo write timecom.dynatrace.extension.sql-oracle.memory.sga.redoBuffer.redoWriteTime.countTotal elapsed time of the write from the redo log buffer to the current redo log file
Logical readscom.dynatrace.extension.sql-oracle.memory.sessionLogicalReads.countThe sum of "db block gets" plus "consistent gets"
Physical readscom.dynatrace.extension.sql-oracle.memory.physicalReads.countTotal number of data blocks read from disk
Physical reads directcom.dynatrace.extension.sql-oracle.memory.physicalReadsDirect.countNumber of reads directly from disk, bypassing the buffer cache
Sorts in memorycom.dynatrace.extension.sql-oracle.memory.memorySorts.countNumber of sort operations that were performed completely in memory and did not require any disk writes
Sorts on diskcom.dynatrace.extension.sql-oracle.memory.diskSorts.countNumber of sort operations that required at least one disk write
DB Block gets from cachecom.dynatrace.extension.sql-oracle.memory.dbBlockGetsFromCache.countNumber of times a consistent read was requested for a block from the buffer cache.
Consistent gets from cachecom.dynatrace.extension.sql-oracle.memory.consistentGetsFromCache.countNumber of times a CURRENT block was requested from the buffer cache.
Physical reads into cachecom.dynatrace.extension.sql-oracle.memory.physicalReadsCache.countTotal number of data blocks read from disk into buffer cache.
Library cache hit ratiocom.dynatrace.extension.sql-oracle.memory.libraryCacheHitRatioLibrary cache hit ratio
limits
Metric nameMetric keyDescription
Sessions utilizationcom.dynatrace.extension.sql-oracle.limits.sessions_utilizationUtilization of sessions on the instance. This is a percentage of current utilization relative to the limit.
Processes utilizationcom.dynatrace.extension.sql-oracle.limits.processes_utilizationUtilization of processes on the instance. This is a percentage of current utilization relative to the limit.
sessions
Metric nameMetric keyDescription
Active Sessionscom.dynatrace.extension.sql-oracle.sessions.activeActive sessions count
Blocked Sessionscom.dynatrace.extension.sql-oracle.sessions.blockedBlocked sessions count
Total sessionscom.dynatrace.extension.sql-oracle.sessions.allTotal sessions count
User callscom.dynatrace.extension.sql-oracle.sessions.userCalls.countTotal number of logins, parses, or execute calls
Deadlockscom.dynatrace.extension.sql-oracle.sessions.deadlocks.countTotal number deadlocks
FRA
Metric nameMetric keyDescription
FRA Usagecom.dynatrace.extension.sql-oracle.fra.usageThe percentage disk utilization in the fast recovery area.
FRA limitcom.dynatrace.extension.sql-oracle.fra.limitMaximum amount of disk space (in bytes) that the database can use for the fast recovery area. This is the value specified in the DB_RECOVERY_FILE_DEST_SIZE initialization parameter.
FRA usedcom.dynatrace.extension.sql-oracle.fra.usedAmount of disk space (in bytes) used by fast recovery area files created in current and all previous fast recovery areas. Changing fast recovery areas does not reset SPACE_USED to 0.
FRA reclaimablecom.dynatrace.extension.sql-oracle.fra.reclaimableTotal amount of disk space (in bytes) that can be created by deleting obsolete, redundant, and other low priority files from the fast recovery area
cpu
Metric nameMetric keyDescription
CPU corescom.dynatrace.extension.sql-oracle.cpu.coresNumber of CPU cores
Background CPU usage (per second)com.dynatrace.extension.sql-oracle.cpu.backgroundTotalCPU usage of background processes in centi seconds per second
Foreground CPU usage (per second)com.dynatrace.extension.sql-oracle.cpu.foregroundTotalCPU usage of foreground processes in centi seconds per second
queryPerformance
Metric nameMetric keyDescription
Connection management timecom.dynatrace.extension.sql-oracle.queries.connectionManagement.countTime spent on performing session connect and disconnect calls
PL SQL exec timecom.dynatrace.extension.sql-oracle.queries.plSqlExec.countTime spent on running the PL/SQL interpreter
SQL exec timecom.dynatrace.extension.sql-oracle.queries.sqlExec.countTime spent on executing SQL
SQL parse timecom.dynatrace.extension.sql-oracle.queries.sqlParse.countTime spent on parsing SQL
DB Timecom.dynatrace.extension.sql-oracle.queries.dbTime.countTime spent on performing Database user-level calls
DB CPUcom.dynatrace.extension.sql-oracle.queries.cpuTime.countCPU time spent on performing database user-level calls

FAQ

How does this Dynatrace extension collect data from my databases?

This extension runs on your Dynatrace ActiveGates and connects to the configured databases. Once the connection is established, the extension regularly runs queries on the database to gather performance and health metrics, reporting the results back to Dynatrace.

The extension executes only SELECT queries to collect data, and most of these target GV$ or V$ views. To see exactly which queries are executed, download the extension yaml artifact by going to Release notes, opening a release and pressing the Download version button.

How often are these monitoring queries executed?

From version 3.2.0, the query-interval and heavy-query-interval configuration variables control query execution frequency. Most queries run every query-interval minutes (default: 1 minute), while the queries under

  • asm (detailed)
  • tablespaces
  • tablespaces (detailed)
  • Blocked sessions
  • TopN

run every heavy-query-interval minutes (default: 5 minutes).

For older versions, most queries run every minute, with exceptions for the heavy queries mentioned above, which run every 5 minutes.

How do I adjust query timeout?

By default, the extension's monitoring queries time out after 10 seconds. For queries in the following feature sets, the long-running-query-timeout variable lets you specify a custom timeout in seconds:

  • asm (detailed)
  • tablespaces
  • tablespaces (detailed)
  • TopN
What is the difference between Feature set and Feature set (detailed)

The following feature sets have both regular and detailed versions. These can be enabled or disabled in accordance to your specific use-case:

  • asm and asm (detailed)
    • Due to the high license consumption associated with monitoring thousands of ASM disks, the asm feature set captures only ASM disk group data, while the asm (detailed) feature set captures data for all disks. Both feature sets can be enabled at the same time.
  • waitEvents and waitEvents (detailed)
    • To control license consumption, the waitEvents feature set collects wait time metrics aggregated by wait class, while the waitEvents (detailed) feature set collects metrics for the top 20 wait events.
  • tablespaces and tablespaces (detailed)
    • Due to the high CPU consumption caused by joining tablespace metrics with datafile data, the tablespaces feature set does not collect the com.dynatrace.extension.sql-oracle.tablespaces.allocatedSpace metric coming from CDB_DATA_FILES (which tablespaces (detailed) does). Furthermore, the tablespaces feature set only collects data for tablespaces with more than 50% used space (as reported by CDB_TABLESPACE_USAGE_METRICS), while the tablespaces (detailed) feature set collects metrics for all tablespaces. Only one of these feature sets should be enabled at any given time.
Why am I missing Data Guard metrics?

For some of the Data Guard metrics, not seeing any data is the correct behavior and it means the Data Guard deployment is working as expected. The following metrics show data points only when there are issues that need further investigation:

  • NOLOGGING activity records a metric data point when operations against the database generate no redo log records. This requires investigation because from a Data Guard perspective the mechanism is completely bypassed when such activity occurs, leaving the standby vulnerable until these files are manually refreshed.
  • Data Guard severe events records a metric data point when Data Guard reports a fatal or severe event. The metric dimensions carry the event message or description for further investigation on the database instance.
  • Archive destination status records a metric data point when the database's archive destinations report an Invalid or Error status. The metric dimensions show a description of the status and identify the archive destination that reported the error.
Why am I missing CPU usage metrics?

The extension collects the com.dynatrace.extension.sql-oracle.cpu.backgroundTotal and com.dynatrace.extension.sql-oracle.cpu.foregroundTotal metrics from the GV$METRIC view, filtered by metric group System Metrics Long Duration (Group ID 2). Since this group is only populated at the CDB level, these metrics are available only when the extension connects to the CDB, not the PDB.

If you are missing these two metrics, double-check your connection configuration and ensure that the extension configuration is pointing to the CDB.

Why are the tablespace usage metrics reported by Dynatrace different to what I am used to seeing?

While some administrators monitor tablespace usage by manually reviewing datafiles, Dynatrace derives all tablespace metrics (com.dynatrace.extension.sql-oracle.tablespaces.*) from the DBA_TABLESPACE_USAGE_METRICS view, which provides Oracle's own calculations on tablespaces' maximum and used space. The values for maximum space (and therefore used space %) can differ significantly from the datafile approach, as this view accounts for both underlying storage capacity and auto-extend settings. To learn how these metrics are calculated, see Oracle's table usage metrics.

Why do I see duplicate entities?

When monitoring RAC setups, the extension automatically discovers nodes from the GV$ views. Configure monitoring only for the cluster listener, not for each individual node. If you see duplicate clusters or nodes, verify that the extension connects to the cluster listener, not to each individual node.

Also, confirm that the extension is configured to connect to the CDB, and not the individual PDBs.

Why am I not seeing my databases?

If there is no data for a database at all, a connection problem between the ActiveGate and the database server is the most likely cause.

  • First, verify that the connection details (hostname/IP, port, service name/SID) are correct and that the monitoring user has permission to establish a session.

  • Next, confirm that a connection can be established from the ActiveGate to the database server, and that no firewalls are blocking it. Use the Dynatrace DB connection check tool to verify that the ActiveGate can establish a JDBC connection.

If data is missing for a specific metric or set of metrics, the monitoring user may be missing required permissions. Verify that the user has all permissions listed on the Hub tile. Check the ActiveGate logs for errors during query execution.

In some cases, a missing metric indicates a misconfiguration (CDB vs. PDB, for example). Some metrics are only available at the CDB level. Verify that the extension is configured to connect to the CDB.

Where do I look for diagnostic logs?

Detailed error messages are in the ActiveGate logs directory on the server.

Troubleshooting

Related tags
DatabaseSQLSQLOracleApplication Observability