SQL Server Wysyłka drewna: kompletny przewodnik dla DBA [2026]

SQL Server Log Shipping to zautomatyzowane rozwiązanie do odzyskiwania danych po awarii, które utrzymuje kopie zapasowe baz danych produkcyjnych w trybie gotowości. Technologia ta przesyła kopie zapasowe dziennika transakcji z bazy głównej na serwerze głównym do jednej lub kilku baz zapasowych na oddzielnych serwerach zapasowych, zapewniając synchronizację baz zapasowych z bazą główną i chroniąc przed utratą danych i awariami serwerów.

1.2 Cel i korzyści z transportu drewna

Przesyłanie dziennika spełnia wiele ważnych celów w administrowaniu bazami danych:

Jego podstawową rolą jest odzyskiwanie danych po awarii, czyli zapewnienie niezawodnego miejsca docelowego w przypadku, gdy główny serwer stanie się niedostępny z powodu awarii sprzętu, uszkodzenia oprogramowania lub katastrofalnych zdarzeń mających wpływ na centrum danych.
Jest to również opłacalne rozwiązanie rozwiązanie o wysokiej dostępnościW przeciwieństwie do funkcji klasy korporacyjnej, które wymagają kosztownej licencji, wysyłka dziennika działa z SQL Server Standard Edition, dzięki czemu rozwiązanie to jest dostępne dla organizacji o ograniczonym budżecie.
Dodatkowe bazy danych w trybie gotowości oferują dodatkową wartość wykraczającą poza odzyskiwanie danych po awarii. Administratorzy baz danych mogą ich używać do raportowania w trybie tylko do odczytu, odciążając serwer produkcyjny od zadań związanych z zapytaniami.
Funkcja opóźnionego przywracania zapewnia ochronę przed przypadkowymi modyfikacjami danych. Konfigurując opóźnienie przywracania, tworzysz okno czasowe na odzyskanie danych po błędach użytkownika, zanim destrukcyjne zmiany dotrą do dodatkowej bazy danych.

2. SQL Server Komponenty i przepływ pracy wysyłki dziennika

Wysyłka drewna składa się z następujących elementów:

Serwer podstawowy i baza danych podstawowa: Serwer podstawowy reprezentuje Twoją bazę produkcyjną SQL Server instancja uruchamiająca bazę danych podstawową.
Udział kopii zapasowej: Pośrednia lokalizacja służąca do przechowywania i przesyłania kopii zapasowych dziennika transakcji z serwera podstawowego do serwerów pomocniczych.
Serwery pomocnicze i bazy danych pomocnicze: Serwery pomocnicze przechowują kopie zapasowe bazy danych podstawowej.
Serwer monitorujący (opcjonalnie): Ten serwer śledzi historię i stan wszystkich operacji tworzenia kopii zapasowych, kopiowania i przywracania w całej topologii przesyłania dzienników.
Zadania agenta: obejmują zadania tworzenia kopii zapasowych, kopiowania, przywracania i alertów, automatyzujące cały proces przesyłania dziennika.

Przepływ pracy automatyzacji wygląda następująco:

Zadanie tworzenia kopii zapasowej jest wykonywane na serwerze głównym i polega na tworzeniu kopii zapasowych dziennika transakcji bazy danych głównej w udziale kopii zapasowej.
Zadanie kopiowania jest wykonywane na każdym serwerze pomocniczym i polega na przesyłaniu plików kopii zapasowej dziennika z udziału kopii zapasowej do serwera(ów) pomocniczych.
Zadanie przywracania jest wykonywane na każdym serwerze pomocniczym i polega na stosowaniu skopiowanych kopii zapasowych dziennika transakcji do pomocniczej bazy danych.
Zadanie alertu jest uruchamiane na serwerze monitorującym i sprawdza, czy operacje tworzenia kopii zapasowych i przywracania danych zostały ukończone w akceptowalnych ramach czasowych.

3. Wymagania wstępne i wymagania

3.1 SQL Server Wymagania dotyczące wersji

Wysyłka drewna jest dostępna od SQL Server 2000 i jest nadal obsługiwany we wszystkich kolejnych wersjach SQL Server 2005–2025. Długotrwałe wsparcie świadczy o stabilności technologii i jej ciągłej przydatności.

