SQL Server Baza danych w trybie odzyskiwania: 10 poprawek [2026]

SQL Server Baza danych w trybie odzyskiwania? Zdobądź 10 sprawdzonych rozwiązań już teraz! Rozwiązania krok po kroku, od prostych napraw po zaawansowane naprawy.

1. Zrozumienie SQL Server Tryb odzyskiwania bazy danych

1.1 Czym jest tryb odzyskiwania w SQL Server

Kiedy SQL Server baza danych pokazuje status „W trakcie odzyskiwania”, oznacza to SQL Server Wykonuje odzyskiwanie po awarii lub odzyskiwanie transakcji, aby zapewnić spójność bazy danych. Ten automatyczny proces utrzymuje integralność danych poprzez odtwarzanie zatwierdzonych transakcji i wycofywanie niezatwierdzonych.

Tryb odzyskiwania zazwyczaj występuje po nieoczekiwanym wyłączeniu systemu, awarii zasilania lub podczas przywracania bazy danych. Chociaż jest to normalny mechanizm ochronny, problemy pojawiają się, gdy… SQL Server odzyskiwanie bazy danych trwa niezwykle długo lub sprawia wrażenie zablokowanego.

1.2 Trzy fazy odzyskiwania bazy danych

SQL Server rekonwalescencja przebiega w trzech odrębnych fazach:

1.2.1 Faza analizy

SQL Server Skanuje dziennik transakcji od ostatniego punktu kontrolnego w celu identyfikacji brudnych stron i aktywnych transakcji. Tworzy tabelę brudnych stron (DPT) i tabelę aktywnych transakcji (ATT), aby śledzić, co wymaga odzyskania.

1.2.2 Faza powtórzenia (przewiń do przodu)

System odtwarza wszystkie zatwierdzone transakcje, które nie zostały zapisane na dysku przed awarią. Dzięki temu wszystkie zatwierdzone zmiany zostaną poprawnie zastosowane w plikach bazy danych.

1.2.3 Faza cofania (wycofywania)

Wszystkie niezatwierdzone transakcje są wycofywane w celu zachowania spójności bazy danych. Po zakończeniu baza danych staje się dostępna do normalnych operacji.

1.3 Typowe objawy i komunikaty o błędach

Kiedy twój SQL Server Jeśli baza danych znajduje się w trybie odzyskiwania, zazwyczaj zobaczysz:

Nazwa bazy danych wyświetlana jako „(w trakcie odzyskiwania)” SQL Server Studio zarządzania
Nieudane logowanie z komunikatami „baza danych jest odzyskiwana”
Wpisy w dzienniku błędów pokazujące procenty postępu odzyskiwania
Stan bazy danych wyświetla „ODZYSKIWANIE” po zapytaniu

2. Przyczyny pierwotne SQL Server Problemy z trybem odzyskiwania

2.1 Niekompletne operacje przywracania

Najczęstszą przyczyną jest przywracanie z wielu plików kopii zapasowych za pomocą NORECOVERY opcja bez finału Z REGENERACJĄ polecenie. Baza danych pozostaje w oczekiwaniu na kolejne operacje przywracania.

2.2 Problemy z dziennikiem transakcji

Duże pliki dziennika transakcji lub nadmierna liczba plików dziennika wirtualnego (VLF) znacznie spowalniają odzyskiwanie. Podczas odzyskiwania bazy danych MS SQL z tysiącami plików VLF proces ten może trwać godziny lub dni.

2.3 Problemy związane z systemem

Awarie sprzętu, przerwy w dostawie prądu lub niewystarczająca ilość miejsca na dysku mogą zakłócić normalne działanie bazy danych, co z kolei może spowodować uruchomienie długotrwałego procesu odzyskiwania podczas ponownego uruchamiania.

2.4 Uszkodzenie bazy danych

Uszkodzone pliki bazy danych uniemożliwiają pomyślne ukończenie odzyskiwania, przez co baza danych pozostaje na zawsze zablokowana w trybie odzyskiwania.

3. Kroki diagnostyczne przed naprawą

3.1 Sprawdzanie SQL Server Dzienniki błędów

