À propos d'Oracle Data Guard

Vous pouvez utiliser Oracle Data Guard sur un système de base de données. Oracle Data Guard garantit la haute disponibilité, la protection des données et la récupération après sinistre des données d'entreprise.

Pour plus d'informations sur Oracle Data Guard, voir Présentation d'Oracle Data Guard.

Politique GIA requise

Pour que vous puissiez utiliser Oracle Cloud Infrastructure, un administrateur doit vous accorder un accès de sécurité au moyen d'une politique. Cet accès est requis que vous utilisiez la console ou l'API REST avec une trousse SDK, l'interface de ligne de commande ou un autre outil. Si vous obtenez un message indiquant que vous ne disposez pas de l'autorisation requise, vérifiez auprès de l'administrateur le type d'accès qui vous a été octroyé et le compartiment à utiliser.

Pour en connaître davantage sur les politiques, voir Introduction aux politiques et Politiques communes.

Rubriques connexes

Informations générales

La configuration d'Oracle Data Guard nécessite au moins deux bases de données : une base principale et une base de secours. Les bases de données principale et de secours constituent ensemble une configuration Data Guard. La plupart des applications accèdent à la base principale. Une base de données de secours est une copie cohérente sur le plan transactionnel de la base principale.

Data Guard Group permet de créer et de gérer plusieurs bases de données de secours locales et distantes liées à une base de données principale, offrant ainsi une flexibilité pour la protection des données et la récupération après sinistre. Dans un groupe Data Guard, une base de données principale peut prendre en charge jusqu'à six bases de données de secours.

Oracle Data Guard tient à jour la base de données de secours en transmettant et en appliquant des données de journalisation provenant de la base de données principale. Si la base de données principale n'est plus disponible, vous pouvez utiliser Data Guard pour permuter ou basculer la base de données de secours vers le rôle de base principale. Cela est vrai même si vous disposez de plusieurs bases de données de secours.
  • Permutation : Une permutation inverse les rôles de base de données principale et de base de secours.
  • Basculement : Un basculement fait passer la base de données de secours au rôle principal après l'échec ou l'inaccessibilité de la base de données principale existante.
  • Remettre en service : Remet en service une base de données dans le rôle de secours dans une configuration Data Guard.
Dans une configuration Data Guard classique, deux bases de données de secours sont couramment utilisées :
  • Base de données de secours locale : Une base de données de secours dans la même région que la base de données de production est idéale pour les scénarios de basculement, sans perte de données pour les défaillances locales (telles que les défaillances de base de données, de grappe ou de domaine de disponibilité). Dans ce cas, l'incidence du basculement d'application est réduite, car les applications continuent de fonctionner sans que les performances ne soient affectées par la communication avec une région distante.
  • Base de données de secours distante (inter-région) : Une base de données de secours distante, située dans une autre région, est généralement utilisée pour la récupération après sinistre ou pour décharger le traitement des interrogations en lecture seule. Une configuration de base de données de secours distante assure la protection des données contre les défaillances régionales.

Certains clients d'entreprise cherchent la symétrie après un changement de site. Par exemple, ils peuvent préférer avoir la base de données de secours principale et locale dans la région 1, et une base de données de secours distante avec sa propre base de données de secours locale dans la région 2. Dans cette configuration, il y aura trois bases de données de secours. Après un changement de site, vous disposez toujours d'une base de données principale et d'une base de données de secours locale facilement disponibles dans la nouvelle région principale.

En outre, vous pouvez améliorer leurs configurations en ajoutant une autre base de données de secours à des fins de test, en tirant parti de nos capacités de secours instantanée (lecture/écriture).

Une configuration Data Guard nécessite au moins deux systèmes de base de données, l'un contenant la base principale et l'autre la base de secours. Lorsque vous activez Data Guard pour une base de données, un nouveau système de BD avec la base de secours est créé et associé à la base principale.

