Best practices para el uso de transacciones distribuidas XA con productos Oracle

Transcripción

1 Oficina Técnica para la Gestión y Supervisión de Servicios TIC Subdirección de Tecnologías de la Información Best practices para el uso de transacciones distribuidas XA con productos Oracle Referencia documento: InfV5_JASAS_XA_BestPractices_V430.doc Fecha: Versión: 4.3.0

2 Registro de Cambios Fecha Autor Versión Notas 17 de Octubre de 2013 Emilio Nestal Versión inicial Revisiones Nombre Jonathan Ortiz Role Advanced Support Engineer Distribución Copia Nombre Empresa 1 Subdirección de Tecnologías de la Información 2 Servicio de Coordinación de Informática de la Consejería de Hacienda y Administración Pública Servicio Andaluz de Salud, Junta de Andalucía Consejería de Hacienda y Administración Pública, Junta de Andalucía Pág. 2 / 26

3 Índice de Contenidos CONTROL DE CAMBIOS... 4 INTRODUCCIÓN... 5 OBJETIVOS DE ESTE DOCUMENTO... 6 BEST PRACTICES DE USO DE TRANSACCIONES DISTRIBUIDAS... 7 Introducción... 7 Visión general... 8 Transacciones distribuidas basadas en XA... 9 Transacciones distribuidas controladas por Oracle RDBMS USO DE XA CON ORACLE DATABASE Timeouts XA y Oracle Database Transacciones distribuidas y la gestión de bloqueos Transacciones distribuidas y la optimización Read-Only Transacciones distribuidas y la información de REDO Gestión de transacciones distribuidas en Oracle Database USO DE XA Y ORACLE REAL APPLICATION CLUSTERS (RAC) Oracle Database versión 9.0 y anteriores Oracle 9iR2 RAC Oracle 10gR1 RAC Oracle 10gR2 RAC Oracle 11gR1 RAC Oracle 11gR2 RAC USO DE XA Y OTRAS OPCIONES DE ORACLE DATABASE Privilegios relacionados con XA XA y Database Links XA y Oracle Real Application Testing XA y PL/SQL Pág. 3 / 26

4 Control de cambios Cambio Descripción Página 1 Primera versión de este documento. N/A Pág. 4 / 26

5 Introducción Este documento recoge una serie de recomendaciones de Oracle Soporte planteadas como buenas prácticas de desarrollo para aplicaciones que hagan uso de transaciones distruidas o XA a través de los productos Oracle RDBMS Server, Oracle Tuxedo y Oracle Weblogic Server. Estas recomendaciones están encaminadas a minimizar los posibles problemas de rendimiento en sistema de cualquier tamaño y en la gran mayoría de los casos se basan en la experiencia de casos reales gestionados por Oracle Soporte. Finalmente, este documento también recoge una serie de conceptos de componentes, módulos y tecnologías relacionadas con Oracle RDBMS 11gR1 y 11gR2 Real Application Cluster (RAC), Oracle Weblogic Server 11gR1 (WLS) y Oracle Tuxedo 11g que a juicio de Oracle Soporte deberían tenerse claros para asegurar la aplicación de las recomendaciones recogidas en este documento, y de manera general, entender los productos Oracle sobre los que se sustentan los sistemas y aplicaciones. Pág. 5 / 26

6 Objetivos de este documento A lo largo de los puntos de este documento se irá definiendo una guía de buenas prácticas para el desarrollo de aplicaciones y para el uso de productos Oracle que usen el protocolo XA para la gestión de transacciones distribuidas. Este documento se centra en el productos Oracle RDBMS, tanto en modo single instace como en clúster a través de Real Application Cluster 11gR1. Respecto a las versiones, el documento abarca el comportamiento desde la versión 9iR2 hasta la versión 11gR2. Pág. 6 / 26

7 Best practices de uso de transacciones distribuidas Introducción Una transacción distribuida es un conjunto de dos o más ramas de una misma transacción relacionadas que tienen que gestionarse de forma coordinada. Las operaciones transacionales pueden abarcar múltiples fuentes de datos. Por ejemplo, una transacción distribuida puede implicar la gestión de una transacción a través de, por ejemplo, una base de datos como Oracle RDBMS, y una cola de mensajes como MQ Series, o dos bases de datos independientes En el entorno actual de IT, el uso de transacciones distribuidas o globales es cada día vez más generalizado y mas amplio, especialmente desde su adopción por arquitecturas basadas en componentes Java EE. Aunque las transacciones distribuidas se han utilizado desde hace muchos años, la especificación XA se publicó en 1991, hay una clara falta de conciencia de las implicaciones de diseño y de utilización de transacciones distribuidas dentro de una arquitectura. En este documento se analizarán algunas de las áreas que potencialemnte se tienen que tener en cuenta cuando se utiliza transacciones XA, a saber: La recuperabilidad de datos: dado que puede varias fuentes con distintas versiones de un mismo hecho, la coherencia transaccional sólo puede mantenerse si todas las fuentes de datos pueden ser recuperados en el mismo punto transaccional consistente. Con las transacciones controladas por Oracle es posible usar el SCN, pero esto puede aumentar el nivel de pérdida de datos para abarcar todas las bases de datos que participan en el proceso de recuperación. Es decir, con transacciones distribuidas XA que no hay manera fácil de sincronizar las fuentes de datos heterogéneas al mismo punto transaccional consistente. Transacciones dudosas: durante un fallo, las transacciones "en la duda" pueden causar bloqueos sobre cualquiera de los datos que se ha modificado y que ya en estado "preparado". Hasta que la transacción en estado "preparada" no se pueda recuperar de confirmar commit o rechazar rollback, los datos afectados pueden no ser accesibles para otras transacciones. Un solo fallo puede afectar a un conjunto más amplio de funciones dentro de las aplicacións que estén utilizando estos datos. Rendimiento: debido a la comunicación adicional inherente a una transacción distribuida en dos fases, así como la necesidad de escribir mas información en los registros de transacciones, el uso de transacciones distribuidas normalmente incurre en una sobrecarga de rendimiento en comparación con un solo transacciones de fase. Por tanto, las transacciones distribuidas se deben utilizar solamente en escenarios de múltiples fuentes de datos que deben ser actualizados en la misma transacción de negocio o cuando se utiliza como parte integrante de un producto, por ejemplo, servidor de aplicaciones Oracle BPEL Process Manager. El alcance de las transacciones distribuidas debería ser el menor posible, tanto para limitar el impacto de las fallo como para simplificar los procedimientos de recuperación que pueden ser necesarios para restablecer la coherencia transaccional en todas las bases de datos o en las fuentes datos relacionados. Pág. 7 / 26

