5장 Calendar Server 데이터베이스 관리

이 장에서는 다음 절을 포함하여 Sun ONE Calendar Server 데이터베이스 관리 방법을 설명합니다.

Calendar Server 데이터베이스 파일

기본적으로 Calendar Server 데이터베이스 파일(그리고 cld_cache 및 ldap_cache 디렉토리)은 다음 디렉토리에서 만들고 유지 관리합니다.

필요할 경우 Calendar Server 구성 프로그램(csconfigurator.sh)을 실행하여 다른 디렉토리를 지정할 수 있습니다. 구성 프로그램에 대한 자세한 내용은 Solaris 운영 체제용 Sun ONE Calendar Server 6.0 설치 설명서를 참조하십시오.

표 5-1 Calendar Server 데이터베이스 파일
파일	설명
ics50calprops.db	모든 달력용 달력 등록 정보. 달력 아이디(calid), 달력 이름, 액세스 제어 목록(ACL) 및 소유자를 포함합니다.
ics50events.db	모든 달력용 이벤트
ics50todos.db	모든 달력용 수행할 작업(태스크)
ics50alarms.db	모든 이벤트 및 수행할 작업(태스크)의 경보
ics50gse.db	그룹 예약 엔진(GSE)에 대한 예약 요청 대기열
ics50journals.db	달력 저널. 현재 릴리스에서는 저널이 구현되지 않습니다.
ics50caldb.conf	데이터베이스 버전 아이디
ics50recurring.db	반복 이벤트
ics50deletelog.db	삭제된 이벤트 및 수행할 작업(태스크). 7장, "로그 삭제 데이터베이스 관리"를 참조하십시오.

csdb 유틸리티를 사용한 데이터베이스 관리

이 절에서는 csdb 유틸리티를 사용하여 이 기능을 수행하는 방법을 설명합니다.

csdb 유틸리티를 실행하려면 Calendar Server가 실행되고 있는 시스템에 대해 관리 권한을 가진 사용자로 로그인해야 합니다. 자세한 내용은 11장, "Calendar Server 명령줄 유틸리티"를 참조하십시오.

대상 데이터베이스 지정

csdb 유틸리티 -t 옵션으로 대상 데이터베이스를 지정할 수 있습니다.

-t caldb - 달력 데이터베이스

-t sessdb - 세션 데이터베이스

-t statdb - 통계 데이터베이스

-t 옵션을 포함하지 않은 경우 csdb는 3가지 데이터베이스 모두에서 실행됩니다. 단, 달력 데이터베이스에서만 실행되는 check 및 rebuild 명령은 예외입니다.

달력 데이터베이스 상태 보기

달력 데이터베이스 상태를 보려면 csdb 유틸리티 list 명령을 사용합니다. Calendar Server는 실행 중이어도 되고 중지해도 됩니다.

-t 옵션을 사용하여 대상 데이터베이스(caldb, sessdb 또는 statdb)를 지정합니다. 그렇지 않으면 csdb는 3가지 데이터베이스 모두에서 실행됩니다.

예를 들어 모든 데이터베이스의 상태 및 통계를 보려면 다음 명령을 사용합니다.

현재 디렉토리의 달력 데이터베이스에 대한 정보를 세부 정보 표시 모드에서 보려면 다음 명령을 사용합니다.

달력 데이터 가져오기 및 내보내기

달력 데이터를 파일로 내보내거나 파일에서 가져오려면 csexport 및 csimport 유틸리티를 사용합니다. 달력 데이터는 iCalendar (.ics) 또는 XML (.xml) 형식이 가능합니다.

csexport 및 csimport는 Calendar Server가 설치된 시스템에서 로컬로 실행해야 합니다. Calendar Server는 실행 중이어도 되고 중지해도 됩니다.

달력 데이터 내보내기

달력 데이터를 파일로 가져가려면 csexport를 사용합니다. 출력 파일에 대해 지정한 파일 이름 확장자(.ics 또는 .xml)에 따라 사용되는 형식이 결정됩니다.

예를 들어, 달력 아이디(calid)가 JSmithcal인 달력을 iCalendar (text/calendar MIME) 형식으로 jsmith.ics라는 파일에 내보내려면 다음 명령을 사용합니다.

달력 JSmithcal을 XML (text/xml MIME) 형식으로 jsmith.xml이라는 파일로 내보내려면 다음 명령을 사용합니다.

달력 데이터 가져오기

csexport 유틸리티를 사용하여 저장했던 파일로부터 달력 데이터를 가져오려면 csimport를 사용합니다. 가져오기 파일의 파일 이름 확장명(.ics 또는 .xml)은 달력이 저장된 형식을 나타냅니다.

예를 들어, iCalendar (text/calendar MIME) 형식으로 저장했던 jsmith.ics 파일로부터 달력 아이디(calid) JSmithcal로 달력 데이터를 가져오려면 다음 명령을 사용합니다.

