Service Backup and DR pour Oracle

La base de données Oracle est une base de données d'entreprise populaire qui prend en charge les applications stratégiques. Cette page présente le service Backup and DR pour les environnements de base de données Oracle. L'architecture associée fournit une sauvegarde incrémentielle continue et cohérente avec les applications pour Google Cloud, ainsi qu'une récupération et un clonage instantanés pour les bases de données Oracle de plusieurs téraoctets.

Fonctionnement

Les sections suivantes décrivent le processus de capture et de récupération des données.

Capture de données

  1. L'agent Backup and DR est déployé sur le serveur Oracle.

  2. Installez le disque intermédiaire sur le serveur de base de données.

  3. Appelez l'API incrémentielle RMAN pour copier les blocs modifiés.

  4. Appelez la fusion incrémentielle RMAN pour créer une sauvegarde complète virtuelle.

  5. Démontez le disque intermédiaire du serveur de base de données.

  6. Backup and DR prend un instantané interne. La sauvegarde complète synthétique à un instant donné est prête.

Récupération de données

Backup and DR monte instantanément un disque de préparation réinscriptible sur ISCSI ou NFS, puis met la base de données en ligne.

API de sauvegarde Oracle

Backup and DR utilise les API Oracle suivantes :

  • Copie d'image RMAN : la restauration d'une copie d'image d'un fichier de données est beaucoup plus rapide, car la structure physique du fichier de données existe déjà. La directive RMAN BACKUP AS COPY crée des copies d'image pour tous les fichiers de données de l'ensemble de la base de données et conserve le format des fichiers de données.

  • API ASM et CRS : le groupe de disques de sauvegarde ASM est géré à l'aide des API ASM et CRS.

  • API de sauvegarde des journaux d'archive RMAN : les journaux d'archive générés sont sauvegardés sur le disque de préproduction et supprimés de l'emplacement de l'archive de production.

Limiter les conflits lorsque vous utilisez le service Backup and DR avec d'autres produits de sauvegarde

Le service Backup and DR peut coexister avec les anciens produits qui capturent des données à partir des bases de données de production. Les bonnes pratiques suivantes peuvent vous aider à améliorer votre expérience :

Planning de sauvegarde de la base de données Oracle

Bonne pratique Programmez les tâches de sauvegarde de la base de données du service Backup and DR pour qu'elles commencent à un moment où l'ancien logiciel de sauvegarde devrait avoir terminé. Ne planifiez pas l'exécution de l'ancien logiciel de sauvegarde immédiatement après la fin normale d'un job de sauvegarde de base de données du service Backup and DR.
Motif Si les anciens jobs de sauvegarde et les jobs de sauvegarde de base de données du service Backup and DR s'exécutent simultanément, cela peut avoir un impact important sur les performances du serveur de base de données, ce qui peut entraîner une instabilité et éventuellement une panne. De plus, pour Oracle, cela peut entraîner des images de sauvegarde non valides pour l'une ou les deux solutions.

Gestion des journaux d'archive Oracle

Oracle utilise les journaux d'archive générés lors d'une sauvegarde de base de données pour assurer la cohérence et la récupérabilité de cette sauvegarde. Par conséquent, si les journaux d'archive sont supprimés lors d'un job de sauvegarde de base de données, cette copie de sauvegarde ne peut pas être récupérée.

Exigence Un seul système peut gérer (capturer et/ou tronquer/supprimer) les journaux, qu'il s'agisse de l'ancien logiciel de sauvegarde ou du service Backup and DR.
Bonne pratique N'autorisez pas la suppression des journaux d'archive Oracle lors d'un job Backup and DR, et n'autorisez pas le service Backup and DR à supprimer les journaux d'archive lors d'un ancien job RMAN de sauvegarde.
Si l'ancien logiciel gère le journal d'archive, désactivez les jobs de suppression des journaux d'archive dans l'ancien logiciel de sauvegarde au début du job de sauvegarde Backup and DR, et reprenez les jobs de suppression à la fin ou conservez le journal d'archive pendant au moins 24 heures avant de le supprimer.
Motif Si les journaux d'archive sont purgés lors d'une tâche de sauvegarde de base de données, il est possible que l'image de sauvegarde de cette base de données ne puisse pas être récupérée.

Conflit de métadonnées RMAN avec les anciennes sauvegardes qui rendent les sauvegardes du service Backup and DR obsolètes

Par défaut, le paramètre DO NOT UNCATALOG dans les détails et les paramètres de l'application Backup and DR est défini sur Non. Une sauvegarde de fichier de données Backup and DR est cataloguée au début de la sauvegarde et supprimée du catalogue à la fin du job. Si vous définissez cette option sur Oui, le temps de sauvegarde des bases de données comportant un grand nombre de fichiers de données est optimisé. Pour ce faire, le catalogue de sauvegarde des fichiers de données RMAN est conservé après chaque job de sauvegarde. Toutefois, il interfère avec d'autres produits de sauvegarde.

