Oracle Cloud Infrastructure-Dokumentation

Best Practices für Verbindungen mit geringer Latenz mit Autonomous Database

Schritte zur Reduzierung der Latenz für Verbindungen zwischen einer Anwendung und Autonomous Database sind wichtig, wenn Ihre Anwendung viele Roundtrips zwischen der Anwendung und der Datenbank durchführt.

Beispiel: Eine OLTP-Anwendung stellt eine Verbindung zu Autonomous Database her und leitet Tausende von SQL-Anweisungen einzeln an die Datenbank weiter, um einen Kundenauftrag auszuführen. In diesem Fall erfordert die Anwendung Tausende von Roundtrips, und die Verringerung der Latenz für jeden Roundtrip kann den Kundenauftragsprozess erheblich beschleunigen. Für solche Anwendungen gibt es Best Practices, die Sie befolgen können, um die Latenz für Datenbankverbindungen zu reduzieren.

Übergeordnetes Thema: Verbindungs- und Netzwerkoptionen und -features

Schritte zur Reduzierung der Latenz für Datenbankverbindungen

Sie können diese Empfehlungen befolgen, um die Latenz für Verbindungen zwischen Ihren Anwendungen und der Datenbank zu reduzieren.

Bestimmen Sie zunächst die Availability-Domain der Datenbank. Um die Availability-Domain einer Autonomous Database-Instanz zu suchen, melden Sie sich als ADMIN an, und führen Sie die folgende Abfrage aus: 

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

Beispiel:

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

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

Sie können die Informationen zur Availability-Domain auch in der Oracle Cloud Infrastructure-Konsole anzeigen. Weitere Informationen finden Sie unter Netzwerkinformationen in der OCI-Konsole anzeigen.

Um die Latenz zu reduzieren, gehen Sie wie folgt vor:

  1. Platzieren Sie Clients oder Mid-Tier-Server in derselben Availability-Domain wie die Autonomous Database-Instanz.

    Beispiel: Wenn Ihre Anwendung auf einer Oracle Cloud Infrastructure Compute-VM ausgeführt wird, wählen Sie beim Erstellen der Compute-Instanz dieselbe Availability-Domain aus wie die Autonomous Database-Instanz.

    Wenn die Anwendung in einer anderen Cloud oder in einem On-Premises-Data-Center ausgeführt wird, verwenden Sie OCI FastConnect, um die Latenz für die Verbindung zu Ihrer OCI-Region zu reduzieren. Weitere Informationen finden Sie unter Überblick über FastConnect.

  2. Netzwerkrouting konfigurieren.

    • Wenn Sie eine Autonomous Database-Instanz auf einem öffentlichen Endpunkt verwenden, konfigurieren Sie das Netzwerkrouting so, dass die Verbindung vom Client zur Datenbank über ein Servicegateway erfolgt.

      In den folgenden Themen finden Sie weitere Informationen.

    • Wenn Sie eine Autonomous Database-Instanz auf einem privaten Endpunkt verwenden, stellen Sie eine Verbindung zur Datenbank mit dem privaten Endpunkt her, der in Ihrem Netzwerk angezeigt wird, ohne dass ein Servicegateway konfiguriert werden muss.

  3. Verwenden Sie unidirektionale TLS-Verbindungen ohne Wallet.

    Als Best Practice für eine geringere Latenz konfigurieren Sie die Autonomous Database-Instanz so, dass sowohl mTLS- als auch TLS-Verbindungen zulässig sind, und verwenden Sie TLS-Verbindungen, um Ihre Anwendung mit der Datenbank zu verbinden.

    In den folgenden Themen finden Sie weitere Informationen:

  4. Verwenden Sie TCP Fast Open (TFO), um eine Verbindung zur Datenbank herzustellen.

Schritte zur Reduzierung der Latenz für Datenbankverbindungen für Datenbanken mit Autonomous Data Guard

Bietet Schritte zur Konfiguration einer Autonomous Data Guard-Standbyumgebung, von Clients und Mid-Tiers, um die Latenz für Datenbankverbindungen zu reduzieren, wenn Sie nach einem Failover oder nach einem Switchover eine Verbindung herstellen (wenn die Standbydatenbank zur Primärdatenbank wird).

Übergeordnetes Thema: Best Practices für Verbindungen mit geringer Latenz mit Autonomous Database

Latenz für Datenbankverbindungen mit lokalem Autonomous Data Guard reduzieren

Führen Sie diese Schritte aus, um die Latenz für die Datenbankverbindungen zu reduzieren, die Sie bei Verwendung von Autonomous Data Guard und bei einem Failover oder Switchover zu einer lokalen Standbydatenbank vornehmen.