8 Visión general Es recomendable estudiar enfoques alternativos antes de comprometerse con una arquitectura que abarca transacciones distribuidas. Por ejemplo, sería recomendable estudiar si existe la posibilidad de que una fuente de datos esté enviando cambios a la otra, y a continuación, se actualiza el origen de datos secundarios y se haga commit sobre ellos antes de actualizar el origen de datos principal. En este escenario, si la transacción falla antes del commit global, los datos sobre los que se haya hecho commit en el origen de datos secundario permanecerán, pero se tendrá que hacer roollback en base de datos principal. En este escenario, si se desea reiniciar la transacción, la fuente de datos principal deberá comprobar si la actualización se ha aplicado a la fuente de datos secundarios, por ejemplo, a través de una clave única, antes de realizar cualquier nueva operación. Si se detecta un duplicado, por ejemplo, la transacción puede ser desechada y la fuente de datos principal se actualizará para reflejar el éxito de la actualización en el origen de datos secundario. Como hemos comentado antes, na transacción distribuida es un conjunto de dos o más ramas de una misma transacción que están relacionados y que se tienen que gestionar de forma coordinada. Las operaciones posibles pueden abarcan múltiples fuentes de datos, por ejemplo, una transacción distribuida puede implicar la gestión de una transacción a través de una base de datos, por ejemplo, Oracle y una cola de un software de mensajería, por ejemplo, MQ Series, o dos bases de datos independientes, por ejemplo, Oracle y Oracle. Al utilizar transacciones distribuidas pueden existir múltiples versiones de la verdad, y esto puede causar bastantes problemas sobre todo en situaciones de recuperación en todos los puntos implicados hasta el mismo punto transaccional consistente. Sin embargo, el reto principal es tener un mecanismo que mantiene la coherencia transaccional durante el funcionamiento normal, esto se logra mediante un mecanismo de confirmación en dos fases. Este mecanismo de confirmación de dos fases se divide, a su vez, en dos fases principales, una fase de "preparación" y una fase de "commit". En la fase de preparación, el coordinador de la transacción solicita a la otra base de datos / fuentes de datos de participantes a comprometerse a confirmar o deshacer la transacción. Estos registrarán sus transacciones como "preparada" y enviarán una respuesta al coordinador de transacciones. Durante la fase de confirmación, si todos los participantes en la transacción han acordado confirmar la transacción, entonces el coordinador de transacciones pide a todos los participantes confirmar la transacción. De lo contrario, si uno o más de los participantes no se ponen de acuerdo para confirmar la transacción, entonces el coordinador de transacciones pide a todos los participantes a deshacer la transacción. Una vez que todos los participantes han reconocido que han realizado la solicitud de commit o de rollback, la transacción se ha completado y el coordinador de transacciones se puede retirar o "olvidar" la existencia de la transacción distribuida. Esto se refiere a veces como la "fase de olvidar" y es de aplicación específica y fuera del estándar XA el cómo y cuándo el coordinador de transacciones elimina la información relativa a las transacciones distribuidas terminadas. Pág. 8 / 26

9 La mayoría de las implementaciones de dos fases tienen una optimización de tipo "read only", en el que las fuentes de datos no han tenido que aplicar cambios en el ámbito transacción distribuida durante la fase de preparación. Del mismo modo, existen implementaciones que también pueden tener un mecanismo de una fase, por lo que si sólo una fuente de datos ha sido usada o actualizada, la fase de preparación se omitirá y la transacción será confirmada, commit, en una sola fase. Todos los participantes en una transacción distribuida debe realizar la misma acción: deben, o bien todos hacen commit o todas efectúan un rollback de la transacción. El coordinador de la transacción automáticamente controla y vigila estos commit y rollback de transacciones distribuidas y mantienen la integridad transaccional utilizando el mecanismo de confirmación en dos fases. Sin embargo, si se produce un corte o fallo entre la fase de preparación y la fase de confirmación debido a que el coordinador de transacciones no está disponible, entonces las transacciones y sus datos asociados se pueden quedar en un estado dudoso o "en duda". Estos datos no se podrán cambiar hasta que el resultado de la transacción se haya resuelto, ya sea por el coordinador de transacciones o mediante la intervención externa, por ejemplo, por un DBA. En la mayoría de los casos, la operación de resolución de estas transacciones en duda se realiza automáticamente una vez que el coordinador de transacción vuelve a poder comunicarse al origen de datos. La resolución manual sólo debe ser necesaria cuando la transacción dudosa tiene bloqueos sobre recursos de datos críticos o la causan el host, la red o cualqueier otro software. En general, el mecanismo de confirmación en dos fases es completamente transparente y no requiere de programación especial por parte del usuario o del desarrollador de la aplicación. No obstante, requiere un coordinador de transacciones, esto puede ser o bien una base de datos como Oracle, un monitor de transacciones tales como Oracle Tuxedo o un servidor de aplicaciones como Oracle Servidor WebLogic. Transacciones distribuidas basadas en XA Modelo Distributed Transaction Processing del grupo X/Open La norma XA es una especificación del grupo X/Open para el procesamiento de transacciones distribuidas (DTP) a través de fuentes de datos heterogéneas, como por ejemplo, base de datos Oracle, que se publicó en En él se describe la interfaz entre el coordinador de transacciones y de las fuentes de datos que participan en la transacción distribuida. Dentro del coordinador de transacciones XA se denomina gestor de transacciones o Transaction Manager (TM) y de las fuentes de datos que participan se denominan los administradores de recursos o Resource Manager (RM). Algunos productos como la base de datos Oracle y Oracle WebLogic Server puede actuar como gestores de transacciones o administradores de recursos o ambos en la misma transacción XA. Ejemplos de un gestor de transacciones XA son: Oracle Tuxedo, Oracle WebLogic Server, la base de datos Oracle y IBM WebSphere Application Server. Ejemplos de Pág. 9 / 26

