JavaScript is required to for searching.
Ignorer les liens de navigation
Quitter l'aperu
Guide du service de données Oracle Solaris Cluster pour Oracle
search filter icon
search icon

Informations document

Préface

Installation et configuration de HA pour Oracle

Présentation du processus d'installation et de configuration de HA pour Oracle

Planification de l'installation et de la configuration de HA pour Oracle

Configuration requise

Questions relatives à la planification de la configuration

Préparer les noeliguds et disques

Préparation des noeliguds

Configuration de l'accès à la base de données Oracle à l'aide de Solaris Volume Manager

Configuration de l'accès à la base de données Oracle à l'aide de Veritas Volume Manager

Configuration de l'accès à la base de données Oracle à l'aide d'Oracle ASM

Installation du logiciel Oracle ASM

Vérification de l'installation du logiciel Oracle ASM

Installation du logiciel Oracle

Installation du logiciel Oracle

Configuration des paramètres du noyau Oracle

Vérification de l'installation et la configuration Oracle

Vérification de l'installation Oracle

Création d'une base de données Oracle

Création d'une base de données Oracle principale

Paramétrage des autorisations de base de données Oracle

Paramétrage d'autorisations de base de données Oracle

Installation des packages HA pour Oracle

Installation de packages HA pour Oracle

Enregistrement et configuration de HA pour Oracle

Outils permettant l'enregistrement et la configuration de HA pour Oracle

Paramétrage des propriétés d'extension HA pour Oracle

Enregistrement et configuration de HA pour Oracle à l'aide de l'utilitaire clsetup

Enregistrement et configuration de HA pour Oracle sans Oracle ASM à l'aide des commandes de maintenance d'Oracle Solaris Cluster

Enregistrement et configuration de HA pour Oracle avec une instance Oracle ASM unique à l'aide des commandes de maintenance d'Oracle Solaris Cluster

Enregistrement et configuration de HA pour Oracle avec une instance Oracle ASM en cluster à l'aide des commandes de maintenance d'Oracle Solaris Cluster

Par où continuer ?

Vérification de l'installation HA pour Oracle

Vérification de l'installation HA pour Oracle

Clients Oracle

Emplacement des fichiers journaux HA pour Oracle

Réglage des détecteurs de pannes HA pour Oracle

Fonctionnement du détecteur de pannes de serveur Oracle

Fonctionnement du détecteur de pannes principal

Fonctionnement du test de détection des pannes du client de base de données

Opérations de contrôle de la partition des journaux de restauration archivés

Opérations visant à déterminer si la base de données est opérationnelle

Actions effectuées par le détecteur de pannes de serveur en réponse à une panne de transaction de base de données

Analyse des alertes enregistrées par le détecteur de pannes de serveur

Fonctionnement du détecteur de pannes du listener Oracle

Obtention de fichiers Core pour le dépannage des délais d'attente de SGBD

Personnalisation du détecteur de pannes Serveur HA pour Oracle

Définition de comportements personnalisés pour les erreurs

Format de fichier d'actions personnalisées

Modification de la réponse à une erreur SGBD

Réponse à une erreur dont les effets sont majeurs

Ignorer une erreur dont les effets sont mineurs

Modification de la réponse aux alertes journalisées

Modification du nombre maximum de tests de délai d'attente dépassé consécutifs

Propagation d'un fichier d'actions personnalisées à tous les noeliguds d'un cluster

Spécification du fichier d'actions personnalisées qu'un détecteur de pannes de serveur doit utiliser

Spécification du fichier d'actions personnalisées qu'un détecteur de pannes de serveur doit utiliser

Mise à niveau des types de ressource HA pour Oracle

Mise à niveau du type de ressource SUNW.oracle_listener

Informations relatives à l'enregistrement de la nouvelle version du type de ressource

Informations relatives à la migration d'instances existantes du type de ressource

Mise à niveau du type de ressource SUNW.oracle_server

