Los errores ocurren y, a veces, los datos deben corregirse en producción. ¿Cuál es la forma más segura de hacerlo desde el punto de vista de una gran empresa? ¿Hay herramientas que pueden ayudar? Aquí hay algunas consideraciones que impulsan este requisito ...
- Necesitamos registrar quién ejecutó la consulta y qué ejecutaron
- Idealmente, necesitamos darle acceso a la persona para que solo ejecute consultas en las tablas de interés y solo por un corto tiempo
- Lo que sea que se esté ejecutando, las consultas deben tener algo de inteligencia para no permitir la ejecución prolongada y el bloqueo de SQL para ejecutarse sin permiso explícito
- Este proceso debe ser independiente de la base de datos o al menos comprender DB2, Oracle y SQL Server.
Estamos tratando de reducir el riesgo de que las consultas de reparación de productos ad-hoc hagan lo "incorrecto" y, al mismo tiempo, agreguemos algo de seguridad / auditorías al proceso. ¿Pensamientos o ideas?
Respuestas:
Nunca actualice las bases de datos de producción manualmente.
Escribe guiones.
Verifíquelos tres veces y haga que varias personas lo hagan, no solo una persona que lo haga tres veces.
Incluya consultas de validación posteriores al cambio en esos scripts.
Siempre que la situación lo permita, pruebe todo el cambio dentro de una transacción que se revierte al final, después de que se haya ejecutado la validación posterior al cambio. Cuando esté seguro con los resultados, cambie la reversión a una confirmación.
Pruebe esos scripts ad nauseam contra una base de datos de prueba.
Haga una copia de seguridad antes de ejecutar el script en la base de datos de producción.
Ejecuta los scripts.
Verifique, valide y verifique tres veces los datos modificados utilizando los scripts de validación posterior al cambio.
Haga una verificación visual de todos modos.
Si algo parece apagado, retroceda y restaure la copia de seguridad.
No continúe con los datos modificados como datos de producción hasta que esté absolutamente seguro de que todo está bien y haya finalizado la sesión de los gerentes (comerciales) involucrados.
fuente
WHEREy tu base de datos estará inactiva por el resto del día. O semana.La respuesta de Marjan Venema es técnicamente válida y debe seguirse cuando sea posible. Por desgracia, Marjan responde desde el punto de vista de un teórico o un administrador de base de datos purista al que le gusta hacer las cosas de manera limpia. En la práctica, a veces las restricciones comerciales hacen que sea imposible hacer las cosas de manera limpia.
Imagine el siguiente caso:
Hay un error en el producto de software que hace que deje de funcionar cuando detecta lo que considera una inconsistencia de datos en la base de datos,
Todos los desarrolladores que podrían solucionar el error en la aplicación son inalcanzables,
Actualmente, la compañía está perdiendo miles de dólares por hora (digamos $ 6 000, lo que significa $ 100 por minuto),
El error está afectando a varias tablas, una de las cuales es enorme y se refiere solo a los datos en sí, no al esquema,
Para evitar el error, debe experimentar un poco con los datos, lo que implica eliminarlos y cambiarlos,
La base de datos es grande y tomaría tres horas tomar o restaurar la copia de seguridad,
La última copia de seguridad completa se tomó hace tres semanas; también hay copias de seguridad incrementales diarias, y la última copia de seguridad incremental diaria se realizó hace 14 horas,
Se supone que las copias de seguridad de la base de datos son confiables; fueron severamente probados, incluso recientemente,
No es aceptable perder 14 horas de datos, pero la pérdida de una o dos horas de datos es,
El entorno de ensayo se utilizó por última vez hace seis meses; parece que no está actualizado y puede llevar horas configurarlo,
La base de datos es Microsoft SQL Server 2008 Enterprise.
La forma limpia de hacer las cosas es:
Restaurar la copia de seguridad en un entorno provisional,
Experimenta allí
Verifique el guión final dos veces,
Ejecute el script en el servidor de producción.
Solo el primer paso le costará $ 18 000 a su empresa. El riesgo es bastante bajo si realiza el tercer paso sin problemas, pero dado que trabaja bajo presión extrema, el riesgo sería mucho mayor. Puede terminar con un script que funcionó perfectamente bien en la puesta en escena, luego atornilla la base de datos de producción.
En cambio, podrías haber hecho así:
Cree una instantánea (Microsoft SQL Server lo admite, y lleva unos segundos revertir (y nada crear) una instantánea de una base de datos que demora una hora en hacer una copia de seguridad; me imagino que otros productos de bases de datos también admiten instantáneas),
Experimente directamente en la base de datos de producción, volviendo a la instantánea si algo sale mal.
Mientras que un purista arreglaría la base de datos de una manera limpia y aún correría el riesgo de arruinar las cosas dada la presión del tiempo mientras desperdicia más de $ 20 000 de su compañía, un administrador de la base de datos que tenga en cuenta las restricciones comerciales arreglará la base de datos de una manera lo que minimizará los riesgos (gracias a las instantáneas) mientras lo hace rápidamente.
Conclusión
Soy purista y odio hacer las cosas de una manera no limpia. Como desarrollador, refactorizo el código que modifico, comento las partes difíciles que no se pudieron refactorizar, compruebo la base de código y hago revisiones de código. Pero también tomo en consideración las circunstancias en las que haces las cosas limpiamente y al día siguiente que te despiden, o minimizas tanto los riesgos como el impacto financiero al hacer un truco rápido que funciona.
Si un técnico de TI quiere hacer las cosas de manera limpia solo por el bien de la limpieza, mientras que causa una pérdida de miles de dólares para la empresa, este técnico de TI tiene una profunda incomprensión de su trabajo.
fuente
Es una mala práctica y una puerta de invitación para más problemas y problemas de datos. Incluso hay una frase que describe este enfoque como " Rápido y sucio ".
Continuar arreglando / actualizando directamente en un servidor de producción es muy peligroso , ya que le costará a usted / a su compañía una fortuna ( demandas legales, datos malos / sucios, negocios perdidos, etc. )
Sin embargo, los errores estarán allí y deben corregirse. El estándar industrial de facto es aplicar parches / (secuencias de comandos de implementación) en un Staging (entorno de preproducción con la última copia de la base de datos prod) y dejar que el analista de datos / QA verifique la solución. El mismo script debe ser controlado por la versión y aplicado al entorno Prod para evitar problemas.
Hay una serie de buenas prácticas mencionadas en esta publicación relacionada: buenas prácticas de la base de datos provisional
Un buen conjunto de referencias para mirar son:
fuente
En la mayoría de las organizaciones, he trabajado para actualizar los datos en el entorno en vivo, siempre fue realizado por un pequeño grupo de personas con los derechos de acceso para hacerlo, generalmente con un título de trabajo como DBA. Como las actualizaciones solo pueden ser realizadas por el pequeño número de personas, existe al menos una posibilidad de que se familiaricen con los datos y, por lo tanto, reduzcan (pero no eliminen) el riesgo de problemas.
La persona que escribe el script de actualización lo haría en la prueba (como en otras respuestas) y obtendría una aprobación seria de los no técnicos (aquellos que conocen el sistema, además de alguien con autoridad superior) de que las características parecen estar 'correctas nuevamente' en Además de su propia prueba paranoica. Los scripts y los datos serían verificados independientemente por otro técnico (a menudo el rol de DBA que mencioné) en la prueba antes de que se ejecute. Los resultados se compararían con los valores anticipados (únicos para cada escenario, pero a menudo cosas como conteos de filas, etc.)
En una empresa para la que trabajé, hacer copias de seguridad no era una opción realista, pero todas las filas que se actualizaron se escribieron en un archivo de texto para referencia ANTES de la actualización, y luego DESPUÉS de la actualización si alguien alguna vez necesita consultarla. Los scripts y estos datos se guardaron en un registro de cambios de datos debidamente organizado.
Cada negocio es único, y los riesgos de actualizar algunos datos son claramente mayores que en otros.
Al tener un proceso que hace que las personas tengan que pasar por alto para hacer estas actualizaciones, esperamos que promueva una cultura que haga que las personas quieran tratar esto como un último recurso, y cree una actitud saludable de "doble verificación, triple verificación" en torno a estas cosas.
fuente
Hay momentos en que debe corregir datos en Prod que no existen en otros servidores. Esto no se debe solo a errores, sino que podría ser una importación de datos de un archivo enviado por un cliente que era incorrecto o un problema causado por alguien que hackeó su sistema. O por un problema causado por una mala entrada de datos. Si su base de datos es grande o tiene un tiempo crítico, es posible que no tenga tiempo para restaurar la última copia de seguridad y corregirla en el desarrollador.
Su primera defensa (¡y algo sin lo que ninguna base de datos Enterprise puede permitirse prescindir!) Son las tablas de auditoría. Puede usarlos para retroceder cambios de datos incorrectos. Además, puede escribir scripts para devolver los datos al estado anterior y probarlos en otros servidores mucho antes de que necesite revertir los datos auditados. Entonces, el único riesgo es que identificó los registros correctos para revertir.
A continuación, todos los scripts para cambiar los datos de producción deben incluir lo siguiente:
Deben estar en transacciones explícitas y tener un bloque TRY Catch.
Deben tener un modo de prueba que pueda usar para revertir los cambios después de ver cuáles habrían sido. Debería tener una declaración seleccionada antes de que se realizara el cambio y una ejecución después del cambio para asegurarse de que el cambio fuera correcto. El script debe asegurarse de que se muestre el número de filas procesadas. Tenemos algo de esto preconfigurado en una plantilla que asegura que las piezas se realicen. Las plantillas para cambios también ayudan a ahorrar tiempo al escribir la corrección.
Si hay una gran cantidad de datos para cambiar o actualizar, considere escribir el script para que se ejecute en lotes con confirmaciones para cada lote. No desea bloquear todo el sistema mientras arregla un millón de registros. Si tiene una gran cantidad de datos para corregir, asegúrese de que un dba o alguien que esté acostumbrado a la optimización del rendimiento revise el script antes de ejecutarlo y, si es posible, ejecutarlo fuera del horario laboral.
A continuación, todas las secuencias de comandos para cambiar cualquier cosa en la producción se revisan en código y se ponen en control de origen. Todos ellos, sin excepción.
Finalmente, los desarrolladores no deben ejecutar estos scripts. Deben ser ejecutados por dbas o un grupo de administración de configuración. Si no tiene ninguno de ellos, entonces solo las personas que son líderes tecnológicos o superiores deberían tener los derechos para ejecutar cosas en productos. Cuantas menos personas ejecuten cosas en productos, más fácil será localizar un problema. Las secuencias de comandos deben escribirse de modo que simplemente se ejecuten, no resalten partes y se ejecuten paso a paso. Es lo más destacado lo que a menudo causa problemas a las personas cuando se olvidan de resaltar la cláusula where.
fuente
He actualizado datos muchas veces en la ejecución de bases de datos de producción. Estoy de acuerdo con la respuesta anterior, que este nunca sería un procedimiento operativo estándar.
También sería costoso (miraríamos por encima de los hombros de los demás y discutiremos 2 o 3 tal vez)
Y la regla de oro: siempre haga una declaración de selección para mostrar lo que se haría antes de hacer una declaración de actualización / eliminación / inserción
¡La regla de oro aplicada por las otras dos personas en el equipo!
fuente
re: la respuesta de MainMa ...
fuente