Diagnostyka rozwiązywania problemów z wydajnością bazy danych SQL w warstwie Hiperskala

Dotyczy:Azure SQL Database

Aby rozwiązać problemy z wydajnością w bazie danych w warstwie Hiperskala, ogólne metodologie dostrajania wydajności SQL są punktem początkowym każdego badania wydajności. Jednak biorąc pod uwagę architekturę rozproszoną warstwy Hiperskala, może być konieczne rozważenie dodatkowych danych diagnostycznych. W tym artykule opisano dane diagnostyczne specyficzne dla hiperskala.

Zmniejszone czasy oczekiwania na rejestrowanie zdarzeń

Każda baza danych i elastyczna pula w usłudze Azure SQL Database zarządza prędkością generowania dzienników za pośrednictwem zarządzania szybkością generowania dzienników. Limit szybkości logów jest podany w kolumnie primary_max_log_rate w sys.dm_user_db_resource_governance.

Czasami szybkość generowania dzienników w podstawowej replice obliczeniowej musi zostać zmniejszona, aby zachować umowy dotyczące poziomu usług przywracalności (SLA). Na przykład może się to zdarzyć, gdy serwer strony lub inna replika obliczeniowa jest znacznie opóźniona w stosowaniu nowych rekordów dziennika z usługi logowania. Jeśli nie ma żadnych komponentów Hyperscale, mechanizm zarządzania szybkością generowania dzienników pozwala na generowanie ich z prędkością do 150 MiB/s na bazę danych dla sprzętu serii Premium oraz sprzętu zoptymalizowanego pod kątem pamięci serii Premium. W przypadku sprzętu serii standardowej maksymalna szybkość rejestrowania wynosi 100 MiB/s na bazę danych. W przypadku elastycznych pul maksymalna szybkość rejestrowania wynosi 150 MiB/s na pulę dla sprzętu z serii Premium i serii Premium zoptymalizowanej pod kątem pamięci oraz 125 MiB/s na pulę dla innego sprzętu.

Następujące typy oczekiwania pojawiają się w sys.dm_os_wait_stats po zmniejszeniu szybkości logowania:

Typ oczekiwania	Powód
`RBIO_RG_STORAGE`	Opóźnione przetwarzanie dziennika przez serwer stron
`RBIO_RG_DESTAGE`	Opóźniona konsumpcja dzienników przez długoterminowy magazynowanie dzienników
`RBIO_RG_REPLICA`	Opóźnione użycie dziennika przez replikę wtórną HA lub nazwaną replikę
`RBIO_RG_GEOREPLICA`	Opóźnione użycie dziennika przez geograficzną replikę pomocniczą
`RBIO_RG_DESTAGE`	Opóźniona konsumpcja dziennika przez serwis dziennika
`RBIO_RG_LOCALDESTAGE`	Opóźniona konsumpcja dziennika przez serwis dziennika
`RBIO_RG_STORAGE_CHECKPOINT`	Opóźnione użycie dziennika przez serwer strony ze względu na powolny punkt kontrolny bazy danych
`RBIO_RG_MIGRATION_TARGET`	Opóźnione użycie dziennika przez bazę danych niebędącą Hiperskalą podczas migracji odwrotnej

Funkcja dynamicznego zarządzania sys.dm_hs_database_log_rate() (DMF) zawiera więcej szczegółów, aby ułatwić zrozumienie redukcji szybkości rejestrowania, jeśli istnieje. Na przykład, można określić, która replika pomocnicza jest opóźniona w stosowaniu rekordów dziennika, oraz jaki jest łączny rozmiar niezastosowanego jeszcze dziennika transakcji.

Odczyty serwera stron

Repliki obliczeniowe nie buforują pełnej kopii bazy danych lokalnie. Dane lokalne repliki obliczeniowej są przechowywane w puli buforowej (w pamięci) i w lokalnym odpornym rozszerzeniu puli buforowej (RBPEX), które zawiera podzbiór najczęściej odwiedzanych stron danych. Ta lokalna pamięć podręczna SSD jest rozmiarowana proporcjonalnie do rozmiaru obliczeniowego. Z drugiej strony każdy serwer stron ma pełną pamięć podręczną SSD dla części przechowywanej bazy danych.

Gdy odczyt operacji wejścia/wyjścia jest wykonywany na replice obliczeniowej, jeśli dane nie znajdują się w puli bufora ani w lokalnej pamięci podręcznej SSD, strona z żądanym numerem sekwencji dziennika (LSN) jest pobierana z odpowiedniego serwera stron. Odczyty z serwerów stron są zdalne i są wolniejsze niż odczyty z lokalnej pamięci podręcznej SSD. Podczas rozwiązywania problemów z wydajnością związanych z operacjami we/wy musimy określić, ile operacji we/wy zostało wykonanych za pośrednictwem stosunkowo wolniejszego odczytu serwera stron.

Kilka dynamicznych widoków zarządzanych (DMV) i zdarzeń rozszerzonych mają kolumny i pola, które określają liczbę zdalnych odczytów z serwera stron, które można porównać z łączną liczbą odczytów. Magazyn zapytań przechwytuje również odczyty serwera stron w statystykach wykonywania zapytań.

