|
그 밖의 복구문제
7-1. 다음과 같이 초기화 파라미터가 설정되어 있을 때 “RECOVER DATABASE” 명령을 실행하면 몇 개의 복구 프로세스가 실행되는가?.
PARALLEL_MIN_SERVERS = 2
PARALLEL_MAX_SERVERS = 5
RECOVERY_PARALLELISM = 3
a. 1
b. 2
c. 3
d. 4
e. 5
<해설>
CPU가 여러 개 장착된 시스템에서는 복구 프로세스를 여러 개 띄워서 병렬로 작업을 수행하면 시간을 크게 절약할 수 있다. 물론 적용해야 할 아카이브 로그 파일의 개수가 적을 때에는 별반 차이가 없으나 그 수가 수백, 수천 개로 늘어나면 매우 효과적인 복구 방법이 된다.
병렬 복구 기능을 이용할 때에는 몇 개의 복구 프로세스를 사용하느냐가 관건인데 최적의 값을 결정짓는 요소는 CPU와 디스크 및 디스크 컨트롤러의 수이다.
RECOVER DATABASE 명령을 아무런 옵션 없이 사용하면 디폴트로 NOPARALLEL로 인식되므로 하나의 복구 프로세스를 이용해서 작업이 진행된다.
RECOVERY_PARALLELISM 파라미터의 값이 2 이므로 디폴트로 두 개의 복구 프로세스가 실행되지 않을까 하고 의문을 가질 수도 있지만 이 파라미터는 인스턴스 복구에 사용되는 것으로 미디어 복구에는 해당되지 않으므로 주의를 요한다.
SVRMGRL> RECOVER DATABASE PARALLEL;
과 같이 몇 개의 복구 프로세스를 띄울지를 지정하지 않으면 오라클에서 자동으로 PARALLEL_MIN_SERVERS와 PARALLEL_MAX_SERVERS 사이에서 최적의 값을 선택하도록 되어 있다. 실제로 몇 개의 복구 프로세스가 실행되는지를 알고 싶다면 alertlog 파일을 참조하면 된다.
정답 : (a) (<- 마우스로 정답 부분을 선택하세요)
7-2. ASCII 형태의 컨트롤 파일을 생성하는 “ALTER DATABASE BACKUP CONTROLFILE TO TRACE” 명령은 데이터베이스가 어떤 상태일 때 실행할 수 있는가? (두 가지)
a. CLOSED
b. NOMOUNT
c. MOUNT
d. OPEN
<해설>
컨트롤 파일을 생성할 때에는 NOMOUNT 상태에서 작업을 하는데 그 이유는 데이터베이스가 MOUNT 될 때 컨트롤 파일을 열어서 데이터베이스의 물리적 정보를 확인해야 하기 때문이다. 그러므로 MOUNT 이상의 상태에서는 컨트롤 파일이 오픈되어 있으므로 그 정보를 읽어서 트레이스 파일에 저장할 수 있지만 CLOSED와 NOMOUNT 단계에서는 컨트롤파일의 내용을 알지 못하므로 이 명령을 이용해서 백업할 수 없다.
정답 : (c),(d) (<- 마우스로 정답 부분을 선택하세요)
7-3. READ-WRITE 상태의 테이블스페이스를 백업한 다음에 READ-ONLY 상태로 변경하였다. 나중에 디스크 장애가 발생해서 아카이브 파일을 이용한 복구를 수행할 때 이 테이블스페이스에 대한 처리 방법으로 옳은 것은?
a. 복구 후에 READ_WRITE 상태로 변경해 주어야 한다.
b. 복구 후에 READ-ONLY 상태로 변경해 주어야 한다.
c. 특별한 조치는 필요 없다.
d. 복구 작업을 하기 전에 이 테이블스페이스를 OFFLINE 시켜야 한다.
<해설>
READ-WRITE 상태에서 백업을 받은 이후에 READ-ONLY 상태로 변경했다면 백업을 받고 나서 READ-ONLY 상태로 변경하기까지의 시간동안 발생한 작업에 대해서는 아카이브 로그를 이용한 복구 작업이 필요하다.
만약 READ-ONLY 상태로 변경한 다음에 백업을 받아 놓은 것이 있다면 백업을 리스토어 하는 것으로 간단히 복구가 끝나므로 빨리 작업을 끝마칠 수 있다.
백업을 리스토어한 다음에 아카이브 로그를 적용시키는 과정 속에는 READ-WRITE 상태에서 READ-ONLY 상태로 전환하는 작업도 포함되므로 복구를 마치고 나면 테이블스페이스는 READ-ONLY 상태가 되어 있으므로 특별히 취할 조치는 없다.
(d)와 같이 복구를 하기 전에 READ-ONLY 테이블스페이스를 OFFLINE 시키는 것은 백업 컨트롤파일을 이용해서 복구할 때 해당되는 내용이므로 본 문제와는 관련이 없다.
정답 : (c) (<- 마우스로 정답 부분을 선택하세요)
트러블 슈팅
8-1. “dbw0_2381.trc”라는 트레이스 파일은 어떤 초기화 파라미터가 가리키는 위치에 생성되겠는가?
a. BACKGROUND_DUMP_DEST
b. ARCHIVE_LOG_DEST
c. USER_DUMP_DEST
d. CORE_DUMP_DEST
<해설>
초기화 파라미터 중에는 “DEST”단어가 포함되어 파일 시스템 상의 디렉토리를 가리키는 것이 많다. dbw01_2381.trc 파일은 이름을 보면 알 수 있듯이 DBW0(Database Writer) 백그라운드 프로세스가 생성한 것인데 alert.log와 백그라운드 프로세스로부터 만들어지는 덤프 파일은 BACKGROUND_DUMP_DEST 파라미터가 가리키는 곳에 만들어진다.
USER_DUMP_DEST는 사용자가 만든 트레이스 파일이 생성되는 곳이고 CORE_DUMP_DEST는 유닉스 환경에서 오라클이 생성한 코어 파일이 저장되는 곳으로 유닉스 외의 운영 체제를 사용한다면 CORE_DUMP_DEST는 별 의미가 없다.
정답 : (a) (<- 마우스로 정답 부분을 선택하세요)
8-2. 데이터베이스가 CLOSED 상태에서도 블록 손상을 체크할 수 있는 방법은?
a. ANALYZE TABLE <테이블명> VALIDATE STRUCTURE;
b. DB_BLOCK_CHECKING 파라미터
c. DBMS_REPAIR 패키지
d. DBVERIFY 유틸리티
<해설>
데이터베이스의 블록이 손상되었다는 ORA-1578 메시지는 관리자가 만나기 꺼려하는 에러 중에서도 최우선으로 꼽힌다.
ORA-1578 에러를 해결하는 가장 손쉬운 방법은 문제의 객체를 삭제하고 다시 만드는 것이지만 이 방법은 너무 출혈이 크고 솔직히 해결책이라고 부르기는 곤란하다. 실제로 널리 애용되어온 방법은 인덱스를 통해서 손상된 블록에 해당되는 데이터를 제외한 나머지를 추출하여 새로운 객체를 만드는 것이었다. 지금은 그보다 한 단계 발전하여 보다 전문적인 방법을 활용할 수 있다.
ANALYZE TABLE <테이블명> VALIDATE STRUCTURE 명령은 지정한 객체의 구조적 결함 여부를 알려준다. 그러나 이 명령이 실행되는 동안에는 해당 객체에 대한 DML 작업을 할 수 없기 때문에 아무 때나 무심코 실행하면 업무가 마비될 수 있으므로 조심해야 한다.
DB_BLOCK_CHECKING 파라미터를 TRUE로 설정하면 데이터 블록을 변경할 때 손상 여부를 검사한다. 처리하는 데이터가 많을수록 시스템에 걸리는 부하도 늘어나며 그 크기는 대략 1~10% 정도로 알려져 있다. 따라서 조금이라도 퍼포먼스를 올리고 싶다면 FALSE 상태에 작업하는 것도 보탬이 되겠지만 가능하면 TRUE로 설정하는 것이 좋다. 단, SYSTEM 테이블스페이스에 대한 검사는 항상 예외 없이 수행된다.
DBMS_REPAIR 패키지는 ORA-1578 에러의 천적이라고 할 수 있다. 손상된 데이터 블록을 찾아내서 더 이상 사용하지 않도록 마킹함으로써 상당히 만족스런 수준의 해결 능력을 보여준다.
DBVERFIY는 별도의 실행 파일로 제공되는 유틸리티로 주로 백업이나 리스토어 전에 데이터파일의 손상 여부를 진단할 때 이용된다. 오라클 외부에서 동작하므로 데이터베이스의 운영에 미치는 영향이 가장 적은 편이며 오프라인 상태의 데이터베이스에 대해서 사용한다.
정답 : (d) (<- 마우스로 정답 부분을 선택하세요)
8-3. 테이블에 손상된 블록이 있어도 ORA-1578 에러가 발생하지 않도록 하는 DBMS_REPAIR 패키지의 프로시저는?
a. CHECK_OBJECT
b. FIX_CORRUPT_BLOCKS
c. DUMP_ORPAHN_KEYS
d. REBUILD_FREELISTS
e. SKIP_CORRUPT_BLOCKS
<해설>
DBMS_REPAIR 패키지는 catproc.sql을 실행할 때 함께 만들어지므로 특별한 사유가 없는 한 기본적으로 설치가 되어 있을 것이다. 이 패키지에서 제공하는 여러 프로시저 가운데 FIX_CORRUPT_BLOCKS와 SKIP_CORRUPT_BLOCKS 프로시저의 기능이 혼란을 일으킬 소지가 있다.
FIX_CORRUPT_BLOCKS는 CHECK_OBJECT가 찾아낸 데이터 블록이 손상되었음을 표시하는 것으로 이름에서 전달되는 느낌과는 달리 이 프로시저를 이용해서 손상된 블록에 낙인을 찍어도 계속 그 블록을 액세스 하기 때문에 ORA-1578 에러가 발생한다.
ORA-1578 에러가 나오지 않도록 하려면 FIX_CORRUPT_BLOCKS를 실행한 이후에 다시 SKIP_CORRUPT_BLOCKS 프로시저를 이용해서 해당 블록을 SKIP 하도록 세팅해야 한다.
정답 : (d) (<- 마우스로 정답 부분을 선택하세요)
8-4. LogMiner를 사용할 때 UTL_FILE_DIR 파라미터를 지정하는 이유는?
a. 리두로그 파일을 읽어와야 하므로
b. 딕셔너리 파일을 만들어야 하므로
c. 리두로그 파일의 내용을 저장하기 위해서
d. 임시 저장 공간이 필요하므로
<해설>
LogMiner가 리두로그 파일의 신비를 풀어헤침으로써 이전에는 도저히 불가능했던 일들이 가능해졌다. 가장 고마운 경우를 들자면 원치 않은 작업을 수행하고 커밋까지 했더라도 명령을 무효화시키기 위해서 백업을 리스토어 할 필요 없이 리두로그 파일로부터 작업을 되돌리는 SQL 문을 직접 추출할 수 있다는 것이다.
LogMiner를 사용하기 위한 전초 작업으로는 먼저 딕셔너리 파일을 생성해야 한다. 꼭 필요한 것은 아니지만 딕셔너리 파일을 만들지 않으면 LogMiner가 뽑아낸 SQL 명령에서 객체의 이름이 실제의 이름이 아닌 오라클 내부에서 사용되는 코드로 나오기 때문에 판독하기가 어렵다. 따라서 딕셔너리 파일을 만드는 것이 좋으며 이를 위해서는 UTL_FILE_DIR 파라미터를 딕셔너리 파일을 만들고자 하는 디렉토리로 지정해야 한다.
LogMiner의 기능에는 찬사를 아끼고 싶지 않으나 아직 IOT(Index Organized Table), 클러스터 인덱스와 클러스터 테이블, 체인 로우 등을 비롯한 몇몇 객체와 기능을 지원하지 못하기 때문에 개선의 여지는 남아있다고 하겠다.
정답 : (b) (<- 마우스로 정답 부분을 선택하세요)
RMAN 이란?
9-1. RMAN의 기능에 해당되는 것을 모두 선택하시오(네 가지)
a. 스케줄링(scheduling) 기능
b. 데이터베이스 셧다운
c. 인크리멘탈 백업
d. Oracle7 지원
e. 테이프 디바이스로의 백업
f. 데이터베이스를 압축하여 백업
<해설>
RMAN은 Oracle7 시절의 EBU(Enterprise Backup Utility)를 계승한 것으로(호환은 안됨) 백업과 복구를 위한 전문 유틸리티이다. 새로운 기술을 두려워하지 않는 DBA라면 고전적인 백업과 복구 습관을 버리고 RMAN 매니아가 되어보기를 권장하고 싶다. 그 만큼 매력적인 부분이 있기 때문이다.
RMAN은 파일을 복사하고 옮기는 운영 체제 차원의 작업과 데이터베이스 레벨의 복구 작업을 모두 처리할 수 있으며 백업 파일을 RMAN이 관리하므로 관리자는 신경을 쓰지 않아도 된다. 물론 이런 편리함은 잘 다듬어진 스크립트와 오랜 기간의 숙련을 통해서도 얻을 수 있겠지만 RMAN의 세련된 기능을 따라잡기에는 역부족이다.
RMAN의 다양한 능력 중에서 가장 눈길을 끄는 것은 인크리멘탈 백업이다. 익스포트에서 지원하는 인크리멘탈 백업은 백업의 최소 단위가 테이블이었던 관계로 이름 값을 하지 못했으나 RMAN의 인크리멘탈 백업은 변경된 블록만을 백업할 수 있기 때문에 진정한 의미의 인크리멘탈 백업 능력을 갖추고 있다.
또한 사용되지 않은 데이터 블록을 전부 백업할 필요 없이 일부만 저장하는 일종의 압축(?) 기능도 늘 시간에 쫓기는 관리자에게 큰 도움이 된다. 특히 데이터베이스를 생성한 초기라면 백업의 크기를 획기적으로 줄일 수 있다. 그리고 데이터베이스의 기동과 셧다운도 가능하며 테이프 디바이스와의 연동도 지원된다.
한편 RMAN에는 자체적인 스케줄링 기능은 포함되어 있지 않으며 Oracle 8.0 이상에 한해서 사용할 수 있으므로 Oracle7 과는 호환되지 않는다.
정답 : (b),(c),(e),(f) (<- 마우스로 정답 부분을 선택하세요)
9-2. Recovery Catalog가 없는 경우 RMAN은 백업과 복구에 필요한 정보를 어디에 저장하는가?
a. 레지스트리 또는 환경변수
b. 카타로그 데이터베이스의 SYSTEM 테이블스페이스
c. 타겟 데이터베이스의 SYSTEM 테이블스페이스
d. 카타로그 데이터베이스의 컨트롤 파일
e. 타겟 데이터베이스의 컨트롤파일
<해설>
RMAN은 DBA가 기억해야 할 백업 파일의 이름과 위치, 날짜 등을 스스로 관리하기 때문에 백업과 복구에 관한 정보를 저장하기 위한 공간을 필요로 한다. 그런 목적으로 사용되는 것이 Recovery Catalog이다.
Recovery Catalog는 데이터베이스 내에 테이블 형태로 존재하는데 이를 타겟 데이터베이스(백업을 하고자 하는 데이터베이스) 내에 함께 생성할 수도 있지만 그렇게 하면 타겟 데이터베이스가 깨졌을 때 Recovery Catalog도 사라지므로 Recovery Catalog는 타겟 데이터베이스와는 다른 시스템에 별도의 카타로그 데이터베이스를 만들어서 저장해야 하고 카타로그 데이터베이스의 백업에도 신경을 써야 한다.
그러나 카타로그 데이터베이스를 운영할 만한 여건이 되지 않는다면 필요한 정보를 Recovery Catalog 대신 타겟 데이터베이스의 컨트롤 파일에 기록할 수도 있다. 다만 이 때에는 불가피하게 안전성이 떨어질 수 밖에 없고 RMAN의 기능 일부를 사용하지 못하는 단점을 감수해야 한다.
정답 : (e) (<- 마우스로 정답 부분을 선택하세요)
9-3. 다음 중에서 Recovery Catalog 없이 타겟 데이터베이스에 접속하는 명령은?
a. rman target sys/change_on_install control
b. rman target sys/change_on_install nocatalog
c. rman target sys/change_on_install
d. rman sys/change_on_install
<해설>
오라클의 메시지 한글화 작업에서 종종 버그가 발견되곤 하는데 RMAN에서도 그 흔적을 찾아볼 수 있다. 윈도우용 버전을 오라클 홈페이지에서 다운로드 받아서 설치하고 NLS_LANG의 LANGUAGE 파트를 KOREAN으로 설정한 다음 “rman ?”를 실행해서 도움말을 출력해 보면 한글옵션과 영문옵션이 섞여 있는 재미있는 화면을 볼 수 있다.
RMAN에서 카타로그 데이터베이스에 접속하려면 (c)처럼 “사용자명/패스워드@서비스명”을 기술해야 하고 Recovery Catalog를 사용하지 않는다면 nocatalog 옵션을 지정하면 된다. 한글 도움말 화면만 믿고 “rman 대상 sys/change_on_install nocatalog”과 같이 실행하면 여지없이 에러가 출력될 것이다.
정답 : (b) (<- 마우스로 정답 부분을 선택하세요)
9-4. RMAN에서 카타로그 데이터베이스를 기동하는 방법은?
a. RMAN> startup catalog sys/change_on_install@cat
b. RMAN> startup catalog
c. 타겟 데이터베이스를 기동하면 카타로그 데이터베이스도 함께 기동된다.
d. RMAN에서는 카타로그 데이터베이스를 기동할 수 없다.
<해설>
RMAN으로 타겟 데이터베이스를 기동하거나 셧다운 할 때에는 익히 알고 있는 startup, shutdown 명령을 사용하면 된다. 또한 셧다운 상태에서도 서버 매니저에서 “connect internal”이 가능하듯이 RMAN 역시 타겟 데이터베이스가 셧다운 된 상태에서도 접속할 수 있다.
그러나 RMAN은 카타로그 데이터베이스가 기동되어 있지 않은 상태에서는 카타로그 데이터베이스에는 접속할 수 없으며 카타로그 데이터베이스를 기동하는 기능도 없기 때문에 먼저 서버 매니저 등을 통해서 카타로그 데이터베이스를 띄운 다음에 접속해야 한다.
정답 : (d) (<- 마우스로 정답 부분을 선택하세요)
Recovery Catalog 의 생성과 관리
10-1. 카타로그를 소유할 유저에게 부여할 목적으로 사용되는 롤은? (주관식)
<해설>
“CREATE CATALOG TABLESPACE 테이블스페이스명”명령을 실행하면 카타로그가 생성되는데 이 때 카타로그가 생성되는 유저에게는 RECOVERY_CATALOG_OWNER 롤을 부여하도록 되어 있다. 한 가지 독특한 점은 데이터베이스를 만든 후에 반드시 실행하는 catalog.sql 스크립트에서 다른 스크립트를 부르지 않고 직접 생성하는 롤이 꼭 하나가 있는데 그 것이 바로 RECOVERY_CATALOG_OWNER이다.
정답 : RECOVERY_CATALOG_OWNER (<- 마우스로 정답 부분을 선택하세요)
10-2. 가장 최신의 백업을 제외한 나머지를 확인해서 모두 삭제하고 싶다면 어떤 명령으로 알아낼 수 있는가?
a. RMAN> list obsolete redundancy 0;
b. RMAN> report obsolete redundancy 0;
c. RMAN> report obsolete redundancy 1;
d. RMAN> report obsolete redundancy 2;
<해설>
RMAN의 편리성이 돋보이는 문제다. RMAN이 없다면 백업 날짜별로 디렉토리를 만드는 등의 수고를 해야 하지만 RMAN을 이용하면 알아서 처리해 주므로 일단 명령어에만 익숙해진 다음에는 오퍼레이터 한명을 비서로 둔 듯한 기분이 들 것이다.
백업을 주기적으로 받다 보면 날짜 순으로 다량의 백업이 쌓이게 되는데 간혹 최신의 것이 아니라 예전의 백업이 필요할 때도 있지만 어느 정도 시간이 흐른 후에는 더 이상 필요 없다고 판단되는 백업을 삭제하여 디스크 공간을 확보하는 것이 일반적이다.
“report obsolete redundancy” 명령 다음에 오는 숫자는 몇 개의 최신 백업을 남겨둘 것인가를 결정하는 파라미터로 1 이상의 값을 지정해야 한다. redundancy가 1이라는 것은 최신 백업 하나만 허용하겠다는 의미이므로 가장 최근의 백업을 제외한 나머지가 모두 이 명령에 걸리게 된다.
정답 : (a) (<- 마우스로 정답 부분을 선택하세요
10-3. 카타로그에 저장된 full_backup 이라는 스크립트를 실행하는 명령으로 옳은 것은?
a. RMAN> run { execute script full_backup; }
b. RMAN> run { execute full_backup; }
c. RMAN> execute script full_backup;
d. RMAN> @full_backup
e. RMAN> start full_backup
<해설>
RMAN에서 사용되는 스크립트는 나중에 다시 실행하기 위해서 카타로그에 저장될 수 있다. 카타로그에 들어있는 스크립트를 실행하려면 (a)와 같이 “execute script” 명령을 사용하면 된다. (d)의 @ 기호는 카타로그가 아니라 파일 형태의 스크립트를 실행할 때 이용된다.
마치 스토어드 프로시저가 데이터베이스에 저장되는 것과 비슷한데 스크립트의 이름은 RC_STORED_SCRIPT에서 볼 수 있고 스크립트의 소스는 RC_STORED_SCRIPT_LINE을 통해서 직접 확인할 수 있다.
정답 : (a) (<- 마우스로 정답 부분을 선택하세요)
RMAN 을 이용한 백업
11-1. 다음 명령으로 5 개의 데이터파일로 이루어진 users 테이블스페이스를 백업한다면 몇 개의 백업 셋이 생성되는가?
run {
allocate channel c1 type disk;
allocate channel c2 type disk;
backup tablespace users;
}
a. 1개
b. 2개
c. 3개
d. 4개
e. 5개
<해설>
RMAN으로 백업할 때에는 지정한 파일의 포맷을 바꾸지 않고 그대로 복사하는 이미지 카피와 RMAN 고유의 형식으로 변환하여 저장하는 백업 셋 중에서 선택할 수 있다.
RMAN의 장점을 십분 활용하기 위해서는 백업 셋을 이용하는 것이 좋은데 백업 셋을 만들고 리스토어 할 때에는 RMAN 포맷으로 변환하는 단계에서 약간의 오버헤드 발생하는 단점이 있다.
backup 명령을 실행하면 하나 이상의 백업 셋(backup set)이라는 것을 형성하게 된다. 백업 셋은 RMAN에서 사용하는 논리적인 개념이고 실제로 디스크 상에는 하나 이상의(보통은 하나로 구성됨) 백업 피스로 불리는 파일로 이루어진다. 백업 피스에는 여러 개의 데이터파일이 들어갈 수 있다.
이 문제의 열쇠는 filesperset 파라미터가 쥐고 있다. filesperset은 하나의 백업 셋에 몇 개의 데이터파일을 넣을 수 있는가를 지정하는 것인데 본 문제에서는 특별히 명시하지 않았기 때문에 (백업하는 파일 수 / 채널 수)의 결과를 반올림한 값과 64 중에서 작은 값으로 결정된다. 이 공식을 적용하면 5개의 파일을 2개의 채널을 통해서 백업하므로 5 / 2 = 2.5 이고 반올림하면 3이 된다. 따라서 이 값이 64보다 작으므로 filesperset은 3임을 알 수 있다.
하나의 백업 셋에 최대 3개의 파일이 들어갈 수 있으므로 5개의 데이터파일을 백업한다면 총 2개의 백업 셋이 필요하다. 백업 후에 몇 개의 백업 셋이 만들어졌는지는 “list backup” 명령으로 확인하면 된다.
정답 : (b) (<- 마우스로 정답 부분을 선택하세요)
11-2. 다음 명령의 의미를 제대로 설명한 것은?
set limit channel ch1 kbytes = 50000;
a. 채널 ch1을 통해서 전송되는 데이터의 크기를 50M로 제한한다
b. 백업할 수 있는 데이터파일의 최대 크기를 50M로 제한한다
c. 백업 셋의 최대 크기를 50M로 설정한다
d. 백업 피스의 최대 크기를 50M로 설정한다
<해설>
이 명령은 백업 피스의 최대 크기를 제한할 때 사용되는 것이다. 백업 피스는 물리적인 파일로서 크기가 너무 커서 다루기가 곤란하다면 이 명령으로 백업 피스의 최대 크기를 지정할 수 있다. 통상 하나의 백업 셋은 하나의 백업 피스로 이루어지지만 이 명령을 이용하면 여러 개의 백업 피스로 나눌 수 있다.
정답 : (d) (<- 마우스로 정답 부분을 선택하세요)
11-3. NOARCHIVELOG 모드에서 RMAN으로 오프라인 백업을 수행할 때 데이터베이스는 어떤 상태이어야 하는가?
a. CLOSE
b. NOMOUNT
c. MOUNT
d. OPEN
<해설>
NOARCHIVELOG 모드에서는 아무리 RMAN의 기능이 강력하다고 하더라도 데이터베이스가 오픈된 상태에서 백업을 수행할 수 없다는 원칙에는 변함이 없다.
RMAN의 독특한 점은 오프라인 백업을 데이터베이스가 CLOSE 상태가 아니라 MOUNT 단계에서 수행한다는 점이다. 물론 이 때에도 카타로그 데이터베이스는 오픈되어 있어야 한다.
정답 : (c) (<- 마우스로 정답 부분을 선택하세요)
11-4. 보기의 순서대로 백업을 하였다면 2001/01/29에 수행한 명령은 어느 시점 이후부터의 변경사항을 백업하는가?
2001/01/01 backup incremental level 0 database;
2001/01/08 backup incremental level 2 database;
2001/01/15 backup incremental level 2 cumulative database;
2001/01/22 backup incremental level 2 database;
2001/01/29 backup incremental level 2 cumulative database;
a. 2001/01/01
b. 2001/01/08
c. 2001/01/15
d. 2001/01/22
e. 아무것도 백업하지 않음
<해설>
인크리멘탈 백업에는 differential과 cumulative 두 가지 모드가 있으며 백업 레벨도 함께 지정해야 한다. 레벨 0은 전체 데이터베이스를 백업하는 것으로 앞으로 수행하는 인크리멘탈 백업의 초석을 형성하므로 인크리멘탈 백업을 하기로 마음먹었다면 먼저 레벨 0 백업을 수행해 주어야 한다.
differential 모드에서는 자신과 레벨이 갖거나 낮은 백업 이후의 변경된 내용을 백업하는데 반해서 cumulative 모드는 자신보다 레벨이 낮은 백업 이후의 변경된 내용을 백업한다. 따라서 cumulative 모드에서는 이전에 수행했던 동일 레벨의 백업 내용을 포괄하게 된다.
인크리멘탈 백업에서 특별히 cumulative 라고 지정하지 않는다면 디폴트로 differential 모드가 적용된다.
2001/01/29에 수행한 명령이 cumulative 모드이고 레벨 2 이므로 가장 최근에 수행한 레벨 1 이하의 백업을 찾아야 한다. 시간을 거슬러 올라가 보면 2001/01/01의 레벨 0 백업 이후의 내용을 모두 백업 받게 됨을 알 수 있다.
정답 : (a) (<- 마우스로 정답 부분을 선택하세요)
RMAN 을 이용한 리스토어와 복구
12-1. ARCHIVELOG 모드로 운영중인 데이터베이스에서 다음 명령을 실행할 때 에러가 발생하는 이유로 적절한 것은? 현재 데이터베이스는 오픈된 상태이다.
run {
allocate channel diskch1 type disk;
restore tablespace tools;
recover tablespace tools;
}
a. restore 명령 전에 tools 테이블스페이스를 offline 시키지 않았다
b. recover 명령 후에 tools 테이블스페이스를 online 시키지 않았다
c. diskch1 채널을 사용 후에 release 하지 않았다
d. 데이터베이스를 NOARCHIVELOG 모드로 전환한 다음에 작업해야 한다
<해설>
tools 테이블스페이스를 리스토어 하기에 앞서 offline 시키지 않았기 때문이다. 데이터베이스가 오픈된 상태에서 백업 셋을 만들 때에는 RMAN에서 나름대로의 방법으로 처리를 해 주므로 해당 테이블스페이스를 백업 모드로 전환시키는 명령이 스크립트에 포함되지 않는다.
하지만 리스토어와 복구를 할 때에는 해당 테이블스페이스를 먼저 offline 시키고 나서 작업을 해야 하며 안 그러면 restore 명령에서 에러가 발생한다.
일반적으로 recover 명령 다음에 tools 테이블스페이스를 online 시켜는 SQL문이 없는 경우는 드물지만 빠뜨린다고 해서 에러가 발생하지는 않는다. 물론 online 시키기 전에는 tools 테이블스페이스를 이용할 수 없다.
run 명령이 끝나면 자동으로 사용한 채널을 반납하므로 채널을 allocate 한 후에 release 명령을 기술하는 것은 좋은 습관이긴 하나 의무사항은 아니다.
정답 : (a) (<- 마우스로 정답 부분을 선택하세요)
12-2. RMAN의 switch와 대응되는 SQL 명령은?
a. ALTER SYSTEM SWITCH LOGFILE;
b. ALTER DATABASE SWITCH LOGFILE;
c. ALTER DATABASE RENAME DATAFILE;
d. ARCHIVE LOG NEXT;
<해설>
이미지 카피를 받은 다음에 어떠한 이유로든 백업한 파일을 원래의 데이터파일이 있는 위치로 리스토어할 수 없다고 생각해 보자. 그 때에는 이미지 카피를 다른 디렉토리로 리스토어 하거나 그대로 데이터파일처럼 사용할 수 있는데 switch 명령으로 데이터 파일의 위치가 변경되었음을 알려주면 된다. ALTER DATABASE RENAME DATAFILE 명령과 마찬가지 역할을 한다고 볼 수 있다.
정답 : (c) (<- 마우스로 정답 부분을 선택하세요)
12-3. 특정한 시간으로 데이터베이스를 되돌리려고 한다. 다음 스크립트에서 어느 곳에 set until time 옵션을 삽입해야 하는가?
run {
allocate channel diskch1 type disk;
restore database;
recover database;
sql ‘alter database open resetlogs’;
}
a. restore 명령 이전
b. restore와 recover 명령 사이
c. recover와 sql 명령 사이
d. 위치는 상관 없음
<해설>
불완전 복구를 수행할 때 set until time 옵션은 restore보다 먼저 설정해야 한다. restore 명령 이후에 설정하면 set until time으로 지정한 시간 이후의 상태에 해당되는 백업이 리스토어가 될 수도 있으며 그러면 롤 포워드가 불가능하기 때문이다.
정답 : (b) (<- 마우스로 정답 부분을 선택하세요)
스탠바이 데이터베이스 (Standby Database)
13-1. 스탠바이 데이터베이스의 DB_NAME 파라미터는 어떻게 설정해야 하는가?
a. STANDBY
b. 프라이머리 데이터베이스의 DB_NAME과 동일하게
c. 프라이머리 데이터베이스의 DB_NAME과 다르게
d. 아무 값이나 상관 없음
<해설>
스탠바이 데이터베이스는 야구로 말하자면 구원 투수에 견줄 수 있다. 구원 투수가 불펜에서 몸을 풀면서 대기하고 있다가 선발 투수가 난조를 보이면 즉시 투입되는 것처럼 스탠바이 데이터베이스도 항상 스스로를 최신 상태로 유지하면서 기다리다가 프라이머리 데이터베이스에 문제가 발생하면 짧은 시간 안에 그 역할을 대신할 수 있는 준비된 데이터베이스이다.
스탠바이 데이터베이스는 일단 프라이머리 데이터베이스의 백업을 이용하여 똑같이 만든 다음에 끊임없이 변경 내용을 반영하고 있다가 프라이머리 데이터베이스에 이상이 발생하면 바로 오픈하여 사용하는 장애 대처 방법이다.
프라이머리 데이터베이스의 변경 사항을 반영하는 방법으로는 아카이브로그 파일을 이용한다. 스탠바이 데이터베이스는 마운트 상태에서 프라이머리 데이터베이스로부터 새로운 아카이브로그 파일이 생성되어 전달되는 것을 기다렸다가 자신에게 그 아카이브로그 파일을 적용함으로써 프라이머리 데이터베이스와 거의 차이가 없는 상태를 유지하는 것이다.
그러나 스탠바이 데이터베이스는 항상 복구 상태에 머물러 있기 때문에 사용자들이 그 곳에 들어 있는 데이터를 이용할 수 없다는 약점이 있다. 만약 프라이머리 데이터베이스에 아무런 문제도 발생하지 않는다면 스태바이 데이터베이스를 구축하기 위해서 투입한 비용을 고스란히 썩히고 있는 셈이 된다.
이를 조금이나마 극복하기 위해서 스탠바이 데이터베이스를 읽기 전용 모드로 전환해서 쿼리 작업의 일부를 처리하도록 함으로써 프라이머리 데이터베이스의 부하를 덜어주는 방법을 사용하기도 한다. 그러나 이렇게 사용자들을 위해서 서비스 하는 동안에는 아카이브로그 파일을 이용한 복구가 진행되지 않기 때문에 나중에 진짜로 프라이머리 데이터베이스의 역할을 대신하여야 할 때 밀려있던 아카이브로그 파일을 모두 적용해야 하므로 신속한 대처가 어렵다는 문제가 있다.
스탠바이 데이터베이스를 사용할 때에 유의해야 할 초기화 파라미터가 몇 가지가 있는데 그 중에서 DB_NAME 파라미터는 프라이머리 데이터베이스의 DB_NAME과 같도록 설정해야 한다. 스탠바이 데이터베이스의 컨트롤 파일은 프라이머리 데이터베이스로부터 생성하여 가져온 것인데 이 컨트롤 파일에는 프라이머리 데이터베이스의 이름이 등록되어 있기 때문이다.
정답 : (b) (<- 마우스로 정답 부분을 선택하세요)
13-2. 스탠바이 데이터베이스로서의 역할을 중단하고 프라이머리 데이터베이스의 기능을 수행하도록 하는 명령은?
a. ALTER DATABASE OPEN;
b. ALTER DATABASE OPEN READ ONLY;
c. ALTER DATABASE ACTIVATE STANDBY DATABASE;
d. RECOVER STANDBY DATABASE;
<해설>
스탠바이 데이터베이스는 프라이머리 데이터베이스와 동일한 시스템에 만들 수도 있고 다른 시스템에 생성할 수도 있는데 당연히 서로 다른 시스템에 구축하는 것이 훨씬 안전하다.
스탠바이 데이터베이스로 프라이머리 데이터베이스를 대체하는 것을 활성화(ACTIVATE) 시킨다고 말한다. (c) 명령을 실행하면 스탠바이 데이터베이스는 더 이상 스탠바이 데이터베이스가 아니라 완전히 프라이머리 데이터베이스로서 동작하게 된다. 또한 일단 이 명령을 실행한 다음에는 스탠바이 데이터베이스의 속성을 상실하게 되므로 다시 스탠바이 데이터베이스로 돌아갈 수 없다는 의미도 가지고 있다.
보통은 이렇게 되면 서로의 역할을 완전히 바꿔서 기존의 프라이머리 데이터베이스를 스탠바이 데이터베이스로 셋업해서 사용하는 경우가 많다. 즉, 두 장비를 서로 번갈아 가면서 스탠바이와 프라이머리 데이터베이스로 이용하는 것이다. 그런데 두 데이터베이스가 설치되어 있는 하드웨어의 성능 차이가 미미하다면 이렇게 사용하는 것이 별 무리가 없겠지만 스탠바이 데이터베이스를 낮은 사양의 하드웨어에 설치했다면 스페어 타이어를 끼고는 오래 달릴 수 없으므로 빨리 기존의 데이터베이스를 복구해야 할 것이다.
정답 : (c) (<- 마우스로 정답 부분을 선택하세요)
13-3. 스탠바이 데이터베이스의 세 가지 모드에 해당되지 않는 것은?
a. Manual Recovery Mode
b. Managed Recovery Mode
c. Read Only Mode
d. Read Write Mode
<해설>
Manual Recovery Mode에서는 프라이머리 데이터베이스로부터 아카이브로그 파일을 가져오는 작업과 이를 이용하여 스탠바이 데이터베이스를 지속적으로 복구하는 과정을 관리자가 직접 조작해야 한다. 따라서 손이 많이 가기 때문에 Managed Recovery Mode로 운영할 수 없는 특별한 상황에서만 주로 이용된다.
Managed Recovery Mode는 프라이머리 데이터베이스에서 아카이브로그 파일을 가져와서 복구하는 과정이 모두 자동으로 이루어지므로 가장 많이 이용되는 방법이다. 이 모드를 사용할 때에는 Net8을 통해서 아카이브로그 파일을 공급 받는다.
Read Only Mode는 프라이머리 데이터베이스의 부하를 덜고 유휴 장비의 효율을 높이기 위해서 스탠바이 데이터베이스를 쿼리 전용으로 사용하는 방법이다. 그러나 이 상태에서는 프라이머리 데이터베이스로부터 가져온 아카이브로그 파일을 이용한 복구가 잠정적으로 중단되므로 나중에 실제로 스탠바이 데이터베이스가 프라이머리 데이터베이스를 대체하여야 할 때에는 그 동안 쌓인 아카이브로그 파일을 모두 적용해야 하므로 시간이 많이 걸리는 단점이 있다.
정답 : (d) (<- 마우스로 정답 부분을 선택하세요)
13-4. 하나의 프라이머리 데이터베이스에 대해서 Managed Recovery Mode로 운영되는 스탠바이 데이터베이스를 최대 몇 개 까지 생성하여 운영할 수 있는가?
a. 1개
b. 2개
c. 3개
d. 4개
e. 5개
<해설>
Manual Recovery Mode에서는 아카이브로그 파일을 스탠바이 데이터베이스가 있는 장비로 옮기는 작업을 관리자가 직접 수행하기 때문에 프라이머리 데이터베이스 입장에서는 몇 개의 스탠바이 데이터베이스를 사용하든 알 필요가 없다. 따라서 하나의 프라이머리 데이터베이스에 대해서 원하는 만큼의 스탠바이 데이터베이스를 만들어서 사용할 수 있다.
반면 Managed Recovery Mode로 운영할 수 있는 스탠바이 데이터베이스의 개수는 하나의 프라이머리에 데이터베이스에 대해서 최대 4 개 까지 가능하다는 제약이 있다. 그 이유는 초기화 파라미터를 보면 알 수 있다.
아카이브로그 파일이 생성되는 위치를 지정하는 파라미터는 LOG_ARCHIVE_DEST_n 인데 n은 1부터 5까지 가능하므로 총 5 곳을 지정할 수 있다. 그런데 적어도 하나는 로컬 디렉토리를 지정해야 하므로 스탠바이 데이터베이스를 위해서는 나머지 4 개의 파라미터만 사용할 수 있기 때문이다.
필요하다면 4 개의 스탠바이 데이터베이스를 Managed Recovery Mode로 운영하면서 추가적으로 Manual Recovery Mode로 더 많은 스탠바이 데이터베이스를 사용할 수도 있다.
정답 : (d) (<- 마우스로 정답 부분을 선택하세요)
|
