Considérations relatives aux réplicas RDS for Oracle - Amazon Relational Database Service

Considérations relatives aux réplicas RDS for Oracle

Avant de créer un réplica Oracle, tenez compte des exigences, restrictions et recommandations suivantes.

Considérations relatives aux versions et aux licences de RDS pour les réplicas Oracle

Avant de créer un réplica de RDS for Oracle, tenez compte des exigences, restrictions et recommandations suivantes :

  • Si le réplica est en mode lecture seule, assurez-vous que vous disposez d'une licence Active Data Guard. Si vous placez le réplica en mode monté, vous n'avez pas besoin d'une licence Active Data Guard. Seul le moteur Oracle DB prend en charge les réplicas montés.

  • Les réplicas Oracle sont pris en charge uniquement pour le moteur Oracle Enterprise Edition (EE).

  • Les réplicas Oracle sont disponibles pour les instances créées à l'aide de la version Oracle Database 12c Version 1 (12.1.0.2.v10) et les versions 12c supérieures, ainsi que pour les instances non CDB de Oracle Database 19c. Les réplicas de CDB ne sont pas prises en charge.

  • Les réplicas Oracle sont disponibles pour les instances de base de données exécutées uniquement sur des classes d'instance de base de données avec deux vCPU ou plus. Une instance de base de données source ne peut pas utiliser les classes d'instances db.t3.micro ou db.t3.small.

  • La version du moteur de base de données Oracle de l'instance de base de données source et tous ses réplicas doivent être identiques. Amazon RDS met à niveau les réplicas immédiatement après la mise à niveau de l'instance de base de données source, quelle que soit la fenêtre de maintenance d'un réplica. Pour les mises à niveau majeures de versions de réplicas inter-régions, Amazon RDS effectue automatiquement les opérations suivantes :

    • Génère un groupe d'options pour la version cible

    • Copie toutes les options et tous les paramètres d'option du groupe d'options d'origine vers le nouveau groupe d'options

    • Associe le réplica en lecture inter-région mis à niveau au nouveau groupe d'options

    Pour plus d'informations sur la mise à niveau de la version du moteur de base de données, veuillez consulter la section Mise à niveau du moteur de base de données RDS for Oracle.

Considérations sur les options pour les réplicas RDS for Oracle

Avant de créer un réplica de RDS for Oracle, tenez compte des exigences, restrictions et recommandations suivantes :

  • Si votre réplica Oracle se trouve dans la même région AWS que son instance de base de données source, assurez-vous qu'il appartient au même groupe d'options que l'instance de base de données source. Les modifications apportées au groupe d'options source ou à l'appartenance au groupe d'options source sont propagées aux réplicas. Ces modifications sont appliquées aux réplicas immédiatement après leur application à l'instance de base de données source, quelle que soit la fenêtre de maintenance du réplica.

    Pour plus d'informations sur les groupes d'options, consultez Utilisation de groupes d'options.

  • Lorsque vous créez un réplica Oracle inter-région, Amazon RDS crée un groupe d'options qui lui est dédié.

    Vous ne pouvez pas supprimer un réplica Oracle inter-région du groupe d'options qui lui est dédié. Aucune autre instance de base de données ne peut utiliser le groupe d'options dédié à un réplica Oracle inter-région.

    Vous pouvez uniquement ajouter ou supprimer les options non répliquées suivantes d'un groupe d'options dédié :

    • NATIVE_NETWORK_ENCRYPTION

    • OEM

    • OEM_AGENT

    • SSL

    Pour ajouter d'autres options à un réplica Oracle inter-région, ajoutez-les au groupe d'options de l'instance de base de données source. L'option est également installée sur tous les réplicas de l'instance de base de données source. Pour les options sous licence, assurez-vous qu'il existe suffisamment de licences pour les réplicas.

    Lorsque vous promouvez un réplica Oracle inter-région, le réplica promu se comporte de la même façon que d'autres instances de bases de données Oracle, y compris pour la gestion de ses options. Vous pouvez promouvoir un réplica explicitement ou implicitement en supprimant son instance de base de données source.

    Pour plus d'informations sur les groupes d'options, veuillez consulter Utilisation de groupes d'options.

Considérations sur la sauvegarde et la restauration des réplicas de RDS for Oracle

Avant de créer un réplica de RDS for Oracle, tenez compte des exigences, restrictions et recommandations suivantes :

  • Pour créer des instantanés des réplicas de RDS for Oracle ou activer les sauvegardes automatiques, veillez à définir manuellement la période de conservation des sauvegardes. Les sauvegardes automatiques ne sont pas activées par défaut.

  • L'heure de la base de données désigne la dernière heure de transaction appliquée des données dans la sauvegarde. Lorsque vous restaurez une sauvegarde de réplica, vous rétablissez l'heure de la base de données, et non l'heure à laquelle la sauvegarde a été effectuée. La différence est importante car un réplica peut être en retard de plusieurs minutes ou heures par rapport à l’instance principale.

    Pour identifier la différence, utilisez la commande describe-db-snapshots. Comparez le paramètre snapshotDatabaseTime, qui est l'heure de la base de données du réplica de sauvegarde, et le champ OriginalSnapshotCreateTime, qui est la dernière transaction appliquée sur la base de données principale.

Considérations diverses pour les réplicas RDS for Oracle

Avant de créer un réplica de RDS for Oracle, tenez compte des exigences, restrictions et recommandations suivantes :

  • Si une instance de base de données est une source pour un ou plusieurs réplicas inter-région, la base de données source conserve ses journaux redo archivés jusqu'à ce qu'ils soient appliqués dans tous les réplicas inter-régions. Les journaux redo archivés peuvent entraîner une augmentation de la consommation de stockage.

  • Un déclencheur de connexion sur une instance principale doit permettre l'accès à l'utilisateur RDS_DATAGUARD et à tout utilisateur dont la valeur AUTHENTICATED_IDENTITY est RDS_DATAGUARD ou rdsdb. En outre, le déclencheur ne doit pas définir le schéma actuel pour l'utilisateur RDS_DATAGUARD.

  • Pour éviter d'interrompre l'automatisation RDS, les déclencheurs système doivent permettre à des utilisateurs spécifiques de se connecter à la base de données primaire et de réplication. Les déclencheurs système incluent les déclencheurs DDL, les déclencheurs de connexion et les déclencheurs de rôle de base de données. Nous vous recommandons d'ajouter du code à vos déclencheurs pour exclure les utilisateurs répertoriés dans l'exemple de code suivant :

    -- Determine who the user is SELECT SYS_CONTEXT('USERENV','AUTHENTICATED_IDENTITY') INTO CURRENT_USER FROM DUAL; -- The following users should always be able to login to either the Primary or Replica IF CURRENT_USER IN ('master_user', 'SYS', 'SYSTEM', 'RDS_DATAGUARD', 'rdsdb') THEN RETURN; END IF;
  • Pour éviter de bloquer les connexions du processus de l'agent Data Guard, n'activez pas les sessions restreintes. Pour plus d'informations sur les sessions restreintes, consultez Activation et désactivation de sessions restreintes.

  • Le suivi des modifications de bloc est pris en charge pour les réplicas en lecture seule, mais pas pour les réplicas montés. Vous pouvez convertir un réplica monté en réplica en lecture seule, puis activer le suivi des modifications de bloc. Pour plus d'informations, consultez Activation et désactivation du suivi des modifications de bloc.