Wenn Sie über eine lokale Autonomous Data Guard-Standbydatenbank verfügen und sich in einer Region mit mehreren Availability-Domains befinden, erstellt Autonomous Data Guard die lokale Standbydatenbank in einer anderen Availability-Domain. Beim Failover oder Switchover zur Standbydatenbank wird die lokale Standbydatenbank zur primären Datenbank. Zur Vorbereitung auf einen Failover oder Switchover wird empfohlen, Standby-Clients und Mid-Tiers zu aktivieren, damit Ihre Anwendungen nach einem Ausfall oder nach einem Switchover im Falle eines Ausfalls der Availability-Domain weiter arbeiten können.

Prüfen Sie zunächst, ob der Disaster-Recovery-Typ für Ihren lokalen Peer Autonomous Data Guard ist. Weitere Informationen finden Sie unter Autonomous Data Guard aktivieren.

Führen Sie die folgenden Aufgaben aus, um Standbyclients und Mid-Tiers für geringe Latenz zu konfigurieren, wenn Sie Autonomous Data Guard mit einer lokalen Standbydatenbank in einer Region mit mehreren Availability-Domains verwenden.

  1. Platzieren Sie die Standbyclients oder Mid-Tiers in derselben Availability-Domain wie die lokale Standbydatenbank (alle Komponenten müssen so konfiguriert sein, dass sie dieselbe Availability-Domain verwenden).

    Beispiel: Wenn Ihre Anwendung auf einer Oracle Cloud Infrastructure Compute-VM ausgeführt wird, wählen Sie beim Erstellen der Compute-Instanz dieselbe Availability-Domain für die Compute-VM wie die Standbydatenbank aus. Dadurch wird die Disaster Recovery-Konfiguration so vorbereitet, dass die Standbydatenbank und die Standby-Compute-VM nach einem Failover oder Switchover dieselbe Availability-Domain verwenden. Dadurch wird die Latenz für Verbindungen zur Datenbank im Vergleich zu einer Konfiguration verringert, bei der die Komponenten verschiedene Availability-Domains verwenden.

    Um die Availability-Domain der Standbydatenbank zu bestimmen, melden Sie sich als ADMIN-Benutzer bei der primären Datenbank an, und führen Sie die folgende Abfrage aus:

    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';

    Beispiel: Dieser Befehl zeigt die Availability-Domain für eine lokale Standbydatenbank an:

    AVAILABILITY_DOMAIN 
------------------- 
SoSC:US-ASHBURN-AD-3
  2. Sie müssen keine zusätzliche Netzwerkkonfiguration vornehmen oder unidirektionale TLS-Verbindungen für die lokale Standbydatenbank zulassen. Eine lokale Standbydatenbank hat dieselbe Setupnetzwerkkonfiguration wie die primäre Datenbank.
  3. Konfigurieren Sie Ihre Clients und Mid-Tiers für die Verwendung von TCP Fast Open.

Reduzierung der Latenz für Datenbankverbindungen mit regionsübergreifendem Autonomous Data Guard

Führen Sie diese Schritte aus, um die Latenz für die Datenbankverbindungen zu reduzieren, die Sie bei der Verwendung von Autonomous Data Guard und beim Failover oder beim Switchover zu einer regionsübergreifenden Standbydatenbank vornehmen.

Wenn Sie eine oder mehrere regionsübergreifende Autonomous Data Guard-Standbydatenbanken hinzufügen, werden die regionsübergreifenden Standbydatenbanken in den Regionen hinzugefügt, die Sie auswählen, wenn Sie einen regionsübergreifenden Peer hinzufügen. Beim Failover oder Switchover zu einer regionsübergreifenden Autonomous Data Guard-Standbydatenbank wird die regionsübergreifende Standbydatenbank zur primären Datenbank. Zur Vorbereitung auf ein regionales Failover oder Switchover wird empfohlen, Standbyclients und Mid-Tiers in der Remoteregion zur Verfügung zu haben. Dadurch werden die Clients und die Mid-Tier in der Remoteregion vorbereitet, sodass Ihre Anwendungen im Falle eines Ausfalls oder nach einem Switchover weiterarbeiten können.

Stellen Sie zunächst sicher, dass Ihr Disaster Recovery mindestens eine regionsübergreifende Autonomous Data Guard-Standbydatenbank enthält. Weitere Informationen finden Sie unter Regionsübergreifende Standbydatenbank hinzufügen.

Führen Sie diese Schritte aus, um Clients und Mid-Tiers für eine geringe Latenz zu konfigurieren, wenn Sie Autonomous Data Guard mit einer oder mehreren regionsübergreifenden Standbydatenbanken verwenden.

  1. Platzieren Sie die Standby-Clients oder Mid-Tiers in derselben Availability-Domain wie die regionsübergreifenden Standbydatenbanken.

    Um die Availability-Domains für regionsübergreifende Autonomous Data Guard-Standbydatenbanken zu bestimmen, melden Sie sich als ADMIN-Benutzer bei der Primärdatenbank an, und führen Sie die folgende Abfrage aus: 

    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';

    Beispiel: Wenn Sie über zwei regionsübergreifende Standbydatenbanken verfügen, werden mit diesem Befehl die Availability-Domains für jede regionsübergreifende Standbydatenbank angezeigt:

    AVAILABILITY_DOMAIN    
