significado - database sql

¿Cuál es su forma#1 de tener cuidado con una base de datos en vivo?

Question

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 los datos incorrectos que crearon los errores de mi producto. Al igual que el acceso raíz de Unix, es simplemente peligroso. ¿Qué lecciones debería aprender antes de tiempo?

¿Qué es lo # 1 que hace para tener cuidado al operar con datos en vivo?

Answer 1

1. Siempre haga una copia de seguridad antes de cambiar.
2. Siempre haga modificaciones (por ejemplo, ALTER TABLE) a través de un script.
3. Siempre modifique los datos (por ejemplo, ELIMINAR) a través de un procedimiento almacenado.

Answer 2

1. Verifique, vuelva a verificar y vuelva a verificar cualquier declaración que esté haciendo actualizaciones. Incluso si crees que estás haciendo una simple actualización de una sola columna, tarde o temprano no tendrás suficiente café y te olvidarás de una cláusula de "dónde", nukeando una mesa entera.

Un par de otras cosas que he encontrado útiles:

• si usa MySQL, habilite las actualizaciones seguras

• Si tiene un DBA, pídales que lo hagan.

He descubierto que estas 3 cosas me han impedido causar un daño grave.

Answer 3

1. si es posible, pida emparejarse con alguien
2. siempre cuente hasta 3 antes de presionar Enter (si está solo, ya que esto enfurecerá a su compañero).

Answer 4

¡Controla dos veces, confía una vez!

Answer 5

¿Mi forma # 1 de tener cuidado con una base de datos en vivo? No lo toques. :)

Las copias de seguridad pueden deshacer el daño que inflija en la base de datos, pero es probable que presente efectos secundarios negativos durante ese lapso de tiempo.

No importa cuán sólido piense que es el guión con el que está trabajando, ejecútelo durante 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.

Answer 6

A menudo, antes de hacer una ACTUALIZACIÓN o ELIMINAR, escribo el SELECCIONAR equivalente.

Answer 7

Agregaré a las recomendaciones de hacer BEGIN TRAN antes de su ACTUALIZACIÓN, solo que no olviden hacer el COMPROMISO; puede hacer tanto daño si deja abierta su transacción no comprometida. No se distraiga con teléfonos, compañeros de trabajo, almuerzos, etc. cuando se encuentre en medio de actualizaciones o encontrará que todos los demás están encerrados hasta que COMPROMETEN o RETREN.

Answer 8

Asegúrese de especificar una cláusula where cuando elimine registros.

Answer 9

Como ejemplo, creo SQL como este

--Update P Set
--Select ID, Name as OldName, 
    Name=''Jones''
From Person P
Where ID = 1000

Destaco el texto desde el final hasta Seleccionar y ejecutar ese SQL. Una vez que verifico que está extrayendo el registro que deseo actualizar, presiono shift-up para resaltar la instrucción Update y ejecutar eso.

Tenga en cuenta que utilicé un alias. Nunca actualizo un nombre de tabla explícitamente. Siempre uso un alias

Si hago esto junto con transacciones y rollback / commits, estoy realmente a salvo.

Answer 10

Copia de seguridad o volcado de la base de datos antes de comenzar.

Answer 11

Cree un usuario de solo lectura (u obtenga el DBA para hacerlo) y solo use ese usuario para mirar el DB. Agregue los permisos apropiados al esquema para que pueda ver el contenido de procedimientos almacenados / vistas / disparadores / etc. pero no tiene la capacidad de cambiarlos.

Answer 12

Diferentes colores por entorno: configuramos nuestro desarrollador PL / SQL (IDE para Oracle) para que cuando inicie sesión en el DB de producción, todas las ventanas estén en rojo brillante. Algunos han llegado incluso a asignar un color diferente para el desarrollo y la prueba.

Answer 13

Haga una copia de seguridad primero: debe ser la ley número 1 de sysadmining de todos modos

EDITAR : incorporando lo que otros han dicho, asegúrese de que sus ACTUALIZACIONES tengan cláusulas WHERE apropiadas.

Idealmente, nunca debería cambiarse una base de datos en vivo (más allá de INSERT y mantenimiento básico). Cambiar la estructura de la base de datos en vivo está especialmente cargada de potencial mal karma.

Answer 14

Los datos siempre deben implementarse en vivo a través de scripts, que se pueden ensayar tantas veces como sea necesario para hacerlo correctamente en dev. Cuando hay datos dependientes para que la secuencia de comandos se ejecute correctamente en el desarrollador, colóquelo de forma adecuada; no puede salirse con la suya con este paso si realmente quiere tener cuidado.

Answer 15

Mi regla (como desarrollador de aplicaciones): ¡No lo toques! Para eso están los DBA entrenados. Diablos, ni siquiera quiero permiso para tocarlo. :)

Answer 16

NUNCA haga una actualización a menos que esté en una BEGIN TRAN t1, no en una base de datos de desarrollo, ni en producción, ni en ningún lado. NUNCA ejecute COMMIT TRAN t1 fuera de un comentario - siempre escriba

--COMMIT TRAN t1

