[오라클]유지 관리 계획

원활한 성능을 위한 자동화, 모니터링 유지 관리 작업들

 

정기적인 유지 관리는 원활하고 성공적인 데이터베이스 운영을 위해 필수적이다. 유지 관리는 데이터손실을 막기 위한 백업을 만드는 것을 포함하며, 데이터의 일관성 유지, 데이터와 인덱스간의 불일치를 막아주어 데이터 무결성을 확인하고 데이터의 단편화를 막아 정기적으로 인덱스를 갱신하는 것을 포함한다.

 

SQL서버의 데이터베이스 유지 관리 계획은 유지 관리 운영의 정의, 자동화와 모니터링 하는 것을 도와준다. 유지 관리 계획의 생성을 통해 진행되는 데이터베이스 유지 관리 계획 마법사는 보통은 각각의 유지 관리 영역에 적절한 기본값을 선택한다.

 

그러나 마법사를 사용하여 목적에 알맞은 작업을 하기 위해선 유지 보수 계획이 실행될 때 SQL 서버 T-SQL 명령들이 실행되는 각각의 옵션 내용이 어떻게 동작을 하는지 알아야 하고, 이 명령들이 데이터베이스의 성능에 어떻게 영향을 끼칠 것인지, 그리고 이 내용들은 디스크 공간의 필요에 대한 유지 관리 계획에 어떤 영향을 미칠지도 알 필요가 있다.

 

 

데이터 베이스 유지 관리 계획 아키텍처

 

데이터베이스 유지 관리 계획을 세우기 위해 데이터베이스 유지 관리 계획 마법사를 사용할 수 있다. 데이터베이스 유지 관리 계획 마법사는 하나 이상의 데이터베이스를 선택하는 것으로 시작된다. 그리고 나서 유지 관리 계획에 포함시킬 작업 내용을 포함시킨다. msdb 데이터베이스에 있는 몇몇의 시스템 테이블은 유지관리 작업 계획과 작업 내용에 대한 상세한 정보를 가지고 있다.

SQL서버는 유지관리 계획을 생성할 때 sysdbmaintplan 테이블에 엔트리를 생성한다. 여러분의 계획이 정의한 작업(무결성 체크, 최적화, 백업)을 실행할 때 마다 SQL서버는 sysdbmaintplan_history 테이블에 해당 내용을 기입한다. 마법사의 첫 단계는 유지관리 계획이 필요한 데이터베이스를 정의하는 것이다. 선택한 데이터베이스는 sysdbmaintplan_databases 테이블에 저장된다. 이 테이블은 데이터베이스 유지 관리 계획에 관련된 각 데이터 베이스 정보를 담고 있는 하나의 열을 가진다. 만약 여러 개의 데이터베이스라는 옵션을 선택한 경우 database_name 컬럼에 모든 데이터베이스, 모든 사용자 데이터베이스, 모든 시스템 데이터베이스 중 하나의 항목을 포함한다.

다음의 몇 단계는 최적화, 무결성 검사, 데이터베이스 백업, 트랜잭션 로그 백업 등 4개의 유지 관리 작업을 정의한다. 데이터베이스 유지관리 계획 마법사는 계획에 포함시킨 각각의 작업을 위한 SQL 서버 에이전트 작업을 생성하고 sysjobs 테이블에 이 작업들을 저장한다. 마법사는 sysdbmaintplan_jobs 테이블에 유지관리계획과 그 작업 사이의 링크를 저장한다.

 

