Recent comments

None


İçerik Ara











Yasal Uyarı
Bu sitede sunulan tüm bilgi ve dökümanlar Turgay Sahtiyan tarafından yazılmaktadır. Yazıların kaynak göstermek şartıyla kullanılması serbesttir.

© Copyright 2009-2013
Takvim
<<  Haziran 2017  >>
PaSaÇaPeCuCuPa
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789
Keywords

SQL Server’da performans açısından belki de en önemli noktalardan biri sistem database’lerinden biri olan TempDB’nin iyi bir şekilde configure edilmesi ve yönetilmesidir. Bugünkü yazımda TempDB ve TempDB best practice’leri üzerine konuşuyor olacağız.

[more]

TempDB Nedir?

TempDB, SQL Server kuruluşu ile beraber gelen 4 sistem database’inden biridir. Her instance için 1 adet olan TempDB’de örnek olarak aşağıdaki bilgiler tutulur:

  • Kullanıcı tarafından create edilen temp table, table variable ya da cursor gibi geçici objeler
  • SQL Server tarafından sort, spool, hash join gibi işlemler için create edilen work table ya da ara sonuçlar gibi internal objeler
  • Read committed snapshot isolation ya da snapshot isolation özelliği kullanıldığında generate edilen row versioning bilgileri
  • Online index operation işlemlerinde tutulan row versioning bilgileri TempDB’de tutulurlar.

Yukarıda da görüldüğü gibi hem kullanıcı hem de internal işlemler için çok fazla durumda kullanılan TempDB bazı durumlarda performans sıkıntısı oluşturabilmektedir. Bu yüzden çok iyi configure ve monitor edilmelidir.

Ayrıca daha önce de belirttiğim gibi tüm instance için sadece 1 adet olan TempDB, konfigurasyonun ve monitoring’in önemini daha da arttırmaktadır.

 

TempDB Best Practice’leri

Bu bölümde TempDB için uyguladığımız aşaıdaki best practice’lerden bahsediyor olacağım.

  • TempDB Data File Sayısı
  • TempDB Data File’larının Aynı Boyutta Olması
  • TempDB File’larının Bulunduğu Storage
  • Yoğun TempDB Kullanımının Analiz Edilmesi
  • T1118 Trace Flag’i

TempDB Data File Sayısı

TempDB üzerinde yapılan allocation ve deallocation işlemlerinde diğer database’lerde de olduğu gibi PFS, GAM ve SGAM page’leri kullanılır. Çok yoğun TempDB kullanılan workload’larda, örneğin sürekli ufak boyutlu temp table’lar create ve drop edildiğinde bu page’ler üzerinde contention yani beklemeler görülebilir. (Örneğin 2:1:3 SGAM page’inde PAGELATCH_XX wait tipi gibi)

Allocation bitmap page’lerinde oluşan bu contention’i azaltmak için 1’den fazla tempdb data file’i kullanılabilir. Bu şekilde page sayısı arttırılacak ve round robin kullanım sayesinde contention azaltılacaktır.

TempDB data file sayısının best practice’i workload’a ve core CPU sayısına göre değişiklik göstermektedir. Bu konu üzerinde internette çok fazla best practice’e rastlayabilirsiniz. Benim kullandığım ise şu şekilde;

  • Core CPU sayısı 8’den az ise core cpu sayısı kadar data file yapmak
  • Core CPU sayısı 8’den fazla ise TempDB data file sayısının 8 yapılması ve wait type’larda PAGELATCH_XX wait type’ının analiz edilmeye devam edilmesidir. Contention görülmeye devam edildiği sürece data file sayısı her defasında 4 arttırılabilir.
“ But there’s now even better guidance, and what I also recommend. At PASS in 2011, my good friend Bob Ward, who’s the top guy in SQL Product Support, espoused a new formula: if you have less than 8 cores, use #files = #cores. If you have more than 8 cores, use 8 files and if you’re seeing in-memory contention, add 4 more files at a time.”
http://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-1230-tempdb-should-always-have-one-data-file-per-processor-core/

Bu noktada akla TempDB data file sayısını her defasında neden 4’er 4’er arttırıp tek seferde 32 ya da 40 yapmadığımız sorusu gelebilir. TempDB data file sayısının fazla olması da performance’a eksi yönde etki eden bir durumdur. Bu yüzden belirli bir sayıdan (8) başlanarak contention görüldüğü sürece (contention analizi için sys.dm_os_wait_stats DMV’si sonucunda çıkan result set’teki PAGELATCH_XX wait type’I gözlenebilir) data file sayısının arttırılması daha iyi bir yaklaşımdır.

Temp DB data file sayısının çok olmasının performans üzerindeki etkisi için aşağıdaki yazıya göz atılabilir;

“So, why is one-to-one not always a good idea? Too many tempdb data files can cause performance problems for another reason. If you have a workload that uses query plan operators that require lots of memory (e.g. sorts), the odds are that there won’t be enough memory on the server to accommodate the operation, and it will spill out to tempdb. If there are too many tempdb data files, then the writing out of the temporarily-spilled data can be really slowed down while the allocation system does round-robin allocation. The same thing can happen with very large temp tables in tempdb too.

Why would round-robin allocation cause things to slow down for memory-spills to tempdb with a large number of files? A couple of possibilities:

Round-robin allocation is per filegroup, and you can only have one filegroup in tempdb. With 16, 32, or more files in tempdb, and very large allocations happening from just a few threads, the extra synchronization and work necessary to do the round-robin allocation (looking at the allocation weightings for each file and deciding whether to allocate or decrement the weighting, plus quite frequently recalculating the weightings for all files – every 8192 allocations) starts to add up and become noticeable. It’s very different from lots of threads doing lots of small allocations. It’s also very different from allocating from a single-file filegroup – which is optimized (obviously) to not do round-robin.

Your tempdb data files are not the same size and so the auto-grow is only growing a single file (the algorithm is unfortunately broken), leading to skewed usage and an I/O hotspot.

Having too many files can lead to essentially random IO patterns when the buffer pool needs to free up space through the lazywriter (tempdb checkpoints don’t flush data pages) for systems with not very large buffer pools but *lots* of tempdb data. If the I/O subsystem can’t handle the load across multiple files, it will start to slow down.”
http://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-1230-tempdb-should-always-have-one-data-file-per-processor-core/

TempDB’ye yeni bir data file ekleme işini hem SSMS hem de TSQL komutu ile yapabilirsiniz. Örneğin aşağıdaki komut TempDB’ye başlangıç boyutu 1024 MB, auto growth değeri 512 MB olan yeni bir data file ekler.

USE [master]
GO
ALTER DATABASE [tempdb] ADD FILE 
	( NAME = N'Tempdev2', 
	  FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\Tempdev2.ndf' , 
	  SIZE = 1048576KB , 
	  FILEGROWTH = 524288KB )
