Ignorer les liens de navigation
Quitter l'aperu
| Guide du service de données Oracle Solaris Cluster pour Oracle Real Application Clusters Oracle Solaris Cluster 3.3 3/13 (Français)

Périmètre de la recherche:

- Ce document
- Toute la bibliothque

## Personnalisation du détecteur de pannes Serveur Oracle 9i RAC

La personnalisation du détecteur de pannes serveur Oracle 9i RAC permet de modifier le comportement du détecteur de pannes de serveur comme suit :

- Remplacement d'une action prédéfinie pour une erreur

- Spécification d'une action pour une erreur pour laquelle aucune action n'est prédéfinie

| Attention - Avant de personnaliser le détecteur de pannes du serveur Oracle 9i RAC, 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 la détection. Si les 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 du serveur Oracle 9i RAC, revenez aux actions prédéfinies. Revenir aux actions prédéfinies permet de déterminer si le problème provient de votre personnalisation.

La personnalisation du détecteur de pannes du serveur Oracle 9i RAC 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 noeuds 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 Oracle 9i RAC détecte les types d'erreur suivants :

- Erreurs de SGBD qui se produisent au cours de la sonde d'une base de données par le détecteur de pannes du serveur

- Alertes qu'Oracle consigne dans un fichier journal d'alertes

- Délais d'attente provoqués par un échec de réception d'une réponse dans le laps de temps défini par la propriété d'extension `Probe_timeout`

Pour définir un comportement personnalisé pour ces types d'erreurs, 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

- Modification de la réponse à une erreur de SGBD

- Modification de la réponse aux alertes journalisées

- Modification du nombre maximal de sondes de délai dépassé consécutives

#### 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 de serveur Oracle 9i RAC. Chaque entrée définit le comportement personnalisé pour une erreur de 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 d'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 de fichier d'actions personnalisées se présente sous la forme d'une suite de paires mot-clé/valeur délimitée 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=RESTART|STOP|NONE;]
    [CONNECTION_STATE=co|di|on|*;]
    [NEW_STATE=co|di|on|*;]
    [MESSAGE="message-string"]
    }

Des espaces peuvent être utilisés entre les paires de mot-clé/valeur distinctes 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 du serveur a détectée. Les valeurs suivantes sont autorisées pour ce mot-clé :

  `DBMS_ERROR`

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

  `SCAN_LOG`

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

  `TIMEOUT_ERROR`

    Spécifie que l'erreur est un 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 de SGBD.

`ERROR`

  Identifie l'erreur. 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 | Numéro d'une erreur de SGBD générée par Oracle
  `SCAN_LOG` | Expression régulière citée | Chaîne dans un message d'erreur qu'Oracle a consigné dans le fichier journal d'alertes d'Oracle
  `TIMEOUT_ERROR` | Nombre entier | Nombre de sondes de délai dépassé consécutives depuis le dernier démarrage ou redémarrage du détecteur de pannes du serveur

  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 du serveur doit effectuer en réponse à l'erreur. Les valeurs suivantes sont autorisées pour ce mot-clé :

  `NONE`

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

  `STOP`

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

  `RESTART`

    Spécifie que le détecteur de pannes de serveur arrête et redémarre la ressource du serveur Oracle 9i RAC.

  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 l'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 du 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 du serveur est en ligne. Le détecteur de pannes du serveur est en ligne lorsqu'il est connecté à la base de données.

  `di`

    Spécifie que l'entrée s'applique uniquement si le détecteur de pannes du 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 du 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 du 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 du serveur doit se déconnecter de la base de données. Le détecteur de pannes du serveur se reconnecte à sa prochaine sonde de la base de données.

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

`MESSAGE`

  Spécifie qu'un message est ajouté au fichier journal de la ressource lorsque l'erreur est détectée. Le message doit être placé 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 n'est ajouté au fichier journal de la ressource lorsque l'erreur est détectée.

#### Modification de la réponse à une erreur de SGBD

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

- Réponse à une erreur dont les effets sont majeurs

- Non prise en compte d'une erreur dont les effets sont mineurs

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

- `ERROR_TYPE` est défini sur `DBMS_ERROR`.

- `ERROR` est défini sur le numéro de l'erreur de SGBD.

- `ACTION` est défini sur l'action nécessaire.

##### Réponse à une erreur dont les effets sont majeurs

