다음을 통해 공유

SQL Server 파일에 대해 OS 오류 665 및 1450이 보고됨

  • 아티클

이 문서는 를 실행하는 DBCC CHECKDB동안 OS 오류 1450 및 665가 데이터베이스 파일에 대해 보고되는 문제를 resolve, 데이터베이스 스냅샷 만들기 또는 파일 증가를 만드는 데 도움이 됩니다.

원래 제품 버전: SQL Server
원래 KB 번호: 2002606

증상

SQL Server 실행 중인 컴퓨터에서 다음 작업 중 하나를 수행한다고 가정합니다.

  • 큰 데이터베이스에 데이터베이스 스냅샷 만듭니다. 그런 다음 원본 데이터베이스에서 수많은 데이터 수정 또는 유지 관리 작업을 수행합니다.
  • 미러 데이터베이스에 데이터베이스 스냅샷 만듭니다.
  • 명령 패밀리를 DBCC CHECKDB 실행하여 큰 데이터베이스의 일관성을 검사 해당 데이터베이스에서 많은 수의 데이터 변경도 수행합니다.

참고

SQL Server 데이터베이스 스냅샷 및 DBCC CHECKDB와 같은 작업에 스파스 파일을 사용합니다.

  • 데이터베이스 백업 또는 복원.
  • 병렬 BCP 실행을 사용하고 동일한 볼륨에 쓰기를 사용하여 BCP 를 통해 여러 파일에 대량 복사를 수행합니다.

이러한 작업의 결과로 SQL Server 실행 중인 환경에 따라 SQL Server 오류 로그에 보고된 이러한 오류 중 하나 이상을 확인할 수 있습니다.

The operating system returned error 665(The requested operation could not be completed due to a file system limitation) to SQL Server during a write at offset 0x00002a3ef96000 in file 'Sam.mdf:MSSQL_DBCC18'

