데이터 복구 및 고가용성

백업 개요

다음 제한사항에 주의하십시오.

• 테이블 스페이스가 같은 테이블에서 온라인으로 재구성하는 경우 DMS 테이블 스페이스에서 온라인 백업 조작을 시작할 수 있습니다. 자르는 단계 동안 재구성 조작의 잠금 대기가 발생할 수 있습니다.
• 테이블 스페이스가 같은 테이블에서 온라인으로 재구성하는 경우 SMS 테이블 스페이스에서 온라인 백업 조작을 시작할 수 없습니다. 두 조작 모두 배타적 잠금이 필요합니다.

백업 사용

백업 유틸리티에 다음 제한사항이 적용됩니다.

• 테이블 스페이스 백업 조작 및 테이블 스페이스 리스토어 조작은 비록 여러 다른 테이블 스페이스에서 실행하더라도 동시에 실행할 수 없습니다.
• 파티션된 데이터베이스 환경에서 롤 포워드 복구를 수행할 수 있으려면, 노드 목록에서 데이터베이스를 정기적으로 백업하고 시스템의 나머지 노드에 대해 적어도 하나의 백업 이미지를 가지고 있어야 합니다(노드가 해당 데이터베이스에 대한 사용자 데이터를 담고 있지 않은 경우에도). 데이터베이스에 대한 사용자 데이터가 없는 데이터베이스 파티션 서버에서 데이터베이스 파티션의 백업 이미지가 필요한 두 가지 상황이 있습니다.
  • 최종 백업을 수행한 후 데이터베이스 파티션 서버를 데이터베이스 시스템에 추가했고, 이 데이터베이스 파티션 서버에서 포워드 복구를 수행해야 합니다.
  • 특정 시점 복구가 사용되어 시스템의 모든 데이터베이스 파티션이 롤 포워드 보류 상태에 있어야 합니다.
  • DMS 테이블 스페이스에 대한 온라인 백업 조작은 다음의 조작과 호환되지 않습니다.
    • 로드
    • 재구성(오프라인 전용). 재구성 조작의 자르는 단계에서 잠금 대기가 발생한 경우에도 백업 중인 테이블 스페이스에 있는 테이블을 온라인으로 재구성할 수 있습니다.
    • 테이블 스페이스 삭제
    • 테이블 절단
    • 인덱스 작성
    • 처음에 로그되지 않음(CREATE TABLE 및 ALTER TABLE문 사용)

고가용성 재해 복구 개요

START HADR, STOP HADR 또는 TAKEOVER HADR 명령을 수행할 때, 해당 오류 코드(SQL01767N, SQL01769N 또는 이유 코드 98의 SQL01770N)가 생성될 수 있습니다. 이 이유 코드는 명령을 실행한 서버의 HADR에 대해 설치된 라이센스가 없음을 나타냅니다. 문제점을 해결하려면, db2licm을 사용하여 유효한 HADR 라이센스를 설치하거나 분배의 일부로 유효한 HADR 라이센스가 포함된 서버 버전을 설치하십시오.

플랫폼간 백업 및 리스토어 지원

DB2 Universal Database^(TM)(UDB)는 플랫폼간 백업 및 리스토어 조작을 지원합니다.

DB2^(R) UDB 버전 8 Windows^(R)(32비트) 플랫폼에서 작성된 데이터베이스를 DB2 UDB 버전 8 Windows(64비트) 플랫폼에 리스토어하거나 DB2 버전 8 Windows(64비트) 플랫폼에서 작성된 데이터베이스를 DB2 UDB 버전 8 Windows(32비트) 플랫폼에 리스토어할 수 있습니다.

DB2 UDB 버전 8 Linux^(TM)(32비트) 플랫폼에서 작성된 데이터베이스를 DB2 UDB 버전 8 Linux(64비트) 플랫폼에 리스토어하거나 DB2 버전 8 Linux(64비트) 플랫폼에서 작성된 데이터베이스를 DB2 UDB 버전 8 Linux(32비트) 플랫폼에 리스토어할 수 있습니다.

DB2 UDB 버전 8 AIX^(R), HP-UX, Linux PPC, Linux zSeries^(R) 또는 Solaris 운영 환경 플랫폼에서 32비트 또는 64비트로 작성된 데이터베이스를 DB2 UDB 버전 8 AIX, HP-UX, Linux PPC, Linux zSeries 또는 Solaris 운영 환경 플랫폼(32비트 또는 64비트)에 리스토어할 수 있습니다.

테이프에 백업(Linux)

Linux에서 3480 및 3490 테이프 디바이스에 대한 최대 블록 크기 한계는 61 440바이트입니다.

Tivoli Storage Manager

BACKUP DATABASE 또는 RESTORE DATABASE 명령을 호출할 때, 데이터베이스나 테이블 스페이스 백업 또는 리스토어 조작을 관리하기 위해 TSM(Tivoli^(R) Storage Manager) 제품을 사용하도록 지정할 수 있습니다. 다음을 제외하고 필요한 최소 TSM 클라이언트 API 레벨은 버전 4.2.0입니다.

• TSM 클라이언트 API 버전 4.2.1이 필요한 64비트 Solaris 시스템
• TSM 클라이언트 API 버전 5.1이 필요한 64비트 Windows NT^(R) 운영 체제
• 최소 TSM 클라이언트 API 버전 5.1.5가 필요한 iSeries^(TM) 및 pSeries^(R)용 32비트 Linux
• TSM 클라이언트 API 버전 5.3 이상이 필요한 iSeries 및 pSeries용 64비트 Linux
• 최소 TSM 클라이언트 API 버전 5.2.0이 필요한 AMD Opteron 시스템의 64비트 Linux
• 최소 TSM 클라이언트 API 버전 5.2.2가 필요한 zSeries용 64비트 Linux

