Tablas/bases de datos separadas para informes y operaciones CRUD

Question

Periódicamente, los usuarios que ejecutan informes bloquean a los usuarios que realizan operaciones CRUD y provocan tiempos de espera. Me gustaría crear ubicaciones duplicadas de las tablas actuales para los usuarios del informe.

Estaba pensando en crear un trabajo que haga una copia de seguridad de la base de datos de mi aplicación, y la restaure en una base de datos en el mismo servidor para que los usuarios que ejecutan informes se separen de los que realizan operaciones CRUD. El trabajo se ejecutará cada 10 minutos más o menos. Las pruebas iniciales muestran que el inicio y el final serán de aproximadamente 30 segundos. El espacio en disco no es un problema.

¿Es esta una buena/mala idea? ¿Qué peligros debo tener en cuenta? ¿Hay una mejor manera de hacer esto?

Answer 1

Esto parece una buena idea. La única preocupación que tengo es ¿necesitas actualizar cada 10 minutos? Esto también podría ralentizar las cosas mientras se ejecuta la actualización. Por lo general, estos se hacen de la noche a la mañana (para tener el menor impacto para los demás), o si durante el día, en solo 3 puntos fijos (por ejemplo, 10 a.m., 1 p.m. y 4 p.m.).

Answer 2

Naturalmente para la mayoría de las aplicaciones de clase empresarial, la base de datos de transacciones siempre se mantiene separada de la base de datos de informes. El sistema de transacciones está sintonizado para OLTP y la base de datos de informes puede desnormalizarse para adaptarse a la necesidad de los escenarios de informes. Entonces es casi una sugerencia natural.

Answer 3

Tenga cuidado al realizar copias de seguridad frecuentes, ¡esto podría provocar una gran cantidad de tiempo de inactividad!

soluciones comunes

De hecho, es una práctica común para crear una instancia independiente sólo para la presentación de informes.

Algunas personas incluso van un paso más allá y ponen informes en una máquina física o clúster separado para aislar aún más esa parte de la carga.

Ambos se pueden manejar con replicación (que evita el problema de tiempo de inactividad). O simplemente podría hacer una copia de seguridad nocturna e informar en contra de eso.

También me gustaría mencionar que el enfoque de gama alta es Data Warehousing, donde básicamente se transforma esta nueva base de datos en un repositorio de lectura optimizada que es más eficiente para informar. Eso lleva mucho tiempo implementarlo, por lo que es no la solución rápida que está buscando.

Consideraciones finales

Una última cosa: Yo he visto algunas tiendas en la cúspide de este problema tratan de evitar el trato con él. Aquí está la conclusión: los informes tienden a aumentar en determinados momentos del mes o año, por lo que si normalmente está a punto de matar su servidor de base de datos, la última semana del mes puede empujarlo al límite.

Esta pregunta es muy similar: https://stackoverflow.com/questions/190512/sql-server-separate-database-for-reports

Answer 4

Antes de hacer una actualización costosa, podría ver si la colocación

...from sometable WITH (NOLOCK) 

en sus consultas de información mitiga el problema. Al menos, le puede dar tiempo para descubrir qué es lo óptimo.