여러 날에 걸쳐 DBCC CHECKDB 나누기

매우 큰 데이터베이스에 대해 며칠 동안 DBCC CHECKDB를 수동으로 분산시키는 Paul Randal의 방법 을 구현하려고 노력하고 있습니다.

• 데이터베이스의 테이블을 대략 7 개의 버킷으로 나누기
• 일주일에 두 번 DBCC CHECKALLOC 실행
• 일주일에 한 번 DBCC CHECKCATALOG 실행
• 매일 한 버킷에서 DBCC CHECKTABLE 실행

이 기술을 사용한 사람이 있습니까? 기존 스크립트가 있습니까?

나는 이것이 실제로 CHECKDB 가하는 모든 것을 다루지 않을 수도 있다고 우려합니다. CHECKDB의 온라인 설명서에는 CHECKALLOC, CHECKCATALOG 및 CHECKTABLE 외에도 다음과 같은 내용이 포함되어 있습니다.

• 데이터베이스에서 모든 인덱싱 된 뷰의 내용을 확인합니다.
• FILESTREAM을 사용하여 파일 시스템에 varbinary (max) 데이터를 저장할 때 테이블 메타 데이터와 파일 시스템 디렉토리 및 파일 간의 링크 레벨 일관성을 검증합니다. (SQL 2008 만 해당)
• 데이터베이스에서 Service Broker 데이터의 유효성을 검사합니다.

내 질문은 다음과 같습니다.

1. 이러한 추가 점검이 필요 / 중요합니까? (인덱싱 된 뷰는 아마도 나에게 조금 더 관련이 있습니다. 아직 Service Broker 또는 FILESTREAM을 사용하고 있다고 생각하지 않습니다.)

2. 그렇다면 이러한 추가 검사를 별도로 수행 할 수있는 방법이 있습니까?

3. CHECKALLOC 및 CHECKCATALOG는 큰 DB에서도 매우 빠르게 실행되는 것으로 보입니다. 매일 이것을 운영하지 않는 이유는 무엇입니까?

(참고 : 이는 수백 대의 서버 또는 특정 크기 이상의 모든 데이터베이스에있는 수천 개의 기존 데이터베이스에 대한 표준 루틴입니다. 이는 CHECKFILEGROUP을 사용하도록 모든 데이터베이스를 재구성하는 것과 같은 옵션이 실제로 실용적이지 않음을 의미합니다.)

이러한 추가 점검이 필요 / 중요합니까? (인덱싱 된 뷰는 아마도 나에게 조금 더 관련이 있습니다. 아직 Service Broker 또는 FILESTREAM을 사용하고 있다고 생각하지 않습니다.)

DBCC CHECKTABLE WITH EXTENDED_LOGICAL_CHECKS 인덱싱 된 뷰 에서 직접 실행할 수 있습니다 . 특정 상황 에서는 인덱싱 된 뷰를 확인하는 것이 문제가 될 수 있으므로 그 결과로 오 탐지를 조사 할 수 있도록 준비하십시오. (Paul Randal은 또한 언급 된 기사에 대한 의견에서 거짓 부정도 가능하지만 직접 경험하지는 않는다고 언급합니다.)

그렇다면 이러한 추가 검사를 별도로 수행 할 수있는 방법이 있습니까?

Service Broker 실행 또는 FILESTREAM별도로 검사를 지원 하지 않습니다.

CHECKALLOC그리고 CHECKCATALOG심지어 대형 DBS에 매우 빠르게 실행하는 것 같다. 매일 이것을 운영하지 않는 이유는 무엇입니까?

내가 아는 것은 아닙니다.

DBCC CHECKDB는 SQL Server 데이터베이스가 손상되지 않도록 100 % 확신하는 데 필수적 입니다. 그러나 데이터베이스의 크기가 커짐에 따라 연중 무휴 24 시간이라고 주장 할 때 유지 관리 기간을 찾기가 매우 어렵습니다. 수년 동안 SQL Server 팀은 특히 하드웨어로 인한 물리적 손상과 관련된 가장 일반적인 형태의 손상을 감지하는 다양한 메커니즘을 구현했습니다.