Voici d'autres détails sur les exigences :

  • Les versions et les éditions de base de données doivent être identiques. Pour les bases de données 26ai, les bases principale et de secours doivent avoir la même version majeure, alors que la base de secours peut avoir une version mineure supérieure.
  • Data Guard ne prend pas en charge Oracle Database Édition Standard. (Active Data Guard requiert l'édition Enterprise - Extreme Performance.)
  • Chaque base de données d'une configuration Data Guard doit avoir un nom unique (DB_UNIQUE_NAME) qui n'est pas utilisé par d'autres bases de données des systèmes de base de données qui hébergent la configuration Data Guard. Toutefois, la base de données principale et la base de secours peuvent utiliser la même valeur DB_NAME.
  • L'édition de la base de données détermine si Active Data Guard (ADG) peut être utilisé. ADG n'est disponible qu'avec l'édition Enterprise - Extreme Performance. Si vous utilisez le modèle de licence BYOL et que votre licence n'inclut pas ADG, vous devez vous assurer qu'ADG n'est pas activé lors de la configuration de Data Guard pour l'édition Enterprise - Extreme Performance. Vous pouvez également utiliser l'édition Enterprise ou l'édition Enterprise - High Performance, ce qui n'active pas ADG par défaut. Voir Utiliser Oracle Data Guard avec l'interface de ligne de commande de la base de données.
  • Si vos bases de données principale et de secours se trouvent dans la même région, elles doivent utiliser le même réseau en nuage virtuel (VCN).
  • Si les bases de données principale et de secours se trouvent dans des régions différentes, vous devez appairer les réseaux en nuage virtuels pour chaque base de données. Voir Appairage distant de réseaux en nuage virtuels à l'aide d'une connexion d'appairage distant.
  • Les bases de données principale et de secours peuvent se trouver dans une région différente, mais elles doivent se trouver dans le même domaine.
  • Le mot de passe SYS et le mot de passe du portefeuille TDE des bases de données principale et de secours doivent tous être identiques.
  • Data Guard inter-régions est également pris en charge si la base de données utilise le service de chambre forte OCI pour les clés TDE.

  • Configurez les règles de trafic entrant et sortant de la liste de sécurité pour les sous-réseaux des systèmes de base de données dans une configuration Data Guard afin de permettre au trafic TCP de se déplacer entre les ports applicables. Assurez-vous que les règles que vous créez sont avec état (valeur par défaut).

    Par exemple, si le sous-réseau du système de BD de la base de données principale utilise le CIDR source 10.0.0.0/24 et que celui du système de la base de données de secours utilise le CIDR source 10.0.1.0/24, créez les règles présentées dans l'exemple suivant.

    Note :

    Les règles de trafic sortant de l'exemple montrent comment activer le trafic TCP pour le port 1521 uniquement, ce qui est une exigence minimale pour que Data Guard fonctionne. Si le trafic TCP est déjà activé sur tous vos ports sortants (0.0.0.0/0), vous n'avez pas besoin d'ajouter explicitement ces règles de trafic sortant.
  • Les bases de données de secours dans OCI sont des bases de secours physiques.
  • La création d'une base de données de secours associée à une autre base de données de secours ("base de secours en cascade") n'est pas prise en charge.
  • Vous pouvez créer une configuration Data Guard lorsque la base de données est chiffrée à l'aide du service de chambre forte OCI. Toutefois, OCI Vault prend actuellement en charge la réplication de clé vers une seule région distante. Par conséquent, les configurations Data Guard inter-régions pour les bases de données utilisant le service de chambre forte OCI sont limitées à deux régions : la région principale et une région distante. Plusieurs bases de données de secours peuvent être créées dans ces régions, mais les configurations couvrant au moins trois régions ne sont pas prises en charge.

Problèmes connus

  • Dans Data Guard inter-régions, après une permutation, vous ne pouvez pas effectuer la rotation de la clé KMS de base de données sur la nouvelle base principale.
  • Dans Data Guard inter-régions, après une permutation, vous ne pouvez pas créer de base de données enfichable sur la nouvelle base principale.

Liste de sécurité du sous-réseau sur le système de base de données principale 

Ingress Rules:
	Stateless: No
	Source: 10.0.1.0/24
	IP Protocol: TCPSource Port Range: All 
	Destination Port Range: 1521
	Allows: TCP traffic for ports: 1521

Egress Rules:
	Stateless: No
	Destination: 10.0.1.0/24 
	IP Protocol: TCP 
	Source Port Range: All
	Destination Port Range: 1521
	Allows: TCP traffic for ports: 1521

Liste de sécurité du sous-réseau sur le système de base de données de secours 

Ingress Rules:	
	Stateless: No
	Source: 10.0.0.0/24 
	IP Protocol: TCP 
	Source Port Range: All 
	Destination Port Range: 1521
	Allows: TCP traffic for ports: 1521

Egress Rules:
	Stateless: No
	Destination: 10.0.0.0/24 
	IP Protocol: TCP 
	Source Port Range: All
	Destination Port Range: 1521
	Allows: TCP traffic for ports: 1521

Pour plus d'informations sur la création et la modification de règles, voir Listes de sécurité.

Oracle Data Guard - Points à considérer pour les domaines de disponibilité et d'erreur

Oracle recommande que le système de BD qui contient la base de données de secours se trouve dans un domaine de disponibilité différent de celui qui contient la base principale, afin d'optimiser la disponibilité et la récupération après sinistre. Si vous activez Oracle Data Guard pour une base de données et que votre base de secours se trouve dans le même domaine de disponibilité que la base principale (par choix ou parce que vous travaillez dans un région à un seul domaine de disponibilité), Oracle vous conseille de placer la base de secours dans un domaine d'erreur différent de celui de la base de données principale.

Note :

Si la base principale et la base de secours sont des bases de données Oracle RAC à deux noeuds et qu'elles se trouvent dans le même domaine de disponibilité, un seul des deux noeuds de la base de secours peut se trouver dans un domaine d'erreur qui n'inclut aucun autre noeud de base principale ou de secours. En effet, chaque domaine de disponibilité ne comprend que trois domaines d'erreur, et les bases de données principale et de secours ont un total de quatre noeuds. Pour plus d'informations sur les domaines de disponibilité et les domaines d'erreur, voir Régions et domaines de disponibilité.