Merhaba, ben Kirk. Kıdemli baş mühendisim ve GSE ekibiyle birlikte çalışıyorum. Bu video, Microsoft SQL Server TSQL veritabanı aracı DBCC CHECKDB'yi incelemeye ayrılmıştır. DBCC CHECKDB'nin neden ve ne zaman çalıştırılması gerektiğini, ilgili veritabanı denetimi ve çalışma zamanı düzeyini belirleyen komut seçenekleriyle birlikte tartışacağız.
Demoya geçmeden önce tartışmak istediğimiz birkaç nokta var. DBCC CHECKDB, belirli bir SQL sunucusu veritabanındaki tüm nesnelerin mantıksal ve fiziksel bütünlüğüne bakan bir TSQL aracıdır. Ayrıca mevcut olan bazı onarım seçeneklerimiz var ve veritabanının anlık görüntüsünün kullanılmasını veya kullanılmamasını içeren bir seçenek olarak "TABLOCK" adlı bir şeyimiz de var. ESTIMATEONLY" seçeneğine, bunu neden kullanmak istediğimize ve bunun bir CHECKDB işlemi sırasında "TEMPDB" kullanımıyla ilişkili olduğuna bakacağız.
Ayrıca, "PHYSICAL_ONLY"e, yani bu seçeneği neden ve ne zaman kullanmak istediğimize de bakacağız. Ayrıca "MAXDOP" adı verilen bir şeyle CHECKDB işlemine dahil olan işlemci sayısını nasıl kontrol edebileceğimize de bakacağız. Bu noktada, DBCC CHECKDB'yi çalıştırdığımızda ne göreceğimize dair bazı örneklere bakacağız. Bu nedenle, ilk komutun kendisi tam anlamıyla DBCC CHECKDB'nin belirli bir veritabanı içinde bakması mümkün olan her şeyi kontrol edecektir.
Sonuçlar önümüzde. Bunu çalıştırdığımızda en çok ilgilendiğimiz dönüş satırı, veritabanında bulunan "ayırma hataları" ve "tutarlılık hataları" sayısıdır. Yani, sağlıklı bir "AdventureWorks2019" veritabanım var, bu yüzden her şey hatasız geri geliyor. Şimdi, bu aynı zamanda küçük bir veritabanı olduğu için gerçekten çok hızlı çalışıyor. Çok daha büyük bir veritabanımız varsa, örneğin bunun 100 katı büyüklüğünde bir veritabanımız varsa, bunu çalıştırmak çok daha uzun sürecektir.
Ve birçok kişi DBCC CHECKDB'yi ne sıklıkla çalıştırmayı denememiz gerektiğini merak ediyor ve genellikle SQL ustaları size onu mümkün olan en kısa sürede çalıştırmayı denemek istediğinizi söyleyecektir. Veritabanında herhangi bir tutarsızlık veya herhangi bir yazılım hasarı varsa, bunu olabildiğince çabuk keşfetmek ve bununla başa çıkmak istersiniz. Bir sonraki seçenek "WITH PHYSICAL_ONLY" olarak adlandırılan seçenektir.
Aynı komuttur, ancak bu durumda kelimenin tam anlamıyla yalnızca fiziksel varlığı veya veritabanının yapısını kontrol eder. Genellikle tam bir kontrolden çok daha hızlı çalışır ve bu nedenle bunu, bakım sürelerimizde sınırlamalarımız olan üretim ortamlarında çalıştırmak isteriz. Ayrıca "WITH TABLOCK" adlı başka bir seçeneğimiz daha var, bu nedenle DBCC CHECKDB hakkında anlamamız gereken bir şey, yaptığı ilk şeylerden biri, "TEMPDB" veritabanında bulunan bir anlık görüntü dosyası oluşturmasıdır ve bir CHECKDB işlemiyle böyle bir şey için "TEMPDB" kullanamayacağımız zamanlar vardır.
Bu nedenle, "WITH TABLOCK" olarak adlandırdığımız her ne olursa olsun, DBCC CHECKDB'ye bir anlık görüntü dosyası oluşturmamasını söylüyoruz, bu nedenle "TEMPDB"de bu alanı işgal etmeyecek ve bunun bir sonucu olarak genellikle daha hızlı çalışacaktır. Seçenek olarak çalıştırabileceğimiz diğer şeylerden biri de "WITH ESTIMATEONLY" seçeneğidir. Bu özel komut, CHECKDB'yi çalıştırırken "TEMPDB" veritabanımızda ne kadar alan kullanmayı beklediğimizi bize söyleyecektir.
Ve işte bunun çıktısına bir örnek, kilobayt olarak geri geliyor, yani bu yaklaşık 230 megabayt. Sahip olduğumuz diğer bir seçenek de "WITH MAXDOP". Şimdi, DBCC CHECKDB ne çalıştırırsa çalıştırsın, paralel çalışması gerektiği kadar işlemci kullanmaya çalışır. Mümkün olan en kısa sürede yürütmeyi denemek için birden çok iş parçacığı çalıştırmak istiyor. Bu nedenle, bu işlemde çalıştırılmasına izin vermek istediğimiz işlemci sayısıyla ilgili sınırlamalar olabilir, bu nedenle bunu "WITH MAXDOP" ifadesiyle sınırlayabiliriz.
Bu durumda, SQL'e CHECKDB çalıştırmamız için yalnızca bir işlemci kullanmasını söylüyorum. Ve bunu yaptığımızda, buna adanmış daha az işlemci olur, ancak DBCC CHECKDB'nizi çalıştırmak genellikle daha uzun sürer. Şimdi devam edelim ve onarım seçeneklerine bir göz atalım. Farklı onarım seçenekleri vardır. En ciddi olanı "REPAIR_ALLOW_DATA_LOSS" dediğimiz seçenektir. Hatalarla geri gelen bir veritabanını onarmaya çalışmak için bu seçeneği her kullandığımızda kelimenin tam anlamıyla veri kaybedebilirsiniz. Alternatif olarak "REPAIR_REBUILD" seçeneğini kullanabiliriz.
REPAIR_REBUILD, yazılım onarımı seçeneği olarak kabul edilir ve bununla kastettiğimiz, bunu çalıştırdığımızda veritabanındaki kullanılabilir verileri kaybetmeyeceğimizi garanti etmesidir. Bu komutun düzenlenme şekli "Ana" veritabanının bağlamını kullanacağız. Böyle bir şey yaptığımızda, bir onarım işlemine izin vermek için veritabanını "SINGLE_USER" moduna geçirmeliyiz. Bu durumda biz de bunu yapacağız.
Şimdi burada "ESTIMATEONLY" seçeneğimiz var. Bir kez daha, "ESTIMATEONLY" bize bunu yapmak için "TEMPDB"de ne kadar alandan vazgeçeceğimizi söyleyecek. Anlık görüntü dosyamız, buraya getirimize bağlı olarak yaklaşık 230 megabayt yer kaplayacak. Bununla bir onarım yaptıktan sonra tekrar "MULTI_USER" moduna geçirmek istiyoruz. Şimdi, "ESTIMATEONLY" ile aslında onarımı yapmadık, yalnızca tahmini yaptık. Şimdi komutu "REPAIR_REBUILD" ile nasıl çalıştıracağımıza bakalım.
Bir kez daha, gidip bunu "Execute" edelim, onu "MULTI_USER" içine geri koyacağız. Bir kez daha, "Ana" veritabanı bağlamında, onu "SINGLE_USER" moduna alacağız. Bu durumda, bir onarım işlemi gerçekleştireceğiz. Bu, yumuşak onarım işlemidir. Ve göreceğiniz şey, normal bir DB kontrolünde göreceğimizin çoğudur ve elbette, bir kez daha, bildirilen hataları kontrol etmek istiyoruz. Bu durumda, hata yok.
İyi bir veritabanım var. Ve bu işlemin son kısmı, onu tekrar "MULTI_USER" moduna geçirmektir. Yani, "REPAIR_ALLOW_DATA_LOSS" onarım komutu, tam olarak "REPAIR_REBUILD" gibidir, ancak "REPAIR_ALLOW_DATA_LOSS" kullanıyoruz. Genellikle, "REPAIR_REBUILD"yi çalıştırmayı denediğimizde "REPAIR_REBUILD" geri gelip veritabanının onarımının tamamlanamadığını söylediğinde bunu çalıştırıyoruz.
Yani, iyi bir yedekleme olmadan son çaremiz ve evet, bir "REPAIR_ALLOW_DATA_LOSS" yapmak zorunda kalmadan önce iyi bir yedekleme kullanmalıyız. Yedek yoksa veritabanını tekrar çevrimiçi ve kullanılabilir duruma getirmek için tek seçeneğimiz budur. Böylece, CHECKDB'nin ne zaman kullanılacağını ve mevcut en yaygın komut seçeneklerinden bazılarını göz önünde bulundurarak DBCC CHECKDB'yi tartışma demomuzu sonlandırıyoruz. Umarım bu video, tutarlı, kararlı bir SQL Server veritabanı yüklemesini sürdürmeye çalışırken DBCC CHECKDB kullanmanın değerini anlamanıza yardımcı olmuştur.
İzlediğiniz için teşekkür ederiz.