SQL Server 2005 이상에는 PAGE_VERIFY = CHECKSUM 이있어 데이터베이스 페이지의 물리적 손상을 사전에 감지하여 I / O 시스템에 기록 될 때 각 페이지에 체크섬을 추가하고 디스크에서 읽을 때 체크섬의 유효성을 검사 할 수 있습니다.

또한 CHECKSUM 을 사용한 백업 (전체 또는 차등) 은 하드웨어로 인한 모든 I / O 손상을 감지합니다.

따라서 하드웨어 손상으로 인해 SQL Server는이를 감지하고보고하는 데 효과적입니다. 중요한 손상 관련 경고 도 설정해야합니다 .

여전히 논리적 손상 , 스 크라이 블러로 인한 오류 -SQL Server 프로세스 내에서 실행되는 타사 코드 또는 Windows 커널 모드 및 / 또는 SQL Server 에서 실행되는 충분한 권한이있는 드라이버 또는 기타 소프트웨어에 의해 메모리 내 페이지가 손상되는 경우 위의 방법으로는 버그 등을 감지 할 수 없으므로 CHECKDB 가 등장합니다.

DBCC CHECKDB는 다른 방법으로는 감지 할 수없는 손상 가능성에 대한 페이지 헤더 검사를 포함하여보다 철저한 검사를 수행합니다.

기존 스크립트가 있습니까?

휠을 재창조하는 대신 Ola의 SQL Server 무결성 검사 솔루션을 살펴 보는 것이 좋습니다.

DBCC CHECKDB를 효율적으로 실행 :

CHECKDB를 실행하기 위해 데이터베이스가 많거나 데이터베이스가 많은 유지 관리 기간이 부족한 경우 창의력을 발휘해야합니다.

SQLSkills 교육에 참석 한 후 내 환경에서 구현 한 내용은 다음과 같습니다.

• 점검해야 할 테이블을 우선 순위로 정하십시오.
• 서로 다른 우선 순위를 가진 그룹으로 테이블을 분리 한 후 실행 DBCC CHECKTABLE실행과 함께 DBCC CHECKALLOC하고DBCC CHECKCATALOG
• 우선 순위가있는 테이블 이름을 저장할 작업자 테이블을 만듭니다. 우선 순위가 높은 모든 테이블 (대규모가 큰)이 한 그룹에 있지 않으면 CHECKDB가 전혀 완료되지 않습니다.
• 작업자 테이블에 유지 관리 기간이 지난 후에 CHECKDB가 종료 될 때 오케스트레이션하는 시간 초과 열을 가질 수도 있습니다.
• 그것을 실행에 테이블 당 걸린 시간 추가 DBCC CHECKTABLE, DBCC CHECKALLOC하고 DBCC CHECKCATALOG. 일반적으로 수표를 실행 하는 데 걸리는 시간을 느낄 수 있습니다.
• NOINDEX사용자 테이블에서 비 클러스터형 인덱스를 확인하지 않으므로 작업 속도가 빨라지므로 옵션을 사용하여 실행할 수도 있습니다. 데이터가 손실되지 않으므로 필요한 경우 인덱스를 삭제하고 다시 만들 수 있기 때문에 데이터 손상만큼 중요하지 않기 때문에 이점이 있습니다.

분명히 Enterprise Edition은 DBCC 문의 병렬 실행을 활용할 수 있지만 모든 CPU를 사용하게 될 수 있으므로 MAXDOP 설정을 찾으십시오. 이것은 리소스 관리자에 의해 제한 될 수 있습니다.

참고 : SPARSE 열이있는 경우 여기에 설명 된대로 CHECKDB가 느리게 작동 합니다 .

마지막으로, 사용 가능한 모든 도구 세트 + 데이터베이스 서버 하드웨어 시스템에 대한 믿음과 가장 중요한 데이터 가치를 활용하여 데이터베이스 손상을 방지하는 방법입니다.

훌륭한 참고 자료 :

• CHECKDB는 필수입니까?
• DBCC 검사 및 테라 바이트 규모 데이터베이스
• SQLU VLDB Week – 무결성 검사
• PHYSICAL_ONLY 옵션을 사용하면 DBCC CHECKDB 명령이 향상되어 성능이 향상 될 수 있습니다
• SQL Server 2008 데이터베이스 검사