Przywracanie strony online osiąga limit 1000

Zadanie polegało na próbie odzyskania bazy danych, która uległa uszkodzeniu (z powodu awarii we / wy, która została naprawiona od tego czasu). Nie znam bazy danych ani jej zawartości.

Otrzymałem starą (~ 3 tygodnie) pełną kopię zapasową i serię dzienników transakcji ... jednak brakuje dzienników transakcji, więc mogę odzyskać dane tylko do określonej daty. Brakuje około 2,5 tygodnia danych (i do tej bazy danych ciągle dodaje się dużo danych).

Dostałem również kopię uszkodzonej bazy danych (która jest dostępna, ale z dużą ilością stron uszkodzonych / brakujących).

Próbowałem typowych DBCC CHECKDBpoleceń (nadal nie repair_allow_data_loss, to będzie moja ostatnia deska ratunku, jeśli nic więcej nie zadziała).

Po wielu przychodzi i idzie do bazy danych (db jest 1,5 terabajtowym małym potworem i wszystko, co robię, jest powolne i zajmuje trochę czasu), próbowałem przywrócić stronę online z ostatniej znanej dobrej kopii zapasowej uszkodzonych stron.

Aby to zrobić, stworzyłem skrypt, który tworzy wiele RESTORE DATABASE <foo> PAGE='pages' FROM DISK='<bar.bak>'poleceń na podstawie danych DBCC CHECKDBwyjściowych (zwykle wyrażenie regularne i odrębne) ... jak dotąd tak dobrze, że działało to do momentu, w którym powiedziałem, że osiągnąłem limit 1000 stron na plik (w tym pliku db znajduje się 8 plików) na polecenie przywracania.

Więc prosi mnie o „dokończenie przywracania online”, ale nie potrafię tego zrobić ... Nie mam dziennika ogona ani niczego bardziej kompletnego niż pełna kopia zapasowa, od której zaczynam, więc Zasadniczo nie wiem, jak dokończyć przywracanie, aby kontynuować próbowanie z resztą stron.

Próbowałem, RESTORE DATABASE <foo> WITH RECOVERYale to też nie działało, prosi mnie o dziennik, którego nie mam.

Czy ktoś ma jakieś wskazówki, jak mogę spróbować odzyskać coś z tego miejsca? Lub jak „ukończyć” przywracanie online, aby móc nadal próbować odzyskać więcej stron? Czy miałbym ten sam problem, jeśli spróbuję przywrócić offline (zasadniczo dodając WITH NORECOVERYdo wszystkiego, a następnie próbując przywrócić go na końcu?)

Ręczne opracowanie bazy danych jest w zasadzie niemożliwe do wykonania ... istnieją setki tabel z milionami wierszy i nie ma jasnego znaczenia, co to jest. Uszkodzona baza danych nie powiedzie się w przypadku SELECTzapytań po kilku milionach wierszy, ale nie jestem pewien, czy uda mi się ustalić, gdzie. Próbowałem odbudować wszystkie indeksy nieklastrowane, ale istnieją uszkodzone strony z danymi wierszy, więc to też nie działało.

Pewna utrata danych byłaby akceptowalna, ale spójność w bazie danych powinna przynajmniej starać się osiągnąć.

Uszkodzona baza danych jest nadal w trybie online, a klienci nad nią pracują (więc wciąż otrzymuje nowe dane), więc każdy proces, który wykonuję na stole laboratoryjnym, powinien być później odtwarzalny w produkcyjnej bazie danych (przestoje będą trudne).

To jest SQL Server 2014 Enterprise

PS: Nie jestem DBA ... Jestem programistą, ale klient wypróbował niektóre „eksperckie” usługi odzyskiwania po awarii SQL i zrezygnowali, więc zostałem poproszony o obejrzenie i sprawdzenie, czy mógłbym Zrób cokolwiek.

Aktualizacja : po wielu testach przywracanie strona po stronie nie było możliwe, więc porzuciliśmy ten pomysł. Chcemy ręcznie odzyskać dane (ręcznie wybierając brakujące rekordy z uszkodzonych tabel i wstawić je do ostatniej znanej dobrej kopii zapasowej), wykonując do tego kilka zautomatyzowanych narzędzi (znowu są setki tabel).

Standardowa procedura to:

1. Uzyskaj identyfikatory stron, które należy przywrócić.
2. Rozpocznij przywracanie strony z pełną bazą danych.
3. Zastosuj najnowszą różnicową kopię zapasową.
4. Zastosuj kolejne kopie zapasowe dziennika.
5. Utwórz nową kopię zapasową dziennika.
6. Przywróć nową kopię zapasową LOB.

Po zastosowaniu nowej kopii zapasowej dziennika przywracanie strony jest zakończone, a następnie strony są użyteczne.

Przykład przywracania

RESTORE DATABASE <database> PAGE='1:57, 1:202, 1:916, 1:1016'  
   FROM <file_backup_of_file_B>   
   WITH NORECOVERY;  
RESTORE LOG <database> FROM <log_backup>   
   WITH NORECOVERY;  
RESTORE LOG <database> FROM <log_backup>   
   WITH NORECOVERY;   
BACKUP LOG <database> TO <new_log_backup>;   
RESTORE LOG <database> FROM <new_log_backup> WITH RECOVERY;  
GO  

Dokumentacja: Przywróć strony (SQL Server) (Dokumenty Microsoft) Dokumentacja: Instrukcje PRZYWRACANIA (Transact-SQL) (Dokumenty Microsoft)

Masz jednak luki w kopiach zapasowych TLOG, a przywrócenie powyższej procedury może przywrócić bazę danych do stanu, w którym nie chcesz.

Jesteś w skomplikowanej sytuacji.

