SQL Server Bakım Planı - Görevler ve Çizelgeleme Konusunda En İyi Uygulamalar

Sql Server 2005 veritabanlarımız için bir bakım planı hazırlamakla görevliyim. Yedeklemeler için biliyorum Her 15 dakikada bir günlük tam veritabanı yedeklemesi ve işlemsel günlük yedeklemeleri yapmak istiyorum. Benim sorunum başka hangi görevleri yapmak istediğimi ve ne sıklıkla yapmam gerektiğini bulmak.

Şimdiye kadar aklımda. Düşüncemde herhangi bir kusur varsa veya bunu yapmanın daha iyi bir yolu varsa beni düzeltin.

1. Yedekleme - Tüm Tablolar, Tam Yedekleme (günlük)
2. Yedekleme - Seçili Tablolar, Tam Yedekleme (saat başı)
3. Yedekleme - İşlem Günlükleri (her 15 dakikada bir)
4. Veritabanı bütünlüğünü kontrol edin (günlük)
5. Dizini yeniden düzenle (günlük)
6. İstatistikleri güncelle (günlük)
7. Veritabanını küçültme (haftalık)
8. Dizini yeniden oluştur (haftalık)
9. Bakım temizliği (günlük)

Bir süre önce (başka bir işte benzer bir plan hazırladığımda) bu görevlerin bazılarının günlük olarak çalıştırılmasının gerekmediğini veya günlük olarak çalıştırılmaması gerektiğini hatırladım. Hangileri, benden kaçar. Bir felakette veri kaybını azaltacak, ancak yoğun saatlerde çalışırken sistemi vergilendirmeyecek (ve aynı zamanda performansı artıracak) daha iyi bir bakım planı oluşturmak için biraz rehberlik kullanabilirim.

Josh,

Bu, tüm DBA'lar için çok yaygın bir iştir ve doğru cevap her biri ve her sunucu için aynı değildir. Diğer birçok şey gibi, neye ihtiyacınız olduğuna bağlıdır.

Kesinlikle "Shrink Database" komutunu çalıştırmak istediğiniz gibi. Performans ve aşağıda ref onun kötülüğü size neden gösterecektir. Diske ve indeks parçalanmasına neden olur ve bu performans sorunlarına yol açabilir. Verilerin ve günlük dosyalarının büyük bir kısmını önceden tahsis ederek daha iyi durumda olursunuz, böylece otomatik büyüme başlamaz.

# 2'nizi anlamadım. seçilen tablolar tam yedekleme. Bu konuda daha fazla detay verir misiniz?

Dizine yeniden düzenleme, istatistikleri güncelleme ve dizin yeniden oluşturma işlemlerine geldiğinizde, bunun nasıl yapıldığına dikkat etmeniz gerekir, aksi takdirde daha fazla kaynak kullanmanız ve performans sorunlarıyla sonuçlanmanız gerekir.

Dizinleri yeniden oluşturduğunuzda, dizinlerin istatistikleri fullscan ile güncellenir, ancak bundan sonra istatistikleri güncellerseniz, bunlar varsayılan bir örnekle tekrar güncellenecektir (birkaç faktöre bağlıdır, genellikle tablo boyutu> 8 olduğunda tablonun% 5'i MB) performans sorunlarına yol açabilir. Sahip olduğunuz baskıya bağlı olarak, çevrimiçi dizin yeniden oluşturma işlemleri yapabilirsiniz. Bu aktiviteyi yapmanın doğru yolu parçalanma miktarını kontrol etmektir ve buna bağlı olarak indeks yeniden veya indeks yeniden düzenleme + güncelleme istatistiklerini yapın. Ayrıca, hangi tabloların istatistikleri daha sık güncellemesi gerektiğini belirlemek ve istatistikleri daha sık güncellemeye çalışmak isteyebilirsiniz.

Bakım Planları Tamam, ancak SSIS’e giriş yapıp MP’leri değiştirmeden bu özelleştirmeleri yaparak bunlardan en iyi şekilde yararlanmanız zor. Bu yüzden onları kullanmamayı ve Ola Hallengren'in milletvekillerinden daha sağlam olan ücretsiz betiklerini kullanmayı tercih etmiyorum . Ayrıca, bu konuda Paul Randal tarafından referans yapılan makaleye göz atmanızı tavsiye ederim.

Ref: http://technet.microsoft.com/en-us/magazine/2008.08.database.aspx

Bu, sorunuza kapsamlı bir cevap değil, iyi bir başlangıç ​​noktasıdır. HTH ve başka sorunuz / yorumunuz varsa bize bildirin.

Bir cevabı kabul etseniz bile, deneyimimi paylaşacağım. Belki yardımcı olacak :-).