HADR 로컬 호스트 및 로컬 서비스 매개변수에 대한 값 제한사항

데이터베이스 구성 갱신 명령을 준비하는 동안 고가용성 재해 복구(HADR) 로컬 호스트 및 로컬 서비스 매개변수(HADR_LOCAL_SVC 및 HADR_REMOTE_SVC)의 값을 지정할 경우, 값은 다른 서비스에 사용하지 않는 포트여야 합니다. Linux 또는 UNIX^(R) 명령행을 사용하여 매개변수를 구성할 경우, 값은 /etc/services 파일에서도 명시해야 합니다.

고가용성 재해 복구에 대한 추가 시스템 요구사항

기본 데이터베이스에서 테이블 스페이스를 작성하는 데 컨테이너를 사용할 수 없어서 대기 데이터베이스에서 로그 재생에 실패할 경우, 기본 데이터베이스는 로그 재생에 실패했음을 알리는 오류 메시지를 수신하지 못합니다.

오류 재생 오류를 점검하려면, 새 테이블 스페이스를 작성할 때 대기 데이터베이스에서 db2diag.log와 관리 로그를 모니터해야 합니다.

인계 조작이 발생하면 작성한 새 테이블 스페이스는 새 기본 데이터베이스에서 사용할 수 없습니다. 이러한 상황을 복구하려면 백업 이미지를 통해 새 기본 데이터베이스에서 테이블 스페이스를 복원하십시오.

다음 예에서 테이블 스페이스 MY_TABLESPACE는 새 기본 데이터베이스로 사용되기 전에 MY_DATABASE 데이터베이스에서 리스토어됩니다.

1. db2 connect to my_database
2. db2 list tablespaces show detail
   주:
   db2 list tablespaces show detail 명령을 실행하여 모든 테이블 스페이스 상태를 표시하고 5단계에 필요한 테이블 스페이스 ID를 확보하십시오.
3. db2 stop hadr on database my_database
4. db2 "restore database my_database tablespace (my_tablespace) online redirect"
5. db2 "set tablespace containers for my_tablespace_ID_# ignore rollforward container operations using (path
   '/my_new_container_path/')"
6. db2 "restore database my_database continue"
7. db2 rollforward database my_database to end of logs and stop tablespace "(my_tablespace)"
8. db2 start hadr on database my_database as primary

고가용성 재해 복구를 위한 비복제 조작

버전 8.2 문서 상태:

BLOB 및 CLOB가 복제되지 않습니다. 그러나 이들에 대한 스페이스가 대기 데이터베이스에서 할당됩니다.

명령문은 다음과 같아야 합니다.

로그되지 않은 BLOB 및 CLOB는 복제되지 않지만 스페이스는 대기 데이터베이스에서 할당됩니다.

HADR에서 지원하지 않는 원시 로그

고가용성 재해 복구(HADR)는 데이터베이스 로그 파일에 대해 원시 I/O(직접 디스크 액세스)의 사용을 지원하지 않습니다. HADR이 START HADR 명령으로 시작되거나 데이터베이스가 구성된 HADR을 사용하여 재시작되었지만 원시 로그가 발견된 경우, 연관된 명령은 SQL1768N 이유 코드 "9"로 실패합니다.

결함 모니터 및 Health Monitor 비교

Health Monitor 및 결함 모니터는 단일 데이터베이스 인스턴스에서 |작동하는 도구입니다. Health Monitor는 Health 표시기를 사용하여 |특정 데이터베이스 관리 프로그램 성능이나 데이터베이스 성능의 상태를 |평가합니다. Health 표시기는 테이블 스페이스와 같은 |일부 특정 클래스의 데이터베이스 오브젝트를 측정합니다. 해당 클래스의 |데이터베이스 오브젝트 상태를 판별하도록 Health 표시기를 특정 기준으로 |평가할 수 있습니다. 또한 표시기가 임계값을 초과하거나 데이터베이스 오브젝트가 |비정상 상태임을 표시할 때 Health 표시기에서 이를 알리는 경보가 |생성될 수 있습니다.

비교해서 보면 결함 모니터의 경우 모니터링 및 실행 중인 인스터스를 |보존하는 기능만 있습니다. 모니터링 중인 DB2 UDB 인스턴스가 |예기치 않게 종료하면 결함 모니터가 인스턴스를 재시작합니다. 결함 |모니터는 Windows에서 사용될 수 없습니다.

결함 모니터링 해제

데이터베이스 인스턴스 DB2INST1에 대한 결함 모니터링을 해제하려면 |DB2 UDB 명령 창에서 다음 명령을 입력하십시오.

   db2fm -i db2inst1 -f no

결함 모니터가 DB2INST1에서 더이상 실행되지 않음을 확인하려면 UNIX 시스템에서 |다음 명령을 입력하십시오.

   ps -ef|grep -i fm

Linux 시스템에서 다음 명령을 입력하십시오.

   ps auxw|grep -i fm

db2fmd 및 DB2INST1이 표시되는 항목에는 결함 모니터가 해당 인스턴스에 |계속 실행 중인 상태로 표시됩니다. 결함 모니터를 해제하려면 인스턴스 소유자로서 |다음 명령을 입력하십시오.

   db2fm -i db2inst1 -D