Rozšířené události v Azure SQL

Platí pro:Azure SQL DatabaseAzure SQL Managed InstanceSQL database ve Fabric

Úvod do rozšířených událostí najdete tady:

Sady funkcí, funkce a scénáře použití rozšířených událostí ve službě Azure SQL Database, sql database in Fabric a Azure SQL Managed Instance jsou podobné tomu, co je dostupné na SQL Serveru. Hlavní rozdíly:

  • V Azure SQL Database, SQL databázi ve Fabricu a Azure SQL Managed Instance event_file cíl vždy používá objekty blob ve službě Azure Storage místo souborů na disku.
    • V SQL Serveru event_file může cíl používat soubory na disku nebo bloby v Azure úložišti.
  • V Azure SQL Database a v databázi SQL ve Fabric mají relace událostí vždy obor omezený na databázi. To znamená, že:
    • Relace událostí v jedné databázi nemůže shromažďovat události z jiné databáze.
    • K události musí dojít v kontextu uživatelské databáze, která se má zahrnout do relace.
  • Ve službě Azure SQL Managed Instance můžete vytvořit relace událostí jak s rozsahem serveru, tak s rozsahem databáze. Pro většinu scénářů doporučujeme používat relace událostí s rozsahem serveru.

Začínáme

Existují dva příklady návodů, které vám pomůžou rychle začít s rozšířenými událostmi:

Rozšířené události lze použít k monitorování replik jen pro čtení. Další informace najdete v tématu Čtení dotazů na repliky.

Osvědčené postupy

Při používání rozšířených událostí bezpečně, spolehlivě a bez vlivu na stav databázového stroje a výkon úloh využijte následující osvědčené postupy.

  • Pokud použijete cíl event_file:
    • V závislosti na událostech přidaných do relace můžou soubory vytvořené event_file cílem obsahovat citlivá data. Pečlivě zkontrolujte přiřazení rolí RBAC a seznamy řízení přístupu (ACL) v účtu úložiště a kontejneru, včetně zděděného přístupu, abyste se vyhnuli udělení zbytečného přístupu ke čtení. Dodržujte zásadu nejnižších oprávnění.
    • Použijte účet úložiště ve stejné oblasti Azure jako databáze nebo spravovaná instance, ve které vytváříte relace událostí.
    • Slaďte redundanci účtu úložiště s redundancí databáze, elastického fondu nebo spravované instance. Pro místně redundantní prostředky použijte LRS, GRS nebo RA-GRS. Pro zónově redundantní prostředky použijte ZRS, GZRS nebo RA-GZRS. Podrobnosti najdete v části Redundance služby Azure Storage.
    • Nepoužívejte jinou úroveň přístupu k objektům blob než Hot.
    • Nepovolujte hierarchický obor názvů pro účet úložiště.
  • Pokud chcete vytvořit relaci událostí, která poběží nepřetržitě a automaticky se spustí po každém restartu modulu Database Engine (například po převzetí služeb při selhání nebo po údržbě), zahrňte do příkazů CREATE EVENT SESSION nebo ALTER EVENT SESSION možnost relace událostí STARTUP_STATE = ON.
  • Naopak použijte STARTUP_STATE = OFF pro krátkodobé relace pro události, například při operativním řešení potíží.
  • V Azure SQL Database nečtěte události uváznutí z předdefinované relace událostí dl. Pokud se shromáždí velké množství událostí zablokování, jejich čtení pomocí funkce sys.fn_xe_file_target_read_file() může v databázi master způsobit chybu z důvodu nedostatku paměti. To může mít vliv na zpracování přihlášení a způsobit výpadek aplikace. Doporučené způsoby, jak monitorovat uvíznutí, najdete v článku Shromažďování grafů uvíznutí v Azure SQL Database pomocí rozšířených událostí.

Cíle relace událostí

Další informace o cílech rozšířených událostí podporovaných ve službě Azure SQL Database, SQL databázi v rámci Fabric, Azure SQL Managed Instance a SQL Serveru najdete v tématu Cíle pro rozšířené události.

