Source: http://docplayer.es/2437120-Tecnicas-avanzadas-para-gestion-de-sistemas-de-informacion-tarea-obligatoria-sobre-tecnologias-para-sistemas-de-informacion.html
Timestamp: 2017-09-21 03:52:26+00:00

Document:
Técnicas Avanzadas para Gestión de Sistemas de Información. Tarea obligatoria sobre: Tecnologías para Sistemas de Información - PDF
Download "Técnicas Avanzadas para Gestión de Sistemas de Información. Tarea obligatoria sobre: Tecnologías para Sistemas de Información"
Inés Sevilla Medina
1 Instituto de Computación Facultad de Ingeniería Universidad de la República Oriental del Uruguay Técnicas Avanzadas para Gestión de Sistemas de Información Carrera de Ingeniería en Computación Edición 2003 Tarea obligatoria sobre: Tecnologías para Sistemas de Información Título Estudiantes Replicación en Oracle 9i Helena Rivas Martín Varela Javier Frank Iang Yim Docente encargado: Dr. Ing. Hermann Steffen 1
2 7$*6, 7UDEDMR2EOLJDWRULR Técnicas de replicación de datos en Oracle 9 Integrantes: Helena Rivas Iang Yim Martín Varela Javier Frank
3 ,QWURGXFFLyQBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB Organización del documento 3 &RQFHSWRV JHQHUDOHV BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB Aplicaciones Que Usan replicación 4 Objetos, Grupos y Sitios Replicables 4 Tipos de ambientes de Replicación 5 Conflictos de Replicación 9 Otras opciones para la replicación Multimaster 9 5HSOLFDFLyQ PDHVWUD BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB Conceptos de replicación maestra 10 Proceso de replicación multimaestro 12 Conceptos sobre resolución de Conflictos 14 Arquitectura de la replicación Multimaster 15 9LVWDV 0DWHULDOL]DGDV BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB Por que usar vistas materializadas? 19 Vistas materializadas en múltiples capas 19 Arquitectura 21 &RQIOLFWRV BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB Tipos de conflictos 23 Detección de conflictos 23 Resolución de Conflictos 23 Multitier Materializaed Views 24 Técnicas para evitar conflictos 24 Arquitectura de resolución de conflictos 25 Resolución de conflictos de unicidad 26 &RQFOXVLyQ BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
4 ,QWURGXFFLyQ Replicación es el proceso de copiado y mantenimiento de objetos de la base de datos, tales como tablas, en bases de datos múltiples simulan un sistema de bases de datos distribuido. Los cambios hechos en un sitio son capturados y almacenados localmente antes de ser enviados y aplicados en cada una de las locaciones remotas. La replicación en Oracle es una característica del servidor Oracle, no es un servidor separado. La Replicación utiliza tecnología de bases de datos distribuidas para compartir datos entre múltiples sitios, pero una base de datos replicada y una base de datos distribuida no son lo mismo. En una DB distribuida, los datos están disponibles en muchas locaciones, pero en una tabla en particular reside solo en una locación. Por ejemplo, la tabla de empleados reside solo en la DB ny.world en un sistema de base de datos distribuido, el que también incluye las DB hk.world y la.world. Replicación significa que el mismo dato esta disponible en múltiples locaciones. Por ejemplo, la tabla empleados esta disponible en ny.world, hk.world, y la.world. Algunas razones para utilizar replicación son: Disponibilidad La replicación mejora la disponibilidad de las aplicaciones, ya que provee opciones alternativas de acceso a los datos. Si un sitio no se encuentra disponible, entonces los usuarios pueden continuar con si consulta o aun actualizando las locaciones restantes. En otras palabras la replicación provee una excelente protección contra fallas. Performance La replicación provee un rápido, acceso local a datos compartidos ya que balancea la actividad sobre múltiples sitios. Algunos usuarios pueden acceder a un servidor mientras que otros acceden a diferentes servidores, reduciendo la carga de todos los servidores. También, los usuarios pueden acceder a datos de un sitio replicado que tiene un menos costo de acceso, típicamente un sitio que se encuentra geográficamente más cerca de ellos. Computación Desconectada Una vista materializada (materialized view) es una copia (replica) completa o parcial de una tabla objetivo en un determinado momento. Materialized views habilitan a los usuarios a trabajar sobre un subconjunto de la DB mientras están desconectados del servidor de DB central. Mas tarde, cuando se establezca una conexión, los usuarios pueden sincronizar (refresh) las materializad views a demanda. Cuando los usuarios refrescan las vistas materializadas, pueden actualizar la DB central con todos los cambios que hayan hecho, a su vez recibirán los cambios que puedan haber ocurrido mientras estaban desconectados. Reducción de la carga La replicación puede ser utilizada para distribuir datos sobre locaciones en múltiples regiones. Así, las aplicaciones pueden acceder a varios servidores regionales en vez de acceder a un servidor central. Esta configuración puede reducir la carga de la red dramáticamente. Despliegue en masa Cada vez mas, las organizaciones necesitan desarrollar algunas aplicaciones que requieren de la capacidad de usar y manipular datos. Con Oracle Replication, deployment templates habilitan a uno a crear multiples ambientes de materialized views rapidamente. Se pueden utilizar variables para hacer a gusto cada ambiente de materialized view según sus necesidades. Por ejemplo, uno puede utilizar deployment templates para sales force automation. en este caso, el template puede contener variables para varias regiones de ventas y vendedores. Organización del documento En lo que sigue del documento se trataran conceptos básicos de la replicación en Oracle. En la primera sección se verán los distintos objetos y ambientes de replicación. La segunda sección trata la replicación maestra.las vistas materializadas,conceptos y sus arquitecturas, son tratadas en la tercera sección
5 y por último en la cuarta sección se verán los conflictos y posibles soluciones a estos para distintos ambientes de replicación. &RQFHSWRV JHQHUDOHV Aplicaciones Que Usan replicación Replicación soporta una variedad de aplicaciones que a menudo tiene diferentes requerimientos.algunas aplicaciones permiten sitios de vistas materializadas relativamente autónomos. Por ejemplo, automatización de ventas, servicio de campo, venta al por menor, y otras aplicaciones de despliegue de masa típicamente requiere datos para ser periódicamente sincronizados entre el sistema central de base de datos y un gran numero de sitios pequeños, remotos, los cuales a menudo son desconectados desde la base de datos central. En ese caso, los sitios remotos deben ser autónomos. Por otra parte, aplicaciones tales cono centros de llamadas y sistemas de Internet requieren datos en múltiples servidores para ser sincronizados de manera continua, casi instantánea para asegurarse que el servicio que se provee está disponible y equivalente en todo momento. Por ejemplo, un sitio web de ventas al por menor en Internet debe asegurarse que los clientes vean la misma información en el catálogo online en cada sitio. Aquí, la consistencia de datos es más importante que la autonomía del sitio. Replicación en Oracle puede ser usada para cada tipo de aplicaciones descriptas en los párrafos anteriores, y para sistemas que combinen aspectos de ambos tipos de aplicaciones. De hecho, la replicación en Oracle puede soportar ambos, despliegues de masa y replicación servidor- a- servidor, habilitando la integración en un ambiente único y coherente. En tal ambiente, por ejemplo, la automatización de ventas y servicio de centro de llamadas de clientes, pueden compartir datos. Replicación Oracle puede replicar datos en ambientes que usen diferentes versiones de Oracle y en ambientes que corran Oracle en diferentes sistemas operativos. Por lo tanto, aplicaciones que usen datos en tales ambientes pueden usar replicación Oracle. Objetos, Grupos y Sitios Replicables Las siguientes secciones explican los componentes básicos de un sistema de replicación, incluyendo objetos, grupos y sitios de replicación. Objetos Replicables Un objeto replicable es un objeto de una base de datos existente en múltiples servidores en un sistema de base de datos distribuido. En un ambiente de replicación, cualquier actualización hecha a un objeto replicable en un sitio es aplicada a las copias en todos los otros sitios. Replicación Oracle permite replicar los siguientes tipos de objetos: Tablas Índices Vistas y Object Views Packages y Packages Bodies Procedimientos y Funciones Tipos definidos por el usuario y Type Bodies Triggers Sinónimos Indextypes Operadores definidos por el usuario En cuanto a tablas, replicación soporta avanzadas características tales como tablas particionadas, tablas organizadas por índices, tablas conteniendo columnas que se basan en tipos definidos por el usuario, y tablas objetos. Grupos Replicables En un ambiente de replicación, Oracle maneja objetos replicables usando grupos replicables. Un grupo replicable es una colección de objetos replicables que están relacionados lógicamente.
6 Organizando objetos de bases de datos relacionadas dentro de un grupo replicable, es más fácil administrar muchos objetos juntos. típicamente, se crea y usa un grupo replicable para organizar el esquema de objetos necesarios para soportar una aplicación de base de datos particular. Sin embargo, grupos replicables y esquemas no necesitan corresponder uno con otro. Un grupo replicable pueden contener objetos de múltiples esquemas, y un esquema singular puede tener objetos en múltiples grupos replicables. Sin embargo, cada objeto replicable puede ser miembro sólo de un grupo replicable. Sitios Replicables Un grupo replicable puede existir en múltiples sitios replicables. Ambientes de replicación soportan dos tipos básicos de sitios: sitios maestros y sitios de vistas materializadas. Un sitios puede ser tanto un sitio maestro para un grupo replicable y un sitio de vistas materializadas para otro grupo replicable diferente. Sin embargo, un sitio no puede ser a la vez master site y materialized view site de un mismo grupo replicable. Las diferencias entre master sites y materializad view sites son las siguientes: Un grupo replicable en un master site es referido más específicamente como un master group. Un grupo replicable en un materializad view site está basado en un master group y es referido más específicamente como un materializad view group. Adicionalmente, cada master group tiene exactamente un master definition site. Un master definition site de un grupo de replicación es un master site sirviendo como el centro de control para manejo de grupos de replicación y objetos en el grupo. Un master site mantiene una copia completa de todos los objetos en un grupo de replicación, mientras que las vistas materializadas en un materializad view site pueden contener todos o un subconjunto de la tabla de datos dentro de un master group. Por ejemplo, si el hr_repg master group contiene las tablas empleados y departamentos, entonces todos los master sites participando en el master group deben mantener una copia completa de empleados y departamentos. Sin embargo, una vista de un materializad view site debería contener solo una vista materializada de la tabla de empleados, mientras que otra materialized view site debería contener vistas materializadas de ambas tablas, de empleados y departamentos. Todos los master sites en un ambiente de replicación multimaster se comunican directamente con uno y otro para propagar continuamente los cambios de datos en el grupo de replicación. Materialized view sites contienen una imagen, o vista materializada, de la tabla de datos desde un cierto punto en el tiempo. Típicamente, una vista materializada es actualizada periódicamente para sincronizarla con su master site. Usted puede organizar vistas materializadas en refresh groups. Vistas materializadas en un refresh group pueden pertenecer a uno o más grupos de vistas materializadas, y ellas son actualizadas al mismo tiempo para asegurar que los datos en todas las vistas materializadas en el refresh group correspondan al mismo transaccionalmente consistente punto de tiempo. Tipos de ambientes de Replicación Replicación Oracle soporta los siguientes tipos de ambientes de replicación: Replicación Multimaster Replicación de Vistas Materializadas. Configuraciones híbridas Multimaster y Vistas Materializadas. Replicación Multimaster Replicación Multimaster (también llamada peer-to-peer o n-way replication) permite sitios múltiples, actuando como pares iguales, para dirigir grupos de objetos de base de datos replicables. Cada sitio en un ambiente de replicación multimaster es un master site, y cada sitio se comunica con los otros master sites. Las aplicaciones pueden actualizar cualquier tabla replicada en cualquier sitio en una configuración multimaster. Los servidores de base de datos Oracle operando como master sites en un ambiente multimaster automáticamente trabajan para converger (reunir) los datos de todas las replicas de tablas y para asegurar la consistencia global de la transacción y la integridad de los datos. Replicación asincrónica es el medio más común para implementar la replicación multimaster. Otros medios incluyen replicación sincrónica y procedural, las cuales son discutidas después en este capítulo. Cuando usted usa replicación asincrónica, la información acerca de un lenguaje de manipulación de datos (DML) cambia en una tabla es guardado en la cola (queue) de transacciones diferidas en el master site donde el cambio ocurrió. Estos cambios son llamados Transacciones diferidas. Las transacciones diferidas son
7 empujadas o propagadas hacia el otro master site participante en intervalos regulares. Puede controlar la cantidad de tiempo en un intervalo. Usar replicación asincrónica significa que los son posibles conflictos de datos, porque la misma fila de valor puede ser actualizada en dos master sites diferentes casi al mismo tiempo. Sin embargo, usted puede usar técnicas para evitar conflictos y, si el conflicto ocurre, Oracle provee mecanismos preconstruidos que pueden ser implementados para resolverlos. La información sobre los conflictos sin resolver es almacenada en un Log de error. Master Group Quiesce A veces, es posible parar toda la actividad de replicación de un master group para poder ejecutar ciertas tareas administrativas en el master group. Por ejemplo, si se debe parar toda la actividad de replicación de un master group para agregar un nuevo objeto master group. Parar toda la actividad de replicación de un master group es llamado quiescing el grupo. Cuando un master group es quiesced, los usuarios no pueden dar DML declaraciones de ninguno de los objetos en el master group. También, todas las transacciones diferidas deben ser propagadas antes de que pueda quiesce un master group. Los usuarios pueden continuar consultando las tablas en un quiesced master group. Replicación de vistas materializadas Un materializad view contiene una copia completa o parcial de un target master desde un punto singular en el tiempo. El target master puede ser a la vez una tabla master en un master site o un master materializad view en un materializad view site. Un master materializad view es un materializad view que funciona como un master para otro materializad view. Un multitier materializad view es uno que está basado en otro materializad view, en lugar de una tabla master. Materializad view provee los siguientes beneficios: Permite accesos locales, lo cual mejora los tiempos de respuesta y la disponibilidad. Offload queries del master site o del master materialized view site, porque en su lugar los usuarios pueden preguntar el materialized view local. Incrementa la seguridad de los datos permitiéndole a usted replicar solo un subset seleccionado del target master s data set. Un materialized view puede ser solo para lectura, updatable, o writeable, y esos tipos de materialized views proveen beneficios en suma de aquellos enumerados previamente. Vistas materializadas de solo lectura En una configuración básica, las vistas materializadas pueden proveer acceso de solo lectura a la tabla de datos que se originan desde un master site o master materialized view site. Las aplicaciones pueden consultar datos de vistas materializadas de solo lectura para evitar accesos al master site a través de la red, prescindiendo de la disponibilidad de la red. Sin embargo, las aplicaciones a lo largo de todo el sistema deben acceder a datos en el master site para ejecutar sentencias DML. Las master tables y master materialized view de solo lectura no necesitan pertenecer a un grupo de replicación. Read-only materialized views proveen los siguientes beneficios: Eliminan la posibilidad de conflictos porque no pueden ser actualizados. Soportan materialized views complejas. Ejemplos de materialized views complejas son materialized views que contienen set de operaciones o una cláusula CONNECT BY. Vistas materializadas actualizables En una configuración más avanzada, puede crear un updatable materialized view que permita a los usuarios insertar, actualizar, y borrar filas de las tablas del master objetivo o master materialized view ejecutando estas operaciones en el materialized view. Un updatable materialized view puede también contener un subset de los datos en el target master. Updatable materialized views están basados en tablas o en otros materialized views que han sido establecidos para soportar la replicación. De hecho, updatable materialized views deben ser parte de un materialized view group que este basado en otro grupo de replicación. Updatable materialized views tiene las siguientes propiedades. Están siempre basados en una tabla singular, aunque tablas múltiples pueden ser referenciadas en un subquery.
8 Pueden ser actualizados de forma incrementada o rápida. Oracle propaga los cambios hechos a un updatable materialized view a una tabla remote master o master materialized view del materialized view. Las actualizaciones al master entonces cascada a otros sitios de replicación. Updatable materialized views proveen los siguientes beneficios: Permiten a los usuarios consultar y actualizar un set de datos local replicado aun cuando está desconectado del master site o del master materialized view site. Requiere menos recursos que una replicación multimaster, mientras todavía soporta la actualización de datos. Materialized views pueden ser actualizadas según la demanda, mientras que la replicación multimaster propaga los cambios a intervalos regulares. Además, debido a que los materialized views pueden residir en una base de datos que contienen menos información, el espacio del disco y los requerimientos de la memoria para los clientes de materialized view pueden ser menores que los requerimientos para un servidor Oracle que contenga master sites. Vistas materializadas writeable Se puede crear un materialized view usando la cláusula FOR UPDATE durante la creación pero luego nunca agregar el materialized view a un materialized view group. En ese caso, los usuarios pueden ejecutar las sentencias de manipulación de datos (DML) en el materialized view, pero esos cambios no pueden ser propagados al master y se pierden si el materialized view es actualizado. Tales materialized views son llamados writeable materialized views. Subconjuntos de Filas y Columnas con vistas materializadas Ambos, subconjuntos de filas y columnas habilitan a crear materialized views que contienen una copia parcial de los datos en una master table o master materialized view. Tales materialized views pueden ser útiles para oficinas regionales o fuerzas de ventas que no requieran el set completo de datos. Row subsetting permite incluir solo las filas que sean necesarias de los masters en los materialized views usando una cláusula WHERE. Las columnas subsetting permiten incluir solo las columnas que sean necesarias de los masters en los materialized views. Usted hace esto especificando columnas particulares en el planteo SELECT durante la creación del materialized view. Actualización de vistas materializadas Para asegurarse que un materialized view es consistente con su tabla master o master materialized view, se necesita actualizar periódicamente el materialized view. Oracle provee los siguientes tres métodos para actualizar los materialized views: Fast Refresh que utiliza materialized view logs para actualizar solo las filas que han cambiado desde la ultima actualización. Complete refresh que actualiza todo el materialized view. Force refresh ejecuta una actualización rápido cuando es posible. Cuando una rápida actualización no es posible, force refresh ejecuta una actualización completa (Complete refresh) Refresh Groups Cuando es importante para los materialized views ser transaccionalmente consistentes con los otros, usted puede organizarlos en grupos actualizados (Refresh groups). Actualizando el refresh group, usted se puede asegurar que los datos en todos los materialized views en el refresh group corresponden al mismo transaccionalmente consistente punto de tiempo. Ambos, read-only y updatable materialized views, pueden ser incluidos en un refresh group. Un materialized view en un refresh group aun puede ser actualizado individualmente, pero haciendo eso anula los beneficios de el refresh group, porque actualizando el materialized view individualmente no actualiza otros materialized views en el refresh group. Registro de vistas materializadas Un Materialized View Log es una tabla en el master site o master materialized view site del materialized view que guarda todo los cambios de DML al master table o master materialized view. Un Materialized View Log es asociado con un simple master table o master materialized view, y cada uno de esos
9 tiene solo un materialized view log, prescindiendo de cuantos materialized views refresh del master. Un fast refresh de un materialized view es posible solo si el master del materialized view tiene un materialized view log. Cuando un materialized view es fast refresh, entradas en associated materialized view log del materialized view que han aparecido desde la última vez que el materialized view fue actualizado son aplicadas al materialized view. Despliegue de Patrones Plantillas de Despliegue simplifica la tarea de desplegar y mantener muchos materialized view sites remotos. Usando deployment templates, se puede definir una colección de materialized view definitions en un master site, y puede usar parámetros en las definiciones para que el materialized view pueda ser habituado para usuarios individuales o tipos de usuarios. Cuando el usuario instancia un patrón, los materialized views son creados y multiplicados en el sitio remoto. Los valores del parámetro pueden ser a la vez suplidos por los usuarios remotos o tomados desde una tabla mantenida en un master site. Online and Offline Instantiation Cuando un usuario instancia un patrón en un materialized view site, el objeto DDL (por ejemplo, CREATE MATERIALIZED VIEW O CREATE TABLE declaración) es ejecutado para crear el esquema de objetos en un materialized view site, y los objetos son multiplicados con los datos apropiados. Los usuarios pueden instanciar patrones mientras están conectados al master site (online instantiation), o mientras están desconectados desde un master site (offline instantiation). La instanciación offline es usada a menudo para disminuir los descargas del servidor durante los períodos picos de uso y para reducir los tiempos de conexión remotos. Para instanciar un patrón offline, usted empaqueta el patrón y los datos requeridos en algún tipo de medio de almacenamiento, tales como cintas, cd rom,atc. Luego, en vez de sacar la información del master site, los usuarios la sacan del los almacenamientos media que contienen los patrones y los datos. Configuraciones Híbridas : Multimaster y Materialized View La Replicación Multimaster y materialized views pueden ser combinadas en configuraciones híbridas o mixtas para reunir los distintos requerimientos de aplicación. Configuraciones híbridas pueden tener cualquier número de master sites y múltiple materialized view sites para cada master. Multimaster (o n-way) replicación entre dos master puede soportar replicación de tablas completas entre las bases de datos que soportan dos regiones geográficas. Materialized views pueden ser definidas en los masters para replicar tablas completas o subconjuntos de tablas a sitios dentro de cada región. Diferencias clave entre vistas materializadas y master tables replicadas incluyen las siguientes: Tablas maestras replicadas deben contener datos para la tabla completa que está siendo replicada, mientras que las vistas materializadas pueden replicar subset de datos de master tabla. Replicación Multimaster permite replicar cambios de cada transacción mientras los cambios ocurren. Las actualizaciones de vistas materializadas son orientadas a conjuntos, propagando cambios desde múltiples transacciones en una operación más eficiente, orientadas a lotes, pero con intervalos menos frecuentes. Si ocurren conflictos de cambios hechos a copias múltiples de los mismos datos, entonces la detección y resolución de conflictos siempre ocurre en un master site o en un master materialized view site. La siguiente figura muestra un ambiente de replicación híbrido.
10 Links agendados Ambos, master sites y materialized views sites usan links agendados para propagar cambios de datos a otros sitios. Un link agendado es una base de datos con un catálogo de usuario definido para empujar transacciones diferidas. Un link agendado determina como un master site propaga sus colas de transacciones diferidas a sus master site. Cuando usted crea un link agendado, Oracle crea un empleo en la cola del empleo local para empujar la cola de transacciones diferidas a otro sitio en el sistema. Conflictos de Replicación Los ambientes de replicación asincrónicos multimaster y updatable materialized view deben dirigirse a la posibilidad de conflictos de replicación que puedan ocurrir cuando, por ejemplo, dos transacciones originadas desde diferentes sitios actualizan la misma fila casi al mismo tiempo. Cuando ocurren los conflictos de datos, usted necesita un mecanismo para asegurar que el conflicto sea resuelto de acuerdo con las reglas de su negocio y para asegurar que la información converja correctamente en todos los sitios. Además para terminar con cualquier conflicto que pudiera ocurrir en un ambiente de replicación, Oracle Replication ofrece una variedad de métodos preconstruidos de resolución de problemas que lo habilita a definir un sistema de resolución de conflictos para la base de datos que resuelve los conflictos de acuerdo con las reglas del negocio. Si se tiene una situación única que los métodos preconstruidos de resolución de problemas no pueden resolver, entonces se tiene la opción de construir y utilizar métodos propios de resolución de conflictos. Otras opciones para la replicación Multimaster La replicación asincrónica es la forma más común de implementar la replicación multimaster. Sin embargo, hay otras dos opciones de replicación: sincrónica y procedural. Replicación Sincrónica Un ambiente de replicación multimaster puede utilizar replicación asincrónica o sincrónica para copiar datos. Con la replicación asincrónica, los cambios hechos en un master site ocurren en tiempo posterior en los otros master sites participantes. Con la replicación sincrónica, los cambios hechos en un master site ocurren inmediatamente en todos los otros master sites participantes. Cuando utiliza la replicación sincrónica, una actualización de una tabla resulta en la replicación inmediata de la actualización en todos los master sites participantes. De hecho, cada transacción incluye todos los master sites. Por lo tanto, si un master site no puede procesar una transacción por cualquier motivo, entonces la transacción es rolled back en todos los master sites. Aunque se evita la posibilidad de conflictos cuando se utiliza la replicación sincrónica, esto requiere un ambiente estable para operar suavemente. Si la comunicación a un master site no es posible debido a un problema en la red, por ejemplo, entonces los usuarios pueden aun consultar tablas replicadas, pero ninguna transacción puede ser completada hasta que la comunicación sea restablecida. También, es posible para configurar la replicación asincrónica para que simule replicación sincrónica.
11 replicación Procedural Las aplicaciones de procesamiento por lotes pueden cambiar grandes cantidades de datos en una sola transacción. En tales casos, row-level replication puede disminuir la carga de la red con algunos cambios en los datos. Para evitar dichos problemas, una aplicación de procesamiento por lotes operando en un ambiente de replicación puede utilizar replicación procedural para replicar llamadas a procedimientos almacenados para converger en replicas de datos. replicación procedural replica solo las llamadas a los procedimientos almacenados que una aplicación utiliza para actualizar una tabla. No replica los datos modificados en si. Para utilizar replicación procedural, se deben replicar los paquetes que modifican datos en el sistema en todos los sitios. Luego de replicar los paquetes, se debe generar un wrapper para el paquete en cada sitio, el wrapper asegura que sea la ultima llamada hecha al mismo procedimiento del paquete en todos los sitios en el ambiente de replicación. La replicación procedural puede ocurrir asincrónicamente o sincrónicamente. Detección de Conflictos y Replicación Procedural Cuando un dato replicado utiliza replicación procedural, los procedimientos que replican los datos son responsables de asegurar la integridad del dato replicado. Esto es, se deben diseñar procedimientos tanto para evitar o detectar conflictos de replicación y para resolverlos apropiadamente. En consecuencia, la replicación procedural es principalmente utilizada cuando las bases de datos son modificadas solo en grandes operaciones por lote. En tales situaciones, los conflictos de replicación son poco probables ya que numerosas transacciones no disputan el mismo dato. 5HSOLFDFLyQ PDHVWUD Conceptos de replicación maestra Para entender los detalles arquitectónicos de la replicación maestra, es necesario entender los conceptos de la replicación maestra. Ya vimos anteriormente conceptos de replicación maestra, pero en esta sección pretendemos profundizar un poco mas. Conocer como y porque la replicación es usada nos proveerá de una comprensión mucho mayor de cómo los elementos arquitectónicos individuales trabajan juntos para crear un ambiente de replicación multimaestro. Que es la replicación maestra? Oracle tiene dos tipos de replicación maestra: replicación maestra única y replicación multimaestra. La replicación multimaestra incluye muchos sitios maestros donde cada uno de los sitios maestros opera como iguales. En la replicación con un solo sitio maestro la replicación de la vista materializada provee los mecanismos para soportar potencialmente cientos o miles de sitios de vista materializada. Un sitio maestro único que soporta uno o mas sitios de vista materializadas puede también participar en un entorno multimaster creando un ambiente de replicación híbrida (la combinación de replicación multimaster y vista materializada).las vistas materializadas pueden estar basadas en tablas maestras en sitios maestros o en vistas materializadas en sitios maestros de vistas materializadas. Cuando las vistas materializadas están basadas en vistas materializadas se tiene un entorno multitier de vistas materializadas, en un ambiente de este tipo las vistas materializadas que tiene otras vistas materializadas basadas en ellas son llamadas vistas materializadas maestras Replicación multimaster La replicación multimaestro también conocida peer to peer o replicación de n visas esta compuesta de múltiples sitios maestros que participan igualmente en un modelo que soporta actualizaciones desde cualquier sitio. Las actualizaciones a un sitio individual son propagadas a todos los demás sitios maestros que participan. Los servidores de bases de datos Oracle que operan como sitios maestros en un ambiente de replicación multimaestro trabajan automáticamente para uniformizar los datos de todas las replicas de tablas y aseguran las consistencia global de las transacciones y la integridad de los datos. La resolución de conflictos es manejada independientemente de cada uno de los sitios maestros. La replicación multimaestro provee la replicación completa de cada tabla replicada en cada uno de los sitios maestro. Si el ambiente de replicación es un ambiente híbrido (tienen muchos sitios maestros soportando una o mas sitios de vistas materializadas) entonces el sitio maestro objetivo propaga cualquiera de las actualizaciones realizadas sobre la visita materializada a todos los otros sitios maestros en el ambiente de replicación multimaestro. Después cada uno
12 de los sitios maestro propagan los cambios a sus vistas materializadas durante la regeneración de las vistas materializadas. La siguiente figura muestra un posible ambiente de replicación multimaestro. Replicación de un solo maestro Un sitio maestro único puede también funcionar como el sitio maestro objetivo para uno o mas sitios de vistas materializadas. Contrariamente a la replicación multimaestro donde las actualizaciones son propagadas a todos los demás sitios las actualizaciones a las vistas materializadas son realizadas solo en el sitio maestro objetivo. Sitios maestros Un sitio maestro puede ser un nodo en un ambiente de replicación multimaestro y ser el maestro para uno o mas sitios de vistas materializadas en un ambiente de replicación de maestro único o multimaestro. Los objetos replicados son guardados en el sitios maestro y están disponibles para ser accedidos por los usuarios. Sitio maestro de definición En un ambiente de replicación multimaestro un sitio maestro opera como el sitio maestro de definición para un grupo maestro. Este sitio particular realiza muchas de las tareas de mantenimiento y administrativas para el ambiente de replicación multimaestro. Cada grupo maestro puede tener un único sitios de definición maestro, aunque el sitio de definición maestro puede ser cualquiera de los sitios maestros en el ambiente multimaestro. Tradicionalmente en el sitio de definición maestro puede ser cambiado a otro sitios maestro si es necesario. Un sitio maestro único soportando replicación de vistas materializadas es por defecto el sitios de definición maestro. Por que utilizar replicación multimaestro Desde un punto de vista muy básico, la replicación es usada para asegurar que que los datos estén disponibles cuando y donde se los necesite. Las siguientes secciones describen varios ambientes diferentes que tienen necesidades de disponibilidad distintos. Un ambiente de replicación puede tener uno o mas de los siguientes requerimientos: Tolerancia a fallas: la replicación multimaestro puede ser utilizada para proteger la disponibilidad de una base de datos critica, por ejemplo, un ambiente de replicación multimaestro puede replicar los datos en su base de datos para establecer un sitio tolerante a fallas si el sitio primario deja de estar disponible debido a problemas en el sistema o en la red. Un sitio tolerante a fallas de este tipo puede servir también como una base de datos totalmente funcional para soportar el acceso de aplicaciones cuando el sitio primario opera concurrente mente. Es posible usar también Oracle net para configurar el tiempo de conexión automática cuando ocurre una falla, lo cual le permite a oracle net cambiar a un sitio maestro diferente si el primer sitio maestro falla. Balanceo de carga: La replicación multimaestro es útil para las aplicaciones de procesamiento de transacciones que requieren múltiples puntos de acceso a información de basas de datos para los siguientes propósitos:
13 Distribuir la sobrecarga de una aplicación Asegurar disponibilidad continua Proveer acceso localizado a los datos Las aplicaciones que tiene requerimiento de distribución de carga comúnmente incluyen aplicaciones de servicio a los clientes. Cluster reales de aplicación Oracle comparados con replicación: Las áreas primordiales donde se debe considerar si utiliza replicación oracle o cluster reales de aplicación oracle son: balanceo de carga y supervivencia. Balanceo de carga: El sistema de replicación oracle provee balanceo de carga de lecturas sobre múltiples bases de datos mientras que los cluster reales de aplicación proveen balanceo de cargas sobre lecturas y escrituras Como cada escritura debe ser hecha en cada sitio de replicación, la replicación no ofrece balanceo de carga de escrituras. Supervivencia: La replicación provee mejor protección con respecto a desastres naturales, fallas eléctricas y o sabotaje. Porque el resto de los sitios de replicación puedes estar ubicados en otra región geográfica. Los cluster reales de aplicación operan en un cluster o en un sistema masivamente paralelo y esta localizado en un mismo ambiente físico, por lo que no puede proteger contra los mismos problemas físicos que la replicación. Interoperabilidad: la replicación oracle puede replicar datos entre plataformas distintas y sistemas operativos distintos que estén corriendo oracle. Las instancias en un cluster real de aplicación deben correr en la misma plataforma. Soporte para vistas materializadas de ambientes de vistas materializadas desconectadas: La replicación de vistas materializadas permite a los usuarios almacenar remotamente todos o un conjunto de los datos replicados de un sitio maestro en un ambiente desconectado. Este escenario es típico de sistemas de automatización de ventas donde un laptop individual ( un dispositivo desconectado) guarda un subconjunto de los datos relacionados con un vendedor individual. Los sitios maestro operan como el objetivo de los ambiente de vistas materializadas. El soporte de sitios maestros puede ser : Un sistema maestro único soportando todas las vistas materializadas, el cual reduce la posibilidad de datos divergentes debido a que la resolución de conflictos es llevada a cabo únicamente en los sitios maestros o en los sitios maestros de vistas materializadas (en un ambiente de vistas materializadas multitier) Una combinación de replicación multimaestro y de vistas materializadas donde grupos de vistas materializadas son apuntadas a diferentes maestros de la configuración multimaestro. Esta configuración distribuye la carga entre múltiples nodos maestros y provee escalabilidad mejorada en caso de que uno de los nodos maestro se vuelva no disponible. Proceso de replicación multimaestro Como vimos anteriormente hay dos tipos de replicación maestro, Asincrónica y Sincrónica. Replicación asincrónica: La replicación asincrónica propaga cualquier DML o ejecución de un procedimiento independientemente a todo los otros sitios maestro que participan en el ambiente de replicación multimaestro. La propagación ocurre en una transacción independiente después que el DML o el procedimiento d replicación han sido ejecutados localmente. La replicación asincrónica es el modo por defecto para la replicación debido a que requiere menos recurso de red y hardware que la replicación sincrónica, resultando en mejor disponibilidad y desempeño. La replicación asincrónica sin embargo significa que los conjuntos de datos de los distintos sitios maestros del ambiente de replicación pueden ser diferentes durante un periodo de tiempo hasta que los cambio hayan sido propagados. Por otro lado conflictos de datos pueden ocurrir en un ambiente de replicación sincrónica. A continuación se describen el proceso de replicación asincrónica: 1-Un usuario publica una sentencia de DML o ejecuta un wrapper para un procedimiento replicado. Después que una tabla haya sido acondicionada para replicación, cualquier DML para el cual el usuario realice un commit sobre la tabla es capturado para replicación en todos los sitios maestros. Para cada fila que es insertada, actualizada o borrada, un gatillo crea una llamada a procedimiento remoto (RPC) diferida y la
14 coloca en la cola de transacciones diferidas. La cola de transacciones diferidas contiene todas las RPCs diferidas. Si un procedimiento ha sido replicado y su wrapper en un sitio maestro entonces la RPCes colocada en la cola de transacciones diferidas. 2-la cola de transacciones diferidas guarda RPCs diferidas. Cada transacción en la cola de transacciones diferidas tiene una lista de destinatarios que define a donde la transacción diferida debe ser progapada; esta lista contiene todos los sitios maestros excepto el sitio original. Existe una cola de transacciones diferidas para cada sitio, y esta cola puede ser usada en grupos de replicación multi. 3-La propagación envía transacciones diferidas a su destino a intervalos preestablecidos o bajo demanda, las transacciones diferidas en la cola de transacciones diferidas son propagadas a sus destinos objetivos. Cada destino puede tener diferentes intervalos. 4-La transacción diferida es aplicada en el destino remoto mientras que una transacción diferida esta siendo propagada a su destino objetivo, cada RPC diferida es aplicada en el sitio destino llamando a un paquete interno. Si la transacción diferida no puede ser aplicada exitosamente en el sitio destino, entonces es reenviada y colocada en la cola de error en el sitio destino, donde el DBA puede reparar la condición de error y reaplicar la transacción diferida. Cuando una transacción diferida es aplicada en el sitio destino, Oracle chequea posibles conflictos de datos. Si un conflicto es detectado, entonces es registrado en el sitio remoto y,opcionalmente, un método de resolución de conflictos es invocado. 5-cuando una transacción diferida a sido exitosamente propagada a todos los sitios maestros, no es purgada de la cola de transacciones diferidas del sitio original inmediatamente. Esta podría ser purgada mas tarde por un trabajo de purgación el cual corre a intervalos definidos por el usuario. Replicación sincrónica : La replicación sincrónica propaga cualquier cambio hecho en el sitio local a todo los otro sitios maestros conectados sincrónicamente en un mismo ambiente de replicación durante la misma transacción que el cambio inicial. Si la propagación falla en cualquiera de los sitios maestro, entonces la transacción entera, incluyendo el cambio inicial en el sitio maestro local es deshecha. Esta estricta medida asegura la consistencia de datos a lo largo del ambiente de replicación. Contrariamente a la replicación asincrónica, no existe un periodo de tempo en el cual los datos en los sitios maestros no coincidan. La replicación sincrónica también asegura que no se introduzcan conflictos de datos en el ambiente de replicación. Estos beneficios tienen el costo de requerir mucho hardware y recursos de red, y se pide la flexibilidad para el tiempo de desconexión. Por ejemplo, si un único sistema maestro en un ambiente mutimaesto de ese nodo no esta disponible, entonces una transacción no puede ser completada en ningún sitio maestro. Sin embargo, en la replicación asincrónica, la transacción diferida es mantenida en el sitio original hasta que el sitio caído se vuelva disponible. Mientras tanto, la transacción puede ser exitosamente propagada y aplicada a los otros sitios de replicación. Adicionalmente mientras el desempeño de las consultas se mantiene alto, ya que son realizadas localmente con replicación sincrónica, las actualizaciones son mas lentas debido al protocolo de dos fases que se utiliza para realizar los commits y que asegura que cualquier actualización sea exitosamente propagada y aplicada en los sitios remotos. A continuación se describe proceso de replicación sincrónica: 1-Un usuario publica una sentencia de DML o ejecuta el wrapper de un procedimiento replicado después de que una tabla a sido acondicionada para replicaron, cualquier DML sobre el cual el usuario realice commit y que tenga como objetivo dicha tabla es capturado para replicación en todos los otros sitios maestros de replicación. Si un procedimiento ha sido replicado y su wrapper es ejecutado en un sitio maestro, entonces el procedimiento llamado es capturado para replicación. 2-El DML o la ejecución del wrapper es inmediatamente propagado a los sitios destino. El gatillo interno captura cualquier DML e inmediatamente propaga estas acciones a todos los otros sitios maestros en el ambiente de replicación. El gatillo interno aplica estas acciones en el contexto seguro del link de la base de datos del propagador y usa un RPC interno para aplicar estas acciones en el sitio destino. Como un gatillo in terno, un wrapper pasa un procedimiento replicado inmediatamente propaga la llamada al procedimiento a todos los otros sitios maestros en el ambiente de replicación. Si la transacción falla en cualquiera de los sitios maestros de replicación entonces la transacción es desecha en todos los sitios maestros. Esta metodología asegura la consistencia de datos en todos los sitios maestros de replicaron. Debido a la necesidad de deshacer una transacción si cualquier sitio falla, la replicación sincrónica es extremadamente dependiente de redes de alta disponibilidad,bases de datos de alta disponibilidad y hardware asociado.
15 Conceptos sobre resolución de Conflictos Cuando Oracle replica una tabla, algún DML aplicado a la tabla replicada de un sitio replicado(tanto un sitio master o con vistas materializadas) que causa un conflicto de datos en el sitio de destino es automáticamente detectado por el servidor Oracle en el sitio destino. Algunos conflictos de datos introducidos por el sitio de vistas materializadas son detectados y solucionados en el sitio master objetivo o en el sitio master de vistas materializadas de las vista materializada. Por ejemplo, si el siguiente master group es programado para propagar cambios una vez por hora, entonces considerar que pasa cuando: Hora sitio master A sitio master B estado 8:00am propagar cambios al sitio master B propagar cambios al sitio master A convergencia de datos 8:15am actualiza fila 1 8:30am actualiza fila 1 9:00am propagar cambios al sitio master B propagar cambios al sitio master A detección de conflicto en la fila 1 Si el tiempo entre propagaciones es considerado un intervalo, y dos o mas sitios actualizan la misma fila durante el mismo intervalo, entonces ocurre un conflicto. Además de los conflictos de actualización, descriptos anteriormente, están los problemas de inserción y borrado. Cada conflicto ocurre cuando las acciones conflictivas ocurren dentro del mismo intervalo. Actualización: Dos o mas sentencias de DML son aplicadas a la misma fila en diferentes sitios de replicación antes que la sentencia de DML pueda ser propagada a los otros sitios. Unicidad: Una inserción es llevada a cabo en dos o mas sitios y la clave primaria ( u otro conjunto de columnas únicas) por cada inserción que contiene el mismo valor, o una actualización en un sitio modifica la clave primaria(u otro conjunto de columnas únicas), el cual contienen el misma valor que una inserción en otro sitio. Eliminacion: Un fila es eliminada en n sitio y una actualización ocurre en otro sitio, esto puede resultar en un intento de actualizar una fila que y ano existe mas, o l máxima fila es eliminada en el mismo intervalo en mas de un sitio. Luego que un conflicto de datos es detectado, ocurren las siguientes acciones: 1-Los métodos de resolución de conflictos tratan de resolver el conflicto de datos. 2-Si el conflicto no fue resuelto, entonces se registra el conflicto en la cola de errores en el sitio destino. Cuando un conflicto de datos es registrado en la cola de errores, luego el administrador de la base de datos es responsable de resolver manualmente el conflicto. Si escoge utilizar métodos de resolución provistos por Oracle o los definidos por el usuario, entonces el servidor Oracle trata automáticamente de resolver el conflicto. Los métodos de resolución de conflictos que uno puede implementar deben estar de acuerdo con las regla s del negocio definidas por el ambiente de replicación y deben garantizar convergencia de datos. Puede ser necesario modificar tablas para encontrar las
16 necesidades de los métodos de resolución que se implementaron. Por ejemplo, el ultimo método de resolución de conflicto timestamp necesita una columna de timestamp en la tabla en la cual es implementada. Arquitectura de la replicación Multimaster Esta sección describe la arquitectura de la replicación en términos de mecanismos y procesos. Mecanismos de sitio maestro Para soportar un ambiente de replicación, Oracle utiliza los siguientes mecanismos en cada sitio maestro que participa, ya sea en ambientes de replicación multimaestro o replicación master. Algunos de estos mecanismos son requeridos solo en circunstancias especiales. Roles / Usuarios del master site Dependiendo de los requerimientos de seguridad, los siguientes tres roles pueden ser consolidados en un solo administrador de replicación. De hecho, en la mayoría de los ambientes de replicación multimaestro utilizan un solo usuario que lleva a cabo los roles de administrador de replicación, propagador y receptor. Administrador de replicación Rrealiza todas las funciones administrativas relacionadas al sitio maestro en un ambiente de replicación. Tiene las siguientes responsabilidades: Construcción y mantenimiento de grupos individuales de replicación master. Agregar y eliminar los master sites participantes. Administración de colas. Controlar el estado del ambiente de replicación (normal y quiesced). Propagador Realiza la tarea de propagar cada transacción contenida la cola de transacciones diferidas a la de destino. Puede haber varios administradores para administrar los distintos esquemas, pero solo un propagador por cada base de datos Receptor Es el responsable de recibir y aplicar las transacciones diferidas por el propagador. Si no tiene los permisos apropiados para invocar transacciones en la cola de diferidas, entonces toda la transacción se coloca en la cola de error del destino. Vínculos de base de datos Proveen un conducto para replicar datos entre master sites y materializad views sites. En un ambiente multimaster, hay un database link desde cada master site individual a todos los demás master sites. Es decir que hay N-1 database links por cada master site, donde N es el total de sitios maestros. En la figura cada master site tiene dos database links a los restantes master sites. Esta configuración asegura canales de comunicación vi direccionales entre sitios maestros, necesaria para replicación multimaster.
17 Notar que los sitios de vistas materializadas, solo necesitan un link desde el sitio de vista materializada al master site. El sitio maestro no necesita un link al sitio de vistas materializadas. Objetos replicables Tablas: En la mayoría de los casos la replicaron de tablas es lo fundamental del ambiente de replicación. Luego de que la tabla es seleccionada para ser replicada y ha sido generada con soporte de replicación, es monitoreada por trigger internos que detectan cualquier DML aplicado a ella. Índices: Cualquier índice que es usado para reforzar una tabla es automáticamente creado en sitios destinos remotos cuando una tabla es seleccionada para replicación y creada en el sitio remoto. Cualquier índice necesario por razones de performance debe ser explícitamente seleccionado para replicación para ser creado en los demás master sites participantes en el ambiente de replicación. Cuando un índice es replicado a otros sitios, funciona como si el índice hubiera sido creado localmente. No es necesario generar soporte de replicación para los índices. Packages y Package Bodies: Seleccionar packages y package Bodies y generar el necesario soporte de replicación da la habilidad de realizar replicación procedural. Este tipo de replicación puede ofrecer mejoras de performance para grandes operaciones orientadas a lotes con gran numero de filas que deben ser corridas en forma serial dentro del ambiente de replicación. Procedimientos y funciones: Los procedimientos y funciones no declarados como parte de un package no pueden tener soporte de replicación. Tipos definidos por el usuario ytype Bodies Para replicar un objeto esquema con tipos definidos por el usuario, estos tipos deben existir en todos los sitios de replicación y ser exactamente el mismo en todos los sitios. Triggers Para asegurarse que cualquier aplicación o base de datos lógica es presentada en cada master site, uno puede seleccionar triggers para replicación. Un importante ejemplo de trigger de replicación es replicar un trigger que automáticamente inserta una marca de tiempo en la tabla cuando alguna DML es aplicada en la tabla. Vistas, vistas objeto y sinónimos Cuando uno replica una vista, un objeto vista o un sinónimo, uno utiliza simplemente la replicación para distribuir ese objeto a los otros master sites que están involucrados en el ambiente de replicación. Luego de que el objeto es replicado a los otros sitios, opera como si el objeto hubiera sido creado localmente. ningún trigger interno o package, monitora el objeto para capturar sus cambios. Indextypes Oracle soporta la replicación de tipos de índices. Uno debe explícitamente replicar el tipo y el cuerpo de las funciones que uno utiliza para implementar un tipo índice. Operadores definidos por el usuario Desarrolladores de aplicaciones orientadas a objetos pueden extender la lista de operadores relacionales bulit-in (por ejemplo +,-,/,*).Cuando uno replica operadores definidos por el usuario, simplemente utiliza la replicación para distribuir el operador a los demás master sites involucrados en el ambiente de replicación
18 Triggers internos Se utilizan para capturar y almacenar información acerca de actualizaciones a datos replicados. Triggers internos construyen llamadas a procedimientos remotos (RPCs) para reproducir cambios en datos hechos en el sitio local a sitios de replicación remota. Procedimientos internos Cuando un RPC diferido es creado en un trigger interno es propagado a los demás master sites participantes, un procedimiento interno en el sitio destino es utilizado para aplicar al RPC en el sitio remoto. Estos procedimientos internos son activados automáticamente cuando uno genera soporte de replicación para una tabla. Estos procedimientos son ejecutados basados en RPCs recibidos desde la cola de transacciones diferidas del sitio de origen. Cola de transacciones diferidas Almacena las transacciones (por ejemplo DML) que son limite de otro destino en un master grupo. Oracle almacena RPCs producidos por los triggers internos en la cola de transacciones diferidas de un sitio para luego propagarlas. Cola de error Almacena la información de aquellas transacciones que no pudieron ser aplicadas con éxito en el sitio local. No se despliega información acerca de errores en otros sitios maestros. Cuando una condición de error ha sido resuelta, se puede re ejecutar la transacción o borrarla de la cola de error. Cola de trabajo Oracle logra el proceso de propagación utilizando el mecanismo de la cola de trabajo y transacciones diferidas. Cada servidor tiene su cola local de trabajos. Una cola de trabajos locales de un servidor es una base de datos que almacena información acerca de trabajos locales tales como PL/SQL para ejecutar un trabajo, cuando corre un trabajo, etc. Mecanismos administrativos Muchos mecanismos son requeridos para manejar las tareas administrativas que son llevadas a cabo para soportar un ambiente de replicación. Estos mecanismos permiten encender y apagar un ambiente de replicación, así como monitorear tareas administrativas que son generadas cuando uno construye o modifica el ambiente de replicación. Modos de operación de replicación Hay tres modos de operación : Normal este modo permite que la replicación ocurra. El ambiente de replicación esta corriendo en este modo. Cualquier transacción sobre un objeto replicado es permitida y es propagada apropiadamente. Quiescing es el modo para pasar del modo normal al modo quiesced. En este modo el usuario no esta habilitado a ejecutar transacciones sobre objetos replicados, pero existen transacciones diferidas que son propagadas. Las consultas sobre tablas quiescing están permitidas. Cuando todas las transacciones diferidas fueron exitosamente propagadas a sus respectivos destinos, el ambiente de replicación precede en el modo Quiesced. Quiesced puede ser considerado deshabilitado para el uso normal de la replicación,.es principalmente para propósitos administrativos (tales como agregar o eliminar objetos replicados).la replicación esta detenida en este modo. Modo control de replicación: Existen dos modos de operación Suspend Ejecutando el mecanismo suspend comienza el modo quiescing que transfiere el modo de operación replicación a un master gruop normal en uno quiesced. Este mecanismo solo puede ejecutarse en un ambiente en modo normal. Ejecutar este mecanismo cuando sea necesario modificar el ambiente de replicación. Resume transfiere un grupo maestro desde el modo de replicación quiesced al modo normal. Si se han llevado a cabo trabajos administrativos en el ambiente de replicación ( por ejemplo, se agrego un objeto
19 replicado), entonces se debe verificar que la cola de pedidos administrativos este vacía antes de ejecutar el mecanismo de resume. Mecanismos Organizacionales El mas notable de los mecanismos organizacionales es el master group. Ayuda a agrupar columnas que son utilizadas para resolver conflictos en una tabla replicada. Master group en un ambiente de replicación, Oracle logra la replicación de objetos utilizando Grupos de Replicación. Son una colección de objetos replicados que son siempre actualizados en una manera transaccionalmente consistente. Organizando objetos relacionados de la base de datos en un grupo de replicación, es mas fácil administrar los objetos a la vez. típicamente, uno crea y usa un grupo de replicación para organizar un esquema de objetos necesario para soportar una aplicación de base de datos en particular. En un ambiente de replicación multimaster, los grupos de replicación son llamados master groups. Column groups proveen mecanismos para agrupar todas las columnas que están involucradas en una rutina de resolución de conflictos.
20 9LVWDV 0DWHULDOL]DGDV Como vimos anteriormente, una vista materializada es una réplica de un master en un instante de tiempo. Estas vistas son actualizadas mediante procesos por lotes conocidos como refreshes. Como varios de los conceptos de las vistas materializadas ya fueron explicados, vamos a ver algunas características extra que son de interés. Por que usar vistas materializadas? Ya vimos anteriormente cuales eran las ventajas de la DB replicadas. Las ventajas de las vistas materializadas de por si, son las siguientes: Reducir la carga de la red. (Visto anteriormente) Replicación de subconjuntos: Esto permite la replicación de datos pertinentes para el sitio en particular. Es decir que permite replicar el mínimo imprescindible. Permite computación off-line. (Visto anteriormente) Desarrollo en masa. (Visto anteriormente) Vistas materializadas en múltiples capas Oracle permite la creación de vistas materializadas, basadas en otras vistas materializadas. Esto genera un ambiente de varias capas de vistas, una jerarquía. Las vistas en este tipo de ambientes pueden ser de escritura o sólo lectura. En esta figura se puede ver un posible ambiente de replicación con mv1.world dependiendo del master orc1.world y a mv2.world dependiendo de mv1.world. A las vistas que actúan de master de otras vistas se les llama master materialized views. Cualquier sitio puede ser un master y cada master puede tener mas de 1 vista dependiente. En la siguiente figura vemos una jerarquía de vistas dependientes de un master.
Instituto de Computación Facultad de Ingeniería Universidad de la República Oriental del Uruguay Técnicas Avanzadas para Gestión de Sistemas de Información Carrera de Ingeniería en Computación dición 2003

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 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución