Best Practices for Low Latency Connections with Autonomous Database

Taking steps to reduce the latency for connections between an application and Autonomous Database is critical if your application performs many round-trips between the application and the database.

For example, consider an OLTP application connecting to Autonomous Database and submitting thousands of SQL statements to the database individually to execute a sales order. In this case, the application requires thousands of round-trips, and reducing the latency for each round-trip can considerably speed up the sales order process. For such applications there are best practices that you can follow to reduce the latency for database connections.

• Steps to Reduce Latency for Database Connections
  You can follow these recommendations to reduce the latency for connections between your applications and the database.
• Steps to Reduce Latency for Database Connections for Databases with Autonomous Data Guard
  Provides steps to take to configure an Autonomous Data Guard standby environment, clients and mid-tiers, to reduce latency for database connections when you connect after a failover or after a switchover (when the standby becomes the Primary).
• Conceptual Network Diagram for Low Latency Database Connections
  Shows the conceptual network diagram for low latency connections using public endpoints and private endpoints for your database.

Steps to Reduce Latency for Database Connections

You can follow these recommendations to reduce the latency for connections between your applications and the database.

First determine the database's availability domain. To find an Autonomous Database instance's availability domain, connect as ADMIN and run the following query:

SELECT json_value(cloud_identity, '$.AVAILABILITY_DOMAIN') AVAILABILITY_DOMAIN FROM v$pdbs;

For example:

SELECT json_value(cloud_identity, '$.AVAILABILITY_DOMAIN') AVAILABILITY_DOMAIN
             FROM v$pdbs;

AVAILABILITY_DOMAIN  
-------------------- 
SoSC:US-ASHBURN-AD-1

To reduce latency, do the following:

1. Place clients or the mid-tier servers in the same availability domain as the Autonomous Database instance.

   For example, if your application runs on an Oracle Cloud Infrastructure Compute VM, select the same availability domain as the Autonomous Database instance when you create the compute instance.

   If the application runs in another cloud or in an on-premises data center, use OCI FastConnect to reduce the latency for the connection to your OCI region. See FastConnect Overview for more information.

2. Configure the network routing.

   • If you are using an Autonomous Database instance on a public endpoint, configure your network routing so that the connection from the client to the database goes through a Service Gateway.

     See the following for more information.

     • Setting Up a Service Gateway in the Console

     • Access to Oracle Services: Service Gateway

   • If you are using an Autonomous Database instance on a private endpoint, you connect to the database using the private endpoint visible in your network, without the need to configure a Service Gateway.

3. Use one-way TLS connections without a wallet.

   As a best practice for lower latency, configure the Autonomous Database instance to allow both mTLS and TLS connections and use TLS connections to connect your application to the database.

   See the following for more information:

   • Secure Connections to Autonomous Database

   • Update Network Options to Allow TLS or Require Only Mutual TLS (mTLS) Authentication on Autonomous Database

4. Use TCP Fast Open (TFO) to connect to the database.

   See Use TCP Fast Open (TFO) to Connect Clients to Autonomous Database for more information.

Steps to Reduce Latency for Database Connections for Databases with Autonomous Data Guard

Provides steps to take to configure an Autonomous Data Guard standby environment, clients and mid-tiers, to reduce latency for database connections when you connect after a failover or after a switchover (when the standby becomes the Primary).

• Reduce Latency for Database Connections with Local Autonomous Data Guard
  Follow these steps to reduce the latency for the database connections you make when you use Autonomous Data Guard and you either failover or switchover to a local standby database.
• Reduce Latency for Database Connections with Cross-Region Autonomous Data Guard
  Follow these steps to reduce the latency for the database connections you make when you use Autonomous Data Guard and you either fail over or switch over to a cross-region standby database.

Reduce Latency for Database Connections with Local Autonomous Data Guard

Follow these steps to reduce the latency for the database connections you make when you use Autonomous Data Guard and you either failover or switchover to a local standby database.

If you have an Autonomous Data Guard local standby and you are in a region with multiple availability domains, Autonomous Data Guard creates the local standby database in a different availability domain. When you failover or switchover to the standby database, the local standby becomes the Primary database. To prepare for a failover or a switchover it is recommended to have standby clients and mid-tiers available to enable, so that after a failure or after a switchover, your applications can continue working in the event of an availability domain failure.

First, verify that the disaster recovery type for your local peer is Autonomous Data Guard. See Enable Autonomous Data Guard for more information.

Perform the following tasks to configure standby clients and mid-tiers for low latency when you are using Autonomous Data Guard with a local standby in a region with multiple availability domains.