Rozdíly Transact-SQL

Když spustíte příkazy CREATE EVENT SESSION, ALTER EVENT SESSION a DROP EVENT SESSION v SQL Serveru a ve spravované instanci Azure SQL, použijete klauzuli ON SERVER . Ve službě Azure SQL Database místo toho použijete klauzuli ON DATABASE, protože v Azure SQL Database mají relace událostí obor platnosti databáze.

Zobrazení katalogu rozšířených událostí

Rozšířené události poskytují několik katalogových zobrazení. Zobrazení katalogu poskytují informace o metadatech nebo definici relace události. Tato zobrazení nevrací informace o instancích aktivních relací událostí.

Seznam zobrazení katalogu pro každou platformu najdete v tématu Zobrazení katalogu rozšířených událostí.

Zobrazení dynamické správy pro rozšířené události

Rozšířené události poskytují několik zobrazení dynamické správy (DMV). Zobrazení dynamické správy (DMV) vracejí informace o spuštěných relacích událostí.

Seznam zobrazení dynamické správy pro každou platformu najdete v tématu Zobrazení dynamické správy rozšířených událostí.

Běžná DMV

Existují další rozšířené dynamické správy událostí, které jsou společné pro Azure SQL Database, Azure SQL Managed Instance a SQL Server:

Dostupné události, akce a cíle

Pomocí tohoto dotazu můžete získat dostupné události, akce a cíle:

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

Podívejte se na oprávnění pro podrobná oprávnění podle platformy.

Autorizace a řízení kontejneru úložiště

Když použijete event_file cíl s objekty blob služby Azure Storage, databázový stroj, na kterém je spuštěná relace událostí, musí mít specifický přístup ke kontejneru objektů blob. Tento přístup můžete udělit jedním z následujících způsobů:

  • Přiřaďte roli RBAC Storage Blob Data Contributorspravované identitě logického serveru Azure SQL nebo spravované instance Azure SQL pro kontejner a vytvořte přihlašovací údaje, které modulu Database Engine určí, aby k ověřování používal spravovanou identitu.

    Jako alternativu k přiřazení role RBAC Storage Blob Data Contributor můžete přiřadit následující akce RBAC:

    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

  • Vytvořte token SAS pro kontejner a uložte token do přihlašovacích údajů.

    Ve službě Azure SQL Database musíte použít přihlašovací údaje s oborem databáze. Ve službě Azure SQL Managed Instance a SQL Serveru použijte přihlašovací údaje s oborem serveru.

    Token SAS, který vytvoříte pro kontejner Azure Storage, musí splňovat následující požadavky:

    • Mějte oprávnění rwdl (Read, Write, Delete, List).
    • Nastavte čas zahájení a čas ukončení platnosti tak, aby pokrývaly celou dobu trvání relace události.
    • Nemá žádná omezení IP adres.

Obvodová bezpečnost sítě (náhled)

Perimetr síťové bezpečnosti (náhled) vytváří hranici přístupu k síti kolem zdrojů Azure SQL Database a dalších platforem Azure as a Service (PaaS). Když přiřadíte logický server k síťovému bezpečnostnímu perimetru (NSP), odchozí spojení, která Extended Events navazuje na Azure Storage, podléhají přístupovým pravidlům perimetru.

Note

Perimetr síťové bezpečnosti je dostupný pouze pro Azure SQL Database. Tato sekce se nevztahuje na Azure SQL Managed Instance ani SQL databázi ve Fabric. Jako ukázková funkce je síťový bezpečnostní perimetr předmětem doplňkových podmínek užívání pro Microsoft Azure Previews.

Jak Extended Events využívá přístup k síti

Extended Events provádí odchozí spojení z Database Engine do Azure Storage ve dvou případech:

  • Zápis dat o událostech. Když zahájíte event session s event_file cílem, který ukazuje na blob, Database Engine zkontroluje odchozí přístup před začátkem relace a pokaždé vyprázdní event buffery do blobu.
  • Čtení dat o událostech. Když voláte sys.fn_xe_file_target_read_file nebo sys.fn_MSxe_read_event_stream pomocí blob URL, Database Engine při inicializaci funkce kontroluje odchozí přístup. SSMS volá sys.fn_MSxe_read_event_stream , když otevřete zachycená data událostí v prohlížeči událostí.

