sql_batch_completed to zdarzenie Extended Events rejestrujące zakończenie wykonania partii poleceń T-SQL.
Rola zdarzenia sql_batch_completed w Extended Events
sql_batch_completed jest zdarzeniem dostępnym w mechanizmie Extended Events programu Microsoft SQL Server. Rejestruje zakończenie wykonania partii poleceń T-SQL przesłanej do silnika jako batch. Partią może być tekst zawierający jedno polecenie albo kilka poleceń rozdzielonych instrukcjami sterującymi, na przykład średnikami. Zdarzenie jest generowane po zakończeniu przetwarzania takiej partii, dlatego opisuje wykonanie już zakończone, a nie moment jej rozpoczęcia.
Batch nie jest tym samym co pojedyncza instrukcja SQL. Jeżeli w jednym przesłanym tekście znajduje się kilka poleceń, sql_batch_completed odnosi się do całej partii. Do obserwowania zakończeń poszczególnych instrukcji służą inne zdarzenia Extended Events, między innymi sql_statement_completed. Z kolei wywołania procedur składowanych i polecenia wykonywane przez mechanizm RPC mogą być analizowane za pomocą zdarzeń przeznaczonych dla tego typu ruchu, takich jak rpc_completed. Rozróżnienie tych zdarzeń jest konieczne, aby nie przypisać czasu całego batcha jednej instrukcji lub nie pominąć zapytań wysyłanych jako RPC.
Informacje dostępne po zakończeniu partii T-SQL
Sesja Extended Events może zapisać dla sql_batch_completed między innymi tekst wykonywanego batcha, czas trwania, zużycie czasu procesora, liczbę odczytów logicznych, liczbę odczytów fizycznych, liczbę zapisów oraz liczbę zwróconych lub przetworzonych wierszy, o ile wybrane pola są dostępne w danej wersji SQL Server i zostaną dodane do konfiguracji sesji. Znaczenie wartości zależy od konkretnego zdarzenia i wersji silnika, dlatego przed interpretacją należy sprawdzić definicję zdarzenia w katalogu systemowym Extended Events.
Do zdarzenia można również dołączyć akcje, czyli dodatkowe informacje zbierane w chwili wystąpienia zdarzenia. Przykładami są identyfikator sesji, nazwa aplikacji klienckiej, nazwa hosta, nazwa loginu, identyfikator bazy danych oraz identyfikator planu zapytania, jeżeli dana akcja jest obsługiwana przez środowisko. Akcje nie są tym samym co pola zdarzenia: dodanie ich zwiększa ilość zapisywanych danych i może wpływać na narzut obserwacji. W praktyce warto wybierać tylko informacje potrzebne do powiązania wpisu z konkretną sesją, aplikacją i bazą.
Budowa sesji i filtrowanie sql_batch_completed
Sesję można utworzyć instrukcją CREATE EVENT SESSION z użyciem pakietu sqlserver. Przykładowa konfiguracja może wyglądać następująco: CREATE EVENT SESSION monitor_batch ON SERVER ADD EVENT sqlserver.sql_batch_completed ACTION(sqlserver.session_id, sqlserver.sql_text) WHERE (duration > 1000000) ADD TARGET package0.event_file(SET filename = N'C:\XE\monitor_batch.xel'); W tym przykładzie filtr dotyczy czasu trwania, a wartość duration jest interpretowana w mikrosekundach, więc warunek oznacza partie trwające dłużej niż jedną sekundę. Lokalizacja pliku musi istnieć i być dostępna dla konta usługi SQL Server.
Po utworzeniu sesji trzeba ją uruchomić poleceniem ALTER EVENT SESSION monitor_batch ON SERVER STATE = START;. Dane mogą być zapisywane do celu event_file, który tworzy pliki XEL odczytywane przez SQL Server Management Studio albo funkcję sys.fn_xe_file_target_read_file. Do krótkiej obserwacji można użyć także celu ring_buffer, ale jego zawartość znajduje się w pamięci i jest nadpisywana po zapełnieniu bufora. Samo utworzenie sesji nie oznacza jeszcze rejestrowania zdarzeń; stan START jest wymagany, a po restarcie serwera zachowanie zależy od konfiguracji opcji STARTUP_STATE.
Interpretacja wpisów przy analizie wydajności SQL Server
Wpis sql_batch_completed potwierdza, że SQL Server zakończył obsługę określonej partii, ale sam w sobie nie wyjaśnia, dlaczego wykonanie trwało długo. Duża wartość duration może wynikać z oczekiwania na blokadę, odczytu danych z dysku, przeciążenia procesora, nieefektywnego planu wykonania albo oczekiwania na inne zasoby. Porównanie czasu trwania z cpu_time pomaga zawęzić przyczynę: wysoki czas całkowity przy relatywnie niskim czasie CPU wskazuje na oczekiwanie, natomiast wysokie obie wartości mogą wskazywać na intensywne przetwarzanie.
Analizując zdarzenia, należy uwzględnić tekst batcha, bazę danych, identyfikator sesji, aplikację oraz przedział czasu. Ten sam tekst może mieć różny czas wykonania przy innym planie, rozmiarze danych lub poziomie konkurencji. Warto zestawiać sql_batch_completed z informacjami o blokadach, oczekiwaniach i planach wykonania, ponieważ pojedynczy rekord nie stanowi pełnej diagnozy. Jeżeli batch zawiera wiele instrukcji, analiza sql_statement_completed pozwala ustalić, która z nich zużyła najwięcej czasu lub operacji wejścia-wyjścia. Przy diagnostyce komputera z uruchomionym SQL Server należy dodatkowo sprawdzić obciążenie procesora, pamięci masowej i pamięci operacyjnej, aby oddzielić problem silnika od ograniczeń sprzętowych.
