Azure SQL'de Genişletilmiş Olaylar

Şunlar için geçerlidir:Azure SQL VeritabanıAzure SQL Yönetilen ÖrneğiFabric'te SQL Veritabanı

Genişletilmiş Olaylara giriş için bkz:

Azure SQL Veritabanı'ndaki Genişletilmiş Olaylar, Doku'daki SQL veritabanı ve Azure SQL Yönetilen Örneği için özellik kümesi, işlevsellik ve kullanım senaryoları, SQL Server'da sağlananlara benzer. Ana farklar şunlardır:

  • Azure SQL Veritabanı, Fabric üzerinde SQL veritabanı ve Azure SQL Yönetilen Örneği'nde event_file hedef her zaman diskteki dosyalar yerine Azure Depolama'daki blobları kullanır.
    • SQL Server'da hedef, event_file diskteki dosyaları veya Azure Depolama'daki blobları kullanabilir.
  • Azure SQL Veritabanı'te ve Fabric'teki SQL veritabanında olay oturumları her zaman veritabanı kapsamındadır. Bu, şu anlama gelir:
    • Bir veritabanındaki olay oturumu başka bir veritabanından olay toplayamaz.
    • Bir olayın oturuma dahil edilmesi için kullanıcı veritabanı bağlamında gerçekleşmesi gerekir.
  • Azure SQL Yönetilen Örneği'nde hem sunucu kapsamındaki hem de veritabanı kapsamındaki olay oturumları oluşturabilirsiniz. Çoğu senaryo için sunucu kapsamlı olay oturumları kullanmanızı öneririz.

Get started

Genişletilmiş Olaylar'ı hızlı bir şekilde kullanmaya başlamanıza yardımcı olacak iki izlenecek yol örneği vardır:

Genişletilmiş Olaylar, salt okunur replikaları izlemek için kullanılabilir. Daha fazla bilgi için Çoğaltmalardaki okuma sorguları bölümüne bakın.

En iyi yöntemler

Genişletilmiş Olayları güvenli, güvenilir ve veritabanı altyapısının sistem durumunu ve iş yükü performansını etkilemeden kullanmak için aşağıdaki en iyi yöntemleri benimseyin.

  • Eğer event_file hedefini kullanırsanız:
    • Oturuma eklenen olaylara bağlı olarak, hedef tarafından event_file oluşturulan dosyalar hassas veriler içerebilir. Gereksiz okuma erişimi vermekten kaçınmak için, devralınan erişim de dahil olmak üzere depolama hesabı ve kapsayıcıdaki RBAC rol atamalarını ve erişim denetimi listelerini (ACL) dikkatle gözden geçirin. En az ayrıcalık ilkesini izleyin.
    • Olay oturumlarını oluşturduğunuz veritabanı veya yönetilen örnekle aynı Azure bölgesinde bir depolama hesabı kullanın.
    • Depolama hesabının yedekliliğini veritabanının, elastik havuzun veya yönetilen örneğin yedekliliğiyle hizalayın. Yerel olarak yedekli kaynaklar için LRS, GRS veya RA-GRS kullanın. Alanlar arası yedekli kaynaklar için ZRS, GZRS veya RA-GZRS kullanın. Ayrıntılar için bkz . Azure Depolama yedekliliği .
    • Hot dışında hiçbir blob erişim katmanı kullanmayın.
    • Depolama hesabı için hiyerarşik ad alanını etkinleştirmeyin.
  • Her Veritabanı Altyapısı yeniden başlatmasının ardından (örneğin, bir yük devretme veya bakım olayından sonra) otomatik olarak başlayan sürekli çalışan bir olay oturumu oluşturmak istiyorsanız, CREATE EVENT SESSION veya ALTER EVENT SESSION deyimlerinize STARTUP_STATE = ON olay oturumu seçeneğini ekleyin.
  • Buna karşılık geçici sorun gidermede kullanılanlar gibi kısa süreli olay oturumları için kullanın STARTUP_STATE = OFF .
  • Azure SQL Veritabanı yerleşik olay oturumundan kilitlenme olaylarını okumayındl. Toplanan çok sayıda kilitlenme olayı varsa, bunları sys.fn_xe_file_target_read_file() işleviyle okumak veritabanında bellek yetersiz hatasına master neden olabilir. Bu, oturum açma işlemlerini etkileyebilir ve uygulama kesintisine neden olabilir. Kilitlenmeleri izlemenin önerilen yolları için bkz: Extended Events ile Azure SQL Veritabanı'nda kilitlenme grafiklerini toplama.

