Kompresja kopii zapasowej powodująca uszkodzenie w bazie danych TDE SQL 2017

13

W SQL Server 2017 (CU3), ilekroć włączę kompresję kopii zapasowej w jednej z moich baz danych TDE, proces tworzenia kopii zapasowej zawsze uszkadza określoną stronę w bazie danych. Jeśli uruchomię kopię zapasową bez kompresji, nie zostanie ona uszkodzona. Oto kroki, które podjąłem, aby zweryfikować i odtworzyć ten problem:

  1. Uruchom DBCC CheckDB w bazie danych „TDE_DB1”; wszystko jest dobrze, bez błędów;
  2. Pomyślnie wykonaj kopię zapasową bazy danych bez kompresji; PRZYWRÓĆ WERYFIKOWANY mówi, że wszystko jest dobrze;
  3. Pomyślnie przywróć bazę danych jako „TDE_DB2”; wszystko jest dobrze, DBCC CheckDB nie pokazuje żadnych błędów;
  4. Pomyślnie wykonaj kopię zapasową bazy danych „TDE_DB1” Z kompresją; PRZYWRÓĆ WERYFIKOWANE błędy, mówiąc: „Wykryto uszkodzenie zestawu kopii zapasowych”;
  5. Próba przywrócenia bazy danych jako „TDE_DB2”; błędy, mówiąc: „PRZYWRACANIE wykryło błąd na stronie (1: 92454) w bazie danych”
  6. Powtórz kroki 1-3; wszystko jest dobrze;
  7. DROP „TDE_DB1” i „TDE_DB2”; Przywróć „TDE_DB1” z kopii zapasowej; wszystko jest dobrze;
  8. Powtórz kroki 1-5; uzyskać te same wyniki;

Podsumowując: Baza danych i regularne kopie zapasowe wydają się być w porządku, uruchomienie CHECKDB w bazie danych i VERIFYONLY na kopiach zapasowych nie zgłasza żadnych błędów. Wydaje się, że tworzenie kopii zapasowej bazy danych przy użyciu kompresji powoduje uszkodzenie.

Poniżej znajdują się przykłady kodu z błędami. (Uwaga: MAXTRANSFERSIZE jest wymagany do używania kompresji z bazą danych TDE )

-- Good, completes with no corruption;
BACKUP DATABASE [TDE_DB1] TO DISK = N'E:\MSSQL\Backup\TDE_DB1a.bak' WITH CHECKSUM;
RESTORE VERIFYONLY FROM DISK = N'E:\MSSQL\Backup\TDE_DB1a.bak' WITH CHECKSUM;

RESTORE DATABASE [TDE_DB2]
FROM DISK = 'E:\MSSQL\Backup\TDE_DB1a.bak'
WITH MOVE 'DataFileName' to 'E:\MSSQL\Data\TDE_DB2.mdf'
,MOVE 'LogFileName' to 'F:\MSSQL\Log\TDE_DB2_log.ldf';


-- Bad, I haz corruption;
BACKUP DATABASE [TDE_DB1] TO DISK = N'E:\MSSQL\Backup\TDE_DB1b.bak' WITH CHECKSUM, COMPRESSION, MAXTRANSFERSIZE = 131072;
RESTORE VERIFYONLY FROM DISK = N'E:\MSSQL\Backup\TDE_DB1b.bak' WITH CHECKSUM;
-- ERROR
--Msg 3189, Level 16, State 1, Line 1
--Damage to the backup set was detected.
--Msg 3013, Level 16, State 1, Line 1
--VERIFY DATABASE is terminating abnormally.

RESTORE DATABASE [TDE_DB2]
FROM DISK = 'E:\MSSQL\Backup\TDE_DB1b.bak'
WITH MOVE 'DataFileName' to 'E:\MSSQL\Data\TDE_DB2.mdf'
,MOVE 'LogFileName' to 'F:\MSSQL\Log\TDE_DB2_log.ldf';
-- ERROR
--Msg 3183, Level 16, State 1, Line 7
--RESTORE detected an error on page (1:92454) in database "TDE_DB2" as read from the backup set.
--Msg 3013, Level 16, State 1, Line 7
--RESTORE DATABASE is terminating abnormally.

Próbowałem następnie sprawdzić stronę, która zgłosiła błąd (zawsze jest to ta sama strona), ale DBCC PAGE zgłasza, że ​​ObjectId ma wartość 0. Według tego artykułu Paula Randala oznacza to, że nie znaleziono metadanych, i jednym z powodów może być uszkodzenie samej strony i użycie niepoprawnych wartości do próby wyszukania metadanych. Jego rada to uruchomienie CHECKDB, czego nie mogę zrobić, ponieważ uszkodzona kopia zapasowa nie zostanie przywrócona.

Próbowałem sugestii z tego wpisu SO (dodawanie INIT i FORMAT do komendy BACKUP), aby zresetować metadane, ale wydaje się, że nic to nie zmieniło, nadal otrzymuję uszkodzenie skompresowanej kopii zapasowej.

