“AÑO DE LA INVERSION RURAL Y LA SEGURIDAD ALIMENTARIA”

“UNIVERSIDAD SAN PEDRO”

INTEGRANTES: RUIZ LEJABO JOSE CHAPILLIQUEN CORNEJO BABY

DOCENTE: RIVERA MONTERO FREDY

CURSO: BASE DE DATOS II

TEMA: REPLICACION DE BASE DE DATOS

ESCUELA: INFORMATICA Y DE SISTEMAS

FACULTAD: INGENIERIA

2013 Índice:

INTRODUCCION

W. Curtis Preston

Tecnología de replicación de datos………………………………………………………………………. 4Replicación síncrona y asíncrona………………………………………………………………………….. 4Replicación asíncrona y “replicación periódica”…………………………………………………… 5

Buenas prácticas de administración para garantizar una replicación eficaz………….. 5Replicación y duplicación de datos………………………………………………………………………. 6

Conceptos Universales

Replicación……………………………………………………………………………………………………………………….. 7 Beneficios…………………………………………………………………………………………………………….............. 8 Replicación en Árbol………………………………………………………………………………………………………... 9 Características y beneficios…………………………………………………………………………………………… 11 Componentes del modelo de replicación ……………………………………………………………13 Escenarios típicos de la replicación…………………………………………………………………….. 14

Tipos de replicación

replicación de instantáneas…………………………………………………………………………................................17replicación transaccional …………………………………………………………………………......... 19 replicación de mezcla………………………………………………………………………………….........21

Factores para elegir el método de replicación a utilizar………………………………………………… 23

Configurar la replicación con la creación de reflejo de la base de datos

Configurar el publicador………………………………………………………………………………....... 24Configurar la creación de reflejo de la base de datos……………………………………...... 24Configurar la entidad reflejada de manera que utilice el mismo distribuidor que la entidad de seguridad………………………………………………………………………………………… 24Configurar los agentes de replicación para la conmutación por error.....................25Agregar las entidades de seguridad y reflejada al Monitor de replicación……….....26

CONCLUSIONES

BIBLIOGRAFIA

INTRODUCCION

|

La replicación de datos permite que ciertos datos de la base de datos sean almacenados en más de un sitio, y su principal utilidad es que permite aumentar la disponibilidad de los datos y mejora el funcionamiento de las consultas globales a la base de datos. [Elm00]

La replicación en SQL Server consiste, en el transporte de datos entre dos o más instancias de servidores. Para ello SQL Server brinda un conjunto de soluciones que permite copiar, distribuir y posiblemente modificar datos de toda la organización. Se incluyen, además, varios métodos y opciones para el diseño, implementación, supervisión y administración de la replicación, que le ofrecen la funcionalidad y flexibilidad necesarias para distribuir datos y mantener su coherencia.

En la replicación se utiliza una metáfora de la industria de la publicación para representar los componentes y procesos de una topología de replicación. De esta forma el modelo se compone, básicamente, de los siguientes elementos: publicador, distribuidor, suscriptores, publicaciones, artículos y suscripciones.

W. Curtis Preston

|

¿Qué es la tecnología de replicación de datos y cómo funciona?

La replicación es el proceso de copia de datos de un alojador a otro por bloques y de forma diferencial. Por lo tanto, como la replicación se suele llevar a cabo a nivel de archivo o de libro, a medida que cambian cosas en el libro en cuestión, los bloques que han cambiado en la fuente se replican inmediatamente en el destino.

¿Cuál es la diferencia entre replicación síncrona y replicación asíncrona?

La tecnología de replicación síncrona no reconoce el asiento de la aplicación primaria hasta que se ha replicado el bloque en la sede de destino. La replicación asíncrona, en cambio, primero reconoce el asiento y luego replica el bloque al cabo del tiempo.

Cada una tiene sus ventajas e inconvenientes en distintos supuestos. La replicación síncrona tiene la ventaja de estar continuamente actualizada en la sede de destino. Se tiene siempre la certeza de que los datos existentes en la sede de destino están tan al día como los datos de la sede de origen. La dificultad reside en que, como no reconoce el asiento hasta que sabe que el bloque se ha replicado, el lapso de tiempo necesario para que el bloque llegue al destino puede incidir en el rendimiento de la aplicación frontal. Por lo tanto, la sincronización sólo se suele hacer en un centro de datos o a una distancia muy corta – inferior a 75 kilómetros, o incluso a 35 kilómetros. Algunas tecnologías permiten llegar más lejos, pero son muy recientes.