10 un administrador de recursos XA son: la base de datos Oracle, IBM DB2, MS-SQL, IBM MQ-Series y JMS. Al referirse a XA, la mayoría de las organizaciones se refieren a la versión 1 de la especificación XA. Sin embargo, en 1994 fue publicado un borrador (draft) de la versión 2 y es conocido como la especificación XA+, esto nunca fue ratificado y formalmente publicado como una norma técnica y por lo tanto no se utiliza ninguno de los proveedores clave XA. La especificación XA+ era una especificación mejorada que permita transacciones distribuidas que se coordinan a través de múltiples gestores de transacciones heterogéneas, por ejemplo, Oracle Tuxedo y la base de datos Oracle, así como dictar cómo los administradores de transacciones deben comunicarse con varias instancias de tipo RM, por ejemplo en Oracle RAC. Una versión de la especificación XA también se puede encontrar en My Oracle Support Nota The XA specification for Distributed Transaction Processing. El modelo DTP de X/Open se representa la siguiente casuistica, actualizaciones de varios administradores de recursos (RM) compatibles con XA un programa de aplicación (AP). Todos los cambios están coordinados por un gestor de transacciones XA (TM) para garantizar la coherencia transaccional a través de todos los RM. Cada RM tendrá al menos una rama de la transacción distribuida coordinada por el TM. Todas las ramas de la transacción distribuida debe ser completado, commit, o deshecho, rollback, como una sola unidad de trabajo. Dentro del modelo DTP de X/Open del AP se comunicará a la RM utilizando la interfaz nativa de la RM, por ejemplo, SQL o DML. La AP también comunicará a la TM mediante un protocolo denominado TX que permite establecer los límites de transacción. El protocolo TX tiene un número de implementaciones "estándar", a saber, XATMI (basado en Oracle Tuxedo), TxRPC (basdo en DCE) y XCPI-C (basado IBM Encina). No todas estas implementaciones son compatibles entre si,, por ejemplo Tuxedo sólo es compatible con los estándares XATMI y TxRPC, mientras que IBM Encina sólo es compatible con los estándares XCPI-C y TxRPC. JTA y JTS Aunque el uso del modelo DTP de X/OPEN está restringido principalmente a los administradores de transacciones tales como Oracle Tuxedo o IBM Encina, los conceptos de DTP han sido ampliamente desplegado. Por ejemplo, la especificación XA ha sido implementado como un conjunto estándar de API de Java en JavaEE conocida como la API Java Transaction especificación (JTA). JTA permite a un administrador de transacciones basado en Java realizar transacciones distribuidas. El API JTA es básicamente el modelo DTP de X/Open, pero reemplaza el protocolo TX con un conjunto de APIs Java que utilizan los programas de aplicación para establecer los límites de transacción. Un ejemplo de un gestor de transacciones JTA es Oracle WebLogic Server. También dentro de la especificación Java EE, se encuentra el servicio de transacciones Java (JTS). JTS es un contenedor Java que soporta la especificación JTA a alto nivel, mientras que las aplicacións Java usan Object Transaction Service de OMG (OTS) en un nivel inferior. OTS es un componente de Common Object Request Broker Architecture (CORBA) tambien de OMG que nunca fue ampliamente adoptado. La especificación OTS fue construido con la ayuda de X/Open y se basa en los conceptos propuestos en XA+ para proporcionar un medio para que las transacciones distribuidas para ser coordinadas a través de gestores transacciones Pág. 10 / 26

11 heterogéneas o múltiples. El modelo OTS también sustituyó al protocolo TX de XA así como los interfaces definidos en el modelo DTP de X/Open establecidos en CORBA. El modelo OTS fue definido para que fuera totalmente interoperable con el modelo DTP de X/Open. Sin embargo, JTS no implementa el modelo de OTS, pero proporciona una especificación de las interfaces en un gestor de transacciones compatible OTS / COBRA. Transaciones XA, conceptos Dentro de XA, el TM coordina todas las ramas de una transacción distribuida, así como el mantenimiento de la información de éstas dentro de su control. Si esta información de estado se pierde o no está disponible, entonces los RM subyacentes pueden requerir intervención manual para resolver las transacciones dudosas. En la medida que el TM es responsable de coordinar y controlar el progreso de una transacción distribuida, las aplicaciones, no deberán contener ninguna declaración específica al RM que, independientemente, deshará o confirmará la transacción distribuida. Por tanto, una aplicación no debe emitir ningún DDL, por ejemplo, TRUNCUTE o CREATE TABLE, ya que en sí misma es una operación autónoma implícita. El mecanismo de commit en dos fases de XA tiene las siguientes fases que se ejecutan por parte del TM y del RM cada vez que una aplicación confirma una transacción distribuida: Fase de preparación (prepare phase): El TM pide a los RM participantes que se preparen para hacer commit o rollback de una transacción solicitada, incluso si se produce un fallo. Si alguna RM no puede prepararse, la transacción se deshecha mediante un rollback. Fase de compromiso (commit phase): Si todos los RMs responden al TM que están preparados, el TM pide a todos los RMs que confirmen la transacción. Igualmente, XA es también compatible con las optimizaciones de transacciones en sólo lectura (read only) y en una fase (single phase). Dentro de una transacción distribuida XA hay un mínimo de dos o más ramas de transacción que se llevarán a cabo contra uno o más RMs. Dentro de un mismo RM, estas ramas pueden estar relacionadas o acopladas. Este acoplamiento pued e ser de dos tipos: estrechamente acoplado (tightly-coupled) o débilmente acoplado (looselycoupled). Si las ramas de transacción están fuertemente acoplados, entonces compartirán mecanismos de protección (locks). En consecuencia, para que, en un escenario de transacciones fuertemente acoplados, los cambios previos al commit realizados en una rama de transacción deben ser visibles por todas las ramas que pertenecen a la misma transacción distribuida. En el caso de transacciones débilmente acopladas, estas ramas no comparten las cerraduras y por tanto, no es necesario que dichos cambios sean visibles. En un escenario de transacciones distribuida, el RM debe garantizar que no se produzcan interbloqueos (deadlocks) entre los recursos necesarios en las diferentes ramas de una transacción XA. La forma en que esta funcionalidad se implemente es a discreción del fabricante del RM, y por tanto puede existir ciertas limitaciones el acceso concurrente de datos por parte del resto de las ramas fuertemente acoplados, Pág. 11 / 26

