MSSQL Server Ola Hallengren Database Integrity Check

Bu makalede Ola Hallengren MaintenanceSolution scriptini çalıştırdıktan sonra sql agent altında gelen Database Integrity Check system databases ve Database Integrity Check user databases yapılarını detaylı bir şekilde görmüş olacağız. Bu yapıya geçmeden önce sayfamızda DBCC makalelerine bakılması gerekmektedir. Şimdi oluşturulan bu jobın bizlere neler sağladığı ve nasıl kontrol edildiğini görmüş olalım. Gerçek sistem üzerinde yapılarımız bu şekilde kontrol edilmektedir. İlgili linkten script indirilebilir.

Not: OlaHallengren scriptleri default olarak herhangi bir schedule yapısına sahip değildir. Çalışabilmesi için herhangi bir zaman diliminin belirlenmesi gerekmektedir.

Default olarak script tarafından oluşturulan yukarıda görülen jobların kendi bulunduğumuz ortama göre dizayn edebiliriz. Bunun için Ola Hallengren Maintenance Solution scriptinin indirilmesi gerekmektedir. Gerçek sistemler üzerinde yapılar şu şekilde çalışmaktadır. Secondary sunucusunda hafta bir dbcc checkdb fiziksel ve mantıksal olarak çalıştırılması gerekirken. Primary sunucusunda ayda 1 sadece fiziksel tutarlılık testi yapılması yeterlidir. Neden primary sunucusunda mantıksal test yapılmıyor diye sorabilirsiniz. Çünkü mantıksal olarak secondary sunucusunda yapılmaktadır. Primary sunucusunda ekstradan gerek yoktur. Mantıksal hatalardan kastımız veritabanının iç yapısındaki tutarsızlıklardan kaynaklanır. Fiziksel olarak sayfalar sağlamdır, ancak veri ilişkileri bozulmuştur.  Mantıksal olan hatalara örnek vermek gerekirse Index ve tablo verileri arasında uyumsuzluk, Foreign key ihlalleri, Bozuk B-tree yapıları (index fragmentation), Geçersiz pointer’lar (orphaned rows, missing pages)
Bir tablodaki satır, başka bir tablodaki foreign key ile eşleşmiyor. Clustered index ile nonclustered index arasında tutarsızlık var. Primary sunucusunda fiziksel olarak taramanın yapılmasının sebebi ilgili sunucuda fiziksel olarak page bozulması, donanım arızaları, disk bozulması vs.. herhangi bir sorun olup olmadığını gözlemlemektedir. DBCC makalelerinde belirtilen tüm scriptlerini Ola Hallengren scriptlerinde görmek mümkündür.

DatabaseIntegrityCheck Stored procedure’in içerisinde Default’ta olan değişkenlerin ekran resimleri:

Not: Updateability READ_ONLY ve READ_WRITE  için işlemleri yapmaktadır. ExtendedLogicalChecks sadece mantıksal check işlemi yapılması için kullanılmaktadır. NoinformationalMessages yes seçilmesi bilgilendirme mesajlarını göstermez. StringDelimiter belirtilen ifadelerin ayracının virgül olduğunu göstermektedir. DatabaseOrder veritabanının hangi sırayla alınacağını belirtiriz. Bu ifade veritabanı ismine göre sıralamaya dizmektedir. Bu değişkenler ilgili ifadelerle kullanılmaktadır. DATABASE_NAME_ASC, DATABASE_SIZE_DESC gibi ifadeleri kullanılmaktadır.

Not: @LockTimeout = 600 → “10 dk bekle, alamazsan vazgeç” ilgili job kendini hemen sonlandırmaz. Job devam etmektedir production korunmaktadır.

Genel olarak Job içerisinde kullanabileceğimiz genel komutlar aşağıda gösterilmektedir.

EXECUTE dbo.DatabaseIntegrityCheck
@Databases = 'USER_DATABASES',
@CheckCommands = 'CHECKDB',--CHECKFILEGROUP,CHECKTABLE.. yazılabilir.
@PhysicalOnly = 'Y', --Sadece fiziksel olarak kontrol yapılması
@NoIndex = 'Y', -- Non clustered indexler dışında kontrol sağlanır.
@AvailabilityGroupReplicas='SECONDARY', --ALL,PRIMARY şeklinde belirtilebilir.
@AvailabilityGroups='ALL_AVAILABILITY_GROUPS,-AG%',-- Tüm availability kontrol veya tek AG üzerinde tarama işlemi yapar.
@TimeLimit=2000,-- Saniye cinsinden belirli bir çalışma zamanı belirlenebilir. 2 bin saniye boyunca çalışır.
@LogToTable='Y', -- Yapılan işlemleri log tablosuna kaydeder.
@NoInformationalMessages='Y',-- Bu ifade bilgilendirme mesajlarını göstermez.
@TabLock='N', --Performans anlamında tabloya ve ilgili ifadeye lock koyar.
@Maxdop=8-- Tutarlılık testinin paralel çalışmasını sağlayabiliriz.