y luego seleccione la declaración para ejecutarla. (Obviamente, esto solo se aplica a los clientes de consultas GUI.) Si hace estas cosas, se convertirá en una segunda naturaleza para hacerlas y no perderá casi ningún momento.

De hecho, tengo una macro de "actualización" que mecanografía esto. Siempre pego esto para configurar mis actualizaciones. Puede crear uno similar para eliminar e insertar.

begin tran t1
update 
set 
where 
rollback tran t1
--commit tran t1

Answer 17

Para agregar a lo que dijo @ Wayne , escriba su WHERE antes del nombre de la tabla en una declaración DELETE o UPDATE .

Answer 18

Para responder mi propia pregunta:

Al escribir una declaración de actualización, escríbala fuera de orden.

1. Escribir UPDATE [table-name]
2. Escribe WHERE [conditions]
3. Regrese y escriba 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. Imposible que la update person set email = ''[email protected]'' para que esté sentado en la ventana de consulta, listo para ejecutarse mediante una pulsación de tecla fuera de lugar, listo para estropear cada fila de la tabla.

Editar: Como han dicho otros, escriba la cláusula WHERE para sus eliminaciones antes de escribir DELETE .

Answer 19

RESPALDA TUS DATOS. Lo aprendí de la manera difícil trabajando con las bases de datos de clientes regularmente.

Answer 20

Realice los cambios en una copia y, cuando esté satisfecho, aplique la solución en vivo.

Answer 21

Si está utilizando Oracle u otra base de datos que lo soporte, verifique sus cambios antes de hacer un COMMIT.

Answer 22

Si estoy actualizando una base de datos con una secuencia de comandos, siempre me aseguro de poner un punto de corte o dos al comienzo de la secuencia de comandos, en caso de que ejecute la ejecución / ejecución por accidente.

Answer 23

Siempre agregue una cláusula de uso.

Answer 24

Siempre asegúrese de que sus ACTUALIZACIONES y SUPRIMIENTOS tengan la cláusula WHERE adecuada.

Answer 25

Siempre comente las consultas destructivas (insertar, actualizar, eliminar, eliminar, alterar) al escribir consultas ad hoc en el Analizador de consultas. De esta 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 primero su declaración where, con una selección, y asegurarse de que está alterando los datos correctos.

Answer 26

Tal vez considere no usar ningún borrado o eliminación en absoluto. O tal vez reduzca los permisos de usuario para que solo un usuario de base de datos especial pueda eliminar / eliminar cosas.

Answer 27

Tres cosas que aprendí a lo largo de los años ...

Primero, si está haciendo actualizaciones o elimina datos en vivo, primero escriba una consulta SELECT con la cláusula WHERE que va a utilizar. Asegúrate de que funcione. Asegúrate de que sea correcto. A continuación, anteponga la sentencia UPDATE / DELETE a la cláusula WHERE de trabajo conocida.

Nunca quieres tener

DELETE FROM Customers

sentado en su analizador de consultas esperando a que escriba la cláusula WHERE ... accidentalmente pulse "ejecutar" y acaba de matar a su tabla de clientes. Oops.

Además, según su plataforma, descubra cómo realizar una copia de seguridad rápida de una tabla. En SQL Server 2005,

SELECT *
INTO CustomerBackup200810032034
FROM Customer

copiará cada fila de la tabla completa del Cliente en una nueva tabla llamada CustomerBackup200810032034, que luego puede eliminar una vez que haya hecho las actualizaciones y se haya asegurado de que todo esté bien. Si sucede lo peor, es mucho más fácil restaurar los datos que faltan de esta tabla que tratar de restaurar la copia de seguridad de la noche anterior desde el disco o la cinta.

Finalmente, desconfíe de las eliminaciones en cascada de deshacerse de las cosas que no tenía la intención de eliminar: compruebe las relaciones de las tablas y las restricciones clave antes de modificar nada.

Answer 28

siempre pruebe cualquier consulta más allá de seleccionar en los datos de desarrollo primero para asegurarse de que tenga el impacto correcto.

Answer 29

BEGIN TRANSACTION;

De esa forma puede deshacerse después de un error.

Answer 30

• Nadie quiere una copia de seguridad, pero todos claman por la recuperación
• Cree su base de datos con referencias de clave externa, porque debe:
• hágalo lo más difícil posible para actualizar / eliminar datos y destruir la integridad estructural / algo más con eso
• Si es posible, ejecute en un sistema donde tenga que confirmar los cambios antes de almacenarlos permanentemente (es decir, desactivar la confirmación automática mientras repara el db)
• Intenta identificar las clases de tu problema para que entiendas cómo solucionarlo sin problemas
• Obtenga una rutina para reproducir copias de seguridad en una base de datos, siempre tenga a mano una segunda base de datos en un servidor de prueba para que pueda trabajar en eso
• Porque recuerda: si algo falla totalmente, debes volver a ponerlo en funcionamiento lo más rápido posible

Bueno, eso es todo lo que puedo pensar ahora. Tome los pasajes en negrita y verá cuál es el # 1 para mí. ;-)