SQL Server'da DBA'ler için CheckList 1.Bölüm

Genel DBA Best Practices

Günlük Olarak Yapılması Beklenenler:

·         OS event log'lar ve Sql Server Log'lar da olağandışı bir şey olup olmadığı kontrol edilmelidir.

·         Zamanlanmış olan job'ların hepsinin düzgün şekilde çalıştığı kontrol edilmelidir.

·         Backup'ların başarılı şekilde güvenli bir ortama kayıt edildiği doğrulanmalıdır.

·         SQL Server'ın out of disc space hatası almadığı kontrol edilmeli ayrıca iyi performans sağlanabilmesi için bütün diskler üzerinde en az %15 ve üzeri boş alan bırakılmalıdır.

·         Gün içerisinde belli aralıklarla Profilier/SQL Trace ile performans izlenmelidir.

·         Düzenli olarak sistemde sorunlara sebep olabilecek problemler tanımlanmalı ve takip edilmelidir.

·         Sunucularda yapılan değişiklikler için düzenli kayıtlar tutarak performans ve benzeri sorunlar tanımlanarak dokümante edilmelidir.

·         SQL Server' da alert tanımlayarak herhangi bir problem oluşma durumunda e-mail ile bilgilendirilin ki doğru zamanda hatayı giderebilmek için aksiyon alma imkânı yaratın.

·         Düzenli olarak backup'lar alarak test server'lar da bunları çalışılabilirliğini test edin. Her gün aldığınız bütün backup'ları test etmek zorunda değilsiniz. Fakat alınan backup’ların doğru ve çalışır durumda olduğundan emin olun.

·         Profesyonel gelişiminizi ilerletmek için DBA olarak yeni bir şeyler öğrenmeye zaman ayırın.

INSTALLATION
·         Acil durumlarda hızlı aksiyon alabilmek için SQL Server Instance yükleme talimatlarının en ince ayrıntısına kadar yazılı olarak bulunması gerekmektedir.

·         Eğer mümkünse,  bütün SQL Server Instance'ların tutarlı olabilmesi için şirket kapsamında yükleme ve konfigre seçenekleri aynı olmalıdır.

·         SQL Server                 Servis'lerini instance üzerinde yüklemeyin.(Microsoft Full-Text Indexing, Reporting Service, Analysis Service gibi...)

·         Yüksek performans için SQL Server Windows işletim sistemi üzerinde kullanın.

·         Optimum performans sağlamak için fiziksel server'ınızda bir tane SQL Server Instance çalıştırın.

·         En verimli I/O performansı için databse file(.mdf) ile log file (.ldf) farklı disklerde konumlandırın.

·         Eğer Temdb sistem içerisinde çok yoğun kullanılıyorsa, Tempdb'nin de ayrı bir disc üzerinde çalışmasını sağlayın.

·         Domain Controller üzerinde SQL Server kurulumu yapmayın.

·         SQL Server'ın NTFS formatında ki diskte yüklü olduğundan emin olun.

·         NTFS data file encryption ve compression’ı(sıkıştırma) SQL Server database ve log dosyalarında kullanmayın.

UPGRADİNG

·         Upgrade işlemine başlamadan önce SQL Server Upgrade Advisor'u çalıştırın.

·         Yükseltme işlemine başlamadan önce gerekli olan değişiklikleri yapın.

·         Production ortamına geçmeden önce upgrade işlemini test ortamında deneyin ve uygulamalarınızı yeni upgarde edilmiş SQL Server üzerinde deneyin.

·         Upgarde işlemini yapmadan önce yeni sürümde çıkabilecek problemlere karşı geri dönüş için planlamanızın olduğundan emin olun.

·         SQL Server cluster'ları upgarde etmeyin.  Bunun yerine yeni bir donanım üzerinde rebuild edin.