Dzieje się tak tylko z jedną z moich baz danych TDE. Mam 4 inne bazy danych TDE na tym samym serwerze i nie mają tego problemu. To mówi mi, że może istnieć problem związany z tą konkretną bazą danych. Zdaję sobie sprawę, że łatwym rozwiązaniem jest po prostu nie używanie kompresji, ale wydaje mi się, że może to być wczesne ostrzeżenie o większym problemie nadchodzącym na drodze.

Czy ktoś widział to wcześniej lub miał pojęcie, dlaczego kompresja spowodowałaby uszkodzenie tej strony? W tym momencie nie jestem pewien, co robić dalej. Rozważałem przywrócenie strony z wcześniejszej kopii zapasowej, ale nie sądzę, żeby to miało znaczenie, ponieważ strona w zwykłej bazie danych wydaje się w porządku.

AKTUALIZACJA 1: Poniżej znajdują się wyniki z STRONY DBCC, z opcją 0:

Wykonanie DBCC zakończone. Jeśli DBCC wydrukuje komunikaty o błędach, skontaktuj się z administratorem systemu.

STRONA: (1: 92454)

BUFOR:

BUF @ 0x000002187AE55640

bpage = 0x000002184865E000 bhash = 0x0000000000000000
bpageno = (1: 92454) bdbid = 8 braków = 0 bcputicks = 563 bsampleCount = 1
bUse1 = 51429 bstat = 0x809 blog = 0x15a
bnext = 0x0000000000Cont0000 b

NAGŁÓWEK:

Strona @ 0x000002184865E000

m_pageId = (1: 92454) m_headerVersion = 111
m_type = 189 m_typeFlagBits = 0x2d m_level = 197
m_flagBits = 0x525e m_objId (AllocUnitId.idObj) = 788815194
mUIndaIdIdIndIndIdIlIsIt Meta IndeksId = -1 Metadane: ObjectId = 0 m_prevPage = (32842: 1881351155) m_nextPage = (13086: -560562340)
pminlen = 36067 m_slotCnt = 8149 m_freeCnt = 51871 m_freeData = 7295 m_reserved_nt1_m1 = 1984 14755
m_xdesId = (12811: 1559482793) m_ghostRecCnt = 12339
m_tornBits = -1381699202 DB Frag ID = 1

Status przydziału

GAM (1: 2) = PRZYDZIELONY SGAM (1: 3) = NIE PRZYZNANY
PFS (1: 88968) = 0x0 0_PCT_FULL DIFF (1: 6) = NIEZMIENIONY
ML (1: 7) = NIE ZLOGOWANY

Jeśli spróbuję uruchomić STRONĘ DBCC z innymi opcjami, otrzymuję poniższe błędy:

STRONA DBCC z opcją 1: Msg 0, poziom 11, stan 0, wiersz 0 Wystąpił poważny błąd w bieżącym poleceniu. Ewentualne wyniki należy odrzucić.

STRONA DBCC z opcją 3: Msg 2514, poziom 16, stan 5, wiersz 3 Wystąpił błąd STRONY DBCC: Nieprawidłowy typ strony - styl zrzutu 3 niemożliwy.

AKTUALIZACJA 2: Oto niektóre wyniki z DMO sys.dm_db_database_page_allocations:

id_obiektu = 75 index_id = 1 rowset_id = 281474981625856 allocation_unit_id = 281474981625856
allocation_unit_type = 1 allocation_unit_type_desc = IN_ROW_DATA extent_file_id = 1 extent_page_id = 92448
allocated_page_iam_file_id = 1 allocated_page_iam_page_id = 104
allocated_page_file_id = 1 allocated_page_page_id = 92454
is_allocated is_iam_page = 0 = 0 = 0 is_mixed_page_allocation

Eric Cobb
źródło

Odpowiedzi:

8

Wygląda na to, że ten problem dotyczy baz danych, na których uruchomiono operacje SHRINK. W moim przypadku brałem kopię jednej z naszych produkcyjnych baz danych na SQL Server 2014 (która jest już zaszyfrowana za pomocą TDE), uruchamiając DBCC SHRINKFILE zarówno na plikach danych, jak i plikach dziennika, a następnie robiłem kopię zapasową i przywracałem ją na nowym SQL Serwer 2017. (Przyczyną zmniejszenia było zmniejszenie rozmiaru, aby przyspieszyć przesyłanie kopii zapasowej).

W ramach testu przywróciłem kopię bazy danych, na której nie uruchomiłem DBCC SHRINKFILE, i nie miałem problemów z uszkodzeniem podczas kompresji kopii zapasowych.

Podsumowując, wyniki moich testów są następujące:

  • Normalne operacje tworzenia kopii zapasowych / przywracania w tej „zmniejszonej” bazie danych TDE działają poprawnie w SQL 2017
  • Kompresowanie kopii zapasowych „skurczonej” bazy danych TDE wydaje się powodować uszkodzenie tabeli sys.sysmultiobjrefs
  • Kompresowanie kopii zapasowych zwykłej bazy danych TDE (bez uruchamiania DBCC SHRINKFILE) działa poprawnie i nie zgłasza uszkodzenia

Nie wiem, czy jest to potwierdzony błąd w SQL Server 2017, ale przesłałem swoje ustalenia do firmy Microsoft, aby je przejrzały.

Morał tej historii brzmi: NIE WALCUJ SWOICH BAZ DANYCH! ZAWSZE! :)

Eric Cobb
źródło