Olay oturumu hedefleri

Azure SQL Veritabanı, Fabric'teki SQL Veritabanı, Azure SQL Yönetilen Örneği ve SQL Server'da desteklenen Genişletilmiş Olaylar hedefleri hakkında daha fazla bilgi için bkz. Genişletilmiş Olaylar için Hedefler.

Transact-SQL farkları

SQL Server'da ve Azure SQL Yönetilen Örneği'nde CREATE EVENT SESSION, ALTER EVENT SESSION ve DROP EVENT SESSION deyimlerini yürüttüğünüzde ON SERVER yan tümcesini kullanırsınız. Azure SQL Veritabanı'nda bunun yerine ON DATABASE yan tümcesini kullanırsınız, çünkü Azure SQL Veritabanı'ndaki olay oturumları veritabanı kapsamındadır.

Genişletilmiş Olaylar kataloğu görünümleri

Genişletilmiş Olaylar birkaç katalog görünümü sağlar. Katalog görünümleri size olay oturumu meta verileri veya tanımı hakkında bilgi gösterir. Bu görünümler etkin olay oturumlarının örnekleri hakkında bilgi döndürmez.

Her platform için katalog görünümlerinin listesi için bkz. Genişletilmiş Olaylar Kataloğu Görünümleri.

Extended Events dinamik yönetim görünümleri

Genişletilmiş Olaylar birkaç dinamik yönetim görünümü (DMV) sağlar. DMV'ler, başlatılan olay oturumları hakkında bilgi döndürür.

Her platform için DMV'lerin listesi için bkz. Genişletilmiş Olaylar Dinamik Yönetim Görünümleri.

Yaygın kullanılan DMV'ler

Azure SQL Veritabanı, Azure SQL Yönetilen Örneği ve SQL Server için ortak olan ek Genişletilmiş Olaylar DMV'leri vardır:

Kullanılabilir olaylar, eylemler ve hedefler

Şu sorguyu kullanarak kullanılabilir olayları, eylemleri ve hedefleri alabilirsiniz:

SELECT o.object_type,
       p.name AS package_name,
       o.name AS db_object_name,
       o.description AS db_obj_description
FROM sys.dm_xe_objects AS o
INNER JOIN sys.dm_xe_packages AS p
ON p.guid = o.package_guid
WHERE o.object_type IN ('action','event','target')
ORDER BY o.object_type,
         p.name,
         o.name;

Permissions

Platforma göre ayrıntılı izinler için izinlere bakın.

Depolama kapsayıcısı yetkilendirme ve denetimi

Azure Depolama bloblarıyla event_file hedefine kullandığınızda, olay oturumunu çalıştıran Veritabanı Motoru'nun blob kapsayıcısına belirli bir erişime sahip olması gerekir. Bu erişimi aşağıdaki yollardan biriyle vekleyebilirsiniz:

  • Depolama Blobu Veri Katkıda Bulunanı RBAC rolünü kapsayıcıdaki Azure SQL mantıksal sunucusunun veya Azure SQL yönetilen örneğinin yönetilen kimliğine atayın ve Veritabanı Altyapısı'na kimlik doğrulaması için yönetilen kimliği kullanmasını bildirmek üzere bir kimlik bilgisi oluşturun.

    Storage Blob Data Contributor RBAC rolünü atamaya alternatif olarak, aşağıdaki RBAC eylemlerini atayabilirsiniz:

    Namespace Action
    Microsoft.Storage/storageAccounts/blobServices/containers/ read
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/ delete
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/ read
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/ write

  • Kapsayıcı için bir SAS belirteci oluşturun ve belirteci bir kimlik bilgisi içinde depolayın.

    Azure SQL Veritabanı'de veritabanı kapsamlı bir kimlik bilgisi kullanmanız gerekir. Azure SQL Yönetilen Örneği ve SQL Server'da sunucu kapsamındaki bir kimlik bilgisi kullanın.

    Azure Depolama kapsayıcınız için oluşturduğunuz SAS belirteci aşağıdaki gereksinimleri karşılamalıdır:

    • rwdl (Read, Write, Delete, List) izinlerine sahip olun.
    • Olay oturumunun ömrünü kapsayan başlangıç zamanına ve süre sonu süresine sahip olun.
    • IP adresi kısıtlaması yoktur.

