})
The Oracle app is a unified logs and metrics app that helps you monitor Oracle database cluster availability, performance, and resource utilization. Preconfigured dashboards and searches provide insight into the health of your database clusters, parallel executions, resource utilization, response time, tablespaces, throughput, wait for class/events, listeners, audit logs, and security.
This app is tested with the following Oracle versions:
* Non-Kubernetes: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production - Version 19.3.0.0.0
* Kubernetes: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production - Version 19.3.0.0.0
## Log types
* Alert Logs
* Listener Logs
* Audit Logs
## Collect Logs and Metrics for the Oracle app
This section provides instructions for configuring logs and metrics collection for the Sumo Logic app for the Oracle.
### Configure Oracle Logs and Metrics Collection
Sumo Logic supports the collection of logs and metrics data from Oracle in both Kubernetes and non-Kubernetes environments.
Click on the appropriate links based on the environment where your Oracle clusters are hosted.
})
The first service in the metrics pipeline is Telegraf. Telegraf collects metrics from Oracle. Note that we’re running Telegraf in each pod we want to collect metrics from as a sidecar deployment: i.e. Telegraf runs in the same pod as the containers it monitors. Telegraf uses the [exec input plugin](https://github.com/influxdata/telegraf/tree/master/plugins/inputs/exec) to obtain metrics. (For simplicity, the diagram doesn’t show the input plugins.) The injection of the Telegraf sidecar container is done by the Telegraf Operator.
Prometheus pulls metrics from Telegraf and sends them to [Sumo Logic Distribution for OpenTelemetry Collector](https://github.com/SumoLogic/sumologic-otel-collector) which enriches metadata and sends metrics to Sumo Logic.
In the logs pipeline, Sumo Logic Distribution for OpenTelemetry Collector collects logs written to standard out and forwards them to another instance of Sumo Logic Distribution for OpenTelemetry Collector, which enriches metadata and sends logs to Sumo Logic.
:::note Prerequisites
It’s assumed that you are using the latest helm chart version. If not, upgrade using the instructions [here](/docs/send-data/kubernetes).
:::
#### Configure Metrics Collection
This section explains how to collect Oracle metrics from a Kubernetes environment.
In Kubernetes environments, we use the Telegraf Operator, which is packaged with our Kubernetes collection. You can learn more about this[ here](/docs/send-data/collect-from-other-data-sources/collect-metrics-telegraf/telegraf-collection-architecture). Follow the steps listed below to collect metrics from a Kubernetes environment:
**Step 1. Configure Oracle pod to send metrics to Sumo Logic**
We use custom Python script which sends Oracle metrics into Sumo Logic as mentioned [here](https://github.com/SumoLogic/sumologic-integrations/tree/main/Oracle#step-4-create-a-script-to-gather-oracle-rdbms-metrics). There are two methods to execute the script in pod:
1. Use [Config Map to execute the script.](https://github.com/kubernetes/kubernetes/issues/71356#issuecomment-441169334)
2. Modify existing dockerfile and update the Pod definition:
```bash
FROM python:3.7
RUN pip install cx_Oracle
# Install Oracle Client
ENV ORACLE_HOME=/opt/oracle
ENV LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib
RUN wget https://dl.influxdata.com/telegraf/r....4-1_amd64.deb \
&& dpkg -i telegraf_1.20.4-1_amd64.deb
RUN apt-get update && apt-get install -y libaio1 && rm -rf /var/lib/apt/lists/* \
&& wget -q https://download.oracle.com/otn_soft....0.0.0dbru.zip \
&& unzip instantclient-*.zip \
&& mkdir -p $ORACLE_HOME \
&& mv instantclient_19_6 $ORACLE_HOME/lib \
&& rm -f instantclient-*.zip
COPY sumo_oracle_metrics.py /app/
COPY exec_oracle_metrics.sh /app/
RUN chmod +x entrypoint.sh && chmod +x /tmp/exec_oracle_metrics.sh
CMD ["telegraf"]
```
**Step 2. [Setup Kubernetes Collection with the Telegraf Operator.](/docs/send-data/collect-from-other-data-sources/collect-metrics-telegraf/install-telegraf)**
**Step 3. Add annotations on your Oracle pods**
On your Oracle Pods, add the following annotations:
```sql
annotations:
telegraf.influxdata.com/class: sumologic-prometheus
prometheus.io/scrape: "true"
prometheus.io/port: "9273"
telegraf.influxdata.com/inputs: |+
[[inputs.exec]]
commands = ["/path_TO_BE_CHANGEME/exec_oracle_metrics.sh"]
timeout = "5s"
data_format = "influx"
[inputs.exec.tags]
environment ="dev_ENV_TO_BE_CHANGED"
component ="database"
db_system ="oracle"
db_cluster ="oracle_on_premise_ENV_TO_BE_CHANGED"
db_cluster_address = "ENV_TO_BE_CHANGED"
db_cluster_port = "ENV_TO_BE_CHANGED"
```
* If you haven’t defined a cluster in Oracle, enter `default` for `db_cluster`.
* Enter values for the parameters marked `ENV_TO_BE_CHANGED` in the snippet above:
* `telegraf.influxdata.com/inputs`. This contains the required configuration for the Telegraf exec Input plugin. Please refer[ to this doc](https://github.com/influxdata/telegraf/tree/master/plugins/inputs/redis) for more information on configuring the Oracle input plugin for Telegraf. Note: As telegraf will be run as a sidecar the host should always be localhost.
* In the input plugins section:
* **commands** - The [exec](https://github.com/influxdata/telegraf/tree/master/plugins/inputs/exec) plugin executes all the commands in parallel on every interval and parses metrics from their output in any one of the accepted [Input Data Formats](https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_INPUT.md).
* In the tags section `[inputs.exec.tags]`:
* `environment`. This is the deployment environment where the Oracle cluster identified by the value of **servers** resides. For example: dev, prod or qa. While this value is optional we highly recommend setting it.
* `db_cluster`. Enter a name to identify this Oracle cluster. This cluster name will be shown in the Sumo Logic dashboards.
* `db_cluster_address`. Enter the cluster hostname or ip address that is used by the application to connect to the database. It could also be the load balancer or proxy endpoint.
* `db_cluster_port`. Enter the database port. If not provided, a default port will be used.
:::note
`db_cluster_address` and `db_cluster_port` should reflect exact configuration of DB client configuration in your application, especially if you instrument it with OT tracing. The values of these fields should match exactly the connection string used by the database client (reported as values for net.peer.name and net.peer.port metadata fields).
For example, if your application uses `“oracle-prod.sumologic.com:3306”` as the connection string, the field values should be set as follows: `db_cluster_address=oracle-prod.sumologic.com db_cluster_port=3306`
If your application connects directly to a given oracle node, rather than the whole cluster, use the application connection string to override the value of the “host” field in the Telegraf configuration: `host=oracle-prod.sumologic.com`
Pivoting to Tracing data from Entity Inspector is possible only for “Oracle address” Entities.
:::
* **Do not modify the following values** as it will cause the Sumo Logic apps to not function correctly:
* `telegraf.influxdata.com/class: sumologic-prometheus`. This instructs the Telegraf operator what output to use. This should not be changed.
* `prometheus.io/scrape: "true"`. This ensures our Prometheus will scrape the metrics.
* `prometheus.io/port: "9273"`. This tells prometheus what ports to scrape on. This should not be changed.
* `telegraf.influxdata.com/inputs`
* In the tags section [inputs.exec.tags]:
* `component: “database”` - This value is used by Sumo Logic apps to identify application components.
* `db_system: “oracle”` - This value identifies the database system.
* For all other parameters, see [this doc](/docs/send-data/collect-from-other-data-sources/collect-metrics-telegraf/install-telegraf#configuring-telegraf) for more parameters that can be configured in the Telegraf agent globally.
Sumo Logic Kubernetes collection will automatically start collecting metrics from the pods having the labels and annotations defined in the previous step.
Verify metrics in Sumo Logic.
#### Configure Logs Collection
This section explains the steps to collect Oracle logs from a Kubernetes environment.
1. **(Recommended Method) Add labels on your Oracle pods to capture logs from standard output**. Make sure that the logs from Oracle are sent to stdout. Follow the instructions below to capture Oracle logs from stdout on Kubernetes.
1. Apply following labels to the Oracle pod:
```bash
labels:
environment: "prod_ENV_TO_BE_CHANGED"
component: "database"
db_system: "oracle"
db_cluster "Cluster_ENV_TO_BE_CHANGED"
db_cluster_address = "ENV_TO_BE_CHANGED"
db_cluster_port = "ENV_TO_BE_CHANGED"
```
Enter in values for the following parameters (marked in **ENV_TO_BE_CHANGED** above):
* `environment`. This is the deployment environment where the Oracle cluster identified by the value of **servers** resides. For example:- dev, prod, or QA. While this value is optional we highly recommend setting it.
* `db_cluster`. Enter a name to identify this Oracle cluster. This cluster name will be shown in the Sumo Logic dashboards. If you haven’t defined a cluster in Oracle, then enter ‘**default**’ for `db_cluster`.
* `db_cluster_address` - Enter the cluster hostname or ip address that is used by the application to connect to the database. It could also be the load balancer or proxy endpoint.
* `db_cluster_port` - Enter the database port. If not provided, a default port will be used.
:::note
`db_cluster_address` and `db_cluster_port` should reflect the exact configuration of DB client configuration in your application, especially if you instrument it with OT tracing. The values of these fields should match exactly the connection string used by the database client (reported as values for net.peer.name and net.peer.port metadata fields).
For example, if your application uses `“oracle-prod.sumologic.com:3306”` as the connection string, the field values should be set as follows: `db_cluster_address=oracle-prod.sumologic.com db_cluster_port=3306`
If your application connects directly to a given oracle node, rather than the whole cluster, use the application connection string to override the value of the “host” field in the Telegraf configuration: `host=oracle-prod.sumologic.com`
Pivoting to Tracing data from Entity Inspector is possible only for “Oracle address” Entities.
:::
**Do not modify** the following values as they will cause the Sumo Logic apps to not function correctly.
* `component: “database”` - This value is used by Sumo Logic apps to identify application components.
* `db_system: “oracle”` - This value identifies the database system.
For all other parameters, see [this doc](/docs/send-data/collect-from-other-data-sources/collect-metrics-telegraf/install-telegraf#configuring-telegraf) for more parameters that can be configured in the Telegraf agent globally.
1. The Sumologic-Kubernetes-Collection will automatically capture the logs from stdout and will send the logs to Sumologic. For more information on deploying Sumologic-Kubernetes-Collection, [visit](/docs/integrations/containers-orchestration/kubernetes#collecting-metrics-and-logs-for-the-kubernetes-app) here.
1. Verify logs in Sumo Logic.
1. **(Optional) Collecting Oracle Logs from a Log File**. Follow the steps below to capture Oracle logs from a log file on Kubernetes.
1. Determine the location of the Oracle log file on Kubernetes. This can be determined from the Oracle.conf for your Oracle cluster along with the mounts on the Oracle pods.
1. Install the Sumo Logic [tailing sidecar operator](https://github.com/SumoLogic/tailing-sidecar/tree/main/operator#deploy-tailing-sidecar-operator).
1. Add the following annotation in addition to the existing annotations.
```sql
annotations:
tailing-sidecar: sidecarconfig;**FER to normalize the fields in Kubernetes environments.** Labels created in Kubernetes environments automatically are prefixed with pod_labels. To normalize these for our app to work, a Field Extraction Rule named **AppObservabilityOracleDatabaseFER** is automatically created for Database Application Components.
})
The process to set up collection for Oracle data is done through the following steps:
1. Configure Logs Collection
1. Enable Oracle Logging
2. Verify Log Files Path.
3. Configure three Local log file Sources.
4. Set Up Oracle Performance Metrics Script
2. Configure Metrics Collection
1. Configure a Hosted Collector
2. Configure an HTTP Logs and Metrics Source
3. Install Telegraf
4. Configure, and start Telegraf
#### Configure Logs Collection
This section provides instructions for configuring log collection for Oracle running on a non-Kubernetes environment.
**Step 1. Enable Oracle Logging**
If logging is not currently enabled for the following logs, enable it.
* **Alert log**
* **Listener log**.
* Enable Listener Log: The basic syntax of Listener Control utility commands is as follows
```bash
lsnrctl command [listener_name]
lsnrctl set log_status on
```
* **Audit Log**. Follow [this](https://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm#TDPSG50000) guide to enable Audit Logs.
**Step 2. Verify Local logs file directories and Path**
* **Oracle Alert Logs**. For 11g and later releases (12c, 18c, 19c): By default, Oracle logs are stored in `$ORACLE_BASE/diag/rdbms/$DB_UNIQUE_NAME/$ORACLE_SID/trace/`.
* The default directory for log files is value of `BACKGROUND_DUMP_DEST`. you can query the value of `BACKGROUND_DUMP_DEST`, an initialization parameter, where you can find Oracle alert log
```
SQL> show parameter background_dump_dest;
```
* **Oracle Listener Logs**. You can check listener log file with command:
```bash
[oracle@sumolab alert]$ lsnrctl status
```
* **Oracle Audit Logs**. By default, Oracle logs are stored in `$ORACLE_BASE/app/oracle/admin/orcl/adump`. The default directory for log files is value of `audit_file_dest`. you can query the value of `audit_file_dest`, an initialization parameter, where you can find the Oracle Audit log directory
```
SQL> show parameter audit
```
Audit Logs should be in either `XML, EXTENDED` or `{{OS }}` for app to work.
**Step 3. Configure three Local File Sources**
In this step, you will configure three Local File sources on an installed collector, one for each of the following Oracle logs: Alert, Listener, and Audit.
Follow the instructions in [Local File Source](/docs/send-data/installed-collectors/sources/local-file-source).
When you configure the sources, plan your source categories to ease the querying process. A hierarchical approach allows you to make use of wildcards. For example:
| Source | Example Source Category |
|:---|:---|
| Alert Logs | DB/Oracle/Alert |
| Listener Logs | DB/Oracle/Listener |
| Audit | DB/Oracle/Audit |
Add Following **Fields** on each Local File Source:
* **Fields**. Set the following fields:
* `component = database`.
* `db_system = oracle`.
* `db_cluster = })
**DB Connections**. The count of database connections established during the previous 24 hours.
**TNS Errors**. The count of TNS errors during the previous 24 hours.
**Top TNS Errors**. A table that shows the top 10 TNS errors and the count of each in the previous 24 hours.
**TNS Error Trend**. A stacked column chart that shows the count of each TNS error per one hour timeslice, over the previous 24 hours.
**SID**. A donut chart that shows the breakdown of connections by SID over the previous 24 hours.
**Service Name**. A donut chart that shows the breakdown of connections by service name over the previous 24 hours.
**Service Name Vs SID Adoption**. A donut chart that shows the breakdown of connections by SID versus by Service Name over the previous 24 hours.
**Protocol Used**. A donut chart that shows the breakdown of connection requests by protocol over the previous 24 hours.
**Command Execution Status**. A donut chart that shows the breakdown of successful and failed Listener commands over the previous 24 hours.
**Commands Executed**. A donut chart that shows the breakdown of specific lsnrctl commands over the previous 24 hours.
**Top Ports Used by Client**. A table that shows the top 20 client ports that initiated connections, and connection count for each over the previous 24 hours.
**Top Database Users**. A table that shows the top 20 database users for which the client initiated connections, and connection count for each over the previous 24 hours.
**Most Active User Hosts**. A table that shows the top 20 user hosts that initiated connections, and connection count for each over the previous 24 hours.
**Top Client Hosts for __jdbc__**. A table that shows connections initiated from Client Host by appserver using the JDBC Thin Client (host name __jdbc__) and the connection count for each over the previous 24 hours.
**Top User Program Name**. A table that shows the top 20 programs that initiated connections over the previous 24 hours.
### Alert Analysis
See information about Oracle errors, including counts of various error types, ORA messages, oracle instance state, and other data derived from the Oracle Alert log.
})
**Deadlock Errors**. Count of ORA-00060 messages over the previous 24 hours.
**Database Crash Errors**. Count of database crash errors (ORA-00603, ORA-00449, ORA-00471, or ORA-01092) over the previous 24 hours.
**Archival Log Creation Errors**. Count of ORA-00270 messages over the previous 24 hours.
**Internal Errors**. Count of internal errors (ORA-00600 or ORA-07445) over the previous 24 hours.
**Fatal NI Connect Errors**. Count fatal NI connect errors over the previous 24 hours.
**Top ORA Messages**. A donut chart that shows the breakdown of ORA messages by message type over the previous 24 hours.
**ORA Messages Over Time**. A stacked column chart that shows the count of ORA messages of each message type per one hour timeslice over the previous 24 hours.
**Hosts Reporting ORA Messages**. A stacked column chart that shows the count of ORA messages of all types by host per one hour timeslice over the previous 24 hours.
**Top TNS Errors**. A table that shows the count of Transparent Network Substrate (TNS) errors of each type over the previous 24 hours.
**Log Switch Activity By Hosts**. An area chart that shows the count of log switch events per one hour timeslice by host. (A log switch is the point at which the database stops writing to one redo log file and begins writing to another.)
**Failures, Warnings and Errors by Instance Source**. An area chart that shows the count of messages from the Oracle Alert log that match patterns like: `fail*`, `warn*`, or `error*`.
**Archival Errors by Instance**. A stacked column chart that shows the count of messages from the Oracle Alert log that contain the string “Archival Error" by per one hour timeslice by database instance over the previous 24 hours.
**Unable to Extend Tablespace Errors**. A table that lists errors related to a failure to extend a tablespace, that occurred during the previous 24 hours.
**Instance Started**. A table that lists when database instances were started during the previous three days.
**Instance Shutdown Initiated**. A table that lists when shutdowns of database instances were initiated during the previous three days.
**Instance Shutdown Complete**. A table that lists when shutdowns of database instances were initiated during the previous three days.
### Listener Troubleshooting
See details of Oracle listener process activity, including database connections by host and application, connection failures, command execution status and trends, and other data derived from the Oracle Listener log.
})
**DB Connections By Host**. An area chart that shows the count of database connections by host, per 5 minute timeslice, over the previous 24 hours.
**DB Connections By Applications**. A stacked column chart that shows the count of database connection by initiating program, per one day timeslice, over the previous 7 days.
**Failed to Success Connection Ratio - Outlier**. A visualization that shows when the ratio of failed to successful connections was statistically significant (more than three standard deviations higher than the running average), over the previous 30 days.
**Failed Connection Attempts**. A table that lists failed database connection attempts over the previous three days.
**Command Execution Status**. A table that lists the count of specific lsnrctl commands that were issued in the previous seven days, and the count of failures and successes for each.
**Command Execution Trend**. A stacked column chart that shows the count of specific lsnrctl commands that were issued in the previous seven days per one day timeslice.
**Listener Stopped Events**. A table that lists listener stop events during the previous 7 days.
**SID or Service Name Detailed Breakup**. A table that shows the count of connections performed with sid or service name, by userhost, clienthost, and databaseuser.
### Security Monitoring
See information about database connections established by privileged users, connection attempts from public IP addresses, attempts to execute unauthorized commands, and events that associated with potentially inappropriate activities as derived from Oracle Listener and Alert Logs.
})
**Admin Restricted Command Execution**. The count of database commands that resulted in TNS-12508 errors over the previous 24 hours.
**Unauthorized Command Execution**. The count of database commands that resulted in TNS-01190 errors over the previous 24 hours.
**Possible InAppropriate Activity**. The count of lsnrctl commands the resulted in errors of the following types over the previous 24 hours: TNS-01169, TNS-01189, TNS-01190, "TNS-12508", ORA-12525, ORA-28040, or ORA-12170.
**Connections By Privileged Users**. A donut chart that shows the breakdown of connections from privileged user accounts, such as root and administrator, over the previous 24 hours.
**Connection Status by Privileged User**s. A table that shows the count of successful and unsuccessful connections from privileged user accounts, such as root and administrator, over the previous 24 hours.
**Connections By Privileged Users - Trend**. A line chart that shows the count of connections from privileged user accounts, such as root and administrator, per one hour timeslice over over the previous 24 hours.
**Recent Successful DB Connections by Privileged Users**. A table that shows the count of successful connections from privileged user accounts, such as root and administrator, per one minute timeslice, over the previous 24 hours.
**Failed Connection Attempt From PublicIP Location**. A map chart that shows the count and location of failed connection attempts from geographical locations over the previous 24 hours.
**Successful Connection Attempt From PublicIP Location**. A map chart that shows the count and location of successful connection attempts from geographical locations over the previous 24 hours.
**Failed DB Connections by Privileged Users**. A table that provides information about failed database connections from privileged user accounts, such as root and administrator, over the previous 24 hours.
### Sys Audit Log
See information derived from the syslog audit trail, including successful and failed activities, and top usage by client, database user, and privileges used.
})
**Status Trend**. A stacked column chart that shows the count of successful and unsuccessful database actions over the previous 24 hours.
**Failure Status Trend**. A stacked column chart that shows the count of unsuccessful database actions by failure status code over the previous 24 hours.
**Recent Failure Activities**. A table that lists unsuccessful database actions over the previous 60 minutes.
**Top Client Users**. A table that shows the top 10 client users over the previous 24 hours, and a count of the events associated with each.
**Top Database Users**. A table that shows the top 10 database users over the previous 24 hours, and a count of the events associated with each.
**Top Privileges Used**. A table that shows the top 10 database privileges used over the previous 24 hours, and a count of the events associated with each.
**Recent Successful Activities**. A table that lists information about successful database actions over the previous 60 minutes.
### Sys Audit Log - Logon Analysis
See logon activity information derived from the syslog audit trail, including successful and failed logons, logon status trends, multiple database user logons and client user logons from the same UserHost, and multiple UserHost logons with the same database user.
})
**Successful Logons**. Count of successful logins in the previous 24 hours.
**Failed Logons**. Count of failed logins in the previous 24 hours.
**Successful Logoffs**. Count of successful logoffs in the previous 24 hours.
**Logon Activities Trend**. Stacked column chart that shows the count of logons and logoffs per one hour timeslice over the previous 24 hours.
**Brute Force Login Success**. Table that lists information about brute force login attempts that succeeded during the previous three days.
**Excessive Failed Logons**. A table that lists information about incidents where there were more than five failed logons within 5 minutes during last three days.
**Multiple Database User Logons From Same UserHost**. A table that lists UserHosts that successfully established connections using more than one database user over the previous 24 hours.
**Multiple Client User Logons From Same UserHost**. A table that lists UserHosts that successfully established connections using more than one client user over the previous 24 hours.
**Multiple UserHosts Logons with Same Database User**. A table that lists database users that successfully established connections from the multiple user hosts over the previous 24 hours.
### XML Audit Log - Logon Analysis
See logon activity information derived from the XML audit trail, including successful and failed logons, logon status trends, multiple database user logons and client user logons from the same UserHost, and multiple UserHost logons with the same database user.
})
### XML Audit Log - SQL Statement Analysis
See information derived from the XML audit trail about user management, role management, Data Definition Language (DDL), Data Manipulation Language (DML), and Transaction Control Language (TCL) activity.
})
**Recent User Management Activities**. A table that lists information about user management activities in the previous 24 hours.
**User Management Activity Trend**. A stacked column chart that shows the count of user management actions by action type per one hour timeslice over the last 7 days.
**Recent Role Management Activities**. A table that lists information about role management activities in the previous 24 hours.
**Role Management Activity Trend**. A stacked column chart that shows the count of role management actions by action type per one hour timeslice over the last 7 days.
**Recent DDL Activities**. A table that lists information about Data Definition Language (DDL) activities in the previous 24 hours.
**DDL Activity Trend**. A stacked column chart that shows the count of DDL actions by action type per one hour timeslice over the last 7 days.
**Recent DML Activities**. A table that lists information about Data Manipulation Language (DML) activities in the previous 24 hours.
**DML Activity Trend**. **DDL Activity Trend**. A stacked column chart that shows the count of DML actions by action type per one hour timeslice over the last 7 days.
**Recent TCL Activities**. A table that lists information Transaction Control Language (TCL) activities in the previous 24 hours.
**TCL Activity Trend**. A stacked column chart that shows the count of DML actions by action type per one hour timeslice over the last 7 days.
### Monitor Performance by DB Script
See database usage information obtained by the Oracle script source, including tablespace and datafile utilization; recent active connections; wait times; and recent jobs.
})
**TableSpace Utilization**. A table that shows, for each tablespace, the percentage of tablespace used for each 5 minute timeslice over the last 60 minutes.
**TableSpace Utilization Trend**. A line chart that shows, for each tablespace, the percentage of tablespace used over the last 24 hours.
**Datafile Space Utilization**. A table that shows, for each database file (.dbf), the percentage of allocated file space used for each 5 minute timeslice over the last 60 minutes.
**Datafile Space Utilization Trend**. A line chart that shows, for each database file (.dbf), the percentage of allocated file space used over the last 24 hours.
**Buffer Cache Hit Ratio**. An area chart that shows the buffer cache hit ratio for each 5 minute timeslice over the last 60 minutes.
**Recent Active Connections**. A table of information about recent active connections, including the user, machine, and number of connections.
**Maximum Wait Time (sec) by User**. A line chart that shows, for each user, the session wait times for each 5 minute timeslice over the last 60 minutes.
**Top Session Wait Time Events**. A table that shows the top 10 event types associated with session waits, and the count of each event type.
**Recent Jobs in the database**. A table of information about recent database jobs, including when each job ran, low long it ran, and when it will next run.
### Wait Events
Every wait event belongs to a class of wait events. The following list describes each of the wait classes.
})
### Wait Class
All the wait events are grouped under wait classes and here are the most important wait classes you must know: Administrative, Application, Commit, Concurrency, Configuration, Idle, Network, Other, System I/O, User I/O.
})
### Throughput
The **Oracle - Throughput** dashboard provides an at-a-glance view of the state of system loads in clusters: Logon, Transaction, and Redo.
})
### Tablespaces
The Oracle - Tablespaces dashboard provides an at-a-glance view of the tablespaces in clusters: Percent Used, Max size, Size Used, and Free.
})
### System Global Area
The Oracle - System Global Area dashboard provides an at-a-glance view of a group of shared memory structures, known as SGA components, that contain data and control information for one Oracle Database instance.
})
### Response Time
The Oracle - Response dashboard performance statistics such as database CPU Time, Wait Time Ratio, Response time, Soft Parse Radio, and Execute
})
### Resource Utilization
The Oracle - Resource Utilization dashboard performance statistics such as Limit, OS load, CPU, Cursors, PGA, Physical, I/O and VM
})
### Parallel Execution
The **Oracle - Parallel Execution** dashboard performance statistics such as Sessions, DDL statements parallelized, PX downgraded, Background services
})
## Create monitors for Oracle app
import CreateMonitors from '../../reuse/apps/create-monitors.md';