¿Cuál es su flujo de trabajo para planificar una migración de datos?

Muchas veces me llevaron al final de un esfuerzo de desarrollo de software y me dijeron algo como "está bien, tenemos todo este código nuevo y requiere que las tablas cambien y que los datos se migren".

Parece que cada vez es un escenario único, disparar desde la cadera, la mejor suposición. Siento que este es mi conjunto de habilidades más débil como DBA.

Me gustaría entrar en algunos patrones para abordar, administrar y probar las migraciones de datos .

Indíqueme algunas de las mejores prácticas y / o dónde puedo obtener material de aprendizaje para ayudarme a mejorar en esta área.

Cada vez que lo hago, hemos hecho dos pases ...

1. tome una instantánea y, trabajando en un servidor diferente, úsela para determinar qué se debe hacer para la migración y escríbala.
2. una vez que tienen el script en la mano, la instantánea se restaura en el sistema de prueba y se programa para ver si se ejecutará dentro del tiempo requerido, o se ajusta y modifica hasta que pueda.
3. haga que las partes interesadas firmen que nada se ve mal con los datos en el sistema de prueba.

Luego, durante un fin de semana, tiene una interrupción programada:

1. El viernes por la noche, los sistemas que usan la base de datos se desactivan, se realiza una copia de seguridad en frío completa y los scripts se ejecutan para migrar / modificar / lo que sea a los datos
2. Los sistemas se vuelven a instalar bajo alguna dirección privada o se configuran de alguna manera para que no esté abierto a nadie más que a las partes interesadas para las pruebas de aceptación
3. Si las partes interesadas lo aprueban, el sistema se pone en línea y se hace público; de lo contrario, la base de datos se restaura a partir de la copia de seguridad realizada el viernes por la noche y comienza el proceso nuevamente.

Con nuestro horario, la gente de la base de datos generalmente tenía desde las 6 p. M. Del viernes hasta las 10 a. M. Del sábado para ejecutar las secuencias de comandos de copia de seguridad y migración, por lo que nuestro objetivo era que se ejecutaran en menos de 8 horas (~ 6 de las cuales eran copias de seguridad), así que ' tendría algo de tiempo para nuestras pruebas y correcciones antes de que se publique a las partes interesadas.

A las partes interesadas se les dio su ventana de tiempo por adelantado, por lo que sabían dejar su fin de semana abierto para la prueba al comienzo de la ventana. También se les informaría al final de su ventana, generalmente el domingo por la tarde, donde si todos no hubieran cerrado la sesión, tendríamos que comenzar a retroceder.

Ah, y por supuesto ... si alguien tuvo un cambio durante cualquiera de las pruebas de aceptación, e hicimos un cambio, significaba que todas las aprobaciones de las partes interesadas se anularon, y tuvieron que volver a probar ... entonces intentaríamos darles todo un tiempo para buscar problemas y ejecutar las correcciones como un lote, en lugar de aplicarlos uno por uno.

Afortunadamente, las únicas veces que tuve una de esas situaciones en las que no podíamos tener un tiempo de inactividad significativo, los sistemas que estaba migrando se alimentaban de scripts, no de la entrada del usuario, por lo que podía tener dos sistemas paralelos en funcionamiento y cambiarlos. cuando las cosas se cerraron. (solo una vez hubo un problema, cuando mi jefe insistió en que hiciéramos una copia de seguridad completa, sin entender que todo iba a estar en línea con una IP diferente ... entonces, ¿qué debería haber sido una interrupción de 5 minutos en un el mal día se convirtió en un corte de 5 horas).

