Recherche dans <book_title>…

Guide de l'administrateur Veritas NetBackup™ for Oracle

Last Published: 2017-11-02

Product(s): NetBackup (8.1)

Configuration d'exemple RAC : le nom de basculement n'est pas disponible et la charge de la sauvegarde est répartie, une politique avec script personnalisé.

Une sauvegarde avec une charge répartie sans nom de basculement doit être compatible avec les configurations précédentes. Sans nom de basculement, le planificateur NetBackup doit exécuter le script de sauvegarde sur les deux hôtes. Dans ce cas, le script doit démarrer RMAN sur seulement un des hôtes. Etant donné que RMAN peut assigner des canaux sur les deux instances, les demandes de l'utilisateur doivent présenter des noms d'hôte spécifiques. La condition est que la reconnexion du serveur de médias NetBackup puisse récupérer les données de l'hôte correspondant.

La politique doit spécifier les deux noms de client (soit hostname1 et hostname2, soit vipname1 et vipname2). La spécification des noms de client permet de s'assurer que le script de sauvegarde est exécuté sur au moins un hôte actif.
Le script de sauvegarde doit être accessible aux deux hôtes dans le cluster. 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 de sauvegarde à partir du client principal, démarrez RMAN et lancez la sauvegarde. En cas d'exécution du script de sauvegarde à 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 de sauvegarde à 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
```
Le script de sauvegarde ne doit pas être configuré pour envoyer une valeur unique pour NB_ORA_CLIENT. La raison en est que le serveur de médias NetBackup doit se reconnecter à l'hôte correspondant à l'hôte ayant lancé la demande de sauvegarde de l'utilisateur.
Configurez la sauvegarde de façon à fournir un nom de client spécifique à l'hôte avec chaque demande de sauvegarde à l'aide de l'une des trois options suivantes :
- Configurez RMAN pour lier les canaux spécifiques à des instances spécifiques et pour envoyer les noms de client associés sur chaque canal pour le stockage d'images de sauvegarde. Configurez également RMAN pour qu'il se reconnecte à l'hôte à l'origine de la demande de transfert de données.
```
ALLOCATE CHANNEL 1 ... PARMS='ENV=(NB_ORA_CLIENT=vipname1)' CONNECT='sys/passwd@vipname1';
ALLOCATE CHANNEL 2 ... PARMS='ENV=(NB_ORA_CLIENT=vipname2)' CONNECT='sys/passwd@vipname2';
ALLOCATE CHANNEL 3 ... PARMS='ENV=(NB_ORA_CLIENT=vipname1)' CONNECT='sys/passwd@vipname1';
ALLOCATE CHANNEL 4 ... PARMS='ENV=(NB_ORA_CLIENT=vipname2)' CONNECT='sys/passwd@vipname2';
```
  Remarque :
  Si un ou plusieurs de ces nœuds sont arrêtés, ces opérations d'allocation échouent et entraînent l'échec de la sauvegarde.
- Vous pouvez également configurer Oracle pour lier les canaux spécifiques à des hôtes spécifiques.
```
CONFIGURE CHANNEL 1 DEVICE TYPE 'SBT_TAPE' CONNECT 'sys/passwd@vipname1' PARMS 
   "ENV=(NB_ORA_CLIENT=vipname1)";
CONFIGURE CHANNEL 2 DEVICE TYPE 'SBT_TAPE' CONNECT 'sys/passwd@vipname2' PARMS 
   "ENV=(NB_ORA_CLIENT=vipname2)";
CONFIGURE CHANNEL 3 DEVICE TYPE 'SBT_TAPE' CONNECT 'sys/passwd@vipname1' PARMS 
   "ENV=(NB_ORA_CLIENT=vipname1)";
CONFIGURE CHANNEL 4 DEVICE TYPE 'SBT_TAPE' CONNECT 'sys/passwd@vipname2' PARMS 
   "ENV=(NB_ORA_CLIENT=vipname2)";
```
- Par défaut, la sauvegarde utilise des noms de client qui doivent être différents pour chaque hôte et correspondent en général au nom d'hôte physique.

Configurez le serveur maître NetBackup pour autoriser l'accès aux noms d'hôte physique à toutes les images de sauvegarde.

cd /usr/opnv/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
```

Le script de sauvegarde est exécuté sur tous les hôtes actifs mais ne démarre RMAN que sur un seul hôte. RMAN assigne des canaux à tous les hôtes pour répartir la charge. Les demandes de sauvegarde de l'utilisateur comprennent une chaîne NB_ORA_CLIENT ou CLIENT_NAME spécifique à l'hôte qui envoie la demande et qui correspond à la politique. La reconnexion pour le transfert de données et l'image de sauvegarde sont enregistrées sous ce nom.

Les deux clients peuvent lancer la restauration. RMAN doit être configuré avec l'option " 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. Ce nom est le nom de client qui est utilisé lors du transfert pour stockage de la partie de jeu de sauvegarde.

SEND 'NB_ORA_CLIENT=client_name_used_by_backup';