Yanlış veritabanını yanlışlıkla değiştirme riskini nasıl en aza indirebilirim?

Sadece Nesne Gezgini'nde bir sunucu ile bağlantıyı kesmenin, o sunucuda zaten açık olan sorgu pencerelerini yürütmenizi engellemediğini öğrendim.

Benim durumum şöyle: dev / evreleme sunucumuza ve üretim sunucumuza bağlanmak için kullandığım bir SSMS örneğim var. Üretimle olan bağlantımı kapatmam gerektiğini düşündüğüm için dev üzerindeki bir sürü veriyi silmek zorunda kaldım, ancak kullandığım sorgu penceresine dikkat etmedim. (Neyse ki sadece birkaç saatlik bir yedek aldık.)

Üretim verilerini imha eden ilk kişi değilim ve eminim ki son kişi olmayacağım. Bu yüzden, yanlış veritabanında sorgu yürütme riskini en aza indirmenize yardımcı olan kontrol listeleri, en iyi uygulamalar vb. Arıyorum. Daha önce başınıza geldi mi ve bundan kaçınmak için iş akışınızı nasıl uyarladınız?

SSMS'de yapmak istediğim bir şey, veritabanına bağlanırken Özel Renkler kullanmaktır. Böylece Canlı veritabanları için güzel bir parlak Kırmızı ve geliştirici veya test sistemleri için yumuşak mavi veya yeşil seçersiniz. Dahili SSMS'yi kullanıyordum, ancak bu günlerde SSMS Tools Addon Color kodlamasını tercih ediyorum.

Ya da SSMS Araçları için böyle (Gerçekten güzel bir eklenti ve rengi yerleşik olarak olduğu gibi altta değil, üstte olduğunda daha iyi buluyorum)

Kim soracak bağlı olarak, biraz daha fazla iş gerektirecektir, ama her zaman için deyimi altında kullanma alışkanlığı var bütün herkes için üretim ya da üretim öncesi sorgu pencereler ve UPDATE, DELETEve INSERTtüm ortamlarda ifadeleri.

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

Bunu görürsem, hemen "Biliyorum, o sorgu penceresi hala bağlı" ya da "Ah bok, otomatik olarak sahip olmamam gereken bir şey yaptım" - ve evet, veritabanını nesne gezgini içinde kapatabilirsin, ama bir sorgu penceresi hala bağlanabilir. Aklımda, tüm üretim sorguları vurgulanmalı ve birlikte çalıştırılmalıdır BEGIN TRAN; her şeyde kazara bir F5, her şeyi geri almalı, değil COMMIT. Bunun yaptığı, kullanıcının eylemlerinin bilincinde olmaya zorlanmasıdır; Yediğiniz her öğünün fotoğrafını çekmeye benzer şekilde kilo vermenize yardımcı olur çünkü durup ne yaptığınızı düşünmeniz gerekir.

Yapılması daha uzun sürüyor mu? Evet. Hataların% 100'ünü durdurur mu? Evet, çünkü hiçbir şey yapmaz, el ile zorlamadığım sürece COMMIT, yazdıktan sonra, doğası beni düşünmeye zorlar COMMIT.

Üretim değişiklikleri için ikinci bir kullanıcı hesabı oluşturun ve hesabınızın şu anda sahip olduğu erişimi iptal edin. Üretimde bir şeyler yapmak istediğinizde ssms'yi ikinci kullanıcı olarak çalıştırabilirsiniz.

EDIT: Bu yalnızca etki alanı oturum açma durumunda yararlı olacaktır. İki ayrı alan adı hesabınız varsa, DEV ve PROD için ayrı SSMS bulut sunucularına sahip olmanız gerekir. Etki alanı hesaplarını kullanmıyorsanız, bu öneri size çok fazla yardımcı olmaz.

Ayrıca, ayrı alan adı hesapları kullanıyorsanız, kullanıcı başına SSMS renk ayarlarınızı ayarlayabilirsiniz; belki PROD'ye bağlanan hesap için parlak kırmızı bir arka plana sahip olabilirsiniz.

İşte hem akla geldiği iyi bir beyaz kağıt geçerli: http://download.microsoft.com/download/D/2/D/D2D931E9-B6B5-4E3B-B0AF-22C749F9BB7E/SQL_Server_Separation_of_Duties_White_Paper_Jul2011.docx

Günlük giriş hesabınıza tam SA erişimi vermeme gibi konuları tartışır.

Eklentime bir göz atın: SSMSBoost. Tam olarak ihtiyacınız olan şey var. Mevcut veritabanınızı izlemesi ve rengini değiştirmesi için SSMS Durum çubuğu renklendirme özelliğini geliştirdim. Ayrıca "önemli DB uyarısı" kayan araç ipucu ekleyebilirsiniz:

Bu özellik hakkında daha fazla bilgiyi buradan edinebilirsiniz: http://www.ssmsboost.com/Features/ssms-add-in-preferred-connections