GO

TempDB Data File’larının Aynı Boyutta Olması

Bir önceki bölümde TempDB data file’larının sayısı üzerine konuştuk ve diyelim ki core CPU sayımız 4 ve 4 adet TempDB data file bulundurmaya karar verdik. Şimdi ikinci best practice’imiz yani bu data file’ların aynı boyutta olmasının öneminden bahsedeceğiz.

TempDB’de bulunan data file’lar round robin olarak proportional fill algorithm özelliğini kullanırlar. Bu özelliğin performanslı bir şekilde kullanılabilmesi için tüm data file’ların aynı boyutta olması gerekmektedir. Ayrıca TempDB’ye özel bir problem, tempdb data file’larından eğer herhangi biri diğerlerinden büyükse, auto growth esnasında her zaman büyük olan data file büyütülecektir. Bu durum da proportional fill algorithm özelliğinin sağlıklı bir şekilde kullanılmamasına sebebiyet verecektir.

Aslında burada başka bir best practice’den daha bahsetmek gerekiyor. Bilindiği gibi data file’larda yer bittiğinde eğer auto growth özelliği aktif halde bırakılırsa data file için yeni bir alan otomatik olarak alloce edilecektir. Data file allocation işlemi file seviyesinde exclusive lock’a sebebiyet verdiğinden dolayı auto growth işlemi sırasında file’a erişim engellenecek ve eğer çok fazla auto growth oluşursa performans eksi yönde etkilencektir. Bu yüzden

  • TempDB data file’larına uygun bir başlangıç değeri vermek
  • Auto growth değerlerini daha büyük chunk’lar halinde ayarlamak önemli bir diğer best practice’dir

Bu şekilde TempDB data file’ları -ideal durumda- auto growth’a yakalanmayacak, yakalansa bile büyük chunk’lar halinde büyütüldükleri için sürekli büyüme ihtiyacı duymayacaklardır.

Bu bölümdeki ilk best practice yani TempDB data file’larına uygun bir başlangıç değeri vermek üzerine önemli bir noktanın altını çizmek istiyorum. Bildiğiniz gibi TempDB her SQL Server restart’ında baştan create edilir. Eğer TempDB data file’larının ilk başlangıç değerlerini çok yüksek tutarsanız restart işlemleri sonrası SQL Server’ın hazır hale gelmesi uzun sürecektir. Dolayısıyla uygun bir değerin belirlenmesi önem tşaımaktadır.

Bu bölümdeki best practice’leri toparlayacak olursak. Diyelim ki core CPU sayımız 4 ve 4 TempDB data file’i kullanmaya karar verdik. Ve eğer toplamda 10GB’lık TempDB boyutu bizim için yeterli ise yapmamız gerekenleri şu şekilde sıralayabiliriz.

  • TempDB’ye 3 adet daha data file eklenerek toplam data file sayısı 4’e çıkarılır.
  • Tüm data file’ların başlangıç boyutları 2.5 GB (10 GB/4) olarak ayarlanır.
  • Data file’ların auto growth değerleri büyük chunk’lar halinde auto growth gerçekleşsin diye uygun bir değere (örneğin 512 MB ya da 256 MB) set edilir.

Her ne kadar data file’lara uygun bir başlangıç değeri atansa da plansız ya da problemli bir durumda data file’lar büyüme ihtiyacı duyabilir. Bu durum da data file’lardan biri büyütülecek ve önemli best practice’lerimizden biri olan “TempDB data file’larının eşit boyutta olması” best practice geçersiz duruma gelecektir. Bu problemin önüne geçmek için T1117 trace flag’i kullanılabilir. Bu trace flag aktif hale getirildiğinde bir file group içerisindeki data file’lardan herhangi biri auto growth’a girdiğinde sadece ilgili file değil file group içerisinde bütün data file’lar beraber büyütülecek ve dolayısıyla TempDB data file’larının aynı boyutta olma best practice’i korunmuş olacaktır. Yalnız unutulmaması gereken önemli bir nokta T1117 trace flag’i sadece TempDB’yi değil instance’da bulunan tüm database’leri etkilemektedir.

TempDB data file’larına başlangıç değeri ve auto growth değeri verme işlemlerini SSMS’ten TempDB özelliklerine girerek yapabilirsiniz.

TempDB File’larının Bulunduğu Storage

TempDB’nin yoğun bir şekilde kullanıldığı ortamlarda TempDB performansının overall SQL Server performansını nasıl etkileyeceğinden bahsettik. Bu yüzden TempDB file’larının diğer user database file’larından ayrı bir yerde ve sistemde bulunan en yüksek performanslı disklerde (örneğin SSD disklerde) bulundurulması önemli bir best practice’dir.

TempDB data file’larının nasıl taşınabileceği ile alakalı şu blog post’umu okuyabilirsiniz.

Yoğun TempDB Kullanımının Analiz Edilmesi

Şu ana kadar bahsettiğimiz tüm best practice’ler, TempDB üzerinde yapabileceğimiz konfigurasyon değişiklikleri ile performans artışını sağlamak amacıyla kurgulayabileceğimiz değişiklikler. Aslında belki de bu best practice’lerden daha önce TempDB’nin neden yoğun bir şekilde kullanıldığı ve gerçekten bu kadar yoğun bir şekilde kullanılıp kullanılmamasını analiz etmek olmalıdır. Çünkü çoğu sorguda şunu görüyoruz ki; yoğun temp table’lar kullanılarak yapılan işlemler aslında temp table kullanılmadan da yapılabilmektedir.

Bu yüzden eğer yukarıdaki best practice’leri yapmanıza rağmen hala allocation bit page contention’ları görmeye devam ediyorsanız TempDB’nin neden yoğun bir şekilde kullanıldığının analiz edilmesi ve gerekiyorsa kodda değişiklik yapılarak bu kullanımın azaltılması gerekmektedir. Hatta daha da ideali bu analizi best practice’leri yapmadan önce yapmaktır.

Tekrar belirtiyorum; sadece 1 adet TempDB’miz var ve ona gerçekten iyi bakmalıyız.

T1118 Trace Flag’i

SQL Server’da tüm yeni allocation’larda ilk 8 page’e kadar yapılan page allocation’ları mixed extend’ler üzerinden yapılmaktadır. Obje için alloce edilen alan 8 page’i geçtikten sonra gelen yeni page istekleri artık uniform extend olarak sağlanmaktadır. İlk 8 page için mixed extend’lerden allocation yapılırken her allocation’da PFS, GAM ve SGAM allocation bit page’lerin tamamına bakılır. Bu durumda 8 page’in allocation’i için SGAM page’e 8 defa erişilmektedir ve bu da SGAM (örneğin 2:1:3) üzerinde contention görülmesine sebebiyet verir.

T1118 trace flag’i aktif edildiğinde tüm extend allocation’ları uniform olarak verilir. Bu durumda SGAM üzerindeki contention aşılabilir.

Eğer yukarıdaki best practice’leri uygulamanıza ragmen hala allocation bit page contention’larına rastlıyorsanız T1118 trace flag’ini aktif etmeyi düşünebilirsiniz

ÖZET

TempDB performans açısından SQL Server için oldukça önem taşımaktadır. Instance başına 1 TempDB olduğu için TempDB’nin konfigurasyonu ve yönetimi oldukça önemlidir.

TempDB performansı için base olarak şu best practice’ler uygulanabilir.

  • TempDB kullanımının azaltılması (örneğin gereksiz temp table kullanımının kaldırılması)
  • TempDB file’larının diğer kullanıcı database’lerinden farklı ve en yüksek performanslı disklere konulması.
  • TempDB data file’larının arttırılması
    • Core CPU sayısı 8’den az ise Core CPU sayısı kadar
    • Core CPU sayısı 8’den fazla ise 8 data file oluşturulup contention görülmeye devam edildiği sürece 4’er 4’er data file eklenmesi.
  • TempDB data file’larına uygun bir başlangıç boyutu verilmesi
  • TempDB data file’larının boyutlarının aynı yapılması (Proportional Fill Algorithm)
  • Auto growth değerlerine uygun bir değer verilmesi (Örneğin; 256 MB ya da 512 MB)
  • Gerekirse T1118 trace flag’i aktif hale getirilerek extend allocation’ının uniform extend olarak yapılmasının sağlanması.
Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


Bugün uzun zamandır yazmayı düşündüğüm çok önemli bir konu & best practice üzerine konuşuyor olacağız.

[more]

Virtual Log File (VLF) Nedir?

Virtual Log File transaction log dosyası içerisindeki transactionları saklayan mantıksal parçalardır. Bir database’in sahip olduğu VLF’lere DBCC LOG_INFO() komutu ile bakılabilir.

image

Örneğin benim sistemimde bulunan AdventureWorks veritabanı 1 transaction log dosyası içerisinde 444 virtual log file içermekte.

Yeni Bir VLF Nasıl Eklenir?

Transaction log dosyası üzerinde yapılan her auto growth ya da manuel büyütme işleminde yeni 1 ya da 1’den fazla VLF eklenir. Kaç tane VLF’nin ekleneceği büyümenin boyutuna bağlıdır. Buna göre;

  • Büyüme 64 MB’a kadar ise 4 VLF
  • 64 MB ile 1 GB arasında ise 8 VLF
  • 1 GB’dan fazla ise 16 VLF eklenir

Örneğin eğer transaction log file’ı 512 MB büyütürseniz (yukarıdaki listede 2. sıraya denk gelmekte) bu durumda 8 VLF eklenecek ve her VLF’nin boyutu 512/8 = 64 MB olacaktır.

Dolayısıyla Auto growth ya da manuel büyütme boyutlarınız ne kadar küçükse (bildiğiniz gibi default auto growth değeri log dosyaları için 1 MB’dır) VLF sayınız o kadar fazla olacaktır.

 

Çok Fazla VLF’ye Sahip Olmanın Veritabanına Etkisi Nedir?

Transaction log dosyasındaki VLF sayısı 2 farklı açıdan bizi etkiler;

  • Her database recovery işleminde (örneğin restart ya da failover sonrası) veritabanı recovery edilirken redo ve undo operasyonları işletilir. Redo operasyonu başlamadan transaction log dosyasındaki bütün VLF’ler okunur. VLF sayısı arttıkça bu okuma süresi uzayacak ve dolayısıyla recovery süresi yani veritabanın ayağa kalkma süresi uzayacaktır
  • VLF sayısı arttıkça database üzerinde yapılan DML (insert-update-delete) işlemlerinin performansı etkilenir. Şu blog post’ta bu konu çok güzel bir şekilde analiz edilmiş. Buna göre diğer özellikleri aynı ama birinde 20.000 diğerinde 16 VLF bulunan 2 veritabanı üzerinde yapılan insert-update-delete işlemlerinin süresi aşağıdaki gibidir.

    image

    Tablodan da rahatça anlaşılacağı gibi VLF sayısı arttıkça DML performansı kötü yönde etkilenmektedir.

 

VLF Best Practice’i Nedir?

VLF sayısı için genel kabul görmüş best practice değeri her transaction log file için 1000’dir. Fakat veritabanı boyutuna göre bu best practice değeri azaltılabilir. Örneğin 1000 best practice değeri 300 GB’lık bir transaction log’a sahip veritabanı için anlamlıyken 2 GB transaction log dosyasına sahip bir veritabanında çok daha az sayıda VLF’e sahip olunması gerekir.

Tabii burda göz önünde bulundurulması gereken bir başka best practice ise çok büyüt boyutlarda VLF’lere sahip olunmamasıdır. Bu konuda Kimberly L. Tripp (blog | twitter) şu blog post’ta VLF dosyaları için maksimum 512 MB boyutuna sahip olunmasını tavsiye etmektedir. (512 MB’lık VLF’lere sahip olmak için büyümeler 8 GB’lık chunk’lar halinde yapılmalıdır.)

Bu bölümde son olarak SQL Server 2012 ile beraber gelen VLF kontrolünden bahsetmek istiyorum. Database’in her recovery işleminde (örneğin restart) bütün database’lerin VLF sayıları kontrol edilir ve eğer 1000’den fazla VLF’e sahip olan bir veritabanı var ise SQL Error Log’da aşağıdaki şekilde loglanır.

Database VLF_DB has more than 1000 virtual log files which is excessive. Too many virtual log files can cause long startup and backup times. Consider shrinking the log and using a different growth increment to reduce the number of virtual log files.

VLF Sayısına Nasıl Bakılır?

Makalemin başında da bahsettiğim gibi bir database’in sahip olduğu VLF’lere ve sayısına DBCC LOGINFO() komutu ile bakılabilir.

 

VLF Sayısı Nasıl Azaltılır?

Daha önce de bahsettiğim gibi çok fazla VLF’e sahip olmanın en büyük sebeplerinden biri uygun bir auto growth değerinin kullanılmıyor olmasıdır. Bu yüzden ilk yapılması gereken daha sonraki büyümeleri kontrol altına almak adına uygun bir auto growth değeri verilmesidir. Log file’lar için 512 Mb ya da 1 GB’lık auto growth değerleri kullanılabilir.

