Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dotyczy:SQL Server
W tym temacie opisano synchroniczne i asynchroniczne tryby operacyjne dla sesji dublowania bazy danych.
Uwaga / Notatka
Aby zapoznać się z wprowadzeniem do mirroringu bazy danych, zobacz Mirroring bazy danych (SQL Server).
Terminy i definicje
W tej sekcji przedstawiono kilka terminów, które są kluczowe dla tego tematu.
Tryb wysokiej wydajności
Sesja dublowania bazy danych działa asynchronicznie i używa tylko głównego serwera i serwera dublowania. Jedyną formą przełączania ról jest wymuszona usługa (z możliwą utratą danych).
Tryb wysokiego bezpieczeństwa
Sesja dublowania bazy danych działa synchronicznie i, opcjonalnie, używa monitora, a także głównego serwera i serwera dublowania.
Bezpieczeństwo transakcji
Właściwość bazy danych specyficznej dla dublowania, która określa, czy sesja dublowania bazy danych działa synchronicznie, czy asynchronicznie. Istnieją dwa poziomy bezpieczeństwa: FULL i OFF.
Witness
Do użycia tylko w trybie wysokiego bezpieczeństwa jest opcjonalne wystąpienie programu SQL Server, które umożliwia serwerowi lustrzanemu rozpoznanie, czy należy zainicjować automatyczne przełączanie w tryb failover. W przeciwieństwie do dwóch partnerów failover świadek nie obsługuje bazy danych. Obsługa automatycznego trybu failover jest jedyną rolą monitora.
Asynchroniczne dublowanie bazy danych (tryb wysoka wydajność)
W tej sekcji opisano, jak działa dublowanie asynchroniczne bazy danych, gdy jest odpowiednie do korzystania z trybu wysokiej wydajności i jak reagować, jeśli serwer główny ulegnie awarii.
Uwaga / Notatka
Większość wersji programu SQL Server obsługuje tylko synchroniczne dublowanie bazy danych ("Bezpieczeństwo tylko pełne"). Aby uzyskać informacje o wersjach, które w pełni obsługują dublowanie bazy danych, zobacz artykuł "Wysoka dostępność (Zawsze włączone)" w wersjach i obsługiwane funkcje programu SQL Server 2022.
Gdy bezpieczeństwo transakcji jest wyłączone, sesja dublowania bazy danych działa asynchronicznie. Operacja asynchroniczna obsługuje tylko jeden tryb operacyjny o wysokiej wydajności. Ten tryb zwiększa wydajność kosztem wysokiej dostępności. Tryb wysokiej wydajności używa tylko serwera głównego i serwera lustrzanego. Problemy na serwerze dublowania nigdy nie wpływają na serwer główny. Po utracie głównego serwera dublowana baza danych jest oznaczona jako ODŁĄCZONA, ale jest dostępna jako ciepła rezerwa.
Tryb o wysokiej wydajności obsługuje tylko jedną formę przełączania ról: przymusową usługę (z możliwością utraty danych), która używa serwera lustrzanego jako serwera o ciepłej rezerwie. Wymuszona usługa jest jedną z możliwych odpowiedzi na awarię serwera głównego. Ponieważ utrata danych jest możliwa, należy rozważyć alternatywy przed wymuszeniem usługi na lustro. Aby uzyskać więcej informacji, zobacz Odpowiadanie na błąd Principal w dalszej części tej sekcji.
Na poniższej ilustracji przedstawiono konfigurację sesji przy użyciu trybu wysokiej wydajności.
W trybie wysokiej wydajności, gdy tylko serwer główny wysyła dziennik transakcji na serwer dublowania, serwer główny wysyła potwierdzenie do klienta, nie czekając na potwierdzenie z serwera dublowanego. Transakcje są zatwierdzane bez oczekiwania, aż serwer lustrzany zapisze dziennik na dysku. Operacja asynchroniczna pozwala głównemu serwerowi działać z minimalnym opóźnieniem transakcji.
Serwer dublowany próbuje nadążyć za rekordami dziennika wysyłanymi przez serwer główny. Jednak lustrzana baza danych może być nieco opóźniona względem głównej bazy danych, choć zazwyczaj różnica między bazami danych jest niewielka. Jednak luka może stać się znacząca, jeśli serwer główny jest obciążony dużym obciążeniem lub system serwera dublowanego jest załadowany.
W tej sekcji:
Kiedy jest odpowiedni tryb High-Performance?
Tryb wysokiej wydajności może być przydatny w scenariuszu odzyskiwania po awarii, w którym serwer właściwy i serwery lustrzane są oddzielone znaczną odległością i gdzie nie chcesz, aby małe błędy wpływały na serwer właściwy.
Uwaga / Notatka
Wysyłanie dzienników może być uzupełnieniem mirroringu bazy danych i jest korzystną alternatywą dla asynchronicznego mirroringu bazy danych. Aby uzyskać informacje o zaletach wysyłania dzienników, zobacz Rozwiązania o wysokiej dostępności (SQL Server). Aby uzyskać informacje na temat korzystania z wysyłania dzienników z dublowaniem bazy danych, zobacz Dublowanie bazy danych i Wysyłanie dzienników (SQL Server).
Wpływ świadka na tryb wysokiej wydajności
Jeśli używasz Transact-SQL do konfigurowania trybu wysokiej wydajności, zawsze, gdy właściwość SAFETY jest ustawiona na OFF, zdecydowanie zalecamy, aby właściwość WITNESS była również ustawiona na OFF. Świadek może współistnieć z trybem wysokiej wydajności, ale nie zapewnia korzyści i wprowadza ryzyko.
Jeśli świadek zostanie odłączony od sesji, kiedy którykolwiek z partnerów ulegnie awarii, baza danych stanie się niedostępna. Dzieje się tak, ponieważ mimo że tryb wysokiej wydajności nie wymaga świadka, jeśli jest ustawiony, sesja wymaga kworum składającego się z co najmniej dwóch wystąpień serwera. Jeśli sesja straci kworum, nie może udostępniać bazy danych.
Kiedy świadek jest ustawiony w sesji modułu wysokiej wydajności, wymuszanie kworum oznacza, że:
Jeśli serwer dublowania zostanie utracony, serwer główny musi być połączony ze świadkiem. W przeciwnym razie serwer główny przełączy bazę danych w tryb offline, aż monitor lub serwer dublowania ponownie dołączy do sesji.
Jeśli serwer główny zostanie utracony, przełączenie usługi na serwer lustrzany wymaga, aby serwer lustrzany był połączony z serwerem świadkiem.
Uwaga / Notatka
Aby uzyskać informacje o typach kworum, zobacz Kworum: Jak świadek wpływa na dostępność bazy danych (dublowanie bazy danych).
Reagowanie na awarię podmiotu głównego
Gdy główny podmiot ulegnie awarii, właściciel bazy danych ma kilka opcji, jak następuje:
Pozostaw bazę danych niedostępną do czasu, gdy główna jednostka będzie znowu dostępna.
Jeśli główna baza danych i dziennik transakcji są nienaruszone, ten wybór zachowuje wszystkie zatwierdzone transakcje kosztem dostępności.
Zatrzymaj sesję dublowania bazy danych, ręcznie zaktualizuj bazę danych, a następnie rozpocznij nową sesję dublowania bazy danych.
Jeśli główna baza danych zostanie utracona, ale serwer główny jest nadal uruchomiony, natychmiast spróbuj wykonać kopię zapasową końca dziennika w głównej bazie danych. Jeśli tworzenie kopii zapasowej dziennika końcowego powiedzie się, usunięcie dublowania może być najlepszą alternatywą. Po usunięciu mirroringu, można przywrócić dziennik na wcześniejszą bazę danych będącą lustrzaną kopią, co zachowuje wszystkie dane.
Uwaga / Notatka
Jeśli tworzenie kopii zapasowej dziennika końcowego nie powiodło się i nie można poczekać na odzyskanie serwera głównego, rozważ wymuszenie działania serwera, które ma zaletę utrzymania stanu sesji.
Wymuś usługę (z możliwością utraty danych) na serwerze lustrzanym.
Wymuszone działanie serwisowe jest wyłącznie metodą odzyskiwania po awarii i powinno być używane oszczędnie. Wymuszanie usługi jest możliwe tylko wtedy, gdy serwer główny nie działa, sesja jest asynchroniczna (bezpieczeństwo transakcji jest ustawione na WYŁĄCZONE), a sesja nie ma żadnego świadka (właściwość WITNESS jest ustawiona na wartość OFF) lub świadek jest połączony z serwerem lustrzanym (czyli mają kworum).
Wymuszanie usługi powoduje, że serwer lustrzany przejmuje rolę głównego i udostępnia swoją kopię bazy danych dla klientów. Gdy usługa jest wymuszana, dzienniki transakcji, które główna baza danych jeszcze nie przesłała do serwera lustrzanego, zostaną utracone. W związku z tym należy ograniczyć wymuszoną usługę do sytuacji, w których możliwa utrata danych jest akceptowalna, a natychmiastowa dostępność bazy danych ma krytyczne znaczenie. Aby uzyskać informacje na temat sposobu działania wymuszonej usługi i najlepszych rozwiązań dotyczących korzystania z niej, zobacz Przełączanie ról podczas sesji dublowania bazy danych (SQL Server).
Synchroniczne dublowanie bazy danych (tryb wysokiego poziomu bezpieczeństwa)
W tej sekcji opisano sposób działania synchronicznego mirroringu bazy danych, w tym alternatywne tryby wysokiego bezpieczeństwa (z automatycznym przełączeniem awaryjnym i bez niego) oraz informacje o roli świadka w automatycznym przełączeniu awaryjnym.
Gdy bezpieczeństwo transakcji jest ustawione na PEŁNE, sesja dublowania bazy danych jest uruchamiana w trybie wysokiego bezpieczeństwa i działa synchronicznie po początkowej fazie synchronizacji. W tej sekcji opisano szczegóły sesji dublowania bazy danych skonfigurowanych do operacji synchronicznej.
Aby osiągnąć operację synchroniczną dla sesji, serwer dublowania musi zsynchronizować bazę danych dublowania z główną bazą danych. Po rozpoczęciu sesji serwer główny rozpoczyna wysyłanie aktywnego dziennika na serwer dublowania. Serwer dublowania zapisuje wszystkie przychodzące rekordy dziennika na dysku tak szybko, jak to możliwe. Po zapisaniu wszystkich odebranych rekordów dziennika na dysku bazy danych są synchronizowane. Tak długo, jak partnerzy pozostają w komunikacji, bazy danych pozostają zsynchronizowane.
Uwaga / Notatka
Aby monitorować zmiany stanu w sesji dublowania bazy danych, użyj klasy zdarzeń Zmiany stanu dublowania bazy danych . Aby uzyskać więcej informacji, zobacz Klasę zdarzeń zmiany stanu dublowania bazy danych.
Po zakończeniu synchronizacji każda transakcja zatwierdzona w głównej bazie danych jest również zatwierdzana na serwerze dublowania, co gwarantuje ochronę danych. Jest to osiągane przez oczekiwanie na zatwierdzenie transakcji w głównej bazie danych, dopóki serwer główny nie otrzyma komunikatu z serwera lustrzanego z informacją, że utrwalił dziennik transakcji na dysku. Zwróć uwagę, że oczekiwanie na ten komunikat zwiększa opóźnienie transakcji.
Czas wymagany do synchronizacji zależy zasadniczo od tego, jak daleko baza danych dublowania znajdowała się za główną bazą danych na początku sesji (mierzona przez liczbę rekordów dziennika początkowo odebranych z serwera głównego), obciążenie pracy głównej bazy danych i szybkość systemu dublowania. Po zsynchronizowaniu sesji utwardzony dziennik, który nie został jeszcze odtworzony w lustrzanej bazie danych, pozostaje w kolejce przywracania.
Gdy tylko baza danych lustrzanych zostanie zsynchronizowana, stan obu kopii bazy danych zmieni się na ZSYNCHRONIZOWANE.
Operacja synchroniczna jest utrzymywana w następujący sposób:
Po otrzymaniu transakcji od klienta, serwer główny zapisuje ją w dzienniku zdarzeń.
Serwer główny zapisuje transakcję w bazie danych i jednocześnie wysyła rekord dziennika do serwera lustrzanego. Serwer główny czeka na potwierdzenie z serwera lustrzanego przed potwierdzeniem klientowi jednego z następujących: zatwierdzenie transakcji lub wycofanie.
Serwer lustrzany utrwala dziennik na dysku i zwraca potwierdzenie do serwera głównego.
Po otrzymaniu potwierdzenia z serwera dublowanego serwer główny wysyła do klienta komunikat potwierdzający.
Tryb wysokiego bezpieczeństwa chroni dane, wymagając synchronizacji danych między dwoma miejscami. Wszystkie zatwierdzone transakcje są gwarantowane do zapisania na dysku na serwerze lustrzanym.
W tej sekcji:
Tryb wysokiego bezpieczeństwa bez automatycznego przełączania awaryjnego
Tryb wysokiego bezpieczeństwa z automatycznym przełączaniem awaryjnym
Tryb High-Safety bez automatycznego przełączenia
Na poniższym rysunku przedstawiono konfigurację trybu wysokiego bezpieczeństwa bez automatycznego przełączania awaryjnego. Konfiguracja składa się tylko z dwóch partnerów.
Gdy partnerzy są połączeni, a baza danych jest już zsynchronizowana, obsługiwane jest ręczne przełączenie awaryjne. Jeśli wystąpienie serwera lustrzanego ulegnie awarii, nie ma to wpływu na wystąpienie głównego serwera i działa bez ochrony (bez lustrzania danych). Jeśli serwer główny jest niedostępny, mirroring zostanie wstrzymane, ale usługa może zostać przełączona na serwer lustrzany (z możliwością utraty danych). Aby uzyskać więcej informacji, zobacz Przełączanie ról podczas sesji dublowania bazy danych (SQL Server).
tryb wysokiego bezpieczeństwa z automatycznym przełączeniem awaryjnym
Automatyczne przełączanie w tryb failover zapewnia wysoką dostępność, zapewniając, że baza danych jest nadal obsługiwana po utracie jednego serwera. Automatyczne przełączanie awaryjne wymaga, aby w ramach sesji znajdowało się trzecie wystąpienie serwera, witness, które idealnie znajduje się na trzecim komputerze. Na poniższej ilustracji przedstawiono konfigurację sesji trybu wysokiego bezpieczeństwa, która obsługuje automatyczne przechodzenie w tryb failover.
W przeciwieństwie do dwóch partnerów świadek nie obsługuje bazy danych. Świadek po prostu obsługuje automatyczne przechodzenie w tryb failover, sprawdzając, czy serwer główny działa. Serwer dublowania inicjuje automatyczne przełączanie w tryb failover tylko wtedy, gdy dublowanie i monitor pozostają ze sobą połączone po odłączeniu obu z serwera głównego.
Po ustawieniu świadka sesja wymaga kworum — relacji między co najmniej dwoma wystąpieniami serwera, która umożliwia udostępnienie bazy danych. Aby uzyskać więcej informacji, zobacz Świadek dublowania bazy danych i Kworum: Jak świadek wpływa na dostępność bazy danych (dublowanie bazy danych).
Automatyczne przełączanie w tryb awaryjny wymaga następującego warunku:
Baza danych jest już zsynchronizowana.
Awaria występuje, gdy wszystkie trzy wystąpienia serwera są połączone, a serwer świadek i serwer odbicia pozostają połączone.
Utrata partnera ma następujący wpływ:
Jeśli serwer główny stanie się niedostępny w powyższych warunkach, nastąpi automatyczne przejście w tryb failover. Serwer lustrzany przełącza się do roli głównego i oferuje swoją bazę danych jako główną bazę danych.
Jeśli serwer główny stanie się niedostępny, gdy te warunki nie zostaną spełnione, możliwe może być wymuszanie usługi (z możliwą utratą danych). Aby uzyskać więcej informacji, zobacz Przełączanie ról podczas sesji dublowania bazy danych (SQL Server).
Jeśli jedyny serwer lustrzany stanie się niedostępny, serwer główny i świadek będą działać dalej.
Jeśli sesja utraci świadek, kworum wymaga obu partnerów. Jeśli jeden z partnerów utraci kworum, obaj partnerzy utracą kworum, a baza danych stanie się niedostępna do czasu ponownego ustanowienia kworum. To wymaganie kworum zapewnia, że w przypadku braku świadka baza danych nigdy nie jest narażona, czyli nie działa bez lustrzanego odbicia.
Uwaga / Notatka
Jeśli spodziewasz się, że świadek pozostanie odłączony przez znaczną ilość czasu, zalecamy usunięcie świadka z sesji do momentu, aż będzie dostępny.
ustawienia Transact-SQL i tryby operacyjne dublowania bazy danych
W tej sekcji opisano sesję mirroringu bazy danych w zakresie ustawień ALTER DATABASE i stanów mirroringowanej bazy danych oraz świadka, jeśli istnieje. Sekcja jest przeznaczona dla użytkowników, którzy zarządzają dublowaniem bazy danych głównie lub wyłącznie przy użyciu języka Transact-SQL, a nie przy użyciu programu SQL Server Management Studio.
Wskazówka
Alternatywą dla korzystania z języka Transact-SQL jest sterowanie trybem operacyjnym sesji w Eksploratorze obiektów przy użyciu strony Mirroring w oknie dialogowym Właściwości bazy danych. Aby uzyskać więcej informacji, zobacz Ustanawianie sesji dublowania bazy danych przy użyciu uwierzytelniania systemu Windows (SQL Server Management Studio).
W tej sekcji:
Jak bezpieczeństwo transakcji i stan świadka wpływają na tryb operacyjny
Czynniki wpływające na zachowanie w przypadku utraty serwera głównego
Jak bezpieczeństwo operacji transakcyjnych i stan świadka wpływają na tryb operacyjny
Tryb operacyjny sesji jest określany przez połączenie ustawień bezpieczeństwa transakcji i stanu świadka. W dowolnym momencie właściciel bazy danych może zmienić poziom bezpieczeństwa transakcji i dodać lub usunąć świadka.
W tej sekcji:
Bezpieczeństwo transakcji
Bezpieczeństwo transakcji to właściwość bazy danych specyficzna dla dublowania, która określa, czy sesja dublowania bazy danych działa synchronicznie, czy asynchronicznie. Istnieją dwa poziomy bezpieczeństwa: FULL i OFF.
BEZPIECZEŃSTWO PEŁNE
Pełne bezpieczeństwo transakcji powoduje, że sesja działa synchronicznie w trybie wysokiego bezpieczeństwa. Jeśli świadek jest obecny, sesja obsługuje automatyczne awaryjne przełączanie.
Podczas ustanawiania sesji przy użyciu instrukcji ALTER DATABASE sesja rozpoczyna się od właściwości SAFETY ustawionej na FULL; oznacza to, że sesja rozpoczyna się w trybie wysokiego bezpieczeństwa. Po rozpoczęciu sesji można dodać świadka.
Aby uzyskać więcej informacji, zobacz Synchroniczne dublowanie bazy danych (trybHigh-Safety), we wcześniejszej części tego tematu.
BEZPIECZEŃSTWO WYŁĄCZONE
Wyłączenie bezpieczeństwa transakcji powoduje, że sesja działa asynchronicznie w trybie wysokiej wydajności. Jeśli właściwość SAFETY ma wartość OFF, właściwość WITNESS powinna być również ustawiona na WARTOŚĆ OFF (wartość domyślna). Aby uzyskać informacje o wpływie świadka w trybie wysokiej wydajności, zobacz Stan świadka w dalszej części tego tematu. Aby uzyskać więcej informacji na temat uruchamiania z wyłączonym bezpieczeństwem transakcji, zobacz Asynchroniczne dublowanie bazy danych (High-Performance tryb), we wcześniejszej części tego tematu.
Ustawienie bezpieczeństwa transakcji bazy danych jest rejestrowane dla każdego partnera w widoku wykazu sys.database_mirroring w kolumnach mirroring_safety_level i mirroring_safety_level_desc . Aby uzyskać więcej informacji, zobacz sys.database_mirroring (Transact-SQL).
Właściciel bazy danych może w dowolnym momencie zmienić poziom bezpieczeństwa transakcji.
Stan świadka
Jeśli został ustawiony świadek, wymagane jest kworum, więc stan świadka jest zawsze znaczący.
Jeśli istnieje, świadek ma jeden z dwóch stanów:
Gdy świadek jest połączony z partnerem, znajduje się w stanie CONNECTED w odniesieniu do tego partnera i ma z nim kworum. W takim przypadku można udostępnić bazę danych, nawet jeśli jeden z partnerów jest niedostępny.
Gdy świadek istnieje, ale nie jest połączony z partnerem, świadek jest w stanie NIEZNANY lub ODŁĄCZONY względem tego partnera. W takim przypadku świadek nie ma kworum z tym partnerem, a jeśli partnerzy nie są ze sobą połączeni, baza danych stanie się niedostępna.
Aby uzyskać informacje o kworum, zobacz Kworum: Jak świadek wpływa na dostępność bazy danych (mirroring bazy danych).
Stan każdego świadka w wystąpieniu serwera jest rejestrowany w widoku katalogowym sys.database_mirroring w kolumnach mirroring_witness_state i mirroring_witness_state_desc. Aby uzyskać więcej informacji, zobacz sys.database_mirroring (Transact-SQL).
W tabeli poniżej podsumowano, od czego zależy tryb operacyjny sesji, na podstawie ustawień zabezpieczeń transakcji i stanu świadka.
| Tryb operacyjny | Bezpieczeństwo transakcji | Stan świadka |
|---|---|---|
| Tryb wysokiej wydajności | OFF | NULL (bez świadka)** |
| Wysokopoziomowy tryb bezpieczeństwa bez automatycznego failover. | PEŁNY | NULL (brak świadka) |
| Tryb wysokiego bezpieczeństwa z automatycznym trybem failover* | PEŁNY | PODŁĄCZONY |
*Jeśli świadek zostanie odłączony, zalecamy ustawienie WITNESS OFF do momentu udostępnienia wystąpienia serwera świadka.
**Jeśli świadek jest obecny w trybie wysokiej wydajności, świadek nie uczestniczy w sesji. Jednak aby udostępnić bazę danych, co najmniej dwa wystąpienia serwera muszą pozostać połączone. W związku z tym zalecamy ustawienie właściwości WITNESS na wartość OFF w sesjach trybu wysokiej wydajności. Aby uzyskać więcej informacji, zobacz Kworum: Jak świadek wpływa na dostępność bazy danych (odbicie lustrzane bazy danych).
Wyświetlanie ustawień bezpieczeństwa i stanu świadka
Aby wyświetlić ustawienia zabezpieczeń i stan świadka dla bazy danych, użyj widoku wykazu sys.database_mirroring. Odpowiednie kolumny są następujące:
| Czynnik | Kolumny | Description |
|---|---|---|
| Bezpieczeństwo transakcji | poziom_bezpieczeństwa_odzwierciedlenia lub opis_poziomu_bezpieczeństwa_odzwierciedlenia | Ustawienie bezpieczeństwa transakcji dla aktualizacji w dublowej bazie danych, jedno z następujących elementów: UNKNOWN OFF PEŁNY NULL = baza danych nie jest w trybie online. |
| Czy świadek istnieje? | mirroring_witness_name | Nazwa serwera świadka dublowania bazy danych lub wartość NULL wskazująca, że żaden świadek nie istnieje. |
| Stan świadka | stan_świadka_lustrzanego lub opis_stanu_świadka_lustrzanego | Stan świadka w bazie danych dla danego partnera: UNKNOWN PODŁĄCZONY DISCONNECTED NULL = brak świadka lub baza danych nie jest dostępna online. |
Na przykład na głównym serwerze lub serwerze lustrzanym wprowadź:
SELECT mirroring_safety_level_desc, mirroring_witness_name, mirroring_witness_state_desc FROM sys.database_mirroring
Aby uzyskać więcej informacji na temat tego widoku wykazu, zobacz sys.database_mirroring (Transact-SQL).
Czynniki wpływające na zachowanie w przypadku utraty serwera nadrzędnego
Poniższa tabela zawiera podsumowanie połączonego wpływu ustawienia bezpieczeństwa transakcji, stanu bazy danych i stanu obserwatora na zachowanie sesji mirroring w przypadku utraty serwera głównego.
| Bezpieczeństwo transakcji | Stan bazy danych w trybie mirroringu | Stan świadka | Zachowanie w przypadku utraty podmiotu zabezpieczeń |
|---|---|---|---|
| PEŁNY | SYNCHRONIZOWANE | PODŁĄCZONY | Odbywa się automatyczne przełączanie w tryb failover. |
| PEŁNY | SYNCHRONIZOWANE | DISCONNECTED | Serwer lustrzany zatrzymuje się; failover nie jest możliwy i nie można udostępnić bazy danych. |
| OFF | ZAWIESZONE lub ODŁĄCZONE | NULL (brak świadka) | Usługę można wymusić na serwerze lustrzanym (z możliwością utraty danych). |
| PEŁNY | SYNCHRONIZOWANIE LUB ZAWIESZANIE | NULL (bez świadka) | Usługę można wymusić na serwerze lustrzanym (z możliwością utraty danych). |
Powiązane zadania
Dodawanie lub zastępowanie monitora dublowania bazy danych (SQL Server Management Studio)
Usuwanie monitora z sesji dublowania bazy danych (SQL Server)
Zmiana bezpieczeństwa transakcji w sesji dublowania bazy danych (Transact-SQL)
Zobacz też
Monitorowanie mirroringu baz danych (SQL Server)
Świadek mirroringu bazy danych