SQL 2017 TDE 데이터베이스에서 백업 압축으로 인한 손상


13

SQL Server 2017 (CU3)에서 TDE 데이터베이스 중 하나에서 백업 압축을 활성화 할 때마다 백업 프로세스가 항상 데이터베이스의 특정 페이지를 손상시킵니다. 압축하지 않고 백업을 실행해도 손상되지 않습니다. 이 문제를 확인하고 재현하기 위해 취한 단계는 다음과 같습니다.

  1. "TDE_DB1"데이터베이스에서 DBCC CheckDB를 실행하십시오. 모든 것이 좋고 오류가 없습니다.
  2. 압축하지 않고 데이터베이스를 성공적으로 백업하십시오. VERIFYONLY는 모든 것이 좋다고 말합니다.
  3. "TDE_DB2"로 데이터베이스를 복원했습니다. DBCC CheckDB는 오류가 없다.
  4. 압축하여 "TDE_DB1"데이터베이스를 성공적으로 백업하십시오. "백업 세트 손상이 감지되었습니다"라는 오류가 발생했습니다.
  5. "TDE_DB2"로 데이터베이스를 복원하려고 시도했습니다. "RESTORE가 데이터베이스의 페이지 (1 : 92454)에서 오류를 감지했습니다."
  6. 1-3 단계를 반복하십시오. 모두 좋은;
  7. DROP "TDE_DB1"및 "TDE_DB2"; 백업에서 "TDE_DB1"을 복원하십시오. 모두 좋은;
  8. 1-5 단계를 반복하십시오. 동일한 결과를 얻습니다.

요약하자면, 데이터베이스와 정기 백업은 정상인 것 같습니다. 데이터베이스에서 CHECKDB를 실행하고 백업에서 VERIFYONLY를 실행해도 오류가보고되지 않습니다. 압축으로 데이터베이스를 백업하면 손상이 발생한 것 같습니다.

다음은 오류가있는 코드 샘플입니다. (참고 : TDE 데이터베이스와 함께 압축을 사용하려면 MAXTRANSFERSIZE가 필요합니다 )

-- 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.

그런 다음 오류가 있다고보고 된 페이지를 확인하려고했지만 (항상 동일한 페이지입니다) DBCC PAGE는 ObjectId가 0이라고보고합니다. Paul Randal 의이 기사에 따르면 메타 데이터가 발견되지 않았으며 그 이유 중 하나는 페이지 자체가 손상되었고 메타 데이터를 검색하는 데 잘못된 값이 사용 되었기 때문일 수 있습니다. 그의 조언은 손상된 백업이 복원되지 않기 때문에 CHECKDB를 실행하는 것입니다.

메타 데이터를 재설정하기 위해이 SO Post (INIT 및 FORMAT을 BACKUP 명령에 추가) 제안을 시도했지만 아무것도 변경되지 않았지만 여전히 압축 백업이 손상되었습니다.

이것은 내 TDE 데이터베이스 중 하나에서만 발생합니다. 이 동일한 서버에 4 개의 다른 TDE 데이터베이스가 있으며이 문제가 없습니다. 이 특정 데이터베이스에 근본적인 문제가있을 수 있음을 알려줍니다. 쉬운 해결책은 압축을 사용하지 않는 것이지만 실제로는 더 큰 문제가 발생하는 초기 경고라고 생각합니다.

아무도 전에 이것을 본 적이 있거나 압축으로 인해 해당 페이지가 손상되는 이유를 알고 있습니까? 이 시점에서, 나는 다음에 무엇을해야할지에 대해 상실했습니다. 이전 백업에서 페이지를 복원하는 것을 고려했지만 일반 데이터베이스의 페이지가 괜찮아 보인다고 생각하지는 않습니다.

업데이트 1 : 아래는 옵션 0을 사용하는 DBCC PAGE의 결과입니다.

DBCC 실행이 완료되었습니다. DBCC가 오류 메시지를 인쇄 한 경우 시스템 관리자에게 문의하십시오.

페이지 : (1 : 92454)

완충기:

BUF @ 0x000002187AE55640