12 por ejemplo, sólo una rama puede estar ejecutando operaciones de tipo DML a la vez. El estándar XA permite el uso de la heurística para la realización de una o más ramas de transacción dentro de una transacción distribuida. Si se produce un fallo de comunicación, algunos RM puede emplear la heurística para decidir si una operación preparada se confirma (commit) o se deshace (rollback) con independencia de la decisión del TM, por ejemplo, para desbloquear una serie de recursos compartidos. Sin embargo, esto puede dejar los datos en un estado incoherente con respecto al resto de la transacción distribuida, por ejemplo, si un RM realiza commit sobre su rama, pero todas las demás ramas se les pide que deshagan su trabajo, el resultado será inconsistente. Esta situación incluye aquellas donde es necesaria la intervención manual, por ejemplo, de un DBA o administrador sistemas, para liberar los bloqueos (lock) que igualmente se convierte en una finalización heurística de dicha transacción distribuida. Hay que tener en cuenta que si un RM informa de la terminación heurística al TM, el RM no debe descartar la información que posee sobre la rama de transacción, es decir, aunque el resultado de la transacción distribuida se haya resuelta de forma manual, las referencias a la transacción heurística todavía pueden permanecer dentro de RM hasta eliminarse manualmente. El estándar XA también permite modos sincrónicos y asincrónicos de trabajo. El modo asíncrono es opcional dentro del estándar y no está implementdo por algunos fabricantes y productos, por ejemplo, en la base de datos Oracle. Para simular los diferentes escenarios de fallo de una transacción distribuida controlada mediante XA se recomienda revisar las siguientes notas de MyOracleSupport: Session Switching & Global Transaction Mgt, which provides a C source program Demonstration of Integrating OJMS operations within an XA Transaction, whichprovidesa Java source program. A diferencia de las transacciones distribuidas controladas por Oracle, la especificación XA no permite que un marcado de punto en el tiempo (point in time) se acuerde y establezca entre bases de datos participantes, por ejemplo, a través de la sincronización SCN que se ha comentado anteriormente. Esto significa que si se requiere una recuperación incompleta de uno o más RM, no existe un mecanismo para recuperar todos los RMs en el mismo punto transaccionalmente coherente en el tiempo. Para una recuperación incompleta, hay dos opciones: Diseñar mecanismo especificos de la aplicación para asegurar la consistencia transaccional en todos los RMs en el caso de recuperación incompleta. La recuperación en el tiempo se realiza a un punto donde la carga de trabajo era baja o nula. XA y la consistencía Point in Time a través de varios Resource Managers Cabe señalar que dentro de un sistema OLTP podría haber una gran cantidad de transacciones que tienen lugar en cualquier momento en particular, el estado de las transacciones individuales variarán de RM y no hay ninguna garantía de que todas las ramas de una transacción se completen en el mismo punto en el tiempo. Esto Pág. 12 / 26

13 afecta tanto a copias de seguridad y recuperaciones como se comentó anteriormente, así como a los diseños de aplicaciones que esperan o necesitan esa coherencia transaccional a través de todos los RMs. La especificación XA no establece qué orden una TM solicita a un RM la operación de commit o en qué plazo de tiempo los RMs debe realizarlo. Sólo se confirma que todos los RMs han acordado realizad la operación de commit sobre los datos. Por lo tanto, existe la posibilidad de que se produzca una sitación denominada race condition, sobre todo si el procesamiento depende de la orden de operaciones de escritura a uno o más de RMs. Este es un punto especialmente importante, ya que una aplicación que es independiente de la operativa de realización de la transacción distribuida puede ser capaz de leer los cambios realizados por la transacción distribuida antes de que estén disponibles para otros RM. Es importante destacar que la secuencia en la que el TM realiza las peticiones al RM para hacer los commits pueden realizarse en cualquier orden, por lo que el primer RM que es solicitado para confirmar la trasacción puede tener sus cambios realizados antes de que el último RM implicado realice lo priopio. Por el contrario, aunque el RM hay realizado su commit para el TM, estos cambios pueden necesitar ser procesados antes de ser puestos a disposición de otros usuarios del RM. Cuando varios RMs están implicados dentro de la misma transacción distribuida, el nivel de procesamiento para realizar los commits y que los cambios visibles a los demás puede variar de un RM a otro. Por lo tanto, existe la posibilidad de que la último RM al que se le pregunte para realizar el commit podría hacer que sus cambios fueran visibles antes de el primer RM recibiera la solicitud de commit por parte del TM. De cualquier manera, la coherencia transaccional no está garantizada hasta que todos los RMs se han comprometido y han hecho sus cambios visibles, independientemente de que mientras la fase de confirmación está en curso, exista la posibilidad de que un lector independiente a la transación distribuida para obtener una visión inconsistente de los datos a través de uno de los múltiples RMs implicados. Este problema de la consistencia de los datos en un punto particular en el tiempo puede afectar de sobre manera a arquitecturas basadas en mesajería o colas de mensajes. Por ejemplo, una transacción actualiza una o varias bases de datos y una cola de mensajes basado en un archivo. Si un proceso independiente supervisa la cola y lee el mensaje de la cola durante la fase de commit, existe la posibilidad de que los cambios correspondientes no estén todavía disponible para otros lectores en las bases de datos que se están actualizando. En estos casos de uso, el proceso de lectura independiente de la cola puede fallar, por no encontrar el resto de cambios que espera o, aún peor, terminar haciendo cambios a los datos basados con los valores válidos antes de la transacción distribuida de partida. Transacciones distribuidas controladas por Oracle RDBMS La base de datos de Oracle RDBMS se puede utilizar para coordinar una transacción distribuida a través de dos o más bases de datos Oracle que participan en una sola transacción. En esta sección del documento sólo se tendrán en cuenta las transacciones que utilizan un dblink entre dos base de datos y por tanto los ejemplos Pág. 13 / 26