·         SQL Server önceki bir sürüm üzerinden yükseltme yaparsanız, bütün veritabanı istatistiklerinizi güncellemeniz gerekmektedir. Çünkü istatistikler update işlemi esnasında otomatik olarak güncellenmezler. Manuel olarak müdahale etmeniz gerekir.

SECURİTY

·         SQL Server'ın fiziksel güvenliği sağlanmalıdır, yetkisiz bir kullanıcının fiziksel olarak server'lara bağlanması engellenmelidir.

·         Sadece gerekli olan network kütüphaneleri ve protokolleri SQL Server instance'da yüklü olmalıdır.

·         Sysadmin yetkisi olabildiğince minimize edilmelidir.

·         Sadece ihtiyaç dâhilinde sysadmin yetkisi ile giriş yapılmadır. Sysadmin yetkileri gerekli değilken DBA'ler için farklı account'lar tanımlanmalı ve normal durumlarda bu yetki ile login olunmalıdır.

·         SA'ya olabildiğince karmaşık bir şifre atanmalı ve SQL Server'a bu şifre kullanılarak asla giriş yapılmamalıdır. Bunun yerine SQL Server'a sysadmin olarak login olurken Windows Authentication hesabı kullanılmalıdır.

·         Kullanıcılara işini gerçekleştirebileceği minimum oranda yetki verilmelidir.

·         Kullanıcılara direk olarak tablolara erişmek yerine stored Procedure ya da view'lara erişim yetkisi sağlayın.

·         SQL Server Login yerine mümkün olduğunca windows authentication login'i kullanın

·         SQL Server login hesabı için güçlü bir şifre kullanın.

·         Public database rolü için izin yetkilerini kısıtlandırın.

·         SQL Server'a artık bağlanmasına ihtiyaç kalmayan kullanıcıların login hesaplarını temizleyin.

·         Sysadmin olmayanlara asla xp cmdshell yetkisi vermeyin.

·         Production ortamında bulunan SQL Server instance'lardan sample veritabanlarını silin.

·         Kullanıcı gruplarını yönetebilmek için Windows Global Groups ya da SQL Server Role benzer izinleri kullanın.

·         SQL Server üzerinde network paylaşımı yapmaktan kaçının.

·         Login auditing ilgili düzenlemeler yapılarak kimlerin login’lerinin başarılı olup kimlerin başarısız olduğunun takibini yapın.

·         SA hesabı ile uygulamalardan SQL Server'a erişmek için giriş yapılmamalıdır.

·         SQL Server'ın arka planda firewall ile korunduğundan emin olun direkt olarak internete savunmasız olarak bağlantıya izin vermeyin.

·         Her bir SQL Server servisi farklı bir Windows domain account'u altında çalıştırılmalıdır.

·         SQL Server servis hesapları ihtiyaç olunan minimum düzeyde izin ve yetkiler ile çalıştırılmalıdır.

·         SQL Server'ın kurulu olduğu server da antivirüs ve antispyware koruması için güvenlik programları kullanın. Gün içerisinde kullanıcı aktiviteleri yoğunluğu azken sistemi taratın.

·         Bütün SQL Server backup'larınızı 3. parti uygulamalar ile şifreleyin(Red Gate, SQL Backup Pro)

·         SQL Server güvenlik taraması sisteminizin güvenlik açıklarınızı tespit eder.

·         SQL Server ve client arasında SSL ya da IPSEC bağlantısını kullanın.

·         Eğer SQL Server 2005/2008 kullanıyorsanız password policy kontrolünü aktif edin.

JOB MAINTENANCE

·         Aynı SQL Server Instance içerisinde farklı job'ların örtüşmesine izin vermeyin. İdeal olan, her bir job farklı zamanlarda çalışacak şekilde planlanmalıdır.

·         Yeni bir job oluşturduğunuz zaman hataları yakalayabileceğinizden emin olmalısınız. Log job aktivitileri ve fail olma durumunda sizi haberdar edecek alert'ler tanımlamasınız.

·         Bütün job'lar atayabileceğiniz ve bir SQL Server login hesabı tanımlayıp job'ların çalışması bunun üzerinde sağlanmalı ve bütün job'lar bu hesap altında toplanmalıdır.

·         Eğer tanımladığınız job'lar T-SQL kodu içeriyorsa, yazılan kodun optimize ve verimli çalıştığından emin olun.

·         Periyodik olarak(günlük,haftalık yada aylık ) logical fregmentation önüne geçebilmek için veritabanızdaki index'lerin rebuild yada reorganize edilmelidir.

·         DBCC ve CHECKDB'yi belli periyotların bütün veritabanı üzerinde çalıştırarak database'in bütünlüğünü denetlemek gerekir.

·         DBCC komutlarını transaction'ın yoğun olduğu zamanlarda kullanmaktan kaçınmak gerekir. Bu komutlar I/O oranını yoğunlaştırır ve SQL Server'ın performansını düşürmektedir.

·         Eğer çok nadiren SQL Server Service'lerini restart'larsanız muhtemel olarak SQL Server'ın Log'ları ciddi miktarda büyüyecektir. Bundan dolayı bunların yüklenmesi ve görüntülenmesi ciddi zaman gerektirir. Güncel error log'u kapatıp yeni bir tane oluşturabilirsiniz.  Bu sayede log'lar ciddi şekilde büyümeyecektir. Bu haftalık olarak yapılabilir.

SQL SERVER CONFIGURATION SETTINGS

·         SQL Server configuration settings'in ayarları default’tan gelen şekli ile kalmalıdır.  Yapılacak olan herhangi bir değişiklik sadece deneyim sahibi olan bir dba tarafından gerçekleştirilmeli ve yapılacak olan değişikliğin server'a lehne veya aleyhine olacak sonuçları kestirebilmelidir.

·         Eğer 32 bit'lik SQL Server kullanıyorsanız ve RAM miktarınız 4 GB'dan yüksekse AWE ayarlarınızın doğru şekilde ayarlandığından emin olun.

·         Çoğu durumda "maximum server memory" ve "minimum server memory"  varsayılan değerlerinde bırakılmalıdır. Çünkü SQL Server, serverdaki memoryi dinamik olarak paylaştırıp optimum performansı sağlar. Eğer 32-bit AWE memory yada 64-bit AWE memory kullanıyorsanız, bu durumda server'daki fiziksel RAM miktarından daha az olarak "maximum server memory" değiştirebilirsiniz.

DATABASE SETTİNGS

·         "Auto create statistics" ve "auto update statistics" seçenekleri tüm user'lar da default olarak bırakılmalıdır. Çok ender durumlar söz konsu olduğu zaman bunlar kapatılabilir ve eğer kapalı durumdaysa manuel olarak istatistikleri update ederek veriler güncel tutulmalıdır.

·         Otomatik Shrink seçeneği her ne kadar çok cazip gözükse de bu çok fazla tavsiye edilen bir seçenek değil. SQL Server kaynaklarını gereksizce harcamak ayrıca index fregmentasyonuna (parçalanma) sebep olacaktır. Eğer ki shrink'in kullanılması gereken bir durum söz konusu ise bunu manuel olarak yapın. Otomatize etmeyin.

·         AutoGrowth seçeneği ile database boyutunun otomatik olarak yönetilmesine güvenilmemelidir. Bunun yerine database'in büyüme trendini izleyerek ileriye yönelik planlama yapıp database boyutu düzenlenebilir. AutoGrowth seçeneği sadece beklenmedik büyümeler için kullanılmalıdır.

REPLICAITON

·         İhtiyaçlar replication topolojisi tasarlanmadan önce net bir şekilde belirlenmelidir. Başarılı bir replication için öncesinde iyi bir planlama yapılmalıdır.

·         İdeal olanı publisher, distributer ve subscriber'ların farklı fiziksel donanımlarda bulunmasıdır.

·         Backup'ların test edilmesi ve yapıya göre belirlenmiş uygun bir restore stratejisi oluşturulmalı ve dokümante edilmelidir.

·         Gerçekten SQL Server replication üzerinde çeşitli gelişmiş modifikasyonlara ihtiyaç duymadıkça performans ve diğer konularda sorunlar ile karşılaşmamak için SQL Server sunmuş olduğu seçenekler üzerinde değişiklik yapmayın. Eğer bunlar üzerinde değişiklik yapıldıysa bütün yapılan değişikliklerin testini yapın ve herhangi bir sorun olmadığından emin olun.

·         Periyodik olarak publisher ve subscriber'lar arasındaki data'ların bütünlüğünün sağlandığından emin olun.

·         Düzenli olarak replikasyon süreçleri ve job'ların sorunsuz çalıştığını takip edin.

·         Düzenli olarak replikasyon performansını izleyin ve her şeyin yolunda gittiğinden emin olun.

·         Bütün replikasyon job'larına alert tanımlayın. Eğer ki job'ların birinde bir fail olma durumu söz konusu olursa en kısa sürede müdahale edebilme şansınız olsun.


KAYNAKÇA
simple-talk.com

MS SQL Server'da Sistem Database'lerini Anlamak

Sql Server instance yüklendiği zaman default olarak belli database'ler instance ile birlikte kurulurlar. Bunların görevlerinin neler olduğu ne işe yaradığını bilmek önemlidir. Aşağıda size bunları anlatmaya çalıştım. Bu default olarak yüklenen database’ler şunlardır:

• Master
• Tempdb
• Model
• msdb
• resource
• distribution

Master Database

Master database aslında isminde de anlaşılabileceği gibi primary (birincil) veritabanımızdır. Bu veritabanı olmadan SQL Server başlatılamaz. Master database önemli database objeleri hakkında bilgileri saklar. Bunlara örnek olarak ise:

Instance içinde olan veritabanları

• AlwaysOn
• Database Mirroring
• Configration
• Login'ler
• Kaynak Yönetimi
• Endpoint

Örneğin aşağıdaki kodu çalıştırırsanız instance'ınızın içinde bulunan tüm database'lerin listesini görerbilirsiniz.

SELECT * FROM sys.master_files

Yukarıdaki query bize veritabanlarının listesini ve ek olarak da her bir database'in konfigrasyon seçenekleri ile ilgili bilgilerde yer almaktadır.

Tempdb Database

TempDb kullanıcılar yada uygulamalar tarafından SQL Server üzerinde oluşturulurlar. TempDb içerisinde geçici objeler saklanır. Bu bahsettiğimiz geçici objeler; geçici tablolar stored procedur'ler, tablo değişkenleri, global temp tablolar bulunur. Bunlara ek olarak da TempDb'de online index işlemleri, Trigger tetiklendikten sonraki durum saklanır. SQL Server her yeniden başlatıldığında TempDb yeniden oluşturulur. Ayrıca TempDb içerisinde kullanıcılar da objeler oluşturabilir. Fakat verileri düzenli olarak tempdb' de saklamak güvenilir bir yöntem değildir. Aslında adından da belli olacağı üzere geçici database olduğu için SQL'in yeniden başlatılması, oturumun kapanması gibi durumlarda buralarda saklanan veriler sıfırlanacaktır. Ayrıca tempdb üzerinde backup ya da restore seçenekleri kullanılamaz. Kafalarda biraz daha netleşmesi açısından benim tempdb'yi en çok kullandığım alanlara değinelim; kritik bir veritabanı üzerinde çalışıldığı için tablolara doğrudan yazma, güncelleme yetkimiz yok. Fakat scriptler üzerinde çalışırken local bir temp tabloya yazıp üzerinde her türlü  insert,update, delete işlemini uygulayarak geliştirmelerimizi test edip emin olduktan sonra gerekli değişiklikler canlı ortama taşınır. 

