¿Qué factores objetivos indican que es hora de implementar la replicación de SQL Server?

Estoy tratando de lograr un equilibrio entre el alto rendimiento de nuestra base de datos y la facilidad de mantenimiento. Estamos considerando usar la replicación para mejorar el rendimiento, al replicar nuestros informes SSRS en una base de datos físicamente separada de nuestra base de datos transaccional. Sin embargo, habilitar la replicación tiene una serie de inconvenientes desde el punto de vista del desarrollador:

• Hace que los cambios de esquema sean más difíciles
• Interfiere con nuestro servidor automatizado de integración / compilación
• Parece dificultar la implementación del control de código fuente SQL

Mi pregunta es : ¿Cuándo sabes que es hora de replicar a la luz de estos inconvenientes? ¿Cómo decide si la complejidad adicional justifica las ganancias?

Lo hemos usado antes, por lo que configurarlo no es un problema. Se trata más de tomar la decisión de habilitarla o no. Estoy buscando algunas métricas de rendimiento de objetos que otros han observado con la replicación.

Por supuesto, lo mejor sería hacer algunas pruebas de carga simuladas en nuestros propios servidores y resolverlo nosotros mismos, pero espero que haya algunas pautas generales.

La replicación debe considerarse durante la fase de diseño de la aplicación. Si tiene una fuerza de trabajo / base de usuarios distribuida geográficamente, puede tener sentido tener bases de datos regionales y bases de datos centrales. Las bases de datos desconectadas en las computadoras portátiles pueden "sincronizarse" cuando finalmente se vuelven a conectar con la red (piense en el personal de ventas en el camino).

En cuanto a los informes, la réplica NO es la respuesta. La mayoría de los problemas de rendimiento en un entorno de informes se deben al hecho de que los informes se escriben en un sistema configurado para el procesamiento de transacciones en línea (OLTP).

La replicación con fines informativos es simplemente mover sus datos OLTP a otro servidor, pero mantener la misma estructura amigable con los informes. En esencia, está arrojando más hardware al problema y aumentando sus costos de mantenimiento, pero con ganancias marginales.

Lo que debe observar es cómo obtener los datos específicos que necesitan sus informes y transformarlos en un formato más útil. Cree una fuente que tome nuevas transacciones de su base de datos de producción y la almacene en una base de datos de informes, preferiblemente en un servidor separado. Cada vez que se ejecuta el feed, debe capturar todos los datos que son más nuevos que la última vez que se ejecutó, transformar esos datos y almacenarlos. Los informes que está ejecutando actualmente le darán una buena idea de los tipos de transformaciones requeridas.

Al seguir este enfoque, obtendrá grandes beneficios de rendimiento.

Por lo que vale, hemos encontrado que la replicación es útil en una situación similar porque los redactores de informes pueden "poseer" los índices en la base de datos replicada. Esto nos ha dado la capacidad de mejorar el rendimiento de las consultas al agregar índices que los desarrolladores de aplicaciones nunca habrían aprobado en producción debido a su impacto negativo en INSERTOS y ACTUALIZACIONES.

¿Quizás parte de su caso de uso es copiar algunas tablas transaccionales, cambiar algo de indexación y ver si vale la pena?

¡Espero que esto ayude!