La ventaja de la replicación asíncrona es que, sea cual sea el ancho de banda o la latencia, no incide en el rendimiento de la aplicación primaria. El inconveniente de la replicación asíncrona es que se puede desincronizar de la aplicación primaria, y en realidad se puede desincronizar tanto que no alcance nunca a ponerse al día. Algunos productos tienen la capacidad de funcionar en modos especiales para intentar ponerse al día, pero si no se tiene ancho de banda suficiente o si se tiene demasiada latencia, se puede quedar uno tan atrás que no se cumple el objetivo de punto de restauración (RPO), que es el interés fundamental de la replicación.

De modo que o se está siempre actualizado, pero con el riesgo de incidir en el rendimiento, o no se incide en el rendimiento, pero se puede uno desincronizar muy rápidamente.

|

¿”En qué difiere la replicación asíncrona de la “replicación periódica”?

Técnicamente, la replicación periódica es un subconjunto de una de las maneras de realizar replicación asíncrona, en la medida en que como asíncrono significa precisamente que no se está forzando el reconocimiento del asiento antes de reconocer el contra asiento en la aplicación primaria. La replicación periódica significa que se toma una instantánea en un momento determinado, normalmente cada hora.

A continuación, el producto de replicación examina los bytes que han cambiado entre la última instantánea y la actual, y luego replica los bytes necesarios para crear esos puntos en el tiempo en el destino de replicación. Por lo tanto, algunos de ellos se pueden replicar continuamente y después tomarán una instantánea en la sede de origen. Luego les bastará con replicar ese estado en la otra sede. Pero la gran diferencia es que con el sistema de replicación periódica, si se corrompe un punto en el tiempo, se dispone de otro o de varios a los cuales regresar.

Con la replicación asíncrona, dependiendo de lo actualizado que se esté, se está copiando continuamente todo, incluida la corrupción. Si por ejemplo borrara accidentalmente una tabla, podría sobrescribir el destino con esa corrupción.

¿Puede comentar buenas prácticas de administración para garantizar la replicación efectiva?

Todo se reduce a probar. Mucha gente opta por la replicación porque piensa que va a tener ancho de banda suficiente, que la replicación utiliza muy poco ancho de banda, y que basta con poner en marcha la replicación para que todo funcione como por arte de magia. Ese es el camino más seguro hacia el desastre. Da por supuesto que todos los productos de replicación replicarán la misma cantidad de datos. Lo primero que hay que comprender es que productos distintos replican de forma diferente y envían cantidades de datos diversas, y se comportan de forma diferente en condiciones distintas. Pruebe los productos en un contexto experimental, donde el ancho de banda y la latencia no sean un problema, pero tome nota del ancho de banda que está utilizando la replicación.

Otra cosa que puede hacer es utilizar un simulador de Red de área amplia donde podrá simular realmente distintos tipos tanto de latencias como de anchos de banda más bajos. A continuación, puede especificar que tiene que parecer que el dispositivo está a 1.500 ó 15.000 kilómetros de distancia, y comprobar cómo funciona la aplicación en esas condiciones. Si se hace ese experimento en vez de contentarse con utilizar una Red de área amplia, es porque ayuda a descartar variables de la ecuación, de tal modo que la

|

única variable que quede sea el software que se está probando. Si puede usted simular los cambios, el ancho de banda y la latencia de modo que sean siempre los mismos, podrá ver qué distinto es el comportamiento de los diversos productos. Creo que si prueba usted los productos antes de comprarlos, tendrá una experiencia mucho más positiva que la mayoría de la gente.

Lo siguiente que queda por hacer es supervisar. La replicación funciona tan silenciosamente, que poca gente está pendiente de comprobarla. La forma más segura que conseguir que fallen es no vigilarlas.

Qué relación hay entre replicación y duplicación de datos?

Están relacionadas en la medida en que con la duplicación de datos, puede usted replicar cosas que antes no podía. Históricamente, la replicación se realizado a nivel de libro o de archivo. Se replica un libro, archivo o base en su ubicación primaria. Después, si se guarda esa base de datos a una matriz de discos, y luego se replica esa matriz de discos sin duplicación, se estaría replicando una cantidad de datos significativamente mayor que si se replicara desde el origen.

La duplicación permite guardar esos datos en disco utilizando metodologías de duplicación, y luego, como la duplicación en realidad elimina los bloques redundantes, permite replicar esa guarde a otra ubicación. Algo que hasta ahora, sólo era posible en los entornos más reducidos.

|

Conceptos Universales

Replicación:

La replicación es el proceso de copiar y mantener actualizados los datos en varios nodos de bases de datos ya sean estos persistentes o no. Éste usa un concepto donde existe un nodo amo o maestro (master) y otros sirvientes o esclavos (slaves).

La replicación de discos y particiones es la respuesta a una parte importante de esas dos acciones de mantenimiento. La replicación es el proceso mediante el cual se genera una copia exacta de parte del sistema. Esa parte puede ser desde un archivo hasta una carpeta, una partición, un disco o incluso varios discos.

