공략 포인트
앞의 두 과목을 무사히 통과했다면 이제 기본은 완성되었으므로 약간 긴장을 늦추고 공부 해도 좋다. 네트워크 과목은 좀 다르지만 백업과 복구, 퍼포먼스 튜닝은 기존의 지식을 바탕으로 풀어가는 것이므로 수험자의 체감 부담이 적다.
DBA의 가장 중요한 업무에 대해서 설문 조사를 한다면 십 중 팔구 백업이 일순위로 꼽힐 것이다. DBA의 책임 영역은 데이터를 안전하게 보호하고 데이터를 필요로 하는 사람에게 원활한 공급이 이루어 지도록 하는 것이다. 따라서 데이터를 손실 위험으로부터 지키기 위하여 백업을 받고 매끄러운 공급을 위해서 크고 작은 관리작업과 튜닝을 수행한다.
백업을 제외한 다른 업무는 제대로 수행하지 못했더라도 얼마든지 만회할 기회가 있다. 데이터베이스의 구조가 잘못 되었다면 추석 연휴를 반납하고라도 뜯어 고치면 되고 기대 이하의 성능에는 다소의 예산을 투입해서 튜닝 진단을 받으면 된다. 또한 디스크가 엉망으로 얽혀버렸는데 복구에 익숙치 않다면 오라클에서 지원을 받을 수도 있다. 데이터베이스가 다운된 후 복구 되기 까지 걸리는 평균 시간(Mean Time To Recovery)이 DBA의 평가 요소에서 큰 부분을 차지하므로 이렇게 자꾸 외부의 힘을 빌리는 것은 곤란하지만 자신의 능력을 넘어서는 일에 대해서는 지체 없이 도움을 받는 것이 현명한 선택일 것이다.
그러나 백업은 절대적으로 DBA의 몫이다. 백업 플랜을 작성하고 계획한 절차대로 수행하는 것은 어려운 일이 아니지만 여기서 실수가 발생하면 DBA로서의 자질과 성실성에 큰 손상을 입는다. 또한 백업이 잘못되면 장애 발생시 입게 되는 시간적 금전적 피해 규모는 비교할 상대가 없다.
백업은 생명보험과도 같다. 백업을 위해서 들이는 시간과 비싼 저장 장치가 아깝게 느껴지겠지만 만약의 사태가 발생했을 때 믿을 것은 백업밖에 없는 것이다. 백업만 제대로 받아 두면 복구는 시간문제지만 제대로 된 백업이 없을 때에는 별의 별 편법을 동원하여 복구를 해야 할 경우도 생기고 그나마 복구를 하더라도 데이터베이스는 만신창이가 되기도 한다.
본 과목은 오라클 아키텍쳐를 충실히 이해하고 있다면 별 어려움을 느끼지 않을 것이다. 다만 지금까지 쌓아온 지식을 보강하고 RMAN 유틸리티의 사용법을 익히는 것으로 훌륭한 준비가 될 것으로 믿는다. 문제 분포를 보면 개별 단원으로는 물리적 백업에 관한 문제가 8문제로 가장 많지만 RMAN과 관련된 부분에서 그보다 두 배 이상이 출제되므로 합격을 결정 짓는 다크호스다. 강좌 초반에 다루는 개념적인 부분과 아카이브에 대한 기본적인 이해도를 묻는 문제도 그에 못지않은 비중을 차지한다. 그리고 가장 마지막에 다룰 스탠바이 데이터베이스에서도 5문제가 나오므로 끝가지 최선을 다해주기 바란다.
데이터 복구를 위한 오라클 구조
1-1. 데이터베이스를 사용하던 중 실수로 전원 스위치를 내려버렸다. 이와 같은 경우는 어떤 유형의 장애에 해당되는가?
a. User Error
b. Statement Error
c. Process Failure
d. Instance Failure
e. Media Failure
<해설>
모든 학문의 시작은 사물과 현상을 분류하는 것에서 비롯되듯이 데이터베이스와 관련된 장애도 성격에 따라서 보기와 같은 다섯 가지로 구분 지을 수 있다.
User Error는 유저가 실수로 데이터를 삭제한 것과 같은 경우를 말하는데 이 때에는 백업을 이용해서 원상태로 복구를 시켜주면 되고 만약 백업 받은 것이 없다면 복구를 할 수 없다는 간단한 논리의 적용이 가능하므로 문제 파악이 쉽다.
Statement Error는 SQL문을 잘못 작성하였거나 미들웨어와 오라클간의 호환성 결여 로 인한 문제 등을 가리킨다. 예를 들어 TP 모니터와 오라클의 버전이 맞지 않아서 발생하는 까다롭고 미묘한 문제들을 떠올려 볼 수 있다.
Process Failure는 유저 프로세스가 비정상적으로 종료된 경우로 유저가 고의로 직접 중단시켰거나 또는 네트워크 회선의 불량으로 접속이 단절된 경우 등이 해당된다.
Instance Failure는 정전이나 오라클 백그라운드 프로세스의 정지 등으로 오라클 인스턴스가 다운되는 것을 말하며 본 문제가 여기에 속한다. Instance Failure가 발생하면 다음에 인스턴스를 기동할 때 오라클이 자동으로 복구를 수행하기 때문에 DBA가 직접 관여할 문제는 아니다.
Media Failure는 데이터파일과 같이 오라클 데이터베이스를 구성하고 있는 파일이 삭제되거나 손상된 경우를 말하며 심각한 복구 문제는 모두 이 카테고리에서 발생하므로 앞으로 우리가 중점적으로 다룰 분야이다.
정답 : (d) (<- 마우스로 정답 부분을 선택하세요)
1-2. 유저가 실수로 중요한 테이블을 삭제하였다. 다행히 아카이브 모드로 운영중이었는데 어떤 복구 방법을 선택해야 삭제된 테이블을 되살릴 수 있는가?
a. Complete Recovery
b. Incomplete Recovery
<해설>
완전 복구(Complete Recovery)는 보관중인 백업을 리스토어 한 다음에 백업 이후에 생성된 모든 리두 로그 파일을 적용하는 복구 방법을 말한다. 모든 리두 로그 파일의 정보를 사용하므로 가장 최신의 상태로 복구가 되지만 본 문제에서는 완전 복구를 수행하면 다시 테이블이 삭제된 상태가 되어버리므로 복구하는 의미가 없다.
이런 때에는 데이터베이스를 테이블이 삭제 되기 이전의 시점으로 돌려 놓아야 하므로 백업 받은 이후에 생성된 모든 리두 로그 파일을 적용해선 안 되고 복구를 하던 중간에 작업을 중단하고 데이터베이스를 오픈 시켜야 하는데 이를 일컬어 불완전 복구(Incomplete Recovery)라고 부른다.
백업 계획을 수립한 다음에는 반드시 백업 받은 것을 이용해서 복구가 제대로 되는지 테스트 해 보아야 한다.
오래 전에 운영 체제를 업그레이드하는 사이트로부터 백업을 어떻게 받아야 하는지를 문의 받은 적이 있었다. 필자는 관리자의 시간을 벌어준답시고 익스포트와 임포트 보다는 간편한 콜드 백업을 받으라고 조언해 주었다.
그런데 결국 다음날 일이 터지고 말았다. 운영 체제를 업그레이드 하는 것은 맞기는 한데 단순한 버전 업이 아니라 SunOS에서 Solaris로 전환하는 것이었기 때문에 두 운영 체제 사이의 이진 호환성이 없는 관계로 콜드 백업이 무용지물이 되고 만 것이다. 운영 체제가 다르더라도 익스포트 받은 덤프 파일은 임포트 유틸리티에서 읽을 수 있지만 데이터 파일은 플랫폼간의 호환성이 없기 때문이다.
결국 SunOS 재설치 -> 오라클 인스톨 -> 백업 리스토어 -> 익스포트 -> Solaris 재설치 -> 오라클 인스톨 -> 임포트와 같은 과정을 거쳐서 겨우 업그레이드 작업을 마칠 수 있었다. 아무리 완벽하게 백업을 받았더라도 예상치 못한 변수가 터지지 않는다고 보장할 수 없으므로 반드시 실전테스트를 거쳐서 검증해 보아야 한다.
정답 : (b) (<- 마우스로 정답 부분을 선택하세요)
1-3. 불완전 복구의 유형에 해당되는 것을 모두 선택하시오(정답은 세 가지).
a. Point-based recovery
b. Time-based recovery
c. Change-based recovery
d. Transaction-based recovery
e. Cancel-based recovery
<해설>
불완전 복구(Incomplete Recovery)는 완전 복구와는 달리 복구하는 중간에 작업을 중단해야 하며 그 시점에 대한 결정은 DBA의 몫이다.
Time-based recovery는 데이터베이스를 특정한 시점까지만 복구하는 방법을 말한다. 2번 문제에서처럼 사용자가 테이블을 삭제한 시간을 알고 있다면 테이블이 삭제되기 직전의 시간을 지정하여 복구를 수행하면 되므로 자주 이용되는 방법이다.
Change-based recovery는 SCN을 직접 사용해서 복구를 하는 방법이고 Cancel-based recovery는 로그 파일을 하나씩 적용하면서 복구를 진행해 가다가 원하는 위치에서 CANCEL 명령으로 복구를 중단하고 오픈하는 방법을 말한다. 자세한 내용은 차차 다루기로 하겠다.
정답 : (b),(c),(e) (<- 마우스로 정답 부분을 선택하세요)
Archive vs. Noarchive
2-1. 수동 아카이빙(Manual Archiving) 상태에서 데이터베이스를 셧다운하지 않고 아카이브를 받을 수 있는 명령은? (정답은 세 가지)
a. ARCHIVE LOG NEXT;
b. ARCHIVE LOG NEW;
c. ALTER SYSTEM ARCHIVE LOG START;
d. ALTER SYSTEM ARCHIVE LOG ALL;
e. ALTER SYSTEM SWITCH LOGFILE;
<해설>
아키이브로그 모드란 온라인 리두 로그 파일이 순환되어 재사용되기 전에 다른 곳으로 백업해 둠으로써 차후에 복구에 사용할 수 있도록 하는 데이터베이스 운영 방식을 말한다. 시스템 환경이 별로 넉넉하지 못했던 시절에는 아카이브로그 모드가 유발하는 프로세서의 부하와 디스크 I/O의 증가 및 여유 공간의 부족, 그리고 관리자의 미숙 등으로 인해서 다양한 장점에도 불구하고 그다지 좋지 않은 인상을 남겨주는 경우가 있었다.
24시간 운영을 하는 곳에서는 백업을 받기 위해서 아카이브로그 모드가 필수적인데 디스크가 넉넉하지 않아서 궁여지책으로 테이프로 직접 아카이브를 받는 곳도 있었다. 그러다 보니 트랜잭션이 몰리는 시간에는 아카이브 받는 속도가 발생되는 트랜잭션의 크기를 따라가지 못해서 데이터베이스가 때때로 멈칫거리는 부작용이 발생하기도 하였다.
현재는 컴퓨터 시스템의 중요성에 대한 마인드가 많이 개선되었고 하드웨어의 성능 향상과 가격 인하로 소규모 데이터베이스라고 해도 아카이브로그 모드로 운영하지 않을만한 뚜렷한 이유를 찾기 어렵다.
아카이브로그 모드로 처음 운영하기 시작하는 사이트에서 가장 자주 일어나는 실수 가운데 하나는 어떤 이유로든 아카이브가 제대로 수행되지 않음으로써 데이터베이스가 모든 동작을 멈추는 것이다. 구체적인 원인으로는 아카이브로그 파일이 저장되는 디스크에 여유 공간이 부족하거나 아카이브 프로세서를 띄워서 자동으로 아카이브가 수행되도록 설정하는 단계를 건너 뛴 것이 대표적이다.
수동으로 아카이브를 시키는 명령은 여러 가지가 있는데 보기 중에서는 (a), (d)가 있으며 (c) 명령을 실행시키면 아카이브 프로세스가 기동되어 자동 아카이브 모드로 운영된다. 단, 인스턴스를 셧다운 하면 그 효력은 상실되므로 계속 자동 아카이브 모드를 유지하려면 파라미터 파일에 LOG_ARCHIVE_START=TRUE 라고 추가해야 한다.
정답 : (a), (c), (d) (<- 마우스로 정답 부분을 선택하세요)
2-2. 아카이브로그 파일의 멀티플렉싱과 아카이브 프로세스는 각각 최대 몇 개 까지 가능한가?
a. 2, 2
b. 3, 5
c. 5, 3
d. 5, 5
e. 5, 10
<해설>
“아카이브로그 파일을 굳이 멀티플렉싱할 필요가 있을까?” 하는 의문을 던지는 분들도 있을 것이다. 아카이브로그 모드로 운영하다 보면 생성되는 파일의 개수가 굉장히 많기 때문에 조금의 부주의로 한 두개의 아카이브로그 파일이 없어지는 경우가 심심찮게 발생한다.. 아카이브로그 파일의 특성상 모든 파일을 철저하게 보관하고 있더라도 중간 시점에 생성된 하나만 잃어버리면 그 이후의 아카이브로그 파일은 쓸모가 없기 때문에 전체를 완전하게 보존해야 한다. 그래서 디스크의 가격이 별 문제가 되지 않는 요즘에는 아카이브로그 파일의 멀티플렉싱이 매우 설득력 있는 장애 대비 방법의 하나라고 말할 수 있다.
오라클 8.0 버전에서는 아카이브로그 파일의 멀티플렉싱이 두 곳으로만 가능했지만 오라클 8i부터는 최대 다섯 개로 확장되었다. 즉, 이전의 방법은 LOG_ARCHIVE_DEST와 LOG_ARCHIVE_DUPLEX_DEST 파라미터를 사용하여 두 개의 디렉토리를 지정하는 것이었는데 지금은 LOG_ARCHIVE_DEST_1, LOG_ARCHIVE_DEST_2, …, LOG_ARCHIVE_DEST_5와 같은 다섯 개의 파라미터를 이용하여 아카이브로그 파일을 저장하는 디렉토리를 지정할 수 있다. 오라클 8i 에서는 이 두 가지 방법을 모두 사용할 수 있지만 서로 배타적이므로 어느 하나만을 선택해서 이용해야 한다.
이렇게 아카이브로그 파일을 여러 곳에 생성하다 보니 자연히 하나의 ARCn 프로세스만으로는 작업을 감당하기 벅차기 때문에 필요에 따라서 최대 10개의 ARCn 프로세스가 떠서 작업을 할 수 있다. 단, 실제로 사용되는 ARCn 프로세스의 개수는 오라클에서 자동으로 결정하며 LOG_ARCHIVE_MAX_PROCESSES 파라미터는 단지 인스턴스 기동시에 뜨는 ARCn 프로세스의 개수를 의미할 뿐이다.
정답 : (e) (<- 마우스로 정답 부분을 선택하세요)
물리적 백업
3-1. 데이터파일이 백업 모드 상태인지를 확인할 수 있는 딕셔너리는? (두 가지)
a. V$DATAFILE
b. V$DBFILE
c. V$DATAFILE_HEADER
d. V$BACKUP
e. V$DATABASE
<해설>
백업 모드란 해당 데이터파일이 핫 백업을 받는 상태에 놓여있다는 것을 말한다.
ALTER TABLESPACE 테이블스페이스명 BEGIN BACKUP;
명령으로 특정 테이블스페이스를 백업하겠다고 지정하면 그 테이블스페이스를 구성하고 있는 모든 데이터파일이 백업 모드로 변경된다.
백업 모드에서는 데이터파일의 헤더에 기록되는 SCN은 갱신되지 않지만 해당 테이블스페이스에 대한 SELECT, INSERT 등의 작업이 모두 가능하므로 사용자는 백업 모드라는 것을 의식하지 않고 그대로 사용할 수 있다.
그러나 백업 모드에서는 리두로그 파일에 추가적인 정보가 기록되므로 사용자가 적은 시간대를 선택해서 작업을 해야 퍼포먼스 저하를 방지할 수 있다.
데이터가 변경되거나 추가될 때 백업 모드 상태의 데이터파일에는 직접 기록되지 않고 리두로그 파일에만 저장되었다가 나중에 백업 모드에서 빠져나오면 리두로그 파일의 정보를 데이터파일에 반영하는 것으로 오해할 소지도 있다. 그러나 실제로는 평상시와 마찬가지로 백업 모드에서도 데이터파일에 변경 사항이 기록되며 단지 헤더에 저장되는 SCN이 갱신되지 않는 것이다.
데이터파일이 백업 모드인지를 확인할 때에는 보통 V$BACKUP을 이용한다. V$BACKUP의 STATUS 컬럼의 값이 ACTIVE 라면 해당 데이터파일이 백업 모드임을 의미한다.
또한 V$DATAFILE_HEADER의 FUZZY 컬럼의 값이 YES일 때에도 백업 모드라고 판단할 수 있다.
여러 개의 테이블스페이스를 한 번에 백업 모드로 전환시켜서 작업하면 어떤 테이블스페이스가 백업 모드 상태인지 혼란스럽고 리두로그 데이터의 생성이 과도하게 늘어날 뿐 아니라 미처 백업 모드를 종료하지 않은 상태에서 데이터베이스가 다운될 경우 복구가 번거로우므로 한 번에 하나씩 백업 모드로 전환해서 작업하는 것이 정석이다.
정답 : (c),(d) (<- 마우스로 정답 부분을 선택하세요)
3-2. 다음 명령을 실행했을 때 컨트롤 파일이 백업되는 디렉토리는 어떤 초기화 파라미터에 의해서 결정되는가?
ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
a. BACKGROUND_DUMP_DEST
b. LOG_ARCHIVE_DEST
c. CORE_DUMP_DEST
d. STANDBY_ARCHIVE_DEST
e. USER_DUMP_DEST
<해설>
컨트롤 파일을 백업하는 명령은 두 가지가 있다. 먼저 위의 명령을 실행하면 USER_DUMP_DEST 파라미터에 지정된 위치로 텍스트 포맷의 트레이스 파일이 생성되는데 이 파일은 약간의 편집을 거치면 직접 실행해서 컨트롤 파일을 만들 수 있도록 SQL 스크립트 형식으로 되어 있다.
그리고 다음 명령으로도 컨트롤 파일을 백업할 수 있다.
ALTER DATABASE BACKUP CONTROLFILE TO ‘/disk1/backup/backup1.ctl’;
이 명령을 실행하면 /disk/backup/backup1.ctl 이라는 이름으로 컨트롤 파일이 백업되는데 이 파일은 원래의 컨트롤 파일과 동일한 바이너리 포맷이라는 점이 앞의 명령과 차이가 있다.
정답 : (e) (<- 마우스로 정답 부분을 선택하세요)
3-3. 다음 두 명령을 실행할 때 각각 어느 시점에 관련된 테이블스페이스를 백업하는 것이 바람직한가?
ALTER TABLESPACE users READ ONLY;
CREATE TABLE newemp
AS SELECT * FROM emp UNRECOVERABLE;
a. 명령 전, 명령 전
b. 명령 전, 명령 후
c. 명령 후, 명령 전
d. 명령 후, 명령 후
e. 필요 없음
<해설>
테이블스페이스를 읽기전용(read-only) 상태로 전환한 다음에는 백업을 받아두는 습관을 기르는 것이 좋다. 읽기전용 상태로 변경하기 전에 백업을 받으면 장애가 발생했을 때 백업을 리스토어 하고 나서 다시 리두로그 파일을 이용한 복구작업을 수행해야 한다. 그러나 읽기전용 상태로 전환한 다음에 백업을 해 주면 단순히 백업을 리스토어 하는 것으로 복구가 끝나므로 복구 시간을 단축할 수 있다..
다음의 명령도 비슷한 맥락에서 생각해 볼 수 있다. 이와 같은 Nologging 명령은 리두로그 정보를 발생하지 않기 때문에 실행 속도가 빠르다는 장점은 있지만 대신 장애가 발생했을 때 리두로그 파일을 이용한 복구가 불가능하다. 따라서 Nologging 명령을 수행한 다음에는 바로 백업을 실시하는 것이 좋다. Nologging 명령을 수행하기 전에 받은 백업은 별 의미가 없다.
정답 : (d) (<- 마우스로 정답 부분을 선택하세요)
완전복구 (Complete Recovery)
4-1. 다음은 아카이브로그 모드로 운영중인 데이터베이스의 작업 및 장애 내용을 기록한 것이다.
03:00 데이터베이스 전체 백업
09:00 트랜잭션 A 실행
09:10 트랜잭션 B 실행
10:00 트랜잭션 B 커밋
10:10 트랜잭션 A 커밋
11:00 트랜잭션 C 실행
11:05 SYSTEM 데이터 파일이 손상되면서 데이터베이스 다운
데이터베이스를 완전히 복구했을 때 복구되는 트랜잭션은?
a. 트랜잭션 A
b. 트랜잭션 A,B
c. 트랜잭션 B,C
d. 트랜잭션 A,C
e. 트랜잭션 A,B,C
<해설>
아카이브로그 모드의 장점을 얘기할 때에는 장애가 발생해도 데이터의 손실 없이 완전한 복구가 가능하다는 말이 결코 빠지지 않는다.
그러나 아카이브로그 모드도 커밋되지 않은 트랜잭션은 복구시키지 않으므로 완벽하게 장애가 발생하기 직전으로 돌아가는 것은 아니다. 롤 포워드(roll forward)로 복구를 한 후에 커밋되지 않은 트랜잭션은 다시 롤백시키기 때문인데 문서 작업을 하다가 PC가 다운되면 이전에 저장하고 난 다음의 내용은 날아가 버리는 것과 비슷한 이치라고 하겠다.
결론적으로 트랜잭션 A, B는 커밋을 했지만 트랜잭션 C는 커밋하기 전에 데이터베이스가 다운되었으므로 트랜잭션 C는 복구 후에 다시 작업해야 한다.
정답 : (b) (<- 마우스로 정답 부분을 선택하세요)
4-2. 노아카이브로그 모드로 운영중인 데이터베이스에서 USERS 테이블스페이스의 데이터 파일을 실수로 삭제하였다. 전날 콜드 백업을 받아두었다면 어떤 복구 방법을 사용하는 것이 가장 적절한가?
a. 삭제된 데이터 파일만 리스토어 하면 된다.
b. 삭제된 데이터 파일만 리스토어 하고 복구한다.
c. 콜드 백업 전체를 리스토어 한다.
d. 콜드 백업에서 모든 데이터 파일만 리스토어 하고 복구를 실시한다.
<해설>
노아카이브로그 모드로 운영할 때에는 복구 방법이 매우 제한적이다. 99.9%의 경우 백업 전체를 내리는 조치밖에는 별다른 대안이 없기 때문에 사실 복구보다는 단순한 리스토어에 가깝다고 할 수 있다.
극히 예외적인 경우로 백업을 받은 이후에 온라인 리두로그 파일이 순환되어 덮어씌워지지 않은 상태에서 데이터 파일이 없어졌다면 백업 이후의 작업 내용이 온라인 리두로그 파일에 그대로 살아있으므로 (b)나 (d)와 같은 방법도 가능하다. 그러나 실제 상황에서 이런 행운은 기대하지 않는 편이 좋으므로 정답과는 거리가 있다고 하겠다.
일반적으로 콜드 백업을 리스토어 할 때에는 없어진 데이터 파일을 포함하여 나머지도 모두 함께 리스토어 해야 한다. 그렇지 않으면 데이터베이스의 일관성을 유지할 수 없기 때문에 사용할 수 없다.
정답 : (c) (<- 마우스로 정답 부분을 선택하세요)
4-3. 디스크 에러가 발생하여 백업을 리스토어 하고 데이터베이스를 마운트 시켰다. 복구가 필요한 파일을 알려면 어떤 딕셔너리를 참조하면 되는가?
a. v$log_history
b. v$recover_file
c. v$recovery_log
d. v$filestat
e. v$datafile
<해설>
미디어 복구가 필요한 데이터 파일이 있다면 데이터베이스를 오픈할 때 “이러이러한 파일이 미디어 복구가 필요하다”는 에러 메시지가 나오므로 힘들이지 않고도 복구할 파일을 알 수 있다. 그러나 에러가 나오기 전에 미리 문제의 데이터 파일을 알고 싶다면 v$recover_file를 참조하면 된다.
v$log_history에는 리두로그 파일이 스위치 되면서 발생하는 과거 기록이 담겨 있다. 아카이브로그 모드가 아니더라도 상관없으며 컨트롤 파일에 들어있는 리두로그 히스토리를 보여준다.
정답 : (c),(d) (<- 마우스로 정답 부분을 선택하세요)
3-2. 다음 명령을 실행했을 때 컨트롤 파일이 백업되는 디렉토리는 어떤 초기화 파라미터에 의해서 결정되는가?
ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
a. BACKGROUND_DUMP_DEST
b. LOG_ARCHIVE_DEST
c. CORE_DUMP_DEST
d. STANDBY_ARCHIVE_DEST
e. USER_DUMP_DEST
<해설>
컨트롤 파일을 백업하는 명령은 두 가지가 있다. 먼저 위의 명령을 실행하면 USER_DUMP_DEST 파라미터에 지정된 위치로 텍스트 포맷의 트레이스 파일이 생성되는데 이 파일은 약간의 편집을 거치면 직접 실행해서 컨트롤 파일을 만들 수 있도록 SQL 스크립트 형식으로 되어 있다.
그리고 다음 명령으로도 컨트롤 파일을 백업할 수 있다.
ALTER DATABASE BACKUP CONTROLFILE TO ‘/disk1/backup/backup1.ctl’;
이 명령을 실행하면 /disk/backup/backup1.ctl 이라는 이름으로 컨트롤 파일이 백업되는데 이 파일은 원래의 컨트롤 파일과 동일한 바이너리 포맷이라는 점이 앞의 명령과 차이가 있다.
정답 : (b) (<- 마우스로 정답 부분을 선택하세요)
불완전 복구 (Incomplete Recovery)
5-1. Cancel-based recovery의 최소 복구 단위는?
a. 초(second)
b. SCN
c. 트랜잭션
d. 리두로그 파일
e. 오라클 블록
<해설>
불완전 복구(Incomplete Recovery)에는 Time-based, Cancel-based, Change-based 이상 세 가지 종류가 있다. 최소 복구 단위라면 얼마나 세밀하게 복구 간격을 조절할 수 있는가를 물어보는 것인데 정밀한 복구가 가능한 방법일수록 좀 더 높은 조작 기술과 상세한 정보를 필요로한다.
Time-based 방법의 예를 들면 다음과 같다.
RECOVER DATABASE UNTIL TIME ‘2001-03-01:15:24:30’;
이 명령을 실행하면 데이터베이스를 2001년 3월 1일 오후 3시 24분 30초의 상태로 만들어 준다. 이 때 지정하는 시간은 초(second) 단위 까지 설정할 수 있으며 SCN이나 로그 시퀀스 번호 보다는 시간이 쉽게 인지할 수 있는 개념이기 때문에 즐겨 이용된다.
Cancel-based 방법의 최소 단위는 리두로그 파일이다. 리두로그 파일의 중간 쯤에서 복구를 멈추고 싶다면 이 방법을 사용할 수 없으며 대신 Change-based 방법을 이용해야 한다.
Change-based 방법은 SCN 단위로 복구할 수 있기 때문에 가장 섬세한 컨트롤이 가능하다.
SCN은 트랜잭션 단위인데 1초 안에 여러 개의 트랜잭션이 발생할 수도 있으므로 Time-based 방법보다 Change-based 방법의 정밀도가 높다고 볼 수 있다. Time-based 방법의 정밀도는 중간 정도이고 Cancel-based 방법은 가장 사용하기 쉬운 반면 또한 가장 정밀도가 떨어진다.
정답 : (d) (<- 마우스로 정답 부분을 선택하세요)
5-2. 다음 중 불완전 복구를 수행해야 하는 경우가 아닌 것은?
a. 테이블을 삭제하기 이전의 상태로 돌아갈 때
b. 블록 손상(corruption)이 발생하기 이전으로 돌아갈 때
c. 커런트(current) 리두로그 파일이 손상되었을 때
d. 정전으로 시스템이 다운되었을 때
<해설>
불완전 복구는 완전 복구를 할 수 없기 때문에 불가피하게 선택하는 수도 있지만 데이터베이스를 과거의 시점으로 돌리기 위해서 일부러 불완전 복구를 하는 고의적인 상황도 있다.
대표적인 예가 a)와 b) 같은 경우이다. 특히 b)처럼 블록 손상이 발생하면 마치 하드디스크의 배드 섹터가 발생했을 때의 찜찜한 느낌처럼 문제가 생긴 곳 뿐 아니라 데이터베이스 전체에 대한 불신이 싹트게 된다. 그래서 성격이 깔끔한 사람은 약간의 데이터 손실을 감수하고서라도 블록 손상이 발생하기 이전으로 돌아가는 것을 선호하는 경우도 있다.
c)와 같이 현재 LGWR가 기록중인 커런트 리두로그 파일이 깨졌다면 이 파일의 내용은 아카이브되지 않은 상태이기 때문에 데이터의 손실은 불가피하다.
d)의 정전에 의한 시스템 다운은 미디어 복구가 아닌 인스턴스 복구만 하면 되므로 데이터의 손상 없이 완전 복구가 이루어진다.
정답 : (d) (<- 마우스로 정답 부분을 선택하세요)
5-3. 불완전 복구 작업을 완료하고 데이터베이스를 오픈하려고 한다. 다음 중에서 옳은 방법은?
a. ALTER DATABASE OPEN;
b. ALTER DATABASE OPEN NORESETLOGS;
c. ALTER DATABASE OPEN RESETLOGS;
d. ALTER DATABASE OPEN READ WRITE;
e. ALTER DATABASE OPEN READ ONLY;
<해설>
불완전 복구를 수행한 다음에 데이터베이스를 오픈할 때에는 반드시 RESETLOGS 옵션을 사용해야 한다.
RESETLOGS를 이용해서 컨트롤 파일과 데이터 파일의 시퀀스 번호를 초기화 시키고 온라인 리두로그 파일을 깨끗하게 만들어 주는 이유는 과거의 리두로그 파일들이 실수로 적용되는 것을 미연에 방지하기 위한 것이다. RESETLOGS를 사용하면 모든 데이터파일에 새로운 RESETLOGS SCN과 타임스탬프가 기록되는데 이 정보가 일치하지 않는 리두로그 파일은 복구에 사용되지 않기 때문에 잘못된 리두로그 파일이 적용되는 것을 원천적으로 차단할 수 있다.
RESETLOGS로 데이터베이스가 오픈되면 기존의 백업이 무의미해지므로 다시 전체 데이터베이스를 꼭 백업해 주어야 한다.
정답 : (c) (<- 마우스로 정답 부분을 선택하세요)
익스포트와 임포트
6-1. 다음과 같이 데이터베이스 작업과 백업을 수행하였다.
INCTYPE=COMPLETE 백업
BOOKS 테이블 생성
BOOKS 테이블에 10건의 데이터 입력
INCTYPE=INCREMENTAL 백업(a)
BOOKS 테이블에 20건의 데이터 입력
INCTYPE=CUMULATIVE 백업(b)
BOOKS 테이블에 40건의 데이터 입력
INCTYPE=INCREMENTAL 백업(c)
INCTYPE=CUMULATIVE 백업(d)
(a),(b),(c),(d) 단계에서 익스포트되는 BOOKS 테이블의 레코드 건수의 총 합은?
a. 50
b. 70
c. 90
d. 110
e. 130
<해설>
인크리멘탈(incremental) 익스포트는 증분 익스포트라고도 번역하지만 다소 어색하므로 그냥 소리나는 대로 쓰기로 한다.
인크리멘탈 익스포트는 백업 시간을 단축해 보자는 취지로 등장하였다. 익스포트를 받을 때 마다 매번 전부 다 백업하는 것은 비효율적이므로 이전에 익스포트 받은 다음에 변경된 부분만 백업할 수 있다면 시간을 크게 절감할 수 있지 않겠느냐는 것이었다.
그러나 결과는 절반의 성공에 그치고 말았다. 분명 이전의 백업 이후에 변경된 부분만 백업되므로 시간을 단축할 수는 있었지만 문제는 기존 테이블에 한 건만 데이터가 추가되어도 테이블 전체를 다시 백업해야 하는 특성 때문이었다.
결국 수 많은 테이블이 빈번하게 생성되는 시스템에서는 큰 재미를 보았지만 주로 기존 테이블에 대한 DML 작업이 많은 환경에서는 불필요하게 덤프파일의 개수만 늘어나므로 환영을 받지 못했다.
인크리멘탈 익스포트에는 세 가지 타입이 있다.
COMPLETE는 데이터베이스 전체를 백업 받는 것이고 CUMULATIVE는 이전의 COMPLETE 또는 CUMULATIVE 백업 이후의 내용을 익스포트 한다. INCREMENTAL은 이전의 COMPLETE, CUMULATIVE 또는 INCREMENTAL 익스포트 이후의 변경 사항을 백업한다.
이렇게 여러 레벨로 나누어 놓은 이유는 파일 관리를 좀 더 수월하게 하기 위해서이다. 인크리멘탈 익스포트의 단점 중의 하나가 관리할 덤프 파일이 갈수록 늘어난다는 점인데 여러 차레 인크리멘탈 익스포트를 수행한 다음에 그보다 상위의 모드로 익스포트를 수행하면 이전의 자잘한 덤프파일을 대체할 수 있다.
본 문제에서는 인크리멘탈 익스포트를 수행할 때 마다 테이블의 내용이 변경되었기 때문에 (a)=10건, (b)=10+20=30건, (c)=10+20+40=70건이 각각 익스포트 된다. (d)에서는 BOOKS 테이블에 변경 사항이 없으므로 0건이 익스포트 된다. 따라서 모두 합치면 110건이 정답이다.
정답 : (d) (<- 마우스로 정답 부분을 선택하세요)
6-2. 임포트 되는 순서를 올바르게 나열하시오(주관식).
a. 테이블 데이터
b. 테이블 정의(definition)
c. 제약 조건, 뷰, 프로시저, 트리거
d. 테이블 인덱스
e. 타입(type) 정의
<해설>
객체에 따라서 다른 객체를 참조하지 않는 완전 독립형인 경우도 있지만 대부분 여러 객체가 서로 얽혀 있는 것이 일반적이다. 그래서 임포트될 때 최고의 효율을 꾀하고 의존 관계에 의한 에러를 방지하기 위해서 매우 정교하게 순서가 설정되어 있는데 힘들여 암기할 필요 없이 아래처럼 논리적으로 따져보면 대략 순서를 유추할 수 있다.
먼저 테이블을 만들 때 타입 정의를 사용할 수도 있으므로 테이블보다는 타입이 먼저 만들어져야 함을 알 수 있다..
그리고 인덱스가 있는 상태에서 데이터를 넣는 것보다 데이터를 먼저 넣은 다음에 인덱스를 생성하는 것이 속도가 빠르기 때문에 데이터와 인덱스의 임포트 순서가 결정된다.
그 밖에 제약조건은 특히 레퍼런스 때문에 자연스럽게 뒤로 밀리게 되고 트리거는 테이블의 데이터보다 먼저 만들면 나중에 데이터가 임포트 될 때 불필요하게 실행되므로 이를 방지하기 위해서 역시 우선순위가 낮게 설정된다.
이런 관계를 종합해 보면 큰 어려움 없이 정답을 찾아낼 수 있을 것이다.
정답 : (f),(c),(b),(e),(d) (<- 마우스로 정답 부분을 선택하세요)
6-3. TSPITR(Tablespace Point-In-Time Recovery)와 관련된 초기화 파라미터가 아닌 것은?
a. LOCK_NAME_SPACE
b. DB_FILE_NAME_CONVERT
c. LOG_FILE_NAME_CONVERT
d. CONTROL_FILE_NAME_CONVERT
<해설>
실수로 테이블을 하나 삭제한 후에 이 테이블을 살려내야 한다면?
전통적인 복구 전략에 따르면 백업 전체를 리스토어 한 다음에 불완전 복구를 수행하거나 별도의 장소에 백업을 리스토어 한 다음 익스포트/임포트를 이용하여 테이블을 받아와야 할 것이다.
TSPITR은 이런 문제에 대한 업그레이드된 해결 방법이다. 전체적인 개념은 두 번째의 익스포트/임포트 방법과 유사하지만 TSPITR은 익스포트/임포트를 통해서는 메타데이터만 전송하고 실제의 데이터 복구는 운영체제 상의 데이터 파일을 복사하는 것으로 대신하기 때문에 속도가 매우 빠르다. 테이블이 아닌 테이블스페이스를 기본 단위로 한다는 특징이 있고 작업 과정이 비교적 복잡한 편이지만 삭제된 테이블의 크기가 클수록 그 가치가 더욱 빛나는 기능이다.
LOCK_NAME_SPACE는 클론 데이터베이스(TSPITR을 위해서 생성한 데이터베이스)가 원래의 데이터베이스와 이름이 같아도 기동할 수 있도록 하는 역할을 하므로 데이터베이스 이름을 바꿀 필요가 없도록 해 준다.
클론 데이터베이스를 기동할 때 기존 데이터베이스의 컨트롤 파일 백업본을 이용하는데 파일들의 위치가 기존 데이터베이스와 달라지기 때문에 새로운 위치에 있는 파일을 찾을 수 있도록 디렉토리 이름을 바꿔주는 파라미터가 제공된다.
데이터 파일은 DB_FILE_NAME_CONVERT, 리두로그 파일은 LOG_FILE_NAME_CONVERT를 이용해서 위치를 변환한다. 파일 이름이 아닌 디렉토리를 지정하는 것임을 주의하기 바란다. 예를 들면 다음과 같다.
DB_FILE_NAME_CONVERT = ‘/disk1/oracle/orig’,’/disk1/oracle/clone’
정답 : (d) (<- 마우스로 정답 부분을 선택하세요)
tb_free.zip.001
프로시져백업.zip