Definición del comportamiento personalizado para los errores

Idioma:

El supervisor de fallos del Servidor de HA para Oracle Database 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 Database registra en el archivo log 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

Un archivo de acción personalizada 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 Database. 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.

Notas - Cada entrada de un archivo de acción personalizado anula la acción preestablecida para un error o especifica una acción para un error para el cual no se ha preestablecido ninguna acción. Cree entradas en un archivo de acción personalizado sólo para las acciones preestablecidas que esté anulando o para los errores para los que no se haya preestablecido ninguna acción. No cree entradas para las acciones que no desee modificar.

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 Dato	Significado
`DBMS_ERROR`	Entero	Número de error de DBMS generado por Oracle Database.
`SCAN_LOG`	Expresión regular entre comillas	Cadena de un mensaje de error registrado por Oracle Database en el archivo log de alertas de Oracle Database.
`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:

NINGUNO: Especifica que el supervisor de fallos del servidor ignora el error.
STOP: Especifica que el supervisor de fallos de 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 cambia el grupo de recursos del servidor de base de datos a otro nodo del cluster.

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 de servidor intenta conectarse a la base de datos.
on: Especifica que la entrada se aplica únicamente si el supervisor de fallos de servidor está en línea. El supervisor de fallos de 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 de servidor debe desconectarse desde 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 log 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 Table 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:

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 Database: unable to allocate num-bytes bytes of shared memory. No obstante, este error de Oracle Database indica que el área global compartida (SGA) no tiene suficiente memoria o está fragmentada incorrectamente, o ambos casos. 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-3 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 de DBMS 4.031, la acción que realiza el supervisor de fallos del servidor es un reinicio.
Esta entrada se aplica independientemente del estado de conexión entre la base de datos y el supervisor de fallos de 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 Database, out of process memory when trying to allocate num-bytes bytes, es el reinicio. Este error de Oracle Database indica que el supervisor de fallos del servidor no pudo 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-4 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 de servidor ignora el error de DBMS 4.030.
Esta entrada se aplica independientemente del estado de conexión entre la base de datos y el supervisor de fallos de 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 Database 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 Table 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 se configura en SCAN_LOG.
ERROR se configura como una expresión regular entre comillas que identifica una cadena en un mensaje de error que Oracle Database registró en el archivo log de alertas de Oracle Database.
ACTION debe estar establecida en la acción que se necesita.

El supervisor de fallos del servidor procesa las entradas en un archivo de acción personalizado en el orden en el 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-5 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:

En respuesta a las alertas registradas que contienen el texto ORA-00600: Einternal error, la acción que realiza el supervisor de fallos de servidor es un reinicio.
Esta entrada se aplica independientemente del estado de conexión entre la base de datos y el supervisor de fallos de 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 - Si se incrementa el número máximo de sondeos consecutivos con timeout agotado, aumenta el tiempo necesario para detectar un bloqueo de la base de datos.

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.

Notas - No es necesario crear una entrada para el primer sondeo con tiempo de espera agotado. La acción que realiza el supervisor de fallos de servidor como respuesta al primer sondeo con tiempo de espera agotado está preestablecida.

Para el último sondeo permitido con tiempo de espera agotado, cree una entrada en que las palabras clave estén definidas como se indica a continuación:

ERROR_TYPE se configura en TIMEOUT_ERROR.
ERROR se configura en el número máximo de sondeos consecutivos con tiempo de espera agotado permitido.
ACTION se configura en RESTART.

Para cada sondeo consecutivo con tiempo de espera agotado restante, excepto para el primer sondeo con tiempo de espera agotado, cree una entrada en la que las palabras clave estén definidas de la siguiente manera:

ERROR_TYPE se configura en TIMEOUT_ERROR.
ERROR se configura con el número de secuencia del sondeo con tiempo de espera agotado. Por ejemplo, para el segundo sondeo consecutivo con tiempo de espera agotado, configure esta palabra clave en 2. Para el tercer sondeo consecutivo con tiempo de espera agotado, configure la palabra clave en 3.
ACTION se configura en NONE.

Consejo - Para facilitar la depuración, especifique un mensaje que indique el número de secuencia del sondeo con tiempo de espera agotado.

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

Ejemplo 1-6 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 personalizada para aumentar el número máximo de sondeos consecutivos con tiempo de espera agotado a cinco. Estas entradas especifican el siguiente comportamiento:

El supervisor de fallos de servidor ignora el segundo sondeo consecutivo con tiempo de espera agotado a través del cuarto sondeo consecutivo con tiempo de espera agotado.
Como respuesta al quinto sondeo consecutivo con tiempo de espera agotado, la acción que realiza el supervisor de fallos de servidor es un reinicio.
Las entradas se aplican independientemente del estado de conexión entre la base de datos y el supervisor de fallos de servidor cuando se produce el tiempo de espera.
El estado de conexión entre la base de datos y el supervisor de fallos de servidor debe permanecer sin cambios después de que se produce 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 finalizado, se imprime el siguiente mensaje en el archivo de registro del recurso:
```
Timeout #5 has occurred. Restarting.
```