bpage = 0x000002184865E000 bhash = 0x0000000000000000
bpageno = (1 : 92454) bdbid = 8 참조 = 0 bcputicks = 563 bsampleCount = 1
bUse1 = 51429 bstat = 0x809 블로그 = 0x15a
bnext = 0x0000000000000000 bDirtyContext = 0x0000000000000000 bstatir2 = 0x0000000000000000 bstatir2

페이지 헤더 :

페이지 @ 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
m_indexId (AllocUnitId.idInd) = 515 메타 데이터 0128 메타 데이터 : AllocUnit IndexId = -1 메타 데이터 : ObjectId = 0 m_prevPage = (32842 : 1881351155) m_nextPage = (13086 : -560562340)
pminlen = 36067 m_slotCnt = 8149 m_freeCnt = 51871 m_freeData = 7295 m_reservedCnt = 4810 m_lsn = (742012401actm) : 14755
m_xdesId = (12811 : 1559482793) m_ghostRecCnt = 12339
m_tornBits = -1381699202 DB Frag ID = 1

할당 상태

GAM (1 : 2) = 할당 된 SGAM (1 : 3) = 할당되지 않은
PFS (1 : 88968) = 0x0 0_PCT_FULL DIFF (1 : 6) = 변경되지 않은
ML (1 : 7) = NOT MIN_LOGGED

다른 옵션으로 DBCC PAGE를 실행하려고하면 아래 오류가 발생합니다.

옵션 1 인 DBCC PAGE : 메시지 0, 레벨 11, 상태 0, 라인 0 현재 명령에서 심각한 오류가 발생했습니다. 결과가 있으면 버려야합니다.

옵션 3이있는 DBCC PAGE : 메시지 2514, 수준 16, 상태 5, 줄 3 DBCC PAGE 오류가 발생했습니다. 잘못된 페이지 유형-덤프 스타일 3을 사용할 수 없습니다.

업데이트 2 : sys.dm_db_database_page_allocations DMO의 결과는 다음과 같습니다.

한 object_id = 75 = 1 INDEX_ID rowset_id = 281,474,981,625,856 allocation_unit_id = 281,474,981,625,856
allocation_unit_type = 1 allocation_unit_type_desc = IN_ROW_DATA extent_file_id = 1 extent_page_id = 92,448
allocated_page_iam_file_id = 1 = 104 allocated_page_iam_page_id
allocated_page_file_id = 1 allocated_page_page_id = 92,454
is_allocated is_iam_page = 0 = 0 = 0 is_mixed_page_allocation

답변:


8

이 문제는 SHRINK 작업이 실행 된 데이터베이스에서 발생하는 것으로 보입니다. 필자의 경우 SQL Server 2014 (이미 TDE로 암호화되어 있음)에서 프로덕션 데이터베이스 중 하나의 사본을 가져 와서 데이터 및 로그 파일 모두에서 DBCC SHRINKFILE을 실행 한 다음 백업을 수행하고 새 SQL에서 복원했습니다. 2017 서버. 축소의 이유는 백업 전송 속도를 높이기 위해 크기를 줄이는 것이 었습니다.

테스트로 DBCC SHRINKFILE을 실행하지 않은 데이터베이스 복사본을 복원했으며 백업 압축시 손상 문제가 없었습니다.

요약하면 테스트 결과는 다음과 같습니다.

  • 이 "shrunken"TDE 데이터베이스에 대한 일반적인 백업 / 복원 작업은 SQL 2017에서 올바르게 작동합니다.
  • “shrunken”TDE 데이터베이스 백업을 압축하면 sys.sysmultiobjrefs 테이블에서 손상이 발생한 것으로 보입니다
  • DBCC SHRINKFILE을 실행하지 않은 일반 TDE 데이터베이스의 백업 압축이 올바르게 작동하고 손상을보고하지 않습니다

이것이 SQL Server 2017에서 확인 된 버그인지는 알지 못하지만 조사 결과를 Microsoft에 보내서 조사 할 수 있도록했습니다.

따라서이 이야기의 교훈은 다음과 같습니다. 데이터베이스를 축소하지 마십시오! 이제까지! :)

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.