DB2 기초: IBM DB2 Universal Database 백업 유틸리티 (한글)

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다.  제안 및 의견 피드백

난이도 : 초급

Dale McInnis, DB2 Development, IBM Canada Ltd.
Paul Zikopoulos, DB2 Competitive Technologies Team, IBM Canada Ltd.

2006 년 6 월 26 일

IBM® DB2® UDB 백업의 최신 기능을 경험해 봅시다. 백업 프로세스 모델, 온라인 및 오프라인 백업의 다양한 유형, Tivoli Storage Manager®를 사용하여 백업하는 방법에 대한 힌트와 팁, 자가 튜닝 기능, 체계적인 백업 전략의 이유와 효과 등을 설명합니다.

머리말

DB2 Universal Database for Linux, UNIX®, Windows® (DB2)의 최신 기능들을 설명하는 것은 중요하다. 왜냐하면 사용자들에게 새로운 핵심 기능에 익숙한지를 물으면 대부분의 사람들은 한번도 들어본 적 없다고 말한다. 출시된 지 꽤 오래되었음에도 말이다. 이 글에서 DB2의 Backup 유틸리티에 대해 알아보고자 한다. 특징과 새로운 기능들을 설명한다.

위로

백업을 하는 이유

정기적인 백업을 해야 하는 이유는 많이 있다. (복구 가능성을 테스트 해야 하는 이유도 많이 있다.) 데이터를 백업할 이유를 못찾겠다면 당신의 직업을 재고해보기 바란다. 백업은 애플리케이션 에러에서 복구하고, 데이터베이스를 복사하고(개발 또는 테스트 시스템을 파퓰레이트 하기), 데이터베이스를 새로운 하드웨어로 옮기고, 새로운 레벨로 마이그레이션 하고, 소프트웨어 업데이트 전후에 복구 가능성을 시험하고, 재해 복구(DR) 또는 고 가용성(HA)을 설정하는 등 여러 가지 작업에 필요하다.

흥미롭게도 요즘 사람들이 백업을 하는 가장 큰 이유는 애플리케이션 에러로부터 복구할 수 있는지를 확인하기 위해서라는 점이다.

오늘날의 하드웨어는 매우 안전하다. 사실, 듀얼 전원, RAID, 듀얼 컨트롤러 등은 거의가 표준이고, 모든 것이 정확히 설정되었다면 하드웨어 정전으로 고생할 일은 거의 없다. 하지만 인간이 만든 에러에서 보호하려면 어떻게 해야 하는가?

위로

왜 파일 시스템 백업이 아닌 DB2 백업인가?

새로운 데이터베이스 관리자(DBA)에게 많은 질문들을 받는다. 가장 주요한 이유는 DB2는 매우 적극적으로 Hot cache (애플리케이션이 필요로 하는 데이터를 메모리에 놓는 것.) 를 유지하려고 한다. 64 비트 모델이 확산되면서 속도가 떨어지지 않도록 하는 것이 추세이다. (그리고 프로세서의 L1, L2, L3 캐시나 랜덤 메모리에 둘 수 있는 데이터가 많을수록 워크로드는 더 빨라진다.) 근본적으로 여러분은 공격적인 데이터 캐싱을 원한다. 왜냐하면 이것은 데이터를 디스크에서 가능한 한 멀리 떨어트려 놓고 값비싼 I/O 사이클을 피하기 때문이다.

DB2가 실행중일 때 파일을 파일 시스템에 백업했다면 DB의 일관성 문제가 발생할 수 있고 또한 데이터를 복구할 수 있다는 것도 보장할 수 없다. 예를 들어, 데이터베이스가 실행중인 동안 파일을 복사한다면 특정시점( PIT)에 대한 데이터베이스안에 있는 모든 데이터들을 복사할 수 없다.

반드시 DB2 백업을 사용하여 데이터의 일관성을 보장해야 한다. 그렇지 않으면 전체 DB2 인스턴스를 오프라인으로 하지 않고는 어떤 것도 보장할 수 없다. DB2 기반의 백업을 사용하면 다음과 같은 온라인 기능의 장점을 활용할 수 있다. 즉 백업이 진행되는 동안 DDL 및 DML을 허용하므로 평상시처럼 비즈니스 업무를 수행할 수 있다.

