Acara yang Diperluas di Azure SQL

Berlaku untuk:Azure SQL DatabaseAzure SQL Managed InstanceSQL database di Fabric

Untuk pengantar Extended Events, lihat:

Rangkaian fitur, fungsionalitas, dan skenario penggunaan untuk Extended Events di Azure SQL Database, database SQL di Fabric, dan Azure SQL Managed Instance mirip dengan apa yang tersedia di SQL Server. Perbedaan utama adalah:

  • Di Azure SQL Database, database SQL di Fabric, dan Azure SQL Managed Instance, event_file target selalu menggunakan blob di Azure Storage, bukan file pada disk.
    • Di SQL Server, event_file target dapat menggunakan file pada disk atau blob di Azure Storage.
  • Pada Azure SQL Database dan Database SQL di Fabric, sesi kejadian selalu dicakup pada tingkat database. Ini berarti bahwa:
    • Sesi peristiwa dalam satu database tidak dapat mengumpulkan peristiwa dari database lain.
    • Peristiwa harus terjadi dalam konteks database pengguna untuk disertakan dalam sesi.
  • Di Azure SQL Managed Instance, Anda dapat membuat sesi peristiwa dengan cakupan server maupun dengan cakupan database. Kami merekomendasikan penggunaan sesi kejadian tingkat server untuk sebagian besar skenario.

Get started

Ada dua contoh panduan untuk membantu Anda memulai Extended Events dengan cepat.

  • Buat sesi acara dengan target event_file di Azure Storage. Contoh ini menunjukkan kepada Anda cara mengambil data peristiwa dalam file (blob) di Azure Storage menggunakan event_file target, dan menyertakan panduan pemecahan masalah untuk kesalahan umum. Gunakan ini jika Anda perlu mempertahankan data peristiwa yang diambil, atau jika Anda ingin menggunakan penampil peristiwa di SQL Server Management Studio (SSMS) untuk menganalisis data yang diambil.
  • Buat sesi event dengan target ring_buffer yang berada di memori. Contoh ini menunjukkan kepada Anda cara mengambil peristiwa terbaru dari sesi peristiwa dalam memori menggunakan ring_buffer target. Gunakan ini sebagai cara cepat untuk melihat peristiwa terbaru selama investigasi ad hoc atau pemecahan masalah, tanpa harus menyimpan data peristiwa yang diambil.

Extended Events dapat digunakan untuk memantau replika baca-saja. Untuk informasi selengkapnya, lihat Membaca kueri pada replika.

Praktik terbaik

Adopsi praktik terbaik berikut untuk menggunakan Extended Events dengan aman, andal, dan tanpa memengaruhi kesehatan mesin database dan performa beban kerja.

  • Jika Anda menggunakan target event_file:
    • Bergantung pada peristiwa yang ditambahkan ke sesi, file yang dihasilkan oleh event_file target mungkin berisi data sensitif. Tinjau penetapan peran RBAC dengan cermat dan daftar kontrol akses (ACL) pada akun penyimpanan dan kontainer, termasuk akses yang diwariskan, untuk menghindari pemberian akses baca yang tidak perlu. Ikuti prinsip hak istimewa paling sedikit.
    • Gunakan akun penyimpanan di wilayah Azure yang sama dengan database atau instans terkelola tempat Anda membuat sesi peristiwa.
    • Sejajarkan redundansi akun penyimpanan dengan redundansi database, kumpulan elastis, atau instans terkelola. Untuk sumber daya yang berlebihan secara lokal, gunakan LRS, GRS, atau RA-GRS. Untuk sumber daya zona redundan , gunakan ZRS, GZRS, atau RA-GZRS. Lihat Redundansi Azure Storage untuk detailnya.
    • Jangan gunakan tingkat akses blob apa pun selain Hot.
    • Jangan aktifkan namespace hierarkis untuk akun penyimpanan.
  • Jika Anda ingin membuat sesi peristiwa yang berjalan terus-menerus dan dimulai otomatis setelah setiap kali Database Engine dimulai ulang (misalnya, setelah failover atau kejadian pemeliharaan), sertakan opsi sesi peristiwa STARTUP_STATE = ON dalam pernyataan CREATE EVENT SESSION atau ALTER EVENT SESSION Anda.
  • Sebaliknya, gunakan STARTUP_STATE = OFF untuk sesi peristiwa jangka pendek seperti yang digunakan dalam pemecahan masalah ad hoc.
  • Di Azure SQL Database, jangan membaca peristiwa kebuntuan dari sesi peristiwa bawaan dl . Jika ada sejumlah besar kejadian deadlock yang dikumpulkan, membacanya dengan fungsi sys.fn_xe_file_target_read_file() dapat menyebabkan kesalahan kehabisan memori dalam database master. Ini dapat memengaruhi pemrosesan login dan mengakibatkan pemadaman aplikasi. Untuk cara yang direkomendasikan untuk memantau deadlock, lihat Mengumpulkan grafik deadlock di Azure SQL Database dengan Extended Events.

