Récupération de données et haute disponibilité

Généralités sur la sauvegarde

Prenez connaissance des restrictions suivantes :

• Le démarrage d'une opération de sauvegarde en ligne d'un espace table DMS est autorisé lorsqu'une table au sein du même espace table est réorganisée en ligne. L'opération de réorganisation peut connaître des attentes sur verrouillage au cours de la phase de troncature.
• Le démarrage d'une opération de sauvegarde en ligne d'un espace table SMS n'est pas autorisé lorsqu'une table au sein du même espace table est réorganisée en ligne. Les deux opérations nécessitent un verrou exclusif.

Utilisation de la sauvegarde

Les restrictions suivantes s'appliquent à l'utilitaire de sauvegarde :

• Une opération de sauvegarde d'espace table et une opération de restauration d'espace table ne peuvent pas être exécutées en même temps, même si différents espaces table sont concernés.
• Pour effectuer une récupération en aval dans un environnement de base de données partitionnées, vous devez sauvegarder régulièrement la base de données sur la liste des noeuds, et vous devez avoir au moins une image de sauvegarde du reste des noeuds sur le système (même ceux qui ne contiennent pas de données utilisateur pour cette base de données). Deux situations nécessitent l'image sauvegardée d'une partition de base de données au niveau d'un serveur de partition de base de données qui ne contient pas de données utilisateur pour la base de données :
  • L'ajout d'un serveur de partition de base de données au système de base de données après avoir effectué la dernière sauvegarde et la nécessité d'effectuer une reprise en aval sur ce serveur de partition de base de données.
  • Une reprise à partir d'un point de cohérence est utilisée, et nécessite que toutes les partitions de la base de données du système soient en état de récupération aval en attente.
  • Les opérations de sauvegarde en ligne des espaces table DMS sont incompatibles avec les opérations suivantes :
    • Chargement
    • Réorganisation (uniquement hors connexion) ; (vous pouvez utiliser la réorganisation en ligne d'une table dans l'espace table qui est sauvegardé, bien que des attentes sur verrouillage soient à prévoir au cours de la phase de troncature de l'opération de réorganisation).
    • Suppression d'espace table
    • Troncature de table
    • Création d'index
    • Non enregistré initialement (utilisé avec les instructions CREATE TABLE et ALTER TABLE)

Présentation du HADR (High Availability Disaster Recovery)

Lorsque vous exécutez les commandes START HADR, STOP HADR ou TAKEOVER HADR, les codes d'erreur correspondants peuvent être générés : SQL01767N, SQL01769N, ou SQL01770N avec le code anomalie 98. Ce dernier indique que la licence de HADR n'est pas installée sur le serveur sur lequel la commande a été exécutée. Pour résoudre ce problème, installez une licence HADR valide à l'aide de db2licm ou une version du serveur dont la distribution comprend la licence HADR.

Prise en charge de la sauvegarde inter-plateformes et de la restauration

DB2 Universal Database (UDB) prend en charge les opérations de sauvegarde et de restauration multiplateformes.

Vous pouvez restaurer des bases de données créées sur une plateforme Windows 32 bits DB2 UDB, version 8 sur une plateforme Windows 64 bits DB2 UDB, version 8, ou l'inverse.

Vous pouvez restaurer des bases de données créées sur une plateforme Linux x86 32 bits DB2 UDB, version 8 sur une plateforme Linux x86-64 ou IA64 64 bits DB2 UDB version 8, et inversement.

Vous pouvez restaurer des bases de données créées avec DB2 UDB version 8 sous AIX, HP-UX, Linux PPC, Linux zSeries, ou dans l'environnement d'exploitation Solaris, en 32 bits ou 64 bits, vers DB2 UDB version 8 sous AIX, HP-UX, Linux PPC, Linux zSeries ou l'environnement d'exploitation Solaris (32 bits ou 64 bits).

Sauvegarde sur bande (Linux)

La taille de bloc maximale pour les unités de bande 3480 et 3490 sous Linux est de 61 440 octets

Tivoli Storage Manager

Lors de l'appel des commandes BACKUP DATABASE ou RESTORE DATABASE, vous pouvez spécifier que vous souhaitez utiliser le produit Tivoli Storage Manager (TSM) pour gérer l'opération de sauvegarde ou de restauration de la base de données ou de l'espace table. Le niveau minimum suivant de l'API client TSM est la version 4.2.0, sauf dans les cas suivants :

• Systèmes Solaris 64 bits nécessitant une API client TSM Version 4.2.1.
• Systèmes d'exploitation Windows NT 64 bits nécessitant l'API client TSM version 5.1.
• Linux 32 bits pour iSeries et pSeries nécessitant au minimum l'API client TSM version 5.1.5
• Linux 64 bits pour iSeries et pSeries, nécessitant au minimum l'API client TSM version 5.3
• Linux 64 bits sur système AMD Opteron nécessitant une API client TSM version 5.2.0.
• Linux 64 bits pour zSeries nécessitant au minimum une API client TSM version 5.2.2.

Restrictions de valeurs pour l'hôte local HADR et les paramètres de service locaux

Lors de la spécification de valeurs pour l'hôte local HADR et les paramètres locaux de service (HADR_LOCAL_SVC et HADR_REMOTE_SVC) lors de la préparation d'une commande update database configuration , les valeurs doivent être des ports qui ne sont pas utilisés pour un autre service. Si les paramètres sont configurés à l'aide d'une ligne de commande Linux ou UNIX, les valeurs doivent également être définies dans le fichier /etc/services.

Configuration système supplémentaires pour HADR

Si vous créez un espace table sur la base de données principale et que la lecture de journal échoue sur la base de données en attente parce que les conteneurs ne sont pas disponibles, la base de données principale ne reçoit pas un message d'erreur indiquant l'échec de lecture journal.

Pour vérifier les erreurs d'exécution de journal, vous devez contrôler le fichier db2diag.log et le journal d'administration sur la base de données en attente lorsque vous créez de nouveaux espaces table.

Si une opération de relais intervient, le nouvel espace table créé n'est pas disponible sur la nouvelle base de données principale. Pour récupérer de cette situation, restaurez l'espace table sur la base de données principale à partir d'une image de sauvegarde.

Dans l'exemple suivant, l'espace table MY_TABLESPACE est restauré sur la base de données MY_DATABASE avant qu'il soit utilisé en tant que nouvelle base de données principale :

1. db2 connect to my_database
2. db2 list tablespaces show detail
   Remarque :
   Exécutez la commande db2 list tablespaces show detail pour afficher l'état de tous les espaces table et obtenir l'ID d'espace table requis pour l'étape 5.
3. db2 stop hadr on database my_database
4. db2 "restore database my_database tablespace (my_tablespace) online redirect"
5. db2 "set tablespace containers for my_tablespace_ID_# ignore rollforward container operations using (path '/my_new_container_path/')"
6. db2 "restore database my_database continue"
7. db2 rollforward database my_database to end of logs and stop tablespace "(my_tablespace)"
8. db2 start hadr on database my_database as primary

Opérations non répliquées pour la récupération HADR

La documentation version 8.2 indique :

Les BLOB et CLOB ne sont pas répliqués. Toutefois, l'espace qui leur est dédié sera alloué sur la base de données en attente.

L'instruction doit être corrigée comme suit :

Les BLOB et CLOB non journalisés ne sont pas répliqués. Toutefois, l'espace qui leur est dédié sera alloué sur la base de données en attente.

HADR ne prend pas en charge les journaux bruts

L'utilitaire HADR ne prend pas en charge l'utilisation d'E-S brutes (accès disque direct) pour les fichiers journaux de base de données. Si HADR est démarré avec la commande START HADR ou si la base de données est redémarré avec HADR configuré, et que des journaux bruts sont détectés, la commande associée échouera avec le code anomalie SQL1768N "9".

Comparaison entre un moniteur de panne et un moniteur de santé

Le moniteur de santé et le moniteur de panne sont des outils qui |fonctionnent sur une seule instance de base de données. Le moniteur de santé |utilise des indicateurs de santé afin d'évaluer la |santé de certains aspects spécifiques aux performances de la base de données et |du gestionnaire de base. Un |indicateur de santé mesure la santé de certains aspects d'une classe |spécifique d'objets de base de données, tels qu'un espace table. Les |indicateurs de santé sont évalués par rapport à des critères |précis afin de déterminer la santé de cette classe d'objet de base de |données. En outre, les indicateurs de santé peuvent générer des alertes |afin de vous informer qu'un indicateur dépasse un certain seuil ou bien |indiquer qu'un objet de base de données est dans un état anormal.

Par comparaison, le moniteur de panne est le seul responsable du maintien en |bon état de fonctionnement de l'instance qu'il gère. Si l'instance DB2 UDB |qu'il gère se termine de façon inattendue, le moniteur de panne redémarre |l'instance. Ce moniteur n'est pas disponible sous Windows.

Arrêt du contrôle de panne

Pour arrêter le contrôle de panne pour l'instance de base de données |DB2INST1, saisissez la commande suivante à partir d'une fenêtre de commande DB2 |UDB :

   db2fm -i db2inst1 -f no

Afin de vous assurer que le moniteur de panne ne fonctionne plus pour DB2INST1, |saisissez la commande suivante pour les systèmes UNIX :

   ps -ef|grep -i fm

Dans les systèmes Linux, saisissez la commande suivante :

   ps auxw|grep -i fm

Une entrée affichant db2fmd et DB2INST1 indique que le moniteur de panne |fonctionne toujours sur cette instance. Pour arrêter le moniteur de panne, |saisissez la commande suivante en tant que propriétaire de l'instance :

   db2fm -i db2inst1 -D