즉 중요한 테이블만 백업하고 전혀 백업할 필요가 없는 혹은 자주 백업할 필요가 없는 다른 테이블은 그대로 둘 수 있다. DB2 백업은 복구할때에도 도움이 된다. 로그를 이용하여 당신이 선택한 특점시점으로 데이터베이스를 되돌릴 수 있다. 다시 말하면 파일 시스템 방식을 사용한 정적 스냅샵과는 달리 제어를 통해 시스템을 특정시점으로 되돌릴 수 있다는 것이다.

DB2는 "하위 세트" 복구를 실행한다. 예를 들어, 다섯 개의 테이블 공간을 백업하면 미디어 오류가 있는 단 한 개의 테이블 공간만 복구할 수 있다. 반면, 파일 시스템 백업은 "모 아니면 도" 식이다.

위로

DB2 백업에 대해서

DB2 백업 유틸리티는 DB2 엔진과 완벽히 통합된다. 단순한 애드온 유틸리티가 아니다. 이미 언급했지만 DB2 유틸리티는 세분화된 기능을 갖추고 있다. 백업 이미지는 다음의 항목들의 어떤 결합도 될 수 있다.

• 데이터베이스 또는 테이블 공간의 리스트
• 온라인 또는 오프라인
• 완전한, 점증적인, 또는 델타

DB2의 백업 유틸리티는 데이터 페이지를 물리적으로 복사한다. 백업 프로세스는 파일 시스템 백업이 아니라 논리적 백업이다. DB2 백업 이미지에는 데이터외에 메타데이타, 데이터베이스 설정, 히스토리 파일, 테이블 공간 정의등 추가정보가 들어 있다.

여러분이 시스템을 백업하면 DB2는 디스크에서 인풋/아웃풋(I/O) 버퍼로 데이터를 읽고, 이를 목표 장치나 제 3의 저장 관리 소프트웨어(IBM Tivoli Storage Manager)에 작성한다. DB2 V8.2 부터, 온라인 백업의 경우 백업 이미지에는 로그 파일이 포함되어 있다. (오프라인 백업은 로그 파일들을 복구할 필요가 없다.) 임시 테이블 공간과 사용하지 않았던 DMS Extent 는 백업 이미지에는 포함되지 않는다. 또한 DB2 백업 유틸리티는 압축 기능( DB2 V8.1.4 부터 ) 과 가속화 ( DB2 V8.2 부터)를 가지고 있다.

DB2는 매우 효율적이고 최적화된 백업 유틸리티를 갖고 있어서 여러 채널를 통해 데이터 페이지를 읽고 임의의 순서로 그것을 대상 디바이스에 쓴다. 다시 말하면 DB2는 백업 유틸리티의 성능을 최적화하기 위해 데이터 페이지를 임의의 순서로 쓴다. (여기서는 여러분이 복구보다는 백업은 더 많이 수행할 것이라고 가정한다.) 또한 DB2 백업 유틸리티는 Raw 디바이스를 지원한다.

DB2에서 사용할 수 있는 세 가지 다른 종류의 백업들이 있다.

• 전체 백업(full backup)은 완전한 백업이다. (0 레벨 백업으로도 표현된다.)
• 점증적인 백업은 마지막 전체 백업 이미지 후에 있었던 모든 변경 사항들을 포착한다. (때로는 1 레벨 백업이라고도 한다.)
• 마지막으로 델타 백업은 어떤 종류의 마지막 백업 이후 변경 사항들을 포착한다. (레벨 2 백업이라고 한다.)

백업 프로세스 모델

DB2 백업 프로세스 모델은 언급할 가치가 있다. DB2 프로세스가 어떻게 수행되는지를 알고 있다면 시스템의 퍼포먼스를 이해하는데 도움이 된다. 그림 1은 DB2의 백업 프로세스 모습이다.

왼쪽을 보면 DB2 테이블 공간과 컨테이너들을 볼 수 있다. 백업 유틸리티를 호출하면 db2agent가 생성되어 버퍼 조종자 (db2bm 프로세스는 디스크에서 공유 메모리로 데이터를 읽어 들이는데 사용됨.) 와 db2bm 프로세스 (공유 메모리를 읽어 대상 장치에 페이지를 작성함.) 사이의 흐름을 제어한다.

얼마나 빠르게 이 프로세스들이 실행되는지에 대해서는 제한이 없다. 하지만 DB2 스로틀링 기능을 사용하여 여러분의 환경의 워크로드와 관련하여 이들을 제어할 수 있다. 이러한 유틸리티들이 빠르게 실행되도록 구성하려면 버퍼 매니퓰레이터가 데이터를 특정 장치 컨트롤러로 줄 필요가 없게끔 코딩되어야 한다. 이것을 "경주"라고 생각하라. DB2는 백업 미디어에 어떤 순서로 페이지들이 배치되는지 신경 쓰지 않는다. 단지 얼마나 빠르게 도달할 수 있는지가 중요하다.

