1000 개를 초과하는 온라인 페이지 복원

손상으로 인해 손상된 데이터베이스를 복구하려고했습니다 (I / O 실패로 인해 수정되었습니다). 데이터베이스 나 데이터베이스에 익숙하지 않습니다.

오래된 (~ 3 주) 전체 백업과 일련의 트랜잭션 로그가 제공되었지만 트랜잭션 로그가 누락되어 특정 날짜까지만 복구 할 수 있습니다. 2.5 주간의 데이터 누락이 있습니다 (이 데이터베이스에 지속적으로 추가되는 많은 데이터가 있습니다).

또한 손상된 데이터베이스의 사본을 받았습니다 (액세스 가능하지만 많은 페이지가 손상되거나 누락되었습니다).

나는 전형적인 DBCC CHECKDB명령을 시도했다 repair_allow_data_loss.

많은 사람들이 데이터베이스에오고 나서 (db는 1.5 테라 바이트 작은 괴물이며 내가하는 모든 작업은 느리고 시간이 걸립니다), 손상된 페이지에 대해 마지막으로 알려진 백업에서 온라인 페이지 복원을 시도했습니다.

그렇게하기 위해 출력 RESTORE DATABASE <foo> PAGE='pages' FROM DISK='<bar.bak>'에서 많은 명령 을 작성하는 스크립트를 작성했습니다 DBCC CHECKDB(일반적으로 정규 표현식과 고유) ... 지금까지는 좋았습니다 .1000 페이지 한도에 도달했다고 말한 시점까지 작동했습니다. restore 명령 당 파일 당 (이 db에는 8 개의 파일이 있습니다).

따라서 "온라인 복원 완료"를 요청하지만 그 방법을 잃어 버렸습니다 ... 꼬리 로그가 없거나 시작한 전체 백업보다 더 완벽한 것은 없습니다. 기본적으로 나머지 페이지를 계속 사용하기 위해 복원을 완료하는 방법을 모르겠습니다.

나는 시도 RESTORE DATABASE <foo> WITH RECOVERY했지만 작동하지 않았다, 그것은 내가 가지고 있지 않은 로그를 요구한다.

아무도 내가 여기서 무엇을 회복하려고 노력할 수 있는지에 대한 팁이 있습니까? 또는 온라인 복원을 "완료"하여 더 많은 페이지를 계속 복구 할 수있는 방법은 무엇입니까? 오프라인 복원을 시도해도 (기본적으로 WITH NORECOVERY모든 것을 추가 한 다음 마지막에 다시 가져 오려고 하면) 동일한 문제가 발생 합니까?

데이터베이스를 직접 작성하는 것은 기본적으로 취소 할 수 없습니다. 수백만 개의 행이있는 수백 개의 테이블이 있으며 그 중 어떤 것이 무엇인지에 대한 명확한 의미는 없습니다. 손상된 DB는 SELECT약 백만 행 후에 쿼리에서 실패 하지만 어디에서 해결할 수 있는지 잘 모르겠습니다. 비 클러스터형 인덱스를 모두 다시 작성하려고했지만 행 데이터가있는 손상된 페이지가 있으므로 작동하지 않습니다.

일부 데이터 손실은 허용되지만 DB의 일관성은 최소한 달성하려고 시도해야합니다.

손상된 데이터베이스는 여전히 온라인 상태이며 클라이언트는이 데이터베이스에서 작업하고 있으므로 (새 데이터를 계속 가져옵니다) 실험실 벤치에서 수행하는 모든 프로세스는 나중에 프로덕션 데이터베이스에서 재현 할 수 있어야합니다 (중단 시간이 어려울 것입니다).

이것은 SQL Server 2014 Enterprise입니다

추신 : 나는 DBA가 아닙니다 ... 나는 프로그래머이지만 클라이언트는 "전문가"SQL 재해 복구 서비스를 시도했지만 포기했습니다. 그래서 그것을 보아서 내가 할 수 있는지 보았습니다. 무엇이든하세요.

업데이트 : 많은 테스트 후에 페이지 단위로 페이지를 복원하는 것이 번거 로움이 없었으므로 아이디어를 버렸습니다. 수동 복구 (손상된 테이블에서 누락 된 레코드를 수동으로 선택하고 마지막으로 성공한 백업에 삽입)를 위해 몇 가지 자동화 된 도구 (수백, 수백 개의 테이블이 있음)를 수행하려고합니다.

표준 절차는 다음과 같습니다.

1. 복원해야 할 페이지 ID를 확보하십시오.
2. 전체 데이터베이스로 페이지 복원을 시작하십시오.
3. 가장 최근의 차등 백업을 적용하십시오.
4. 후속 로그 백업을 적용하십시오.
5. 새 로그 백업을 작성하십시오.
6. 새 로브 백업을 복원하십시오.

새 로그 백업이 적용된 후 페이지 복원이 완료되고 페이지를 사용할 수 있습니다.

복원 예

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  

참조 : 페이지 복원 (SQL Server) (Microsoft Docs) 참조 : RESTORE 문 (Transact-SQL) (Microsoft Docs)

그러나 TLOG 백업에 구멍이 있으며 위의 절차로 복원하면 원하지 않는 시간으로 데이터베이스가 다시 복원 될 수 있습니다.

당신은 복잡한 상황에 처해 있습니다.

1. 데이터베이스에 손상된 페이지가 있고 회사는 지속적으로 문제가있는 데이터베이스에 새 데이터를 추가하고 있습니다. 이로 인해 데이터베이스가 완전히 중단 될 수 있습니다. 수행 이 그 위험을 감수하고 싶어?

2. 누군가는 책임을 져야 할 것이며, 고치려고할수록 결국 그 사람이 될 것인지를 결정하기 위해 더 많은 경영진이 기울어 질 수 있습니다. 수행 이 그 위험을 감수하고 싶어?

3. 당신은 당신이 고용되지 않은 역할을함으로써 어려운 상황에 처하게됩니다. 회사 DBA 나 외부 컨설턴트가 할 수 없었던 것을 달성하려고합니다. 고귀한 몸짓 인 것 같지만 위험에 처하게됩니다. 당신은 결코 성취 할 수없는 것을 "내재적으로 약속"했을 수도 있습니다. 수행 이 그 위험을 감수하고 싶어?

4. 데이터베이스 작업을하는 누군가가 손상된 데이터를 쿼리하면 오류 메시지가 표시 될 수 있습니다. 일상 업무는 이미 영향을 받고 있습니다. 불가피하게 기다릴수록 더 많은 생산성에 영향을 미칩니다. 수행 이 그 위험을 감수하고 싶어? (이 질문은 경영진과 함께 제기 할 수도 있습니다)

5. 회사의 백업 절차에 결함이있는 것 같으며 (그렇지 않으면 TLOG 백업이 어떻게 누락 될까요?) 여전히 문제가없는 것처럼 프로덕션 데이터베이스를 실행하고 있습니다. 수행 이 그 위험을 감수하고 싶어?

내가 줄 수있는 가장 좋은 방법은 프로덕션을 중단하고 Microsoft에 문의하는 것입니다. 또는 최소한 Microsoft에 연락하여 프로덕션을 중단하십시오.

저의 글은 지나치게 신중하고 당신의 관점에서 약간 극적으로 보일 수 있지만, 비슷한 상황에서 데이터가 손실 된 DBA 경험과 개인적으로 관련 될 수 있습니다. 우리는 단지 반 일 데이터를 잃었지만, 우리는에 있었다 주변 시스템과 데이터의 재 동기화 많은 .

기다릴수록 더 비싼 복구가 될 수 있습니다.

페이지 복원에 대한 제한 사항은 공식 문서에서 인용 한 내용입니다.

페이지의 최대 수를 복원 순서로 단일 파일로 복원 할 수 있습니다 1000 . 그러나 파일에 손상된 페이지 수가 적을 경우 페이지 대신 전체 파일을 복원하십시오.

^{( 중점 광산)}

참조 : RESTORE 문-인수 (Transact-SQL) (Microsoft Docs)

모두 정상으로 돌아 오면 DBA 및 / 또는 외부 컨설턴트는 데이터베이스에 대해 다른 백업 / 복원 정책 / 프로 시저 구현을 고려할 수 있습니다. 7x24 이상이어야하므로 어떤 상황에서도 적절한 복원 기능을 제공하지 않는 백업 절차를 수행 할 위험이 없습니다.

데이터 복구 "전문가"로 작업하여이 손상된 데이터베이스를 특히 1TB가 넘는 크기로 복구하는 등 다양한 방법을 시도했습니다. 이것은 프로세스를 훨씬 어렵게 만들고 시간에 대한 경쟁을합니다. 경험 많은 DBA로서, 나는 대부분의 경우, 복원 할 수있는 좋은 백업이있는 유사한 상황을 겪었습니다. 백업이 잘못되고 데이터베이스가 손상된 경우 Stellar Phoenix SQL Database Repair tool 이라는 타사 도구를 많이 사용했습니다 . 이 도구는 손상된 데이터베이스 (.mdf 및 .ndf)를 복구하는 것으로 유명합니다. 다음은 도구의 몇 가지 기능입니다.

• 손상된 SQL 데이터베이스 (.mdf & .ndf) 파일 복구
• 테이블, 트리거, 인덱스, 키, 규칙 및 저장 프로 시저를 복구합니다

• SQL 데이터베이스에서 삭제 된 레코드 복구 수행

• 데이터베이스의 스캔 결과를 저장하여 나중에 복구 수행

• 수리 된 파일을 MSSQL, HTML, XLS 및 CSV 형식으로 저장할 수 있습니다
• MS SQL Server 2016, 2014, 2012,2008 및 이전 버전 지원

이 도구를 사용하려면 .mdf 및 .ndf 파일이 오프라인 상태 여야하므로 손상된 PROD 데이터베이스의 복사본이 있고 SQL Server 서비스를 중지하지 않아도됩니다.

가장 좋은 부분은 평가판이 복구 된 데이터베이스를 내보내거나 저장할 수 없다는 점을 제외하고 도구의 모든 기능을 제공한다는 것입니다. 복구 된 모든 데이터베이스 개체와 복구 프로세스의 여러 단계에 대한 세부 정보를 제공하는 광범위한 복구 로그 파일을 계속 볼 수 있습니다.

다운로드하여 도움이되는지 확인하십시오. 여기에서 다운로드하십시오

이 사이트에서이 도구의 작동 방식에 대한 블로그도 작성했습니다 : samosql 블로그

오늘의 영웅이되어 주셔서 감사합니다.

추신. 이 폭풍이 끝났을 때 관리 부서에 특히 이러한 데이터베이스에 대한 백업 절차를 대대적으로 점검해야한다는 것을 기억하십시오. 이 시나리오의 반복은 완전히 받아 들일 수 없습니다! :)