Příchozí TDS připojení používaná ke správě relací událostí přes T-SQL nevyžadují žádnou konfiguraci NSP specifickou pro Extended Events. Příkazy CREATE EVENT SESSION, ALTER EVENT SESSION, and a DROP EVENT SESSION funkce čtení běží přes běžné klientské připojení, takže se řídí stejnými pravidly příchozího přístupu jako jakékoli jiné klientské připojení k databázi.

Podporované konfigurace

Chování závisí na přístupovém režimu perimetru, na tom, zda je úložný účet ve stejném perimetru jako logický server, a na tom, zda jsou dva různé perimetry propojeny navzájem.

SQL logický server NSP Úložný účet NSP Behavior
Žádná NSP Žádná NSP Perimetr nevyhodnocuje připojení. Extended Events se připojuje k úložnému účtu pomocí konfigurovaného přihlašovacího čísla a pravidel firewallu pro úložný účet. Pro více informací viz Autorizace a řízení úložných kontejnerů.
Žádná NSP V NSP Perimetr nehodnotí odchozí přístup z logického serveru. To, zda bude připojení úspěšné, závisí na příchozích pravidlech vlastního perimetru daného účtu úložiště.
V rámci NSP (vynuceném) Stejný NSP Přístup je vždy povolen. Nepotřebujete odchozí pravidlo.
V NSP (vynucené) Jiné, ale propojené NSP Přístup je povolen na základě pravidel mezi perimetry. Nepotřebujete odchozí pravidlo FQDN.
V NSP (vynucené) Jiný nepropojený NSP, nebo žádný NSP Přístup je povolen, když používáte spravovanou identitu, nebo když odchozí FQDN pravidlo v perimetrovém profilu odpovídá názvu hostitele úložného účtu. Pokud použijete token SAS a žádné pravidlo neodpovídá, spuštění relace událostí se nezdaří s chybou 25602 a funkce čtení mohou selhat s chybou 25759.
V rámci NSP (přechod) Any Perimetr hodnotí a zaznamenává pravidla, ale neblokuje dopravu.

Nastavte odchozí přístup ke skladu

Když nastavíte databázi pro použití Extended Events, můžete si vybrat mezi autentizací spravované identity a SAS tokenu . Mechanismus autentizace, který zvolíte, určuje, zda potřebujete pravidlo odchozího přístupu.

  1. Ověřte si obvodovou asociaci. V portálu Azure vyhledejte Network Security Perimeter, vyberte svůj perimetr a poté v nastavení vyberte Associated Resources, abyste potvrdili, že je váš server uveden. Pro více informací viz Perimetr bezpečnosti sítě.
  2. Vyberte si svůj autentizační mechanismus. Používejte řízenou identitní autentizaci. Spravovaný identitní token obsahuje nároky, které perimetr potřebuje, takže nemusíte přidávat odchozí pravidlo a můžete přeskočit další krok.
  3. Přidejte pravidlo odchozího přístupu (pouze SAS token). Pokud používáte SAS token a perimetr je v režimu vynucení, přidejte pravidlo odchozího přístupu do profilu perimetru. Použijte typ pravidla Plně kvalifikované doménové názvy (FQDN) a hostitelské jméno vašeho úložného účtu jako hodnotu, například myxedata.blob.core.windows.net.

V tomto příkladu můžete použít *.blob.core.windows.net povolení pro všechny Azure Storage účty, ale toto nastavení umožňuje odchozí připojení k úložným účtům, které nevlastníte. Použijte konkrétní název hostitele, kde to jde.

Udržujte perimetr v přechodovém režimu, dokud si neurčite, která pravidla pro odjezd potřebujete. V přechodovém režimu perimetr zaznamenává vyhodnocení pravidel bez blokování přístupu, takže můžete najít chybějící pravidla dříve, než způsobí selhání. Po zavedení pravidel přepněte na vynucený režim.