Kolumny do odczytu raportów serwera stron są dostępne we widokach DMV wykonywania i widokach katalogu.
Pola odczytu serwera stron mogą być znalezione w poniższych zdarzeniach rozszerzonych:
- sql_statement_completed
- sp_statement_completed
- sql_batch_completed
- rpc_completed
- scan_stopped
- query_store_begin_persist_runtime_stat
- query_store_execution_runtime_info
ActualPageServerReads / ActualPageServerReadAheads atrybuty znajdują się w kodzie XML planu zapytania dla planów obejmujących statystyki środowiska uruchomieniowego. Przykład:
```
<RunTimeCountersPerThread Thread="8" ActualRows="90466461" [...] ActualPageServerReads="0" ActualPageServerReadAheads="5687297" ActualLobPageServerReads="0" ActualLobPageServerReadAheads="0" />
```
Napiwek

Aby wyświetlić te atrybuty w oknie właściwości planu zapytania, wymagany jest program SSMS 18.3 lub nowszy.

Statystyki plików wirtualnych i ewidencjonowanie operacji we/wy

W usłudze Azure SQL Database sys.dm_io_virtual_file_stats() DMF jest jednym z metod monitorowania statystyk operacji we/wy bazy danych, takich jak liczba operacji na sekundę (IOPS), przepływność i opóźnienia. Właściwości we/wy w hiperskali różnią się ze względu na jej rozproszoną architekturę . W tej sekcji koncentrujemy się na operacjach wejścia/wyjścia (I/O), jak pokazano w tym DMF.

W przypadku warstwy Hiperskala odpowiednie dane w pliku sys.dm_io_virtual_file_stats() są następujące:

Wiersze, w których wartość database_id jest zgodna z wartością zwracaną przez funkcję DB_ID, a wartość file_id nie wynosi 2, odnoszą się do serwerów stron. Często każdy wiersz odpowiada jednemu serwerowi strony. Jednak w przypadku większych plików używane są liczne serwery stron.
- Wiersz z file_id 2 odpowiada dziennikowi transakcji.
Wiersze, w których wartość w database_id kolumnie wynosi 0, odpowiadają lokalnej pamięci podręcznej SSD w replice obliczeniowej.

Użycie lokalnej pamięci podręcznej SSD

Ponieważ lokalna pamięć podręczna SSD istnieje w tej samej replice obliczeniowej, w której aparat bazy danych przetwarza zapytania, operacje we/wy względem tej pamięci podręcznej są szybsze niż we/wy względem serwerów stron. W bazie danych hiperskali lub elastycznej puli sys.dm_io_virtual_file_stats() ma specjalne wiersze raportujące statystyki I/O dla lokalnej pamięci podręcznej SSD. Te wiersze mają wartość 0 dla kolumny database_id . Na przykład następujące zapytanie zwraca statystyki operacji we/wy lokalnej pamięci podręcznej SSD od momentu uruchomienia bazy danych.

SELECT *
FROM sys.dm_io_virtual_file_stats(0, NULL);

Współczynnik zagregowanych odczytów z lokalnych plików pamięci podręcznej SSD do zagregowanych odczytów ze wszystkich innych plików danych jest współczynnik trafień lokalnej pamięci podręcznej SSD. Ta metryka jest dostarczana przez liczniki wydajności RBPEX cache hit ratio i RBPEX cache hit ratio base dostępne w DMV sys.dm_os_performance_counters.

Odczyty danych

Gdy odczyty są wykonywane przez silnik bazy danych na replice obliczeniowej, mogą być realizowane przy użyciu lokalnej pamięci podręcznej SSD, serwerów stron lub kombinacji tych dwóch, jeśli odczytywanych jest wiele stron.
Gdy replika obliczeniowa odczytuje niektóre strony z określonego pliku danych (na przykład plik z wartością file_id 1), jeśli te dane znajdują się wyłącznie w lokalnej pamięci podręcznej SSD, wszystkie operacje we/wy dla tego odczytu są uwzględniane w lokalnych plikach pamięci podręcznej SSD, gdzie database_id wynosi 0. Jeśli część danych znajduje się w lokalnej pamięci podręcznej SSD, a część znajduje się na serwerach stron, operacje we/wy są uwzględniane częściowo na rzecz lokalnych plików pamięci podręcznej SSD, oraz częściowo na plików danych odpowiadających serwerom stron.
Gdy replika obliczeniowa żąda strony na określonym LSN z serwera strony, jeśli serwer strony nie jest jeszcze na tym poziomie LSN, odczyt w replice obliczeniowej czeka, aż serwer strony osiągnie ten LSN, zanim strona zostanie zwrócona. W przypadku dowolnego odczytu z serwera stron w replice obliczeniowej zobaczysz typ oczekiwania PAGEIOLATCH_*, jeśli oczekuje na to I/O. W warstwie Hiperskala ten czas oczekiwania obejmuje zarówno czas nadrobienia zaległości żądanej strony na serwerze strony do wymaganej nazwy LSN, jak i czasu potrzebnego do przeniesienia strony z serwera stron do repliki obliczeniowej.
Duże operacje odczytu, takie jak odczyty z wyprzedzeniem, są często wykonywane przy użyciu odczytów zbieranych punktowo. Umożliwia to odczyt do 4 MB jako pojedyncza operacja odczytu I/O. Jednak gdy odczytywane dane znajdują się w lokalnej pamięci podręcznej SSD, te odczyty są uwzględniane jako wiele pojedynczych odczytów 8-KB, ponieważ pula buforu i lokalna pamięć podręczna SSD zawsze używają stron 8-KB. W rezultacie liczba odczytów we/wy z lokalnej pamięci podręcznej SSD może być większa niż rzeczywista liczba operacji we/wy wykonanych przez silnik.