1. Twoja baza danych ma uszkodzone strony, a Twoja firma ciągle dodaje nowe dane do bazy danych z problemami. Może to spowodować całkowity czas przestoju bazy danych. Czy ty chcesz ryzykować?

2. Ktoś zostanie pociągnięty do odpowiedzialności, a im więcej spróbujesz to naprawić, tym bardziej kierownictwo może być skłonne zdecydować, że w końcu możesz być tą osobą. Czy ty chcesz ryzykować?

3. Stawiasz się w trudnej sytuacji, przyjmując rolę, do której nie byłeś zatrudniony. Próbujesz osiągnąć coś, czego nie były w stanie osiągnąć ani firmy DBA, ani twój zewnętrzny konsultant. Chociaż może się to wydawać szlachetnym gestem, narażasz się na ryzyko. Być może „domyślnie obiecałeś” coś, czego nigdy nie będziesz w stanie spełnić. Czy ty chcesz ryzykować?

4. Gdy ktoś pracujący z bazą danych zapyta o uszkodzone dane, prawdopodobnie otrzyma komunikat o błędzie. Wpływa to już na codzienną pracę. Im dłużej będziesz czekać z nieuniknionym, tym większa będzie wydajność. Czy ty chcesz ryzykować? (To pytanie można również zadać kierownictwu)

5. Wydaje się, że procedura tworzenia kopii zapasowej w Twojej firmie jest wadliwa (w przeciwnym razie, w jaki sposób nie byłoby tworzenia kopii zapasowych TLOG?) I nadal produkujesz produkcyjną bazę danych, jakby nie było żadnych problemów. Czy ty chcesz ryzykować?

Najlepszą rekomendacją, jaką mogę ci dać, jest zatrzymanie produkcji i zadzwonienie do Microsoft! Lub przynajmniej zadzwoń do Microsoft i prawdopodobnie zatrzymaj produkcję.

Podczas gdy moje pisanie może wydawać się zbyt ostrożne i nieco dramatyzowane z twojej perspektywy, mogę osobiście odnieść się do doświadczenia jako DBA, w którym dane zostały utracone w podobnej sytuacji. Straciliśmy tylko półdniowe dane, ale musieliśmy ponownie zsynchronizować wiele danych z otaczającymi systemami .

Im dłużej zwlekasz, tym droższe może być odzyskiwanie.

Jeśli chodzi o ograniczenie na stronie, przywraca cytat z oficjalnej dokumentacji:

Maksymalna ilość stron , które mogą być przywrócone do każdego pojedynczego pliku w sekwencji przywrócenia 1000 . Jeśli jednak w pliku znajduje się więcej niż niewielka liczba uszkodzonych stron, rozważ przywrócenie całego pliku zamiast stron.

^{( moje podkreślenie )}

Odwołanie: PRZYWRACANIE instrukcji - Argumenty (Transact-SQL) (Dokumenty Microsoft)

Gdy wszystko wróci do normy, administratorzy danych i / lub zewnętrzni konsultanci mogą rozważyć wdrożenie innej zasady / procedury tworzenia kopii zapasowych / przywracania bazy danych. Ponieważ musi to być 7x24, nie można ryzykować wykonania procedury tworzenia kopii zapasowej, która nie zapewnia odpowiednich możliwości przywracania w każdej sytuacji.

Widzę, że wypróbowałeś różne metody, w tym pracę z „ekspertami” zajmującymi się odzyskiwaniem danych, w celu naprawy tej uszkodzonej bazy danych, zwłaszcza o wielkości ponad 1 TB. To sprawia, że ​​proces jest znacznie trudniejszy i wyścig z czasem. Jako doświadczony DBA natknąłem się na podobne sytuacje, w których przez większość czasu dostępne są dobre kopie zapasowe do przywrócenia. W przypadku dziedziczenia złych kopii zapasowych i uszkodzonej bazy danych mocno polegałem na narzędziu innej firmy o nazwie Stellar Phoenix SQL Repair Tool . To narzędzie jest dobrze znane z naprawy uszkodzonych baz danych (.mdf i .ndf). Poniżej znajduje się kilka funkcji tego narzędzia:

• Naprawia uszkodzone pliki bazy danych SQL (.mdf i .ndf)
• Odzyskuje tabele, wyzwalacze, indeksy, klucze, reguły i procedury składowane

• Odzyskiwanie usuniętych rekordów z bazy danych SQL

• Zapisuje wynik skanowania bazy danych, aby wykonać odzyskiwanie na późniejszym etapie

• Umożliwia zapisywanie naprawionego pliku w formatach MSSQL, HTML, XLS i CSV
• Obsługuje MS SQL Server 2016, 2014, 2012,2008 i starsze wersje

Narzędzie wymaga, aby pliki .mdf i .ndf były w trybie offline, więc działa świetnie, że masz kopię uszkodzonej bazy danych PROD i nie musisz zatrzymywać usług SQL Server.

Najlepsze jest to, że wersja testowa zapewnia pełną funkcjonalność narzędzia, z tym wyjątkiem, że naprawionej bazy danych nie można eksportować / zapisywać. Nadal będzie można wyświetlić wszystkie odzyskane obiekty bazy danych i obszerny plik dziennika naprawy, który zawiera szczegółowe informacje na temat różnych etapów procesu naprawy.

Pobierz i sprawdź, czy to pomoże. Pobierz tutaj

Napisałem również blog o tym, jak narzędzie działa na tej stronie: blogi samosql

Dzięki i HTH sprawi, że będziesz bohaterem dnia!

PS. Kiedy burza się skończy, pamiętaj, aby poinformować kierownictwo, że konieczna jest gruntowna zmiana procedur tworzenia kopii zapasowych, szczególnie w przypadku takiej bazy danych. Powtórzenie tego scenariusza jest całkowicie niedopuszczalne! :)