Meilleures pratiques pour les connexions à faible latence avec Autonomous Database

Il est essentiel de prendre des mesures pour réduire la latence des connexions entre une application et Autonomous Database si votre application effectue de nombreux allers-retours entre l'application et la base de données.

Par exemple, envisagez une application OLTP qui se connecte à Autonomous Database et qui soumet des milliers d'instructions SQL à la base de données individuellement pour exécuter une commande client. Dans ce cas, l'application nécessite des milliers d'aller-retour, et la réduction de la latence pour chaque aller-retour peut considérablement accélérer le processus de commande client. Pour ces applications, vous pouvez appliquer les meilleures pratiques afin de réduire la latence des connexions de base de données.

Etapes de réduction de la latence pour les connexions de base de données

Vous pouvez suivre ces recommandations pour réduire la latence des connexions entre vos applications et la base de données.

Déterminez d'abord le domaine de disponibilité de la base de données. Pour rechercher le domaine de disponibilité d'une instance Autonomous Database, connectez-vous en tant qu'utilisateur ADMIN et exécutez la requête suivante :

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

Par exemple :

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

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

Vous pouvez également afficher les informations sur le domaine de disponibilité dans la console Oracle Cloud Infrastructure. Pour plus d'informations, reportez-vous à Visualisation des informations réseau sur la console OCI.

Pour réduire la latence, procédez comme suit :

  1. Placez les clients ou les serveurs de niveau intermédiaire dans le même domaine de disponibilité que l'instance Autonomous Database.

    Par exemple, si votre application est exécutée sur une machine virtuelle Oracle Cloud Infrastructure Compute, sélectionnez le même domaine de disponibilité que l'instance Autonomous Database lorsque vous créez l'instance de calcul.

    Si l'application s'exécute dans un autre cloud ou dans un centre de données sur site, utilisez OCI FastConnect pour réduire la latence de la connexion à votre région OCI. Pour plus d'informations, reportez-vous à Présentation de FastConnect.

  2. Configurez le routage réseau.
    • Si vous utilisez une instance Autonomous Database sur une adresse publique, configurez le routage réseau de sorte que la connexion entre le client et la base de données passe par une passerelle de service.

      Pour plus d'informations, reportez-vous à .

    • Si vous utilisez une instance Autonomous Database sur une adresse privée, vous vous connectez à la base de données à l'aide de l'adresse privée visible sur votre réseau, sans avoir à configurer une passerelle de service.

  3. Utilisez des connexions TLS unidirectionnelles sans portefeuille.

    Pour réduire la latence, il est recommandé de configurer l'instance Autonomous Database afin d'autoriser les connexions mTLS et TLS, et d'utiliser des connexions TLS pour connecter votre application à la base de données.

    Pour plus d'informations, reportez-vous à :

  4. Utilisez TCP Fast Open (TFO) pour vous connecter à la base de données.

Etapes pour réduire la latence des connexions de base de données pour les bases de données avec Autonomous Data Guard

Fournit les étapes à suivre pour configurer un environnement de secours Autonomous Data Guard, des clients et des niveaux intermédiaires, afin de réduire la latence des connexions de base de données lors de la connexion après un basculement ou après une permutation (lorsque la base de données de secours devient la base de données principale).

Réduire la latence des connexions de base de données avec Autonomous Data Guard local

Suivez ces étapes pour réduire la latence des connexions de base de données que vous effectuez lorsque vous utilisez Autonomous Data Guard et que vous effectuez un basculement ou une permutation vers une base de données de secours locale.

Si vous disposez d'une base de données de secours locale Autonomous Data Guard et que vous résidez dans une région comportant plusieurs domaines de disponibilité, Autonomous Data Guard crée la base de données de secours locale dans un autre domaine de disponibilité. Lorsque vous effectuez un basculement ou une permutation vers la base de données de secours, la base de données de secours locale devient la base principale. Pour préparer un basculement ou une permutation, il est recommandé d'activer les clients de secours et les niveaux intermédiaires afin que vos applications puissent continuer à travailler en cas de panne du domaine de disponibilité après une panne ou après une permutation.

