Bagaimana saya bisa meminimalkan risiko tidak sengaja memodifikasi database yang salah?

Saya baru saja belajar cara sulit yang memutuskan sambungan dari server di Object Explorer tidak menghentikan Anda setelah itu dari menjalankan jendela permintaan yang sudah terbuka di server itu.

Situasi saya seperti ini: Saya punya satu instance SSMS yang saya gunakan untuk terhubung ke server dev / staging kami dan ke server produksi kami. Saya harus menghapus banyak data pada dev jadi saya pikir saya harus menutup koneksi saya ke produksi, tapi saya tidak memperhatikan jendela permintaan yang saya gunakan. (Untungnya kami memiliki cadangan yang baru berumur beberapa jam.)

Saya bukan orang pertama yang menghancurkan data produksi dan saya tidak akan menjadi yang terakhir yang saya yakin. Jadi saya mencari daftar periksa, praktik terbaik, dll. Yang membantu Anda meminimalkan risiko mengeksekusi query pada database yang salah. Pernahkah Anda mengalami ini sebelumnya, dan bagaimana Anda menyesuaikan alur kerja Anda untuk menghindari hal ini?

Satu hal yang ingin saya lakukan di SSMS adalah menggunakan Warna Kustom saat menghubungkan ke database. Jadi, Anda memilih basis data Merah untuk Live yang bagus, dan biru atau hijau yang lembut untuk sistem dev atau pengujian. Saya dulu menggunakan SSMS inbuilt, tetapi hari ini saya lebih memilih pengkodean SSMS Tools Addon Color.

Atau seperti ini untuk SSMS Tools (Sebuah addon yang sangat bagus, dan saya menemukan warna lebih baik ketika berada di atas, daripada di bagian bawah seperti built in on)

Bergantung pada siapa Anda bertanya, itu akan memerlukan sedikit lebih banyak pekerjaan, tetapi saya terbiasa selalu menggunakan pernyataan di bawah ini untuk semua jendela permintaan produksi atau pra-produksi, dan untuk semua UPDATE, DELETEdan INSERTpernyataan di semua lingkungan.

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

Jika saya melihat ini, saya akan segera tahu, "Ups, jendela permintaan itu masih terhubung" atau "Oh sial, saya otomatis melakukan sesuatu yang seharusnya tidak saya miliki" - dan ya, Anda bisa menutup database di objek explorer, tetapi jendela permintaan masih dapat dihubungkan. Dalam pikiran saya, semua permintaan produksi harus disorot dan dijalankan BEGIN TRAN; F5 yang tidak disengaja pada semuanya, harus mengembalikan semuanya, bukan COMMIT. Apa yang dilakukan adalah memaksa pengguna untuk sadar akan tindakannya; mirip dengan memotret setiap makan yang Anda makan akan membantu Anda menurunkan berat badan karena Anda harus berhenti dan memikirkan apa yang Anda lakukan.

Apakah perlu waktu lebih lama? Iya. Apakah ini menghentikan 100% kesalahan. Ya, karena tidak ada yang pernah dilakukan, kecuali saya memaksakan secara manual COMMIT, mengetiknya, yang sifatnya memaksa saya untuk mempertimbangkan COMMIT.

Buat akun pengguna kedua untuk perubahan produksi dan cabut akses yang dimiliki akun Anda saat ini. Ketika Anda ingin melakukan hal-hal dalam produksi, Anda dapat menjalankan ssms sebagai pengguna kedua.

EDIT: Ini hanya akan bermanfaat jika login domain. Jika Anda memiliki dua akun domain yang terpisah, Anda akan dipaksa untuk memiliki instance SSMS untuk DEV dan PROD yang terpisah. Jika Anda tidak menggunakan akun domain, saran ini tidak akan banyak membantu Anda.

Juga, jika Anda menggunakan akun domain terpisah, Anda dapat menyesuaikan pengaturan warna SSMS Anda per pengguna, mungkin memiliki latar belakang merah terang untuk akun yang terhubung ke PROD.

Berikut ini adalah kertas putih yang baik yang muncul di pikiran: http://download.microsoft.com/download/D/2/D/D2D931E9-B6B5-4E3B-B0AF-22C749F9BB7E/SQL_Server_Separation_of_Dugas_White_Paper_Jul2011.docx

Ini membahas hal-hal seperti tidak memberikan akses SA harian penuh ke akun login Anda.

Lihat add-in saya: SSMSBoost. Itu persis apa yang Anda butuhkan. Saya telah meningkatkan fitur pewarnaan status-bar SSMS sehingga melacak basis data Anda saat ini dan mengubah warnanya. Selain itu Anda dapat menambahkan tooltip mengambang "alert DB penting":

Baca lebih lanjut tentang fitur ini di sini: http://www.ssmsboost.com/Features/ssms-add-in-preferred-connections