Not: Ola Hallengren scriptlerinde Availability Group kontrol şartı aranmaz. Çünkü ola kendi içerisinde yapmaktadır.

Not: @TabLock ifadesinin kullanılması tablo üzerinde internal database snapshot oluşturulmaz. Exclusive lock oluşturur.

Yukarıda genel olarak verilen çoğu komutu ihtiyacınıza göre yapabilirsiniz.

• Databases değişkeni için birden fazla değer kullanılmaktadır. Bunlar SYSTEM_DATABASES, USER_DATABASES, ALL_DATABASES, AVAILABILITY_GROUP_DATABASES bu yapı ile tüm AG altında veritabanını check işlemi yapılmaktadır. Sadece stand alone olan veritabanları için bakım işlemleri yapılması isteniyorsa USER_DATABASES, -AVAILABILITY_GROUP_DATABASES kullanılmaktadır. Tek bir veritabanı da yazılabildiği gibi birden fazla veritabanıda yazılabilir.

• Birden fazla CheckCommands ifadesi kullanılabilir. (CHECKALLOC, CHECKTABLE, CHECKCATALOG)

• File Group bazında DatabaseIntegrityCheck kontrol işlemi yapılmak isteniyorsa aşağıdaki şekilde komut güncellenir. @FileGroups ifadeleri ALL_FILEGROUPS, Db1.FileGroup1, Db1.FileGroup1, Db2.FileGroup2, ALL_FILEGROUPS, -Db1.FileGroup1, Db1.%FileGroup% şeklinde belirlenebilir.

EXECUTE dbo.DatabaseIntegrityCheck
@Databases = 'AdventureWorks',
@CheckCommands = 'CHECKFILEGROUP',
@FileGroups = 'AdventureWorks.PRIMARY'

• Tüm file grouplar dahil edip bazı file groupları çıkarabiliriz.

EXECUTE dbo.DatabaseIntegrityCheck
@Databases = 'USER_DATABASES',
@CheckCommands = 'CHECKFILEGROUP',
@FileGroups = 'ALL_FILEGROUPS, -AdventureWorks.PRIMARY'

• Tablo bazında kontrol edilmesi istenirse ilgili veritabanı, schema adı ve tablo adının girilmesi gerekmektedir. CHECKTABLE ifadesinin kullanılması gerekmektedir. Ayrıca @Objects kısmında tablonun isminin belirtilmesi gerekmektedir. Tüm tablolar için ALL_OBJECTS belirli şema isminde bulunan tüm tabloların kontrol edilmesini istersek Db1.Şema1.% ifadesinin belirtilmesi gerekmektedir.

EXECUTE dbo.DatabaseIntegrityCheck
@Databases = 'AdventureWorks',
@CheckCommands = 'CHECKTABLE',
@Objects = 'AdventureWorks.Production.Product'

• Tüm tablolarının mantıksal ve fiziksel olarak kontrol işlemi yapılırken bazı tablolar kontrol işleminden çıkarılabilir.

EXECUTE dbo.DatabaseIntegrityCheck
@Databases = 'USER_DATABASES',
@CheckCommands = 'CHECKTABLE',
@Objects = 'ALL_OBJECTS, -AdventureWorks.Production.Product'

• Hangi replica üzerinde çalıştırılacağına karar verilebilir. Hayati önem taşır. Çünkü yanlış replicada çalıştırılması performans anlamında ciddi sorunlar yaratabilir. Secondary makinada çalıştırılması gerekmektedir. Primary sunucuda sadece Fiziksel olarak çalıştırılması gerekmektedir. Bunun için @AvailabilityGroupReplicas ifadesinin kullanılması gerekmektedir. @CheckCommands ifadesinin yazılmaması herhangi bir sorun teşkil etmez default olarak CHECKDB gelmektedir.

EXECUTE dbo.DatabaseIntegrityCheck
@Databases = 'USER_DATABASES',
@CheckCommands = 'CHECKDB',
@AvailabilityGroupReplicas='SECONDARY',
@LogToTable='Y'

• Primary sunucu üzerinde sadece fiziksel test yapmak için @PhysicalOnly komutu çalışmaktadır.

