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 von entscheidender Bedeutung, 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 Reduzierung der Latenz für jede 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 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;

Beispiele:

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

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

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

So reduzieren Sie die Latenz:

  1. Platzieren Sie Clients oder die 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 wie die Autonomous Database-Instanz aus.

    Wenn die Anwendung in einer anderen Cloud oder in einem On-Premise-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 FastConnect Overview.

  2. Konfigurieren Sie das Netzwerkrouting.

    • Wenn Sie eine Autonomous Database-Instanz an 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 mit dem in Ihrem Netzwerk sichtbaren privaten Endpunkt eine Verbindung zur Datenbank her, ohne dass ein Servicegateway konfiguriert werden muss.

  3. Verwenden Sie einseitige 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 stellen Sie mit TLS-Verbindungen eine Verbindung Ihrer Anwendung zur Datenbank her.

    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

Enthält Schritte zur Konfiguration einer Autonomous Data Guard-Standbydatenbankumgebung, -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

Reduzieren Sie die Latenz für Datenbankverbindungen mit Local Autonomous Data Guard

Führen Sie diese Schritte aus, um die Latenz für die Datenbankverbindungen zu reduzieren, die Sie herstellen, wenn Sie Autonomous Data Guard verwenden und entweder Failover oder Switchover zu einer lokalen Standbydatenbank ausführen.

Wenn Sie eine lokale Autonomous Data Guard-Standbydatenbank haben und sich in einer Region mit mehreren Availability-Domains befinden, erstellt Autonomous Data Guard die lokale Standbydatenbank in einer anderen Availability-Domain. Wenn Sie ein Failover oder Switchover zur Standbydatenbank durchführen, wird die lokale Standbydatenbank zur Primärdatenbank. Zur Vorbereitung auf ein Failover oder Switchover wird empfohlen, Standbyclients und Mid-Tiers zur Aktivierung zur Verfügung zu haben. So können Ihre Anwendungen nach einem Fehler oder nach einem Switchover bei einem Ausfall der Availability-Domain weiterarbeiten.

Stellen Sie zunächst sicher, dass der Disaster Recovery-Typ für den 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 eine 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 für die Verwendung derselben Availability-Domain konfiguriert sein).

    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 reduziert, bei der die Komponenten unterschiedliche Availability-Domains verwenden.

    Um die Availability-Domain der Standbydatenbank 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 = '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 einseitige TLS-Verbindungen für die lokale Standbydatenbank zulassen. Eine lokale Standbydatenbank hat dieselbe Setupnetzwerkkonfiguration wie die Primärdatenbank.
  3. Konfigurieren Sie Ihre Clients und Mid-Tiers für die Verwendung von TCP Fast Open.

Reduzieren Sie die 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 herstellen, wenn Sie Autonomous Data Guard verwenden und entweder ein Failover oder ein Switchover zu einer regionsübergreifenden Standbydatenbank ausführen.

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 beim Hinzufügen eines regionsübergreifenden Peers auswählen. Wenn Sie einen Failover oder Switchover zu einer regionsübergreifenden Autonomous Data Guard-Standbydatenbank ausführen, wird die regionsübergreifende Standbydatenbank zur Primärdatenbank. Zur Vorbereitung auf ein regionales Failover oder Switchover wird empfohlen, Standbyclients und Mid-Tiers in der Remoteregion verfügbar zu haben. Dadurch werden die Clients und die Middle Tier in der Remote-Region so vorbereitet, dass Ihre Anwendungen im Falle eines Fehlers oder nach einem Switchover weiter funktionieren können.

Stellen Sie zunächst sicher, dass das 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 Standbyclients 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, stellen Sie als ADMIN-Benutzer eine Verbindung zur Primärdatenbank her, 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 Standbyclients 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 wie die Autonomous Data Guard-Standbydatenbank aus. Dadurch wird sichergestellt, dass sich die regionsübergreifende Standbydatenbank und die Standby-Compute-VM in derselben Region befinden und dieselbe Availability-Domain nach einem Failover oder Switchover verwenden.

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

    Wenn die Anwendung in einer anderen Cloud oder in einem On-Premise-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 FastConnect Overview.

  2. Konfigurieren Sie das Netzwerkrouting in der Region, in der sich die Standbydatenbank befindet. Führen Sie diesen Schritt mehrmals aus, wenn Sie über mehrere regionsübergreifende Standbydatenbanken verfügen.
    1. Wenn sich die Standbydatenbank an 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 mit dem in Ihrem Netzwerk sichtbaren privaten Endpunkt eine Verbindung zur Datenbank her, ohne dass ein Servicegateway konfiguriert werden muss.
  3. Verwenden Sie einseitige TLS-Verbindungen ohne Wallet.

    Wenn Sie unidirektionale TLS für die Primärdatenbank konfiguriert haben, ist für Standbydatenbanken bereits eine unidirektionale TLS konfiguriert. Sie müssen keine zusätzliche Konfiguration für regionsübergreifende Standbydatenbanken ausführen.

  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 mit öffentlichen Endpunkten und privaten Endpunkten für die Datenbank an.

Verbindungen mit geringer Latenz über privaten Endpunkt mit Anwendung, die in 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 über öffentlichen Endpunkt mit Anwendung, die in 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 einer Anwendung, die im On-Premise-Data Center ausgeführt wird und mit 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 einer Anwendung, die in Ihrem mit OCI verbundenen On-Premise-Data Center mit FastConnect ausgeführt wird

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