Overview
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.
Oracle DB monitoring extension supports the client-side DB utilization by providing server-side observability starting with availability and performance statistics, down to individual SQL statements and log insights.
Use cases
- 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
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.
Compatibility information
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
Log Management and Analytics
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