¿Cómo puedo mantener un esquema de base de datos coherente en 18 bases de datos (servidor SQL)?

Question

Tenemos 18 bases de datos que deberían tener esquemas idénticos, pero no los tienen.En ciertos escenarios, se agregó una tabla a uno, pero no al resto.O bien, se requerían ciertos procedimientos almacenados en unas cuantas bases de datos, pero no en otras.O nuestro administrador de bases de datos se olvidó de ejecutar un script para agregar vistas en todas las bases de datos.

¿Cuál es la mejor manera de mantener sincronizados los esquemas de bases de datos?

Answer 1

Para correcciones/limpieza heredadas, existen herramientas, como SQLComparar, que puede generar scripts para sincronizar bases de datos.

Para tiendas .NET que ejecutan SQL Server, también existe la Edición de base de datos de Visual Studio, que puede crear secuencias de comandos de cambios para cambios de esquema que se pueden registrar en el control de fuente y compilarse automáticamente utilizando su proceso de CI/compilación.

Answer 2

Comparación SQL de Red Gate es una gran herramienta para esto.

Answer 3

SQLComparar es la mejor herramienta que he usado para encontrar diferencias entre bases de datos y sincronizarlas.

Para mantener las bases de datos sincronizadas, necesita tener varias cosas en su lugar:

1) Necesita políticas sobre quién puede realizar cambios en la producción.Por lo general, solo debe ser el DBA (equipo de DBA para organizaciones más grandes) y 1 o 2 respaldos.Las copias de seguridad solo deben realizar cambios cuando el DBA no esté disponible o en caso de emergencia.Las copias de seguridad NO deberían implementarse de forma regular.Establezca los derechos de la base de datos de acuerdo con esta política.

2) Un proceso y herramientas para gestionar las solicitudes de implementación.Lo ideal es que tengas un entorno de desarrollo, un entorno de prueba y un entorno de producción.Los desarrolladores deben realizar el desarrollo inicial en el entorno de desarrollo y enviar los cambios a prueba y producción según corresponda.Necesitará alguna forma de informarle al DBA cuándo impulsar los cambios.NO recomendaría un proceso en el que grites al siguiente cubo.Las organizaciones grandes pueden tener un comité de control de cambios y los cambios solo se realizan una vez al mes.Las empresas más pequeñas pueden simplemente hacer que el desarrollador solicite pruebas y, después de las pruebas, se pasa una solicitud de implementación a producción.Una empresa más pequeña para la que trabajé utilizó Rastreador de problemas para estas solicitudes.

Utilice lo que funcione en su situación y presupuesto, solo tenga un proceso y herramientas que funcionen para ese proceso.

3) Dijiste que a veces los objetos solo necesitan ir a un puñado de bases de datos.Con solo 18 bases de datos, probablemente en un servidor, recomendaría hacer que cada base de datos coincida exactamente con los objetos.¿Solo 5 bases de datos necesitan usp_DoSomething?¿Así que lo que?Ponlo en cada base de datos.Esto será mucho más fácil de gestionar.Lo hicimos de esta manera en un sistema de 6 servidores con alrededor de 250-300 bases de datos.Hubo excepciones, pero estaban agrupadas.Las bases de datos del servidor C obtuvieron este conjunto adicional de objetos.Las bases de datos del servidor L obtuvieron este otro conjunto.

4) Dijiste que a veces el DBA se olvida de implementar scripts de cambios en todas las bases de datos.Esto me dice que necesita herramientas para implementar cambios.Probablemente esté tomando un script SQL, abriéndolo en Query Analyzer o Manegement Studio (o lo que sea que use) y yendo manualmente a cada base de datos y ejecutando SQL.Esta no es una buena solución a largo (ni a corto plazo). puerta roja (creadores de SQLCompare arriba) tienen muchas herramientas excelentes. multiscript Parece que puede funcionar para fines de implementación.Trabajé con un DBA que escribió su propia herramienta en SQL Server 2000 usando O-SQl.Tomaría un archivo SQL y lo ejecutaría en cada base de datos del servidor.Tuvo que ejecutarlo en cada servidor, pero fue mejor que ejecutarlo en cada base de datos.También ayudé a escribir una herramienta VB.net que haría lo mismo, excepto que también revisaría una lista de servidores, por lo que solo tenía que ejecutarse una vez.

5) Control de fuente.Mi equipo actual no utiliza control de fuente y no tengo tiempo suficiente para decirles cuántos problemas causa esto.Si no tiene algún tipo de sistema de control de fuente, consiga uno.

Answer 4

No tengo suficiente reputación para comentar la respuesta anterior, pero la versión pro de SQL Compare tiene una API programable.Dado que tiene que replicar cosas en todas estas bases de datos, puede usar esto para realizar un trabajo automatizado para generar los scripts de cambio o para validar que todas las bases de datos estén sincronizadas.Tampoco es mucho más cara que la versión estándar.

Answer 5

Además de usar herramientas de comparación de bases de datos, con 18 bases de datos debería tener un DBA, por lo tanto, aplique una política según la cual solo el DBA puede cambiar tablas en el nivel de la base de datos restringiendo el acceso a CREATE y ALTER solo al DBA.Tanto en su prueba como en sus bases de datos en vivo.¡La base de datos de desarrollo no debería tener esto, por supuesto!Haga que los desarrolladores que han estado creando o alterando los esquemas, quieran o no, pasen por el DBA.

Answer 6

Cree un único script DDL/SQL controlado por fuente para cada versión y solo Úselo para actualizar las bases de datos.Las herramientas de diferenciación pueden ser útiles, pero principalmente para comprobar que no has cometido un error y salir del apuro cuando las políticas fallan.Combine los scripts DDL, SQL y de procedimientos almacenados en un solo script para que no sea fácil "olvidarse" de ejecutar uno de los scripts.

Answer 7

Tenemos una herramienta llamada DB Schema Difftective que puede comparar y sincronizar esquemas de bases de datos.Con nuestra otra herramienta, DB MultiRun, puede implementar fácilmente scripts generados (sincronizados) en múltiples servidores de base de datos (basados ​​en proyectos).

Answer 8

Me doy cuenta de que esta publicación es antigua, pero TurnKey es correcta.Si es un desarrollador que trabaja en un entorno de equipo, la mejor manera de mantener un esquema de base de datos para una aplicación grande es realizar actualizaciones de un esquema maestro en cualquier fuente segura que utilice.Simplemente escriba su propia clase de Scripting y su base de datos será perfecta en todo momento.