장애의 종류
오라클 데이터베이스 환경에서 다음과 같은 다양한 장애가 발생될 수 있습니다.

장애 상황으로부터 효과적으로 복구하기 위해 각 유형의 장애들은 DBA의 다양한 레벨의 참여를 요구합니다. 어떤 경우에 복구는 구현된 백업 전략의 유형에 의존합니다. 예를 들어, 구문 장애는 약간의 DBA 개입을 요구할 수 있지만, 미디어 장애는 테스트된 복구 전략을 DBA가 수행하기를 요구합니다.

구문 장애
구문장애는 오라클 프로그램에서 구문 취급상의 논리적 장애가 있는 경우 발생합니다. 다음과 같은 구문장애 유형이 있습니다.

주:구문 장애일 때 오라클 서버나 운영 체제는 에러 코드와 메시지를 반환할 것입니다. 잘못된 SQL 구문은 자동적으로 롤백 되고 컨트롤은 사용자 프로그램으로 리턴됩니다. 어플리케이션 개발자나 DBA는 장애를 진단하고 해결하기 위하여 오라클 에러 코드를 사용할 수 있습니다.

구문 장애의 해결
구문 장애 시 DBA 개입(intervention)은 장애 종류에 따라 정도가 달라질 것입니다.

사용자 프로세스 장애의 원인
사용자 프로세스가 여러 가지 이유로 실패 될 수 있지만, 일반적인 원인은 다음과 같습니다.

사용자 프로세스 장애와 DBA조치
DBA는 사용자 프로세스 에러를 해결하기 위하여 좀처럼 행동을 취할 필요가 없을 것입니다. 비록 오라클과 다른 사용자 프로세스가 시스템이나 다른 사용자에게 최소의 영향을 주더라도 사용자 프로세스는 작업을 계속할 수 없습니다.

PMON 백그라운드 프로세스
PMON 백그라운드 프로세스는 사용자 프로세스가 비정상적으로 종료된 후 정리(cleaning up)하는 데 일반적으로 충분합니다.

사용자 에러 장애
DBA 개입(intervention)이 사용자 에러로부터 복구하기 위하여 주로 요구됩니다.

사용자 에러 장애의 일반적인 원인

사용자 에러 장애의 최소화
임의의 데이터베이스와 어플리케이션 환경에서의 핵심 사항은 사용자가 교육 받고 데이터베이스의 가용성과 무결성에 관련된 영향을 알고 있도록 하는데 있습니다.

DBA는 사용자 에러로 인해 데이터를 상실할 지도 모르는 어플리케이션과 업무 운영의 유형과, 유효한(valid) 백업으로부터 복구하는 것과 같은 복구 방안의 구현법을 이해해야 합니다.

어떤 복구 상황에서는 인스턴스와 데이터베이스를 에러 직전 시점으로 복원하고 손실 데이터를 export하여 다시 그 데이터를 데이터베이스로 import하는 매우 광범위한 것이 될 수도 있습니다. 

인스턴스 장애
인스턴스 장애는 다음과 같은 여러 가지 이유의 결과로서 발생할 수 있습니다:

인스턴스 장애를 복구하기 위한 DBA의 작업은 다음과 같습니다:

인스턴스 복구
인스턴스 복구는 인스턴스 장애 직전 시점과 일관된 트랜잭션의  상태로 데이터베이스를 복구합니다. 오라클 서버는 데이터베이스가 오픈 되었을 때 필요하다면 인스턴스의 복구를 자동적으로 실행합니다.

주

인스턴스 복구 단계

 번호

  설 명

1

비동기화된 파일
오라클은 비동기화된 파일이 발견될 때 데이터베이스 복구의 필요 여부를 결정합니다. shutdown abort와 같은 인스턴스 장애가 이것을 유발할 수 있습니다. 이 상황은 메모리가 디스크에 기록되지 않고 종료되기 전에 파일이 동기화 되지 않기 때문에 커밋 안된 데이터의 상실을 유발합니다.

2

Roll-Forward 프로세스
DBWR은 커밋된 데이터와 커밋 안된 데이터 모두를 데이터파일에 기록합니다. Roll-forward 프로세스의 목적은 로그에 기록된 모든 변경 사항을 데이터 블록에 적용하는 것입니다.

주
-롤백 세그먼트는 roll-forward 단계 동안 채워집니다. 리두 로그가 사전, 사후 데이터 이미지를 모두 저장하기 때문에, 커밋 안된 블록이 데이터파일에 있고 롤백 엔트리가 없으면 롤백 세그먼트 엔트리는 추가됩니다.
- 리두 로그는 로그 버퍼를 이용하여 적용됩니다. 사용된 버퍼는 복구
를 위해 표시되고, 복구 프로세스에 의해 버퍼가 다 사용되고 필요 없
게 될 때까지 일반 트랜잭션에 관여할 수 없습니다.
- 상태 충돌(status conflict)이 있다면 리두 로그는 read-only 데이터 파일에만 적용됩니다. (즉 파일 헤더는 이 파일이 read-only라고 말하고  있지만 컨트롤 파일은 이 파일을 read-write로 인식하고 있음, 그 반대도 성립)

3

데이터파일의 커밋된 데이터와 커밋 안된 데이터
roll-forward 단계가 성공적으로 끝나기만 하면, 커밋 안된 데이터가 존재할지 모르지만 모든 커밋된 데이터는 데이터파일에 존재합니다.

4

Roll-Back 단계
파일에서 커밋 안된 데이터를 제거하기 위하여, Roll-forward 단계 동안 채워진 롤백 세그먼트가 사용됩니다. 블록은 블록을 처음 요구하는 자가 누구이냐 의존하여 오라클 서버나 사용자에 의해 요청될 때 롤백 됩니다.

5

데이터파일의 커밋된 데이터
roll-forward와 roll-back 단계가 끝났을 때 커밋된 데이터만 디스크에 존재합니다.

6

동기화된 데이터 파일
모든 데이터파일은 이제 동기화 됩니다

미디어 장애
미디어 장애는 데이터베이스 운영에 필요한 파일을 읽을 때와 이 파일에 기록할 때의 물리적인 문제를 포함합니다. 미디어 장애는 보통 DBA 개입을 요구하므로 장애의 종류 중 가장 심각한 것입니다.

미디어 관련 문제의 일반적 유형

미디어 장애의 해결
테스트된 백업 전략은 미디어 장애 문제를 해결하기 위한 핵심 구성요소 입니다. 미디어 장애의 결과로 발생한 고장 시간(down time)과 데이터 상실을 최소화 하기 위한 DBA의 능력은 이용 가능한 백업의 종류에 의존적입니다. 그러므로 복구 전략은 다음에 달려 있습니다:

데이터베이스 동기화
모든 데이터파일, 리두 로그, 컨트롤 파일이 동기화 되지 않았다면, 오라클 데이터베이스는 오픈될 수 없습니다. 이 경우에 복구가 요구됩니다.

데이터베이스 파일 동기화

지연된 트랜잭션 롤백

지연된 롤백은 Oracle7.3.1부터 도입되었습니다. 지연된 롤백은 리두 로그 파일을 사용하는 롤포워드가 완료되면 즉시 데이터베이스가 열리도록 합니다. 커밋되지 않은 트랜잭션의 롤백은 사용자에게 데이터베이스를 연 후에 수행됩니다.

롤백은 다음 중 한 가지 방법으로 수행될 수 있습니다.

Oracle8i 이전

병렬 트랜잭션이 시스템 고장으로 종료된 경우 롤백은 주로 순차적인 작업이기 때문에 지연된 롤백이 장시간 지속될 수 있습니다. 예를 들어, 병렬도가 6인 병렬 갱신 트랜잭션이 10분 정도 지속된 다음 시스템 고장으로 인해 실패합니다. SMON이 직렬로 이러한 트랜잭션을 롤백하는 데는 한 시간 이상 걸릴 수 있습니다.

Oracle8i를 사용할 경우

Oracle8i에서의 fast-start 병렬 롤백은 SMON이 병렬 질의 슬래이브를 사용하여 롤백 작업을 완료하도록 합니다. 사용 불능 트랜잭션이 많은 수의 롤백 블록을 생성한 것으로 SMON이 판단한 경우 병렬 롤백이 자동으로 시작됩니다. 트랜잭션이 생성한 롤백 블록의 현재 임계값은 100입니다.

초기화 매개변수

fast-start 병렬 롤백은 동적 초기화 매개변수 FAST_START_PARALLEL_ROLLBACK에 의해 시작됩니다. 이 매개변수의 유효 값 및 이 값이 fast-start 병렬 롤백에 주는 영향이 표에 나와 있습니다.

동적 성능 뷰

fast-start 병렬 롤백의 진행 및 롤백을 수행하는 데 사용되는 프로세스를 모니터하기 위해 두 개의 새 동적 성능 뷰를 사용할 수 있습니다.

병렬 질의 프로세스

다음 질의를 사용하여 fast-start 병렬 롤백에 대한 병렬 질의

슬래이브의 사용을 모니터합니다.

SELECT * FROM v$fast_start_servers;

STATE           UNDOBLOCKSDONE   PID

----------      --------------  ----

RECOVERING                  99    10

IDLE                         0    11

IDLE                         0    12

IDLE                         0    13

롤백된 트랜잭션

fast-start 롤백의 상태를 확인하기 위해서 다음 질의를 사용합니다.

SELECT usn, state, undoblksdone, undoblkstotal

 FROM v$fast_start_transactions;

 USN   STATE        UNDOBLOCKSDONE  UNDOBLOCKSTOTAL

 ---   -----------  --------------  ---------------

   2   RECOVERING               82              365

USN 열은 롤백이 발생한 롤백 세그먼트를 나타내고 UNDOBLKSDONE 및 UNDOBLKSTOTAL은 수행된 작업의 양과 총 작업량을 각각 나타냅니다.

On-demand 병렬 롤백

fast-start 병렬 롤백은 SMON에 의해 트랜잭션의 롤백 속도가 향상되지만 대용량 트랜잭션의 복구를 시작한 후에 사용자 트랜잭션이 기다려야 하는 문제를 해결하지는 못합니다. 이러한 문제는 SMON이 아직 롤백하지 않은 사용 불능 트랜잭션에서 보유한 잠금을 감지한 경우 발생할 수 있으며 On-demand 병렬 롤백이 이 문제를 해결합니다.

On-demand 블록 레벨 복구에서 사용자 트랜잭션은 해당 사용자 트랜잭션이 액세스를 시도하는 블록에 대해서만 롤백을 시작합니다. 나머지 블록은 SMON에 의해 잠재적으로 병렬로 백그라운드에서 복구됩니다.

요약 정보

컨텍스트

참조

매개변수

DBWR_IO_SLAVES
CONTROL_FILES
FAST_START_IO_TARGET
DB_BLOCK_MAX_DIRTY_TARGET
LOG_CHECKPOINT_INTERVAL
LOG_CHECKPOINT_TIMEOUT
LOG_CHECKPOINTS_TO_ALERT
DB_BLOCK_BUFFERS
DB_BLOCK_SIZE
LOG_BUFFER
LARGE_POOL_SIZE
BACKUP_TAPE_IO_SLAVES

동적 성능 뷰

V$SGA
V$SGASTAT
V$INSTANCE
V$PROCESS
V$DATABASE
V$DATAFILE
V$LOG
V$LOGFILE
V$LOG_HISTORY
V$PARAMETER
V$CONTROLFILE
V$FAST_START_SERVERS
V$FAST_START_TRANSACTIONS
V$INSTANCE_RECOVERY

데이터 딕셔너리 뷰

없음

명령

ALTER DATABASE ADD LOGFILE
ALTER DATABASE DROP LOGFILE
ALTER DATABASE RENAME FILE
ALTER DATABASE ADD LOGFILE MEMBER
ALTER DATABASE DROP LOGFILE MEMBER
ALTER SYSTEM SWITCH LOGFILE

 

X 정답:B


X 정답:B


X 정답:BC


O


O


X 정답:A


O


O


X 정답:AB


X 정답:AC


O


O


O


X 정답:B


X 정답:CDE


X 정답:B


O


X 정답:B


X 정답:A