3.2 SQL Server Wymagania dotyczące edycji

Wysyłka dziennika działa z wersjami Standard, Workgroup, Enterprise i Developer SQL Server. To szerokie wsparcie edycji sprawia, że wysyłka dziennika jest dostępna dla organizacji bez licencji Enterprise Edition, w przeciwieństwie do takich funkcji jak Grupy dostępności Always On które wymagają edycji Enterprise lub Evaluation.

Uwaga: Wersja Express Edition nie obsługuje wysyłki dziennika.

3.3 Wymagania dotyczące modelu odzyskiwania bazy danych

Przesyłanie dziennika wymaga, aby baza danych główna korzystała z modelu pełnego odzyskiwania lub modelu odzyskiwania z logowaniem zbiorczym. Prosty model odzyskiwania nie jest obsługiwany, ponieważ SQL Server automatycznie obcina dzienniki transakcji, przerywając ciągły łańcuch dzienników niezbędny do wysyłki dzienników.

Więcej szczegółów na temat modeli odzyskiwania znajdziesz w naszym kompleksowy przewodnik na temat SQL Server backup.

4. Konfigurowanie wysyłki dziennika za pomocą SSMS

4.1 Utwórz folder do udostępnienia kopii zapasowej

Przed skonfigurowaniem przesyłania dziennika transakcji przygotuj folder współdzielony kopii zapasowych, w którym będą przechowywane i przesyłane kopie zapasowe dziennika transakcji.

Na serwerze głównym lub dedykowanym serwerze plików utwórz folder (np. C:\Kopia zapasowa)
Kliknij folder prawym przyciskiem myszy i wybierz Właściwości
Kliknij Udostępnianie .
Kliknij Udostępnianie zaawansowane
Sprawdź Udostępnij ten folder
Kliknij Uprawnienia i przyznaj Pełna kontrola pozwolenie na SQL Server konto usługi Usługa NT\MSSQLSERVER.
Kliknij OK aplikować.
Udokumentuj ścieżkę sieciową (UNC) (np. \\NAZWA-SERWERA\Kopia zapasowa)

4.2 Włączanie i konfigurowanie wysyłki dziennika

Kliknij prawym przyciskiem myszy bazę danych podstawową i wybierz Właściwości.
W Właściwości bazy danych wybierz plik Wysyłka dziennika transakcji strona w lewym panelu.
Sprawdź Włącz tę bazę danych jako bazę podstawową w konfiguracji wysyłki dziennika aby umożliwić wysyłkę dziennika.
Następnie możesz skonfigurować ustawienia kopii zapasowej, serwera pomocniczego i serwera monitora na tej stronie właściwości. Przedstawimy je w kolejnych podsekcjach.

4.2.1 Konfigurowanie ustawień kopii zapasowej

Kliknij Ustawienia kopii zapasowej przycisk
W Ustawienia kopii zapasowej dziennika transakcji dialog, pod Ścieżka sieciowa do folderu kopii zapasowej w polu wprowadź ścieżkę UNC (np. \\NAZWA-SERWERA\Kopia zapasowa)
Jeżeli folder kopii zapasowej znajduje się na serwerze głównym, wprowadź ścieżkę lokalną (np. C:\Kopia zapasowa)
Skonfiguruj inne ustawienia, takie jak okres przechowywania kopii zapasowej, próg alertu, zadanie kopii zapasowej i kompresję.
Kliknij OK aby potwierdzić ustawienia i zamknąć okno dialogowe.

4.2.2 Konfigurowanie instancji serwera pomocniczego i bazy danych

Kliknij Dodaj dla Instancje serwerów pomocniczych i bazy danych
W Ustawienia dodatkowej bazy danych dialog, kliknij Skontaktuj się aby połączyć się z dodatkową instancją serwera.
W Baza danych wtórna rozwijanej listy, wybierz istniejącą bazę danych lub wpisz nową nazwę bazy danych
W Inicjalizacja bazy danych pomocniczej kartę, wybierz Tak, wygeneruj pełną kopię zapasową bazy danych podstawowej i przywróć ją do bazy pomocniczej (oraz utwórz bazę pomocniczą, jeśli nie istnieje)
Kliknij Skopiuj pliki .
W Folder docelowy dla kopiowanych plików (ten folder zwykle znajduje się na serwerze pomocniczym), wprowadź ścieżkę lokalną folderu docelowego na serwerze pomocniczym.
Upewnij się, że folder istnieje i SQL Server konto usługi ma uprawnienia do zapisu
Kliknij OK aby potwierdzić ustawienia i zamknąć okno dialogowe.

