Üretim veritabanı verilerini güvenle sabitleme

Hatalar olur ve bazen verinin üretimde sabitlenmesi gerekir. Büyük bir şirket açısından bu konuda en güvenli yol nedir? Yardımcı olabilecek araçlar var mı? İşte bu gereksinimi yönlendiren bazı hususlar ...

1. Sorguyu kimin koyduğunu ve ne koştuğunu günlüğe kaydetmemiz gerekir
2. İdeal olarak, kişiye yalnızca ilgili tablolara karşı sorguları ve kısa bir süre için sorgular yürütmesine izin vermeliyiz.
3. Sorguları neyin çalıştırdığı olursa olsun, uzun çalışma ve kilitleme SQL'in açıkça izin almadan çalışmasına izin vermemek için bu konuda bazı akıllılara ihtiyaç duyuyor.
4. Bu işlem DB agnostik olmalı ya da en azından DB2, Oracle ve SQL Server'ı anlamalıdır.

Geçici sorun giderme sorgularının "yanlış olanı" yapma riskini azaltmaya çalışıyoruz ve aynı zamanda sürece bir miktar güvenlik / audtis ekliyoruz. Düşünceler veya Fikirler?

Üretim veritabanlarını hiçbir zaman manuel olarak güncellemeyin.

Senaryoları yaz.

Üçlü olarak kontrol edin ve birden fazla kişinin yapmasını sağlayın, sadece üç kez yapan tek bir kişi değil.

Bu komut dosyalarına değişiklik sonrası doğrulama sorguları ekleyin.

Durum ne zaman izin verirse, değişiklik sonrası onaylama çalıştırıldıktan sonra, tüm değişikliği sonunda geri alınmış bir işlem içinde test edin. Sonuçlardan emin olduğunuzda, geri alma işlemini bir taahhüt olarak değiştirin.

Bu komut dosyaları ve nauseam'i test veritabanına karşı test edin.

Komut dosyasını üretim veritabanına karşı çalıştırmadan önce yedekleyin.

Komut dosyalarını çalıştırın.

Değişiklik sonrası onaylama komut dosyalarını kullanarak değiştirilen verileri kontrol edin, onaylayın ve üçlü kontrol edin.

Yine de görsel olarak kontrol et.

Bir şey görünmüyorsa, geri dönün ve yedeği geri yükleyin.

Her şeyin yolunda olduğuna tamamen emin oluncaya ve ilgili (işletme) yöneticilerinden ayrıldığınızdan emin oluncaya kadar değişen verilerle üretim verileri olarak devam etmeyin.

Marjan Venema'nın cevabı teknik olarak geçerlidir ve mümkün olduğunda takip edilmelidir. Ne yazık ki, Marjan bir teoriye ya da işleri net bir şekilde yapmaktan hoşlanan bir saf veritabanı yöneticisine göre cevap veriyor . Uygulamada, bazen iş kısıtlamaları işleri temiz bir şekilde yapmayı imkansız hale getirir.

Aşağıdaki durumu düşünün:

1. Yazılım ürününde, veritabanında veri tutarsızlığı olduğunu düşündüğünü tespit ettiğinde çalışmayı durdurmasına neden olan bir hata var.

2. Uygulamadaki hatayı düzeltebilecek tüm geliştiricilere erişilemez,

3. Şirket şu anda saatte binlerce dolar kaybediyor (diyelim ki 6 000 dolar yani dakikada 100 dolar),

4. Hata, biri büyük olan birkaç tabloyu etkiliyor ve şemayı değil, yalnızca verileri ilgilendiren

5. Böceği atlatmak için, hem kaldırılmasını hem de değiştirilmesini içeren verileri biraz denemelisiniz.

6. Veri tabanı büyüktür ve yedeği almak veya geri yüklemek üç saat sürecektir.

7. Son tam yedekleme üç hafta önce alındı; ayrıca günlük artımlı yedeklemeler de vardır ve son günlük artımlı yedekleme 14 saat önce yapılmıştır,

8. Veritabanı yedeklemelerinin güvenilir olduğu varsayılır; son zamanlarda da dahil olmak üzere, ciddi bir şekilde test edildiler,

9. 14 saatlik veri kaybı kabul edilemez, ancak bir ila iki saatlik veri kaybı,

10. Aşama ortamı son altı ay önce kullanılmış; güncel değil gibi görünüyor ve ayarlanması saatler sürebilir,

11. Veritabanı Microsoft SQL Server 2008 Enterprise'dır.

Bir şeyler yapmanın temiz yolu şudur:

1. Yedekleme ortamındaki yedeği geri yükleyin,