Peki şu anki VLF sayısını nasıl düşürebiliriz. Bunun için benim uyguladığım adımlar aşağıdaki gibi;

  • İlk olarak log file ihtiyaç analizi yani ne kadarlık bir log file ihtiyaç olduğu belirlenmelidir. Diyelim ki 100 GB’lık bir log file’a ihtiyacımız olsun.
  • Daha sonra log file olabildiği en küçük değerine kadar shrink edilip küçültülmelidir. (Tabii ki bu operasyon mesai saatleri dışında yapılmalıdır.)
  • Akabinde log file büyük chunk’lar halinde büyütülmelidir. Daha öncede söylediğim gibi büyütmeyi maksimum 8 GB’lık chunk’lar halinde yapabilirsiniz. Dolayısıyla database 8 – 16- 24 olacak şekilde büyütülmelidir. (Daha küçük log file’a sahip olan database’ler için daha küçük chunk değerleri kullanılabilir)
  • Büyütme işlemi 100 GB’a erişilene kadar devam ettirilir.

 

VLF konusu oldukça az bilinen ama çok önemli best practice’lerden biridir. Bu yüzden periyodik olarak database’lerin VLF sayılarını kontrol edip best practice’lerin üzerinde VLF’e sahip olan database’lerde yukarıdaki işlemleri yapmanızı kesinlikle tavsiye ederim.

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


As you all know, on of the most important best practices is all data files of TempDB should be same size.

If you have 4 core processor on your box, then best practice is create Tempdb with 4 data files, and set the initial size for all of them. (let’s say 1 GB)

After that what if Tempdb needs to grow? At this time one of Tempdb data file will be grow and all data files’ size are not identical anymore.

There’s a trace flag for this purpose. With T1117 trace flag, you can keep all data files’ size same after auto growth. I mean all data files growth together if your database needs to grow

Let me give an example. Assume that your TempDB has 4 data files and each data file has 1GB initial size and 256Mb auto growth value. If Tempdb needs to grow, not only one data file grow, all data files grow together, so you can keep them same size.

One last word, this trace flag is instance wide. So every databases in this instance may affected by this behavior.

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


SQL Server 2012 RTM olduktan sonra büyük projelerde kullanılmaya şimdiden başlandı. Tabii ki sistemlerdeki best practice kullanımları oldukça önemli. SQL Server 2012 BPA tool’u ile sistemlerin best practice kontrollerini kullanışlı bir arayüz ile rahatça yapabiliriz.

Tool’u aşağıdaki adresten indirebilirsiniz.

http://www.microsoft.com/en-us/download/details.aspx?id=29302

SQL Server 2012 BPA tool’unun kurulum ve kullanımı SQL Server 2008 R2 sürümü için çıkarılan Best Practice Analyzer tool’una oldukça benzemekte. Bu konu ile alakalı yazdığım detaylı makaleye buradan erişebilirsiniz.

Best Practice’ler ile dolu günler geçirmeniz dileğiyle :)

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


Ya da data dosyalarındaki otomatik büyüme (auto growth) işlemleri normalden fazla zaman mı alıyor? Eğer öyle ise muhtemelen SQL Server 2005 ile gelen Instant File Initialization (Anında Dosya Oluşturulması) özelliğini kullanmıyorsunuzdur.

[more]

SQL Server 2005 ile gelen ve şu ana kadar gördüğüm kadarıyla çok az DBA tarafından bilinen Instant File Initialization, data dosyalarının allocate edilirken 0’lar ile doldurulmadan anında allocate edilmesidir.

Dosyalar verilirken 0’lar ile doldurulmadığı için disaster recovery gibi veritabanlarının sıfırdan restore edildiği durumlarda oldukça fazla zaman kazandırmaktadır.

Ayrıca gene data dosyalarında yapılan otomatik büyüme (Auto Growth) işlemlerinde de yeni verilen alanlar 0’lar ile doldurulmayacağı için işlem daha hızlı tamamlanacaktır.

Instant File Initialization özelliği SADECE data dosyalarında işe yarar. Log dosyalarının doğası gereği verilen alanın 0’lar ile doldurulması gerekmektedir.

Instant File Initialization Nasıl Aktif Edilir?

Instant File Initialization özelliğinin kullanılabilmesi için SQL Server service hesabının Local Group Policy’de Perform Volume Maintenance Tasks’a eklenmesi gerekmektedir. Bu ekrana Start>>All Programs>>Administrative Tools yolundan ulaşabilirsiniz. Servis hesabı eklendikten sonra servisin kapatılıp açılması gerekir.

Karşılaştırma

Makalemin bu kısmında Instant File Initialization özelliğinin aktif ve pasif olduğu durumlarda 20GB’lık yeni bir veritabanı oluşturma işleminin ne kadar sürdüğünü karşılaştıracağız.

İlk olarak Perform Volume Maintenance Task’tan SQL Server service hesabını çıkartıp, servisi kapatıp açalım ve aşağıdaki veritabanı oluşturma script’ini çalıştıralım.

CREATE DATABASE [IFI_Deneme] ON  PRIMARY 
	( NAME = N'IFI_Deneme', FILENAME = N'D:\DATA\IFI_Deneme.mdf' , SIZE = 20971520KB , FILEGROWTH = 1024KB )
 LOG ON 
	( NAME = N'IFI_Deneme_log', FILENAME = N'D:\DATA\IFI_Deneme_log.ldf' , SIZE = 1024KB , FILEGROWTH = 10%)

 

Instant File Initialization aktif değilken veritabanı oluşturulma işlemi 6 dakika 8 saniye sürdü.

Şimdi aynı işlemi Perform Volume Maintenance Tasks’a SQL Server service hesabını ekledikten ve servisi kapatıp açtıktan sonra tekrar yapalım.

Bu şekilde yani Instant File Initialization aktif iken veritabanı oluşturulma işlemi 3 saniye sürdü.

Neredeyse 120 kat daha hızlı. Süper değil mi?

240 GB'lık bir veritabanı üzerinde yaptığım restore denemesinin sonuçları ise şu şekilde;

Instant Instant File Initialization Aktif değil iken : 1.5 saat

Instant Instant File Initialization Aktif iken : 37 dakika 34 saniye

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


Mart 2011’de yayınladığım SQL Server’da Index Kavramı başlıklı makalemden sonra bugün de performans iyileştirmenin bir diğer büyük adımı olan SQL Server’da İstatistis (Statistics) Kavramı üzerine yazılmış detaylı makalemi paylaşıyorum.

Bu makale, SQL Server’da istatistiklerin kullanım amacını,faydalarını ve güncel olmalarının önemini sorguladıktan sonra, istatistiklerinin içeriğinin incelenmesi ve istatistiklerin otomatik oluşturulma ve güncellenme parametrelerinin ve bu parametrelerin best practice’lerinin neler oldukları üzerinde duracaktır.

[more]