각 테이블 공간은 그 테이블 공간에 있는 모든 데이터를 처리하는 담당 프로세스가 할당된다. 버퍼 매니퓰레이터의 수는 Backup 유틸리티를 호출할 때 사용되는 병렬 옵션에 의해 제어된다. 예를 들어, 이 옵션을 2 로 설정하면 여러분은 두 개의 db2bm 프로세스를 갖게 된다. 각 두 개의 개별 테이블 공간들을 병렬로 읽을 수 있다.

db2med 프로세스는 여러분이 준 목표의 수와 동일하다. 예를 들어, Tivoli Storage Manager의 경우 세 가지 세션을 열 경우 DB2는 세 개의 스트림을 Tivoli 서버에 설정한다. DB2 드라이브 병렬성이 아카이브 미디어에 도움이 된다.

데이터를 파일 시스템에 백업하고 그 파일 시스템이 가상 다중 디스크들이라면 마운트 포인트를 여러 번 지정해야 한다. 예를 들어, Windows용 DB2에서 다음과 같이 명령어를 입력한다.

backup database sample to c: c: c:

이 경우, DB2는 아카이브 미디어에 세 개의 db2med 프로세스를 만들고 db2bm 프로세스에서 그곳으로 병렬로 데이터 페이지를 작성한다.

점증적인 백업

점증적인 백업은 우선 V7.2 릴리스에 도입되었다. 우리는 이러한 유형의 백업이 점점 인기를 얻어가고 있다는 것을 알았다. 이것이 처음 도입되었을 때 데이터 수정이 비교적 적은 데이터 웨어하우징 용도였다.

점증적인 백업은 이전 백업 이후에 변경된 인덱스와 데이터 페이지만 백업할 수 있다. 예외로는 긴 필드와 "dirty" 테이블 공간의 LOB 데이타이다. 이들은 항시 백업된다. 이러한 유형의 데이터에 대해서는 점증적인 지원이 없다. 왜냐하면 이러한 데이터 유형은 인덱스와 데이터 페이지와는 다른 물리적 포맷을 갖고 있기 때문이다. 현재 DB2 버전은 백업시점에서 LOB 데이터가 변경되었는지를 알 수 없다. 이 예외는 DB2 향후 버전에서는 없어질 것이다.

그림 2는 DB2에서 사용할 수 있는 다양한 종류의 부분 백업을 보여주고 있다.

이 그림에서 볼 때 점증적인 백업은 마지막 전체 백업에 기반하고 있다는 것을 알 수 있다. 화요일에 수행된 점증적인 백업에는 전체 백업이 일요일에 수행된 후에 월요일과 화요일의 모든 변경 사항들을 포함하고 있다는 의미이다.

델타 백업은 마지막 점증적인 백업 또는 델타 백업에 기반하고 있다. 델타 백업의 경우 데이터를 재구현 할 수 있으려면 마지막 전체 백업 후에 취해진 모든 백업들을 관리해야 한다. 예를 들어, 수요일의 근무시간 까지 데이터를 복구하려면 월요일, 화요일, 수요일(또는 수요일의 로그 파일)의 델타 백업 이미지가 필요하다. 화요일에 점증적인 백업을 수행했다면 화요일의 점증적 백업 이미지와 수요일의 델타 백업 이미지 (또는 로그 파일) 가 필요하다.

변경된 페이지들 외에도, 점증적인 백업에는 데이터베이스의 메타데이터(데이터베이스 설정, 히스토리 파일, 테이블 공간 정의)가 포함되어 복구를 돕는다. 이러한 메타데이터는 점증적이지 않다. 매번 전체 복사를 수행한다.

기본적으로 DB2 데이터베이스는 점증적인 백업으로 설정되어 있지 않다. 런타임시 성능에 별로 영향을 주지 않으므로 DB2가 이러한 유형의 백업을 수행토록 한다. 이러한 유형의 백업을 실행하려면 TRACKMOD 데이터베이스 설정 매개변수를 ON으로 설정한다. (매개변수 변경은 다음 데이터베이스 활성화 까지는 유효하지 않다.)

