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:
- Uruchom DBCC CheckDB w bazie danych „TDE_DB1”; wszystko jest dobrze, bez błędów;
- Pomyślnie wykonaj kopię zapasową bazy danych bez kompresji; PRZYWRÓĆ WERYFIKOWANY mówi, że wszystko jest dobrze;
- Pomyślnie przywróć bazę danych jako „TDE_DB2”; wszystko jest dobrze, DBCC CheckDB nie pokazuje żadnych błędów;
- Pomyślnie wykonaj kopię zapasową bazy danych „TDE_DB1” Z kompresją; PRZYWRÓĆ WERYFIKOWANE błędy, mówiąc: „Wykryto uszkodzenie zestawu kopii zapasowych”;
- 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”
- Powtórz kroki 1-3; wszystko jest dobrze;
- DROP „TDE_DB1” i „TDE_DB2”; Przywróć „TDE_DB1” z kopii zapasowej; wszystko jest dobrze;
- 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 bNAGŁÓ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 = 1Status 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