Informations relatives à l'enregistrement de la nouvelle version du type de ressource

Informations relatives à la migration d'instances existantes du type de ressource

Modification du rôle d'une instance Oracle Data Guard

Modification du rôle d'une instance Oracle Data Guard

A.  Propriétés d'extension de HA pour Oracle

B.  Actions prédéfinies des erreurs de SGBD et des alertes enregistrées

C.  Exemples de configuration pour Oracle ASM avec HA pour Oracle

Index

Personnalisation du détecteur de pannes Serveur HA pour Oracle

La personnalisation du détecteur de pannes Serveur HA pour Oracle permet de modifier le comportement du détecteur de pannes comme suit :


Attention

Attention - Avant de personnaliser le détecteur de pannes Serveur HA pour Oracle, réfléchissez aux conséquences, en particulier si vous modifiez une action de redémarrage ou de basculement afin qu'elle ignore ou arrête le contrôle. Si des erreurs ne sont pas corrigées pendant de longues périodes, elles peuvent causer des problèmes avec la base de données. Si vous êtes confronté à des problèmes avec la base de données après la personnalisation du détecteur de pannes Serveur HA pour Oracle, revenez aux actions prédéfinies. Le fait de repasser aux actions prédéfinies permet de déterminer si le problème provient de votre personnalisation.


La personnalisation du détecteur de pannes Serveur HA pour Oracle implique les activités suivantes :

  1. Définition de comportements personnalisés pour les erreurs

  2. Propagation d'un fichier d'actions personnalisées à tous les nœuds ou zones d'un cluster

  3. Spécification du fichier d'actions personnalisées qu'un détecteur de pannes de serveur doit utiliser

Définition de comportements personnalisés pour les erreurs

Le détecteur de pannes Serveur HA pour Oracle détecte les types d'erreur suivants :

Pour définir un comportement personnalisé pour ces types d'erreur, créez un fichier d'actions personnalisées. Cette section contient les informations suivantes concernant les fichiers d'actions personnalisées :

Format de fichier d'actions personnalisées

Un fichier d'actions personnalisées est un simple fichier texte. Le fichier contient une ou plusieurs entrées qui définissent le comportement personnalisé du détecteur de pannes Serveur HA pour Oracle. Chaque entrée définit le comportement personnalisé pour une erreur SGBD, une erreur de délai d'attente ou plusieurs alertes journalisées. Un fichier d'actions personnalisées peut contenir jusqu'à 1 024 entrées.


Remarque - Chaque entrée dans un fichier d'actions personnalisées remplace l'action prédéfinie pour une erreur ou spécifie une action pour une erreur pour laquelle aucune action n'est prédéfinie. Créez des entrées dans un fichier d'actions personnalisées uniquement pour les actions prédéfinies que vous remplacez ou pour les erreurs pour lesquelles aucune action n'est prédéfinie. Ne créez pas d'entrées pour les actions que vous ne modifiez pas.


Une entrée dans un fichier d'actions personnalisées se présente sous la forme d'une séquence de paires composées d'un mot-clé et d'une valeur séparées par des points-virgules. Chaque entrée est entourée par des accolades.

Le format d'une entrée de fichier d'actions personnalisées se présente comme suit :

{
[ERROR_TYPE=DBMS_ERROR|SCAN_LOG|TIMEOUT_ERROR;]
ERROR=error-spec; 
[ACTION=SWITCH|RESTART|STOP|NONE;]
[CONNECTION_STATE=co|di|on|*;]
[NEW_STATE=co|di|on|*;]
[MESSAGE="message-string"]
}

Des blancs peuvent être utilisés entre les paires de mot-clé et de valeurs séparées et entre les entrées pour formater le fichier.

La signification et les valeurs autorisées pour les mots-clés dans un fichier d'actions personnalisées sont les suivantes :

ERROR_TYPE

