SQL Server 유지 관리 계획-작업 및 일정에 대한 모범 사례

Sql Server 2005 데이터베이스에 대한 유지 관리 계획을 수립해야합니다. 백업의 경우 15 분마다 매일 전체 데이터베이스 백업 및 트랜잭션 로그 백업을 수행하려고합니다. 내 문제는 내가하고 싶은 다른 작업과 얼마나 자주 해야하는지 파악하는 데 있습니다.

그래서 지금까지 이것을 염두에 두었습니다. 내 생각에 결함이 있거나 더 좋은 방법이 있으면 수정하십시오.

1. 백업-모든 테이블, 전체 백업 (일일)
2. 백업-선택된 테이블, 전체 백업 (시간별)
3. 백업-트랜잭션 로그 (15 분마다)
4. 데이터베이스 무결성 검사 (매일)
5. 인덱스 재구성 (매일)
6. 통계 업데이트 (매일)
7. 데이터베이스 축소 (매주)
8. 인덱스 재 구축 (매주)
9. 유지 보수 정리 (매일)

나는 몇 시간 전에 (다른 직업에서 비슷한 계획을 세울 때)이 작업 중 일부를 매일 실행할 필요가 없거나 매일 실행해서는 안된다는 것을 기억했습니다. 어느 것에 관해서는, 그것은 나를 탈출합니다. 재난시 데이터 손실을 줄일 수있는 더 나은 유지 관리 계획을 세우는 데 약간의 지침을 사용할 수 있지만 사용량이 많은 시간에 실행시 시스템에 부담을주지 않으며 성능도 향상시킵니다.

조롱,

이것은 모든 DBA에게 매우 일반적인 작업이며 정답은 모든 서버와 서버마다 동일하지 않습니다. 다른 많은 것들과 마찬가지로 필요한 것에 달려 있습니다.

가장 확실한 것은 이미 제안한대로 "Shrink Database"를 실행하고 싶지 않다는 것입니다. 성능에 대한 EVIL과 아래 참조는 그 이유를 보여줍니다. 디스크 및 인덱스 조각화가 발생하여 성능 문제가 발생할 수 있습니다. 자동 증가가 시작되지 않도록 데이터 및 로그 파일에 큰 크기를 사전 할당하면 더 좋습니다.

나는 당신의 # 2를 이해하지 못했습니다. 선택된 테이블 전체 백업. 이것에 대해 더 자세히 설명해 주시겠습니까?

인덱스 재구성, 통계 업데이트 및 인덱스 재구성으로이 작업을 수행하는 방법에주의를 기울여야합니다. 그렇지 않으면 더 많은 리소스를 사용하게되고 성능 문제가 발생합니다.

인덱스를 다시 작성하면 인덱스의 통계는 fullscan으로 업데이트되지만 그 이후에 통계를 업데이트하면 기본 샘플로 다시 업데이트됩니다 (테이블 크기가 8보다 큰 경우 일반적으로 테이블의 5 % 인 여러 요인에 따라 다름). 성능 문제가 발생할 수 있습니다. 보유한 에디션에 따라 온라인 인덱스 재 구축을 수행 할 수 있습니다. 이 활동을 수행하는 올바른 방법은 조각화 양을 확인하고 인덱스 재구성 또는 인덱스 재구성 + 업데이트 통계에 따라 다릅니다. 또한 통계를 더 자주 업데이트해야하는 테이블을 식별하고 통계를 더 자주 업데이트하려고 할 수 있습니다.

유지 관리 계획은 괜찮지 만 SSIS에 로그인하여 MP를 조정할 수 없다면 이러한 사용자 지정 작업을 최대한 활용하기가 어렵습니다. 그래서 나는 그것들을 사용하지 않고 MP보다 강력한 Ola Hallengren의 무료 스크립트 를 사용하는 것을 선호합니다 . 또한이 주제에 대해 Paul Randal이 참조한 기사를 따르는 것이 좋습니다.

참조 : http://technet.microsoft.com/en-us/magazine/2008.08.database.aspx