İki tip şekilde temp db tanımlanabilir:

Create table #table...

scriptini çalıştırırsanız local bir tablo oluşturmuş olursunuz ki bu durumda sadece çalışma yapmış olduğunuz session ve tek bir kullanıcı üzerinden bu tabloya ulaşılabilinir.

Create table ##table...

scripti çalıştırdığı durumda global bir temp table oluşturulmuş olur ve bu table farklı session ve kullanıcılar tarafında erişilebilir olur.

Model Database:

Aynı instance içerisinde oluşturulan bütün veritabanları modellerinin saklandığı yerdir. Aynı zamanda model database bir şablon olarak da kullanılabilir. Örneğin bir instance'ında dâhil olmak üzere belli standart bir tablo için her bir database içerisinde ayrı ayrı oluşturmak yerine tek bir seferde hepsinde model database sayesinde tanımlanabilir.  Eğer model database mevcut değil ya da offline ise tempdb bu durumda oluşturulamaz. Daha öncede bahsettiğimiz gibi Tempdb, SQL Server her başlatıldığında yeniden oluşturulur ki eğer model db'ye ulaşılamıyorsa TempDb'nin de bu durumda yaratılması mümkün olmaz.

Msdb Database:

Msdb database SQL Server Agent'lar için temel olarak back-end veritabanı olarak hizmet eder. Kullanıcı yeni bir Sql Agent Job tanımlarsa ya da bunu schedule(zamanlama) ederse bunların metadata'ları bu database üzerinde saklanırlar. Aynı zamanda aşağıdaki component'leri barındırır.

• Service Brokers
• Alerts
• Log Shipping
• SSIS Packages
• Utility Control Point (UCP)
• Database Mail
• Maintance Plans

Resource Database

Resource database root'lar içersinde gizlenmiştir ve read only(sadece okunabilir) olarak çalışır. Bu database'in en temel amacı bir sonraki SQL Server versiyonuna geçebilmek için upgarde işlemlerini sağlamaktır. Bir SQL Server instance içerisinde bulunan bütün sistem objeleri bu database de bulunur.Resource database içerisinde iki tip dosya vardır: mssqlsystemresource.mdf ve mssqlsystemresource.ldf'tir.Bir diğer önemli bilgi bu veritabanının ID'si 32767'tir ve bu değer SQL Server 2005'ten SQL Server 2014' e kadar aynı kalmıştır. Resource Database Master Database ile aynı lokasyonda bulunmalıdır. Donanımsal bir sıkıntı yaşanması durumunda master database'i yeni bir alana restore etmeniz gerekmektedir. Bunu yapmdan önce WITH MOVE seçeneği ile birlikte yapmamız gerekmektedir ki RESOURCE DATABASE'in .mdf ve .ldf dosyalarıda master database ile birlikte taşınabilsin. Bu database ile ilgili enteresan bir bilgi daha, istisnai durumlar dışında diğer veritabanları gibi Resouce database'in Backup'ını alamaz yada tekrardan restore edemezsiniz.

Distribution Database

Evet, son olarak ele alacağımız sistem veritabanı distribution database. Bu sistem database'i eğer siz instance içiersinde distribution özelliğine sahip bir replication işlemi configre ettiğiniz zaman SQL Server Managament Studio'da system database branch'nin altında bu veritabanını görürsünüz. Replication işlemi için öncelikle verilerin gönderimini sağlayacak olan bir distributor database tanımlamanız gerekmektedir. Bunu da Replication configure ederken buradaki ilgili ekranlardan distribution database oluşturabilirsiniz. Bu veritabanında replication işlemi ile ilgili bütün metadata ve tarihsel dökümler bulunmaktadır.

