Skip to main content
Enterprise applications
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Récupération automatique Oracle sans mode de sauvegarde

PDF

La sauvegarde et la restauration par instantanés sont devenues encore plus simples avec la sortie d'Oracle 12c, car il n'est plus nécessaire de placer la base de données en mode de sauvegarde à chaud. Il est ainsi possible de planifier des sauvegardes par instantanés directement sur le système de stockage.

Les administrateurs de bases de données maîtrisent mieux la procédure de restauration à partir d'une sauvegarde à chaud, mais il est depuis longtemps possible d'utiliser des snapshots qui n'ont pas été créés pendant que la base de données était en mode de sauvegarde à chaud. Pour assurer la cohérence de la base de données, des étapes manuelles supplémentaires ont été nécessaires avec Oracle 10g et 11g. Avec Oracle 12c, sqlplus et rman contiennent la logique supplémentaire permettant de relire les journaux d'archivage sur des sauvegardes de fichiers de données qui n'étaient pas en mode de sauvegarde à chaud.

Comme nous l'avons vu précédemment, la restauration d'une sauvegarde à chaud basée sur des snapshots nécessite deux jeux de données :

  • Un Snapshot des fichiers de données créés en mode de sauvegarde

  • Les journaux d'archivage générés pendant que les fichiers de données étaient en mode de sauvegarde à chaud

Lors de la restauration, la base de données lit les métadonnées à partir des fichiers de données pour sélectionner les journaux d'archivage requis à des fins de restauration.

La récupération automatique sans mode de sauvegarde nécessite des ensembles de données légèrement différents pour obtenir les mêmes résultats :

  • Un snapshot des fichiers de données.

  • Un ensemble synchronisé de journaux d'archivage, de fichiers de contrôle et de journaux de restauration. Les journaux d'archivage doivent inclure tous les enregistrements depuis la création de l'instantané du fichier de données, alors faites attention à un élagage trop agressif des journaux.

Lors de la récupération, la base de données lit les métadonnées des fichiers de données pour identifier les enregistrements de journal nécessaires et rejoue toutes les transactions enregistrées.

REMARQUE :

Cette approche permet d'approximer une restauration à un point précis dans le temps, mais avec une granularité limitée. Par exemple, si vous commencez avec des fichiers de données en mode sauvegarde, vous pouvez faire avancer la base de données jusqu'à n'importe quelle transaction.

Si vous utilisez la méthode de récupération automatique, sans utiliser le mode de sauvegarde, vous devez restaurer la base de données jusqu'au point de l'instantané du journal. Dans des circonstances normales, le RPO resterait nul car les journaux d'archive, les journaux de restauration et les fichiers de contrôle d'origine seraient toujours disponibles dans le système de fichiers actif. Si une récupération devait être effectuée entièrement à partir d'instantanés en raison de la perte de toutes les données dans les systèmes de fichiers actifs, alors le RPO serait d'une heure.

== Organisation des données La disposition la plus simple consiste à isoler les fichiers de données dans des volumes dédiés, des LUN ou des espaces de noms NVMe. Les ressources de stockage doivent être exemptes de tout autre type de fichier. Cela permet de s'assurer que les fichiers de données peuvent être rapidement restaurés grâce à une opération SnapRestore sans détruire un journal de reprise, un fichier de contrôle ou un journal d’archivage important.

Les SAN ont des exigences similaires en matière d'isolation des fichiers de données au sein de ressources dédiées. Avec un système d'exploitation tel que Microsoft Windows utilisant le stockage AFF, un seul volume peut contenir plusieurs LUN de fichiers de données, chacune avec un système de fichiers NTFS. Avec d'autres systèmes d'exploitation, il existe généralement un gestionnaire de volumes logiques. Par exemple, avec Oracle ASM, l'option la plus simple consiste à regrouper les LUN d'un groupe de disques ASM sur un seul volume pouvant être sauvegardé et restauré comme une seule unité. Si des volumes supplémentaires sont nécessaires pour des raisons de performance ou de gestion de la capacité, la création d'un groupe de disques supplémentaire sur ce nouveau volume simplifie la gestion.

ASA ne propose pas d'abstraction au niveau du volume. Il utilise plutôt des groupes de cohérence. Dans de nombreux cas, un seul LUN ou espace de noms NVMe suffit aux exigences de gestion et de performance d'une base de données. Si plusieurs LUN ou espaces de noms sont nécessaires, des ressources supplémentaires peuvent être ajoutées et regroupées au sein d'un groupe de cohérence qui devient le conteneur des fichiers de données.

Si ces instructions sont respectées, les instantanés peuvent être programmés directement sur le système de stockage.

Attention : Vérifiez que l'ASM spfile et passwd les fichiers ne se trouvent pas dans le groupe de disques hébergeant les fichiers de données. Cela interfère avec la capacité à restaurer de manière sélective les fichiers de données et uniquement les fichiers de données.

== Procédure de récupération locale — NFS La procédure de base est la suivante :

  1. Arrêtez la base de données.

  2. Restaurez les volumes de fichiers de données, les LUN ou les espaces de noms à l’instantané précédant immédiatement le point de restauration souhaité.

  3. Exécuter alter database automatic;

Cette procédure suppose que les journaux d'archive souhaités sont toujours présents dans le système de fichiers actif. Si ce n'est pas le cas, les journaux d'archive doivent être restaurés, ou rman ou sqlplus peut être dirigé vers les données dans le .snapshot répertoire.

En outre, dans le cas de bases de données plus petites, l'utilisateur peut restaurer les fichiers de données directement à partir du système .snapshot Répertoire n'ayant pas besoin des outils d'automatisation ou d'un administrateur du stockage pour exécuter une commande SnapRestore.

== Procédure de récupération locale — SAN La procédure de base est la suivante :

  1. Arrêtez la base de données.

  2. Arrêter le ou les groupes de disques hébergeant les fichiers de données. La procédure varie en fonction du gestionnaire de volumes logiques choisi. Avec ASM, le processus nécessite de démonter le groupe de disques. Sous Linux, les systèmes de fichiers doivent être démontés et les volumes logiques et les groupes de volumes désactivés. L'objectif est d'arrêter toutes les mises à jour du groupe de volumes cible à restaurer.

  3. Restaurez les groupes de disques de fichiers de données sur l'instantané immédiatement avant le point de restauration souhaité.

  4. Réactivez les groupes de disques récemment restaurés.

  5. Exécuter alter database automatic;

Cette procédure suppose que les journaux d'archivage souhaités sont toujours présents dans le système de fichier actif. S'ils ne le sont pas, les journaux d'archivage doivent être restaurés en mettant hors ligne les LUN de journaux d'archivage et en effectuant une restauration. Ceci est également un exemple où il est utile de séparer les journaux d'archivage dans des volumes, LUN ou espaces de noms dédiés. Si les journaux d'archivage partagent un groupe de volumes avec les journaux de redo, ces derniers doivent être copiés ailleurs avant la restauration de l'ensemble des LUN afin d'éviter de perdre les dernières transactions enregistrées.

Exemple de récupération complète : Supposons que les fichiers de données aient été corrompus ou détruits et qu’une récupération complète soit nécessaire. La procédure à suivre est la suivante :

[oracle@host1 ~]$ sqlplus / as sysdba
Connected to an idle instance.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 1610612736 bytes
Fixed Size                  2924928 bytes
Variable Size            1040191104 bytes
Database Buffers          553648128 bytes
Redo Buffers               13848576 bytes
Database mounted.
SQL> recover automatic;
Media recovery complete.
SQL> alter database open;
Database altered.
SQL>