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.
Parent topic: Connection and Networking Options and Features
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
You can also view the availability domain information on the Oracle Cloud Infrastructure Console. See View Network Information on the OCI Console for more information.
To reduce latency, do the following:
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.
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.
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
Low Latency Connections Using Public Endpoint with Application Running Inside the OCI Region
Low Latency Connections Using a Private Endpoint with Application Running In On-Premises Data Center Connected to OCI Using FastConnect
Low Latency Connections Using a Private Endpoint with Application Running In Your in On-Premises Data Center Connected to OCI Using FastConnect