BACKGROUND IMAGE: iSTOCK/GETTY IMAGES

Este contenido es parte de Guía Esencial: Novedades de Oracle y consejos para sus usuarios
Resolver Problemas Consiga ayuda para problemas específicos con sus proyectos, procesos y tecnologías.

Oracle RAC: problemas de rendimiento de base de datos

Las bases de datos Oracle RAC comparten recursos con otras aplicaciones que también están en demanda. A veces, la gestión de recursos se ejecuta en un callejón sin salida. Este extracto de "Base de Datos Oracle 10g: Manual de Aplicaciones Clusters Reales" examina lo que ocurre con una base de datos colgada y cómo solucionarlo.

Las bases de datos de RAC tienen más de una instancia utilizando el mismo conjunto de recursos, y un recurso puede ser solicitado por más de una instancia. El intercambio de recursos está bien gestionado por los servicios globales de caché (GCS) y los servicios globales de encolamiento, o enqueue (GES). Sin embargo, en algunos casos, las operaciones de gestión de recursos podrían llegar a una situación de bloqueo y toda la base de datos puede quedar colgada debido a problemas de seriación. A veces, los errores de software también pueden causar problemas de latencia en la base de datos, y estas situaciones casi siempre requieren la intervención de soporte de Oracle en la forma de una solicitud de servicio.

Los problemas de caída de bases de datos se pueden colocar en las siguientes categorías:

• Bases de datos colgadas

• Sesiones colgadas

• Desempeño o rendimiento general de la instancia o base de datos

• Rendimiento de las consultas

Vamos a examinar únicamente la base de datos colgada, ya que es más crítica y compleja que los otros y también se relaciona con nuestro punto de interés. Textos detallados están disponibles para analizar el rendimiento de las consultas y las bases 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:

Nivel

Información de rastreo

1-2

Sólo hanganalyze de salida, sin volcado de proceso en absoluto

3

Nivel 2 + procesos de solo volcado como si estuviera colgado (estado IN_HANG)

4

Nivel 3 + nodos de hoja de vaciado (bloqueadores) en las cadenas de espera (hoja LEAF, LEAF_NW, estado IGN_DMP)

5

Nivel 4 + volcado de todos los procesos que intervienen en las cadenas de espera (estado NLEAF)

10

Volcar todos los procesos (estado IGN)

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.

Investigue más sobre Bases de datos

Únase a la conversación

1 comentario

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

Buenas tardes, se tiene una base de datos : Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options. Durante dos dias se presentaron problemas que derivaron en el reinicio debido a la lentitud. Los DBA's dignosticaron problemas de Indice, en la primera caida, en la segunda problemas con la cantidad de registros de otra tabla. Como usuario percibo es que  al finalizar la jornada los tiempos en el procesamiento suben, sin embargo cunado reinicia la BD. Esos tiempos se minimizan hasta en un 70%. 
Por favor algún consejo para determinar el origen de la lentitud y degradación de BD.

Cancelar

- ANUNCIOS POR GOOGLE

Close