Forum
sys.dm_db_index_usage_stats(urll) DMV sinde index’lerin kullanım oranını görmüştük. Bunun ötesinde hangi index’de update,insert,delete işlemlerinin ayrı ayrı kaç kez gerçekleştiğini, index’te kaç defa bekleme yaşandığını ve IO beklemelerini sorgulamak isteyebiliriz.
Performans sıkıntılarını monitör etmek amaçlı yapılabilecek bu sorgulamalar içinsys.dm_db_index_operational_stats DMF sini kullanabiliriz.
SQL Server da index kullanımının önemine hemen hemen her yazımda değiniyorum.Etkili index kullanımının performans’a inanılmaz artı etkiler yarattığını hepimiz biliyoruz. Yeni bir uygulama geliştirirken index’leri ihtiyaca göre create ediyoruz. Fakat uygulama yaşamaya devam ettikçe yeni index ihtiyaçları ortaya çıkıyor. Bir kısmı bizim kontrolümüz altında olup farkedilebilirken bir kısmını gözden kaçırmamız mümkün.
Bugün anlatacağım 4 DMV ile SQL Server’ın bize create edilmesini önerdiği eksik index’leri nasıl sorgulayacağımızı göreceğiz.
);background-position: 100% 50%;background-repeat: no-repeat no-repeat" href="http://www.turgaysahtiyan.com/post/SQL-Server-e28093-Her-Gun-1-DMW-Gun-4-sysdm_exec_query_stats-ile-Query-Istatistikleri.aspx">sys.dm_exec_query_stats ile Query İstatistikleri yazımda Database Engine’in çalıştırdığı bütün query’lerinin kaynak tüketimi açısından nasıl analiz edilip kötü yazılmış query’lerin bulunabileceğinden bahsetmiştik. Bugünkü yazımda ise aynı performans kontrollerininStored Procedure’ler üzerinde nasıl yapılacağına bakıyor olacağız.
Stored Procedure’lerin istatistiklerini incelemek için sys.dm_exec_procedure_statsDMV’sini kullanacağız. Bu DMV ile CPU, IO gibi değerler üzerinden SP’lerin kaynak tüketimine bakabileceğimiz gibi aynı zamanda kullanılmayan SP’leride analiz edebileceğiz.
Bugün işleyeciğimiz sys.dm_db_partition_stats DMV’si ile sistemde bulunan table’lardaki bütün index’ler için partition bilgileri, kullandıkları page sayısı, satır sayıları gibi bilgileri sorgulayacağız.
Aslında bu bilgileri bu DMV olmadan da table table yada index index dönerek toplamamamız mümkün. Ama sys.dm_db_partition_stats DMV’si tek bir sorgu ile bu bilgilerin tamamına kolayca erişmemizi sağlıyor.
Hocam eline sağlık . Tatile çıkıyorsun yine devam mı 🙂
Danışman - ITSTACK Bilgi Sistemleri
****************************************************************
Probleminiz Çözüldüğünde Sonucu Burada Paylaşırsanız.
Sizde Aynı Problemi Yaşayanlar İçin Yardım Etmiş Olursunuz.
Eğer sorununuz çözüldü ise lütfen "çözüldü" olarak işaretlerseniz diğer üyeler için çok büyük kolaylık sağlayacaktır.
*****************************************************************
Hocam eline sağlık . Tatile çıkıyorsun yine devam mı 🙂
Evet hocam. Tatilde olmama rağmen önceden yazıları hazırlamıştım. Ben tatildeyken her gün yayınlandılar 🙂
SQL Server DMV’leri arasında en sevdiğim DMV’lerden biride sys.dm_os_sys_infoDMV’sidir. Bu DMV ile Server’ın ne zaman start olduğu, SQL Server’ın en son ne zaman restart edildiği, CPU adeti ve fiziksel memory boyutu gibi server bilgilerini TSQL komutları ile alabilmemiz mümkün.
SQL Server DMV’leri arasında en sevdiğim DMV’lerden biride sys.dm_os_sys_infoDMV’sidir. Bu DMV ile Server’ın ne zaman start olduğu, SQL Server’ın en son ne zaman restart edildiği, CPU adeti ve fiziksel memory boyutu gibi server bilgilerini TSQL komutları ile alabilmemiz mümkün.
);background-position: 100% 50%;background-repeat: no-repeat no-repeat" href="http://www.turgaysahtiyan.com/post/SQL-Server-e28093-Her-Gun-1-DMV-Gun-18-e28093-dm_os_sys_info-ile-Database-Server-Bilgileri.aspx">Dünkü DMV yazımda sys.dm_os_sys_info DMV’si ile Server bilgilerini nasıl kontrol edip yorumlayabileceğimizi görmüştük. Bugünkü konumuz olan sys.dm_os_sys_memory ile de server’ın total physical memory değerini, kullanılabilir physical memory değerini, pagefile değerleri gibi memory ile alakalı bilgileri kontrol edebiliriz.
Sistemimizde gerçekleşen bir performans sıkıntısını anlık olarak kontrol ederken );background-position: 100% 50%;background-repeat: no-repeat no-repeat" href="http://www.turgaysahtiyan.com/post/SQL-Server-e28093-Her-Gun-1-DMV-Gun-9-sysdm_io_pending_io_requests.aspx">sys.dm_io_pending_io_requests DMV vasıtasıyla aktif olarak disk üzerinde bekleyen bir işlem olup olmadığını kontrol ettik ve olmadığını gördüğümüzü düşünelim. Peki bir sonraki adımımız ne olacak. Nasıl ki disk üzerinde ki anlık beklemeleri sorguluyorsak aynı şekilde CPU üzerinde de bir bekleme var mı diye kontrol etmeliyiz. İşte bugünkü yazımızda CPU üzerinde herhangi bir bekleme var mı, CPU yetersizliğinden dolayı performans sıkıntısı çekiyor muyum gibi sorularımıza sys.dm_os_schedulers DMV’si ile cevap arayacağız.
SQL Server execute edilen procedure, trigger ya da adhoc query’ler için oluşturduğu Query Plan’larını saklar ve daha sonraki kullanımlarda bu query plan’ları kullanarak işlemin daha hızlı sonuçlanmasını sağlar.
sys.dm_exec_cached_plans DMV’si ile bu saklanan Query Plan’larını sorgulayabilir, hangi obje için oluşturulduğunu, query plan’ın ne olduğunu, bu query plan’ın kaç defa kullanıldığını ve memory’de ne kadar yer kapladığını öğrenebiliriz.
SP ve Function’lar gibi bir çok yerde kullanılmakta olan bir tablom var ve ben bu tabloda kolon ekleme ya da silme gibi structure değişikliği yapmak istiyorum. Değişikliği yapmadan önce hangi objeler bu tablomu kullanıyor bilmeliyim ki sistemi nasıl etkileyeceğimi kestirebileyim.Ya da tanımladığım bir user-defined datatype’ım var. Bu datatype’ta değişiklik yapmak istiyorum ama hangi objeler bu datatype’ı kullanıyor öğrenmek istiyorum.
Bugünkü makalemde bu sorularımıza cevap bulmak için SQL Server’da Dependency sorgularının DMV’ler ile nasıl yapıldığına bakıyor olacağız.
SQL Server’da yazılan birçok uygulamada transaction blokları kullanılmaktadır. Transaction’lar begin trans komutu ile başlatılır ve commit tran ya da rollback trankomutuyla sonlandırılır. Commit tran ile sonlandırıldığında bloğun içinde yapılmış her şey onaylanır ve disk’e yazılır duruma gelir. Rollback tran komutuyla bitirilen transaction’lar içindeki yapılmış bütün değişiklikler ise geriye alınır. Bu şekilde transaction bloğu sonuna kadar hata almadan gelirse yapılan işlemlerin tamamı beraber onaylanır ya da geri alınır. Bu mantıkta bize datanın bütünlüğünü sağlamış olur.
Bugünkü yazımda sunucu üzerinde bulunan aktif olan transaction’ları nasıl sorgulayacağımızı göreceğiz. Bu transaction’ların ne zaman, kim tarafından, hangi makine üzerinden, hangi database üzerinde başlatıldığını, son uyguladığı script bilgisi gibi detay bilgileri sorgulayacağız.
Her Gün 1 DMV yazı dizimizde 24. Güne geldik. Bugüne kadar anlattığım DMV’lerin bir kısmı ile yaptığımız işlemleri windows server ile de yapabilmekteydik.Örneğin cluster node’larını yada cluster drive’larını DMV’ler ile nasıl sorgulayabileceğimize baktık ama bu bilgilere zaten windows server üzerinden de erişebiliyorduk.
Bu sorgulamaları DMV’ler ile yapmamızdaki ana amaç olabildiğince SQL Server üzerinden bu kontrolleri yaparak bir bütünlük sağlamak. Ayrıca bazen Windows Admin arkadaşlarla uğraşmaktansa kendi işimizi kendimiz yapabiliyor olmak daha kolay geliyor. 🙂
Bugün işleyeceğimiz DMV’de bu tarz bir DMV.Hepinizin bildiği gibi PerfMon yada diğer bazı tool’lar ile Performance Counter bilgileri toplanabiliyor. Biz isesys.dm_os_performance_counters DMV’si ile SQL Server ile alakalı performance counter’ları TSQL ile nasıl sorgulayabileceğimizi görüyor olacağız.
);background-position: 100% 50%;background-repeat: no-repeat no-repeat" href="http://www.turgaysahtiyan.com/post/SQL-Server-e28093-Her-Gun-1-DMV-Gun-10-sysdm_io_cluster_shared_drives.aspx">SQL Server – Her Gün 1 DMV - Gün 10 - sys.dm_io_cluster_shared_drives adlı yazımda Cluster bir environment’ta bulunan drive’ların neler olduklarına TSQL komutları ile nasıl bakabileceğimizi görmüştük. Bugün üzerinde duracağımızsys.dm_os_cluster_nodes DMV’si ile cluster bir environment’taki node’ların neler olduklarını TSQL komutu ile nasıl sorgulayacağımızı görüyor olacağız.
Query ve Stored Procedure’lerin kullanım istatistikleri ile alakalı daha önce 2 makale yayınlamıştım. Bu makalelerde Query ve Stored Procedure’lerin kullanımlarına bakmış, CPU,IO gibi kaynak tüketimlerini inceleyip problemli olanları analiz etmiştik.
Bugünkü yazımda ise bu kapsamdaki son DMV olan sys.dm_exec_trigger_stats iletrigger istatistiklerini inceleyip gene CPU,IO gibi kaynak tüketimleri açısından analizlerini yapacağız. Aynı zamanda gene bu DMV vasıtasıyla kullanılmayan trigger’ları raporlayacağız.
SQL Server’da blocking yani engelleme durumları en sık baş ağrıtan konulardan biridir. İyi tasarlanmamış yapılarda bir session diğerini bloklar ve buda performans olarak negatif bir etki yaratır. İşin özünde aynı kaynağın birden fazla session tarafından kullanılma isteği yatar. Örneğin bir tabloya a session’ı insert yaparken b session’ı select çekmek isterse b session’ın a session’ın işini bitirmesini beklemesi gerekmektedir. Gerçi “isolation level”da ne set edildiği önemli bir noktadır ama bugünkü yazımızda bu konuya girmeyerek isolation level’ın ReadCommitted olduğunu varsayacağız. İşte session’ların bu tarz birbirini engellemesi durumuna blocking denir. Bugünkü makalemizde hangi session’ın hangi kaynakları lock’ladığına ve hangi session’ın hangi session’ı blockladığı sorularına DMV’ler ile yanıt bulmaya çalışacağız.
Hepinizin bildiği gibi bir result set üzerinde satır satır hareket edebilmek için Cursor’lar kullanılmaktadır. Bugünkü yazımda bir dabatase üzerindeki açık olan cursor’ları, bu cursor’ları kimin ne zaman açtığını ve query’lerinin neler olduğunu nasıl sorgulayabileceğimize bakıyor olacağız.
sys.dm_os_wait_stats DMV yazımda SQL Server’ın network, CPU gibi hangi dış etkenlerde beklediğini nasıl belirleyebileceğimizi görmüştük. Bugünkü yazımda ise sys.dm_os_latch_stats DMV si ile SQL Server boş page bulma gibi SQL Server ilişkili beklemeleri nasıl sorgulayacağımızı görüyor olacağız.
Her Gün 1 DMV yazımda bugün son günümüz 🙂 Bugünkü yazımda yeni bir DMV anlatmaktansa geride kalan 29 gün boyunca işlediğimiz DMV’leri bir başlık altında toplamayı uygun gördüm. Bu şekilde tek bir post’tan bütün DMV’lere hızlıca erişebileceğiz.
Her gün 1 DMV yazı dizimi dün itibarıyla sonlandırdım. 30 günlük periyotta 39 tane DMV'yi incelem fırsatı bulmuşuz. Bir sonraki yazı dizimizde görüşürüz 🙂
Elinize sağlık Turgay bey. Tabi bunların makale olarak çözümparkta yayınlanması için bize gelmesini bekliyoruz 🙂 Erken gönderin kazanalım hep beraber 🙂
Rafet bey en kısa zamanda dokümanları toparlayıp göndereceğim.
Eline sağlık Hocam
Danışman - ITSTACK Bilgi Sistemleri
****************************************************************
Probleminiz Çözüldüğünde Sonucu Burada Paylaşırsanız.
Sizde Aynı Problemi Yaşayanlar İçin Yardım Etmiş Olursunuz.
Eğer sorununuz çözüldü ise lütfen "çözüldü" olarak işaretlerseniz diğer üyeler için çok büyük kolaylık sağlayacaktır.
*****************************************************************
Rafet bey en kısa zamanda dokümanları toparlayıp göndereceğim.
Merhaba Ulaşabileceiğimiz bri yer mevcutmu acaba *
teşekkürler..