¿Cómo puedo minimizar el riesgo de modificar accidentalmente la base de datos incorrecta?

Aprendí por las malas que desconectarse de un servidor en el Explorador de objetos no le impide después ejecutar ventanas de consulta que ya estaban abiertas en ese servidor.

Mi situación es así: tengo una instancia de SSMS que utilizo para conectarme a nuestro servidor de desarrollo / preparación y a nuestro servidor de producción. Tuve que eliminar un montón de datos en el desarrollo, así que pensé que debería cerrar mi conexión a la producción, pero no presté atención a la ventana de consulta que estaba usando. (Afortunadamente teníamos una copia de seguridad de solo unas pocas horas).

No soy la primera persona en destruir los datos de producción y no seré el último, estoy seguro. Así que estoy buscando listas de verificación, mejores prácticas, etc. que lo ayuden a minimizar el riesgo de ejecutar consultas en la base de datos incorrecta. ¿Te ha sucedido esto antes y cómo has adaptado tu flujo de trabajo para evitarlo?

Una cosa que me gusta hacer en SSMS es usar colores personalizados al conectarme a la base de datos. Por lo tanto, elige un bonito rojo brillante para las bases de datos en vivo y un suave azul o verde para los sistemas de desarrollo o prueba. Solía ​​usar el SSMS incorporado, pero en estos días prefiero la codificación de color del complemento SSMS Tools.

O de esta manera para las herramientas SSMS (un complemento realmente agradable, y encuentro que el color es mejor cuando está en la parte superior, en lugar de en la parte inferior como el incorporado)

Dependiendo de a quién le pregunte, requerirá un poco más de trabajo, pero tuve la costumbre de usar siempre la siguiente declaración para todas las ventanas de consulta de producción o preproducción, y para todos UPDATE, DELETEy INSERTdeclaraciones en todos los entornos.

BEGIN TRAN
-- END OF QUERY WINDOWS
ROLLBACK TRAN
PRINT 'Transaction rolled back.'

Si veo esto, sabré de inmediato: "Vaya, esa ventana de consulta todavía estaba conectada" o "Oh, mierda, auto hice algo que no debería haber hecho", y sí, puedes cerrar la base de datos en el explorador de objetos, pero un La ventana de consulta aún se puede conectar. En mi opinión, todas las consultas de producción deben resaltarse y ejecutarse BEGIN TRAN; un F5 accidental en todo, debería revertir todo, no COMMIT. Lo que esto hace es obligar al usuario a ser consciente de sus acciones; similar a tomar una foto de cada comida que comes, te ayudará a perder peso porque debes detenerte y pensar en lo que estás haciendo.

¿Tarda más en hacerlo? Si. ¿Detiene el 100% de los errores? Sí, porque nada se compromete, a menos que lo fuerce manualmente COMMIT, después de escribirlo, lo que la naturaleza misma me habrá obligado a considerar COMMIT.

Cree una segunda cuenta de usuario para los cambios de producción y revoque el acceso que tiene actualmente su cuenta. Cuando desee hacer cosas en producción, puede ejecutar ssms como segundo usuario.

EDITAR: Esto solo sería beneficioso en el caso de inicios de sesión de dominio. Si tuviera dos cuentas de dominio separadas, se vería obligado a tener instancias separadas de SSMS para DEV y PROD. Si no está utilizando cuentas de dominio, esta sugerencia realmente no lo ayudaría mucho.

Además, si está utilizando cuentas de dominio separadas, puede ajustar la configuración de color de SSMS por usuario, tal vez teniendo un fondo rojo brillante para la cuenta que se conecta a PROD.

Aquí hay un buen libro blanco que también me vino a la mente: http://download.microsoft.com/download/D/2/D/D2D931E9-B6B5-4E3B-B0AF-22C749F9BB7E/SQL_Server_Separation_of_Duties_White_Paper_Jul2011.docx

Discute cosas como no darle a su cuenta de inicio de sesión diaria acceso completo a SA.

Echa un vistazo a mi complemento: SSMSBoost. Tiene exactamente lo que necesitas. He mejorado la función de coloración de la barra de estado SSMS para que rastree su base de datos actual y cambie su color. Además, puede agregar información sobre herramientas flotante de "alerta de DB importante":

