Oracle RAC: problemas de rendimiento de base de datos

Base de datos colgada

El área de soporte de Oracle define una “verdadera” base de datos colgada como "un punto muerto interno o una dependencia cíclica entre dos o más procesos". Cuando se trata de bloqueos DML (es decir, la puesta en cola tipo TM), Oracle es capaz de detectar esta dependencia y hacer retroceder uno de los procesos para romper la condición cíclica. Por otra parte, cuando esta situación se produce con los recursos a nivel del núcleo interno (como pestillos o pasadores), Oracle solía ser generalmente incapaz de detectar y resolver el punto muerto de forma automática.

Si se encuentra con una situación de base de datos colgada, es necesario realizar volcados de estado del sistema de manera que el soporte de Oracle pueda comenzar a diagnosticar la causa raíz del problema. Siempre que use este tipo de vertederos para un bloqueo, es importante tomar al menos tres de ellos con unos pocos minutos de diferencia, en todas las instancias de la base de datos. De esta manera, la evidencia muestra si un recurso sigue detenido de un momento a otro.

El tamaño del archivo maxdump debe establecerse como ilimitado, ya que esto generará archivos de seguimiento más grandes y más extensos, dependiendo del tamaño del área global del sistema (SGA), el número de sesiones de inicio de acceso, y la carga de trabajo en el sistema. El vertedero SYSTEMSTATE contiene una sección separada con información para cada proceso. Normalmente, es necesario tomar dos o tres vertederos en intervalos regulares. Siempre que se realice volcados de SYSTEMSTATE de manera repetitiva, asegúrese de volver a conectarse cada vez para obtener una nueva ID de proceso y también los nuevos archivos de seguimiento. ¡Espere a obtener enormes archivos de rastreo!

A partir de la base de datos Oracle 10g, un vertedero SYSTEMSTATE incluye información del historial de espera de la sesión. Si está utilizando Oracle 10g o posterior, no es necesario tomar varios volcados de estado del sistema. El vertedero SYSTEMSTATE puede ser tomado por cualquiera de los métodos siguientes.

A partir de SQL *Plus:

alter session set max_dump_file_size = unlimited; alter session set events 'immediate trace name systemstate level 10';

Usando oradebug:

REM The select below is to avoid problems on pre 8.0.6 databases select * from dual; oradebug setmypid oradebug unlimit oradebug dump systemstate 10

Cuando la base de datos se cuelga y no se puede conectar a SQL *Plus, puede intentar invocar SQL *Plus con la opción preliminar si está utilizando Oracle 10g o posterior. Esto une el proceso para la instancia de Oracle y no se ejecutan comandos SQL. No se desencadenan registros de inicio de sesión o pre-procesamiento, y no se permite la ejecución de consultas SQL. Vea el cambio en la bandera de sqlplus normal y sqlplus preliminar.

$sqlplus -prelim SQL*Plus: Release 10.2.0.1.0 - Production on Wed Nov 9 11:42:23 2005 Copyright (c) 1982, 2005, Oracle. All rights reserved. Enter user-name: / as sysdba SQL>

Alternativamente, oradebug le permite volcar el estado del sistema global mediante la conexión a un nodo. A continuación se muestra el volcado SYSTEMSTATE global desde oradebug: oradebug –g all dump systemstate 10

La opción -g es utilizada para bases de datos sólo para RAC. Esto volcará estados del sistema para todos los casos. El archivo de volcado/rastreo SYSTEMSTATE se puede encontrar en el directorio user_dump_dest en la instancia en la que se generó el volcado.

Utilería Hanganalyze

Un problema grave del rendimiento puede ser confundido con latencia. Esto suele suceder cuando la contención es tan mala que parece que la base de datos está completamente bloqueada. Por lo general, un vertedero SYSTEMSTATE se utiliza para analizar estas situaciones. Sin embargo, si la instancia es grande, con más de unos pocos gigabytes de SGA y con una gran carga de trabajo, un vertedero SYSTEMSTATE puede tardar una hora o más y, a menudo fallará en volcar todo el SGA y las estructuras de bloqueo. Por otra parte, un vertedero SYSTEMSTATE tiene las siguientes limitaciones cuando se trata de cuestiones de colgado:

