내용 목차
본 장에서는 Tibero Recovery Catalog의 구성요소와 동작 및 운영 방법을 설명한다.
Tibero Recovery Catalog는 다수의 데이터베이스들의 메타데이터(metadata)를 관리를 목적으로 제공하는 기능이다.
Tibero Recovery Catalog는 물리적으로 독립된 장소에 여러 데이터베이스들의 메타데이터를 보관한다. 메타데이터를 보관하는 데이터베이스를 Catalog 데이터베이스(이하 Catalog)라고 한다. 관리하려는 데이터베이스를 Catalog에 등록하면 tbrmgr이 등록하려는 데이터베이스의 컨트롤 파일(Control file)을 읽어 메타데이터를 추출하고, Catalog에 이 데이터를 원격으로 보내어 저장한다. Catalog에 최신 데이터를 업데이트할 수 있다. 그 외에 RMGR 클라이언트를 이용하여 백업을 생성하거나 지우는 경우 관리자가 직접 resync 요청을 보내는 경우에도 메타데이터를 업데이트한다.
저장하는 메타데이터는 다음과 같다.
데이터베이스 아이디, 데이터베이스 이름과 같은 데이터베이스의 기본 정보
테이블 스페이스, 데이터 파일, Redo 로그와 같은 데이터베이스 구조
데이터베이스의 체크포인트
데이터베이스 및 아카이브 로그 백업
Catalog를 이용하면 다음과 같은 이점을 얻을 수 있다.
컨트롤 파일 이외의 장소에 메타데이터를 저장할 수 있어 정보의 다원화가 가능하다.
하나의 데이터베이스에 여러 데이터베이스의 메타데이터를 중앙화하여 관리할 수 있다.
컨트롤 파일에서는 언젠간 사라질 가능성이 있는 아카이브 로그, 로그 히스토리, 백업, 백업 아카이브 로그 정보들을 Catalog에서는 더 길게 보관하는 것이 가능하다.
컨트롤 파일을 재생성하거나 백업을 이용해 복구하였을 시 유실되는 정보들을 Catalog를 이용해서 복구하는 것이 가능하다.
Tibero Recovery Catalog는 Catalog Database에 관리가 필요한 다른 데이터베이스들의 메타데이터를 보관하는 구조를 가진다. 데이터베이스를 Catalog로 사용하기 위해서는 catalog create가 필요하다.
Create할 때 다음을 생성한다.
테이블 스페이스 RECOVERY_CATALOG
데이터베이스들의 메타데이터를 저장하기 위한 테이블 스페이스이다.
시퀀스 SITE_KEY_SEQ
등록된 데이터베이스들을 구분하기 위한 고유값 SITE_KEY 생성을 위한 시퀀스이다.
데이터 파일 recovery_catalog.dtf
메타데이터를 저장하기 위한 데이터 파일이다. 100MB의 크기로 생성되며 autoextent 10MB가 설정되어 있다. Single 데이터베이스 기준 매일 한번 백업을 진행한다고 하였을 때 1년에 약 10MB 정도의 용량을 사용하게 되므로 이를 참고하여 저장공간을 설정하면 된다.
RECOVERY_CATALOG 테이블 스페이스에는 메타데이터 저장을 위한 테이블을 가지고 있으며 RC_SITE_KEY 테이블을 제외한 나머지는 DBID_KEY, SITE_KEY, DBINC_KEY를 Primary Key로 한다. 사용자는 각 KEY 값을 이용하여 Catalog에서 관리할 데이터베이스의 메타데이터 정보를 열람할 수 있다.
| Primary Key | 설명 |
|---|---|
| DBID_KEY | 데이터베이스의 ID이다. 각 데이터베이스의 DBID와 대응하며 V$DATABASE에서 확인 가능하다. |
| SITE_KEY | 데이터베이스의 고유 KEY 값이다. Primary와 Standby는 같은 DBID를 가지기에 이 들을 구분할 수 있는 KEY 값인 SITE_KEY를 가진다. 이 값은 SITE_KEY_SEQ를 통해 생성된다. |
| DBINC_KEY | 데이터베이스의 Incarnation이다(RESETLOGS 부트를 한 시점 정보). 각 데이터베이스의 RESETLOGS_TSN과 대응한다. DBID를 가지기에 이 들을 구분할 수 있는 KEY 값인 SITE_KEY를 가진다. 이 값은 SITE_KEY_SEQ를 통해 생성된다. |
메타데이터를 저장하기 위해 생성한 테이블의 종류는 아래와 같다.
| 테이블 이름 | 설명 |
|---|---|
| RC_LAST_RESYNC | 등록된 데이터베이스가 Catalog에 데이터를 업데이트 할때의 정보를 기록하는 테이블이다. |
| RC_DATABASE | 등록된 데이터베이스의 기본 정보를 기록하는 테이블이다. 컨트롤 파일의 Database Entry section과 대응한다. |
| RC_DB_INCARNATION | 데이터베이스의 INCARNATION 정보를 기록하는 테이블이다. |
| RC_SITE_KEY | 데이터베이스의 DB_UNIQUE_NAME에 대응하는 고유한 열쇠값인 SITE_KEY를 기록하는 테이블이다. 이 테이블은 Incarnation의 구분이 필요하지 않기에 DBINC_KEY를 가지지 않는다. |
| RC_REDO_THREAD | 데이터베이스의 Redo Thread에 대한 정보를 기록하는 테이블이다. 컨트롤 파일의 Redo Thread section과 대응한다. |
| RC_FLASHBACK_THREAD | 데이터베이스의 Flashback Thread에 대한 정보를 기록하는 테이블이다. 컨트롤 파일의 Flashback Thread section과 대응한다. |
| RC_STANDBY_REDO_THREAD | 데이터베이스의 Standby Redo Thread에 대한 정보를 기록하는 테이블이다. 이 테이블은 스탠바이 데이터베이스에서만 업데이트가 진행이 되며, 컨트롤 파일의 Standby Redo Thread section과 대응한다. |
| RC_LOGFILE | 데이터베이스의 Redo 로그 파일에 대한 정보를 기록하는 테이블이다. 컨트롤 파일의 Log File section과 대응한다. |
| RC_TABLESPACE | 데이터베이스의 테이블 스페이스에 대한 정보를 기록하는 테이블이다. 컨트롤 파일의 Tablespace section과 대응한다. |
| RC_DATAFILE | 데이터베이스의 데이터 파일에 대한 정보를 기록하는 테이블이다. 컨트롤 파일의 Datafile section과 대응한다. |
| RC_ARCHIVED_LOG | 데이터베이스의 아카이브 로그에 대한 정보를 기록하는 테이블이다. 컨트롤 파일의 Archived logs section과 대응한다. |
| RC_LOG_HISTORY | 데이터베이스의 로그 스위치 기록에 대한 정보를 기록하는 테이블이다. 컨트롤 파일의 Log History section과 대응한다. |
| RC_BACKUP_SET | 데이터베이스의 백업 셋에 대한 정보를 기록하는 테이블이다. RC_BACKUP_SET은 같은 DB_NAME을 공유하는 데이터베이스들이 모두 공유한다. 컨트롤 파일의 Backup Set section과 대응한다. |
| RC_BACKUP_ARCHIVELOG | 데이터베이스의 백업 아카이브 로그에 대한 정보를 기록하는 테이블이다. RC_BACKUP_ARCHIVELOG는 같은 DB_NAME을 공유하는 데이터베이스들이 모두 공유한다. 컨트롤 파일의 Backup Archivelog section과 대응한다. |
Tibero Recovery Catalog를 구성하는 기본적인 단계는 다음과 같다.
Catalog를 생성한다.
Catalog에 필요한 오브젝트들을 생성하는 단계이다. 자세한 사항은 “18.3.1. Catalog Create”를 참고한다.
관리하고자 하는 데이터베이스를 Catalog에 등록한다.
등록을 통해 Catalog는 해당 데이터베이스의 메타데이터를 저장한다. 자세한 사항은 “18.3.2. Catalog Register”를 참고한다.
필요에 따라 Resync를 진행하여 데이터베이스의 메타데이터를 업데이트한다.
메타데이터의 업데이트는 사용자가 RMGR 클라이언트를 통해 수동으로 진행된다. 자세한 사항은 “18.3.4. Catalog Resync”를 참고한다.
Tibero Recovery Catalog는 RMGR 클라이언트를 이용하여 Catalog를 관리할 수 있다.
Catalog를 관리하기 위한 커맨드는 tbrmgr catalog이며, Catalog와 관련된 모든 기능은 이 커맨드를 통해 동작해야 한다. tbrmgr catalog는 기존 tbrmgr과 옵션을 공유하지 않으며, catalog 옵션은 아래와 같다.
| catalog 옵션 | 설명 |
|---|---|
| create | --cat-userid, RMGR_CATALOG_SID 파라미터로 지정한 데이터베이스를 Catalog로 이용하기 위해 필요한 작업을 실행한다. |
| register | 데이터베이스를 Catalog에 등록하는 작업을 실행한다. |
| unregister | 데이터베이스를 Catalog에서 등록 취소하는 작업을 실행한다. |
| resync | Catalog에 등록된 메타데이터를 현재 데이터베이스의 메타데이터로 업데이트하는 작업을 실행한다. |
| re-register | 컨트롤 파일 재생성과 같이 기존의 컨트롤 파일이 유실된 데이터베이스를 Catalog에 다시 등록하는 작업을 실행한다. |
| --userid | 데이터베이스에 접속할 사용자명과 패스워드 및 SID를 아래와 같은 형식으로 지정한다. --userid USERID[[/PASSWD][@SID]] 화면상에 비밀번호 노출을 원치 않을 때에는 비밀번호를 공백으로 입력한 후 비밀번호를 입력하라는 문구가 나오면 비공개로 번호를 입력할 수 있다. --userid USERID/[@SID] OS 인증을 받은 계정으로 로그인하는 경우 Userid와 Passwd를 입력하지 않아도 로그인 가능하다 --userid / |
| --cat-userid | Catalog에 접속할 사용자명과 패스워드 및 SID를 지정한다. --userid와 같은방식으로 지정하며 RMGR_CATALOG_SID를 지정했을 경우 SID 생략이 가능하다. SID와 RMGR_CATALOG_SID를 모두 지정했다면 --cat-userid에서 지정한 SID가 적용된다. |
| -h, --help | RMGR Catalog의 옵션 사용법을 출력한다. |
| -l, --log-level | 클라이언트 측 RMGR 로그(tbrmgr_trace.log)의 기록 레벨을 설정한다. 레벨은 1부터 5까지 있으며 숫자가 커질수록 더 자세히 기록된다. 기본 레벨은 4이다. |
| -L | tbrmgr_trace.log의 기록될 위치를 지정한다. 기본 경로는 $TB_HOME/client/tbrmgr_log/이다. |
| --all-incarnation | Unregister할 때 모든 incarnation의 메타데이터 정보를 같이 제거한다. |
| --backup-set | 백업 셋과 백업 아카이브 로그의 메타데이터에 대해서만 Resync를 진행한다. |
| --archivelog | 아카이브 로그의 메타데이터에 대해서만 Resync를 진행한다. |
| --log-history | 로그 히스토리의 메타데이터에 대해서만 Resync를 진행한다. |
Tibero Recovery Catalog의 모든 기능을 사용하기 위해 클라이언트는 반드시 Catalog에 연결되어야 한다. 따라서 tbrmgr catalog를 사용할 때는 반드시 --cat-userid를 [예 18.1]와 같이 설정해야 한다.
Catalog에 접속하기 위해선 tbdsn.tbr 파일에 설정이 필요하다.
[예 18.1] Catalog SID 설정 및 연결
cat=(
(INSTANCE=(HOST=123.1.2.3)
(PORT=12345)
(DB_NAME=cat)
)
)
tbrmgr에서 Catalog에 접속하려면 위에서 설정한 SID를 tip 파일의 RMGR_CATALOG_SID 또는 option 중의 하나인 --cat-userid를 설정해야 한다. 두 방법 중에는 --cat-userid를 이용한 설정이 우선 적용된다.
# tip을 이용한 sid 설정 RMGR_CATLOG_SID=cat # rmgr option을 이용한 sid 설정 tbrmgr catalog create --cat-userid <userid>/<passwd>@cat
Create는 RMGR_CATALOG_SID나 --cat-userid로 설정된 데이터베이스를 Catalog로써 사용할 수 있도록 필요한 작업을 실행한다.
tbrmgr catalog create --cat-userid <userid>/<passwd>@cat
위와 같이 작업이 완료되면 Catalog는 메타데이터 관리에 필요한 테이블 스페이스, 데이터 파일 및 테이블들을 생성하게 된다. 생성되는 것은 “18.2. 구성 요소”를 참고한다.
특정 데이터베이스를 관리하기 위해선 해당 데이터베이스를 Catalog에 등록해야하며 이 과정을 Reigster(등록)라고 한다. 다음과 같이 등록을 진행할 수 있다.
tbrmgr catalog register --userid <userid>/<passwd>@<SID> --cat-userid <userid>/<passwd>@cat
RMGR 클라이언트는 데이터베이스의 메타데이터들을 컨트롤 파일에서 직접 읽어서 Catalog에 등록한다. 등록을 완료하면 데이터베이스도 자신이 등록되었음을 컨트롤 파일에 기록한다.
이 때 Catalog는 등록된 데이터베이스들을 DB_UNIQUE_NAME 값으로 구분한다. DB_UNIQUE_NAME은 각 데이터베이스를 구분하기 위한 파라미터로 미설정 시 DB_NAME과 같은 값을 가지게 된다.
만약 등록할 데이터베이스의 DB_UNIQUE_NAME이 이미 등록되어 있는 데이터베이스와 같다면 현재의 등록은 실패하게 된다. 관리자는 이 점을 유의하여 각 데이터베이스의 DB_UNIQUE_NAME을 다르게 설정해야 한다.
또한 Catalog는 데이터베이스를 Incarnation(RESETLOGS 부트를 한 시점 정보)마다 별개로 저장한다. 만약 데이터베이스를 RESETLOGS 부트한다면 기존과 다른 데이터베이스로 취급되며 Catalog 등록정보는 컨트롤 파일에서 사라지게 된다. Catalog는 기존 Incarnation의 메타데이터를 지우지는 않으나, 새 Incarnation의 데이터베이스가 다시 Catalog를 사용하기 위해선 register를 다시 진행해야 한다.
등록된 데이터베이스는 백업 및 복구 과정을 Catalog가 관리하게 되는데, 그로 인해 RMGR을 사용할 때 다음과 같은 부분의 변화가 생긴다.
Catalog에 연결하지 않으면 RMGR Backup / RMGR Delete 기능을 사용할 수 없다.
Catalog에 등록된 데이터베이스는 백업의 관리 주체가 자신에서 Catalog로 변한다. Catalog는 매 백업 때마다 적절한 Backup Set ID를 부여하고 한 DB_NAME을 가진 데이터베이스 내에 동일한 ID를 가진 백업이 없도록 관리한다. 등록된 데이터베이스는 Backup Set ID를 발급할 수 없기에 Catalog 없이는 RMGR 백업을 진행할 수 없고, 백업을 지우는 작업 역시 Catalog에서 관리되어야 하므로 Catalog 없이 진행이 불가하다.
TSC 환경에서 다른 노드가 진행한 백업을 이용해 복구를 진행할 수 있다.
TSC 환경의 Primary, Standby 모두 Catalog에 등록되어 있다면, 서로의 데이터베이스에서 각자 진행한 백업을 이용하여 복구를 진행할 수 있다. 이를 위해선 복구과정에서도 --cat-userid를 통해 Catalog에 연결이 필요하다. 복구과정에 최신 백업 셋이나 지정한 (-b|--backup-set)이 다른 데이터베이스에서 진행되어 컨트롤 파일에 존재하지 않는다면, Catalog에서 복구에 필요한 백업 셋들의 정보 자동으로 컨트롤 파일에 추가한 뒤에 복구 과정을 진행한다.
백업 파일까지 보내주지는 않기에 데이터베이스가 해당 백업 파일에 접근이 가능한 경우에만 사용 가능하다.
Standby에서 백업을 진행하면 백업 셋 정보는 Catalog에 남으며, Primary에서도 Catalog를 통해 확인이 가능하다. 최신의 백업 셋이 Standby에서 진행한 2번 백업이라고 가정하자. 이때 Primary가 Catalog에 연결한채로 복구를 진행하면, 클라이언트는 Catalog에서 자동으로 2번 백업 셋 정보를 가져와 복구를 진행한다.
[예 18.2] Primary를 Standby의 백업을 이용하여 복구 진행
$ tbrmgr recover --cat-userid sys/1234@cat -o /disk1/backup ============================================================================== = Recovery Manager(RMGR) starts = = = = TmaxData Corporation Copyright (c) 2008-. All rights reserved. = ============================================================================== RMGR '-o' option not used : restoring from the paths actually backed up previously ============================================================================== RMGR - recovery (COMPLETE) ============================================================================== Shutting down the instance... Tibero instance terminated (ABNORMAL mode). info file is deleted. unlink failed.: No such file or directory Control file #0 (/home/tibero/c1.ctl) is accessible All control files are accessible. No need to restore the backup control file. Booting up the instance... Listener port = 6001 Tibero 7 TmaxData Corporation Copyright (c) 2008-. All rights reserved. Tibero instance started up (MOUNT mode). Last backup set id: 2 The backup set does not exist in the control file. Copy backup set(s) infos from the recovery catalog to the control file. Initializing the restore progress, it may take few minutes... RMGR begins restoring backup files. Full backup set_id: 2 Last incremental backup set_id: 2 ...
데이터베이스의 메타데이터를 catalog에서 제거하는 과정을 진행하는 기능이다.
tbrmgr catalog unregister --userid <userid>/<passwd>@<SID> --cat-userid <userid>/<passwd>@cat
unregister의 진행은 데이터베이스의 현재 Incarnation 정보에 대해서만 진행된다. 만약 데이터베이스의 모든 정보를 삭제할 --all-incarnation 옵션을 추가해야 한다.
Catalog의 메타데이터를 현재 데이터베이스의 메타데이터와 동기화하는 작업을 진행한다.
tbrmgr catalog resync --userid <userid>/<passwd>@<SID> --cat-userid <userid>/<passwd>@cat
별도로 옵션을 주지 않았을 경우 모든 메타데이터에 대해 동기화가 진행되는 Full Resync가 진행되며, Resync 옵션 중에 하나를 주었을 경우엔 지정한 섹션의 메타데이터만 동기화하는 Partial Resync가 진행된다.
백업 셋 및 백업 아카이브 로그을 제외한 나머지 메타데이터는 사용자가 직접 Resync 요청을 보내야만 진행된다. 백업 셋 및 백업 아카이브 로그는 다른 데이터베이스와 공유하는 메타데이터이기에 RMGR Backup / Delete 등이 진행될 때도 자동으로 수행된다.