Bildiğiniz gibi Extended events ilk olarak SQL Server 2008 ile hayatımıza girdi. İlk duyurulduğunda event sayısının az olması ve Grafik Arayüzünün (GUI) olmaması çok ciddi bir problemdi. Karşısında ise kapı gibi Profiler tool u bulumaktaydı. Profiler uzun yıllardır profesyoneller tarafından kabul görmüş, DBA lerin eli ayağı diyebileceğimiz bir tooldu. Gerçi bu durum SQL Server 2005 versiyonuyla sınırlı sayıda gelen DMV ‘lerle birlikte biraz sarsılmış oldu. DMV ler SQL Serverin arkada topladığını bilgileri göstermesiydi. Çok daha az maliyetli zaten toplanmış kumulatif verilere erişmek bizler için bulunmaz bir nimetti.
Şekil 1 Extended event genel görünümü
2008 R2 versiyonuyla EE’e GUI eklendi. Artık en azından Profilere rakip olabilecek pozisyondaydı. Akıllara hemen Profiler ya da Trace gibi toolar varken Extended events e neden gerek duyuldu sorusu geliyor. Tamamen internal baskılar diyebilirim. Bob Ward ve SQL Server escalation engineerlar sorunların çözülmesi için böyle bir tool a ihtiyaçları olduğunu şiddetle dile getirdiler. En basit manada Profilerin ya da Trace in getirdiği muazzam yük VLDB ortamlarda yarardan çok zarar getirmekteydi. Bu durumda da mühendisler sorunu teşhis etmekte ve çözmekte sorun yaşıyorlardı.
SQL Server 2008 R2 versiyonuyla birlikte Extended eventsler kolaylıkla hayatımıza girdiler diyebilirim. Bu toolun Profilerin yerini almasındaki en önemli nedeni lightweight olması dolayısıyla sisteme çok az extra maliyet getirmesi.
Extended eventsin bu başarısından sonra Profiler toolunun gelecek versiyonlarda desteklenmeyeceği, geliştirilmeyeceği hatta kaldırılması planlanıyordu. Şu an zaten deprecated durumda. Backward compability göz önüne alınarak kaldırılacaktı. Ancak işler o şekilde yürümedi şu an SQL Server 2017 var ve bu tool default olarak hala desteklenmekte. (Bu yazıyı 2018’ten yazıyorum ve marty 2015 de o baloya gelmedi)
Şekil 2 BTTF
Hatta güvenlik açıkları fixleniyor. J Bir nevi geliştirilmesi sadece güvenlik açısından devam etmekte, ancak destek ve yeni geliştirmeler yapılmamakta.
Extended eventin her yeni major ve minör versiyonunda yeni eventler geliyor. Gelişimi çok hızlı bir şekilde ilerliyor. Kendi veri tabanı versiyonunuzdaki event sayısını aşağıdaki sorguyla bulabilirsiniz.
Konuyu toparlayalım ve daha iyi anlayabilmek için iki ürünü karşılaştıralım.
Profiler gelişimi durmuş, Extended event ise geliştirilmesi son hızla devam eden bir tool. Profilerin’ın yeni nesil versiyonu.
Extended Event Profilerdan çok daha fazla event içermekle birlikte daha fazla data tipi de barındırmakta.
EE profiler’a nazaran sisteme çok daha az bir yük getirmekte(lightweight).
Çok daha esnek.
Çıktısını OS metriklerle(perfmon) correlate ederek sorunun nereden kaynaklandığı anlayabiliriz. Sorun OS kaynaklı mı yoksa SQL kaynaklı mı gibi sorulara kolaylıkla cevap bulabiliriz.
Bu da doğal olarak veri tabanı yöneticilerinin işini kolaylaştırmaktadır. Hızlı bir şekilde konfigüre edilebilir. Session bazlı bile olsa sürekli bir traceflag açma durumunu büyük ölçüde ortadan kaldırıyor.
Şekil 3 System Health EE
Eğer 2008 R2 den daha yeni bir engine de çalışıyorsanız default olarak System health extended eventi gelmektedir. System health paketinde deadlocklar default olarak yakalanır ve XML output olusturulur ve kaydedilir. Yani gideyim, traceflag açayım, deadlock trace açayım dertlerimiz kalmadı artık.
Şekil 4 EE even file output
Mimari
EE ler bir paket olarak sql server altında konumlanmaktadır. SQL Server altında birden fazla EE yaratabilirsiniz Bire çok ilişkisi. (One to many) Bir paket birden fazla event, target vb. içerebilir. Yukardaki grafik bu durumu açıklıyor.
Package
Paketler bir isme ve GUID numarasına sahip olurlar. Onları bir konteyner(container) gibi düşünebilirsiniz. Altındaki objeleri tutarlar. Modüllerin yüklenmesi sırasında EE e register olurlar. Dolayısıyla, ilerde anlatacağımız, bir değişiklik yapacağımız zaman neden paketi stop edip değişikliği yapıp tekrar aktif hale getirdiğimizi anlatacağım.
Event
Mevzunun büyük kısmı burada dönüyor. Geliştirilen uygulamada bir kod blogu mu yakalamak istiyoruz? belirli bir süreden uzun süren sorguları teşhis mi etmek istiyoruz. Memory üzerinde split-page leri mi yakalamak istiyoruz gibisinden en basitinden en karmaşığına kadar bütün operasyonları burada yapıyoruz. Tüm eventler bir versiyon numarasına sahip olur. Bu bilgiyi içerlerinde saklarlar.
Target
Bunu tüketici gibi düşünebilirsiniz. Senkronize ya da asenkronize çalışabilir. Asenkron olarak çalışmaya özen gösterelim ki performans kaybımız en az olsun. Her event First In First Out şeklinde kaydedilecek ya da gösterilecektir.
Action
Senkron bir şekilde çalışır. Bir tetikleyicidir. Belirtiğiniz kriterlere uyan bir durumda istediğiniz işlemi yapan objelerdir. Bir uygulamayı tetikleyebilir. Bir sorgu çalıştırabilir. Bir mail atabilir.
Type
Datayı kategorize edebilmemiz için toplanan datanın tipi, uzunluğu ifade şeklini belirtir. Topladığımız şeyin ne olduğunu bize bildirir.int, string, binary vs.
Predicate
Booelan kriterleridir. Logical işlemler için kullanırız. Local ve global kısıtlamalar yapabilirsiniz. Dakikada her n tane event fırlatınca gibi…
Çok fazla fırlatılan eventlerin arasından sizin ihtiyacınız olan eventi yakalamak için burada kısıtlama yapmak hayati öneme sahip.
Map
Versiyonlar arası geçişte bize extra bir iş yapmamamız için bu obje kullanılır. Internaldir. Versiyon numaralarıyla bir sonraki versiyondaki objeye map edilmiş olacaktır.
Message
Genellikle internal olarak kullanılan preformatted text (Atıyorum “Merhaba %.” outputu: Merhaba Dünya. Gibi) içeriklerdir.
Senkronize çalışmaktan mümkün mertebe kaçınalım. Async çalışmak candır tabi özel bir durumunuz yoksa. Bu konuyu ilerde daha detaylı inceleyeceğiz.
SSMS UI- Kullanıcı Ara yüzü
SQL Server Management Studio kullanarak Extended event konfigürasyonu yapmanızı öneririm. Tabii kki arayüz olmadan TSQL komutlarıyla da Extended eventleri kullanabilirsiniz. Genelde bu seçeneği biz extended event paketini sunucular arasında taşırken kullanıyoruz. Ya da eski bir paket üzerinde ufak bir revizyon yapıp yeni versiyonunu yaratmak için kullanıyoruz. Çok güçlü bir arayüzü olduğundan bahsettim. Ekran görüntüleriyle hızlı bir bakış atalım. Daha önce bahsettiğim gibi Extended event paketleri server levelde kaydedilmektedir.
Azure üzerinde SQL Server kullanıyorsanız arayüzü kullanarak herhangi bir extra efor harcamadan extenden event paketlerini kullanmaya devam edebilirsiniz. On premise SQL Server ile Azure SQL Server arasında arka tarafa dönen tek fark “ON SERVER” yerine “ON DATABASE” tanımlamasıdır. Ben ekran görüntülerini hazırlarken kendi laptopumu yani on-prem bir SQL Server kullandım.
SQL Server üzerinde varsayılan olarak gelen QuickSession le başlayan templatelerimiz vardır. İlerde onları da göstereceğim. Şu an o paketleri görmemimizin sebebi Extended event profilerdan o paketleri henüz register etmememizden kaynaklanmaktadır.
Bu daha önceden tanımlanmış paketler dışında AlwaysOn_health ve system_health adında paketleri göreceksiniz. System_health de çok kıymetli bilgiler var login failurelar deadlocklar vs. Ancak bu bilgilerin bir historysi yoktur. Açıp bakmanız lazım yani.
Telemetry_xevents paketi ise siz kurulum yaparken ürünün geliştirilmesi adına bilgilerimi paylaşmak istiyorum şeklide izin verdiyseniz bu pakette yaratılmış olarak geldiğini göreceksiniz. SSMS 17.3 versiyonuyla birlikte gelen bir özelliktir bu.
İlk extended eventimizi yaratalım.
Sessions tabına sağ tıklayıp New session Wizard diyoruz. Daha fazla deneyim kazandığınızda bir sihirbaza ihtiyaç duymadan daha hızlı extended event paketi yaratabilirsiniz.
Bir isim veriyoruz
Query Batch tracking şablonunu seçiyoruz. Profilerdan aşiyanız zaten bu şablonlara.
Toplayacağımız eventler “selected events” panelinde görünmektedir.
Şablondaki tanımlı alanlar seçili geldi. İhtiyacımız olan alanları seçerek devam edebiliriz. Extra bir alan seçmiyorum.
Bir kısıtlama koymak istersek aşağıdaki paneli kullanabiliriz. Bir kısıtlama koymuyorum.
Şu an ring buffer üzerinde yani memory üzerinde tutacağız toplayacağımız datayı. Datayı topladığımız ekranı kapattığımızda bu datalar kaybolacaktır.
Özet kısmı
Bu iki checkboxı işaretleyerek extended event paketini çalıştırıp ekranda görmeye başlayacağız.
Extended event paketi çalıştı ve ektanımıza live data sekmesi geldi.
Benim laptopumda çalışan bir uygulama olmadığı için ekanım boş. Yük oluşturup sorguları yakalayabiliyor muyuz görelim. Yük oluşturma aracımızı çalıştırdık. 1 adet thread basit bir Adventureworks sorgusu atalım. Hemen durduralım bakalım yakalamış mıyız?
4 select sorgusu atmış. Çok hızlı start stop yaparım: D Bakalım exteded event paketimiz bunu yakalamış mı? woow çok havalı. Sorgular önümüzde. Ekstra başka bir ekrana gitmedik. Herşey SSMS üzerinde.
Bu şablonda error_reported eventi varmış. Bu event şu an bizim için gereksiz bir event. Biz sadece batch completed eventini yakalamak istiyoruz. Extended event toolbarı sizde yukarıda çıkacaktır. Ayriyetten bir ayarlama yapmadıysanız. Ben aşağıda kullanıyorum. Oradan filter butonuna basıyoruz.
Bu ekranda name alanınıa kısıtlama giriyor ve entera basıyoruz.
Görmek istemediğimiz alanları kafa karışıklığına neden olmadan ortadan kaldırdık.
Eğer bir where kısıtlamasıyla kısıtılamak istemeyip gruplamak istersek bu sefer önce extended event paketini durdurmamız lazım. Bunun nedeni grouping işlemi yapmak istememiz. Daha sonra grouping butonuna tıklıyoruz. Gruplamak istediğimiz alanı ekleyip ok tuşuna basıyoruz.
Ekran görüntüsü aşağıdaki gibi bir hal aldı. Çok daha yorumlanabilir bir hal aldı ekranımız.
Umarım faydalı bir makale olmuştur, bir sonraki makalemde görüşmek üzere.