TRACKMOD가 실행되면 첫번째 쓰기 연산은 데이터가 주둔하고 있는 테이블 공간에 “dirty”로 표시를 남긴다. 만약 테이블 공간이 "dirty"로 표시되어 있지 않다면 백업시 DB2는 이 테이블 공간을 보지 않고 넘어가고 DB2가 "dirty bit"를 확인하면 테이블 공간내에 있는 Extent 를 검사하여 변경된 데이터 페이지만 백업 이미지로 가져온다. 점증적인 백업을 지원하기 위해 사용된 트래킹 기능은 완전히 내부적인 것이고 스토리지 고려 사항들을 필요로 하지 않는다.

점증적인 백업은 전체 백업이 기본적으로 취해지기 전까지는 허용되지 않는다. 이는 점증적 복구를 위해서는 항상 전체 백업 이미지가 있어야 하기 때문이다.

온라인 백업

DB2는 온라인 또는 오프라인 백업을 수행할 수 있다. 온라인 백업은 정상적인 SELECT, INSERT, DELETE, UPDATE 동안 실행될 수 있다. DB2에서 온라인 백업을 실행할 때의 유일한 제약은 테이블 공간이 백업되고 있는 동안 테이블 공간을 삭제할 수 없다는 것이다.

오프라인 백업의 경우 DB2는 데이터베이스를 읽는 유일한 애플리케이션이라는 것을 알기 때문에 잠금에 대해서는 걱정할 필요가 없다. 온라인 백업의 경우, 상황은 약간 다르다. DB2는 온라인 백업에 대해 잠금 전략을 구현해야 한다. LOB 데이터 와 긴 필드 데이터의 경우, DB2는 Intent None (IN) 잠금을 Share (S) 잠금으로 확대하기 때문에 10% 정도 느려진다.

온라인 백업은 이 작업을 지원하기 위한 내부 구조를 할당하기 위해 UTIL_HEAP 메모리로부터 좀 더 많은 메모리를 취한다.

위로

데이터베이스 히스토리 파일

데이터베이스 히스토리 파일은 데이터베이스 엔진에서 점점 더 중요한 부분이 되고 있다. 데이터베이스 히스토리 파일은 관리 작동에 대한 기록이다. 파일은 백업 이미지가 어떤 형태이든 개별적으로 복구 될 수 있다. 이 파일에 기록된 이벤트들에는 백업, 복구, 로그의 롤 포워드, 로드, 데이터베이스 또는 테이블 공간의 queiscing, 테이블 공간 변경, 삭제된 테이블(삭제된 테이블이 복구될 경우) 같은 연산이 포함된다. 이렇게 기록된 연산에 대한 정보에는 영향 받은 객체들(데이터베이스, 테이블 공간, 테이블), 위치 및 장치 유형(백업 이미지 또는 로드 카피), 관련 로그 파일의 범위, 연산의 시작 및 종료 시간, 결과 SQLCA 코드 등이 포함된다. DB2는 이제 이 파일을 이용하여 자동 복구를 지원한다. 새로운 로그 매니저 역시 이 파일을 사용한다.

이 정보는 복구할 때 꼭 필요로 하기 때문에 DB2 테이블이 아닌 파일로 저장된다. 데이터베이스를 사용할 수 없다면 이것을 데이터베이스 복구에 활용할 수 없다. 따라서 데이터베이스 히스토리는 ASCII 파일 형태로 저장되고 그것을 복구 및 처리할 수 있도록 백업 이미지에 포함된다.

위로

삼자 백업 벤더 지원

백업하는 동안 데이터를 작성하기 위해 DB2가 사용하는 미디어 프로세스는 1993년 이후 오픈 마켓에 사용되었던 인터페이스 세트에 구현된다. 따라서 오늘날 유명한 대부분의 백업 벤더(IBM Tivoli Storage Manager (TSM), Veritas NetBackup, Legato NetWorker, Compuer Associates ) 들은 DB2를 지원한다.

어떤 벤더도 이 인터페이스를 사용하여 그들의 솔루션을 DB2와 통합할 수 있다.(그림 3)

백업 정보를 파일에 작성하는 대신 벤더의 아카이브 소프트웨어에 플러그인 될 때 DB2는 백업 데이터를 이러한 인터페이스에 작성하고, 대상 아카이브 서버에 직접 보낸다.

