Modèles de récupération pour DB2

Les types de récupération que vous pouvez utiliser avec les géodatabases dans DB2 sont la récupération de version, qui utilise la consignation circulaire, la récupération de réimplémentation des modifications, qui utilise la consignation d'archive ou le type HADR (High Availability Disaster Recovery).

Remarque :

veillez à récupérer toutes les bases de données composant la géodatabase ArcSDE lors de la restauration d'une base de données ArcSDE sous DB2 pour z/OS.

• Récupération de version et consignation circulaire

  La consignation circulaire utilise un jeu de fichiers journaux pour enregistrer les modifications apportées à la base de données. Lorsque le dernier fichier journal du jeu est rempli, le premier fichier est réutilisé. Les informations de transaction pouvant être remplacées, lorsque vous utilisez la consignation circulaire, la récupération de réimplémentation des modifications n'est pas possible ; toutefois, la récupération n'est généralement pas requise lors du chargement de données. La consignation circulaire est le modèle de consignation par défaut.

• Récupération de réimplémentation des modifications et consignation d'archive

  Si vous souhaitez utiliser la récupération de réimplémentation des modifications, la méthode de récupération recommandée avec les géodatabases ArcSDE, utilisez la consignation d'archive. La consignation d'archive ne remplace pas les fichiers journaux mais elle crée des journaux supplémentaires pour enregistrer toutes les transactions effectuées depuis la dernière sauvegarde. Vous aurez besoin de plus d'espace disque pour utiliser la consignation d'archive car les journaux ne sont pas réutilisés comme dans le cas de la consignation circulaire.

• HADR

  HADR (High Availability Disaster Recovery) est une fonction de réplication de base de données disponible dans DB2 et qui protège vos données en répliquant les modifications de données d'une base de données source (dite principale) vers une base de données cible (dite de secours). Si la base de données principale tombe en panne, vous pouvez basculer vers la base de données de secours pendant la récupération de la base de données principale.

  Vous pouvez spécifier un mode parmi trois modes de synchronisation pour HADR : synchrone, proche synchrone ou asynchrone.

  En mode synchrone, une modification apportée à la base de données principale n'y est validée qu'une fois les journaux associés écrits dans les journaux de transactions sur la base de données de secours. Les deux bases de données restent ainsi synchronisées car une modification n'est pas appliquée à la base de données principale si elle n'est pas enregistrée dans un fichier journal (et donc récupérable) sur la base de données de secours. Ce mode a le plus grand impact sur les performances de la base de données principale.

  En mode proche synchrone, une modification apportée à la base de données principale n'y est validée qu'une fois les journaux associés écrits dans la mémoire sur la base de données de secours. Ce mode est presque aussi efficace que le mode synchrone et a un impact moindre sur la base de données principale. Toutefois, si la base de données de secours tombe en panne une fois les données validées dans la base de données principale, les données transférées peuvent être perdues et les deux bases de données devenir incohérentes.

  Les validations de transaction de base de données sur la base de données principale ne sont pas affectées par la communication des enregistrements de journaux à la base de données de secours. Dans ce mode, les données entre les deux bases de données risquent plus de devenir incohérentes. D'autres options de réplication peuvent être utilisées avec DB2, notamment les réplications SQL et Q. Consultez votre documentation DB2 pour plus d'informations.

Pour restaurer votre géodatabase, vous pouvez utiliser la commande RECOVER DATABASE ou l'Assistant de récupération de données du centre de contrôle DB2. La géodatabase peut être restaurée vers une base de données existante ou vers une nouvelle base de données. Voici quelques considérations sur la restauration vers une nouvelle base de données :

• Si vous effectuez une récupération vers une nouvelle base de données, vous devez être connecté à l'instance.
• Si vous effectuez une restauration vers une nouvelle base de données sur un autre serveur et que vos serveurs source et cible n'utilisent pas la page de code par défaut, vous devez créer votre base de données sur la machine cible avec la page de code correcte avant de procéder à la restauration. Si vous ne le faites pas et si votre page de codes de production est différente de celle de la source, l'utilitaire de restauration utilise la page de codes par défaut. Cela provoque une erreur SQL2548N.
• Lorsque vous effectuez une récupération vers une nouvelle base de données, le fichier d'historique de récupération de l'image de sauvegarde devient le fichier d'historique de récupération de la nouvelle base de données.

Lorsque vous effectuez une récupération complète d'une base de données récupérable, il ne peut y avoir de connexion à la base de données autre que la connexion établie lorsque la base de données est récupérée. Lorsqu'une sauvegarde complète de base de données est restaurée, DB2 vérifie que tous les tablespaces référencés dans l'image de sauvegarde figurent dans la base de données vers laquelle les données sont restaurées. (Il peut s'agir d'une base de données existante ou d'une nouvelle base de données vide.) Si un tablespace est manquant ou inaccessible, l'opération de récupération échoue.

Pour éviter cela, vous pouvez effectuer une opération de restauration redirigée. Ceci vous permet de spécifier de nouveaux tablespaces vers lesquels vous pouvez restaurer les tablespaces de l'image de sauvegarde qui étaient manquants dans la base de données cible. Pour plus d'informations sur l'exécution d'une restauration redirigée, consultez votre documentation DB2.

Si vous restaurez uniquement des tablespaces individuels d'une base de données récupérable, la base de données peut rester en ligne si les utilisateurs ne sont pas connectés aux tablespaces que vous essayez de restaurer.

Astuce

• Vous pouvez automatiser l'archivage et l'extraction des fichiers journaux avec un programme de sortie utilisateur. Pour ce faire, vous devez définir le paramètre de configuration logarchmeth1 sur USEREXIT.

  Pour plus d'informations sur le développement et l'utilisation d'un programme de sortie utilisateur, consultez votre documentation DB2.

• Si votre base de données est partitionnée, vous devez exécuter la commande RECOVER DATABASE à partir de la partition de catalogue. Lorsque vous restaurez une base de données partitionnée sur un point spécifique dans le temps, toutes les partitions répertoriées dans le fichier db2nodes.cfg sont affectées. Lorsque vous effectuez une récupération sur la fin des journaux, vous pouvez spécifier les partitions affectées par la récupération. Si vous ne désignez pas de partitions spécifiques, toutes les partitions du fichier db2nodes.cfg sont affectées.