Es un conjunto de tecnologías destinadas a la copia y distribución de datos y objetos de base de datos desde una base de datos a otra, para luego sincronizar ambas bases de datos y mantener su coherencia. La replicación permite distribuir datos entre diferentes ubicaciones y entre usuarios remotos o móviles mediante redes locales y de área extensa, conexiones de acceso telefónico, conexiones inalámbricas e Internet.

La replicación transaccional se usa normalmente en escenarios servidor a servidor que requieren un alto rendimiento, como por ejemplo, la mejora de la escalabilidad y la disponibilidad, el almacenamiento de datos y la creación de informes, la integración de datos procedentes de varios sitios, la integración de datos heterogéneos, y la descarga del procesamiento por lotes. La replicación de mezcla se ha diseñado principalmente para las aplicaciones móviles o de servidores distribuidos que pueden encontrarse con conflictos de datos. Los escenarios más frecuentes son: el intercambio de datos con usuarios móviles, las aplicaciones de punto de venta (POS) a consumidores, y la integración de datos de varios sitios. La replicación de instantáneas se usa para proporcionar el conjunto de datos inicial para la replicación transaccional y de mezcla; también se puede usar cuando está indicada una actualización completa de los datos. Con estos tres tipos de replicación, SQL Server proporciona un sistema eficaz y flexible para la sincronización de datos en toda la organización.

|

Beneficios:

La replicación se usa mucho en sistema de acceso a datos por varios motivos:

Rendimiento: Normalmente y dependiendo del caso, hay más lectura que escritura en una base de datos, por lo que tener varios nodos solo procesando la lectura puede traer un gran beneficio de rendimiento en una base de datos muy consultada.

Prueba de fallas: Un esclavo estando casi sincrónicamente actualizado puede ser útil en caso de que el nodo maestro caiga, este puede reemplazarlo y así no detener el servicio.

Fiabilidad: Muchas veces se puede tener una replicación para tener la seguridad de que los datos están siendo copiados a otro nodo, en caso de sufrir un desperfecto en el maestro.

Generación de bloqueos: aunque esta es más precisa, también se puede usar para procesos que necesiten leer datos, generando bloqueos, al hacerlo sobre un esclavo esto no interviene en el funcionamiento de todo el sistema, es muy usado para por ejemplo, hacer copias de seguridad, o extraer grandes cantidades de datos para generar estadísticas.

|

Replicación en Árbol:

En muchos casos, los esclavos también pueden tener sus propios esclavos, por lo que se puede generar árboles de replicación, bajando la carga al maestro y dando la posibilidad de diseñar mejores modelos contra caídas de servicios.

Las soluciones para integración de datos necesitan soportar requerimientos claves de negocios como toma de decisiones en tiempo real, efectividad operacional y rentabilidad. Cambios, como el crecimiento exponencial de datos, expansión global del negocio y ambientes de múltiples bases de datos que requieren de soluciones de integración de datos que sean flexibles, fácil de usar por el equipo humano de TI existente y que pueda ser implementado rápidamente para resultados mensurables.

Proyectos para integración especifica de datos como conversión de datos de nuevos sistemas de bases de datos, migración de datos para nuevos o versiones actualizadas de ERP, CRM u otra suite de aplicaciones, replicando información corporativa para recuperación de desastres o duplicando datos específicos a bases de datos de bajo costo para análisis y reportes, requieren de una solución que provea:

Soporte acceso y movimiento de datos en tiempo real (adicional al bach) Soporte cualquier tamaño de set de datos Soporte múltiples bases de datos (tanto como bases de origen o destino) Soporte cualquier plataforma

Con actividades de sincronización de datos, como distribución da datos operacionales, actualización en tiempo real de los sistemas analíticos o balanceo de datos entre numerosos sistemas, usted también puede necesitar estas características:

Tecnología de captura de datos (CDC) – para minimizar el acceso a las bases de datos de origen y destino

Soporte a Bases de Datos Heterogéneas Soportar transformaciones de datos Soportar integración de datos con soluciones de data warehousing,

Instalando una sólida solución de integración de datos que permite direccionar múltiples bases de datos, múltiples plataformas y acezando datos en tiempo real permite resolver varios problemas de administración de información que puedan surgir de una absorción/adquisición, requerimientos de could computing, cambios del negocio, auditoria/riesgo, administración remota y Master Data Managment (MDM) o planes de gobernabilidad de datos.

HiT Software DBMoto® provee una óptima integración de datos basado en estándares abiertos, los cuales permiten al equipo de tecnología o integradores de sistemas

|

implementar en forma rentable una solución atreves de bases de datos heterogéneas o cualquier plataforma.

