Zdarzenia rozszerzone w usłudze Azure SQL

Dotyczy:Azure SQL DatabaseAzure SQL Managed InstanceBaza danych SQL w Fabric

Wprowadzenie do zdarzeń rozszerzonych można znaleźć tutaj:

Zestaw funkcji, funkcje i scenariusze użycia dla zdarzeń rozszerzonych w usłudze Azure SQL Database, bazie danych SQL w sieci szkieletowej i usłudze Azure SQL Managed Instance są podobne do tego, co jest dostępne w programie SQL Server. Główne różnice są następujące:

  • W usłudze Azure SQL Database, bazie danych SQL w Fabric i usłudze Azure SQL Managed Instance event_file obiekt docelowy zawsze używa obiektów blob w usłudze Azure Storage, a nie plików na dysku.
    • W programie SQL Server obiekt docelowy event_file może używać plików na dysku lub obiektów blob w Azure Storage.
  • W usługach Azure SQL Database i SQL Database w usłudze Fabric sesje zdarzeń są zawsze ograniczone do zakresu bazy danych. Oznacza to, że:
    • Sesja zdarzeń w jednej bazie danych nie może zbierać zdarzeń z innej bazy danych.
    • Zdarzenie musi wystąpić w kontekście bazy danych użytkownika, która ma zostać uwzględniona w sesji.
  • W usłudze Azure SQL Managed Instance można tworzyć sesje zdarzeń zarówno na poziomie serwera, jak i na poziomie bazy danych. W większości scenariuszy zalecamy użycie sesji zdarzeń na poziomie serwera.

Wprowadzenie

Istnieją dwa przykłady przewodników, które ułatwiają szybkie rozpoczęcie pracy z zdarzeniami rozszerzonymi:

Zdarzenia rozszerzone mogą służyć do monitorowania replik przeznaczonych tylko do odczytu. Aby uzyskać więcej informacji, zobacz Odczyt zapytań dotyczących replik.

Najlepsze rozwiązania

Zastosuj poniższe najlepsze praktyki, aby bezpiecznie i niezawodnie korzystać z Extended Events bez negatywnego wpływu na stan silnika bazy danych i wydajność obciążeń.

  • Jeśli używasz event_file target:
    • W zależności od zdarzeń dodanych do sesji pliki generowane przez event_file obiekt docelowy mogą zawierać poufne dane. Dokładnie przejrzyj przypisania ról RBAC oraz listy kontroli dostępu (ACL) dla konta magazynu i kontenera, łącznie z uprawnieniami dziedziczonymi, aby uniknąć niepotrzebnego przyznawania uprawnień do odczytu. Przestrzegaj zasady najniższych uprawnień.
    • Użyj konta magazynowego w tym samym regionie platformy Azure co baza danych lub wystąpienie zarządzane, w których tworzysz sesje zdarzeń.
    • Dopasuj nadmiarowość konta magazynu do nadmiarowości bazy danych, elastycznej puli lub wystąpienia zarządzanego. W przypadku zasobów z lokalną nadmiarowością użyj LRS, GRS lub RA-GRS. W przypadku zasobów nadmiarowych strefowo użyj ZRS, GZRS lub RA-GZRS. Aby uzyskać szczegółowe informacje, zobacz Nadmiarowość usługi Azure Storage.
    • Nie używaj żadnej warstwy dostępu do obiektu blob innej niż Hot.
    • Nie włączaj hierarchicznej przestrzeni nazw dla konta magazynu.
  • Jeśli chcesz utworzyć sesję zdarzeń działającą w sposób ciągły, uruchamianą automatycznie po każdym ponownym uruchomieniu Aparatu bazy danych (na przykład po przełączeniu awaryjnym lub operacji konserwacyjnej), uwzględnij opcję sesji zdarzeń STARTUP_STATE = ON w instrukcjach CREATE EVENT SESSION lub ALTER EVENT SESSION.
  • Z drugiej strony należy używać STARTUP_STATE = OFF do krótkoterminowych sesji zdarzeń, takich jak te używane w rozwiązywaniu problemów ad hoc.
  • W usłudze Azure SQL Database nie odczytuj zdarzeń zakleszczeń z wbudowanej sesji zdarzeń dl. Jeśli zebrano dużą liczbę zdarzeń zakleszczenia, odczytanie ich za pomocą funkcji sys.fn_xe_file_target_read_file() może spowodować błąd braku pamięci w master bazie danych. Może to mieć wpływ na przetwarzanie logowania i spowodować awarię aplikacji. Aby zapoznać się z zalecanymi sposobami monitorowania zakleszczeń, zobacz temat Zbieranie wykresów zakleszczeń w usłudze Azure SQL Database za pomocą funkcji Extended Events.