The operating system returned error 1450 (Insufficient system resources exist to complete the requested service.) to SQL Server during a write at offset 0x00002a3ef96000 in file with handle 0x0000000000000D5C. This is usually a temporary condition and the SQL Server will keep retrying the operation. If the condition persists, then immediate action must be taken to correct it.`

이러한 오류 외에도 다음과 같은 래치 제한 시간 오류가 발생할 수 있습니다.

Timeout occurred while waiting for latch: class *'DBCC_MULTIOBJECT_SCANNER'*, id 000000002C61DF40, type 4, Task 0x00000000038089B8 : 16, waittime 600, flags 0x1a, owning task 0x0000000006A09828. Continuing to wait.  

Timeout occurred while waiting for latch: class *'ACCESS_METHODS_HOBT_COUNT'*, id 000000002C61DF40, type 4, Task 0x00000000038089B8 : 16, waittime 600, flags 0x1a, owning task 0x0000000006A09828. Continuing to wait.

또한 및 sys.dm_os_waiting_tasks와 같은 sys.dm_exec_requests 다양한 DMV(동적 관리 뷰)를 볼 때 차단을 확인할 수도 있습니다.

드물게 SQL Server 오류 로그에 보고되고 SQL Server 메모리 덤프를 생성하는 비수익 스케줄러 문제가 발생할 수 있습니다.

원인

이 문제는 NTFS에서 많이 조각난 파일을 유지하기 위해 많은 수의 ATTRIBUTE_LIST_ENTRY 인스턴스가 필요한 경우에 발생합니다. 공간이 파일 시스템에 의해 이미 추적된 클러스터 옆에 있는 경우 특성은 단일 항목으로 압축됩니다. 그러나 공간이 조각화된 경우 여러 특성으로 추적해야 합니다. 따라서 파일 조각화가 많을 경우 특성이 소진되고 665 오류가 발생할 수 있습니다. 이 동작은 다음 KB 문서에서 설명합니다. NTFS 볼륨의 조각화된 파일이 특정 크기를 초과하여 증가하지 않을 수 있습니다.

SQL Server 또는 다른 애플리케이션에서 만든 일반 및 스파스 파일은 이러한 스냅샷 파일의 수명 동안 많은 양의 데이터 수정이 발생할 때 이러한 수준으로 조각화될 수 있습니다.

동일한 볼륨에 있는 모든 스트라이프 파일 집합에서 데이터베이스 백업을 수행하거나 동일한 볼륨의 여러 파일로 데이터를 대량 복사(BCP-ing)하는 경우 쓰기가 인접한 위치에 있지만 다른 파일에 속할 수 있습니다. 예를 들어 한 스트림은 201에서 400 사이의 오프셋에 쓰고, 다른 스트림은 401에서 600으로 쓰고, 세 번째 스트림은 601에서 800으로 쓸 수 있습니다. 이 프로세스는 다른 스트림에도 계속됩니다. 이렇게 하면 동일한 물리적 미디어에서 파일 조각화가 발생합니다. 각 백업 파일 또는 BCP 출력 스트림은 인접한 스토리지를 가져오지 못하기 때문에 특성 스토리지를 소진할 수 있습니다.

SQL Server 엔진이 NTFS 스파스 파일 및 대체 데이터 스트림을 사용하는 방법에 대한 전체 배경은 자세한 내용을 참조하세요.

해결 방법

다음 옵션 중 하나 이상을 사용하여 이 문제를 resolve 것이 좋습니다.

  1. 데이터베이스 파일을 ReFS(복원 파일 시스템) 볼륨에 배치합니다. 이 볼륨에는 NTFS에서 제공하는 것과 동일한 ATTRIBUTE_LIST_ENTRY 제한이 없습니다. 현재 NTFS 볼륨을 사용하려면 데이터베이스 파일을 일시적으로 다른 곳으로 이동한 후 ReFS를 사용하여 다시 포맷해야 합니다. ReFS를 사용하는 것이 이 문제를 해결하는 가장 좋은 장기 솔루션입니다.

    참고

    SQL Server 2012 및 이전 버전은 스파스 파일 대신 명명된 파일 스트림을 사용하여 스냅샷을 만들었습니다CHECKDB. ReFS는 파일 스트림을 지원하지 않습니다. ReFS의 SQL Server 2012 파일에서 실행 DBCC CHECKDB 하면 오류가 발생할 수 있습니다. 자세한 내용은 DBCC CHECKDB가 SQL Server 2014부터 내부 스냅샷 데이터베이스를 만드는 방법의 참고 사항을 참조하세요.

  2. 데이터베이스 파일이 있는 볼륨을 조각화합니다. 조각 모음 유틸리티가 트랜잭션인지 확인합니다. SQL Server 파일이 있는 드라이브 조각 모음에 대한 자세한 내용은 SQL Server 데이터베이스 드라이브 및 권장 사항을 조각 모음할 때의 예방 조치를 참조하세요. 파일에서 이 작업을 수행하려면 SQL Server 종료해야 합니다. 안전 조치로 파일을 조각 모음하기 전에 전체 데이터베이스 백업을 만드는 것이 좋습니다. 조각 모음은 SSD(반도체 드라이브) 미디어에서 다르게 작동하며 일반적으로 문제를 해결하지 않습니다. 파일을 복사하고 SSD 펌웨어가 실제 스토리지를 다시 패키징하도록 허용하는 것이 더 나은 솔루션인 경우가 많습니다. 자세한 내용은 더 이상 DBCC에 대한 운영 체제 오류(665 - 파일 시스템 제한)를 참조하세요.

  3. 파일 복사 - 파일의 복사본을 수행하면 프로세스에서 바이트가 긴밀하게 압축될 수 있으므로 더 나은 공간 확보가 가능합니다. 파일을 복사하거나 다른 볼륨으로 이동하면 특성 사용량이 줄어들고 OS 오류 665를 방지할 수 있습니다. 하나 이상의 데이터베이스 파일을 다른 드라이브에 복사합니다. 그런 다음 파일을 새 볼륨에 그대로 두거나 원래 볼륨으로 다시 복사할 수 있습니다.

  4. /L 옵션을 사용하여 큰 FRS를 가져와 NTFS 볼륨의 서식을 지정합니다. 이 선택은 더 커지므로 ATTRIBUTE_LIST_ENTRY 이 문제를 완화할 수 있습니다. 후자는 데이터베이스 스냅샷 대한 스파스 파일을 만들기 때문에 이 선택은 사용할 DBCC CHECKDB 때 유용하지 않을 수 있습니다.

    참고

    Windows Server 2008 R2 및 Vista를 실행하는 시스템의 경우 명령을 사용하여 옵션을 format 사용하기 /L 전에 먼저 KB 문서 967351 핫픽스를 적용해야 합니다.

  5. 큰 데이터베이스를 더 작은 파일로 분할합니다. 예를 들어 8TB 데이터 파일이 하나 있는 경우 8개의 1TB 데이터 파일로 분리할 수 있습니다. 이 옵션은 작은 파일에서 더 적은 수의 수정이 발생하므로 특성 소모가 발생할 가능성이 적기 때문에 도움이 될 수 있습니다. 또한 데이터를 이동하는 과정에서 파일이 압축적으로 구성되고 조각화가 줄어듭니다. 다음은 프로세스를 간략하게 설명하는 개략적인 단계입니다.

    1. 동일한 파일 그룹에 7개의 새 1TB 파일을 추가합니다.
    2. 기존 테이블의 클러스터형 인덱스를 다시 빌드하여 각 테이블의 데이터를 8개 파일로 자동으로 분산합니다. 테이블에 클러스터형 인덱스가 없는 경우 인덱스 하나를 만들고 삭제하여 동일한 작업을 수행합니다.
    3. 이제 약 12% 가득 찬 원래 8TB 파일을 축소합니다.

  6. 데이터베이스 자동 증가 설정: NTFS 특성의 프로덕션 성능 및 압축에 도움이 되는 크기를 확보하도록 자동 증가 증분 데이터베이스 설정을 조정합니다. 자동 증가 발생 빈도가 낮고 증가 증가 크기가 클수록 파일 조각화 가능성이 줄어듭니다.

  7. 성능 향상을 사용하여 명령 수 DBCC CHECK 명을 줄여 665 오류를 방지합니다. DBCC CHECKDB 명령이 향상되면 PHYSICAL_ONLY 옵션을 사용할 때 성능이 더 빨라질 수 있습니다. 스위치를 PHYSICAL_ONLY 사용하여 실행 DBCC CHECKDB 해도 이 오류를 방지할 수 있다는 보장은 없지만 대부분의 경우 가능성이 줄어듭니다.

  8. 여러 파일(스트라이프 집합)에서 데이터베이스 백업을 수행하는 경우 파일 MAXTRANSFERSIZEBLOCKSIZE 수를 신중하게 계획하고( BACKUP 참조) 목표는 더 큰 바이트 청크를 파일에 함께 작성하여 일반적으로 수행되는 파일 시스템의 조각을 줄이는 것입니다. 더 빠른 성능과 조각화 감소를 위해 여러 볼륨에 걸쳐 파일을 스트라이프하는 것이 좋습니다.

  9. BCP를 사용하여 여러 파일을 동시에 작성하는 경우 유틸리티 쓰기 크기를 조정합니다(예: BCP 일괄 처리 크기 늘리기). 또한 조각화를 방지하거나 병렬 쓰기 수를 줄이려면 여러 스트림을 다른 볼륨에 쓰는 것이 좋습니다.

  10. 를 실행 DBCC CHECKDB하려면 가용성 그룹 또는 로그 전달/대기 서버 설정을 고려할 수 있습니다. 또는 명령을 실행 DBCC CHECKDB 하여 작업을 오프로드하고 스파스 파일의 과도한 조각화로 인한 문제가 발생하지 않도록 할 수 있는 두 번째 서버를 사용합니다.

  11. 를 실행할 DBCC CHECKDB때 데이터베이스 서버에 작업이 거의 없을 때 명령을 실행하면 스파스 파일이 가볍게 채워집니다. 파일에 대한 쓰기가 적을수록 NTFS에서 특성이 소진될 가능성이 줄어듭니다. 작업이 적은 것은 가능한 경우 두 번째 읽기 전용 서버에서 실행 DBCC CHECKDB 해야 하는 또 다른 이유입니다.

  12. SQL Server 2014를 실행하는 경우 최신 서비스 팩으로 업그레이드합니다. 자세한 내용은 수정: 2014년 SQL Server columnstore 인덱스가 포함된 데이터베이스에 대해 DBCC CHECKDB 명령을 실행할 때 OS 오류 665를 참조하세요.

추가 정보