¡Acceso ilimitado 24/7 a todos nuestros libros y vídeos! Descubra la Biblioteca Online ENI. Pulse aquí
¡Acceso ilimitado 24/7 a todos nuestros libros y vídeos! Descubra la Biblioteca Online ENI. Pulse aquí
  1. Libros
  2. SQL Server 2016
  3. Replicación
Extrait - SQL Server 2016 Aprender a administrar una base de datos transaccional con SQL Server Management Studio
Extractos del libro
SQL Server 2016 Aprender a administrar una base de datos transaccional con SQL Server Management Studio Volver a la página de compra del libro

Replicación

Presentación

La replicación es una poderosa funcionalidad de SQL Server que permite distribuir datos y ejecutar los procedimientos almacenados sobre varios servidores de la empresa. La tecnología de replicación ha evolucionado considerablemente y ahora permite copiar, trasladar los datos a diferentes lugares y sincronizarlos automáticamente. La replicación puede establecerse entre las bases de datos residentes sobre el mismo servidor o sobre servidores diferentes. Los servidores pueden estar sobre una red local (LAN) o global (WAN) o sobre Internet.

SQL Server distingue dos grandes categorías de replicación:

  • La replicación de servidor a servidor.

  • La replicación de servidor a clientes.

En el caso de replicación de servidor a servidor, la replicación permite una mayor integración o aproximación de los datos entre varios servidores de base de datos. El objetivo de este tipo de replicación es efectuar un intercambio de información entre servidores de base de datos. Los usuarios que trabajan sobre las bases de datos que participan en la replicación pueden, de esta manera, consultar datos de mayor calidad.

La replicación de servidor a cliente afecta principalmente a los usuarios desconectados de la red de la empresa que desean trabajar con todos los datos de la empresa o parte de ellos. Los usuarios trabajan con una aplicación específica...

Las necesidades para la replicación

La replicación es una tecnología compleja y no puede existir una solución única para cubrir todas las necesidades. SQL Server ofrece diferentes tecnologías de replicación que se pueden adaptar y combinar para responder lo más fielmente posible a las necesidades de las aplicaciones. Cada tecnología tiene ventajas e inconvenientes. Los tres criterios principales para seleccionar una tecnología de replicación son:

  • La coherencia de los datos replicados.

  • La autonomía de los sitios.

  • El particionamiento de datos para evitar conflictos.

No es posible optimizar los tres criterios al mismo tiempo, de manera que una solución que favorezca la coherencia de los datos deberá dejar poca autonomía a los sitios para averiguar en todo momento el conjunto de modificaciones que tienen lugar sobre los datos.

1. Coherencia de los datos replicados

Existen dos tipos principales de coherencia:

  • La homogeneidad de las transacciones.

  • La convergencia de los datos.

La coherencia de las operaciones distribuidas, como la replicación, es mucho más complicada de mantener en comparación con la coherencia de las transacciones locales, por lo que es suficiente con respetar el test ACID (Atomicidad, Coherencia, Aislamiento y Durabilidad).

La homogeneidad de las transacciones en la replicación obliga a que los datos sean idénticos en todos los sitios que participan en la replicación, como si la transacción fuera a ejecutarse sobre todos los sitios.

La convergencia de los datos significa que todos los sitios que participan en las replicaciones deben tener el mismo juego de datos, que no es necesariamente el que se obtendría si todas las replicaciones se hubieran desarrollado sobre el mismo servidor.

a. Coherencia de las transacciones

En todos los casos, los sitios contienen un juego de valores idéntico a aquel sobre el que han hecho o se podían haber hecho todas las operaciones de modificación.

Coherencia transaccional inmediata

Con esta coherencia, todos los sitios que participan en la replicación tienen...

Los modelos de replicación

En SQL Server, los diferentes modelos de replicación utilizan la metáfora «editor-suscriptor» para diseñar lo mejor posible dichos modelos.

1. Los principales componentes

a. El editor

Igual que un editor de libros o periódicos, un servidor editor pone a disposición de los otros servidores los datos para instalar la replicación.

El editor conserva todos los datos publicados (los que participan en la replicación) y mantiene al día las modificaciones realizadas sobre estos datos. Para los datos publicados, el editor es siempre único.