DBMoto ofrece replicación e integración de datos en tiempo real con:

Bajo costo de inversión Soporte a bases de datos heterogeneas Interoperabilidad con sistemas legados Rápida implementación / lo más rápido existente en el mercado Alta fiabilidad y comprobado rendimiento Soporte técnico experto y responsable Soporta 32-bit/64-bit No intrusivo en sistemas IBM

DBMoto ejecuta replicación de datos en Refresh y tiempo real para sus servidores y equipos computaciones corporativos. Las principales bases de datos como IBM DB2 (incluyendo i/System i/iSeries/AS400, AIX, Linux, Windows y z/OS), Oracle, Microsoft SQL Server, Sybase ASE, SQL Anywhere, MySQL, IBM Informix, Ingres, PosgreSQL, Gupta Tehcnologies SQLBase y Firebird están soportadas. DBMoto actualmente soporta IBM Netezza data warehouse (Ingles) como destino de datos.

En modo Refresh (Snapshot), DBMoto lee los datos, aplica las reglas de mapeo definidas por el administrador y escribe los resultados en la bases de datos de destino. En modo Mirroring, DBMoto ejecuta una replicación incremental en tiempo real desde el destino al origen, basado en la actividad de los logs de transacciones y aplicando Captura de datos (CDC) para minimizar el tráfico de datos. En modo Synchronization, DBMoto ejecuta un Mirroring bidireccional con resolución de conflictos incorporado con el fin de sincronizar datos entre las bases de datos de origen y destino. DBMoto ofrece sincronización multi-servidor, coordinando la sincronización de datos entre tres o más bases de datos.

|

Poderosos y amigables asistentes gráficos permitirán instalar el producto en forma muy rápida. Y a diferencia de otras soluciones de integración de datos, DBMoto ofrece control ilimitado sobre las replicaciones y transformaciones de datos utilizando tecnología de scripting.

Características y Beneficios:

Características Claves Beneficios

Mirroring en tiempo real basado sobre logs de transacciones

Toma de decisiones mas precisa

Replicación modo Refresh Fácil, e instantánea entrega de datos

Modo SincronizaciónNo necesita programación

Mantiene dos bases de datos sincronizadas - Servidor de Bases deDatos mantiene la estabilidad

Asistentes gráficos Rápida y fácil instalación y configuración

Completa adaptación vía scripting Detallado control detransformaciones

Funcionalidades incorporadas, con extensivas funciones personalizadas Creación de tablas automática en el destino

Rápido despliegue de datos

|

Accesibilidad remota a la consola de administración Managment Center

Conveniente administración

Completo reporte grafico de actividades y acceso

Herramienta de auditoría para el análisis de datos

Interfaz gráfica y amigable Rápida curva de aprendizaje

Múltiples funciones de comparaciónde resultados en DBMoto Verifer

Reduce el tiempo para verificar la actualizacióndatos posteriormente a una replicación

Avanzada consola de errores

Solución precisa de problemas posterior a una replicación

Grupo de replicaciones

Reduce el tiempo de conectividad y tráfico entre el origen y destino

|

Componentes del modelo de replicación

Para representar los componentes y procesos de una topología de replicación se utilizan metáforas de la industria de la publicación. El modelo se compone de los siguientes objetos: el publicador, el distribuidor, el suscriptor, la publicación, el artículo y la suscripción; así como de varios agentes, que son los procesos responsabilizados de copiar los datos entre el publicador y el suscriptor. Estos agentes son: agente de instantáneas, agente de distribución, agente del lector del registro, agente del lector de cola y agente de mezcla .

La replicación de datos es un asunto exclusivamente entre servidores de datos, en nuestro caso hablamos de servidores SQL Server. Los servidores SQL Server pueden desempeñar uno o varios de los siguientes roles: publicador, distribuidor o suscriptor.

El publicador es un servidor que pone los datos a disposición de otros servidores para poder replicarlos. El distribuidor es un servidor que aloja la base de datos de distribución y almacena los datos históricos, transacciones y metadatos. Los suscriptores reciben los datos replicados.

Una publicación es un conjunto de artículos (este concepto: "artículo de una publicación", es diferente del concepto "artículo o registro de una base de datos", como explicaremos más adelante) de una base de datos. Esta agrupación de varios artículos facilita especificar un conjunto de datos relacionados lógicamente y los objetos de bases de datos que desea replicar conjuntamente. Un artículo de una publicación puede ser una tabla de datos la cual puede contar con todas las filas o algunas (filtrado horizontal) y simultáneamente contar de todas las columnas o algunas (filtrado vertical), un procedimiento almacenado, una definición de vista, la ejecución de un procedimiento almacenado, una vista, una vista indizada o una función definida por el usuario.