2. Orada deney,

3. Son senaryoyu iki kere kontrol et,

4. Komut dosyasını prodüksiyon sunucusunda çalıştırın.

Sadece ilk adım şirketinize 18.000 dolara mal olacak. Üçüncü adımı kusursuz bir şekilde uygularsanız, risk oldukça düşüktür, ancak aşırı baskı altında çalıştığınızdan, risk çok daha yüksek olacaktır. Aşamada mükemmel çalışan bir senaryo ile bitebilir, daha sonra üretim veritabanını mahvedebilirsiniz.

Bunun yerine, böyle yapabilirdi:

1. Anlık görüntü oluşturma (Microsoft SQL Server bunu destekler ve yedeklenmesi bir saat süren bir veritabanının görüntüsünü geri almak (ve oluşturulacak hiçbir şey değildir) sanırım; diğer veritabanı ürünlerinin de anlık görüntüleri desteklediğini düşünüyorum),

2. Bir şey yanlış giderse, anlık görüntüye geri dönerek doğrudan üretim veritabanını deneyin.

Bir temizleyici veri tabanını temiz bir şekilde düzeltirken ve şirketinin 20.000 dolarını aşarak zaman baskısı verilen şeyleri berbat etme riski olsa da, iş kısıtlarını göz önünde bulunduran bir veritabanı yöneticisi veri tabanını bir şekilde düzeltir. hızlı bir şekilde yaparken riskleri en aza indirecektir (anlık görüntüler sayesinde).

Sonuç

Ben kendimde saf biriyim ve işleri temiz olmayan bir şekilde yapmaktan nefret ediyorum. Bir geliştirici olarak, değiştirdiğim kodu yeniden alıyorum, yeniden yapılandırılamayan zor kısımları yorumluyorum, kod tabanını birim sınaması yapıyorum ve kod incelemeleri yapıyorum. Ama aynı zamanda ya temiz bir şekilde yaptığınız ve ertesi gün kovulduğunuz durumları ya da işe yarayan hızlı bir saldırı yaparak hem riskleri hem de finansal etkileri en aza indirgendiğinizi de göz önünde bulunduruyorum.

Eğer bir BT uzmanı, sadece şirket adına binlerce dolarlık zarara yol açarken , sadece temizlik uğruna işleri net bir şekilde yapmak isterse , bu BT adamı işini derinlemesine yanlış anlar.

Üretim veritabanı verilerini güvenle sabitleyin. Büyük bir şirket açısından bu konuda en güvenli yol nedir? Yardımcı olabilecek araçlar var mı?

Bu bir olan kötü bir uygulama ve daha fazla veri sorunları ve sorunlar için bir davet kapısı. Bu yaklaşımı " Hızlı ve Kirli " olarak tanımlayan bir cümle bile var .

Doğrudan bir üretim sunucusunda devam eden düzeltmelerin / güncellemelerin yapılması çok tehlikelidir , çünkü bu size / şirketinize bir servete mal olur ( hukuk davaları, kötü / kirli veriler, iş kaybı vb. )

Ancak, böcekler orada olacak ve düzeltilmesi gerekiyor. De-facto endüstri standardı bir yamaları / (dağıtım komut) uygulamaktır Evreleme (prod veritabanının son kopya ile ön üretim ortamı) ve veri analisti / QA düzeltmeyi doğrulamak için izin verin. Sorunları önlemek için aynı komut dosyası sürüm denetlenmeli ve Prod ortamına uygulanmalıdır.

Bu ilgili yazıda belirtilen çok sayıda iyi uygulama vardır - Evreleme veritabanı iyi uygulamaları

Bakılması gereken iyi referanslar:

• Sabit bir hatayı ne kadar hızlı üretime sokabilirsin?
• Yazılım Geliştirme Maliyetleri Piramidi
• Test ve Hata Tespiti için Ne Kadar Zaman Tahsis Edilmeli

Çoğu kuruluşta, canlı ortamdaki verileri güncellemeye çalıştım, genellikle erişim hakları olan ve genellikle DBA gibi bir iş unvanı olan küçük bir grup insan tarafından yapıldı. Güncellemeler yalnızca az sayıda insan tarafından yapılabildiğinden, en azından verilere aşinalık kazanma ve dolayısıyla sorun riskini azaltma (ancak ortadan kaldırma) olasılığı vardır.