14 se destinan a productos relacionados con Oracle RDBMS y transacciones distribuidas como la replicación avanzada o la propagación de Oracle AQ. Existen otros mecanismos y funcionalidades de Oracle RDBMS que usan transacciones distribuidas, como los diferentes gateways con otros bases de datos no Oracle, que difieren el procesamiento estándar descrito a continuación. El mecanismo de transacción distribuida de Oracle RDBMS posee tanto las optimizaciones de sólo lectura (read only) como la de una fase (single phase) que se describieron anteriormente. Si se le solicita a una base de datos preparar para una transacción distribuida y despues no se produce ningún cambio en la base de datos, ésta entonces devolverá un código de estado correspondiente a sólo lectura y no continuará con ninguna parte adicional en la transacción. Para una transacción distribuida que se produzca dentro de Oracle RDBMS, los cambios se deben hacer implicando a dos o más bases de datos dentro de la misma transacción. Si sólo hay una base de datos, la fase de preparación no es ejecutada y la transacción es considerada como remota (remote) en lugar de transacción distribuida. Tanto para las transacciones distribuidas como par las remotos, la base de datos iniciadora es el coordinador global de la operación (TM). De resto de bases de datos implicadas, la base de datos con la mayor valor para el parámetro COMMIT_POINT_STRENGTH será la nominada como commit point site de la transacción. En las transacciones remotas, esta base de datos siempre será la la base de datos que se actualiza. El commit point site es el punto único en el que se registra el estado de la transacción y donde se realizará el commit antes que cualquiera de las otras bases de datos implicadas. Adicionalmente, es la única base de datos que no entra en el estado de preparación (prepared) y por lo tanto puede no tener ningúna transacciones en estado pendiente en caso de error. Tenemos que tener en cuenta que el resultado de la transacción distribuida o remota en el commit point site determina si la transacción se confirma o se deshace. Si existen otros nodos involucrados, seguirán el ejemplo del primero, el commit point site. El coordinador global (TM) se asegurará de que todos los nodos dentro de una transacción distribuida completan la transacción en la misma manera que el commit point site. En el caso de transacciones distribuidas, la base de datos seleccionada como commit point site debe ser la base de datos que almacena los datos más críticos, ya que esta base de datos nunca entra en el estado de preparación (prepared) y por lo tanto nunca puede generar transacciones en estados dudoso, incluso si se produce un fallo. Este factor es importante, ya que debermos recordar que en situaciones de error, los nodos afectados permanecen en un estado preparado, bloqueando los registros en vuelo hasta la resolución de la transacciones en duda. El mecanismo de commit en dos fases de Oracle tiene las siguientes fases ue la base de datos realiza automáticamente cada vez que un usuario realiza un commit de una transacción distribuida: Prepare phase : El TM solicita a los nodos participantes que no sean el commit point site que confirmar (commit) o deshacer la transacción, incluso si se produce un fallo. Si un nodo no puede ejecutar esta fase de preparación, la transacción se deshace en esta fase. Commit phase: Si todos los participantes responden al TM que están preparados, éste solicita al commit point site la realización del commit. Después de que el commit point site finalice, el TM pide a todos los demás nodos la confirmación la transacción. Pág. 14 / 26

15 Forget phase: El TM se olvida de la transacción. En Oracle cada transacción confirmada tiene un número de cambio de sistema asociado (SCN) para identificar los cambios realizados por las sentencias SQL dentro de cada transacción. Oracle utiliza el SCN para mantener la coherencia de lectura para las consultas. Como cada base de datos tiene su propio SCN que se mantiene de forma independiente, existe la situación de que una base de datos pueda estar fuera de fecha con respecto a las otras bases de datos dentro de la transacción distribuida. Para minimizar el impacto de esta situación, los SCN en una transacción distribuida se sincronizan al final de cada sentencia SQL remota y al principio y al final de cada transacción. Debido a esta diferencia de SCNs, una consulta puede ser ejecutada sobre una versión de los datos o snapshot mas antigua, perdiendo la visibilidad de los cambios mas recientes de la base de datos remota. En base a la consistencia de lectura, una consulta SQL se puede recuperar de manera consistente pero con datos obsoletos o fuera de fecha. Hay que tener en cuenta que todos los datos recuperados por la consulta SQL será de un SCN antiguo, por lo que si una transación ejecutada en local actualizada dos tablas en una base de datos remota, y posteriormente selecciona datos desde estas mismas tablas, no optendrá los valores actualizados. La sincronicación de SCN es necesaria para consultas SQL donde, a modo de workaround se ejecuta una consulta de tipo dummy, por ejemplo, select * from dual@remotesite. If SCN synchronization is required for specific queries then a common workaround is to precede each remote query with a dummy remote query to the same site, for example, SELECT * FROM DUAL@REMOTE. Uno de los beneficios de la coordinación y la sincronización de SCN es que la recuperación incompleta de todas las bases de datos a un solo SCN o transacción es posible. Esto permite la coherencia transaccional se mantenga incluso cuando sólo una de las bases de datos pueda recuperarse parcialmente, por ejemplo, debido a un desastre. Sin embargo, hay que tener en cuenta que este tipo de recuperaciones incompletas suponen pérdida de datos en las bases de datos a menos que exista un mecanismo de terceros para reproducir todas las transacciones que faltan. Para simular diferentes escenarios de fallo dentro de una transacción distribuida, recomendamos la revisión de la Nota# Manually Resolving In-Doubt Transactions: Different Scenarios. Pág. 15 / 26