4.2.3 Konfigurowanie serwera monitora

Sprawdź Użyj instancji serwera monitorującego
Kliknij Ustawienia
Kliknij Skontaktuj się aby połączyć się z instancją serwera monitora
Ustaw Usuń historię po określić okres przechowywania w godzinach
Kliknij OK aby potwierdzić ustawienia i zamknąć okno dialogowe.

4.2.4 Przeglądanie i kończenie konfiguracji

Przejrzyj wszystkie ustawienia na Wysyłka dziennika transakcji strona
Sprawdź ustawienia kopii zapasowej, konfiguracje serwera pomocniczego i ustawienia monitorowania
Kliknij OK zastosować konfigurację
Kreator tworzy wszystkie niezbędne zadania na serwerach podstawowych, pomocniczych i monitorujących
Kliknij Zamknij po zakończeniu konfiguracji

5. Zalety i wady transportu drewna

5.1 zalety SQL Server Wysyłka kłód

Ekonomiczne rozwiązanie: Pracuje z SQL Server Edycja Standard, eliminująca kosztowne wymagania licencyjne Edycji Enterprise. Dzięki temu niezawodne odzyskiwanie danych po awarii jest dostępne dla organizacji o ograniczonym budżecie.
Łatwa konfiguracja i konserwacja: Kreator konfiguracji prowadzi administratorów przez proces konfiguracji, oferując przejrzyste opcje. Większość baz danych można skonfigurować w ciągu 15–30 minut bez specjalistycznego szkolenia.
Obsługa wielu serwerów pomocniczych: Obsługa wielu serwerów zapasowych bez ograniczeń architektonicznych. Wdróż jeden serwer zapasowy do lokalnego odzyskiwania po awarii, drugi zdalnie, a trzeci do raportowania.
Minimalny wpływ na serwer główny: Działa asynchronicznie, eliminując obciążenie synchronizacji na serwerze głównym. Czas zatwierdzania transakcji pozostaje niezmieniony.
Wykorzystuje istniejące kopie zapasowe dziennika transakcji: Kopie zapasowe dziennika transakcji to standardowe kopie zapasowe dziennika transakcji, które można wykorzystać do odzyskiwania danych z określonego punktu w czasie, niezależnie od wysyłki dziennika.
Opcja opóźnionego przywracania: Funkcja opóźnienia przywracania zapewnia ochronę przed przypadkową modyfikacją danych, niedostępną w rozwiązania replikacji w czasie rzeczywistym.
Brak konieczności współdzielenia pamięci masowej: Wykorzystuje niezależną pamięć masową na każdym serwerze, eliminując wymagania dotyczące współdzielonej pamięci masowej i związanych z tym kosztów.
Wsparcie międzyplatformowe: Działa identycznie zarówno w systemach Windows, jak i Linux SQL Server wdrożenia.
Działa w różnych domenach: Nie wymaga relacji zaufania domeny ani integracji z usługą Active Directory.

5.2 Wady i ograniczenia transportu drewna

Brak automatycznego przełączania awaryjnego: Głównym ograniczeniem jest konieczność ręcznego przełączania awaryjnego. Administratorzy muszą wykonać kilka kroków przed wznowieniem usługi.
Opóźnienie synchronizacji danych: Bazy danych drugorzędne zawsze pozostają w tyle za bazami podstawowymi pod względem częstotliwości tworzenia kopii zapasowych i przywracania.
Tylko konfiguracja na poziomie bazy danych: Konfiguruje się na poziomie bazy danych, a nie instancji. Ochrona 50 baz danych wymaga 50 oddzielnych konfiguracji.
Ręczne zmiany ciągu połączenia: Aplikacje muszą aktualizować ciągi połączeń, aby wskazywały na serwer zapasowy po przełączeniu awaryjnym.
Przerwania bazy danych drugorzędnej: Bazy danych pomocnicze w trybie gotowości rozłączają użytkowników podczas operacji przywracania.
Oddzielne zarządzanie bazą danych: Każda konfiguracja bazy danych musi być zarządzana indywidualnie, bez skoordynowanych możliwości zarządzania.