Si une erreur que le détecteur de pannes du serveur ignore affecte plus d'une session, une action du détecteur de pannes du serveur peut être nécessaire pour empêcher une perte de service.

Par exemple, aucune action n'est prédéfinie pour l'erreur Oracle 4031 : `unable to allocate` num-bytes `bytes of shared memory`. 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 possible de l'ignorer. Toutefois, si cette erreur affecte plusieurs sessions, envisagez de spécifier au détecteur de pannes du serveur de redémarrer la base de données.

L'exemple suivant présente une entrée dans un fichier d'actions personnalisées visant à changer la réponse à une erreur de SGBD en redémarrage.

Exemple 5-4 Changement de la réponse à une erreur de 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 de SGBD 4031. Cette entrée spécifie le comportement suivant :

- En réponse à l'erreur de SGBD 4031, l'action que le détecteur de pannes du serveur effectue est un redémarrage.

- Cette entrée s'applique quel que soit l'état de la connexion entre la base de données et le détecteur de pannes du serveur lorsque l'erreur est détectée.

- L'état de la connexion entre la base de données et le détecteur de pannes du serveur ne doit pas être modifié après la détection de l'erreur.

- Le message suivant est ajouté au fichier journal de la ressource lorsque cette erreur est détectée :

      Insufficient memory in shared pool.

##### Non prise en compte d'une erreur dont les effets sont mineurs

Si les effets d'une erreur à laquelle le détecteur de pannes du 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 : `out of process memory when trying to allocate` num-bytes `bytes` est le redémarrage. Cette erreur Oracle indique que le détecteur de pannes du serveur n'a pas pu allouer de mémoire de segment privée. Une cause possible de cette erreur est que la mémoire disponible pour le système d'exploitation est insuffisante. Si cette erreur affecte plusieurs sessions, un redémarrage de la base de données peut être approprié. Cependant, il est possible que cette erreur n'affecte pas les autres sessions, car ces sessions ne nécessitent pas de mémoire privée supplémentaire. Dans cette situation, envisagez de spécifier au détecteur de pannes du serveur d'ignorer l'erreur.

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

Exemple 5-5 Non prise en compte d'une erreur de 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 de SGBD 4030. Cette entrée spécifie le comportement suivant :

- Le détecteur de pannes du serveur ignore l'erreur de SGBD 4030.

- Cette entrée s'applique quel que soit l'état de la connexion entre la base de données et le détecteur de pannes du serveur lorsque l'erreur est détectée.

- L'état de la connexion entre la base de données et le détecteur de pannes du serveur ne doit pas être modifié après la détection de l'erreur.

- Aucun message n'est ajouté au fichier journal de la ressource lorsque cette erreur est détectée.

#### Modification de la réponse aux alertes journalisées

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

Les alertes journalisées pour lesquelles une action a été prédéfinie sont répertoriées dans le Tableau B-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 du serveur répond.

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

- `ERROR_TYPE` est défini sur `SCAN_LOG`.

- `ERROR` est défini sur une expression régulière citée qui identifie une chaîne dans un message d'erreur qu'Oracle a consigné dans le fichier journal d'alertes d'Oracle.

- `ACTION` est défini sur l'action nécessaire.

Le détecteur de pannes du serveur traite les entrées d'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 journalisée est traitée. Les entrées correspondantes suivantes sont ignorées. Si vous utilisez des expressions régulières afin de spécifier des actions pour plusieurs alertes journalisé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 peuvent être ignorées.

Par exemple, un fichier d'actions personnalisées peut 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 5-6 Modification de la réponse à une alerte journalisé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 :

- En réponse aux alertes journalisées contenant le texte `ORA-00600: internal error`, le détecteur de pannes du serveur effectue une action de redémarrage.

- Cette entrée s'applique quel que soit l'état de la connexion entre la base de données et le détecteur de pannes du serveur lorsque l'erreur est détectée.

- L'état de la connexion entre la base de données et le détecteur de pannes du serveur ne doit pas être modifié après la détection de l'erreur.

- Aucun message n'est ajouté au fichier journal de la ressource lorsque cette erreur est détectée.

#### Modification du nombre maximal de sondes de délai dépassé consécutives

