A propos d'Oracle Data Guard

Vous pouvez utiliser Oracle Data Guard sur un serveur 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 Enterprise.

Pour plus d'informations sur Oracle Data Guard, reportez-vous à Introduction à Oracle Data Guard.

Stratégie IAM requise

Pour utiliser Oracle Cloud Infrastructure, un administrateur doit vous accorder un accès sécurisé dans une stratégie. Cet accès est requis, que vous utilisiez la console ou l'API REST avec un kit SDK, une interface de ligne de commande ou un autre outil. Si un message vous indique que vous ne disposez pas des droits d'accès ou des autorisations nécessaires, vérifiez auprès de l'administrateur le type d'accès qui vous a été accordé et le compartiment dans lequel vous devez travailler.

Si vous ne connaissez pas les stratégies, reportez-vous à Introduction aux stratégies et à Stratégies courantes.

Rubriques connexes

Informations générales

La configuration Oracle Data Guard requiert au moins deux bases de donnée : une dans un rôle principal et une dans un rôle de secours. Les bases de données principale et de secours constituent une configuration Data Guard. La plupart des applications accèdent à la base de données principale. Une base de données de secours est une copie cohérente au point de vue transactionnel de la base de données principale.

Le groupe Data Guard 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, ce qui offre 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.

Pour tenir à jour la base de données de secours, Oracle Data Guard transmet les données redo à partir de la base de données principale et les applique. Si la base de données principale devient indisponible, vous pouvez utiliser Data Guard pour permuter la base de données de secours ou basculer la base de données de secours vers le rôle principal. Cela est vrai même si vous disposez de plusieurs bases de données de secours.
  • Permutation : la permutation inverse les rôles de la base de données principale et de secours.
  • Basculement : le basculement attribue au rôle principal la base de données de secours en temps d'échec ou d'inaccessibilité à la base de données principale existante.
  • Rétablissement : rétablit le rôle d'une base de donnée dans une configuration Data Guard en mode de secours.
Dans une configuration Data Guard standard, 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 située 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 pannes locales (telles que les pannes de base de données, de cluster ou de domaine de disponibilité). Dans ce cas, l'impact du basculement des applications est réduit, car les applications continuent à fonctionner sans la surcharge de performances liée à 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 requêtes en lecture seule. Une configuration de base de données de secours distante assure la protection des données contre les pannes régionales.

Certains clients professionnels recherchent 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, trois bases de données de secours sont disponibles. 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 fonctionnalités de secours de cliché (lecture/écriture).

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

Les détails supplémentaires des exigences sont les suivants :

  • Les versions et éditions de base de données doivent être identiques. Pour les bases de données 26ai, les bases de données principale et de secours doivent être sur la même version majeure, tandis que la base de données de secours peut être sur une version mineure supérieure.
  • Data Guard ne prend pas en charge Oracle Database Standard Edition. (Active Data Guard requiert Enterprise Edition 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ée par les autres bases de_données des systèmes de_données qui hébergent la configuration Data Guard. Toutefois, les bases de données principale et de secours peuvent utiliser la même valeur de nom de base de données (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 Enterprise Edition 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 Enterprise Edition Extreme Performance. Vous pouvez également utiliser Enterprise Edition ou Enterprise Edition High Performance, qui n'activent pas ADG par défaut. Reportez-vous à utilisation d'Oracle Data Guard avec l'interface de ligne de commande de base de données.
  • Si vos bases de données principale et de secours se trouvent dans la même région, elles doivent toutes deux utiliser le même réseau cloud virtuel.
  • Si les bases de données principale et de secours résident dans des régions différentes, vous devez appairer les réseaux cloud virtuels pour chaque base de données. Reportez-vous à Appairage à distance de réseaux cloud virtuels à l'aide d'une connexion d'appairage à distance.
  • 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 être identiques.
  • Une instance Data Guard inter-région est également prise en charge si la base de données utilise OCI Vault pour les clés TDE.

  • Configurez les règles entrantes et sortantes des listes de sécurité pour les sous-réseaux des systèmes de base de donnée dans une configuration Data Guard afin d'autoriser le trafic TCP entre les ports applicables. Veillez à créer des règles avec conservation de statut (valeur par défaut).

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

    Remarques :

    Les règles sortantes de l'exemple montrent comment activer le trafic TCP uniquement pour le port 1521. Il s'agit d'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 sortantes.
  • Les bases de données de secours dans OCI sont des bases de données 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 données 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 cryptée à l'aide d'OCI Vault. Cependant, 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égion pour les bases de données utilisant OCI Vault 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 une instance Data Guard inter-région, après une permutation, vous ne pouvez pas effectuer de rotation de la clé KMS de base de données sur la nouvelle base de données principale.
  • Dans une instance Data Guard inter-région, après une permutation, vous ne pouvez pas créer de base de données pluggable sur la nouvelle base de données principale.

Liste de sécurité pour le sous-réseau du 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é pour le sous-réseau du 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, reportez-vous à Listes de sécurité.

Remarques concernant le domaine de disponibilité et le domaine de pannes pour Oracle Data Guard

Oracle recommande de placer le système de base de données contenant la base de données de secours dans un domaine de disponibilité différent de celui du système de base de données contenant la base de données principale afin d'améliorer 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 données de secours se trouve dans le même domaine de disponibilité que la base de données principale (par choix ou si vous travaillez dans une seule région de domaine de disponibilité), Oracle recommande de placer la base de données de secours dans un domaine de pannes différent de celui de la base de données principale.

Remarques :

Si vos bases de données principale et de secours sont des bases de données Oracle RAC à deux nœuds et que toutes deux se trouvent dans le même domaine de disponibilité, seul l'un des deux nœuds de la base de données de secours peut se trouver dans un domaine de pannes qui n'inclut aucun autre nœud de la base de données principale ou de secours. Cela est dû au fait que chaque domaine de disponibilité ne dispose que de trois domaines de pannes, et que les bases de données principale et de secours disposent d'un total combiné de quatre noeuds. Pour plus d'informations sur les domaines de disponibilité et les domaines de pannes, reportez-vous à Régions et domaines de disponibilité.