Indique le type de l'erreur que le détecteur de pannes de serveur a détecté. Les valeurs suivantes sont autorisées pour ce mot-clé :

DBMS_ERROR

Spécifie que l'erreur est une erreur SGBD.

SCAN_LOG

Spécifie que l'erreur est une alerte journalisée dans un fichier journal d'alertes.

TIMEOUT_ERROR

Spécifie que l'erreur est un dépassement de délai d'attente.

Le mot-clé ERROR_TYPE est facultatif. Si vous omettez ce mot-clé, l'erreur est considérée comme une erreur SGBD.

ERROR

Identifie les erreurs. Le type de données et la signification de error-spec sont déterminés par la valeur du mot-clé ERROR_TYPE comme le montre le tableau suivant.

ERROR_TYPE
Type de données
Signification
DBMS_ERROR
Nombre entier
Le numéro d'erreur d'une erreur SGBD généré par Oracle
SCAN_LOG
Expression régulière citée
Une chaîne dans un message d'erreur qu'Oracle a journalisé dans le fichier journal d'alertes d'Oracle
TIMEOUT_ERROR
Nombre entier
Le nombre de tests de délai dépassé consécutifs depuis la dernière fois que le détecteur de pannes de serveur a démarré ou redémarré

Vous devez spécifier le mot-clé ERROR. Si vous omettez ce mot-clé, l'entrée du fichier d'actions personnalisées est ignorée.

ACTION

Spécifie l'action que le détecteur de pannes de serveur doit effectuer en réponse à une erreur. Les valeurs suivantes sont autorisées pour ce mot-clé :

NONE

Spécifie que le détecteur de pannes de serveur ignore l'erreur.

STOP

Spécifie que le détecteur de pannes de serveur est arrêté.

RESTART

Spécifie que le détecteur de pannes de serveur arrête et redémarre l'entité spécifiée par la valeur de la propriété d'extension Restart_type de la ressource SUNW.oracle_server.

SWITCH

Spécifie que le détecteur de pannes de serveur bascule le groupe de ressources de la base de données sur un autre nœud ou une autre zone.

Le mot-clé ACTION est facultatif. Si vous omettez ce mot-clé, le détecteur de pannes de serveur ignore l'erreur.

CONNECTION_STATE

Spécifie l'état requis de la connexion entre la base de données et le détecteur de pannes de serveur quand une erreur est détectée. L'entrée s'applique uniquement si la connexion est dans l'état requis quand l'erreur est détectée. Les valeurs suivantes sont autorisées pour ce mot-clé :

*

Spécifie que l'entrée s'applique toujours, quel que soit l'état de la connexion.

co

Spécifie que l'entrée s'applique uniquement si le détecteur de pannes de serveur tente de se connecter à la base de données.

on

Spécifie que l'entrée s'applique uniquement si le détecteur de pannes de serveur est en ligne. Le détecteur de pannes de serveur est en ligne quand il est connecté à la base de données.

di

Spécifie que l'entrée s'applique uniquement si le détecteur de pannes de serveur se déconnecte de la base de données.

Le mot-clé CONNECTION_STATE est facultatif. Si vous omettez ce mot-clé, l'entrée s'applique toujours, quel que soit l'état de la connexion.

NEW_STATE

Spécifie l'état de la connexion entre la base de données et le détecteur de pannes de serveur que ce dernier doit atteindre une fois l'erreur détectée. Les valeurs suivantes sont autorisées pour ce mot-clé :

*

Spécifie que l'état de la connexion ne doit pas changer.

co

Spécifie que le détecteur de pannes de serveur doit se déconnecter de la base de données et s'y reconnecter immédiatement.

di

Spécifie que le détecteur de pannes de serveur doit se déconnecter de la base de données. Le détecteur de pannes de serveur se reconnecte à son prochain test de la base de données.

Le mot-clé NEW_STATE est facultatif. Si vous omettez ce mot-clé, l'état de la connexion de la base de données ne change pas une fois l'erreur détectée.

