none
윈도우 파일 시스템 제한으로 인한 DB 복구 실패 error code = 665 RRS feed

  • 질문

  • DB를 복구하면 665 error 가 뜨면서 실패합니다.

    알아본 결과 디스크 단편화가 심해서 윈도우 자체에서 파일 시스템에 제한이 걸려서 그렇다고 하는데 복구 하려는 환경은 

    윈도우 2016 서버, MsSql 2016 버전 사용중 입니다.

    백업은 분할 압축 방식 사용하여 문제 없이 진행 하였습니다.

    현재 D 드라이브 용량은 10TB 정도 되고 여유 공간은 3TB 정도 있습니다. 

    복구하려는 DB의 용량은 2TB 정도 되고요 문제는 DB 파일 하나의 크기가 1.78TB 정도 됩니다 이 파일 때문에 파일 시스템 제한에 걸리는 거 같은데 이게 단편화의 문제인지 아니면 NTFS 파일 시스템 자체의 문제인지 정확한 원인을 알고 싶습니다.

    그리고 해결 방안은 단편화 때문이라면 디스크 조각 모음과 포맷을 제외한 다른 해결방안도 알고 싶습니다.

    2020년 6월 17일 수요일 오전 7:56

답변

  • os-errors-1450-and-665-are-reported-for-database-data-files  라는 웹페이지를 검색하면 해결책들이 나오는데요. 원인은 디비 snapshot 생성 후, 많은 업데이트(update,insert,delete,merge)를 하여, 파일에 단편화가 극심해서 생긴 현상이라는데요.  정기적으로 인덱스 리빌드나, 리오그 작업을 해주는 것이, 데이타베이스 성능에도 좋은 영향을 미칠거라고 봅니다.

    NTFS 볼륨내에서 극심하게 단편화된 파일은 특정 크기 이상은 grow 하지 않아서 생긴 문제인데, 대규모 데이타 수정이 이루어지면, 이 단편화된 파일의 크기가,  더 이상 grow하지 않는 수준으로 커질수 있다고 합니다.

    디스크 조각 모음 외에, 위의 웹페이지에서 Resolution 섹션에서 소개하는 해결책 하나를, 그대로 번역해 보겠습니다.

    그 큰 디비를 좀 더 작은 파일들로 나누세요. 예를들어, 만약, 당신이 8 테라의 데이타 파일을 가지고 있다면, 이 파일을 8개의 1 테라 파일로 나눌수 있을 것입니다.  다음 단계로 그렇게 할수 있습니다.

    1.같은 파일 그룹에 새로운 1 테라 크기 파일 7개를 추가하세요.

    2. 기존 테이블들의 클러스터드 인덱스들을 리빌드 하세요. 그렇게 하면  각 테이블의 데이타를 8개의 파일들에 걸쳐 자동으로 나눠서 저장할 것입니다. 만약, 어떤 테이블이 클러스터드 인덱스가 없다면, 하나 만드시고,  인덱스 리빌드 후, drop 해서 동일 효과를 볼수 있습니다.

    3. 최초의 8 테라 파일을 shrink 하세요. 그러면,그 파일은, 12에서 15% 정도 차게 될것입니다.(8테라 데이타를 8개로 나누니, 기존 8테라 파일이 12에서 15% 차게 된다는 말)

    ♣  이부분은 제 개인적인 생각인데, 각 파일의 크기가 작아졌으므로, 향후, 단편화가 생겨도, grow 하지 않는 크기까지 파일이 커지기까지는 시간이 꽤 걸리거나, 그럴 일은 없을 것으로 보입니다.

    • 답변으로 표시됨 patk2580 2020년 6월 19일 금요일 오전 12:28
    2020년 6월 17일 수요일 오전 10:25