Przed podjęciem próby naprawy należy sprawdzić SQL Server Dziennik błędów z komunikatami o postępie odzyskiwania. Szukaj wpisów pokazujących procent ukończenia i szacowany pozostały czas.

Otwórz SQL Server Studio zarządzania
Przejdź do Zarząd -> SQL Server Dzienniki
Przejrzyj ostatnie wpisy dotyczące nazwy Twojej bazy danych
Poszukaj wskaźników fazy odzyskiwania (faza 1, 2 lub 3 z 3)

3.2 Monitorowanie postępów odzyskiwania

Użyj dynamicznych widoków zarządzania, aby śledzić aktywne operacje odzyskiwania:

SELECT session_id, command, blocking_session_id, wait_type, wait_time, wait_resource
FROM sys.dm_exec_requests
WHERE command = 'DB STARTUP';

3.3 Sprawdzanie stanu bazy danych

Sprawdź aktualny stan bazy danych, aby poznać status odzyskiwania:

SELECT name, state_desc
FROM sys.databases
WHERE name = 'YourDatabaseName';

4. Rozwiązanie nr 1: Poczekaj na zakończenie naturalnego procesu regeneracji

Czasami cierpliwość jest najlepszym rozwiązaniem, gdy... SQL Server Baza danych jest w trakcie odzyskiwania. To podejście sprawdza się, gdy odzyskiwanie przebiega prawidłowo, ale trwa dłużej niż oczekiwano.

4.1 Kiedy należy zachować cierpliwość

Zezwól na naturalne zakończenie, gdy:

Rejestry błędów pokazują stały postęp przy malejących szacunkach czasu
Nie zgłoszono żadnych błędów korupcyjnych
W bazie danych ostatnio odnotowano duże transakcje
Liczba komórek VLF jest możliwa do opanowania (poniżej 1,000)

4.2 Monitorowanie postępów odzyskiwania

Szacunki czasu odzyskiwania w dziennikach błędów są często niedokładne. Skup się na procentach postępu, a nie na pozostałym czasie. Duże bazy danych z bogatą historią transakcji mogą wymagać kilku godzin na pełne odzyskanie.

5. Rozwiązanie nr 2: Użyj opcji PRZYWRÓĆ BAZĘ DANYCH Z ODZYSKIWANIEM

Ta poprawka rozwiązuje problem niekompletnych operacji przywracania, w których pominięto ostatni krok odzyskiwania. Użyj jej, gdy… SQL Server db w odzyskiwaniu powstał w wyniku procesu przywracania przy użyciu komendy NORECOVERY.

5.1 Zrozumienie polecenia

PRZYWRÓĆ BAZĘ DANYCH Z ODZYSKIWANIEM Polecenie kończy proces odzyskiwania poprzez wycofanie niezatwierdzonych transakcji i ponowne uruchomienie bazy danych.

5.2 Etapy wdrożenia

Otwórz SQL Server Studio zarządzania
Połącz się ze swoim SQL Server przykład
Kliknij Nowy > Zapytanie z bieżącym połączeniem
Wykonaj: RESTORE DATABASE [YourDatabaseName] WITH RECOVERY;
Poczekaj na potwierdzenie ukończenia

Ostrzeżenie: Użyj tego polecenia tylko wtedy, gdy masz pewność, że nie są w toku żadne dodatkowe operacje przywracania.

6. Rozwiązanie nr 3: Rozwiąż problemy z dziennikiem transakcji

Problemy z dziennikiem transakcji są główną przyczyną wydłużonego czasu odzyskiwania. Ta poprawka rozwiązuje problem pełnych dzienników, nadmiarowych plików VLF i problemów z przestrzenią dziennika, które powodują problemy. SQL Server w trakcie leczenia.

6.1 Tworzenie kopii zapasowych dzienników transakcji

Zwolnij miejsce w dzienniku transakcji, tworząc kopie zapasowe dziennika transakcji:

Otwórz SQL Server Studio zarządzania
Kliknij prawym przyciskiem myszy swoją bazę danych -> Zadania -> Kopię zapasową
zmiana Typ kopii zapasowej do Dziennik transakcji
Określ miejsce docelowe kopii zapasowej
Kliknij OK wykonać