6. Najlepsze praktyki i przypadki użycia

6.1 Kiedy stosować transport drewna

Odzyskiwanie danych po awarii przy niskim budżecie: Doskonale sprawdza się jako ekonomiczne rozwiązanie do odzyskiwania danych po awarii dla organizacji, które nie mogą sobie pozwolić na koszty licencji Enterprise Edition.
Umiarkowane wymagania RPO/RTO: Aplikacje tolerujące 15–30 minutową utratę danych i 30–60 minut przestoju idealnie wpisują się w jego możliwości.
Serwer raportowania tylko do odczytu: Twórz kopie tylko do odczytu na potrzeby raportowania obciążeń, które tolerują okresowe rozłączenia.
Środowiska edycji standardowej: Organizacje standaryzowane na SQL Server Wersja Standard nie ma dostępu do grup dostępności Always On, przez co wysyłka dziennika jest najlepszą dostępną opcją.
Projekty migracji serwerów: Ułatwia migracje serwerów poprzez utrzymywanie zsynchronizowanych kopii w okresach przejściowych.
Wymagania dotyczące opóźnionych danych: Skonfiguruj opóźnienia przywracania, aby zachować bazy danych w ustalonych punktach w przeszłości w celach zgodności lub audytu.

6.2 Kiedy NIE należy stosować transportu drewna

Wymagania dotyczące niemal zerowego czasu przestoju: Aplikacje wymagające czasu RTO poniżej 15 minut nie mogą polegać na ręcznym przełączaniu awaryjnym.
Potrzebne automatyczne przełączanie awaryjne: Nie jest to właściwe, gdy wymogi biznesowe wymagają automatycznego przełączania awaryjnego bez interwencji administratora.
Wymagana synchronizacja w czasie rzeczywistym: Aplikacje wymagające danych w czasie rzeczywistym lub prawie rzeczywistym na serwerach pomocniczych nie są w stanie zaakceptować opóźnień związanych z przesyłaniem dzienników.
Minimalna tolerancja utraty danych: Organizacje, w których wskaźnik RPO mierzy się w sekundach lub które wymagają zerowej utraty danych, potrzebują rozwiązań synchronicznych.

6.3 Najlepsze praktyki

Optymalizacja częstotliwości tworzenia kopii zapasowych: Zrównoważ częstotliwość tworzenia kopii zapasowych z obciążeniem systemu i celami odzyskiwania. Zacznij od 15-minutowych interwałów i dostosuj je do rzeczywistych potrzeb.
Rozważania dotyczące ścieżki sieciowej: Używaj ścieżek UNC zamiast mapowanych dysków do lokalizacji kopii zapasowych. Umieść udziały kopii zapasowych w niezawodnej infrastrukturze sieciowej.
Konfiguracja monitorowania i powiadamiania: Skonfiguruj alerty dotyczące błędów zadań tworzenia kopii zapasowej, kopiowania i przywracania natychmiast po zakończeniu konfiguracji przesyłania dziennika.
Regularny harmonogram testów: Zaplanuj kwartalne lub półroczne testy awaryjne, aby zweryfikować procedury i utrzymać administratorów w gotowości.
Konserwacja dokumentacji: Prowadź szczegółowe podręczniki dokumentujące szczegóły konfiguracji, procedury przełączania awaryjnego i czynności rozwiązywania problemów.
Względy bezpieczeństwa: Używaj dedykowanych kont usługowych z minimalnymi wymaganymi uprawnieniami. Odpowiednio ogranicz uprawnienia do udziałów sieciowych.
Zarządzanie miejscem na dysku: Monitoruj stale miejsce na dysku w lokalizacjach kopii zapasowych. Skonfiguruj alerty, gdy miejsce spadnie poniżej 20%.
Konfiguracja zasad przechowywania: Ustaw okres przechowywania kopii zapasowych dłuższy niż maksymalne akceptowalne opóźnienie synchronizacji.
Opóźnienie przywracania w celu ochrony: Skonfiguruj opóźnienia przywracania, gdy ochrona przed przypadkowymi modyfikacjami uzasadnia większe opóźnienie synchronizacji.