Todo depende del volumen de datos en comparación con la potencia del hardware que admite la base de datos y los acuerdos sobre la disponibilidad del sistema. ¿Tiene algún tiempo de inactividad o debería hacerse todo en línea? Comience a limpiar los datos, eliminando las filas desactualizadas tanto como sea posible. Este es un proyecto en sí mismo. Si los datos son limpios y valiosos, haga que el usuario decida sobre el tiempo de inactividad. Si el tiempo de inactividad está disponible, es bastante sencillo, si se trata de una transformación conocida que debería aplicarse a los datos existentes para formar la colección actualizada. Si no hay tiempo de inactividad permitido, o muy poco, el desafío comienza. Oracle admite esto de varias maneras, como la redefinición de tablas en línea y la nueva redefinición basada en la edición 11g. Con la redefinición de la tabla en línea, puede preparar las tablas para tomar su nueva forma. Esto se puede hacer mientras la aplicación se ejecuta en la forma anterior de la tabla [s]. Si están todos listos, puede cambiar a la nueva forma de la tabla [s]. Este también será el momento de introducir el nuevo código de la aplicación y al mismo tiempo marcará el comienzo del tiempo de inactividad requerido para implementar la nueva aplicación. Los datos históricos más antiguos se pueden preparar antes de que los datos en vivo migren y se mantengan sincronizados utilizando herramientas como Oracle Golden Gate. En tal escenario, efectivamente construye una nueva base de datos que asume el rol de la base de datos anterior. La redefinición basada en la edición es más adecuada si no se necesitan cambios en la tabla. Hay toneladas de opciones a considerar y creo que es difícil dar una buena regla que siempre funcione. Este también será el momento de introducir el nuevo código de la aplicación y al mismo tiempo marcará el comienzo del tiempo de inactividad requerido para implementar la nueva aplicación. Los datos históricos más antiguos se pueden preparar antes de que los datos en vivo migren y se mantengan sincronizados utilizando herramientas como Oracle Golden Gate. En tal escenario, efectivamente construye una nueva base de datos que asume el rol de la base de datos anterior. La redefinición basada en la edición es más adecuada si no se necesitan cambios en la tabla. Hay toneladas de opciones a considerar y creo que es difícil dar una buena regla que siempre funcione. Este también será el momento de introducir el nuevo código de la aplicación y al mismo tiempo marcará el comienzo del tiempo de inactividad requerido para implementar la nueva aplicación. Los datos históricos más antiguos se pueden preparar antes de que los datos en vivo migren y se mantengan sincronizados utilizando herramientas como Oracle Golden Gate. En tal escenario, efectivamente construye una nueva base de datos que asume el rol de la base de datos anterior. La redefinición basada en la edición es más adecuada si no se necesitan cambios en la tabla. Hay toneladas de opciones a considerar y creo que es difícil dar una buena regla que siempre funcione. Los datos históricos más antiguos se pueden preparar antes de que los datos en vivo migren y se mantengan sincronizados utilizando herramientas como Oracle Golden Gate. En tal escenario, efectivamente construye una nueva base de datos que asume el rol de la base de datos anterior. La redefinición basada en la edición es más adecuada si no se necesitan cambios en la tabla. Hay toneladas de opciones a considerar y creo que es difícil dar una buena regla que siempre funcione. Los datos históricos más antiguos se pueden preparar antes de que los datos en vivo migren y se mantengan sincronizados utilizando herramientas como Oracle Golden Gate. En tal escenario, efectivamente construye una nueva base de datos que asume el rol de la base de datos anterior. La redefinición basada en la edición es más adecuada si no se necesitan cambios en la tabla. Hay toneladas de opciones a considerar y creo que es difícil dar una buena regla que siempre funcione.

Es un tema interesante, Ronald.

Buenas respuestas hasta ahora. Agregaré un par de puntos más para su consideración.

Primero, cuando puede hacer sus migraciones con un simple DML SQL, puede confiar en gran medida en su motor SQL para asegurarse de que todas las filas se procesen con éxito. Sin embargo, he estado involucrado en migraciones, donde parte de la migración fue un poco más complicada: hubo transformaciones de datos reales a medida que los datos se movieron a una nueva estructura. En estos casos, es importante que tenga un proceso que pueda manejar los siguientes elementos:

• Contar registros en vs. registros procesados.
• Detecte errores durante la transformación y trate con ellos de una manera que permita que la transformación continúe y permita el reprocesamiento de los registros "incorrectos" una vez que haya identificado una solución.
• Los recuentos de registros deben incluir registros "incorrectos", es decir, registros de entrada = registros de salida buenos + registros incorrectos
• Si su transformación cambia el recuento de registros (un registro de entrada se convierte en más de un registro de salida, por ejemplo), tenga una manera de predecir el número de registros de salida con los que terminará y luego pruebe sus resultados contra ese recuento.

El otro punto que agregaría es que es importante tener un plan para lo que vas a hacer si las cosas no salen según lo planeado. Esta es realmente una función del despliegue en su conjunto, pero parece que se pasa por alto con tanta frecuencia que pensé que valía la pena mencionarlo.

Una descripción general de cómo hacerlo

Para empezar

• Tiene la base de datos "después" en prueba / UAT / lo que sea "DB de trabajo"
• Tiene la base de datos "antes" en producción. Así que úselo para crear una copia de producción en alguna parte = "DB de referencia". Y otro como "prueba de script DB"
• También espero que tenga un montón de scripts de desarrollo con sus ALTER, etc. Si es así, otra copia de producción con su script de desarrollo aplicado, limpiamente y en orden es útil = "cambiar DB"

A continuación, descargue las herramientas de comparación de Red Gate o algo así como el administrador Embarcadero SQL Change . No puedes migrar fácilmente sin él. El costo es trivial a la cantidad de tiempo ahorrado. Y lo más importante, los scripts generados hacen cambios en una sola transacción, lo que significa una implementación limpia

Ahora,

• generar scripts de cambio y reversión utilizando las herramientas que comparan entre "referencia" y "cambio"
• aplique la secuencia de comandos de cambio a "prueba de secuencia de comandos" y compare de nuevo a "DB de trabajo"
• aplique el script de reversión a "prueba de script" y compare de nuevo a "y compare de nuevo a" DB de trabajo "

Ahora, tiene scripts de cambio y reversión seguros y probados para aplicar siempre.

Y, por supuesto, hace una copia de seguridad de la base de datos antes de cualquier cambio porque, estadísticamente, las cosas siempre sucederán eventualmente.

Las herramientas de Red Gate también se pueden comparar con una carpeta que está bajo control de origen. Luego capturamos los ALTER, etc. en nuestro control de origen por separado para los scripts de cambio reales.