Setup Prerequisite Policies for Operations Insights

Setup and Manage Policies for Operations Insights Services

With Policy Advisor you can grant and modify the necessary policies for specific telemetry type and resource types that need to be analyzed with Operations Insights from your environment, both for the user group which will be performing this action and for the service itself.

Create Administrator Policies

1. Log into the Console as your tenancy administrator, Open the navigation menu and under Governance and Administration, go to Identity and click Policies.
2. Use the create a policy instructions and give the policy a meaningful name. For example, opsi-admin-policy.
3. Add the following policy statement to allow the group to enable/disable Operations Insights or, to create/enable/disable a Management Agent host or an Enterprise Manager managed database, or to update/add tags to all Operations Insights resources. For example, if your admin group is called opsi-admin group and you want to add this policy at the tenancy level, add the following:

   allow group opsi-admins to manage opsi-family in tenancy
   allow group opsi-admins to manage management-dashboard-family in tenancy

   Note that policies can also be created at the compartment level.

   See also Details for Management Dashboard for more details on policies for using Dashboards.

4. Depending on what resources you will be enabling add the following policies:

   Enabling	Policies	Details
   Autonomous Databases - basic features	allow group opsi-admins to use autonomous-database-family in tenancy	Basic features include Capacity Planning and SQL Warehouse.
   Autonomous Databases - full features	allow group opsi-admins to use autonomous-database-family in tenancy allow group opsi-admins to manage virtual-network-family in tenancy allow group opsi-admins to read secret-family in tenancy allow group opsi-admins to read secret-family in tenancy allow service operations-insights to read secret-family in tenancy where ANY {target.vault.id = 'mydbVault'} allow service operations-insights to read autonomous-database-family in tenancy where ALL{request.operation='GenerateAutonomousDatabaseWallet'}	Full features currently include SQL Explorer and ADDM Spotlight. Virtual network access is needed as part of the private endpoint reverse connection creation. Secret family access is required to read the database user password from OCI vault for running data collections against the database. Wallet generation permission is needed for connecting over mTLS to the database. See also Autonomous Database Full Feature Support.
   Bare Metal, VMs and ExaDB-D Databases	allow group opsi-admins to use database-family in tenancy allow group opsi-admins to manage virtual-network-family in tenancy allow group opsi-admins to read secret-family in tenancy allow service operations-insights to read secret-family in tenancy where ANY {target.vault.id = 'mydbVault'}	Access to Operations Insights is via private endpoint. Virtual network access is needed as part of the private endpoint reverse connection creation. Secret family access is required to read the database user password from OCI vault for running data collections against the database.
   External databases, hosts and Engineered Systems using Oracle Enterprise Manager	allow dynamic-group opsienterprisemanagerbridge to read object-family in compartment MyBucketCompartment where ANY (target.bucket.name='embridge-bucket') allow group opsi-admins to inspect object-family in tenancy	Enterprise Manager is an on-premises Oracle management solution that can integrate with OCI services and share data. You need to create a dynamic group to access the data in an Object Storage compartment, for example: ALL {resource.type='opsienterprisemanagerbridge'} If you will be enabling databases managed by Enterprise Manager (databases and hosts) see complete policies details under: Adding Enterprise Manager Targets.
   External databases and hosts using the OCI Management Agent	allow group opsi-admins to use external-database-family in tenancy allow group opsi-admins to manage management-agent-install-keys in tenancy	Any resources outside of OCI, such as on-premises databases that are not managed by Enterprise Manager, will require a Management Agent. If you will enable databases managed using a Management Agent, see also management agent policies.
   OCI Compute Instances	allow group opsi-admins to manage management-agents in tenancy allow group opsi-admins to manage instance-family in tenancy allow group opsi-admins to read instance-agent-plugins in tenancy	These instances can be enabled using Management Agents. See also the special policies under Deploy Management Agents on Compute Instances.
   AWR Hub (performance data from the Oracle Database Automatic Workload Repository)	ADB-S: allow dynamic-group OPSI_AWR_Hub_Dynamic_Group to manage opsi-awr-hub-sources in tenancy ADB-D and external databases: allow group <User Group> to use opsi-awr-hub-sources in tenancy Legacy policy: allow opsi-admins to manage opsi-family in tenancy	Note that there are additional policies required when you create an AWR Hub. You can add these through the guided creation process. For complete details see Analyze Automatic Workload Repository (AWR) Performance Data.
   EM Warehouse (continuous ingestion of EM data)	allow group opsi-admins to manage opsi-em-warehouse-family in tenancy	EM Warehouse continuously ingests Enterprise Manager repository metric data and stores it in an ADW Warehouse or OCI Object Store. See Analyze Automatic Workload Repository (AWR) Performance Data.
   Exadata Warehouse	N/A	Exadata Warehouse is a repository of data from on-premises and cloud-based Oracle Engineered Systems monitored by Enterprise Manager. See Exadata Warehouse.
   News reports	allow service operations-insights to use ons-topics in compartment opsi_prod allow group opsi-admins to inspect ons-topic in tenancy	News report generates weekly email reports on your OPSI monitored fleet using ONS (Oracle Notification Services). See: News Reports.

