Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dotyczy:
programu SQL Server
Aspekt wydajności zawsze włączonych grup dostępności ma kluczowe znaczenie dla utrzymania umowy dotyczącej poziomu usług (SLA) dla baz danych o krytycznym znaczeniu. Zrozumienie sposobu, w jaki grupy dostępności przesyłają dzienniki do replik pomocniczych, może pomóc w oszacowaniu celu czasu odzyskiwania (RTO) i celu punktu odzyskiwania (RPO) w ramach implementacji dostępności oraz w identyfikacji wąskich gardeł w źle działających grupach dostępności czy replikach. W tym artykule opisano proces synchronizacji, pokazano, jak obliczyć niektóre kluczowe metryki i podano linki do niektórych typowych scenariuszy rozwiązywania problemów z wydajnością.
Proces synchronizacji danych
Aby oszacować czas pełnej synchronizacji i zidentyfikować wąskie gardło, musisz zrozumieć proces synchronizacji. Wąskie gardło wydajności może znajdować się w dowolnym miejscu procesu, a jego znalezienie może pomóc w zgłębianiu ukrytych problemów. Na poniższej ilustracji i tabeli przedstawiono proces synchronizacji danych:
| Kolejność | Opis kroku | Komentarze | Przydatne metryki |
|---|---|---|---|
| 1 | Generowanie dziennika | Dane dziennika są opróżniane na dysk. Ten dziennik musi być replikowany do replik zapasowych. Rekordy dziennika wprowadzają kolejkę wysyłania. | SQL Server:Database > Bajty dziennika spłukane na sekundę |
| 2 | Uchwycić | Dzienniki dla każdej bazy danych są przechwytywane i wysyłane do odpowiedniej kolejki partnera (jedna na parę repliki bazy danych). Ten proces przechwytywania działa nieprzerwanie, o ile replika dostępności jest połączona, a przenoszenie danych nie jest zawieszone z jakiegokolwiek powodu, a para replika-baza danych jest wyświetlana jako synchronizowanie lub zsynchronizowane. Jeśli proces przechwytywania nie jest w stanie skanować i kolejkować komunikatów wystarczająco szybko, kolejka wysyłania dzienników zaczyna się gromadzić. |
SQL Server:Availability Replica > Bajty wysłane do repliki na sekundę, co stanowi zagregowaną sumę wszystkich komunikatów bazy danych znajdujących się w kolejce dla tej repliki dostępności. log_send_queue_size (KB) i log_bytes_send_rate (KB/s) w repliki podstawowej. |
| 3 | Wyślij | Komunikaty w każdej kolejce repliki bazy danych są odsyłane i wysyłane przez sieć do odpowiedniej repliki pomocniczej. | SQL Server:Replika dostępności > Bajty wysyłane do transportu/s |
| 4 | Odbieranie i buforowanie | Każda replika pomocnicza odbiera i buforuje komunikat. | Licznik wydajności SQL Server: Replika dostępności > Bajty logu odebrane/s |
| 5 | Utwardzać | Dziennik jest opróżniany na replice zapasowej w celu utrwalenia danych. Po opróżnieniu dziennika potwierdzenie jest wysyłane z powrotem do repliki podstawowej. Po wzmocnieniu logu unika się utraty danych. |
Licznik wydajności programu SQL Server:Baza danych > Bajty dziennika opróżnione/s Typ oczekiwania HADR_LOGCAPTURE_SYNC |
| 6 | Ponowić | Przeprowadź ponownie wyczyszczone strony na repliki wtórnej. Strony są przechowywane w kolejce do powtórnego przetwarzania, gdy czekają na ponowne wykonanie. |
SQL Server:Replika bazy danych > Redone bajty/s redo_queue_size (KB) i redo_rate. Typ oczekiwania REDO_SYNC |
Bramy sterowania przepływem
Grupy dostępności są zaprojektowane z bramami sterowania przepływem na głównej replice, aby uniknąć nadmiernego zużycia zasobów, takich jak zasoby sieciowe i pamięci, na wszystkich replikach dostępnościowych. Te bramy sterowania przepływem nie wpływają na stan zdrowia synchronizacji replik dostępności, ale mogą wpływać na wydajność całych baz danych dostępności, w tym RPO.
Po przechwyceniu dzienników na replice podstawowej podlegają one dwóm poziomom kontroli przepływu. Po osiągnięciu progu wiadomości którejkolwiek bramy, komunikaty dziennika nie są już wysyłane do określonej repliki ani do określonej bazy danych. Komunikaty mogą być wysyłane po odebraniu komunikatów potwierdzenia dla wysłanych komunikatów w celu ograniczenia liczby wysłanych komunikatów poniżej progu.
Oprócz bram sterowania przepływem istnieje inny czynnik, który może uniemożliwić wysyłanie komunikatów dziennika. Synchronizacja replik gwarantuje, że komunikaty są wysyłane i stosowane w kolejności numerów sekwencji dziennika (LSN). Przed wysłaniem komunikatu dziennika jego numer LSN jest również sprawdzany względem najniższego potwierdzonego numeru LSN, aby upewnić się, że jest mniejszy niż jeden z progów (w zależności od typu komunikatu). Jeśli różnica między dwiema liczbami LSN jest większa niż próg, komunikaty nie są wysyłane. Gdy różnica ponownie przekroczy próg, komunikaty zostaną wysłane.
Program SQL Server 2022 zwiększa limity liczby komunikatów dozwolonych przez każdą bramę. Korzystając z flagi śledzenia 12310, zwiększony limit jest również dostępny dla następujących wersji programu SQL Server, począwszy od: SQL Server 2019 CU9, SQL Server 2017 CU18 i SQL Server 2016 SP1 CU16.
W poniższej tabeli porównaliśmy limity komunikatów:
SQL Server 2022 i obsługiwane wersje programu SQL Server (począwszy od programu SQL Server 2019 CU9, SQL Server 2017 CU18 i SQL Server 2016 SP1 CU16), które włączają flagę śledzenia 12310, mają następujące ograniczenia:
| Poziom | Liczba bram | Liczba komunikatów | Przydatne metryki |
|---|---|---|---|
| Transport | 1 na replikę awaryjną | 16384 | Zdarzenie rozszerzone database_transport_flow_control_action |
| Baza danych | 1 na bazę danych dostępności | 7168 |
DBMIRROR_SEND Zdarzenia rozszerzone hadron_database_flow_control_action |
Dwa przydatne liczniki wydajności, SQL Server: replika dostępności > Sterowanie przepływem/s i SQL Server:Dostępność Replika > Czas sterowania przepływem (ms/s), pokazują, w ciągu ostatniej sekundy, ile razy kontrola przepływu została aktywowana i ile czasu spędziliśmy na oczekiwaniu na sterowanie przepływem. Wyższy czas oczekiwania w sterowaniu przepływem przekłada się na wyższy RPO. Aby uzyskać więcej informacji na temat typów problemów, które mogą powodować długi czas oczekiwania w sterowaniu przepływem, zobacz Rozwiązywanie problemów: grupa dostępności przekroczyła cel punktu odzyskiwania.
Szacowanie czasu przełączania awaryjnego (RTO)
RTO w umowie SLA zależy od czasu przejścia w tryb failover implementacji Always On w danym momencie, co można wyrazić za pomocą następującej formuły:
Grupy dostępności obliczanie celu czasu odzyskiwania 
Ważny
Jeśli grupa dostępności zawiera więcej niż jedną bazę danych dostępności, to baza danych dostępności o najwyższym poziomie Tfailover stanie się czynnikiem ograniczającym zgodność z celem czasu odzyskiwania (RTO).
Czas wykrywania błędów, Tdetection, to czas potrzebny systemowi na wykrycie błędu. Ten czas zależy od ustawień na poziomie klastra, a nie od poszczególnych replik dostępności. W zależności od skonfigurowanego warunku automatycznego przełączenia awaryjnego, można wyzwolić przełączenie awaryjne jako natychmiastową odpowiedź na krytyczny błąd wewnętrzny programu SQL Server, taki jak osierocone spinlocki. W takim przypadku wykrywanie może nastąpić tak szybko, jak szybko raport o błędach sp_server_diagnostics (Transact-SQL) zostanie wysłany do klastra WSFC (domyślny interwał to 1/3 limitu czasu sprawdzania kondycji). Można również wyzwolić przełączenie awaryjne z powodu przekroczenia limitu czasu, na przykład przekroczenia limitu czasu sprawdzania kondycji klastra (domyślnie 30 sekund) lub kiedy dzierżawa między biblioteką DLL zasobu a wystąpieniem programu SQL Server wygasła (domyślnie 20 sekund). W takim przypadku czas wykrywania jest tak długi, jak interwał limitu czasu. Aby uzyskać więcej informacji, zobacz elastyczne zasady przełączania awaryjnego dotyczące automatycznego failoveru grupy dostępności (SQL Server).
Jedyną rzeczą, którą replika pomocnicza musi wykonać, aby przygotować się do przejścia w tryb failover, jest ponowne przygotowanie do końca dziennika. Czas ponownego wykonania, Tredo, jest obliczany przy użyciu następującej formuły:
gdzie redo_queue jest wartością w redo_queue_size, a redo_rate jest wartością w redo_rate.
Czas pracy w trybie failover, Toverhead, obejmuje czas potrzebny na przełączenie klastra WSFC w tryb failover i przełączenie baz danych w tryb online. Ten czas jest zwykle krótki i stały.
Szacowanie potencjalnej utraty danych (RPO)
Cel RPO w Twoim SLA zależy od możliwej utraty danych we wdrożeniu Always On w dowolnym momencie. Tę możliwą utratę danych można wyrazić w następującej formule:
gdzie log_send_queue to wartość log_send_queue_size, a szybkość generowania dziennika to wartość SQL Server:Database > Bajty zapisane do dziennika na sekundę.
Ostrzeżenie
Jeśli grupa dostępności zawiera więcej niż jedną bazę danych dostępności, to baza danych dostępności o najwyższym Tdata_loss staje się wartością ograniczającą dla zgodności z RPO.
Kolejka wysyłania dziennika reprezentuje wszystkie dane, które mogą zostać utracone z powodu katastrofalnego błędu. Na pierwszy rzut oka ciekawym jest, że szybkość generowania dziennika jest używana zamiast szybkości wysyłania dziennika (zobacz log_send_rate). Należy jednak pamiętać, że użycie szybkości wysyłania dziennika daje tylko czas na synchronizację, podczas gdy RPO mierzy utratę danych na podstawie szybkości generowania, a nie na podstawie szybkości synchronizacji.
Najprostszym sposobem oszacowania Tdata_loss jest użycie last_commit_time. Dynamiczny widok zarządzania w repliki podstawowej zgłasza tę wartość dla wszystkich replik. Możesz obliczyć różnicę między wartością repliki podstawowej a wartością repliki pomocniczej, aby oszacować, jak szybko dziennik w repliki pomocniczej nadrabia zaległości w repliki podstawowej. Jak wspomniano wcześniej, to obliczenie nie informuje o potencjalnej utracie danych na podstawie szybkości generowania dziennika, ale powinno to być bliskie przybliżenie.
Szacowanie RTO & i RPO za pomocą pulpitu nawigacyjnego SSMS
W grupach dostępności Always On, czas przywracania (RTO) i cel punktu odzyskiwania (RPO) są obliczane i wyświetlane dla baz danych hostowanych na replikach zapasowych. Na pulpicie repliki podstawowej, wartości RTO i RPO są grupowane według repliki drugorzędnej.
Aby wyświetlić RTO i RPO na pulpicie nawigacyjnym, wykonaj następujące czynności:
W programie SQL Server Management Studio rozwiń węzeł Zawsze włączona wysoka dostępność, kliknij prawym przyciskiem myszy nazwę grupy dostępności i wybierz pozycję Pokaż pulpit nawigacyjny.
Wybierz pozycję Dodaj/Usuń kolumny na karcie Grupuj według. Sprawdź oba szacowany czas przywracania (w sekundach) [RTO] i szacowany czas utraty danych [RPO].
Obliczanie pomocniczej wartości czasu odzyskiwania bazy danych
Obliczenie czasu odzyskiwania określa, ile czasu jest potrzebne do odzyskania pomocniczej bazy danych po przejściu w tryb failover. Czas przełączenia awaryjnego jest zwykle krótki i stały. Czas wykrywania zależy od ustawień na poziomie klastra, a nie od poszczególnych replik dostępności.
W przypadku pomocniczej bazy danych (DB_sec) obliczenie i wyświetlenie jej docelowego czasu odzyskiwania opiera się na redo_queue_size i redo_rate:
Z wyjątkiem przypadków szczególnych, formuła do obliczenia RTO (czasu odzyskiwania) pomocniczej bazy danych to:
Obliczanie RPO dla pomocniczej bazy danych
W przypadku pomocniczej bazy danych (DB_sec), obliczanie i wyświetlanie jej celu punktu odzyskiwania (RPO) opiera się na parametrach is_failover_ready, last_commit_time oraz last_commit_time skorelowanej podstawowej bazy danych (DB_pri). Gdy pomocniczy database.is_failover_ready = 1, daa jest synchronizowany i nie nastąpi utrata danych po przejściu w tryb failover. Jeśli jednak ta wartość to 0, istnieje różnica między last_commit_time w podstawowej bazie danych a last_commit_time w pomocniczej bazie danych.
W przypadku podstawowej bazy danych last_commit_time jest czasem, kiedy została zatwierdzona najnowsza transakcja. W przypadku pomocniczej bazy danych last_commit_time oznacza czas ostatniego zatwierdzenia transakcji w podstawowej bazie danych, która została również pomyślnie zabezpieczona i uwierzytelniona w pomocniczej bazie danych. Ta liczba powinna być taka sama zarówno dla podstawowej, jak i pomocniczej bazy danych. Różnica między tymi dwiema wartościami to okres, w którym oczekujące transakcje nie zostały utrwalone w pomocniczej bazie danych i zostaną utracone w przypadku przełączenia awaryjnego.
Liczniki wydajności używane w formułach docelowego czasu odzyskiwania/docelowego punktu odzyskiwania
- redo_queue_size (KB) [używane w RTO]: Rozmiar kolejki redo to rozmiar dzienników transakcji między last_received_lsn a last_redone_lsn. last_received_lsn to identyfikator bloku dziennika, który wskazuje punkt, do którego wszystkie bloki dziennika zostały odebrane przez replikę pomocniczą hostującą tę bazę danych. Last_redone_lsn to numer sekwencji dziennika ostatniego rekordu dziennika, który został ponownie zapisany w pomocniczej bazie danych. Na podstawie tych dwóch wartości można znaleźć identyfikatory początkowego bloku dziennika (last_received_lsn) i blok dziennika końcowego (last_redone_lsn). Odstęp między tymi dwoma blokami dziennika może reprezentować, ile bloków dziennika transakcji jeszcze nie zostało ponownie przetworzonych. Jest to mierzone w kilobajtach (KB).
- redo_rate (KB/s) [używane wRTO ]: wartość kumulatywna, która pokazuje, ile dziennika transakcji (KB) zostało odtworzone na pomocniczej bazie danych w Kilobajtach (KB)/sekunda w ciągu danego okresu czasu.
- last_commit_time (data/godzina) [w użyciu do RPO]: W przypadku podstawowej bazy danych last_commit_time oznacza godzinę zatwierdzenia najnowszej transakcji. W przypadku pomocniczej bazy danych last_commit_time jest najnowszym czasem zatwierdzenia transakcji w podstawowej bazie danych, która została pomyślnie utrwalona w pomocniczej bazie danych. Ponieważ ta wartość dla sekundarnej powinna być zsynchronizowana z tą samą wartością w pierwotnej, każda różnica między tymi dwiema wartościami stanowi oszacowanie utraty danych (RPO).
Szacowanie celu czasu odzyskiwania (RTO) i celu punktu odzyskiwania (RPO) przy użyciu widoków dynamicznych zarządzania (DMV)
Istnieje możliwość wykonywania zapytań do widoków dynamicznych zarządzania sys.dm_hadr_database_replica_states i sys.dm_hadr_database_replica_cluster_states w celu oszacowania celu punktu odzyskania (RPO) i czasu do osiągnięcia odzyskania (RTO) bazy danych. Poniższe zapytania tworzą procedury składowane, które umożliwiają wykonanie obu tych czynności.
Notatka
Upewnij się, że najpierw utworzysz i uruchomisz procedurę składowaną, aby oszacować cel czasu odzyskiwania, ponieważ wartości, które generuje, są konieczne do uruchomienia procedury składowanej do szacowania celu punktu odzyskiwania.
Utwórz procedurę składową do oszacowania czasu odbudowy (RTO)
- W docelowej repliki wtórnej utwórz procedurę składowaną proc_calculate_RTO. Jeśli ta procedura składowana już istnieje, usuń ją najpierw, a następnie utwórz ją ponownie.
if object_id(N'proc_calculate_RTO', 'p') is not null
drop procedure proc_calculate_RTO
go
raiserror('creating procedure proc_calculate_RTO', 0,1) with nowait
go
--
-- name: proc_calculate_RTO
--
-- description: Calculate RTO of a secondary database.
--
-- parameters: @secondary_database_name nvarchar(max): name of the secondary database.
--
-- security: this is a public interface object.
--
create procedure proc_calculate_RTO
(
@secondary_database_name nvarchar(max)
)
as
begin
declare @db sysname
declare @is_primary_replica bit
declare @is_failover_ready bit
declare @redo_queue_size bigint
declare @redo_rate bigint
declare @replica_id uniqueidentifier
declare @group_database_id uniqueidentifier
declare @group_id uniqueidentifier
declare @RTO float
select
@is_primary_replica = dbr.is_primary_replica,
@is_failover_ready = dbcs.is_failover_ready,
@redo_queue_size = dbr.redo_queue_size,
@redo_rate = dbr.redo_rate,
@replica_id = dbr.replica_id,
@group_database_id = dbr.group_database_id,
@group_id = dbr.group_id
from sys.dm_hadr_database_replica_states dbr join sys.dm_hadr_database_replica_cluster_states dbcs on dbr.replica_id = dbcs.replica_id and
dbr.group_database_id = dbcs.group_database_id where dbcs.database_name = @secondary_database_name
if @is_primary_replica is null or @is_failover_ready is null or @redo_queue_size is null or @replica_id is null or @group_database_id is null or @group_id is null
begin
print 'RTO of Database '+ @secondary_database_name +' is not available'
return
end
else if @is_primary_replica = 1
begin
print 'You are visiting wrong replica';
return
end
if @redo_queue_size = 0
set @RTO = 0
else if @redo_rate is null or @redo_rate = 0
begin
print 'RTO of Database '+ @secondary_database_name +' is not available'
return
end
else
set @RTO = CAST(@redo_queue_size AS float) / @redo_rate
print 'RTO of Database '+ @secondary_database_name +' is ' + convert(varchar, ceiling(@RTO))
print 'group_id of Database '+ @secondary_database_name +' is ' + convert(nvarchar(50), @group_id)
print 'replica_id of Database '+ @secondary_database_name +' is ' + convert(nvarchar(50), @replica_id)
print 'group_database_id of Database '+ @secondary_database_name +' is ' + convert(nvarchar(50), @group_database_id)
end
- Uruchom proc_calculate_RTO z docelową nazwą pomocniczej bazy danych:
exec proc_calculate_RTO @secondary_database_name = N'DB_sec'
W danych wyjściowych wyświetlana jest wartość RTO docelowej repliki pomocniczej bazy danych. Zapisz group_id, replica_idi group_database_id do użycia z procedurą składowaną szacowania RPO.
Przykładowe dane wyjściowe:
Czas odzyskiwania (RTO) bazy danych DB_sec wynosi 0
group_id bazy danych DB4 jest F176DD65-C3EE-4240-BA23-EA615F965C9B
Replica_id bazy danych serwera DB4 to 405554F6-3FDC-4593-A650-2067F5FABFFD
ID grupy bazy danych DB4 to 39F7942F-7B5E-42C5-977D-02E7FFA6C392
Utwórz procedurę składowaną w celu oszacowania RPO
- W repliki podstawowej utwórz procedurę składowaną proc_calculate_RPO. Jeśli już istnieje, usuń go najpierw, a następnie utwórz go ponownie.
if object_id(N'proc_calculate_RPO', 'p') is not null
drop procedure proc_calculate_RPO
go
raiserror('creating procedure proc_calculate_RPO', 0,1) with nowait
go
--
-- name: proc_calculate_RPO
--
-- description: Calculate RPO of a secondary database.
--
-- parameters: @group_id uniqueidentifier: group_id of the secondary database.
-- @replica_id uniqueidentifier: replica_id of the secondary database.
-- @group_database_id uniqueidentifier: group_database_id of the secondary database.
--
-- security: this is a public interface object.
--
create procedure proc_calculate_RPO
(
@group_id uniqueidentifier,
@replica_id uniqueidentifier,
@group_database_id uniqueidentifier
)
as
begin
declare @db_name sysname
declare @is_primary_replica bit
declare @is_failover_ready bit
declare @is_local bit
declare @last_commit_time_sec datetime
declare @last_commit_time_pri datetime
declare @RPO nvarchar(max)
-- secondary database's last_commit_time
select
@db_name = dbcs.database_name,
@is_failover_ready = dbcs.is_failover_ready,
@last_commit_time_sec = dbr.last_commit_time
from sys.dm_hadr_database_replica_states dbr join sys.dm_hadr_database_replica_cluster_states dbcs on dbr.replica_id = dbcs.replica_id and
dbr.group_database_id = dbcs.group_database_id where dbr.group_id = @group_id and dbr.replica_id = @replica_id and dbr.group_database_id = @group_database_id
-- correlated primary database's last_commit_time
select
@last_commit_time_pri = dbr.last_commit_time,
@is_local = dbr.is_local
from sys.dm_hadr_database_replica_states dbr join sys.dm_hadr_database_replica_cluster_states dbcs on dbr.replica_id = dbcs.replica_id and
dbr.group_database_id = dbcs.group_database_id where dbr.group_id = @group_id and dbr.is_primary_replica = 1 and dbr.group_database_id = @group_database_id
if @is_local is null or @is_failover_ready is null
begin
print 'RPO of database '+ @db_name +' is not available'
return
end
if @is_local = 0
begin
print 'You are visiting wrong replica'
return
end
if @is_failover_ready = 1
set @RPO = '00:00:00'
else if @last_commit_time_sec is null or @last_commit_time_pri is null
begin
print 'RPO of database '+ @db_name +' is not available'
return
end
else
begin
if DATEDIFF(ss, @last_commit_time_sec, @last_commit_time_pri) < 0
begin
print 'RPO of database '+ @db_name +' is not available'
return
end
else
set @RPO = CONVERT(varchar, DATEADD(ms, datediff(ss ,@last_commit_time_sec, @last_commit_time_pri) * 1000, 0), 114)
end
print 'RPO of database '+ @db_name +' is ' + @RPO
end
- Wykonaj proc_calculate_RPO z docelowej bazy danych group_id, replica_idi group_database_id.
exec proc_calculate_RPO @group_id= 'F176DD65-C3EE-4240-BA23-EA615F965C9B',
@replica_id = '405554F6-3FDC-4593-A650-2067F5FABFFD',
@group_database_id = '39F7942F-7B5E-42C5-977D-02E7FFA6C392'
- Dane wyjściowe wyświetlają wartość RPO docelowej repliki pomocniczej bazy danych.
Monitorowanie celu czasu odzyskiwania (RTO) i celu punktu odzyskiwania (RPO)
W tej sekcji pokazano, jak monitorować grupy dostępności dla metryk RTO (cel czasu odzyskiwania) i RPO (cel punktu odzyskiwania). Ten pokaz jest podobny do samouczka GUI przedstawionego w modelu zdrowia Always On, część 2: Rozszerzanie modelu zdrowia.
Elementy czasu przełączania awaryjnego i potencjalnej utraty danych w szacowanie czasu przełączania awaryjnego (RTO) oraz szacowanie potencjalnej utraty danych (RPO) są wygodnie udostępniane jako metryki wydajności w aspekcie zarządzania zasadami Stan repliki bazy danych (zobacz Wyświetlanie aspektów zarządzania opartych na zasadach na obiekcie programu SQL Server). Te dwie metryki można monitorować zgodnie z harmonogramem i otrzymywać alerty, gdy metryki przekraczają odpowiednio RTO (cel czasu odzyskiwania) i RPO (cel punktu odzyskiwania).
Przedstawione skrypty tworzą dwie zasady systemowe, które są uruchamiane zgodnie z ich harmonogramami, z następującymi cechami:
Polityka RTO, która kończy się niepowodzeniem, gdy szacowany czas przełączenia awaryjnego przekracza 10 minut, oceniana co 5 minut.
Polityka RPO, która kończy się niepowodzeniem, gdy szacowana utrata danych przekracza 1 godzinę, oceniana co 30 minut.
Te dwie polityki mają identyczną konfigurację na wszystkich replikach dostępności
Zasady są oceniane na wszystkich serwerach, ale tylko w grupach dostępności, dla których replika dostępności lokalnej jest repliką podstawową. Jeśli lokalna replika dostępności nie jest repliką podstawową, zasady nie są oceniane.
Na pulpicie nawigacyjnym Always On są wygodnie wyświetlane błędy zasad podczas wyświetlania ich na replice podstawowej.
Aby utworzyć zasady, wykonaj poniższe instrukcje na wszystkich instancjach serwera, które uczestniczą w grupie dostępności.
uruchom usługę SQL Server Agent, jeśli nie została jeszcze uruchomiona.
W SQL Server Management Studio z menu Tools kliknij Opcje.
Na karcie Always On programu SQL Server wybierz pozycję Włącz zasady Always On zdefiniowane przez użytkownika i kliknij przycisk OK.
To ustawienie umożliwia wyświetlanie prawidłowo skonfigurowanych zasad niestandardowych na pulpicie nawigacyjnym Always On Dashboard.
Utwórz warunek zarządzania opartego na zasadach przy użyciu następujących specyfikacji:
Nazwa:
RTOSkładowa: stan repliki bazy danych
pól:
Add(@EstimatedRecoveryTime, 60)operator : <=
wartość:
600
Ten warunek kończy się niepowodzeniem, gdy potencjalny czas przejścia w tryb failover przekracza 10 minut, w tym 60 sekund na potrzeby wykrywania awarii i pracy w trybie failover.
Utwórz drugi warunek zarządzania oparty na zasadach przy użyciu następujących specyfikacji:
nazwa:
RPOFacet: Stan repliki bazy danych
pól:
@EstimatedDataLossoperator : <=
wartość:
3600
Ten warunek kończy się niepowodzeniem, gdy potencjalna utrata danych przekracza 1 godzinę.
Utwórz trzeci warunek zarządzania oparty na zasadach przy użyciu następujących specyfikacji:
nazwa:
IsPrimaryReplicaFacet: grupy dostępności
pól:
@LocalReplicaRoleoperator: =
wartość:
Primary
Ten warunek sprawdza, czy lokalna replika dostępności dla danej grupy dostępności jest repliką podstawową.
Utwórz zasady zarządzania oparte na zasadach przy użyciu następujących specyfikacji:
strona Ogólne:
nazwa:
CustomSecondaryDatabaseRTOsprawdź warunek:
RTOPrzeciwko celom: Każdy stan repliki bazy danych w IsPrimaryReplica GrupaDostępności
To ustawienie zapewnia, że zasady są oceniane tylko w grupach dostępności, dla których replika dostępności lokalnej jest repliką podstawową.
tryb oceny: Zgodnie z harmonogramem
Harmonogram: CollectorSchedule_Every_5min
włączone: wybrana
Opis strony:
kategorii: ostrzeżenia bazy danych dostępności
To ustawienie umożliwia wyświetlanie wyników oceny zasad na pulpicie nawigacyjnym Always On.
Opis: Bieżąca replika ma RZO, który przekracza 10 minut, zakładając, że obciążenie związane z odkrywaniem i failover wynosi 1 minutę. Należy natychmiast zbadać problemy z wydajnością w odpowiedniej instancji serwera.
tekst do wyświetlenia: przekroczono celu czasu odzyskiwania!
Utwórz drugą zasadę zarządzania opartą na politykach przy użyciu następujących specyfikacji.
strona Ogólne:
nazwa:
CustomAvailabilityDatabaseRPOsprawdź warunek:
RPOPrzeciwko celom: Każdy DatabaseReplicaState w IsPrimaryReplica AvailabilityGroup
tryb oceny: Zgodnie z harmonogramem
Harmonogram: CollectorSchedule_Every_30min
włączone: wybrana
Opis strony:
kategorii: ostrzeżenia bazy danych dostępności
Opis: Baza danych dostępności przekroczyła cel punktu odzyskiwania (RPO) 1 godziny. Należy natychmiast zbadać problemy z wydajnością replik dostępności.
tekst do wyświetlania: przekroczono celu punktu odzyskiwania!
Po zakończeniu tworzone są dwa nowe zadania agenta programu SQL Server, po jednym dla każdego z harmonogramów oceny zasad. Te zadania powinny mieć nazwy rozpoczynające się od syspolicy_check_schedule.
Historię zadań można wyświetlić, aby sprawdzić wyniki oceny. Błędy oceny są również rejestrowane w dzienniku aplikacji systemu Windows (w Podglądzie zdarzeń) z identyfikatorem zdarzenia 34052. Agenta programu SQL Server można również skonfigurować do wysyłania alertów dotyczących błędów zasad. Aby uzyskać więcej informacji, zobacz Konfigurowanie alertów w celu powiadamiania administratorów zasad o błędach zasad.
Scenariusze rozwiązywania problemów z wydajnością
W poniższej tabeli wymieniono typowe scenariusze rozwiązywania problemów związane z wydajnością.
| Scenariusz | Opis |
|---|---|
| Rozwiązywanie problemów: grupa dostępności przekroczyła czasu odzyskiwania | Po automatycznym przejściu w tryb failover lub zaplanowanym ręcznym przejściu w tryb failover bez utraty danych czas przejścia w tryb failover przekracza cel czasu odzyskiwania. Możesz też oszacować czas przełączania w tryb failover repliki pomocniczej z zatwierdzaniem synchronicznym (na przykład automatycznego partnera trybu failover) i stwierdzić, że przekracza on cel czasu odzyskiwania. |
| Rozwiązywanie problemów: grupa dostępności przekroczyła RPO | Po wykonaniu wymuszonego ręcznego przejścia w tryb failover, utrata danych jest większa niż określony punkt odzyskiwania. Lub podczas obliczania potencjalnej utraty danych asynchronicznie zatwierdzanej repliki pomocniczej okazuje się, że przekracza ona RPO. |
| Rozwiązywanie problemów: zmiany na głównej replice nie są odzwierciedlane na replice pomocniczej | Aplikacja kliencka pomyślnie ukończy aktualizację repliki podstawowej, ale wykonanie zapytania względem repliki pomocniczej pokazuje, że zmiana nie została odzwierciedlona. |
Przydatne rozszerzone wydarzenia
Następujące rozszerzone zdarzenia są przydatne przy rozwiązywaniu problemów z replikami w stanie Synchronizowanie.
| Nazwa zdarzenia | Kategoria | Kanał | Kopia dostępności |
|---|---|---|---|
| ponowienie_uaktualniono | Transakcji | Debugować | Wtórny |
| redo_worker_entry | Transakcji | Debugować | Wtórny |
| hadr_transport_dump_message | alwayson |
Debugować | Podstawowy |
| hadr_worker_pool_task | alwayson |
Debugować | Podstawowy |
| hadr_dump_primary_progress | alwayson |
Debugować | Podstawowy |
| hadr_dump_log_progress | alwayson |
Debugować | Podstawowy |
| hadr_undo_of_redo_log_scan | alwayson |
Analityczny | Wtórny |