Guide de l'administrateur Veritas NetBackup™ for Oracle
- Introduction
- Démarrage rapide de NetBackup for Oracle
- Installation de NetBackup for Oracle
- A propos de la liaison d'Oracle RMAN avec NetBackup pour UNIX
- Configuration de politique Oracle
- Préparation à la configuration de NetBackup for Oracle
- Gestion des instances pour une politique intelligente Oracle
- A propos des politiques intelligentes d'Oracle (OIP)
- A propos des politiques Oracle basées sur un modèle ou un script
- A propos de l'ajout de sélections de sauvegarde à une politique Oracle
- A propos de la configuration de l'environnement d'exécution
- A propos de la création de modèles et de scripts de shell
- A propos de la création manuelle de scripts RMAN
- Exécution de sauvegardes et de restaurations Oracle
- A propos de NetBackup pour des sauvegardes d'Oracle
- A propos des restaurations NetBackup for Oracle
- Redirection d'une restauration vers un autre client
- Utilisation de NetBackup for Oracle dans un environnement en cluster Microsoft Windows
- Récupération assistée
- Dépannage de la récupération assistée
- NetBackup for Oracle avec Snapshot Client
- A propos du dépannage de NetBackup for Oracle avec Snapshot Client
- Fonctionnement de NetBackup for Oracle avec Snapshot Client
- A propos de la configuration de Snapshot Client avec NetBackup for Oracle
- Restauration de NetBackup for Oracle à partir d'une sauvegarde par cliché
- A propos de la configuration des sauvegardes BLI NetBackup for Oracle sous UNIX
- A propos des effets de Snapshot Client
- À propos de la prise en charge d'Oracle pour Replication Director
- Dépannage
- Dépannage des erreurs de sauvegarde ou de restauration RMAN
- Annexe A. Clusters d'applications réelles
- Annexe B. Pratiques d'excellence pour protéger Oracle RAC avec NetBackup
- Annexe C. Pratiques d'excellence de déduplication
- Annexe D. Prise en charge Snapshot Client de SFRAC
- Annexe E. Sauvegardes incrémentielles de niveau bloc émanant de scripts sans RMAN sur systèmes UNIX et Linux
- Vérification des paramètres d'installation pour des sauvegardes incrémentielles de blocs sans RMAN
- Création de politiques NetBackup pour les sauvegardes incrémentielles de bloc basées sur les scripts
- Création de scripts de notification pour les sauvegardes incrémentielles de bloc
- Réalisation de sauvegardes et restaurations
- A propos du dépannage des erreurs de sauvegarde ou de restauration
- Annexe F. Archivage XML
- Exportation/importation XML dans NetBackup for Oracle
- Modèles d'exportation XML et scripts shell
- Création de l'archive d'une exportation XML
- Restauration d'une archive d'exportation XML
- A propos de la redirection d'une restauration de l'archive d'une exportation XML vers un autre client
- Dépannage des erreurs d'importation/exportation XML
- Annexe G. Enregistrer des emplacements autorisés
Configuration d'exemple RAC : le nom de basculement n'est pas disponible et la charge de la sauvegarde n'est pas répartie
Dans cette configuration, les noms d'hôte ou de VIP permettent de se connecter aux hôtes correspondants dans le cluster. Vous avez besoin d'une configuration spéciale pour vous assurer que le script de sauvegarde est exécuté au moins sur l'un des hôtes mais pas sur les deux hôtes. Dans le cas contraire, vous ne pouvez pas effectuer de sauvegarde si l'instance spécifiée est arrêtée ou une sauvegarde redondante a lieu si les deux instances spécifiées sont actives.
En résumé, le terme "principal" se rapporte à l'instance sur laquelle vous effectuez en règle générale la sauvegarde. Le terme secondaire se rapporte à l'autre instance qui peut être utilisée si la principale est indisponible. De plus, étant donné que vous pouvez effectuer une sauvegarde à partir des deux hôtes, vous pouvez enregistrer les images de sauvegarde sous les deux noms de client. Le nom de stockage d'image dépend de l'hôte actif au moment de la sauvegarde. La configuration est la suivante :
La politique spécifie des noms de client pour les deux hôtes (soit hostname1 et hostname2 ou vipname1 et vipname2). La spécification du nom du client garantit que la sauvegarde est effectuée sur un hôte opérationnel.
Les deux hôtes du cluster doivent avoir accès au script de sauvegarde. Le système de fichiers mis en cluster constitue un bon emplacement.
Vous devez personnaliser le script de sauvegarde pour pouvoir démarrer RMAN sur un seul des clients. En cas d'exécution du script à partir du client principal, démarrez RMAN et lancez la sauvegarde. En cas d'exécution du script à partir du client secondaire, et ce, même si le client principal est actif, l'état renvoyé à la fin de l'opération doit être égal à 0 pour que le planificateur NetBackup n'utilise plus ce client. En cas d'exécution du script à partir du client secondaire car le client principal n'est pas actif, démarrez RMAN et lancez la sauvegarde. Vous pouvez personnaliser le script à l'aide de l'utilitaire tnsping sur le client principal ou envoyer une demande à la base de données. Utilisez cette personnalisation pour vérifier si l'autre instance est ouverte et peut effectuer la sauvegarde.
$ select INST_ID, STATUS, STARTUP_TIME, HOST_NAME from gv$instance; INST_ID STATUS STARTUP_T HOST_NAM ---------- ------------ --------- --------- 1 OPEN 13-JAN-09 vipname1 2 OPEN 13-JAN-09 vipname2
Chaque demande de sauvegarde de l'utilisateur doit utiliser un nom de client qui autorise le serveur de médias NetBackup à se reconnecter à l'hôte correspondant pour le transfert de données. Par défaut, la sauvegarde utilise la chaîne CLIENT_NAME du fichier bp.conf., qui est différente pour chaque hôte. Il est conseillé de configurer RMAN de façon à fournir le nom de client correspondant à la politique comme suit :
SEND 'NB_ORA_CLIENT=$NB_ORA_CLIENT';
Configurez le serveur maître NetBackup pour permettre l'accès physique aux noms d'hôte à toutes les images de sauvegarde.
cd /usr/openv/netbackup/db/altnames echo "hostname1" >> hostname1 echo "vipname1" >> hostname1 echo "hostname2" >> hostname1 echo "vipname2" >> hostname1 cp hostname1 hostname2
Vous pouvez utiliser Réseau préféré ou tout autre moyen pour forcer NetBackup à utiliser les adresses IP associées aux noms de VIP pour les demandes de sauvegarde sortantes de l'utilisateur. Si vous utilisez cette méthode, vous devez permettre aux noms de VIP d'accéder à toutes les images de sauvegarde.
cd /usr/openv/netbackup/db/altnames cp hostname1 vipname1 cp hostname1 vipname2
Les deux clients peuvent lancer la restauration. RMAN doit être configuré avec l'option "SET AUTOLOCATE ON;" pour demander les parties du jeu de sauvegardes de l'hôte ou de l'instance approprié ayant effectué la sauvegarde. Vous pouvez également effectuer une restauration à partir de l'hôte ou de l'instance si vous configurez chaque demande de restauration de façon à inclure le bon nom de client. Le nom de client est celui qui est utilisé lors du transfert pour stockage de la partie de jeu de sauvegarde.
SEND 'NB_ORA_CLIENT=client_name_used_by_backup'