Lea más sobre esta característica aquí: http://www.ssmsboost.com/Features/ssms-add-in-preferred-connections

En uno de mis trabajos desarrollamos una herramienta para este propósito.

Si deseaba ejecutar una declaración en PROD, le obligaba a escribir:

run_sql servername PROD <file_with_sqlstatements>.sql

Escribiría los resultados en un archivo de registro y agregaría la ejecución a un registro en nuestra base de datos de administración. Fue muy útil, por ejemplo, cuando queríamos averiguar quién fue la última persona en cambiar una tabla determinada.

En SSMS, cuando tiene servidores registrados, puede aplicar un determinado color a una conexión, de modo que, por ejemplo, todas las conexiones PROD tengan un color rojo en la parte inferior. Pero es mejor evitar el uso de herramientas GUI en un servidor de producción si es posible.

Solo dos consejos más, ya que no veo nada similar aquí:

1. En mi flujo de trabajo, a menudo trabajo con múltiples declaraciones en una sola ventana, y estoy bastante acostumbrado a seleccionar el flujo de texto y luego ejecutarlo. Pero siempre tengo miedo de presionar accidentalmente F5 cuando no hay texto seleccionado y ejecutar todas las declaraciones en una ventana como resultado. Entonces, cada vez que abro una nueva ventana, empiezo a escribir cualquier basura que SQL se negará a compilar. Esto efectivamente hace que todo el lote no sea ejecutable. (¡Advertencia! Si usa varios lotes separados, GOentonces se requiere basura por lote).

2. Al realizar cambios de datos en el servidor de producción (o siempre que necesito un cuidado extremo), las transacciones implícitas son muy útiles ( SET IMPLICIT_TRANSACTIONS ONo cambia una opción en SSMS para que la opción sea efectiva para cada nueva ventana). De esta manera, cada declaración que no esté en transacción inicia una nueva transacción. Solo me comprometo si me aseguro dos veces de que hice lo que pretendía.

Intente utilizar un usuario de Windows separado, que es el único que tiene configurada la base de datos de producción. Establezca todo el tema de color de este usuario en rojo. Con un cambio rápido de usuario, esto no debería ser un problema.

Nunca use las credenciales de producción en una cuenta que esté en una máquina de desarrollo. Una breve llamada telefónica o una pregunta de compañero de trabajo y luego está felizmente borrando todo para su nuevo testrun ...

Otra opción (misma idea) es usar un escritorio remoto o una máquina virtul con un tema diferente.

Otra forma bastante sencilla de evitar la ejecución de todo en la ventana de consulta cuando se presiona F5 sería rodear todo el contenido con / * y * / haciendo de todo un comentario.

Aún puede ejecutar las declaraciones que desee resaltándolas y presionando F5 de la manera habitual, aunque estén incluidas en un comentario.

Nota: si elige este método, no podrá beneficiarse del resaltado de sintaxis o el autocompletado, pero si no usa esas características tanto, podría valer la pena sacrificarlas para garantizar que sea 100% imposible de dañar la base de datos con un F5 accidental.

Editar: tampoco podrá usar / * * / en ningún lugar dentro de la ventana de consulta; de lo contrario, descomentará accidentalmente el código posterior. Necesito seguir con la notación en su lugar.

De acuerdo con el comentario de swasheck sobre la pregunta original, ¿qué hay de ejecutar ...

seleccione @@ servername + '\' + @@ servicename

... antes de ejecutar cualquier DML, o incluso mirar la barra de estado para ver a qué instancia está conectado, o incluso ejecutar todos los DML en una transacción para que pueda revertir si se da cuenta de que ha cometido un error. Aquí hay muchas sugerencias geniales, pero básicamente, cuando se trata de DML potencialmente destructivo, los trucos solo te llevarán hasta cierto punto. Siempre verifico, verifico dos veces y verifico nuevamente. Y si estoy lidiando con una pequeña cantidad de datos, incluso podría SELECCIONAR EN una nueva tabla antes del DML, ejecutar mi DML, hacer algunas comparaciones para asegurarme de que todo funcionó correctamente, y luego soltar la tabla de "copia de seguridad". Trabaja inteligentemente y no duro.