Bagikan melalui

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.
  • Di Azure SQL Database dan database SQL di Fabric, sesi peristiwa selalu dilingkup 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 cakupan server dan cakupan database. Sebaiknya gunakan sesi peristiwa cakupan 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 event_file target:
    • 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 selain .Hot
    • Jangan aktifkan namespace hierarkis untuk akun penyimpanan.
  • Jika Anda ingin membuat sesi peristiwa yang terus berjalan yang dimulai secara otomatis setelah setiap Mesin Database dimulai ulang (misalnya, setelah failover atau peristiwa pemeliharaan), sertakan opsi STARTUP_STATE = ON sesi peristiwa dalam pernyataan atau CREATE EVENT SESSION AndaALTER EVENT SESSION.
  • 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 peristiwa kebuntuan yang dikumpulkan, membacanya dengan fungsi sys.fn_xe_file_target_read_file() dapat menyebabkan kesalahan di luar memori dalam master database. Ini dapat memengaruhi pemrosesan login dan mengakibatkan pemadaman aplikasi. Untuk cara yang direkomendasikan untuk memantau kebuntuan, lihat Mengumpulkan grafik kebuntuan di Azure SQL Database dengan Acara yang Diperluas.

Target sesi peristiwa

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 sebagai gantinya ON DATABASE , karena dalam sesi peristiwa Azure SQL Database tercakup dalam database.

Tampilan katalog Acara yang Diperluas

Extended Events menyediakan beberapa tampilan katalog. Tampilan katalog memberi tahu Anda tentang metadata atau definisi sesi peristiwa. 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 peristiwa yang dimulai .

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

DMV 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 Kontributor Data Blob Penyimpanan ke identitas terkelola server logis Azure SQL atau instans terkelola Azure SQL pada kontainer, dan buat kredensial untuk menginstruksikan Mesin Database untuk menggunakan identitas terkelola untuk autentikasi.

    Sebagai alternatif untuk menetapkan peran RBAC Kontributor Data Blob Penyimpanan, 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.

    Di Azure SQL Database, Anda harus menggunakan kredensial cakupan 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).
    • Memiliki waktu mulai dan waktu kedaluwarsa yang mencakup masa pakai sesi peristiwa.
    • Tidak memiliki batasan alamat IP.

Tata kelola sumber daya

Di Azure SQL Database, konsumsi memori oleh sesi peristiwa yang diperluas dikontrol secara dinamis oleh Mesin Database untuk meminimalkan ketidakcocokan sumber daya.

Ada batasan memori yang tersedia untuk sesi peristiwa:

  • 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.
  • Menggunakan CREATE pernyataan dan ALTER untuk sesi peristiwa, kurangi jumlah memori yang Anda tentukan dalam MAX_MEMORY klausul untuk sesi tersebut.

Note

Di Acara yang Diperluas, MAX_MEMORY klausul muncul dalam dua konteks: saat membuat atau mengubah sesi (pada tingkat sesi), dan saat menggunakan ring_buffer target (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 peristiwa baru yang diperluas mungkin gagal karena kendala memori bahkan ketika jumlah total sesi yang dimulai di bawah 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