Güncelleme komut dosyasını yazan kişi bunu sınamada (diğer cevaplara göre) yapar ve özelliklerin 'tekrar' doğru göründüğünü belirlemediği için teknisyen olmayanlardan (sistemi tanıyanlar, ayrıca üst düzey otoriteye sahip biri) ciddi şekilde imzayı alacak kendi paranoyak testlerine ek olarak. Senaryolar ve veriler bağımsız bir şekilde, teste girmeden önce testte başka bir teknisyen (genellikle bahsettiğim DBA rolü) tarafından doğrulanacaktı. Sonuçlar beklenen değerlere göre kontrol edilir (her senaryo için benzersiz, ancak çoğu zaman satır sayıları vb.)

Çalıştığım bir şirkette, yedekleme almak gerçekçi bir seçenek değildi, ancak güncellenmesi gereken tüm satırlar güncelleme öncesinde ÖNCE referans için bir metin dosyasına yazılmıştı ve ardından güncellemeden sonra herhangi birisine başvurması gerekecek olursa tekrar. Betikler ve bu veriler uygun şekilde organize edilmiş bir Veri Değişim Günlüğünde tutulmuştur.

Her işletme benzersizdir ve bazı verileri güncelleme riskleri diğerlerine göre açıkça daha fazladır.

İnsanların bu güncellemeleri yapmak için çemberlerin içinden atlaması gereken bir sürece sahip olarak, umarız, insanların bunu son çare olarak görmesini isteyen bir kültürü tanıtır ve bunun etrafında sağlıklı bir "çifte kontrol, üçlü kontrol" tutumu yaratırsınız.

Prod'da, diğer sunucularda bulunmayan verileri düzeltmeniz gereken zamanlar olabilir. Bu sadece hatalardan değil, müşterinin hatalı gönderdiği bir dosyadan veya sisteminize sızan birinin neden olduğu bir sorundan veri içe aktarmasından kaynaklanıyor olabilir. Veya hatalı veri girişinin neden olduğu bir problemden. Veritabanınız büyükse veya zaman açısından kritikse, en son yedeği geri yüklemek ve cihazda düzeltmek için zamanınız olmayabilir.

İlk savunmanız (ve Enterprise veritabanının onsuz olamayacağı bir şey!) Denetim tablolarıdır. Kötü veri değişikliklerini geri almak için bunları kullanabilirsiniz. Ayrıca, verileri önceki durumuna döndürmek ve denetlenen verileri geri almanız gerekmeden çok önce diğer sunucularda test etmek için komut dosyaları yazabilirsiniz. O zaman tek risk, geri alınacak doğru kayıtları belirlemenizdir.

Daha sonra üretim verilerini değiştirmek için tüm komut dosyaları aşağıdakileri içermelidir:

Açık işlemlerde bulunmalı ve bir YTL Catch bloğuna sahip olmalıdırlar.

Ne olacağını gördükten sonra değişiklikleri geri almak için kullanabileceğiniz bir test moduna sahip olmaları gerekir. Değişiklik yapılmadan önce ve değişikliğin doğru olduğundan emin olmak için değişiklik yapıldıktan bir kez sonradan seçilmiş bir statüye sahip olmalısınız. Betik, işlenen satır sayısının gösterildiğinden emin olmalıdır. Parçaların yapılmasını sağlayan bir şablonda önceden ayarlanmış bazılarımız var. Değişiklikler için şablonlar, düzeltmeyi de yazarken zaman kazanmanıza yardımcı olur.

Değiştirilecek ya da güncellenecek çok miktarda veri varsa, komut dosyasını her bir parti için taahhütlü gruplar halinde çalışmak üzere yazmayı düşünün. Bir milyon kaydı düzeltirken tüm sistemi kilitlemek istemezsiniz. Düzeltmek için büyük miktarda veri kaynağınız varsa, dba'nın veya performans ayarlaması yapmak için kullanılan bir kişinin çalıştırma ve mümkünse çalışma saatleri dışında çalıştırmadan önce komut dosyasını gözden geçirdiğinden emin olun.

Daha sonra, üretimdeki herhangi bir şeyi değiştirmek için tüm komut dosyaları kod gözden geçirilir ve kaynak kontrolüne alınır. Hepsi - istisnasız.

Sonunda devs bu betikleri çalıştırmamalı. Dbas veya bir yapılandırma yönetimi grubu tarafından çalıştırılmalıdırlar. Bunlardan hiçbirine sahip değilseniz, o zaman sadece teknik lider veya daha yüksek olan insanlar eşyalarını eşyada çalıştırma haklarına sahip olmalıdır. Prod'da işleri yapan insanlar ne kadar az olursa, bir sorunu bulmak o kadar kolay olur. Scriptler basitçe çalıştırılacak, parçaların vurgulanması ve bir seferde bir adım çalıştırılmaması için yazılmalıdır. İnsanları nerede olduklarını vurgulamayı unuttuklarında sık sık belaya sokan vurgulayıcı şeyler.