Una suscripción es una petición de copia de datos o de objetos de base de datos para replicar. Una suscripción define qué publicación se recibirá, dónde y cuándo. Las suscripciones pueden ser de inserción o de extracción; y una publicación puede admitir una combinación de suscripciones de inserción y extracción. El publicador (en las suscripciones de inserción) o el suscriptor (en las suscripciones de extracción) solicita la sincronización o distribución de datos de una suscripción.

El publicador puede disponer de una o más publicaciones, de las cuales los suscriptores se suscriben a las publicaciones que necesitan, nunca a artículos individuales de una publicación. El publicador, además, detecta qué datos han cambiado durante la

|

replicación transaccional y mantiene información acerca de todas las publicaciones del sitio.

La función del distribuidor varía según la metodología de replicación implementada. En ocasiones se configura como distribuidor el mismo publicador y se le denomina distribuidor local. En el resto de los casos el distribuidor será remoto, pudiendo coincidir en algún caso con un suscriptor.

Los suscriptores además de obtener sus suscripciones, en dependencia del tipo y opciones de replicación elegidas, pueden devolver datos modificados al publicador. Además puede tener sus propias publicaciones.

Escenarios típicos de la replicación

En una solución de replicación pudiera ser necesario utilizar varias publicaciones en una combinación de metodologías y opciones. En la replicación los datos o transacciones fluyen del publicador al suscriptor pasando por el distribuidor.

Por lo tanto en su configuración mínima una topología de replicación se compone de al menos dos o tres servidores SQL Server que desempeñan los tres roles mencionados.

Variando la ubicación del servidor distribuidor podríamos contar con las siguientes variantes:

1. El rol de distribuidor desempeñado por el publicador (Fig. 1).2. El rol de distribuidor desempeñado por el suscriptor (Fig. 2)3. Un servidor de distribución, independiente del publicador y del suscriptor (Fig.3)

Fig.1 Publicador-Distribuidor Fig.2 Distribuidor-Suscriptor

|

Fig. 3 Distribuidor independiente

En la mayoría de las configuraciones, el peso fundamental de la replicación recae, sobre el servidor de distribución. Por tanto éste puede ser un criterio para determinar su ubicación, teniendo en cuenta las configuraciones (posibilidades físicas) de los servidores, así como otras responsabilidades que pueden estar desempeñando (servidor de dominio, servidor de páginas web entre otras) [Mic01].

Existe la posibilidad de contar con un servidor que se suscriba a una publicación y a la vez la publique para el resto de los suscriptores, esto puede ser muy útil cuando se cuente con una conexión muy costosa con el publicador principal. Por ejemplo el publicador principal en Madrid y los suscriptores en Ciudad Habana, Varadero, Cayo Coco, Cayo Largo, etc. En casos como este, se puede elegir un suscriptor, digamos el servidor de Ciudad Habana el cual se suscribe al publicador en Madrid y a la vez actúa como servidor de publicación para los servidores de Varadero, Cayo Coco, Cayo Largo y demás. Evidentemente en una configuración tal pueden nuevamente combinarse la ubicación de los dos distribuidores y aumentar el número de variantes que pueden presentarse pero las consideraciones para determinar la ubicación del servidor que fungirá como distribuidor son las ya mencionadas.

|

Tipos de replicación

Los tipos básicos de replicación son:

replicación de instantáneas replicación transaccional replicación de mezcla

Para ajustarse aún más a los requerimientos de los usuarios se incorporan opciones como son la actualización inmediata en el suscriptor, la actualización en cola y la transformación de datos replicados.

|

Replicación de instantáneas

En la replicación de instantáneas los datos se copian tal y como aparecen exactamente en un momento determinado. Por consiguiente, no requiere un control continuo de los cambios. Las publicaciones de instantáneas se suelen replicar con menos frecuencia que otros tipos de publicaciones. Puede llevar más tiempo propagar las modificaciones de datos a los suscriptores. Se recomienda utilizar: cuando la mayoría de los datos no cambian con frecuencia; se replican pequeñas cantidades de datos; los sitios con frecuencia están desconectados y es aceptable un periodo de latencia largo (la cantidad de tiempo que transcurre entre la actualización de los datos en un sitio y en otro). En ocasiones se hace necesario utilizarla cuando están involucrados algunos tipos de datos (text, ntext, e image) cuyas modificaciones no se registran en el registro de transacciones y por tanto no se pueden replicar utilizando la metodología de replicación transaccional.

Los servidores OLAP son candidatos a la replicación de instantáneas. Las consultas ad-hoc que aplican los administradores de sistemas de información son generalmente de solo lectura y los datos con antigüedad de horas o días no afectan sus consultas. Por

|

