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

데이터베이스 손상 검색

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

데이터베이스 손상 기본

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

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

로그 파일 모니터링

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

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

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


주 –

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


csmonitor 사용

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

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

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

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

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

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

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

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

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

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


    cd /opt/SUNWics5/cal/sbin
  5. 달력 데이터베이스의 복사본에 대해 check 명령을 실행합니다.


    ./csdb check dbdir /tmp/check.out 

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

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

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

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