Ağ güvenlik perimetresi (önizleme)

Ağ güvenliği çevresi (önizleme), Azure SQL Veritabanı ve diğer Azure platform as a service (PaaS) kaynakları etrafında ağ erişim sınırı oluşturur. Bir mantıksal sunucuyu ağ güvenlik çevresi (NSP) ile ilişkilendirdiğinizde, Extended Events'in Azure Depolama'a yaptığı çıkış bağlantıları çevrenin erişim kurallarına tabidir.

Note

Ağ güvenlik çevresi yalnızca Azure SQL Veritabanı için mevcuttur. Bu bölüm, Azure SQL Yönetilen Örneği veya Fabric'teki SQL veritabanı için geçerli değildir. Önizleme özelliği olarak, ağ güvenliği çevresi Microsoft Azure Önizlemeleri için Ek Kullanım Şartları'na tabidir.

Genişletilmiş Olaylar ağ erişimini nasıl kullanır

Extended Events, Database Engine'den Azure Depolama'a iki durumda çıkış bağlantıları sağlar:

  • Etkinlik verisi yazmak. Bir etkinlik oturumunu bir event_file bloba işaret eden bir hedefle başlattığınızda, Database Engine oturum başlamadan önce çıkış erişimini kontrol eder ve her seferinde olay tamponlarını bloba yönlendirir.
  • Etkinlik verilerini okumak. Blob URL'si ile sys.fn_xe_file_target_read_file veya sys.fn_MSxe_read_event_stream çağırdığınızda, fonksiyon başlatıldığında Database Engine giden erişimi kontrol eder. Olay görüntüleyicisinde yakalanan olay verilerini açtığınızda SSMS, sys.fn_MSxe_read_event_stream çağırır.

T-SQL üzerinden olay oturumlarını yönetmek için kullanılan gelen TDS bağlantıları, Genişletilmiş Olaylara özgü herhangi bir NSP yapılandırmasına ihtiyaç duymaz. CREATE EVENT SESSION, ALTER EVENT SESSION ve DROP EVENT SESSION deyimleri ile okuma işlevlerinin tümü normal bir istemci bağlantısı üzerinden çalışır; bu nedenle, veritabanına yapılan diğer tüm istemci bağlantılarıyla aynı gelen erişim kurallarına tabidir.

Desteklenen yapılandırmalar

Davranış, çevrenin erişim moduna , depolama hesabının mantıksal sunucu ile aynı çevrede olup olmadığına ve iki farklı çevrenin birbirine bağlı olup olmadığına bağlıdır.

SQL mantıksal sunucu NSP Depolama hesabı NSP Behavior
NSP yok NSP yok Sınır bağlantıyı denetlemez. Genişletilmiş Olaylar, yapılandırdığınız kimlik bilgisi ve depolama hesabı güvenlik duvarı kuralları aracılığıyla depolama hesabına bağlanır. Daha fazla bilgi için bkz. Depolama konteyneri yetkilendirmesi ve kontrolü.
NSP yok Bir NSP'de Çevre, mantıksal sunucudan giden erişimi değerlendirmez. Bağlantının başarılı olup olmayacağı, depolama hesabının kendi çevresindeki gelen kurallara bağlıdır.
Bir NSP'de (Zorunlu) Aynı NSP Erişim her zaman izinlidir. Bir çıkış kuralına ihtiyacınız yok.
Bir NSP içinde (Zorunlu) Farklı ama bağlantılı NSP Erişime sınırlar arası kurallar aracılığıyla izin verilir. Giden FQDN kuralına ihtiyacınız yok.
Bir NSP’de (Zorunlu) Farklı bağlantısız NSP ya da hiç NSP yok Yönetilen bir kimlik kullandığınızda veya çevre profilinde giden FQDN kuralı depolama hesabının ana adıyla eşleştiğinde erişim izinlidir. Bir SAS token kullanıyorsanız ve kural eşleşmiyorsa, olay oturumu 25602 hatasıyla başlamaz ve okuma fonksiyonları 25759 hatasıyla başarısız olabilir.
Bir NSP'de (Geçiş) Any Çevre kuralları değerlendirir ve kaydeder ama trafiği engellemez.

