Detectar sesiones bloqueándose entre instancias de un RAC

Detectar sesiones que estan bloqueandose en un ambiente RAC no es tan sencillo como en una “single instance”, el lockeo puede estar produciendose entre sesiones de diferentes instancias
instance
Con esta consulta podemos obtener información sobre las sesiones que están bloqueándose de forma cruzada entre distintas instancias de un RAC.

SELECT b.inst_id,LPAD(‘—>’,DECODE(A.request,0,0,5))   ||A.SID SID, a.id1, a.id2, a.lmode, a.BLOCK, a.request,   DECODE(a.TYPE,    ’MR’, ‘Media Recovery’,    ’RT’, ‘Redo Thread’,    ’UN’, ‘User Name’,    ’TX’, ‘Transaction’,    ’TM’, ‘DML’,    ’UL’, ‘PL/SQL User Lock’,    ’DX’, ‘Distributed Xaction’,    ’CF’, ‘Control File’,    ’IS’, ‘Instance State’,    ’FS’, ‘File Set’,    ’IR’, ‘Instance Recovery’,    ’ST’, ‘Disk Space Transaction’,    ’TS’, ‘Temp Segment’,    ’IV’, ‘Library Cache Invalidation’,    ’LS’, ‘Log Start or Switch’,    ’RW’, ‘Row Wait’,    ’SQ’, ‘Sequence Number’,    ’TE’, ‘Extend Table’,    ’TT’, ‘Temp Table’, a.TYPE) lock_type,    b.PROGRAM,b.OSUSER ,b.USERNAME,b.status,    b.module,b.action ,b.LOGON_TIME,b.LAST_CALL_ET,    ’alter system kill session ‘ || ”” || a.SID    || ‘, ‘ || b.serial# ||”” || ‘ immediate;’ kill_session,    DECODE(object_type, NULL, NULL, ‘Dbms_Rowid.rowid_create(1, ‘ ||    row_wait_obj# || ‘, ‘    || row_wait_file# ||’, ‘ ||     row_wait_block#||’, ‘ || row_wait_row# ||’)') row_id FROM gV$LOCK a, gv$session b, dba_objects o WHERE (a.id1,a.id2) IN        (SELECT id1,id2 FROM gV$LOCK WHERE lmode=0)    AND a.INST_ID=b.INST_ID    AND a.SID=b.SID    AND o.object_id (+) = DECODE(b.ROW_WAIT_OBJ#, -1, NULL, b.ROW_WAIT_OBJ#) ORDER BY a.id1,a.id2,a.request;

Estimar duración de una operación de restore con RMAN

Cuando realizamos un restore con rman, en una base de datos montada sobre filesystems, podemos darnos una idea del avance de la operación de restauración verificando la copia a disco de los datafiles en el directorio correspondiente.
En el caso que nuestra base este sobre raw devices, como ocurre con OPS o RAC, no siempre podemos detectar a simple vista el progreso de esta tarea; principalmente por que en el directorio donde oracle ve los datafiles tenemos links simbólicos del sistema operativo a particiones raw.
Podemos estimar entonces el avance utilizando una consulta sobre la vista v$session_longops. Esta vista nos muestra el estado de las operaciones que llevan ejecutándose más de 6 segundos, por lo general operaciones de backup, restore recovery, toma de estadísticas y consultas importantes.
Corriendo la siguiente consulta:

SELECT sid, serial#, context, sofar, totalwork,   ROUND(sofar/totalwork*100,2) “% COMPLETE”  FROM V$SESSION_LONGOPS  WHERE opname LIKE ‘RMAN%’  AND opname NOT LIKE ‘%aggregate%’  AND totalwork != 0  AND sofar != totalwork;

Obtenemos:

SID    SERIAL#    CONTEXT      SOFAR  TOTALWORK  %COMPLETE       18          1          1   10235772   11137792       91.9

