Definición del problema

Nuestros usuarios necesitan la capacidad de consultar una base de datos que está principalmente actualizada. Los datos pueden estar obsoletos hasta 24 horas y eso es aceptable. ¿Cuál sería el enfoque de menor costo para obtener y mantener una segunda base de datos actualizada con una copia de producción? ¿Hay un enfoque en el que no estoy pensando?

Carga de trabajo

Tenemos una aplicación de terceros que utilizamos para monitorear la actividad de negociación de acciones. Durante el día, ocurren muchos pequeños cambios como parte de varios flujos de trabajo (sí, este intercambio fue válido. No, esto es sospechoso, etc.). Por la noche, realizamos operaciones basadas en conjuntos grandes (cargamos las operaciones del día anterior).

La solución actual y el problema

Hacemos uso de instantáneas de bases de datos . A las 10 p. M., Soltamos y recreamos la instantánea. Entonces comienza el procesamiento de ETL. Obviamente, esto es gravoso para nuestro disco, pero permite a nuestros usuarios la posibilidad de consultar la base de datos sin bloquear la base de datos (usan un front-end de Access). Lo usan hasta altas horas de la noche y temprano en la mañana para que noten el tiempo de inactividad.

El problema con este enfoque es doble. La primera es que, en caso de que falle el procesamiento nocturno, y eso no es terriblemente raro, podemos restaurar la base de datos que da como resultado la caída de la instantánea. El otro problema es que nuestros tiempos de procesamiento están pasando por nuestro SLA. Estamos tratando de abordar esto trabajando con el proveedor después de haber identificado las consultas mal escritas y la falta de indexación. La instantánea de la base de datos también es un culpable de esta desaceleración, como lo demuestra la diferencia de velocidad cuando está presente versus no --- impactante, lo sé.

Enfoques considerados

Agrupamiento

Teníamos la agrupación de bases de datos activada, pero eso no abordaba las necesidades de hacer que los datos estuvieran disponibles y, en general, complicaba la vida del administrador. Desde entonces se ha apagado.

Replicación de SQL Server

Comenzamos a mirar la replicación la semana pasada. Nuestra teoría es que podemos obtener un segundo catálogo de pie y sincronizado con la base de datos de producción. Antes del inicio de ETL, cortaremos la conexión y solo la volveremos a habilitar una vez que el proceso de ETL se haya completado.

El administrador comenzó con la replicación de instantáneas, pero le preocupa que tarde varios días de uso elevado de la CPU para generar la instantánea, así como el consumo de disco requerido. Indica que parece escribir todos los datos en archivos físicos antes de enviarlos al suscriptor, por lo que nuestra base de datos de .6TB costará 1.8TB en costos de almacenamiento. Además, si tomará varios días generar un complemento, entonces no encajaría en el SLA deseado.

Después de leer el buen artículo, parece que Snapshot podría ser la forma de inicializar a los suscriptores, pero luego nos gustaría cambiar a Replicación transaccional para mantenerlo sincronizado después de eso. ¿Asumo que activar / desactivar la replicación transaccional no forzará una reinicialización completa? De lo contrario, volaremos nuestra ventana de tiempo

Reflejo de base de datos

Nuestra base de datos está en modo de recuperación COMPLETA, por lo que la duplicación de la base de datos es una opción, pero sé aún menos que la replicación. Encontré la respuesta SO que indicaba que "La creación de reflejo de la base de datos impide el acceso directo a los datos, los datos reflejados solo son accesibles a través de una instantánea de la base de datos".

Envío de registro

Parece que el envío de registros también podría ser una opción, pero esta es otra de esas cosas de las que no sé nada. ¿Sería una solución de menor costo (implementación y mantenimiento) que cualquier otra cosa? Según el comentario de Remus "El envío de registros permite el acceso de solo lectura a la copia de la réplica, pero desconectará a todos los usuarios al aplicar el siguiente registro de respaldo recibido (por ejemplo, cada 15-30 minutos)". No estoy seguro de cuánto tiempo se traduciría ese tiempo de inactividad, lo que podría causar cierta angustia a los usuarios.

MS Sync

Solo escuché sobre el uso de Sync el pasado fin de semana y aún no lo he investigado. Odiaría presentar una nueva tecnología para algo con alta visibilidad como este problema, pero si es el mejor enfoque, que así sea.

SSIS

Hacemos mucho SSIS aquí, por lo que generar unos cientos de paquetes SSIS para mantener el secundario sincronizado es una opción para nosotros, aunque fea . No soy fanático de hacer esto, ya que es una gran cantidad de gastos generales de mantenimiento, prefiero que mi equipo no asuma.

Instantánea "mágica" de SAN

En el pasado, escuché que nuestros administradores usan tecnología SAN para hacer copias de seguridad instantáneas de discos completos. Quizás haya algo de magia EMC que pueda usarse para hacer copias súper rápidas de mdf / ldf y luego podamos separar / adjuntar la base de datos de destino.

Copia de seguridad y restaurar

Creo que hacemos copias de seguridad completas una vez por semana, diferenciales todas las noches y tlog cada 15 minutos. Si los usuarios pudieran vivir con la interrupción de 3-4 horas para la restauración completa, supongo que esto podría ser un enfoque.

Restricciones

Windows 2008 R2, SQL Server 2008 R2 (Enterprise Edition), VMWare v5 Enterprise Edition, almacenamiento SAN EMC con unidades asignadas a archivos vmdk, copias de seguridad de manejo de comunicaciones y .6TB de datos en el catálogo de origen. Esta es una aplicación de terceros que alojamos internamente. Modificar su estructura generalmente está mal visto. Los usuarios no pueden ir sin consultar la base de datos y se niegan a verse limitados mediante la identificación proactiva de las tablas que supervisan para realizar su trabajo.

Our DBAs are purely contractors at the moment. The full-timers have set sail and we have not replaced them yet. The application admins are not well versed on SQL Server matters and we have a team of Storage/VM admins that could help/hinder this effort. Development teams are not currently involved but can be enlisted based on the approach. So a simpler to implement and maintain solution would be preferable.

Yo estoy en el lado del desarrollo de la hosue, así que solo puedo proponer enfoques y no he tenido que lidiar con el lado administrativo de las cosas. Entonces, sin tiempo en la silla de administrador, dudo en decir que un enfoque sería superior a otro --- todo se ve muy bien según los documentos. Estoy totalmente dispuesto a correr en cualquier dirección que sugieran porque, según lo veo, solo me hará más valioso como profesional de DB. Tengo una carretilla pero no tengo capa de holocausto disponible .

Preguntas relacionadas

• /programming/525637/what-are-the-scenarios-for-using-mirroring-log-shipping-replication-and-cluste

• /programming/434982/mirroring-vs-replication

• /programming/4303020/sync-databases-mirroring-replication-log-shipping

• /programming/4303020/sync-databases-mirroring-replication-log-shipping

• http://nilebride.wordpress.com/2011/07/24/log-shipping-vs-mirroring-vs-replication/

Ediciones

Para responder a las preguntas de @ onnt

Aceptación de latencia de datos

Los usuarios actualmente ven datos que tienen hasta 24 horas de retraso. Los datos solo están actualizados a partir de 2200

Cantidad de cambio de datos en un minuto, hora y día determinados No estoy seguro de cómo cuantificar eso. Horario comercial, tal vez cientos de cambios por hora. Procesamiento nocturno, millones de filas por día hábil

Conectividad al secundario

Red interna, host virtual separado y almacenamiento dedicado

Leer requisitos en la instancia secundaria

El grupo de Windows tendrá acceso de lectura a la secundaria, todas las tablas

Tiempo de actividad de la instancia secundaria

No existe una definición sólida de un requisito de tiempo de actividad. Los usuarios quieren que esté siempre disponible, pero están dispuestos a pagar por eso, probablemente no tanto. Siendo realistas, diría que bastarían 23 horas al día.

Alteraciones al esquema existente y a todos los objetos.

Modificaciones poco frecuentes, tal vez una vez por trimestre para objetos de tabla. Tal vez una vez al mes para objetos de código.

Seguridad

No hay necesidades especiales de seguridad. Los permisos de producción coincidirían con los permisos de la copia. Aunque, según lo pienso, podríamos revocar el acceso de lectura de los usuarios a prod y solo permitirles leer la copia ... Sin embargo, no es un requisito.

@ estrecho mandarín

Revertir a la instantánea podría ser una opción, pero creo que hubo alguna razón por la que no lo persiguieron. Lo consultaré con el administrador

@cfradenburg

Supuse que solo usaríamos uno de estos enfoques, pero ese es un buen punto para que las restauraciones rompan las "otras" tecnologías de sincronización. Están investigando cómo usar la magia de instantáneas de EMC. Como lo describió el administrador, tomarían una instantánea en 1900 y migrarían la imagen a la zona de la secundaria. Eso debería completarse para el 2200 y luego realizarían una separación y una nueva conexión de la base de datos secundaria.

Envolver

2012-10-29 Evaluamos la magia de instantáneas de EMC y algunas otras opciones de replicación, pero los DBA decidieron que podrían resolver mejor la duplicación. Voté las respuestas porque todas me ayudaron y me dieron muchas opciones, así como "tarea" para investigar.

Modificar su estructura generalmente está mal visto

Es más que probable que se produzca la replicación y yo descartaría la sincronización antes de eso. (de pruebas transacitonales altas de la vida real en Sync Framework)

Si 3-4 horas es su excepción de latencia de datos, el envío de registros probablemente será su mejor apuesta aquí en una copia de solo lectura. Pero, ¿cuánto cambio está ocurriendo en el registro? descubra que debe monitorearlo para ver qué tan rápido y cuánto necesita avanzar.

Si no puede ir a Mirroring o actualizar a 2012 Enterprise, eso está fuera, aunque sería una buena estrategia si puede ir a Enterprise si no está en él.

SSIS no pretende simplemente volcar datos, sino que puede hacerlo. Sin embargo, está observando demasiado en términos de transformaciones de búsqueda y la tarea sería costosa en tiempo y recursos. Aunque, como dije, puede hacerlo.

Realmente, habrá un estrechamiento distintivo de opciones basado en responder algunas preguntas

• Aceptación de latencia de datos
• Cantidad de cambio de datos en un minuto, hora y día determinados Conectividad al secundario
• Leer requisitos en la instancia secundaria
• Tiempo de actividad de la instancia secundaria
• Alteraciones al esquema existente y a todos los objetos.
• Seguridad

Esta será una de esas cosas que debes probar por ti mismo para encontrar lo que funciona mejor. La replicación puede ser complicada, por lo que si bien puede que no haya un costo monetario directo, habrá gastos generales administrativos para mantenerla.

Para ampliar el envío de registros, no necesita restaurar los registros cada 15-30 minutos. Si lo desea, puede hacerlo cada cuatro horas o una vez al día. Una solución similar a la que he implementado es hacer una copia de seguridad completa semanal y restaurarla a una base de datos de informes (que puede llevar un tiempo y ocurre el fin de semana). Durante la semana se realizan copias de seguridad diferenciales y se restauran todas las noches a la base de datos de informes. Los usuarios deben iniciarse antes de la restauración, pero dado que la base de datos de informes es una aplicación de horario comercial, no hay problema con eso. Los datos tienen un día de antigüedad, lo que no debería ser un problema en función de sus requisitos.

Para usar la creación de reflejo de la base de datos para esto, necesitaría comprar Enterprise para poder usar instantáneas si aún no está ejecutando Enterprise. Tampoco mantendría los datos 100% actualizados, ya que la instantánea debe eliminarse (lo que significa que todos los usuarios deben estar fuera) y luego volver a crearse para obtener los nuevos datos. Sin embargo, esto sería menos tiempo que las restauraciones de registros o el método que expliqué anteriormente.

Si la actualización a SQL 2012 es una opción, es posible configurar un secundario de solo lectura que se mantendrá actualizado con la base de datos primaria. Solo menciono esto porque es probable que sea la solución más fluida.

Por mucho que la gente se moleste con la replicación transaccional, parece una buena opción para su situación. Un par de notas:

1. No tiene que inicializar el suscriptor con una instantánea. Puede hacer una copia de seguridad del editor e inicializar con eso.
2. Puede pausar la entrega de comandos al suscriptor simplemente deteniendo el trabajo de distribución (es solo un trabajo normal del Agente SQL, ya sea en el distribuidor o en el suscriptor, dependiendo de si lo configuró como una suscripción push o pull, respectivamente). Solo tenga en cuenta su retención en el distribuidor de modo que tenga suficiente historial para poder ponerse al día.
3. Puede cambiar la indexación en el suscriptor para acomodar las cargas de trabajo que se realizarán allí (presumiblemente de tipo informe) en lugar de tener que aceptar la indexación de su editor (presumiblemente de tipo OLTP) si lo desea.