Omezení a rozdíly v chování

  • Database Engine kontroluje odchozí přístup při zahájení relace a při každém vyčištění bufferu. Pokud odstraníte odchozí pravidlo během běžící relace, relace se nezastaví. Místo toho začínají selhávat jednotlivé zápisy do bufferu.
  • Spravované identity a SAS tokeny nejsou pod perimetrem ekvivalentní. Spravovaný identifikační token přenáší nároky na perimetr, takže nepotřebuje odchozí pravidlo. SAS token tyto nároky nenese, takže potřebuje odpovídající odchozí pravidlo v režimu vynucování.
  • Blokovaná čtení nemusí vyvolat chybu. Když obvod blokuje sys.fn_xe_file_target_read_file nebo sys.fn_MSxe_read_event_stream, funkce může vyvolat chybu 25759 nebo 25717, nebo vrátit prázdnou množinu výsledků bez chyby. Pokud očekáváte data, ale nevrátí se žádné řádky ani chyba, zkontrolujte odchozí pravidla.

Chyby, když perimetr blokuje přístup

Chyba 25602 znamená, že event_file cíl nemohl inicializovat, protože perimetr zablokoval odchozí spojení k úložnému účtu:

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.

Chyba 25759 znamená, že perimetr zablokoval čtecí funkci:

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

Chyba 25717 znamená, že přístup byl odvolán, zatímco funkce pro čtení prováděla čtení. Protože Database Engine čte blob data v částech místo stahování celých souborů, může tato chyba nastat v průběhu výsledné sady:

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

Pro vyřešení těchto chyb přejděte na spravovanou autentizaci identity, přidejte odchozí FQDN pravidlo, které odpovídá názvu hostitele úložného účtu, nebo přesunute úložný účet do stejného obvodu jako logický server.

Podrobnější diagnostické informace o inicializaci cíle a selháních zápisu do vyrovnávací paměti naleznete v protokolu modulu Extended Events:

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

Změny asociace perimetru a režimů přístupu se objevují v Azure Activity Logu pro logický server. Hodnocení příchozích a odchozích pravidel se objevují v diagnostických logech perimetru sítě.

Zásady správného řízení prostředků

Ve službě Azure SQL Database je spotřeba paměti relacemi rozšířených událostí dynamicky řízena databázovým modulem, aby se minimalizovaly konflikty o prostředky.

Množství paměti dostupné pro relace událostí je omezené:

  • V rámci jedné databáze je celková paměť relací omezena na 128 MB.
  • V elastickém fondu jsou jednotlivé databáze omezeny limity jednotlivých databází a celkem nemohou překročit 512 MB.

Pokud se zobrazí chybová zpráva odkazující na limit paměti, můžete provést opravné akce:

  • Spouštějte méně souběžných relací událostí.
  • Pomocí příkazů CREATE a ALTER pro relace událostí snižte množství paměti, které pro relaci zadáte v klauzuli MAX_MEMORY.

Note

V Extended Events se klauzule MAX_MEMORY objevuje ve dvou kontextech: při vytváření nebo úpravě relace (na úrovni relace) a při použití cíle ring_buffer (na úrovni cíle). Výše uvedené limity platí pro paměť na úrovni relace.

Počet spuštěných relací událostí ve službě Azure SQL Database je omezený:

  • V jedné databázi je limit 100.
  • V elastickém fondu je limit 100 relací v rozsahu databáze na jeden fond.

V hustých elastických poolech může spuštění nové relace rozšířených událostí selhat kvůli omezením paměti, i když je celkový počet spuštěných relací nižší než 100.

Pokud chcete zjistit celkovou paměť spotřebovanou relací událostí, spusťte následující dotaz při připojení k databázi, ve které je spuštěna relace události:

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

Chcete-li zjistit celkovou paměť relací událostí pro elastický fond, je třeba tento dotaz spustit ve všech databázích ve fondu.

Související obsah

  • Poslední aktualizace v