Las mejores prácticas para la gestión del cambio con índices

Question

Nuestra tienda de TI está comenzando a construir un grupo de DBA. Todos nosotros (incluido yo mismo) hemos venido del mundo del desarrollo de aplicaciones/arquitectura, por lo que el mundo del DBA sigue siendo bastante nuevo para nosotros.

Junto con la construcción de un grupo DBA, estamos buscando crear procedimientos y procesos de gestión de cambios (con suerte en función de las mejores prácticas) para cuando necesitamos mover los cambios.

He encontrado el siguiente Lo cual es útil para principalmente el procedimiento activado, almacenado y/o cambios DDL. Pero no necesariamente aborda índices o bases de datos de proveedores.

Tenemos una combinación de nuestras bases de datos propias y de proveedores. En nuestro caso, algunos de los proveedores (aunque no todos) están trabajando con nuestra empresa para construir la (s) base (s) de datos y las aplicaciones. Estamos en el proceso de prueba de rendimiento nuestras aplicaciones ahora antes de que "se activen". Por lo tanto, estamos analizando los índices (o la falta de ellos) bastante fuertemente.

A medida que nos encontramos con índices que creemos que deberían hacerse, ¿cómo nos ocupamos mejor de la gestión del cambio con respecto a estos, tanto para nuestras propias bases de datos como para cualquier proveedor?

¿Qué haces en tu tienda? Estoy menos preocupado por las herramientas que por el proceso.

EDITAR: Hasta ahora, aprecio los comentarios, comentarios y respuestas para esta pregunta. He notado que algunas de las respuestas son un poco específicas para la herramienta. Estoy buscando más prácticas "agnósticas", si eso se puede tener.

Sin embargo, si el agnóstico no es posible, entonces para los conjuntos de herramientas, usamos IBM DB2 LUW (y eso en realidad en AIX) principalmente. Tenemos un poco de DB2 en Windows y DB2 para I (IBM's i5/OS), pero en su mayoría somos AIX DB2. Utilizamos el control de origen, específicamente subversión.

Una vez más, buscar las mejores prácticas generales, pero arriba es lo que usamos que sería específico del proveedor.

EDITAR: Decisión actual: Tenemos la intención de rastrear nuestro razonamiento y nuestros cambios. Por lo tanto, vamos a abrir un problema en nuestro software de seguimiento de problemas (que en nuestro caso es JIRA). Ahora podemos agregar documentación sobre qué prioridad tiene el cambio, datos que respaldan cuál debería ser el cambio, el cambio y los resultados del cambio de otro entorno donde se probó el cambio.

Luego también tenemos la intención de realizar un seguimiento de nuestros cambios en los scripts en SVN (al igual que se sugirió a continuación). De esta manera podemos rastrear qué versión de qué existe dónde. Esto se puede grabar en nuestro problema JIRA (y en cualquier otro software de auditoría que usemos, es decir, enlaces pegados). Podemos saber con más certeza qué cambio fue para qué entorno y por qué. Entonces también podemos rastrear si el índice fue algo que agregamos más allá de la implementación de los proveedores o antes de su implementación, etc.)

Answer 1

Recomiendo encarecidamente que trate su base de datos básicamente de la misma manera que trata su código de aplicación. Puede escribir su base de datos en sus componentes y verificarlas al control de origen y luego usar las mismas etiquetas y versiones que usa para sus aplicaciones.

Para poner los objetos en el control de la fuente, hay una serie de herramientas que puede usar. Microsoft tiene una herramienta que se le apoda Data Dude. Funciona con Visual Studio. También se están preparando para lanzar una nueva herramienta llamada SQL Server Database Tools (SSDT), nuevamente, trabajando con Visual Studio. Mi compañía, Red Gate Software, hace una herramienta que funcione con SSMS llamada SQL Source Control.

En términos de proceso, escribí varios capítulos para el libro Guía Red Gate para el desarrollo del equipo. Está disponible como una descarga gratuita (o si quieres matar un árbol, puedes purcahse de Amazon). Entro en muchos más detalles sobre el trabajo con bases de datos en equipos de desarrollo allí.

Answer 2

1. Mantenemos los scripts de base de datos como parte de nuestra base de código de aplicación que se mantiene bajo el control de versiones. Sin embargo, utilizamos diferentes "procesos" para el código de desarrollo y de producción.

