Source: http://docplayer.es/2437241-Solucion-de-conflictos-durante-la-sincronizacion-de-datos-en-la-aduana.html
Timestamp: 2018-01-19 06:26:55+00:00

Document:
SOLUCIÓN DE CONFLICTOS DURANTE LA SINCRONIZACIÓN DE DATOS EN LA ADUANA - PDF
SOLUCIÓN DE CONFLICTOS DURANTE LA SINCRONIZACIÓN DE DATOS EN LA ADUANA
Download "SOLUCIÓN DE CONFLICTOS DURANTE LA SINCRONIZACIÓN DE DATOS EN LA ADUANA"
Antonio Castellanos Carrizo
1 SOLUCIÓN DE CONFLICTOS DURANTE LA SINCRONIZACIÓN DE DATOS EN LA ADUANA CONFLICTS SOLUTION DURING DATA SYNCHRONIZATION IN THE CUSTOM Ing. Fernando Nápoles Gamez 1, Ing. Bernardo Corrales Armbuster 1 1 Universidad de las Ciencias Informáticas, Cuba. Carretera a San Antonio de los Baños, Km 2 ½, La Lisa, Ciudad de La Habana, Cuba La Habana, Octubre, 2013
2 RESUMEN El presente trabajo está encaminado a la solución de conflictos durante la sincronización de las bases de datos para el Sistema de Gestión Integral de Aduanas (GINA) utilizando como sistema de gestión de bases de datos Oracle 11g. Al efectuarse el intercambio de información entre las bases de datos de los servidores, se produce el registro de información múltiple perteneciente a un mismo elemento, provocando redundancia, inconsistencia y pérdida de los datos, expresándose en la ocurrencia de conflictos en los registros almacenados. Para resolver el problema se identifican los tipos de conflictos que ocurren, y se propone un mecanismo automático de resolución de los mismos teniendo en cuenta dos tipos de nodos: central y secundario. Palabras Clave: Base de datos, inconsistencia, mecanismo automático, redundancia, resolución de conflictos, sincronización. ABSTRACT This paper provides a conflicts resolution while the synchronization of the databases for the Integrated Management System of Customs (GINA), using as a databases management system Oracle 11g. When the exchange of information between databases servers is made, multiple information belonging to the same element are registered, causing redundancy, inconsistency and loss of data, expressed in the occurrence of conflicts in the stored records. To solve the problem, the types of conflicts are identified; and an automatic mechanism for resolving them is proposed, considering two types of nodes: central and secondary. Keywords: Database, conflicts resolution, inconsistency, redundancy, synchronization.
3 1. INTRODUCCIÓN La Aduana General de la República (AGR) es una organización destinada a supervisar el tráfico internacional de medios de transportes, mercancías y viajeros. Como parte de los programas de informatización, la AGR ha venido desarrollando, apoyada por el Centro de Automatización para la Información y la Dirección (CADI) y con la colaboración de la Universidad de las Ciencias Informáticas, el Sistema de Gestión Integral de Aduanas (GINA). Este sistema cuenta con servidores de base de datos que requieren sincronizar sus datos. El despliegue se efectúa como se observa en el esquema de la red nacional de la Aduana General de la República, Fig. 1. Fig. 1. Esquema de la red nacional de la Aduana General de la República. En la concepción del sistema GINA, que debe funcionar como un sistema integral para la gestión de todos los procesos de una aduana, se determinó que toda la información se debe almacenar en una base de datos única. Como resultado del proceso de despliegue de las nuevas soluciones informáticas y la descentralización de la información para alcanzar mayor disponibilidad y seguridad de la información, el sistema se concibe además como un sistema distribuido con la presencia de un servidor central que funciona como puente entre los demás servidores y se encarga de manejar la información de estos, y que en situaciones excepcionales debe funcionar de manera que un nodo desconectado del servidor central debe ser capaz de continuar prestando servicios en forma autónoma y registrar las operaciones que se vayan realizando para posteriormente actualizar el servidor central y luego por réplica a todos los servidores de respaldo y los restantes que forman el sistema distribuido y que manejan información común. 1
4 Esto introduce una problemática al registrarse elementos nuevos en las operaciones como personas o medios de transporte. Si el elemento nuevo registra operaciones en el servidor local de una aduana que está funcionando desconectada y antes que ese servidor se reconecte también dicho elemento registra operaciones en otros nodos que estén conectados directamente o desconectados en el momento que todos los nodos se activen es necesario homogeneizar toda la información referente al elemento nuevo bajo un único identificador y con la precedencia entre las operaciones que ha realizado contra la aduana como entidad única. También puede ocurrir que un elemento nuevo se registre en subsistemas diferentes que tienen intereses diferentes con respecto al concepto nuevo e igualmente en el momento que se vuelvan a conectar los nodos es necesario que el servidor central quede registrado un único elemento que contenga todas las informaciones provenientes de todos los subsistemas donde se insertó. Se ha identificado que pueden ocurrir conflictos en la información que se almacena entre los servidores de la red nacional de la Aduana General de la República, el servidor central y los servidores secundarios, debido a que no existe el correcto tratamiento de la información durante sincronización entre dichos servidores. Se necesita por tanto resolver estos conflictos en la información, garantizando la consistencia de los datos. 2. MATERIAL Y MÉTODO 2.1 Entorno de réplica. Existen dos entornos clásicos de réplica de datos: Maestro-Esclavo: También es conocido como de solo lectura, porque permite a un solo sitio (maestro) realizar consultas de escritura sobre los demás, mientras estos solo pueden hacer consultas de lectura (esclavos) Maestro-Maestro: También llamado par-a-par o réplica de camino de n, porque permite múltiples sitios (maestros), actuando como pares iguales. Cada sitio es un sitio maestro, y se comunica con otros sitios maestros. 2
5 Dada las características del entorno descrito por la Aduana, estamos en el caso de un entorno Maestro-Maestro, pues aunque se tiene un servidor central y varios secundarios, en todos es posible modificar o insertar información. Además la presencia de conflictos solo es propia en un entorno de este tipo, ya que en un ambiente Maestroesclavo, al ser de solo lectura, no existen conflictos Tipos de replicación Los tipos de replicación están relacionados con el momento en que se realiza la actualización de los datos cuando se efectúa una transacción de escritura en la base de datos. Replicación Asíncrona: En el caso de la replicación asíncrona, las actualizaciones a una réplica son propagadas hacia los demás en algún momento posterior, no dentro de la misma transacción, por lo tanto la replicación asíncrona presenta un retardo de tiempo o latencia, durante el cual es posible que las réplicas no sean idénticas. Replicación Síncrona: En el caso de la replicación síncrona, si se actualiza una réplica dada, todas las demás réplicas del mismo fragmento de datos también se actualizan dentro de la misma transacción; lo que implica que (desde un punto de vista lógico) solo existe una versión de los datos. La replicación asíncrona se ajusta a las características de la situación. 2.2 Tipos de conflictos presentes: TIPO 1: conflicto de elementos con igual concepto: Se refiere a la existencia de dos elementos cuya identificación es la misma según el concepto que representan para el subsistema, pero que poseen en sus respectivos registros o tuplas, valores diferentes dentro del dominio de los atributos que los describen. TIPO 2: conflicto de elementos en distintos subsistemas: Se refiere a la presencia de dos elementos que representan el mismo concepto global en la base de datos, pero que son tratados por diferentes subsistemas según sus propios conceptos. De esta forma se almacena información diversa en cada subsistema relacionada al elemento, pero bajo diferentes identificadores, de tal forma no es posible asociar correctamente toda la información del elemento a través de las restricciones de integridad referencial. 3
6 3. Caso de estudio Para la mejor comprensión se propone el siguiente caso de estudio, que simula la situación real del entorno de réplica. Nodo # 1: Servidor Central Aduana General de la República Nodo # 2: Servidor Aeropuerto Internacional José Martí Nodo # 3: Servidor Aeropuerto Internacional de Varadero De esta forma se propone desarrollar un mecanismo en lenguaje PL/SQL, que se introduciría en cada nodo que forma el entorno con la particularidad de que se predefine comportamientos distintos en correspondencia del tipo de nodo donde se encuentre, si es nodo central o si es nodo secundario. 3.1 Estrategia general para la identificación unívoca de elementos. Determinar qué entidades o tablas de la base de datos están involucradas en el proceso de réplica. Detectar la ocurrencia de un conflicto de unicidad o de integridad referencial en las tablas antes determinadas. Capturar los datos relacionados con la tupla o registro que provocó el conflicto de violación, incluyendo la tabla o entidad a la que pertenece. Capturar el nombre de la restricción establecida en la base de datos que fue violentada y los atributos asociados a esta, los cuales conforman la clave única, primaria, o foránea de la tabla. Guardar los datos capturados como metadatos para su posterior utilización. Conflictos que se pueden presentar. Clasificación. Los conflictos de unicidad que tienen lugar en la situación que nos ocupa los podemos agrupar en casos según sus características. Estos son: 4
7 Caso 1: Identificador igual, elementos iguales conceptualmente. En este caso se parte de la identificación de los elementos a través de los atributos que puedan definir la existencia única de los mismos, a través de una clave única, siendo clave natural. El conflicto ocurre al poseer dos registros los mismos valores de clave única o los mismos valores de clave primaria, entiéndase por esta última la clave definida en la tabla a través de una secuencia lo que representa una clave subrogada. Al confirmarse la semejanza de estos registros se procede a comparar la similitud de los restantes campos y determinar las diferencias entre ambos, para efectuar la solución de estos en correspondencia con las diferencias encontradas. Caso 2: Identificador igual, elementos distintos conceptualmente. Sucede al poseer los dos registros en conflicto, de distintos valores en la clave única, los mismos valores de clave primaria, lo que representa en nuestra situación una clave subrogada por medio del establecimiento de una secuencia. Al tener el mismo valor de clave primaria se presenta un conflicto. En esta situación se puede resolver creando un nuevo elemento donde se le asigne un nuevo identificador al último elemento insertado. Caso 3: Identificador distinto, elementos iguales conceptualmente. En este caso se necesita aplicar la forma de identificación de cada elemento a través de los atributos que puedan determinar la existencia única de esos elementos, a través de una clave única, siendo clave natural. El conflicto ocurre al poseer dos registros los mismos valores de clave única y distintos valores de clave primaria, entiéndase por esta última la clave definida en la tabla a través de una secuencia lo que representa una clave subrogada. Una vez identificados los elementos se puede proceder a comparar la similitud de los restantes campos y determinar las diferencias entre ambos, para efectuar la solución de los mismos en correspondencia con las diferencias encontradas. 5
8 3.2 Formas de solución de conflictos. Para poder aplicar los criterios de resolución de conflictos se elaborarán un conjunto de reglas que permitan dar solución a los conflictos principales. Anteriormente se ha explicado que los conflictos presentes en la situación se identifican como parte de los conflictos de unicidad, puesto que parten de la necesidad de identificar a un elemento unívocamente y lo que se relaciona directamente con los términos de violación de las restricciones de integridad, ya sea por clave única o clave foránea. Para garantizar que no se den conflictos de unicidad clásicos, se implementará una de las soluciones que se proponen para ello. En este caso establecer un rango distinto a las secuencias por cada servidor o nodo. Rangos para cada nodo: Nodo Central Aduana General de la República (id: nodo1) Valor de inicio de la secuencia: 1 Valor de incremento: 5 Primeros 10 números: 1, 6, 11, 16, 21, 26, 31, 36, 41, 46 Nodo Aeropuerto Internacional José Martí (id: nodo2) Valor de inicio de la secuencia: 2 Valor de incremento: 5 Primeros 10 números: 2, 7, 12, 17, 22, 27, 32, 37, 42, 47 Nodo Aeropuerto Internacional Varadero (id: nodo3) Valor de inicio de la secuencia: 3 Valor de incremento: 5 Primeros 10 números: 3, 8, 13, 18, 23, 28, 33, 38, 43, 48 Es válido resaltar que este rango de números está limitado para una cantidad menor o igual a 10 nodos, si es necesario ponerlo en práctica en una mayor cantidad de nodos 6
9 sería necesario cambiar el valor de incremento de la secuencia por 10. De esta forma el rango es mayor. 3.3 Criterios de resolución de un conflicto. De forma general se han identificado criterios de detección de un conflicto. Estos son: Determinar si los dos elementos son iguales según el concepto que representan, en ese momento se identifica la ocurrencia de un conflicto. Determinar el tipo de conflicto que se presenta Conocer el nodo donde ocurre el conflicto Establecer comportamientos para cada tipo de nodo: central y secundario. Detección de las diferencias de claves primarias de los elementos. Conocer la diferencia de todos los atributos referentes a cada elemento. 3.4 Reglas de resolución de conflictos. Se considera que las reglas a implementar deben ser las siguientes, cumpliendo con una condición y permitiendo realizar alguna acción o tomar una decisión. 1. Si poseen el mismo identificador y no se trata del mismo elemento, asignarle un nuevo identificador al último elemento recibido e insertarlo como un nuevo elemento. 2. Si poseen el mismo identificador y tratarse del mismo elemento, verificar las diferencias entre los atributos de ambos elementos. 3. Si son iguales los atributos de esos elementos, se mantiene el elemento local y se desecha el remoto. 4. Si son distintos los atributos, en el caso de los nodos secundarios, se actualizan los pertenecientes al elemento local con las diferencias que poseía el elemento remoto, exceptuando en este proceso los campos nulos del remoto, garantizando de esta forma que siempre se tenga en los nodos secundarios la información identificada por el central como correcta y se mantengan los datos que el nodo central no posee. 7
10 5. Si son distintos los atributos, en el caso del servidor central, se actualizan los campos nulos del elemento local con los datos del elemento remoto, garantizando así que los datos del servidor central no sean sobre escritos o eliminados y se tenga presente los datos que el local no posea y el remoto sí. 6. Si posee distinto identificador, y no se trata del mismo elemento, se mantiene el elemento local intacto y se inserta el elemento remoto. 7. Si posee distinto identificador y se trata del mismo elemento, se verifican las diferencias entre los atributos. 8. Si son iguales los atributos de esos elementos, en el caso de los servidores secundarios se inserta el elemento con sus datos dado que son iguales, y con el nuevo identificador procedente del servidor central, se modifican los valores en los campos de clave foránea en las tablas que tienen relación con la afectada para asociar al elemento con nuevo identificador la información que estaba relacionada al anterior. Por último se elimina el elemento que posee el valor de identificador modificado. 9. Si son iguales los atributos de esos elementos, en el caso del servidor central, se mantiene el elemento local y se desecha el remoto. 10. Si son distintos los atributos, en el caso de los servidores o nodos secundarios, se inserta un nuevo elemento con el identificador del elemento remoto y con una mezcla de la información común y las diferencias que poseía este último con respecto al local, exceptuando en este proceso los campos nulos del remoto, garantizando de esta forma que siempre se tenga en los nodos secundarios la información identificada por el central como correcta y se incorporen los datos que el nodo central no posee. Posteriormente se modifican los valores en los campos de clave foránea en las tablas que tienen relación con la afectada para asociar al elemento con nuevo identificador la información que estaba relacionada al anterior. Por último se elimina el elemento que posee el valor de identificador local. 8
11 11. Si son distintos los atributos, en el caso del servidor central, se actualizan los campos nulos del elemento local con los datos del elemento remoto, cuando el local posee campos nulos, garantizando así que los datos del servidor central no sean sobre escritos o eliminados y se tenga presente los datos que el local no posea y el remoto sí. Posteriormente se modifican los valores en los campos de clave foránea, en las tablas que tienen relación con la afectada, modificando en todas las ocurrencias el valor del identificador perteneciente al registro remoto por el valor del identificador del registro local, para asociar así al elemento local la información que estaba relacionada al elemento remoto. 3.5 Unificación de la información referente a un elemento. Como se demuestra en la definición de las reglas anteriores, por lo general en el caso de que un elemento no sea el correcto o se tenga una versión del mismo que deba ser tenida en cuenta, se actualiza su identificador y con ello los datos que lo caracterizan o se inserta un nuevo elemento con toda la información. Como esos datos son relevantes en la tupla de la tabla a la que pertenece, y en cualquier otro lugar donde se utilicen son enlazados por el identificador de dicha tupla como clave foránea, entonces se necesita primero obtener la jerarquía de las tablas para luego de insertar el elemento con el nuevo identificador, actualizar seguidamente con este nuevo valor de identificador todos los valores en los campos que conformen las claves foráneas de las tablas que tengas relación con ella y que apuntan a esta clave primaria, así toda la información referente al elemento con el anterior identificador quedará relacionada con este pero a través del nuevo identificador. Como la opción on_update_cascade no está habilitada para las claves foráneas desde las primarias en Oracle, por lo que no es posible modificar primero el valor de la clave primaria y luego por cascada los de las claves foráneas relacionados a esta, y además no es posible modificar un valor de clave primaria siempre que este tenga asociado dependencias, es necesario actualizar los valores de las claves foráneas que apuntan a una clave primaria partiendo de los niveles más bajos en la jerarquía de las tablas, desde las tablas hijas hasta las tablas padres. Sería 9
12 necesario entonces hacer un recorrido en árbol de la jerarquía de las tablas y realizar estas modificaciones de forma recursiva. Ejemplo 1: Solución de conflicto TIPO 2: elementos en distintos subsistemas. CASO: 3 Nodo Secundario. Registro de la tabla persona del esquema PERSONA en la base de datos del nodo central: ID_PERS TRATAMIENT PRIMER_NOMBE SEGUNDO_NOMB PRIMER_APELLI SEGUNDO_APELLI TIP ONA O RE DO DO O 1 NULL Yasser Antonio Romero Pineiro 1 Registro de la tabla persona del esquema PERSONA en la base de datos del nodo secundario: ID_PERS TRATAMIENT PRIMER_NOM SEGUNDO_NOMB PRIMER_APELLIDO SEGUNDO_APELLI TIP ONA O BE RE DO O 10 NULL Yasser Antonio Romero Pineiro 1 Registro de la tabla lcf_persona_vinculada del esquema LCF en la base de datos del nodo secundario ID_RESULTADO_CONTROL ID_PERSONA 5 10 En este caso en el nodo secundario se tiene una información asociada a la persona que posee como ID_PERSONA el valor 10. Ejecutando lo antes explicado, se detectaría que la persona es la misma y como la tupla que se recibe en el nodo secundario proviene el nodo central se debería actualizar el identificador de la persona, asignado el valor 1 a ID_PERSONA, en lugar de 10 en la tupla del nodo secundario. Pero para poder efectuar esto, es necesario primero insertar el elemento en la tabla PERSONA con el nuevo valor de identificador en el campo ID_PERSONA y luego actualizar este valor en los hijos de la tabla en cuestión. Al 10
13 realizar esta operación se actualizan todas las ocurrencias de ID_PERSONA, que se encuentra como clave foránea en las tablas que tienen relación con la tabla PERSONA donde estaba el valor 10, se asigna el valor 1. Así queda la información relacionada a la persona 10, vinculada ahora a la misma persona pero con otro identificador, el 1. Se evalúa si existe diferencia en los restantes campos y al no suceder se mantienen con los datos intactos. Estado de las tuplas luego de efectuar la operación: Registro de la tabla persona del esquema PERSONA en la base de datos del nodo secundario: ID_PERSO TRATAMIENT PRIMER_NOMB SEGUNDO_NOM PRIMER_APELLI SEGUNDO_APELLI TIPO NA O E BRE DO DO 1 NULL Yasser Antonio Romero Pineiro 1 Registro de la tabla lcf_persona_vinculada en la base de datos del nodo secundario ID_RESULTADO_CONTROL ID_PERSONA 5 1 Nodo Central Si esta situación se diera en el nodo central, se mantiene intacto el elemento local, pues solo son diferentes los identificadores y al tener prioridad la información del nodo central se mantiene el identificador de este. De todas formas es necesario asociar la información que arriba relacionada con el elemento de identificador 10 al elemento con identificador 1. Para ello, la tupla perteneciente al elemento remoto de la tabla lcf_persona_vinculada que hace referencia al elemento persona con identificador 10, al arribar provoca un conflicto de clave foránea pues esa persona no existe en la base de datos, de esa manera se almacena como un conflicto de este tipo, guardando los datos asociados en las tablas temporales. Luego cuando al resolver el conflicto de unicidad donde se actualiza el valor de las claves foráneas con el nuevo valor del identificador en todas las tablas hijas, se 11
14 actualizan igualmente esos valores en las tablas temporales pertenecientes a la correspondiente tabla hija donde está almacenado el registro conflictivo, modificando así el valor 10 por el 1 en el campo ID_PERSONA. Posteriormente esos registros ya con el identificador del elemento local 1 son recuperados e insertados en las tablas originales a las que pertenecen. Así puede recuperar la información de un elemento que llegue al nodo central, si los identificadores son distintos. Ejemplo 2: Solución del conflicto Tipo 1: conflicto de elementos con igual concepto. Caso 1. Nodo Secundario Registro de la tabla persona del esquema PERSONA en la base de datos del nodo central: ID_PERSO TRATAMIENT PRIMER_NOMB SEGUNDO_NOM PRIMER_APELLI SEGUNDO_APELLID TIPO NA O E BRE DO O 1 null Yasser Antonio Romero Pineiro 1 Registro de la tabla persona del esquema PERSONA en la base de datos del nodo secundario: ID_PERSO TRATAMIENT PRIMER_NOMB SEGUNDO_NOM PRIMER_APELLI SEGUNDO_APELLID TIPO NA O E BRE DO O 1 especial Yasser Antonio Romero Pineiro 2 En este caso en el nodo secundario tiene la misma persona que posee como ID_PERSONA el valor 1. Ejecutando lo antes explicado, se detectaría que la persona es la misma y como el identificador de la persona es el mismo no se modifica. Se evalúa la existencia de diferencias entre los valores de los restantes campos, y al detectarse alguna, según la prioridad establecida para el servidor central, se procede a actualizar los campos al elemento local con las diferencias que poseía el elemento remoto, exceptuando en este proceso los campos nulos del remoto, garantizando de 12
15 esta forma que siempre se tenga en los nodos secundarios la información identificada por el central como correcta y se mantengan los datos que el nodo central no posee. Estado de las tuplas luego de efectuar la operación: Registro de la tabla persona del esquema PERSONA en la base de datos del nodo secundario: ID_PERSONA TRATAMIENT PRIMER_NOMB SEGUNDO_NOMBRE PRIMER_APELLIDO SEGUNDO_APELLID TIPO O E O 1 especial Yasser Antonio Romero Pineiro 1 En caso de que lo anterior sucediera en el nodo central el resultado sería el mismo pues se actualizarían en la tupla del elemento local, solo los campos que posean valor nulo, garantizando se almacene la información del elemento remoto que el local no posea. Existen otras modificaciones como la suma de valores, pero ya son configuraciones concretas que van más allá de establecer una prioridad. 4. Estructura del mecanismo El mecanismo se diseña como una solución automática de detección y resolución de los conflictos identificados y tipificados. Está pensado para que sea independiente de la forma de réplica que se utilice, siempre que se tenga en cuenta que el punto de partida radica en la ocurrencia de errores de unicidad y de claves foráneas en primera instancia. El mecanismo está concebido en tres componentes esenciales. El primero de ellos es un trigger que se encarga de chequear las tablas involucradas ante la ocurrencia de un conflicto y detectarlo, además de capturar y almacenar los datos necesarios en las estructuras creadas para ese fin. El segundo componente es un paquete de funciones con sus procedimientos y su funcionalidad principal de resolver los conflictos detectados. El tercer componente es una tarea programada o job el cual se encarga de 13
16 activar la función principal que ejecuta a su vez los procedimientos necesarios a través la resolución automática de los conflictos. Fig. 2. Estructura propuesta para el mecanismo. Integración con el entorno de réplica: El mecanismo deberá desplegarse en cada servidor, donde su comportamiento dependerá del tipo de nodo en el que se ubique, dígase nodo central o secundario. Fig. 3. Integración del mecanismo en el entorno existente. 5. Resultado y discusión El punto de partida del mecanismo es la detección de errores en las tablas, pero es necesario conocer cuáles son las tablas involucradas en la réplica. Para garantizar el funcionamiento del mecanismo es necesario se tenga una tabla de control donde se especifiquen las tablas que estarán bajo este proceso de réplica. Es importante que el nombre de estas tablas tenga incluido el nombre del esquema de tal forma que esté compuesto por [nombre_esquema.nombre_tabla], para de esta forma 14
17 garantizar se conozca la ubicación exacta de la tabla y no haya confusiones si existe esta en varios esquemas. Además se podrá acceder indistintamente a la información de un elemento que se encuentre en varios subsistemas. Así esta información es aprovechada por el mecanismo con el objetivo de alcanzar el mayor dinamismo y transparencia necesarios. Se debe especificar el nombre de esta tabla de control que contenga la información. Estructuras necesarias para el funcionamiento del mecanismo Primeramente se crean tablas temporales correspondientes a cada una de las tablas sobre las cuales el mecanismo trabajará en la detección de los conflictos. Estas tablas poseen la misma estructura que las tablas originales con el objetivo de poder almacenar en ellas el mismo tipo de información que estas. Además se le agrega una columna id_error donde se almacenará el valor de una secuencia que identificará de manera única un conflicto en la base de datos. El nombre de estas tablas seguirá el siguiente estándar: Estándar de nombre de tablas temporales: Nombre de las tablas: [NOMBRE_TABLA]_T Con el objetivo de efectuar la creación de estas tablas temporales de forma dinámica se creó un procedimiento almacenado nombrado tables_to_replicate. Este procedimiento es ejecutado cada vez sea llamado el mecanismo pues es posible que entre una ejecución y otra del mismo se haya agregado otra tabla como objeto de replicación y por tanto el mecanismo debe incorporarla a sus objetos de chequeo dinámicamente. Tablas de Control. Metadatos. Cada una de las siguientes tablas hace posible el funcionamiento del mecanismo, pues en ellas se almacenan de forma automática datos y metadatos (datos de los datos) imprescindibles y críticos para realizar la tarea de detección y posterior resolución de los conflictos. Estas constituyen las fuentes o destinos de muchas funcionalidades que se encuentran enlazadas dentro del mecanismo, las cuales serán enunciadas más adelante en este capítulo. Estas tablas son creadas por el procedimiento create_tables. Las tablas son las siguientes: 15
18 Nombre de la tabla: ORAERROR Descripción Cuadro 1: Descripción tabla ORAERROR Almacena el identificador de un conflicto así como datos necesarios asociados a él Atributo Tipo Descripción id_error number(20) Identificador del conflicto table_name varchar2(40) Nombre de la tabla donde ocurre el conflicto log_date timestamp(6) Momento en que sucede el conflicto log_usr varchar2(30) Usuario que realiza la operación error_n number(10) Número de error según Oracle error_msg varchar2(100) Mensaje del error sql_text varchar2(100) SQL de la operación que se realizó. constraint_voliated Varchar2(40) Nombre de la restricción violada Cuadro 2: Descripción tabla LOG_GENERIC_CONFLICT Nombre de la tabla: LOG_GENERIC_CONFLICT Descripción Almacena las tuplas remotas que han provocado un conflicto Atributo Tipo Descripción id_conflict number(20) Identificador del conflicto conflict_record xmltype Registro remoto que provocó el conflicto Cuadro 3: Descripción tabla ORIGINAL_RECORD Nombre de la tabla: ORIGINAL_RECORD Descripción Almacena las tuplas locales que han provocado un conflicto Atributo Tipo Descripción id_conflict number(20) Identificador del conflicto original_record xmltype Registro local que provocó el conflicto Cuadro 4: Descripción tabla TABLE_PARENTS Nombre de la tabla: TABLE_PARENTS Descripción Almacena la relación de todas las tablas hijas, presentes en el esquema y relacionadas con el mecanismo, con sus respectivas tablas padres. Atributo Tipo Descripción nombre_tabla varchar2(40) Nombre de una tabla hija tabla_padre varchar2(40) Nombre de la tabla padre 16
19 Cuadro 5: Descripción tabla CONSTRAINTS_COL_TEMP Nombre de la tabla: CONSTRAINTS_COL_TEMP Descripción Almacena el nombre de las columnas que conforman cada una de las restricciones o claves de una tabla, así como el tipo de restricción: primaria, única, foránea. Atributo Tipo Descripción campo varchar2(40) Nombre de la columna nombre_constraint varchar2(3) Nombre de la restricción tipo_constraint varchar2(40) Tipo de restricción (P,U,R) nombre_tabla varchar2(40) Nombre de la tabla Detección, captura y almacenamiento de un conflicto. Al ocurrir una violación de unicidad Oracle lanza el error conocido por Ora o 1, y en el caso de una violación de integridad referencial lanza el error Ora Por eso la detección, captura y almacenamiento de un conflicto de este tipo es realizado por un trigger nombrado AFTER_ERROR y que se activa al ocurrir un error en la base de datos filtrando el tipo de error de unicidad o de integridad referencial. En él se chequean solo las tablas que se relacionan con el proceso de réplica. Cuadro 6: Descripción trigger AFTER_ERROR Nombre del trigger : AFTER_ERROR Descripción Detección, captura y almacenamiento de un conflicto de unicidad. Momento EVENTO SOBRE OBJETO after servererror on database El resultado del trigger almacena los datos de la tupla remota que provocó el error en la tabla temporal asociada a la tabla original donde ocurrió el conflicto, además guarda el identificador del conflicto como id_error. Al mismo tiempo almacena información importante del conflicto en la tabla ORAERROR como el identificador, tabla donde sucede, instante, usuario, numero de error según la clasificación de Oracle, el mensaje de error, la sentencia sql que se ejecutó y el nombre de la clave o restricción que se violó. Estos datos se consultan posteriormente. Resolución de un conflicto La resolución de conflictos que se implementa es un mecanismo automático y dinámico en PL/SQL que se ejecuta según el tiempo deseado en la base datos. Esto es posible 17
20 mediante una tarea programada o job que ejecuta el procedimiento principal del mecanismo para resolver los conflictos anteriormente detectados y almacenados. Este procedimiento principal es nombrado handle_conflict y es el encargado de manejar todo lo relacionado con la resolución de los conflictos. En su interior son ejecutados a su vez los distintos procedimientos que conforman el paquete util_package en el orden en el que son necesarios, teniendo como procedimiento principal el solve_conflict, donde se resuelven los conflictos. Conforman el paquete util_package los siguientes procedimientos: Cuadro 7: Descripción principales funciones y procedimientos del paquete util_package. Nombre del procedimiento Descripción find_constraints_column_proc Obtiene el nombre de las claves y su tipo(r, P, U) por cada tabla, los campos que pertenecen a cada una de las claves y el nombre de la tabla a la que están asociadas. get_conflicts_x_table Obtiene los conflictos sucedidos en una tabla determinada. get_error_record Obtiene el registro remoto que provocó un conflicto dado get_all_columns Obtiene el nombre las columnas pertenecientes a una tabla específica get_conflict_orignal_record Obtiene el registro local que provocó un conflicto dado get_constraint_table Dado el nombre de una clave obtiene los campos que la forman. solve_conflict Dado un conflicto, y los registros involucrados resuelve el conflicto. recursive_cascade Actualiza recursivamente las ocurrencias de un valor de clave primaria en las claves foráneas de las tablas hijas. El procedimiento handle_conflict selecciona todos los conflictos ocurridos luego de su última ejecución, resolviendo cada uno de ellos, no sin antes clasificarlos y tener en cuenta el tipo de nodo en el que es ejecutado (central o secundario). Los primeros procedimientos que son ejecutados son los que garantizan se almacenen los datos necesarios en las tablas de control creadas, estos serán ejecutados cada vez sea llamado el procedimiento principal, porque los datos y metadatos que se manejan pueden cambiar en el intervalo de las distintas ejecuciones del mismo. 18
Replicación de Datos en SQL Server... 3. Resumen... 3. 1. Introducción... 3. 2. Componentes del modelo de replicación... 3
REPLICACIÓN DE DATOS EN SQL SERVER CONTENIDO Replicación de Datos en SQL Server... 3 Resumen... 3 1. Introducción... 3 2. Componentes del modelo de replicación... 3 3. Escenarios típicos de la replicación...
Opciones de replicación y distribución de datos en Oracle RDBMS 9iR2, 10gR2 y 11gR1
Oficina Técnica para la Gestión y Supervisión de Servicios TIC Subdirección de Tecnologías de la Información Opciones de replicación y distribución de datos en Oracle RDBMS 9iR2, 10gR2 y 11gR1 Referencia
Arquitectura de sistema de alta disponibilidad
Mysql Introducción MySQL Cluster esta diseñado para tener una arquitectura distribuida de nodos sin punto único de fallo. MySQL Cluster consiste en 3 tipos de nodos: 1. Nodos de almacenamiento, son los
Sistema para el control y tramitación de documentos SITA MSc. María de la Caridad Robledo Gómez y Ernesto García Fernández.
Sistema para el control y tramitación de documentos SITA MSc. María de la Caridad Robledo Gómez y Ernesto García Fernández. CITMATEL Ave 47 e/18 A y 20, Playa, Ciudad de La habana, CP 10300 Cuba. E mail:
Arturo Cepeda Pérez. Software Engineering Tutor
Software Engineering Tutor M A N U A L D E U S U A R I O Tabla de contenidos 1. Software Engineering Tutor... 1 2. Entorno... 2 2.1. Vista Modelo... 3 2.2. Vista Diagrama... 4 2.3. Vista Propiedades...
COMPUTACIÓN DE ALTA PERFORMANCE 2011 1 TOLERANCIA A FALLOS COMPUTACIÓN DE ALTA PERFORMANCE Curso 2011 Sergio Nesmachnow (sergion@fing.edu.uy) Santiago Iturriaga (siturria@fing.edu.uy) Gerardo Ares (gares@fing.edu.uy)
El Manejador de Bases de Datos Relacionales ORACLE
El Manejador de Bases de Datos Relacionales ORACLE Como la segunda empresa vendedora de software a nivel mundial, ORACLE provee una plataforma completa para desarrollar aplicaciones que utilicen el recurso
Bases de Datos Distribuidas Sistemas de Bases de Datos Distribuidas Un Sistema de Bases de Datos Distribuidas (SBDD) es un conjunto de sitios (servidores) débilmente acoplados y que no comparten componentes
CURSO DE ADO EXPRESS/DATASNAP
CURSO DE ADO EXPRESS/DATASNAP EN DELPHI 7 RESUMEN DE EJERCICIOS Serie A 0 Creación de la base de datos 1 El API de ADO 2 Cadenas de conexión y propiedades 3 Tipos de cursores 4 Recuperación asíncrona 5
75:10 Técnicas de Diseño Trabajo práctico Documento de Arquitectura Simulador de Carreras Grupo 6: Integrantes: Anaya, Roxana Maribel 82875 maribel.anaya@gmail.com Esteban Alejandro Czelada 79992 gauchomouse@gmail.com
IWG-101: Introducción a la Ingeniería Departamento de Informática, UTFSM 1 Gestión de Bases de Datos Gestión de Bases de Datos Base de datos una colección de datos relacionados organizados de manera de
de a M. -Tastets Universidad de Concepción,Chile www.inf.udec.cl\ andrea andrea@udec.cl II Semestre - 2007 y del s: Sistemas de y del s: de y del s: Objetivos de la Unidad Dar a conocer las características,
Ingeniería del Software I Clase de Testing Funcional 2do. Cuatrimestre de 2007
Enunciado Se desea efectuar el testing funcional de un programa que ejecuta transferencias entre cuentas bancarias. El programa recibe como parámetros la cuenta de origen, la de cuenta de destino y el
RESOLUCIÓN No. 178 /2008
RESOLUCIÓN No. 178 /2008 POR CUANTO: El Decreto Ley No. 204 de fecha 11 de enero del 2000, cambió la denominación del Ministerio de Comunicaciones por la de Ministerio de la Informática y las Comunicaciones,
Buenas Prácticas en Bases de Datos. María del Pilar Angeles. Posgrado de la Facultad de Ingeniería, UNAM. mpilar_angeles@exalumno.unam.
Buenas Prácticas en Bases de Datos María del Pilar Angeles. Posgrado de la Facultad de Ingeniería, UNAM. mpilar_angeles@exalumno.unam.mx Algunos Tópicos de Base de Datos Modelado y Diseño Programación
Arquitectura Básica CÍCLOPE CMS
Arquitectura Básica CÍCLOPE CMS Introducción. Arquitectura Colaborativa. El diseño de la arquitectura documental de CÍCLOPE CMS permite crear y administrar documentos electrónicos y mantenerlos disponibles
Inn2 Tecnologías Ltda.
Manual de uso: ECLIPSE DASQLs Conectividad de OPC DA a SQL Server Versión 1.4 Inn2 Tecnologías Web: www.inn2.cl Mail: info@inn2.cl 2009 - Inn2 Tecnologías Eclipse DASQLs V. 1.4 mail: info@inn2.cl 1 1.-
Guías técnicas Grupo Danysoft: InterBase para programadores Delphi
Guías técnicas Grupo Danysoft: InterBase para programadores Delphi Por Pablo Reyes Equipo Grupo Danysoft febrero de 2002 - (902) 123146 www.danysoft.com Este documento se ha realizado utilizando Doc-To-Help,
Práctica 2. Academia Bristol
Práctica 2. Academia Bristol Se desea tener una base de datos con la siguiente información acerca de los alumnos de una academia de idiomas donde se imparten varios cursos: Información acerca de los alumnos,
TESTING DE SISTEMAS DATA GUARD PARA ENTORNOS ORACLE. Oficina de Calidad Subdirección de Tecnologías de la Información
Oficina de Calidad Subdirección de Tecnologías de la Información TESTING DE SISTEMAS PARA ENTORNOS ORACLE DATA GUARD Referencia documento: InfV5_JASAS_DG_SystemTest_V310.doc Fecha: 12 de enero de 2012
Arquitectura de Proyectos de IT Apunte: Introducción a MQ y conceptos de mensajería Autores: Patricio Echagüe patricioe@gmail.com Ing. Gastón Escobar gescobar@gmail.com Versión: 0.1 Octubre, 2005 1 Índice
CENTRO INTEGRAL DE GESTIÓN DEL TRANSPORTE COLECTIVO DEL CONSORCIO REGIONAL DE TRANSPORTES DE MADRID
CENTRO INTEGRAL DE GESTIÓN DEL TRANSPORTE COLECTIVO DEL CONSORCIO REGIONAL DE TRANSPORTES DE MADRID Autores de la comunicación J. Dionisio González Ingeniero de Caminos, Canales y Puertos. Responsable
Fecha de efectividad: 2014-2 PLAN DE CLAVE NOMBRE DE LA ASIGNATURA CARRERA ESTUDIO ASIGNATURA L.S.C. 2009-2 12001 Administración de Base de Datos. PRÁCTICA LABORATORIO Administración de Base de Datos DURACIÓN
LABORATORIO 8. Optimización de Consultas SQL a través de herramientas del SMBD Oracle
LABORATORIO 8. Optimización de Consultas SQL a través de herramientas del SMBD Oracle GUÍA DE LABORATORIO Nº 8 Actividad de Proyecto No. 10: desarrollar mantenimiento preventivo, correctivo o proactivo
SISTEMAS DE GESTIÓN DE BASE DE DATOS SGBD / DBMS
Universidad de Carabobo Facultad Experimental de Ciencias y Tecnología Departamento de Computación Unidad Académica Base de Datos SISTEMAS DE GESTIÓN DE BASE DE DATOS SGBD / DBMS Integrantes: Fidel Gil

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 Resolución 
 resolución 
 resolución 

RESOLUCIÓN 

RESOLUCIÓN