이것은 귀하의 질문에 대한 포괄적 인 답변이 아니라 좋은 출발점입니다. 추가 질문 / 의견이 있으면 HTH에 알려주십시오.

이미 답변을 수락 한 경우에도 내 경험을 공유하겠습니다. 아마 도움이 될 것입니다 :-).

1. 전체 일일 백업 (일일)-훌륭하지만 미리 정의 된 시간이 지나면 공간을 확인하고 오래된 파일을 제거하는 것을 잊지 마십시오.
2. 선택한 테이블 백업 (시간별)-왜 필요한지 이해하지 못하면 차등 백업을 사용하는 것이 좋습니다. SSIS, 스크립트, bcp 등 특정 테이블 만 어떻게 백업합니까? diff 백업과 관련하여 로그 백업 역할을 훔치기 때문에 너무 자주 예약하지 마십시오.
3. 트랜잭션 로그 백업 (15 분마다) – 훌륭합니다. 모든 데이터베이스에 필요합니까? 모든 데이터베이스가 전체 복구 모델을 사용합니까?
4. db 무결성 검사-예. 그러나 환경을 죽이지 않도록해야합니다. DBCC 체크 문은 리소스에 대해이기적이고 완전한 DB를 스캔하므로 비업무 시간 중에 스케줄해야합니다.
5. 인덱스 재구성 (매일)-강제하지 말고 필요한 경우에만 수행하십시오. 조각화와 관련하여 인덱스 DMV를 확인하고 필요에 따라 재구성하십시오. 매주 하나의 작업으로 모든 인덱스 및 통계 작업을 옮겼습니다.
6. 통계 업데이트 (매일)- 이전 질문에 대한 내 답변 을 참조하십시오 . 매일 모든 통계를 강제로 업데이트하는 대신 통계가 마지막으로 업데이트 된시기를 확인하는 것이 좋으며 경우에 따라 통계를 업데이트하는 경우도 있습니다.
7. 데이터베이스 축소 (매주)-아뇨. 파일 축소에 관한 Paul Randal의 기사를 읽으십시오 .
8. 인덱스 재 구축 (매주)-5 참조

9. 유지 보수 정리 (매일)-괜찮습니다.

10. 또한 백업을 확인하는 작업을 추가하는 것이 좋습니다. RESTORE 명령 버전이 있습니다 (verifyOnly .. 올바르게 리콜하는 경우). 매일 선호하지만 매주 말해 봅시다.

데이터가 손실 될 경우 차폐를 원한다고 언급하므로이 유지 관리 절차에서 시스템 데이터베이스를 추가해야합니다. 또한 서버 자체가 아닌 다른 머신에서 파일을 백업하도록주의하십시오. master db, msdb..etc를 다시 빌드해야 할 경우에 대비하여 파일을 어딘가에 보관하십시오. 당신의 작업에 행운을 빕니다!

늦은 답변이지만 다른 독자들에게 유용 할 수 있습니다.

보이지 않는 위험을 수반하는 유지 관리 또는보고 작업이 많이 있다는 점을 명심하십시오.

차등 백업을 매일 수행하는 동안 드라이브가 가득 차면 어떻게됩니까? 인덱스 재 구축 작업이 비정상적으로 오래 실행되면 어떻게됩니까? 데이터로드 프로세스가 광범위한 리소스 경합을 유발하여 정상적인 작업을 수행하는 경우는 어떻습니까? 이 모든 것은 계획된 사건이지만 우리가 보호하려는 바로 그 프로세스에 상당한 혼란을 야기 할 수 있습니다.

민감한 작업이나 리소스를 많이 사용하는 작업이 겹치지 않도록 서로 다른 작업이 상호 작용하고 시간을 지정하는 방법을 항상 고려하십시오.

이 기사를 먼저 읽으십시오 : http://www.sqlshack.com/removing-the-risk-from-important-maintenance-tasks-in-sql-server/