MESSAGE

Spécifie un message supplémentaire qui est ajouté au fichier journal quand l'erreur est détectée. Le message doit être entre guillemets. Ce message s'ajoute au message standard qui est défini pour l'erreur.

Le mot-clé MESSAGE est facultatif. Si vous omettez ce mot-clé, aucun message supplémentaire n'est ajouté au fichier journal de la ressource quand l'erreur est détectée.

Modification de la réponse à une erreur SGBD

L'action effectuée par le détecteur de pannes de serveur en réponse à chaque erreur de SGBD est prédéfinie comme indiqué dans la Tableau 1. Pour déterminer s'il vous est nécessaire de modifier la réponse à une erreur SGBD, prenez en considération l'effet des erreurs SGBD sur votre base de données pour déterminer si les actions prédéfinies sont appropriées. Pour obtenir des exemples, reportez-vous aux sous-sections suivantes :

Pour changer la réponse à une erreur SGBD, créez une entrée dans le fichier d'actions personnalisées dans lequel les mots-clés sont définis comme suit :

Réponse à une erreur dont les effets sont majeurs

Si une erreur que le détecteur de pannes de serveur ignore affecte plus d'une session, il peut s'avérer nécessaire que le détecteur de pannes de serveur exécute une action pour empêcher une perte de service.

Par exemple, aucune action n'est prédéfinie pour l'erreur Oracle 4031 : impossible d'allouer num-bytes octets de mémoire partagée. Cependant cette erreur Oracle indique que la zone globale partagée (SGA) n'a pas assez de mémoire, est très fragmentée, ou les deux. Si cette erreur n'affecte qu'une seule session, il est envisageable de l'ignorer. Toutefois, si cette erreur affecte plusieurs sessions, envisagez de spécifier que le détecteur de pannes de serveur redémarre la base de données.

L'exemple suivant montre une entrée dans un fichier d'actions personnalisées pour modifier la réponse à une erreur SGBD en redémarrage.

Exemple 4 Modification de la réponse à une erreur SGBD en redémarrage

{
ERROR_TYPE=DBMS_ERROR;
ERROR=4031; 
ACTION=restart;
CONNECTION_STATE=*; 
NEW_STATE=*;
MESSAGE="Insufficient memory in shared pool.";
}

Cet exemple montre une entrée dans un fichier d'actions personnalisées qui remplace l'action prédéfinie pour l'erreur SGBD 4031. Cette entrée spécifie le comportement suivant :

Ignorer une erreur dont les effets sont mineurs

Si les effets d'une erreur à laquelle le détecteur de pannes de serveur répond sont mineurs, le fait d'ignorer l'erreur peut s'avérer moins perturbateur que d'y répondre.

Par exemple, l'action prédéfinie pour l'erreur Oracle 4030 : mémoire de traitement manquante lors d'affectation de num-bytes octets est un redémarrage. Cette erreur Oracle indique que le détecteur de pannes de serveur n'a pas réussi à allouer une mémoire du tas privée. Une des causes possibles de cette erreur est que le système d'exploitation dispose d'une mémoire insuffisante. Si cette erreur affecte plusieurs sessions, il peut être approprié de redémarrer la base de données. Cependant, il est possible que l'erreur n'affecte pas d'autres sessions car ces sessions ne nécessitent pas plus de mémoire privée. Dans cette situation, envisagez de spécifier au détecteur de pannes de serveur d'ignorer l'erreur.

L'exemple suivant montre une entrée dans un fichier d'actions personnalisées pour ignorer une erreur SGBD.

Exemple 5 Ignorer une erreur SGBD

{
ERROR_TYPE=DBMS_ERROR;
ERROR=4030;
ACTION=none;
CONNECTION_STATE=*;
NEW_STATE=*;
MESSAGE="";
}

Cet exemple montre une entrée dans un fichier d'actions personnalisées qui remplace l'action prédéfinie pour l'erreur SGBD 4030. Cette entrée spécifie le comportement suivant :