16 Uso de XA con Oracle Database Timeouts XA y Oracle Database Hay un número consierable de timeout o de tiempos de espera que se utilizam en implementaciones XA. El objetivo principal de estos timeouts son evitar problemas de bloqueo entre las fases prepare y commit. Por ejemplo si un TM se cuelga o muere después de la etapa de prepare, la RM tiene que ser capaz de liberar los bloqueos para otras operaciones que no son manejadas por TM fallido. La regla de oro para estos tiempos de espera es que las utilizadas por el RM debe ser mayor que los utilizados por la TM, de tal manera que la TM siempre permanece en el control de la transacción distribuida. Por ejemplo, si los tiempos de espera del RM son menos de los tiempos de espera de la TM, el RM puede descartar una transacción sin control por parte del TM. Un resultado común en este tipo de casos es una respuesta de tipo ORA-24756: Transacción no existe". Igualmente dentro de la implementación de Oracle XA hay una serie de tiempos de espera que se utilizan para determinar fallos dentro de una transacción distribuida. Dos de estos tiempos de espera se pasan por el TM a Oracle al abrir una conexión utilizando el método del API xa_open, estos son: SesTm (SessionTimeout) especifica el tiempo máximo que una transacción puede estar inactiva antes de que se cancele de forma automática por el sistema. Por ejemplo, si el TM utiliza una llamada a procedimiento remoto entre el cliente y el servidor, se aplica el valor de SesTM al tiempo entre la finalización de una llamada y el inicio de la siguiente, o al proceso de confirmación o rollback; SesWt (sessionwait) especifica el límite máximo de tiempo de espera un branch de una transación que está siendo utilizado por una sesión. El valor predeterminado es de 60 segundos. Tanto el SesTM como el SesWt se encuentran en los archivos de configuración específicos TM a través de la cadena de conexión de base de datos. SesTM es obligatoria, mientras que SesWt a menudo se deja a su valor predeterminado. Una cadena de conexión de ejemplo es el siguiente: ORACLE_XA+SQLNET=SID3+ACC=P/user/pwd+SesTM+=10+LogDir=/usr/local/XAlog Los tiempos de espera SesTM y SesWT no se aplican a las transacciones XA gestionados a través de una conexión JDBC. En este caso se utiliza el método settransactiontimeout lugar. Del mismo modo, para PL/SQL, a partir de Oracle Database 11gR1, la función XA_SETTIMEOUT dentro del paquete DBMS_XA se puede utilizar para establecer el tiempo de espera de transacción. El valor predeterminado es de 60 segundos. Además, existen otro timeout o tiempos de espera que deben tenerse en cuenta, estos son: Pág. 16 / 26

17 global transaction timeout del TM, que en caso de servidores de aplicaciones basados en Java EE es el tiempo de espera de JTA. El parámetro DISTRIBUTED_LOCK_TIMEOUT de Oracle RDBMS, que limita el timpo que las transacciones distribuidas esperarán por bloqueo; Los parametros CONNECT_TIME y IDLE_TIME como parte del PROFILE asiganado al usuario/esquema. Por defecto, ambos parámetros tienen el valor de ILIMITADO para el perfil DEFAULT. Por lo general, estos tiempos de espera deben establecerse en el siguiente orden: 1. Global transaction timeout del TM o el tiempo de espera JTA < 2. SesTmandSesWt, TransactionTimeout para JDBC o PL/SQL < 3. DISTRIBUTED_LOCK_TIMEOUT < 4. Cualquiera de los parámetros CONNECT_TIME o IDLE_TIME Hay que tener en cuenta que si los tiempos de espera se agotan dentro de Oracle RDBMS, el PMON eliminará la rama de transacción si no está preparada o forzará a que la transacción se convierta en un transacción en duda en el caso de que si esté preparada. El PMON se activa cada 60 segundos, por lo que puede haber una demora de hasta 60 segundos antes de que la sesión cambie de estado después de la expiración del timeout. Es decir, hay que sumar al valor del parámetro SesTm otro 60 segundos más en el peor de los casos. Si el timeout se cumple se convierte en un transacción dudosa o en duda, aparecerá en el vista DBA_2PC_PENDING y en la vista DBA_PENDING_TRANSACTIONS. Estas transacciones dudosas provocarán que cualquier acceso a los datos afectados por la transacción fallen con el error ORA lock held by in-doubt distributed transaction <tran id>. La mayoría de los casos, la transacción dudosa se recupera automáticamente una vez que el TM se puede comunicar con el RM. La resolución manual sólo debe ser necesaria cuando la transacción dudosa tenga bloqueos sobre datos críticos, recursos o exista un fallo en a máquina, la red o el software. En este caso, recuperación manual, la operación puede terminar con la aplicación de una heurística, que su vez puede necesitar la intervención nuevamente de forma manual. Alternativamente, si el DISTRIBUTED_LOCK_TIMEOUT se establece a un valor excesivamente bajo, las transacciones pueden agotar el timeout esperando a otras sesiones. En ese caso, puede generarse un Esto puede resultar en un ORA timeout: distributed transaction waiting for lock. Transacciones distribuidas y la gestión de bloqueos Todas las transacciones distribuidas fuertemente acoplados adquieren un enqueue de tipo DX mientras están trabajando con la transacción. Este enqueue se utiliza para serializar el acceso a la base de datos a través de múltiples ramas de una transacción distribuida, de forma que sólo una rama de la transacción puede tener SQL activa en cualquier momento en el tiempo. Pág. 17 / 26