5. Click Create.

Create Non-administrator Policies

Users can only use Operations Insights if their group has been granted the requisite permissions. To allow the opsiuser user to enable/disable Operations Insights on only Autonomous Databases within their tenancy, you must create an identity policy to grant the opsi-users user appropriate group permissions.

1. Log in to the Console as your tenancy administrator and navigate to Governance and Administration > Identity and click Policies.
2. Use the To create a policy instructions and give the policy a meaningful name. For example, opsi-user-policy.
3. Add a policy statement to allow the group to enable/disable Operations Insights. For example, for the opsi-users group, add the following:

   allow group opsi-users to use opsi-family in tenancy
   allow group opsi-users to read management-dashboard-family in tenancy

4. Click Create.

For more fine grained control access to Operations Insights, see Details for Operations Insights.

Permissions

The following Oracle Cloud Infrastructure service permissions are required to enable Operations Insights for Oracle Cloud Databases and additionally for Exadata Cloud Service systems.

• Bare Metal and Virtual Machine DB systems and Exadata Cloud Service permissions: To enable Operations Insights for Oracle Cloud Databases, you must have the required Bare Metal and Virtual Machine DB systems and Exadata Cloud Service permissions.
  Note
  
  To use Exadata Insights, you must enable the Exadata target and not the database directly.
  Here's an example of a policy that grants the opsi-admins user group the permission to enable Operations Insights for the Oracle Cloud Databases in the tenancy:

  Note
  
  These policies can be compartment-scoped as well.

  allow group opsi-admins to read database-family in tenancy

  For Exadata, the following policies are also required:

  Note
  
  These policies can be compartment-scoped as well.

  allow group opsi-admins to read cloud-exadata-infrastructures in tenancy

  allow group opsi-admins to read cloud-vmclusters in tenancy

  For more information on specific Bare Metal and Virtual Machine DB systems and Exadata Cloud service resource-types and permissions, see Details for Bare Metal and Virtual Machine DB Systems and Details for Exadata Cloud Service Instances.

• Networking service permissions: To work with the Operations Insights private endpoint and enable communication between Operations Insights and the Oracle Cloud Database, you must have the manage permission on the vnics resource-type and the use permission on the subnets resource-type and either the network-security-groups or security-lists resource-type (You can either open up network access via a network security group (the database should have been configured to use the same), or the subnet needs to have the appropriate security lists (the subnet the database resides in)).

  Here are examples of the individual policies that grant the opsi-admins user group the required permissions:

  allow group opsi-admins to manage vnics in tenancy
  allow group opsi-admins to use subnets in tenancy
  allow group opsi-admins to use network-security-groups in tenancy

  
  allow group opsi-admins to use security-lists in tenancy

  Or a single policy using the Networking service aggregate resource-type grants the opsi-admins user group the same permissions detailed in the preceding paragraph:

  allow group opsi-admins to manage virtual-network-family in tenancy

  For more information on the Networking service resource-types and permissions, see the Networking section in Details for the Core Services.

