Personalización del supervisor de fallos Servidor de HA para Oracle

La personalización del supervisor de fallos Servidor de HA para Oracle le permite modificar el comportamiento del supervisor de fallos de servidor de la siguiente manera:

• Anulando la acción preestablecida para un error.

• Especificando una acción para un error para el que no hay ninguna acción preestablecida.

---

Precaución - Antes de personalizar el supervisor de fallos Servidor de HA para Oracle, tenga en cuenta los efectos que podrían tener sus personalizaciones, en especial, si cambia una acción del reinicio o si conmuta una acción para ignorar o detener la supervisión. Si los errores permanecen sin corregirse durante periodos prolongados, los errores podrían ocasionar problemas con la base de datos. Si detecta problemas con la base de datos después de personalizar el supervisor de fallos Servidor de HA para Oracle, vuelva a utilizar las acciones preestablecidas. Al volver a utilizar las acciones preestablecidas puede determinar si el problema lo ocasionó la configuración personalizada.

---

Las siguientes secciones describen las actividades que se realizan para personalizar el supervisor de fallos Servidor de HA para Oracle:

• Definición del comportamiento personalizado de errores

• Propagación de un archivo de acción personalizada a todos los nodos de un cluster

• Especificación del archivo de acción personalizada que debe utilizar un supervisor de fallos de servidor

Definición del comportamiento personalizado de errores

El supervisor de fallos Servidor de HA para Oracle detecta los siguientes tipos de errores:

• Errores de DBMS que ocurren durante un sondeo de la base de datos realizado por el supervisor de fallos del servidor.

• Alertas que Oracle registra en el archivo de registro de alertas.

• Tiempos de espera agotados debido a que no se recibe una respuesta durante el tiempo establecido por la propiedad de extensión Probe_timeout.

Para definir el comportamiento personalizado para estos tipos de errores, cree un archivo de acción personalizado. Esta sección contiene la siguiente información sobre los archivos de acción personalizados:

• Formato de archivo de acción personalizado

• Cambio de la respuesta a un error de DBMS

• Cambio de la respuesta a las alertas registradas

• Cambio del número máximo de sondeos consecutivos con tiempo de espera finalizado

Formato de archivo de acción personalizado

Un archivo de acción personalizado es un archivo de texto sin formato. El archivo contiene una o más entradas que definen el comportamiento personalizado del supervisor de fallos de Servidor de HA para Oracle. Cada entrada define el comportamiento personalizado para un solo error de DBMS, un solo error de tiempo de espera finalizado o varias alertas registradas. Se permite un máximo de 1.024 entradas en un archivo de acción personalizado.

Una entrada en un archivo de acción personalizado se compone de una secuencia de pares de palabra clave y valor separados por punto y coma. Cada entrada está encerrada entre llaves.

El formato de una entrada en un archivo de acción personalizado es el siguiente:

{
[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"]
}

Puede utilizarse un espacio en blanco entre los pares de palabra clave y valor separados y entre las entradas para dar formato al archivo.

El significado y los valores permitidos de las palabras clave en un archivo de acción personalizado son los siguientes:

ERROR_TYPE

Indica el tipo de error que ha detectado el supervisor de fallos del servidor. Se permiten los siguientes valores para esta palabra clave:

DBMS_ERROR

Especifica que el error es un error de DBMS.

SCAN_LOG

Especifica que el error es una alerta que está registrada en el archivo de registro de alertas.

TIMEOUT_ERROR

Especifica que el error es un tiempo de espera finalizado.

La palabra clave ERROR_TYPE es opcional. Si la omite, se da por sentado que el error es un error de DBMS.

ERROR

Identifica el error. El significado y el tipo de datos de error-spec están determinados por el valor de la palabra clave ERROR_TYPE como se muestra en la siguiente tabla.

ERROR_TYPE Tipo de datos Significado DBMS_ERROR Entero Número de error de un error de DBMS que genera Oracle. SCAN_LOG Expresión regular entre comillas Cadena en un mensaje de error que ha registrado Oracle en el archivo de registro de alertas de Oracle. TIMEOUT_ERROR Entero Número de sondeos consecutivos de tiempo de espera finalizado desde que el supervisor de fallos del servidor se inició o reinició por última vez.

Debe especificar la palabra clave ERROR. Si omite esta palabra clave, la entrada en el archivo de acción personalizado se ignora.

ACTION

Especifica la acción que el supervisor de fallos del servidor va a realizar como respuesta al error. Se permiten los siguientes valores para esta palabra clave:

NONE

Especifica que el supervisor de fallos del servidor ignora el error.

STOP

Especifica que el supervisor de fallos del servidor se detiene.

RESTART

Especifica que el supervisor de fallos del servidor detiene y reinicia la entidad especificada por el valor de la propiedad de extensión Restart_type del recurso SUNW.oracle_server.

SWITCH

Especifica que el supervisor de fallos del servidor conmuta el grupo de recursos del servidor de base de datos a otro nodo o zona.

La palabra clave ACTION es opcional. Si omite esta palabra clave, el supervisor de fallos de servidor ignora el error.

CONNECTION_STATE

Especifica el estado necesario de la conexión entre la base de datos y el supervisor de fallos de servidor cuando se detecta el error. La entrada sólo se aplica si la conexión se encuentra en el estado requerido cuando se detecta el error. Se permiten los siguientes valores para esta palabra clave:

*

Especifica que la entrada siempre se aplica, sea cual sea el estado de la conexión.

co

Especifica que la entrada se aplica únicamente si el supervisor de fallos del servidor intenta conectarse a la base de datos.

on

Especifica que la entrada se aplica únicamente si el supervisor de fallos del servidor está en línea. El supervisor de fallos del servidor está en línea si está conectado a la base de datos.

di

Especifica que la entrada se aplica únicamente si el supervisor de fallos del servidor se desconecta de la base de datos.

La palabra clave CONNECTION_STATE es opcional. Si omite esta palabra clave, la entrada siempre se aplica, sea cual sea el estado de la conexión.

NEW_STATE

Especifica el estado de la conexión entre la base de datos y el supervisor de fallos del servidor que el supervisor de fallos del servidor debe tener después de que se detecta el error. Se permiten los siguientes valores para esta palabra clave:

*

Especifica que el estado de la conexión debe permanecer igual.

co

Especifica que el supervisor de fallos del servidor debe desconectarse de la base de datos y volver a conectarse de inmediato a la base de datos.

di

Especifica que el supervisor de fallos del servidor debe desconectarse de la base de datos. El supervisor de fallos del servidor se vuelve a conectar la próxima vez que sondea la base de datos.

La palabra clave NEW_STATE es opcional. Si omite esta palabra clave, el estado de la conexión de la base de datos permanece igual después de que se detecta el error.

MESSAGE

Especifica un mensaje adicional que se imprime en el archivo de registro del recurso cuando se detecta este error. El mensaje debe estar encerrado entre comillas dobles. Este mensaje es adicional al mensaje estándar definido para el error.

La palabra clave MESSAGE es opcional. Si omite esta palabra clave, no se imprime ningún mensaje adicional en el archivo de registro del recurso cuando se detecta este error.

Cambio de la respuesta a un error de DBMS

La acción que el supervisor de fallos del servidor lleva a cabo como respuesta a cada error de DBMS está preestablecida en la Tabla B-1. Para determinar si necesita cambiar la respuesta a un error de DBMS, considere el efecto de los errores de DBMS en la base de datos para determinar si las acciones preestablecidas son apropiadas. Para ver ejemplos, consulte las subsecciones siguientes:

• Respuesta a un error con efectos importantes

• Omisión de un error con efectos secundarios

Para cambiar la respuesta a un error de DBMS, cree una entrada en un archivo de acción personalizado en la que las palabras clave estén establecidas de la siguiente manera:

• ERROR_TYPE debe estar establecida en DBMS_ERROR.

• ERROR debe estar establecida en el número de error del error de DBMS.

• ACTION debe estar establecida en la acción que se necesita.

Respuesta a un error con efectos importantes

Si un error que el supervisor de fallos del servidor ignora afecta más de una sesión, es posible que se requiera una acción por parte del supervisor de fallos del servidor para evitar una pérdida de servicio.

Por ejemplo, no hay ninguna acción preestablecida para el error 4031 de Oracle: unable to allocate num-bytes bytes of shared memory. No obstante, este error de Oracle indica que el área global compartida (SGA) no tiene suficiente memoria, está fragmentada incorrectamente, o ambas cosas. Si este error sólo afecta una sesión, podría resultar apropiado ignorarlo. Sin embargo, si este error afecta más de una sesión, considere especificar que el supervisor de fallos del servidor reinicie la base de datos.

El siguiente ejemplo muestra una entrada en un archivo de acción personalizado para cambiar la respuesta a un error de DBMS a un reinicio.

Ejemplo 1-4 Cambio de la respuesta a un error de DBMS a un reinicio

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

Este ejemplo muestra una entrada en un archivo de acción personalizado que anula la acción preestablecida para el error 4031 de DBMS. Esta entrada especifica el siguiente comportamiento:

• En respuesta al error 4031 de DBMS, la acción que realiza el supervisor de fallos del servidor es un reinicio.

• Esta entrada se aplica sea cual sea el estado de la conexión entre la base de datos y el supervisor de fallos del servidor cuando se detecta el error.

• El estado de la conexión entre la base de datos y el supervisor de fallos del servidor debe permanecer igual después de que se detecta el error.

• El siguiente mensaje se imprime en el archivo de registro del recurso cuando se detecta este error:

  Insufficient memory in shared pool.

Omisión de un error con efectos secundarios

Si los efectos de un error al que responde el supervisor de fallos del servidor no son importantes, ignorar el error puede ser menos perjudicial que responder al error.

Por ejemplo, la acción preestablecida para el error 4030 de Oracle: out of process memory when trying to allocate num-bytes bytes es reiniciar. Este error de Oracle indica que el supervisor de fallos del servidor no ha podido asignar memoria en montón privada. Una posible causa de este error es que no hay suficiente memoria disponible en el sistema operativo. Si el error afecta más de una sesión, podría resultar adecuado reiniciar la base de datos. Sin embargo, es posible que este error no afecte otras sesiones porque no requieren memoria privada adicional. En este caso, considere la posibilidad de especificar que el supervisor de fallos del servidor ignore el error.

El siguiente ejemplo muestra una entrada en un archivo de acción personalizado para ignorar un error de DBMS.

Ejemplo 1-5 Omisión de un error de DBMS

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

Este ejemplo muestra una entrada en un archivo de acción personalizado que anula la acción preestablecida para el error 4030 de DBMS. Esta entrada especifica el siguiente comportamiento:

• El supervisor de fallos del servidor ignora el error 4030 de DBMS.

• Esta entrada se aplica sea cual sea el estado de la conexión entre la base de datos y el supervisor de fallos del servidor cuando se detecta el error.

• El estado de la conexión entre la base de datos y el supervisor de fallos del servidor debe permanecer igual después de que se detecta el error.

• No se imprime ningún mensaje adicional en el archivo de registro del recurso cuando se detecta este error.

Cambio de la respuesta a las alertas registradas

El software de Oracle registra las alertas en un archivo identificado por la propiedad de extensión alert_log_file. El supervisor de fallos del servidor analiza este archivo y efectúa las acciones en respuesta a las alertas para las que se ha definido una acción.

Las alertas registradas para las que hay una acción preestablecida figuran en la Tabla B-2. Cambie la respuesta a las alertas registradas para modificar la acción preestablecida o para definir nuevas alertas a las que responda el supervisor de fallos del servidor.

Para cambiar la respuesta a las alertas registradas, cree una entrada en un archivo de acción personalizado en la que las palabras clave estén establecidas de la siguiente manera:

• ERROR_TYPE debe estar establecida en SCAN_LOG.

• ERROR debe estar establecida en una expresión regular entre comillas que identifique una cadena en un mensaje de error que ha registrado Oracle en el archivo de registro de alertas de Oracle.

• ACTION debe estar establecida en la acción que se necesita.

El supervisor de fallos del servidor procesa las entradas de un archivo de acción personalizado en el orden en que ocurren. Sólo se procesa la primera entrada que coincide con una alerta registrada. El resto de las entradas que coinciden se ignoran. Si está utilizando expresiones regulares para especificar acciones para varias alertas registradas, asegúrese de que las entradas más específicas ocurran antes de las entradas más generales. Las entradas específicas que ocurren después de las entradas generales podrían ignorarse.

Por ejemplo, un archivo de acción personalizado puede definir diferentes acciones para los errores identificados por las expresiones regulares ORA-65 y ORA-6. Para garantizar que no se ignore la entrada que contiene la expresión regular ORA-65, asegúrese de que esta entrada tenga lugar antes de la entrada que contiene la expresión regular ORA-6.

El siguiente ejemplo muestra una entrada en un archivo de acción personalizado para cambiar la respuesta a una alerta registrada.

Ejemplo 1-6 Cambio de la respuesta a una alerta registrada

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

En este ejemplo, se muestra una entrada en un archivo de acción personalizado que anula la acción preestablecida para las alertas registradas relativas a los errores internos. Esta entrada especifica el siguiente comportamiento:

• Como respuesta a las alertas registradas que contienen el texto ORA-00600: internal error, la acción que realiza el supervisor de fallos del servidor es un reinicio.

• Esta entrada se aplica sea cual sea el estado de la conexión entre la base de datos y el supervisor de fallos del servidor cuando se detecta el error.

• El estado de la conexión entre la base de datos y el supervisor de fallos del servidor debe permanecer igual después de que se detecta el error.

• No se imprime ningún mensaje adicional en el archivo de registro del recurso cuando se detecta este error.

Cambio del número máximo de sondeos consecutivos con tiempo de espera finalizado

De manera predeterminada, el supervisor de fallos del servidor reinicia la base de datos tras el segundo sondeo consecutivo con tiempo de espera finalizado. Si la base de datos está levemente cargada, dos sondeos consecutivos con tiempo de espera finalizado deberían ser suficientes para indicar que la base de datos no responde. Sin embargo, durante los períodos de carga elevada, un sondeo del supervisor de fallos del servidor podría finalizar el tiempo de espera aunque la base de datos funcione correctamente. Para impedir que el supervisor de fallos del servidor reinicie la base de datos de forma innecesaria, aumente el número máximo de sondeos consecutivos con tiempo de espera finalizado.

---

Precaución - El aumento del número máximo de sondeos consecutivos con tiempo de espera finalizado aumenta la cantidad de tiempo necesaria para detectar que la base de datos no responde.

---

Para cambiar el número máximo de sondeos consecutivos con tiempo de espera finalizado permitidos, cree una entrada en un archivo de acción personalizado para cada sondeo consecutivo con tiempo de espera finalizado permitido, excepto para el primer sondeo con tiempo de espera finalizado.

Para el último sondeo con tiempo de espera finalizado permitido, cree una entrada en la que las palabras clave estén establecidas de la siguiente manera:

• ERROR_TYPE debe estar establecida en TIMEOUT_ERROR.

• ERROR debe estar establecida en el número máximo de sondeos consecutivos con tiempo de espera finalizado que estén permitidos.

• ACTION debe estar establecida en RESTART.

Para cada uno de los sondeos restantes con tiempo de espera finalizado, excepto el primer sondeo con tiempo de espera finalizado, cree una entrada en la que las palabras clave estén establecidas de la siguiente manera:

• ERROR_TYPE debe estar establecida en TIMEOUT_ERROR.

• ERROR debe estar establecida en el número de secuencia del sondeo con tiempo de espera finalizado. Por ejemplo, para el segundo sondeo consecutivo con tiempo de espera finalizado, establezca esta palabra clave en 2. Para el tercer sondeo consecutivo con tiempo de espera finalizado, establezca esta palabra clave en 3.

• ACTION debe estar establecida en NONE.

En el siguiente ejemplo, se muestran las entradas de un archivo de acción personalizado para aumentar el número máximo de sondeos consecutivos con tiempo de espera finalizado a cinco.

Ejemplo 1-7 Cambio del número máximo de sondeos consecutivos con tiempo de espera finalizado

{
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.";
}

En este ejemplo, se muestran las entradas de un archivo de acción personalizado para aumentar el número máximo de sondeos consecutivos con tiempo de espera finalizado a cinco. Estas entradas especifican el siguiente comportamiento:

• El supervisor de fallos del servidor ignora del segundo sondeo consecutivo con tiempo de espera finalizado al cuarto sondeo consecutivo con tiempo de espera finalizado.

• Como respuesta al quinto sondeo consecutivo con tiempo de espera finalizado, la acción que realiza el supervisor de fallos del servidor es un reinicio.

• Las entradas se aplican sea cual sea el estado de la conexión entre la base de datos y el supervisor de fallos del servidor cuando finaliza el tiempo de espera.

• El estado de la conexión entre la base de datos y el supervisor de fallos del servidor debe permanecer igual después de haber finalizado el tiempo de espera.

• Cuando ocurren del segundo sondeo consecutivo con tiempo de espera finalizado al cuarto sondeo consecutivo con tiempo de espera finalizado, se imprime un mensaje con el siguiente formato en el archivo de registro del recurso:

  Timeout #number has occurred.

• Cuando se produce el quinto sondeo consecutivo con tiempo de espera agotado, se imprime el siguiente mensaje en el archivo de registro del recurso:

  Timeout #5 has occurred. Restarting.

Propagación de un archivo de acción personalizada a todos los nodos de un cluster

Un supervisor de fallos del servidor debe comportarse de forma coherente en todos los nodos o zonas del cluster. Por lo tanto, el archivo de acción personalizado que utiliza el supervisor de fallos del servidor debe ser idéntico en todos los nodos o zonas del cluster. Después de crear o modificar un archivo de acción personalizado, compruebe que el archivo sea idéntico en todos los nodos o zonas del cluster propagando el archivo a todos los nodos o zonas del cluster. Para propagar el archivo a todos los nodos o zonas del cluster, utilice el método que resulte más adecuado para la configuración del cluster:

• Localizar el archivo en un sistema de archivos que comparten todos los nodos o zonas.

• Localizar el archivo en un sistema de archivos local de alta disponibilidad

• Copiar el archivo al sistema de archivos local de cada nodo o zona del cluster con los comandos del sistema operativo, como el comando rcp(1) o el comando rdist(1)

Especificación del archivo de acción personalizada que debe utilizar un supervisor de fallos de servidor

Para aplicar acciones personalizadas a un supervisor de fallos de servidor, debe especificar el archivo de acción personalizada que debe utilizar el supervisor de fallos. Las acciones personalizadas se aplican a un supervisor de fallos de servidor cuando éste lee un archivo de acción personalizada. Un supervisor de fallos de servidor lee un archivo de acción personalizada cuando se especifica el archivo.

La especificación de un archivo de acción personalizado también valida el archivo. Si el archivo contiene errores de sintaxis, aparece un mensaje de error. Por lo tanto, después de modificar un archivo de acción personalizado, vuelva a especificar el archivo para validarlo.

---

Precaución - Si se detectan errores de sintaxis en un archivo de acción personalizado modificado, corrija los errores antes de que se reinicie el supervisor de fallos. Si los errores de sintaxis siguen estando cuando el supervisor de fallos se reinicia, el supervisor de fallos lee el archivo erróneo e ignora las entradas que aparecen tras el primer error de sintaxis.

---

Cómo especificar el archivo de acción personalizado que debe utilizar un supervisor de fallos del servidor

1. Conviértase en superusuario en un nodo del clúster o asuma un rol que proporcione la autorización de RBAC solaris.cluster.modify.
2. Establezca la propiedad de extensión Custom_action_file del recurso SUNW.oracle_server.

   Establezca esta propiedad en la ruta absoluta del archivo de acción personalizado.

   # clresource set -p custom_action_file=filepath server-resource

   -p custom_action_file= filepath

   Especifica la ruta absoluta del archivo de acción personalizado.

   server-resource

   Especifica el recurso SUNW.oracle_server.