Exigence Définissez le paramètre Do not uncatalog sur Non.
Bonne pratique Les sauvegardes de bases de données du service Backup and DR sont incrémentielles pour toujours. Pour ce faire, utilisez la copie d'image RMAN avec l'API de fusion incrémentielle RMAN. La première sauvegarde RMAN est une copie d'image complète du fichier de données de la base de données sur le disque de sauvegarde Backup and DR avec un instantané interne du disque de sauvegarde. Les exécutions de sauvegarde incrémentielle RMAN suivantes avec fusion incrémentielle RMAN sur le disque de sauvegarde Backup and DR mettent à jour la dernière sauvegarde complète avec les modifications incrémentielles avant l'instantané. Toutefois, si une sauvegarde de base de données tierce ou une vérification croisée de la sauvegarde s'exécute après la sauvegarde de base de données Backup and DR, tous les fichiers de données de sauvegarde sous la sauvegarde Backup and DR sont marqués comme obsolètes dans les métadonnées RMAN. Si le paramètre "Détails et paramètres de l'application Backup and DR" Do not uncatalog est défini sur Oui, l'erreur suivante s'affiche : Échec du catalogage des copies d'images à partir de l'appareil intermédiaire et la sauvegarde échoue. Définissez Do not uncatalog sur Non pour que la fonctionnalité coexiste avec d'autres anciens produits de sauvegarde.
Motif Par défaut, le paramètre Do not uncatalog> in Backup and DR application details & settings is set to No. Setting this to Yes interferes with other backup products.

Suivi des modifications de blocs de base de données Oracle (BCT)

Le suivi des modifications de blocs Oracle permet de sauvegarder rapidement les bases de données en identifiant les blocs qui ont été modifiés. Seuls les blocs modifiés sont inclus dans l'opération de sauvegarde.

  • Backup and DR Service prend en charge l'incrémentiel permanent pour les bases de données exécutées avec ou sans suivi des blocs modifiés. Si BCT n'est pas activé, le temps de sauvegarde incrémentielle augmente.

  • Le suivi des blocs modifiés est activé au niveau de la base de données.

  • Oracle enregistre les blocs modifiés dans chaque fichier de données dans un fichier de suivi, qui est un petit fichier binaire stocké dans la zone de la base de données.

  • Lorsque BCT est activé, RMAN utilise le fichier BCT pour obtenir les blocs modifiés pour la sauvegarde incrémentielle.

  • RMAN analyse chaque bloc d'un fichier de données pour tous les fichiers de données de la base de données lors de la sauvegarde incrémentielle lorsque le suivi des blocs modifiés sur la base de données n'est pas activé.

Protéger les bases de données Oracle dans un groupe de cohérence Backup and DR

Dans la plupart des configurations, un groupe de cohérence peut contenir une seule application de base de données Oracle et un nombre quelconque d'applications de système de fichiers à partir du serveur Oracle. Un groupe de cohérence est le choix recommandé pour les bases de données Oracle dans les cas d'utilisation de test et de développement, ainsi que pour l'agilité métier.

Bases de données Oracle avec TDE

Le service Backup and DR est compatible avec différentes méthodes de capture et de présentation pour les bases de données Oracle dans diverses configurations. Cela inclut les opérations de sauvegarde, de récupération et de montage Application Aware de la base de données Oracle avec le chiffrement transparent des données (TDE) configuré.

Pour les bases de données Oracle avec TDE, les fichiers de portefeuille de l'hôte de sauvegarde source doivent être disponibles pour l'hôte cible de tous les montages Application Aware. Pour ce faire, plusieurs possibilités s'offrent à vous.

  • Les fichiers du portefeuille peuvent être copiés du serveur source de sauvegarde vers le serveur de montage cible, et Oracle peut être configuré pour y accéder.
  • Si les fichiers du portefeuille Oracle sont stockés sur un appareil central et partagé sur le réseau, l'instance Oracle de la cible de montage Appaware doit être configurée pour y accéder.

  • Si les fichiers du portefeuille Oracle ont été capturés lors de la sauvegarde du service Backup and DR en définissant le paramètre avancé "Emplacement du fichier de configuration Oracle", vous pouvez les récupérer en procédant comme suit :

    1. Montez la base de données sur l'hôte cible de manière standard.
    2. Copiez les fichiers de portefeuille à partir du montage de base de données standard vers l'hôte cible et configurez Oracle pour qu'il les utilise.
    3. Démontez la base de données de l'hôte cible.
    4. Effectuez un montage compatible avec les applications de la base de données sur l'hôte cible.

