Guide de Mise À Niveau Et de Migration Des Serveurs v5 Vers 6.3.4 - Upgrade - Guide PDF

IBM Tivoli Storage Manager
Version 6.3.4
Guide de mise à niveau et de migration des

Serveurs V5
GC11-6978-02
IBM Tivoli Storage Manager
Version 6.3.4
Guide de mise à niveau et de migration des

Serveurs V5
GC11-6978-02
Remarque :
Avant d'utiliser le présent document et le produit associé, prenez connaissance des informations figurant à la section
«Remarques», à la page 601.
La présente édition s'applique à la version 6.3.4 de IBM Tivoli Storage Manager (numéro de produit 5608-E01,
5608-E02, 5608-E03), ainsi qu'à toutes les éditions et modifications ultérieures, sauf indication contraire dans les
nouvelles éditions ou les bulletins techniques. Elle remplace l'édition GC27-4017-01.
© Copyright IBM Corporation 2009, 2013.
Table des matières
Préface . . . . . . . . . . . . . . xiii
A qui s'adresse ce guide . . . . . . . . . .
xiii Configuration matérielle et logicielle requise pour
Comment utiliser ce guide . . . . . . . . .
xiii le serveur mis à niveau . . . . . . . . . 22
Publications . . . . . . . . . . . . . xiv. Compatibilité du serveur Tivoli Storage Manager
Publications Tivoli Storage Manager . . . . xiv. avec d'autres produits DB2 sur le système . . . . 40
Informations de support . . . . . . . . . xvii | Déterminer le niveau approprié d'un serveur V5
Obtention d'une formation technique . . . . xvii | avant une mise à niveau . . . . . . . . . . 42
Recherche dans les bases de connaissances . . xvii Exécution du vérificateur de prérequis . . . . . 43
Contacter le service de support logiciel IBM . . xix Planification de l'espace nécessaire au processus de
mise à niveau et au serveur mis à niveau . . . . 44
Table desdematières
Nouveautés la version 6.3 . . . . xxiii Espace requis pour le système du serveur version
Mises à jour du serveur . . . . . . . . . xxiii 5 . . . . . . . . . . . . . . . . . 44
Nouveautés
Figures . . du. serveur
. . . dans
. . la .version
. . 6.3.4
. . . xxiii
. v 5.2.6 dbLastWritten
Espace requis pour .le système
. . . du . serveur
. . . version
. . . 14
Nouveautés du serveur dans la version 6.3.3 xxiv 5.2.7
6 . .prstBlobSize
. . . . . . . . . . . . . . . 14 45
Nouveautés du serveur dans la version 6.3.1
Tableaux . . . . . . . . . . . . . . xxvi vii 5.3 Estimation
Table SearchServiceField . . total
de l'espace disque . . requis
. . pour
. . le. 14
Nouveautés du serveur dans la version 6.3.0 xxvi 5.3.1 srchServiceFldId
processus . . et
de mise à niveau . le. serveur
. . . mis. à. . 14
5.3.2
niveausearchServiceId
. . . . . . . . . . . . . . . 47 14
Avis aux lecteurs canadiens. . . . . xxxiv
. ix 5.3.3 nom
Feuille . . .pour
de calcul . l'espace
. . . de . planification
. . . . . du. 15
5.3.4 type
serveur V6.3. ou
. ultérieure
. . . . . . . . . . . . 15 50
Partie 1. 1.
Chapitre Mise à niveau. du
Introduction . serveur
. . . . de
. . 1 5.3.5 indexed
Estimation de la .durée
. . de. mise
. .à niveau.
. . . . . . . 15 50
1.1 version
la Manuel Cúram Generic
5 vers la Search Server
version 6.3Guide
ou . . 1 5.3.6 stockées
Exemple . . . de
- Estimation . la
. durée
. . de . mise
. . à. . . 15
1.2 Prérequis . . . . . . . . . . . . . . 1 5.3.7
niveauentityName
en fonction de . la
. taille
. . de . la. base
. . de. . . 16
ultérieure. . . . . . . . . . . . .
1.3 Public concerné . . . . . . . . . . .
. . 11 5.3.8 untokenized
données . . . . . . . . . . . . . . 16 51
5.3.9 analyzerName.
Conseils de performances . . pour
. .le processus
. . . . . . 16
Chapitre
Chapitre 1. 2. Présentation des mises à
Concepts et définitions . . . 3 d'extraction d'une base de données version 5 . . 52
jour
2.1 Introduction . . . . . . . du
de la base de données . serveur
. . . . .. 3
3 Conseils 6.
Chapitre relatifs
Guide aux d'initiation
performances pour à
Base de données
2.2 Generic SearchduServer
serveur
. .. .. .. .. .. .. .. .. .. 33 l'insertion de données
l'interface de programme dans la d'application
base de données
2.3 Index . . . . . .la base
Espace disponible dans . . de . données
. . . pour . . . 3 version 6.3 ou ultérieure . . . . . . . . . 53
de Generic Search Server . . . . . . 17
Planification de la mise à niveau de plusieurs
2.4 un serveur
Service version 6.3 ou
de recherche . ultérieure
. . . . .. .. .. .. .. 44 6.1 Introduction . . . . . . . . . . . . . 17
2.5 Journal
Zone . de . reprise.
. . . .. .. .. .. .. .. .. .. .. .. .. 45 serveurs et composants . . . . . . . . . . 54
6.2 Associateurs . . . . . . . . . . . . . 17
Modifications
2.6 Document . . aux
liées . opérations
. . . . .. .. .. .. .. .. .. 45 | Composants disponibles pour l'installation . . . 54
6.3 Contrôleur de recherche . . . . . . . . . 18
2.7 Opérations
Lucene . de . base
. . de. données
. . . .. .. .. .. .. .. .. 54 Compatibilité avec des serveurs et des
6.4 Connecteur du service de recherche . . . . . 18
2.8 Protection et reprise
Base de données de de la base. de
transfert . données
. . . .. .. .. 56 composants exécutés à des versions antérieures . 54
6.5 Requêtes . . . . . . . . . . . . . . 18
2.9 Plusieurs
Requête . instances
. . . du . serveur
. . . sur . un. seul
. . . . . 6 Planification de la mise à niveau de plusieurs
6.6 Objet CuramTerm . . . . . . . . . . . 19
2.10système
Terme .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 68 serveurs sur un seul système . . . . . . . 54
6.6.1 Structure de requête . . . . . . . . . 19
2.11Modification
Analyseur . du . démarrage
. . . . du . serveur
. . . .. .. .. .. 69 Planification de la mise à niveau des
6.6.2 Termes standard . . . . . . . . . . 19
2.12Modifications
Associateur liées
. . aux
. fichiers
. . . et. à . . . . . . 6 gestionnaires de bibliothèque et des clients de la
6.6.3 Termes de date et de plage de dates . . . 20
2.13l'environnement
Extracteur. . . . . . . . . . . . . . . . . . . . . . . . . .10 6 bibliothèque . . . . . . . . . . . . . 55
6.6.4 Texte . . . . . . . . . . . . . . 20
Modifications des commandes d'administration 11 Planification de la mise à niveau des clients . . 56
6.7 Génération de requêtes . . . . . . . . . 21
Planification de la mise à niveau des agents de
Chapitre 3. Présentation de Generic 6.7.1 Génération d'une instance de Query Builder 21
Chapitre 2. Planification stockage . . . . . . . . . . . . . . 56
Search Server . . . . .de. la. mise
. . à. . . 7 6.7.2 Ajout de critères de recherche . . . . . 21
Test du processus de mise à niveau pour un serveur 56
niveau
3.1 Generic Search Server et Lucene . .. .. .. .. 13
du serveur . . . . . . . 7 6.7.3 Génération de requêtes à partir d'une struct 21
Effectuez un test en extrayant les données à
Processus de mise
3.2 Importation de àdonnées
niveau du serveur
à partir de la version
de Cúram . . . 7 6.7.4 Spécification des zones du service de
partir d'une copie distincte du serveur . . . . 57
53.3sur la version 6.3 ou ultérieure
Synchronisation du serveur de recherche. . . . . . . . . . .13
8 recherche à renvoyer . . . . . . . . . . 21
Effectuez un test en extrayant les données à
3.4 Comparaison
Contrôleur dede la mise à .niveau
recherche . . sur . un. système
. . . . 9 6.7.5 Obtention de l'objet de requête . . . . . 21
partir du serveur de production . . . . . . 58
3.5 existant
Processuset de
surrecherche
un nouveau . . système
. . . . . . . . . . . . .14 9 6.8 Gestion des résultats de recherche . . . . . 22
Préparation des modifications opérationnelles . . . 59
3.6 Comparaison
Références . des . .méthodes
. . . de. transfert
. . . des . . . . 9 6.9 Type de données et conversion de chaîne . . . 22
Informations de référence pour la planification . . 60
données vers la base de données version 6.3 ou
Modifications apportées aux commandes et
ultérieure . . . . . . . . . . . . . . 17 Chapitre
Chapitre 4. Recherches prises en options . 7.. Implémentation
. . . . . . . d'une . . . . . . 60
utilitaires de mise à niveau DSMUPGRD . . . 18
charge
Configurations Generic
par matérielle Search
et logicielleServer
requises. pour. . 11 recherche
Messages du avec Generic
serveur ajoutés Search
ou modifiésServer
. . . . 23
81
4.1 7.1 Valeurs recommandées
Présentation . . . . pour . .la .dénomination
. . . . . . 23
la mise à niveau vers le serveur version 6.3 ou . . 11
Introduction . . . . . . . . . . .
4.2 Propriétés 7.2 d'un serveur
Exemple . . . .de .personne
de recherche . . . : présentation
. . . . . 81 23
ultérieure . .associées
. . . à .Generic . . Search
. . . Server . . . . 19
dans l'application Cúram . . . . . requise
. . . pour . . 11 7.3 Développement de fichiers DMX SearchService 24
Configuration matérielle et logicielle
4.3 le
Maintenir 7.3.1 Configuration de l'enregistrement du service
système ladusynchronisation
serveur versiondes données
5 mis à niveauCúram. . 19
et des données de recherche . . . . . . . . . 12 de recherche . . . . . . . . . . . . . 24
4.3.1 Synchronisation basée sur les événements 12 7.3.2 Configuration de l'enregistrement
SearchServiceField . . . . . . . . . . . 24
© Copyright IBM Corp. 2009, 2013
Chapitre 5. Tables de base de données 7.4 Implémentation d'opérations de l'associateur . . iii 24
7.4.1 Interface Mapper.mapToStagingDb . . . . 24
de transfert . . . . . . . . . . . . . 13
7.4.2 Interface Mapper.getObjectList . . . . . 25
5.1 Introduction . . . . . . . . . . . . . 13
7.4.3 Interface Mapper.getExtKey . . . . . . 26
Chapitre 3. Présentation des scénarios Scénario 1: Paramétrage des variables
de mise à niveau . . . . . . . . . . 85 d'environnement pour les utilitaires de mise à
Scénario 1 : Mise à niveau du serveur sur un même niveau sur des systèmes AIX, HP-UX, Linux et
système via des supports . . . . . . . . . . 85 Oracle Solaris . . . . . . . . . . . . 119
Mise à niveau du serveur par le biais de Scénario 1: Installation des utilitaires de mise à
l'assistant . . . . . . . . . . . . . . 86 niveau sur des systèmes Microsoft Windows . . 120
Mise à niveau manuelle du serveur par le biais Scénario 1: Préparation de la base de données sur
des utilitaires . . . . . . . . . . . . . 88 un serveur version 5 en vue de la mise à niveau . 120
Scénario 2 : Mise à niveau du serveur sur un même Scénario 1: Désinstallation du programme version
système par le réseau . . . . . . . . . . . 90 5 avant l'installation de V6.3 ou d'une version
Mise à niveau du serveur par le biais de ultérieure . . . . . . . . . . . . . . 122
l'assistant . . . . . . . . . . . . . . 90 Scénario 1: Désinstallation du programme
Mise à niveau manuelle du serveur par le biais version 5 sur des systèmes AIX . . . . . . 122
des utilitaires . . . . . . . . . . . . . 92 Scénario 1: Désinstallation du programme
Scénario 3 : Mise à niveau du serveur sur un version 5 sur des systèmes HP-UX . . . . . 122
nouveau système via des supports. . . . . . . 94 Scénario 1: Désinstallation du programme
Mise à niveau du serveur par le biais de version 5 sur des systèmes Linux . . . . . . 123
l'assistant . . . . . . . . . . . . . . 94 Scénario 1: Désinstallation du programme
Mise à niveau manuelle du serveur par le biais version 5 sur des systèmes Oracle Solaris . . . 123
des utilitaires . . . . . . . . . . . . . 96 Scénario 1: Désinstallation du programme
Scénario 4 : Mise à niveau du serveur sur un version 5 sur des systèmes Microsoft Windows . 124
nouveau système via le réseau . . . . . . . . 98 Scénario 1: Installation du serveur V6.3 ou d'une
Mise à niveau du serveur par le biais de version ultérieure . . . . . . . . . . . . 124
l'assistant . . . . . . . . . . . . . . 99 Scénario 1: Création des répertoires et de l'ID
Mise à niveau manuelle du serveur par le biais utilisateur pour l'instance de serveur mise à niveau 129
des utilitaires . . . . . . . . . . . . 100 Scénario 1: Mise à niveau du serveur par le biais
de l'assistant de mise à niveau. . . . . . . . 133
Scénario 1: Mise à niveau manuelle du serveur par
Chapitre 4. Scénario 1 : Même le biais des utilitaires . . . . . . . . . . . 135
système, via des supports . . . . . . 103 Scénario 1: Extraction des données sur des
Scénario 1: Préparation de la mise à niveau . . . 103 supports . . . . . . . . . . . . . . 135
Scénario 1: Vérification de la configuration Scénario 1: Création et formatage de la nouvelle
requise pour la mise à niveau . . . . . . . 104 base de données . . . . . . . . . . . 136
Scénario 1: Préparation de l'espace pour le Scénario 1: Chargement des données extraites
processus de mise à niveau. . . . . . . . 108 dans la nouvelle base de données . . . . . 141
Scénario 1: Modification du serveur avant la Scénario 1: Création d'un service Windows pour
mise à niveau . . . . . . . . . . . . 109 l'instance de serveur . . . . . . . . . . 143
Scénario 1: Désactivation des sessions . . . . 110 Scénario 1: Configuration du système en vue de
Scénario 1: Sauvegarde des pools de stockage et la sauvegarde de la base de données . . . . 144
de la base de données du serveur . . . . . 110
Scénario 1: Suppression ou changement de nom Chapitre 5. Scénario 2 : Même
du fichier NODELOCK . . . . . . . . . 111
Scénario 1: Sauvegarde des informations de
système, via le réseau . . . . . . . 149
configuration . . . . . . . . . . . . 111 Scénario 2: Préparation de la mise à niveau . . . 149
Scénario 1: Création d'un récapitulatif du Scénario 2: Vérification de la configuration
contenu de la base de données . . . . . . 112 requise pour la mise à niveau . . . . . . . 150
Scénario 1: Arrêt du serveur avant l'installation Scénario 2: Préparation de l'espace pour le
de la mise à niveau . . . . . . . . . . 112 processus de mise à niveau. . . . . . . . 154
Scénario 1 : Installation des utilitaires de mise à Scénario 2: Modification du serveur avant la
niveau . . . . . . . . . . . . . . . . 113 mise à niveau . . . . . . . . . . . . 154
Scénario 1: Installation des utilitaires de mise à Scénario 2: Désactivation des sessions . . . . 155
niveau sur des systèmes AIX . . . . . . . 113 Scénario 2: Sauvegarde des pools de stockage et
Scénario 1: Installation des utilitaires de mise à de la base de données du serveur . . . . . 156
niveau sur des systèmes HP-UX . . . . . . 115 Scénario 2: Suppression ou changement de nom
Scénario 1: Installation des utilitaires de mise à du fichier NODELOCK . . . . . . . . . 156
niveau sur des systèmes Linux . . . . . . 116 Scénario 2: Sauvegarde des informations de
Scénario 1: Installation des utilitaires de mise à configuration . . . . . . . . . . . . 157
niveau sur des systèmes Oracle Solaris . . . 118 Scénario 2: Création d'un récapitulatif du
contenu de la base de données . . . . . . 157
Scénario 2: Arrêt du serveur avant l'installation
de la mise à niveau . . . . . . . . . . 158
iv IBM Tivoli Storage Manager : Guide de mise à niveau et de migration des serveurs V5
Scénario 2 : Installation des utilitaires de mise à Scénario 3: Suppression ou changement de nom
niveau. . . . . . . . . . . . . . . . 158 du fichier NODELOCK . . . . . . . . . 201
Scénario 2: Installation des utilitaires de mise à Scénario 3: Sauvegarde des informations de
niveau sur des systèmes AIX . . . . . . . 159 configuration . . . . . . . . . . . . 201
Scénario 2: Installation des utilitaires de mise à Scénario 3: Création d'un récapitulatif du
niveau sur des systèmes HP-UX . . . . . . 160 contenu de la base de données . . . . . . 202
Scénario 2: Installation des utilitaires de mise à Scénario 3: Arrêt du serveur avant l'installation
niveau sur des systèmes Linux . . . . . . 162 de la mise à niveau . . . . . . . . . . 202
Scénario 2: Installation des utilitaires de mise à Scénario 3 : Installation des utilitaires de mise à
niveau sur des systèmes Oracle Solaris . . . 163 niveau. . . . . . . . . . . . . . . . 203
Scénario 2: Paramétrage des variables Scénario 3: Installation des utilitaires de mise à
d'environnement pour les utilitaires de mise à niveau sur des systèmes AIX . . . . . . . 203
niveau sur des systèmes AIX, HP-UX, Linux et Scénario 3: Installation des utilitaires de mise à
Oracle Solaris . . . . . . . . . . . . 164 niveau sur des systèmes HP-UX . . . . . . 205
Scénario 2: Installation des utilitaires de mise à Scénario 3: Installation des utilitaires de mise à
niveau sur des systèmes Microsoft Windows . . 165 niveau sur des systèmes Linux . . . . . . 206
Scénario 2: Préparation de la base de données sur Scénario 3: Installation des utilitaires de mise à
un serveur version 5 en vue de la mise à niveau . 166 niveau sur des systèmes Oracle Solaris . . . 207
Scénario 2: Désinstallation du programme version Scénario 3: Paramétrage des variables
5 avant l'installation de V6.3 ou d'une version d'environnement pour les utilitaires de mise à
ultérieure . . . . . . . . . . . . . . 167 niveau sur des systèmes AIX, HP-UX, Linux et
Scénario 2: Désinstallation du programme Oracle Solaris . . . . . . . . . . . . 209
version 5 sur des systèmes AIX . . . . . . 167 Scénario 3: Installation des utilitaires de mise à
Scénario 2: Désinstallation du programme niveau sur des systèmes Microsoft Windows . . 209
version 5 sur des systèmes HP-UX . . . . . 168 Scénario 3: Mise à niveau du serveur par le biais
Scénario 2: Désinstallation du programme de l'assistant de mise à niveau. . . . . . . . 210
version 5 sur des systèmes Linux . . . . . . 168 Scénario 3, assistant: Installation du serveur
Scénario 2: Désinstallation du programme V6.3 ou d'une version ultérieure . . . . . . 211
version 5 sur des systèmes Oracle Solaris . . . 169 Scénario 3, assistant: Création des répertoires et
Scénario 2: Désinstallation du programme de l'ID utilisateur pour l'instance de serveur
version 5 sur des systèmes Microsoft Windows . 169 mise à niveau . . . . . . . . . . . . 216
Scénario 2: Installation du serveur V6.3 ou d'une Scénario 3: Démarrage de l'assistant de mise à
version ultérieure . . . . . . . . . . . . 169 niveau. . . . . . . . . . . . . . . 219
Scénario 2: Création des répertoires et de l'ID Scénario 3: Mise à niveau manuelle du serveur par
utilisateur pour l'instance de serveur mise à niveau 175 le biais des utilitaires . . . . . . . . . . . 221
Scénario 2: Mise à niveau du serveur par le biais Scénario 3: Préparation de la base de données
de l'assistant de mise à niveau. . . . . . . . 178 sur un serveur version 5 en vue de la mise à
Scénario 2: Mise à niveau manuelle du serveur par niveau. . . . . . . . . . . . . . . 222
le biais des utilitaires . . . . . . . . . . . 180 Scénario 3: Extraction des données sur des
Scénario 2: Création et formatage de la nouvelle supports . . . . . . . . . . . . . . 223
base de données . . . . . . . . . . . 180 Scénario 3, manuel: Installation du serveur V6.3
Scénario 2: Transfert de la base de données du ou d'une version ultérieure . . . . . . . . 224
serveur via un réseau . . . . . . . . . 185 Scénario 3, manuel: Création des répertoires et
Scénario 2: Création d'un service Windows pour de l'ID utilisateur pour l'instance de serveur
l'instance de serveur . . . . . . . . . . 187 mise à niveau . . . . . . . . . . . . 229
Scénario 2: Configuration du système en vue de Scénario 3: Création et formatage de la nouvelle
la sauvegarde de la base de données . . . . 188 base de données . . . . . . . . . . . 232
Scénario 3: Chargement des données extraites
Chapitre 6. Scénario 3 : Nouveau dans la nouvelle base de données . . . . . 237
système, via des supports . . . . . . 193 Scénario 3: Création d'un service Windows pour
l'instance de serveur . . . . . . . . . . 239
Scénario 3: Préparation de la mise à niveau . . . 193
Scénario 3: Configuration du système en vue de
Scénario 3: Vérification de la configuration
la sauvegarde de la base de données . . . . 240
requise pour la mise à niveau . . . . . . . 194
Scénario 3: Préparation de l'espace pour le
processus de mise à niveau. . . . . . . . 197 Chapitre 7. Scénario 4 : Nouveau
Scénario 3: Modification du serveur avant la système, via le réseau . . . . . . . 245
mise à niveau . . . . . . . . . . . . 198 Scénario 4: Préparation de la mise à niveau . . . 245
Scénario 3: Désactivation des sessions . . . . 200 Scénario 4: Vérification de la configuration
Scénario 3: Sauvegarde des pools de stockage et requise pour la mise à niveau . . . . . . . 246
de la base de données du serveur . . . . . 200 Scénario 4: Préparation de l'espace pour le
processus de mise à niveau. . . . . . . . 249
Table des matières v

Scénario 4: Modification du serveur avant la Mise à niveau du serveur à V6.3.3 ou une version
mise à niveau . . . . . . . . . . . . 249 ultérieure dans un environnement Windows en
Scénario 4: Désactivation des sessions . . . . 251 cluster . . . . . . . . . . . . . . . . 297
Scénario 4: Sauvegarde des pools de stockage et Planification de la mise à niveau . . . . . . 297
de la base de données du serveur . . . . . 251 Préparation du système et exécution de
Scénario 4: Suppression ou changement de nom l'assistant de mise à niveau . . . . . . . . 297
du fichier NODELOCK . . . . . . . . . 252 Mise à niveau du serveur V6.3.2 ou d'une version
Scénario 4: Sauvegarde des informations de antérieure dans un environnement de cluster
configuration . . . . . . . . . . . . 252 Windows . . . . . . . . . . . . . . . 299
Scénario 4: Création d'un récapitulatif du Planification de la mise à niveau . . . . . . 300
contenu de la base de données . . . . . . 253 Préparation de la mise à niveau . . . . . . 300
Scénario 4: Arrêt du serveur avant l'installation Installation du serveur et chargement de la base
de la mise à niveau . . . . . . . . . . 253 de données . . . . . . . . . . . . . 302
Scénario 4 : Installation des utilitaires de mise à Configuration du serveur . . . . . . . . 304
niveau. . . . . . . . . . . . . . . . 254
Scénario 4: Installation des utilitaires de mise à Chapitre 9. Procédures générales de
niveau sur des systèmes AIX . . . . . . . 254 mise à niveau d'un serveur vers la
Scénario 4: Installation des utilitaires de mise à
niveau sur des systèmes HP-UX . . . . . . 256
version 6.3 ou ultérieure . . . . . . 307
Scénario 4: Installation des utilitaires de mise à Préparation de la mise à niveau . . . . . . . 308
niveau sur des systèmes Linux . . . . . . 257 Vérification de la configuration requise pour la
Scénario 4: Installation des utilitaires de mise à mise à niveau . . . . . . . . . . . . 308
niveau sur des systèmes Oracle Solaris . . . 259 Préparation de l'espace pour le processus de
Scénario 4: Paramétrage des variables mise à niveau . . . . . . . . . . . . 312
d'environnement pour les utilitaires de mise à Modification du serveur avant la mise à niveau 313
niveau sur des systèmes AIX, HP-UX, Linux et Désactivation des sessions . . . . . . . . 314
Oracle Solaris . . . . . . . . . . . . 260 Sauvegarde des pools de stockage et de la base
Scénario 4: Installation des utilitaires de mise à de données du serveur . . . . . . . . . 315
niveau sur des systèmes Microsoft Windows . . 261 Suppression ou changement de nom du fichier
Scénario 4: Mise à niveau du serveur par le biais NODELOCK . . . . . . . . . . . . 316
de l'assistant de mise à niveau. . . . . . . . 262 Sauvegarde des informations de configuration 316
Scénario 4, assistant: Installation du serveur Création d'un récapitulatif du contenu de la
V6.3 ou d'une version ultérieure . . . . . . 262 base de données . . . . . . . . . . . 317
Scénario 4, assistant: Création des répertoires et Arrêt du serveur avant l'installation de la mise à
de l'ID utilisateur pour l'instance de serveur niveau. . . . . . . . . . . . . . . 317
mise à niveau . . . . . . . . . . . . 267 Installation des utilitaires de mise à niveau sur le
Scénario 4: Démarrage de l'assistant de mise à serveur d'origine . . . . . . . . . . . . 317
niveau. . . . . . . . . . . . . . . 271 Installation des utilitaires de mise à niveau sur
Scénario 4: Mise à niveau manuelle du serveur par des systèmes AIX . . . . . . . . . . . 318
le biais des utilitaires . . . . . . . . . . . 272 Installation des utilitaires de mise à niveau sur
Scénario 4: Préparation de la base de données des systèmes HP-UX . . . . . . . . . . 320
sur un serveur version 5 en vue de la mise à Installation des utilitaires de mise à niveau sur
niveau. . . . . . . . . . . . . . . 273 des systèmes Linux . . . . . . . . . . 321
Scénario 4, manuel: Installation du serveur V6.3 Installation des utilitaires de mise à niveau sur
ou d'une version ultérieure . . . . . . . . 274 des systèmes Oracle Solaris . . . . . . . 322
Scénario 4, manuel: Création des répertoires et Paramétrage des variables d'environnement
de l'ID utilisateur pour l'instance de serveur pour les utilitaires de mise à niveau sur des
mise à niveau . . . . . . . . . . . . 279 systèmes AIX, HP-UX, Linux et Oracle Solaris . 324
Scénario 4: Création et formatage de la nouvelle Installation des utilitaires de mise à niveau sur
base de données . . . . . . . . . . . 283 des systèmes Microsoft Windows . . . . . . 324
Scénario 4: Transfert de la base de données du Préparation de la base de données sur un serveur
serveur via un réseau . . . . . . . . . 288 version 5 en vue de la mise à niveau . . . . . 325
Scénario 4: Création d'un service Windows pour Désinstallation du programme version 5 avant
l'instance de serveur . . . . . . . . . . 289 l'installation de V6.3 ou d'une version ultérieure . 327
Scénario 4: Configuration du système en vue de Désinstallation du programme version 5 sur des
la sauvegarde de la base de données . . . . 290 systèmes AIX . . . . . . . . . . . . 327
Désinstallation du programme version 5 sur des
systèmes HP-UX . . . . . . . . . . . 327
Chapitre 8. Environnements en cluster Désinstallation du programme version 5 sur des
: Procédures de mise à niveau . . . . 295 systèmes Linux . . . . . . . . . . . . 328
Mise à niveau du serveur V6.3 ou ultérieure dans
un environnement de cluster AIX. . . . . . . 295
vi IBM Tivoli Storage Manager : Guide de mise à niveau et de migration des serveurs V5
Désinstallation du programme version 5 sur des Phase d'extraction de la base de données : message
systèmes Oracle Solaris . . . . . . . . . 328 de refus de connexion . . . . . . . . . . 371
Désinstallation du programme version 5 sur des | Phase de formatage de base de données : échec
systèmes Microsoft Windows . . . . . . . 328 | avec rc=499 . . . . . . . . . . . . . . 372
Installation du serveur V6.3 ou d'une version Phase d'insertion de la base de données : messages
ultérieure. . . . . . . . . . . . . . . 329 ANR1338E affichés par l'utilitaire de mise à niveau. 374
Création des répertoires et de l'ID utilisateur pour Phase d'insertion de la base de données : messages
l'instance de serveur mise à niveau . . . . . . 334 ANR1525I sans progression apparente . . . . . 374
Mise à niveau du serveur par le biais de l'assistant Phase d'insertion de la base de données : Difficulté
de mise à niveau . . . . . . . . . . . . 337 de relance du processus de mise à niveau . . . . 375
Mise à niveau manuelle du serveur par le biais des | Phase de démarrage du serveur : Error ANR0162W 377
utilitaires . . . . . . . . . . . . . . . 339 Phase de démarrage du serveur : Avertissements
Création et formatage de la nouvelle base de sur les options de serveur non prises en charge . . 379
données . . . . . . . . . . . . . . 340 Phase Postupgrade : Le fichier dsmserv.dsk non
Transfert de la base de données du serveur via disponible . . . . . . . . . . . . . . 379
des supports . . . . . . . . . . . . 345 Phase ostupgrade : Echec de la commande VARY 380
Transfert de la base de données du serveur via Phase Postupgrade : rétablissement à partir de la
un réseau. . . . . . . . . . . . . . 348 version V6.3 ou ultérieure vers la version
Création d'un service Windows pour l'instance précédente du serveur V5 . . . . . . . . . 380
de serveur . . . . . . . . . . . . . 350 Etapes de rétablissement de la version
Configuration du système en vue de la antérieure du serveur. . . . . . . . . . 380
sauvegarde de la base de données . . . . . 351 Etapes de reprise supplémentaires si vous avez
créé des pools de stockage ou activé le
Chapitre 10. Exécution des premières dédoublonnage de données. . . . . . . . 382
étapes après la mise à niveau . . . . 355
Vérification de l'accès aux pools de stockage sur | Partie 2. Migration des serveurs
disque . . . . . . . . . . . . . . . . 355 | V5 Tivoli Storage Manager sur les
Configuration des services Solaris pour l'instance
de serveur . . . . . . . . . . . . . . 356
| systèmes AIX, HP-UX, ou Solaris
Configuration des options de serveur pour la | vers la version V6.3.4 surLinux . . 385
maintenance de la base de données serveur . . . 356
Démarrage de l'instance du serveur après la mise à | Chapitre 12. Présentation de la
niveau. . . . . . . . . . . . . . . . 357 | migration . . . . . . . . . . . . . 387
Démarrage du serveur sur des systèmes AIX, | Feuille de route de migration . . . . . . . . 387
HP-UX, Linux et Oracle Solaris . . . . . . 357 | Scénarios pour la migration d'un serveur à partir
Démarrage du serveur sur des systèmes | d'un système AIX, HP-UX, ou Solaris vers V6.3.4
Windows . . . . . . . . . . . . . . 362 | sur Linux. . . . . . . . . . . . . . . 388
Enregistrement des licences. . . . . . . . . 362 | Processus de migration . . . . . . . . . . 393
Sauvegarde de la base de données après la mise à | Utilitaires et commandes de migration des
niveau du serveur . . . . . . . . . . . . 363 | données . . . . . . . . . . . . . . 393
Vérification du serveur mis à niveau . . . . . 364 | Transfert de données . . . . . . . . . . 393
Changement du nom d'hôte pour le serveur Tivoli | Disponibilité de périphérique . . . . . . . 394
Storage Manager . . . . . . . . . . . . 364 | Protection des données client et du serveur au
Changement du nom d'hôte pour un serveur | cours du processus . . . . . . . . . . 394
exécuté sur des systèmes AIX, HP-UX, Linux ou
Solaris . . . . . . . . . . . . . . . 365
Changement du nom d'hôte pour un serveur
| Chapitre 13. Planification de la
exécuté sous Windows . . . . . . . . . 365 | migration . . . . . . . . . . . . . 397
Mise à jour de l'automatisation . . . . . . . 366 | Configurations matérielles et logicielles requises
Surveillance du serveur mis à niveau . . . . . 367 | pour les serveurs version 5 et 6.3.4 or ou ultérieure 398
Suppression de GSKit version 7 après la mise à | Estimation de l'espace requis pour la base de
niveau sur Tivoli Storage Manager version 6.3 ou | données et le journal de reprise . . . . . . . 398
ultérieure. . . . . . . . . . . . . . . 368 | Estimation de la durée requise pour la migration 399
| Trasfert de données de planification . . . . . . 400
Chapitre 11. Identification des | Planification de la mise à niveau de plusieurs
| serveurs et composants . . . . . . . . . . 400
problèmes liés à la mise à niveau de | Préparation des changements opérationnels . . . 400
la base de données . . . . . . . . . 371 | Estimation de l'espace requis pour le stockage et
Phase de mise à jour de serveur : Avertissements | les périphériques . . . . . . . . . . . . 401
sur les options de serveur non prises en charge . . 371 | Conseils de performances pour le processus
| d'extraction d'une base de données version 5 . . . 402
Table des matières vii

| Conseils relatifs aux performances pour l'insertion | Scénario de migration 2: Création de l'ID
| de données dans la base de données version 6.3.4 | utilisateur et des répertoires pour l'instance de
| or ou ultérieure. . . . . . . . . . . . . 402 | serveur . . . . . . . . . . . . . . 431
| informations de référence pour la planification de | Scénario de migration 2: Création de l'instance
| migration. . . . . . . . . . . . . . . 403 | de serveur et de la base de données . . . . . 432
| Scénario de migration 2: chargement des
| Chapitre 14. Préparation de la | données extraites dans la base de données
| migration . . . . . . . . . . . . . 405 | V6.3.4 or ou ultérieure . . . . . . . . . 435
| Préparation de l'espace pour le processus de
| Scénario de migration 2:Configuration du
| migration. . . . . . . . . . . . . . . 405
| système en vue de la sauvegarde de la base de
| Mise à niveau du serveur version 5 vers la version
| données . . . . . . . . . . . . . . 437
| 5.5.6 ou version ultérieure . . . . . . . . . 405
| Scénario de migration 3: Utilisation de la méthode
| Désactivation des sessions . . . . . . . . . 406
| de réseau et de l'assistant de mise à jour . . . . 438
| Sauvegarde ou migration des données stockées sur
| Scénario de migration 3: Installation du serveur
| des périphériques DISK et FILE . . . . . . . 407
| V6.3.4 or ou ultérieure . . . . . . . . . 439
| Migration des données étant stockées sur des
| Scénario de migration 3: Configuration des
| périphériques GENERICTAPE . . . . . . . . 408
| paramètres des périphériques . . . . . . . 442
| Déplacer les groupes de sauvegarde qui sont
| Scénario de migration 3: Création de l'ID
| stockés sur les unités FILE . . . . . . . . . 409
| utilisateur et des répertoires pour l'instance de
| Sauvegarde de la base de données du serveur . . 409
| serveur . . . . . . . . . . . . . . 443
| Création d'un récapitulatif du contenu de la base
| Scénario de migration 3: Exécution de l'assistant
| de données . . . . . . . . . . . . . . 410
| de mise à niveau . . . . . . . . . . . 444
| Modification du serveur pour prévenir les
| Scénario de migration 4: Utilisation de la méthode
| problèmes potentiels . . . . . . . . . . . 410
| de réseau et de la ligne de commande . . . . . 445
| Arrêt du serveur avant la migration . . . . . . 412
| Scénario de migration 4: préparation de la base
| de données du serveur V5 . . . . . . . . 446
| Installation des utilitaires de mise à niveau . . . 412
| Scénario de migration 4: Installation du serveur
| Installation des utilitaires de mise à niveau sur
| des systèmes AIX . . . . . . . . . . . 412
| Scénario de migration 4: Configuration des
| paramètres des périphériques . . . . . . . 449
| des systèmes HP-UX . . . . . . . . . . 414
| Scénario de migration 4: Création de l'ID
| utilisateur et des répertoires pour l'instance de
| des systèmes Oracle Solaris . . . . . . . 415
| serveur . . . . . . . . . . . . . . 450
| Scénario de migration 4: Création de l'instance
| Chapitre 15. Migration de la base de | de serveur et de la base de données . . . . . 451
| données du serveur vers le | Scénario de migration 4: Transfert de la base de
| serveurV6.3.4 or ou ultérieure . . . . 417 | données du serveur via un réseau . . . . . 454
| Scénario de migration 1: Utilisation de la méthode | Scénario de migration 4:Configuration du
| de réseau et de la ligne de commande . . . . . 417 | système en vue de la sauvegarde de la base de
| Scénario de migration 1: Installation du serveur | données . . . . . . . . . . . . . . 456
| Scénario de migration 1: Configuration des | Chapitre 16. Exécution des premières
| paramètres des périphériques . . . . . . . 420 | étapes après la mise à niveau . . . . 459
| Scénario de migration 1: Création de l'ID | Configuration des options de serveur pour la
| utilisateur et des répertoires pour l'instance de | maintenance de la base de données serveur . . . 459
| serveur . . . . . . . . . . . . . . 421 | Démarrage du serveur . . . . . . . . . . 460
| Scénario de migration 1: Exécution de l'assistant | Démarrage du serveur à l'aide de l'ID utilisateur
| de mise à niveau . . . . . . . . . . . 423 | d'instance . . . . . . . . . . . . . 462
| Scénario de migration 2: Utilisation de la méthode | Démarrage du serveur à l'aide de l'ID de
| de support et de la ligne de commande . . . . 423 | superutilisateur. . . . . . . . . . . . 463
| Scénario de migration 2: préparation de la base | Démarrage automatique des serveurs . . . . 463
| de données du serveur V5 . . . . . . . . 424 | Vérification des résultats de la migration . . . . 464
| Scénario de migration 2: Extraction des données | Enregistrement des licences. . . . . . . . . 464
| sur des supports . . . . . . . . . . . 425 | Mise à jour des informations du chemin d'accès à
| Scénario de migration 2: Installation du serveur | l'unité . . . . . . . . . . . . . . . . 465
| V6.3.4 or ou ultérieure . . . . . . . . . 426 | Sauvegarde de la base de données . . . . . . 465
| Scénario de migration 2: Configuration des | Changement du nom d'hôte pour le serveur Tivoli
| paramètres des périphériques . . . . . . . 428 | Storage Manager . . . . . . . . . . . . 466
| Scénario de migration 2: Configuration des | Mise à jour de l'option tcpserveraddress . . . . 467
| périphériques . . . . . . . . . . . . 429 | Configuration de l'adresse IP du serveur . . . . 467
viii IBM Tivoli Storage Manager : Guide de mise à niveau et de migration des serveurs V5
| Migration des données d'une bande magnétique Conseils de performances pour le processus
| vers des unités de DISQUE ou de FICHIER . . . 469 d'extraction d'une base de données version 5 . . 501
| Restauration de groupes de sauvegarde . . . . 470 Conseils relatifs aux performances pour
| Mise à jour de l'automatisation . . . . . . . 471 l'insertion de données dans la base de données
| Début des opérations et surveillance des serveurs 471 version 6.3 ou ultérieure. . . . . . . . . 502
Planification de la mise à niveau de plusieurs
| Chapitre 17. Identification et serveurs et composants . . . . . . . . . . 503
| résolution des problèmes de la Planification des changements apportés aux agents
de stockage . . . . . . . . . . . . . . 503
| migration d'un serveur version 5 Préparation des changements opérationnels . . . 503
| depuis AIX, HP-UX, ou Solaris . . . . 473 Informations de référence pour la planification . . 504
| Rétablissement de la version 5 du serveur à partir Migration des attributs d'unité et de
| de la version 6.3.4 or ou ultérieure . . . . . . 473 bibliothèque . . . . . . . . . . . . . 504
Migration d'options de serveur . . . . . . 511
Partie 3. Migration des serveurs
Tivoli Storage Manager version 5 Chapitre 20. Préparation de la
s'exécutant sur des systèmes migration . . . . . . . . . . . . . 515
Préparation de l'espace pour le processus de
z/OS vers la version 6 sous AIX ou migration. . . . . . . . . . . . . . . 515
Linux on System z . . . . . . . . 475 Sauvegarde des informations de configuration . . 516
Installation et configuration du serveur version 6.3
Chapitre 18. Présentation de la ou ultérieure . . . . . . . . . . . . . 516
migration . . . . . . . . . . . . . 477 Installation du serveur version 6.3 ou ultérieure
sur des systèmes AIX ou Linux . . . . . . 516
Feuille de route de la migration . . . . . . . 477
Création de répertoires et de l'ID utilisateur
Scénarios de migration d'un serveur à partir d'un
pour l'instance de serveur . . . . . . . . 519
système z/OS vers AIX ou Linux sur System z . . 477
Préparation du serveur version 5 s'exécutant sous
Présentation de Tivoli Storage Manager for z/OS
z/OS pour la migration . . . . . . . . . . 521
Media . . . . . . . . . . . . . . . . 481
Modification du serveur avant la migration . . 521
Processus de migration . . . . . . . . . . 481
Mise à niveau du serveur version 5.5.6 ou
Présentation du processus de migration . . . 482
ultérieur . . . . . . . . . . . . . . 522
Tâches principales du processus de migration 484
Installation de Tivoli Storage Manager for z/OS
Utilitaires et commandes de migration des
Media . . . . . . . . . . . . . . . 523
données . . . . . . . . . . . . . . 485
Définition d'un serveur qui correspond au
Migration d'unité . . . . . . . . . . . 486
serveur multimédia z/OS . . . . . . . . 523
Groupes de sauvegarde . . . . . . . . . 488
Désactivation des sessions . . . . . . . . 524
Impacts de la migration sur les agents de
Analyse du serveur Tivoli Storage Manager à
stockage . . . . . . . . . . . . . . 489
l'aide de ZMSPREPARE . . . . . . . . . 524
Protection des données client et du serveur au
Suppression des volumes de pools de stockage
cours du processus . . . . . . . . . . 490
de copie basés sur disque . . . . . . . . 526
Comparaison des méthodes de migration de la
Sauvegarde des données des pools de stockage
base de données . . . . . . . . . . . 490
principaux basés sur disque . . . . . . . 527
Changements opérationnels et exigences . . . . 491
Identification et suppression des groupes de
Systèmes automatisés de réponse au message 491
sauvegarde FILE . . . . . . . . . . . 528
Remarques sur les performances . . . . . . 491
Création du fichier d'options du serveur Tivoli
Storage Manager . . . . . . . . . . . 528
Chapitre 19. Planification de la Réexécution de la commande ZMSPREPARE
migration . . . . . . . . . . . . . 495 afin de vérifier les conditions prérequises . . . 528
Configurations matérielle et logicielle requises pour Sauvegarde de la base de données du serveur 530
les serveurs version 5 et 6.3 ou ultérieure . . . . 495 Arrêt du serveur avant la migration . . . . . 530
Compatibilité avec d'autres composants et d'autres Préparation de la base de données d'un serveur
versions . . . . . . . . . . . . . . . 496 version 5 pour la migration. . . . . . . . 531
Estimation de l'espace requis pour la base de
données et le journal de reprise . . . . . . . 497 Chapitre 21. Migration de la base de
Planification des transferts de données depuis les
données du serveur z/OS vers le
périphériques FILE et DISK . . . . . . . . 498
Estimation de l'espace requis pour le stockage et serveur version 6.3 ou ultérieure . . . 533
les périphériques . . . . . . . . . . . . 498 Migration d'un serveur z/OS version 5 via des
Estimation de la durée requise pour la migration 499 supports . . . . . . . . . . . . . . . 533
Exemple - Estimation de la durée de migration Création et formatage de la nouvelle base de
en fonction de la taille de la base de données. . 500 données . . . . . . . . . . . . . . 533
Table des matières ix

Extraction des données sur des supports . . . 533 Partie 4. Annexes . . . . . . . . . 559
Transfert de la bande vers une autre
bandothèque . . . . . . . . . . . . 534
Chargement des données extraites dans la Annexe A. Utilitaires, scripts et
nouvelle base de données . . . . . . . . 534 commandes pour la mise à niveau de
Migration d'un serveur z/OS version 5 via un serveur et la migration . . . . . . . 561
réseau . . . . . . . . . . . . . . . . 536 DSMUPGRD QUERYDB (affichage d'informations
Création et formatage de la nouvelle base de sur une base de données version 5) . . . . . . 561
données . . . . . . . . . . . . . . 536 DSMUPGRD PREPAREDB (préparation d'une base
Transfert de la base de données du serveur via de données version 5 pour la mise à niveau) . . . 561
un réseau. . . . . . . . . . . . . . 536 DELETE VOLHISTORY (Suppression des données
de l'historique des volumes séquentiels) . . . . 562
Chapitre 22. Configuration des DSMUPGRD EXTRACTDB (extraction de données
périphériques de serveur multimédia à partir de la base de données d'un serveur version
5) . . . . . . . . . . . . . . . . . 567
z/OS sur le nouveau serveur . . . . . 539
Fichier manifeste pour l'extraction des données
sur des supports . . . . . . . . . . . 570
Chapitre 23. Exécution des premières DSMUPGRD EXTEND DB (extension de la taille
étapes après la mise à niveau . . . . 541 de la base de données) . . . . . . . . . . 572
Configuration des options de serveur du serveur DSMUPGRD EXTEND LOG ((augmentez la la
migré . . . . . . . . . . . . . . . . 541 taille du journal) . . . . . . . . . . . . 573
Démarrage du serveur . . . . . . . . . . 543 DSMUPGRD UPDATE (Création d'entrées de
Démarrage du serveur à l'aide de l'ID utilisateur registre pour une instance de serveur version 5) . . 574
d'instance . . . . . . . . . . . . . 545 DSMSERV LOADFORMAT (Formatage d'une base
Démarrage du serveur à l'aide de l'ID utilisateur de données) . . . . . . . . . . . . . . 574
root . . . . . . . . . . . . . . . 546 DSMSERV INSERTDB (Déplacement d'une base de
| Démarrage automatique des serveurs . . . . 546 données de serveur vers une base de données
Vérification des résultats de la migration . . . . 548 vide) . . . . . . . . . . . . . . . . 576
Recréation des pools de stockage basés sur disque ZMSPREPARE (Préparez un serveur sur un
et déplacés vers une bande . . . . . . . . . 548 système z/OS en vue d'une migration) . . . . . 579
Recréation des pools de stockage supprimés . . 548 Le script du démarrage du serveur : rc.dsmserv 582
Recréation des volumes de pool de stockage Exemples des commandes à exécuter pour valider
marqués comme détruits . . . . . . . . 549 la mise à niveau de la base de données. . . . . 583
Restauration des données des pools de stockage
sauvegardés . . . . . . . . . . . . . 549 Annexe B. Installation des modules de
Nettoyage en supprimant les volumes DISK et langue du serveur . . . . . . . . . 585
FILE de z/OS marqués comme détruits . . . 550
Environnements locaux de langue du serveur . . 585
Enregistrement des licences. . . . . . . . . 550
Configuration d'un module de langue . . . . . 589
Sauvegarde de la base de données . . . . . . 550
Mise à jour de l'automatisation . . . . . . . 551
Mise à jour de la configuration des agents de Annexe C. Ressources requises pour
stockage . . . . . . . . . . . . . . . 551 le système HP-UX . . . . . . . . . 591
Début des opérations et surveillance des serveurs 552 Estimation des ressources de sémaphore requises 591
Migration des données depuis les volumes Estimation des ressources de processus requises 591
multimédia z/OS vers d'autres périphériques . . 554 Estimation du nombre d'unités d'exécution requises
par processus . . . . . . . . . . . . . 592
Chapitre 24. Identification et Affichage et modification de la configuration du
noyau . . . . . . . . . . . . . . . . 592
résolution des problèmes liés à la
migration d'un serveur version 5 à
Annexe D. Utilisation des zones
partir d'un système z/OS vers AIX ou
Solaris . . . . . . . . . . . . . . 593
Linux on System z . . . . . . . . . 555 Création d'une zone Solaris. . . . . . . . . 593
Restauration du serveur version 5 s'exécutant sous
z/OS après une migration . . . . . . . . . 555
Restauration du serveur version 5 avant le
transfert des données vers le serveur version 6.3
ou ultérieure . . . . . . . . . . . . 555
Restauration du serveur version 5 avant la
suppression des volumes . . . . . . . . 555
Restauration du serveur version 5 après la
suppression de la base de données d'origine . . 556
x IBM Tivoli Storage Manager : Guide de mise à niveau et de migration des serveurs V5
Annexe E. Services associés au Glossaire . . . . . . . . . . . . . 605
serveur Tivoli Storage Manager . . . 597
Index . . . . . . . . . . . . . . . 607
Annexe F. Fonctions d'accessibilité de
la famille de produits Tivoli Storage
Manager . . . . . . . . . . . . . 599
Remarques . . . . . . . . . . . . 601
Marques . . . . . . . . . . . . . . . 603
Table des matières xi

xii IBM Tivoli Storage Manager : Guide de mise à niveau et de migration des serveurs V5
Préface
Cette publication fournit des informations sur la mise à niveau des serveurs IBM®
Tivoli Storage Manager depuis l'un des niveaux de Version 5 pris en charge vers
Version 6.3 ou ultérieure.
A qui s'adresse ce guide

Ce guide s'adresse aux administrateurs chargés de la mise à niveau du serveur
Tivoli Storage Manager version 5 vers la version 6.3 ou ultérieure.
La compréhension des informations fournies dans ce guide requiert des

connaissances dans les domaines suivants :
v Le système d'exploitation et la plateforme sur lesquels sont exécutés les serveurs
v Les opérations d'administration classiques des serveurs Tivoli Storage Manager
mis à niveau
v La capacité de stockage utilisée par les serveurs mis à niveau
v Le réseau auquel se connectent les serveurs
Remarque : Pour obtenir des informations sur la mise à niveau du serveur de V6.1
à V6.3 ou ultérieure et de V6.2 à V6.3 ou ultérieure, voir les procédures de mise à
niveau dans le Guide d'installation.
Comment utiliser ce guide

Pour optimiser l'utilisation de ce guide, suivez la procédure suggérée.
Si vous mettez à niveau le serveur de la V5 vers la V6.3 ou ultérieure sur le même

système d'exploitation, effectuez la séquence suivante :
1. Consultez les informations de présentation concernant les mises à jour du
serveur : Chapitre 1, «Présentation des mises à jour de la base de données du
serveur», à la page 3.
2. Consultez les informations liées à la planification ainsi que les descriptions des
scénarios :
a. Chapitre 2, «Planification de la mise à niveau du serveur», à la page 13
b. Chapitre 3, «Présentation des scénarios de mise à niveau», à la page 85
3. Sélectionnez le scénario à utiliser et planifiez la configuration requise au niveau
du matériel, des logiciels et du stockage pour votre serveur et votre
environnement. Vous pouvez utiliser une feuille de calcul pour la planification
d'espace : «Feuille de calcul pour l'espace de planification du serveur V6.3 ou
ultérieure», à la page 50.
4. Lancez un test du processus de mise à niveau : «Test du processus de mise à
niveau pour un serveur», à la page 56. Utilisez les résultats du test pour affiner
la planification (estimation de la durée d'indisponibilité du serveur suite au
processus de mise à niveau, par exemple).
5. Mettez le serveur à niveau en suivant les étapes du scénario sélectionné :
v Chapitre 4, «Scénario 1 : Même système, via des supports», à la page 103
v Chapitre 5, «Scénario 2 : Même système, via le réseau», à la page 149
v Chapitre 6, «Scénario 3 : Nouveau système, via des supports», à la page 193
© Copyright IBM Corp. 2009, 2013 xiii

v Chapitre 7, «Scénario 4 : Nouveau système, via le réseau», à la page 245
6. Effectuez le processus de mise à niveau en suivant les étapes de la section
suivante :
v Chapitre 10, «Exécution des premières étapes après la mise à niveau», à la
page 355
Si vous mettez à niveau le serveur de la V5 vers la V6.3 ou ultérieure sur un autre

système d'exploitation, effectuez la séquence pour votre chemin de migration
sélectionné :
v Partie 2, «Migration des serveurs V5 Tivoli Storage Manager sur les systèmes
AIX, HP-UX, ou Solaris vers la version V6.3.4 surLinux», à la page 385
v Partie 3, «Migration des serveurs Tivoli Storage Manager version 5 s'exécutant
sur des systèmes z/OS vers la version 6 sous AIX ou Linux on System z», à la
page 475
Publications
Les publications de la famille de produits IBM Tivoli Storage Manager sont
disponibles en ligne. La famille de produits Tivoli Storage Manager inclut IBM
Tivoli Storage FlashCopy Manager, IBM Tivoli Storage Manager for Space
Management, IBM Tivoli Storage Manager for Databases et d'autres produits de
gestion de l'espace de stockage d'IBM Tivoli.
Pour trouver toutes les publications, effectuez votre recherche dans le centre de
documentation de Tivoli Storage Manager approprié :
v Centre de documentation de la version 6.3 : http://pic.dhe.ibm.com/infocenter/
tsminfo/v6r3
v Centre de documentation de la version 6.4 : http://pic.dhe.ibm.com/infocenter/
tsminfo/v6r4
Vous pouvez télécharger les versions PDF des publications à partir du centre de
documentation Tivoli Storage Manager ou du site IBM Publications Center à
l'adresse http://www.ibm.com/shop/publications/order/.
Accédez à Tivoli Documentation Central pour trouver des centres de

documentation contenant la documentation officielle du produit pour les versions
actuelles et précédentes des produits Tivoli, y compris la famille de produits Tivoli
Storage Manager. Vous pouvez trouver Tivoli Documentation Central à l'adresse
http://www.ibm.com/tivoli/documentation.
vous pouvez également commander des publications connexes depuis le site Web
d'IBM Publications Center sur http://www.ibm.com/shop/publications/order/.
Le site web fournit des informations concernant les commandes depuis d'autres
pays que les Etats-Unis. Aux Etats-Unis, vous pouvez commander des publications
en téléphonant au 1-800-879-2755.
Publications Tivoli Storage Manager

Le tableau ci-dessous répertorie les publications qui composent la bibliothèque
Tivoli Storage Manager.
Tableau 1. Publications associées au serveur Tivoli Storage Manager
Titre de la publication Numéro de référence
IBM Tivoli Storage Manager for AIX - Guide d'installation GC11-2950
xiv IBM Tivoli Storage Manager : Guide de mise à niveau et de migration des serveurs V5
Tableau 1. Publications associées au serveur Tivoli Storage Manager (suite)
IBM Tivoli Storage Manager for AIX - Guide d'administration SC11-2773
IBM Tivoli Storage Manager for AIX - Guide de référence SC11-6499
d'administration
IBM Tivoli Storage Manager for HP-UX - Guide d'installation GC11-2157
IBM Tivoli Storage Manager for HP-UX - Guide d'administration SC11-2774
IBM Tivoli Storage Manager for HP-UX - Guide de référence SC11-6501
d'administration
IBM Tivoli Storage Manager for Linux - Guide d'installation SC11-2762
IBM Tivoli Storage Manager for Linux - Guide d'administration SC11-2775
IBM Tivoli Storage Manager for Linux - Guide de référence SC11-6500
d'administration
IBM Tivoli Storage Manager for Oracle Solaris - Guide d'installation SC11-2763
IBM Tivoli Storage Manager for Oracle Solaris - Guide d'administration SC11-2776
IBM Tivoli Storage Manager for Oracle Solaris - Guide de référence SC11-6502
d'administration
IBM Tivoli Storage Manager for Windows - Guide d'installation GC11-6490
IBM Tivoli Storage Manager for Windows - Guide d'administration SC11-2777
IBM Tivoli Storage Manager for Windows - Guide de référence SC11-6503
d'administration
IBM Tivoli Storage Manager for z/OS Media - Guide d'installation et SC11-6982
d'utilisation
IBM Tivoli Storage Manager - Upgrade and Migration Guide for V5 GC11-6978
Servers
IBM Tivoli Storage Manager - Guide d'intégration pour Tivoli Storage SC11-6797
Manager FastBack
Tableau 2. Publications associées à l'agent de stockage Tivoli Storage Manager

IBM Tivoli Storage Manager for SAN for AIX - Guide d'utilisation de SC11-2785
l'agent de stockage
IBM Tivoli Storage Manager for SAN for HP-UX - Guide d'utilisation de SC11-2786
l'agent de stockage
IBM Tivoli Storage Manager for SAN for Linux - Guide d'utilisation de SC11-2787
l'agent de stockage
IBM Tivoli Storage Manager for SAN for Oracle Solaris - Guide SC11-2788
d'utilisation de l'agent de stockage
IBM Tivoli Storage Manager for SAN for Windows - Guide d'utilisation SC11-2789
de l'agent de stockage
Tableau 3. Publications associées au client Tivoli Storage Manager

IBM Tivoli Storage Manager for UNIX and Linux - Guide d'installation SC11-6473
et d'utilisation du client de sauvegarde-archivage
IBM Tivoli Storage Manager for Windows - Guide d'installation et SC11-6474
d'utilisation du client de sauvegarde-archivage
Préface xv
Tableau 3. Publications associées au client Tivoli Storage Manager (suite)
IBM Tivoli Storage Manager - Utilisation de l'interface de programme SC11-6421
d'application
IBM Tivoli Storage Manager for Space Management for UNIX and Linux SC11-6475
- Guide d'utilisation
IBM Tivoli Storage Manager HSM for Windows - Guide d'administration SC11-6520
Tableau 4. Publications associées à la protection des données Tivoli Storage Manager

IBM Tivoli Storage Manager for Databases: Data Protection for Microsoft GC27-4010
SQL Server Installation and User’s Guide
IBM Tivoli Storage Manager for Databases: Data Protection for Oracle for SC11-6983
UNIX and Linux - Guide d'installation et d'utilisation
IBM Tivoli Storage Manager for Databases: Data Protection for Oracle for SC11-6984
Windows - Guide d'installation et d'utilisation
IBM Tivoli Storage Manager for Mail: Data Protection for Microsoft GC27-4009
Exchange Server Installation and User’s Guide
IBM Tivoli Storage Manager for Mail: Data Protection for Lotus Domino SC11-6985
UNIX and Linux - Guide d'installation et d'utilisation
for Windows - Guide d'installation et d'utilisation
IBM Tivoli Storage Manager for Enterprise Resource Planning: Data SC11-2087
Protection for SAP - Guide d'installation et d'utilisation pour DB2
Protection for SAP - Guide d'installation et d'utilisation pour Oracle
IBM Tivoli Storage Manager for Virtual Environments - Guide SC11-6906
d'installation et d'utilisation
IBM Tivoli Storage Manager for Microsoft SharePoint Guide N/A
Tableau 5. Publications relatives à l'identification des problèmes et à l'optimisation d'IBM

Tivoli Storage Manager
IBM Tivoli Storage Manager - Guide d'identification des incidents GC11-6484
IBM Tivoli Storage Manager Optimizing Performance GC11-6485
IBM Tivoli Storage ManagerMessages client et codes retour de l'interface SC11-6798
de programme d'application
IBM Tivoli Storage Manager - Messages du serveur et codes d'erreur SC11-6796
IBM Tivoli Storage Manager for Mail: Data Protection for Microsoft GC27-4011
Exchange Server Messages
IBM Tivoli Storage Manager for Databases: Data Protection for Microsoft GC27-4012
SQL Server Messages
IBM Tivoli Storage Manager for Databases: Data Protection for Oracle - SC11-6979
Messages
- Messages
Protection for SAP - Messages
xvi IBM Tivoli Storage Manager : Guide de mise à niveau et de migration des serveurs V5
Remarque : Des informations sont disponibles sur IBM System Storage Archive
Manager au centre de documentation de Tivoli Storage Manager v6.3.0.
Informations de support
Vous trouverez des informations de support pour les produits IBM à partir de
diverses sources.
Commencez par le portail de support IBM : http://www.ibm.com/support/entry/

portal/. Vous pouvez sélectionner les produits qui vous intéressent et rechercher
une large gamme d'informations associées.
Obtention d'une formation technique

Des informations relatives aux cours de formation technique sur Tivoli sont
disponibles en ligne.
Accédez aux sites Web suivants pour vous abonner aux formations, poser des
questions et interagir avec les autres utilisateurs des produits de stockage IBM.
Formation et certification pour les logiciels Tivoli
Choisissez l'instructeur, la formation par sessions en ligne, les cours sur le
Web personnalisés, la préparation à la certification Tivoli et d'autres
options de formation à l'adresse : http://www.ibm.com/software/tivoli/
education/
Tivoli Support Technical Exchange
Des experts techniques partagent leurs connaissances et répondent à vos
questions au cours de diffusions sur le Web : http://www.ibm.com/
software/sysmgmt/products/support/supp_tech_exch.html.
Communauté Storage Management
Interagissez avec d'autres utilisateurs de produits de gestion de l'espace de
stockage IBM à l'adresse : http://www.ibm.com/developerworks/
servicemanagement/sm/index.html
Communauté globale des utilisateurs de Tivoli
Partagez des informations et apprenez-en plus d'autres utilisateurs Tivoli
dans le monde à l'adresse : http://www.tivoli-ug.org/.
IBM Education Assistant
Visionnez des enregistrements de démonstration conçus pour vous aider à
utiliser les produits logiciels IBM de manière plus efficace à l'adresse :
http://publib.boulder.ibm.com/infocenter/ieduasst/tivv1r0/index.jsp
Recherche dans les bases de connaissances

Plusieurs bases de connaissances peuvent vous aider à résoudre un problème
relatif à la famille de produits Tivoli Storage Manager.
Commencez par rechercher le centre de documentation Tivoli Storage Manager à

l'adresse suivante : http://pic.dhe.ibm.com/infocenter/tsminfo/v6r3. A partir de
ce site Web, vous pouvez rechercher la documentation Tivoli Storage Manager
actuelle.
Préface xvii
Recherche sur Internet
Si vous ne trouvez aucune réponse à votre question dans le centre de
documentation IBM Tivoli Storage Manager, faites une recherche sur Internet pour
obtenir des informations pouvant vous aider à résoudre le problème.
Pour effectuer une recherche dans plusieurs ressources Internet, accédez au site
Web de support IBM à l'adresse http://www.ibm.com/support/entry/portal/.
Vous pouvez rechercher des informations sans vous abonner. Connectez-vous à

l'aide de votre ID et mot de passe IBM si vous souhaitez personnaliser le site en
fonction de votre utilisation du produit et de vos besoins en informations. Si vous
ne disposez pas déjà d'un ID et d'un mot de passeIBM, cliquez sur Sign in
(Abonnement) en haut de la page et suivez les instructions d'enregistrement.
Sur ce site Web de support, vous pouvez rechercher différentes ressources comme :
v Notes techniques IBM.
v Téléchargements IBM.
v Publications IBM Redbooks.
v IBM Authorized Program Analysis Reports (rapports officiels d'analyse de
programme). Sélectionnez le produit et cliquez sur Downloads
(Téléchargements) pour consultez la liste APAR.
Si vous ne trouvez aucune solution permettant de résoudre cet incident, vous

pouvez effectuer des recherches dans les forums et groupes de discussion
disponibles sur Internet pour obtenir les informations les plus récentes susceptibles
de vous aider.
Une liste indépendante de débats entre utilisateurs ADSM-L est proposée par by
Marist College. Vous pouvez vous abonner en envoyant un e-mail à
listserv@vm.marist.edu. Le corps du message doit contenir le texte suivant :
SUBSCRIBE ADSM-L your_first_name your_family_name.
Pour partager vos expériences et apprendre des autres dans les communautés
Tivoli Storage Manager et d'Tivoli Storage FlashCopy Managerutilisateurs, accédez
à Service Management Connect (http://www.ibm.com/developerworks/
servicemanagement/sm/index.html). De là, vous pouvez trouver des liens pour
produire des wikis et des communautés d'utilisateurs.
Utilisation d'IBM Support Assistant

IBM Support Assistant est un logiciel complémentaire qui peut vous aider à définir
les problèmes. Il est disponible pour certains produits Tivoli Storage Manager et
Tivoli Storage FlashCopy Manager.
Pour savoir quels produits sont pris en charge, accédez à la page Web de
téléchargement d'IBM Support Assistant à l'adresse : http://www.ibm.com/
software/support/isa/download.html.
IBM Support Assistant vous aide à regrouper des informations de support lorsque
vous devez ouvrir un PMR (Problem management record), vous permettant ainsi
d'assurer le suivi d'un problème. Les modules d'extension, propres à chaque
produit, fournissent les ressources suivantes :
v des liens vers des services de support,
v des liens vers des services de formation,
v la capacité de soumettre des enregistrements de gestion d'incidents.
xviii IBM Tivoli Storage Manager : Guide de mise à niveau et de migration des serveurs V5
Vous trouverez des informations sur le site Web d'IBM Support Assistant :
http://www.ibm.com/software/support/isa/
Vous pouvez également installer l'application IBM Support Assistant autonome sur
un poste de travail. Pour en améliorer les fonctionnalités, vous pouvez installer des
modules d'extension spécialement conçus pour les produits IBM que vous utilisez.
Recherchez sur le site suivant des compléments aux produits spécifiques :
http://www.ibm.com/support/docview.wss?uid=swg27012689.
Recherche des correctifs du produit

Un correctif produit permettant de résoudre l'incident peut être disponible sur le
site Web du service de support logiciel IBM.
Vous pouvez déterminer quels correctifs sont disponibles en consultant le site Web
de support logiciel IBM à l'adresse http://www.ibm.com/support/entry/portal/.
v Si vous avez précédemment personnalisé le site en fonction de votre utilisation
du produit :
1. Cliquez sur le lien de votre produit ou d'un composant pour lequel vous
souhaitez trouver un correctif.
2. Cliques sur Downloads (Téléchargements), puis sur Fixes by version
(Correctifs par version).
v Si vous n'avez pas personnalisé le site en fonction de votre utilisation du
produit, cliquez sur Downloads (Téléchargements) et recherchez votre produit.
Réception d'une notification sur les correctifs de produit

Vous pouvez recevoir des notifications concernant les correctifs, les flash, les mises
à niveau et d'autres nouveautés concernant les produits IBM.
Pour vous abonner pour recevoir des notifications sur les produits IBM, procédez
comme suit :
1. A partir de la page de support à l'adresse http://www.ibm.com/support/
entry/portal/, cliquez sur Sign in to create, manage, or view your
subscriptions dans la sous-fenêtre Notifications.
2. Abonnez-vous en utilisant votre ID et votre mot de passe IBM. Si vous ne
possédez pas encore d'ID et de mot de passe IBM, cliquez sur register now et
complétez le processus d'enregistrement.
3. Cliquez sur Manage all my subscriptions dans la sous-fenêtre Notifications.
4. Cliquez sur l'onglet Subscribe, puis sur Tivoli.
5. Sélectionnez les produits pour lesquels vous souhaitez recevoir des notifications
et cliquez sur Continue.
6. Indiquez vos préférences de notification et cliquez sur Submit.
Contacter le service de support logiciel IBM

Vous pouvez contacter le service de support logiciel IBM si vous disposez d'un
contrat actif d'abonnement et de support IBM et si vous êtes autorisé à soumettre
des problèmes à IBM.
Pour obtenir de l'aide à partir du service de support logiciel IBM, procédez comme
suit :
1. Vérifiez que vous avez satisfait les prérequis suivants :
a. Configurez un contrat d'abonnement et de support.
Préface xix
b. Déterminez l'impact de l'incident sur vos activités.
c. Décrivez votre problème et recueillez des renseignements sur le contexte.
2. Suivez les instructions de «Soumission du problème au service de support
logiciel IBM», à la page xxi.
Configuration d'un contrat d'abonnement et de support

Configurez un contrat d'abonnement et de support. Le type de contrat de
maintenance dont vous avez besoin dépend du type de produit dont vous
disposez.
Pour les logiciels distribués IBM (notamment, liste non exhaustive, les produits
IBM Tivoli, Lotus et Rational, de même que les produits IBM DB2 et IBM
WebSphere s'exécutant sur les systèmes d'exploitation Microsoft Windows ou AIX
ou encore Linux), inscrivez-vous à IBM Passport Advantage de l'une des manières
suivantes :
v En ligne : Visitez le site Web de Passport Advantage à l'adresse
http://www.ibm.com/software/lotus/passportadvantage/, cliquez sur How to
enroll et suivez les instructions fournies.
v Par téléphone : Vous pouvez composer le 1-800-IBMSERV (1-800-426-7378) aux
Etats-Unis. Pour connaître le numéro de téléphone correspondant à votre pays,
accédez à la page Web du Guide de l'assistance logicielle IBM à l'adresse
http://www14.software.ibm.com/webapp/set2/sas/f/handbook/home.html et
cliquez sur Contacts.
Détermination de l'impact commercial

Lorsque vous soumettez un incident à IBM, il vous est demandé d'indiquer son
niveau de gravité. Vous devez donc comprendre et évaluer l'incidence commerciale
du problème que vous signalez.
Gravité 1 Incidence commerciale critique : il vous est impossible d'utiliser

le logiciel, ce qui se traduit par une incidence critique sur les
activités. Cette situation exige une solution immédiate.
Gravité 2 Incidence commerciale significative : le logiciel est utilisable,
mais gravement limité.
Gravité 3 Incidence commerciale notable : le logiciel est utilisable, les
fonctions secondaires (non critiques pour l'activité) étant toutefois
indisponibles.
Gravité 4 Incidence commerciale minimale : soit le problème entraîne une
faible incidence sur l'activité, soit un palliatif raisonnable au
problème a été appliqué.
Description du problème et collecte des informations

d'arrière-plan
Lorsque vous décrivez un incident à IBM, il est utile d'être aussi précis que
possible. Incluez toutes les informations possibles afin que les spécialistes du
support logiciel IBM puissent vous aider à résoudre efficacement l'incident.
Pour gagner du temps, connaissez les réponses à ces questions :

v Quelles versions des logiciels exécutiez-vous lorsque le problème est survenu ?
v Disposez-vous d'historiques, traces ou messages concernant les symptômes du
problème ? Il est probable que le service de support logiciel IBM vous demande
ces informations.
xx IBM Tivoli Storage Manager : Guide de mise à niveau et de migration des serveurs V5
v Le problème peut-il être recréé ? Dans l'affirmative, quelles étapes ont abouti à
l'incident ?
v Des modifications ont-elles été apportées au système ? Celles-ci peuvent
concerner le matériel, le système d'exploitation, le logiciel de mise en réseau, etc.
v Recourez-vous actuellement à une solution palliative à ce problème ? Si oui,
soyez prêt à la décrire lors de la soumission de l'incident.
Soumission du problème au service de support logiciel IBM

Vous pouvez soumettre le problème au service de support logiciel IBM en ligne ou
par téléphone.
En ligne
Accédez au site Web du service de support logiciel IBM à l'adresse
http://www.ibm.com/support/entry/portal/Open_service_request/
Software/Software_support_(general). Abonnez-vous pour accéder aux
demandes de service IBM et entrez les informations requises dans l'outil de
soumission de problème.
Par téléphone
Pour connaître le numéro de téléphone correspondant à votre pays,
accédez à la page Web du Guide de l'assistance logicielle IBM à l'adresse
http://www14.software.ibm.com/webapp/set2/sas/f/handbook/
home.html et cliquez sur Contacts.
Préface xxi
xxii IBM Tivoli Storage Manager : Guide de mise à niveau et de migration des serveurs V5
Nouveautés de la version 6.3
La présente section résume les changements apportés à IBM Tivoli Storage
Manager Version 6.3.
Mises à jour du serveur

Les nouvelles fonctionnalités et autres modifications sont disponibles dans le
serveur IBM Tivoli Storage Manager version 6.3. Les mises à jour techniques
apportées depuis la précédente édition sont signalées par une barre verticale ( | )
dans la marge de gauche.

Le groupe de correctifs 6.3.4 du serveur contient de nouvelles fonctions, en plus
des correctifs d'incidents.
Le serveur inclus avec les produits Tivoli Storage Manager et IBM Tivoli Storage
Manager Extended Edition version 6.4 sont au niveau version 6.3.4. Le serveur
version 6.3.4 est également disponible en téléchargement séparé, en tant que
groupe de correctifs pour les utilisateurs actuels de la version 6.3.
| Migration Tivoli Storage Manager vers la V6.3.4 ou ultérieure

| sous Linux x86_64
| Vous pouvez maintenant migrer un serveur Tivoli Storage Manager version 5 qui
| s'exécute sur un système d'exploitation AIX, HP-UX, ou Solaris vers la version 6.3.4
| ou ultérieur sur un système d'exploitation Linux x86_64.
| En fonction de votre environnement matériel et logiciel, cette procédure de

| migration peut être utile pour la consolidation du serveur, l'équilibrage de charge
| ou la standardisation sur le système d'exploitation Linux.
| Centre d'opérations IBM Tivoli Storage Manager

| Centre d'opérations IBM Tivoli Storage Manager V6.4.1 est une nouvelle interface
| utilisateur Web permettant de gérer un environnement de stockage.
| Centre d'opérations V6.4.1 contient une page de présentation de l'interaction des

| serveurs et clients Tivoli Storage Manager. Vous pouvez utiliser le Centre
| d'opérations pour identifier rapidement les problèmes potentiels, gérer les alertes
| et accéder à la ligne de commande Tivoli Storage Manager. L'interface centre
| d'administration est également disponible, mais le Centre d'opérations est
| l'interface de surveillance préférée.
| Mises à jour Tivoli Monitoring for Tivoli Storage Manager

| Tivoli Monitoring for Tivoli Storage Manager version 6.3.4 inclut certains nouveaux
| rapports Cognos, et des fonctions, y compris des méthodes pour la distribution des
| rapports Cognos à d'autres organisations.
| Les nouveaux rapports Cognos suivants sont disponibles :

| Rapports de statut
| v Récapitulatif et détails de stockage du client
| v statut d'activité VE
© Copyright IBM Corp. 2009, 2013 xxiii

| v Récapitulatif du type de sauvegarde VE
| v Récapitulatif de l'occupation actuelle
| Rapports de tendance
| v Tendances d'utilisation du stockage du client
| Pour autoriser le partage des rapports, les rapports Cognos peuvent être exportés
| et importés dans d'autres instances Tivoli Common Reporting.
| L'espace de travail Journal d'agent est amélioré pour afficher si les serveurs
| surveillés sont installés et exécutés.
| Les valeurs d'élagage sont automatiquement configurées maintenant au cours de

| nouvelles installations. Si vous avez effectué la mise à niveau de l'application, vous
| devez configurer manuellement les paramètres d'élagage pour supprimer
| périodiquement les données de la base de données WAREHOUS.

des correctifs d'incident.
Le serveur inclus avec les produits Tivoli Storage Manager et IBM Tivoli Storage
Manager Extended Edition version 6.4 sont au niveau version 6.3.3. Le serveur
version 6.3.3 est également disponible en téléchargement séparé, en tant que
groupe de correctifs pour les utilisateurs actuels de la version 6.3.
Mots de passe authentifiés par LDAP

IBM Tivoli Storage Manager Le serveur V6.3.3 peut utiliser un serveur d'annuaire
LDAP pour authentifier les mots de passe. Les mots de passe authentifiés par
LDAP vous offrent un niveau supplémentaire de sécurité en étant sensibles à la
casse, en offrant une application de la règle de mots de passe avancée, et un
serveur centralisé sur lequel les authentifier.
Vous devez avoir un serveur d'annuaire LDAP sur lequel authentifier une
représentation hachée du mot de passe. Après avoir configuré le serveur Tivoli
Storage Manager, vous pouvez authentifier les mots de passe d'administrateur et
de noeud avec le serveur d'annuaire LDAP.
Les deux méthodes d'authentification sont LDAP et LOCAL. LOCAL signifie que
le mot de passe est authentifié avec le serveur Tivoli Storage Manager.
Les mots de passe qui sont authentifiés avec le serveur Tivoli Storage Manager ne
sont pas sensibles à la casse. Tous les mots de passe peuvent être composés de
caractères issus de la liste suivante :
a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9
~ ! @ # $ % ^ & * _ - + = ` | ( ) { } [ ] : ; < > , . ? /
Restriction : Les noeuds clients doivent être de V6.4 ou ultérieure pour utiliser le
serveur d'annuaire LDAP afin d'authentifier les mots de passe.
Prévention des conflits par le pilote du périphérique

Solaris
xxiv IBM Tivoli Storage Manager : Guide de mise à niveau et de migration des serveurs V5
Sur les systèmes Oracle Solaris, le pilote de bande générique SCSI (pilote st) prend
automatiquement en charge les pilotes au démarrage du système. Si un pilote est
également configuré par le Tivoli Storage Manager pilote du périphérique ou par
le pilote du périphérique de bande IBM, les données sont écrasées car plusieurs
pilotes ont accès au même périphérique grâce à l'utilisation d'un nom différent.
Utilisez la fonction rmstdev pour supprimer les fichiers du périphérique qui sont
créés par le pilote st Oracle Solaris pour toutes les unités de bande qui sont
également configurées par le Tivoli Storage Manager pilote du périphérique ou par
le pilote du périphérique de bande IBM. La suppression de ces fichiers garantit
qu'un seul pilote a accès à une unité de bande.
La fonction rmstdev fonctionne lorsque le serveur démarre automatiquement. Si le

démarrage n'est pas automatique, vous devez exécuter la fonction manuellement
en tant qu'utilisateur root avant de démarrer le Tivoli Storage Manager serveur.
Mises à jour Tivoli Monitoring for Tivoli Storage Manager

Tivoli Monitoring for Tivoli Storage Manager inclut à présent certains nouveaux
espaces de travail Tivoli Enterprise Portal, de nouveaux rapports Cognos, et
l'option permettant aux clients existants IBM Tivoli Monitoring d'installer et de
déployer des agents de surveillance à partir d'un petit module d'agent.
Les nouveaux rapports Cognos sont :

Rapports de statut :
v Statut d'activité de client
v Actualité de la sauvegarde client
v Statut de sauvegarde client
v Etat du planning client
v Récapitulatif d'utilisation du pool de stockage client
v Récapitulatif de l'occupation actuelle du client
v Récapitulatif du pool de stockage actuel
v Plus forte utilisation de l'espace de stockage
v Statut de planification du serveur
v Planifications client manquées et échouées la veille
Rapports de tendance
v Taux de succès de l'activité client
v Taux de succès de la planification client
v Tendances de croissance de la base de données du serveur
v Tendances de croissance de l'espace de stockage du serveur
Les nouveaux espaces de travail de surveillance Tivoli Enterprise Portal sont les
suivants :
v L'espace de travail du résumé de l'activité qui fournit des données sur le serveur
et les opérations clientpour des environnements virtuels et non virtuels.
v L'espace de travail des sessions qui fournit une vue de toutes les sessions de
client actives fonctionnant sur le serveur spécifique.
Des informations de sauvegarde VMware supplémentaires sont désormais fournies

dans le journal d'activité du serveur Tivoli Storage Manager et dans la table
récapitulative pour les opérations de protection des données pour VMware. Ces
Nouveautés de la version 6.3 xxv

nouvelles informations offrent une collecte de données et un contenu de rapports
lorsque vous utilisez des fonctions de génération de rapports telles que Tivoli
Common Reporting.
Une nouvelle option permettant d'activer l'authentification LDAP en créant et en

configurant des instances en créant et en configurant les instances de contrôle de
l'agent.
La capacité améliorée à exclure ou à filtrer les numéros de messages pour affiner

les résultats.
Les utilisateurs existants IBM Tivoli Monitoring peuvent désormais installer le petit
package d'agents et déployer à distance des agents de surveillance sans avoir à
télécharger le plus grand package Tivoli Monitoring for Tivoli Storage Manager.
Contrôle des connexions inactives de l'opération NDMP

Le signal de présence Transmission Control Protocol (TCP) est un mécanisme par lequel
de petits paquets de données sont envoyés sur le réseau à des intervalles
prédéfinis. Les paquets empêchent la fermeture d'une connexion à exécution
longue et inactive par le logiciel de pare-feu, qui détecte et ferme les connexions
inactives. Dans cette version, vous pouvez activer la fonction de signal de présence
TCP pour les connexions de contrôle NDMP.
Améliorations pour le traitement à l'expiration

Des améliorations de l'inventaire à l'expiration sont disponibles dans cette édition.
Le traitement de noeuds peut désormais être réparti sur plusieurs unités
d'exécution en parallèle, au niveau de l'espace fichier. Cette modification de
processus permet de répartir la charge de travail et d'éviter plus efficacement les
goulots d'étranglement pour les noeuds qui prennent en charge les serveurs
virtuels.

des correctifs d'incident.
Validation des données au cours des opérations de

lecture/écriture sur bande
Avec la protection de bloc logique, IBM Tivoli Storage Manager comprend une
valeur de contrôle de redondance cyclique à la fin de chaque bloc logique de
données, à écrire sur bande. Vous pouvez spécifier la validation de bloc de
données CRC au cours des opérations de lecture et d'écriture, ou uniquement au
cours des opérations d'écriture.
Vous pouvez utiliser la protection de bloc logique uniquement avec les types
d'unités et de support suivants :
v IBM LTO5 et versions ultérieures
v IBM 3592 Generation 3 unités, et ultérieures, avec support 3592 Generation, et
ultérieures

Les nouvelles fonctionnalités et autres modifications sont disponibles dans le
serveur Tivoli Storage Manager version 6.3.
xxvi IBM Tivoli Storage Manager : Guide de mise à niveau et de migration des serveurs V5
Réplication de poste
La réplication de poste est le processus consistant à copier de manière incrémentielle
ou à répliquer les données des postes client d'un serveur Tivoli Storage Manager
vers un autre serveur Tivoli Storage Manager à des fins de reprise après incident.
Le serveur à partir duquel les données du poste client sont répliquées est appelé
serveur de réplication source. Le serveur sur lequel les données de poste client sont
répliquées est appelé serveur de réplication cible.
La réplication de poste évite la logistique et les risques liés au déplacement

physique de supports de bande vers un emplacement distant. Si un incident se
produit et que le serveur de réplication source n'est pas disponible, les clients de
sauvegarde-archivage de Tivoli Storage Manager peuvent récupérer leurs données
auprès du serveur de réplication cible. Si vous ne parvenez pas à récupérer le
serveur de réplication source, vous pouvez convertir les postes client vers des
postes sans réplication pour les opérations de stockage sur le serveur de réplication
cible.
Si vous utilisez les fonctions d'exportation et d'importation de Tivoli Storage

Manager pour stocker les données de poste client sur un serveur de reprise après
incident, vous pouvez convertir les postes en postes de réplication. Lors de la
réplication des données, vous pouvez aussi utiliser le dédoublonnage des données
pour réduire les besoins en termes de bande passante et de stockage.
Les serveurs Tivoli Storage Manager 6.3 peuvent être utilisés pour la réplication de
poste. Vous pouvez cependant répliquer des données pour des postes client de la
version 6.3 ou antérieure. Vous pouvez aussi répliquer des données qui ont été
stockées sur un serveur Tivoli Storage Manager version 6.2 ou antérieure avant
votre mise à niveau vers la version 6.3.
Vous ne pouvez pas répliquer des noeuds à partir d'un serveur Tivoli Storage
Manager version 6.3.3 sur un serveur qui s'exécute à un niveau antérieur de Tivoli
Storage Manager.
Dédoublonnage de données de serveur de fichiers NetApp

Le dédoublonnage de données appartenant aux serveurs de fichiers de l'unité de
stockage réseau est désactivé par défaut. Pour activer le dédoublonnage des
données du serveur NetApp, utilisez la nouvelle option de serveur
ENABLENASDEDUP.
Réorganisation des tables et index de la base de données

Si la réorganisation automatique des tables et index affecte la performance du
serveur, vous pouvez planifier manuellement des réorganisations.
Déploiement automatique du client de sauvegarde-archivage

Il est possible de planifier IBM Tivoli Storage Manager version 6.3 pour déployer
automatiquement le logiciel du client de sauvegarde-archivage sur tous les postes
de travail sur lesquels le client de sauvegarde-archivage est installé.
Vous pouvez déployer des clients de sauvegarde-archivage sur des systèmes

d'exploitation Microsoft Windows à partir d'un groupe de correctifs ou de
correctifs temporaires pour toutes les éditions de la version 5.4 ou des versions
supérieures. Vous pouvez migrer le client de sauvegarde-archivage vers un niveau
de version, d'édition, de modification ou de groupe de correctifs de la version 5.5
et des versions supérieures.
Nouveautés de la version 6.3 xxvii

Vous pouvez déployer des clients de sauvegarde-archivage sur des systèmes
d'exploitation autres que Windows à partir de toutes les éditions de la version 5.5
ou des versions supérieures. Ces clients de sauvegarde-archivage peuvent
fonctionner sur tous les niveaux de version, d'édition, de modification ou de
groupe de correctifs suivants. Vous pouvez coordonner les mises à jour de chaque
client de sauvegarde-archivage à partir du centre d'administration.
Traitement en flux continu de sauvegarde et de restauration

Plusieurs flux de données simultanés peuvent réduire la durée requise pour
sauvegarder ou restaurer la base de données. Vous pouvez spécifier plusieurs flux
de données simultanés pour des opérations de sauvegarde de base de données
automatiques ou manuelles.
Au cours des opérations de restauration, le serveur Tivoli Storage Manager tente

d'utiliser le même nombre de flux de données que celui que vous avez indiqué
pour l'opération de sauvegarde. Supposons par exemple que vous spécifiez quatre
flux de données pour une opération de sauvegarde de base de données. Lors d'une
opération de restauration, le serveur tente d'utiliser quatre unités. Si une unité est
hors ligne et indisponible, le serveur utilise trois unités pour l'opération de
restauration.
Le bénéfice des flux de données multiples et simultanés dépend de la taille de la

base de données. En règle générale, si la base de données fait moins de 100 Go, le
nombre de fois où vous pouvez sauvegarder est relativement réduit. Les flux de
données multiples et simultanés utilisent également plus de volumes. Si les
volumes sont de haute capacité et que vous utilisez la compression de données,
cela peut avoir pour conséquence un gaspillage de l'espace.
Mises à jour Tivoli Monitoring for Tivoli Storage Manager

IBM Tivoli Monitoring for Tivoli Storage Manager, précédemment appelé fonction
de génération de rapports et de surveillance, dispose d'un assistant d'installation
amélioré. Cognos est maintenant inclus pour la création de rapports personnalisés.
Les mises à jour apportées à Tivoli Monitoring for Tivoli Storage Manager incluent
les éléments suivants :
v Cognos Business Intelligence V8 est une suite d'information décisionnelle fournie
avec Tivoli Common Reporting. Tivoli Common Reporting fait partie de
l'installation du centre d'administration, lorsque vous sélectionnez le composant
Tivoli Common Reporting. Pour plus d'informations, voir Customizing reports
with Cognos Business Intelligence à la section Monitoring operations du Guide
d'administration. Toutes les informations relatives aux rapports client et serveur
sont également accessibles dans cette section.
v Le processus d'installation a été amélioré pour inclure un vérificateur des
prérequis. Il exécute maintenant automatiquement toutes les tâches de
configuration de l'installation.
v Un espace de travail personnalisable a été ajouté au tableau de bord pour
afficher de nombreux éléments fréquemment visualisés en une seule vue. Ce
paramètre par défaut permet au tableau de bord d'afficher des données relatives
à l'espace de stockage utilisé par poste, les planifications client et serveur n'ayant
pas abouti ainsi que des détails sur les pools de stockage, les unités et les
messages d'erreur du journal d'activité.
v Vous pouvez inclure plusieurs serveurs dans un seul rapport. Les rapports ont
été améliorés pour affiner les données affichées.
v Les nouveaux espaces de travail Tivoli Enterprise Portal sont les suivants :
journal d'activité, journal d'agent, mises à jour du statut du poste client, unités,
xxviii IBM Tivoli Storage Manager : Guide de mise à niveau et de migration des serveurs V5
bibliothèques, taux d'occupation, détails relatifs aux valeurs par coeur de
processeur et statut et détails de la réplication.
v De nouveaux rapports client sont disponibles : détails sur le support du pool de
stockage, détails sur le récapitulatif du stockage, détails sur la réplication,
croissance de la réplication et récapitulatif de la réplication.
v De nouveaux rapports serveur sont disponibles : détails sur le journal d'activité,
capacité de traitement du serveur et rapport mis à jour sur la capacité de
traitement du serveur pour les données collectées par des agents avant la
version 6.3.
Estimation des unités de valeur par coeur de processeur

Vous pouvez utiliser de nouvelles méthodes pour obtenir des informations sur le
nombre d'unités client et serveur connectées au système et l'utilisation d'unités de
valeur par coeur de processeur par unités de serveur. Ces nouvelles méthodes
fournissent des informations pour vous aider à évaluer la conformité à la licence
du système Tivoli Storage Manager.
A l'aide de la nouvelle commande QUERY PVUESTIMATE, vous pouvez créer des

rapports qui évaluent le nombre d'unités de serveur et d'unités de client gérées par
le serveur Tivoli Storage Manager. Vous pouvez également afficher des
informations PVU par poste. Ces rapports ne sont pas juridiquement contraignants
mais fournissent un point de départ pour la détermination des conditions de
licence. Vous pouvez également afficher des informations PVU dans le centre
d'administration. Le centre d'administration fournit des récapitulatifs des unités
client, des unités serveur et des valeurs par coeur de processeur ainsi que d'autres
informations détaillées.
A des fins d'estimation des valeurs par coeur de processeur, seuls les postes sous
Windows 7, Windows XP Professional et Apple sont considérés comme des unités
client par défaut. Les postes des autres plateformes sont quant à eux considérés
comme des unités serveur par défaut. Vous pouvez mettre à jour la classification
de rôle en exécutant la commande UPDATE NODE. Vous pouvez également afficher et
modifier les classifications de rôle sur l'ordinateur portable du poste client centre
d'administration.
Pour obtenir un rapport détaillé, exécutez la commande SQL SELECT * FROM

PVUESTIMATE_DETAILS. Cette commande extrait des informations au niveau du
poste. Ces données peuvent être exportées vers une feuille de calcul et modifiées
pour mieux représenter l'environnement système.
Pour plus d'informations sur les calculs PVU et leur utilisation à des fins d'octroi
de licence, voir la rubrique décrivant le rôle des PVU dans Guide d'administration.
Vérificateur des prérequis

Tivoli Storage Manager version 6.3 inclut un vérificateur des prérequis, outil
pouvant être exécuté avant le démarrage de l'installation de Tivoli Storage
Manager.
Le vérificateur des prérequis vérifie les conditions requises pour le serveur Tivoli
Storage Manager, le centre d'administration et Tivoli Monitoring for Tivoli Storage
Manager. Il vérifie le système d'exploitation, le volume d'espace disque disponible,
la mémoire requise pour le serveur ainsi que d'autres conditions prérequises.
L'outil présente un récapitulatif des résultats, vous informe des modifications
requises dans votre environnement avant l'installation et crée des répertoires
requis. De cette manière, le vérificateur des prérequis peut aider à simplifier le
processus d'installation.
Nouveautés de la version 6.3 xxix

Pour plus d'informations, voir la section sur l'exécution du programme de
vérification des conditions d'installation dans Guide d'installation.
Mises à jour de l'unité de stockage

La prise en charge d'une nouvelle unité ainsi que d'autres modifications apportées
aux unités de stockage sont disponibles dans Tivoli Storage Manager version 6.3.
Bandothèques virtuelles :
Grâce aux améliorations disponibles dans la version 6.3, vous pouvez définir une
bibliothèque comme bandothèque virtuelle (VTL) sur Tivoli Storage Manager.
Les VTL utilisent généralement des sous-systèmes de disques pour stocker des
données en interne. Comme elles n'utilisent pas de support de bande, vous pouvez
dépasser les fonctions d'une bandothèque physique lors de l'utilisation de l'espace
de stockage VTL. Avec une VTL, vous pouvez définir le nombre de volumes et
d'unités, ce qui offre une plus grande flexibilité de l'environnement de stockage et
augmente la productivité en autorisant des montages et des E-S de bande
simultanés.
Formatage plus rapide des volumes DISK et des volumes FILE préalloués :
AIX HPUX Linux Solaris
Sur certains systèmes de fichiers Linux et UNIX, notamment ext4 sous Linux et
JFS2 sous AIX, IBM Tivoli Storage Manager formate des volumes à accès aléatoire
et des volumes de disque à accès séquentiel préalloués quasiment instantanément.
Par exemple, Tivoli Storage Manager peut formater un volume FILE ou DISK sous
JFS2 en moins d'une seconde.
La nouvelle méthode de formatage des volumes sur certains systèmes Linux et

UNIX est similaire à la méthode utilisée par Tivoli Storage Manager pour formater
des volumes sous Windows.
La nouvelle méthode offre les avantages suivants :

v Lors du formatage du volume, les E-S sont négligeables et n'affectent pas la
performance. Par exemple, si vous exécutez une opération de serveur et que
vous avez besoin d'un volume supplémentaire, vous pouvez formater le volume
sans affecter la performance de l'opération en cours.
v Le stockage du système de fichiers est alloué pour toute la taille du fichier sans
écrire de blocs et sans créer de fichiers fractionnés. Par exemple, lorsque vous
utilisez la commande DEFINE VOLUME pour créer un volume de 10Go, le fichier
sous-jacent dans le système fichier consomme 10Go de stockage. Comme la taille
du volume FILE ne change pas, les fichiers journaux du système de fichiers ne
nécessitent pas d'une mise à jour constante.
v Le risque de fragmentation du fichier est réduit.
Avant d'utiliser la nouvelle méthode de formatage des volumes, Tivoli Storage

Manager vérifie le système de fichiers pour déterminer s'il prend en charge cette
méthode. Si ce n'est pas le cas, Tivoli Storage Manager utilise l'ancienne méthode.
Accès aux unités de stockage liées par FICON sur un système z/OS :
La base de données d'un serveur Tivoli Storage Manager version 5 s'exécutant sur
un système z/OS peut être migrée vers un serveur 6.3 s'exécutant sous AIX ou
Linux sous System z. Après la mise à niveau, les utilisateurs z/OS peuvent
xxx IBM Tivoli Storage Manager : Guide de mise à niveau et de migration des serveurs V5
toujours accéder aux données stockées sur des volumes de bande dont le contenu
est accessible via des unités de stockage liées par FICON.
Le serveur Tivoli Storage Manager 6.3 accède aux données client à l'aide d'une
unité de stockage liée à z/OS. L'unité de stockage est rendue disponible par IBM
Tivoli Storage Manager for z/OS Media.
De plus, Tivoli Storage Manager for z/OS Media facilite l'accès aux fichiers
linéaires VSAM (Virtual Storage Access Method) sous z/OS en utilisant une
méthode de stockage FILE séquentielle améliorée.
Pour plus d'informations, voir la section sur la migration de serveur Tivoli Storage
Manager sur systèmse z/OS vers la version 6 dans Tivoli Storage Manager Upgrade
and Migration Guide for V5 Servers.
Mode Append-only pour les unités IBM LTO-5 :
L'option de serveur CHECKTAPEPOS permet au serveur Tivoli Storage Manager de

vérifier la validité et la cohérence des positions des blocs de données sur une
bande.
Les améliorations apportées à cette option permettent à une unité de rechercher les
problèmes d'écrasement de données avant chaque opération d'écriture et
permettent à Tivoli Storage Manager de repositionner des bandes à l'emplacement
approprié et de poursuivre l'écriture des données. Utilisez l'option CHECKTAPEPOS
avec des unités LTO Generation 5 IBM.
Remarque : Vous pouvez activer le mode d'ajout uniquement pour IBM LTO
Generation 5 et les unités ultérieures et pour les unités qui prennent en charge
cette fonction.
Réservation persistante pour des unités de bande :
La réservation persistante permet de libérer des réservations d'unités de bande à

partir d'autres serveurs en cas, par exemple, de panne d'un serveur.
Dans Tivoli Storage Manager version 6.3, la réservation persistante est activée pour
des unités et des niveaux d'unité prenant en charge la fonction.
Pour plus de détails sur la prise en charge de la réservation persistante, voir

http://www.ibm.com/support/docview.wss?uid=swg21470319.
Mises à jour du centre d'administration

Une nouvelle prise en charge du centre d'administration est disponible dans Tivoli
Storage Manager version 6.3.
Tivoli Integrated Portal version 2.1 : AIX Linux Solaris Windows
Le centre d'administration Tivoli Storage Manager utilise Tivoli Integrated Portal

pour son interface utilisateur graphique (GUI). Avec Tivoli Integrated Portal 2.1,
vous pouvez maintenant surveiller le centre d'administration avec Internet
Explorer 8 et Mozilla Firefox 3.5. Tous les navigateurs que vous avez utilisés avec
Tivoli Integrated Portal version 1.1.1 et versions ultérieures peuvent être utilisés
avec cette dernière version.
Nouveautés de la version 6.3 xxxi

Lorsque vous installez Tivoli Integrated Portal 2.1, l'installation de Tivoli Common
Reporting, d'un service de sécurité intégré ou du service de planification est
facultative. Ces fonctions peuvent être ajoutées et enregistrées sur Tivoli Integrated
Portal 2.1 par la suite.
Mises à jour du domaine de règles centre d'administration :
Grâce aux améliorations apportées au centre d'administration, vous pouvez

maintenant spécifier des paramètres d'archive basés sur les événements à l'aide des
assistants Domaine de règles et Classe de gestion.
Si vous avez défini une période de rétention des archives pour un objet via le
serveur, vous pouvez mettre à jour ces paramètres à l'aide du bloc-notes Classe de
gestion du centre d'administration.
La définition d'une période de rétention des archives permet de s'assurer que des
objets ne sont pas supprimés du serveur Tivoli Storage Manager tant que les
critères de conservation basés sur des règles ne sont pas remplis.
Analyse des données de performances du client :
Grâce à la nouvelle fonction Client Performance Monitor, vous pouvez rassembler

et analyser des données de performances sur les opérations de sauvegarde et de
restauration d'un client IBM Tivoli Storage Manager.
La fonction Client Performance Monitor est accessible depuis le centre

d'administration Tivoli Storage Manager et utilise des données collectées par
l'interface de programme d'application. Vous pouvez afficher des informations de
performances sur l'utilisation du processeur, du disque, du réseau ainsi que sur les
vitesses de transfert et la compression de données. Vous pouvez analyser les débits
de données à tout moment lors d'une opération de sauvegarde ou de restauration.
Vous pouvez également utiliser des informations de performance pour analyser les
goulots d'étranglements de la performance sur le processeur, le disque ou le
réseau.
Activation et désactivation de sessions de serveur

Vous pouvez maintenant désactiver et activer temporairement toutes les sessions
entrantes ou sortantes pour un serveur Tivoli Storage Manager particulier.
Cette fonction est utile, par exemple, si vous avez planifié un arrêt du réseau
susceptible d'affecter les communications entre les serveurs de réplication source et
cible. Pour éviter les problèmes de réplication, vous pouvez désactiver les sessions
sortantes du serveur de réplication source avant l'arrêt. Une fois les
communications rétablies, vous pouvez reprendre la réplication en activant les
sessions sortantes.
Aide de la ligne de commande pour les sous-commandes

Dans cette édition, vous pouvez obtenir de l'aide sur les sous-commandes Tivoli
Storage Manager. Par exemple, vous pouvez afficher de l'aide pour la commande
DEFINE DEVCLASS pour les classes d'unités 3570 et 3590. Pour afficher l'aide de ligne
de commande pour une sous-commande, entrez help suivi du numéro de rubrique
de la commande.
Les numéros de rubrique sont répertoriés dans la table des matières, par exemple :
xxxii IBM Tivoli Storage Manager : Guide de mise à niveau et de migration des serveurs V5
3.0 Commandes administratives
...
3.13.10 DEFINE DEVCLASS (Définition d’une classe d’unités)
3.13.10.1 DEFINE DEVCLASS (Définition d’une classe d’unités 3570)
3.13.10.2 DEFINE DEVCLASS (Définition d’une classe d’unités 3590)
...
Pour afficher de l'aide pour la commande DEFINE DEVCLASS pour les classes
d'unités 3570, entrez :
help 3.13.10.1
Comme dans les éditions précédentes, vous pouvez utiliser cette méthode pour
afficher l'aide pour les commandes dont le nom est unique, par exemple REGISTER
NODE :
3.46 REGISTER
3.46.1 REGISTER ADMIN (Enregistrement d’un administrateur)
3.46.2 REGISTER LICENSE (Enregistrement d’une nouvelle licence)
3.46.3 REGISTER NODE (Enregistrement d’un poste)
Pour afficher l'aide pour la commande REGISTER NODE, vous pouvez entrer :
help 3.46.1
Vous pouvez également entrer help commandName, où commandName correspond au

nom de la commande serveur pour laquelle vous souhaitez des informations :
help register node
Chiffrement de données avec TLS/SSL

Vous pouvez utiliser Transport Layer Security (TLS)/Secure Sockets Layer (SSL)
sur des plateformes HP-UX, Linux, Oracle Solaris, AIX et Windows.
Grâce aux communications TLS/SSL conformes aux normes industrielles, vous

pouvez chiffrer tout le trafic entre le client de sauvegarde-archivage, les clients de
la ligne de commande administrative et le serveur IBM Tivoli Storage Manager.
Vous pouvez utiliser des certificats SSL de signature automatique ou acquis par le
fournisseur.
Dans la version Tivoli Storage Manager V6.3 et supérieure, pour utiliser SSL avec
des certificats autosignés, sélectionnez l'option SSLTLS12 après avoir attribué de
nouveaux certificats auto-signés à tous les clients de l'archive de sauvegarde V6.3.
Vous pouvez utiliser des certificats depuis les versions du serveur précédent mais
dans ce cas, vous ne pouvez pas utiliser TLS 1.2.
Pour le serveur Tivoli Storage ManagerV6.3.3, TLS/SSL est disponible pour les
fonctions hors réseau localet serveur à serveur.
Nouveautés de la version 6.3 xxxiii

Avis aux lecteurs canadiens
Le présent document a été traduit en France. Voici les principales différences et particularités dont vous
devez tenir compte.
Illustrations
Les illustrations sont fournies à titre d'exemple. Certaines peuvent contenir des données propres à la
France.
Terminologie
La terminologie des titres IBM peut différer d'un pays à l'autre. Reportez-vous au tableau ci-dessous, au
besoin.
IBM France
IBM France IBM Canada
IBM Canada
ingénieur
ingénieur
commercial
commercial représentant
représentant
agence commerciale
agence commerciale succursale
succursale
ingénieur
ingénieur
technico-commercial
technico-commercial informaticien
informaticien
inspecteur
inspecteur technicien
technicien
du matériel
du matériel
Claviers
Claviers
Les lettres
Les sont
lettres
disposées
sont disposées
différemment
différemment
: le clavier
: le clavier
françaisfrançais
est de type
est de
AZERTY,
type AZERTY,
et le clavier
et le clavier
français-canadien
français-canadien
de typede
QWERTY.
type QWERTY.
OS/2 etOS/2
Windows
et Windows
- Paramètres
- Paramètres
canadiens
canadiens
Au Canada,
Au Canada,
on utilise
on :utilise :
v les pages
v lesdepages
codesde850
codes
(multilingue)
850 (multilingue)
et 863 (français-canadien),
et 863 (français-canadien),
v le code
v lepays
code002,
pays 002,
v le code
v leclavier
code clavier
CF. CF.
Nomenclature
Nomenclature
Les touches
Les touches
présentées
présentées
dans ledans
tableau
le tableau
d'équivalence
d'équivalence
suivantsuivant
sont libellées
sont libellées
différemment
différemment
selon qu'il
selon
s'agit
qu'il s'agit
du clavier
du clavier
de la France,
de la France,
du clavier
du clavier
du Canada
du Canada
ou du clavier
ou du clavier
des États-Unis.
des États-Unis.
Reportez-vous
Reportez-vous
à ce tableau
à ce tableau
pour faire
pourcorrespondre
faire correspondre
les touches
les touches
françaises
françaises
figurantfigurant
dans ledans
présent
le présent
documentdocument
aux touches
aux touches
de votre de votre
clavier. clavier.
xxxiv
© Copyright
© Copyright
IBM Corp.
IBM2012,
Corp.
2013
2012, 2013 ix ix
Brevets
Il est possible qu'IBM détienne des brevets ou qu'elle ait déposé des demandes de brevets portant sur
certains sujets abordés dans ce document. Le fait qu'IBM vous fournisse le présent document ne signifie
pas qu'elle vous accorde un permis d'utilisation de ces brevets. Vous pouvez envoyer, par écrit, vos
demandes de renseignements relatives aux permis d'utilisation au directeur général des relations
commerciales d'IBM, 3600 Steeles Avenue East, Markham, Ontario, L3R 9Z7.
Assistance téléphonique
Si vous avez besoin d'assistance ou si vous voulez commander du matériel, des logiciels et des
publications IBM, contactez IBM direct au 1 800 465-1234.
viii IBM Cúram Social Program Management : Cúram - Guide d'installation des outils tiers pour UNIX xxxv
xxxvi
xxxiv IBM Tivoli Storage Manager : Guide de mise à niveau et de migration des serveurs V5
Partie 1. Mise à niveau du serveur de la version 5 vers la
version 6.3 ou ultérieure
Vous pouvez mettre à niveau le serveur IBM Tivoli Storage Manager directement
de la version 5 à la version 6.3 ou ultérieure.
Tivoli Storage Manager version 6.3 fournit une base de données relationnelle basée
sur la technologie IBM® DB2®. Lorsque vous mettez à niveau le système de la
version 5 à la version 6.3 ou ultérieure, vous extrayez les données d'une base de
données du serveur Tivoli Storage Manager en cours et les chargez dans la
nouvelle structure de base de données. Tivoli Storage Manager fournit les
utilitaires nécessaires.
La mise à niveau de la version 5 vers la version 6.3 ou ultérieure nécessite une

planification, ainsi que des tests, le cas échéant. Commencez par découvrir les
nouveautés de la version 6.3 ou ultérieure et collectez ensuite les informations sur
les serveurs Tivoli Storage Manager en cours.
Public visé
Ces informations sont destinées aux administrateurs de serveurs Tivoli
Storage Manager, qui sont responsables de la mise à niveau des serveurs
Tivoli Storage Manager V5 vers la V6.3 ou ultérieure. Les administrateurs
doivent avoir des connaissances dans les domaines suivants :
v Le système d'exploitation et la plateforme sur lesquels sont exécutés les
serveurs
v Les opérations d'administration classiques des serveurs Tivoli Storage
Manager mis à niveau
v La capacité de stockage utilisée par les serveurs mis à niveau
v Le réseau auquel se connectent les serveurs
Comment utiliser ces informations
Procédure suggérée pour utiliser ces informations :
1. Consultez les informations de présentation concernant les mises à jour
du serveur : Chapitre 1, «Présentation des mises à jour de la base de
données du serveur», à la page 3.
2. Consultez les informations liées à la planification ainsi que les
descriptions des scénarios :
a. Chapitre 2, «Planification de la mise à niveau du serveur», à la page
13
b. Chapitre 3, «Présentation des scénarios de mise à niveau», à la page
85
3. Sélectionnez le scénario à utiliser et planifiez la configuration requise
au niveau du matériel, des logiciels et du stockage pour votre serveur
et votre environnement. Vous pouvez utiliser une feuille de calcul pour
la planification d'espace : «Feuille de calcul pour l'espace de
planification du serveur V6.3 ou ultérieure», à la page 50.
4. Lancez un test du processus de mise à niveau : «Test du processus de
mise à niveau pour un serveur», à la page 56. Utilisez les résultats du
test pour affiner la planification (estimation de la durée
d'indisponibilité du serveur suite au processus de mise à niveau, par
exemple).
© Copyright IBM Corp. 2009, 2013 1

5. Mettez le serveur à niveau en suivant les étapes du scénario sélecti
5. Mettez le serveur à niveau en suivant les étapes du scénario sélectionné :
: v Chapitre 4, «Scénario 1 : Même système, via des supports», à la p
103 v Chapitre 5, «Scénario 2 : Même système, via le réseau», à la page
v Chapitre 5, «Scénario 2 : Même système, via le réseau», à la page 149 v Chapitre 6, «Scénario 3 : Nouveau système, via des supports», à l
page 193 v Chapitre 7, «Scénario 4 : Nouveau système, via le réseau», à la pa
245 6. Effectuez le processus de mise à niveau en suivant les étapes de la
6. Effectuez le processus de mise à niveau en suivant les étapes de la section suivante :
section suivante : v Chapitre 10, «Exécution des premières étapes après la mise à nive
v Chapitre 10, «Exécution des premières étapes après la mise à niveau», à la page 355
à la page 355
Pour plus d'informations sur la mise à niveau du serveur de la V6.1 ou V6.2 v
Pour plus d'informations sur la mise à niveau du serveur de la V6.1 ou V6.2la V6.3
versou ultérieure, voir les procédures de mise à niveau dans le Guide
la V6.3 ou ultérieure, voir les procédures de mise à niveau dans le Guide d'installation.
d'installation.
2 IBM Tivoli Storage Manager : Guide de mise à niveau et de migration des serveurs V5
Chapitre 1. Présentation des mises à jour de la base de
données du serveur
La version 6.3 IBM Tivoli Storage Manager utilise une base de données
relationnelle basée sur la technologie IBM DB2. Les versions Tivoli Storage
Manager plus anciennes que 6.1 n'utilisaient pas la technologie DB2. Avant de
mettre le serveur à niveau vers V6.3 ou ultérieure, en savoir plus sur DB2.
Base de données du serveur

Le serveur V6.3 intègre une technologie de base de données professionnelle IBM
DB2 qui offre des fonctions de gestion de base de données à la base de données du
serveur. Un administrateur peut gérer la base de données du serveur à l'aide des
interfaces d'administration Tivoli Storage Manager.
Les interfaces d'administration Tivoli Storage Manager sont mises à jour, ce qui
permet à un administrateur habitué aux versions antérieures du serveur de
continuer à administrer le serveur pratiquement sans changement. La base de
données ne requiert pas de compétences d'administrateur de base de données. Le
nouveau programme de gestion de base de données présente un certain nombre
d'avantages :
Disponibilité du serveur améliorée
La réorganisation automatisée en ligne s'effectue alors que le serveur est en
cours de fonctionnement.
Il est possible d'exécuter automatiquement des audits sur la base de
données afin d'en garantir la cohérence. Au fur et à mesure que les
données sont ajoutées à la base de données du serveur, le gestionnaire de
base de données vérifie les contraintes de données et les types de données.
Les contrôles d'intégrité en ligne évitent la survenue d'incidents qui
nécessitaient l'exécution d'audits hors connexion dans les versions
antérieures.
Evolutivité améliorée
La capacité du serveur a été améliorée pour les opérations simultanées par
l'augmentation de la taille maximale du journal de reprise.
Le nombre maximal d'objets pouvant être gérés par un seul serveur a été
augmenté.
La taille effective de la base de données peut être limitée par le temps
disponible pour la réalisation des opérations, telles qu'une sauvegarde de
base de données, des sauvegardes client et un dédoublonnage des données.
Fonction SQL intégrale
Vous pouvez obtenir plus facilement des informations à partir de la base
de données du serveur, grâce aux fonctionnalités intégrales des requêtes
SQL.
Il devient possible de formuler des requêtes SQL plus complexes sur les
données de la base de données. Pour tirer pleinement parti de ces
fonctionnalités, des compétences SQL peuvent s'avérer nécessaires pour
développer de nouveaux outils.

Présentation des mises à jour de la base de données du serveur
Espace disponible dans la base de données pour un serveur

version 6.3 ou ultérieure
La base de données est stockée dans l'ensemble de répertoires que vous indiquez.
L'espace disponible pour ces répertoires détermine l'espace disponible pour la base
de données.
Avec la version 6.3 ou ultérieure, il n'est pas nécessaire de créer ou d'effectuer un

suivi des volumes de la base de données du serveur. En revanche, vous créez et
désignez les répertoires pouvant être utilisés par le serveur pour la base de
données. Le gestionnaire de base de données qui fait partie du serveur gère
automatiquement l'espace disponible dans ces répertoires comme étant celui de la
base de données.
La base de données peut être répartie sur un maximum de 128 répertoires. Placez
ces répertoires sur des disques rapides et fiables, configurés pour un accès d'E-S
aléatoire. Le placement de chaque répertoire sur un système de fichiers différent
est optimal pour les performances, car les données sont segmentées sur les
différents répertoires. Activez la mémoire cache de lecture pour les systèmes de
fichiers de la base de données et la mémoire cache d'écriture si le sous-système du
disque la prend en charge.
La taille maximale de la base de données Tivoli Storage Manager est 4 To.
La taille effective de la base de données peut être limitée dans votre

environnement par le temps disponible pour la réalisation des opérations, telles
qu'une sauvegarde de base de données, des sauvegardes client et un
dédoublonnage des données (si utilisé).
Journal de reprise
Le journal de reprise permet d'éviter qu'un problème (par exemple une
indisponibilité de l'alimentation système) laisse la base de données dans un état
incohérent. Il est également indispensable lorsque vous voulez restaurer la base de
données.
Pour de plus amples informations, consultez la section journal de reprise dans le

Guide d'administration.
Modifications liées aux opérations

Des améliorations significatives ont été apportées au niveau des performances du
serveur, parmi lesquelles une automatisation accrue de la gestion de la base de
données.
Pour plus d'informations sur les opérations avec un serveur version 6.3 ou
ultérieure, consultez la section concernant la gestion de la base de données et du
journal de reprise Guide d'administration.
Opérations de base de données

Le gestionnaire de base de données contrôle les opérations de la base de données
en exécutant des tâches automatiques visant à conserver celle-ci en bon état.
Le gestionnaire de base de données contrôle l'espace de stockage de la base de

données. Le serveur peut utiliser tout l'espace disponible pour les répertoires
spécifiés pour la base de données. Dans V6.3, vous ne gérez pas les volumes
individuels de la base de données, ce qui était indispensable dans les anciennes

versions du serveur. Lorsque l'espace de la base de données devient insuffisant,
plutôt que de l'étendre en ajoutant des volumes, ajoutez des répertoires (de
préférence sur différents volumes physiques) à l'espace de base de données.
La réorganisation de la base de données s'effectue automatiquement. En fonction

de l'activité, le programme du gestionnaire de base de données sélectionne les
tables de base de données à analyser afin de déterminer quand elles doivent être
réorganisées. Le gestionnaire de base de données exécute alors la réorganisation
sans perturber les opérations du serveur.
Au fur et à mesure que les données sont ajoutées à la base de données du serveur,
le gestionnaire de base de données vérifie automatiquement les contraintes de
données et les types de données. Les contrôles d'intégrité en ligne évitent la
survenue d'incidents qui nécessitaient l'exécution d'audits hors connexion dans les
versions antérieures.
Contrôlez l'espace utilisé par le serveur et l'espace disponible dans les systèmes de
fichiers où se trouvent les répertoires pour s'assurer que l'espace est toujours
disponible. Des informations sur l'utilisation de l'espace de la base de données et
sur l'utilisation du journal de reprise sont disponibles via l'Administration Center
et les commandes d'administration, mais aussi via IBM Tivoli Monitoring for Tivoli
Storage Manager.
IBM Tivoli Storage Manager version6.3 ou ultérieure est installé avec l'application
de base de données IBM DB2. Les utilisateurs qui sont des administrateurs DB2
expérimentés peuvent choisir d'effectuer des requêtes SQL avancées et d'utiliser
des outils DB2 pour surveiller la base de données. Cependant, n'utilisez pas les
outils DB2 pour modifier les paramètres de configuration DB2 prédéfinis par Tivoli
Storage Manager. Ne modifiez pas l'environnement DB2 pour Tivoli Storage
Manager de quelque manière que ce soit, telle qu'en utilisant d'autre produits. Le
serveur Tivoli Storage Manager V6.3 a été conçu et testé avec le langage de
définition de données (DDL) et la configuration de la base de données déployés
par Tivoli Storage Manager.
Chapitre 1. Présentation des mises à jour de la base de données du serveur 5

Avertissement : Les modifications apportées au langage DDL ou à la

configuration de la base de données sans recourir aux interfaces Tivoli Storage
Manager peut affecter les performances de la base de données du serveur,
l'endommager, la détruire, ou entraîner une perte des données. Respectez les
restrictions suivantes :
v N'utilisez pas d'outils ou d'interfaces de base de données autres que ceux fournis
par Tivoli Storage Manager pour modifier les paramètres de configuration
définis par Tivoli Storage Manager au cours du processus d'installation.
v Ne modifiez pas l'environnement DB2.
v Si vous utilisez des outils ou des interfaces de base de données autres que ceux
fournis par Tivoli Storage Manager, la base de données de serveur doit être en
lecture seule. N'utilisez pas d'autres interfaces pour apporter des modifications à
la base de données du serveur Tivoli Storage Manager.
v Ne modifiez pas le logiciel DB2 qui est installé avec les modules d'installation et
les groupes de correctifs de Tivoli Storage Manager.
v N'installez pas ou ne mettez pas à niveau vers une autre version, édition ou
groupe de correctifs du logiciel DB2.
Protection et reprise de la base de données

Les sauvegardes de la base de données sont indispensables pour protéger toutes
les données gérées par le serveur. La reprise d'une base de données endommagée
ou perdue peut s'effectuer à partir des sauvegardes de la base de données,
associées aux sauvegardes de l'historique des volumes et au journal de reprise afin
de restaurer la base de données à son état le plus récent ou à un point dans le
temps.
Sauvegardes de base de données
Protégez le serveur en utilisant des plannings d'administration afin
d'exécuter des sauvegardes de base de données régulières, au moins une
fois par jour. Il pourra être nécessaire d'effectuer des sauvegardes plus
fréquentes si le serveur gère un nombre élevé de transactions client.
Vous pouvez créer des sauvegardes intégrales, incrémentales et
instantanées de la base de données du serveur. Vous pouvez planifier des
sauvegardes automatiques ou les effectuer manuellement.
Le journal d'archivage est inclus dans les sauvegardes de base de données,
afin de pouvoir être utilisé pour la récupération aval de la base de
données. A la fin d'une sauvegarde de base de données intégrale, les
fichiers de journal d'archivage les plus anciens devenus inutiles sont
supprimés automatiquement pour libérer de l'espace. Les fichiers de
journal d'archivage inclus dans une sauvegarde sont automatiquement
supprimés lorsque deux autres sauvegardes complètes ont été achevées.
Si l'espace du journal de reprise est limité, il est préférable d'effectuer des
sauvegardes intégrales plus fréquentes afin de libérer de l'espace grâce à la
suppression automatique de fichiers.
Une sauvegarde incrémentale de la base de données inclut toutes les
modifications de la base de données depuis la dernière sauvegarde
intégrale. Dans les versions précédentes du serveur, une sauvegarde
incrémentielle comprenait les modifications apportées depuis la dernière
sauvegarde intégrale ou incrémentielle, et plusieurs sauvegardes
incrémentielles pouvaient être nécessaires pour restaurer la base de
données. Depuis la version 6.3 ou ultérieure, lorsque vous devez restaurer
une base de données, utilisez la dernière sauvegarde intégrale et
uniquement la dernière sauvegarde incrémentielle.
Les sauvegardes automatiques sont effectuées par le gestionnaire de base

de données en fonction de l'utilisation de l'espace du journal actif depuis la
dernière sauvegarde de la base de données et du quotient d'espace utilisé
par rapport à l'espace total attribué au journal actif. Pour configurer des
sauvegardes automatiques de la base de données, indiquez pendant la
configuration initiale du serveur une classe d'unités à utiliser lors de ces
sauvegardes. Les sauvegardes de la base de données qui sont effectuées
par le gestionnaire de la base sont des sauvegardes complètes ou
incrémentielles.
Copie miroir de la base de données
La base de données ne peut être mise en miroir par Tivoli Storage Manager
dans V6.3. Utilisez plutôt la copie miroir matérielle.
Mode journal de reprise
Le serveur V6.3 s'exécute toujours dans un mode équivalent au mode
restauration en aval.
Les changements apportés à la base de données sont enregistrés dans le
journal de reprise afin de conserver une image cohérente pour la base de
données. Les fichiers journaux actifs et d'archivage, compris dans les
sauvegardes de base de données, vous permettent de restaurer le serveur
au moment le plus tardif possible. Vous pouvez également restaurer la
base de données à une heure précise.
Pour vous assurer que les informations de journal requises sont disponibles
pour la restauration de la base de données, vous pouvez indiquer qu'une
copie miroir du journal actif soit effectuée dans un autre emplacement du
système de fichiers. Pour une disponibilité maximale, ces copies miroir
actives doivent être placées sur un unité physique différente.
Fichiers nécessaires à la restauration de la base de données
Le fichier historique de volumes et le fichier de configuration des unités
sont nécessaires pour restaurer la base de données.
Avant la version V6.3, le fichier historique de volumes était facultatif pour
la restauration de la base de données, et si un fichier de configuration des
unités n'était pas disponible, vous pouviez recréer le fichier. Pour démarrer
avec le serveur V6.3, le fichier historique de volumes et le fichier de
configuration des unités doivent être disponibles; le fichier de
configuration des unités ne peut être recréé.
Important : Assurez-vous que le fichier d'options du serveur inclut les

options suivantes :
v Au moins une option VOLUMEHISTORY avec le nom d'un fichier à mettre
automatiquement à jour lorsque les informations d'historique des
volumes sont modifiées.
v Au moins une option DEVCONFIG avec le nom d'un fichier dans lequel
enregistrer une copie de sauvegarde des informations sur la
configuration d'unité.
Gestionnaire de reprise
Le gestionnaire de reprise s'exécute avec la nouvelle base de données et les
opérations de sauvegarde de base de données. Certaines strophes du plan
de reprise après incident ont été ajoutées ou modifiées afin de prendre en
compte les modifications apportées aux opérations de base de données.
Restauration de la base de données
La base de données peut être restaurée à son état le plus récent ou à un

point précis dans le temps. Le fichier historique des volum
point précis dans le temps. Le fichier historique des volumes et le fichier de configuration des unités sont nécessaires pour restaurer
de configuration des unités sont nécessaires pour restaurer la base de données.
données.
Cette dernière peut être restaurée à un emplacement différ
Cette dernière peut être restaurée à un emplacement différent de son emplacement d'origine. La restauration de la base de donn
emplacement d'origine. La restauration de la base de données est une façon de déplacer un serveur.
façon de déplacer un serveur.
Plusieurs instances du serveur sur un seul système
Plusieurs instances du serveur sur un seul système Une instance du serveur exécute le programme serveur en utilisan
Une instance du serveur exécute le programme serveur en utilisant sa base de données, son journal de reprise et les options du serveur. Pour exé
données, son journal de reprise et les options du serveur. Pour exécuter plusieurs instances du serveur sur un seul système, créez des répertoires diff
instances du serveur sur un seul système, créez des répertoires différents pour la base de données et le journal de reprise, et un répertoire d'instance
base de données et le journal de reprise, et un répertoire d'instance pour chaque serveur destiné à contenir le fichier d'options du serveur et les aut
serveur destiné à contenir le fichier d'options du serveur et les autres fichiers nécessaires à l'exécution de chaque instance du serveur.
nécessaires à l'exécution de chaque instance du serveur.
Sur les systèmes AIX, HP-UX, Linux et Solaris, chaque instance de
Sur les systèmes AIX, HP-UX, Linux et Solaris, chaque instance de serveur requiert un ID utilisateur unique, appelé ID de propriétaire d'instance. Sur
un ID utilisateur unique, appelé ID de propriétaire d'instance. Sur les systèmes Windows, les instances de serveur peuvent être la propriété d'un s
Windows, les instances de serveur peuvent être la propriété d'un seul ou de plusieurs comptes utilisateurs différents.
plusieurs comptes utilisateurs différents.
Les fichiers correspondant à chaque instance et les fichiers de prog
Les fichiers correspondant à chaque instance et les fichiers de programme serveur sont stockés à des emplacements différents. Dans le cadre du proce
sont stockés à des emplacements différents. Dans le cadre du processus de configuration du serveur, vous créez un répertoire destiné à conten
configuration du serveur, vous créez un répertoire destiné à contenir les fichiers de l'instance du serveur. Les fichiers suivants sont stockés dans le rép
l'instance du serveur. Les fichiers suivants sont stockés dans le répertoire d'instance :
: v Fichier d'options du serveur, dsmserv.opt
v Fichier d'options du serveur, dsmserv.opt v Fichier de configuration d'unité si l'option de serveur DEVCONFIG
v Fichier de configuration d'unité si l'option de serveur DEVCONFIG n'indique pas un nom complet
un nom complet v Fichier d'historique des volumes si l'option de serveur VOLUMEHIS
v Fichier d'historique des volumes si l'option de serveur VOLUMEHISTORY n'indique pas un nom complet
pas un nom complet v Volumes des pools de stockage DEVTYPE=FILE, si le répertoire
v Volumes des pools de stockage DEVTYPE=FILE, si le répertoire de la classe d'unités n'est pas spécifié entièrement ou qualifié de manière com
d'unités n'est pas spécifié entièrement ou qualifié de manière complète v Fichier dsmserv.v6lock
v Fichier dsmserv.v6lock v Exits utilisateur
v Exits utilisateur v Sortie de trace (si le nom qualifié complet n'est pas indiqué)
v Sortie de trace (si le nom qualifié complet n'est pas indiqué)
La base de données et les fichiers journaux de reprise sont stockés
La base de données et les fichiers journaux de reprise sont stockés dans des répertoires distincts, différents du répertoire d'instance.
répertoires distincts, différents du répertoire d'instance.
Pour gérer la mémoire système utilisée par chaque serveur sur un
Pour gérer la mémoire système utilisée par chaque serveur sur un système, utilisez l'option de serveur DBMEMPERCENT pour limiter le pourcentage de m
l'option de serveur DBMEMPERCENT pour limiter le pourcentage de mémoire système pouvant être utilisé par le gestionnaire de base de données de chaq
pouvant être utilisé par le gestionnaire de base de données de chaque serveur. Si tous les serveurs sont d'égale importance, utilisez la même valeur
tous les serveurs sont d'égale importance, utilisez la même valeur pour chacun. Si un serveur est un serveur de production et les autres des serveurs
un serveur est un serveur de production et les autres des serveurs de test, affectez au premier une valeur supérieure.
au premier une valeur supérieure.

Par exemple, pour exécuter deux instances de serveur tsminst1 et tsminst2, vous
pouvez créer les répertoires d'instance /tsminst1 et /tsminst2. Dans chaque
répertoire, placez le fichier dsmserv.opt de ce serveur. Chaque fichier dsmserv.opt
doit indiquer un port différent pour le serveur à utiliser. Pour démarrer
automatiquement les deux instances de serveur, utilisez le script rc.dsmserv.
Modification du démarrage du serveur

Vous pouvez démarrer automatiquement plusieurs instances du serveur Tivoli
Storage Manager lors du démarrage du système.
Démarrage d'instances de serveur (AIX, HP-UX, Linux, Solaris)


Storage Manager lors du démarrage du système (à partir de /etc/inittab par
exemple, sous AIX) sans avoir besoin de scripts configurés par l'utilisateur. Deux
options DSMSERV et un script permettent de démarrer les instances de serveur de
cette façon.
La méthode standard pour démarrer le serveur consiste à utiliser l'ID utilisateur

d'instance. A l'aide de l'ID utilisateur d'instance, vous simplifiez le processus de
configuration et évitez des problèmes potentiels. Cependant, dans certains cas, il
peut être nécessaire d'utiliser un autre ID utilisateur pour démarrer le serveur. Par
exemple, vous souhaiterez peut-être utiliser l'ID utilisateur root pour vous assurer
que le serveur peut accéder à des périphériques spécifiques. Pour permettre à un
autre utilisateur que l'ID utilisateur d'instance de démarrer le serveur, l'ID
utilisateur doit posséder les droits suffisants pour émettre la commande de
démarrage du serveur et du gestionnaire de base de données. Par ailleurs, il doit
appartenir au groupe SYSADM_GROUP. L'ID utilisateur doit avoir le droit
d'accéder à la base de données du serveur et d'utiliser tous les fichiers, répertoires
et périphériques requis par le serveur. Avant de démarrer le serveur, accordez
explicitement les droits d'accès à la base de données du serveur à l'ID utilisateur et
vérifiez tous les autres droits de l'ID utilisateur.
Conseil : Solaris Si vous exécutez un serveur Tivoli Storage Manager sur un

système Solaris, vous pouvez utiliser la fonction Solaris Service Management
Facility (SMF) pour configurer et contrôler le serveur Tivoli Storage Manager
comme un service. Pour plus d'informations, voir la note technique 7021102
(http://www.ibm.com/support/docview.wss?uid=swg27021102).
Permutation des ID utilisateur
L'option -u userID de DSMSERV permet au serveur de permuter les ID
utilisateur sur demande. Elle est principalement conçue pour être utilisée
dans /etc/inittab sur des systèmes AIX ou des méthodes similaires sur
d'autres plateformes. La configuration est plus simple si vous basculez vers
l'ID utilisateur qui est propriétaire de l'instance lors du démarrage.
Modification du répertoire de travail en cours
L'option -i instance_dir de DSMSERV permet au serveur de changer son
répertoire de travail en cours sur demande. Elle a pour objet principal de
s'assurer que plusieurs instances du serveur Tivoli Storage Manager
peuvent être lancées à partir de /etc/inittab sans nécessiter de script
configuré par l'utilisateur.
Configuration de l'environnement à l'aide d'un script
Le script /opt/tivoli/tsm/server/bin/rc.dsmserv, conçu pour fonctionner
sur les systèmes AIX, HP-UX, Linux et Solaris est fourni. Il configure les
variables d'environnement et modifie le chemin de bibliothèque afin de
résoudre les bibliothèques requises par le serveur Tivoli Storage Manager.
Le chemin de la bibliothèque correspond à la variable suivante :
AIX LIBPATH
Linux LD_LIBRARY_PATH
Appelez le script à partir de l'emplacement de démarrage du système,

/etc/inittab par exemple sur un système AIX.
Tâches associées:
«Démarrage du serveur sur des systèmes AIX, HP-UX, Linux et Oracle Solaris», à
la page 357
Démarrage d'instances de serveur (Windows)

Windows

Storage Manager lors du démarrage du système en configurant les options pour le
serveur en tant que service.
Vous pouvez définir le mode et les options de démarrage du service serveur afin
que le serveur démarre en même temps que le système.
Lorsque le serveur est démarré en tant que service, le service dédié au gestionnaire
de base de données correspondant est également démarré automatiquement. La
dénomination de ce service est identique à celle d'un service DB2 et son nom inclut
le nom de l'instance de serveur. Par exemple, le service de gestionnaire de base de
données pour l'instance de serveur Server1 a pour nom : DB2 - DB2TSM1 - SERVER1
Lorsque vous arrêtez le service pour le serveur, celui du gestionnaire de base de

données n'est pas automatiquement arrêté. Si vous voulez arrêter à la fois le
serveur et son gestionnaire de base de données, vous devez arrêter le service du
gestionnaire séparément.
Concepts associés:
Annexe E, «Services associés au serveur Tivoli Storage Manager», à la page 597
Tâches associées:
«Démarrage du serveur sur des systèmes Windows», à la page 362
Modifications liées aux fichiers et à l'environnement

Les emplacements et les noms de certains fichiers ont changé par rapport aux
versions précédentes.
AIX Emplacement d'installation
L'emplacement des fichiers du serveur et du gestionnaire d'unités Tivoli
Storage Manager a changé : il ne correspond plus à /usr, mais à /opt.
L'emplacement des fichiers pour l'agent de stockage Tivoli Storage
Manager est également passé de /usr à /opt.
AIX HPUX Linux Solaris Emplacement des fichiers journaux
Au cours de l'installation, les journaux sont stockés dans le répertoire
/var/tivoli/tsm. Les journaux et la trace des assistants de configuration et
de mise à niveau sont également stockés à cet emplacement.
AIX HPUX Linux Noms des ensembles de fichiers
Solaris
Les ensembles de fichiers ont été fusionnés et leur nom a changé. A
l'exception des messages, le serveur est contenu dans le répertoire
tivoli.tsm.server.
Variables d'environnement
v La variable DSMSERV_DIR n'est plus valide. Le serveur Tivoli Storage
Manager détermine automatiquement le répertoire dans lequel il est
installé et il recherche les exits, modules chargeables et fichiers de

messages liés à ce répertoire. Sous Windows le programme utilise des
entrées de registre.
v La variable DSMSERV_CONFIG n'est plus valide.
Important : Lorsque vous mettez à niveau des utilitaires pour un serveur

de la version 5, des variables d'environnement doivent être définies pour
les utilitaires. Pour plus d'informations, voir «Paramétrage des variables
d'environnement pour les utilitaires de mise à niveau sur des systèmes
AIX, HP-UX, Linux et Oracle Solaris», à la page 324.
Tâches associées:
«Paramétrage des variables d'environnement pour les utilitaires de mise à niveau
sur des systèmes AIX, HP-UX, Linux et Oracle Solaris», à la page 324
Modifications des commandes d'administration

Avec le nouveau gestionnaire de base de données, la gestion de la base de données
s'effectue toujours via des commandes Tivoli Storage Manager. Les tâches
d'administration de la base de données sont différentes ce qui fait que les
modifications apportées au serveur incluent des commandes d'administration
nouvelles, modifiées et supprimées.
Des options de serveur et des utilitaires ont également changé.

Référence associée:
«Modifications apportées aux commandes et options», à la page 60

Chapitre 2. Planification de la mise à niveau du serveur
La planification de la mise à niveau vers la IBM Tivoli Storage Manager version6.3
ou ultérieure est très importante car vous devez non seulement installer le
nouveau code, mais transférer les contenus de la base de données du serveur dans
la nouvelle base de données.
Le transfert des données de la base de données du serveur version 5 d'origine vers

la base de données version 6.3 ou ultérieure utilise un pourcentage élevée du
processeur du système et requiert un volume d'E-S important.
Dans votre planification, envisagez de tester la mise à niveau sur des systèmes de
non-production. Vous obtenez ainsi des informations sur la durée du processus de
mise à niveau de la base de données du serveur, lesquelles vous aident à prévoir la
durée d'indisponibilité du serveur. La durée de la mise à niveau varie d'une base
de données à l'autre.
Vous obtenez également des informations sur la taille de la nouvelle base de

données par rapport à celle d'origine, ce qui vous permet d'évaluer plus
précisément l'espace de stockage dont vous avez besoin.
Si vous disposez de plusieurs serveurs, mettez à niveau un premier serveur afin de

voir comment le processus fonctionne avec vos données. Basez-vous sur les
résultats que vous avez obtenus pour planifier la mise à niveau des autres
serveurs.
Processus de mise à niveau du serveur de la version 5 sur la version

6.3 ou ultérieure
Passer de Tivoli Storage Manager version 5 à la version 6.3 ou ultérieure nécessite
un plus gros travail de préparation et de planification que les mises à niveau
précédentes. En raison de la nature du programme de base de données utilisé par
le serveur, une base de données existante doit être transférée dans la structure de
la nouvelle de base de données à l'aide des outils de mise à niveau fournis.
A l'exception des processus d'extraction et d'insertion de la base de données, le

processus de mise à niveau du serveur est similaire au processus de reprise après
incident. Les fichiers essentiels du serveur, tels que le fichier d'options et le fichier
de configuration des unités, doivent être disponibles et les unités utilisées pour les
pools de stockage doivent être disponibles pour le serveur mis à niveau.
Les principales étapes du processus de mise à niveau de la version 5 sur la version

6.3 ou ultérieure sont les suivantes :
1. Planifiez le matériel et le logiciel du système et évaluez le temps de mise à
niveau.
Pour déterminer comment et quand procéder à la mise à niveau, basez-vous à
la fois sur les informations relatives au processus de mise à niveau du serveur
Tivoli Storage Manager et sur les conditions d'exploitation de vos serveurs
existants.
Astuce : Si vous intégrez un nouveau matériel ou apportez des modifications à

l'infrastructure du système de stockage, planifiez la segmentation du réseau de

Mise à niveau du serveur de la version 5 sur la version 6.3 ou ultérieure
stockage SAN. Prévoyez du temps pour créer les instructions et les chemins des
unités et pour restituer les volumes de bande après la mise à niveau. Pour les
unités de bande IBM, aucun pilote multi-accès n'est disponible pour les unités
de bande distribuées sur plusieurs adaptateurs. Utilisez les définitions de
segmentation et d'unité pour équilibrer la charge de travail.
2. Sauvegardez les fichiers de configuration et la base de données du serveur
Tivoli Storage Manager. Vérifiez qu'au moins une sauvegarde complète de la
base de données est disponible sur site.
Conseil : Si vous devez restaurer la base de données après l'échec d'une mise à
niveau, le fait de disposer d'une base de données de sauvegarde sur site vous
permet de gagner du temps.
3. Facultatif : vérifiez votre environnement système en exécutant le vérificateur de
prérequis. Apportez toutes les modifications requises avant de continuer
l'installation.
4. Installez le code du serveur. Les tâches d'installation sont les suivantes :
v Installation du nouveau code de serveur, ce qui inclut le serveur et le
programme de son gestionnaire de base de données. Configurez un ID
utilisateur pour la nouvelle instance de serveur.
v Installation du module des utilitaires de mise à niveau sur le système sur
lequel est installé le serveur version 5 existant.
5. Mettez à niveau la base de données. Cette tâche englobe la préparation de la
base de données et son transfert. Aidez-vous des utilitaires de mise à niveau ou
de l'assistant de mise à niveau pour exécuter ces tâches.
Ces derniers extraient les données d'une base de données existante et les insère
dans une nouvelle base de données version 6.3 ou ultérieure. Ce transfert
s'effectue via des supports ou via le réseau.
Au cours du transfert d'une base de données vers la structure de la nouvelle
base de données, les données sont examinées afin de s'assurer qu'elles sont
compatibles avec les contraintes appliquées dans la nouvelle base de données.
Certaines erreurs sont corrigées automatiquement par les outils de mise à
niveau. D'autres doivent être corrigées manuellement.
Si vous utilisez l'assistant, vous devez exécuter les étapes de mise à niveau
dans le bon ordre. Si vous effectuez la mise à niveau manuellement à l'aide
d'utilitaires à partir d'une ligne de commande, appliquez scrupuleusement la
procédure.
6. Vérifiez la mise à niveau en exécutant des opérations de base et en demandant
des informations sur le système afin de confirmer que ces dernières ont été
correctement transférées.
Pour vous aider à choisir le mode d'exécution du processus de mise à niveau,

consultez les informations de comparaison des méthodes de mise à niveau ainsi
que les descriptions des scénarios de mise à niveau.
Tâches associées:
Chapitre 3, «Présentation des scénarios de mise à niveau», à la page 85
Comparaison de la mise à niveau sur un système existant et

sur un nouveau système
Pour qu'un serveur version6.3 ou ultérieure soit mis à niveau sur un serveur
existant, il faut que le système soit indisponible pour l'utilisation de production au
cours de l'installation et du transfert des données vers la nouvelle base de données.
Le transfert du serveur vers un nouveau système vous offre plus de flexibilité en

termes de processus de mise à niveau, mais avec des coûts supplémentaires.
Si vous mettez à niveau Tivoli Storage Manager vers un système d'exploitation

différent, un ensemble limité de chemins de migration est disponible. Pour obtenir
des instructions sur la migration d'un serveur qui s'exécute sur un système
d'exploitationz/OS, voir Partie 3, «Migration des serveurs Tivoli Storage Manager
version 5 s'exécutant sur des systèmes z/OS vers la version 6 sous AIX ou Linux
on System z», à la page 475. Pour obtenir des instructions sur la migration serveur
qui s'exécute sur un système d'exploitation AIX, HP-UX, ou Solaris, voir Partie 2,
«Migration des serveurs V5 Tivoli Storage Manager sur les systèmes AIX, HP-UX,
ou Solaris vers la version V6.3.4 surLinux», à la page 385.
le tableau suivant répertorie les éléments à prendre en compte lors du choix du

scénario de mise à niveau du serveur.
Tableau 6. Eléments à prendre en compte pour la sélection d'un scénario de mise à niveau du serveur
Elément Mise à niveau sur un système existant Mise à niveau sur un nouveau système
Matériel système Des ressources supplémentaires (espace En plus du système existant, il est
disque, mémoire, et éventuellement nécessaire de disposer d'un nouveau
capacité du processeur) sont requises sur système conforme aux exigences
le système existant. requises.
Vous devez effectuer une mise à niveau

vers un nouveau système si le serveur
existant est installé sur une plateforme
non prise en charge pour la version 6.3
ou ultérieure.
Logiciel Le logiciel installé sur le système doit Le logiciel installé sur le nouveau
être conforme aux exigences requises système doit être conforme aux
pour la version 6.3 ou ultérieure. exigences requises pour la version 6.3 ou
ultérieure.
Le serveur version 6.3 ou ultérieure ne
peut pas coexister avec d'autres versions Le logiciel installé sur le système version
sur le même système. 5 d'origine doit être conforme aux
conditions requises pour les utilitaires de
mise à niveau (ces conditions sont les
mêmes que pour le serveur version 5.5).
Chapitre 2. Planification de la mise à niveau 15

Tableau 6. Eléments à prendre en compte pour la sélection d'un scénario de mise à niveau du serveur (suite)
Disponibilité du serveur V5 Toutes les instances du serveur version 5 Vous pouvez échelonner la mise à
ne sont plus disponibles une fois le niveau de plusieurs serveurs car le
programme du serveur version 6.3 ou programme serveur V5 peut rester sur le
ultérieure installé. Les données gérées système d'origine.
par une instance de serveur ne sont pas
Il est possible de redémarrer le serveur
accessibles tant que le processus de mise
à niveau pour cette instance de serveur version 5.5 sur le système d'origine une
n'est pas terminé. fois l'extraction de la base de données
terminée. Toutefois, si vous redémarrez
Pour revenir à l'utilisation du serveur le serveur version 5.5 pour des
V5, vous devez réinstaller le même opérations de production après
niveau du programme serveur V5 utilisé l'extraction de la base de données, vous
avant. Ensuite, restaurer la base de devez planifier soigneusement le
données V5 à partir d'une sauvegarde. processus de mise à niveau afin d'éviter
toute perte de données. Pour plus
d'informations sur les méthodes de mise
à nineau hybrides à utiliser, y compris
les opérations d'exportation et
d'importation, ainsi que pour les conseils
permettant d'éviter la perte de données,
voir Tivoli Storage Manager wiki
(http://www.ibm.com/developerworks/
mydeveloperworks/wikis/home/wiki/
Tivoli Storage Manager).
Il est possible de redémarrer un serveur

V5.3 ou V5.4 sur le système d'origine,
mais sa base de données doit être
restaurée préalablement à partir de la
sauvegarde de la base de données.
Méthode de transfert de la La base de données peut être transférée Vous devez soit disposer d'une
base de données via une connexion réseau sur le système connexion réseau entre le système
hôte local, ou via des disques ou des existant et le nouveau, soit disposer
supports externes. d'une unité ou d'un support pour y
stocker la base de données extraite.
Unités de stockage et pools de Des unités connectées existantes peuvent Le nouveau système doit avoir accès à la
stockage être utilisées. totalité de l'espace de stockage utilisé
par le système d'origine.
Vous devez modifier l'appartenance ou
les droits d'accès pour la totalité de Il pourra être nécessaire de modifier des
l'espace disque utilisé par les pools de définitions d'unités de type FILE une
stockage (types d'unité FILE ou DISK). fois la mise à niveau effectuée.
L'ID utilisateur que vous allez créer
comme étant le propriétaire de l'instance Vous devez modifier l'appartenance ou
du serveur mis à niveau doit être le les droits d'accès pour la totalité de
détenteur de l'espace disque des pools l'espace disque utilisé par les pools de
de stockage ou avoir des droits d'accès stockage (types d'unité FILE ou DISK).
en lecture-écriture sur celui-ci. L'ID utilisateur que vous allez créer
comme étant le propriétaire de l'instance
du serveur mis à niveau doit être le
détenteur de l'espace disque des pools
de stockage ou avoir des droits d'accès
en lecture-écriture sur celui-ci.
Si l'environnement comprend un réseau

de zone de stockage (SAN), il peut être
nécessaire de modifier les zones ou le
masquage LUN.
Tableau 6. Eléments à prendre en compte pour la sélection d'un scénario de mise à niveau du serveur (suite)
Connexions des clients et des Aucune modification n'est nécessaire. L'adresse réseau des clients et des agents
agents de stockage et partage de stockage doit être mise à jour après la
de bibliothèque mise à niveau. Vous pouvez également
apporter des modifications au réseau de
sorte que le nouveau système ait la
même adresse que le système d'origine.
De même, si le serveur partage une

bibliothèque avec d'autres serveurs, des
modifications à l'adresse réseau peuvent
être requises après la mise à niveau.
Concepts associés:
«Configuration matérielle et logicielle requise pour le serveur mis à niveau», à la
page 22
Tâches associées:
«Estimation de l'espace disque total requis pour le processus de mise à niveau et le
serveur mis à niveau», à la page 47
«Configuration matérielle et logicielle requise pour le système du serveur version 5
mis à niveau», à la page 19
Comparaison des méthodes de transfert des données vers la

base de données version 6.3 ou ultérieure
Le transfert des données d'une version antérieure de la base de données vers la
version 6.3 ou ultérieure s'effectue via les utilitaires de mise à niveau. Vous pouvez
exécuter ces utilitaires avec l'aide d'un assistant.
Pour transférer la base de données, vous devez installer les utilitaires de mise à
niveau sur le système où se trouve la base de donnés d'origine du serveur. Le
module d'utilitaires est disponible à partir du site de téléchargement FTP
correspondant au produit Tivoli Storage Manager. L'installation du module des
utilitaires de mise à niveau et l'installation du serveur version 6.3 ou ultérieure
sont deux tâches distinctes.
Vous pouvez transférer la base de données de deux manières :

Via des supports
Vous pouvez extraire les données de la base de données d'origine vers des
supports et les charger ultérieurement dans la nouvelle base de données.
Cette dernière peut être installée ou non sur le même système.
La méthode faisant appel à des supports est appropriée si vous effectuez
une mise à niveau vers un nouveau système physique pour le serveur et
que vos deux systèmes, l'ancien et le nouveau, ne peuvent pas être
disponibles en même temps, ou si vous ne pouvez pas les connecter à une
réseau haute vitesse. C'est le cas également si vous effectuez une mise à
niveau vers un nouveau système et souhaitez que le serveur version 6.3 ou
ultérieure utilise le même espace de stockage sur disque que le serveur
version 5.
Via un réseau
Vous pouvez simultanément extraire les données de la base de données

d'origine et les charger dans la nouvelle base de données. Cette dernière

peut être installée sur le même système ou sur un système différent
connecté au réseau.
Choisissez cette méthode pour utiliser l'utilitaire de mise à niveau au
maximum de ses performances, en particulier si vous effectuez une
migration à partir d'un système physique vers un nouveau système et que
les systèmes sont connectés via un réseau haute vitesse. L'utilisation du
réseau réduit la quantité de mémoire requise car aucune condition n'est
requise pour l'enregistrement de données non chargées depuis la base de
données version 5 sur disque ou sur bandes.
Dans l'une et l'autre méthode, le serveur d'origine ne peut pas être exécuté en
production pendant l'extraction des données.
Concepts associés:
«utilitaires de mise à niveau DSMUPGRD»
Tâches associées:
utilitaires de mise à niveau DSMUPGRD

Vous pouvez utiliser les utilitaires de mise à niveau DSMUPGRD pour préparer et
extraire les données à partir de la base de données du serveur V5.3, V5.4, ou V5.5
pour l'insertion dans une base de données vide du serveur V6.3 ou ultérieure.
Les utilitaires DSMUPGRD s'exécutent sur la base de données d'origine.
L'utilitaire DSMUPGRD PREPAREDB met à niveau une base de données de serveur vers
la version 5.5 et nettoie les données afin de préparer celles-ci au processus
d'extraction.
Important : Une fois mise à niveau d'une version 5.3 ou 5.4 vers la version 5.5, la
base de données du serveur ne peut plus être utilisée avec un serveur 5.3 ou 5.4. Si
vous ne souhaitez pas mettre à niveau la base de données de votre serveur de
production, vous pouvez restaurer la sauvegarde de la base de données sur un
autre système. Ensuite, mettez à niveau cette copie de la base de données.
L'utilitaire DSMUPGRD EXTRACTDB extrait les données d'une base de données de

serveur. vous pouvez utiliser l'utilitaire pour extraire et insérer simultanément les
données dans une nouvelle base de données via un réseau. Sinon, utilisez
l'utilitaire pour extraire les données de support pour les insérer ultérieurement
dans une nouvelle base de données. L'extraction des données peut s'exécuter au
moyen de plusieurs processus.
Si un problème survient au cours de la préparation ou de l'extraction des données,

vous pouvez faire appel aux utilitaires DSMUPGRD EXTEND DB et DSMUPGRD EXTEND LOG
pour augmenter l'espace disponible pour la base de données ou le journal.
«DSMUPGRD QUERYDB (affichage d'informations sur une base de données
version 5)», à la page 561
«DSMUPGRD PREPAREDB (préparation d'une base de données version 5 pour la
mise à niveau)», à la page 561
«DSMUPGRD EXTRACTDB (extraction de données à partir de la base de données
d'un serveur version 5)», à la page 567
«DSMUPGRD EXTEND DB (extension de la taille de la base de données)», à la
page 572
«DSMUPGRD EXTEND LOG ((augmentez la la taille du journal)», à la page 573
«DSMUPGRD UPDATE (Création d'entrées de registre pour une instance de
serveur version 5)», à la page 574
«DSMSERV INSERTDB (Déplacement d'une base de données de serveur vers une
base de données vide)», à la page 576
DSMSERV LOADFORMAT (Formatage d'une base de données)
Configurations matérielle et logicielle requises pour la mise à niveau

vers le serveur version 6.3 ou ultérieure
Utilisez ces informations comme point de départ.
Pour obtenir les dernières informations sur les configurations matérielles et

logicielles, consultez le site de support du produit à l'adresse http://
www.ibm.com/support/docview.wss?uid=swg21243309.
Pour vérifier votre environnement d'installation, vous pouvez exécuter le

vérificateur de prérequis avant de lancer l'installation. Pour plus d'informations sur
le vérificateur de prérequis, voir «Exécution du vérificateur de prérequis», à la
page 43.
Restrictions : AIX HPUX Linux Solaris Vous pouvez installer et

exécuter le serveur V6.3 ou ultérieure sur un système où DB2 est déjà installé, si
DB2 a déjà été installé indépendamment ou comme partie d'une autre application,
toutefois avec des restrictions. Pour plus de détails, consultez la section
Compatibilité du serveur Tivoli Storage Manager avec d'autres produits DB2 dans
le système.
Restriction : Windows Vous ne pouvez pas installer et exécuter le serveur V6.3 ou

ultérieure sur un système où DB2 est déjà installé, si DB2 a déjà été installé
indépendamment ou comme partie d'une autre application. Le serveur version 6.3
ou ultérieure nécessite l'installation et l'utilisation de la version de DB2 qui
l'accompagne. Le système ne doit comporter aucune autre version de DB2.
Tâches associées:
Configuration matérielle et logicielle requise pour le système

du serveur version 5 mis à niveau
Un serveur version 5.3, 5.4 ou 5.5 peut être mis à niveau vers la version 6.3 ou
ultérieure. Le module des utilitaires de mise à niveau doit être installé sur le
système sur lequel est installée la base de données version 5. Le système version 5

doit respecter la configuration requise pour que les utilitaires de mise à niveau
puissent être exécutés, même si vous prévoyez de placer le serveur mis à jour sur
un nouveau système.
Il se peut que les serveurs V5.3 ou V5.4 s'exécutent sur des systèmes d'exploitation
qui ne sont pas pris en charge par des utilitaires de mise à niveau. Par conséquent,
il peut être nécessaire de mettre à jour votre système avant de lancer la procédure
de mise à niveau. Servez-vous des informations fournies dans le tableau des
tableau 7 ci-dessous pour savoir si vous utilisez l'une des versions de système
d'exploitation qui doivent être mises à jour.
| Lorsque vous prévoyez de mettre à niveau un système, vous devez vérifier que le
| serveur source est au niveau 5.3.6 ou ultérieur et que le correctif temporaire le plus
| récent pour le niveau choisi est installé.
Pour optimiser le processus de mise à niveau et éviter d'éventuels problèmes,

mettez à niveau le serveur V5 vers le niveau le plus récent, puis installez le
correctif temporaire le plus récent pour ce niveau. Suivez les instructions contenues
dans «Déterminer le niveau approprié d'un serveur V5 avant une mise à niveau», à
la page 42. Pour télécharger le groupe de correctif et le correctif temporaire les plus
récents, visitez le site IBM Support Portal à l'adresse http://www.ibm.com/
support/entry/portal/Downloads. Localisez la version appropriée de Tivoli
Storage Manager.
Tableau 7. Versions de système d'exploitation à mettre à niveau pour l'exécution des
utilitaires de mise à niveau
Vous devez mettre à niveau cette
version (ou une version ultérieure)
Système pour pouvoir utiliser les utilitaires
d'exploitationSi vous exécutez cette version... de mise à niveau.
AIX v IBM AIX 5L version 5.1 (32 ou 64 v AIX version 5.3 (64 bits
bits) uniquement)
v AIX version 5.2 (32 ou 64 bits) v AIX version 6.1 (64 bits
uniquement)
HP-UX v PA-RISC : v PA-RISC :
HP-UX 11i version 1.0 (32 ou 64 HP-UX 11i version 2 (64 bits )
bits) HP-UX 11i version 3 (64 bits)
Linux on v Red Hat Enterprise Linux 3 (pris en v Red Hat Enterprise Linux 4
Power charge sur les processeurs v Red Hat Enterprise Linux 5
POWER5 uniquement)
v SUSE Linux Enterprise Server 9 et
v SUSE Linux Enterprise Server 10
8/UnitedLinux 1.0 (pris en charge
v Asianux 2.0 - Red Flag DC 5.0 et
uniquement sur les processeurs
Haansoft Linux 2006 ou Asianux
antérieurs à POWER5)
3.0
v Miracle Linux 4.0 ou Asianux 2.0
v Version 2.3.3 ou ultérieure des
v Bibliothèques GNU C 2.2.5-108 bibliothèques GNU C qui sont
installées sur le système cible
Tableau 7. Versions de système d'exploitation à mettre à niveau pour l'exécution des

utilitaires de mise à niveau (suite)
Vous devez mettre à niveau cette
version (ou une version ultérieure)
Système pour pouvoir utiliser les utilitaires
d'exploitationSi vous exécutez cette version... de mise à niveau.
Linux x86 v Red Hat Enterprise Linux 3 (AS, v Red Hat Enterprise Linux 4
WS, ES) v Red Hat Enterprise Linux 5
v SUSE Linux Enterprise Server v SUSE Linux Enterprise Server 9 et
(SLES) 8 / UnitedLinux 1.0 10
v Version 2.2.5-213 des bibliothèques v Asianux 2.0 - Red Flag DC 5.0,
GNU C Miracle Linux 4.0 et Haansoft
Linux 2006 ou Asianux 3.0
bibliothèques GNU C qui sont
Linux v Red Hat Enterprise Linux 3 v Red Hat Enterprise Linux 4
x86_64
v Red Flag Advanced Server 4.1 v Red Hat Enterprise Linux 5
v SUSE Linux Enterprise Server 8 v SUSE Linux Enterprise Server 9 et
v Version 2.2.5-213 des bibliothèques 10
GNU C v Asianux 2.0 - Red Flag DC 5.0,
Miracle Linux 4.0 et Haansoft
Linux 2006 ou Asianux 3.0
installées sur l'ordinateur cible
Linux v SUSE Linux Enterprise Server 8 / v Red Hat Enterprise Linux 4
zSeries UnitedLinux 1.0 v Red Hat Enterprise Linux 5
v Version 2.2.5-108 des bibliothèques v SUSE Linux Enterprise Server 9 et
GNU C 10
Oracle v Oracle Solaris 8 (64 bits) v SPARC 64 bits :
Solaris
Oracle Solaris 9
Oracle Solaris 10
v x86_64 :
Oracle Solaris 10
Microsoft v Windows 2000 Professional v Windows Server 2003 (Standard,
Windows Enterprise ou Datacenter) Edition
v Windows 2000 Server
v Windows 2000 Advanced Server v Windows Server 2003 (Standard,
Enterprise ou Datacenter) x64
v Windows 2000 Datacenter Server
Edition
v Windows Server 2008 (Standard,
Enterprise ou Datacenter) Edition
v Windows Server 2008 (Standard,
Enterprise ou Datacenter) x64
Edition
Conseil : Les configurations systèmes pour l'utilitaire de mise à niveau sont les
mêmes que pour les configurations systèmes du serveur V5.5 dans la mesure où
cet utilitaire est basé sur le code de serveur V5.5. Consultez la configuration
système requise pour un serveur version 5.5 sur l'un des sites Web suivants.
Comparez le système hébergeant votre serveur version 5.3 ou 5.4 avec la
configuration requise pour un serveur 5.5.
AIX http://www.ibm.com/support/docview.wss?uid=swg21052220
HP-UX
http://www.ibm.com/support/docview.wss?uid=swg21052219
Linux
Linux sur des serveurs Power Systems : http://www.ibm.com/
support/docview.wss?uid=swg21108042
Linux x86 : http://www.ibm.com/support/
docview.wss?uid=swg21107360
Linux x86_64 : http://www.ibm.com/support/
Linux zSeries : http://www.ibm.com/support/
Solaris
Windows
Configuration matérielle et logicielle requise pour le serveur

mis à niveau
Utilisez ces exigences comme point de départ. Pour obtenir des informations
actualisées sur la configuration matérielle et logicielle requise, consultez le site de
support du produit.
Le site de support du produit se trouve à l'adresse http://www.ibm.com/support/

entry/portal/Overview/Software/Tivoli/Tivoli_Storage_Manager.
Si vous mettez à niveau Tivoli Storage Manager sur un système d'exploitation

différent, un ensemble limité de chemins de migration est disponible. Pour obtenir
d'exploitation z/OS, voir Partie 3, «Migration des serveurs Tivoli Storage Manager
version 5 s'exécutant sur des systèmes z/OS vers la version 6 sous AIX ou Linux
on System z», à la page 475. Pour obtenir des instructions sur la migration d'un
serveur qui s'exécute sur un système d'exploitation AIX, HP-UX, ou Solaris, voir
Partie 2, «Migration des serveurs V5 Tivoli Storage Manager sur les systèmes AIX,
HP-UX, ou Solaris vers la version V6.3.4 surLinux», à la page 385.
Certaines plates-formes qui étaient prise en charge par des versions antérieures du
serveur ne sont pas prise en charge pour la version V6.3 ou ultérieure. Si le
serveur s'exécute sur l'une de ces plateformes, vous ne pourrez pas le mettre à
niveau vers la version 6.3 ou ultérieure sur la même plateforme. Pour les
plateformes requises, voir le tableau suivant.
Tableau 8. Plateformes requises pour la mise à niveau de la version 5 à la version 6.3 ou
ultérieure
Plateforme requise pour la mise à niveau
Plateforme pour le serveur version 5 vers la version 6.3 ou ultérieure
HP-UX exécuté sur un système PA-RISC HP-UX exécuté sur un système Intel Itanium

ultérieure (suite)
Linux exécuté sur un système Itanium Linux exécuté sur un système x86_64
(IA64)
Linux exécuté sur un système x86_32 Linux exécuté sur un système x86_64
| Solaris s'exécutant sur un système x86_64 Linux exécuté sur un système x86_64
Windows exécuté sur un système Itanium Windows exécuté sur un système x86_64
(IA64)
Si vous effectuez une mise à niveau de Tivoli Storage Manager version 5 sur la
version 6.3 ou ultérieure sur un nouveau système, des restrictions s'appliquent.
Assurez-vous d'avoir installé le serveur V6.3 ou ultérieure dans un environnement
matériel et logiciel compatible, comme décrit dans le tableau suivant.
Tableau 9. Exigences de mise à niveau de la version 5 vers la version V6.3 ou ultérieure
serveur version 6.3 ou
serveur V5 ultérieure Commentaires
AIX exécuté sur un système AIX exécuté sur un système
IBM POWER IBM POWER
HP-UX exécuté sur un HP-UX exécuté sur un
système Itanium système Itanium
HP-UX exécuté sur un HP-UX exécuté sur un HP-UX exécuté sur un
système PA-RISC système Itanium système PA-RISC non pris en
charge pour les serveurs
version 6.3 ou ultérieure.
Linux exécuté sur un Linux exécuté sur un
système IBM POWER système IBM POWER
Linux exécuté sur un Linux exécuté sur un Linux exécuté sur un
système Itanium (IA64) système x86_64 système Itanium non pris en
système x86_32 système x86_64 système x86_32 n'est pas pris
en charge pour les serveurs
Linux sur System z Linux sur System z


sur un nouveau système (suite)
| Solaris s'exécutant sur un Le système d'xploitation Un serveur version 6.3 ou
| système x86_64 dépend de la méthode de ultérieure ne peut pas être
| migration installé sur un système
| Solaris x86_64. Cependant,
| vous pouvez migrer un
| serveur V5 qui s'exécute sur
| un système d'exploitation
| Solaris x86_64 vers un
| serveur V6.3.4 or ou
| ultérieure sur un système
| d'exploitation Linux x86_64.
| Pour obtenir des instructions,
| voir Partie 2, «Migration des
| serveurs V5 Tivoli Storage
| Manager sur les systèmes
| AIX, HP-UX, ou Solaris vers
| la version V6.3.4 surLinux»,
| à la page 385.
| Sinon, vous pouvez migrer le

| système Solaris x86_64 en
| installant un serveur V6.3 ou
| ultérieure sur n'importe quel
| système d'exploitation pris
| en charge pour la version
| V6.3 ou ultérieure. Utilisez
| ensuite les commandes
| EXPORT et IMPORT du serveur
| Tivoli Storage Manager pour
| déplacer le serveur du
| système source de version 5
| au système cible de version
| 6.3 ou ultérieure.
Windows exécuté sur un Windows exécuté sur un Windows exécuté sur un
système Itanium (IA64) système x86_64 système Itanium n'est pas
pris en charge pour les
serveurs version 6.3 ou
ultérieure.
système x86_32 système x86_64 système x86_32 non pris en
charge pour des serveurs
z/OS AIX ou Linux sur System z Pour obtenir des instructions,
voir Partie 3, «Migration des
serveurs Tivoli Storage
Manager version 5
s'exécutant sur des systèmes
z/OS vers la version 6 sous
AIX ou Linux on System z»,
à la page 475.
Configuration requise pour le serveur sur des systèmes AIX

AIX
Vérifiez que votre système AIX remplit ces conditions.
Configuration matérielle requise
Le tableau suivant présente la configuration matérielle minimale requise.
Pour toute information sur l'estimation de l'espace disque total requis, voir
serveur mis à niveau», à la page 47.
Tableau 10. Configurations matérielles
Type de
matériel Configurations matérielles
Matériel Un ordinateur POWER4, POWER5, POWER6, POWER7 (64 bits)
correctement configuré.
Espace disque L'espace disque minimal suivant est requis :
v 5 Mo pour le répertoire /var
v 2 Go pour le répertoire /opt/tivoli/tsm
v 30 Mo pour le répertoire /opt si vous créez des points de montage
v 360 Mo pour le répertoire /tmp
v 300 Mo pour le répertoire /usr
v 2 Go dans le répertoire de base
Conseil : Prévoyez d'utiliser plus d'espace pour l'identification des
problèmes.
Il est nécessaire de prévoir de l'espace disque supplémentaire pour la base

de données et les fichiers journaux. La taille de la base de données dépend
du nombre de fichiers client à stocker et de la méthode utilisée par le
serveur pour la gestion de ces fichiers. L'espace requis par le journal actif
par défaut est de 16 Go, volume minimal nécessaire pour la majorité des
charges de travail et des configurations. Allouez au moins trois fois l'espace
du journal actif au journal d'archivage (48 Go). Vérifiez que vous disposez
des ressources nécessaires en cas de dédoublonnage de données ou si vous
prévoyez une charge de travail client conséquente.
| Pour des performances optimales et pour faciliter l'entrée-sortie, indiquez

| au moins deux conteneurs de dimension égale ou des numéros d'unité
| logique (LUNs) pour la base de données. Voir Optimisation des performances
| pour plus d'informations sur la configuration des répertoires de la base de
| données. En outre, chaque journal actif et d'archivage doit avoir son propre
| conteneur ou numéro d'unité logique.
Pour plus de détails sur l'espace disque, reportez-vous à la section sur la

planification de la capacité.

Tableau 10. Configurations matérielles (suite)

Type de
Mémoire v 12 Go.
(minimum)
v 16 Go en cas de dédoublonnage de données.
v Au moins 32 Go pour des serveurs fortement utilisés. L'utilisation de 32
Go ou plus de mémoire améliore la performance de l'inventaire de la
base de données du serveur Tivoli Storage Manager.
v Si vous prévoyez d'exécuter plusieurs instances, elles nécessitent chacune
le volume de mémoire indiqué pour un serveur. Multipliez le volume de
mémoire d'un serveur par le nombre d'instances planifiées pour le
système.
| v Le traitement de la réplication de noeud nécessite plus de mémoire.
| Utilisez un minimum de 32 Go de mémoire pour la réplication de noeud
| sans dédoublonnage de données. La réplication de noeud associé au
| dédoublonnage de données requiert un minimum de 64 Go de mémoire.
Configuration logicielle requise
Le tableau suivant présente la configuration logicielle minimale requise.

Tableau 11. Configurations logicielles
Type de
logiciel Configurations logicielles minimales
Système AIX 6.1 exécuté dans un environnement de noyau 64 bits avec la
d'exploitation configuration supplémentaire suivante :
v AIX 6.1 TL 2.
v Les systèmes POWER7 nécessitent AIX 6.1 TL 4.
v Niveau d'exécution minimal C++ avec les ensembles de fichiers xlC.rte
11.1.0.1 et xlC.aix61.rte 11.1.0.1 ou ultérieurs. Ces ensembles de fichiers
sont inclus dans le package destiné à IBM C++ Runtime Environment
Components for AIX du mois de juin 2008.
AIX 7.1 s'exécutant dans un environnement de noyau 64 bits.

v Le niveau d'exécution minimal C++ exige des ensembles de fichiers
xlC.rte 11.1.0.1 et xlC.aix61.rte 11.1.0.1 ou ultérieurs. Ces ensembles de
fichiers sont inclus dans le module IBM C++ Runtime Environment
Components for AIX V11.1 d'avril 2010.
Pour connaître les dernières recommandations relatives aux niveaux de

maintenance AIX, voir http://www.ibm.com/support/
Navigateur Navigateur Web pour extraire un module d'installation en ligne. Les
Web navigateurs suivants sont pris en charge :
v Microsoft Internet Explorer 7.0 ou supérieur
v Firefox 3.5 ou supérieur
Votre navigateur doit prendre en charge la page de codes du serveur. Si

votre navigateur ne prend pas en charge la page de codes de serveur, il
se peut que la fenêtre soit illisible. Si votre navigateur correspond à ces
critères mais n'affiche pas correctement une interface Web Tivoli Storage
Manager, envisagez d'utiliser un navigateur différent.
Protocole de Une méthode de communication configurée.
communication
Tableau 11. Configurations logicielles (suite)

Type de
Traitement Les E-S asynchrones doivent être activées.
Pilotes Installez le pilote de périphérique Tivoli Storage Manager le plus récent.
Le pilote doit être configuré avant d'utiliser le serveur Tivoli Storage
Manager avec des unités de bande.
Vous pouvez localiser des pilotes de périphérique IBM sur le site Web Fix
Central.
1. Accédez au site Web Fix Central : http://www.ibm.com/support/
fixcentral/.
2. Sélectionnez Storage Systems pour le groupe de produits.
3. Sélectionnez Tape Systems pour la famille de produits.
4. Sélectionnez Tape device drivers and software pour le type de
produit.
5. Sélectionnez Tape device drivers pour le produit.
6. Sélectionnez votre système d'exploitation pour la plateforme.
Utilitaire L'utilitaire gunzip doit être disponible sur votre système pour installer ou
Gunzip mettre à niveau le serveur Tivoli Storage Manager version 6. Vérifiez que
l'utilitaire gunzip est installé et que son chemin d'accès est défini dans la
variable d'environnement PATH.
Autres logiciels Interpréteur de commandes Korn (ksh)
Configuration requise du serveur sur des systèmes HP-UX

HPUX
Vérifiez que votre système HP-UX respecte la configuration requise.
Vous ne pouvez pas exécuter un serveur version 6.3 ou ultérieure sur un système
PA-RISC sous HP-UX. Si le serveur s'exécute sur cette plateforme, vous ne pourrez
pas le mettre à niveau vers la version 6.3 ou ultérieure sur celle-ci. Vous devez
installer votre serveur version 6.3 ou ultérieure sur un système Itanium exécutant
le système d'exploitation HP-UX, puis mettre à niveau votre serveur version 5 pour
ce système à l'aide de la méthode utilisant un réseau ou des supports.
Type de
Matériel Un système Intel Itanium 64 bits.

Tableau 12. Configurations matérielles (suite)

Type de
v 2 Go pour le répertoire /opt si vous ne créez pas de points de montage
problèmes.



Mémoire v 12 Go.
système.
Les ressources système telles que les valeurs de sémaphore et de noyau requièrent
une configuration et un réglage particuliers. Reportez-vous à l'Annexe C,
«Ressources requises pour le système HP-UX», à la page 591.

Type de
logiciel Configuration logicielle minimale
Système Le système Itanium HP doit être doté d'un système d'exploitation 11i v3
d'exploitation (11.31) avec les niveaux de maintenance les plus récents installés.
11i v3 avec :
v PHCO_38658 - correctif cumulatif libc
Les correctifs les plus récents au système d'exploitation doivent être

appliqués. Les niveaux plus anciens pour lesquels il n'existe pas de
correctifs ne fonctionnent pas avec les pilotes d'unités utilisés par Tivoli
Storage Manager.
Protocole de Une méthode de communication installée et activée (la mémoire partagée
communication correspond à la valeur par défaut).
Périphériques v Un lecteur de DVD-ROM disponible pour l'installation si vous installez
et pilotes à partir d'un support DVD-ROM.
v Le module du pilote de périphérique Tivoli Storage Manager ne
contient pas de pilote de périphérique pour ce système d'exploitation
car un pilote de périphérique générique SCSI est utilisé. Configurez le
pilote de périphérique avant d'utiliser le serveur Tivoli Storage
Manager avec des unités de bande.
Le module du pilote Tivoli Storage Manager contient des outils de
pilote et des démons ACSLS. Vous pouvez localiser des modules de
pilotes IBM sur le site Web Fix Central.
fixcentral/.
produit.
Configuration du serveur requise sur des systèmes Linux

Linux
Vérifiez que votre système Linux respecte la configuration requise.
Certaines plateformes qui étaient prises en charge par des versions antérieures du
serveur ne le sont plus pour la version 6.3 ou ultérieure :
v Linux exécuté sur un système Itanium (IA64)
v Linux exécuté sur un système x86 32 bits
Si le serveur s'exécute sur l'une de ces plateformes, vous ne pourrez pas le mettre à
niveau vers la version 6.3 ou ultérieure sur la même plateforme. Vous devez
installer votre serveur version 6.3 ou ultérieure sur un système x86_64 exécutant le
système d'exploitation Linux puis mettre votre serveur version 5 à niveau pour ce

système à l'aide de la méthode utilisant un réseau ou des supports.
Configuration du serveur requise pour Linux sur des systèmes POWER :

Linux
Le serveur Tivoli Storage Manager respecte la configuration matérielle et logicielle

minimale requise.
| Si vous disposez d'IBM 3592 ou d'une bandothèque Ultrium ou d'une unité,

| installez le pilote de périphérique le plus récent avant d'installer Tivoli Storage
| Manager. Vous pouvez localiser les unités de périphérique dans
| http://www.ibm.com/support/fixcentral/.
Tableau 14. Configuration matérielle
Type de
matériel Configuration matérielle
Matériel Un serveur Linux on Power Systems sur un système IBM, tel que l'un de
ceux répertoriés dans le site Web suivant :
http://www.ibm.com/systems/power/software/linux/about/index.html
problèmes.



Tableau 14. Configuration matérielle (suite)

Type de
Mémoire v 12 Go.
système.

Tableau 15. Configuration logicielle requise
Type de
Système Le serveur Tivoli Storage Manager sur Linux on Power (architecture
d'exploitation ppc64) nécessite l'un des systèmes d'exploitation suivants :
v Red Hat Enterprise Linux 5 , mise à jour 3 ou suivante
v Red Hat Enterprise Linux 6
v SUSE Linux Enterprise Server 10, Service Pack 2 ou suivant
Et l'élément supplémentaire suivant :

v Niveau d'environnement d'exécution C++ minimum avec xlC 8.0.0.0
Pour télécharger le module d'exécution XL C++, accédez au site Web
suivant : http://www.ibm.com/software/awdtools/xlcpp/. Pour plus de
détails sur cette condition système requise, consultez le site Web suivant :
http://www.ibm.com/software/data/db2/9/sysreqs.html.
Bibliothèques Bibliothèques GNU C, version 2.4-31.30 et versions ultérieures.
| libaio.so.1 pour les serveurs Red Hat Enterprise Linux et SUSE Linux
| Enterprise (les packages 32 et 64 bits sont requis).
Si vous utilisez SUSE Linux Enterprise Server 11, téléchargez le package

d'exécution XL C/C++ V10.1. Voir le lien http://www.ibm.com/support/
docview.wss?uid=swg24022673 pour les instructions.
Protocole de v TCP/IP version 4 ou 6, standard pour Linux
communication
v Protocole de mémoire partagée (avec un client Tivoli Storage Manager
Version 6.3 ou ultérieure System p)
Traitement Les E-S asynchrones doivent être activées. Sur les noyaux Linux version
2.6 ou ultérieure, installez la bibliothèque libaio pour activer les E-S
asynchrones.

Tableau 15. Configuration logicielle requise (suite)

Type de

Configuration du serveur requise pour Linux sur des systèmes x86_64 : Linux

minimale requise.

Type de
Matériel Processeur AMD64 ou Intel EMT-64
Tableau 16. Configuration matérielle (suite)

Type de
problèmes.



Mémoire v 12 Go.
système.


Type de
Système Le serveur Tivoli Storage Manager pour Linux x86_64 requiert l'un des
d'exploitation systèmes d'exploitation suivants :
Bibliothèques La bibliothèque GNU C, version 2.3.3-98.38 ou ultérieure est installée sur
le système Tivoli Storage Manager.
Pour les serveurs Red Hat Enterprise Linux et SUSE Linux Enterprise :
| v libaio.so.1 (packages 32 et 64 bits requis)
| v libstdc++.so.5 (packages 32 et 64 bits requis)
communication
Version 6.3 ou ultérieure Linux x86_64)
asynchrones.

Configuration du serveur requise pour Linux sur des systèmes System z :

Linux

minimale requise.

Type de
Matériel Une partition logique native IBM zSeries, IBM System z9, IBM System z10
ou IBM zEnterprise System (z114 et z196) 64 bits ou un invité z/VM.
problèmes.



Mémoire v 12 Go.
système.


Type de
Système Le serveur Tivoli Storage Manager pour Linux sur System z (architecture
d'exploitation s390x 64 bits) requiert l'un des systèmes d'exploitation suivants :
Bibliothèque La bibliothèque GNU C, version 2.4-31.43.6, est installée sur le système
Pour les serveurs Red Hat Enterprise Linux et SUSE Linux Enterprise :
| v libaio.so.1 (packages 32 et 64 bits requis)
communication
Version 6.3 ou ultérieure Linux sous System z)
asynchrones.

Exigences du serveur sur les systèmes Solaris

Solaris
Vérifiez que votre système Solaris respecte la configuration requise.

Type de
Matériel L'un des processeurs suivants est requis :
v Processeurs Ultra SPARC (architecture sun4u)
v Processeurs Ultra SPARC (architecture sun4v)
Espace disque La liste suivante répertorie l'espace disque minimal requis pour des
processeurs de type Ultra SPARC (architecture sun4u et sun4v) pour les
répertoires et journaux respectifs :
problèmes.



Mémoire v 12 Go.
système.
Conseil : Vérifiez qu'il y a au moins deux fois plus d'espace de
permutation alloué que de mémoire physique sur le système.


Type de
Système Oracle Solaris 10, en mode 64 bits sur un système Ultra Sparc avec une
d'exploitation architecture sun4u ou sun4v
v Correctif 118822-25
v Si des périphériques bruts sont utilisés, correctif 125100-07
Protocole de TCP/IP
communication
| Périphériques Si vous disposez d'une unité IBM 3570, 3590, 3592, ou d'une
| et pilotes bandothèque, installez le pilote de périphérique le plus récent.
| Configurez le pilote de périphérique avant d'utiliser le serveur Tivoli
| Storage Manager avec des unités de bande.
Vous pouvez localiser des pilotes de périphérique IBM sur le site Web Fix
Central.
fixcentral/.
produit.
Solaris Zones : Avant d'installer le serveur dans une zone, vérifiez que cette
dernière est configurée avec un accès en écriture au niveau du répertoire /usr.
Pour installer un serveur dans une zone Solaris, cette dernière doit avoir un accès
en écriture au niveau des répertoires /usr, /opt, /var et /tmp. Les zones par défaut
ne disposent pas d'accès en écriture au niveau du répertoire /usr. Voir Annexe D,
«Utilisation des zones Solaris», à la page 593.
Configuration requise pour le serveur sur des systèmes

Microsoft Windows
Windows
Vérifiez que votre système Microsoft Windows respecte la configuration.
Vous ne pouvez pas exécuter un serveur version 6.3 ou ultérieure sur un système
Itanium (IA64) doté d'un système d'exploitation Windows. Si le serveur s'exécute
sur cette plateforme, vous ne pourrez pas le mettre à niveau vers la version 6.3 ou
ultérieure sur celle-ci. Vous devez installer votre serveur version 6.3 ou ultérieure
sur un système x86_64 exécutant le système d'exploitation Windows puis mettre

votre serveur version 5 à niveau pour ce système à l'aide de la méthode utilisant
un réseau ou des supports.
Type de
Matériel Processeur AMD64 ou Intel EMT-64
Espace disque v Au moins 3 Go d'espace disque libre (pour une installation classique)
v 200 Mo d'espace de répertoire temporaire
v Taille de partition de 2 Go sur l'unité C:\
v 300 Mo dans le répertoire de base



Mémoire v 12 Go.
système.


Tableau 23. Configuration logicielle
Type de
Système L'un des systèmes d'exploitation suivants :
d'exploitation v Microsoft Windows Server 2008 : Standard, Enterprise ou Datacenter
x64 Edition (64 bits)
v Microsoft Windows Server 2008 R2 : Standard, Enterprise ou
Datacenter Edition (64 bits)
| v Microsoft Windows 2012 (64-bits)
Protocole de Au moins l'un des protocoles de communication suivants (installé par
communication défaut avec les systèmes d'exploitation Windows actuels) :
v Tubes nommés
v TCP/IP version 4 ou version 6

Fonctions Les fonctions du système Windows, comme Device Manager, sont prises
système en charge sur la console Tivoli Storage Manager 64 bits.
Les fonctions normales du système Windows sont disponibles pour le

serveur 64 bits à l'aide de la fonction Manage Computer du système
Windows.
| Autres logiciels Windows 2012 requiert l'installation et l'activation de .NET Framework
| 3.5.
Compatibilité du serveur Tivoli Storage Manager avec d'autres

produits DB2 sur le système
Vous pouvez installer d'autres produits qui déploient et utilisent les produits DB2
sur le même système que le serveur Tivoli Storage Manager 6.3 ou ultérieure sur
les plateformes AIX, HP-UX, Linux et Oracle Solaris, avec certaines restrictions.
Pour installer et utiliser d'autres produits utilisant un produit DB2 sur le même
système que le serveur Tivoli Storage Manager, vérifiez que vous respectez les
critères suivants :
Tableau 24. Compatibilité du serveur Tivoli Storage Manager avec d'autres produits DB2 sur
le système
Critères Instructions
Niveau de version Les autres produits qui utilisent un produit
DB2 doivent utiliser DB2 version 9 ou une
version ultérieure. Les produits DB2
comprennent l'encapsulation de produit et le
support de ségrégation depuis la version 9.
A compter de cette version, vous pouvez
exécuter plusieurs copies des produits DB2,
à différents niveaux de code et sur le même
système. Pour plus d'informations, voir les
informations relatives à plusieurs copies DB2
: http://pic.dhe.ibm.com/infocenter/
db2luw/v9r7.
ID utilisateur et répertoires Vérifiez que les ID utilisateur, les ID
utilisateur isolé, l'emplacement d'installation,
les autres répertoires et les informations
associées ne sont pas partagés entre les
installations DB2. Vos spécifications doivent
être différentes des ID et emplacements
utilisés pour l'installation et la configuration
du serveur Tivoli Storage Manager. Si vous
avez utilisé l'assistant dsmicfgx ou
dsmupgdx pour configurer la version 6.3 ou
ultérieure, ou pour la mise à niveau du
serveur à partir de la version 5.5, il s'agit
des valeurs que vous avez entrées lors de
l'exécution de l'assistant. Si vous avez utilisé
les procédures manuelles de configuration
pour la version 6.3 6.3 ou ultérieure ou la
mise à niveau à partir de la version 5.5,
vérifiez ces procédures si nécessaire pour
sélectionner de nouveau les valeurs utilisées
pour le serveur.

le système (suite)
Attribution de ressources Examinez les ressources et la capacité du
système par rapport aux conditions requises
pour le serveur Tivoli Storage Manager et
les autres applications utilisant le produit
DB2. Pour fournir des ressources suffisantes
aux autres applications DB2, vous devrez
modifier les paramètres du serveur Tivoli
Storage Manager, de sorte que ce dernier
utilise moins de mémoire système et de
ressources. De même, si les charges de
travail pour les autres applications DB2
entrent en concurrence avec le serveur Tivoli
Storage Manager en termes de processeur ou
de ressources mémoire, les performances du
serveur en matière de gestion de la charge
de travail du client ou toute autre opération
côté serveur risquent d'être également
affectés.
Pour scinder les ressources et offrir

davantage de capacité pour le réglage et
l'allocation de processeur, mémoire et toute
autre ressource système pour plusieurs
applications, envisagez d'utiliser un système
de partition logique (LPAR), de partition de
charge de travail (WPAR) ou tout autre
support de poste de travail virtuel. Par
exemple, exécutez une application DB2 sur
son propre système virtualisé.
| Déterminer le niveau approprié d'un serveur V5 avant une mise à

| niveau
| Lorsque vous préparez un système pour une mise à niveau, vous devez vérifier le
| niveau du serveur V5 et mettre à jour le serveur, si nécessaire. En procédant à la
| révision des lignes directrices et en amenant le niveau du serveur V5 à un niveau
| approprié, vous pouvez optimiser l'opération de mise à niveau suivante à V6.
| Les lignes directrices s'appliquent aux mises à niveau du serveur de V5 vers V6

| sur le même système d'exploitation. Les lignes directrices s'appliquent également si
| vous faites migrer un serveur V5 vers V6 sur un système d'exploitation différent.
| A partir de la version V5.3.6 ou d'une version ultérieure, vous pouvez mettre à

| niveau le serveur et passer en V6. Toutefois, afin de déterminer le niveau le plus
| approprié pour un serveur V5 avant le passage vers V6, passez en revue les lignes
| directrices suivantes:
| v La méthode recommandée consiste à mettre à niveau le serveur de façon à
| atteindre le dernier niveau de V5 avant de mettre le serveur à V6. Vous pourrez
| ainsi utiliser les dernières fonctionnalités de mise à jour pour extraire des
| informations d'une base de données serveur source et insérer des informations
| dans une base de données du serveur cible.
| v Lorsque vous mettez à jour le serveur V5, installez le dernier correctif

| temporaire. Vous pourrez ainsi réduire les risques d'occurrence de problèmes liés
| à la mise à jour.
| v Parce les fonctionnalités de mise à niveau sont fournies dans un package séparé,
| vous pouvez installer la dernière version des fonctionnalités sans pour autant
| procéder à la mise à niveau du serveur V5. Si vous installez uniquement les
| fonctionnalités de mise à niveau, les restrictions suivantes s'appliquent:
| – Pour éviter un problème potentiel lors de l'extraction de données, les
| fonctionnalités de mise à niveau doivent être de niveau V5.5.4 ou version
| ultérieure.
| – Les fonctionnalités de mise à jour doivent être de même niveau que le
| serveur V5, ou d'une version ultérieure.
| – Si vous envisagez d'extraire la base de données du serveur vers un support,
| la méthode recommandée consiste à la mise à niveau du serveur source en
| vue d'obtenir la version V5.5.6 ou version ultérieure. Si le serveur source est
| au niveau V5.5.6 ou version ultérieure, le serveur cible doit être au niveau
| V6.1.5 ou version ultérieure, V6.2.3 ou version ultérieure, ou V6.3.0 ou une
| version ultérieure.
| Pour trouver le dernier niveau du serveur V5 et les derniers correctifs temporaires,
| consultez le portail de prise en charge d' IBM ® à http://www.ibm.com/support/
| entry/portal/Downloads.
Exécution du vérificateur de prérequis

Le vérificateur de prérequis est un outil facultatif gratuit qui vérifie le système
d'exploitation, le volume d'espace disque disponible pour l'installation et la
mémoire minimale nécessaire pour installer le serveur Tivoli Storage Manager et
d'autres prérequis.
Pour vous assurer que votre environnement système est approprié pour
l'installation, vous pouvez exécuter le programme de vérification des conditions
prérequises avant chaque installation.
Conseil : Ce dernier vérifie uniquement la mémoire minimale requise. Pour des

tâches supplémentaires, plus de mémoire est nécessaire.
Le vérificateur des conditions prérequises présente un récapitulatif des résultats à

la fin de la vérification. Toutes les modifications devant être apportées à votre
environnement avant l'installation sont répertoriées. Tous les répertoires requis
pour l'installation sont créés.
Pour exécuter le vérificateur, procédez comme suit.

1. Assurez-vous que le module d'installation approprié est téléchargé et que ses
fichiers sont extraits. Le vérificateur des conditions prérequises fait partie du
module d'installation.
2. Choisissez l'interface graphique (valeur par défaut) ou la méthode de console
pour démarrer l'installation, et suivez les instructions de l'assistant pour
l'exécuter :
v Exécutez la commande suivante pour démarrer l'assistant d'installation à

l'aide de l'interface graphique :
./prereqcheck.bin


l'aide de la méthode de console :
./prereqcheck.bin -i console
Windows

l'aide de l'interface graphique :
prereqcheck.exe
Ou cliquez deux fois sur le fichier prereqcheck.exe.

l'aide de la méthode de console :
prereqcheck.exe -i console
3. Sélectionnez la langue de l'interface utilisateur du programme de vérification
des prérequis.
4. Dans les panneaux d'accueil et d'exclusion de responsabilité, consultez les
instructions et acceptez-les.
Si la page Prerequisite Results indique que votre système a passé avec succès les
contrôles, vous êtes prêt à démarrer l'installation.
Si un message d'erreur s'affiche sur la page Prerequisite Results, procédez aux

corrections requises avant de poursuivre avec l'installation. La page récapitulative
répertorie les erreurs et vous dirige vers le fichier journal des erreurs.
Planification de l'espace nécessaire au processus de mise à niveau et

au serveur mis à niveau
Planifiez l'espace disque nécessaire au processus de mise à niveau, à la base de
données du serveur et au journal de reprise du serveur mis à niveau. Prenez en
compte l'espace disque actuellement utilisé par le serveur et déterminez si les
modifications matérielles peuvent être planifiées pour coïncider avec la mise à
niveau du serveur.
Espace requis pour le système du serveur version 5

L'espace nécessaire pour stocker la sauvegarde de la base de données du serveur
est une étape importante de la préparation du processus de mise à niveau. Si vous
utilisez la méthode via des supports pour transférer les données, vous avez besoin
d'espace pour stocker les données extraites.
La sauvegarde de la base de données du serveur exige autant d'espace que pour la

base de données version 5. Utilisez des supports à accès séquentiel adaptés, tels
qu'une bande ou un disque.
D'autres contraintes en matière d'espace requis dépendent de la méthode choisie

pour le transfert des données à partir de la base de données version 5 :
Via des supports
Vous avez besoin de supports pour stocker les données qui seront extraites
de la base de données version 5. Il peut s'agir d'espace sur bande ou sur
disque défini en tant que classe d'unités de disque à accès séquentiel.
L'espace requis pour les données extraites est le même que celui utilisé
dans votre base de données. Si cette dernière est sauvegardée dans de
bonnes conditions et que vous n'avez plus besoin d'exécuter le serveur
version 5, vous pouvez en option libérer l'espace utilisé par la base de

données version 5 et le journal de reprise une fois l'extraction terminée.
Via un réseau
Vous devez disposer d'une copie de travail de la base de données et du
journal de reprise version 5 sur le système version 5. Si vous utilisez une
copie de la base de données qui a été créée dans le but de tester le
processus de mise à niveau, vous devez disposer d'un espace suffisant
pour contenir la taille allouée totale de la base de données ; vous pouvez
utiliser la taille minimale pour un journal de reprise version 5.
Tâches associées:
Espace requis pour le système du serveur version 6

Avant de commencer le processus de mise à niveau, planifiez l'espace disque
nécessaire pour la base de données et le journal de reprise. L'emplacement des
répertoires du journal de reprise et de la base de données est très important pour
les opérations effectuées sur le serveur.
Vous avez besoin de répertoires uniques et vides pour les éléments suivants du
serveur mis à niveau :
v Base de données
v Journal de reprise
– Journal actif
– Journal d'archivage
– Facultatif : copie miroir du journal d'archivage
– Facultatif : journal d'archivage secondaire (journal des reprises d'archivage)
v Le répertoire d'instance du serveur, destiné à contenir les fichiers spécifiques de
cette instance de serveur (fichier des options de serveur et autres fichiers
spécifiques du serveur)
Localisez la base de données et le journal actif dans un emplacement de stockage

rapide et fiable, disposant d'une forte disponibilité. La configuration idéale consiste
à utiliser plusieurs répertoires pour l'espace de la base de données, situés sur
autant d'unités physiques ou numéros d'unités logiques que de répertoires.
Placez les répertoires du journal de reprise et de la base de données sur des

volumes physiques ou des systèmes de fichiers distincts.
Afin de conserver l'intégrité de la base de données, vérifiez que le matériel de

stockage choisi peut résister à des défaillances, telles que les coupures de courant
ou des pannes du contrôleur. Vous pouvez améliorer les performances de la base
de données en utilisant un matériel fournissant une mémoire cache d'écriture
rapide et non volatile à la base de données et aux journaux.

Tâches associées:
Information associée:
Site de support de Tivoli Storage Manager
Espace requis pour la base de données

La quantité d'espace de base de données requise dépend de la taille de la base de
données V5 d'origine et de la quantité de données pouvant être gérée par le
serveur.
La quantité d'espace de stockage de la base de données est géré automatiquement.

L'espace de la base de données peut être réparti sur un maximum de 128
répertoires. Une fois que vous avez indiqué les répertoires pour la base de
données, le serveur utilise l'espace disque disponible sur ces répertoires si
nécessaire.
Prévoyez un espace à 33 à 50% plus important que celui utilisé par la base de
données de la version 5. (N'incluez pas dans l'estimation l'espace inutilisé alloué
pour la base de données version 5.) Certaines bases de données peuvent s'accroître
temporairement pendant le processus de mise à niveau ; prévoyez de fournir un
espace supérieur de 80 % à celui utilisé par la base de données version 5.
Estimez la quantité d'espace qui sera requis par la base de données pour effectuer
les étapes suivantes :
1. Utilisez la commande QUERY DB FORMAT=DETAILED pour déterminer le nombre de
pages de base de données utilisées dans la base de données version 5.
2. Multipliez ce nombre par 4096 pour obtenir le nombre d'octets utilisés.
3. Ajoutez entre 33 et 50 % à ce nombre afin d'estimer l'espace nécessaire pour la
base de données.
Testez la mise à niveau de la base de données afin d'obtenir une estimation plus
précise. Toutes les bases de données ne verront pas leur espace s'accroître de 33 à
50%.
Lorsque que le serveur fonctionne normalement, il se peut qu'après le processus de

mise à niveau, certaines opérations causent une augmentation temporaire
importante de la quantité d'espace utilisé par la base de données. Continuez de
surveiller l'utilisation de l'espace de base de données afin de déterminer si cet
espace doit être augmenté pour le serveur.
Pour optimiser les performances de la base de données, anticipez sa croissance

future lorsque vous définissez l'espace que vous lui est affectez. Si vous
sous-estimez l'espace nécessaire et devez ensuite ajouter des répertoires
supplémentaires, le gestionnaire de base de données devra effectuer une nouvelle
réorganisation de la base de données, ce qui consomme des ressources sur le
système. Faites une estimation des exigences liées à la croissance de la base de
données, en fonction du nombre prévu d'objets supplémentaires à stocker dans
l'espace de stockage du serveur. Pour plus d'informations sur l'estimation des
besoins d'une base de données en matière d'espace, voir Guide d'administration.
Restriction : Vous ne pouvez pas utiliser de volumes logiques bruts pour la base
de données. Pour réutiliser l'espace disque qui était occupé par des volumes
logiques bruts dans une version antérieure du serveur, vous devez d'abord créer
des systèmes de fichiers sur le disque.
Pour les dernières informations et recommandations, rendez-vous sur le site de

support Tivoli Storage Manager à l'adresse suivante : http://www.ibm.com/
support/entry/portal/Overview/Software/Tivoli/Tivoli_Storage_Manager.
Espace requis pour le journal de reprise

La quantité d'espace requis pour le journal de reprise dépend de différents
facteurs, comme le niveau d'activité du client avec le serveur.
Pour plus d'informations, voir la section décrivant les exigences en matière

d'espace réservé au journal de reprise dans IBM Tivoli Storage Manager Guide
d'installation.
Pour connaître les dernières informations et mises à jour, consultez le site du

support deTivoli Storage Manager à l'adresse suivante : http://www.ibm.com/
Estimation de l'espace disque total requis pour le processus

de mise à niveau et le serveur mis à niveau
En plus de celui requis pour le serveur mis à niveau lui-même, un espace disque
supplémentaire est nécessaire pour le processus de mise à niveau. Par exemple, si
vous mettez à niveau le serveur sur le système où il est déjà installé, vous aurez
besoin d'un espace suffisant pour stocker les deux copies de la base de données au
cours du processus de mise à niveau.
L'espace requis pour le serveur version 6.3 ou ultérieure mis à niveau dépend de la
taille de la base de données version 5 et d'autres facteurs. Pour plus
d'informations, voir «Espace requis pour la base de données», à la page 46 et
«Espace requis pour le journal de reprise».
L'espace requis pour le processus de mise à niveau dépend du mode de transfert

des données de la base de données version 5 vers la nouvelle base de données.
Vous pouvez transférer les données vers la nouvelle base de données via des
supports ou via un réseau, si les conditions requises suivantes sont remplies :
v La méthode avec supports requiert des supports à accès séquentiel. Il peut s'agir
d'un bande ou d'une classe d'unités de disque à accès séquentiel (unité de type
FILE).
v Selon la deuxième méthode, une connexion réseau doit être établie entre les
systèmes si vous effectuez la mise à niveau sur un nouveau système.
Le tableau 25 fournit des conseils de base sur l'estimation de chaque élément pour
chacun des scénarios principaux. Vous trouverez des informations sur le
dimensionnement de la base de données et du journal de reprise version 6.3 ou
ultérieure à la rubrique «Espace requis pour le système du serveur version 6», à la
page 45.
Tableau 25. Conseils d'estimation de l'espace requis. Sélectionnez le scénario et lisez le contenu de la colonne.
Elément qui Type Scénario 1 : Scénario 2 : Scénario 3 : Scénario 4 :
requiert de d'espace v Même système v Même système v Nouveau v Nouveau
l'espace que le serveur que le serveur système système
version 5 version 5 v Via des supports v Via un réseau
v Via des supports v Via un réseau
Base de données Disque Espace alloué à la Espace alloué à la 0 0
V5 : espace alloué base de données V5 base de données V5
à la base de
données initiale

Tableau 25. Conseils d'estimation de l'espace requis (suite). Sélectionnez le scénario et lisez le contenu de la
colonne.
Base de données Supports à Espace utilisé par Espace utilisé par Espace utilisé par la Espace utilisé par
V5 : copie de accès la base de données la base de données base de données V5 la base de données
sauvegarde finale séquentiel V5 (basé sur le taux V5 (basé sur le taux (basé sur le taux V5 (basé sur le taux
(%) d'utilisation) (%) d'utilisation) (%) d'utilisation) (%) d'utilisation)
Base de données Supports à Espace utilisé par 0 Espace utilisé par la 0
V5 : données accès la base de données base de données V5
extraites séquentiel V5 (basé sur le taux (basé sur le taux
(%) d'utilisation) (%) d'utilisation)
Journal de reprise Disque Quantité d'espace Quantité d'espace 0 0
V5 alloué pour le alloué pour le
journal de reprise journal de reprise
V5 V5
Base de données Disque Espace utilisé par Espace utilisé par Espace utilisé par la Espace utilisé par
V6.3 ou ultérieure la base de données la base de données base de données la base de données
: taille estimée V5, plus 33 à 50 % V5, plus 33 à 50 % V5, plus 33 à 50 % V5, plus 33 à 50 %
Base de données Supports à Identique à la taille Identique à la taille Identique à la taille Identique à la taille
version 6.3 ou accès de base de données de base de données de base de données de base de données
ultérieure : séquentiel estimée estimée estimée estimée
première
sauvegarde
Répertoire de Disque 16 Go pendant le 16 Go pendant le 16 Go pendant le 16 Go pendant le
journal actif processus de mise à processus de mise à processus de mise à processus de mise à
version 6.3 ou niveau. Il pourra niveau. Il pourra niveau. Il pourra niveau. Il pourra
ultérieure être nécessaire être nécessaire être nécessaire être nécessaire
d'indiquer une d'indiquer une d'indiquer une d'indiquer une
valeur supérieure valeur supérieure valeur supérieure valeur supérieure
pour permettre le pour permettre le pour permettre le pour permettre le
fonctionnement fonctionnement fonctionnement fonctionnement
normal du serveur. normal du serveur. normal du serveur. normal du serveur.
Copie miroir du Disque Si utilisée, même Si utilisée, même Si utilisée, même Si utilisée, même
journal actif V6.3 taille que le journal taille que le journal taille que le journal taille que le journal
ou ultérieure actif actif actif actif
(facultatif)
Répertoire de Disque Estimation en Estimation en Estimation en Estimation en
journal fonction de fonction de fonction de fonction de
d'archivage l'activité des clients l'activité des clients l'activité des clients l'activité des clients
version 6.3 ou et de la fréquence et de la fréquence et de la fréquence et de la fréquence
ultérieure de sauvegarde de de sauvegarde de de sauvegarde de la de sauvegarde de
la base de données la base de données base de données la base de données
tableau 26, à la page 49 affiche un exemple de feuille de calcul complète pour une
base de données V5 de 100 Go ayant 80% d'espace utilisé, en supposant une
augmentation de la base de données de 33% à 50% lors de la mise à niveau.
Tableau 26. Estimation d'espace pour une base de données V5 de 100 Go

Base de données Disque 100 Go 100 Go 0 0
V5 : espace alloué
à la base de
données initiale
Base de données Supports à 80 Go 80 Go 80 Go 80 Go
V5 : copie de accès
sauvegarde finale séquentiel
Base de données Supports à 80 Go 0 80 Go 0
V5 : données accès
extraites séquentiel
Journal de reprise Disque 12 12 0 0
V5
Base de données Disque 106 à 120 Go 106 à 120 Go 106 à 120 Go 106 à 120 Go
V6.3 ou ultérieure
: taille estimée
Base de données Supports à 106 à 120 Go 106 à 120 Go 106 à 120 Go 106 à 120 Go
version 6.3 ou accès
ultérieure : séquentiel
première
sauvegarde
Répertoire de Disque 8 Go 8 Go 8 Go 8 Go
journal actif
version 6.3 ou
ultérieure
Copie miroir du Disque (8 Go) (8 Go) (8 Go) (8 Go)
journal actif V6.3
ou ultérieure
(facultatif)
Répertoire de Disque 80 Go 80 Go 80 Go 80 Go
journal
d'archivage
version 6.3 ou
ultérieure
Espace disque Disque 307 à 320 Go 307 à 320 Go 195 à 208 Go 195 à 208 Go
total requis pour
le processus de (315 à 328 Go) (315 à 328 Go) (203 à 216 Go) (203 à 216 Go)
mise à niveau
Totalité des Supports à 267 à 280 Go 187 à 200 Go 267 à 280 Go 187 à 200 Go
médias à accès accès
séquentiel requis séquentiel
pour le processus
de mise à niveau
Espace disque Disque 195 à 208 Go 195 à 208 Go 195 à 208 Go 195 à 208 Go
total pour le
serveur V6.3 ou (203 à 216 Go) (203 à 216 Go) (203 à 216 Go) (203 à 216 Go)
ultérieure après
mise à niveau et
nettoyage

Concepts associés:
«Espace requis pour le système du serveur version 5», à la page 44
«Espace requis pour le système du serveur version 6», à la page 45
Tâches associées:
Chapitre 3, «Présentation des scénarios de mise à niveau», à la page 85
Feuille de calcul pour l'espace de planification du serveur

V6.3 ou ultérieure
Vous pouvez utiliser la feuille de calcul pour planifier la quantité et l'emplacement
de stockage nécessaire pour le serveur V6.3 ou ultérieure.
Elément Espace requis Emplacement

Le répertoire d'instance pour le
serveur, un répertoire qui
contient des fichiers spécifiques
de cette instance de serveur
(fichier des options et autres
fichiers spécifiques du serveur)
La base de données
Journal actif
Journal d'archivage
Facultatif : copie miroir du
journal actif
Facultatif : journal d'archivage
secondaire (emplacement de
reprise pour le journal
d'archivage)
Estimation de la durée de mise à niveau

Le serveur version 5 est indisponible pendant toute la durée des opérations de
mise à niveau. Estimez la durée de la mise à niveau afin de pouvoir prévoir la
durée d'indisponibilité du serveur. Le temps nécessaire à la mise à niveau d'un
serveur version 5 dépend de plusieurs facteurs.
Les facteurs suivants peuvent affecter la durée de la mise à niveau :

v Taille de la base de données en cours de mise à niveau.
v Nombre et vitesse des processeurs du système.
v Configuration des unités de stockage. Si un nouveau matériel est introduit, il
faut du temps pour définir les nouvelles unités du serveur, pour tester la
configuration et ajuster les pools de stockage.
v Méthode de transfert des données de la base de données V5 vers la base de
données V6 (support ou réseau). Lors du transfert des données via le réseau, la
durée d'extraction et la durée d'insertion se chevauchent. La méthode par le
réseau peut permettre de réduire la durée totale de la mise à niveau grâce au
chevauchement des opérations.
v Type de charge de travail gérée par le serveur. Une charge de travail consistant
en un grand nombre de petits fichiers ou de fichiers aux noms longs peut
rallonger la durée de la mise à niveau.
v Volume de fragmentation dans la base de données version 5. Un niveau
supérieur de fragmentation entraîne un processus d'insertion de la base de
données plus efficace. La raison est la suivante : les données fragmentées sur le
système version 5 peuvent utiliser plusieurs unités d'exécution et processeurs
sur le système version 6.
Consultez les conseils de performances pour plus d'informations.
Dans les laboratoires IBM, les environnements de test de performances ont permis
d'exécuter des opérations de mise à niveau de 5 à 10 Go par heure en utilisant la
méthode via le réseau. Ce débit est calculé en fonction de la quantité d'espace de la
base de données version 5 et non en fonction de l'espace dédié à cette dernière. Les
résultats dépendent de la configuration. Le débit est plus faible si vous utilisez la
méthode via les supports, car les opérations d'extraction et d'insertion des données
s'exécutent de façon séquentielle et non simultanément.
Les résultats obtenus dans votre environnement peuvent être différents. Il est
particulièrement important de tester les opérations de mise à niveau dans votre
environnement pour les serveurs Tivoli Storage Manager qui prennent en charge
les systèmes essentiels.
Si vous estimez la durée requise pour les opérations de mise à niveau en fonction
de la quantité de données contenues dans la base de données, cette estimation sera
probablement supérieure à la réalité. La base de données est organisée selon une
structure de ramification que l'on appelle arbre, avec des enregistrements de base
de données réelles stockées aux extrémités des branches, appelées feuilles de
l'arbre. L'extraction ignore les branches et extrait uniquement les informations des
feuilles. Par conséquent, la quantité de données extraites peut être largement
inférieure à l'espace total utilisée par la base de données (la somme des feuilles et
des branches). Il est impossible de déterminer à l'avance la quantité de données à
extraire par rapport à la taille totale de la base de données. C'est la raison pour
laquelle votre estimation sera probablement supérieure à la durée réelle de
l'opération.
Exemple - Estimation de la durée de mise à niveau en

fonction de la taille de la base de données
Vous pouvez faire une estimation approximative de la durée de la mise à niveau
requise en fonction de la quantité de données contenues dans la base version 5.
Pour cette estimation, ajoutez la durée requise pour des tâches supplémentaires
telles que la configuration des unités de stockage.
1. Exécutez une commande pour obtenir des informations sur la base de données
version 5.
v Si le serveur version 5 est en cours de fonctionnement, exécutez la
commande suivante :
query db format=detailed
v Si le serveur version 5 n'est pas en cours de fonctionnement et si vous avez
installé les utilitaires de mise à niveau, exécutez l'utilitaire de mise à niveau
suivant :
dsmupgrd querydb
Exemple de résultats :

Espace disponible (Mo) : 16 384

Capacité allouée (Mo) : 16 364
Extension maximum (Mo) : 20
Réduction maximum (Mo) : 772
Taille de page (octets) : 4 096
Pages utilisables : 4 189 184
Pages utilisées : 3 214 880
Pct Util: 76.7
Pct. occupé Pct. occupé : 76,7
Volumes physiques : 8
Pages du pool de mémoires tampon : 8 192
Total des demandes de mémoire tampon : 4 510
Pct. réussite mémoire cache : 94,15
Pct. attente mémoire cache : 0,00
Sauvegarde en cours ? : Non
Type de sauvegarde en cours :
Sauvegardes incrémentales depuis la dernière intégrale : 0
Modifiés depuis la dernière sauvegarde (Mo) : 12 558,12
Pourcentage modifié : 100,00
Date/Heure de la dernière sauvegarde intégrale : 02/07/2008 02:24:16
Estimation de l’espace récupérable (Mo) :
Dernière estimation de l’espace récupérable (Mo) :
Pages disponibles pour les objets temporaires : 197 632
Pages allouées aux objets temporaires : 0
Pages utilisées pour les objets temporaires : 0
2. Utilisez les résultats de la requête pour calculer la quantité de données

contenues dans la base. Multipliez le nombre de pages utilisées par leur taille.
En utilisant les résultats de l'exemple, vous pouvez calculer la quantité de
données contenues dans cette base :
3 214 880
pages utilisées × 4 096 octets/page = 13 168 148 480 octets (ou 12,26 Go)
3. Pour estimer le temps nécessaire pour l'opération de mise à niveau, divisez la
quantité de données par le débit prévu.
Par exemple, pour un débit de 5 Go/heure et de 10 Go/heure :
12,26 Go ÷ 5 Go/heure = 2,5 heures
Conseils de performances pour le processus d'extraction

d'une base de données version 5
La vitesse du processus d'extraction est par nature limitée par le débit d'E-S vers la
destination des données.
La durée du processus dépend également de la taille de la base de données. Cette

durée sera approximativement équivalente à celle requise pour une sauvegarde
intégrale de la base de données.
Ne réorganisez pas la base de données Tivoli Storage Manager version 5 avant la

mise à niveau. La raison en est la suivante : une plus grande capacité de traitement
peut être obtenue lorsque la base de données source ne contient pas de longues
séquences de pages allouées à une table de base de données unique. Cette astuce
s'applique à la méthode de support comme à la méthode de réseau.
Les astuces suivantes en matière de performances dépendent de la méthode choisie

pour le transfert des données à partir de la base de données version 5 .
Via des supports
Si vous utilisez la méthode de support, suivez les astuces suivantes :
v Si vous extrayez les données sur bande, utilisez une unité de bande
haute vitesse.
v Si vous extrayez les données sur disque, employez une unité de disque
ou un numéro d'unité logique différent de celui utilisé pour la base de
données et le journal de reprise version 5.
v Si cette dernière et la destination des données extraites se trouvent sur
une unité de virtualisation (contrôleur de stockage haut de gamme ou
unité de virtualisation SAN), vérifiez que les deux numéros d'unités
logiques virtuelles ne sont pas installés sur la même unité de disque
physique. Assurez-vous que l'espace utilisé pour la base de données
version 5 et la destination des données extraites est situé sur des unités
de disque physiques distinctes au sein de l'unité de virtualisation.
v S'il n'est pas possible de fournir des numéros d'unité logique différents
pour la base de données version 5 et la destination de l'extraction, le
processus d'extraction sera plus lent. Cette baisse de performances peut
être acceptable selon la taille de la base de données et vos exigences de
mise à niveau.
Via un réseau
Si vous utilisez la méthode de réseau, suivez les astuces suivantes :
v Utilisez une liaison haute vitesse si vous extrayez les données vers un
système différent. Pour mettre à niveau une base de données de plus de
2 ou 3 Go, utilisez au moins un réseau Ethernet d'1 Go.
v Si vous extrayez la base de données sur le même système, aucune
connexion réseau externe n'est requise.
Conseils relatifs aux performances pour l'insertion de

données dans la base de données version 6.3 ou ultérieure
Le processus d'insertion des données de la version 5 extraites dans la base de
données version 6.3 ou ultérieure est la partie la plus longue du processus de mise
à niveau. Les performances du processus d'insertion dépende de la configuration
du système.
Il peut s'exécuter sur un système conforme aux exigences minimales requises, mais
ses performances peuvent être faibles. Pour optimiser ces dernières, configurez le
système comme indiqué dans les conseils suivants.
Processeurs
Le processus d'insertion est destiné à utiliser plusieurs processeurs ou
coeurs. Le processus d'insertion s'exécute généralement plus efficacement
sur un système doté d'un nombre relativement moins élevé de processeurs
rapides. Si le système est doté de nombreux processeurs lents, vous pouvez
atteindre des niveaux de performances réduits.
Espace de stockage sur disque
Le processus d'insertion est destiné à utiliser des sous-systèmes de
stockage sur disque à bande passante élevée. La vitesse du processus est
étroitement liée à l'espace de stockage sur disque utilisé.
Pour des performances optimales, utilisez plusieurs numéros d'unité
logique mappés vers plusieurs disques indépendants ou vers des
ensembles redondants de disques indépendants (RAID) dont la taille des
segments est élevée (128 ko, par exemple). Utilisez un système de fichiers
différent sur chaque numéro d'unité logique.
Le tableau suivant illustre le bon usage des numéros d'unité logique.

Tableau 27. Exemple d'utilisation de numéros d'unité logique

NUL Utilisation
1 Journal actif
2 Journal d'archivage
3, 4, 5 Répertoires de bases de données
6 Base de données version 5 extraite (nécessaire uniquement si
celle-ci a été extraite via des supports vers une classe d'unités de
disque à accès séquentiel)
Si l'espace de stockage sur disque est fourni par une unité de virtualisation
(contrôleur de stockage haut de gamme ou unité de virtualisation SAN),
vérifiez qu'aucun numéro d'unité logique virtuel ne figure sur la même
unité de disque physique. Assurez-vous que les répertoires utilisés sont
placés sur des unités de disque physiques différentes au sein de l'unité de
virtualisation.
Planification de la mise à niveau de plusieurs serveurs et composants

Si votre environnement inclut plusieurs serveurs et agents de stockage, évaluez la
compatibilité des versions exécutées avec un serveur version 6.3 ou ultérieure mis
à niveau. Prévoyez de mettre à niveau un premier serveur dans un environnement
de test. Echelonnez ensuite les mises à niveau des serveurs et des agents de
stockage supplémentaires.
| Composants disponibles pour l'installation

| Outre le serveur, vous pouvez installer des modules de langue, le centre des
| opérations, le centre d'administration, Tivoli Monitoring for Tivoli Storage
| Manager, et d'autres composants.
| Compatibilité avec des serveurs et des composants exécutés

à des versions antérieures
Détails sur la compatibilité des différents niveaux de serveur, de client, d'agent de
stockage, de serveur du gestionnaire de bibliothèque, des serveurs du client de
bibliothèque et des serveurs du gestionnaire de configuration qui fonctionnent
ensemble et sont disponibles à partir du site de support du produit.
Ce dernier est disponible à l'adresse suivante : http://www.ibm.com/support/

entry/portal/Overview/Software/Tivoli/Tivoli_Storage_Manager
Pour utiliser les nouvelles fonctions disponibles dans Tivoli Storage Manager V6.3
ou ultérieure, installez la dernière version du Centre d'Administration.
Planification de la mise à niveau de plusieurs serveurs sur un

seul système
La façon de mettre à niveau plusieurs serveurs fonctionnant sous un même
système dépend si ces serveurs sont censés rester sur ce système ou si vous
prévoyez de les déplacer vers un autre système. Après avoir installé le serveur
version 6.3 ou ultérieure sur un système vous ne pouvez plus exécuter de serveurs
version 5 sur ce système.
Si les serveurs mis à niveau restent sur le même système, toutes les instances de
serveur doivent être mises à niveau simultanément. Une fois que l'étape du
processus de mise à niveau consistant à installer le programme de serveur version

6.3 ou ultérieure sur le système est terminée, il n'est plus possible de démarrer un
serveur version 5 sur ce système. Chaque serveur version 5 doit être mis à niveau
séparément pour pouvoir ensuite être démarré à nouveau.
Si vous prévoyez de déplacer les serveurs vers un nouveau système dans le cadre
du processus de mise à niveau, vous pouvez mettre à niveau ces serveurs
indépendamment les uns des autres.
Vous pouvez utiliser l'assistant de mise à niveau, ou utilisez manuellement

utilitaires de mise à niveau pour mettre à niveau les serveurs :
v Si vous utilisez l'assistant de mise à niveau, lancez-le une fois pour chaque
instance du serveur.
Vous pouvez mettre à niveau plusieurs serveurs simultanément. A chaque fois
que vous lancez l'assistant de mise à niveau, celui-ci s'applique à un seul
serveur, mais vous pouvez le lancer dans plusieurs fenêtres à la fois.
v Si vous utilisez les utilitaires pour effectuer la mise à niveau manuellement à
partir d'une ligne de commande, répétez la procédure pour mettre à niveau
chaque instance du serveur.
Vous pouvez lancer l'exécution d'une instance de serveur mise à niveau alors que
la mise à niveau d'autres instances de serveur est toujours en cours.
Concepts associés:
«Comparaison de la mise à niveau sur un système existant et sur un nouveau
système», à la page 14
Planification de la mise à niveau des gestionnaires de

bibliothèque et des clients de la bibliothèque
Pour fonctionner avec un gestionnaire de bibliothèque 6.3 ou ultérieure version, les
serveurs clients bibliothèques doivent avoir le niveau de version 5.4 ou une version
ultérieure.
Si les serveurs client de bibliothèque sont à la version 5.3 ou antérieure, vous

devez mettre à niveau ces serveurs au moins vers la version 5.4 avant de mettre à
niveau le serveur gestionnaire de bibliothèque vers la version 6.3 ou ultérieure. Si
les serveurs client de bibliothèque sont à la version 5.4 ou d'une version ultérieure,
vous pouvez mettre à niveau le serveur gestionnaire de bibliothèque vers la
version 6.3 ou ultérieure, puis mettre à niveau les serveurs client de bibliothèque.
Si vous transférez un gestionnaire de bibliothèque ou des clients de bibliothèque

vers de nouveaux systèmes dans le cadre d'une mise à niveau vers la version 6.3
ou ultérieure, avant de mettre à niveau les serveurs, transférez-les vers les
nouveaux systèmes. En commençant par le transfert des serveurs, vous pouvez
rétablir la connectivité vers tous les serveurs et périphériques avant la mise à
niveau. Mettez ensuite à niveau le gestionnaire de bibliothèque, puis les clients de
bibliothèque.
Pour obtenir des informations actualisées sur les niveaux des clients de
bibliothèque pris en charge, consultez le site web suivant : http://www.ibm.com/

Planification de la mise à niveau des clients

Pour pouvoir être connectés à un serveur version 6.3 ou ultérieure, les postes client
doivent exécuter une version 5.5 ou suivante du programme client.
Planification de la mise à niveau des agents de stockage

Pour pouvoir se connecter à un serveur version 6.3 ou ultérieure, les agents de
stockage doivent au minimum avoir le niveau de version 6.1.
Si des agents de stockage ont un niveau de version antérieur, mettez-les à niveau

vers la version 6.1 dans un premier temps, puis vers la version 6.3 ou ultérieure.
Vérifiez que le transfert des données hors réseau local fonctionne comme prévu
avant de mettre à niveau le serveur.
Pour obtenir des informations actualisées sur les niveaux de version des agents de
stockage pris en charge, consultez le site website suivant : http://www.ibm.com/
Test du processus de mise à niveau pour un serveur

Testez la mise à niveau pour vous assurer que l'opération s'est bien passée. Plus
votre environnement est complexe, plus ce test est important. Il peut vous aider à
prévoir la durée d'indisponibilité du serveur suite à la mise à niveau.
Le serveur d'origine et le serveur version 6.3 ou ultérieure ne peuvent pas être

installés conjointement sur un système. Pour évaluer le serveur version 6.3 ou
ultérieure, vous pouvez installer le programme sur un nouveau système.
Pour effectuer un test avec une copie des données de production ou pour tester le
processus de mise à niveau, vous pouvez créer un serveur de test à l'aide des
utilitaires de mise à niveau. Suivez la procédure de mise à niveau normale en
tenant compte des conseils suivants :
Réduction de l'impact sur votre serveur de production
Pour éviter d'affecter votre serveur de production d'origine, vous devez
installer le serveur version 6.3 ou ultérieure sur un système différent. Des
versions différentes du serveur ne peuvent pas être exécutées
conjointement sur un système.
L'utilitaire DSMUPGRD doit être installé sur le système qui contient le serveur
d'origine ou une copie. Le module des utilitaires effectue par défaut
l'installation à un emplacement différent de celui utilisé pour un serveur
normal, de sorte que le serveur de production n'est pas affecté par
l'installation.
Important : Lorsque vous exécutez l'utilitaire DSMUPGRD PREPAREDB, ce

dernier met à niveau la version de la base de données vers un niveau de
groupe de correctifs version 5.5. Si vous ne voulez pas mettre à niveau la
base de données de votre serveur de production au niveau du groupe de
correctifs version 5.5, sauvegardez la base de données et utilisez la
sauvegarde sur un autre système pour tester la mise à niveau.
Vous pouvez extraire la base de données de production à des fins de test
en utilisant des supports ou le réseau. L'avantage de cette méthode est de
permettre le chargement répété de la base de données de test sans arrêter à
chaque fois le serveur de production.
Détection de problèmes dans la base de données

Le paramètre PREVIEW est disponible dans l'utilitaire DSMSERV INSERTDB.
Lorsque vous utilisez le paramètre PREVIEW=YES, l'opération comprend
toutes les étapes du processus, à l'exception de l'insertion de données dans
la nouvelle base de données.
Si vous prévisualisez l'opération d'insertion, vous pouvez vérifier
rapidement la lisibilité de la base de données source. Vous pouvez
également identifier les violations de contraintes de données avant
d'exécuter le processus de mise à niveau sur votre serveur. Examinez les
violations détectées lors de la prévisualisation pour éviter des retards lors
de l'exécution du processus de mise à niveau.
Protection du stockage et des données stockées
Assurez-vous que les unités de stockage de votre serveur de production ne
sont pas disponibles pour le serveur de test. Si le serveur de test peut
détecter les unités utilisées par le serveur de production, il peut lancer des
opérations telles que la soumission de réinitialisations sur les unités de
bande ou le déchargement des bandes.
Par exemple, si vos unités de bande sont connectées à un réseau de
stockage SAN il pourra être nécessaire de modifier les zones de ce dernier
pour empêcher le serveur de test de détecter les unités.
A des fins de test, vous pouvez utiliser l'une des méthodes suivantes pour créer
une copie de sauvegarde de la base de données. Ces méthodes sont fournies sous
forme hiérarchique. Pour connaître les instructions à suivre pour chaque étape, voir
les procédures détaillées.
Tâches associées:
Chapitre 9, «Procédures générales de mise à niveau d'un serveur vers la version 6.3
ou ultérieure», à la page 307
Effectuez un test en extrayant les données à partir d'une

copie distincte du serveur
Le transfert de la base de données peut s'effectuer via des supports ou via le
réseau.
1. Préparez un système de test. Il s'agit d'un système différent du serveur de
production, sur lequel vous devez installer une copie séparée du serveur
version 5.3, 5.4 ou 5.5 (la même version que votre serveur de production).
2. Sauvegardez la base de données du serveur de production.
3. Restaurez la sauvegarde de la base de données sur le système de test.
Démarrez le serveur pour vérifier que l'opération de restauration a fonctionné
correctement.
Conseil : Si vous mettez le serveur à niveau via les supports, vérifiez que la
classe d'unité est valide sur le système de test. Par exemple, si vous utilisez une
classe d'unités FILE pour l'étape d'extraction, assurez-vous que le chemin
d'accès à la classe d'unités est valide sur le système de test. Le chemin qui
figure dans la base de données du serveur pour la classe d'unités doit être
correcte. Si nécessaire, démarrez le serveur et mettez à jour le chemin.
Si vous utilisez une classe d'unité de bande pour l'étape d'extraction,

assurez-vous que les noms d'unité sont corrects pour la bibliothèque et les
unités.

4. A ce stade vous pouvez utiliser les procédures détaillées dans l'une des sections
suivantes afin d'achever le test :
Chapitre 4, «Scénario 1 : Même système, via des supports», à la page 103
Chapitre 5, «Scénario 2 : Même système, via le réseau», à la page 149
Effectuez un test en extrayant les données à partir du serveur

de production
Cet exemple de processus utilise la méthode via des supports pour transférer la
base de données vers le système de test. Suivez les étapes de la procédure pour
Chapitre 6, «Scénario 3 : Nouveau système, via des supports», à la page 193, en
effectuant simplement quelques légères modifications.
Si vous utilisez ce processus, le serveur de production sera indisponible au

minimum pendant toute la durée nécessaire à la préparation et à l'extraction de la
base de données. Cette durée est approximativement équivalente à celle requise
pour une sauvegarde intégrale de la base de données.
1. Préparez le test en sauvegardant la base de données du serveur de production.
Envisagez de créer une deuxième copie de sauvegarde de la base de données.
Pour plus d'informations, voir «Scénario 3: Préparation de la mise à niveau», à
la page 193.
2. Installez les utilitaires DSMUPGRD sur le même système que le serveur de
production. Pour plus d'informations, voir «Installation des utilitaires de mise à
niveau sur le serveur d'origine», à la page 317.
3. Préparez la base de données et extrayez les données depuis la base de données
du serveur de production vers des supports en utilisant soit les commandes,
soit l'assistant de mise à niveau. Pour plus d'informations, voir :
v «Scénario 3: Mise à niveau du serveur par le biais de l'assistant de mise à
niveau», à la page 210
a. «Scénario 3, assistant: Installation du serveur V6.3 ou d'une version
ultérieure», à la page 211
b. «Scénario 3, assistant: Création des répertoires et de l'ID utilisateur pour
l'instance de serveur mise à niveau», à la page 216
c. «Scénario 3: Démarrage de l'assistant de mise à niveau», à la page 219
Une fois l'extraction terminée, vous pouvez mettre le processus en pause
en quittant l'assistant pendant que vous terminez l'étape 4 afin de
restaurer et de redémarrer le serveur de production.
v «Scénario 3: Mise à niveau manuelle du serveur par le biais des utilitaires», à
la page 221
a. «Scénario 3: Préparation de la base de données sur un serveur version 5
en vue de la mise à niveau», à la page 222
b. «Scénario 3: Extraction des données sur des supports», à la page 223
4. Une fois les données extraites du serveur de production, reprenez les
opérations habituelles en restaurant la sauvegarde de la base de données,
effectuée à l'étape 1, sur le serveur de production. Vous pouvez ensuite
redémarrer ce dernier.
5. A ce stade, poursuivez le test en suivant les procédures détaillées pour le
scénario 3 et en utilisant le système de test comme nouveau système.
v Si vous utilisez l'assistant, redémarrez-le si nécessaire puis reprenez la
procédure à l'étape qui suit l'extraction.
v Si vous utilisez les commandes, procédez comme suit :
a. Scénario 3: Installation du serveur V6.3 ou d'une version ultérieure
b. Scénario 3: Création des répertoires et de l'ID utilisateur pour l'instance

de serveur mise à niveau
c. «Scénario 3: Création et formatage de la nouvelle base de données», à la
page 232
d. «Scénario 3: Chargement des données extraites dans la nouvelle base de
données», à la page 237
Dans le cadre du test, vous pouvez utiliser le paramètre PREVIEW=YES
dans l'utilitaire DSMSERV INSERTDB afin de tester l'opération d'insertion. Si
vous prévisualisez cette dernière, vous pouvez vérifier rapidement la
lisibilité de la base de données source. Vous pouvez également identifier
les violations de contraintes de données pouvant empêcher la mise en
production d'une base de données mise à niveau. Lorsque vous utilisez ce
paramètre, l'opération comprend toutes les étapes du processus, à
l'exception de l'insertion de données dans la nouvelle base de données.
e. «Scénario 3: Configuration du système en vue de la sauvegarde de la
base de données», à la page 240
Préparation des modifications opérationnelles

Lorsque vous mettez à niveau votre système de la version 5 sur la version 6.3 ou
ultérieure, la méthode de sauvegarde et de surveillance de la base de données du
serveur change.
Vérifiez les procédures d'exploitation, les scripts et les plannings d'administration

que vous utilisez pour les opérations du serveur :
v Planifiez régulièrement la sauvegarde de la base de données du serveur via
l'utilisation de plannings d'administration, un script de maintenance ou encore
vos propres scripts. Sauvegardez la base de données du serveur au moins une
fois par jour. Pour obtenir de meilleurs résultats, considérez les sauvegardes les
plus fréquentes pour la base de données V6.3 ou ultérieure que vous avez
exécutées avec la base de données V5. Pour s'assurer que l'espace du journal
d'archivage a été supprimé, pensez à la programmation de sauvegardes de bases
de données plus complètes et moins incrémentielles.
Consultez les informations relatives au fonctionnement des sauvegardes
automatiques de bases de données pour le serveur version 6.3 ou ultérieure.
Pour plus de détails, voir le Guide d'administration.
v Compréhension de la méthode d'utilisation de la base de données et de l'espace
du journal de restauration et du changement de contrôle.
v Vérifiez les scripts et les plannings d'administration. Le serveur version 6.3 ou
ultérieure ajoute de nouvelles commandes et en modifie et en supprime d'autres.
Ces modifications affecteront vos opérations automatisées. Pour plus
d'informations sur les commandes nouvelles et modifiées, voir «Modifications
apportées aux commandes et options», à la page 60.
v Vérifiez les commandes SELECT que vous utilisez régulièrement. Un certain
nombre de paramètres et de syntaxes précédemment autorisés ne sont pas
acceptés par le programme du gestionnaire de base de données. Pour plus
d'informations sur les mises à jour de la commande SELECT, voir «Modifications
apportées à la commande SELECT», à la page 79. Pour résoudre les problèmes liés
aux commandes SELECT, voir la note technique 1380830 (http://www.ibm.com/
support/docview.wss?uid=swg21380830).
v Si vous utilisez des produits d'éditeurs de logiciels indépendants en guise
d'interface avec le serveur, assurez-vous qu'ils sont compatibles avec le serveur

Pour utiliser les nouvelles fonctions disponibles dans Tivoli Storage Manager V6.3
ou ultérieure, installez la dernière version du Centre d'Administration.
Concepts associés:
«Protection et reprise de la base de données», à la page 6
«Journal de reprise», à la page 4
«Opérations de base de données», à la page 4
«Modifications apportées aux commandes et options»
«Modifications apportées à la commande SELECT», à la page 79
Informations de référence pour la planification

Les informations relatives aux commandes d'administration, options du serveur et
messages du serveurs qui ont été ajoutés, modifiés ou supprimés sont susceptibles
de vous aider à planifier la mise à niveau vers la version 6.3 ou ultérieure.
Modifications apportées aux commandes et options

Pour identifier les modifications apportées aux opérations nécessaires pour le
serveur, consultez la liste des commandes qui ont été ajoutées, modifiées ou
supprimées.
Nouveaux utilitaires, commandes et options du serveur

Avant de planifier une mise à niveau du serveur, vous devez avoir connaissance
des nouvelles commandes, utilitaires, et options qui ont été introduites dans la
version 6 et la version ultérieure.
«Nouvelles commandes»
«Nouveaux utilitaires», à la page 64
«Nouvelles options de serveur», à la page 64
Nouvelles commandes
Tableau 28. Nouvelles commandes
Commandes
comparables dans les
Commande Fonction versions antérieures
| AUDIT LDAPDIRECTORY Permet d'authentifier un espace de nom contrôlé par Aucun
| Tivoli Storage Manager sur un serveur Lightweight
| Directory Access Protocol (LDAP).
ANNULATION DE Annule tous les processus de réplication de noeud. Aucun
REPLICATION
| DEFINE ALERTTRIGGER Déclenche une alerte dans le Centre des Opérations Aucun
| chaque fois qu'un serveur emet un message d'erreur
| spécifié.
AIX Linux DEFINE Définit une classe d'unités pour un type d'unité de Aucun
DEVCLASS - serveur stockage. Un ensemble de types de classe d'unités
multimédia z/OS restreint est disponible pour les unités accessibles via
le serveur multimédia z/OS.
AIX Linux
DEFINE Définit une bibliothèque représentant une ressource de Aucun
LIBRARY (Définition d'un type stockage TAPE ou FILE gérée par le Tivoli Storage
de bibliothèque ZOSMEDIA) Manager for z/OS Media.
Tableau 28. Nouvelles commandes (suite)

Commandes
AIX Linux DEFINE Définit un chemin vers une bibliothèque ZOSMEDIA. Aucun
PATH (Définition d'un chemin Vous devez d'abord définir le serveur multimédia
lorsque la destination est une z/OS dans votre configuration à l'aide de la
bibliothèque ZOSMEDIA) commande DEFINE SERVER.
| DEFINE STATUSTHRESHOLD Définit un seuil de surveillance du statut. Aucun

| DELETE STATUSTHRESHOLD Supprime un seuil de surveillance du statut. Aucun
EXTEND DBSPACE Augmente l'espace de stockage que le serveur peut DEFINE DBVOLUME
utiliser pour la base de données.
EXTEND DB
Vous pouvez disposer de plusieurs emplacements pour
l'espace de stockage de la base de données. Après
avoir installer et utiliser l'utilitaire DSMSERV FORMAT ou
DSMSERV LOADFORMAT, vous pouvez augmenter les
emplacements de stockage.
IDENTIFY DUPLICATES Démarre ou arrête les processus qui identifient les Aucun
données en double dans un pool de stockage.
PERFORM LIBACTION Définit ou supprime en une fois toutes les unités et Aucun
leurs chemins pour une seule bibliothèque.
| QUERY ALERTSTATUS Affiche les informations relatives aux alertes émises Aucun
| sur le serveur Tivoli Storage Manager.
| QUERY ALERTTRIGGER Affiche les messages de serveur définis en tant Aucun
| qu'alertes.
QUERY DBSPACE Affiche les informations relatives aux répertoires QUERY DBVOLUME
utilisés par une base de données pour stocker les
données.
| QUERY MONITORSETTINGS Affiche les informations relatives aux paramètres de Aucun
| configuration pour la surveillance des alertes et le
| statut du serveur.
| QUERY MONITORSTATUS Affiche les messages de surveillance compris dans une Aucun
| période de conservation du statut défini.
QUERY PVUESTIMATE Génère une estimation d'unités client et serveur gérées Aucun
par un serveur Tivoli Storage Manager. en outre, cette
commande fournit une estimation des totaux d'unités
de valeur par processeur (PVU) pour les unités de
serveur.
QUERY REPLICATION Affiche les informations relatives aux processus de Aucun
réplication de noeud en cours d'exécution et terminés.
QUERY REPLNODE Affiche le nombre de fichiers de noeuds client stockés Aucun
sur les serveurs de réplication source et cible.
QUERY REPLRULE Affiche les informations relatives aux règles de Aucun
réplication.
QUERY SSLKEYRINGPW Affiche le mot de passe du fichier de la base de Aucun
données de clés Secure Sockets Layer (SSL).
| QUERY STATUSTHRESHOLD Affiche les informations relatives aux seuils de Aucun
| surveillance d'un statut.
REMOVE REPLNODE Supprime un noeud client de la réplication. Aucun


Commandes
REPLICATE NODE Reproduit des données dans les espaces fichier Aucun
appartenant à un ou plusieurs noeuds client ou à des
groupes définis de noeuds client.
| SET ALERTACTIVEDURATION Indique la durée d'activité d'une alerte avant qu'elle Aucun
| devienne inactive.
| SET Indique la durée pendant laquelle une alerte reste Aucun
| ALERTCLOSEDDURATION fermée avant d'être supprimée.
| SET ALERTEMAIL Active les alertes à envoyer par courrier électronique Aucun
| aux administrateurs spécifiés.
| SET ALERTEMAILFROMADDR Indique l'adresse électronique de l'expéditeur de Aucun
| l'alerte.
| SET ALERTEMAILSMTPHOST Indique le nom d'hôte du serveur de messagerie Aucun
| Simple Mail Transfer Protocol (SMTP) utilisé pour
| envoyer des alertes par courrier électronique.
| SET ALERTEMAILSMTPPORT Indique le numéro de port d'un serveur de messagerie Aucun
| SMTP utilisé pour envoyer des alertes par courrier
| électronique.
| SET Indique la durée d'inactivité d'une alerte. Aucun
| ALERTINACTIVEDURATION
| SET ALERTMONITOR Active ou désactive un moniteur d'alertes. Aucun
| SET Indique les administrateurs qui recoivent des Aucun
| ALERTSUMMARYTOADMINS récapitulatifs d'alertes horaires par courrier
| électronique.
| SET ALERTUPDATEINTERVAL Indique à quelle fréquence un moniteur d'alertes Aucun
| procède à la mise à jour et à l'élagage des alertes
| stockées dans la base de données du serveur Tivoli
| Storage Manager.
SET ARREPLRULEDEFAULT Spécifie la règle de réplication de serveur pour les Aucun
données d'archivage.
SET BKREPLRULEDEFAULT Spécifie la règle de réplication de serveur pour les Aucun
données de sauvegarde.
SET CPUINFOREFRESH Indique le nombre de jours entre des analyses de poste Aucun
de travail utilisées pour les estimations de PVU.
SET DBRECOVERY Définit la classe d'unités à utiliser pour la sauvegarde DEFINE
de la base de données du serveur. Le gestionnaire de DBBACKUPTRIGGER
base de données utilise la classe d'unités pour les
sauvegardes automatiques de la base de données.
SET DBREPORTMODE Définit la quantité d'informations diagnostics signalée Aucun
pour une base de données.
SET Vérifie les extensions envoyées au serveur pendant le Aucun
DEDUPVERIFICATIONLEVEL dédoublonnage de données côté client.
| SET Définit la méthode d'authentification du mot de passe Aucun
| DEFAULTAUTHENTICATION par défaut pour les noeuds et les administrateurs.
SET Définit les pools de données actives qui sont inclus Aucun
DRMACTIVEDATASTGPOOL dans vos procédures et plans de reprise.

Commandes
| SET LDAPPASSWORD Définit un mot de passe pour un nom d'utilisateur ou Aucun
| un ID que vous indiquez à l'aide de la commande SET
| LDAPUSER.
| SET LDAPUSER Indique l'ID d'un utilisateur ou d'un compte pouvant Aucun
| effectuer des opérations d'administration lorsque
| l'utilisateur ou le compte accède à un serveur de
| répertoire LDAP.
| SET Définit un groupe de serveurs qui est surveillé pour Aucun
| MONITOREDSERVERGROUP des alertes et le statut.
| SET MONITORINGADMIN Définit le nom de l'administrateur de surveillance Aucun
| utilisé pour se connecter aux serveurs du groupe de
| serveurs surveillés.
SET REPLRETENTION Indique la période de conservation des enregistrements Aucun
de réplication de poste client dans la base de données
du serveur de réplication source.
SET REPLSERVER Définit le nom du serveur de réplication cible. Aucun
SET SPREPLRULEDEFAULT Définit la règle de réplication de serveur pour les Aucun.
données de gestion de l'espace.
SET SSLKEYRINGPW Fournit le mot de passe du fichier de la base de Aucun
données de clés au serveur.
| SET STATUSMONITOR Active ou désactive la surveillance du sttut. Aucun
| SET Indique le nombre de minutes entre les requêtes du Aucun
| STATUSREFRESHINTERVAL serveur. Les requêtes sont utilisées pour la surveillance
| du statut.
| UPDATE ALERTTRIGGER Met à jour les attributs d'un ou de plusieurs Aucun
| déclencheurs d'alertes.
| UPDATE ALERTSTATUS Met à jour le statut d'une alerte signalée. Aucun
AIX Linux UPDATE Met à jour une classe d'unités. Un ensemble de types Aucun
DEVCLASS - serveur de classe d'unités restreint est disponible pour les
multimédia z/OS unités accessibles via un serveur multimédia z/OS.
UPDATE FILESPACE Met à jour les règles de réplication pour les espaces Aucun
fichier.
AIX Linux UPDATE Met à jour un chemin vers une bibliothèque Aucun
PATH (Mise à jour d'un chemin ZOSMEDIA.
lorsque la destination est une
bibliothèque ZOSMEDIA)
UPDATE REPLRULE Active ou désactive une règle de réplication. Aucun
| UPDATE STATUSTHRESHOLD Met à jour un seuil pour la surveillance du statut. Aucun
VALIDATE REPLICATION Identifie les règles de réplication qui s'appliquent aux Aucun
espaces fichier dans les postes client qui sont
configurés pour la réplication.
z/OS ZMSPREPARE Analyse le serveur version 5 et génère un rapport Aucun

décrivant les étapes à exécuter avant le début de la
migration des données.

Nouveaux utilitaires
Tableau 29. Nouveaux utilitaires
Commandes
DSMSERV DISPLAY DBSPACE Utilitaire hors connexion permettant d'afficher les DSMSERV DISPLAY
emplacements actuels de l'espace de stockage de la DBVOLUMES
base de données.
DSMSERV DISPLAY LOG Utilitaire hors connexion permettant d'afficher des DSMSERV DISPLAY
informations sur les journaux de reprise, y compris les LOGVOLUMES
journaux actifs et les journaux d'archivage.
DSMSERV INSERTDB Utilitaire hors ligne utilisé uniquement pour l'insersion Aucun
de données extraites de la base de données du serveur
version 5 dans une base de données version vide6.3 ou
ultérieure.
DSMSERV REMOVEDB Utilitaire hors ligne utilisé uniquement lorsque vous Aucun
êtes certain de n'avoir plus besoin d'une base de
données du serveur et des journaux de reprise. A
utiliser avec précaution.
DSMUPGRD EXTEND DB Utilitaire hors ligne utilisé uniquement sur un serveur Aucun
version 5 pour étendre la base de données lorsque
l'espace de base de données est insuffisant pour mener
à bien le processus de mise à niveau.
DSMUPGRD EXTEND LOG Utilitaire hors ligne utilisé uniquement sur un serveur Aucun
version 5 pour étendre le journal de reprise lorsque
l'espace de celui-ci est insuffisant pour mener à bien le
processus de mise à niveau.
DSMUPGRD EXTRACTDB Utilitaire hors ligne utilisé uniquement sur un serveur Aucun
version 5 pour extraire les données de la base de
données. Les données extraites sont insérées dans une
base de données version 6.3 ou ultérieure à l'aide de
l'utilitaire DSMSERV INSERTDB.
DSMUPGRD PREPAREDB Utilitaire hors ligne utilisé uniquement sur un serveur Aucun
version 5 pour préparer la base de données à
l'extraction. Une fois que celui-ci a été exécuté, les
données peuvent être extraites de la base de données à
l'aide de l'utilitaire DSMUPGRD EXTRACTDB.
DSMUPGRD QUERYDB Utilitaire hors ligne utilisé uniquement sur un serveur Aucun
version 5 pour afficher les informations relatives à la
base de données et au journal de reprise.
Nouvelles options de serveur

Tableau 30. Nouvelles options de serveur. Dans le cas de certaines options, les modifications ne sont pas effectives
tant que le serveur n'a pas été redémarré.
Commandes ou
options comparables
dans les versions
Nouvelle option de serveur Fonction antérieures
ACTIVELOGDIRECTORY Nom du répertoire dans lequel tous les journaux actifs DEFINE
sont stockés. LOGVOLUME
Tableau 30. Nouvelles options de serveur (suite). Dans le cas de certaines options, les modifications ne sont pas
effectives tant que le serveur n'a pas été redémarré.
Commandes ou
options comparables
dans les versions
ACTIVELOGSIZE Taille maximale du journal actif. EXTEND LOG
REDUCE LOG
ALLOWREORGINDEX Indique si la réorganisation d'index lancée par le Aucun
serveur est activée.
ALLOWREORGTABLE Indique si la réorganisation de tableau lancée par le Aucun

serveur est activée.
ARCHFAILOVERLOGDIRECTORY Répertoire dans lequel le serveur stocke les fichiers de Aucun

journaux d'archivage s'ils ne peuvent pas être stockés
à l'emplacement du journal d'archivage.
ARCHLOGDIRECTORY Répertoire dans lequel le serveur enregistre le journal Aucun
d'archivage.
CLIENTDEDUPTXNLIMIT Taille maximale d'une transaction lorsque les données Aucun
dédoublonnées du côté client sont sauvegardées ou
archivées.
DBDIAGPATHFSTHRESHOLD Indique le seuil d'espace disponible sur le système de Aucun
fichiers ou le disque qui contient le fichier
db2diag.log. Lorsque le volume d'espace disponible
est inférieur ou égal au seuil spécifié, le message
d'erreur ANR1545W s'affiche.
DBMEMPERCENT Limite pour le pourcentage de mémoire système Aucun
utilisée pour la base de données.
DBMTCPPORT Numéro de port sur lequel le gestionnaire de Aucun
communications TCP/IP du gestionnaire de base de
données doit attendre les demandes de sessions client.
DEDUPTIER2FILESIZE Spécifie à quelle taille de fichier Tivoli Storage Aucun
Manager commence à utiliser le dédoublonnage des
données Tier 2.
DEDUPTIER3FILESIZE Spécifie à quelle taille de fichier Tivoli Storage Aucun
Manager commence à utiliser le dédoublonnage des
données Tier 3.
ENABLENASDEDUP Indique si un serveur dédoublonne les données Aucun
stockées par un serveur de fichier de stockage en
réseau (NAS). Cette option s'applique uniquement aux
serveurs de fichier NetApp.
| FFDCLOGNAME Nom du journal de capture de données à la première Aucun
| défaillance (FFDC).
| FFDCMAXLOGSIZE Taille du journal FFDC. Aucun
| LDAPCACHEDURATION Durant pendant laquelle le serveur Tivoli Storage Aucun
| Manager cache des informations d'authentification du
| mot de passe LDAP.
| LDAPURL Emplacement d'un serveur de répertoire LDAP. Aucun

Tableau 30. Nouvelles options de serveur (suite). Dans le cas de certaines options, les modifications ne sont pas
effectives tant que le serveur n'a pas été redémarré.
Commandes ou
options comparables
dans les versions
MIRRORLOGDIRECTORY Répertoire dans lequel est stockée la copie miroir du DEFINE LOGCOPY
journal actif.
| NDMPENABLEKEEPALIVE Indique si le serveur active la fonction de signal de Aucun
| présence Transmission Control Protocol (TCP) sur le
| protocole de gestion de données en réseau (NDMP)
| pour les unités NAS.
| NDMPKEEPIDLEMINUTES Délai, en minutes, avant que le système d'exploitation Aucun
| ne transmette le premier paquet de signal de présence
| sur une connexion de contrôle NDMP.
REORGBEGINTIME Première fois où le serveur Tivoli Storage Manager Aucun
peut démarrer une réorganisation de table ou d'index.
REORGDURATION Intervalle durant lequel une réorganisation de table ou Aucun
d'index lancée par le serveur peut démarrer.
AIX Linux Solaris Temps de réponse autorisé pour les adaptateurs de Aucun
bus hôte lorsqu'ils sont interrogés par le processus de
Windows
reconnaissance du réseau de stockage (SAN).
SANDISCOVERYTIMEOUT
SERVERDEDUPTXNLIMIT Taille maximale des objets pouvant être dédoublonnés Aucun
sur un serveur.
SSLFIPSMODE Indique si le mode Federal Information Processing Aucun
Standards (FIPS) est effectif pour SSL.
SSLTLS12 Controls Transport Layer Security (TLS) 1.2, un Aucun
protocole SSL disponible pour un usage avec Tivoli
Storage Manager version6.3 ou ultérieure. TLS 1.2 peut
uniquement être utilisé avec les clients version 6.3 ou
ultérieure.
Modifications des options, utilitaires et commandes de serveur

Faites attention aux commandes, aux fonctionnalités et aux options mises à jour
sur V6 et sur des versions ultérieures.
«Commandes mises à jour», à la page 67
«Utilitaires mis à jour», à la page 74
«Options de serveur mises à jour», à la page 74
Commandes mises à jour

Tableau 31. Commandes mises à jour
Commande Modifications
Sauvegarder Base de documents Vous devez exécuter la commande SET
DBRECOVERY avant la commande Sauvegarder
base de données. Lors de l'exécution de la
commande SET DBRECOVERY, vous définissez
la classe d'unités pour la sauvegarde de base
de données.
Une sauvegarde incrémentielle de base de

données est une sauvegarde de toutes les
modifications effectuées depuis la dernière
sauvegarde complète. Dans les versions
antérieures du serveur, une sauvegarde
incrémentale consistait à sauvegarder toutes
les modifications effectuées depuis la
dernière sauvegarde intégrale ou
incrémentale.
Les nouveaux paramètres sont disponibles :

v Le paramètre DEDUPDEVICE identifie les
unités de stockage qui prennent en charge
le dédoublonnage de données et optimise
les images de sauvegarde enregistrées sur
ces unités.
v Le paramètre NUMSTREAMS indique le
nombre de flux de transfert de données
parallèles qui sont utilisées pour la
sauvegarde de base de données.
| BACKUP NODE Les commandes comprennent la valeur
| QUERY NASBACKUP SNAPMIRROR pour le paramètre TYPE :
| RESTORE NODE v Lorsque vous indiquez la valeur
| SNAPMIRROR pour la commande BACKUP
| NODE, le système de fichiers est copié vers
| un pool de stockage à l'aide de NetApp
| SnapMirror pour la fonction Bande
| magnétique.
| v Lorsque vous indiquez la valeur
| SNAPMIRROR pour la commande QUERY
| NASBACKUP, la sortie indique les
| informations sur les images NetApp
| SnapMirror.
| v Lorsque vous indiquez la valeur
| SNAPMIRROR pour la commande RESTORE
| NODE, le système de fichiers est extrait
| d'une image NetApp SnapMirror.
| BACKUP STGPOOL Les commandes peuvent être utilisées avec
| DEFINE STGPOOL les fonctions de dédoublonnage de données.
QUERY STGPOOL
UPDATE STGPOOL

Tableau 31. Commandes mises à jour (suite)

BACKUP VOLHISTORY Les opérations de vidage de mémoire de la
DELETE VOLHISTORY base de données ne sont plus possibles. Par
QUERY VOLHISTORY conséquent, les volumes de vidage de
UPDATE VOLHISTORY mémoire de la base de données ne
s'affichent dans l'historique des volumes.
AIX Linux z/OS Si vous

déplacez un serveur V5 fonctionnant sur un
système d'exploitation z/OS vers un serveur
V6.3 ou ultérieure sur un système
d'exploitation AIX or Linux, vous pouvez
exécuter la commande DELETE VOLHISTORY
sur le serveur V5 pour préparer la
migration. La commande indique la classe
d'unités des volumes à supprimer.
| DEFINE DEVCLASS Lorsque vous exécutez les commandes
| UPDATE DEFINE DEVCLASS ou UPDATE DEVCLASS pour
| DEVCLASS indiquer une classe d'unités 3592 ou LTO,
| vous pouvez utiliser le paramètreLBPROTECT.
| Le paramètre LBPROTECT indique si la
| protection de bloc logique est utilisée pour
| assurer l'intégrité des données sur la bande
| magnétique.
AIX Linux z/OS Un

ensemble de types de classe d'unités
restreint est disponible pour les unités
accessibles via un serveur multimédia z/OS.
DEFINE LIBRARY AIX Linux Vous pouvez utiliser
la commande DEFINE LIBRARY pour définir
un type de bibliothèque ZOSMEDIA. Dans
ce cas, vous pouvez définir une bibliothèque
représentant une bande magnétique ou une
source de stockage de FICHIER qui est
conservée par Tivoli Storage Manager for
z/OS Media.
DEFINE LIBRARY Vous pouvez utiliser la commande DEFINE
UPDATE LIBRARY LIBRARY pour définir une bibliothèque
virtuelle de bande magnétique (VTL) vers le
serveur Tivoli Storage Manager. Vous
pouvez utiliser la commande UPDATE
LIBRARY pour mettre à jour une définition
VTL.
AIX Linux Vous pouvez utiliser la commande DEFINE

DEFINE PATH PATH pour définir un chemin d'accès à une
bibliothèque ZOSMEDIA.
DEFINE SERVER Vous pouvez utiliser la commande DEFINE
SERVER pour définir un serveur pour les
fonctions suivantes : transfert de données
hors réseau local, réplication des postes et
transfert de données à l'aide de serveur
multimédia z/OS.

DEFINE SPACETRIGGER Les commandes peuvent être uniquement
DELETE SPACETRIGGER utilisées pour les pools de stockage. Les
QUERY SPACETRIGGER déclencheur d'extension de capacité ne sont
UPDATE SPACETRIGGER plus disponibles pour les bases de données
et journaux.
DEFINE VOLUME La capacité maximale d'un volume dans un
pool de stockage de type DISK est de 8
téraoctets.
DISABLE SESSIONS Le paramètre DIRECTION indique s'il faut
ENABLE SESSIONS désactiver ou activer les sessions entrantes,
sortantes ou les deux.
| EXPIRE INVENTORY Le traitement du processus d'expiration peut
| être exécuté pour les noeuds et groupes de
| noeuds spécifiques ou pour tous les noeuds
| dans un domaine de règles. Les types de
| données à examiner au niveau de
| l'expiration peuvent être spécifiés.
| Les valeurs pour le paramètre DURATION sont

| modifiées. Vous pouvez spécifier une valeur
| dans la plage 1 à 999999 pour définir le
| nombre maximal de minutes pour le
| processus d'expiration.
GRANT La classe de privilège d'analyse ANALYST est
AUTHORITY supprimée.
REVOKE AUTHORITY
HALT Le paramètre QUIESCE a été supprimé.
| LOCK ADMIN Le paramètre AUTHENTICATION indique la
| méthode d'authentification que l'utilisateur
| utilise pour se connecter.
| LOCK NODE Le paramètre AUTHENTICATION indique la
| méthode authentification par mot de passe
| requise pour se connecter à un noeud.
| MOVE DRMEDIA Les modifications apportées aux commandes
| PREPARE du gestionnaire de reprise permettre
| QUERY DRMEDIA d'inclure les pools de données actives dans
| QUERY DRMSTATUS les plans et procédures de reprise après
| incident.
| La commande MOVE DRMEDIA peut être

| utilisée simultanément avec la commande
| BACKUP STGPOOL. Vérifiez que le processus de
| pool de stockage principal est terminé avant
| de sauvegarder la base de données. Vérifiez
| que la commande BACKUP STGPOOL et la
| commande BACKUP DB sont terminées avant
| d'exécuter la commande MOVE DRMEDIA.
QUERY DB La sortie indique le nombre total de pages
libres dans les espaces de table.
AIX Linux Vous pouvez utiliser cette commande pour

QUERY DEVCLASS afficher les informations spécifiques au
QUERY LIBRARY serveur multimédia z/OS.
QUERY PATH


QUERY FILESPACE Vous pouvez utiliser cette commande pour
afficher les informations de réplication.
| QUERY LOG Vous pouvez utiliser cette commande pour
| afficher les informations sur les répertoires
| actifs, de journaux miroir miroir, de reprise
| d'archive et de journaux archivés.
| QUERY NODE Vous pouvez utiliser cette commande pour
| afficher les informations sur la méthode
| d'authentification par mot de passe ainsi que
| sur les paramètres de sécurité pour l'ID
| administrateur.
| QUERY OPTION Les options obsolètes sont supprimées de la
| sortie. La sortie est mise à jour pour inclure
| des informations sur les paramètres des
| serveurs de l'annuaire LDAP.
QUERY PROCESS Vous pouvez utilisez cette commande pour
obtenir des informations sur les processus
d'identification dupliquée pour obtenir des
informations sur la manière de dupliquer les
processus d'identification.
QUERY SERVER Vous pouvez utiliser cette commande pour
trouver si la communication de la couche
Secure Sockets Layer (SSL) est utilisée.
QUERY SESSION Vous pouvez utiliser cette commande pour
afficher les actions qui se produisent
pendant la session.
| QUERY STATUS Les options obsolètes et le déclencheur des
| sauvegardes de la base de données sont
| supprimées.
| Vous pouvez utiliser cette commande pour

| vérifier si les mots de passe sont authentifiés
| avec le serveurTivoli Storage Manager ou
| avec le serveur de l'annuaire LDAP.
| Vous pouvez également afficher le nom qui

| est spécifié pour le serveur de réplication
| cible par défaut.
| QUERY VOLHISTORY Pour le paramètre TYPE, entrez les valeurs
| RPFile et RPFSnapshot sont ajoutées. Avec
| l'aide des valeurs, vous pouvez afficher les
| enregistrements contenant des informations
| sur les objets du fichier de plan de reprise.
| QUERY VOLUME Vous pouvez utiliser cette commande pour
| vérifier si la protection de bloc logique est
| activée.

| REGISTER ADMIN Les nouveaux paramètres sont disponibles :
| v Le paramètre ALERT indique si les alertes
| sont envoyées à l'adresse de courrier
| électronique de l'administrateur.
| v Le paramètre AUTHENTICATION indique si la
| méthode d'identification pour l'ID
| administrateur.
| v Le paramètre SSLREQUIRED indique si l'ID
| utilisateur de l'administrateur doit utiliser
| la couche SSL pour communiquer avec le
| client de sauvegarde-archivage à partir du
| serveur Tivoli Storage Manager.
| REGISTER ADMIN Dans ces commandes, le paramètre ALERT
| QUERY ADMIN indique si les alertes sont envoyées à
| UPDATE ADMIN l'adresse de courrier électronique de
| l'administrateur.
| Dans la commande QUERY ADMIN, la sortie est

| mise à jour pour inclure les informations sur
| les alertes e-mail, la méthode
| d'authentification par mot de passe ainsi que
| les paramètres de sécurité pour l'ID
| administrateur.
REGISTER LICENSE Vous êtes invité à utiliser cette commande
pour enregistrer les licences pour les
composants du serveur. L'utilisation de la
commande REGISTER LICENSE implique que
vous soyez d'accord et que vous acceptiez
les conditions de licence qui sont spécifiées
dans le contrat de licence.
| REGISTER NODE Les nouveaux paramètres sont disponibles :
| v Le paramètre AUTHENTICATION indique la
| méthode d'authentification par mot de
| passe pour le noeud.
| v Le paramètre BACKUPINITIATION indique si
| l'ID utilisateur non superutilisateur du
| noeud client peut sauvegarder les fichiers
| sur le serveur.
| v Les paramètres The BKREPLRULEDEFAULT,
| ARREPLRULEDEFAULT, and
| SPREPLRULEDEFAULT indiquent la règle de
| réplication qui s'applique au type de
| données lorsque les règles d'espace du
| fichier sont définies à DEFAULT.
| v Le paramètre REPLSTATE indique si les
| données appartenant au noeud client sont
| prêtes pour la réplication.
| v Le paramètre ROLEOVERRIDE indique s'il
| faut substituer le rôle du rapport du client
| pour une estimation PVU.
| v Le paramètre SSLREQUIRED indique si le
| noeud doit utiliser la couche SSL pour
| communiquer avec le serveur Tivoli
| Storage Manager.


| REMOVE ADMIN Vous pouvez utiliser le paramètre
| SYNCLDAPDELETE pour supprimer un ID
| administrateur enregistré sur un serveur
| d'annuaire LDAP.
| REMOVE NODE Vous pouvez utiliser le paramètre
| SYNCLDAPDELETE pour supprimer un
| identificateur de noeud enregistré sur un
| serveur d'annuaire LDAP.
| RENAME ADMIN Vous pouvez utiliser le paramètre
| SYNCLDAPDELETE pour renommer un ID
| administrateur authentifiant vers un serveur
| d'annuaire LDAP.
| RENAME NODE Vous pouvez utiliser le paramètre
| SYNCLDAPDELETE pour renommer un
| identificateur de noeud enregistré sur un
| serveur d'annuaire LDAP.
| SELECT Les mises à jour suivantes s'appliquent à la
| commande SELECT :
| v Dans les versions précédentes sur le
| serveur, la syntaxe qui ne se conformait
| pas aux règles de syntaxe SQL pouvaient
| être utilisées dans la commande SELECT.
| Dans V6.3 et dans une version ultérieure,
| vous devez utiliser la syntaxe SQL qui est
| conforme aux règles de syntaxe du
| gestionnaire de base de données, DB2.
| v Vous pouvez utiliser l'analyse SELECT *
| FROM PVUESTIMATE_DETAILS pour générer
| un rapport fournissant des informations
| détaillées au niveau du noeud.
| v Vous pouvez utiliser la commande SELECT
| pour répertorier les identifiants de mots
| de passe pour les administrateurs et
| noeuds qui authentifient avec un serveur
| d'annuaire LDAP.
| v Vous pouvez utiliser la commande pour
| vérifier SELECT pour vérifier si la
| protection de bloc logique est activée pour
| la classe ou le volume d'une unité.
SET DBRECOVERY Le paramètre NUMSTREAMS indique le nombre
de flux de transfert de données simultanées
à utiliser pendant la sauvegarde de votre
base de données.
| SETOPT Les options obsolètes sont supprimées.
| L'option LDAPCACHEDURATION détermine le
| temps pendant lequel le serveur Tivoli
| Storage Manager cache des informations sur
| l'authentification par mot de passe LDAP.
| UNLOCK ADMIN Le paramètre AUTHENTICATION indique la
| méthode d'authentification par mot de passe
| requise pour la connexion d'un
| administrateur.

| UNLOCK NODE Le paramètre AUTHENTICATION indique la
| méthode pour authentification par mot de
| passe de noeud.
| UPDATE ADMIN La classe de privilège d'analyse ANALYST est
| supprimée. Les nouveaux paramètres sont
| disponibles :
| méthode d'authentification de mot de
| passe utilisée pour l'ID administrateur.
| v Le paramètre SSLREQUIRED indique si l'ID
| utilisateur de l'administrateur doit utiliser
| la couche SSL pour communiquer avec le
| client de sauvegarde-archivage à partir du
| serveur Tivoli Storage Manager.
| v Le paramètre SYNCLDAPDELETE est utilisé
| pour la suppression d'un ID
| administrateur depuis un serveur
| d'annuaire LDAP.
| UPDATE NODE La classe de privilège d'analyse ANALYST est
| supprimée. Les nouveaux paramètres sont
| disponibles :
| méthode d'authentification de mot de
| passe.
| v Le paramètre SSLREQUIRED indique si un
| noeud doit utiliser la couche SSL pour
| communiquer avec le serveur Tivoli
| Storage Manager.
| v Le paramètre SYNCLDAPDELETE est utilisé
| pour modifier la méthode
| d'authentification pour un noeud depuis
| l'authentification avec le serveur
| d'annuaire LDAP jusqu'à celle du serveur
| Tivoli Storage Manager.
UPDATE LIBRARY Vous pouvez utiliser cette commande pour
mettre à jour une définition de bibliothèque
pour un VTL.
UPDATE NODE Les nouveaux paramètres sont disponibles :
v Le paramètre BACKUPINITIATION indique si
l'ID utilisateur non superutilisateur du
noeud client peut sauvegarder les fichiers
sur le serveur.
v Le paramètre ROLEOVERRIDE indique s'il
faut substituer le rôle du rapport du client
pour une estimation PVU.
AIX Linux UPDATE PATH Vous pouvez utiliser cette commande pour
la mise à jour vers une bibliothèque
ZOSMEDIA.
UPDATE SERVER Vous pouvez utiliser cette commande pour
indiquer s'il faut utiliser la couche SSL
pendant les communications de serveur à
serveur.

Utilitaires mis à jour

Tableau 32. Utilitaires mis à jour
Utilitaire Modifications
DSMSERV Vous pouvez indiquer l'ID utilisateur
propriétaire de l'instance de serveur au
démarrage. Vous pouvez également spécifier
l'ID utilisateur pour les autres fonctionnalités
DSMSERV.
DSMSERV FORMAT Les paramètres obsolètes sont supprimés.
Les nouveaux paramètres sont disponibles
pour spécifier les répertoires pour l'espace
de base de données ainsi que la taille
maximale et les emplacements du journal de
reprise.
DSMSERV INSERTDB Le paramètre CONFIGINFO indique les
informations de configuration d'unité
utilisées par la fonctionnalité DSMSERV
INSERTDB pour le chargement d'une base de
données.
DSMSERV RESTORE DB L'historique des volumes est obligatoire
pour la restauration d'une base de données.
Toutes les opérations utilisent la

récupération aval.
La fonction pour la restauration de volumes

de base de données individuelle est
supprimée. Le serveur ne gère plus les
volumes de la base de données.
AIX Linux Le paramètre MEDIASERVER est utilisé

DSMUPGRD EXTRACTDB pendant une mise à niveau depuis un
DSMUPGRD PREPAREDB serveur V5 sur z/OS. Le paramètre indique
le nom du serveur à utiliser en tant que
serveur multimédia z/OS.
Options de serveur mises à jour

Tableau 33. Options de serveur mises à jour
Option Modifications
CHECKTAPEPOS You can use the CHECKTAPEPOS option to
enable append-only mode for IBM LTO
Generation 5 and later drives, and for any
drives that support this feature.
AIX Linux Solaris L'option SANDISCOVERY a changé dans Tivoli

Storage Manager version 5.5.3 et dans les
éditions ultérieures. Pour s'assurer du bon
Windows SANDISCOVERY fonctionnement du système, vérifiez le
paramètre de l'option SANDISCOVERY.
Tableau 33. Options de serveur mises à jour (suite)

Option Modifications
TXNGROUPMAX La valeur par défaut passe de 256 à 4096.
Vérifiez si le fichier d'options du serveur
contient cette option :
v Si le fichier d'options du serveur ne
contient pas cette option, le serveur utilise
automatiquement la nouvelle valeur par
défaut.
v Si le fichier d'options du serveur inclut
une valeur pour l'option, le serveur utilise
la valeur spécifiée. Si la valeur indiquée
est inférieure à 4096, augmentez cette
valeur ou supprimez l'option afin que le
serveur utilise la nouvelle valeur par
défaut. En améliorant la valeur ou en
utilisant la nouvelle valeur par défaut,
vous pouvez améliorer la performance
pour les opérations de déplacement de
données telles que la migration de pool de
stockage et la sauvegarde de pool de
stockage.
L'amélioration de la valeur pour l'option

TXNGROUPMAX n'a aucun effet sur la
performance de transfert de données pour
les fichiers qui étaient enregistrés sur le
serveur à l'aide d'une valeur moindre pour
l'option.
Commandes, utilitaires et options de serveur supprimés

Certaines commandes, options et certains utilitaires sont supprimés car ils ne sont
plus utiles. Dans certains cas, de nouvelles commandes remplacent les commandes
supprimées.
«Commandes supprimées»
«Utilitaires supprimés», à la page 77
«Options de serveur supprimées», à la page 78
Commandes supprimées
Tableau 34. Commandes supprimées
Commandes supprimées Commentaires
CONVERT ARCHIVE L'opération ayant été exécutée par cette
commande n'est plus utile.
DEFINE DBBACKUPTRIGGER Veillez à planifier des sauvegardes de la
DELETE DBBACKUPTRIGGER base de données pour qu'elles se déroulent
QUERY DBBACKUPTRIGGER au moins une fois par jour.
UPDATE DBBACKUPTRIGGER
DEFINE DBCOPY Les volumes de base de données ne sont
plus utilisés.
DEFINE DBVOLUME L'attribution d'espace s'effectue
QUERY DBVOLUME automatiquement dans les emplacements de
répertoire spécifiés pour la base de données.

Tableau 34. Commandes supprimées (suite)

DEFINE LOGCOPY Au lieu des copies de volume de journal,
vous pouvez spécifier une copie miroir du
journal afin que le journal actif soit protégé
par une copie miroir.
DEFINE LOGVOLUME Le gestionnaire de base de données
DELETE LOGVOLUME administre automatiquement l'espace dans
QUERY les répertoires du journal de reprise.
LOGVOLUME
Pour obtenir des informations sur les
répertoires utilisés pour les journaux, utilisez
la commande QUERY LOG.
ESTIMATE DBREORGSTATS La collecte et la redéfinition des statistiques
de base de données s'effectuent
automatiquement.
Les opérations de réorganisation de la base

de données sont faites automatiquement par
le gestionnaire de la base de données selon
les besoins.
EXTEND DB L'attribution d'espace s'effectue
automatiquement dans les emplacements de
Si le serveur a besoin d'un espace
supplémentaire, vous pouvez ajouter des
emplacements de répertoire en utilisant la
commande EXTEND DBSPACE.
EXTEND LOG Des options de serveur sont disponibles
pour augmenter la taille des journaux de
reprise.
QUERY SQLSESSION Les informations fournies par cette
commande ne se trouvent plus dans la base
de données du serveur. Les paramètres SQL
SELECT sont remplacés par les options de
syntaxe disponibles dans une commande
DB2 SELECT.
REDUCE DB L'attribution d'espace s'effectue
Vous ne pouvez pas ajuster la capacité
affectée de la base de données.
REDUCE LOG Le gestionnaire de base de données
administre automatiquement l'espace dans
les répertoires du journal de reprise.
RESET BUFPOOL L'ption BUFPOOLSIZE ayant été éliminée; cette
commande n'est pas nécessaire.
RESET La collecte et la redéfinition des statistiques
DBMAXUTILIZATION de base de données s'effectuent
RESET LOGCONSUMPTION automatiquement.
RESET LOGMAXUTILIZATION
SET LOGMODE La fonction de consignation de la base de
données s'exécute toujours en mode de
récupération aval.
Tableau 34. Commandes supprimées (suite)

SET SQLDATETIMEFORMAT Les commandes sont remplacées par des
SET SQLDISPLAYMODE options dans la syntaxe de commande DB2
SET SQLMATHMODE SELECT.
UNDO ARCHCONVERSION L'opération ayant été exécutée par cette
UPDATE ARCHIVE L'opération ayant été exécutée par cette
Utilitaires supprimés
Tableau 35. Utilitaires supprimés
Utilitaire supprimé Commentaires
DSMFMT L'attribution d'espace s'effectue
DSMSERV AUDITDB Les audits de base de données hors
connexion ne sont plus requis.
Au fur et à mesure que les données sont

ajoutées à la base de données du serveur, le
gestionnaire de base de données vérifie
automatiquement les contraintes de données
et les types de données. Les contrôles
d'intégrité en ligne évitent la survenue des
incidents qui nécessitaient l'exécution
d'audits hors connexion dans les versions
antérieures.
DSMSERV DISPLAY DBBACKUPVOLUME Des informations sur les volumes utilisés
pour la sauvegarde de la base de données
sont disponibles depuis le fichier historique
des volumes. Ce dernier est désormais
obligatoire pour restaurer la base de
données.
DSMSERV DISPLAY DBVOLUMES La commande DSMSERV DISPLAY DBSPACE
permet d'afficher des informations sur
l'espace de base de données lorsque le
serveur n'est pas en cours d'exécution.
DSMSERV DISPLAY LOGVOLUMES DSMSERV DISPLAY LOG permet d'afficher les
informations relatives aux journaux de
reprise, y compris le journal actif, la copie
miroir du journal actif, le répertoire de
reprise pour le journal d'archivage et
l'emplacement de dépassement de capacité
des journaux.
DSMSERV DUMPDB L'opération ayant été exécutée par cet
utilitaire n'est plus utile.

Tableau 35. Utilitaires supprimés (suite)

Utilitaire supprimé Commentaires
DSMSERV EXTEND LOG Cet utilitaire est remplacé par les options de
serveur suivantes :
ACTIVELOGSIZE
ACTIVELOGDIRECTORY
MIRRORLOGDIRECTORY
Ces options permettent d'augmenter l'espace
du journal de reprise si ce dernier est saturé
lorsque le serveur est arrêté.
DSMSERV LOADDB L'opération ayant été exécutée par cet
DSMSERV RESTORE DB Le serveur n'effectue pas le suivi de volumes
v Permet de restaurer un volume de base de de base de données individuels dans la
données unique à son état le plus récent version 6.3 ou ultérieure.
v Permet de restaurer une base de données Le fichier historique des volumes est requis
à un point dans le temps lorsqu'aucun pour l'exécution d'opérations de restauration
fichier historique des volumes n'est de base de données.
disponible
DSMSERV UNLOADDB L'opération ayant été exécutée par cet
Options de serveur supprimées
lorsque vous démarrez le serveur, vous pouvez recevoir des messages

d'avertissement sur les options du serveur non prises en charge, mais qui
n'apparaissent pas dans la liste des options supprimées. Si la version 5 tolérait la
présence de certaines options du serveur non prises en charge par le serveur, la
version 6.3 ou ultérieure les notifie en affichant des avertissements. Vous pouvez
soit ignorer l'erreur, soit mettre à jour le fichier des options du serveur et
redémarrer le serveur.
Tableau 36. Options de serveur supprimées
Option supprimée Commentaires
BUFPOOLSIZE Le serveur ajuste dynamiquement la valeur
de taille du pool de mémoire tampon.
DBPAGESHADOW L'option n'est plus nécessaire.
DBPAGESHADOWFILE L'option n'est plus nécessaire.
LOGPOOLSIZE Le serveur utilise son propre pool de
mémoire tampon du journal de reprise de
taille fixe.
LOGWARNFULLPERCENT L'option n'est plus nécessaire.
MIRRORREAD La mise en miroir du journal actif est prise
MIRRORWRITE en charge, mais pas celle de la base de
données. Protégez la disponibilité de la base
de données en la plaçant sur des unités
présentant des caractéristiques de haute
disponibilité.
SELFTUNEBUFPOOLSIZE Le serveur ajuste dynamiquement la taille
du pool de mémoire tampon.
Modifications apportées à la commande SELECT

Dans les versions précédentes du serveur, la commande SELECT acceptait une
syntaxe qui n'était pas toujours conforme aux règles de syntaxe SQL. Avec la
version 6.3 ou ultérieure, le serveur respecte les règles de syntaxe SQL utilisées par
son gestionnaire de base de données, le programme DB2. Des exemples illustrent
les modifications que vous pouvez être amené à apporter aux instructions SELECT
que vous utilisez.
«Prédicat LIKE d'une instruction SELECT imbriquée»
«Instructions SELECT pour le calcul de l'heure»
«Colonnes index_keyseq et index_order»
«Accès aux objets de la base de données à l'aide de la commande SELECT», à la
page 80
«Extraction d'informations de plusieurs tables de base de données», à la page
80
«Résultats de la commande SELECT pour la classe d'unités DISK», à la page 80
«Espaces en trop dans la sortie», à la page 80
«Types de données pour opérations arithmétiques», à la page 81
Prédicat LIKE d'une instruction SELECT imbriquée
Vous ne pouvez pas utiliser le prédicat LIKE pour une instruction SELECT
imbriquée. Par exemple, si vous recevez une erreur lorsque vous utilisez le
prédicat LIKE comme dans l'instruction suivante :
select * from volumeusage where volume_name like (select distinct volume_name
from volumeusage where node_name=’node1’)
Remplacez cette syntaxe par le paramètre in, comme dans cette instruction :
select * from volumeusage where volume_name in (select distinct
volume_name
from volumeusage where node_name=’node1’)
Instructions SELECT pour le calcul de l'heure
La durée qualifiée ne peut pas être comparée dans une instruction SELECT. Par
exemple, l'instruction suivante entraîne une erreur SQL :
select * from actlog where (current_time-date_time) seconds <= 60 seconds
Les instructions suivantes sont des exemples de syntaxe correcte.
Pour lister les entrées du journal d'activité pendant les 60 dernières secondes,
utilisez :
select * from actlog where
TIMESTAMPDIFF(2,CHAR(current_timestamp-date_time)) <= 60
Pour lister les entrées du journal d'activité pendant les 60 dernières minutes,
utilisez :
select * from actlog where
TIMESTAMPDIFF(4,CHAR(current_timestamp-date_time)) <= 60
Colonnes index_keyseq et index_order
Les tables du catalogue système SYSCAT.COLUMNS et SYSCAT.TABLES sont

désormais traitées par le gestionnaire de base de données et non pas directement
par le serveur Tivoli Storage Manager. Les colonnes INDEX_KEYSEQ et INDEX_ORDER

ne sont pas disponibles. Utilisez à leur place la colonne KEYSEQ. Pour plus
d'informations, entrez la chaîne de recherche keyseq dans le centre de
documentation suivant : http://pic.dhe.ibm.com/infocenter/db2luw/v9r7.
Accès aux objets de la base de données à l'aide de la commande

SELECT
Les objets de la base de données auxquels il est possible d'accéder via la

commande SELECT sont les mêmes que dans les versions antérieures du serveur,
avec l'ajout de nouvelles fonctions dans la version 6.3 ou ultérieure.
Toutefois, les tables de catalogue SYSCAT.COLUMNS et SYSCAT.TABLES incluent

désormais tous les objets de la base de données connus du serveur, y compris les
objets auxquels il n'est pas possible d'accéder à l'aide de la commande SELECT.
Vous recevrez un message d'erreur si une commande SELECT inclut une tentative
d'accès à l'un de ces objets.
Extraction d'informations de plusieurs tables de base de données
Pour extraire des informations de plusieurs tables, utilisez un processus de

jonction. De nombreux types de processus de jonction peuvent être utilisés.
Par exemple, la commande suivante qui était utilisée avec des versions antérieures
du serveur ne fonctionne plus :
select entity,activity,sum(bytes),sum(end_time-start_time),sum(affected),sum(failed),sum(mediaw)
from summary where entity in (select node_name from nodes) and
cast((current_timestamp-start_time)hours as decimal)<24 group by entity,activity
Vous pouvez déclarer des noms de colonnes qui sont extraites de plusieurs tables
afin qu'une instruction conditionnelle puisse être exécutée avec les résultats voulus
à partir de la commande SELECT. Par exemple :
select entity,activity,sum(bytes),sum(end_time-start_time),sum(affected),sum(failed),sum(mediaw)
from summary su, nodes nd where su.entity=nd.node_name and
cast((current_timestamp-start_time)hours as decimal)<24 group by entity,activity
Résultats de la commande SELECT pour la classe d'unités DISK
Quand vous utilisez la commande SELECT pour obtenir des informations de la table
DEVCLASSES pour la classe d'unités DISK, la version 6.1 fournit des résultats
sensiblement différents de ceux des versions précédentes.
Dans les versions précédentes, le champ SHARED était vide (nul) pour la classe
d'unités DISK. Dans la version V6.3, le champ SHARED contient la valeur NO. Le
champ SHARED ne s'applique pas à la classe d'unités DISK et la valeur NO peut être
ignorée.
Espaces en trop dans la sortie
Il se peut que des espaces apparaissent dans la sortie là où il n'y en avait pas
auparavant. Si des espaces de fin apparaissent dans la sortie, comme dans
l'exemple de sortie tabschema suivant, vous pouvez utiliser la fonction scalaire
RTRIM pour les supprimer.
dsmadmc -errorlogn=errorlog -id=admin -pa=admin -comma -dataonly=y
’select tabschema,tabname from tables’
SYSCAT ,ATTRIBUTES
SYSCAT ,AUDITPOLICIES
SYSCAT ,AUDITUSE
Par exemple, si vous écrivez des scripts d'automatisation et devez supprimer les
espaces supplémentaires vous pouvez utiliser la fonction scalaire RTRIM :
select
rtrim(tabschema) as tabschema, tabname from syscat.tables
Types de données pour opérations arithmétiques
Les modifications de la gestion des types de données utilisés dans les opérations
arithmétiques peut nécessiter la modification des commandes SELECT utilisées dans
les versions précédentes du serveur.
Par exemple, l'instruction SUM figurant dans la commande suivante provoque une
erreur de dépassement arithmétique :
select nom_noeud,sum(capacity)
as capacity,
sum(capacity * (pct_util/100)) as used from filespaces group by
nom_noeud
Pour que cette commande soit compatible avec la version 6.3 ou ultérieure, ajoutez
la fonction CAST pour convertir les éléments de l'instruction SUM en données
décimales :
select nom_noeud,sum(capacity)
as capacity,
sum(cast(capacity as decimal) * cast((pct_util/100) as decimal)) as used from
filespaces group by nom_noeud
Messages du serveur ajoutés ou modifiés

Si des scripts ou autres dispositifs automatisés utilisent les messages du serveur,
consultez la liste des messages ajoutés, modifiés ou supprimés afin d'identifier les
éléments que vous pouvez être amené à modifier.
La liste est disponible dans le centre de documentation : http://pic.dhe.ibm.com/

infocenter/tsminfo/v6r3
Elle est également disponible dans la publication Tivoli Storage ManagerMessages de

serveur et codes d'erreur pour la version 6.3 ou ultérieure.
Valeurs recommandées pour la dénomination d'un serveur

Utilisez ces descriptions comme référence lorsque vous installez ou mettez à
niveau un serveur Tivoli Storage Manager.
ID utilisateur d'instance
L'ID utilisateur d'instance constitue la base des autres noms associés à l'instance de
serveur. L'Id utilisateur d'instance est également appelé le propriétaire de
l'instance.
Par exemple : tsminst1
L'ID utilisateur d'instance est l'ID utilisateur qui doit être propriétaire de ou
disposer de droits de lecture/écriture sur tous les répertoires que vous créez pour
la base de données et le journal de reprise. La méthode standard d'exécution du
serveur consiste à utiliser l'ID utilisateur d'instance. Cet ID utilisateur doit
également disposer des droits d'accès en lecture/écriture sur les répertoires utilisés
pour les classes d'unités FILE.


Répertoire de base de l'ID utilisateur d'instance
Si ce n'est déjà fait, le répertoire de base peut être créé lors de la création
de l'ID utilisateur d'instance à l'aide de l'option (-m). En fonction des
paramètres locaux, le répertoire de base peut avoir le format :
/home/id_utilisateur_instance
Par exemple : /home/tsminst1
Le répertoire de base est initialement utilisé pour contenir le profil de l'ID
utilisateur et les paramètres de sécurité.
Nom d'instance de base de données

Le nom d'instance de base de données doit être identique à l'ID utilisateur
d'instance sous lequel vous exécutez l'instance de serveur.
Par exemple : tsminst1
Windows
Le nom d'instance de base de données est le nom de l'instance de serveur
tel qu'il apparaît dans le registre.
Par exemple : Server1
Répertoire d'instance
Le répertoire d'instance est un répertoire qui contient des fichiers spécifiques à une
instance de serveur (le fichier d'options du serveur et d'autres fichiers spécifiques
au serveur). Vous pouvez lui donner le nom de votre choix. Pour faciliter
l'identification, utilisez un nom qui lie le répertoire au nom d'instance.
Vous pouvez créer le répertoire d'instance comme sous-répertoire du
répertoire de base pour l'ID utilisateur d'instance. Par exemple :
/home/ID_utilisateur_instance/ID_utilisateur_instance
Dans l'exemple suivant, le répertoire d'instance est placé dans le répertoire
de base pour l'ID utilisateur tsminst1 : /home/tsminst1/tsminst1
Vous pouvez également créer le répertoire ans un autre emplacement, par
exemple : /tsmserver/tsminst1
Le répertoire d'instance contient les fichiers suivants de l'instance de
serveur :
v Le fichier d'options du serveur, dsmserv.opt
v Le fichier de base de données de clés du serveur, cert.kdb, et les fichiers
.arm (utilisés par des clients et d'autres serveurs pour importer les
certificats Secure Sockets Layer du serveur)
v Le fichier de configuration des unités, si l'option de serveur DEVCONFIG
ne spécifie pas de nom complet
v Le fichier de l'historique des volumes, si l'option de serveur
VOLUMEHISTORY ne spécifie pas de nom complet
v Les volumes des pools de stockage DEVTYPE=FILE, si le répertoire de
la classe d'unités n'est pas intégralement spécifié ou qu'il n'est pas
complet.
v Les exits utilisateur
v La sortie de trace (si nom non complet)

Windows
Vous pouvez utiliser un nom incluant le nom de l'instance du serveur tel
qu'il apparaît (ou apparaîtra) dans le registre. Les noms d'instance de
serveur par défaut se présentent sous la forme Serverx.
Par exemple : d:\tsm\server1
Le répertoire d'instance contient les fichiers suivants de l'instance de
serveur :
v Le fichier d'options du serveur, dsmserv.opt
v Le fichier de base de données de clés du serveur, cert.kdb, et les fichiers
.arm (utilisés par des clients et d'autres serveurs pour importer les
certificats Secure Sockets Layer du serveur)
v Le fichier de configuration des unités, si l'option de serveur DEVCONFIG
ne spécifie pas de nom complet
v Le fichier de l'historique des volumes, si l'option de serveur
v Les volumes des pools de stockage DEVTYPE=FILE, si le répertoire de
la classe d'unités n'est pas intégralement spécifié ou qu'il n'est pas
complet.
v Les exits utilisateur
v La sortie de trace (si nom non complet)
Nom de base de données
Le nom de base de données est toujours TSMDB1 pour chaque instance de serveur.
Ce nom ne peut pas être modifié.
Nom de serveur
Le nom de serveur est un nom interne pour Tivoli Storage Manager utilisé pour les
opérations impliquant des communications entre plusieurs serveurs Tivoli Storage
Manager. Les exemples illustrent des communications entre serveurs et le partage
de bibliothèques.
AIX Linux Solaris Windows Le nom de serveur est également utilisé

pour ajouter le serveur au centre d'administration afin qu'il puisse être géré par
cette interface. Utilisez un nom unique pour chaque serveur. Pour faciliter
l'identification dans le centre d'administration (ou à partir d'une commande QUERY
SERVER), utilisez un nom qui reflète l'emplacement ou la fonction du serveur.
| AIX Linux Le nom de serveur est également utilisé pour

Windows
| ajouter le serveur au Centre d'opérations afin qu'il puisse être géré par cette
| interface. Utilisez un nom unique pour chaque serveur. Pour faciliter
| l'identification dans le Centre d'opérations (ou à partir d'une commande QUERY
| SERVER), utilisez un nom qui reflète l'emplacement ou la fonction du serveur.
HPUX Utilisez un nom unique pour chaque serveur. Pour faciliter

l'identification à partir d'une commande QUERY SERVER, utilisez un nom qui reflète
l'emplacement ou la fonction du serveur.
Si vous utilisez l'assistant, le nom par défaut suggéré est le nom d'hôte du système
que vous utilisez. Vous pouvez utiliser un nom différent qui soit significatif dans

votre environnement. Si votre système comporte plusieurs serveurs et si vous avez

recours à l'assistant, vous pouvez utiliser le nom par défaut pour un seul des
serveurs. Vous devez entrer un nom unique pour chaque serveur.
Par exemple :
PAYROLL
SALES
Windows
TUCSON_SERVER1
TUCSON_SERVER2
Pour plus d'informations sur les names du serveur, voir le manuelGuide

d'administration.
Répertoires pour l'espace de base de données et le journal de

reprise
Les répertoires peuvent être nommés en respectant les valeurs recommandées

locales. Pour une identification plus facile, utilisez des noms qui associent les
répertoires à l'instance de serveur.
Par exemple, pour le journal d'archivage :

AIX HPUX Linux Solaris /tsminst1_archlog
Windows f:\server1\archlog
Chapitre 3. Présentation des scénarios de mise à niveau
Vous pouvez mettre à niveau le IBM Tivoli Storage Manager serveur sur le même
système ou sur un nouveau. Vous pouvez utiliser une méthode de support ou de
réseau pour le transfert des données de la base de données du serveur d'origine
vers la base de données du serveur mis à niveau. Les descriptions des scénarios
illustrent l'ordre des étapes pour les différentes approches.
Sélectionnez le scénario qui vous intéresse dans la table suivante. Les scénarios
présentés dans cette section récapitulent les étapes requises dans chaque situation.
Pour exécuter cette procédure, suivez le lien vers les procédures détaillées fourni
dans la présentation du scénario.
Tableau 37. Liens vers les présentations de scénario
Emplacement du serveur Méthode de transfert des
Scénario mis à niveau données
«Scénario 1 : Mise à niveau Même système que le Via des supports
du serveur sur un même serveur d'origine
système via des supports»
«Scénario 2 : Mise à niveau Même système que le Via un réseau
du serveur sur un même serveur d'origine
système par le réseau», à la
page 90
«Scénario 3 : Mise à niveau Nouveau système Via des supports
du serveur sur un nouveau
système via des supports», à
la page 94
«Scénario 4 : Mise à niveau Nouveau système Via un réseau
du serveur sur un nouveau
système via le réseau», à la
page 98
Concepts associés:
«Comparaison des méthodes de transfert des données vers la base de données
version 6.3 ou ultérieure», à la page 17
Scénario 1 : Mise à niveau du serveur sur un même système via des

supports
Dans ce scénario, toutes les tâches de mise à niveau sont exécutées sur le même
système. La base de données est extraite sur des supports et insérée ultérieurement
dans la base de données version 6.3 ou ultérieure.
Vous pouvez utiliser l'assistant ou effectuer la mise à niveau manuelle du serveur à

l'aide des utilitaires. L'assistant offre une approche guidée de la mise à niveau d'un
serveur. Le recours à l'assistant permet d'éviter des étapes de configuration qui
s'avèrent complexes lorsqu'elles sont effectuées manuellement.

Concepts associés:
Tâches associées:
Chapitre 4, «Scénario 1 : Même système, via des supports», à la page 103
Mise à niveau du serveur par le biais de l'assistant
Mise à niveau vers la version 6 sur le même système, via des supports
Upgrade using the upgrade wizard
Tâches de la base de
données version 5
Tâches de préparation. Sauvegardez la base
données version 6 1. de données version 5.
2. Installez les utilitaires DSMUPGRD.
3. Préparez la base de données versions V5.

Exécutez l'utilitaire DSMUPGRD
PREPAREDB.
4. Désinstallez le code de serveur version 5.
5. Installez le code du serveur version 6.
6. Créez les répertoires et l'ID utilisateur

pour le serveur version 6.
Serveur Tivoli
Storage Manager
Version 5
Démarrez l'assistant de mise à niveau.

7. Utilisez l'assistant pour configurer le
serveur version 6 et mettre à niveau la
base de données version 5.
Exécutez les étapes postérieures à

8. l'installation.
Figure 1. Scénario 1
Les étapes suivantes constituent un résumé de la procédure correspondant à ce

scénario. Si ce scénario correspond à votre environnement, voir les détails de la
procédure : Chapitre 4, «Scénario 1 : Même système, via des supports», à la page
103.
1. Exécutez toutes les tâches de préparation qui incluent l'exécution d'une
Chapitre 3. Présentation des scénarios de mise à niveau 87

2. Installez le module des utilitaires de mise à niveau (DSMUPGRD) sur le système.

Celui-ci doit être installé que vous utilisiez l'assistant de mise à niveau ou les
utilitaires pour effectuer la mise à niveau.
3. Préparez la base de données version 5 à l'aide de l'utilitaire DSMUPGRD
PREPAREDB.
4. Désinstallez le code de serveur version 5. Facultatif : avant d'installer la version
6.3 ou ultérieure, exécutez le vérificateur de prérequis d'installation.
5. Installez le code du serveur version 6.3 ou ultérieure sur le système.
6. Créez les répertoires pour la base de données et les journaux version 6.3 ou
ultérieure, ainsi que l'ID utilisateur auquel appartiendra l'instance de serveur.
7. Démarrez l'assistant de mise à niveau pour configurer le nouveau serveur et
mettre à niveau la base de données version 5. Cet assistant permet d'exécuter
les tâches suivantes :
a. Extraction de la base de données version 5 vers un support externe.
b. Création et formatage d'une base de données vide pour la réception de
données
c. Insertion des données depuis les supports à partir desquels elles ont été
extraites
d. Configurez le système pour la sauvegarde de la base de données.
8. Effectuez les tâches consécutives à l'installation, y compris la sauvegarde de la
base de données et la vérification de son contenu.
Mise à niveau manuelle du serveur par le biais des utilitaires
b. Création et formatage d'une base de données vide pour la réception de
données
c. Insertion des données depuis les supports à partir desquels elles ont été
extraites
d. Configurez le système pour la sauvegarde de la base de données.
Effectuez la mise à niveau à l'aide de la ligne de commande et les utilitaires de
mise à niveau.
Tâches de la base de Tâches de la base de
données version 5 données version 6
1. Tâches de préparation. 7. Extrayez la base de données version

5 vers des supports externes.
Sauvegardez la base de
données version 5.
EXTRACTDB.
2. Installez
DSMUPGRD.
les utilitaires
8. Créez et formatez une base de
données V6 vide. Exécutez db2icrt et
l'utilitaire DSMSERV LOADFORMAT.
3. Préparez la base de données

versions V5. Exécutez
l'utilitaire DSMUPGRD
PREPAREDB.
Insérez les données depuis les
9. supports dans la nouvelle base de
données. Exécutez l'utilitaire
4. Désinstallez le code de
serveur version 5. DSMSERV INSERTDB.
5. Installez
version 6.
le code du serveur
10. Configurez le système pour une
88 sauvegarde
IBM Tivoli Storage Manager : Guide de mise à niveau et de migration de baseV5
des serveurs de données.
6. Créez les répertoires et l'ID

utilisateur pour le serveur
version 6. 11. Exécutez les étapes postérieures à
l'installation.
Serveur Tivoli
Storage Manager
Version 5

procédure : Chapitre 4, «Scénario 1 : Même système, via des supports», à la page
103.


PREPAREDB.
4. Désinstallez le code de serveur version 5. Facultatif : avant d'installer la
version 6.3 ou ultérieure, exécutez le vérificateur de prérequis d'installation.
7. Extrayez la base de données version 5 vers des supports externes à l'aide de
l'utilitaire DSMUPGRD EXTRACTDB.
8. Créez et formatez une base de données vide pour la réception de données. La
base de données est créée à l'aide de la commande db2icrt. La base de
données est formatée à l'aide de l'utilitaire DSMSERV LOADFORMAT.
9. Insérez les données depuis les supports à partir desquels elles ont été
extraites. Vous devez disposer du fichier manifeste qui a été créé dans le cadre
du processus d'extraction. Aidez-vous de l'utilitaire DSMSERV INSERTDB.
10. Configurez le système pour la sauvegarde de la base de données.
Scénario 2 : Mise à niveau du serveur sur un même système par le

réseau
Dans ce scénario, toutes les tâches de mise à niveau sont exécutées sur le même
système. Les données sont extraites de la base de données du serveur d'origine et
insérées simultanément dans la nouvelle base de données du serveur.

Concepts associés:
Tâches associées:
Chapitre 5, «Scénario 2 : Même système, via le réseau», à la page 149
Concepts associés:
Tâches associées:
Chapitre
Mise 5, «Scénario
à niveau 2 : Même
du serveur de lasystème,
versionvia5 lesur
réseau», à la page
la version 6.3149
ou ultérieure

Upgrade using the upgrade wizard
données version 5
90 Tâches
IBM Tivolide la base
Storage de:
Manager Guide de mise à niveau et dedemigration
Tâches des serveurs
préparation. V5 la base
Sauvegardez
données version 6 1. de données version 5.
2. Installez les utilitaires DSMUPGRD.

PREPAREDB.
4. Désinstallez le code de serveur version 5.

Serveur Tivoli
Storage Manager
Version 5
Démarrez l'assistant de mise à niveau.

7. Utilisez l'assistant pour configurer le
serveur version 6 et mettre à niveau la
Exécutez les étapes postérieures à

8. l'installation.

procédure : Chapitre 5, «Scénario 2 : Même système, via le réseau», à la page 149.


PREPAREDB.
4. Désinstallez le code de serveur version 5. Facultatif : avant d'installer la version
6.3 ou ultérieure, exécutez le vérificateur de prérequis d'installation.
a. Création et formatage d'une base de données vide pour la réception de
données
b. Transférez les données de la base de données version 5 vers la base de
données version 6.3 ou ultérieure.
c. Configurez le système pour la sauvegarde de la base de données.
Mise à niveau vers la version 6 sur le même système, via le réseau

Effectuez la mise à niveau à l'aide de la ligne de commande et les
utilitaires de mise à niveau.
Tâches de la base de Tâches de la base de
données version 5 données version 6
1. Tâches de préparation. 7. Créez et formatez une base de données

V6 vide. Exécutez db2icrt et l'utilitaire
Sauvegardez la base de
données version 5. DSMSERV LOADFORMAT.
Installez les utilitaires

2. DSMUPGRD. Lancez l'insertion pour le nouveau
8. serveur. Exécutez l'utilitaire DSMSERV
INSERTDB.
3. Préparez la base de données

versions V5. Exécutez
l'utilitaire DSMUPGRD
PREPAREDB.
Lancez le processus d'extraction.
9. Exécutez l'utilitaire DSMUPGRD
Désinstallez le code de EXTRACTDB.
4. serveur version 5.
5. Installez le code du serveur 10. Configurez le système pour une

sauvegarde de base de données.
version 6.
Créez les répertoires et l'ID

6. utilisateur pour le serveur 11. Exécutez les étapes postérieures à
version 6. l'installation.
Serveur Tivoli
Storage Manager
Version 5

procédure : Chapitre 5, «Scénario 2 : Même système, via le réseau», à la page 149.


PREPAREDB.
4. Désinstallez le code de serveur version 5. Facultatif : avant d'installer la
version 6.3 ou ultérieure, exécutez le vérificateur de prérequis d'installation.
7. Créez et formatez une base de données vide pour la réception de données. La
base de données est créée à l'aide de la commande db2icrt. La base de
données est formatée à l'aide de l'utilitaire DSMSERV LOADFORMAT.
8. Démarrez le processus d'insertion pour le nouveau serveur à l'aide de
l'utilitaire DSMSERV INSERTDB.
9. Lancez le processus d'extraction à partir de la base de données version 5 en
faisant appel à l'utilitaire DSMUPGRD EXTRACTDB.
Scénario 3 : Mise à niveau du serveur sur un nouveau système via des

supports
Dans ce scénario, certaines tâches de mise à niveau sont exécutées sur le système
d'origine et d'autres sur le nouveau système. La base de données est extraite sur
des supports et insérée ultérieurement dans la base de données version 6.3 ou
ultérieure.

Concepts associés:
Tâches associées:
Chapitre 6, «Scénario 3 : Nouveau système, via des supports», à la page 193
Mise à niveau vers la version 6 sur un nouveau système,

via des supports
Mise à niveau à l'aide de l'assistant de mise à niveau
Installez le code du serveur

3. version 6.

utilisateur pour le serveur version 6.
1. Tâches de préparation.
Sauvegardez la base de données
version 5.
Démarrez l'assistant de mise à

5. niveau. Utilisez l'assistant pour
configurer le serveur version 6
2. Installez les utilitaires DSMUPGRD
et mettre à niveau la base de
données version 5.
Effectuez les étapes postérieures à

6. l'installation.
Serveur Tivoli Serveur Tivoli

Storage Manager Storage Manager
Version 5 Version 6

procédure : Chapitre 6, «Scénario 3 : Nouveau système, via des supports», à la
page 193.
1. Exécutez toutes les tâches de préparation sur le système d'origine. La
préparation inclut l'exécution d'une sauvegarde de la base de données.
2. Installez le module des utilitairesDSMUPGRD sur le système d'origine. Celui-ci doit
être installé que vous utilisiez l'assistant de mise à niveau ou que vous
procédiez manuellement à la mise à niveau du serveur à l'aide des utilitaires.

3. Installez le code du serveur version 6.3 ou ultérieure sur le nouveau système.

Facultatif : avant d'installer le code de serveur version 6.3 ou ultérieure,
exécutez le vérificateur de prérequis d'installation.
a. Préparation de la base de données version 5 sur le système d'origine
b. Extraction de la base de données version 5 du système d'origine vers des
supports externes
c. Création et formatage d'une base de données vide sur le nouveau système
pour la réception de données.
d. Insertion de données sur le nouveau système depuis les supports à partir
desquels elles ont été extraites
e. Configuration du nouveau système pour la sauvegarde de la base de
données

via des supports
Effectuez la mise à niveau à l'aide de la ligne de commande et les utilitaires
1. Tâches de préparation. Sauvegardez 5. Installez le code du serveur version 6.

la base de données version 5.

2. Installez les utilitaires DSMUPGRD sur

le système version 5.
Préparez la base de données versions

7. Créez et formatez une base de données
vide. Exécutez db2icrt et l'utilitaire
3. V5. Exécutez l'utilitaire DSMUPGRD DSMSERV LOADFORMAT.
PREPAREDB.
4. Extrayez la base de données version 5 8. Insérez les données depuis les supports
dans la nouvelle base de données.
vers des supports externes. Exécutez Exécutez l'utilitaire DSMSERV INSERTDB.
9. Configurez le système pour une sauvegarde

de base de données.
10. Exécutez les étapes postérieures à

l'installation.

Version 5 Version 6


procédure : Chapitre 6, «Scénario 3 : Nouveau système, via des supports», à la
page 193.
2. Installez le module des utilitairesDSMUPGRD sur le système d'origine. Celui-ci
doit être installé que vous utilisiez l'assistant de mise à niveau ou que vous
3. Sur le système d'origine, préparez la base de données version 5 à l'aide de
l'utilitaire DSMUPGRD PREPAREDB.
4. Sur le système d'origine, extrayez la base de données version 5 vers des
supports externes à l'aide de l'utilitaire DSMUPGRD EXTRACTDB.
7. Sur le nouveau système, créez et formatez une base de données vide pour la
réception des données. La base de données est créée à l'aide de la commande
db2icrt. La base de données est formatée à l'aide de l'utilitaire DSMSERV
LOADFORMAT.
8. Sur le nouveau système, insérez les données depuis les supports à partir
desquels elles ont été extraites. Vous devez disposer du fichier manifeste qui a
été créé dans le cadre du processus d'extraction. Aidez-vous de l'utilitaire
DSMSERV INSERTDB.
Scénario 4 : Mise à niveau du serveur sur un nouveau système via le

réseau
Dans ce scénario, certaines tâches de mise à niveau sont exécutées sur le système
d'origine et d'autres sur le nouveau système. Les données sont extraites de la base
de données du serveur d'origine et transmises via la connexion réseau afin d'être
insérées dans la base de données du nouveau serveur.

Concepts associés:
Tâches associées:
Chapitre 7, «Scénario 4 : Nouveau système, via le réseau», à la page 245

via des supports
Mise à niveau à l'aide de l'assistant de mise à niveau
Installez le code du serveur

3. version 6.

utilisateur pour le serveur version 6.
1. Tâches de préparation.
Sauvegardez la base de données
version 5.

configurer le serveur version 6
2. Installez les utilitaires DSMUPGRD
et mettre à niveau la base de
données version 5.
Effectuez les étapes postérieures à

6. l'installation.

Version 5 Version 6


procédure : Chapitre 7, «Scénario 4 : Nouveau système, via le réseau», à la page
245.
2. Installez le module des utilitairesDSMUPGRD sur le système d'origine. Celui-ci doit
être installé que vous utilisiez l'assistant de mise à niveau ou que vous
a. Préparation de la base de données version 5 sur le système d'origine
b. Création et formatage d'une base de données vide sur le nouveau système
pour la réception de données.
c. Transférez les données de la base de données version 5 vers la base de
données version 6.3 ou ultérieure.
d. Configuration du nouveau système pour la sauvegarde de la base de
données

via le réseau
Effectuez la mise à niveau à l'aide de la ligne de commande et les
utilitaires de mise à niveau.

1. Tâches de préparation. Sauvegardez la
2. Installez les utilitaires DSMUPGRD sur le

système version 5.
6.
5. Créez et formatez une base de données
vide. Exécutez db2icrt et l'utilitaire
DSMSERV LOADFORMAT.
3. Préparez la base de données versions

V5. Exécutez l'utilitaire DSMUPGRD
PREPAREDB.
7. Lancez l'insertion pour le nouveau

serveur. Exécutez l'utilitaire DSMSERV
INSERTDB.
8. Lancez le processus d'extraction. Exécutez

9. Configurez le système pour une sauvegarde
10. Exécutez les étapes postérieures à

l'installation.

Version 5 Version 6


procédure : Chapitre 7, «Scénario 4 : Nouveau système, via le réseau», à la page
245.
2. Installez le module des utilitairesDSMUPGRD sur le système d'origine. Celui-ci
doit être installé que vous utilisiez l'assistant de mise à niveau ou que vous
3. Sur le système d'origine, préparez la base de données version 5 à l'aide de
l'utilitaire DSMUPGRD PREPAREDB.
6. Sur le nouveau système, créez et formatez une base de données vide pour la
réception des données. La base de données est créée à l'aide de la commande
db2icrt. La base de données est formatée à l'aide de l'utilitaire DSMSERV
LOADFORMAT.
7. Sur le nouveau système, lancez le processus d'insertion pour le nouveau
serveur. Aidez-vous de l'utilitaire DSMSERV INSERTDB.
8. Sur le système d'origine, lancez le processus d'extraction pour la base de
données version 5 à l'aide de l'utilitaire DSMUPGRD EXTRACTDB.
Chapitre 4. Scénario 1 : Même système, via des supports
Utilisez cette procédure si vous mettez à niveau le IBM Tivoli Storage Manager
serveur sur le même système que celui de votre serveur V5, et si vous utilisez la
méthode de support pour le transfert de données.
La procédure de mise à niveau du serveur comprend les tâches suivantes :

1. «Scénario 1: Préparation de la mise à niveau»
2. «Scénario 1 : Installation des utilitaires de mise à niveau», à la page 113
3. «Scénario 1: Préparation de la base de données sur un serveur version 5 en vue
de la mise à niveau», à la page 120
4. «Scénario 1: Désinstallation du programme version 5 avant l'installation de V6.3
ou d'une version ultérieure », à la page 122
5. «Scénario 1: Installation du serveur V6.3 ou d'une version ultérieure», à la page
124
6. «Scénario 1: Création des répertoires et de l'ID utilisateur pour l'instance de
serveur mise à niveau», à la page 129
7. Mise à niveau du serveur à l'aide de l'une des méthodes suivantes :
la page 135
8. Les tâches suivantes sont exécutées après la mise à niveau :
a. «Vérification de l'accès aux pools de stockage sur disque», à la page 355
b. «Configuration des services Solaris pour l'instance de serveur», à la page
356
c. «Configuration des options de serveur pour la maintenance de la base de
données serveur», à la page 356
d. «Démarrage de l'instance du serveur après la mise à niveau», à la page 357
e. «Enregistrement des licences», à la page 362
f. «Sauvegarde de la base de données après la mise à niveau du serveur», à la
page 363
g. «Vérification du serveur mis à niveau», à la page 364
h. «Changement du nom d'hôte pour le serveur Tivoli Storage Manager», à la
page 364
i. «Mise à jour de l'automatisation», à la page 366
j. «Surveillance du serveur mis à niveau», à la page 367
k. «Suppression de GSKit version 7 après la mise à niveau sur Tivoli Storage
Manager version 6.3 ou ultérieure», à la page 368
Scénario 1: Préparation de la mise à niveau

Préparez la mise à niveau en effectuant les actions suivantes : vérification de la
configuration requise, préparation de l'espace requis, sauvegarde du serveur et
modification de certains paramètres de serveur.
Suivez soigneusement les étapes de préparation afin de protéger votre serveur et

ses données.

Important : Il est possible, une fois la mise à niveau vers la version 6.3 ou
ultérieure terminée, que les conditions vous obligent à rétablir temporairement la
version précédente du serveur. Le rétablissement réussi de la version précédente
du serveur est uniquement possible si vous avez exécuté toutes les étapes de
préparation. Pour savoir pourquoi c'est si important, consultez la procédure de
rétablissement d'un serveur mis à niveau à sa version précédente.
Pour préparer la mise à niveau, procédez comme suit :

1. «Scénario 1: Vérification de la configuration requise pour la mise à niveau»
2. «Scénario 1: Préparation de l'espace pour le processus de mise à niveau», à la
page 108
3. «Scénario 1: Modification du serveur avant la mise à niveau», à la page 109
4. «Scénario 1: Désactivation des sessions», à la page 110
5. «Scénario 1: Sauvegarde des pools de stockage et de la base de données du
serveur», à la page 110
6. «Scénario 1: Suppression ou changement de nom du fichier NODELOCK», à la
page 111
7. «Scénario 1: Sauvegarde des informations de configuration», à la page 111
8. «Scénario 1: Création d'un récapitulatif du contenu de la base de données», à la
page 112
9. «Scénario 1: Arrêt du serveur avant l'installation de la mise à niveau», à la page
112
Tâches associées:
«Phase Postupgrade : rétablissement à partir de la version V6.3 ou ultérieure vers
la version précédente du serveur V5», à la page 380
Scénario 1: Vérification de la configuration requise pour la

mise à niveau
Vérifiez si la configuration de votre système est conforme aux exigences du
serveur.
Restriction : Si vous mettez à niveau le serveur Tivoli Storage Manager sur le

même système, le système doit répondre à la configuration minimale à la fois pour
les serveurs de version 5 et de version 6.3 ou ultérieure.
| 1. Vérifiez que le serveur que vous prévoyez de mettre à niveau est au niveau de
| version 5.3.6 ou suivant et que le dernier correctif temporaire est installé. Pour
| optimiser le processus de mise à niveau et éviter d'éventuels problèmes, mettez
| à niveau le serveur V5 vers le niveau le plus récent, puis installez le correctif
| temporaire le plus récent pour ce niveau. Suivez les instructions contenues
| dans la section «Déterminer le niveau approprié d'un serveur V5 avant une
| mise à niveau», à la page 42. Pour installer le dernier groupe de correctifs du
| serveur ainsi que le dernier correctif temporaire, visitez le site de
| téléchargements FTP à l'adresse ftp://public.dhe.ibm.com/storage/tivoli-
| storage-management/maintenance/server/. Localisez ensuite la version
| appropriée de Tivoli Storage Manager.
2. Assurez-vous que le système sur lequel le serveur version 5 est installé respecte
la configuration minimale requise. Consultez les informations contenues dans
«Configuration matérielle et logicielle requise pour le système du serveur
version 5 mis à niveau», à la page 19 afin de déterminer si vous devez mettre à
jour votre système avant de poursuivre.
3. Vérifiez que le système sur lequel vous prévoyez d'installer le serveur version
6.3 ou ultérieure est conforme aux exigences requises pour le type et le niveau
de système d'exploitation. Pour des informations actualisées sur la

configuration système, voir Systèmes d'exploitation pris en charge par Tivoli
Storage Manager (http://www.ibm.com/support/
docview.wss?uid=swg21243309). Vous pouvez maintenant vérifier
manuellement l'environnement d'installation. Sinon, attendez que les fichiers
d'installation soient extraits puis exécutez le vérificateur prérequis, qui vérifie
automatiquement l'environnement système. Pour plus d'informations, voir
«Exécution du vérificateur de prérequis», à la page 43.
Si vous effectuez une mise à niveau Tivoli Storage Manager sur un système
d'exploitation différent, un ensemble limité de chemins de migration est
disponible. Pour obtenir des instructions sur la migration d'un serveur qui
s'exécute sur un système d'exploitation z/OS, voir Partie 3, «Migration des
serveurs Tivoli Storage Manager version 5 s'exécutant sur des systèmes z/OS
vers la version 6 sous AIX ou Linux on System z», à la page 475. Pour obtenir
d'exploitation AIX, HP-UX, ou Solaris, voir Partie 2, «Migration des serveurs V5
Tivoli Storage Manager sur les systèmes AIX, HP-UX, ou Solaris vers la version
V6.3.4 surLinux», à la page 385.
Certaines plates-formes qui étaient prise en charge par des versions antérieures
du serveur ne sont pas prise en charge pour la version V6.3 ou ultérieure. Si le
ultérieure
(IA64)
(IA64)
Assurez-vous d'installer le serveur V6.3 ou ultérieure dans un environnement
IBM POWER IBM POWER
Chapitre 4. Scénario 1 : Même système, via des supports 105

| à la page 385.

ultérieure.
Manager version 5
à la page 475.
4. Vérifiez que la mémoire système est conforme aux exigences du serveur. Si

vous prévoyez d'exécuter plusieurs instances du serveur V6.3 ou ultérieure sur
le système, chacune d'elles requiert le volume mémoire répertorié pour un seul
serveur. Multipliez la mémoire destinée à un serveur par le nombre d'instances
planifiées pour le système.
Pour des informations spécifiques sur la mémoire requise, voir la section
relative à votre système d'exploitation :
Tableau 40. Mémoire requise pour le système version 6.3 ou ultérieure
Système d'exploitation Mémoire requise
AIX AIX «Configuration requise pour le serveur sur

des systèmes AIX», à la page 25
HPUX HP-UX «Configuration requise du serveur sur des

systèmes HP-UX», à la page 27
Linux Linux «Configuration du serveur requise sur des

systèmes Linux», à la page 29
Solaris Solaris «Exigences du serveur sur les systèmes

Solaris», à la page 36
Windows Windows «Configuration requise pour le serveur sur

des systèmes Microsoft Windows», à la page
38
5. Vérifiez que le système dispose d'un espace de stockage sur disque suffisant
pour la base de données et les journaux de reprise. Pour connaître les exigences
requises et obtenir une assistance, consultez les informations de planification.
Vous pouvez suivre l'une des deux approches suivantes :
v Vérifiez que le système dispose d'un espace de stockage sur disque suffisant
pour stocker la base de données et les journaux de reprise pour les serveurs
V5 et V6.3 ou ultérieure.
v Après avoir sauvegardé la base de données version 5 et extrait les données
dans la base de données via des supports, reconfigurez le sous-système de
disque utilisé pour le stockage de la base de données. Insérez ensuite les
données dans la nouvelle base de données à partir des supports. Vous devez
suivre cette approche si vous ne disposez pas d'espace disque suffisant pour
les deux serveurs.
Si vous ajoutez un nouveau composant matériel pour le serveur, comme une
unité de stockage sur disque pour la base de données, celui-ci doit être installé
et mis en service.

Concepts associés:
«Configurations matérielle et logicielle requises pour la mise à niveau vers le
serveur version 6.3 ou ultérieure», à la page 19
Scénario 1: Préparation de l'espace pour le processus de

mise à niveau
Déterminez la quantité et le type d'espace requis pour le processus de mise à
niveau avant de commencer le processus.
1. Vérifiez que l'espace disque du système correspond à celui estimé lors de
l'étape de planification. Utilisez les feuilles de calcul de planification que vous
complétez avec vos informations. Voir «Feuille de calcul pour l'espace de
2. Vérifiez que vous avez de l'espace disponible pour stocker la base de données
et le fichier manifeste créé par le processus d'extraction.
a. Identifiez la classe d'unités vers laquelle vous allez extraire la base de
données d'origine. La définition doit exister dans la base de données du
serveur et pas uniquement dans le fichier de configuration d'unité. Affichez
les informations sur les classes d'unités en effectuant la procédure :
query devclass format=detailed
La classe d'unités doit être à accès séquentiel et disposer de volumes ou
d'espace disponibles. Définissez une nouvelle classe d'unités si nécessaire.
La classe d'unités ne peut pas être de type NAS ou CENTERA.
Important : Vous devez confirmer maintenant que la définition figurant dans

la base de données du serveur pour la classe d'unités est correcte. Une fois
la préparation de la base de données pour la mise à niveau réalisée (en
effectuant l'étape Prepare Database dans l'assistant de mise à niveau ou à
l'aide de l'utilitaire DSMUPGRD PREPAREDB), cette définition de classe d'unités
ne peut plus être mise à niveau. Par exemple, vérifiez le chemin d'une
classe d'unités FILE. Si vous avez copié le serveur d'origine sur un système
différent en vue d'extraire les données, le chemin peut être différent sur le
système en cours.
b. Vérifiez que des espaces ou des volumes sont disponibles dans la classe
d'unités sélectionnée. La quantité d'espace nécessaire est à peu près la
même que la taille actuelle de la base de données d'origine.
Par exemple, si la classe d'unités est de type FILE, assurez-vous que le
répertoire dispose suffisamment d'espace pour votre environnement. Si la
classe d'unités est de type TAPE, assurez-vous que les volumes de montage
suffisants sont disponibles pour votre environnement.
Assurez-vous que l'ID utilisateur d'instance que vous créez pour le serveur
mis à niveau dispose des droits d'accès à l'emplacement d'extraction des
données.
c. Vérifiez que les droits d'accès sont corrects pour l'emplacement que vous
prévoyez de spécifier pour le fichier manifeste.
L'ID utilisateur qui exécutera les utilitaires de préparation et d'extraction de
la base de données (DSMUPGRD PREPAREDB et DSMUPGRD EXTRACTDB) doit avoir
des droits d'accès en écriture sur ce fichier. Il s'agit généralement de l'ID
utilisateur root.
Lorsque les données seront insérées dans la base de données version 6.3 ou
ultérieure, l'ID utilisateur de l'instance que vous utilisez pour le serveur mis
à niveau doit avoir des droits d'accès sur le fichier manifeste.
La taille du fichier manifeste est généralement inférieure à 1 ko.
Tâches associées:
Scénario 1: Modification du serveur avant la mise à niveau

Une commande doit être exécutée sur le serveur afin de prévenir un type
d'incident particulier pendant le processus de mise à niveau. Il peut être utile
d'apporter certaines modifications aux paramètres de serveur typiques pour
préparer la mise à niveau.
1. A partir d'une ligne de commande d'administration Tivoli Storage Manager,
lancez la commande suivante :
convert ussfilespace
Cette commande permet de corriger un incident qui peut se produire avec les
bases de données Tivoli Storage Manager antérieures. Si le problème n'existe
pas dans votre base de données, la commande est exécutée et vous pouvez voir
le message d'erreur ANR2034E. Cette erreur peut être ignorée. Pour plus
d'informations, voir la note technique 1408895 (http://www.ibm.com/support/
docview.wss?uid=swg21408895). Si le problème se produit dans votre base de
données, l'exécution de la commande peut prendre un certain temps.
Important : Ne faites pas l'impasse sur cette étape. Si l'incident se produit sur
votre base de données et que vous n'exécutez pas cette commande
immédiatement, l'exécution de l'utilitaire DSMUPGRD PREPAREDB échoue. Vous
devez redémarrer le serveur V5 et exécuter la commande CONVERT USSFILESPACE
avant de poursuivre avec le processus de mise à niveau.
2. Reportez-vous aux étapes de rétablissement de la version antérieure du serveur
dans la section «Phase Postupgrade : rétablissement à partir de la version V6.3
ou ultérieure vers la version précédente du serveur V5», à la page 380.
Si vous avez besoin de revenir à la version antérieure après la mise à niveau
vers la version 6.3 ou ultérieure, vous obtiendrez de meilleurs résultats si vous
maîtrisez bien la procédure et vous préparez à cette éventualité.
3. Ajustez les paramètres du serveur et des clients de la manière suivante. Ces
ajustements doivent être effectués pour vous permettre de revenir au serveur
d'origine après la mise à niveau si un incident se produit.
a. Pour chaque pool de stockage à accès séquentiel, définissez le paramètre
REUSEDELAY au nombre de jours pendant lesquels vous souhaitez revenir au
serveur d'origine si nécessaire.
Par exemple, si vous souhaitez être en mesure de revenir au serveur
d'origine pour une période allant jusqu'à 30 jours après la mise à niveau
vers la version V6.3 ou ultérieure, définissez le paramètre REUSEDELAY vers
une période de 31 jours. Emettez la commande d'administration suivante :
update stgpool
pool_stockage_accès_séquentiel reusedelay=31
b. Pour chaque copie du pool de stockage, affectez au paramètre RECLAIM la
valeur 100 (ce qui correspond à 100 %). Emettez la commande
d'administration suivante :
update stgpool pool_stockage_copie reclaim=100
c. Si vous utilisez généralement une commande DELETE VOLHISTORY pour
supprimer des sauvegardes de base de données, vérifiez que la commande
ne supprime pas celles-ci trop fréquemment. L'intervalle entre les
sauvegardes doit être au moins le même nombre de jours que celui défini
pour la période REUSEDELAY pour les pools de stockage à accès séquentiel.

Par exemple, pour supprimer les sauvegardes de base de données tous les
45 jours, émettez la commande d'administration suivante :
delete volhist type=dbbackup todate=-45
d. Pour les clients importants qui utilisent le serveur, vérifiez que la valeur de
l'option client schedlogretention est paramétrée pour conserver le journal
de planification client pendant le temps nécessaire. Le cas échéant, mettez à
jour l'option des clients.
Les entrées du journal de planification client peuvent s'avérer utiles si la
version d'origine du serveur doit être rétablie. Si la période de conservation
du journal est trop courte, les informations qu'il contient pourraient être
supprimées trop tôt.
Par exemple, pour élaguer le journal tous les 45 jours et sauvegarder les
entrées de journal, ajoutez l'option suivante :
schedlogretention 45 S
AIX HPUX Linux Placez cette option dans le fichier
Solaris
dsm.sys à l'intérieur d'une section serveur.
Windows Placez cette option dans le fichier d'options client, dsm.opt.
Scénario 1: Désactivation des sessions

Lors de la préparation de la mise à niveau, empêchez toute activité sur le serveur
en désactivant les nouvelles sessions. Annulez toute session existante.
Les commandes contenues dans la procédure suivante sont des commandes

d'administration de Tivoli Storage Manager.
1. Empêchez tous les clients, agents de stockage et autres serveurs, de démarrer
de nouvelles sessions avec le serveur. Utilisez les commandes suivantes :
disable sessions client
disable sessions server
2. Empêchez toute activité d'administration effectuée par un ID utilisateur autre
que l'ID administrateur utilisé pour effectuer la préparation de la mise à
niveau. Verrouillez les autres ID administrateur, si nécessaire :
lock admin nom_administrateur
3. Recherchez toute session existante et prévenez les utilisateurs que le serveur va
être arrêté. Pour rechercher les sessions existantes, utilisez la commande
suivante :
query session
4. Annulez les sessions encore actives. Utilisez la commande :
cancel session all
Scénario 1: Sauvegarde des pools de stockage et de la base

de données du serveur
Juste après avoir mis à niveau le serveur, sauvegardez les pools de stockage
principaux afin d'en créer des copies et procédez à une sauvegarde intégrale de la
base de données.
Sauvegardez les pools de stockage et la base de données du serveur à l'aide des

commandes d'administration de Tivoli Storage Manager :
1. Sauvegardez les pools de stockage principaux afin d'en créer des copies à l'aide
de la commande BACKUP STGPOOL :
backup stgpool pool_principal
pool_copie
où pool_principal indique le pool de stockage principal et pool_copie le pool de

stockage de copie. Si vous avez effectué des sauvegardes régulières des pools
de stockage, cette étape sauvegarde uniquement les données ajoutées aux pools
de stockage principaux depuis la dernière sauvegarde.
2. Sauvegardez la base de données. Il est conseillé d'utiliser de préférence une
sauvegarde par image instantanée. Une sauvegarde par image instantanée est
une sauvegarde intégrale qui n'interrompt pas les sauvegardes de base de
données planifiées. Exécutez la commande suivante :
backup db type=dbsnapshot
devclass=nom_classe_unités
La classe d'unités que vous indiquez doit exister et avoir des volumes
disponibles. Par exemple, pour effectuer une sauvegarde instantanée de votre
base de données vers la classe d'unités TAPECLASS à l'aide de volumes
utilisables, procédez comme suit :
backup db type=dbsnapshot devclass=tapeclass
Pour utiliser des volumes spécifiques, indiquez leur nom dans la commande.
Conseil : Prévoyez de générer deux copies de la sauvegarde afin de la protéger

en cas de défaillance des supports. Vérifiez qu'au moins une sauvegarde
complète de la base de données est disponible sur site. Si vous devez restaurer
la base de données après l'échec d'une mise à niveau, le fait de disposer d'une
base de données de sauvegarde sur site vous permet de gagner du temps.
Scénario 1: Suppression ou changement de nom du fichier

NODELOCK
Pour vérifier que les informations sur la licence sont bien mises à jour au cours du
processus de mise à niveau, supprimez ou renommez le fichier NODELOCK.
Le fichier NODELOCK conserve les informations sur les licences de l'installation

précédente de Tivoli Storage Manager . Pour vérifier que les informations sur la
licence sont bien mises à jour au cours du processus de mise à niveau, supprimez
ou renommez le fichier NODELOCK avant de démarrer le processus de mise à niveau.
Ces information sur la licence sont remplacées par les nouvelles une fois la mise à
niveau effectuée. Le fichier NODELOCK se trouve dans le répertoire d'instance du
serveur.
Scénario 1: Sauvegarde des informations de configuration

Avant d'installer la nouvelle version, sauvegardez les fichiers critiques et les
informations du serveur. Stockez les fichiers en lieu sûr, sur un système différent
de celui en cours de mise à niveau ou sur un support hors connexion, comme un
CD. Les fichiers sont nécessaires après l'installation de la nouvelle version du
logiciel. Ces fichiers vous seront également utiles pour rétablir une version
antérieure après la mise à niveau.
1. Sauvegardez les informations de configuration des unités en utilisant la
commande administrative Tivoli Storage Manager :
backup devconfig filenames=nom_fichier
où file_name désigne le fichier destiné au stockage des informations de

configuration des unités.
2. Sauvegardez les informations sur l'historique en utilisant la commande Tivoli
Storage Manager administrative :

backup volhistory filenames=nom_fichier
où file_name désigne le fichier destiné au stockage des informations sur

l'historique des volumes. Assurez-vous que l'historique des volumes inclut les
informations relatives à la sauvegarde de la base de données que vous avez
effectuée lors des étapes précédentes. Par exemple, lancez la commande :
query volhistory type=dbsnapshot
Examinez la sortie de requête pour vérifier que l'horodatage pour la

sauvegarde de base de données correspondant à l'heure de la sauvegarde.
3. Enregistrez les copies des fichiers suivants qui se trouvent dans le répertoire
d'instance du serveur :
v Fichier d'option de serveur, généralement renommé dsmserv.opt
v dsmserv.dsk
Important : Le fichier dsmserv.dsk n'est pas disponible dans Tivoli Storage

Manager version 6.3 ou ultérieure. Enregistrez une copie du fichier
dsmserv.dsk si vous devez repasser à la version 5.5.
4. Dans le repertoire d'instance du serveur, recherchez le fichier du journal
comptable, dsmaccnt.log. Si le fichier existe sauvegardez une copie.
5. Sauvegardez n'importe quel script qui utilisé pour terminer le nettoyage
quotidien du serveur. Consultez les scripts afin d'identifier les changements
nécessaires une fois la mise à niveau terminée.
6. Stocker le fichier de configuration d'unité, le fichier historique des volumes, le
fichier d'options du serveur et les autres fichiers dans un emplacement sûr.
Assurez-vous que les fichiers sont stockés sur un système différent à partir d'un
système en cours de mise à niveau ou sur un support hors ligne.
Scénario 1: Création d'un récapitulatif du contenu de la base

de données
Créez un récapitulatif du contenu de la base de données d'origine. Après la mise à
niveau, vous pouvez utiliser les mêmes commandes pour comparer les résultats et
confirmer que le contenu de la base de données est intact.
Exécutez des commandes qui fournissent un récapitulatif des informations relatives

au contenu de la base de données. Par exemple, lancez les commandes qui
présentent un résumé des espaces fichier protégés et sauvegardez les résultats.
Pour la liste des commandes, voir «Exemples des commandes à exécuter pour
valider la mise à niveau de la base de données», à la page 583.
«Exemples des commandes à exécuter pour valider la mise à niveau de la base de
Scénario 1: Arrêt du serveur avant l'installation de la mise à

niveau
Arrêtez tous les processus du serveur et démontez toutes les bandes montées.
Arrêtez ensuite le serveur.
Pour arrêter le serveur avant d'installer la mise à niveau, utilisez les commandes
d'administration de Tivoli Storage Manager :
1. Vérifiez si des processus serveur sont en cours d'exécution. Annulez les
processus ou laissez-les se terminer. Utilisez les commandes suivantes :
query process
cancel process numéro_processus
Attendez que les processus soient arrêtés. L'arrêt de certains processus, comme
le processus de migration de pools de stockage peut prendre un certain temps.
Pour plus d'informations sur la requête ou l'annulation de processus, voir les
commandes QUERY PROCESS et CANCEL PROCESS dans le Guide de référence
d'administration.
2. Une fois toutes les sessions et tous les processus arrêtés, vérifiez si des bandes
sont montées. Démontez toutes les bandes montées. Utilisez les commandes
suivantes :
query mount
dismount volume nom_volume
Pour plus d'informations sur la désinstallation des bandes, voir les commandes
QUERY MOUNT et DISMOUNT VOLUME dans le Guide de référence d'administration.
3. Arrêtez le serveur. Utilisez la commande :
halte
Scénario 1 : Installation des utilitaires de mise à niveau

Vous devez installer les utilitaires de mise à niveau sur le système. Le module
d'installation des utilitaires doit être téléchargé sur un site Web.
| La méthode recommandée consiste à installer la dernière version disponible des

| utilitaires de mise à niveau. Pour plus d'informations sur le choix d'une version,
| voir «Déterminer le niveau approprié d'un serveur V5 avant une mise à niveau», à
| la page 42.
Utilisez la procédure correspondant à votre système d'exploitation :

v AIX «Scénario 1: Installation des utilitaires de mise à niveau sur des
systèmes AIX»
v HPUX «Scénario 1: Installation des utilitaires de mise à niveau sur des
v Linux «Scénario 1: Installation des utilitaires de mise à niveau sur des
v Solaris «Scénario 1: Installation des utilitaires de mise à niveau sur des
systèmes Oracle Solaris », à la page 118
v Windows «Scénario 1: Installation des utilitaires de mise à niveau sur des
systèmes Microsoft Windows», à la page 120
Concepts associés:
«utilitaires de mise à niveau DSMUPGRD», à la page 18
Scénario 1: Installation des utilitaires de mise à niveau sur

des systèmes AIX
AIX
Installez les utilitaires de mise à niveau sur le système. Le module à installer peut
être téléchargé à partir du site des téléchargements FTP. Les utilitaires de mise à
niveau servent à préparer et à extraire la base de données à partir du serveur
d'origine.

1. Procurez-vous le module des utilitaires de mise à niveau depuis le site de

téléchargement FTP.
a. Consultez le site ftp://public.dhe.ibm.com/storage/tivoli-storage-
management/maintenance/server-upgrade/v5r5/
b. Accédez au répertoire correspondant au système d'exploitation sur lequel
s'exécute votre serveur version 5. A partir de ce répertoire, ouvrez le
répertoire 5.5.x.x. La référence 5.5.x.x doit être identique ou ultérieure à
celle du serveur version 5 que vous mettez à niveau.
c. Sélectionnez le module qui correspond à votre système d'exploitation, et
téléchargez-le vers l'emplacement souhaité sur le système du serveur. Le
nom du module se présente sous la forme suivante :
5.5.x.x-TIV-TSMUPG-AIX.tar.gz
Les nombres présents au début du nom identifient le niveau d'édition du
module des utilitaires de mise à niveau.
d. Facultatif : Pour installer les messages dans une langue autre que l'anglais,
ouvrez le répertoire LANG et téléchargez un module de langue. Les
messages traduits sont disponibles dans le module de langue habituel
pour serveur version 5.
2. Connectez-vous avec l'ID utilisateur root.
3. Vérifiez que les ensembles de fichiers suivants sont installés sur le système :
xlC.rte 8.0.0.5 ou version ultérieure
gsksa.rte 7.0.4.11
Vous pouvez utiliser les commandes suivantes pour vérifier ces jeux de
fichiers :
lslpp -L xlC.rte
lslpp -L gsksa.rte
Si nécessaire, vous pouvez obtenir le jeu de fichiers gsksa.rte version 5.5 à

partir de tout module de maintenance régulier pour le serveur AIX. Les
modules de maintenance sont disponibles sur le site de téléchargement FTP :
ftp://public.dhe.ibm.com/storage/tivoli-storage-management/maintenance/
server/v5r5/AIX/
4. Extrayez le contenu du module d'utilitaires de mise à niveau. Si vous avez
téléchargé un module de langue, extrayez également son contenu.
5. Accédez au répertoire qui correspond à l'architecture du processeur du
système d'exploitation.
6. Accédez l'outil SMIT (System Management Interface Tool).
a. Entrez la commande smitty install_update
b. Sélectionnez Install and Update Software > Install and Update from ALL
Available Software.
7. Sélectionnez l'unité de type INPUT. Indiquez l'emplacement du répertoire du
module des utilitaires de mise à niveau sur le système.
8. Sélectionnez Software to Install (logiciels à installer). Appuyez sur F4 ou sur
Echap+4 pour afficher la liste des ensembles de fichiers disponibles dans le
répertoire.
9. Sélectionnez les ensembles de fichiers pour les utilitaires de mise à niveau, le
pilote de périphérique et éventuellement le module de langue. Le jeu de
fichiers correspondant aux utilitaires de mise à niveau est
tivoli.tsmupg.server. Les modules de langue facultatifs comprennent des
messages pour des langues autres que l'anglais américain.
10. Paramétrez COMMIT software updates sur Yes. Appuyez sur la touche F4 ou
sur Echap+4.
11. Paramétrez SAVE replaced files sur No.
12. Assurez-vous que les paramètres par défaut des options de la fenêtre
indiquent success pour tous les jeux de fichiers sélectionnés.
13. Appuyez sur la touche Entrée et répondez à la question ARE YOU SURE? en
appuyant à nouveau sur cette touche. L'installation commence.
14. Une fois l'installation terminée, quittez le programme SMIT.
15. Facultatif : Si vous avez installé un module de langue, vérifiez que la variable
d'environnement correspondant aux paramètres régionaux est définie pour
utiliser ce module. Entrez la commande suivante pour définir la variable
d'environnement des paramètres régionaux au niveau des messages :
export LC_MESSAGES=xxxx
où xxxx correspond aux paramètres régionaux à utiliser. Par exemple, utilisez

it_IT pour l'italien. Pour que les utilitaires de mise à niveau fonctionnent avec
les paramètres régionaux souhaités, indiquez la valeur true au niveau des
instructions suivantes :
v Les paramètres régionaux sont installés sur le système.
v Les utilitaires de mise à niveau prennent en charge les paramètres
régionaux.
v Le module de langue installé pour les utilitaires de mise à niveau
correspond aux paramètres régionaux.
16. Une fois les utilitaires de mise à niveau installés, poursuivez avec «Scénario 1:
Paramétrage des variables d'environnement pour les utilitaires de mise à
niveau sur des systèmes AIX, HP-UX, Linux et Oracle Solaris», à la page 119.

des systèmes HP-UX
HPUX
d'origine.
5.5.x.x-TIV-TSMUPG-platforme.tar.gz

ouvrez le répertoire LANG et téléchargez un module de langue. Les messages
traduits sont disponibles dans le module de langue habituel pour serveur
version 5.
3. Extrayez le contenu du module d'utilitaires de mise à niveau. Par exemple,
lancez la commande suivante à partir du répertoire dans lequel vous avez
sauvegardé le module téléchargé :
gzip
-dc nom_module.tar.gz | tar -xvf -
4. Accédez au répertoire qui correspond à l'architecture du processeur du système
d'exploitation.
5. Installez les utilitaires de mise à niveau et le pilote de périphérique. Utilisez
l'argument source (-s) pour indiquer le répertoire dans lequel le module a été
extrait. Par exemple, s'il s'agit du répertoire /tmp/TSM, lancez la commande
suivante :
swinstall -s /tmp/TSM nom_module
Les utilitaires sont installés dans le répertoire /opt/tivoli/tsm/upgrade/bin.

6. Facultatif : Installez le module de langue.
a. Extrayez le contenu du module.
gzip -d nom_module.img.gz
b. Installez le module. Par exemple, s'il s'agit du répertoire /tmp/TSM, lancez la
commande suivante :
swinstall -s /tmp/TSM/nom_module.img nom_module
c. Entrez la commande suivante pour définir la variable d'environnement des
paramètres régionaux au niveau des messages :
où xxxx correspond aux paramètres régionaux à utiliser. Par exemple,

utilisez it_IT pour l'italien. Pour que les utilitaires de mise à niveau
fonctionnent avec les paramètres régionaux souhaités, indiquez la valeur
true au niveau des instructions suivantes :
régionaux.

des systèmes Linux
Linux
d'origine.

c. Ouvrez le répertoire correspondant à votre système d'exploitation et
téléchargez le module. Le nom du module se présente sous la forme
suivante :
5.5.x.x-TIV-TSMUPG-platforme.tar.bz2
version 5.
lancez les commandes suivantes à partir du répertoire dans lequel vous avez
bunzip2 nom_module.tar.bz2
tar xvf nom_module.tar
d'exploitation, par exemple : x86_64.
5. Installez les utilitaires de mise à niveau et le pilote de périphérique. Utilisez la
commande suivante :
rpm -ivh nom_module.rpm
Les utilitaires sont installés par défaut dans le répertoire /opt/tivoli/tsm/
upgrade/bin.
a. Extrayez le contenu du module téléchargé.
b. Installez le module correspondant à la langue que vous souhaitez utiliser.

régionaux.


des systèmes Oracle Solaris
Solaris
d'origine.
5.5.x.x-TIV-TSMUPG-platforme.tar.Z
version 5.
3. Accédez au répertoire dans lequel le module des utilitaires de mise à niveau a
été téléchargé.
uncompress -c nom_module.tar.Z | tar -xvf -
5. Accédez au répertoire qui correspond à l'architecture de processeur du système
d'exploitation.
l'argument source (-d) pour indiquer le répertoire dans lequel le module a été
suivante :
pkgadd -d . /tmp/TSM package_name

upgrade/bin.
décompressez package_name.pkg.Z

Utilisez l'argument source (-d) pour indiquer le répertoire dans lequel le
module a été extrait. Par exemple, s'il s'agit du répertoire /tmp/TSM, lancez
la commande suivante :
pkgadd
-d /tmp/TSM nom_module.pkg
nom_module

régionaux.
niveau sur des systèmes AIX, HP-UX, Linux et Oracle Solaris».
Scénario 1: Paramétrage des variables d'environnement pour

les utilitaires de mise à niveau sur des systèmes AIX, HP-UX,
Linux et Oracle Solaris
Après avoir installé le module des utilitaires de mise à niveau, définissez les
variables d'environnement dans le shell à partir duquel vous allez exécuter les
utilitaires. Une variable d'environnement décrit l'environnement fonctionnel d'un
processus, par exemple son répertoire d'accueil ou le terminal utilisé.
La variable DSMSERV_DIR indique l'emplacement d'installation des utilitaires de mise

à niveau. Par défaut, l'emplacement correspond au répertoire suivant :
AIX
/usr/tivoli/tsm/upgrade/bin
HPUX Linux Solaris
/opt/tivoli/tsm/upgrade/bin
Utilisez la commande appropriée pour votre système afin de définir la variable

d'environnement pour exécuter les utilitaires. Si shell fait partie du groupe ksh ou
bash, entrez la commande suivante pour définir la variable DSMSERV_DIR :
export DSMSERV_DIR=upgrade_utilities_directory
Si votre Shell fait partie du groupe csh , utilisez la commande suivante :

setenv DSMSERV_DIR upgrade_utilities_directory

où upgrade_utilities_directory est le répertoire dans lequel les utilitaires de mise à

jour sont installés.
Après avoir défini les variables d'environnement, poursuivez avec «Scénario 1:

Préparation de la base de données sur un serveur version 5 en vue de la mise à
niveau».

des systèmes Microsoft Windows
Windows
d'origine.
management/maintenance/server-upgrade/v5r5/WIN
b. Ouvrez le répertoire 5.5.x.x. La référence 5.5.x.x doit être identique ou
ultérieure à celle du serveur version 5 que vous mettez à niveau.
c. Sélectionnez le module téléchargez-le vers l'emplacement souhaité sur le
système du serveur. Le nom du module se présente sous la forme suivante :
5.5.x.x-TIV-TSMUPG-Windows.exe
installez le module de langue que votre installation requiert.
2. Connectez-vous avec un ID administrateur.
3. Lancez le module exécutable des utilitaires de mise à niveau.
L'emplacement par défaut pour l'installation des utilitaires dépend de
l'emplacement où la dernière installation du serveur version 5 a été effectuée.
Par exemple, si le serveur version 5 a été installé à l'aide du chemin par défaut,
C:\Program Files\Tivoli\TSM\server, les utilitaires de mise à niveau sont
installés dans C:\Program Files\Tivoli\TSM\upgrade.
Une fois les utilitaires de mise à niveau installés, poursuivez avec «Scénario 1:
niveau».
Conseil : Lorsque vous faites appel aux utilitaires de mise à niveau, si plusieurs
serveurs sont exécutés sur le système, vous devez utiliser l'option -k pour indiquer
le nom de la clé de registre Windows à partir de laquelle extraire les informations
relatives au serveur mis à niveau. La valeur par défaut de l'option est SERVER1.
Scénario 1: Préparation de la base de données sur un serveur version

5 en vue de la mise à niveau
Avant d'extraire les données de la base de données, vous devez préparer la base de
données du serveur à l'aide de l'utilitaire DSMUPGRD PREPAREDB. Si plusieurs serveurs
sont installés sur un seul système, répétez cette tâche pour chaque serveur.
1. Assurez-vous que toutes les étapes de préparation ont été effectuées.
2. Connectez-vous à l'aide de l'ID utilisateur du système sur lequel le serveur

d'origine est installé. Connectez-vous avec l'ID d'administrateur sur un système
Windows.
3. Accédez au répertoire d'instance du serveur que vous mettez à niveau. Le
répertoire d'instance est celui qui contient les fichiers, tels que dsmserv.dsk, du
serveur.

4. Préparez la base de données. Dirigez la sortie du processus vers un fichier à
des fins de surveillance.
AIX
A partir du répertoire d'instance du serveur que vous mettez à niveau,
lancez la commande suivante pour exécuter le processus en arrière-plan
et diriger la sortie vers le fichier prepare.out :
nohup /usr/tivoli/tsm/upgrade/bin/dsmupgrd preparedb >prepare.out 2>&1 &
HPUX Linux Solaris

nohup /opt/tivoli/tsm/upgrade/bin/dsmupgrd preparedb >prepare.out 2>&1 &
Windows
lancez la commande suivante pour exécuter le processus et diriger la
sortie vers le fichier prepare.out :
"c:\Program Files\Tivoli\TSM\upgrade\dsmupgrd"
preparedb 1>>prepare.out 2>&1
Si plusieurs serveurs sont installés sur le système, exécutez la

commande à partir du répertoire d'instance du serveur que vous
souhaitez préparer. Indiquez la clé de registre pour ce serveur. Par
exemple, si le serveur est SERVER2 :
"c:\Program Files\Tivoli\TSM\upgrade\dsmupgrd" -k server2
5. Surveillez le processus afin d'identifier les erreurs et les messages
d'avertissement. Le message final indique la réussite ou l'échec de l'opération.
A partir du répertoire de l'instance du serveur que vous mettez à niveau,
lancez la commande suivante pour surveiller le processus :
tail -f prepare.out
Conseil : Sur des systèmes Windows, utilisez la commande tail ou un

utilitaire équivalent permettant de surveiller le contenu d'un fichier qui change.
Par exemple, Windows Server 2003 Resource Kit Tools inclut la commande tail
qui peut être utilisée comme indiqué dans l'exemple.
6. Assure-vous que l'opération de préparation a réussi avant de passer à l'étape
suivante. Si l'opération de préparation échoue, il peut être nécessaire de
redémarrer le serveur version 5 pour corriger le problème et relancer
l'opération de préparation. Si le serveur mis à niveau correspond à la version
V5.3 or V5.4, il peut être nécessaire de restaurer la base de données à l'aide
d'une sauvegarde avant de relancer le serveur pour corriger le problème.

Scénario 1: Désinstallation du programme version 5 avant l'installation

de V6.3 ou d'une version ultérieure
Pour optimiser les résultats lorsque vous mettez à niveau le serveur vers la version
6.3 ou ultérieure sur le même système que celui où se trouve le serveur version 5,
désinstallez le programme de ce dernier avant d'installer le programme du serveur

v AIX «Scénario 1: Désinstallation du programme version 5 sur des systèmes
AIX»
v HPUX «Scénario 1: Désinstallation du programme version 5 sur des systèmes
HP-UX»
v Linux «Scénario 1: Désinstallation du programme version 5 sur des systèmes
Linux», à la page 123
v Solaris «Scénario 1: Désinstallation du programme version 5 sur des systèmes
Oracle Solaris», à la page 123
v Windows «Scénario 1: Désinstallation du programme version 5 sur des systèmes
Microsoft Windows», à la page 124
Scénario 1: Désinstallation du programme version 5 sur des

systèmes AIX
AIX
Désinstallez le serveur version V5, la licence du serveur et le pilote de

périphérique, s'il est disponible. Ne supprimez pas la base de données, le journal de
reprise ou tout autre fichier ou répertoire associé, comme le fichier d'options du
serveur.
v Pour un serveur version 5.4 ou 5.5, entrez les commandes suivantes :
/usr/sbin/installp -ug tivoli.tsm.license.aix5.rte64
/usr/sbin/installp -ug tivoli.tsm.devices.aix5.rte
/usr/sbin/installp -ug tivoli.tsm.server.aix5.rte64
v Pour un serveur version 5.3, entrez les commandes suivantes :
/usr/sbin/installp -ug tivoli.tsm.license
/usr/sbin/installp -ug tivoli.tsm.devices
/usr/sbin/installp -ug tivoli.tsm.server
Après avoir désinstallé le programme du serveur version 5, poursuivez avec

«Scénario 1: Installation du serveur V6.3 ou d'une version ultérieure», à la page
124.

systèmes HP-UX
HPUX

serveur.
swremove TIVsmS64IA.server
swremove TIVsmS64IA.license
swremove TIVsmDD64_IA11_23.tsmscsi
swremove TIVsmS64.server
swremove TIVsmS64.license
swremove TIVsmDD64_HP11_11.tsmscsi

124.

systèmes Linux
Linux

serveur.
1. Pour identifier quels sont les modules Tivoli Storage Manager installés, lancez
rpm -qa | grep TIVsm
2. Supprimez le serveur, la licence de serveur et les modules de pilote de
périphérique. Emettez les commandes suivantes :
rpm -e TIVsm-server
rpm -e TIVsm-license
rpm -e TIVsm-tsmscsi

124.

systèmes Oracle Solaris
Solaris

serveur.
Emettez les commandes suivantes :

/usr/sbin/pkgrm TIVsmS
/usr/sbin/pkgrm TIVsmSlic
/usr/sbin/pkgrm TIVsmSdev


«Scénario 1: Installation du serveur V6.3 ou d'une version ultérieure».

systèmes Microsoft Windows
Windows

serveur.
Ne supprimez pas les entrées de registre pour le serveur.

1. Cliquez sur Démarrer > Panneau de configuration > Ajout/Suppression de
programmes.
2. Sélectionnez Tivoli Storage Manager le composant serveur, puis cliquez sur
Remove. Répétez l'opération pour la licence et le pilote de périphérique.
Si des messages vous suggérent de redémarrer le système s'affichent,
ignorez-les jusqu'à ce que les composants sélectionnés Tivoli Storage Manager
soient supprimés.

Scénario 1: Installation du serveur V6.3 ou d'une version ultérieure

Vous pouvez faire appel à l'assistant d'installation ou installer le serveur par le
biais de la console.
Veillez à exécuter toutes les étapes de préparation, parmi lesquelles la sauvegarde

de la base de données du serveur, avant de commencer la procédure d'installation.
Le serveur ne sera pas disponible tant que l'installation et la mise à niveau ne
seront pas terminées.
Démarrage avec V6.3, l'assistant d'installation du serveur IBM Tivoli Storage

Manager dispose d'un accord de licence distinct pour les produits suivants :
v Tivoli Storage Manager
v IBM Tivoli Storage Manager Extended Edition
v IBM System Storage Archive Manager
v IBM Tivoli Storage Manager pour Storage Area Networks
Avant la mise à niveau du serveur Tivoli Storage Manager, vérifiez que vous
possédez le support d'installation d'édition de la base du serveur installé. Si vous
avez installé Tivoli Storage Manager à partir d'un DVD, vérifiez que le DVD est
disponible. Si vous avez installé Tivoli Storage Manager à partir d'un module
téléchargé, vérifiez que les fichiers téléchargés sont disponibles. Si la mise à niveau
échoue et que le module de licence du serveur est désinstallé, le support
d'installation d'édition de la base de serveur est nécessaire pour réinstaller la
licence.
Pour vérifier l'environnement système et installer le serveur, complétez les étapes

suivantes :
1. Pour certains systèmes d'exploitation, vous devez vérifier certains paramètres

système avant de démarrer l'installation.
Linux
Si vous utilisez Security Enhanced Linux sur votre système, définissez
SELINUX=disable ou définissez SELINUX=permissive dans le fichier
/etc/sysconfig/selinux, au moins jusqu'à ce que le processus
d'installation soit terminé.
Si vous n'indiquez pas ces paramètres, le message suivant s'affichera
lorsque vous installerez le serveur :
Impossible d’exécuter l’assistant d’installation avec la configuration actuelle.
Il va s’arrêter.
Pour plus d’informations sur les journaux des erreurs d’installation,
entrez la phrase "installation log files" dans la
zone Search de ce site :
http://publib.boulder.ibm.com/infocenter/tsminfo/v6r3
Solaris
Avant d'installer tous les composants Tivoli Storage Manager,
assurez-vous que la variable d'environnement LD_LIBRARY_PATH_64
n'est pas définie.
2. Connectez-vous au système.
Connectez-vous à l'aide de l'ID utilisateur root.
Windows
Connectez-vous en tant qu'administrateur.
3. Si vous disposez du DVD du produit, suivez la procédure ci-après.
Insérez le DVD Tivoli Storage Manager dans un lecteur de DVD.
Vérifiez que le DVD est monté sur le répertoire /dvdrom et accédez à
ce répertoire.
Windows
Insérez le DVD du serveur Tivoli Storage Manager. Utilisez
l'Explorateur Windows pour afficher le contenu du DVD.
4. Si vous avez téléchargé le programme à partir de Passport Advantage en tant
que fichier exécutable, appliquez la procédure suivante.
a. Vérifiez que vous disposez de suffisamment d'espace pour stocker

les fichiers d'installation lors de leur extraction du module du
produit. Consultez le document se rapportant au téléchargement
pour plus d'informations sur les exigences en matière d'espace :
Tivoli Storage Manager: http://www.ibm.com/support/
Tivoli Storage Manager Extended Edition :
System Storage Archive Manager: http://www.ibm.com/
b. Accédez au répertoire dans lequel vous avez placé le fichier
exécutable.

Conseil : Assurez-vous que le fichier se trouve dans le répertoire

où vous voulez que les fichiers soient extraits. Lors d'une étape
ultérieure, les fichiers seront extraits dans ce répertoire.
c. Modifiez les droits d'accès au fichier en entrant la commande
suivante :
chmod
a+x nom_module.bin
La variable nom_module correspond généralement à un nom tel que

CZ1N1ML.
d. Extrayez les fichiers d'installation :
./nom_module.bin
Le module étant volumineux, l'extraction prend un certain temps.

Windows

exécutable.

où vous voulez que les fichiers soient extraits. Lors de l'étape
suivante, les fichiers seront extraits dans le répertoire actif.
c. Cliquez deux fois sur le fichier exécutable ou entrez la commande
suivante sur la ligne de commande afin d'extraire les fichiers
d'installation. Les fichiers sont extraits dans le répertoire actif.
nom_module.exe
Nom_module correspond généralement à un nom du type CZ1N9ML.

5. Vérifiez que l'environnement système est conforme aux exigences
d'installation. Vous pouvez vérifier manuellement les exigences ou exécuter le
vérificateur de prérequis. Pour exécuter le vérificateur de prérequis, procédez
comme suit :
a. AIX HPUX Linux Solaris Exécutez cette commande pour
démarrer la vérification de la configuration requise à l'aide d'une interface
graphique :
./prereqcheck.bin
Exécutez également cette commande pour démarrer la vérification de la

configuration requise à l'aide de la méthode de console :
b. Windows Exécutez cette commande pour démarrer la vérification de la

configuration requise à l'aide d'une interface graphique :
prereqcheck.exe
Exécutez par ailleurs cette commande pour démarrer la vérification de la

configuration requise avec la méthode de la console :
c. Sélectionnez la langue de l'interface utilisateur du programme de
vérification des prérequis.
d. Dans les panneaux d'accueil et d'exclusion de responsabilité, consultez les
Si le panneau Prerequisite Results indique que votre poste de travail a passé
les contrôles avec succès, vous pouvez démarrer l'installation. Si une erreur
s'affiche dans le panneau Prerequisite Results, effectuez les corrections
requises avant de continuer l'installation. Pour plus d'informations sur le
vérificateur de prérequis, voir «Exécution du vérificateur de prérequis», à la
page 43.
6. A partir du DVD ou de l'emplacement où vous avez extrait le module, lancez
l'assistant d'installation. Vous pouvez utiliser l'assistant graphique ou
l'assistant de la console.
v Lancez l'assistant graphique :

./install.bin
v Lancez l'assistant de console :
./install.bin -i console
Windows

install.exe
install.exe -i console
Pour obtenir des informations sur les traductions disponibles pour le serveur,
voir la section des langues locales. Pour obtenir des informations sur
l'installation silencieuse du serveur, voir la section sur l'installation Tivoli
Storage Manager en mode silencieux du Guide d'installation.
7. Sélectionnez la langue de votre installation et suivez l'assistant en
sélectionnant Suivant pour avancer dans les différentes étapes de l'assistant.
a. Vous devez accepter le contrat de licence pour pouvoir effectuer

l'installation. Sélectionnez le produit que vous êtes autorisé à
utiliser et un contrat de licence s'affiche. Vous ne pouvez
sélectionner qu'un produit sur la page. Si vous sélectionnez Tivoli
Storage Manager, Tivoli Storage Manager Extended Edition ou
System Storage Archive Manager, le système vous demande si
vous continuez à utiliser un partage hors réseau local ou de
bibliothèques. Si vous sélectionnez YES, vous devez accepter la
licenceTivoli Storage Manager for Storage Area Networks. Cette
licence vient s'ajouter à la licence du produit que vous choisissez
sur la page précédente.

b. Sélectionnez les composants à installer. Les composants sont : le

serveur, les langues, la licence, le pilote de périphérique et l'agent
de stockage. Aucun composant n'est sélectionné par défaut, vous
devez donc faire un choix. Si vous avez précédemment installé un
serveur, assurez-vous de sélectionner le même répertoire pendant
que vous installez un module de langue, une licence ou un pilote
de périphérique. Si vous avez précédemment installé un agent de
stockage, vérifiez que vous avez sélectionné le même répertoire si
vous réinstallez un pilote d'unité. Un serveur et un agent de
stockage ne peuvent pas être installés sur le même poste de
travail. Pour en savoir plus sur les autres composants que vous
choisissez d'installer, voir Guide d'installation.
L'interface de programmation de Tivoli Storage Manager l'application client,
DB2 Version 9.7, et Global Security Kit (GSKit) 8 sont automatiquement
installés en sélectionnant le composant du serveur.
8. Lorsque l'installation est terminée, vérifiez qu'un message s'affiche indiquant
que l'installation a réussi.
Important : Si des erreurs se sont produites lors de l'installation, un panneau

récapitulatif les répertorie et vous redirige vers un journal des erreurs.
Corrigez les erreurs avant de passer à l'étape suivante.
Le journal d'installation est enregistré à l'emplacement suivant :
AIX HPUX Linux Solaris /var/tivoli/tsm
Windows Le répertoire choisi pour l'installation (recherchez les fichiers
log.txt et logs.zip)
9. Téléchargez et appliquez tous les correctifs disponibles pour le serveur.
Rendez-vous sur le site de support du produit à l'adresse suivante :
http://www.ibm.com/support/entry/portal/Downloads. Recherchez les
mises à jour du serveur.
Vous pouvez également vérifier le site de téléchargements FTP à l'adresse
suivante : ftp://public.dhe.ibm.com/storage/tivoli-storage-management/
maintenance/server.
10. HPUX Linux Solaris Modifiez les valeurs des paramètres du noyau,
si nécessaire.
HPUX
Exécutez l'utilitaire db2osconf afin d'obtenir des recommandations sur
les modifications à apporter aux valeurs du paramètre du noyau en
fonction de la taille du système. En fonction des recommandations,
modifiez les résultats de l'utilitaire. Vous pouvez redémarrer le
système.
Pour plus d'informations sur l'utilitaire et sur la modification des
paramètres du noyau, voir http://pic.dhe.ibm.com/infocenter/
db2luw/v9r7. Pour rechercher les informations, entrez le nom de
l'utilitaire db2osconf dans la zone Search de ce site.
Important : Les recommandations fournies par l'utilitaire db2osconf

correspondent à des valeurs minimales. Certaines charges de travail,
par exemple, le processus de mise à niveau de la base de données,
peuvent nécessiter de définir une valeur supérieure à celle
recommandée. Pour plus d'information sur le réglage des paramètres
du noyau pour Tivoli Storage Manager, voir http://www.ibm.com/
support/docview.wss?uid=swg27015156.
Les ressources système, telles que les sémaphores, peuvent également

nécessiter un configuration et un réglage particuliers. Voir Annexe C,
Linux
Pour mettre à jour les paramètres du noyau sous Red Hat et SUSE
Linux, vous pouvez exécuter la commande ipcs - l afin de
répertorier les valeurs des paramètres. Analysez les résultats pour
déterminer si votre système requiert des modifications.
Pour plus d'informations sur la modification des paramètres du
noyau, voir http://pic.dhe.ibm.com/infocenter/db2luw/v9r7. Pour
rechercher des informations, entrez une chaîne de recherche telle que
modifier paramètres noyau dans la zone de recherche du site.
Pour exécuter Tivoli Storage Manager avec DB2, vous devez peut-être
définir les valeurs de paramètre de noyau à un niveau supérieur aux
valeurs minimales suggérées et effectuer d'autres changements au
système. Pour plus de détails, voir la section sur le réglage des
paramètres de noyau pour les systèmes Linux dans le Guide
d'installation.
Solaris
système.

Concepts associés:
Scénario 1: Création des répertoires et de l'ID utilisateur pour

l'instance de serveur mise à niveau
Créez les répertoires dont l'instance de serveur a besoin pour la base de données et
les fichiers journaux de reprise et créez l'ID utilisateur à laquelle appartiendra
l'instance du serveur.
Avant de terminer cette tâche, reportez-vous aux informations relatives à la

planification de l'espace pour le serveur. Voir «Feuille de calcul pour l'espace de

1. Créez l'ID utilisateur auquel appartiendra l'instance du serveur. C'est à l'aide de

cet ID utilisateur que vous créez l'instance du serveur lors d'une étape
ultérieure.
Créez un ID utilisateur et un groupe auxquels appartiendra l'instance

du serveur Tivoli Storage Manager.
a. Créez l'ID l'utilisateur et le groupe.
Restriction : L'ID utilisateur doit uniquement contenir des lettres en

minuscules (a-z), des chiffres (0-9) et le trait de soulignement (_).
L'ID utilisateur et le nom du groupe doivent respecter les règles
suivantes :
v La longueur doit être inférieure ou égale à 8 caractères.
v L'ID utilisateur et le nom de groupe ne peuvent pas commencer
par ibm, sql, sys, ou un chiffre.
v L'ID utilisateur et le nom de groupe ne peuvent pas être user,
admin, guest, public, local, ou un mot réservé à SQL.
Par exemple, créez l'ID utilisateur tsminst1 dans le groupe
tsmsrvrs. Les exemples ci-dessous indiquent comment créer cet ID
utilisateur et ce groupe à l'aide des commandes du système
d'exploitation.
AIX
# mkgroup id=1001 tsmsrvrs

# mkuser id=1002 pgrp=tsmsrvrs home=/home/tsminst1 tsminst1
# passwd tsminst1
HPUX
# groupadd tsmsrvrs
# useradd -d /home/tsminst1 -m -g tsmsrvrs
-s /bin/ksh tsminst1
# passwd tsminst1
Linux
# groupadd tsmsrvrs
# useradd -d /home/tsminst1 -m -g tsmsrvrs -s /bin/bash tsminst1
# passwd tsminst1
Solaris
# groupadd tsmsrvrs
# useradd -d /export/home/tsminst1 -m -g tsmsrvrs
# passwd tsminst1
b. Déconnectez-vous, puis reconnectez-vous au système en utilisant le
nouvel ID utilisateur et le nouveau mot de passe. Utilisez un
programme de connexion interactif, tel que telnet, de telle sorte que
le système vous invite à saisir un mot de passe et à le changer si
nécessaire.
c. S'il n'existe pas de profil de configuration pour cet ID utilisateur,
créez le fichier. Par exemple, créez un fichier .profile si vous
utilisez l'interpréteur de commandes Korn (ksh).
Windows
Identifiez le compte utilisateur auquel appartiendra l'instance du
serveur Tivoli Storage Manager. Lorsque le serveur est démarré en tant

que service Windows, il s'agit du compte auquel ce service se
connectera. Le compte utilisateur doit avoir des droits d'accès
d'administrateur sur le système. Un compte utilisateur peut posséder
plusieurs instances de serveur.
Vous pouvez créer un compte utilisateur ou utiliser un compte existant.
Si vous disposez de plusieurs serveurs sur un système et voulez
exécuter chaque serveur avec un compte utilisateur différent, créez un
compte utilisateur au cours de cette étape.
a. Créez l'ID utilisateur.
Restriction : L'ID utilisateur peut contenir uniquement des lettres

en minuscules (a à z), des chiffres (0 à 9), ainsi que le trait de
soulignement (_). L'ID utilisateur doit comporter 30 caractères ou
moins et ne peut pas commencer par ibm, sql, sys, ou un chiffre.
L'ID utilisateur et le nom de groupe ne peuvent pas être user, admin,
guest, public, local, ou un mot réservé à SQL.
Utilisez la commande suivante pour créer l'ID utilisateur :
net
user ID_utilisateur */add
Une invite vous demande créer et de vérifier un mot de passe

correspondant au nouvel ID utilisateur.
b. Exécutez les commandes suivantes du système d'exploitation afin
d'ajouter le nouvel ID utilisateur aux groupes d'administrateur :
net localgroup
Administrators ID_utilisateur /add
net localgroup DB2ADMNS user_ID /add
c. Connectez-vous à votre système à l'aide du nouvel ID utilisateur et
du nouveau mot de passe.
d. Pour tous les répertoires qui ont été créés pour l'instance de serveur,
assurez-vous que l'ID utilisateur de cette dernière permet d'y
accéder en lecture/écriture. Au nombre des répertoires à vérifier
figurent le répertoire d'instance et tous les répertoires de base de
données et de journaux.
2. Créez les répertoires nécessaires au serveur. Vérifiez que vous êtes connecté
avec l'ID utilisateur que vous avez créé.
Vous avez besoin d'un répertoire unique et vide pour chacun des éléments
présents dans le tableau suivant. Créez les répertoires de base de données, le
répertoire de journaux actif et le journal d'archivage sur différents volumes
physiques. Pour l'espace requis, voir «Feuille de calcul pour l'espace de
Tableau 41. Feuille de travail pour la création des répertoires requis

Exemples de commandes de
Elément création de répertoires Vos répertoires
Le répertoire d'instance du mkdir /home/user_ID/tsminst1
serveur, destiné à
contenir les fichiers de
cette instance de serveur,
y compris le fichier
d'options du serveur

Tableau 41. Feuille de travail pour la création des répertoires requis (suite)
Répertoires de base de mkdir /home/user_ID/tsmdb001
données mkdir /home/user_ID/tsmdb002
mkdir /home/user_ID/tsmdb003
Répertoire du journal mkdir /home/user_ID/tsmlog
actif
Répertoire du journal mkdir /home/user_ID/
d'archivage tsmarchlog
Facultatif : répertoire de mkdir /home/user_ID/
la copie miroir du tsmlogmirror
journal actif
Facultatif : répertoire du mkdir /home/user_ID/
journal d'archivage tsmarchlogfailover
secondaire qui est
l'emplacement de reprise
pour le journal
d'archivage
Windows

Le répertoire d'instance du mkdir d:\tsm\server1
Répertoires de base de mkdir d:\tsm\db001
données mkdir e:\tsm\db002
mkdir f:\tsm\db003
mkdir g:\tsm\db004
Répertoire du journal mkdir h:\tsm\log
actif
Répertoire du journal mkdir i:\tsm\archlog
d'archivage
Facultatif : répertoire de mkdir j:\tsm\logmirror
la copie miroir du
journal actif
Facultatif : répertoire du mkdir k:\tsm\archlogfailover
journal d'archivage
secondaire qui est
pour le journal
d'archivage
Lorsqu'un serveur est initialement créé, avec la fonctionnalité DSMSERV FORMAT

ou avec l'assistant de configuration, une base de données de serveur et un
journal de récupération sont également créés. De plus, des fichiers sont créés
pour contenir les informations de base de données utilisées par le gestionnaire
3. Créez des volumes logiques supplémentaires et montez les volumes sur les
répertoires qui ont été créés à l'étape précédente.
Poursuivez le processus de mise à niveau en vous aidant de l'une des rubriques

suivantes :
«Scénario 1: Mise à niveau du serveur par le biais de l'assistant de mise à
niveau»
«Scénario 1: Mise à niveau manuelle du serveur par le biais des utilitaires», à la
page 135
Tâches associées:
«Planification de l'espace nécessaire au processus de mise à niveau et au serveur
«Valeurs recommandées pour la dénomination d'un serveur», à la page 81
Scénario 1: Mise à niveau du serveur par le biais de l'assistant de

mise à niveau
L'assistant offre une approche guidée pour la mise à niveau d'un serveur. Le
recours à l'assistant permet d'éviter des étapes de configuration complexes
lorsqu'elles sont effectuées manuellement. Lancez l'assistant sur le système où vous
avez installé le programme du serveur version 6.3 ou ultérieure.
Avant de commencer la procédure de mise à niveau, vous devez exécuter toutes

les étapes précédentes de préparation de la mise à niveau, installer les utilitaires de
mise à niveau, installer le programme du serveur version 6.3 ou ultérieure et créer
les répertoires ainsi que l'ID utilisateur pour l'instance de serveur.
1. Vérifiez que les conditions requises ci-dessous sont remplies.
v Le client X Window doit être installé sur le système. Un serveur X

Window doit également être en cours d'exécution sur votre bureau.
v L'un des protocoles suivants doit être activé au niveau du système.
Assurez-vous que le port utilisé par le protocole n'est pas bloqué par
un pare-feu.
– Secure Shell (SSH). Vérifiez que le port affiche la valeur par défaut
(22). Vérifiez également que le service de démon SSH possède des
droits d'accès pour se connecter au système à l'aide de localhost.
– Remote shell (rsh).
– Protocole d'exécution éloigné (REXEC).
v Vous devez pouvoir vous connecter au système sous l'ID utilisateur
que vous avez créé pour l'instance du serveur en utilisant le
protocole SSH, RSH ou REXEC. Lorsque vous utilisez l'assistant,
vous devez fournir cet ID utilisateur et ce mot de passe pour accéder
à ce système.
Windows
v Le système sur lequel vous avez installé le programme du serveur

version6.3 ou ultérieure doit disposer du protocole Windows server

message block (SMB) activé. SMB est l'interface utilisée par File and
Print Sharing (également appelé CIFS). Pour utiliser le protocole
SMB, vous devez vérifier que le partage de fichiers et de
l'imprimante est activé et que le port 445 n'est pas bloqué par votre
pare-feu.
v Si le serveur V5 est installé sur un système différent de celui du
serveur version6.3 ou ultérieure, ce système doit également disposer
du protocole SMB activé.
v Vous devez pouvoir vous connecter au système disposant du
protocole SMB activé à l'aide de l'ID utilisateur créé pour l'instance
de serveur, ou à l'aide de l'ID utilisateur existant sur le système.
Lorsque vous utilisez l'assistant, vous devez fournir l'ID et le mot de
passe afin d'accéder au système.
2. Windows Si le système fonctionne sous Windows Server 2008 ou Windows
Vista, procédez comme suit pour désactiver la fonction User Account Control :
a. Assurez-vous que la fonction Remote Registry sous Windows Services est
lancée, et que les ports 445, 137, et 139 sont déverrouillés dans le pare-feu.
b. Configurez à la fois le serveur d'infrastructure et les systèmes cible en tant
que membres d'un domaine Windows. Servez-vous d'un compte utilisateur
de ce domaine ou d'un domaine sécurisé lorsque vous établissez la
connexion à la cible.
c. Connectez-vous au poste de travail cible en activant et en utilisant le
compte administrateur intégré. Pour activer le compte administrateur
intégré, cliquez sur Panneau de configuration > Outils d'administration >
Stratégies de sécurité locale > Paramètres de sécurité > Stratégies locales >
Options de sécurité. Double-cliquez sur la section Comptes : Etat du
compte Administrateur. Sélectionnez Autoriser et cliquez sur OK.
d. Cliquez sur Panneau de configuration > Outils d'administration >
Stratégie de sécurité locale > Paramètres de sécurité > Stratégies locales >
Options de sécurité. Double-cliquez sur la section Gestion du Compte
Utilisateur : Exécuter tous les administrateurs en mode Admin Approval.
Sélectionnez Désactiver et cliquez sur OK.
3. Lancez l'assistant de mise à niveau, dsmupgdx, à partir du répertoire
d'installation du serveur version 6.3 ou ultérieure.
Connectez-vous à l'aide de l'ID utilisateur root. Exécutez la commande :
/opt/tivoli/tsm/server/bin/dsmupgdx
Windows
Ouvrez une nouvelle fenêtre d'invite de commande et lancez la
commande suivante :
"c:\Program Files\Tivoli\TSM\server\dsmupgdx.exe"
4. Suivez les instructions permettant de terminer la mise à niveau. L'assistant de
mise à niveau peut être arrêté et redémarré, mais le serveur ne sera pas
opérationnel tant que le processus de mise à niveau n'est pas entièrement
terminé.
Important : Prenez connaissance de tous les messages qui s'affichent pour

chaque phase du processus de mise à niveau dans la zone prévue à cet effet
dans l'assistant. Les messages d'information peuvent indiquer des actions
survenues pendant le processus qui peuvent être importantes.
Pour mener à bien la mise à niveau, suivez les étapes décrites dans Chapitre 10,
«Exécution des premières étapes après la mise à niveau», à la page 355.
Scénario 1: Mise à niveau manuelle du serveur par le biais des

utilitaires
Utilisez les fonctionnalités pour mettre à jour le serveur à l'aide de l'interface de
commande.
Avant de démarrer la procédure de mise à niveau, vous devez effectuer toutes les
étapes précédentes pour préparer la mise à niveau. Assurez-vous que les
fonctionnalités de mise à niveau sont installées, de même que le programme
serveur V6.3 ou ultérieure et que vous avez créé les répertoires et un ID
d'utilisateur pour l'instance du serveur.
Exécutez les étapes suivantes :

1. «Scénario 1: Extraction des données sur des supports»
2. «Scénario 1: Création et formatage de la nouvelle base de données», à la page
136
3. «Scénario 1: Chargement des données extraites dans la nouvelle base de
4. «Scénario 1: Création d'un service Windows pour l'instance de serveur», à la
page 143
5. «Scénario 1: Configuration du système en vue de la sauvegarde de la base de
Après avoir configuré le système en vue de la sauvegarde de la base de données,

menez à bien la mise à niveau en suivant les étapes décrites dans Chapitre 10,
Concepts associés:
«Fichier manifeste pour l'extraction des données sur des supports», à la page 570
Scénario 1: Extraction des données sur des supports

Vous pouvez extraire les données depuis la base de données du serveur d'origine
vers des supports à accès séquentiel. Ces derniers peuvent correspondre à de
l'espace sur bande ou sur disque qui est défini avec la classe d'unités FILE.
Windows.
2. Vérifiez que l'unité que vous voulez utiliser pour stocker les données extraites
est disponible. La base de données du serveur et le fichier de configuration
d'unité doivent contenir une définition de classe d'unités valide pour l'unité.
3. A partir du répertoire de l'instance du serveur que vous mettez à niveau,
lancez la commande de démarrage de l'extraction. Dirigez la sortie du
processus vers un fichier à des fins de surveillance. Par exemple, exécutez la
commande suivante, sur une ligne :
AIX
nohup /usr/tivoli/tsm/upgrade/bin/dsmupgrd extractdb \

devclass=file manifest=./manifest.txt >extract.out 2>&1 &

HPUX Linux Solaris
nohup /opt/tivoli/tsm/upgrade/bin/dsmupgrd extractdb \

Windows
"c:\Program Files\Tivoli\TSM\upgrade\dsmupgrd" extractdb

devclass=file manifest=.\manifest.txt 1>>extract.out 2>&1
Conseil : Les messages émis au cours de l'opération d'extraction ne sont pas

sauvegardés dans le journal d'activité du serveur. Dirigez la sortie de l'utilitaire
vers un fichier, comme indiqué dans les exemples, afin d'enregistrer les
messages.
d'avertissement, ainsi que les éléments pouvant nécessiter une intervention. Un
message s'affichant juste avant la fin du processus indique la réussite ou l'échec
de l'opération :
Message de réussite : ANR1382I EXTRACTDB : le processus 1, l'extraction
de la base de données, est terminé.
Message d'échec : ANR1396E EXTRACTDB : le processus 1, l'extraction de
la base de données, est terminé mais des erreurs se sont produites.
Par exemple, dans le répertoire d'instance du serveur que vous mettez à
niveau, lancez la commande suivante afin de surveiller le processus :
tail -f extract.out
La durée du processus dépend de la taille de la base de données. Cette durée
sera approximativement équivalente à celle requise pour une sauvegarde

Concepts associés:
Tâches associées:
«Scénario 1: Préparation de l'espace pour le processus de mise à niveau», à la page
108
Scénario 1: Création et formatage de la nouvelle base de

données
Créez l'instance du serveur et formatez les fichiers pour une base de données
version 6.3 ou ultérieure vide.
1. Connectez-vous au système sur lequel vous avez installé le programme
Connectez-vous à l'aide de l'ID utilisateur root. Vérifiez les éléments
suivants :
v Le répertoire principal de l'utilisateur, /home/tsminst1, existe. S'il

n'existe pas de répertoire de base, vous devez le créer.
Le répertoire d'instance stocke les fichiers core suivants générés par
le serveur Tivoli Storage Manager :
– Le fichier d'options du serveur, dsmserv.opt
– Le fichier de base de données clés, cert.kdb, et le fichier .arm ,
utilisés par les clients et d'autres serveurs pour importer les
certificats Secure Sockets Layer du serveur
– Le fichier de configuration des unités, si l'option de serveur
DEVCONFIG ne spécifie pas de nom complet
– Le fichier de l'historique des volumes, si l'option de serveur
– Volumes des pools de stockage DEVTYPE=FILE si le répertoire
de la classe d'unités n'est pas complet ou qualifié complet
– Exits utilisateur
– Sortie de trace, s'il n'est pas pleinement qualifié
v un fichier de configuration shell, par exemple, .Le profil, existe
dans le répertoire principal. L'utilisateur root et l'identifiant
d'utilisateur d'instance doivent disposer d'une permission écrite
pour ce fichier. pour plus d'informations, reportez-vous à DB2
Information Center (http://pic.dhe.ibm.com/infocenter/db2luw/
v9r7), et recherchez des informations sur les paramètres
d'environnement variables Linux et UNIX.
Windows
2. Créez une instance Tivoli Storage Manager à l'aide de la commande db2icrt.
Entrez la commande suivante sur une seule ligne. Pour le nom
d'instance, indiquez l'ID utilisateur créé pour être propriétaire de
l'instance :
/opt/tivoli/tsm/db2/instance/db2icrt -a server -s ese -u

nom_instance nom_instance
Par exemple, si l'ID utilisateur pour cette instance est tsminst1, utilisez
la commande suivante pour créer l'instance :

tsminst1 tsminst1
A faire : A partir de ce point, utilisez ce nouvel ID utilisateur lors de

la configuration du Tivoli Storage Manager serveur. Déconnectez l'ID
utilisateur et connectez-vous à l'aide de l'ID utilisateur propriétaire de
l'instance.
Windows
Entrez la commande suivante sur une seule ligne. Le compte
utilisateur indiqué devient l'ID utilisateur propriétaire de la version6.3
ou ultérieure serveur; cet ID correspond à l'ID utilisateur de l'instance.
db2icrt -s ese -u compte_utilisateur nom_instance

Par exemple, si le compte utilisateur est tsminst1 et que l'instance de

serveur est Server1, entrez la commande suivante :
db2icrt -s ese -u tsminst1 server1
Le service de base de données pour l'instance de serveur se connecte

au compte utilisateur indiqué dans cette commande.
Utilisez le nom de la clé de registre du serveur version 5 comme nom

d'instance pour le serveur version 6.3 ou ultérieure. Vous êtes invité à
entrer le mot de passe pour le compte utilisateur.
Le nom d'instance que vous indiquez dans cette commande db2icrt
est celui que vous spécifierez ultérieurement à l'aide de l'option -k
dans la commande DSMSERV LOADFORMAT, lors de la création et du
formatage de la base de données et du journal de reprise.
3. Connectez-vous au système à l'aide de l'ID utilisateur possédant l'instance de
serveur version 6.3 ou ultérieure (ID utilisateur d'instance).
4. Copiez les fichiers de configuration dans le répertoire d'instance créé pour le
nouveau serveur. Il s'agit des fichiers de configuration que vous avez
sauvegardés à partir du serveur version 5 initial :
v Configuration d'unité
v Fichier d'options du serveur, généralement appelé dsmserv.opt
Par exemple, si vous avez créé le répertoire d'instance figurant dans l'exemple
lors de l'étape de création de répertoires pour le serveur version 6.3 ou
ultérieure, copiez les fichiers dans le répertoire suivant :
AIX HPUX Linux Solaris /tsminst1
Windowsd:\tsm\server1
Assurez-vous que l'ID utilisateur auquel appartient le serveur version 6.3 ou
ultérieure (ID utilisateur de l'instance) dispose de la propriété ou des droits de
lecture et d'écriture sur les fichiers que vous avez copiés.
5. Modifiez le fichier d'options du serveur.
a. Supprimez toute option non prise en charge pour la version 6.3 ou
ultérieure. Vous trouverez la liste des options supprimées, dans le
tableau 36, à la page 78.
b. Vérifiez que le fichier d'options du serveur contient au moins une option
VOLUMEHISTORY et au moins une option DEVCONFIG. Un fichier d'historique
des volumes et un fichier de configuration d'unité sont nécessaires, c'est
pourquoi vous devez restaurer la base de données, générer des copies
automatiques de ces fichiers pour être sûr de les avoir à disposition en cas
de besoin.
c. Vérifiez si le fichier d'options du serveur inclut l'option TXNGROUPMAX avec
une valeur définie et, si oui, vérifiez quelle est cette valeur. Vous pouvez
modifier la valeur courante, car la valeur par défaut pour cette option
passe de 256 à 4096 avec la version 6.3 ou ultérieure. L'augmentation de la
valeur peut améliorer les performance des opérations de transfert des
données, comme la migration d'un pool de stockage et la sauvegarde d'un
pool de stockage.
v Si le fichier d'options du serveur inclut cette option, le serveur utilise
automatiquement la nouvelle valeur par défaut : 4096.
v Si une valeur a été définie dans le fichier d'options du serveur pour
cette option, le serveur utilise cette valeur. Si la valeur indiquée est
inférieure à 4096, vous pouvez l'augmenter ou supprimer l'option afin

que le serveur utilise la nouvelle valeur par défaut.
6. Modifiez le chemin d'accès par défaut à la base de données.
Modifiez le chemin d'accès par défaut à la base de données afin qu'il
corresponde au répertoire d'instance du serveur. Exécutez la
commande suivante :
db2 update dbm cfg using dftdbpath répertoire_instance
Par exemple :
db2 update dbm cfg using dftdbpath /tsminst1
Windows
corresponde à l'unité sur laquelle se trouve le répertoire d'instance du
serveur. Effectuez les étapes suivantes :
a. Cliquez sur Démarrer > Programmes > IBM DB2 > DB2TSM1 >
outils de ligne de commande > Interpréteur de commandes.
b. Entrez quit pour sortir de l'interpréteur de commandes.
Une fenêtre contenant une invite de commande s'ouvre, avec
l'environnement configuré pour permettre de lancer les
commandes lors des étapes ultérieures.
c. A partir de l'invite de commande de cette fenêtre, lancez la
commande suivante afin de définir la variable d'environnement
pour l'instance de serveur avec laquelle vous travaillez :
set
db2instance=nom_instance
Le nom indiqué par nom_instance est identique à celui que vous

avez indiqué lorsque vous avez lancé la commande db2icrt. Par
exemple, pour définir la variable d'environnement pour l'instance
de serveur Server1, lancez la commande suivante :
set db2instance=server1
d. Lancez la commande suivante pour définir l'unité par défaut :
db2 update dbm cfg using dftdbpath emplacement_instance
Par exemple, si le répertoire d'instance est d:\tsm\server1,

l'emplacement de l'instance est l'unité d:. Entrez la commande :
db2 update dbm cfg using dftdbpath d:
7. Modifiez le chemin d'accès à la bibliothèque pour utiliser la version d' IBM
Global Security Kit (GSKit) installée avec le Tivoli Storage Manager serveur :
AIX Exécutez la commande suivante :
export LIBPATH=/usr/opt/ibm/gsk8_64/lib64:$LIBPATH
AIX HPUX Linux Vous devez mettre à jour les fichiers
Solaris
suivants pour définir le chemin d'accès à la bibliothèque DB2 lorsque Tivoli
Storage Manager le serveur démarre :
v répertoire_instance/sqllib/usercshrc
v répertoire_instance/sqllib/userprofile
Pour le fichier répertoire_instance/sqllib/usercshrc, ajoutez les lignes
suivantes :

v AIX
setenv LIBPATH /usr/opt/ibm/gsk8_64/lib64:$LIBPATH

v HPUX Solaris
setenv LD_LIBRARY_PATH /opt/ibm/gsk8_64/lib64:$LD_LIBRARY_PATH

v Linux
setenv LD_LIBRARY_PATH /usr/local/ibm/gsk8_64/lib64:$LD_LIBRARY_PATH

Pour le fichier répertoire_instance/sqllib/userprofile, ajoutez les lignes
suivantes :
v AIX
LIBPATH=/usr/opt/ibm/gsk8_64/lib64:$LIBPATH
export LIBPATH
v HPUX Solaris
LD_LIBRARY_PATH=/opt/ibm/gsk8_64/lib64:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH
v Linux
LD_LIBRARY_PATH=/usr/local/ibm/gsk8_64/lib64:$LD_LIBRARY_PATH
Vérifiez les paramètres de chemin d'accès à la bibliothèque et assurez-vous
que la version GSKit est la version 8.0.14.14 ou une version ultérieure. Emettez
les commandes suivantes :
v AIX
echo $LIBPATH
gsk8capicmd_64 -version
gsk8ver_64
v HPUX Linux Solaris
echo $LD_LIBRARY_PATH
gsk8ver_64
Si la version GSKit ne correspond pas à la version 8.0.14.14 ou une version
ultérieure, vous devez reinstaller le Tivoli Storage Manager serveur. La
réinstallation permet de s'assurer que la version GSKit correcte est disponible.
8. Effectuez cette étape pour définir la page de code du serveur.
Affectez à la variable d'environnement système DB2CODEPAGE la valeur 819
pour chaque instance de serveur. Avant de lancer la commande DSMSERV
LOADFORMAT, connectez-vous au système en tant que propriétaire d'instance et
exécutez la commande suivant :
db2set
-i nom_instance DB2CODEPAGE=819
Par exemple : AIX HPUX Linux Solaris
db2set -i tsminst1 DB2CODEPAGE=819
Windows
db2set -i server1 DB2CODEPAGE=819

9. Accédez au répertoire d'instance que vous avez créé pour le serveur.
10. Créez et formatez la base de données et les journaux de reprise. Dans la
commande, indiquez les répertoires que vous avez créés pour la base de
données et les journaux. Les répertoires doivent être vides.
Par exemple, pour obtenir une taille de journal actif de 16 Go (16384

Mo, la taille par défaut), lancez la commande suivante, sur une seule
ligne :
/opt/tivoli/tsm/server/bin/dsmserv loadformat \
dbdir=/tsmdb001,/tsmdb002,/tsmdb003,/tsmdb004 \
activelogsize=16384 activelogdirectory=/tsmlog \
mirrorlogdirectory=/tsmlogmirror archlogdirectory=/tsmarchlog
Windows

Mo, la taille par défaut), pour l'instance de serveur Server1, lancez la
commande suivante, sur une seule ligne :
"c:\Program Files\Tivoli\TSM\server\dsmserv" loadformat
dbdir=d:\tsm\db001,e:\tsm\db002,f:\tsm\db003,g:\tsm\db004
activelogsize=16384 activelogdirectory=h:\tsm\log
mirrorlogdirectory=j:\tsm\logmirror archlogdirectory=i:\tsm\archlog
Si le serveur que vous mettez à niveau n'est pas Server1, vous devez
utiliser l'option -k. L'option -k indique le nom d'instance pour
l'exécution de cet utilitaire. Par exemple, si le système comporte
plusieurs instances de serveur et que l'instance mise à niveau est
Server2, lancez la commande suivante :
"c:\Program Files\Tivoli\TSM\server\dsmserv" -k server2
loadformat dbdir=d:\tsm\db001,e:\tsm\db002,f:\tsm\db003,g:\tsm\db004
Important : L'instance de serveur que vous indiquez doit être passée

par toutes les étapes précédentes du processus de mise à niveau, y
compris la création de l'instance de base de données (commande
db2icrt).
Tâches associées:
«Commandes, utilitaires et options de serveur supprimés», à la page 75
Scénario 1: Chargement des données extraites dans la

nouvelle base de données
Après avoir formaté une base de données vide via l'utilitaire DSMSERV LOADFORMAT,
chargez les données que vous avez extraites de la base de données de serveur
d'origine.
Avant de commencer à charger les données, vérifiez que les conditions requises
ci-après sont remplies :
v Le fichier manifeste de l'opération DSMUPGRD EXTRACTDB doit être disponible.
v Le fichier d'options du serveur doit contenir une entrée pour le fichier de

v Le fichier de configuration d'unité doit disposer des informations sur la classe

d'unités spécifiée dans le fichier manifeste.
v Le support contenant la base de données extraites doit être disponible pour le
serveur version 6.3 ou ultérieure. L'unité doit être physiquement attachée au
système. Les autorisations doivent être définies pour accorder l'accès au support
à l'ID utilisateur auquel appartient l'instance de serveur version 6.3 ou
ultérieure.
Effectuez les étapes suivantes :

1. Vérifiez que le serveur version 6.3 ou ultérieure peut accéder aux données
extraites.
v Si les données extraites sont stockées sur bande, l'unité de bande doit être
connectée au système.
v Si les données extraites ont été stockées à l'aide d'une classe d'unités FILE ou
DISK, procédez comme suit :
a. Connectez-vous au système avec l'ID de superutilisateur.
b. Assurez-vous que l'ID utilisateur auquel appartient le serveur version 6.3
ou ultérieure (ID utilisateur de l'instance) dispose de la propriété ou des
droits de lecture et d'écriture sur les fichiers extraits.
2. Pour le fichier manifeste qui a été créé par le processus d'extraction, vérifiez
que l'ID utilisateur d'instance dispose de la propriété ou de la permission de
lecture/écriture.
3. Connectez-vous à l'aide de l'ID utilisateur instance.
4. Sur le serveur de version 6.3 ou ultérieure, procédez comme suit :
a. Vérifiez que le fichier d'options du serveur version 5 inclut l'option
DEVCONFIG et que cette dernière indique le chemin complet du fichier de
b. Vérifiez que le fichier de configuration d'unité est disponible dans le
serveur version 5 à l'emplacement indiqué par l'option DEVCONFIG.
c. Vérifiez que les droits sur le fichier de configuration d'unité autorise l'accès
en lecture pour l'ID utilisateur de l'instance.
5. Vérifiez que le contenu du fichier de configuration d'unité est correct. La classe
d'unités qui a été utilisée pour l'étape d'extraction est enregistrée dans le fichier
manifeste et elle doit exister et être valide sur le système version 6.3 ou
ultérieure.
a. Vérifiez les entrées correspondant aux classes d'unités de type FILE. Par
exemple, les chemins peuvent être différents sur le système.
b. Vérifiez les entrées concernant les unités de bande et d'autres unités. Par
exemple, les noms d'unité peuvent avoir changé.
| 6. Vérifiez les contenus du fichier manifeste et modifiez-le si nécessaire :
| a. Vérifiez que les noms d'unité du fichier manifeste sont valides pour le
| système V6.3 ou ultérieure. Les noms pour un même périphérique peuvent
| être différent sur des systèmes V5 et V6.
| b. Assurez-vous que le fichier manifeste contient une liste des volumes à
| utiliser lors du chargement des données extraites dans la nouvelle base de
| données. Par exemple, si le fichier manifeste contient une liste des volumes
| appartenant à une classe d'unités de type FILE, assurez-vous que le chemin
| complet des volumes est correct pour le système.
7. Lancez la commande DSMSERV INSERTDB pour charger une base de données de
serveur extraite dans la base de données préparée vide version 6.3 ou
ultérieure. Dirigez la sortie du processus vers un fichier à des fins de

surveillance. Par exemple, exécutez la commande suivante, sur une seule ligne :
nohup /opt/tivoli/tsm/server/bin/dsmserv insertdb \

manifest=./manifest.txt >insert.out 2>&1 &
Windows
"c:\Program Files\Tivoli\TSM\server\dsmserv" insertdb \

manifest=.\manifest.txt 1>>insert.out 2>&1
8. Surveillez le processus afin d'identifier les messages d'erreur et les messages
d'avertissement, ainsi que les éléments pouvant nécessiter une intervention. Le
système affiche des statistiques temporaires sur l'opération de chargement de
base de données. Toutefois, il peut y avoir des périodes durant lesquelles aucun
message n'est généré. Durant ce temps, les opérations DB2 s'exécutent en
arrière-plan. La durée du processus dépend de la taille de la base de données.
Pour plus d'informations, voir «Exemple - Estimation de la durée de mise à
niveau en fonction de la taille de la base de données», à la page 51.
Facultatif : vérifiez que la base de données est chargée en surveillant le
processeur et la présence des entrées-sorties pour le processus du serveur et le
processus DB2 correspondant. Par exemple, exécutez la commande suivante
pour surveiller le processus :
tail -f insert.out
Conseil : Windows Sur des systèmes Windows, utilisez la commande tail ou

un utilitaire équivalent permettant de surveiller le contenu d'un fichier qui
change. Par exemple, Windows Server 2003 Resource Kit Tools inclut la
commande tail qui peut être utilisée comme indiqué dans l'exemple.
Un message généré par la commande DSMSERV INSERTDB indique l'état de
l'opération :
Message de réussite : ANR1395I INSERTDB : le processus 1, l'insertion
Message d'échec : ANR1396E INSERTDB : le processus 1, l'insertion de
9. Si vous avez utilisé une unité de bande, une fois l'opération d'insertion
terminée, supprimez ou ou extrayez de la bibliothèque la bande contenant les
données extraites. Empêchez la réutilisation de la bande jusqu'à ce que vous
soyez sûr ne pas avoir à répéter l'opération d'insertion.
Concepts associés:
Scénario 1: Création d'un service Windows pour l'instance de

serveur
Windows
Si vous utilisez l'assistant de mise à niveau (dsmupgdx), un service Windows est

automatiquement créé pour le serveur Tivoli Storage Manager version 6.3 ou
ultérieure. Si vous n'utilisez pas l'assistant de mise à niveau, vous devez créer
manuellement le service Windows pour le serveur Tivoli Storage Manager.

1. Accédez au répertoire d'installation du programme du serveur. Par défaut, ce

répertoire est le suivant : C:\Program Files\Tivoli\TSM\console. Si vous avez
installé le serveur dans un répertoire différent, accédez au sous-répertoire
console du répertoire d'installation du serveur.
2. Installez le service Windows en indiquant le nom d'instance et le mot de passe
du serveur Tivoli Storage Manager dans le nom du service. Exécutez la
commande suivante :
install
"TSM nom_instance_serveur"
"C:\Program Files\Tivoli\TSM\server\dsmsvc.exe"
instance_owner instance_owner_password
où :
"TSM nom_instance_serveur" est le nom du service en cours d'installation.
nom_instance_serveur est le nom de l'instance indiquée lors de l'exécution
de la commande db2icrt.
instance_owner est le compte du propriétaire d'instance ; ce compte
comprend le service.
instance_owner_password est le mot de passe du compte du propriétaire
d'instance.
Exemple
Pour installer le service Windows pour l'instance de serveur server1,
exécutez la commande suivante sur une ligne. L'exemple utiliserudy
comme propriétaire d'instance et s21ret comme mot de passe pour le
compte du propriétaire d'instance.
install "TSM server1" "C:\Program Files\Tivoli\TSM\server\dsmsvc.exe"
rudy s21ret
3. Facultatif : Utilisez les outils d'administration Windows (Outils
d'administration > Services) pour modifier manuellement le service et indiquer
un type de démarrage automatique.
Tâches associées:
Scénario 1: Configuration du système en vue de la

sauvegarde de la base de données
Le gestionnaire de base de données et l'API Tivoli Storage Manager doivent être
configurés de sorte que celui-ci puisse sauvegarder la base de données du serveur.
La configuration s'effectue automatiquement si vous utilisez l'assistant de mise à
niveau (dsmupgdx). Si vous n'utilisez pas l'assistant vous devez effectuer la
configuration manuellement.
v «Scénario 1: Configuration du système pour la sauvegarde de base de données
sur des systèmes AIX, HP-UX, Linux et Oracle Solaris», à la page 145
sur des systèmes Microsoft Windows», à la page 147

Scénario 1: Configuration du système pour la sauvegarde de

base de données sur des systèmes AIX, HP-UX, Linux et Oracle
Solaris
Si vous n'avez pas utilisé l'assistant de mise à niveau, vous devez terminer la
configuration de sauvegarde de base de données manuellement.
Dans les étapes ci-après, tsminst1 correspond à l'ID utilisateur de l'instance de

serveur et /tsminst1 au répertoire de l'instance de serveur Tivoli Storage Manager.
1. Configurez la variable d'environnement de l'API Tivoli Storage Manager pour
l'instance de base de données :
a. Connectez-vous en utilisant l'ID utilisateur tsminst1.
b. Lorsque l'utilisateur tsminst1 est connecté, assurez-vous que
l'environnement DB2 est correctement initialisé. L'environnement DB2 est
initialisé via l'exécution du script /home/tsminst1/sqllib/db2profile, qui
s'exécute normalement depuis le profil de l'ID utilisateur. Si
/home/tsminst1/.profile n'exécute pas le script db2profile,ajoutez les lignes
suivantes à /home/tsminst1/.profile:
if [ -f /home/tsminst1/sqllib/db2profile ]; then
. /home/tsminst1/sqllib/db2profile
fi
| c. Dans le fichier userprofile du répertoire /home/tsminst1/sqllib directory,
| ajoutez ou mettez à jour les lignes suivantes :
| AIX Shell Korn ou Bash :
| export DSMI_CONFIG=/home/tsminst1/tsminst1/tsmdbmgr.opt
| export DSMI_DIR=/usr/tivoli/tsm/client/api/bin64
| export DSMI_LOG=/home/tsminst1/tsminst1
| HPUX Linux Solaris Shell Korn ou Bash :
| export DSMI_DIR=/opt/tivoli/tsm/client/api/bin64
| AIX Shell Bourne :
| DSMI_CONFIG=/home/tsminst1/tsminst1/tsmdbmgr.opt
| DSMI_DIR=/usr/tivoli/tsm/client/api/bin64
| DSMI_LOG=/home/tsminst1/tsminst1
| export DSMI_CONFIG DSMI_DIR DSMI_LOG
| HPUX Linux Solaris Shell Bourne :
| DSMI_DIR=/opt/tivoli/tsm/client/api/bin64
| AIX Shell C :
| setenv DSMI_CONFIG=/home/tsminst1/tsminst1/tsmdbmgr.opt
| setenv DSMI_DIR=/usr/tivoli/tsm/client/api/bin64
| setenv DSMI_LOG=/home/tsminst1/tsminst1
| HPUX Linux Solaris Shell C :
| setenv DSMI_DIR=/opt/tivoli/tsm/client/api/bin64
2. Déconnectez-vous, puis reconnectez-vous sous tsminst1 ou exécutez la
commande suivante :
. ~/.profile

| Conseil : Veillez à insérer un espace après le point initial (.) caractère.

3. Créez un fichier nommé tsmdbmgr.opt dans le répertoire /tsminst1 et ajoutez la
ligne suivante :
SERVERNAME TSMDBMGR_TSMINST1
A faire : Le nom utilisé doit être identique à celui de l'instance de serveur.

4. Ajoutez les lignes suivantes au fichier de configuration dsm.sys de l'API Tivoli
Storage Manager. Le fichier de configuration dsm.sys se trouve à l'emplacement
par défaut suivant :
AIX /usr/tivoli/tsm/client/api/bin64
HPUX Linux Solaris /opt/tivoli/tsm/client/api/bin64/dsm.sys
Evitez de placer le nom du serveur, TSMDBMGR_TSMINST1, en première
position dans le fichier dsm.sys car sinon, il constituerait la valeur par défaut
du système. Dans cet exemple, les lignes ajoutées se trouvent après la section
correspondant à server_a.
Servername server_a
COMMMethod TCPip
TCPPort 1500
TCPServeraddress node.domain.company.COM
servername TSMDBMGR_TSMINST1
commmethod tcpip
tcpserveraddr localhost
tcpport 1500
passwordaccess generate
passworddir /home/tsminst1/tsminst1
errorlogname /home/tsminst1/tsminst1/tsmdbmgr.log
nodename $$_TSMDBMGR_$$
Conseil : Assurez-vous que vous entrez la même valeur tcpport qui est utilisée
par le serveur. Cette valeur est spécifiée dans le fichier dsmserv.opt.
5. Arrêtez et démarrez l'instance de base de données :
a. Arrêtez DB2:
db2stop
b. Démarrez DB2:
db2start
6. Définissez le mot de passe de l'API :
a. Vérifiez que le serveur Tivoli Storage Manager est démarré. Voir
«Démarrage du serveur sur des systèmes AIX, HP-UX, Linux et Oracle
Solaris», à la page 357 pour plus d'informations.
b. Connectez-vous à l'aide de l'ID utilisateur root.
| c. Définissez la source du profil du gestionnaire de base de données en
| exécutant la commande suivante. Assurez-vous d'avoir fait entré un point,
| un espace et le chemin d'accès au fichier db2profile. Si vous n'insérez pas
| l'espace, la sauvegarde de la base de données échoue.
| Important : Solaris Accédez au shell Korn (/bin/ksh) avant d'exécuter la

| commande suivante.
| . /home/tsminst1/sqllib/db2profile
d. Modifiez le mot de passe de l'API. Utilisez la commande suivante :
/home/tsminst1/sqllib/adsm/dsmapipw
e. Lorsque vous y êtes invité par la commande dsmapipw, indiquez TSMDBMGR

comme mot de passe initial et nouveau mot de passe.
f. Entrez la commande de système d'exploitation suivante :
rm /home/tsminst1/tsminst1/tsmdbmgr.log


base de données sur des systèmes Microsoft Windows
Windows
Windows Dans les commandes suivantes, les exemples utilisent serveur1 pour
l'instance de base de données et d:\tsmserver1 pour le répertoire de serveur Tivoli
Storage Manager. Remplacez ces valeurs par vos valeurs dans les commandes.
1. Créez le fichier tsmdbmgr.env dans le répertoire d:\tsmserver1 avec le contenu
suivant :
DSMI_CONFIG=d:\tsmserver1\tsmdbmgr.opt
DSMI_LOG=d:\tsmserver1
2. Configurez la variable d'environnement de l'API DSMI_ pour l'instance de base
de données :
a. Ouvrez une fenêtre de commande DB2. Pour ce faire, accédez au répertoire
C:\Program Files\Tivoli\TSM\db2\bin ou si vous avez installé Tivoli
Storage Manager à un emplacement différent, accédez au sous-répertoire
db2\bin du répertoire d'installation principal. Puis, exécutez la commande
suivante :
db2cmd
b. Exécutez cette commande :
db2set -i server1 DB2_VENDOR_INI=d:\tsmserver1\tsmdbmgr.env
3. Créez le fichier tsmdbmgr.opt dans le répertoire d:\tsmserver1 avec le contenu
suivant :
*************************************************
commmethod tcpip
tcpport 1500
errorlogname d:\tsmserver1\TSMDBMGR_TSMSERVER1.log
a. Ouvrez une fenêtre de commande DB2. Pour cela, vous pouvez accéder au
répertoire C:\Program Files\Tivoli\TSM\db2\bin ou si vous avez installé
Tivoli Storage Manager à un emplacement différent, accédez au
sous-répertoire db2\bin dans votre répertoire d'installation principal. Puis,
exécutez la commande suivante :
db2cmd
b. Définissez l'instance de base de données :

c. Arrêtez DB2:
db2stop
d. Démarrez DB2:
db2start
5. Entrez la commande suivante sur une ligne :
"c:\program files\tivoli\tsm\server\dsmsutil.exe"
UPDATEPW /NODE:$$_TSMDBMGR_$$ /PASSWORD:TSMDBMGR /VALIDATE:NO /OPTFILE:
"d:\tsmserver1\tsmdbmgr.opt"

Chapitre 5. Scénario 2 : Même système, via le réseau
méthode de réseau pour le transfert de données.

4. «Scénario 2: Désinstallation du programme version 5 avant l'installation de V6.3
ou d'une version ultérieure », à la page 167
5. «Scénario 2: Installation du serveur V6.3 ou d'une version ultérieure», à la page
169
6. «Scénario 2: Création des répertoires et de l'ID utilisateur pour l'instance de
serveur mise à niveau», à la page 175
la page 180
356
page 363
page 364


ses données.


page 154
page 156
page 157
158
Tâches associées:

mise à niveau
serveur.


ultérieure
(IA64)
(IA64)
IBM POWER IBM POWER
Chapitre 5. Scénario 2 : Même système, via le réseau 151

| à la page 385.

ultérieure.
Manager version 5
à la page 475.
4. Vérifiez que la mémoire système est conforme aux exigences du serveur.

v Vérifiez que la mémoire système est suffisante pour exécuter deux serveurs
simultanément.
Lorsque vous exécutez le processus qui extrait la base de données du serveur
existant et l'insère sur le nouveau serveur, l'effet net est que deux serveurs
s'exécutent simultanément. La mémoire système doit être suffisante pour
gérer ces processus.
v Si vous prévoyez d'exécuter plusieurs instances du serveur V6.3 ou ultérieure
sur le système, chacune d'elles requiert le volume mémoire répertorié pour
un seul serveur. Multipliez la mémoire destinée à un serveur par le nombre
d'instances planifiées pour le système.





38
Vérifiez que le système dispose d'un espace de stockage sur disque suffisant
pour stocker la base de données et les journaux de reprise pour les serveurs V5
et V6.3 ou ultérieure.
et mis en service.

Concepts associés:

mise à niveau
Vérifiez que l'espace disque du système correspond à celui estimé lors de l'étape
de planification. Utilisez les feuilles de calcul de planification que vous complétez
avec vos informations. Voir «Feuille de calcul pour l'espace de planification du
serveur V6.3 ou ultérieure», à la page 50.
Tâches associées:


update stgpool
Solaris


suivante :
query session


cancel session all

base de données.

pool_copie



NODELOCK

serveur.

1. Sauvegardez les informations de configuration des unités en utilisant la
commande administrative Tivoli Storage Manager :
où file_name désigne le fichier destiné au stockage des informations de

configuration des unités.
2. Sauvegardez les informations sur l'historique en utilisant la commande Tivoli
Storage Manager administrative :
où file_name désigne le fichier destiné au stockage des informations sur

l'historique des volumes. Assurez-vous que l'historique des volumes inclut les
Examinez la sortie de requête pour vérifier que l'horodatage pour la

sauvegarde de base de données correspondant à l'heure de la sauvegarde.
3. Enregistrez les copies des fichiers suivants qui se trouvent dans le répertoire
v Fichier d'option de serveur, généralement renommé dsmserv.opt
v dsmserv.dsk

5. Sauvegardez n'importe quel script qui utilisé pour terminer le nettoyage
quotidien du serveur. Consultez les scripts afin d'identifier les changements
6. Stocker le fichier de configuration d'unité, le fichier historique des volumes, le
fichier d'options du serveur et les autres fichiers dans un emplacement sûr.
Assurez-vous que les fichiers sont stockés sur un système différent à partir d'un
système en cours de mise à niveau ou sur un support hors ligne.

de données



niveau
query process
d'administration.
suivantes :
query mount
halte

Vous devez installer les utilitaires de mise à niveau sur le système. Le module
d'installation des utilitaires doit être téléchargé sur un site Web.

| la page 42.

systèmes AIX», à la page 159

Concepts associés:

des systèmes AIX
AIX
d'origine.
gsksa.rte 7.0.4.11
fichiers :
lslpp -L xlC.rte
lslpp -L gsksa.rte

server/v5r5/AIX/


Available Software.
répertoire.
sur Echap+4.

régionaux.

des systèmes HP-UX
HPUX
d'origine.

version 5.
gzip
d'exploitation.
suivante :

commande suivante :

régionaux.



des systèmes Linux
Linux
d'origine.
suivante :
version 5.
commande suivante :
upgrade/bin.


régionaux.

Solaris
d'origine.
version 5.


d'exploitation.
suivante :

upgrade/bin.
pkgadd
nom_module

régionaux.


AIX
HPUX Linux Solaris



Après avoir défini les variables d'environnement, poursuivez avec «Scénario 2:

niveau», à la page 166.

Windows
d'origine.
Une fois les utilitaires de mise à niveau installés, poursuivez avec «Scénario 2:
niveau», à la page 166.

Utilisez l'option -o avec la commande DSMUPGRD pour indiquer l'emplacement du
fichier d'options du serveur.
Scénario 2: Préparation de la base de données sur un serveur version

5 en vue de la mise à niveau
Windows.
serveur.

AIX
HPUX Linux Solaris

Windows


tail -f prepare.out

Scénario 2: Désinstallation du programme version 5 avant l'installation

de V6.3 ou d'une version ultérieure

v AIX «Scénario 2: Désinstallation du programme version 5 sur des systèmes
AIX»
v HPUX «Scénario 2: Désinstallation du programme version 5 sur des systèmes
HP-UX», à la page 168
v Linux «Scénario 2: Désinstallation du programme version 5 sur des systèmes
Linux», à la page 168
v Solaris «Scénario 2: Désinstallation du programme version 5 sur des systèmes
Oracle Solaris», à la page 169
v Windows «Scénario 2: Désinstallation du programme version 5 sur des systèmes

systèmes AIX
AIX

serveur.



169.

systèmes HP-UX
HPUX

serveur.

169.

systèmes Linux
Linux

serveur.
rpm -e TIVsm-server

169.

systèmes Oracle Solaris
Solaris

serveur.



systèmes Microsoft Windows
Windows

serveur.

programmes.
soient supprimés.

Scénario 2: Installation du serveur V6.3 ou d'une version ultérieure





licence.

suivantes :
Linux
Il va s’arrêter.
Solaris
n'est pas définie.
Windows
ce répertoire.
Windows

exécutable.

suivante :
chmod
a+x nom_module.bin

CZ1N1ML.
./nom_module.bin

Windows

exécutable.

nom_module.exe


comme suit :
graphique :
./prereqcheck.bin

prereqcheck.exe

page 43.

./install.bin
Windows

install.exe



maintenance/server.
si nécessaire.
HPUX


système.

Linux
d'installation.
Solaris
système.

Concepts associés:
Scénario 2: Création des répertoires et de l'ID utilisateur pour

l'instance de serveur mise à niveau

ultérieure.


suivantes :
d'exploitation.
AIX

# passwd tsminst1
HPUX
# groupadd tsmsrvrs
# passwd tsminst1
Linux
# groupadd tsmsrvrs
# passwd tsminst1
Solaris

# groupadd tsmsrvrs
# passwd tsminst1
nécessaire.
Windows

net

net localgroup


actif
journal actif
secondaire qui est
pour le journal
d'archivage
Windows

mkdir f:\tsm\db003
mkdir g:\tsm\db004
actif
d'archivage
la copie miroir du
journal actif

journal d'archivage
secondaire qui est
pour le journal
d'archivage


suivantes :
«Scénario 2: Mise à niveau du serveur par le biais de l'assistant de mise à
niveau»
«Scénario 2: Mise à niveau manuelle du serveur par le biais des utilitaires», à la
page 180
Tâches associées:

mise à niveau

v Le client X Window doit être installé sur le système. Un serveur X

Window doit également être en cours d'exécution sur votre bureau.
un pare-feu.

v Vous devez pouvoir vous connecter au système sous l'ID utilisateur
que vous avez créé pour l'instance du serveur en utilisant le
protocole SSH, RSH ou REXEC. Lorsque vous utilisez l'assistant,
à ce système.
Windows

pare-feu.
Windows
commande suivante :

terminé.


utilitaires
commande.

1. «Scénario 2: Création et formatage de la nouvelle base de données»
2. «Scénario 2: Transfert de la base de données du serveur via un réseau», à la
page 185
page 187

Concepts associés:

données
suivants :

Windows
l'instance :


tsminst1 tsminst1

l'instance.
Windows




de besoin.
pool de stockage.

commande suivante :
Par exemple :
Windows
set


Solaris
suivantes :

v AIX

v HPUX Solaris

v Linux

suivantes :
v AIX
export LIBPATH
v HPUX Solaris
v Linux
v AIX
echo $LIBPATH
gsk8ver_64
gsk8ver_64
db2set
Windows


ligne :
Windows


db2icrt).
Tâches associées:
Scénario 2: Transfert de la base de données du serveur via un

réseau
Déplacez la base de données en démarrant le processus d'insertion du serveur V6.3
ou ultérieure pour accepter la base de données du serveur. Ensuite, démarrez le
processus d'extraction du serveur V5 pour extraire et envoyer la base de données.
Avant de lancer cette procédure, vérifiez que le serveur version 5 et le nouveau

serveur ne sont pas en cours d'exécution.
1. Démarrez le processus d'insertion sur le serveur version 6.3 ou ultérieure en
vue d'accepter la base de données. Pour surveiller le processus, dirigez sa sortie
vers un fichier. Par exemple, démarrez le serveur en respectant un délai de 60
minutes (durée par défaut) nécessaire à l'établissement d'une connexion entre le

serveur version 6.3 ou ultérieure et en dirigeant la sortie du processus vers le

fichier insert.out à l'aide de la commande ci-dessous :

sesswait=60 >insert.out 2>&1 &
Windows
"c:\Program Files\Tivoli\TSM\server\dsmserv" insertdb

sesswait=60 1>>insert.out 2>&1
Le serveur démarre et attend 60 minutes, le temps qu'il soit contacté par le

serveur d'origine. Les messages peuvent ne pas être traités pendant une
certaine période. Pendant cette période, les opérations DB2 s'exécutent en
arrière-plan. Facultatif : Pour vérifier que les opérations se poursuivent comme
prévu, surveillez l'utilisation de l'unité centrale et de l'E-S pour le processus du
serveur et le processus DB2 correspondant.
2. Surveillez la sortie du processus DSMSERV INSERTDB. Vérifiez que le processus
DSMSERV INSERTDB a émis le message suivant avant de passer à l'étape suivante :
ANR1336I INSERTDB: Serveur source prêt pour les connexions
Pour surveiller la sortie du processus dans le fichier insert.out, exécutez la

commande suivante :
tail -f insert.out

3. Démarrez l'extraction à partir du serveur d'origine. Indiquez l'adresse TCP/IP
et le port du serveur version 6.3 ou ultérieure. Dirigez la sortie du processus
vers un fichier à des fins de surveillance. Par exemple, exécutez la commande
suivante, sur une seule ligne :
AIX

hladdress=127.0.0.1 lladdress=1500 >extract.out 2>&1 &
HPUX Linux Solaris

Windows
"c:\Program Files\Tivoli\TSM\upgrade\dsmupgrd" extractdb hladdress=127.0.0.1

lladdress=1500 1>>extract.out 2>&1
4. Surveillez les processus des messages d'erreur et d'avertissemen ainsi que tous
les éléments que vous devez peut-être traiter. A partir du répertoire de
l'instance du serveur que vous mettez à niveau, lancez la commande suivante
pour surveiller le processus d'extraction :
tail -f extract.out
La durée du processus dépend de la taille de la base de données, du matériel

utilisé et du réseau.
5. Examinez les résultats des processus d'extraction et d'insertion pour consulter
les messages indiquant la réussite ou l'échec des opérations.
Processus Message de réussite Message d'échec

Extraction ANR1382I EXTRACTDB : le ANR1396E EXTRACTDB : le
processus 1, l'extraction de la processus 1, l'extraction de la
base de données, est terminé. base de données, est terminé
mais des erreurs se sont
produites.
Insertion ANR1395I INSERTDB : le ANR1396E INSERTDB : le
processus 1, l'insertion de la processus 1, l'insertion de la
produites.

serveur
Windows

commande suivante :
install
où :
d'instance.
Exemple


rudy s21ret
Tâches associées:

sur des systèmes AIX, HP-UX, Linux et Oracle Solaris»


Solaris

fi

| AIX Shell C :
commande suivante :
. ~/.profile

ligne suivante :

Servername server_a
COMMMethod TCPip
TCPPort 1500
commmethod tcpip
tcpport 1500

a. Arrêtez DB2:
db2stop
b. Démarrez DB2:
db2start



Windows
suivant :
de données :

suivante :
db2cmd
suivant :
*************************************************
commmethod tcpip
tcpport 1500
db2cmd
c. Arrêtez DB2:
db2stop
d. Démarrez DB2:
db2start


Chapitre 6. Scénario 3 : Nouveau système, via des supports
méthode de support pour le transfert de données.

la page 221
356
page 363
page 364


ses données.


page 197
page 201
page 202
202
Tâches associées:

mise à niveau
serveur.

ultérieure
(IA64)
(IA64)
IBM POWER IBM POWER
Chapitre 6. Scénario 3 : Nouveau système, via des supports 195

| à la page 385.

ultérieure.
Manager version 5
à la page 475.







38
et mis en service.
6. Vérifiez que le nouveau système peut accéder aux unités de stockage utilisées
sur le système d'origine. Cela inclut les unités de disque et de bande utilisées
pour stocker les données client.
Il peut s'avérer nécessaire de laisser une unité de stockage connectée au
système d'origine pour effectuer l'extraction de la base de données. Transférez
ensuite l'unité de stockage vers le nouveau système.
Concepts associés:

mise à niveau
2. Vérifiez que vous avez de l'espace disponible pour stocker la base de données
et le fichier manifeste créé par le processus d'extraction.



système en cours.
données.
utilisateur root.
Tâches associées:

update stgpool
AIX HPUX Linux Solaris Placez cette option dans le fichier



suivante :
query session
cancel session all

base de données.

pool_copie



NODELOCK

serveur.

1. Sauvegardez les informations de configuration du périphérique à l'aide de la
commande d'administration Tivoli Storage Manager :
où file_name indique le fichier dans lequel stocker les informations de

configuration du périphérique.
2. Sauvegardez les informations de l'historique du volume à l'aide de la

l'historique du volume. Assurez-vous que l'historique des volumes inclut les
Vérifiez la sortie de la requête pour s'assurer que l'horodatage de la sauvegarde

de base de données correspond à la durée réelle de la sauvegarde.
3. Sauvegardez les copies des fichiers suivants qui se trouvent dans le répertoire
v Fichier d'options de serveur, généralement nommé dsmserv.opt
v dsmserv.dsk



5. Sauvegardez tous les scripts utilisés pour effectuer le nettoyage quotidien du
serveur. Consultez les scripts afin d'identifier les changements nécessaires une
fois la mise à niveau terminée.
6. Enregistrez dans un endroit sûr le fichier de configuration d'unité, le fichier
historique des volumes, le fichier d'options et tout autre fichier requis.
Assurez-vous que les fichiers sont stockés dans un système différent de celui en
cours de mise à niveau, ou sur un support hors connexion.

de données


niveau
query process
d'administration.
suivantes :
query mount
halte

Vous devez installer les utilitaires de mise à niveau sur le système où se trouve le
serveur version 5. Le module d'installation des utilitaires doit être téléchargé sur
un site Web.

| la page 42.

v AIX«Scénario 3: Installation des utilitaires de mise à niveau sur des
systèmes AIX»
v Windows«Scénario 3: Installation des utilitaires de mise à niveau sur des
Concepts associés:

des systèmes AIX
AIX
Installez les utilitaires de mise à niveau sur le système où le serveur version 5 est
installé. Le module à installer peut être téléchargé à partir du site des
téléchargements FTP. Les utilitaires de mise à niveau servent à préparer et à
extraire la base de données à partir du serveur d'origine.

gsksa.rte 7.0.4.11
fichiers :
lslpp -L xlC.rte
lslpp -L gsksa.rte

server/v5r5/AIX/
Available Software.
répertoire.
sur Echap+4.

régionaux.
16. Une fois les utilitaires de mise à niveau installés, reprenez à l'étape «Scénario
3: Paramétrage des variables d'environnement pour les utilitaires de mise à

des systèmes HP-UX
HPUX
version 5.
gzip
d'exploitation.
suivante :


commande suivante :

régionaux.
7. Une fois les utilitaires de mise à niveau installés, reprenez à l'étape «Scénario 3:

des systèmes Linux
Linux
suivante :
version 5.
commande suivante :
upgrade/bin.

régionaux.

Solaris


version 5.
d'exploitation.
suivante :

upgrade/bin.
pkgadd
nom_module


régionaux.


AIX
HPUX Linux Solaris



Une fois les variables d'environnement définies, poursuivez le processus de mise à

niveau en vous aidant de l'une des rubriques suivantes :
v «Scénario 3: Mise à niveau manuelle du serveur par le biais des utilitaires», à la
page 221

Windows


Restriction : N'installez pas les utilitaires dans le même répertoire que le

serveur d'origine à mettre à niveau. Installez-les dans un répertoire distinct.
Une fois les utilitaires de mise à niveau installés, poursuivez le processus de mise à
niveau»
page 221
serveurs sont exécutés sur le système, vous devez utiliser l'option -k pour
indiquer le nom de la clé de registre Windows à partir de laquelle extraire les
informations relatives au serveur mis à niveau. La valeur par défaut de l'option
est SERVER1.

mise à niveau
Avant de commencer la procédure suivante, vous devez exécuter toutes les étapes
précédentes de préparation de la mise à niveau et installer les utilitaires de mise à
niveau.
Avant de démarrer l'assistant de mise à niveau, vérifiez que le serveur version 6.3
ou ultérieure est installé et que les répertoires et l'ID utilisateur ont été créés.
1. Scénario 3: Installation du serveur V6.3 ou d'une version ultérieure
2. Scénario 3: Création des répertoires et de l'ID utilisateur pour l'instance de
serveur mise à niveau
3. «Scénario 3: Démarrage de l'assistant de mise à niveau», à la page 219
Scénario 3, assistant: Installation du serveur V6.3 ou d'une

version ultérieure



suivantes :
Linux
Il va s’arrêter.
Solaris
n'est pas définie.

Windows
ce répertoire.
Windows

exécutable.

suivante :
chmod
a+x nom_module.bin

CZ1N1ML.
./nom_module.bin

Windows


exécutable.

nom_module.exe

comme suit :
graphique :
./prereqcheck.bin

prereqcheck.exe

page 43.

./install.bin

Windows

install.exe



maintenance/server.
si nécessaire.
HPUX
système.

Linux
d'installation.
Solaris


système.

Concepts associés:
Scénario 3, assistant: Création des répertoires et de l'ID

utilisateur pour l'instance de serveur mise à niveau

ultérieure.


suivantes :
d'exploitation.
AIX

# passwd tsminst1
HPUX
# groupadd tsmsrvrs
# passwd tsminst1
Linux
# groupadd tsmsrvrs
# passwd tsminst1
Solaris
# groupadd tsmsrvrs
# passwd tsminst1
nécessaire.
Windows

net



net localgroup

actif
journal actif
secondaire qui est
pour le journal
d'archivage
Windows

mkdir f:\tsm\db003
mkdir g:\tsm\db004
actif
d'archivage
la copie miroir du
journal actif
journal d'archivage
secondaire qui est
pour le journal
d'archivage

Tâches associées:
Scénario 3: Démarrage de l'assistant de mise à niveau




version 6.3 ou ultérieure doit disposer du client X Window. Un
serveur X Window doit également être en cours d'exécution sur votre
bureau.
v L'un des protocoles suivants doit être activé au niveau des systèmes.
un pare-feu.
v Vous devez pouvoir vous connecter au système version 6.3 ou
ultérieure sous l'ID utilisateur que vous avez créé pour l'instance du
serveur en utilisant le protocole SSH, RSH ou REXEC. Lorsque vous
utilisez l'assistant, vous devez fournir cet ID utilisateur et ce mot de
passe pour accéder à ce système.
Windows

pare-feu.

Windows
commande suivante :
terminé.


utilitaires
commande.
niveau.

2. «Scénario 3: Extraction des données sur des supports», à la page 223
232
6. «Scénario 3: Chargement des données extraites dans la nouvelle base de
page 239


Concepts associés:
Scénario 3: Préparation de la base de données sur un serveur

version 5 en vue de la mise à niveau
Windows.
serveur.

AIX
HPUX Linux Solaris

Windows

tail -f prepare.out

Scénario 3: Extraction des données sur des supports

Windows.
AIX

HPUX Linux Solaris

Windows


messages.
de l'opération :


tail -f extract.out

Concepts associés:
Tâches associées:
«Scénario 3: Préparation de l'espace pour le processus de mise à niveau», à la page
197
Scénario 3, manuel: Installation du serveur V6.3 ou d'une

version ultérieure


suivantes :
Linux
Il va s’arrêter.
Solaris
n'est pas définie.
Windows
ce répertoire.
Windows

exécutable.

suivante :
chmod
a+x nom_module.bin

CZ1N1ML.
./nom_module.bin

Windows


exécutable.

nom_module.exe

comme suit :
graphique :
./prereqcheck.bin

prereqcheck.exe

page 43.


./install.bin
Windows

install.exe



WindowsLe répertoire choisi pour l'installation (recherchez les fichiers
maintenance/server.
si nécessaire.
HPUX
système.

Linux

d'installation.
Solaris
système.

Concepts associés:
Scénario 3, manuel: Création des répertoires et de l'ID


ultérieure.


suivantes :


d'exploitation.
AIX

# passwd tsminst1
HPUX
# groupadd tsmsrvrs
# passwd tsminst1
Linux
# groupadd tsmsrvrs
# passwd tsminst1
Solaris
# groupadd tsmsrvrs
# passwd tsminst1
nécessaire.
Windows

net

net localgroup

actif
journal actif
secondaire qui est
pour le journal
d'archivage
Windows


mkdir f:\tsm\db003
mkdir g:\tsm\db004
actif
d'archivage
la copie miroir du
journal actif
journal d'archivage
secondaire qui est
pour le journal
d'archivage

Tâches associées:

données
suivants :

Windows
l'instance :


tsminst1 tsminst1

l'instance.
Windows




de besoin.
pool de stockage.

commande suivante :
Par exemple :
Windows
set


Solaris
suivantes :

v AIX

v HPUX Solaris

v Linux

suivantes :
v AIX
export LIBPATH
v HPUX Solaris
v Linux
v AIX
echo $LIBPATH
gsk8ver_64
gsk8ver_64
db2set
Windows


ligne :
Windows

Si vous avez déjà créé la première instance de serveur sur le système
(server1) et voulez en créer d'autres, vous devez utiliser l'option -k.
L'option -k indique le nom d'instance pour l'exécution de cet utilitaire.
Par exemple, si le nom d'instance pour le serveur est server2, lancez la
commande :
Tâches associées:
Scénario 3: Chargement des données extraites dans la

nouvelle base de données
d'origine.

ultérieure.

extraites.
v Si les données extraites ont été stockées à l'aide d'une classe d'unités FILE ou
DISK, procédez comme suit :
b. Assurez-vous que l'ID utilisateur auquel appartient le serveur version 6.3
ou ultérieure (ID utilisateur de l'instance) dispose de la propriété ou des
droits de lecture et d'écriture sur les fichiers extraits.
2. Connectez-vous avec l'ID utilisateur de l'instance au système sur lequel vous
avez installé le serveur version 6.3 ou ultérieure.
| 3. Copiez le fichier manifeste qui a été créé par le processus d'extraction vers le
| système version 6.3 ou ultérieure. Assurez-vous que l'ID utilisateur d'instance
| est propriétaire de ou possède des droits en lecture/écriture pour le fichier
| manifeste.
5. Vérifiez que le contenu du fichier de configuration d'unité est correct. La classe
d'unités qui a été utilisée pour l'étape d'extraction est enregistrée dans le fichier
manifeste et elle doit exister et être valide sur le système version 6.3 ou
ultérieure.
| appartenant à une classe d'unités de type FILE, assurez-vous que le chemin
| complet des volumes est correct pour le système.
surveillance. Par exemple, exécutez la commande suivante, sur une seule ligne :

Windows

base de données. Toutefois, il peut y avoir des périodes durant lesquelles aucun
message n'est généré. Durant ce temps, les opérations DB2 s'exécutent en
arrière-plan. La durée du processus dépend de la taille de la base de données.
Pour plus d'informations, voir «Exemple - Estimation de la durée de mise à
niveau en fonction de la taille de la base de données», à la page 51.
tail -f insert.out

l'opération :
9. Si vous avez utilisé une unité de bande, une fois l'opération d'insertion
terminée, supprimez ou ou extrayez de la bibliothèque la bande contenant les
données extraites. Empêchez la réutilisation de la bande jusqu'à ce que vous
Concepts associés:

serveur
Windows



commande suivante :
install
où :
d'instance.
Exemple
rudy s21ret
Tâches associées:



Solaris

fi
| AIX Shell C :
commande suivante :
. ~/.profile

ligne suivante :


Servername server_a
COMMMethod TCPip
TCPPort 1500
commmethod tcpip
tcpport 1500
a. Arrêtez DB2:
db2stop
b. Démarrez DB2:
db2start



Windows
suivant :
de données :
suivante :
db2cmd
suivant :
*************************************************
commmethod tcpip
tcpport 1500
db2cmd
c. Arrêtez DB2:
db2stop
d. Démarrez DB2:
db2start



Chapitre 7. Scénario 4 : Nouveau système, via le réseau
méthode de réseau pour le transfert de données.

la page 272
356
page 363
page 364


ses données.


page 249
page 252
page 253
253
Tâches associées:

mise à niveau
serveur.

ultérieure
(IA64)
(IA64)
IBM POWER IBM POWER
Chapitre 7. Scénario 4 : Nouveau système, via le réseau 247

| à la page 385.

ultérieure.
Manager version 5
à la page 475.







38
et mis en service.
6. Vérifiez que le nouveau système peut accéder aux unités de stockage utilisées
sur le système d'origine. Cela inclut les unités de disque et de bande utilisées
pour stocker les données client.
Concepts associés:

mise à niveau
Vérifiez que l'espace disque du système correspond à celui estimé lors de l'étape
de planification. Utilisez les feuilles de calcul de planification que vous complétez
avec vos informations. Voir «Feuille de calcul pour l'espace de planification du
serveur V6.3 ou ultérieure», à la page 50.
Tâches associées:



update stgpool

Solaris


suivante :
query session
cancel session all

base de données.

pool_copie





NODELOCK

serveur.

1. Sauvegardez les informations de configuration du périphérique à l'aide de la

configuration du périphérique.
2. Sauvegardez les informations de l'historique du volume à l'aide de la

l'historique du volume. Assurez-vous que l'historique des volumes inclut les
Vérifiez la sortie de la requête pour s'assurer que l'horodatage de la sauvegarde

de base de données correspond à la durée réelle de la sauvegarde.
3. Sauvegardez les copies des fichiers suivants qui se trouvent dans le répertoire
v Fichier d'options de serveur, généralement nommé dsmserv.opt
v dsmserv.dsk

5. Sauvegardez tous les scripts utilisés pour effectuer le nettoyage quotidien du
serveur. Consultez les scripts afin d'identifier les changements nécessaires une
fois la mise à niveau terminée.

de données


niveau
query process


d'administration.
suivantes :
query mount
halte

un site Web.

| la page 42.

systèmes AIX»
Concepts associés:

des systèmes AIX
AIX

gsksa.rte 7.0.4.11
fichiers :
lslpp -L xlC.rte
lslpp -L gsksa.rte

server/v5r5/AIX/
Available Software.
répertoire.
sur Echap+4.


régionaux.

des systèmes HP-UX
HPUX
version 5.

gzip
d'exploitation.
suivante :

commande suivante :

régionaux.

des systèmes Linux
Linux


suivante :
version 5.
commande suivante :
upgrade/bin.

régionaux.

Solaris
version 5.
d'exploitation.
suivante :

upgrade/bin.

pkgadd
nom_module

régionaux.


AIX
HPUX Linux Solaris



Une fois les variables d'environnement définies, poursuivez le processus de mise à


page 272

Windows

Une fois les utilitaires de mise à niveau installés, poursuivez le processus de mise à
page 272
serveurs sont exécutés sur le système, vous devez utiliser l'option -k pour
indiquer le nom de la clé de registre Windows à partir de laquelle extraire les
informations relatives au serveur mis à niveau. La valeur par défaut de l'option
est SERVER1.


mise à niveau
niveau.
Avant de démarrer l'assistant de mise à niveau, vérifiez que le serveur version 6.3
ou ultérieure est installé et que les répertoires et l'ID utilisateur ont été créés.
3. «Scénario 4: Démarrage de l'assistant de mise à niveau», à la page 271
Scénario 4, assistant: Installation du serveur V6.3 ou d'une

version ultérieure



suivantes :
Linux

Il va s’arrêter.
Solaris
n'est pas définie.
Windows
ce répertoire.
Windows

exécutable.

suivante :
chmod
a+x nom_module.bin


CZ1N1ML.
./nom_module.bin

Windows

exécutable.

nom_module.exe

comme suit :
a. AIX HPUX Linux Exécutez cette commande pour
Solaris
graphique :
./prereqcheck.bin

prereqcheck.exe


page 43.

./install.bin
Windows

install.exe



maintenance/server.
si nécessaire.
HPUX
système.

Linux

d'installation.
Solaris
système.

Concepts associés:
Scénario 4, assistant: Création des répertoires et de l'ID


ultérieure.


suivantes :


d'exploitation.
AIX

# passwd tsminst1
HPUX
# groupadd tsmsrvrs
# passwd tsminst1
Linux
# groupadd tsmsrvrs
# passwd tsminst1
Solaris
# groupadd tsmsrvrs
# passwd tsminst1
nécessaire.
Windows


net

net localgroup

actif
journal actif

secondaire qui est
pour le journal
d'archivage
Windows

mkdir f:\tsm\db003
mkdir g:\tsm\db004
actif
d'archivage
la copie miroir du
journal actif
journal d'archivage
secondaire qui est
pour le journal
d'archivage

Tâches associées:
Scénario 4: Démarrage de l'assistant de mise à niveau



bureau.
v L'un des protocoles suivants doit être activé au niveau des systèmes.
un pare-feu.
v Vous devez pouvoir vous connecter au système version 6.3 ou
ultérieure sous l'ID utilisateur que vous avez créé pour l'instance du
serveur en utilisant le protocole SSH, RSH ou REXEC. Lorsque vous
utilisez l'assistant, vous devez fournir cet ID utilisateur et ce mot de
passe pour accéder à ce système.
Windows

pare-feu.


Windows
commande suivante :
terminé.


utilitaires
commande.
niveau.

de la mise à niveau»
283
5. «Scénario 4: Transfert de la base de données du serveur via un réseau», à la
page 288
page 289

Concepts associés:
Scénario 4: Préparation de la base de données sur un serveur

version 5 en vue de la mise à niveau
Windows.
serveur.

AIX
HPUX Linux Solaris


Windows

tail -f prepare.out

Scénario 4, manuel: Installation du serveur V6.3 ou d'une

version ultérieure



suivantes :

Linux
Il va s’arrêter.
Solaris
n'est pas définie.
Windows
ce répertoire.
Windows

exécutable.


suivante :
chmod
a+x nom_module.bin

CZ1N1ML.
./nom_module.bin

Windows

exécutable.

nom_module.exe

comme suit :
graphique :
./prereqcheck.bin


prereqcheck.exe

page 43.

./install.bin
Windows

install.exe




maintenance/server.
si nécessaire.
HPUX
système.


Linux
d'installation.
Solaris
système.

Concepts associés:
Scénario 4, manuel: Création des répertoires et de l'ID


ultérieure.



suivantes :
d'exploitation.
AIX

# passwd tsminst1
HPUX
# groupadd tsmsrvrs
# passwd tsminst1
Linux
# groupadd tsmsrvrs
# passwd tsminst1
Solaris
# groupadd tsmsrvrs
# passwd tsminst1
nécessaire.
Windows


net

net localgroup


actif
journal actif
secondaire qui est
pour le journal
d'archivage
Windows

mkdir f:\tsm\db003
mkdir g:\tsm\db004
actif
d'archivage
la copie miroir du
journal actif
journal d'archivage
secondaire qui est
pour le journal
d'archivage

Tâches associées:

données
suivants :
Windows


l'instance :


tsminst1 tsminst1

l'instance.
Windows



Windows d:\tsm\server1

de besoin.
pool de stockage.
commande suivante :
Par exemple :
Windows
set



Solaris
suivantes :
v AIX

v HPUX Solaris

v Linux

suivantes :
v AIX
export LIBPATH
v HPUX Solaris
v Linux
v AIX
echo $LIBPATH
gsk8ver_64
gsk8ver_64
db2set
Windows


ligne :
Windows

Si vous avez déjà créé la première instance de serveur sur le système
(server1) et voulez en créer d'autres, vous devez utiliser l'option -k.
L'option -k indique le nom d'instance pour l'exécution de cet utilitaire.
Par exemple, si le nom d'instance pour le serveur est server2, lancez la
commande :

Tâches associées:
Scénario 4: Transfert de la base de données du serveur via un

réseau
Déplacez la base de données en démarrant le processus d'insertion du serveur V6.3
ou ultérieure pour accepter la base de données du serveur. Ensuite, démarrez le

1. Vérifiez qu'une connexion réseau correcte est établie entre les deux systèmes.

Windows



commande suivante :
tail -f insert.out

AIX

HPUX Linux Solaris

Windows

tail -f extract.out


produites.
produites.

serveur
Windows



commande suivante :
install
où :
d'instance.
Exemple
rudy s21ret
Tâches associées:



Solaris

fi
| AIX Shell C :
commande suivante :
. ~/.profile

ligne suivante :


Servername server_a
COMMMethod TCPip
TCPPort 1500
commmethod tcpip
tcpport 1500
a. Arrêtez DB2:
db2stop
b. Démarrez DB2:
db2start



Windows
suivant :
de données :
suivante :
db2cmd
suivant :
*************************************************
commmethod tcpip
tcpport 1500
db2cmd
c. Arrêtez DB2:
db2stop
d. Démarrez DB2:
db2start



Chapitre 8. Environnements en cluster : Procédures de mise à
niveau
Pour mettre à niveau un serveur IBM Tivoli Storage Manager de V5 à V6.3 ou
ultérieure dans un environnement en cluster, vous devez compléter les tâches de
programmation, de préparation, d'installation et de configuration. Les procédures
varient, en fonction du système d'exploitation et de la version.
Suivez la procédure de votre système d'exploitation, de votre édition source et de

votre édition cible :
Système d'exploitation Edition source et cible Procédure

AIX De V5.5 à V6.3 ou ultérieure «Mise à niveau du serveur
V6.3 ou ultérieure dans un
environnement de cluster
AIX»
Windows De V5.5 à V6.3.3 ou une «Mise à niveau du serveur à
version ultérieure V6.3.3 ou une version
ultérieure dans un
environnement Windows en
cluster», à la page 297
Windows De V5.5 à V6.3.2 ou une «Mise à niveau du serveur
version antérieure V6.3.2 ou d'une version
antérieure dans un
environnement de cluster
Windows», à la page 299
Pour obtenir des informations sur la mise à niveau du serveur, de V6.1 ou V6.2 à
V6.3 ou ultérieure dans un environnement en cluster, voir le Guide d'installation.
Pour obtenir des informations sur les environnements en cluster Linux, voir le
Guide d'installation.
Mise à niveau du serveur V6.3 ou ultérieure dans un environnement de

cluster AIX
AIX
Pour mettre à niveau Tivoli Storage Manager la version V5.5 vers V6.3 ou
ultérieure dans un environnement de cluster de haute disponibilité sur un système
d'exploitation AIX, plusieurs étapes sont requises.

1. Installez toutes les ressources partagées sur un seul noeud. Il s'agit du noeud
principal. Si votre environnement comprend plusieurs instances de Tivoli
Storage Manager, les ressources partagées pour toutes les instances doivent être
accessibles au noeud principal au cours de la mise à niveau.
2. Procédez à une mise à niveau de la version 5 à le version 6.3 ou ultérieure.
Utilisez l'une des méthodes suivantes pour chaque instance :

v Chapitre 5, «Scénario 2 : Même système, via le réseau», à la page 149
Lorsque vous créez et configurez les instances DB2, utilisez l'assistant de mise à
niveau ou la méthode manuelle. Vérifiez que vous n'avez pas configuré
l'instance de serveur pour qu'elle démarre automatiquement après un
redémarrage système. Une fois l'assistant de mise à niveau exécuté, l'instance
démarre.
3. Ajustez les scripts de démarrage et d'arrêt du cluster pour utiliser les
répertoires d'instance corrects. Chaque instance a besoin de son propre
ensemble de scripts. Tivoli Storage Manager La version 6.3 utilise un canevas
de script de démarrage et d'arrêt différent de la version 5.5. Utilisez la
commande suivante de la version 6.3 :
v /opt/tivoli/tsm/server/bin/startserver
v /opt/tivoli/tsm/server/bin/stopserver
4. Testez les scripts de démarrage et d'arrêt pour vérifier qu'ils fonctionnent
comme prévu.
5. Sur le noeud principal, arrêtez toutes les instances de serveur.
6. Pour chaque noeud secondaire, exécutez les tâches suivantes :
a. Installez le serveur version 6.3 ou ultérieure. Pour plus d'informations, voir
«Installation du serveur V6.3 ou d'une version ultérieure», à la page 329.
b. Créez les répertoires et l'ID utilisateur de l'instance de serveur mise à
niveau. Pour plus d'informations, voir «Création des répertoires et de l'ID
utilisateur pour l'instance de serveur mise à niveau», à la page 334.
c. Installez toutes les ressources partagées sur toutes les instances de serveur
du noeud secondaire.
d. En tant que superutilisateur, exécutez l'assistant de configuration :
/opt/tivoli/tsm/server/bin/dsmicfgx. Indiquez le répertoire d'instance
correct pour chaque instance de serveur. Cochez la case pour indiquer que
l'instance de serveur est configurée pour un noeud secondaire d'un cluster
de grande disponibilité. En cochant cette case, vous créez les instances de
base de données requises et vous classez la base de données dans chaque
instance.
e. Ajustez les scripts de démarrage et d'arrêt du cluster pour utiliser les
répertoires d'instance corrects. Chaque instance a besoin de son propre
ensemble de scripts. Utilisez la commande suivante de la version 6.3 :
/opt/tivoli/tsm/server/bin/startserver
/opt/tivoli/tsm/server/bin/stopserver
f. Testez les scripts de démarrage et d'arrêt pour vérifier qu'ils fonctionnent
comme prévu.
Après la mise à niveau, effectuez les tâches de vérification et de configuration.

Pour plus d'informations, voir Chapitre 10, «Exécution des premières étapes après
la mise à niveau», à la page 355.
Pour plus d'informations sur la configuration des environnements en cluster,

consultez la section sur la configuration d'un environnement AIX en cluster dans
Mise à niveau du serveur à V6.3.3 ou une version ultérieure dans un
environnement Windows en cluster
Windows
Pour mettre à niveau le serveur Tivoli Storage Manager de V5.5 à V6.3.3 ou

version ultérieure dans un environnement de cluster sur un système Windows,
revisez les directives de planification. Ensuite, installez V6.3.3 ou une version de
serveur ultérieure sur tous les noeuds du cluster. Enfin, exécutez l'assistant de mise
à niveau qui comprend la nouvelle base de données et configure le système.
Effectuez les tâches suivantes :

1. Planifiez la mise à niveau, telle que décrite dans «Planification de la mise à
niveau».
2. Préparez le système puis exécutez l'assistant de mise à niveau, tel que décrit
dans «Préparation du système et exécution de l'assistant de mise à niveau».
Pour plus d'informations sur la configuration d'un environnement de cluster

Windows, consultez la section sur la configuration d'un environnement de cluster
Windows dans Guide d'administration.
Planification de la mise à niveau

Windows
Avant de mettre à niveau le serveur de V5.5 à V6.3.3 ou une version ultérieure

dans un environnement en cluster sur un système Windows, planifiez la mise à
niveau.

1. Examinez les instructions de configuration du cluster. Si vous effectuez la mise
à niveau sur le même système, assurez-vous que l'environnement en cluster est
correctement configuré. Si vous effectuez la mise à niveau sur un nouveau
système, configurez les noeuds du cluster puis créez un groupe de ressources.
Pour plus de détails, voir la section sur la configuration des environnements en
cluster dans le Guide d'administration. Des informations sur les exigences du
groupement, les instructions d'installation du serveur et des emplacements de
répertoire sont disponibles.
2. Déterminez s'il faut mettre à niveau le serveur à l'aide de la méthode de réseau
ou de support. Pour obtenir une comparaison de la méthode de réseau et de
celle de support, voir «Comparaison de la mise à niveau sur un système
existant et sur un nouveau système», à la page 14.
Après avoir programmé la mise à niveau, complétez les étapes dans «Préparation
du système et exécution de l'assistant de mise à niveau».
Préparation du système et exécution de l'assistant de mise à

niveau
Windows
Pour préparer le système pour la mise à niveau, installez le serveur de version

6.3.3 ou version suivante sur tous les noeuds du cluster et créez les répertoires et
Chapitre 8. Environnements de cluster : Procédures de mise à niveau 297

l'ID utilisateur correspondant à l'instance de serveur mise à niveau. Exécutez
ensuite l'assistant de mise à niveau, qui insère la nouvelle base de données et
configure le système.
licence.
| Vous pouvez mettre à niveau le serveur sur le même système ou migrer le serveur
| vers un nouveau système cible avec un nouveau système d'exploitation. Avant
| d'effectuer une mise à niveau ou une migration du serveur, vérifiez que Microsoft
| Windows Server 2008, Microsoft Windows Server 2008 R2, ou Microsoft Windows
| Server 2012 est installé sur le système cible. Vous pouvez utiliser Windows Server
| 2012 uniquement si vous effectuez une mise à niveau ou une migration du système
| vers la version Tivoli Storage Manager 6.3.4 ou une version ultérieure.
Pour préparer le système et exécuter l'assistant de mise à niveau, procédez comme

suit :
1. Si vous effectuez une mise à niveau ou migration d'un serveur vers Windows
Server 2012, installez le serveur d'automatisation du cluster de basculement
ainsi que l'interface de commande du cluster de basculement. Pour installer
ces composants, exécutez les commandes suivantes depuis Windows 2.0
PowerShell :
| Install-WindowsFeature -Name RSAT-Clustering-AutomationServer
| Install-WindowsFeature -Name RSAT-Clustering-CmdInterface
2. Vérifiez que le serveur version 5.5 possède un historique des volumes ainsi
que des fichiers de configuration d'unité.
3. Si vous effectuez la mise à niveau sur le même système, supprimez les
ressources de cluster de version 5.5 :
a. Vérifiez que le noeud principal contient les ressources de cluster.
b. A l'aide de Microsoft Failover Cluster Manager, enregistrez les valeurs de
l'adresse TCP/IP et le nom de réseau des éléments de serveur de groupe.
Le groupe de cluster comprend les ressources de serveur et de disque
Tivoli Storage Manager. Les ressources de serveur sont le nom de réseau
dans la section Server Name (Nom de serveur) et l'instance Tivoli Storage
Manager dans la section Other Resources (Autres ressources).
c. Supprimez la ressource Tivoli Storage Manager et le nom réseau.
4. Si vous effectuez la mise à niveau sur le même système, désinstallez le
serveur version 5.5. Pour chaque noeud du cluster, désinstallez le serveur
version 5.5, la licence de serveur et le pilote de périphérique. Ne supprimez
pas la base de données, le journal de reprise, le fichier d'options de serveur ou
tout autre fichier ou répertoire associé.
Pour plus d'informations sur la désinstallation du serveur, voir
«Désinstallation du programme version 5 sur des systèmes Microsoft
Windows», à la page 328.
5. Modifiez le fichier d'options du serveur version 5.5 :
a. Supprimez toute option non prise en charge pour la version 6.3. Pour
obtenir une liste des options supprimées, voir «Commandes, utilitaires et
options de serveur supprimés», à la page 75.
VOLUMEHISTORY et au moins une option DEVCONFIG. Un fichier historique de
volumes et un fichier de configuration des unités sont nécessaires pour
restaurer la base de données.
c. Déterminez si le fichier d'options du serveur inclut l'option TXNGROUPMAX
avec une valeur. Si l'option est incluse et que la valeur est inférieure à
4096, vous pouvez augmenter la valeur ou supprimer l'option afin que le
serveur utilise la nouvelle valeur par défaut. L'augmentation de la valeur
peut améliorer les performance des opérations de transfert des données,
comme la migration d'un pool de stockage et la sauvegarde d'un pool de
stockage.
6. Utilisez un assistant d'installation ou la console pour installer le serveur Tivoli
Storage Manager version 6.3.3 ou version suivante sur tous les noeuds qui
doivent faire partie du cluster. Pour plus d'informations, voir «Installation du
serveur V6.3 ou d'une version ultérieure», à la page 329.
7. Préparez le système pour la mise à niveau en créant les répertoires et l'ID
utilisateur correspondant à l'instance de serveur mise à niveau. L'ID utilisateur
de l'instance doit être défini pour le contrôleur de domaine. Pour plus
d'informations, voir «Création des répertoires et de l'ID utilisateur pour
l'instance de serveur mise à niveau», à la page 334. Créez les répertoires dont
l'instance de serveur a besoin pour la base de données et les fichiers journaux
de reprise uniquement sur les unités partagées, comme identifié dans la table
de cette section. Exécutez cette opération sur le noeud principal.
8. Démarrez l'assistant de mise à niveau sur le noeud principal en émettant la
commande suivante :
Suivez les étapes de l'assistant de mise à niveau. Lorsque vous êtes invité à
entrer un ID utilisateur pour la connexion au service de serveur, entrez le
domaine et l'ID utilisateur au format suivant : domain\userid. Lorsque vous
êtes invité à sélectionner les noeuds du cluster, sélectionnez le noeud principal
et tous les autres noeuds à inclure. Lorsque vous êtes invité à spécifier les
répertoires de l'instance, la base de données et les journaux, spécifiez les
répertoires se trouvant sur un disque partagé. Passez en revue les sélections
dans le panneau Summary (Récapitulatif). Si celles-ci sont correctes, cliquez
sur Suivant pour formater et insérer la base de données.
9. Si le système comprend plusieurs instances de serveur à mettre à niveau,
exécutez l'assistant de mise à niveau pour chaque instance.
Une fois que vous avez suivi les étapes de l'assistant de mise à niveau, la mise
à niveau est terminée et le système est configuré. Le serveur est démarré
automatiquement.
10. Facultatif : si la mise à niveau a été effectuée sur le système existant,
supprimez les fichiers de base de donnéesTivoli Storage Manager V5.5.
Mise à niveau du serveur V6.3.2 ou d'une version antérieure dans un

environnement de cluster Windows
Windows

Pour mettre à niveau Tivoli Storage Manager le serveur V5.5 vers une version 6.3.2
ou une version antérieure dans un environnement de cluster Windows, plusieurs
tâches doivent être effectuées.
Effectuez les tâches qui sont décrites dans les rubriques suivantes :
1. «Planification de la mise à niveau»
2. «Préparation de la mise à niveau»
3. «Installation du serveur et chargement de la base de données», à la page 302
4. «Configuration du serveur», à la page 304
Pour plus d'informations sur la configuration d'un environnement de cluster

Windows, consultez la section sur la configuration d'un environnement de cluster
Windows dans Guide d'administration.
Planification de la mise à niveau

Windows
Pour planifier la mise à niveau du serveur version 5.5 vers la version 6.3.2 dans un
environnement de cluster d'un système d'exploitation Windows, suivez les
instructions de configuration du cluster et les procédures manuelles de mise à
niveau. Ensuite, sélectionnez la méthode et le scénario de mise à niveau.
1. Suivez les instructions de configuration du cluster. Pour plus de détails,
consultez la section sur la configuration des environnements de cluster dans
Guide d'administration. Vous pouvez trouver des informations sur les
configurations de cluster, les instructions d'installation, ainsi que les
emplacements de répertoire.
2. Suivez les procédures de mise à niveau manuelle. Pour plus d'informations sur
les mises à niveau manuelles, consultez «Mise à niveau manuelle du serveur
par le biais des utilitaires», à la page 339.
3. Déterminez s'il faut mettre à niveau le serveur à l'aide de la méthode de réseau
ou de support. Pour obtenir une comparaison de la méthode de réseau et de
celle de support, voir «Comparaison de la mise à niveau sur un système
existant et sur un nouveau système», à la page 14.
4. Sélectionnez un scénario de mise à niveau. Pour plus d'informations concernant
les scénarios de mise à niveau, consultez Chapitre 3, «Présentation des
scénarios de mise à niveau», à la page 85.
Après avoir planifié la mise à niveau, suivez les étapes décrites dans «Préparation
de la mise à niveau».
Préparation de la mise à niveau

Windows
Pour préparer le système à une mise à niveau de la version 5.5 vers la version 6.3.2
dans un environnement de cluster Windows, supprimez les ressources de cluster
5.5, installez les fonctionnalités de mise à niveau, préparez la base de données V5,
et désinstasllez le serveur version 5.5.
Pour préparer le système à une mise à niveau, procédez comme suit :

1. Vérifiez que le serveur V5.5 possède un historique des volumes ainsi que des
fichiers de configuration d'unité valides.
2. Pour votre scénario sélectionné, localisez les informations concernant la
préparation d'une mise à niveau : «Scénario 1: Préparation de la mise à
niveau», à la page 103, «Scénario 2: Préparation de la mise à niveau», à la
page 149, «Scénario 3: Préparation de la mise à niveau», à la page 193 ou
«Scénario 4: Préparation de la mise à niveau», à la page 245. A partir du
noeud principal, procédez comme suit pour votre scénario :
a. "Vérification de la configuration requise pour la mise à niveau"
b. "Préparation de l'espace pour le processus de mise à niveau"
c. "Modification du serveur avant la mise à niveau"
d. "Désactivation des sessions"
e. "Sauvegarde des pools de stockage et de la base de données du serveur"
f. "Sauvegarde des informations de configuration"
Enregistrement des noms de la base de données et des volumes journal. Vous
pouvez les supprimer après une mise à niveau réussie.
3. Supprimez les ressources de cluster version 5.5 :
a. Vérifiez que le noeud principal contient les ressources de cluster.
b. A l'aide de Microsoft Failover Cluster Manager, enregistrez les valeurs de
l'adresse TCP/IP et le nom de réseau des éléments de serveur du groupe.
Le groupe de cluster comprend les ressources de serveur et de disque
Tivoli Storage Manager. Les ressources de serveur sont le nom de réseau
dans la section Server Name et l'instance Tivoli Storage Manager dans la
section Other Resources.
c. Supprimez l'instance Tivoli Storage Manager et le nom réseau.
4. Suivez les instructions de votre scénario :
a. "Installation des utilitaires de mise à niveau sur des systèmes Microsoft
Windows"
b. "Préparation de la base de données sur un serveur version 5 en vue de la
mise à niveau"
Avant d'extraire les données de la base de données, aidez-vous de l'utilitaire
DSMUPGRD PREPARE pour préparer la base de données du serveur. Si plusieurs
serveurs sont installés sur un seul système, répétez cette tâche pour chaque
serveur.
5. A partir de chaque noeud de cluster, utilisez Microsoft Management Console
(MMC) pour supprimer l'instance de serveur. Ne supprimez pas les volumes
de fichier et de disque ; supprimez seulement les entrées de service et de
registre. Une fois la configuration du serveur effectuée, supprimez les fichiers
de base de données qui ne sont plus utilisés. Fermez la MMC.
Conseil : Lorsque vous exécutez la MMC, vous pouvez voir s'afficher un

message d'erreur ANRU1203E. La MMC attend une réponse du serveur qui
n'est pas totalement initialisé. Pour poursuivre, cliquez sur OK et sur NEXT
(Suivant). Cette opération peut requérir plusieurs tentatives.
6. Désinstallez le serveur version 5.5. Pour plus d'informations sur la
désinstallation du serveur, voir «Désinstallation du programme version 5 sur
des systèmes Microsoft Windows», à la page 328.
Pour chaque noeud du cluster, désinstallez le serveur version 5.5, la licence de
serveur et le pilote de périphérique. Ne supprimez pas la base de données, le
journal de reprise ou tout autre fichier ou répertoire associé, comme le fichier
d'options du serveur.
7. Supprimez le type de ressource Serveur TSM du cluster :

a. Quittez Microsoft Failover Cluster Manager.
b. Sur un noeud du cluster, sur la ligne de commande, émettez la commande
suivante :
cluster resourcetype "TSM Server" /delete
8. Sur chaque noeud, supprimez les fichiers DLL tsmsvrrsc du répertoire
Windows Cluster C:\Windows\Cluster. Par exemple : TsmSrvRscExX64.dll et
TsmSrvRscX64.dll. Il peut exister deux ou trois fichiers DLL.
9. Redémarrez tous les systèmes du cluster.
10. Copiez et conservez le fichier dsmserv.opt ainsi que le fichier nommé dans
l'option DEVCONFIG. La configuration de cluster initiale pour Tivoli Storage
Manager version 6.3 ou ultérieure change ces fichiers. Vous devez posséder les
valeurs de serveur d'origine pour charger la base de données Tivoli Storage
Manager V5.5.
11. Modifiez le fichier d'options du serveur enregistré :
ultérieure. Pour obtenir une liste des options supprimées, voir
«Commandes, utilitaires et options de serveur supprimés», à la page 75.
VOLUMEHISTORY et au moins une option DEVCONFIG. Un fichier historique de
volumes et un fichier de configuration des unités sont nécessaires pour
restaurer la base de données.
c. Déterminez si le fichier d'options du serveur inclut l'option TXNGROUPMAX
avec une valeur. Si l'option est incluse et que la valeur est inférieure à
4096, vous pouvez augmenter la valeur ou supprimer l'option afin que le
serveur utilise la nouvelle valeur par défaut. L'augmentation de la valeur
peut améliorer les performance des opérations de transfert des données,
comme la migration d'un pool de stockage et la sauvegarde d'un pool de
stockage.
une fois que vous avez préparé le serveur pour la mise à niveau, effectuez les
tâches décrites dans «Installation du serveur et chargement de la base de données».
Installation du serveur et chargement de la base de données

Windows
Une fois que vous avez préparé le système pour une mise à jour depuis la version
5.5 vers la version 6.3.2 ou antérieure dans un environnement de cluster Windows,
installez le serveur de version 6.3.2 ou antérieure et chargez la base de données.
licence.
Conseil : Certaines étapes de cette procédure exigent que vous exécutiez Microsoft
Management Console (MMC). Dans ce cas, vous pouvez voir s'afficher un message
d'erreur ANRU1203E. La MMC attend une réponse du serveur qui n'est pas
totalement initialisé. Pour poursuivre, cliquez sur OK et sur NEXT (Suivant). Cette
opération peut requérir plusieurs tentatives.
Pour installer le serveur de version 6.3.2 ou antérieure et charger la base de
données, procédez comme suit :
1. Utilisez un assistant d'installation ou la console pour installer le serveur sur
tous les noeuds qui doivent faire partie du cluster. Pour plus d'informations,
voir «Installation du serveur V6.3 ou d'une version ultérieure», à la page 329.
2. Créez les répertoires et l'ID utilisateur de l'instance de serveur mise à niveau.
L'ID utilisateur de l'instance doit être défini pour le contrôleur de domaine.
Pour plus d'informations, voir «Création des répertoires et de l'ID utilisateur
pour l'instance de serveur mise à niveau», à la page 334. Créez les répertoires
dont l'instance de serveur a besoin pour la base de données et les fichiers
journaux de reprise uniquement sur les unités partagées, comme identifié dans
la table. Exécutez cette opération sur un seul noeud.
Pour le reste des étapes, vous devez vous connecter avec l'ID utilisateur
domain\userid.
3. Si vous utilisez la méthode de support, procédez comme suit dans votre
scénario sélectionné pour extraire les données du support.
4. Avant de saisir la valeur MMC pour configurer le serveur sur le noeud
principal, assurez-vous que l'ID utilisateur appartenant au serveur V6.3.2 ou
une version ultérieure (l'ID utilisateur de l'instance) dispose de la propriété ou
du droit de lecture/écriture pour les fichiers copiés. L'ID utilisateur de
l'instance doit avoir des droits d'accès d'administrateur sur le système et doit
faire partie des groupes DB2ADMNS et DB2USERS.
5. Pour plusieurs instances, vous devez créer les instances de serveur dans le
même ordre que celui créé à l'origine. La MMC nomme la première instance de
serveur SERVER1, la seconde SERVER2 et ainsi de suite.
La MMC version 6.3 ou ultérieure utilise le même répertoire d'instance de
serveur que celui spécifié dans le serveur V5.5. C'est pourquoi vous devez
enregistrer ailleurs le contenu du répertoire. Remplacez le fichier dsmserv.opt
par le fichier dsmserv.opt que vous avez édité et enregistré. Conservez le
fichier enregistré ; il doit être à nouveau remplacé.
6. Avant d'utiliser la valeur MMC pour configurer le noeud principal, a
ssurez-vous que tous les noeuds fonctionnent. Tous les noeuds doivent être
exécutés pour que la configuration du cluster DB2 fonctionne.
7. Sur le noeud principal, ouvrez la MMC pour commencer à configurer le
premier noeud principal. Si la liste Tâche de configuration initiale ne s'ouvre
pas immédiatement, cliquez avec le bouton droit de la souris sur le système
dansTivoli Storage Manager et sélectionnez Ajouter un nouveau serveur TSM.
Utilisez les panneaux d'initialisation de serveur pour configurer, initialiser et
regrouper le serveur. Dans le panneau Server Service Logon Parameters
(Paramètres de connexion du service de serveur), entrez domain\userid. Dans le
panneau Server Name and Password (Nom et mot de passe du serveur), entrez
le nom du cluster d'origine. Utilisez les panneaux de configuration du cluster
jusqu'à ce que la fenêtre Device Configuration Wizard (Assistant de
configuration d'unité) s'affiche. Cliquez sur Cancel (Annuler). Ne configurez ni
les périphériques, ni les noeuds client.
8. Supprimez la nouvelle base de données créée et chargez la base de données
précédente :
a. Mettez à jour le cluster de telle sorte que la reprise ne s'effectue pas
automatiquement et que le service ne démarre pas automatiquement. Dans
le gestionnaire de cluster, ouvrez le panneau Instance properties (Propriétés
d'instance). Notez les paramètres qui seront redéfinis au cours d'une étape

ultérieure. Désactivez l'option Auto Start (Démarrage automatique). Sous
l'onglet Failover (Reprise), paramétrez sur 0 le nombre maximum de
reprises dans la période spécifiée.
b. L'assistant peut laisser le service du serveur Tivoli Storage Manager
fonctionner. Affichez le menu de services. Si le service de serveur
fonctionne, cliquez avec le bouton droit de la souris sur le serveur et
sélectionnez Stop (Arrêter).
c. Pour supprimer la dernière base de données créée, aidez-vous de l'utilitaire
DSMSERV REMOVEDB.
d. Videz les répertoires de la base de données, du journal des actifs, du journal
miroir, du journal d'archivage et du journal de reprise d'archivage.
e. Dans le répertoire d'instance, remplacez les fichiers de configuration d'unité
et le fichier dsmserv.opt par les fichiers de configuration d'unité V5.5 et le
fichier dsmserv.opt mis à jour qui a été enregistré au cours de la phase de
préparation.
f. Exécutez manuellement l'utilitaire DSMSERV LOADFORMAT en utilisant les
paramètres du fichier initserv.bat dans le répertoire d'instance de
l'utilitaire DSMSERV FORMAT.
9. Chargez les données dans la base de données.
v Si vous utilisez la méthode de support, suivez ces instructions : «Chargement
des données extraites dans la nouvelle base de données», à la page 346.
v Si vous utilisez la méthode de réseau, suivez ces instructions : «Transfert de
la base de données du serveur via un réseau», à la page 348. Pour la
méthode de réseau, la commande DSMUPGRD EXTRACTDB doit spécifier l'adresse
IP du système et non l'adresse du cluster.
Une fois que vous avez installé le serveur et chargé la base de données, effectuez
les étapes décrites dans «Configuration du serveur».
Configuration du serveur
Windows
Après l'installation du serveur version Tivoli Storage Manager 6.3.2 et le

chargement de la base de données, exécutez Microsoft Management Console
(MMC) pour configurer les noeuds. Ensuite, assurez-vous que le serveur est
configuré pour la sauvegarde de la base de données et qu'il fonctionne
normalement. Enfin, mettez à jour le cluster pour permettre une reprise et un
démarrage automatique.
Pour configurer le nouveau système, procédez comme suit :

1. Exécutez l'assistant de configuration du Cluster sur chaque noeud du cluster.
Pour exécuter l'assistant sur un noeud, déplacez les ressources de cluster vers
ce noeud et ouvrez MMC. Dans la section Wizards, double-cliquez sur
l'assistant de configuration du Cluster.
| 2. Pour vérifier que le serveur est configuré pour la sauvegarde de base de
| données, procédez comme suit :
| a. Emettez la commande db2set db2_vendor_ini.
| b. vérifiez que la valeur DB2_VENDOR_INI est paramétrée sur le fichier
| tsmdbmgr.env.
3. Si le serveur n'est pas configuré pour la sauvegarde de base de données, suivez
les étapes de votre scénario sélectionné afin de configurer le système pour une
sauvegarde de base de données sur un système Microsoft Windows.
4. Vérifiez que le serveur a bien été mis à niveau et qu'il fonctionne normalement.
La vérification comprend le démarrage du serveur à partir de Microsoft
Failover Cluster Manager, l'enregistrement des licences et la sauvegarde de la
base de données.
5. Mettez le cluster à jour afin de permettre une reprise et un démarrage
automatique grâce aux paramètres d'origine précédemment notés.
La création d'instance initiale de la MMC version 6.3 ou ultérieure laisse un
volume de pool de stockage sur disque supplémentaire non défini pour Tivoli
Storage Manager sur le disque partagé. Le fichier tsm1.dat de répertoire
d'instance porte ce nom.
6. Facultatif : Supprimez ou définissez pour le serveur le volume du pool de
stockage sur disque*.dat.
7. Facultatif : supprimez les fichiers de base de données Tivoli Storage Manager
V5.5.

Chapitre 9. Procédures générales de mise à niveau d'un
serveur vers la version 6.3 ou ultérieure
Des utilitaires et un assistant sont fournis pour vous assister dans la mise à niveau
du serveur IBM Tivoli Storage Manager. Cet ensemble de procédures générales
peut être utilisé pour tout scénario de mise à niveau. Sinon, vous pouvez
sélectionner le scénario qui correspond à votre plan de mise à niveau et utiliser
l'ensemble de procédures spécifiques de ce scénario.
La procédure de mise à niveau du serveur inclut les tâches suivantes :

1. «Préparation de la mise à niveau», à la page 308
2. «Installation des utilitaires de mise à niveau sur le serveur d'origine», à la page
317
3. «Préparation de la base de données sur un serveur version 5 en vue de la mise
à niveau», à la page 325
4. Mise à niveau sur un même système uniquement : «Désinstallation du
programme version 5 avant l'installation de V6.3 ou d'une version ultérieure »,
à la page 327
5. «Installation du serveur V6.3 ou d'une version ultérieure», à la page 329
6. «Création des répertoires et de l'ID utilisateur pour l'instance de serveur mise à
v «Mise à niveau du serveur par le biais de l'assistant de mise à niveau», à la
page 337
v «Mise à niveau manuelle du serveur par le biais des utilitaires», à la page
339
356
page 363
page 364

Préparation de la mise à niveau


ses données.

1. «Vérification de la configuration requise pour la mise à niveau»
2. «Préparation de l'espace pour le processus de mise à niveau», à la page 312
3. «Modification du serveur avant la mise à niveau», à la page 313
4. «Désactivation des sessions», à la page 314
5. «Sauvegarde des pools de stockage et de la base de données du serveur», à la
page 315
6. «Suppression ou changement de nom du fichier NODELOCK», à la page 316
7. «Sauvegarde des informations de configuration», à la page 316
8. «Création d'un récapitulatif du contenu de la base de données», à la page 317
9. «Arrêt du serveur avant l'installation de la mise à niveau», à la page 317
Tâches associées:
Vérification de la configuration requise pour la mise à niveau

serveur.


ultérieure
(IA64)
(IA64)
IBM POWER IBM POWER
Chapitre 9. Procédures générales de mise à niveau d'un serveur vers la version 6.3 ou ultérieure 309
| à la page 385.

ultérieure.
Manager version 5
à la page 475.
4. Vérifiez que la mémoire système est conforme aux exigences du serveur.

v Si vous prévoyez de mettre à niveau le serveur sur le même système, et que
vous utilisez la méthode réseau pour le transfert de la base de données,
assurez-vous que l'espace de la mémoire système est suffisant pour
l'exécution des deux serveurs.
Lorsque vous exécutez le processus qui extrait la base de données du serveur
existant et l'insère sur le nouveau serveur, l'effet net est que deux serveurs
s'exécutent simultanément. La mémoire système doit être suffisante pour
gérer ces processus.
v Si vous prévoyez d'exécuter plusieurs instances du serveur V6.3 ou ultérieure
sur le système, chacune d'elles requiert le volume mémoire répertorié pour
un seul serveur. Multipliez la mémoire destinée à un serveur par le nombre
d'instances planifiées pour le système.





38
et mis en service.
Si vous prévoyez de mettre à niveau le serveur sur le même système, vous
pouvez suivre l'une des deux approches suivantes :
v Vérifiez que le système dispose d'un espace de stockage sur disque suffisant
pour stocker la base de données et les journaux de reprise pour les serveurs
V5 et V6.3 ou ultérieure.
v Après avoir sauvegardé la base de données version 5 et extrait les données
dans la base de données via des supports, reconfigurez le sous-système de
disque utilisé pour le stockage de la base de données. Insérez ensuite les
données dans la nouvelle base de données à partir des supports. Vous devez
suivre cette approche si vous ne disposez pas d'espace disque suffisant pour
les deux serveurs.
6. Si vous transférez le serveur vers un nouveau système, vérifiez que le système
V6.3 ou ultérieure peut accéder aux unités de stockage utilisées sur le système
V5. Cela inclut les unités de disque et de bande utilisées pour stocker les
données client.
Si vous transférez la base de données via la méthode de support, il peut
s'avérer nécessaire de laisser une unité de stockage connectée au système
d'origine pour effectuer l'extraction de la base de données. Transférez ensuite
l'unité de stockage vers le nouveau système.
Concepts associés:
Préparation de l'espace pour le processus de mise à niveau

La quantité et le type d'espace requis pour le processus de mise à niveau varie
selon que vous effectuez une mise à niveau vers la nouvelle version sur le même
système ou sur un système différent. Un autre facteur à prendre en compte est la
manière dont vous transférez les données dans la nouvelle base de données, en
utilisant des supports ou le réseau.
2. Si vous prévoyez d'extraire la base de données du serveur d'origine du support
pour l'insertion ultérieure dans la nouvelle base de données, assurez-vous que
l'espace est disponible pour le stockage de la base de données et le fichier
manifeste créés par le processus d'extraction.

système en cours.
données.
utilisateur root.
Tâches associées:
Modification du serveur avant la mise à niveau


update stgpool
Désactivation des sessions


suivante :
query session
cancel session all
Sauvegarde des pools de stockage et de la base de données

du serveur
base de données.

pool_copie


Suppression ou changement de nom du fichier NODELOCK


serveur.
Sauvegarde des informations de configuration

1. Sauvegardez les informations de configuration en utilisant la Tivoli Storage
Manager commande administrative :
Sauvegarde de devconfig filenames=nom_fichier
où nom_fichier indique le fichier dans lequel les informations de configuration

doivent être sockées.
2. Sauvegardez les informations de l'historique des volumes en utilisant la Tivoli
Storage Manager commande administrative :
Sauvegarde de volhistory filenames=nom_fichier
où nom_fichier indique le fichier dans lequel les informations de l'historique des

volumes doivent être stockées. Assurez-vous que l'historique des volumes
inclut les informations relatives à la sauvegarde de la base de données que
vous avez effectuée lors des étapes précédentes. Par exemple, lancez la
commande :
Requête volhistory type=dbsnapshot
Analysez les résultats des requêtes pour vérifier que l'heure de sauvegarde de
la base de données correspond à l'heure actuelle de la sauvegarde.
3. Sauvegardez les copies des fichiers suivants, qui se trouvent dans le répertoire
v dsmserv.dsk

5. Sauvegardez tous les scripts utilisés pour effectuer la gestion interne

quotidienne du serveur. Consultez les scripts afin d'identifier les changements
Création d'un récapitulatif du contenu de la base de données


Arrêt du serveur avant l'installation de la mise à niveau

query process
d'administration.
suivantes :
query mount
halte
Installation des utilitaires de mise à niveau sur le serveur d'origine

un site Web.

| la page 42.

v AIX «Installation des utilitaires de mise à niveau sur des systèmes AIX»
v HPUX «Installation des utilitaires de mise à niveau sur des systèmes HP-UX»
, à la page 320
v Linux «Installation des utilitaires de mise à niveau sur des systèmes Linux»,
à la page 321
v Solaris «Installation des utilitaires de mise à niveau sur des systèmes Oracle
Solaris », à la page 322
v Windows «Installation des utilitaires de mise à niveau sur des systèmes
Installation des utilitaires de mise à niveau sur des systèmes

AIX
AIX
Vous devez installer les utilitaires de mise à niveau sur le système où se trouvent
le serveur d'origine et sa base de données. Le module à installer peut être
téléchargé à partir du site des téléchargements FTP.
gsksa.rte 7.0.4.11
fichiers :
lslpp -L xlC.rte
lslpp -L gsksa.rte

server/v5r5/AIX/
Available Software.
répertoire.
sur Echap+4.

régionaux.
16. Une fois les utilitaires de mise à niveau installés, poursuivez avec
«Paramétrage des variables d'environnement pour les utilitaires de mise à

HP-UX
HPUX
version 5.
gzip
d'exploitation.
suivante :

commande suivante :


régionaux.
7. Une fois les utilitaires de mise à niveau installés, poursuivez avec «Paramétrage
des variables d'environnement pour les utilitaires de mise à niveau sur des
systèmes AIX, HP-UX, Linux et Oracle Solaris», à la page 324.

Linux
Linux
Restriction : N'installez pas les utilitaires dans le répertoire d'installation du

serveur d'origine qui doit être mis à niveau. Installez-les dans un répertoire
distinct.
suivante :
version 5.

commande suivante :
upgrade/bin.

régionaux.
systèmes AIX, HP-UX, Linux et Oracle Solaris», à la page 324.

Oracle Solaris
Solaris
Restriction : N'installez pas les utilitaires dans le répertoire d'installation du

serveur d'origine qui doit être mis à niveau. Installez-les dans un répertoire
distinct.

version 5.
d'exploitation.
suivante :

upgrade/bin.
pkgadd
nom_module

régionaux.
systèmes AIX, HP-UX, Linux et Oracle Solaris».
Paramétrage des variables d'environnement pour les utilitaires

de mise à niveau sur des systèmes AIX, HP-UX, Linux et
Oracle Solaris

AIX
HPUX Linux Solaris



Après avoir défini la variable d'environnement, poursuivez avec «Préparation de la

base de données sur un serveur version 5 en vue de la mise à niveau», à la page
325.

Microsoft Windows
Windows


Une fois les utilitaires de mise à niveau installés, poursuivez avec «Préparation de
la base de données sur un serveur version 5 en vue de la mise à niveau».
Si vous mettez à niveau le serveur sur le même système que la version antérieure
et que vous utilisez la méthode réseau pour extraire et insérer les données dans la
base de données version 6.3 ou ultérieure, utilisez l'option -o avec la commande
DSMUPGRD pour spécifier l'emplacement du fichier d'options du serveur.
Préparation de la base de données sur un serveur version 5 en vue de

la mise à niveau
Les utilitaires de mise à niveau doivent être installés sur le système où se trouve la
base de données.
Important : Après la préparation d'une base de données version 5.3 ou 5.4 à l'aide
de l'utilitaire DSMUPGRD PREPAREDB, la version de la base de données du serveur est
5.5. Vous ne pouvez plus exécuter cette base de données sur un programme de
serveur version 5.3 ou 5.4. Après la mise à niveau du serveur vers la version V6.3
ou ultérieure, si vous souhaitez revenir à la version antérieure, vous devez
réinstaller la version antérieure du code de serveur. Vous devez ensuite restaurer la
sauvegarde de la base de données du serveur correspondant à cette version.
Windows.

serveur.

AIX
HPUX Linux Solaris

Windows

tail -f prepare.out

Désinstallation du programme version 5 avant l'installation de V6.3 ou

d'une version ultérieure
Désinstallation du programme version 5 sur des systèmes AIX

AIX

serveur.

Désinstallation du programme version 5 sur des systèmes

HP-UX
HPUX

serveur.


Linux
Linux

serveur.
rpm -e TIVsm-server


Oracle Solaris
Solaris

serveur.



Microsoft Windows
Windows

serveur.

programmes.

soient supprimés.

«Installation du serveur V6.3 ou d'une version ultérieure».
Installation du serveur V6.3 ou d'une version ultérieure

Si vous installez le serveur V6.3 ou ultérieure sur le même système comme étant le
serveur V5, assurez-vous que toutes les étapes de préparation de la mise à niveau
sont achevées, y compris la sauvegarde de la base de données, avant de démarrer
l'installation. Le serveur que vous mettez à niveau est disponible uniquement
lorsque les étapes d'installation et de mise à niveau sont terminées.

licence.
Pour vérifier l'environnement du système et installer le serveur, complétez les

étapes suivantes :
Linux
Il va s’arrêter.
Solaris
n'est pas définie.
Windows
ce répertoire.
Windows

exécutable.

suivante :
chmod
a+x nom_module.bin

CZ1N1ML.
./nom_module.bin

Windows

exécutable.

nom_module.exe

comme suit :
graphique :
./prereqcheck.bin

prereqcheck.exe

page 43.


./install.bin
Windows

install.exe


maintenance/server.
si nécessaire.
HPUX
système.

Linux

d'installation.
Solaris
système.

Concepts associés:
Création des répertoires et de l'ID utilisateur pour l'instance de serveur

mise à niveau

ultérieure.


suivantes :

d'exploitation.
AIX

# passwd tsminst1
HPUX
# groupadd tsmsrvrs
# passwd tsminst1
Linux
# groupadd tsmsrvrs
# passwd tsminst1
Solaris
# groupadd tsmsrvrs
# passwd tsminst1
nécessaire.
Windows

net

net localgroup

actif
journal actif
secondaire qui est
pour le journal
d'archivage
Windows

mkdir f:\tsm\db003
mkdir g:\tsm\db004
actif
d'archivage
la copie miroir du
journal actif
journal d'archivage
secondaire qui est
pour le journal
d'archivage


suivantes :
«Mise à niveau du serveur par le biais de l'assistant de mise à niveau»
«Mise à niveau manuelle du serveur par le biais des utilitaires», à la page 339
Tâches associées:
Mise à niveau du serveur par le biais de l'assistant de mise à niveau


1. Vérifiez que les conditions requises ci-dessous sont remplies :

bureau.
un pare-feu.
Si le serveur version 5 est installé sur un système différent de celui
du serveur version 6.3 ou ultérieure, l'un des protocoles doit
également être activé pour celui-ci.
v Vous devez pouvoir vous connecter au système version6.3 ou
ultérieure avec l'ID utilisateur créé pour l'instance de serveur, à l'aide
du protocole SSH, rsh, ou REXEC. Lorsque vous utilisez l'assistant,
à ce système.
Windows

pare-feu.

Windows
commande suivante :
terminé.

Tâches associées:
«Mise à niveau manuelle du serveur par le biais des utilitaires»

commande.

1. «Création et formatage de la nouvelle base de données», à la page 340
2. Transférez la base de données en suivant l'une des méthodes suivantes :
v «Transfert de la base de données du serveur via des supports», à la page 345
v «Transfert de la base de données du serveur via un réseau», à la page 348
3. «Création d'un service Windows pour l'instance de serveur», à la page 350
4. «Configuration du système en vue de la sauvegarde de la base de données», à

la page 351

Concepts associés:
Création et formatage de la nouvelle base de données

suivants :
Windows
l'instance :


tsminst1 tsminst1

l'instance.
Windows




de besoin.
pool de stockage.
commande suivante :
Par exemple :
Windows
set



AIX HPUX Linux Solaris Vous devez mettre à jour les fichiers
suivantes :
v AIX

v HPUX Solaris

v Linux

suivantes :
v AIX
export LIBPATH
v HPUX Solaris
v Linux
v AIX
echo $LIBPATH
gsk8ver_64
gsk8ver_64

db2set
Windows


ligne :
Windows


db2icrt).
Poursuivez le processus de mise à niveau en vous aidant des instructions de l'une

des rubriques suivantes :
«Transfert de la base de données du serveur via des supports»

«Transfert de la base de données du serveur via un réseau», à la page 348
Tâches associées:
Transfert de la base de données du serveur via des supports

Utilisez le support pour transférer la base de données serveur lorsque le serveur
V6.3 ou ultérieure est installé sur un autre système et qu'aucune connexion réseau
n'est disponible. Utilisez également la méthode d'installation lorsque le système du
serveur ne dispose pas suffisamment d'espace pour les deux bases de données ou
lorsque vous souhaitez tester le processus de mise à niveau et configurer un
serveur de test.
Le processus créé un fichier manifeste au cours de l'extraction des données qui

contient des informations sur les supports utilisés pour stocker les données. Le
fichier manifeste est requis pour le chargement des données dans la nouvelle base
de données.
1. «Extraction des données sur des supports»
2. «Chargement des données extraites dans la nouvelle base de données», à la
page 346
Concepts associés:
Extraction des données sur des supports

Windows.
AIX

HPUX Linux Solaris

Windows


messages.
de l'opération :
tail -f extract.out

Concepts associés:
Tâches associées:
«Préparation de l'espace pour le processus de mise à niveau», à la page 312
Chargement des données extraites dans la nouvelle base de

données
d'origine.
ultérieure.

extraites.
v Si les données extraites ont été stockées à l'aide d'une classe d'unités FILE
ou DISK, procédez comme suit :
b. Assurez-vous que l'ID utilisateur auquel appartient le serveur version
6.3 ou ultérieure (ID utilisateur de l'instance) dispose de la propriété ou
des droits de lecture et d'écriture sur les fichiers extraits.
2. Assurez-vous que l'ID utilisateur d'instance est propriétaire de ou possède des
droits en lecture/écriture sur le fichier manifeste qui a été créé par le
processus d'extraction.
3. Connectez-vous avec l'ID utilisateur de l'instance au système sur lequel vous
avez installé le serveur version 6.3 ou ultérieure.
4. Si le serveur version 6.3 ou ultérieure est installé sur un système différent du
serveur d'origine, copiez le fichier manifeste qui a été créé par le processus
d'extraction vers le système version 6.3 ou ultérieure.
6. Vérifiez que le contenu du fichier de configuration d'unité est correct. La
classe d'unités qui a été utilisée pour l'étape d'extraction est enregistrée dans
le fichier manifeste et elle doit exister et être valide sur le système version 6.3
ou ultérieure.
| appartenant à une classe d'unités de type FILE, assurez-vous que le
| chemin complet des volumes est correct pour le système.
surveillance. Par exemple, exécutez la commande suivante, sur une seule ligne
:

Windows

base de données. Toutefois, il peut y avoir des périodes durant lesquelles
aucun message n'est généré. Durant ce temps, les opérations DB2 s'exécutent
en arrière-plan. La durée du processus dépend de la taille de la base de
données. Pour plus d'informations, voir «Exemple - Estimation de la durée de
mise à niveau en fonction de la taille de la base de données», à la page 51.
tail -f insert.out

l'opération :
10. Une fois les données chargées dans la base de données, si vous avez utilisé la
méthode avec supports et une unité de bande, supprimez ou extrayez de la
bibliothèque la bande qui a été utilisée pour recevoir les données extraites.
Empêchez la réutilisation de la bande jusqu'à ce que vous soyez sûr ne pas
avoir à répéter l'opération de chargement de base de données.
Continuez le processus de mise à niveau en exécutant les étapes décrites dans

«Création d'un service Windows pour l'instance de serveur», à la page 350.
Concepts associés:
Transfert de la base de données du serveur via un réseau

Déplacez la base de données en démarrant le processus d'insertion pour le serveur
V6.3 ou ultérieure afin d'accepter la base de données serveur. Ensuite, démarrez le



Windows



commande suivante :
tail -f insert.out

AIX

HPUX Linux Solaris

Windows

tail -f extract.out


produites.
produites.
Création d'un service Windows pour l'instance de serveur

Windows

commande suivante :
install
où :

d'instance.
Exemple
rudy s21ret
Tâches associées:
Configuration du système en vue de la sauvegarde de la base

de données
v «Configuration du système pour la sauvegarde de base de données sur des
systèmes AIX, HP-UX, Linux et Oracle Solaris»
v «Configuration du système pour la sauvegarde de base de données sur des

Configuration du système pour la sauvegarde de base de

données sur des systèmes AIX, HP-UX, Linux et Oracle Solaris


fi
| AIX Shell C :
commande suivante :
. ~/.profile

ligne suivante :


Servername server_a
COMMMethod TCPip
TCPPort 1500
commmethod tcpip
tcpport 1500
a. Arrêtez DB2:
db2stop
b. Démarrez DB2:
db2start



données sur des systèmes Microsoft Windows
Windows

données sur des systèmes Microsoft Windows
suivant :
de données :
suivante :
db2cmd
suivant :
*************************************************
commmethod tcpip
tcpport 1500
db2cmd
c. Arrêtez DB2:
db2stop
d. Démarrez DB2:
db2start

Chapitre 10. Exécution des premières étapes après la mise à
niveau
Vérifiez que le serveur a bien été mis à niveau et qu'il fonctionne normalement.
Les étapes de la vérification comprennent le démarrage du serveur,
l'enregistrement des licences et la sauvegarde de la base de données. Configurez
également des options du serveur disponibles.
Effectuez les tâches qui sont décrites dans les sections suivantes :
1. «Vérification de l'accès aux pools de stockage sur disque»
2. «Configuration des services Solaris pour l'instance de serveur», à la page 356
3. «Configuration des options de serveur pour la maintenance de la base de
4. «Démarrage de l'instance du serveur après la mise à niveau», à la page 357
5. «Enregistrement des licences», à la page 362
6. «Sauvegarde de la base de données après la mise à niveau du serveur», à la
page 363
7. «Vérification du serveur mis à niveau», à la page 364
8. «Changement du nom d'hôte pour le serveur Tivoli Storage Manager», à la
page 364
9. «Mise à jour de l'automatisation», à la page 366
10. «Surveillance du serveur mis à niveau», à la page 367
11. «Suppression de GSKit version 7 après la mise à niveau sur Tivoli Storage
Après avoir mis à niveau le serveur de la Version 6.3.3 ou supérieure, vous pouvez
authentifier les mots de passe avec le serveur répertoire LDAP, ou authentifier les
mots de passe avec le serveur IBM Tivoli Storage Manager. Les mots de passe qui
sont authentifiés à l'aide du serveur d'annuaire LDAP peuvent fournir une sécurité
de système améliorée. Pour plus de détails, voir la section relative à la gestion des
mots de passe et des procédures de connexion dans le Guide d'administration.
Vérification de l'accès aux pools de stockage sur disque

Pour la totalité de l'espace disque utilisé pour les pools de stockage (types d'unité
FILE ou DISK) par le serveur version 5, vérifiez que l'ID utilisateur qui est
propriétaire de l'instance du serveur mise à niveau en est le détenteur ou possède
des droits d'accès en lecture/écriture. Assurez-vous également que l'ID utilisateur
d'instance dispose des droits d'accès à toutes les unités utilisées, y compris les
unités logiques brutes.
1. Affichez les informations sur les classes d'unités FILE et les volumes DISK.
AIX HPUX Linux Solaris Dans chaque chemin d'accès de la
classe d'unités FILE ou du volume DISK, effectuez la procédure suivante :
ls -l
Windows Dans chaque répertoire de la classe d'unités FILE ou du volume
DISK, effectuez la procédure suivante :
dir /Q

2. Vérifiez que le propriétaire de la catégorie de périphérique FILE ou de volume

DISK est le propriétaire de l'instance du serveur et que les permissions définies
lui permettent de lire et d'écrire sur les fichiers.
Configuration des services Solaris pour l'instance de serveur

Solaris
Si vous exécutez un serveur Tivoli Storage Manager sur un système Solaris, vous
pouvez utiliser la fonction Solaris Service Management Facility (SMF) pour
configurer et contrôler le serveur Tivoli Storage Manager comme un service.
Pour plus d'informations, voir la note technique 7021102 (http://www.ibm.com/

Configuration des options de serveur pour la maintenance de la base

de données serveur
Afin d'éviter les problèmes liés à la croissance de la base de données et aux
performances de serveur, le serveur surveille automatiquement les tables de sa
base de données et les réorganise si nécessaire. Avant de démarrer le serveur pour
une utilisation en production, définissez les options de serveur afin de contrôler le
moment où la réorganisation est exécutée. Si vous prévoyez d'utiliser le
dédoublonnage, assurez-vous que l'option permettant d'exécuter la réorganisation
de l'index est activée.
La réorganisation des tables et des index requiert des ressources de processeur

importantes, un espace de journal actif et un espace de journal d'archivage.
Comme la sauvegarde de base de données est prioritaire par rapport à la
réorganisation, sélectionnez l'heure et la durée de la réorganisation afin de vous
assurer que les processus ne se chevauchent pas et que la réorganisation peut être
effectuée. Pour plus d'informations sur la réorganisation de la planification, voir
Si vous mettez à jour ces options de serveur lorsque le serveur est en cours
d'exécution, vous devez arrêter et redémarrer le serveur avant que les valeurs
mises à jour s'appliquent.
1. Modifiez les options du serveur.
AIX HPUX Linux Modifiez le fichier d'options du
Solaris
serveur, dsmserv.opt, situé dans le répertoire d'instance du serveur. Procédez
comme suit lors de la modification du fichier d'options du serveur :
v Pour activer une option, supprimez l'astérisque placé en début de ligne.
v Commencez par entrer une option sur toutes les lignes.
v Saisissez une seule option par ligne. L'option complète avec sa valeur doit se
trouver sur une seule ligne.
v Si vous avez plusieurs entrées pour une option du fichier, le serveur utilise la
dernière.
v Pour afficher les options disponibles du serveur, voir le fichier d'exemple,
dsmserv.opt.smp, situé dans le répertoire /opt/tivoli/tsm/server/bin.
Windows Vous pouvez modifier les options du serveur à l'aide de l'éditeur de
fichier d'options inclus dans la console IBM Tivoli Storage Manager. S'il est
recommandé d'utiliser l'éditeur de fichier d'options pour modifier les options
serveur, vous pouvez néanmoins utiliser un éditeur de texte.
2. Si vous prévoyez d'utiliser le dédoublonnage, activez l'option de serveur

ALLOWREORGINDEX. Ajoutez l'option et la valeur suivantes au fichier d'options du
serveur :
allowreorgindex yes
3. Paramétrez deux options de serveur contrôlant le moment où la réorganisation
commence et combien de temps elle dure. Sélectionnez une heure et une durée
de telle sorte que la réorganisation soit exécutée au moment où vous pensez
que le serveur est le moins occupé. Ces options de serveur contrôlent les
processus de réorganisation des tables et des index.
a. Paramétrez l'heure de démarrage de la réorganisation à l'aide de l'option de
serveur REORGBEGINTIME. Indiquez l'heure au format 24 heures. Par exemple,
pour paramétrer l'heure de début de la réorganisation à 16h30, définissez
l'option et la valeur suivantes dans le fichier d'options du serveur :
reorgbegintime 20:30
b. Paramétrez l'intervalle au cours duquel le serveur peut commencer la
réorganisation. Par exemple, pour indiquer que le serveur peut commencer
la réorganisation quatre heures après l'heure paramétrée à l'aide de l'option
de serveur REORGBEGINTIME, définissez l'option et la valeur suivantes dans le
fichier d'options du serveur :
reorgduration 4
4. Si le serveur était en cours d'exécution lorsque vous avez mis à jour le fichier
d'options du serveur, arrêtez et redémarrez le serveur.
Démarrage de l'instance du serveur après la mise à niveau

Vérifiez que l'instance du serveur est configurée correctement en démarrant
celle-ci.
A faire : Le démarrage du serveur est une opération qui s'effectue au niveau du

système d'exploitation à laquelle s'appliquent un certain nombre de restrictions. Si
vous n'êtes pas autorisé à utiliser le programme DSMSERV, vous ne pouvez pas le
lancer. Si vous n'avez pas de droits en lecture ou en écriture sur les fichiers
contenus dans le répertoire de l'instance, vous ne pouvez pas démarrer cette
instance du serveur.
Démarrage du serveur sur des systèmes AIX, HP-UX, Linux et

Oracle Solaris
Vous disposez de diverses options pour démarrer le serveur Tivoli Storage

Manager, en fonction du système d'exploitation sur lequel le serveur s'exécute.
Avant de démarrer le serveur, vérifiez que les droits d'accès et les valeurs ulimit
sont correctement définies.

Chapitre 10. Exécution des premières étapes après la mise à niveau 357

Important : Linux Solaris Au démarrage du serveur Tivoli Storage Manager,

le processus dsmserv est lancé en tant que propriétaire de l'instance. Sur les
plateformes Linux et Solaris, les noms des fichiers d'unité spéciaux sont détenus
par l'utilisateur root. Ils sont généralement en lecture/écriture pour le
superutilisateur et en lecture seule en cas d'accès par le groupe et au niveau
mondial. Le serveur Tivoli Storage Manager étant démarré en tant qu'utilisateur
non superutilisateur, il est possible qu'il ne dispose pas des droits requis pour
accéder aux fichiers d'unité spéciaux en mode lecture/écriture. Pour y remédier,
modifiez les paramètres d'autorisation sur les fichiers d'unité spéciaux (par
exemple, /dev/rmtX) pour accorder des droits d'accès en lecture/écriture à
l'utilisateur de l'instance. Vous pouvez procéder de différentes façons pour
modifier les paramètres d'autorisation :
v Si le système est dédié à Tivoli Storage Manager et que seul l'administrateur
Tivoli Storage Manager y a accès, assurez-vous que les fichiers d'unité spéciaux
sont globalement modifiables.
v Si le système comprend plusieurs utilisateurs, vous pouvez limiter l'accès en
faisant de l'utilisateur de l'instance Tivoli Storage Manager le propriétaire des
fichiers d'unité spéciaux.
v Si plusieurs instances utilisateur s'exécutent sur le même système, modifiez le
nom du groupe, par exemple TAPEUSERS, et ajoutez chaque ID utilisateur
d'instance Tivoli Storage Manager à ce groupe. Modifiez ensuite le propriétaire
des fichiers d'unité spéciaux pour qu'ils appartiennent au groupe TAPEUSERS et
assurez-vous que le groupe peut y écrire des données :
chmod g+w /dev/rmtX
AIX HPUX Linux Solaris Lorsque vous démarrez le serveur Tivoli

Storage Manager, ce dernier tente de changer certaines valeurs ulimit en illimité.
En règle générale, l'action de ce serveur garantit des performances optimales et
vous aide dans le débogage. Si vous êtes un utilisateur non superutilisateur au
démarrage du serveur, les tentatives de modifications des valeurs ulimit peuvent
échouer. Pour garantir un bon fonctionnement du serveur si vous utilisez le
serveur en tant qu'utilisateur non superutilisateur, définissez les valeurs ulimit
aussi élevées que possible avant de lancer leserveur.
Lorsque vous spécifiez les valeurs ulimit, assurez-vous de définirles limites

utilisateur DB2 aussi élevéesque possible. DB2 repose sur une mémoire de données
privée pour le tri des allocations de mémoire lors du traitement SQL. Une capacité
de segment de mémoire partagée insuffisante peut occasionner des échecs du
serveur Tivoli Storage Manager lorsqu'il interagit avec DB2. Pour de plus amples
informations sur la configuration des valeurs appropriées, consulter Technote
1212174 (http://www.ibm.com/support/docview.wss?uid=swg21212174).
Pour obtenir des instructions sur la définition de valeurs ulimit, consultez le

tableau suivant :
Tableau 67. Valeurs Ulimit
Type de valeur Ulimit Valeur standard
Taille maximum des fichiers core créés Illimité
Tableau 67. Valeurs Ulimit (suite)

Taille maximum du segment de données Illimité
d'un processus
Taille de fichier maximale Illimité
| Nombre maximum de fichiers ouverts v Pour les serveurs sur lesquels sont activés
| la réplication et/ou le dédoublonnage des
| données, indiquez une valeur minimale
| de 16384.
| v pour tous les serveurs, indiquez une
| valeur minimale de 8192.
Délai maximal d'exécution du processeur en Illimité
secondes
| Pour des détails sur la définition des valeurs ulimit, consultez la documentation
| relative à votre système d'exploitation.
Linux La valeur par défaut pour la limite utilisateur des processus utilisateur
maximum (nproc) a changé sur certains distribution et versions du système
d'exploitation Linux. La nouvelle valeur par défaut est 1024. Cette valeur peut
entraîner un comportement inattendu dans le serveur Tivoli Storage Manager. Pour
le système d'exploitation Red Hat Enterprise Linux (RHEL) 6, la valeur par défaut
pour nproc a baissé jusqu'à 1024. Cette valeur peut avoir changé dans d'autres
versions et distributions de Linux qui sont prises en charge par le serveur Tivoli
Storage Manager. Augmentez la limite utilisateur des processus utilisateur
maximum à la valeur minimale recommandée de 16384. Si la valeur n'est pas mise
à jour, le serveur peut avoir un comportement inattendu, y compris des
défaillances ou des échecs. Pour vérifier la limite utilisateur en cours, lancez la
commande suivante en tant qu'utilisateur d'instance :
ulimit -u
Par exemple :
[user@Machine ~]$ ulimit -u
16384
Pour afficher les valeurs en cours de toutes les limites utilisateur, exécutez la
commande suivante :
ulimit -a
Par exemple :
[user@Machine ~]$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
signaux en attente (-i) 128098
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
priorité en temps réel (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 16384

virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
Pour mettre à jour la limite utilisateur des processus utilisateur maximum, ajoutez
une ligne au fichier /etc/security/limits.conf. Sur le système d'exploitation
RHEL 6, la limite utilisateur pour nproc est définie dans le fichier
/etc/security/limits.d/90-nproc.conf. Ce fichier remplace les paramètres du
fichier /etc/security/limits.conf. Pour mettre à jour la limite utilisateur sur le
système d'exploitation RHEL 6, vous devez soit éditer le fichier dans le répertoire
/etc/security/limits.d ou supprimer le fichier et ajouter une ligne au fichier
/etc/security/limits.conf.
Concepts associés:
«Démarrage d'instances de serveur (AIX, HP-UX, Linux, Solaris)», à la page 9
Démarrage du serveur à l'aide de l'ID utilisateur d'instance

L'ID utilisateur d'instance possède un profil utilisateur qui lui permet d'exécuter le
serveur avec les autorisations nécessaires.
1. Connectez-vous à l'aide de l'ID utilisateur d'instance.
Conseil : Le script db2profile définit les variables d'environnement pour les

bases de données de l'instance de serveur. Lors de la définition de l'instance de
serveur, le script est ajouté au profil de configuration pour l'ID utilisateur
d'instance, si ce profil existe.
Si vous vous connectez à l'aide de l'ID utilisateur d'instance et si cet ID dispose

d'un profil de configuration (.profile si vous utilisez l'interpréteur de
commandes Korn) lors de la définition de l'instance de serveur, le script
db2profile s'exécute automatiquement. Si l'ID ne dispose d'aucun profil ou si
le script ne s'exécute pas automatiquement, exécutez-le manuellement à l'aide
de la commande suivante :
. ~/sqllib/db2profile
2. Accédez au répertoire d'instance correspondant à l'instance de serveur que
vous voulez démarrer.
3. Démarrez l'instance du serveur en lançant la commande suivante :
/opt/tivoli/tsm/server/bin/dsmserv
Le programme du serveur s'exécute en arrière-plan pour vous permettre de

configurer un ID administrateur et de vous connecter à l'instance de serveur.
Exemple
Dans cet exemple, le nom de l'instance du serveur Tivoli Storage Manager est
tsminst1 et le répertoire d'instance est /tsminst1. Pour démarrer tsminst1, exécutez
cd /tsminst1
Pour démarrer le serveur en arrière-plan, exécutez la commande suivante :

cd /tsminst1
/opt/tivoli/tsm/server/bin/dsmserv -q &
Démarrage du serveur à l'aide de l'ID utilisateur root


d'instance. Cependant, dans certains cas, il peut être nécessaire d'utiliser un autre
ID utilisateur pour démarrer le serveur. Par exemple, vous souhaiterez peut-être
utiliser l'ID utilisateur root pour vous assurer que le serveur peut accéder à des
périphériques spécifiques.
Pour plus d'informations sur le démarrage du serveur de l'ID utilisateur root, voir
le Guide d'administration.
Démarrage automatique des serveurs

| AIX HPUX Linux Solaris
| Vous pouvez configurer les serveurs pour qu'ils démarrent automatiquement au

| démarrage du système. Si le serveur est installé sur un système d'exploitation AIX,
| HP-UX ou Solaris, utilisez le script rc.dsmserv qui est fourni dans ce but.
| Le script rc.dsmserv se trouve dans le répertoire /opt/tivoli/tsm/server/bin.
| Linux Si le serveur est installé sur un système d'exploitation Linux, vous devez
| utiliser le script dsmserv.rc pour démarrer automatiquement le serveur.
| Linux Pour plus d'informations, voir la section sur l'exécution automatique des
| serveurs sous Linux dans le Guide d'installation.
| Conseil : AIX HPUX Solaris Si vous avez utilisé l'assistant de mise à

| niveau, vous aviez l'option de démarrer le serveur mis à niveau automatiquement
| lors du redémarrage du système. Si vous avez fait ce choix, le démarrage du
| serveur a été ajouté au fichier /etc/inittab.
AIX HPUX Solaris
Pour démarrer automatiquement le serveur au démarrage du système, procédez
comme suit :
Pour chaque serveur que vous souhaitez démarrer automatiquement, ajoutez une
entrée au fichier /etc/inittab pour exécuter le script rc.dsmserv :
v Définissez le niveau d'exécution à la valeur correspondant au mode
multi-utilisateur et activez l'option réseau. En général, le niveau d'exécution à
utiliser est 2, 3 ou 5, suivant le système d'exploitation et sa configuration.
Vérifiez que le niveau d'exécution dans le fichier /etc/inittab correspond au
niveau d'exécution du système d'exploitation. Consultez la documentation de
votre système d'exploitation pour plus d'informations sur les niveaux
d'exécution.
v Dans la commande rc.dsmserv, indiquez le nom du propriétaire de l'instance à
l'aide de l'option -u et l'emplacement du répertoire de l'instance du serveur à
l'aide de l'option -i.
Pour vérifier la syntaxe correcte, voir la documentaiton de votre système
d'exploitation.
AIX HPUX Solaris
Exemple : démarrage automatique d'une instance de serveur
Dans cet exemple, le propriétaire de l'instance correspond à tsminst1; le

répertoire d'instance du serveur correspond à /home/tsminst1/tsminst1; le
niveau d'exécution est 3; et l'ID du processus est tsm1. Ajoutez l'entrée
suivante au fichier /etc/inittab, sur une seule ligne :
tsm1:3:once:/opt/tivoli/tsm/server/bin/rc.dsmserv -u tsminst1
-i /home/tsminst1/tsminst1 -q >/dev/console 2>&1
Exemple : démarrage automatique de plusieurs instances de serveur
Si vous souhaitez exécuter plusieurs instances de serveur, ajoutez une
entrée pour chacune d'entre elles. Cet exemple utilise les ID de propriétaire
d'instance suivants :
v tsminst1
v tsminst2
Cet exemple utilise les répertoires d'instance suivants :
v /home/tsminst1/tsminst1
v /home/tsminst2/tsminst2
Cet exemple utilise les identifiants de processus suivants :
v tsm1
v tsm2
Le niveau d'exécution est 3. Ajoutez les entrées suivantes au
fichier/etc/inittab. Assurez-vous que chaque entrée se trouve sur une
seule ligne.
«Le script du démarrage du serveur : rc.dsmserv», à la page 582
Démarrage du serveur sur des systèmes Windows

Windows
Vous pouvez utiliser l'utilitaire DSMSERV pour démarrer le serveur.
Accédez au répertoire dans lequel le serveur est installé et procédez comme suit :
dsmserv -k instance_serveur
où instance_serveur correspond au nom de votre instance serveur. Server1

correspond à la première instance par défaut du serveur Tivoli Storage Manager
sur un système.
Concepts associés:
«Démarrage d'instances de serveur (Windows)», à la page 10
Enregistrement des licences

Enregistrez immédiatement toute fonction Tivoli Storage Manager sous licence que
vous avez acheté afin de ne pas perdre les données après le début d'utilisation du
serveur. Pour s'assurer que les licences précédentes et nouvelles sont enregistrées,
procédez comme suit :
1. Dans le répertoire d'instance du serveur de votre installation, assurez-vous que

le fichier NODELOCK a été supprimé ou renommé. Le fichier NODELOCK conserve
les informations sur les licences précédentes de votre installation.
2. Réenregistrez les licences précédemment enregistrées à l'aide de la commande
REGISTER LICENSE. Pour plus d'informations sur la commande REGISTER
LICENSE, voir la section REGISTER LICENSE dans le Guide de référence de
l'administrateur.
3. Enregistrez de nouvelles licences à l'aide de la commande REGISTER LICENSE.
Restriction : Vous ne pouvez pas enregistrer de licences pour IBM Tivoli

Storage Manager for Mail, IBM Tivoli Storage Manager for Databases, IBM
Tivoli Storage Manager for Enterprise Resource Planning et IBM Tivoli Storage
Manager for Space Management.
Sauvegarde de la base de données après la mise à niveau du serveur

Après avoir mis à niveau le serveur avec succès, procédez dès que possible à une
sauvegarde intégrale de sa base de données. Avant d'effectuer la sauvegarde,
sélectionnez la classe d'unités pour les sauvegardes de la base de données.
1. Effectuez les étapes suivantes :
a. Si vous n'avez pas fait appel à l'assistant (dsmupgdx) pour la mise à niveau
du serveur, vérifiez que vous avez effectué les étapes en vue de configurer
manuellement le système pour les sauvegardes de la base de données.
b. Si vous avez utilisé la méthode avec supports et une unité de bande,
supprimez ou extrayez de la bibliothèque la bande qui a été utilisée pour
recevoir les données extraites. Empêchez la réutilisation de la bande tant
que vous n'êtes pas assuré du bon fonctionnement du serveur mis à niveau
et de la nécessité de répéter l'étape d'insertion de la base de données.
2. Sélectionnez la classe d'unités à utiliser pour les sauvegardes automatiques de
la base de données. Lancez la commande suivante à partir d'une ligne de
commande d'administration IBM Tivoli Storage Manager.
set dbrecovery nom_classe_unités
La classe d'unités que vous indiquez sera utilisée par le gestionnaire de base de
données pour toutes les sauvegardes automatiques de la base.
3. Sauvegardez la base de données.
backup db devclass=nom_classe_unités type=full
La classe d'unités peut être identique ou différente de celle que vous avez
indiquée à l'aide de la commande SET DBRECOVERY. S'il s'agit d'une classe
d'unités différente, un message d'avertissement s'affiche, mais la sauvegarde
continue.
4. Sauvegardez le moteur de déploiement à l'aide de la commande suivante :
. /var/ibm/common/acsi/setenv.sh
cd /usr/ibm/common/acsi/bin
./de_backupdb
Windows
cd "C:\Program Files\IBM\Common\acsi"
setenv.cmd
cd "C:\Program Files\IBM\Common\acsi\bin"
de_backupdb.cmd
Tâches associées:
«Configuration du système en vue de la sauvegarde de la base de données», à la
page 351
Vérification du serveur mis à niveau

Vérifiez le fonctionnement du serveur. Si ce dernier a été installé sur un nouveau
système dans le cadre de la mise à niveau, vérifiez et mettez à jour les connexions
vers les unités de stockage et les autres composants.
1. Surveillez les messages émis par le serveur au moment du démarrage.
Recherchez les messages d'erreur et d'avertissement.
2. Si le serveur s'exécute sur un nouveau système à la suite de la mise à niveau,
vérifiez les éléments suivants :
a. Assurez-vous que toutes les unités de stockage du serveur d'origine sont
accessibles au serveur mis à niveau.
b. Comparez le nom des unités entre le nouveau système et le système
d'origine. Le cas échéant, mettez à jour les définitions des unités sur le
serveur. Par exemple, mettez à jour les définitions du chemin.
c. Mettez à jour l'adresse réseau utilisée par les clients de
sauvegarde-archivage, les agents de stockage, les serveurs des clients de
bibliothèque et d'autres serveurs destinés à communiquer avec le serveur
mis à niveau.
Au lieu d'effectuer ces mises à jour, vous pouvez éventuellement utiliser
l'adresse réseau du système d'origine en tant qu'adresse du nouveau
système. Vous avez également la possibilité de mettre à jour le système de
nom de domaine (DNS) pour qu'il désigne le nouveau système au lieu du
système d'origine. Prenez contact avec votre administrateur système.
3. Vérifiez que vous pouvez vous connecter au serveur via un client
d'administration comme avec la version antérieure du serveur.
4. Exécutez les commandes permettant d'obtenir un résumé des informations
contenues dans la base de données. Comparez le récapitulatif avec les résultats
obtenus pour les mêmes commandes avant la mise à niveau.
5. Effectuez des sauvegardes pour des postes client standard et vérifiez que leur
fonctionnement est celui attendu.
6. Vérifiez que des opérations telles que le transfert de données hors réseau local
et le partage de bibliothèques fonctionnent correctement.
7. Après avoir constaté que le serveur fonctionne correctement et qu'il n'est plus
nécessaire de rétablir la version précédente du serveur, n'oubliez pas de rétablir
la valeur initiale des paramètres que vous avez modifiés pour préparer la mise
à niveau.
Changement du nom d'hôte pour le serveur Tivoli Storage Manager

Si vous devez changer le nom d'hôte du serveur Tivoli Storage Manager version
6.3 ou ultérieure, vérifiez que vous mettez également à jour la configuration de
base de données. Si vous échouez dans la mise à jour de la configuration de base
de données, le serveur Tivoli Storage Manager risque de ne pas démarrer.
Changement du nom d'hôte pour un serveur exécuté sur des

systèmes AIX, HP-UX, Linux ou Solaris
Pour changer le nom d'hôte d'un serveur Tivoli Storage Manager exécuté sur un
système AIX, HP-UX, Linux ou Solaris, plusieurs étapes sont requises.
1. Arrêtez tous les serveurs Tivoli Storage Manager en cours d'exécution sur le
système.
2. Modifiez le nom d'hôte en utilisant les procédures définies pour votre système
d'exploitation.
3. A partir de l'ID superutilisateur du système, émettez la commande suivante :
db2set -g DB2SYSTEM=nouveau_nom_d_hôte
où newhostname est le nouveau nom d'hôte du serveur.
| Conseil : La commande db2set se trouve dans le répertoire

| /opt/tivoli/tsm/db2/adm.
4. Vérifiez que la valeur de DB2SYSTEM a été modifiée en émettant la commande
suivante :
db2set -all
Cette commande affiche tous les paramètres de configuration utilisés par la

base de données.
5. Dans le répertoire répertoire_instance/sqllib, localisez le fichier
db2nodes.cfg. Le fichier contient une entrée qui affiche le nom d'hôte
précédent, par exemple :
0 tsmmon TSMMON 0
a. Mettez à jour l'entrée avec le nouveau nom d'hôte. Cette entrée est similaire
à l'entrée suivante :
0 tsmnew nouveau_nom_d_hôte 0
b. Enregistrez et fermez le fichier changé.
Changement du nom d'hôte pour un serveur exécuté sous

Windows
Windows
Pour changer le nom d'hôte d'un serveur Tivoli Storage Manager exécuté sur un
système Windows, sauvegardez la base de données, arrêtez le serveur, modifiez le
fichier de configuration DB2 et redémarrez le serveur.
1. Sauvegardez la base de données Tivoli Storage Manager.
2. Arrêtez le serveur Tivoli Storage Manager.
3. Modifiez le service de démarrage du serveur Tivoli Storage Manager pour un
démarrage manuel :
a. Sur la console Tivoli Storage Management Console, développez
l'arborescence jusqu'à ce que le serveur s'affiche. Puis, développez le poste
du serveur et le poste Reports sous le serveur sélectionné.
b. Sélectionnez Informations sur le service
c. Sélectionnez le serveur dans la sous-fenêtre de droite et cliquez dessus
avec le bouton droit. Puis, cliquez sur Propriétés.
d. Dans la zone Type de démarrage, sélectionnez Manuel.
4. Emettez les commandes suivantes à partir de la fenêtre d'invite de commande

DB2 pour mettre à jour la variable de registre DB2SYSTEM, désactivez la
sécurité étendue et vérifiez les paramètres :
db2set -g DB2SYSTEM=nouveau_nom_d_hôte
db2set -g DB2_EXTSECURITY=NO
db2set -all
Conseil : Le paramètre DB2_EXTSECURITY est réinitialisé sur YES lorsque vous

redémarrez le système.
5. Vérifiez la présence du fichier db2nodes.cfg. Selon votre version de Windows,
le fichier db2nodes.cfg peut se trouver dans l'un des des répertoires suivants :
| v Windows 2008 ou version ultérieure :
| C:\ProgramData\IBM\DB2\DB2TSM1\<nom d'instance DB2>
v Autres versions de Windows :
C:\Documents and Settings\All Users\Application Data\IBM\DB2\DB2TSM1\
<nom d'instance DB2>
Conseil : Le fichier db2nodes.cfg est un fichier caché. Vérifiez que tous les
fichiers s'affichent en accédant à l'explorateur Windows et en sélectionnant
Outils > Options du dossier et en spécifiant l'affichage des fichiers masqués.
Si le fichier db2nodes.cfg n'existe pas sur votre système, passez à l'étape
suivante. Si le fichier existe, émettez la commande suivante pour mettre à jour
le nom d'hôte :
db2nchg /n:0 /i:<instance> /h:<nouveau
nom d’hôte>
6. Changez le nom d'hôte Windows, comme décrit dans la documentation du
système Windows que vous utilisez.
7. Redémarrez le serveur.
8. Mettez à jour les paramètres de sécurité en exécutant la commande suivante :
db2extsec -a new_host_name\DB2ADMNS -u new_host_name\DB2USERS
9. Démarrez le serveur Tivoli Storage Manager.
10. Réinitialisez le service de démarrage pour le serveur Tivoli Storage Manager
en optant pour le démarrage automatique :
a. Sur la console Tivoli Storage Management Console, développez
l'arborescence jusqu'à ce que le serveur s'affiche. Puis, développez le poste
du serveur et le poste Reports sous le serveur sélectionné.
b. Sélectionnez Informations sur le service
c. Sélectionnez le serveur dans la sous-fenêtre de droite et cliquez dessus
avec le bouton droit. Puis, cliquez sur Propriétés.
d. Dans la zone Type de démarrage, sélectionnez Automatique.
Mise à jour de l'automatisation

Une fois la mise à niveau effectuée, il pourra être nécessaire de modifier les
plannings d'administration définis dans la version 5 pour qu'ils fonctionnent en
raison des changements apportés à la syntaxe de commande. Implémentez et
vérifiez les modifications apportées à l'automatisation et aux scripts qui nécessitent
d'être modifiés dans le processus de planification.
Important : Assurez-vous que l'automatisation inclut une sauvegarde de la base de

données. Sauvegardez la base de données au moins une fois par jour.
Surveillance du serveur mis à niveau

Lorsque vous commencez à utiliser le serveur mis à niveau pour des opérations de
production, surveillez l'espace utilisé par ce dernier afin de vous assurer qu'il est
suffisant. Effectuez les ajustements d'espace si nécessaire.
1. Surveillez le journal actif afin de vous assurer que la taille est suffisante pour la
charge de travail gérée par l'instance de serveur.
Lorsque la charge de travail du serveur est proche du niveau généralement
attendu, et que l'espace utilisé par le journal actif représente entre 80 et 90 % de
l'espace disponible pour le répertoire du journal actif. Il se peut que vous soyez
obliger d'augmenter l'espace. La nécessité d'augmenter l'espace dépend des
types de transactions dans la charge de travail du serveur. Les caractéristiques
de transaction affectent le mode d'utilisation de l'espace dédié au journal actif.
Les caractéristiques de transaction suivantes peuvent affecter l'utilisation de
l'espace dans le journal actif :
v Nombre et taille des fichiers dans les opérations de sauvegarde
– Les clients, tels que les serveurs de fichiers qui sauvegardent un grand
nombre de petits fichiers peuvent générer un grand nombre de
transactions qui s'achèvent rapidement. Ces transactions peuvent utiliser
une grande quantité d'espace dans le journal actif, mais pour une courte
période.
– Les clients tels qu'un serveur de messagerie ou un serveur de base de
données qui sauvegardent des blocs importants de données dans un petit
nombre de transactions peuvent générer de petits nombres de transactions
dont l'exécution est longue. Il se peut que les transactions utilisent une
petite quantité d'espace dans le journal actif mais pendant une longue
période.
v Types de connexion réseau
– Les opérations de sauvegarde qui sont effectuées sur des connexions
réseau rapides accélèrent l'exécution des transactions. Les transactions
utilisent l'espace du journal actif pendant une période de temps plus
courte.
relativement plus lentes génèrent des transactions dont l'exécution est plus
longue. Les transactions utilisent l'espace du journal actif pendant une
période de temps plus longue.
Si le serveur gère des transactions ayant des caractéristiques très diverses,
l'espace utilisé pour le journal actif peut croître ou décroître fortement au cours
du temps. Pour un tel serveur, il peut être nécessaire de s'assurer qu'un
pourcentage généralement moins important de l'espace du journal actif est
utilisé. L'espace supplémentaire permet au journal actif de s'accroître pour les
transactions dont l'exécution est longue.
2. Surveillez le journal d'archivage pour vous assurer qu'il y a toujours de l'espace
disponible.
A faire : Si le journal d'archivage et le journal de reprise d'archivage

deviennent saturés, il se peut que le journal actif le devienne également, ce qui
peut provoquer l'arrêt du serveur. L'objectif est de créer suffisamment d'espace
disponiblepour le journal d'archivage de sorte qu'il n'utilise jamais toute
l'espace disponible.
Les conditions suivantes peuvent être observées :
a. dans un premier temps, le journal d'archivage croît rapidement lorsqu'une
opération classique de sauvegarde avec des clients se produit;
b. des sauvegardes de base de données sont effectuées régulièrement, en mode

planifié ou manuel;
c. Après des sauvegardes complètes de la base de données, des élagages sont
effectués automatiquement au niveau du journal. L'espace utilisé par le
journal d'archivage décroît lorsque l'élagage se produit.
d. Les opérations des clients se poursuivent normalement et le journal
d'archivage s'accroît également.
e. Des sauvegardes de base de données sont effectuées régulièrement et des
suppressions ont lieu dans le journal chaque fois qu'une sauvegarde de base
de données intégrale est exécutée.
Dans ces conditions, le journal d'archivage s'accroît dans un premier temps,
puis décroît pour, éventuellement, croître à nouveau. Pendant une période, au
fur et à mesure que les opérations normales se poursuivent, la quantité
d'espace utilisée par le journal d'archivage devrait arriver à se stabiliser.
Si le journal d'archivage continue à croître, effectuez l'une des actions
ci-dessous ou les deux :
v ajoutez de l'espace au journal d'archivage. Il se peut qu'un transfert du
journal d'archivage vers un système de fichiers différent soit nécessaire.
Pour plus d'informations sur le transfert du journal d'archivage, voir le
document Guide d'administration.
v Augmentez la fréquence des sauvegardes intégrales de la base de données
afin que l'élagage du journal se produise le plus souvent.
3. Si vous avez difini un répertoire pour le journal de reprise d'archivage,
déterminez si des journaux sont enregistrées dans ce répertoire pendant les
opérations normales. Si l'espace du journal de reprise est utilisé, augmentez la
taille du journal d'archivage. L'objectif est d'utiliser le journal de reprise
d'archivage uniquement dans des conditions inhabituelles, et non dans des
opérations normales.
Concepts associés:
«Espace requis pour le journal de reprise», à la page 47
«Opérations de base de données», à la page 4
Suppression de GSKit version 7 après la mise à niveau sur Tivoli

Storage Manager version 6.3 ou ultérieure
Windows
L'assistant d'installation Tivoli Storage Manager met à niveau GSKit version 8 et

les versions ultérieures. GSKit version 7 n'est pas supprimé ou mis à niveau
lorsque vous effectuez une mise à niveau sur Tivoli Storage Manager version 6.3
ou ultérieure, même si ce composant a été installé avec une version antérieure de
Si vous n'avez plus besoin de GSKit version 7 et que vous souhaitez libérer de
l'espace sur votre système, vous pouvez le supprimer après la mise à niveau sur
Tivoli Storage Manager version 6.3 ou ultérieure.
Avertissement : La suppression de GSKit version 7 peut affecter d'autres

programmes de votre système basés dessus.
1. Sauvegardez votre registre.
a. Cliquez sur Start (Démarrer), puis sur Run (Exécuter).
b. Tapez Regedit. Cliquez sur OK.

c. Pour enregistrer une copie de votre registre, sélectionnez File (Fichier) >
Export (Exporter).
d. Si vous devez ensuite restaurer le registre, sélectionnez File (Fichier) >
Import (Importer).
Pour plus d'informations, voir votre documentation Windows.
2. Localisez le répertoire dans lequel GSKit est installé. Le répertoire par défaut
est C:\Program Files\IBM\gsk7\.
3. Supprimez le répertoire d'installation GSKit gsk7 et tous les sous-fichiers et
répertoires. Cliquez avec le bouton droit de la souris sur le dossier et cliquez
sur Delete (Supprimer).
4. Supprimez la clé de registre GSKit version 7 et toutes les sous-clés et valeurs.
Avertissement : Le fait de supprimer la mauvaise clé peut générer des
problèmes de système tels que l'incapacité à redémarrer le poste de travail.
a. Cliquez sur Start (Démarrer), puis sur Run (Exécuter).
b. Tapez Regedit. Cliquez sur OK.
c. La clé de registre GSKit se trouve dans ce répertoire : HKEY_LOCAL_MACHINE\
SOFTWARE\IBM. Cliquez avec le bouton droit de la souris sur la clé de registre
HKEY_LOCAL_MACHINE\SOFTWARE\IBM\GSK7, puis cliquez sur Delete
(Supprimer).
Chapitre 11. Identification des problèmes liés à la mise à
niveau de la base de données
Pour obtenir des conseils sur l'identification des problèmes communs, consultez
cette section. Une procédure indiquant comment rétablir la version précédente du
serveur est également incluse.
Pour obtenir les informations les plus récentes sur les problèmes pouvant survenir
lors d'une mise à niveau et apprendre à les résoudre, consultez le site de support
de IBM Tivoli Storage Manager disponible à l'adresse : http://www.ibm.com/
Phase de mise à jour de serveur : Avertissements sur les options de

serveur non prises en charge
Lorsque vous exécutez l'assistant de mise à niveau ou l'un des utilitaires de mise à
niveau, des messages d'avertissement sont générés sur les options de serveur non
prises en charge.
Symptômes
Des messages d'avertissement relatifs aux options de serveur s'affichent mais le

processus se poursuit.
Causes
Le fichier d'options de serveur inclut les options qui ne sont pas valides pour un
serveur version 5.5. Par exemple, il peut inclure des options qui sont valides
uniquement pour un serveur version 5.4 ou antérieure.
Si vous avez déjà mis à niveau le fichier d'options de serveur en vue d'ajouter des
options valides uniquement pour un serveur version 6.3 ou ultérieure, des
messages d'avertissement pourront également être générés lors des processus de
mise à niveau.
Résolution du problème
Vous pouvez ignorer les messages d'avertissement tant que le processus de mise à
niveau n'est pas terminé.
Une fois le processus de mise à jour terminé, avant de démarrer le serveurV6.3 ou

ultérieure , modifiez le fichier d'options de serveur et supprimez les options qui ne
sont pas valides pour V6.3 ou ultérieure.
Phase d'extraction de la base de données : message de refus de

connexion
Lorsque vous utilisez la méthode via le réseau pour transférer la base de données
du serveur version 5 vers la base de données du serveur version 6, des messages
de refus de connexion sont reçus lors du démarrage de l'opération d'extraction.

Identification des problèmes liés à la mise à niveau de la base de données
Symptômes
Il se peut que les messages suivants s'affichent :

ANR8214E L’ouverture d’une session avec
adresse_hôte a échoué en raison d’un refus de connexion.
ANR0454E Session refusée par le serveur nom_serveur, motif : Echec de la communication.
Causes
Un message de refus de connexion signifie généralement que le système tente de

se connecter à un hôte ou à un port où aucun processus n'est à l'écoute pour une
connexion.
Avant de relancer le processus d'extraction, vérifiez les éléments suivants :

v Assurez-vous que la méthode de communication TCP/IP est activée pour le
serveur cible. La méthode de communication est définie à l'aide de l'option
COMMMETHOD dans le fichier d'options du serveur. TCP/IP est le paramètre par
défaut pour la méthode de communication de serveur mais le fichier d'options
du serveur cible peut contenir une valeur différente. Vérifiez si la méthode
COMMMETHOD NONE ou uniquement la méthode COMMMETHOD SHMEM est indiquée dans
le fichier d'options du serveur. Supprimez la méthode COMMMETHOD NONE si elle est
dans le fichier d'options du serveur. Ajoutez la méthode COMMMETHOD TCPIP si elle
ne figure pas dans le fichier d'options du serveur.
v Assurez-vous que les valeurs indiquées avec les paramètres HLADDRESS et
LLADDRESS dans la commande DSMSERV EXTRACTDB sont correctes. Le paramètre
LLADDRESS doit correspondre à la valeur indiquée pour l'option TCPPORT dans le
fichier d'options du serveur cible.
v Avant de relancer la commande DSMSERV EXTRACTDB, attendez que le processus
DSMSERV INSERTDB génère le message suivant :
| Phase de formatage de base de données : échec avec rc=499

| Windows
| Lorsque vous utilisez l'assistant de mise à niveau pour mettre à niveau un serveur
| Tivoli Storage Manager surWindows de la version 5 à la version 6.3 ou ultérieure,
| le système ne parvient pas à formater la nouvelle base de données.
| Symptômes
| L'opération de formatage de base de données échoue avec le code de retour

| rc=499.
| Causes
| Ce problème peut être causé par un programme antivirus Sophos. Si vous installez
| un programme antivirus Sophos sur le système qui est en cours de mise à niveau,
| il est possible que le programme analyse la base de données de l'instanceTivoli
| Storage Manager pendant la mise à jour. L'opération d'analyse peut affecter la
| création de fichiers base de données.
| Résolution de l'incident
| Pour diagnostiquer l'incident, passez en revue le fichier dsmupgdx.trc dans le

| répertoire c:\Program Files\Tivoli\TSM. Si vous voyez le message rc=499, sachez
| que la base de données n'a pas été correctement formatée. L'exemple suivant
| présente une sortie de suivi avec le message rc=499 :
| timestamp com.tivoli.dsm.ServerConfig.ServerDB$FormatThread.run(): Issuing cmd:
| "C:\Program Files\Tivoli\TSM\Server\dsmserv" -k Server1 LOADFORMAT dbfile=\
| "C:\Program Files\Tivoli\TSM\server1\dbfile.1\" activelogdir=\"D:\ActiveLog\"
| archlogdir=\"E:\ArchiveLog\" activelogsize=16384 >Format.Out 2>&1 on id tsminst1
| timestamp com.tivoli.dsm.ServerConfig.ProcessMonitor.run(): enter, Monitoring file
| C:\Program Files\Tivoli\TSM\server1\Format.Out
| timestamp 2012 com.tivoli.dsm.ServerConfig.ProcessMonitor.read(): File
| C:\Program Files\Tivoli\TSM\server1\Format.Out not created yet.
| timestamp com.tivoli.dsm.ServerConfig.ProcessMonitor.read(): File C:\Program Files
| \Tivoli\TSM\server1\Format.Out now being read. ...
| timestamp com.tivoli.dsm.ServerConfig.ProcessMonitor.read(): File C:\Program Files
| \Tivoli\TSM\server1\Format.Out now being read.
| timestamp com.tivoli.dsm.ServerConfig.ServerDB$FormatThread.run(): Format rc: 9994
| timestamp com.tivoli.dsm.ServerConfig.ServerDB$FormatThread.run(): format stderr:
| timestamp com.tivoli.dsm.ServerConfig.ProcessMonitor.cancel(): enter
| timestamp com.tivoli.dsm.ServerConfig.ProcessMonitor.read(): File C:\Program
| Files\Tivoli\TSM\server1\Format.Out now being read.
| timestamp com.tivoli.dsm.ServerConfig.ProcessMonitor.run(): exit
| timestamp com.tivoli.dsm.ServerConfig.ProcessMonitor.cancel(): exit
| timestamp com.tivoli.dsm.ConfigWizard.DoFormatPanel.signalEvent(): enter,
| event=formatDone, rc=499
| Si le fichier n'est pas disponibledsmupgdx.trc, passez en revue le fichier db2diaglog

| pour voir si l'erreur suivante est signalée :
| ID de classement non valide
| Le fichier échantillon db2diaglog suivant indique un échec de formatage de la base

| de données :
| horodatage LEVEL: Severe
| PID : 2304 TID : 2008 PROC : db2syscs.exe
| INSTANCE: SERVER1 NODE : 000 DB : TSMDB1
| APPHDL : 0-8 APPID: *LOCAL.SERVER1.121107195909
| AUTHID : TSMINST1
| EDUID : 2008 EDUNAME: db2agent (TSMDB1) 0
| FUNCTION: DB2 UDB, relation data serv, sqlrr_dump_ffdc, probe:300
| DATA #1 : SQLCA, PD_DB2_TYPE_SQLCA, 136 bytes
| sqlcaid : SQLCA sqlcabc: 136 sqlcode: -901 sqlerrml: 20
| sqlerrmc: Invalid collation ID
| sqlerrp : SQLNQB6E
| sqlerrd : (1) 0x00000000 (2) 0x00000000 (3) 0x00000000
| (4) 0x00000000 (5) 0xFFFFFF9C (6) 0x00000000
| sqlwarn : (1) (2) (3) (4) (5) (6)
| (7) (8) (9) (10) (11)
| sqlstate:
| Si vous déterminez que la base de données n'a pas été correctement formatée et si
| le programme antivirus Sophos est installé, procédez comme suit :
| 1. Pour s'assurer que le programme antivirus n'affecte pas l'opération de
| formatage de la base de données, procédez comme suit :
| v Configurez le programme antivirus pour s'assurer qu'il n'analyse pas la base
| de données d'instanceTivoli Storage Manager ou les fichiers.
| v Désactivez le programme antivirus pendant une période limitée pour qu'il
| n'affecte pas le processus de formatage de la base de données.
Chapitre 11. Identification des problèmes liés à la mise à niveau de la base de données 373
| A faire : Avant de reconfigurer ou de désactiver le programme antivirus,

| passez en revue le documentation du produit antivirus pour prendre
| connaissance des risques potentiels et de la manière dont il faut les migrer.
| 2. Relancez l'assistant de mise à niveau.
| 3. Si vous aviez désactivé le programme antivirus, réactivez-le.
|
Phase d'insertion de la base de données : messages ANR1338E
affichés par l'utilitaire de mise à niveau
Un ou plusieurs messages ANR1338E concernant des violations de contraintes ou
d'autres problèmes liés aux données s'affichent pendant la phase d'insertion de la
base de données lors de l'exécution de l'assistant de mise à niveau ou de l'utilitaire
DSMSERV INSERTDB.
Symptômes
Les messages de violations de contraintes s'affichent, mais le processus se poursuit.

Les données présentant un problème ne sont pas ajoutées dans la base de données
version 6.
Causes
Le processus d'insertion a rencontré un ou plusieurs problèmes lié(s) à des valeurs

de la base de données version 5, qui ont été insérées dans la base de données
version 6. Ces valeurs ne respectent pas les contraintes d'un type ou d'un format
de données, ou ne sont pas valides pour d'autres raisons.
Certaines données n'ayant pas été insérées dans la base de données, cette dernière
affiche un état incohérent.
Avertissement : Ne démarrez pas le serveur tant que ce problème n'est pas

résolu. Dans le cas contraire, vous risqueriez d'endommager les données. Prenez
contact avec le support IBM pour déterminer l'étendue du problème et savoir
comment réagir.
L'équipe de support IBM vous demandera de lui fournir le fichier constrnt.log,

qui contient des informations détaillées concernant les problèmes.
Phase d'insertion de la base de données : messages ANR1525I sans

progression apparente
L'utilitaire DSMSERV INSERTDB affiche de manière répétée le message d'état
ANR1525I sans aucune progression.
Symptômes
Il est possible que des messages tels que ceux ci-dessous s'affichent lors de
l'exécution du processus d'insertion.
ANR1524I INSERTDB : Début de la phase de mise à jour de la base de données.

ANR1525I INSERTDB : les entrées de la base de données 0 de 25 185 883 ont été mises à jour en 0:23:10.
Le nombre d'entrées de la base de données mises à jour peut ne pas augmenter

pendant un long moment moment.
Causes
Lors de la phase de mise à jour de l'utilitaire DSMSERV INSERTDB, les informations

de plusieurs ensembles de tables source sont fusionnées en un nombre restreint de
tables cible. Chaque opération fusionnant plusieurs tables source en une table cible
est une opération DB2 UPDATE longue et unique. Une opération UPDATE n'indique
aucun état tant qu'elle n'est pas terminée. L'état n'étant mis à jour qu'à la fin de
l'opération, le message ANR1525I affiche de façon répétée le même nombre
d'entrées mises à jour.
Une fois chaque ensemble de tables fusionné dans une table cible, le message
ANR1525I indique correctement la progression. Toutefois, la fusion de chaque
ensemble de tables peut durer extrêmement longtemps et afficher le même état
pendant toute la durée de l'opération. Ce blocage de l'état n'est pas un problème
en soi. L'affichage répété du message ANR1525I indique que l'utilitaire DSMSERV
INSERTDB est toujours en cours d'exécution, même si les statistiques affichées par le
message ne changent pas.
Résolution de l'incident
Lorsque l'utilitaire DSMSERV INSERTDB passe en phase de mise à jour de la base de

données, la majeure partie du travail restant est effectuée par DB2. Vous pouvez
utiliser des méthodes indirectes pour déterminer si l'opération progresse. Par
exemple, vous pouvez utiliser un contrôleur système tel que topas sur AIX pour
confirmer que le processus DB2 db2sysc fonctionne correctement. L'utilisation
d'une ressource de processeur et d'E-S au niveau des répertoires de base de
données par le processus db2sysc permettent de savoir si la phase de mise à jour
progresse.
Phase d'insertion de la base de données : Difficulté de relance du

processus de mise à niveau
Lorsque le processus de mise à niveau échoue lors de l'étape d'insertion de la base
de données, le redémarrage du processus génère des erreurs.
Symptômes
Lorsque vous tentez de redémarrer le processus, à l'aide de l'assistant de mise à

niveau (dsmupgdx)ou de commandes, vous recevrez des messages indiquant que la
base de données existe ou que des répertoires ne sont pas vides.
Causes
Ce problème est dû au fait qu'une instance de base de données a déjà été créée en
dépit de l'échec. Il se peut que les répertoires que vous avez indiqués dans
l'assistant ou à l'aide de la commande DSMSERV LOADFORMAT ne soient plus vides car

le processus a pu écrire des informations dans ces derniers avant d'échouer. Pour
que l'opération de formatage puisse être relancée, les répertoires doivent être vides.
Essayez de résoudre le problème de la manière suivante.

1. Vérifiez que vous êtes connecté avec le même ID utilisateur que celui
utilisé lors de l'échec de l'opération d'insertion. Il doit s'agir de l'ID
utilisateur créé spécifiquement pour l'instance de serveur qui était en
cours de mise à niveau lorsque l'échec s'est produit.
Avertissement : Assurez-vous que vous utilisez un ID utilisateur
correct. La base de données appartenant à l'ID utilisateur avec lequel
vous vous connectez est celle qui sera supprimée lors de l'étape
suivante. N'effectuez pas les étapes suivantes lorsque vous êtes
connecté avec un ID utilisateur possédant une instance de serveur
version 6 valide et fonctionnelle.
2. Supprimez l'instance de base de données qui a été créée.
dsmserv removedb TSMDB1
Autre méthode : Si la commande DSMSERV REMOVEDB échoue, supprimez

la base de données à l'aide de la commande DB2. Emettez les
commandes suivantes :
db2start
db2 drop db tsmdb1
3. Pour réutiliser la base de données et les répertoires de journaux que
vous avez indiqués lors de la tentative qui a échoué en vue de créer
l'instance de serveur, vérifiez que chaque répertoire est maintenant
vide.
4. Relancez l'assistant de mise à niveau pour l'instance de serveur en
cours de mise à niveau.
Si vous utilisez des commandes, reprenez à l'étape dans laquelle vous
avez lancé la commande DSMSERV LOADFORMAT.
Windows
1. Supprimez l'instance de base de données qui a été créée. Exécutez la

commande :
dsmserv removedb -k nom_instance_serveur TSMDB1
Le nom indiqué par nom_instance_serveur est celui de la clé de registre

pour l'instance de serveur qui était en cours de mise à niveau lorsque
l'échec s'est produit. Par exemple, si Server2 était en cours de mise à
niveau, lancez la commande :
dsmserv removedb -k server2 TSMDB1
Avertissement : Veillez à indiquer le nom de l'instance de serveur

pour laquelle le processus a échoué. L'exécution de cette commande
supprime la base de données correspondant à l'instance de serveur
indiquée.
Autre méthode : Si la commande DSMSERV REMOVEDB échoue, utilisez la

commande DB2 pour supprimer la base de données :
l'environnement configuré pour permettre de lancer les commandes
lors des étapes ultérieures.
set
db2instance=nom_instance_serveur
Par exemple, pour définir la variable d'environnement pour

l'instance de serveur Server1, lancez la commande suivante :
d. Exécutez la commande pour supprimer la base de données :
db2 drop db tsmdb1
2. Pour réutiliser la base de données et les répertoires de journaux que
vous avez indiqués lors de la tentative qui a échoué en vue de créer
l'instance de serveur, vérifiez que chaque répertoire est maintenant
vide.
3. Relancez l'assistant de mise à niveau pour l'instance de serveur en
cours de mise à niveau.
Si vous utilisez des commandes, reprenez à l'étape dans laquelle vous
avez lancé la commande DSMSERV LOADFORMAT.
| Phase de démarrage du serveur : Error ANR0162W

| Windows
| Après la mise à jour du serveurTivoli Storage Manager de V5 à V6.3 ou ultérieure

| sur un système d'exploitationWindows , l'instance de serveur échoue au
| démarrage.
| Symptômes
| Le démarrage du serveur échoue avec le message d'erreur ANR0162W.
| Causes
| Ce problème peut être dû à un programme antivirus Sophos. Si un programme

| antivirus Sophos est installé sur le système qui est mis à jour, le programme
| antivirus peut analyser l'instance de base de donnéesTivoli Storage Manager
| pendant la mise à jour. L'opération d'analyse peut affecter le démarrage de
| l'instance de serveur.
| Résolution du problème
| pour diagnostiquer le problème, tentez de démarrer le serveur. Pour démarrer le

| serveur à partir du répertoire par défaut, C:\Program Files\Tivoli\TSM\server,
| délivre la commande suivante :
| dsmserv -k instance_serveur
| où instance_serveur est le nom de l'instance du serveur. Server1 correspond à la

| première instance par défaut du serveur Tivoli Storage Manager.
| Si le serveur ne redémarre pas, la sortie inclut message ANR0162W,comme indiqué

| dans l'exemple suivant :
| C:\Program Files\Tivoli\TSM\server>dsmserv -k server1
| ANR7800I DSMSERV generated at 02:08:06 on Jul 26 2012.
| Tivoli Storage Manager for Windows
| Version 6, Release 3, Level 2.000
| Licensed Materials - Property of IBM
| (C) Copyright IBM Corporation 1990, 2011.
| All rights reserved.
| U.S. Government Users Restricted Rights - Use, duplication or disclosure
| restricted by GSA ADP Schedule Contract with IBM Corporation.
| ANR0900I Processing options file c:\Program Files\Tivoli\TSM\server1\dsmserv.opt.
| ANR4726I The ICC support module has been loaded.
| ANR0990I Server restart-recovery in progress.
| ...
| ANR0984I Process 1 for AUDIT LICENSE started in the BACKGROUND at 13:14:09.
| ANR2820I Automatic license audit started as process 1.
| ANR2560I Schedule manager started.
| ANR0162W Supplemental database diagnostic information: -1:42884:-440
| ([IBM][CLI Driver][DB2/NT64] SQL0440N No authorized routine named "COLLATIONNAME"
| of type "FUNCTION" having compatible arguments was found. SQLSTATE=42884).
| ANR0162W Supplemental database diagnostic information: -1:42884:-440
| ([IBM][CLI Driver][DB2/NT64]
| ...
| ANR0171I tbtbl.c(14146): Error detected on x:y, database in evaluation mode.
| ...
| ANR9999D_3937368011 LmLcAuditThread(lmlcaud.c:864) Thread<31>: Error in committing
| audit license transaction.
| ANR9999D Thread<31> issued message 9999 from:
| ANR9999D Thread<31> 000007FEE95CE599 OutDiagToCons()+159
| ANR9999D Thread<31> 000007FEE95C7FFC outDiagfExt()+fc
| ANR9999D Thread<31> 000007FEE91EC95B LmLcAuditThread()+13fb
| ANR9999D Thread<31> 000007FEE8DE6384 startThread()+124
| ANR9999D Thread<31> 0000000071F41D9F endthreadex()+43
| ANR9999D Thread<31> 0000000071F41E3B endthreadex()+df
| ANR9999D Thread<31> 0000000076C2BE3D BaseThreadInitThunk()+d
| ANR9999D Thread<31> 0000000076E36A51 RtlUserThreadStart()+21
| ...
| ANR0369I Stopping the database manager because of a server shutdown.
| ANR0991I Server shutdown complete.
| Si vous déterminez que l'instance de serveur n'arrive pas à démarrer et que le

| programme antivirus Sphos est installé alors exécutez les étapes suivantes :
| 1. Pour s'assurer que le programme antivirus n'affecte pas le démarrage de
| l'instance de serveur, prenez les mesures suivantes :
| v Configurez le programme antivirus pour s'assurer qu'il n'analyse pas la base
| de données ou les fichiers d'instance Tivoli Storage Manager.
| v Désactivez le programme antivirus pendant un temps limité pour que
| l'instance de serveur puisse être démarré.
| A faire : Avant de reconfigurer ou de désactiver le programme antivirus,

| consultez la documentation de l'antivirus pour prendre con science des risques
| possibles et comment les atténuer.
| 2. Redémarrez l'instance de serveur.
| 3. Si vous avez désactivé le programme antivirus, réactivez le.
|
Phase de démarrage du serveur : Avertissements sur les options de
serveur non prises en charge
Lorsque vous démarrez le serveur version 6.3 ou ultérieure, des avertissements
concernant des options du serveur non prises en charge s'affichent. Toutefois, les
options ne s'affichent pas dans la liste des options serveur qui ont été supprimées
pour V6.3 ou ultérieure.
Symptômes
Des messages ANR0902W relatifs aux options serveur s'affichent, mais le serveur
démarre tout de même.
Causes
Si la version 5 tolérait la présence de certaines options du serveur non prises en

charge par le serveur, la version 6.3 ou ultérieure les notifie en affichant des
avertissements.
La liste des options de serveur qui ont été supprimées pour la version 6.3 ou
ultérieure contient les options qui ont été supprimées depuis le lancement de la
version 5.5. Si l'option serveur affichant un avertissement sur votre système ne
figure pas dans cette liste, l'option a probablement été supprimée dans une édition
précédente, par exemple la version 5.4.
Vous pouvez soit ignorer l'erreur, soit mettre à jour le fichier des options du
serveur et redémarrer le serveur.
Phase Postupgrade : Le fichier dsmserv.dsk non disponible

Après avoir exécuté l'assistant de mise à niveau ou l'un des utilitaires de mise à
niveau, le fichier dsmserv.dsk est introuvable.
Symptômes
Le fichier dsmserv.dsk ne se trouve plus dans le répertoire par défaut du serveur.
Causes
Le fichier dsmserv.dsk n'est pas utilisé dans Tivoli Storage Manager version 6.3 ou
ultérieure.
Aucune intervention n'est requise. Cependant, si vous prévoyez de mettre à niveau

le serveur de la version 5 vers la version 6.3 ou ultérieure, vous souhaiterez
peut-être sauvegarder le fichier dsmserv.dsk au cas où vous deviez revenir à Tivoli
Storage Manager version 5.
Phase ostupgrade : Echec de la commande VARY

Après avoir effectué une mise à niveau du serveur Tivoli Storage Manager, la
commande VARY échoue.
Symptômes
Vous ne parvenez pas à utiliser cette commande pour mettre en ligne un pool de
stockage à accès aléatoire pour le serveur Tivoli Storage Manager.
Causes
Ce problème peut avoir diverses causes. Il est entre autres possible que l'ID
utilisateur exécutant le serveur ne possède pas d'accès en écriture aux disques du
serveur.
Vérifiez que l'ID utilisateur qui exécutera le serveur possède un accès en écriture
aux disques du serveur. Ensuite, réexécutez la commande VARY.
Phase Postupgrade : rétablissement à partir de la version V6.3 ou

ultérieure vers la version précédente du serveur V5
Si vous devez rétablir le serveur Tivoli Storage Manager vers la version précédente
après une mise à niveau, vous devez avoir une sauvegarde complète de la base de
donnée. Vous devez également disposer du support d'installation du serveur de
votre version d'origine, ainsi que des fichiers de configuration clés. En suivant
scrupuleusement les étapes de préparation préliminaires à la mise à niveau du
serveur, il est possible de rétablir la version précédente du serveur en réduisant la
perte des données.
Vous devez disposer des éléments suivants de la version antérieure du serveur :

v Sauvegarde de la base de données du serveur
v Fichier historique des volumes
v Fichier de configuration d'unité
v Fichier d'options du serveur
v Fichier dsmserv.dsk
Avertissement : Indiquez le paramètre REUSEDELAY pour éviter la perte des

données au moment de rétablir une version précédente du serveur.
Exécutez les étapes suivantes sur le système sur lequel le serveur version 6.3 ou
ultérieure est installé :
Etapes de rétablissement de la version antérieure du serveur

1. Sauvegardez la base de données version 6.3 ou ultérieure ainsi que le contenu
du répertoire d'instance, y compris le fichier historique des volumes, le fichier
de configuration d'unité et le fichier d'options du serveur. Conservez ces
fichiers au cas où il serait nécessaire de rétablir la version 6.3 ou ultérieure du
serveur.
2. Supprimez la base de données du gestionnaire de base de données, puis
supprimez les répertoires de la base de données et du journal de reprise.
a. Supprimez manuellement la base de données. Exécutez la commande

suivante :
dsmserv removedb tsmdb1
Vous pouvez également utiliser la commande suivante :
db2 drop db tsmdb1
b. Si vous devez réutiliser l'espace occupé par les répertoires de la base de
données et du journal de reprise, vous pouvez maintenant supprimer ces
répertoires.
3. Utilisez le programme d'installation pour désinstaller le serveur version 6.3 ou
ultérieure. La désinstallation supprime le serveur et le gestionnaire de base de
données avec leurs répertoires respectifs.
Pour plus d'informations, voir le guide d'installation de Tivoli Storage Manager.
4. Réinstallez la version du programme du serveur que vous avez utilisé avant
la mise à niveau vers la version 6.3 ou ultérieure. Cette version doit
correspondre à celle du serveur qui était exécuté lorsque vous avez créé la
sauvegarde de la base de données que vous allez restaurer à une étape
suivante.
Par exemple, si le serveur était au niveau de version 5.4.4.0 avant la mise à
niveau et que vous prévoyez d'utiliser la sauvegarde de la base de données
employée sur ce serveur, vous devez installer le programme du serveur
version 5.4.0.0, puis le groupe de correctifs version 5.4.4.0 pour pouvoir
restaurer la sauvegarde de la base de données.
a. Réinstallez la version de base du serveur qui était utilisée avant la mise à
niveau vers la version 6.3 ou ultérieure.
b. Réinstallez tous les groupes de correctifs qui étaient installés sur le serveur
de base de version antérieure à la mise à niveau vers la version 6.3 ou
ultérieure.
5. Copiez les fichiers suivants dans le répertoire pour obtenir des informations
de serveur :
v Fichier dsmserv.dsk
v Fichier d'options de serveur (généralement, dsmserv.opt)
6. Formatez la base de données à l'aide de l'utilitaire DSMSERV FORMAT. Pour
plus de détails, voir les informations relatives à la version du serveur que
vous réinstallez. Les informations de la version 5.5 sont disponibles dans le
centre de documentation suivant : http://publib.boulder.ibm.com/infocenter/
tivihelp/v1r1
Des informations relatives aux versions 5.4 et 5.3 sont disponibles dans le
même centre de documentation. Faites défiler le contenu du panneau de
navigation et développez la section Previous versions.
7. Restaurez la base de données en utilisant la sauvegarde créée au cours des
étapes de préparation avant la mise à niveau.
8. i vous avez activé le dédoublonnage des données pour des pools de stockage
de type FILE qui existaient avant la mise à niveau, ou si vous avez transféré
les données qui existaient avant la mise à niveau dans les nouveaux pools de
stockage lors de l'utilisation du serveur version V6.3 ou ultérieure, vous devez
effectuer des étapes supplémentaires. Voir «Etapes de reprise supplémentaires
si vous avez créé des pools de stockage ou activé le dédoublonnage de
données», à la page 382.
9. Si le paramètre REUSEDELAY dans les pools de stockage a une valeur inférieure

à l'âge de la base de données que vous avez restaurée, restaurez les volumes
contenus dans les pools de stockage à accès séquentiel qui étaient récupérés
après la sauvegarde de la base de données. Utilisez la commande RESTORE
VOLUME.
Si vous ne disposez pas d'une sauvegarde d'un pool de stockage, soumettez
les volumes récupérés à un audit à l'aide de la commande AUDIT VOLUME et en
spécifiant le paramètre FIX=YES en vue de résoudre les incohérences. Utilisez
la commande :
audit volume nom_volume fix=yes
10. Si les opérations de sauvegarde ou d'archivage du client ont été effectuées via
la version 6.3 ou ultérieure du serveur, vous pouvez être amené à effectuer un
audit sur les volumes du pool de stockage sur lesquels les données ont été
stockées.
11. Si vous utilisiez des pools de données actives avant la mise à niveau du
serveur vers la version V6.3 ou ultérieure, vous devez recréer les pools.
La durée nécessaire à la recréation des pools de données actives peut être
importante, en fonction du nombre et la taille des pools de données actives à
recréer.
Etapes de reprise supplémentaires si vous avez créé des

pools de stockage ou activé le dédoublonnage de données
Si vous avez créé des pools de stockage, activé le dédoublonnage de données sur
des pools de stockage de type FILE ou effectué ces deux opérations alors que votre
serveur était en cours d'exécution en tant que serveur version V6.3 ou ultérieure,
vous devez exécuter des étapes supplémentaires pour exécuter le serveur à la
version précédente.
Utilisez ces informations si vous avez effectué l'une ou les deux opérations
suivantes alors que votre serveur s'exécutait en tant que serveur version 6.3 ou
ultérieure :
v Si vous avez activé la fonction de dédoublonnage de données pour des pools de
stockage qui existaient avant la mise à niveau vers la version 6.3 ou ultérieure.
Le dédoublonnage de données s'applique uniquement aux pools de stockage
utilisant une unité de type FILE.
v Vous avez créé des pools de stockage principaux après la mise à niveau et
transféré les données qui ont été stockées dans d'autres pools de stockage vers
les nouveaux pools de stockage.
Une fois le serveur restauré sur la version 5, procédez comme suit.

v Pour chaque pool de stockage pour lequel vous avez activé la fonction de
dédoublonnage de données, restaurez-le dans son intégralité par le biais de la
commande RESTORE STGPOOL. Pour effectuer cette tâche vous devez disposer
d'une sauvegarde complète du pool de stockage, laquelle doit avoir été créée
avant la mise à niveau vers la version 6.3 ou ultérieure.
v Pour les pools de stockage que vous avez créés après la mise à niveau, consultez
les informations suivantes pour déterminer l'action à exécuter.
Les données qui ont été transférées des pools de stockage existants version 5
vers les nouveaux pools de stockage peuvent être perdues car les nouveaux
pools n'existent plus sur votre serveur version 5 restauré. La reprise possible
dépend du type du pool de stockage :
– Si des données ont été transférées des pools de stockage de type DISK version
5 vers un nouveau pool de stockage, l'espace occupé par ces données a
probablement été réutilisé. Vous devez ainsi restaurer les pools de stockage
d'origine version 5 en utilisant les sauvegardes de pools de stockage créées
Si aucune donnée n'a été transférée des pools de stockage V5 DISK vers un
nouveau pool, vérifiez les volumes de pool de stockage dans ces pools de
type DISK.
– Si les données ont été déplacées des pools de stockage à accès séquentiel
version 5 vers un nouveau pool de stockage, il est possible que ces données
aient été conservées et qu'elles soient utilisables dans les volumes de pool de
stockage du serveur version 5 restauré. Les données peuvent être utilisables si
le paramètre REUSEDELAY du pool de stockage a été défini sur une valeur qui a
empêché la récupération alors que le serveur s'exécutait sous la version 6.3 ou
ultérieure. Si des volumes ont été récupérés alors que le serveur s'exécutait en
tant que serveur version 6.3 ou ultérieure, ceux-ci doivent être restaurés
depuis les sauvegardes de pool de stockage créées avant la mise à niveau vers
la version 6.3 ou ultérieure.
|
| Partie 2. Migration des serveurs V5 Tivoli Storage Manager

| sur les systèmes AIX, HP-UX, ou Solaris vers la version
| V6.3.4 surLinux
| Vous pouvez maintenant migrer un serveur Tivoli Storage Manager version 5 qui
| s'exécute sur un système d'exploitation AIX, HP-UX, ou Solaris vers la version 6.3.4
| ou ultérieure sur un système d'exploitation Linux x86_64.
| En fonction de votre environnement matériel et logiciel, cette procédure de

| migration peut être utile pour la consolidation du serveur, l'équilibrage de charge
| ou la standardisation sur le système d'exploitation Linux.

|
| Chapitre 12. Présentation de la migration

| Avant de migrer le serveur, révisez la feuille, de route de migration, les scénarios
| de migration et les informations connexes.
| Vous pouvez utiliser l'une des options de migration suivantes :

| v Suivez la procédure de la migration multi-plateformes, en démarrant par
| «Feuille de route de migration».
| v Suivez la procédure de la migration multi-plateformes, en démarrant par
| «Feuille de route de migration», puis facilitez le processus en utilisant le moteur
| de migration à partir du logiciel Butterfly.
| Le moteur de migration du logiciel Butterfly automatise le processus de
| migration des données de sauvegarde à partir d'un ou de plusieurs serveurs
| Tivoli Storage Manager V5 vers le serveur V6 Tivoli Storage Manager. Le moteur
| de migration du logiciel Butterfly offre également des options de planification
| pour les rapports de migration et en temps réel sur l'avancement du processus
| de migration. Seuls les services logiciels IBM et les partenaires commerciaux IBM
| sont autorisés à utiliser le moteur de migration du logiciel Butterfly. Pour plus
| d'informations, contactez les services logiciels IBM ou votre partenaire
| commercial IBM.
|
| Feuille de route de migration
| la feuille de route de migration fournit des liens vers des informations pouvant
| vous aider à planifier, préparer, et effectuer le processus de migration.
| Pour planifier la migration, exécutez les étapes suivantes :

| 1. Revoyez les scénarios de migration. Voir «Scénarios pour la migration d'un
| serveur à partir d'un système AIX, HP-UX, ou Solaris vers V6.3.4 sur Linux», à
| la page 388.
| 2. Adaptez-vous aux commandes et utilitaires que vous êtes susceptible d'utiliser
| au cours du processus de migration. Voir «Utilitaires et commandes de
| migration des données», à la page 393.
| 3. Revoyez les directives pour le transfert des données inaccessibles ou non
| lisibles par le système cible. Voir «Transfert de données», à la page 393.
| 4. Revoyez les informations sur la migration de périphériques. Voir «Disponibilité
| de périphérique», à la page 394.
| 5. Revoyez les directives sur les données client et le serveur au cours du
| processus de migration. Voir «Protection des données client et du serveur au
| cours du processus», à la page 394.
| 6. Sélectionnez la méthode de migration à utiliser et planifiez la configuration
| requise au niveau du matériel, des logiciels et du stockage pour votre serveur
| et votre environnement. Voir Chapitre 13, «Planification de la migration», à la
| page 397.
| pour se préparer à la migration, voir Chapitre 14, «Préparation de la migration», à

| la page 405.
| Pour migrer le système, voir Chapitre 15, «Migration de la base de données du

| serveur vers le serveurV6.3.4 or ou ultérieure», à la page 417.

Migration des serveurs version 5 sur AIX, HP-UX, ou Solaris vers la version 6.3.4 sur
Linux
| pour préparer le système à une opération, voir Chapitre 16, «Exécution des
| premières étapes après la mise à niveau», à la page 459.
|
| Scénarios pour la migration d'un serveur à partir d'un système AIX,
| HP-UX, ou Solaris vers V6.3.4 sur Linux
| Plusieurs scénarios sont disponibles pour migrer un serveur Tivoli Storage
| Manager de la version 5 sur un système d'exploitation AIX, HP-UX, ou Solaris vers
| la version 6.3.4 or ou ultérieure sur un système d'exploitation Linux x86_64. En
| plus de la migration du serveur, vous devez migrer les données de la base de
| données version 5 vers la base de données version 6.3.4 or ou ultérieure.
| Passez en revue les scénarios afin de choisir celui qui convient le mieux à votre
| environnement matériel et logiciel.
| Les scénarios suivants sont disponibles :

| v scénario de migration 1 : méthode support, assistant de mise à niveau
| v scénario de migration 2 : méthode support, ligne de commande
| v scénario de migration 3 : méthode réseau, assistant de mise à niveau
| v scénario de migration 4 : méthode réseau, ligne de commande
| Pour migrer la base de données du serveur, vous pouvez utiliser l'une des
| méthodes suivantes :
| Via des supports
| Vous pouvez extraire les données de la base de données d'origine vers le
| support, puis les charger ultérieurement dans la nouvelle base de données.
| Via un réseau
| Vous pouvez simultanément extraire les données de la base de données
| d'origine et les charger dans la nouvelle base de données via une
| connexion réseau.
| Pour d'informations sur le moment où il faut utiliser un la méthode support ou

| réseau, voir «Comparaison des méthodes de transfert des données vers la base de
| données version 6.3 ou ultérieure», à la page 17.
| Pour migrer le serveur, vous pouvez utiliser l'assistant de mise à niveau ou la ligne
| de commande :
| assistant de mise à niveau
| L'assistant vous accompagne tout au long du processus. Vous pouvez
| éviter certaines étapes qui s'avèrent complexes lorsqu'elles sont effectuées
| manuellement.
| ligne de commande
| Vous pouvez emettre des commandes administratives pour mettre à niveau
| le système manuellement.
| Scénario de migration 1 : méthode support, assistant de mise à

| niveau
| La figure suivante montre comment procéder à la migration d'un serveur à l'aide

| de la méthode support et l'assistant de mise à niveau.
Linux
|
Migration vers V6 à l'aide de la méthode de média
Migrez grâce à l'assistant
Installez le serveur V6.3.4 ou un

2. serveur ultérieur.
Configurez de nouveaux
périphériques. Créez l'ID utilisateur
3. et les répertoires pour le serveur
V6.3.4. ou un serveur ultérieur.
1. Exécutez les tâches de préparation.
Effectuez la mise à niveau du
serveur de V5.5.6 ou une version
ultérieure. Migrez les données vers
des unités de bande. Sauvegardez
la base de données. Installez les
configurer le serveur V6.3.4 ou un
serveur ultérieur et mettez à
niveau la base de données V5.
Exécutez les tâches de post-

5. migration.
Serveur V5 Tivoli Serveur V6.3.4 ou

Storage Manager ultérieure de Tivoli
Storage Manager
|
| Figure 9. Scénario de migration 1
|
| Pour plus d'informations sur la sélection d'un niveau approprié d'un serveur
| version 5 avant une procédure de migration, voir «Déterminer le niveau approprié
| d'un serveur V5 avant une mise à niveau», à la page 42.
| Scénario de migration 2 : méthode support, ligne de commande

| de la méthode support et l'assistant de mise à niveau.
Chapitre 12. Présentation de la migration 389

Linux
|
|
Migration vers V6 à l'aide de la méthode de média
Migrez grâce à la ligne de commande
4. Installez
ultérieur.
le serveur V6.3.4 ou un serveur
5. Configurez de nouveaux périphériques.

Créez l'ID utilisateur et les répertoires pour
le serveur V6.3.4.
1. Exécutez les étapes de préparation.
Effectuez la mise à niveau du serveur de
V5.5.6 ou une version ultérieure. Migrez
les données vers des unités de bande.
Sauvegardez la base de données.
6. Créez l'instance de serveur et de base de

données. Exécutez la commande db2icrt
2. Extrayez la base de données version 5
vers des supports externes. Exécutez
et l'utilitaire DSMSERV LOADFORMAT.
3. Extract the V5 database to external 7. Insérez les données depuis les supports
dans la nouvelle base de données.
media. Run the DSMUPGRD Exécutez l'utilitaire DSMSERV INSERTDB.
EXTRACTDB utility.
8. Configurez le système pour la sauvegarde

de la base de données.
9. Exécutez les tâches de post-migration.
Serveur V5 Serveur V6.3.4 ou

Tivoli Storage ultérieure de Tivoli
Manager Storage Manager
|
|
Linux
| Scénario de migration 3 : méthode réseau, assistant de mise à

| niveau
| de la méthode réseau et l'assistant de migration.
|
|
Migration vers V6 à l'aide de la méthode de réseau
Migrez grâce à l'assistant
2. Installez le serveur V6.3.4 ou un

serveur ultérieur.
3. Créez l'ID utilisateur et les

répertoires pour le serveur V6.3.4.
ou un serveur ultérieur.
Exécutez les tâches de préparation.

1. Effectuez la mise à niveau du serveur
de V5.5.6 ou une version ultérieure. 4. Démarrez l'assistant de mise à
niveau. Utilisez l'assistant pour
Migrez les données vers des unités de configurer le serveur V6.3.4 ou un
bande. Sauvegardez la base de
données. Installez les utilitaires de serveur ultérieur et mettez à niveau
mise à niveau. la base de données V5.

Storage Manager
|
|

Linux
| Scénario de migration 4 : méthode réseau, ligne de commande

| de la méthode réseau et l'assistant de migration.
|
|
Migration vers V6 à l'aide de la méthode de réseau
Migrez grâce à la ligne de commande
3. Installez
ultérieur.
le serveur V6.3.4 ou un serveur
4. Créez l'ID utilisateur et les répertoires pour

le serveur V6.3.4. ou un serveur ultérieur.
Exécutez les tâches de préparation.

1. Effectuez la mise à niveau du serveur de
V5.5.6 ou une version ultérieure. Migrez les
données vers des unités de bande.
Sauvegardez la base de données. Installez
les utilitaires de mise à niveau.
5. Créez l'instance de serveur et de base de
données. Exécutez la commande db2icrt
et l'utilitaire DSMSERV LOADFORMAT.

PREPAREDB.
6. Lancez l'insertion pour le nouveau serveur.

Exécutez l'utilitaire DSMSERV INSERTDB.
7. Lancez le processus d'extraction. Exécutez

8. Configurez le système pour la sauvegarde

Storage Manager
|
|
Linux
|
| Processus de migration
| Vous pouvez utiliser les utilitaires et les commandes afin de faciliter le processus
| de migration. Les restrictions s'appliquent au transfert de données au cours du
| processus de migration et à la disponibilité de périphérique. Au cours du
| processus de migration, il faut veiller à protéger les données client et le serveur.
| Utilitaires et commandes de migration des données

| Tivoli Storage Manager fournit des utilitaires et des commandes pour vous aider
| dans le transfert de données à partir du système V5 qui s'exécute sur AIX, HP-UX,
| ou Solaris vers V6.3.4 or ou ultérieure on Linux x86_64.
| Vous pouvez utiliser les utilitaires suivants pour la migration de données :

| DSMUPGRD QUERYDB
| L'utilitaire DSMUPGRD QUERYDB affiche les informations sur le journal de la
| base de données et de reprise pour un serveur V5.
| DSMUPGRD PREPAREDB
| L'utilitaire DSMUPGRD PREPAREDB prépare la base de données pour la
| migration en vérifiant que toutes les tâches de prémigration sont exécutées.
| DSMUPGRD EXTRACTDB
| L'utilitaire DSMUPGRD EXTRACTDB extrait les données de la base de données
| de serveur.
| DSMSERV LOADFORMAT
| L'utilitaire DSMSERV LOADFORMAT met en forme une base de données vide en
| vue d'y insérer les données extraites.
| DSMSERV INSERTDB
| L'utilitaire DSMSERV INSERTDB transfère les données extraites vers une
| nouvelle base de données.
| De nombreux utilitaires et de nombreuses commandes utilisés pour la mise à

| niveau de serveur sont également utilisés pour la migration de serveur. Pour plus
| d'informations, voir Annexe A, «Utilitaires, scripts et commandes pour la mise à
| niveau de serveur et la migration», à la page 561.
| Vous pouvez utiliser les commandes pour valider la mise à niveau de la base de
| données. Pour plus d'informations, voir «Exemples des commandes à exécuter
| pour valider la mise à niveau de la base de données», à la page 583.
| Transfert de données
| Dans certains cas, les données enregistrées sur un système version 5 peuvent ne
| pas être lisibles et accessibles sur un système version6.3.4 or ou ultérieure . Vous
| pouvez prendre des mesures pour vous assurer que ces données sont lisibles et
| accessibles.
| Les restrictions suivantes s'appliquent au transfert de données :

| v Les volumes logiques bruts utilisés sur un système version 5 ne sont pas
| disponibles sur un système version6.3.4 or ou ultérieure. Les volumes logiques
| bruts ne peuvent pas être utilisés sur des systèmes Linux.

Linux
| v Les données enregistrées sur des périphériques GENERICTAPE ne sont pas

| disponibles sur un système version6.3.4 or ou ultérieure. Les périphériques
| GENERICTAPE ne peuvent pas être utilisées sur des systèmes Linux.
| v Les volumes enregistrées sur des périphériques DISK et FILE peuvent ne pas
| être disponibles sur un système version6.3.4 or ou ultérieure, en fonction des
| restrictions du système cible.
| v Un pilote de périphérique requis pour accéder à un type spécifique de matériel
| d'archivage peut ne pas être pris en charge sur un systèmeversion6.3.4 or ou
| ultérieure.
| v Le matériel d'archivage lié à un système version 5 peut être incompatible au
| système version6.3.4 or ou ultérieure.
| La façon la plus fiable de transférer des données vers le nouveau système est de
| les migrer vers une unité de bande non GENERICTAPE. L'unité de bande doit être
| accessibles aux systèmes version 5 et version6.3.4 or ou ultérieure. Après la
| migration, vous pouvez migrer les données à partir de la bande magnétique vers
| des périphériques DISK ou FILE qui sont compatibles au système version6.3.4 or
| ou ultérieure.
| Disponibilité de périphérique
| Les périphériques utilisés sur un système V5 peuvent être inaccessibles sur une
| base de données de serveur V6.3.4 or ou ultérieure.
| Si un périphérique est inaccessible, vous devez planifier une migration de données

| à partir du périphérique V5 vers un périphérique accessible dans une base de
| données de serveur V6.3.4 or ou ultérieure.
| Pour obtenir une liste de périphériques et de systèmes d'exploitation pouvant être

| utilisés, consultez les sites web suivants :
| AIX HPUX Solaris Site web des périphériques pris en charge par
| IBM Tivoli Storage Manager pour les systèmes AIX, HP-UX, Solaris, et
| Windows (http://www.ibm.com/software/sysmgmt/products/support/
| IBM_TSM_Supported_Devices_for_AIXHPSUNWIN.html)
| Linux Site web de périphériques pris en charge par IBM Tivoli Storage
| Manager pour les systèmes Linux (http://www.ibm.com/software/sysmgmt/
| products/support/IBM_TSM_Supported_Devices_for_Linux.html)
| Protection des données client et du serveur au cours du

| processus
| Pour protéger les données client et le serveur, vous devez exécuter plusieurs tâches
| lors de la phase de préparation. Planifiez une sauvegarde ou une migration de
| certains types de données vers des unités de bande non GENERICTAPE ainsi
| qu'une sauvegarde de la base de données du serveur.
| La sauvegarde de données est nécessaire pour vous assurer un retour à la version

| précédente Tivoli Storage Manager si nécessaire.
| Pour plus d'informations sur les tâches de sauvegarde, consultez les rubriques
| suivantes :
| v «Sauvegarde ou migration des données stockées sur des périphériques DISK et
| FILE», à la page 407
Linux
| v «Migration des données étant stockées sur des périphériques GENERICTAPE», à

| la page 408
| v «Déplacer les groupes de sauvegarde qui sont stockés sur les unités FILE», à la
| page 409
| v «Sauvegarde de la base de données du serveur», à la page 409
| v «Création d'un récapitulatif du contenu de la base de données», à la page 410
| Conseil : Lors de la sauvegarde de la base de données, générez deux copies de

| sauvegarde afin de la protéger en cas d'échec de support. Vérifiez qu'au moins une
| sauvegarde complète de la base de données est disponible sur site. Si vous devez
| restaurer la base de données, vous pouvez gagner du temps en ayant une copie de
| sauvegarde disponible immédiatement.
| Ne désinstallez pas le serveur V5 tant que vous n'êtes pas sûr que la migration
| vers la version6.3.4 or ou ultérieure a ete effectuée avec succès.
| Pour plus d'informations sur la protection de la base de données, voir «Protection

| et reprise de la base de données», à la page 6.

|
| Chapitre 13. Planification de la migration

| Planifiez la migration avec attention pour réduire la durée d'indisponibilité du
| système Tivoli Storage Manager. Pendant la migration, vous devez installer le
| nouveau logiciel et déplacer le contenu du serveur de base de données V5 dans la
| nouvelle base de données V6.3.4 or ou ultérieure.
| Le transfert des données de la base de données du serveur d'origine V5 vers la

| base de données V6.3.4 or ou ultérieure utilise un pourcentage élevé de la capacité
| de traitement. Le transfert requiert également un grand nombre d'activités d'E-S.
| Dans votre planification, envisagez de tester la migration sur des systèmes de

| non-production. Vous obtenez ainsi des informations sur la durée de la migration
| de la base de données du serveur, lesquelles vous aident à prévoir la durée
| d'indisponibilité du serveur. La durée de la migration varie d'une base de données
| à l'autre.
| Vous obtenez également des informations sur la taille de la nouvelle base de

| données par rapport à celle d'origine, ce qui vous permet d'évaluer plus
| précisément l'espace de stockage dont vous avez besoin.
| Si vous disposez de plusieurs serveurs, envisagez de migrer un premier serveur

| afin de voir comment le processus fonctionne avec vos données. Basez-vous sur les
| résultats que vous avez obtenus pour planifier la migration des autres serveurs.
| Pour planifier la migration, procédez comme suit:

| 1. Sélectionnez un scénario de migration. Pour plus d'informations, voir
| «Scénarios pour la migration d'un serveur à partir d'un système AIX, HP-UX,
| ou Solaris vers V6.3.4 sur Linux», à la page 388.
| 2. Vérifiez les exigences matérielles et logicielles. Pour plus d'informations, voir
| «Configurations matérielles et logicielles requises pour les serveurs version 5 et
| 6.3.4 or ou ultérieure», à la page 398.
| 3. Effectuez les étapes suivantes :
| a. «Estimation de l'espace requis pour la base de données et le journal de
| reprise», à la page 398
| b. «Estimation de la durée requise pour la migration», à la page 399
| c. «Trasfert de données de planification», à la page 400
| d. «Planification de la mise à niveau de plusieurs serveurs et composants», à
| la page 400
| e. «Préparation des changements opérationnels», à la page 400
| f. «Estimation de l'espace requis pour le stockage et les périphériques», à la
| page 401
| 4. Pour vous permettre de planifier la migration, passez en revue les informations
| suivantes :
| v «Conseils de performances pour le processus d'extraction d'une base de
| données version 5», à la page 402
| v «Conseils relatifs aux performances pour l'insertion de données dans la base
| de données version 6.3.4 or ou ultérieure», à la page 402
| v «informations de référence pour la planification de migration», à la page 403

Linux
| 5. Facultatif : Testez le processus de migration dans un environnement limité ou

| dans un environnement non dédié à laproduction.
|
| Configurations matérielles et logicielles requises pour les serveurs
| version 5 et 6.3.4 or ou ultérieure
| Vérifiez les configurations matérielles et logicielles pour les serveurs version 5 et
| version6.3.4 or ou ultérieure. Au cours de l'installation du serveur, vous pouvez
| utiliser un vérificateur de prérequis afin de confirmer la configuration système
| pour le serveur version6.3.4 or ou ultérieure.
| Au cours du processus de migration, vous devez mettre à niveau le serveur V5

| vers V5.5.6 ou une version ultérieure. Pour optimiser le processus de migration et
| éviter d'éventuels problèmes, mettez à niveau le serveur V5 vers le niveau le plus
| récent, puis installez le correctif temporaire le plus récent pour ce niveau. Suivez
| les instructions contenues dans la section «Déterminer le niveau approprié d'un
| serveur V5 avant une mise à niveau», à la page 42. Pour plus d'informations sur le
| serveur V5.5, voir le centre de documentation V5.5 Tivoli Storage Manager à
| http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1.
| Pour plus d'informations sur les configurations matérielles et logicielles pour un

| serveur version6.3.4 or ou ultérieure sur Linux x86_64, voir «Configuration du
| serveur requise pour Linux sur des systèmes x86_64», à la page 32. Pour obtenir
| des informations actualisées sur la configuration matérielle et logicielle requise,
| consultez le site de support du produit Tivoli Storage Manager à l'adresse
| http://www.ibm.com/support/docview.wss?uid=swg21243309.
| Pour plus d'informations sur le vérificateur de prérequis, voir «Exécution du

| vérificateur de prérequis», à la page 43.
| Vous devez installer une unité de bande manuelle ou une bandothèque avec au
| moins une unité de bande. L'unité de bande doit être prise en charge à la fois par
| la source et les systèmes d'exploitation cibles.
|
| Estimation de l'espace requis pour la base de données et le journal de
| reprise
| Planifiez l'espace requis pour le processus de migration, ainsi que pour les bases
| de données de serveur et le journal de reprise du serveur version 6.3.4 or ou
| ultérieure. L'espace requis pour une migration multiplateforme de la version 5 vers
| la version 6.3.4 or ou ultérieure est similaire à celui pour une mise à niveau de la
| version 5 vers la version 6.3 ou ultérieure sur le même système d'exploitation.
| Pour estimer l'espace requis pour la base de données et le journal de reprise,

| procédez comme suit.
| 1. Estimez l'espace requis pour le système du serveur version 5. Pour de plus
| amples informations, consultez la rubrique «Espace requis pour le système du
| serveur version 5», à la page 44.
| 2. Estimez l'espace requis pour le système du serveur version 6.3.4 or ou
| ultérieure. Pour de plus amples informations, consultez la rubrique «Espace
| requis pour le système du serveur version 6», à la page 45.
| 3. Estimez l'espace total pour le processus de migration et le serveur version 6.3.4
| or ou ultérieure. Pour de plus amples informations, consultez la rubrique
Linux
| «Estimation de l'espace disque total requis pour le processus de mise à niveau

| et le serveur mis à niveau», à la page 47.
| 4. Facultatif : utilisez une feuille de calcul pour planifier la quantité et
| l'emplacement de l'espace pour le serveur version 6.3.4 or ou ultérieure. Pour
| de plus amples informations, consultez la rubrique «Feuille de calcul pour
| l'espace de planification du serveur V6.3 ou ultérieure», à la page 50.
|
| Estimation de la durée requise pour la migration
| Le serveur version 5 n'est pas disponible pendant toute la durée des opérations de
| migration. Estimez la durée de la migration afin de pouvoir prévoir la durée
| d'indisponibilité du serveur. Le temps nécessaire à la migration d'un serveur
| version 5 dépend de plusieurs facteurs.
| Les facteurs suivants peuvent affecter la durée de la migration :

| v Taille de la base de données en cours de migration.
| v Nombre et vitesse des processeurs système.
| v Configuration des périphériques de stockage. Si un nouveau matériel est
| introduit, il faut un certain temps pour définir les nouveaux périphériques sur le
| serveur, tester la configuration et ajuster les pools de stockage.
| v Méthode choisie pour transférer les données de la base de données version 5
| vers la base de données version 6 :via les supports ou le réseau). Lors du
| transfert des données via le réseau, la durée d'extraction et la durée d'insertion
| se chevauchent. La méthode via le réseau peut permettre de réduire la durée
| totale de la migration grâce au chevauchement des opérations.
| v Type de charge de travail gérée par le serveur. Une charge de travail consistant
| en un grand nombre de petits fichiers ou de fichiers aux noms très longs peut
| rallonger la durée de la migration.
| Des données sont disponibles sur des mises à niveau deTivoli Storage Manager V5
| vers la V6.3 ou ultérieure sur le même système d'exploitation. Ces informations
| peuvent vous aider à estimer la durée requise pour une migration
| multi-plateforme. Dans les laboratoires IBM, les environnements de test de
| performances ont permis d'exécuter des opérations de mise à niveau de 5 à 10 Go
| par heure en utilisant la méthode via le réseau. Ce débit est calculé en fonction de
| la quantité d'espace utilisée par la base de données version 5 et non en fonction de
| l'espace attribué à cette dernière. Les résultats dépendent de la configuration. Le
| débit est plus faible si vous utilisez la méthode via les supports, car les opérations
| d'extraction et d'insertion des données s'exécutent de façon séquentielle et non
| simultanément.
| Si vous estimez la durée requise pour les opérations de mise à niveau en fonction
| de la quantité de données de la base de données, cette estimation sera
| probablement supérieure à la réalité. La base de données est composée de branches
| (arborescence) dont les noeuds finaux (ou feuilles) contiennent les enregistrements de
| la base de données. L'extraction ignore les branches et extrait uniquement les
| informations contenues dans les feuilles. Ainsi, la quantité de données extraites par
| l'utilitaire d'extraction peut être largement inférieure à l'espace total utilisé par la
| base de données (qui inclut l'ensemble des informations contenues dans les feuilles
| et dans les branches). Il est impossible de déterminer à l'avance la quantité de
| données à extraire par rapport à la taille totale de la base de données. C'est la
| raison pour laquelle votre estimation sera probablement supérieure à la durée
| réelle de l'opération.
Chapitre 13. Planification de la migration 399

Linux
| Les résultats obtenus dans votre environnement peuvent être différents de ceux
| obtenus dans les laboratoires. Il est particulièrement important de tester les
| opérations de migration dans votre environnement pour les serveurs Tivoli Storage
| Manager utilisés par les systèmes essentiels.
|
| Trasfert de données de planification
| Toutes les données qui sont stockées sur des périphériques DISK ou FILE doivent
| être transférées ou sauvegardées sur des unités de bande non-GENERICTAPE
| avant le démarrage de la migration. Les données stockées sur les périphériques
| GENERICTAPE doivent être migrées vers les unités de bandes non-GENERICTAPE
| Lorsque vous planifiez le transfert des données, assurez-vous que vous disposez
| du volume de bandes disponibles pour la sauvegarde et le stockage de données:
| v Les volumes de bande doivent au moins être disponibles pour sauvegarder le
| pool de stockage principal..
| v Les unités de bandes doivent être accessibles à la fois pour les systèmes V5 et
| V6.
| v Les unités de bandes doivent être accessibles à la fois pour les systèmes V5 et
| V6. Pour plus d'informations sur les périphériques qui peuvent être utilisés,
| consulter le site de votre système d'exploitation:
| – AIX HPUX Solaris Les périphériques pris en charge sous les
| systèmes AIX, HP-UX, Solaris, et Windows (http://www.ibm.com/software/
| sysmgmt/products/support/
| IBM_TSM_Supported_Devices_for_AIXHPSUNWIN.html)
| – Linux Périphériques pris en charge sous les systèmes Linux
| (http://www.ibm.com/software/sysmgmt/products/support/
| IBM_TSM_Supported_Devices_for_Linux.html)
| v Pour optimiser le processus, des volumes de bande doivent être disponibles
| pour créer une seconde sauvegarde sur site du pool de stockage principal. En
| créant un pool de stockage de sauvegarde hors site et un autre sur site, vous
| respectez les exigences de reprise après incident du stockage hors site.
| Parallèlement, les volumes du second pool sont disponibles sur site pour
| restaurer les données immédiatement après la migration.
|
| Planification de la mise à niveau de plusieurs serveurs et composants
| Si votre environnement inclut plusieurs serveurs et agents de stockage, évaluez la
| compatibilité des versions actuelles avec un serveur V6.3.4 or ou ultérieure mis à
| niveau. Prévoyez de mettre à niveau un premier serveur dans un environnement
| de test. Echelonnez ensuite les mises à niveau des serveurs et des agents de
| stockage supplémentaires.
| Pour obtenir des informations sur la compatibilité des agents de stockage et des
| clients de bibliothèque avec les serveurs Tivoli Storage Manager version 6.3 ou
| ultérieure, voir la note technique 1302789 (http://www.ibm.com/support/
| docview.wss?uid=swg21302789).
|
| Préparation des changements opérationnels
| Lorsque vous migrez votre système de la version 5 vers la version 6.3.4 or ou
| ultérieure, la méthode de sauvegarde et de surveillance de la base de données du
| serveur change.
Linux
| Vérifiez les procédures d'exploitation, les scripts et les plannings d'administration

| que vous utilisez pour les opérations du serveur :
| v Prévoyez d'effectuer des sauvegardes régulières de la base de données à l'aide
| de plannings d'administration, d'un script de maintenance ou de vos propres
| scripts. Sauvegardez la base de données du serveur au moins une fois par jour.
| Pour de meilleurs résultats, envisagez de planifier des sauvegardes plus
| fréquentes pour la base de données version 6.3.4 or ou ultérieure que vous ne
| l'avez fait pour la base de données version 5. Pour être certain que l'espace de
| journal d'archivage est élagué, envisagez de planifier plus de sauvegardes de
| base de données complètes et moins de sauvegardes incrémentielles.
| Pour plus d'informations sur la planification de sauvegardes de bases de
| données, voir la section sur sauvegarder la base de données dans Guide
| d'administration.
| v Découvrez comment l'espace de la base de données et du journal de reprise est
| utilisé et comment la surveillance doit être modifiée.
| v Vérifiez les scripts et les plannings d'administration. En commençant par le
| serveur V6 Tivoli Storage Manager, de nouvelles commandes ont été modifiées
| et certaines commandes qui étaient devenues inutiles ont été supprimées. Ces
| modifications affecteront vos opérations automatisées. Pour plus d'informations
| sur les commandes nouvelles et modifiées, voir «Modifications apportées aux
| commandes et options», à la page 60.
| v Vérifiez les commandes SELECT que vous utilisez régulièrement. Un certain
| nombre de paramètres et de syntaxes précédemment autorisés ne sont pas
| acceptés par le programme du gestionnaire de base de données. Pour plus
| d'informations sur les mises à jour de la commande SELECT, voir «Modifications
| apportées à la commande SELECT», à la page 79. Pour résoudre les problèmes liés
| aux commandes SELECT, voir la note technique 1380830 (http://www.ibm.com/
| support/docview.wss?uid=swg21380830).
| v Si vous utilisez des produits d'éditeurs de logiciels indépendants en guise
| d'interface avec le serveur, assurez-vous qu'ils sont compatibles avec le serveur
| version 6.3.4 or ou ultérieure.
| Pour utiliser les nouvelles fonctions disponibles dans Tivoli Storage Manager V6.3
| ou ultérieure, installez la dernière version du Centre d'Administration.
|
| Estimation de l'espace requis pour le stockage et les périphériques
| Estimez la quantité d'espace requise pour le stockage du système Tivoli Storage
| Manager V6.3.4 or ou ultérieure. Planifiez les périphériques à utiliser pour le
| stockage.
| Pour planifier le stockage et les périphériques, procédez comme suit :

| 1. Estimez l'espace requis pour le stockage sur le nouveau système Tivoli Storage
| Manager version 6.3.4 or ou ultérieure. Pour plus de détails, voir la section
| décrivant l'estimation d'espace requis pour les pools de stockage à accès
| séquentiel dans le Guide d'administration.
| 2. Planifiez l'espace requis pour les périphériques pour le nouveau système Tivoli
| Storage Manager version 6.3.4 or ou ultérieure. Pour plus de détails, voir la
| section relative à la planification de la configuration des unités dans le Guide
| d'administration.

Linux
|
| Conseils de performances pour le processus d'extraction d'une base
| de données version 5
| La vitesse du processus d'extraction est par nature limitée par le débit d'E-S vers la
| destination des données.
| La durée du processus dépend également de la taille de la base de données. Cette

| durée est approximativement équivalente à celle requise pour une sauvegarde
| complète de la base de données.
| Ne réorganisez pas la base de données Tivoli Storage Manager version 5 avant la

| mise à niveau. Une capacité de traitement plus rapide peut être obtenue lorsque la
| base de données source ne contient pas de longues séquences de pages attribuées à
| une table de données unique. Suivez ces instructions pour la méthode support et la
| méthode réseau.
| Les astuces de performances suivantes dépendent de la méthode choisie pour le

| transfert de données à partir de la base de données version 5 :
| Via des supports
| Si vous utilisez une méthode de support, et si vous extrayez les données
| sur bande, utilisez une unité de bande à haute vitesse.
| Via un réseau
| Si vous utilisez une méthode réseau, utilisez un lien à haute vitesse. Pour
| mettre à niveau une base de données de plus de 2 ou 3 Go, utilisez au
| moins un réseau Ethernet d'1 Go.
|
| Conseils relatifs aux performances pour l'insertion de données dans la
| base de données version 6.3.4 or ou ultérieure
| Le processus d'insertion des données de la version 5 extraites dans la base de
| données version 6.3.4 or ou ultérieure est la partie la plus longue du processus de
| migration et la plus critique pour la configuration du système.
| Sur un système qui répond aux exigences minimales, le processus d'insertion

| s'exécute, mais les performances peuvent être faibles. Pour optimiser ces dernières,
| configurez le système comme indiqué dans les conseils suivants.
| Processeurs
| Le processus d'insertion est destiné à utiliser plusieurs processeurs ou
| coeurs. Le processus d'insertion s'exécute généralement plus efficacement
| sur un système doté d'un nombre relativement moins élevé de processeurs
| rapides. Si le système est doté de nombreux processeurs lents, vous pouvez
| atteindre des niveaux de performances réduits.
| Espace de stockage sur disque
| Le processus d'insertion est destiné à utiliser des sous-systèmes de
| stockage sur disque à bande passante élevée. La vitesse du processus est
| étroitement liée à l'espace de stockage sur disque utilisé.
| Pour des performances optimales, utilisez plusieurs numéros d'unité
| logique mappés vers plusieurs disques indépendants ou vers des
| ensembles redondants de disques indépendants (RAID) dont la taille des
| segments est élevée (128 ko, par exemple). Utilisez un système de fichiers
| différent sur chaque numéro d'unité logique.
| Le tableau suivant illustre le bon usage des numéros d'unité logique.
Linux
| Tableau 68. Exemple d'utilisation des numéros d'unité logique

| Numéro
| d'unité
| logiqsue
| (LUN) Utilisation
| 1 Journal actif
| 2 Journal d'archivage
| 3, 4, 5 Répertoires de bases de données
| 6 Base de données V5 extraite, nécessaire uniquement si la méthode
| de support est utilisée pour extraire la base de données V5 pour
| une classe d'unité séquentielle
|
| Si l'espace de stockage sur disque est fourni par une unité de virtualisation
| (contrôleur de stockage haut de gamme ou unité de virtualisation SAN),
| vérifiez qu'aucun numéro d'unité logique virtuel ne figure sur la même
| unité de disque physique. Assurez-vous que les répertoires utilisés sont
| placés sur des unités de disque physiques différentes au sein de l'unité de
| virtualisation.
|
| informations de référence pour la planification de migration
| Les informations sur les nouvelles commandes d'administration supprimées,
| changées, les options de serveur, et les messages de serveur peuvent vous aider à
| planifier la migration.
| Pour plus d'informations, voir «Informations de référence pour la planification», à

| la page 60.

|
| Chapitre 14. Préparation de la migration

| Pour préparer votre système pour la migration entre serveurs de V5 à V6.3.4 or ou
| ultérieure, vous devez effectuer plusieurs étapes. Assurez-vous avoir vérifié les
| conditions requises pour la migration et mettez à niveau le version 5 à la version
| 5.5.6 ou ultérieure. Puis, préparez des données stockées sur des unités DISK, FILE
| et GENERICTAPE pour la migration puis sauvegardez la base de données du
| serveur.
|
| Préparation de l'espace pour le processus de migration
| Vérifiez que vous disposez d'un espace suffisant sur le système version 6.3.4 or ou
| ultérieure pour le processus de migration.
| 1. Vérifiez que l'espace disque du système correspond à celui estimé lors de
| l'étape de planification. Utilisez la feuille de travail de planification que vous
| avez remplie avec vos informations.
| 2. Si vous prévoyez d'extraire la base de données du serveur d'origine vers un
| support pour l'insérer ultérieurement dans une nouvelle base de données,
| vérifiez que vous disposez d'un espace de stockage suffisant. L'espace de
| stockage est requis pour la base de données et le fichier manifeste créé par le
| processus d'extraction. Procédez comme suit :
| a. Identifiez la classe d'unités vers laquelle vous allez extraire la base de
| données d'origine. La définition doit exister dans la base de données du
| serveur et pas uniquement dans le fichier de configuration d'unité.
| La classe d'unités doit être séquentielle et le type de classe d'unités doit être
| une bande. L'unité de bande doit être compatible avec la version 5 et le
| système V6.3.4 or ou ultérieure. Définissez une nouvelle classe d'unités si
| nécessaire.
| b. Vérifiez que des espaces ou des volumes sont disponibles dans la classe
| d'unités sélectionnée. La quantité d'espace nécessaire est à peu près la
| même que la taille actuelle de la base de données d'origine.
| Assurez-vous que l'ID utilisateur d'instance que vous créez pour le serveur
| mis à niveau dispose des droits d'accès à l'emplacement d'extraction des
| données.
| c. Vérifiez que les droits d'accès sont corrects pour l'emplacement que vous
| prévoyez de spécifier pour le fichier manifeste.
| Lorsque les données seront insérées dans la base de données version 6.3.4 or
| ou ultérieure, l'ID utilisateur de l'instance que vous utilisez pour le serveur
| mis à niveau doit avoir des droits d'accès sur le fichier manifeste.
| La taille du fichier manifeste peut être inférieure à 1 Ko. Cependant, pour
| une configuration complexe, elle peut dépasser 1 Ko.
|
| Mise à niveau du serveur version 5 vers la version 5.5.6 ou version
| ultérieure
| Mettez à niveau le serveur version 5 vers la version 5.5.6 ou ultérieure de sorte à
| pouvoir utiliser les fonctionnalités conçues pour vous aider à préparer la
| migration.

Linux
| Le serveur Tivoli Storage Manager ne doit pas être en cours d'exécution durant
| l'installation du serveur V5.5.6 ou lors de la mise en oeuvre des groupes de
| correctifs ultérieurs
| Pour installer un groupe de correctifs sur le serveur, vous devez avoir installé le
| package de licences de Tivoli Storage Manager. Le package de licences est fourni
| lors de l'achat d'une édition de base.
| Avant la mise à niveau du serveur Tivoli Storage Manager, vérifiez que vous
| possédez le support d'installation d'édition de la base du serveur installé. Si vous
| avez installé Tivoli Storage Manager à partir d'un DVD, vérifiez que le DVD est
| disponible. Si vous avez installé Tivoli Storage Manager à partir d'un module
| téléchargé, vérifiez que les fichiers téléchargés sont disponibles. Si la mise à niveau
| échoue et que le module de licence du serveur est désinstallé, le support
| d'installation d'édition de la base de serveur est nécessaire pour réinstaller la
| licence.
| 1. Le fichier de pack de la version V5.5.6 ou version groupe de correctifs
| ultérieurs est disponible sur le site de téléchargement FTP Tivoli Storage
| Manager àftp://public.dhe.ibm.com/storage/tivoli-storage-management/
| maintenance/server/v5r5/MVS/LATEST .
| 2. Pour obtenir des informations sur l'installation, consultez le fichier README.txt,
| qui est disponible dans le fichier de pack version 5.5.6 ou ultérieure.
| 3. Installez le groupe de correctifs version 5.5.6 ou ultérieure.
| Pour de plus amples informations sur le serveur Tivoli Storage Manager version
| 5.5, consultez le centre de documentation de Tivoli Storage Manager version 5.5
| disponible à l'adresse suivante : http://publib.boulder.ibm.com/infocenter/
| tivihelp/v1r1/index.jsp.
|
| Désactivation des sessions
| En préparation de la migration, évitez toute activité sur le serveur en désactivant
| les nouvelles sessions. Annulez toute session existante.
| Les commandes contenues dans la procédure suivante sont des commandes

| d'administration de Tivoli Storage Manager.
| Pour désactiver les sessions, effectuez les étapes suivantes:

| 1. Empêchez tous les clients, agents de stockage et autres serveurs, de démarrer
| de nouvelles sessions avec le serveur. Utilisez les commandes suivantes :
| Désactivez le client de session
| Désactivez le serveur de session.
| Pour plus d'informations sur la commande DISABLE SESSIONS et d'autres
| commandes d'administration, voir le document Guide de référence
| d'administration.
| 2. Empêchez toute activité d'administration effectuée par un ID utilisateur autre
| que l'ID administrateur utilisé pour effectuer la préparation de la migration.
| Verrouillez les autres ID administrateur, si nécessaire . Utilisez la commande
| suivante :
| lock admin nom_administrateur
| où administrator_name indique le nom de l'administrateur.

| 3. Vérifiez si des processus serveur sont en cours d'exécution. Annulez les
| processus ou laissez-les se terminer. Utilisez les commandes suivantes :
Linux
| traitement de requêtes
| annulez le processus numéro_processus
| où process_number indique le nom du processus. Attendez que les processus

| soient arrêtés. L'arrêt de certains processus, comme le processus de migration
| de pools de stockage peut prendre un certain temps.
| 4. Recherchez toute session existante et prévenez les utilisateurs que le serveur va
| être arrêté. Pour rechercher les sessions existantes, utilisez la commande
| suivante :
| query session
| 5. Annulez les sessions encore actives. Utilisez la commande :
| annulation de session all
|
| Sauvegarde ou migration des données stockées sur des périphériques
| DISK et FILE
| Avant de faire migrer le serveur, assurez-vous que toutes les données qui sont
| stockées sur des périphériques DISK et FILE sont sauvegardées ou migrées vers
| des unités de bandes non-GENERICTAPE. Cette étape est nécessaire parce que les
| données qui sont stockées sur les périphériques DISK et FILE ne peuvent être
| migrées dans le cadre d'une migration multi-plateforme.
| Pour sauvegarder des données sur bande et marquer les volumes originaux comme
| détruits, procédez comme suit:
| 1. Créer un pool de stockage de copies pour une unité de bande en exécutant la
| commande DEFINE STGPOOL. Par exemple, pour créer un pool de stockage de
| copies dénommé ltocopypool, et affecté à la classe d'unités LTOCLASS,
| exécutez la commande suivante:
| define stgpool ltocopypool ltoclass pooltype=copy
| Pour plus d'informations sur la commande DEFINE STGPOOL et d'autres
| commandes Tivoli Storage Manager, voir le document Guide de référence
| d'administration.
| 2. Sauvegarder un pool de stockage principal sur un périphérique DISK ou FILE
| en exécutant la commande BACKUP BACKUP STGPOOL. Par exemple, pour
| sauvegarder un pool principal de stockage de copies dénommé primary_pool
| dans un pool de stockage de copies dénommé ltocopypool, exécutez la
| commande suivante:
| backup stgpool primary_pool ltocopypool
| 3. Mettre hors fonction les volumes de pools de stockage primaire sur disque à
| l'aide de la commande VARY. Par exemple, pour mettre hors fonction un pool de
| stockage dénommé primary_disk_pool, exécutez la commande suivante:
| Mettre primary_disk_pool hors fonction
| 4. Pour faire en sorte que les volumes originaux soient marqués "détruits",
| modifiez le mode d'accès de chaque volume des pools de stockage principaux
| en mode "détruit". Utilisez la commande UPDATE VOLUME. Par exemple, si le nom
| du pool de stockage principal est primary_pool, marquez les volumes situés
| dans le pool comme étant des volumes "détruits" en exécutant la commande
| suivante:
| update volume * wherestgpool=primary_pool access=destroyed
| Si vous préférez faire migrer les données, vous pouvez utiliser la commande
| MIGRATE STGPOOL, la commande MOVE DATA, ou encore la commande MOVE NODEDATA,
| en fonction du répertoire où Les données sont stockées et de la façon dont vous
Chapitre 14. Préparation de la migration 407

Linux
| envisagez les déplacer. Pour plus d'informations, consulter la partie sur la

| migration des données d'un d'un disque vers une bande magnétique dans Guide
| d'administration.
| Après avoir fait migré le serveur vers V6.3.4 or ou ultérieure, vous pouvez
| déplacer les données de la bande magnétique vers un pool de stockage qui accède
| plus rapidement aux données. Par exemple, vous pouvez faire migrer les données
| vers un pool de stockage à accès aléatoire qui utilise une classe d'unité DISK. Vous
| pouvez également faire migrer ou restaurer les données d'un pool de stockage qui
| utilise une classe d'unité FILE.
|
| Migration des données étant stockées sur des périphériques
| GENERICTAPE
| Avant de migrer le serveur, procédez à la migration de toutes les données étant
| stockées sur les périphériques GENERICTAPE vers les unités de bande
| non-GENERICTAPE. Cette étape est nécessaire parce que les données qui sont
| stockées sur les périphériques GENERICTAPE ne peuvent être migrées dans le
| cadre d'une migration multi-plateforme.
| Pour migrer les données stockées sur les périphériques GENERICTAPE, effectuez
| les étapes suivantes:
| 1. Créez un pool de stockage à accès séquentiel principal sur une unité de bande
| non-GENERICTAPE en exécutant la commande DEFINE STGPOOL.
| Par exemple, pour créer un pool de stockage de copies dénommé ltopool qui
| est affecté à la classe d'unités LTOCLASS, effectuez la commande suivante:
| define stgpool ltopool ltoclass
| Pour plus d'informations sur la création de pools de stockage, voir la
| commande DEFINE STGPOOL dans Guide de référence d'administration.
| 2. Pour fournir un emplacement pour les fichiers qui seront migrés, configurez le
| pool de stockage principal suivant. Utilisez la commande UPDATE STGPOOL.
| Par exemple, pour mettre à jour un pool de stockage principal dénommé
| gentapepool par l'ajout d'un autre pool de stockage dénommé ltopool et
| déterminer un seuil élevé de migration défini à 100, exécutez la commande
| suivante :
| update stgpool gentapepool nextstgpool=ltopool highmig=100
| Pour plus d'informations sur la configuration du pool de stockage principal
| suivant, voir la commande UPDATE STGPOOL dans Guide de référence
| d'administration.
| 3. Migrer les données du pool de stockage GENERICTAPE vers un pool de
| stockage non GENERICTAPE à l'aide de la commande MIGRATE STGPOOL. Par
| exemple, pour migrer un pool de stockage dénommé gentapepool vers le pool
| de stockage sivant et déterminer un seuil bas de migration d'une valeur 0,
| exécutez la commande suivante:
| migrate stgpool gentapepool lowmig=0
| Pour plus d'informations sur la migration des pools de stockage, voir la section
| qui décrit comment transférer des données dans Guide d'administration. Voir
| également la commande MIGRATE STGPOOL dans Guide de référence
| d'administration.
Linux
|
| Déplacer les groupes de sauvegarde qui sont stockés sur les unités
| FILE
| Avant de migrer le serveur, déplacez tous les groupes de sauvegarde stockés sur
| les unités FILE vers le système dans lequel vous planifiez d'installer le serveur
| V6.3.4 or ou ultérieure.
| Pour identifier les groupes de sauvegarde stockés sur les unités FILE et les
| déplacer vers le système cible, procédez comme suit :
| 1. Obtenez une liste détaillée de volumes qui sont associés au groupe de
| sauvegarde en lançant la commande QUERY BACKUPSET :
| query backupset f=d
| Pour plus d'informations sur l'obtention d'une liste de volumes, voir la
| commande QUERY BACKUPSET dans Guide de référence d'administration.
| 2. Révisez la sortie pour savoir quels sont les groupes de sauvegarde qui sont
| stockés dans les unités FILE.
| 3. Copiez les volumes qui sont associés aux groupes de sauvegarde sur les unités
| FILE vers le système cible. Par exemple, copiez les volumes vers un serveur
| FTP sur le système cible. Les volumes doivent être copiés vers un emplacement
| où ils seront accessible par l'ID utilisateur de l'instance de serveur. Si possible,
| conservez la structure qui utilisée sur le système source. S'il est impossible de
| conserver la structure du fichier dans le système source, copiez les volumes
| vers tous les emplacements sur le système cible.
| A faire : Si vous ne pouvez pas conserver la structure du fichier utilisée sur le

| système cible, vous devez remplir plus d'étapes après la migration du serveur.
| La commande DELETE BACKUPSET permet de supprimer les entrées de volume
| précédentes de la base de données et permet également à la commande DEFINE
| BACKUPSET de recréer les groupes de sauvegarde à laide des volumes dans leur
| nouvel emplacement.
|
| Sauvegarde de la base de données du serveur
| Juste avant de migrer le serveur Tivoli Storage Manager,sauvegardez la base de
| données du serveur dans une unité de bande non-GENERICTAPE.
| Effectuez une sauvegarde par image, qui permet d'effectuer une sauvegarde
| complète de la base de données sans interrompre les sauvegardes planifiées.
| Utilisez la commande suivante :
| backup db type=type devclass=nom_classe_unités
| où type indique le type de sauvegarde de base de données et device_class_name

| indique le nom de la classe d'unités. La classe d'unités que vous indiquez doit
| exister et avoir des volumes disponibles.
| Par exemple, pour sauvegarder une base de données en utilisant les volumes
| utilisables, dans une unité appartenant à la classe d'unités TAPECLASS, exécutez la
| commande:
| backup db type=dbsnapshot devclass=tapeclass
| Pour utiliser des volumes spécifiques, indiquez leur nom dans la commande.
| Conseil : pour protéger la sauvegarde des incidents avec le support, faites deux
| copies de la sauvegarde. Assurez-vous qu'au moins une sauvegarde de base de

Linux
| données complète est disponible sur place. Si vous devez restaurer la base de
| données originale, le fait d 'avoir une sauvegarde sur site vous permet de gagner
| du temps vu qu'elle est immédiatement disponible.
| Pour plus d'informations sur la sauvegarde des bases de données, voir la

| commande BACKUP DB dans Guide de référence d'administration.
|
| Création d'un récapitulatif du contenu de la base de données
| Créez un récapitulatif du contenu de la base de données d'origine. Après la mise à
| niveau, vous pouvez utiliser les mêmes commandes pour comparer les résultats et
| confirmer que le contenu de la base de données est intact.
| Exécutez des commandes qui fournissent un récapitulatif des informations relatives

| au contenu de la base de données. Par exemple, lancez les commandes qui
| présentent un résumé des espaces fichier protégés et sauvegardez les résultats.
| Pour la liste des commandes, voir «Exemples des commandes à exécuter pour
| valider la mise à niveau de la base de données», à la page 583.
|
| Modification du serveur pour prévenir les problèmes potentiels
| Pour prévenir des problèmes potentiels pendant et après la migration, modifiez le
| serveur V5.
| Avant de modifier le serveur, reportez-vous aux étapes de rétablissement de la

| version antérieure du serveur dans la section «Rétablissement de la version 5 du
| serveur à partir de la version 6.3.4 or ou ultérieure», à la page 473.
| 1. Pour prévenir un problème avec les espaces fichier UNIX System Services,
| exécutez la commande suivante dans une ligne de commande d'administration
| Tivoli Storage Manager :
| convert ussfilespace
| Cette commande permet de corriger un incident qui peut se produire avec les
| bases de données Tivoli Storage Manager antérieures. Si le problème se produit
| dans votre base de données, la commande s'exécute et vous pouvez voir le
| message d'erreur ANR2034E s'afficher. Cette erreur peut être ignorée. Pour plus
| d'informations, voir la note technique 1408895 (http://www.ibm.com/support/
| docview.wss?uid=swg21408895). Si le problème se produit dans votre base de
| données, l'exécution de la commande peut prendre un certain temps.
| Important : Si vous n'exécutez pas cette commande, l'utilitaire DSMUPGRD

| PREPAREDB peut échouer. Vous devez redémarrer le serveur version 5 et exécuter
| la commande CONVERT USSFILESPACE avant de poursuivre avec le processus de
| mise à niveau.
| 2. Ajustez les paramètres du serveur et des clients de la manière suivante. Ces
| ajustements doivent être effectués pour vous permettre de revenir au serveur
| d'origine après la migration, si un problème se produit.
| a. Pour chaque pool de stockage à accès séquentiel sur bande magnétique,
| utilisez la commande UPDATE STGPOOL pour définir le paramètre REUSEDELAY.
| Définissez le paramètre au nombre de jours pendant lesquels vous
| souhaitez être en mesure de revenir au serveur d'origine, si nécessaire.
| Par exemple, si vous souhaitez être en mesure de revenir au serveur
| d'origine pendant plus de 30 jours après la migration, définissez le
| paramètre REUSEDELAY à 31 jours :
Linux
| update stgpool pool_stockage_accès_séquentiel reusedelay=31
| où sequential_access_storage_pool indique le nom du pool de stockage. Pour

| plus d'informations sur la configuration du paramètre REUSEDELAY, voir la
| commande UPDATE STGPOOL dans Guide de référence d'administration.
| b. Pour chaque pool de stockage de copie sur bande, utilisez la commande
| QUERY STGPOOL pour déterminer la valeur du paramètre RECLAIM. Notez la
| valeur pour une référence ultérieure. Si vous devez revenir au serveur V5 à
| tout moment pendant le processus de migration, il serait utile de connaître
| la valeur du paramètre RECLAIM pour pouvoir restaurer la configuration.
| Lancez la commande suivante :
| query stgpool sequential_access_storage_pool format=detailed
| où sequential_access_storage_pool indique le nom du pool de stockage de

| copie. Dans la sortie système, la valeur du paramètre RECLAIM se trouve
| dans le champReclamation Threshold (seuil de réclamation). Pour plus
| d'informations sur la manière de déterminer de la valeur du paramètre
| RECLAIM, voir la commande QUERY STGPOOL dans Guide de référence
| d'administration.
| c. Pour chaque pool de stockage de copie sur bande, utilisez la commande
| UPDATE STGPOOL pour définir le paramètre RECLAIM à 100, c'est-à-dire 100%.
| Par exemple, exécutez la commande suivante :
| update stgpool pool_stockage_copie reclaim=100
| où copy_storage_pool indique le nom du pool de stockage de copie.

| d. Pour tous les volumes de bande qui ont été utilisés par le serveur V5,
| indiquez le mode d'accès read-only (en lecture seule). Emettez la
| commande d'administration suivante :
| update volume tape_volume access=readonly
| où tape_volume indique le nom du volume de bande. Pour plus

| d'informations sur la spécification du mode read-only (eb lecture seule),
| voir la commandeUPDATE VOLUME dans Guide de référence d'administration.
| e. Pour les clients qui jouent un rôle primordial dans votre système, vérifiez
| que la valeur de l'option client schedlogretention est définie pour
| conserver le journal des opérations planifiées du client pendant le temps
| nécessaire.
| Le journal des opérations planifiées du client peut être utile si vous devez
| retourner le système au serveur d'origine. Si la période de conservation du
| journal est trop courte, les informations qu'il contient pourraient être
| supprimées trop tôt.
| Par exemple, pour élaguer le journal tous les 45 jours et sauvegarder les
| entrées de journal, ajoutez l'option suivante :
| schedlogretention 45 S
| où 45 indique le nombre de jours et S indique que les entrées seront

| sauvegardées.
| Placez l'option client schedlogretention dans le fichier dsm.sys à l'intérieur
| d'une section serveur.
| Pour plus d'informations sur l'élagage du journal, voir l'option
| clientschedlogretention dans Guide d'installation et d'utilisation du client de
| sauvegarde-archivage.

Linux
|
| Arrêt du serveur avant la migration
| Sur le serveurTivoli Storage Manager version 5.5.6 ou ultérieur, arrêtez tous les
| processus serveur. Puis, démontez toutes les bandes montées et arrêtez le serveur.
| Pour arrêter le serveur avant d'installer la mise à niveau, utilisez les commandes
| d'administration de Tivoli Storage Manager :
| 1. Vérifiez si des processus serveur sont en cours d'exécution. Annulez les
| processus ou laissez-les se terminer. Utilisez les commandes suivantes :
| query process
| cancel process numéro_processus
| Attendez que les processus soient arrêtés. L'arrêt de certains processus, comme
| le processus de migration de pools de stockage peut prendre un certain temps.
| Pour plus d'informations sur la requête ou l'annulation de processus, voir les
| commandes QUERY PROCESS et CANCEL PROCESS dans le Guide de référence
| d'administration.
| 2. Une fois toutes les sessions et tous les processus arrêtés, vérifiez si des bandes
| sont montées. Démontez toutes les bandes montées. Utilisez les commandes
| suivantes :
| query mount
| dismount volume nom_volume
| Pour plus d'informations sur la désinstallation des bandes, voir les commandes
| QUERY MOUNT et DISMOUNT VOLUME dans le Guide de référence d'administration.
| 3. Arrêtez le serveur. Utilisez la commande :
| halte
|
| Installation des utilitaires de mise à niveau
| Vous devez installer les utilitaires de mise à niveau sur le système où se trouve le
| serveur version 5. Les fonctionnalités de mise à jour permettent de préparer et
| d'extraire les données d'une base de données serveur V5 en vue de les insérer dans
| une base de données vide du serveur V6.
| Utilisez la procédure correspondant à votre système d'exploitation :

| v AIX «Installation des utilitaires de mise à niveau sur des systèmes AIX»
| v HPUX «Installation des utilitaires de mise à niveau sur des systèmes HP-UX»
| , à la page 414
| v Solaris «Installation des utilitaires de mise à niveau sur des systèmes Oracle
| Solaris », à la page 415
| Installation des utilitaires de mise à niveau sur des systèmes

| AIX
| AIX
| Vous devez installer V5.5.6 ou les plus récents utilitaires de mise à niveau sur le
| système où se trouvent le serveur d'origine et sa base de données. Le module à
| installer peut être téléchargé à partir du site des téléchargements FTP.
| 1. Procurez-vous le module des utilitaires de mise à niveau depuis le site de
| téléchargement FTP.
Linux
| a. Consultez le site ftp://public.dhe.ibm.com/storage/tivoli-storage-

| management/maintenance/server-upgrade/v5r5/
| b. Accédez au répertoire AIX. A patir de ce répertoire, ouvrez le répertoire
| 5.5.6.x ou une version ultérieure. Le niveau doit être identique ou ultérieur
| à celui du serveur V5 que vous mettez à niveau.
| c. Téléchargez le module dans un emplacement approprié sur le système du
| serveur. Le nom du module se présente sous la forme suivante :
| 5.5.x.x-TIV-TSMUPG-AIX.tar.gz
| Les nombres présents au début du nom identifient le niveau d'édition du
| module des utilitaires de mise à niveau.
| d. Facultatif : Pour installer les messages dans une langue autre que l'anglais,
| ouvrez le répertoire LANG et téléchargez un module de langue. Les
| messages traduits sont disponibles dans le module de langue habituel
| pour serveur version 5.
| 2. Connectez-vous avec l'ID utilisateur root.
| 3. Vérifiez que les ensembles de fichiers suivants sont installés sur le système :
| xlC.rte 8.0.0.5 ou version ultérieure
| gsksa.rte 7.0.4.11
| Vous pouvez utiliser les commandes suivantes pour vérifier ces jeux de
| fichiers :
| lslpp -L xlC.rte
|
| lslpp -L gsksa.rte
| Si nécessaire, vous pouvez obtenir le jeu de fichiers gsksa.rte version 5.5 à

| partir de tout module de maintenance régulier pour le serveur AIX. Les
| modules de maintenance sont disponibles sur le site de téléchargement FTP :
| ftp://public.dhe.ibm.com/storage/tivoli-storage-management/maintenance/
| server/v5r5/AIX/
| 4. Extrayez le contenu du module d'utilitaires de mise à niveau. Si vous avez
| téléchargé un module de langue, extrayez également son contenu.
| 5. Accédez au répertoire qui correspond à l'architecture de processeur du
| système d'exploitation.
| 6. Accédez à l'outil SMIT (System Management Interface Tool).
| a. Entrez la commande smitty install_update
| b. Sélectionnez Install and Update Software > Install and Update from ALL
| Available Software.
| 7. Sélectionnez l'unité de type INPUT. Indiquez l'emplacement du répertoire du
| module des utilitaires de mise à niveau sur le système.
| 8. Sélectionnez Software to Install (Logiciels à installer). Appuyez sur F4 ou sur
| Echap+4 pour afficher la liste des ensembles de fichiers disponibles dans le
| répertoire.
| 9. Sélectionnez les ensembles de fichiers pour les utilitaires de mise à niveau
| ainsi que le pilote de périphérique et éventuellement le module de langue. Le
| jeu de fichiers correspondant aux utilitaires de mise à niveau est
| tivoli.tsmupg.server. Les modules de langue facultatifs comprennent des
| messages dans d'autres langues que l'anglais.
| 10. Paramétrez COMMIT software updates sur Yes. Appuyez sur la touche F4 ou
| sur Echap+4.
| 11. Paramétrez SAVE replaced files sur No.

Linux
| 12. Assurez-vous que les paramètres par défaut des options de la fenêtre
| indiquent success pour tous les jeux de fichiers sélectionnés.
| 13. Appuyez sur la touche Entrée et répondez à la question ARE YOU SURE? en
| appuyant à nouveau sur cette touche. L'installation commence.
| 14. Une fois l'installation terminée, quittez le programme SMIT.
| 15. Facultatif : Si vous avez installé un module de langue, vérifiez que la variable
| d'environnement local est définie pour utiliser ce module. Entrez la
| commande suivante pour définir la variable d'environnement des paramètres
| régionaux au niveau des messages :
| export LC_MESSAGES=xxxx
| où xxxx correspond aux paramètres régionaux à utiliser. Par exemple, utilisez

| it_IT pour l'italien. Pour que les utilitaires de mise à niveau fonctionnent avec
| les paramètres régionaux souhaités, indiquez la valeur true au niveau des
| instructions suivantes :
| v Les paramètres régionaux sont installés sur le système.
| v Les utilitaires de mise à niveau prennent en charge les paramètres
| régionaux.
| v Le module de langue installé pour les utilitaires de mise à niveau
| correspond aux paramètres régionaux.

| HP-UX
| HPUX
| b. Accédez au répertoire HP-UX. A partir de ce répertoire, ouvrez le répertoire
| 5.5.6.x ou une version ultérieure. Le niveau doit être identique ou ultérieur
| à celui du serveur V5 que vous mettez à niveau.
| 5.5.x.x-TIV-TSMUPG-platforme.tar.gz
| ouvrez le répertoire LANG et téléchargez un module de langue. Les messages
| traduits sont disponibles dans le module de langue habituel pour serveur
| version 5.
| 3. Extrayez le contenu du module d'utilitaires de mise à niveau. Par exemple,
| lancez la commande suivante à partir du répertoire dans lequel vous avez
| sauvegardé le module téléchargé :
| gzip
| -dc nom_module.tar.gz | tar -xvf -
Linux
| 4. Accédez au répertoire qui correspond à l'architecture de processeur du système

| d'exploitation.
| 5. Installez les utilitaires de mise à niveau et le pilote de périphérique. Utilisez
| l'argument source (-s) pour indiquer le répertoire dans lequel le module a été
| extrait. Par exemple, s'il s'agit du répertoire /tmp/TSM, lancez la commande
| suivante :
| swinstall -s /tmp/TSM nom_module
| Les utilitaires sont installés dans le répertoire /opt/tivoli/tsm/upgrade/bin.

| 6. Facultatif : Installez le module de langue.
| a. Extrayez le contenu du module.
| gzip -d nom_module.img.gz
| b. Installez le module. Par exemple, s'il s'agit du répertoire /tmp/TSM, lancez la
| commande suivante :
| swinstall -s /tmp/TSM/nom_module.img nom_module
| c. Entrez la commande suivante pour définir la variable d'environnement des
| paramètres régionaux au niveau des messages :
| où xxxx correspond aux paramètres régionaux à utiliser. Par exemple,

| utilisez it_IT pour l'italien. Pour que les utilitaires de mise à niveau
| fonctionnent avec les paramètres régionaux souhaités, indiquez la valeur
| true au niveau des instructions suivantes :
| régionaux.

| Oracle Solaris
| Solaris
| Restriction : N'installez pas les utilitaires dans le répertoire d'installation du

| serveur d'origine qui doit être mis à niveau. Installez-les dans un répertoire
| distinct.
| b. Accédez au répertoire Solaris. A partir de ce répertoire, ouvrez le
| répertoire 5.5.6.x ou une version ultérieure. Le niveau doit être identique ou
| ultérieur à celui du serveur V5 que vous mettez à niveau.
| 5.5.x.x-TIV-TSMUPG-platforme.tar.Z

Linux

| ouvrez le répertoire LANG et téléchargez un module de langue. Les messages
| traduits sont disponibles dans le module de langue habituel pour serveur
| version 5.
| 3. Accédez au répertoire dans lequel le module des utilitaires de mise à niveau a
| été téléchargé.
| 4. Extrayez le contenu du module d'utilitaires de mise à niveau. Par exemple,
| lancez la commande suivante à partir du répertoire dans lequel vous avez
| sauvegardé le module téléchargé :
| uncompress -c nom_module.tar.Z | tar -xvf -
| 5. Accédez au répertoire qui correspond à l'architecture de processeur du système
| d'exploitation.
| 6. Installez les utilitaires de mise à niveau et le pilote de périphérique. Utilisez
| l'argument source (-d) pour indiquer le répertoire dans lequel le module a été
| extrait. Par exemple, s'il s'agit du répertoire /tmp/TSM, lancez la commande
| suivante :
| pkgadd -d . /tmp/TSM nom_module
| Les utilitaires sont installés par défaut dans le répertoire /opt/tivoli/tsm/

| upgrade/bin.
| 7. Facultatif : Installez le module de langue.
| a. Extrayez le contenu du module téléchargé.
| décompressez nom_module.pkg.Z
| b. Installez le module correspondant à la langue que vous souhaitez utiliser.
| Utilisez l'argument source (-d) pour indiquer le répertoire dans lequel le
| module a été extrait. Par exemple, s'il s'agit du répertoire /tmp/TSM, lancez
| la commande suivante :
| pkgadd
| -d /tmp/TSM nom_module.pkg
| nom_module
| c. Entrez la commande suivante pour définir la variable d'environnement des
| paramètres régionaux au niveau des messages :
| où xxxx correspond aux paramètres régionaux à utiliser. Par exemple,

| utilisez it_IT pour l'italien. Pour que les utilitaires de mise à niveau
| fonctionnent avec les paramètres régionaux souhaités, indiquez la valeur
| true au niveau des instructions suivantes :
| régionaux.
|
|
| Chapitre 15. Migration de la base de données du serveur vers

| le serveurV6.3.4 or ou ultérieure
| Migrez la base de données du serveur en utilisant le scénario qui fonctionne le
| mieux pour votre environnement matériel et logiciel. Le serveur original ne peut
| pas être en cours d'exécution durant l'extraction des données de la base de
| données du serveur.
| Pour avoir une présentation des scénarios de migration, consulter «Scénarios pour
| la migration d'un serveur à partir d'un système AIX, HP-UX, ou Solaris vers V6.3.4
| sur Linux», à la page 388.
| Suivez les instructions du scénario choisi.

| v «Scénario de migration 1: Utilisation de la méthode de réseau et de la ligne de
| commande»
| v «Scénario de migration 2: Utilisation de la méthode de support et de la ligne de
| commande», à la page 423
| v «Scénario de migration 3: Utilisation de la méthode de réseau et de l'assistant de
| mise à jour», à la page 438
| v «Scénario de migration 4: Utilisation de la méthode de réseau et de la ligne de
| commande», à la page 445
|
| Scénario de migration 1: Utilisation de la méthode de réseau et de la
| ligne de commande
| Procédez comme suit si vous mettez à niveau le serveur à l'aide du support média
| et l'assistant de mise à niveau. Grâce à la méthode de support, vous pouvez
| extraire les données de la base de données d'origine vers des supports et les
| charger ultérieurement dans la nouvelle base de données. Grâce à l'assistant, vous
| simplifiez le processus de configuration.
| Pour migrer le système à l'aide du scénario de migration 1, procédez comme suit :

| 1. Vérifiez que les tâches de planification ont été effectuées. Voir Chapitre 13,
| «Planification de la migration», à la page 397.
| 2. Assurez-vous les tâches de préparation ont été effectuées. Voir Chapitre 14,
| «Préparation de la migration», à la page 405.
| 3. Effectuez les tâches décrites dans les rubriques suivantes :
| a. «Scénario de migration 1: Installation du serveur V6.3.4 or ou ultérieure», à
| la page 418
| b. «Scénario de migration 1: Configuration des paramètres des périphériques»,
| à la page 420
| c. «Scénario de migration 1: Création de l'ID utilisateur et des répertoires pour
| l'instance de serveur», à la page 421
| d. «Scénario de migration 1: Exécution de l'assistant de mise à niveau», à la
| page 423
| Une fois les étapes de planification, de préparation et de migration terminées,

| effectuez les tâche de post-migration. Voir Chapitre 16, «Exécution des premières
| étapes après la mise à niveau», à la page 459.

Linux
| Scénario de migration 1: Installation du serveur V6.3.4 or ou

| ultérieure
| Vous pouvez faire appel à l'assistant d'installation ou installer le serveur par le
| biais de la console.
| A partir de la version 6.3, l'assistant d'installation du serveur IBM Tivoli Storage

| Manager possède un contrat de licence distinct pour les produits suivants :
| v Tivoli Storage Manager
| v IBM Tivoli Storage Manager Extended Edition
| v IBM System Storage Archive Manager
| v IBM Tivoli Storage Manager for Storage Area Networks
| Pour vérifier l'environnement système et installer le serveur, procédez comme suit :

| 1. Sur certains systèmes d'exploitation, vous devez vérifier certains paramètres
| système avant de commencer l'installation.
| Si vous utilisez Security Enhanced Linux sur votre système, définissez
| SELINUX=disable ou SELINUX=permissive dans le fichier /etc/sysconfig/
| selinux, au moins jusqu'à ce que le processus d'installation soit terminé.
| Si vous n'indiquez pas ces paramètres, le message suivant s'affichera lorsque
| vous installerez le serveur :
| Impossible d’exécuter l’assistant d’installation avec la configuration actuelle.
| Il va s’arrêter.
| Pour plus d’informations sur les journaux des erreurs d’installation,
| entrez la phrase "installation log files" dans la
| zone Search de ce site :
|
| http://publib.boulder.ibm.com/infocenter/tsminfo/v6r3
||
| 2. Connectez-vous au système à l'aide de l'ID utilisateur root.
| 3. Si vous disposez du DVD du produit, insérez le DVDTivoli Storage Manager
| dans un lecteur de DVD. Vérifiez que le DVD est monté sur le répertoire
| /dvdrom et accédez à ce répertoire.
| 4. Si vous avez téléchargé le programme depuis Passport Advantage en tant que
| fichier exécutable, procédez comme suit :
| a. Vérifiez que vous disposez de suffisamment d'espace pour stocker les
| fichiers d'installation lors de leur extraction du module du produit. Pour
| l'espace requis, voir le document à télécharger :
| Tivoli Storage Manager: http://www.ibm.com/support/
| docview.wss?uid=swg24030521
| Edition étendue Tivoli Storage Manager : http://www.ibm.com/
| support/docview.wss?uid=swg24030527
| System Storage Archive Manager: http://www.ibm.com/support/
| b. Accédez au répertoire dans lequel vous avez placé le fichier exécutable.
| Conseil : Assurez-vous que le fichier se trouve dans le répertoire où vous

| voulez que les fichiers soient extraits. Lors d'une étape ultérieure, les
| fichiers seront extraits dans ce répertoire.
| c. Modifiez les droits d'accès au fichier en entrant la commande suivante :
| chmod
| a+x nom_module.bin
Linux
| La variable nom_module correspond généralement à un nom tel que

| CZ1N1ML.
| d. Extrayez les fichiers d'installation :
| ./nom_module.bin
| Le module étant volumineux, l'extraction prend un certain temps.

| 5. Vérifiez que l'environnement système est conforme aux exigences
| d'installation. Vous pouvez vérifier manuellement les exigences ou exécuter le
| vérificateur de prérequis. Pour exécuter le vérificateur de prérequis, procédez
| comme suit :
| a. Emettez cette commande pour lancer le programme de vérification des
| prérequis à l'aide d'une interface graphique :
| ./prereqcheck.bin
| Sinon, émettez cette commande pour lancer le programme de vérification

| des prérequis à l'aide de la méthode de console :
| ./prereqcheck.bin -i console
| b. Sélectionnez la langue de l'interface utilisateur du programme de
| vérification des prérequis.
| c. Dans les panneaux d'accueil et d'exclusion de responsabilité, consultez les
| instructions et acceptez-les.
| Si le panneau Prerequisite Results indique que votre poste de travail a passé
| avec succès les contrôles, vous êtes prêt à démarrer l'installation. Si un
| message d'erreur s'affiche dans le panneau Prerequisite Results, apportez les
| corrections nécessaires avant de poursuivre l'installation. Pour plus
| d'informations sur le vérificateur de prérequis, voir «Exécution du vérificateur
| de prérequis», à la page 43.
| 6. A partir du DVD ou de l'emplacement où vous avez extrait le module, lancez
| l'assistant d'installation. Vous pouvez utiliser l'assistant graphique ou
| l'assistant de la console.
| v Lancez l'assistant graphique :
| ./install.bin
| v Lancez l'assistant de console :
| ./install.bin -i console
| Pour plus d'informations sur les traductions disponibles pour le serveur, voir
| la section traitant des langues locales du serveur dans l'annexe. Pour plus
| d'informations sur l'installation du serveur en mode silencieux, voir la section
| traitant de l'installation de Tivoli Storage Manager en mode silencieux dans le
| Guide d'installation.
| 7. Sélectionnez la langue de votre installation et suivez l'assistant, en cliquant sur
| Suivant pour passer à l'étape suivante dans l'assistant.
| a. Vous devez accepter le contrat de licence pour poursuivre. Sélectionnez le
| produit que vous êtes autorisé à utiliser et un contrat de licence s'affiche.
| Vous ne pouvez sélectionner qu'un seul produit sur la page. Si vous
| sélectionnez Tivoli Storage Manager, Tivoli Storage Manager Extended
| Edition ou System Storage Archive Manager, le système vous demande si
| vous utiliserez un partage hors réseau local ou un partage de bibliothèque.
| Si vous sélectionnez YES, vous devez accepter la licence Tivoli Storage
| Manager for Storage Area Networks. Cette licence vient s'ajouter à la
| licence du produit que vous choisissez sur la page précédente.
| b. Sélectionnez les composants à installer. Les composants sont le serveur, les
| langues, le pilote de périphérique et l'agent de stockage. Il n'existe pas de
Chapitre 15. Migration de la base de données du serveur vers le serveurV6.3.4 or ou ultérieure 419
Linux
| valeur par défaut et vous devez donc faire un choix. Si vous avez
| précédemment installé un serveur, vérifiez que vous avez sélectionné le
| même répertoire que celui utilisé lors de l'installation d'un module de
| langue, d'une licence ou d'un pilote de périphérique. Si vous avez déjà
| installé un agent de stockage, vérifiez que vous avez sélectionné le même
| répertoire pour l'installation d'un pilote de périphérique. Un serveur et un
| agent de stockage ne peuvent pas être installés sur le même poste de
| travail. Pour en savoir plus sur les autres composants que vous choisissez
| d'installer, voir Guide d'installation.
| L'interface de programme d'application client Tivoli Storage Manager, DB2
| version 9.7 et Global Security Kit (GSKit) 8 sont automatiquement installés
| lorsque vous sélectionnez le composant de serveur.
| 8. Lorsque l'installation est terminée, vérifiez qu'un message s'affiche indiquant
| que l'installation a réussi.
| Important : Si des erreurs se sont produites lors de l'installation, un panneau

| récapitulatif les répertorie et vous redirige vers un journal des erreurs.
| Corrigez les erreurs avant de passer à l'étape suivante.
| Le journal d'installation se trouve dans le répertoire /var/tivoli/tsm.
| 9. Téléchargez et appliquez tous les correctifs disponibles pour le serveur.
| Rendez-vous sur les site de téléchargments FTP à l'adresse :
| server. A défaut, rendez-vous sur le site de support du produit à l'adresse
| suivante :http://www.ibm.com/support/entry/portal/Downloads et
| recherchez les mises à jour du serveur.
| 10. Modifiez les valeurs des paramètres du noyau, si nécessaire.
| Pour mettre à jour les paramètres du noyau sous Red Hat et SUSE Linux,
| vous pouvez exécuter la commande ipcs - l afin de répertorier les valeurs
| des paramètres. Analysez les résultats pour déterminer si votre système
| requiert des modifications.
| Pour plus d'informations à propos de la modification des paramètres du
| noyau, reportez-vous au centre de documentation DB2 (http://
| pic.dhe.ibm.com/infocenter/db2luw/v9r7). Pour rechercher des informations,
| entrez une chaîne de recherche telle que modifier paramètres noyau, dans la
| zone de recherche du site.
| Pour exécuter Tivoli Storage Manager avec DB2, vous devrez peut-être définir
| des valeurs de paramètre de noyau supérieures aux valeurs minimales
| suggérées et apporter d'autres modifications au système. Pour plus de détails,
| voir la section traitant du réglage des paramètres de noyau pour les systèmes
| Linux dans le Guide d'installation.
| Scénario de migration 1: Configuration des paramètres des

| périphériques
| Définissez les paramètres des unités de stockage que vous envisagez d'utiliser avec
| le serveur V6.3.4 or ou ultérieure. Assurez-vous que vous définissez correctement
| les autorisations d'accès pour les utilisateurs et les groupes.
| Pour configurer des unités de stockage, suivez ces instructions:

| v Si les unités que vous envisagez d'utiliser sont contrôlées par le pilote de
| périphérique IBM, effectuez les étapes suivantes:
| 1. Installer le pilote de périphérique IBM et configurer les unités. Suivez les
| instructions du manuel d'utilisateur Tape Device Drivers Installation IBM sur
| http://www.ibm.com/support/docview.wss?uid=ssg1S7002972.
Linux
| 2. Pour définir les autorisations d'accès, effectuez l'une des actions suivantes:
| – Si le système est dédié àTivoli Storage Manager et que seul
| l'administrateur Tivoli Storage Manager y a accès,faites en sorte que les
| fichiers spéciaux de périphériques puissent être lus et écrits par tous les
| utilisateurs. Lancez la commande suivante :
| chmod a+rw /dev/IBMtapex
| – Limitez l'accès à un groupe en créant un groupe et en ajoutant chaque ID
| utilisateur d'instance pour Tivoli Storage Manager de ce groupe. Ensuite,
| modifiez la propriété des fichiers spéciaux de périphériques pour en faire
| une propriété du groupe, puis faites en sorte que les fichiers spéciaux de
| périphériques puissent être lus et écrits par le groupe. Lancez la
| chmod g+rw /dev/IBMtapex
| périphérique Tivoli Storage Manager, effectuez les étapes suivantes:
| 1. Connectez-vous en qualitÚ de superutilisateur.
| 2. Octroi du droit d'accès en lecture et en écriture.
| – Pour accorder un droit d'accès en lecture et en écriture à tous les
| utilisateurs, exécutez la commande suivante:
| /opt/tivoli/tsm/devices/bin/autoconf -a
| – Pour accorder un droit d'accès en lecture et en écriture au groupe
| uniquement, exécutez la commande suivante:
| /opt/tivoli/tsm/devices/bin/autoconf -g
| Pour en savoir plus sur la configuration des périphériques, voir la section traitant
| la connexion des périphériques au serveur dans Guide d'administration.
| Scénario de migration 1: Création de l'ID utilisateur et des

| répertoires pour l'instance de serveur
| Créez l'ID utilisateur auquel appartiendra l'instance du serveur. Créez également
| les répertoires que l'instance de serveur utilisera pour la base de données et les
| journaux de récupération.
| Avant de démarrer, pour passer en revue les informations relatives à planification

| de l'espace pour le serveur, consultez «Estimation de l'espace requis pour la base
| de données et le journal de reprise», à la page 398.
| Pour créer l'ID utilisateur, le groupe et les répertoires pour l'instance de serveur
| migrée, procédez comme suit :
| 1. Créez un ID utilisateur et un groupe auxquels appartiendra l'instance du
| serveur Tivoli Storage Manager. C'est à l'aide de cet ID utilisateur que vous
| créez l'instance du serveur lors d'une étape ultérieure.
| Restriction : L'ID utilisateur doit uniquement contenir des lettres en

| minuscules (a-z), des chiffres (0-9) et le trait de soulignement (_). L'ID
| utilisateur et le nom de groupe doivent respecter les règles suivantes :
| v La longueur doit être inférieure ou égale à 8 caractères.
| v L'ID utilisateur et le nom de groupe ne peuvent pas commencer par ibm, sql,
| sys, ou un chiffre.
| v L'ID utilisateur et le nom de groupe ne peuvent pas être user, admin, guest,
| public, local, ou un mot réservé à SQL.
Linux
| Par exemple, créez l'ID utilisateur tsminst1 dans le groupe tsmsrvrs. Les
| exemples ci-dessous indiquent comment créer cet ID utilisateur et ce groupe à
| l'aide des commandes du système d'exploitation.
| # groupadd tsmsrvrs
| # useradd -d /home/tsminst1 -m -g tsmsrvrs -s /bin/bash tsminst1
| # passwd tsminst1
| 2. Déconnectez-vous, puis reconnectez-vous au système en utilisant le nouvel ID
| utilisateur et le nouveau mot de passe. Utilisez un programme de connexion
| interactif tel que telnet pour afficher une invite de mot de passe et modifier ce
| dernier si nécessaire.
| 3. S'il n'existe pas de profil de configuration pour cet ID utilisateur, créez le
| fichier. Par exemple, créez un fichier .profile si vous utilisez l'interpréteur de
| commandes Korn (ksh).
| 4. Vérifiez que vous êtes connecté avec l'ID que vous avez créé. Puis, créez les
| répertoires nécessaires au serveur.
| Vous avez besoin de répertoires uniques et vides pour chacun des éléments
| présentés dans le tableau suivant. Créez les répertoires de base de données, le
| répertoire de journaux actif et le journal d'archivage sur différents volumes
| physiques. Pour l'espace requis, voir «Feuille de calcul pour l'espace de
| planification du serveur V6.3 ou ultérieure», à la page 50.
| Tableau 69. Feuille de travail pour la création des répertoires requis
| Exemples de commandes de
| Elément création de répertoires Vos répertoires
| Le répertoire d'instance mkdir /home/user_ID/tsminst1
| du serveur, destiné à
| contenir les fichiers pour
| cette instance de serveur,
| y compris le fichier
| d'instance du serveur
| Répertoires de base de mkdir /home/user_ID/tsmdb001
| données mkdir /home/user_ID/tsmdb002
| mkdir /home/user_ID/tsmdb003
| Répertoire du journal mkdir /home/user_ID/tsmlog
| actif
| Répertoire du journal mkdir /home/user_ID/
| d'archivage tsmarchlog
| Facultatif : répertoire de mkdir /home/user_ID/
| la copie miroir du tsmlogmirror
| journal actif
| Facultatif : répertoire du mkdir /home/user_ID/
| journal d'archivage tsmarchlogfailover
| secondaire qui est
| l'emplacement de reprise
| pour le journal
| d'archivage
|
| Lorsqu'un serveur est initialement créé, avec la fonctionnalité DSMSERV FORMAT
| ou avec l'assistant de configuration, une base de données de serveur et un
| journal de récupération sont également créés. De plus, des fichiers sont créés
| pour contenir les informations de base de données utilisées par le gestionnaire
| de base de données.
Linux
| 5. Créez plus de volumes logiques et montez les volumes sur les répertoires qui
| ont été créés à l'étape précédente.
| Scénario de migration 1: Exécution de l'assistant de mise à

| niveau
| L'assistant offre une approche guidée pour la mise à niveau d'un serveur. Lancez
| l'assistant sur le système où vous avez installé le programme du serveur version
| 6.3.4 or ou ultérieure.
| Avant de lancer l'assistant de mise à niveau, effectuez les étapes précédentes afin
| de préparer la mise à niveau. Assurez-vous avoir sauvegardé les données du
| serveur et les fichiers de configuration. Vérifiez également que vous avez installé le
| programme serveur version 6.3.4 or ou ultérieure et créez les répertoires et les ID
| utilisateur pour l'instance de serveur.
| 1. Vérifiez que les conditions suivantes sont remplies :
| v Le système sur lequel vous avez installé le programme du serveur version
| 6.3.4 or ou ultérieure doit disposer du client X Window. Un serveur X
| Window doit également être en cours d'exécution sur votre bureau.
| v L'un des protocoles suivants doit être activé au niveau du système. Vérifiez
| que le port que le protocole utilise n'est pas bloqué par un pare-feu.
| – Secure Shell (SSH). Vérifiez que le port affiche la valeur par défaut (22).
| Assurez-vous également que le service démon possède les droits d'accès
| pour se connecter au système en utilisant localhost.
| – Remote shell (rsh).
| – Protocole d'exécution éloigné (REXEC).
| L'un des protocoles du serveur version 5 doit également être activé.
| v Vous devez pouvoir vous connecter au système version 6.3.4 or ou ultérieure
| sous l'ID utilisateur que vous avez créé pour l'instance du serveur à l'aide du
| protocole SSH, rsh ou REXEC. Lorsque vous utilisez l'assistant, vous devez
| fournir cet ID utilisateur et ce mot de passe pour accéder à ce système.
| 2. Lancez l'assistant de mise à niveau, dsmupgdx, à partir du répertoire
| d'installation du serveur version 6.3.4 or ou ultérieure. Connectez-vous à l'aide
| de l'ID utilisateur root :
| /opt/tivoli/tsm/server/bin/dsmupgdx
| 3. Suivez les instructions permettant de terminer la mise à niveau. L'assistant de
| mise à niveau peut être arrêté et redémarré, mais le serveur ne sera pas
| opérationnel tant que le processus de mise à niveau n'est pas entièrement
| terminé. Prenez connaissance de tous les messages qui s'affichent pour chaque
| phase du processus de mise à niveau dans l'assistant. Votre attention peut être
| recommandée par des messages d'information.
|
| Scénario de migration 2: Utilisation de la méthode de support et de la
| ligne de commande
| Procédez comme suit si vous migrez la base de données du serveur à l'aide de la
| méthode de support et de la ligne de commande. Grâce à la méthode de support,
| vous pouvez extraire les données de la base de données d'origine vers les supports
| et les charger dans la nouvelle base de données. Grâce à la ligne de commande,
| vous pouvez émettre des commandes d'administration pour mettre à niveau
| manuellement le système.
Linux
| Pour migrer le système à l'aide du scénarion de migration 2, procédez comme suit

| :
| 3. Effectuez les tâches qui sont décrites dans les rubriques suivantes :
| a. «Scénario de migration 2: préparation de la base de données du serveur V5»
| b. «Scénario de migration 2: Extraction des données sur des supports», à la
| page 425
| c. «Scénario de migration 2: Installation du serveur V6.3.4 or ou ultérieure», à
| la page 426
| d. «Scénario de migration 2: Configuration des paramètres des périphériques»,
| à la page 428
| e. «Scénario de migration 2: Configuration des périphériques», à la page 429
| f. «Scénario de migration 2: Création de l'ID utilisateur et des répertoires pour
| g. «Scénario de migration 2: Création de l'instance de serveur et de la base de
| données», à la page 432
| h. «Scénario de migration 2: chargement des données extraites dans la base de
| données V6.3.4 or ou ultérieure», à la page 435
| i. «Scénario de migration 2:Configuration du système en vue de la sauvegarde
| de la base de données», à la page 437

| Scénario de migration 2: préparation de la base de données

| du serveur V5
| Avant d'extraire les données de la base de données du serveur V5, vous devez
| préparer la base de données à l'aide de l'utilitaire DSMUPGRD PREPAREDB. Si plusieurs
| serveurs sont installés sur un seul système, répétez cette tâche pour chaque
| serveur.
| Les utilitaires de mise à niveau doivent être installés sur le système V5.
| 1. Vérifiez que les étapes de préparation ont été effectuées. Pour obtenir des
| instructions, voir Chapitre 14, «Préparation de la migration», à la page 405.
| 2. Connectez-vous à l'aide de l'ID utilisateur root sur le système V5.
| 3. Accédez au répertoire d'instance du serveur que vous mettez à niveau. Le
| répertoire d'instance est celui qui contient les fichiers, tels que dsmserv.dsk, du
| serveur.
| 4. Préparez la base de données. Dirigez la sortie du processus vers un fichier à
| des fins de surveillance. A partir du répertoire d'instance du serveur que vous
| mettez à niveau, lancez la commande suivante pour exécuter le processus en
| arrière-plan et diriger la sortie vers le fichier prepare.out :
| AIX
| nohup /usr/tivoli/tsm/upgrade/bin/dsmupgrd preparedb >prepare.out 2>&1 &
| HPUX Solaris
| nohup /opt/tivoli/tsm/upgrade/bin/dsmupgrd preparedb >prepare.out 2>&1 &
Linux
| 5. Surveillez le processus afin d'identifier les erreurs et les messages

| d'avertissement. Le message final indique la réussite ou l'échec de l'opération.
| A partir du répertoire de l'instance du serveur que vous mettez à niveau,
| lancez la commande suivante pour surveiller le processus :
| tail -f prepare.out
| Assurez-vous que l'opération de préparation a réussi avant de passer à l'étape

| suivante. Si ce n'est pas le cas, il se peut que vous deviez redémarrer le serveur
| version 5 pour résoudre le problème et réexécuter l'opération de préparation. Si la
| version du serveur mis à niveau est 5.3 ou 5.4, il peut être nécessaire de restaurer
| la base de données à l'aide d'une sauvegarde. Vous pouvez ensuite redémarrer le
| serveur pour corriger le problème.
| Scénario de migration 2: Extraction des données sur des

| supports
| Utilisez la fonctionnalité DSMUPGRD pour extraire les données de la base de données
| du serveur V5 et stockez les dans une unité de bande.
| 1. Connectez-vous à l'aide du nom du superutilisateur au système qui a le serveur
| V5.
| 2. Assurez-vous de la disponibilité de l'unité de stockage. La base de données du
| serveur et le fichier de configuration d'unité doivent contenir une définition de
| classe d'unités valide pour l'unité.
| 3. A partir du répertoire de l'instance du serveur que vous mettez à niveau,
| lancez la commande de démarrage de l'extraction. Dirigez la sortie du
| processus vers un fichier à des fins de surveillance. Par exemple, exécutez la
| commande suivante, sur une ligne :
| AIX
| nohup /usr/tivoli/tsm/upgrade/bin/dsmupgrd extractdb \

| devclass=tape manifest=./manifest.txt >extract.out 2>&1 &
| HPUX Solaris
| nohup /opt/tivoli/tsm/upgrade/bin/dsmupgrd extractdb \

| devclass=tape manifest=./manifest.txt >extract.out 2>&1 &
| Conseil : Les messages émis au cours de l'opération d'extraction ne sont pas

| sauvegardés dans le journal d'activité du serveur. Dirigez la sortie de l'utilitaire
| vers un fichier, comme indiqué dans les exemples, afin d'enregistrer les
| messages.
| d'avertissement, ainsi que les éléments pouvant nécessiter une intervention. Un
| message s'affichant juste avant la fin du processus montre que l'opération a
| échoué ou a réussi:
| Message de réussite : ANR1382I EXTRACTDB : le processus 1, l'extraction
| de la base de données, est terminé.
| Message d'échec : ANR1396E EXTRACTDB : le processus 1, l'extraction de
| la base de données, est terminé mais des erreurs se sont produites.
| Par exemple, dans le répertoire d'instance du serveur que vous mettez à
| niveau, lancez la commande suivante afin de surveiller le processus :
| tail -f extract.out
| La durée du processus dépend de la taille de la base de données. Il fait à peu
| près le temps nécessaire pour une sauvegarde complète de la base de données.
Linux

| ultérieure


|
||

| chmod
Linux

| CZ1N1ML.
| ./nom_module.bin

| comme suit :
| ./prereqcheck.bin

| ./install.bin
Linux


| périphériques

Linux
| Scénario de migration 2: Configuration des périphériques

| Sur le serveur Tivoli Storage Manager V6.3.4 or ou ultérieure, configurez les
| périphériques que vous prévoyez d'utiliser. Obtenez les noms de périphérique de
| bibliothèque et ceux de périphériques de commande pour le serveur 6.3.4 or ou
| ultérieure. Puis, effectuez la mise à jour du fichier manifest avec les noms.
| Exécutez les étapes suivantes pour configurer les périphériques :

| 1. Obtenez les numéros de série de bibliothèque à partir du fichier manifest sur le
| système V5.
| Conseil : Le fichier manifest a été créé lors d'une étape précédente, «Scénario
| de migration 2: Extraction des données sur des supports», à la page 425.
| L'exemple suivant provient du fichier manifest du serveur V5 :
| DEFINE LIBRARY LTO_LIB LIBTYPE=SCSI WWN="500143800329CAD8"
| SERIAL="DEC91503HW" SHARED=NO AUTOLABEL=NO RESETDRIVE=NO
| Dans l'exemple précédent, le numéro de série de la bibliothèque est DEC91503HW.

| 2. Otenez les noms de périphériques de bibliothèque :
| v Si les périphériques sont controllés par le pilote de périphérique Tivoli
| Storage Manager,prenez les mesures suivantes :
| a. Sur le système, lancez la commande :
| cat /dev/tsmscsi/lbinfo
| Dans la sortie, recherchez tous numéros de série de bibliothèque que
| vous avez identifié dans l'Etape 1.
| La sortie d'échantillon suivante est à partir du serveur V6 :
Linux
| Index Minor Host CHN ID LUN Type Vendor_ID Device_Serial_Number product_ID Rev.
| 000 006 001 000 003 001 008 HP DEC91503HW MSL G3 Series 5.80
| Dans la sortie d'échantillon, le numéro de série de bibliothèque est

| DEC91503HW et le numéro d'index est 000.
| b. Utilisez le numéro d'index pour définir le nom de bibliothèque.
| Un nom de bibliothèque a le format suivant :
| /dev/tsmscsi/lbx
| où x correspond au numéro d'index sans les zéros. Dans cet exemple, le

| numéro d'index est 000. Lorsque les zéros sont supprimés, le numéro
| devient 0 et le nom de la bibliothèque est définit par /dev/tsmscsi/lb0.
| v Si les périphériques sont contrôlés par des pilotes de périphériques de bande
| IBM, obtenez les noms de périphériques de bibliothèque dans le guide
| d'utilisation et IBM Tape Device Drivers Installation:
| http://www.ibm.com/support/docview.wss?uid=ssg1S7002972
| Les noms de périphériques de bibliothèque qui sont contrôlés par un pilote
| de périphériques IBM sur un système Linux ont le format suivant :
| /dev/IBMchangerx
| où x est un entier. Par exemple, un périphérique de bibliothèque peut être

| nommé /dev/IBMchanger0.
| 3. Obtenez les numéros de série pour les périphériques de lecteur à partir du
| fichier manifest sur le système V5. L'exemple suivant provient du fichier
| manifest d'un serveur V5 :
| DEFINE DRIVE LTO_LIB LTO_DRIVE ELEMENT=1 ONLINE=Yes
| WWN="500143800329CAD9" SERIAL="HU171200NG"
| Dans l'exemple précédent, le numéro de série est HU171200NG.
| 4. Otenez les noms des lecteurs de l'appareil :
| v Si les périphériques sont controllés par le pilote de périphérique Tivoli
| Storage Manager,prenez les mesures suivantes :
| a. Sur le système V6, exécutez la commande suivante :
| cat /dev/tsmscsi/mtinfo
| Dans la sortie, recherchez tous les numéros de série de bibliothèque que

| vous avez identifié dans l'Etape In the output, 3.
| La sortie d'échantillon suivant est à partir d'un serveur V6 :
| Index Minor Host CHN ID LUN Type Vendor_ID Device_Serial_Number Product_ID Rev.
| 000 005 001 000 003 000 001 HP HU171200NG Ultrium 4-SCSI H68W
| Dans la sortie d'échantillon, le numéro d'index est 000.

| b. Utilisez le numéro d'index à partir de la sortie dans Etape 4a pour définir
| le nom du lecteur de périphérique. Le nom d'un lecteur de périphérique
| a le format suivant :
| /dev/tsmscsi/mtx
| où x est le numéro d'index sans les zéros. Dans cet exemple, le numéro
| d'index est 000. Une fois avoir retirer les zéros, le numéro est 0 et le nom
| du lecteur de périphérique est défini par /dev/tsmscsi/mt0.
| v Si les périphériques sont contrôlés par des lecteurs de périphériques de
| bande IBM, obtenez les noms de lecteur de périphérique en suivant les
| instructions du guide d'utilisation et de IBM Tape Device Drivers Installation :
Linux
| http://www.ibm.com/support/docview.wss?uid=ssg1S7002972
| Les noms de lecteurs de périphériques qui sont contrôlés par IBM les lecteurs
| de périphérique de bande ont le format suivant :
| /dev/IBMtapex
| où x est un numéro qui est affecté à un périphérique. Par exemple, un lecteur

| de périphérique peut être nommé /dev/IBMtape0, où 0 est le numéro de
| périphérique.
| 5. Mise à jour du fichier manifest avec les noms de périphériques de bibliothèque
| et de lecteur, et sauvegardez le fichier.

| des répertoires que l'instance du serveur utilisera pour les bases de données et


| # passwd tsminst1
Linux

| actif
| journal actif
| pour le journal
| d'archivage
|
| Scénario de migration 2: Création de l'instance de serveur et

| de la base de données
| Créez l'instance du serveur et formatez les fichiers pour une base de données
| version 6.3.4 or ou ultérieure vide. Par la suite, vous pourrez migrer les données
| de la base de données du serveur V5 vers la nouvelle base de données V6.3.4 or ou
| ultérieure.
| 1. Connectez-vous au système sur lequel vous avez installé le programme V6.3.4
| or ou ultérieure à l'aide de L'ID du superutilisateur.
| Vérifiez les éléments suivants :
| v Le répertoire de base de l'utilisateur, /home/tsminst1, existe. S'il
| n'existe pas de répertoire de base, vous devez le créer.
| v Le répertoire d'instance stocke les fichiers core suivants générés par
| le serveur Tivoli Storage Manager :
| – Le fichier d'options du serveur, dsmserv.opt
Linux
| – Le fichier de base de données de clés du serveur, cert.kdb, et les

| fichiers .arm, qui sont utilisés par des clients et d'autres serveurs
| pour importer les certificats Secure Sockets Layer du serveur
| – Fichier de configuration d'unité si l'option de serveur DEVCONFIG
| n'indique pas un nom complet
| – Fichier d'historique des volumes si l'option de serveur
| VOLUMEHISTORY n'indique pas un nom complet
| – Volumes des pools de stockage du type d'unité FILE, si le
| répertoire de la classe du périphérique n'est pas complètement
| défine, ou pas pleinement qualifié
| – Exits utilisateur
| – La sortie de trace, si le nom qualifié complet n'est pas indiqué
| v Un fichier de configuration de l'interpréteur de commandes,par
| exemple un fichier .profile, existe dans le répertoire de base. L'ID
| de superutilisateur et d'utilisateur d'instance doit disposer de droits
| d'accès en écriture à ce fichier. Pour plus d'informations, visiter le
| centre de documentationDB2 et recherchez des informations sur les
| paramètres des variables d'environnementLinux and UNIX.
| 2. Créez une instance Tivoli Storage Manager à l'aide de la commande db2icrt.
| Entrez la commande suivante sur une seule ligne. Pour le nom d'instance,
| indiquez l'ID utilisateur créé pour être propriétaire de l'instance :
| /opt/tivoli/tsm/db2/instance/db2icrt -a server -s ese -u
| id_utilisateur nom_instance
| Par exemple, si l'ID utilisateur pour cette instance est tsminst1, utilisez la
| commande suivante pour créer l'instance :
| tsminst1 tsminst1
| A faire : A ce stade, utilisez ce nouvel ID utilisateur lors de la configuration

| du serveur Tivoli Storage Manager. Déconnectez-vous de l'ID superutilisateur
| et connectez-vous à l'aide du nom d'utilisateur qui est le propriétaire de
| l'instance.
| 3. Connectez-vous au système à l'aide de l'ID utilisateur possédant l'instance de
| serveur version 6.3.4 or ou ultérieure (ID utilisateur d'instance).
| 4. Copiez les fichiers de configuration dans le répertoire d'instance créé pour le
| nouveau serveur. Il s'agit des fichiers de configuration que vous avez
| sauvegardés à partir du serveur version 5 initial :
| v fichier de configuration des unités
| v Fichier d'options du serveur, généralement appelé dsmserv.opt
| Par exemple, si vous avez créé le répertoire d'instance figurant dans l'exemple
| lors de l'étape de création de répertoires, copiez les fichiers dans le répertoire
| suivant:
| /tsminst1
| Assurez-vous que l'ID utilisateur d'instance est propriétaire de ou possède des
| droits en lecture/écriture des fichiers copiés.
| 5. Modifiez le fichier d'options du serveur.
| a. Supprimez toute option non prise en charge pour la version 6.3 ou
| ultérieure. Vous trouverez la liste des options supprimées, dans le
| tableau 36, à la page 78.
Linux
| b. Vérifiez que le fichier d'options du serveur contient au moins une option

| VOLUMEHISTORY et au moins une option DEVCONFIG. Un fichier d'historique
| des volumes et un fichier de configuration d'unité sont nécessaires lorsque
| vous devez restaurer la base de données, générer des copies automatiques
| de ces fichiers. Vous pouvez ainsi faire en sorte que les fichiers soient
| disponibles en cas de besoin.
| c. Vérifiez si le fichier d'options du serveur inclut l'option TXNGROUPMAX avec
| une valeur définie et, si oui, vérifiez quelle est cette valeur. Vous pouvez
| modifier la valeur courante, car la valeur par défaut pour cette option
| passe de 256 à 4096 avec la version 6.3 ou ultérieure. L'augmentation de la
| valeur peut améliorer les performance des opérations de transfert des
| données, comme la migration d'un pool de stockage et la sauvegarde d'un
| pool de stockage.
| v Si le fichier d'options du serveur inclut cette option, le serveur utilise
| automatiquement la nouvelle valeur par défaut : 4096.
| v Si une valeur a été définie dans le fichier d'options du serveur pour
| cette option, le serveur utilise cette valeur. Si la valeur indiquée est
| inférieure à 4096, vous pouvez l'augmenter ou supprimer l'option afin
| que le serveur utilise la nouvelle valeur par défaut.
| 6. Modifiez le chemin d'accès par défaut à la base de données afin qu'il
| corresponde au répertoire d'instance du serveur. Exécutez la commande :
| db2 update dbm cfg using dftdbpath répertoire_instance
| Par exemple:
| db2 update dbm cfg using dftdbpath /tsminst1
| 7. Modifiez le chemin d'accès à la bibliothèque pour utiliser la version d'IBM
| Global Security Kit (GSKit) installé avec le serveur Tivoli Storage Manager .
| Vous devez mettre à jour les fichiers suivants pour définir le chemin d'accès à
| la bibliothèque lorsque DB2 ou le serveur Tivoli Storage Manager sont
| démarrés :
| v répertoire_instance/sqllib/usercshrc
| v répertoire_instance/sqllib/userprofile
| Pour le fichier instance_directory/sqllib/usercshrc, ajoutez la ligne
| suivante:
| setenv LD_LIBRARY_PATH /usr/local/ibm/gsk8_64/lib64:$LD_LIBRARY_PATH
| Pour le fichier répertoire_instance/sqllib/userprofile, ajoutez les lignes

| suivantes :
| LD_LIBRARY_PATH=/usr/local/ibm/gsk8_64/lib64:$LD_LIBRARY_PATH
| export LD_LIBRARY_PATH
| Vérifiez les paramètres de chemin d'accès à la bibliothèque et vérifiez que la

| version GSKit est la version 8.0.14.14 ou ultérieure. Exécutez les commandes
| suivantes à partir du répertoire de base de l'instance, par exemple,
| /home/tsminst1:
| echo $LD_LIBRARY_PATH
| gsk8capicmd_64 -version
| gsk8ver_64
| Si votre version de GSKit n'est pas la version 8.0.14.14 ou une version
| ultérieure, vous devez réinstaller le serveur Tivoli Storage Manager. La
| réinstallation permet de s'assurer que la version GSKit correcte est disponible.
| 8. Effectuez cette étape pour définir la page de code de serveur.
Linux
| Définissez la variable d'environnement système DB2CODEPAGE à 819 pour

| chaque instance de serveur. Avant d'exécuter la commande DSMSERV
| LOADFORMAT, connectez-vous au système en tant que propriétaire de l'instance
| de serveur puis exécutez la commande:
| db2set
| -i nom_instance DB2CODEPAGE=819
| Exemple :
| db2set -i tsminst1 DB2CODEPAGE=819
| 9. Accédez au répertoire d'instance que vous avez créé pour le serveur.
| 10. Créez et définissez le format de la base de données et des journaux de
| récupération à l'aide de la commande DSMSERV LOADFORMAT. Dans la
| commande, indiquez les répertoires que vous avez créés pour la base de
| données et les journaux. Les répertoires doivent être vides.
| Par exemple, pour obtenir une taille de journal actif de 16 GB ou 16384 MB, ce
| qui constitue la taille par défaut exécutez la commande sur une seule ligne:
| /opt/tivoli/tsm/server/bin/dsmserv loadformat \
| dbdir=/tsmdb001,/tsmdb002,/tsmdb003,/tsmdb004 \
| activelogsize=16384 activelogdirectory=/tsmlog \
| mirrorlogdirectory=/tsmlogmirror archlogdirectory=/tsmarchlog
| Pour plus d'informations sur la création et le mise en forme d'une base de
| données voir Annexe A, «Utilitaires, scripts et commandes pour la mise à
| d'avertissement. Le message final indique que l'opération a échoué ou a réussi.
| Scénario de migration 2: chargement des données extraites

| dans la base de données V6.3.4 or ou ultérieure
| Après avoir formaté une base de données vide via l'utilitaire DSMSERV LOADFORMAT,
| chargez les données que vous avez extraites de la base de données de serveur
| d'origine.
| Avant de commencer à charger les données, vérifiez que les conditions requises
| ci-après sont remplies :
| v Le fichier manifeste de l'opération DSMUPGRD EXTRACTDB doit être disponible.
| v Le fichier d'options du serveur doit contenir une entrée pour le fichier de
| configuration d'unité.
| v Le fichier de configuration d'unité doit disposer des informations sur la classe
| d'unités spécifiée dans le fichier manifeste.
| v Le support contenant la base de données extraites doit être disponible pour le
| serveur version 6.3.4 or ou ultérieure. L'unité doit être physiquement attachée au
| système. Les autorisations doivent être définies pour accorder l'accès au support
| à l'ID utilisateur auquel appartient l'instance de serveur version 6.3.4 or ou
| ultérieure.
| Effectuez les étapes suivantes :

| 1. Vérifiez que le serveur version 6.3.4 or ou ultérieure peut accéder aux données
| extraites. Le lecteur de bande qui est utilisé pour les données extraites doivent
| être physiquement connecté au système V 6.3.4 or ou ultérieure .
| 2. Assurez-vous que l'ID utilisateur d'instance est propriétaire de ou possède des
| droits en lecture/écriture sur le fichier manifeste qui a été créé par le
| processus d'extraction.
Linux
| 3. Connectez-vous avec l'ID utilisateur de l'instance au système sur lequel vous

| avez installé le serveur version 6.3.4 or ou ultérieure.
| 4. Copiez le fichier manifeste qui a été créé par le processus d'extraction vers le
| système version 6.3.4 or ou ultérieure.
| 5. Sur le serveur de version 6.3.4 or ou ultérieure, procédez comme suit :
| a. Vérifiez que le fichier d'options du serveur version 5 inclut l'option
| DEVCONFIG et que cette dernière indique le chemin complet du fichier de
| configuration d'unité.
| b. Vérifiez que le fichier de configuration d'unité est disponible dans le
| serveur version 5 à l'emplacement indiqué par l'option DEVCONFIG.
| c. Vérifiez que les droits sur le fichier de configuration d'unité autorise l'accès
| en lecture pour l'ID utilisateur de l'instance.
| 6. Vérifiez que le contenu du fichier de configuration d'unité est correct. La
| classe d'unités qui a été utilisée pour l'étape d'extraction est enregistrée dans
| le fichier manifeste et elle doit exister et être valide sur le système version
| 6.3.4 or ou ultérieure. Vérifiez les entrées de la bande. Par exemple, les noms
| d'unité peuvent avoir changé.
| 7. Vérifiez le contenu du fichier manifeste est modifiez le fichier si nécessaire.
| a. Assurez-vous que les noms de périphériques dans le fichier manifeste sont
| valables pour la Vnsure that the device names in the manifest file are valid
| pour le système version 6.3.4 or ou ultérieure. Il se peut que les noms de
| périphériques diffère pour le même périphérique selon qu'il s'agit du
| système V5 ou V6.3.4 or ou ultérieure.
| données.
| 8. Pour charger une base de données extraite dans la base de données version,
| 6.3.4 or ou ultérieure préparée et vide, exécutez la commande DSMSERV
| INSERTDB. Dirigez la sortie du processus vers un fichier à des fins de
| surveillance. Par exemple, exécutez la commande suivante, sur une seule ligne
| :
| nohup /opt/tivoli/tsm/server/bin/dsmserv insertdb \
| manifest=./manifest.txt >insert.out 2>&1 &
| Pour plus d'informations sur le chargement d'une base de données extraite
| vers une nouvelle base de données, voir Annexe A, «Utilitaires, scripts et
| commandes pour la mise à niveau de serveur et la migration», à la page 561.
| 9. Surveillez le processus afin d'identifier les messages d'erreur et les messages
| d'avertissement, ainsi que les éléments pouvant nécessiter une intervention. Le
| système affiche des statistiques temporaires sur l'opération de chargement de
| base de données. Toutefois, il peut y avoir des périodes durant lesquelles
| aucun message n'est généré. Durant ce temps, les opérations DB2 s'exécutent
| en arrière-plan. La durée du processus dépend de la taille de la base de
| données. Pour plus d'informations, voir «Exemple - Estimation de la durée de
| mise à niveau en fonction de la taille de la base de données», à la page 51.
| Facultatif : vérifiez que la base de données est chargée en surveillant le
| processeur et la présence des entrées-sorties pour le processus du serveur et le
| processus DB2 correspondant. Par exemple, exécutez la commande suivante
| pour surveiller le processus :
| tail -f insert.out
| Un message généré par la commande DSMSERV INSERTDB indique l'état de
| l'opération :
Linux
| v Message de réussite : ANR1395I INSERTDB : le processus 1, l'insertion

| de la base de données, est terminé.
| v Message d'échec : ANR1396E INSERTDB : le processus 1, l'insertion de
| la base de données, est terminé mais des erreurs se sont produites.
| 10. Si vous avez utilisé la méthode médias pour mettre à niveau le système, après
| chargement des données dans la base de données, supprimez ou vérifiez à
| partir de la Bibliothèque la bande qui contient les données extraites.
| Empêchez la réutilisation de la bande jusqu'à ce que vous soyez sûr ne pas
| avoir à répéter l'opération de chargement de base de données.
| Scénario de migration 2:Configuration du système en vue de

| la sauvegarde de la base de données
| Si vous n'avez pas utilisé l'assistant de mise à niveau, vous devez terminer la
| configuration de sauvegarde de base de données manuellement.
| Dans les étapes ci-après, tsminst1 correspond à l'ID utilisateur de l'instance de

| serveur et /tsminst1 au répertoire de l'instance de serveur Tivoli Storage Manager.
| 1. Configurez la variable d'environnement de l'API Tivoli Storage Manager pour
| l'instance de base de données :
| a. Connectez-vous à l'aide de l'ID utilisateur tsminst1.
| b. Lorsque l'utilisateur tsminst1 est connecté, assurez-vous que
| l'environnement DB2 est correctement initialisé. L'environnement DB2 est
| initialisé via l'exécution du script /home/tsminst1/sqllib/db2profile, qui
| s'exécute normalement depuis le profil de l'ID utilisateur. Si
| /home/tsminst1/.profile n'exécute pas le script db2profile, par exemple
| lorsque vous utilisez l'interpréteur de commandes Korn (/bin/ksh), ajoutez
| les lignes suivantes /home/tsminst1/.profile:
| if [ -f /home/tsminst1/sqllib/db2profile ]; puis
| fi
| c. Ajoutez ou mettez à jour les lignes suivantes dans le fichier useprofile
| dans le répertoire /home/tsminst1/sqllib :
| 2. Déconnectez-vous, puis reconnectez-vous sous tsminst1 ou exécutez la
| . ~/.profile
| Conseil : Assurez-vous que vous entrez dans un espace après le point initial (.)
| caractère !.
| 3. Créez un fichier dénommé tsmdbmgr.opt dans le répertoire /tsminst1 et ajoutez
| la ligne suivante:
| SERVERNAME TSMDBMGR_TSMINST1
| A faire : Le nom utilisé doit être identique à celui de l'instance de serveur.

| 4. Ajoutez les lignes suivantes au fichier de configuration de l'API Tivoli Storage
| Manager dsm.sys. Le fichier de configuration dsm.sys se trouve à
| l'emplacement par défaut suivant:
| /opt/tivoli/tsm/client/api/bin64/dsm.sys
Linux
| Evitez de placer le nom du serveur, TSMDBMGR_TSMINST1,en première

| position dans le fichier dsm.sys car sinon, il constituerait la valeur par défaut
| du système. Dans cet exemple, les lignes ajoutées se trouvent après la section
| correspondant à server_a.
| Servername server_a
| COMMMethod TCPip
| TCPPort 1500
| TCPServeraddress node.domain.company.COM
|
|
| servername TSMDBMGR_TSMINST1
| commmethod tcpip
| tcpserveraddr localhost
| tcpport 1500
| passwordaccess generate
| passworddir /home/tsminst1/tsminst1
| errorlogname /home/tsminst1/tsminst1/tsmdbmgr.log
| nodename $$_TSMDBMGR_$$
| Conseil : Assurez-vous que vous entrez la même valeur tcpport qui est utilisée
| par le serveur. La valeur tcpport est spécifiée dans le fichier dsmserv.opt.
| 5. Arrêtez et démarrez l'instance de base de données :
| a. Arrêtez DB2:
| db2stop
| b. Démarrez DB2:
| db2start
| 6. Définissez le mot de passe de l'API :
| a. Vérifiez que le serveur Tivoli Storage Manager est démarré. Pour en savoir
| plus, voir «Démarrage du serveur», à la page 460.
| b. Connectez-vous à l'aide de l'ID utilisateur root.
| c. Définissez la source du profil de gestionnaire de base de données en
| un espace et le chemin d'accès au fichier db2profile. Si vous n'entrez pas
| d. Modifiez le mot de passe de l'API. Utilisez la commande suivante :
| /home/tsminst1/sqllib/adsm/dsmapipw
| e. Lorsque vous y êtes invités par la commande dsmapipw, indiquez comme
| TSMDBMGR mot de passe initial et nouveau mot de passe.
| f. Entrez la commande de système d'exploitation suivante :
| rm /home/tsminst1/tsminst1/tsmdbmgr.log
|
| Scénario de migration 3: Utilisation de la méthode de réseau et de
| l'assistant de mise à jour
| Procédez comme suit si vous si vous migrez le serveur grâce à la métode de
| support réseau et à l'assistant de mise à niveau. Grâce à la méthode de réseau,
| vous pouvez extraire simultanément les données de la base de données d'origine et
| les charger dans la nouvelle base de données sur une connexion réseau. Grâce à
| l'assistant, vous simplifiez le processus de configuration.

| :
Linux
| a. «Scénario de migration 3: Installation du serveur V6.3.4 or ou ultérieure»
| b. «Scénario de migration 3: Configuration des paramètres des périphériques»,
| à la page 442
| c. «Scénario de migration 3: Création de l'ID utilisateur et des répertoires pour
| d. «Scénario de migration 3: Exécution de l'assistant de mise à niveau», à la
| page 444


| ultérieure


|
||
Linux


| chmod

| CZ1N1ML.
| ./nom_module.bin

| comme suit :
| ./prereqcheck.bin

| ./install.bin
Linux

Linux


| périphériques

Linux



| # passwd tsminst1
Linux

| actif
| journal actif
| pour le journal
| d'archivage
|
| Scénario de migration 3: Exécution de l'assistant de mise à

| niveau
| L'assistant offre une approche guidée pour la mise à niveau d'un serveur. Lancez
| l'assistant sur le système où vous avez installé le programme du serveur version
| 6.3.4 or ou ultérieure.
| Avant de lancer l'assistant de mise à niveau, effectuez les étapes précédentes afin
| de préparer la mise à niveau. Assurez-vous avoir sauvegardé les données du
| serveur et les fichiers de configuration. Vérifiez également que vous avez installé le
| programme serveur version 6.3.4 or ou ultérieure et créez les répertoires et les ID
| utilisateur pour l'instance de serveur.
| 1. Vérifiez que les conditions suivantes sont remplies :
| v Le système sur lequel vous avez installé le programme du serveur version
| 6.3.4 or ou ultérieure doit disposer du client X Window. Un serveur X
| Window doit également être en cours d'exécution sur votre bureau.
| v L'un des protocoles suivants doit être activé au niveau du système. Vérifiez
| que le port que le protocole utilise n'est pas bloqué par un pare-feu.
Linux
| – Secure Shell (SSH). Vérifiez que le port affiche la valeur par défaut (22).
| Assurez-vous également que le service démon possède les droits d'accès
| pour se connecter au système en utilisant localhost.
| – Remote shell (rsh).
| – Protocole d'exécution éloigné (REXEC).
| L'un des protocoles du serveur version 5 doit également être activé.
| v Vous devez pouvoir vous connecter au système version 6.3.4 or ou ultérieure
| sous l'ID utilisateur que vous avez créé pour l'instance du serveur à l'aide du
| protocole SSH, rsh ou REXEC. Lorsque vous utilisez l'assistant, vous devez
| fournir cet ID utilisateur et ce mot de passe pour accéder à ce système.
| 2. Lancez l'assistant de mise à niveau, dsmupgdx, à partir du répertoire
| d'installation du serveur version 6.3.4 or ou ultérieure. Connectez-vous à l'aide
| de l'ID utilisateur root :
| /opt/tivoli/tsm/server/bin/dsmupgdx
| 3. Suivez les instructions permettant de terminer la mise à niveau. L'assistant de
| mise à niveau peut être arrêté et redémarré, mais le serveur ne sera pas
| opérationnel tant que le processus de mise à niveau n'est pas entièrement
| terminé. Prenez connaissance de tous les messages qui s'affichent pour chaque
| phase du processus de mise à niveau dans l'assistant. Votre attention peut être
| recommandée par des messages d'information.
|
| Scénario de migration 4: Utilisation de la méthode de réseau et de la
| ligne de commande
| Procédez comme suit si vous migrez la base de données du serveur à l'aide de la
| méthode de réseau et de la ligne de commande. Grâce à la méthode de réseau,
| vous pouvez extraire simultanément les données de la base de données d'origine et
| les charger dans la nouvelle base de données sur une connexion réseau. Grâce aux
| commandes d'administration, vous pouvez migrer le système manuellement.

| :
| a. «Scénario de migration 4: préparation de la base de données du serveur V5»
| , à la page 446
| b. «Scénario de migration 4: Installation du serveur V6.3.4 or ou ultérieure», à
| la page 446
| c. «Scénario de migration 4: Configuration des paramètres des périphériques»,
| à la page 449
| d. «Scénario de migration 4: Création de l'ID utilisateur et des répertoires pour
| e. «Scénario de migration 4: Création de l'instance de serveur et de la base de
| données», à la page 451
| f. «Scénario de migration 4: Transfert de la base de données du serveur via un
| réseau», à la page 454
| g. «Scénario de migration 4:Configuration du système en vue de la sauvegarde
| de la base de données», à la page 456
Linux

| Scénario de migration 4: préparation de la base de données

| du serveur V5
| Avant d'extraire les données de la base de données du serveur V5, vous devez
| préparer la base de données à l'aide de l'utilitaire DSMUPGRD PREPAREDB. Si plusieurs
| serveurs sont installés sur un seul système, répétez cette tâche pour chaque
| serveur.
| Les utilitaires de mise à niveau doivent être installés sur le système V5.
| 1. Vérifiez que les étapes de préparation ont été effectuées. Pour obtenir des
| instructions, voir Chapitre 14, «Préparation de la migration», à la page 405.
| 2. Connectez-vous à l'aide de l'ID utilisateur root sur le système V5.
| 3. Accédez au répertoire d'instance du serveur que vous mettez à niveau. Le
| répertoire d'instance est celui qui contient les fichiers, tels que dsmserv.dsk, du
| serveur.
| 4. Préparez la base de données. Dirigez la sortie du processus vers un fichier à
| des fins de surveillance. A partir du répertoire d'instance du serveur que vous
| mettez à niveau, lancez la commande suivante pour exécuter le processus en
| arrière-plan et diriger la sortie vers le fichier prepare.out :
| AIX
| nohup /usr/tivoli/tsm/upgrade/bin/dsmupgrd preparedb >prepare.out 2>&1 &
| HPUX Solaris
| nohup /opt/tivoli/tsm/upgrade/bin/dsmupgrd preparedb >prepare.out 2>&1 &

| d'avertissement. Le message final indique la réussite ou l'échec de l'opération.
| A partir du répertoire de l'instance du serveur que vous mettez à niveau,
| lancez la commande suivante pour surveiller le processus :
| tail -f prepare.out
| Assurez-vous que l'opération de préparation a réussi avant de passer à l'étape

| suivante. Si ce n'est pas le cas, il se peut que vous deviez redémarrer le serveur
| version 5 pour résoudre le problème et réexécuter l'opération de préparation. Si la
| version du serveur mis à niveau est 5.3 ou 5.4, il peut être nécessaire de restaurer
| la base de données à l'aide d'une sauvegarde. Vous pouvez ensuite redémarrer le
| serveur pour corriger le problème.

| ultérieure

Linux

|
|
|

| chmod

| CZ1N1ML.
| ./nom_module.bin

| comme suit :
| ./prereqcheck.bin
Linux

| ./install.bin
Linux


| périphériques

Linux



| # passwd tsminst1
Linux
| actif
| journal actif
| pour le journal
| d'archivage
|
| Scénario de migration 4: Création de l'instance de serveur et

| de la base de données
| Créez l'instance du serveur et formatez les fichiers pour une base de données
| version 6.3.4 or ou ultérieure vide.
| 1. Connectez-vous au système sur lequel vous avez installé le programme V6.3.4
| or ou ultérieure à l'aide de L'ID du superutilisateur.
| Vérifiez les éléments suivants :
| v Le répertoire de base de l'utilisateur, /home/tsminst1, existe. S'il
| n'existe pas de répertoire de base, vous devez le créer.
Linux
| v Le répertoire d'instance stocke les fichiers core suivants générés par

| le serveur Tivoli Storage Manager :
| – Le fichier d'options du serveur, dsmserv.opt
| – Le fichier de base de données de clés du serveur, cert.kdb, et les
| fichiers .arm, qui sont utilisés par des clients et d'autres serveurs
| pour importer les certificats Secure Sockets Layer du serveur
| – Fichier de configuration d'unité si l'option de serveur DEVCONFIG
| n'indique pas un nom complet
| – Fichier d'historique des volumes si l'option de serveur
| VOLUMEHISTORY n'indique pas un nom complet
| – Volumes des pools de stockage du type d'unité FILE, si le
| répertoire de la classe du périphérique n'est pas complètement
| défine, ou pas pleinement qualifié
| – Exits utilisateur
| – La sortie de trace, si le nom qualifié complet n'est pas indiqué
| v Un fichier de configuration de l'interpréteur de commandes,par
| exemple un fichier .profile, existe dans le répertoire de base. L'ID
| de superutilisateur et d'utilisateur d'instance doit disposer de droits
| d'accès en écriture à ce fichier. Pour plus d'informations, visiter le
| centre de documentationDB2 et recherchez des informations sur les
| paramètres des variables d'environnementLinux and UNIX.
| 2. Créez une instance Tivoli Storage Manager à l'aide de la commande db2icrt.
| Entrez la commande suivante sur une seule ligne. Pour le nom d'instance,
| indiquez l'ID utilisateur créé pour être propriétaire de l'instance :
| id_utilisateur nom_instance
| Par exemple, si l'ID utilisateur pour cette instance est tsminst1, utilisez la
| commande suivante pour créer l'instance :
| tsminst1 tsminst1
| A faire : A ce stade, utilisez ce nouvel ID utilisateur lors de la configuration

| du serveur Tivoli Storage Manager. Déconnectez-vous de l'ID superutilisateur
| et connectez-vous à l'aide du nom d'utilisateur qui est le propriétaire de
| l'instance.
| 3. Connectez-vous au système à l'aide de l'ID utilisateur possédant l'instance de
| serveur version 6.3.4 or ou ultérieure (ID utilisateur d'instance).
| 4. Copiez le fichier d'options du serveur à partir du serveur V5 vers le répertoire
| d'instance que vous avez créé pour le serveur V6.3.4 or ou ultérieure. fichier
| d'options du serveur est généralement appelé dsmserv.opt. Par exemple, si
| vous avez créé le répertoire d'instance figurant dans l'exemple lors de l'étape
| de création de répertoires, copiez les fichiers dans le répertoire suivant:
| /tsminst1
| Assurez-vous que l'ID utilisateur d'instance est propriétaire de ou possède des
| droits en lecture/écriture du fichier d'options du serveur.
| 5. Modifiez le fichier d'options du serveur.
| a. Supprimez toute option non prise en charge pour la version 6.3 ou
| ultérieure. Vous trouverez la liste des options supprimées, dans le
| tableau 36, à la page 78.
| b. Vérifiez que le fichier d'options du serveur contient au moins une option
| VOLUMEHISTORY et au moins une option DEVCONFIG. Un fichier d'historique
Linux
| des volumes et un fichier de configuration d'unité sont nécessaires lorsque

| vous devez restaurer la base de données, générer des copies automatiques
| de ces fichiers. Vous pouvez ainsi faire en sorte que les fichiers soient
| disponibles en cas de besoin.
| c. Vérifiez si le fichier d'options du serveur inclut l'option TXNGROUPMAX avec
| une valeur définie et, si oui, vérifiez quelle est cette valeur. Vous pouvez
| modifier la valeur courante, car la valeur par défaut pour cette option
| passe de 256 à 4096 avec la version 6.3 ou ultérieure. L'augmentation de la
| valeur peut améliorer les performance des opérations de transfert des
| données, comme la migration d'un pool de stockage et la sauvegarde d'un
| pool de stockage.
| v Si le fichier d'options du serveur inclut cette option, le serveur utilise
| automatiquement la nouvelle valeur par défaut : 4096.
| v Si une valeur a été définie dans le fichier d'options du serveur pour
| cette option, le serveur utilise cette valeur. Si la valeur indiquée est
| inférieure à 4096, vous pouvez l'augmenter ou supprimer l'option afin
| que le serveur utilise la nouvelle valeur par défaut.
| 6. Modifiez le chemin d'accès par défaut à la base de données afin qu'il
| corresponde au répertoire d'instance du serveur. Exécutez la commande :
| db2 update dbm cfg using dftdbpath répertoire_instance
| Par exemple:
| db2 update dbm cfg à l’aide de dftdbpath /tsminst1
| 7. Modifiez le chemin d'accès à la bibliothèque pour utiliser la version d'IBM
| Global Security Kit (GSKit) installé avec le serveur Tivoli Storage Manager .
| Vous devez mettre à jour les fichiers suivants pour définir le chemin d'accès à
| la bibliothèque lorsque DB2 ou le serveur Tivoli Storage Manager sont
| démarrés :
| v répertoire_instance/sqllib/usercshrc
| v répertoire_instance/sqllib/userprofile
| Pour le fichier instance_directory/sqllib/usercshrc, ajoutez la ligne
| suivante:
| setenv LD_LIBRARY_PATH /usr/local/ibm/gsk8_64/lib64:$LD_LIBRARY_PATH
| Pour le fichier répertoire_instance/sqllib/userprofile, ajoutez les lignes

| suivantes :
| LD_LIBRARY_PATH=/usr/local/ibm/gsk8_64/lib64:$LD_LIBRARY_PATH
| export LD_LIBRARY_PATH
| Vérifiez les paramètres de chemin d'accès à la bibliothèque et vérifiez que la

| version GSKit est la version 8.0.14.14 ou ultérieure. Exécutez les commandes
| suivantes à partir du répertoire de base de l'instance, par exemple,
| /home/tsminst1:
| echo $LD_LIBRARY_PATH
| gsk8capicmd_64 -version
| gsk8ver_64
| Si votre version de GSKit n'est pas la version 8.0.14.14 ou une version
| ultérieure, vous devez réinstaller le serveur Tivoli Storage Manager. La
| réinstallation permet de s'assurer que la version GSKit correcte est disponible.
| 8. Effectuez cette étape pour définir la page de code de serveur.
Linux
| Définissez la variable d'environnement système DB2CODEPAGE à 819 pour

| chaque instance de serveur. Avant d'exécuter la commande DSMSERV
| LOADFORMAT, connectez-vous au système en tant que propriétaire de l'instance
| de serveur puis exécutez la commande:
| db2set
| -i nom_instance DB2CODEPAGE=819
| Exemple :
| db2set -i tsminst1 DB2CODEPAGE=819
| 9. Accédez au répertoire d'instance que vous avez créé pour le serveur.
| 10. Créez et définissez le format de la base de données et des journaux de
| récupération à l'aide de la commande DSMSERV LOADFORMAT. Dans la
| commande, indiquez les répertoires que vous avez créés pour la base de
| données et les journaux. Les répertoires doivent être vides.
| Par exemple, pour obtenir une taille de journal actif de 16 GB ou 16384 MB, ce
| qui constitue la taille par défaut exécutez la commande sur une seule ligne:
| /opt/tivoli/tsm/server/bin/dsmserv loadformat \
| dbdir=/tsmdb001,/tsmdb002,/tsmdb003,/tsmdb004 \
| activelogsize=16384 activelogdirectory=/tsmlog \
| mirrorlogdirectory=/tsmlogmirror archlogdirectory=/tsmarchlog
| Pour plus d'informations sur la création et le mise en forme d'une base de
| données voir Annexe A, «Utilitaires, scripts et commandes pour la mise à
| d'avertissement. Le message final indique que l'opération a échoué ou a réussi.
| Scénario de migration 4: Transfert de la base de données du

| serveur via un réseau
| Transférez la base de données en lançant le processus d'insertion pour que le
| serveur version 6.3.4 or ou ultérieure accepte la base de données du serveur.
| Démarrez ensuite le processus d'extraction pour que le serveur version 5 puisse
| extraire et envoyer la base de données.
| Avant de lancer cette procédure, vérifiez que le serveur version 5 et le nouveau

| serveur ne sont pas en cours d'exécution.
| Pour transférer la base de données du serveur sur un réseau, effectuez les étapes
| suivantes:
| 1. Vérifiez qu'une connexion réseau correcte est établie entre les deux systèmes.
| 2. Démarrez le processus d'insertion sur le serveur version 6.3.4 or ou ultérieure
| en vue d'accepter la base de données. Utilisez la commandeDSMSERV INSERTDB.
| Pour surveiller le processus, dirigez sa sortie vers un fichier. Par exemple, pour
| démarrer le serveur en respectant un délai de 60 minutes (durée par défaut)
| nécessaire au serveur V5 pour contacter le serveur V6.3.4 or ou ultérieure et en
| dirigeant la sortie du processus vers le fichier insert.out, exécutez la
| nohup /opt/tivoli/tsm/server/bin/dsmserv insertdb \
| sesswait=60 >insert.out 2>&1 &
| Pour en savoir plus sur l'insertion des données, voir Annexe A, «Utilitaires,
| scripts et commandes pour la mise à niveau de serveur et la migration», à la
| page 561.
Linux
| Le serveur démarre et attend 60 minutes, le temps qu'il soit contacté par le

| serveur d'origine. Une certaine période peut s'écouler durant laquelle aucun
| message n'est généré. Durant ce temps, les opérations DB2 s'exécutent en
| arrière-plan. Facultatif : pour vérifier que les opérations se poursuivent comme
| prévu, surveillez l'utilisation de l'unité centrale et la présence des
| entrées-sorties pour le processus du serveur et le processus DB2 correspondant.
| 3. Surveillez la sortie du processus DSMSERV INSERTDB. Vérifiez que le processus
| DSMSERV INSERTDB émet le message suivant avant d'aller à l'étape suivante:
| ANR1336I INSERTDB: Serveur source prêt pour les connexions
| Pour surveiller la sortie du processus dans le fichier insert.out, exécutez la

| tail -f insert.out
| 4. Lancez le processus d'extraction de données à partir du serveur original à l'aide
| de la commande DSMUPGRD EXTRACTDB. Lancez la commande à partir du
| répertoire du serveur version 5. Indiquez l'adresse TCP/IP et le port du serveur
| version 6.3.4 or ou ultérieure. Dirigez la sortie du processus vers un fichier à
| des fins de surveillance. Par exemple, exécutez la commande suivante, sur une
| seule ligne :
| AIX
| nohup /usr/tivoli/tsm/upgrade/bin/dsmupgrd extractdb \

| hladdress=9.11.25.124 lladdress=1500 >extract.out 2>&1 &
| HPUX Solaris
| nohup /opt/tivoli/tsm/upgrade/bin/dsmupgrd extractdb \

| hladdress=9.11.25.124 lladdress=1500 >extract.out 2>&1 &
| Pour en savoir plus sur l'extraction de données, voir Annexe A, «Utilitaires,
| scripts et commandes pour la mise à niveau de serveur et la migration», à la
| page 561.
| 5. Surveillez les processus pour détecter des messages d'erreur et d'avertissement
| ainsi que des éléments que vous pourriez devoir résoudre. A partir du
| répertoire de l'instance du serveur que vous mettez à niveau, lancez la
| commande suivante pour surveiller le processus d'extraction :
| tail -f extract.out
| La durée du processus dépend de la taille de la base de données, du matériel

| utilisé et du réseau.
| 6. Examinez les résultats des processus d'extraction et d'insertion pour consulter
| les messages indiquant la réussite ou l'échec des opérations.
|| Processus Message de réussite Message d'échec
| Extraction ANR1382I EXTRACTDB : le ANR1396E EXTRACTDB : le
| processus 1, l'extraction de la processus 1, l'extraction de la
| base de données, est terminé. base de données, est terminé
| mais des erreurs se sont
| produites.
| Insertion ANR1395I INSERTDB : le ANR1396E INSERTDB : le
| processus 1, l'insertion de la processus 1, l'insertion de la
| base de données, est terminé. base de données, est terminé
| mais des erreurs se sont
| produites.
|
Linux
| Scénario de migration 4:Configuration du système en vue de

| la sauvegarde de la base de données
| Si vous n'avez pas utilisé l'assistant de mise à niveau, vous devez terminer la
| configuration de sauvegarde de base de données manuellement.
| Dans les étapes ci-après, tsminst1 correspond à l'ID utilisateur de l'instance de

| serveur et /tsminst1 au répertoire de l'instance de serveur Tivoli Storage Manager.
| 1. Configurez la variable d'environnement de l'API Tivoli Storage Manager pour
| l'instance de base de données :
| a. Connectez-vous à l'aide de l'ID utilisateur tsminst1.
| b. Lorsque l'utilisateur tsminst1 est connecté, assurez-vous que
| l'environnement DB2 est correctement initialisé. L'environnement DB2 est
| initialisé via l'exécution du script /home/tsminst1/sqllib/db2profile, qui
| s'exécute normalement depuis le profil de l'ID utilisateur. Si
| /home/tsminst1/.profile n'exécute pas le script db2profile, par exemple
| lorsque vous utilisez l'interpréteur de commandes Korn (/bin/ksh), ajoutez
| les lignes suivantes /home/tsminst1/.profile:
| if [ -f /home/tsminst1/sqllib/db2profile ]; puis
| fi
| c. Ajoutez ou mettez à jour les lignes suivantes dans le fichier useprofile
| dans le répertoire /home/tsminst1/sqllib :
| 2. Déconnectez-vous, puis reconnectez-vous sous tsminst1 ou exécutez la
| . ~/.profile
| Conseil : Assurez-vous que vous entrez dans un espace après le point initial (.)
| caractère !.
| 3. Créez un fichier dénommé tsmdbmgr.opt dans le répertoire /tsminst1 et ajoutez
| la ligne suivante:
| SERVERNAME TSMDBMGR_TSMINST1
| A faire : Le nom utilisé doit être identique à celui de l'instance de serveur.

| 4. Ajoutez les lignes suivantes au fichier de configuration de l'API Tivoli Storage
| Manager dsm.sys. Le fichier de configuration dsm.sys se trouve à
| l'emplacement par défaut suivant:
| /opt/tivoli/tsm/client/api/bin64/dsm.sys
| Evitez de placer le nom du serveur, TSMDBMGR_TSMINST1,en première
| position dans le fichier dsm.sys car sinon, il constituerait la valeur par défaut
| du système. Dans cet exemple, les lignes ajoutées se trouvent après la section
| correspondant à server_a.
| Servername server_a
| COMMMethod TCPip
| TCPPort 1500
| TCPServeraddress node.domain.company.COM
|
|
| servername TSMDBMGR_TSMINST1
| commmethod tcpip
| tcpserveraddr localhost
| tcpport 1500
Linux
| passwordaccess generate
| passworddir /home/tsminst1/tsminst1
| errorlogname /home/tsminst1/tsminst1/tsmdbmgr.log
| nodename $$_TSMDBMGR_$$
| Conseil : Assurez-vous que vous entrez la même valeur tcpport qui est utilisée
| par le serveur. La valeur tcpport est spécifiée dans le fichier dsmserv.opt.
| 5. Arrêtez et démarrez l'instance de base de données :
| a. Arrêtez DB2:
| db2stop
| b. Démarrez DB2:
| db2start
| 6. Définissez le mot de passe de l'API :
| a. Vérifiez que le serveur Tivoli Storage Manager est démarré. Pour en savoir
| plus, voir «Démarrage du serveur», à la page 460.
| b. Connectez-vous à l'aide de l'ID utilisateur root.
| c. Définissez la source du profil de gestionnaire de base de données en
| un espace et le chemin d'accès au fichier db2profile. Si vous n'entrez pas
| d. Modifiez le mot de passe de l'API. Utilisez la commande suivante :
| /home/tsminst1/sqllib/adsm/dsmapipw
| e. Lorsque vous y êtes invités par la commande dsmapipw, indiquez comme
| TSMDBMGR mot de passe initial et nouveau mot de passe.
| f. Entrez la commande de système d'exploitation suivante :
| rm /home/tsminst1/tsminst1/tsmdbmgr.log
|
|
| Chapitre 16. Exécution des premières étapes après la mise à

| niveau
| Vérifiez que le serveur a bien été migré et qu'il fonctionne normalement. Cette
| vérification concerne le démarrage du serveur, l'enregistrement des licences et la
| sauvegarde de la base de données. Après avoir effectué ces étapes, vous pouvez
| commencer les opérations et surveiller le serveur migré.
| Effectuez les étapes suivantes :

| 1. «Configuration des options de serveur pour la maintenance de la base de
| données serveur»
| 2. «Démarrage du serveur», à la page 460
| 3. «Vérification des résultats de la migration», à la page 464
| 4. «Enregistrement des licences», à la page 464
| 5. «Mise à jour des informations du chemin d'accès à l'unité», à la page 465
| 6. «Sauvegarde de la base de données», à la page 465
| 7. «Changement du nom d'hôte pour le serveur Tivoli Storage Manager», à la
| page 466
| 8. «Mise à jour de l'option tcpserveraddress», à la page 467
| 9. «Configuration de l'adresse IP du serveur», à la page 467
| 10. «Migration des données d'une bande magnétique vers des unités de DISQUE
| ou de FICHIER», à la page 469
| 11. «Restauration de groupes de sauvegarde», à la page 470
| 12. «Mise à jour de l'automatisation», à la page 471
| 13. «Début des opérations et surveillance des serveurs», à la page 471
| Après avoir migré le système vers la version 6.3.3, vous pouvez authentifier les
| mots de passe à l'aide du serveur d'annuaire LDAP ou authentifier les mots de
| passe à l'aide du serveur Tivoli Storage Manager. Les mots de passe qui sont
| authentifiés à l'aide du serveur d'annuaire LDAP peuvent fournir une sécurité de
| système améliorée. Pour plus de détails, voir la section relative à la gestion des
| mots de passe et des procédures de connexion dans le Guide d'administration.
|
| Configuration des options de serveur pour la maintenance de la base
| de données serveur
| Afin d'éviter les problèmes liés à la croissance de la base de données et aux
| performances de serveur, le serveur surveille automatiquement les tables de sa
| base de données et les réorganise si nécessaire. Avant de démarrer le serveur pour
| une utilisation en production, définissez les options de serveur afin de contrôler le
| moment où la réorganisation est exécutée. Si vous prévoyez d'utiliser le
| dédoublonnage, assurez-vous que l'option permettant d'exécuter la réorganisation
| de l'index est activée.
| La réorganisation des tables et des index requiert des ressources de processeur

| importantes, un espace de journal actif et un espace de journal d'archivage.
| Comme la sauvegarde de base de données est prioritaire par rapport à la
| réorganisation, sélectionnez l'heure et la durée de la réorganisation afin de vous

Linux
| assurer que les processus ne se chevauchent pas et que la réorganisation peut être
| effectuée. Pour en savoir plus sur la planification de la réorganisation, voirGuide
| d'administration.
| 1. Modifiez les options de serveur
| Editez le fichier d'options du serveur, dsmserv.opt, dans le répertoire d'instance
| du serveur. Suivez ces instructions lorsque vous modifiez le fichier d'options
| du serveur:
| v Pour activer une option, supprimez l'astérisque placé au début de la ligne.
| v Commencez à saisir une option dans l'une des lignes.
| v Saisissez une seule option par ligne. L'option complète avec sa valeur doit
| occuper une seule ligne.
| v Si vous avez plusieurs entrées pour une option du fichier, le serveur utilise la
| dernière.
| v Pour consulter les options de serveur disponibles, reportez-vous au modèle
| de fichier, dsmserv.opt.smp, dans le répertoire /opt/tivoli/tsm/server/bin.
| 2. Si vous envisagez d'utiliser le dédoublonnage des données, activez l'option du
| serveur ALLOWREORGINDEX. Ajoutez l'option et la valeur suivantes au fichier
| d'options du serveur :
| allowreorgindex yes
| 3. Paramétrez deux options de serveur contrôlant le moment où la réorganisation
| commence et combien de temps elle dure. Sélectionnez une heure et une durée
| de telle sorte que la réorganisation soit exécutée au moment où vous pensez
| que le serveur est le moins occupé. Ces options de serveur contrôlent les
| processus de réorganisation des tables et des index.
| a. Paramétrez l'heure de démarrage de la réorganisation à l'aide de l'option de
| serveur REORGBEGINTIME. Indiquez l'heure au format 24 heures. Par exemple,
| pour paramétrer l'heure de début de la réorganisation à 16h30, définissez
| l'option et la valeur suivantes dans le fichier d'options du serveur :
| reorgbegintime 20:30
| b. Paramétrez l'intervalle au cours duquel le serveur peut commencer la
| réorganisation. Par exemple, pour indiquer que le serveur peut commencer
| la réorganisation quatre heures après l'heure paramétrée à l'aide de l'option
| de serveur REORGBEGINTIME, définissez l'option et la valeur suivantes dans le
| fichier d'options du serveur :
| reorgduration 4
| 4. Activez éventuellement la fonction de reconnaissance SAN:
| sandiscovery on
| Conseil : La reconnaissance SAN permet au serveur de corriger

| automatiquement le nom de fichier spécial d'une unité s'il a été remplacé par
| une unité de bande précise.
|
| Démarrage du serveur
| Avant de démarrer le serveur, vérifiez que les droits d'accès et les valeurs ulimit
| sont correctement définies.Puis lancez le serveur version 6.3.4 or ou ultérieure pour
| vérifier qu'il est correctement installé.
| Restriction : Si vous ne disposez pas des droits d'utilisation du programme

| DSMSERV, vous ne pouvez pas démarrer le serveur. Si vous n'avez pas de droits
| en lecture ou en écriture sur les fichiers contenus dans le répertoire de l'instance,
| vous ne pourrez pas démarrer cette instance du serveur.
Linux
| La méthode standard pour démarrer le serveur consiste à utiliser l'ID utilisateur

| d'instance. A l'aide de l'ID utilisateur d'instance, vous simplifiez le processus de
| configuration et évitez des problèmes potentiels. Cependant, dans certains cas, il
| peut être nécessaire d'utiliser un autre ID utilisateur pour démarrer le serveur. Par
| exemple, vous souhaiterez peut-être utiliser l'ID utilisateur root pour vous assurer
| que le serveur peut accéder à des périphériques spécifiques. Pour permettre à un
| autre utilisateur que l'ID utilisateur d'instance de démarrer le serveur, l'ID
| utilisateur doit posséder les droits suffisants pour émettre la commande de
| démarrage du serveur et du gestionnaire de base de données. Par ailleurs, il doit
| appartenir au groupe SYSADM_GROUP. L'ID utilisateur doit avoir le droit
| d'accéder à la base de données du serveur et d'utiliser tous les fichiers, répertoires
| et périphériques requis par le serveur. Avant de démarrer le serveur, accordez
| explicitement les droits d'accès à la base de données du serveur à l'ID utilisateur et
| vérifiez tous les autres droits de l'ID utilisateur.
| Lorsque vous démarrez le serveur Tivoli Storage Manager, ce dernier tente de

| changer certaines valeurs ulimit en illimité. En règle générale, ce processus garantit
| des performances optimales et facilite le débogage. Si vous êtes un utilisateur non
| superutilisateur au démarrage du serveur, les tentatives de modifications des
| valeurs ulimit peuvent échouer. Pour garantir un bon fonctionnement du serveur si
| vous utilisez le serveur en tant qu'utilisateur non superutilisateur, définissez les
| valeurs ulimit aussi élevées que possible avant de lancer leserveur.
| Lorsque vous spécifiez les valeurs ulimit, assurez-vous de définirles limites

| utilisateur DB2 aussi élevéesque possible. DB2 repose sur une mémoire de données
| privée pour le tri des allocations de mémoire lors du traitement SQL. Une capacité
| de segment de mémoire partagée insuffisante peut occasionner des échecs du
| serveur Tivoli Storage Manager lors de l'interaction avec DB2. Pour plus
| d'informations sur la configuration des valeurs du système d'exploitation
| approprié, reportez-vous à la note technique 1212174 (http://www.ibm.com/
| support/docview.wss?uid=swg21212174).
| Pour obtenir des instructions sur la définition de valeurs ulimit, consultez le

| tableau suivant :
| Tableau 73. Valeurs Ulimit
| Type de valeur Ulimit Valeur standard
| Taille maximum des fichiers core créés Illimité
| Taille maximum du segment de données Illimité
| d'un processus
| Taille de fichier maximale Illimité
|| Nombre maximum de fichiers ouverts v Pour les serveurs sur lesquels sont activés
| de 16384.
| Délai maximal d'exécution du processeur en Illimité
| secondes
|
Linux
| La valeur par défaut pour la limite utilisateur des processus utilisateur maximum
| (nproc) a changé sur certaines distributions et versions du système d'exploitation
| Linux. La nouvelle valeur par défaut est 1024. Cette valeur peut entraîner un
| comportement inattendu dans le serveur Tivoli Storage Manager. Pour le système
| d'exploitation Red Hat Enterprise Linux (RHEL) 6, la valeur par défaut de nproc a
| été réduite à 1024. Cette valeur peut avoir changé dans d'autres versions et
| distributions de Linux qui sont prises en charge par le serveur Tivoli Storage
| Manager. Augmentez la limite utilisateur des processus utilisateur maximum à la
| valeur minimale recommandée de 16384. Si la valeur n'est pas mise à jour, le
| serveur peut présenter un comportement inattendu, y compris des blocages ou des
| pannes. Pour vérifier la limite utilisateur en cours, lancez la commande suivante en
| tant qu'utilisateur d'instance :
| ulimit -u
| Par exemple :
| [user@Machine ~]$ ulimit -u
| 16384
| Pour afficher les valeurs en cours de toutes les limites utilisateur, exécutez la
| ulimit -a
| Par exemple :
| [user@Machine ~]$ ulimit -a
| core file size (blocks, -c) 0
| data seg size (kbytes, -d) unlimited
| scheduling priority (-e) 0
| file size (blocks, -f) unlimited
| pending signals (-i) 128098
| max locked memory (kbytes, -l) 64
| max memory size (kbytes, -m) unlimited
| open files (-n) 1024
| pipe size (512 bytes, -p) 8
| POSIX message queues (bytes, -q) 819200
| real-time priority (-r) 0
| stack size (kbytes, -s) 10240
| cpu time (seconds, -t) unlimited
| max user processes (-u) 16384
| virtual memory (kbytes, -v) unlimited
| file locks (-x) unlimited
| Pour mettre à jour la limite utilisateur des processus utilisateur maximum, ajoutez
| une ligne au fichier /etc/security/limits.conf. Sur le système d'exploitation
| RHEL 6, la limite utilisateur pour nproc est définie dans le fichier
| /etc/security/limits.d/90-nproc.conf. Ce fichier remplace les paramètres du
| fichier /etc/security/limits.conf. Pour mettre à jour la limite utilisateur sur le
| système d'exploitation RHEL 6, vous devez soit éditer le fichier dans le répertoire
| /etc/security/limits.d ou supprimer le fichier et ajouter une ligne au fichier
| /etc/security/limits.conf.
| Démarrage du serveur à l'aide de l'ID utilisateur d'instance

| L'ID utilisateur d'instance possède un profil utilisateur qui lui permet d'exécuter le
| serveur avec les autorisations nécessaires.
| 1. Connectez-vous à l'aide de l'ID utilisateur d'instance.
Linux
| Conseil : Le script db2profile définit les variables d'environnement pour les

| bases de données de l'instance de serveur. Lors de la définition de l'instance de
| serveur, le script est ajouté au profil de configuration pour l'ID utilisateur
| d'instance, si ce profil existe.
| Si vous vous connectez à l'aide de l'ID utilisateur d'instance et si cet ID dispose

| d'un profil de configuration (.profile si vous utilisez l'interpréteur de
| commandes Korn) lors de la définition de l'instance de serveur, le script
| db2profile s'exécute automatiquement. Si l'ID ne dispose d'aucun profil ou si
| le script ne s'exécute pas automatiquement, exécutez-le manuellement à l'aide
| de la commande suivante :
| . ~/sqllib/db2profile
| 2. Accédez au répertoire d'instance correspondant à l'instance de serveur que
| vous voulez démarrer.
| 3. Démarrez l'instance du serveur en lançant la commande suivante :
| /opt/tivoli/tsm/server/bin/dsmserv
| Le programme du serveur s'exécute en arrière-plan pour vous permettre de

| configurer un ID administrateur et de vous connecter à l'instance de serveur.
| Exemple
| Dans cet exemple, le nom de l'instance du serveur Tivoli Storage Manager est
| tsminst1 et le répertoire d'instance est /tsminst1. Pour démarrer tsminst1, exécutez
| la commande suivante :
| cd /tsminst1
| /opt/tivoli/tsm/server/bin/dsmserv
| Pour démarrer le serveur en arrière-plan, exécutez la commande suivante :

| cd /tsminst1
| /opt/tivoli/tsm/server/bin/dsmserv -q &
| Démarrage du serveur à l'aide de l'ID de superutilisateur

| La méthode standard pour démarrer le serveur consiste à utiliser l'ID utilisateur
| d'instance. Cependant, dans certains cas, il peut être nécessaire d'utiliser un autre
| ID utilisateur pour démarrer le serveur. Par exemple, vous souhaiterez peut-être
| utiliser l'ID utilisateur root pour vous assurer que le serveur peut accéder à des
| périphériques spécifiques.
| Pour plus d'informations sur le démarrage du serveur à l'aide de l'ID

| superutilisateur, voir le Guide d'administration.
| Démarrage automatique des serveurs

| Linux
| Vous pouvez configurer les serveurs pour qu'ils démarrent automatiquement au

| démarrage du système. Utilisez le script dsmserv.rc qui est fourni dans ce but.
| Pour plus d'instructions, voir les informations relatives au démarrage automatique

| des serveurs sur le système d'exploitation Linux dans le Guide d'installation.
Linux
|
| Vérification des résultats de la migration
| A la suite de la migration, vérifiez le fonctionnement du serveurversion 6.3.4 or ou
| ultérieure. Surveillez le serveur pour des messages d'erreur et d'avertissement,
| vérifiez que les périphérique de stockage sont accessibles au serveur et effectuez
| des tests pour s'assurer que le système fonctionne comme planifié.
| 1. Surveillez les messages émis par le serveur au moment du démarrage.
| Recherchez les messages d'erreur et d'avertissement.
| 2. Vérifiez les éléments suivants :
| a. Assurez-vous que les périphérique de stockage du serveur d'origine sont
| accessible au serveur de mise à niveau.
| b. Comparez le nom des unités entre le nouveau système et le système
| d'origine. Le cas échéant, mettez à jour les définitions des unités sur le
| serveur. Par exemple, mettez à jour les définitions du chemin. Pour des
| instructions, voir «Mise à jour des informations du chemin d'accès à l'unité»
| , à la page 465.
| c. Mettez à jour l'adresse réseau utilisée par les clients de
| sauvegarde-archivage, les agents de stockage, les serveurs des clients de
| bibliothèque et d'autres serveurs destinés à communiquer avec le serveur
| mis à niveau.
| Au lieu d'effectuer ces mises à jour, vous pouvez éventuellement utiliser
| l'adresse réseau du système d'origine en tant qu'adresse du nouveau
| système. Vous avez également la possibilité de mettre à jour le système de
| nom de domaine (DNS) pour qu'il désigne le nouveau système au lieu du
| système d'origine. Prenez contact avec votre administrateur système.
| 3. Vérifiez que vous pouvez vous connecter au serveur via un client
| d'administration comme avec la version antérieure du serveur.
| 4. Exécutez les commandes permettant d'obtenir un résumé des informations
| contenues dans la base de données. Comparez le récapitulatif avec les résultats
| obtenus pour les mêmes commandes avant la migration de la base de données.
| Conseil : Pour plus d'informations sur les commandes exécutées avant la

| migration d'une base de données, voir«Création d'un récapitulatif du contenu
| de la base de données», à la page 410.
| 5. Effectuez des sauvegardes pour des postes client standard et vérifiez que leur
| fonctionnement est celui attendu.
| 6. Vérifiez que des opérations telles que le transfert de données hors réseau local
| et le partage de bibliothèques fonctionnent correctement.
| Si le serveur fonctionne correctement et que vous ne devez pas rétablir la version

| précédente, retourneztous les paramètres que vous avez modifiés pour préparer la
| mise à niveauaux valeurs d'origine.
|
| Enregistrement des licences
| Enregistrez immédiatement toute fonction Tivoli Storage Manager sous licence que
| vous avez achetée afin de ne pas perdre de données après avoir commencé à
| utiliser le serveur.
| Enregistrez les licences pour les composants de serveur Tivoli Storage Manager
| installés sur votre système en exécutant la commande REGISTER LICENSE, une
| commande d'administration Tivoli Storage Manager :
| enregistremnt du fichier de licence=*.lic
Linux
| Pour plus d'informations sur les licences d'enregistrement, voir la commande

| REGISTER LICENSE dans Guide de référence de l'administrateur.
| Restriction : Vous ne pouvez pas enregistrer de licences pour IBM Tivoli Storage
| Manager for Mail, IBM Tivoli Storage Manager for Databases, IBM Tivoli Storage
| Manager for Enterprise Resource Planning et IBM Tivoli Storage Manager for
| Space Management.
|
| Mise à jour des informations du chemin d'accès à l'unité
| Si la fonction de détection du réseau d'unités de stockage (SAN) n'est pas activée,
| mettez à jour le chemin d'accès à l'unité pour toutes les unités et bibliothèques.
| Cette étape est requise pour s'assurer que vous pouvez accéder aux périphériques
| de stockage via le nouveau système.
| L'option du serveur SANDISCOVERY est disponible pour corriger automatiquement

| un nom de fichier spécial d'une unité si le nom du fichier a changé en raison des
| modifications apportées dans dans un environnement SAN. Si l'option du serveur
| SANDISCOVERY est définie sur OFF, mettez à jour manuellement les informations du
| chemin d'accès à l'unité.
| Pour des instructions sur la mise à jour des informations du chemin d'accès à
| l'unité, voir la commande UPDATE PATH dans Guide de référence d'administration.
| Si l'option du serveur SANDISCOVERY est définie sur ON, les informations du chemin
| d'accès à l'unité pour les unités et bibliothèques doivent être mises à jour
| automatiquement lorsque le serveur version 6.3.4 or ou ultérieure démarre
| automatiquement.
|
| Sauvegarde de la base de données
| Après avoir migré les données, exécutez une sauvegarde complète de la base de
| données dès que possible. Sauvegardez également l'historique des volumes.
| 1. Effectuez les étapes suivantes :
| a. Si vous n'avez pas fait appel à l'assistant de configuration d'instance pour
| configurer le serveur, assurez-vous d'avoir effectué les étapes de
| configuration manuelle du système pour les sauvegardes de base de
| données.
| b. Si vous avez utilisé la méthode avec supports et une unité de bande,
| supprimez ou extrayez de la bibliothèque la bande qui a été utilisée pour
| recevoir les données extraites. Empêchez la réutilisation de la bande avant
| de vous assuré que le serveur version V6.3.4 or ou ultérieure fonctionne
| correctement et que vous n'avez pas besoin de répéter l'étape d'insertion de
| la base de données.
| 2. Sélectionnez la classe d'unités à utiliser pour les sauvegardes automatiques de
| la base de données. A partir de la ligne de commande d'administration Tivoli
| Storage Manager, lancez la commande suivante :
| configurez dbrecovery nom_classe_unités
| où device_class_name est le nom de la classe d'unités devant être utilisée par le

| gestionnaire de base de données pour toutes les sauvegardes automatiques de
| bases de données.
Linux
| Pour plus d'informations sur le choix d'une classe d'unités pour les
| sauvegardes automatiques, voir la commande SET DBRECOVERY dansGuide de
| référence d'administration.
| 3. Sauvegardez la base de données à l'aide de la commande suivante :
| backup db devclass=nom_classe_unités type=full
| où device_class_name est le nom de la classe d'unités. Vous pouvez spécifier la

| classe d'unités comme étant identique ou différente de celle que vous avez
| indiquée à l'aide de la commande SET DBRECOVERY. S'il s'agit d'une classe
| d'unités différente, un message d'avertissement s'affiche, mais la sauvegarde
| continue.
| commandeBACKUP DB dans Guide de référence d'administration.
| 4. Sauvegardez l'historique des volumes en exécutant la commande suivante:
| backup volhistory filenames=nom_fichier
| où file_name est le nom du le nom du fichier dans lequel les informations

| d'historique de volume sont enregistrées.
| commande BACKUP VOLHISTORY dans Guide de référence d'administration.
|
| Changement du nom d'hôte pour le serveur Tivoli Storage Manager
| Si vous devez changer le nom d'hôte du serveur Tivoli Storage Manager version
| 6.3.4 or ou ultérieure, vérifiez que vous mettez également à jour la configuration
| de base de données. L'échec dans la mise à niveau de la configuration de la base
| de données Tivoli pourrait empêcher le serveur Storage Manager de démarrer.
| 1. Arrêtez tous les serveurs Tivoli Storage Manager en cours d'exécution sur le
| système.
| 2. Modifiez le nom d'hôte en utilisant les procédures définies pour votre système
| d'exploitation.
| 3. A partir de l'ID superutilisateur du système, émettez la commande suivante :
| db2set -g DB2SYSTEM=nouveau_nom_d_hôte
| où newhostname est le nouveau nom d'hôte du serveur.
| Conseil : La commande db2set se trouve dans le répertoire

| /opt/tivoli/tsm/db2/adm.
| 4. Vérifiez que la valeur de DB2SYSTEM a été modifiée en émettant la commande
| suivante :
| db2set -all
| Cette commande affiche tous les paramètres de configuration utilisés par la

| base de données.
| 5. Dans le répertoire répertoire_instance/sqllib, localisez le fichier
| db2nodes.cfg. Le fichier contient une entrée qui affiche le nom d'hôte
| précédent, par exemple :
| 0 tsmmon TSMMON 0
| a. Mettez à jour l'entrée avec le nouveau nom d'hôte. Cette entrée est similaire
| à l'entrée suivante :
| 0 tsmnew nouveau_nom_d_hôte 0
| b. Enregistrez et fermez le fichier changé.
Linux
|
| Mise à jour de l'option tcpserveraddress
| Pour s'assurer que tous les clients et serveurs dans le système peuvent accéder au
| serveur version 6.3.4 or ou ultérieure, vous devez mettre à jour l'option du client
| tcpserveraddress.
| Définissez l'option tcpserveraddress pour tous les clientsTivoli Storage Manager

| qui accèdent au serveur migré. Définissez l'option pour tous les autres serveurs qui
| communiquent avec le serveur migré.
| Pour plus de détails, voirGuide d'installation et d'utilisation du client de

| sauvegarde-archivage.
|
| Configuration de l'adresse IP du serveur
| Si vous prévoyez d'utiliser les communications de serveur à serveur, assurez-vous
| que les autres utilisateurs du système peuvent communiquer avec le serveur V6.3.4
| or ou ultérieure. Mettez à jour l'adresse IP de haut niveau du serveur V 6.3.4 or ou
| ultérieure puis définissez par conséquent les adresses IP d'autres serveurs du
| système .
| Pour mettre à jour les adresses IP pour les communications de serveur à serveur,
| utilisez les commandes d'administration Tivoli Storage Manager :
| 1. Mettez à jour l'adresse IP du serveur V6.3.4 or ou ultérieure à l'aide de la
| commande SET SERVERHLADDRESS. Par exemple, pour définir l'adresse IP vers
| 9.230.99.66, exécutez la commande suivante :
| set serverhladdress 9.230.99.66
| Pour plus d'informations sur la mise à niveau d'une adresse IP, voit la
| commande SET SERVERHLADDRESS dans la Guide de référence d'administration.
| 2. Pour chaque serveur Tivoli Storage Manager qui communique avec le serveur
| V6.3.4 or ou ultérieure, mettez à jour le paramètre HLAddress en exécutant la
| commande UPDATE SERVER. Par exemple, pour définir l'adresse IP du serveu
| vers 9.230.99.66, exécutez la commande suivante :
| update server server2 hladdress=9.230.99.66
| Pour plus d'informations sur la mise à niveau d'un paramètre HLAddress, voir
| la commande UPDATE SERVER dans la Guide de référence d'administration.
| 3. Si vous partagez les bibliothèques, procédez comme suit :
| a. Vérifiez que le serveur V 6.3.4 or ou ultérieure fonctionne comme il se doit.
| Pour plus d'informations, voir «Vérification des résultats de la migration», à
| la page 464.
| Dans les trois sous-étapes suivantes, vous êtes demandé de définir le

| serveur V6.3.4 or ou ultérieure pour le serveur de gestionnaire de
| bibliothèque puis supprimez la définition du serveur V5. Par conséquent,
| vous ne pouvez pas revenir au système V5.
| b. Sur le serveur client de bibliothèque, définissez le serveur V6.3.4 or ou
| ultérieure pour le serveur client de bibliothèque. Par exemple, pour définir
| un serveur avec une adresse IP de 9.230.99.66 une adresse de bas niveau de
| 1500, exécutez la commande suivante :
| define server new_server_name serverpass=new_server_pass
| hla=9.230.99.66_address lla=1500
| dans laquelle new_server_name indique le nom du serveur V6.3.4 or ou

| ultérieure.
Linux
| Pour plus d'informations sur la définition d'un serveur, voir la commande

| DEFINE SERVER dans la Guide de référence d'administration.
| c. Sur le serveur client de bibliothèque, mettez à jour la bibliothèque partagée
| à l'aide de la commande UPDATE LIBRARY :
| update library library_name primarylibmanager=new_server_name
| dans laquelle library_name indique le nom de la bibliothèque partagée et

| new_server_name indique le nom du serveur V6.3.4 or ou ultérieure.
| Pour plus d'informations sur la mise à jour d'une bibliothèque partagée,
| voir la commande UPDATE LIBRARY dans la Guide de référence d'administration.
| d. Sur le serveur client de bibliothèque, supprimez la définition précédente du
| serveur de gestionnaire de bibliothèque à l'aide de la commande DELETE
| SERVER :
| delete server v5_server_name
| dans laquelle v5_server_name indique le nom du serveur V5 Tivoli Storage

| Manager.
| Pour plus d'informations sur la suppression d'un serveur de gestionnaire de
| bibliothèque, voir la commande DELETE SERVER dans la Guide de référence
| d'administration.
| e. Sur le serveur client de bibliothèque, définissez le mot de passe pour la
| communication entre serveurs à l'aide de la commande SET SERVERPASSWORD
| :
| set serverpassword lc_password
| dans laquelle lc_password indique un mot de passe pour le serveur client de

| bibliothèque.
| Pour plus d'informations sur la configuration d'un mot de passe pour les
| communications de serveur à serveur, voir la commande SET
| SERVERPASSWORD dans la Guide de référence d'administration.
| f. Sur le serveur client de bibliothèque, réinitialisez la clé de vérification du
| serveur à l'aide de la commande UPDATE SERVER :
| update server * forcesync=yes
| Pour plus d'informations sur la réinitialisation d'une clé de vérification d'un
| serveur, voir la commande UPDATE SERVER dans la Guide de référence
| d'administration.
| g. Facultatif : Sur le serveur client de bibliothèque, vérifiez celui-ci peut
| communiquer avec le serveur de gestionnaire de bibliothèque à l'aide de la
| commande AUDIT LIBRARY :
| audit library library_name checklabel=barcode
| dans laquelle library_name indique le nom de la bibliothèque partagée.

| Pour plus d'informatons sur la vérification des communications entre un
| serveur client de bibliothèque et un serveur de gestionnaire de bibliothèque,
| voir la commande AUDIT LIBRARY dans la Guide de référence d'administration.
| 4. Si vous prévoyez d'utiliser le transfert de données hors réseau local, configurez
| l'agent de stockage pour vous assurer qu'il peut commniquer avec le serveur
| V6.3.4 or ou ultérieure. Utilisez la commande DSMSTA SETSTORAGESERVER. Par
| exemple, exécutez la commande suivante :
| dsmsta setstorageserver myname=storagnt mypassword=fun4me
| myhladdress=agent.example.com servername=new_server_name
| serverpassword=new_server_password
| hladdress=high_level_address lladdress=low_level_address
Linux
| Dans cet exemple, les variables suivantes sont utilisées :

| v new_server_name indique le nom du serveur V6.3.4 or ou ultérieure.
| v new_server_password indique le mot de passe pour le serveur V6.3.4 or ou
| ultérieure.
| v high_level_address indique l'adresse de haut niveau du serveur V6.3.4 or ou
| ultérieure.
| v low_level_address indique l'adresse de haut niveau du serveur 6.3.4 or ou
| ultérieure.
| Pour plus d'informations sur la configuration d'un agent de stockage afin de
| pouvoir communiquer avec un serveur, voir la commande DSMSTA
| SETSTORAGESERVER dans la Guide d'utilisation de l'agent de stockage.
|
| Migration des données d'une bande magnétique vers des unités de
| DISQUE ou de FICHIER
| Après la migration entre serveurs, vous pouvez déplacer les données d'une unité
| de bande vers une unité de DISQUE ou de FICHIER. dANS Dans ce cas, vous avez
| la possibilité de fournir un accès aux données plus rapide.
| Pour déplacer les données d'une bande magnétique vers une unité de DISQUE ou
| de FICHIER, procédez comme suit :
| 1. Si vous déplacez les données vers une unité de FICHIER, définissez une classe
| d'unités de FICHIER à l'aide de la commande d'administration Tivoli Storage
| Manager DEFINE DEVCLASS. Par exemple, pour définir une classe d'unités
| nommée FILECLASS avec un type d'unité de FICHIER et une capacité maximale
| de 50 MB, exécutez la commande suivante :
| définissez la classe de fichier devclass devtype=file maxcapacity=50m
| Pour plus d'informations sur la définition d'une classe d'unités de FICHIER,

| voir la commande DEFINE DEVCLASS dans Guide de référence d'administration.
| 2. Définissez un pool de stockage à l'aide de la commande administrative Tivoli
| Storage ManagerDEFINE STGPOOL.
| v Par exemple, si vous déplacez les données vers une unité de DISQUE, pour
| définir un pool de stockage principal nommé BACKUPPOOL, exécutez la
| définissez le cache-disque stgpool backuppool = oui nextstgpool=prog2
| Dans cet exemple, la mise en cache est activée et PROG2 est spécifiée en tant
| que pool de stockage principal vers lequel migrent les fichiers.
| v Par exemple, si vous déplacez les données vers une unité FILE, pour définir
| un pool de stockage principal dénommé FILEPOOL, exécutez la commande
| suivante :
| définissez la classe de fichiers du pool de fichiers stgpool nextstgpool=prog3
| Dans cet exemple, PROG3 est spécifiée en tant que pool de stockage vers
| lequel migrent les fichiers.
| Pour plus d'informations sur la définition d'un pool de stockage, voir la
| commande DEFINE STGPOOL dans la Guide de référence d'administration.
| 3. Définissez un volume à l'aide de la commande administrative DEFINE VOLUME.
| Par exemple, pour définir un volume de 4 MB nommé /home/tsminst1/
| jamesvol.dsm dans un pool de stockage dénommé BACKUPPOOL, exécutez la
| commande :
Linux
| définissez le pool de sauvegarde du volume /home/tsminst1/jamesvol.dsm formatsize=4
| For more information about defining a volume, see the DEFINE VOLUME
| command in the Guide de référence d'administration.
| 4. Pour déplacer les données vers un périphérique disque, utilisez les commandes
| d'administrationTivoli Storage Manager MOVE DATA ou MOVE NODEDATA en
| fonction de l'emplacement dans lequel sont enregistrées les données et la
| manière dont vous voulez les déplacer. Par exemple, pour déplacer les fichiers
| vers un volume de pool de stockage nomméSTGVOL.1 vers le pool de stockage
| BACKUPPOOL, exécutez la commande suivante :
| move data stgvol.1 stgpool=backuppool
| Pour plus d'informations sur le déplacement des données, voir les commandes
| MOVE DATA et MOVE NODEDATA dans la Guide de référence d'administration.
| 5. Pour déplacer les données d'une bande passante vers une unité de FiCHIER,
| utilisez les commandes d'administration Tivoli Storage Manager UPDATE
| STGPOOL et MIGRATE STGPOOL. Par exemple les données vers un pool de stockage
| nommé LTOPOOL vers le pool de stockageFILEPOOL, exécutez les commandes
| suivantes :
| update stgpool ltopool nextstgpool=filepool highmig=100
| migrate stgpool ltopool lowmig=0
| Pour plus d'informations sur le déplacement des données, voir les commandes
| UPDATE STGPOOL et MIGRATE STGPOOL dans la Guide de référence d'administration.
| Par ailleurs, vous pouvez utiliser les commandes MOVE DATA ou MOVE NODEDATA
| pour déplacer les données vers une unité de FICHIER, en fonction de la
| manière dont les données sont enregistrées et celle par laquelle vous souhaitez
| les déplacer.
|
| Restauration de groupes de sauvegarde
| Si vous aviez copié des groupes de sauvegarde vers un emplacement temporaire
| avant la migration, il est possible que vous souhaitiez déplacer les groupes de
| sauvegarde vers un autre emplacement après la migration. Vous pouvez supprimer
| les entrées existantes dans la base de données du serveur et puis recréer les
| groupes de sauvegarde dans leur nouvel emplacement.
| Pour restaurer des groupes de sauvegarde à un nouvel emplacement, procédez

| comme suit :
| 1. Supprimez les entrées de groupe de sauvegarde depuis la base de données du
| serveur à l'aide la commande d'administration Tivoli Storage Manager DELETE
| BACKUPSET. Par exemple, pour supprimer un groupe de sauvegarde nommé
| PERS_DATA.3099, émettez la commande suivante :
| delete backupset pers_data.3099
| Pour plus d'informations sur la suppression d'entrées de groupes de
| sauvegarde, voir la commande DELETE BACKUPSET dans Guide de référence
| d'administration.
| 2. Recréez un groupe de sauvegarde en émettant la commande
| d'administrationthe Tivoli Storage Manager DEFINE BACKUPSET. Par exemple,
| pour définir le groupe de sauvegarde PERS_DATA backup appartenant au
| noeud JANE, émettez la commande suivante :
| define backupset jane pers_data devclass=agadm
| volumes=vol1,vol2 retention=50 description="sector 7 base image"
Linux
| Dans cet exemple, les volumes VOL001 et VOL002 contiennent les données du
| groupe de sauvegarde. Le groupe de sauvegarde est conservé sur le serveur
| pendant 50 jours. Les volumes doivent être lus par une unité affectée à la classe
| d'unités AGADM. Une description, sector 7 base image, est incluse.
| Pour plus d'informations sur la récréation de groupes de sauvegarde, voir la
| commandeDEFINE BACKUPSET dans Guide de référence d'administration.
|
| Mise à jour de l'automatisation
| Une fois la migration des données effectuée, il pourra être nécessaire de modifier
| les plannings d'administration définis dans la version des changements apportés à
| la syntaxe de commande. Implémentez et vérifiez les changements apportés à
| l'automatisation et aux scripts qui nécessitent d'être modifiés dans le processus de
| planification.
| Important : Assurez-vous que l'automatisation inclut une sauvegarde de la base de

| données. Sauvegardez la base de données au moins une fois par jour.
|
| Début des opérations et surveillance des serveurs
| Lorsque vous commencez à exécuter le serveur V Tivoli Storage Manager 6.3.4 or
| ou ultérieure, surveillez l'espace utilisé par celui-ci Assurez-vous que la quantité
| d'espace est appropriée.
| Pour surveiller le serveur version 6.3.4 or ou ultérieure et effectuer tous les

| ajustements nécessaires, procédez comme suit :
| 1. Surveillez le journal actif afin de vous assurer que la taille est suffisante pour la
| charge de travail gérée par l'instance de serveur.
| Lorsque la charge de travail du serveur est proche du niveau généralement
| attendu, et que l'espace utilisé par le journal actif représente entre 80 et 90 % de
| l'espace disponible pour le répertoire du journal actif. Il se peut que vous soyez
| obliger d'augmenter l'espace. La nécessité d'augmenter l'espace dépend des
| types de transactions dans la charge de travail du serveur. Les caractéristiques
| de transaction affectent le mode d'utilisation de l'espace dédié au journal actif.
| Les caractéristiques de transaction suivantes peuvent affecter l'utilisation de
| l'espace dans le journal actif :
| v Nombre et taille des fichiers dans les opérations de sauvegarde
| – Les clients, tels que les serveurs de fichiers qui sauvegardent un grand
| nombre de petits fichiers peuvent générer un grand nombre de
| transactions qui s'achèvent rapidement. Ces transactions peuvent utiliser
| une grande quantité d'espace dans le journal actif, mais pour une courte
| période.
| – Les clients tels qu'un serveur de messagerie ou un serveur de base de
| données qui sauvegardent des blocs importants de données dans un petit
| nombre de transactions peuvent générer de petits nombres de transactions
| dont l'exécution est longue. Il se peut que les transactions utilisent une
| petite quantité d'espace dans le journal actif mais pendant une longue
| période.
| v Types de connexion réseau
| – Les opérations de sauvegarde qui sont effectuées sur des connexions
| réseau rapides accélèrent l'exécution des transactions. Les transactions
| utilisent l'espace du journal actif pendant une période de temps plus
| courte.
Linux
| – Les opérations de sauvegarde qui sont effectuées sur des connexions

| relativement plus lentes génèrent des transactions dont l'exécution est plus
| longue. Les transactions utilisent l'espace du journal actif pendant une
| période de temps plus longue.
| Si le serveur gère des transactions ayant des caractéristiques très diverses,
| l'espace utilisé pour le journal actif peut croître ou décroître fortement au cours
| du temps. Pour un tel serveur, il peut être nécessaire de s'assurer qu'un
| pourcentage généralement moins important de l'espace du journal actif est
| utilisé. L'espace supplémentaire permet au journal actif de s'accroître pour les
| transactions dont l'exécution est longue.
| 2. Surveillez le journal d'archivage pour vous assurer qu'il y a toujours de l'espace
| disponible.
| A faire : Si le journal d'archivage et le journal de reprise d'archivage

| deviennent saturés, il se peut que le journal actif le devienne également, ce qui
| peut provoquer l'arrêt du serveur. L'objectif est de créer suffisamment d'espace
| disponiblepour le journal d'archivage de sorte qu'il n'utilise jamais toute
| l'espace disponible.
| Les conditions suivantes peuvent être observées :
| a. dans un premier temps, le journal d'archivage croît rapidement lorsqu'une
| opération classique de sauvegarde avec des clients se produit;
| b. des sauvegardes de base de données sont effectuées régulièrement, en mode
| planifié ou manuel;
| c. Après des sauvegardes complètes de la base de données, des élagages sont
| effectués automatiquement au niveau du journal. L'espace utilisé par le
| journal d'archivage décroît lorsque l'élagage se produit.
| d. Les opérations des clients se poursuivent normalement et le journal
| d'archivage s'accroît également.
| e. Des sauvegardes de base de données sont effectuées régulièrement et des
| suppressions ont lieu dans le journal chaque fois qu'une sauvegarde de base
| de données intégrale est exécutée.
| Dans ces conditions, le journal d'archivage s'accroît dans un premier temps,
| puis décroît pour, éventuellement, croître à nouveau. Pendant une période, au
| fur et à mesure que les opérations normales se poursuivent, la quantité
| d'espace utilisée par le journal d'archivage devrait arriver à se stabiliser.
| Si le journal d'archivage continue à croître, effectuez l'une des actions
| ci-dessous ou les deux :
| v ajoutez de l'espace au journal d'archivage. Il se peut qu'un transfert du
| journal d'archivage vers un système de fichiers différent soit nécessaire.
| Pour plus d'informations sur le transfert du journal d'archivage, voir le
| document Guide d'administration.
| v Augmentez la fréquence des sauvegardes intégrales de la base de données
| afin que l'élagage du journal se produise le plus souvent.
| 3. Si vous avez difini un répertoire pour le journal de reprise d'archivage,
| déterminez si des journaux sont enregistrées dans ce répertoire pendant les
| opérations normales. Si l'espace du journal de reprise est utilisé, augmentez la
| taille du journal d'archivage. L'objectif est d'utiliser le journal de reprise
| d'archivage uniquement dans des conditions inhabituelles, et non dans des
| opérations normales.
|
|
| Chapitre 17. Identification et résolution des problèmes de la

| migration d'un serveur version 5 depuis AIX, HP-UX, ou
| Solaris
| Au cas où vous rencontre des problèmes pendant ou après la migration, des
| instructions pour le rétablissement du serveur à sa version précédente sont
| disponibles.
|
| Rétablissement de la version 5 du serveur à partir de la version 6.3.4
| or ou ultérieure
| Si vous suivez les étapes de la procédure de migration, vous pouvez retourner au
| serveur V5 à n'importe quel endroit se trouvant sur le chemin de la migration.
| Exigence : Le serveur version 5 doit être installé sur le système d'origine durant le
| processus de migration.
| Pour restaurer le serveur version 5, procédez comme suit :

| 1. Sur le système version 5, pour chaque pool de stockage à accès séquentiel sur
| bande, définissez le paramètre REUSEDELAY au nombre de jours pendant lesquels
| vous souhaitez revenir au serveur V6.3.4 or ou ultérieure, si nécessaire.
| Par exemple, si vous souhaitez être en mesure de revenir au serveur V6.3.4 or
| ou ultérieure pendant une période allant jusqu'à 30 jours après le retour à la
| version 5, définissez le paramètre REUSEDELAY à 31 jours. Emettez la commande
| d'administration suivante :
| update stgpool
| pool_stockage_accès_séquentiel reusedelay=31
| où sequential_access_storage_pool indique le nom du pool de stockage. En

| indiquant le paramètre REUSEDELAY, vous pouvez aider à prévenir la perte de
| données du client de sauvegarde-archivage.
| Pour de plus amples informations sur la configuration du paramètre
| REUSEDELAY, voir la commande UPDATE STGPOOL dansGuide de référence
| d'administration.
| 2. Pour tous les volumes de bande qui ont été utilisés par le serveur V5, indiquez
| le mode d'accèsreadwrite(lecture/écriture). Emettez la commande
| d'administration suivante :
| update volume tape_volume access=readwrite
| où tape_volume indique le nom du volume de bande.

| Pour plus d'informations sur la spécification du mode d'accès readwrite
| (lecture/écriture), voir la commande UPDATE VOLUME dans Guide de référence
| d'administration.
| 3. Pour chaque pool de stockage de copie utilisée par le serveur version 5,
| changez la valeur du paramètre RECLAIM de 100 à la valeur qui a été défini
| avant la migration. Emettez la commande d'administration suivante :
| update stgpool copy_storage_pool reclaim=reclaim_value
| où copy_storage_pool représente le nom du pool de stockage de copie et

| reclaim_value représente la valeur de réclamation utilisée avant la migration.

Linux
| Pour de plus amples informations sur la configuration du paramètre RECLAIM,

| voir la commande UPDATE STGPOOL dansGuide de référence d'administration.
| 4. Démarrez le serveur version en exécutant les commandes d'administration
| suivantes :
| ./dsmserv
|
|
| Partie 3. Migration des serveurs Tivoli Storage Manager

| version 5 s'exécutant sur des systèmes z/OS vers la version 6
| sous AIX ou Linux on System z
| Un serveur IBM Tivoli Storage Manager V5 fonctionnant sur un système z/OS
| peut être déplacé vers un serveur V6.3 ou ultérieure qui fonctionne sur AIX ou
| Linux sur System z. Pendant la migration, IBM Tivoli Storage Manager for z/OS
| Media doit être installé sur le serveur V5 pour assurer l'accès continu aux données
| enregistrées sur le système z/OS.
| La migration multiplateforme offre les avantages suivants :

| v Les données client stockées sur le système z/OS sont accessibles à partir du
| serveur Tivoli Storage Manager version 6.3 ou ultérieure via Tivoli Storage
| Manager for z/OS Media. Vous pouvez conserver le matériel de stockage
| existant qui utilise la technologie de canal Fiber Connector (FICON).
| v Le système Tivoli Storage Manager version 6.3 ou ultérieure peut être développé
| à l'aide de systèmes de stockage s'exécutant sous z/OS ou UNIX.
| Le processus de migration du serveur Tivoli Storage Manager d'un système

| d'exploitation z/OS vers AIX ou Linux on System z est semblable au processus de
| mise à niveau de Tivoli Storage Manager V5 à V6.3 ou ultérieure sur le même
| système d'exploitation. Pour la migration multiplateforme, vous devez exécuter des
| étapes supplémentaires afin de s'assurer que les données des systèmes z/OS sont
| accessibles à partir du serveur Tivoli Storage Manager V6.3 ou ultérieure.

|
| Chapitre 18. Présentation de la migration

| Avant de commencer la migration multiplateforme, consultez la feuille de route de
| la migration, les scénarios de la migration et les informations associées afin de
| pouvoir planifier le processus de migration.
|
| Feuille de route de la migration
| La feuille de route de la migration propose des liens vers les informations vous
| permettant de planifier, préparer et exécuter le processus de migration.
| Pour planifier et préparer le processus de migration, procédez comme suit :

| 1. Consultez les informations sur le produit Tivoli Storage Manager for z/OS
| Media. Pour plus d'informations, voir Tivoli Storage Manager for z/OS Media
| Installation and Configuration Guide.
| 2. Consultez les scénarios de migration suivants : Scénarios de migration d'un
| serveur d'un système z/OS vers AIX ou Linux sur System z.
| 3. Familiarisez-vous avec les principales phases du processus de migration :
| «Processus de migration», à la page 481.
| 4. Consultez les changements auxquels il faut s'attendre dans le système suite à la
| migration : «Changements opérationnels et exigences», à la page 491.
| 5. Consultez les instructions de planification de la migration : Chapitre 19,
| 6. Sélectionnez la méthode de migration à utiliser et planifiez la configuration
| requise au niveau du matériel, des logiciels et du stockage pour votre serveur
| et votre environnement.
| 7. Exécutez les étapes de préparation : Chapitre 20, «Préparation de la migration»,
| à la page 515.
| Pour migrer et configurer le système, procédez comme suit :

| 1. Suivez les instructions de migration : Chapitre 21, «Migration de la base de
| données du serveur z/OS vers le serveur version 6.3 ou ultérieure», à la page
| 533.
| 2. Configurez les unités de serveur multimédia z/OS : Chapitre 22,
| «Configuration des périphériques de serveur multimédia z/OS sur le nouveau
| serveur», à la page 539.
| 3. Exécutez le processus de migration : Chapitre 23, «Exécution des premières
|
| Scénarios de migration d'un serveur à partir d'un système z/OS vers
| AIX ou Linux sur System z
| Vous pouvez migrer le serveur à l'aide de la méthode de support, de la méthode
| de réseau ou de la méthode hybride de mise à niveau et migration.
| Grâce à la méthode de support, vous pouvez extraire les données de la base de

| données d'origine vers des supports et les charger ultérieurement dans la nouvelle
| base de données. Le graphique suivant présente la méthode de support.

Migration de serveurs version 5 s'exécutant sur des systèmes z/OS vers la version 6 sous
AIX ou Linux
Migration vers un système

V6 à l'aide de la méthode de
1. Installez le logiciel du serveur version 6.
3. Mise à niveau de Upgrade Tivoli Storage

Manager sur V5.5.6. ou ultérieure.
2. Créez les répertoires et l'ID utilisateur pour la
nouvelle instance de serveur.
4. Installation de Tivoli Storage Manager

for z/OS Media.
Définition d'un serveur pour qu'il

10. Créez et formatez la base de données. Exécutez la
commande db2icrt et l'utilitaire DSMSERV
5. corresponde à Tivoli Storage Manager for LOADFORMAT.
z/OS Media.
6. Analyse du serveur V5. Exécutez la

commande ZMSPREPARE.
11. Chargement des données extraites dans la
nouvelle base de données. Exécutez l'utilitaire
DSMSERV INSERTDB.
12. Configurez le système pour une sauvegarde de

base de données.
Sauvegarde de la base de données V5
7. sur une bande magnétique.
Configuration des unités du serveur multimédia

Préparez la base de données versions
13. z/OS.
8. V5. Exécutez l'utilitaire DSMUPGRD
PREPARE.
14. Recréation des pools de stockage sur disque.

9. Extrayez la base de données version 5 vers
des supports externes. Exécutez l'utilitaire
DSMUPGRD EXTRACTDB.
15. Exécution
migration.
des étapes postérieures à la
Tivoli Storage Tivoli Storage

Manager pour Manager pour
serveur V5 z/OS serveur V6 AIX
ou Linux
Figure 13. Migration d'un serveur à l'aide de la méthode de support
AIX ou Linux
Grâce à la méthode de réseau, vous pouvez extraire simultanément les données de

la base de données d'origine et les charger dans la nouvelle base de données. Le
graphique suivant présente la méthode de réseau.

AIX ou Linux
Migration vers un système V6 à

l'aide de la méthode de réseau
1. Installez le logiciel du serveur version 6.
3. Mise à niveau de Upgrade Tivoli

Storage Manager sur V5.5.6. ou
ultérieure. 2. Créez les répertoires et l'ID utilisateur pour la
nouvelle instance de serveur.
4. Installation de Tivoli Storage Manager

for z/OS Media.
9.Créez et formatez la base de données. Exécutez la

commande db2icrt et l'utilitaire DSMSERV
LOADFORMAT.
5. Définition d'un serveur pour qu'il
corresponde à Tivoli Storage Manager for
z/OS Media.
6. Analyse du serveur V5. Exécutez la

commande ZMSPREPARE.
Vérifiez que le serveur peut contenir la base de
10. données.\nExécutez l'utilitaire DSMSERV
INSERTDB.
Configurez le système pour une sauvegarde de

12. base de données.
7. Sauvegarde de la base de données V5

sur une bande magnétique.
13. Configuration des unités du serveur multimédia
z/OS.
8. Préparez la base de données versions

V5. Exécutez l'utilitaire DSMUPGRD
PREPARE.
14. Recréation des pools de stockage sur disque.

Extraction et déplacement de la base
11. de données. Exécutez l'utilitaire
DSMUPGRD EXTRACTDB.
15. Exécution des étapes postérieures à la
migration.
Tivoli Storage Tivoli Storage

Manager pour Manager pour
serveur V5 z/O serveur V6 AIX
ou Linux
Figure 14. Migration du serveur à l'aide de la méthode de réseau
AIX ou Linux
Les utilisateurs expérimentés peuvent utiliser une troisième option, la méthode

hybride de mise à niveau et migration, pour migrer le serveur. Cette méthode
utilise une combinaison d'opérations d'exportation et d'importation avec les
méthodes de mise à niveau version 6 classiques. Pour plus d'informations sur la
méthode hybride de mise à niveau et migration et pour obtenir une comparaison
des trois options, voir «Comparaison des méthodes de migration de la base de
Après la migration multiplateforme, vous disposez d'une plus grande flexibilité en

termes de stockage des données. Vous pouvez sélectionner l'une des principales
options suivantes :
v Vous pouvez continuer à utiliser le système z/OS pour le stockage des données.
Dans ce cas, les données sont stockées sur des volumes de bande et le contenu
est accessible via les unités de stockage FICON associées.
v Vous pouvez progressivement transférer les données en dehors du système de
stockage z/OS et utiliser le système version 6.3 ou ultérieure system sous AIX
ou Linux sur System z pour un stockage des données.
Concepts associés:
«Présentation du processus de migration», à la page 482
«Tâches principales du processus de migration», à la page 484
«Comparaison des méthodes de migration de la base de données», à la page 490
Présentation de Tivoli Storage Manager for z/OS Media

Grâce à IBM Tivoli Storage Manager for z/OS Media, vous pouvez utiliser un
système Tivoli Storage Manager version 6.3 ou ultérieure pour accéder aux
données stockées sur un système z/OS.
Le serveur Tivoli Storage Manager for z/OS Media permet au serveur Tivoli
Storage Manager d'accéder au support de stockage séquentiel du système z/OS. Le
serveur multimédia z/OS gère le stockage sur bande magnétique utilisé par le
serveur Tivoli Storage Manager version 5 exécuté sur le système z/OS.
Seuls les serveurs Tivoli Storage Manager version 6.3 ou ultérieure exécutés sur les
systèmes d'exploitation AIX ou Linux sur System z peuvent utiliser Tivoli Storage
Manager for z/OS Media.
Pour plus d'informations sur Tivoli Storage Manager for z/OS Media, voir Tivoli
Storage Manager for z/OS Media Installation and Configuration Guide.
Concepts associés:
«Présentation du processus de migration», à la page 482
Processus de migration
La migration de Tivoli Storage Manager version 5 exécuté sous z/OS vers la
version 6.3 ou ultérieure sous AIX ou Linux sur System z requiert une planification
considérable. Avant de commencer, familiarisez-vous avec la présentation de la
migration, les principales tâches du processus de migration et les utilitaires utilisés
pour la migration.

AIX ou Linux
Présentation du processus de migration

Avant de commencer le processus de migration, prenez connaissance des
restrictions qui s'appliquent et consultez les descriptions des opérations système
avant et après la migration.
Les restrictions suivantes s'appliquent à la migration :

v Le serveur version 5 exécuté sous z/OS peut être uniquement migré sur un
système AIX ou Linux sur System z.
v Les données client stockées dans les pools de stockage de serveur sur bande
magnétique peuvent rester sur le système z/OS existant, mais les informations
sur la base de données doivent être migrées. Les données client stockées sur des
disques à accès aléatoire ou dans des pools de stockage FILE existants doivent
être transférées sur une bande magnétique avant le début de la migration.
Avant la migration, le serveur Tivoli Storage Manager version 5 utilise les
périphériques de stockage FICON associés pour accéder au support de stockage
z/OS.
Le graphique suivant présente les opérations à exécuter avant la migration.
zSeries
z/OS LPAR
Serveur Tivoli
Storage
Manager
LAN
pièce jointe
z/OS FICON
client de sauvegarde-
archivage Tivoli
Storage Manager
support de stockage z/OS
Figure 15. Opérations à exécuter avant la migration
Une fois que vous avez migré votre système vers un serveur 6.3 ou ultérieure sous
AIX, le serveur Tivoli Storage Manager version 6.3 ou ultérieure utilise le Tivoli
Storage Manager for z/OS Media pour accéder au support de stockage z/OS.
Le graphique suivant illustre le système après la migration vers un serveur 6.3 ou

ultérieure sous AIX.
AIX ou Linux
connexion à grande
vitesse
LAN pSeries AIX zSeries z/OS
Serveur Tivoli
Storage
Manager
Serveur
multimédia
DB2
pièce jointe
z/OS FICON
client de
sauvegarde-
archivage Tivoli
Storage Manager
Figure 16. Opérations après la migration vers un serveur version 6.3 ou ultérieure exécuté sur AIX
Une fois que vous avez migré votre système vers un serveur 6.3 ou ultérieure sous
Linux sur System z, le serveur Tivoli Storage Manager version 6.3 ou ultérieure
utilise le Tivoli Storage Manager for z/OS Media pour accéder au support de
stockage z/OS.
Le graphique suivant illustre le système après la migration vers un serveur version

6.3 ou ultérieure sous Linux sur System z.

AIX ou Linux
zSeries
Hipersocket
LAN Linux sur System z LPAR z/OS LPAR
Serveur Tivoli
Storage
Manager
Serveur
multimédia
DB2
pièce jointe
z/OS FICON
client de sauvegarde-
archivage Tivoli
Storage Manager
Figure 17. Opérations après la migration vers un serveur version 6.3 ou ultérieure exécuté sous Linux sur System z
Concepts associés:
«Tâches principales du processus de migration»
«Migration d'unité», à la page 486
Tâches principales du processus de migration

Le processus de migration comprend l'installation de Tivoli Storage Manager for
z/OS Media sur le serveur source version 5 et l'installation de Tivoli Storage
Manager version 6.3 ou ultérieure sur le serveur cible. Les autres tâches
comprennent la sauvegarde de données, puis la migration des données du serveur
source version 5 vers le serveur cible version 6.3 ou ultérieure.
1. Préparez le système pour la migration.
a. Sur le serveur cible, installez Tivoli Storage Manager version 6.3 ou
ultérieure et configurez une instance de base de données.
b. Sur le serveur source, mettez à niveau Tivoli Storage Manager sur la version
5.5.6 ou une version ultérieure.
c. Sur le serveur source, installez Tivoli Storage Manager for z/OS Media.
d. Sur le serveur source, utilisez la commande ZMSPREPARE pour analyser le
serveur et générer un rapport. Les informations contenues dans le rapport
vous permettent d'identifier les étapes à exécuter avant la migration.
e. Sauvegardez, transférez ou supprimez les données stockées sur les pools de
stockage DISK ou FILE. Empêchez les nouvelles données de se stocker sur
les pools de stockage DISK ou FILE.
AIX ou Linux
f. Sauvegardez la base de données de serveur source sur une bande

magnétique.
Important : Vérifiez qu'une sauvegarde complète de la base de données est

disponible sur site. Une sauvegarde est essentielle si le processus de
migration est interrompu ou supprimé. La sauvegarde doit être stockée sur
une bande magnétique car les volumes FILE ne peuvent pas être utilisés au
cours du processus de migration.
2. Transférez les données de la base de données source vers la base de données
cible.
3. Exécutez la configuration d'unité et les tâches associées.
a. Ajoutez des unités au serveur cible comme l'exige le serveur Tivoli Storage
Manager for z/OS Media.
b. Définissez de nouveaux pools de stockage DISK et FILE sur le serveur cible.
Restaurez des données des sauvegardes des pools de stockage DISK et FILE
qui se trouvaient sur le système z/OS.
c. Si des volumes z/OS DISK ou FILE ont été marqués comme détruits,
supprimez ces volumes.
Utilitaires et commandes de migration des données

Tivoli Storage Manager propose des utilitaires et une commande vous permettant
de transférer des données d'un système version 5 exécuté sous z/OS vers le
système Tivoli Storage Manager version 6.3 ou ultérieure exécuté sous AIX ou
Linux sur System z.
Utilisez les utilitaires suivants pour la migration de données :

DSMUPGRD EXTRACTDB
L'utilitaire DSMUPGRD EXTRACTDB extrait les données de la base de données
de serveur.
DSMSERV INSERTDB
L'utilitaire DSMSERV INSERTDB transfère les données extraites vers une
nouvelle base de données.
DSMSERV LOADFORMAT
L'utilitaire DSMSERV LOADFORMAT met en forme une base de données vide en
vue d'y insérer les données extraites.
DSMUPGRD PREPAREDB
L'utilitaire DSMUPGRD PREPAREDB prépare la base de données pour la
migration en vérifiant que toutes les tâches de prémigration sont exécutées.
Utilisez la commande suivante pour la migration de données :

ZMSPREPARE
La commande ZMSPREPARE analyse le serveur version 5 et fournit des
données vous permettant d'identifier les étapes à exécuter avant la
migration.
De nombreux utilitaires et de nombreuses commandes utilisés pour le mise à

niveau de serveur sont également utilisés pour la migration de serveur. Pour plus
d'informations, voir Annexe A, «Utilitaires, scripts et commandes pour la mise à
niveau de serveur et la migration», à la page 561.

AIX ou Linux
«ZMSPREPARE (Préparez un serveur sur un système z/OS en vue d'une
migration)», à la page 579
DSMUPGRD EXTRACTDB
DSMUPGRD PREPAREDB (préparation d'une base de données pour la mise à
niveau)
Migration d'unité
Vous devez migrer les unités pour vous assurer que le serveur Tivoli Storage
Manager version 6.3 ou ultérieure exécuté sous AIX ou Linux on System z peut
accéder aux fichiers stockés sur un système z/OS. Une présentation de la
migration d'unités est fournie.
Le processus de migration d'unité varie en fonction du type d'unité et du type de

données stockées :
v Migrez les unités de bande à l'aide des utilitaires.
v Migrez les données stockées sur les disques et les données écrites dans les
classes d'unités FILE en exécutant des étapes manuelles. Les étapes manuelles
comprennent la sauvegarde des données et la suppression des volumes et des
pools désormais inutiles.
Sauvegarde des pools de stockage principaux sur un disque
Vérifiez que vous disposez de volumes de bande disponibles pour sauvegarder les
données stockées à l'aide des unités DISK ou FILE :
v Les volumes de bande doivent au moins être disponibles pour sauvegarder le
pool de stockage principal.
v Pour optimiser le processus, créez une seconde sauvegarde sur site du pool de
stockage principal. En créant un pool de stockage de sauvegarde hors site et un
autre sur site, vous respectez les exigences de reprise après incident du stockage
hors site. Dans le même temps, des volumes du second pool sont disponibles
sur site pour restaurer les données immédiatement après la migration..
Une fois les volumes de pool de stockage principal sur disque sauvegardés,
marquez-les comme étant détruits. Cette étape vous permet d'implémenter les
procédures de sauvegarde et de restauration qui réduisent le temps de migration.
De plus, il est plus facile de revenir au système version 5 si nécessaire.
Sauvegarde des pools de stockage non principaux sur un disque
Pour les pools de stockage de copie et les pools de stockage de données actives
écrits dans les classes d'unités FILE, vous devez sauvegarder ou réaffecter les
données dans les nouveaux pools de stockage. Vous devez ensuite supprimer les
données des disques.
Pour les données de pool de non stockage écrites dans les classes d'unités FILE,
vous devez supprimer les types de données suivants : sauvegardes de base de
données, images instantanées de la base de données, vidages de mémoire de base
de données, fichiers de plan de reprise, volumes d'exportation et groupes de
sauvegarde. Vous ne devez pas supprimer les volumes de pool de stockage à accès
séquentiel.
AIX ou Linux
Conversion des classes d'unités z/OS
Au cours du processus de migration, l'utilitaire DSMSERV INSERTDB convertit les

classes d'unités z/OS en classes d'unités AIX ou Linux sur System z. La conversion
des classes d'unités s'effectue de la manière suivante :
v La classe d'unités DISK est mappée sur la classe d'unités DISK prédéfinie pour
le serveur AIX ou Linux on System z.
v Toutes les classes d'unités de type SERVER sont converties dans l'équivalent AIX
ou Linux sur System z.
v Les attributs de classes d'unités FILE spécifiques au système d'exploitation z/OS
sont supprimés au cours de la migration, car le dernier serveur multimédia
z/OS installé ne prend pas en charge le type d'unité FILE précédemment utilisé.
Les nouvelles classes d'unités FILE doivent plutôt être définies après la
migration afin d'utiliser un stockage FILE séquentiel via le serveur multimédia
z/OS.
v La bande magnétique et les classes d'unités FILE sont configurées pour utiliser
le serveur multimédia z/OS de la manière suivante :
– Les classes d'unités de bande non configurées pour un accès hors réseau local
sont mises à jour pour utiliser le serveur multimédia z/OS. L'utilitaire
DSMSERV INSERTDB définit une nouvelle bibliothèque et un nouveau chemin
pour chaque classe d'unités et configure les bibliothèques pour accéder au
– Les classes d'unités de bande configurées pour un accès hors réseau local ne
restent pas configurées pour un accès hors réseau local. Ces classes d'unités de
bande possèdent toutes des bibliothèques partagées ou externe qui leur sont
associées. Les bibliothèques sont supprimées et remplacées par des
bibliothèques et des chemins assurant un accès via le serveur multimédia
z/OS. Après la migration, les classes d'unités de bande configurées pour un
accès hors réseau local utilisent le serveur multimédia z/OS pour
communiquer via un réseau local. L'agent de stockage Tivoli Storage Manager
facilite cette communication.
– Les attributs de classes d'unités communs aux plateformes z/OS, AIX et
Linux on System z sont conservés.
– Les attributs de classes d'unités utilisés uniquement pour z/OS sont
transformés en nouveaux attributs de classes d'unités utilisés par le serveur
multimédia z/OS.
– Les attributs de classes d'unités utilisés sur les systèmes AIX et Linux sur
System z, mais qui n'existaient pas sur le système z/OS, sont paramétrés
comme étant des valeurs par défaut utilisables.
Rôle de Tivoli Storage Manager for z/OS Media
Après la migration, Tivoli Storage Manager for z/OS Media assure la gestion des
données de bande stockées sur le serveur version 5 exécuté sous z/OS. C'est
pourquoi vous devez installer Tivoli Storage Manager for z/OS Media sur le
serveur version 5 au cours de la phase de préparation. De plus, vous devez utiliser
la commande DEFINE SERVER pour définir un nouveau serveur sur le serveur
version 5 afin qu'il corresponde au serveur multimédia z/OS. Le nouveau serveur
est utilisé au cours de la phase de migration pour accéder au support de mise à
niveau. Une fois la migration terminée, le serveur permet d'accéder aux données
de client stockées sur la bande magnétique.

AIX ou Linux
Le graphique suivant explique comment Tivoli Storage Manager utilise le serveur

multimédia z/OS pour accéder au support de stockage z/OS.
AIX ou Linux sur z/OS

System z
Serveur Tivoli
Storage Manager Serveur
multimédia
DB2
pièce jointe
pièce jointe Fibre FICON
Channel Protocol
support de stockage Local support de stockage DE

Fibre Channel Protocol serveur multimédia z/OS
Figure 18. Rôle du serveur multimédia z/OS dans le système migré
Statut des volumes de bande
L'utilitaire DSMSERV INSERTDB change le statut de tous les volumes de bande

FILLING en FULL. Ce changement est nécessaire car le serveur multimédia z/OS
ne peut pas s'ajouter aux volumes de bande initialement écrits par Tivoli Storage
Manager exécuté sous z/OS.
Groupes de sauvegarde
Consultez les informations sur les groupes de sauvegarde pour savoir quels
groupes de sauvegarde définis sur le serveur version 5 avant la migration sont
utilisables après la migration.
Les groupes de sauvegarde utilisant des unités de bande sont automatiquement

migrés
Les groupes de sauvegarde utilisant les classes d'unités FILE ne sont pas migrés.
Les groupes de sauvegarde utilisant les classes d'unités FILE ne peuvent être
générés, transférés ou ouverts après la migration.
Au cours du processus de migration, vous pouvez utiliser la commande

ZMSPREPARE pour générer une liste de groupes de sauvegarde utilisant les classes
AIX ou Linux
d'unités FILE. Vous pouvez ensuite utiliser la commande DELETE BACKUPSET pour
supprimer chaque groupe de sauvegarde utilisant une classe d'unités FILE.
Impacts de la migration sur les agents de stockage

Après la migration du système, un agent de stockage installé sur un client Tivoli
Storage Manager peut envoyer des données aux unités de stockage associées à un
serveur multimédia z/OS ou recevoir des données de ces unités.
Le transfert de données hors réseau local de et vers les unités de stockage z/OS est
impossible. L'agent de stockage installé sur le client Tivoli Storage Manager
communique plutôt avec le serveur multimédia z/OS via un réseau local. Les
données client peuvent être lues ou écrites à l'aide du stockage sur fichier ou sur
bande serveur multimédia z/OS sans que les données ne passent par le serveur
Tivoli Storage Manager. Le graphique suivant présente les canaux de
communication.
client de
sauvegarde-
archivage Tivoli serveur
Storage Manager multimédia
DB2 \nz/OS
Agent de
stockage
Serveur Tivoli
Storage Manager
Client data
Métadonnées
FICON
LAN
Client data
Bandothèque
unités de bande z/OS
SAN FICON associées au
canal
Figure 19. Agent de stockage communiquant avec le serveur multimédia z/OS via un réseau local
Exigence : Pour se connecter à un serveur V6.3 ou ultérieure dans un système qui

utilise serveur multimédia z/OS, les agents de stockage doivent être sur V6.3 ou
ultérieure. Si vous disposez d'agents de stockage sur d'anciennes versions,
mettez-les à niveau vers V 6.3 ou ultérieure dans le cadre du processus de
migration.
Pour plus d'informations sur le transfert de données dans un environnement

serveur multimédia z/OS, voir Guide d'utilisation de l'agent de stockage.

AIX ou Linux
Protection des données client et du serveur au cours du

processus
Pour protéger les données client et le serveur, vérifiez que vous avez sauvegardé
les pools de stockage et la base de données de serveur avant de commencer le
processus de migration. Ces fichiers vous seront utiles pour revenir à la version
Tivoli Storage Manager antérieure.
Les instructions de migration entre serveurs fournissent des informations détaillées

sur les tâches de sauvegarde à exécuter. Les deux principales tâches de sauvegarde
sont listées dans ce document :
v «Sauvegarde des informations de configuration», à la page 516
v «Sauvegarde de la base de données du serveur», à la page 530
Conseil : Lors de la sauvegarde de la base de données, générez deux copies de

sauvegarde afin de la protéger en cas d'échec de support. Vérifiez qu'au moins une
sauvegarde complète de la base de données est disponible sur site. Si vous devez
restaurer la base de données après l'échec d'une mise à niveau, le fait de disposer
d'une base de données de sauvegarde sur site vous permet de gagner du temps.
Pour plus d'informations sur la protection de la base de données, voir «Protection

et reprise de la base de données», à la page 6.
Important : Ne désinstallez pas le serveur version 5 sur le système z/OS tant que
vous n'avez pas vérifié que la migration vers la version 6.3 ou ultérieure a été
effectuée.
Comparaison des méthodes de migration de la base de

données
Vous pouvez transférer la base de données version 5 vers le nouveau système
version 6.3 ou ultérieure à l'aide de la méthode de support, la méthode de réseau
ou de la méthode hybride de mise à niveau et migration. La méthode hybride de
mise à niveau et migration combine la migration de la base de données avec les
opérations d'exportation et d'importation.
Comparaison des méthodes de support et de réseau
Le moyen classique de migrer la base de données consiste à utiliser la méthode de

support ou de réseau :
Via des supports
Vous devez extraire les données de la base de données d'origine vers des
supports et les charger ultérieurement dans la nouvelle base de données.
Utilisez cette méthode si vous ne pouvez pas vous connecter au système
version 5 et au système version 6.3 ou ultérieure à l'aide d'un réseau à
grande vitesse.
Via un réseau
Vous devez simultanément extraire les données de la base de données
d'origine et les charger dans la nouvelle base de données.
Utilisez cette méthode si votre système requiert des performances
maximales de l'utilitaire de mise à niveau et si les systèmes sont connectés
à l'aide d'un réseau à grande vitesse.
AIX ou Linux
Dans l'une et l'autre méthode, le serveur d'origine ne peut pas être exécuté
pendant l'extraction des données. Vous pouvez vous attendre à ce que le serveur
Tivoli Storage Manager ne soit pas disponible pendant des heures ou des jours. Le
temps d'indisponibilité dépend de plusieurs facteurs, y compris de la taille de la
base de données et des performances du système de disque contenant la base de
données précédente et la nouvelle base de données.
Méthode hybride de mise à niveau et migration
S'il est important de migrer le système avec un temps d'indisponibilité minimum,

vous pouvez utiliser la méthode hybride de mise à niveau et migration. Cette
méthode utilise une combinaison d'opérations d'exportation et d'importation avec
les méthodes de mise à niveau version 6 classiques. Cela implique une
planification détaillée.
Avant de choisir d'utiliser la méthode hybride de mise à niveau et migration,

estimez le temps qu'il faut pour migrer les données à l'aide de l'une des méthodes
classiques par rapport à la méthode hybride. La méthode classique applicable dans
votre cas peut prendre moins de temps que la méthode hybride de mise à niveau
et migration.
Pour obtenir une description de la méthode hybride de mise à niveau et migration,

voir le livre blanc du forum Tivoli Storage Manager à l'adresse suivante :
http://www.ibm.com/developerworks/mydeveloperworks/wikis/home/wiki/
Tivoli Storage Manager/page/Tivoli Storage Manager Version 6 Hybrid Upgrade
Migration Method.
Concepts associés:
«Scénarios de migration d'un serveur à partir d'un système z/OS vers AIX ou
Linux sur System z», à la page 477
Changements opérationnels et exigences

Pour préparer les changements apportés au système Tivoli Storage Manager suite à
la migration, étudiez les changements opérationnels et les exigences.
Pour obtenir une description générale des changements opérationnels consécutifs à

une mise à niveau sur la version 6.3 ou ultérieure, voir «Modifications liées aux
opérations», à la page 4. Pour obtenir une description des changements spécifiques
à une migration de z/OS vers un système exécuté sous AIX ou Linux sur System
z, voir les rubriques suivantes.
Systèmes automatisés de réponse au message

Le système d'exploitation z/OS comprend une fonction automatisée de réponse au
message. Si vous configurez des réponses aux messages automatisées pour le
serveur version 5 et ses messages avec un préfixe ANR, vous pouvez en faire
autant pour le dernier serveur multimédia z/OS installé et ses messages avec le
préfixe ANZ.
Pour obtenir une liste des messages ANZ, voir la section des messages dans IBM
Tivoli Storage Manager for z/OS Media Installation and Configuration Guide.
Remarques sur les performances

La migration sur le serveur Tivoli Storage Manager version 6.3 ou ultérieure
exécuté sous AIX ou Linux sur System z peut impliquer différentes exigences en

AIX ou Linux
matière de capacité de traitement du réseau comparé au système version 5 sur

z/OS. Après la migration, vous pouvez constater une augmentation du nombre de
données transférées via les réseaux connectés au serveur Tivoli Storage Manager.
Pour optimiser les performances de serveur, respectez les instructions figurant dans
cette section et planifiez la migration en conséquence.
Avant de configurer une connexion réseau entre le serveur Tivoli Storage Manager
et le serveur multimédia z/OS, tenez compte des points suivants :
v Pour les connexions client utilisées pour sauvegarder, archiver, restaurer et
récupérer les données, le serveur version 6.3 ou ultérieure requiert généralement
la même bande passante de réseau que le serveur version 5 exécuté sur un
système z/OS. On part pour cela du principe que le serveur migré version 6.3
ou ultérieure protège les mêmes clients que le système version 5.
v Il faut une bande passante du réseau plus grande pour les opérations de
stockage ou de récupération des données à l'aide du serveur multimédia z/OS
que pour les opérations utilisant une disque ou une bande magnétique local(e).
v Pour optimiser les performances, utilisez les réseaux dédiés aux connexions
entre le serveur version 6.3 ou ultérieure et le serveur multimédia z/OS. Utilisez
les technologies permettant d'optimiser les performances et l'efficacité du réseau,
telles que les trames jumbo et HiperSockets. HiperSockets peut être utilisé pour
les connexions entre les partitions logiques Linux et z/OS situées sur le même
complexe de processeurs centraux System z.
v Pour augmenter la bande passante du réseau entre le serveur version 6.3 ou
ultérieure et le serveur multimédia z/OS, configurez plusieurs interfaces
spécifiées sur une définition de serveur unique. Vous pouvez utiliser une
expression délimitée par des virgules pour l'adresse TCP/IP, comme dans cet
exemple :
define server ...
hladdress=10.10.48.1,10.10.56.1
lladdress=1500...
Si cette méthode est utilisée, des données peuvent être stockées ou récupérées à
l'aide d'une interface réseau disponible. Vous n'êtes pas obligé de répartir les
exigences de stockage entre plusieurs classes d'unités. Cette méthode permet
d'augmenter la bande passante du réseau disponible et de prendre en charge la
reprise de la connexion réseau et l'équilibrage des charges.
v Pour optimiser les performances réseau à l'aide du serveur multimédia z/OS,
vérifiez que les systèmes z/OS et de serveur Tivoli Storage Manager peuvent
utiliser une fenêtre TCP/IP de grande taille. Sous z/OS, cela signifie que
l'instruction TCPIP.PROFILE TCPCONFIG comprend le paramètre
TCPMAXRCVBUFRSIZE qui n'est pas paramétré sur la valeur par défaut de 256 Ko
ou plus. Sous AIX, cela signifie que le paramètre de réglage réseau rfc1323 est
paramétré sur 1, ce qui ne correspond pas à la valeur par défaut. Sous Linux,
cela signifie que le paramètre de noyau net.ipv4.tcp_window_scaling n'est pas
paramétré sur la valeur par défaut 1.
v Pour réduire les exigences en matière de bande passante du réseau, stockez les
données de sauvegarde et d'archivage dans un pool de disque local du serveur
version 6.3 ou ultérieure. Utilisez ensuite la sauvegarde de pool de stockage et la
migration du pool de stockage pour copier et déplacer les données dans l'espace
de stockage de bande serveur multimédia z/OS. Cette méthode requiert moins
de bande passante de réseau que la sauvegarde ou l'archivage des données
directement dans l'espace de stockage des classes d'unités serveur multimédia
z/OS FILE, puis le déplacement des données dans l'espace de stockage de bande
z/OS.
AIX ou Linux
v Si vous stockez les données à l'aide du serveur multimédia z/OS, la capacité de

traitement de la sauvegarde de session unique doit représenter 80 % de la
capacité de traitement prévue lors du stockage des données à l'aide des unités
de stockage locales. Par exemple, on part du principe que la capacité de
traitement pour la sauvegarde d'un grand nombre de données est de 30 Mo par
seconde pour le serveur version 5 sur un système z/OS. Suite à la migration
vers le serveur version 6.3 ou ultérieure exécuté sous AIX ou Linux sur System z
avec un serveur multimédia z/OS, la capacité de traitement peut être réduite et
passer à 80 % ou 24 Mo par seconde.
v Utilisez l'agent de stockage Tivoli Storage Manager installé sur le système client
avec la méthode de communication hors réseau local pour sauvegarder ou
archiver des données directement dans le serveur multimédia z/OS. Cette
méthode peut permettre de réduire les exigences en matière de bande passante
de réseau du serveur version6.3 ou ultérieure et d'augmenter la capacité de
traitement de la sauvegarde.

AIX ou Linux
Chapitre 19. Planification de la migration
la planification de la migration vers la version IBM Tivoli Storage Manager 6.3 ou
ultérieure est très importante car, vous devez non seulement installer le nouveau
code, mais aussi transférer les contenus de la base de données du serveur dans la
nouvelle base de données.
Le transfert des données de la base de données du serveur version 5 d'origine vers

la base de données version 6.3 ou ultérieure utilise un pourcentage élevé de la
capacité de traitement et requiert une quantité importante d'activités d'E-S.
Dans votre planification, envisagez de tester la migration sur des systèmes de

non-production. Vous obtenez ainsi des informations sur la durée de la migration
de la base de données du serveur, lesquelles vous aident à prévoir la durée
d'indisponibilité du serveur. La durée de la migration varie d'une base de données
à l'autre.
Vous obtenez également des informations sur la taille de la nouvelle base de

données par rapport à celle d'origine, ce qui vous permet d'évaluer plus
précisément l'espace de stockage dont vous avez besoin.
Si vous disposez de plusieurs serveurs, envisagez de migrer un premier serveur

afin de voir comment le processus fonctionne avec vos données. Basez-vous sur les
résultats que vous avez obtenus pour planifier la migration des autres serveurs.
Configurations matérielle et logicielle requises pour les serveurs

version 5 et 6.3 ou ultérieure
Avantd de démarrer le processus de migratiodn, vérifiez que le système est
conforme aux configurations matérielles et logicielles requises pour le serveur V5
et le serveur V6.3 ou ultérieure.
| Au cours du processus de migration, vous devez mettre à niveau le serveur

| version 5 sous z/OS vers la version 5.5.6 ou une version ultérieure. Suivez les
| instructions contenues dans la section «Déterminer le niveau approprié d'un
| serveur V5 avant une mise à niveau», à la page 42. Les serveurs Tivoli Storage
| Manager version 5.5 sous z/OS sont pris en charge par z/OS V1R7, z/OS V1R8 ou
| plus.
Pour plus d'informations sur les configurations matérielles et logicielles requises

pour un serveur V6.3 ou ultérieure qui s'exécute sur AIX, voir «Configuration
requise pour le serveur sur des systèmes AIX», à la page 25.
Pour plus d'informations sur les configurations matérielles et logicielles requises

pour un serveur V6.3 ou ultérieure qui s'exécute sur Linux on System z,
voir«Configuration du serveur requise pour Linux sur des systèmes System z», à la
page 34.
Pour obtenir des informations actualisées sur la configuration matérielle et

logicielle requise, consultez le site de support du produit Tivoli Storage Manager à
l'adresse http://www.ibm.com/support/docview.wss?uid=swg21243309.

AIX ou Linux
Compatibilité avec d'autres composants et d'autres versions

Vous pouvez installer d'autres produits déployant et utilisant les produits DB2 sur
le même système que le serveur Tivoli Storage Manager version 6.3 ou ultérieure
exécuté sous AIX ou Linux sur System z.
Pour installer et utiliser d'autres produits utilisant un produit DB2 sur le même
système que le serveur Tivoli Storage Manager, vérifiez que vous respectez les
critères suivants :
le système
Niveau de version Les autres produits qui utilisent un produit
DB2 doivent utiliser DB2 version 9 ou une
version ultérieure. Les produits DB2
comprennent l'encapsulation de produit et le
support de ségrégation depuis la version 9.
A compter de cette version, vous pouvez
exécuter plusieurs copies des produits DB2,
à différents niveaux de code et sur le même
système. Pour plus d'informations, voir les
informations relatives à plusieurs copies DB2
: http://pic.dhe.ibm.com/infocenter/
db2luw/v9r7.
ID utilisateur et répertoires Vérifiez que les ID utilisateur, les ID
utilisateur isolé, l'emplacement d'installation,
les autres répertoires et les informations
associées ne sont pas partagés entre les
installations DB2. Vos spécifications doivent
être différentes des ID et emplacements
utilisés pour l'installation et la configuration
du serveur Tivoli Storage Manager. Si vous
avez utilisé l'assistant dsmicfgx ou
dsmupgdx pour configurer la version 6.3 ou
ultérieure, ou pour la mise à niveau du
serveur à partir de la version 5.5, il s'agit
des valeurs que vous avez entrées lors de
l'exécution de l'assistant. Si vous avez utilisé
les procédures manuelles de configuration
pour la version 6.3 6.3 ou ultérieure ou la
mise à niveau à partir de la version 5.5,
vérifiez ces procédures si nécessaire pour
sélectionner de nouveau les valeurs utilisées
pour le serveur.
AIX ou Linux
le système (suite)
Attribution de ressources Examinez les ressources et la capacité du
système par rapport aux conditions requises
pour le serveur Tivoli Storage Manager et
les autres applications utilisant le produit
DB2. Pour fournir des ressources suffisantes
aux autres applications DB2, vous devrez
modifier les paramètres du serveur Tivoli
Storage Manager, de sorte que ce dernier
utilise moins de mémoire système et de
ressources. De même, si les charges de
travail pour les autres applications DB2
entrent en concurrence avec le serveur Tivoli
Storage Manager en termes de processeur ou
de ressources mémoire, les performances du
serveur en matière de gestion de la charge
de travail du client ou toute autre opération
côté serveur risquent d'être également
affectés.
Pour scinder les ressources et offrir

davantage de capacité pour le réglage et
l'allocation de processeur, mémoire et toute
autre ressource système pour plusieurs
applications, envisagez d'utiliser un système
de partition logique (LPAR), de partition de
charge de travail (WPAR) ou tout autre
support de poste de travail virtuel. Par
exemple, exécutez une application DB2 sur
son propre système virtualisé.
Estimation de l'espace requis pour la base de données et le journal de

reprise
Planifiez l'espace requis pour le processus de migration, ainsi que pour les bases
de données de serveur et le journal de reprise du serveur version 6.3 ou ultérieure.
L'espace requis pour une migration multiplateforme de la version 5 vers la version
6.3 ou ultérieure est similaire à celui pour une mise à niveau de la version 5 vers la
version 6.3 ou ultérieure sur la même plateforme.
Pour estimer l'espace requis pour la base de données et le journal de reprise,

procédez comme suit.
1. Estimez l'espace requis pour le système du serveur version 5. Pour de plus
amples informations, consultez la rubrique «Espace requis pour le système du
serveur version 5», à la page 44.
2. Estimez l'espace requis pour le système du serveur version 6.3 ou ultérieure.
Pour de plus amples informations, consultez la rubrique «Espace requis pour le
système du serveur version 6», à la page 45.
3. Estimez l'espace total pour le processus de migration et le serveur version 6.3
ou ultérieure. Pour de plus amples informations, consultez la rubrique
«Estimation de l'espace disque total requis pour le processus de mise à niveau
et le serveur mis à niveau», à la page 47. Si vous prévoyez de migrer les
données via des supports, consultez les informations figurant dans la section
Chapitre 6, «Scénario 3 : Nouveau système, via des supports», à la page 193. Si
AIX ou Linux
vous prévoyez de migrer les données via des supports, consultez les
informations figurant dans la section Chapitre 7, «Scénario 4 : Nouveau
système, via le réseau», à la page 245.
4. Facultatif : utilisez une feuille de calcul pour planifier la quantité et
l'emplacement de l'espace pour le serveur version 6.3 ou ultérieure. Pour de
plus amples informations, consultez la rubrique «Feuille de calcul pour l'espace
de planification du serveur V6.3 ou ultérieure», à la page 50.
Planification des transferts de données depuis les périphériques FILE

et DISK
Le serveur version 6.3 ou ultérieure ne peut pas accéder aux données stockées à
l'aide des périphériques DISK ou FILE sur le serveur z/OS. Cette restriction
signifie que les données stockées sur des périphériques DISK ou FILE doivent être
sauvegardées sur bande avant le début de la migration.
Vérifiez que vous possédez des volumes de bande disponibles pour sauvegarder
les données stockées à l'aide des périphériques DISK ou FILE :
v Des volumes de bande doivent, au minimum, être disponibles pour la
sauvegarde du pool de stockage principal.
v Pour optimiser le processus, des volumes de bande doivent être disponibles
pour créer une seconde sauvegarde sur site du pool de stockage principal. En
créant un pool de stockage de sauvegarde hors site et un autre sur site, vous
respectez les exigences de reprise après incident du stockage hors site.
Parallèlement, les volumes du second pool sont disponibles sur site pour
restaurer les données immédiatement après la migration.
La première étape du processus de préparation consiste à exécuter la commande

ZMSPREPARE. La commande ZMSPREPARE permettra d'identifier tous les pools de
stockage de type d'unité DISK et FILE, ainsi que les volumes et la quantité de
données devant être sauvegardés sur bande.
Tous les groupes de sauvegarde sur le stockage FILE doivent être supprimés.
Estimation de l'espace requis pour le stockage et les périphériques

Estimez la quantité d'espace requise pour le stockage des données sur le nouveau
système Tivoli Storage Manager version 6.3 ou ultérieure. Planifiez les
périphériques à utiliser pour le stockage.
1. Estimez l'espace requis pour le stockage sur le nouveau système Tivoli Storage
Manager version 6.3 ou ultérieure. Pour de plus amples informations, consultez
la section décrivant l'estimation d'espace requis pour les pools de stockage à
accès séquentiel dans le Guide d'administration de Tivoli Storage Manager.
2. Planifiez l'espace requis pour les périphériques pour le nouveau système Tivoli
Storage Manager version 6.3 ou ultérieure. Pour plus d'informations, consultez
la section planification de la configuration des périphériques dans Guide
d'administration.
AIX ou Linux
Estimation de la durée requise pour la migration

Le serveur version 5 n'est pas disponible pendant toute la durée des opérations de
migration. Estimez la durée de la migration afin de pouvoir prévoir la durée
d'indisponibilité du serveur. Le temps nécessaire à la migration d'un serveur
version 5 dépend de plusieurs facteurs.
Les facteurs suivants peuvent affecter la durée de la migration :

v Taille de la base de données à migrer.
v Nombre et vitesse des processeurs système.
v Configuration des périphériques de stockage. Si un nouveau matériel est
introduit, il faut un certain temps pour définir les nouveaux périphériques sur le
serveur, tester la configuration et ajuster les pools de stockage.
v Méthode choisie pour transférer les données de la base de données version 5
vers la base de données version 6 (via les supports ou le réseau). Lors du
transfert des données via le réseau, la durée d'extraction et la durée d'insertion
se chevauchent. La méthode via le réseau peut permettre de réduire la durée
totale de la migration grâce au chevauchement des opérations.
v Type de charge de travail gérée par le serveur. Une charge de travail consistant
en un grand nombre de petits fichiers ou de fichiers aux noms très longs peut
rallonger la durée de la migration.
Des données sont disponibles sur des mises à niveau de Tivoli Storage Manager
version 5 vers la version 6.3 ou ultérieure sur la même plateforme. Ces
informations peuvent vous aider à estimer la durée requise pour une migration
multiplateforme.
Dans des environnements de tests de performances dans les laboratoires IBM, les
opérations de migration ont atteint 5-10 Go par heure à l'aide de la méthode via le
réseau. Ce débit est calculé en fonction de la quantité d'espace utilisée par la base
de données version 5 et non en fonction de l'espace attribué à cette dernière. Les
résultats dépendent de la configuration. Le débit est plus faible si vous utilisez la
méthode via les supports, car les opérations d'extraction et d'insertion des données
s'exécutent de façon séquentielle et non simultanément.
Si vous estimez la durée requise pour les opérations de migration en fonction de la

quantité de données contenues dans la base de données, cette estimation sera
probablement supérieure à la réalité. La structure de la base de données
(l'arborescence) est composée de branches dont les noeuds finaux (ou "feuilles")
contiennent les enregistrements de la base de données. L'extraction ignore les
branches et extrait uniquement les informations contenues dans les feuilles. Ainsi,
la quantité de données extraites peut être largement inférieure à l'espace total
utilisé par la base de données (qui inclut l'ensemble des informations contenues
dans les feuilles et dans les branches). Il est impossible de déterminer à l'avance la
quantité de données à extraire par rapport à la taille totale de la base de données.
C'est la raison pour laquelle votre estimation sera probablement supérieure à la
durée réelle de l'opération.
Les résultats obtenus dans votre environnement peuvent être différents de ceux
obtenus dans les laboratoires. Il est particulièrement important de tester les
opérations de migration dans votre environnement pour les serveurs Tivoli Storage
Manager utilisés par les systèmes essentiels.

AIX ou Linux
Exemple - Estimation de la durée de migration en fonction de

la taille de la base de données
Vous pouvez faire une estimation approximative de la durée de la migration en
fonction de la quantité de données contenues dans la base de données version 5.
Pour effectuer cette estimation, ajoutez la durée requise pour les tâches
supplémentaires telles que la configuration des périphériques de stockage.
1. Pour obtenir des détails sur la base de données version 5, émettez une
commande.
v Si le serveur version 5 est en cours d'exécution, exécutez la commande
suivante :
query db format=detailed
v Si le serveur version 5 n'est pas en cours d'exécution, utilisez l'utilitaire de
mise à niveau :
dsmupgrd querydb
Voici un exemple de sortie obtenue lorsque le serveur est en cours d'exécution
et que la commande query db format=detailed est émise :
Capacité affectée (Mo) : 37 992
Extension maximale (Mo) : 1 968
Réduction maximale (Mo) : 8 360
% util : 78,0
Pct. occupé % util : 78,0
Nombre total des demandes de mise en mémoire tampon : 180 003
% de réussite en mémoire cache : 99,81
% d’attente en mémoire cache : 0,00
Sauvegardes incrémentielles depuis la dernière sauvegarde complète : 0
Changement depuis la dernière sauvegarde (Mo) : 67,63
Horodatage de la dernière sauvegarde complète : 18/05/11 23:16:26
Voici un exemple de sortie obtenue lorsque le serveur n'est pas en cours

d'exécution et que l'utilitaire dsmupgrd querydb est exécuté :
AIX ou Linux

Capacité affectée (Mo) : 37 992
Extension maximale (Mo) : 1 968
Réduction maximale (Mo) : 8 360
% util : 78,0
Pct. occupé % util : 78,0
Nombre total de demandes de mise en mémoire tampon : 179 946
% de réussite en mémoire cache : 99,81
% d’attente en mémoire cache : 0,00
Sauvegardes incrémentielles depuis la dernière sauvegarde complète : 0
Changement depuis la dernière sauvegarde (Mo) : 67,63
Horodatage de la dernière sauvegarde complète : 19/05/11 06:16:26
2. Pour calculer la quantité de données dans la base de données, utilisez les

résultats de la commande de requête. Multipliez le nombre de pages utilisées
par leur taille.
En utilisant les résultats de l'exemple, vous pouvez calculer la quantité de
données contenues dans cette base :
7 584 383 pages utilisées × 4096 octets/page = 31 065 632 768 d’octets ou 28,9 Go
3. Pour estimer le temps nécessaire pour l'opération de mise à niveau, divisez la
quantité de données par le débit prévu.
Par exemple, pour un débit de 5 Go/heure et de 10 Go/heure :
«DSMUPGRD QUERYDB (affichage d'informations sur une base de données
version 5)», à la page 561
Conseils de performances pour le processus d'extraction

d'une base de données version 5
La vitesse du processus d'extraction est par nature limitée par le débit d'E-S vers la
destination des données.
La durée du processus dépend également de la taille de la base de données. Cette

durée sera approximativement équivalente à celle requise pour une sauvegarde
Ne réorganisez pas la base de données Tivoli Storage Manager version 5 avant la

mise à niveau. La raison en est la suivante : une plus grande capacité de traitement
peut être obtenue lorsque la base de données source ne contient pas de longues
séquences de pages allouées à une table de base de données unique. Cette astuce
s'applique à la méthode de support comme à la méthode de réseau.
Les astuces suivantes en matière de performances dépendent de la méthode choisie

pour le transfert des données à partir de la base de données version 5 .
Via des supports
Si vous utilisez la méthode de support, suivez les astuces suivantes :

AIX ou Linux
v Si vous extrayez les données sur bande, utilisez une unité de bande
haute vitesse.
v Si cette dernière et la destination des données extraites se trouvent sur
une unité de virtualisation (contrôleur de stockage haut de gamme ou
unité de virtualisation SAN), vérifiez que les deux numéros d'unités
logiques virtuelles ne sont pas installés sur la même unité de disque
physique. Assurez-vous que l'espace utilisé pour la base de données
version 5 et la destination des données extraites est situé sur des unités
de disque physiques distinctes au sein de l'unité de virtualisation.
v S'il n'est pas possible de fournir des numéros d'unité logique différents
pour la base de données version 5 et la destination de l'extraction, le
processus d'extraction sera plus lent. Cette baisse de performances peut
être acceptable selon la taille de la base de données et vos exigences de
mise à niveau.
Via un réseau
Si vous utilisez la méthode de réseau, suivez l'astuce suivante :
v Utilisez une liaison HSL. Pour mettre à niveau une base de données de
plus de 2 ou 3 Go, utilisez au moins un réseau Ethernet d'1 Go.
Concepts associés:
Conseils relatifs aux performances pour l'insertion de

données dans la base de données version 6.3 ou ultérieure
Le processus d'insertion des données de la version 5 extraites dans la base de
données version 6.3 ou ultérieure est la partie la plus longue du processus de
migration et la plus critique pour la configuration du système.
Il peut s'exécuter sur un système conforme aux exigences minimales requises, mais
ses performances peuvent être faibles. Pour optimiser ces dernières, configurez le
système comme indiqué dans les conseils suivants.
Processeurs
Le processus d'insertion est destiné à utiliser plusieurs processeurs ou
coeurs. Le processus d'insertion s'exécute généralement plus efficacement
sur un système doté d'un nombre relativement moins élevé de processeurs
rapides. Si le système est doté de nombreux processeurs lents, vous pouvez
atteindre des niveaux de performances réduits.
Espace de stockage sur disque
Le processus d'insertion est destiné à utiliser des sous-systèmes de
stockage sur disque à bande passante élevée. La vitesse du processus est
étroitement liée à l'espace de stockage sur disque utilisé.
Pour des performances optimales, utilisez plusieurs numéros d'unité
logique mappés vers plusieurs disques indépendants ou vers des
ensembles redondants de disques indépendants (RAID) dont la taille des
segments est élevée (128 ko, par exemple). Utilisez un système de fichiers
différent sur chaque numéro d'unité logique.
Le tableau suivant illustre le bon usage des numéros d'unité logique.
Tableau 75. Exemple d'utilisation de LUN
LUN Utilisation
1 Journal actif
AIX ou Linux
Tableau 75. Exemple d'utilisation de LUN (suite)

LUN Utilisation
2 Journal d'archivage
3, 4, 5 Répertoires de bases de données
Si l'espace de stockage sur disque est fourni par une unité de virtualisation
(contrôleur de stockage haut de gamme ou unité de virtualisation SAN),
vérifiez qu'aucun numéro d'unité logique virtuel ne figure sur la même
unité de disque physique. Assurez-vous que les répertoires utilisés sont
placés sur des unités de disque physiques différentes au sein de l'unité de
virtualisation.
Planification de la mise à niveau de plusieurs serveurs et composants

Si votre environnement inclut plusieurs serveurs et agents de stockage, évaluez la
compatibilité des versions exécutées avec un serveur version 6.3 ou ultérieure mis
à niveau. Prévoyez de mettre à niveau un premier serveur dans un environnement
de test. Echelonnez ensuite les mises à niveau des serveurs et des agents de
stockage supplémentaires.
Pour plus d'informations sur l'agent de stockage et la compatibilité de la

bibliothèque avec les serveurs Tivoli Storage Manager V6.3 ou ultérieure, voir la
note technique 1302789 (http://www.ibm.com/support/
docview.wss?uid=swg21302789).
Tâches associées:
«Test du processus de mise à niveau pour un serveur», à la page 56
Planification des changements apportés aux agents de stockage

Pour pouvoir se connecter à un serveur version 6.3 ou ultérieure dans un système
qui utilise le serveur multimédia z/OS, les agents de stockage doivent au
minimum avoir le niveau de version 6.3.
Si des agents de stockage ont un niveau de version antérieur, mettez-les à niveau

vers la version 6.3 dans un premier temps avant de mettre à niveau le serveur vers
la version 6.3 ou ultérieure. Vérifiez que le transfert des données hors réseau local
fonctionne comme prévu avant de mettre à niveau le serveur.
Pour obtenir les informations les plus récentes sur les niveaux de version des
agents de stockage pris en charge, consultez le site Web suivant :
Concepts associés:
«Impacts de la migration sur les agents de stockage», à la page 489
Préparation des changements opérationnels

Lorsque vous migrez votre système de la version 5 vers la version 6.3 ou
ultérieure, la méthode de sauvegarde et de surveillance de la base de données du
serveur change.
Vérifiez les procédures d'exploitation, les scripts et les plannings d'administration

que vous utilisez pour les opérations du serveur :
v Planifiez régulièrement la sauvegarde de la base de données du serveur via
l'utilisation de plannings d'administration, un script de maintenance ou encore

AIX ou Linux
vos propres scripts. Sauvegardez la base de données du serveur au moins une

fois par jour. Pour obtenir de meilleurs résultats, considérez les sauvegardes les
plus fréquentes pour la base de données V6.3 ou ultérieure que vous avez
exécutées avec la base de données V5. Pour s'assurer que l'espace du journal
d'archivage a été supprimé, pensez à la programmation de sauvegardes de bases
de données plus complètes et moins incrémentielles.
Consultez les informations relatives au fonctionnement des sauvegardes
automatiques de bases de données pour le serveur version 6.3 ou ultérieure.
Pour plus de détails, voir le Guide d'administration.
v Compréhension de la méthode d'utilisation de la base de données et de l'espace
du journal de restauration et du changement de contrôle.
v Vérifiez les scripts et les plannings d'administration. Le serveur version 6.3 ou
ultérieure ajoute de nouvelles commandes et en modifie et en supprime d'autres.
Ces modifications affecteront vos opérations automatisées. Pour plus
d'informations sur les commandes nouvelles et modifiées, voir «Modifications
apportées aux commandes et options», à la page 60.
v Vérifiez les commandes SELECT que vous utilisez régulièrement. Un certain
nombre de paramètres et de syntaxes précédemment autorisés ne sont pas
acceptés par le programme du gestionnaire de base de données. Pour plus
d'informations sur les mises à jour de la commande SELECT, voir «Modifications
apportées à la commande SELECT», à la page 79. Pour résoudre les problèmes liés
aux commandes SELECT, voir la note technique 1380830 (http://www.ibm.com/
v Si vous utilisez des produits d'éditeurs de logiciels indépendants en guise
d'interface avec le serveur, assurez-vous qu'ils sont compatibles avec le serveur
Informations de référence pour la planification

Les informations concernant les commandes et options de serveur mises à jour et
la migration des classes d'unités et des attributs de bibliothèque peuvent vous
aider à planifier le processus de migration.
Informations de référence générales pour les mises à niveau et

les migrations Tivoli Storage Manager
les informations de référence générales sont fournies. Vous pouvez consulter les
changements apportés aux commandes, aux options et aux utilitaires implémentés
depuis la version 5 et en savoir plus sur les pratiques de convention de nom du
serveur. Pour plus d'informations, voir «Informations de référence pour la
planification», à la page 60.
Utilitaires, scripts et commandes
Pour plus d'informations sur les utilitaires, les scripts et les commandes
disponibles, voir Annexe A, «Utilitaires, scripts et commandes pour la mise à
niveau de serveur et la migration», à la page 561.
Migration des attributs d'unité et de bibliothèque

Consultez les informations sur la classe d'unités pour comprendre comment les
classes d'unités z/OS sont mappées vers un équivalent utilisé par un système AIX
ou Linux sur System z. Consultez les informations sur la bibliothèque et le chemin
pour comprendre comment les nouvelles bibliothèques et les nouveaux chemins
AIX ou Linux
sont définis afin de s'assurer que les classes d'unités existantes peuvent utiliser le
serveur multimédia z/OS. L'utilitaire DSMSERV INSERTDB mappe les classes d'unités
et définit les bibliothèques et les chemins.
Migration de classe d'unités
Les tableaux ci-dessous expliquent comment chaque type d'unité z/OS est mappé
vers son équivalent sur un système AIX ou Linux sur System z.
Tableau 76. Attributs de classe d'unités 3590
Utilisé sur AIX et
Attribut Utilisé sur z/OS Linux sur System z Remarques
DEVTYPE Yes Yes La valeur est toujours
de 3590.
LIBRARY Yes (facultatif) Yes (obligatoire) La classe d'unités
LIBRARY est
remplacée par une
nouvelle bibliothèque
fournissant un accès
via le serveur
multimédia z/OS. Si
aucune bibliothèque
n'a été spécifiée sur
le système version 5,
une nouvelle
bibliothèque est
définie pour fournir
un accès via le
serveur multimédia
z/OS.
ESTCAPACITY Yes Yes La valeur est
conservée.
MAXCAPACITY Yes No La valeur est
supprimée.
FORMAT Yes Yes La valeur est
conservée.
PREFIX Yes Yes La valeur est
conservée.
MOUNTRETENTION Yes Yes La valeur est
conservée.
MOUNTWAIT Yes Yes La valeur est
conservée.
MOUNTLIMIT Yes Yes La valeur est
conservée.
COMPRESSION Yes New La valeur est
conservée.
EXPIRATION Yes New La valeur est
conservée.
RETENTION Yes New La valeur est
conservée.
PROTECTION Yes New La valeur est
conservée.

AIX ou Linux
Tableau 76. Attributs de classe d'unités 3590 (suite)

Utilisé sur AIX et
UNIT Yes New La valeur est
conservée.
Tableau 77. Attributs de classe d'unités 3592

Utilisé sur AIX et
de 3592.
LIBRARY Yes (facultatif) Yes (obligatoire) La classe d'unités
LIBRARY est
remplacée par une
via le serveur
une nouvelle
bibliothèque est
un accès via le
serveur multimédia
z/OS.
conservée.
supprimée.
WORM Yes Yes La valeur est
conservée.
SCALEDCAPACITY No Yes La valeur par défaut
100 est utilisée.
DRIVEENCRYPTION No Yes Une valeur ALLOW
est utilisée. La valeur
ALLOW permet au
système z/OS distant
de contrôler
l'utilisation du
chiffrement d'unité.
conservée.
conservée.
conservée.
conservée.
conservée.
AIX ou Linux
Tableau 77. Attributs de classe d'unités 3592 (suite)

Utilisé sur AIX et
conservée.
conservée.
conservée.
conservée.
conservée.
Tableau 78. Attributs de classe d'unités CARTRIDGE

Utilisé sur AIX et
CARTRIDGE.
LIBRARY No Yes (obligatoire) Une nouvelle
bibliothèque est
un accès via le
serveur multimédia
z/OS.
conservée.
supprimée.
FORMAT No Yes La valeur par défaut
DRIVE est utilisée.
conservée.
conservée.
conservée.
conservée.
conservée.
conservée.
conservée.
conservée.
conservée.

AIX ou Linux
Tableau 79. Attributs de classe d'unités ECARTRIDGE

Utilisé sur AIX et
ECARTRIDGE.
LIBRARY Yes (facultatif) Yes (obligatoire) La bibliothèque est
remplacée par une
via le serveur
une nouvelle
bibliothèque est
un accès via le
serveur multimédia
z/OS.
conservée.
supprimée.
WORM No Yes La valeur par défaut
NO est utilisée.
DRIVEENCRYPTION No Yes Une valeur ALLOW
est utilisée. La valeur
ALLOW permet au
système z/OS distant
de contrôler
l'utilisation du
chiffrement d'unité.
conservée.
conservée.
conservée.
conservée.
conservée.
conservée.
conservée.
conservée.
conservée.
conservée.
AIX ou Linux
Tableau 80. Attributs de classe d'unités FILE

Utilisé sur AIX et
FILE.
LIBRARY No New Une nouvelle
bibliothèque n'est pas
un accès aux classes
d'unités FILE via le
serveur multimédia
z/OS. Cela est dû au
fait que le serveur
multimédia ne prend
pas en charge les
classes d'unités FILE
précédentes. La
classe LIBRARY n'est
définie qu'en fonction
des nouvelles classes
d'unités FILE et n'est
pas ajoutée aux
classes d'unités qui
existaient sur le
serveur version 5.
conservée.
conservée.
REPERTOIRE No Yes Cet attribut n'est pas
défini.
PARTAGE No Yes La valeur par défaut
NO est utilisée.
UNIT Yes No La valeur est
supprimée.
VOLSER Yes No La valeur est
supprimée.
PRIMARYALLOC No New Cet attribut n'est pas
défini pour les
migrées du serveur
version 5. Cet attribut
est uniquement
utilisé pour les
nouvelles classes
FILE ajoutées.

AIX ou Linux
Tableau 80. Attributs de classe d'unités FILE (suite)

Utilisé sur AIX et
SECONDARYALLOC No New Cet attribut n'est pas
défini pour les
migrées du serveur
version 5. Cet attribut
est uniquement
utilisé pour les
nouvelles classes
FILE ajoutées.
MAXCAPACITY Yes Yes La valeur est
conservée.
Tableau 81. Attributs de classe d'unités SERVER.

A faire : Les classes d'unités avec un type d'unité SERVER sont les mêmes dans z/OS,
AIX et Linux sur System z. Toutes les classes d'unités de type d'unité SERVER sont
conservées tel qu'elles.
Utilisé sur AIX et
SERVER.
SERVERNAME Yes Yes La valeur est
conservée.
conservée.
conservée.
conservée.
RETRYPERIOD Yes Yes La valeur est
conservée.
RETRYINTERVAL Yes Yes La valeur est
conservée.
MAXCAPACITY Yes Yes La valeur est
conservée.
Migration de bibliothèque et de chemin
Sur le système z/OS, les bibliothèques et les chemins permettent l'accès hors
réseau local des supports à l'aide d'agents de stockage exécutés sur des systèmes
AIX ou Linux sur System z. L'accès hors réseau local n'étant pas pris en charge
pour des serveurs migrés à partir de z/OS, toutes les bibliothèques et les chemins
sont supprimés au cours de la migration. Ensuite, les nouvelles bibliothèques et les
nouveaux chemins sont créés pour autoriser l'accès aux support via le serveur
multimédia z/OS.
L'utilitaire DSMSERV INSERTDB définit les nouvelles bibliothèques et les nouveaux

chemins de telle sorte que les classes d'unités existantes puissent utiliser le serveur
multimédia z/OS. Pour chaque classe d'unités, une nouvelle bibliothèque est
définie à l'aide du même nom que la classe d'unités :
AIX ou Linux
DEFINE LIBRARY <nom_classe_unités> LIBTYPE=ZOSMEDIA
Un nouveau chemin est défini :

DEFINE PATH <server_name><nom_classe_unités>SRCTYPE=SERVER DESTTYPE=LIBRARY
ZOSMEDIASERVER=<nom_serveur_support>ONLINE=YES
Migration d'options de serveur

Au cours du processus de mise à niveau, la commande ZMSPREPARE analyse le
fichier d'options du serveur Tivoli Storage Manager et fournit des
recommandations. Ces recommandations vous aident à migrer les options de
serveur vers le option de serveur du système version 6.3 ou ultérieure et vers le
option de serveur du serveur multimédia z/OS.
La commande ZMSPREPARE fournit des recommandations basées sur le tableau

ci-dessous. Avant de migrer les options de serveur, consultez le tableau.
A faire : L'ensemble des options de serveur disponible sur le serveur version 5 est
différent de l'ensemble d'options disponible sur un serveur version 6.3 ou
ultérieure. De la même manière, l'ensemble d'options de serveur disponible sur un
système z/OS est différent de l'ensemble d'options de serveur disponible sur un
système AIX ou Linux sur System z.
Tableau 82. Options de serveur spécifiques à la plateforme z/OS
Utilisé sur AIX Utilisé sur le
ou Linux sur serveur
Nom d'option System z multimédia z/OS Remarques
COMMMETHOD Yes No Cette option indique la méthode de communication
devant être utilisée par le serveur. Les systèmes z/OS
prennent uniquement en charge les méthodes de
communication TCPIP et V6TCPIP. Ces deux méthodes de
communication sont également prises en charge par les
systèmes AIX et Linux sur System z.
DELETIONEXIT No No Cette option indique un module d'exit utilisateur qui
reçoit le contrôle lorsqu'un volume de bande est supprimé
de la base de données. Cette option de serveur n'est pas
compatible avec les systèmes AIX et Linux sur System z.
C'est pour cette raison que toute entrée existante de cette
option de serveur doit être supprimée.
DYNALLOCOFFLN No Yes Cette option permet au Tivoli Storage Manager for z/OS
Media de sélectionner une unité autonome si aucune autre
n'est disponible.
FILEEXIT Yes No Cette option définit un fichier vers lequel les événements
activés sont acheminés. Le nom de fichier spécifié doit être
vérifié afin de s'assurer qu'il fonctionne sur le système
FILETEXTEXIT Yes No Cette option définit un fichier vers lequel les événements
activés sont acheminés. Le nom de fichier spécifié doit être
vérifié afin de s'assurer qu'il fonctionne sur le système
HTTPTCPPORT No No Cette option indique le numéro de port HTTP pour la
méthode de communication HTTP d'IBM TCP/IP. Cette
option n'est pas disponible dans Tivoli Storage Manager
LFVOLUMEFORMATCOUNT No No Cette option définit le nombre de volumes formatés
automatiquement par le serveur Tivoli Storage Manager
pour les opérations hors réseau local si le pool de
stockage ne contient pas de volume formaté. Cette option
n'est pas disponible dans Tivoli Storage Manager version
6.3 ou ultérieure.

AIX ou Linux
Tableau 82. Options de serveur spécifiques à la plateforme z/OS (suite)

LICENSES No No Cette option indique les termes d'un contrat de licence.
Les systèmes AIX et Linux sur System z utilisent un
mécanisme de licence différent de celui spécifié par cette
option. C'est pourquoi les nouvelles licences doivent être
enregistrées sur le serveur version 6.3 ou ultérieure. Toute
entrée existante de cette option de serveur doit être
supprimée.
MESSAGEFORMAT Yes Yes Cette option détermine si un numéro du message doit
s'afficher sur toutes les lignes d'un message multiligne ou
seulement sur la première ligne.
MSGHIGHLIGHT No No Cette option indique le niveau de gravité du message
pour la mise en évidence. Toute entrée existante doit être
supprimée lors de la migration du fichier d'options de
serveur vers les systèmes AIX ou Linux sur System z.
MSGSUPPRESS No Yes Cette option indique le niveau des messages à supprimer.
Toute entrée existante doit être supprimée lors de la
migration du fichier d'options du serveur vers les
systèmes AIX ou Linux sur System z. Toute entrée
existante doit être copiée dans le fichier d'options du
serveur serveur multimédia z/OS.
OAMCALL No Yes Cette option indique si l'allocation du Tivoli Storage
Manager for z/OS Media doit accéder à la base de
données OAM afin de déterminer si une bande
magnétique requise se trouve dans la bandothèque
automatique.
ROUTECODE No Yes Cette option indique le code d'acheminement pour les
messages Tivoli Storage Manager. Toute entrée existante
doit être supprimée lors de la migration du fichier
d'options du serveur vers les systèmes AIX ou Linux sur
System z. Toute entrée existante doit être copiée dans le
fichier d'options du serveur serveur multimédia z/OS.
TAPEDELEXIT No Yes Cette option indique le nom d'un programme d'exit
appelé lorsqu'un volume de bande est supprimé du pool
du Tivoli Storage Manager for z/OS Media des volumes
de bande gérés.
TCPADDR No Yes Cette option indique l'adresse IP d'accueil que le Tivoli
Storage Manager for z/OS Media utilise généralement
pour écouter les connexions entrantes.
TCPADMINPORT Yes No Cette option indique le numéro de port sur lequel le pilote
de communication TCP/IP du serveur attend des requêtes
pour des sessions autres que les sessions client. Cette
option doit être comprise dans le fichier d'options de
serveur AIX ou Linux pour System z.
TCPBUFSIZE Yes No Cette option définit la taille de la mémoire tampon utilisée
pour les demandes d'envoi TCP/IP. La valeur par défaut
utilisée par les systèmes AIX et Linux sur System z est 16,
comparé à 32, qui est la valeur utilisée par z/OS. Toute
valeur existante doit être reconsidérée compte tenu du fait
que le serveur version 6.3 ou ultérieure est exécuté sur un
autre système d'exploitation.
TCPNAME No Yes Cette option indique le nom de l'espace adresse de
démarrage pour TCP/IP. Toute entrée existante doit être
supprimée lors de la migration du fichier d'options du
serveur vers les systèmes AIX ou Linux sur System z.
Toute entrée existante doit être copiée sur el fichier
d'option du serveur serveur multimédia z/OS.
AIX ou Linux
Tableau 82. Options de serveur spécifiques à la plateforme z/OS (suite)

TCPPORT Yes Yes Cette option indique le numéro de port sur lequel le pilote
de communication TCP/IP du serveur attend des requêtes
pour des sessions client. Cette option doit être migrée vers
le serveur version 6.3 ou ultérieure uniquement une fois
que vous vous êtes assuré que le port indiqué est
disponible sur le serveur version 6.3 ou ultérieure. De la
même manière, cette option doit être migrée vers le
serveur multimédia z/OS uniquement une fois que vous
vous êtes assuré que le port indiqué est disponible sur ce
serveur. Il peut être utile pour les clients de contacter le
serveur multimédia z/OS sur le port existant. C'est
pourquoi le port indiqué pour cette option de serveur doit
être différent du port du serveur Tivoli Storage Manager
en cours de migration du système z/OS.
TCPWINDOWSIZE Yes No Cette option définit (en kilooctets) le volume de données
reçu pouvant être placé en mémoire tampon sur une
connexion TCP/IP en une seule fois. L'option est utilisée
pour le réglage. Toute valeur existante doit être
reconsidérée compte tenu du fait que le serveur version
6.3 ou ultérieure est exécuté sur un autre système
d'exploitation.
TECBEGINEVENTLOGGING Yes No Cette option définit si la consignation des événements
pour le destinataire Tivoli doit être lancée au démarrage
du serveur.
TECHOSTNAME Yes No Cette option désigne le nom d'hôte ou l'adresse IP du
serveur d'événements Tivoli.
TECPORT Yes No Cette option définit l'adresse du port TCP/IP sur lequel le
serveur d'événements Tivoli est en mode écoute.
UNIQUETDPTECEVENTS Yes No Cette option génère une classe d'événement Tivoli
Enterprise Console unique pour chaque message Tivoli
Storage Manager, y compris les messages client, serveur et
agent Tivoli Data Protection.
UNIQUETECEVENTS Yes No Cette option génère une classe d'événement Tivoli
Enterprise Console unique pour chaque message Tivoli
Storage Manager.
USEREXIT Yes No Cette option détermine l'exit défini par l'utilisateur chargé
de la gestion d'un événement spécifique. La syntaxe de
cette option varie suivant le système d'exploitation. Cette
option indique un module d'exit utilisateur chargé par le
serveur. C'est pourquoi toute valeur existante doit être
reconsidérée compte tenu du fait qu'un module d'exit
z/OS ne fonctionne pas sur un système d'exploitation AIX
ou Linux sur System z.
«Modifications apportées aux commandes et options», à la page 60

AIX ou Linux
Chapitre 20. Préparation de la migration
Pour préparer la migration de la version IBM Tivoli Storage Manager 5 sous z/OS
vers la version6.3 ou ultérieure dans le système AIX ou Linux z, vous devez suivre
plusieurs étapes. Vérifiez que vous avez installé et configuré le serveur version 6.3
ou ultérieure, et préparez la base de données du serveur version 5 pour la
migration.
Préparation de l'espace pour le processus de migration

Vérifiez que vous disposez d'un espace suffisant sur le système version 6.3 ou
ultérieure pour le processus de migration.
l'étape de planification. Utilisez la feuille de calcul de planification dans
laquelle vous avez entré vos informations.
2. Si vous prévoyez d'extraire la base de données du serveur d'origine vers un
support pour l'insérer ultérieurement dans une nouvelle base de données,
vérifiez que vous disposez d'un espace de stockage suffisant. L'espace de
stockage est requis pour la base de données et le fichier manifeste créé par le
processus d'extraction.
serveur et pas uniquement dans le fichier de configuration d'unité.
La classe d'unités doit être séquentielle et le type de classe d'unités doit être
une bande. Définissez une nouvelle classe d'unités si nécessaire.
données.
des droits d'accès en écriture sur ce fichier.
La taille du fichier manifeste peut être inférieure à 1 Ko. Cependant, pour
une configuration complexe, elle peut dépasser 1 Ko.

AIX ou Linux
Tâches associées:
«Estimation de l'espace requis pour la base de données et le journal de reprise», à
la page 497
Sauvegarde des informations de configuration

informations du serveur. Stockez les fichiers en lieu sûr car vous en aurez besoin
une fois l'installation de la nouvelle version du logiciel terminée. Ces fichiers vous
seront également utiles pour rétablir une version antérieure après la mise à niveau.
1. Sauvegardez les informations de configuration des unités.
2. Sauvegardez les informations de l'historique des volumes. Assurez-vous que
l'historique des volumes inclut les informations relatives à la sauvegarde de la
base de données que vous avez effectuée lors des étapes précédentes. Par
exemple, lancez la commande :
query volhistory type=dbbackup
3. Créez une copie du fichier d'options du serveur.
4. Facultatif : Créez une copie du journal comptable.
5. Sauvegardez les scripts à l'aide desquels la gestion interne quotidienne du
serveur a été effectuée. Consultez les scripts afin d'identifier les changements
Sélectionnez un emplacement qui ne soit pas sur le système mis à niveau.
Installation et configuration du serveur version 6.3 ou ultérieure

En préparation de la migration du serveur version 5 à partir du système z/OS,
installez et effectuez une première configuration du serveur version 6.3 ou
ultérieure.
Installation du serveur version 6.3 ou ultérieure sur des

systèmes AIX ou Linux


suivantes :
1. Linux Pour certains systèmes d'exploitation, vous devez vérifier certains
paramètres système avant de démarrer l'installation.
AIX ou Linux

Il va s’arrêter.
2. Connectez-vous au système à l'aide de l'ID utilisateur root.

Insérez le DVD Tivoli Storage Manager dans un lecteur de DVD. Vérifiez que
le DVD est monté sur le répertoire /dvdrom et accédez à ce répertoire.
a. Vérifiez que vous disposez de suffisamment d'espace pour stocker les
fichiers d'installation lors de leur extraction du module du produit.
Consultez le document se rapportant au téléchargement pour plus
d'informations sur les exigences en matière d'espace :
Tivoli Storage Manager Extended Edition : http://www.ibm.com/
System Storage Archive Manager: http://www.ibm.com/support/
b. Accédez au répertoire dans lequel vous avez placé le fichier exécutable.
Conseil : Assurez-vous que le fichier se trouve dans le répertoire où vous

voulez que les fichiers soient extraits. Lors d'une étape ultérieure, les
fichiers seront extraits dans ce répertoire.
c. Modifiez les droits d'accès au fichier en entrant la commande suivante :
chmod
a+x nom_module.bin

CZ1N1ML.
./nom_module.bin

5. Vérifiez que l'environnement du système respecte les exigences d'installation.
Vous pouvez vérifier les exigences manuellement ou exécuter le vérificateur
des prérequis. Pour exécuter le vérificateur des prérequis, procédez comme
suit :
a. Exécutez le fichier prereqcheck.bin.
b. Sélectionnez la langue de l'interface utilisateur du programme de
c. Dans les panneaux d'accueil et d'exclusion de responsabilité, consultez les
les contrôles avec succès, vous pouvez démarrer l'installation. Si un d'erreur

AIX ou Linux

requises avant de continuer l'installation. Pour de plus amples informations
sur le vérificateur des prérequis, consultez la rubrique «Exécution du
vérificateur de prérequis», à la page 43.
./install.bin
Pour des informations sur les traductions disponibles pour le serveur, voir la
section des langues locales. Pour les informations sur l'installation silencieuse
du serveur, voir la section sur l'installation Tivoli Storage Manager en mode
silencieux du Guide d'installation.
7. Sélectionnez la langue de votre installation et suivez l'assistant, en cliquant sur
Suivant pour passer à l'étape suivante dans l'assistant.
a. Vous devez accepter le contrat de licence pour poursuivre.

Sélectionnez le produit que vous êtes autorisé à utiliser et un
contrat de licence s'affiche. Vous ne pouvez sélectionner qu'un seul
produit sur la page. Si vous sélectionnez Tivoli Storage Manager,
Tivoli Storage Manager Extended Edition ou System Storage
Archive Manager, le système vous demande si vous utiliserez un
partage hors réseau local ou un partage de bibliothèque. Si vous
sélectionnez YES, vous devez accepter la licence Tivoli Storage
Manager for Storage Area Networks. Celle-ci s'ajoute à la licence
du produit que vous avez sélectionné sur la page précédente.
b. Sélectionnez les composants à installer. Les composants sont le
serveur, les langues, le pilote de périphérique et l'agent de
stockage. Il n'existe pas de valeur par défaut et vous devez donc
faire un choix. Si vous avez précédemment installé un serveur,
assurez-vous de sélectionner le même répertoire pendant que vous
installez un module de langue, une licence ou un pilote de
périphérique. Si vous avez précédemment installé un agent de
L'interface de programmation de l'application client Tivoli Storage Manager,
DB2 et Global Security Kit (GSKit) sont automatiquement installés en
sélectionnant le composant serveur.

Le journal d'installation est stocké à l'emplacement suivant :
/var/tivoli/tsm
AIX ou Linux

maintenance/server.
10. Linux Modifiez les valeurs des paramètres du noyau, si nécessaire.
Pour mettre à jour les paramètres du noyau sous Red Hat et SUSE Linux,
vous pouvez exécuter la commande ipcs - l afin de répertorier les valeurs
des paramètres. Analysez les résultats pour déterminer si votre système
requiert des modifications.
Pour plus d'informations sur la modification des paramètres du noyau, voir
http://pic.dhe.ibm.com/infocenter/db2luw/v9r7. Pour rechercher des
informations, entrez une chaîne de recherche telle que modifier paramètres
noyau dans la zone de recherche du site.
Pour exécuter Tivoli Storage Manager avec DB2, vous devez peut-être définir
les valeurs de paramètre de noyau à un niveau supérieur aux valeurs
minimales suggérées et effectuer d'autres changements au système. Pour plus
de détails, voir la section sur le réglage des paramètres de noyau pour les
systèmes Linux dans le Guide d'installation.
Création de répertoires et de l'ID utilisateur pour l'instance de

serveur

planification de l'espace pour le serveur.
ultérieure.
a. Créez l'ID utilisateur et le groupe.

minuscules (a-z), des chiffres (0-9) et le trait de soulignement (_). L'ID
utilisateur et le nom du groupe doivent respecter les règles suivantes :
v L'ID utilisateur et le nom de groupe ne peuvent pas commencer par ibm,
sql, sys, ou un chiffre.
v L'ID utilisateur et le nom de groupe ne peuvent pas être user, admin,
Par exemple, créez l'ID utilisateur tsminst1 dans le groupe tsmsrvrs. Les
exemples ci-dessous indiquent comment créer cet ID utilisateur et ce groupe
à l'aide des commandes du système d'exploitation.
AIX

# passwd tsminst1
Linux

AIX ou Linux
# groupadd tsmsrvrs
# passwd tsminst1
b. Déconnectez-vous, puis reconnectez-vous au système en utilisant le nouvel
ID utilisateur et le nouveau mot de passe. Utilisez un programme de
connexion interactif, tel que telnet, de telle sorte que le système vous invite
à saisir un mot de passe et à le changer si nécessaire.
c. S'il n'existe pas de profil de configuration pour cet ID utilisateur, créez le
fichier. Par exemple, créez un fichier .profile si vous utilisez l'interpréteur
de commandes Korn (ksh).
actif
journal actif
secondaire qui est
pour le journal
d'archivage

3. Créer d'autres volumes logiques et montez les volumes sur les répertoires créés
à l'étape précédent.
AIX ou Linux
Tâches associées:
«Préparation de l'espace pour le processus de migration», à la page 515
Préparation du serveur version 5 s'exécutant sous z/OS pour la

migration
Pour préparer la migration du serveur version 5, assurez-vous que celui-ci est mis
à niveau vers la version 5.5.6 ou ultérieure. Ensuite, sur le serveur version 5.5.6 ou
ultérieure, installez leserveur multimédia z/OS. Emettez la commande ZMSPREPARE
pour identifier les étapes supplémentaires devant être effectuées avant la migration
de données. Ensuite, sauvegardez les données.
Pour protéger votre serveur et ses données, suivez attentivement les étapes de
préparation.
version précédente du serveur. Le retour à la version précédente du serveur est
uniquement possible si vous avez effectué toutes les étapes de préparation.
Modification du serveur avant la migration

Une commande doit être exécutée sur le serveur afin de prévenir un type de
problème particulier pendant le processus de migration. Il est recommandé
d'apporter certains changements aux paramètres du serveur pour le préparer à la
migration.

AIX ou Linux

update stgpool
Mise à niveau du serveur version 5.5.6 ou ultérieur

Pour préparer la mise à niveau du serveur Tivoli Storage Manager version 5,
vérifiez que Tivoli Storage Manager version 5.5.6 ou ultérieure est installé.
Mettez à niveau le serveur version 5 vers la version 5.5.6 ou ultérieure de sorte à

pouvoir utiliser la commande ZMSPREPARE et d'autres outils conçus pour vous aider
à préparer la migration.
Le serveur Tivoli Storage Manager ne doit pas être en cours d'exécution lors de
l'installation du groupe de correctifs.
Pour installer un groupe de correctifs sur le serveur, vous devez avoir installé le
package de licences de Tivoli Storage Manager. Le package de licences est fourni
lors de l'achat d'une édition de base.
AIX ou Linux
licence.
1. Obtenez le fichier de pack du groupe de correctifs de la version 5.5.6 ou
ultérieure sur le site de téléchargement FTP Tivoli Storage Manager à
l'adresseftp://public.dhe.ibm.com/storage/tivoli-storage-management/
maintenance/server/v5r5/MVS/LATEST .
2. Pour obtenir des informations sur l'installation, consultez le fichier README.txt,
qui est disponible dans le fichier de pack version 5.5.6 ou ultérieure.
3. Installez le groupe de correctifs version 5.5.6 ou ultérieure.
Pour de plus amples informations sur le serveur Tivoli Storage Manager version
5.5, consultez le centre de documentation de Tivoli Storage Manager version 5.5
disponible à l'adresse suivante : http://publib.boulder.ibm.com/infocenter/
tivihelp/v1r1/index.jsp.
Installation de Tivoli Storage Manager for z/OS Media

Pour installer Tivoli Storage Manager for z/OS Media, utilisez les commandes
d'installation appropriées. Effectuez ensuite les tâches de configuration.
Installez Tivoli Storage Manager for z/OS Media en suivant les instructions
figurant dans le IBM Tivoli Storage Manager for z/OS MediaGuide d'installation et de
configuration.
Configurez Tivoli Storage Manager for z/OS Media en suivant les instructions
figurant dans le IBM Tivoli Storage Manager for z/OS MediaGuide d'installation et de
configuration.
Concepts associés:
«Présentation de Tivoli Storage Manager for z/OS Media», à la page 481
Définition d'un serveur qui correspond au serveur multimédia

z/OS
Sur le système version 5, créez une définition de serveur qui correspond au
serveur multimédia z/OS. Le serveur multimédia z/OS sera utilisé durant l'étape
DSMSERV INSERTDB pour accéder au support de mise à niveau sur bande. Après la
fin de la migration, le serveur multimédia z/OS sera utilisé pour accéder aux
données du client stockées sur bande.
Sur le serveur version 5, émettez la commande DEFINE SERVER. Vérifiez que les
paramètres suivants sont définis :
v Le paramètre SERVER_NAME doit spécifier l'ID utilisateur utilisé pour exécuter le
serveur Tivoli Storage Manager version 5.
v Le paramètre SERVERPASSWORD doit spécifier le mot de passe utilisé pour se
connecter au serveur multimédia z/OS.
v Le paramètre HLADDRESS doit spécifier l'adresse IP du serveur multimédia z/OS.
v Le paramètre LLADDRESS doit spécifier le numéro de port du serveur multimédia
z/OS.

AIX ou Linux
Voici un exemple :
define server tsmserv serverpassword=yourlife hladdress=9.115.20.97 lladdress=1555
Pour plus de détails, voir la section relative à la commande DEFINE SERVER dans
Guide de référence d'administration.
Désactivation des sessions

En préparation de la migration, évitez toute activité sur le serveur en désactivant
les nouvelles sessions. Annulez toute session existante.

query process
4. Vérifiez si une session existe et avertissez les utilisateurs que le serveur va être
arrêté. Pour rechercher les sessions existantes, utilisez la commande suivante :
query session
cancel session all
Analyse du serveur Tivoli Storage Manager à l'aide de

ZMSPREPARE
Pour analyser le serveur Tivoli Storage Manager version 5 en préparation de la
migration, utilisez la commande ZMSPREPARE. La commande ZMSPREPARE fournit des
informations utiles pour exécuter les étapes nécessaires avant de pouvoir
commencer la migration de données.
Le rapport généré par la commande ZMSPREPARE inclut des informations sur les
éléments suivants :
v Volumes de pool de stockage situés sur les classes d'unités FILE et DISK et qui
doivent être convertis sur bande ou supprimés
v Volumes séquentiels enregistrés dans l'historique des volumes et situés sur le
stockage FILE, à l'exception des volumes de pool de stockage
v Groupes de sauvegarde situés sur le stockage FILE
v Classes d'unités non valides
v Options de serveur pouvant nécessiter une mise à niveau
v Horodatage de la plus récente sauvegarde de la base de données du serveur
AIX ou Linux
Exigence : Exécutez la commande ZMSPREPARE pour vous assurer que tous les
prérequis sont remplis avant de commencer la migration de données.
1. Sur le serveur version 5, exécutez la commande ZMSPREPARE à partir de ligne de
commande du client d'administration. Pour de plus amples informations sur la
commande ZMSPREPARE, consultez la rubrique «ZMSPREPARE (Préparez un
serveur sur un système z/OS en vue d'une migration)», à la page 579. La sortie
de la commande ZMSPREPARE affiche les types d'informations suivants :
Disk-based storage pools.
Storage Storage Device Estimated Pct Volumes

Pool Name Pool Type Class Name Capacity Util are not
marked
destroyed
----------- ----------- ---------- ---------- ----- ---------
ADPPOOL Active-Data FILE 551 G 19.6 0
DISKPOOL Primary DISK 731 G 38.5 10
FILEMIGPOOL Primary FILE 851 G 20.8 12
FROM-POMPE- Primary FROM-POMP- 561 G 22.1 0
II2-VV EII2-VV
LONGFNPOOL Primary FILE 61 G 1.5 0
**************************************************
FILE device type backup sets.
Node Name Backup Set Name Data Type Date/Time

--------------- --------------- --------------- --------------------
CLIENT115 TEST.99790852 File 08/19/11 13:20:25
Retention Device Description Has Table

Period Class Name of Conten-
ts (TOC)?
--------- ---------- --------------- ----------
365 FILE No Description No
**************************************************
Sequential volumes with a device type of FILE.
Date/Time Volume Type Device Class Volume Name

-------------------- -------------- ------------ ---------------------
08/19/11 13:36:45 EXPORT FILE SVTSMS1.S3785800.EXP
**************************************************
Convert server options file.
( Yes/No/Consult documentation/ Unknown option )
Line Option Include in V6 server Include in media server

Number options file? options file?
------ -------------- ------------------------ ------------------------
1 MSGWAITALL No No
6 TCPPORT Consult Consult
7 TCPNAME No Consult
8 TCPADMINPORT Yes No
9 HTTPTCPPORT No No
14 VOLUMEHISTORY Consult No
15 DEVCONFIG Consult No
22 TCPBUFSIZE Consult No
35 USELARGEBUFFE- No No
RS
48 LICENSE No No
49 LICENSE No No
54 LFVOLUMEFORMA- No No

AIX ou Linux
TCOUNT
60 LFVOLUMEFORMA- No No
TCOUNT
73 LICENSE No No
74 LICENSE No No
**************************************************
No unsupported device classes are found.
**************************************************
Last
Complete
Backup
Date/Time
---------
08/18/11
13:52:-
35
**************************************************
2. Apportez les changements appropriés à votre environnement système en
utilisant le rapport généré par la commande ZMSPREPARE. En se basant sur le
rapport, vous pouvez exécuter une ou plusieurs des tâches suivantes :
v Sauvegardez les pools de stockage principaux basés sur disque identifiés par
la commande ZMSPREPARE afin de copier les pools de stockage sur bande.
Pour plus d'informations, voir «Sauvegarde des données des pools de
stockage principaux basés sur disque», à la page 527. Mettez à niveau les
volumes de pool de stockage de sorte que ACCESS=DESTROYED et supprimez les
volumes des pools de stockage de sauvegarde basés sur disque. Pour plus
d'informations, voir «Suppression des volumes de pools de stockage de copie
basés sur disque». Pour afficher les noms de volume dans les pools de
stockage qui nécessitent une manipulation, utilisez la commande ZMSPREPARE
FORMAT=DETAILED.
v Mettez à jour les options de serveur identifiées. Pour plus d'informations,
voir «Création du fichier d'options du serveur Tivoli Storage Manager», à la
page 528.
v Supprimez ou modifiez les classes d'unités non valides.
v Supprimez les volumes séquentiels portant un type d'unité FILE tels que les
sauvegardes de base de données, les exportations et les groupes de
sauvegarde. Pour plus d'informations, voir «Identification et suppression des
groupes de sauvegarde FILE», à la page 528.
Suppression des volumes de pools de stockage de copie

basés sur disque
Avant de migrer le serveur Tivoli Storage Manager version 5.5 sous z/OS vers la
version6.3 ou ultérieure, supprimez tous les volumes de pool de stockage sur
disque ou marquez-les comme détruits.
Les volumes de pools de stockage principaux peuvent être marqués comme

détruits, mais détruit n'est pas un mode d'accès valide pour les volumes de pools
de copie sur disque. C'est pourquoi vous devez supprimer les volumes des pools
de stockage de copie sur disque avant de migrer vos données.
AIX ou Linux
1. A l'aide de la sortie de la commande ZMSPREPARE, déterminez si le pool de

stockage de copie doit être migré du serveur version 5.5 vers le serveur version
6.3 ou ultérieure ou s'il peut être recréé sur le serveur version 6.3 ou ultérieure
après la migration.
2. Si vous devez migrer le pool de stockage de copie vers le serveur version 6.3
ou ultérieure, recréez le pool de stockage de copie sur le système version 5.5 à
partir du pool de stockage principal à l'aide de la commande BACKUP STGPOOL.
Cette procédure s'explique par le fait que les copies des pools de copie ne sont
pas autorisées dans Tivoli Storage Manager.
3. Si le pool de stockage principal est également basé sur disque, sauvegardez le
pool de stockage vers un pool de stockage de copie basé sur bande comme
décrit dans la rubrique «Sauvegarde des données des pools de stockage
principaux basés sur disque».
4. Supprimez les volumes de pools de stockage de copie sur disque à l'aide de la
commande DELETE VOLUME.
Pour plus de détails, voir la section relative à la commande DELETE VOLUME
dans Guide de référence d'administration.
Sauvegarde des données des pools de stockage principaux

basés sur disque
Les pools de stockage principaux basés sur disque ne seront pas disponibles après
la migration. C'est pourquoi vous devez créer un pool de stockage de copie sur
bande pour chaque pool de stockage principal basé sur disque qui n'en possède
pas. Ensuite, sauvegardez toutes les données des pools de stockage principaux
basés sur disque vers les pools de stockage de copie sur bande.
Après la migration, restaurez les pools de stockage à l'aide de cette sauvegarde.

1. Créez un pool de stockage de copie sur bande. Emettez la commande DEFINE
STGPOOL. Spécifiez les paramètres suivants :
v Le paramètre POOL_NAME indique le nom du pool de stockage à définir.
v Le paramètre DEVICE_CLASS_NAME indique le nom de la classe d'unités à accès
séquentiel à laquelle ce pool de stockage de copie est affecté.
v Le paramètre POOLTYPE=COPY indique que vous souhaitez définir un pool de
stockage.
Voici un exemple :
define stgpool tapepool2 dc480 pooltype=copy
Pour plus d'informations, voir la section DEFINE STGPOOL dans Guide de
référence d'administration.
2. Sauvegardez un pool de stockage principal. Emettez la commande BACKUP
STGPOOL. Par exemple, pour sauvegarder un pool de stockage principal appelé
PRIMARY_POOL sur un pool de stockage de copie appelé COPYSTG, émettez
backup stgpool primary_pool copystg
Pour plus d'informations, voir la section BACKUP STGPOOL dans Guide de
3. Modifiez le mode d'accès de chaque volume de pools de stockage principal
basé sur disque sur détruit de sorte qu'aucun fichier ne puisse être écrit sur ou
lu à partir des volumes dans le pool de stockage. Utilisez la commande UPDATE

AIX ou Linux
VOLUME. Pour plus d'informations sur le changement du mode d'accès aux pools
de stockage, voir Guide d'administration. Pour plus d'informations sur la
commande UPDATE VOLUME , voir Guide de référence d'administration.
Identification et suppression des groupes de sauvegarde FILE

Les groupes de sauvegarde utilisant les classes d'unités FILE ne peuvent être
générés, transférés ou ouverts après la migration de vos données. C'est la raison
pour laquelle vous devez supprimer tous les groupes de sauvegarde qui utilisent
les classes d'unités FILE.
1. Déterminez les groupes de sauvegarde qui utilisent les classes d'unités FILE.
Passez en revue le rapport généré par la commande ZMSPREPARE.
2. Supprimez les groupes de sauvegarde qui utilisent les classes d'unités FILE.
Pour plus de détails, voir la section relative à la suppression des paramètres de
sauvegarde dans Guide d'administration.
Tâches associées:
«Analyse du serveur Tivoli Storage Manager à l'aide de ZMSPREPARE», à la page
524
Création du fichier d'options du serveur Tivoli Storage

Manager
Pour créer un fichier d'options du serveur, commencez par utiliser le fichier
d'options à partir du serveur Tivoli Storage Manager version 5 et apporter les
changements appropriés au serveur version 6.3 ou ultérieure.
1. Transférez le fichier d'options utilisé par le serveur Tivoli Storage Manager
version 5 vers le répertoire d'instance du serveur Tivoli Storage Manager
version 6.3 ou ultérieure. Vérifiez que le fichier appartient au propriétaire de
l'instance de serveur Tivoli Storage Manager et qu'il dispose des autorisations
valides pour cet ID propriétaire.
2. Déterminez les changements requis dans le fichier d'options et apportez-les :
a. Passez en revue le rapport généré par la commande ZMSPREPARE. La section
Conversion du fichier d'options du serveur répertorie les options qui
existent dans le fichier d'options version 5, mais ne peuvent pas être
transférées vers le fichier version 6.3 ou ultérieure.
b. Utilisez les informations de la section Convert server options file pour
déterminer s'il faut inclure une option de serveur dans le fichier version 6.3
ou ultérieure.
Pour plus de détails sur les options du serveur, voir Guide de référence
d'administration. Pour plus d'informations sur les options de serveur nouvelles et
modifiées depuis la version 5, voir «Modifications apportées aux commandes et
options», à la page 60.
Tâches associées:
«Analyse du serveur Tivoli Storage Manager à l'aide de ZMSPREPARE», à la page
524
Réexécution de la commande ZMSPREPARE afin de vérifier

les conditions prérequises
Une fois que vous avez exécuté une fois la commande ZMSPREPARE et que vous
avez apporté les changements nécessaires à votre environnement, exécutez à
nouveau la commande ZMSPREPARE pour vous assurer que toutes les conditions
prérequises de migration sont respectées.
AIX ou Linux
Important : Il est obligatoire d'exécuter la commande ZMSPREPARE pour vous

assurer que tous les prérequis sont remplis avant de commencer la migration de
données.
1. Sur le serveur version 5, exécutez la commande ZMSPREPARE à partir de ligne de
commande du client d'administration. Pour de plus amples informations sur la
commande ZMSPREPARE, consultez la rubrique «ZMSPREPARE (Préparez un
serveur sur un système z/OS en vue d'une migration)», à la page 579.
2. Passez en revue le rapport généré par la commande ZMSPREPARE pour vous
assurer que toutes les conditions prérequises de la migration sont respectées. Si
les conditions prérequises de la migration sont respectées, le rapport est
identique au rapport suivant. Vérifiez les éléments suivants :
v La valeur Volumes are not marked destroyed (Volumes non marqués comme
détruits) est de 0 pour tous les pools de stockage.
v Pour les groupes de sauvegarde, ce message s'affiche : No FILE device type
backup sets are found (Aucun groupe de sauvegarde d’un type d’unité
FILE détecté).
v Pour les volumes séquentiels, ce message s'affiche : No sequential volumes
with a device type of FILE were found (Aucun volume séquentiel d’un
type d’unité FILE détecté).
v Une valeur s'affiche dans la colonne Last Complete Backup Date/Time (Heure
et date de la dernière sauvegarde complète). L'heure est de préférence
récente.
tsm: EZU11>zmsprepare
Disk-based storage pools.

Pool Name Pool Type Class Name Capacity Util are not
marked
destroyed
----------- ----------- ---------- ---------- ----- ---------
ARCHIVEPOOL Primary DISK 0.0 M 0.0 0
BACKUPPOOL Primary DISK 10.0 M 0.5 0
FILE Primary FILE 4 G 0.0 0
SPACEMGPOOL Primary DISK 0.0 M 0.0 0
**************************************************
No FILE device type backup sets are found.
**************************************************
No sequential volumes with a device type of FILE were found.
**************************************************
Convert server options file.
( Yes/No/Consult documentation/ Unknown option )

------ -------------- ------------------------ ------------------------
1 COMMMETHOD Yes No
9 LICENSE No No
10 LICENSE No No
**************************************************
No unsupported device classes are found.

AIX ou Linux
**************************************************
Last
Complete
Backup
Date/Time
---------
09/26/20-
11 09:5-
9:15
**************************************************
3. Si des conditions prérequises de la migration ne sont pas respectées, apportez
les changements appropriés dans votre environnement système et exécutez à
nouveau la commande ZMSPREPARE. Répétez cette étape comme demandé
jusqu'à ce que toutes les conditions prérequises de la migration soient
respectées.
Sauvegarde de la base de données du serveur

Immédiatement avant de migrer le serveur, exécutez une sauvegarde complète de
la base de données sur une classe d'unités de bande.
Sauvegardez la base de données à l'aide de la commande suivante. Exécutez une

sauvegarde intégrale ou instantanée.
backup db type=type devclass=nom_classe_unités
La classe d'unités que vous indiquez doit exister et avoir des volumes disponibles.
Par exemple, pour effectuer une sauvegarde instantanée de votre base de données
vers la classe d'unités TAPECLASS à l'aide de volumes utilisables, procédez
comme suit :
Conseil : Pour protéger contre la défaillance des supports, faites deux copies de la
sauvegarde. Vérifiez qu'au moins une sauvegarde de base de données complète est
possible sur site. Si vous devez restaurer la base de données après l'échec d'une
mise à niveau, le fait de disposer d'une base de données de sauvegarde sur site
vous permet de gagner du temps.
Arrêt du serveur avant la migration

Sur le serveur Tivoli Storage Manager version 5 s'exécutant sous z/OS, arrêtez tous
les processus serveur. Démontez ensuite toutes les bandes montées et arrêtez le
serveur.
query process
AIX ou Linux
d'administration.
suivantes :
query mount
halte
Préparation de la base de données d'un serveur version 5

pour la migration
2. Connectez-vous en tant qu'administrateur au système de serveur version 5.
3. Préparez la base de données à l'aide de l'utilitaire DSMUPGRD PREPAREDB. Pour
utiliser l'utilitaire DSMUPGRD PREPAREDB sous z/OS, vous devez soumettre un
travail par lots à l'aide du langage JCL, comme dans l'exemple suivant :
//PREPARE JOB ,REGION=256M,TIME=1440,CLASS=A,MSGCLASS=H
//* SETPROG APF,ADD,DSN=SVTSMS1.TSM556.LINKLIB,VOL=TS405B
//*
//TIVSMDB EXEC PGM=DSMUPGRD,
// PARM=’POSIX(ON)/PREPAREDB MEDIASERVER=TUCMVSTT’
//STEPLIB DD DSN=SVTSMS1.TSM556.LINKLIB,DISP=SHR
//OPT DD DSN=SVTSMS1.TSM556.OPTIONS,DISP=SHR
//DSMAMENG DD DSN=SVTSMS1.TSM556.MESSAGES(ANRMENU),DISP=SHR
//HLPAMENG DD DSN=SVTSMS1.TSM556.HELP(ANRHENU),DISP=SHR
//DSK DD DSN=SVTSMS1.TSM556.DISKLOG,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
4. Surveillez la sortie du travail pour détecter des erreurs et des messages
d'avertissement. La sortie du travail se trouve sur la console MVS.
Avant de migrer la base de données du serveur V5, assurez-vous de l'opération en

cours se termine avec succès. Si ce n'est pas le cas, il se peut que vous deviez
redémarrer le serveur version 5 pour résoudre le problème et réexécuter l'opération
de préparation.

AIX ou Linux
Chapitre 21. Migration de la base de données du serveur z/OS
vers le serveur version 6.3 ou ultérieure
Migrez la base de données du serveur IBM Tivoli Storage Manager V5
fonctionnant sur z/OS vers le serveur V6.3 ou ultérieure.
Déterminez la méthode de transfert de la base de données : via des supports ou

via un réseau. Pour obtenir des informations sur les avantages de chaque méthode,
d consultez la rubrique «Comparaison des méthodes de migration de la base de
Dans chacune des méthodes, le serveur d'origine ne peut pas être en cours
d'exécution lors de l'extraction des données.
Pour déplacer la base de données via des supports, suivez les instructions de la
rubrique «Migration d'un serveur z/OS version 5 via des supports».
Pour déplacer la base de données via le réseau, suivez les instructions de la

rubrique «Migration d'un serveur z/OS version 5 via un réseau», à la page 536.
Migration d'un serveur z/OS version 5 via des supports

Pour migrer un serveur z/OS version 5 via des supports, préparez la base de
données version 5 pour la migration et extrayez les données vers les supports.
Créez ensuite la nouvelle base de données et formatez-la. Chargez les données
extraites dans la nouvelle base de données.

1. Pour définir la base de données, exécutez l'assistant DSMICFGX comme vous le
feriez lors de l'installation de Tivoli Storage Manager.
2. A l'aide de l'ID du propriétaire d'instance Tivoli Storage Manager, exécutez la
commande suivante :
3. Pour formater la base de données, utilisez l'utilitaire DSMSERV LOADFORMAT avec
les paramètres adéquats.
Si vous procédez de cette manière, il est inutile de configurer le système pour une
sauvegarde de base de données après la migration.
Extraction des données sur des supports

Extrayez les données de la base de données du serveur version 5 d'origine vers le
support séquentiel.
1. Connectez-vous en tant qu'administrateur au serveur Tivoli Storage Manager
version 5 à l'aide de la console d'administration.

AIX ou Linux
3. Pour démarrer l'extraction, utilisez l'utilitaire DSMUPGRD EXTRACTDB. Pour utiliser

l'utilitaire DSMUPGRD EXTRACTDB sous z/OS, vous devez soumettre un travail par
lots à l'aide du langage JCL, comme dans l'exemple suivant :
//EXTRMED JOB ,REGION=256M,TIME=1440,CLASS=A,MSGCLASS=H
//* SETPROG APF,ADD,DSN=SVTSMS1.COLLIN.TSM556.LINKLIB,VOL=TS405B
//*
// PARM=’POSIX(ON)/EXTRACTDB DEVCLASS=CARTRIDGE MAN=//SVTSMS1.MED.MFST’
//SYSPRINT DD SYSOUT=*
Pour obtenir des informations sur la commande DSMUPGRD EXTRACTDB, consultez

la rubrique «DSMUPGRD EXTRACTDB (extraction de données à partir de la
base de données d'un serveur version 5)», à la page 567.
4. Surveillez la sortie du travail pour détecter des erreurs et des messages
d'avertissement. La sortie du travail se trouve sur la console MVS. Un message
s'affichant juste avant la fin du processus indique la réussite ou l'échec de
l'opération :
complète de la base de données.
Transfert de la bande vers une autre bandothèque

Si vous utilisez des unités de bande directement connectées au serveur version 6.3
ou ultérieure, il se peut que vous deviez déplacer les bandes au lieu des unités de
bande gérées par le serveur multimédia z/OS.
Cette étape est requise uniquement si vous prévoyez d'exécuter la commande

DSMSERV INSERTDB pour transférer les données du serveur version 5 vers des unités
de bande directement connectées au serveur version 6.3 ou ultérieure. Dans ce cas,
il se peut que vous deviez déplacer les bandes vers une autre bandothèque avant
de pouvoir insérer les données dans la base de données DB2. Pour de plus amples
informations, reportez-vous à la documentation technique de votre bandothèque.
Chargement des données extraites dans la nouvelle base de

données
Chargez les données extraites de la base de données du serveur version 5 dans la
base de données du serveur version 6.3 ou ultérieure.
v Une nouvelle base de données vide doit être préparée sur le serveur version 6.3
ou ultérieure à l'aide de la commande DSMSERV LOADFORMAT.
AIX ou Linux

serveur version 6.3 ou ultérieure. Les autorisations doivent être définies pour
accorder l'accès au support à l'ID utilisateur auquel appartient l'instance de
serveur version 6.3 ou ultérieure.
v Le paramètre MANIFEST doit être spécifié pour indiquer que les données seront
lues à partir d'un support externe.
1. Sur le serveur version 5, démarrez le serveur multimédia z/OS. Le serveur
version 6.3 ou ultérieure accédera aux volumes de données extraits via le
2. Connectez-vous avec l'ID utilisateur de l'instance de serveur Tivoli Storage
Manager au système sur lequel vous avez installé le serveur version 6.3 ou
ultérieure.
3. Copiez le fichier manifeste qui a été créé par le processus d'extraction sur le
système version 5 vers le système version 6.3 ou ultérieure. Assurez-vous que
l'ID utilisateur d'instance est propriétaire ou possède des droits en
lecture/écriture sur le fichier manifeste.
| 4. Vérifiez le contenu du fichier manifeste puis modifiez le fichier si nécessaire :
| a. Vérifiez que les noms d'unité sont valides pour le système V6.3 ou
| ultérieure. En particulier, vérifiez que les définitions pour accéder au
| serveur multimédia sont correctes. Si vous n'utilisez pas un serveur
| multimédia, vérifiez que les noms d'unité pour accéder aux périphériques
| qui se trouvent sur le système V6.3 ou ultérieure sont corrects.
| données.
5. Pour charger une base de données de serveur extraite dans la base de données
version 6.3 ou ultérieure vide, émettez la commande DSMSERV INSERTDB. Dirigez
la sortie du processus vers un fichier à des fins de surveillance. Par exemple,
exécutez la commande suivante, sur une seule ligne :
AIX Linux

système affiche des statistiques temporaires sur l'opération. Toutefois, il peut y
avoir des périodes durant lesquelles aucun message n'est généré. Durant ce
temps, les opérations DB2 s'exécutent en arrière-plan. La durée du processus
dépend de la taille de la base de données. Pour plus d'informations, voir
«Estimation de la durée requise pour la migration», à la page 499.
Facultatif : vérifiez que le processus de chargement des données se poursuit ;
surveillez l'utilisation du processeur et des entrées-sorties pour le processus du
serveur et le processus DB2 correspondant. Un message dans le résultat du
processus de la commande DSMSERV INSERTDB indique l'état de l'opération :
Le message de réussite doit être affiché pour pouvoir passer à l'étape suivante.
7. Si vous avez utilisé la méthode avec supports pour la mise à niveau et une
unité de bande, protégez la bande qui contient les données extraites après la fin
de l'opération d'insertion. Par exemple, supprimez la bande ou consultez-la
Chapitre 21. Migration de la base de données du serveur z/OS vers le serveur version 6.3 ou ultérieure 535
AIX ou Linux
dans la bibliothèque. Empêchez la réutilisation de la bande jusqu'à ce que vous

DSMUPGRD EXTRACTDB
Migration d'un serveur z/OS version 5 via un réseau

Pour migrer un serveur version 5 s'exécutant sous z/OS vers un serveur version
6.3 ou ultérieure s'exécutant sous AIX ou Linux on System z, plusieurs étapes sont
requises. Préparez la base de données du serveur version 5 pour la migration, puis
créez et formatez la nouvelle base de données. Ensuite, déplacez la base de
données du serveur version 5 via le réseau vers la base de données du serveur

1. Pour définir la base de données, exécutez l'assistant DSMICFGX comme vous le
feriez lors de l'installation de Tivoli Storage Manager.
2. A l'aide de l'ID du propriétaire d'instance Tivoli Storage Manager, exécutez la
commande suivante :
3. Pour formater la base de données, utilisez l'utilitaire DSMSERV LOADFORMAT avec
les paramètres adéquats.
Si vous procédez de cette manière, il est inutile de configurer le système pour une
sauvegarde de base de données après la migration.
Transfert de la base de données du serveur via un réseau

Pour déplacer la base de données du serveur via un réseau, démarrez d'abord
l'utilitaire DSMSERV INSERTDB sur le serveur version 6.3 ou ultérieure pour vous
assurer que le serveur peut recevoir la base de données. Puis, sur le serveur
version 5, extrayez la base de données et envoyez-la via le réseau au serveur
version 6.3 ou ultérieure à l'aide de l'utilitaire DSMSERV EXTRACTDB.
Avant de lancer cette procédure, vérifiez que le serveur Tivoli Storage Manager
version 5 et le serveur version 6.3 ou ultérieure ne sont pas en cours d'exécution.
2. Démarrez le processus DSMSERV INSERTDB sur le serveur version 6.3 ou
ultérieure afin de recevoir la base de données. Le processus doit être lancé par
l'ID utilisateur du propriétaire de l'instance Tivoli Storage Manager. Pour
surveiller le processus, dirigez sa sortie vers un fichier. Par exemple, démarrez
le serveur en respectant un délai de 60 minutes (durée par défaut) nécessaire à
l'établissement d'une connexion entre le serveur version 6.3 ou ultérieure et en
dirigeant la sortie du processus vers le fichier insert.out à l'aide de la
commande ci-dessous :

serveur d'origine.
3. Surveillez la sortie du processus. Une période non résolution des messages
peut s'écouler. Pendant cette période, les opérations DB2 s'exécutent en arrière
AIX ou Linux
plan. Facultatif : Pour vérifier que les opérations se poursuivent comme prévu,
surveillez l'utilisation l'utilisation du CPU et d'I/O pour le processus de
serveur et le processus DB2 correspondant. Avant de passer à l'étape suivante,
vérifiez que le processus DSMSERV INSERTDB a résolu le message suivant :
4. Démarrez le processus DSMSERV EXTRACTDB sur le serveur version 5. Indiquez
l'adresse TCP/IP et le port du serveur version 6.3 ou ultérieure sur la carte
PARM. Soumettez un travail par lots à l'aide du langage JCL, comme dans
l'exemple suivant :
//EXTRACT JOB ,REGION=256M,TIME=1440,CLASS=A,MSGCLASS=H
//*
// PARM=’POSIX(ON)/EXTRACTDB HLADDRESS=9.11.125.129 LLADDRESS=1500’
5. Surveillez les processus pour détecter des erreurs, des messages d'avertissement
et des éléments que vous pourriez devoir résoudre. La sortie du travail se
trouve sur la console MVS.
6. Pour rechercher les messages qui indiquent la réussite ou l'échec des
opérations, examinez les sorties des processus d'extraction et d'insertion.

produites.
produites.
Chapitre 21. Migration de la base de données du serveur z/OS vers le serveur version 6.3 ou ultérieure 537
AIX ou Linux
Chapitre 22. Configuration des périphériques de serveur
multimédia z/OS sur le nouveau serveur
Sur le serveur IBM Tivoli Storage Manager version 6.3 ou ultérieure, configurez les
périphériques que vous prévoyez d'utiliser avec le stockage du serveur multimédia
z/OS.
Pour plus d'informations, consultez la section relative à la configuration du serveur

Tivoli Storage Manager en vue d'utiliser le stockage du serveur multimédia z/OS
d'Guide d'administration.

Chapitre 23. Exécution des premières étapes après la mise à
niveau
Une fois que vous avez migré le système, configurez les options du serveur,
vérifiez les résultats de migration et effectuez d'autres tâches pour vous assurer
que le système fonctionne comme prévu.
Effectuez les tâches qui sont décrites dans les rubriques suivantes :
1. «Configuration des options de serveur du serveur migré»
2. «Démarrage du serveur», à la page 543
3. «Vérification des résultats de la migration», à la page 548
4. «Recréation des pools de stockage basés sur disque et déplacés vers une
bande», à la page 548
5. «Enregistrement des licences», à la page 550
6. «Sauvegarde de la base de données», à la page 550
7. «Mise à jour de l'automatisation», à la page 551
8. «Mise à jour de la configuration des agents de stockage», à la page 551
9. «Début des opérations et surveillance des serveurs», à la page 552
10. «Migration des données depuis les volumes multimédia z/OS vers d'autres
périphériques», à la page 554
Une fois que vous migrez le système vers la version 6.3.3 ou supérieure, vous
pouvez authentifier les mots de passe avec le serveur répertoire LDAP, ou
authentifier les mots de passe avec le serveur IBM Tivoli Storage Manager. Les
mots de passe qui sont authentifiés à l'aide du serveur d'annuaire LDAP peuvent
fournir une sécurité de système améliorée. Pour plus de détails, voir la section
relative à la gestion des mots de passe et des procédures de connexion dans le
Configuration des options de serveur du serveur migré

Afin d'éviter les problèmes liés à la croissance de la base de données et aux
performances de serveur, le serveur surveille automatiquement les tables de sa
base de données et les réorganise si nécessaire. Avant de démarrer le serveur pour
une utilisation en production, définissez les options de serveur afin de contrôler le
moment où la réorganisation est exécutée. Si vous prévoyez d'utiliser le
dédoublonnage, assurez-vous que l'option permettant d'exécuter la réorganisation
de l'index est activée.
Vérifiez les paramètres de plusieurs autres options de serveur.
La réorganisation des tables et des index requiert des ressources de processeur

importantes, un espace de journal actif et un espace de journal d'archivage.
Comme la sauvegarde de base de données est prioritaire par rapport à la
réorganisation, sélectionnez l'heure et la durée de la réorganisation afin de vous
assurer que les processus ne se chevauchent pas et que la réorganisation peut être
effectuée. Pour plus d'informations sur la réorganisation de la planification, voir

AIX ou Linux
Si vous mettez à jour ces options de serveur lorsque le serveur est en cours
d'exécution, vous devez arrêter et redémarrer le serveur avant que les valeurs
mises à jour s'appliquent.
1. Modifiez les options de serveur.
Modifiez le fichier d'options du serveur, dsmserv.opt, dans le répertoire
d'instance du serveur. Procédez comme suit lors de la modification du fichier
d'options du serveur :
v pour activer une option, supprimez l'astérisque placé au début de la ligne ;
v Saisissez une option sur une ligne.
v Saisissez une seule option par ligne. L'option complète avec sa valeur doit se
trouver sur une seule ligne.
v Si vous avez plusieurs entrées pour une option du fichier, le serveur utilise la
dernière.
v Pour afficher les options de serveur disponibles, voir l'exemple de fichier,
dsmserv.opt.smp, dans le répertoire /opt/tivoli/tsm/server/bin.
2. Si vous prévoyez d'utiliser le dédoublonnage, activez l'option de serveur
ALLOWREORGINDEX. Ajoutez l'option et la valeur suivantes au fichier d'options du
serveur :
allowreorgindex yes
3. Paramétrez deux options de serveur contrôlant le moment où la réorganisation
commence et combien de temps elle dure. Sélectionnez une heure et une durée
de telle sorte que la réorganisation soit exécutée au moment où vous pensez
que le serveur est le moins occupé. Ces options de serveur contrôlent les
processus de réorganisation des tables et des index.
a. Paramétrez l'heure de démarrage de la réorganisation à l'aide de l'option de
serveur REORGBEGINTIME. Indiquez l'heure au format 24 heures. Par exemple,
pour paramétrer l'heure de début de la réorganisation à 16h30, définissez
l'option et la valeur suivantes dans le fichier d'options du serveur :
reorgbegintime 20:30
b. Paramétrez l'intervalle au cours duquel le serveur peut commencer la
réorganisation. Par exemple, pour indiquer que le serveur peut commencer
la réorganisation quatre heures après l'heure paramétrée à l'aide de l'option
de serveur REORGBEGINTIME, définissez l'option et la valeur suivantes dans le
fichier d'options du serveur :
reorgduration 4
4. Vérifiez les options de serveur suivantes.
Nom de l'option Instructions

DEVCONFIG Vérifiez que le nom de fichier spécifié par l'option DEVCONFIG
fonctionne sur le système version 6.3 ou ultérieure. Vérifiez que le
chemin existe et que la syntaxe est correcte pour la plateforme
LANGUAGE Vérifiez que la langue spécifiée par l'option LANGUAGE est adaptée.
Spécifiez fr_FR ou une autre langue disponible pour le serveur.
Pour plus d'informations sur les langues disponibles, consultez la
section sur les langues locales de serveur dans l'annexe B.
AIX ou Linux
Nom de l'option Instructions

VOLUMEHISTORY Vérifiez que le nom de fichier spécifié par l'option VOLUMEHISTORY
fonctionne sur le système version 6.3 ou ultérieure. Vérifiez que le
chemin existe et que la syntaxe est correcte pour la plateforme
Important : Le serveur version 6.3 ou ultérieure utilise un format
différent pour les informations de l'historique des volumes que le
serveur version 5. C'est la raison pour laquelle vous devez
sauvegarder l'historique des volumes une fois la migration
terminée. L'option VOLUMEHISTORY était facultative dans la version 5,
mais elle est obligatoire pour la sauvegarde de base de données et
la restauration dans la version 6.3 ou ultérieure.
5. Si le serveur était en cours d'exécution lorsque vous avez mis à jour le fichier
d'options du serveur, arrêtez et redémarrez le serveur.
Démarrage du serveur
Vérifiez que l'instance du serveur est configurée correctement en démarrant
celle-ci. Avant de démarrer l'instance de serveur, assurez-vous que les autorisations
et les valeurs ulimit sont correctement définies.

Le démarrage du serveur est une opération qui s'effectue au niveau du système

d'exploitation à laquelle s'appliquent un certain nombre de restrictions. Si vous
n'êtes pas autorisé à utiliser le programme DSMSERV, vous ne pouvez pas le lancer.
Si vous n'avez pas de droits en lecture ou en écriture sur les fichiers contenus dans
le répertoire d'instance, vous ne pouvez pas démarrer cette instance du serveur.
Important : Linux Au démarrage du serveur Tivoli Storage Manager, le

processus dsmserv est lancé en tant que propriétaire de l'instance. Sur lesLinux
systèmes d'exploitation, es noms de fichier spécifiques au périphérique
appartiennent à l'utilisateur root. Ils sont généralement en lecture/écriture pour
l'utilisateur root et en lecture seule en cas d'accès par le groupe et au niveau
mondial. Le serveur Tivoli Storage Manager étant démarré en tant qu'utilisateur
non root, il est possible qu'il ne dispose pas des droits requis pour accéder aux
fichiers d'unité spéciaux en mode lecture/écriture. Pour y remédier, modifiez les
paramètres d'autorisation sur les fichiers d'unité spéciaux (par exemple, /dev/rmtX)
pour accorder des droits d'accès en lecture/écriture à l'utilisateur de l'instance.
Vous pouvez procéder de différentes façons pour modifier les paramètres
d'autorisation :
AIX ou Linux
v Si le système est dédié à Tivoli Storage Manager et que seul l'administrateur

Tivoli Storage Manager y a accès, assurez-vous que les fichiers d'unité spéciaux
sont globalement modifiables.
v Si le système comprend plusieurs utilisateurs, vous pouvez limiter l'accès en
faisant de l'utilisateur de l'instance Tivoli Storage Manager le propriétaire des
fichiers d'unité spéciaux.
v Si plusieurs instances utilisateur s'exécutent sur le même système, modifiez le
nom du groupe, par exemple TAPEUSERS, et ajoutez chaque ID utilisateur
d'instance Tivoli Storage Manager à ce groupe. Modifiez ensuite le propriétaire
des fichiers d'unité spéciaux pour qu'ils appartiennent au groupe TAPEUSERS et
assurez-vous que le groupe peut y écrire des données :
chmod g+w /dev/rmtX
AIX Linux Lorsque vous démarrez le serveur Tivoli Storage Manager, ce

dernier tente de changer certaines valeurs ulimit en unlimited. En règle générale,
ce processus garantit des performances optimales et facilite le débogage. Si vous
êtes un utilisateur non superutilisateur au démarrage du serveur, les tentatives de
modifications des valeurs ulimit peuvent échouer. Pour garantir un bon
fonctionnement du serveur si vous utilisez le serveur en tant qu'utilisateur non
superutilisateur, définissez les valeurs ulimit aussi élevées que possible avant de
lancer leserveur.
Lors de cette tâche, assurez-vous de définir des limites utilisateur DB2 aussi
élevées que possible. DB2 repose sur une mémoire de données privée pour le tri
des allocations de mémoire lors du traitement SQL. Une capacité de segment de
mémoire partagée insuffisante peut occasionner des échecs du serveur Tivoli
Storage Manager lors de l'interaction avec DB2. Pour plus d'informations sur la
configuration de valeurs appropriées, reportez-vous à la note technique 1212174
(http://www.ibm.com/support/docview.wss?uid=swg21212174).
Pour obtenir des instructions sur la définition de valeurs ulimit, consultez le

tableau suivant :
Tableau 84. Valeurs Ulimit
Taille maximum des fichiers core créés Illimité
Taille maximum du segment de données Illimité
d'un processus
Taille de fichier maximale Illimité
| Nombre maximum de fichiers ouverts v Pour les serveurs sur lesquels sont activés
| de 16384.
Délai maximal d'exécution du processeur en Illimité
secondes
AIX ou Linux
Linux La valeur par défaut pour la limite utilisateurs des processus utilisateur
maximum (nproc) a changé sur certaines distributions et versions du système
d'exploitationLinux. La nouvelle valeur par défaut est 1024. Cette valeur peut
entraîner un comportement inattendu dans le serveur Tivoli Storage Manager.
Augmentez la limite de la valeur nproc à la valeur minimale recommandée de
16384. Si la valeur n'est pas mise à jour, le serveur peut avoir un comportement
inattendu, y compris des défaillances et des échecs.
Pour vérifier la limite utilisateur en cours, lancez la commande suivante en tant

qu'utilisateur d'instance :
ulimit -u
Par exemple :
[user@Machine ~]$ ulimit -u
16384
Pour afficher les valeurs en cours de toutes les limites utilisateur, exécutez la
commande suivante :
ulimit -a
Par exemple :
[user@Machine ~]$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 128098
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 16384
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
Pour mettre à jour la limite utilisateur du nombre maximum de processus

utilisateur, ajoutez une ligne au fichier /etc/security/limits.conf.
Démarrage du serveur à l'aide de l'ID utilisateur d'instance

AIX Linux
L'ID utilisateur d'instance possède un profil utilisateur qui lui permet d'exécuter le
serveur avec les autorisations nécessaires.
1. Connectez-vous à l'aide de l'ID utilisateur d'instance.
Conseil : Le script db2profile définit les variables d'environnement pour les

bases de données de l'instance de serveur. Lorsque l'instance de serveur est
définie, le script est ajouté au profil de configuration pour l'ID utilisateur
d'instance, si ce profil existe.
Si vous vous connectez à l'aide de l'ID utilisateur d'instance et si cet ID dispose

d'un profil de configuration (.profile si vous utilisez l'interpréteur de
commandes Korn ou .bash_profile si vous utilisez l'interpréteur de
AIX ou Linux
commandes Bash) lors de la définition de l'instance de serveur, le script

db2profile s'exécute automatiquement. Si l'ID ne dispose d'aucun profil ou si
le script ne s'exécute pas automatiquement, exécutez-le manuellement à l'aide
de la commande suivante :
. ~/sqllib/db2profile
2. Accédez au répertoire d'instance correspondant à l'instance de serveur que
vous voulez démarrer.
3. Démarrez l'instance du serveur en lançant la commande suivante :
Le programme du serveur s'exécute en arrière-plan pour vous permettre de

configurer un ID administrateur et de vous connecter à l'instance de serveur.
Exemple
Dans cet exemple, le nom de l'instance du serveur Tivoli Storage Manager est
tsminst1 et le répertoire d'instance est /tsminst1. Pour démarrer tsminst1, exécutez
cd /tsminst1
Pour démarrer le serveur en arrière-plan, exécutez la commande suivante :

cd /tsminst1
/opt/tivoli/tsm/server/bin/dsmserv -q &
Démarrage du serveur à l'aide de l'ID utilisateur root

AIX Linux

d'instance. Cependant, dans certains cas, il peut être nécessaire d'utiliser un autre
ID utilisateur pour démarrer le serveur. Par exemple, vous souhaiterez peut-être
utiliser l'ID utilisateur root pour vous assurer que le serveur peut accéder à des
périphériques spécifiques.
Pour plus d'informations sur le démarrage du serveur via l'utilisation de l'ID

utilisateur root, voir le Guide d'administration.
| Démarrage automatique des serveurs

| AIX Linux
| Vous pouvez configurer les serveurs pour qu'ils démarrent automatiquementau

| démarrage du système.
| AIX Si le serveur est installé sur un système d'exploitationAIX, utilisez le

| script rc.dsmserv qui est fourni dans ce but. Le script rc.dsmserv se trouve dans le
| répertoire /opt/tivoli/tsm/server/bin.
| AIX
| Pour démarrer automatiquement le serveur au démarrage du système, procédez

| comme suit :
AIX ou Linux
| Pour chaque serveur à démarrer automatiquement, ajoutez une entrée dans le

| fichier /etc/inittab pour exécuter le script rc.dsmserv.
| v Définissez le niveau d'exécution de la valeur correspondant au mode
| multi-utilisateur et activez l'option réseau. Généralement, le niveau d'exécution à
| utiliser est 2, 3 ou 5, selon le système d'exploitation et sa configuration.
| Assurez-vous que le niveau d'exécution dans le fichier /etc/inittab correspond
| au niveau d'exécution du système d'exploitation. Consultez la documentation de
| votre système d'exploitation pour plus d'informations sur les niveaux
| d'exécution.
| v Dans la commande rc.dsmserv, indiquez le nom du propriétaire de l'instance à
| l'aide de l'option -u et l'emplacement du répertoire d'instance du serveur à l'aide
| de l'option -i.
| Vérifiez que la syntaxe est correcte en vous reportant à la documentation de votre
| système d'exploitation.
| Exemple : Démarrage automatique d'une instance de serveur
| Dans cet exemple, le propriétaire d'instance est tsminst1 ; le répertoire de
| l'instance de serveur est /home/tsminst1/tsminst1 ; le niveau d'exécution
| est 2 ; et l'ID de processus est tsm1. Ajoutez l'entrée suivante au fichier
| /etc/inittab, sur une seule ligne :
| tsm1:2:once:/opt/tivoli/tsm/server/bin/rc.dsmserv -u tsminst1
| -i /home/tsminst1/tsminst1 -q >/dev/console 2>&1
| Exemple : Démarrage automatique de plusieurs instances de serveur
| Si vous souhaitez exécuter plusieurs instances de serveur, ajoutez une
| entrée pour chacune d'entre elles. Cet exemple utilise les ID de propriétaire
| d'instance suivants :
| v tsminst1
| v tsminst2
| Cet exemple utilise les répertoires d'instance suivants :
| v /home/tsminst1/tsminst1
| v /home/tsminst2/tsminst2
| Cet exemple utilise les ID de processus suivants :
| v tsm1
| v tsm2
| Le niveau d'exécution est 2. Ajoutez les entrées suivantes au fichier
| /etc/inittab. Assurez-vous que chaque entrée se trouve sur une seule
| ligne.
| Linux Si le serveur est installé sur un système d'exploitation Linux, utilisez le

| script dsmserv.rc.
| Linux Pour plus d'informations, voir la section relative au démarrage

| automatique du serveur sur un système Linux dans le Guide d'installation.
AIX ou Linux
Vérification des résultats de la migration

Vérifiez le fonctionnement du serveur. Si ce dernier a été installé sur un nouveau
système dans le cadre de la mise à niveau, vérifiez et mettez à jour les connexions
vers les unités de stockage et les autres composants.
1. Surveillez les messages émis par le serveur au moment du démarrage.
Recherchez les messages d'erreur et d'avertissement.
2. Si le serveur s'exécute sur un nouveau système à la suite de la mise à niveau,
vérifiez les éléments suivants :
a. Assurez-vous que toutes les unités de stockage du serveur d'origine sont
accessibles au serveur mis à niveau.
b. Comparez le nom des unités entre le nouveau système et le système
d'origine. Le cas échéant, mettez à jour les définitions des unités sur le
serveur. Par exemple, mettez à jour les définitions du chemin.
c. Mettez à jour l'adresse réseau utilisée par les clients de
sauvegarde-archivage, les agents de stockage, les serveurs des clients de
bibliothèque et d'autres serveurs destinés à communiquer avec le serveur
mis à niveau.
Au lieu d'effectuer ces mises à jour, vous pouvez éventuellement utiliser
l'adresse réseau du système d'origine en tant qu'adresse du nouveau
système. Vous avez également la possibilité de mettre à jour le système de
nom de domaine (DNS) pour qu'il désigne le nouveau système au lieu du
système d'origine. Prenez contact avec votre administrateur système.
3. Vérifiez que vous pouvez vous connecter au serveur via un client
d'administration comme avec la version antérieure du serveur.
4. Exécutez les commandes permettant d'obtenir un résumé des informations
contenues dans la base de données. Comparez le récapitulatif avec les résultats
obtenus pour les mêmes commandes avant la mise à niveau.
5. Effectuez des sauvegardes pour des postes client standard et vérifiez que leur
fonctionnement est celui attendu.
6. Vérifiez que des opérations telles que le transfert de données hors réseau local
et le partage de bibliothèques fonctionnent correctement.
7. Après avoir constaté que le serveur fonctionne correctement et qu'il n'est plus
nécessaire de rétablir la version précédente du serveur, n'oubliez pas de rétablir
la valeur initiale des paramètres que vous avez modifiés pour préparer la mise
à niveau.
Recréation des pools de stockage basés sur disque et déplacés vers

une bande
Le processus de recréation des pools de stockage basés sur disque diffère selon que
vous ayez supprimé les pools de stockage d'origine ou que vous les ayez marqués
comme détruits.
Recréation des pools de stockage supprimés

Si vous avez sauvegardé puis supprimé des pools de stockage en préparation de la
migration, définissez de nouveaux pools de stockage. Ces étapes sont nécessaires
pour vous assurer que les données sauvegardées peuvent être restaurées et
utilisées par le système Tivoli Storage Manager version 6.3 ou ultérieure.
AIX ou Linux
La commande DEFINE STGPOOL vous permet de définir des pools de stockage sur le
serveur Tivoli Storage Manager version 6.3 ou ultérieure. Sinon, définissez des
pools de stockage sur bande sur le serveur multimédia z/OS. Effectuez l'une des
étapes suivantes :
v Pour définir des pools de stockage sur le système Tivoli Storage Manager
version 6.3 ou ultérieure, exécutez la commande DEFINE STGPOOL.
Pour plus d'informations, voir la commande DEFINE STGPOOL dans Guide de
v Définissez des pools de stockage sur le serveur multimédia z/OS.
Pour de plus amples informations, consultez le Guide d'installation et de
configuration d'IBM Tivoli Storage Manager for z/OS Media.
Recréation des volumes de pool de stockage marqués comme

détruits
Si vous avez sauvegardé des volumes de pool de stockage, puis les avez marqués
comme détruits, procédez comme suit pour vous assurer que les données
sauvegardées peuvent être restaurées et utilisées par le système version 6.3 ou
ultérieure.
1. Mettez à jour les définitions des classes d'unités FILE écrites sur disque en
exécutant la commande UPDATE DEVCLASS. Pour les classes d'unités qui ont été
migrées de V5.5 Tivoli Storage Manager sur z/OS à Tivoli Storage Manager
V6.3 ou ultérieure, mettez à jour le paramètre DIRECTORY pour indiquer
l'emplacement des volumes de pool de stockage à lire. Le cas échéant, mettez à
jour le paramètre MAXCAPACITY. Pour plus d'informations sur la commande
UPDATE DEVCLASS, voir le Guide de référence d'administration.
2. Pour tous les pools de stockage basés sur disque et de type FILE qui n'allouent
pas automatiquement de nouveaux volumes, définissez des volumes de pool de
stockage. Utilisez la commande DEFINE VOLUME. Pour plus d'informations sur la
commande DEFINE VOLUME, voir le Guide de référence d'administration.
Restauration des données des pools de stockage

sauvegardés
Restaurez les pools de stockage sauvegardés vers les pools de stockage principaux
DISK et FILE sur le système Tivoli Storage Manager version 6.3 ou ultérieure.
Pour restaurer les données des pools de stockage sauvegardés, exécutez la

commande RESTORE STGPOOL sur le système Tivoli Storage Manager version 6.3 ou
ultérieure. Pour indiquer le nom du nouveau pool de stockage dans lequel les
fichiers doivent être restaurés, utilisez le paramètre NEWSTGPOOL.
Pour plus d'informations, voir la commande RESTORE STGPOOL dans Guide de

Conseil : Il peut être nécessaire d'augmenter temporairement la valeur du

paramètre MAXSCR de certains pools de stockage de type FILE pour s'assurer que les
données sont restaurées. Cela s'explique par le fait que les volumes de pool de
stockage sur lesquels s'applique l'attribut ACCESS=DESTROYED portent préjudice au
paramètre MAXSCR. Ne supprimez pas les volumes de pool de stockage marqués
comme détruits avant de restaurer les données vers le pool de stockage, car la
suppression entraîne également l'effacement des données correspondantes dans la
sauvegarde du pool de copies.
AIX ou Linux
Nettoyage en supprimant les volumes DISK et FILE de z/OS

marqués comme détruits
Après avoir restauré les pools de stockage principaux à partir de leur sauvegarde
sur bande, vous pouvez supprimer les volumes de type DISK et FILE qui étaient
marqués comme détruits. Ces volumes de pool de stockage de type DISK et FILE
étaient utilisés par le système version 5 s'exécutant sous z/OS et ne sont plus
nécessaires.
Ne supprimez pas les volumes de pool de stockage marqués comme détruits avant
de restaurer les données vers le pool de stockage, car la suppression entraîne
également l'effacement des données correspondantes dans la sauvegarde du pool
de stockage de copie.
Pour supprimer les volumes de pool de stockage, exécutez la commande DELETE

VOLUME. Pour supprimer plusieurs volumes, supprimez-les un par un.
Pour plus d'informations, voir la commande DELETE VOLUME dans Guide de référence
d'administration.
Enregistrement des licences

Enregistrez immédiatement toute fonction Tivoli Storage Manager sous licence que
vous avez acheté afin de ne pas perdre les données après le début d'utilisation du
serveur. Pour s'assurer que les licences précédentes et nouvelles sont enregistrées,
procédez comme suit :
1. Dans le répertoire d'instance du serveur de votre installation, vérifiez que le
fichier NODELOCK a été supprimé ou renommé. Le fichier NODELOCK conserve les
informations sur les licences précédentes de votre installation.
2. Réenregistrez les licences précédemment enregistrées à l'aide de la commande
REGISTER LICENSE. Pour plus d'informations concernant la commande REGISTER
LICENSE, voir la section REGISTER LICENSE dans le Guide de référence de
l'administrateur.
3. Enregistrez de nouvelles licences à l'aide de la commande REGISTER LICENSE.
Restriction : Vous ne pouvez pas enregistrer des licences pour IBM Tivoli
Storage Manager for Mail, IBM Tivoli Storage Manager for Databases, IBM
Tivoli Storage Manager for Enterprise Resource Planning et IBM Tivoli Storage
Manager for Space Management.
Sauvegarde de la base de données

Après avoir migré les données, exécutez une sauvegarde complète de la base de
données dès que possible. Sauvegardez également l'historique des volumes.
1. Procédez comme suit :
a. Si vous n'avez pas fait appel à l'assistant de configuration d'instance pour
configurer le serveur, assurez-vous d'avoir effectué les étapes de
configuration manuelle du système pour les sauvegardes de base de
données.
b. Si vous avez utilisé la méthode avec supports et une unité de bande,
supprimez ou extrayez de la bibliothèque la bande qui a été utilisée pour
recevoir les données extraites. Empêchez la réutilisation de la bande tant
AIX ou Linux
que vous n'êtes pas assuré du bon fonctionnement du serveur version 6.3
ou ultérieure et de la nécessité de répéter l'étape d'insertion de la base de
données.
2. Sélectionnez la classe d'unités à utiliser pour les sauvegardes automatiques de
la base de données. A partir de la ligne de commande d'administration Tivoli
Storage Manager, lancez la commande suivante :
set dbrecovery nom_classe_unités
La classe d'unités que vous indiquez sera utilisée par le gestionnaire de base de
données pour toutes les sauvegardes automatiques de la base.
3. Sauvegardez la base de données.
backup db devclass=nom_classe_unités type=full
Vous pouvez spécifier la classe d'unités comme étant identique ou différente de

celle que vous avez indiquée à l'aide de la commande SET DBRECOVERY. S'il
s'agit d'une classe d'unités différente, un message d'avertissement s'affiche, mais
la sauvegarde continue.
4. Sauvegardez l'historique des volumes.
Mise à jour de l'automatisation

Une fois la migration de vos données effectuée, il pourra être nécessaire de
modifier les plannings d'administration définis dans la version des changements
apportés à la syntaxe de commande. Implémentez et vérifiez les changements
apportés à l'automatisation et aux scripts qui nécessitent d'être modifiés dans le
processus de planification.
Important : Assurez-vous que l'automatisation inclut une sauvegarde de la base de

données. Sauvegardez la base de données au moins une fois par jour.
Mise à jour de la configuration des agents de stockage

Une fois la migration de vos données terminée, vérifiez que les données peuvent
être transférées des agents de stockage vers le serveur multimédia z/OS. Si
nécessaire, reconfigurez les agents de stockage pour vous assurer que les données
peuvent être transférées.
Les agents de stockage permettent aux systèmes client d'écrire des données
directement dans et de lire des données directement à partir des périphériques de
stockage connectés au serveur multimédia z/OS. Un agent de stockage installé sur
un système client doit être configuré pour communiquer avec le serveur
multimédia z/OS à l'aide du réseau local.
1. Vérifiez que les données peuvent être transférées de l'agent de stockage vers le
Pour obtenir des informations sur la vérification du transfert de données,
consultez la rubrique Guide d'utilisation de l'agent de stockage.
2. Si vous détectez un problème avec le transfert de données, mettez à jour la
configuration de l'agent de stockage.
Pour obtenir des informations sur la configuration d'un agent de stockage pour
lui donner accès au serveur multimédia z/OS, consultez la rubrique Guide
d'utilisation de l'agent de stockage.
AIX ou Linux
Début des opérations et surveillance des serveurs

Lorsque vous commencez à exécuter le serveur Tivoli Storage Manager version 6.3
ou ultérieure, surveillez l'espace utilisé par celui-ci pour vous assurer que la
quantité d'espace est appropriée. Sur le serveur version 5 sur lequel le serveur
multimédia z/OS est installé, vous pouvez continuer à utiliser les outils z/OS pour
surveiller l'activité sur le système.
Pour surveiller le serveur version 6.3 ou ultérieure et effectuer tous les ajustements
nécessaires, procédez comme suit :
1. Surveillez le journal actif afin de vous assurer que la taille est suffisante pour la
charge de travail gérée par l'instance de serveur.
Lorsque la charge de travail du serveur est proche du niveau généralement
attendu, et que l'espace utilisé par le journal actif représente entre 80 et 90 % de
l'espace disponible pour le répertoire du journal actif. Il se peut que vous soyez
obliger d'augmenter l'espace. La nécessité d'augmenter l'espace dépend des
types de transactions dans la charge de travail du serveur. Les caractéristiques
de transaction affectent le mode d'utilisation de l'espace dédié au journal actif.
Les caractéristiques de transaction suivantes peuvent affecter l'utilisation de
l'espace dans le journal actif :
v Nombre et taille des fichiers dans les opérations de sauvegarde
– Les clients, tels que les serveurs de fichiers qui sauvegardent un grand
nombre de petits fichiers peuvent générer un grand nombre de
transactions qui s'achèvent rapidement. Ces transactions peuvent utiliser
une grande quantité d'espace dans le journal actif, mais pour une courte
période.
– Les clients tels qu'un serveur de messagerie ou un serveur de base de
données qui sauvegardent des blocs importants de données dans un petit
nombre de transactions peuvent générer de petits nombres de transactions
dont l'exécution est longue. Il se peut que les transactions utilisent une
petite quantité d'espace dans le journal actif mais pendant une longue
période.
v Types de connexion réseau
réseau rapides accélèrent l'exécution des transactions. Les transactions
utilisent l'espace du journal actif pendant une période de temps plus
courte.
relativement plus lentes génèrent des transactions dont l'exécution est plus
longue. Les transactions utilisent l'espace du journal actif pendant une
période de temps plus longue.
Si le serveur gère des transactions ayant des caractéristiques très diverses,
l'espace utilisé pour le journal actif peut croître ou décroître fortement au cours
du temps. Pour un tel serveur, il peut être nécessaire de s'assurer qu'un
pourcentage généralement moins important de l'espace du journal actif est
utilisé. L'espace supplémentaire permet au journal actif de s'accroître pour les
transactions dont l'exécution est longue.
2. Surveillez le journal d'archivage pour vous assurer qu'il y a toujours de l'espace
disponible.
A faire : Si le journal d'archivage et le journal de reprise d'archivage

deviennent saturés, il se peut que le journal actif le devienne également, ce qui
peut provoquer l'arrêt du serveur. L'objectif est de créer suffisamment d'espace
AIX ou Linux
disponiblepour le journal d'archivage de sorte qu'il n'utilise jamais toute

l'espace disponible.
Les conditions suivantes peuvent être observées :
a. dans un premier temps, le journal d'archivage croît rapidement lorsqu'une
opération classique de sauvegarde avec des clients se produit;
b. des sauvegardes de base de données sont effectuées régulièrement, en mode
planifié ou manuel;
c. Après des sauvegardes complètes de la base de données, des élagages sont
effectués automatiquement au niveau du journal. L'espace utilisé par le
journal d'archivage décroît lorsque l'élagage se produit.
d. Les opérations des clients se poursuivent normalement et le journal
d'archivage s'accroît également.
e. Des sauvegardes de base de données sont effectuées régulièrement et des
suppressions ont lieu dans le journal chaque fois qu'une sauvegarde de base
de données intégrale est exécutée.
Dans ces conditions, le journal d'archivage s'accroît dans un premier temps,
puis décroît pour, éventuellement, croître à nouveau. Pendant une période, au
fur et à mesure que les opérations normales se poursuivent, la quantité
d'espace utilisée par le journal d'archivage devrait arriver à se stabiliser.
Si le journal d'archivage continue à croître, effectuez l'une des actions
ci-dessous ou les deux :
v ajoutez de l'espace au journal d'archivage. Il se peut qu'un transfert du
journal d'archivage vers un système de fichiers différent soit nécessaire.
Pour plus d'informations sur le transfert du journal d'archivage, voir le
document Guide d'administration.
v Augmentez la fréquence des sauvegardes intégrales de la base de données
afin que l'élagage du journal se produise le plus souvent.
3. Si vous avez difini un répertoire pour le journal de reprise d'archivage,
déterminez si des journaux sont enregistrées dans ce répertoire pendant les
opérations normales. Si l'espace du journal de reprise est utilisé, augmentez la
taille du journal d'archivage. L'objectif est d'utiliser le journal de reprise
d'archivage uniquement dans des conditions inhabituelles, et non dans des
opérations normales.
Après la migration, vous pouvez continuer à utiliser les outils z/OS pour
surveiller l'activité sur le système version 5 sur lequel le serveur multimédia z/OS
s'exécute.
Pour obtenir des informations sur la surveillance de l'activité sur le système

version 5, consultez la section relative à la surveillance du serveur dans un
système s'exécutant sous z/OS. Ces informations se trouvent dans le centre de
documentation de Tivoli Storage Manager version 5.5 disponible à l'adresse
http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/index.jsp.
Si vous utilisez le client d'administration Tivoli Storage Manager V5 TSO, vous

souhaiterez peut-être passer à un nouveau client d'administration. Vous pouvez
adapter vos outils z/OS pour utiliser le client d'administration z/OS UNIX System
Services (USS) 6.1.4. Le client d'administration USS 6.1.4 de z/OS n'est pas
disponible au téléchargement sur le site FTP client, mais peut être obtenu en
commandant les groupes de correctifs suivants :
v UK62472 pour le client de sauvegarde-archivage USS
v UK62473 pour le client d'interface de programme d'application USS
AIX ou Linux
Pour de plus amples informations sur la commande de groupes de correctifs,

consultez le site Web IBM Passport Advantage à l'adresse http://www.ibm.com/
software/lotus/passportadvantage/.
Migration des données depuis les volumes multimédia z/OS vers

d'autres périphériques
Après la migration, les données peuvent être déplacées des volumes multimédia
z/OS vers d'autres périphériques.
Pour déplacer des données depuis les volumes multimédia z/OS vers d'autres
périphériques, utilisez l'une des méthodes suivantes :
v Dirigez les nouvelles données entrantes vers les pools de stockage sur le système
AIX ou Linux on System z. Permettez ensuite aux données existantes, stockées
sur le système z/OS, d'expirer de manière naturelle.
v Déplacez activement les données depuis les volumes multimédia z/OS vers les
pools de stockage situés sur le système AIX ou Linux on System z. Pour
déplacer les données, utilisez la commande MOVE DATA ou MOVE NODEDATA.
Pour plus d'informations sur les commandes MOVE DATA et MOVE NODEDATA, voir le
Chapitre 24. Identification et résolution des problèmes liés à
la migration d'un serveur version 5 à partir d'un système z/OS
vers AIX ou Linux on System z
Lisez cette section pour obtenir des astuces sur l'identification et la résolution des
problèmes communs pouvant se produire après la migration. Une procédure
indiquant comment restaurer la version précédente du serveur est également
incluse.
Restauration du serveur version 5 s'exécutant sous z/OS après une

migration
Si vous devez rétablir le serveur IBM Tivoli Storage Manager à une version
précédente après la migration, vous devez posséder une sauvegarde complète de la
base de données effectuée à partir du système version 5. En outre, vous devez
disposer du support d'installation du serveur de la version d'origine et des fichiers
de configuration de clés. En suivant scrupuleusement les étapes de préparation
avant la mise à niveau du serveur, il est possible de restaurer la version précédente
en limitant au minimum la perte de données.
Le serveur version 5 s'exécutant sous z/OS peut être remis en production à

n'importe quel point du chemin de migration. En fonction de la progression,
différentes actions sont requises pour restaurer le serveur d'origine :
v Pour restaurer le serveur version 5 avant le transfert des données vers le
système version 6.3 ou ultérieure, consultez la rubrique «Restauration du serveur
version 5 avant le transfert des données vers le serveur version 6.3 ou
ultérieure».
v Pour restaurer le serveur version 5 avant la suppression des volumes DISK ou
FILE, consultez la rubrique «Restauration du serveur version 5 avant la
suppression des volumes».
v Pour restaurer le serveur version 5 après la suppression de la base de données
d'origine, consultez la rubrique «Restauration du serveur version 5 après la
suppression de la base de données d'origine», à la page 556.
Restauration du serveur version 5 avant le transfert des

données vers le serveur version 6.3 ou ultérieure
Si vous avez effectué les étapes de préparation de la migration, mais que vous
n'avez pas transféré les données, vous pouvez restaurer le système version 5. Vous
devez redémarrer le serveur z/OS et mettre à jour les volumes pertinents.
1. Redémarrez le serveur version 5 s'exécutant sur le système z/OS.
2. Modifiez l'état d'accès des volumes DISK et FILE de détruit à READWRITE.
Restauration du serveur version 5 avant la suppression des

volumes
Si vous avez effectué les étapes de préparation de la migration, mais que vous
n'avez pas supprimé les volumes DISK ou FILE, vous pouvez restaurer le serveur
version 5 en procédant de la manière suivante.
1. Redémarrez le serveur version 5 s'exécutant sur le système z/OS.
2. Modifiez l'état d'accès des volumes DISK et FILE de détruit à READWRITE.
Identification et résolution des problèmes de la migration
Restauration du serveur version 5 après la suppression de la

base de données d'origine
Pour restaurer le serveur version 5 après la suppression de la base de données,
vous devez restaurer la base de données version 5 à partir de ses copies de
sauvegarde. Après la restauration de la base de données, il peut être nécessaire de
restaurer le contenu des volumes DISK et FILE.
Vous devez disposer des éléments suivants de la version antérieure du serveur :

v Sauvegarde de la base de données du serveur
Conseil : Le paramètre REUSEDELAY permet de rallonger la durée d'attente avant la

restauration du serveur version 5 d'origine, s'exécutant sur un système z/OS. Pour
rallonger la durée, indiquez le paramètre REUSEDELAY pour tous les pools de
stockage à accès séquentiel durant la phase de préparation. Indiquez le paramètre
avant la sauvegarde finale de la base de données et le début de la migration.
Pour de plus amples informations sur la configuration du paramètre REUSEDELAY,

consultez la rubrique «Modification du serveur avant la migration», à la page 521.
Restriction : Les fichiers sauvegardés ou archivés sur le serveur après la migration

du serveur vers le système version 6.3 ou ultérieure seront perdus si le serveur est
restauré à la version 5. Vous ne pouvez pas utiliser les commandes EXPORT ou
IMPORT pour restaurer ces fichiers, car les données d'exportation de la version 6.3
ou ultérieure ne peuvent pas être importées par un serveur version 5.
Etapes de restauration de la version antérieure du serveur

Pour rétablir la version du serveur précédente, procédez comme suit :
1. Sauvegardez la base de données version 6.3 ou ultérieure ainsi que le contenu
du répertoire d'instance, y compris le fichier historique des volumes, le fichier
de configuration d'unité et le fichier d'options du serveur. Conservez ces
fichiers au cas où vous deviez rétablir le serveur version 6.3 ou ultérieure.
2. Supprimez la base de données du gestionnaire de base de données, puis
supprimez les répertoires de la base de données et du journal de reprise.
a. Supprimez manuellement la base de données. Exécutez la commande
suivante :
Vous pouvez également utiliser la commande suivante pour supprimer la
base de données :
db2 drop db tsmdb1
b. Si vous devez réutiliser l'espace occupé par les répertoires de la base de
données et du journal de reprise, vous pouvez maintenant supprimer ces
répertoires.
3. Utilisez le programme d'installation pour désinstaller le serveur version 6.3 ou
ultérieure. La désinstallation supprime le serveur et le gestionnaire de base de
données avec leurs répertoires respectifs.
Pour plus de détails, voir la section décrivant la désinstallation de Tivoli
Storage Manager dans le Guide d'installation.
4. Réinstallez la version du programme du serveur que vous avez utilisé avant
la mise à niveau vers la version 6.3 ou ultérieure. Cette version doit
correspondre à celle exécutée par le serveur lorsque vous avez créé la

sauvegarde de la base de données que vous allez restaurer à une étape
suivante.
Par exemple, si le serveur était au niveau de version 5.5.6.0 avant la mise à
niveau et que vous prévoyez d'utiliser la sauvegarde de la base de données
employée sur ce serveur, vous devez installer le programme du serveur
version 5.5.0.0, puis le correctif version 5.5.6.0 pour pouvoir restaurer la
a. Réinstallez la version de base du serveur qui était utilisée avant la mise à
niveau vers la version 6.3 ou ultérieure.
b. Réinstallez tous les groupes de correctifs qui étaient installés sur le serveur
de base de version antérieure à la mise à niveau vers la version 6.3 ou
ultérieure.
5. Copiez les fichiers suivants dans le répertoire pour obtenir des informations
de serveur :
6. Formatez la base de données à l'aide de l'utilitaire DSMSERV FORMAT. Pour
de plus amples informations, consultez les informations relatives à la version
du serveur que vous réinstallez. Les informations de la version 5.5 sont
disponibles dans le centre de documentation suivant : http://
publib.boulder.ibm.com/infocenter/tivihelp/v1r1
Des informations relatives aux versions 5.4 et 5.3 sont disponibles dans le
même centre de documentation. Faites défiler le contenu du panneau de
navigation et développez la section Previous versions.
7. Restaurez la base de données en utilisant la sauvegarde créée au cours des
étapes de préparation avant la mise à niveau.
8. Si vous avez activé le dédoublonnage de données pour des pools de stockage
de type FILE qui existaient avant la mise à niveau ou si vous avez transféré
les données qui existaient avant la mise à niveau vers de nouveaux pools de
stockage lors de l'utilisation du serveur version 6.3 ou ultérieure, vous devez
effectuer des étapes de reprise supplémentaires. Voir «Etapes de reprise
supplémentaires si vous avez créé des pools de stockage ou activé le
dédoublonnage des données», à la page 558.
9. Si le paramètre REUSEDELAY dans les pools de stockage a une valeur inférieure
à l'âge de la base de données que vous avez restaurée, restaurez les volumes
contenus dans les pools de stockage à accès séquentiel qui étaient récupérés
après la sauvegarde de la base de données. Utilisez la commande RESTORE
VOLUME.
Si vous ne disposez pas d'une sauvegarde d'un pool de stockage, soumettez
les volumes récupérés à un audit à l'aide de la commande AUDIT VOLUME
associée au paramètre FIX=YES en vue de résoudre les incohérences. Utilisez
la commande :
audit volume nom_volume fix=yes
10. Si les opérations de sauvegarde ou d'archivage du client ont été effectuées via
la version 6.3 ou ultérieure du serveur, vous pouvez être amené à effectuer un
audit sur les volumes du pool de stockage sur lesquels les données ont été
stockées.
11. Si vous utilisez des pools de données actives avant la mise à niveau vers la
version 6.3 ou ultérieure, vous devez les recréer.
Chapitre 24. Identification et résolution des problèmes 557

La durée nécessaire à cette opération peut être importante, suivant le nombre

et la taille des pools de données actives à recréer.
Etapes de reprise supplémentaires si vous avez créé des pools

de stockage ou activé le dédoublonnage des données
Si vous avez créé des pools de stockage, activé le dédoublonnage de données sur
des pools de stockage de type FILE ou effectué ces deux opérations alors que votre
serveur s'exécutait à la version 6.3 ou ultérieure, vous devez exécuter des étapes
supplémentaires afin de rétablir le serveur à sa version antérieure.
Utilisez ces informations si vous avez effectué l'une ou les deux opérations
suivantes alors que votre serveur s'exécutait en tant que serveur version 6.3 ou
ultérieure :
v Vous avez activé le dédoublonnage de données pour tous les pools de stockage
qui existaient avant le mise à niveau vers la version 6.3 ou ultérieure. Le
dédoublonnage de données s'applique uniquement aux pools de stockage
utilisant une unité de type FILE.
v Vous avez créé des pools de stockage principaux après la mise à niveau et
transféré vers les nouveaux pools de stockage des données qui ont été stockées
dans d'autres pools de stockage.
Une fois le serveur restauré sur la version 5, procédez comme suit.

v Pour chaque pool de stockage pour lequel vous avez activé la fonction de
dédoublonnage de données, restaurez-le dans son intégralité au moyen de la
commande RESTORE STGPOOL. Pour effectuer cette tâche vous devez disposer
d'une sauvegarde complète du pool de stockage, laquelle doit avoir été créée
v Pour les pools de stockage que vous avez créés après la mise à niveau, consultez
les informations suivantes pour déterminer l'action à exécuter.
Les données qui ont été transférées des pools de stockage existants version 5
vers les nouveaux pools de stockage peuvent être perdues car les nouveaux
pools n'existent plus sur votre serveur version 5 restauré. La reprise possible
dépend du type du pool de stockage :
– Si des données ont été transférées des pools de stockage de type DISK version
5 vers un nouveau pool de stockage, l'espace occupé par ces données a
probablement été réutilisé. Vous devez ainsi restaurer les pools de stockage
version 5 d'origine en utilisant les sauvegardes de pools de stockage créées
Si aucune donnée n'a été transférée de pools de stockage de type DISK version
5 vers un nouveau pool de stockage, auditez les volumes de pool de stockage
dans ces pools de type DISK.
– Si les données ont été déplacées des pools de stockage à accès séquentiel
version 5 vers un nouveau pool de stockage, il est possible que ces données
aient été conservées et qu'elles soient utilisables dans les volumes de pool de
stockage du serveur version 5 restauré. Les données peuvent être utilisables si
le paramètre REUSEDELAY du pool de stockage a été défini sur une valeur qui a
empêché la récupération alors que le serveur s'exécutait sous la version 6.3 ou
ultérieure. Si des volumes ont été récupérés alors que le serveur s'exécutait en
tant que serveur version 6.3 ou ultérieure, ceux-ci doivent être restaurés
depuis les sauvegardes de pool de stockage créées avant la mise à niveau vers
la version 6.3 ou ultérieure.
Partie 4. Annexes

Annexe A. Utilitaires, scripts et commandes pour la mise à
niveau de serveur et la migration
Les utilitaires et les commandes sont disponibles pour effectuer une mise à niveau
ou une migration d'un serveur version 5 sur la version 6.3 ou ultérieure. Un script
est disponible pour démarrer plusieurs serveurs.
DSMUPGRD QUERYDB (affichage d'informations sur une base de

données version 5)
Utilisez l'utilitaire DSMUPGRD QUERYDB pour afficher les informations sur le journal de
base de données et de récupération pour un serveur étant sur une version
antérieure à V6.3. Ces informations permettent d'estimer la quantité d'espace de
stockage nécessaire à la base de données et au journal de reprise une fois le
serveur mis à niveau à la version 6.3 ou ultérieure.
Syntaxe
-k Server1
DSMUPGRD QUERYDB
-quiet -o fichier_options -k nom_clé
Paramètres
AIX HPUX Linux Solaris z/OS -quiet
Indique que les messages à la console sont supprimés. Ce paramètre est
facultatif.
-ofichier_options
Indique un fichier d'options à utiliser. Ce paramètre est facultatif.
Windows -k nom_clé
Indique le nom de la clé de registre Windows d'où extraire les informations sur
le serveur. La valeur par défaut est SERVER1. Ce paramètre est facultatif.
Exemples
Procurez-vous des informations sur la base de données :

dsmupgrd querydb
DSMUPGRD PREPAREDB (préparation d'une base de données version

5 pour la mise à niveau)
L'utilitaire DSMUPGRD PREPAREDB permet de préparer une base de données de
serveur à se mettre à niveau sur la version 6.3 ou ultérieure. Vous devez l'exécuter
avant de lancer l'utilitaire DSMUPGRD EXTRACTDB.
Syntaxe
-k Server1
DSMUPGRD

PREPAREDB MEDIASERVER-=-media_server_name
Paramètres
facultatif.
-ofichier_options
Windows -k nom_clé
z/OS MEDIASERVER
Désigne le nom du serveur devant être utilisé comme serveur multimédia
z/OS. Le serveur doit avoir été défini à l'aide de la commande DEFINE SERVER
avant d'utiliser l'utilitaire DSMUPGRD PREPAREDB.
Exemple
dsmupgrd preparedb
DELETE VOLHISTORY (Suppression des données de l'historique des

volumes séquentiels)
z/OS
La commande DELETE VOLHISTORY permet de supprimer les enregistrements de

fichiers historiques de volumes qui ne sont plus nécessaires (par exemple,
enregistrements pour des volumes de sauvegardes de bases de données désuets).
Lors d'une migration de z/OS vers AIX ou Linux sur System z, émettez cette
commande sur le serveur version 5 pour indiquer la classe d'unité des volumes
devant être supprimés pour préparer la migration.
Lorsque vous supprimez des enregistrements pour des volumes qui ne sont pas
dans des pools de stockage (par exemple, sauvegardes de base de données ou
volumes d'exportation), les volumes reprennent le statut de volumes utilisables
même si IBM Tivoli Storage Manager les a acquis en tant que volumes privés. Les
volumes utilisables dont le type d'unité est FILE sont supprimés. Lorsque vous
supprimez des enregistrements pour des volumes de pools de stockage, les
volumes restent dans la base de données Tivoli Storage Manager. Lorsque vous
supprimez des enregistrements pour des objets fichiers de plan de reprise à partir
d'un serveur source, les objets sur le serveur cible sont marqués pour être
supprimés.
La commande DELETE BACKUPSET vous permet de supprimer des données de

volumes de groupes de sauvegarde spécifiées dans le fichier historique de
volumes. N'utilisez pas la commande DELETE VOLHISTORY pour supprimer des
données de volumes de groupes de sauvegarde dans le fichier historique de
volumes.
Pour les utilisateurs de DRM, le délai d'expiration des sauvegardes de base de

données devra être contrôlé avec la commande SET DRMDBBACKUPEXPIREDAYS et non
pas avec la commande DELETE VOLHISTORY. L'utilisation de la commande DELETE
VOLHISTORY supprime l'enregistrement de Tivoli Storage Manager du volume. Cela
peut provoquer la perte de volumes qui étaient gérés par la commande MOVE
DRMEDIA. Le moyen classique de gérer le délai d'expiration automatique de volumes
de sauvegardes de la base de données DRM est d'utiliser la commande SET
DRMDBBACKUPEXPIREDAYS.
La commande DELETE VOLHISTORY peut être utilisée pour définir la classe d'unités
des volumes devant être supprimés en vue de la migration. Cette commande peut
être utilisée avant la migration d'un serveur Tivoli Storage Manager version 5
exécuté sous z/OS vers un serveur version 6 exécuté sous AIX ou Linux sur
System Z. La class d'unités doit présenter un type d'unité FILE et peut être définie
uniquement si le paramètre ZMSPREPARE est défini sur YES.
Remarques :
1. Les volumes pour la dernière série de sauvegardes de base de données ne sont
pas supprimés.
2. Les fichiers historiques de volumes existants ne sont pas mis à jour
automatiquement avec cette commande.
3. Vous pouvez utiliser la commande DEFINE SCHEDULE pour effacer de manière
périodique les enregistrements d'historiques de volumes.
Classe de privilèges
Pour émettre cette commande, vous devez disposer d'un privilège système.
Syntaxe
TOTime = 23:59:59
DELete VOLHistory TODate = date
TOTime = heure
Type = All
DBBackup
DEVclass = nom_classe
DBSnapshot
DEVclass = nom_classe
DBDump
DBRpf
EXPort
DELETELatest = No
RPFile
DELETELatest = No
Yes
DELETELatest = No
RPFSnapshot
DELETELatest = No
Yes
STGNew
STGReuse
STGDelete
Annexe A. Utilitaires, scripts et commandes 563

No
ZMSPREPARE = Yes DEVClass = class_name
Paramètres
TODate (obligatoire)
Désigne la date à utiliser pour sélectionner les données d'historiques de
volumes séquentiels à supprimer. Tivoli Storage Manager supprime
uniquement les enregistrements créés à la date indiquée ou avant cette date.
Vous pouvez définir cette date à l'aide de l'une des valeurs suivantes :
Valeur Description Exemple

MM/JJ/AAAA Une date spécifique 23/01/1999
TODAY La date du jour TODAY
TODAY-jours ou La date actuelle, moins le TODAY–30 ou –30.
-jours nombre de jours indiqué. Le
nombre maximal de jours Pour supprimer les enregistrements
admis est 9999. qui ont 30 jours ou plus, vous pouvez
entrer TODAY-30 ou simplement -30.
TOTime
Indique que vous voulez supprimer les enregistrements créés à la date
indiquée, à l'heure ou avant l'heure spécifiée. Ce paramètre est facultatif. La
valeur par défaut est la fin de la journée (23:59:59). Vous pouvez définir cette
heure à l'aide de l'une des valeurs suivantes :
Valeur Description Exemple

HH:MM:SS Une heure spécifique à la date 12:30:22
indiquée
NOW L'heure actuelle à la date NOW
indiquée
NOW+HH:MM ou L'heure actuelle plus les NOW+03:00 ou +03:00.
+HH:MM heures et les minutes à la date
indiquée. Si vous lancez la commande DELETE
VOLHISTORY à 9h00 avec
TOTIME=NOW+03:00 ou
TOTIME=+03:00, Tivoli Storage
Manager supprime les
enregistrements créés à 12h00 ou plus
tôt à la date indiquée.
NOW-HH:MM ou L'heure actuelle moins les NOW-03:30 ou -03:30.
-HH:MM heures et les minutes à la date
indiquée. Si vous lancez la commande DELETE
VOLHISTORY à 9h00 avec
TOTIME=NOW-3:30 ou
TOTIME=-3:30, Tivoli Storage
Manager supprime les
enregistrements créés à 5h30 ou plus
tôt à la date indiquée.
Type (obligatoire)
Désigne le type d'enregistrement, répondant également aux critères de date et
d'heure, à supprimer du fichier historique de volumes. Les valeurs admises
sont les suivantes :
All
Indique que tous les enregistrements doivent être supprimés.
Remarque : La commande DELETE VOLHISTORY ne supprime pas les

enregistrements de volumes distants.
DBBackup
Indique que doivent être supprimés uniquement les enregistrements
contenant des données sur les volumes utilisés pour les sauvegardes
incrémentales et intégrales de la base de données, c'est-à-dire avec des
types de volumes BACKUPFULL et BACKUPINCR, répondant aux critères
de date et d'heure indiquées. Les dernières séries de sauvegardes
incrémentielles et intégrales de la base de données ne sont pas supprimées.
DEVclass=nom_classe
Désigne le nom de la classe d'unités utilisée pour créer les sauvegardes
de la base de données. Ce paramètre facultatif peut être utilisé pour
supprimer les sauvegardes de la base de données créées en utilisant la
classe d'unités de volumes virtuels de serveur à serveur. Le type de la
classe d'unités doit être SERVER. Ce paramètre peut être utilisé
seulement pour supprimer des entrées d'historiques de volumes de
types BACKUPFULL, BACKUPINCR, ou DBSNAPSHOT.
Un volume de sauvegardes intégrales, incrémentales ou instantanées
de la base de données peut être supprimé si toutes les conditions qui
suivent sont réunies :
v La classe d'unités utilisée pour créer le volume de sauvegardes de la
base de données doit être identique à la classe d'unités spécifiée.
v Le volume a été créé avant ou à l'heure et à la date indiquées.
v Le volume n'appartient pas à la dernière série de sauvegardes
intégrales et incrémentales de la base de données si le type de
volume spécifié est DBBackup, ou à la série de sauvegardes
instantanées de la base de données si le type de volume est
DBSnapshot.
DBSnapshot
Indique qu'il faut supprimer uniquement les enregistrements contenant des
données sur les volumes utilisés pour les sauvegardes instantanées de la
base de données, et répondant aux critères d'heure et de date indiquées. La
dernière sauvegarde instantanée de la base de données n'est pas
supprimée.
DEVclass=nomclasse
Désigne le nom de la classe d'unités utilisée pour créer les sauvegardes
de la base de données. Ce paramètre facultatif peut être utilisé pour
supprimer les sauvegardes de la base de données créées en utilisant la
classe d'unités de volumes virtuels de serveur à serveur. Le type de la
classe d'unités doit être SERVER. Ce paramètre peut être utilisé
seulement pour supprimer des entrées d'historiques de volumes de
types BACKUPFULL, BACKUPINCR, ou DBSNAPSHOT.
Un volume de sauvegardes intégrales, incrémentales ou instantanées
de la base de données peut être supprimé si toutes les conditions qui
suivent sont réunies :
v La classe d'unités utilisée pour créer le volume de sauvegardes de la
base de données doit être identique à la classe d'unités spécifiée.
v Le volume a été créé avant ou à l'heure et à la date indiquées.

v Le volume n'appartient pas à la dernière série de sauvegardes
intégrales et incrémentales de la base de données si le type de
volume spécifié est DBBackup, ou à la série de sauvegardes
instantanées de la base de données si le type de volume est
DBSnapshot.
DBRpf
données sur les volumes de sauvegardes intégrales et incrémentielles de la
base de données et sur les volumes de fichiers de plan de reprise.
EXPort
Indique que seuls les enregistrements contenant des données sur les
volumes d'exportation doivent être supprimés.
RPFile
données sur les objets fichiers de plan de reprise stockés sur un serveur
cible et répondant aux critères de date et d'heure indiquées.
DELETELatest
Indique si le dernier fichier de plan de reprise peut être ou non
supprimé. Ce paramètre facultatif peut être utilisé pour supprimer les
derniers fichiers de plan de reprise créés avec une classe d'unités de
volumes virtuels de serveur à serveur.
Ce paramètre peut être utilisé seulement pour supprimer les entrées
d'historiques de volumes de type RPFILE (par exemple, les fichiers de
plan de reprise créés en utilisant le paramètre DEVCLASS avec la
commande PREPARE). Si ce paramètre n'est pas spécifié, les dernières
entrées RPFILE ne sont pas supprimées.
No Indique que le dernier fichier RPFILE ne sera pas supprimé.
Yes Indique que le dernier fichier RPFILE sera supprimé s'il répond
aux critères de date et d'heure indiqués.
RPFSnapshot
données sur les fichiers de plan de reprise créés dans l'hypothèse de
sauvegardes de la base de données, lesquels sont stockés sur un serveur
cible et répondent aux critères de date et d'heure indiquées. Le dernier
fichier RPFSNAPSHOT n'est pas supprimé sauf s'il répond aux critères de date
et d'heure. La valeur affectée au paramètre DELETELATEST est Yes.
DELETELatest
Indique si le dernier fichier de plan de reprise peut être ou non
supprimé. Ce paramètre facultatif peut être utilisé pour supprimer les
derniers fichiers de plan de reprise créés avec une classe d'unités de
volumes virtuels de serveur à serveur.
Ce paramètre peut être utilisé seulement pour supprimer les entrées
d'historiques de volumes de type RPFSNAPSHOT (par exemple, les
fichiers de plan de reprise créés en utilisant le paramètre DEVCLASS avec
la commande PREPARE). Si ce paramètre n'est pas spécifié, les dernières
entrées RPFSNAPSHOT ne seront pas supprimées.
No Indique que le dernier fichier RPFSNAPSHOT ne sera pas
supprimé.
Yes Indique que le dernier fichier RPFSNAPSHOT sera supprimé s'il
répond aux critères de date et d'heure indiquées.
STGNew
données sur les nouveaux volumes de stockage à accès séquentiel.
STGReuse
données sur les volumes des pools de stockage séquentiels réutilisés.
STGDelete
données sur les volumes de pools de stockage séquentiels supprimés.
ZMSPREPARE
Indique si la commande DELETE VOLHISTORY est utilisée pour supprimer les
volumes séquentiels stockés dans une classes d'unités FILE. La suppression
s'effectue avant de migrer un serveur version 5 Tivoli Storage Manager exécuté
sur z/OS vers un serveur version 6 exécuté sous AIX ou Linux sur System z.
No Indique que la commande DELETE VOLHISTORY n'est pas utilisée pour
préparer une migration. Il s'agit de l'option par défaut.
Yes
Indique que la commande DELETE VOLHISTORY est utilisée pour préparer
une migration.
DEVclass=nom_classe
Désigne le nom de la classe d'unités utilisée pour créer les volumes
supprimés. Le type de classe d'unités doit être FILE.
Exemple : Suppression des informations du fichier de plan de

reprise
Supprimez toutes les données des fichiers de plan de reprise créés le 28/03/2005
ou avant cette date.
delete volhistory type=rpfile todate=03/28/2005
DSMUPGRD EXTRACTDB (extraction de données à partir de la base de

données d'un serveur version 5)
L'utilitaire DSMUPGRD EXTRACTDB permet d'extraire des données depuis une base de
données de serveur. Les données peuvent être insérées dans une base de données
du serveur version 6.3 ou ultérieure dès qu'elles ont été extraites ou plus tard.
Condition prérequise
Avant de faire appel à cet utilitaire, lancez l'utilitaire DSMUPGRD PREPAREDB sur la
base de données existante.
Syntaxe
-k Server1
DSMUPGRD
EXTRACTDB A : Extraction vers des supports

B : Extraction et transmission via un réseau

EVentbasedused = Yes

EVentbasedused = Never
A : Extraction vers des supports :
DEVclass = nom_classe_unité MANifest = nom_fichier
SCRatch = Yes

SCRatch = Yes ,
No (1)
VOLumenames = nom_volume
B : Extraction et transmission via un réseau :
HLAddress = adresse_IP LLAddress = port_TCP
Remarques :
1 Vous devez spécifier l'option VOLUMENAMES si SCRATCH=NO est indiqué.
Paramètres
facultatif.
-ofichier_options
Windows -k nom_clé
DEVclass
Indique la classe d'unités à accès séquentiel à utiliser pour stocker les données
extraites. Ce paramètre est obligatoire si vous voulez extraire la base de
données vers des supports.
Restriction : Vous ne pouvez pas utiliser une classe d'unités avec une unité de
type NAS ou CENTERA.
Restriction : z/OS Pour un serveur Tivoli Storage Manager exécuté sur un

système z/OS, vous ne pouvez pas utiliser une classe d'unités avec une unité
de type FILE.
MANifest
Indique l'emplacement du fichier manifeste. Utilisez un nom qualifié complet
du fichier ou placez-le dans un répertoire local. Par exemple : ./manifest.txt
Ce paramètre est obligatoire si vous voulez extraire la base de données vers
des supports.
EVentbasedused
Indique si la conservation de l'archivage fondée sur un événement a été utilisée
sur le serveur. Cette fonction permet de fonder la conservation d'un objet
archivé sur un événement externe. La valeur par défaut de ce paramètre est
YES. Les valeurs possible sont les suivantes :
Yes
Indique que la conservation de l'archivage fondée sur un événement a été
utilisée sur le serveur. Sa valeur par défaut est YES. Si vous ne savez pas
précisément ce qu'il en est, acceptez la valeur par défaut.
Le remplacement de la valeur par défaut peut causer l'expiration
prématurée des objets d'archivage après la mise à niveau si la conservation
des archives basées sur des événements a été utilisée. L'utilisation de la
valeur par défaut garantit des résultats corrects.
Never
Indique que la conservation de l'archivage fondée sur un événement n'a
jamais été utilisée sur le serveur.
Avertissement : L'indication de EVENTBASEDUSED=NEVER peut

améliorer les performances de la mise à niveau. Cependant, n'utilisez pas
cette valeur s'il y a une probabilité que la conservation des archives basées
sur des événements ait été utilisée sur le serveur. Si la conservation des
archives basées sur des événements a été utilisée sur le serveur, l'indication
de EVENTBASEDUSED=NEVER peut conduire à l'expiration prématurée
des fichiers d'archivage une fois la mise à niveau effectuée.
SCRatch
Indique si les données peuvent être stockées dans des volumes utilisables. Ce
paramètre est facultatif. La valeur par défaut est YES. Les valeurs admises sont
les suivantes :
Yes
Précise que les volumes utilisables peuvent être utilisés.
Si vous spécifiez SCRATCH=YES et définissez des volumes à l'aide du
paramètre VOLUMENAMES, ces derniers sont utilisés en premier. Les volumes
utilisables ne sont employés que si les volumes indiqués ne comportent
pas un espace suffisant pour contenir les données extraites.
Si le type d'unité de la classe d'unités est FILE, les noms des volumes
utilisables sont générés à partir d'un horodatage.
No Indique que les volumes utilisables ne peuvent pas être utilisés. Si vous
spécifiez cette valeur, vous devez également indiquer les volumes à l'aide
du paramètre VOLUMENAMES.
Si les volumes que vous spécifiez avec le paramètre VOLUMENAMES ne
comportent pas un espace suffisant pour contenir les données extraites, le
processus échoue.
VOLumenames
Indique les volumes à utiliser pour stocker la base de données extraite. Si vous
spécifiez plusieurs volumes, séparez les noms par des virgules, sans insérer
d'espaces.
HLAddress
Indique l'adresse IP numérique ou le nom de domaine du serveur version 6.3
ou ultérieure. Ce paramètre est obligatoire si vous voulez extraire et
transmettre simultanément les données au serveur version 6.3 ou ultérieure via
le réseau.
Si le serveur version 5 et le serveur version 6.3 ou ultérieure se trouvent sur le
même système, vous pouvez indiquer localhost.

LLAddress
Indique l'adresse de bas niveau du serveur version 6.3 ou ultérieure. Cette
adresse est identique à la valeur indiquée avec l'option de serveur TCPPORT
pour le serveur version 6.3 ou ultérieure. Ce paramètre est obligatoire si vous
voulez extraire et transmettre simultanément les données au serveur version
6.3 ou ultérieure via le réseau.
Exemples
Extraction et transmission des données à un serveur via un réseau:

dsmupgrd extractdb hladdress=xyz.company.com lladdress=1555
Extraction et stockage des données sur des supports :

dsmupgrd extractdb devclass=tapeclass manifest=keepthis.txt
Fichier manifeste pour l'extraction des données sur des

supports
Au cours de l'extraction des données sur des supports, l'utilitaire DSMUPGRD crée un
fichier manifeste. Il contient des informations sur les volumes et les classes d'unités
utilisés pour stocker les données extraites.
Le fichier manifeste est requis pour le processus d'insertion des données lorsque
vous utilisez des supports pour transférer la base de données vers le serveur
version 6.3 ou ultérieure. Vous indiquez son nom lors du lancement de l'utilitaire
DSMSERV INSERTDB.
AIX HPUX Linux Solaris Windows Dans le fichier manifeste, la

section sur la configuration des unités contient des informations concernant les
paramètres de configuration de l'unité de serveur source. Vous pouvez modifier les
paramètres, tels que le nom des unités et les numéros des éléments d'unité, avant
d'utiliser le fichier manifeste avec l'utilitaire DSMSERV INSERTDB, en particulier si
l'utilitaire est exécuté sur un autre système.
Le contenu d'un fichier manifeste est similaire à l'exemple suivant :

* Fichier manifeste version 2 pour EXTRACTDB
DEVCLASS=3584L2
STREAMS=1
VOLUMENAMES000=L12345
* Informations sur la configuration d’unité
DEFINE DEVCLASS 3584L2 DEVTYPE=LTO FORMAT=DRIVE MOUNTLIMIT=DRIVES MOUNTWAIT=60
MOUNTRETENTION=60 PREFIX=ADSM LIBRARY=3584L2 WORM=NO DRIVEENCRYPTION=ALLOW
SET SERVERNAME MOKSHA
DEFINE LIBRARY 3584L2 LIBTYPE=SCSI SERIAL="00000002267304AB" SHARED=YES
AUTOLABEL=YES RESETDRIVE=YES
DEFINE DRIVE 3584L2 3584L2_DRV1 ELEMENT=265 ONLINE=Yes WWN="500507630F18BA09"
SERIAL="0007859130"
DEFINE PATH MOKSHA 3584L2 SRCTYPE=SERVER DESTTYPE=LIBRARY DEVICE=/dev/IBMchanger5 ONLINE=YES
DEFINE PATH MOKSHA 3584L2_DRV1 SRCTYPE=SERVER DESTTYPE=DRIVE LIBRARY=3584L2 DEVICE=/dev/IBMtape20 ONLINE=YES
z/OS La section de la configuration d'unité contient des informations sur la

configuration d'unité pour le serveur source. Les instructions de configuration
d'unité sont basées sur les définitions du serveur source, en revanche, les
instructions sont transformées au format requis par un serveur exécuté sous AIX
ou Linux sur System z. La section de la configuration d'unité est configurée pour
utiliser un serveur multimédia z/OS pour l'accès au support.
Un fichier manifeste utilisé pour une mise à niveau sur un système AIX a un
contenu similaire à l'exemple suivant :
DEVCLASS=TAPE3592
STREAMS=1
VOLUMENAMES000=JJY010
/* Configuration d’unité */
DEFINE LIBRARY CARTRIDGE LIBTYPE=ZOSMEDIA
DEFINE DEVCLASS CARTRIDGE DEVTYPE=Cartridge ESTCAPACITY=184320K PREFIX=ADSM
MOUNTLIMIT=5 MOUNTRETENTION=60 MOUNTWAIT=60 UNIT=B81M5C36 COMPRESSION=Yes
PROTECTION=No LIBRARY=CARTRIDGE
DEFINE PATH TUCMVSTT-TSM CARTRIDGE SRCTYPE=SERVER DESTTYPE=LIBRARY
ZOSMEDIASERVER=TUCMVSTT ONLINE=YES
DEFINE DEVCLASS COPYFILEDEV DEVTYPE=File MAXCAPACITY=3144704K PREFIX=SVTSMS1
MOUNTLIMIT=20
DEFINE LIBRARY ECARTRIDGE LIBTYPE=ZOSMEDIA
DEFINE DEVCLASS ECARTRIDGE DEVTYPE=ECartridge ESTCAPACITY=9437184K
PREFIX=ADSM MOUNTLIMIT=2 MOUNTRETENTION=60 MOUNTWAIT=60 UNIT=3590
PROTECTION=No FORMAT=9840-C LIBRARY=ECARTRIDGE
DEFINE PATH TUCMVSTT-TSM ECARTRIDGE SRCTYPE=SERVER DESTTYPE=LIBRARY
DEFINE DEVCLASS FILE DEVTYPE=File MAXCAPACITY=2097152K PREFIX=SVTSMS1
MOUNTLIMIT=20
DEFINE DEVCLASS FROM-POMPEII2-VV DEVTYPE=File MAXCAPACITY=3144704K
PREFIX=SVTSMS1 MOUNTLIMIT=20
DEFINE DEVCLASS POMPEII2-VV DEVTYPE=Server SERVERNAME=POMPEII2
MAXCAPACITY=512000K PREFIX=ADSM MOUNTLIMIT=3 RETRYPERIOD=10 RETRYINTERVAL=30
DEFINE LIBRARY TAPE3592 LIBTYPE=ZOSMEDIA
DEFINE DEVCLASS TAPE3592 DEVTYPE=3592 ESTCAPACITY=314572800K
PREFIX=ADSM MOUNTLIMIT=2 MOUNTRETENTION=5 MOUNTWAIT=5 UNIT=C06M7N03
WORM=No PROTECTION=No RETENTION=30 FORMAT=Drive LIBRARY=TAPE3592
DEFINE PATH TUCMVSTT-TSM TAPE3592 SRCTYPE=SERVER DESTTYPE=LIBRARY
DEFINE LIBRARY 3590 LIBTYPE=ZOSMEDIA
DEFINE DEVCLASS 3590 DEVTYPE=3590 ESTCAPACITY=9437184K PREFIX=ADSM
MOUNTLIMIT=2 MOUNTRETENTION=60 MOUNTWAIT=60 UNIT=3590 COMPRESSION=Yes
PROTECTION=No LIBRARY=3590
DEFINE PATH TUCMVSTT-TSM 3590 SRCTYPE=SERVER DESTTYPE=LIBRARY
DEFINE SERVER POMPEII2 COMMMETHOD=TCPIP HLADDRESS=9.11.124.164
LLADDRESS=1500 NODENAME=TUCMVSTT-TSM PASSWORD=188b4fe70a44686c84d0dfd44b
SERVERPASSWORD=18589b55e788df53d5
DEFINE SERVER PURGE COMMMETHOD=TCPIP HLADDRESS=9.11.124.228 LLADDRESS=1500
SERVERPASSWORD=180fb66e028d
DEFINE SERVER STA_PURGE COMMMETHOD=TCPIP HLADDRESS=9.11.124.228 LLADDRESS=1502
SERVERPASSWORD=18909a64694f303df677
DEFINE SERVER TUCMVSTT COMMMETHOD=TCPIP HLADDRESS=9.11.92.49 LLADDRESS=1559
SERVERPASSWORD=187a747f70fff04180
SET SERVERNAME TUCMVSTT-TSM
SET SERVERPASSWORD 1891a1cefdcaf489d86c66af54
Un fichier manifeste utilisé pour une mise à niveau sur un système Linux sur un
système System z a un contenu similaire à l'exemple suivant :
DEVCLASS=TAPE3490
STREAMS=1
VOLUMENAMES000=D71124,D71121,D71126
/* Configuration d’unité */
DEFINE LIBRARY CARTRIDGE LIBTYPE=ZOSMEDIA
DEFINE DEVCLASS CARTRIDGE DEVTYPE=Cartridge ESTCAPACITY=184320K PREFIX=ADSM
MOUNTLIMIT=2 MOUNTRETENTION=60 MOUNTWAIT=60 UNIT=3480 COMPRESSION=Yes
PROTECTION=No LIBRARY=CARTRIDGE
DEFINE PATH MVSTS CARTRIDGE SRCTYPE=SERVER DESTTYPE=LIBRARY
ZOSMEDIASERVER=TUCMVSTS ONLINE=YES
DEFINE LIBRARY ECARTRIDGE LIBTYPE=ZOSMEDIA
DEFINE DEVCLASS ECARTRIDGE DEVTYPE=ECartridge ESTCAPACITY=9437184K
PREFIX=ADSM MOUNTLIMIT=2 MOUNTRETENTION=60 MOUNTWAIT=60 UNIT=3590
PROTECTION=No FORMAT=9840-C LIBRARY=ECARTRIDGE
DEFINE PATH MVSTS ECARTRIDGE SRCTYPE=SERVER DESTTYPE=LIBRARY
DEFINE DEVCLASS FILE DEVTYPE=File MAXCAPACITY=2097152K PREFIX=SVTSMS2
MOUNTLIMIT=150
DEFINE DEVCLASS FROM-MVSTT DEVTYPE=File MAXCAPACITY=2097152K PREFIX=SVTSMS2
MOUNTLIMIT=100
DEFINE DEVCLASS LONGFN DEVTYPE=File MAXCAPACITY=204800K PREFIX=SVTSMS2
MOUNTLIMIT=20
DEFINE DEVCLASS TAPE3490 DEVTYPE=Cartridge ESTCAPACITY=184320K PREFIX=ADSM
MOUNTLIMIT=200 MOUNTRETENTION=60 MOUNTWAIT=60 UNIT=B81M4C36 COMPRESSION=Yes
PROTECTION=No RETENTION=60 LIBRARY=TAPE3490
DEFINE PATH MVSTS TAPE3490 SRCTYPE=SERVER DESTTYPE=LIBRARY
DEFINE DEVCLASS TAPE3592 DEVTYPE=3592 ESTCAPACITY=314572800K PREFIX=ADSM
MOUNTLIMIT=5 MOUNTRETENTION=2 MOUNTWAIT=60 UNIT=C06M7N03 WORM=No
PROTECTION=No FORMAT=Drive LIBRARY=TAPE3592
DEFINE PATH MVSTS TAPE3592 SRCTYPE=SERVER DESTTYPE=LIBRARY
DEFINE DEVCLASS TO-MVSTT DEVTYPE=Server SERVERNAME=TUCMVSTT
MAXCAPACITY=2097152K PREFIX=ADSM MOUNTLIMIT=50 RETRYPERIOD=10 RETRYINTERVAL=30
DEFINE DEVCLASS 3590 DEVTYPE=3590 ESTCAPACITY=9437184K PREFIX=ADSM MOUNTLIMIT=2
MOUNTRETENTION=60 MOUNTWAIT=60 UNIT=3590 COMPRESSION=Yes PROTECTION=No LIBRARY=3590
DEFINE PATH MVSTS 3590 SRCTYPE=SERVER DESTTYPE=LIBRARY ZOSMEDIASERVER=TUCMVSTS
ONLINE=YES
DEFINE DEVCLASS 3592 DEVTYPE=3592 ESTCAPACITY=314572800K PREFIX=ADSM
PROTECTION=No FORMAT=Drive LIBRARY=3592
DEFINE PATH MVSTS 3592 SRCTYPE=SERVER DESTTYPE=LIBRARY ZOSMEDIASERVER=TUCMVSTS
ONLINE=YES
DEFINE LIBRARY 3592LANFREE LIBTYPE=ZOSMEDIA
DEFINE DEVCLASS 3592LANFREE DEVTYPE=3592 ESTCAPACITY=314572800K PREFIX=ADSM
PROTECTION=No FORMAT=Drive LIBRARY=3592LANFREE
DEFINE PATH MVSTS 3592LANFREE SRCTYPE=SERVER DESTTYPE=LIBRARY
DEFINE SERVER PURGE COMMMETHOD=TCPIP HLADDRESS=purge.storage.tucson.ibm.com
LLADDRESS=1500 SERVERPASSWORD=180fb66e028d

DEFINE SERVER STA_PURGE COMMMETHOD=TCPIP HLADDRESS=purge.storage.tucson.ibm.com
LLADDRESS=1502 SERVERPASSWORD=18909a64694f303df677
DEFINE SERVER TUCMVSTS COMMMETHOD=TCPIP HLADDRESS=9.11.92.48 LLADDRESS=2556
SERVERPASSWORD=184feb8740bb139271
DEFINE SERVER TUCMVSTT COMMMETHOD=TCPIP HLADDRESS=tucmvstt.storage.tucson.ibm.com
LLADDRESS=2533 NODENAME=MVSTS PASSWORD=18bf4d36c185
SET SERVERNAME MVSTS
DSMSERV INSERTDB (Déplacement d'une base de données de serveur vers une
base de données vide)
DSMUPGRD EXTEND DB (extension de la taille de la base de données)

Cet utilitaire permet d'augmenter la taille d'une base de données version 5. Faites
appel à cet utilitaire uniquement lorsqu'une erreur se produit pendant le processus
de mise à niveau, indiquant que vous avez besoin d'augmenter l'espace de base de
données pour que le traitement continue.
L'utilitaire DSMFMT permet de formater un nouveau volume destiné à étendre la

base de données. Pour toute information sur son utilisation, voir le centre de
documentation de la version 5.5 : http://publib.boulder.ibm.com/infocenter/
tivihelp/v1r1
Syntaxe
-k Server1
DSMUPGRD
EXTEND DB nom_volume mégaoctets
Paramètres
facultatif.
AIX HPUX Linux Solaris Windows z/OS -ofichier_options
Windows -k nom_clé
nom_volume (obligatoire)
Indique le nom à utiliser pour le volume d'extension de la nouvelle base de
données.
megabytes (obligaoire)
Indique la taille du nouveau volume en mégaoctets. La taille doit être un
multiple de 4 Mo et être inférieure d'1 Mo à celle du volume indiqué dans le
paramètre nom_volume. Par exemple, si le volume est d'une taille de 5 Mo,
spécifiez une valeur de 4.
DSMUPGRD EXTEND LOG ((augmentez la la taille du journal)
Utilisez cet utilitaire sur un serveur V5 pour augmenter la taille du journal de
reprise lorsque le message ANR9999D LOGSEG a été émis pendant le processus de
mise à niveau, ce qui indique que vous avez besoin d'espace supplémentaire pour
continuer le processus de mise à niveau.
Emettez cette commande si vous recevez un message ANR9999D LOGSEG. Cela

indique que votre espace de journal a été sursollicité et votre service s'arrête avec
une erreur LOGSEG871. Après l'exécution du serveur, vous pouvez procéder
comme suit :
v Sauvegardez la base de données pour libérer de l'espace réservé au journal de
reprise.
v Ajustez la taille du journal de récupération, le pourcentage de déclenchement de
sauvegarde de base de données, ou les deux pour permettre la réussite des
prochaines sauvegardes de base de données.
Utilisez l'utilitaire DSMFMT pour formater un nouveau volume à utiliser pour

l'extension du journal de reprise. Pour toute information sur son utilisation, voir le
centre de documentation de la version 5.5 : http://publib.boulder.ibm.com/
infocenter/tivihelp/v1r1
Syntaxe
-k Server1
DSMUPGRD
EXTEND LOG nom_volume mégaoctets
Paramètres
facultatif.
AIX HPUX Linux Solaris Windows z/OS -ofichier_options
Windows -k nom_clé
nom_volume (obligatoire)
Indique le nom à utiliser pour le nouveau volume d'extension du journal de
reprise
megabytes (obligaoire)
Indique la taille du nouveau volume en mégaoctets. La taille doit être un
multiple de 4 Mo et être inférieure d'1 Mo à celle du volume indiqué dans le
paramètre nom_volume. Par exemple, si le volume est d'une taille de 5 Mo,
spécifiez une valeur de 4.

DSMUPGRD UPDATE (Création d'entrées de registre pour une instance
de serveur version 5)
Windows
Cet utilitaire permet de créer des entrées de registre pour une instance de serveur
version V5 si des entrées de registre toujours requises ont été supprimées
accidentellement pendant le processus de mis à niveau. Par exemple, vous pouvez
recourir à cet utilitaire si vous mettez un serveur version 5 à niveau vers un
serveur version 6.3 ou ultérieure sur un même système et exécutez
accidentellement l'utilitaire DSMSERV LOADFORMAT avant l'utilitaire DSMUPGRD
PREPAREDB.
Exécutez cet utilitaire à partir du répertoire d'instance pour la base de données

version 5 (dans laquelle des fichiers comme dsmserv.dsk sont stockés pour le
serveur). L'utilitaire recrée les entrées de registre initiales pour le serveur version 5
mais les enregistre à un emplacement de sauvegarde pour ne pas remplacer les
entrées qui ont été ajoutées par la version 6.3 ou ultérieure.
Syntaxe
-k Server1
DSMUPGRD UPDATE
-k nom_clé
Paramètres
-k nom_clé
Indique le nom de la clé de registre Windows dans laquelle doivent être
stockées les informations sur le serveur. La valeur par défaut est Server1.
Exemple
Exécutez l'utilitaire pour recréer des entrées de registre pour l'instance de serveur,
Server2.
"c:\Program Files\Tivoli\TSM\upgrade\dsmupgrd" -k server2 update

L'utilitaire DSMSERV LOADFORMAT permet de formater une base de données vide sur
le serveur version 6.3 ou ultérieure lors de la préparation de l'insertion de données
à partir d'une base de données version 5 extraite.
Affectez à la variable d'environnement système DB2CODEPAGE la valeur 819 pour

chaque instance de serveur. Avant de lancer la commande DSMSERV LOADFORMAT,
connectez-vous au système en tant que propriétaire d'instance et exécutez la
commande suivant :
db2set
Windows
AIX HPUX Linux Solaris Windows

Syntaxe
-k Server1
DSMSERV
-u nom_utilisateur -i rép_instance -k nom_clé
LOADFORMAT
-o fichier_options -noexpire -quiet
,
ACTIVELOGSize = 16384
DBDir = répertoire
DBFile = fichier ACTIVELOGSize = mégaoctets
ACTIVELOGDir = répertoire ARCHLogdir = répertoire

ARCHFailoverlogdir = répertoire MIRRorlogdir = répertoire
Paramètres
AIX HPUX Linux Solaris -u nom_utilisateur
Indique un nom d'utilisateur vers lequel basculer avant d'initialiser le serveur.
Ce paramètre est facultatif.
AIX HPUX Linux -i rép_instance
Solaris
Indique un répertoire d'instance à utiliser. Il devient le répertoire de travail en
cours du serveur. Ce paramètre est facultatif.
Windows -k nom_clé
Indique le nom d'une clé de registre Windows utilisée pour stocker des
informations sur ce serveur. N'utilisez ce paramètre que pour installer des
serveurs supplémentaires sur le même système. Une fois que le serveur a été
installé au moyen de ce paramètre, vous devez toujours le lancer avec la valeur
de ce paramètre. La valeur par défaut est SERVER1.
-o fichier_options
-noexpire
Indique que le traitement à l'expiration est supprimé au démarrage. Ce
paramètre est facultatif.
-quiet
facultatif.
DBDir
Spécifie les noms de chemin relatif d'un ou de plusieurs répertoires utilisés

pour stocker des objets de base de données. Les noms de répertoire doivent
être séparés par des virgules sans espace. Vous pouvez spécifier jusqu'à 128
noms de répertoire. Vous devez indiquer le paramètre DBDIR ou le paramètre
DBFILE.
DBFile
Spécifie le nom d'un fichier contenant les noms de chemin relatif d'un ou de
plusieurs répertoires utilisés pour stocker des objets de base de données.
Chaque nom de répertoire doit figurer sur une ligne distincte du fichier. Vous
pouvez spécifier jusqu'à 128 noms de répertoire. Vous devez indiquer le
paramètre DBDIR ou le paramètre DBFILE.
ACTIVELOGSize
Indique la taille des journaux actifs en mégaoctets. Ce paramètre est facultatif.
La valeur minimale est 2 048 Mo (2 Go) ; la valeur maximale est 131 072 Mo
(128 Go). Si vous spécifiez un nombre impair, la valeur est arrondie à la valeur
paire suivante. La valeur par défaut est de 16 384 Mo.
ACTIVELOGDirectory (obligatoire)
Indique le répertoire dans lequel le serveur Tivoli Storage Manager écrit et
stocke les fichiers des journaux actifs. Il n'y a qu'un seul emplacement de
journaux actifs. Le nom doit être un nom de répertoire qualifié complet. Le
répertoire doit exister, il doit être vide et l'ID utilisateur doit pouvoir y accéder
dans le gestionnaire de la base de données. Le nombre maximal de caractères
est 175.
ARCHLogdirectory (obligatoire)
Indique le répertoire des fichiers journaux d'archivage. Le nom doit être un
nom de répertoire qualifié complet. Le nombre maximal de caractères est 175.
ARCHFailoverlogdirectory
Indique le répertoire à utiliser comme emplacement de stockage secondaire si
le répertoire ARCHLOGDIRECTORY est saturé. Ce paramètre est facultatif. Le
nombre maximal de caractères est 175.
MIRRorlogdirectory
Indique le répertoire dans lequel le serveur reproduit le journal actif (les
fichiers figurant dans le répertoire ACTIVELOGDIRECTORY). Ce paramètre est
facultatif. Le répertoire doit avoir un nom de répertoire qualifié complet. Le
nombre maximal de caractères est 175.
Exemple : Formatage d'une base de données
AIX Linux
dsmserv format dbdir=/tsmdb001 activelogsize=8192

activelogdir=/activelog archlogdir=/archlog
archfailoverlogdir=/archfaillog mirrorlogdir=/mirrorlog
DSMSERV INSERTDB (Déplacement d'une base de données de serveur

vers une base de données vide)
L'utilitaire DSMSERV INSERTDB permet de déplacer une base de données de serveur
dans une nouvelle base de données V6.3. La base de données peut être extraite du
serveur d'origine et insérée dans une nouvelle base de données sur le nouveau
serveur à l'aide d'une connexion réseau entre les deux serveurs. Elle peut
également être insérée depuis un support contenant la base de données extraite.
Conseil : AIX Si le serveur est installé sur sur un système d'exploitation AIX
Version 6.1, pour améliorer la performance du système, envisagez de choisir la
spécification du fuseau horaire associée à Portable Operating System Interface
(POSIX). Cette spécification alternative du fuseau horaire, axée sur la base de
données Olson, peut affecter la performance du système. Pour plus d'informations
sur les spécifications de fuseau horaire, voir la documentation du système
d'exploitation AIX. Si le serveur est installé sur AIX Version 7.1, ce problème ne se
rencontre pas.
| Avant d'utiliser l'utilitaire DSMSERV INSERTDB, effectuez les tâches de planification et

| de préparation nécessaires, telles que la sauvegarde de la base de données et des
| informations de configuration. Veillez à respecter toutes les exigences avant de
| déplacer la base de données du serveur. Pour plus d'informations de planification
| et de préparation, voir la procédure de mise à niveau ou de migration de votre
| système.
Conditions pour l'insertion à l'aide d'un support
Avant d'exécuter l'utilitaire permettant d'insérer la base de données du serveur

dans une base de données vide, vérifiez que votre système remplit les conditions
suivantes.
v Si le fichier manifeste ne contient pas les informations de configuration de l'unité
ou si vous spécifiez le paramètre CONFIGINFO=DEVCONFIG, les instructions
suivantes doivent être vérifiées :
– Le fichier d'options du serveur doit contenir une entrée pour le fichier de
– Le fichier de configuration d'unité doit disposer des informations sur la classe
v Le support contenant la base de données extraite doit être disponible pour le
serveur V6.3. Les autorisations doivent être également définies pour permettre
au support d'accéder à l'ID utilisateur propriétaire de l'instance de serveur V6.3.
Syntaxe
-k Server1
DSMSERV
-u nom_utilisateur -i rép_instance -k nom_clé
INSERTDB
-o fichier_options -noexpire -quiet
PREview = No
A: Insertion depuis un support
B: Insertion sur un réseau PREview = Yes
No
A: Insertion depuis un support :
CONFiginfo = MANifest

DEVclass = nom_classe_unité CONFiginfo = MANifest
DEVconfig

MANifest = nom_fichier
B: Insertion sur un réseau :
SESSWait = 60
SESSWait = minutes
Paramètres
AIX HPUX Linux Solaris -u nom_utilisateur
Indique un nom d'utilisateur vers lequel basculer avant d'initialiser le serveur.
Ce paramètre est facultatif.
AIX HPUX Linux Solaris -i rép_instance
Indique un répertoire d'instance à utiliser. Il devient le répertoire de travail en
cours du serveur. Ce paramètre est facultatif.
Windows -k nom_clé
le serveur. Ce paramètre est facultatif. La valeur par défaut est SERVER1.
-o fichier_options
-noexpire
Indique que le traitement à l'expiration est supprimé au démarrage. Ce
paramètre est facultatif.
-quiet
facultatif.
DEVclass
Indique une classe d'unités à accès séquentiel. Vous pouvez spécifier toute
classe d'unités souhaitée à l'exception de la classe d'unités DISK. La définition
de la classe d'unités doit exister dans le fichier manifeste ou le fichier de
Ce paramètre est facultatif et utilisé uniquement lorsque la base de données à
insérer dans la base de données V6.3 vide a été extraite vers un support. Si la
base de données se trouve sur un support et que vous ne spécifiez aucune
classe d'unité, c'est la classe d'unité indiquée dans le fichier manifeste qui sera
utilisée.
Restriction : Vous ne pouvez pas utiliser de classe d'unités de type NAS ou

CENTERA.
MANifest
Indique l'emplacement du fichier manifeste. Utilisez un nom qualifié complet
du fichier ou placez-le dans un répertoire local. Par exemple : ./manifest.txt
Ce paramètre est obligatoire lorsque la base de données à insérer dans la base
de données V6.3 vide a été extraite vers un support.
CONFiginfo
Indique la source des informations de configuration de l'unité utilisée par
l'opération DSMSERV INSERTDB. La valeur par défaut de ce paramètre est
MANIFEST. Les valeurs possibles sont les suivantes :
MANifest
Indique que les informations de configuration de l'unité sont lues à partir
du fichier manifeste. Si le fichier manifeste ne les contient pas, le fichier de
configuration de l'unité est utilisé à la place.
DEVConfig
Indique que les informations de configuration de l'unité sont lues à partir
du fichier de configuration de l'unité.
SESSWait
Indique le nombre de minutes pendant lesquelles le serveur V6.3 attend que le
serveur d'origine le contacte. La valeur par défaut est fixée à 60 minutes.
Utilisez ce paramètre uniquement si les données insérées dans la base de
données V6.3 vide sont transmises depuis le serveur source via une connexion
réseau.
PREview
Indique si vous souhaitez prévisualiser l'opération d'insertion. Ce paramètre
est facultatif. La valeur par défaut est NO.
Utilisez le paramètre PREVIEW=YES pour tester une base de données.
Lorsque vous utilisez ce paramètre, l'opération inclut toutes les étapes du
processus, à l'exception de l'insertion réelle des données dans la nouvelle base
de données. Lorsque vous prévisualisez l'opération d'insertion, vous pouvez
rapidement vérifier la lisibilité de la base de données source. Vous pouvez
également identifier toute violation de contrainte de données susceptible
d'empêcher une base de données à niveau d'être placée en production.
ZMSPREPARE (Préparez un serveur sur un système z/OS en vue d'une

migration)
z/OS
Utilisez la commande ZMSPREPARE pour afficher des informations sur les données à
sauvegarder du disque sur une bande magnétique pour préparer la migration du
serveur vers le serveur multimédia z/OS.
La commande ZMSPREPARE génère également des rapports sur les éléments suivants
:
v Pools de copie et de stockage des données actives devant être supprimés ou
marqués comme détruits
v Volumes séquentiels enregistrés dans l'historique de volume et situés dans
l'espace de stockage FILE, sauf les volumes de pool de stockage
v Groupes de sauvegarde situés dans l'espace de stockage FILE
v Classes d'unités non valides
v Options de serveur nécessitant une mise à jour
v Date et heure de la toute dernière sauvegarde de base de données de serveur
Cette commande peut être émise uniquement sur un serveur z/OS .

Classe de privilèges
Tout administrateur peut émettre cette commande.
Syntaxe
STGpool = * Format = Standard
ZMSPRepare
STGpool = nom_pool Format = Standard
Detailed
Paramètres
STGpool
Indique les pools de stockage à répertorier.
Format
Indique le format de la sortie. Les valeurs suivantes sont possibles :
Standard
Indique que des données récapitulatives s'affichent.
Detailed
Indique que des données détaillées s'affichent.
Exemple : affichez les données de tous les pools de stockage au

format standard
Affichez les données de tous les pools de stockage au format standard. Exécutez la
commande suivante :
zmsprepare stgpool=* Format=Standard
Disk-based Storage Pools...
Pool Name Pool Type Class Name Capacity Util not mark-
ed destr-
oyed
----------- ----------- ---------- ---------- ----- ---------
ARCHIVEPOOL Primary DISK 0.0 M 0.0 0
BACKUPPOOL Primary DISK 12.0 M 0.0 1
HFSPOOL Primary HFSCLASS 0.0 M 0.0 2
SPACEMGPOOL Primary DISK 0.0 M 0.0 0
**************************************************
No FILE device type Backup Sets found.
**************************************************
Sequential volumes with a device type of FILE...
Date/Time Volume Type Device Class Volume Name
-------------------- -------------- ------------ ------------------------------
04/22/2011 13:20:09 BACKUPFULL FILE USER3.S3503609.DBB
04/22/2011 13:20:30 EXPORT FILE USER3.S3503630.EXP
**************************************************
Server options file conversion guidance.
( Yes/No/Consult documentation )
------ -------------- ------------------------ ------------------------
19 COMMOPENTIMEO- No No
UT
24 COMMMETHOD Yes No
104 TCPNAME No Yes
109 DELETIONEXIT No No
137 VOLUMEHISTORY Consult No
**************************************************
Last
Complete
Backup
Date/Time
03/15/11 15:51:21
Exemple : affichez les données de tous les pools de stockage au

format détaillé
Affichez les données de tous les pools de stockage au format détaillé. Exécutez la
commande suivante :
zmsprepare stgpool=* Format=Detailed
La sortie est identique à celle de l'exemple précédent, excepté pour la section du

pool de stockage qui comprend une liste de tous les volumes non marqués comme
DELETED :

Disk-based Storage Pools...
Storage Pool Name: ARCHIVEPOOL
Storage Pool Type: Primary
Device Class Name: DISK
Estimated Capacity: 0.0 M
Pct Util: 0.0
Volumes not marked destroyed: 0
Copy Storage Pools:
Volume Name:
Storage Pool Name: BACKUPPOOL

Pct Util: 0.0
Copy Storage Pools:
Volume Name: STGVOL1 Read/Write
Storage Pool Name: HFSPOOL

Device Class Name: HFSCLASS
Pct Util: 0.0
Copy Storage Pools:
Volume Name: /u/tsm/tsm1/hfsvol1 Read/Write
/u/tsm/tsm2/hfsvol2 Read/Write
Storage Pool Name: SPACEMGPOOL

Pct Util: 0.0
Copy Storage Pools:
Volume Name:
Le script du démarrage du serveur : rc.dsmserv

Le script de démarrage peut être utilisé au démarrage du système pour démarrer

automatiquement une instance de serveur sous un ID utilisateur spécifique.
Syntaxe
rc.dsmserv -u nom_utilisateur
-U nom_utilisateur -i rép_instance
Paramètres
-u nom_utilisateur
Indique l'Tivoli Storage ManagerID utilisateur d'instance pour lequel
l'environnement est configuré. Le serveur s'exécutera sous cet ID utilisateur.
-U nom_utilisateur
Indique l'Tivoli Storage ManagerID utilisateur d'instance pour lequel
l'environnement est configuré. Le serveur s'exécutera sous l'ID utilisateur de
l'appelant de la commande.
-i rép_instance
Indique un répertoire d'instance à utiliser. Celui-ci devient le répertoire de
travail en cours du serveur.
Exemples des commandes à exécuter pour valider la mise à niveau de

la base de données
Exécutez des commandes avant et après la mise à niveau d'un serveur afin
d'obtenir des informations sur le contenu de la base de données du serveur. Vous
pourrez vous assurer que les données ont été transférées correctement en
comparant les résultats des commandes avant et après la mise à niveau. Des
exemples de commandes vous sont fournis pour commencer.
Les commandes suivantes indiquent comment obtenir des informations

récapitulatives sur certains types d'objet :
Espaces fichier
select node_name, count(*) as "Number of Filespaces" from filespaces
group by node_name order by 2
Noeuds
select platform_name, count(*) as "Number of Nodes" from nodes group
by platform_name
Fichiers sauvegardés
select node_name,sum(num_files) as "Number of Backup Files" from
occupancy where type=’Bkup’ group by node_name
Fichiers archivés
select node_name,sum(num_files) as "Number of Archive Files" from
occupancy where type=’Arch’ group by node_name
Classes de gestion
select count(*) as "Number of Management Classes" from mgmtclasses
Scripts du serveur
select count(*) as "Number of Server Scripts" from script_names
Pools de stockage
select count(*) as "Number of Storage Pools" from stgpools
L'exemple suivant présente un ensemble de commandes plus complet. Vous

pouvez exécuter ce dernier en tant que script à partir de la ligne de commande
d'un serveur Tivoli Storage Manager. Redirigez la sortie vers un fichier afin de
sauvegarder les résultats.
select node_name, count(*) as "Number of Filespaces" from filespaces group by node_name order by 2
select platform_name, count(*) as "Number of Nodes" from nodes group by platform_name
select count(*) as "Number of Administrators" from admins
select node_name,sum(num_files) as "Number of Backup Files" from occupancy where type=’Bkup’
group by node_name
select node_name,sum(num_files) as "Number of Archive Files" from occupancy where type=’Arch’
group by node_name
select count(*) as "Number of Schedule Associations" from associations
select count(*) as "Number of Backupsets" from backupsets
select count(*) as "Number of Client Option Sets" from cloptsets
select count(*) as "Number of Collocation Groups" from collocgroup
select count(*) as "Number of Archive CopyGroups" from ar_copygroups
select count(*) as "Number of Backup CopyGroups" from bu_copygroups
select count(*) as "Number of Data Movers" from datamovers
select count(*) as "Number of Device Classes" from devclasses
select count(*) as "Number of Domains" from domains
select count(*) as "Number of Drives" from drives
select count(*) as "Number of Libraries" from libraries
select count(*) as "Number of Library Volumes" from libvolumes
select count(*) as "Number of Volumes" from volumes

select count(*) as "Number of Management Classes" from mgmtclasses
select count(*) as "Number of Node Groups" from nodegroup
select count(*) as "Number of Device Paths" from paths
select count(*) as "Number of Policy Sets" from policysets
select count(*) as "Number of Client Schedules" from client_schedules
select count(*) as "Number of Admin Schedules" from admin_schedules
select count(*) as "Number of Server Scripts" from scripts
select count(*) as "Number of Servers Defined" from servers
select count(*) as "Number of Servers Groups Defined" from server_group
select count(*) as "Number of Storage Pools Defined" from stgpools
Annexe B. Installation des modules de langue du serveur
AIX HPUX Linux Solaris Windows
Les versions traduites du serveur IBM Tivoli Storage Manager permettent au

serveur d'afficher des messages et l'aide dans des langues autres que l'anglais
américain. Les versions traduites permettent également d'utiliser des conventions
d'environnement local pour la date, l'heure et le format des nombres.
Environnements locaux de langue du serveur

Utilisez l'option de module de langue par défaut ou sélectionnez un autre module
de langue pour afficher les messages et l'aide du serveur.
AIX HPUX Linux Solaris Ce module de langue est installé

automatiquement pour l'option de langue par défaut suivante, pour les messages
et l'aide du serveur Tivoli Storage Manager :
v AIX LANGUAGE en_US
v HPUXLANGUAGE AMENG
L'environnement local de système suivant doit être installé sur le système
lorsque vous utilisez LANGUAGE AMENG :
HPUX en_US.iso88591
v Linux LANGUAGE en_US
v LANGUAGE AMENG
Solaris L'environnement local de système suivant doit être installé sur le
système lorsque vous utilisez LANGUAGE AMENG :
Solaris en_US
Windows Ce module de langue est installé automatiquement pour l'option de

langue par défaut suivante pour les messages et l'aide du serveur Tivoli Storage
Manager : LANGUAGE AMENG.
Pour les langues ou les environnements locaux autres que ceux par défaut,
Vous pouvez utiliser les langues affichées : AIX
Tableau 85. Langues de serveur pour AIX

Langue Valeur de l'option LANGUAGE
Chinois simplifié zh_CN
Chinois simplifié (UTF-8) ZH_CN
Chinois traditionnel (Big5) Zh_TW
Chinois traditionnel (UTF-8) ZH_TW
Chinois traditionnel (euc_tw) zh_TW
Anglais en_US
Anglais (UTF-8) EN_US

Tableau 85. Langues de serveur pour AIX (suite)
Français fr_FR
Français (UTF-8) FR_FR
Allemand de_DE
Allemand (UTF-8) DE_DE
Italien it_IT
Italien (UTF-8) IT_IT
Japonais EUC ja_JP
Japonais PC Ja_JP
Japonais UTF8 JA_JP
Coréen ko_KR
Coréen (UTF-8) KO_KR
Portugais (Brésil) pt_BR
Portugais (Brésil) (UTF-8) PT_BR
Russe ru_RU
Russe (UTF-8) RU_RU
Espagnol es_ES
Espagnol (UTF-8) ES_ES
Remarques :
v Le support de l'environnement en_US doit être installé sur le système.
v Pour plus d'informations sur le paramétrage de l'option LANGUAGE, voir Guide de
HPUX
Tableau 86. Langues du serveur pour HP-UX

Chinois simplifié zh_CN.hp15CN
zh_CN.utf8
Chinois traditionnel zh_TW.big5
zh_TW.eucTW
zh_TW.utf8
Anglais AMENG (par défaut)
en_US.utf8
Français fr_FR.iso88591
fr_FR.utf8
Allemand de_DE.iso88591
de_DE.utf8
Italien it_IT.iso88591
it_IT.utf8
Japonais ja_JP.eucJP
ja_JP.utf8
Tableau 86. Langues du serveur pour HP-UX (suite)
Coréen ko_KR.eucKR
ko_KR.utf8
Portugais (Brésil) pt_PT.iso88591
pt_PT.utf8
Russe ru_RU.iso88595
ru_RU.utf8
Espagnol es_ES.iso88591
es_ES.utf8
Remarques : Pour plus d'informations sur le paramétrage de l'option LANGUAGE, voir
Linux
Tableau 87. Langues de serveur pour Linux

LANGUAGE (LANGUE) Valeur de l'option LANGUAGE
Chinois simplifié zh_CN
zh_CN.gb18030
zh_CN.utf8
Chinois traditionnel Big5 / Zh_TW
zh_TW
zh_TW.utf8
Anglais (Etats-Unis) en_US
en_US.utf8
Français fr_FR
fr_FR.utf8
Allemand de_DE
de_DE.utf8
Italien it_IT
it_IT.utf8
Japonais ja_JP
ja_JP.utf8
Coréen ko_KR
ko_KR.utf8
Portugais (Brésil) pt_BR
pt_BR.utf8
Russe ru_RU
ru_RU.utf8
Espagnol es_ES
es_ES.utf8
Annexe B. Installation des modules de langue du serveur 587

Solaris
Tableau 88. Langues du serveur pour Solaris

Chinois simplifié zh
zh_CN.UTF-8
Chinois traditionnel zh_TW
zh_TW.BIG5
zh_TW.UTF-8
Anglais AMENG (par défaut)
en_US.UTF-8
Français fr_FR.ISO8859-1
fr_FR.UTF-8
Allemand de_DE.ISO8859-1
de_DE.UTF-8
Italien it_IT.ISO8859-1
it_IT.UTF-8
Japonais ja
ja_JP.UTF-8
Coréen ko
ko_KR.UTF-8
Portugais (Brésil) pt_BR.ISO8859-1
pt_BR.UTF-8
Russe ru_RU.ISO8859-5
ru_RU.UTF-8
Espagnol es_ES.ISO8859-1
es_ES.UTF-8
Remarques :
v LANGUAGE AMENG requiert l'environnement local de système en_US.
v Pour plus d'informations sur le paramétrage de l'option LANGUAGE, voir Guide de
Windows
Tableau 89. Langues de serveur pour Windows

Chinois simplifié chs
Chinois traditionnel cht
Anglais ameng
Français fra
Allemand deu
Italien ita
Japonais (Maj-JIS) jpn
Coréen kor
Tableau 89. Langues de serveur pour Windows (suite)
Portugais (Brésil) ptb
Russe rus
Espagnol esp
Restriction : AIX Linux Solaris Windows Pour les utilisateurs centre

d'administration, il se peut que certains caractères ne s'affichent pas correctement si
la version du navigateur Web n'est pas dans la même langue que le serveur. Dans
ce cas, choisissez une version du navigateur utilisant la même langue que le
serveur.
Configuration d'un module de langue

Une fois le module de langue configuré, les messages et l'aide sont affichés dans
Tivoli Storage Manager dans des langues autre que l'anglais américain. Des
modules d'installation sont fournis avec Tivoli Storage Manager.
AIX HPUX Linux Solaris Pour définir le support d'un

environnement local, effectuez l'une des actions suivantes :
v Définissez l'option LANGUAGE dans le fichier d'option du serveur en indiquant le
nom de l'environnement local à utiliser. Par exemple :
AIX Linux Pour utiliser un environnement local it_IT , définissez
l'option LANGUAGE pour it_IT. Voir «Environnements locaux de langue du
serveur», à la page 585.
HPUX Pour utiliser l'environnement local it_IT.iso88591 , définissez
l'option LANGUAGE pour it_IT.iso88591. Voir «Environnements locaux de
langue du serveur», à la page 585.
Solaris Pour utiliser l'environnement local it_IT.ISO8859-1 , définissez
l'option LANGUAGE pour it_IT.ISO8859-1. Voir «Environnements locaux de
langue du serveur», à la page 585.
v AIX HPUX Linux Solaris Définissez la variable d'environnement
LC_MESSAGES pour correspondre à la valeur définie dans le fichier d'options du
serveur. Par exemple, pour définir la variable d'environnement en italien, entrez
la valeur suivante :
export LC_MESSAGES=it_IT
Windows Attribuez à l'option LANGUAGE du fichier d'options du serveur le nom

de l'environnement local à utiliser. Par exemple : pour utiliser l'environnement
local ita , définissez l'option LANGUAGE pour ita. Voir «Environnements locaux
de langue du serveur», à la page 585.
Si l'environnement local s'initialise convenablement, il contrôle la date, l'heure et le

numéro du serveur. Si l'environnement local ne s'initialise pas correctement, le
serveur utilise l'anglais américain Fichiers de message en anglais et la date, l'heure,
ainsi que le format numérique du serveur.
Annexe B. Installation des modules de langue du serveur 589

Annexe C. Ressources requises pour le système HP-UX
HPUX
Les sémaphores, la mémoire partagée et les processus sont des ressources système
HP-UX qui peuvent nécessiter une configuration et un réglage spécifiques pour le
serveur Tivoli Storage Manager.
Estimation des ressources de sémaphore requises

HPUX
IBM Tivoli Storage Manager utilise des procédures pour le contrôle de ses
opérations internes.
Pour obtenir une estimation du nombre total de procédures requis par le serveur,
utilisez la formule suivante :
semaphores= 60 + (2 x maxSessions)
Où maxSessions correspond au nombre maximal de sessions clientes simultanées.
Par exemple, si vous estimez que vous utiliserez simultanément un nombre

maximal de sessions actives égal à 15, cela signifie que Tivoli Storage Manager
aura besoin d'environ 90 procédures.
Remarque : Si d'autres applications utilisent les procédures, vous devez veiller à ce

que les conditions requises correspondantes soient respectées lorsque vous
optimisez la configuration du noyau.
Une fois que vous avez estimé le nombre de procédures à utiliser, vérifiez que la
configuration du noyau contient la valeur correcte. Pour plus d'informations, voir
«Affichage et modification de la configuration du noyau», à la page 592.
Estimation des ressources de processus requises

HPUX
IBM Tivoli Storage Manager utilise des processus HP-UX pour les opérations
serveur simultanées.
Pour obtenir une estimation du nombre total de processus requis par le serveur,
utilisez la formule suivante :
processus = 60 + (2 x maxSessions)
Où maxSessions correspond au nombre maximal de sessions clientes simultanées.
Par exemple, supposons que vous utilisiez simultanément un nombre maximal de

sessions actives égal à 15. Vous pouvez alors calculer qu'IBM Tivoli Storage
Manager doit utiliser environ 90 processus pour contrôler ses opérations internes.
Mais vous devez tenir compte de tous les autres processus HP-UX susceptibles

d'être exécutés simultanément sur votre système lorsque vous calculez les
conditions requises pour vos ressources de noyau HP-UX.
Une fois que vous avez estimé le nombre de processus à utiliser, vérifiez que la
configuration du noyau contient la valeur correcte. Pour plus d'informations, voir
«Affichage et modification de la configuration du noyau».
Estimation du nombre d'unités d'exécution requises par processus

HPUX
La valeur HP-UX par défaut affectée au nombre maximal d'unités d'exécution

autorisé dans chaque processus est 64.
Lorsque Tivoli Storage Manager traite une lourde charge de travail ou participe à
un transfert de données hors réseau, il se peut que cette valeur soit trop faible.
Afin d'éviter les erreurs de création d'unités d'exécution sur le serveur Tivoli
Storage Manager, faites passer à 500 le nombre maximal d'unités d'exécution par
processus pour HP-UX.
Pour plus d'informations, voir «Affichage et modification de la configuration du

noyau».
Affichage et modification de la configuration du noyau

HPUX
Pour afficher ou modifier votre configuration de noyau existante, recourez soit à

l'utilitaire SAM sur HP-UX version 11iv2 ou System Management Homepage
(SMH) sur HP-UX version 11iv3, soit modifiez directement le fichier de
configuration. Pour définir les valeurs de noyau, suivez les recommandations de
l'utilitaire DB2OSCONF.
Démarrez SAM ou SMH, puis sélectionnez :

1. Configuration du noyau
2. Paramètres configurables
Une liste de paramètres s'affiche ; vous pouvez en modifier les valeurs. Cette liste
contient les éléments suivants :
v semmns Nombre maximum de procédures
v shmmax Quantité maximale de mémoire partagée disponible
v nproc Nombre maximal de processus
v max_thread_proc Nombre maximal d'unités d'exécution autorisé dans chaque
processus
Pour plus d'informations sur la modification des paramètres de noyau
configurables, consultez la documentation HP-UX.
Annexe D. Utilisation des zones Solaris
Solaris
Le serveur Tivoli Storage Manager prend en charge la fonction Solaris Zone

disponible avec Solaris Version 10. Deux types de zones sont prise en charge :
global et local.
La zone globale est la zone par défaut sur un système hôte Solaris ; elle contrôle
les ressources système. Les zones locales peuvent être créées et contrôlées depuis la
zone globale ; elles exécutent des processus de manière isolée sur un même
système hôte.
Pour installer Tivoli Storage Manager le serveur dans la zone globale ou locale,
connectez-vous à la zone dans laquelle vous souhaitez installer le serveur. Ensuite,
terminez le processus normal d'installation de votre système. Vous pouvez installer
le serveur dans plusieurs zones en effectuant chaque installation séparément. Le
serveur Tivoli Storage Manager est installé uniquement dans la zone en cours.
Reportez-vous au chapitre relatif à l'utilisation des périphériques dans le Guide

d'administration pour plus d'informations sur l'installation Tivoli Storage Manager
du pilote périphérique dans la zone Solaris.
Pour plus d'informations, reportez-vous à la documentation d'administration du

système Solaris.
Création d'une zone Solaris

Solaris
Pour installer un serveur Tivoli Storage Manager sur une zone Solaris, la zone doit
avoir accès en écriture aux répertoires /usr, /opt, /var et /tmp. Les zones par
défaut ne disposent pas d'accès en écriture au niveau du répertoire /usr.
Le processus d'installation du serveur Tivoli Storage Manager requiert une zone

locale Solaris disposant des droits d'accès en écriture aux répertoires /usr, /opt,
/var et /tmp lors de la création de la zone locale à partir de la zone globale. Par
défaut, une zone locale dispose des droits en écriture sur les répertoires /opt, /var
et /tmp mais n'a pas accès en écriture au répertoire /usr. Pour installer Tivoli
Storage Manager version 6.3 ou ultérieure sur une zone locale de la plateforme
Solaris, la zone doit être configurée avec l'accès en écriture au répertoire /usr.
Pour créer une zone locale de base avec accès en écriture au répertoire /usr,
procédez comme suit.
1. Dans la zone globale, créez un répertoire de zone :
# mkdir -m 700 /zones/sunshade1
2. Configurez la zone :
# zonecfg -z sunshade1

sunshade1: No such zone configured
Use ’create’ to begin configuring a new zone.
zonecfg:sunshade1> create
zonecfg:sunshade1> set zonepath=/zones/sunshade1
zonecfg:sunshade1> set autoboot=true
zonecfg:sunshade1> remove inherit-pkg-dir dir=/usr
zonecfg:sunshade1> add net
zonecfg:sunshade1:net> set address=9.11.100.1
zonecfg:sunshade1:net> set physical=bnx0
zonecfg:sunshade1:net> end
zonecfg:sunshade1> add attr
zonecfg:sunshade1:net> set name=comment
zonecfg:sunshade1:net> set type=string
zonecfg:sunshade1:net> set value="This is sunshade1..."
zonecfg:sunshade1:net> end
zonecfg:sunshade1> verify
zonecfg:sunshade1> commit
zonecfg:sunshade1>exit
3. Vérifiez la zone :
# zoneadm list -cv
ID NAME STATUS PATH BRAND IP
0 global running / native shared
- sunshade1 configured /zones/sunshade1 native shared
# zonecfg -z sunshade1 info

zonename: sunshade1
zonepath: /zones/sunshade1
brand: native
autoboot: false
bootargs:
pool:
limitpriv:
scheduling-class:
ip-type: shared
inherit-pkg-dir:
dir: /lib
inherit-pkg-dir:
dir: /platform
inherit-pkg-dir:
dir: /sbin
net:
address: 9.11.100.1
physical: bnx0
attr:
name: comment
type: string
value: "This is sunshade1..."
4. Installez la zone :
# zoneadm -z sunshade1 install
5. Démarrez la zone :
# zoneadm -z sunshade1 boot
# zoneadm list -cv
ID NAME STATUS PATH BRAND IP
0 global running / native shared
- sunshade1 configured /zones/sunshade1 native shared
6. Configurez la zone pour le réseau :

# zlogin -C sunshade1 # -- configure zone for the network
Après avoir créé la zone locale pour Tivoli Storage Manager version 6.3 ou
ultérieure, le serveur Tivoli Storage Manager, l'agent de stockage et les modules de
pilotes de périphériques peuvent être installés sur la zone. Vous pouvez installer et
exécuter le serveur, l'agent de stockage et le pilote de périphérique dans les zones
locales à l'aide du même processus pour les installer et les exécuter dans des zones
globales.
Annexe D. Utilisation des zones Solaris 595

Annexe E. Services associés au serveur Tivoli Storage
Manager
Windows
Lorsque vous démarrez le serveur Tivoli Storage Manager en tant que service,
d'autres services sont lancés automatiquement. Ces services sont associés au
gestionnaire de base de données DB2.
Les services suivants sont associés au serveur Tivoli Storage Manager.
Nom du service Fonction Commentaires

TSM instance_serveur Service destiné à l'instance de serveur Définissez les options de démarrage
Tivoli Storage Manager désignée par et d'arrêt pour ce service afin que
instance_serveur. l'instance de serveur soit démarrée et
arrêtée automatiquement.
Par exemple : TSM Server1
Chaque instance de serveur est
exécutée en tant que service distinct.
DB2 - DB2TSM1 - INSTANCE_SERVEUR Service DB2 destiné à l'instance de Ce service est lancé automatiquement
serveur désignée par instance_serveur. lorsque le serveur destiné à l'instance
de serveur Tivoli Storage Manager est
Par exemple : DB2 - DB2TSM1 - démarré. Le service DB2 ne s'arrête
SERVER1 pas automatiquement lorsque vous
arrêtez le service pour le serveur.
Le système dispose de l'un de ces

services pour chaque service
d'instance de serveur qui est démarré
sur le système.
DB2 Governor (DB2TSM1) Service DB2 crée pendant Ne modifiez pas les options pour ce
l'installation et qui est requis pour service.
toutes les instances de serveur.
DB2 License Server (DB2TSM1) Service DB2 crée pendant Ne modifiez pas les options pour ce
DB2 Management Server (DB2TSM1) Service DB2 crée pendant Ne modifiez pas les options pour ce
DB2 Remote Command Server Service DB2 crée pendant Ne modifiez pas les options pour ce
(DB2TSM1) l'installation et qui est requis pour service.
Serveurs mis à niveau depuis 6.1.0 ou 6.1.1 : Sur un système exécutant le

programme serveur Tivoli Storage Manager 6.1.0 ou 6.1.1, un service
supplémentaire appelé DB2 - DB2TSM1 - DB2TSM-0 s'affiche dans la liste des
services. Lorsque le programme serveur 6.1.0 ou 6.1.1 est mis à niveau vers une
version supérieure, ce service est renommé DB2 - DB2TSM1 - DB2TSM. Ce service n'a
pas d'impact sur le fonctionnement des instances de serveur Tivoli Storage
Manager que vous configurez. DB2TSM est une instance DB2 non fonctionnelle.

Annexe F. Fonctions d'accessibilité de la famille de produits
Les fonctions d'accessibilité aident les utilisateurs souffrant d'un handicap, tel
qu'une mobilité réduite ou une vision limitée, à utiliser les produits de
technologies de l'information avec succès.
Fonctions d'accessibilité
La liste suivante contient les principales fonctions d'accessibilité de la famille de

produits Tivoli Storage Manager :
v Fonctionnement à l'aide du clavier uniquement
v Interfaces régulièrement utilisées par les lecteurs d'écran
v Touches reconnaissables au toucher mais qui ne s'activent pas en les touchant
v Unités correspondant aux normes de l'industrie pour les ports et les connecteurs
v Lien des unités d'entrée et de sortie alternatives
Si vous installez Centre d'opérations IBM Tivoli Storage Manager en mode console,
son installation est pleinement accessible.
Les fonctions d'accessibilité du Centre d'opérations ne sont complètement prises en

charge que dans le navigateur Mozilla Firefox exécuté sur un système Windows.
Le centre de documentation de Tivoli Storage Manager et les publications connexes

sont activées pour l'accessibilité. Pour des informations sur les fonctions
d'accessibilité du centre de documentation, voir la rubrique suivante :
http://pic.dhe.ibm.com/infocenter/tsminfo/v6r3/topic/com.ibm.help.ic.doc/
iehs36_accessibility.html.
Navigation par le clavier
Sur Windows, la famille de produits suit les conventions Tivoli Storage Manager
Microsoft pour toute navigation ou pour tout accès au clavier. Le support du
glisser-déplacer est géré via l'utilisation de l'option Microsoft Windows
Accessibility, connue sous le nom de MouseKeys. Pour plus d'informations sur
MouseKeys et d'autres options d'accessibilité Windows, voir l'aide en ligne
Windows, en citant le mot clé «MouseKeys».
Sur d'autres systèmes d'exploitation, ces produits respectent les conventions du

système d'exploitation en matière de navigation et d'accès à l'aide du clavier.
Logiciel fournisseur
La famille de produits Tivoli Storage Manager inclut certains logiciels fournisseur

non protégés par le contrat de licence IBM. IBM décline toute responsabilité
concernant les fonctions d'accessibilité de ces produits. Contactez le fournisseur
pour obtenir des informations sur l'accessibilité de ses produits.
IBM et l'accessibilité
Voir IBM Human Ability and Accessibility Center (http://www.ibm.com/able)

pour des informations sur l'engagement d'IBM sur l'accessibilité.
Remarques
Le présent document peut contenir des informations ou des références concernant
certains produits, logiciels ou services IBM non annoncés dans ce pays. Pour plus
de détails, référez-vous aux documents d'annonce disponibles dans votre pays, ou
adressez-vous à votre partenaire commercial IBM. Toute référence à un produit,
logiciel ou service IBM n'implique pas que seul ce produit, logiciel ou service
puisse être utilisé. Tout autre élément fonctionnellement équivalent peut être
utilisé, s'il n'enfreint aucun droit d'IBM. Il est de la responsabilité de l'utilisateur
d'évaluer et de vérifier lui-même les installations et applications réalisées avec des
produits, logiciels ou services non expressément référencés par IBM.
IBM peut détenir des brevets ou des demandes de brevet couvrant les produits
mentionnés dans le présent document. La remise de ce document ne vous donne
aucun droit de licence sur ces brevets ou demandes de brevet. Si vous désirez
recevoir des informations concernant l'acquisition de licences, veuillez en faire la
demande par écrit à l'adresse suivante :
IBM Director of Licensing

IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
Les informations sur les licences concernant les produits utilisant un jeu de
caractères double octet peuvent être obtenues en contactant le Service Propriété
Intellectuelle d'IBM dans votre pays ou en écrivant à l'adresse suivante :
Intellectual Property Licensing

Legal and Intellectual Property Law
IBM Japan Ltd
1623-14, Shimotsuruma, Yamato-shi
Kanagawa 242-8502 Japan
Le paragraphe suivant ne s'applique ni au Royaume-Uni, ni dans aucun pays

dans lequel il serait contraire aux lois locales. LE PRESENT DOCUMENT EST
LIVRE «EN L'ETAT». IBM DECLINE TOUTE RESPONSABILITE, EXPLICITE OU
IMPLICITE, RELATIVE AUX INFORMATIONS QUI Y SONT CONTENUES, Y
COMPRIS EN CE QUI CONCERNE LES GARANTIES DE VALEUR
MARCHANDE OU D'ADAPTATION A VOS BESOINS. Certaines juridictions
n'autorisent pas l'exclusion des garanties implicites, auquel cas l'exclusion ci-dessus
ne vous sera pas applicable.
Le présent document peut contenir des inexactitudes ou des coquilles. Ce

document est mis à jour périodiquement. Chaque nouvelle édition inclut les mises
à jour. IBM peut modifier sans préavis les produits et logiciels décrits dans ce
document.
Les références à des sites Web non IBM sont fournies à titre d'information
uniquement et n'impliquent en aucun cas une adhésion aux données qu'ils
contiennent. Les éléments figurant sur ces sites Web ne font pas partie des
éléments du présent produit IBM et l'utilisation de ces sites relève de votre seule
responsabilité.

IBM pourra utiliser ou diffuser, de toute manière qu'elle jugera appropriée et sans
aucune obligation de sa part, tout ou partie des informations qui lui seront
fournies.
Les licenciés souhaitant obtenir des informations permettant : (i) l'échange des
données entre des logiciels créés de façon indépendante et d'autres logiciels (dont
celui-ci), et (ii) l'utilisation mutuelle des données ainsi échangées, doivent adresser
leur demande à :
IBM Corporation
2Z4A/101
11400 Burnet Road
Austin, TX 78758
U.S.A.
Ces informations peuvent être soumises à des conditions particulières, prévoyant

notamment le paiement d'une redevance.
Le logiciel sous licence décrit dans ce document et tous les éléments sous licence
disponibles s'y rapportant sont fournis par IBM conformément aux dispositions de
l'ICA (IBM Customer Agreement), des Conditions internationales d'utilisation des
logiciels IBM ou de tout autre accord équivalent.
Les données de performance indiquées dans ce document ont été déterminées dans
un environnement contrôlé. Par conséquent, les résultats peuvent varier de manière
significative selon l'environnement d'exploitation utilisé. Certaines mesures
évaluées sur des systèmes en cours de développement ne sont pas garanties sur
tous les systèmes disponibles. En outre, elles peuvent résulter d'extrapolations. Les
résultats peuvent donc varier. Il incombe aux utilisateurs de ce document de
vérifier si ces données sont applicables à leur environnement d'exploitation.
Les informations concernant des produits non IBM ont été obtenues auprès des
fournisseurs de ces produits, par l'intermédiaire d'annonces publiques ou via
d'autres sources disponibles. IBM n'a pas testé ces produits et ne peut confirmer
l'exactitude de leurs performances ni leur compatibilité. Elle ne peut recevoir
aucune réclamation concernant des produits non IBM. Toute question concernant
les performances de produits non IBM doit être adressée aux fournisseurs de ces
produits.
Ces informations sont fournies uniquement à titre de planification. Elles sont

susceptibles d'être modifiées avant la mise à disposition des produits décrits.
Le présent document peut contenir des exemples de données et de rapports utilisés

couramment dans l'environnement professionnel. Ces exemples mentionnent des
noms fictifs de personnes, de sociétés, de marques ou de produits à des fins
illustratives ou explicatives uniquement. Toute ressemblance avec des noms de
personnes, de sociétés ou des données réelles serait purement fortuite.
LICENCE DE DROIT D'AUTEUR :
Ces informations contiennent des modèles de programmes d'application en langage

source présentant les techniques de programmation de différentes plateformes
d'exécution. Vous pouvez copier, modifier et distribuer gratuitement ces modèles
de programmes, sous quelque forme que ce soit, pour développer, utiliser,
commercialiser ou distribuer des programmes d'application conformes à l'interface
de programmation des applications pour la plateforme d'exécution pour laquelle
les modèles de programmes sont écrits. Ces modèles n'ont pas été scrupuleusement
testés dans toutes les conditions. C'est la raison pour laquelle IBM ne peut pas
garantir ou répondre de la fiabilité, de la serviçabilité ou du fonctionnement de ces
programmes. Les modèles de programmes sont fournis "TELS QUELS", sans
garantie d'aucune sorte. La société IBM ne sera pas tenue responsable des
dommages causés par l'utilisation des modèles de programmes.
Chaque copie ou toute partie de ces modèles de programmes ou tout travail qui en
découle doit contenir une note de droit d'auteur se présentant comme suit : ©
(nom de votre société) (année). Les parties de ce code proviennent de IBM Corp.
Sample Programs. © Copyright IBM Corp. _enter the year or years_.
Si vous visualisez ces informations en ligne, il se peut que les photographies et

illustrations en couleur n'apparaissent pas à l'écran.
Marques
IBM, le logo IBM et ibm.com sont des marques d'International Business Machines
Corp. dans de nombreux pays. D'autres noms de produits et services peuvent être
des marques d'IBM ou d'autres sociétés. La liste actualisée de toutes les marques
d'IBM est disponible sur la page Web "Copyright and trademark information" à
http://www.ibm.com/legal/copytrade.shtml.
Intel et Itanium sont des marques déposées d'Intel Corporation ou de ses filiales
aux Etats-Unis et dans d'autres pays.
Linux est une marque de Linus Torvalds aux Etats-Unis et/ou dans certains autres
pays.
Microsoft et Windows sont des marques de Microsoft Corporation aux Etats-Unis

et/ou dans certains autres pays.
UNIX est une marque déposée de The Open Group aux Etats-Unis et/ou dans
certains autres pays.
LTO et Ultrium sont des marques de HP, d'IBM Corp. et de Quantum aux
Etats-Unis et dans d'autres pays.
Remarques 603
Glossaire
Un glossaire est disponible avec les termes et définitions associés à la famille IBM Tivoli Storage Manager
de produits.
Vous pouvez afficher le glossaire dans le centre de documentation Tivoli Storage Manager du
http://pic.dhe.ibm.com/infocenter/tsminfo/v6r3.
Pour afficher les glossaires pour d'autres produits IBM, voir http://www.ibm.com/software/
globalization/terminology/.

Index
A base de données (suite)
chargement de données
base de données (suite)
extraction (suite)
abonnement au support xx migration des serveurs à partir d' DSMUPGRD EXTRACTDB 567
accès AIX, HP-UX, ou Solaris 435 fichier manifeste 570
pools de stockage sur disque 355 chargement des données, via des migration des serveurs à partir d'
activation du serveur 357 supports AIX, HP-UX, ou Solaris 425
Adresse IP migration à partir de z/OS 534 performances 52
mise à jour procédures de scénarios 141, 237 sortie des messages 135, 223, 345
après le déplacement depuis AIX, procédures générales 346 vers des supports 135, 223, 345,
HP-UX ou Solaris 467 configuration de sauvegarde 533
agents de stockage migration des serveurs à partir d' formatage
changements de planification AIX, HP-UX, ou Solaris 437 migration des serveurs à partir d'
migration à partir de z/OS 503 configuration en vue d'une AIX, HP-UX, ou Solaris 432, 451
migration de z/OS 489 sauvegarde procédures de scénarios 136, 180,
mise à jour de la configuration 551 migration des serveurs à partir d' 232, 283, 340
mise à niveau 54, 56 AIX, HP-UX, ou Solaris 456 procédures générales 340
Anglais américain 589 contrôle formatage vide 574
arrêt du serveur extraction 135, 223, 345 journaux de reprise 4
Voir aussi serveur, arrêt création manager
migration de serveurs à partir de migration z/OS 533, 536 Voir gestionnaire de base de
z/OS 530 procédures de scénarios 136, 180, données
migration de serveurs depuis AIX, 232, 283 modifications dans la version 6.3 ou
HP-UX, ou Solaris 412 procédures générales 340 ultérieure 3
assistant de mise à niveau création d'une instance de serveur modifications de la protection 6
description 338 procédures de scénarios 136, 180, modifications de la reprise 6
journaux 10 232, 283 opérations 4
migration des serveurs depuis AIX, procédures générales 340 préparation
HP-UX, ou Solaris 423, 444 déplacement avant la migration depuis AIX,
mise à niveau de serveurs comparaison des méthodes 490 HP-UX, ou Solaris 424, 446
multiples 54 déplacement des données, via des préparation pour la migration à partir
scénarios 133, 178, 210, 219, 262, 271 supports 17 de z/OS 531
assistants migration z/OS 533 préparation pour la mise à niveau
Voir description de l'assistant de mise procédures de scénarios 135, 223 procédures de scénarios 120, 166,
à niveau procédures générales 345 222, 273
attributs de bibliothèque déplacement des données, via un procédures générales 325
migration de z/OS 505 réseau présentation des mises à jour 3
audit de la base de données 3 Migration des données à partir Requêtes SQL 3
automatisation d'AIX, HP-UX, ou Solaris 454 restauration 6
implémentation 366 migration z/OS 536 résumé de contenu avant la
après la migration depuis AIX, procédures de scénarios 185, 288 migration 410
HP-UX, ou Solaris 471 procédures générales 348 résumé de contenu avant mise à
après la migration vers z/OS 551 description 3 niveau
planification 59 emplacement 4 procédures de scénarios 112, 157,
espace 4 202, 253
estimation de l'espace requis 497 procédures générales 317
B Avant la migration des données à sauvegarde
bandothèques partir d'AIX, HP-UX, ou Avant la migration de données à
mise à jour des informations du Solaris 398 partir des systèmes AIX, HP-UX
chemin d'accès à l'unité estimation de l'espace requis pour le ouSolari 409
après la migration depuis AIX, journal de reprise 497 sauvegardes
HP-UX ou Solaris 465 Avant la migration des données à après la migration à partir de
base de données partir d'AIX, HP-UX, ou z/OS 550
administration 4 Solaris 398 après la migration depuis AIX,
astuces de performances extension 572 HP-UX ou Solaris 471
insertion de données dans la base extraction après la mise à niveau 363
de données version 6 502 astuces de performances 501 automatique 6
audits 3 chargement des données Avant la migration des données à
base de données extraites 141, 237, 346 partir d'AIX, HP-UX, ou
déplacement des données, via un classe d'unités, définition 135, Solaris 465
réseau 17 223, 345 reprise 6
description 567 sauvegardes automatiques 6

base de données (suite)
sauvegardes avant mise à niveau
conditions requises pour la mise à
niveau (suite)
D
procédures de scénarios 110, 156, serveur V5 (suite) dédoublonnage de données
200, 251 via un réseau 44 Après migration des serveurs à partir
procédures générales 315 serveur version 6.3 ou ultérieure 19 d' AIX, HP-UX, ou Solaris 459
transfert de données depuis des configuration démarrage automatique, serveur 361,
périphériques FILE et DISK 498 API, Tivoli Storage Manager 463
migration des serveurs à partir d' procédures de scénarios 144, 188, démarrage de serveurs
AIX, HP-UX, ou Solaris 400 240, 290 après la mise à niveau 357
transfert de données depuis des procédures générales 351 automatiquement 361
périphériques GENERICTAPE sauvegardes de base de données après la migration depuis AIX,
migration des serveurs à partir d' procédures de scénarios 144, 188, HP-UX, ou Solaris 463
AIX, HP-UX, ou Solaris 400 240, 290 démarrage automatique 9
validation de la mise à niveau 583 procédures générales 351 instances multiples 9, 10, 361, 463
base de données de serveur serveur multimédia z/OS 523 modifications dans la version 6.3 ou
Voir aussi base de données configuration, affichage et modification ultérieure 9
options de réorganisation 356, 541 du noyau 592 serveurs Windows
bases de connaissances, recherche xvii configuration logicielle requise services 362
bibliothèques partagées, mise à présentation générale 22 services Windows 10
niveau 55 serveur V5 20 déplacement des serveurs AIX, HP-UX ou
serveur version 6.3 ou ultérieure Solaris
AIX 25 Adresse IP
mise à jour 467
C HP-UX 27
Linux 29 désactivation de sessions 110, 155, 200,
chemins 251, 315
Linux sur System z 34
migration de z/OS 505 documentation
Linux sur systèmes POWER 30
classes d'unités ordre xiv
Linux x86_64 32
migration de z/OS 505 recherche xiv
Microsoft Windows 38
clavier 599 téléchargement xiv
Oracle Solaris 36
clients de bibliothèque, mise à niveau 55 données
configuration matérielle
commande SET DBRECOVERY 363, 465, migration d'une bande magnétique
migration z/OS 495
550 vers le DISQUE
planification 13
commande ZMSPREPARE après migration entre serveurs
présentation générale 22
préparation du serveur sur z/OS pour depuis AIX, HP-UX ou
serveur V5 20
une migration 579 Solaris 469
serveur version 6.3 ou ultérieure
commandes migration d'une bande magnétique
AIX 25
administration 11 vers le FICHIER
HP-UX 27
commande SET DBRECOVERY 465 après migration entre serveurs
Linux 29
migration de serveurs à partir de AIX, depuis AIX, HP-UX ou
Linux sur des systèmes
HP-UX, ou Solaris 393 Solaris 469
POWER 30
mise à jour 66 Périphériques DISK
Linux sur System z 34
modifications dans la version 6 60 migration des serveurs à partir d'
Linux x86_64 32
nouveau 60 AIX, HP-UX, ou Solaris 407
Microsoft Windows 38
présentation 561 Périphériques FILE
Oracle Solaris 36
SELECT 79 migration des serveurs à partir d'
configurations logicielles
SET DBRECOVERY 550 AIX, HP-UX, ou Solaris 407
migration de serveurs à partir de AIX,
supprimé 75 Périphériques GENERICTAPE
HP-UX, ou Solaris 398
validation de la mise à niveau de base migration des serveurs à partir d'
configurations logicielles requises
de données 583 AIX, HP-UX, ou Solaris 408
migration z/OS 495
VARY 380 transfert
configurations matérielles
ZMSPREPARE 579 migration de serveurs à partir de
commandes de migration AIX, HP-UX, or Solaris 393
présentation 561 données client
contrat du support xx
commandes de mise à niveau protection
contrôle
présentation 561 migration de serveurs à partir de
journaux du serveur mis à
compatibilité serveur avec les autres AIX, HP-UX, ou Solaris 394
niveau 367
produits DB2 40 protection au cours de la
Serveur V6 après migration à partir
composants migration 490
des systèmes AIX, HP-UX ou
compatibilité avec les versions données du serveur
Solaris 471
antérieures 54 protection
serveur version 5 après la migration
disponibles pour l'installation 54 migration de serveurs à partir de
vers z/OS 552
conditions préalables AIX, HP-UX, ou Solaris 394
serveur version 6 après la migration
vérificateur de prérequis droits d'accès
vers z/OS 552
exécution 43 configuration
copie miroir de journal actif
vérification 43 périphériques 420, 428, 442, 449
espace requis 47
conditions requises pour la mise à niveau pools de stockage sur disque 355
correctifs, obtention xix
serveur V5 DSMSERV INSERTDB 374
création d'une zone Solaris 593
via des supports 44
dsmupgdx
Voir description de l'assistant de mise
espace requis (suite)
journal de reprise 47
G
à niveau journal des reprises d'archivage 47 gestionnaire de base de données
DSMUPGRD, utilitaires de mise à niveau migration des serveurs depuis AIX, configuration de sauvegarde
Voir utilitaires de mise à niveau HP-UX, ou Solaris 405 procédures de scénarios 144, 188,
DSMUPGRD EXTEND DB, utilitaire serveur V5 240, 290
extension de la base de données via des supports 44 procédures générales 351
V5 572 via un réseau 44 présentation des mises à jour 3
DSMUPGRD EXTRACTDB, utilitaire serveur version 6.3 ou ultérieure 19 présentation générale 3
extraction de la base de données espace requis pour le stockage gestionnaire de base de données
V5 567 migration à partir de z/OS 498 (DB2TSM1) 597
DSMUPGRD PREPAREDB, utilitaire migration des serveurs à partir d' AIX, gestionnaire de bibliothèque, mise à
préparation d'une base de données HP-UX, ou Solaris 401 niveau 55
version 5 561 espace requis pour les périphériques gestionnaire de reprise après incident 6
DSMUPGRD QUERYDB, utilitaire migration à partir de z/OS 498 groupes de sauvegarde
affichage d'informations sur un migration des serveurs à partir d' AIX, avant et après la migration 488
serveur V5 561 HP-UX, ou Solaris 401 restauration
affichage d'informations sur une base espaces requis après la migration depuis AIX,
de données V5 561 base de données 46 HP-UX, ou Solaris 470
journal de reprise 46 suppression 528
migration à partir de z/OS 515 GSKit
suppression de la version 7 368
E planning worksheet 50
processus de mise à niveau
enregistrement
estimation 47
licences
après la migration depuis AIX,
planification 44 H
serveur version 6.3 ou ultérieure 45 handicap 599
estimation
après la mise à niveau 363
durée de la mise à niveau 50
enregistrement des licences
REGISTER LICENSE, commande 550
espace requis pour la mise à
niveau 47
I
environnement de cluster IBM Publications Center xiv
performances 50
mise à niveau, planification 297, 300 IBM Support Assistant xviii
unités d'exécution par processus
mise à niveau à partir de la version IBM Tivoli Storage Manager for z/OS
(HP-UX) 592
5.5 vers la version 6.3.2 ou une Media
extension
version antérieure 302 Voir serveur multimédia z/OS
base de données 572
mise à niveau à partir de la version ID utilisateur d'instance 8
journaux, archive 573
5.5 vers la version 6.3.3 ou version identification des problèmes
extraction de la base de données
suivante 298 description du problème pour
astuces de performances
Mise à niveau de la version 5.5 vers la l'assistance logicielle IBM xx
migration de serveurs à partir de
version 6.3.2 ou une version détermination de l'incidence
AIX, HP-UX, ou Solaris 402
antérieure 300, 304 commerciale pour l'assistance
Mise à niveau de la version V5.5 vers logicielle IBM xx
V6.3 ou ultérieure 295 soumission d'un incident au service
mise à niveau de V5.5 à V6.3.3 ou une F de support logiciel IBM xxi
version ultérieure 297 feuille de travail identification et résolution des problèmes
environnement de cluster AIX planification de l'espace pour le migration à partir de z/OS 555
Mise à niveau de la version V5.5 vers serveur 50 migration from AIX, HP-UX ou
V6.3 ou ultérieure 295 fichier manifeste 570 Solaris 473
environnement de cluster Windows fichier NODELOCK indiquer la classe d'unités des volumes
mise à niveau à partir de la version changement de nom 363, 550 pour la suppression
5.5 vers la version 6.3.2 ou une suppression 363, 550 DELETE VOLHISTORY,
version antérieure 302 fichiers commande 562
mise à niveau à partir de la version dénomination 10 informations de configuration
5.5 vers la version 6.3.3 ou version emplacement 10 sauvegardes avant la migration
suivante 298 historique des volumes 6 z/OS 516
Mise à niveau de la version5.5 vers la manquant 379 sauvegardes avant mise à niveau
version 6.3.2 ou une version Fonctionnalités de mise à niveau procédures de scénarios 111, 157,
antérieure 300, 304 installation 201, 252
mise à niveau de V5.5 à V6.3.3 ou une Avant la migration des données à procédures générales 316
version ultérieure 297 partir d'AIX, HP-UX, ou informations de configuration des
Environnements en cluster Solaris 412 périphériques
mise à niveau vers V6.3 ou fonctions d'accessibilité 599 migration de serveurs à partir de AIX,
ultérieure 295 fonctions de traduction 585 HP-UX, ou Solaris 394
espace disque, requis 47 formation informations de configuration des unités
espace requis voir formation technique Tivoli xvii migration à partir de z/OS 539
copie miroir de journal actif 47 formation, technique Tivoli xvii sauvegardes avant la migration
journal actif 47 formation technique Tivoli xvii z/OS 516
journal d'archivage 47
Index 609
informations de configuration des unités
(suite)
J méthodes de mise à niveau (suite)
procédures
conversion des classes d'unités jeux de sauvegardes même système, via des
z/OS 486 déplacement supports 103
sauvegardes avant mise à niveau avant la migration depuis AIX, même système, via le réseau 149
procédures de scénarios 111, 157, HP-UX, ou Solaris 409 nouveau système, via des
201, 252 journal actif supports 193
procédures générales 316 espace requis 47 nouveau système, via le
informations de support xvii surveillance après la mise à réseau 245
informations du chemin d'accès à l'unité niveau 367 migration de serveurs à partir de AIX,
mise à jour journal d'archivage HP-UX, ou Solaris 387
après la migration depuis AIX, espace requis 47 astuces de performances
HP-UX ou Solaris 465 surveillance après la mise à extraction de la base de
informations sur l'historique des volumes niveau 367 données 402
besoin de récupération de base de journal de reprise avant de commencer 393
données 6 description 4 commandes 393
sauvegardes avant la migration emplacement 47 configurations logicielles 398
z/OS 516 espace requis 46 configurations matérielles 398
sauvegardes avant mise à niveau journal des reprises d'archivage données client
procédures de scénarios 111, 157, Voir aussi journal des reprises protection 394
201, 252 d'archivage données du serveur
procédures générales 316 espace requis 47 protection 394
informations sur la licence surveillance après la mise à feuille de route 387
mise à jour niveau 367 périphériques
procédures de scénarios 111, 156, journaux migration 394
201, 252 espace requis, reprise 46 transfert de données 393
procédures générales 316 extension, archive 573 utilitaires 393
insertion de la base de données installation 10 migration de serveurs à partir de
astuces de performances mode journal de reprise 6 z/OS 516, 533
migration de serveurs à partir de mode récupération aval analyse du serveur version 5 524
AIX, HP-UX, ou Solaris 402 Voir mode journal de reprise base de données
installation reprise préparation pour la migration à
disponibilité des composants 54 emplacement 47 partir de z/OS 521
emplacement 10 présentation générale 4 changements apportés aux
journaux 10 paramètres 521
serveur changements opérationnels 503
migration des serveurs à partir d' L chargement des données
AIX, HP-UX, ou Solaris 418, 426 langues extraites 534
migration des serveurs depuis AIX, Définir 589 configuration des périphériques de
HP-UX, ou Solaris 439, 446 licences serveur multimédia z/OS 539
installation de Tivoli Storage Manager enregistrement configuration du serveur version 6.3
zone Solaris 593 après la migration depuis AIX, ou ultérieure 516
installation du serveur multimédia HP-UX, ou Solaris 464 création d'une base de données
z/OS 523 après la mise à niveau 363 version 6 533, 536
instance de serveur enregistrement après la migration à création du fichier d'options du
création partir de z/OS 550 serveur 528
migration des serveurs à partir d' Linux x86_64 définition de pools de stockage 549
AIX, HP-UX, ou Solaris 432, 451 Voir aussi migration de serveurs à définition du serveur
répertoires partir de AIX, HP-UX, ou Solaris multimédia 523
migration des serveurs à partir d' migration démarrage automatique du
AIX, HP-UX, ou Solaris 431, Linux x86_64 387 serveur 546
443, 450 migration vers 385 démarrage d'une instance de
migration des serveurs depuis AIX, Voir migration de serveurs à partir serveur 545
HP-UX ou Solaris 421 de AIX, HP-UX, ou Solaris démarrage de l'instance de
instances de serveur Logiciels Butterfly 387 serveur 543
démarrage 9, 10 démarrage du serveur
owner 8 à partir de l'ID utilisateur
instances de serveur multiples 8
Internet, recherche pour la résolution de
M root 546
déplacement de données
problèmes xviii messages via des supports 533
Internet, recherche pour la résolution des résultats d'extraction 135, 223, 345 désactivation de sessions 524
problèmes xix serveur 81 durée requise 499
serveur multimédia z/OS 491 espace requis pour la base de données
méthode hybride de mise à niveau et et le journal de reprise 497
migration 490 espace requis pour le stockage 498
méthodes de mise à niveau espace requis pour les
présentation générale 85 périphériques 498
migration de serveurs à partir de z/OS migration de serveurs de z/OS (suite) migration de serveurs depuis AIX,
(suite) commandes 485 HP-UX, ou Solaris (suite)
exemple d'estimation de la durée 500 compatibilité avec d'autres serveur (suite)
extraction des données produits 496 démarrage du serveur à l'aide de
vers des supports 533 configurations matérielles et logicielles l'ID de superutilisateur 463
formatage d'une base de données requises 495 serveurs
version 6 533, 536 définition de bibliothèque 505 démarrage automatique 463
installation du serveur version définition de chemin 505 tcpserveraddress, option
6.3 516 informations de référence 504 mise à jour 467
installation du serveur version 6.3 ou méthode hybride de mise à niveau et vérification des résultats 464
ultérieure 516 migration 490 migration de serveurs depuis AIX,
mise à niveau de plusieurs serveurs et migration d'unité 486, 505 HP-UX ou Solaris
composants 503 préparation du serveur 579 données
planification 495 présentation 477 déplacement depuis des unités de
premières étapes après la présentation du processus 482 bande 469
migration 541 principales phases 484 ID utilisateur
préparation 515 restrictions 482 création 421
préparation d'une base de données utilitaires 485 répertoires
version 5 531 via des supports 490 création 421
préparation de l'espace 515 via un réseau 490 scénario de migration 1
préparation du serveur version 5 521 migration de serveurs depuis AIX, création de répertoires 421
présentation 475 HP-UX, ou Solaris créer un ID utilisateur 421
recréation des pools de stockage sur automatisation migration de serveurs depuisAIX,
disque 548 mise à jour 471 HP-UX, ou Solaris
recréation des volumes de pool de changements opérationnels 401 paramètres du serveur
stockage 549 contenu de base de données modification 410
restauration de pools de création de récapitulatif 410 scénario de migration 3
stockage 549 informations du chemin d'accès à installation du serveur 439
restauration du serveur version l'unité scénario de migration 4
5 555 mise à jour 465 installation du serveur 446
après la suppression de la base de jeux de sauvegardes migration de serveurs vers Linux x86_64
données du serveur version déplacement 409 Voir migration de serveurs à partir de
5 556 restauration 470 AIX, HP-UX, ou Solaris
avant la suppression des licences migration depuis AIX, HP-UX ou Solaris
volumes 555 enregistrement 464 identification et résolution des
avant le déplacement des méthode de support, assistant de mise problèmes 473
données 555 à niveau 417 migration des servers d'AIX, HP-UX, ou
sauvegarde des données 527 méthode réseau, assistant de mise à Solaris
sauvegarde la base de données du niveau 438 périphériques
serveur 530 mise à niveau de plusieurs serveurs et configuration 429
scénarios 477 composants 400 scénarion de migration 2
suppression de volumes marqués planification 397 configuration de
comme détruits 550 préparation 405 périphérique 429
suppression des groupes de préparation de l'espace 405 migration des serveurs à partir d' AIX,
sauvegarde 528 restauration du serveur version HP-UX, ou Solaris 385
suppression des volumes de pool de 5 473 avantages 385
stockage de copie 526 scénario de migration 1 417 base de données
transfert de données exécution de l'assistant de mise à sauvegarde 465
via un réseau 536 niveau 423 Transfert des données, via un
transfert de données depuis des scénario de migration 2 réseau 454
périphériques FILE et DISK 498 méthode de support, ligne de base de données serveur
transfert de la bande vers une autre commande 424 gestion 459
bandothèque 534 préparation de base de sauvegarde 409
vérification des options de données 424 conditions requises pour le journal de
serveur 541 scénario de migration 3 438 reprise 398
vérification des résultats 548 exécution de l'assistant de mise à données stockées sur les
via des supports ou un réseau 533 niveau 444 périphériques FILE
migration de serveurs de z/OS scénario de migration 4 migration 407
agents de stockage 489 méthode de réseau, ligne de données sur les périphériques
astuces de performances commande 445 GENERICTAPE 408
extraction de la base de préparation de base de migration 408
données 501 données 446 durée requise 399
insertion de la base de serveur espace requis
données 502 démarrage 460 contrôle 471
avant de commencer 482 démarrage à partir de l'ID espace requis pour le stockage 401
avantages 477 d'instance utilisateur 462 espace requis pour les
changements opérationnels 491 périphériques 401
Index 611
migration des serveurs à partir d' AIX, migration des serveurs à partir de AIX, moteur de déploiement
HP-UX, ou Solaris (suite) HP-UX, ou Solaris (suite) sauvegarde 363
exigences pour la base de données stockées sur les
données 398 périphériques DISK (suite)
Fonctionnalités de mise à niveau
installation 412
sauvegarde 407
données stockées sur les
N
noeuds client
ID utilisateur périphériques FILE
modifications des paramètres pour la
création 431, 443, 450 sauvegarde 407
mise à niveau
méthode planification
procédures générales 313
sélection 417 référence 403
nom d'hôte
nom d'hôte migration des serveurs à partir de
modification
modification 466 systèmes AIX, HP-UX, ou Solaris
Après la migration des données à
options du serveur scénarios 388
partir d'AIX, HP-UX, ou
configuration 459 Migration multi-plateformes vers Linux
Solaris 466
périphériques x86_64
après la mise à niveau 365
configuration 420, 428, 442, 449 Voir migration de serveurs à partir de
noms d'ensembles de fichiers 10
répertoires AIX, HP-UX, ou Solaris
noms pour une instance de serveur 81
création 431, 443, 450 mise à niveau
Scénario de migration 1 comparaison des méthodes 15
installation du serveur 418 nouveau système, serveur version 6.3
Scénario de migration 2 ou ultérieure O
chargement des données comparaison avec une mise à Option, LANGUE 589
extraites 435 niveau système existante 15 option LANGUAGE (LANGUE) 585
configuration en vue d'une procédures options
sauvegarde de la base de même système, via des après la migration à partir de z/OS
données 437 supports 103 vérification 541
création d' un ID utilisateur 431 même système, via le réseau 149 mise à jour 66
création d'une instance de nouveau système, via des modifications dans la version 6 60
serveur 432 supports 193 nouveau 60
création de la base de nouveau système, via le supprimé 75
données 432 réseau 245 options de démarrage
création de répertoires 431 objectif général 307 modification du répertoire de travail
installation du serveur 426 processus 13 en cours 9
Scénario de migration 3 serveur permutation des ID utilisateur 9
Création d'un ID utilisateur 443 présentation générale 1 utilitaire DSMSERV 9
création de répertoires 443 système existant, serveur V5 options de serveur
Scénario de migration 4 comparaison avec une nouvelle migré à partir de z/OS 511
configuration en vue d'une mise à niveau système 15 options du serveur
sauvegarde de la base de utilisation de l'interface de commande mise à jour 66
données 456 procédures de scénarios 135, 180, nouveau 60
Création d'un ID utilisateur 450 221, 272, 339 supprimé 75
création d'une instance de procédures générales 339
serveur 451 mise à niveau manuelle
création de la base de
données 451
Voir mise à niveau à l'aide de
l'interface de commande
P
Passport Advantage xx
création de répertoires 450 mise à niveau vers le serveur version 6.3
performances des connexions réseau
Transfert de la base de données du ou ultérieure
migration de z/OS 492
serveur 454 procédures de scénarios
performances des processus de mise à
serveur même système, via des
niveau
contrôle 471 supports 103
conseils
sessions même système, via le réseau 149
extraction, serveur V5 52
désactivation 406 nouveau système, via des
insertion, serveur version 6.3 ou
tâches de post-migration 459 supports 193
ultérieure 53
transfert de données depuis des nouveau système, via le
estimation 50
périphériques FILE et DISK 400 réseau 245
périphériques
transfert de données depuis des procédures générales 307
configuration
périphériques GENERICTAPE 400 mise à niveau vers le serveur version
migration des serveurs à partir d'
via des supports 417 V6.3 ou une version ultérieure
AIX, HP-UX, ou Solaris 420,
via un réseau 417 rétablissement de la version V5 380
428, 442, 449
migration des serveurs à partir de AIX, Mises à jour Tivoli Monitoring
migration des serveurs d'AIX,
HP-UX, ou Solaris V6.3.3 xxv
HP-UX, or Solaris 429
astuces de performances Mises à jour Tivoli Monitoring version
planification d'une mise à niveau
insertion de la base de 6.3.4 xxiii
agents de stockage 54, 56
données 402 mode journal de reprise 6
espace requis
données stockées sur les modules de langue 585
système de serveur version 5 44
périphériques DISK Mot de passe authentifié par LDAP xxiv
espaces requis
migration 407
processus de mise à niveau 44
planification d'une mise à niveau (suite) préparation de la mise à niveau (suite) sauvegardes
espaces requis (suite) sauvegarde des informations de avant la mise à niveau
système de serveur version6.3 ou configuration pools de stockage z/OS 527
ultérieure 45 procédures de scénarios 111, 157, base de données
estimation du temps nécessaire 50, 201, 252 après la migration à partir de
51 procédures générales 316 z/OS 550
postes clients 56 sauvegardes de pool de stockage après la mise à niveau 363
programme client 56 procédures de scénarios 110, 156, automatique 6
référence 60 200, 251 Avant la migration des données à
serveur 13 procédures générales 315 partir d'AIX, HP-UX, ou
environnement de cluster préparation du serveur version 5 Solaris 465
AIX 295 migration de serveurs à partir de fichier historique de volume 6
environnement de cluster z/OS 522 protection 6
Windows 297, 300 produits DB2, compatibilité avec le reprise 6
serveurs multiples 54 serveur 40, 496 configuration de l'API pour la base de
plusieurs composants propriété données
migration des serveurs depuis AIX, pools de stockage sur disque 355 procédures de scénarios 144, 188,
HP-UX, ou Solaris 400 publications 240, 290
mise à niveau à partir de z/OS 503 Tivoli Storage Manager xiv procédures générales 351
plusieurs copies DB2 40 configuration du gestionnaire de base
pools de stockage de données
définition en vue de la migration à
partir de z/OS 549
R procédures de scénarios 144, 188,
240, 290
réorganisation d'index
recréation procédures générales 351
Après migration des serveurs à partir
migration z/OS 548 sauvegardes avant la migration z/OS
d' AIX, HP-UX, ou Solaris 459
restauration dans le cadre de la base de données de serveur 530
réorganisation de table
migration à partir de z/OS 549 informations de configuration 516
Après migration des serveurs à partir
sauvegardes avant mise à niveau pools de stockage 486
d' AIX, HP-UX, ou Solaris 459
procédures de scénarios 110, 156, sauvegardes avant mise à niveau
répertoires
200, 251 base de données
création d'un nom d' une instance de
procédures générales 315 procédures de scénarios 110, 156,
serveur
vérification de l'accès 355 200, 251
migration des serveurs à partir d'
pools de stockage de copie procédures générales 315
AIX, HP-UX, ou Solaris 431,
suppression des volumes basés sur informations de configuration
443, 450
disque 526 procédures de scénarios 111, 157,
création pour une instance de serveur
postes clients 201, 252
migration des serveurs depuis AIX,
modifications des paramètres pour la procédures générales 316
HP-UX ou Solaris 421
mise à niveau pools de stockage
résolution de problèmes
procédures de scénarios 109, 154, procédures de scénarios 110, 156,
problèmes courants 371
198, 250 200, 251
ressources de processus du serveur
planification d'une mise à niveau 56 procédures générales 315
estimation du nombre total 591
préparation de la migration z/OS sauvegardes de base de données
utilisation de SAM avec 11iv2 pour
sauvegarde des informations de planification 13, 503
afficher ou modifier 592
configuration 516 migration des serveurs depuis AIX,
utilisation de SMH avec 11iv3 pour
préparation de la mise à niveau HP-UX, ou Solaris 401
base de données Scénario de migration 2
ressources de sémaphore du serveur
procédures de scénarios 120, 166, extraction des données 425
estimation du nombre de 591
222, 273 migration des serveurs à partir d' AIX,
utilisation de SAM avec 11iv2 pour
procédures générales 325 HP-UX, ou Solaris 425
opérations du serveur 59 scénarios
utilisation de SMH avec 11iv3 pour
préparation de l'espace migration de serveurs à partir de
procédures de scénarios 108, 154, systèmes AIX, HP-UX, ou
ressources pour système HP
197, 249 Solaris 388
remarques sur les processus 591
procédures générales 312 migration de z/OS 477
remarques sur les sémaphores 591
présentation générale présentation de la mise à niveau 85
rétablissement de la version antérieure du
procédures de scénarios 103, 149, procédures de mise à niveau
serveur 371
193, 245 même système, via des
procédures générales 308 supports 103
sauvegarde de base de données même système, via le réseau 149
procédures de scénarios 110, 156, S nouveau système, via des
200, 251 Sauvegarde avant la migration de supports 193
procédures générales 315 données à partir des systèmes AIX, nouveau système, via le
sauvegarde de l'historique des HP-UX, ou Solaris réseau 245
volumes base de données serveur 409 scripts
procédures de scénarios 111, 157, sauvegarde des informations de configuration de l'environnement 9
201, 252 configuration 516 démarrage automatique des
procédures générales 316 serveurs 361, 463
Index 613
scripts (suite) serveur (suite) serveur (suite)
implémentation 366 démarrage (suite) options de démarrage
après la migration à partir de à partir de l'ID utilisateur DSMSERV 9
z/OS 551 root 361 modification du répertoire de
après la migration depuis AIX, automatique 361, 463 travail en cours 9
HP-UX ou Solaris 471 modifications dans la version 6.3 permutation des ID utilisateur 9
présentation 561 ou ultérieure 9 options mises à jour 66
rc.dsmserv 9, 361, 463 sous Windows 10, 362 options supprimées 75
SELECT, commande 79 sur AIX, HP-UX, Linux, protection au cours de la
serveur Solaris 357 migration 490
après la migration à partir de z/OS démarrage après migration 460, 462, restauration du serveur version 5
démarrage automatique du 463 après la migration à partir de
serveur 546 démarrage après une mise à z/OS 555
démarrage du serveur à partir de niveau 357 après la migration depuis AIX,
l'ID utilisateur root 546 exécution avec ID utilisateur HP-UX, ou Solaris 473
instance de démarrage 543 root 361 après la suppression de la base de
premières étapes 541 fichiers données du serveur version
vérification des opérations de dénomination 10 5 556
serveur 548 emplacement 10 avant la suppression des
après la migration depuis AIX, HP-UX installation de la version 6.3 volumes 555
ou Solaris migration à partir de z/OS 516 avant le déplacement des
vérification des opérations de installation de la version 6.3.4 or ou données 555
serveur 464 ultérieure rétablissement de la version V5
après la mise à niveau migration des serveurs à partir d' après la mise à niveau 380
premières étapes 355 AIX, HP-UX, ou Solaris 418, 426 service Solaris 356
arrêt 530 migration des serveurs depuis AIX, service Windows 144, 187, 239, 289,
migration des serveurs depuis AIX, HP-UX, ou Solaris 439, 446 350
HP-UX, ou Solaris 412 installation de la version 6.3 ou utilitaires
arrêt avant mise à niveau ultérieure mise à jour 66
procédures de scénarios 112, 158, procédures de scénarios 124, 169, modifications dans la version
202, 253 211, 224, 262, 274 6 60
procédures générales 317 procédures générales 329 nouveau 60
avant la migration instance de démarrage 357 supprimé 75
déterminer le niveau approprié du à partir de l'ID utilisateur utilitaires mis à jour 66
groupe de correctifs 42 d'instance 545 utilitaires supprimés 75
préparer le serveur sur z/OS 579 instances vérification des conditions requises
avant la migration à partir de z/OS démarrage 9, 10 procédures de scénarios 104, 150,
planification 495 ID de propriétaire 8 194, 246
avant la migration depuis AIX, multiples sur un système procédures générales 308
HP-UX, ou Solaris unique 8 vérification des exigences
planification 397 propriétaire, création 329 procédures de scénarios 104, 150,
avant la mise à niveau messages 81 194, 246
déterminer le niveau approprié du migration des serveurs à partir d' AIX, procédures générales 308
groupe de correctifs 42 HP-UX, ou Solaris 406 serveur multimédia
indiquer la classe d'unités des migration via un réseau 536 Voir serveur multimédia z/OS
volumes pour la mise à niveau, planification 13 serveur multimédia z/OS 477, 485
suppression 562 Mise à niveau du serveur version 5 commande ZMSPREPARE
préparer une base de données vers la version 5.5.6 406 vérifier les conditions prérequises
vide 574 modification des paramètres de la migration 529
changements apportés aux paramètres avant la migration depuis AIX, configuration 523
en vue de la migration 521 Linux ou Solaris 410 définition 523
commandes modifications des paramètres pour la fonctionnalité 475
administration 11 mise à niveau installation 523
mise à jour 66 procédures de scénarios 109, 154, messages 491
modifications dans la version 198, 250 migration d'unité 486
6 60 procédures générales 313 migration de données 524
nouveau 60 modifications liées aux opérations 4 migration des données vers d'autres
supprimé 75 nouveaux utilitaires 60 périphériques 554
commandes mises à jour 66 nouvelles commandes 60 présentation du produit 481
commandes supprimées 75 nouvelles options 60 suppression des groupes de
compatibilité options sauvegarde 528
produits DB2 40 mise à jour 66 vérification des conditions prérequises
versions antérieures 54 modifications dans la version de la migration 529
configuration 357 6 60 serveurs multiple, mise à niveau 54
démarrage 362 nouveau 60 serveurs multiples
à partir de l'ID utilisateur auquel supprimé 75 migration des serveurs depuis AIX,
appartient l'instance 360 HP-UX, ou Solaris 400
serveurs multiples (suite) transfert de données utilitaires de mise à niveau (suite)
mise à niveau 54 Avant la migration des données à installation sur Windows
mise à niveau à partir de z/OS 503 partir d'AIX, HP-UX, ou procédures de scénarios 120, 165,
service client Solaris 407, 408 210, 261
contact xix procédures générales 324
service de support logiciel journaux, emplacement 10
contact xix
services Solaris
U présentation 561
présentation de DSMUPGRD 18
unités
création pour instances de présentation générale 18
mise à jour des informations du
serveur 356 serveur V5
chemin d'accès à l'unité
services sur des systèmes Solaris DSMUPGRD QUERYDB 561
après la migration depuis AIX,
création pour instances de Serveur V5
HP-UX ou Solaris 465
serveur 356 DSMUPGRD EXTEND LOG 573
unités d'exécution 592
services sur des systèmes Windows transfert de données, méthodes 17
unités de bande
création pour instances de utilisation pour mise à niveau
déplacement des données après
serveur 144, 187, 239, 289, 350 procédures de scénarios 135, 180,
migration 469
DB2 597 221, 272
Utilitaire DSMSERV
démarrage d'un serveur 10 procédures générales 339
LOADFORMAT 574
gestionnaire de base de données 10 variables d'environnement, paramètres
Utilitaire DSMUPGRD EXTEND LOG
gestionnaire de base de données procédures de scénarios 119, 164,
augmenter la taille du journal du
(DB2TSM1) 597 209, 260
serveur V5 573
serveur 597 procédures générales 324
utilitaire DSMUPGRD UPDATE 574
services Windows utilitaires du serveur
utilitaires
création pour instances de mise à jour 66
Voir aussi utilitaires de mise à niveau
serveur 144, 187, 239, 289, 350 nouveau 60
DSMSERV LOADFORMAT 574
Serveur Tivoli Storage Manager 597 supprimé 75
DSMUPGRD UPDATE 574
sessions
désactivation
Avant la migration des données à
partir d'AIX, HP-UX, ou
mise à jour 66 V
modifications dans la version 6 60 variable d'environnement
Solaris 406
nouveau 60 DSMSERV_CONFIG
désactivation avant la mise à
supprimé 75 configuration des utilitaires de mise à
niveau 110, 155, 200, 251, 315, 524
utilitaires de migration niveau
SQL
présentation 561 procédures de scénarios 164
modifications de la syntaxe dans la
utilitaires de mise à niveau variable d'environnement DSMSERV_DIR
version 6.3 ou ultérieure 79
base de données version 5 configuration des utilitaires de mise à
requêtes dans la version 6.3 ou
BACKUP STGPOOL 527 niveau
ultérieure 3
DSMUPGRD EXTEND DB 572 procédures de scénarios 119, 164,
SELECT, commande 79
DSMUPGRD EXTRACTDB 567 209, 260
support de langue 589
DSMUPGRD PREPAREDB 561 procédures générales 324
support de langue nationale de la
DSMUPGRD QUERYDB 561 obsolète pour la version 6.3 ou
console 585
ZMSPREPARE 524 ultérieure 10
support logiciel
création d'un serveur de test 56 variables d'environnement
description du problème pour
DSMSERV_DIR 10 configuration des utilitaires de mise à
l'assistance logicielle IBM xx
installation sur AIX niveau
détermination de l'incidence
avant la migration depuis AIX, procédures de scénarios 119, 164,
commerciale pour l'assistance
HP-UX, ou Solaris 412 209, 260
logicielle IBM xx
procédures de scénarios 114, 159, procédures générales 324
soumission d'un incident xxi
203, 254 modifications dans la version 6.3 ou
surveillance après la migration vers z/OS
procédures générales 318 ultérieure 10
serveur 552
installation sur HP-UX serveur version 6.3 ou ultérieure 10
avant la migration depuis AIX, utilitaires de mise à niveau 10
HP-UX, ou Solaris 414 VARY, commande
T procédures de scénarios 115, 161, identification et résolution des
tcpserveraddress, option 205, 256 problèmes 380
mise à jour procédures générales 320 vérification de la mise à niveau
après la migration depuis AIX, installation sur Linux opérations du serveur 364
HP-UX ou Solaris 467 procédures de scénarios 117, 162, via des supports 17, 490, 533
technologie DB2 3 206, 257 via un réseau 17, 490
test procédures générales 321 migration de serveurs à partir de
avant la mise à niveau 56 installation sur Oracle Solaris z/OS 536
Tivoli Storage Manager base de données avant la migration depuis AIX, volumes
de serveur HP-UX, ou Solaris 415 suppression dans le cadre de la
Voir base de données procédures de scénarios 118, 163, migration à partir de z/OS 550
Tivoli Storage Manager for z/OS Media 207, 259 volumes de pool de stockage
Voir serveur multimédia z/OS procédures générales 322 recréation 549
traductions 585
Index 615
Z
Zones Solaris 593

Numéro de programme : 5608-E01

5608-E02
5608-E03
Imprimé en France
GC11-6978-02

Guide de Mise À Niveau Et de Migration Des Serveurs v5 Vers 6.3.4 - Upgrade - Guide PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Guide de Mise À Niveau Et de Migration Des Serveurs v5 Vers 6.3.4 - Upgrade - Guide PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

IBM Tivoli Storage Manager

Guide de mise à niveau et de migration des

Guide de mise à niveau et de migration des

Table des matières v

Table des matières vii

Table des matières ix

Table des matières xi

A qui s'adresse ce guide

La compréhension des informations fournies dans ce guide requiert des

Comment utiliser ce guide

Si vous mettez à niveau le serveur de la V5 vers la V6.3 ou ultérieure sur le même

© Copyright IBM Corp. 2009, 2013 xiii

Si vous mettez à niveau le serveur de la V5 vers la V6.3 ou ultérieure sur un autre

Accédez à Tivoli Documentation Central pour trouver des centres de

Publications Tivoli Storage Manager

Tableau 2. Publications associées à l'agent de stockage Tivoli Storage Manager

Tableau 3. Publications associées au client Tivoli Storage Manager

Tableau 4. Publications associées à la protection des données Tivoli Storage Manager

Tableau 5. Publications relatives à l'identification des problèmes et à l'optimisation d'IBM

Commencez par le portail de support IBM : http://www.ibm.com/support/entry/

Obtention d'une formation technique

Recherche dans les bases de connaissances

Commencez par rechercher le centre de documentation Tivoli Storage Manager à

Vous pouvez rechercher des informations sans vous abonner. Connectez-vous à

Si vous ne trouvez aucune solution permettant de résoudre cet incident, vous

Utilisation d'IBM Support Assistant

Recherche des correctifs du produit

Réception d'une notification sur les correctifs de produit

Contacter le service de support logiciel IBM

Configuration d'un contrat d'abonnement et de support

Détermination de l'impact commercial

Gravité 1 Incidence commerciale critique : il vous est impossible d'utiliser

Description du problème et collecte des informations

Pour gagner du temps, connaissez les réponses à ces questions :

Soumission du problème au service de support logiciel IBM

Mises à jour du serveur

Nouveautés du serveur dans la version 6.3.4

| Migration Tivoli Storage Manager vers la V6.3.4 ou ultérieure

| En fonction de votre environnement matériel et logiciel, cette procédure de

| Centre d'opérations IBM Tivoli Storage Manager

| Centre d'opérations V6.4.1 contient une page de présentation de l'interaction des

| Mises à jour Tivoli Monitoring for Tivoli Storage Manager

| Les nouveaux rapports Cognos suivants sont disponibles :

© Copyright IBM Corp. 2009, 2013 xxiii

| Les valeurs d'élagage sont automatiquement configurées maintenant au cours de

Nouveautés du serveur dans la version 6.3.3

Mots de passe authentifiés par LDAP

Prévention des conflits par le pilote du périphérique

La fonction rmstdev fonctionne lorsque le serveur démarre automatiquement. Si le

Mises à jour Tivoli Monitoring for Tivoli Storage Manager

Les nouveaux rapports Cognos sont :

Des informations de sauvegarde VMware supplémentaires sont désormais fournies

Nouveautés de la version 6.3 xxv

Une nouvelle option permettant d'activer l'authentification LDAP en créant et en

La capacité améliorée à exclure ou à filtrer les numéros de messages pour affiner

Contrôle des connexions inactives de l'opération NDMP

Améliorations pour le traitement à l'expiration

Nouveautés du serveur dans la version 6.3.1

Validation des données au cours des opérations de

Nouveautés du serveur dans la version 6.3.0

La réplication de poste évite la logistique et les risques liés au déplacement

Si vous utilisez les fonctions d'exportation et d'importation de Tivoli Storage

Dédoublonnage de données de serveur de fichiers NetApp