D59999FR10 sg1 PDF

THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY.
COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
D69793
Edition 1.0
Février 2011
D59999FR10
Manuel du stagiaire - Volume I
Gestion des clusters et ASM
Oracle Grid Infrastructure 11g :
Oracle University and CFAO THECHNOLOGIES use only

#WVGWTU Copyright © 2010, Oracle. Tous droits réservés.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
James Womack Avertissement
James Spiller Cette documentation contient des informations qui sont la propriété d'Oracle
Corporation et sont protégées par les lois relatives aux droits d'auteur et à la propriété
intellectuelle. Vous ne pouvez copier et imprimer ce document qu'à des fins d'utilisation
%QPVTKDWVKQPUVGEJPKSWGU personnelle lors de la participation à une formation dispensée par Oracle. Le document
ne peut être modifié ou altéré en aucune manière. A l'exception des cas où l'utilisation
David Brower faite du document s'inscrit dans le respect des lois relatives aux droits d'auteur, vous
Jean-Francois Verrier ne pouvez pas utiliser, partager, télécharger, copier, imprimer, afficher, exécuter,
reproduire, publier, breveter, diffuser, transmettre ou distribuer ce document, en partie
Mark Fuller ou en totalité, sans l'autorisation expresse d'Oracle.
Mike Leatherman
Barb Lundhild Les informations fournies dans ce document sont susceptibles de modification sans
préavis. Par ailleurs, Oracle Corporation ne garantit pas qu'elles soient exemptes
S. Matt Taylor d'erreurs et vous invite, le cas échéant, à lui en faire part par écrit à l'adresse suivante :
Rick Wessman Oracle University, 500 Oracle Parkway, Redwood Shores, California 94065 USA.

Restrictions applicables au gouvernement américain : ̘
4ÃXKUKQPUVGEJPKSWGU Restricted Rights Notice
Christopher Andrews If this documentation is delivered to the United States Government or anyone using the
Christian Bauwens documentation on behalf of the United States Government, the following notice is
Michael Cebulla applicable:
Jonathan Creighton U.S. GOVERNMENT RIGHTS
Al Flournoy The U.S. Government’s rights to use, modify, reproduce, release, perform, display, or
Andy Fortunak disclose these training materials are restricted by the terms of the applicable Oracle
license agreement and/or the applicable U.S. Government contract.
Joel Goodman
Michael Hazel Marques
Pete Jones Oracle est une marque déposée d'Oracle Corporation et/ou de ses filiales.. Tout autre
Jerry Lee nom de produit ou de société peut être une marque de son propriétaire.
Markus Michalewicz
Peter Sharman
Ranbir Singh
Linda Smalley
Janet Stern
Richard Strohm
Branislav Valny
Doug Williams
'FKVGWTU
,C[CPVJ[-GUJCXCOWTVJ[
)KTK8GPWIQRCN
Table des matières
1 Architecture d'Oracle Grid Infrastructure

Objectifs 1-2
Oracle Grid Infrastructure 1-3
Module 1 : Concepts Oracle Clusterware 1-4
Qu'est-ce qu'un cluster ? 1-5
Qu'est-ce qu'un clusterware ? 1-6
Oracle Clusterware 1-7

Architecture et services d'Oracle Clusterware 1-8
Objectifs d'Oracle Clusterware 1-9
Gestion de réseau avec Oracle Clusterware 1-10
Agrégation de liaisons : Commutateur simple 1-12
Agrégation de liaisons : Commutateurs multiples 1-14
Recommandations relatives aux cartes réseau d'interconnexion 1-15
Autres recommandations relatives à l'interconnexion 1-16
Quiz 1-17
Module 2 : Architecture d'Oracle Clusterware 1-18
Démarrage d'Oracle Clusterware 1-19
Architecture des processus d'Oracle Clusterware 1-20
Grid Plug and Play 1-22
Domaine GPnP 1-23
Composants GPnP 1-24
Profil GPnP 1-25
Service GNS (Grid Naming Service) 1-26
Nom SCAN (Single Client Access Name) 1-27
Présentation de l'architecture de GPnP 1-29
Fonctionnement de GPnP : Démarrage d'un noeud du cluster 1-31
Fonctionnement de GPnP : Connexions de base de données client 1-32
Quiz 1-33
Module 3 : Architecture d'ASM 1-35
Qu'est-ce qu'Oracle ASM ? 1-36
ASM et ASM Cluster File System 1-37
Fonctionnalités et avantages principaux d'ASM 1-39
Conceptions d'instance ASM : Environnement ASM non clusterisé et bases
de données Oracle 1-40
Conceptions d'instance ASM : Environnement ASM clusterisé pour des bases
de données de cluster 1-41
de données mixtes 1-42
Privilèges système ASM 1-43
Groupes OS ASM avec séparation des rôles 1-44
Authentification pour l'accès aux instances ASM 1-45
iii
Authentification basée sur un mot de passe pour ASM 1-46
Gérer le fichier de mots de passe ASM 1-47
Utiliser un groupe OS unique 1-48

Utiliser des groupes OS distincts 1-49
Composants ASM : Logiciels 1-50
Composants ASM : Instance ASM 1-51
Composants ASM : Processus principaux 1-53
Composants ASM : Processus d'écoute ASM 1-54
Composants ASM : Fichiers de configuration 1-55
Composants ASM : Services de groupe 1-56
Composants ASM : Groupe de disques ASM 1-57
Groupe de disques ASM : Groupes d'échec 1-58

Composants d'une instance ASM : Disques ASM 1-59
Composants ASM : Fichiers ASM 1-60
Fichiers ASM : Extents et stripping 1-61
Fichiers ASM : Mise en miroir 1-62
Composants ASM : Clients ASM 1-63
Composants ASM : Utilitaires ASM 1-64
Evolutivité d'ASM 1-65
Synthèse 1-66
2 Installation de Grid Infrastructure

Objectifs 2-2
Module 1 : Planification de la préinstallation 2-3
Planification du stockage partagé pour Grid Infrastructure 2-4
Dimensionnement du stockage partagé 2-5
Stocker le registre OCR dans ASM 2-6
Référentiel OCR (Oracle Clusterware Repository) 2-7
Gérer les disques votants dans ASM 2-9
Service CSS 2-10
Principaux fichiers journaux d'Oracle Clusterware 2-11
Installer ASMLib 2-12
Préparer ASMLib 2-13
Quiz 2-14
Module 2 : Tâches préalables à l'installation de Grid Infrastructure 2-15
Installation d'Oracle Grid Infrastructure 11g 2-16
Vérifier la configuration système 2-17
Vérifier la configuration réseau 2-18
Configuration logicielle (noyau) 2-20
Configuration logicielle : Packages 2-21
Module Oracle Validated Configuration RPM 2-22
Créer des utilisateurs et des groupes 2-24
Créer des groupes et des utilisateurs : Exemple 2-25
Paramètres du shell pour l'utilisateur de Grid Infrastructure 2-26
Quiz 2-28
Module 3 : Installation de Grid Infrastructure 2-29
iv
Installer Grid Infrastructure 2-30
Fonctionnalité Grid Plug and Play 2-31
Informations sur les noeuds du cluster 2-32

Définir l'utilisation de l'interface réseau 2-33
Informations sur les options de stockage 2-34
Isolement des pannes avec IPMI 2-35
Groupes dotés de privilèges du système d'exploitation 2-36
Emplacements d'installation et d'inventaire 2-37
Vérification des prérequis 2-38
Terminer l'installation 2-39
Vérifier l'installation d'Oracle Grid Infrastructure 2-40
Module 4 : Configurer des groupes de disques ASM et ACFS 2-41

Configurer ASM avec ASMCA 2-42
Créer un groupe de disques ASM avec ASMCA 2-43
Créer un groupe de disques ASM : Options avancées 2-44
Créer un groupe de disques avec Enterprise Manager 2-45
Créer un groupe de disques ASM avec les outils en mode ligne
de commande 2-47
Configurer un volume ASM : ASMCA 2-48
Configurer un volume ASM : EM 2-49
Configurer un volume ASM : ASMCMD et SQL 2-50
Configurer un système de fichiers ACFS 2-51
Configurer un système de fichiers ACFS avec EM 2-52
Configurer un système de fichiers ACFS à partir de la ligne de commande 2-53
Monter un système de fichiers ACFS avec ASMCA 2-54
Monter un système de fichiers ACFS avec EM 2-55
Monter un système de fichiers ACFS avec les outils en mode ligne
de commande 2-56
Synthèse 2-57
Exercice 2 : Présentation 2-58
Quiz 2-59
3 Administrer Oracle Clusterware

Objectifs 3-2
Gérer Oracle Clusterware 3-3
Gérer Oracle Clusterware avec Enterprise Manager 3-4
Contrôler Oracle Clusterware 3-5
Vérifier le statut d'Oracle Clusterware 3-6
Déterminer l'emplacement des fichiers de configuration
d'Oracle Clusterware 3-7
Vérifier l'intégrité des fichiers de configuration d'Oracle Clusterware 3-8
Sauvegarder et récupérer un disque votant 3-9
Ajouter, supprimer, ou migrer des disques votants 3-10
Localiser les sauvegardes automatiques du registre OCR 3-11
Modifier l'emplacement de la sauvegarde automatique du registre OCR 3-12
Ajouter, remplacer et réparer un emplacement de registre OCR 3-13
v
Supprimer un emplacement de registre OCR 3-14
Migrer des emplacements OCR vers ASM 3-15
Migration d'un registre OCR d'une unité ASM vers une autre unité
de stockage partagé 3-17
Exécuter des sauvegardes manuelles du registre OCR 3-18
Récupérer le registre OCR à l'aide de sauvegardes physiques 3-19
Récupérer le registre OCR à l'aide de sauvegardes logiques 3-20
Registre Oracle Local Registry 3-21
Déterminer les paramètres réseau en cours 3-23
Modifier des adresses IP virtuelles publiques 3-24
Modifier l'adaptateur d'interconnexion 3-26
Gérer les ressources de type adresse VIP et processus d'écoute SCAN 3-28

Gérer les ressources associées aux adresses VIP et aux processus d'écoute
SCAN 3-29
Quiz 3-31
Synthèse 3-33
4 Gérer Oracle Clusterware

Module 4-1 Ajouter et supprimer des répertoires d'origine
Oracle Clusterware 4-2
Objectifs 4-3
Ajouter des répertoires d'origine Oracle Clusterware 4-4
Opérations requises avant d'exécuter addNode.sh 4-5
Ajouter un noeud avec addNode.sh 4-7
Terminer l'ajout de noeud en mode silencieux 4-8
Supprimer un noeud du cluster 4-9
Supprimer un noeud d'un cluster (utilisation de GNS) 4-13
Supprimer un noeud du cluster 4-14
Quiz 4-15
Synthèse 4-16
Module 4-2 Appliquer des patches à Oracle Clusterware 4-17
Objectifs 4-18
Mise à niveau "out-of-place" d'Oracle Clusterware 4-19
Mise à niveau d'Oracle Clusterware 4-20
Types de patch 4-21
Propriétés des patches 4-23
Configurer la bibliothèque de logiciels 4-24
Configurer l'application des patches 4-25
Démarrer le démon de provisionnement 4-26
Obtenir des patches Oracle Clusterware 4-27
Charger des patches 4-29
Gestionnaire de procédure de déploiement 4-31
Appliquer des patches avec un temps d'arrêt réduit dans les environnements
de cluster 4-32
Appliquer des patches de manière non simultanée 4-33
vi
Vérifier les versions d'un logiciel 4-34
Installer un jeu de patches de manière non simultanée à l'aide d'OUI 4-35
Installer un jeu de patches avec OUI 4-37

Installer un jeu de patches de manière non simultanée à l'aide d'OUI 4-38
OPatch : Présentation 4-39
OPatch : Utilisation générale 4-41
Avant d'appliquer des patches avec OPatch 4-42
Installer un patch de manière non simultanée avec OPatch 4-43
Installer un patch avec une période d'arrêt minimale en utilisant OPatch 4-45
Quiz 4-46
Synthèse 4-48

5 Assurer une haute disponibilité des applications avec Oracle Clusterware
Objectifs 5-2
Services de haute disponibilité d'Oracle Clusterware 5-3
Composants de haute disponibilité d'Oracle Clusterware 5-4
Options de gestion des ressources 5-5
Pools de serveurs 5-6
Attributs d'un pool de serveurs 5-7
Pools de serveurs GENERIC et FREE 5-9
Affectation de serveurs à des pools 5-11
Attributs et états des serveurs 5-12
Créer des pools de serveurs avec srvctl et crsctl 5-14
Gérer les pools de serveurs avec srvctl et crsctl 5-15
Ajouter des pools de serveurs avec Enterprise Manager 5-16
Gérer les pools de serveurs avec Enterprise Manager 5-17
Modélisation des ressources Oracle Clusterware 5-18
Types de ressource 5-20
Ajouter un type de ressource 5-21
Paramètres d'un type de ressource 5-23
Paramètres avancés d'un type de ressource 5-24
Définir des dépendances entre ressources 5-25
Créer une adresse IP virtuelle d'application en utilisant crsctl 5-27
Créer une adresse IP virtuelle d'application à l'aide d'EM 5-29
Gérer les ressources Oracle Clusterware avec EM 5-30
Ajouter des ressources avec EM 5-31
Ajouter des ressources à l'aide de crsctl 5-36
Gérer les ressources avec EM 5-37
Gérer les ressources avec crsctl 5-40
Evénements de haute disponibilité : ONS et FAN 5-42
Gérer un serveur ONS avec srvctl 5-43
Quiz 5-44
Synthèse 5-46
vii
6 Dépanner Oracle Clusterware
Objectifs 6-2
Règle d'or pour le débogage d'Oracle Clusterware 6-3

Principaux fichiers journaux d'Oracle Clusterware 6-5
Script de collecte des informations de diagnostic 6-7
Utilitaire de vérification de cluster : Présentation 6-8
Utilitaire de vérification de cluster : Vérification des composants 6-9
Utilitaire de vérification de cluster (cluvfy) : Emplacements 6-10
Utilitaire de vérification de cluster (cluvfy) : Fichier de configuration 6-11
Utilitaire de vérification de cluster (cluvfy) : Exemple de sortie 6-13
Activer le débogage des ressources 6-14
Débogage dynamique 6-15

Activer la fonction de trace pour les outils basés sur Java 6-16
Préserver les fichiers journaux avant leur réutilisation 6-17
Processus susceptibles de redémarrer des noeuds 6-18
Identifier le processus à l'origine d'un redémarrage 6-19
Utiliser diagwait pour la résolution des problèmes d'éviction 6-20
Module hangcheck-timer du noyau Linux 6-21
Configurer le module du noyau hangcheck-timer 6-22
Eviter les redémarrages intempestifs 6-23
Utiliser ocrdump pour afficher le contenu logique du registre OCR 6-24
Vérifier l'intégrité du registre OCR 6-25
Outils de débogage du registre OCR 6-26
Effectuer des recherches dans la page My Oracle Support - Knowledge 6-27
Synthèse 6-28
Quiz 6-29
7 Gérer les instances ASM

Objectifs 7-2
Paramètres d'initialisation ASM 7-3
Paramètre ASM_DISKGROUPS 7-5
Groupes de disques montés au démarrage 7-6
Paramètre ASM_DISKSTRING 7-7
Paramètre ASM_POWER_LIMIT 7-9
Paramètre INSTANCE_TYPE 7-10
Paramètre CLUSTER_DATABASE 7-11
Paramètre MEMORY_TARGET 7-12
Ajuster les paramètres des instances ASM dans les fichiers SPFILE 7-13
Démarrer et arrêter des instances ASM à l'aide de srvctl 7-14
Démarrer et arrêter des instances ASM à l'aide de SQL*Plus 7-15
Démarrer et arrêter des instances ASM avec ASMCA et ASMCMD 7-18
Démarrer et arrêter des instances ASM contenant des fichiers clusterisés 7-19
Démarrer et arrêter le processus d'écoute ASM 7-20
Vues dynamiques des performances ASM 7-21
Schéma des vues dynamiques des performances d'ASM 7-22
viii
Quiz 7-24
Synthèse 7-26
Présentation de l'exercice 7 : Gérer les instances ASM 7-27
8 Gérer les groupes de disques ASM

Objectifs 8-2
Présentation des groupes de disques 8-3
Créer un nouveau groupe de disques 8-4
Créer un nouveau groupe de disques avec ASMCMD 8-6
Attributs d'un groupe de disques 8-7
Vue V$ASM_ATTRIBUTE 8-9
Attributs de compatibilité 8-10

Fonctionnalités activées par les attributs de compatibilité des groupes
de disques 8-11
Prise en charge des disques avec une taille de secteur de 4 Ko 8-12
Prise en charge des disques avec secteurs de 4 Ko 8-13
Prise en charge d'ASM pour les disques avec secteurs de 4 Ko 8-14
Utiliser la clause SECTOR_SIZE 8-15
Visualiser les groupes de disques ASM 8-17
Visualiser les informations relatives aux disques ASM 8-19
Etendre un groupe de disques existant 8-21
Supprimer des disques d'un groupe existant 8-22
Clause REBALANCE POWER 0 8-23
Vue V$ASM_OPERATION 8-24
Ajouter et supprimer des disques dans la même commande 8-25
Ajouter et supprimer des groupes d'échec 8-26
Annuler la suppression de disques d'un groupe 8-27
Monter et démonter des groupes de disques 8-28
Afficher les clients connectés 8-30
Supprimer des groupes de disques 8-31
Vérifier la cohérence des métadonnées d'un groupe de disques 8-32
Fonctionnalité ASM Fast Mirror Resync 8-33
Groupes d'échec préférés pour la lecture 8-34
Groupes d'échec préférés pour la lecture Recommandations 8-35
Afficher les statistiques sur les disques ASM 8-36
Considérations sur les performances, l'évolutivité et la facilité de gestion pour
les groupes de disques 8-38
Quiz 8-39
Synthèse 8-41
Présentation de l'exercice 8 : Gérer les groupes de disques ASM 8-42
9 Gérer les fichiers, les répertoires et les modèles ASM

Objectifs 9-2
Clients ASM 9-3
Interaction entre les instances de base de données et ASM 9-5
Accéder aux fichiers ASM par le biais de RMAN 9-6
ix
Accéder aux fichiers ASM à l'aide d'Oracle XML DB 9-8
Accéder aux fichiers ASM à l'aide de DBMS_FILE_TRANSFER 9-9
Accéder aux fichiers ASM à l'aide de l'utilitaire ASMCMD 9-10

Noms de fichier ASM entièrement qualifiés 9-11
Autres noms de fichiers ASM 9-13
Contextes valides pour les types de nom de fichier ASM 9-15
Création d'un fichier unique - Exemples 9-16
Création de plusieurs fichiers - Exemple 9-17
Afficher les alias, les fichiers et les répertoires ASM 9-18
Afficher les fichiers ASM 9-20
Répertoires ASM 9-21
Gérer les répertoires ASM 9-22

Gérer les alias de fichier 9-23
Positionnement intelligent des données ASM 9-24
Règles pour le positionnement intelligent des données 9-25
Affecter des fichiers à une zone d'un disque 9-26
Affecter des fichiers à une zone d'un disque avec Enterprise Manager 9-27
Surveiller le positionnement intelligent des données ASM 9-28
Modèles de groupes de disques 9-29
Visualiser les modèles 9-31
Gérer les modèles de groupes de disques 9-32
Gérer les modèles de groupes de disques avec ASMCMD 9-33
Utiliser des modèles de groupes de disques 9-34
Listes de contrôle d'accès ASM 9-35
Prérequis pour l'utilisation des listes de contrôle d'accès ASM 9-36
Gérer les listes de contrôle d'accès ASM à l'aide de commandes SQL 9-37
Gérer les listes de contrôle d'accès ASM à l'aide de commandes ASMCMD 9-38
Gérer les listes de contrôle d'accès ASM avec Enterprise Manager 9-39
Règles relatives aux listes de contrôle d'accès ASM 9-41
Quiz 9-42
Synthèse 9-44
10 Gérer les systèmes de fichiers clusterisés ASM

Objectifs 10-2
Volumes et fichiers ASM 10-3
Présentation de l'architecture ACFS et ADVM 10-4
Processus ADVM 10-7
Contraintes liées à ADVM 10-8
ASM Cluster File System 10-9
Allocation d'espace avec ADVM 10-11
Striping d'un volume 10-12
Striping de volume : Exemple 10-13
Créer un volume ACFS 10-15
Créer un volume ASM dynamique avec Enterprise Manager 10-16
Gérer les volumes ADVM dynamiques 10-19
Créer un système de fichiers ACSF avec Enterprise Manager 10-20
x
Gérer les volumes dynamiques avec SQL*PLUS 10-21
Enregistrer un volume ACFS 10-22
Créer un volume ACFS via ASMCA 10-23

Créer un système de fichiers ACFS avec ASMCA 10-24
Monter un système de fichiers ACFS avec ASMCA 10-25
Gérer ACFS avec EM 10-26
Etendre ASMCMD pour les volumes dynamiques 10-27
API Linux/UNIX pour les systèmes de fichiers 10-28
Extensions Linux/UNIX 10-29
Commandes ACFS indépendantes de la plateforme 10-30
Clichés ACFS 10-31
Gérer les clichés ACFS 10-32

Gérer les clichés ACFS avec Enterprise Manager 10-34
Créer des clichés ACFS 10-35
Gérer les clichés 10-36
Afficher un cliché 10-37
Sauvegardes ACFS 10-38
Performances ACFS 10-39
Utiliser des volumes ACFS après un redémarrage 10-40
Vues ACFS 10-41
Quiz 10-42
Synthèse 10-43
Présentation de l'exercice 10 : Gérer ACFS 10-44
Annexe A : Exercices et solutions
Annexe B: Cloner Oracle Clusterware

Objectifs B-2
Qu'est-ce que le clonage ? B-3
Avantages du clonage d'Oracle Clusterware B-4
Créer un cluster en clonant Oracle Clusterware B-5
Préparer le répertoire d'origine d'Oracle Clusterware pour le clonage B-6
Effectuer un clonage pour créer un nouvel environnement
Oracle Clusterware B-9
Script clone.pl B-11
Variables d'environnement du script clone.pl B-12
Options de commande du script clone.pl B-13
Effectuer un clonage pour créer un nouvel environnement
Oracle Clusterware B-14
Fichiers journaux générés au cours du clonage B-18
Clonage pour étendre Oracle Clusterware vers plusieurs noeuds B-20
Quiz B-25
Synthèse B-27
xi
xii
Copyright © 2010, Oracle. Tous droits réservés.

Architecture d'Oracle Grid Infrastructure

Objectifs
A la fin de ce chapitre, vous pourrez :

• expliquer les principes et les finalités des clusters
• décrire les recommandations relatives aux éléments
matériels des clusters
• décrire l'architecture d'Oracle Clusterware
• décrire comment Grid Plug and Play affecte Clusterware

• décrire l'architecture d'ASM (Automatic Storage
Management)
• décrire les composants d'ASM
Oracle Grid Infrastructure 11g : Gestion des clusters et ASM 1 - 2

Oracle Grid Infrastructure

• ASM et Oracle Clusterware sont installés dans un répertoire
d'origine unique appelé Oracle Grid Infrastructure 11g
Release 2.
• Ce répertoire est appelé le répertoire d'origine Grid
Infrastructure.

Oracle Grid Infrastructure

Dans Oracle Database 11g Release 2, Automatic Storage Management (ASM) et Oracle
Clusterware sont installés dans un même répertoire d'origine nommé Oracle Grid
Infrastructure. Ce répertoire est appelé le répertoire d'origine Grid Infrastructure. Les
assistants de configuration démarrent après le processus interactif et l'installation binaire
d'Oracle Universal Installer qui configurent ASM et Oracle Clusterware. Bien que
l'installation désigne Oracle Grid Infrastructure, Oracle Clusterware et Automatic Storage
Manager restent des composants distincts.
Dans ce chapitre, les concepts relatifs à Oracle Grid Infrastructure sont présentés dans trois
modules :
• Module 1 : Concepts Oracle Clusterware
• Module 2 : Architecture d'Oracle Clusterware
• Module 3 : Concepts et architecture ASM


Module 1 : Concepts Oracle Clusterware

Qu'est-ce qu'un cluster ?
• Groupe d'ordinateurs indépendants mais interconnectés

qui agissent comme un système unique
• Généralement déployé pour
accroître la disponibilité et
les performances, ou
pour équilibrer une charge
globale évoluant de façon

dynamique
Qu'est-ce qu'un cluster ?

Un cluster est constitué d'un groupe d'ordinateurs indépendants mais interconnectés dont les
ressources peuvent être utilisées conjointement pour une tâche de traitement. L'une des
caractéristiques d'un cluster est qu'il doit apparaître comme un serveur unique pour une
application. La plupart des architectures clusterisées utilisent un réseau dédié pour la
communication et la coordination entre les noeuds du cluster.
Une architecture clusterisée implémentée pour des transactions et des calculs impliquant
beaucoup de donnéesest généralement organisée autour d'un stockage sur disque partagé.
Les clusters sans ressources partagées utilisent une autre architecture dans laquelle le stockage
n'est pas partagé et où les données doivent être répliquées ou segmentées au sein du cluster.
Ils sont généralement utilisés pour les charges globales qui peuvent se diviser facilement et de
façon prévisible en unités de petite taille qu'il est possible de traiter en parallèle. Les clusters
avec disque partagé peuvent effectuer ces tâches tout en offrant la flexibilité requise par les
charges variables. Les clusters avec équilibrage de la charge permettent de répartir la charge
d'une application entre différents noeuds. Dans un cluster avec basculement en cas de panne,
certains noeuds peuvent être définis comme hôte principal d'une application, tandis que
d'autres servent d'hôte principal pour différentes applications. Lorsqu'un noeud tombe en
panne, les applications qu'il prend en charge sont déplacées vers un autre noeud. Les clusters
avec équilibrage de la charge peuvent fournir des fonctionnalités de basculement, mais ils
peuvent également exécuter une application sur plusieurs noeuds, ce qui offre une plus grande
flexibilité pour différentes charges globales. Oracle prend en charge une architecture
clusterisée avec disque partagé offrant des fonctionnalités d'équilibrage de la charge et de
basculement en cas de panne. Dans un cluster Oracle, tous les noeuds doivent partager la
même architecture de processeur et exécuter le même système d'exploitation.

Qu'est-ce qu'un clusterware ?
Logiciel qui fournit des interfaces et des services variés pour un

cluster. Ces fonctionnalités permettent en général les
opérations suivantes :
• Gérer le cluster dans son ensemble
• Protéger l'intégrité du cluster
• Tenir à jour le registre des ressources du cluster

• Gérer les modifications intervenant dans le cluster
• Fournir une vue commune des ressources
Qu'est-ce qu'un clusterware ?

Un clusterware est un logiciel qui fournit les interfaces et les services requis par un cluster.
Les différentes architectures clusterisées nécessitent un logiciel fournissant des services
spécifiques. Par exemple, dans un cluster simple avec basculement en cas de panne, le
clusterware peut surveiller la disponibilité des applications et effectuer un basculement si un
noeud devient indisponible. Dans un cluster avec équilibrage de la charge, différents services
sont requis pour permettre la simultanéité d'accès aux données et la coordination de la charge
globale.
En règle générale, un clusterware inclut des fonctionnalités permettant les opérations
suivantes :
• Permettre au cluster d'être géré comme une entité unique (en dehors des exigences du
système d'exploitation) si nécessaire.
• Assurer l'intégrité du cluster de sorte que les données soient protégées et que le cluster
continue à fonctionner en cas de problèmes de communication avec un noeud.
• Tenir à jour un registre des ressources afin que leur emplacement soit connu dans
l'ensemble du cluster et que les dépendances soient actualisées.
• Gérer les modifications intervenant dans le cluster telles que les ajouts ou les
suppressions de noeuds, ou les défaillances.
• Fournir une vue commune des ressources telles que les adresses réseau et les fichiers d'un
système de fichiers.

Oracle Clusterware
Oracle Clusterware :
• Elément clé d'Oracle Grid Infrastructure
• Intégré à Oracle
Automatic Storage
Management (ASM)
• Base du système de fichiers

clusterisé ASM (ACFS)
• Socle d'Oracle
Real Application Clusters
(RAC)
• Infrastructure générale de
cluster pour toutes sortes
d'applications
Oracle Clusterware
Oracle Clusterware est un élément clé d'Oracle Grid Infrastructure, qui inclut également
Automatic Storage Management (ASM) et ASM Cluster File System (ACFS).
Dans la version 11.2, Oracle Clusterware peut utiliser ASM pour tous les fichiers partagés
requis par le cluster. Par ailleurs, Oracle Clusterware offre ASM Cluster File System, un
système de fichiers clusterisé généraliste qui peut être utilisé pour la plupart des données
stockées sous forme defichiers (documents, feuilles de calcul, états, etc.).
La combinaison d'Oracle Clusterware, d'ASM et d'ACFS fournit aux administrateurs une
solution de cluster unifiée qui constitue le socle d'une base de données Oracle
RealApplication Clusters (RAC) tout en pouvant s'appliquer à toutes sortes d'applications.
Remarque : Grid Infrastructure est un terme collectif désignant Oracle Clusterware, ASM
et ACFS. Ces composants sont si étroitement intégrés qu'on utilise l'appellation collective
Oracle Grid Infrastructure. Dans ce chapitre, ASM et ACFS sont mentionnés dans certaines
sections. Cependant, ils seront traités plus en détail dans des chapitres ultérieurs.

Architecture et services d'Oracle Clusterware
• Architecture de cluster avec disque partagé prenant en

charge l'équilibrage de la charge et le basculement
• Services inclus :
– Gestion du cluster
– Surveillance des noeuds
– Services déclenchés

par un événement
– Synchronisation
temporelle
– Gestion du réseau
– Haute disponibilité
Architecture et services d'Oracle Clusterware

Oracle Clusterware fournit un ensemble complet de services de cluster pour la prise en charge
de la base de données Oracle Real Application Cluster (RAC) avec disque partagé et
équilibrage de la charge. Il peut également être utilisé pour fournir des services de
basculement à des bases Oracle monoinstances et à d'autres applications.
Les services fournis par Oracle Clusterware sont les suivants :
• La gestion du cluster, qui permet de surveiller et de contrôler les services et les
ressources applicatives à partir de n'importe quel noeud.
• La surveillance des noeuds, qui fournit des informations en temps réel relatives aux
noeuds disponibles et aux ressources prises en charge. L'intégrité du cluster est protégée
en excluant ou isolant les noeuds qui ne répondent pas.
• Les services déclenchés par un événement, qui publient les événements intervenant dans
le cluster afin que les applications aient connaissance des modifications survenues.
• La synchronisation temporelle, qui synchronise la date et l'heure sur tous les noeuds du
cluster.
• La gestion du réseau, qui fournit et gère les adresses IP virtuelles (VIP) associées aux
noeuds du cluster ou aux ressources applicatives afin de disposer d'une identité cohérente
au niveau du réseau quels que soient les noeuds disponibles. Par ailleurs, Grid Naming
Service (GNS) gère les noms réseau dans le cluster.
• La haute disponibilité, qui gère, surveille et redémarre toutes les autres ressources en
fonction des besoins.

Objectifs d'Oracle Clusterware
• Installation plus simple

• Gestion simplifiée
• Intégration étroite avec Oracle RAC
• Améliorations apportées
à ASM et avantages
pour toutes les

applications
• Aucun besoin
d'un clusterware
supplémentaire
Objectifs d'Oracle Clusterware

Oracle Clusterware est le clusterware requis pour Oracle Real Application Clusters (RAC).
Oracle Database 11g Release 2 assure une intégration étroite entre Oracle Clusterware et
RAC en étendant l'intégration avec Automatic Storage Management (ASM). Le résultat est
que désormais toutes les données partagées du cluster peuvent être gérées via ASM. Celles-ci
incluent les données nécessaires pour exécuter Oracle Clusterware, Oracle RAC, et toutes les
autres applications déployées dans le cluster.
Dans la plupart des cas, cette fonctionnalité élimine la nécessité de déployer un clusterware
supplémentaire à partir d'autres sources, ce qui évite les éventuels problèmes d'intégration liés
à l'exécution de plusieurs clusterwares. La gestion d'ensemble du cluster est ainsi plus simple.
La plupart des améliorations apportées à ASM sont décrites dans les chapitres ultérieurs, mais
la suite de ce chapitre examine une série de fonctionnalités Oracle Clusterware
supplémentaires et les avantages qu'elles fournissent.

Gestion de réseau avec Oracle Clusterware
• Chaque noeud doit comporter au moins deux adaptateurs réseau.

• Chaque adaptateur réseau public doit prendre en charge le
protocole TCP/IP.
• L'adaptateur d'interconnexion entre noeuds doit prendre en charge :
– User Datagram Protocol (UDP) pour les plateformes UNIX et Linux
– TCP pour les plateformes Windows
Réseau public

NIC1 NIC1
NIC2 NIC2
NIC1 Interconnexion entre noeuds :

NIC2 Réseau privé
Gestion de réseau avec Oracle Clusterware

Chaque noeud doit comporter au moins deux adaptateurs réseau : un pour l'interface réseau
publique et l'autre pour l'interface réseau privée ou pour les interconnexions entre noeuds. En
outre, les noms d'interface associés aux adaptateurs de réseau pour chaque réseau doivent être
les mêmes sur tous les noeuds. Par exemple, dans un cluster à deux noeuds, vous ne pouvez
pas configurer des adaptateurs réseau en utilisant eth0 comme interface publique sur node1,
et eth1 sur node2. Les noms d'interface publics devant être identiques, vous devez configurer
eth0 sur les deux noeuds. Vous devez aussi configurer les interfaces privées sur les mêmes
adaptateurs réseau. Si eth1 est l'interface privée pour node1, il doit aussi s'agir de l'interface
privée pour node2.
Avant de commencer l'installation, sur chaque noeud, vous devez disposer d'au moins deux
interfaces à configurer pour les adresses IP publiques et privées. Vous pouvez configurer les
adresses IP avec une des options suivantes :
• Oracle Grid Naming Service (GNS) en utilisant une adresse statique définie pendant
l'installation, qui alloue dynamiquement des adresses IP virtuelles à l'aide du protocole
DHCP
&[PCOKE*QUV%QPHKIWTCVKQP2TQVQEQN, lequel doit s'exécuter sur le réseau. Vous
devez sélectionner l'installation avancée d'Oracle Clusterware pour utiliser GNS.
• Des adresses statiques que les administrateurs réseau affectent à un serveur de noms de
domaine (DNS) sur chaque noeud. Pour l'installation standard d'Oracle Clusterware, vous
devez utiliser des adresses statiques.

Gestion de réseau avec Oracle Clusterware (suite)

Pour le réseau public, chaque adaptateur de réseau doit prendre en charge le protocole
TCP/IP. Pour le réseau privé, l'interconnexion entre noeuds doit prendre en charge le
protocole UDP (TCP pour Windows) à l'aide d'adaptateurs de réseau haut débit et de
commutateurs (switches) prenant en charge le protocole TCP/IP. Il est recommandé d'utiliser
Gigabit Ethernet ou un équivalent.
Chaque noeud d'un cluster requiert un protocole d'interconnexion entre noeuds pour la prise
en charge du mécanisme "Cache Fusion", et le protocole TCP/IP pour le système
d'interrogation d'Oracle Clusterware. Token Ring n'est pas pris en charge pour les
interconnexions sous +$/#+:. Votre protocole d'interconnexion doit être certifié par Oracle
pour votre plateforme.

Remarque : Les câbles croisés ne sont pas pris en charge pour les interconnexions Oracle
Clusterware.

Agrégation de liaisons : Commutateur simple

• L'agrégation de liaisons peut être utilisée pour augmenter la
redondance afin d'offrir une meilleure disponibilité dans le cadre
d'une configuration Actif/Secours.
• L'agrégation de liaisons peut être utilisée pour augmenter la
bande passante afin d'améliorer les performances dans le cadre
d'une configuration Actif/Actif.
Interconnexion

Interconnexion
Chaque Chaque
noeud eth1 noeud eth1
bond0 bond0
eth2 eth2
Actif Secours Actif Actif
Agrégation de liaisons : Commutateur simple

L'agrégation de liaisons d'interconnexion implique l'association de plusieurs cartes d'interface
réseau physiques en une interface logique unique. Le comportement des interfaces dépend des
paramètres, des modes et des gestionnaires utilisés pour effectuer l'agrégation.
Une stratégie souvent utilisée pour les configurations haute disponibilité est l'agrégation
Actif/Secours, parfois appelée Actif/Passif. En général, une seule des cartes transporte le
trafic. L'autre est disponible pour le basculement. Voici un exemple de configuration
Actif/Secours sous Linux comme indiqué par la commande ifconfig :
bond0 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4
inet addr:XXX.XXX.XXX.YYY Bcast:XXX.XXX.XXX.255
Mask:255.255.252.0
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:7224794 errors:0 dropped:0 overruns:0 frame:0
TX packets:3286647 errors:1 dropped:0 overruns:1 carrier:0
collisions:0 txqueuelen:0

Agrégation de liaisons : Commutateur simple (suite)

eth1 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4
Mask:255.255.252.0
UP BROADCAST RUNNING NOARP SLAVE MULTICAST MTU:1500 Metric:1
Interrupt:10 Base address:0x1080
eth2 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4

Mask:255.255.252.0
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
Interrupt:9 Base address:0x1400
Les éléments eth1 et eth2 sont les cartes d'interface réseau physiques. L'élément bond0
est une carte d'interface réseau "virtuelle". Notez que l'interface bond0 logique apparaît en
tant que MASTER tandis que les deux autres sont indiquées en tant que SLAVE. L'interface
sans option NOARP (eth2) est l'esclave actif en cours. Notez également que les trois
interfaces ont la même adresse layer-2 ou MAC (Media Access Control) et des adresses IP.
Dans l'exemple, il existe des statistiques relatives au trafic sur toutes les ECTVGU TÃUGCW en
raison d'un grand nombre d'arrêts et de défaillances dans le passé.
Remarque : Pendant l'installation du produit Oracle Clusterware, l'interface bond0 est
indiquée en réponse aux invites pour que l'interface d'interconnexion soit utilisée.
Une autre stratégie courante pour l'agrégation de liaisons implique des configurations
Active/Active conformes aux normes IEEE 802.3ad. Cet agencement implique l'utilisation
simultanée des deux cartes réseau physiques en parallèle pour obtenir une bande passante
supérieure. Si 802.3ad est utilisé sur la couche des cartes réseau, il est très important que le
commutateur prenne également en charge 802.3ad. Une mauvaise configuration entraîne des
performances médiocres et des réinitialisations d'interface. Une alternative consiste à utiliser
une carte réseau unique avec une bande passante élevée, telle qu'une carte 10Gbit Ethernet au
lieu d'une carte 1Gbit Ethernet. Infiniband peut également être utilisé pour l'interconnexion
entre noeuds.
L'agrégation de liaisons est parfois appelée collaboration de cartes réseau, jonction de ports,
EtherChannel, liaison MLT (Multi-Link Trunking), tolérance de panne réseau (NFT -
Network Fault Tolerance) ou groupe d'agrégations de liaisons (LAG - Link Aggregate
Group). Elle est généralement limitée à un commutateur unique. Les solutions impliquant
plusieurs commutateurs incluent l'agrégation de liaisons SMLT (Split Multi-Link Trunking),
l'agrégation DSMLT (Distributed Split Multi-Link Trunking) et l'agrégation RSMLT (Routed
Split Multi-Link Trunking).

Agrégation de liaisons : Commutateurs multiples
• Les commutateurs redondants connectés via une liaison

peuvent être utilisés pour une conception haute
disponibilité améliorée.
• Il s'agit de la configuration recommandée pour
l'interconnexion entre noeuds.
Interconnexion

Chaque
noeud eth1 eth1
bond0 bond0
Liaison entre commutateurs
eth2 eth2
Actif Secours
Agrégation de liaisons : Commutateurs multiples

Dans les solutions avec un seul commutateur présentées dans la diapositive précédente, une
panne du commutateur entraîne l'arrêt de toutes les interconnexions. Pour améliorer la
disponibilité, il est possible d'implémenter un commutateur redondant comme illustré dans la
diapositive et de connecter les commutateurs par le biais d'une liaison. Il s'agit de la
conception recommandée pour l'interconnexion entre noeuds d'Oracle Clusterware. Seul le
mode Actif/Secours est pris en charge dans cette configuration.
Certaines des solutions classiques d'agrégation sont les suivantes :
• Cisco EtherChannel basé sur 802.3ad
• AIX EtherChannel
• Agrégation automatique de ports HPUX
• Liaison Sun, IPMP, GLD
• Liaison Linux (certains modes uniquement)
• Association de cartes réseau Windows
Dans un environnement comprenant des commutateurs partagés, il est possible d'utiliser un
réseau local virtuel (VLAN) pour les interconnexions entre noeuds. Celles-ci doivent
constituer un sous-réseau dédié non transférable mis en correspondance avec un VLAN
unique dédié et non partagée.

Recommandations relatives aux cartes réseau

d'interconnexion
Le paramétrage optimal d'une carte réseau d'interconnexion peut varier en
fonction du pilote utilisé. Tenez compte des recommandations suivantes :
• Configurez la carte d'interconnexion sur le bus PCI le plus rapide.
• Assurez-vous que les noms et les emplacements des cartes réseau
sont identiques sur tous les noeuds.
• Définissez le contrôle de flux : receive=on, transmit=off.
• Indiquez le débit binaire pris en charge par chaque carte.

• Définissez la négociation automatique en mode bidirectionnel
simultané.
• Vérifiez la compatibilité des paramètres du commutateur :
– Si 802.3ad est utilisé sur les cartes réseau, il doit être utilisé et pris en
charge sur le commutateur.
– L'unité de transmission maximale (MTU) doit être identique sur les cartes
réseau et sur le commutateur.
• Les paramètres du pilote peuvent varier selon les logiciels.
Recommandations relatives aux cartes réseau d'interconnexion

L'impossibilité de configurer correctement les cartes réseau et les commutateurs utilisés pour
l'interconnexion entre noeuds entraîne une dégradation importante des performances et
éventuellement l'éviction ou l'isolement de noeuds. Si vous avez le choix entre des normes de
bus telles que PCI et PCI Express, configurez la carte d'interconnexion sur le bus PCI le plus
rapide. Il s'agit d'une condition requise pour que la négociation automatique entre les cartes
réseau et le commutateur s'effectue avec le débit le plus élevé pris en charge. Le contrôle de
flux doit être activé pour la réception. Il arrive que ce paramètre soit modifié entre les mises
à jour du logiciel du pilote et les modifications. En fonction du mode d'agrégation de liaisons
utilisé, il peut y avoir besoin d'un support spécialisé au niveau du commutateur. La
synchronisation entre les paramètres du commutateur et ceux des cartes réseau est très
importante.
Pour Oracle Database Real Application Clusters (RAC), l'interconnexion entre noeuds est
utilisée pour transporter les images de bloc de base de données. Les blocs d'une base Oracle
peuvent avoir une taille allant jusqu'à 32 Ko tandis qu'un message d'interconnexion standard
fait environ 200 octets.
Lorsque l'interconnexion entre noeuds est mal configurée ou défectueuse, divers problèmes
peuvent se présenter :
• Paquets et fragments supprimés
• Débordements de tampons
• Echec du réassemblage des paquets ou dépassement des délais d'attente
• Erreurs générales Tx/Rx

Autres recommandations
relatives à l'interconnexion
Tampon de sockets UDP (rx)
• Les paramètres par défaut conviennent pour la plupart des clients.
• Il peut être nécessaire d'augmenter la taille du tampon affecté dans
les cas suivants :
– La taille de MTU a augmenté.
– La commande netstat signale des erreurs.
– La commande ifconfig signale des paquets supprimés ou un
dépassement de capacité.

Trames étendues :
• Il ne s'agit pas d'une norme de l'IEEE (Institute of Electrical and
Electronics Engineers)
• Elles sont utiles pour le stockage NAS (Network Attached
Storage)/iSCSI.
• Elles peuvent entraîner des problèmes d'interopérabilité entre les
unités réseau.
• Elles doivent être configurées avec soin et testées sérieusement.
Autres recommandations relatives à l'interconnexion

La taille maximale du tampon de réception des sockets UDP varie en fonction du système
d'exploitation. Cette limite peut aller de 128k à 1G. Dans la plupart des cas, les paramètres par
défaut conviennent pour la plupart des clients. Il s'agit de l'un des premiers paramètres à
modifier si des blocs sont perdus lors de la réception. Consultez le site My Oracle Support
(précédemment, MetaLink) le site Web pour les paramètres de meilleur-exercice pour votre
plate-forme. Il peut être nécessaire de modifier la taille du tampon dans trois cas : lorsque la
taille de MTU a augmenté, lorsque la fragmentation et/ou le réassemblage de paquets sont
trop fréquents, ou en cas de perte de paquets ou de dépassement des délais d'attente.
Les trames étendues ne sont pas obligatoires pour Oracle Clusterware et ne sont pas
configurées par défaut. Elles sont prises en charge, mais il convient de les utiliser avec
précaution car il ne s'agit pas d'une norme IEEE. Il peut exister des différences significatives
entre les unités réseau et les commutateurs, notamment d'un fournisseur à un autre. La taille
standard d'une trame étendue est de 9k, mais cette valeur peut varier. Il est nécessaire que
toutes les unités du chemin de communication soient définies avec la même valeur.
Remarque : Pour Oracle Clusterware, l'unité de transmission maximale (MTU - Maximum
Transmission) doit être identique sur tous les noeuds. Dans le cas contraire, un message
d'erreur est envoyé aux fichiers d'alertes du clusterware.

Quiz
L'adaptateur Ethernet public de chaque noeud du cluster doit

prendre en charge le protocole UDP.
1. Vrai
2. Faux

Réponse : 2
Cette affirmation est fausse. L'adaptateur Ethernet public de chaque noeud du cluster doit
prendre en charge le protocole TCP/IP. L'adaptateur privé doit prendre en charge le protocole
UDP sur les plateformes Linux/UNIX et le protocole TCP/IP sur les plateformes Windows.


Module 2 : Architecture d'Oracle Clusterware

Démarrage d'Oracle Clusterware

• Oracle Clusterware est démarré par le démon d'initialisation du
système d'exploitation.
Système d'exploitation Script de démarrage Processus d'Oracle Clusterware
démon init du clusterware
ohasd.bin oclskd.bin
init octssd.bin crsd.bin
/etc/init.d/init.ohasd
oraagent.bin gipcd.bin
diskmon.bin mdnsd.bin
ocssd.bin gpnpd.bin
evmd.bin scriptagent.bin

cssdagent oraagent.bin
orarootagent.bin
• L'installation d'Oracle Clusterware modifie le fichier

/etc/inittab pour que ohasd soit redémarré en cas de panne.
# cat /etc/inittab
..
h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
Démarrage d'Oracle Clusterware

Pendant l'installation d'Oracle Clusterware, le script de démarrage init.ohasd est copié
dans /etc/init.d. Ce script est chargé de configurer les variables d'environnement avant
de démarrer les démons et les processus d'Oracle Clusterware.
Le démon Oracle High Availability Services (ohasd) est chargé de démarrer les autres
démons locaux, de les surveiller et de les redémarrer, jusqu'au démon crsd, qui gère les
ressources à l'échelle du cluster. Lorsque init démarre ohasd lors du lancement d'Oracle
Clusterware, ohasd démarre orarootagent, cssdagent et oraagent. Ces processus
exécutent les tâches suivantes :
• orarootagent lance crsd.
- crsd démarre un autre processus orarootagen chargé des ressources CRS
appartenant à la racine, y compris les adresses IP virtuelles SCAN.
• cssdagent lance cssd (ocssd).
• oraagent démarre mdnsd, evmd, ASM, ctssd et gpnpd. oraagent lance aussi
gsd, Oracle Notification Service (ONS) et les processus d'écoute.
Certains des démons haute disponibilité s'exécutent pour le compte de l'utilisateur root avec
une priorité en temps réel, tandis que d'autres s'exécutent pour le compte du propriétaire du
clusterware avec des priorités correspondant au mode utilisateur. Lorsqu'une commande est
utilisée pour arrêter Oracle Clusterware, les démons sont arrêtés, mais le processus ohasd
continue de s'exécuter.

Architecture des processus d'Oracle Clusterware

Les processus du clusterware sont organisés en plusieurs groupes
de composants. En voici la description :
Composant Processes Propriétaire
Cluster Ready Service (CRS) crsd root
Cluster Synchronization Service (CSS) ocssd,cssdmonitor, grid owner,
cssdagent root, root
Event Manager (EVM) evmd, evmlogger grid owner

Cluster Time Synchronization Service octssd root
(CTSS)
Oracle Notification Service (ONS) ons, eons grid owner
Oracle Agent oraagent grid owner
Oracle Root Agent orarootagent root
Grid Naming Service (GNS) gnsd root
Grid Plug and Play (GPnP) gpnpd grid owner
Multicast domain name service (mDNS) mdnsd grid owner
Architecture des processus d'Oracle Clusterware

Oracle Clusterware contient plusieurs processus qui facilitent les opérations de cluster. Les
composants Cluster Ready Service (CRS), Cluster Synchronization Service (CSS), Event
Management (EVM) et Oracle Notification Service (ONS) communiquent avec les autres
couches de composants du cluster dans le même environnement de base de données. Ces
composants sont également les liens de communication principaux entre Oracle Database,
les applications et les composants de haute disponibilité d'Oracle Clusterware. En outre, ces
processus en arrière-plan surveillent et gèrent les opérations de base de données. La liste
suivante décrit certains processus en arrière-plan importants d'Oracle Clusterware. Elle inclut
des composants qui sont des processus Linux et UNIX, ainsi que des services Windows.
• Cluster Ready Service (CRS) : Programme principal de gestion des opérations de haute
disponibilité au sein d'un cluster. Le processus CRS gère deux types de ressources CRS :
- Ressources de cluster : Une ressource de cluster est une ressource Oracle
Clusterware. Les ressources de cluster sont affichées, ajoutées, modifiées ou
supprimées à l'aide de la commande crsctl.
- Ressources locales : Une ressource locale s'exécute sur chaque noeud du cluster
(pas de basculement en cas de panne). Il peut s'agir, par exemple, d'un processus
d'écoute, d'ASM, d'un groupe de disques ou d'Oracle Notification Service (ONS).
• Le démon CRS (crsd) gère les ressources du cluster en fonction des informations de
configuration stockées dans 1TCENG%NWUVGT4GIKUVT[ (OCR) pour chaque ressource. Il
assure notamment les opérations de démarrage, d'arrêt, de surveillance et de basculement
en cas de panne. Le processus crsd génère des événements lorsque le statut d'une
ressource change.

Architecture des processus d'Oracle Clusterware (suite)

Lorsque vous effectuez l'installation d'Oracle RAC, le processus crsd surveille
l'instance de base de données Oracle, le processus d'écoute, etc., et redémarre
automatiquement ces composants lorsqu'un incident survient. Lorsqu'une ressource CRS
échoue, le démon CRS tente de la redémarrer si cela est défini dans sa configuration.
CRS bascule la ressource vers un autre noeud (si sa configuration l'indique) après
épuisement des tentatives de redémarrage.
• Cluster Synchronization Service (CSS) : Gère la configuration du cluster en contrôlant
les noeuds membres et en signalant l'arrivée ou le départ d'un noeud. Si vous utilisez un
clusterware tiers certifié, les processus CSS communiquent avec ce logiciel pour gérer
les informations d'appartenance aux noeuds. CSS comprend trois processus distincts :

le démon CSS (ocssd), l'agent CSS (cssdagent) et la fonction de surveillance CSS
(cssdmonitor). Le processus cssdagent surveille le cluster et isole les
entrées/sorties. Ce service était précédemment fourni par le démon de surveillance
Oracle Process Monitor (oprocd), également appelé OraFenceService sous Windows.
Une défaillance de cssdagent amène Oracle Clusterware à redémarrer le noeud.
• Démon Disk Monitor (diskmon) : Assure la surveillance et l'isolement des E/S
clôturant pour le serveur de stockage HP Oracle Exadata. Etant donné que le stockage
Exadata peut être ajouté à n'importe quel noeud Oracle RAC à tout moment, le démon
diskmon est toujours démarré lorsque ocssd est démarré.
• Event Manager (EVM) : Processus en arrière-plan qui publie des événements Oracle
Clusterware.
• Multicast Domain Name Service (mDNS) : Permet les requêtes DNS. mDNS est un
processus en arrière-plan sous Linux et UNIX, et un service sous Windows.
• Oracle Grid Naming Service (GNS) : Passerelle entre le mDNS du cluster et les
serveurs DNS externes. Le processus GNS effectue la résolution de noms dans le
cluster.
• Oracle Notification Service (ONS) : Service de type publication/abonnement pour les
événements de communication FAN (Fast Application Notification).
• oraagent : Etend le clusterware pour prendre en charge les conditions Oracle
particulières et les ressources complexes. Il exécute des scripts serveur d'appel de
programmes externes lorsque des événements FAN se produisent. Ce processus
s'appelait RACG dans Oracle Clusterware 11g Release 1 (11.1).
• Agent racine Oracle (orarootagent) : Processus oraagent spécialisé qui aide
CRSD à gérer les ressources possédées par la racine, telles que le réseau et l'adresse IP
virtuelle du grid.
• Démon Cluster Kill (oclskd) : Gère les demandes d'éviction d'instance/de noeud qui
sont remontées jusqu'au service CSS.
• Démon Grid IPC (gipcd): &ÃOQPF CKFGRQWTN KPHTCUVTWEVWTGFGEQOOWPKECVKQP

Grid Plug and Play

• Dans les versions antérieures, l'ajout ou la suppression de serveurs
dans un cluster nécessitait une préparation manuelle importante.
• Dans Oracle Database 11g Release 2, GPnP permet à chaque
noeud d'effectuer les tâches suivantes dynamiquement :
– Négocier les identités réseau appropriées pour lui-même
– Obtenir des informations supplémentaires d'un profil de configuration
– Se configurer ou se reconfigurer à l'aide des données de profil, afin
que les noms d'hôte et les adresses puissent être résolus sur le
réseau

• Pour ajouter un noeud, il suffit de connecter le serveur au cluster et
de permettre au cluster de configurer le noeud.
Grid Plug and Play

Dans les versions antérieures, l'ajout ou la suppression de serveurs dans un cluster nécessitait
une préparation manuelle importante. Avec la version Oracle Database 11g Release 2, Grid
Plug and Play (GPnP) permet de réduire les coûts d'installation, de configuration et de gestion
des noeuds serveur en utilisant un service de noms de grille dans le cluster afin de permettre à
chaque noeud d'effectuer les tâches suivantes dynamiquement :
• Négocier les identités réseau appropriées pour lui-même
• Obtenir les informations complémentaires à traiter à partir d'un profil de configuration
• Se configurer ou se reconfigurer à l'aide des données de profil, afin que les noms d'hôte et
les adresses puissent être résolus sur le réseau
Etant donné que les serveurs effectuent ces tâches dynamiquement, l'ajout et la suppression de
noeuds nécessitent simplement que l'administrateur connecte le serveur au cluster et permette
au cluster de configurer le noeud. Lorsque Grid Plug and Play est utilisé conformément aux
recommandations, l'ajout d'un noeud au cluster de base de données fait partie du redémarrage
normal du serveur, et la suppression d'un noeud se produit lorsque le serveur est arrêté. Cette
méthode supprime de nombreuses opérations manuelles, réduit les risques d'erreur, et favorise
les configurations pouvant être modifiées facilement plutôt que celles qui nécessitent un
paramétrage fixe par noeud.
Il est recommandé d'utiliser ASM et la gestion automatique des annulations. Ainsi, il n'y a pas
de décision spécifique à prendre si un tablespace d'annulation doit être alloué pour une
instance de base de données nouvellement identifiée.

Domaine GPnP
• Un domaine GPnP est un ensemble de noeuds

appartenant à un cluster unique desservi par le service
GPnP :
– Nom du cluster : cluster01
– Domaine réseau : example.com
– Domaine GPnP : cluster01.example.com

• Chaque noeud inclus dans le domaine GPnP présente les
caractéristiques suivantes :
– Au moins une interface routable permettant la connexion en
dehors du domaine GPnP pour l'interface publique
– Un identificateur qui est unique dans le domaine GPnP
– Une personnalité affectée par le profil GPnP, des
caractéristiques physiques et une image logicielle du noeud
Domaine GPnP
Un domaine GPnP est un ensemble de noeuds desservis par le service GPnP. Dans la plupart
des cas, sa taille est limitée par le domaine multicast. Les noeuds d'un domaine multicast
connaissent implicitement le domaine GPnP dont ils font partie grâce à la clé publique de leur
autorité de provisionnement. Un domaine GPnP est défini par les noeuds d'un domaine
multicast identifiant une autorité de provisionnement spécifique, comme indiqué par le
certificat dans leurs images de logiciels. Un noeud GPnP est un ordinateur appartenant à un
domaine GPnP. Il doit présenter les caractéristiques suivantes :
Connectivité IP : Le noeud doit comporter au moins une interface routable permettant la
connexion en dehors du domaine GPnP. Si le noeud présente différents modes de connexion
(interfaces multiples, sous-réseaux, etc.), la liaison requise (publique, privée, stockage) doit
être identifiée dans le profil GPnP. La connexion physique est contrôlée par une entité
extérieure et n'est pas modifiée par GPnP.
Identificateur unique : A chaque noeud est associé un identificateur unique, créé par OSD.
Cet ID doit nécessairement être unique dans le domaine GPnP, mais il est utile qu'il soit
globalement unique dans le plus large domaine possible.
Personnalité : Les caractéristiques de la personnalité d'un noeud sont les suivantes :
• Nom du cluster
• Classification réseau (public/privé)
• Stockage à utiliser pour ASM et CSS
• Signatures numériques
• Image logicielle du noeud, incluant les applications qui peuvent être exécutées

Composants GPnP
Image logicielle
• Une image logicielle est un ensemble de logiciels en
lecture seule à exécuter sur les noeuds du même type.
• Au minimum, l'image doit contenir :
– Un système d'exploitation
– Le logiciel GPnP

– Un certificat de sécurité provenant de l'autorité de
provisionnement
– Les autres logiciels requis pour configurer le noeud
lorsqu'il démarre
Composants GPnP
Une image logicielle est un ensemble de logiciels en lecture seule à exécuter sur les noeuds du
même type. Au minimum, elle doit contenir un système d'exploitation, le logiciel GPnP, le
certificat de sécurité émis par l'autorité de provisionnement, ainsi que les autres logiciels
requis pour configurer le noeud au démarrage. Dans sa forme la plus complète, l'image peut
contenir tous les logiciels d'application à exécuter sur le noeud, y compris Oracle Database,
IAS et les applications client. Dans GPnP, une image n'a pas besoin d'être propre à un noeud
particulier. Elle peut être déployée sur autant de noeuds que nécessaire.
Une image est créée par une autorité de provisionnement par des moyens non définis par
GPnP. Elle peut nécessiter une installation sur une machine exemple, puis le nettoyage du
stockage pour supprimer les données dépendant du noeud.
Une image est répartie sur un noeud par l'autorité de provisionnement selon des méthodes
hors du cadre de GPnP — CD transportés par l'administrateur système, démarrage réseau ou
tout autre mécanisme.

Profil GPnP
Fichier profile.xml :
$ cat GRID_HOME/gpnp/profiles/peer/profiles.xml
<?xml version="1.0" encoding="UTF-8"?><gpnp:GPnP-Profile Version="1.0"
xmlns="http://www.grid-pnp.org/2005/11/gpnp-profile" ...
xsi:schemaLocation="http://www.grid-pnp.org/2005/11/gpnp-profile gpnp-profile.xsd"
ProfileSequence="4" ClusterUId="2deb88730e0b5f1bffc9682556bd548e" ClusterName="cluster01"
PALocation=""><gpnp:Network-Profile><gpnp:HostNetwork id="gen" HostName="*"><gpnp:Network
id="net1" IP="192.0.2.0" Adapter="eth0" Use="public"/><gpnp:Network id="net2"
IP="192.168.1.0" Adapter="eth1"
Use="cluster_interconnect"/></gpnp:HostNetwork></gpnp:Network-Profile><orcl:CSS-Profile
id="css" DiscoveryString="+asm" LeaseDuration="400"/><orcl:ASM-Profile id="asm"
DiscoveryString="/dev/sd*" SPFile="+data/spfile.ora"/><ds:Signature

<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<InclusiveNamespaces xmlns="http://www.w3.org/2001/10/xml-exc-c14n#"
PrefixList="gpnp orcl xsi"/>
...
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>gIBakmtUNi9EVW/XQoE1mym3Bnw=</ds:DigestValue>
...
<ds:SignatureValue>cgw3yhP/2oEm5DJzdachtfDMbEr2RSfFFUlZujLemnOgsM...=</ds:SignatureValue>
Profil GPnP
Un profil GPnP est un petit fichier XML servant à définir la personnalité globale appropriée
pour des images qui sont par ailleurs identiques. Le profil peut être obtenu au démarrage à
partir d'un site distant, ou il peut être intégré de manière permanente dans une image. Il inclut
les données de configuration GPnP générique et, éventuellement, des données de
configuration spécifiques à l'application. Les données de configuration GPnP génériques sont
utilisées pour configurer l'environnement réseau et le stockage au cours du démarrage. Les
parties applicatives du profil peuvent être utilisées pour créer des personnalités spécifiques
à l'application. Le profil est dépendant de la sécurité. Il peut identifier le stockage à utiliser
comme partition racine d'une machine. Pour pouvoir être utilisé, un profil doit être signé
numériquement par l'autorité de provisionnement et doit être validé sur chaque noeud. Par
conséquent, l'image doit inclure le certificat public de l'autorité à utiliser pour la validation.
Les profils sont conçus de façon qu'il soit difficile de les modifier. Ils peuvent être intégrés de
manière permanente dans les images en lecture seule ou être répliqués sur des machines qui
sont arrêtées lorsqu'une modification est apportée. Les attributs de profil définissant la
personnalité d'un noeud sont les suivants :
• Nom du cluster
• Classification réseau (public/privé)
• Stockage à utiliser pour ASM et CSS
• Informations sur la signature numérique
Les modifications apportées à un cluster, et donc au profil, sont répliquées par le démon
gpnpd au cours de l'installation, du démarrage du système, ou lors d'une mise à jour. Les
mises à jour peuvent être déclenchées par des modifications réalisées à l'aide d'outils de
configuration tels que oifcfg, crsctl, asmca, etc.
Service GNS (Grid Naming Service)
• GNS est un composant complet de Grid Plug and Play.

• La seule adresse IP statique requise pour le cluster est l'adresse IP
virtuelle de GNS.
• Le sous-domaine du cluster est défini en tant que domaine délégué.
[root@my-dns-server ~]# cat /etc/named.conf
// Default initial "Caching Only" name server configuration
...

# Delegate to gns on cluster01
cluster01.example.com #sous-domaine du cluster# NS cluster01-
gns.example.com
# Let the world know to go to the GNS vip
cluster01-gns.example.com. 192.0.2.155 # adresse GNS du cluster
• Une demande de résolution de cluster01-scan.cluster01.example.com

serait transmise au service GNS sur 192.0.2.155.
• Chaque noeud du cluster gère un processus DNS multicast (mDNS).
Service GNS (Grid Naming Service)

L'utilisation d'un service GNS (Grid Naming Service) suppose qu'il existe un serveur DHCP
s'exécutant sur le réseau public, avec suffisamment d'adresses pour les adresses IP virtuelles et
les adresses IP virtuelles SCAN (Single Client Access Name ). Avec GNS, seule une adresse
IP statique est requise pour le cluster, l'adresse IP virtuelle de GNS. Cette adresse doit être
définie dans le domaine DNS. GNS configure un serveur DNS multicast (mDNS) dans le
cluster. Celui-ci résout les noms du cluster sans qu'il y ait besoin d'une configuration statique
du serveur DNS pour d'autres adresses IP de noeud.
Le serveur mDNS fonctionne comme suit. Dans GNS, les noms de noeud sont résolus avec la
méthode LLMNR (Link-Local Multicast Name Resolution). Pour cela, le domaine LLMNR
".local" utilisé par la résolution multicast est mis en correspondance avec le sous-domaine
indiqué dans la demande DNS. Lorsque vous sélectionnez GNS, un serveur mDNS est
configuré sur chaque hôte du cluster. LLMNR repose sur le mDNS géré par Oracle
Clusterware pour la résolution des noms utilisés par l'hôte.
Pour utiliser le GNS, avant l'installation, l'administrateur DNS doit créer la délégation de
domaine au sous-domaine pour le cluster. Les interrogations adressées au cluster sont
envoyées au processus d'écoute de GNS sur l'adresse IP virtuelle de GNS. Lorsqu'une
demande arrive au domaine, GNS la résout à l'aide de son mDNS interne et répond à
l'interrogation.

Nom SCAN (Single Client Access Name)

• Le nom SCAN (Single Client Access Name) est l'adresse utilisée
par les clients qui se connectent au cluster.
• Il s'agit d'un nom de domaine enregistré sur trois adresses IP,
dans le DNS ou le GNS.
# dig @192.0.2.155 cluster01-scan.cluster01.example.com
...
;; QUESTION SECTION:
;cluster01-scan.cluster01.example.com. IN A

;; ANSWER SECTION:
cluster01-scan.cluster01.example.com. 120 IN A 192.0.2.244
;; AUTHORITY SECTION:
cluster01.example.com. 10800 IN A 192.0.2.155
;; SERVER: 192.0.2.155#53(192.0.2.155)
• Le nom SCAN constitue pour les clients un nom stable présentant

une grande disponibilité, qui est indépendant des noeuds
constituant le cluster.
Nom SCAN (Single Client Access Name)

Le nom SCAN (Single Client Access Name) est l'adresse utilisée par les clients qui se
connectent au cluster. Il s'agit d'un nom de domaine complet (nom_hôte + domaine)
enregistré sur trois adresses IP. Si vous utilisez GNS et disposez du support DHCP, GNS
affecte dynamiquement des adresses au nom SCAN.
Si vous n'utilisez pas GNS, le nom SCAN doit être défini dans le DNS système pour
permettre la résolution des trois adresses qui lui sont associées. Cette opération doit être
effectuée avant d'installer Oracle Grid Infrastructure. Le nom SCAN, et les adresses IP
associées, constitue un nom stable que les clients utilisent pour les connexions,
indépendamment des noeuds qui constituent le cluster.
Les noms SCAN fonctionnent comme des alias de cluster. Toutefois, ils sont résolus sur
n'importe quel noeud du cluster. Par conséquent, à la différence de ce qui se passe avec une
adresse IP virtuelle pour un noeud, les clients se connectant avec le nom SCAN n'ont plus
besoin d'adresses IP virtuelles actualisées lorsque des noeuds sont ajoutés ou supprimés du
cluster. Etant donné que la résolution des adresses SCAN désigne le cluster plutôt qu'une
adresse de noeud du cluster, il est possible d'ajouter ou de supprimer des noeuds dans le
cluster sans affecter la configuration des adresses SCAN.
Au cours de l'installation, des processus d'écoute (listeners) sont créés sur chaque noeud pour
les adresses IP SCAN. Oracle Clusterware transmet les demandes applicatives adressées au
nom SCAN du cluster à l'instance fournissant le service qui est la moins chargée.

Nom SCAN (Single Client Access Name) (suite)

Les processus d'écoute SCAN peuvent s'exécuter sur n'importe quel noeud du cluster. Les
noms SCAN assurent l'indépendance par rapport à l'emplacement pour les bases de données,
afin que la configuration client n'ait pas à dépendre des noeuds exécutant une base
particulière.
Oracle Database 11g Release 2 et les instances ultérieures s'enregistrent uniquement auprès
des processus d'écoute SCAN en tant que processus d'écoute distants. Les bases de données
mises à niveau s'enregistrent auprès des processus d'écoute SCAN en tant que processus
d'écoute distants, mais aussi auprès de tous les processus d'écoute de noeud.
Si vous indiquez un domaine GNS au cours de l'installation, le nom SCAN prend par défaut la
valeur clustername-scan.GNS_domain Sinon, il prend par défaut la valeur

clustername_scan.current_domain.
Remarque : dig : Domain Information Groper

Présentation de l'architecture de GPnP

Résolution de l'adresse VIP Résolution du nom d'hôte en adresse
Obtient les trois adresses VIP SCAN
Résolution du nom VIP et du nom hôte

DNS GNS Enregistre l'adresse VIP du noeud
Adresse VIP statique de GNS & l'adresse VIP SCAN
Utilise une adresse
Nom résolu en
trois adresses VIP
SL SL SL
Equilibrage de
VIP SCAN
la charge
remote_listener
LL LL LL LL LL
Client local_listener

Scan+port+service
Node1 Node2 Node3 Node4 Noden
Obtient l'adresse
profile.xml
VIP du noeud Adresse

…
Noeud
& l'adresse VIP SCAN VIP noeud
le moins
obtenues par orarootagent
Adresses VIP dynamiques
chargé & SCAN

pour le VIP
service agents
orarootagent
DHCP
GPnP GPnP GPnP GPnP GPnP Réplication
de profil
Repérage de GPnP
mDNS mDNS mDNS mDNS mDNS
Présentation de l'architecture de GPnP

Service GPnP
Le service GPnP est fourni collectivement par tous les agents GPnP. Il s'agit d'une méthode
distribuée de réplication de profils. Le service est instancié sur chaque noeud du domaine en
tant qu'agent GPnP. Le service est de type égal à égal (peer-to-peer). Il n'existe aucun
processus principal. Cela permet une haute disponibilité car la panne d'un agent GPnP
n'affecte pas les autres noeuds. GPnP nécessite le protocole standard IP multicast (fourni par
mDNS) pour localiser les services homologues. Grâce au repérage en mode multicast, GPnP
identifie les homologues sans configuration. C'est ainsi qu'un agent GPnP démarré sur un
nouveau noeud identifie un autre agent pouvant avoir un profil approprié.
Résolution de noms
Un nom défini dans un domaine GPnP peut être résolu dans les cas suivants :
• Les hôtes du domaine GPnP utilisent le serveur DNS standard pour résoudre les noms
des hôtes situés en dehors de ce domaine. Ils prennent contact avec leur service DNS
habituel. Ils peuvent obtenir l'adresse de leur serveur DNS dans la configuration globale,
ou via DHCP.
• Dans le domaine GPnP, les noms d'hôte sont résolus à l'aide de mDNS. Pour cela, chaque
noeud doit disposer d'un répondeur mDNS connaissant les noms et les adresses utilisés
par ce noeud. Il doit aussi prendre en charge la bibliothèque client du système
d'exploitation pour la résolution de noms à l'aide de ce protocole multicast. Pour résoudre
un nom, un client exécute gethostbyname, ce qui génère une interrogation mDNS. Si
le nom existe sur un noeud, le répondeur situé sur ce noeud répond en indiquant l'adresse
IP. Le logiciel client peut mettre la résolution en cache pendant une durée spécifique.

Présentation de l'architecture de GPnP (suite)

• Les machines situées en dehors du domaine GPnP ne peuvent pas résoudre les noms de
ce domaine à l'aide de multicast. Pour résoudre ces noms, elles utilisent le serveur DNS
standard. L'autorité de provisionnement arrange le DNS global pour déléguer un sous-
domaine (zone) à l'adresse connue qui se trouve dans le domaine GPnP. GPnP crée un
service nommé GNS pour résoudre les noms GPnP sur cette adresse fixe.
Le noeud sur lequel le serveur GNS s'exécute est à l'écoute des demandes DNS. Lorsque
des demandes sont reçues, elles sont traduites et transmises au mDNS, et les réponses
sont collectées, traduites, puis renvoyées au client externe. Le service GNS est "virtuel"
car il est sans conservation d'état (stateless). N'importe quel noeud du domaine multicast
peut héberger le serveur. Seule la configuration de GNS est globale :

- Adresse à écouter sur le port 53 du DNS standard.
- Nom(s) des domaines à traiter.
Il peut y avoir autant d'entités GNS que nécessaire pour des raisons de disponibilité. Le
service GNS fourni par Oracle peut utiliser CRS pour assurer la disponibilité d'un
fournisseur GNS unique.
Processus d'écoute SCAN (SL) et processus d'écoute locaux (LL)
Lorsqu'un client soumet une demande de connexion, le processus d'écoute SCAN qui est à
l'écoute sur une adresse IP SCAN et le port SCAN fait l'objet d'un contrat pour le compte du
client. Etant donné que tous les services du cluster sont enregistrés auprès du processus
d'écoute SCAN, ce dernier renvoie l'adresse du processus d'écoute local du noeud le moins
chargé parmi tous ceux qui proposent le service. Enfin, le client établit la connexion au
service par le biais du processus d'écoute du noeud qui offre le service. Toutes ces opérations
sont effectuées de manière transparente sur le client sans qu'il y ait besoin d'effectuer une
configuration explicite sur ce dernier.
Au cours de l'installation, des processus d'écoute sont créés sur chaque noeud pour les
adresses IP SCAN. Oracle Net Services transmet les demandes des applications à l'instance
fournissant le service qui est la moins chargée. Etant donné que la résolution des adresses
SCAN désigne le cluster plutôt qu'une adresse de noeud du cluster, il est possible d'ajouter ou
de supprimer des noeuds dans le cluster sans affecter la configuration des adresses SCAN.

Fonctionnement de GPnP :
Démarrage d'un noeud du cluster
1. Les adresses IP sont négociées pour les interfaces publiques à
l'aide de DHCP :
– Adresses IP virtuelles
– Adresses IP virtuelles SCAN
2. Un agent GPnP est lancé à partir du répertoire d'origine Oracle
Clusterware des noeuds.
3. L'agent GPnP obtient son profil en local ou à partir de l'un des

agents GPnP homologues qui répondent.
4. Le stockage partagé est configuré pour répondre aux exigences
du profil.
5. Les services à démarrer sont indiqués dans le profil, notamment :
– Service GNS pour la résolution des noms externes
– Processus d'écoute SCAN
Fonctionnement de GPnP : Démarrage d'un noeud du cluster

Lorsqu'un noeud est démarré dans un environnement GPnP :
• Les adresses réseau sont négociées pour toutes les interfaces avec DHCP.
• Le clusterware du noeud démarré lance un agent GPnP.
• L'agent GPnP du noeud démarré obtient son profil localement, ou il utilise le repérage de
ressources (RD) pour rechercher les agents GPnP homologue dans le grid. Dans le
second cas, le profil est obtenu de l'un des homologues GPnP qui répond.
L'agent GPnP effectue la configuration réseau indiquée dans le profil. Cette opération
inclut la création de noms d'hôte raisonnables. S'il existe des paramètres statiques, ils
sont utilisés de préférence aux mécanismes dynamiques. Les interfaces réseau peuvent
être modifiées afin de correspondre aux exigences du profil.
• Le stockage partagé est configuré pour répondre aux exigences du profil.
• Le démarrage du système et des services est effectué comme indiqué dans la diapositive.
Dans le cas de RAC, CSS et CRS sont ensuite démarrés. Ils constituent le cluster et
lancent les instances de base de données appropriées. Le démarrage des services peut
utiliser les valeurs des marques de réservation, ou peut négocier dynamiquement des
valeurs au lieu de s'appuyer sur des configurations fixes. L'un des services susceptible
d'être démarré quelque part est le système GNS pour la résolution de noms externes.
Un autre service généralement démarré est un processus d'écoute Oracle SCAN.

Fonctionnement de GPnP :
Connexions de base de données client

GNS
DNS
Client de
base de
données
Processus Listener1

d'écoute
SCAN
Processus
Listener2
d'écoute
SCAN
Processus Listener3
d'écoute
SCAN
Fonctionnement de GPnP : Connexions de base de données client

Dans un environnement GPnP, le client de base de données n'a plus à utiliser l'adresse TNS
pour contacter le processus d'écoute d'un noeud cible. Il peut utiliser la méthode EZConnect
pour se connecter à la base de données. Lorsque le serveur DNS résout l'adresse indiquée dans
la chaîne de connexion, il transmet la demande de résolution au service GNS avec l'adresse IP
virtuelle du processus SCAN choisi, ainsi que le nom du service de base de données souhaité.
Avec la syntaxe EZconnect, cela donne :
scan-name.cluster-name.company.com/ServiceName, où le nom de service peut
être le nom de la base de données. Le service GNS répond au serveur DNS avec l'adresse IP
correspondant au nom indiqué. Cette adresse est ensuite utilisée par le client pour contacter le
processus d'écoute SCAN. Le processus d'écoute SCAN utilise le système d'équilibrage de la
charge des connexions pour sélectionner un processus d'écoute de noeud de base de données
approprié, dont il renvoie le nom au client dans un message OracleNet Redirect. Le client se
reconnecte au processus d'écoute sélectionné, et il résout le nom via un appel au service GNS.
Les processus d'écoute SCAN doivent être connus de tous les noeuds et clients du processus
d'écoute de base de données. Les noeuds d'instance de base de données ne procèdent à un
enregistrement croisé qu'avec les processus d'écoute SCAN connus, et ils leur envoient des
mesures sur les connexions au niveau service. Les noms SCAN connus des serveurs de base
de données peuvent être indiqués dans les profils ou stockés dans le registre OCR.

Quiz
L'entrée init.ohasd du fichier /etc/inittab

est chargée de :
1. Démarrer Oracle Clusterware lors de l'amorçage du noeud
2. Monter les volumes partagés requis par Oracle
Clusterware
3. Gérer les évictions de noeud

4. Redémarrer ohasd en cas de panne
Réponse : 4
La réponse est 4. L'entrée init.ohasd du fichier /etc/inittab assure le redémarrage
du démon Oracle de gestion de la haute disponibilité (ohasd) en cas de panne.

Quiz
Parmi les affirmations suivantes concernant le service GNS

(Grid Naming Service), laquelle n'est pas vraie ?
1. GNS est un composant complet de Grid Plug and Play.
2. Chaque noeud du cluster exécute un processus DNS
multicast (mDNS).
3. L'adresse IP virtuelle de GNS doit être affectée par DHCP.

4. Le sous-domaine du cluster est défini en tant que domaine
délégué.
Réponse : 3
L'affirmation 3 est incorrecte. L'adresse IP virtuelle de GNS doit être définie statiquement.


Module 3 : Architecture d'ASM

Qu'est-ce qu'Oracle ASM ?
Application Application
Système de fichiers
ASM
Gestionnaire de volumes logiques

Système d'exploitation Système d'exploitation
Matériel Matériel
Qu'est-ce qu'Oracle ASM ?

Oracle Automatic Storage Management (ASM) est essentiellement un gestionnaire de
volumes et un système de fichiers intégrés dans un serveur Oracle Database. Les volumes disk
raw sont affectés à ASM pour la gestion et le contrôle de la même manière que les volumes
raw gérés par un gestionnaire de volumes. ASM est étroitement intégré à Oracle Database
et a été optimisé en conséquence. Il s'agit du produit recommandé pour le stockage Oracle
Database.
La combinaison de fonctions de gestion des volumes et d'un système de fichiers permet un
niveau d'intégration et d'efficacité inégalé. Par exemple, ASM peut éviter la surcharge liée à
un système de fichiers conventionnel et obtenir les performances native des disques raw pour
les fichiers de données Oracle et les autres types de fichiers pris en charge par ASM.
ASM est conçu pour fonctionner efficacement dans tous les environnements, clusterisés
ou non.
Depuis Oracle Database 11g Release 2, ASM peut être utilisé comme un gestionnaire de
volumes et un système de fichiers de classe entreprise pour des données non Oracle.

ASM et ASM Cluster File System
• ASM gère les fichiers de

base de données Oracle.
• ACFS gère les autres
fichiers. Application
• Répartition des données
Système
entre les disques pour Base de ACFS de fichiers
équilibrer la charge données tiers

• Mise en miroir intégrée ASM/ADVM
entre les disques
• Résolution de nombreux Système d'exploitation
défis en termes de
gestion du stockage
ASM et ASM Cluster File System

ASM permet la gestion du stockage sur une machine unique ou sur les différents noeuds d'un
cluster pour la prise en charge d'Oracle Real Application Clusters (RAC). Dans Oracle
Database 11g Release 2, ASM Dynamic Volume Manager (ADVM) est disponible pour la
prise en charge d'ASM Cluster File System (ACFS) en tant que système de fichiers
généraliste. ASM distribue la charge des entrées/sorties (E/S) entre toutes les ressources
disponibles d'un groupe de disques afin d'optimiser les performances tout en éliminant la
nécessité du réglage (tuning) manuel. Il aide les DBA à gérer un environnement de base de
données dynamique en leur permettant d'augmenter la taille de la base de données sans avoir à
l'arrêter pour ajuster l'allocation de l'espace de stockage. ACFS permet aux gestionnaires de
stockage d'étendre les avantages d'ASM aux besoins généraux de stockage des fichiers. ASM
permet de gérer des copies redondantes des données afin d'assurer la tolérance de panne. Cette
fonction peut également être associée à des mécanismes de stockage fiables fournis par les
fabricants. La gestion des données s'effectue via la sélection des caractéristiques de fiabilité et
de performances souhaitées pour certaines classes de données, au niveau fichier. Les
fonctionnalités ASM et ACFS permettent aux administrateurs de gagner du temps en
automatisant la gestion de la mémoire. Ceux-ci peuvent ainsi gérer des bases de données
et des systèmes de fichiers plus volumineux (et plus nombreux) de manière plus performante.
Le graphique de la diapositive ci-dessus indique la position d'ASM et d'ADVM dans la
couche de stockage. La couche classique comprend un système d'exploitation, suivi d'un
gestionnaire de volumes logiques, d'un système de fichiers, d'une base de données, puis d'une
application. ASM peut remplacer le gestionnaire de volumes logiques et le système de fichiers
pour une base de données Oracle. Combiné à ACSF, ADVM élimine la nécessité d'utiliser un
système de fichiers clusterisé distinct pour les fichiers partagés autres que des fichiers de base
de données. ASM est une solution complète.

ASM et ASM Cluster File System (suite)

La diapositive présente la couche Oracle 11g Release 2 Automatic Storage Management.
ASM se situe au niveau du système d'exploitation et inclut ASM Dynamic Volume Manager
(ADVM). Au même niveau que la base de données, on trouve ASM Cluster File System
(ACFS) et éventuellement des systèmes de fichiers tiers liés à ADVM.

Fonctionnalités et avantages principaux d'ASM
• Striping des fichiers plutôt que des volumes logiques

• Redondance au niveau fichier
• Permet une reconfiguration de disque en ligne et un
rééquilibrage dynamique
• Réduit notablement le temps nécessaire pour effectuer une
resynchronisation après une panne transitoire en assurant le
suivi des modifications lorsque le disque est hors ligne

• Fournit une vitesse de rééquilibrage ajustable
• Prend en charge les clusters
• Permet de lire une copie miroir au lieu de la copie principale
pour les clusters étendus
• Est installé automatiquement dans le cadre de Grid
Infrastructure
Fonctionnalités et avantages principaux d'ASM

ASM permet le striping et la mise en miroir sans qu'il soit nécessaire d'acquérir un
gestionnaire de volumes logiques (LVM) tiers. ASM divise un fichier en éléments qu'il
répartit de manière uniforme sur tous les disques. ASM utilise une technique d'indexation
pour suivre l'emplacement de chaque élément. Les techniques de striping traditionnelles
utilisent des fonctions mathématiques pour diviser des volumes logiques. #5/ GUV WPKSWGECT
KN WVKNKUG NCOKUG GPOKTQKT CWPKXGCW HKEJKGTRNWVÏV SW CW PKXGCW XQNWOG Par conséquent, le
même groupe de disques peut contenir des fichiers bénéficiant de cette protection et des
fichiers non protégés.
.QTUSWG NCECRCEKVÃ FGUVQEMCIG EJCPIG#5/ PG RTQEÂFG RCUCWTGUVTKRKPI FGVQWVGU NGU
FQPPÃGU6QWVGHQKUFCPU NGECFTGF WPG QRÃTCVKQP GPNKIPGKN FÃRNCEG WPG SWCPVKVÃ FGFQPPÃGU
RTQRQTVKQPPGNNG ´ N GURCEG FGUVQEMCIG CLQWVÃ QW UWRRTKOÃ CHKP FGTGFKUVTKDWGT NGUHKEJKGTU GVFG
ICTFGT WPG EJCTIGF '5 ÃSWKNKDTÃG GPVTG NGUFKUSWGU Vous pouvez augmenter ou réduire la
vitesse des opérations de rééquilibrage pour ajuster l'impact sur le sous-système d'E/S. Cette
fonctionnalité permet également la resynchronisation rapide des disques à la suite d'une panne
transitoire.
ASM prend en charge tous les types de fichier de base de données Oracle. Il prend également
en charge Real Application Clusters (RAC), et évite d'avoir à recourir à un gestionnaire de
volumes logiques de cluster ou à un système de fichiers clusterisé. Dans les clusters étendus,
vous pouvez définir la copie préférée pour la lecture.
ASM est inclus dans Oracle Grid Infrastructure. Il est disponible avec les installations
Enterprise Edition et Standard Edition.

Conceptions d'instance ASM :
Environnement ASM non clusterisé

et bases de données Oracle
Instance de Instance de Instance de
BdD Oracle A BdD Oracle B BdD Oracle C
Instance ASM
Serveur de base de données

monoinstance

Groupe de disques ASM A Groupe de disques ASM B
Conceptions d'instance ASM : Environnement ASM non clusterisé et bases

de données Oracle
La diapositive ci-dessus illustre la première des trois conceptions d'instance ASM. Cette
configuration utilise un environnement ASM non clusterisé pour une ou plusieurs bases de
données non clusterisées. Dans le bas du graphique, il existe deux groupes de disques que
l'instance ASM utilise pour fournir de l'espace aux bases de données. Dans cet environnement,
une seule machine hôte héberge à la fois l'instance ASM et les trois instances de base de
données. Chaque base peut stocker ses fichiers dans les deux groupes de disques, ou dans un
seul, au choix. L'instance ASM gère les métadonnées et fournit des allocations d'espace pour
les fichiers ASM créés par chaque base. Lorsqu'une instance de base de données crée ou
ouvre un fichier ASM, elle communique ses demandes à l'instance ASM. En réponse, celle-ci
fournit des informations sur la topographie des extents de fichier à l'instance de base de
données. Cette conception est utile pour effectuer une consolidation du stockage.

Environnement ASM clusterisé

pour des bases de données de cluster
Instance 1 Instance 2 Instance 1 Instance 2
de la BdD de la BdD de la BdD de la BdD
Oracle A Oracle A Oracle B Oracle B
Instance ASM 1 Instance ASM 2 Instance ASM 3 Instance ASM 4
Serveurs
Oracle RAC


de données de cluster
La diapositive ci-dessus illustre la deuxième des trois conceptions d'instance ASM. Elle
présente un cluster ASM dans un environnement de base de données Oracle RAC où ASM
fournit un pool de stockage clusterisé. Pour chacun des quatre noeuds indiqués, il existe une
instance ASM qui peut assurer la gestion de l'espace pour plusieurs bases de données Oracle
RAC ou monoinstances dans le cluster. Deux bases de données RAC sont présentées. La
base A a des instances sur les deux premiers noeuds, tandis que la base B a des instances sur
les deux autres noeuds. Il s'agit de deux bases de données RAC distinctes. Toutefois, il n'y a
qu'un cluster ASM de quatre noeuds. Les instances ASM de chaque machine se coordonnent
entre elles lors du provisionnement d'espace à partir des deux groupes de disques indiqués.
Dans cette conception, ASM permet la consolidation du stockage, et RAC permet
éventuellement la consolidation au niveau base de données.

Environnement ASM clusterisé

pour des bases de données mixtes
Instance de Instance de Instance de Instance de
BdD Oracle A BdD Oracle B BdD Oracle C BdD Oracle C
Instance ASM 1 Instance ASM 2 Instance ASM 3
Serveurs

de base de données

de données mixtes
La diapositive ci-dessus illustre la dernière des trois conceptions d'instance ASM. Elle
présente un environnement ASM clusterisé à trois noeuds qui fournit un pool de stockage
clusterisé comprenant les groupes de disques A et B. Un pool de stockage ASM partagé est
obtenu à l'aide d'Oracle Clusterware. Cette conception comprend des environnements de base
de données clusterisés et non clusterisés sur chacun des trois noeuds. Cette conception est
utile dans un environnement de grid où une instance peut être déplacée sur n'importe quel
noeud du serveur de base de données, et où plusieurs instances peuvent résider sur n'importe
quel noeud.

Privilèges système ASM
• Une instance ASM n'a pas de dictionnaire de données. Le seul

moyen de s'y connecter est d'utiliser les privilèges système
ci-après.
Privilège ASM Groupe de Privilège
privilèges
SYSASM OSASM Privilège d'administration complet
SYSDBA OSDBA for ASM

Accès aux données stockées dans ASM
Création et suppression de fichiers
Octroi et révocation d'accès fichiers
SYSOPER OSOPER for ASM Privilèges limités permettant de démarrer et
d'arrêter l'instance ASM avec des
commandes non destructives ALTER
DISKGROUP
• Dans l'environnement ASM, l'utilisateur SYS est créé

automatiquement avec le privilège SYSASM.
Privilèges système ASM

Une instance ASM n'a pas de dictionnaire de données. Le seul moyen de s'y connecter est le
recours aux privilèges système SYSASM, SYSDBA ou SYSOPER. Le tableau de la diapositive
ci-dessus présente les privilèges système ASM.
Le privilège SYSDBA de l'instance ASM accorde l'accès aux données stockées dans ASM.
Pour appliquer des commandes SQL*Plus afin de gérer les composants ASM associés à la
base de données, connectez-vous en tant que SYSDBA à l'instance de base de données plutôt
qu'à l'instance ASM. Les utilisateurs connectés en tant que SYSDBA peuvent créer et
supprimer des fichiers, des alias, des répertoires et des modèles, afficher différentes vues des
instances ASM, manipuler les fichiers qui ont été créés par cet utilisateur, accéder à des
fichiers pour lesquels un autre utilisateur a explicitement accordé l'accès, ou encore accorder
le contrôle d'accès aux fichiers ASM à d'autres utilisateurs. Les utilisateurs connectés avec le
privilège SYSDBA ne peuvent pas créer ou redimensionner un groupe de disques lorsu'ils sont
connectés avec le privilège SYSDBA.
Remarque : Par défaut, ASMCMD essaie de se connecter en tant que SYSDBA en fonction
du groupe du système d'exploitation.
Les utilisateurs bénéficiant du privilège SYSOPER sur l'instance ASM peuvent démarrer,
arrêter, monter, démonter et vérifier des groupes de disques (mais pas la réparation). D'autres
opérations, telles que CREATE DISKGROUP et ADD/DROP/RESIZE DISK, nécessitent le
privilège SYSASM et ne sont pas possibles avec le privilège SYSOPER. Le privilège
SYSOPER ne donne pas accès aux vues système —par exemple, v$asm_*.
Lors de l'installation, l'utilisateur ASMSNMP est créé avec les privilèges SYSDBA pour
surveiller l'instance Oracle ASM.

Groupes OS ASM avec séparation des rôles
Pour séparer les tâches des administrateurs ASM et des DBA,

il existe six groupes OS :
Groupe Pour Exemple Privilège

OSASM ASM asmadmin SYSASM
OSDBA ASM asmdba SYSDBA
OSOPER ASM asmoper SYSOPER

groupe Les deux oinstall
oraInventory
OSDBA BdD dba SYSDBA
OSOPER BdD oper SYSOPER
Groupes OS ASM avec séparation des rôles

Dans Oracle Database 11g, un nouveau groupe OS doté de privilèges a été introduit —le
groupe OSASM— qui est utilisé exclusivement pour ASM. Les membres de ce groupe
peuvent se connecter en tant que SYSASM via l'authentification par le système d'exploitation
et ont ainsi un accès complet à ASM. Au départ, seul l'utilisateur du système d'exploitation
qui installe le logiciel Grid Infrastructure est membre de ce groupe. Toutefois, d'autres
utilisateurs peuvent être ajoutés. Ce groupe est également propriétaire des disques ASM. Les
fichiers binaires Oracle doivent effectuer une opération setgid sur ce groupe, afin que les
instances et les outils Oracle puissent accéder aux disques ASM sans que les utilisateurs aient
un accès direct à ces unités. Dans l'exemple, le nom de ce groupe est asmadmin.
Dans l'exemple, le groupe OSDBA pour ASM est appelé asmdba. Les membres de ce groupe
peuvent se connecter à l'instance ASM en tant que SYSDBA. Chaque propriétaire d'une
instance de base de données qui utilisera ASM pour le stockage doit être un membre de ce
groupe. Le groupe OSDBA pour ASM peut être un groupe autre que le groupe OSDBA pour
une base de données.
Dans l'exemple, le groupe OSOPER pour ASM est nommé asmoper. Les membres de ce
groupe OS ont le privilège SYSOPER, qui limite le jeu de commandes SQL autorisées au
minimum requis pour la gestion de base d'une instance ASM déjà configurée. Le groupe
OSOPER d'une base de données est un groupe différent.

Authentification pour l'accès aux instances ASM
Il existe trois modes de connexion aux instances ASM :

• Connexion locale en utilisant l'authentification par le système
d'exploitation
$ sqlplus / AS SYSASM
SQL> CONNECT / AS SYSOPER
• Connexion locale en utilisant l'authentification par mot de passe

$ sqlplus fred/xyzabc AS SYSDBA
SQL> CONNECT bill/abc123 AS SYSASM
• Connexion à distance à l'aide d'Oracle Net Services et de

l'authentification par mot de passe
$ sqlplus bill/abc123@asm1 AS SYSASM
SQL> CONNECT fred/xyzabc@asm2 AS SYSDBA
Authentification pour l'accès aux instances ASM

Il existe trois modes de connexion aux instances ASM :
• Connexion locale en utilisant l'authentification par le système d'exploitation. Les
utilisateurs du système d'exploitation qui sont membres du groupe OSASM, OSDBA pour
ASM ou OSOPER peuvent se connecter à ASM sans indiquer d'informations
d'identification supplémentaires. Par exemple, un utilisateur du système d'exploitation
qui est membre du groupe OSASM peut se connecter à l'instance ASM avec les privilèges
d'administration complets en utilisant :
CONNECT / AS SYSASM
• Connexion locale en utilisant l'authentification par mot de passe. L'exemple suivant
crée une connexion locale en utilisant l'authentification par mot de passe :
CONNECT sys/<sys password> AS SYSASM
• Connexion à distance via Oracle Net Services en utilisant l'authentification par mot
de passe. L'authentification basée sur un mot de passe est également prise en charge à
distance via Oracle Net Services. L'exemple suivant crée une connexion à distance via
Oracle Net Services en utilisant l'authentification par mot de passe.
CONNECT sys/<sys_password>@<net_services_alias> AS SYSASM

Authentification basée sur un mot de passe

pour ASM
• Authentification basée sur un mot de passe :
– Utilise un fichier de mots de passe
– Peut être utilisée localement et à distance
— REMOTE_LOGIN_PASSWORDFILE doit avoir une valeur autre
que NONE pour permettre l'authentification par mot de passe à
distance.
• Un fichier de mots de passe est créé initialement :

– Par Oracle Universal Installer lors de l'installation d'ASM
– Manuellement à l'aide de l'utilitaire orapwd
– Avec seulement l'utilisateur SYS
• Il est possible d'ajouter des utilisateurs au fichier de mots
de passe de deux façons :
– Commande SQL*Plus GRANT
– Commande ASMCMD orapwuser
Authentification basée sur un mot de passe pour ASM

Pour ASM, l'authentification basée sur un mot de passe utilise un fichier de mots de passe.
Cette méthode peut être employée localement ou à distance. L'authentification basée sur un
mot de passe est activée par défaut lorsque l'instance ASM est créée par Oracle Universal
Installer. Vous pouvez créer un fichier de mots de passe pour ASM manuellement à l'aide de
l'utilitaire orapwd.
Pour activer l'authentification basée sur un mot de passe à distance, le fichier de mots de passe
doit exister, et le paramètre d'initialisation REMOTE_LOGIN_PASSWORDFILE doit avoir
une valeur autre que NONE. La valeur par défaut est EXCLUSIVE pour les instances ASM.
Lorsque le fichier de mots de passe est initialement créé, il contient seulement l'utilisateur de
base de données SYS. Pour ajouter d'autres utilisateurs, vous pouvez utiliser les commandes
SQL CREATE USER et GRANT. Par exemple :
REM create a new user, then grant the SYSOPER privilege
SQL> CREATE USER new_user IDENTIFIED BY new_user_passwd;
SQL> GRANT SYSOPER TO new_user;
Avec ASMCMD, vous pouvez ajouter un utilisateur avec le privilège SYSASM comme suit :
asmcmd orapwuser –-add –-privilege sysasm new_user

Gérer le fichier de mots de passe ASM
Pour l'instance ASM, le fichier de mots de passe :

• Peut être créé par un utilisateur possédant le logiciel ASM
• Contient les rôles attribués aux utilisateurs
• Est requis par Oracle Enterprise Manager pour la
connexion à distance à l'instance ASM
• Peut être consulté de la manière suivante :

– SQL*Plus :SELECT * FROM V$PWFILE USERS
– ASMCMD :: lspwusr
Gérer le fichier de mots de passe ASM

Oracle Enterprise Manager a besoin d'un fichier de mots de passe pour se connecter à
l'instance ASM.
Pour afficher les utilisateurs indiqués dans ce fichier avec les privilèges associés, utilisez la
commande SQL*Plus :
SELECT * FROM V$PWFILE_USERS;
ou la commande ASMCMD :
lspwusr
Pour révoquer un privilège, utilisez la commande SQL*Plus :
REVOKE SYSASM FROM user
Dans ASMCMD, vous pouvez modifier le privilège avec :
asmcmd orapwuser --modify --privilege sysasm user
Remarque : Le privilège indiqué, quel qu'il soit, remplace n'importe quel autre privilège
accordé précédemment.
Dans ASMCMD, vous pouvez supprimer un utilisateur du fichier de mots de passe avec :
asmcmd orapwuser --delete user
Remarque : Les utilisateurs d'ASMCMD ne peuvent pas se connecter via le fichier de mots
de passe. Leurs privilèges dépendent des groupes OS dont ils sont membres.

Utiliser un groupe OS unique
Rôle/logiciel Propriétaire Groupes/privilèges

du logiciel
Administrateur Oracle oracle dba/SYSASM, SYSDBA,
ASM/répertoire d'origine d'Oracle SYSOPER
Grid Infrastructure
Database administrator 1/Database oracle dba/SYSASM, SYSDBA,
home 1 SYSOPER

Database administrator 2/Database oracle dba/SYSASM, SYSDBA,
home 2 SYSOPER
Operating system disk device oracle dba
owner
Utiliser un groupe OS unique

Oracle Grid Infrastructure et Oracle Database peuvent être installés avec un seul groupe OS
pour tous les utilisateurs ASM.
Par exemple, l'utilisateur oracle peut installer les logiciels Grid Infrastructure et Oracle
Database, et donc être le propriétaire des deux ensembles de logiciels. Les groupes
recommandés dans ce cas sont le groupe principal pour l'utilisateur oinstall et le groupe
secondaire dba.
Les unités de disque appartiennent à l'utilisateur oracle. L'utilisateur OS oracle peut se
connecter aux bases de données en tant que SYSDBA, et l'instance ASM, en tant que SYSASM.
Il n'existe aucune séparation des responsabilités. L'utilisateur peut exécuter toutes les
fonctions de gestion de l'instance ASM et les deux bases de données.

Utiliser des groupes OS distincts
Rôle/logiciel Propriétaire Groupes/Privilèges/Groupe OS

du logiciel
Oracle ASM grid asmadmin/SYSASM/OSASM
administrator asmdba/SYSDBA/OSDBA for ASM
Oracle Grid asmoper/SYSOPER /OSOPER for ASM
Infrastructure home
Database administrator oracle1 asmdba/SYSDBA
1 dba1/SYSDBA for db1

Database home 1 oper1/SYSOPER fro db1
Database administrator oracle2 asmdba/SYSASM
2 dba2/SYSDBA
Database home 2 oper2/SYSOPER
Operating system disk grid asmadmin
device owner
Utiliser des groupes OS distincts

Lorsque vous implémentez des privilèges d'administrateur distincts, sélectionnez pour
l'instance ASM un groupe OSDBA différent de ceux que vous choisissez pour l'instance de
base de données. Par exemple, dba1 et dba2 sont les groupes dotés de privilèges pour
database1 et database2. asmadmin est le groupe doté de privilèges pour ASM. Notez que les
deux propriétaires de base de données sont des membres du groupe asmdba. Ainsi, chacun
d'eux peut créer, visualiser et gérer les fichiers de données ASM, mais pas les groupes de
disques ASM.
Dans l'exemple, il est supposé que les administrateurs du stockage et les administrateurs de
base de données sont des personnes différentes appartenant à des groupes différents. Les
administrateurs de base de données de database1 sont différents de ceux de database2.

Composants ASM :
Logiciels
Pour l'installation ASM des logiciels :
• Les répertoires sont indiqués par les variables d'environnement
du système d'exploitation.
– ORACLE_BASE est le répertoire supérieur pour le propriétaire d'un
logiciel particulier.
– ORACLE_HOME est utilisé pour identifier le répertoire supérieur du
logiciel Grid Infrastructure.

• Utilisez un répertoire ORACLE_BASE commun pour tous les
produits appartenant au même utilisateur.
• Utilisez un emplacement ORACLE_HOME distinct de celui des
autres produits Oracle même s'ils ont le même numéro de
version.
• Ne placez pas le répertoire ORACLE HOME de Grid sous
ORACLE_BASE.
• ORACLE_HOME nécessite de 3 à 5 Go d'espace disque.
Composants ASM : Logiciels

Il est nécessaire de créer deux répertoires pour l'installation des fichiers binaires de logiciel :
le répertoire Oracle Base et le répertoire Oracle Home. Le répertoire Oracle Base est le
répertoire de plus haut niveau pour l'installation des logiciels Oracle d'un propriétaire
spécifique. Les recommandations OFA (Optimal Flexible Architecture) conseillent d'utiliser
un chemin du type /u01/app/<software owner>, dans lequel le propriétaire des logiciels
est oracle si Database et Grid Infrastructure ont le même propriétaire, et grid si les
propriétaires sont distincts. Indiquez l'emplacement du répertoire Oracle Base à l'aide de la
variable d'environnement système $ORACLE_BASE. Si vous avez défini la variable
d'environnement $ORACLE_BASE pour l'utilisateur grid, Oracle Universal Installer crée le
répertoire Oracle Inventory dans le répertoire $ORACLE_BASE/../oraInventory. Le
répertoire Oracle Inventory (oraInventory) contient l'inventaire de tous les logiciels
installés sur le système.
Le répertoire d'origine Oracle Home est le répertoire dans lequel vous choisissez d'installer le
logiciel d'un produit Oracle spécifique. Vous devez indiquer des répertoires Oracle Home
distincts pour les différents produits Oracle installés ou pour les différentes versions d'un
même produit. Les règles de l'architecture OFA recommandent d'utiliser un chemin similaire
à /u01/app/11.2.0/grid.
Définissez la variable d'environnement système $ORACLE_HOME pour indiquer l'emplacement
du répertoire Oracle Home du logiciel Grid Infrastructure, lequel nécessite de 3 à 5 Go
d'espace disque suivant le type d'installation.

Composants ASM :
Instance ASM
L'instance ASM comprend les processus et la mémoire utilisés
par ASM.
Mémoire SGA (System Global Area)
Zone de Zone de
mémoire mémoire Cache Mémoire
partagée Large ASM libre

Pool
Processus – Composants de la CPU

RBAL ARBn GMON Onnn PZ9n
MARK
Autres processus divers
Instance ASM
Composants ASM : Instance ASM

A chaque démarrage d'ASM ou d'une base de données, une zone de mémoire partagée appelée
SGA (System Global Area) est allouée et des processus en arrière-plan sont lancés. La
combinaison des processus en arrière-plan et de la mémoire SGA constitue une instance ASM.
Une instance représente les composants de type CPU et RAM d'un environnement d'exécution
ASM.
La mémoire SGA associée à une instance ASM est allouée et utilisée autrement que la mémoire
SGA d'une instance de base de données. Elle est divisée en quatre zones principales :
• Zone de mémoire partagée : Utilisée pour les métadonnées.
• Zone de mémoire LARGE POOL : Utilisée pour les opérations en parallèle.
• Cache ASM : Utilisé pour la lecture et l'écriture des blocs pendant les opérations de
rééquilibrage.
• Mémoire libre : Mémoire existante qui n'a pas été allouée.
La quantité de mémoire minimale recommandée pour une instance ASM est 256 Mo. La
gestion automatique de la mémoire est activée par défaut pour chaque instance ASM. Elle règle
dynamiquement la taille des différents composants de la mémoire SGA. La quantité de
mémoire qui est nécessaire pour une instance ASM dépend de la quantité d'espace disque gérée
par ASM.
Une instance ASM comprend par ailleurs des processus en arrière-plan. Ceux-ci peuvent être
nombreux, mais ils ne sont pas toujours présents.

Composants ASM : Instance ASM (suite)
Les processus en arrière-plan propres à la fonctionnalité ASM sont décrits dans la diapositive
suivante. Etant donné que l'instance ASM partage la même base de code qu'une instance de
base de données Oracle, tous les processus en arrière-plan requis pour une instance de base de
données existent dans l'instance ASM. Certains sont obligatoires tandis que d'autres sont
facultatifs. Voici quelques exemples :
• ARCn : Processus d'archivage.
• CKPT : Processus de point de reprise (checkpoint).
• DBWn : Processus Database Writer.
• DIAG : Processus de diagnostic.
• Jnnn : Processus de gestion de la file d'attente des travaux.
• LGWR : Processus Log Writer.

• PMON : Processus de surveillance.
• PSP0 : Processus de génération dynamique de processus (Spawner).
• QMNn : Processus de surveillance de file d'attente (Queue Monitor).
• RECO : Processus de récupération (Recoverer).
• SMON : Moniteur système (System Monitor).
• VKTM : Compteur de temps virtuel (Virtual Keeper of Time).
• MMAN : Processus gestionnaire de mémoire (Memory Manager).
Cette liste de processus n'est pas exhaustive. Selon les options de base de données et la
configuration de l'instance, il peut exister des centaines de processus qui s'exécutent en
arrière-plan. Pour une instance ASM, ces processus n'effectuent pas toujours les mêmes
tâches que pour une instance de base de données. Par exemple, le processus LGWR d'une
instance de base de données est chargé de copier les modifications stockées dans le tampon de
journalisation de la SGA vers les fichiers de journalisation en ligne figurant sur le disque.
Pour sa part, une instance ASM n'a pas de tampon de journalisation dans la mémoire SGA, et
elle n'utilise pas de fichiers de journalisation en ligne. Son processus LGWR copie les
informations de journalisation sur un groupe de disques ASM.
Si l'instance ASM est clusterisée, elle utilise des processus supplémentaires liés à la gestion
de cluster. Voici quelques exemples :
• LMON : Moniteur du service global de mise en file d'attente (Global Enqueue Service).
• LMDn : Démon du service global de mise en file d'attente (Global Enqueue Service).
• LMSn : Processus du service global de mise en cache (Global Cache Service).
• LCKn : Processus de verrouillage.
Des processus supplémentaires sont démarrés lorsque des volumes ADVM sont configurés.
• VDBG : Le processus en arrière-plan de gestion de volumes transmet au gestionnaire de
volumes logiques (Dynamic Volume Manager) les demandes de verrouillage ou de
déverrouillage d'extent pour des opérations sur les volumes. VDBG est un processus en
arrière-plan fatal. Un arrêt non planifié de ce processus entraîne la panne de l'instance
ASM.
• VBGn : Les processus en arrière-plan de volume (Volume Background) attendent les
demandes du gestionnaire de volumes dynamiques, qui doivent être coordonnées avec
l'instance ASM. Un exemple d'une telle demande est l'ouverture ou la fermeture d'un
fichier de volume ASM lorsque le gestionnaire de volumes dynamiques est averti de
l'ouverture d'un volume (éventuellement suite à une demande de montage du système de
fichiers) ou de la fermeture d'un volume ouvert (éventuellement suite à une demande de
démontage du système de fichiers). La mort non planifiée de l'un de ces processus n'a
aucun effet sur l'instance ASM.
• VMB: Le processus VMB (Volume Membership Background) coordonne les membres du
cluster avec l'instance ASM.
Composants ASM :
Processus principaux
Les principaux processus d'une instance ASM sont
responsables des activités ASM.
Processus Description
RBAL Ouvre tous les fichiers de périphérique dans le cadre du processus de

repérage et coordonne l'activité de rééquilibrage
ARBn Un ou plusieurs processus esclaves qui assurent l'activité de rééquilibrage

GMON Gère les activités de niveau disque telles que la suppression ou la mise hors
ligne, ou la modification du niveau de compatibilité d'un groupe de disques
ASM
MARK Marque les unités d'allocation ASM comme étant obsolètes le cas échéant
Onnn Un ou plusieurs processus esclaves ASM formant un pool de connexions à

l'instance ASM pour l'échange de messages
PZ9n Un ou plusieurs processus esclaves en parallèle utilisés pour extraire des

données à partir de vues GV$ dans une installation ASM clusterisée
Composants d'une instance ASM : Processus principaux

L'instance ASM utilise des processus en arrière-plan dédiés pour la majeure partie de ses
fonctionnalités. Le processus RBAL (Rebalance) coordonne l'activité de rééquilibrage entre
les groupes de disques d'une instance ASM. Il effectue une ouverture globale de tous les
disques ASM. Les mouvements de rééquilibrage réels entre les extents de données de
l'instance sont assurés par les processus ARBn. Plusieurs processus ARBn peuvent opérer en
même temps. Ils sont nommés ARB0, ARB1, et ainsi de suite. Le processus GMON gère les
membres des groupes de disques ASM. Le processus MARK définit comme obsolètes les
unités d'allocation ASM pour lesquelles l'écriture sur un disque hors ligne a échoué. Les
processus Onnn représentent le côté serveur d'une connexion client/serveur. Ils apparaissent
au démarrage de l'instance et disparaissent ensuite. Ils constituent un pool de connexions à
l'instance ASM pour l'échange de messages et n'apparaissent qu'en cas de nécessité. Les
processus PZ9n correspondent à un ou plusieurs processus esclaves en parallèle qui sont
utilisés pour extraire des données lorsqu'ASM s'exécute dans une configuration clusterisée sur
plusieurs machines simultanément.

Composants ASM :
Processus d'écoute ASM
Le processus d'écoute ASM est un processus permettant d'établir des
connexions réseau entre des clients ASM et l'instance ASM.
• Il s'exécute par défaut dans le répertoire Grid
$ORACLE_HOME/bin.
• Il écoute sur le port 1521 par défaut.
• Il est équivalent à un processus d'écoute d'instance de base de
données.

• Il est capable d'écouter toutes les instances de base de données
situées sur la même machine que l'instance ASM.
• Il peut s'exécuter en même temps que des processus d'écoute
de base de données distincts ou être remplacé par un processus
d'écoute de base de données.
• Il est nommé TNSLSNR sur la plateforme Linux.
Composants ASM : Processus d'écoute ASM

Le processus d'écoute ASM est un processus permettant d'établir des connexions réseau entre
des clients ASM et l'instance ASM. Il est installé avec le logiciel ASM. Il s'exécute par défaut
dans le répertoire $ORACLE_HOME/bin de Grid sur le port 1521. Le processus d'écoute ASM
est équivalent à un processus d'écoute de base de données ou Oracle Net. Etant donné
qu'ASM est généralement installé avant la base de données, le processus d'écoute ASM est
configuré et démarré automatiquement pour fournir une passerelle vers l'instance ASM pour
les clients distants. Ce processus d'écoute est capable d'écouter toutes les instances exécutées
sur la machine, y compris les instances de base de données. Après l'installation d'ASM,
l'installation d'une base de données est exécutée dans un autre emplacement ORACLE_HOME.
Chaque emplacement ORACLE_HOME peut fournir un processus d'écoute supplémentaire et un
ensemble de fichiers de configuration. Le processus d'écoute ASM et les processus d'écoute
de base de données distincts peuvent s'exécuter simultanément sur des ports différents, ou
bien processus d'écoute ASM peut être remplacé par un processus d'écoute de base de
données distinct. Il existe deux fichiers de configuration pour le processus d'écoute. Il s'agit
des fichiers suivants :
$ORACLE_HOME/network/admin/listener.ora
$ORACLE_HOME/network/admin/sqlnet.ora (Optional)
Le processus d'écoute est nommé tnslsnr sur la plateforme Linux. Il peut être géré à l'aide
de l'utilitaire srvctl . La syntaxe à utiliser pour démarrer et arrêter le processus d'écoute est
la suivante :
srvctl start listener -n nodename
srvctl stop listener -n nodename

Composants ASM :
Fichiers de configuration
L'installation ASM du logiciel utilise plusieurs fichiers de configuration pour
définir l'environnement.
• Les fichiers de configuration d'une instance ASM sont les suivants :
– Le fichier de paramètres serveur (SPFILE), qui initialise l'instance ASM et
définit les paramètres de démarrage.
– orapw+ASM qui est le fichier de mots de passe binaire utilisé pour
l'authentification à distance auprès de l'instance ASM.
• Les fichiers de configuration d'un processus d'écoute ASM sont les

suivants :
– listener.ora, un fichier texte qui définit le processus d'écoute ASM.
– sqlnet.ora, un fichier texte facultatif qui fournit des options
supplémentaires sur le processus d'écoute.
• Autres fichiers textuels de configuration :
– /etc/oratab, qui répertorie toutes les instances sur l'ordinateur hôte.
– /etc/oraInst.loc, qui définit le répertoire orainventory.
Composants ASM : Fichiers de configuration

La plupart des métadonnées liées à ASM sont stockées dans le groupe de disques ASM et
dans les tables implantées en mémoire de l'instance ASM. Quelques autres fichiers sont
utilisés pour la configuration. L'instance ASM utilise deux fichiers de configuration. Le
fichier de paramètres serveur qui définit les paramètres d'initialisation au démarrage est un
fichier binaire créé par défaut dans un groupe de disques ASM spécifique dans
+<disk_group>/<cluster>/ASMPARAMETERFILE/register.253.nnnnnn.
L'administrateur peut créer un fichier de paramètres d'initialisation au format texte nommé par
défaut init+ASMn.ora. La version texte et la version binaire sont mutuellement exclusives
pour le démarrage.
L'autre fichier utilisé pour configurer l'instance est le fichier de mots de passe binaire nommé
orapw+ASM. Ce fichier est utilisé pour l'authentification locale et distante à partir des clients
ASM. Le fichier de mots de passe se trouve dans le répertoire $ORACLE_HOME/dbs.
Le processus d'écoute ASM utilise également deux fichiers de configuration. Le fichier
principal de configuration du processus d'écoute est le fichier texte listener.ora. Il
définit le protocole et les informations correspondantes pour les points de connexion du
processus d'écoute. L'autre fichier est le fichier texte facultatif sqlnet.ora. Il est utilisé
pour définir le domaine et la méthode de résolution de l'ordinateur. Ces deux fichiers de
configuration se trouvent dans le répertoire $ORACLE_HOME/network/admin.
Il existe quelques autres fichiers de configuration divers de type texte. Le fichier texte
/etc/oratab répertorie les instances exécutées sur la machine hôte tandis que le fichier
/etc/oraInst.loc définit l'emplacement du fichier OraInventory central.

Composants ASM :
Services de groupe
Les services de groupe fournis par Oracle Clusterware permettent
aux applications qui coopèrent de communiquer dans un
environnement d'égal à égal.
• Les services de groupe de l'environnement Oracle :
– Fournissent les informations nécessaires pour établir les connexions
– Aident à effectuer une récupération après un verrouillage
– Garantissent l'unicité des numéros des groupes de disques ASM

– Surveillent l'appartenance aux noeuds, les évictions et les verrous de
cluster
• Oracle Clusterware est chargé des opérations suivantes :
– Démarrer et arrêter des instances ASM
– Démarrer et arrêter des instances de base de données dépendantes
– Monter et démonter des groupes de disques
– Monter et démonter des volumes ACFS
Composants ASM : Services de groupe

ASM dépend des services de groupe fournis par Oracle Clusterware dans tous les
environnements, clusterisés ou non. Ces services permettent aux applications qui coopèrent,
telles que les instances ASM et de base de données, de communiquer dans un environnement
d'égal à égal (peer to peer) et de déterminer le statut d'autres applications. Pour ASM, les
services de groupe présentent les caractéristiques suivantes :
• Ils permettent à l'instance de base de données de localiser l'instance ASM et les
informations de connexion et d'identification associées pour établir une connexion OCI
(Oracle Call Interface).
• Ils aident à effectuer une récupération après un verrouillage. L'instance ASM gère
certains verrous pour le compte des instances de base de données. Dans le cas où une
instance de base de données échoue, ASM utilise les services de groupe de ocssd.bin
pour vérifier que tous les processus de base de données sont terminés avant de libérer les
verrous.
• Ils garantissent l'unicité du numéro affecté à un groupe de disques ASM lors de
l'exécution.
Oracle Clusterware est chargé de gérer l'appartenance aux noeuds et la surveillance des
signaux d'activité, le verrouillage de base du cluster et les évictions de noeud.
Oracle Clusterware assure le démarrage et l'arrêt pour l'instance ASM et les instances de base
de données et les ressources dépendantes, ainsi que pour les ressources dont dépend ASM.

Composants ASM :
Groupe de disques ASM
Le groupe de disques ASM est l'objet sous-jacent géré par ASM :
• Il comprend un ou plusieurs disques ASM qui fournissent de
l'espace.
• Il contient des métadonnées autonomes et des informations de
journalisation pour la gestion de l'espace au sein du groupe.
• Il est la base utilisée pour le stockage des fichiers ASM.
• Il prend en charge trois types de groupe de disques basés sur les
niveaux suivants de redondance :

– Normal correspond par défaut à la mise en miroir bidirectionnelle
interne des fichiers ASM.
– High correspond par défaut à la mise en miroir tridirectionnelle des
fichiers ASM.
– External n'utilise aucune mise en miroir ASM mais assure la
redondance à l'aide de disques externes ou d'une configuration RAID.
• Il prend en charge les fichiers ASM à partir de plusieurs bases
de données.
Composants ASM : Groupe de disques ASM

Un groupe de disques ASM se compose d'un ou plusieurs disques ASM fournissant de
l'espace. Il s'agit de l'objet principal géré par ASM. Chaque groupe de disques contient ses
propres métadonnées, ainsi que les informations de journalisation requises pour la gestion de
l'espace. Les fichiers ASM sont affectés à partir de groupes de disques. Cette méthode est
comparable aux volumes logiques ou aux unités logiques d'autres solutions de gestion de
disques. Un fichier ASM est complètement contenu dans un groupe de disques, mais un
groupe de disques ASM peut contenir des fichiers provenant de bases de données distinctes.
Il est possible de créer plusieurs groupes de disques, mais il est recommandé de n'en créer que
deux. L'un des groupes doit être utilisé pour toutes les données des bases, et l'autre doit servir
pour la zone de récupération rapide des bases.
Lorsque vous créez un groupe de disques, vous définissez un type de groupe de disques ASM
basé sur l'un des trois niveaux suivants de redondance :
• Normal pour la mise en miroir bidirectionnelle
• High pour la mise en miroir tridirectionnelle
• External pour assurer la redondance à l'aide d'éléments matériels externes
Le niveau de redondance contrôle le nombre de défaillances de disques qui sont tolérées sans
entraîner un démontage du groupe de disques ou une perte de données. Il définit la valeur par
défaut pour le nombre de copies d'extents de fichier ASM, mais la redondance elle-même est
contrôlée au niveau fichier.

Groupe de disques ASM : Groupes d'échec
Un groupe d'échec est un sous-ensemble de disques d'un groupe qui

peuvent échouer en même temps parce qu'ils partagent des éléments
matériels.
• Les groupes d'échec permettent la mise en miroir des métadonnées
et des données utilisateur.
• Par défaut, chaque disque est placé dans un groupe d'échec
constitué de lui-même.
• Lors de la création d'un groupe de disques, plusieurs disques

peuvent être placés dans un même groupe d'échec.
• Les groupes d'échec s'appliquent uniquement aux groupes de
disques présentant une redondance normale ou élevée.
– Un groupe de disques à redondance normale requiert au moins deux
groupes d'échec pour implémenter la mise en miroir bidirectionnelle
des fichiers.
– Un groupe de disques à redondance élevée requiert au moins trois
groupes d'échec pour implémenter la mise en miroir tridirectionnelle
des fichiers.
Groupe de disques ASM : Groupes d'échec

Un groupe d'échec est un sous-ensemble de disques ASM d'un groupe qui peuvent échouer
en même temps parce qu'ils partagent des éléments matériels. La défaillance des éléments
matériels communs doit pouvoir être tolérée. Quatre disques figurant dans un même plateau
amovible, non protégés avec RAID, doivent appartenir au même groupe d'échec car en cas de
retrait du plateau, les quatre disques échouent en même temps. Des disques figurant dans la
même armoire peuvent appartenir à des groupes d'échec différents si celle-ci a un système
redondant d'alimentation et de refroidissement. Il n'est alors pas nécessaire de se protéger
contre les pannes de l'ensemble de l'armoire.
Les groupes d'échec sont employés pour stocker les copies miroir des données lorsqu'ASM est
utilisé pour la mise en miroir via la déclaration d'un type de groupe de disques Normal ou
High lors de la création. Un groupe de disques à redondance normale requiert au moins deux
groupes d'échec pour implémenter la mise en miroir bidirectionnelle des fichiers. Un groupe de
disques à redondance élevée requiert au moins trois groupes d'échec pour implémenter la mise
en miroir tridirectionnelle des fichiers.
Il existe toujours des groupes d'échec, même s'ils ne sont pas créés explicitement. Si vous
n'indiquez pas de groupe d'échec pour un disque, ce disque est placé dans un groupe d'échec
constitué de lui-même, qui porte le nom du disque. Par conséquent, si 20 disques appartiennent
à un seul groupe de disques, il peut y avoir 20 groupes d'échec. Les groupes d'échec n'ont de
sens que pour les groupes de disques présentant une redondance normale ou élevée.
Tous les groupes d'échec appartenant au même groupe de disques doivent être créés avec la
même capacité pour éviter les problèmes d'allocation d'espace.

Composants d'une instance ASM : Disques ASM
Les disques ASM sont les périphériques de stockage constituant les

groupes de disques ASM.
• Ils sont formés de cinq sources, comme suit :
– Disque ou partition d'une unité de stockage
– Disque physique entier ou partition d'un disque physique
– Volume logique (LV) ou unité logique (LUN)
– Fichier réseau (NFS)
– Disque de grid Exadata

• Ils sont nommés lorsqu'ils sont ajoutés à un groupe de disques,
avec un nom différent de celui attribué à l'unité au niveau du
• Un disque ASM peut correspondre à plusieurs noms d'unité
système situés sur des noeuds distincts du cluster.
• Ils sont divisés en unités (AU) d'allocation qui peuvent avoir une
taille de 1, 2, 4, 8, 16, 32 ou 64 Mo.
Composants d'une instance ASM : Disques ASM

Les disques ASM sont les périphériques de stockage qui fournissent l'espace des groupes de
disques ASM. Ils ne sont pas toujours les mêmes que les disques physiques. Un disque ASM
comprend cinq sources, comme suit :
• Disque ou partition d'une unité de stockage
• Disque physique entier ou partition d'un disque physique
• Volume logique (LV) ou unité logique (LUN)
• Fichier réseau (NFS)
• Disque de grid Exadata
ASM n'utilise pas le nom de disque défini au niveau du système d'exploitation, mais le nom
qui est affecté au disque lors de son ajout au groupe de disques ASM. Les noms de disque
ASM utilisent une convention d'appellation logique. Dans un environnement de cluster, le
nom de disque ASM doit être le même pour tous les noeuds du cluster, mais le nom du
système d'exploitation peut être différent.
Chaque disque ASM est divisé en unités d'allocation (AU). L'unité d'allocation est l'élément
de base utilisé pour les affectations dans un groupe de disques. Un extent de fichier comprend
une ou plusieurs unités d'allocation. Un fichier ASM Oracle est constitué d'un ou de plusieurs
extents. Chaque extent de fichier est affecté à un disque ASM unique. Lorsque vous créez un
groupe de disques, vous pouvez définir la taille de l'unité d'allocation ASM avec une valeur
égale à une puissance de 2 comprise entre 1 et 64 Mo (1, 2, 4,… .64). ASM répartit les
fichiers de manière uniforme sur tous les disques du groupe. Cette configuration d'allocation
gère chaque disque avec un même niveau de capacité et une même charge d'E/S. Les
différents disques ASM ne doivent pas partager le même disque physique.

Composants ASM :
Fichiers ASM
Les fichiers ASM sont un jeu limité de types de fichier stockés dans un
groupe de disques ASM.
• Ils sont limités aux types de fichier suivants :
Fichiers de contrôle Journaux Flashback Jeu de fichiers dump Data
Pump
Fichiers de données Fichier SPFILE de BdD Configuration Data Guard
Fichiers de données Jeux de sauvegarde RMAN Bitmaps de suivi des

temporaires modifications

Fichiers de journalisation en Copies des fichiers de données Fichiers OCR
ligne RMAN
Fichiers de journalisation Fichiers de données de Fichier SPFILE ASM
archivés transport
• Ils sont stockés en tant que jeu ou ensemble d'extents de données.

• Ils sont répartis entre tous les disques d'un groupe de disques.
• Ils portent les noms commençant par un signe plus (+) qui sont générés
automatiquement, ou des alias définis par l'utilisateur.
Composants ASM : Fichiers ASM

Les fichiers ASM sont un jeu limité de types de fichier stockés dans un groupe de disques
ASM. Ils ne sont pas créés directement par ASM, mais ASM génère automatiquement leurs
noms. Un nom de fichier ASM commence par un signe plus (+) suivi du nom d'un groupe de
disques. En outre, il contient le nom de la base de données à l'origine de la création ainsi
qu'un qualificateur de type de fichier. Un nom de fichier entièrement qualifié présente le
format suivant :
+group/dbname/file type/file type tag.file.incarnation
Vous pouvez considérer le signe plus (+) comme le répertoire racine du système de fichiers
ASM, à l'instar de la barre oblique (/) dans les systèmes de fichiers Linux. Voici un exemple
de nom de fichier ASM entièrement qualifié :
+dgroup2/prod/controlfile/current.256.541956473
Le tableau de la diapositive répertorie les types de fichier valides qui peuvent être stockés
dans un groupe de disques ASM. Chaque fichier ASM doit être contenu dans un groupe de
disques unique, mais une base de données Oracle peut contenir des fichiers appartenant à
différents groupes de disques. Vous pouvez indiquer des alias conviviaux pour les fichiers
ASM en créant une structure de répertoires hiérarchique et utiliser les noms de répertoire
comme préfixes des noms de fichier.

Fichiers ASM : Extents et stripping
• ASM peut utiliser des extents de données de taille variable pour

contenir de fichiers volumineux, afin de limiter les besoins en termes
de stockage, et pour améliorer les performances.
– Chaque extent de données réside sur un disque unique.
– Les extents de données sont constitués d'une ou plusieurs unités
d'allocation.
– La taille de chaque extent de données est définie comme suit :
— 1 unité d'allocation par extent pour les 20 000 premiers extents (0-19999)

— 8 unités d'allocation par extent pour les 20 000 extents suivants
(20000-39999)
— 64 unités d'allocation par extent pour les extents suivants
• ASM répartit les fichiers par le biais des extents. Il utilise un
stripping grossier pour l'équilibrage de la charge et un stripping fin
pour réduire le temps d'attente.
– Le stripping grossier utilise toujours la taille d'unité d'allocation en
cours.
– Le stripping fin utilise toujours une taille de stripe de 128 Ko.
Fichiers ASM : Extents et stripping

Le contenu des fichiers ASM est stocké dans un groupe de disques comme un jeu d'extents de
données stockés sur des disques individuels. Chaque extent de données réside sur un disque
unique. Les extents sont constitués d'une ou plusieurs unités d'allocation. Pour le stockage de
fichiers de plus en plus plus volumineux, ASM utilise des extents de taille variable.
La taille d'extent initiale est égale à la taille de l'unité d'allocation, puis elle augmente
selon un facteur 8 ou 64 en fonction de seuils prédéfinis. Elle augmente selon un facteur 8
après 20 000 extents. Elle augmente une dernière fois selon un facteur 64 après
40 000 extents.
ASM utilise un stripping grossier pour équilibrer la charge entre tous les disques d'un groupe,
et un stripping fin pour réduire le temps d'attente d'E/S. Dans le premier cas, la taille de stripe
est toujours égale à la taille d'unité d'allocation en cours. Cette dernière correspond à la taille
d'unité d'allocation définie pour un groupe de disques à sa création. Elle peut être différente
pour chaque groupe de disques. La taille des stripes de niveau fin est égale à 128 Ko. Le
stripping fin s'intègre dans une série de stripping grossiers. Les fichiers de contrôle, les
fichiers de journalisation en ligne et les journaux Flashback utilisent le stripping fin par
défaut. Tous les autres types de fichier utilisent le stripping grossier. La méthode de stripping
par défaut peut être modifiée à l'aide de modèles personnalisés.

Fichiers ASM : Mise en miroir
La mise en miroir ASM est définie au niveau fichier.

• Deux fichiers peuvent partager le même groupe de disques, l'un
étant mis en miroir et l'autre non.
• ASM affecte les extents d'un fichier en plaçant la version
principale et la copie miroir dans des groupes d'échec distincts.
• Les options de mise en miroir disponibles pour tous les types de
groupe de disques ASM sont les suivantes :

Type de groupe de Niveaux de mise en Niveau de mise en
disques miroir pris en charge miroir par défaut
Redondance externe Pas de protection (aucun) Pas de protection (aucun)
Redondance normale Bidirectionnelle Bidirectionnelle

Tridirectionnelle
Pas de protection (aucun)
Redondance élevée Tridirectionnelle Tridirectionnelle
Groupe de disques ASM : Mise en miroir

La mise en miroir préserve l'intégrité des données en conservant des copies des données sur
plusieurs disques afin d'éviter les risques de panne en un point unique. La mise en miroir
ASM est plus souple que la mise en miroir RAID traditionnelle parce que vous pouvez définir
le niveau de redondance pour chaque fichier d'un groupe de disques. Deux fichiers peuvent
partager le même groupe de disques, l'un étant mis en miroir et l'autre non.
Lorsqu'ASM alloue un extent pour un fichier présentant une redondance normale (mise en
miroir bidirectionnelle), il alloue un extent primaire et un extent secondaire. ASM sélectionne
le disque de stockage de l'extent secondaire dans un groupe d'échec différent de celui de
l'extent primaire. Ainsi, la défaillance simultanée de tous les disques d'un groupe d'échec
n'entraîne aucune perte de données.
Le tableau de la diapositive présente les types de groupe de disques, les niveaux de mise en
miroir pris en charge pour les fichiers au sein de chaque groupe de disques, et le niveau par
défaut de mise en miroir utilisé pour tous les fichiers du groupe de disques lorsqu'aucune mise
en miroir personnalisée n'est indiquée.
Avec un groupe de disques à redondance externe, ASM s'appuie sur le système de stockage
pour fournir des fonctionnalités RAID. Toute erreur d'écriture entraîne un démontage forcé de
l'ensemble du groupe de disques. Avec une redondance normale, la perte d'un disque ASM est
tolérée. Avec une redondance élevée, la perte de deux disques ASM figurant dans des groupes
d'échec différents est tolérée.

Composants ASM :
Clients ASM
Toute instance de base de données active qui utilise le
stockage ASM et est connectée à l'instance ASM est un client
ASM.
• Le suivi des clients ASM s'effectue dans la vue dynamique
des performances v$asm_client.
• Dans ASM, chaque fichier est associé à une seule base.

Instance de Instance de OCR
BdD Oracle B BdD Oracle C
Instance de
BdD Oracle A
Instance ASM
ADVM ACFS monté
Composants ASM : Clients ASM

Toute instance de base de données active qui utilise le stockage ASM et est connectée à
l'instance ASM est un client ASM. Dans ASM, un fichier n'est associé qu'à une seule base de
données, ou un seul client, à la fois. Cela peut être observé avec le nom entièrement qualifié
de chaque fichier. La deuxième partie de ce nom correspond au nom de la base de données,
comme suit :
+group/dbname/file type/file type tag.file.incarnation
Le suivi des clients ASM s'effectue dans la vue dynamique des performances
v$asm_client. Il existe une ligne pour chaque combinaison de nom d'instance de base de
données et de numéro de groupe de disques.
Un fichier OCR stocké dans ASM est répertorié en tant que client ASM avec le nom +ASM.
Les volumes ADVM sont des clients ASM et le système de fichiers doit être démonté avant
que l'instance puisse être arrêtée. Les volumes ASM ont le nom de client asmvol.
Remarque : De nombreux utilitaires sont capables de se connecter à l'instance ASM pour
effectuer l'administration. Ils sont parfois appelés clients ASM, mais ils n'apparaissent pas
dans la vue dynamique des performances v$asm_client. Dans ce cours, nous parlerons
d'utilitaires ASM.

Composants ASM :
Utilitaires ASM
De nombreux utilitaires peuvent être employés pour
l'administration d'ASM. Ces utilitaires peuvent comprendre :
• Oracle Universal Installer (OUI)
• ASM Configuration Assistant (ASMCA)
• Oracle Enterprise Manager (EM)
• SQL*Plus

• Utilitaire de ligne de commande ASM (ASMCMD)
• Utilitaire de contrôle de processus d'écoute (lsnrctl)
• Utilitaire de contrôle de serveur (srvctl)
• XML DB (FTP et HTTP)
Composants ASM : Utilitaires ASM

Il existe de nombreux utilitaires qui peuvent être utilisés pour l'administration d'ASM. Certains
de ces utilitaires se connectent directement à l'instance ASM tandis que d'autres peuvent
analyser les en-têtes de disque ASM directement. Ces utilitaires peuvent comprendre :
• Oracle Universal Installer (OUI) : Est utilisé pour installer le logiciel ASM et peut créer
les groupes de disques initiaux.
• ASM Configuration Assistant (ASMCA) : Est utilisé initialement pour configurer
l'instance ASM et pour créer des groupes de disques. Il peut être appelé à partir de
l'utilitaire OUI.
• Oracle Enterprise Manager (EM) : Est utilisé pour exécuter l'administration centrale
d'un environnement de grid, y compris celle de l'instance ASM, à l'aide d'une interface
client graphique.
• SQL*Plus : Est utilisé pour accéder à l'instance ASM à partir de la ligne de commande,
à l'aide de commandes SQL. Toutes les commandes ASM et toutes les tâches
d'administration d'ASM peuvent être lancées avec cet utilitaire.
• Utilitaire de ligne de commande ASM (ASMCMD) : Est utilisé pour administrer ASM
à partir de la ligne de commande sans utiliser le langage SQL. La syntaxe employée est de
type UNIX.
• Utilitaire de contrôle de processus d'écoute : (Le contrôleur de serveur est préféré.)
Est utilisé pour démarrer, arrêter, puis vérifier le statut du processus d'écoute ASM.
• Utilitaire de contrôle de serveur : Est utilisé pour démarrer, arrêter, puis vérifier le statut
de toutes les instances ASM d'un environnement de cluster via une commande unique.
• XML DB : Permet d'accéder aux fichiers ASM via FTP et HTTP.

Evolutivité d'ASM
ASM impose les limites suivantes :

• 63 groupes de disques dans un système de stockage
• 10 000 disques ASM dans un système de stockage
• Stockage maximum de deux téraoctets pour chaque disque ASM
(non Exadata)
• Stockage maximum de quatre pétaoctets pour chaque disque
ASM (Exadata)

• Stockage maximum de 40 exaoctets pour chaque système de
stockage
• 1 million de fichiers par groupe de disques
• Limites pour la taille des fichiers ASM (dans la base de données,
la limite est de 128 To) :
– Redondance External : 140 Po.
– Redondance Normal : 42 Po.
– Redondance High : 15 Po.
Evolutivité d'ASM
ASM impose les limites suivantes :
• 63 groupes de disques dans un système de stockage.
• 10 000 disques ASM dans un système de stockage.
• Stockage maximum de deux téraoctets pour chaque disque ASM non Exadata.
• Stockage maximum de quatre pétaoctets pour chaque disque ASM Exadata.
• Stockage maximum de 40 exaoctets pour chaque système de stockage.
• 1 million de fichiers par groupe de disques.
Oracle Database prend en charge des tailles de fichier allant jusqu'à 128 To. ASM prend en
charge des tailles supérieures dans n'importe quel mode de redondance. Cela permet une
capacité quasiment sans limite pour une croissance ultérieure. Les tailles limites des fichiers
ASM sont les suivantes :
• Redondance externe : 140 pétaoctets
• Redondance normale : 42 pétaoctets
• Redondance élevée : 15 pétaoctets
Les équivalences en termes de puissance de dix sont les suivantes :
• 1 gigaoctet = 1 000 000 000 octets ou 109
• 1 téraoctet = 1 000 000 000 000 octets ou 1012
• 1 pétaoctet = 1 000 000 000 000 000 octets ou 1015
• 1 exaoctet = 1 000 000 000 000 000 000 octets ou 1018

Synthèse
Ce chapitre vous a permis d'apprendre à :

• expliquer les principes et les finalités des clusters
• décrire les recommandations relatives aux éléments
matériels des clusters
• décrire l'architecture d'Oracle Clusterware
• décrire comment Grid Plug and Play affecte Clusterware

• décrire l'architecture d'ASM
• décrire les composants d'ASM


Installation de Grid Infrastructure

Objectifs

• effectuer les tâches préalables à l'installation de Grid
Infrastructure
• installer Grid Infrastructure
• vérifier l'installation
• configurer des groupes de disques ASM

(Automatic Storage Management)
• configurer des volumes ASM
• implémenter un système de fichiers ACFS
(ASM Cluster File System)
• monter des volumes ACFS


Module 1 : Planification de la préinstallation

Planification du stockage partagé pour Grid Infrastructure

• Il existe trois manières de stocker les fichiers de Grid Infrastructure :
– Système de fichiers clusterisé (CFS) pris en charge
– Système de fichiers réseau (NFS) certifié
– ASM (Automatic Storage Management)
Option de stockage Disque votant/ Logiciel Oracle
Registre OCR
ASM (Automatic Storage Management) Oui Non
ACSF (ASM Cluster File System) Non Oui
OCFS2 (Oracle Cluster File System) Oui Oui

GFS (Global File System) Red Hat Oui Oui
NFS (certifié uniquement) Oui Oui
Partitions de disque partagé (unités raw ou en Non Non
mode block)
• Les nouvelles installations ne sont pas autorisées sur les unités raw
ou en mode block.
• Lors de la mise à niveau d'une base de données RAC existante, vous
pouvez utiliser une partition existante d'une unité raw ou en mode bloc
et effectuer une mise à niveau non simultanée de l'installation.
Planification du stockage partagé pour Grid Infrastructure

Les fichiers de configuration d'Oracle Clusterware (disque votant et registre OCR (Oracle
Cluster Registry)) peuvent être placés dans un système de fichiers clusterisé ou un système de
fichiers réseau (NFS - Network File System) pris en charge. Depuis Oracle 11g Release 2, ces
fichiers peuvent maintenant être stockés avec l'option ASM. Conjointement avec ASM
Cluster File System, ASM fournit désormais une solution complète de stockage partagé pour
Oracle RAC. Les réseaux de stockage (SAN - Storage Area Network) d'autres fournisseurs
sont considérés comme des unités en mode block partagées dans le tableau de la diapositive.
Avec Oracle Database 11g Release 2, il n'est pas possible d'utiliser DBCA (Database
Configuration Assistant) ou Universal Installer pour stocker les fichiers d'Oracle Clusterware
ou Oracle Database directement sur des unités raw ou en mode block.
Si vous envisagez la mise à niveau d'une base RAC existante ou d'une base RAC avec des
instances ASM, vous pouvez utiliser une partition existante d'une unité raw ou en mode block
et effectuer une mise à niveau non simultanée de l'installation existante. Il n'est pas possible
d'effectuer une nouvelle installation à l'aide d'unités raw ou en mode block, et la prise en
charge de ces unités sera supprimée dans une version ultérieure.

Dimensionnement du stockage partagé
Dimensionnement minimum pour les fichiers de configuration

d'Oracle Clusterware avec une redondance externe, normale
ou élevée :
Redondance Nombre Fichiers Fichiers du Total
minimum de OCR disque
disques votant

Externe 1 280 Mo 280 Mo 560 Mo
Normale 3 560 Mo 840 Mo 1,4 Go
Elevée 5 840 Mo 1,4 Mo 2,3 Go
Dimensionnement du stockage partagé

Si vous choisissez de placer les fichiers de configuration dans un système de fichiers partagé,
Oracle recommande d'affecter ce système à une unité de stockage offrant une haute
disponibilité telle qu'un système RAID (4GFWPFCPV#TTC[QH+PGZRGPUKXG&KUMU), ou bien de
monter deux systèmes de fichiers et d'utiliser Oracle Clusterware pour assurer la redondance.
Lorsque vous utilisez la redondance externe, la configuration minimale requise est un fichier
OCR (Oracle Cluster Registry) et un disque votant de 280 Mo chacun. Si Oracle Clusterware
est utilisé pour implémenter la redondance normale, deux fichiers OCR et trois disques
votants de 280 Mo chacun doivent être créés, soit un total de 1,4 Go. Seulement deux fichiers
OCR peuvent être créés, mais Oracle Clusterware admet un maximum de 32 disques votants.
Configurez toujours un nombre impair de disques votants.
Le compte utilisateur avec lequel vous effectuez l'installation doit avoir le droit de créer des
fichiers dans le répertoire indiqué. L'emplacement des fichier OCR doit appartenir à
root:oinstall, tandis que celui du disque votant doit appartenir à crs:oinstall.
Tous les emplacements de fichiers doivent avoir le modèle de permissions 0640. Ces
conditions ne s'appliquent qu'à Oracle Clusterware. L'espace supplémentaire requis pour la
base de données et les applications doit être planifié.

Stocker le registre OCR dans ASM

• Le registre OCR (Oracle Cluster Registry) peut être stocké
dans ASM.
• Il est protégé par une mise en miroir basée sur les paramètres
de redondance du groupe de disques ASM qui le contient.

Stocker le registre OCR dans ASM

Oracle Clusterware utilise le registre OCR (Oracle Cluster Registry) pour stocker et gérer les
informations relatives aux composants contrôlés par Oracle Clusterware tels que les bases de
données Oracle RAC, les services, les processus d'écoute et les adresses IP virtuelles, ainsi
que les autres applications. Le registre OCR écrit les données de configuration dans une
structure arborescente de paires clé-valeur.
Pour faciliter la gestion du stockage dans Oracle Clusterware, le registre OCR est désormais
configuré par défaut pour utiliser ASM (Automatic Storage Management). Vous pouvez ainsi
gérer le stockage de la base de données et celui du clusterware à l'aide d'Oracle Enterprise
Manager.
Dans ASM, le registre OCR est stocké comme tout autre fichier de données, comme illustré
dans la diapositive. Lorsque vous effectuez une mise à niveau d'une version antérieure
d'Oracle Clusterware, vous pouvez migrer l'emplacement du registre OCR dans ASM.
Cela évite d'avoir à utiliser des gestionnaires de volumes clusterisés tiers et d'avoir à gérer des
partitions de disque distinctes pour le registre OCR dans les installations Oracle Clusterware.

Référentiel OCR (Oracle Clusterware Repository)
Noeud1 Noeud2 Noeud3
Cache OCR Cache OCR Cache OCR
Processus Processus Processus

CRSD CRSD CRSD

Processus Processus
client client
Stockage
Fichier
partagé Fichier
OCR OCR
principal secondaire
Référentiel OCR (Oracle Clusterware Repository)

Les informations de configuration du cluster sont tenues à jour dans le référentiel OCR. Ce
référentiel repose sur une architecture distribuée utilisant un cache partagé pour l'optimisation
des interrogations et des mises à jour atomiques. Chaque noeud du cluster gère une copie en
mémoire du fichier OCR, ainsi que le démon CRS (CRSD) qui accède à son cache OCR. Un
seul des processus CRSD effectue réellement des opérations de lecture et d'écriture dans le
fichier OCR de la zone de stockage partagé. Il est chargé d'actualiser son propre cache local,
mais aussi le cache OCR sur les autres noeuds du cluster. Pour les interrogations dans le
référentiel du cluster, les clients OCR communiquent directement avec le FÃOQP %45 local
du noeud qui les héberge. Lorsque les clients ont besoin de mettre à jour le référentiel OCR,
ils communiquent via le processus CRSD local avec le processus CRSD qui réalise les E/S
d'écriture dans le référentiel sur disque.
Les principaux clients du référentiel OCR sont Oracle Universal Installer, SRVCTL,
Enterprise Manager (EM), DBCA (Database Configuration Assistant), Database Upgrade
Assistant (DBUA), Network Configuration Assistant (NETCA) et ASM Configuration
Assistant (ASMCA). En outre, le référentiel OCR gère les informations relatives aux
dépendances et au statut pour les ressources applicatives définies dans Oracle Clusterware,
notamment les bases de données, les instances, les services et les applications des noeuds.

Référentiel OCR (Oracle Clusterware Repository) (suite)

Le processus d'installation d'Oracle Clusterware vous donne la possibilité d'assurer
automatiquement la mise en miroir du fichier OCR. Cette opération crée un deuxième fichier
OCR, appelé fichier OCR miroir, qui est une copie du fichier OCR d'origine, appelé fichier
OCR principal. Vous pouvez placer le fichier OCR miroir dans un système de fichiers
clusterisé ou sur un raw device partagé. Bien qu'il soit recommandé de mettre le fichier OCR
en miroir, vous n'êtes pas obligé de le faire pendant l'installation.
L'installation d'Oracle Grid Infrastructure définit à présent trois emplacements pour le
référentiel OCR et en admet jusqu'à cinq. Les nouvelles installations sur des raw devices ne
sont plus prises en charge.

Gérer les disques votants dans ASM
• Chaque noeud doit pouvoir accéder à la plupart des disques

votants. Sinon, il est retiré du cluster.
• Les disques votants peuvent être stockés sur un groupe de
disques ASM.
– Il ne s'agit pas de fichiers ASM standard.
– Oracle Clusterware connaît leur emplacement dans le cas où ASM
est indisponible.

• Le nombre de disques votants est déterminé par le paramètre de
redondance des groupes de disques ASM.
– 1 pour une redondance externe
– 3 pour une redondance normale
– 5 pour une redondance élevée
• Les différents disques votants doivent appartenir à des groupes
d'échec distincts.
• Les disques votants sont contrôlés à l'aide de l'utilitaire crsctl .
Gérer les disques votants dans ASM

Oracle Clusterware utilise des fichiers de disque votant, appelés disques votants, pour
déterminer les noeuds qui sont membres du cluster et pour assurer l'intégrité du cluster. Si
vous configurez des disques votants dans ASM, vous n'avez pas besoin d'effectuer cette
opération manuellement. Le nombre prédéfini de disques votants créé pour un groupe de
disques dépend de la redondance de celui-ci.
ASM gère les disques votants différemment des autres fichiers. Lorsque vous configurez
initialement Oracle Clusterware, vous indiquez le groupe de disques qui contiendra les
disques "votants". Chaque disque votant est placé dans un groupe d'échec ASM distinct. Vous
devez définir suffisamment de groupes d'échec pour prendre en charge le nombre de disques
votants correspondant à chaque niveau de redondance. Par exemple, vous devez disposer d'au
moins trois groupes d'échec pour stocker les disques votants d'un groupe de disques présentant
une redondance normale. Les disques votants n'apparaissent pas comme des fichiers standard
dans ASM. Oracle Clusterware enregistre précisément l'emplacement des informations de ces
disques. Ainsi, dans le cas où ASM devient indisponible pour une raison quelconque, les
services de synchronisation du cluster peuvent malgré tout accéder aux disques votants et
gérer le cluster.
L'utilisation d'un groupe de disques présentant une redondance normale ou élevée offre
l'avantage suivant. Si l'un des disques contenant un disque votant échoue, il est possible de
récupérer ce dernier dès lors qu'un autre disque est disponible dans le groupe. Les disques
votants sont contrôlés à l'aide de l'utilitaire crsctl. Par exemple, la commande suivante
migre les disques votants de leur position actuelle vers un groupe de disques ASM nommé
VOTE :
# crsctl replace votedisk +VOTE

Service CSS

CSS CSS CSS
Je vois 1, 2 et 3.
Les noeuds
Je vois Je vois
peuvent se voir.
1, 2 et 3. 1, 2 & 3.
Disque votant

"Split-brain"
Le noeud 3 ne peut plus
communiquer via CSS CSS CSS
(RMN)
une interconnexion
Je ne vois pas 3. Je vois 1&2. J'ai été
privée.
Noeud1 : Je vois 1&2. Je vois évincé !
Les autres ne voient plus Noeud2 : Je vois 1&2. 3. Je ferais
ses signaux d'activité => mieux de
et l'évincent en utilisant le Nous devons m'arrêter !
évincer 3 !
disque votant. Disque votant
Service CSS
Le service CSS détermine quels sont les noeuds disponibles dans le cluster et fournit aux
autres processus des services de verrouillage ainsi que des informations sur l'appartenance au
groupe. CSS détermine généralement la disponibilité des noeuds en fonction des
communications dans un réseau privé dédié. Un disque votant est utilisé comme mécanisme
de communication secondaire. Des messages concernant les signaux d'activité sont envoyés
via le réseau et le disque votant, comme illustré dans le premier graphique de la diapositive.
Le disque votant est une partition d'un disque raw partagé ou un fichier d'un système de
fichiers clusterisé accessible à tous les noeuds du cluster. Il sert essentiellement à gérer les
échecs de communication dans le réseau privé. Il est utilisé pour obtenir des informations sur
l'état des noeuds et pour définir les noeuds à placer hors ligne. En l'absence de disque votant,
les noeuds isolés risquent de ne pas pouvoir déterminer s'il s'est produit une défaillance réseau
ou si les autres noeuds ne sont plus disponibles. Le cluster peut alors se trouver dans un état
où plusieurs sous-clusters de noeuds ont un accès non synchronisé aux mêmes fichiers de base
de données. Le second graphique de la diapositive illustre ce qui se produit lorsque Noeud3
ne peut plus envoyer de signaux d'activité aux autres membres du cluster. Puisque les autres
ne peuvent plus voir ces signaux, ils décident d'évincer ce noeud à l'aide du disque votant.
Lorsque Noeud3 lit le message d'éviction, il se réinitialise généralement pour garantir
l'annulation des E/S en attente. Oracle Clusterware prend en charge jusqu'à 32 disques votants
redondants.
Remarque : Le disque votant est parfois appelé disque quorum.

Principaux fichiers journaux d'Oracle Clusterware
<Grid_Home>
log
<hostname>

agent admin crsd cssd evmd racg client ctssd
diskmon gipcd gnsd gnsd gpnpd mdnsd ohasd
alert<nodename>.log

Oracle Clusterware utilise une structure de répertoires de journalisation unifiée pour
regrouper les fichiers journaux des composants Oracle Clusterware. Cette structure consolidée
simplifie la collecte des informations de diagnostic et facilite l'extraction de données et
l'analyse des problèmes.
La diapositive ci-dessus présente les principaux répertoires utilisés par Oracle Clusterware
pour le stockage de ses fichiers journaux :
• Les journaux CRS figurent dans <Grid_Home>/log/<hostname>/crsd/. Le fichier
crsd.log est archivé chaque fois qu'il atteint 10 Mo (crsd.l01, crsd.l02, …).
• Les journaux CRS figurent dans Grid_HOME /log/<hostname>/cssd/. Le fichier
cssd.log est archivé chaque fois qu'il atteint 20 Mo (cssd.l01, cssd.l02, …).
• Les journaux EVM se trouvent dans <Grid_Home>/log/<hostname>/evmd.
• Les journaux SRVM (srvctl) et OCR (ocrdump, ocrconfig, ocrcheck) sont
stockés dans <Grid_Home>/log/<hostname>/client/ et
$ORACLE_HOME/log/<hostname>/client/.
• Les alertes importantes d'Oracle Clusterware sont consignées dans le fichier
alert<nodename>.log, dans le répertoire <Grid_Home>/log/<hostname>.

Installer ASMLib
Pour installer ASMLib manuellement :
• Déterminez le package oracleasm approprié.
# uname –rm
2.6.9-5.ELsmp i686
• Téléchargez et installez le package oracleasm à partir de :
http://www.oracle.com/technology/tech/linux/asmlib/index.html
• Téléchargez les packages oracleasmlib et oracleasm-

support correspondant à votre version de Linux.
• Téléchargez le package oracleasm correspondant à la version
du noyau.
• Connectez-vous en tant que root et installez les packages ASM.
# rpm -Uvh oracleasm-support-version.arch.rpm \
oracleasm-kernel-version.arch.rpm \
oracleasmlib-version.arch.rpm
Installer ASMLib
Installez Linux ASMLib RPMs pour simplifier l'administration du stockage. ASMLib fournit
les chemins persistants et les droits pour les périphériques de stockage utilisés par ASM, ce
qui élimine la nécessité d'actualiser les fichiers udev ou devlabel avec ces informations.
ASMLib 2.0 est fourni comme un ensemble de trois packages Linux :
• oracleasmlib-2.0 : Bibliothèques ASM
• oracleasm-support-2.0 : Utilitaires requis pour administrer ASMLib
• oracleasm : Module noyau pour la bibliothèque ASM
Chaque distribution Linux dispose de son propre ensemble de packages ASMLib 2.0 et, dans
chaque distribution, chaque version du noyau a un package oracleasm qui lui correspond.
Si vous êtes enregistré auprès de Oracle Unbreakable Linux Network, vous pouvez
télécharger et installer des packages d'ASMLib de votre système automatiquement. Pour
installer ASMLib à partir d'ULN :
1. Connectez-vous en tant qu'utilisateur root.
2. Exécutez la commande suivante :
# up2date -i oracleasm-support oracleasmlib oracleasm-’uname -r’
Pour installer ASMLib manuellement, effectuez les opérations indiquées dans la diapositive
ci-dessus.

Préparer ASMLib
• Configurez ASMLib.
# /usr/sbin/oracleasm configure -i
• Marquez les partitions de disque candidates pour ASM.

# /usr/sbin/oracleasm createdisk ASM_DISK_NAME \
candidate_disk

• Rendez des disques ASM disponibles sur tous les
autres noeuds du cluster.
# /usr/sbin/oracleasm scandisks
Préparer ASMLib
Configurer ASMLib
Connectez-vous en tant que root et entrez les commandes suivantes :
# oracleasm configure -i
Fournissez les informations demandées par le système. La commande oracleasm par
défaut se trouve dans le répertoire /etc/init.d. Si vous entrez la commande oracleasm
configure sans l'indicateur -i, vous obtenez la configuration en cours. Exécutez ensuite la
commande oracleasm init.
Marquer les partitions de disque candidates pour ASM
Pour qu'OUI reconnaisse les partitions de disque candidates pour ASM, vous devez vous
connecter en tant que root et marquer celles-ci. Pour marquer un disque pour une utilisation
par ASM, entrez la commande suivante, où ASM_DISK_NAME est le nom du groupe de
disques ASM, et candidate_disk, le nom de l'unité de disque que vous souhaitez affecter
à ce groupe :
oracleasm createdisk ASM_DISK_NAME candidate_disk
Par exemple : # oracleasm createdisk data1 /dev/sdf
Rendre des disques ASM disponibles sur tous les noeuds
Pour rendre un disque disponible pour les autres noeuds du cluster, entrez la commande
suivante en tant qu'utilisateur root sur chaque noeud : # /usr/sbin/oracleasm
scandisks
Cette commande identifie les disques partagés qui sont connectés aux noeuds marqués comme
disques ASM.

Quiz
Le registre OCR (Oracle Cluster Registry) peut être stocké

dans ASM.
1. Vrai
2. Faux

Réponse : 1
Cette affirmation est vraie.

Module 2 : Tâches préalables à l'installation

de Grid Infrastructure


Installation d'Oracle Grid Infrastructure 11g
1. Vérifiez la configuration système requise.

2. Vérifiez la configuration réseau requise.
3. Installez les packages requis pour le système
d'exploitation.
4. Définissez les paramètres du noyau.
5. Créez des groupes et des utilisateurs.

6. Créez les répertoires nécessaires.
7. Configurez les limites du shell relatives
au propriétaire de l'installation.
8. Installez Oracle Clusterware.
Installation d'Oracle Grid Infrastructure 11g

Pour installer correctement Oracle Grid Infrastructure, il est important que vous compreniez
les tâches à réaliser et l'ordre dans lequel elles doivent être effectuées. Au préalable, vérifiez
que chaque noeud qui fera partie du cluster possède la configuration matérielle et logicielle
requise présentée dans ce chapitre. Vous devez procéder pas à pas pour vérifier le matériel et
les logiciels, ainsi que pour effectuer les procédures de préinstallation propres à la plateforme.
Vous devez installer les patches du système d'exploitation requis par le logiciel de cluster et
vérifier que les paramètres du noyau sont adaptés à vos besoins.
Oracle Grid Infrastructure doit être installé à l'aide de l'utilitaire graphique OUI. Les
installations basées sur des outils en mode caractère ne sont pas possibles. Toutefois, OUI
peut être exécuté automatiquement en mode batch en utilisant des fichiers de réponses pour
fournir les valeurs dont l'installation a besoin. Avant de commencer cette opération, vérifiez
que les composants matériels de votre cluster fonctionnent normalement. Sinon, l'installation
risque d'être interrompue ou de ne pas fonctionner.
Si vous envisagez d'utiliser Enterprise Manager Grid Control pour gérer les déploiements de
cluster, vous devez installer l'agent EM (Enterprise Manager) sur chaque noeud du cluster.
Remarque : Ce chapitre fournit des informations sur l'installation, mais il ne doit pas être
utilisé à la place du manuel Installation pour votre plateforme.

Vérifier la configuration système
• Au moins 1,5 Go de mémoire physique est nécessaire.

# grep MemTotal /proc/meminfo
MemTotal: 2097320 kB
• Au moins 1,5 Go d'espace de swap est nécessaire.

# grep SwapTotal /proc/meminfo
SwapTotal: 4194296 kB

• Le répertoire local /tmp doit comporter au moins 1 Go d'espace
libre.
# df -h /tmp
Filesystem Size Used Avail Use% Mounted on
/dev/sda6 9.7G 2.3G 7.0G 25% /
• Au moins 4,5 Go d'espace de stockage local sont nécessaires
sur chaque noeud pour les logiciels.
Vérifier la configuration système

Le système doit présenter la configuration matérielle minimale suivante :
• La quantité minimale de mémoire RAM requise est 1,5 Go pour Grid Infrastructure pour
un cluster, ou 2,5 Go pour Grid Infrastructure pour un cluster et Oracle RAC. Pour
déterminer la quantité de mémoire physique, entrez la commande suivante :
# grep MemTotal /proc/meminfo
• La quantité minimale d'espace de swap requise est de 1,5 Go. Oracle recommande de
définir un espace de swap égal à 1,5 fois la quantité de RAM requise pour les systèmes
dotés d'au plus 2 Go de RAM. Pour les systèmes comprenant 2 à 16 Go de RAM, utilisez
un espace de swap de la même taille que la RAM. Pour les systèmes comportant plus de
16 Go de RAM, utilisez 16 Go d'espace de swap. Pour déterminer la taille de l'espace de
swap configuré, tapez la commande suivante :
grep SwapTotal /proc/meminfo
• Au moins 1 Go d'espace disque doit être disponible dans le répertoire /tmp (les variables
TMP et TMPDIR peuvent forcer l'utilisation d'un autre emplacement). Pour déterminer
l'espace disque disponible dans le répertoire /tmp, entrez la commande :
df -h /tmp.
• Au moins 1,4 Go d'espace disque est requis pour les fichiers de configuration d'Oracle
Clusterware, avec une redondance normale utilisant deux fichiers OCR et trois disques
votants. Il doit s'agir de l'espace de stockage partagé accessible par chaque noeud.
• Au moins 4,5 Go sont requis pour le répertoire d'origine du logiciel Grid Infrastructure.

Vérifier la configuration réseau
• Chaque noeud doit comporter au moins deux cartes d'interface réseau.

• Les noms d'interface doivent être les mêmes sur tous les noeuds.
• Une carte réseau publique doit prendre en charge le protocole TCP/IP,
et une carte réseau privée, le protocole UDP.
• L'adresse IP publique doit être stockée dans le serveur de noms de
domaine (DNS) ou dans le fichier /etc/hosts.
• L'adresse du cluster GNS doit être stockée dans le serveur de noms de
domaine.

# cat /etc/hosts
##### Public Interfaces – eth0 (odd numbers)####
xxx.xxx.100.11 host01.example.com host01
xxx.xxx.100.13 host02.example.com host02
• Eviter les défaillances réseau publiques lors de l'utilisation de
périphériques NAS ou de montages NFS en démarrant le démon Name
Service Cache.
# /sbin/service nscd start
Vérifier la configuration réseau

Voici une liste de conditions pour la configuration réseau :
• Chaque noeud doit comporter au moins deux cartes d'interface réseau (NIC - Network
Interface Card) : une pour le réseau public et une pour le réseau privé.
• Les noms d'interface doivent être les mêmes sur tous les noeuds du cluster.
• Sur le réseau public, chaque carte réseau doit prendre en charge le protocole TCP/IP. Sur
le réseau privé, chaque carte réseau doit prendre en charge le protocole UDP (User
Datagram Protocol). Les plateformes Windows utilisent uniquement TCP.
• Si des serveurs de noms de domaine (DNS) sont utilisés, les adresses IP publiques
doivent être enregistrées.
• Si les horodatages diffèrent de manière significative entre les noeuds, des évictions et des
réinitialisations de noeud peuvent se produire. Le protocole NTP (Network Time
Protocol) peut être utilisé pour synchroniser les horodatages entre les noeuds du cluster.
Si NTP n'est pas configuré, Oracle Clusterware installe le démon csstd.
• Pour éviter les défaillances du réseau public lors de l'utilisation d'unités NAS (Network
Attached Storage) ou de montages NFS (Network File System), entrez la commande
suivante en tant qu'utilisateur root pour activer le démon Name Service Cache (nscd) :
# /sbin/service nscd start
• Assurez-vous que chaque noeud est correctement identifié à l'aide des utilitaires
hostname et ifconfig.

Vérifier la configuration réseau (suite)

Vous pouvez configurer les adresses IP avec une des options suivantes :
• Le service GNS (Oracle Grid Naming Service) en utilisant une adresse statique définie
lors de l'installation, avec des adresses affectées dynamiquement pour toutes les autres
adresses IP, obtenue à partir du serveur DHCP
&[PCOKE*QUV%QPHKIWTCVKQP2TQVQEQN
de votre entreprise et résolue via un serveur de noms de domaine multicast configuré
dans le cluster.
• Des adresses statiques que les administrateurs réseau affectent à un serveur de noms de
domaine (DNS) sur chaque noeud.

Configuration logicielle (noyau)
Configuration requise pour le noyau du système d'exploitation

Linux x86 (32 bits et 64 bits)
Distribution Linux Configuration requise

Asianux Asianux 2, noyau version 2.6.9 ou ultérieure
Asianux Server 3, noyau version 2.6.18 ou ultérieure

Oracle Enterprise Linux OEL 4 Update 7, noyau version 2.6.9 ou ultérieure
(OEL) OEL 5 Update 2, noyau version 2.6.18 ou ultérieure
Red Hat Enterprise Linux RHEL 4 Update 7, noyau version 2.6.9 ou ultérieure
(RHEL) RHEL 5 Update 2, noyau version 2.6.18 ou ultérieure
SUSE Enterprise Linux SUSE 10, noyau version 2.6.16.21 ou ultérieure
SUSE 11, noyau version 2.6.27.19 ou ultérieure
Configuration logicielle (noyau)

Pour les installations d'Oracle Grid Infrastructure, vérifiez que vous disposez des versions et
des packages du noyau indiqués dans le tableau de la diapositive. Si vous prévoyez d'installer
Oracle Database ou Oracle RAC en plus d'Oracle Grid Infrastructure, reportez-vous au
manuel Oracle Grid Infrastructure Installation Guide, 11g Release 2 (11.2) for Linux pour
déterminer si vous devez installer des packages supplémentaires pour les fonctionnalités
que vous prévoyez d'utiliser.

Configuration logicielle : Packages
Configuration requise pour Linux x86 Oracle 32-bit Grid

Infrastructure et Oracle RAC RPM pour Asianux Server 3, OEL
5 et RHEL 5
binutils-2.17.50.0.6 libaio-0.3.106
compat-libstdc++-33-3.2.3 libaio-devel-0.3.106
elfutils-libelf-0.125 libgcc-4.1.2

elfutils-libelf-devel-0.125 libgomp-4.1.2
glibc-2.5-24 libstdc++-4.1.2
glibc-common-2.5 libstdc++-devel-4.1.2
glibc-devel-2.5 make-3.81
glibc-header-2.5 sysstat-7.0.2
gcc-4.1.2 unixODBC-2.2.11
gcc-c++-4.1.2 unixODBC-devel-2.2.11
Configuration logicielle : Packages

Si vous prévoyez d'installer une instance Oracle Database ou une base de données de cluster
Oracle en plus d'Oracle Grid Infrastructure, reportez-vous à la liste de la diapositive pour
déterminer si vous devez installer des packages supplémentaires pour les fonctionnalités que
vous envisagez d'utiliser. Si vous exécutez Asianux Server 3, OEL5 ou RHEL5, reportez-vous
à la liste de la diapositive pour connaître la configuration requise pour RPM.
Pour déterminer si les packages requis sont installés, sélectionnez une commande similaire
à ce qui suit :
# rpm –qa | grep package_name
Il est préférable d'utiliser la commande grep pour rechercher le nom du package sans les
informations de version car des versions plus récentes peuvent être installées. Installez les
packages manquants et leurs dépendances avec la syntaxe suivante :
# rpm –ivh package_name

Module Oracle Validated Configuration RPM
Lorsque le module Oracle Validated Configuration RPM est

installé, il effectue les opérations suivantes :
• Il installe tous les packages supplémentaires requis pour
installer Oracle Grid Infrastructure et Oracle Database.
• Il crée un utilisateur oracle et les groupes oraInventory
(oinstall) et OSDBA (dba).

• Il définit les paramètres de sysctl.conf,
les paramètres de
démarrage, les limites utilisateur
et les paramètres des pilotes
en fonction des recommandations
fournies par le programme
Oracle Validated Configurations.
Module Oracle Validated Configuration RPM

Si la distribution Linux est Oracle Enterprise Linux ou Red Hat Enterprise Linux, vous
pouvez effectuer la plupart des tâches de configuration préalables à l'aide du module Oracle
Validated Configuration RPM, disponible sur le site Unbreakable Linux Network. Lorsqu'il
est installé, ce module effectue les opérations suivantes :
• Il installe automatiquement tous les packages supplémentaires requis pour installer
Oracle Grid Infrastructure et Oracle Database.
• Il crée un utilisateur oracle et les groupes oraInventory (oinstall) et OSDBA
(dba).
• Il définit et vérifie les paramètres de sysctl.conf, les paramètres de démarrage, les
limites utilisateur et les paramètres des pilotes en fonction des recommandations du
programme Oracle Validated Configurations.
Si vous utilisez Oracle Enterprise Linux version 4.7 ou ultérieure ou Oracle Enterprise Linux
version 5.2 ou ultérieure, le module Oracle Validated Configuration RPM est inclus dans le
support d'installation. Utilisez la procédure suivante pour vous abonner aux canaux Oracle
Unbreakable Linux et pour ajouter le canal Oracle Software for Enterprise Linux qui distribue
ce module :
1. Effectuez une installation par défaut de type Oracle Enterprise Linux Workstation ou Red
Hat Enterprise Linux.
2. Enregistrez votre serveur avec Unbreakable Linux Network (ULN). Par défaut, vous êtes
enregistré au canal Enterprise Linux (latest) correspondant à votre matériel et à votre

Module Oracle Validated Configuration RPM (suite)

3. Connectez-vous à ULN à l'aide de l'URL suivante : https://linux.oracle.com.
4. Cliquez sur l'onglet Systems et, dans la liste System Profiles, sélectionnez un serveur
enregistré. La fenêtre System Details s'ouvre et affiche les abonnements pour le serveur.
5. Dans la liste Available Channels, sélectionnez le canal Oracle Software for Enterprise
Linux correspondant à votre installation de Linux—par exemple, "Oracle Software for
Enterprise Linux 4 (x86_64)".
6. Cliquez sur Subscribe.
7. Dans une session de terminal, connectez-vous en tant que root et entrez la commande
suivante :
# up2date --nox --show-channels

Vous devez voir que vous êtes abonné au canal Oracle Software for Enterprise Linux.
Par exemple :
el4_i386_latest
el4_i386_oracle
8. Ouvrez une session de terminal en tant que root et installez le module Oracle
Validated Configuration RPM avec up2date, à l'aide de la commande suivante :
# up2date --install oracle-validated
9. Répétez les étapes 1 à 8 sur tous les autres serveurs du cluster.

Créer des utilisateurs et des groupes
• Créez un groupe d'inventaire des logiciels Oracle sur chaque

noeud.
• L'ID de groupe doit être cohérent sur chaque noeud.
# groupadd -g 501 oinstall
• Définissez le propriétaire des logiciels Oracle sur chaque noeud.

• L'ID utilisateur doit être cohérent sur chaque noeud et le groupe

d'inventaire doit être le groupe principal.
• La plupart des produits Oracle (Grid Infrastructure, Oracle
Database, Enterprise Manager, etc.) appartiennent généralement
au même utilisateur, généralement appelé oracle, mais chaque
produit peut appartenir à un utilisateur différent.
# useradd –u 501 –g oinstall oracle
ou
# useradd –u 502 –g oinstall grid
Créer des utilisateurs et des groupes

Il est nécessaire de créer un groupe du système d'exploitation associé à Oracle Central
Inventory (oraInventory). oraInventory contient un registre des répertoires Oracle
Home de tous les produits Oracle installés sur le serveur. Il est conçu pour être partagé par
plusieurs produits. Il contient également les fichiers journaux et de trace des programmes
d'installation. Le nom suggéré pour le groupe du système d'exploitation est oinstall.
Dans une installation de cluster, il est très important que l'ID de groupe soit le même sur tous
les noeuds du cluster.
Il faut également définir un utilisateur du système d'exploitation propriétaire de l'installation
d'Oracle Clusterware. Traditionnellement, tous les produits Oracle installés sur le même
ordinateur tel que les clusterwares, les bases de données, les utilitaires de gestion de disques et
les outils de gestion d'entreprise appartiennent à l'utilisateur nommé oracle. Chaque produit
peut être associé à un compte différent du système d'exploitation. Cela peut être nécessaire si
des responsabilités distinctes sont utilisées pour gérer les différents composants. Il est très
important que l'ID utilisateur soit le même sur tous les noeuds du cluster.
Il est nécessaire que le propriétaire du logiciel Oracle Clusterware et le propriétaire du
logiciel Oracle Database aient le même groupe principal que le groupe Oracle Inventory.
Remarque : Si cette installation d'Oracle Clusterware inclut une base de données et d'autres
produits Oracle, envisagez de créer les groupes dba et oper.

Créer des groupes et des utilisateurs :

Exemple
1 Créer des groupes :
# /usr/sbin/groupadd -g 1000 oinstall
# /usr/sbin/groupadd -g 1100 asmadmin
# /usr/sbin/groupadd -g 1200 dba
# /usr/sbin/groupadd -g 1201 oper
# /usr/sbin/groupadd -g 1300 asmdba
# /usr/sbin/groupadd -g 1301 asmoper
2 Créer des utilisateurs
# /usr/sbin/useradd -u 1100 -g oinstall -G asmdba,dba, \

asmoper oracle
Si un propriétaire distinct est nécessaire pour Grid Infrastructure :
# /usr/sbin/useradd -u 1101 -g oinstall -G asmdba,dba, \
asmoper grid
3 Créer des répertoires
# mkdir -p /u01/app/grid /u01/app/oracle
# chown -R grid:oinstall /u01/app
# chown oracle:oinstall /u01/app/oracle
# chmod 775 /u01/app
Créer des groupes et des utilisateurs : Exemple

L'exemple ci-après crée le groupe Oracle Inventory (oinstall), OSDBA, OSASM et
ODBA pour les groupes ASM où ils constituent le même groupe (dba). Par ailleurs, il définit
les propriétaires des logiciels Grid Infrastructure (grid) et Oracle Database (oracle) en les
associant aux groupes appropriés. L'exemple de la diapositive montre également comment
configurer un chemin de base Oracle compatible avec NCUVTWEVWTG1(#
1RVKOCN(NGZKDNG
#TEJKVGEVWTG, avec les droits appropriés :
1. Connectez-vous au noeud du cluster en tant que root. Entrez des commandes similaires
à celles de la diapositive pour créer les groupes oinstall, asmadmin et asmdba et,
si nécessaire, les groupes asmoper, dba et oper. Utilisez l'option -g pour définir l'ID
de groupe correct (GID) pour chaque groupe.
2. Pour créer l'utilisateur de Grid Infrastructure, entrez une commande similaire à la
suivante (pour l'exemple considéré) :
# /usr/sbin/useradd -u 1100 -g oinstall -G asmdba,dba,asmoper
oracle
Si un autre propriétaire distinct est nécessaire pour Grid Infrastructure :
# /usr/sbin/useradd -u 1101 -g oinstall -G asmdba,dba,asmoper grid
3. Créez les répertoires de base pour les logiciel Oracle Grid Infrastructure et Oracle
Database.
# mkdir -p /u01/app/grid /u01/app/oracle
# chown -R grid:oinstall /u01/app
# chown oracle:oinstall /u01/app/oracle
# chmod 775 /u01/app

Paramètres du shell pour l'utilisateur

• Ajoutez les lignes suivantes au fichier
/etc/security/limits.conf sur chaque noeud :
grid soft nproc 2047
grid hard nproc 16384
grid soft nofile 1024
grid hard nofile 65536
oracle soft nproc 2047

oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536
• Ajoutez la commande suivante au fichier

/etc/pam.d/login sur chaque noeud :
session required pam_limits.so
Paramètres du shell pour l'utilisateur de Grid Infrastructure

Les modules d'authentification PAM (Pluggable Authentication Modules) pour Linux offrent
une grande souplesse pour l'authentification des utilisateurs. Ils fournissent une série de
modules de bibliothèque qui peuvent être utilisés par de nombreux programmes tels que
login et su. L'avantage est que de nouveaux schémas d'authentification peuvent être
connectés aux modules PAM et être mis à disposition. Vous devez alors réécrire les
programmes qui dépendent de l'authentification. Les modules PAM permettent la gestion
des comptes, de l'authentification, des mots de passe et des sessions. Le fichier
/etc/security/limits.conf est le fichier de configuration du module pam_limits,
l'un des différents modules PAM.
Pour le propriétaire d'Oracle Grid Infrastructure, il est recommandé d'adopter des valeurs
supérieures aux valeurs par défaut pour les limites fixes sur le nombre maximum de processus
admis (nproc) et le nombre maximum de fichiers ouverts (nofile). Ces limites sont définies
par le superutilisateur et appliquées par le noyau. Pour les comptes utilisateur, il n'est pas
possible de définir des limites supérieures aux limites fixes. Les limites ajustables sont
considérées comme les valeurs de démarrage par défaut pour une utilisation normale, mais les
utilisateurs peuvent les modifier.
Remarque : Ces conditions s'appliquent également au compte utilisé pour le logiciel de base
de données, généralement nommé oracle. Vous pouvez ajouter cette valeur au fichier
/etc/security/limits.conf en plus du propriétaire du compte d'Oracle Grid
Infrastructure.

Paramètres du shell pour l'utilisateur

Pour le shell Bourne, Bash ou Korn, ajoutez l'instruction

suivante au fichier /etc/profile sur chaque noeud.
if [ $USER = "oracle" ] || [ $USER = "grid" ]; then
if [ $SHELL = "/bin/ksh" ]; then
ulimit -u 16384
ulimit -n 65536

else
ulimit -u 16384 -n 65536
fi
umask 022
fi
Paramètres du shell pour l'utilisateur de Grid Infrastructure (suite)

La commande Linux ulimit permet de contrôler les ressources système qui sont à la
disposition du shell et des processus démarrés par le shell. Pour vérifier les paramètres en
cours, exécutez la commande suivante : ulimit –a
Le nombre maximal de processus disponibles pour un utilisateur est défini par l'option –u,
et le nombre maximum de descripteurs de fichier ouvert, par l'option -–n. La syntaxe exacte
à utiliser dépend du shell dans lequel s'exécute le compte utilisateur. Oracle recommande
d'utiliser des valeurs supérieures aux valeurs par défaut.
Remarque : Ces conditions s'appliquent également au compte utilisé pour le logiciel de base
de données, généralement nommé oracle. Vous pouvez ajouter cette valeur
/etc/profile en plus du propriétaire du compte d'Oracle Clusterware.

Quiz
Parmi les affirmations suivantes, laquelle n'est pas vraie ?

1. Au moins 1,5 Go de mémoire physique est nécessaire.
2. Au moins 1,5 Go d'espace de swap est nécessaire.
3. Le répertoire local /tmp doit comporter au moins 400 Mo
d'espace libre.
4. Au moins 4,5 Go d'espace de stockage local sont

nécessaires sur chaque noeud pour les logiciels.
Réponse : 3
L'affirmation 4 est fausse. Le répertoire local /tmp doit comporter au moins 1 Go d'espace
libre.


Module 3 : Installation de Grid Infrastructure

Installer Grid Infrastructure

./runInstaller

Installer Grid Infrastructure

Lancez OUI en exécutant la commande runInstaller en tant que propriétaire grid à
partir du CD d'installation CD ou du répertoire temporaire des logiciels. Cliquez sur "Install
and Configure Grid Infrastructure For a Cluster" et cliquez sur Next.
Choisir un type d'installation
OUI a été amélioré pour prendre en charge les nouvelles fonctionnalités Oracle RAC (Oracle
Real Application Clusters) fournies dans Oracle Database 11g Release 2. Sa présentation est
différente de celle des versions précédentes. L'une des premières améliorations concerne la
page Installation Type. Elle permet de sélectionner une installation standard (Typical
Installation) avec une valeur IP fixe de base. Vous pouvez également choisir une installation
avancée (Advanced Installation) intégrant la fonctionnalité )TKF2NWICPF2NC[
)2P2 et
offrant une plus grande flexibilité pour la configuration des éléments suivants :
• Stockage partagé pour le référentiel OCR et les fichiers votants
• Options réseau telles que les services de noms de grid (GNS)
• Isolement des défaillances à l'aide de l'interface IPMI (Intelligent Platform Management
Interface)
Etant donné que l'option d'installation standard effectue une configuration de base, le
processus d'interrogation est réduit.

Fonctionnalité Grid Plug and Play

Fonctionnalité Grid Plug and Play

Après avoir choisi les langues des produits dans la page Select Product Languages, vous
accédez à la page Grid Plug and Play Information. Vous devez indiquer un nom de cluster.
Ce nom doit être unique dans le sous-réseau. Si Grid Control est utilisé, le nom du cluster doit
être unique au sein du domaine de gestion de Grid Control.
Le PQO5%#0
5KPING%NKGPV#EEGUU0COGest l'adresse utilisée par les clients qui se
connectent au cluster. Il s'agit d'un nom de domaine enregistré auprès de trois adresses IP,
dans le serveur DNS (Domain Name Server) ou le service GNS (Grid Naming Service). Les
adresses SCAN doivent être sur le même sous-réseau que les adresses IP virtuelles des noeuds
du cluster. Le nom de domaine SCAN doivent être uniques au sein de votre réseau
d'entreprise. Le port SCAN doit par défaut avoir la valeur 1522, sauf s'il existe un conflit au
niveau de ce port.
Si vous indiquez un sous-domaine GNS, le nom SCAN prend par défaut la valeur
clustername-scan.GNSdomain. Par exemple, si vous lancez l'installation d'Oracle Grid
Infrastructure à partir du serveur racnode01, que le nom du cluster est cluster01
et que le domaine GNS est cluster01.example.com, le nom SCAN est cluster01-
scan.cluster01.example.com.
Si vous n'utilisez pas GNS, le nom SCAN doit être défini dans le DNS pour permettre la
résolution des trois adresses qui lui sont associées. Affectez trois adresses au nom SCAN.
Pour finir, vous devez indiquer l'adresse de votre service GNS. Cette adresse doit pouvoir être
résolue par le DNS.

Informations sur les noeuds du cluster

Informations sur les noeuds du cluster

La page Cluster Node Information définit les noms d'hôte publics et les noms d'hôte virtuels.
Par le passé, les noms d'hôte et les noms VIP étaient définis dans le DNS ou localement dans
un fichier. Si vous souhaitez configurer votre cluster de cette manière, vérifiez que la case à
cocher Configure GNS n'est pas sélectionnée dans l'écran précédent. Cliquez sur le bouton
Add et complétez les champs Public Node Name et Virtual Host Name pour chaque noeud du
cluster.
Si GNS a été sélectionné dans l'écran précédent et que le protocole DHCP est configuré dans
le sous-domaine dans lequel le cluster réside, la configuration est simplifiée. Cliquez sur le
bouton Add, puis ajoutez le nom d'hôte comme le montre le graphique de la diapositive. Il
n'est pas nécessaire d'indiquer un nom F CFTGUUG +2XKTVWGNNG RQWTEJCSWG PQGWF car ces noms
sont automatiquement configurés par Clusterware à l'aide de DHCP.
Il est possible de configurer SSH (5GEWTG5JGNN) pour des noeuds spécifiques en cliquant sur le
bouton SSH Connectivity. Vous devez fournir aux propriétaires du logiciel un mot de passe
commun à tous les noeuds. Une fois la connectivité SSH établie, cliquez sur Next pour
continuer.

Définir l'utilisation de l'interface réseau

Définir l'utilisation de l'interface réseau

Dans la page Specify Network Interface Usage, vous pouvez sélectionner les interfaces réseau
à utiliser sur les noeuds du cluster pour la communication entre les noeuds. Vous devez
choisir une interface pour le réseau public et une pour le réseau privé. Vérifiez que la bande
passante des interfaces réseau choisies est suffisante pour la prise en charge du trafic réseau
lié au cluster et à RAC. Il est fortement recommandé d'utiliser une interface Gigabit Ethernet
pour l'interconnexion privée entre noeuds. Sélectionnez le type d'utilisation approprié pour
chaque interface réseau. Dans l'exemple de la diapositive, il y a trois interfaces : eth0, eth1 et
eth2. L'interface eth0 est l'interface réseau principale de l'hôte et doit avoir le type Public.
L'interface eth2 est configurée pour une interconnexion privée entre noeuds et doit avoir le
type Private. L'interface eth2 est dédiée au réseau de stockage, qui prend en charge le
stockage partagé du cluster. Elle doit être associée au type Do Not Use. Une fois que vous
avez terminé, cliquez sur le bouton Next pour continuer.

Informations sur les options de stockage

Informations sur les options de stockage

Dans la page Storage Option Information, vous pouvez indiquer la méthode à privilégier pour
le stockage des fichiers d'Oracle Clusterware. La première option est ASM (Automatic
Storage Management). La possibilité d'utiliser des groupes de disques ASM pour le référentiel
OCR et le disque votant d'Oracle Clusterware est une nouvelle fonctionnalité d'Oracle
Database 11g Release 2 Grid Infrastructure. Si vous sélectionnez cette option et qu'ASM n'a
pas encore été configuré, OUI lance l'assistant de configuration ASM pour configurer ASM et
un groupe de disques afin de prendre en charge la configuration illustrée dans la diapositive.
Lorsque vous utilisez ASM, la redondance pour le référentiel OCR et les disques votants est
liée à la redondance que vous définissez pour le groupe de disques et au nombre de disques
placés dans le groupe. Le disque votant est affecté à trois disques du groupe dans le cas d'une
redondance normale et à cinq disques dans le cas d'une redondance élevée. Par défaut, chaque
disque du groupe est placé dans un groupe d'échec constitué de lui-même et les disques
votants sont placés dans différents groupes d'échec. Le référentiel OCR est stocké de la même
manière que les fichiers de base de données.
L'autre option de stockage disponible est le stockage dans le système de fichiers partagé. Les
systèmes de fichiers appropriés incluent les systèmes de fichiers clusterisés pris en charge, par
exemple OCFS2 ou NFS (Network File System). Si vous sélectionnez Shared File System
dans la page Storage Option Information, vous êtes invité à indiquer le système de fichiers
clusterisé ou le répertoire NFS à utiliser pour le référentiel OCR et les disques votants,
comme illustré dans la diapositive.
La page qui s'affiche ensuite est la page Specify ASM Password. La nouvelle instance ASM
nécessite son propre utilisateur SYS avec les privilèges SYSASM. Indiquez un mot de passe
sécurisé et cliquez sur Next pour continuer.

Isolement des pannes avec IPMI

Isolement des pannes avec IPMI

L'interface IPMI (Intelligent Platform Management Interface) fournit un ensemble d'interfaces
communes au matériel et au microprogramme que les administrateurs peuvent utiliser pour
surveiller l'état du système et assurer la gestion. Avec Oracle Database 11g Release 2, Oracle
Clusterware peut intégrer IPMI permettre l'isolement des pannes et assurer l'intégrité du
cluster.
Vous devez configurer le matériel et les logiciels suivants pour permettre aux noeuds du
cluster d'être gérés avec IPMI :
• Chaque noeud membre du cluster requiert un microprogramme BMC (Baseboard
Management Controller) compatible avec la version 1.5 d'IPMI, prenant en charge IPMI
sur les réseaux locaux (LAN) et configuré pour le contrôle à distance.
• Chaque noeud membre de cluster requiert un pilote IPMI installé sur chaque noeud.
• Le cluster nécessite un réseau de gestion pour IPMI. Il peut s'agir d'un réseau partagé,
mais Oracle recommande de configurer un réseau dédié.
• Le port Ethernet de chaque noeud du cluster utilisé par BMC doit être connecté au réseau
de gestion d'IPMI.
Si vous prévoyez d'utiliser IPMI, vous devez fournir un nom et un mot de passe pour le
compte d'administration lorsque vous y êtes invité.
Remarque : Pour qu'Oracle Clusterware communique avec BMC, le pilote IPMI doit être
installé de manière permanente sur chaque noeud, de sorte qu'il soit disponible au
redémarrage du système. Le pilote IPMI est disponible sur Asianux Linux, Oracle Enterprise
Linux, Red Hat Enterprise Linux, et les distributions de SUSE Enterprise Linux prises en
charge avec cette version.

Groupes dotés de privilèges
du système d'exploitation

Groupes dotés de privilèges du système d'exploitation

Dans la page Privileged Operating System Groups, vous devez définir les groupes auxquels le
propriétaire d'oracle Grid Infrastructure doit appartenir pour permettre l'authentification par le
système d'exploitation dans ASM. L'exemple de la diapositive indique asmdba pour le
groupe OSDBA (ASM Database Administrator), asmoper pour le groupe OSOPER
(ASM Instance Administration Operator) et asmadmin pour le groupe OSASM
(ASM Instance Administrator). Cliquez sur Next pour continuer.

Emplacements d'installation et d'inventaire

Emplacements d'installation et d'inventaire

Ensuite, OUI affiche la page Specify Installation Location. Entrez l'emplacement
d'installation de base du logiciel Oracle. Un emplacement Oracle Base distinct doit être créé
pour chaque utilisateur du système d'exploitation possédant une installation de logiciel
Oracle. Dans l'exemple de la diapositive, cet emplacement est /u01/app/grid.
Dans le champ Software Location, entrez le répertoire dans lequel vous souhaitez installer
Oracle Grid Infrastructure. Dans l'exemple, l'utilisateur du système d'exploitation grid
possédera cette installation. Le champ Software Location doit contenir
/u01/app/11.2.0/grid. Lorsque vous avez indiqué les valeurs appropriées pour Oracle
Base et Software Location, cliquez sur Next pour continuer.
Dans la page Create Inventory, entrez un emplacement sous Oracle Base pour le stockage de
l'inventaire Oracle. Cliquez sur Next pour continuer.

Vérification des prérequis

Vérification des prérequis

Depuis Oracle Database 11g Release 2, OUI assure un guidage plus important pour assurer un
déploiement conforme aux recommandations et éviter les problèmes de configuration. En
outre, les assistants valident les configurations. Ils fournissent des scripts de correction des
problèmes que vous pouvez choisir d'utiliser ou de rejeter. Lorsque vous cliquez sur le bouton
Fix and Check Again, vous accédez à une fenêtre qui vous invite à exécuter un script de
correction. Celui-ci doit être lancé sur tous les noeuds pour le compte de l'utilisateur root.
L'exemple de la diapositive montre la réponse d'Oracle Universal Installer concernant le
paramètre WMEM_MAX du noyau, qui a une valeur trop faible pour une installation réussie.
L'installeur peut déterminer si l'erreur peut être corrigée et permet à l'utilisateur qui effectue
l'installation de le laisser faire le nécessaire. Lorsque l'utilisateur clique sur le bouton Fix &
Check Again, un script est généré pour les noeuds affectés par l'erreur. Après l'exécution du
script sur tous les noeuds en tant que root, le paramètre de noyau est ajusté, ce qui permet à
l'installation de continuer. Une fois les vérifications de prérequis terminées avec succès,
cliquez sur Next pour continuer. Il est possible qu'un problème d'installation ne puisse pas être
corrigé avec un script généré. Dans ce cas, la valeur No est indiquée dans la colonne Fixable.
Lorsque la page Summary apparaît, vérifiez les informations d'installation affichées. Si les
informations sont correctes, cliquez sur le bouton Finish pour lancer l'installation du logiciel.

Terminer l'installation

Terminer l'installation
Une fois Grid Infrastructure copié sur les noeuds distants, vous êtes invité à exécuter les
scripts root sur tous les noeuds concernés. Si c'est le premier logiciel Oracle lancé par
l'utilisateur du système d'exploitation, l'installeur vous invite à exécuter les scripts
orainstRoot.sh sur tous les noeuds. Ensuite, vous devez exécuter le script root.sh sur
tous les noeuds. Une fois le script root.sh exécuté sur le dernier noeud, cliquez sur Finish
pour quitter l'installeur.

Vérifier l'installation d'Oracle Grid Infrastructure

[root@racnode01 ~]# /u01/app/11.2.0/grid/bin/crsctl stat res -t
--------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATA.dg
ONLINE ONLINE racnode01
ora.LISTENER.lsnr
ora.asm
ONLINE ONLINE racnode01 Started
ONLINE ONLINE racnode02 Started
ora.eons
...
ora.registry.acfs

--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
1 ONLINE ONLINE racnode02
ora.gns
ora.gns.vip
ora.oc4j
1 OFFLINE ONLINE racnode02
ora.racnode01.vip
1 ONLINE ONLINE racnode01 ...
Vérifier l'installation d'Oracle Grid Infrastructure

Exécutez la commande crsctl comme indiqué dans la diapositive pour vérifier que toutes
les ressources du cluster sont en cours d'exécution. En outre, vous devez vérifier que le DNS
transmet correctement les demandes d'adresse de l'application et les adresses IP virtuelles
SCAN au GNS, et que celles-ci sont résolues correctement. Vous pouvez effectuer cette
opération avec la commande dig. Exécutez la commande dig avec les adresses DNS et VIP
indiquées ci-après :
# dig @myDNS.example.com racnode01-cluster01.example.com
...
;racnode01-vip.cluster01.example.com. IN A
;; ANSWER SECTION:
racnode01-vip.cluster01.example.com. 120 IN A 192.0.2.103
...
# dig @myDNS.example.com cluster01-scan.cluster01.example.com
...
;cluster01-scan.cluster01.example.com. IN A
;; ANSWER SECTION:

ASM et ACFS

Module 4 : Configurer des groupes de disques

Configurer ASM avec ASMCA

Configurer ASM avec ASMCA

L'assistant de configuration ASM (ASMCA), de même que ASMCMD et SQL*Plus, est situé
dans le répertoire Home d'Oracle Grid Infrastructure. Tous ces utilitaires requièrent que la
variable d'environnement ORACLE_SID soit définie. En utilisant le script oraenv, vous
pouvez définir les variables ORACLE_SID, ORACLE_HOME et PATH.
Considérons un exemple, en supposant que vous êtes connecté en tant que propriétaire du
logiciel grid sur le premier noeud du cluster :
$ . oraenv
ORACLE_SID = [+ASM1] ? +ASM1
The Oracle base for ORACLE_HOME=/u01/app/11.2.0/grid is
/u01/app/grid
Lancez l'utilitaire ASM Configuration Assistant (ASMCA) avec :
$ asmca
ASMCA fournit un ensemble complet de commandes permettant de gérer les instances ASM,
les groupes de disques, les volumes et les systèmes de fichiers clusterisés ASM.
Les opérations nécessaires pour gérer ASM peuvent également être effectuées dans
SQL*Plus, ASMCMD et Enterprise Manager.

Créer un groupe de disques ASM avec ASMCA

Créer un groupe de disques ASM avec ASMCA

Dans la diapositive ci-dessus, ASMCA est utilisé pour créer un groupe de disques. La
redondance a la valeur Normal. Quatre disques sont sélectionnés pour être des membres du
groupe : ORCL:DATA5, ORCL:DATA6, ORCL:DATA7 et ORCL:DATA8. Les deux premiers
disques sont placés dans le groupe d'échec ACFS1, et les autres dans le groupe d'échec
ACFS2. La colonne Header Status peut contenir différentes valeurs. Lorsque le disque est
créé pour la première fois, elle contient la valeur CANDIDATE. Si le disque a été membre
d'un groupe et a été correctement supprimé, elle contient la valeur FORMER comme illustré
dans la diapositive. La valeur PROVISIONED est similaire à la valeur CANDIDATE, à ceci
près qu'elle implique qu'une action supplémentaire propre à la plateforme a été effectuée par
un administrateur pour rendre le disque disponible pour ASM.
Le chemin de repérage (discovery) des disques est défini par le paramètre d'initialisation
ASM_DISKSTRING. Ce paramètre peut définir plusieurs chemins de recherche séparés par
des virgules. La valeur par défaut du paramètre ASM_DISKSTRING est une chaîne vide. Il
existe un chemin approprié de repérage par défaut pour la plupart des plateformes de système
d'exploitation. L'utilisation d'une chaîne de repérage limitée à quelques répertoires peut
réduire le temps de recherche, mais cette chaîne doit inclure tous les disques membres des
groupes existants. La chaîne par défaut permet à ASM de rechercher les disques qui ont été
initialisés via l'utilitaire Oracle ASMLib, oracleasm. Les options avancées pour les
groupes de disques sont indiquées plus loin dans ce chapitre.

Créer un groupe de disques ASM :

Options avancées

Créer un groupe de disques ASM : Options avancées

En bas de la page Create Disk Group, cliquez sur Show Advanced Options pour afficher la
page illustrée dans la diapositive ci-dessus. Dans cette partie de la page, vous pouvez définir
les attributs d'un groupe de disques : taille de l'unité d'allocation et compatibilité.
Le champ ASM Compatibility définit l'attribut COMPATIBLE.ASM. Pour Oracle ASM dans
Oracle Database 11g, 10.1 est la valeur par défaut de l'attribut COMPATIBLE_ASM lors de
l'utilisation de l'instruction SQL CREATE DISKGROUP, de la commande ASMCMD mkdg
et de la page Oracle Enterprise Manager Create Disk Group. Lorsque vous créez un groupe de
disques via ASMCA, la valeur par défaut est 11.2.0. Lors de la définition des attributs de
compatibilité, indiquez au moins les versions principale et mineure d'un numéro de version
Oracle Database valide. Par exemple, vous pouvez indiquer la valeur "11.1" ou "11.2".
Oracle considère que tous les chiffres manquants sont des zéros.
Le champ Database Compatibility indique le numéro de version minimum que doit avoir une
instance de base de données pour être autorisée à utiliser le groupe de disques. Il correspond à
l'attribut COMPATIBLE.RDBMS.
Pour qu'il soit possible d'utiliser des volumes ADVM, les champs ADVM Compatibility et
ASM Compatibility doivent contenir la valeur 11.2.0 ou une valeur supérieure. Le champ
ADVM Compatibility définit l'attribut COMPATIBLE.ADVM.
Remarque : L'augmentation des attributs de compatibilité d'un groupe de disques est une
opération irréversible.

Créer un groupe de disques

avec Enterprise Manager

Créer un groupe de disques avec Enterprise Manager

La même fonctionnalité est disponible avec Enterprise Manager. La diapositive ci-dessus
présente la page Disk Group de la cible Automatic Storage Management.
Remarque : Enterprise Manager ne fait pas partie de l'installation de Grid Infrastructure.
%QOOG XQWU NGXGTTG\ FCPU N GZGTEKEG CUUQEKÃ CWEJCRKVTG, vous devez installer une instance
de base de données pour accéder à la Enterprise Manager Database Control présentée dans la
diapositive ci-dessus.

Créer un groupe de disques
avec Enterprise Manager

Créer un groupe de disques avec Enterprise Manager (suite)

Tout comme avec l'utilitaire ASMCA, vous pouvez définir des groupes de disques et des
groupes d'échec dans la page Create Disk Group d'Enterprise Manager. Pour modifier la
chaîne de repérage (discovery) des disques, cliquez sur l'onglet Configuration. Les options de
compatibilité sont disponibles dans la page Create Disk Group, mais cette section n'est pas
affichée dans la diapositive ci-dessus.

Créer un groupe de disques ASM

avec les outils en mode ligne de commande
Créer un groupe de disques à l'aide de SQL :
CREATE DISKGROUP ACFS NORMAL REDUNDANCY
FAILGROUP ACFS2
DISK 'ORCL:DATA7' SIZE 1953 M ,'ORCL:DATA8' SIZE
2329 M
FAILGROUP ACFS1
DISK 'ORCL:DATA5' SIZE 1953 M ,'ORCL:DATA6' SIZE

1953 M
ATTRIBUTE 'compatible.rdbms' = '11.2.0.0.0',
'compatible.asm' = '11.2.0.0.0',
'compatible.advm' = '11.2.0.0.0' ;
Créer un groupe de disques à l'aide de ASMCMD :
asmcmd mkdg disk_config.xml
Créer un groupe de disques ASM avec les outils en mode ligne de commande
Vous pouvez créer un groupe de disques ASM avec les outils en mode ligne de commande.
L'instruction SQL présentée dans la diapositive exécute la même opération que celle qui a été
réalisée dans les diapositives précédentes avec ASMCA et Enterprise Manager.
La commande asmcmd de la diapositive effectue la même opération si le fichier
disk_config.xml est :
<dg name="data" redundancy="normal">
<fg name="fg1">
<dsk string="/dev/disk1"/>
<dsk string="/dev/disk2"/> </fg>
<fg name="fg2">
<dsk string="/dev/disk3"/>
<dsk string="/dev/disk4"/> </fg>
<a name="compatible.asm" value="11.2"/>
<a name="compatible.rdbms" value="11.2"/>
<a name="compatible.advm" value="11.2"/>
</dg>

Configurer un volume ASM : ASMCA

Configurer un volume ASM : ASMCA

Pour créer un volume ASM via ASMCA, cliquez sur l'onglet Volumes puis sur Create.
Dans la page Create Volume, entrez le nom du volume, sélectionnez le nom du groupe de
disques et entrez la taille. Ce sont les paramètres de base qui doivent être fournis.
Les attributs avancés sont la redondance et le striping. La redondance est appliquée au niveau
fichier dans ASM —dans ce cas, le volume. L'option Unprotected signifie qu'il n'existe qu'une
seule copie de l'extent de fichier de volume dans le groupe de disques. L'option Normal
indique qu'il y a deux copies de chaque extent de fichier volume dans des groupes d'échec
distincts. Ainsi, en cas de panne d'un disque, il reste toujours une copie. L'option High indique
qu'il existe trois copies, afin que le fichier ne soit pas perdu en cas de défaillance de deux
disques.
La zone Striping indique comment les données sont découpées en tranches dans le volume.
Les volumes peuvent avoir une granularité supérieure à celle des fichiers ASM. Le champ
Stripe Columns indique le nombre d'extents de fichier de volume alloués à un stripe et le
champ Stripe Width indique le nombre d'octets alloués à chaque extent de fichier. Les extents
de fichier sont placés sur les disques du groupe en mode tourniquet (round-robin). Des
morceaux de données de la taille du stripe sont alloués dans chaque extent de fichier en mode
tourniquet. Dans l'exemple de la diapositive ci-dessus, il y quatre extents de fichier et les
stripes remplissent ces extents avec des incréments de 128 Ko. Tous les extents obtiennent un
morceau de données avant l'attribution d'un second morceau à l'un d'eux. Ainsi, les E/S sont
réparties entre tous les disques du groupe, ce qui réduit les temps d'attente.

Configurer un volume ASM : EM

Configurer un volume ASM : EM

Dans la page d'accueil d'une instance ASM, accédez à la page Disk Group pour le groupe de
disques où vous voulez créer le volume.
1. Dans la page d'accueil de l'instance ASM, cliquez sur l'onglet Disk Groups.
2. Dans la page Disk Groups, cliquez sur le nom du groupe de disques.
3. Dans la page Disk Group: <disk group name>, cliquez sur l'onglet Volumes.
4. Cliquez sur Create.
5. Dans la page Create ASM Volume, entrez le volume, la taille et la redondance. Si vous le
souhaitez, sélectionnez les zones de disque à utiliser pour les extents principaux et les
extents miroir.

Configurer un volume ASM :

ASMCMD et SQL
Créer un volume à l'aide de SQL :
ALTER DISKGROUP ACFS ADD VOLUME TESTVOL
SIZE 500M UNPROTECTED
Créer un volume en utilisant ASMCMD :
volcreate -G ACFS -s 500M --redundancy unprotected

Configurer un volume ASM : ASMCMD et SQL

Vous pouvez créer un volume ASM avec les mêmes propriétés en utilisant SQL ou l'utilitaire
ASMCMD.

Configurer un système de fichiers ACFS

Configurer un système de fichiers ACFS

En utilisant ASMCA, vous pouvez formater le volume ASM avec un système de fichiers
ACFS (ASM Cluster File System). Dans la page Create ASM Cluster File System, vous
pouvez indiquer le point de montage d'un système de fichiers généraliste et, éventuellement,
enregistrer le point de montage. Une fois enregistré, le volume devient une ressource gérée,
qui est montée lorsque le serveur est lancé.
Pour un volume ACFS contenant un répertoire d'origine pour Oracle Database,
l'enregistrement est obligatoire. Le répertoire d'origine doit être enregistré en tant que
ressource gérée pour la mise à jour des dépendances entre la base de données, ASM et ACFS.
La dépendance implique qu'au démarrage d'une instance de base de données à l'aide de la
commande srvctl, ASM est démarré, le volume ACFS est monté et la base de données est
démarrée. La base de données ne peut pas être démarrée tant que le répertoire contenant les
exécutables (ORACLE HOME) n'est pas montée.
Remarque : ACSF ne peut pas être utilisé pour un système de fichiers racine, un système de
fichiers d'amorçage ou un système de fichiers contenant les exécutables de Grid
Infrastructure. Il ne peut être utilisé pour aucun fichier pouvant être stocké dans ASM.

Configurer un système de fichiers ACFS avec EM

Configurer un système de fichiers ACFS avec EM

La diapositive ci-dessus montre que vous pouvez utiliser EM pour configurer un système de
fichiers ACFS avec les mêmes options qu'avec ASMCA.

Configurer un système de fichiers ACFS à partir

de la ligne de commande
Linux/UNIX
• Formater le volume avec ACFS :
/sbin/mkfs -t acfs /dev/asm/testvol-461 "testvol"
• Enregistrer le point de montage :
/sbin/acfsutil registry -a -f /dev/asm/testvol-461

/u01/app/grid/acfsmounts/acfs_testvol
Windows
• Formater le volume avec ACFS :
acfsformat asm-volume1-123
• Enregistrer le point de montage :
acfsutil registry -f -a asm-volume1-123 G:/mnt
Configurer un système de fichiers ACFS à partir de la ligne de commande

5QWU .KPWZQW 70+:NGRTQRTKÃVCKTG FG)TKF+PHTCUVTWEVWTGRGWV HQTOCVGT NGXQNWOG.
L'exemple de la diapositive définit un système de fichiers ACFS sur le volume
/dev/asm/testvol-461 et lui associe le libellé de volume testvol.
Le propriétaire du logiciel de grid peut également stocker ce volume et un point de montage
particulier avec la configuration du cluster, afin que le volume soit monté au redémarrage.
Sous Windows, utilisez la commande indiquée pour définir un système de fichiers ACFS sur
le volume asm-volume-123. La commande Windows permettant d'enregistrer le volume a
la même syntaxe que la commande Linux/UNIX. Ces commandes diffèrent seulement par le
nom d'unité et de répertoire.
Windows comprend un ensemble distinct de commandes essentiellement destinées aux
systèmes de fichiers ACFS et aux volumes ADVM. Sous Linux et UNIX, vous utilisez les
commandes du système d'exploitation telles que mkfs et fsck, tandis que sous Windows,
vous utilisez acfsformat et acfschkdsk. Reportez-vous au manuel Oracle Database
Storage Administrator’s Guide: Oracle ACFS Command-Line Tools pour connaître la syntaxe
des outils ACFS en mode ligne de commande pour les deux environnements.

Monter un système de fichiers ACFS avec ASMCA

Monter un système de fichiers ACFS avec ASMCA

La diapositive ci-dessus présente les étapes requises pour monter un système de fichiers
ACFS avec ASMCA.
1. Appelez ASMCA et cliquez sur l'onglet ASM Cluster File System.
2. Cliquez avec le bouton droit sur le volume que vous souhaitez monter et sélectionnez
la commande Show Mount .
3. Dans la page Mount ACFS Command, vérifiez le point de montage et cliquez sur
Generate Command.
4. Dans la page Mount ACFS Command, copiez la commande dans une fenêtre de terminal
sur chaque noeud et exécutez la commande en tant que superutilisateur (root).

Monter un système de fichiers ACFS avec EM

Monter un système de fichiers ACFS avec EM

La diapositive ci-dessus présente les étapes de montage d'un système de fichiers ACFS
à partir d'Enterprise Manager.
1. Dans l'onglet ACFS de la page de l'instance ASM, sélectionnez le volume et cliquez
sur Mount.
2. Dans la page Cluster Select Hosts, sélectionnez les hôtes où vous souhaitez monter
le système de fichiers et cliquez sur Continue.
3. Dans la page Mount ASM Cluster File System, vérifiez le point de montage et cliquez
sur Generate Command.
4. Dans la page Show Command, copiez la commande dans une fenêtre de terminal
sur chaque noeud et exécutez la commande en tant que superutilisateur (root).

Monter un système de fichiers ACFS

avec les outils en mode ligne de commande
Windows
C:> acfsmountvol G:\mnt asm-volume1-123
Linux/UNIX
# /bin/mount -t acfs /dev/asm/testvol-461
/u01/app/grid/acfsdata/test

Monter un système de fichiers ACFS avec les outils en mode ligne de commande
Que vous utilisiez Enterprise Manager ou ASMCA, les commandes doivent être exécutées par
un superutilisateur. Le superutilisateur est root sous UNIX ou Linux, et administrator
sous Windows.
Les outils en mode ligne de commande correspondent aux mêmes commandes générées par
Enterprise Manager ou ASMCA.

Synthèse

Infrastructure
• installer Grid Infrastructure
• vérifier l'installation
• configurer des groupes de disques ASM

• configurer des volumes ASM
• implémenter un système de fichiers ACFS (ASM Cluster
File System)
• monter des volumes ACFS

Exercice 2 : Présentation
Dans cet exercice, vous allez :

Infrastructure
• installer Oracle Grid Infrastructure
• créer un groupe de disques ASM
• créer et monter un volume ASM


Quiz
Vous devez configurer GNS pour tirer parti de la configuration

automatique des adresses IP virtuelles.
1. Vrai
2. Faux

Réponse : 1



Administrer Oracle Clusterware

Objectifs

• gérer Oracle Clusterware
• décrire les techniques de sauvegarde et de restauration
du registre OCR (Oracle Cluster Registry)
• gérer les paramètres réseau


Gérer Oracle Clusterware
• Utilitaires en mode ligne de commande

– crsctl gère les opérations liées au clusterware :
— Démarrer et arrêter Oracle Clusterware
— Activer et désactiver les démons Oracle Clusterware
— Enregistrer les ressources du cluster
– srvctl gère les opérations liées aux ressources Oracle :
Démarrer et arrêter des instances et des services de base de

—
données
• Enterprise Manager
– Interface graphique basée sur un navigateur
– Fonctions de gestion de cluster dans :
— Database Control — dans le cluster
— Grid Control — via un serveur de gestion centralisé

La gestion d'Oracle Clusterware s'effectue à l'aide des utilitaires de ligne de commande
crsctl et srvctl installés dans le répertoire d'origine d'Oracle Grid Infrastructure.
Les composants et les ressources Oracle Clusterware peuvent être surveillés et gérés de
n'importe quel noeud du cluster à l'aide de crsctl. L'utilitaire srvctl fournit des
fonctionnalités de surveillance et de gestion similaires pour les ressources Oracle telles que
les instances et les services de base de données. Les deux utilitaires sont fournis avec Oracle
Clusterware. Toutefois, la plupart des commandes crsctl ne sont disponibles que pour les
administrateurs du clusterware, tandis que les commandes srvctl sont disponibles pour
d'autres groupes tels que les administrateurs de base de données.
Enterprise Manager est l'interface graphique de gestion basée sur un navigateur fournie par
Oracle. Elle peut être utilisé pour gérer Oracle Clusterware de deux manières. Enterprise
Manager Database Control peut être utilisé dans un cluster pour gérer les fonctions de ce
cluster. Enterprise Manager Database Control requiert l'installation et la configuration d'une
instance Oracle Database dans le cluster pour pouvoir être utilisé. Enterprise Manager Grid
Control utilise un serveur de gestion centralisé pour assurer la gestion de plusieurs clusters
à partir d'une console unique.

Gérer Oracle Clusterware avec Enterprise Manager
Exemple : Déplacer une ressource.

Gérer Oracle Clusterware avec Enterprise Manager

Enterprise Manager Database Control fournit des fonctions permettant de gérer Oracle
Clusterware. Ces fonctions permettent notamment d'enregistrer et de gérer les ressources.
L'exemple de la diapositive ci-dessus fournit une illustration standard de l'interface de gestion.
Il montre comment les ressources peuvent être déplacées dynamiquement d'un noeud à un
autre du cluster. La ressource my_resource est déplacée de host02 à host01.
Dans la page Confirmation, vous pouvez voir la commande qui sera exécutée pour transférer
la ressource :
crsctl relocate resource my_resource –n host01 –s host02

Contrôler Oracle Clusterware
L'utilitaire crsctl peut être employé pour contrôler Oracle

Clusterware.
• Pour démarrer ou arrêter Oracle Clusterware sur un noeud
particulier :
# crsctl start crs

# crsctl stop crs
• Pour activer ou désactiver Oracle Clusterware sur un

noeud particulier :
# crsctl enable crs
# crsctl disable crs
Contrôler Oracle Clusterware

Lorsqu'un noeud qui contient Oracle Clusterware est démarré, le script wrapper d'Oracle
Clusterware est automatiquement lancé par le script de démarrage /etc/init.d/ohasd.
Lorsque l'utilitaire crsctl est employé pour désactiver le démarrage automatique de Cluster
Ready Services (CRS), des informations d'état relatives au démarrage sont placées dans les
fichiers de contrôle SLCS_SRC, ce qui empêche le démarrage automatique lors de la
réinitialisation de la machine. Pour vérifier le statut de CRS, utilisez la syntaxe suivante :
# crsctl check crs
CRS-4638: Oracle High Availability Services is online
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
Vous pouvez être amené à contrôler manuellement la couche Oracle Clusterware lors de
l'application de patches ou pendant les indisponibilités prévues. Vous pouvez arrêter Oracle
Clusterware à l'aide de la commande crsctl stop crs et le démarrer à l'aide de la
commande crsctl start crs.

Vérifier le statut d'Oracle Clusterware
L'utilitaire crsctl peut être utilisé pour vérifier le statut

d'Oracle Clusterware.
• Pour déterminer l'état général sur un noeud particulier :
$ crsctl check crs
CRS-4638: Oracle High Availability Services is online

• Pour vérifier la viabilité des services CSS (Cluster

Synchronization Services) sur tous les noeuds :
$ crsctl check cluster
Vérifier le statut d'Oracle Clusterware

L'utilitaire crsctl peut être employé pour vérifier le statut d'Oracle Clusterware sur des
noeuds spécifiques et sur l'ensemble des noeuds. Contrairement aux commandes de contrôle
crsctl qui nécessitent un accès root (comme indiqué dans la diapositive précédente),
les commandes check n'ont pas besoin d'un accès root et peuvent être exécutées par le
propriétaire d'Oracle Clusterware. Il est possible de connaître l'état général du clusterware sur
un noeud particulier à l'aide de la commande crsctl check crs. Il est aussi possible de
cibler trois démons spécifiques en utilisant la commande crsctl check <daemon> pour
les démons crsd, evmd et cssd. Ces commandes ne sont traitées que sur le noeud où elles
sont exécutées. Pour vérifier la viabilité des services CSS (Cluster Synchronization Services)
sur tous les noeuds, utilisez la commande crsctl check cluster. La diapositive
présente le résultat d'un contrôle de l'état général du cluster.

Déterminer l'emplacement des fichiers

de configuration d'Oracle Clusterware
Les deux types principaux de fichier de configuration d'Oracle
sont le disque votant et le registre OCR (Oracle Cluster Registry).
• Pour déterminer l'emplacement du disque votant :
# crsctl query css votedisk
## STATE File Universal Id File Name Disk group
-- ----- ----------------- ---------- ----------
1. ONLINE 8c2e45d734c64f8abf9f136990f3daf8 (ASMDISK01) [DATA]

2. ONLINE 99bc153df3b84fb4bf071d916089fd4a (ASMDISK02) [DATA]
3. ONLINE 0b090b6b19154fc1bf5913bc70340921 (ASMDISK03) [DATA]
Located 3 voting disk(s).
• Pour déterminer l'emplacement du registre OCR :

$ cat /etc/oracle/ocr.loc
ocrconfig_loc=+DATA
local_only=FALSE
Déterminer l'emplacement des fichiers de configuration d'Oracle Clusterware

Oracle Clusterware utilise essentiellement deux types de fichier de configuration : le disque
votant et le registre OCR (Oracle Cluster Registry). Il peut y avoir plusieurs copies
redondantes de chacun de ces fichiers. Vous pouvez déterminer l'emplacement du disque
votant à l'aide de la commande crsctl query css votedisk sur n'importe quel
noeud. Il n'est pas obligatoire que les démons CSS soient en cours d'exécution, et la
commande peut être lancée par le propriétaire de Grid Infrastructure. L'emplacement du
fichier OCR peut être déterminé à l'aide de la commande cat /etc/oracle/ocr.loc.
Etant donné que ces fichiers se trouvent toujours dans l'espace de stockage partagé, la
commande peut être exécutée à partir de n'importe quel noeud.
Remarque : Le registre OCR peut également être localisé à l'aide de l'utilitaire ocrcheck,
à condition que le chemin de l'utilitaire soit connu ou que le chemin ait été ajouté à la variable
d'environnement PATH.

Vérifier l'intégrité des fichiers de configuration

d'Oracle Clusterware
Les techniques suivantes sont utilisées pour valider l'intégrité
des fichiers de configuration d'Oracle Clusterware.
• Recourez à l'utilitaire ocssd.log pour vérifier les
problèmes liés aux disques votants.
$ grep voting <grid_home>/log/<hostname>/cssd/ocssd.log

• Recourez à l'utilitaire cluvfy ou ocrcheck pour vérifier
l'intégrité du registre OCR.
$ cluvfy comp ocr –n all -verbose
$ ocrcheck
Vérifier l'intégrité des fichiers de configuration d'Oracle Clusterware

Pour vérifier l'intégrité des disques votants, examinez le fichier ocssd.log. Les erreurs
liées aux disques votants apparaissent dans ce journal. En voici un extrait :
$ grep voting ocssd.log
[ CSSD]2008-09-09 10:47:09.711 [100494224] >ERROR:
clssnmvReadFatal: voting device corrupt
(0x00000000/0x00000000/1//dev/sda6)
[ CSSD]2008-09-09 10:47:09.711 [3082128272] >ERROR:
clssnmvReadFatal: voting device corrupt
(0x00000000/0x00000000/2//dev/sda7)
Deux commandes peuvent être utilisées pour vérifier l'intégrité du registre OCR.
Ces commandes sont les suivantes :
$ ocrcheck
$ cluvfy comp ocr –n all –verbose

Sauvegarder et récupérer un disque votant
• Dans Oracle Clusterware 11g Release 2, les disques

votants sont sauvegardés automatiquement dans le registre
OCR lors de toute modification de la configuration.
• Les données du disque votant sont automatiquement
restaurées sur tous les disques votants ajoutés.
• L'utilisation de dd pour sauvegarder et restaurer un disque

votant peut entraîner la perte du disque votant !
• Pour ajouter ou supprimer des disques votants dans un
stockage non ASM (Automatic Storage Management),
utiliser les commandes suivantes :
# crsctl delete css votedisk path_to_voting_disk
# crsctl add css votedisk path_to_voting_disk
Sauvegarder un disque votant

Dans les versions antérieures, la sauvegarde des disques votants à l'aide d'une commande dd
était une tâche de postinstallation requise. Avec Oracle Clusterware 11g Release 2, cette
procédure n'est pas prise en charge car la sauvegarde et la restauration d'un disque votant
à l'aide de la commande dd peuvent entraîner la perte du disque votant.
Il n'est plus nécessaire de sauvegarder les disques votants manuellement car ils sont
sauvegardés automatiquement dans le registre OCR dans le cadre de toute modification de la
configuration. Par ailleurs, les données du disque votant sont automatiquement restaurées sur
tous les disques votants ajoutés.
Récupérer les disques votants
Si vous avez plusieurs disques votants dans l'espace de stockage non ASM, vous pouvez les
supprimer de votre environnement puis les rajouter avec toutes les informations provenant
des autres disques votants, à l'aide des commandes suivantes dans lesquelles path est le
chemin complet de l'emplacement du disque votant :
crsctl delete css votedisk path_to_voting_disk
crsctl add css votedisk path_to_voting_disk
Remarque : Vous pouvez migrer des disques votants d'un espace de stockage non ASM vers
un espace ASM sans arrêter le cluster. Pour utiliser un groupe de disques ASM pour gérer les
disques votants, vous devez définir l'attribut COMPATIBLE.ASM avec la valeur 11.2.0.0.

Ajouter, supprimer, ou migrer des disques votants
• Pour ajouter ou supprimer un ou plusieurs disques votants

dans un stockage non ASM :
# crsctl add css votedisk path_to_new_voting_disk
# crsctl delete css votedisk path_to_old_voting_disk
• Pour ajouter un disque votant à ASM :

# crsctl replace votedisk +asm_disk_group

• Pour migrer des disques votants entre un périphérique
de stockage non ASM et ASM, ou inversement, indiquez
le nom du groupe de disques ASM ou le chemin d'accès
du périphérique de stockage non ASM :
# crsctl replace votedisk {+asm_disk_group |
path_to_voting_disk}
Ajouter, supprimer, ou migrer des disques votants

Pour ajouter un ou plusieurs disques votants à un stockage non ASM, exécutez la commande
suivante en tant que root :
# crsctl add css votedisk path_to_voting_disk [...]
Pour ajouter un disque votant à ASM :
# crsctl replace votedisk +asm_disk_group
Pour remplacer le disque votant A par le disque votant B sur un stockage non ASM, ajoutez
d'abord le disque votant B, puis supprimez le disque votant A :
# crsctl add css votedisk path_to_voting_diskB
# crsctl delete css votedisk path_to_voting_diskA
Utilisez la commande crsctl replace votedisk pour remplacer un disque votant sur
une unité ASM. Vous n'avez pas besoin de supprimer des disques votants de l'unité ASM
à l'aide de cette commande.
Pour supprimer un disque votant, exécutez la commande suivante en tant que root, en
remplaçant la valeur de la variable voting_disk_GUID par un ou plusieurs identificateurs
globalement uniques (GUID) séparés par un espace, correspondant aux disques votants
à supprimer :
# crsctl delete css votedisk voting_disk_GUID
Pour migrer des disques votants entre un périphérique de stockage non ASM et ASM,
ou inversement, indiquez le nom du groupe de disques ASM ou le chemin d'accès du
périphérique de stockage non ASM dans la commande suivante :
# crsctl replace votedisk {+asm_disk_group | path_to_voting_disk}
Vous pouvez exécuter cette commande sur n'importe quel noeud du cluster.

Localiser les sauvegardes automatiques

du registre OCR
• Le registre OCR est sauvegardé automatiquement.
• Un seul noeud effectue la sauvegarde.
• Pour définir le noeud et l'emplacement de la sauvegarde :
$ ocrconfig -showbackup auto
host02 2009/07/28 12:20:42 /u01/app/.../cdata/cluster01/backup00.ocr
host02 2009/07/27 16:20:37 /u01/app/.../cdata/cluster01/day.ocr

host02 2009/07/28 00:20:39 /u01/app/.../cdata/cluster01/week.ocr
• Les fichiers peuvent être répartis entre les noeuds en raison

d'incidents.
• La fréquence des sauvegardes et les stratégies de conservation
sont définies comme suit :
– Toutes les quatre heures : CRS conserve les trois dernières copies.
– A la fin de chaque jour : CRS conserve les deux dernières copies.
– A la fin de chaque semaine : CRS conserve les deux dernières copies.
Localiser les sauvegardes automatiques du registre OCR

Les informations contenues dans le fichier OCR ont un caractère beaucoup plus dynamique
que celles du disque votant. Oracle Clusterware effectue automatiquement les sauvegardes
courantes du registre OCR. Il s'agit de sauvegardes physiques. Un seul noeud a la
responsabilité d'effectuer les sauvegardes, mais cette responsabilité peut être transmise à
n'importe quel autre noeud du cluster en cas d'indisponibilité. Par défaut, l'emplacement cible
des sauvegardes automatiques du fichier OCR est le répertoire̘
<Grid Home>/cdata/<cluster name> .
Des sauvegardes automatiques ont lieu toutes les quatre heures, mais les fichiers conservés
sont en nombre restreint. Seules les trois dernières sauvegardes effectuées au cours de
l'intervalle sont conservées, les plus anciennes étant écrasées. A la fin de la journée, une
sauvegarde est effectuée et les deux dernières sont conservées. A la fin de la semaine, une
sauvegarde est effectuée et les deux dernières sont conservées. En résumé, il n'y a que sept
sauvegardes automatiques qui nécessitent de l'espace de stockage. Elles présentent les
anciennetés suivantes : quatre heures, huit heures, douze heures, vingt-quatre heures,
quarante-huit heures, sept jours et quatorze jours. L'intervalle de sauvegarde de quatre heures
n'est pas fondé sur l'heure en cours, mais est calculé à partir du démarrage du clusterware.
Les noms des fichiers de sauvegarde, qui ne peuvent pas être modifiés, sont les suivants :
backup00.ocr, backup01.ocr, backup02.ocr, day.ocr, day_.ocr,
week.ocr et week_.ocr.

Modifier l'emplacement de la sauvegarde

automatique du registre OCR
• La sauvegarde automatique doit être effectuée dans un
emplacement partagé par tous les noeuds.
# ocrconfig –backuploc <path to shared CFS or NFS>
• Cet emplacement est utilisé pour les sauvegardes

automatiques et manuelles.

• Il est recommandé que ces fichiers soient inclus dans les
sauvegardes de routine planifiées vers un emplacement
hors ligne.
• Si les services CRS ont été arrêtés sur tous les noeuds,
la planification des sauvegardes est suspendue.
• Lorsqu'ils sont redémarrés, il n'y a pas de sauvegarde
immédiate. L'horloge des sauvegardes est initialisée.
Modifier l'emplacement de la sauvegarde automatique du registre OCR

Etant donné que la sauvegarde automatique n'est exécutée que par le noeud maître dans le
système de fichiers local par défaut, il est recommandé de modifier l'emplacement de la
sauvegarde automatique du registre OCR pour utiliser un emplacement partagé par tous les
noeuds du cluster, à l'aide de la commande ocrconfig -backuploc <new
location> . Cette commande admet un argument, qui est le chemin d'accès complet au
répertoire du nouvel emplacement. Cet emplacement est utilisé pour les sauvegardes
automatiques et manuelles. Vous ne pouvez pas personnaliser les fréquences de sauvegarde,
le nombre de copies conservées, ni les noms des fichiers de sauvegarde. Si les services CRS
sont arrêtés sur le noeud maître, un autre noeud devient le maître, et les sauvegardes
reprennent sur ce noeud. Si l'emplacement de sauvegarde n'a pas été remplacé par un
emplacement partagé, les sauvegardes peuvent exister localement sur plusieurs noeuds.
Si les services CRS sont arrêtés sur tous les noeuds au cours d'une sauvegarde planifiée,
leur redémarrage n'entraîne pas de sauvegarde immédiate. L'horloge des sauvegardes est
initialisée. Dans ce cas, l'intervalle entre les sauvegardes peut être supérieur aux quatre heures
standard.
En raison de l'importance des informations figurant dans le fichier OCR, il est recommandé
de créer manuellement des copies des sauvegardes physiques générées automatiquement.
Vous pouvez utiliser n'importe quel logiciel de sauvegarde pour copier ces fichiers, et il est
recommandé d'effectuer cette opération au moins une fois par jour, sur une unité différente de
celle des sauvegardes automatiques.
Remarque : Ne placez pas les sauvegardes automatiques du registre OCR dans un système de
fichiers #%(5
#5/ %NWUVGT(KNG5[UVGO.

Ajouter, remplacer et réparer un emplacement

de registre OCR
• Pour ajouter un emplacement de registre OCR sur une
unité de stockage ASM ou autre :
# ocrconfig -add +DATA2
# ocrconfig -add /dev/sde1
• Pour modifier l'emplacement actuel du registre OCR :

# ocrconfig -replace /dev/sde1 -replacement +DATA2
• Pour réparer la configuration OCR, exécutez la commande

suivante sur le noeud sur lequel vous avez arrêté Oracle
Clusterware :
[root@host03]# ocrconfig -repair -add DATA1
Vous ne pouvez pas effectuer cette opération sur un noeud sur lequel
est exécuté Oracle Clusterware.
Ajouter, remplacer et réparer un emplacement de registre OCR

Vous pouvez ajouter un emplacement de registre OCR après avoir effectué une mise à niveau
ou une installation d'Oracle Grid Infrastructure. Oracle Clusterware peut gérer jusqu'à cinq
emplacements redondants pour le registre OCR. En tant qu'utilisateur root, exécutez la
commande suivante pour ajouter un emplacement OCR sur une unité de stockage ASM
ou autre :
# ocrconfig -add +asm_disk_group | file_name
Pour modifier l'emplacement OCR en cours en utilisant destination_file ou
+ASM_disk_group pour indiquer les emplacements source et cible :
# ocrconfig -replace destination_file | +ASM_disk_group -replacement
destination_file | +ASM_disk_group
Il peut être nécessaire de réparer une configuration OCR si celle-ci a changé pendant qu'un
noeud était arrêté. La réparation d'une configuration OCR implique d'ajouter, de supprimer ou
de remplacer un emplacement OCR. Pour réparer une configuration OCR, exécutez
ocrconfig sur le noeud sur lequel vous avez arrêté Oracle Clusterware en tant que root :
# ocrconfig -repair -add file_name | -delete file_name | -replace
current_file_name -replacement new_file_name
%GVVG QRÃTCVKQP PG OQFKHKG NCEQPHKIWTCVKQP1%4SWG UWT NGPQGWF UWT NGSWGN XQWU GZÃEWVG\ NC
EQOOCPFG Par exemple, si l'emplacement OCR est /dev/sde1, utilisez la commande
ocrconfig -repair -add /dev/sde1 sur ce noeud pour réparer la configuration OCR.

Supprimer un emplacement de registre OCR
• Pour supprimer un emplacement OCR, il faut qu'au moins

un autre registre OCR soit en ligne.
• Exécutez la commande suivante sur n'importe quel noeud
du cluster pour supprimer un emplacement OCR d'une
unité ASM ou d'un autre emplacement partagé :
# ocrconfig -delete +DATA2

# ocrconfig -delete /dev/sde1
• N'exécutez pas une suppression d'emplacement OCR

s'il n'y a pas au moins un autre emplacement OCR actif
en ligne !
Supprimer un emplacement de registre OCR

Pour supprimer un emplacement OCR, il faut qu'au moins un autre registre OCR soit en ligne.
Vous pouvez supprimer un emplacement OCR afin de réduire la surcharge correspondante,
ou pour arrêter la mise en miroir du fichier OCR car vous avez déplacé celui-ci sur une unité
de stockage redondante telle qu'une unité RAID.
Exécutez la procédure suivante en tant qu'utilisateur root pour supprimer un emplacement
OCR de l'environnement Oracle Clusterware :
1. Assurez-vous qu'au moins un emplacement OCR autre que celui supprimé est en ligne.
2. Exécutez la commande suivante sur n'importe quel noeud du cluster pour supprimer un
emplacement OCR d'une unité ASM ou d'un autre emplacement :
# ocrconfig -delete +ASM_disk_group | file_name
La variable file_name peut représenter un nom d'unité ou de fichier. Cette commande met
à jour la configuration OCR sur tous les noeuds sur lesquels Oracle Clusterware est exécuté.
Attention : Avant de supprimer un emplacement OCR, assurez-vous qu'il existe au moins un
autre emplacement OCR actif en ligne.

Migrer des emplacements OCR vers ASM
1. Vérifiez que vous disposez de la mise à niveau Oracle

Clusterware 11g Release 2.
$ crsctl query crs activeversion
Oracle Clusterware active version on cluster is [11.2.0.1.0]
2. Démarrez ASM sur tous les noeuds et créez un groupe de
disques qui comporte au moins 1 Go d'espace et présente au
moins une redondance normale.

3. Pour ajouter un emplacement OCR à un groupe de disques
ASM, exécutez la commande suivante en tant que root :
# ocrconfig -add +DATA2
4. Pour supprimer les configurations de stockage qui ne sont plus
utilisées, exécutez la commande suivante en tant que root :
# ocrconfig -delete /dev/raw/raw1
# ocrconfig -delete /dev/raw/raw2
Migrer des emplacements OCR vers ASM

Dans Oracle Database 11g Release 2, le registre OCR est par défaut configuré pour utiliser
ASM afin de faciliter la gestion du stockage Oracle Clusterware. Lorsque le stockage Oracle
Clusterware se trouve dans un groupe de disques ASM, vous pouvez gérer la base de données
et le clusterware à partir d'EM.
Toutefois, lorsque vous effectuez la mise à niveau d'une version antérieure d'Oracle Database,
vous pouvez migrer les emplacements OCR vers une unité ASM afin de bénéficier des
améliorations apportées à la gestion du stockage Oracle Clusterware. Pour migrer un
emplacement OCR vers ASM à l'aide de la commande ocrconfig :
1. Vérifiez que la mise à niveau d'Oracle Clusterware vers la version 11g Release 2 est
terminée. Exécutez la commande suivante pour vérifier la version actuelle en cours :
2. Utilisez #5/ %QPHKIWTCVKQP#UUKUVCPV
#5/%# pour configurer et démarrer ASM sur
tous les noeuds du cluster, puis créez un groupe de disques qui comporte au moins 1 G
d'espace et présente au moins une redondance normale.
3. Pour ajouter un emplacement OCR à un groupe de disques ASM, vérifiez que la couche
Oracle Clusterware fonctionne et exécutez la commande suivante en tant que root: #
ocrconfig -add +new_disk_group
Vous pouvez exécuter cette commande plus d'une fois si vous ajoutez plusieurs
emplacements OCR.
4. Pour supprimer les configurations de stockage qui ne sont plus utilisées, exécutez la
commande suivante en tant que root :
# ocrconfig -delete old_storage_location

Migrer des emplacements OCR vers ASM (suite)
Remarque : Le registre OCR hérite de la redondance du groupe de disques. Si vous souhaitez

une redondance élevée pour ce registre, vous devez configurer le groupe de disques avec une
redondance élevée lorsque vous le créez.

Migration d'un registre OCR d'une unité ASM
vers une autre unité de stockage partagé

1. Vérifiez que vous disposez de la mise à niveau Oracle
Clusterware 11g Release 2.
Oracle Clusterware active version on cluster is [11.2.0.1.0]
2. Créez au moins un fichier partagé avec les droits suivants :
root, oinstall, 640 en vous assurant que la partition de
montage comporte au moins 300 Mo d'espace libre.

3. Pour ajouter un emplacement OCR Location, assurez-vous que
la couche Oracle Clusterware est en cours d'exécution et lancez
la commande suivante en tant que root :
# ocrconfig -add /dev/sde1
# ocrconfig -add /dev/sdf1
4. Pour supprimer les configurations de stockage qui ne sont plus
utilisées, exécutez la commande suivante en tant que root :
# ocrconfig -delete +DATA2
Migration d'un registre OCR d'une unité ASM vers une autre unité de stockage
partagé
Pour migrer le stockage d'Oracle Clusterware d'ASM vers une autre solution :
1. Vérifiez que la mise à niveau d'Oracle Clusterware vers la version 11g Release 2 est
terminée. Exécutez la commande suivante pour vérifier la version en cours d'exécution :
$ crsctl query crs activeversion.
2. Créez un fichier partagé avec les droits suivants : root, oinstall, 640, en vous
assurant que la partition de montage comprend au moins 300 Mo d'espace.
3. Pour ajouter le fichier comme emplacement OCR, assurez-vous que la couche Oracle
Clusterware est en cours d'exécution et lancez la commande suivante en tant que root :
# ocrconfig -add new_file_location
emplacements OCR.
4. Pour supprimer les configurations de stockage qui ne sont plus utilisées, exécutez la
commande suivante en tant que root :
# ocrconfig -delete old_storage_location
emplacements OCR.

Exécuter des sauvegardes manuelles

du registre OCR
Lorsque des modifications importantes sont apportées à la
configuration, il est recommandé d'effectuer une sauvegarde
manuelle à la demande.
• Pour effectuer une sauvegarde physique :
# ocrconfig -manualbackup
• Pour afficher la liste des sauvegardes manuelles :

$ ocrconfig –showbackup manual
host02 2009/07/28 16:59:17
/u01/app/.../cdata/cluster01/backup_20090728_165917.ocr
• Pour effectuer une sauvegarde logique :

# ocrconfig -export /home/oracle/ocr.backup
Exécuter des sauvegardes manuelles du registre OCR

A la différence de celui du disque votant, le contenu OCR peut être très dynamique par
nature, notamment dans les environnements haute disponibilité. Si une quantité importante
de travail a été réalisée et entraîne des modifications du registre OCR, il est recommandé
d'effectuer une sauvegarde manuelle ou un export sans attendre la sauvegarde automatique.
Cette sauvegarde à la demande pourra être utilisée pour restaurer les informations en cas de
perte ou de corruption des données OCR avant la sauvegarde automatique.
Vous ne pouvez pas indiquer le nom employé pour la sauvegarde manuelle. Cette opération
crée un fichier nommé backup_<date>_<time>.ocr qui est placé dans l'emplacement
de sauvegarde par défaut. Lorsqu'une sauvegarde manuelle est exécutée, elle n'affecte pas
l'intervalle de sauvegarde automatique. La commande export crée un fichier binaire qui
contient une sauvegarde logique des clés et des valeurs OCR.
La plupart des modifications que vous apportez à la configuration affectent non seulement le
contenu du fichier OCR, mais créent également des fichiers et des objets de base de données.
Souvent, certaines de ces modifications ne sont pas restaurées lorsque vous restaurez le fichier
OCR. N'effectuez pas de restauration du fichier OCR pour rétablir des configurations
antérieures si certaines des modifications apportées à la configuration échouent. Le contenu
du fichier OCR risquerait de ne pas correspondre à l'état du reste du système.

Récupérer le registre OCR

à l'aide de sauvegardes physiques
1. Localisez une sauvegarde physique : $ ocrconfig –showbackup
2. Arrêtez la couche Oracle Clusterware # crsctl stop cluster -all

sur tous les noeuds :
3. Arrêtez Oracle High Availability # crsctl stop crs

Services sur tous les noeuds :

4. Restaurez la sauvegarde physique du registre OCR :
# ocrconfig –restore /u01/app/.../cdata/cluster01/day.ocr
5. Redémarrez Oracle High

Availability Services sur # crsctl start crs
tous les noeuds :
6. Vérifiez l'intégrité du registre OCR : $ cluvfy comp ocr -n all
Récupérer le registre OCR à l'aide de sauvegardes physiques

Utilisez la procédure suivante pour restaurer le fichier OCR sur un système UNIX :
1. Identifiez les sauvegardes OCR en utilisant la commande ocrconfig -
showbackup. Vous pouvez exécuter cette commande à partir de n'importe quel noeud
en tant qu'utilisateur oracle. La sortie indique sur quel noeud et selon quel chemin
extraire les sauvegardes générées automatiquement et manuellement. Utilisez l'argument
auto ou manual pour afficher une seule catégorie.
2. Arrêtez la couche Oracle Clusterware sur tous les noeuds à l'aide de la commande
crsctl stop cluster -all.
3. Arrêtez Oracle High Availability Services sur tous les noeuds du cluster en exécutant la
commande crsctl stop crs sur tous les noeuds en tant qu'utilisateur root.
4. Effectuez la restauration en appliquant le fichier de sauvegarde OCR identifié à l'étape 1,
en utilisant la commande suivante en tant qu'utilisateur root, où file_name est le
nom du fichier OCR à restaurer : ocrconfig -restore file_name.
Assurez-vous que les unités OCR que vous indiquez dans le fichier de configuration
OCR (/etc/oracle/ocr.loc) existent et sont valides.
5. Redémarrez Oracle High Availability Services sur les noeuds du cluster en redémarrant
chaque noeud ou en exécutant la commande crsctl start crs en tant
qu'utilisateur root.
6. Vérifiez l'intégrité des fichiers OCR sur tous les noeuds à l'aide de la commande
cluvfy comp ocr –n all.

Récupérer le registre OCR à l'aide

de sauvegardes logiques
1. Localisez une sauvegarde logique créée à l'aide d'une
exportation du fichier OCR.
2. Arrêtez Oracle Clusterware sur tous les noeuds :
# crsctl stop cluster -all
3. Arrêtez Oracle High Availability Services sur tous les noeuds :
# crsctl stop crs

4. Restaurer les sauvegardes du fichier OCR logique :
# ocrconfig –import /shared/export/ocrback.dmp
5. Redémarrez Oracle High Availability Services sur tous les

noeuds :
# crsctl start crs
6. Vérifiez l'intégrité du fichier $ cluvfy comp ocr -n all
OCR :
Récupérer le registre OCR à l'aide de sauvegardes logiques

Utilisez la procédure suivante pour importer le fichier OCR sous UNIX :
1. Identifiez le fichier OCR que vous souhaitez importer en identifiant le fichier d'export
OCR que vous avez créé précédemment à l'aide de la commande ocrconfig -export
file_name.
2. Arrêtez Oracle Clusterware sur l'ensemble des noeuds de la base de données RAC en
exécutant la commande crsctl stop crs sur tous les noeuds en tant qu'utilisateur
root.
3. Exécutez l'import en appliquant le fichier d'export OCR que vous avez identifié à l'étape
1 à l'aide de la commande suivante, où file_name correspond au nom du fichier OCR à
partir duquel vous souhaitez importer les informations OCR :
ocrconfig -import file_name
4. Redémarrez Oracle High Availability Services sur tous les noeuds du cluster en
redémarrant chaque noeud à l'aide de la commande crsctl start crs.
5. Lancez la commande de vérification du cluster (cluvfy) pour contrôler l'intégrité du
fichier OCR. L'argument -n all extrait la liste de tous les noeuds configurés comme
membres du cluster :
cluvfy comp ocr -n all

Registre Oracle Local Registry

• Chaque noeud du cluster dispose d'un fichier OCR local pour les
ressources qui lui sont propres, appelé Oracle Local Registry (OLR).
• Le registre OLR est installé et configuré lorsqu'Oracle Clusterware est
installé.
• Une de ses fonctions est de faciliter le démarrage d'Oracle Clusterware
dans les cas où ASM est utilisé pour le registre OCR et les disques
votants.
• Vous pouvez vérifier le statut du registre OLR à l'aide de ocrcheck :
$ ocrcheck –local

Status of Oracle Local Registry is as follows :
Version : 3
Total space (kbytes) : 262120
Used space (kbytes) : 2204
Available space(kbytes): 259916
ID : 1535380044
Device/File Name : /u01/app/11.2.0/grid/cdata/host01.olr
Device/File integrity check succeeded
Local registry integrity check succeeded
Logical corruption check succeeded
Registre Oracle Local Registry

Dans Oracle Clusterware 11g Release 2, chaque noeud du cluster dispose d'un registre local
pour les ressources qui lui sont propres, appelé Oracle Local Registry (OLR). Ce registre est
installé lorsqu'Oracle Clusterware installe le registre OCR. Le registre OLR d'un noeud peut
faire l'objets d'accès simultanés en lecture et en écriture émanant de plusieurs processus,
qu'Oracle Clusterware soit ou non en cours d'exécution et complètement opérationnel.
Le registre OLR fournit à différents processus Oracle Clusterware l'accès aux données de
configuration principales même si Oracle Clusterware ne s'exécute pas sur le noeud. Une de
ses fonctions est de faciliter le démarrage d'Oracle Clusterware dans les cas où ASM est
utilisé pour le registre OCR et les disques votants. Pendant le processus de démarrage, le
registre OLR est utilisé pour rechercher l'emplacement exact des disques votants. Cela permet
au noeud de joindre le cluster. Après la première phase, ASM est démarré. Une fois qu'ASM
est démarré, les processus qui nécessitent le registre OCR complet peuvent démarrer et le
processus de démarrage du clusterware s'exécute.
Par défaut, le registre OLR est situé dans grid_home/cdata/hostname.olr. Vous pouvez
contrôler le registre OLR à l'aide des utilitaires ocrcheck, ocrdump et ocrconfig avec
l'option -local.
Vous pouvez vérifier le statut du registre OLR à l'aide de l'utilitaire ocrcheck, comme suit :
$ ocrcheck –local

Registre Oracle Local Registry (suite)

Vous pouvez afficher le contenu du registre OLR sur le terminal du texte qui a lancé le
programme, à l'aide de l'utilitaire OCRDUMP :
$ ocrdump -local -stdout
Vous pouvez effectuer des tâches d'administration sur le registre OLR à l'aide de l'utilitaire
OCRCONFIG. Pour exporter le registre OLR dans un fichier :
$ ocrconfig –local –export file_name
Pour importer un fichier dans le registre OLR :
$ ocrconfig –local –import file_name
Pour modifier le fichier OLR sur le noeud local :
$ ocrconfig –local –repair olr file_name

Le mot-clé olr utilisé avec l'option -repair n'est valide que lorsque l'option -local est
utilisée.

Déterminer les paramètres réseau en cours

• Pour déterminer la liste des interfaces disponibles dans le cluster :
$ oifcfg iflist –p -n
• Pour déterminer les interfaces publiques et privées qui ont été
configurées :
$ oifcfg getif
eth0 192.0.2.0 global public
eth1 192.168.1.0 global cluster_interconnect

• Pour déterminer le nom d'hôte, l'adresse, le masque de sous-
réseau et l'interface associés à une adresse IP virtuelle (VIP) :
$ srvctl config nodeapps -a

VIP exists.:host01
VIP exists.:
/192.0.2.247/192.0.2.247/255.255.255.0/eth0
...
Déterminer les paramètres réseau en cours

Pour déterminer la liste des interfaces disponibles sur le cluster, recourez à l'utilitaire Oracle
Interface Configuration (oifcfg). La commande oifcfg iflist –p –n interroge le
système d'exploitation pour repérer les interfaces réseau présentes sur le noeud. Si l'option –n
est utilisée, la sortie indique le numéro réseau de chaque interface, et non l'adresse IP avec le
masque réseau.
Pour déterminer les interfaces publiques, privées et de stockage qui ont été configurées pour
Oracle Clusterware, utilisez la commande oifcfg getif.
Les adresses IP virtuelles (VIP) ne doivent être associées qu'aux interfaces publiques. Pour
déterminer le nom d'hôte, l'adresse, le masque de sous-réseau et l'interface associés à une
adresse IP virtuelle, utilisez la commande srvctl config nodeapps –a.

Modifier des adresses IP virtuelles publiques
1. Arrêtez tous les services qui s'exécutent sur le noeud dont

vous voulez modifier l'adresse IP virtuelle :
$ srvctl stop service -d RDBA -s sales,oltp -n host01
2. Vérifiez l'adresse IP en cours de l'adresse IP virtuelle :

$ srvctl config vip -n host01

VIP exists.:host01
VIP exists.: /host01-vip/192.168.2.20/255.255.255.0/eth0
3. Arrêtez l'adresse IP virtuelle :

$ srvctl stop vip -n host01
4. Vérifiez que l'adresse IP virtuelle ne fonctionne plus en

exécutant la commande ifconfig -a.

Les clients configurés pour utiliser des adresses IP virtuelles publiques ouvertes pour des
versions de base de donnée antérieures à Oracle Database 11g Release 2 peuvent continuer
à utiliser leurs adresses de connexion existantes. Il est recommandé de configurer les clients
pour utiliser FGUPQOU 5%#0
5KPING%NKGPV#EEGUU0COG, mais ce n'est pas obligatoire.
Lorsqu'une version antérieure d'Oracle Database est mise à niveau, elle est enregistrée avec
un nom SCAN. Les clients peuvent utiliser ce nom pour se connecter à la base de données,
ou ils peuvent continuer à utiliser les adresses IP virtuelles pour les connexions.
Si vous continuez à utiliser les adresses IP virtuelles pour les connexions client, vous pouvez
modifier l'adresse IP virtuelle alors qu'Oracle Database et Oracle ASM continuent à
s'exécuter. Toutefois, vous devez arrêter les services lorsque vous modifiez l'adresse. Lorsque
vous redémarrez l'adresse IP virtuelle, les services sont également redémarrés sur le noeud.
Effectuez les opérations suivantes pour modifier une adresse IP virtuelle :
1. Arrêtez tous les services qui s'exécutent sur le noeud dont vous voulez modifier l'adresse
IP virtuelle :
$ srvctl stop service -d db_name -s service_name_list -n my_node
2. Vérifiez l'adresse IP actuelle de l'adresse VIP à l'aide de la commande srvctl
config vip :
$ srvctl config vip -n my_node
3. Arrêtez l'adresse IP virtuelle à l'aide de la commande srvctl stop vip :
$ srvctl stop vip -n mynode
4. Vérifiez que l'adresse IP virtuelle ne fonctionne plus en exécutant la commande
ifconfig -a.

5. Apportez les modifications nécessaires au fichier /etc/hosts

sur tous les noeuds et modifiez le serveur DNS (Domain Name
Server) pour associer la nouvelle adresse IP à l'ancien nom hôte.
6. Modifiez les applications associées au noeud et indiquez une
nouvelle adresse IP virtuelle :
# srvctl modify nodeapps -n host01 -A \
192.168.2.125/255.255.255.0/eth0

7. Démarrez l'adresse IP virtuelle associée au noeud.
# srvctl start vip -n host01
8. Répétez les étapes pour chaque noeud du cluster.
9. Exécutez cluvfy pour vérifier la connectivité entre tous les
noeuds pour lesquels le cluster est configuré :
$ cluvfy comp nodecon -n all -verbose
Modifier des adresses IP virtuelles publiques (suite)

5. Apportez les modifications nécessaires aux fichiers /etc/hosts sur tous les noeuds et
modifiez le serveur DNS pour associer la nouvelle adresse IP à l'ancien nom d'hôte.
6. Modifiez les applications associées au noeud et indiquez une nouvelle adresse IP virtuelle
à l'aide de la syntaxe suivante :
# srvctl modify nodeapps -n node_name -A new_vip_address
7. Démarrez la nouvelle adresse IP virtuelle du noeud en exécutant la commande
srvctl start vip :
$ srvctl start vip -n mynode
8. Répétez les étapes pour chaque noeud du cluster.
Etant donné que l'utilitaire srvctl est un outil de gestion au niveau cluster, vous pouvez
effectuer ces tâches pour n'importe quel noeud particulier sans devoir vous connecter à
celui-ci.
9. Exécutez la commande suivante pour vérifier la connectivité entre tous les noeuds pour
lesquels le cluster est configuré. Cette commande repère toutes les interfaces réseau
disponibles sur les noeuds du cluster et vérifie la connectivité entre les noeuds par le biais
de ces interfaces. La commande ci-après liste également toutes les interfaces disponibles
sur les noeuds qui conviennent comme adresses IP virtuelles.
$ cluvfy comp nodecon -n all -verbose

Modifier l'adaptateur d'interconnexion

• Sur un noeud unique du cluster, ajoutez la nouvelle spécification d'interface globale :
$ oifcfg setif -global eth2/192.0.2.0:cluster_interconnect
• Vérifiez les modifications avec oifcfg getif puis arrêtez Clusterware sur tous les
noeuds en exécutant la commande suivante en tant que root sur chaque noeud :
# oifcfg getif
# crsctl stop crs
• Affectez l'adresse réseau aux nouveaux adaptateurs réseau sur tous les noeuds
à l'aide de la commande ifconfig :

# ifconfig eth2 192.0.2.15 netmask 255.255.255.0 \
broadcast 192.0.2.255
• Supprimez l'ancienne spécification d'adaptateur/sous-réseau et redémarrez
Clusterware :
$ oifcfg delif -global eth1/192.168.1.0
# crsctl start crs
Modifier l'adaptateur d'interconnexion

Pour modifier l'interface réseau pour l'interconnexion privée entre noeuds (par exemple, eth1),
vous devez effectuer la modification sur tous les noeuds (de manière globale). Cela tient au
fait qu'Oracle ne permet actuellement pas l'utilisation de différentes cartes d'interface réseau
dans le même sous-réseau pour l'interconnexion entre les noeuds du cluster.
Pour modifier l'interface réseau, procédez comme suit :
1. Vérifiez que la couche Oracle Clusterware est en cours d'exécution sur tous les noeuds
du cluster.
2. Utilisez les commandes du système d'exploitation (ifconfig ou la commande
correspondant à votre système) pour vérifier que l'interface nouvelle ou modifiée est
configurée et active sur tous les noeuds membres du cluster.
3. Sur un noeud unique du cluster, ajoutez la nouvelle spécification d'interface globale :
$ oifcfg setif -global interface_name/subnet:cluster_interconnect
4. Sur un noeud du cluster, utilisez ifconfig pour vérifier que la nouvelle adresse
IP existe.
5. Ajoutez le nouveau sous-réseau à l'aide de la commande suivante, qui précise le nom de
l'interface et l'adresse du sous-réseau. Les modifications prennent effet lorsqu'Oracle
Clusterware redémarre :
$ oifcfg setif -global interface_name/subnet:cluster_interconnect
6. Vérifiez la configuration avec la commande oifcfg getif.
7. Arrêtez Oracle Clusterware en exécutant la commande suivante en tant que root sur
chaque noeud :
# crsctl stop crs

Modifier l'adaptateur d'interconnexion (suite)

8. Affectez l'adresse réseau en cours au nouvel adaptateur réseau en utilisant ifconfig.
En tant qu'utilisateur root, exécutez la commande du système d'exploitation ifconfig
pour affecter l'adresse réseau privée en cours à l'adaptateur réseau destiné à être utilisé
pour l'interconnexion. Il requiert généralement un certain temps d'arrêt pour l'interface
en cours et la nouvelle interface. Reportez-vous à la documentation du système
d'exploitation de votre plate-forme pour plus d'informations sur l'exécution de la
commande ifconfig.
Vous devez actualiser la configuration du système d'exploitation car les modifications
apportées à l'aide de la commande ifconfig ne sont pas persistantes.
9. Supprimez l'ancien sous-réseau comme suit, en indiquant le nom et l'adresse de

l'ancienne interface : oifcfg delif -global interface_name/subnet
Par exemple : $ oifcfg delif -global eth1/10.10.0.0
Remarque : Cette étape ne doit être exécutée qu'après la validation d'une interface de
remplacement dans la configuration Grid Plug and Play. La suppression pure et simple
des interfaces du cluster sans fournir d'interface de remplacement valide peut entraîner
une configuration non valide.
10. Redémarrez Oracle Clusterware en exécutant la commande suivante en tant
qu'utilisateur root sur tous les noeuds :
# crsctl start crs
Vous devez redémarrer Oracle Clusterware après l'exécution de la commande oifcfg
delif car Oracle Clusterware, Oracle ASM, et Oracle RAC continuent à utiliser
l'ancien sous-réseau jusqu'à ce qu'ils soient redémarrés.

Gérer les ressources de type adresse VIP

et processus d'écoute SCAN
• Pour ajouter une ressource de type adresse VIP SCAN :
$ srvctl add scan -n cluster01-scan
• Pour supprimer des ressources Oracle d'une adresse

VIP SCAN :
$ srvctl remove scan [-f]

• Pour ajouter une ressource de type processus d'écoute
SCAN :
$ srvctl add scan_listener
$ srvctl add scan_listener -p 65536 ## using nondefault port number ##
• Pour supprimer des ressources Oracle Clusterware de

tous les processus d'écoute SCAN :
$ srvctl remove scan_listener [-f]
Gérer les ressources associées aux adresses VIP et aux processus

d'écoute SCAN
La commande srvctl add scan permet d'associer des ressources Oracle Clusterware à un
nom SCAN spécifique. La commande crée un nombre de ressources VIP SCAN identique au
nombre d'adresses IP générées par SCAN, ou égal à trois lorsque network_number identifie
un réseau DHCP et une configuration Oracle GNS. Utilisez la commande srvctl add
scan avec la syntaxe suivante :
srvctl add scan -n scan_name [-k network_number [-S subnet/
netmask[/if1[|if2|...]] où –n est le nom SCAN qualifié par le domaine et -k est le
numéro optionnel du réseau d'où proviennent les adresses IP SCAN. Sinon, les adresses VIP
SCAN proviennent du même réseau que les adresses VIP standard. Si le numéro de réseau
n'existe pas, la clause -S <subnet>/<netmask>/[|if1] le crée. La clause –S doit être
utilisée lorsque <network_number> n'existe pas.
Pour ajouter le nom SCAN new-scan.cluster01.example.com, exécutez la
commande suivante :
# srvctl add scan -n new-scan.cluster01.example.com
La commande srvctl add scan_listener peut être utilisée pour associer des ressources
aux processus d'écoute SCAN. Le nombre de ressources créées est identique au nombre de
ressources associées à des adresses VIP SCAN. Utilisez la commande srvctl add
scan_listener avec la syntaxe suivante :
srvctl add scan_listener [-l lsnr_name_prefix] [-p scan_port]
où –l est le préfixe du nom du processus d'écoute SCAN, et –p, le numéro de port.

Gérer les ressources associées aux adresses VIP

et aux processus d'écoute SCAN
• La commande srvctl modify scan modifie la

configuration VIP SCAN pour qu'elle corresponde à celle
d'une autre adresse VIP SCAN :
$ srvctl modify scan -n new-scan
• La commande srvctl modify scan_listener -u

modifie les informations de configuration de tous les
processus d'écoute SCAN afin qu'elles correspondent à la
configuration VIP SCAN en cours :
$ srvctl modify scan_listener -u
SCAN (suite)
La commande srvctl modify scan modifie la configuration d'une adresse VIP SCAN
pour qu'elle corresponde à celle d'une autre adresse VIP SCAN identifiée par scan_name.
Si scan_name désigne plus d'adresses IP que dans la configuration initiale, de nouvelles
ressources Oracle Clusterware sont créées pour les adresses supplémentaires. Si scan_name
désigne un nombre inférieur d'adresses IP, les ressources Oracle Clusterware associées aux
adresses VIP SCAN présentant les numéros les plus élevés sont supprimées afin que le
nombre de ressources VIP SCAN corresponde au nombre d'adresses IP défini par scan_name.
Utilisez la commande srvctl modify scan avec la syntaxe suivante :
srvctl modify scan [-n scan_name]
Pour modifier la configuration VIP SCAN cluster01-scan :
# srvctl modify scan -n cluster01-scan
La commande srvctl modify scan_listener modifie les informations de configuration
de tous les processus d'écoute SCAN. Utilisez la commande srvctl modify
scan_listener avec la syntaxe suivante :
srvctl modify scan_listener { -p scan_port | -u }
–p est le nouveau port de recherche et –u met à jour la configuration du processus d'écoute
SCAN pour la faire correspondre à la configuration de l'adresse VIP SCAN en cours.

SCAN (suite)
Pour modifier le port du processus d'écoute SCAN pour LISTENER_SCAN1 et actualiser la
configuration du cluster, exécutez la commande suivante :
# srvctl modify scan_listener -p 1531
# srvctl modify scan_listener –u
# srvctl config scan_listener ### To verify changes ###
SCAN Listener LISTENER_SCAN1 exists. Port: TCP:1531

Quiz
Lesquels des outils suivants ne peuvent pas être utilisés pour

gérer les opérations de Clusterware ou les ressources Oracle ?
1. Enterprise Manager
2. srvctl
3. Oracle Universal Installer
4. crsctl

Réponse : 3
La bonne réponse est 3.

Quiz
Parmi les affirmations suivantes concernant le registre OLR

(Oracle Local Registry), lesquelles sont vraies ?
1. Chaque noeud du cluster dispose d'un registre local
pour les ressources propres aux noeuds.
2. Le registre OLR doit être créé manuellement après
l'installation de Grid Infrastructure sur chaque noeud

du cluster.
3. Une de ses fonctions est de faciliter le démarrage d'Oracle
Clusterware dans les cas où ASM est utilisé pour le
registre OCR et les disques votants.
4. Vous pouvez vérifier le statut du registre OLR à l'aide
de ocrcheck.
Réponses : 1,3,4
Les affirmations 1, 3 et 4 sont vraies.

Synthèse

• gérer Oracle Clusterware
• comprendre les techniques de sauvegarde et de
récupération du registre OCR
• gérer les paramètres réseau



• vérifier, démarrer et arrêter Oracle Clusterware
• ajouter et supprimer des fichiers de configuration Oracle
Clusterware
• effectuer une sauvegarde des registres OCR et OLR




Module 4-1 Ajouter et supprimer

des répertoires d'origine Oracle Clusterware


Objectifs
A la fin de ce module, vous pourrez :

• effectuer les opérations prérequises avant d'étendre
un cluster
• utiliser addNode.sh pour ajouter un noeud à un cluster
• supprimer un noeud d'un cluster


Ajouter des répertoires d'origine

Oracle Clusterware
Le script shell addNode.sh est utilisé pour ajouter des noeuds

à un environnement Oracle Clusterware existant.
Caractéristiques :
• Il s'exécute sans interface graphique.
• Il n'effectue pas les tâches prérequises pour le système
d'exploitation.

GRID HOME GRID HOME
Système Système
d'exploitation d'exploitation
Stockage
Ajouter des répertoires d'origine Oracle Clusterware

8QWU RQWXG\ WVKNKUGT FKHHÃTGPVGU OÃVJQFGU pour ajouter et supprimer des noeuds dans un
environnement Oracle Clusterware :
• Procédures automatiques de clonage : Copiez les images d'une installation Oracle
Clusterware sur d'autres noeuds afin de créer des nouveaux clusters présentant la même
configuration matérielle, à l'aide du script clone.pl.
• Enterprise Manager Grid Control : Fournit une interface graphique et des assistants
automatisés aux procédures de clonage.
• addNode.sh : Appelle un sous-ensemble des fonctionnalités OUI.
• Procédure de suppression de noeud : Supprime un noeud d'un cluster.
Dans ce module, vous allez étudier l'utilisation de addNode.sh et de la procédure de
suppression de noeud. Une attention particulière doit être accordée aux procédures car
certaines étapes sont exécutées sur les noeuds existants, tandis que d'autres sont exécutées
sur les noeuds qui sont ajoutés ou supprimés.
Remarque : Dans ce chapitre, il est supposé que host01 et host02 sont les noeuds
existants, et que host03 est le noeud qui est ajouté ou supprimé.

Opérations requises avant d'exécuter addNode.sh

Pour les étapes suivantes, il est supposé que vous disposez d'une
installation réussie de Linux et d'Oracle Clusterware.
1. Etablissez les connexions physiques : réseau, stockage, et autres.
2. Installez le système d'exploitation.
3. Effectuez les tâches prérequises avant l'installation d'Oracle
Clusterware :
A. Vérifiez les caractéristiques du système.
B. Vérifiez la configuration réseau requise.

C. Installez les packages requis pour le système d'exploitation.
D. Définissez les paramètres du noyau.
E. Créez des groupes et des utilisateurs.
F. Créez les répertoires nécessaires.
G. Configurez les limites du shell du propriétaire de l'installation.
H. Configurez SSH (Secure Shell) et activez l'équivalence des
utilisateurs.

Le script addNode.sh est utilisé pour étendre une installation Oracle Clusterware existante
sur d'autres noeuds. Avant d'exécuter le script addNode.sh, il est nécessaire d'effectuer
plusieurs opérations. A l'étape 1, le nouveau noeud doit être connecté physiquement à
l'infrastructure réseau existante du cluster afin d'inclure les connexions publiques, privées, de
stockage et autres qui peuvent exister. Rappelez-vous que tous les noeuds doivent utiliser les
mêmes noms d'adaptateur pour les interfaces publiques et privées. A l'étape 2, configurez une
image clonée du système d'exploitation installé sur les autres noeuds du cluster, comprenant
les patches de service, les pilotes et les modifications de configuration. S'il n'est pas possible
de réaliser cette image, il est nécessaire d'appliquer au nouveau noeud les différentes
modifications qui ont été exécutées lors de l'installation d'Oracle Clusterware, à l'étape 3.
La tâche prérequise correspondant au provisionnement du stockage n'est pas listée, car elle a
été effectuée par les noeuds existants. Vous devez vous assurer que SSH (Secure Shell ) est
configuré pour s'exécuter sans invite pour les noms d'hôte, qu'ils soient qualifiés ou non. Cela
implique de mettre à jour les fichiers authorized_keys et known_hosts des noeuds
existants en plus de ceux des noeuds ajoutés.
Selon la méthode utilisée pour transférer le système d'exploitation sur le nouveau noeud,
certaines tâches de l'étape 3 peuvent avoir été exécutées. Dans ce cas, il suffit de vérifier leur
réalisation.

4. Vérifiez l'installation des noeuds existants avec l'utilitaire de

vérification de cluster (cluvfy).
A. Procédez à une vérification postinstallation du matériel et du
[grid@host01]$ cluvfy stage –post hwos –n host03

B. Comparez en détail les propriétés du nouveau noeud et
celles d'un noeud existant de référence.
[grid@host01]$ cluvfy comp peer -refnode host01 \
-n host03 -orainv oinstall -osdba asmdba -verbose
Opérations requises avant d'exécuter addNode.sh (suite)

Nous avons vu différentes méthodes de lancement de l'utilitaire de vérification de cluster
(cluvfy). Des informations détaillées sur cluvfy sont fournies dans le chapitre "Dépanner
Oracle Clusterware". A l'étape 4, vous lancez cluvfy à partir d'un noeud existant (host01)
pour effectuer une vérification du matériel et du système d'exploitation sur le nouveau noeud
(host03). Ensuite, toujours avec cluvfy, vous comparez en détail les propriétés du
nouveau noeud et celles d'un noeud de référence existant. Si des erreurs sont repérées lors de
ces vérifications, elles doivent être corrigées avec le script addNode.sh avant de
poursuivre.
Dans les exemples de la diapositive, host01 est un noeud existant et host03 est le
nouveau noeud ajouté.

Ajouter un noeud avec addNode.sh
1. Vérifiez qu'Oracle Clusterware est installé sur au moins

un noeud.
2. Vérifiez l'intégrité du cluster et du noeud à ajouter
(host03) avec :
[grid@host01] cluvfy stage -pre nodeadd -n host03
3. Si vous n'utilisez pas Grid Naming Service (GNS), lancez

le script addNode.sh en utilisant la syntaxe suivante pour
ajouter host03 sur un cluster existant :
[grid@host01]$ cd /Grid_Home/oui/bin
[grid@host01]$ ./addNode.sh –silent \
"CLUSTER_NEW_NODES={host03}" \
"CLUSTER_NEW_VIRTUAL_HOSTNAMES={host03-vip}"
Ajouter un noeud avec addNode.sh

Le script addNode.sh est utilisé pour étendre le logiciel Oracle Clusterware d'un noeud
existant vers les nouveaux noeuds ajoutés au cluster. Si l'option "silent" n'est pas utilisée, le
script addNode.sh requiert la définition de la variable d'environnement DISPLAY. Sinon,
aucune fenêtre graphique n'est affichée. Si vous n'utilisez pas GNS, pour un cluster
comprenant les noeuds host01 et host02, ajoutez un nouveau noeud host03 comme suit :
[grid@host01]$ ./addNode.sh -silent
"CLUSTER_NEW_NODES={host03}"
"CLUSTER_NEW_VIRTUAL_HOSTNAMES={host03-vip}"
A la fin du script addNode.sh, des instructions expliquent comment lancer plusieurs scripts
sur les noeuds sélectionnés pour le compte de l'utilisateur root. Chaque script a un nom
différent, se trouve dans un répertoire différent et s'exécute sur un noeud différent. N'exécutez
pas ces scripts en parallèle. Les instructions se présentent comme suit :
The following configuration scripts need to be executed as the
"root" user in each cluster node.
/u01/app/11.2.0/grid/root.sh #On nodes gr7214
To execute the configuration scripts:
1. Open a terminal window
2. Log in as "root"
3. Run the scripts in each cluster node

Terminer l'ajout de noeud en mode silencieux
4. Vérifiez l'intégrité du cluster.

[grid@host01]$ cluvfy stage –post nodeadd –n host03
-verbose

Terminer l'ajout de noeud en mode silencieux

A l'étape 4, contrôlez l'intégrité du cluster pour vérifier que l'ajout du noeud a réussi.

Supprimer un noeud du cluster
La procédure de suppression d'un noeud comprend plusieurs étapes.

• Vous ne pouvez pas simplement supprimer le noeud du cluster.
• Le module Oracle Central Inventory situé sur chaque noeud a
des informations sur tous les noeuds.
• Le module Oracle Cluster Registry (OCR) contient aussi des
informations sur tous les noeuds.

host03
host03 host03
GRID HOME GRID HOME GRID HOME
Système Système Système

d'exploitation d'exploitation d'exploitation
host03 Stockage

Sur chaque noeud du cluster, le module Oracle Central Inventory contient des informations
sur l'ensemble des noeuds. Le registre OCR et le disque votant contiennent aussi des
informations sur chaque noeud du cluster. Par conséquent, pour supprimer un noeud
correctement, il est nécessaire d'effectuer plusieurs opérations. Vous ne pouvez pas
simplement supprimer le noeud. La procédure de suppression d'un noeud comprend
plusieurs étapes.
La suppression d'un noeud du cluster est un processus en plusieurs étapes. Certaines
commandes sont exécutées sur le noeud à supprimer tandis que d'autres commandes doivent
être lancées sur un noeud existant du cluster. Certaines commandes sont exécutées par
l'utilisateur root tandis que d'autres sont lancées par le propriétaire du logiciel Oracle
Clusterware. Les arguments fournis à une commande peuvent être le noeud existant, le noeud
à supprimer, ou encore la liste complète des noeuds restants. Il convient d'effectuer la
procédure avec attention afin d'éviter toute erreur.

1. Vérifiez l'emplacement du répertoire d'origine

d'Oracle Clusterware.
2. Sur l'un des noeuds qui sera conservé, exécutez
l'instruction suivante en tant que root pour mettre fin
au bail CSS (Cluster Synchronization Service) sur le
noeud à supprimer :

[root@host01]# crsctl unpin css -n host03
3. Exécutez le script rootcrs.pl en tant que root à partir

du répertoire Grid_home/crs/install sur chaque
noeud à supprimer :
[root@host03]# ./rootcrs.pl -delete -force

Si vous exécutez un cluster dynamique Grid Plug and Play (GPnP) en utilisant &*%2

&[PCOKE*QUV%QPHKIWTCVKQP2TQVQEQN et GNS, passez à l'étape 3.
Etape 1 : Vérifiez l'emplacement du répertoire d'origine d'Oracle Clusterware. Ce répertoire
doit être cohérent sur tous les noeuds.
Etape 2 : Mettez fin au bail CSS sur le noeud à supprimer. La commande crsctl unpin
échoue lorsque CSS n'est pas en cours sur le noeud à supprimer. Exécutez la commande
olsnodes –s –t pour voir si le noeud est actif ou localisé (opération pin). Si le noeud
n'est pas localisé, passez à l'étape 3.
Remarque : Vous ne pouvez pas exécuter une opération unpin sur un noeud qui comporte
une instance RAC (Real Application Clusters) d'une version antérieure à 11.2.0 si vous avez
installé la version 11.2 d'Oracle Clusterware 11g sur ce noeud.
Etape 3 : Désactivez les applications et les démons Oracle Clusterware qui s'exécutent sur le
noeud. Ensuite, si vous exécutez un cluster dynamique Grid Plug and Play utilisant DHCP et
GNS, passez à l'étape 4.
Remarque : Cette procédure suppose que le noeud à supprimer est accessible. Si vous ne
pouvez pas exécuter de commandes sur ce noeud, vous devez arrêter et supprimer
manuellement la ressource VIP en utilisant les commandes suivantes en tant qu'utilisateur
root sur l'un des noeuds conservés :
# srvctl stop vip -i vip_name -f
# srvctl remove vip -i vip_name -f
où vip_name est N CFTGUUG +2XKTVWGNNG
8+2 du noeud supprimé.

4. A partir de l'un des noeuds conservés, supprimez le noeud

du cluster à l'aide de la commande suivante exécutée en
tant qu'utilisateur root:
[root@host01]# crsctl delete node -n host03
5. Sur le noeud à supprimer, en tant qu'utilisateur qui a

installé Oracle Clusterware, exécutez la commande
suivante à partir du répertoire Grid_home/oui/bin :
[grid@host03]$ ./runInstaller -updateNodeList
ORACLE_HOME=Grid_Home "CLUSTER_NODES=
{host03}" CRS=TRUE -local
Supprimer un noeud du cluster (suite)

Etape 4 : En tant qu'utilisateur root, supprimez le noeud du cluster à partir de l'un des
noeuds conservés. Ensuite, si vous exécutez un cluster dynamique Grid Plug and Play utilisant
DHCP et GNS, passez à l'étape 7.
Etape 5 : En tant qu'utilisateur qui a installé Oracle Clusterware sur le noeud à supprimer,
exécutez la commande suivante :
[grid@host03]$ cd $Grid_Home/oui/bin
[grid@host03]$ ./runInstaller –updateNodeList \
ORACLE_HOME=Grid_Home "CLUSTER_NODES={host03}" CRS=TRUE -
local


6. Sur le noeud à supprimer, exécutez la commande
runInstaller en tant qu'utilisateur qui a installé Oracle
Clusterware.
A. Si vous disposez d'un répertoire d'origine partagé :
[grid@host03]$ ./runInstaller -detachHome
ORACLE_HOME=/u01/app/11.2.0/grid
B. Si le répertoire d'origine n'est pas partagé, désinstallez
le répertoire d'origine d'Oracle Clusterware :

[grid@host03]# ./deinstall –local
7. Sur un noeud restant, mettez à jour la liste des noeuds
en tant que propriétaire du logiciel Oracle Grid :
[grid@host01]$ cd /Grid_home/oui/bin
[grid@host01]$ ./runInstaller -updateNodeList \
ORACLE_HOME=/u01/app/11.2.0\grid \
"CLUSTER_NODES={host01,host02}" CRS=TRUE

Etape 6 :
A. Pour un répertoire d'origine partagé du répertoire Grid_home/oui/bin, en tant que
propriétaire du clusterware :
[grid@host03]$ ./runInstaller -detachHome
ORACLE_HOME=/u01/app/11.2.0/grid
B. Pour un répertoire d'origine non partagé du répertoire Grid_home/deinstall,
en tant que propriétaire du logiciel Oracle Grid :
[grid@host03]# ./deinstall –local
Avertissement : La commande deinstall –local peut endommager l'installation
du cluster.
Etape 7 : Sur un noeud restant, mettez à jour la liste des noeuds. Exécutez la commande
suivante en tant que propriétaire du logiciel Oracle Grid :
[grid@host01]$ /Grid_Home/oui/bin/runInstaller \
-updateNodeList ORACLE_HOME=/u01/app/grid \
"CLUSTER_NODES={host01,host02}" CRS=TRUE

Supprimer un noeud d'un cluster

(utilisation de GNS)
Si votre cluster utilise GNS, effectuez les opérations suivantes
(étapes de la procédure précédente) :
3. Exécutez le script rootcrs.pl en tant qu'utilisateur root
à partir du répertoire Grid_home/crs/install sur
chaque noeud à supprimer.
4. A partir de l'un des noeuds conservés, supprimez le noeud

du cluster.
7. Sur un noeud restant, mettez à jour la liste des noeuds en
tant que propriétaire du logiciel Oracle Grid.
Supprimer un noeud d'un cluster (utilisation de GNS)

Dans le cas d'un cluster dynamique Grid Plug and Play utilisant DHCP et GNS, la procédure
de suppression d'un noeud du cluster est plus simple. Exécutez simplement les étapes 3, 4 et 7
de la procédure précédente.

8. Sur un noeud restant, vérifiez que les noeuds indiqués ont

été supprimés du cluster.
[grid@host01]$ cluvfy stage -post nodedel –n
host03 [-verbose]


A l'étape 8, exécutez la commande cluvfy pour vérifier que les noeuds indiqués ont été
supprimés du cluster. En général, cette commande vérifie que les informations de
configuration d'interface propres aux noeuds ont été supprimées, que les noeuds ne font plus
partie de la configuration du cluster et qu'un nettoyage #5/
#WVQOCVKE5VQTCIG
/CPCIGOGPVapproprié a été exécuté.

Quiz
Le script addNode.sh peut générer des scripts permettant

de corriger les prérequis pour les noeuds ajoutés à un cluster
existant.
1. Vrai
2. Faux

Réponse : 2
Non, addNode.sh nécessite que le noeud à ajouter soit configuré correctement. L'utilitaire
cluvfy peut être utilisé pour générer des scripts correctifs.

Synthèse
Ce module vous a permis d'apprendre à :

• effectuer les opérations prérequises avant d'étendre
un cluster
• utiliser addNode.sh pour ajouter un noeud à un cluster
• supprimer un noeud d'un cluster



à Oracle Clusterware
Module 4-2 Appliquer des patches

Objectifs
A la fin de ce module, vous pourrez :

• décrire les types de patch et de mise à niveau disponibles
• concevoir des mécanismes d'application de paches et de
mises à niveau non simultanés
• comparer les versions logicielles à la version active
• installer un jeu de patches avec l'utilitaire Oracle Universal

Installer (OUI)
• installer un patch avec l'utilitaire opatch

Mise à niveau "out-of-place" d'Oracle Clusterware
• Oracle Clusterware 11g Release 2 permet seulement les mises à

niveau "out-of-place".
– Une mise à niveau "in-place" est installée dans le répertoire d'origine
existant de Clusterware et remplace l'ancienne version du logiciel.
– Une mise à niveau "out-of-place" conserve les deux versions de
Clusterware sur des noeuds distincts, dans des répertoires Grid home
différents, mais une seule est active.
• Installez Oracle Clusterware dans un répertoire d'origine distinct

avant la mise à niveau afin de réduire le temps d'arrêt du cluster.
• Les valeurs en cours de la version du logiciel et de l'emplacement
Grid home sont stockées dans le registre OCR.
• Il existe une version active au niveau cluster qui indique la version
des protocoles de communication et les structures de données des
disques partagés utilisés par le cluster.
Mise à niveau "out-of-place" d'Oracle Clusterware

Oracle Clusterware 11g Release 2 permet seulement les mises à niveau "out-of-place".
Dans ce type de mise à niveau, le nouveau logiciel est placé dans un répertoire d'origine
Oracle Clusterware distinct. Dans les versions antérieures, les mises à niveau étaient
exécutées "in-place". La nouvelle version du logiciel était installée dans le répertoire d'origine
du logiciel existant ou actif. Avec la mise à niveau "out-of-place", les deux versions du
logiciel sont présentes sur les noeuds en même temps, dans des répertoires Grid home
distincts, mais une seule est active.
L'installation d'Oracle Clusterware dans un répertoire d'origine distinct avant la mise à niveau
réduit la durée d'indisponibilité prévue pour les mises à jour de cluster, ce qui permet de
mieux répondre aux exigences du contrat de niveau de service. Une fois le logiciel installé,
vous pouvez effectuer la mise à niveau du cluster en arrêtant l'ancienne version du logiciel et
en démarrant la nouvelle noeud par noeud (on parle de mises à niveau non simultanées).
Chaque noeud tient à jour un paramètre de version qui indique la version d'Oracle
Clusterware active sur la machine. La version du logiciel est stockée dans le registre OCR.
Il existe aussi une version active au niveau cluster qui indique la version des protocoles de
communication et les structures de données des disques partagés utilisés par le cluster.

Mise à niveau d'Oracle Clusterware

Mise à niveau d'Oracle Clusterware

Oracle Database 11g Release 2 OUI permet d'effectuer une mise à niveau "out-of-place"
d'Oracle Clusterware. La page "Specify Installation Location" est affichée. Le champ Specify
Location field n'est pas en lecture seule, comme le montre le graphique de la diapositive
ci-dessus. Vous pouvez y indiquer un nouveau répertoire situé sous le répertoire Oracle base
qui sera la cible de la nouvelle version d'Oracle Clusterware.

Types de patch
• Jeu de patches CRS :

– Est installé avec l'utilitaire OUI
– Est nommé selon la convention suivante : 10.2.0.4.0,11.1.0.7.0,11.2.0.1
– Fait l'objet d'un test de régression complet et peut contenir des centaines
de correctifs
– Est cumulatif pour chaque version de base
• Regroupement de patches CRS (BP - Bundle Patch) :

– Est installé avec l'utilitaire opatch
– Est nommé selon la convention suivante : 11.1.0.6 .0 BP#1, BP#2, BP#3
– Fait l'objet d'un test de régression complet et peut contenir 20–30 patches
– Est cumulatif pour chaque BP au même niveau de jeu de patches
• Patch ponctuel ou patch MLR (Merge Label Request) CRS :
– Est installé avec l'utilitaire opatch
– Contient généralement des correctifs de priorité 1 qui ne sont pas encore
inclus dans un regroupement
Types de patch
Il existe différents types de patch disponibles pour Oracle Clusterware. Le premier type est le
jeu de patches. Il s'agit d'un ensemble de patches fournis en complément d'une version de base
(par exemple, 10.2.0.1 .0 ou 11.1.0.2 .0). Un jeu de patches incrémente le quatrième chiffre du
numéro de version. Il inclut des mises à jour pour Oracle Clusterware et pour Oracle RDBMS.
Vous devez mettre à niveau Oracle Clusterware avant Oracle RDBMS. Il est possible
d'appliquer un patch à Oracle Clusterware sans l'appliquer à RDBMS, mais l'inverse n'est pas
vrai. Les jeux de patches sont mis à disposition moins fréquemment que d'autres types de
patches. Ils sont cumulatifs et peuvent contenir des centaines de correctifs. L'utilitaire Oracle
Universal Installer (OUI) est toujours employé pour installer les jeux de patches.
Le deuxième type courant de patch disponible pour Oracle Clusterware est appelé le
regroupement de patches (BP - Bundle Patch) CRS. Il s'agit d'un petit groupe de correctifs,
généralement 20 à 30, qui a fait l'objet d'un test de régression complet et est fourni plus
fréquemment que les jeux de patches. Chaque regroupement CRS présentant le même niveau
de jeu de patches est cumulatif pour ce niveau uniquement. La convention d'appellation est
11.1.0.6.0 BP#1, 11.1.0.6.0 BP#2, et ainsi de suite. Lorsque le niveau de jeu de patches est
incrémenté, la numérotation des patches du regroupement CRS est initialisée. Les patches
d'un regroupement CRS sont toujours appliqués à l'aide de l'utilitaire opatch plutôt qu'avec
OUI. Les regroupements de patches sont des fichiers binaires qui n'ont pas besoin d'une
réédition de liens.

Types de patch (suite)

Le dernier type de patch pouvant être appliqué à Oracle Clusterware est appelé patch ponctuel
(one-off) ou patch MLR (Merge Label Request) CRS. Il s'installe avec l'utilitaire opatch et
contient des correctifs de priorité 1 qui ne sont pas encore inclus dans un regroupement. Il
peut comprendre plusieurs corrections.

Propriétés des patches

• Les mises à niveau et les jeux de patches sont installés de manière
non simultanée.
• Les regroupements de patches peuvent utiliser les procédures
minimisant les temps d'arrêt. La plupart des regroupements de patches
peuvent être appliqués de manière non simultanée.
• La plupart des patches individuels peuvent aussi être appliqués de
manière non simultanée.
• Depuis la version 11.2.0.2, les regroupements de patches peuvent être
installés "in-place" ou "out-of-place".

Type de patch Outil Méthode Mises à niveau
non simultanées
Jeu de patches OUI Out-of-place Oui
Regroupement de OPatch/Enterprise Manager In-place La plupart (à vérifier)

patches
Patches ponctuels OPatch/Enterprise Manager In-place La plupart (à vérifier)
Propriétés des patches

En fonction de leur type, les patches peuvent être installés avec différents outils et selon
différentes méthodes.
Les jeux de patches peuvent être appliqués de manière non simultanée, avec OUI (Oracle
Universal Installer). Ils sont installés en mode "out-of-place".
Les regroupements de patches peuvent être installés via Enterprise (EM) ou OPatch. Même
EM Database Control peut être utilisé pour corriger les logiciels Oracle Clusterware et
RDBMS. Les regroupements de patches sont installés "in-place". La plupart peuvent être
appliqués de manière non simultanée, mais il convient de le vérifier dans le fichier
README.txt correspondant ou dans les métadonnées du patch.
Les patches ponctuels peuvent être installés "in-place" avec EM ou OPatch. De même que les
regroupements de patches, la plupart des patches ponctuels peuvent être installés de manière
non simultanée s'ils ont été définis ainsi. Un patch ou un regroupement de patches ne peut pas
être utilisé de manière non simultanée s'il n'a pas le label approprié.
Tous les patches ponctuels et tous les regroupements de patches peuvent utiliser la méthode
minimisant le temps d'arrêt.
L'utilisation d'Enterprise Manager pour installer des patches est traitée en détail dans le
manuel Oracle Database 2 Day + Real Application Clusters Guide 11g Release 2.

Configurer la bibliothèque de logiciels
Utilisez la page Provisioning d'Enterprise Manager.

• Ajoutez l'emplacement de la bibliothèque de logiciels :

Configurer la bibliothèque de logiciels

Pour utiliser les fonctionnalités d'application de patches d'Enterprise Manager, vous
configurez l'emplacement de la bibliothèque de logiciels, également appelé cache de patches.
Vous pouvez disposer d'un ou plusieurs emplacements de bibliothèque. C'est dans ce
répertoire que les patches seront stockés au cours de leur transfert vers le cluster local.
Pour accéder à la page Provisioning à partir de la page Database - Home :
1. Cliquez sur l'onglet Software and Support.
2. Dans la section Deployment Procedure Manager, cliquez sur le lien Deployment and
Provisioning Software Library.
Dans la page Provisioning, vous retrouvez la section Software Library Configuration dans le
bas de la page.
L'emplacement de la bibliothèque de logiciels doit être un répertoire existant.

Configurer l'application des patches

Configurer l'application des patches

L'application des patches est plus simple lorsqu'Enterprise Manager est configuré pour se
connecter à My Oracle Support (précédemment appelé MetaLink). Les patches disponibles
peuvent être téléchargés et déployés via Enterprise Manager. La page Patching Setup est
accessible par un superutilisateur, à l'aide du bouton Setup. La configuration de l'application
des patches peut également être effectuée lors de l'installation.
Pour configurer l'application des patches, vous devez fournir les informations d'identification
et de connexion pour My Oracle Support. Cela suppose que le cluster a accès à l'URL de
recherche de patches : http:/updates.oracle.com, directement ou via un proxy. L'onglet Proxy
and Connections Settings permet de configurer la connexion Internet.

Démarrer le démon de provisionnement
Le démon de provisionnement se démarre comme suit :

$ pafctl start
Enter repository user password :
Enter interval [default 3]:
Provisioning Daemon is Up, Interval = 3

Démarrer le démon de provisionnement

Le gestionnaire de procédure de déploiement (Deployment Procedure Manager) permet de
visualiser, d'éditer, d'exécuter et de gérer les procédures de déploiement. Ces procédures
incluent les pratiques recommandées par Oracle pour différentes tâches de provisionnement.
Pour que le gestionnaire de procédures de déploiement fonctionne correctement, le travail
Provisioning Daemon doit être actif. Ce démon surveille le statut des procédures de
déploiement en cours.
La commande pafctl permet de le démarrer, de l'arrêter et d'afficher son statut.

Obtenir des patches Oracle Clusterware


Les derniers jeux de patches et regroupements de patches CRS recommandés peuvent être
téléchargés depuis le site Web My Oracle Support à partir de l'URL suivante :
http://support.oracle.com/
Une fois connecté au site Web, cliquez sur l'onglet "Patches & Updates". Pour obtenir le
dernier jeu de patches, cliquez sur le lien "Quick Links to: Latest Patchsets, Mini Packs and
Maintenance Packs". Pour localiser le dernier regroupement de patches CRS, s'il y en a un de
disponible, affichez l'onglet "Patches & Updates" et cliquez sur le lien "Oracle Database" sous
l'en-tête Recommended Patches. La page Recommended Patches Search est alors affichée.
Dans le champ Product, conservez la valeur "Oracle Database Family", modifiez la valeur du
champ Release, remplacez la valeur du champ Patch Target par la valeur "Real Application
Clusters", modifiez la valeur du champ Platform, puis cliquez sur Go. Les derniers
regroupements de patches CRS sont répertoriés, s'il en existe.


Obtenir des patches Oracle Clusterware (suite)

Les patches qui ne sont pas inclus dans un regroupement (BP - Bundle Patch) sont
généralement mis à disposition suite à une "service request" (SR) enregistrées dans Oracle
Support pour un problème particulier.
Remarque : La diapositive ci-dessus présente des exemples de regroupements de patches
pour la version 11.1.0.7. Lors de la rédaction de ce cours, il n'existait pas de regroupements
disponibles pour la version 11.2.0.

Charger des patches

Charger des patches

Lorqu'il n'existe pas de connexion directe à l'URL indiquée précédemment, il est possible de
télécharger des patches sur un ordinateur local puis de les charger dans la bibliothèque de
logiciels. Pour charger des patches dans la bibliothèque de logiciels à l'aide d'Enterprise
Manager Database Control :
1. Dans la page Database - Home, cliquez sur Software and Support.
2. Dans la page Software and Support, sélectionnez View Patch Cache sous l'en-tête
Database Software Patching.
3. Dans la page Patch Cache, cliquez sur Upload Patch. Vous accédez à la page "Create
Oracle Software Update Component".
4. Cliquez sur le bouton Browse puis accédez au répertoire où vous avez sauvegardé le
fichier de patches sur le disque. Si vous accédez à Database Control à partir d'un
navigateur qui s'exécute sur un ordinateur client, le patch doit être disponible sur cet
ordinateur client. Lorsque vous avez localisé le fichier de patch, cliquez sur son nom
pour le sélectionner, puis cliquez sur Open. Le nom du fichier est inséré dans le champ
Patch File.
5. Dans la section Patch Attributes de la page "Create Oracle Software Update
Component", entrez les informations suivantes sur le patch à charger :
- Numéro du patch
- Type de patch (individuel ou jeu de patches)
- Date de création du patch

Charger des patches (suite)

- Description du patch
- Famille de produits concernée par le patch (par exemple, Oracle Database)
- Produit auquel le patch s'applique (par exemple, RDBMS Server)
- Version du produit
- Plate-forme sur laquelle s'exécute la base de données
- Langue utilisée (par exemple, anglais américain)
- (Facultatif) Description du patch
Vous pouvez trouver la plupart de ces informations dans le fichier README du jeu de
patches.
6. Lorsque vous avez terminé d'écrire les informations, sélectionnez "Add Patch File to

Patch Cache" et cliquez sur le bouton Upload. La page Patch Cache apparaît de
nouveau, avec un message de confirmation.
7. Le patch figure désormais dans la mémoire cache destinée aux patches.

Gestionnaire de procédure de déploiement

Gestionnaire de procédure de déploiement

La page "Deployment Procedure Manager" présente plusieurs procédures qui peuvent être
planifiées en vue de l'application de patches.
Pour accéder à cette page, cliquez sur l'onglet Software and Support de la page
Database - Home. Dans la page Software and Support, cliquez sur Deployment Procedures.
Vous pouvez alors sélectionner une procédure et planifier un déploiement.

Appliquer des patches avec un temps d'arrêt réduit

dans les environnements de cluster
Il est possible d'appliquer des patches Oracle Clusterware
et Oracle RAC sans arrêter complètement le cluster.
• OPatch peut désormais appliquer plusieurs patches
sur plusieurs noeuds.
• OPatch détecte si le schéma de base de données est à un
niveau inférieur à celui du nouveau patch et, dans ce cas,

exécute des commandes SQL pour actualiser le schéma.
• OUI installe les jeux de patches comme des mises à
niveau "out-of-place", ce qui réduit les temps d'arrêt.
Appliquer des patches avec un temps d'arrêt réduit dans les environnements
de cluster
Il est possible d'appliquer des patches Oracle Clusterware et Oracle RAC sans arrêter
complètement le cluster. Dans de nombreux cas, cette opération n'entraîne aucun temps
d'arrêt. Cela permet également d'effectuer des mises à niveau "out-of-place" des logiciels
Oracle Clusterware et Oracle Database, ce qui réduit les temps d'arrêt de maintenance dans
un environnement Oracle RAC.
OPatch peut désormais appliquer plusieurs patches sur plusieurs noeuds. OPatch ne démarre
pas les instances sur lesquelles un patch a été appliqué en mode non simultané si les autres
instances de la base n'ont pas encore ce patch. OPatch détecte si le schéma de base de données
est à un niveau inférieur à celui du nouveau patch et, dans ce cas, exécute des commandes
SQL pour actualiser le schéma.
Vous pouvez utiliser srvctl pour arrêter le logiciel Oracle exécuté dans un répertoire
d'origine Oracle Home, en vue de l'application des patches. L'application des patches Oracle
Grid Infrastructure est effectuée automatiquement sur tous les noeuds. Il est possible
d'appliquer plusieurs patches sur plusieurs noeuds.
Pour les logiciels Grid Infrastructure (Oracle Clusterware et Automatic Storage Management)
et Oracle Database, les jeux de patches sont désormais installés comme des mises à niveau
"out-of-place". Cela réduit les temps d'arrêt requis.

Appliquer des patches de manière non simultanée

Lorsqu'un patch est installé de manière non simultanée, il est appliqué sur
un noeud pendant que les autres continuent à fournir des services.
Caractéristiques :
• Sur chaque noeud, il doit exister des répertoires d'origine distincts pour
les logiciels.
• Cette méthode permet à différentes versions de coexister temporairement.
• Elle n'est pas disponible pour tous les patches.
Logiciel non partagé Logiciel partagé

GRID HOME GRID HOME Node1 GRID HOME
Node1 Node2 Node2
Stockage FS local Stockage FS local Stockage CFS partagé
Le patch doit être appliqué

L'application non simultanée n'est
sur tous les noeuds
possible que pour certains patches.
en même temps.
Appliquer des patches de manière non simultanée

Par défaut, Oracle prend en charge la mise à niveau non simultanée pour les patches Oracle
Clusterware. Cette méthode est disponible pour les jeux de patches, les regroupements de
patches et la plupart des patches individuels. Elle permet d'actualiser un noeud avec le dernier
niveau de patch pendant que les autres noeuds continuent à utiliser la version plus ancienne
pour fournir des services métier.
L'application de patches de manière non simultanée est permise par l'utilisation d'un système
de fichiers non partagé pour stocker les fichiers de logiciel, appelé Grid home. Chaque noeud
gère sa propre copie. Lorsque cette technique est utilisée sur un cluster de 50 noeuds, il y a
50 copies du logiciel Oracle Clusterware, c'est-à-dire 50 copies nécessitant de l'espace disque
et 50 copies à mettre à jour. Elle permet d'appliquer des patches et des mises à niveau de
manière non simultanée en autorisant deux versions du cluster en même temps.
L'application de patches de manière non simultanée ne peut pas être effectuée lorsque les
fichiers du logiciel Oracle Clusterware sont stockés dans un système de fichiers clusterisé
partagé dans lequel une copie unique du logiciel est commune à tous les noeuds. Cette
configuration nécessite nettement moins d'espace disque et limite le patch ou la mise à niveau
à une seule copie. Toutefois, l'application du patch ou de la mise à niveau implique l'arrêt du
logiciel. Il faut également arrêter l'ensemble des bases de données, des applications et des
services qui dépendent d'Oracle Clusterware. Cette technique implique donc des temps d'arrêt.
Remarque : Il se peut qu'un jeu de patches puisse être appliqué de manière non simultanée
pour Oracle Clusterware, mais pas pour RDBMS.

Vérifier les versions d'un logiciel
• Lors de l'application de patches de manière non

simultanée, la version disponible sur un noeud peut
temporairement être plus récente que la version active.
– Pour vérifier la version du logiciel sur un noeud :
$ crsctl query crs softwareversion [hostname]

– Pour vérifier la version active du cluster :
• La présence de différentes versions n'est admise que

pendant l'application d'un patch.
Vérifier les versions d'un logiciel

Lors de l'application d'un patch ou d'une mise à niveau de manière non simultanée, deux
versions du logiciel peuvent temporairement coexister dans le cluster. La version du logiciel
est la dernière version qui est installée sur un noeud particulier. Vous pouvez vérifier le
numéro de version stocké dans le registre OCR à l'aide de la commande suivante :
$ crsctl query crs softwareversion
Oracle Clusterware version on node [host01] is [11.1.0.7.0]
La version active est celle qui possède le numéro le plus faible dans le cluster. Cela s'applique
au cluster, et non à un noeud spécifique. La version active n'est pas mise à jour tant qu'il
existe un noeud qui ne dispose pas de la dernière version. Vous pouvez vérifier la version
active à l'aide de la commande suivante :
Oracle Clusterware active version on the cluster is
[11.1.0.6.0]
Il n'est pas possible d'utiliser différentes versions d'Oracle Clusterware simultanément de
manière permanente. Cela n'est autorisé que pendant une courte durée, c'est-à-dire pendant
l'application du patch ou du jeu de patches aux noeuds du cluster.
Remarque : La version d'Oracle Clusterware doit être supérieure à la version d'autres
produits Oracle tels que RAC (Real Application Clusters) et ASM.

Installer un jeu de patches de manière

non simultanée à l'aide d'OUI
Sur un noeud de cluster, procédez comme suit :
1. Lisez les dernières informations concernant le jeu de
patches.
2. Arrêtez toutes les applications qui dépendent d'Oracle
Clusterware.
3. Arrêtez les applications Oracle Clusterware sur le noeud, en

transférant l'adresse IP virtuelle (VIP) vers un autre noeud.
$ srvctl stop nodeapps -n host01 -r
4. Démarrez la version la plus récente d'OUI à partir du jeu

de patches.
$ cd patchset_directory/Disk1
$ ./runInstaller
Installer un jeu de patches de manière non simultanée à l'aide d'OUI

Après avoir téléchargé le dernier jeu de patches, décompressez-le dans un répertoire
accessible par le premier noeud concerné. Ce jeu ne doit pas nécessairement se trouver dans
un système de fichiers partagé. L'installeur le distribuera sur les autres noeuds du cluster.
Etape 1 : Lisez les notes relatives à la plate-forme utilisée. Chaque jeu de patches est propre à
une plate-forme de système d'exploitation et doit contenir des notes concernant celle-ci. La
procédure décrite ici est générique. Elle peut comprendre des étapes différentes pour certains
systèmes d'exploitation.
Etape 2 : Il est nécessaire d'arrêter sur le premier noeud toutes les applications qui dépendent
d'Oracle Clusterware telles que les instances de base de données, les processus d'écoute de
base de données, les instances ASM, et autres. L'administrateur de base de données peut
choisir de désactiver les mécanismes de connexion sur le premier noeud, de déconnecter les
utilisateurs actuellement liés à ce noeud, de les reconnecter et de les distribuer sur d'autres
noeuds avant d'arrêter les applications.
Etape 3 : Arrêtez les applications Oracle Clusterware sur le noeud à l'aide de l'utilitaire
srvctl comme illustré dans la diapositive. L'option –r déplace l'adresse IP virtuelle (VIP)
vers d'autres noeuds pour éviter les dépassements de délai d'attente de connexion.
Si le registre OCR et les disques votants figurent dans ASM, utilisez la commande
crsctl stop crs.

Installer un jeu de patches de manière non simultanée à l'aide d'OUI (suite)

Etape 4 : Exécutez toujours la dernière version provenant de la distribution décompressée
de l'installeur plutôt que l'ancienne version figurant dans le logiciel de clusterware existant.
OUI permet d'installer des jeux de patches et doit être appelé à partir d'une session graphique.
L'utilitaire OUI doit être appelé par le compte utilisateur possédant le logiciel Oracle
Clusterware, et non par l'utilisateur root.

Installer un jeu de patches avec OUI

Installer un jeu de patches avec OUI

Remarque : Les instructions fournies dans cette page sont générales car il n'existait pas de
jeux de patches disponibles pour Oracle 11g Release 2 lors de la rédaction du cours. Vérifiez
les informations livrées avec chaque jeu de patches.
Appelez OUI à partir du répertoire des jeux de patches et suivez les instructions affichées.
Dans la fenêtre Welcome, vous pouvez vérifier la liste de tous les produits qui sont
actuellement installés sur la machine en cliquant sur le bouton Installed Products. Cliquez sur
le bouton Next pour installer le jeu de patches.
Dans la fenêtre Source, vous pouvez indiquer le répertoire dans lequel le jeu de patches
réside. La fenêtre Install Location vous invite à préciser le répertoire Oracle Base, ainsi que le
nom et l'emplacement du répertoire Oracle Home. Les valeurs par défaut dépendent des
variables d'environnement qui sont définies et des applications actuellement installées. Une
fenêtre de sélection de produit peut apparaître si le jeu contient des patches pour RDBMS et
Oracle Clusterware.
Pour un cluster existant, tous les noeuds sont automatiquement sélectionnés dans la fenêtre
Specify Hardware Cluster Installation Mode et il n'est pas possible d'apporter des
modifications. Le logiciel est distribué sur chaque noeud du cluster, et aucune autre action
n'est effectuée sur les noeuds qui continuent à fournir des services métiers.
Dans la page récapitulative, tous les noeuds sont également répertoriés, mais la distribution du
logiciel est la seule action qui est exécutée sur les autres noeuds. .GUCWVTGU PQGWFU RGWXGPV
EQPVKPWGT´ GZÃEWVGT NCEQWEJG 1TCENG%NWUVGTYCTG GVNGUCRRNKECVKQPUCUUWTCPV CKPUK NC
EQPVKPWKVÃ FW UGTXKEGLWUSW ´ EG SW KNU UQKGPV RTÄVU ´ ÄVTG CTTÄVÃU.

Installer un jeu de patches de manière

non simultanée à l'aide d'OUI
En tant qu'utilisateur root, effectuez les opérations suivantes
sur un noeud du cluster :
5. Arrêtez les démons Oracle Clusterware et Oracle.
# crsctl stop crs
6. Exécutez le script de mise à niveau root.

# cd /u01/app/11.2.0/grid/install
# ./root*.sh
7. Démarrez toutes les applications dépendantes qui ont été
arrêtées à l'étape 2.
8. Répétez toutes les étapes de l'étape 4 (runInstaller) sur
chaque noeud.
Installer un jeu de patches de manière non simultanée à l'aide d'OUI

Sur le premier noeud où l'installation a été effectuée, connectez-vous en tant qu'utilisateur
root et lancez l'utilitaire crsctl pour arrêter la couche Oracle Clusterware. Avant cet
arrêt, la version logicielle correspond toujours à l'ancienne version.
Une fois la couche Oracle Clusterware arrêtée, lancez le script indiqué dans les instructions
d'OUI pour effectuer la mise à niveau. Ce script redémarre la couche Oracle Clusterware à la
fin et la version logicielle correspond alors à la nouvelle version. La version active reste
l'ancienne version jusqu'à ce que tous les noeuds soient mis à jour.
Une fois la couche Oracle Clusterware redémarrée, toutes les applications dépendantes qui
ont été arrêtées sur le noeud peuvent être redémarrées. Répétez toutes les étapes sur les autres
noeuds, à l'exception de l'étape 4 (runInstaller). Le logiciel a déjà été distribué sur
chaque noeud du cluster. Les mises à jour des autres noeuds doivent être terminées
rapidement. Il n'est pas possible d'exécuter les noeuds d'un environnement Oracle Clusterware
avec différentes versions logicielles pendant un long moment.

OPatch : Présentation
OPatch est un utilitaire Java qui permet l'application et l'annulation de

patches ponctuels. Caractéristiques :
• Il est utilisé pour les regroupements de patches CRS et les patches
ponctuels.
• Il permet d'appliquer un patch de manière non simultanée à Oracle
Clusterware.
• Il gère un inventaire des patches qui sont installés.
• Il ne requiert pas une réédition de liens pour les patches CRS.

• Il est appelé pour le compte du propriétaire du logiciel Grid
Infrastructure.
• Il nécessite l'exécution de scripts spéciaux avant et après
l'application de regroupements de patches CRS :
– prerootpatch.sh (en tant que root)
– prepatch.sh (en tant que propriétaire du clusterware)
– postpatch.sh (en tant que propriétaire du clusterware)
– postrootpatch.sh (en tant que root)
OPatch : Présentation
OPatch est un utilitaire Java qui permet l'application et l'annulation de patches ponctuels à un
produit Oracle. Il n'est pas utilisé pour appliquer des jeux de patches. OPatch est inclus avec
l'installation d'Oracle Clusterware 11g. Lors de l'application de patches à une installation
Oracle Clusterware de manière non simultanée, l'utilisateur est invité à indiquer les noeuds
concernés. Un tel patch ne peut pas être activé en appelant l'outil de patch. OPatch prend
également en charge un mode minimisant le temps d'arrêt. Il tient à jour un inventaire de tous
les patches qui ont été installés.
Il convient de tenir compte de certains points lors de l'application de patches à Oracle
Clusterware. Une partie du logiciel appartient à l'utilisateur root et l'autre au compte utilisé
pour installer le produit. Pour appliquer un patch aux composants appartenant à root, il est
nécessaire de déverrouiller le clusterware en exécutant certains scripts spéciaux. Après
l'application du patch, il faut rétablir les paramètres de sécurité antérieurs en exécutant
d'autres scripts. Ces scripts se trouvent dans le répertoire des patches. Les scripts
supplémentaires sont notamment les suivants :
• prerootpatch.sh :
- Vérifie que le script est appelé pour l'utilisateur root.
- Vérifie qu'Oracle Clusterware est arrêté sur le noeud local.
- Vérifie que les paramètres corrects ont été définis.
- Déverrouille le logiciel Oracle Clusterware, transmet la propriété de certains fichiers
à un utilisateur autre que root et modifie les droits.

OPatch : Présentation (suite)

• prepatch.sh :
- Vérifie que les paramètres sont corrects.
- Modifie les droits sur les fichiers sélectionnés.
- Recherche les variables d'installation incluses dans les fichiers existants.
- Vérifie que les valeurs ont été obtenues pour les variables.
- Enregistre les variables et les valeurs dans le fichier
Grid_home/install/params.crs .
• postpatch.sh :
- Vérifie que le fichier Grid_home/install/params.crs a le format

approprié.
- Fournit les valeurs correctes à partir de params.crs.
- Initialise les droits sur les fichiers sélectionnés.
• postrootpatch.sh :
- Verrouille les exécutables et les répertoires en définissant root comme
propriétaire.
- Copie les scripts wrappers d'initialisation à l'emplacement approprié.
- Met à jour /etc/inittab afin que les nouveaux fichiers soient utilisés pour le
lancement d'Oracle Clusterware.
- Attend le démarrage d'Oracle Clusterware.

OPatch : Utilisation générale
• Pour définir la variable ORACLE_HOME ou l'option –oh

pour toutes les commandes :
$ export ORACLE_HOME=/u01/app/11.2.0/grid
$ opatch command [options]
ou
$ opatch command –oh /u01/app/11.2.0/grid [options]

• Pour obtenir de l'aide sur la syntaxe d'OPatch :
$ opatch command –help
• Pour vérifier si un patch peut être appliqué de manière

non simultanée (exécution à partir du répertoire patch) :
$ opatch query -all | grep –i Rolling
OPatch : Utilisation générale

L'utilitaire OPatch nécessite que la variable d'environnement ORACLE_HOME soit définie ou
que la valeur de ORACLE_HOME soit transmise comme argument sur la ligne de commande
avec l'option –oh. Dans le cas d'Oracle Clusterware, le paramètre ORACLE_HOME désigne le
répertoire d'installation d'Oracle Clusterware, et non l'emplacement d'autres produits Oracle
installés. En règle générale, ORACLE_HOME désigne le répertoire d'origine du produit
à patcher.
La documentation OPatch se trouve dans le répertoire Grid_home/OPatch/docs. Elle
comprend les manuels OPatch Users Guide et OPatch Prerequisite Users Guide. Pour obtenir
de l'aide sur la syntaxe de l'utilitaire, recourez à l'option –help comme suit :
opatch -help
opatch apply -help
opatch lsinventory -help
opatch rollback -help
opatch prereq -help
opatch util –help
En général, les regroupements de patches CRS et les patches ponctuels peuvent être appliqués
de manière non simultanée, c'est-à-dire noeud par noeud. Toutefois, il est toujours important
d'examiner chaque patch pour identifier les exceptions à cette règle. Pour vérifier si un patch
peut être appliqué de manière non simultanée, décompressez le patch téléchargé dans un
répertoire de votre choix et, dans ce répertoire, exécutez la commande suivante :
$ORACLE_HOME/OPatch/opatch query -is_rolling_patch <patch_location>

Avant d'appliquer des patches avec OPatch
• Vérifiez la valeur actuelle de la variable ORACLE_HOME.

• Sauvegardez le répertoire concerné à l'aide d'un utilitaire
du système d'exploitation ou Oracle Secure Backup.
• Appliquez le patch à chaque noeud.
• Mettez à jour la variable d'environnement PATH avec le
répertoire OPatch.

Avant d'appliquer des patches avec OPatch

L'utilitaire Oracle d'application de patches, OPatch, vérifie que la variable d'environnement
ORACLE_HOME désigne un répertoire existant. Vous devez vérifier que la variable
ORACLE_HOME correspond au répertoire d'origine Oracle Home du produit concerné
par le patch.
Il est recommandé de sauvegarder le répertoire du logiciel avant d'appliquer un patch. Cela
s'applique aux répertoires d'installation d'Oracle RAC, ASM ou Oracle Clusterware. La
sauvegarde doit aussi inclure le répertoire orainventory.
Si vous téléchargez le patch manuellement et utilisez Patch pour l'installer, vous devez copier
le patch sur chaque noeud. Si vous utilisez Enterprise Manager pour télécharger le patch et
que vous avez sélectionné tous les noeuds du cluster en tant que cible du patch, le patch est
automatiquement installé sur tous ces noeuds.
Le fichier binaire opatch se trouve dans le répertoire $ORACLE_HOME/OPatch. Vous
pouvez indiquer ce chemin lors de l'exécution d'OPatch, ou vous pouvez mettre à jour la
variable d'environnement PATH pour qu'elle inclue le répertoire OPatch. Pour modifier la
variable PATH sous Linux, utilisez :
$ export PATH=$PATH:$ORACLE_HOME/OPatch

Installer un patch de manière non simultanée

avec OPatch
1. Vérifiez qu'Oracle Inventory est correctement configuré.
[grid]$ opatch lsinventory -detail -oh \
/u01/app/11.2.0/grid
2. Arrêtez CRS sur le premier noeud à patcher.

[root]$ crsctl stop crs
3. Déverrouillez les fichiers protégés.

[root]# cd <patch_location>
[root]# ./custom/scripts/prerootpatch.sh -crshome\
/u01/app/11.2.0/grid -crsuser grid
4. Sauvegardez les paramètres de configuration importants.

[grid]$ ./custom/scripts/prepatch.sh –crshome\
/u01/app/11.2.0/grid
Installer un patch de manière non simultanée avec OPatch

Avec l'utilitaire OPatch, il est possible d'appliquer un patch à tous les noeuds du cluster
simultanément via une seule commande. Cependant, cela nécessite d'arrêter Oracle
Clusterware sur tous les noeuds en même temps. Pour éviter l'indisponibilité complète de la
base de données, il est possible d'appliquer les patches de manière non simultanée, d'abord sur
le noeud local d'abord, puis sur chacun des autres noeuds. Pour appliquer un patch de manière
non simultanée avec OPatch, démarrez à l'étape 1 en vérifiant qu'Oracle Inventory peut être
localisé et configuré correctement à l'aide de la commande suivante :
opatch lsinventory –detail –oh Grid_home
Si la variable d' environnement ORACLE_HOME a été définie, il n'est pas nécessaire d'inclure
l'option –oh. A l'étape 2, arrêtez la pile de processus Oracle Clusterware sur le noeud local
avec la commande suivante :
crsctl stop crs
A l'étape 3, connectez-vous en tant que root et déverrouillez les fichiers protégés à l'aide de
la commande suivante :
prerootpatch.sh –crshome Grid_home -crsuser <Grid
owner>
A l'étape 4, sauvegardez les paramètres de configuration importants pour éviter leur
écrasement par le patch, à l'aide de la commande suivante :
prepatch.sh –crshome Grid_home
Le fichier Grid_home/install/params.crs est créé.

Installer un patch de manière non simultanée

avec OPatch
5. Installez le patch CRS sur le premier noeud uniquement.
[grid]$ opatch apply -local -oh Grid_home\
patch location
6. Appliquez les paramètres de configuration aux fichiers patchés.

[grid]$ ./custom/scripts/postpatch.sh -crshome\
Grid_home

7. Rétablissez les verrous des fichiers protégés.
[root]# ./custom/scripts/postrootpatch.sh\
-crshome Grid_home
8. Vérifiez l'installation du patch.
[grid]$ opatch lsinventory -detail -oh Grid_home
9. Répétez les étapes 1-8 sur chaque noeud, l'un après l'autre.
Installer un patch de manière non simultanée avec OPatch (suite)

A l'étape 5, n'appliquez le patch qu'à l'installation Grid locale sur le premier noeud, à l'aide de
la commande suivante :
opatch apply –local –oh grid_home patch_location
"patch_location" est le répertoire où le patch a été décompressé. Si aucun chemin n'est
indiqué, le répertoire en cours est utilisé. A l'étape 6, appliquez les paramètres de
configuration qui ont été sauvegardés à l'étape 4 aux fichiers qui ont été modifiés par le patch,
à l'aide de la commande suivante :
postpatch.sh –crshome <grid_home>
A l'étape 7, il est nécessaire de restaurer le verrou sur Oracle Clusterware en rétablissant
root comme propriétaire des fichiers sélectionnés, et en redéfinissant les droits appropriés
en exécutant la commande suivante en tant que root :
postrootpatch.sh –crshome Grid_home
A l'étape 8, vérifiez l'installation du patch à l'aide de la commande suivante :
opatch lsinventory –detail –oh Grid_home
Les huit étapes peuvent alors être répétées sur chaque noeud du cluster, l'un après l'autre,
afin d'appliquer le patch.
Remarque : Un patch peut contenir des correctifs pour Grid et pour RDBMS. Consultez le
fichier README.txt du patch pour obtenir des instructions supplémentaires.

Installer un patch avec une période d'arrêt

minimale en utilisant OPatch
Actions :
• Le noeud local est toujours patché en premier.
• Le noeud local est utilisé comme base pour l'application du patch
aux autres noeuds.
• L'utilisateur est invité à indiquer le premier ensemble de noeuds
à patcher.
• Pour chaque noeud du premier ensemble :

– Arrêtez l'instance.
– Le patch est propagé.
– Appliquez le patch au noeud.
• Arrêtez les noeuds restants.
• Le patch est propagé vers les noeuds restants.
• L'inventaire est mis à jour.
• Démarrez le premier ensemble avant de patcher chaque noeud
du deuxième.
Installer un patch avec une période d'arrêt minimale en utilisant OPatch

Dans le cadre de l'application de patches avec une période d'arrêt minimale, les noeuds sont
divisés en deux ensembles. Les noeuds du premier ensemble sont arrêtés et le patch leur est
appliqué. Une fois l'opération terminée, les noeuds du deuxième ensemble sont à leur tour
arrêtés. Le premier ensemble de noeuds est alors redémarré et le patch est appliqué au second
ensemble de noeuds. Une fois l'opération terminée, les noeuds sont redémarrés. Avec cette
méthode, le temps d'arrêt d'Oracle RAC est moins long que lorsque tous les noeuds sont
arrêtés en même temps.
Lorsque vous utilisez la méthode d'application de patches avec une période d'arrêt minimale,
les actions suivantes se produisent :
• Le noeud local est toujours patché en premier.
• Le noeud local est utilisé comme base pour l'application du patch aux autres noeuds.
• L'utilisateur est invité à indiquer le premier ensemble de noeuds à patcher.
• Pour chaque noeud du premier ensemble, l'utilisateur est invité à arrêter l'instance et le
patch est propagé et appliqué au noeud.
• Lorsque le premier ensemble des noeuds a été patché, l'utilisateur est invité à arrêter les
noeuds restants.
• Les instances sont arrêtées sur les noeuds du deuxième ensemble.
• Le patch est propagé au dernier ensemble de noeuds et l'inventaire est mis à jour.
• Vous pouvez démarrer les noeuds patchés (le premier ensemble de noeuds) avant de
modifier les noeuds restants.

Quiz
Quels outils peuvent être utilisés pour installer un jeu

de patches ?
1. Oracle Universal Installer
2. OPatch
3. Enterprise Manager Database Console
4. Database Configuration Assistant

Réponses : 1, 2
Dans Oracle 11g Release 2, il est possible d'utiliser Oracle Universal Installer ou Enterprise
Manager Database Console.

Quiz
L'application de patches dans un environnement Oracle

Clusterware nécessite une attention particulière concernant
le propriétaire et les droits.
1. Vrai
2. Faux

Réponse : 1
Le répertoire d'origine Oracle Home pour Oracle Clusterware et plusieurs fichiers du
répertoire appartiennent à l'utilisateur root. Il est nécessaire de modifier le propriétaire
et les droits avant d'appliquer un patch, puis de les rétablir dans leur état d'origine.

Synthèse
Ce module vous a permis d'apprendre à :

• décrire les types de patch disponibles
• appliquer des patches de manière non simultanée
• comparer les versions logicielles à la version active
• installer un jeu de patches avec l'utilitaire Oracle Universal
Installer (OUI)

• installer un patch avec l'utilitaire opatch


Assurer une haute disponibilité
des applications avec Oracle Clusterware

Objectifs

• décrire les composants de haute disponibilité d'Oracle
Clusterware
• comparer les bases de données gérées par une stratégie
et les bases gérées par l'administrateur
• décrire le fonctionnement des pools de serveur

• décrire les stratégies d'affectation des applications
• créer une adresse IP virtuelle (VIP) pour une application
• gérer les ressources applicatives

Services de haute disponibilité

Oracle Clusterware fournit des services de haute disponibilité
aux bases de données RAC (Real Application Clusters) et à
d'autres applications.
• Oracle Clusterware surveille périodiquement toutes les
applications protégées.
• En fonction de la stratégie de gestion des incidents définie,
Oracle Clusterware redémarre les applications en échec

sur le même noeud ou les déplace vers un autre noeud.
• Il peut protéger les applications Oracle et non Oracle.
Services de haute disponibilité d'Oracle Clusterware

Oracle Clusterware est une infrastructure de cluster portable fournissant des services de haute
disponibilité aux bases de données RAC et aux autres applications. Oracle Clusterware assure
la haute disponibilité des applications en surveillant leur état, en les redémarrant en cas de
panne, et en les transférant sur un autre noeud du cluster quand le noeud en cours d'utilisation
tombe en panne ou quand l'application ne peut plus s'y exécuter. En cas d'échec d'un noeud,
certains types d'application protégés, tels que les instances de base de données RAC, ne sont
pas transférés vers les noeuds restants.
Un cluster est un ensemble d'au moins deux noeuds partageant un pool de stockage commun
utilisé par les fichiers système d'Oracle Clusterware (registre OCR et disque votant), une
interconnexion réseau commune et un système d'exploitation commun.
Oracle Clusterware surveille régulièrement toutes les applications protégées et, en fonction de
la stratégie de gestion des incidents définie, il les redémarre sur le même noeud, les transfère
vers un autre noeud, ou ne les redémarre pas du tout.

Composants de haute disponibilité

Plusieurs composants sont utilisés pour implémenter la haute

disponibilité avec Oracle Clusterware.
Composant Définition
Ressource Entité contrôlée par Oracle Clusterware pour la haute
disponibilité, telle qu'une application.
Programme d'action Programme qui fournit la logique permettant de démarrer,
d'arrêter et de surveiller une ressource.

Privilèges Privilèges d'accès et d'utilisation associés à une ressource
qui permettent une exécution par un utilisateur différent de
l'utilisateur CRS (Cluster Ready Services).
Dépendance entre Relation fonctionnelle entre des ressources ou des
ressources applications.
Adresse IP virtuelle Adresse IP virtuelle dont dépend une application.
(VIP) d'application
Registre OCR Mécanisme de stockage pour les profils de ressource, les
stratégies et les privilèges
Composants de haute disponibilité d'Oracle Clusterware

Plusieurs composants sont employés conjointement pour établir un environnement de haute
disponibilité pour les applications qui utilisent Oracle Clusterware. Une ressource est une
entité contrôlée par Oracle Clusterware pour la haute disponibilité, telle qu'une application.
Il s'agit d'une notion distincte du gestionnaire de ressources (Resource Manager), un outil
Oracle Database permettant de gérer les ressources système consommées telles que la CPU
et la mémoire RAM. Les ressources pour la haute disponibilité sont définies avec un profil qui
définit les attributs et les stratégies associés à l'application. Le profil d'application identifie
également le programme d'action, qui est un programme ou un script chargé de fournir la
logique nécessaire pour démarrer ou arrêter une ressource, ou pour vérifier son statut. Par
ailleurs, le profil d'application définit les stratégies à appliquer en cas de panne. Le logiciel
Oracle Clusterware fonctionne avec les droits de l'utilisateur root ou administrator.
Les privilèges permettent à Oracle Clusterware de contrôler les composants applicatifs à
inclure pour autoriser l'application à s'exécuter dans le contexte d'un utilisateur différent de
celui de CRS (Cluster Ready Services). Les ressources peuvent dépendre d'autres ressources
pour leur exécution. Par exemple, une ressource de type base de données peut dépendre d'une
ressource de stockage. Une adresse IP virtuelle d'application (VIP) est une adresse IP virtuelle
qui peut basculer vers d'autres noeuds si les stratégies le permettent. Il s'agit d'un exemple
typique de dépendance d'application. L'adresse IP virtuelle d'une application est une
ressource. Toutes les informations relatives à une ressource sont stockées dans le fichier de
configuration OCR d'Oracle Clusterware et sont disponibles sur chaque noeud du cluster.

Options de gestion des ressources
Oracle Database 11g Release 2 offre deux types de gestion des

ressources pour les bases de données RAC :
• Configuration gérée par l'administrateur :
– Utilise un sous-ensemble du pool de serveurs prédéfini GENERIC
– Place les ressources manuellement comme indiqué par
l'administrateur de base de données
– Est la stratégie de gestion utilisée dans les versions précédentes

– Convient bien pour un petit nombre de noeuds
• Configuration gérée par une stratégie :
– Regroupe les serveurs d'un cluster dans des pools
– Contrôle l'emplacement des services par le biais de pools
de serveurs
– Est conforme à la gestion de la charge globale
– Est préférable pour un grand nombre de noeuds
Options de gestion des ressources

Il existe deux types de configuration pour la gestion des ressources d'une base de données
RAC : la configuration gérée par l'administrateur et la configuration gérée par une stratégie.
Chaque type de gestion utilise la notion de pools de serveur, qui servent à regrouper des
serveurs du cluster d'un point de vue logique.
La configuration gérée par l'administrateur est la stratégie de gestion utilisée dans les versions
antérieures. Les administrateurs de base de données définissent les serveurs sur lesquels les
ressources de base de données doivent s'exécuter et y placent manuellement les ressources en
fonction des besoins. Cette méthode utilise un sous-ensemble du pool de serveurs prédéfini
GENERIC. Elle convient pour un petit nombre de noeuds compte tenu des opérations
manuelles de positionnement.
La configuration gérée par une stratégie contrôle l'emplacement des ressources par le biais de
pools de serveurs. Les administrateurs de base de données définissent le pool de serveurs sur
lequel chaque ressource de base de données doit s'exécuter (à l'exception de GENERIC et
FREE). Oracle Clusterware est alors chargé de placer la ressource sur un serveur spécifique.
Cela évite l'affectation physique des ressources à des noeuds spécifiques du cluster. Ce type
de configuration est conforme à la gestion de la charge globale et convient mieux pour un
grand nombre de noeuds.

Pools de serveurs
Les pools de serveurs sont des regroupements logiques de serveurs

ou de noeuds d'un cluster. Caractéristiques :
• Ils permettent de répartir une charge globale uniforme entre
plusieurs serveurs du cluster.
• Ils sont alloués aux bases de données hôte ou à d'autres
ressources.
• Ils sont gérés à l'aide des commandes crsctl et srvctl.

• Il peut exister des relations parent-enfant entre les pools de
serveurs.
– Les pools de niveau supérieur sont mutuellement exclusifs.
• Deux pools de serveurs prédéfinis sont générés lors de
l'installation d'Oracle Clusterware :
– FREE : Pour les serveurs qui ne sont pas affectés à d'autres pools.
– GENERIC : Pour les configurations fixes gérées par l'administrateur
et les bases de données antérieures à la version 11g Release 2
Pools de serveurs
Les pools de serveurs sont des regroupements logiques de serveurs ou de noeuds d'un cluster.
Ils incluent généralement un sous-ensemble du nombre total de noeuds d'un cluster. Les pools
de serveurs sont alloués à des bases de données hôte ou à d'autres ressources et indiquent sur
quels noeuds ces ressources peuvent s'exécuter. Chaque nom de pool de serveurs doit être
unique au sein du cluster. Les pools de serveurs permettent de répartir une charge globale
uniforme (ensemble de ressources Oracle Clusterware) entre plusieurs serveurs du cluster. Ils
sont gérés à l'aide des commandes crsctl et srvctl. Dans le cadre d'une gestion avec
séparation des rôles, vous pouvez permettre explicitement aux utilisateurs du système
d'exploitation de modifier les attributs de certains pools de serveurs. Il peut exister des
relations parent-enfant entre les pools de serveurs. Les pools de serveurs de niveau supérieur
sont toujours mutuellement exclusifs, ce qui signifie qu'un serveur du cluster ne peut
appartenir qu'à un pool particulier à un instant donné. Les pools de serveurs de niveau
supérieur créent une division logique du cluster en plusieurs sous-clusters.
Lorsqu'Oracle Clusterware est installé, deux pools de serveurs sont créés automatiquement :
GENERIC et FREE. Initialement, tous les serveurs d'une nouvelle installation sont affectés au
pool FREE. Les serveurs sont transférés automatiquement du pool FREE aux nouveaux pools
définis.

Attributs d'un pool de serveurs
Attribut Description
ACL Liste de contrôle d'accès qui définit les privilèges nécessaires pour le
pool de serveurs
ACTIVE_SERVERS Liste des serveurs actuellement affectés à un pool
EXLUSIVE_POOLS Indique si les serveurs peuvent appartenir à plusieurs pools
IMPORTANCE Importance relative du pool de serveurs, comprise entre 0 (valeur la

plus faible) et 1000

MAX_SIZE Nombre maximum de serveurs qu'un pool peut contenir
MIN_SIZE Nombre minimum de serveurs qu'un pool peut contenir
NAME Nom du pool de serveurs
PARENT_POOLS Définit les pools parent lors de la création de pools de serveurs

imbriqués
SERVER_NAMES Liste des serveurs qui peuvent être associés à un pool de serveurs
Attributs d'un pool de serveurs

Les attributs d'un pool de serveurs peuvent être définis lors de la création du pool, ou
postérieurement. Le seul attribut obligatoire est NAME. Les attributs facultatifs sont les
suivants :
• ACL : Définit le propriétaire du pool de serveurs et les privilèges accordés aux différents
utilisateurs et groupes du système d'exploitation. La valeur de cet attribut est alimentée
lors de la création d'un pool de serveurs en fonction de l'identité du processus qui crée le
pool, sauf si elle est modifiée explicitement. Il utilise une chaîne au format :
owner:user:rwx,pgrp:group:rwx,other::r— pour définir les privilèges
autorisés pour les utilisateurs owner, group et other. Les privilèges admis pour un
pool de serveurs sont la lecture seule (r), la possibilité de modifier les attributs ou de
supprimer le pool (w), et la possibilité d'affecter des ressources au pool (x).
• ACTIVE_SERVERS : Liste des serveurs actuellement affectés au pool, délimités par des
espaces. Cet attribut est géré automatiquement par Oracle Clusterware.
• EXCLUSIVE_POOLS : Indique si les serveurs affectés au pool sont partagés avec
d'autres pools. Cet attribut est une valeur de type chaîne contenant n'importe quelle
chaîne arbitraire. Tout autre pool de serveurs présentant la même valeur pour cette chaîne
est mutuellement exclusif avec ce pool.

Attributs d'un pool de serveurs (suite)

• IMPORTANCE : Indique l'importance relative du pool de serveurs par rapport aux
autres, avec une valeur comprise entre 0 (valeur la plus faible) et 1000. La valeur par
défaut est 0.
• MAX_SIZE : Indique le nombre maximum de serveurs qu'un pool peut contenir.
La valeur –1, qui est la valeur par défaut, correspond à l'ensemble du cluster.
• MIN_SIZE : Indique le nombre minimum de serveurs qu'un pool peut contenir.
La valeur de cet attribut ne définit pas une limite fixe. Elle détermine la priorité pour
l'affectation des serveurs. La valeur par défaut est 0.
• PARENT_POOLS : Permet la création de pools de serveurs imbriqués. Les pools de
serveurs répertoriés dans cet attribut constituent les pools de serveurs parents. Il est

possible d'indiquer plusieurs pools de serveurs parents séparés par une virgule.
• SERVER_NAMES : Répertorie les noeuds sur lesquels résident les serveurs qui peuvent
être associés à un pool. Si cet attribut est vide, Oracle Clusterware suppose que
n'importe quel serveur peut être affecté à n'importe quel pool, dans les limites fixées par
les autres attributs tels que PARENT_POOLS.
Remarque : Tous les attributs du pool de serveurs GENERIC sont en lecture seule et ne
peuvent pas être modifiés. Pour le pool FREE, seuls les attributs IMPORTANCE et ACL
peuvent être modifiés.

Pools de serveurs GENERIC et FREE
• Lors de la mise à niveau de Clusterware, tous les noeuds

sont placés dans le pool GENERIC pour assurer la
compatibilité avec les versions antérieures.
• Le pool de serveurs GENERIC stocke les bases de
données dont la version est inférieure à 1.2 et les bases
gérées par l'administrateur avec des configurations fixes.

• Les attributs du pool de serveurs FREE sont soumis aux
restrictions suivantes :
– SERVER_NAMES, MIN_SIZE et MAX_SIZE ne peuvent pas
être modifiés par l'utilisateur.
– IMPORTANCE et ACL peuvent être modifiés par l'utilisateur.
• Les attributs de configuration du pool GENERIC ne peuvent
pas être modifiés.
Pools de serveurs GENERIC et FREE

Lorsqu'Oracle Clusterware est installé, deux pools de serveurs sont créés automatiquement :
GENERIC et FREE. Initialement, tous les serveurs d'une nouvelle installation sont affectés au
pool FREE. Les serveurs sont transférés automatiquement du pool FREE aux nouveaux pools
définis. Lorsque vous mettez à niveau Oracle Clusterware, tous les noeuds sont affectés au
pool de serveurs GENERIC pour garantir la compatibilité avec les versions de base de
données antérieures à Oracle Database 11g Release 2. Le pool FREE comprend les serveurs
qui ne sont affectés à aucun autre pool. Les attributs du pool de serveurs FREE sont soumis
aux restrictions suivantes :
• SERVER_NAMES, MIN_SIZE et MAX_SIZE ne peuvent pas être modifiés par
l'utilisateur.
• IMPORTANCE et ACL peuvent être modifiés par l'utilisateur.
Le pool GENERIC stocke les bases de données dont la version est inférieure à 1.2 et les bases
gérées par l'administrateur avec des configurations fixes. Le pool GENERIC comprend les
serveurs qui répondent à l'une ou l'autre des conditions suivantes :
• Serveurs que vous avez définis dans l'attribut HOSTING_MEMBERS de toutes les
ressources de type application.
• Serveurs dont les noms sont indiqués dans l'attribut SERVER_NAMES des pools qui
indiquent le pool GENERIC comme pool parent.
Les attributs du pool GENERIC sont soumis aux restrictions suivantes :
• Les attributs de configuration du pool GENERIC ne peuvent pas être modifiés.

Pools de serveurs GENERIC et FREE (suite)
• Lorsque vous indiquez un nom du serveur dans l'attribut HOSTING_MEMBERS, Oracle

Clusterware le permet uniquement dans les cas suivants :
- Le serveur est en ligne et existe dans le pool GENERIC.
- Le serveur est en ligne et existe dans le pool FREE, auquel cas Oracle Clusterware
le transfère dans le pool GENERIC.
- Le serveur est en ligne et existe dans n'importe quel autre pool, et le client est un
administrateur du cluster ou il est autorisé à utiliser les serveurs du pool, auquel
cas le serveur est transféré dans le pool GENERIC.
- Le serveur est hors ligne et le client est un administrateur du cluster.
Lorsque vous enregistrez un pool de serveurs enfant avec le pool GENERIC, Oracle

Clusterware le permet uniquement si les noms de serveur répondent aux conditions
précédemment indiquées pour les ressources. Initialement, les serveurs sont si possible
affectés au pool GENERIC au démarrage du cluster ou lorsqu'un serveur est ajouté au cluster,
et sinon à d'autres pools.

Affectation de serveurs à des pools
Supposons qu'il n'existe pas de serveurs dans le cluster, que

tous les pools de serveurs soient vides, et qu'ils soient définis
comme suit :
NAME IMPORTANCE MIN_SIZE MAX_SIZE PARENT_POOLS EXCLUSIVE_POOLS
sp1 1 1 10
sp2 3 1 6

sp3 2 1 2
sp2_child1 2 1 5 sp2 s123
sp2_child2 1 1 5 sp2 s123
host01 est inclus dans le cluster et est affecté aux pools de

serveurs sp2 et sp2_child1.
Affectation de serveurs à des pools

Supposons que le cluster ne comprenne pas de serveurs pour l'instant, que tous les pools de
serveurs soient vides, et qu'ils soient définis comme indiqué dans le tableau de la diapositive.
L'affectation des serveurs aux pools commence lors de l'inclusion du serveur host01 dans
le cluster :
1. Oracle Clusterware traite d'abord les pools de premier niveau (ceux qui ne dépendent pas
d'un pool parent). Dans l'exemple, il s'agit des pools sp1, sp2 et sp3.
2. Oracle Clusterware liste les pools de serveurs selon leur attribut IMPORTANCE comme
suit : sp2, sp3, sp1.
3. Il affecte host01 à sp2 parce que sp2 a l'attribut IMPORTANCE le plus élevé et parce
que sa valeur MIN_SIZE n'est pas encore atteinte.
4. Oracle Clusterware traite les pools enfants de sp2 (sp2_child1 et sp2_child2).
Les deux pools ont une taille inférieure à leur attribut MIN_SIZE.
5. Oracle Clusterware liste les deux pools de serveurs restants selon leur attribut
IMPORTANCE comme suit : sp2_child1, sp2_child2.
6. Il affecte host01 à sp2_child1 mais ne peut pas affecter host01 à sp2_child2
car sp2_child1 est défini comme mutuellement exclusif avec sp2_child2 par le
biais de la chaîne EXCLUSIVE_POOLS égale à s123.

Attributs et états des serveurs
Attribut Fonction
NAME Nom du noeud du serveur
ACTIVE_POOLS Liste des pools auxquels un serveur appartient, séparés
par un espace
STATE L'état d'un serveur peut être : ONLINE, OFFLINE,
LEAVING, JOINING, VISIBILE et RECONFIGURING.
STATE_DETAILS Informations supplémentaires concernant les attributs
STATE

Utilisez la commande crsctl status server pour contrôler
l'état du serveur :
# crsctl status server -f
NAME=host01 NAME=host02 NAME=host03

STATE=ONLINE STATE=ONLINE STATE=ONLINE
ACTIVE_POOLS=ora.OLTP ACTIVE_POOLS=APP ACTIVE_POOLS=ora.OLTP
STATE_DETAILS= STATE_DETAILS= STATE_DETAILS=
Remarque : Le résultat réel est orienté verticalement.
Attributs et états des serveurs

Lorsqu'un serveur est ajouté à un cluster, Oracle Clusterware lui affecte un ensemble
d'attributs. Lorsque le serveur est supprimé du cluster, Oracle Clusterware annule ces
paramètres. Ces attributs sont les suivants :
NAME : Nom du noeud du serveur. Un nom du serveur peut contenir tous les caractères pris en
charge par la plateforme à l'exception du point d'exclamation (!) et du tilde (~). Il ne peut pas
commencer par un point ni par ora. Cet attribut est nécessaire.
ACTIVE_POOLS : Liste des pools auxquels un serveur appartient, séparés par un espace.
Oracle Clusterware gère cette liste automatiquement.
STATE : Un serveur peut présenter l'un des états suivants :
• ONLINE : Le serveur est membre du cluster et il est accessible pour l'affectation des
ressources.
• OFFLINE : Le serveur n'est pas membre du cluster. Il n'est donc pas disponible pour
l'affectation des ressources.
• JOINING : Lorsqu'un serveur est inclus dans le cluster, Oracle Clusterware vérifie qu'il
est valide pour l'affectation des ressources. Oracle Clusterware vérifie également l'état
des ressources configurées pour s'exécuter sur le serveur. Le serveur quitte cet état une
fois les vérifications terminées.
• LEAVING : Le serveur prend l'état LEAVING au début d'un arrêt planifié. Il devient alors
indisponible pour l'affectation des ressources.

Attributs et états des serveurs (suite)

• VISIBLE : Les serveurs sur lesquels Oracle Clusterware s'exécute, mais pas le démon
Cluster Ready Services (crsd), prennent l'état VISIBLE. Cela indique généralement
un problème ou une panne intermittente et le fait qu'Oracle Clusterware tente de
récupérer (redémarrer) le démon. Oracle Clusterware ne peut pas gérer les ressources
sur les serveurs tant que ceux-ci présentent cet état.
• RECONFIGURING : Lorsqu'un serveur est transféré d'un pool à un autre en raison d'une
reconfiguration, il prend cet état si les ressources qui s'y exécutent doivent être arrêtées
et déplacées. Cela se produit parce que les ressources qui s'exécutent sur le serveur ne
sont pas nécessairement configurées pour s'exécuter dans le pool cible. Une fois les
ressources correctement en place, le serveur reprend l'état ONLINE.

STATE_DETAILS : Attribut en lecture seule géré par Oracle Clusterware. Il fournit des
informations supplémentaires relatives à l'état du serveur. Il peut inclure les informations
suivantes :
• Etat du serveur : ONLINE :
- AUTOSTARTING RESOURCES : La procédure de redémarrage des ressources
(exécutée lors de la réinitialisation d'un serveur ou du redémarrage de la couche
Oracle Clusterware) est en cours sur le serveur.
- AUTOSTART QUEUED : Le serveur attend le lancement automatique des
ressources pour commencer. Lorsque cela se produit, la valeur de l'attribut prend la
valeur AUTOSTARTING RESOURCES.
• Etat du serveur : RECONFIGURING :
- STOPPING RESOURCES : Les ressources qui ne peuvent pas s'exécuter dans le
nouveau pool de serveurs sont en cours d'arrêt.
- STARTING RESOURCES : Les ressources qui peuvent s'exécuter dans le nouveau
pool de serveurs sont en cours de démarrage.
- RECONFIG FAILED : Une ou plusieurs ressources ne se sont pas arrêtées, de
sorte que le serveur ne peut pas prendre l'état ONLINE. A ce stade, une
intervention manuelle est requise. Vous devez arrêter les ressources qui ne sont pas
arrêtées, ou annuler leur enregistrement. Ensuite, le serveur prend
automatiquement l'état ONLINE.
• Etat du serveur : JOINING :
- CHECKING RESOURCES : A la suite de l'initialisation d'un serveur, du
redémarrage de la couche Oracle Clusterware ou du redémarrage du démon crsd
sur un serveur, le moteur de stratégies doit déterminer l'état en cours des
ressources exécutées sur ce serveur. Tant que cette procédure est en cours, cette
valeur est renvoyée.

Créer des pools de serveurs

avec srvctl et crsctl
Recourez à l'utilitaire crsctl ou srvctl pour créer des pools
de serveurs supplémentaires.
• Définir des attributs sur la ligne de commande :
$ crsctl add serverpool SP1 –attr "MIN_SIZE=2,
MAX_SIZE=5, IMPORTANCE=3"
$ srvctl add srvpool –g SP1 –l 2 –u 5 –i 3 -n

"server1,server2"
• Définir des attributs à partir d'un fichier texte :

$ crsctl add serverpool SP1 –file
/usr/local/bin/SP1_attributes.txt
Créer des pools de serveurs avec srvctl et crsctl

Utilisez la commande crsctl add serverpool ou srvctl add srvpool pour
ajouter un pool de serveurs à Oracle Clusterware. Le seul attribut obligatoire est NAME.
Le premier exemple de la diapositive définit les attributs facultatifs sur la ligne de commande
à l'aide de l'utilitaire crsctl. Les noms et les valeurs d'attribut doivent être indiqués entre
guillemets ("") et être séparés par des virgules. N'employez pas l'utilitaire crsctl pour des
pools de serveurs dont le nom commence par ora car il s'agit de pools Oracle. La diapositive
montre également l'utilisation de srvctl. Celle-ci permet seulement d'indiquer les attributs
MIN_SIZE (-l), MAX_SIZE (-u), IMPORTANCE (-i) et SERVER_NAMES (-n). Le
deuxième exemple de la diapositive définit les attributs en indiquant un fichier texte qui les
contient. La commande crsctl add serverpool admet les options supplémentaires
suivantes :
• (-i) : Entraîne l'échec de la commande si le processus crsd ne peut pas traiter la
demande immédiatement.
• (-f) : Option qui force le processus crsd à arrêter les ressources s'exécutant sur un
serveur d'un autre pool et à transférer ce serveur dans le pool que vous ajoutez.

Gérer les pools de serveurs

avec srvctl et crsctl
Recourez à l'utilitaire crsctl ou srvctl pour supprimer ou
modifier des pools de serveurs.
• Pour supprimer un pool de serveurs :
$ crsctl delete serverpool SP1
$ srvctl remove srvpool –g SP1

• Pour modifier un pool de serveurs :
$ crsctl modify serverpool SP2 –attr "MIN_SIZE=4,
MAX_SIZE=8, IMPORTANCE=7"
$ srvctl modify srvpool -g SP2 –l 4 –u 8 –i 7
Gérer les pools de serveurs avec srvctl et crsctl

Recourez à l'utilitaire crsctl ou srvctl pour supprimer et modifier des pools de serveurs.
N'employez pas l'utilitaire crsctl pour des pools de serveurs dont le nom commence par
ora car il s'agit de pools Oracle.

Ajouter des pools de serveurs avec Enterprise Manager

Ajouter des pools de serveurs avec Enterprise Manager

Pour ajouter un pool de serveur à l'aide d'Enterprise Manager, cliquez sur l'onglet du dossier
Cluster, puis sur l'onglet du sous-dossier Administration. Localisez la section Server Pools et
cliquez sur le lien Add Server Pool. Dans la page Add Server Pool, indiquez le nom du pool
de serveurs et précisez s'il contiendra des ressources Oracle ou non Oracle. En outre, indiquez
la taille maximale du pool. Vous pouvez choisir Entire Cluster, ou bien Specify Maximum
Size et indiquer le nombre maximal de serveurs admis dans le pool. Développez la section
Advanced pour configurer la taille minimale, l'importance et le pool parent. En outre, vous
pouvez affecter directement des serveurs spécifiques au pool. Si le pool admet des ressources
non Oracle, il est aussi possible de définir des groupes exclusifs.

Gérer les pools de serveurs avec Enterprise Manager

Gérer les pools de serveurs avec Enterprise Manager

Les pools de serveurs peuvent être contrôlés à partir de la page Server Pools d'Enterprise
Manager. Pour accéder à la page, cliquez sur l'onglet Cluster, puis sur l'onglet du sous-dossier
Administration. Dans la section Server Pools, cliquez sur Manage Server Pools. Vous obtenez
des informations détaillées concernant les pools de serveurs configurés. Les actions possibles
à partir de cette page sont les suivantes :
• Afficher les attributs du pool.
• Modifier les attributs du pool.
• Supprimer un pool.
• Déplacer un pool.
• Créer un nouveau pool.
Si l'un des pools de niveau supérieur contient d'autres pools, il est possible de gérer ceux-ci en
développant l'arborescence.

Modélisation des ressources Oracle Clusterware
• Lorsqu'une application est enregistrée, vous indiquez comment

elle est gérée par Clusterware en définissant ses attributs.
• Les informations d'enregistrement incluent un script ou un
programme d'action que Clusterware appelle pour démarrer,
arrêter, gérer et nettoyer l'application.
– Un script d'action est un script shell qui est appelé par un
agent générique du script fourni par Oracle Clusterware.

– Un agent spécifique à l'application est généralement un
programme C ou C++ qui appelle les API Clusterware
directement.
• Oracle Clusterware 11g R2 comprend deux agents :
– Agent de script : CRS_HOME/bin/scriptagent
– Agent d'application : CRS_HOME/bin/appagent
Modélisation des ressources Oracle Clusterware

Depuis l'introduction d'Oracle Database 11g Release 2, il existe maintenant plus d'options
pour gérer tous les types d'application et créer des dépendances entre elles à l'aide d'Oracle
Clusterware. Lorsque vous enregistrez une application en tant que ressource Oracle
Clusterware, vous indiquez comment Oracle Clusterware va la gérer à l'aide d'attributs que
vous allouez à la ressource. Par exemple, ces attributs peuvent définir la fréquence à laquelle
la ressource est vérifiée et le nombre de tentatives de redémarrage sur le même serveur avant
une tentative de basculement sur un autre serveur. Les informations d'enregistrement
contiennent également le chemin d'un script ou d'un programme d'action propre à l'application
qu'Oracle Clusterware appelle pour démarrer, arrêter, gérer et nettoyer l'application.
Un script d'action est un script shell qui est appelé par un agent générique fourni par Oracle
Clusterware. Cet agent est généralement un programme C ou C++ qui appelle les API Oracle
Clusterware directement. Oracle Clusterware 11g Release 2 (11.2) inclut deux agents de script
qui permettent d'utiliser des scripts pour protéger une application. Ces agents sont les
suivants :
• Agent de script (scriptagent sous Linux ; scriptagent.exe sous Windows) :
Recourez à cet agent pour utiliser des scripts shell ou batch pour protéger une
application. Les types de ressource cluster_resource et local_resource sont
tous deux configurés pour utiliser automatiquement cet agent.

Modélisation de ressources Clusterware (suite)

Agent d'application (appagent sous Linux ; appagent.exe sous Windows) : Cet
agent protège automatiquement toutes les ressources de type application utilisées dans
les précédentes versions d'Oracle Clusterware. Vous n'avez aucune configuration à effectuer
pour tirer parti de cet agent. Il appelle les scripts d'action comme avec les versions antérieures
d'Oracle Clusterware et ne doit être utilisé qu'avec les ressources de type application.

Types de ressource
• Oracle Clusterware utilise les types de ressource pour organiser

les ressources présentant des attributs similaires.
• Avantages de l'utilisation des types de ressource :
– Vous avez seulement à gérer les attributs nécessaires.
– Vous pouvez gérer toutes les ressources en fonction de leur type.
• Toutes les ressources enregistrées dans Oracle Clusterware
doivent être associées à un type de ressource.

• Il existe deux types de ressource prédéfinis dans Oracle
Clusterware :
– Ressources locales
– Ressources du cluster
• Vous pouvez définir des types de ressource personnalisés
à l'aide d'Enterprise Manager.
Types de ressource
Les ressources sont généralement uniques, mais elles peuvent avoir des attributs communs.
Oracle Clusterware utilise des types pour organiser les ressources similaires. L'utilisation de
types de ressource offre les avantages suivants :
• Ils permettent de gérer uniquement les attributs requis par les ressources.
• Vous pouvez facilement gérer plusieurs ressources par le biais de leur type.
Chaque ressource enregistrée dans Oracle Clusterware doit avoir un certain type. En plus des
deux types prédéfinis fournis dans Oracle Clusterware, vous pouvez définir des types de
ressource personnalisés adaptés à vos besoins. Les types de ressource prédéfinis sont les
suivants :
• Ressources locales : Il s'agit de ressources liées à un serveur. Le nom de ce type est
local_resource. Une ressource locale s'exécute sur un serveur individuel du cluster.
Son état n'a pas de sens en dehors du contexte de ce serveur.
• Ressources de cluster : Les ressources de cluster (correspondant au type
cluster_resource) tiennent compte de l'environnement du cluster. Elles sont
concernées par la fonctionnalité de cardinalité, ainsi que par les opérations de
permutation de rôles entre serveurs et de basculement en cas de panne. L'état des
ressources de cluster a un sens dans le contexte du cluster.
Les versions antérieures de Clusterware ne sont prises en charge que pour le type de ressource
application. Ce type de ressource existe toujours, mais uniquement pour des raisons de
compatibilité descendante. Oracle recommande d'enregistrer les ressources de type
application avec le type cluster_resource dans Oracle Clusterware 11g Release 2.

Ajouter un type de ressource

Ajouter un type de ressource

Pour ajouter un nouveau type de ressource à Oracle Clusterware à l'aide d'Oracle Enterprise
Manager, effectuez les opérations suivantes :
1. Connectez-vous à Oracle Enterprise Manager Database Control et cliquez sur l'onglet
Cluster, puis sur l'onglet du sous-dossier Administration. Cliquez ensuite sur Add
Resource Type.
2. Entrez le nom utilisateur et le mot de passe de l'administrateur du cluster pour afficher
la page Add Resource Type.
3. Entrez le nom du type de ressource dans le champ Name.
4. Dans la liste déroulante du champ Base Resource Type, sélectionnez
cluster_resource ou local_resource comme type de ressource de base.
En général, sélectionnez le type cluster_resource pour les ressources qui peuvent
résider sur n'importe quel serveur du cluster. Sélectionnez le type local_resource
pour les ressources qui doivent être présentes sur chaque serveur d'un cluster, par
définition, comme les adresses IP virtuelles (VIP), les instances ASM et les ressources
réseau. Cliquez sur le bouton View pour afficher les caractéristiques, les paramètres
et les dépendances du type de ressource sélectionné.
5. Les paramètres facultatifs de la section Placement régissent le positionnement de la
ressource dans le cluster par Oracle Clusterware. Ces paramètres sont les suivants :
- Cardinality : Nombre de noeuds sur lesquels la ressource doit s'exécuter
simultanément.
- Degree : Nombre de fois où une ressource peut s'exécuter simultanément sur un
noeud unique.

Ajouter un type de ressource (suite)

- Server Pool : Permet d'affecter la ressource à un pool de serveurs s'il en existe.
Cela indique que les ressources configurées avec ce type sont gérées par une
stratégie.
- Hosting Members : Définit une association entre une resource et un groupe
d'hôtes. Cela indique que les ressources configurées avec ce type sont gérées par
l'administrateur.
- Placement Policy : Une stratégie équilibrée permet à la ressource d'être affectée
à n'importe quel noeud en ligne.
- Load : Clusterware interprète cette valeur avec celle de l'attribut PLACEMENT.
Lorsque ce dernier a une valeur équilibrée, la valeur de LOAD indique où il vaut

mieux placer une ressource.
- Active placement : Lorsque cet attribut a la valeur 1, Clusterware réévalue le
positionnement d'une ressource lors de l'ajout ou du redémarrage d'un serveur du
cluster.
6. Dans le champ Action Program de la section du même nom, indiquez si Oracle
Clusterware appelle un script d'action, un fichier d'agent ou les deux pour gérer la
ressource.

Paramètres d'un type de ressource

Paramètres d'un type de ressource

Pour continuer la configuration du type de ressource, cliquez sur l'onglet Parameters. Comme
le montre la diapositive, les paramètres sont classés en différentes catégories : paramètres de
lancement, paramètres d'arrêt et paramètres de statut. Les paramètres configurables sont les
suivants :
• Auto Start : Indique si Oracle Clusterware démarre automatiquement une ressource
après la récupération d'un serveur du cluster.
• Start Attempts : Nombre de fois où Oracle Clusterware tente de démarrer une ressource
sur le serveur actuel avant d'essayer de le déplacer.
• Start Timeout : Délai d'attente maximum (en secondes) pour l'exécution d'une action de
démarrage. Oracle Clusterware renvoie un message d'erreur si l'action ne finit pas dans le
délai imparti.
• Uptime Threshold : Durée pendant laquelle une ressource doit être opérationnelle pour
qu'Oracle Clusterware la considère comme stable.
• Stop Timeout : Délai d'attente maximum (en secondes) pour l'exécution d'une action
d'arrêt.
• Check Interval : Intervalle (en secondes) entre les exécutions répétées de l'action de
contrôle.
• Script Timeout : Délai d'attente maximum (en secondes) pour l'exécution d'un script
d'action. Ce délai s'applique à toutes les actions (démarrage, arrêt, vérification et
nettoyage).
• Failure Interval : Intervalle, en secondes, pendant lequel Oracle Clusterware applique
l'attribut Failure Threshold. Si la valeur est zéro (0), le suivi des défaillances est
désactivé.
Paramètres avancés d'un type de ressource

Paramètres avancés d'un type de ressource

Utilisez le tableau de l'onglet Advanced Settings pour configurer les droits associés aux
paramètres du type de ressource en cours de création. Un paramètre configuré pour être en
lecture seule ne peut pas être modifié lorsqu'une ressource est enregistrée avec le nouveau
type de ressource. Un paramètre configuré pour être obligatoire doit être défini lors de
l'enregistrement d'une ressource. Pour une description complète des paramètres de ressources,
reportez-vous au manuel Oracle Clusterware Administration and Deployment Guide.

Définir des dépendances entre ressources


Cliquez sur l'onglet Dependencies pour configurer les dépendances de démarrage et d'arrêt
entre ressources pour le nouveau type de ressource. Des ressources sont dépendantes
lorsqu'elles dépendent l'une de l'autre ou s'affectent mutuellement. Par exemple, lorsqu'Oracle
Clusterware tente de démarrer une ressource, il est nécessaire que toutes les ressources dont
elle dépend soient en ligne et dans le même emplacement. Si Oracle Clusterware ne peut pas
mettre ces ressources en ligne, la ressource initiale (dépendante) ne peut pas être mise en ligne
non plus. Les dépendances de ressources sont organisées en deux catégories : les dépendances
de démarrage et d'arrêt. Cette séparation améliore les dépendances entre les ressources et les
types de ressource.
Dépendances de démarrage
Oracle Clusterware regarde les dépendances de démarrage entre ressources lorsque l'état d'une
ressource passe de OFFLINE à ONLINE. Les dépendances de démarrage affichées dans EM
incluent :
• Hard Dependency : Définit une dépendance forte indiquant qu'une autre ressource doit
être ONLINE pour que la ressource dépendante puisse démarrer.
• Weak Dependency : Indique que le système tente de démarrer la ressource liée à la
ressource dépendante si elle n'est pas ONLINE.


Définir des dépendances entre ressources (suite)

Dépendances de démarrage (suite)
• Attraction Dependency : Indique que Clusterware tentera de démarrer une ressource sur
le même noeud que la ressource dépendante.
• Pullup Dependency : Lorsque vous sélectionnez cette option pour une ressource, celle-ci
démarre suite au démarrage des ressources indiquées.
• Dispersion Dependency : Dans la mesure du possible, la ressource n'est pas sélectionnée
sur le même serveur que les ressources dépendantes.
Dépendances d'arrêt
Oracle Clusterware regarde les dépendances d'arrêt entre ressources lorsque l'état d'une
ressource passe de ONLINE à OFFLINE.
Lorsque vous définissez une dépendance forte, la ressource dépendante doit être arrêtée
lorsque la seconde passe à l'état INTERMEDIATE, OFFLINE, ou UNKNOWN. Les deux
ressources peuvent essayer de démarrer ou de basculer vers un autre serveur, selon la façon
dont elles sont configurées.
Lorsque vous cliquez sur l'icône représentant une torche à droite du champ Dependent On
Resource, vous obtenez la liste des ressources enregistrées que vous pouvez sélectionner.
Lorsque vous avez terminé, revenez à l'onglet General et cliquez sur le bouton Submit.

Créer une adresse IP virtuelle d'application

en utilisant crsctl
• Si les clients accèdent à l'application via un réseau, vous devez
enregistrer l'adresse IP virtuelle (VIP) dont dépend celle-ci.
• Pour créer un type pour la nouvelle adresse VIP, exécutez la commande
suivante en tant que root ou que propriétaire d'Oracle Clusterware :
# crsctl add type app.appvip.type -basetype ora.cluster_vip.type
• Après avoir créé un type d'adresse VIP d'application, vous pouvez ajouter
l'adresse VIP réelle au cluster :

# crsctl add resource MyAppsVip -type app.appvip.type -attr
"RESTART_ATTEMPTS=2,START_TIMEOUT=100,STOP_TIMEOUT=100,
CHECK_INTERVAL=10,USR_ORA_VIP=192.168.10.10,START_DEPENDENCIES=
’hard(ora.net1.network) pullup(ora.net1.network)’,
STOP_DEPENDENCIES=’hard(ora.net1.network)’"
• Le script appvipcfg simplifie l'ajout d'une adresse VIP :

# appvipcfg create -network=1 -ip=192.168.10.10 \
-vipname=MyAppsVIP -user=root
Créer une adresse IP virtuelle d'application en utilisant crsctl

Si les clients d'une application accèdent à celle-ci via un réseau, vous pouvez enregistrer
l'adresse IP virtuelle (VIP) dont l'application dépend. Une adresse IP virtuelle d'application est
une ressource de cluster gérée par Oracle Clusterware. (Oracle Clusterware fournit un agent
standard à cet effet.) Basez les adresses IP virtuelles des nouvelles applications sur ce type
d'adresse VIP pour garantir un comportement cohérent de toutes les adresses IP virtuelles
déployée dans un cluster.
Pour créer un type pour l'adresse VIP d'une nouvelle application, exécutez la commande
crsctl add type indiquée dans la diapositive ci-dessus en tant que root ou que
propriétaire de l'installation Oracle Clusterware. Après avoir créé un type d'adresse VIP
d'application, vous pouvez ajouter l'adresse VIP elle-même au cluster. Pour enregistrer une
adresse IP virtuelle en tant que ressource dans Oracle Clusterware, exécutez la commande
crsctl add resource en tant que root ou en tant que propriétaire de l'installation
Oracle Clusterware, comme indiqué dans la diapositive.
Sous Linux et UNIX, une adresse VIP d'application doit être exécutée par le compte root.
Si l'adresse n'a pas été ajoutée par le compte root, vous devez vous assurer qu'elle peut être
exécutée par root :
1. Connectez-vous en tant que root et exécutez la commande suivante :
# crsctl setperm resource MyAppsVip –o root
2. Exécutez cette commande pour permettre au propriétaire de l'installation Oracle
Database d'exécuter le script :
# crsctl setperm resource MyAppsVip –u user:oracle:r-x

Créer une adresse IP virtuelle d'application en utilisant crsctl (suite)
Remarque : Actuellement, le paramètre USR_ORA_VIP est ignoré dans les clusters

GNS/DHCP.
Oracle recommande d'utiliser le script <Grid_home>/bin/appvipcfg pour créer ou
supprimer une adresse VIP d'application. Lancez ce script comme suit :
appvipcfg create -network=network_number -ip=ip_address
-vipname=vip_name -user=user_name [-group=group_name
appvipcfg delete -vipname=vip_name]
où network_number est le numéro du réseau, ip_address est l'adresse IP, vip_name est
le nom de l'adresse VIP et user_name est le nom de l'utilisateur.

Le script appvipcfg suppose que la ressource réseau par défaut ora.vip
(ora.net1.network) est utilisée par défaut. En outre, il est supposé que le type par
défaut app.appvip est utilisé.

Créer une adresse IP virtuelle d'application
à l'aide d'EM

Créer une adresse IP virtuelle d'application à l'aide d'EM

Cluster. Cliquez sur Administration puis sur Manage Resources.
2. Entrez le nom et le mot de passe administrateur et cliquez sur Add VIP.
3. Saisissez le nom de l'adresse IP virtuelle dans le champ Name. L'adresse IP virtuelle est
basée sur le type de ressource ora.cluster_vip_net1.type.
4. Sélectionnez "Start the resource after creation" si vous voulez que l'adresse IP virtuelle
démarre immédiatement.
5. Les paramètres facultatifs définissent l'emplacement de l'adresse IP virtuelle dans le cluster.
6. Dans le champ Action Program de la section du même nom, indiquez si Oracle Clusterware
appelle un script d'action, un fichier d'agent ou les deux pour gérer l'adresse VIP. L'option
"Use Agent File" est sélectionnée par défaut, avec le chemin d'un exécutable. Vous devez
également définir le chemin d'accès d'un script, d'un fichier, ou des deux, selon ce que vous
sélectionnez dans le menu déroulant. Si vous choisissez Action Script, vous pouvez cliquer
sur Create New Action Script pour utiliser le modèle de script d'action d'Enterprise
Manager.
7. Pour configurer l'adresse IP virtuelle, cliquez sur Parameters. Dans cette page, vous pouvez
configurer les paramètres de démarrage, d'arrêt et de statut, la surveillance hors ligne et
tous les attributs définis.
8. Cliquez sur Advanced Settings pour configurer les attributs de l'adresse IP virtuelle selon
l'instance.
9. Cliquez sur Dependencies pour configurer les dépendances de démarrage et d'arrêt entre
l'adresse IP virtuelle et d'autres ressources. Cliquez sur Submit lorsque vous avez fini de
configurer l'adresse IP virtuelle.
Gérer les ressources Oracle Clusterware avec EM
• Enterprise Manager peut désormais être utilisée pour :

– Créer les ressources Oracle Clusterware
– Gérer les ressources Oracle Clusterware
– Surveiller les ressources Oracle Clusterware
• EM permet les tâches de gestion des ressources suivantes :
– Modifier les attributs des ressources

– Démarrer et arrêter des ressources
– Déplacer une ressource
• Caractéristiques des ressources pouvant être surveillées
à partir d'Enterprise Manager :
– Cardinalité
– Etat en cours et état visé
– Hôtes en cours d'exécution
Gérer les ressources Oracle Clusterware avec EM

Depuis l'introduction d'Oracle Database 11g Release 2, vous pouvez utiliser Oracle Enterprise
Manager pour gérer les ressources Oracle Clusterware. Vous pouvez créer et configurer ces
ressources, et vous pouvez les surveiller et les gérer après leur déploiement dans le cluster.
L'utilisation d'Oracle Enterprise Manager pour surveiller et gérer les différentes ressources
Oracle Clusterware facilite la gestion quotidienne des environnements haute disponibilité.

Ajouter des ressources avec EM


Pour ajouter des ressources à Oracle Clusterware à l'aide d'Oracle Enterprise Manager :
Cluster, cliquez sur Administration et sur Add Resource.
2. Entrez le nom utilisateur et le mot de passe de l'administrateur du cluster pour afficher la
page Add Resource Type.
3. Saisissez le nom de la ressource dans le champ Name.
4. Sélectionnez cluster_resource ou local_resource dans la liste déroulante
Resource. Oracle Clusterware utilise des types pour organiser les ressources similaires.
Chaque ressource enregistrée dans Oracle Clusterware doit avoir un certain type. En plus
des deux types prédéfinis fournis dans Oracle Clusterware, vous pouvez définir des types
de ressource personnalisés. En général, sélectionnez le type cluster_resource pour
les ressources qui peuvent résider sur n'importe quel serveur du cluster. Sélectionnez le
type local_resource pour les ressources qui doivent être présentes sur chaque
serveur d'un cluster, par définition, comme les adresses IP virtuelles (VIP), les instances
ASM et les ressources réseau. Cliquez sur le bouton View pour afficher les
caractéristiques, les paramètres et les dépendances du type de ressource sélectionné.


Paramètres de ressources

Ajouter des ressources avec EM (suite)

5. Entrez une description claire et compréhensible de la ressource dans le champ
Description.
6. Sélectionnez "Start the resource after creation" si vous voulez que l'adresse IP virtuelle
démarre immédiatement.
7. Les paramètres facultatifs de la section Placement régissent le positionnement de la
ressource dans le cluster par Oracle Clusterware. Ces paramètres sont les suivants :
- Cardinality
- Degree
- Server Pool
- Hosting Members
- Placement Policy
- Load
- Active placement
8. Dans le champ Action Program de la section du même nom, indiquez si Oracle
Clusterware appelle un script d'action, un fichier d'agent ou les deux pour gérer l'adresse
VIP. Si vous choisissez le script d'action, vous pouvez cliquer sur Create New Action
Script pour utiliser le modèle de script d'action Oracle Enterprise Manager pour créer un
script d'action pour la ressource.


Paramètres de ressource :


Pour continuer la configuration du type de ressource, cliquez sur l'onglet Parameters. Comme
le montre la diapositive, les paramètres sont classés en différentes catégories : paramètres de
lancement, paramètres d'arrêt et paramètres de statut. Les paramètres configurables sont les
suivants :
• Auto Start
• Start Attempts
• Start Timeout
• Uptime Threshold
• Stop Timeout
• Script Timeout
• Check Interval
• Failure Interval
• Failure Threshold
• Restart Attempts
• Offline Check Interval

Dépendances de ressource :


Cliquez sur Dependencies pour configurer les dépendances de démarrage et d'arrêt entre les
ressources. Des ressources sont dépendantes lorsqu'elles dépendent l'une de l'autre ou
s'affectent mutuellement. Dans Oracle Clusterware 11g Release 2, les dépendances sont
organisées en deux catégories : les dépendances de démarrage et les dépendances d'arrêt.
Dépendances de démarrage
Oracle Clusterware regarde les dépendances de démarrage entre ressources lorsque l'état d'une
ressource passe de OFFLINE à ONLINE. Les dépendances de démarrage affichées dans EM
incluent :
• Hard
• Weak
• Attraction
• Pullup
• Dispersion



Dépendances d'arrêt
Oracle Clusterware regarde les dépendances d'arrêt entre ressources lorsque l'état d'une
ressource passe de ONLINE à OFFLINE.
• Lorsque vous définissez une dépendance forte, la ressource dépendante doit être arrêtée
lorsque la seconde passe à l'état INTERMEDIATE, OFFLINE ou UNKNOWN. Les deux
ressources peuvent essayer de démarrer ou de basculer vers un autre serveur, selon la
façon dont elles sont configurées.
Cliquez sur Submit lorsque vous avez fini de configurer la ressource.

Ajouter des ressources à l'aide de crsctl
• Les ressources peuvent être enregistrées dans Oracle

Clusterware à l'aide de la commande crsctl add
resource.
• Pour ajouter un serveur Web Apache en tant que :
– Ressource gérée par l'administrateur :
# crsctl add resource myApache -type cluster_resource -attr
"ACTION_SCRIPT='/u01/ogi/scripts/myapache.scr',

PLACEMENT=’restricted’, HOSTING_MEMBERS=’host01 host02’,
CHECK_INTERVAL=’30’,START_DEPENDENCIES=’hard(appsvip)’,
STOP_DEPENDENCIES=’hard(appsvip)’, RESTART_ATTEMPTS=’2’,"
– Ressource gérée par une stratégie :

# crsctl add resource myApache -type cluster_resource -attr
"ACTION_SCRIPT=’/u01/ogi/scripts/myapache.scr’,
PLACEMENT=’restricted’, SERVER_POOLS=’myServerPool’,
CHECK_INTERVAL=’30’, START_DEPENDENCIES=’hard(appsvip)’,
STOP_DEPENDENCIES=’hard(appsvip)’,RESTART_ATTEMPTS=’2’,"
Ajouter des ressources à l'aide de crsctl

Les ressources sont stockées dans Oracle Oracle Clusterware 11g Release 2 à l'aide de la
commande crsctl add resource. Les commandes crs_register et crs_profile
sont encore disponibles dans le répertoire d'origine d'Oracle Clusterware mais elles sont
fournies pour la compatibilité descendante uniquement.
Pour enregistrer une application en tant que ressource :
crsctl add resource resource_name -type resource_type -attr
"attribute_name=’attribute_value’, attribute_name=’attribute_value’,
...”
L'option -type est suivie du nom du type de ressource, et l'option -attr est suivie d'une
liste de paires attribut de ressource-valeur séparées par une virgule, délimitée par des
guillemets (" "). Les valeurs d'attribut doivent être indiquées entre apostrophes (' ').
Pour annuler l'enregistrement d'une ressource, utilisez la commande crsctl delete
resource. Vous ne pouvez pas annuler l'enregistrement d'une application ou d'une
ressource qui est ONLINE ou requise par une autre ressource, sauf si vous utilisez l'option
-force. L'exemple qui suit annule l'enregistrement de l'application Apache Web Server :
# crsctl delete resource myApache
Exécutez la commande crsctl delete resource comme étape de nettoyage
lorsqu'une ressource n'est plus gérée par Oracle Clusterware. Oracle Corporation recommande
d'annuler l'enregistrement de toutes les ressources inutiles.

Gérer les ressources avec EM
Actions de gestion


Pour gérer les ressources avec Oracle Enterprise Manager :
Cluster, cliquez sur Administration et sur Manage Resources.
2. Entrez le nom utilisateur et le mot de passe de l'administrateur du cluster pour afficher
la page Manage Resources.
3. Sélectionnez "Show Oracle Resources" pour afficher la liste des ressources Oracle ou
pour saisir le nom d'une ressource particulière que vous souhaitez gérer. Après avoir
sélectionné une ressource, cliquez sur le bouton View pour afficher les attributs de la
ressource ou sur le bouton Edit pour les modifier.


Démarrer ou arrêter une ressource :


Les ressources peuvent être arrêtées ou démarrées à partir de la page EM Manage Resources,
comme indiqué dans la diapositive. Pour arrêter la ressource my ressource,
sélectionnez-la dans la liste et cliquez sur le bouton Stop. Cliquez sur le bouton Confirm
dans la page Start/Stop Confirmation pour poursuivre l'action d'arrêt. La page Manage
Resources est alors affichée, indiquant l'état actuel de la ressource. Elle doit afficher une
flèche vers le BAS (OFFLINE) pour les paramètres Current State et Target State, comme le
montre le graphique de la diapositive.
Pour démarrer la ressource, sélectionnez-la simplement à partir de la page Manage Resources
et cliquez sur le bouton Start. Cliquez sur le bouton Continue dans la page Start/Stop
Confirmation pour continuer. Une flèche vers le HAUT doit être affichée pour les paramètres
Current State et Target State (ONLINE). En outre, les hôtes en cours sont affichés.


Déplacer une ressource :

Gérer les ressources avec EM (suite)

A partir de la page Manage Resources, vous pouvez déplacer des ressources d'un noeud à un
autre du cluster. Pour déplacer une ressource nommée my resource de host02 à
host01, sélectionnez-la et cliquez sur Relocate. Dans la page Relocate Resource,
sélectionnez host02 dans le champ From Host. La liste affiche tous les noeuds sur lesquels
la ressource est en cours d'exécution. Entrez ou sélectionnez host01 dans le champ To Host
et cliquez sur le bouton Continue. Dans la page Relocate Resource: Confirmation, cliquez sur
le bouton Continue pour poursuivre avec l'action. Dans la page Confirmation, la commande
qui sera exécutée pour déplacer la ressource s'affiche :
crsctl relocate resource my_resource –n host01 –s host02

Gérer les ressources avec crsctl
• Démarrer ou arrêter des ressources avec la commande

crsctl start|stop resource :
# crsctl stop resource myApache
CRS-2673: Attempting to stop 'myApache' on 'host01'
CRS-2677: Stop of 'myApache' on 'host01' succeeded
# crsctl start resource myApache
CRS-2672: Attempting to start 'myApache' on 'host01'
CRS-2676: Start of 'myApache' on 'host01' succeeded

• Utilisez la commande crsctl relocate resource pour
déplacer des applications et des ressources applicatives :
# crsctl relocate resource myApache -n host02
CRS-2673: Attempting to stop 'myApache' on 'host01'
CRS-2677: Stop of 'myApache' on 'host01' succeeded
CRS-2672: Attempting to start 'myApache' on 'host02'
CRS-2676: Start of 'myApache' on 'host02' succeeded

Vous démarrez et arrêtez les ressources avec les commandes crsctl start|stop
resource. Les démarrages ou arrêts effectués manuellement en dehors d'Oracle Clusterware
peuvent invalider le statut des ressources. En outre, Oracle Clusterware peut tenter de
redémarrer une ressource sur laquelle vous procédez à un arrêt manuel. L'exécution de la
commande crsctl start resource sur une ressource définit la valeur cible de celle-ci
avec la valeur ONLINE. Oracle Clusterware tente de modifier l'état pour qu'il corresponde
à cette valeur cible en exécutant le programme d'action avec le paramètre de démarrage.
Lorsqu'une ressource est en cours d'exécution, l'état visé et l'état actuel ont tous deux la valeur
ONLINE.
Pour démarrer une ressource applicative enregistrée dans Oracle Clusterware, utilisez la
commande crsctl start resource. Par exemple :
# crsctl start resource myApache
Utilisez la commande crsctl relocate resource pour déplacer des applications et
des ressources applicatives. Pour déplacer l'application Apache Web Server sur un serveur
nommée rac2, exécutez la commande suivante :
# crsctl relocate resource myApache -n host02
Pour déplacer une application et les ressources dont elle a besoin, utilisez l'option -f avec
la commande crsctl relocate resource.

Entrez la commande suivante pour afficher les informations relatives

aux applications et aux ressources sous forme de tableau :
# crsctl status resource
NAME=ora.DATA.dg
TYPE=ora.diskgroup.type
TARGET=ONLINE , ONLINE
STATE=ONLINE on host01, ONLINE on host02
NAME=ora.LISTENER.lsnr
TYPE=ora.listener.type

...
NAME=ora.rdba.db
TYPE=ora.database.type
NAME=ora.scan3.vip
TYPE=ora.scan_vip.type
TARGET=ONLINE
STATE=ONLINE on host02
Gérer les ressources avec crsctl (suite)

Pour afficher les informations d'état sur les applications et les ressources qui se trouvent sur
les serveurs du cluster, utilisez la commande crsctl status resource. L'exemple
suivant affiche les informations d'état concernant l'application Apache Web Server :
# crsctl status resource myApache
NAME=myApache
TYPE=cluster_resource
TARGET=ONLINE
STATE=ONLINE on host01
Entrez la commande suivante pour afficher les informations relatives aux applications et aux
ressources sous forme de tableau :
# crsctl status resource
Ajoutez un nom de ressource à la commande précédente pour déterminer :
• Le nombre de redémarrages de la ressource
• Le nombre d'échecs de la ressource au cours de l'intervalle considéré
• Le nombre maximal de redémarrages ou d'échecs pour une ressource
• L'état visé pour la ressource et le statut normal
Utilisez l'option -f avec la commande crsctl status resource resource_name pour
afficher des informations concernant une ressource spécifique.

Evénements de haute disponibilité : ONS et FAN
Appl. Appl. Appl.

Appl. C Appl. C
.NET Java Java
ODP.NET API OCI API API JDBC
ONS C ONS Java
ONS ONS

AQ
Evénements
Appl. ONS
haute disp.
proxy Evénements
haute disp. Evéne-
Scripts ments DB
d'appel CRS EMD
externe
haute Control
disp.
Exéc.
d'appel
externe Evénements
haute disp. Noeud1
Événements de haute disponibilité : ONS et FAN

Les événements de haute disponibilité sont générés lorsque les ressources changent d'état dans
un environnement Oracle Clusterware. Oracle Notification Service (ONS) est une fonction qui
crée une passerelle avec les serveurs de niveau intermédiaire (middle tier) ou les applications
pour transmettre ces événements à la logique applicative en vue d'un traitement ou d'une
réaction. ONS fait partie d'une grande structure appelée FAN (Fast Application Notification).
Les applications utilisent les événements pour détecter rapidement les défaillances et
rééquilibrer les pools de connexions en fonction des pannes et des récupérations. Lorsque la
fonction FAN est utilisée avec une base de données Oracle, la fonctionnalité Advanced Queuing
(AQ) permet aux événements de haute disponibilité d'être reçus par les applications externes
telles que les clients .NET. Pour bénéficier pleinement des avantages de la fonction FAN,
le plus simple est d'utiliser un client intégré à cette fonction, par exemple :
• Cache de connexion implicite JDBC (Java Database Connectivity)
• Appels de programmes externes (callouts) personnalisables
• Connection Manager (CMAN)
• Processus d'écoute
• API ONS (Oracle Notification Service)
• Pool de connexions ou pool de sessions OCI (Oracle Call Interface)
• Gestion transparente des incidents de connexion (TAF - Transparent Application Failover)
• Pool de connexions ODP.NET
Remarque : Les applications ci-dessus ne peuvent pas toutes recevoir tous les types
d'événement FAN.

Gérer un serveur ONS avec srvctl
• Pour déterminer la configuration ONS actuelle :

$ srvctl config nodeapps -s
ONS daemon exists. Local port 6100, remote port 6200
• Pour ajouter un serveur ONS :

$ srvctl add nodeapps -l 6100 -r 6200

• Pour démarrer ou arrêter un serveur ONS :
$ srvctl start|stop nodeapps
Gérer un serveur ONS avec srvctl

L'utilitaire srvctl peut être employé pour créer, gérer et supprimer les serveurs ONS
(Oracle Notification Server). Pour ajouter un serveur ONS, exécutez la commande suivante :
srvctl add nodeapps [-l ons_local_port][-r ons_remote_port]
[-t host[:port],[host[:port]],..
où -l identifie le port (ou processus d'écoute) local du démon ONS, -r indique le port distant
(ou d'écriture) du démon ONS, et -t introduit une liste de paires host:port d'hôtes distants
faisant partie du réseau ONS mais pas du cluster Oracle Clusterware. Le port local est utilisé
pour la communication entre le processus ONS et les clients ONS sur le même noeud. Un port
distant est défini dans le registre OCR qui est utilisé pour la communication entre le processus
ONS et d'autres processus ONS sur d'autres noeuds du cluster ou du niveau intermédiaire.
La syntaxe à utiliser pour démarrer et arrêter un serveur ONS est la suivante :
srvctl start|stop nodeapps [-f]
Pour afficher les informations de configuration pour les services ONS (et toutes les autres
applications nodeapps), exécutez la commande suivante :
srvctl config nodeapps
Pour obtenir les variables d'environnement pour les services ONS (et toutes les autres
applications nodeapps), exécutez la commande suivante :
srvctl getenv nodeapps

Quiz
Lorsqu'Oracle Clusterware est installé, les pools de serveurs

GENERIC et FREE sont créés automatiquement.
1. Vrai
2. Faux

Réponse : 1

Quiz
Oracle Database 11g Release 2 fournit deux méthodes pour la

gestion des ressources. Cette gestion peut être :
• effectuée par l'administrateur
• basée sur des seuils
• basée sur une stratégie

Réponses : 1, 3
Les réponses correctes sont la gestion effectuée par l'administrateur et la gestion basée
sur une stratégie.

Synthèse

• décrire les composants de haute disponibilité d'Oracle
Clusterware
• comparer les bases de données gérées par une stratégie
et les bases gérées par l'administrateur
• décrire le fonctionnement des pools de serveur

• décrire les stratégies d'affectation des applications
• créer une adresse IP virtuelle (VIP) pour une application
• gérer les ressources applicatives

Cet exercice traite de la protection d'une application Apache.




Dépanner Oracle Clusterware

Objectifs

• localiser les fichiers journaux d'Oracle Clusterware
• collecter tous les fichiers journaux avec
diagcollection.pl
• activer le débogage des ressources
• activer le débogage au niveau composant

• activer la fonction de trace pour les outils basés sur Java
• résoudre les problèmes liés au registre OCR (Oracle
Cluster Registry)

Règle d'or pour le débogage

• Veillez toujours à ce que l'heure système soit exactement la
même sur les noeuds afin :
– de faciliter l'analyse des informations de journalisation
– de garantir l'exactitude des résultats lors de la lecture des vues GV$
pour les instances de base de données Oracle Real Application
Clusters (RAC)
– d'éviter les évictions d'instance intempestives

• Il est fortement recommandé de synchroniser les noeuds à l'aide
du protocole NTP (Network Time Protocol).
– Modifiez le fichier de paramètres d'initialisation NTP pour définir
l'indicateur -x, qui empêche le temps d'être ajusté vers l'arrière.
# vi /etc/sysconfig/ntp
OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"
• Si NTP n'est pas utilisé, Clusterware configure automatiquement

le service Cluster Time Synchronization Service (CTSS).
Règle d'or pour le débogage d'Oracle Clusterware

Il est recommandé de configurer le protocole NTP (Network Time Protocol) sur tous les
noeuds du cluster avant d'installer Oracle Clusterware. Cela permet de synchroniser les
horloges entre tous les noeuds et facilite l'analyse des informations de trace basées sur les
horodatages ou des résultats des interrogations exécutées sur les vues GV$ lors de l'utilisation
d'une instance de base de données Oracle RAC. Ces vues sont utilisées par l'administrateur de
base de données pour obtenir des informations consolidées sur une base pour chaque noeud du
cluster. Pour Oracle Enterprise Linux, NTP est configuré avec le fichier /etc/ntp.conf.
Modifiez le fichier et ajoutez les entrées suivantes :
server name01.example.com #Server with atomic clock
server name02.example.com #Server with less accuracy
restrict name01.example.com mask 255.255.255.255 nomodify notrap noquery
restrict name02.example.com mask 255.255.255.255 nomodify notrap noquery
Vous pouvez démarrer le service NTP à l'aide de la commande service ntpd start.
Activez le lancement de NTP à chaque démarrage à l'aide de la commande chkconfig
ntpd on. L'utilitaire ntpq peut être employé pour gérer les performances des serveurs NTP.
Si vous utilisez NTP et préférez l'employer à la place de CTSS, vous devez modifier le fichier
d'initialisation de NTP pour définir l'indicateur -x, qui empêche le temps d'être ajusté en
arrière. Redémarrez le démon Network Time Protocol après avoir effectué cette tâche.

Règle d'or pour le débogage d'Oracle Clusterware (suite)

Pour effectuer cette opération sur les systèmes Oracle Enterprise Linux, Red Hat Linux et
Asianux, modifiez le fichier /etc/sysconfig/ntpd pour ajouter l'indicateur -x, comme
dans l'exemple suivant :
OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"
Si NTP n'est pas utilisé, Clusterware configure automatiquement le service CTSS (Cluster
Time Synchronization Service) et démarre le démon octcssd.bin sur tous les noeuds du
cluster.
Remarque : Une différence de réglage de plus de 5 minutes entre les horloges peut entraîner
des évictions d'instances. Il est fortement recommandé d'arrêter toutes les instances avant le
réglage de la date et de l'heure.

<Grid_Home>
log
<hostname>

agent admin crsd cssd evmd racg client ctssd
diskmon gipcd gnsd gnsd gpnpd mdnsd ohasd
alert<nodename>.log

Oracle Clusterware utilise une structure de répertoires unifiée pour regrouper ses fichiers
journaux. Cette structure consolidée simplifie la collecte des informations de diagnostic et
facilite l'extraction de données et l'analyse des problèmes.
La diapositive ci-dessus présente les principaux répertoires utilisés par Oracle Clusterware
pour le stockage de ses fichiers journaux :
• Les journaux Cluster Ready Service (CRS) se trouvent dans
<Grid_Home>/log/<hostname>/crsd/. Le fichier crsd.log est archivé chaque
fois qu'il atteint 10 Mo (crsd.l01, crsd.l02, …).
• Les journaux Cluster Synchronization Service (CSS) se trouvent dans <Grid_Home>
/log/<hostname>/cssd/. Le fichier cssd.log est archivé chaque fois qu'il atteint
20 Mo (cssd.l01, cssd.l02, …).
• Les fichiers du gestionnaire d'événements se trouvent dans
<Grid_Home>/log/<hostname>/evmd.
• Les journaux SRVM (srvctl) et OCR (ocrdump, ocrconfig, ocrcheck) se trouvent
dans <Grid_Home>/log/<hostname>/client/ et
$ORACLE_HOME/log/<hostname>/client/.
• Les alertes importantes d'Oracle Clusterware sont consignées dans le fichier
alert<nodename>.log, dans le répertoire <Grid_Home>/log/<hostname>.
• Les journaux Oracle Cluster Registry (OCR) (ocrdump, ocrcheck, ocrconfig) sont
stockés dans <Grid_Home>/log/<hostname>/client.

Principaux fichiers journaux d'Oracle Clusterware (suite)

En outre, les informations importantes de trace et d'alerte relatives à #5/
#WVQOCVKE5VQTCIG
/CPCIGOGPV figurent dans le répertoire <Grid_Base>/diag/asm/+asm/+ASMn,
notamment les répertoires de journaux et de trace.

Script de collecte des informations de diagnostic
• Le script <Grid_Home>/bin/diagcollection.pl est

utilisé pour collecter les fichiers journaux importants. Il doit
être exécuté en tant que root.
• Il génère les fichiers suivants dans le répertoire local :
– crsData _<hostname_date_time>.tar.gz
– ocrData _<hostname_date_time>.tar.gz
– coreData_<hostname_date_time>.tar.gz
–

osData _<hostname_date_time>.tar.gz
# /u01/app/11.2.0/grid/bin/diagcollection.pl --collect
Production Copyright 2004, 2008, Oracle. All rights reserved
Cluster Ready Services (CRS) diagnostic collection tool
The following diagnostic archives will be created in the local directory.
crsData_host01_20090729_1013.tar.gz -> logs,traces and cores from CRS home.
Note: core files will be packaged only with the --core option.
ocrData_host01_20090729_1013.tar.gz -> ocrdump, ocrcheck etc
coreData_host01_20090729_1013.tar.gz -> contents of CRS core files
osData_host01_20090729_1013.tar.gz -> logs from Operating System
...
Script de collecte des informations de diagnostic

Utilisez le script diagcollection.pl pour collecter des informations de diagnostic d'une
installation Oracle Grid Infrastructure. Les diagnostics fournissent des informations
supplémentaires permettant au support technique Oracle de résoudre les problèmes. Ce script
se trouve dans <Grid_Home>/bin. Pour exécuter ce script, vous devez être connecté en tant
que root. L'exemple de la diapositive ci-dessus illustre l'appel du script pour la collecte des
informations de diagnostic. Appelé avec l'option –-collect, le script génère, dans le
répertoire local, les quatre fichiers mentionnés dans la diapositive.
• coreData...tar.gz inclut les fichiers noyau et leur analyse extraits dans des fichiers
texte.
• crsData...tar.gz contient les fichiers journaux provenant de
<Grid_Home>/log/<hostname>.
• Les fichiers ocrData...tar.gz contiennent les résultats de ocrdump et ocrcheck,
et la liste des sauvegardes OCR.
• osData...tar.gz contient /var/log/messages et les fichiers d'archivage associés.
Vous pouvez également appeler le script avec l'option –clean pour effacer du répertoire
local les fichiers générés lors d'une exécution précédente. Il est aussi possible de ne capturer
qu'un sous-ensemble des fichiers journaux. Pour cela, ajoutez les options suivantes après
l'option –-collect : –-crs pour collecter les journaux Oracle Clusterware, –-core pour
collecter les fichiers noyau, ou –-all pour collecter tous les journaux. L'option par défaut est
–-all.

Utilitaire de vérification de cluster : Présentation
• Recourez à l'utilitaire de vérification de cluster pour vérifier

que vous disposez d'un cluster bien structuré pour Oracle
Grid Infrastructure et RAC :
– Installation
– Configuration
– Fonctionnement
• Vous pouvez effectuer une vérification complète de la

couche.
• Cette vérification est non intrusive.
• Le mode diagnostic cherche à établir la cause de l'échec
des tâches de vérification.
• Vous pouvez générer des scripts de correction avec
certaines commandes de l'utilitaire CVU à l'aide de
l'indicateur -fixup.
Utilitaire de vérification de cluster : Présentation

L'utilitaire de vérification de cluster (CVU - Cluster Verification Utility) est fourni avec
Oracle Clusterware et Oracle Database 10g Release 2 (10.2) et les versions ultérieures, avec
l'option RAC. CVU vous permet de vérifier, pendant l'installation et la configuration, que tous
les composants requis pour la réussite de l'installation d'Oracle Clusterware, ou d'Oracle
Clusterware et d'une base de données RAC, sont installés et configurés correctement.
Il fournit, en outre, une assistance pour toute modification du cluster ou de la base de
données RAC.
Il existe deux types de commande CVU :
• Les commandes de test de préparation, utilisées pour tester la configuration du système et
vérifier que ce dernier est prêt pour des opérations d'installation de logiciels, de création
de base de données ou de modification de configuration. Ces commandes permettent
également de valider la réussite d'opérations de configuration spécifiques du cluster.
• Les commandes de vérification de composant sont utilisées pour vérifier les différents
composants du cluster et déterminer leur état.
Vous pouvez également utiliser CVU pour vérifier un composant particulier pendant
l'exécution de la couche ou pour isoler un sous-système du cluster pour diagnostic. En mode
diagnostic, CVU tente d'établir la cause de l'échec d'une tâche de vérification afin d'apporter
des éléments qui pourront aider à diagnostiquer le problème.
CVU peut générer des scripts de correction qui exécutent la configuration système requise
pour une installation réussie en plus d'identifier les problèmes système susceptibles d'entraîner
des défaillances d'installation. Il fournit des vérifications supplémentaires pour rechercher les
éventuels problèmes d'installation, de configuration et de fonctionnement.

Utilitaire de vérification de cluster :

Vérification des composants
• Un sous-système ou un module du cluster RAC est considéré
comme un composant dans CVU.
• Il est possible de vérifier la disponibilité et l'intégrité d'un
composant du cluster.
• Voici des exemples de composants. Certains sont simples, par
exemple une unité de stockage spécifique, tandis que d'autres
sont complexes, comme la couche Oracle Clusterware :

– Espace disponible – Intégrité du cluster
– Accessibilité de la zone – Privilèges
de stockage partagée d'administration
– Connectivité des noeuds – Compatibilité entre
– Intégrité du système de fichiers homologues
clusterisé – Configuration système
– Intégrité d'Oracle Clusterware requise
$ cluvfy comp -list
Utilitaire de vérification de cluster : Vérification des composants

L'utilitaire CVU prend en charge le concept de vérification des composants. Les vérifications
entrant dans cette catégorie ne sont pas associées à une étape de déploiement spécifique. Un
composant peut être simple, comme l'espace disque disponible, ou complexe (couvrant
plusieurs sous-composants), comme la couche Oracle Clusterware. Il est possible de vérifier
la disponibilité, l'intégrité ou tout autre comportement spécifique d'un composant du cluster.
Vous pouvez répertorier les composants CVU avec la commande cluvfy comp -list :
nodereach Vérifie si le noeud est accessible. peer Compare les propriétés à celles des
nodecon Vérifie la connectivité des noeuds. homologues.
cfs Vérifie l'intégrité de CFS. ha Vérifie l'intégrité de HA.
ssa Vérifie le stockage partagé. asm Vérifie l'intégrité d'ASM.
space Vérifie la disponibilité de l'espace. acfs Vérifie l'intégrité d'ACFS.
sys Vérifie la configuration minimale olr Vérifie l'intégrité du registre OLR.
requise. gpnp Vérifie l'intégrité de GPnP.
clu Vérifie l'intégrité du cluster. gns Vérifie l'intégrité de GNS.
clumgr Vérifie l'intégrité du gestionnaire scan Vérifie la configuration de SCAN.
du cluster. ohasd Vérifie l'intégrité d'OHASD.
ocr Vérifie l'intégrité d'OCR. crs Vérifie l'intégrité de CRS.
admprv Vérifie les privilèges vdisk Vérifie les paramètres des disques
d'administration. votants.
software Vérifie la distribution des logiciels.
clocksync Contrôle la synchronisation d'horloge.
nodeapp Vérifie l'existence des applications.

Utilitaire de vérification de cluster (cluvfy) :

Emplacements
• Téléchargez les fichiers à partir du site Web d'OTN :
– Créez un répertoire local.
– Copiez et décompressez cvu_<OS>.zip.
– Utilisez la version la plus récente.
• DVD du logiciel Oracle :
– Répertoire Disk1

– runcluvfy.sh
• Répertoire d'origine Grid Infrastructure :
– <Grid_Home>/bin/cluvfy
• Répertoire d'origine Oracle :
– $ORACLE_HOME/bin/cluvfy
Utilitaire de vérification de cluster (cluvfy) : Emplacements

L'utilitaire de vérification de cluster (CVU - Cluster Verification Utility) a été introduit dans
Oracle Clusterware Release 10.2.0.1.0. Il prend en charge les versions 11gR2, 11gR1, 10gR2,
ainsi que 10gR1 pour Oracle Clusterware et RAC. CVU est disponible sous trois formes
différentes :
• Sur le site Web d'Oracle Technology Network (OTN), à l'adresse :
http://www.oracle.com/technology/products/database/clustering/cvu/cvu_download_hom
epage.html
Téléchargez le package et décompressez-le dans un répertoire local (<cvhome>). Vous
pouvez utiliser la commande cluvfy à partir du répertoire <cvhome>/bin. Vous
pouvez éventuellement définir la variable d'environnement CV_DESTLOC. Cette
variable doit pointer sur une zone accessible en écriture sur tous les noeuds. CVU tente
de copier les fichiers nécessaires à cet emplacement. Si cette variable n'est pas définie,
CVU utilise par défaut /tmp.
• Sur le DVD de la version 11.2 du logiciel Oracle (version packagée). Utilisez
runcluvfy.sh, qui est nécessaire lorsque rien n'est installé. Vous pouvez le trouver
dans le répertoire Disk1.
• Installé dans les répertoires d'origine d'Oracle Clusterware et de RAC version 11.2.
Utilisez cluvfy si la couche logicielle CRS est installée. cluvfy se trouve dans
le répertoire <Grid_Home>/bin.
Remarque : Pour une installation manuelle, il suffit d'installer CVU sur un seul noeud. CVU
se déploie sur les noeuds distants pendant les exécutions nécessitant un accès à ces noeuds.

Fichier de configuration
$ cat cvu_config
# Configuration file for Cluster Verification Utility(CVU)
# Version: 011405
#
#If CRS home is not installed, this list will be
#picked up when -n all is mentioned in the commandline argument.
#CV_NODE_ALL=
#if enabled, cvuqdisk rpm is required on all nodes
CV_RAW_CHECK_ENABLED=TRUE

# Fallback to this distribution id
CV_ASSUME_DISTID=OEL4
# Whether X-Windows check should be performed for SSH user equivalence
#CV_XCHK_FOR_SSH_ENABLED=TRUE
# To override SSH location
#ORACLE_SRVM_REMOTESHELL=/usr/bin/ssh
# To override SCP location
#ORACLE_SRVM_REMOTECOPY=/usr/bin/scp
Utilitaire de vérification de cluster (cluvfy) : Fichier de configuration

Vous pouvez utiliser le fichier de configuration de CVU afin de définir des entrées
spécifiques pour l'exécution de cet utilitaire. Le chemin d'accès du fichier de configuration est
$CV_HOME/cv/admin/cvu_config. Voici la liste des options prises en charge dans
cvu_config :
• CV_ORACLE_RELEASE : Version du logiciel à vérifier.
• CV_NODE_ALL : Si cette est définie, elle indique la liste des noeuds qui doivent être
récupérés lorsqu'Oracle Clusterware n'est pas installé et que l'option -n all a été
utilisée dans la ligne de commande.
• CV_RAW_CHECK_ENABLED : L'indication de la valeur TRUE active le contrôle de
l'accessibilité des disques SCSI partagés dans Red Hat version 3.0 ou ultérieure. Cette
vérification requiert l'installation du package cvuqdisk rpm sur tous les noeuds.
Par défaut, la valeur de cette option est TRUE et la vérification des disques partagés est
activée.
• CV_ASSUME_DISTID : Indique l'ID de la distribution utilisée par CVU. Par exemple,
pour que CVU fonctionne avec SuSE 9 ES, indiquez la valeur Pensacola.
• CV_XCHK_FOR_SSH_ENABLED : Lorsque la valeur TRUE est indiquée, X-Windows
vérifie l'équivalence des utilisateurs avec ssh. Par défaut, cette entrée est mise en
commentaire et la vérification X-Windows est désactivée.
• CV_TRACELOC : Associez à cette variable d'environnement le chemin complet du
répertoire de trace de votre choix.

Utilitaire de vérification de cluster (cluvfy) : Fichier de configuration (suite)

• ORACLE_SRVM_REMOTESHELL : Lorsque cette option est définie, elle indique
l'emplacement de la commande ssh/rsh, qui remplace la valeur par défaut de CVU.
Par défaut, cette entrée est mise en commentaire et l'outil utilise /usr/sbin/ssh et
/usr/sbin/rsh.
Remarque : Si l'utilitaire CVU ne trouve pas une clé définie dans le fichier de configuration,
il recherche la variable d'environnement correspondant au nom de la clé. Sinon, il utilise une
valeur par défaut.
• ORACLE_SRVM_REMOTECOPY : Lorsque cette option est définie, elle indique
l'emplacement de la commande scp ou rcp, qui remplace la valeur par défaut de CVU.
Par défaut, cette entrée est mise en commentaire et CVU utilise /usr/bin/scp et

/usr/sbin/rcp.
Si l'utilitaire CVU ne trouve pas une clé définie dans le fichier de configuration, il recherche
la variable d'environnement correspondant au nom de la clé. Si la variable d'environnement
est définie, CVU utilise sa valeur. Sinon, il utilise une valeur par défaut pour cette entité.
Pour fournir à l'utilitaire CVU la liste de tous les noeuds d'un cluster, vous pouvez utiliser
l'option -n all lors de l'exécution d'une commande.


Exemple de sortie
$ cluvfy comp crs -n all -verbose
Verifying CRS integrity
Checking CRS integrity...

The Oracle clusterware is healthy on node "host03"

CRS integrity check passed
Verification of CRS integrity was successful.
Utilitaire de vérification de cluster (cluvfy) : Exemple de sortie

La diapositive ci-dessus illustre la sortie de la commande cluvfy comp crs –n all –
verbose. Cette commande vérifie l'intégralité de la couche Oracle Clusterware.

Activer le débogage des ressources
• Modifiez l'attribut de ressource USR_ORA_DEBUG avec la

valeur 1 pour des ressources particulières :
# crsctl set log res "ora.host01.vip:1"
• Après avoir capturé toutes les informations de trace,

réaffectez la valeur 0 à l'attribut de débogage :

# crsctl set log res "ora.host01.vip:1"
Activer le débogage des ressources

Le support technique Oracle peut vous demander d'activer la fonction de trace afin de
capturer des informations supplémentaires pour la résolution des problèmes liés à des
ressources Oracle Clusterware. Les procédures décrites dans cette section peuvent affecter
les performances. Ne les exécutez qu'avec l'aide du support technique Oracle.
Pour générer des informations de trace supplémentaires pour une ressource spécifique en
cours d'exécution, vous pouvez utiliser crsctl en tant qu'utilisateur root pour activer le
débogage des ressources :
crsctl set log res "<resource name>:1"
L'exemple présenté dans la diapositive active le débogage pour la ressource
ora.host01.vip.
Une fois toutes les informations de trace capturées, n'oubliez pas de réexécuter les
commandes crsctl set log res "<resource name>:0" appropriées.

Débogage dynamique
crsctl
lsmodules debug
log trace statedump
crs css evm

$ crsctl lsmodules css
The following are the Cluster Synchronization Services modules:
CSSD COMCRS COMMNS CLSF SKGFD
crsctl set log {crs | css | evm} "component_name=debugging_level,[...]"
# crsctl set log crs "CRSEVT=1","CRSCOMM=2","CRSTIMER=5"
# crsctl set log res "myResource1=1"
Débogage dynamique
Vous pouvez utiliser les commandes crsctl set log en tant qu'utilisateur root pour
activer le débogage dynamique pour les services %NWUVGT4GCF[5GTXKEGU
%45%NWUVGT
5[PEJTQPK\CVKQP5GTXKEGU
%55, ainsi que pour les composants Event Manager (EVM) et
Clusterware. Les informations de débogage restent dans le registre OCR (Oracle Cluster
Registry) en vue d'une utilisation après le prochain démarrage. Vous pouvez également
activer le débogage des ressources. Les commandes crsctl lsmodules crs| css|evm
permettent de lister les composants pouvant être utilisés pour le débogage. L'exemple de la
diapositive ci-dessus répertorie les composants de CSS. Les niveaux de journalisation par
défaut sont mieux interprétés avec un accès au code source et sont conçus pour les besoins du
support technique Oracle. Lorsque le support technique Oracle vous y invite, vous pouvez
utiliser des commandes telles que la commande suivante pour activer une journalisation
supplémentaire :
• crsctl set log <module name> "<component>=<debugging level>", où
<module name> est le nom du module, CRS, EVM ou CSS ; <component name> est le
nom du composant obtenu à l'aide de la commande crsctl lsmodules, et
<debugging level> est un niveau compris entre 0 et 5.
• crsctl debug statedump crs|css|evm, qui effectue un dump des informations
d'état pour les modules crs, css ou evm.
• crsctl set log res "<res_name>=<debugging_level>", qui active la
journalisation pour une ressource spécifique.
L'exemple de la diapositive ci-dessus montre comment activer dynamiquement une
journalisation additionnelle (niveau 5) pour les composants CRS suivants : CRSEVT,
CRSAPP, CRSTIMER et CRSRES.

Activer la fonction de trace pour les outils

basés sur Java
Pour activer la fonction de trace pour cluvfy, netca et srvctl,
définissez SRVM_TRACE avec la valeur TRUE :
$ export SRVM_TRACE=TRUE
$ srvctl config database –d orcl > /tmp/srvctl.trc
$ cat /tmp/srvctl.trc
...
[main] [ 2009-09-16 00:58:53.197 EDT ]
[CRSNativeResult.addRIAttr:139] addRIAttr: name 'ora.orcl.db 3

1', 'USR_ORA_INST_NAME@SERVERNAME(host01)':'orcl1'
[main] [ 2009-09-16 00:58:53.197 EDT ]
[main] [ 2009-09-16 00:58:53.198 EDT ]
[main] [ 2009-09-16 00:58:53.198 EDT ]
[CRSNative.searchEntities:857] found 3 ntitie
...
Activer la fonction de trace pour les outils basés sur Java

Tous les outils et utilitaires basés sur Java disponibles dans RAC sont appelés par l'exécution
de scripts portant leur nom. Les utilitaires concernés sont Cluster Verification Utility
(cluvfy), Database Configuration Assistant (dbca), Database Upgrade Assistant (dbua),
Net Configuration Assistant (netca) et Server Control (srvctl). Par exemple, pour
exécuter l'assistant Database Configuration Assistant, entrez la commande dbca.
Par défaut, Oracle active la fonction de trace pour dbca et dbua. Les fichiers journaux qui en
résultent sont écrits respectivement dans $ORACLE_HOME/cfgtoollogs/dbca/ et
$ORACLE_HOME/cfgtoollogs/dbua. Pour cluvfy, gsdctl et SRVCTL, vous pouvez
définir la variable d'environnement SRVM_TRACE avec la valeur TRUE pour que le système
génère des traces. Les traces sont écrites dans des fichiers journaux ou transmises à la sortie
standard. Par exemple, le système peut les stocker dans des fichiers journaux figurant dans le
répertoire <Grid_Home>/cv/log/ pour cluvfy. Toutefois, comme illustré dans la
diapositive, il transmet les traces directement à la sortie standard pour srvctl.

Préserver les fichiers journaux avant leur réutilisation
• Ecrivez un script shell pour copier les fichiers journaux

avant qu'ils soient réutilisés.
# Script to archive log files before wrapping occurs
# Written for CSS logs. Modify for other log file types.
CSSLOGDIR=/u01/app/11.2.0/grid/log/host01/cssd
while [ 1 –ne 0 ]; do
CSSFILE=/tmp/css_`date +%m%d%y"_"%H%M`.tar

tar -cf $CSSFILE $CSSLOGDIR/*
sleep 300
done
exit
• Exécutez le script créé en arrière-plan.

# chmod 755 archscript.sh; nohup ./archscript.sh &
Préserver les fichiers journaux avant leur réutilisation

En fonction du niveau de débogage qui a été activé, les fichiers journaux peuvent être
réutilisés et leur contenu écrasé, ce qui limite la quantité d'informations disponible pour la
résolution des problèmes. Pour éviter la perte d'informations, créez un script qui copie tous les
fichiers de journalisation avant qu'ils soient réutilisés, comme illustré dans la diapositive.
Exécutez ce script en arrière-plan pour capturer les fichiers de journalisation tant que le
débogage est activé. Arrêtez-le lorsqu'il n'est plus nécessaire de capturer les fichiers journaux.
Cette technique peut être appliquée à n'importe quel fichier journal pour lequel elle est
nécessaire. Les fichiers journaux CSS sont indiqués à titre d'exemple. Les journaux Oracle
Clusterware bénéficient déjà d'un mécanisme de rotation qui assure leur sauvegarde, mais si
les niveaux de débogage activés sont élevés, ils peuvent être réutilisés.

Processus susceptibles de redémarrer

des noeuds
Les processus suivants peuvent éliminer des noeuds du
cluster ou redémarrer des noeuds :
• hangcheck-timer : Surveille les pannes et les pauses
d'une machine.
• oclskd : Est utilisé par CSS pour redémarrer un noeud
en fonction des demandes d'autres noeuds du cluster.

• ocssd : Surveille l'état des noeuds.
Processus susceptibles de redémarrer des noeuds

Sur les systèmes Linux, le module hangcheck-timer est un module du noyau qui surveille
les pannes et les pauses pour lesquels l'exécution du système reprend après un certain temps sans
que l'horloge note le temps perdu. Si le temps perdu dépasse un certain seuil, le module
redémarre le noeud. CSS utilise le démon Oracle Clusterware Kill Daemon (oclskd) pour
arrêter les processus liés aux membres du groupe CSS pour lesquels des demandes d'arrêt sont
arrivées.
Le démon CSSDMONITOR surveille le démon OCSSD pour identifier les problèmes d'arrêt ou
de planification. Il peut redémarrer un noeud s'il détecte une panne. Si le démon OCSSD est
perdu, le noeud est réinitialisé.
Remarque : Le module hangcheck-timer est nécessaire pour les bases de données RAC
Oracle Database 11g Release 1, mais il ne l'est plus pour Oracle Database 11g Release 2 RAC.

Identifier le processus à l'origine

d'un redémarrage
Le plus souvent, le processus écrit des messages d'erreur
dans son fichier journal lorsqu'une réinitialisation est requise.
• ocssd
– /var/log/messages
– <Grid_Home>/log/<hostname>/cssd/ocssd.log
• oclskd

– <Grid_Home>/log/<hostname>/client/oclskd.log
• hangcheck-timer
– /var/log/messages
Identifier le processus à l'origine d'un redémarrage

Tout d'abord, déterminez l'heure de la réinitialisation du noeud. Pour cela, vous pouvez
utiliser la commande uptime et soustraire la valeur obtenue de l'heure système actuelle.
Ensuite, utilisez l'heure du redémarrage pour analyser les fichiers journaux.
Lorsque le démon OCSSD est chargé de redémarrer un noeud, un message du type "Oracle
CSSD failure. Rebooting for cluster integrity." est écrite dans le fichier des messages système,
dans le répertoire /var/log/messages. Par ailleurs, le journal du démon cssd, stocké
dans <Grid_Home>/log/<hostname>/cssd/ocssd.log, peut contenir des
messages du type "Begin Dump" ou "End Dump" juste avant le redémarrage. Si ces
fichiers ne vous permettent pas d'identifier le processus qui a entraîné la réinitialisation,
il peut être nécessaire d'activer des options de débogage et de trace supplémentaires.
Si le module hangcheck-timer est utilisé, il consigne des messages dans le journal
système lorsqu'une panne est détectée et il redémarre le noeud. Pour vérifier si ce processus
est responsable de la réinitialisation du noeud, examinez le fichier /var/log/messages
et recherchez un message d'erreur similaire à "Hangcheck: hangcheck is
restarting the machine".
Remarque : Les processus en arrière-plan oclsomon et oprocd ont été supprimés d'Oracle
Database 11g Release 2.

Utiliser diagwait pour la résolution

des problèmes d'éviction
Lorsqu'un noeud est éliminé sur un système présentant une charge
importante, il peut arriver que le système d'exploitation n'ait pas le
temps de vider les journaux et les fichiers trace avant le redémarrage.
• Utilisez l'attribut CSS diagwait pour accorder plus de temps
à cette opération.
• Cela ne garantit pas que les journaux sont écrits.
• La valeur recommandée est de 13 secondes.

• Le paramètre d'attente au niveau cluster doit être modifié.
• Il n'est pas activé par défaut.
– Pour l'activer :
# crsctl set css diagwait 13 -force
– Pour le désactiver :
# crsctl unset css diagwait
Utiliser diagwait pour la résolution des problèmes d'éviction

Lorsqu'un noeud est éliminé alors qu'il présente une charge importante en termes de CPU
(ou par manque de ressources), il est possible que le système d'exploitation n'ait pas le temps
de vider les fichiers journaux et les fichiers trace avant de le redémarrer. Cela peut entraîner la
perte d'informations de diagnostic qui seraient utiles pour déterminer les causes de l'éviction
du noeud. En utilisant l'attribut CSS diagwait, il est possible d'accorder plus de temps à
l'écriture des fichiers journaux et de trace avant le redémarrage du noeud. Oracle recommande
de définir diagwait avec une valeur de 13 secondes pour tous les clients de base de
données RAC Oracle 10g et Oracle 11g. Cela ne garantit pas nécessairement l'écriture des
fichiers, mais favorise cette opération. Pour modifier l'attribut CSS diagwait, une coupure
au niveau cluster est requise. L'attribut CSS diagwait n'est pas activé par défaut.

Module hangcheck-timer du noyau Linux
• Le module hangcheck-timer du noyau n'est pas requis pour

les bases de données RAC Oracle Database 11g Release 2.
• Il est toujours nécessaire pour les bases de données RAC
Oracle Database 11g Release 1.
• Il n'est pas nécessairement chargé par défaut.
• Les valeurs par défaut doivent être modifiées explicitement.
• Le module accepte trois paramètres :

– hangcheck_tick (valeur recommandée : 1 seconde)
– hangcheck_margin (valeur recommandée : 10 secondes)
– hangcheck_reboot (valeur recommandée : 1)
• La valeur (CSS misscount) doit être supérieure à
(hangcheck_tick + hangcheck_margin).
Module hangcheck-timer du noyau Linux

Pour le système d'exploitation Linux, le module hangcheck-timer est nécessaire pour
toutes les installations de base de données Oracle RAC. Le module hangcheck-timer a
été inclus dans le noyau Linux avant l'introduction de OPROCD dans Oracle version 10.2.0.4.
Depuis Oracle Database 11g Release 2, le module hangcheck-kernel n'est plus
nécessaire. En revanche, les bases RAC Oracle Database 11g Release 1 utilisent toujours
hangcheck-timer et oprocd. Le module hangcheck-timer du noyau ne redémarre
jamais un noeud à cause d'un manque de CPU, mais uniquement suite à une panne du noyau
ou d'un pilote de périphérique. OPROCD a été introduit pour permettre de détecter plus de
pannes que le module hangcheck-timer.
Le module hangcheck-timer doit être chargé pour le compte de l'utilisateur root à
l'aide de la commande insmod ou modprobe chaque fois qu'une machine est redémarrée.
Le module accepte trois paramètres. Le paramètre hangcheck_tick définit la durée en
secondes entre les différents intervalles de vérification. Le paramètre hangcheck_margin
définit la marge admise, en secondes, entre l'heure prévue et l'heure réelle. Les valeurs
recommandées étaient de 30 secondes et de 180 secondes pour Oracle Database 9i. Pour
Oracle Database 10g et 11g, les valeurs recommandées sont de 1 et
10 secondes. Le noeud n'est pas redémarré si hangcheck_reboot a la valeur 0, alors qu'il
l'est si le paramètre a la valeur 1. La valeur par défaut était 1 pour Oracle Enterprise Linux 4,
tandis qu'il s'agit de 0 pour Oracle Enterprise Linux 5.

Configurer le module du noyau

hangcheck-timer
1. Si vous effectuez la configuration pour une base de données
RAC Oracle 11g R1, ajoutez les options suivantes dans le fichier
/etc/modprobe.conf:
options hangcheck-timer hangcheck_tick=1
hangcheck_margin=10 hangcheck_reboot=1
2. Ajoutez l'instruction suivante dans /etc/rc.local pour
installer le module à chaque redémarrage (selon la version du
système d'exploitation) :

/sbin/modprobe hangcheck-timer
3. Chargez les nouvelles valeurs de hangcheck-timer :
# sbin/modprobe -v hangcheck-timer
4. Validez les options hangcheck-timer qui sont chargées :
# grep Hangcheck /var/log/messages
Configurer le module du noyau hangcheck-timer

Le module hangcheck-timer du noyau n'est pas nécessairement chargé par défaut. Pour
le noyau Linux 2.6, la valeur par défaut de hangcheck_reboot est désormais 0, ce qui est
incorrect pour les systèmes Oracle. Le paramètre hangcheck-timer doit être configuré
pour les systèmes Oracle. Démarrez à l'étape 1 pour éditer le fichier
/etc/modprobe.conf de manière à définir les valeurs recommandées chaque fois que le
module est chargé. A l'étape 2, ajoutez une commande chargeant le module du noyau chaque
fois que le noeud est réinitialisé. La syntaxe présentée dans la diapositive ci-dessus est
simplement un exemple. La commande insmod peut être utilisée à la place de la commande
modprobe. Des fichiers de démarrage autres que /etc/rc.local peuvent être utilisés.
Lorsque le module du noyau est chargé, des messages sont écrits dans le fichier des messages
système. Ils indiquent les valeurs qui ont été utilisées pour les paramètres lors du chargement.
Vérifiez les valeurs chargées en consultant le fichier des messages système pour vous assurer
que les paramètres appropriés ont été obtenus à partir du fichier /etc/modprobe.conf.
La présence du message "Hangcheck: hangcheck value past margin" dans le fichier des
messages système indique que hangcheck-timer a été chargé sans que soit défini
hangcheck_reboot=1. Une réinitialisation était nécessaire, mais n'a pas été exécutée.
Corrigez les paramètres de hangcheck-timer et rechargez le module.

Eviter les redémarrages intempestifs
• Pour déterminer la valeur en cours du paramètre

CSS misscount :
# crsctl get css misscount
• Vérifiez que : (CSS misscount) > (TIMEOUT + MARGIN)

• Vérifiez que : (CSS misscount) > diagwait

• Pour modifier le paramètre CSS misscount (valeur par défaut
de 30 secondes recommandée) :
# crsctl set css misscount 45
Eviter les redémarrages intempestifs

On parle de redémarrage intempestif lorsqu'un noeud est initialisé alors qu'il n'y avait aucune
éviction CSS formelle en cours. Une telle opération peut se produire lorsque MARGIN a une
valeur faible tandis que la charge CPU est élevée, ou à la suite d'une erreur du planificateur.
Les valeurs par défaut conviennent dans la plupart des cas. Toutefois, il existe de grandes
variations dans les temps d'attente entre différents systèmes d'exploitation et entre différentes
versions, qui peuvent entraîner les réinitialisations inutiles ou erronées.
Augmentez la valeur de l'attribut CSS diagwait si elle est trop faible et que vous constatez
des redémarrages intempestifs. Si le module hangcheck-timer est à l'origine de ces
redémarrages, augmentez la valeur du paramètre hangcheck_margin du module noyau
hangcheck-timer. Si les valeurs de diagwait ou hangcheck_margin ont été
augmentées, vérifiez les points suivants :
(CSS misscount) > (TIMEOUT + MARGIN)
(CSS misscount) > diagwait
(CSS misscount) > (hangcheck_tick + hangcheck_margin)
Le redémarrage dû au dépassement de la valeur misscount n'est pas considéré comme
intempestif. Si vous obtenez le message "Configuration parameter misscount is not defined"
lors de la vérification du paramètre CSS misscount, la valeur par défaut de 30 secondes
est utilisée.
Remarque : Ne modifiez la valeur du paramètre "misscount" ou du délai d'attente de disque
que sur la recommandation du support technique Oracle.

Utiliser ocrdump pour afficher le contenu logique

du registre OCR
• Pour faire un dump du registre OCR dans un fichier texte en vue
de sa lecture :
[grid]$ ocrdump filename_with_limited_results.txt
[root]# ocrdump filename_with_full_results.txt

• Pour faire un dump du registre OCR pour une clé particulière :

# ocrdump –keyname SYSTEM.language
• Pour faire un dump du registre OCR vers stdout au format

XML :
# ocrdump –stdout -xml
• Pour faire un dump du fichier de sauvegarde OCR :

# ocrdump –backupfile week.ocr
Utiliser ocrdump pour afficher le contenu logique du registre OCR

L'utilitaire ocrdump peut être employé pour afficher le contenu du registre OCR pour le
débogage. L'utilitaire ocrdump permet d'afficher les informations logique en stockant le
contenu dans un fichier ou en l'affichant sur stdout dans un format lisible. Si la commande
ocrdump est exécutée sans option, un fichier portant le nom par défaut OCRDUMPFILE est
écrit dans le répertoire en cours, à condition que ce répertoire soit accessible en écriture. Les
informations contenues dans le registre OCR sont organisées à l'aide de clés associées à des
privilèges. Par conséquent, l'utilisateur root ne voit pas les mêmes résultats que le
propriétaire du clusterware. Par exemple :
Pour root, ocrdump –stdout | wc –l renvoie 3355 lignes sur un système de test
tandis que
pour grid, ocrdump –stdout | wc –l renvoie 521 lignes sur le même système.
Le nombre de lignes d'informations du fichier OCR dépend de nombreux facteurs tels que le
nombre de noeuds du cluster et le nombre de ressources enregistrées dans ce fichier. Les
valeurs que vous obtenez sont donc différentes.
Pour déterminer toutes les modifications qui se sont produites dans le fichier OCR au cours de
la semaine qui précède, localisez la sauvegarde automatique de cette semaine et comparez-la
à un dump du registre OCR en cours, comme suit :
# ocrdump
# ocrdump –stdout –backupfile week.ocr | diff - OCRDUMPFILE

Vérifier l'intégrité du registre OCR
Utilisez la commande ocrcheck pour vérifier l'intégrité

du fichier OCR.
$ ocrcheck
Status of Oracle Cluster Registry is as follows :
Version : 2
Total space (kbytes) : 275980
Used space (kbytes) : 2824

Available space (kbytes) : 273156
ID : 1274772838
Device/File Name : +DATA1
Device/File Name : +DATA2
Cluster registry integrity check succeeded
Logical corruption check succeeded
Vérifier l'intégrité du registre OCR

L'utilitaire ocrcheck affiche la version du format de bloc du registre OCR, l'espace total
disponible et l'espace utilisé, la valeur OCRID et les emplacements configurés pour le registre
OCR. L'utilitaire ocrcheck effectue une vérification de checksum bloc par bloc pour tous
les fichiers OCR configurés. Par ailleurs, il renvoie le statut de chaque fichier, ainsi que le
résultat du contrôle d'intégrité de l'ensemble du registre OCR.

Outils de débogage du registre OCR
• Outils OCR :
– ocrdump
– ocrconfig
– ocrcheck
– srvctl
• Les journaux sont générés dans le répertoire suivant :

<Grid_Home>/log/<hostname>/client/
• Le débogage est contrôlé par le fichier suivant :
<Grid_Home>/srvm/admin/ocrlog.ini
mesg_logging_level = 5
comploglvl="OCRAPI:5 ; OCRSRV:5; OCRCAC:5; OCRMAS:5; OCRCONF:5; OCRRAW:5"
comptrclvl="OCRAPI:5 ; OCRSRV:5; OCRCAC:5; OCRMAS:5; OCRCONF:5; OCRRAW:5"
Outils de débogage du registre OCR

Comme nous l'avons vu précédemment, différents outils peuvent être utilisés pour manipuler
le registre OCR : ocrdump, ocrconfig, ocrcheck et srvctl.
Ces utilitaires créent des fichiers journaux dans
<Grid_Home>/log/<hostname>/client/. Pour changer la quantité d'informations
journalisées, modifiez le fichier <Grid_Home>/srvm/admin/ocrlog.ini. Le niveau
de journalisation par défaut est 0, qui correspond à une journalisation minimale. Lorsque la
valeur de mesg_logging_level est 0 (valeur par défaut), seules les conditions d'erreur
sont consignées. Vous pouvez adopter la valeur 3 ou 5 pour obtenir des informations plus
détaillées.
Si cela ne suffit pas, vous pouvez également modifier les niveaux de journalisation et de trace
pour chacun des composants utilisés pour la manipulation du registre OCR. Pour cela,
modifiez les entrées contenant comploglvl et comptrclvl dans le fichier
ocrlog.ini.
La diapositive ci-dessus présente les trois lignes que vous pouvez ajouter au fichier
ocrlog.ini pour obtenir des informations de débogage supplémentaires. Par exemple,
vous pouvez être amené à modifier le fichier ocrlog.ini si vous obtenez des erreurs
pendant l'utilisation de l'outil ocrdump ou ocrconfig.

Effectuer des recherches dans la page

My Oracle Support - Knowledge

Effectuer des recherches dans la page My Oracle Support - Knowledge

My Oracle Support est la nouvelle plate-forme d'assistance fournie par Oracle. Elle intègre un
gestionnaire de configuration des logiciels qui permet d'effectuer les configurations requises
dans le cadre du processus de support. Il suffit d'installer ce gestionnaire et de charger les
données de configuration pour bénéficier de fonctionnalités d'assistance personnalisées et
proactives, qui exploitent la vaste base de connaissances Oracle. Les conseils fournis incluent
des contrôles personnalisés de la sécurité et de l'état des produits qui identifient les problèmes
avant qu'ils n'affectent les performances du système et recommandent des correctifs. Une
personne de votre organisation doit être désignée en tant qu'administrateur de My Oracle
Support. Elle est chargée de créer des comptes supplémentaires pour les autres membres de
l'entreprise. Une fois connecté au site http://support.oracle.com, vous pouvez accéder à la
page Knowledge Articles pour résoudre les problèmes liés à Oracle Clusterware.

Synthèse

• localiser les fichiers journaux d'Oracle Clusterware
• collecter tous les fichiers journaux avec
diagcollection.pl
• activer le débogage des ressources
• activer le débogage au niveau composant

• activer la fonction de trace pour les outils basés sur Java
• résoudre les problèmes liés au registre OCR
(Oracle Cluster Registry)

Quiz
Le module hangcheck-timer peut provoquer des

redémarrages intempestifs dans les clusters Oracle Grid
Infrastructure 11g Release 2.
1. Vrai
2. Faux

Réponse : 2
Faux. Le module hangcheck-timer n'est plus nécessaire dans les clusters Oracle Grid
Infrastructure 11g Release 2.

Quiz
Parmi les affirmations suivantes concernant cluvfy,

lesquelles sont vraies ?
1. Vous l'utilisez pour effectuer une vérification complète de la
couche.
2. Il applique une méthodologie de vérification non intrusive.
3. Il fonctionne uniquement sur les clusters utilisant ASM pour

le stockage partagé.
4. Vous pouvez générer des scripts de correction avec
certaines commandes de l'utilitaire CVU à l'aide de
l'indicateur -fixup.
Réponses : 1, 2, 4
Les affirmations 1, 2 et 4 sont correctes.


• utiliser les fichiers de journalisation
• utiliser ocrdump
• utiliser cluvfy




Gérer les instances ASM

Objectifs

• décrire et utiliser les paramètres d'initialisation ASM
(Automatic Storage Management)
• gérer les instances ASM et les processus associés
• surveiller ASM à l'aide des vues dynamiques des
performances V$ASM


Paramètres d'initialisation ASM
• Les paramètres d'initialisation ASM peuvent être définis :

– Une fois l'installation terminée, à l'aide des instructions SQL
ALTER SYSTEM ou ALTER SESSION.
• INSTANCE_TYPE=ASM est le seul paramétrage obligatoire.
• Il existe plusieurs paramètres propres à ASM.
– Ils ont des noms commençant par ASM_.

• Certains paramètres de base de données sont valides
pour ASM.
– Par exemple, MEMORY_TARGET.
• Vous pouvez utiliser un fichier PFILE ou SPFILE pour
gérer les paramètres.
Paramètres d'initialisation ASM

Pour modifier les paramètres d'initialisation d'une instance ASM après l'installation, vous
pouvez utiliser Enterprise Manager ou les instructions SQL ALTER SYSTEM ou ALTER
SESSION.
Il existe trois groupes de paramètres pour une instance ASM : les paramètres obligatoires, les
paramètres réservés à ASM et les paramètres qui sont également valides pour la base de
données. INSTANCE_TYPE est le seul paramètre obligatoire pour ASM. Les paramètres
propres à ASM ont des noms commençant par ASM_. Leurs valeurs par défaut conviennent
pour la plupart des environnements. Certains paramètres d'initialisation de la base de données
sont également valides pour ASM (par exemple, MEMORY TARGET). Généralement, ASM
utilise des valeurs par défaut appropriées pour ces paramètres de base de données.
Oracle recommande vivement d'utiliser un fichier de paramètres serveur (SPFILE) comme
fichier de paramètres d'une instance ASM. Le fichier SPFILE est mis à jour par l'instance. Il
doit donc être dans un emplacement partagé. Dans un environnement ASM clusterisé, le
fichier SPFILE est placé par défaut dans un groupe de disques ASM. Il peut également être
situé dans un système de fichiers clusterisé. Vous pouvez utiliser un fichier de paramètres
d'initialisation au format texte (PFILE) avec les fichiers PFILE de chaque noeud du cluster,
mais ils doivent être mis à jour manuellement et synchronisés.

Paramètres d'initialisation ASM (suite)

Les règles concernant le nom du fichier, l'emplacement par défaut et l'ordre de recherche qui
s'appliquent aux fichiers de paramètres d'initialisation de base de données s'appliquent aux
fichiers de paramètres d'initialisation ASM. L'ordre de recherche est le suivant :
l'emplacement défini dans le profil Grid Plug and Play, puis un fichier SPFILE dans le
répertoire d'origine Oracle Home, enfin un fichier PFILE dans le répertoire d'origine Oracle
Home. L'emplacement par défaut du fichier PFILE de l'instance +ASM1 est :
$ORACLE_HOME/dbs/spfile+ASM1.ora

Paramètre ASM_DISKGROUPS
ASM_DISKGROUPS indique les groupes de disques qui sont montés

automatiquement par ASM au démarrage de l'instance.
• Sa valeur par défaut est NULL.
• Il est ignoré dans certaines circonstances :
– Si ASM est démarré avec l'option NOMOUNT
– Si tous les groupes de disques sont montés explicitement
• Il peut être défini dynamiquement à l'aide de l'instruction ALTER

SYSTEM.
• Il est automatiquement modifié lorsque des groupes de disques
sont ajoutés, supprimés, montés ou démontés si vous utilisez un
fichier SPFILE.
• Il doit être ajusté manuellement si vous utilisez un fichier PFILE.
– Sauf lorsque ASMCA est utilisé pour créer un nouveau groupe de
disques.
Paramètre ASM_DISKGROUPS
Le paramètre d'initialisation ASM_DISKGROUPS définit la liste des groupes de disques qui
sont automatiquement montés par ASM au démarrage d'une instance. La valeur par défaut du
paramètre ASM_DISKGROUPS est la chaîne NULL.
Le paramètre ASM DISKGROUPS est ignoré lorsque vous indiquez l'option NOMOUNT au
démarrage de l'instance ou lorsque vous exécutez l'instruction ALTER DISKGROUP ALL
MOUNT.
Le paramètre ASM_DISKGROUPS est dynamique. Voici un exemple de définition de
ASM_DISKGROUPS :
ALTER SYSTEM SET ASM_DISKGROUPS = 'DATA, LOG, STANDBY'
Lorsqu'un fichier SPFILE est utilisé, ASM_DISKGROUPS est modifié chaque fois qu'un groupe
de disques est monté, démonté, créé ou supprimé. Lorsque vous utilisez ASMCMD ou
SQLPLUS pour monter un disque, le disque n'est monté que sur le noeud local et
ASM_DISKGROUPS n'est modifié que pour l'instance locale. Lorsque vous utilisez ASMCA
pour monter un groupe de disques, vous pouvez effectuer le montage localement ou sur tous
les noeuds. ASM_DISKGROUPS est modifié en fonction de votre choix. Avec Enterprise
Manager, vous pouvez choisir les noeuds sur lesquels vous voulez monter et démonter le
groupe. EM gère uniquement les noeuds sur lesquels il existe un agent.
Lorsque vous utilisez un fichier PFILE, vous devez modifier le fichier de paramètres
d'initialisation pour ajouter ou supprimer des noms de groupe de disques. Voici un exemple de
paramètre ASM_DISKGROUPS dans un fichier PFILE :
ASM_DISKGROUPS = 'DATA', 'LOG', 'STANDBY'

Groupes de disques montés au démarrage
Au démarrage, l'instance Oracle ASM tente de monter les

groupes de disques suivants :
• Groupes de disques désignés par le paramètre
d'initialisation ASM_DISKGROUPS
• Groupe de disques utilisé par les services CSS (Cluster
Synchronization Services) pour les fichiers votants

• Groupes de disques utilisés par Oracle Clusterware pour
le registre OCR (Oracle Cluster Registry)
• Groupe de disques utilisé par l'instance Oracle ASM pour
stocker le fichier de paramètres serveur (SPFILE) ASM
Groupes de disques montés au démarrage

Au démarrage, l'instance Oracle ASM tente de monter les groupes de disques suivants :
• Groupes de disques désignés par le paramètre d'initialisation ASM_DISKGROUPS
• Groupe de disques utilisé par les services CSS (Cluster Synchronization Services) pour
les fichiers votants
• Groupes de disques utilisés par Oracle Clusterware pour le registre OCR (Oracle Cluster
Registry)
• Groupe de disques utilisé par l'instance Oracle ASM pour stocker le fichier de paramètres
serveur (SPFILE) ASM
Si aucun groupe de disques de cette liste n'est trouvé, l'instance ASM ne monte aucun groupe
au démarrage.
Dans le cluster utilisé pour l'exercice, le groupe de disques DATA est monté car il inclut le
registre OCR, les fichiers votants et le fichier SPFILE pour l'instance ASM. Les groupes de
disques FRA et ACFS ne sont montés au démarrage que lorsqu'ils sont nommés dans le
paramètre d'initialisation ASM_DISKGROUPS.

Paramètre ASM_DISKSTRING
ASM DISKSTRING indique une liste de chaînes qui limite le jeu

de disques repérés par une instance ASM.
• Sa valeur par défaut est NULL.
– ASM explore un chemin par défaut et recherche les disques
auxquels il a accès en lecture et en écriture.
— Le chemin de recherche par défaut dépend de la plateforme.

— Le chemin de recherche par défaut inclut les disques Oracle
ASMLib.
• Il peut utiliser * et ? comme caractères génériques.
• Il peut être défini dynamiquement à l'aide de l'instruction
ALTER SYSTEM.
– Toutefois, une modification est rejetée si la valeur proposée
ne peut pas être utilisée pour trouver tous les disques
appartenant aux groupes actuellement montés.
Paramètre ASM_DISKSTRING
Le paramètre d'initialisation ASM_DISKSTRING indique une liste de chaînes séparées par
une virgule qui limite le jeu de disques repérés par une instance ASM. Seuls les disques qui
correspondent à une des chaînes sont découverts.
Les chaînes de repérage peuvent inclure des caractères génériques. Le caractère * représente
un nombre quelconque de caractères. Le caractère ?, lorsqu''il est utilisé comme premier
caractère d'un chemin, définit une extension vers le répertoire d'origine ORACLE_HOME.
Lorsque vous utilisez ? ailleurs dans le chemin, il représente un caractère quelconque, en
fonction du système d'exploitation. Sur les systèmes Linux et UNIX, d'autres modèles de
caractères génériques peuvent être utilisés.
Le format de la chaîne de repérage dépend de la bibliothèque ASM et du système
d'exploitation utilisés. Par exemple, sur un serveur Linux qui n'utilise pas ASMLib, pour
limiter le processus de repérage aux disques qui correspondent au modèle /dev/sd*,
définissez ASM_DISKSTRING = /dev/sd *
Pour limiter le processus de repérage résultats aux disques dont le nom finit par 3 ou 4,
définissez ASM_DISKSTRING = /dev/sd *3, /dev/sd *4.

Paramètre ASM_DISKSTRING (suite)
La valeur par défaut du paramètre ASM_DISKSTRING est la chaîne NULL. Avec la valeur
NULL, ASM explore le chemin par défaut pour trouver tous les disques du système pour
lesquels l'instance ASM a un accès en lecture et en écriture. Le chemin de recherche par
défaut dépend de la plate-forme. La liste suivante affiche le chemin par défaut pour une
sélection de plates-formes courantes :
Linux : /dev/raw/*
AIX : /dev/rhdisk*
HP-UX : /dev/rdisk/*
Solaris : /dev/rdsk/*

Windows : \\.\ORCLDISKn
Notez que la valeur par défaut de ASM_DISKSTRING ne permet pas toujours de trouver tous
les disques. Si votre installation utilise la fonctionnalité de chemins d'accès multiples
(multipathing), le logiciel peut définir des pseudodevices dans un chemin différent du chemin
par défaut du système d'exploitation. Si votre site utilise le package ASMLib d'un fournisseur
tiers, il se peut que ce dernier ait des conventions spécifiques pour les chaînes de repérage que
vous devez employer pour ASM_DISKSTRING.
Remarque : Etant donné que ASMLib est open source, il peut être proposé par des
fournisseurs autres qu'Oracle.
Si Oracle ASMLib est utilisé, le patch de recherche par défaut inclut également tous les
disques définis sur ASMLib. Le chemin par défaut qui désigne tous les disques Oracle
ASMLib est ORCL:*.
Si ASM est utilisé conjointement avec un serveur Oracle Exadata Storage Server, ajoutez le
chemin global de recherche o/*/* au paramètre ASM_DISKSTRING pour garantir le
repérage des disques Exadata Grid. Par exemple, la chaîne o/192.168.234.*/data*
permet de trouver tous les disques dont le nom commence par data pour une plage
d'adresses IP.
Le paramètre ASM_DISKSTRING est dynamique et peut être défini à l'aide de la commande
ALTER SYSTEM. Toute tentative de modification dynamique de ASM_DISKSTRING est
rejetée, et l'ancienne valeur est conservée si la nouvelle valeur ne peut pas être utilisée pour
repérer un disque qui appartient à un groupe déjà monté.
Remarque : ASM ne peut utiliser un disque que si toutes les instances ASM du cluster sont
en mesure de le trouver via l'une de leurs chaînes de repérage. Les noms n'ont pas besoin
d'être identiques sur chaque noeud, mais tous les disques doivent pouvoir être trouvés par tous
les noeuds du cluster. Cela peut nécessiter de modifier dynamiquement le paramètre
d'initialisation pour permettre l'ajout d'un nouveau stockage. Une telle modification requiert la
commande SQL suivante :
Pour modifier la chaîne de repérage des disques sur tous les noeuds du cluster :
ALTER SYSTEM SET asm_diskstring=value sid=*
Pour modifier la chaîne de repérage des disques sur l'instance +ASM1 uniquement :
ALTER SYSTEM SET asm_diskstring=value sid=+ASM1

Paramètre ASM_POWER_LIMIT
Le paramètre d'initialisation ASM_POWER_LIMIT définit la façon dont

s'effectue le rééquilibrage entre les disques.
• La valeur par défaut est 1.
– ASM effectue le rééquilibrage en utilisant un minimum de
ressources système.
• Les valeurs admises sont comprises entre 0 et 11.
– La valeur 0 désactive le rééquilibrage.

– Les valeurs les plus basses utilisent moins de ressources système
mais entraînent des opérations de rééquilibrage plus lentes.
– Les valeurs élevées utilisent plus de ressources système mais
permettent un rééquilibrage plus rapide.
• Ce paramètre peut être défini dynamiquement à l'aide de la
commande ALTER SYSTEM ou ALTER SESSION.
Paramètre ASM_POWER_LIMIT
Le paramètre d'initialisation ASM_POWER_LIMIT définit la façon dont s'effectue le
rééquilibrage entre les disques. La valeur par défaut est 1 et la plage de valeurs acceptables va
de 0 à 11. La valeur 0 désactive le rééquilibrage. Les valeurs numériques élevées permettent
un rééquilibrage plus rapide, mais au prix d'une plus grande utilisation des ressources système
et d'une surcharge d'E/S. Chaque instance peut avoir une valeur différente pour
ASM_POWER_LIMIT.

Paramètre INSTANCE_TYPE
INSTANCE_TYPE indique si l'instance est une instance de base

de données ou une instance ASM.
• Définissez INSTANCE_TYPE = ASM pour une instance
ASM.
• Il s'agit du seul paramètre obligatoire pour ASM.

Paramètre INSTANCE_TYPE
Le paramètre d'initialisation INSTANCE_TYPE doit être défini avec la valeur ASM pour une
instance ASM. Il s'agit d'un paramètre obligatoire qui ne peut pas être modifié. Voici un
exemple de paramètre INSTANCE_TYPE dans le fichier d'initialisation :
INSTANCE_TYPE = ASM

Paramètre CLUSTER_DATABASE
CLUSTER_DATABASE indique si la clusterisation du stockage

est ou non activée.
• Définissez CLUSTER_DATABASE = TRUE pour que
différentes instances ASM puissent accéder
simultanément aux mêmes disques ASM.
• Dans ce cas, ASM peut prendre en charge des bases de

données clusterisées (RAC) et monoinstances (non RAC).
Paramètre CLUSTER_DATABASE
Dans le cadre d'ASM, le paramètre d'instance CLUSTER_DATABASE indique si la
clusterisation du stockage est activée. Vous devez définir CLUSTER_DATABASE = TRUE
si vous souhaitez que différentes instances ASM clusterisées puissent accéder simultanément
aux mêmes disques ASM.
Notez qu'un système ASM clusterisé peut prendre en charge les bases de données RAC
(Real Application Clusters) et les bases monoinstances.
Remarque : Toutes les instances d'un cluster doivent avoir le même paramétrage.

Paramètre MEMORY_TARGET
MEMORY TARGET indique la mémoire totale utilisée par une

instance ASM.
• Oracle Corporation recommande fortement d'utiliser la
gestion automatique de la mémoire pour ASM.
• Tous les autres paramètres d'instance liés à la mémoire
sont ajustés automatiquement en fonction de
MEMORY_TARGET.

• La valeur par défaut de 272 Mo est adaptée à la plupart
des environnements.
• La valeur minimale de MEMORY_TARGET est de 256 Mo.
– Les valeurs inférieures à 256 Mo sont ignorées.
• Il est possible d'augmenter dynamiquement cette valeur
à l'aide de l' instruction ALTER SYSTEM.
Paramètre MEMORY_TARGET
Oracle Corporation recommande fortement d'utiliser la gestion automatique de la mémoire
(AMM - Automatic Memory Management) pour ASM. Cette fonctionnalité gère
automatiquement les paramètres liés à la mémoire des instances ASM en fonction du
paramètre MEMORY_TARGET. Elle est activée par défaut sur les instances ASM, même si le
paramètre MEMORY_TARGET n'est pas défini explicitement. La valeur par défaut utilisée
pour MEMORY_TARGET (272 Mo) est acceptable pour la plupart des environnements. Ce
paramètre est le seul à définir pour la gestion globale de la mémoire ASM.
Vous pouvez augmenter dynamiquement MEMORY_TARGET, jusqu'à la valeur
MEMORY_MAX_TARGET, tout comme pour une instance de base de données.
Remarque : Pour les environnements Linux, la gestion automatique de la mémoire ne
fonctionne pas si /dev/shm n'est pas disponible ou a une taille inférieure à
MEMORY_TARGET. Pour la version 5 d'Enterprise Linux, la taille par défaut de /dev/shm
est la moitié de celle de la mémoire système. Vous pouvez la modifier en ajoutant l'option
size à l'entrée /dev/shm dans /etc/fstab. Pour plus d'informations, consultez la page
man correspondante à la commande mount.
Remarque : La valeur minimum de MEMORY_TARGET pour ASM est de 256 Mo dans le
fichier SPFILE. Si vous indiquez une valeur inférieure pour MEMORY_TARGET, Oracle
Database la remplace automatiquement par la valeur 256 Mo.

Ajuster les paramètres des instances ASM

dans les fichiers SPFILE
• Le fichier de paramètres serveur (SPFILE) est un fichier
binaire qui ne peut pas être modifié à l'aide d'un éditeur de
texte.
• Pour ajuster les paramètres des instances ASM dans ce
fichier, utilisez Oracle Enterprise Manager ou la
commande SQL ALTER SYSTEM.

SQL> ALTER SYSTEM SET ASM_DISKSTRING='ORCL:*'
2> SID='*' SCOPE=SPFILE;
• Dans un environnement ASM clusterisé, les fichiers

SPFILE doivent résider dans ASM ou dans un système de
fichiers clusterisé.
Ajuster les paramètres des instances ASM dans les fichiers SPFILE
Vous pouvez utiliser un fichier de paramètres serveur (SPFILE) en tant que fichier de
paramètres pour les instances ASM. Le fichier SPFILE est un fichier binaire qui ne peut pas
être modifié à l'aide d'un éditeur de texte.
Vous pouvez utiliser Oracle Enterprise Manager ou la commande SQL ALTER SYSTEM pour
ajuster les paramètres des instances ASM dans un fichier SPFILE.
Par exemple, pour ajuster le fichier SPFILE afin que votre environnement ASM repère les
disques Oracle ASMLib, vous pouvez exécuter :
ALTER SYSTEM SET ASM_DISKSTRING='ORCL:*' SID='*' SCOPE=SPFILE;
Si vous utilisez SCOPE=SPFILE, seul le paramètre stocké dans le fichier SPFILE est
modifié. La modification n'affecte pas le paramètre actuel de l'instance ASM en cours
d'exécution. Si le paramètre peut être modifié dynamiquement, vous pouvez utiliser
SCOPE=MEMORY pour ajuster un paramètre pour une instance en cours d'exécution, ou bien
indiquer SCOPE=BOTH (ou omettre la clause SCOPE) pour ajuster dynamiquement un
paramètre et sauvegarder la modification dans le fichier SPFILE.
Vous pouvez ajouter une clause SID facultative pour indiquer que le paramètre s'applique à
une instance spécifique, ou utiliser la clause par défaut SID='*' pour indiquer explicitement
que le paramètre s'applique à toutes les instances. Par exemple, pour ajuster le fichier SPFILE
afin que l'instance +ASM1 utilise une valeur POWER_LIMIT spécifique, vous pouvez
exécuter :
ALTER SYSTEM SET ASM_POWER_LIMIT=5 SCOPE=SPFILE SID='+ASM1';
Si vous utilisez un fichier SPFILE dans un environnement ASM clusterisé, vous devez placer
le fichier SPFILE dans ASM, dans un système de fichiers NFS (Network-Attached Files) ou
dans un système de fichiers clusterisé.

Démarrer et arrêter des instances ASM

à l'aide de srvctl
L'utilitaire Server Control (srvctl) peut être utilisé pour
démarrer et arrêter des instances ASM.
• Un noeud à la fois :
$ srvctl start asm -n host01
$ srvctl start asm -n host02
$ srvctl status asm -n host01
ASM is running on host01.

ASM is running on host02.
• Tous les noeuds simultanément :

$ srvctl stop asm
ASM is not running on host01.
$ srvctl status asm
ASM is not running on host01,host02.
$
Démarrer et arrêter des instances ASM à l'aide de srvctl

L'utilitaire Server Control (srvctl) peut être utilisé pour démarrer et arrêter des instances
ASM avec d'autres ressources gérées par Oracle Clusterware. srvctl figure dans
l'emplacement Grid_home/bin défini au cours de l'installation d'Oracle Clusterware.
L'un des principaux avantages de srvctl est qu'il permet de démarrer ou d'arrêter toutes les
instances ASM du cluster à partir de n'importe quel noeud. srvctl permet de contrôler
ASM de différentes manières :
• Démarrer une instance ASM.
srvctl start asm [-n <node>] [-i <asm_inst>] [-o <start_option>]
<node> est le nom du noeud du cluster hébergeant l'instance ASM (facultatif). Si ce
paramètre n'est pas défini, l'instance ASM est démarrée sur tous les noeuds.
<asm_inst> est le nom de l'instance ASM concernée (facultatif).
<start_option> est l'une des options valides de démarrage d'instance (FORCE, MOUNT,
OPEN, NOMOUNT, ou RESTRICT) (facultatif).
• Arrêter une instance ASM.
srvctl stop asm [-n <node>] [-i <asm_inst>] [-o <stop_option>]
<stop_option> est l'une des options valides d'arrêt d'instance
(NORMAL, IMMEDIATE, TRANSACTIONAL, ou ABORT) (facultatif).
• Déterminer l'état d'une instance ASM.
srvctl status asm [-n <node>
Remarque : srvctl peut également être utilisé pour gérer une instance ASM non
clusterisée.


à l'aide de SQL*Plus
Le démarrage et l'arrêt d'instances ASM à l'aide de SQL*Plus est
similaire au démarrage et à l'arrêt d'instances de base de données.
$ export ORACLE_SID=+ASM1
$ export ORACLE_HOME=/u01/app/11.2.0/grid
$ $ORACLE_HOME/bin/sqlplus / AS SYSASM
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

With the Real Application Clusters and Automatic Storage Management

options
SQL> startup
ASM instance started
Total System Global Area 284565504 bytes

Fixed Size 1312896 bytes
Variable Size 258086784 bytes
ASM Cache 25165824 bytes
ASM diskgroups mounted
SQL>
Démarrer et arrêter des instances ASM à l'aide de SQL*Plus

Avec SQL*Plus, vous démarrez une instance ASM à l'aide de la commande STARTUP,
comme vous le feriez pour une instance de base de données Oracle. Vous devez tenir compte
des points suivants :
• Pour vous connecter à une instance ASM à l'aide de SQL*Plus, affectez à la variable
d'environnement ORACLE_SID le SID ASM. Par défaut, il s'agit de +ASM pour une base
de données monoinstance. Pour un noeud Oracle RAC, il s'agit de +ASMnode_number,
node_number correspondant au numéro du noeud.
• Affectez à la variable d'environnement ORACLE_HOME l'emplacement d'installation
d'ASM.
• Le fichier de paramètres d'initialisation doit contenir l'entrée suivante :
INSTANCE_TYPE = ASM
Ce paramètre indique que l'instance en cours de démarrage est une instance ASM et non
une instance de base de données.
• Lorsque vous exécutez la commande STARTUP au lieu d'essayer de monter et d'ouvrir la
base de données, elle tente de monter les groupes de disques indiqués par le paramètre
d'initialisation ASM_DISKGROUPS et par les règles de montage des groupes de disques.
Si aucun groupe de disques ne satisfait aux règles, l'instance ASM démarre et ASM
affiche un message signalant qu'aucun groupe de disques n'a été monté. Vous pouvez
ultérieurement monter les groupes de disques à l'aide de la commande ALTER
DISKGROUP...MOUNT.

Démarrer et arrêter des instances ASM à l'aide de SQL*Plus (suite)

La liste suivante décrit les paramètres de la commande STARTUP qui concernent ASM.
• FORCE : Transmet une commande SHUTDOWN ABORT à l'instance ASM avant de la
redémarrer.
• MOUNT ou OPEN : Monte les groupes de disques désignés par le paramètre
d'initialisation ASM_DISKGROUPS. Dans une instance ASM, MOUNT et OPEN sont
synonymes. OPEN est la valeur par défaut si aucun paramètre de commande n'est défini.
• NOMOUNT : Démarre l'instance ASM sans monter aucun groupe de disques.
• RESTRICT : Démarre une instance en mode d'accès restreint. La clause RESTRICT
peut être utilisée avec les clauses MOUNT, NOMOUNT et OPEN.
En mode d'accès restreint, les instances de base de données ne peuvent pas utiliser les

groupes de disques. Autrement dit, les bases de données ne peuvent pas ouvrir les
fichiers figurant dans les groupes. Par ailleurs, si un groupe de disques est monté par une
instance en mode restreint, il ne peut être monté par aucune autre instance du cluster. Le
mode restreint permet d'effectuer des tâches de maintenance sur un groupe de disques
sans être gêné par les accès client. Lorsque vous effectuez des opérations de
rééquilibrage pendant qu'un groupe de disques est en mode d'accès restreint, vous évitez
les messages de verrouillage et de déverrouillage qui sont générés entre les instances
ASM dans un environnement clusterisé. Cela améliore les performances. A la fin de la
période de maintenance, vous devez démonter le groupe de disques explicitement puis le
remonter en mode normal.
Le processus d'arrêt d'une instance ASM est lancé lorsque vous exécutez la commande
SHUTDOWN dans SQL*Plus. Au préalable, assurez-vous que les variables d'environnement
ORACLE_SID et ORACLE_HOME sont définies afin que vous puissiez vous connecter à
l'instance ASM.
Avant d'arrêter une instance ASM, il est fortement recommandé d'arrêter toutes les instances
de base de données qui l'utilisent.
La liste suivante décrit les paramètres de la commande SHUTDOWN qui concernent ASM.
• NORMAL : ASM attend la fin des instructions SQL en cours pour démonter tous les
groupes de disques et arrêter l'instance ASM. ASM attend également que tous les
utilisateurs se déconnectent de l'instance. Si plusieurs instances de base de données sont
connectées à l'instance ASM, la commande SHUTDOWN renvoie une erreur et laisse
l'instance ASM s'exécuter. NORMAL est le mode d'arrêt par défaut.
• IMMEDIATE ou TRANSACTIONAL : ASM attend la fin des instructions SQL en cours
pour démonter tous les groupes de disques et arrêter l'instance ASM. En revanche, il
n'attend pas que les utilisateurs actuellement connectés à l'instance soient déconnectés.
Si plusieurs instances de base de données sont connectées à l'instance ASM, la
commande SHUTDOWN renvoie une erreur et laisse l'instance ASM s'exécuter.

Démarrer et arrêter des instances ASM à l'aide de SQL*Plus (suite)

• ABORT : L'instance ASM est arrêtée immédiatement sans que les groupes de disques
soient démontés de manière ordonnée. Dans ce cas, la récupération a lieu au démarrage
suivant d'ASM. Si une instance de base de données est connectée à l'instance ASM, elle
est abandonnée.
Si les systèmes de fichiers clusterisés Oracle ACFS (Automatic Storage Management
Cluster File System) sont actuellement montés sur des volumes Oracle ADVM
#5/
&[PCOKE8QNWOG/CPCIGT, ces systèmes de fichiers doivent d'abord être démontés.
Sinon, les applications rencontreront des erreurs d'E/S, et il ne sera pas possible de
transmettre les informations utilisateur et les métadonnées Oracle ACFS avant
l'isolement du stockage ASM.
S'il existe des clients connectés à ASM, l'instance ASM ne s'arrête que si l'option abort

est utilisée.


avec ASMCA et ASMCMD

Démarrer et arrêter des instances ASM avec ASMCA et ASMCMD

L'utilitaire ASMCA illustré dans la diapositive ci-dessus permet de démarrer et d'arrêter une
instance ASM. L'utilitaire ASMCMD permet également de démarrer et d'arrêter les instances
ASM avec les commandes suivantes :
asmcmd start asm
$ asmcmd
ASMCMD [+] > shutdown
ASMCMD [+] > shutdown --immediate
ASMCMD [+] > shutdown --abort
ASMCMD> startup --nomount --pfile asm_init.ora
ASMCMD> startup –-mount


contenant des fichiers clusterisés
Les instances ASM contenant le registre OCR et les disques

votants :
• sont automatiquement redémarrées par le démon des
services de haute disponibilité
• utilisent crsctl stop crs

Démarrer et arrêter des instances ASM contenant des fichiers clusterisés

Les instances ASM qui contiennent les fichiers OCR et les fichiers du disque votant sont
automatiquement relancées par le démon des services de haute disponibilité. Les instances
ASM auxquelles des clients sont connectés ne peuvent pas être arrêtées, sauf avec
l'option abort.
Oracle Clusterware est un client ASM lorsque les fichiers OCR et les fichiers du disque votant
sont stockés dans des groupes de disques ASM. L'arrêt des services Oracle Clusterware inclut
l'arrêt d'ASM.

Démarrer et arrêter le processus d'écoute ASM
• Avec l'utilitaire lsnrctl :

$ lsnrctl start listener
LSNRCTL for Linux: Version 11.2.0.1.0 - Production on 08-OCT-2009
22:44:22
Copyright (c) 1991, 2009, Oracle. All rights reserved.
Starting /u01/app/11.2.0/grid/bin/tnslsnr: please wait...
... Intermediate output removed ...
The command completed successfully
$

• Avec l'utilitaire srvctl :
$ srvctl start listener -n host01
$
Démarrer et arrêter le processus d'écoute ASM

Un système ASM clusterisé standard configure un processus d'écoute réseau Oracle dans le
répertoire d'origine ASM. Ce processus d'écoute peut être démarré manuellement et arrêté
à l'aide de l'utilitaire lsnrctl installé dans le cadre de l'installation d'ASM :
$ lsnrctl start listener
$ lsnrctl stop listener
Vous pouvez également recourir à l'utilitaire Server Control (srvctl) pour démarrer et
arrêter le processus d'écoute ASM comme suit :
$ srvctl start listener –n <node>
$ srvctl stop listener –n <node>
Les utilitaires lsnrctl et srvctl existent dans les répertoires d'origine grid_home et
RDBMS Home. La version utilisée dépend de l'emplacement des fichiers de configuration du
processus d'écoute. L'installation de Grid Infrastructure démarre un processus d'écoute en
utilisant les fichiers de configuration qui figurent dans grid_home. Par défaut, l'installation de
la base de données utilise ce processus d'écoute. Dans ce cas, définissez les variables
d'environnement ORACLE_HOME et PATH de manière à ce qu'elles utilisent grid_home puis
exécutez les utilitaires.
Si vous créez un nouveau processus d'écoute en utilisant les fichiers de configuration qui
figurent dans le répertoire d'origine RDBMS Home, définissez les variables d'environnement
ORACLE_HOME et PATH de manière à ce qu'elles utilisent RDBMS Home puis exécutez
les utilitaires.

Vues dynamiques des performances ASM
L'instance ASM héberge les tables de métadonnées implantées en

mémoire et les présente sous forme de vues dynamiques des
performances.
• Ces vues sont employées par les utilitaires ASM pour extraire des
informations sur les métadonnées à l'aide d'instructions SQL.
• Il existe plusieurs vues dédiées à ASM, notamment :
V$ASM_ALIAS V$ASM_ATTRIBUTE V$ASM_CLIENT

V$ASM_DISK V$ASM_DISK_IOSTAT V$ASM_DISK_STAT
V$ASM_DISKGROUP V$ASM_DISKGROUP_STAT V$ASM_FILE
V$ASM_OPERATION V$ASM_TEMPLATE V$ASM_ACFSVOLUME
V$ASM_FILESYSTEM
Les vues V$ASM_* existent dans les instances ASM et les instances
de base de données. Les lignes renvoyées peuvent varier.
Vues dynamiques des performances ASM

Une instance ASM n'a pas de dictionnaire de données. Les informations concernant sa
configuration et son exécution peuvent être obtenues en interrogeant un ensemble de vues
dynamiques des performances. Les vues dynamiques des performances d'ASM ont des noms
commençant par V$ASM. Elles peuvent être interrogées à l'aide d'instructions SQL de la
même manière que n'importe quelle vue dynamique des performances de la base de données.
La diapositive ci-dessus répertorie les principales vues dynamiques des performances
contenant des métadonnées liées à ASM.
Les vues V$ASM existent dans les instances ASM et dans les instances de base de données. Si
vous interrogez une vue V$ASM tout en étant connecté à une instance ASM, vous obtenez les
informations relatives à l'instance ASM. Si vous interrogez une vue V$ASM en étant connecté
à une instance de base de données, certaines vues ne renvoient aucune information, tandis que
d'autres renvoient un sous-ensemble d'informations sur l'utilisation d'ASM dans cette instance
de base de données.
Dans un environnement clusterisé, les vues V$ASM sont complétées par des vues GV$ASM qui
leur correspondent. Les vues GV$ASM fournissent une vue consolidée des informations de
toutes les instances ASM du cluster. Chaque vue GV$ASM a la même structure que la vue
V$ASM correspondante, avec une colonne en plus, INST_ID, qui indique l'identificateur
d'instance associé à chaque enregistrement.
Remarque : Les vues dynamiques des performances d'ASM seront décrites ultérieurement
dans ce cours dans le contexte de diverses tâches d'administration. Pour obtenir la définition
complète de toutes les colonnes de chaque vue, reportez-vous au manuel Oracle Database
Reference 11g Release 2 dans la bibliothèque de documentation d'Oracle Database.

Screen reader h int: T his
slide conta ins a d iagra m that
is exp lain ed in t he sp eaker
notes.
Schéma des vues dynamiques

des performances d'ASM
V$ASM_FILE V$ASM_ALIAS V$ASM_ATTRIBUTE

V$ASM_OPERATION V$ASM_DISKGROUP V$ASM_DISK
V$ASM_DISK
V$ASM_TEMPLATE V$ASM_CLIENT
_IOSTAT
Schéma des vues dynamiques des performances d'ASM

Le schéma de la diapositive ci-dessus illustre les relations entre les vues dynamiques des
performances d'ASM. Notez que toutes les vues sont liées d'une manière ou d'une autre à la
vue V$ASM_DISKGROUP par le biais de la colonne GROUP_NUMBER.
Les relations indiquées dans le schéma peuvent également être décrites de la façon suivante :
• Un groupe de disques indiqué dans V$ASM_DISKGROUP peut contenir plusieurs fichiers
listés dans V$ASM_FILE.
• Un groupe de disques indiqué dans V$ASM_DISKGROUP peut contenir plusieurs alias
listés dans V$ASM_ALIAS.
• Un enregistrement de fichier indiqué dans la vue V$ASM_FILE a un nom de fichier et
peut avoir un alias indiqué dans V$ASM_ALIAS.
• Un nom de fichier indiqué dans V$ASM_ALIAS est lié à un enregistrement de fichier
contenu dans la vue V$ASM_FILE.
• Un alias de fichier indiqué dans la vue V$ASM_ALIAS est lié à un enregistrement de
fichier contenu dans la vue V$ASM_FILE.
• Un alias de répertoire indiqué dans la vue V$ASM_ALIAS n'a pas d'enregistrement
correspondant dans la vue V$ASM_FILE.
• Un alias de répertoire indiqué dans la vue V$ASM_ALIAS peut être le parent de
plusieurs noms et alias de fichiers répertoriés dans la vue V$ASM_ALIAS.

Schéma des vues dynamiques des performances d'ASM (suite)

• Un groupe de disques indiqué dans la vue V$ASM_DISKGROUP dispose d'attributs qui
sont listés dans la vue V$ASM_ATTRIBUTE si l'attribut COMPATIBLE.ASM
correspondant a la valeur 11.1 ou une valeur supérieure.
• Un groupe de disques indiqué dans la vue V$ASM_DISKGROUP peut faire l'objet d'une
opération de longue durée indiquée dans la vue V$ASM_OPERATION.
• Un groupe de disques indiqué dans la vue V$ASM_DISKGROUP peut contenir plusieurs
modèles listés dans la vue V$ASM_TEMPLATE.
• Un groupe de disques indiqué dans la vue V$ASM_DISKGROUP peut être utilisé par
plusieurs instances de base de données indiquées dans la vue V$ASM_CLIENT.
• Un groupe de disques indiqué dans la vue V$ASM_DISKGROUP peut contenir plusieurs

disques listés dans la vue V$ASM_DISK.
• Un client de base de données indiqué dans la vue V$ASM_CLIENT dispose de
nombreux enregistrements de performances répertoriés dans la vue V$ASM
DISK_IOSTAT, qui correspondent chacun à un disque indiqué dans la vue
V$ASM_DISK.
Remarque : Les vues V$ASM_DISKGROUP_STAT et V$ASM_DISK_STAT ne sont pas
présentées dans cette section. Elles sont identiques aux vues V$ASM_DISKGROUP et
V$ASM_DISK, respectivement. Ces vues sont décrites en détail dans le manuel
Oracle Database Reference 11g Release 2.

Quiz
Quelle est la configuration recommandée pour l'initialisation de

l'instance ASM :
1. Stockage du fichier SPFILE sur un raw device partagé
2. Utilisation d'un fichier de paramètres serveur (SPFILE)
3. Stockage d'une fichier SPFILE sur des disques distincts
4. Stockage d'un fichier SPFILE dans un groupe de disques

ASM
5. Utilisation d'un fichier de paramètres d'initialisation au
format texte (PFILE)
6. Utilisation d'un fichier PFILE référençant un fichier SPFILE
Réponses : 2 et 4

Quiz
La gestion automatique de la mémoire est activée sur les

instances ASM.
1. Vrai
2. Faux

Réponse : 1
Oracle Corporation recommande fortement d'utiliser la gestion automatique de la mémoire
(AMM) pour ASM.
La valeur par défaut utilisée pour MEMORY_TARGET (272 Mo) convient pour la plupart des
environnements. La valeur de MEMORY_TARGET est définie lors de l'installation et peut être
ajustée ultérieurement.

Synthèse

• décrire et utiliser les paramètres d'initialisation ASM
• gérer les instances ASM et les processus associés
• surveiller ASM à l'aide des vues dynamiques des
performances V$ASM


Présentation de l'exercice 7 :
Gérer les instances ASM
• ajuster les paramètres d'initialisation
• arrêter et démarrer des instances
• lancer Enterprise Manager
• surveiller le statut des instances



D59999FR10 sg1 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

D59999FR10 sg1 PDF

Transféré par

Droits d'auteur :

Formats disponibles

THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY.

COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED

Oracle University and CFAO THECHNOLOGIES use only

James Womack Avertissement

Oracle University and CFAO THECHNOLOGIES use only

1 Architecture d'Oracle Grid Infrastructure

Oracle University and CFAO THECHNOLOGIES use only

Utiliser un groupe OS unique 1-48

Oracle University and CFAO THECHNOLOGIES use only

2 Installation de Grid Infrastructure

Informations sur les noeuds du cluster 2-32

Oracle University and CFAO THECHNOLOGIES use only

3 Administrer Oracle Clusterware

Oracle University and CFAO THECHNOLOGIES use only

4 Gérer Oracle Clusterware

Installer un jeu de patches avec OUI 4-37

Oracle University and CFAO THECHNOLOGIES use only

Règle d'or pour le débogage d'Oracle Clusterware 6-3

Oracle University and CFAO THECHNOLOGIES use only

7 Gérer les instances ASM

Présentation de l'exercice 7 : Gérer les instances ASM 7-27

8 Gérer les groupes de disques ASM

Oracle University and CFAO THECHNOLOGIES use only

9 Gérer les fichiers, les répertoires et les modèles ASM

Accéder aux fichiers ASM à l'aide de l'utilitaire ASMCMD 9-10

Oracle University and CFAO THECHNOLOGIES use only

10 Gérer les systèmes de fichiers clusterisés ASM

Créer un volume ACFS via ASMCA 10-23

Oracle University and CFAO THECHNOLOGIES use only

Annexe A : Exercices et solutions

Annexe B: Cloner Oracle Clusterware

Copyright © 2010, Oracle. Tous droits réservés.

Oracle University and CFAO THECHNOLOGIES use only

A la fin de ce chapitre, vous pourrez :

Oracle University and CFAO THECHNOLOGIES use only

Copyright © 2010, Oracle. Tous droits réservés.

Oracle Grid Infrastructure 11g : Gestion des clusters et ASM 1 - 2

Oracle Grid Infrastructure

Oracle University and CFAO THECHNOLOGIES use only

Oracle Grid Infrastructure

Oracle Grid Infrastructure 11g : Gestion des clusters et ASM 1 - 3

Copyright © 2010, Oracle. Tous droits réservés.

Oracle Grid Infrastructure 11g : Gestion des clusters et ASM 1 - 4

Qu'est-ce qu'un cluster ?

• Groupe d'ordinateurs indépendants mais interconnectés

Oracle University and CFAO THECHNOLOGIES use only

Copyright © 2010, Oracle. Tous droits réservés.

Qu'est-ce qu'un cluster ?

Oracle Grid Infrastructure 11g : Gestion des clusters et ASM 1 - 5

Qu'est-ce qu'un clusterware ?

Logiciel qui fournit des interfaces et des services variés pour un

Oracle University and CFAO THECHNOLOGIES use only

Copyright © 2010, Oracle. Tous droits réservés.

Qu'est-ce qu'un clusterware ?

Oracle Grid Infrastructure 11g : Gestion des clusters et ASM 1 - 6

Oracle University and CFAO THECHNOLOGIES use only

Copyright © 2010, Oracle. Tous droits réservés.

Oracle Grid Infrastructure 11g : Gestion des clusters et ASM 1 - 7

Architecture et services d'Oracle Clusterware

• Architecture de cluster avec disque partagé prenant en

Oracle University and CFAO THECHNOLOGIES use only

Copyright © 2010, Oracle. Tous droits réservés.

Architecture et services d'Oracle Clusterware