Dalam salah satu pekerjaan saya, kami mengembangkan alat untuk tujuan ini.

Jika Anda ingin menjalankan pernyataan pada PROD, itu memaksa Anda untuk menulis:

run_sql servername PROD <file_with_sqlstatements>.sql

Itu akan menulis hasilnya ke logfile dan menambahkan eksekusi ke dalam log di database manajemen kami. Itu sangat berguna misalnya ketika kami ingin mencari tahu siapa orang terakhir yang mengubah tabel tertentu.

Di SSMS, ketika Anda memiliki server terdaftar, Anda dapat menerapkan warna tertentu untuk koneksi, sehingga misalnya semua koneksi PROD memiliki warna merah di bagian bawah. Tapi yang terbaik adalah menghindari menggunakan alat-GUI pada server produksi jika memungkinkan.

Hanya dua tips lagi, karena saya belum melihat yang serupa di sini:

1. Dalam alur kerja saya, saya sering bekerja dengan banyak pernyataan dalam satu jendela, dan saya cukup terbiasa untuk memilih-teks-lalu-jalankan. Tapi saya selalu takut untuk secara tidak sengaja menekan F5 ketika tidak ada teks yang dipilih dan mengeksekusi semua pernyataan di jendela sebagai hasilnya. Jadi setiap kali saya membuka jendela baru saya mulai dengan mengetik apa pun sampah SQL akan menolak untuk dikompilasi. Ini secara efektif membuat seluruh batch tidak dapat dieksekusi. (Peringatan! Jika Anda menggunakan banyak batch yang dipisahkan dengan GOsampah maka diperlukan per batch.)

2. Ketika melakukan perubahan data pada server produksi (atau kapan pun saya membutuhkan perawatan ekstrim) - transaksi implisit sangat berguna (Anda juga SET IMPLICIT_TRANSACTIONS ONatau mengubah opsi dalam SSMS sehingga opsi ini efektif untuk setiap jendela baru). Dengan cara ini setiap pernyataan yang tidak ada dalam transaksi - memulai transaksi baru. Saya hanya berkomitmen jika saya memastikan dua kali bahwa saya melakukan apa yang saya inginkan.

Coba gunakan pengguna windows terpisah, yang merupakan satu - satunya yang memiliki database produksi yang dikonfigurasi. Atur tema seluruh warna pengguna ini menjadi merah. Dengan pergantian pengguna yang cepat ini seharusnya tidak menjadi masalah.

Jangan pernah menggunakan kredensial produksi di akun yang ada di mesin pengembangan. Panggilan telepon pendek atau pertanyaan rekan kerja dan setelah itu Anda dengan senang hati menghapus semuanya untuk testrun baru Anda ...

Pilihan lain (ide yang sama) menggunakan remote desktop atau mesin virtul dengan tema yang berbeda.

Cara lain yang agak langsung untuk mencegah eksekusi segala sesuatu di jendela kueri ketika F5 ditekan adalah dengan mengelilingi semua konten dengan / * dan * / sehingga membuat semuanya menjadi komentar.

Anda masih dapat menjalankan pernyataan yang Anda inginkan dengan menyorotinya dan menekan F5 dengan cara biasa, meskipun mereka terlampir dalam komentar.

Catatan: jika Anda memilih metode ini, Anda tidak akan dapat mengambil manfaat dari penyorotan sintaksis atau pelengkapan otomatis, tetapi jika Anda tidak menggunakan fitur-fitur itu terlalu banyak maka akan lebih baik jika mengorbankannya untuk memastikan bahwa tidak mungkin rusak 100% database dengan F5 yang tidak disengaja.

Sunting: Anda juga tidak akan dapat menggunakan / * * / di mana saja di dalam jendela kueri, jika tidak, Anda akan secara tidak sengaja membatalkan komentar kode selanjutnya. Harus tetap dengan - notasi saja.

Dalam perjanjian dengan komentar swasheck pada pertanyaan awal, bagaimana dengan mengeksekusi ...

pilih @@ servername + '\' + @@ servicename

... sebelum menjalankan DML apa pun, atau bahkan melihat bilah status untuk melihat instance apa yang terhubung dengan Anda, atau bahkan menjalankan semua DML dalam transaksi sehingga Anda dapat mengembalikannya jika Anda sadar telah melakukan kesalahan? Banyak saran bagus di sini, tetapi pada dasarnya, ketika datang ke DML yang berpotensi merusak, gimmick hanya akan membuat Anda sejauh ini. Saya selalu memeriksa, mengecek, dan memeriksa lagi. Dan jika saya berurusan dengan sejumlah kecil data, saya bahkan mungkin MEMILIH KE tabel baru sebelum DML, jalankan DML saya, lakukan beberapa perbandingan untuk memastikan semuanya bekerja dengan benar, lalu jatuhkan tabel "cadangan". Bekerja lebih cerdas, bukan lebih keras.