• Vault service permissions:

  Cloud database credentials are added to the OCI Vault service, so you will have to write a policy to allow Operations Insights to read them for metric data collections. To create new secrets or use existing secrets when specifying the database credentials to enable Operations Insights for Oracle Cloud Databases, you must have the manage permission on the secret-family aggregate resource-type.

  Here's an example of the policy that grants the opsi-admins user group the permission to create and use secrets in the tenancy:

  allow group opsi-admins to manage secret-family in tenancy

  In addition to the user group policy for the Vault service, the following service policy is required to grant Operations Insights the permission to read database password secrets in a specific vault:

  allow service operations-insights to read secret-family in compartment ABC where target.vault.id = 'Vault OCID' 

  Note
  
  

  Compartment ABC is the compartment of the vault. This compartment is not required to match the compartment of the database.

  For more information on the Vault service resource-types and permissions, see Details for the Vault Service.

Oracle Cloud Database-related Prerequisite

• To enable and use Operations Insights for Oracle Cloud Databases, you must grant a database user, such as DBSNMP, the privileges required to access and monitor the Oracle Cloud Database. Important: When selecting a CDB, the database user must be a common user for all PDBs within the CDB.

  SQL> GRANT SELECT ANY DICTIONARY, SELECT_CATALOG_ROLE TO DBSNMP;

  For instructions on how to set up Oracle Database monitoring credentials, see Creating the Oracle Database Monitoring Credentials for Oracle Cloud Infrastructure Database Management and Operations Insights (Doc ID 2857604.1).
• Before starting to add databases in Operations Insights execute the best practice script steps outlined in OCI : Best Practices / Troubleshooting Guide For Monitoring Databases In Operations Insights (Doc ID 2942938.1).
  Note
  
  It is strongly recommended the script be run every 6 months or if any databases are missing the storage or tablespace data.
• Security best practices require that you change your passwords frequently, especially database passwords. The Security Technical Implementation Guide (STIG) and the Center for Internet Security (CIS) security benchmarks require regular password rotation. Oracle Database password lifetime is controlled through the user profiles, for more information see: Using a Password Management Policy.

  Changing the passwords for interactive database users such as DBAs is easy; they are forced to change it the next time they log into the database after their password has expired. However, the situation is more complicated when the database account is supporting an application like Database Management or Operations Insights running on multiple mid-tiers. If the password is changed in the database but not yet in these systems, they could repeatedly attempt to log in with the old password. This could result in account lockouts and potential service interruptions.

  Now you can follow security best practices for password update AND maintain application availability, this feature is available for Oracle Databases 19.12 and above. For more information see: Managing Gradual Database Password Rollover for Applications.

Enabling Network Communication

Specific network settings are required to enable communication between Operation Insights and Oracle Cloud Databases.

You must enable communication between Operations Insights and the Oracle Cloud Database by adding the ingress and egress security rules to an NSG or a Security List in the VCN in which the Oracle Cloud Database can be accessed.

Before you enable communication between Operations Insights and the Oracle Cloud Database, you must:

• Ensure that you're familiar with security rules. For information, see Security Rules.
• Depending on whether you want to use NSGs or Security Lists to add the ingress and egress rules, you must have the required permissions and be familiar with how to add security rules.
  Note
  
  

  • An NSG must be available to create an Operations Insights private endpoint. For more information, see Network Security Groups.
  • A security list rule that allows access over the database port <number> is applied to the NSG for access within the VCN or subnet CIDR block. For more information, see Security Lists.
