DBCC CHECKDB hayati önem taşır SQL Server veritabanlarının bozulma olmadığından% 100 emin olması için . Bununla birlikte, büyük boyutta büyüyen veritabanları nedeniyle, 24x7 kadar olduğunu iddia ettiğinizde bir bakım penceresi bulmak çok zordur. Yıllar boyunca, SQL Server ekibi, özellikle donanımın neden olduğu Fiziksel bozulma ile ilgili en yaygın yolsuzluk biçimlerini tespit edecek çeşitli mekanizmalar uygulamıştır.
SQL Server 2005 ve üzeri, veritabanı sayfalarındaki fiziksel bozulmayı proaktif olarak tespit etmenize ve böylece G / Ç sistemine yazılırken her sayfaya bir sağlama toplamı eklemenize ve sağlama toplamını diskten okunduğu gibi doğrulamanıza yardımcı olabilecek PAGE_VERIFY = CHECKSUM'a sahiptir.
Ayrıca, CHECKSUM ile yedekleme (tam veya diferansiyel) donanımın neden olduğu G / Ç bozulmalarını algılamayı garanti eder.
Bu nedenle, bozulmanın donanım tarafından, SQL Server bunu tespit etmek ve raporlamak için iyi bir iş çıkarır. (Ayrıca, yolsuzlukla ilgili önemli Uyarıları da ayarladığınızdan emin olun ).
Bununla birlikte, mantıksal bozulma , scribbler kaynaklı hatalar - bellek içi sayfalar, SQL Server işlemi içinde çalışan üçüncü taraf koduyla veya Windows çekirdek modunda ve / veya SQL Server'da yürütülmesi gereken ayrıcalıklara sahip sürücüler veya diğer yazılımlarla bozulduğunda Hatalar , vb. Yukarıdaki yöntemler kullanılarak tespit edilemez ve dolayısıyla CHECKDB resmedilir .
DBCC CHECKDB, başka bir yolla algılanamayan olası bozulmalar için sayfa başlıklarını kontrol etmeyi içeren daha kapsamlı bir kontrol gerçekleştirir.
Orada herhangi bir komut dosyası var mı?
Tekerleği yeniden icat etmek yerine, Ola'nın SQL Server Bütünlük Kontrolü çözümüne göz atmanızı şiddetle tavsiye ederim
DBCC CHECKDB'yi verimli bir şekilde çalıştırmak:
CHECKDB'yi çalıştırmak için büyük veritabanlarına veya çok sayıda veritabanına sahip bakım penceresinde sıkı olduğunuzda yaratıcı olmanız yeterlidir.
SQLSkills eğitimine katıldıktan sonra, çevremde uyguladığım şey:
- hangi tabloların kontrol edilmesi gerektiğine öncelik verin.
- tabloları farklı önceliklere sahip gruplara ayırın ve ardından
DBCC CHECKTABLEçalışan DBCC CHECKALLOCveDBCC CHECKCATALOG
- Tablo adlarını önceliklerle birlikte saklayacak bir çalışan tablosu oluşturun. Tüm yüksek öncelikli tabloların (büyük ölçüde büyük olan) bir grupta olmadığından emin olun, aksi takdirde CHECKDB'niz hiç tamamlanmaz.
- Alt tablonuzda, CHECKDB'nizin bakım penceresini geçtikten sonra öldürüleceği zaman düzenlenecek bir zaman aşımı sütunu bile olabilir
- O dönemde masaya başına ne kadar sürdüğünü ekleyin
DBCC CHECKTABLE, DBCC CHECKALLOCve DBCC CHECKCATALOG. Böylece, çeklerinizin genellikle ne kadar sürdüğünü anlayabilirsiniz .
NOINDEXKullanıcı tablolarındaki Kümelenmemiş Dizinleri denetlemediğinden, işlemi hızlandıracağı için seçenekle de çalışabilirsiniz . Hiçbir veri kaybolmadığından ve gerekirse Dizini bırakıp yeniden oluşturabildiğiniz için Veri bozulması kadar kritik olmadığı için bunun bir avantajı vardır.
Açıkçası, Enterprise sürümü DBCC deyimlerinin Paralel yürütülmesinden yararlanabilir, ancak tüm CPU'nuzu alabileceği için MAXDOP ayarına dikkat edin. Bu, Kaynak Yöneticisi tarafından sınırlandırılabilir.
Not: SPARSE sütununuz varsa, CHECKDB'niz burada açıklandığı gibi yavaş yavaş ölecektir .
Son olarak, mevcut tüm araç setini + veritabanı sunucusu donanım sisteminize olan inancınızı ve en önemlisi verilerinizin değerini kullanarak veritabanı bozulmasını nasıl önleyeceğinizdir.
Bazı mükemmel referanslar: