Oracle

Prerequisites

Oracle 19c or 21c
User permissions that grant access to Turbonomic through a specific user account

See Creating a Service User Account in Oracle.
Dynamic Performance View (V$) must be enabled

For more information, see Adding a Dynamic Performance View.
Access through the firewall to the Oracle database port that you specify for the Turbonomic target connection

Adding a dynamic performance view

In order to collect data from the Oracle database, Turbonomic uses the Dynamic Performance View (referred to as V$). V$ is not enabled by default. You must run a script to build the tables and views that are necessary to enable V$. In some environments only the DBA has privileges to run this script.

To enable V$:

Open a secure shell session (ssh) on the database host as a system user or a user with the sysdba role
In the shell session enter the following commands:
```
sqlplus /nolog
connect /as sysdba
CREATE USER My_Username IDENTIFIED BY My_Password container=all;
GRANT CONNECT TO My_Username container=all;
GRANT sysdba TO My_Username container=all;
```
Note:
If security or other practices prohibit assigning SYSDBA to this user, you can use the following command to provide access to all V$ views:

GRANT select any dictionary TO My_Username;

This creates a user account named My_Username with full privileges to access the V$ Dynamic Performance view.

Adding an Oracle database to Turbonomic

You can add an individual database server as a target, or you can add all matching targets within a given scope.

Click Settings > Target configuration.
On the Target configuration page, click Add Target.
On the Select target page, click Oracle.
In the side panel, review the connection requirements and then click Connect Target.
On the Connection overview page, configure the following settings:
- Display name
  
  Specify a name that uniquely identifies this connection.
  
  This name is for display purposes only and does not need to match any name in Oracle.
- Username
  
  Specify the username of the account Turbonomic uses to connect to the target.
  
  For Turbonomic to execute actions, the account must have administrator privileges. You must have enabled user permissions to this user account, including remote access from the Turbonomic server.
- Password
  
  Specify the password of the account Turbonomic uses to connect to the target.
- Scope
  
  Specify the scope Turbonomic uses for application discovery.
  
  The scope is a group of virtual machines that contain the databases that are discovered as part of a separate Turbonomic target.
  
  If you set a scope, Turbonomic searches for virtual machines in the selected group.
  
  Turbonomic can monitor up to 500 virtual machines in a group. If you have more than 500 virtual machines in your environment, split them across smaller groups and then add those groups as individual targets.
  
  Note:
  All database servers in the scope must share the same service name, credentials, and port. For databases that have a different value for any of these, you must create a separate target using those values.
- Oracle TCP Port
  
  Specify the port that connects to the database. You must open the firewall on the database server to allow access through this port. By default, the port is 1521.
  
  Any firewall on the database must allow access through this port. To find the port, open an SSH session (as a system or sysdba user) on the database’s host, run lsnrctl status, and then check PROTOCOL=tcp.
- Oracle service name
  
  Specify the service name for the database that you are connecting to Turbonomic.
  
  To find the service name, open an SSH session on the database’s host and run the following commands:
  
  sqlplus /no log
  
  connect /as sysdba
  
  SELECT SYS_CONTEXT ('userenv', 'db_name') FROM dual;
- Authenticate all database servers
  
  If you select this option, Turbonomic attempts to authenticate all database servers in the selected scope. If Turbonomic is unable to authenticate a database server, the target is not added and no data is collected.

Updating Oracle database passwords in bulk

You can update Oracle database passwords in bulk by uploading a CSV file through the Turbonomic user interface (UI). Use this feature to regularly rotate passwords for multiple Oracle targets without having to manually update each target.

The bulk update process uses a CSV file that you generate in the Turbonomic UI, download and edit locally, then upload to Turbonomic. Complete the following steps.

Click Settings > Target configuration.
On the Target configuration page, filter the list of targets to include only your Oracle targets.
1. Click the Filter icon to create a search filter.
2. Click Add criteria, and select the Type filter.
3. Set the value to be Oracle.
4. Click Save and apply to create the filter and filter the list of targets.
Create the CSV file.
1. Click the dropdown menu on the Add Target button and select Download file for bulk update.
2. In the Select target type window, select Oracle and click Next.
3. In the Select scope window, select the Oracle targets that you want to update and click Next.
  
  By default, all Oracle targets are selected.
4. Click Download file (CSV).
Open the CSV file that you downloaded and update the password column with the new password. Save the changes.
Upload the updated CSV file to Turbonomic.
1. On the Target configuration page, click the dropdown menu on the Add Target button and select Upload file for bulk update.
2. Drag the updated file into the Upload file window or select it from your file browser.
  
  If the file is invalid, an error notification appears, along with a window that details the errors that were found. Fix any errors and repeat steps 5a and 5b. When the file passes the validation check, the Submit button is available.
3. Click Submit.
  
  When the upload completes, a notification appears that confirms the passwords were updated.

Monitored resources

Turbonomic monitors the following resources:

Database server
- Database memory (DBMem)
  
  Database memory (or DBMem) is the measurement of memory that is utilized by a Database Server.
  
  Actions to resize database memory are driven by data on the Database Server, which is more accurate than data on the hosting VM.
- Transaction
  
  Transaction is a value that represents the per-second utilization of the transactions that are allocated to a given entity.
- Response time
  
  Response time is the elapsed time between a request and the response to that request. Response time is typically measured in seconds (s) or milliseconds (ms).
- Connection
  
  Connection is the measurement of database connections utilized by applications.
  
  A database connection is a physical communication pathway that holds database sessions, which are logical entities in the database instance memory that represent the state of a current user login to a database. Connections should be managed properly.
- Transaction log
  
  Transaction log is the measurement of storage capacity utilized by a Database Server for transaction logging.
- DB cache hit rate
  
  DB cache hit rate is the measurement of Database Server accesses that result in cache hits, measured as a percentage of hits versus total attempts. A high cache hit rate indicates efficiency.
Virtual machine
- Virtual memory (vMem)
  
  Virtual memory (vMem) is the measurement of memory that is in use.
- Virtual CPU (vCPU)
  
  Virtual CPU is the measurement of CPU that is in use.
- Virtual storage
  
  Virtual storage is the measurement of virtual storage capacity that is in use.
- Storage access (IOPS)
  
  Storage access, also known as IOPS, is the per-second measurement of read and write access operations on a storage entity.
- Latency
  
  Latency is the measurement of storage latency.

Actions

Turbonomic supports the following actions:

Database server

Resize

Actions to resize database memory are driven by data on the Database Server, which is more accurate than data on the hosting VM. Turbonomic uses database memory and cache hit rate data to decide whether resize actions are necessary.

A high cache hit rate value indicates efficiency. The optimal value is 100% for on-prem (self-hosted) Database Servers, and 90% for cloud Database Servers. When the cache hit rate reaches the optimal value, no action generates even if database memory utilization is high. If utilization is low, a resize down action generates.

When the cache hit rate is less than the optimal value but database memory utilization remains low, no action generates. If utilization is high, a resize up action generates.
Virtual machine

Resize

Resize resource capacity, reservation, or limit to improve performance.