• Make a note of the Oracle Cloud Database private IP addresses and port details and the Operations Insights private IP addresses. These are details that you may have to enter when you add security rules, and here's information on where you can find them:
  • For Oracle Cloud Database port details, see the DB System Information section on the Database System Details page for Oracle Databases on Bare Metal and Virtual Machine DB systems. For Oracle Databases on Exadata Cloud service, see Network details on the Exadata VM Cluster Details page.
  • For Oracle Cloud Database private IP addresses, see the Nodes section on the Database System Details page for single instance databases on Bare Metal and Virtual Machine DB systems. For RAC databases, use the Scan IP Address, which is available on the DB System Details page for the Virtual Machine DB system and on the Exadata VM Cluster Details page for the Exadata Cloud service.

  Note that an Operations Insights private endpoint for single instance Oracle Cloud Databases in the Bare Metal and Virtual Machine DB systems has only one private IP address and an Operations Insights private endpoint for RAC Oracle Cloud Databases in the Virtual Machine DB system and Exadata Cloud service has two private IP addresses.

For Operations Insights to communicate with the Oracle Cloud Database, you must add ingress and egress security rules using either Network Security Groups (NSG) or Security Lists. The following examples illustrate how to enable communication between an Operations Insights private endpoint and the Oracle Databases on a Virtual Machine DB system using NSGs and Security Lists.

Create an NSG to enable communication between the Operations Insights private endpoint and a Virtual Machine DB system

In the following example, an NSG is created and added to:

• A Virtual Machine DB system
• An Operations Insights private endpoint for single instance Oracle Cloud Databases (which is already created)

On completing the tasks listed in this example, the Operations Insights private endpoint will have access to all the single instance databases in the Virtual Machine DB system's VCN without impacting the VCN's subnet architecture.

For information on creating an NSG in the Virtual Machine DB system's VCN, see To create an NSG.

After you create the NSG, you must add it to the Virtual Machine DB system and the Operations Insights private endpoint.

For information on how to add the NSG to the Virtual Machine DB system, see To edit the Network Security Groups (NSGs) for your DB System.

To add the NSG to the Operations Insights private endpoint, go to the Operations Insights Private Endpoint Administration page (Administration > Private Endpoints) and click the private endpoint to which you want to add the NSG. On the Private Endpoint Details page, click Edit against Network Security Groups and add the newly created NSG.

Add security rules to a Security List to enable communication between an Operations Insights private endpoint and a Virtual Machine DB system

In the following example, stateful security rules are added to an existing Security List in the Virtual Machine DB system's VCN to enable communication between an Operations Insights private endpoint for single instance Oracle Cloud Databases and all the subnets in the VCN. This ensures that the Operations Insights private endpoint can access all the single instance databases in the VCN.

For information on updating an existing Security List, see To update rules in an existing security list.

Obtaining CIDR Block Values

The CIDR block values used to define rules will be specific to your environment and not those shown in the above examples. You can obtain the correct CIDR ingress/egress rule values for your Operations Insights environment as follows:

• Ingress Rules

  The ingress rule you need to create depends on the subnet specified when creating the private endpoint. You can find the CIDR block on the VCN/Subnet page. Operations Insights also provides a convenient link to the VCN/Subnet page directly from the Private Endpoint Details page.

  
  
  
  
  
• Egress Rules

  The egress rule you need to create depends on the VCN in which your Oracle Cloud Database(s) reside. You can find the CIDR block by navigating to the database details page where you'll find a link to the associated VCN.

  
  
  
  
  
  
  
  
  
  Note
  
  You should write your rule using the entire CIDR block so that the private endpoint can be used for all databases in the VCN.

TCPS Enabling Permissions

If you opt to use the TCP/IP with Transport Layer Security (TCPS) protocol to securely connect to the Oracle Cloud Database, then you're required to enter the port number and upload the database wallet when enabling Database Management.

For information on how to configure TLS authentication, see Configuring Transport Layer Security Authentication.

Creating a Private Endpoint

To create a private endpoint:

1. From the Operations Insights main menu, click Administration and then Private Endpoints to access the Private Endpoint Administration page for the currently selected compartment. If endpoints for the compartment were previously defined, they will appear in the table where you can perform administrative functions.
2. Click Create Private Endpoint. The Create Private Endpoint dialog displays.
   
   
   
   
3. Enter the required parameters to define the endpoint:
   • Name: An easily identifiable name for the endpoint.
   • Description: Optional
   • Compartment: Select a compartment in which to create the private endpoint from the drop-down list. By default, the compartment that was selected prior to clicking Create Private Endpoint is chosen. Note that this does not have to match the database compartment.

   Configuration

   The private endpoint will be created in the VCN and subnet selected here. Select a subnet that has connectivity to the subnet which contains the database that will be added to Operations Insights.

   • Use this private endpoint for RAC databases. You should select this when connecting to an ExaDB-D/VM RAC database. It can only be set during private endpoint creation and cannot be changed later.
   • Virtual Cloud Network in <compartment>: Select the VCN within the current compartment that will be used to access the Cloud database. If desired, use the drop-down list to choose another VCN in that compartment.
   • Subnet in <compartment>: Select a subnet within the chosen VCN. By default, the first subnet in the drop-down list is selected.

   Network Security Group (optional)

   A network security group lets you add additional fine-grained security access to any resources that will be using the private endpoint. A security group acts as a virtual firewall that allows you to separate your VCN's subnet architecture from your security requirements.

   To add a network security group to the private endpoint,

   1. Click +Another Network Security Group.
   2. Select an existing network security group from the drop-down selector.
   3. If no security groups exist, click Add new to display the VCN details page where you can define a new Network Security Group for that VCN.
   4. From the Network Security Group region of the Create Private Endpoint dialog, click the refresh icon. The newly defined security group will be available in the drop-down selector.

4. Click Create Private Endpoint. The Private Endpoint Details page displays where you can view private endpoint information including direct links to the details pages for the endpoint’s VCN, subnet, and network security groups.

For more information about security groups, see Network Security Groups

From the Private Endpoints Details page, you can perform the following operations:

• View existing or define new resource tags
• Edit the private endpoint (name, description, add/delete network security groups)
• Move the private endpoint to a different compartment
• Add resource tags
• Delete the private endpoint
• Register Oracle Cloud Databases with the private endpoint
• View work requests associated with the private endpoint. Note: By default, the details page displays database resources. To display work resources, click Work Requests in the Resources menu. For more information about work requests, see Work Resources.

The above operations can also be performed from the Private Endpoint Administration page via the context menu (vertical ellipsis) for each private endpoint.

Deleting a Private Endpoint

You can delete a private endpoint from the Private Endpoint Administration page. Important: All databases accessing the private endpoint must first be disabled.

Change a TCPS Cloud Service Database to TCP

You can change a TCPS monitored cloud database to a default TCP connection, first disable the database by clicking the three dot action menu for the database you want to edit. Once disabled click on Edit Connection Details, select TCP as the protocol and update the port number. Once complete re-enable the database.

You can also change a TCP monitored database to a TCPS connection by clicking the three dot action menu for the database you with to edit, disabling the database, click on Edit Connection Details, select TCPS as the protocol and update the port number. Once complete re-enable the database.

Enabling/Disabling Exadata Cloud Service Databases

If Exadata Cloud Service databases were previously enabled, they do not need to be enabled again. If all the Container Databases/Non-Container Databases are already enabled, simply select the VM Cluster and the Private Endpoint used when adding the Exadata system.

When disabling the Exadata system, it's highly recommended that this be done on the Exadata system itself as this will disable the databases and hosts automatically.

If you want to disable a single Container Database and its Pluggable Databases, simply disable the Container Database and all its Pluggable Databases will also be disabled as a result.

To delete an EM bridge:

1. Open the navigation menu and click Observability and Management. Under Operations Insights, click Administration. The Database Fleet option is selected by default in the Operation Insights navigation menu.
2. Click EM Bridges. The EM Bridge Administration page displays.
3. In the EM Bridge table, click on the EM bridge you want to delete. The details page for the EM bridge displays.
4. For each enabled resource in the table, choose Disable Operations Insights from the Actions menu. All resources must be disabled.
   Note
   
   Any Exadata Systems should be disabled and deleted first (this will also disable and delete the child databases and hosts).