İşlerimden birinde bu amaçla bir araç geliştirdik.

PROD'da bir ifade çalıştırmak istiyorsanız, sizi yazmaya zorladı:

run_sql servername PROD <file_with_sqlstatements>.sql

Sonuçları bir günlük dosyasına yazar ve yürütmeyi yönetim veritabanımızdaki bir günlüğe ekler. Örneğin, belirli bir masayı değiştiren son kişinin kim olduğunu bulmak istediğimizde çok kullanışlı geldi.

SSMS'de, kayıtlı sunucularınız olduğunda, örneğin tüm PROD bağlantılarının altında kırmızı bir renk olması için bir bağlantıya belirli bir renk uygulayabilirsiniz. Ancak mümkünse üretim sunucusunda GUI araçlarını kullanmaktan kaçınmak en iyisidir.

Zaten burada benzer bir şey göremediğim için sadece iki ipucu daha:

1. İş akışımda genellikle tek bir pencerede birden çok ifadeyle çalışırım ve select-text-then-run akışına alışkınım. Ancak, hiçbir metin seçilmediğinde yanlışlıkla F5 tuşuna basmaktan ve sonuç olarak bir pencerede tüm ifadeleri yürütmekten korkuyorum. Her yeni pencere açtığımda, SQL'in derlemeyi reddedeceği çöpleri yazmaya başlıyorum. Bu, tüm grubu etkin bir şekilde çalıştırılamaz hale getirir. (Uyarı! Ayrılmış birden çok toplu GOiş kullanıyorsanız, toplu iş başına çöp gerekir.)

2. Üretim sunucusunda veri değişiklikleri yaparken (veya aşırı bakıma ihtiyaç duyduğumda) - örtük işlemler çok faydalıdır ( SET IMPLICIT_TRANSACTIONS ONSSMS'de bir seçeneği değiştirirsiniz, böylece seçenek her yeni pencere için etkili olur). Bu şekilde işlemde olmayan her ifade yeni bir işlem başlatır. Sadece istediğim şeyi iki kez yaptığımdan emin olursam taahhüt ederim.

Üretim veritabanını yapılandırmış olan tek bir Windows kullanıcısı kullanmayı deneyin . Bu kullanıcının tüm renk temasını kırmızıya ayarlayın. Hızlı kullanıcı değiştirme ile bu sorun olmamalı.

Üretim kimlik bilgilerini hiçbir zaman geliştirme makinesindeki bir hesapta kullanmayın. Kısa bir telefon görüşmesi veya iş arkadaşı sorusu ve daha sonra yeni test grubunuz için her şeyi mutlu bir şekilde siliyorsunuz ...

Başka bir seçenek (aynı fikir), farklı bir temaya sahip uzak bir masaüstü veya virtül makinesi kullanmaktır.

F5 tuşuna basıldığında sorgu penceresindeki her şeyin yürütülmesini önlemenin oldukça basit bir yolu, tüm içeriği / * ve * / ile çevrelemek ve böylece her şeyi bir yorum yapmak olacaktır.

Yine de bir açıklamada yer alsalar da, istediğiniz ifadeleri vurgulayarak ve her zamanki gibi F5 tuşuna basarak yürütebilirsiniz.

Not: Bu yöntemi seçerseniz, sözdizimi vurgulama veya otomatik tamamlamadan yararlanamayacaksınız, ancak bu özellikleri çok fazla kullanmıyorsanız, zarar görmenin% 100 imkansız olduğundan emin olmak için onları feda etmek faydalı olabilir. yanlışlıkla F5 ile veritabanı.

Düzenleme: Ayrıca sorgu penceresinde herhangi bir yerde / * * / kullanamayacaksınız, aksi takdirde sonraki kodu açacaksınız. Bunun yerine - notasyonu ile sopa gerekir.

Swasheck'in orijinal soru hakkındaki yorumuyla anlaşarak, yürütmeye ne dersiniz ...

@@ sunucuadı + '\' + @@ hizmet adını seçin

... herhangi bir DML çalıştırmadan, hatta hangi örneğe bağlandığınızı görmek için durum çubuğuna bakmadan, hatta bir işlem yaptığınızda tüm DML'yi çalıştırmadan önce bir hata yaptığınızı fark ederseniz geri alabilirsiniz? Burada birçok harika öneri var, ancak temel olarak, potansiyel olarak yıkıcı DML söz konusu olduğunda, hile sadece sizi şimdiye kadar alacaktır. Her zaman kontrol ederim, tekrar kontrol ediyorum ve tekrar kontrol ediyorum. Ve az miktarda veriyle uğraşıyorsam, DML'den önce yeni bir tabloya SEÇEBİLİRİM, DML'imi çalıştırabilir, işlerin doğru çalıştığından emin olmak için bazı karşılaştırmalar yapabilir, ardından "yedekleme" tablosunu bırakabilirim. Daha zekice çalış daha fazla değil.