Makaledeki ana başlıklar şu şekildedir.

  • İstatistik (Stat) Nedir?
  • DBCC SHOW_STATISTICS Komutu ile İstatistik İçeriğini Görüntülemek
  • İstatistiklerin Güncel Olmasının Önemi
  • İstatistiklerin Otomatik Oluşturulma ve Güncellenme Parametreleri
    • Auto_Create_Statistics
    • Auto_Update_Statistics
    • Auto_Update_Statistics_Async
  • SQL Server Profiler ile İstatistik Oluşma ve Güncellenme İşlemlerini İzlemek
  • Sonuç

Makale çok uzun olduğu için word formatında yayınlayacağım. Dosyayı buradan indirebilirsiniz.

 

İyi Çalışmalar

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


SQL Server’da sistemin nasıl çalıştığını kontrol etmek için bakacağımız belkide ilk yer SQL Server Error Log’larıdır. SQL Server ve Agent Error Log’ları sayesinde sistemde herhangi bir ciddi problem olup olmadığını kontrol etmemiz mümkündür.

Bugünkü yazımda SQL Server Error Log’ların sayısının nasıl arttırılacağını, yeni bir error log dosyasının nasıl create edilebileceğini, kısacası SQL Server’da Error Log’lar ile çalışırken hangi best practice’leri uygulamamız gerektiğinden bahsedeceğim.

[more]

Bu makalemde şu ana başlıklar üzerinde duracağız.

  • SQL Server’da Error Log’lar ile Çalışmak
  • Database Engine Error Log’ları
    • Database Engine Error Log’ları Hakkında Genel Bilgilendirme
    • Database Engine Error Log Recycle’ı Elle Tetiklemek (master.sys.sp_cycle_errorlog)
    • Database Engine Error Log’larının Sayısını Arttırmak
    • Database Engine Error Log’ları Okumak İçin Özelleştirilmiş Log Arama SP’si
    • Başarılı Backup İşlemi Log’larının Error Log’a Yazılmasını Engellemek
  • SQL Server Agent Error Log’ları
    • SQL Server Agent Error Log’ları Hakkında Genel Bilgilendirme
    • SQL Server Egent Error Log Recycle’ı Elle Tetiklemek (msdb.sys.sp_cycle_agent_errorlog)
  • Error Log Recycle İşlemini SQL Job ile Tetiklemek

SQL Server ve Agent Error Log’lar eğer değişiklik yapılmadıysa şu tarz bir folder’da bulunur.

C:\Program Files\Microsoft SQL Server\MSSQL10.S10ENT\MSSQL\Log

Bu folder’da bulunan ERRORLOG isimli dosyalar Database Engine’in Error Log’ları, SQLAGENT şeklinde başlayan dosyalar ise SQL Server Agent’ın Error Log’larıdır.

Database Engine Error Log’ları

SQL Server Database Engine için default olarak 1 adet aktif (ERRORLOG) ve 6 adet arşiv (ERRORLOG.1’den ERRORLOG.6’ya kadar olan dosyalar) olmak üzere 7 adet error log dosyası bulunmaktadır. Her SQL Server servisi restart olduğunda aktif olan log ERRORLOG.1 haline dönüşür ve ondan sonraki error log’lar da bir sıra kayar. Ve sondaki error log’da silinir. (Bu işleme recycle denilmektedir.)

Recycle işlemini şu şekilde gösterebiliriz.

el1

Recycle işleminin servis restart’ı ile olduğunu söylemiştik. Bu işlemi elle tetiklemekte mümkündür. Bir sonraki bölümde bu işlemin nasıl yapılabileceğine değiniyor olacağım.

Database Engine Error Log Recycle’ı Elle Tetiklemek (master.sys.sp_cycle_errorlog)

SQL Server Database Engine servisi restart olduğunda yeni bir error log dosyası oluşur ve en sondaki error log dosyası silinir demiştik. Bu işleme de Recycle dendiğini belirtmiştik. Detayları bir önceki bölümde inceleyebilirsiniz.

SQL Server servisinin uzun süre ayakta olduğu ya da bir hatadan dolayı çok fazla error basıldığı durumda aktif ErrorLog dosyası şişmeye başlar ve büyük bir boyuta erişir. Böyle bir durumda bu errorlog dosyasının içeriğine bakmak oldukça güç hale gelir.

İşte böyle bir durumda 0’dan yeni bir error log dosyası oluşturmak için servisi restart etmektense recycle işlemini elle tetiklememiz mümkündür.

Aşağıdaki SP execute edildiğinde aktif olan errorlog dosyası ERRORLOG.1 haline dönüşecek ve yeni bir error log dosyası 0’dan oluşturulacaktır.

EXEC master.sys.sp_cycle_errorlog;

 

Database Engine Error Log’larının Sayısını Arttırmak

Bir önceki bölümde anlattığım gibi servis restart olduğunda ya da recycle işlemi elle tetiklendiği zaman yeni bir error log dosyası oluşturulur ve en sondaki error log dosyasıda silinir. Yani default olarak 1 aktif 6 da arşiv olmak üzere 7 error log dosyasına izin verilir.

Error Log’lar sistemi analiz etmek için etkin yöntemlerden biri olduğu için eski error log dosyalarının hemen silinmesini istemeyebiliriz. Bu durumda saklanacak error log dosyası parametresini değiştirmemiz gerekir.

Bu değişikliği Management Studio üzerinden şu şekilde yapabiliriz.

  1. Management >> SQL Server Logs yazısına sağ tıklayıp configure ekranını açıyoruz. 

    el2
  2. Gelen ekranda kaç adet error log’un arşiv olarak saklanmasını istediğimizi belirtip OK’e basıyoruz. 

    el3

Database Engine Error Log’ları Okumak İçin Özelleştirilmiş Log Arama SP’si

SQL Server Log’larını okurken filter özelliği kullanabilmekteyiz. Ama bu filter özelliği sadece “like” yani “içinde geçen” şeklinde çalışmaktadır. Ve ne yazık ki “not like” yani “içinde geçmeyen” şeklinde bir filter verememekteyiz. Peki ne zaman ihtiyacımız olur not like aramasına. Örneğin başarılı backup işlemleri loglandığında ve çok sık aralıklarla TLog backup’ı aldığımızda log dosyası çok fazla sayıda backup bilgisi ile dolmaktadır. Ve biz bu backup loglarını exclude ederek raporu görüntülemek isteyebiliriz.

İşte bu amaçla yazmış olduğum SP’yi anlattığım makaleme buradan erişebilirsiniz.

Başarılı Backup İşlemi Log’larının Error Log’a Yazılmasını Engellemek

SQL Server da başarılı olan her backup işlemi bildiğiniz gibi SQL Server Log’a yazılmaktadır. TLog backup kullanımınız var ise ve çok sıklıkla backup alıyorsanız SQL Server Log a çok fazla sayıda kayıt yazılacaktır ve bu da log’un okunmasını zorlaştıracaktır. Şu linkten erişebileceğiniz makalemde başarılı backup işlemlerinin SQL Server Log’a yazılmasını nasıl engelleyeceğimizi görebilirsiniz.