예를 들어, TSM을 사용하고 있다면 DB2는 TSM API를 로딩할 것이다. 이러한 라이브러리들은 DB2 커널에 직접 로딩되고 어드레스 공간에서 실행된다. 벤더의 플러그인 코드(DB2 V7+FP11)의 품질을 걱정할 필요가 없다. DB2는 파트너 코드의 오류로부터 인스턴스 주소를 보호하기 때문이다. 사실 작업이 수행되기 전에 DB2는 미리 시그널 핸들러의 상태를 얻고 그 후에 그것을 리셋한다. 벤더의 코드가 잘못되어도 데이터베이스 엔진은 고장 나지 않는다. (백업 연산 자체는 실패할 것이다.)

DB2는 Tivoli Storage Manager와 긴 통합의 역사를 갖고 있다. 사실, DB2는 TSM API용 추가 지원에 있어 두 번째 애플리케이션이었다. Tivoli와의 긴 역사 덕택에(사실 IBM 제품이다.) TSM을 무료로 지원한다.

Tivoli Storage Manager 힌트&팁

TSM을 사용하기 위해 DB2를 설정하는 것은 간단하다.

우선, dsmapipw 유틸리티(관리 권한을 가진 사용자로서)를 실행하여 TSM 패스워드를 설정한다. 이 유틸리티는 sqllib\adsm 디렉토리에 있다. 이 유틸리티는 TSM 패스워드를 디스크 상의 노드용으로 암호화 및 저장한다. 이 단계에서의 오류가 TSM과 DB2를 사용할 때의 문제의 60%를 차지한다. 패스워드가 정확하게 설정되지 않으면 137 에러 코드를 받게 된다.

다음에 DB2 TSM 스팩의 환경 변수를 반출한다. 세 가지 환경 변수들이 있다.

• DSMI_DIR는 TSM 클라이언트가 설치된 디렉토리이다.
• DSMI_CONFIG는 TSM의 설정 장소이다.
• DSMI_LOG는 모든 에러가 작성되는 파일을 지정한다.

이 모든 설정들은 인스턴스가 시작될 때 포착된다. 따라서 이들 중 어떤 것이라도 변경하면(그리고 TSM과 작동하도록 DB2를 처음 설정한 것이라면), 인스턴스를 재시작 해야 한다. 설정 매개변수들 중 일부만 변경한다면 인스턴스만 재시작 하면 된다. 예를 들어, TSM 설정 파일(통신하기 원하는 TSM 서버)에서 특정 TSM 설정을 변경했다면 데이터베이스 엔진을 재시작 할 필요가 없다. 이 환경 변수들은 일반적으로 DB2 인스턴스의 사용자 프로파일에 위치해 있다.

TSM은 타임스탬프를 사용하여 모든 백업들을 구분한다. DB2는 TSM 서버에 기간 만료 정책을 사용하지 않는다. 이는 백업들이 기간이 만료되지 않기 때문에 이것을 처리하기 위한 계획을 항상 고려해야 한다는 것을 명심해야 한다.

DB2 V7에서, 백업을 삭제하는 대신, DB2는 이들을 비활성으로 표시하기 때문에 TSM을 설정하여 비활성 카피들을 보유하도록 해야 한다. 이는 DB2 V8에서 변했다. 이제는 백업을 삭제할 때 TSM 관리 클래스 정의와 관계없이 수행한다.

DB2 V7에서 TSM을 사용하여 노드 상에 데이터베이스를 백업한다면 그 백업을 실행한 사용자만이 이를 복구할 수 있었다. DB2 V7환경에서는 이들이 또다른 서버로 옮겨야 한다는 점에서 문제점을 야기시켰다. 그래서 이동한 서버를 원래 노드인것처럼 가장해야만 했고 또한 각각의 패스워드를 알아야 했다. 목표 노드에 빈 데이터베이스를 만들고 TSM_NODENAME, TSM_PASSWORD, TSM_OWNER 데이터베이스 설정 매개변수를 설정하고 PASSWORDACCESS=PROMPT를 변경하고 dsm.opt 파일에 NODENAME에 주석을 달아야 했다.

DB2 V 8.2에서 이러한 복잡함이 "벤더 옵션" 지원의 추가로 해소되었다. 이 기능을 사용하면 옵션 매개변수들을 직접 TSM API로 보낼 수 있다. 백업 이미지가 생성되었던 이름과 원래 DB2 인스턴스 ID가 포함된다. 더 이상 원래 노드의 TSM 패스워드를 알 필요가 없어졌고 백업 이미지를 복구하는 프로세스도 두 단계로 간단해 졌다.