Vérifiez d'abord que le type de récupération après sinistre de votre homologue local est Autonomous Data Guard. Pour plus d'informations, reportez-vous à Activation d'Autonomous Data Guard.

Effectuez les tâches suivantes afin de configurer les clients de secours et les niveaux intermédiaires pour une faible latence lorsque vous utilisez Autonomous Data Guard avec une base de données de secours locale dans une région avec plusieurs domaines de disponibilité.

  1. Placez les clients de secours ou les niveaux intermédiaires dans le même domaine de disponibilité que la base de données de secours locale (tous les composants doivent être configurés pour utiliser le même domaine de disponibilité).

    Par exemple, si votre application est exécutée sur une machine virtuelle Oracle Cloud Infrastructure Compute, lorsque vous créez l'instance de calcul, sélectionnez le même domaine de disponibilité pour la machine virtuelle Compute que la base de données de secours. La configuration de récupération après sinistre est ainsi préparée de sorte que la base de données de secours et la machine virtuelle de calcul de secours utilisent le même domaine de disponibilité après un basculement ou une permutation. Cela permet de réduire la latence des connexions à la base de données par rapport à une configuration dans laquelle les composants utilisent des domaines de disponibilité différents.

    Pour déterminer le domaine de disponibilité de la base de données de secours, connectez-vous à la base de données principale en tant qu'utilisateur ADMIN et exécutez l'interrogation suivante :

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

    Par exemple, cette commande affiche le domaine de disponibilité d'une base de données de secours locale :

    AVAILABILITY_DOMAIN 
    ------------------- 
    SoSC:US-ASHBURN-AD-3
  2. Vous n'avez pas besoin d'effectuer de configuration réseau supplémentaire ni d'autoriser des connexions TLS unidirectionnelles pour la base de données de secours locale. Une base de données de secours locale a la même configuration réseau de configuration que la base de données principale.
  3. Configurez vos clients et les niveaux intermédiaires pour utiliser TCP Fast Open.

Réduire la latence des connexions de base de données avec Autonomous Data Guard inter-région

Suivez ces étapes pour réduire la latence des connexions de base de données que vous établissez lorsque vous utilisez Autonomous Data Guard et que vous effectuez un basculement ou une permutation vers une base de données de secours inter-région.

Si vous ajoutez des bases de données de secours Autonomous Data Guard inter-région, les bases de données de secours inter-région sont ajoutées dans les régions que vous sélectionnez lorsque vous ajoutez un homologue inter-région. Lorsque vous effectuez un basculement ou une permutation vers une base de données de secours Autonomous Data Guard inter-région, la base de données de secours inter-région devient la base de données principale. Pour préparer un basculement ou une permutation régional, il est recommandé de disposer de clients de secours et de niveaux intermédiaires dans la région distante. Cela prépare les clients et le niveau intermédiaire de la région distante de sorte qu'en cas de panne ou après une permutation, vos applications puissent continuer à fonctionner.

Vérifiez d'abord que la récupération après sinistre inclut au moins une base de données de secours Autonomous Data Guard inter-région. Pour plus d'informations, reportez-vous à Ajout d'une base de données de secours inter-région.

