Ring Buffer

Ring Buffer to docelowy typ Extended Events przechowujący ostatnie zdarzenia w pamięci, tracone po restarcie.

Ring Buffer w SQL Server Extended Events

Ring Buffer jest docelowym typem sesji Extended Events w Microsoft SQL Server. Służy do przechowywania przechwyconych zdarzeń bezpośrednio w pamięci procesu SQL Server. Mechanizm działa jak bufor cykliczny: nowe zdarzenia są dopisywane do jego końca, a gdy zabraknie miejsca, najstarsze wpisy są zastępowane nowszymi. Dzięki temu bufor nie rośnie bez ograniczeń i może przechowywać przede wszystkim informacje o niedawnej aktywności silnika.

W przeciwieństwie do celu event_file, Ring Buffer nie zapisuje zdarzeń w trwałym pliku. Zawartość jest dostępna przez metadane uruchomionej sesji Extended Events, między innymi za pomocą widoku dynamicznego sys.dm_xe_database_targets w Azure SQL Database lub sys.dm_xe_session_targets w SQL Server. Dane celu są zwracane jako XML, który zawiera elementy opisujące przechwycone zdarzenia oraz ich pola. Po zatrzymaniu sesji, ponownym uruchomieniu sesji albo restarcie usługi SQL Server przechowywane zdarzenia nie stanowią trwałego archiwum.

Jak działa cykliczne nadpisywanie zdarzeń

Sesja Extended Events może przekazywać każde spełniające warunki zdarzenie do jednego lub większej liczby celów. W przypadku Ring Buffer wpis jest umieszczany w obszarze pamięci przypisanym do celu. Rozmiar tego obszaru określa parametr MAX_MEMORY celu. Gdy limit zostanie osiągnięty, SQL Server usuwa najstarsze dane w takim zakresie, aby można było zapisać kolejne zdarzenia. Oznacza to, że zawartość bufora zależy od liczby zdarzeń, ich rozmiaru oraz częstotliwości występowania, a nie od stałej liczby rekordów.

Przykładowa definicja celu może wyglądać następująco: ADD TARGET package0.ring_buffer (SET max_memory = 4096). Wartość parametru jest podawana w kilobajtach. Sam zapis nie ogranicza liczby zdarzeń do 4096, lecz określa limit pamięci celu. Jedno zdarzenie może zajmować różną ilość miejsca, ponieważ zależy to od wybranych pól, akcji oraz zawartości danych, takich jak tekst instrukcji, identyfikator sesji czy plan wykonania. Im większy i częściej generowany jest materiał diagnostyczny, tym krótszy okres historii pozostanie w buforze.

Odczyt zawartości i ograniczenia analizy

Zawartość celu Ring Buffer odczytuje się zwykle przez zapytanie do widoku sys.dm_xe_session_targets, połączone z sys.dm_xe_sessions. W kolumnie target_data znajduje się XML celu. Przykładowy odczyt może korzystać z konstrukcji CAST(target_data AS XML), a następnie z metod XML, takich jak .nodes() i .value(), aby wyodrębnić nazwę zdarzenia oraz jego pola. Nazwy elementów zależą od konfiguracji sesji, dlatego przed napisaniem zapytania trzeba sprawdzić rzeczywistą strukturę zwróconego XML.

Ring Buffer dobrze nadaje się do krótkiej obserwacji problemu, który wystąpił niedawno, na przykład błędów, blokowania, długich operacji albo nieoczekiwanych zdarzeń sesji. Nie powinien być jednak jedynym źródłem dowodów w analizie incydentu. Restart serwera, ponowne utworzenie sesji, przepełnienie bufora lub duża liczba zdarzeń może spowodować utratę informacji potrzebnych do odtworzenia przebiegu problemu. Dodatkowo odczyt danych w formacie XML wymaga poprawnego filtrowania i interpretacji znaczników. Sam fakt obecności zdarzenia w buforze nie dowodzi jeszcze przyczyny awarii; trzeba zestawić je z czasem wystąpienia, identyfikatorem sesji, tekstem polecenia i innymi dostępnymi polami.

Dobór celu do rodzaju diagnostyki

Przy krótkim, kontrolowanym śledzeniu zdarzeń Ring Buffer pozwala ograniczyć zapis do pamięci i szybko sprawdzić ostatni fragment aktywności SQL Server. Konfiguracja powinna obejmować tylko potrzebne zdarzenia, predykaty oraz akcje, ponieważ niepotrzebne pola zwiększają rozmiar wpisów i przyspieszają wypieranie starszych danych. Warto także kontrolować czas działania sesji oraz monitorować, czy jej narzut i ilość przechwytywanych informacji odpowiadają celowi diagnostycznemu.

Jeżeli wymagany jest zapis do późniejszego porównania, przekazanie pliku innemu administratorowi albo zachowanie historii po restarcie, właściwszym rozwiązaniem jest cel trwały, taki jak event_file. Ring Buffer pozostaje wtedy pomocniczym widokiem ostatnich zdarzeń, a nie repozytorium pełnej historii. Diagnostyka powinna uwzględniać również wersję SQL Server, ponieważ dostępne zdarzenia, pola, akcje i widoki mogą różnić się między wydaniami oraz między SQL Server a usługami Azure. Przy problemach z działaniem sesji należy sprawdzić, czy sesja jest uruchomiona, jaki cel został faktycznie skonfigurowany i czy odczyt wykonywany jest z właściwego widoku dynamicznego.