18 Dentro de una misma base de datos de ejemplo, todas las transacciones distribuidas están estrechamente unidas por defecto. El gestor de transacciones XA puede anular esta situación en el inicio de cualquier de las transacciones distribuidas que ejecuta. Del mismo modo dentro, de un entorno de múltiples instancias RAC todas las transacciones distribuidas están estrechamente unidas por defecto. Sin embargo antes de Oracle Database 11gR, los enqueues DX se mantienen de forma independiente por cada instancia. Desde Oracle Database 11gR1 esto ha cambiado y todo el clúster es consciente de los enqueues DX de cada transacción distribuida fuertemente acoplada del clúster. Estos enqueues DX de tipo cluster-wide son administrados por el Global Enqueue Service (GES) de Oracle RAC, de forma que el control de cada transacción se transfiere entre las instancias de base de datos cuando las transacciones distribuidas abarcan más de una. Sin embargo, sólo una rama dela transacción fuertemente acoplada puede estar activa en un momento dado. Otro de los cambios asociados a los enqueues DX y Oracle RAC, es que el nuevo mecanismo de coherencia de lectura de permite que todos los cambios pre-commit se realicen en una rama de transacción de una transacción acoplada y que sean visibles por otras ramas de la misma transacción. Antes de 11gR1, los cambios realizados en una instancia no eran visibles a las ramas situadas en otra de las instancias. Las transacciones distribuidas debilmente o nada acopladas son independientes entre sí y no adquieren un enqueue DX y por tanto no es necesario serializar su actividad transaccional en diferentes ramas de transacción. El uso de varias ramas dentro de unas transacciones distribuidas obliga a que todas las ramas de transacción realicen una confirmación en dos fases, es decir, el sistema no se puede utilizar una única fase como optimización XA cuando éstas se ejecutan en la misma base de datos. En general, Oracle mantiene la coherencia de lectura basándose en el SCN cuando se inicia la instrucción de lectura. De forma que sólo los cambios que se confirmaron (commit) antes de que se ejecutara la instrucción de lectura se incluirán en el conjunto de resultados devuelto. Sin embargo, hay una excepción cuando se trata de transacciones distribuidas, donde el lector puede ser bloqueado y puede producirse bloqueos a nivel de bloque entre las fases prepare y commit. Antes de 10gR2, las transacciones distribuidas gestionadas externamente a Oracle usaban una estrategia de bloqueo a nivel de bloque de forma que las posibles sesiones con operaciones de lectura sobre ese bloque quedaban tambien bloqueadas entre las etapas prepare y commit. De esta forma, por ejemplo las sesiones que deseaban leer no podían ver los datos antes ni después hasta que se confirman los cambios. Desde 10gR2 y en adelante, este comportamiento se ha modificado de tal manera que las transacciones distribuidas generan bloqueos a nivel de fila y no bloquean al resto de sesiones que desean leeer entre el prepare y el commit. Este comportamiento se encuentra disponible en las versiones anteriores a través del parche , que se incorpora en los patchset y Sin embargo, para las transacciones distribuidas controladas por Oracle no hay cambio en la funcionalidad, la sessión que desea leer se bloquea a nivel de bloque y se adquieren entre el prepare y commit. Esto se debe a que dentro de una transacción distribuida controlada por Oracle el cambio pueden tener un commit SCN menor que el actual SCN del sistema, y por tanto no se sabe si una transacción preparada debe ser visible o no para otras sesiones que están leyendo. Con Pág. 18 / 26

19 transacciones distribuidas controlado por Oracle, todas las bases de datos que participan en la transacción se coordinarán de manera que se alinean sus SCN durante la fase de confirmación o commit. Tanto las transaciones XA controladas externamente como las controladas por Oracle que modifique filas que han sido alteradas por otra transacción deberán esperar hasta que se complete la operación. Lo ideal sería que la operación de bloqueo se completará con éxito antes de que se agote el tiempo establecido como timeout ya sea por el timeout del TM bien por el timeout DISTRIBUTED_LOCK_TIMEOUT a nivel de base de datos. Si la transacción se marca como dudosa, el resto de operaciones que estaban a la espera recibierán un error del tipo "ORA lock held by in-doubt distributed transaction <tranid>". Si la operación que bloquea tiene una duración más larga que el valor de DISTRIBUTED_LOCK_TIMEOUT de la base de datos se puede producir una situación de interbloqueo y las transacciones distribuidas, controladas o no por Oracle, fallarán con un error de tipo "ORA-02049: timeout: distributed transaction waiting for lock ". Si el orden de la configuración de los diferentes timeout es correcta, no debería producirse nunca este error ya que el tiempo de espera del TM debe superarse siempre antes de que se alcance el tiempo de espera del DISTRIBUTED_LOCK_TIMEOUT. Cuando una rama de una transacción distribuida falla entre la fase prepare y la fase del commit, se marca como dudosa hasta que sea resuelta por el coordinador de la transacción. En este caso, todas las filas modificadas por la transacción fallida serán bloqueadas hasta que sea resulta satisfactoriamente. Todas las transacciónes que intenten acceder a dichos datos recibirán un error del tipo ORA lock held by in-doubt distributed transaction <tran id >. Cualquier aplicación que use transacciones distribuidas tiene que estar diseñada para evitar en la medida de lo posible las contenciones tanto a nivel de fila como de bloque. La latencia inherente a la ejecución de las fases de prepare y commit sobre la ejecución en una única fase puede significar una degración del rendimiento si estas transacciones tiene que compartir filas o índices entre ellas. Transacciones distribuidas y la optimización Read-Only Antes de Oracle Real Application Cluster 11gR1, la optimización de sólo lectura de las transacciones distribuidas sólo se realizaba a nivel de instancia de base de datos dentro de un mismo RAC. Si una transacción distribuida utiliza más de una instancia de base de datos RAC, entonces sólo lectura optimización no se usaba. A partir de 11gR1, la optimización de sólo lectura de las transacciones distribuidas puede ocurrir cuando una transacción distribuida utilice más de una instancia de la base de datos RAC. Transacciones distribuidas y la información de REDO Tanto las transacciones distribuidas controladas por Oracle escriben un registro de REDO durante la fase de preparación y un registro de REDO durante la fase de confirmación o commit. En 11gR1, un registro adicional se escribe en la etapa de preparación en el caso de haya dos o mas instancias de bases de datos que participan en la misma transacción distribuida. El REDO generado durante la fase de preparación es un registro REDO interno y no es visible a través de Oracle Log Miner. Por tanto, en el caso de recuperación incompleta de una base de datos con Pág. 19 / 26

