Sun Java System Calendar Server 6 2005Q4 관리 설명서

데이터베이스 문제 처리

이 절은 Calendar Server 데이터베이스를 포함하여 다양한 문제에 대해 설명합니다.

Berkeley 데이터베이스 도구 찾기

많은 문제 해결 단계를 수행하려면 Berkeley 데이터베이스 유틸리티 프로그램에 액세스해야 합니다. 이러한 유틸리티 프로그램의 한 버전을 Calendar Server 번들에서 사용할 수 있지만 유틸리티 프로그램이 지원되지 않습니다. 자세한 내용은 Sleepycat Software(http://www.sleepycat.com)에서 직접 확인할 수 있습니다.

이 절은 다음 내용으로 구성되어 있습니다.

Berkeley 데이터베이스 유틸리티에 액세스하려면

LD_LIBRARY_PATH 환경 변수를 설정하고 내보내 다음 디렉토리를 반영합니다.

cal_svr_base/SUNWics5/cal/tools/unsupported/bin/

사용 가능한 도구 목록

다음 표에는 일반적으로 사용되는 Berkeley 데이터베이스 도구(유틸리티 프로그램)가 나열되어 있습니다.

데이터베이스 도구	설명
`db_archive`	더 이상 사용되지 않는 로그 파일의 경로 이름을 표준 출력에 한 줄당 하나씩 씁니다.
`db_checkpoint`	데이터베이스 로그를 모니터하고 검사점 루틴을 주기적으로 호출하여 검사하는 데몬 프로세스입니다.
`db_deadlock`	데이터베이스 환경 잠금 영역을 선회하고 교착 상태가 감지될 때마다 잠금 요청을 중지하거나 시간 초과된 잠금 요청을 중지합니다.
`db_dump`	`db_load` 유틸리티에서 인식되는 일반 텍스트 형식의 표준 출력에 지정된 파일을 씁니다.
`db_load`	표준 입력을 읽어 지정된 데이터베이스 파일로 로드합니다. 파일이 없는 경우 파일을 만듭니다.
`db_printlog`	로그 파일을 사람이 읽을 수 있는 형식으로 덤프하는 디버깅 유틸리티입니다.
`db_recover`	예상치 못한 응용 프로그램, 데이터베이스 또는 시스템 오류가 발생한 후 데이터베이스를 일관된 상태로 복원합니다.
`db_stat`	데이터베이스 환경에 대한 통계를 표시합니다.
`db_verify`	하나 이상의 파일과 해당 파일에 포함된 데이터베이스의 구조를 확인합니다.

데이터베이스 교착 상태 검색 및 수정

Berkeley 데이터베이스가 교착 상태인 경우 데이터베이스를 재설정해야 합니다. 이러한 조건은 가능한 빨리 검색해야 합니다

시스템에서 데이터베이스를 주기적으로 확인하여 교착 상태를 검색하고 관리자에게 알리게 하려면

단계

구성을 변경할 권한을 가지고 관리자로 로그인합니다.

/etc/opt/SUNWics5/cal/config 디렉토리로 변경합니다.

이전 ics.conf 파일을 복사하고 이름을 바꿔 저장합니다.

필요한 경우 ics.conf를 다음 값으로 편집합니다.

local.caldb.deadlock.autodetect=”yes”

주 –
이 매개 변수가 “yes”로 설정되어 있는 경우 잠금 영역을 모니터하는 db_deadlock 데몬이 시작됩니다.

데이터베이스 손상 검색

달력 데이터베이스 손상은시스템 자원 경쟁, 하드웨어 오류, 응용 프로그램 오류, 데이터베이스 오류 및 사람에 의한 실수 등 여러 가지 원인에 의해 발생할 수 있습니다. 이 절에서는 Calendar Database 손상을 검색하는 방법에 대해 설명합니다.

데이터베이스 손상 기본

누구도 손상 없는 데이터베이스를보장할수없습니다데이터 손실과 작업 중단 시간을 최소화할 수 있습니다. 데이터베이스와 Calendar Server를 자세히 모니터하여 손상을 조 기에 검색해야 합니다. 손상이 발견될 경우 복구할 수 있도록 전체 백업을 자주 수행해야 합니다.

달력 데이터베이스에는 다음과 같은 두 가지 수준의 손상이 발생할 수 있습니다.

응용 프로그램 수준–많은 데이터베이스 파일 중 하나에 있는 위반 항목이 서버가 실행되지 않게 합니다.
데이터베이스 수준–Berkeley 데이터베이스 페이지의 손상이 다양한 문제를 발생시킵니다. csdb check 실행 중의 루핑 현상이 공통 증상입니다. 또 다른 공통 증상으로 다음과 같은 오류 메시지가 발생합니다.
```
“illegal page type or format”, 
or “page 97895 doesn’t exist, create flag not set.”
```

로그 파일 모니터링

경보 로그를 포함하여 Calendar Server 로그 파일을 모니터하여 데이터베이스 손상을 나타내는 오류 메시지가 있는지 확인합니다. 로그 파일에 대한 자세한 내용은 Calendar Server 로그 파일 사용을 참조하십시오.

정기적으로 로그 파일에서 경보, 심각, 오류 및 경고 수준의 오류가 있는지 검사하고 그런 오류가 발견되면 해당 이벤트를 조사하여 Calendar Server 작업과 관련된 원인을 찾아야 합니다. 알림 및 정보 수준의 로그 이벤트는 정상적인 Calendar Server 작업 중에 발생하며 서버 작동을 모니터할 수 있도록 제공됩니다.

데이터베이스 디렉토리에서 어떤 트랜잭션 로그 파일도 제거하지 마십시오. 트랜잭션 로그 파일은 트랜잭션 업데이트(추가, 수정, 삭제)를 포함하고 있으므로 이 파일을 제거하면 복구 불가능한 달력 데이터베이스 손상을 발생시킬 수 있습니다.

주 –

Calendar Server 기술 지원 요청 시 문제 해결에 도움이 될 로그 파일을 제공해야 하는 경우가 있습니다.

csmonitor 사용

csmonitor 유틸리티를 사용하여 Calendar Server를 모니터합니다. 이 유틸리티는 여러 트랜잭션 로그 파일이 있거나 달력 데이터베이스의 디스크 공간 부족 등과 같은 문제가 검색될 경우 관리자에게 경고 전자 메일을 보냅니다. 자세한 내용은 csmonitor를 참조하십시오.

달력 데이터베이스 손상 검사 방법

check 명령을 사용하여 달력 등록 정보(calprops) 및 이벤트와 작업(태스크)을 포함한 달력 데이터베이스에서 손상을 검색합니다. check 명령이 해결할 수 없는 비일관성 오류가 발견된 경우에는 출력으로 상황을 보고합니다.

check 명령은 경보나 그룹 예약 엔진(GSE) 데이터베이스의 손상을 확인하지 않습니다.

단계

Calendar Server가 설치된 시스템에 대한 관리 권한이 있는 사용자로 로그인합니다.

Calendar Server는 실행 중이어도 되고 중지해도 되지만 가능하면 Calendar Server를 중지하는 것이 좋습니다.

아직 달력 데이터베이스의 복사본을 만들지 않은 경우 지금 만듭니다.

데이터베이스(.db) 파일만 복사합니다. 공유(__db.*) 또는 로그(log.*) 파일은 복사할 필요가 없습니다.

cal_svr_base/SUNWics5/cal/sbin 디렉토리로 변경합니다.

예를 들어, Solaris 운영 체제에서 기본 디렉토리에 다음과 같이 입력합니다.
cd /opt/SUNWics5/cal/sbin

달력 데이터베이스의 복사본에 대해 check 명령을 실행합니다.
./csdb check dbdir /tmp/check.out
dbdir을 지정하지 않은 경우 check는 현재 디렉토리의 데이터베이스를 사용합니다.

check 명령은 많은 정보를 생성할 수 있으므로 이번 예와 같이 stdout 및 stderr을 포함한 모든 출력을 파일로 재지정하는 것도 바람직합니다.

check를 마치면 출력 파일을 검토합니다. 데이터베이스가 손상된 경우 rebuild 명령을 실행합니다.

손상된 달력 데이터베이스 재구축을 참조하십시오.

데이터베이스가 손상된 경우 서비스 중단 방지(읽기 전용 모드)

이 절에서는 복구 모드에서 손상된 데이터베이스를 액세스 가능한 상태로 유지하는 방법에 대해 설명하며, 다음 내용으로 구성되어 있습니다.

읽기 전용 모드 사용

데이터베이스 손상이 발생할 경우 서비스 중단을 방지하는 한 가지 방법은 데이터베이스를 읽기 전용 모드로 전환하는 것입니다. 읽기 전용 모드에서는 최종 사용자가 데이터베이스 항목을 읽을 수 있지만 항목을 추가, 수정 또는 삭제할 수 없습니다. 최종 사용자가 달력 데이터를 추가, 수정 또는 삭제하려고 하면 오류 메시지가 표시됩니다. 또한, 데이터베이스가 읽기 전용 모드인 동안에는 달력 이벤트와 할 일을 추가, 수정 또는 삭제하는 관리자 도구가 작동되지 않습니다.

주 –

읽을 수 없는 지점에서 데이터베이스가 손상된 경우 백업을 복원할 수 있을 만큼 충분한 시간 동안 서비스를 중단해야 합니다. 백업을 복원하는 가장 빠른 방법은 손상 없는 핫 백업을 사용하는 것입니다. 복원하기 전에를 참조하십시오.

데이터베이스를 읽기 전용 모드로 전환하려면

단계

필요하지 않은 경우 달력 서비스를 일시적으로 중지하여 데이터베이스의 추가 손상을 방지할 수 있습니다.

달력 서비스를 중지하려면

cal_svr_base/SUNWics5/cal/sbin/stop-cal

명령줄에서 ics.conf가 있는 디렉토리로 변경합니다.

cd /etc/opt/SUNWics5/config

달력 데이터베이스에 대한 읽기 전용 모드를 지정합니다.

caldb.berkeleydb.readonly=”yes”

ics.conf 파일 편집이 완료되면 Calendar Server를 다시 시작합니다.

cal_svr_base /SUNWics5/cal/sbin/start-cal

ics.conf 변경 내용을 적용하려면 서비스를 다시 시작해야 합니다.

일반 데이터베이스 오류 처리

이 절에서는 일반적인 몇 가지 데이터베이스 오류에 대해 설명하고 치료 방법을 제안합니다. 이 절은 다음 내용으로 구성되어 있습니다.

csadmind가 시작되지 않거나 시작 중에 충돌함

csadmind는 그룹 예약 엔진(GSE)과 경보 디스패치 엔진을 모두 처리하는 서비스이기 때문에 GSE 대기열이나 경보 대기열의 위반 항목으로 인해 이러한 문제가 발생할 수 있습니다.

치료 방법

단계

csadmind가 실행 중이 아닌 경우 stop-cal을 즉시 실행합니다.

달력 서버를 실행된 상태로 두면 트랜잭션 로그가 누적되므로 데이터베이스에 추가 손상이 발생하여 트랜잭션 로그 파일을 데이터베이스에 맞게 조정하는 데 더 많은 시간이 걸릴 수 있습니다.

csadmind을 다시 시작해 보십시오(start-cal 다시 실행).

성공적으로 시작되면 다음을 수행하여 두 대기열이 작동하는지 확인합니다.
1. csschedule을 사용하여 GSE 대기열 검사
2. dbrig를 사용하여 경보 대기열 검사
  
  csschedule 및 dbrig 실행에 대한 자세한 내용은 부록 D, Calendar Server 명령줄 유틸리티 참조 를 참조하십시오.

csadmind가 덤프와 충돌하는 경우 pstack을 분석합니다.

추적 중에 GSE 관련 함수(GSE 문자가 포함되어 있음)가 발견되면 GSE 대기열의 첫번째 항목과 이벤트 데이터베이스의 참조 항목을 조사합니다. 대부분의 경우 GSE 항목에서 참조되는 이벤트가 위반 항목입니다. 이 문제를 해결하려면 다음을 수행합니다.
1. csschedule을 사용하여 GSE 항목을 제거합니다.
2. cscomponents를 사용하여 데이터베이스에서 위반 이벤트를 제거합니다.
  
  csschedule 및 cscomponents 실행에 대한 자세한 내용은 부록 D, Calendar Server 명령줄 유틸리티 참조 를 참조하십시오.

항목이 손상되지 않은 경우 Calendar Server를 처리할 수 없는 특수한 경우일 수 있습니다.

다음 단계를 수행합니다.
1. 손상된 데이터베이스의 달력 환경 스냅샷을 만든 다음 고객 지원부에 문의하십시오.
  
  환경 백업을 만들려면
  1. 다음 위치에 있는 db_checkpoint 유틸리티를 사용합니다.
    
    cal_svr_base/SUNWics5/cal/tools/unsupported/bin/db_checkpoint
  2. db_archive -s를 실행합니다.
    
    -s 옵션을 실행하여 모든 데이터베이스 파일을 식별한 다음 CD, DVD, 테이프 등과 같은 이동식 매체에 복사합니다.
  3. db_archive -l를 실행합니다.
    
    -l 옵션을 사용하여 모든 로그 파일을 식별하고 적용되지 않은 로그 파일을 이동식 매체에 복사합니다.
2. 서비스 중단을 방지하려면 달력 데이터베이스를 일시적으로 읽기 전용 상태로 전환하고 핫 백업 복사본으로 되돌립니다.
  - 달력 데이터베이스를 읽기 전용 상태로 전환하면 일시적으로 추가, 수정 또는 삭제 트랜잭션을 수행할 수 없게 됩니다. 최종 사용자가 달력 데이터를 추가, 수정 또는 삭제하려고 하면 오류 메시지가 표시됩니다. 또한, 데이터베이스가 읽기 전용 모드인 동안에는 달력 이벤트와 할 일을 추가, 수정 또는 삭제하는 관리자 도구가 작동되지 않습니다.
    
    달력 데이터베이스를 읽기 전용 모드로 전환하려면 ics.conf 파일을 편집하고 다음과 같이 매개 변수를 “yes”로 설정합니다.
    
    caldb.berkeleydb.readonly=”yes”
  - 자동 백업 복사본 복원에 나오는 지침에 따라 핫 백업 복사본으로 되돌립니다.
    
    csstored를 구성하여 활성화하면 몇 분 이내에 최신 상태의 핫 백업을 사용할 수 있습니다. 항상 핫 백업 복사본을 확인하여 복사본이 손상되지 않았는지 확인해야 합니다. (db_verify 실행)

기타 오류의 경우 덤프를 수행하고 절차를 다시 로드하여 데이터베이스를 복구할 수 있는지 확인합니다.

이 절차는 덤프 및 로드 절차를 사용하여 달력 데이터베이스 복구 에 설명되어 있습니다.

서비스가 중단되어 최종 사용자가 연결할 수 없음–끊어진 잠금

이 문제는 Berkeley DB 데이터베이스 페이지 잠금을 보관하는 제어 스레드가 잠금을 해제하지 않고 종료되어 발생할 수 있습니다. 문제를 확인하려면 cshttpd 프로세스의 pstack 및 csadmind를 실행합니다. (pstack은/usr/bin/pstack에 있는 표준 UNIX 유틸리티임) 잠금을 위해 대기 중인 스레드가 표시됩니다.

문제를 해결하려면 다음과 같은 방법으로 Calendar Server를 다시 시작합니다.

단계

start-cal이 있는 디렉토리로 변경합니다.

cd cal_svr_base/SUNWics5/cal/sbin

start-cal 명령을 실행합니다.

./start-cal

csdb 재구축 완료 안 됨–데이터베이스 루핑

데이터베이스 루핑은 일반적으로 데이터베이스 파일이 손상되어 발생합니다. 데이터베이스가 손상되었기 때문에 복구할 수 없습니다. 다음과 같은 여러 가지 옵션이 있습니다.

단계

핫 백업으로 되돌립니다.

손상이 최근에 발생한 경우 핫 백업 중 하나를 사용할 수 있습니다.

재해 아카이브 복구 프로세스를 사용합니다.

제안되는 프로세스를 보려면 자동 백업 복사본 복원을 참조하십시오.

덤프를 사용하고 절차를 다시 로드합니다. 자세한 내용은 덤프 및 로드 절차를 사용하여 달력 데이터베이스 복구 를 참조하십시오.

손상된 달력 데이터베이스 재구축

이 절에서는 csdb rebuild 명령 사용 방법을 설명하고 다음 내용으로 구성되어 있습니다.

재구축 개요

rebuild 명령은 달력 데이터베이스를 검사하고 달력 등록 정보(calprops) 이벤트 및 수행할 작업(태스크)이 손상되었는지 확인합니다. rebuild 명령이 비일관성을 발견한 경우 cal_svr_base /SUNWics5/cal/sbin/rebuild_db 디렉토리에 달력 데이터베이스(.db 파일)를 재구축합니다.

-g 옵션 없는 rebuild 명령은 그룹 예약 엔진(GSE) 데이터베이스를 제외하고 모든 데이터베이스를 재구축합니다. GSE 데이터베이스도 재구축하려면 -g 옵션을 포함시킵니다.

rebuild 명령을 사용하기 전에 GSE 데이터베이스에 항목이 있는지 확인하려면 csschedule -v list 명령을 실행한 다음 GSE가 항목 처리를 마치게 합니다.

달력 데이터베이스를 재구축하려면

단계

Calendar Server가 설치된 시스템에 대한 관리 권한이 있는 사용자로 로그인합니다.

Calendar Server를 중지합니다.

달력 데이터베이스의 복사본을 만들어 /tmp/db 디렉토리에 넣습니다.

데이터베이스(.db) 파일과 로그(log.*) 파일을 복사합니다. 공유( __db.*) 파일은 복사할 필요가 없습니다.

cal_svr_base/SUNWics5/cal/sbin 디렉토리로 변경합니다.

예를 들어, Solaris 운영 체제에서 기본 디렉토리에 다음과 같이 입력합니다.
cd /opt/SUNWics5/cal/sbin
주 –
sbin 디렉토리의 디스크 공간이 문제라면 다른 디렉토리에서 rebuild 명령을 실행합니다.

달력 데이터베이스 복사본에 대해 rebuild 명령을 실행합니다.
./csdb rebuild /tmp/db /tmp/
데이터베이스 경로를 지정하지 않은 경우 rebuild는 현재 디렉토리를 사용합니다. /tmp/ 매개 변수는 다시 작성된 데이터베이스의 대상 디렉토리를 지정합니다.

GSE 데이터베이스도 재구축하려면 -g 옵션을 포함시킵니다.

rebuild 명령은 많은 정보를 생성할 수 있으므로 stdout 및 stderr을 포함한 모든 출력을 파일로 재지정하는 것도 바람직합니다.

주 –
항상 최신 백업 복사본을 사용하여 달력 데이터베이스를 재구축합니다.

그러나 심각한 데이터 손실이 발생했고 그 동안 정기적으로 데이터베이스를 백업했으며 2개 이상의 복사본이 존재하는 경우, 최신 복사본에서 가장 오래된 복사본으로 재구축합니다. 한 가지 단점은, 삭제했던 달력 구성 요소가 다시 만들어진 데이터베이스에 나타난다는 것입니다.

예를 들어, db_0601, db_0615 및 db_0629 디렉토리에 백업 달력 데이터베이스 파일 3세트가 있는 경우, 다음 순서대로 rebuild 명령을 실행합니다.
./csdb rebuild db_0629 ./csdb rebuild db_0615 ./csdb rebuild db_0601
그러면 rebuild 명령은 재구축된 데이터베이스를 cal_svr_base/SUNWics5/cal/sbin/rebuild_db 디렉토리에 저장합니다.

rebuild를 마치면 rebuild.out 파일에서 출력을 검토합니다.

해당 재구축이 성공했을 경우 rebuild.out 파일의 마지막 행은 다음과 같습니다.
Calendar database has been rebuilt

이전 단계에서 rebuild가 성공했음을 확인한 다음 재구축된 데이터베이스(.db) 파일을 rebuild_db 디렉토리에서 작업 데이터베이스로 복사합니다.

손상된 데이터베이스에 공유(__db.*) 또는 로그(log.*) 파일이 있는 경우 이들을 다른 디렉토리로 옮깁니다.

Calendar Server를 다시 시작합니다.

샘플 재구축 출력

다음 예에서는 이 명령과 그 결과 생성된 출력을 보여 줍니다.

# ./csdb -g rebuild
Building calprops based on component information.
Please be patient, this may take a while...
Scanning events database...
512 events scanned
Scanning todos database...
34 todos scanned
Scanning events database...
512 events scanned
Scanning todos database...
34 todos scanned
Scanning deletelog database...
15 deletelog entries scanned
Scanning gse database...
21 gse entries scanned
Scanning recurring database...
12 recurring entries scanned
Successful components db scan
Calendar database has been rebuilt
Building components based on calprops information.
Please be patient, this may take a while...
Scanning calprops database to uncover events...
25 calendars scanned
Scanning calprops database to uncover todos...
25 calendars scanned
Successful calprops db scan
Calendar database has been rebuilt

주 –

이전 샘플 출력에서는 이벤트와 할 일 데이터베이스가 각각 두 번씩 검색되었습니다. 이는 오류가 아닙니다. 먼저 달력 등록 정보 데이터베이스에서 정보를 확인한 다음 달력 등록 정보 데이터베이스에 액세스할 수 있는지 다시 확인합니다.

덤프 및 로드 절차를 사용하여 달력 데이터베이스 복구

이절은 다음 내용으로 구성되어 있습니다.

덤프 및 로드 개요

덤프 및 로드 절차를 사용하여 손상된 데이터베이스를 복구합니다. 덤프 및 로드 절차는 Berkeley 데이터베이스 db_dump 및 db_load 유틸리티를 사용하며, Calendar Server는 이러한 유틸리티를 다음 디렉토리에 보관합니다.

cal_svr_base/SUNWics5/cal/tools/unsupported/bin

db_dump 유틸리티는 데이터베이스 파일을 읽고 그 데이터베이스 항목을 db_load 유틸리티와 호환되는 형식을 사용하여 출력 파일에 기록합니다.

db_dump 및 db_load 유틸리티에 대한 설명서는 다음 Sleepycat Software 웹 사이트를 참조하십시오.

http://www.sleepycat.com/docs/utility/index.html

db_dump 및 db_load 유틸리티를 사용한 데이터베이스 복구의 성공 여부는 데이터베이스 손상 정도에 따라 결정됩니다. 데이터베이스를 성공적으로 복구하려면 db_dump 옵션을 여러 차례 시도해야 하는 경우도 있습니다. 그러나 데이터베이스가 심각하게 손상될 경우 복구가 불가능하고 따라서 데이터베이스의 손상 없는 최신 버전 핫 백업 또는 아카이브 백업으로 되돌려야할 수도 있습니다.

주 –

덤프 및 로드 절차를 수행하려면 달력 데이터베이스가 Berkeley DB 버전 3.2.9 이상이어야 합니다. 이전 버전인 경우에는 먼저 cs5migrate 유틸리티를 실행하여 달력 데이터베이스를 업그레이드합니다.

최신 버전의 cs5migrate를 구하려면 Sun 기술 지원에 문의하십시오.

덤프 및 로드 절차를 수행하려면

단계

Calendar Server가 실행되는 사용자 및 그룹(예: icsuser 및 icsgroup) 또는 수퍼유저( root)로 로그인합니다.

필요할 경우 Calendar Server를 중지합니다.

csbackup, Sun StorEdge Enterprise Backup^TM 소프트웨어 또는 Legato Networker® 같은 유틸리티를 사용하여 달력 데이터베이스를 백업합니다.

자세한 내용은 17 장, Calendar Server 데이터 백업 및 복원 을 참조하십시오.

db_dump 유틸리티를 사용하여 손상된 각 데이터베이스 파일을 덤프합니다.

데이터베이스 파일은 ics50calprops.db, ics50journals.db, ics50alarms.db, ics50events.db , ics50todos.db 및 ics50gse.db입니다.

데이터베이스가 복구될 때까지 또는 데이터베이스를 복구할 수 없음을 확인할 때까지 다음 옵션을 순서대로 사용하여 db_dump를 실행합니다.
- 옵션 없음 ? 심각하지 않은 데이터베이스 손상
- -r 옵션 보통 수준의 데이터베이스 손상
- -R 옵션 심각한 데이터베이스 손상-R 옵션은 부분 및 삭제된 레코드를 비롯하여 -r 옵션보다 더 많은 데이터를 손상된 데이터베이스로부터 덤프합니다.
  
  예를 들어, db_dump를 -r 옵션과 함께 실행하려면 다음 명령을 사용합니다.
  db_dump -r ics50events.db \> ics50events.db.txt

db_load 유틸리티를 사용하여 출력 파일을 새 데이터베이스 파일로 로드합니다.

예를 들면 다음과 같습니다.
db_load new.ics50events.db < ics50events.db.txt
db_load가 홀수 개수의 키나 데이터 항목을 보고할 경우 db_dump 출력 파일을 편집하여 홀수 키나 데이터 항목을 제거합니다. 그런 다음 db_load를 다시 실행합니다.

손상된 다른 데이터베이스 파일에 대해 앞의 두 단계를 반복합니다.

즉, 손상된 다른 데이터베이스 파일에 대해 db_dump를 실행합니다.

손상된 달력 데이터베이스 재구축에 설명된 대로 csdb rebuild 명령을 사용하여 복구된 데이터베이스 파일을 재구축합니다.

rebuild를 마치면 출력 파일에서 출력을 검토합니다. 해당 재구축이 성공했을 경우 rebuild.out 파일의 마지막 행은 다음과 같습니다.
Calendar database has been rebuilt
csdb rebuild 명령이 성공하지 못한 경우 다음 db_dump 옵션(-r 또는 -R)을 사용하여 데이터베이스를 덤프합니다.

db_dump -R 옵션이 손상된 데이터베이스를 복구하지 못한 경우 Sun Microsystems 기술 지원 또는 영업 담당자에게 연락하여 도움을 받으십시오. 그 사이에 손상 없는 최신 데이터베이스 백업으로 되돌려야 할 수도 있습니다.

자동 백업 복사본 복원

10 장, 자동 백업 구성(csstored)에 설명된 자동 백업 기능을 사용한 경우 라이브 데이터베이스가 손상되었다면 핫 백업 복사본을 복원할 수 있습니다.

이 절에서는 서로 다른 두 자동 백업 복원 방법에 대해 설명합니다.

복원하기 전에

백업을 복원하기 전에 다음을 확인해야 합니다.

활성 데이터베이스를 손상시킨 트랜잭션을 진단했는지 여부
새 아카이브가 손상되지 않도록 손상 트랜잭션을 제거했거나 수정했는지 여부
손상된 데이터베이스를 다른 디렉토리나 이동식 매체에 복사하여 보관했는지 여부반드시 기술 지원부에 문의해야 합니다.

핫 백업 복원

라이브 데이터베이스가 손상된 경우 핫 백업을 가장 먼저 선택해야 합니다. 핫 백업을 복원하려면 다음 단계를 수행합니다.

단계

적용되지 않았거나 손상된 활성 데이터베이스 디렉토리에 쓰기 위해 열려 있는 로그 파일을 식별합니다.

쓰기 위해 열려 있는 로그를 닫습니다. 이 로그에는 최신 트랜잭션이 포함되어 있습니다.

새 (복구) 디렉토리를 만듭니다.

현재 핫 백업 복사본을 새 복구 데이터베이스 디렉토리에 복사합니다.

손상된 라이브 데이터베이스 디렉토리의 log.* 파일을 새 복구 데이터베이스 디렉토리에 복사합니다.

데이터베이스의 아카이브 복사본을 저장하는 경우 경우 활성 데이터베이스에 적용되지 않은 로그를 아카이브 디렉토리에 복사하여 아카이브 백업 복사를 완료합니다.

새 복구 데이터베이스에 대해 지정된 -c -h 옵션과 함께 db_recover를 실행합니다.

예를 들어, 새 복구 디렉토리가 recoverydb인 경우 명령은 다음과 같습니다.

db_recover -c -h recoverydb

log.* 파일을 새 복구 디렉토리에 그대로 둡니다.

db_recover 프로그램이 로그 파일을 새 복구 데이터베이스에 적용했지만 버전 42부터 Berkeley DB는 로그 파일이 그대로 유지되는 것으로 기대합니다.

새 복구 디렉토리에 있는 데이터베이스 파일에 대해 db_verify를 실행합니다.

자세한 내용은 달력 데이터베이스 손상 검사 방법을 참조하십시오.

새 복구 디렉토리에 대해 csdb -v list를 실행합니다.

새 복구 디렉토리가 앞의 세 복구 단계를 모두 통과한 경우 손상된 이전 활성 데이터베이스를 새 복구 데이터베이스로 대체합니다.

새 스냅샷 역할을 하도록 새 라이브 데이터베이스를 핫 백업 디렉토리에 복사합니다.

다음에 정기 스냅샷을 찍을 때까지 모든 새 로그가 이 복사본에 적용됩니다.

Calendar Server를 시작합니다.

새 복구 디렉토리에서 단계가 실패할 경우 다음과 같은 방법으로 손상되지 않은 이전 핫 백업을 식별합니다.
1. 핫 백업에 대한 역방향 작업을 통해 db_verify 및 csdb -v list를 하나씩 차례로 실행하여 손상되지 않은 최신 복사본을 찾습니다.
2. 통과한 첫 번째 핫 백업 복사본을 라이브 데이터베이스 디렉토리에 복원할 수 있습니다.
  
  핫 백업 복원의 설명대로 손상된 라이브 데이터베이스를 손상 없는 핫 백업으로 대체합니다. (먼저 복원하기 전에를 읽으십시오.)
3. 핫 백업과 아카이브 백업이 없는 경우 기술 지원부에 문의하십시오. 아카이브 백업이 있는 경우 아카이브 백업을 복원하려면 다음에 나오는 절차를 따르십시오. (또한 복원하기 전에를 참조하십시오.)

아카이브 백업을 복원하려면

손상되지 않은 핫 백업이 없지만 아카이브 백업과 해당 트랜잭션 로그가 있는 경우 다음 단계를 수행하여 손상되지 않은 최신 아카이브 데이터베이스 버전을 복원할 수 있습니다.

단계

적용되지 않았거나 손상된 활성 데이터베이스 디렉토리에 쓰기 위해 열려 있는 로그 파일을 식별합니다.

쓰기 위해 열려 있는 로그를 닫습니다. 이 로그에는 최신 트랜잭션이 포함되어 있습니다.

새 (복구) 디렉토리를 만듭니다.

최신 아카이브 복사본과 해당 로그 파일을 새 복구 데이터베이스 디렉토리에 복사합니다.

손상된 라이브 데이터베이스 디렉토리의 적용되지 않은 log.* 파일을 새 복구 데이터베이스 디렉토리에 복사합니다.

새 복구 데이터베이스에 대해 지정된 -c -h 옵션과 함께 db_recover를 실행합니다.

예를 들어, 새 복구 디렉토리가 recoverydb인 경우 명령은 다음과 같습니다.

db_recover -c -h recoverydb

log.* 파일을 새 복구 디렉토리에 그대로 둡니다.

db_recover 프로그램이 로그 파일을 새 복구 데이터베이스에 적용했지만 버전 4.2부터 Berkeley DB는 로그 파일이 해당 위치에 그대로 있는 것으로 기대합니다.

새 복구 디렉토리에 있는 데이터베이스 파일에 대해 db_verify를 실행합니다.

자세한 내용은 달력 데이터베이스 손상 검사 방법을 참조하십시오.

새 복구 디렉토리에 대해 csdb -v list를 실행합니다.

새 복구 디렉토리가 앞의 세 복구 단계를 모두 통과한 경우 손상된 이전 활성 데이터베이스를 새 복구 데이터베이스로 대체합니다.

새 스냅샷 역할을 하도록 새 라이브 데이터베이스를 핫 백업 디렉토리에 복사합니다.

Calendar Server를 시작합니다.

새 복구 디렉토리에서 단계가 실패할 경우 다음과 같은 방법으로 손상되지 않은 이전 아카이브 백업을 식별합니다.
1. 아카이브 백업 복사본 역방향 작업을 통해 각각에 대해 세 복구 프로그램을 차례로 실행하여 손상되지 않은 최신 복사본을 찾습니다. db_recover -c-h, db_verify 및 csdb -v list.
2. 통과한 첫 번째 아카이브 복사본을 라이브 데이터베이스 디렉토리에 복원할 수 있습니다.
  
  아카이브 백업을 복원하려면에 표시된 것처럼 손상된 라이브 데이터베이스를 손상 없는 아카이브 백업으로 대체합니다.
3. 아카이브 백업이 수행되지 않으면 기술 지원부에 문의하십시오.

사용자 정의 백업 스크립트 복구

이 절은 다음 내용으로 구성되어 있습니다.

Berkeley 도구가 동적 라이브러리에 컴파일됨

db_recover와 같은 Berkeley 데이터베이스 도구를 사용하여 사용자 정의 백업 스크립트를 만든 경우 Calendar Server로 업그레이드하면 해당 스크립트가 더 이상 작동하지 않습니다. 이전 Calendar Server 버전에서는 정적 라이브러리를 사용하여 도구를 컴파일했기 때문입니다. 현재 버전에서는 도구를 동적 라이브러리 libdb-4.2.so에 컴파일합니다.

사용자 정의 백업 스크립트를 복구하려면

기존 사용자 정의 스크립트가 있는 새 동적 라이브러리를 사용하려면 다음 전역 변수를 설정합니다.

LD_LIBRARY_PATH=libdb-4.2.so