7. Rozwiązywanie typowych problemów

7.1 Niepowodzenia w tworzeniu kopii zapasowej

Za mało miejsca na dysku: Sprawdź historię zadań pod kątem błędów miejsca na dysku. Sprawdź dostępną i wolną przestrzeń, usuwając stare kopie zapasowe lub włączając kompresję.
Problemy z uprawnieniami: Zweryfikuj SQL Server Konto usługi ma uprawnienia pełnej kontroli zarówno do folderu lokalnego, jak i udziału sieciowego.
Baza danych nie jest w pełni odzyskana: Wróć do modelu pełnego odzyskiwania i wykonaj pełną kopię zapasową, aby ponownie uruchomić łańcuch dziennika transakcji.

7.2 Niepowodzenia w zadaniach kopiowania

Ścieżka sieciowa jest niedostępna: Przetestuj łączność z serwerem pomocniczym, mapując ręcznie ścieżkę sieciową.
Problemy z uwierzytelnianiem: Skonfiguruj jawne dane uwierzytelniające w celu dostępu do zasobów sieciowych, jeśli serwery znajdują się w różnych domenach.
Problemy z blokowaniem plików: Wyklucz folder kopii zapasowej ze skanowania antywirusowego w czasie rzeczywistym, aby zapobiec blokowaniu plików.

7.3 Przywracanie nieudanych zadań

Brak plików kopii zapasowej: Sprawdź, czy pliki znajdują się w folderze docelowym i sprawdź historię zadań kopiowania.
Błąd sekwencji przywracania: Zidentyfikuj brakujące kopie zapasowe dziennika transakcji i przywróć je po kolei, aby naprawić łańcuch dziennika.
Baza danych w złym stanie: Ponownie zainicjuj wysyłkę dziennika, przywracając pełną kopię zapasową za pomocą NORECOVERY, jeśli ktoś odzyskał bazę danych.
Uszkodzenie pliku bazy danych: Jeśli błędy przywracania danych utrzymują się pomimo prawidłowej sekwencji i konfiguracji, same pliki bazy danych mogą być uszkodzone. W takich przypadkach może być konieczne użycie specjalistycznego narzędzia. narzędzie do odzyskiwania SQL aby wyodrębnić dane z uszkodzonych plików .MDF i .NDF przed próbą ponownego zainicjowania wysyłki dziennika.

7.4 Problemy z opóźnieniem synchronizacji

Ograniczenia przepustowości sieci: Włącz kompresję kopii zapasowej, aby zmniejszyć rozmiar plików i wymagania dotyczące przepustowości.
Duży wolumen transakcji: Rozważ zwiększenie częstotliwości tworzenia kopii zapasowych, aby tworzyć mniejsze i łatwiejsze w zarządzaniu pliki kopii zapasowych.
Niewystarczająca częstotliwość przywracania: Zwiększ częstotliwość wykonywania zadań przywracania, aby zbliżyć ją do częstotliwości tworzenia kopii zapasowych i zminimalizować opóźnienie.

7.5 Monitorowanie problemów z łącznością serwera (SQL 2025)

Błędy dostawcy OLE DB: SQL Server Domyślne obowiązkowe szyfrowanie w wersji 2025 koliduje ze starszymi instancjami, w których brakowało prawidłowej konfiguracji szyfrowania.
Niezgodność konfiguracji szyfrowania: Sprawdź konfigurację serwera połączonego na serwerze monitorującym i sprawdź ustawienia szyfrowania.
Rozwiązania tymczasowe: Usuń i utwórz ponownie wysyłkę dziennika przy użyciu parametrów TLS 1.3 lub zaktualizuj wszystkie instancje do SQL Server 2025.

7.6 SQL Server Problemy z obsługą agenta