ejemplo un departamento desea hacer una investigación sobre demografía de los artículos vendidos hace dos meses. La información de la semana pasada no afectará sus consultas; además el departamento no está planeando hacer cambio en los datos, solo necesita el almacén de datos. Hay que destacar además que cuando están involucrados algunos tipos de datos (text, ntext, e image) cuyas modificaciones no se registran en el registro de transacciones [Mic01] y por lo tanto es necesario transportar estos datos del publicador al suscriptor para lo cual es necesario utilizar la replicación de instantáneas, al menos como una solución parcial.

Con la opción de actualización inmediata en el suscriptor se permite a los suscriptores actualizar datos solamente si el publicador los va a aceptar inmediatamente. Si el publicador los acepta, se propagan a otros suscriptores. El suscriptor debe estar conectado de forma estable y continua al publicador para poder realizar cambios en el suscriptor. Esta opción es útil en escenarios en los que tienen lugar unas cuantas modificaciones ocasionales en los servidores suscriptor.

En la ilustración siguiente se muestran los componentes principales de la replicación de instantáneas.

|

Replicación transaccional

En este caso se propaga una instantánea inicial de datos a los suscriptores, y después, cuando se efectúan las modificaciones en el publicador, las transacciones individuales se propagan a los suscriptores. SQL Server 2000 almacena las transacciones que afectan a los objetos replicados y propaga esos cambios a los suscriptores de forma continua o a intervalos programados. Al finalizar la propagación de los cambios, todos los suscriptores

|

tendrán los mismos valores que el publicador. Suele utilizarse cuando: se desea que las modificaciones de datos se propaguen a los suscriptores, normalmente pocos segundos después de producirse; se necesita que las transacciones sean atómicas, que se apliquen todas o ninguna al suscriptor; los suscriptores se conectan en su mayoría al publicador; su aplicación no puede permitir un periodo de latencia largo para los suscriptores que reciban cambios.

Es útil en escenarios en los que los suscriptores pueden tratar a sus datos como de sólo lectura, pere necesitan cambios a los datos con una cantidad mínima de latencia. Ejemplo: un sistema para el procesamiento y distribución de pedidos. En este tipo de escenario, podría tener varios publicadores recibiendo pedidos de mercancías. Estos pedidos se replican entonces a un almacén central donde se despachan los pedidos. El almacén puede tratar los datos como de sólo lectura y requiere nueva información en forma periódica.

Con el uso de la opción de atualización inmediata en el suscriptor se pierde aún más la autonomía de sitio, pero se reduce el tiempo en el cual los sitios actualizan sus copias de los datos. Para hacer modificaciones en la base de datos del suscriptor éstas se realizan (o intentan) también en la base de datos publicador en una confirmación de dos fases (2PC) por lo que si su modificación se confirma indica que es válida y luego en cuestión de minutos, o según la planificación hecha, estos cambios son duplicados a las demás bases de datos suscriptoras.

En la siguiente ilustración se muestran los principales componentes de la replicación transaccional.

|

Replicación de mezcla

Permite que varios sitios funcionen en línea o desconectados de manera autónoma, y mezclar más adelante las modificaciones de datos realizadas en un resultado único y

|

uniforme. La instantánea inicial se aplica a los suscriptores; a continuación SQL Server 2000 hace un seguimiento de los cambios realizados en los datos publicados en el publicador y en los suscriptores. Los datos se sincronizan entre los servidores a una hora programada o a petición. Las actualizaciones se realizan de manera independiente, sin protocolo de confirmación, en más de un servidor, así el publicador o más de un suscriptor pueden haber actualizado los mismos datos. Por lo tanto, pueden producirse conflictos al mezclar las modificaciones de datos. Cuando se produce un conflicto, el Agente de mezcla invoca una resolución para determinar qué datos se aceptarán y se propagarán a otros sitios. Es útil cuando: varios suscriptores necesitan actualizar datos en diferentes ocasiones y propagar los cambios al publicador y a otros suscriptores; los suscriptores necesitan recibir datos, realizar cambios sin conexión y sincronizar más adelante los cambios con el publicador y otros suscriptores; el requisito de periodo de latencia de la aplicación es largo o corto; la autonomía del sitio es un factor crucial.

Es útil en ambientes en los que cada sitio hacen cambios solamente en sus datos pero que necesitan tener la información de los otros sitios. Por ejemplo podría crearse una base de datos que registre la historia delictiva de individuos. En cada municipio de Villa Clara, se puede tener una copia de la base de datos de toda la provincia y no se requiere estar conectado permanentemente a la base de datos de la instancia provincial.

|

En el siguiente diagrama se muestran los componentes que se utilizan en la replicación de mezcla.

Factores para elegir el método de replicación a utilizar

|