Cele sesji zdarzeń

Aby uzyskać więcej informacji o obiektach docelowych zdarzeń rozszerzonych obsługiwanych w usłudze Azure SQL Database, bazie danych SQL w sieci szkieletowej, usłudze Azure SQL Managed Instance i programie SQL Server, zobacz Cele dla zdarzeń rozszerzonych.

Transact-SQL różnice

Podczas wykonywania instrukcji CREATE EVENT SESSION, ALTER EVENT SESSION i DROP EVENT SESSION w programie SQL Server i w usłudze Azure SQL Managed Instance należy użyć klauzuli ON SERVER . W usłudze Azure SQL Database zamiast tego używa się klauzuli ON DATABASE, ponieważ w usłudze Azure SQL Database sesje zdarzeń mają zakres bazy danych.

Widoki wykazu zdarzeń rozszerzonych

Zdarzenia rozszerzone udostępniają kilka widoków katalogowych. Widoki katalogu informują o metadanych lub definicji sesji zdarzeń. Te widoki nie zwracają informacji o wystąpieniach aktywnych sesji zdarzeń.

Aby uzyskać listę widoków wykazu dla każdej platformy, zobacz Rozszerzone widoki wykazu zdarzeń.

Dynamiczne widoki zarządzania zdarzeniami rozszerzonymi

Zdarzenia rozszerzone udostępniają kilka dynamicznych widoków zarządzania (DMV). Dynamiczne widoki zarządzania zwracają informacje o uruchomionych sesjach zdarzeń.

Aby uzyskać listę dynamicznych widoków zarządzania dla każdej platformy, zobacz Dynamiczne widoki zarządzania zdarzeniami rozszerzonymi.

Typowe dynamiczne widoki zarządzania

Istnieją dodatkowe dynamiczne widoki zarządzania zdarzeniami rozszerzonymi, które są wspólne dla usługi Azure SQL Database, usługi Azure SQL Managed Instance i programu SQL Server:

Dostępne zdarzenia, akcje i cele

Dostępne zdarzenia, akcje i obiekty docelowe można uzyskać przy użyciu tego zapytania:

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

Zobacz uprawnienia , aby uzyskać szczegółowe uprawnienia według platformy.

Autoryzacja i kontrola kontenera magazynu

Jeśli używasz celu event_file z obiektami blob usługi Azure Storage, silnik bazy danych, na którym uruchomiona jest sesja zdarzeń, musi mieć określony dostęp do kontenera obiektów blob. Ten dostęp można udzielić w jeden z następujących sposobów:

  • Przypisz rolę RBAC Storage Blob Data Contributor do tożsamości zarządzanej serwera logicznego Azure SQL lub wystąpienia zarządzanego Azure SQL dla kontenera i utwórz poświadczenie, aby poinstruować aparat bazy danych, by używał tożsamości zarządzanej do uwierzytelniania.

    Alternatywnie do przypisania roli RBAC Współautor danych obiektów blob usługi Storage można przypisać następujące akcje 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

  • Utwórz token SAS dla kontenera i zapisz token w poświadczeniu.

    W usłudze Azure SQL Database należy użyć poświadczenia o zakresie bazy danych. W usłudze Azure SQL Managed Instance i w programie SQL Server użyj poświadczenia związanego z serwerem.

    Token SAS utworzony dla kontenera usługi Azure Storage musi spełniać następujące wymagania:

    • Mieć rwdl uprawnienia (Read, Write, Delete, List).
    • Ustaw czas rozpoczęcia i czas wygaśnięcia tak, aby obejmowały okres trwania sesji zdarzenia.
    • Brak ograniczeń adresów IP.