EXECUTE dbo.DatabaseIntegrityCheck
@Databases = 'USER_DATABASES',
@PhysicalOnly = 'Y',
@AvailabilityGroupReplicas='PRIMARY',
@LogToTable='Y'

• Tüm veritabanları üzerinde nonclustered indexler haricinde dbcc check komutunu görebiliriz.

EXECUTE dbo.DatabaseIntegrityCheck
@Databases = 'ALL_DATABASES',
@CheckCommands = 'CHECKDB',
@NoIndex = 'Y'

Aşağıdaki komut ile sqlcmd üzerinden Integrity jobımız çalışmaktadır. Tüm replica sunucularımızın üzerinde ilgili komutun aynı şekilde oluşturulması gerekmektedir.

sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d master -Q "EXECUTE [dbo].[DatabaseIntegrityCheck] @Databases = 'USER_DATABASES', @AvailabilityGroupReplicas='SECONDARY' ,@NoInformationalMessages = 'Y', @LogToTable = 'Y'" -b

Yukarıdaki komutlarımızda @CheckCommands ifadesinin bulunmamasının sebebi default olarak stored procedure yapımızın içinde çalışmasından dolayıdır.

@NoInformationalMessages ifadesi gereksiz yere log üretmemesi içindir. Job’ımız çalıştıktan sonra kontrol işlemi için @LogToTable ifadesinin belirtilmesi gerekmektedir. Ayrıca Job oluşturulduktan sonra Output file özelliğinin aktif edilmesi gerekmektedir.

Sistemimiz üzerinde önceden herhangi bir Integrity Check çalışmamışsa tahmini yöntemle veritabanları bölünebilir. Önceden çalışmış bir job veya joblarınız varsa commang log veya output file dan incelenip backup’ları çakışmayacak bir şekilde şeçilmesi gerekmektedir. Önceden herhangi bir integrity check job’ı çalışmamışsa tahmini yöntemle veritabanı boyutlarına bakarak bu işlemleri gerçekleştiririz.

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.

Not: Bazı veritabanlarını dbcc işlemlerinde büyük olmasına rağmen check işlemi kısa sürmektedir. Bazı küçük veritabanlarında ise uzun sürmektedir. Sebebi ise içerisinde bulunan veri yapısına bağlıdır.

Not: Bir sunucu üzerinde primary ve secondary şeklinde iki AG yapısı varsa scriptlerimiz aynı şekilde oluşturulur. Her veritabanı kendi secondary sunucusunda çalışmaktadır.

Not: System veritabanları her sunucu üzerinde local olarak çalıştırılması gerekmektedir. Aşağıdaki komut system veritabanlarının çalıştığı script görünmektedir.

sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d master -Q "EXECUTE [dbo].[DatabaseIntegrityCheck] @Databases = 'SYSTEM_DATABASES', @LogToTable = 'Y'" -b

Genel DBCC komutumuz Olahallengren scriptleriyle aynıdır.

DBCC CHECKDB(N'Veritabanı_Adı') WITH ALL_ERRORMSGS, NO_INFOMSGS, TABLOCK, ESTIMATEONLY,PHYSICAL_ONLY, DATA_PURITY, NOINDEX)

Yukarıdaki komutların bir job aracılığıyla çalışmasından sonra herhangi bir sorunda index sorunu veya buna benzer sorunlar çözülmektedir. Sayfalarda herhangi bir bozulma olmuşsa Repair rebuild komutu kullanılır. Bu sorunu çözmezse data loss komutu kullanılmaz. Backup restore yönteminin tercih edilmesi gerekmektedir.

Not: Sql server Failover olduktan sonra dbcc checkdb anlık o an veritabanını almaya devam eder yeni veritabanına geçerken primary olarak görür ola kendi içerisinde her veritabanına geçerken kontrol yapmaktadır. Artık secondary olan sunucu primary olduğunda primary olduğu için kalan veritabanlarında herhangi bir işlem yapmaz. Başarılı bir şekilde sonlanır. Secondary sunucusu not sychronizing olduğunda dbcc check o an ilgili veritabanında hata verir. System kendine geldiğinde ilgili veritabanı için dbcc check failed verir. Kaldığı yerden devam eder job bitiminde failed görünür .

Bu makalede DBCC komutlarını system üzerinden job aracılığıyla nasıl çalışacağını detaylı bir şekilde görmüş olduk. Başka bir makalede görüşmek dileğiyle..

Emrolunduğun Gibi Dosdoğru Ol!” (Hûd: 112)