1. 백업 이미지를 생성한 후에 db2adutl 옵션을 사용하여 이 이미지에 대한 접근 권한을 새로운 노드에 부여한다.

   db2adutl grant newuser on nodename newhost for db mydb

   
   
2. 새로운 목표 노드에서 백업 명령어에 'options' 필드를 사용해야 한다. 예를 들어

   db2 restore db mydb use tsm options 'fromnode=originalnode fromuser=originalinstance'

   
   

마지막으로, DB2 V8에 db2audtl 유틸리티의 도입으로 TSM 서버에 대해 DB2 백업을 관리하는 방법이 향상되었다. 이전에는 DB2 네이밍 규칙 때문에 백업 관리가 복잡했었다. DB2는 백업 파일들의 이름을 만들므로 그 결과 백업 이미지는 유일한 이름을 갖고 기간이 만료되지 않기 때문에 TSM 관리 클래스에 의존하여 이들을 관리할 수 없다.

db2audtl 명령어는 7가지 옵션이 있다.

• DELETE: 백업을 비활성으로 표시하고(DB2 버전이 8 보다 하위 버전일 경우), 백업을 삭제하고(DB2 V8) 로그를 삭제한다. 버전이 8보다 하위 버전의 경우, TSM은 비활성 DB2 데이터베이스 백업 객체에 백업 카피 그룹 정의에 기반하여 삭제용 플래그를 단다. TSM Expire Inventory 명령어가 실행되면 삭제용 플래그가 붙은 객체들은 TSM 서버에서 제거된다. db2adutl이 데이터베이스 백업을 제거할 수 있으려면 Backdel 매개변수가 TSM 노드에 yes로 설정되어야 한다. TSM 서버에 저장된 DB2 로그를 지우려면 Archdel Yes 매개변수가 노드용으로 설정되어야 한다. 이 매개변수들은 TSM 노드를 등록할 때 지정될 수 있거나 TSM 서버에 대한 노드 정보를 업데이트 할 때 수행된다.
• QUERY: 노드에 생성된 모든 또는 특정 DB2 객체들을 나열한다. Show inactive 문은 비활성으로 표시된 백업 이미지들을 모는데 사용된다.
• EXTRACT: TSM 객체에서 디스크 이미지들을 만든다. 데이터베이스 이미지가 비활성으로 표시되면 더 이상 복구될 수 없다. 하지만 TSM 서버에서 여전히 추출될 수 있고 추출된 이미지는 복구를 수행하는데 사용된다. DB2 V8에서 db2adutl은 객체를 삭제하는데 사용된다. 비활성으로 표시될 뿐만 아니라 TSM 서버에서 즉각적인 종료로 설정된다.
• VERIFY: V6 이후 db2adutl 유틸리티에 VERIFY 옵션이 생겼다. 이미지가 TSM 서버에서 읽힐 수 있고 유효성 검사를 수행할 수 있다. 이는 db2ckbkp 유틸리티를 실행할 수 있는 방식이다. (이전에는 dumpimage로 알려짐.) 이미지가 복구 가능할 지 확인하려면 TSM을 통해서 수행한다.
• GRANT: 호스트 상에 사용자에게 db2 백업 이미지와 로그 파일들에 액세스하는 기능을 제공한다. 이는 GRANT 옵션을 실행하는 노드상에 생성된 데이터베이스와 제휴 되어 있다.
• REVOKE: 호스트 상의 사용자에게 DB2 백업 이미지와 지정된 또는 모든 데이터베이스와 제휴 된 로그 파일들로의 액세스를 취소할 수 있는 기능을 제공한다.
• QUERYACCESS: 호스트 상의 사용자에게 queryaccess 옵션을 실행하는 노드 상에서 생성된 지정된 또는 모든 데이터베이스와 관련된 db2 백업 이미지와 로그 파일들로의 허용된 액세스를 쿼리 할 기능을 제공한다.

다음 테이블은 TSM과 DB2 V7에 대한 지원 내용이다.

위로

DB2 V8.1 BACKUP의 새로운 점

이 섹션에서는 DB2 V8.1에 도입된 새로운 기능에 대해 알아보도록 하겠다.

DB2 V8.1.2

DB2 V8.1.2에서 Backup 유틸리티에서 스로틀링이 실행된다. 이는 매우 강력한 기능으로서 DBA가 서비스 레벨 계약(SLA)을 엄수할 수 있다.