SQL Server Agent Error Log’ları

SQL Server Agent Error Log’ları da Database Engine Error Log’ların da olduğu gibi servis restart olduğunda recycle olur. Tabi burada bahsettiğimiz servis database engine servisi değil SQL Server Agent servisidir.

Bir diğer farklılık ise Database Engine log’ları default olarak 1+6 log file’dan oluşmakta ve bu rakamda değişiklik yapılabilmekteyken SQL Agent Error Log’ları 1+9 log file’dan oluşmakta ve bu rakamlarda değişiklik yapılamamaktadır. Aktif olan SQL Agent Error Log’un dosya adı SQLAGENT.OUT, arşiv olan log file’ların adları ise SQLAGENT.x şeklindedir.

SQL Server Agent Error Log Recycle’ı Elle Tetiklemek (master.sys.sp_cycle_agent_errorlog)

SQL Server Agent Error Log recycle işlemini hem SSMS’ten hem de TSQL ile yapmamız mümkündür.

Management Studio’dan recycle işlemini yapmak için SQL Server Agent >> Error Logs yazısına sağ tıklayıp açılan ekrandan Recycle yazısını tıklamamız gerekir.

el4

Aynı işlemi TSQL ile şu şekilde yapabiliriz.

EXEC msdb.dbo.sp_cycle_agent_errorlog;

 

Error Log Recycle İşlemini SQL Job ile Tetiklemek

Error Log’ları servisler restart olduğunda recycle olur aynı zamanda elle tetiklememizde mümkündür diye belirtmiştik.

Şimdi bu işlemi otomatize etmek için bir SQL Server Job hazırlayacağız ve her ayın başında çalışan bu job vasıtasıyla hem database engine hem SQL Server Agent log’larını otomatik olarak recycle edeceğiz.

Bu şekilde otomatik olarak error log’ların boyutlarını kontrol altında tutmuş olacağız.

Bahsi geçen Job’ın script’ine aşağıda erişebilirsiniz.

USE [msdb]
GO
BEGIN TRANSACTION
DECLARE @ReturnCode INT
SELECT @ReturnCode = 0
IF NOT EXISTS (SELECT name FROM msdb.dbo.syscategories WHERE name=N'Database Maintenance' AND category_class=1)
BEGIN
EXEC @ReturnCode = msdb.dbo.sp_add_category @class=N'JOB', @type=N'LOCAL', @name=N'Database Maintenance'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback

END

DECLARE @jobId BINARY(16)
EXEC @ReturnCode =  msdb.dbo.sp_add_job @job_name=N'Error Log Recycle', 
		@enabled=1, 
		@notify_level_eventlog=0, 
		@notify_level_email=0, 
		@notify_level_netsend=0, 
		@notify_level_page=0, 
		@delete_level=0, 
		@description=N'No description available.', 
		@category_name=N'Database Maintenance', 
		@owner_login_name=N'sa', @job_id = @jobId OUTPUT
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback

EXEC @ReturnCode = msdb.dbo.sp_add_jobstep @job_id=@jobId, @step_name=N'Database Engine Log Recycle', 
		@step_id=1, 
		@cmdexec_success_code=0, 
		@on_success_action=3, 
		@on_success_step_id=0, 
		@on_fail_action=2, 
		@on_fail_step_id=0, 
		@retry_attempts=0, 
		@retry_interval=0, 
		@os_run_priority=0, @subsystem=N'TSQL', 
		@command=N'EXEC master.sys.sp_cycle_errorlog;', 
		@database_name=N'master', 
		@flags=0
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback

EXEC @ReturnCode = msdb.dbo.sp_add_jobstep @job_id=@jobId, @step_name=N'SQL Server Agent Log Recycle', 
		@step_id=2, 
		@cmdexec_success_code=0, 
		@on_success_action=1, 
		@on_success_step_id=0, 
		@on_fail_action=2, 
		@on_fail_step_id=0, 
		@retry_attempts=0, 
		@retry_interval=0, 
		@os_run_priority=0, @subsystem=N'TSQL', 
		@command=N'EXEC msdb.dbo.sp_cycle_agent_errorlog;', 
		@database_name=N'msdb', 
		@flags=0
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_update_job @job_id = @jobId, @start_step_id = 1
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_add_jobschedule @job_id=@jobId, @name=N'Every Month', 
		@enabled=1, 
		@freq_type=16, 
		@freq_interval=1, 
		@freq_subday_type=1, 
		@freq_subday_interval=0, 
		@freq_relative_interval=0, 
		@freq_recurrence_factor=1, 
		@active_start_date=20110419, 
		@active_end_date=99991231, 
		@active_start_time=0, 
		@active_end_time=235959, 
		@schedule_uid=N'f631ead7-612f-4536-bd65-15aa1f75179a'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_add_jobserver @job_id = @jobId, @server_name = N'(local)'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
COMMIT TRANSACTION
GOTO EndSave
QuitWithRollback:
    IF (@@TRANCOUNT > 0) ROLLBACK TRANSACTION
EndSave:

GO

 

SQL Server’da sistemin nasıl çalıştığını kontrol etmek için Error Log’ların analizi oldukça fazla kullanılan yöntemlerden biridir. Bu yüzden best practice’lere göre ayarlanmış SQL Server ve Agent Error Log kullanımı ileride oluşabilecek sıkıntıların önüne geçmek için çok önemlidir.

 

İyi Çalışmalar

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


12 Ocak Çarşamba günü yapmış olduğum webcast’te kullandığım powerpoint dosyasını ve scriptleri sizinle paylaşmak istiyorum.

İlerleyen günlerde webcast’i video formatında da paylaşıyor olacağım.

[more]

PowerPoint Dosyası

http://www.turgaysahtiyan.com/file.axd?file=2011%2f01%2fMSSQL_2008_BPA_Sunum.pptx

Sunumda Kullanılan Scriptler

--Engine - Databases using simple recovery model
--Recovery Model'i simple olan databaseler
Select *
from sys.databases
where recovery_model_desc='SIMPLE' and database_id>4

--Engine – Backups outdated for databases
--Son Backup Alma Zamanları ve Backup Alınan Yerler
SELECT xx.*,T3.physical_device_name FROM
(
SELECT
T1.Name as DatabaseName,MAX(T2.backup_finish_date) as backup_finish_date,
COALESCE(Convert(varchar(12), MAX(T2.user_name), 101),'NA') as UserName
FROM sys.sysdatabases T1
LEFT OUTER JOIN msdb.dbo.backupset T2 ON T2.database_name = T1.name
where T1.dbid>4
GROUP BY T1.Name
)xx
LEFT OUTER JOIN msdb.dbo.backupset T2 ON T2.database_name = xx.DatabaseName and T2.backup_finish_date=xx.backup_finish_date
LEFT OUTER JOIN msdb.dbo.backupmediafamily T3 ON T3.media_set_id = T2.media_set_id
ORDER BY xx.DatabaseName