XML (text/xml MIME) 형식으로 저장했던 jsmith.xml 파일로부터 JSmithcal 달력으로 데이터를 가져오려면 다음 명령을 사용합니다.

지정된 달력 아이디(calid)가 이미 존재한 경우 기존 데이터를 지운 뒤 새 데이터를 가져옵니다.

손상된 데이터베이스 복구

손상된 세션이나 통계 데이터베이스를 복구하려면 csdb 유틸리티 recover 명령을 사용합니다. -t 옵션을 사용하여 대상 데이터베이스, sessdb(세션) 또는 statdb(통계)를 지정합니다.

recover 명령을 실행하기 전에 stop-cal 명령을 사용하여 Calendar Server를 중지합니다.

예를 들어, 현재 디렉토리에서 손상된 세션 데이터베이스를 복구하려면 다음 명령을 사용합니다.

달력 데이터베이스 삭제


주	손상된 달력 데이터베이스(caldb)를 복구하려면 recover 대신 csdb 유틸리티 check 및 rebuild 명령을 사용합니다. 자세한 내용은 "달력 데이터베이스 검사 및 다시 만들기"를 참조하십시오.

달력 데이터베이스를 삭제하려면 csdb 유틸리티 delete 명령을 사용합니다. Calendar Server를 중지해야 합니다.

대상 데이터베이스(caldb, sessdb 또는 statdb)를 지정하려면 -t 옵션을 사용해야 합니다. 그렇지 않으면 csdb는 3가지 데이터베이스를 모두 삭제합니다.

예를 들어, 달력 데이터베이스를 삭제하려면 다음 명령을 사용합니다.

csdb 유틸리티는 데이터베이스를 삭제하기 전에 경고 메시지를 표시합니다.

데이터베이스 손상 확인 및 복구

달력 데이터베이스 손상은 시스템 자원 경쟁, 하드웨어 오류, 응용 프로그램 오류, 데이터베이스 오류 그리고 물론 사람에 의한 실수 등 여러 가지 원인에 의해 발생할 수 있습니다. 이 절에서는 다음 내용을 비롯하여 달력 데이터베이스 손상을 확인하고 손상된 데이터베이스를 복구하는 방법을 설명합니다.

데이터 손실 최소화

달력 데이터베이스 검사 및 다시 만들기

덤프 및 로드 절차를 사용한 데이터베이스 복구

데이터 손실 최소화

복구 절차가 아무리 확실하다고 하더라도 데이터 손실을 최소화하려면 데이터베이스 손상을 조기에 발견하는 것이 바람직합니다. 데이터베이스 손상을 확인하려면 다음 제안을 따르십시오.

csbackup, Sun StorEdge Enterprise Backup™ 소프트웨어 또는 Legato Networker® 등과 같은 유틸리티를 사용하여 데이터베이스를 매일 백업합니다. 자세한 내용은 6장, "Calendar Server 데이터 백업 및 복원"을 참조하십시오.

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

csmonitor 유틸리티를 사용하여 Calendar Server를 모니터하고 2개 이상의 트랜잭션 로그 파일이나 달력 데이터베이스용 디스크 공간 부족과 같은 문제를 발견하면 전자 메일로 관리자에게 알립니다. 자세한 내용은 "csmonitor"를 참조하십시오.

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

달력 데이터베이스 검사 및 다시 만들기

csdb 유틸리티 명령은 달력 데이터베이스(caldb)를 검사하고, 필요할 경우 다시 만드는 데 사용하는 다음 명령을 포함합니다.

check 명령은 달력 데이터베이스를 검사하여 데이터베이스가 손상되었는지 확인하고 그 결과를 출력 형태로 보고합니다(check 명령은 경보나 그룹 예약 엔진(GSE) 데이터베이스의 손상을 확인하지 않음).

또한 rebuild 명령도 달력 데이터베이스를 검사하여 데이터베이스가 손상되었는지 확인하고, 필요할 경우 달력 데이터베이스를 다시 만듭니다(.db 파일).

데이터베이스 문제를 유발할 수 있는 이벤트가 발생했을 경우 check 명령(및 필요할 경우 rebuild 명령)을 실행합니다. 예를 들어, 사이트에 정전이 발생한 경우 check 명령을 실행하여 데이터베이스가 손상되었는지 여부를 확인합니다.

또한 csdb 유틸리티는 손상된 세션이나 통계 데이터베이스를 복구하는 recover 명령을 포함합니다. 달력 데이터베이스가 손상된 경우 recover대신 check 및 rebuild를 사용합니다.

달력 데이터베이스의 손상 확인


주의	이 명령을 실행하기 전에 csbackup 유틸리티(또는 또 다른 백업 유틸리티)를 사용하여 달력 데이터베이스를 백업합니다.