• Lee el SGA de manera "sucia", por lo que puede ser incoherente a la hora de volcar todo un largo proceso.

• Por lo general, vierte mucha información (la mayoría de la cual no se necesita para determinar el origen de la caída), lo que hace que sea difícil determinar rápidamente las dependencias entre los procesos.

• No identifica los procesos de "interesantes" en los que realizar volcados adicionales (ERRORSTACK o estado del proceso, PROCESS STATE).

• A menudo es una operación muy cara en las bases de datos que tienen grandes SGAs. Un volcado SYSTEMSTATE puede tomar horas, y realizar volcados continuos dentro de un intervalo de pocos minutos es casi imposible.

Para superar las limitaciones del vertedero SYSTEMSTATE, una nueva utilería llamada hanganalyze se introdujo en Oracle 8i. En Oracle 9i, el comando hanganalyze se ha mejorado para proporcionar información de todo el cluster en entornos RAC de una sola vez. Este sistema utiliza el proceso demonio (daemon) DIAG en el proceso de RAC para la comunicación entre las instancias. En todo el cluster, hanganalyze generará información para todas las sesiones de la agrupación, independientemente de la instancia que emitió el comando.

Hanganalyze se puede invocar desde SQL *Plus o mediante oradebug (que está disponible cuando se conecta como SYS en la utilería SQL *Plus). La siguiente sintaxis se puede utilizar para obtener el rastro de hanganalyze cuando se conecta a SQL *Plus:

alter session set events 'immediate trace name hanganalyze level ';

O cuando está conectado como SYS:

oradebug hanganalyze

En el cluster, hanganalyze se puede obtener de este modo:

oradebug setmypid oradebug setinst all oradebug -g def hanganalyze

Ello establece la cantidad de información adicional que se extraerá de los procesos que hanganalyze ha encontrado (volcado ERROSTACK) basándose en el estado (STATE) del nodo. La siguiente tabla describe los diferentes niveles y la información de rastreo emitida cuando se han configurado:

Hanganalyze utiliza llamadas al núcleo interno para determinar si una sesión está esperando un recurso y reporta las relaciones entre los bloqueadores y quienes esperan. Además, se determina qué procesos son "interesantes" como para verterse, y se pueden llevar a cabo volcados automáticos de estado de proceso (PROCESS STATE) y ERRORSTACKs en esos procesos, con base en el nivel utilizado durante la ejecución de hanganalyze.

NOTA: Hanganalyze no pretende sustituir a un vertedero SYSTEMSTATE, pero puede servir como una hoja de ruta para interpretar un estado del sistema, mientras que se diagnostican problemas complejos. Los problemas de rendimiento relacionados con la fila de objetos de caché, en cola, y los cierres pueden ser analizados solamente con hanganalyze y/o un vertedero SYSTEMSTATE. La información de estado del proceso en estos vertederos proporciona una imagen precisa de las cerraduras/cierres en poder de cada proceso o sesión. También nos dice qué evento estaba esperando el proceso y si se llevaron a cabo los bloqueos TM para una transacción. Los problemas asociados con las cerraduras sentencia DDL y los problemas de bloqueo de fila de caché se pueden depurar usando sólo estos vertederos.

Sobre el autor: K Gopalakrishnan es consultor senior con el grupo de Servicios de Tecnología Avanzada en Oracle Corporation, especializado exclusivamente en la optimización del rendimiento, alta disponibilidad y recuperación de desastres. Él es un experto reconocido en Oracle RAC y el funcionamiento interno de la bases de datos y ha utilizado su amplia experiencia para solucionar muchos molestos problemas de rendimiento en todo el mundo para gigantes de las telecomunicaciones, bancos, instituciones financieras, y universidades.