---------------------- 
SoSC:PHX-AD-3          
SoSC:US-SANJOSE-1-AD-1
    1. Wenn Sie über eine regionsübergreifende Standbydatenbank verfügen, zeigt die Abfrage eine einzelne Availability-Domain an. Platzieren Sie die Standby-Clients und Mid-Tiers in derselben Region, und verwenden Sie dieselbe Availability-Domain wie die regionsübergreifende Standbydatenbank.

      Beispiel: Wenn Ihre Anwendung auf einer Oracle Cloud Infrastructure Compute-VM ausgeführt wird, wählen Sie beim Erstellen der Compute-Instanz dieselbe Availability-Domain für die Compute-VM aus wie die Autonomous Data Guard-Standbydatenbank. Dadurch wird sichergestellt, dass sich die regionsübergreifende Standbydatenbank und die Standby-Compute-VM in derselben Region befinden und nach einem Failover oder Switchover dieselbe Availability-Domain verwenden.

    2. Wenn Sie über mehrere regionsübergreifende Standbydatenbanken verfügen, verwenden Sie in jeder Region die entsprechende Availability-Domain, die mit der Region und der Availability-Domain für jede entsprechende Standbydatenbank übereinstimmt. Sie müssen dieses Setup mehrmals ausführen (alle Komponenten in einer einzelnen Region sollten dieselbe Availability-Domain wie die Autonomous Data Guard-Standbydatenbank verwenden).

    Wenn die Anwendung in einer anderen Cloud oder in einem On-Premises-Data-Center ausgeführt wird, verwenden Sie OCI FastConnect, um die Latenz für die Verbindung zu Ihrer OCI-Region zu reduzieren. Weitere Informationen finden Sie unter Überblick über FastConnect.

  2. Konfigurieren Sie das Netzwerkrouting in der Region, in der sich die Standbydatenbank befindet. Führen Sie diesen Schritt mehrmals aus, wenn mehrere regionsübergreifende Standbydatenbanken vorhanden sind.
    1. Wenn sich die Standbydatenbank auf einem öffentlichen Endpunkt befindet, konfigurieren Sie das Netzwerkrouting so, dass die Verbindung von den Clients in der Region, in der sich die regionsübergreifende Standbydatenbank befindet, über ein Servicegateway erfolgt.

      In den folgenden Themen finden Sie weitere Informationen:

    2. Wenn sich die Standbydatenbank auf einem privaten Endpunkt befindet, stellen Sie eine Verbindung zur Datenbank mit dem privaten Endpunkt her, der in Ihrem Netzwerk sichtbar ist, ohne dass ein Servicegateway konfiguriert werden muss.
  3. Verwenden Sie unidirektionale TLS-Verbindungen ohne Wallet.

    Wenn Sie One-Way-TLS für die Primärdatenbank konfiguriert haben, sind für Standbydatenbanken bereits On-Way-TLS konfiguriert. Sie müssen keine zusätzliche Konfiguration für regionsübergreifende Standbydatenbanken vornehmen.

  4. Konfigurieren Sie Ihre Clients und Mid-Tiers für die Verwendung von TCP Fast Open.

Konzeptionelles Netzwerkdiagramm für Datenbankverbindungen mit geringer Latenz

Zeigt das konzeptionelle Netzwerkdiagramm für Verbindungen mit geringer Latenz, die öffentliche Endpunkte und private Endpunkte für Ihre Datenbank verwenden.

Verbindungen mit geringer Latenz mit privatem Endpunkt und Anwendung, die innerhalb der OCI-Region ausgeführt wird

Beschreibung von adb-private-low-latency.eps folgt
Beschreibung der Abbildung adb-private-low-latency.eps

Verbindungen mit geringer Latenz mit öffentlichem Endpunkt und Anwendung, die innerhalb der OCI-Region ausgeführt wird

Beschreibung von adb-public-low-latency.eps folgt
Beschreibung der Abbildung adb-public-low-latency.eps

Verbindungen mit geringer Latenz über einen privaten Endpunkt mit Anwendung, die im On-Premise-Data Center ausgeführt wird und über FastConnect mit OCI verbunden ist

Beschreibung von adb-fastconnect-private-low-latency.eps folgt
Beschreibung der Abbildung adb-fastconnect-private-low-latency.eps

Verbindungen mit geringer Latenz über einen öffentlichen Endpunkt mit Anwendung, die in Ihrem On-Premise-Data Center ausgeführt wird und über FastConnect mit OCI verbunden ist

Beschreibung von adb-fastconnect-public-low-latency.eps folgt
Beschreibung der Abbildung adb-fastconnect-public-low-latency.eps