Para mi cliente, de vez en cuando trabajo en su base de datos en vivo para solucionar un problema que ellos mismos han creado, o para corregir datos erróneos que crearon los errores de mi producto. Al igual que el acceso root de Unix, es peligroso. ¿Qué lecciones debo aprender antes de tiempo?
¿Qué es lo primero que debe hacer para tener cuidado al operar con datos en vivo?
Respuestas:
Tres cosas que he aprendido de la manera más difícil a lo largo de los años ...
Primero, si está haciendo actualizaciones o eliminaciones de datos en vivo, primero escriba una consulta SELECT con la cláusula WHERE que usará. Asegúrate de que funcione. Asegúrate de que sea correcto. Luego, anteponga la instrucción UPDATE / DELETE a la cláusula WHERE de trabajo conocida.
Nunca querrás tener
DELETE FROM Customers
sentado en su analizador de consultas esperando que escriba la cláusula WHERE ... accidentalmente presione "ejecutar" y acaba de eliminar su tabla de clientes. ¡Ups!
Además, dependiendo de su plataforma, descubra cómo realizar una copia de seguridad rápida y sucia de una mesa. En SQL Server 2005,
SELECT *
INTO CustomerBackup200810032034
FROM Customer
copiará todas las filas de toda la tabla Customer en una nueva tabla llamada CustomerBackup200810032034, que luego podrá eliminar una vez que haya realizado las actualizaciones y se haya asegurado de que todo esté bien. Si ocurre lo peor, es mucho más fácil restaurar los datos faltantes de esta tabla que intentar restaurar la copia de seguridad de anoche desde un disco o cinta.
Finalmente, tenga cuidado con las eliminaciones en cascada que eliminan las cosas que no tenía la intención de eliminar: verifique las relaciones de sus tablas y las restricciones clave antes de modificar nada.
BEGIN TRANSACTION;
De esa manera, puede retroceder después de un error.
Haga una copia de seguridad primero: debería ser la ley número 1 de la administración de sistemas de todos modos
EDITAR : incorporando lo que otros han dicho, asegúrese de que sus ACTUALIZACIONES tengan cláusulas WHERE apropiadas.
Idealmente, el cambio de una base de datos en vivo nunca debería suceder (más allá de INSERTs y mantenimiento básico). Cambiar la estructura de la base de datos en vivo está especialmente cargado de mal karma potencial.
Realice los cambios en una copia y, cuando esté satisfecho, aplique la corrección a la versión en vivo.
A menudo, antes de hacer una ACTUALIZACIÓN o ELIMINACIÓN, escribo el SELECT equivalente.
NUNCA realice una actualización a menos que esté en un BEGIN TRAN t1, ni en una base de datos de desarrollo, ni en producción, ni en ningún lugar. NUNCA ejecute un COMMIT TRAN t1 fuera de un comentario; escriba siempre
--COMMIT TRAN t1
y luego seleccione la declaración para ejecutarla. (Obviamente, esto sólo se aplica a los clientes de consultas de GUI). Si hace estas cosas, se convertirá en una segunda naturaleza y no perderá casi nada de tiempo.
De hecho, tengo una macro de "actualización" que escribe esto. Siempre pego esto para configurar mis actualizaciones. Puede hacer uno similar para eliminaciones e inserciones.
begin tran t1
update
set
where
rollback tran t1
--commit tran t1
Siempre asegúrese de que sus UPDATEs y DELETEs tengan la cláusula WHERE adecuada.
Para responder mi propia pregunta:
Al escribir una declaración de actualización, escríbala fuera de orden.
UPDATE [table-name]WHERE [conditions]SET [columns-and-values]Elegir las filas que desea actualizar antes de decir qué valores desea cambiar es mucho más seguro que hacerlo en el otro orden. Hace que sea imposible update person set email = 'bob@bob.com'estar sentado en su ventana de consulta, listo para ser ejecutado por una pulsación de tecla fuera de lugar, listo para estropear cada fila de la tabla.
Editar: como han dicho otros, escriba la WHEREcláusula para sus eliminaciones antes de escribir DELETE.
Como ejemplo, creo SQL como este
--Update P Set
--Select ID, Name as OldName,
Name='Jones'
From Person P
Where ID = 1000
Resalto el texto desde el final hasta el Seleccionar y ejecuto ese SQL. Una vez que verifico que está extrayendo el registro que quiero actualizar, presiono shift-up para resaltar la declaración de actualización y ejecutarla.
Tenga en cuenta que utilicé un alias. Nunca actualizo explícitamente el nombre de una tabla. Siempre uso un alias.
Si hago esto junto con transacciones y rollback / commits, estoy realmente seguro.
¿Mi forma número uno de tener cuidado con una base de datos activa? No lo toques. :)
Las copias de seguridad pueden deshacer el daño que infliges en la base de datos, pero aún es probable que introduzcas efectos secundarios negativos durante ese período de tiempo.
No importa qué tan sólido crea que es el script con el que está trabajando, ejecútelo a través de un ciclo de prueba. Incluso si un "ciclo de prueba" significa ejecutar el script en su propia instancia de la base de datos, asegúrese de hacerlo. Es mucho mejor introducir defectos en su caja local que en un entorno de producción.
Algunas otras cosas que he encontrado útiles:
si usa MySQL, habilite las actualizaciones seguras
Si tiene un DBA, pídale que lo haga.
He descubierto que estas 3 cosas me han impedido hacer un daño grave.
Bueno, eso es todo en lo que puedo pensar ahora. Tome los pasajes en negrita y verá cuál es el número 1 para mí. ;-)
Si está utilizando Oracle u otra base de datos que lo admita, verifique sus cambios antes de realizar un COMMIT.
Los datos siempre deben implementarse para vivir a través de scripts, que se pueden ensayar tantas veces como sea necesario para hacerlo bien en dev. Cuando haya datos dependientes para que el script se ejecute correctamente en el desarrollador, organícelo de manera adecuada; no puede salirse con la suya con este paso si realmente quiere tener cuidado.
Haga una copia de seguridad o vuelque la base de datos antes de comenzar.
Para agregar a lo que dijo @ Wayne , escriba su WHEREantes del nombre de la tabla en una declaración DELETEo UPDATE.
Diferentes colores por entorno: Hemos configurado nuestro desarrollador PL \ SQL (IDE para Oracle) para que cuando inicie sesión en la base de datos de producción, todas las ventanas estén en rojo brillante. Algunos han ido tan lejos como para asignar un color diferente para desarrollo y prueba también.
Asegúrese de especificar una cláusula where al eliminar registros.
Siempre pruebe primero cualquier consulta más allá de la selección en los datos de desarrollo para asegurarse de que tenga el impacto correcto.
Si estoy actualizando una base de datos con un script, siempre me aseguro de poner uno o dos puntos de interrupción al comienzo de mi script, en caso de que apriete el botón de ejecutar / ejecutar por accidente.
Agregaré a las recomendaciones de hacer BEGIN TRAN antes de su ACTUALIZACIÓN, pero no olvide hacer el COMMIT; puede hacer el mismo daño si deja abierta su transacción no comprometida. No se distraiga con teléfonos, compañeros de trabajo, almuerzos, etc. cuando esté en medio de actualizaciones o encontrará que todos los demás están encerrados hasta que usted COMPROMETE o ROLLBACK.
Siempre comento cualquier consulta destructiva (insertar, actualizar, eliminar, soltar, alterar) cuando escribo consultas ad hoc en Query Analyzer. De esa forma, la única forma de ejecutarlos es resaltarlos, sin seleccionar la parte comentada, y presionar F5.
También creo que es una buena idea, como ya se mencionó, escribir su declaración where primero, con una selección, y asegurarse de que está alterando los datos correctos.
Cree un usuario de solo lectura (u obtenga el DBA para que lo haga) y solo use ese usuario para mirar la base de datos. Agregue los permisos adecuados al esquema para que pueda ver el contenido de los procedimientos almacenados / vistas / activadores / etc. pero no tener la capacidad de cambiarlos.