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.

Sauvegardes en ligne

Contributeurs jfsinmsp
PDF

Deux datasets sont nécessaires pour protéger et restaurer une base de données Oracle en mode de sauvegarde. Notez qu'il ne s'agit pas de la seule option de sauvegarde Oracle, mais qu'elle est la plus courante.

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

  • Les journaux d'archivage créés pendant que les fichiers de données étaient en mode de sauvegarde

Si une récupération complète incluant toutes les transactions validées est requise, un troisième élément est requis :

  • Les journaux de reprise en cours

Il existe plusieurs façons de restaurer une sauvegarde en ligne. De nombreux clients restaurent les snapshots à l'aide de l'interface de ligne de commande ONTAP, puis à l'aide d'Oracle RMAN ou de sqlplus pour terminer la restauration. Cette approche est particulièrement fréquente dans les environnements de production de grande taille. En effet, la probabilité et la fréquence des restaurations de bases de données sont extrêmement faibles et les restaurations sont gérées par un administrateur de bases de données qualifié. Pour une automatisation totale, des solutions telles que NetApp SnapCenter intègrent un plug-in Oracle avec une ligne de commande et des interfaces graphiques.

Certains grands clients ont adopté une approche plus simple en configurant des scripts de base sur les hôtes afin de placer les bases de données en mode de sauvegarde à un moment spécifique en préparation d'un snapshot planifié. Par exemple, planifiez la commande alter database begin backup à 23:58, alter database end backup à 00:02, puis planifiez les snapshots directement sur le système de stockage à minuit. Résultat : une stratégie de sauvegarde simple et hautement évolutive ne nécessite aucun logiciel ni licence externe.

Disposition des données

La solution la plus simple consiste à isoler les fichiers de données dans un ou plusieurs volumes, LUN ou espaces de noms NVMe dédiés. Les ressources de stockage ne doivent contenir aucun autre type de fichier. Ceci afin de garantir que les fichiers de données peuvent être rapidement restaurés via une opération SnapRestore sans détruire un journal de restauration important, un fichier de contrôle ou un journal d'archivage.

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 l'abstraction au niveau du volume, contrairement à un système AFF qui peut héberger plusieurs LUN. ASA utilise plutôt des groupes de cohérence. Dans de nombreux cas, un seul LUN ou espace de noms NVMe suffit aux besoins 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 restauration locale : NFS

Cette procédure peut être conduite manuellement ou via une application telle que SnapCenter. La procédure de base est la suivante :

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

  2. Récupérez les volumes NFS de fichiers de données à partir de l'instantané précédant immédiatement le point de restauration souhaité.

  3. Réexécutez les journaux d'archivage au point souhaité.

  4. Relire les journaux de reprise en cours si vous souhaitez effectuer une restauration complète.

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'archivage doivent être restaurés ou rman/sqlplus peut être dirigé vers les données du répertoire d'instantanés.

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 des administrateurs de stockage pour exécuter une snaprestore commande.

Procédure de restauration locale—SAN

Cette procédure peut être conduite manuellement ou via une application telle que SnapCenter. 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 doivent être désactivés. L'objectif est d'arrêter toutes les mises à jour du groupe de volumes cible à restaurer.

  3. Restaurez les LUN hébergeant les groupes de disques de fichiers de données à l'instantané précédant immédiatement le point de restauration souhaité.

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

  5. Réexécutez les journaux d'archivage au point souhaité.

  6. Relire tous les journaux de reprise si vous souhaitez procéder à une restauration complète.

Cette procédure suppose que les journaux d'archivage souhaités sont toujours présents dans le système de fichier actif. Dans le cas contraire, les journaux d'archivage doivent être restaurés en mettant complètement hors ligne les LUN/espaces de noms de journaux d'archivage et en effectuant une restauration (ou en créant un clone d'un instantané précédent, ce qui peut s'avérer complexe en raison de la création de noms UUID ou LVM dupliqués sur le même hôte). Cet exemple illustre également l'utilité de séparer les journaux d'archivage dans des ressources de stockage dédiées. Si les journaux d'archivage partagent un groupe de volumes avec les journaux de restauration, alors les journaux de restauration doivent être copiés ailleurs avant la restauration de l'ensemble des LUN. Cette étape permet d'éviter la perte de ces dernières transactions enregistrées.