Target sesi acara

Untuk informasi selengkapnya tentang target Extended Events yang didukung di Azure SQL Database, database SQL di Fabric, Azure SQL Managed Instance, dan SQL Server, lihat Target untuk Kejadian yang Diperluas.

perbedaan Transact-SQL

Saat Anda menjalankan pernyataan CREATE EVENT SESSION, ALTER EVENT SESSION, dan DROP EVENT SESSION di SQL Server dan di Azure SQL Managed Instance, Anda menggunakan klausul .ON SERVER Di Azure SQL Database, Anda menggunakan klausul ON DATABASE sebagai gantinya, karena sesi peristiwa di Azure SQL Database dicakup pada tingkat database.

Tampilan katalog Acara yang Diperluas

Extended Events menyediakan beberapa tampilan katalog. Tampilan katalog memberi tahu Anda tentang metadata atau definisi sesi acara. Tampilan ini tidak mengembalikan informasi tentang instans sesi peristiwa aktif.

Untuk daftar tampilan katalog untuk setiap platform, lihat Tampilan Katalog Peristiwa Yang Diperluas.

Tampilan manajemen dinamis Extended Events

Extended Events menyediakan beberapa tampilan manajemen dinamis (DMV). DMV mengembalikan informasi tentang sesi acara yang dimulai.

Untuk daftar Tampilan Manajemen Dinamis (DMV) untuk setiap platform, lihat Tampilan Manajemen Dinamis Peristiwa yang Diperluas.

DMV yang umum

Ada DMV Extended Events tambahan yang umum untuk Azure SQL Database, Azure SQL Managed Instance, dan SQL Server:

Peristiwa, tindakan, dan target yang tersedia

Anda bisa mendapatkan peristiwa, tindakan, dan target yang tersedia menggunakan kueri ini:

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

Lihat izin untuk izin terperinci menurut platform.

Otorisasi dan kontrol kontainer penyimpanan

Saat Anda menggunakan event_file target dengan blob Azure Storage, Mesin Database yang menjalankan sesi peristiwa harus memiliki akses khusus ke kontainer blob. Anda dapat memberikan akses ini dengan salah satu cara berikut:

  • Tetapkan peran RBAC Storage Blob Data Contributor ke identitas terkelola milik server logis Azure SQL atau instans terkelola Azure SQL pada kontainer tersebut, dan buat kredensial untuk mengarahkan Mesin Database agar menggunakan identitas terkelola untuk autentikasi.

    Sebagai alternatif untuk memberikan peran RBAC Storage Blob Data Contributor, Anda dapat menetapkan tindakan RBAC berikut:

    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

  • Buat token SAS untuk kontainer, dan simpan token dalam kredensial.

    Dalam Azure SQL Database, Anda harus menggunakan kredensial yang dicakup database. Di Azure SQL Managed Instance dan SQL Server, gunakan kredensial cakupan server.

    Token SAS yang Anda buat untuk kontainer Azure Storage Anda harus memenuhi persyaratan berikut:

    • rwdl memiliki izin (Read, Write, Delete, List).
    • Tetapkan waktu mulai dan waktu berakhir yang mencakup seluruh masa berlaku sesi acara.
    • Tidak memiliki batasan alamat IP.

Perimeter keamanan jaringan (pratinjau)

Perimeter keamanan jaringan (pratinjau) menempatkan batas akses jaringan di sekitar Azure SQL Database dan sumber daya platform Azure sebagai layanan (PaaS) lainnya. Ketika Anda mengaitkan server logis dengan network security perimeter (NSP), koneksi keluar yang dibuat Extended Events ke Azure Storage tunduk pada aturan akses perimeter.

Note

Perimeter keamanan jaringan hanya tersedia untuk Azure SQL Database. Bagian ini tidak berlaku untuk Azure SQL Managed Instance atau database SQL di Fabric. Sebagai fitur pratinjau, perimeter keamanan jaringan tunduk pada Syarat Penggunaan Tambahan untuk Pratinjau Microsoft Azure.

Bagaimana Extended Events menggunakan akses jaringan

