27 Şub by NURULLAH ÇAKIR

DBCC CHECKDB Detayları

DBCC CHECKDB komutu veritabanında oluşan mantıksal ve fiziksel hataların tespit edilmesi ve gerekirse onarılması için kullanılır. Veritabanı üzerinde DBCC CHECKDB komutunu çalıştırdığınızda DBCC CHECKALLOC , DBCC CHECKTABLE , DBCC CHECKCATALOG komutlarını ayrıca çalıştırmanıza gerek kalmaz. Çünkü DBCC CHECKDB hepsini içerir. Bu komutlarla ilgili detayları aşağıdaki makalelerde bulabilirsiniz.

 

DBCC CHECKALLOC Nedir“,

DBCC CHECKTABLE Nedir“,

DBCC CHECKCATALOG Nedir

Özellikle veritabanı suspect olduğunda çok işimize yarar. Düzenli olarak her veritabanı üzerinde bu komutu çalıştırmamız gerekir. Bu komutu çalıştıran job ile ilgili bilgiyi “SQL Server Maintenance/Bakım İşlemleri(OLA HALLENGREN)” isimli makalemde bulabilirsiniz.

NOT: Eğer veritabanı dosyalarınızın olduğu disklerde yeterli yer yoksa DBCC CHECKDB job’ınız aşağıdaki şekilde hata alır.

The operating system returned error 665(The requested operation could not be completed due to a file system limitation) to SQL Server during a write at offset 0x00001954fac000 in file ‘.mdf_MSSQL_DBCC37’. Additional messages in the SQL Server error log and system event log may provide more detail. This is a severe system-level error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

 

DBCC CHECKDB’nin birkaç farklı kullanım şekli vardır. Bunların hepsini teker teker inceleyelim.

Aşağıdaki komut ile Test veritabanındaki mantıksal ve fiziksel hatalar tespit edilir.

Aşağıdaki sorgu yardımıyla kullanıcı tablolarındaki non clustered index ‘ler dışındaki hatalar tespit edilir.

 

Aşağıdaki komutu kullanarak kullanıcı tablolarındaki non clustereded index’lerdeki hataları veri kaybı olmadan düzeltecek şekilde DBCC CHECKDB komutunu çalıştırabilirsiniz.

 

REPAIR_REBUILD işlemi filestream veri içeren hataları düzeltmez.

 

 

Aşağıdaki komutu kullanarak veritabanındaki bütün hataları veri kaybı riski ile beraber düzeltecek şekilde DBCC CHECKDB komutunu çalıştırabilirsiniz.

 

Script’in sonundaki ALL_ERRORMSGS yazmasak bile default olarak bu şekilde kabul eder. Her nesne için alınan bütün hataları göster anlamına gelir.

 

Script’in sonundaki NO_INFOMSGS bilgilendirme mesajlarını gösterme anlamına gelir.

 

NOT1: Veritabanının suspect olduğu teyidini yaptıktan sonra kurtarmak için(REPAIR_REBUILD ya da REPAIR_ALLOW_DATA_LOSS komutları ile çalıştırmadan önce) girişime başlamadan önce yapmamız gereken ilk işin bu haliyle bir backup’ını almak olmalı!!!

 

NOT2: DBCC CHECKDB komutunu REPAIR_REBUILD ya da REPAIR_ALLOW_DATA_LOSS ile çalıştırdıktan sonra DBCC CHECKCONSTRAINTS komutunu çalıştırmanızı öneririm. Bu komutla ilgili bilgiyi “DBCC CHECKCONSTRAINTS Nedir” isimli makalemde bulabilirsiniz.

 

Default olarak DBCC CHECKDB komutu indexed view, XML index, ve spatial index ler için sadece fiziksel tutarlılık testi yapar. Aşağıdaki komutu kullanarak compatibility level’i  SQL Server 2008 ve üstü olan veritabanlarındaki indexed view, XML index, ve spatial index ler için mantıksal tutarlılık kontrolü de yapılır. “Compatibility Level Nedir Ve Nasıl Değiştirilir” isimli makalemi okumak isteyebilirsiniz.

 

 

DBCC CHECKDB komutu internal database snapshot kullanır. Bu sayede bu komutu çalıştırdığınızda bloklama olmaz. “Database Snapshot Nedir ve Nasıl Alınır?” isimli makalemi okumak isteyebilirsiniz.

 

Aşağıdaki komutu kullanarak çalıştırırsanız internal database snapshot kullanmak yerine veritabanı üzerinde exclusive lock koyar. “SQL Server Lock Çeşitleri” isimli makalemi okumak isteyebilirsiniz.

 

 