images/08EC07.png

b. El distribuidor

Se trata del servidor SQL que contiene la base de distribución; es decir, aquella que contiene toda la información utilizada por los suscriptores para tener actualizados los datos que incluyen.

Estos dos roles pueden ser realizados por la misma máquina.

images/08EC08.png

c. Los suscriptores

Son los servidores SQL los que almacenan una copia de la información publicada y después reciben las modificaciones de estos datos. En las versiones 6.x de SQL Server, no era posible modificar los datos sobre los suscriptores. Ahora es posible modificar los datos publicados sobre el suscriptor. Un suscriptor puede convertirse en editor para otros suscriptores.

Igual que en una revista, los suscriptores deben contar con una suscripción para recibir los datos publicados. Existen dos tipos de suscripción:

Suscripción enviada

En este caso, es el distribuidor el que se encarga de enviar la actualización de los datos distribuidos a todos los suscriptores. Este tipo de suscripción es especialmente adecuada cuando el tiempo de actualización de los suscriptores debe reducirse al mínimo.

Con las suscripciones enviadas, los suscriptores pueden ser bases de datos diferentes de SQL Server, como Oracle, por ejemplo.

Suscripción de extracto

Es el suscriptor el que decide suscribirse o no. Es, por tanto, el suscriptor el que va a solicitar regularmente actualizaciones. Este tipo de suscripción resulta muy adecuado cuando los suscriptores son muy numerosos, ya que la carga de trabajo del servidor distribuidor será muy importante. Las suscripciones de extracto también se adaptan bien a los usuarios poco asiduos, ya que cuando el usuario se conecta a la red de la empresa es su propio servidor el que solicita la actualización...

Planificación

La implementación de la replicación necesita una planificación rigurosa de las tareas que hay que realizar con el fin de utilizar lo mejor posible los recursos proporcionados por SQL Server, reduciendo los recursos materiales (tiempo de CPU, red) utilizados por la replicación.

1. Opciones generales de planificación

a. Opción NOT FOR REPLICATION

La opción NOT FOR REPLICATION permite definir un comportamiento diferente de las opciones cuando el tratamiento se hace en el marco de la replicación. Esta opción es posible sobre:

  • Las columnas de tipos identity.

  • Las restricciones de validación (CHECK).

  • Las restricciones de clave extranjera (FOREIGN KEY).

  • Los triggers de base de datos.

b. Tipo de datos uniqueidentifier

El tipo de datos uniqueidentifier se utiliza con la columna ID y con la función NEWID(), que permite generar un nuevo ID para cada nueva línea.

Ventajas de GUID:

  • GUID es siempre única y de esta manera se evitan numerosos conflictos.

  • El número de GUID no está limitado, contrariamente a los identificadores.

Sin embargo, esta opción no es interesante cuando los usuarios no ven o no utilizan los valores de GUID. Efectivamente, los valores de tipo uniqueidentifier presentan inconvenientes que no pueden pasarse por alto al poner en marcha una aplicación.

  • La manipulación por un usuario es complicada (formato demasiado largo).

  • Los valores son aleatorios y no tienen ningún sentido.

  • Los valores uniqueidentifier no están necesariamente disponibles para las aplicaciones existentes, que se construyen a partir de valores de identificadores incrementales.

En resumen, es posible precisar que los valores de tipo uniqueidentifier se adaptan bien cuando son utilizados directamente por SQL Server o por la aplicación, ya que permiten manejar un identificador único, pero su manejo por parte del usuario final es difícil. Estos valores son muy utilizados en el proceso de replicación para el almacenamiento interno de la información.

c. Filtrado de los datos

Por defecto, cuando una tabla participa en una publicación, la totalidad de los datos que contiene se replica sobre los puestos remotos. Sin embargo, los puestos remotos no tienen obligatoriamente necesidad de conocer la totalidad de los valores. Algunas veces solo les interesa un subconjunto de líneas o de columnas....

El acceso a la red

Para que el proceso de replicación se desarrolle sin problemas, se deben satisfacer algunas condiciones elementales sobre el acceso a la red:

  • Si los servidores SQL que participan en la replicación están en dominios diferentes, se deben establecer relaciones de aprobación entre estos dominios.

  • El agente SQL Server debe ejecutarse en el contexto de una cuenta de usuario del dominio. Si es posible, el agente SQL Server de los diferentes servidores SQL que participan en la replicación utiliza siempre la misma cuenta de usuario. Esta cuenta de usuario de dominio debe ser miembro del grupo local de administradores para que SQLServerAgent se beneficie de los privilegios administrativos.

Es posible averiguar y modificar la configuración de este servicio por medio de SQL Server Configuration Manager.

images/75-confManagerserviceprop.png

Verificación de las propiedades del agente SQL Server

El agente SQL Server no debe utilizar ni una cuenta local system ni una cuenta de usuario local, ya que estas dos cuentas no permiten acceder a los recursos de la red.

Puesta en marcha

Independientemente de cuál sea el modelo y el tipo de replicación elegidos, la puesta en marcha de esta técnica siempre debe seguir las mismas etapas:

  • La puesta en marcha del distribuidor.

  • La puesta en marcha del editor.

  • La puesta en marcha de los suscriptores.

  • La definición de las publicaciones.

Como SQL Server considera por defecto que el editor y el distribuidor residen en el mismo servidor, la instalación de estos dos componentes se mezcla.

Para poder poner en marcha la replicación a partir de SQL Server Management Studio, todos los servidores SQL que participan en la replicación deben estar inscritos en ella.

SQL Server Management Studio ofrece diferentes asistentes gráficos para instalar, vigilar y parametrizar el entorno de replicación. Se accede a todos estos elementos desde el nodo Replication del explorador de objetos de SQL Server Management Studio. 

images/76-replication.png

1. El distribuidor

Se trata del puesto que va a gestionar el directorio compartido para la captura instantánea, así como la base de distribución. El distribuidor almacena las modificaciones efectuadas sobre los datos y los transmite a los suscriptores.

a. Conceptos

El distribuidor debe estar instalado antes de establecer los editores que lo utilizan. Para crear un distribuidor, es necesario ser administrador del sistema (miembro del grupo local Administradores y conectarse a SQL Server como administrador a través de las conexiones aprobadas). Una vez que el distribuidor esté instalado, es posible conocer sus propiedades locales y remotas.

La base de datos de distribución

Contiene todas las transacciones que están a la espera de ser enviadas hacia los suscriptores. En el marco de una replicación transaccional, es alimentada por el agente de vigilancia del diario que transfiere a ella todas las transacciones que intervienen sobre los datos replicados. Esta base se crea automáticamente durante la configuración del distribuidor, pero es posible:

  • Especificar un servidor de distribución remoto durante la instalación del editor.

  • Definir varias bases de distribución para un mismo editor.

Acceso al directorio compartido

El directorio de distribución, utilizado por la replicación de captura instantánea, debe estar disponible para todos los agentes de distribución que sean capaces de utilizarlo. Su uso depende...

El acceso a los datos remotos

SQL Server permite a un usuario conectado localmente ejecutar una consulta sobre un servidor remoto. Este proceso se basa en la unión entre los servidores. Cuando la unión se establece entre dos servidores, el servidor que recibe por parte de alguno de sus usuarios una petición de ejecución de una consulta sobre otro servidor transmite la consulta al servidor remoto.

En el esquema siguiente, un usuario conectado a servidor1 puede solicitar la ejecución de una consulta sobre servidor2 sin tener que conectarse a servidor2. Efectivamente, como los dos servidores están asociados, es servidor1 el que se encarga de ejecutar la consulta sobre servidor2.

images/08ec327.png

La ventaja de los servidores asociados radica en que es el servidor el que se encarga de la conexión sobre el servidor remoto. Esta operación es transparente para el usuario final.

Antes de poder trabajar con un servidor asociado, es necesario inscribirlo sobre el servidor local y después definir una política de gestión de las conexiones establecidas sobre el servidor asociado.

El concepto de servidores asociados permite a SQL Server establecer una relación de confianza con orígenes OLE DB que tienen la ventaja de acceder a los servidores remotos, emitir las consultas, operaciones de actualización, comandos y transacciones compartidas sobre los orígenes de datos heterogéneos.

1. Añadir...