Extended Events melakukan koneksi keluar dari Database Engine ke Azure Storage dalam dua kasus:

  • Menulis data peristiwa. Saat Anda memulai sesi event dengan event_file target yang menunjuk ke blob, Database Engine memeriksa akses keluar sebelum sesi dimulai, dan sekali lagi setiap kali membuang event buffer ke blob.
  • Membaca data kejadian. Saat Anda memanggil sys.fn_xe_file_target_read_file atau sys.fn_MSxe_read_event_stream dengan URL blob, Database Engine memeriksa akses keluar saat fungsi inisialisasi. SSMS memanggil sys.fn_MSxe_read_event_stream saat Anda membuka data kejadian yang ditangkap di penampil kejadian.

Koneksi TDS masuk yang digunakan untuk mengelola sesi event melalui T-SQL tidak memerlukan konfigurasi NSP khusus untuk Extended Events. Pernyataan CREATE EVENT SESSION, ALTER EVENT SESSION, dan DROP EVENT SESSION, serta semua fungsi pembacaan, dijalankan melalui koneksi klien normal, sehingga mengikuti aturan akses inbound yang sama seperti koneksi klien lainnya ke database.

Konfigurasi yang didukung

Perilaku bergantung pada mode akses perimeter, apakah akun penyimpanan berada di perimeter yang sama dengan server logis, dan apakah dua perimeter berbeda saling terhubung.

SQL logical server NSP Akun penyimpanan NSP Behavior
Tidak ada NSP Tidak ada NSP Perimeter ini tidak mengevaluasi koneksi. Extended Events terhubung ke akun penyimpanan menggunakan kredensial yang Anda konfigurasikan dan aturan firewall akun penyimpanan. Untuk informasi lebih lanjut, lihat Otorisasi dan kontrol kontainer penyimpanan.
Tidak ada NSP Dalam NSP Perimeter tidak mengevaluasi akses keluar dari server logis. Apakah koneksi berhasil bergantung pada aturan masuk dari perimeter akun penyimpanan itu sendiri.
Dalam NSP (Diberlakukan) NSP yang sama Akses selalu diperbolehkan. Anda tidak perlu aturan keluar.
Dalam NSP (Diberlakukan) NSP berbeda tapi terhubung Akses diperbolehkan melalui aturan lintas perimeter. Anda tidak memerlukan aturan FQDN untuk lalu lintas keluar.
Dalam NSP (Diberlakukan) NSP yang berbeda dan tidak terhubung, atau tidak ada NSP Akses diizinkan jika Anda menggunakan identitas terkelola, atau jika aturan FQDN outbound dalam profil perimeter sesuai dengan nama host akun penyimpanan. Jika Anda menggunakan token SAS dan tidak ada aturan yang cocok, sesi peristiwa gagal dimulai dengan kesalahan 25602, dan fungsi pembacaan mungkin gagal dengan kesalahan 25759.
Dalam NSP (Transisi) Any Perimeter mengevaluasi dan mencatat aturan tapi tidak memblokir lalu lintas.

Konfigurasikan akses keluar ke akun penyimpanan

Saat Anda mengonfigurasi database untuk menggunakan Extended Events, Anda dapat memilih antara identitas terkelola dan autentikasi token SAS . Mekanisme autentikasi yang Anda pilih menentukan apakah Anda membutuhkan aturan akses keluar.

  1. Verifikasi asosiasi perimeter. Di portal Azure, cari Network Security Perimeter, pilih perimeter Anda, lalu pilih Associated Resources dari menu Settings untuk memastikan server Anda terdaftar. Untuk informasi lebih lanjut, lihat Perimeter keamanan jaringan.
  2. Pilih mekanisme autentikasi Anda. Gunakan autentikasi identitas terkelola. Token identitas terkelola menyertakan klaim yang dibutuhkan perimeter tersebut, sehingga Anda tidak perlu menambahkan aturan outbound dan dapat melewati langkah berikutnya.
  3. Tambahkan aturan akses keluar (hanya token SAS). Jika Anda menggunakan token SAS dan perimeter berada dalam mode pemberlakuan, tambahkan aturan akses keluar pada profil perimeter. Gunakan tipe aturan Nama domain lengkap (FQDN) dan nama host akun penyimpanan Anda sebagai nilai, misalnya myxedata.blob.core.windows.net.

Dalam contoh ini, Anda dapat menggunakan *.blob.core.windows.net untuk mengizinkan semua akun Azure Storage, tetapi pengaturan tersebut memungkinkan koneksi keluar ke akun Azure Storage yang tidak Anda miliki. Gunakan nama host spesifik jika Anda memungkinkan.