Obwód zabezpieczeń sieci (wersja zapoznawcza)

Perimeter bezpieczeństwa sieciowego (preview) wyznacza granicę dostępu do sieci wokół zasobów Azure SQL Database oraz innych platform Azure as a Service (PaaS). Gdy przypisujesz logiczny serwer do obwodu bezpieczeństwa sieciowego (NSP), połączenia wychodzące, które Extended Events tworzy do Azure Storage, podlegają regułom dostępu tego obszaru.

Note

Perimeter bezpieczeństwa sieciowego jest dostępny tylko dla Azure SQL Database. Ta sekcja nie dotyczy Azure SQL Managed Instance ani bazy danych SQL w Fabric. Jako funkcja podglądowa, obwód bezpieczeństwa sieciowego podlega Dodatkowym Warunkom Użytkowania dla Microsoft Azure Previews.

Jak Extended Events wykorzystuje dostęp do sieci

Extended Events umożliwia połączenia wychodzące z Database Engine do Azure Storage w dwóch przypadkach:

  • Zapisywanie danych zdarzeń. Gdy rozpoczynasz sesję zdarzeń z elementem docelowym event_file, który wskazuje na obiekt blob, Aparat bazy danych sprawdza dostęp wychodzący przed rozpoczęciem sesji oraz ponownie za każdym razem, gdy opróżnia bufory zdarzeń do obiektu blob.
  • Odczytywanie danych z wydarzeń. Gdy wywołujesz sys.fn_xe_file_target_read_file lub sys.fn_MSxe_read_event_stream z URL-em blob, Database Engine sprawdza dostęp wychodzący po inicjalizacji funkcji. SSMS wywołuje sys.fn_MSxe_read_event_stream, gdy otwierasz przechwycone dane zdarzeń w przeglądarce zdarzeń.

Przychodzące połączenia TDS używane do zarządzania sesjami zdarzeń przez T-SQL nie wymagają żadnej konfiguracji NSP specyficznej dla Extended Events. Instrukcje CREATE EVENT SESSION, ALTER EVENT SESSION i DROP EVENT SESSION oraz funkcje odczytu działają w ramach standardowego połączenia klienta, więc podlegają tym samym regułom dostępu przychodzącego co każde inne połączenie klienta z bazą danych.

Obsługiwane konfiguracje

Zachowanie zależy od trybu dostępu do obwodu, od tego, czy konto pamięci znajduje się w tym samym obwodzie co serwer logiczny oraz czy dwa różne obwody są ze sobą powiązane.

SQL logiczny serwer NSP Konto magazynu NSP Behavior
Brak NSP Brak NSP Strefa brzegowa nie sprawdza połączenia. Extended Events łączy się z kontem magazynu przy użyciu skonfigurowanego przez Ciebie poświadczenia oraz reguł zapory konta magazynu. Więcej informacji można znaleźć w artykule Autoryzacja i kontrola pojemników magazynowych.
Brak NSP W NSP Obwód zabezpieczeń nie analizuje dostępu wychodzącego z serwera logicznego. To, czy nawiązanie połączenia się powiedzie, zależy od reguł ruchu przychodzącego we własnym obwodzie konta magazynu.
W NSP (egzekwowanym) Ten sam NSP Dostęp jest zawsze dozwolony. Nie potrzebujesz reguły wychodzącej.
W NSP (egzekwowanym) Odrębne, ale powiązane NSP Dostęp jest dozwolony zgodnie z zasadami przekraczania granic obwodowych. Nie potrzebujesz reguły FQDN dla ruchu wychodzącego.
W NSP (egzekwowanym) Inne, niepowiązane NSP lub brak NSP Dostęp jest dozwolony, gdy używasz zarządzanej tożsamości lub gdy wychodząca reguła FQDN w profilu perimetru odpowiada nazwie hosta konta pamięci. Jeśli używasz tokena SAS i żadna reguła nie pasuje, sesja zdarzeń nie może zostać uruchomiona z błędem 25602, a funkcje odczytu mogą zakończyć się niepowodzeniem z błędem 25759.
W NSP (faza przejściowa) Jakikolwiek Obwod ocenia i rejestruje zasady, ale nie blokuje ruchu.