Usługa nie została uruchomiona: Sprawdź stan usługi agenta i skonfiguruj ją tak, aby uruchamiała się automatycznie.
Harmonogram zadań wyłączony: Sprawdź status harmonogramu zadań i włącz wyłączone harmonogramy.
Niepowodzenia w etapach zadania: Przejrzyj historię zadań, aby zidentyfikować nieudane kroki i konkretne komunikaty o błędach.

8. Często zadawane pytania (FAQ)

P: Czy mogę skorzystać z usługi wysyłki dziennika w ramach Express Edition?

Nie, SQL Server Wersja Express Edition nie obsługuje wysyłki dziennika, ponieważ jej brakuje SQL Server Agent.

P: Jak często powinienem planować tworzenie kopii zapasowych dziennika?

A: Domyślne 15-minutowe interwały zapewniają rozsądną równowagę. Dostosuj je do swojego celu punktu odzyskiwania.

P: Czy do raportowania można używać baz danych drugorzędnych?

O: Tak, bazy danych pomocnicze skonfigurowane w trybie gotowości umożliwiają dostęp tylko do odczytu pomiędzy operacjami przywracania.

P: Co się stanie, jeśli serwer główny ulegnie awarii?

A: Wykonaj ręczne przełączenie awaryjne, aby uruchomić dodatkową bazę danych. Utrata danych równa się opóźnieniu synchronizacji w momencie awarii.

P: Czy mogę mieć wiele serwerów pomocniczych?

O: Tak, usługa przesyłania dzienników obsługuje nieograniczoną liczbę serwerów pomocniczych z niezależnymi konfiguracjami.

P: Jak obliczyć opóźnienie synchronizacji?

A: Porównaj ostatni przywrócony znacznik czasu dziennika transakcji z czasem bieżącym, korzystając z tabel monitorowania wysyłki dziennika.

P: Czy logowanie wysyłki działa w różnych domenach?

O: Tak, działa w różnych domenach lub w środowiskach grup roboczych i nie wymaga relacji zaufania.

P: Jaka jest różnica między trybem No Recovery a trybem gotowości?

A: Brak trybu odzyskiwania uniemożliwia dostęp do bazy danych. Tryb gotowości umożliwia wykonywanie zapytań tylko do odczytu między operacjami przywracania.

P: Czy mogę tymczasowo wstrzymać wysyłkę drewna?

O: Tak, wyłącz zadania tworzenia kopii zapasowej, kopiowania i przywracania, aby wstrzymać synchronizację, zachowując jednocześnie konfigurację.

P: Jak usunąć konfigurację wysyłki dziennika?

O: W Wysyłka dziennika transakcji strona właściwości:

Odznacz Włącz tę bazę danych jako bazę podstawową w konfiguracji wysyłki dziennika
Kliknij OK aby usunąć konfigurację i usunąć zadania.

P: Czy mogę przełączyć bazę danych pomocniczą w tryb odczytu i zapisu?

O: Tak, wykonaj polecenie RESTORE DATABASE WITH RECOVERY, ale spowoduje to przerwanie łańcucha przesyłania dziennika.

P: Jakie maksymalne opóźnienie mogę skonfigurować w celu przywrócenia danych?

O: Nie ma sztywnego limitu. Skonfiguruj opóźnienia od minut do dni, w zależności od wymagań dotyczących ochrony.

P: Jak wysyłka dziennika wpływa na strategię tworzenia kopii zapasowych?

A: Tworzy kopie zapasowe dziennika transakcji, które można wykorzystać zarówno do wysyłki dziennika, jak i odzyskiwania danych z określonego punktu w czasie.

P: Czy mogę skorzystać z opcji przesyłania dzienników w celu migracji serwera?

O: Tak, należy skonfigurować przesyłanie dzienników na nowy serwer, przeprowadzić synchronizację, a następnie na czas konserwacji wykonać zaplanowane przełączanie awaryjne starego serwera.

P: Jakie narzędzia monitorujące współpracują z wysyłką dziennika?

A: SQL Server Management Studio zawiera wbudowane raporty. Narzędzia innych firm, takie jak SQL Monitor i SolarWinds, zapewniają ulepszone monitorowanie.

9. Wnioski i zalecenia

9.1 Podsumowanie kluczowych punktów