우선 먼저 문제를 정의하는 것부터 시작한다. 이 글에서 간단히 설명했듯이, DB2 Backup 유틸리티는 한 가지를 염두해 두고 디자인 되었다. 바로 성능이다. 이것은 고객이 원하는 것이다. 고객이 성능을 요구하면 줄어든 배치 윈도우를 만나게 되고 더 작아진 관리 윈도우에 더 많은 손을 써야 했다. 세상은 변했다. 세상은 변했고 비즈니스 환경은 중단없이 24x7, 지속적으로 사용이 가능해야 한다.

Backup 유틸리티를 가능한 한 빠르게 만들어달라고 요청했던 고객들이, 이제는 이를 천천히 실행할 방법을 모색해 줄 것을 요청하고 있다. 유틸리티 스로틀링이 도입된다.

스로틀링 유틸리티는 Backup 유틸리티 정책을 정의함으로써 정상업무의 특정 범주까지는 현재 운영서버의 워크로드에는 영향을 주지 않을 것이다. 다시 말해서 DB2에 의해 사용될 수 있는 리소스를 제한하여 비즈니스 환경의 다양한 요소에 맞춰 유틸리티 속도를 높이거나 줄일 수 있고 중지할 수 있다.

그림 5은 백업 같은 유틸리티 스로틀링 효과이다.

이전 차트에서 백업이 실행되지 않을 때 쓰루풋(분 당 트랜잭션)을 볼 수 있었다. BACKUP이 실행되면 이 시스템의 트랜잭션 비율은 100 Tpm 밑으로 떨어진다. 스로틀링은 운영 서버의 워크로드에 허용되는 비율을 설정할 수 있도록 한다. 업무 환경에 맞도록 백업의 쓰루풋을 만들수 있다.

SLA가 분 당 300 트랜잭션 이상을 관리하는데 기반하고 있다면 non-adaptive 스로틀 비율을 70%로 설정해야 한다. 이것은 30% 정도 운영서버에 영향을 줄 수 있도록 백업 작업이 리소스를 소비하는 것을 의미한다.) DB2는 BACKUP에 사용할 수 있는 리소스들을 조정하여 운영 서버의 워크로드에 미치는 영향을 평균 30%로 한다.

DB2 V8.1.4

DB2 V8.1.4에서 BACKUP 유틸리티는 압축 옵션으로 강화되었다. 그리고 새로운 TSM 통합 명령어(GRANT와 REVOKE)가 추가되었다.

DB2에 데이터베이스 백업을 압축할 것을 요청할 수 있다. 백업 유틸리티는 디스크를 히트하기 전에 데이터를 버퍼에 압축한다. 이 데이터는 변형된 Lempel-Zev (LZ) 알고리즘("A Technique for High Performance Data Compression," Welch, Terry A., IEEE Computer, vol. 17, no. 6 (June 1984), pp. 8-19.)을 사용하여 데이터베이스에서 읽혀질 때 압축된다. 디폴트 알고리즘은 플랫폼 독립이기 때문에 AIX용 DB2에서 백업하여 이것을 HP 머신용 DB2에 둘 수 있다.

BACKUP 유틸리티의 오픈 플러그인 인터페이스를 통해 압축 알고리즘을 제공할 수 있다. 압축 라이브러리를 지정하고 머신을 소실했다면 걱정하지 말라. DB2는 알고리즘의 실행 파일들을 백업 이미지에 복사하기 때문에 이미지를 복구할 수 있다.

다음 다이어그램은 DB2 BACKUP 압축 알고리즘을 사용한 공간 절약 샘플이다. 이 예제에서, 전형적인 ERP 데이터베이스는 압축 옵션과 함께 백업된다. 백업 크기는 대략 180MB에서 30 MB 정도이다.

또 다른 테스트에서, 완전히 랜덤화 된 데이터베이스(ASCII 문자와 숫자로 구성됨)는 250MB에서185MB 이다.

이 압축은 소프트웨어 기반이기 때문에 여러분의 환경을 추가 CPU 사이클로 부과한다. 예를 들어, ERP 예제에서 백업 시간은 56분에서 1시간 46분이다. 하지만 네트워크의 대역폭이 병목에 걸리면 감소된 이미지 크기 때문에 I/O 시간도 줄어든다.

DB2 V8.2.4는 새로운 TSM GRANT/REVOKE 명령어를 도입했다.(TSM 힌트와 팁 섹션 참조)

DB2 V8.2