Konfiguruj dostęp wychodzący do konta pamięci masowej

Gdy konfigurujesz bazę danych do korzystania z Extended Events, możesz wybrać między uwierzytelnianiem tożsamości zarządzanej a tokenem SAS . Wybrany przez Ciebie mechanizm uwierzytelniania decyduje, czy potrzebujesz reguły dostępu wychodzącego.

  1. Zweryfikuj skojarzenie perymetru. W portalu Azure wyszukaj Network Security Perimeter, wybierz swój perymetr, a następnie wybierz Associated Resources w menu Settings, aby potwierdzić, że Twój serwer jest na liście. Więcej informacji można znaleźć w artykule Obszar bezpieczeństwa sieci.
  2. Wybierz swój mechanizm uwierzytelniania. Korzystaj z zarządzanego uwierzytelniania tożsamości. Zarządzany token tożsamości zawiera roszczenia potrzebne dla obwodu, więc nie musisz dodawać reguły wychodzącej i możesz pominąć kolejny krok.
  3. Dodaj regułę dostępu wychodzącego (tylko token SAS). Jeśli używasz tokena SAS i perymetr jest w trybie wymuszonym, dodaj regułę dostępu wychodzącego w profilu perymetru. Użyj typu reguły Fully qualified domain names (FQDN) oraz nazwy hosta swojego konta pamięci jako wartości, na przykład myxedata.blob.core.windows.net.

W tym przykładzie możesz użyć ustawienia *.blob.core.windows.net, aby zezwolić na dostęp do wszystkich kont usługi Azure Storage, ale to ustawienie umożliwia połączenia wychodzące z kontami magazynu, które nie należą do Ciebie. Używaj konkretnej nazwy hosta, gdzie możesz.

Utrzymuj strefę brzegową w trybie przejściowym, dopóki nie potwierdzisz, które reguły ruchu wychodzącego są potrzebne. W trybie przejściowym perymetr rejestruje oceny reguł bez blokowania dostępu, więc możesz znaleźć brakujące reguły, zanim spowodują awarie. Przełącz na tryb wymuszania, gdy reguły są już wdrożone.

Ograniczenia i różnice w zachowaniach

  • Aparat bazy danych sprawdza dostęp wychodzący, gdy sesja się rozpoczyna, oraz przy każdym opróżnianiu bufora. Jeśli usuniesz regułę wychodzącą podczas trwania sesji, sesja się nie zatrzyma. Poszczególne zapisy do bufora zaczynają kończyć się niepowodzeniem.
  • Zarządzane tożsamości i tokeny SAS nie są równoważne w obrębie granicy zabezpieczeń. Zarządzany token tożsamości przenosi roszczenia perymetru, więc nie potrzebuje reguły wychodzącej. Token SAS nie posiada tych roszczeń, więc potrzebuje odpowiedniej reguły wychodzącej w trybie wymuszonym.
  • Zablokowana funkcja odczytu może nie wywołać błędu. Gdy obwód blokuje sys.fn_xe_file_target_read_file lub sys.fn_MSxe_read_event_stream, funkcja może wywołać błąd 25759 lub 25717 lub zwrócić pusty zbiór wyników bez błędu. Jeśli oczekujesz danych, ale nie otrzymujesz żadnych wierszy i nie pojawia się żaden błąd, sprawdź reguły ruchu wychodzącego.