각 작업은 유틸리티 스위치를 포함하는 하나의 파라미터로 xp_sqlmaint 확장 저장 프로시저를 호출하는 하나의 단계를 가지고 있다. 유틸리티 스위치는 사용자 인터페이스가 없는 실행파일을 위한 커맨드라인 파라미터로 동등하게 생각해 볼 수 있다. SQL 서버는 데이터베이스 유지관리 계획을 백그라운드 프로세스로 사용자의 개입 없이 실행한다. 따라서 유틸리티 스위치는 그 계획이 실행할 때 무엇을 할지를 정의한 파라미터로써 작용한다. 마법사는 각 계획을 위해 선택한 옵션을 위한 이 스위치들을 만들어 준다. [그림 1]에 나와 있는 작업 명령은 유틸리티 스위치를 따라 sqlmaint 유틸리티를 호출하는 xp_sqlmaint의 예제이다. Sqlmaint 은 SQL 서버 데이터베이스 유지관리 계획의 핵심적인 부분이다. 이는 유틸리티 스위치를 처리하고, T-SQL 명령을 작성하고 그것을 SQL 서버로 보낸다. Sqlmaint는 또한 오래된 데이터베이스 백업을 삭제하고, 텍스트와 html 보고서 파일을 생성할 수 있다. BOL은 sqlmaint 유틸리티 스위치에 대한 리스트를 포함 하고 있다. 이 유지 관리 계획 시스템 테이블을 테스트하다가 흥미로운 점을 발견했다. 당신이 작성한 실행계획이나 선택한 각각의 옵션도 시스템 테이블에 저장되지 않는다는 점이다. 시스템 테이블은 오직 계획과 스케줄작업에 대한 링크만을 포함한다. 유지 관리 계획을 수정하기 위해 열었을 때 엔터프라이즈 관리자는 각 관련된 작업을 읽고 계획 생성시 선택한 옵션을 얻기 위해 xp_sqlmaint 호출을 처리한다. 예를 들어 만약 [그림 2]에서 보여지는 바와 같이 유지 관리 계획이 Optimizations에 관한 내용이며 페이지당 여유공간을 10%로 변경하는 것을 선택한다면 xp_sqlmaint 호출은 정의된 동작의 하나로 RebldIdx 10을 포함한다. RebldIdx 10 은 실행 시에 그 데이터베이스의 모든 인덱스를 다시 재빌드하여 각 인덱스 페이지가 10%의 여유공간을 하는 T-SQL 명령으로 변환된다.

SQL서버는 유지 관리 계획 시스템 테이블에 이러한 정의 내용을 기록하지 않는다는 것은 중요하다. 유지 관리 계획의 구현은 합리적으로 이루어진다. 만약 이러한 정의들이 시스템 테이블에 저장된다면 누군가가 수작업으로 스케줄된 유지 관리 계획에 대한 작업 내용을 수정하는 것에 대해 막을 길이 없으므로, 시스템 테이블의 정의와 실제 스케줄상의 매치 되지 않는 정의가 생길 것이다. 
sqlmaint 유틸리티를 실행하고 계획 이름이나 ID를 지정할 때 단지 SQL서버가 시스템테이블에서 검색하는 것은 계획에 포함된 데이터베이스 리스트이다. 이는 수동으로 유지관리계획을 실행시킬 때 sqlmaint 는 계획을 생성하기 위해 마법사를 사용할 때 지정한 동작이 아니고 실행 시에 파라미터로 지정한 액션을 실행한다는 것을 의미한다. 예를 들어 마법사를 이용하여 모든 데이터베이스에 대하여 C:\BACKUP 경로에 풀 백업을 실행하고 1주 이상 지난 백업파일을 삭제하는 계획을 작성했다면 마법사는 아래와 같은 정의를 만들어 낸다.

 

EXECUTE master.dbo.xp_sqlmaint
N"-PlanID 54442E44-EF8D-488A-
AF39-FFBB3CE62D1D -BkUpMedia 
DISK -BkUpDB "C:\BACKUP"
-DelBkUps 1WEEKS "

 

위의 코드를 복사하여 쿼리분석기에 붙여 넣고 이 실행계획에 있는 각각의 데이터베이스에 대하여 DBCC CHECKDB 만을 수행하도록 백업 스위치를 ? CkDB 로 대체한다.

 

EXECUTE master.dbo.xp_sqlmaint
N"-PlanID 54442E44-EF8D-488A-
AF39-FFBB3CE62D1D -CkDB "

 