5. For each disabled database in the table, click the vertical ellipses to display the pop-up menu and choose Delete Operations Insights.
6. Once all databases have been disabled and deleted, click Delete at the top of the EM Bridge details page to start the bridge deletion process.

Delete EM Bridge Bucket Data

Prerequisites

• IMPORTANT: Enterprise Manager configuration (setting up the OCI Bridge) MUST be done first. See Integrating Enterprise Manager with OCI Services.
• EM Bridge and Object Storage bucket has been set up.
• Enable Exadata Systems for Operations Insights.
  • Exadata Database Service on Dedicated Infrastructure, Exadata Database Machines, and Exadata Cloud@Customer deployments must be monitored by Enterprise Manager.
• Exadata Insights is compatible with the following versions of Enterprise Manager:
  • On-premises (Exadata Database Machine): Enterprise Manager 13c Release 5 Update 10 (13.5.0.10) and greater
  • Cloud Service (Exadata Database Service on Dedicated Infrastructure and Exadata Cloud@Customer): Enterprise Manager 13c Release 5 Update 10 (13.5.0.10) and greater

You can filter host and database resources by namespaces, tags, and tag values. Tag filtering lets you display only those resources for which a specific tag has been assigned. This can greatly simplify resource management. For example, you want to perform Capacity Planning on your production databases only. By tagging your production databases with a Lifecycle State of Production, you can easily isolate only the production databases in Operations Insights.

Apply Tags to Resources

1. Navigate tot he Operations Insights Administration page. From the OCI console, select Observability & Management, and the under Operations Insights, select Administration.
2. Select a resource type from the left navigation menu. For example, Database Fleet or Host Fleet.
3. For a specific resource in the list, select Add Tag from that resource's Action menu (vertical ellipses).
4. Enter the requisite tag information and click Add tag. Repeat this step for however many tags you want to define for this resource.
5. Click Add tags when you're finished.

Filter by Tags

1. Click Add to display the Apply a Tag Filter dialog.
   
   
   
   
2. Select a Tag Namespace (optional) and enter a Tag Key.
3. To narrow tag filtering, you can define supplementary patterns on which to filter. By default, Match any value is selected. To define additional Tag Key pattern filtering criteria, click Match any of the following and enter the text to be used for filtering. You can define additional text filtering criteria by clicking Add (+) and entering the desired text.
4. Click Apply Filter.

   To remove the filter, click Clear.

Group by Tags

You can create an arbitrary grouping of target resources based on tag keys and tag values used by free-form and defined tags,

• Free-form Tag: A basic metadata association that consists of a key and a value only. Free-form tags have limited functionality. See Understanding Free-form Tags. Free-form tags allows any user to add tags to resources.
• Tag (or Defined Tag): A tag is the instance of a key definition that is applied to a resource. It consists of a namespace, a key, and a value. "Tag" is used generically to refer to defined tags. Tag administrators create and manage defined tags.

Using free-form and defined tags to create grouping of target resources based on tag keys and tag values lets you perform trend and forecast analysis on any meaningful set of resources. For example, you can define a specific tag keys for all databases that are part of the Sales department within North America and then specify only databases that meet those specific tag key and value criteria be used for trend and forecast analysis or, as shown in the SQL Warehouse example below, group all the SQL statements running in databases as part of a particular department or application grouping. This tag grouping feature can be used with Capacity Planning, Exadata Insights, and Oracle SQL Warehouse.

Monitoring Credentials

Before adding a database, ensure that you have proper monitoring credentials set up. For instructions on how to set up External and Cloud Oracle Database monitoring credentials (Virtual Machine, Bare Metal, and Exadata) see Creating the Oracle Database Monitoring Credentials for Oracle Cloud Infrastructure Database Management and Operations Insights (Doc ID 2857604.1).

To create an Autonomous Database monitoring credential see, see Creating the Autonomous Database Monitoring Credentials for Oracle Cloud Operations Insights (Doc ID 2933173.1).

Enable Databases for Operations Insights

To enable one or more databases for Operations Insights, log in to OCI and do the following:

1. Open the navigation menu and click Observability and Management. Under Operations Insights, click Administration and then Database Fleet..The Database Fleet Administration page displays.
2. Click Add Databases. The Add Databases to Operations Insights dialog displays.
3. Click on the desired Telemetry. Available telemetries are:
   • Cloud Infrastructure: Autonomous databases running in OCI, Exadata Cloud Service databases , Virtual Machine, and Bare Metal.
   • Enterprise Manager: Databases monitored and managed via Enterprise Manager. You'll need to select the EM Bridge. In addition, you'll also need to select the destination compartment as shown in the next step.
   • Agent Service: Databases monitored by the OCI Management Agent Service. You'll need to select the destination compartment as shown in the next step. In addition, you'll also need to select an external connector.
4. Select the Compartment that contains the database that you want to enable for Operations Insights.
   Note
   
   

   This is not needed for Enterprise Manager databases (you select the EM bridge instead) and you choose the destination compartment.

   For Management Agent databases you must also select the connector after selecting the database to enable.

   Optionally, if there are many databases and you know which ones you want to enable, you can filter the returned results based on database type.
5. Select a database to enable.
   Note
   
   Autonomous Databases and Enterprise Manager databases allow you to multi-select databases for enablement. The multi-select feature is not available for databases monitored by Management Agents, Virtual Machine, or Bare Metal. Alternatively, for Exadata, you can bulk enable the entire the entire Exadata system.
6. Click Enable. The enable request is submitted for processing. Depending on amount of data that needs to be uploaded, it may take a few minutes for the process to complete. Data may take up to 24 hours to appear in Operations Insights for newly enabled database.

Available Actions

Once you've added a database to Operations Insights, in addition to enabling and disabling the database, you can also add tags and move these resources to different compartments (only Enterprise Manager databases can be moved). These actions can be accessed by clicking the vertical ellipses for any database in the Database Fleet table.

Prerequisites

1. Enable the Autonomous Database in Operations Insights, for more information see Enable Databases for the Service
2. If your network requires it, create a Private Endpoint. Make sure you set up the correct network requirements for your database, including the creation of private endpoints. The following table outlines the network requirements by type of autonomous databases:

   ADB Type	Access Type	Network Requirements
   ADB Serverless (ADB-S)	Access Anywhere	None
   ADB Serverless (ADB-S)	Private Endpoint	Same Private Endpoint requirements as cloud databases. Note Use the ADB private endpoint VCN/Subnet instead of the database VCN/Subnet For more information see: Enabling Database Cloud Service Databases and Exadata Cloud Service
   ADB Serverless (ADB-S)	ACL (Access Control List) Restricted	The private endpoint needs to be placed in one of the whitelisted VCNs. This VCN must have access to the public ADB endpoint, typically via service gateway. For more information see: Configure Access Control Lists When You Provision or Clone an Instance
   ADB Dedicated (ADB-D)	N/A	Same requirements as cloud databases. For more information see: Enabling Database Cloud Service Databases and Exadata Cloud Service Note Dedicated Autonomous Databases require a private endpoint with DNS Proxy enabled. Operations Insights private endpoints created prior to September 2023 did not require the DNS proxy enabled. A new private endpoint may need to be created.

3. Create the policies to allow Operations Insights service to generate autonomous database wallets, and to read the database password secret. It is recommended this step be performed automatically when setting up the Advanced Features collection in Step 4.
   Example policy to allow Operations Insights service to generate Autonomous Database wallets:

   allow service operations-insights to read autonomous-database-family in tenancy where ALL{request.operation='GenerateAutonomousDatabaseWallet'}

   Example policy to allow Operations Insights service to read the database password secret:

   allow service operations-insights to read secret-family in tenancy where ANY{target.secret.id='<SecretId>'}

Enable Full Features Collection For an Autonomous Database

Available Actions

Once you've added a host to Operations Insights, in addition to enabling and disabling the host, you can also add tags and move these resources to different compartments. These actions can be accessed by clicking the vertical ellipses for any host in the Host Fleet table.