En la elección de un método adecuado para la distribución de los datos en una organización influyen varios factores. Los cuales podemos agruparlos en dos grupos: factores relacionados con los requerimientos de la aplicación y factores relacionados con el entorno de red.

Dentro de los factores relacionados con los requerimientos de la aplicación, los fundamentales son:

Autonomía Consistencia transaccional Latencia

La autonomía de un sitio da la medida de cuanto puede operar el sitio desconectado de la base de datos publicadora. La consistencia transaccional de un sitio viene dado por la necesidad de ejecutar o no inmediatamente todas las transacciones que se han ejecutado en el servidor, o si es suficiente con respetar el orden de las mismas. La latencia de un sitio se refiere al momento en que se deben de sincronizar las copias de los datos. ¿Necesitan los datos estar el 100% en sincronía? O si es admisible determinada latencia ¿de qué tamaño es aceptable el rezago? [Gar99].

Entre los factores relacionados con el entorno de red están la velocidad de transmisión de datos de la red, deben considerarse preguntas como ¿Cómo luce la red? ¿Es rápida? Debe analizarse además la confiabilidad de la red y responder preguntas como ¿Cuán confiable es la red? Por otra parte en el caso que los servidores SQL no permanezcan todo el día encendidos, como pudiera suceder en algunas organizaciones, deben considerarse los horarios de disponibilidad de cada servidor.

La consideración de estos factores sirven de guía en la configuración del ambiente de replicación. Además debe considerar las siguientes preguntas: ¿Qué datos se van a publicar? ¿Reciben todos los suscriptores todos los datos o sólo subconjuntos de ellos? ¿Se deben particionar los datos por sitio? ¿Se debe permitir que los suscriptores envíen actualizaciones de los datos? Y en caso de permitirlas ¿Cómo deben implementarse? ¿Quiénes pueden tener acceso a los datos? ¿Se encuentran estos usuarios en línea? ¿Se encuentran conectados mediante enlaces caros?

Configurar la replicación con la creación de reflejo de la base de datos

|

La configuración de la replicación y la creación de reflejo de la base de datos implican cinco pasos. Cada paso se describe en detalle en la siguiente sección.

1. Configurar el publicador2. Configurar la creación de reflejo de la base de datos3. Configurar la entidad reflejada de manera que utilice el mismo distribuidor que la

entidad de seguridad4. Configurar los agentes de replicación para la conmutación por error5. Agregar las entidades de seguridad y reflejada al Monitor de replicación

El orden de los pasos 1 y 2 se puede invertir.

Para configurar la creación de reflejo de la base de datos para una base de datos de publicación

1. Configure el publicador:

a. Se recomienda el uso de un distribuidor remoto. Para obtener más información acerca de cómo configurar la distribución.

b. Se puede habilitar una base de datos para publicaciones transaccionales y de instantáneas y/o para publicaciones de combinación. Para las bases de datos reflejadas que incluirán más de un tipo de publicación, se debe habilitar la base de datos para ambos tipos en el mismo nodo usando sp_replicationdboption. Por ejemplo, puede ejecutar el siguiente procedimiento almacenado en la entidad de seguridad:

c. exec sp_replicationdboption @dbname='<PublicationDatabase>', @optname='publish', @value=true

d. exec sp_replicationdboption @dbname='<PublicationDatabase>', @optname='mergepublish', @value=true

2. Configurar la creación de reflejo de la base de datos

3. Configurar la distribución para la entidad reflejada.Indique el nombre de la entidad reflejada como el publicador y especifique el mismo distribuidor y la misma carpeta de instantáneas que se utilizan en la entidad de seguridad. Por ejemplo, si está configurando la replicación con procedimientos almacenados, ejecute sp_adddistpublisher en el distribuidor y, a continuación, ejecute sp_adddistributor en la entidad reflejada. Para sp_adddistpublisher:

o Establezca el valor del parámetro @publisher en el nombre de red de la entidad reflejada.

|

o Establezca el valor del parámetro @working_directory en la carpeta de instantáneas que se utiliza en la entidad de seguridad.

4. Especifique el nombre de la entidad reflejada para el parámetro de agente

PublisherFailoverPartner. Este parámetro es necesario para que los siguientes agentes identifiquen la entidad reflejada después de una conmutación por error:

o Agente de instantáneas (para todas las publicaciones)o Agente de registro del LOG (para todas las publicaciones transaccionales)o Agente de lectura de cola (para las publicaciones transaccionales que

admiten suscripciones de actualización en cola)o Agente de mezcla (para suscripciones de mezcla)o Escucha de replicación de SQL Server (replisapi.dll: para suscripciones de

mezcla sincronizadas mediante sincronización web)o Control ActiveX de mezcla de SQL (para suscripciones de mezcla

sincronizadas con el control)El Agente de distribución y el Control ActiveX de distribución de SQL no tienen este parámetro porque no se conectan al publicador.Los cambios en los parámetros del agente tendrán efecto la próxima vez que se inicie el agente. Si el agente se ejecuta sin interrupción, debe detener y reiniciar el agente. Los parámetros se pueden especificar en perfiles de agente y desde el símbolo del sistema. Para obtener más información.

