Dynatrace automatically detects all applications and microservices deployed in your system and how your system uses Oracle Database. This extension provides automatic end-to-end tracing down to individual SQL statements, Oracle Server metrics, and log insights. 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.

• Understand all database dependencies of your applications, which database statements are executed, 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 DB audit logs to spot invalid login attempts
• Track the health and performance of Oracle Database servers (either standalone or multi-tenant)
• Track the most time consuming queries performance
• Speed up application-problem diagnosis when issues are caused by the database

Get started for Oracle Database clients:

If the application that connects to the Oracle Database server runs on a virtual machine or bare-metal, install OneAgent on it 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.

Activate the following OneAgent features to get full tracing insight:

• Node.js Oracle DB
• PHP Oracle

Get started with Oracle Database servers:

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

Activate the remote Oracle Database extension to get full insight into the Oracle Database server's health and performance combined with metrics and events. A dedicated user account is recommended for monitoring, with either:

• CREATE_SESSION
• SELECT_CATALOG_ROLE

roles granted, or set of SELECT permissions on the following performance views:

• V$ASM_Disk_Stat
• V$Database
• V$Instance
• V$LibraryCache
• V$Metric
• V$MetricGroup
• V$Parameter
• V$PDBs
• V$PGAStat
• V$RMAN_Backup_Job_Details
• V$Services
• V$Session
• V$SGAStat
• V$SQLArea
• V$SysStat
• V$System_Event
• V$System_Wait_Class
• V$Sys_Time_Model
• V$Tablespace
• DBA_Data_Files
• DBA_Free_Space
• DBA_Lmt_Free_Space
• DBA_Tablespaces
• DBA_Temp_Free_Space

Depending on the level of detail, additional privileges might be required, such as SYSDBA or SYSASM privileges, to view certain ASM statistics. These privileges are typically granted by an ASM administrator.

Activate log monitoring to get full log insight.

Note:
Enabling Most time consuming queries’ performance may expose sensitive data in reported queries.

The extension supports following Oracle versions:

• Oracle standalone servers
• Oracle Multitenant (CDB/PDB)
• Only monitoring of instances and PDB is supported. CDB monitoring is not in scope of this extension
• Oracle DB 12.2+
• Oracle AWS RDS

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 in the file.

• SELECT value FROM v$parameter WHERE name = 'audit_file_dest';

specifies the log file's location

Add LogAgent security rules

Configure LogAgent's security rules to allow access to local files, by adding the oracle.json file under :

• 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"
        }
    ]
}

Agent restart is not required, this config will be 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, e.g. /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:

• 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: e.g.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