Backup and DR avec une base de données Oracle Exadata ou Oracle ExaCC

Les appliances de sauvegarde/restauration permettent de capturer et de présenter les données Exadata via les protocoles iSCSI ou Oracle dNFS.

  • L'appliance de sauvegarde/récupération est connectée via iSCSI ou Oracle dNFS sur le réseau (et non dans le chemin d'accès aux données).

  • La sauvegarde RMAN utilise RMAN pour écrire directement dans un datastore de copie présenté par Backup and DR en tant que système de fichiers ou groupe de disques ASM.

  • Formats de capture de données : sous Groupe de disques ASM (iSCSI uniquement) ou sous Système de fichiers (dNFS ou iSCSI).

  • La sauvegarde incrémentielle continue de Backup and DR utilise les sauvegardes RMAN mises à jour de manière incrémentielle, en faisant progresser les sauvegardes de copie d'image.

Capture Backup and DR des données Exadata et d'ExaCC

L'agent Backup and DR doit être installé sur le serveur Exadata pour faciliter la communication avec l'appliance de sauvegarde/restauration et pour appeler l'API RMAN pour la sauvegarde de la base de données.

L'agent Backup and DR expose et mappe les disques Backup and DR au serveur Exadata en tant que cible iSCSI. Le format de capture des données peut être Groupe de disques ASM ou Système de fichiers.

Installez l'agent Backup and DR sur chaque hôte Exadata dans l'espace utilisateur pour faciliter la communication avec l'appliance de sauvegarde/récupération et appeler l'API RMAN pour la sauvegarde de la base de données.

Format de capture sous le groupe de disques ASM

Lors d'une sauvegarde, l'agent Backup and DR effectue les opérations suivantes :

  1. Mappez et exposez le disque logique au serveur Exadata en tant que cible iSCSI.

  2. Ajoutez le chemin d'accès au disque Backup and DR à la chaîne de disque ASM.

  3. Assurez-vous que la chaîne de disque ASM est ajoutée au fichier de paramètres et n'existe pas dans le profil CRS.

  4. Créez un groupe de disques ASM en tant que redondance externe à l'aide du disque Backup and DR.

    • Sauvegarde RMAN utilisant RMAN pour écrire directement dans un datastore de copie présenté par l'appliance de sauvegarde/restauration en tant que groupe de disques ASM ou système de fichiers.

    • Sauvegarde incrémentielle illimitée à l'aide des sauvegardes RMAN mises à jour de manière incrémentielle, avec restauration des sauvegardes d'image.

Format de capture dans le système de fichiers à l'aide de dNFS

Oracle direct NFS (dNFS) est un client NFS (Network File System) optimisé qui offre un accès plus rapide et plus évolutif au stockage NFS situé sur des périphériques de stockage NAS (accessibles via TCP/IP). Direct NFS est directement intégré au noyau de la base de données, tout comme ASM.

Le protocole dNFS peut être utilisé pour la sauvegarde basée sur le système de fichiers en tant que partage NFS.

L'agent Backup and DR expose et mappe les disques Backup and DR au serveur Exadata en tant que partage NFS.

Conditions préalables pour dNFS sur le serveur Exadata :

  • Activez dNFS sur le serveur Exadata :

    cd $ORACLE_HOME/rdbms/lib make -f ins_rdbms.mk nfs on

  • Redémarrez la base de données.

    Utilisez l'API RMAN pour sauvegarder la base de données dans le système de fichiers sur le partage dNFS présenté par l'appliance de sauvegarde/récupération.

Remettre en ligne les groupes de disques ASM protégés par Backup and DR après le redémarrage d'un serveur de base de données cible

Après tout redémarrage du serveur de base de données sur lequel la copie Backup and DR est montée, ou si des sauvegardes Backup and DR sont en cours pour la base de données au moment du redémarrage/plantage, suivez ces étapes pour remonter le groupe de disques Backup and DR :

  1. Vérifiez que le serveur de base de données cible est de nouveau opérationnel, et que les systèmes ASM et RAC le sont également.

  2. Redémarrez l'agent Backup and DR (à partir de la racine).

  3. Définissez l'environnement ASM.

  4. Connectez-vous à ASM sqlplus et vérifiez l'état du groupe de disques :

    select name, state from v$asm_diskgroup where name = '<dg name>';)

  5. Si le groupe de disques n'est pas installé, installez-le : alter diskgroup <dg name> mount;

  6. Connectez-vous à l'OS Oracle et définissez l'environnement de base de données, puis démarrez la base de données.

Étapes suivantes

Découvrez les conditions préalables à la sauvegarde d'une base de données Oracle.

Autre documentation pour Backup and DR for Oracle