2. Desarrollo mantenemos los siguientes scripts:

   • base.sql: crea las tablas de esquema y datos de muestra
   • sttagingChanges.sql: realiza cambios en el Base.SQL para el entorno de puesta en escena, principalmente direcciones de correo electrónico, rutas y otros activos que podrían cambiar
   • prodchanges.sql - realiza cambios en Base.sql para una implementación de producción. Para nuevos proyectos, generalmente podemos probarlos en entornos de producción reales.

3. Mantenimiento

   • Base.sql: una versión desinfectada de la base de datos de producción
   • stagingchanges.sql y prodchanges.sql - como se indicó arriba
   • changequest.sql (generalmente tiene la ID de la solicitud de cambio) que aplica cualquier cambio de esquema para la solicitud de cambio actual en la que estamos trabajando
   • Changerequest -Rollback.sql: invierte los cambios realizados para la solicitud de cambio y restablece la base de datos a la producción
   • Archivo (carpeta) para los scripts de solicitud de cambio previo

Entonces, en modo de mantenimiento, todo lo que necesitamos hacer es aplicar el script changequest.sql durante la implementación en la producción

Answer 3

Estar en el espacio de control de versiones de la base de datos durante 5 años (como director de gestión de productos en Dbmaestro) Y después de haber trabajado como DBA durante más de dos décadas, puedo decirle el simple hecho de que no puede tratar los objetos de la base de datos mientras trata su Java, C# u otros archivos.

Hay muchas razones y nombraré algunas:

• Los archivos se almacenan localmente en la PC del desarrollador y el cambio
  hace que no afecten a otros desarrolladores. Del mismo modo, el desarrollador no se ve afectado por los cambios realizados por su colega. En la base de datos esto es
  (generalmente) no el caso y los desarrolladores comparten la misma base de datos
  entorno, por lo que cualquier cambio comprometido con la base de datos afecta a otros.
• Los cambios en el código de publicación se realizan utilizando los cambios de check-in / envío de cambios / etc. (dependiendo de la herramienta de control de origen que use). En ese momento, se inserta el código del directorio local del desarrollador
  en el repositorio de control de origen. Desarrollador que quiere obtener el
  El último código debe solicitarlo desde la herramienta de control de origen. En
  Base de datos El cambio ya existe e impacta otros datos incluso si no se registró en el repositorio.
• Durante la verificación del archivo, la herramienta de control de origen realiza una verificación de conflicto para ver si el mismo archivo fue modificado y marcado por otro desarrollador durante el tiempo que modificó su copia local. Nuevamente, no hay verificación para esto en la base de datos. Si altera un procedimiento de su PC local y al mismo tiempo modifico el mismo procedimiento con el código de mi PC local, anulamos los cambios de los demás.
• El proceso de compilación de código se realiza obteniendo la etiqueta / última versión del código en un directorio vacío y luego realiza una compilación de compilación. La salida son binarios en los que copiamos y reemplazamos el existente. No nos importa lo que antes. ¡En la base de datos no podemos recrear la base de datos, ya que necesitamos mantener los datos! También la implementación ejecuta scripts SQL que se generaron en el proceso de compilación.
• Al ejecutar los scripts SQL (con los comandos DDL, DCL, DML (para contenido estático)) asume que la estructura actual del entorno coincide con la estructura cuando crea los scripts. Si no, entonces sus scripts pueden fallar mientras intenta agregar una nueva columna que ya existe.
• Tratar los scripts SQL como código y generarlos manualmente causará errores de sintaxis, errores de dependencias de la base de datos, scripts que no son reutilizables que complican la tarea de desarrollar, mantener, probar esos scripts. Además, esos scripts pueden ejecutarse en un entorno que es diferente del que se ejecutaría.
• A veces, el script en el repositorio de control de versiones no coincide con la estructura del objeto que se probó y luego los errores ocurrirán en la producción.

Hay muchos más, pero creo que tienes la imagen.

Lo que encontré que funciona es lo siguiente:

1. Utilice un sistema de control de versiones forzado que aplique operaciones de check-out/check-in en los objetos de la base de datos. Esto asegurará que el repositorio de control de versiones coincida con el código que se registró, ya que lee los metadatos del objeto en la operación de registro y no como un paso separado realizado manualmente
2. Use un análisis de impacto que utilice las líneas de base como parte de la comparación para identificar conflictos e identificar si un cambio (al comparar la estructura del objeto entre el repositorio de control de fuente y la base de datos) es un cambio real que origen del desarrollo o un cambio que fue origen desde Un camino diferente y luego se debe omitir, como una rama diferente o una solución de emergencia.

Se publicó un artículo que escribí sobre esto aquí, eres bienvenido a leerlo.