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.
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
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.
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.
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.
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.
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.
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.
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:
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.
Configure your clients and mid-tiers to use TCP Fast Open.
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.
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:
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.
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.
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.
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.
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.
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.
Configure your clients and mid-tiers to use TCP Fast Open.