check 명령은 달력 데이터베이스를 검사하고 달력 등록 정보(calprops) 이벤트 및 수행할 작업(태스크)의 손상 여부를 확인합니다. 만일 check 명령이 해결할 수 없는 비일관성 오류를 발견하면 이러한 상황을 보고합니다.

check 명령을 정기적으로 실행하여 달력 데이터베이스의 비일관성 여부를 확인합니다. 예를 들어, 데이터베이스를 백업할 때마다 check를 실행할 수 있습니다. 그러나 달력 데이터베이스가 이미 손상되었음을 확인한 경우에는 check 명령을 사용할 필요가 없으며 즉시 손상된 데이터베이스를 다시 만들어야 합니다.

달력 데이터베이스의 손상을 확인하는 방법

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

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

아직 달력 데이터베이스의 복사본을 만들지 않은 경우 지금 만듭니다. 데이터베이스(.db) 파일만 복사합니다. 공유(__db_name.share) 또는 로그(log.*) 파일은 복사할 필요가 없습니다.

cal_svr_base/opt/SUNWics5/cal/sbin 디렉토리로 변경합니다. 예를 들어, Solaris 시스템에서 다음과 같이 입력합니다.

cd /opt/SUNWics5/cal/sbin

달력 데이터베이스의 복사본에 check 명령을 실행합니다.

./csdb check dbdir > /tmp/check.out 2>&1

dbdir을 지정하지 않은 경우 check는 현재 디렉토리의 데이터베이스를 사용합니다.

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

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

달력 데이터베이스 다시 만들기

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

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

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

달력 데이터베이스를 다시 만드는 방법

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

Calendar Server를 중지합니다.

cal_svr_base/opt/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개 이상의 복사본이 존재하는 경우, 최신 복사본에서 가장 오래된 복사본으로 rebuild를 수행합니다. 한 가지 단점은, 삭제했던 달력 구성 요소가 다시 만들어진 데이터베이스에 나타난다는 것입니다. 예를 들어, db_0601, db_0615 및 db_0629 디렉토리에 백업 달력 데이터베이스 파일 3세트가 있는 경우, 다음 순서대로 rebuild 명령을 실행합니다. ./csdb rebuild db_0629 ./csdb rebuild db_0615 ./csdb rebuild db_0601 그러면 rebuild 명령은 다시 만든 데이터베이스를 cal_svr_base/opt/SUNWics5/cal/sbin/rebuild_db 디렉토리에 저장합니다.

rebuild를 마치면 rebuild.out 파일에서 출력을 검토합니다. rebuild가 성공했을 경우 rebuild.out 파일의 마지막 행은 다음과 같습니다.

Calendar database has been rebuilt

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

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

Calendar Server를 다시 시작합니다.

덤프 및 로드 절차를 사용한 데이터베이스 복구

csdb rebuild 명령이 성공하지 못한 경우 다음 단계는 덤프와 로드 절차를 사용하여 손상된 데이터베이스 복구를 시도하는 것입니다. 덤프 및 로드 절차는 Berkeley 데이터베이스 db_dump 및 db_load 유틸리티를 사용하며, Calendar Server는 이러한 유틸리티를 다음 디렉토리에 보관합니다.

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

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

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

달력 데이터베이스 버전

덤프 및 로드 절차를 수행하기 전에 달력 데이터베이스가 Berkeley DB 버전 3.2.9인지 확인합니다. 이전 버전이라면 먼저 cs5migrate 유틸리티를 사용하여 달력 데이터베이스를 업그레이드합니다.

cs5migrate 실행에 대한 자세한 내용은 Solaris 운영 체제용 Sun ONE Calendar Server 6.0 설치 설명서를 참조하십시오.

덤프 및 로드 절차를 수행하는 방법

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

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

csbackup, Sun StorEdge Enterprise Backup™ 소프트웨어 또는 Legato Networker®와 같은 유틸리티를 사용하여 달력 데이터베이스를 백업합니다. 자세한 내용은 6장, "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가 홀수 개수의 키나 데이터 항목을 보고할 경우 단계 4에서 db_dump 출력 파일을 편집하여 홀수 키나 데이터 항목을 제거합니다. 그런 다음 db_load를 다시 실행합니다.

손상된 다른 데이터베이스 파일에 대해서도 단계 4 및 단계 5를 반복합니다.

달력 데이터베이스 다시 만들기의 설명대로 csdb rebuild 명령을 사용하여 복구된 데이터베이스 파일을 다시 만듭니다.

rebuild를 마치면 출력 파일에서 출력을 검토합니다. rebuild가 성공한 경우 rebuild.out 파일의 마지막 행은 다음과 같습니다.

Calendar database has been rebuilt

csdb rebuild 명령이 성공하지 못한 경우 단계 4로 돌아가 다음 db_dump 옵션(-r 또는 -R)을 사용하여 데이터베이스를 덤프합니다.

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