Modification de la réponse aux alertes journalisées

Le logiciel Oracle consigne les alertes dans un fichier qui est identifié par la propriété d'extension alert_log_file. Le détecteur de pannes de serveur analyse ce fichier et effectue des actions en réponse aux alertes pour lesquelles une action est définie.

Les alertes enregistrées pour lesquelles une action a été prédéfinie sont répertoriées dans la Tableau 2. Modifiez la réponse aux alertes journalisées pour modifier l'action prédéfinie ou pour définir de nouvelles alertes auxquelles le détecteur de pannes de serveur répond.

Pour changer la réponse aux alertes consignées, créez une entrée dans le fichier d'actions personnalisées dans lequel les mots-clés sont définis comme suit :

Le détecteur de pannes de serveur traite les entrées dans un fichier d'actions personnalisées dans l'ordre dans lequel les entrées se produisent. Seule la première entrée qui correspond à une alerte consignée est traitée. Les entrées correspondantes suivantes sont ignorées. Si vous utilisez des expressions régulières pour spécifier des actions pour plusieurs alertes consignées, veillez à ce que les entrées plus spécifiques se produisent avant les entrées plus génériques. Les entrées spécifiques qui se produisent après les entrées génériques pourraient être ignorées.

Par exemple, un fichier d'actions personnalisées pourrait définir différentes actions pour les erreurs qui sont identifiées par les expressions régulières ORA-65 et ORA-6. Pour veiller à ce que l'entrée contenant l'expression régulière ORA-65 ne soit pas ignorée, assurez-vous que cette entrée se produise avant l'entrée contenant l'expression régulière ORA-6.

L'exemple suivant montre une entrée dans un fichier d'actions personnalisées pour modifier la réponse à une alerte journalisée.

Exemple 6 Modification de la réponse à une alerte consignée

{
ERROR_TYPE=SCAN_LOG;
ERROR="ORA-00600: internal error";
ACTION=RESTART;
}

Cet exemple montre une entrée dans un fichier d'actions personnalisées qui remplace l'action prédéfinie pour les alertes journalisées concernant des erreurs internes. Cette entrée spécifie le comportement suivant :

Modification du nombre maximum de tests de délai d'attente dépassé consécutifs

Par défaut, le détecteur de pannes de serveur redémarre la base de données après le deuxième test de délai dépassé consécutif. Si la base de données est légèrement chargée, deux tests de délai dépassé consécutifs devraient suffire pour indiquer que la base de données est bloquée. Cependant, pendant les périodes de charge élevée, un test de détecteur de pannes de serveur peut dépasser le délai d'attente même si la base de données fonctionne correctement. Pour empêcher le détecteur de pannes de serveur de redémarrer la base de données quand ce n'est pas nécessaire, augmentez le nombre maximum de tests de délai dépassé consécutifs.


Attention

Attention - L'augmentation du nombre maximum de tests de délai dépassé consécutifs augmente le temps nécessaire pour détecter un blocage de la base de données.


Pour changer le nombre maximum de tests de délai dépassé consécutifs autorisés, créez une entrée dans un fichier d'actions personnalisées pour chaque test de délai dépassé consécutif autorisé sauf le premier test de délai dépassé.


Remarque - Il n'est pas nécessaire de créer une entrée pour le premier test de délai dépassé. L'action qu'effectue le détecteur de pannes de serveur en réponse au premier test de délai dépassé est prédéfinie.


Pour le dernier test de délai dépassé, créez une entrée dans laquelle les mots-clés sont réglés comme suit :

Pour chaque test de délai dépassé consécutif restant sauf le premier, créez une entrée dans laquelle les mots-clés sont réglés comme suit :


Astuce - Pour faciliter le débogage, spécifiez un message indiquant le numéro de séquence du test de délai dépassé.