Aşağıdaki komutu kullanırsanız herhangi bir tutarlılık testi yapılmaz. Sadece tutarlılık testi yapılabilmesi için tempdb’de ne kadar alan gerektiği hesaplanır ve aşağıdaki gibi bir çıktı üretir.

 

Estimated TEMPDB space (in KB) needed for CHECKDB on database Test = 756.

 

Aşağıdaki komutu kullanarak çalıştırdığınızda tutarlılık kontrolü sadece fiziksel olarak yapılır. Mantıksal olarak yapılmaz. Microsoft büyük veritabanlarında dbcc checkdb komutu sık çalıştırılmak istendiğinde bu şekilde çalıştırılmasını ama yinede PHYSICAL_ONLY komutu olmadan da belirli aralıklarla DBCC CHECKDB komutunun çalıştırılması gerektiğini söylüyor.  PHYSICAL_ONLY komutu ile çalıştırdığınızda daha hızlı ve daha az cpu kullanarak sonuç alırsınız.

 

Bana sorarsanız bu komutu kullanarak çalıştırmanın pek bir anlamı yok. Çünkü mantıksal tutarlılığını kontrol etmiyor. Yani DBCC CHECKDB için oluşturduğunuz job’ınızı bu komutla oluştursanız. 3 hafta bu job çalışsa ve hiç birinde hata almasa, üçüncü haftanın sonunda PHYSICAL_ONLY olmadan çalıştırdığınızda bir sürü mantıksal hata alsanız bu durum hiç hoşunuza gitmeyecektir. Bu yüzden DBCC CHECKDB komutunu PHYSICAL_ONLY olmadan çalıştırmanızı öneririm.

 

Genellikle büyük veritabanlarında DBCC CHECKDB işlemi uzun sürdüğü için bir çok insan PHYSICAL_ONLY ile çalıştımak gerektiğini çünkü daha hızlı sonuçlandığını söylüyor ama benim fikrim eğer büyük veritabanınız varsa daha büyük bir cpu alın. Örnek olarak yönettiğim büyük bir veritabanının(15 TB) DBCC CHECKDB işlemi 7 gün sürüyordu. Bu veritabanını daha güçlü bir sunucuya taşıdığımda DBCC CHECKDB süresi 10 saate düştü.

 

PHYSICAL_ONLY komutu ile herhangi bir REPAIR(sorunu düzeltme) işlemi yapamazsınız.

 

 

Aşağıdaki komutu kullanarak çalıştırdığınızda veritabanındaki tablolara ait kolonların değerlerinin kolon’un veri tipi ile uyumlu olup olmadığı kontrol edilir. Eğer veritabanınız SQL Server 2005 ve üzeri ise kolon değerleri otomatik olarak kontrol edilir ve DATA_PURITY seçeneğine gerek yoktur.

 

 

SQL Server 2005 öncesinde bazı tabloların ve index’lerin satır sayıları negatif gelebiliyordu. DBCC CHECKDB komutu bunu da kontrol eder ve DBCC UPDATEUSAGE komutunun kullanılmasını tavsiye eder. “DBCC UPDATEUSAGE Nedir Ve Nasıl Kullanılır” isimli makalemden faydalanabilirsiniz.

 

DBCC CHECKDB komutu disable edilmiş index’leri incelemez.

 

DBCC CHECKDB’nin daha hızlı tamamlanması için DBCC CHECKDB çalıştırmadan önce server konfigurasyonlarından maxdop(max degree of paralellism)’u arttırabilirsiniz. Eğer sisteminiz oltp bir sistemse ve tamamen küçük transaction lardan oluşuyorsa maxdop’u arttırmak çalışan sistemin performansını yavaşlatabilir. Bu yüzden maxdop’u arttırdıktan sonra sistemi incelemeli ve herhangi bir performans probleminde değişikliği geri almalısınız. Maxdop değerini doğru ayarlamak için  “sp_configure(SQL Server’da Server Seviyesinde Konfigurasyonlar)” isimli makalemden faydalanabilirsiniz.

 

2 Comments

  1. Merhaba checkdb işlemi temp haricinde, ldf dosyasını da şişiriyor mu? disk yeterliliğinin ne kadar olması gerektiğini nasıl kestirebiliriz?

    1. 100 TB’dan daha büyük veritanları için DBCC CHECKDB yapıyorum ve ldf file’da büyüme olmuyor.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Lütfen captcha kodunu giriniz *

Lütfen Resimdeki Kodu Boşluğa Giriniz.