수정된 코드를 실행시킬 때 sqlmaint는 유지 관리 계획을 실행시키지만 그 계획은 풀 백업에 대해 정의 했다 하더라도 풀 백업을 실행하지 않는다. 실행 시 스위치를 제공하지 않으므로 오직 무결성 확인만을 실행할 것이다.

유지 관리 계획 아키텍처와 sqlmaints 유틸리티 스위치에 익숙해지면 무슨 조건 아래에서 어떤 옵션이 실행되는지를 얻기 위해 수동으로 유지 관리 계획에 대한 작업을 시작할 수 있다. 또한 동적으로 sqlmaint 스위치를 만들어낼 수 있으며 그 옵션을 조금 변경 후 계획을 실행 할 수도 있다. 예를 들면 백업을 하나 대신 두 개의 하드디스크에 저장하기 위해, 백업의 경로를 매번 변경할 수 있다. 당신은 유지 관리 계획을 마법사에서 하듯이 예정된 작업으로서 구현을 할 수 있고, 그것을xp_sqlmaint 확장 저장 프로시저를 통한 T-SQL로부터 호출을 할 수도 있으며 또는 배치 파일이나 응용 프로그램으로부터 sqlmaint 유틸리티를 호출할 수 있다.

 

 

유지 관리 계획 세우기

 

유지 관리 계획을 만드는 가장 쉬운 방법은 엔터프라이즈 관리자의 유지 관리 계획 마법사를 이용하는 방법이다. 마법사를 시작하기 위해 관리 노드를 확장하고 데이터베이스 유지 관리 계획을 오른쪽 클릭해서 새 유지 관리 계획 옵션을 선택한다. 첫 번째 화면은 계획을 실행할 데이터베이스를 선택하는 것이다. 데이터베이스는 각각 선택하거나 미리 정의된 multidatabase 옵션(모든 데이터베이스, 모든 시스템 데이터베이스, 모든 사용자 데이터베이스)중 하나를 선택할 수 있다. 이러한 옵션을 사용하는 것은 편리하지만 데이터베이스의 유지관리의 내용이 상황에 따라 크게 다르게 때문에 모든 환경에 적당하지는 않다. 필자는 보통 모든 시스템 데이터 베이스 옵션을 통하여 각 서버에 적용시키는 하나의 계획과, 개발용 이거나 대기중인 서버에서 모든 사용자 데이터 베이스를 사용하는 또 다른 계획을 만든다. 운용환경에선 각각의 중요한 데이터베이스에 맞는 고유한 계획을 작성한다. 그러나 모든 사용자 데이터베이스와 모든 데이터 베이스 옵션은, 해당 서버에 추가되는 모든 새로운 데이터베이스는 계획에 포함된다는 큰 혜택이 있다. 따라서 예를 들면 유지관리계획이 백업에 대한 작업을 포함하고 있을 경우 새로운 데이터베이스의 백업에 대한 내용은 자동으로 백업되므로 신경 쓸 필요가 없다.

마법사의 다음 몇 단계는 유지 관리 계획을 최적화, 무결성 확인, 데이터베이스 백업과 트랜잭션 로그 백업 등에 관한 업무를 정의하는 것이다. 이러한 각 작업들의 선택 사항을 살펴보자. [그림 2]는 데이터베이스 최적화에 관한 옵션들을 보여준다. 첫 번째 옵션은 인덱스페이지와 데이터의 재 구성에 관한 내용으로 SQL서버의 모든 테이블에 있는 모든 인덱스를 다시 만드는 것을 말한다. 데이터의 단편화에 따라 보통 인덱스를 다시 만드는 것은 데이터와 인덱스 페이지의 사이즈를 축소시킨다. 주기적인 단편화 해소에 따른 인덱스를 다시 만드는 것은 데이터베이스 쿼리 성능을 향상시킨다.

 

그림 2. 데이터베이스 최적화 옵션

 