Błędy, gdy perymetr blokuje dostęp

Błąd 25602 oznacza, że event_file cel nie mógł się zainicjować, ponieważ perymetr zablokował połączenie wychodzące do konta pamięci:

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.

Błąd 25759 oznacza, że perymetr zablokował funkcję odczytu:

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

Błąd 25717 oznacza, że dostęp został cofnięty, gdy funkcja odczytu wykonywała odczyt. Ponieważ Database Engine odczytuje dane blob w fragmentach, zamiast pobierać całe pliki, ten błąd może wystąpić w trakcie zbioru wyników:

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

Aby rozwiązać którykolwiek z tych błędów, przełącz się na uwierzytelnianie za pomocą tożsamości zarządzanej, dodaj regułę wychodzącego ruchu FQDN zgodną z nazwą hosta konta magazynu lub przenieś konto magazynu do tego samego obrębu co serwer logiczny.

Aby uzyskać więcej szczegółów diagnostycznych dotyczących inicjalizacji celu i błędów zapisu bufora, zapytaj dziennik silnika Extended Events:

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

Zmiany skojarzeń obwodu i trybów dostępu pojawiają się w dzienniku aktywności Azure dla logicznego serwera. Ocenianie reguł ruchu przychodzącego i wychodzącego jest widoczne w dziennikach diagnostycznych obwodu zabezpieczeń sieci.

Nadzór nad zasobami

W usłudze Azure SQL Database użycie pamięci przez rozszerzone sesje zdarzeń jest dynamicznie kontrolowane przez aparat bazy danych w celu zminimalizowania rywalizacji o zasoby.

Dostępna pamięć dla sesji zdarzeń jest ograniczona:

  • W pojedynczej bazie danych łączna ilość pamięci sesji jest ograniczona do 128 MB.
  • W elastycznej puli poszczególne bazy danych są ograniczone przez limity pojedynczej bazy danych i łącznie nie mogą przekraczać 512 MB.

Jeśli zostanie wyświetlony komunikat o błędzie odwołujący się do limitu pamięci, możesz wykonać następujące akcje naprawcze:

  • Uruchamianie mniejszej liczby współbieżnych sesji zdarzeń.
  • Używając instrukcji CREATE i ALTER dla sesji zdarzeń, zmniejsz ilość pamięci określonej w klauzuli MAX_MEMORY dla tej sesji.

Note

W przypadku zdarzeń rozszerzonych klauzula MAX_MEMORY jest wyświetlana w dwóch kontekstach: podczas tworzenia lub zmieniania sesji (na poziomie sesji) oraz podczas korzystania z ring_buffer obiektu docelowego (na poziomie docelowym). Powyższe limity dotyczą pamięci na poziomie sesji.

Istnieje limit liczby uruchomionych sesji zdarzeń w usłudze Azure SQL Database:

  • W pojedynczej bazie danych limit wynosi 100.
  • W elastycznej puli limit wynosi 100 sesji w zakresie bazy danych na pulę.

W gęstych elastycznych pulach uruchomienie nowej rozszerzonej sesji zdarzeń może zakończyć się niepowodzeniem z powodu ograniczeń pamięci nawet wtedy, gdy łączna liczba rozpoczętych sesji jest większa niż 100.

Aby znaleźć łączną ilość pamięci zużywaną przez sesję zdarzeń, wykonaj następujące zapytanie podczas nawiązywania połączenia z bazą danych, w której uruchomiono sesję zdarzeń:

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

Aby znaleźć łączną pamięć sesji zdarzeń dla elastycznej puli, to zapytanie musi być wykonywane w każdej bazie danych w puli.

Treści powiązane

  • Last updated on