1. Place the standby clients or mid-tiers in the same availability domain as the local standby database (all components should be configured to use the same availability domain).

   For example, if your application runs on an Oracle Cloud Infrastructure Compute VM, when you create the compute instance select the same availability domain for the Compute VM as the standby database. This prepares the disaster recovery configuration so that the standby database and the standby Compute VM use the same availability domain after a failover or switchover. This will reduce latency for connections to the database compared to a configuration where the components use different availability domains.

   To determine the availability domain of the standby database, connect to the Primary database as the ADMIN user and run the following query:

   SELECT availability_domain FROM v$pdbs,
        JSON_TABLE(
          cloud_identity,
          '$.AUTONOMOUS_DATA_GUARD[*]'
          COLUMNS (
            standby_type PATH '$.STANDBY_TYPE',
            availability_domain PATH '$.AVAILABILITY_DOMAIN'
          )
        ) jt
   WHERE jt.standby_type = 'local';

   For example, this command shows the availability domain for a local standby database:

   AVAILABILITY_DOMAIN 
   ------------------- 
   SoSC:US-ASHBURN-AD-3

2. You do not need to do additional network configuration or allow one-way TLS connections for the local standby database. A local standby database has the same setup network configuration as the Primary database.
3. Configure your clients and mid-tiers to use TCP Fast Open.

   See Use TCP Fast Open (TFO) to Connect Clients to Autonomous Database for more information.

Reduce Latency for Database Connections with Cross-Region Autonomous Data Guard

Follow these steps to reduce the latency for the database connections you make when you use Autonomous Data Guard and you either fail over or switch over to a cross-region standby database.

If you add one or more cross-region Autonomous Data Guard standby databases, the cross-region standby databases are added in the regions that you select when you add a cross-region peer. When you failover or switchover to a cross-region Autonomous Data Guard standby database, the cross-region standby becomes the Primary database. To prepare for a regional failover or switchover, it is recommended to have standby clients and mid-tiers available in the remote region. This prepares the clients and the mid-tier in the remote region so that in the case of a failure or after a switchover, your applications can continue working.

First, verify that your disaster recovery includes at least one cross-region Autonomous Data Guard standby. See Add a Cross-Region Standby Database for more information.

Follow these steps to configure clients and mid-tiers for low latency when using Autonomous Data Guard with one or more cross-region standby databases.

1. Place the standby clients or mid-tiers in the same availability domain as the cross-region standby databases.

   To determine the availability domains for cross-region Autonomous Data Guard standby databases, connect to the Primary database as the ADMIN user and run the following query:

   SELECT availability_domain FROM v$pdbs,
        JSON_TABLE(
          cloud_identity,
          '$.AUTONOMOUS_DATA_GUARD[*]'
          COLUMNS (
            standby_type PATH '$.STANDBY_TYPE',
            availability_domain PATH '$.AVAILABILITY_DOMAIN'
          )
        ) jt
   WHERE jt.standby_type = 'cross-region';

   For example, when you have two cross-region standby databases, running this command shows the availability domains for each cross-region standby database:

   AVAILABILITY_DOMAIN    
   ---------------------- 
   SoSC:PHX-AD-3          
   SoSC:US-SANJOSE-1-AD-1 

   1. If you have one cross-region standby, the query shows a single availability domain. Place the standby clients and mid-tiers in the same region and use the same availability domain as the cross-region standby database.

      For example, if your application runs on an Oracle Cloud Infrastructure Compute VM, when you create the compute instance select the same availability domain for the Compute VM as the Autonomous Data Guard standby database. This assures that the cross-region standby database and the standby Compute VM are in the same region and use the same availability domain after a failover or switchover.

   2. If you have more than one cross-region standby, in each region use the appropriate availability domain that matches the region and the availability domain for each corresponding standby database. You will need to perform this setup multiple times (all components in an individual region should use the same availability domain as the Autonomous Data Guard standby).

   If the application runs in another cloud or in an on-premises data center, use OCI FastConnect to reduce the latency for the connection to your OCI region. See FastConnect Overview for more information.

2. Configure the network routing in the region where the standby database resides. Perform this step multiple times if you have more than one cross-region standby database.
   1. If the standby database is on a public endpoint, configure your network routing so that the connection from the clients in the region where the cross-region standby database is, go through a Service Gateway.

      See the following for more information:

      • Setting Up a Service Gateway in the Console

      • Access to Oracle Services: Service Gateway

   2. If the standby database is on a private endpoint, you connect to the database using the private endpoint visible in your network, without the need to configure a Service Gateway.
3. Use one-way TLS connections without a wallet.

   If you configured one-way TLS for your primary database, standby databases will already have on-way TLS configured. You do not need to do any additional configuration on cross-region standby databases.

4. Configure your clients and mid-tiers to use TCP Fast Open.

   See Use TCP Fast Open (TFO) to Connect Clients to Autonomous Database for more information.

Conceptual Network Diagram for Low Latency Database Connections

Shows the conceptual network diagram for low latency connections using public endpoints and private endpoints for your database.

Low Latency Connections Using Private Endpoint with Application Running Inside the OCI Region

Description of the illustration adb-private-low-latency.eps

Low Latency Connections Using Public Endpoint with Application Running Inside the OCI Region

Description of the illustration adb-public-low-latency.eps

Low Latency Connections Using a Private Endpoint with Application Running In On-Premises Data Center Connected to OCI Using FastConnect

Description of the illustration adb-fastconnect-private-low-latency.eps

Low Latency Connections Using a Private Endpoint with Application Running In Your in On-Premises Data Center Connected to OCI Using FastConnect

Description of the illustration adb-fastconnect-public-low-latency.eps