--Engine - Database files and backup files exist on the same volume
--Datanın bulunduğu yer ile backup ın alındığı yer aynı olan DB'ler
WITH CTE 
AS
(
select DB_NAME(mf.database_id) as DBName
	,LEFT(mf.physical_name,1) as DBFilesFolder 
	,LEFT(bmf.physical_device_name,1) as LastBackupFolder
	,bs.backup_finish_date as LastBackupDate
	,ROW_NUMBER() OVER (PARTITION BY DB_NAME(mf.database_id) ORDER BY bs.backup_finish_date desc) AS RowNumber
from sys.master_files mf
LEFT OUTER JOIN msdb.dbo.backupset bs ON bs.database_name = DB_NAME(mf.database_id) 
LEFT OUTER JOIN msdb.dbo.backupmediafamily bmf ON  bmf.media_set_id = bs.media_set_id
where database_id>4
group by database_id, LEFT(mf.physical_name,1),LEFT(bmf.physical_device_name,1),backup_finish_date
)
Select DBName,DBFilesFolder,LastBackupFolder,LastBackupDate 
from CTE 
where RowNumber=1 and DBFilesFolder=LastBackupFolder

--Engine – Database consistency check not current
--En son sağlıklı DBCC CheckDB Tarihi kontrolü
--dbi_dbccLastKnownGood
DBCC DBINFO('AdventureWorks') WITH TABLERESULTS 

--Engine - Missing Tempdb errors fix or trace flag
--SQL Server Service Pack'ini sorgulamak
select SERVERPROPERTY('ProductLevel')

--Engine – SQL Server tempdb database not configured optimally
--TempDB data file'ları ve boyutları
select DB_NAME (database_id) as DBName
      ,name
      ,Size/128 as Size_MB
from sys.master_files
where database_id=2 and type=0

--Core CPU sayısı
select cpu_count from sys.dm_os_sys_info

--Engine – SQL Server Admin role membership check
--sysadmin listesi
SELECT
p.name AS [Name]
FROM
sys.server_principals r
INNER JOIN sys.server_role_members m ON r.principal_id = m.role_principal_id
INNER JOIN sys.server_principals p ON
p.principal_id = m.member_principal_id
WHERE r.type = 'R' and r.name = N'sysadmin' 

 

İyi Çalışmalar

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


12 Ocak Çarşamba günü yapacağım webcast’in duyurusunu yapmak istiyorum.

SQL Server 2008 R2 Best Practices Analyzer başlıklı webcast’im 12.01.2011 tarihinde 10:00-11:00 saatleri arasında gerçekleşecek.

Aşağıdaki url’i kullanarak vereceğim bu webcast’e katılabilirsiniz.

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032474078&Culture=TR-TR

[more]

Ajandamız şu şekilde olacak;

  • SQL Server BPA Nedir?
  • Best Practice Kavramı Nedir?
  • Kurulum İşlemleri
  • BPA’yı Network Üzerinden Kullanmak İçin Yapılması Gerekenler
  • BPA’ya Genel Bir Bakış
  • SQL Server 2008 Best Practice’leri
  • Soru – Cevap

Vaktiniz varsa katılmanızı kesinlikle tavsiye ederim.

 

İyi Çalışmalar

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


Standalone yani herhangi bir domain’e ait olmayan bir bilgisayarda SQL Server 2008 R2 BPA kurulumu yaparken aşağıdaki gibi bir hata ile karşılaşabilirsiniz.

[more]

There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contat your support personel or package vendor.

image