Zapisy danych

Podstawowa replika obliczeniowa nie zapisuje bezpośrednio na serwerach stron. Zamiast tego rekordy dzienników z usługi dziennika są odtwarzane na odpowiednich serwerach stron.
Zapisy w replice obliczeniowej są głównie zapisywane w lokalnej pamięci podręcznej SSD (database_id 0). Dla zapisów większych niż 8 KB, czyli realizowanych za pomocą zapisu, każdy zapis jest tłumaczony na wiele pojedynczych zapisów o rozmiarze 8 KB w buforze lokalnej pamięci podręcznej SSD, ponieważ zarówno pula buforowa, jak i lokalna pamięć podręczna SSD zawsze korzystają z 8 KB stron. W związku z tym liczba operacji wejścia/wyjścia zapisu widocznych w lokalnej pamięci podręcznej SSD może być większa niż rzeczywista liczba operacji wejścia/wyjścia wykonywanych przez aparat.
Pliki danych inne niż database_id 0, które odpowiadają serwerom stron, mogą również wyświetlać zapisy. W warstwie Hyperscale te operacje zapisu są symulowane, ponieważ repliki obliczeniowe nigdy nie zapisują bezpośrednio do serwerów stron. Statystyki we/wy są uwzględniane w miarę ich występowania w repliki obliczeniowej. IOPS (operacje we/wy na sekundę), przepływność i opóźnienie widoczne na replice obliczeniowej dla plików danych innych niż database_id 0 nie odzwierciedlają rzeczywistych statystyk operacji we/wy zapisów na serwerach stron.

Zapisy dziennika

W podstawowej repliki obliczeniowej zapisy dziennika są uwzględniane w sys.dm_io_virtual_file_stats() pod file_id 2.
W przeciwieństwie do grup dostępności, gdy transakcja zostanie zatwierdzona na podstawowej replice obliczeniowej, rekordy dziennika nie są utrwalane na replice pomocniczej. W Hyperscale dziennik jest utrwalany w usłudze dziennikowej, a następnie asynchronicznie stosowany do replik pomocniczych. Ponieważ zapisy dziennika nie są rzeczywiście wykonywane na replikach pomocniczych, więc ewidencjonowanie operacji we/wy dziennika w sys.dm_io_virtual_file_stats() na replikach pomocniczych nie powinno być używane jako statystyki operacji we/wy dziennika transakcji.

Dane we/wy w statystykach wykorzystania zasobów

W bazie danych innej niż Hiperskala, łącznie operacje we/wy odczytu i zapisu względem plików danych w odniesieniu do limitu IO danych określonego przez ład zasobów są zgłaszane w widokach sys.dm_db_resource_stats i sys.resource_stats w kolumnie avg_data_io_percent. Odpowiednie DMVs dla pul elastycznych to sys.dm_elastic_pool_resource_stats i sys.elastic_pool_resource_stats. Te same wartości są zgłaszane jako Procent operacji we/wy danych metryk usługi Azure Monitor dla baz danych i pul elastycznych.

W bazie danych w warstwie Hiperskala, te kolumny i metryki raportują o wykorzystaniu IO danych względem limitu dla lokalnego magazynu SSD tylko w replice obliczeniowej. Obejmuje to operacje I/O względem lokalnej pamięci podręcznej SSD i tempdb bazy danych. Wartość 100% w tej kolumnie wskazuje, że nadzór nad zasobami ogranicza liczbę operacji we/wy na sekundę magazynu lokalnego. Jeśli jest to skorelowane z problemem z wydajnością, dostosuj obciążenie, aby generować mniej operacji we/wy, lub zwiększ rozmiar mocy obliczeniowej, aby zwiększyć zarządzanie zasobami, maksymalną liczbę operacji we/wy na sekundę , limit. W przypadku zarządzania zasobami lokalnych operacji odczytu i zapisu w pamięci podręcznej SSD, system zlicza pojedyncze operacje danych we/wy 8 KB, a nie większe operacje, które mogą być obsługiwane przez silnik bazy danych.

Operacje wejścia/wyjścia danych względem serwerów stron nie są zgłaszane w widokach wykorzystania zasobów ani za pośrednictwem metryk usługi Azure Monitor, ale są zgłaszane w sys.dm_io_virtual_file_stats(), jak opisano wcześniej.

Sprzężenie zwrotne

Czy ta strona była pomocna?

Last updated on 2025-11-05