20 estos registros de REDO puede dar lugar a transacciones que se marquen como dudosas. Gestión de transacciones distribuidas en Oracle Database La Oracle Database permite el acceso a la siguiente información sobre las transacciones distribuidas desde el punto de vista de base de datos: Información sobre las transacciones distribuidas sin resolver, es decir en prepared y en espera de commit/rollback, está disponible a través de la vista del sistema DBA_PENDING_TRANSACTIONS. Informationon transacciones distribuidas a la espera de recuperación, por ejemplo, transacciones dudosas, está disponible a través de la vista del sistema DBA_2PC_PENDING. Información sobre las transacciones distribuidas en estado activo está disponible a través de la vista del sistema V$GLOBAL_TRANSACTION. Información sobre las conexiones entrantes y salientes en espera de transacciones dentro de una transacción distribuida gestionada por Oracle está disponible a través de la vista del sistema DBA_2PC_NEIGHBORS. A las transacciones dudosas se puede les puede hacer commit o rollback a traves de su identificador, tran_id, manualmente si el TM ya no es capaz de recuperar dicha transacción. Siempre que sea posible el TM, debe intentar recuperar la transacción distribuida para evitar que finalmente se termine de form heurística ya que puede provocar resultados diferentes en cada uno de los RM que participan en la transacción. En cuanto a las transacciones distribuidas ya finalizadas, puede ser eliminadas manualmente usando el sugiente paquete y método PL/SQL. EXECUTE DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY ('<tran_id>'), Para mas detalles sobre el funcionamiento y requisitos de este método se recomienda consultar la nota# How to Purge a Distributed Transaction from a Database. Pág. 20 / 26

21 Uso de XA y Oracle Real Application Clusters (RAC) Oracle Real Application Cluster tiene una serie de restricciones y mejores prácticas respecto al uso de transacciónes distribuidas XA que se detallan a continuación: Antes de 11gR1, toda la rama de transacción debe realizarse en la misma instancia de base de datos. En caso de failover a otra instancia, se aplican condiciones especiales dependiendo de la versión de RAC se despliega. Antes de 11gR1, una transacción XA no conectarse usando load balancing a cualquier de las instancias. La especificación XA permite que una rama de una transacción sea suspendida y vuelta a reanudar por la TM. En el caso de uso de load balancing, cualquiera de las conexiones puede reanudar una rama de transacción que no se inició en esa instancia dando lugar a problemas anteriormente descritos y asociados a lo no propagación de las transacciones distribuidas a través de todas las instancias del cluster. Desde 11gR1, esta restricción se elimina por defecto, sin embargo, siguen existiendo algunas implicaciones de rendimiento si una sola transacción distribuida abarca varias instancias de base de datos. No hay seguridad de que en caso de failover se garantice la unicidad global de la transacción (XID) dentro de Oracle RAC. Oracle RAC no puede comprobar que el XID dado es único entre todas las instancias dentro del clúster. Hay que tener en cuenta que el TM necesita mantener la unicidad global de la XID en todo momento, y que la especificación XA describe que el RM, este caso Oracle RAC, siempre debe aceptar los XID proporcionados desde el TM. Antes de 11gR1, para evitar la posibilidad de que las transacciones fuertemente acoplada no vieran cambios realizados por las demás sesiones, todas las ramas de transacción de una transacción distribuida fuertemente acoplada deben estar ubicados en la misma instancia. Asimismo se recomendó, aunque no es obligatorio, localizar todas las transacciones con acoplamiento debil en la misma instancia de base de datos, para evitar diferentes resultados de varias ramas de transacción dentro de la misma transacción distribuida. Desde 11gR1, se eliminan estas restricciones, siendo posible que todas las transacciones distribuidas sean fuertemente acopladas o no, se ejecuten sin restricciones. Como en el caso anterior, existen implicacionees de rendimiento si una sola transacción abarca varias instancias de bases de datos distribuidas. Consideración aparte tiene las conexiones que en caso de error y usando failover conmuten a una instancia distinta dentro del clúster en caso de que la primera instancia se pierda. Si el TM intenta obtener el estado de las transacciones globales de una instancia diferente puede obtener la información incorrecta sobre el dichas transacciones debido a que no todos los segmentos de REDO de la instancia fallida han sido recuperados o que alguna de las transacciones de la instancia fallida hayan caducado. En este caso, si un TM pide al estado de una rama de transacción distribuida desde una instancia diferente a la que se inició, lo más probable es que la respuesta devuelta sea un error del tipo "ORA-24756: Transaction does not exist. Oracle Database versión 9.0 y anteriores Para las versiones de bases de datos Oracle 9.0 y anteriores, la conexión XA debe abrirse con el parámetro OPS_FAILOVER = T en el momento de la llamada xa_open. Pág. 21 / 26