Depolama hesabına giden erişimi yapılandırın

Bir veritabanını Genişletilmiş Olaylar kullanacak şekilde yapılandırdığınızda, yönetilen kimlik ile SAS token kimlik doğrulaması arasında seçim yapabilirsiniz. Seçtiğiniz kimlik doğrulama mekanizması, giden erişim kuralına ihtiyacınız olup olmadığını belirler.

  1. Çevre ilişkilendirmesini doğrulayın. Azure portalında, Ağ Güvenliği Çevresi ara, çevrenizi seçin ve ardından Ayarlar menüsünden Associated Resources seçeneğini seçerek sunucunuzun listede olduğunu doğrulayın. Daha fazla bilgi için bkz. Ağ güvenlik çevresi.
  2. Kimlik doğrulama mekanizmanızı seçin. Yönetilen kimlik doğrulaması kullanın. Yönetilen kimlik belirteci, perimetrenin ihtiyaç duyduğu claim’leri içerdiğinden bir giden kural eklemeniz gerekmez ve bir sonraki adımı atlayabilirsiniz.
  3. Bir çıkış erişim kuralı ekleyin (sadece SAS tokenı). SAS belirteci kullanıyorsanız ve güvenlik çevresi uygulama modundaysa, güvenlik çevresi profiline bir giden erişim kuralı ekleyin. Tam nitelikli alan adları (FQDN) kural türü ve depolama hesabınızın ana adını değer olarak kullanın, örneğin myxedata.blob.core.windows.net.

Bu örnekte, *.blob.core.windows.net her Azure Depolama hesabına izin verebilirsiniz, ancak bu ayar sahip olmadığınız depolama hesaplarına giden bağlantılara izin veriyor. Mümkün olduğunca özel ana bilgisayar adını kullanın.

Hangi giden kurallara ihtiyacınız olduğunu doğrulayana kadar perimetreyi geçiş modunda tutun. Geçiş modunda, çevre kural değerlendirmelerini erişimi engellemeden kaydeder, böylece eksik kurallar hatalara yol açmadan önce bulabilirsiniz. Kurallar yürürlüğe girdikten sonra zorunlu moda geçin.

Sınırlamalar ve davranış farklılıkları

  • Database Engine, bir oturum başladığında ve her buffer flush'ta çıkış erişimini kontrol eder. Oturum çalışırken giden kuralı kaldırırsanız, oturum durmaz. Bunun yerine bireysel buffer yazımları başarısız olmaya başlar.
  • Yönetilen kimlikler ve SAS tokenları bir sınır altında eşdeğer değildir. Yönetilen kimlik belirteci perimetre taleplerini içerdiğinden giden bir kurala gerek duymaz. Bir SAS tokenı bu talepleri taşımaz, bu yüzden zorunlu modda eşleşen bir outbound kuralı gerekir.
  • Engellenmiş bir okuma fonksiyonu hata yaratmayabilir. Bir çevre, sys.fn_MSxe_read_event_stream veya sys.fn_xe_file_target_read_file öğesini engellediğinde, işlev 25759 ya da 25717 hatasını oluşturabilir veya hata olmadan boş bir sonuç kümesi döndürebilir. Veri bekliyorsanız ancak hiç satır dönmüyor ve hata da almıyorsanız, giden kurallarınızı kontrol edin.

Bir güvenlik çevresi erişimi engellediğinde oluşan hatalar

25602 hatası, event_file hedefinin başlatılamadığı anlamına gelir; bunun nedeni, güvenlik çevresinin depolama hesabına giden bağlantıyı engellemesidir:

The target, "<target_name>", encountered a configuration error during initialization. Object cannot be added to the event session.
For more information, see https://go.microsoft.com/fwlink/?linkid=2336061.

25759 hatası, bir çevrenin okuma fonksiyonunu engellediği anlamına gelir:

Network Security Perimeter (NSP) blocked outbound access to the storage URL '<url>'.
The NSP configuration does not allow reading from the specified location.

25717 hatası, okuma fonksiyonu okunurken erişimin iptal edildiğini gösteriyor. Database Engine, blob verilerini tüm dosyaları indirmek yerine parçalar halinde okuduğundan, bu hata bir sonuç kümesinin ortasında meydana gelebilir:

The operating system returned error <error details> while reading from the file '<url>'.

Bu hatalardan herhangi birini çözmek için, yönetilen kimlik doğrulamasına geçin, depolama hesabının ana adıyla eşleşen bir çıkış FQDN kuralı ekleyin veya depolama hesabını mantıksal sunucu ile aynı sınıra taşıyın.

Hedef başlatma ve buffer yazma hataları hakkında daha fazla tanı detayı için Genişletilmiş Olaylar motoru günlüğünü sorgulayın:

SELECT CONVERT(xml, record) AS record_xml
FROM sys.dm_os_ring_buffers
WHERE ring_buffer_type = 'RING_BUFFER_XE_LOG';

Çevre ilişkilendirme değişiklikleri ve erişim modu değişiklikleri, mantıksal sunucu için Azure Etkinlik Günlüğü'nde görünür. Gelen ve giden kural değerlendirmeleri, ağ güvenliği çevresi tanılama günlüklerinde yer alır.

Kaynak idaresi

Azure SQL Veritabanı' de, genişletilmiş olay oturumları tarafından bellek tüketimi, kaynak çekişmelerini en aza indirmek için Veritabanı Altyapısı tarafından dinamik olarak denetlenmektedir.

Olay oturumları için kullanılabilir bellek sınırı vardır:

  • Tek bir veritabanında toplam oturum belleği 128 MB ile sınırlıdır.
  • Elastik havuzda tek tek veritabanları tek veritabanı sınırlarıyla sınırlıdır ve toplamda 512 MB'ı aşamaz.

Bellek sınırına başvuran bir hata iletisi alırsanız, gerçekleştirebileceğiniz düzeltici eylemler şunlardır:

  • Daha az sayıda eşzamanlı olay oturumu çalıştırın.
  • Olay oturumları için CREATE ve ALTER deyimlerini kullanarak, oturum için MAX_MEMORY yan tümcesinde belirttiğiniz bellek miktarını azaltın.

Note

Genişletilmiş Olaylar'da MAX_MEMORY yan tümcesi iki bağlamda ortaya çıkar: oturum oluşturulurken veya değiştirilirken (oturum düzeyinde) ve ring_buffer hedefi kullanıldığında (hedef düzeyinde). Yukarıdaki sınırlar oturum düzeyi belleği için geçerlidir.

Azure SQL Veritabanı'da başlatılan olay oturumlarının sayısıyla ilgili bir sınır vardır:

  • Tek bir veritabanında sınır 100'dür.
  • Elastik havuzlarda sınır, havuz başına veritabanı kapsamındaki 100 oturumdur.

Yoğun elastik havuzlarda, yeni bir genişletilmiş olay oturumu başlatma işlemi, başlatılan toplam oturum sayısı 100'ün altında olsa bile bellek kısıtlamaları nedeniyle başarısız olabilir.

Bir olay oturumu tarafından tüketilen toplam belleği bulmak için, olay oturumunun başlatıldığı veritabanına bağlıyken aşağıdaki sorguyu yürütebilirsiniz:

SELECT name AS session_name,
       total_buffer_size + total_target_memory AS total_session_memory
FROM sys.dm_xe_database_sessions;

Elastik havuzun toplam olay oturumu belleğini bulmak için bu sorgunun havuzdaki her veritabanında yürütülmesi gerekir.

İlgili içerik

  • Last updated on