Bu hatayı almadan kurulumu sorunsuz bir şekilde yapmak için uygulamanız gereken adımlar aşağıdaki gibi.

  1. Bilgisayarınızda Windows PowerShell 2.0’ın kurulu olduğundan emin olun. Eğer kurulu değilse aşağıdaki adresten indirip kurun.
    http://www.microsoft.com/downloads/en/details.aspx?FamilyID=50633A1F-A665-425D-923C-1A269F8AC084
  2. Windows PowerShell 2.0’ı bir admin account’u ile açın.
  3. Enable-PSRemoting komutunu çalıştırın.
  4. winrm set winrm/config/winrs `@`{MaxShellsPerUser=`"10`"`} komutunu çalıştırın.
  5. Command prompt u açın ve BPA kurulumunu şu şekilde başlatın.
    msiexec /i "C:\Tools\SQL2008R2BPA_Setup64.msi" SKIPCA=1

Bu aşamaları hatasız geçerseniz BPA kurulumunuz sorunsuz tamamlanacaktır.

 

İyi çalışmalar

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


SQL Server 2008 R2 Best Practices Analyzer, instance inizi best practice değerlerine göre kontrol edip size önerilerde bulunan bir tooldur. Bugünkü makelemizde bu tool un kullanımını inceliyor olacağız.

Best practise kavramını biraz açalım. Best practise bahsi geçen teknolojik ürün üzerinde kabul görmüş genel konfigurasyonlardır. Örneğin SQL Server ı ele alacak olursak; Database Data ve Log dosyalarını performans amaçlı farklı fiziksel disklerde bulundurmak best practice dir. Ya da TempDB Data file larını core cpu sayısı kadar yapmak gene bir SQL Server Best Practice dir.

Microsoft SQL Server 2005 Best Practise tool unu release ettikten sonra 2008 Best Practice tool u için çok uzun süre bekledi ve ancak 18.06.2010 tarihinde release edebildi. Çok uzun bir süre 2008 ortamlarımızda hala 2005 best practice tool unu kullanmak zorunda kalırken artık şimdi elimizde 2008 best practice tool u var. Ve bu yazımızda bu tool un detaylarına iniyor olacağız.

[more]

Makalemi 4 başlık altında toplayacağım

  • Kurulum
  • MBCA’ya İlk Bakış
  • MBCA ile Network’teki Bir DB Server’a Bağlanma
  • Tarama Sonucu Bulguları

Kurulum


Öncelikle tool u bilgisayarımıza kuralım. Best Practice Analyzer 2008 R2, Microsoft Baseline Configuration Analyzer (MBCA) 2.0 çatısı altında çalışmaktadır. Dolayısıyla ilk olarak bu tool u bilgisayarımıza kuralım. Download için aşağıdaki MSDN linkini kullanabilirsiniz. Bu linkten sisteminiz için uygun olan tool u indirip kurunuz.

http://www.microsoft.com/downloads/details.aspx?FamilyID=1B6E9026-F505-403E-84C3-A5DEA704EC67&amp;displaylang=en&displaylang=en

Eğer kurulumda “Microsoft Baseline Configuration Analyzer 2.0 is not supported on this SKU.” gibi bir hata alıyorsanız işletim sistemi uyumluluğunu kontrol etmenizde fayda var. Çünkü MBCA sadece aşağıdaki OS larda support edilmektedir.

Supported Operating Systems: Windows 7 Enterprise; Windows 7 Professional; Windows 7 Ultimate; Windows Server 2003; Windows Server 2003 R2 (32-Bit x86); Windows Server 2008; Windows Server 2008 R2; Windows Vista Business; Windows Vista Enterprise; Windows Vista Ultimate

MBCA kurulumunu bitirdikten sonra şimdi Best Practice Analyzer 2008 R2 kurulumuna geçebiliriz. Download için aşağıdaki Microsoft linkini kullanabilirsiniz. Bu linkten sisteminiz için uygun olan tool u indirip kurunuz.

http://www.microsoft.com/downloads/details.aspx?FamilyID=0FD439D7-4BFF-4DF7-A52F-9A1BE8725591&amp;displaylang=en&displaylang=en

Gene Supported Operating Systems kısmını kontrol ederek operating sisteminizin desteklenenler listesinde olduğunu teyit etmenizde fayda var.

Supported Operating Systems: Windows 7; Windows Server 2003; Windows Server 2008; Windows Server 2008 R2; Windows Vista

 

MBCA’ya İlk Bakış


MBCA’yı çalıştıralım. Home ekranında SQL Server 2008 R2 BPA’yı seçelim.

1

Enter Parameters ekranında server ve instance bilgilerini dolduralım. İlk örneğimde kendi makinam üzerinde bulunan DB Engine’i analiz edeceğim.

Daha sonra analiz edilmesini istediğimiz service’lerin yanındaki enable seçeneklerini işaretleyelim.

2

Start Scan yazısına tıkladığımızda MBCA seçtiğimiz DB Server’ı analiz etmeye başlayacak ve ekran görüntüsü bu analiz süresi boyunca aşağıdaki gibi olacaktır.

3

Analiz işlemi tamamlandığında aşağıdaki gibi bir sonuç ortaya çıkacaktır.

4

Ekran detayına inersek;

1 – Select Report Type

Collected Data seçeneği seçilirse tarama sonuçlarını ağaç yapısında görebiliriz.

5

Biz bu makalemizde genelde Results seçeneğini kullanacağız.

2 – Noncompliant – All

All seçeneğinde analiz sonucu best practise değerlerimize uygun olan kayıtlarda gösterilir. Noncompliant seçeneğinde gösterilmez.

6

3 – Export Report

Tarama sonucunu XML file olarak export edebilirsiniz.

4 – Filter

Tarama sonucu çıkan ifadelerde belirli bir ifadeyi aratabilirsiniz. Örneğin aşağıdaki örnekte tempdb ifadesi aratılmıştır.

7

5 – Arrange by

Tarama sonucu çıkan bulguları neye göre dizeceğimizi belirler. Severity, önem derecesini göstermektedir. Genelde bu kritere göre dizim yapmakta fayda vardır. İstersek Category’e görede dizme yapabiliriz.

8

6 – Tarama Sonucu

Tarama sonucu çıkan bulguları bu ekranda görebilir, bu bulguların detayına erişerek Etki(Impact) ve Resolution(Çözüm) bilgilerine ulaşabiliriz.

9

MBCA ile Network’teki Bir DB Server’a Bağlanma


MBCA ile Network üzerindeki bir DB Server’a ayar yapmadan bağlanmaya çalışırsak aşağıdaki gibi bir hata mesajı ile karşılaşmamız mümkün.

10

Hata mesajının detayında da görebileceğiniz gibi MBCA yı kullanan kullanıcın remote makinada local admin olması gerekmektedir. Ayrıca remote makinada powershell’in enable edilmesi gerekmektedir.

Bunun için hem local hemde remote makinalarda powershell’de şu komutların çalıştırılıp powershell’in remote kullanıma açılması gerekmektedir.

1. Enable-PSRemoting –f

2. winrm set winrm/config/winrs `@`{MaxShellsPerUser=`"10`"`}

11

Bu ayarlamalar yapıldıktan sonra analiz işlemi problemsiz gerçekleştirilecektir.

12

Tarama Sonucu Bulguları


Makalemin bu bölümünde tarama sonucu çıkan bazı önemli bulguların detayına inip, bu bulgunun neden geldiğine, neye sebep olabileceğine ve nasıl düzeltilebileceğine bakıyor olacağız.

Engine - Database files and backup files exist on the same volume

13

Best practice olarak disklerde bir sıkıntı olma ihtimalinden dolayı data ve log dosyalarının farklı fiziksel disklerde bulundurulması önerilir. Aynı şekilde alınan backup’larında farklı bir fiziksel diskte bulundurulması best practice’dir. Bu error sonucu bize data ve backup dosyalarının aynı diskte olduğunu göstermekte.

Engine – SQL Server tempdb database not configured optimally

14

Best practice olarak tempdb datafile larının core CPU sayısı kadar yapılması önerilir. Yani 4 CPU lu 8 core lu bir sunucuda tempdb datalarını birbirlerine eşit boyutta 8 adet dosya yapmanızı öneririm.

Engine – Authentication Mode

15

Authentication Mode’un Windows Authentication olması best practice’dir. Lakin hemen hemen her firmada SQL Login’ler ile login olunmaya çalışıldığı için bu bulgu üzerinde çok durmayabiliriz.

Engine – Database consistenct check not current

16

Issue kısmında belirtilen DB’ler için hiç DBCC CHECKDB yapıldığını göstermektedir. DBCC CheckDB DB consistency ve integrity’sini kontrol eden bir sistem komutudur. Best practice olarak periyodik olarak bu kontrolün DB’ler üzerinde yapılması önerilir.

Engine – Backups outdated for databases

17

Bu bulguda uzun zamandır backup alınmayan DB’ler hakkında bilgi verilmektedir. Diskte ve DB’de oluşabilecek problemlerden dolayı her daim iyi bir backup policy üzerinde çalışma yapılması gerekmektedir.

Engine – Databases using simple recovery model

18

Point in time recovery ve disaster anında minimum data kaybı ile sıyrılmak için production DB’lerinde full recovery model kullanılması önerilmektedir. Bu bulguda simple recovery model kullanan DB’ler raporlanmaktadır.

 

ÖZET


Best practise bahsi geçen teknolojik ürün üzerinde kabul görmüş genel konfigurasyonlardır. SQL Server 2008 R2 Best Practices Analyzer ile Database Server’larınızı periyodik olarak kontrol edip, best practice’lere uymayan durumları sorgulayabilirsiniz.

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan