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

22장 문제 해결

이 장에서는 시스템에 문제가 있는지 여부와 문제의 원인을 확인하는 데 사용할 수 있는 몇 가지 문제 해결 기술에 대해 설명합니다. 이 장은 다음 내용으로 구성되어 있습니다.

디버깅 정보 설정

전체 시스템을 “디버그 모드”로 실행하는 ics.conf 매개 변수는 없지만 이 절에서는 유용한 디버그 정보를 가져오는 몇 가지 방법을 설명합니다.


주 –

과도한 로깅과 모니터링은 성능에 부정적인 영향을 주므로 필요하지 않은 경우 해제하십시오.


로깅 수준 올리기

다음 표에 표시된 매개 변수를 사용하여 로깅의 세부 수준을 늘리십시오.

매개 변수 

설명 및 기본값 

logfile.loglevel

CRITICAL, ALERT, ERROR, WARNING, NOTICEINFORMATION을 포함하여 모든 수준을 기록하려면 DEBUG로 설정합니다. 이 설정은 모든 로그에 적용됩니다.

사용 가능한 다른 로그에 대한 자세한 내용은 Calendar Server 로그 파일 사용을 참조하십시오.

LDAP 캐시에 대한 액세스 로깅 활성화

LDAP 데이터 캐시에 대한 모든 액세스를 기록하고 로그(보고서)를 출력하려면 다음 표에 표시된 ics.conf 매개 변수를 설정합니다.

매개 변수 

설명 및 기본값 

local.ldap.cache.stat.enable

LDAP 데이터 캐시에 대한 액세스 로그 여부 및 로그 파일의 통계 인 쇄 여부를 지정합니다. 기본값은 “no”(통계 기록 안 함)입니다. 통계 로깅을 사용 가능하게 하려면 “yes”로 설정합니다.

성능 개선을 위해 디버그 모드에서만 사용하십시오. 

local.ldap.cache.stat.interval

각 통계 보고서가 로그 파일에 기록되는 간격을 초 단위로 지정합니 다. 기본값은 “1800”초(30분)입니다.

로깅이 사용 가능한 경우에만 활성화됩니다. 간격을 줄이면 문제를 정확히 식별하는데 도움이 됩니다. 간격을 늘리면 시스템 로드가 줄어듭니다. 

LDAP 캐시 지우기

Calendar Server에는 현재 LDAP 캐시 데이터를 만료하기 위한 논리가 없습니다. ldap_cache 디렉토리의 내용을 수동으로 제거한 후 Calendar Server를 다시 시작해야 합니다.

ProcedureLDAP 캐시 지우기

단계
  1. Calendar Server를 중지합니다.

  2. /var/opt/SUNWics5/csdb/ldap_cache 디렉토리의 모든 파일을 제거하되, ldap_cache 디렉토리 자체는 제거하지 않습니다.

  3. Calendar Server를 다시 시작합니다.

Calendar Server 유틸리티를 사용하여 시스템 모니터

시스템을 모니터하려면 다음 Calendar Server 유틸리티를 사용합니다.

Calendar Server 유틸리티에 대한 자세한 내용은 부록 D, Calendar Server 명령줄 유틸리티 참조 를 참조하십시오.

LDAP 문제 해결

호스트된 환경을 처음으로 만드는 경우 도메인, 컨테이너, 사용자 및 자원에 대한 해당 항목을 추가하여 LDAP의 DC 트리를 만들어야 합니다. cscal과 같은 Calendar Server 유틸리티를 사용할 때 DC 트리가 없으면 "Initialization failed .... exiting".과 같은 오류 메시지가 표시됩니다.

DC 트리 루트에 최소한 하나(기본값)의 도메인이 있는지 확인합니다. 새 호스트된 도메인 만들기의 지침에 따라 DC 트리 구조를 만듭니다.

마이그레이션 유틸리티 문제 해결

Calendar Server는 달력 데이터베이스 및 LDAP 디렉토리 마이그레이션을 위한 여러 가지 유틸리티를 제공합니다. 이 절은 다음 내용으로 구성되어 있습니다.

기술 지원부에 문의하기 전에 수행할 작업

일반적으로 마이그레이션 유틸리티 사용 문제가 있는 경우 다음과 같은 정보를 미리 수집한 상태에서 기술 지원부에 문의해야 합니다.

마이그레이션 유틸리티 위치

다음 목록에 표시된 위치에서 다양한 마이그레이션 유틸리티와 해당 설명서를 찾을 수 있습니다.

스키마 마이그레이션 유틸리티(commdirmig)

이 유틸리티는 Delegated Administrator에 번들로 함께 제공되는 별도로 설치 가능한 구성 요소입니다. 이 유틸리티는 LDAP 디렉토리를 스키마 1에서 스키마 2로 마이그레이션합니다. 이 유틸리티에 대한 자세한 내용은 Sun Java System Communications Services 6 2005Q4 Schema Migration Guide를 참조하십시오.

Calendar Server 5 to Calendar Server 6 Migration 유틸리티(cs5migrate)

기술 지원부에서는 이 유틸리티가 들어 있는 마이그레이션 번들과 관련 설명서를 제공합니다.

Calendar Server Migration 유틸리티(csmig)

이 유틸리티는 Calendar Server와 함께 설치됩니다. 관련 설명은 문제 해결 절이 들어 있는 4 장, 데이터베이스 마이그레이션 유틸리티에 나와 있습니다. 호스트된 도메인 및 LDAP CLD(달력 조회 데이터베이스) 플러그 인을 사용하는 경우 이 유틸리티를 실행해야 합니다.

Calendar Server Virtual Domain Migration 유틸리티(csvdmig )

이 유틸리티는 Calendar Server와 함께 설치됩니다. 관련 설명은 4 장, 데이터베이스 마이그레이션 유틸리티에 나와 있습니다. 이 유틸리티를 사용하여 호스트된 도메인에 대한 달력 데이터베이스 및 LDAP 디렉토리 항목을 준비합니다.

Calendar Server 2 to Calendar Server 6 Migration 유틸리티( ics2migrate)

이 유틸리티는 Calendar Server와 함께 설치됩니다. 관련 설명은 4 장, 데이터베이스 마이그레이션 유틸리티에 나와 있습니다. 이 유틸리티를 사용하여 Calendar Server 5와 호환되도록 Calendar Server 2 데이터베이스를 마이그레이션합니다.

Netscape Calendar Server 4 to Calendar Server 5 Migration 유틸리티(ncs4migrate)

이 유틸리티는 기술 지원부를 통해서만 구할 수 있습니다. 설명서는 유틸리티 패키지에 포함되어 있습니다. 이 유틸리티는 Netscape Calendar Server 4를 Calendar Server 5로 마이그레이션합니다. 이러한 마이그레이션을 수행할 경우 소스 데이터베이스의 데이터가 일관되지 못하므로 특별히 주의해야 합니다. 수동으로 처리해야 할 작업이 많습니다. 이 유틸리티는 기술 지원부에서만 구할 수 있습니다. 설명서는 유틸리티 패키지에 포함되어 있습니다. 이 유틸리티는 Netscape Calendar Server 4에서 Calendar Server 5로 마이그레이션합니다. 이러한 마이그레이션을 수행할 경우 특별히 주의해야 합니다. 이 유틸리티를 실행하려면 먼저 소스 파일로 여러 가지 작업을 수행해야 합니다. 전문가 서비스의 도움을 받아 마이그레이션을 계획할 수 있습니다.

Calendar Server 문제 해결

이 절에서는 비데이터베이스 문제에 대한 다양한 문제 해결 정보를 제공합니다. 다음 항목에 대해 설명합니다.


정보 –

또한 SSL 장에 SSL에 대한 문제 해결 절인

SSL 문제 해결이 나와 있습니다.


달력 서비스 핑

서비스가 지정된 포트 번호를 수신하는지 확인하려면 cstool 유틸리티 ping 명령을 사용합니다. 서비스 핑으로 해당 서비스가 실제 실행 중인지 확인할 수는 없지만 소켓 연결을 받아들일 수 있는지 여부를 알려 줍니다.

cstool의 서비스 옵션

Calendar Server 서비스 옵션은 다음과 같습니다.

http

HTTP 서비스(cshttpd)

admin

관리 서비스(csadmind)

ens

이벤트 알림 서비스(enpd)


주 –

DWP 서비스(csdwpd) 또는 알림 서비스(csnotifyd)는 핑할 수 없습니다.


cstool 예제

예를 들어, 호스트 이름이 calserver인 시스템을 핑하여 cshttpd 서비스가 포트 80을 수신하는지 확인하려면 다음 명령을 사용합니다.

cstool -p 80 -h calserver ping http

기본적으로 cstool은 응답이 올 때까지 120초 동안 대기하지만 -t timeout 옵션을 사용하면 값을 변경할 수 있습니다.

전체적인 유틸리티 참조 자료를 보려면 부록 D, Calendar Server 명령줄 유틸리티 참조 를 참조하십시오.


주 –

cstool을 실행하려면 Calendar Server가 실행 중이어야 합니다.


Procedurestart-cal 문제 해결

start-cal을 실행할 때 모든 달력 서비스가 시작되지 않은 경우 시작된 서비스를 중지한 다음 다시 시작해야 합니다. 예를 들어, enpd, csnotifydcsadmind는 시작되었지만 cshttpd는 시작되지 않았으면 enpd, csnotifyd csadmind를 중지해야 합니다.

달력 서비스를 시작하려면

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

  2. start-cal을 사용하여 서비스를 중지한 다음 다시 시작합니다. 예를 들면 다음과 같습니다.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

    start-cal은 다양한 달력 서비스를 시작하기 전에 stop-cal 명령을 실행합니다.

  3. stop-cal이 중지되지 않는 경우 중지되지 않은 자식 프로세스가 있을 수 있습니다. 이 문제를 해결하려면 stop-cal 문제 해결을 참조하십시오.

stop-cal 문제 해결

Calendar Server가 종료될 경우에 고려해야 할 두 가지 사항이 있습니다.

Procedure자식 프로세스를 중지하려면

stop-cal을 실행한 후 일부 자식 프로세스가 중지되지 않았을 수 있습니다. 예를 들어, stop-calcshttpd 부모 프로세스를 중지할 수 있지만 cshttpd 자식 프로세스는 중지할 수 없습니다. 이 경우 다음 절차를 사용하여 나머지 Calendar Server 프로세스를 개별적으로 중지해야 합니다.

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

  2. 각 서비스마다 ps 명령을 입력하여 나머지 Calendar Server 프로세스의 프로세스 아이디(PID)를 확인합니다.


    ps -elf | grep cs-process
    

    여기서 cs-processenpd, csnotifyd, csdwpd, csadmind 또는 cshttpd입니다. 예를 들면 다음과 같습니다.


    ps -elf | grep cshttpd
  3. 아직 실행 중인 각 프로세스의 PID를 사용하여 kill -15 명령을 입력하여 프로세스를 종료시킵니다. 예를 들면 다음과 같습니다. kill -15 9875

  4. ps 명령을 다시 입력하여 모든 Calendar Server 프로세스가 중지되었는지 확인합니다.


    If a Calendar Server process is still running, 
       enter a kill -9 command to kill it. 
    For example: kill -9 9875

    주 –

    Calendar Server를 실행하는 Linux 시스템에서 ps 명령을 사용하여 달력 프로세스를 검색하면 혼동되는 결과가 나올 수 있습니다. Linux에서 ps 명령은 프로세스 목록이 아니라 실행 중인 스레드의 목록을 반환합니다. 프로세스만 표시하는 해결 방법은 알려져 있지 않습니다.


Procedure잘못된 종료 후 복구하려면

Calendar Server가 제대로 종료되지 않은 경우 다음 단계를 수행합니다.

단계
  1. 이전 절차 stop-cal 문제 해결의 단계를 수행합니다.

  2. LDAP 데이터 캐시 데이터베이스 디렉토리에서 모든 파일을 수동으로 삭제합니다.

    남아 있는 이러한 파일이 데이터베이스를 손상시킬 수 있습니다. 파일을삭제하려면 다음을 수행합니다.

    1. LDAP 데이터 캐시 디렉토리로 변경합니다.

      기본값은 /opt/SUNWics5/csdb/ldap_cache이지만 ics.conf 파일의 local.ldap.cache.homedir.path 매개 변수에 지정된 디렉토리를 사용합니다.

    2. 디렉토리에서 모든 파일을 제거합니다.

      예를 들면 다음과 같습니다. rm *.*

    3. 모든 파일이 제거되었는지 확인합니다.

      예를 들면 다음과 같습니다. ls

  3. Calendar Server를 다시 시작합니다.

    cal_svr_base /SUNWics5/cal/sbin/start-cal

    LDAP 데이터 캐싱 구성 방법에 대한 자세한 내용은 LDAP를 위한 Calendar Server 구성을 참조하십시오. LDAP 데이터 캐시에 대한 자세한 내용은 Sun Java System Communications Services 6 2005Q4 Deployment Planning Guide를 참조하십시오.

백엔드 서버에 연결할 수 없음

  1. 백엔드 서버를 핑하여 서버가 응답하는지 확인합니다.

    응답할 경우 3단계로 가고 응답하지 않는 경우 실패 원인을 확인하고 백엔드 서버가 다시 작동하는 경우 3단계의 작업을 계속합니다.

  2. CLD 캐시를 지웁니다. CLD 캐시 지우기를 참조하십시오.

    CLD 캐시 옵션을 사용하고 있으며 ics.conf 매개 변수의 서버 이름을 업데이트한 경우, 서버 이름을 제거하려면 CLD 캐시를 지워야 합니다. CLD 캐시에 이전 버전의 항목이 있으면 프런트엔드 서버가 정확한 백엔드 서버로 연결을 설정하지 못하게 되거나 Calendar Server가 옮겨진 후에 달력을 찾을 수 없게 됩니다.

  3. Calendar Server를 다시 시작합니다.

달력을 찾을 수 없음

CLD 캐시 옵션을 사용 중이고 하나 이상의 달력을 다른 백엔드 서버로 이동했거나 백엔드 서버의 이름을 변경한 경우 다음 단계를 수행합니다.

  1. 다음의 달력 이동 절차를 따라야 합니다.

    사용자 달력 관리

  2. CLD 캐시를 지웁니다. CLD 캐시 지우기를 참조하십시오.

    하나 이상의 달력을 다른 백엔드 서버로 이동한 경우 CLD 캐시가 이전 상태가 됩니다. CLD 캐시를 새로 고치려면 캐시를 지워 다시 작성해야 합니다.

프록시 인증을 사용하여 로그인하려고 할 때 “Unauthorized”라는 메시지가 표시됨

  1. service.http.allowadminproxy“yes”로 설정되어 있는지 확인합니다.

  2. admin-user에게 Calendar Server 관리자 권한이 있는지 확인합니다.

  3. admin-password가 올바른지 확인합니다.

  4. calendar-user가 올바른 Calendar Server 사용자인지 확인합니다.

올바르게 완료되지 않는 검색 문제 해결

LDAP 디렉토리 서버 구성의 nsslapd-sizelimitnsLookthroughLimit 속성은 검색이 제대로 완료될 수 있을 만큼 커야 합니다. nsSizeLimit이 부족할 경우 끝이 잘려나갈 수 있으며 결과가 표시되지 않습니다. nsLookthroughLimit이 부족할 경우 검색이 완료되지 않을 수 있습니다.

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

Procedure제한 속성에 해당 값이 있는지 확인

단계
  1. 이러한 속성 값이 제대로 설정되어 있는지 확인하려면 다음 명령을 사용합니다.

    ldapsearch -b "base " "(&(icscalendarowned=*user*)(objectclass=icsCalendarUser))"

    여기서 base는 Calendar Server에 대한 사용자 및 자원 데이터가 있는 LDAP 기본 DN이고 user는 최종 사용자가 사용자 인터페이스의 검색 대화 상자에 입력할 수 있는 값입니다.

  2. LDAP 서버가 오류를 반환하면 nsSizeLimit 또는 nsLookthroughLimit 속성이 충분히 크게 설정되지 않았기 때문일 수 있습니다.

Procedure제한 속성을 적절한 값으로 설정하려면

이러한 속성의 DN은 다음과 같습니다.

dn: cn=config,cn=ldbm databases,cn=plug ins,cn=config

단계
  1. ldapmodify를 사용하여 nsLookthroughLimit 값을 동적으로 설정합니다.

    이속성을 변경하려고 Directory Server를 중지했다가 다시 시작할 필요가 없습니다.

    기본값은 5000입니다. 검색 결과가 보고되지 않는 경우 이 값을 늘릴 수 있습니다. 그러나, 그렇게 하면 LDAP 서버 속도가 느려질 수 있습니다.

    제한이 사용되지 않게 하려면 제한을 -1로 설정할 수 있습니다. 그렇게 하면 시스템이 중단될 수 있으므로 주의하십시오

  2. nsslapd-sizelimit을 더 높은 값으로 설정하려면 다음 단계를 수행해야 합니다.

    1. Directory Server를 중지합니다.

    2. Edit the dse.ldif file.

    3. Directory Server를 다시 시작합니다.


      주 –

      ldapmodify를 사용하고 dse.ldif 파일을 편집하는 방법에 대한 자세한 내용은 다음에서 Directory Server 설명서를 참조하십시오.

      http://docs.sun.com/coll/1316.1http://docs.sun.com/coll/1404.1


csstored에서 성가신 일상 메시지 해제

start-cal 명령은 csstored 프로세스가 구성되어 있지 않더라도 기본적으로 이 프로세스를 시작합니다. 구성되지 않은 csstored 프로세스는 csstored가 실행 중인 모든 시스템에서 해당 프로세스가 구성되지 않았다는 메시지를 24시간마다 표시합니다.

csstored가 구성되지 않은 프로세스를 실행하지 못하게 하여 메시지를 비활성화합니다. csstored 프로세스가 실행되지 않게 하려면 메시지가 표시되는 각 시스템에 표시된 다음 ics.conf 매개 변수를 설정합니다.

service.store.enable=”no”

자동 백업을 수행하도록 csstored를 구성한 시스템에서는 프로세스를 비활성화하지 않도록 주의하십시오.

데이터베이스 문제 처리

이 절은 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

하나 이상의 파일과 해당 파일에 포함된 데이터베이스의 구조를 확인합니다.  

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

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

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

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

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

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

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

    local.caldb.deadlock.autodetect=”yes”


    주 –

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


데이터베이스 손상 검색

달력 데이터베이스 손상은시스템 자원 경쟁, 하드웨어 오류, 응용 프로그램 오류, 데이터베이스 오류 및 사람에 의한 실수 등 여러 가지 원인에 의해 발생할 수 있습니다. 이 절에서는 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 명령을 실행합니다.

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

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

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

읽기 전용 모드 사용

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


주 –

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


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

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

    달력 서비스를 중지하려면

    cal_svr_base/SUNWics5/cal/sbin/stop-cal

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

    cd /etc/opt/SUNWics5/config

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

    caldb.berkeleydb.readonly=”yes”

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

    cal_svr_base /SUNWics5/cal/sbin/start-cal

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

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

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

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

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

치료 방법

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

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

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

    성공적으로 시작되면 다음을 수행하여 두 대기열이 작동하는지 확인합니다.

    1. csschedule을 사용하여 GSE 대기열 검사

    2. dbrig를 사용하여 경보 대기열 검사

      csscheduledbrig 실행에 대한 자세한 내용은 부록 D, Calendar Server 명령줄 유틸리티 참조 를 참조하십시오.

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

    추적 중에 GSE 관련 함수(GSE 문자가 포함되어 있음)가 발견되면 GSE 대기열의 첫번째 항목과 이벤트 데이터베이스의 참조 항목을 조사합니다. 대부분의 경우 GSE 항목에서 참조되는 이벤트가 위반 항목입니다. 이 문제를 해결하려면 다음을 수행합니다.

    1. csschedule을 사용하여 GSE 항목을 제거합니다.

    2. cscomponents를 사용하여 데이터베이스에서 위반 이벤트를 제거합니다.

      csschedulecscomponents 실행에 대한 자세한 내용은 부록 D, Calendar Server 명령줄 유틸리티 참조 를 참조하십시오.

  4. 항목이 손상되지 않은 경우 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 실행)

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

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

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

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

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

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

    cd cal_svr_base/SUNWics5/cal/sbin

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

    ./start-cal

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

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

단계
  1. 핫 백업으로 되돌립니다.

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

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

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

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

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

이 절에서는 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가 항목 처리를 마치게 합니다.

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

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

  2. Calendar Server를 중지합니다.

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

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

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

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


    cd /opt/SUNWics5/cal/sbin

    주 –

    sbin 디렉토리의 디스크 공간이 문제라면 다른 디렉토리에서 rebuild 명령을 실행합니다.


  5. 달력 데이터베이스 복사본에 대해 rebuild 명령을 실행합니다.


    ./csdb rebuild /tmp/db /tmp/

    데이터베이스 경로를 지정하지 않은 경우 rebuild는 현재 디렉토리를 사용합니다. /tmp/ 매개 변수는 다시 작성된 데이터베이스의 대상 디렉토리를 지정합니다.

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

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


    주 –

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

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

    예를 들어, db_0601, db_0615db_0629 디렉토리에 백업 달력 데이터베이스 파일 3세트가 있는 경우, 다음 순서대로 rebuild 명령을 실행합니다.


    ./csdb rebuild db_0629 
    ./csdb rebuild db_0615 
    ./csdb rebuild db_0601

    그러면 rebuild 명령은 재구축된 데이터베이스를 cal_svr_base/SUNWics5/cal/sbin/rebuild_db 디렉토리에 저장합니다.


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

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


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

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

  9. 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_dumpdb_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 기술 지원에 문의하십시오.


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

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

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

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

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

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

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

    데이터베이스가 복구될 때까지 또는 데이터베이스를 복구할 수 없음을 확인할 때까지 다음 옵션을 순서대로 사용하여 db_dump를 실행합니다.

    • 옵션 없음 ? 심각하지 않은 데이터베이스 손상

    • -r 옵션 보통 수준의 데이터베이스 손상

    • -R 옵션 심각한 데이터베이스 손상-R 옵션은 부분 및 삭제된 레코드를 비롯하여 -r 옵션보다 더 많은 데이터를 손상된 데이터베이스로부터 덤프합니다.

      예를 들어, db_dump-r 옵션과 함께 실행하려면 다음 명령을 사용합니다.


      db_dump -r ics50events.db \> ics50events.db.txt
  5. db_load 유틸리티를 사용하여 출력 파일을 새 데이터베이스 파일로 로드합니다.

    예를 들면 다음과 같습니다.


    db_load new.ics50events.db < ics50events.db.txt

    db_load가 홀수 개수의 키나 데이터 항목을 보고할 경우 db_dump 출력 파일을 편집하여 홀수 키나 데이터 항목을 제거합니다. 그런 다음 db_load를 다시 실행합니다.

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

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

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

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


    Calendar database has been rebuilt

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

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

자동 백업 복사본 복원

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

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

복원하기 전에

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

Procedure핫 백업 복원

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

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

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

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

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

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

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

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

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

    db_recover -c -h recoverydb

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

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

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

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

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

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

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

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

  13. Calendar Server를 시작합니다.

  14. 새 복구 디렉토리에서 단계가 실패할 경우 다음과 같은 방법으로 손상되지 않은 이전 핫 백업을 식별합니다.

    1. 핫 백업에 대한 역방향 작업을 통해 db_verifycsdb -v list를 하나씩 차례로 실행하여 손상되지 않은 최신 복사본을 찾습니다.

    2. 통과한 첫 번째 핫 백업 복사본을 라이브 데이터베이스 디렉토리에 복원할 수 있습니다.

      핫 백업 복원의 설명대로 손상된 라이브 데이터베이스를 손상 없는 핫 백업으로 대체합니다. (먼저 복원하기 전에를 읽으십시오.)

    3. 핫 백업과 아카이브 백업이 없는 경우 기술 지원부에 문의하십시오. 아카이브 백업이 있는 경우 아카이브 백업을 복원하려면 다음에 나오는 절차를 따르십시오. (또한 복원하기 전에를 참조하십시오.)

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

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

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

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

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

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

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

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

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

    db_recover -c -h recoverydb

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

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

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

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

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

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

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

  12. Calendar Server를 시작합니다.

  13. 새 복구 디렉토리에서 단계가 실패할 경우 다음과 같은 방법으로 손상되지 않은 이전 아카이브 백업을 식별합니다.

    1. 아카이브 백업 복사본 역방향 작업을 통해 각각에 대해 세 복구 프로그램을 차례로 실행하여 손상되지 않은 최신 복사본을 찾습니다. db_recover -c-h, db_verifycsdb -v list.

    2. 통과한 첫 번째 아카이브 복사본을 라이브 데이터베이스 디렉토리에 복원할 수 있습니다.

      아카이브 백업을 복원하려면에 표시된 것처럼 손상된 라이브 데이터베이스를 손상 없는 아카이브 백업으로 대체합니다.

    3. 아카이브 백업이 수행되지 않으면 기술 지원부에 문의하십시오.

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

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

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

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

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

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

LD_LIBRARY_PATH=libdb-4.2.so