Biarkan perimeter tetap dalam mode transisi sampai Anda mengonfirmasi aturan outbound yang Anda perlukan. Dalam mode transisi, perimeter mencatat evaluasi aturan tanpa memblokir akses, sehingga Anda dapat menemukan aturan yang hilang sebelum menyebabkan kegagalan. Beralih ke mode terpaksa setelah aturan berlaku.

Keterbatasan dan perbedaan perilaku

  • Database Engine memeriksa akses keluar saat sesi dimulai dan pada setiap buffer flush. Jika Anda menghapus aturan keluar saat sesi sedang berjalan, sesi tersebut tidak berhenti. Penulisan ke buffer individual justru mulai gagal.
  • Identitas terkelola dan token SAS tidak setara dalam satu perimeter. Token identitas terkelola memuat klaim perimeter, sehingga tidak memerlukan aturan keluar. Token SAS tidak memuat klaim tersebut, sehingga memerlukan aturan outbound yang sesuai dalam mode pemberlakuan.
  • Fungsi baca yang diblokir mungkin tidak menimbulkan kesalahan. Ketika sebuah perimeter memblokir sys.fn_xe_file_target_read_file atau sys.fn_MSxe_read_event_stream, fungsi tersebut mungkin memunculkan error 25759 atau 25717, atau mengembalikan set hasil kosong tanpa error. Jika Anda mengharapkan data tapi tidak mendapatkan baris dan tidak ada error, periksa aturan outbound Anda.

Kesalahan saat perimeter memblokir akses

Error 25602 berarti event_file target tidak dapat diinisialisasi karena perimeter memblokir koneksi keluar ke akun penyimpanan:

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.

Error 25759 berarti sebuah perimeter memblokir fungsi baca:

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

Error 25717 berarti akses dicabut saat fungsi baca sedang dibaca. Karena Database Engine membaca data blob dalam potongan-potongan daripada mengunduh file utuh, kesalahan ini dapat terjadi di tengah proses set hasil:

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

Untuk mengatasi salah satu kesalahan ini, beralih ke autentikasi identitas terkelola, tambahkan aturan FQDN keluar yang sesuai dengan nama host akun penyimpanan, atau pindahkan akun penyimpanan ke perimeter yang sama dengan server logis.

Untuk detail diagnostik lebih lanjut tentang inisialisasi target dan kegagalan penulisan buffer, tanyakan log mesin Extended Events:

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

Perubahan asosiasi perimeter dan perubahan mode akses muncul di Azure Activity Log untuk server logis. Evaluasi aturan masuk dan keluar muncul dalam log diagnostik perimeter keamanan jaringan.

Tata kelola sumber daya

Di Azure SQL Database, konsumsi memori oleh sesi Extended Events dikontrol secara dinamis oleh Mesin Database untuk meminimalkan perebutan sumber daya.

Ada batas pada memori yang tersedia untuk sesi kejadian:

  • Dalam database tunggal, total memori sesi dibatasi hingga 128 MB.
  • Dalam kumpulan elastis, database individual dibatasi oleh batas database tunggal, dan totalnya tidak boleh melebihi 512 MB.

Jika Anda menerima pesan kesalahan yang mereferensikan batas memori, tindakan korektif yang dapat Anda lakukan adalah:

  • Kurangi jumlah sesi kejadian yang dijalankan secara bersamaan.
  • Untuk sesi peristiwa, gunakan pernyataan CREATE dan ALTER untuk mengurangi jumlah memori yang Anda tentukan dalam klausa MAX_MEMORY untuk sesi tersebut.

Note

Dalam Extended Events, klausa MAX_MEMORY muncul dalam dua konteks: saat membuat atau mengubah sesi (pada tingkat sesi), dan saat menggunakan target ring_buffer (pada tingkat target). Batas di atas berlaku untuk memori tingkat sesi.

Ada batasan jumlah sesi peristiwa yang dimulai di Azure SQL Database:

  • Dalam database tunggal, batasnya adalah 100.
  • Dalam kumpulan elastis, batasnya adalah 100 sesi cakupan database per kumpulan.

Di kumpulan elastis yang padat, memulai sesi extended event baru mungkin gagal karena keterbatasan memori meskipun jumlah total sesi yang telah dimulai kurang dari 100.

Untuk menemukan total memori yang digunakan oleh sesi peristiwa, jalankan kueri berikut saat tersambung ke database tempat sesi peristiwa dimulai:

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

Untuk menemukan total memori sesi peristiwa untuk kumpulan elastis, kueri ini perlu dijalankan di setiap database di kumpulan.

Konten terkait

  • Last updated on