Suivez ces étapes pour configurer les clients et les niveaux intermédiaires pour une faible latence lors de l'utilisation d'Autonomous Data Guard avec des bases de données de secours inter-région.

  1. Placez les clients de secours ou les niveaux intermédiaires dans le même domaine de disponibilité que les bases de données de secours inter-région.

    Pour déterminer les domaines de disponibilité des bases de données de secours Autonomous Data Guard inter-région, connectez-vous à la base de données principale en tant qu'utilisateur ADMIN et exécutez la requête suivante :

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

    Par exemple, lorsque vous disposez de deux bases de données de secours inter-région, l'exécution de cette commande affiche les domaines de disponibilité de chaque base de données de secours inter-région :

    AVAILABILITY_DOMAIN    
    ---------------------- 
    SoSC:PHX-AD-3          
    SoSC:US-SANJOSE-1-AD-1 
    1. Si vous disposez d'une base de données de secours inter-région, l'interrogation affiche un seul domaine de disponibilité. Placez les clients de secours et les niveaux intermédiaires dans la même région et utilisez le même domaine de disponibilité que la base de données de secours inter-région.

      Par exemple, si votre application est exécutée sur une machine virtuelle Oracle Cloud Infrastructure Compute, lorsque vous créez l'instance de calcul, sélectionnez le même domaine de disponibilité pour la machine virtuelle Compute que la base de données de secours Autonomous Data Guard. Ainsi, la base de données de secours inter-région et la machine virtuelle de calcul de secours se trouvent dans la même région et utilisent le même domaine de disponibilité après un basculement ou une permutation.

    2. Si vous disposez de plusieurs bases de données de secours inter-région, dans chaque région, utilisez le domaine de disponibilité approprié qui correspond à la région et au domaine de disponibilité pour chaque base de données de secours correspondante. Vous devrez effectuer cette configuration plusieurs fois (tous les composants d'une région doivent utiliser le même domaine de disponibilité que la base de données de secours Autonomous Data Guard).

    Si l'application s'exécute dans un autre cloud ou dans un centre de données sur site, utilisez OCI FastConnect pour réduire la latence de la connexion à votre région OCI. Pour plus d'informations, reportez-vous à la section FastConnect Overview.

  2. Configurez le routage réseau dans la région où réside la base de données de secours. Effectuez cette étape plusieurs fois si vous disposez de plusieurs bases de données de secours inter-région.
    1. Si la base de données de secours se trouve sur une adresse publique, configurez le routage réseau de sorte que la connexion à partir des clients de la région où se trouve la base de données de secours inter-région passe par une passerelle de service.
    2. Si la base de données de secours se trouve sur une adresse privée, vous pouvez vous connecter à la base de données à l'aide de l'adresse privée visible sur le réseau, sans avoir à configurer une passerelle de service.
  3. Utilisez des connexions TLS unidirectionnelles sans portefeuille.

    Si vous avez configuré le protocole TLS unidirectionnel pour la base de données principale, le protocole TLS unidirectionnel est déjà configuré pour les bases de données de secours. Vous n'avez pas besoin d'effectuer de configuration supplémentaire sur les bases de données de secours inter-région.

  4. Configurez vos clients et les niveaux intermédiaires pour utiliser TCP Fast Open.

Diagramme de réseau conceptuel pour les connexions de base de données à faible latence

Affiche le diagramme de réseau conceptuel pour les connexions à faible latence utilisant des adresses publiques et privées pour votre base de données.

Connexions à faible latence utilisant une adresse privée avec une application exécutée dans la région OCI

Description de l'image adb-private-low-latency.eps
Description de l'image adb-private-low-latency.eps

Connexions à faible latence utilisant une adresse publique avec une application exécutée dans la région OCI

Description de l'image adb-public-low-latency.eps ci-après
description de l'illustration adb-public-low-latency.eps,

Connexions à faible latence à l'aide d'une adresse privée avec une application exécutée dans un centre de données sur site connecté à OCI à l'aide de FastConnect

Description de l'image adb-fastconnect-private-low-latency.eps
Description de l'image adb-fastconnect-private-low-latency.eps

Connexions à faible latence à l'aide d'une adresse publique avec une application exécutée dans votre centre de données sur site connecté à OCI à l'aide de FastConnect

Description de l'image adb-fastconnect-public-low-latency.eps
Description de l'image adb-fastconnect-public-low-latency.eps