그림 3. 데이터베이스 무결성 검사

 

왜냐하면 단편화 해소는 SQL서버가 자료를 검색하는데 검색해야 할 데이터베이스의 데이터와 인덱스페이지의 수를 감소시키기 때문이다 당신은 새로운 fill factor를 지정하거나 기존 fill factor로 인덱스를 다시 만들게 할 수 있다. 만약 예를 들어 페이지 여유공간이 10% 남게 선택했다면 sqlmaint 유틸리티가 가 DBCC DBREINDEX (TableName,", 90, sorted_data_ reorg) 명령을 실행하게 된다. 여유 공간의 양은 기존 단편화와 선택한 fill factor에 따라 복구할 수 있다. 인덱스를 다시 만드는 것은 테이블 잠금을 초래하기 때문에 인덱스 를 다시 만드는 것은 데이터베이스의 일반적인 작업과 충돌할 수 있으므로 이 작업은 데이터베이스 사용이 최소로 떨어질 때 수행 해야 할 것이다. 인덱스를 만들거나 재구성하는 것은 최대나 대량 로그 복구 모델을 이용하여 데이터 베이스에 로그되는 동작이다. 따라서 데이터베이스의 인덱스를 재구성 한 후에는 때로 풀 백업의 크기와 근접할 만큼 커진 트랜잭션 로그 백업의 크기를 기대 할 수 있다. SQL서버는 인덱스를 다시 만들 때 자동으로 인덱스 통계 정보를 업데이트하기 때문에, 최적화의 두 번째 옵션(쿼리 최적화 프로그램에 의해 사용되는 통계 정보 업데이트)은 데이터와 인덱스의 재구성을 선택하지 않은 경우만 사용 가능하게 된다. 이 옵션을 선택하는 것은 주기적으로 인덱스 통계 정보를 업데이트하는 통계 자동 업데이트 데이터베이스 기본 옵션을 변경한 경우를 제외하고 대부분 불필요하다. 유지 관리 계획의 부분으로 AUTO_UPDATE_STATISTICS 옵션을 비활성화했을 때 데이터베이스 통계정보를 업데이트하기 권장한다.

세 번째 옵션은 데이터베이스의 사용되지 않는 공간 삭제에 관한 부분으로 특별한 경우에만 사용해야 하는데, 이는 데이터베이스가 줄어들게 되는 것은 대체로 권장하지 않는 사항이기 때문이다. SQL서버 축소 작업이 일어나면, 서버는 모든 사용중인 페이지들을 데이터베이스의 파일의 처음으로 옮겨야 하고, OS에 여유공간을 돌려주어야 하며, 이는 많은 CPU 자원과 I/O를 야기 할 것이다. 그리고 나서 데이터베이스가 다시 커지기 시작하자마자, SQL서버는 같은 데이터 파일을 다시 확장해야 한다. 그러나 OS에 파일은 더 이상 인접한 공간을 차지하지 않고 있기 때문에 데이터 페이지의 단편화가 생길 것이다. 마법사에서 수행할 수 있는 두 번째 작업은 데이터베이스 무결성 검사이다. [그림 3]과 같이 무결성 탭에서 단순히 데이터만 또는 데이터와 인덱스 모두에 무결성 검사를 할 수 있다.

“사소한 문제라도 복구 시도”를 선택하면 sqlmaint 유틸리티는 REPAIR_FAST 절을 DBCC CHECKDB 명령에 포함시킨다. SQL서버는 데이터베이스가 단일 사용자 모드일 때만 데이터베이스 복구가 가능하다. 유지 관리 계획은 데이터베이스를 복구 명령이 실행되기 전 단일 사용자 모드로 바꾸길 시도할 것이다. 그렇지만 만약 데이터베이스에 다른 사용자가 있다면 그 명령은 실패할 것이고 작업 스케줄은 에러의 이유에 대한 오류 보고를 작성하며 실행되지 않는다. 데이터베이스가 단일 사용자 모드 상태에서는 DBCC명령과 함께 REPAIR_FAST 가 실행되는 중엔 다른 사용자는 데이터베이스에 접근할 수 없으므로 사용자들은 몇 분간 데이터베이스 작업을 할 수 없을 것이다. 또한 다른 작업 스케줄도 sqlmaint가 다중 사용자 모드로 되돌려 놓기 전까지는 작업을 수행할 수 없다. 그러므로 BOL에서 조차 복구 옵션에 관하여 권하고 있다 할지라도, 데이터베이스의 사용패턴과 유지 관리 작업 스케줄 실행 시점에 대하여 데이터베이스에 사용자가 없다는 것을 확신하거나 DBCC 명령의 오류가 보고되었다면 수동으로 실행시킬 필요가 있지를 평가할 필요가 있다. 백업 실행 전에 검사 수행을 선택해서 전체 백업이나 로그 백업 전에 DBCC CHECKDB 명령 실행을 수행할 수 있다. 만약 DBCC에서 문제가 발생한다면 sqlmaint는 백업을 수행하지 않을 것이다. 이 작업의 수행은 오류를 포함한 데이터 베이스의 백업을 방지하도록 설계되었으나 인덱스상의 간단한 오류나 sqlmaint가 단일 사용자모드로 전환할 수 없는 상황에서도 백업이 불가능하며 데이터는 위험에 놓이게 된다. 만약 이 옵션을 선택하면 무결성 검사에 대한 작업의 상태를 모니터링 해서 데이터베이스에 대하여 필요하다면 즉시 수정하거나 백업을 다시 할 수 있어야 한다. 이 옵션에 대한 또 다른 내용은 무결성 검사의 빈도 부분이다. 무결성 검사는 많은 리소스를 필요로 하며, 그 결과 테이블의 잠금과 그로 인하여 응용프로그램의 데이터베이스 접근을 방해하고 데이터베이스와 서버의 성능에 영향을 미칠 수 있다. 데이터베이스의 사용률이 최저로 떨어졌을 때 본 내용을 수행 하여야 한다. 불행하게도 마법사는 전체 백업 전 무결성 검사를 수행하도록 선택하게 되어 있지 않지만 로그 백업 전에는 아니다. 이 제한 사항으로 이 옵션은 로그백업을 빈번하게 해야 하는 데이터베이스로는 부적당하다. 나는 매시간 무결성 검사와 로그백업을 수행하는 대용량 데이터베이스에서 이 옵션을 사용하는 경우를 본 적이 있다. DBCC 명령을 수행하는데 20분이 걸렸으며 따라서 데이터베이스 서버는 운영시간에 1/3 정도를 무결성 검사에 자원을 사용했다.

이러한 문제를 다루기 위해, 데이터베이스 관리자들은 각각의 데이터베이스에 대한 무결성 검사와 함께 전체백업을 하는 경우와 로그백업을 수행하는 작업 등의 두 개의 유지관리 계획을 세워야 한다. 이 기사를 연구하는 동안 또 다른 업무 범위를 발견했다. 만약 마법사에서 백업이전에 무결성 검사를 선택하면 전체 백업과 로그백업에 대한 작업스케줄은 아래 두 개의 스위치를 포함하여 xp_sqlmaint 를 호출한다.

 

-BkUpOnlyIfClean -CkDB

 

만약 마법사가 만들어준 트랜잭션 로그 백업에 대한 작업 스케줄의 스위치를 수동으로 지우면 로그백업이전에는 무결성 검사는 이루어지지 않을 것이나 여전히 전체 백업은 수행될 것 이다.

그림 4. 엔터프라이즈 관리자에서 작업 정보

 

그림 5. 백업 옵션

 

트랜잭션 로그백업 작업을 [그림 4]에서 보는 바와 같이 엔터프라이즈 관리자의 관리노드 ? 서버에이전트-작업 에서 찾을 수 있다. 만약 마법사가 작업을 만든 후 수동으로 작업 명을 바꾼 적이 없다면, 트랜잭션 로그백업의 이름은 유지 관리 계획 “PlanName” 의 트랜잭션 로그 백업일 것이다. 마이크로소프트 기사 "BUG: DB Maintenance Plan Cannot Be Modified to Include/Exclude Integrity Checks Before Backups"(http://support.microsoft.com/?kbid=264194)에 설명되어 있는 버그에 대한 문제를 수정하기 위해 같은 기술을 사용할 수 있다. 이 버그는 백업이전에 기존 무결성 검사 작업이 수정되는 것을 막아주기 때문에 계획을 만들 때 옵션을 선택하는 데만 집중할 수 있도록 해준다. 옵션 스크린과 버그로 인한 수행 결과로부터의 주어진 한계에 대한 최적의 선택은 아마도 작업 스케줄 명령에 이러한 두 스위치를 수동으로 관리하는 것일 것이다.

 

 

데이터베이스 백업 옵션

 

무결성 검사를 구성하고 나면 마법사는 가장 중요한 데이터베이스 유지관리 계획인 전체 데이터베이스와 트랜잭션 로그 백업을 설정하게 된다. 백업 옵션은 [그림 5]에서 보는 바와 같이 전체 백업과 로그 백업으로 나뉜다. 유감스럽게도 유지관리 계획은 차등 백업은 지원하지 않는다. 파일이나 파일그룹 백업을 지원하지 않으므로 유지관리 계획의 부분으로서 전체 백업은 파일이나 파일 그룹 백업을 사용하는 장점을 가지는 큰 규모의 데이터베이스에 항상 유리한 것은 아니다. 완료 시 백업 무결성 확인 체크박스를 선택함으로써 백업 셋이 완전하고 읽기 가능한지를 확인하도록 유지관리 계획을 구성할 수 있다. 만약 매체로서 테이프 드라이브를 사용하는 경우 특정 백업경로를 선택할 수 있으나 성능상의 이유로 SQL 서버 백업을 로컬 하드디스크로 바로 하고 하드 디스크의 백업 파일을 테이프로 하기를 권장한다. 내가 좋아하는 sqlmaint 유틸리티 옵션은 자동으로 오래된 파일을 지우는 작업인데 수분에서 수개월까지 기간을 두어 보존할 수 있게 할 수 있다.

필자는 유지 관리 계획의 트랜잭션 로그 백업을 실행시키며 몇몇의 문제를 발견했다. 만약 단순 복구 모델을 사용하여 로그 백업을 포함시킨다면 마법사는 그 동작이 어긋난다는 경고를 주지 않고 작업 스케줄은 실패 할 것이다. ?SQL 서버 2000 만 해당 SQL 7.0은 버그를 가지고 있는데 이는 기사 "BUG: Sqlmaint Does Not Report Error on BACKUP LOG When Truncate Log on Checkpoint is Set" 로 마이크로소프트 웹사이트 (http://support.microsoft.com/?kbid=242500) 에서 확인이 가능하다. 이는 실패로 이 에러를 보고 하지 않는다. SQL 서버 2000으로 업그레이드 할 때 각 에러 없이 실행된 작업들이 에러를 발생한다면 이러한 문제점에 대해서는 수정할 필요가 있다. 이 버그는 "BUG: Expired Transaction Log Backups May Not Be Deleted by Maintenance Plan"의 문서의 내용과 다소 관계가 있다. (http://support.microsoft.com/?kbid=303292). 문서에 따르면 만약 유지관리 계획이 여러 개의 데이터베이스에 대한 로그 백업과 적어도 하나 이상의 데이터베이스를 단순복구 모델로 실행할 때 sqlmaint 유틸리티는 모든 데이터베이스에 대해 기간이 지난 데이터베이스의 백업들을 삭제하지 못한다. 만약 이 문제가 발생하면 반드시 실행 계획에 속해있는 모든 데이터베이스를 최대나 대량로그 복구모델을 사용하거나 제 2의 단순 복구 모델을 사용하는 유지관리 계획을 세워야 한다. 트랜잭션 로그 백업은 계획의 구성에 있어서 제외시킬 필요가 있다.

 

 

Monitoring and Notifications

그림 6. 리포팅 옵션 정의

 

[그림 6]에서 보는 바와 같이 보고서 탭은 몇몇의 유지관리 계획에 대한 보고옵션을 정의하도록 한다. 보고 문서는 텍스트 파일로 출력이 가능하고 만료 시 SQL서버가 자동으로 삭제한다. sqlmaint 유틸리티는 HTML파일로도 출력할 수도 있으나 이 보고서 탭에서는 그 내용을 선택할 수 없다. 대신 스케줄 작업에서 xp_sqlmaint를 호출할 때 HtmlRpt 과 DelHtmlRpt 스위치를 사용하여 수정할 필요가 있다. 또한 로컬이나 원격 서버 위에 sysdbmaintplan_history 테이블에 로그에 대한 기록을 남기도록 선택할 수 있다.

 

그림 7. 데이터베이스 유지 관리 계획 기록, 대화상자

 

유지관리계획실행에 대한 기록을 검토하는 가장 쉬운 방법은 [그림 7]에서와 보여지는 것과 같이 데이터베이스의 유지관리 계획 기록 대화상자를 확인하는 것이다. 이 대화상자는 엔터프라이즈 관리자의 데이터베이스 유지관리 계획의 노드에서 오른쪽 클릭해서 유지관리 계획 기록을 선택한다. 이 대화상자는 다양한 검색 필터를 제공하므로, sysdbmaintplan_history table 의 수많은 열들을 드릴 다운하는 것은 쉽다. 또한 고객들이 보기 위한 리포트를 작성할 수 있다. 만약 여러 개의 서버를 관리한다면 하나의 서버에 있는 sysdbmaintplan_history테이블에 기록되도록 구현 할 수 있다. 또 다른 옵션은 여러 개의 링크된 서버의 sysdbmaintplan_history 테이블을 읽기 위해 UNION 절을 사용하는 뷰를 만드는 것이다. 기록 테이블과 sqlmaint 텍스트 보고서는 작업스케줄 기록보다 실패 사유에 대하여 좀 더 자세한 내용을 제공한다. 엔터프라이즈 관리자에서 유지관리 작업에 대한 실패를 발견했을 때 나는 유지 보수 관리 기록을 확인하는 것이 더욱 좋다고 생각하는데 그 이유는 작업스케줄 기록은 대부분 sqlmaint.exe failed" 이라는 오류보고 만을 가지고 있기 때문이다.

이런 중요한 환경에서는 무엇이 어떻게 잘못되었는지를 기록 테이블이나 계획 오류 보고만을 주기적으로 살펴보는 그 누군가에게 의존을 할 수는 없을 것이다. 만약 백업이 실패했다면 그에 대한 해결책을 만들기 위해 즉시 통보 받기를 원할 것이다. 마법사나 유지 관리 계획 화면에서 유지 관리 계획의 실패의 통보를 설정 할 순 없다. 이런 보고를 정의하기 위해선 스케줄 작업을 수정할 필요가 있다. SQL는 유지 관리 계획이 변경되었을 때 작업스케줄과 작업명령을 수정 하지만 작업 보고 부분은 그대로 유지된다. 작업 스케줄은 이메일, 호출기, Net Send 의 운영자 옵션을 지원한다. 만약 유지관리 유지관리계획을 삭제하거나 나중에 다시 생성이 되면, 이러한 통보 부분은 다시 작성을 할 필요가 있다.

SQL서버 유지관리 계획은 데이터베이스 유지관리 요구를 정의하고 제공하는 강력하고 유연한 메커니즘이다. 최적화된 유지관리 계획을 생성함으로 인해, 당신은 데이터베이스를 유지관리하고 모니터링 하는데 소비될 많은 시간을 줄일 수 있을 것이다.