Par défaut, le détecteur de pannes du serveur redémarre la base de données après la deuxième sonde de délai dépassé consécutive. Si la base de données est légèrement chargée, deux sondes de délai dépassé consécutives doivent être suffisantes pour indiquer que la base de données est bloquée. Cependant, pendant les périodes de charge élevée, une sonde 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 éviter que le détecteur de pannes du serveur ne redémarre la base de données lorsque que ce n'est pas nécessaire, augmentez le nombre maximal de sondes de délai dépassé consécutives.

| Attention - L'augmentation du nombre maximal de sondes de délai dépassé consécutives augmente le temps nécessaire pour détecter un blocage de la base de données.

Pour modifier le nombre maximal de sondes de délai dépassé consécutives autorisées, créez une entrée dans un fichier d'actions personnalisées pour chaque sonde de délai dépassé consécutive autorisée sauf pour la première sonde de délai dépassé.

Remarque - Il n'est pas nécessaire de créer une entrée pour la première sonde de délai dépassé. L'action effectuée par le détecteur de pannes du serveur en réponse à la première sonde de délai dépassé est prédéfinie.

Pour la dernière sonde de délai dépassé, créez une entrée dans laquelle les mots-clés sont définis comme suit :

- `ERROR_TYPE` est défini sur `TIMEOUT_ERROR`.

- `ERROR` est défini sur le nombre maximal de sondes de délai dépassé consécutives autorisées.

- `ACTION` est défini sur `RESTART`.

Pour chaque sonde de délai dépassé consécutive restante sauf la première, créez une entrée dans laquelle les mots-clés sont définis comme suit :

- `ERROR_TYPE` est défini sur `TIMEOUT_ERROR`.

- `ERROR` est défini sur le numéro de séquence de la sonde de délai dépassé. Par exemple, pour la deuxième sonde de délai dépassé consécutive, définissez ce mot-clé sur 2. Pour la troisième sonde de délai dépassé consécutive, définissez ce mot-clé sur 3.

- `ACTION` est défini sur `NONE`.

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

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

Exemple 5-7 Modification du nombre maximal de sondes de délai dépassé consécutives

    {
    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 maximal de sondes de délai dépassé jusqu'à cinq. Ces entrées spécifient le comportement suivant :

- Le détecteur de pannes du serveur ignore les sondes de la deuxième sonde de délai dépassé consécutive jusqu'à la quatrième.

- En réponse à la cinquième sonde de délai dépassé consécutive, l'action que le détecteur de pannes du serveur effectue est un redémarrage.

- Cette entrée s'applique quel que soit l'état de la connexion entre la base de données et le détecteur de pannes du serveur lorsque le délai est dépassé.

- L'état de la connexion entre la base de données et le détecteur de pannes du serveur ne doit pas être modifié après le dépassement du délai.

- Lorsque les sondes de la deuxième à la quatrième sonde de délai dépassé consécutive se produisent, un message de la forme suivante est ajouté au fichier journal de la ressource :

      Timeout #number has occurred.

- Quand la cinquième sonde de délai dépassé consécutive se produit, le message suivant est ajouté au fichier journal de la ressource :

      Timeout #5 has occurred. Restarting.

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

Un détecteur de pannes de serveur doit avoir un comportement cohérent sur tous les noeuds du cluster. Par conséquent, le fichier d'actions personnalisées que le détecteur de pannes de serveur utilise doit être identique sur tous les noeuds 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 noeuds du cluster en propageant ce fichier sur tous les noeuds du cluster. Pour propager un fichier sur tous les noeuds du cluster, utilisez la méthode la mieux adaptée à votre configuration de cluster :

- Recherche du fichier sur un système de fichiers que tous les noeuds partagent

- Recherche du fichier sur un système de fichiers local à haut niveau de disponibilité

- La copie du fichier sur le système de fichiers local de chaque noeud ou zone du cluster en utilisant des commandes du système d'exploitation telles que la commande `rcp`(1) ou la commande `rdist`(1)

### 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 celui-ci 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 le fichier. 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 à nouveau le spécifier pour le valider.

| 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, celui-ci 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. Connectez-vous en tant que superutilisateur sur un noeud du cluster ou prenez un rôle octroyant une autorisation RBAC de type `solaris.cluster.modify`.
2. Définissez la propriété d'extension `Custom_action_file` de la ressource `SUNW.scalable_rac_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.scalable_rac_server`.

Copyright © 2000, 2013, Oracle et/ou ses affiliés. Tous droits réservés. Notice légale |