24x7 vs 야간 시간 창

연중 무휴 운영으로 더 잘 전환하는 방법에 대한 리소스는 어디에서 찾을 수 있습니까? 큰 데이터베이스를 보유한 대기업은 어떻게 이것을 달성합니까? 다음과 같은 야간 작업

1. 오래된 데이터 제거
2. 재색 인
3. 통계 업데이트

모두 Google 시스템에 중대한 영향을 미치는 것으로 보입니다 ( 예 : 온라인 사용자 및 실시간 데이터 피드). 이 주제와 관련된 모든 책을 아마존에서 찾았지만 지금까지 아무것도 찾지 못했습니다.

24x7 데이터베이스 유지 관리는 고려해야 할 옵션이 많은 상당히 큰 주제입니다. 이 광범위한 주제에는 고려해야 할 항목이 많지만 일부 요점을 바탕으로 시도해 볼 수 있습니다.

가장 먼저 식별하고자하는 것은 많은 작업이 연중 무휴이지만 활동이 적은 시간이 있다는 것입니다. 유지 관리를 실행하는 데이 시간을 활용하여 데이터베이스에 대한 간섭을 줄일 수 있습니다. 두 번째는 서비스 팩 또는 데이터베이스 마이그레이션과 같은 완전한 중단을 위해 시간을 예약해야하므로 관리 부서와 전체 유지 관리 기간을 협상해야합니다. 특정 품목의 경우 각 품목을 고려하고 계획하고 도구를 적절하게 활용해야합니다. 중요한 부분은 각각을 계획 해야한다는 것입니다. 제가 제공하는 모든 예는 "마일이 다를 수 있습니다".

백업

백업은 일반적으로 워크로드에 큰 영향을 미치지 않지만 많은 I / O를 소비 할 수 있으므로 고려해야합니다. 이를 적절하게 예약하고 완료하는 데 걸리는 시간을 모니터링해야합니다. 여기서 가장 큰 장애물은 연중 무휴 24 시간 운영 할 경우 매일 밤마다 전체 백업을 수행 할 수 없다는 것입니다. 전체 백업을 수행 할 수있는 시점, 차등을 수행 할 때 및 둘 다에 대한 보존 기간을 로그 백업과 함께 계획하십시오.

예를 들어, 일요일 밤 (가장 낮은 활동)에 다른 모든 밤의 차이 (월요일-토요일)에 모든 데이터베이스의 전체 백업을 실행합니다. 나는 지난 이틀 동안 디스크에 로그와 마지막 diff를 2 주간 유지합니다. 복구에 충분한 유연성을 제공하지만 필요한 경우 테이프에서 백업을 복구해야 할 수도 있습니다.

인덱스 / 통계 유지 보수

이것은 가장 일반적인 유형의 능동 유지 보수입니다. 피할 수는 없지만 그 영향을 완화 할 수 있습니다. 경험상 초기 규칙은 필요한 개체에 대해서만 유지 관리를 수행해야한다는 것입니다. 일반적인 지침은 조각난 30 %보다 크고 1000 페이지보다 큰 인덱스 만 다시 작성하는 것 입니다. 통계 자동 업데이트 가있는 경우 대부분의 통계 유지 관리를 처리하지만 일을 동기화하는 야간 작업은 나쁜 생각이 아닙니다.

Enterprise Edition이있는 경우 유지 관리를위한 다른 옵션에 액세스 할 수도 있습니다. 온라인 인덱스 리빌드 가 가장 중요합니다. 인덱스는 여전히 사용 중일 때 인덱스를 다시 빌드 할 수있게합니다 (기본적으로 인덱스를 나란히 빌드 한 다음 스왑합니다). 또한 "큰"테이블에 대한 파티셔닝 을 활용 하여 필요한 재 구축 시간을 줄일 수 있습니다.

이러한 모범 사례를 처리하는 사용자 지정 스크립트가없는 경우이 유형의 유지 관리에 가장 적합한 방법은 Ola Hallengren의 유지 관리 스크립트를 사용하는 것 입니다. 이것들은 설정 및 구성이 매우 쉽고 많은 지침을 내장하고 있습니다.

DBCC 일관성 검사

전체 워크로드에 따라 DBCC 검사가 운영에 지장을 줄 수 있습니다. 데이터베이스에 대한 DBCC 영향을 최소화하는 일반적인 두 가지 방법이 있습니다.

• PHYSICAL_ONLY-이 옵션을 실행하면 실제 페이지 수준에서 데이터베이스를 확인하고보다 포괄적 인 전체 확인을 피할 수 있습니다. 여기에는 가장 가능성있는 유형의 손상을 식별하는 내용이 포함됩니다.
• 복원 된 사본 확인-공간이 있으면 데이터베이스를 다른 인스턴스로 복원하고 복원 된 사본에 대해 DBCC 점검을 실행할 수 있습니다. 이것은 당신의 라이브 데이터베이스에 대해 같은 이야기를 할 것이지만, 당신은 분명히 활동을 방해하지 않을 것입니다. 여기서 다른 대안은 로그 전달 사본 또는 미러 된 DB에 대해 DBCC를 실행하는 것입니다.

이 블로그 게시물 은 옵션에 대한 자세한 내용을 제공합니다.

배치 작업 / ETL

이것은 실제로 프로세스 설계 방법에 달려 있습니다. ETL은 항상 다른 애플리케이션과 마찬가지로 라이브 OLTP 테이블을 방해 할 수 있으므로 몇 가지 키를 명심해야합니다.

• 다른 유지 관리 및 활동이 적은 기간에 이러한 작업을 예약하십시오.
• 성능을 위해 배치되고 배치가 너무 커서 테이블이 몇 시간 동안 잠기지 않도록 작업의 크기를 적절하게 조정하십시오. 스펙트럼 끝의 예 : RBAR (Row-by-agonizing-row) 대 단일 행 삭제.
• 스테이지 테이블을 사용하고 적절한 경우 데이터 처리를 오프라인으로하십시오. 꼭 필요한 경우에만 살아있는 물건을 만지십시오.

결론

다시 말하지만 여기에는 많은 근거가 있습니다. 이 안내서는 포괄적 인 안내서는 아니지만 일부 접근 방식에 대한 개괄적 인 개요입니다. 고 가용성 옵션 (예 : 가용성 그룹 및 장애 조치 클러스터링)에 대해서는 언급하지 않았습니다. 각 항목을 검토하고 처리 방법에 대한 계획을 세워야합니다. 여러 가지면에서, 앞으로 나아갈 때 작업을 반복하고 세분화해야합니다.

추가 자료 :

SQL Skills VLDB 유지 관리 모범 사례