Donde vemos en el último campo “% COMPLETE”, el porcentaje total ejecutado de la operación.
En el caso que al correr de manera consecutiva la consulta, por ejemplo cada 2 segundos, no veamos un progreso en el valor de dicho campo; tendríamos que investigar en la vista V$SESSION_WAIT si no estamos en presencia de algún evento de espera que este asociado a la contención en la operación de restore.

SD’A

Que es el GSD en Oracle RAC 9i?

GSD o Global Services Daemond en Oracle RAC 9i, realiza las tareas de índole administrativas (startup, shutdown, etc) solicitadas por parte de clientes como pueden ser SRVCTL, DBCA Y OEM que terminan finalmente interactuando con éste. Este proceso debe estar levantado y corriendo en todos los nodos del RAC para que estas funcionalidades este cien por ciento disponibles y operen de manera correcta, sin embargo solo es necesario la presencia de “un solo” proceso GSD corriendo por nodo en el caso que existieran varias instalaciones diferente de Oracle RAC en el mismo equipo del cluster.
Como ya dijimos, este proceso que corre en background debe estar presente para que puedan realizarse las mencionadas operaciones de administración requeridas por parte del SRVCTL, pero debemos aclarar que éste no es un proceso propio de la instancia y tampoco es levantado por ella durante el startup de la misma. Esta tarea debemos realizarla en forma manual por medio de los comandos gsdctl correspondientes:


gsdctl start – To start the GSD service
gsdctl stop – To stop the GSD service
gsdctl stat – To obtain the status of the GSD service


El binario del Global Services Daemond lo encontramos ubicado en $ORACLE_HOME/bin. Por otro lado, y dentro de las funciones del GSD está el registrar la información de su interacción con los clientes antes citados, por ejemplo las solicitudes desde el SRVCTL o el DBCA y las logea en el archivo gsdaemon_node_name.log ubicado en el directorio $ORACLE_HOME/srvm/ .
Finalmente podemos comentar que a partir de 10g el proceso GSD solo tiene como objetivo responder requerimientos de “management clients” de RAC 9i, por lo tanto si no hay presente bases de datos de esta versión éste no cumplirá ninguna función y el presentar un estado offline no generaría ningún impacto operativo. en este caso existe una manera de deshabilitarlo para evitar probables errores.

SD’A

Registración automática del listener y configuración cruzada en RAC

Previamente a la versión de base 8i, la información sobre la registración de instancias por parte del listener debía ser configurada explícitamente de forma manual en el archivo de configuración listener.ora . A partir de 8i las instancias pueden realizar esta registración de manera automática luego que la instancia levanta y gracias a la ayuda del proceso backgroud PMON el cual lo realiza contra el listener_default, siempre y cuando el parámetro de inicio local_listener no esté definido. Cuando nos referimos a listener default, hablamos del que lleva por nombre LISTENER y escucha en el puerto 1521.
El llamado Automatic Service Registration (ASR), como es de esperar, reduce la sobrecarga de tareas administrativas cuando contamos con una instalación de varias instancias o bases de datos.
Como dijimos antés, básicamente esta tarea de registración es realizada por el proceso PMON el cual le proporciona al listener información propia de la instancia como ser nombre, carga actual y máxima , nombre del servicio proporcionado por la base de datos, información sobre servidores dedicados y/o dispatcher, etc. El PMON realiza esta tarea de envío de información al listener cada 60 segundos y si eventualmente por algún problema que lo afecte no lo hiciera, la información no podría ser registrada contra el listener de manera periódica. Entonces podremos en este caso realizar la resgistración de forma manual utilizando el comando ALTER SYSTEM REGISTER el cual fuerza la registración de la base de datos (instancia) contra el o los listener/s correspondiente. La registracion automática del servicio no requiere de ninguna configuración extra en el archivo listener.ora, pero sí debemos asegurarnos que los siguiente parámetros de inicio este correctamente configurados para que ASR funcione de manera adecuada.