Se recomienda agregar el parámetro –PublisherFailoverPartner a un perfil de agente y, a continuación, especificar el nombre de la entidad reflejada en el perfil. Por ejemplo, si configura la replicación con procedimientos almacenados:

-- Execute sp_help_agent_profile in the context of the distribution database to get the list of profiles.-- Select the profile id of the profile that needs to be updated from the result set.-- In the agent_type column returned by sp_help_agent_profile: -- 1 = Snapshot Agent; 2 = Log Reader Agent; 3 = Distribution Agent; 4 = Merge Agent; 9 = Queue Reader Agent.

exec sp_help_agent_profile;

-- Setting the -PublisherFailoverPartner parameter in the default Snapshot Agent profile (profile 1).-- Execute sp_add_agent_parameter in the context of the distribution database.exec sp_add_agent_parameter @profile_id = 1, @parameter_name = N'-PublisherFailoverPartner', @parameter_value = N'<Failover Partner Name>';

|

-- Setting the -PublisherFailoverPartner parameter in the default Merge Agent profile (profile 6).-- Execute sp_add_agent_parameter in the context of the distribution database.exec sp_add_agent_parameter @profile_id = 6, @parameter_name = N'-PublisherFailoverPartner', @parameter_value = N'<Failover Partner Name>';

5. Agregue las entidades de seguridad y reflejada al Monitor de replicación.

|

Conclusiones:

La replicación de datos consiste en el transporte de datos entre dos o más servidores, permitiendo que ciertos datos de la base de datos estén almacenados en más de un sitio, y así aumentar la disponibilidad de los datos y mejorar el rendimiento de las consultas globales. El modelo de replicación está formado por: publicador, distribuidor, suscriptor, publicación, artículo y suscripción; y varios agentes responsabilizados de copiar los datos entre el publicador y el suscriptor. A los tipos básicos de replicación (de instantáneas, transaccional y de mezcla), se le incorporan opciones para ajustarse aún más a los requerimientos del usuario.

La replicación es muy útil para mejorar la disponibilidad de datos, lo cual pudiera llevarse al caso extremo, conocido como bases de datos distribuidas replicadas totalmente, en el cual consiste en la replicación de la base de datos completa en cada sitio en el sistema distribuido y garantiza notablemente la disponibilidad de datos, pues el sistema puede continuar operando cuando exista en servicio al menos uno de los servidores SQL Server. La desventaja es un alto costo para mantener la consistencia de las copias en cada sitio.

Bibliografía.

1. W. Curtis Preston

|

file:///D:/traajo%20de%20base%20de%20datos/Buenas%20pr%C3%A1cticas%20de%20replicaci%C3%B3n%20de%20datos%20para%20safeguard.htm

2. Conceptos Universalesfile:///D:/traajo%20de%20base%20de%20datos/Replicaci%C3%B3n%20(inform%C3%A1tica)%20-%20Wikipedia,%20la%20enciclopedia%20libre.htmWIKIPEDIA.ORGhttp://es.wikipedia.org/w/index.php?title=Replicaci%C3%B3n_(inform%C3%A1tica)&oldid=70871534BOAWEB.COMfile:///D:/traajo%20de%20base%20de%20datos/Replicaci%C3%B3n%20de%20Datos%20%20%20DBMoto.htm

HITSW.COMhttp://www.hitsw.com/localized/spanish/products_services/dbmoto/dbmoto.html#IMÁGENESfile:///D:/traajo%20de%20base%20de%20datos/REPLICACION%20DE%20DATOS%20-%20Buscar%20con%20Google.htm

3. Tipos de replicación MONOGRAFIAS.COMfile:///D:/traajo%20de%20base%20de%20datos/Replicaci%C3%B3n%20de%20Datos%20en%20SQL%20Server%20-%20Monografias.com.htm

4. Configurar la replicación con la creación de reflejo de la base de datosSQL SERVERfile:///D:/traajo%20de%20base%20de%20datos/Replicaci%C3%B3n%20de%20SQL%20Server.htm

5. Factores para elegir el método de replicación a utilizarfile:///D:/traajo%20de%20base%20de%20datos/Replicaci%C3%B3n%20de%20SQL%20Server.htmSQL SERVERhttp://technet.microsoft.com/es-es/library/bb500342.aspxSQL SERVER TIPOS DE REPLICACIONEShttp://technet.microsoft.com

www.scribd.com

|