Üretim veritabanlarını çalıştırırken verileri birçok kez güncelledim. Yukarıdaki cevaba katılıyorum, bunun asla standart işletim prosedürü olmayacağı yönünde.

Aynı zamanda pahalı olurdu (eachothers'in omuzlarına bakar ve belki 2 veya 3'ü tartışırdık)

Ve altın kural: daima bir update / delete / insert deyimi yapmadan önce ne yapılacağını göstermek için bir select deyimi yapın

Altın kural takımdaki diğer iki kişi tarafından uygulanıyor!

re: MainMa'nın cevabı ...

Yazılım ürününde, veritabanında veri tutarsızlığı olduğunu düşündüğünü tespit ettiğinde çalışmayı durdurmasına neden olan bir hata var.

• Bunun bir "böcek" olduğunu nereden biliyorsun? Veriler, yazılım ürünü geliştiricisinin ortaya koyduğu kurallara göre tutarsızdır.

Uygulamadaki hatayı düzeltebilecek tüm geliştiricilere erişilemez,

Şirket şu anda saatte binlerce dolar kaybediyor (diyelim ki 6 000 dolar yani dakikada 100 dolar),

• Görünüşe göre, 100 $ / dakika'lık bir kayıp şirket yöneticileri için yetkin geliştiricilerin hatalarını düzeltmek ve veritabanını geri yüklemenize yardımcı olmak için geri dönmelerini sağlayacak ve bulmalarını sağlayacak kadar önemli değildir.

Hata, biri büyük olan birkaç tabloyu etkiliyor ve şemayı değil, yalnızca verileri ilgilendiren

• Tüm veritabanı sorunları şemaya "ilişkin". Şemanın nasıl tasarlandığı, bu sorunu nasıl çözeceğinizi belirleyen şeydir.

Böceği atlatmak için, hem kaldırılmasını hem de değiştirilmesini içeren verileri biraz denemelisiniz.

• Evreleme veritabanınız bunun için var. Tam çevrimiçi bir üretim yedeklemesi yaptıktan hemen sonra, üretim veritabanındaki "bozuk" verilerle yeniden doldurmanız gerekebilir.

Veri tabanı büyüktür ve yedeği almak veya geri yüklemek üç saat sürecektir.

• O zaman sorunu hemen incelemeye başlasanız, sorunu analiz ederken, düzeltme komut dosyalarınızı geliştirirken, bunları geliştiricilerle ve size yardımcı olan diğer DBA'larla birlikte test edip rafine ederken çalışabilirsiniz.

Son tam yedekleme üç hafta önce alındı; ayrıca günlük artımlı yedeklemeler de vardır ve son günlük artımlı yedekleme 14 saat önce yapılmıştır,

• En az günlük tam çevrimiçi yedeklemeniz yok mu? Sarhoşsun. Ama muhtemelen buna alışkınsın. Yukarıda başlattığın tam yedeklemenin çalışıyor olması iyi bir şey. Günlük çevrimiçi yedeklemelerle kaçınılabilecek maliyetlerin her dakikasında yönetimin takip ettiğinden emin olun.

Veritabanı yedeklemelerinin güvenilir olduğu varsayılır; son zamanlarda da dahil olmak üzere, ciddi bir şekilde test edildiler,

• Mükemmel! O zaman veritabanını bir kereden fazla geri yüklemeniz gerekmeyebilir.

14 saatlik veri kaybı kabul edilemez, ancak bir ila iki saatlik veri kaybı,

• Tanımladığınız senaryoya göre, tüm bahisler kapalı. Bu bir "bilgi felaket yönetimi" durumudur. Bu süreçte yönetimin yapması için iyi bir şey, gelecekte priper yedeklemeleri ve kurtarma prosedürleri ve kaynakları ile önlenebilecek maliyetleri belgelendirmektir.

Aşama ortamı son altı ay önce kullanılmış; güncel değil gibi görünüyor ve ayarlanması saatler sürebilir,

• Yedekleme sisteminiz çevrimiçi yedeklemeleri destekliyorsa (yani, yedekleme sırasında veritabanı tamamen çalışır durumdaysa), yedeklemeyi yavaşlatmaktan kaçınmak için yeterli donanım kaynağınız varsa, hazırlama veritabanını aynı anda yeniden oluşturmak için özü yapabilirsiniz.

Veritabanı Microsoft SQL Server 2008 Enterprise'dır.

• Bütün bunları yapmak zor ama imkansız değil. İyi şanslar!