Transaction Log Dosyaları Nedir? Ne İşe Yarar?

   Transaction log file'lar SQL Server içerisinde yapılan her türlü işlemin tutulduğu yerdir.  SQL Server içerisindeki en önemli parçalardan biri denilebilir. Çünkü herhangi bir disaster recovery durumunda verilerin kurtarılmasını sağlar. Tatbikî transction log file'da herhangi bir bozulma yoksa. Her bir database modifikasyonunda log kayıtları transaction log'lar yazılmaktadır. Burada bilinmesi gereken bir diğer husus değişlikler log'lanırken sıralı olarak kayıt edilirler.

   Transaction log'lar BULK IMPORT ve SELECT INTO durumları haricinde SQL Server'daki her bir transaction’ı saklarlar. Yapı içerisinde Virtual Log Files adı verilen (VLF) küçük parçalara ayrılmışlardır. Bir VLF dolduğu zaman bir sonraki erişilebilir olan VLF yazılmaya devam eder. Aslında buradaki yapıyı bir döngüye benzetebiliriz. Eğer bütün işlemler tamamlanır ve commit edilirse inactive duruma düşen VLF'ler'in içi boşaltılır ve yeniden yeni oluşan log kayıtları tutulması için en başa dönülür. Bu boşaltma işlemi gerçekleşebilmesi için VLF'lerin inactive durumda olması gerekir aksi takdirde log kayıtları gerekli olduğu için silinemez durumda olacaktır.  Inactive durumda olanlar bu sayede tekrardan kullanılabilir ve overwrite işlemi gerçekleşir. Transaction log'lar içerisinde bulunan bir kayıt eğer commit'lendiyse, page'lerde yapılan değişikler checkpoint vasıtasıyla disk'e yazıldıysa full, differential ya da log backup alındıysa artık daha fazla o kayda transaction log' da ihtiyaç yoktur.

   Logical log transaction log'ların aktif parçalarıdır. Log Sequence Number(LSN) transaction log'lar içerisinde her bir transaction için tanımlanırlar. Online transaciton log’lar içerisinde MinLSN en eski aktif transaction'nın başlangıç noktalarıdır.

   Sql server içerisinde birden fazla transaction log tanımlayabilirsiniz. Fakat bu spesifik durumlar dışında önerilen bir şey değildir. Aynı zamanda yazma işlemini arttırdığı için SQL Server performansını düşürübeilir.

Transaction Log’lar Neden Büyür?

                Her bir transaction online transaction log'lara kayıt edildiğinden daha önce bahsetmiştik. Bundan dolayı SQL Server çalışırken transaction log'lar boyut olarak büyürler. Bu nedenle transaction log'ların SQL Server'ın belirlemiş olduğunuz stratejisine uygun olarak bakımlarının yapılması oldukça önemlidir.

   SQL Server'ın transaction log'ların saklanma biçimine göre bize sunmuş olduğu üç farklı recovery model bulunmaktadır.

                1) Simple Recovery Model:  Bu modelde transaction log backup alınması SQL Server tarafından desteklenmemektedir. Log'ların silinme işlemi otomatik olarak yapılmakta ve disk içerisinde ki alan tekrardan kullanılabilir olmasını SQL Server bize kendisi sağlamaktadır. Bu modelde data kaybı riski bulunmaktadır. 

                2)Bulk- Logged Recovery Model:  Bu model de transaction log back up SQL Server tarafından desteklenmektedir. Burada simple recovery model de olduğu gibi otomatik olarak silme işlemi gerçekleşmez. Overwrite olması için transaction log backup'ların düzenli olarak kullanılmayan alanlar inactive olarak işaretlenmelidir. Bulk-Logged recovery model'de bulk operasyonlarını minimum düzeyde loglayarak transaction log’ların alan kullanımı azaltır.

                3)Full Recovery Model:  Transaction log backup bu modelde desteklenmektedir. Normal şartlar altında data kaybı bu modelde mümkün değildir.  Full recovery modelde de otomatik olarak transaction log'lar silinmezler.  Bulk logged recovery modelde de olduğu gibi bu modelde de düzenli olarak kullanılmayan alanlar inactive olarak işaretlenmelidir ki overwrite işlemi gerçekleşebilsin. Bütün transactionlar log'landığı için bu modelde trasaction log'lar oldukça hızlı bir şekilde büyüme eğilimindedirler.