1. Tam günlük yedekleme (günlük) - harika, ancak önceden belirlenmiş bir sürenin ardından boş alanı denetlemeyi ve eski dosyaları kaldırmayı unutmayın.
2. Seçili tabloları yedekle (saat başı) - neden buna ihtiyaç duyduğunuzu anlamayın, diferansiyel yedeklemelere devam etmeniz daha iyi olur. Yalnızca belirli tabloları nasıl yedeklersiniz: SSIS, scriptler, bcp? Farklı yedekleme işlemleriyle ilgili olarak, günlük yedekleme rolünü çalacağınız için çok sık programlamayın.
3. İşlem günlüğü yedekleri (her 15 dakikada bir) - harika, tüm veritabanlarına ihtiyacınız olduğundan emin misiniz? Tüm veritabanları tam kurtarma modeli kullanıyor mu, kullanmıyor mu?
4. Db bütünlüğünü kontrol edin - evet, ancak ortamınızı öldürmediğinizden emin olmanız gerekir. DBCC kontrol ifadeleri kaynaklar konusunda oldukça bencildir ve tam dbs taraması yapar, bu nedenle kapalı saatlerde programlanmaları gerekir.
5. Dizini yeniden düzenle (günlük) - zorlamayın, yalnızca gerekirse yapın. Dizin DMV'sinin parçalanma ile ilgili olup olmadığını kontrol edin ve yalnızca ihtiyaçlara göre yeniden düzenleyin. Tüm endeks ve istatistik işlemlerini tek bir haftalık görevde taşımak istiyorum.
6. Güncelleme istatistikleri (günlük) - Lütfen önceki bir soruya verdiğim cevaba bakınız . Her gün yalnızca tüm istatistiklerin güncellenmesini zorlamak yerine, istatistiklerin en son ne zaman güncellendiğini kontrol etmeniz ve bazı durumlarda bunları güncellemeniz daha iyi olacaktır.
7. Veritabanını daralt (haftalık) - Ah, hayır. Lütfen Paul Randal'ın dosya küçültme ile ilgili makalesini okuyun .
8. İndeks indeksi (haftalık) - bakınız 5.

9. Bakım temizliği (günlük) - tamam.

10. Ayrıca, yedeklerinizi doğrulamak için bir görev eklemeniz daha iyi olur - RESTORE komutunun bir sürümü var (doğru şekilde hatırlıyorsam doğrula). - her gün tercih etsem de haftalık olarak söyleyelim.

Veri kaybı durumunda korunmak istediğinizi söylüyorsunuz, bu yüzden bu bakım prosedürüne sistem veritabanlarını eklemeniz gerektiğini söyleyebilirim. Ayrıca, dosyaları sunucunun kendisinden farklı bir makinede yedeklemeye de özen gösterin. Master db, msdb..etc dosyasını yeniden kurmanız gerektiğinde ne yapacağınızla ilgili bir dosyayı saklayın. Görevinizde iyi şanslar!

Geç cevap, ancak diğer okuyucular için faydalı olabilir.

Lütfen, bunlarla ilişkili görünmeyen riskleri taşıyan, yaratabileceğiniz çok sayıda bakım veya raporlama işi olduğunu unutmayın.

Günlük gerçekleştirilen diferansiyel yedekleme sırasında bir sürücü dolarsa ne olur? Ve bir dizin yeniden yapılanma işi alışılmadık uzun sürerse ne olur? Bir veri yükleme işlemi, normal işlemleri dizlerine getirerek kapsamlı kaynak çekişmesine neden olur mu? Bunların hepsi planlanmış olaylardır, ancak korumaya çalıştığımız süreçlerde önemli bozulmalara neden olabilir.

Her zaman farklı işlerin nasıl etkileşimde bulunduğunu düşünün ve zaman zaman hassas veya kaynak yoğun görevlerde çakışma olmayacak şekilde zamanlayın.

Önce bu makaleyi okumanızı öneririm: http://www.sqlshack.com/removing-the-risk-from-important-maintenance-tasks-in-sql-server/

Önemli bakım görevlerinin SQL Server'da nasıl gerçekleştirileceğini açıklar - risksiz. Örneğin - bir işlemin yürütmeden önce neye ihtiyaç duyacağının yanı sıra kullanılabilir kaynakları doğrulayan bakım işleriniz için basit kontroller oluşturabilirsiniz. Bu, ortamınızın yapmak üzere olduklarınızı idare edebilmesini sağlamanıza ve kaynaklar yetersiz olduğunda anlamlı bir hata ile iptal etmenize olanak sağlar.

1. İyi görünüyor

2. Burada Diferansiyel Yedeklemeler yapmaktan faydalanabilirsiniz. Onlara kesin bakın

3. İyi görünüyor

4. İyi görünüyor

5. Daha önce belirtildiği gibi, veritabanı küçülmeleri kötüdür, çünkü verilerinizin ve günlük dosyalarınızın fiziksel parçalanmasını sağlar, böylece daha rasgele IO okumalarına neden olur.

5, 6 ve 8: Aşağıdakilere bakınız.

Endeksler güncel istatistiklere dayandığından ve bu işlemlerin sırası oldukça önemli olduğundan bunlar gerçekten el ele gidiyor. Kuşkusuz herkes için işe yaramayabilir, benim uyguladığım temel yöntem, iki tur indeks bakımı yapmaktır. Önce kümelenmiş dizinleri, sonra da kümelenmemiş dizinleri yapıyorum. Her ikisi için de kullandığım yöntem aşağıdaki gibidir. Bir dizin yeterince büyük ve yeterince parçalanmışsa (sys.dm_db_index_physical_stats), dizini yeniden oluşturacağım (tam tarama ile bir istatistik güncellemesi içeren). Bir dizin, yeniden oluşturma için çok küçükse veya yeniden oluşturma için yeterince parçalanmamışsa (100 sayfadan az ve% 5 ila% 15 parçalanma arasında), ilk önce bir dizin yeniden düzenleme gerçekleştireceğim. Daha sonra tam tarama ile bir istatistik güncelleme yapacağım.

Şimdi, bu endeks istatistiklerini kapsar, fakat sütun istatistiklerine bir şey yapmayı ihmal eder. Haftalık olarak sütun istatistiklerini güncelleyeceğim.

Umarım bu bir şekilde yardımcı olmuştur!

"Veri kaybınızın burada yasal sonuçları olabilir" yorumunu eğildim.

Ardından, kesinlikle yedekleri kaldırabilen (ve hızlı bir şekilde felaketle sonuçlanan felaket olaylarından kurtulabilen) ve interneti çıkarabileceğiniz herhangi bir betikten daha iyi olan yedeklemeleri kaldırabilen güçlü bir 3. parti araç (DPM gibi) almak istiyorsunuz.

Yedek olmak bir şeydir. Bunları acil durumlarda nasıl kullanacağınızı bilmek başka bir şeydir.

Önemli bir başarısızlıktan sonra bir yedeği geri yükleme noktasına geliyorsanız, muhtemelen zaten stres ve baskı altında kalmışsınız demektir. 12 işlem günlüğü dosyasıyla RESTORE DATABASE deyimini kusursuzca kazma ve yazma ek yüküne gerek yok ... Ve dua etmek sizi başarısızlığa uğratmaz ...

İşyerimde, bir hafta içindeki 350Gb'lik bir veritabanını DPM kullanarak 5 dakikalık bir süre içinde herhangi bir noktaya getirebilir / geri yükleyebilirim. Bir GUI arayüzü ile. Buna değer, kitabımda.

Gerisi için, kesinlikle Ola Hallengren'in indeks senaryosuna bakınız ve parametreleri ihtiyaçlarınıza göre ayarlayınız. Şahsen, onu her gece bir saatinde yeniden tarama olmadan çalıştırmasını sağlayan zamanlanmış bir görevle birleştim, bu nedenle her seferinde en kötü endeksleri ele alır ve her cumartesi, veya listedeki tüm indeksler ne zaman parçalanmanın tam olarak yeniden taranmasına zorlar? birleştirildi.

Son olarak, sesimi "dosyalarınızı otomatik olarak daraltma, hiç kullanma" grubuna ekliyorum. Dosya Küçültme, günlüklerinizi veya DB dosyalarınızı (sonsuz döngü vb.) Aşan düzensiz bir olay gerçekleştiğinde yalnızca ara sıra kullanılan bir araçtır. Bir bakım aracı olması gerekmiyordu. Disk alanı baskınız varsa, küçültme yalnızca kaçınılmaz olanı geciktirecektir.