Principes de base du Data Guard d'Oracle 12c Data Guard - nuls

Data Guard est la véritable technologie de protection contre les sinistres d'Oracle 12c. Dans celui-ci, vous avez un minimum de deux bases de données, primaire et en veille. Data Guard propose des options pour plusieurs sites de secours ainsi qu'une configuration active-active .

Par actif-actif, cela signifie que tous les sites sont actifs, en cours d'exécution et accessibles. Ceci est contraire aux sites qui ont un emplacement actif et les autres doivent être démarrés quand ils sont nécessaires. Ceci est un exemple de la disposition architecturale générale.

L'architecture de Data Guard et Oracle 12c

Démarrer une description avec la base de données primaire est facile car elle diffère très peu des autres bases de données que vous pourriez avoir. La seule différence est ce qu'il fait avec ses journaux de redo archivés.

La base de données primaire écrit un ensemble de journaux de restauration d'archive dans une zone de récupération Flash ou un disque local. Toutefois, vous pouvez configurer une ou plusieurs autres destinations dans un environnement Data Guard.

Le paramètre LOG_ARCHIVE_DEST_n peut ressembler à ceci pour la configuration précédente:

LOG_ARCHIVE_DEST_10 = 'LOCATION = USE_DB_RECOVERY_FILE_DEST' LOG_ARCHIVE_DEST_1 = "SERVICE = ARCH PHYSDBY1" LOG_ARCHIVE_DEST_2 = "SERVICE = LOGSDBY1 LGWR"

LOG_ARCHIVE_DEST_10 est configuré pour envoyer des journaux de restauration d'archive à la zone de récupération Flash locale. Une destination locale est requise pour toutes les bases de données en mode journal d'archivage.
LOG_ARCHIVE_DEST_1 est configuré pour envoyer les journaux d'archives via le processus d'archivage à un site distant PHYSDBY1. Le nom du service pour ce site distant a une entrée dans les noms tns. ou un fichier sur le serveur principal.
LOG_ARCHIVE_DEST_2 est configuré pour envoyer les journaux d'archivage via le processus LGWR à un site distant nommé LOGSDBY1. Le nom du service pour ce site distant a une entrée dans les noms tns. ou un fichier sur le serveur principal.

Pourquoi la différence entre les méthodes d'expédition ARCn et LGWR? Cela a quelque chose à voir avec les modes de protection. Un environnement Data Guard a trois modes de protection.

Disponibilité maximale

Le mode de protection de disponibilité maximale fait des compromis entre les performances et la disponibilité des données. Il fonctionne en utilisant le LGWR pour écrire simultanément sur les journaux de reprise sur les sites principal et de secours. La dégradation des performances se présente sous la forme de processus devant attendre que les entrées de journalisation soient écrites à plusieurs emplacements.

Les sessions qui émettent des validations doivent attendre que toutes les informations nécessaires aient été enregistrées dans au moins un journal de reprise de la base de données en attente. Si une session se bloque en raison de son incapacité à écrire des informations de rétablissement, le reste de la base de données continue d'avancer.

Protection maximale

Le mode de protection maximale est similaire à la disponibilité maximale, sauf que si une session ne peut pas vérifier que l'opération de rétablissement est écrite sur le site distant, la base de données primaire s'arrête.

Configurez au moins deux sites de secours pour le mode de protection maximale. De cette façon, un site en attente devenant indisponible ne perturbera pas le service pour l'ensemble de l'application.

Ce mode vérifie qu'aucune perte de données ne se produira en cas de sinistre au détriment des performances.

Performances maximales

Le mode de protection maximale des performances détache le processus d'envoi de journaux de la base de données principale en le transmettant au processus d'archivage (ARCn). En faisant cela, toutes les opérations sur le site principal peuvent continuer sans attendre que les entrées de rétablissement soient écrites pour refaire les journaux ou refaire l'expédition.

Ceci est contraire aux modes d'envoi de journaux qui utilisent le consignateur de journaux pour transférer des transactions. L'utilisation de l'enregistreur de journal peut ralentir le traitement de la transaction, car elle peut être affectée par la disponibilité ou les performances du réseau.

Les performances maximales offrent le niveau de performances le plus élevé sur le site principal au détriment de la divergence des données. La divergence des données se produit lorsque les données des deux sites commencent à être désynchronisées. Les données de reprise d'archivage ne sont pas envoyées tant qu'un journal de restauration d'archive complet n'est pas plein. Dans le pire des cas, une perte de site entière peut entraîner la perte de la totalité des données d'un journal d'archivage.

Opérations de basculement et de basculement

Vous pouvez basculer le traitement vers votre site de secours de deux manières:

Le basculement est un basculement planifié qui peut se produire si vous souhaitez effectuer une maintenance sur le site principal qui en a besoin. être indisponible. Cette opération peut nécessiter quelques minutes d'indisponibilité dans l'application, mais si vous devez effectuer une maintenance qui dure une heure ou plus, les temps d'arrêt peuvent en valoir la peine.

Cette opération est appelée commutation gracieuse , car elle transforme le site principal en site de secours et votre site de secours en site principal. En outre, vous pouvez facilement revenir au site principal d'origine sans avoir à le recréer à partir de zéro.
Le basculement se produit lorsque le site principal a été compromis d'une manière ou d'une autre. Peut-être que c'était une perte totale de site, ou peut-être que vous avez découvert la corruption physique dans un fichier de données. Pas toujours, mais généralement après un basculement, vous devez entièrement recréer le site principal ou le récupérer à partir d'une sauvegarde et le réinstaller.

Vous effectuez généralement un basculement uniquement lorsque vous avez déterminé que la correction du site principal prendra suffisamment de temps pour que vous préfériez ne pas avoir d'interruption de l'application pendant tout le temps.

Pour effectuer une permutation, procédez comme suit:

Sur le serveur principal actuel, connectez-vous à SQL * Plus et tapez:
Vous devriez voir ceci:
```
Base de données modifiée.
```

Arrêtez la base de données primaire:

Vous devriez voir ceci:

La base de données est fermée. Base de données démontée. L'instance ORACLE s'est arrêtée.

Démarrez la base de données primaire en mode nom:

Vous devriez voir quelque chose comme ceci:

L'instance ORACLE a démarré.Taille totale du système 789172224 octets Taille fixe 2148552 octets Taille de variable 578815800 octets Tampons de base de données 201326592 octets Rétablir tampons 6881280 octets

Monter la base de données en mode veille:
Vous devriez voir ceci:
```
Base de données modifiée.
```
Démarrer la récupération:
Vous voyez ceci:
```
Récupération du média terminée.
```
Connectez-vous à SQL * Plus sur le mode de veille actuel et tapez ce qui suit:
Vous devriez voir ceci:
```
Base de données modifiée.
```

Arrêtez la base de données en attente:

Vous devriez voir ceci:

La base de données est fermée. Base de données démontée. L'instance ORACLE s'est arrêtée.

Assurez-vous que tous les paramètres d'initialisation appropriés sont définis pour que cette base de données se comporte correctement comme primaire.

Commencez normalement:

Vous devriez voir quelque chose comme ceci:

L'instance ORACLE a démarré. Zone globale du système 789172224 octets Taille fixe 2148552 octets Taille de la variable 578815800 octets Tampons de la base de données 201326592 octets Rétablir les tampons 6881280 octets Base de données montée. Base de données ouverte