Database Monitoring provides deep visibility into your Oracle databases by exposing query samples to profile your different workloads and diagnose issues.
The Agent collects telemetry directly from the database by logging in as a read-only user.
The default Agent configuration for Database Monitoring is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.
Database Monitoring runs as an integration on top of the base Agent (see benchmarks).
Proxies, load balancers, and connection poolers
The Agent must connect directly to the host being monitored. The Agent should not connect to the database through a proxy, load balancer, or connection pooler. Each Agent must have knowledge of the underlying hostname and should stick to a single host for its lifetime, even in cases of failover. If the Datadog Agent connects to different hosts while it is running, the values of metrics will be incorrect.
Data security considerations
See Sensitive information for information about what data the Agent collects from your databases and how to ensure it is secure.
Store your password using secret management software such as Vault. You can then reference this password as ENC[<SECRET_NAME>] in your Agent configuration files: for example, ENC[datadog_user_database_password]. See Secrets Management for more information.
The examples on this page use datadog_user_database_password to refer to the name of the secret where your password is stored. It is possible to reference your password in plain text, but this is not recommended.
You must configure the Agent for each Real Application Cluster (RAC) node, because the Agent collects information from every node separately by querying V$ views. The Agent doesn’t query any GV$ views to avoid generating interconnect traffic. The collected data from each RAC node is aggregated in the frontend.
init_config:instances:- server:'<RAC_NODE_1>:<PORT>'service_name:"<CDB_SERVICE_NAME>"# The Oracle CDB service nameusername:'c##datadog'password:'ENC[datadog_user_database_password]'dbm:truetags:# Optional- rac_cluster:<CLUSTER_NAME>- 'service:<CUSTOM_SERVICE>'- 'env:<CUSTOM_ENV>'- server:'<RAC_NODE_2>:<PORT>'service_name:"<CDB_SERVICE_NAME>"# The Oracle CDB service nameusername:'c##datadog'password:'ENC[datadog_user_database_password]'dbm:truetags:# Optional- rac_cluster:<CLUSTER_NAME>- 'service:<CUSTOM_SERVICE>'- 'env:<CUSTOM_ENV>'
The Agent connects only to CDB. It queries the information about PDBs while connected to CDB. Don’t create connections to individual PDBs.
Set the rac_cluster configuration parameter to the name of your RAC cluster or some user friendly alias. The rac_cluster filter helps you select all RAC nodes in the DBM Oracle Database Overview dashboard. You can set an additional filter for the database of interest.
On the Integrations page in Datadog, install the Oracle integration for your organization. This installs an Oracle dashboard in your account that can be used to monitor the performance of your Oracle databases.
For an existing installation, verify that your configuration is located in the conf.d/oracle-dbm.d/ directory. You may need to migrate the legacy configuration from the conf.d/oracle.d/ directory.
Use the following command to migrate the Oracle integration from the legacy integration to the new one:
Deactivating the legacy integration prevents sending the system metrics twice.
Since the Agent doesn’t require an external Oracle client, remove the jdbc_driver_path configuration parameter from the new parameter file /etc/datadog-agent/conf.d/oracle-dbm.d/conf.yaml.
