Monografias.com > Computación > Programación
Descargar Imprimir Comentar Ver trabajos relacionados

Replicación de Datos en SQL Server




Enviado por dcmorell



    Replicación de Datos en SQL
    Server

    1. Resumen
    2. Componentes del modelo de
      replicación
    3. Escenarios típicos de la
      replicación
    4. Tipos de
      replicación
    5. Factores para elegir el
      método de replicación a
      utilizar
    6. Fases generales para implementar
      y supervisar la replicación
    7. Consideraciones
      finales
    8. Referencias
      Bibliográficas

    Resumen

    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.

    1.
    Introducción

    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 [Mic01].

    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 [Mic01].

    2. 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 [Mic01].

    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
    simultaneamente 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, puede devolver datos modificados al
    publicador. Además puede tener sus propias publicaciones
    [Mic01].

    3. 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.1).
    2. El rol de distribuidor desempeñado por el
      suscriptor (Fig. 1.2)
    3. Un servidor de distribución, independiente del
      publicador y del suscriptor (Fig. 1.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.

    3. 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 [Mic01].

    3.1
    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.

    3.2 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.

    3.3 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.

    4. 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
    [Gar99]:

    • 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 guia 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?

    5. Fases generales para implementar y supervisar
    la replicación

    A pesar de que existen varias formas de implementar y
    supervisar la replicación, y el proceso de
    replicación es diferente según el tipo y las
    opciones elegidas, en general, la replicación se compone
    de las siguientes fases:

    • configuración de la
      replicación
    • generación y aplicación de la
      instantánea inicial
    • modificación de los datos
      replicados
    • sincronización y propagación de los
      datos.

    6. Consideraciones finales

    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
    [Elm00].

    Referencias
    Bibliográficas

    [Elm00] Elmasri, R y Navathe, S. B. Fundamentals of
    database systems. Addison-Wesley, Third Edition,
    2000.

    [Gar99] García, C. Escenario de red para la
    supervisión de fallas en centrales
    telefónicas. Informe
    Final de Tesis de
    Maestría en Computación Aplicada, Universidad
    Central de "Marta Abreu" de Las Villa, Santa Clara,
    1999.

    [Mic01] Microsoft
    Corporation, Libros en
    pantalla de SQL Server, 2001.

     

     

     

     

    Autor:

    Lic. Daniel Eduardo Castro Morell

    Licenciado en Cibernética-Matemática. Profesor Instructor del
    Departamento de Computación. Universidad
    Central "Marta Abreu" de las Villas. Santa Clara. Cuba

    Dr. Ramiro Pérez Váquez

    Doctor en Ciencias
    Técnicas. Profesor Titular del Departamento
    de Computación. Universidad Central "Marta Abreu" de las
    Villas. Santa Clara. Cuba

    Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

    Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

    Categorias
    Newsletter