L'exemple suivant montre les entrées d'un fichier d'actions personnalisées pour augmenter le nombre maximum de tests de délai dépassé jusqu'à 5.

Exemple 7 Modification du nombre maximum de tests de délai d'attente dépassé consécutifs

{
ERROR_TYPE=TIMEOUT;
ERROR=2;
ACTION=NONE;
CONNECTION_STATE=*;
NEW_STATE=*;
MESSAGE="Timeout #2 has occurred.";
}

{
ERROR_TYPE=TIMEOUT;
ERROR=3;
ACTION=NONE;
CONNECTION_STATE=*;
NEW_STATE=*;
MESSAGE="Timeout #3 has occurred.";
}

{
ERROR_TYPE=TIMEOUT;
ERROR=4;
ACTION=NONE;
CONNECTION_STATE=*;
NEW_STATE=*;
MESSAGE="Timeout #4 has occurred.";
}

{
ERROR_TYPE=TIMEOUT;
ERROR=5;
ACTION=RESTART;
CONNECTION_STATE=*;
NEW_STATE=*;
MESSAGE="Timeout #5 has occurred. Restarting.";
}

Cet exemple montre les entrées d'un fichier d'actions personnalisées pour augmenter le nombre maximum de tests de délai dépassé jusqu'à 5. Ces entrées spécifient le comportement suivant :

Propagation d'un fichier d'actions personnalisées à tous les nœuds d'un cluster

Un détecteur de pannes de serveur doit avoir un comportement cohérent sur tous les nœuds ou zones du cluster. C'est pour cela que le fichier d'actions personnalisées que le détecteur de pannes de serveur utilise doit être identique sur tous les nœuds ou zones du cluster. Après la création ou la modification d'un fichier d'actions personnalisées, assurez-vous que ce fichier est identique sur tous les nœuds ou zones du cluster en propageant ce fichier sur tous les nœuds ou zones du cluster. Pour propager un fichier sur tous les nœuds ou zones du cluster, utilisez la méthode la mieux adaptée à votre configuration de cluster :

Spécification du fichier d'actions personnalisées qu'un détecteur de pannes de serveur doit utiliser

Pour appliquer des actions personnalisées à un détecteur de pannes de serveur, vous devez spécifier le fichier d'actions personnalisées que le détecteur de pannes doit utiliser. Des actions personnalisées sont appliquées à un détecteur de pannes de serveur quand ce dernier lit un fichier d'actions personnalisées. Un détecteur de pannes de serveur lit un fichier d'actions personnalisées quand vous lui en spécifiez un.

La spécification d'un fichier d'actions personnalisées valide également ce dernier. Si le fichier contient des erreurs de syntaxe, un message d'erreur s'affiche. Après la modification d'un fichier d'actions personnalisées, il faut donc spécifier le fichier à nouveau pour le valider.


Attention

Attention - Si des erreurs de syntaxe sont détectées dans un fichier d'actions personnalisées modifié, corrigez ces erreurs avant le redémarrage du détecteur de pannes. Si des erreurs de syntaxe ne sont pas corrigées lors du redémarrage du détecteur de pannes, ce dernier lit le fichier erroné, ignorant les entrées qui se produisent après la première erreur de syntaxe.


Spécification du fichier d'actions personnalisées qu'un détecteur de pannes de serveur doit utiliser

  1. Sur un noeud du cluster, connectez-vous en tant que superutilisateur ou adoptez un rôle octroyant une autorisation reposant sur un contrôle d'accès à base de rôles de type solaris.cluster.modify.
  2. Définissez la propriété d'extension Custom_action_file de la ressource SUNW.oracle_server.

    Définissez cette propriété sur le chemin absolu du fichier d'actions personnalisées.

    # clresource set -p custom_action_file=filepath server-resource
    -p custom_action_file=filepath

    Spécifie le chemin absolu du fichier d'actions personnalisées.

    server-resource

    Spécifie la ressource SUNW.oracle_server.