DB2 V8.2는 BACKUP 분야에 많은 향상이 있었다. 우선, BACKUP 유틸리티는 이제 자가 튜닝이다. 사실, 대부분의 경우, 버퍼의 수를 지정할 값을 결정하는데 시간을 보내야 한다. 또한 필요한 병렬의 정도와 버퍼 크기도 정해야 한다. DB2 V8.2에서의 BACKUP 실행은 DB2 V8.1과 비교된다.(그림 8)

DB2 V8.2에서, BACKUP 유틸리티는 버퍼의 수, 병렬성 정도, 버퍼 크기에 대해 자동화 되고 최적화된 설정을 갖고 있다. 이러한 설정은 테이블 공간의 수에 기반하여 DB2에 의해 선택된다. 각 테이블 공간의 EXTENTSIZE, 사용할 수 있는 CPU의 수, 가용 메모리에 기반하고 있다.

자율 설정은 DB2에 의해 선택된다. BACKUP 명령어를 실행할 때 마다 이전에 언급된 매개변수들은 명령어의 호출에 지정되지 않고 API에서 BACKUP을 호출할 경우 0으로 설정되지 않는다.

DB2 V8.2은 DB2가 백업의 필요성을 알려주는 기능을 도입했다. 실제로는 백업도 수행한다. 이는 얼마간의 간격을 두고 데이터베이스 백업을 스케줄링하는 것 이상이다. 백업 작동을 실행하는 비즈니스 기반 정책을 정의할 수 있다. 예를 들어, 마지막 백업이 자동 백업을 실행하기 때문에 총 로그 공간이 소비된다. DB2가 그 작업을 수행하는 것을 원치 않는 DBA는 이 기능을 활용하여 DB2가 DBA가 정의한 정책에 기반하여 또 다른 백업을 실행할 시간이라고 믿을 때 이메일을 받는다. 물론 이것은 이러한 기능과 스로틀링을 결합하여 제품 환경에 영향을 미치지 않도록 한다.

마지막으로 데이터베이스와 테이블 공간의 온라인 백업 이미지들에는 백업 이미지를 견고한 상태로 복구하는데 필요한 로그 파일들이 포함되어 있다. 클라이언트는 이로서 재해에서 복구 될 수 있다. 우리 경험으로는 많은 클라이언트들이 백업을 수행할 때 로그 파일들을 갖고 있지 않는다. 오류가 생기면 그들은 복구될 수 없다. 이 기능은 온라인 백업에만 사용될 수 있으며 백업 명령어에 "include logs" 옵션을 지정함으로서 호출된다. 복구 동안 로그 파일들은 백업 이미지에서만 추출될 수 있다. LOGTARGET 필드가 제공되고 LOGSONLY 매개변수가 설정되면 로그 파일들만 백업 이미지에서 추출된다. 데이터베이스 데이터가 아니다.

기사의 원문보기

• DB2 Basics: The IBM DB2 Universal Database for Linux, UNIX, and Windows Backup Utility

위로

참고자료

• DB2 Technical Support
  
  
• DB2 UDB zone
  

위로

필자소개

		Dale McInnis는 University of New Brunswick에서 학사 학위를 University of Toronto에서 석사 학위를 받았다. Dale은 1988년에 IBM에 입사했으며 1992년부터 DB2 개발 팀에서 일했다. 이 때에도 Dale은 DB2 커널 개발(인덱스 관리, 백업과 복구, 데이터링크 기술, 고 가용성 아키텍트)에 집중했다.

		Paul C. Zikopoulos는 the IBM Database Competitive Technologies 팀의 수상 경험이 있는 작가이자 대변인이다. DB2 분야에서 9년 경력을 쌓았으며 관련 잡지 및 책을 집필했다. Paul은 DB2 Version 8, The Official Guide, DB2, The Complete Reference, DB2 Fundamentals Certification for Dummies, DB2 for Dummies, A DBA's Guide to Databases on Linux의 공동 저자이다. DB2 Certified Advanced Technical Expert (DRDA and Cluster/EEE)와 DB2 Certified Solutions Expert (Business Intelligence and Database Administration)를 보유하고 있다. 현재 그는 Apache Derby/IBM Derby 데이터베이스 관련 책을 집필하고 있다.(paulz_ibm@msn.com)

위로

기사에 대한 평가

보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오. 귀하께서 원하시는 정보를 얻었습니까? 예 아니오 잘 모르겠음   이 페이지 개선을 위한 의견을 주십시오:   이 정보가 얼마나 유용했습니까? (1 = 전혀 도움이 되지 않음, 5 = 매우 유용함) 1 2 3 4 5

위로