6.2 Zarządzanie plikami dziennika wirtualnego (VLF)

Sprawdź liczbę VLF za pomocą:

DBCC LOGINFO('YourDatabaseName');

Jeśli masz ponad 1,000 VLF, zmniejsz ich liczbę poprzez:

Tworzenie kopii zapasowej dziennika transakcji
Zmniejszanie pliku dziennika: DBCC SHRINKFILE(LogFileName, TRUNCATEONLY);
Powiększanie pliku dziennika w dużych blokach (1 GB lub więcej)

6.3 Bezpieczne zmniejszanie plików dziennika

Zmniejszaj logi tylko w okresach konserwacji, gdy nie są aktywne żadne transakcje. Zawsze wykonuj kopię zapasową bazy danych przed zmniejszaniem.

7. Rozwiązanie nr 4: Uruchom DBCC CHECKDB i napraw

Uszkodzenie bazy danych może uniemożliwić pomyślne odzyskiwanie. DBCC CHECKDB to wbudowane polecenie, które może identyfikować i naprawiać drobne uszkodzenia, które uniemożliwiają MS SQL działanie w trybie odzyskiwania.

7.1 Sprawdzanie, czy baza danych nie jest uszkodzona

Zacznij od standardowego podejścia do weryfikacji integralności bazy danych. Najpierw wypróbuj bezpośrednio DBCC CHECKDB:

Wykonaj: DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS;
Przejrzyj wyniki pod kątem błędów spójności
Udokumentuj wszelkie komunikaty o korupcji

Jeśli DBCC CHECKDB nie powiedzie się W przypadku błędów typu „Baza danych jest odzyskiwana. Oczekiwanie na zakończenie odzyskiwania” oznacza to, że baza danych jest w trybie odzyskiwania i blokuje dostęp. W takim przypadku przejdź do sekcji 7.3, aby skorzystać z trybu AWARYJNEGO.

7.2 Opcje naprawy dostępnych baz danych

Jeśli polecenie DBCC CHECKDB zostało wykonane pomyślnie i wykryło uszkodzenie, wykonaj poniższe czynności naprawcze:

Ustaw bazę danych w trybie pojedynczego użytkownika: ALTER DATABASE [YourDatabaseName] SET SINGLE_USER;
Próba bezpiecznej naprawy: DBCC CHECKDB('YourDatabaseName', REPAIR_REBUILD);
W przypadku niepowodzenia użyj: DBCC CHECKDB('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS);
Powrót do trybu wielodostępnego: ALTER DATABASE [YourDatabaseName] SET MULTI_USER;

7.3 Korzystanie z trybu awaryjnego, gdy baza danych jest niedostępna

Tryb awaryjny jest wymagany tylko wtedy, gdy baza danych utknęła w fazie odzyskiwania i odrzuca standardowe próby DBCC CHECKDB. Oznacza bazę danych jako TYLKO_DO_ODCZYTU i wyłącza logowanie. Użyj tego podejścia, gdy standardowy dostęp się nie powiedzie:

Ustaw tryb awaryjny: ALTER DATABASE [YourDatabaseName] SET EMERGENCY;
Ustaw pojedynczego użytkownika: ALTER DATABASE [YourDatabaseName] SET SINGLE_USER;
Uruchom sprawdzanie integralności: DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS;
Jeśli znaleziono uszkodzenie, najpierw uruchom bezpieczną naprawę: DBCC CHECKDB('YourDatabaseName', REPAIR_REBUILD);
W przypadku niepowodzenia należy skorzystać z naprawy z utratą danych: DBCC CHECKDB('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS);
Ustaw wielu użytkowników: ALTER DATABASE [YourDatabaseName] SET MULTI_USER;
Ustaw online: ALTER DATABASE [YourDatabaseName] SET ONLINE;

Ważne: Tryb AWARYJNY pomija standardowe procesy odzyskiwania i powinien być używany tylko wtedy, gdy baza danych jest całkowicie niedostępna. Zawsze wypróbuj standardową metodę DBCC CHECKDB przed przejściem do trybu AWARYJNEGO.

Można znaleźć bardziej kompleksowy przewodnik dotyczący korzystania z DBCC CHECKDB.

8. Rozwiązanie nr 5: Przywróć z kopii zapasowej

Gdy inne metody zawodzą lub integralność danych jest wątpliwa, przywrócenie danych z czystej kopii zapasowej jest często najpewniejszym rozwiązaniem problemu SQL Server bazy danych w kwestiach odzyskiwania.

8.1 Kiedy wybrać przywracanie kopii zapasowej

Warto rozważyć przywrócenie kopii zapasowej, gdy:

Odzyskiwanie trwa już ponad 24 godziny i nie widać postępu
Błędy korupcyjne uniemożliwiają pomyślną naprawę
Masz dostępne najnowsze, zweryfikowane kopie zapasowe
Utrata danych od czasu ostatniej kopii zapasowej jest akceptowalna

8.2 Proces przywracania krok po kroku

Otwórz SQL Server Studio zarządzania
Kliknij prawym przyciskiem myszy Bazy danych -> Przywróć bazę danych
Wybierz Urządzenie pod źródłem
Kliknij Dodaj i przejdź do pliku kopii zapasowej
Wybierz kopię zapasową i kliknij OK
Dodaj Nadpisz istniejącą bazę danych potrzeba
Kliknij OK rozpocząć renowację

8.3 Odzyskiwanie w określonym punkcie czasu

Aby zminimalizować utratę danych, korzystaj z kopii zapasowych dziennika transakcji, aby przywrócić dane do określonego punktu w czasie. Upewnij się, że masz nieprzerwany łańcuch kopii zapasowych dziennika, od pełnej kopii zapasowej do żądanego punktu odzyskiwania.

8.4 Odniesienie

Więcej informacji możesz uzyskać od naszego kompleksowy przewodnik dotyczący tworzenia kopii zapasowych i przywracania ich SQL Server Bazy danych.

9. Poprawka nr 6: Wyłącz właściwość AUTOMATYCZNEGO ZAMKNIĘCIA

Właściwość bazy danych AUTO CLOSE może powodować powtarzające się cykle odzyskiwania, sprawiając wrażenie, że SQL Server Baza danych jest stale w trybie odzyskiwania. Wyłączenie tej właściwości rozwiązuje problem.

9.1 Zrozumienie problemów z funkcją AUTOMATYCZNEGO ZAMKNIĘCIA

Gdy funkcja AUTOMATYCZNEGO ZAMKNIĘCIA jest włączona, SQL Server Zamyka bazę danych po zakończeniu ostatniego połączenia, a następnie otwiera ją ponownie dla nowych połączeń. To wielokrotne otwieranie uruchamia procesy odzyskiwania za każdym razem.

9.2 Wyłączanie funkcji AUTOMATYCZNEGO ZAMKNIĘCIA

Otwórz SQL Server Studio zarządzania
Kliknij prawym przyciskiem myszy swoją bazę danych -> Właściwości
Wybierz Opcje z lewego panelu
Ustaw Automatyczne zamykanie do Fałszywy
Kliknij OK zastosować zmiany

Alternatywnie użyj T-SQL:

ALTER DATABASE [YourDatabaseName] SET AUTO_CLOSE OFF;

10. Rozwiązanie nr 7: Uruchom ponownie SQL Server Usługi

Ponowne uruchomienie usługi może rozwiązać problem zablokowanych procesów odzyskiwania, ale należy je stosować ostrożnie, ponieważ spowoduje ponowne uruchomienie odzyskiwania od początku. Ta poprawka działa, gdy SQL Server w fazie rekonwalescencji wydaje się całkowicie zamrożony.

10.1 Kiedy ponowne uruchomienie usługi pomaga

Uruchom ponownie usługę, gdy:

Postępy w odzyskiwaniu danych zostały wstrzymane na kilka godzin
Rejestry błędów nie wykazują żadnych nowych wpisów
Pozostałe bazy danych działają normalnie
Możesz sobie pozwolić na dłuższy przestój

10.2 Procedury bezpiecznego ponownego uruchomienia

Otwórz SQL Server Manager konfiguracji
Przejdź do SQL Server Usługi
Znajdź grupę programów SQL Server instancję, którą chcesz ponownie uruchomić, a następnie kliknij prawym przyciskiem myszy SQL Server (Nazwa instancji)
Wybierz restart
Poczekaj na pełne ponowne uruchomienie usługi
Monitoruj dzienniki błędów w celu sprawdzenia postępu odzyskiwania

Uwaga: Ponowne uruchomienie spowoduje rozpoczęcie odzyskiwania od nowa, co może wydłużyć całkowity czas odzyskiwania.

11. Rozwiązanie nr 8: Napraw bazę danych poprzez odłączenie i ponowne podłączenie

W skrajnych przypadkach należy odłączyć i ponownie podłączyć bazę danych:

Odłącz bazę danych: EXEC sp_detach_db 'YourDatabaseName';
Dołącz tylko plik MDF: CREATE DATABASE [YourDB] ON (FILENAME = 'C:\Path\YourDB.mdf') FOR ATTACH_REBUILD_LOG;
To odbudowuje nowy dziennik transakcji

Ostrzeżenie: Ta metoda może spowodować utratę danych. Stosuj tylko po wyczerpaniu innych opcji.

12. Rozwiązanie nr 9: Rozwiązywanie problemów z kopiowaniem bazy danych

Konfiguracje lustrzanego odbicia bazy danych mogą powodować specyficzne problemy z odzyskiwaniem. Ta poprawka rozwiązuje problemy specyficzne dla lustrzanego odbicia, które utrzymują bazy danych w stanie odzyskiwania.

12.1 Problemy z odzyskiwaniem danych specyficzne dla dublowania

Bazy danych zdublowane mogą utknąć w procesie odzyskiwania z powodu problemów z połączeniem partnera lub punktów końcowych. Zarówno baza główna, jak i baza danych zdublowana mogą wyświetlać stan odzyskiwania.

12.2 Rozwiązania odzyskiwania lustrzanego

Uruchom ponownie punkt końcowy kopii lustrzanej:

Znajdź nazwę punktu końcowego: SELECT * FROM sys.endpoints WHERE type = 4;
Punkt końcowy zatrzymania: ALTER ENDPOINT [EndpointName] STATE = STOPPED;
Punkt końcowy początkowy: ALTER ENDPOINT [EndpointName] STATE = STARTED;

Jeśli ponowne uruchomienie punktu końcowego się nie powiedzie, należy przerwać partnerstwo lustrzane:

Wykonaj: ALTER DATABASE [DatabaseName] SET PARTNER OFF;
Biegać: RESTORE DATABASE [DatabaseName] WITH RECOVERY;
Ponowna konfiguracja funkcji lustrzanej po uruchomieniu bazy danych

13. Rozwiązanie nr 10: Użyj profesjonalnych narzędzi do odzyskiwania danych

Narzędzia do odzyskiwania danych innych firm zapewniają zaawansowane możliwości naprawy, gdy są wbudowane SQL Server Metody te zawodzą. Te narzędzia często pozwalają odzyskać dane z poważnie uszkodzonych baz danych.

13.1 DataNumen SQL Recovery

DataNumen SQL Recovery ma wysoki wskaźnik odzysku i oferuje kompleksowe opcje.

Poniżej przedstawiono instrukcję jego użycia:

Zatrzymaj SQL Server Serwis.
Utwórz kopię plików bazy danych w trybie odzyskiwania, obejmującą zarówno podstawowy plik MDF, jak i pomocnicze pliki NDF.
Uruchom SQL Server Serwis.
Uruchom DataNumen SQL Recovery.
Zamiast oryginalnego pliku wybierz kopię jako źródło bazy danych do odzyskania.
Kliknij „Rozpocznij odzyskiwanie” i postępuj zgodnie z instrukcjami, aby odzyskać bazę danych.
Po zakończeniu procesu odzyskiwania pojawi się nowa baza danych odzyskiwania. SQL Server który zawiera wszystkie odzyskane dane.

13.2 Kiedy warto rozważyć narzędzia innych firm

Używaj profesjonalnych narzędzi, gdy:

Wbudowane opcje naprawy zawodzą lub zgłaszają poważne uszkodzenia
Brak dostępnych ostatnich kopii zapasowych
Należy odzyskać krytyczne dane pomimo ich uszkodzenia
Standardowe metody odzyskiwania danych powodują znaczną utratę danych

14. Najlepsze praktyki zapobiegawcze

14.1 Regularne zadania konserwacyjne

Wdrażaj te praktyki, aby zapobiegać SQL Server baza danych w problemach z odzyskiwaniem:

Zaplanuj regularne wykonywanie pełnych kopii zapasowych i kopii dziennika: Utrzymuj kompletne łańcuchy zapasowe
Monitoruj liczbę VLF: Aby uzyskać optymalną wydajność, utrzymuj wartości VLF poniżej 100
Rozmiar pliku dziennika planu: Wstępnie dostosuj rozmiar dzienników, aby uniknąć nadmiernego automatycznego wzrostu
Uruchom regularnie DBCC CHECKDB: Wykryj korupcję na wczesnym etapie

14.2 Monitorowanie i alarmowanie

Skonfiguruj proaktywne monitorowanie:

Konfiguruj alerty dotyczące zmian stanu bazy danych
Monitoruj przestrzeń dyskową na dyskach z plikami dziennika
Śledź długotrwałe transakcje
Alert w przypadku nadmiernej liczby komórek VLF

14.3 Sprzęt i infrastruktura

Zapewnij niezawodną infrastrukturę:

Użyj szybkiego magazynu do przechowywania dzienników transakcji (najlepiej dysków SSD)
Wdrożenie redundantnych zasilaczy
Oddzielne pliki danych i dziennika na różnych dyskach
Rozważać rozwiązania o wysokiej dostępności lubić Grupy dostępności Always On

15. Rozwiązywanie problemów w złożonych scenariuszach

15.1 Problemy z wieloma bazami danych

Gdy wiele baz danych utknęło w procesie odzyskiwania:

Sprawdź, czy nie występują problemy w całym systemie (przestrzeń dyskowa, pamięć)
Nadaj priorytet krytycznym bazom danych w celu ich odzyskania
Weź pod uwagę problemy sprzętowe wpływające na całą instancję
Przejrzyj ostatnie zmiany lub aktualizacje systemu

15.2 Rozważania dotyczące dużych baz danych

W przypadku baz danych powyżej 1 TB:

Należy spodziewać się dłuższego czasu rekonwalescencji (potencjalnie kilku dni)
Zapewnij odpowiednią alokację pamięci
Rozważ ustawienia przetwarzania równoległego
Monitoruj przestrzeń tempdb podczas odzyskiwania

15.3 Kiedy skontaktować się z pomocą techniczną firmy Microsoft

Skontaktuj się z pomocą techniczną firmy Microsoft w sprawie:

Krytyczne systemy produkcyjne bez opcji tworzenia kopii zapasowych
Podejrzany SQL Server błędy oprogramowania
Środowiska korporacyjne wymagające gwarantowanego odzyskiwania
Złożone scenariusze Always On lub klastrowania

16. Często zadawane pytania

P: Jak długo powinno SQL Server ile zazwyczaj trwa odzyskiwanie bazy danych?

O: Czas odzyskiwania zależy od rozmiaru bazy danych, wolumenu transakcji i wydajności sprzętu. Małe bazy danych zazwyczaj odzyskują się w ciągu kilku minut, podczas gdy duże bazy danych z rozbudowanymi dziennikami transakcji mogą potrzebować kilku godzin. Szacunki czasu wyświetlane w dziennikach błędów są często niedokładne, dlatego należy skupić się na procentach postępu.

P: Czy mogę przestać SQL Server podczas odzyskiwania bez utraty danych?

A: Zatrzymanie SQL Server Podczas odzyskiwania jest zazwyczaj bezpieczne, ale proces odzyskiwania zostanie uruchomiony od nowa po ponownym uruchomieniu usługi. Wydłuża to całkowity czas odzyskiwania, ale nie powoduje dodatkowej utraty danych poza tą, która miała miejsce podczas pierwotnego incydentu.

P: Jaka jest różnica między stanami „W trakcie odzyskiwania” i „Oczekiwanie na odzyskanie”?

A: „W trakcie rekonwalescencji” oznacza SQL Server Aktywnie wykonuje operacje odzyskiwania. „Oczekiwanie na odzyskiwanie” oznacza, że proces odzyskiwania nie rozpoczął się, zazwyczaj z powodu brakujących plików, niewystarczających uprawnień lub problemów z miejscem na dysku, które należy rozwiązać przed kontynuacją odzyskiwania.

Bardziej szczegółowe informacje na temat „Oczekiwania na odzyskanie” znajdziesz w naszym obszerny przewodnik.

P: Czy utracę dane jeśli użyję opcji REPAIR_ALLOW_DATA_LOSS?

O: Tak, REPAIR_ALLOW_DATA_LOSS może usunąć uszkodzone dane, aby przywrócić spójność bazy danych. Zawsze najpierw wypróbuj REPAIR_REBUILD, który naprawia problemy strukturalne bez utraty danych. Używaj REPAIR_ALLOW_DATA_LOSS tylko w ostateczności, gdy nie masz innych opcji odzyskiwania.

P: Czy mogę uzyskać dostęp do innych baz danych, gdy jedna z nich jest odzyskiwana?

A: Tak, inne bazy danych na tym samym SQL Server Instancje pozostają dostępne podczas odzyskiwania. Niedostępna jest tylko baza danych poddawana odzyskiwaniu. Operacje odzyskiwania mogą jednak mieć wpływ na ogólną wydajność serwera.

P: Co powoduje, że baza danych zatrzymuje się w trybie odzyskiwania?

A: Typowe przyczyny to niekompletne operacje przywracania z użyciem funkcji NORECOVERY, nadmierna liczba plików dziennika wirtualnego (VLF), duże niezatwierdzone transakcje, uszkodzenie bazy danych, niewystarczająca ilość miejsca na dysku oraz problemy sprzętowe. Bazy danych z włączoną funkcją AUTO CLOSE mogą również sprawiać wrażenie, że ciągle przechodzą w tryb odzyskiwania.

P: Jak mogę sprawdzić, czy proces zdrowienia postępuje, czy stoi w miejscu?

A: Monitor SQL Server Dzienniki błędów dla komunikatów o postępie odzyskiwania, pokazujące procenty ukończenia. Użyj sys.dm_exec_requests, aby sprawdzić aktywne polecenia STARTUP bazy danych. Jeśli procenty rosną z czasem, odzyskiwanie postępuje. Brak nowych wpisów w dzienniku przez kilka godzin może wskazywać na zatrzymanie procesu.

P: Czy ponowne uruchomienie jest bezpieczne? SQL Server usługi w trakcie odzyskiwania?

A: Ponowne uruchomienie jest bezpieczne, ale należy je wykonywać ostrożnie. Spowoduje to ponowne uruchomienie odzyskiwania od początku, co może podwoić czas odzyskiwania. Ponowne uruchomienie należy wykonać tylko wtedy, gdy odzyskiwanie wydaje się całkowicie zablokowane i nie ma postępu przez wiele godzin lub gdy podejrzewasz, że proces rzeczywiście utknął.

P: Jaka jest różnica pomiędzy trybem AUTOMATYCZNEGO ZAMKNIĘCIA a trybem odzyskiwania?

A: Funkcja AUTO CLOSE automatycznie zamyka bazy danych, gdy nie ma połączeń, a następnie otwiera je ponownie dla nowych połączeń. To wielokrotne otwieranie uruchamia krótkie procesy odzyskiwania, sprawiając wrażenie, że baza danych jest stale odzyskiwana. Wyłączenie funkcji AUTO CLOSE rozwiązuje ten problem.

P: Czy kopie zapasowe dziennika transakcji mogą być pomocne w odzyskiwaniu danych?

O: Kopie zapasowe dziennika transakcji mogą zwolnić miejsce w dzienniku, jeśli dysk dziennika jest pełny, co potencjalnie umożliwia kontynuowanie odzyskiwania. Nie można jednak utworzyć kopii zapasowej dziennika bazy danych, która jest aktualnie w trybie odzyskiwania. Kopie zapasowe dziennika są bardziej przydatne w profilaktyce i konserwacji po odzyskaniu.

P: Kiedy powinienem skontaktować się z pomocą techniczną firmy Microsoft?

A: Skontaktuj się z pomocą techniczną firmy Microsoft w przypadku krytycznych systemów produkcyjnych, w których wbudowane metody odzyskiwania zawodzą, jeśli podejrzewasz SQL Server błędy oprogramowania, w przypadku złożonych scenariuszy Always On lub klastrowania albo gdy środowiska korporacyjne wymagają gwarantowanego odzyskiwania danych przy minimalnym przestoju.

P: Jak mogę zapobiec blokowaniu się baz danych w trakcie odzyskiwania?

A: Wdrażaj regularne pełne kopie zapasowe i kopie dziennika, monitoruj i zarządzaj liczbami plików VLF, zapewnij odpowiednią ilość miejsca na dysku, stosuj odpowiednie procedury wyłączania, dbaj o niezawodność sprzętu, wyłącz funkcję AUTO CLOSE w bazach danych produkcyjnych i regularnie uruchamiaj operacje DBCC CHECKDB w celu wczesnego wykrywania uszkodzeń.

P: Czym są VLF i dlaczego wpływają na gojenie?

A: Wirtualne pliki dziennika (VLF) to wewnętrzne segmenty plików dziennika transakcji. Zbyt duża liczba plików VLF (ponad 1,000) znacznie spowalnia odzyskiwanie, ponieważ SQL Server Należy przetwarzać każdy z nich indywidualnie. Prawidłowe rozmiary plików dziennika i ustawienia wzrostu pomagają utrzymać optymalną liczbę VLF.

P: Czy mogę przywrócić dane z kopii zapasowej, gdy baza danych jest w trakcie odzyskiwania?

A: Nie można przywrócić bazy danych, która jest obecnie w trybie odzyskiwania. Należy poczekać na zakończenie odzyskiwania lub zatrzymać SQL Server Usługa lub przywróć bazę danych pod inną nazwą. W nagłych przypadkach rozważ przywrócenie bazy danych pod nową nazwą, a następnie jej zmianę po rozwiązaniu problemów z odzyskiwaniem.

17. Wnioski i dalsze kroki

17.1 Podsumowanie kluczowych rozwiązań

Kiedy twój SQL Server baza danych jest w trakcie odzyskiwania, zacznij od poniższych podejść w podanej kolejności:

Sprawdź dzienniki błędów i monitoruj postęp
Jeśli postęp jest stały, poczekaj na naturalne zakończenie
Użyj opcji PRZYWRÓĆ Z ODZYSKIWANIEM w przypadku niekompletnych przywracań
Rozwiązywanie problemów z dziennikiem transakcji
Uruchom DBCC CHECKDB lub profesjonalne narzędzia do wykrywania korupcji
W poważnych przypadkach należy rozważyć przywrócenie kopii zapasowej

Większość SQL Server W sytuacjach odzyskiwania danych problemy rozwiązują się w ciągu kilku godzin dzięki tym sprawdzonym metodom. W przypadku złożonych scenariuszy nie wahaj się skorzystać z zaawansowanych technik lub profesjonalnych narzędzi.

17.2 Dodatkowe zasoby

Aby uzyskać dalszą pomoc:

Microsoft SQL Server Dokumenty
SQL Server forum społecznościowe
Blogi i zasoby techniczne dotyczące administracji bazami danych
Profesjonalne usługi odzyskiwania baz danych

Regularna konserwacja i monitorowanie zapobiegają większości problemów z odzyskiwaniem danych. Wdrażaj praktyki zapobiegawcze opisane w tym przewodniku, aby zminimalizować ryzyko wystąpienia problemów z odzyskiwaniem danych w przyszłości.

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.

SQL Server Baza danych w trybie odzyskiwania: 10 sprawdzonych rozwiązań [Przewodnik 2026]