- service_name: el cual, como sabemos, se forma de la unión de los parámetros db_name y db_domain

- instance_name: Indica efectivamente el SID de la instancia.

Por defecto, el proceso PMON registra información del servicio contra el listener local, como dijimos con configuración default, nombre LISTENER address local y puerto 1521.
Si eventualmente necesitaramos que el proceso PMON registre la instancia contra listeners NO default, es decir con dirección local pero cuyo puerto no sea el estándar 1521 y diferente nombre, debemos configurar el parámetro de inicio local_listener para dar la ubicación de cual será nuestro listener local en este caso.
Otra opción atractiva y altamente recomendable en ambiente RAC es la de registrar la instancia contra un listener remoto, donde obtenemos una opción más para robustecer las opciones de alta disponibilidad. Para realizar esta tarea debemos configurar el parámetro de inicio remote_listener indicando la dirección del listener remoto.

Como realizar la registración cruzada en RAC

Cuando estamos en un ambiente Real Application Cluster debemos asegurarnos que la registración cruzada entre instancias se lleve a cabo correctamente, como comentamos ántes esto lo realizamos por medio de los parámetros particulares de inicio: local_listener y remote_listener.

A continuación describo los pasos que me han resultado efectivos para realizar esta tarea en un RAC de dos nodos:

1) Crear alias en el archivo tnsnames.ora del servidor (ambos) para el listener local y el remoto

LISTENER_INST1 =   (ADDRESS_LIST =   (ADDRESS = (PROTOCOL = TCP)(HOST = nodo1)(PORT = 1523))   )  LISTENER_INST2 =   (ADDRESS_LIST =   (ADDRESS = (PROTOCOL = TCP)(HOST = nodo2)(PORT = 1523))   )

2) Setear los parámetros local_listener y remote_listener referenciando a los alias correspondientes.

INST1.local_listener = LISTENER_INST1 #(local nodo1)  INST1.remote_listener = LISTENER_INST2 #(remoto nodo2)  INST2.local_listener = LISTENER_INST2 #(local nodo2)  INST2.remote_listener = LISTENER_INST1 #(remoto nodo1)

3) Para realizar la prueba podríamos levantar ambos listeners y ambas instancias y luego verificar que los listeners en ambos nodos esten escuchando para cada una de las instancias.

Muchas veces, un repaso a esta configuración puede ahorrarnos dolores de cabeza a la hora de resolver problemas de balanceo de carga y situaciones de failover.

SD’A

Estimar el tiempo de rollback de una transacción

Como es de saber, cuando una sesión termina de manera anormal, toda transacción que no ha sido confirmada todavía comenzará un proceso de rollback. En algunos casos y de acuerdo al volumen de datos en cuestión esta operación puede demorar bastante tiempo y es interesante, y a veces necesario, poder estimar cuanto será ese tiempo.
Podemos entonces consultar las vista v$transaction y v$session para poder calcular cuan larga será la espera para que finalice la operación de rollback.
La siguiente consulta nos devolverá la cantidad de bloques de undo utilizados por la transacción

SELECT a.used_ublk  FROM v$transaction a, v$session b  WHERE a.addr = b.taddr  AND b.sid = //Sid en cuestión//

Si al correr la consulta nos retorna 85000 bloques y al esperar un minuto y ejecutar nuevamente la consulta tenemos 80000 bloques utilizados, obtenemos una tasa de liberación de 5000 bloques por minuto.
De esta manera estamos en condiciones de calcular que, a una tasa de liberación de 5000 bloques por minuto tardará 16 minutos en liberar los restantes 80000 bloques utilizados.

(80000 bloques)/(50000 bloques/minuto) =16 minutos para finalizar la operación.

Con esta sencilla fórmula podremos estimar con bastante aproximación el tiempo empleado para largas operaciones de rollback.

SD’A