SQL Server Log Shipping zapewnia niezawodne i ekonomiczne odzyskiwanie danych po awarii poprzez automatyczne tworzenie kopii zapasowych i przywracanie dziennika transakcji. Technologia ta współpracuje z edycją Standard Edition, wymaga minimalnej infrastruktury i obsługuje wiele serwerów zapasowych.

Przesyłanie dziennika sprawdza się w przypadku umiarkowanych celów odzyskiwania, gdzie dopuszczalne jest ręczne przełączanie awaryjne. Do kluczowych ograniczeń należą wymóg ręcznego przełączania awaryjnego, opóźnienie synchronizacji oraz zakres konfiguracji na poziomie bazy danych.

Technologia ta dobrze integruje się z istniejącymi strategiami tworzenia kopii zapasowych, obsługuje raportowanie w trybie tylko do odczytu w trybie gotowości i zapewnia opóźnione przywracanie danych w przypadku przypadkowych zmian.

9.2 Dokonywanie właściwych wyborów dla swojego środowiska

Przed wdrożeniem oceń wysyłkę dziennika pod kątem konkretnych wymagań. Weź pod uwagę cele dotyczące punktów odzyskiwania, docelowe czasy odzyskiwania, ograniczenia budżetowe i tolerancję złożoności operacyjnej.

Organizacje używające SQL Server Edycja Standardowa z umiarkowanymi wymaganiami odzyskiwania danych powinna zdecydowanie rozważyć wysyłkę logów. Przedsiębiorstwa z rygorystycznym RTO poniżej 15 minut powinny rozważyć grupy dostępności Always On.

Rozważ hybrydowe podejście łączące transport drewna z innymi technologiami w celu optymalizacji kosztów przy jednoczesnym spełnieniu zróżnicowanych wymagań.

9.3 Następne kroki i dodatkowe zasoby

Zacznij od wdrożeń pilotażowych na małą skalę, aby zdobyć doświadczenie. Opracuj kompleksową dokumentację, obejmującą szczegóły konfiguracji, procedury przełączania awaryjnego i przewodniki rozwiązywania problemów.

Zaplanuj regularne testy awaryjne, aby zweryfikować procedury i utrzymać gotowość administratora. Bądź na bieżąco z SQL Server Aktualizacje i ulepszenia.

Referencje

Oficjalny dokument firmy Microsoft: O wysyłce kłód (SQL Server)
Oficjalny dokument firmy Microsoft: Konfiguruj wysyłkę dziennika (SQL Server)

O autorze

Yuan Sheng jest starszym administratorem baz danych (DBA) z ponad 10-letnim doświadczeniem w SQL Server środowiskach i zarządzaniu bazami danych przedsiębiorstw. Z powodzeniem rozwiązał setki scenariuszy odzyskiwania baz danych w firmach z branży usług finansowych, opieki zdrowotnej i produkcji.

Yuan specjalizuje się w SQL Server Odzyskiwanie baz danych, rozwiązania wysokiej dostępności i optymalizacja wydajności. Jego bogate doświadczenie praktyczne obejmuje zarządzanie wieloterabajtowymi bazami danych, wdrażanie grup Always On Availability Groups oraz opracowywanie zautomatyzowanych strategii tworzenia kopii zapasowych i odzyskiwania danych dla systemów biznesowych o znaczeniu krytycznym.

Dzięki swojej wiedzy technicznej i praktycznemu podejściu Yuan skupia się na tworzeniu kompleksowych przewodników, które pomagają administratorom baz danych i specjalistom IT rozwiązywać złożone problemy SQL Server skutecznie stawia czoła wyzwaniom. Jest na bieżąco z najnowszymi SQL Server wydania i rozwijające się technologie baz danych firmy Microsoft, regularnie testując scenariusze odzyskiwania, aby mieć pewność, że jego zalecenia odzwierciedlają najlepsze praktyki stosowane w praktyce.

Masz pytania dot SQL Server Potrzebujesz pomocy w odzyskiwaniu danych lub dodatkowych wskazówek dotyczących rozwiązywania problemów z bazą danych? Yuan zaprasza opinie i sugestie w celu udoskonalenia tych zasobów technicznych.