Omitir Vínculos de navegación | |
Salir de la Vista de impresión | |
Guía de Oracle Solaris Cluster Data Service para Oracle Oracle Solaris Cluster 3.3 3/13 (Español) |
1. Instalación y configuración de HA para Oracle
Descripción general del proceso de instalación y configuración de HA para Oracle
Planificación de la instalación y la configuración de HA para Oracle
Preguntas para la planificación de la configuración
Preparación de los nodos y los discos
Cómo configurar el acceso a la base de datos Oracle con Solaris Volume Manager
Cómo configurar el acceso a la base de datos Oracle con Veritas Volume Manager
Cómo configurar el acceso a la base de datos Oracle con Oracle ASM
Cómo configurar un agente de escucha de SCAN de Oracle Grid Infrastructure para clusters
Instalación del software de Oracle ASM
Verificación de la instalación del software de Oracle ASM
Instalación del software de Oracle Database
Cómo instalar el software de Oracle Database
Cómo definir los parámetros del núcleo de Oracle Database
Verificación de la instalación y la configuración de Oracle Database
Cómo verificar la instalación de Oracle Database
Creación de una base de datos Oracle
Cómo crear una base de datos primaria de Oracle
Configuración de permisos de base de datos de Oracle
Cómo definir permisos de bases de datos Oracle
Instalación de los paquetes de HA para Oracle
Cómo instalar los paquetes de HA para Oracle
Registro y configuración de HA para Oracle
Herramientas para registrar y configurar HA para Oracle
Configuración de las propiedades de extensión de HA para Oracle
Cómo registrar y configurar HA para Oracle (clsetup)
Cómo registrar y configurar HA para Oracle sin Oracle Grid Infrastructure (CLI)
Verificación de la instalación de HA para Oracle
Cómo verificar la instalación de HA para Oracle
Ubicación de los archivos de registro de HA para Oracle
Ajuste los supervisores de fallos de HA para Oracle
Funcionamiento del supervisor de fallos de servidor de Oracle
Funcionamiento del supervisor de fallos principal
Funcionamiento del sondeo de fallos del cliente de la base de datos
Operaciones para supervisar la partición de registros de rehacer archivados
Operaciones para determinar si la base de datos está operativa
Exploración de las alertas registradas por el supervisor de fallos de servidor
Funcionamiento del supervisor de fallos de escucha de Oracle
Personalización del supervisor de fallos Servidor de HA para Oracle
Definición del comportamiento personalizado de errores
Formato de archivo de acción personalizado
Cambio de la respuesta a un error de DBMS
Respuesta a un error con efectos importantes
Omisión de un error con efectos secundarios
Cambio de la respuesta a las alertas registradas
Cambio del número máximo de sondeos consecutivos con tiempo de espera finalizado
Propagación de un archivo de acción personalizada a todos los nodos de un cluster
Actualización de tipos de recursos de HA para Oracle
Actualización del tipo de recurso SUNW.oracle_listener
Información para registrar la nueva versión del tipo de recurso
Información para migrar las instancias existentes del tipo de recurso
Actualización del tipo de recurso SUNW.oracle_server
Información para registrar la nueva versión del tipo de recurso
Información para migrar las instancias existentes del tipo de recurso
Cambio del rol de una instancia de Oracle Data Guard
Cómo cambiar el rol de una instancia de Oracle Data Guard
A. Propiedades de extensión de HA para Oracle
B. Acciones preestablecidas para errores de DBMS y alertas registradas
C. Configuraciones de ejemplo de Oracle ASM con 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.
Las siguientes secciones describen las actividades que se realizan para personalizar el supervisor de fallos Servidor de HA para Oracle:
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:
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.
Nota - 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é sobrescribiendo 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:
Indica el tipo de error que ha detectado el supervisor de fallos del servidor. Se permiten los siguientes valores para esta palabra clave:
Especifica que el error es un error de DBMS.
Especifica que el error es una alerta que está registrada en el archivo de registro de alertas.
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.
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.
|
Debe especificar la palabra clave ERROR. Si omite esta palabra clave, la entrada en el archivo de acción personalizado se ignora.
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:
Especifica que el supervisor de fallos del servidor ignora el error.
Especifica que el supervisor de fallos del servidor se detiene.
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.
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.
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.
Especifica que la entrada se aplica únicamente si el supervisor de fallos del servidor intenta conectarse a la base de datos.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
Nota - No se debe crear una entrada para el primer sondeo con tiempo de espera finalizado. La acción que realiza el supervisor de fallos del servidor como respuesta al primer sondeo con tiempo de espera finalizado está preestablecida.
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.
Consejo - Para facilitar la depuración, especifique un mensaje que indique el número de secuencia del sondeo con tiempo de espera finalizado.
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.
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)
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. |
Establezca esta propiedad en la ruta absoluta del archivo de acción personalizado.
# clresource set -p custom_action_file=filepath server-resource
Especifica la ruta absoluta del archivo de acción personalizado.
Especifica el recurso SUNW.oracle_server.