또한 SQL Server에서 중요한 유지 관리 작업을 수행하는 방법에 대해 설명합니다. 예를 들어 유지 관리 작업에 대한 간단한 검사를 구축하여 사용 가능한 리소스와 실행 전에 필요한 작업을 확인할 수 있습니다. 이를 통해 환경에서 수행하려는 작업을 처리하고 자원이 부족한 경우 의미있는 오류로 중단 할 수 있습니다.

1. 괜찮아 보인다

2. 여기서 차등 백업을 수행하면 도움이 될 수 있습니다. 그들을 위해 확실히 봐

3. 괜찮아 보인다

4. 괜찮아 보인다

5. 앞에서 언급했듯이 데이터베이스 축소는 데이터 및 로그 파일의 물리적 조각화를 생성하여보다 임의의 IO 읽기를 발생시키기 때문에 좋지 않습니다.

5, 6 및 8 : 다음을 참조하십시오.

인덱스는 최신 통계에 의존하기 때문에 실제로 사용됩니다. 이러한 작업의 순서는 상당히 중요합니다. 내가 채택한 기본 방법은 모든 사람에게 효과적이지 않을 수도 있지만 두 번의 인덱스 유지 관리를 수행하는 것입니다. 먼저 클러스터 된 인덱스를 수행 한 다음 비 클러스터형 인덱스를 수행합니다. 두 가지 방법을 모두 사용하는 방법은 다음과 같습니다. 인덱스가 충분히 크고 조각화되면 (sys.dm_db_index_physical_stats) 인덱스를 다시 작성합니다 (전체 스캔으로 통계 업데이트 포함). 인덱스가 재구성하기에 너무 작거나 재구성하기에 충분히 조각화되지 않은 경우 (100 페이지 미만 및 5 %-15 % 조각화) 먼저 인덱스 재구성을 수행합니다. 그런 다음 전체 스캔으로 통계 업데이트를 수행합니다.

이제는 인덱스 통계를 다루지 만 열 통계에 대해서는 아무것도하지 않습니다. 매주 열 통계를 업데이트하겠습니다.

이것이 어떤 식 으로든 도움이 되었기를 바랍니다!

귀하의 "데이터 손실은 여기에 법적 영향을 줄 수 있습니다"라는 의견을 기울였습니다.

그런 다음 백업을 처리 할 수있는 강력한 타사 도구 (예 : DPM과 같은)를 사용하여 인터넷을 차단할 수있는 스크립트보다 훨씬 빠르고 효율적으로 백업을 처리 할 수 ​​있습니다.

백업하는 것이 중요합니다. 응급 상황에서 사용하는 방법을 아는 것도 또 다른 방법입니다.

중대한 장애 발생 후 백업을 복원 할 시점에 이미 스트레스와 압박이 가중되고 있다는 사실을 잊지 마십시오. 12 개의 트랜잭션 로그 파일이 포함 된 RESTORE DATABASE 문을 완벽하게 파고 작성해야하는 추가 부담이 필요하지 않습니다. 그리고 기도해도 실패하지 않습니다 ...

직장에서 DPM을 사용하여 지난 주 5 분 동안 350Gb 데이터베이스를 원하는 시점으로 복구 / 복원 할 수 있습니다. GUI 인터페이스. 내 책에서 가치가 있습니다.

나머지는 확실히 Ola Hallengren의 인덱스 스크립트를 살펴보고 필요에 따라 매개 변수를 조정하십시오. 개인적으로, 나는 매일 밤마다 한 시간 동안 다시 스캔하지 않고 실행되도록 예약 된 작업과 결합하여 매번 최악의 인덱스를 처리하고 매주 토요일마다 또는 목록의 모든 인덱스가있을 때 조각화를 완전히 다시 스캔합니다. 조각 모음이 완료되었습니다.

마지막으로 "파일을 자동으로 축소하지 마십시오"그룹에 음성을 추가합니다. File Shrink는 로그 나 DB 파일 (무한 루프 등)을 과도하게 비 정기적으로 처리하는 이벤트가 발생할 때 산발적으로 사용하는 도구입니다. 유지 관리 도구가 아니어야합니다. 디스크 공간이 부족한 경우 축소는 어쨌든 불가피하게 지연됩니다.