SQL Server yönetiminde Transaction Log’ların bakımının yapılması en önemli görevlerden birisidir denilebilir.  Genelde günlük olarak transaction log'lar izlenmeli hatta çok fazla network trafiği olan sistemlerde daha sık olarak monitoring işleminin yapılması önerilir. Transaction log space'i (kullanılabilir alanı) aşağıdaki kodla izleyebiliriz.

DBCC SQLPERF(LOGSPACE);

GO

   Transaciton log'lar oluşturulmuş olan stratejiye göre düzenli olarak back up'ları alınması auto growth özelliğine göre tercih edilmesi daha sağlıklı olacaktır. Çünkü Transcation log back up aldıktan sonra SQL Server Transaction log dosyasını back up alındığı için truncate edecektir. Back up alındıktan sonrada o alan tekrardan kullanılabilir durumda olacaktır. 

   Transaction log backup'lar disaster recovery durumlarında ciddi önem arz etmektedir. Çünkü bu şekilde ciddi data kayıpları yaşamadan verilrimizi kurtarabiliriz.Örneğin 15 dakikalık aralıklarla back up alınabilir. Bu süreye sisteminize göre siz karar vermeniz daha doğru olacaktır. Bu sayade VLF'ler inaktif olarak işaretlenir ve overwrite ile tekrardan kullanılır.

SQL Server'da Tablo Üzerindeki Aktivitelerin Takibi

Tablo Üzerindeki Aktivitelerin Takibi

Performance tuning’de önemli olan unsurlardan biride hangi tablo üzerinde ne kadar işlem yapıldığını anlamak olacaktır. Aşağıdaki kodda her bir  tablo için bize bilgiler döndürülecek ve bunlar bize tablolar üzerinde gerçekleşen read ve write işlem hacmini gösterecektir.

Yalnız dikkat edilmesi gereken bir husus varki dynamic managament views'dan bu istatistikler Sql Server her restart edildiğinde temizlenirler. Bu istatistikleri(wait ve latch) aynı zamanda manuel olarak da silebilirsiniz. (Dynamic Managament Views  ve function'lar bize server'ın durumu hakkında bilgi verir. Buradan Sql Server'ın durumunu izleyebilir, yaşanan herhangi bir problemi teşhis edebilir yada  performans iyileştirmeleri yapabilirsiniz.) Server'ın daha uzun süre açık olması dynamic management views'ın size daha güvenilir istatiskler sunmasını sağlayacaktır.

SELECT  @@ServerName AS ServerName ,

DB_NAME() AS DBName ,

OBJECT_NAME(ddius.object_id) AS TableName ,

SUM(ddius.user_seeks + ddius.user_scans + ddius.user_lookups)
AS Reads ,

SUM(ddius.user_updates) AS Writes ,

SUM(ddius.user_seeks + ddius.user_scans + ddius.user_lookups

+ ddius.user_updates) AS [Reads&Writes] ,

(SELECT    DATEDIFF(s, create_date, GETDATE()) / 86400.0

FROM      master.sys.databases

WHERE     name = 'tempdb'

) AS SampleDays ,

( SELECT    DATEDIFF(s, create_date, GETDATE()) 
AS SecoundsRunnig

FROM      master.sys.databases

WHERE     name = 'tempdb'

) AS SampleSeconds

FROM    sys.dm_db_index_usage_stats ddius

INNER JOIN sys.indexes i ON ddius.object_id = i.object_id

AND i.index_id = ddius.index_id

WHERE   OBJECTPROPERTY(ddius.object_id, 'IsUserTable') = 1

AND ddius.database_id = DB_ID()

GROUP BY OBJECT_NAME(ddius.object_id)

ORDER BY [Reads&Writes] DESC;

GO