oracle recovery internal · 2013-03-25 · - 6 - i. oracle architecture table index undo temporary...
TRANSCRIPT
Oracle Recovery Internal
OCM
Seungtaek Lee(放浪DBA)
2010.12
1. Physical Architecture
2. Logical Architecture
1. Physical Backup
2. Logical Backup
II. Backup Types
I. Oracle Architecture
1. SCN
2. Change Vectors
3. Redo Record
4. Redo Log
5. Control File
6. Data File
7. Checkpoint
8. Diagnostic Facilities
III. Internal Recovery Structures
1. Instance Recovery
2. Media Recovery
3. Block Recovery
4. Logical Recovery
5. Disaster Recovery
Ⅳ. Recovery Types
1. Backup & Recovery Strategy
2. List Of Outages
3. Recovery Flow Charts
4. Redo Operation Codes
5. Database Flags
6. Recovery-Related Hidden Parameters
7. ADJUST_SCN Event
- Reference
Appendixes
Guide of This Book
I. Oracle Architecture
- Oracle 기본 구조에 대한 개념 이행 및 설명
: Physical, Logical Architecture
II. Backup Types
- Oracle Backup 방법에 대한 개념 이해 및 설명
: Physical, Logical Backup
III. Internal Recovery Structures
- Oracle 을 구성하고 있는 다양한 구성 요소에 대한 구조 및 설명
: SCN, Change Vectors, Redo Records, Redo Logs, etc
Ⅳ. Recovery Types
- Oracle 복구 유형 분류 5가지에 대한 개념 이해 및 설명
: Instance / Media / Block / Logical / Disaster Recovery
Appendixes
- Recover 시 활용할 수 있는 유용한 추가 정보
: 복구작업 흐름도, Redo 코드, 주요 Hidden Parameter 등
ICT인프라본부 | Copyright ⓒ 2010 Samsung SDS Co., Ltd. All Rights Reserved | Confidential
Introduction
- 5 -
I. Oracle Architecture 1. Physical Architecture
SGA
Shared Pool
Data Dictionary Cache
Library Cache
Database Buffer Cache
Redo Log Buffer
Java Pool Large Pool Miscellaneous
SGA
Shared Pool
Data Dictionary Cache
Library Cache
Database Buffer Cache
Redo Log Buffer
Java Pool Large Pool Miscellaneous
Archiver Log Writer Checkpoint Database Writer
ARC0 LGWR CKPT DBW0
Database Writer Checkpoint Log Writer Archiver
ARC0 LGWR CKPT DBW0
Archive Log File Redo Log
Files Data File
Control File Redo Log Files
Instance Instance
Archive Log Files
RAC1 RAC2
Process Monitor
PMON
System Monitor
SMON
Process Monitor
PMON
System Monitor
SMON
- SGA (System Global Area)
. Database Buffer Cache : Data File에서 조회된 Data Block을 저장하는 Cache 영역
. Redo Log Buffer : Recovery에 사용되는 Redo 정보가 Redo Log에 기록될 때까지 해당 정보를 저장하는 Memory 영역
. Shared Pool : 유저 간에 공유할 수 있는 다양한 구성요소를 저장하는 Cache 영역
. Large Pool : RMAN Backup 및 Recovery 작업이나 Parallel Process, Shared Process에 의해 사용하는 Memory 영역
. Java Pool : JVM(Java Virtual Machine)내의 모든 Session별 Java코드 및 데이터에 사용됨
- Background Process
. Database Writer : Database Buffer Cache로부터 Data File로 변경된 Block(Dirty Buffer)를 기록하는 Process
. Log Writer : Log Buffer에 있는 Redo Log Record들을 Redo Log File에 기록하는 Process Transaction Commit시, Log Buffer의 1/3이 찰때, 매 3초 마다 기록
. Checkpoint : Checkpoint Event 발생 시 DBWR 에 신호를 보내고 Data File Header와 Control File에 Checkpoint 정보를 기록하는 Process
. System Monitor : DB Instance Crash 장애 시 Transaction Recovery 작업 수행 Temporary Segment 정리 작업 및 Free Extent에 대한 Coalescing 작업을 수행
. Process Monitor : User Process Failure시 Process Recovery를 수행하고 Failure 된 User Process가 점유하고 있던 자원을 반납하는 작업을 수행
. Archiver : Redo Log File이 Full 되었을 때, 이를 지정한 Storage에 Copy하는 작업을 수행하는 Process
- Database File
. Control File : 물리적 Database 구조 정보, Checkpoint 정보, 백업 정보 등을 저장하는 File
. Data File : Database의 유저 또는 응용 프로그램의 데이터를 저장하는 File
. Redo Log File : Redo Log Record를 저장하는 File
. Archive Log File : Redo Log File이 Full 될 때 이를 Copy하여 Archive Log File형태로 저장함
Archive Log File과 Data File 백업을 이용하여 손실된 Data File을 Recovery함
<Fig I-1-1> Physical Structure
Physical Architecture of Oracle
- 6 -
I. Oracle Architecture
Table
Index
Undo
Temporary
Partition
Cluster
Materialized View
Physical
Structures
Tablespace
Data File
OS Block DB Block
Extent
Segment
Schema Owner
Logical
Structure
Logical
Structure
Row piece
Rows
Columns
Tablespace
Table
Extent
Blocks
Segment
Table A
Table B
<Fig I-2-1> Logical Structure
2. Logical Architecture
- Oracle Database는 Data를 논리적으로는 Tablespace에 저장하고 물리적으로는 Data File에 저장함
- Tablespace
. 하나의 Database에만 속할 수 있음
. 하나 이상의 Data File로 구성됨
. 여러 개의 논리적 저장 영역 단위로 나누어짐
. Schema 객체 Data의 저장 영역임
- Segment
. Tablespace 내에 존재하는 객체임
. Segment는 Extent 모음으로 구성됨
. Table, Index, Cluster, Partition, Material View, Undo, Temporary Segment 등이 있음
- Extent
. Extent는 연속된 DB Block의 모음으로 구성됨
- DB Block
. DB Block은 OS Block에 Mapping됨
. DB Block에는 Row가 저장됨
. Row는 한 개 이상의 Column으로 구성됨
Logical Architecture of Oracle
- 7 -
II. Backup Types
- Database File의 실제 물리적인 Block을 한 위치에서 다른 위치로 Copy하는 Backup
- Physical Backup 종류
. Physical Backup은 DB 가동 유무에 따라 DB 비 가동 상태에서 Backup을 수행하는 Offline백업과
DB 가동 상태에서 Backup을 수행하는 Online 백업으로 구분
. Physical Backup은 OS Command로 Backup을 수행하는 User-Managed Backup과 Oracle RMAN으로
Backup을 수행하는 Server-Managed Backup으로 구분
방식 Offline Backup (Consistency Backup) Online Backup (Inconsistency Backup)
개요 - DB를 정상 Shutdown (Abort제외)한 후 Backup을
수행하는 방식
- 가동중인(Open) DB에서 Backup 수행하는 방식
Backup 수행 중에도 Data File에 Write가 계속됨
대상 - Data File, Control File, Redo Log File - Data File, Control File, Archive Log File
특징 - 모든 Data File이 Consistency가 맞기 때문에
추가로 Redo Log 적용 없이 DB Open 가능
- Data File의 Consistency가 맞지 않기 때문에 Redo
Log를 적용(Recovery) 해야 DB Open이 가능
- Backup되는 Data Block의 SCN이 Data File Header의
Checkpoint SCN보다 높을 수 있음
(Header Inconsistency)
- 백업 시 IO단위와 Data Block의 크기가 다를 수
있음으로 인해 Data Block의 Header와 Tail 부분의
Consistency가 달라 질 수 있음 (Block Inconsistency)
- Data File이 변경되는 동안 Backup이 수행되기
때문에 다른 시점의 Data Block이 백업될 수 있음
(Backup Inconsistency)
1. Physical Backup
<Tab Ⅱ-1-1> Offline/Online Backup 비교
Physical Backup
- 8 -
II. Backup Types 1. Physical Backup
<Tab Ⅱ-1-2> User-Managed Backup/Server-Managed Backup 비교
단계 Inconsistency 현상 User-Managed Backup Server-Managed Backup (RMAN)
시작 - File Header
Inconsistency :
Backup 수행 시
File Header부터
Copy하지 않을
경우 복구 시에
Redo Log 적용
시작 시점을 알 수
없음
- 수동으로 Begin Backup command수행
. Data File Header에 Hot Backup Fuzzy
Bits이 설정됨
. Tablespace/Database단위로
Checkpoint 발생
. OS Command로 Backup 수행 시 Data
File의 Header 부터 Copy 하지 않을 수
있음. 이런 경우에는 복구 시에 Redo
Log 적용 시작 시점을 알 수 없기
때문에 Data File Header의 Checkpoint
SCN을 Backup이 끝날 때까지 고정
시킴
→ 복구 시 Backup File의 Checkpoint
SCN이 Redo Log 적용 시작 시점이 됨
- Data File 단위로 Checkpoint 발생.
- Data File Header 부터 Backup 수행
- Backup 시작 시점의 Checkpoint
SCN이 Backup Set일 경우
메모리(Large Pool/Shared Pool)에
기록되고 Image Copy일 경우
Backup본의 Header Block에 기록됨
→ 복구 시 Checkpoint SCN이 Redo
Log 적용 시작 시점이 됨
- Backup 수행 중에 Data File Header의
Checkpoint SCN은 Checkpoint 발생 때
변함
수행 - Block
Inconsistency :
Backup IO 단위와
Oracle Block 단위
차이 때문에
Backup Block이
손상됨 (Fractured
Block)
- OS Command로 Backup 수행
. Backup 수행 중 Backup IO단위와
Oracle Block IO단위의 차이로 Backup
File의 Block이 Split되는(Fractured
Block) 현상이 발생할 수 있으므로
해당 Block에 Transaction 발생 시 최초
한번은 Block Image Redo Record를
생성함
. 디스크로 Flush된 다음 다시 Cache로
읽혀진다면, Block Image Redo
Record가 다시 생성
. 이 때문에 Backup 수행 시 Redo가 많이
발생
- Oracle Block Size의 배수로 Backup을
수행하고 Block 손상 유무를
Checksum값으로 확인함으로 Block
손상 현상을 방지
종료 - Backup
Inconsistency :
Backup 종료
시점을 알 수
없어서 Redo Log
최소 적용 시점을
알 수 없음
- 수동으로 End Backup command수행
- Redo log에 Hot Backup end marker
생성
→ 복구 시 Consistency 보장을 위한
최소 복구 시점임 (Recovery 수행 시
해당 marker를 만나면 Hot Backup Fuzzy
Bits설정이 해제되고 DB Open이 가능함)
- Data File Header에 Hot Backup Fuzzy
Bits설정이 해제됨
- Backup본의 Block SCN중에서 가장
높은 SCN(Absolute Fuzzy SCN)이
Backup 시작시점의 SCN(Checkpoint
SCN)과 함께 Backup 본의 Header
Block에 기록됨
→ Backup본 Header에 기록된
Absolute Fuzzy SCN이 복구
Consistency 보장을 위한 최소 복구
시점임
- 9 -
II. Backup Types
- User-Managed Backup의 내부 작업
. User-Managed Backup은 Oracle의 Backup 명령어가 아닌 OS 또는 3rd Party Backup Software를
이용한 백업 방식
. Backup 수행은 아래와 같은 단계로 실행
① BEGIN BACKUP Command 수행
② OS 명령어로 Backup 수행
③ END BACKUP Command 수행
. BEGIN BACKUP Command가 수행 되면 해당 Data File에 대한 Checkpoint가 발생
. 또한 해당 Data File Header에 Hot Backup Fuzzy Bit이 설정되고 END BACKUP Command 수행
전까지 Checkpoint SCN은 고정
. 이 고정된 Checkpoint SCN이 복구 작업시에 Redo Log File 적용 시작 시점임
. END BACKUP Command 전 까지 변경이 발생한 Block에 대해서 Block Split현상 대응을 위해 Before
Block Image Redo Record를 생성
. Block Split 현상은 Backup IO 단위와 Oracle IO 단위의 차이에서 오는 현상으로 만약 Oracle Block의
크기가 OS Block의 배수라면 OS가 어떻게 복사하는지에 따라 백업본 블록의 전반과 후반이 다른
시점의 블록으로 기록될 수 있는 현상
. Block Split 현상에 대응하기 위해 Oracle은 Default 값으로(_LOG_BLOCKS_DURING_BACKUP=TRUE)
Online Backup 동안 Block이 변경되면 변경 전 이미지(Before Block Image Memory Dump)를 Redo
Log에 Logging하여 복구 시에 사용
. Before Block Image는 변경된 Block에 대해 최초 한번만 Logging 하지만 백업 수행 동안 디스크로
Flush되었다면 다시 Logging할 수 있음
. END BACKUP Command 가 수행되면 Hot Backup End Marker Redo Record가 생성되고 Hot Backup
Fuzzy Bit은 해제
. 복구 작업 시 Hot Backup End Marker Redo Record까지 적용하면 Resetlogs로 Open가능
34
Block Split 현상
Oracle IO : 8KBytes
REDO RECORD - Thread:1 RBA: 0x000588.00000002.0010 LEN: 0x2050 VLD: 0x05 SCN: 0x0000.002cff6e SUBSCN: 2 04/27/2010 08:45:13 CHANGE #1 TYP:3 CLS: 1 AFN:4 DBA:0x0100c2e1 OBJ:55790 SCN:0x0000.002cfed7 SEQ: 1 OP:18.1 Log block image redo entry Dump of memory from 0xAEDEF220 to 0xAEDF1208 AEDEF220 00000001 0000D9EE 002CFED5 00000000 [..........,.....] AEDEF230 00320002 0100C28A 00230007 0000033A [..2.......#.:...] AEDEF240 008001F4 00140201 00008000 002C8D7A [............z.,.] AEDEF250 00260008 00000432 008009A9 000F03C5 [..&.2...........] AEDEF260 00002001 002CFED7 00000000 00000000 [. ....,.........] AEDEF270 00030100 00180001 1F6B1F6C 00001F6B [........l.k.k...] AEDEF280 1F8C0003 1F6CFFFF 00000000 00000000 [......l.........] AEDEF290 00000000 00000000 00000000 00000000 [................] Repeat 499 times
Block Image(Memory Dump) Redo Record
34 35 35 34
35
34 34 35
35
Backup IO : 4KBytes
1. Physical Backup
<Fig Ⅱ-1-1> User-Managed Backup시 Block Split 현상
- 10 -
II. Backup Types
Header SCN
Block 1 SCN
Block 2 SCN
Block 3 SCN
Block 4 SCN
Block 5 SCN
38 37 39 37 38 36
Header SCN
Block 1 SCN
Block 2 SCN
Block 3 SCN
Block 4 SCN
Block 5 SCN
38 37 34 37 38 36
Header SCN
Block 1 SCN
Block 2 SCN
Block 3 SCN
Block 4 SCN
Block 5 SCN
36 37 34 37 35 35
Header SCN
Block 1 SCN
Block 2 SCN
Block 3 SCN
Block 4 SCN
Block 5 SCN
36 34 34 35 35 35
Header SCN
Block 1 SCN
Block 2 SCN
Block 3 SCN
Block 4 SCN
Block 5 SCN
31 30 34 30 34 34
Block 1 SCN
Block 2 SCN
Block 3 SCN
Block 4 SCN
Block 5 SCN
Header SCN
34 34 37 38 36 36 38
Block 1 SCN
Block 2 SCN
Block 3 SCN
Block 4 SCN
Block 5 SCN
34 34 37 38 36
Block 1 SCN
Block 2 SCN
Block 3 SCN
Block 4 SCN
34 34 37 38
Block 1 SCN
Block 2 SCN
34 34
Block 1 SCN
34
Header SCN
36
Absolute Fuzzy SCN
Checkpoint SCN
Header SCN
Block 1 SCN
Block 2 SCN
Block 3 SCN
Block 4 SCN
Block 5 SCN
36 38
34 34 37 38 36
Header SCN
Block 1 SCN
Block 2 SCN
Block 3 SCN
Block 4 SCN
Block 5 SCN
38 37 34 37 38 36
Online Data File
Backup Set
Restored Data File
③ Recovery
① Online Backup
② Restore
Large Pool
- Server-Managed Backup (RMAN)의 내부 작업
. Server-Managed Backup은 Oracle의 RMAN을 이용한 백업 방식
. RMAN은 BEGIN/END Command 없이 백업을 수행하기 때문에 Block Image 같은 추가 Redo가
발생하지 않음 (Oracle Block Size의 배수로 백업을 수행하기 때문에 Block Split 현상이 없음)
. RMAN은 Full Backup 뿐만 아니라 Block 레벨의 Incremental Backup, Compressed Backup 등 다양한
방식의 백업을 지원
. RMAN은 백업시에 Data File의 Header Block부터 백업을 수행하기 때문에 User-Managed Backup
방식과 달리 Header Block의 Checkpoint SCN을 고정시키지 않음. 복구 시 Redo Log 적용을 Header
Block의 Checkpoint SCN 시점부터 복구를 시작
. RMAN 백업은 End Backup을 수행하지 않기 때문에 백업시에 Redo Log 최소 적용 시점 정보인
Absolute Fuzzy SCN값을 백업 Data File Header에 기록
. Absolute Fuzzy SCN값은 백업 Data File의 Block SCN값 중 가장 큰 SCN 값
1. Physical Backup
<Fig Ⅱ-1-2> Server-Managed Backup (RMAN)
- 11 -
II. Backup Types
Step Description
Online Backup
(①)
- RMAN Online Backup이 시작되면 해당 Data File에 대해 Checkpoint를 발생
이때의 Checkpoint SCN이 기록된 Data File Header Block을 Large Pool 메모리에 Copy
- 이후 순서대로 Block을 읽어 Backup Set에 저장
- Backup 종료시점에 Backup Set Block의 가장 높은 SCN(Absolute Fuzzy SCN)을 Header Block에
Update하여 Backup Set 끝부분에 Header Block을 추가
Recovery (②③) - Recovery시에는 Header Block에 기록된 Checkpoint SCN 부터 Redo Record를 적용
- Absolute Fuzzy SCN까지 Redo 가 적용되면 Fuzzy Bit이 없어지고 DB를 Open할 수 있음
RMAN Image
Copy
- Image Copy 백업도 Backup Set 백업과 거의 동일하게 수행
단 Header Block을 Image Copy본 앞부분에 가장 먼저 저장 (Image Copy본은 Data File과 똑
같은 구조로 만들기 때문에 Restore없이 경로만 바꾸어 사용할 수도 있음)
- Backup 종료 시점에 Absolute Fuzzy SCN을 Image Copy Header Block에 업데이트함
→ 이 때문에 Image Copy본은 Tape 백업이 지원되지 않음
1. Physical Backup
<Tab Ⅱ-1-3> Server-Managed Backup (RMAN)
set serveroutput on
declare
scn number(12) := 0;
scnmax number(12) := 0;
begin
for f in (select * from v$datafile) loop
scn := dbms_backup_restore.scandatafile(f.file#);
dbms_output.put_line('File ' || f.file# ||' absolute fuzzy scn = ' || scn);
if scn > scnmax then scnmax := scn; end if;
end loop;
dbms_output.put_line('Minimum PITR SCN = ' || scnmax);
end;
/
- Snapshot Backup을 이용한 복구
. Disk Split-Mirror 기법을 이용한 백업 솔루션에서 Begin/End Backup을 수행하지 않고 백업 받은
경우의 복구 방법
. Begin/End 없이 수행한 백업은 불완전 복구 시에 Online Fuzzy Bits이 Clear가 안되기 때문에
Resetlogs 옵션으로도 Open할 수 없음(ORA-01547: warning: RECOVER succeeded but OPEN
RESETLOGS would get error below)
. End Of Redo Marker(Current Redo), End Crash Recovery Marker(End Of Crash Recovery), Absolute
Fuzzy SCN 적용 시에는 가능
. dbms_backup_restore.scandatafile Procedure를 이용하여 RMAN처럼 백업 데이터파일 Header에
Absolute SCN을 생성
. 불완전 복구 시 Absolute Fuzzy SCN까지 Redo Record를 적용하면 Resetlogs 옵션으로 Open 가능
- 12 -
II. Backup Types
Direct Path API
External Table API
Oracle_ Loader
Metadata API:
DBMS_METADATA
Oracle_ DataPump
expdp impdp Enterprise Manager
Data Pump
DBMS_DATAPUMP Data/Metadata Movement Engine
Other Clients: (Data Mining, etc)
Write Blocks
Direct Path
Generate SQL Commands
Dump File
Export
Export Oracle Server
Read Blocks
Buffer Cache
Manager
SQL Command Processing
Two-Task Common
(TTC)
TTC Buffer
Evaluating Buffer
Buffer Cache
Oracle Server
2. Logical Backup
- Oracle Utility(Export, Data Pump Export 등)를 사용하여 테이블이나 Stored Procedure 등과
같은 논리적인 데이터를 뽑아서 Binary File로 저장하는 백업방식
. Data를 백업 하지만 백업 시 데이터의 위치(rowid)는 기록하지 않음
- 특징
. 복구 후에는 데이터의 위치(rowid)가 바뀜
. Logical Backup은 일반적으로 Physical Backup의 보완수단으로 사용됨
. Export 하는 동안 Data Block의 손실을 발견할 수 있음
. 이 기종 또는 다른 버전의 DB로 Migration 작업을 할 수 있음
. 서로 다른 DB User간 Data Migration 작업을 할 수 있음
. 일부 테이블만 복구해야 하는 상황일 때 복구작업이 용이
. Physical Backup 보다 적은 공간을 차지함
<Fig Ⅱ-2-1> Exp Architecture
<Fig Ⅱ-2-2> Data Pump Architecture
Logical Backup
- 13 -
III. Internal Recovery Structures 1. SCN
- Database의 Commit 버전을 나타내는 Structure
. System Change Number 또는 System Commit Number
. Read Consistency(Snapshot Query)와 복구를 위한 용도(Redo Log)로 사용
. SCN은 Transaction이 Commit될 때 Redo Log에 저장됨
. SCN은 또한 Control File이나 Data File Header 등 여러 Data Structure에 사용
. Transaction Commit시에만 증가(Commit SCN)하는 것이 아니라 내부적인 작업으로도 증가
- 분산 DB 환경의 SCN
. SCN은 1씩 증가하지만 중간에 값이 건너 뛸 수도 있음 (분산 DB, RAC 환경 등)
. 분산 Transaction(DB Link)에서는 SCN값이 낮은 쪽 Database가 높은 쪽 Database의 SCN에 맞춰짐
. RAC 환경에서는 각각의 Instance는 local SCN을 유지하고 관련된 모든 Instance를 위해 하나의
global SCN을 사용
. RAC환경에서 SCN 생성 알고리즘은 Lamport Scheme 방식(Default)이나 Broadcast on Commit
Scheme 방식을 사용
- SCN Format
. <SCN Wrap>.<SCN Base> (Eg : 0x0000.002cff6e)
. 크기는 48bit (6bytes)
. SCN Wrap (2bytes) : SCN Base에 해당되는 숫자가 4bytes 범위를 넘어설 때 증가
. SCN Base (4bytes) : 새로운 SCN이 할당될 때마다 증가
. SCN = (SCN_WRAP * 4294967290) + SCN_BASE
. 16384/sec로 534년 동안 생성될 수 있다. (248 =281474976710656, 약281조)
- SCN 조회
. 다음과 같이 Database의 CURRENT SCN을 조회
SQL> SELECT CURRENT_SCN FROM V$DATABASE;
SQL> SELECT DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER FROM DUAL;
. COMMIT SCN 조회 방법
SQL> SELECT MAX(ktuxescnw * POWER(2, 32) + ktuxescnb) FROM x$ktuxe;
SQL> insert into scn values (USERENV(‘COMMITSCN’));
. ORA_ROWSCN이라는 Pseudo Column을 조회하면 해당 Row가 속한 Block의 SCN값을 알 수 있음
. ROWDEPENDENCIES 옵션으로 테이블/클러스터를 생성하면 ORA_ROWSCN Column 으로
ROW 단위의 SCN(dscn)값을 알 수 있음
- SCN 변환 함수
. SCN_TO_TIMESTAMP(nSCN NUMBER) : SCN을 TIMESTAMP 정보 (3초 단위) 로 변경해주는 함수
. TIMESTAMP_TO_SCN(dTimestamp) : TIMESTAMP 정보 (3초 단위) 를 SCN으로 변경해주는 함수
. Oracle 9i 인 경우 SMON_SCN_TIME으로 SCN TIMESTAMP (5분 단위) 값을 구할 수 있음
SQL> SELECT TIME_DP TIMESTAMP, SCN_WRP*4294967296+SCN_BAS SCN FROM
SMON_SCN_TIME;
SCN (System Change Number)
- 14 -
III. Internal Recovery Structures 2. Change Vector
- 단일 Data File Block의 변경사항에 대한 Vector 정보
. 1개 이상의 Change Vector가 모여 Redo Record를 구성
- 특징
. Oracle은 Physical한 Block 상태 정보(DBA,SCN,SEQ)와 Logical한 Block 동작 정보(Opcode)로
Data Block의 변경사항을 기록 (Physio-Logical Model)
. Change Vector는 Data Block Buffer가 수정되기 전에 생성 (Write Ahead Log) 복구 작업 시 Oracle은 Change Vector를 읽고 해당 Block에 변경 사항을 적용
Field Description
TYP
Change Type 0 KCOCT_NORM normal change vector 1 KCOCT_NEW completely new contents and usage of a block 2 KCOCT_DLOG delayed logging change included 3 KCOCT_IMAGE block image for hot backup - not a change 4 KCOCT_CLEAR empty block image - just to new the block 5 KCOCT_INVLD invalidation redo from UNRECOVERABLE direct path 6 KCOCT_MARKER media recovery marker 7 KCOCT_MAX max type for detecting corrupt redo logs
CLS
Block Class (블록 종류) : X$.BH.CLASS 1 Data Block 2 Sort Block 3 Deferred Undo Segment Blocks 4 Segment Header Block (Table) 5 Deferred Undo Segment Header Blocks 6 Free List Blocks 7 Extent Map Blocks 8 Space Management Bitmap Blocks 9 Space Management Index Blocks 10 Unused 11 + 2r Segment Header for Undo Segment r 12 + 2r Data Blocks for Undo Segment r
AFN Absolute File Number (데이터파일 ID): V$DATAFILE.FILE#
DBA Relative Database Block Address (데이터파일 블록 주소)
OBJ Object ID : DBA_OBJECTS.OBJECT_ID
SCN System Change Number (수정되기 전 Block의 SCN)
SEQ Sequence Number : Block의 Sequence 번호. 해당 Block에 변경이 생길때마다 증가한다. Block SCN값과 Block Seq#로 Block의 Version이 결정된다.
OP Redo Operation Code (부록 참조) : Logical한 Operation Code 값
블록 SCN이 scn:0x0000.00b1302 이고 블록 주소가 0x0040f0ba 인 블록의 1번 row slot에 1개 row가 insert 됨
DBA:0x0040f0ba
SCN:0x0000.00b1302
ROW:1
DBA:0x0040f0ba
SCN:0x0000.00b14af
ROW:1
col 0: [ 4] c3 02 4e 22
col 1: [ 3] 4c 53 54
Change #1
Before After
<Fig Ⅲ-2-1> Change Vector
<Tab Ⅲ-2-1> Change Vector Dump
Change Vector
- 15 -
III. Internal Recovery Structures 3. Redo Record
- Redo Record는 Change Vector의 묶음
. Redo Record는 Database에 대한 원자적 변경(atomic change)을 의미
- 특징
. 한 개의 Transaction은 여러 개의 Redo Record를 생성할 수 있음
. Change Vector를 Redo Record로 묶는 이유는 Redo Record의 모든 Change Vector가 전부
적용되거나 아니면 전혀 적용되지 않도록 하기 위함임
- Redo Record 생성 순서
① Process의 PGA내에 Redo Record가 만들어 진다.(zero-copy redo 기능을 이용하면
PGA대신 shared pool(private strands)에 Redo Record가 만들어짐 _log_private_parallelism = true)
② Redo Record는 Redo Log Buffer에 Copy됨
③ Buffer Cache 내 Data Block에 Redo Record의 Change Vector가 적용됨
블록 SCN이 0x0000.00b1302 이고 블록 주소가 0x0040f0ba 인 블록의 1번 row slot에 1개 row가 insert 됨
DBA:0x0040f0ba SCN:0x0000.00b1302 ROW:1
DBA:0x0040f0ba SCN:0x0000.00b14af ROW:1 col 0: [ 4] c3 02 4e 22 col 1: [ 3] 4c 53 54
Change #1
블록 SCN이 0x0000.00b146b 이고 블록 주소가 0x008003c4 인 UNDO블록에 블록주소가 0x0040f0ba 인 데이터 블록의 1번 row slot에 대한 Delete Row Piece Undo record가 생성됨
DBA:0x008003c4 SCN:0x0000.00b146b ROW:1
DBA:0x008003c4 SCN:0x0000.00b14af UNDO: code:DRP DBA:0x0040f0ba slot:1
Change #2
insert into emp values (17733,’LST’);
Header Thread:1 RBA: 0x000010.00000002.0010 LEN: 0x01dc VLD: 0x0d SCN: 0x0000.000b14af SUBSCN: 1 10/22/2010 18:03:56
Body
<Fig Ⅲ-3-1> Redo Record
Redo Record
- 16 -
III. Internal Recovery Structures 3. Redo Record
Field Description
Thread Thread : Thread Number (V$LOG.THREAD#)
RBA Redo Byte Address (Redo Record의 주소) : 10bytes로 구성
Format 은 <Redo Log Sequence>.<Redo Log Block>.<Block Offset>
LEN Length of record in bytes (Redo Record Header를 포함한 Redo Record 크기)
VLD
Valid byte in record indicator (Redo Record 종류 및 Header 크기 결정)
KCRVOID 0 The contents are not valid
KCRVALID 1 Includes change vectors
KCRDEPND 2 Includes commit SCN
KCRVOID 4 Includes dependent SCN
KCRNMARK 8 New SCN mark record. SCN allocated exactly at this point in the redo log
by this instance
KCROMARK 16 Old SCN mark record. SCN allocated at or before this point in the redo.
May be allocated by another instance
KCRORDER 32 New SCN was allocated to ensure redo for some block would be ordered by
inc/seq# when redo sorted by SCN
SCN System Change Number (새로 생성된 SCN)
SUBSCN 순번, Date and Time of Change
<Tab Ⅲ-3-1> Redo Record Header
- 17 -
III. Internal Recovery Structures 4. Redo Log
- Redo Record가 SCN 순으로 저장되는 File
- 특징
. Redo Log가 Full이 되면 다음 Redo Log로 Switch됨
. Archive Mode로 운영 중인 DB는 Redo Log가 Switch 될 때 해당 Redo Log를 Archive Log File로
Copy
. Redo Log는 Thread Number와 Log Sequence Number로 구분
. Log Sequence Number는 각각의 Thread에 독립적으로 생성되고 Log Switch도 각각 발생
. Redo Log는 Thread당 최소한 2개 이상의 Group으로 구성
. Redo Log는 각 Group에 Member를 추가함으로 Multiplexing 구성을 할 수 있음
. Redo Log에는 low SCN, next SCN 정보가 있다. low SCN은 해당 Redo Log에 저장된 첫번째
Redo Record의 SCN값이고 next SCN은 다음 Redo Log의 low SCN값과 같음
. Current Redo Log일 경우 next SCN은 무한대로 표시(0xffff.ffffffff)
- Redo Log 생성 순서
. 각 Instance마다 전용 Redo Log가 있음
. SGA에는 Redo Record가 저장되는 Redo Buffer가 있음
Redo Log Buffer는 Redo Log Block으로 구성되어있고 Disk로 Flush되고 난 후에는 재사용됨
. Buffer Cache 내 Data Block에 Redo Record의 Change Vector를 적용
① PGA의 Redo Record는 SGA에 Copy됨.
② 해당 Block의 첫번째 Redo Record 위치를 나타내는 Offset이 계산되어 Redo Block Header에
저장
③ PGA Redo Record의 내용이 Data Block에 반영되고 반영이 정상적이면 Redo Record Header에
Valid Mark를 함
④ LGWR가 Redo Log Block Header에 Block#, Sequence#와 Checksum 정보를 Update함
⑤ LGWR가 Redo Block의 Set을 주기적으로 Flush함
⑥ LGWR는 항상 Redo Block을 Multiple하게 Write하고 Redo Log File에 Append 시킴
Group 1 Group 2 Group 3
Log Buffer
PGA Server Process
PGA Server Process
PGA Server Process
LGWR
Strand 1
Strand 2
<Fig Ⅲ-4-1> Redo Architecture
Redo Log
- 18 -
III. Internal Recovery Structures 4. Redo Log
Block Body
File Header Block : File Type, Block Size, Number Of Blocks, Magic
Block Header (16 bytes) : Signature, Block Number, Sequence#, Offset, Checksum
Redo Log Header : DB ID, DB Name, Thread#, Sequence#, Low SCN, Next SCN
Block Header (16 bytes) : Signature, Block Number, Sequence#, Offset, Checksum
Block Body
Block Header (16 bytes) : Signature, Block Number, Sequence#, Offset, Checksum
Redo Record Header
Redo Record Body : Change Vectors
Redo Record Header
Redo Record Body : Change Vectors
Redo Record Body : Change Vectors
Redo Record Header
Redo Record Body : Change Vectors
512 bytes or 1024 bytes
512 bytes or 1024 bytes
512 bytes or 1024 bytes
512 bytes or 1024 bytes
- Redo Log Structure
. File Header : Redo Block Size
512 bytes (AIX, Sun, Linux, Windows, Irix, Open VMS, DG/UX)
1024 bytes (HP-UX,Tru64)
2048 bytes (SCO Unix, Reliant Unix)
4096 bytes (MVS, MPE/ix),
Number Of Blocks - File Header Block을 제외한 Redo Log File의 총 Block 수
. Redo Log Header : DB Name, Thread, Log Sequence Number, DB Version, Low SCN, High SCN
. Block Header : Block Number,
Sequence#,
Offset - 해당 Block의 첫 Redo Record 위치를 표시
해당 Block에 Redo Record가 없으면 00,
Checksum (XOR),
크기는 16bytes
. Block Body : Redo Record Header, Redo Record Body (Change Vectors)
- Redo Log Dump Command
SQL> ALTER SYSTEM dump logfile 'filename' ... rba min <seqno> <blkno>
rba max <seqno> <blkno>
dba min <filno> <blkno>
dba max <filno> <blkno>
time min <ub4>
time max <ub4>
layer <word> opcode <word>
<Fig Ⅲ-4-2> Redo Log File
- 19 -
III. Internal Recovery Structures 4. Redo Log
LOG FILE #2: (name #2) C:\ORACLEXE\APP\ORACLE\FLASH_RECOVERY_AREA\XE\ONLINELOG\O1_MF_2_6BNYXGJW_.LOG Thread 1 redo log links: forward: 0 backward: 1 siz: 0x19000 seq: 0x00000015 hws: 0x1 bsz: 512 nab: 0xffffffff flg: 0x8 dup: 1 Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.000fb682 Low scn: 0x0000.0010583b 11/10/2010 08:19:12 Next scn: 0xffff.ffffffff 01/01/1988 00:00:00 FILE HEADER: Compatibility Vsn = 169869568=0xa200100 Db ID=2612706299=0x9bbabbfb, Db Name='XE' Activation ID=2612712699=0x9bbad4fb Control Seq=356=0x164, File size=102400=0x19000 File Number=2, Blksiz=512, File Type=2 LOG descrip:"Thread 0001, Seq# 0000000021, SCN 0x00000010583b-0xffffffffffff" thread: 1 nab: 0xffffffff seq: 0x00000015 hws: 0x1 eot: 1 dis: 0 reset logs count: 0x2b9b1c3d scn: 0x0000.000341ab Low scn: 0x0000.0010583b 11/10/2010 08:19:12 Next scn: 0xffff.ffffffff 01/01/1988 00:00:00 Enabled scn: 0x0000.000341ab 10/05/2010 10:13:17 Thread closed scn: 0x0000.0010583b 11/10/2010 08:19:12 Disk cksum: 0x510f Calc cksum: 0x510f Terminal Recovery Stop scn: 0x0000.00000000 Terminal Recovery Stamp 01/01/1988 00:00:00 Most recent redo scn: 0x0000.00000000 Largest LWN: 0 blocks Miscellaneous flags: 0x0 Thread internal enable indicator: thr: 0, seq: 0 scn: 0x0000.00000000
- Redo Log Header Dump
. 각 Redo Log File마다 두개의 Block Header가 있음
. 첫 번째 Block은 File Block Header로 File Type, Block 크기, Block수 정보가 있음
. 두 번째 Block은 Redo Log Header Block으로 DB Name, Thread, Log Sequence Number, DB
Version, Low SCN, High SCN 등의 정보가 있음
- Redo Log Header Dump Command
. ALTER SESSION SET EVENTS ‘immediate trace name redohdr level 10’;
level 1 : Control File Redo Log Entry
level 2 : level 1 + generic file header
level 3 or greater : level 2 + log file header
level 10 : most commonly used
Field Description
Database Name DB Name
Thread Thread Number (V$LOG.THREAD#)
Sequence number Log Sequence Number (V$LOG.SEQUENCE#)
DB Version DB Compatibility Version
Low SCN 첫 번째 Redo Record의 SCN 번호
Next SCN 다음 Redo Log의 Low SCN 번호
seq# DB Version DB Name
Next SCN Low SCN
<Fig Ⅲ-4-3> Redo Log Header Dump
<Fig Ⅲ-4-4> Redo Log Header Binary Dump
<Tab Ⅲ-4-1> Redo Log Header Dump
- 20 -
III. Internal Recovery Structures 5. Control File
- Database Entry, Checkpoint Progress, Redo Thread, Log File, Data File, Backup 정보가 저장된 File
- Control File Dump Command
. ALTER SESSION SET EVENTS 'immediate trace name controlf level 9';
level 1 : Generic File Header
level 2 : Level 1 + Database Info + Checkpoint Progress Records
level 3 or greater : level 2 + reuse record section
level 10 : Binary Dump
Record Section Description
File Header (V$CONTROLFILE)
- Seq# : Control File Version으로 Control File Header가 Update될 때마다 증가됨 - Compatibility Vsn : DB Compatibility Version - DB ID : Database ID. Database 생성시 설정되고 모든 Database File Header에 기록됨 (File이 같은 Database Member인지 확인) - File size (V$CONTROLFILE.FILE_SIZE_BLKS) : Block 수 (File Header 제외) - Blksize ( $CONTROLFILE.BLOCK_SIZE): Control File Block Size (Control File 크기 = File size * Blksize) - File Type = 1 (Control File)
Database Entry (V$DATABASE)
- Database flags : Database 상태 정보(부록 참조) - Incmplt recovery scn : Incomplete Recovery시 마지막 적용된 SCN - Resetlogs scn : Resetlogs Open 시점 SCN - Prior Resetlogs scn : Prior Resetlogs Open 시점 SCN - Database checkpoint (thread,scn) : Database Checkpoint SCN (가장 낮은 Thread Checkpoint) - Threads . #Enabled : Enable 된 Thread 수 . #Open : Open된 Thread 수 - enabled thread : enabled thread bitvec. Checkpoint SCN이 할당되었을때 enable상태의 thread를 표시하는 mask - Max log members : 최대 Redo Log Member 수 - Max data members : 최대 Data File Member 수 (현재는 1 이고 미래를 위해 예약) - Force scn (force archiving SCN) : Archive되기 전 scn - Activation ID : DB를 Activation(resetlogs 또는 Standby DB Activation)했을 때 부여된 ID - Controlfie Checkpointed at scn : Control File Checkpoint SCN
Checkpoint Progress Records (X$KCCCP)
- dirty (X$KCCCP.CPDRT) : Dirty Buffer 수 - low cache rba : Dirty Buffer의 가장 낮은 Redo Record의 RBA. Instance Recovery시 이 RBA의 Redo Record 부터 복구함. Dirty Buffer가 없으면 무한대(0xffffffff.ffffffff.ffff)로 표시 - on disk rba : Redo Log File(DISK)에 Write된 가장 최근 Redo Record의 RBA Instance Recovery는 “low cache rba”부터 시작하여 “on disk rba”까지 복구함 - on disk scn : on disk rba의 SCN - resetlogs scn : Resetlogs SCN - heartbeat (X$KCCCP.CPHBT) : Checkpoint Heartbeat. 매 3초 마다 증가 - mount id (X$KCCCP.CPMID) : Thread가 Mount될 때 부여된 고유한 ID
Redo Thread Records (V$THREAD)
- status : Thread 상태 정보 - #logs : Redo Log Group 수 - first : Min Redo Log Group# - last : Max Redo Log Group# - current : Current Redo Log Group - last used seq# : 현재 Log Sequence Number - enabled at scn : Thread Enable시 SCN - disabled at scn : Thread Disable시 SCN - Checkpointed at scn : Thread Checkpoint SCN - rba : Thread Checkpoint 시 RBA (보통 Current Redo Log의 첫 번째 Redo Record RBA) - enabled threads : enabled thread bitvec - log history : Redo Log History 정보 보관 개수
<Tab Ⅲ-5-1> Control File Dump
Control File
- 21 -
III. Internal Recovery Structures 5. Control File
Record Section Description
Log File Records
- redo log links . forward : The Number of The Next Valid Online Redo Log . backward : The Number of The Previous Valid Online Redo Log - siz : Block 수 - seq : Log Sequence Number - bsz : Log Block Size (Redo Log File Size = siz * bsz) - nab (Next Available Block) : Next Available Block that LGWR will use to write the information. Current Log일 경우 무한대로 설정 (0xffffffff) - flg 0X0001 : set if log file is spooled or archived 0X0002 : set if no more allocation may be done in the log 0X0004 : USE ME flag which indicates to use it to be the next current log 0X0008 : Current Log 0X0010 : set if log is being cleared - dup : Redo Log Member 수 - Prev scn : 이전 Log File의 Low SCN - Low scn : Log File에 저장된 첫번째 Redo Record의 SCN - Next scn : 다음 Log File의 Low SCN
Data File Records (V$DATAFILE)
- status : Data File의 상태 정보 KCCFEFDB 0x0001 file read-only, plugged from foreign DB KCCFEONL 0x0002 file is ONLine KCCFERDE 0x0004 ReaDing is Enabled KCCFECGE 0x0008 ChanGing is Enabled KCCFEMRR 0x0010 Media Recovery Required KCCFEGEM 0x0020 Generate End hot backup Marker at next open KCCFECKD 0x0040 File record generated by check dictionary KCCFESOR 0x0080 Save Offline scn Range at next checkpoint KCCFERMF 0x0100 Renamed Missing File KCCFEGOI 0x0200 Generate Off-line Immediate marker KCCFECUV 0x0400 Checkpoint by instance where UnVerified KCCFEDRP 0x0800 offline to be DRoPped KCCFEWCC 0x1000 Was at Clean Chkpt: clean up to ctrlfile chkpt KCCFEODC 0x2000 Online at Dictionary Check if read/only tblspc KCCFEDBR 0x4000 entry created by DBMS_BACKUP_RESTORE KCCFETRO 0x8000 Transition Read Only 0xe = 0x8 | 0x4 | 0x2 (Change/Write | Read | Online ) : Normal 0x1c = 0x8 | 0x4 | 0x10 (Change/Write | Read | MR ) : Media Recovery. - unrecoverable scn : Nologging(Unrecoverable) 옵션을 사용한 시점 SCN - Checkpoint cnt : Checkpoint Counter. Checkpoint 발생시 마다 증가 Hot Backup 상태에서도 증가 - Stop scn : Stop SCN. . 정상적인 Shutdown(Abort 제외)을 하면 Data File Header의 Checkpoint SCN이 Stop SCN으로 Copy되고 DB를 Open하면 무한대로 설정됨 . Tablespace를 Offline하면 Data File Header의 Checkpoint SCN이 Stop SCN으로 Copy되고 Online하면 다시 무한대로 설정됨 . Recovery시에는 Stop SCN까지 Redo Record를 적용하면 복구가 종료됨 - Offline scn : Offline SCN. Offline Range(Offline – Online) 시작 시점 SCN. Offline Range가 생겼을 때 Data File이 Offline 상태로 변경된 시점 SCN. Offline Range(Offline – Online) 종료 시점에 업데이트 됨(Stop SCN이 Offline SCN으로 바뀌고 Stop SCN은 무한대로 설정됨) - prev_range : 이전 Offline Range(Offline – Online) 생성 횟수 - Online Checkpointed at scn : Online SCN. Offline Range(Offline – Online) 종료 시점 Offline 상태에서 Online으로 바뀐 시점 SCN. Data File의 Offline Range 구간 동안은 Redo 적용이 Skip됨 ※ Control File에는 Offline Range 정보가 있기 때문에 Data File 백업 이후 Normal Offline 이나 Read Only로 상태 변환된 Data File에 대해 Media Recovery 작업을 적절하게 수행 할 수 있음 - Hot Backup end marker scn : End Backup 시점 SCN. Recovery 시 최소한 이 시점까지는 복구를 해야 Resetlogs로 Open이 가능
<Tab Ⅲ-5-1> Control File Dump (Continued)
- 22 -
III. Internal Recovery Structures 6. Data File
V10 STYLE FILE HEADER: Compatibility Vsn = 169869568=0xa200100 Db ID=2612706299=0x9bbabbfb, Db Name='XE' Activation ID=0=0x0 Control Seq=360=0x168, File size=11520=0x2d00 File Number=2, Blksiz=8192, File Type=3 DATA Tablespace #1 - UNDO rel_fn:2 Creation at scn: 0x0000.000014a0 02/07/2006 22:10:36 Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0 reset logs count:0x2b9b1c3d scn: 0x0000.000341ab reset logs terminal rcv data:0x0 scn: 0x0000.00000000 prev reset logs count:0x22adbb36 scn: 0x0000.00000001 prev reset logs terminal rcv data:0x0 scn: 0x0000.00000000 recovered at 11/09/2010 06:50:24 status:0x4 root dba:0x00000000 chkpt cnt: 72 ctl cnt:71 begin-hot-backup file size: 0 Checkpointed at scn: 0x0000.0010ecb0 11/11/2010 08:19:56 thread:1 rba:(0x16.2.10) enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000 ..... Backup Checkpointed at scn: 0x0000.00000000 thread:0 rba:(0x0.0.0) enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000 ..... 00000000 00000000 00000000 00000000 00000000 00000000 External cache id: 0x0 0x0 0x0 0x0 Absolute fuzzy scn: 0x0000.00000000 Recovery fuzzy scn: 0x0000.00000000 01/01/1988 00:00:00 Terminal Recovery Stamp 01/01/1988 00:00:00 Platform Information: Creation Platform ID: 7 Current Platform ID: 7 Last Platform ID: 7
Field Description
Creation at scn Creation SCN : Data File 생성 시점 SCN
Backup taken at scn Backup Checkpoint SCN : Begin Backup 수행 시점 SCN
status
Data File 상태 정보 KCVFHHBP 0x01 hotbackup-in-progress on file (fuzzy file) KCVFHOFZ 0x04 Online FuZzy because it was online and db open KCVFHMFZ 0x10 Media recovery FuZzy - file in media recovery KCVFHAFZ 0x40 Absolutely FuZzy - fuzzyness from file scan KCVFHBCP 0x100 Bad Checkpoint - no enabled thread bitvec KCVFHFMH 0x200 Freshly Munged Header. resetlogs not finished KCVFHXCH 0x400 eXternally CacHed by operating system KCVFHZBA 0x800 Zeroed Blocks Allowed KCVFHPCP 0x1000 Proxy Copy in Progress KCVFHRBS 0x2000 does kcvfhrdb point to bootstrap$ ? KCVFHRTA 0x4000 Real-time apply (RTA) fuzzy KCVFHL0C 0x8000 Incremental level 0 copy
chkpt cnt Checkpoint Count : Checkpoint 수행 횟수. DB Startup시 Control File의 Checkpoint Count와 비교하여 정합성 점검을 한다.
Checkpointed at scn Checkpoint SCN : Checkpoint 수행 시점 SCN. Checkpoint SCN이전에 해당 Data File에 대해 변경을 일으킨 Block은 Data File에 모두 Write되었음을 나타냄. Checkpoint SCN은 Control File에도 복제됨
Absolute fuzzy scn Absolute Fuzzy SCN (V$DATAFILE_COPY.ABSOLUTE_FUZZY_CHANGE#) : 해당 Data File내 가장 높은 Block SCN (RMAN 백업 수행 시)
Recovery fuzzy scn Recover Fuzzy SCN (V$DATAFILE_COPY.RECOVERY_FUZZY_CHANGE#) : 해당 Data File의 Recovery 작업으로 수행된 가장 높은 SCN
- Data File Status, Checkpoint, Fuzzy Bits 정보가 저장된 영역
- Data File Header Dump Command
. ALTER SESSION SET EVENTS 'immediate trace name file_hdrs level 10';
level 1 : Control File's Data File Entry
level 2 : level 1 + generic file header
level 3 or greater : level 2 + Data File header
level 10 : most commonly used
<Fig Ⅲ-6-1> Data File Header Dump
<Tab Ⅲ-6-1> Data File Header Dump
Data File Header
- 23 -
III. Internal Recovery Structures 6. Data File
Fuzzy Bits Description
Hot Backup Fuzzy Bit (0x01)
- Begin Command 시 Setting되며 End Backup 시 Clear 됨. - Hot Backup을 수행시에는 해당 Data File의 Checkpoint SCN을 고정시킴 이때 수행한 Data File의 백업본에는 Checkpoint SCN보다 높은 SCN의 Block이 백업 될수 있음 그러므로 백업된 Data File은 Fuzzy상태라고 할 수 있음 - Media Recovery시에는 End Of Backup Marker Redo 적용 시 (Hot Backup End Marker SCN) Clear됨
Online Fuzzy Bit (0x04)
- Database가 Open되고 Data File이 Online 상태가 되면 설정됨 - Data File은 Checkpoint가 발생한 이후에도 Online상태에서는 변경된 Block이 있을 수 있음 → 그래서 Online 상태의 Data File은 Fuzzy상태라고 할 수 있음 - Database를 정상적으로 Shutdown 하거나 Tablespace를 정상 Offline또는 Read Only로 상태를 변경시킬 때 Clear됨 - Crash Recovery 종료 시점에 End Crash Recovery Marker Redo가 생성되고, Media Recovery시에 Online Fuzzy Bit을 Clear하는데 사용됨
Media Recovery Fuzzy Bit (0x10)
- Media Recovery가 시작될 때 설정되고, Recovery가 정상적으로 끝나게 되면 Clear됨 - Media Recovery시 Archived Log에 있는 Redo Record를 Data File에 즉시 반영 하는 것이 아니고 Recovery Buffer에 읽은 후 반영되기 때문에 변경사항의 일부 는 Buffer에 존재할 수 있음 → 그래서 Media Recovery시 Redo Apply중인 Data File은 Fuzzy 상태임 - 복구 중인 Data File의 Checkpoint SCN이 Recovery Fuzzy SCN값 이상이 되면 Clear됨
Absolute Fuzzy Bit(0x40)
- RMAN 백업 수행 시 해당 Data File의 백업본에 설정됨 - 백업 수행은 일정 시간이 소요되기 때문에 백업 수행 중 변경된 Block이 백업 될 수 있음 - 백업 시작 시점의 Checkpoint SCN보다 높은 Block SCN을 갖는 Block이 백업될 때 백업본의 Data File은 Fuzzy 상태가 됨 - 백업 시작 시점의 Checkpoint SCN보다 높은 Block SCN을 같는 Block중 가장 높은 SCN을 Absolute SCN이라고 함 - Media Recovery 수행 시 RMAN으로 Restore된 Data File의 Checkpoint SCN이 Absolute SCN 이상 값으로 되면 Clear됨
Real Time Apply Fuzzy Bit (0x4000)
- Standby DB가 Real Time Apply 모드에서 운영 시 설정됨 - 보통 Media Recovery Fuzzy Bit과 같이 설정됨 - Real Time Apply Fuzzy Bit이 Clear 안된 상태에서는 Standby DB를 Open할 수 없음
- Data File이 Inconsistency 상태라는 것을 Data File Header에 표시하는 Bit 정보
. Data File의 Checkpoint SCN 이 후 해당 Data File에 변경사항이 있음을 나타냄
. 해당 Data File의 Checkpoint SCN보다 높은 SCN을 갖고 있는 Block이 있다는것을 의미
- 특징
. Fuzzy 상태의 범위는 Checkpoint SCN부터 해당 Fuzzy SCN까지 임
. 일부 Fuzzy Bit은 Fuzzy 상태가 Clear될 때 Fuzzy Marker Redo Record를 생성
. Media Recovery시에 Fuzzy Marker Redo Record를 적용함으로 Fuzzy Bit이 Clear됨
(End Of Backup Marker, End Crash Recovery Marker)
. Fuzzy Bits이 설정된 상태에서는 Database를 Resetlogs로도 Open할 수 없음
<Tab Ⅲ-6-2> Fuzzy Bits
Fuzzy Bits
- 24 -
III. Internal Recovery Structures 7. Checkpoint
` `
MAIN
AUX
MAIN
AUX
MAIN
AUX
MAIN
AUX
LRU-XO
MAIN
AUX
LRU
MAIN
AUX
LRU-W
MAIN
AUX
LRU-XR
MAIN
AUX
LRU-P
MAIN
AUX
Recovery Ckpt Q
MAIN
AUX
File Ckpt Q
MAIN
AUX
Thread Ckpt Q
MAIN
AUX
DB Buffer Cache
SGA
List Description
LRU Replacement List
LRU-W Dirty List
LRU-P Ping Buffers
LRU-XR Buffers to be written for reuse block range
LRU-XO Drop/Truncate Buffers
Thread Checkpoint Queue
Thread Checkpoint Buffers
File Checkpoint Queue
File Checkpoint Buffers
Recovery Checkpoint Queue
Buffers for Performing Recovery
Redo Log Tail Of Log
Transactions
Checkpoint Position 1 Checkpoint Position 2 Checkpoint Position 3
Checkpoint Q 2 Checkpoint Q 1
Working Set
Data File IO Slots DBWR
kcbbxsv
kcfqueuewr
High Priority Write Slots
Medium Priority Write Slots
Low Priority Write Slots
Free IO Slots
- Buffer Cache에 있는 변경된 Block(Dirty Block)을 Data File로 Write하고 Control File과
Data File Header를 Update하는 Database의 Event
- 특성
. Checkpoint가 일어난 후 Checkpoint 발생 시점 이전의 Redo Log Record는 Instance Recovery시
더 이상 사용되지 않음
- Checkpoint 동작 순서
① checkpoint RBA (대부분 current RBA)정보를 얻음
② checkpoint RBA이하의 Dirty Block을 Mark함
③ DBWR에 넘김
④ DBWR가 이 Mark된 Dirty Block을 Data File에 Write함
⑤ CKPT 프로세스가 Control File과 Data File Header를 수정
<Fig Ⅲ-7-1> DBWR Architecture
<Fig Ⅲ-7-2> Checkpoint Position
Checkpoint
- 25 -
III. Internal Recovery Structures 7. Checkpoint
Checkpoint Type
Checkpoint Event Description
Database Checkpoint
Alter system checkpoint [global] Alter database begin backup Alter database close Shutdown (except abort)
- 모든 Instance의 모든 Dirty Buffer가 Write됨 (Full Checkpoint) - Control File과 Data File Header가 수정됨 - Statistics updated : . DBWR checkpoints . DBWR thread checkpoint buffers written . DBWR checkpoint buffers written
Thread Checkpoint
Alter system checkpoint local - 해당 Instance의 모든 Dirty Buffer가 Write됨 - Single DB일 경우 는 Database Checkpoint와 같음 - Control File과 Data File Header가 수정됨 - Thread Checkpoint SCN중 가장 낮은 Checkpoint SCN이 Database SCN이 된다. - Statistics updated : . DBWR checkpoints . DBWR thread checkpoint buffers written . DBWR checkpoint buffers written
Data File Checkpoint
Alter tablespace offline Alter tablespace begin backup Alter tablespace read only
- 모든 Instance의 해당 File의 Dirty Buffer가 Write됨 - Control File과 Data File Header가 수정됨 - Statistics updated . DBWR checkpoints . DBWR checkpoint buffers written . DBWR tablespace checkpoint buffers written
Log Switch Checkpoint
Normal Log Switch Alter system switch logfile
- 해당 Instance의 Dirty Buffer가 Write됨 - Oracle 8i 이전 버전은 Thread Checkpoint와 같음 - Control File과 Data File Header가 수정됨 - Thread Checkpoint SCN중 가장 낮은 Checkpoint SCN이 Database SCN이 됨 - Data File이 50개 이상인 경우 alert.log에 Checkpoint Complete 메시지 후 Background로 Checkpoint가 수행됨 - Statistics updated : . DBWR checkpoints . DBWR checkpoint buffers written . background checkpoints started . background checkpoints completed
Incremental Checkpoint
Every 3 second – The most current RBA – log_checkpoint_timeout – log_checkpoint_interval – fast_start_mttr_target – fast_start_io_target – 90% of the size of the smallest online redo log file
- 빠른 Instance Recovery를 위해 수행 - Checkpoint Queue에 있는 일부 Dirty Block들이 Write됨 - Data File Header의 Checkpoint SCN은 수정되지 않고 Control File의 Checkpoint position만 증가 - Statistics updated . DBWR checkpoint buffers written
Object Checkpoint
Drop table Drop index Truncate table
- 모든 Instance의 해당 Object의 Dirty Buffer가 Write됨 - Statistics updated . DBWR checkpoints . DBWR object drop buffers written
Parallel Query Checkpoint
Parallel Query - 모든 Instance의 해당 Object의 Dirty Buffer가 Write됨 - Parallel Query 시 Direct Read IO때문에 발생 - Statistics updated . DBWR checkpoints . DBWR checkpoint buffers written
<Tab Ⅲ-7-1> Checkpoint Types
- 26 -
III. Internal Recovery Structures 8. Diagnostic Facilities
- Oracle Event Dump 종류
. Immediate Dump Events : Dump를 즉시 생성함 (File Dump, System State Dump, Process State Dump)
. On-Error Dump Events : Error 발생시에만 Dump 생성 (Error Stack)
. Change Behavior Events : Oracle Server의 동작을 제어함 (Workaround 설정, Enable Hidden Features)
. Trace Events : Running 중인 Process의 진행 정보를 생성 (SQL Trace, Recovery 진행 정보)
- DB Hang 발생시 Dump 생성 법
. Hang Analyze Dump 생성
① Command
$ sqlplus '/ as sysdba‘ (sqlplus 접속이 안될 시 sqlplus -prelim '/ as sysdba‘ )
SQL> oradebug setmypid
SQL> oradebug unlimit
SQL> oradebug hanganalyze 3
Wait at least 60 second
SQL> oradebug hanganalyze 3
② Level
1-2 Only HANGANALYZE output, no process dump at all
3 Level 2 + Dump only processes thought to be in a hang (IN_HANG state)
4 Dump leaf nodes in wait chains
5 Dump all processes involved in wait chains
10 Dump all processes
. System State Dump 생성
① Command
$ sqlplus '/ as sysdba'
SQL> oradebug setmypid
SQL> oradebug unlimit
SQL> oradebug dump systemstate 266
Wait 90 seconds
SQL> oradebug dump systemstate 266
Wait 90 seconds
SQL> oradebug dump systemstate 266
② Level
1 Very basic process information only
2 process + session state objects
10 Most common level - includes state object trees for all processes. Includes "interesting" RAC resources in the trace (in RAC only)
11 In RAC level 11 includes a dump of any resources not on the freelist just after the "BUSY GLOBAL CACHE ELEMENTS" section
Level + 256 Adding 256 to the level will try to dump short stack info for each process when the enhancement described in Note 3797523.8 is present. Short stacks are produced reasonably quickly on Solaris and Linux but on other platforms including short stacks in dumps can take a very long time. Hence it is advisable to test if the overhead is acceptable before using this option.
Oracle Dump
- 27 -
III. Internal Recovery Structures 8. Diagnostic Facilities
. Error Stack Dump
① Command
SQL> oradebug setospid SPID → SPID는 문제가 있다고 판단되는 세션의 SPID (V$PROCESS.SPID)
SQL> oradebug unlimit
SQL> oradebug dump errorstack 3
② Level
0 Error stack only
1 Error stack and function call stack (if implemented)
2 As 1 plus the ProcessState
3 As 2 plus the context area (all cursors and current cursor highlighted)
- OS Block Dump
$ dd if=system01.dbf bs=8k skip=99 count=3 | od -xv > file.out
- Oracle file/block Dump
SQL> alter system dump datafile <file#> block <block#>;
SQL> alter system dump logfile ‘filename’;
SQL> alter system dump logfile ‘filename’ dba min <fileno> <blockno>
dba max <fileno> <blockno>;
SQL> alter system dump logfile ‘filename’ dba min <fileno>.<blockno>
dba max <fileno>.<blockno>;(9i이하)
SQL> alter system dump undo header <UndoName>;
SQL> alter system dump undo block <UndoName> xid <usn> <slot> <seq>
SQL> alter session set events 'immediate trace name controlf level 9';
SQL> alter session set events 'immediate trace name file_hdrs level 10';
SQL> alter session set events 'immediate trace name redohdr level 10';
- Heap Dump
. Immediate Dump
SQL> alter session set events 'immediate trace name heapdump level <n>';
Level
1 Top PGA
2 Top SGA
4 Top UGA
8 Current Call
16 User Call
32 Large Pool
. On Error Dump
SQL> alter session set events ‘<error#> trace name heapdump level <n>';
. Dump subheaps
SQL> alter session set events ‘immediate trace name heapdump_addr <addr>';
- Buffer Cache Dump
. Immediate Dump
SQL> alter session set events 'immediate trace name buffers level <n>';
Buffers <level> <level> <level>
Description Headers Brief Block Full Block
Block 1 2 3
and Latch lru 4 5 6
and users/waiters 8 9 10
. On Error Dump
event = “<error#> trace name buffers level <n>’”
Oracle Dump
- 28 -
III. Internal Recovery Structures 8. Diagnostic Facilities
- Library Cache Dump
. Command
SQL> alter session set events 'immediate trace name library_cache level <n>';
. Level
1 - include library cache statistics
2 - include library cache hash table
4 - include library cache handles and objects
8 - include dependencies, read-only dependencies, accesses, authorizations, translations,
schemas and data blocks
16 - include sizes for data blocks
32 - include heap dumps for data blocks . On Error Dump
- Row Cache Dump
. Command
SQL> alter session set events 'immediate trace name row_cache level <n>';
. Level
1 row cache statistics
2 contains the hash table histogram
8 contains the object structure
- DBVERIFY
. DB Block의 Consistency를 점검하는 Utility
. Redo Log File은 점검할 수 없고 Data File만 점검
. Block의 Head와 Tail을 점검하여 비정상(Split Block)이면 해당 Block을 다시 읽고,
다시 읽었을 때 정상이면 Influx Block, 비정상이면 Corrupted Block으로 Reporting 됨
. INVALID REDO RECORD적용(Nologging)에 의한 Block 손상 시 DBV-00201에러 발생(10.2.0.4 이상)
$ dbv file=<file_name> blocksize=<db_block_size>
- ANALYZE Command
. Logical한 Block상태를 점검
. Table과 Index의 Validation 점검
SQL> analyze table <table_name> validate structure cascade;
SQL> analyze index <index_name> validate structure;
SQL> analyze cluster <cluster_name> validate structure;
SQL> analyze table <table_name> partition (<partition_name>) validate structure into invalid_rows;
Oracle Dump
- 29 -
IV. Recovery Types
- DB Instance가 Crash되었을 경우 메모리(DB Buffer Cache)에는 있었으나 디스크에 Write되지 않은
Block(Dirty Buffer)을 Online Redo Log File로 복구하는 작업
- 특징
. Crash Recovery는 DB Startup시 Server Process에 의해 자동으로 수행
. DB가 정상 종료되면 Checkpoint가 수행되고 Data File Header의 Checkpoint SCN을 Control File의
Stop SCN값으로 Copy
. DB가 Online 상태이거나 비정상 종료되었을 경우에는 Control File의 Stop SCN값은 무한대로 설정
(0xffff.ffffffff)
. Instance가 Startup 되면 다음 2가지를 점검
① Control File내의 Checkpoint Counter와 Data File Header내의 Checkpoint Counter값의 일치 여부
② 모든 Data File Header의 Checkpoint SCN값(Start SCN)과 Control File의 Stop SCN값의 일치 여부
. 만약 2가지 모두 일치 하면 Oracle은 Recovery 작업 없이 Open
. 첫 번째 점검이 실패하면 (Data File Header와 Control File의 Checkpoint Counter 일치 여부) Media
Recovery를 수행하여야 함
. 두 번째 점검이 실패하면 (Data File Header의 Checkpoint SCN값과 Control File의 Stop SCN값의
일치 여부) Instance Recovery를 수행
. Instance Recovery는 해당 Thread가 마지막 Checkpoint된 이후로 일어난 Thread의 모든 Redo
(Current Redo Log의 End Of Thread)를 자동으로 적용함
→ 이 과정에서 Data Block의 SCN이 Redo Record의 SCN보다 높은 Block은 Redo 적용이 Skip됨
. Instance Recovery가 끝날때는 모든 종류의 Fuzzy Bit이 Data File에서 지워지고 Instance Recovery의
종료를 의미하는 Redo(end-crash-recovery redo)가 생성됨
→ 이 Redo는 Media Recovery시 해당 Data File의 Online 및 Hot Backup Fuzzy Bit을 지울때 사용됨
. Instance Recovery가 완료된 후에는 Log Switch가 자동으로 발생하고 Checkpoint Counter가 1씩 증가
- Transaction Recovery
. DB Open후에 Uncommited Transaction에 대한 Rollback이 수행됨
. SYSTEM Undo Segment에 있는 Active Transaction은 즉시 Rollback됨
. 다른 Undo Segment의 Active Transaction은 Undo Header에 ‘DEAD’ Mark(0x10)를 함
. Transaction Recovery는 해당 Block이 Access되는 순간 발생
. SMON은 Undo Segment의 Transaction Table을 Scan하고, ‘DEAD’ Transaction에 대한 Rollback작업을
수행
Instance Recovery
1. Instance Recovery
- 30 -
IV. Recovery Types 1. Instance Recovery
- RAC환경에서 Instance Recovery
. RAC환경에서는 살아 있는 Instance가 Crash된 Instance의 Redo Log File로 LGWR가 Instance
Recovery를 수행 → 이때 빠른 복구를 위해 Two Pass Recovery 기법을 사용
. Two Pass Recovery (_two_pass=true)
① Pass 1 : Recovery를 수행하는 Instance에서 Crash된 Thread의 Redo Log File을 읽어 복구에
필요한 Recovery List를 작성함. Recovery List중 BWR(Block Written Record, 이미
Data File에 반영된 Redo Record)같이 복구에 불필요한 Redo Record는 삭제함
② Pass 2 : 실제 Thread Recovery를 수행
. Instance Membership Reconfiguration (IMR))
① Control File Heartbeat : CKPT Process가 매3초마다 thread 전용 Control File
Block(Checkpoint Progress Record)에 업데이터함 (X$KCCCP.CPHBT)
② ORA-29740
- Reason 2 : Control File Timeout(_controlfile_enqueue_timeout) : 900초
- Reason 3 : IPC Send Timeout(_cgs_send_timeout) : 300초
IPC Send Timeout detect후 Cluster가 split-brain을 해결하지
못하면(_imr_splitbrain_res_wait : 600초) eviction됨
- Split-brain발생 시 RR lock을 획득한 Instance가 각 Instance별 vote결과를 CFVRR
(Control File Vote Result Records, Checkpoint Progress Record와 같은 Block에 저장됨)에
업데이트하고 그 결과에 따라 Eviction되는 Instance를 결정
Instance Fails Failure Detected Enqueue
Reconfiguration GRD Freeze
Block Resource Claimed For
Recovery
Pass 1 Recovery Block Resource
Release Resource
Reconfiguration Enqueue Thaw
Cluster Reconfiguration
GRD unfrozen Partial Availability Pass 2 Recovery Individual Block
Availability Recovery
Enqueue Release
<Fig IV-1-1> Two Pass Recovery
- 31 -
IV. Recovery Types 2. Media Recovery
- Database File (Data File, Control File, Redo Log File 등)의 손상 장애를 해결하기 위해서 Database File의 백업을 Restore하고 수동으로 Recover 명령어를 수행하여 Archive Log File과 Online Redo Log File을 Data File에 적용하여 Database를 복구하는 작업
- Complete Recovery . Media Failure가 발생했을 때 Data를 전혀 잃지 않고 Database를 복구하는 것 . Online Redo Log File, 손상된 Data File에 대한 백업, 백업 이후의 모든 Archived Log File, 적합한 Control File이 있어야 Complete Recovery가 가능 . SQL> recover database;
- Incomplete Recovery . Media Recovery후 손실된 Data가 있으면 이 복구를 Incomplete Recovery라고 함 . MR이 필요하지만 Redo Log나 Archived Log File을 유실했을 경우, 유저에 의한 Point In Time Recovery상황 시, DB Open시 Crash Recovery에 필요한 Active Copy가 손상되었을 경우 사용 . Incomplete Recovery후 DB Open은 Resetlogs 옵션으로 Open하여야 한다. SQL> recover database until time 'yyyy-mm-dd:hh24:mi:ss'; SQL> recover database until change <scn>; SQL> recover database until cancel; SQL> recover database until cancel using backup controlfile;
Media Recovery
Data File A
137
Data File B
137
Data File C
137
137
Redo Log 1
136
Redo Log 2
137
Redo Log 3
135
Data File A
137
Data File B
137
Data File C
137
Control File
137
Redo Log 1
136
Redo Log 2
137
Redo Log 3
135
Data File A
137
Data File B
137
Data File C
130
Control File
137 136
137
135
Archived Log
130
Archived Log
132
Archived Log
134
Archived Log
131
133
135
2. Restore Data File and Log Apply
Archived Log Files
3. Recovery Completed (No Data Loss) 1. Data File C Failure
Complete Recovery
Redo Log 2
Redo Log 3
Archived Log
Archived Log
Redo Log 1 Control File
<Fig IV-2-1> Complete/Incomplete Recovery
Data File A
137
Data File B
137
Data File C
137
Control File
137
Redo Log 1
136
Redo Log 2
137
Redo Log 3
135
Data File A
135
Data File B
135
Data File C
135
Control File
135
Redo Log 1
Redo Log 2
Redo Log 3
Data File A
130
Data File B
130
Data File C
130
Control File
130
Archived Log
130
Archived Log
132
Archived Log
134
Archived Log
131
Archived Log
133
Archived Log
135
2. Restore Control File/All Data Files and Log Apply
Archived Log Files
3. Recovery Completed (Data Loss) 1. All Database Files Failure
Incomplete Recovery
- 32 -
IV. Recovery Types 2. Media Recovery
- Media Recovery 수행
. Control File의 Data File Entry에 있는 Checkpoint Counter와 Data File Header의 Checkpoint
Counter가 불일치하면 Media Recovery를 해야 함
. Data File Header의 Checkpoint Counter가 Control File Checkpoint Counter 보다 작은 경우
ORA-01113: file <file#> needs media recovery
ORA-01110: data file <file#>: <file_name>
→ recover database/datafile 수행
. Data File Header의 Checkpoint Counter가 Control File Checkpoint Counter 보다 큰 경우
ORA-01207: file is more recent than controlfile - old controlfile
→ recover database using backup controlfile 또는 Control File 재생성
. 복구 시작 SCN은 모든 복구 대상 Data File의 Checkpoint SCN중 가장 낮은 SCN임
. Online Redo Log File로 Media Recovery가 가능한 경우에도 수동으로 복구해야함
. Control File의 enabled thread bitvec 정보는 Recovery 시작 시 Enable된 Thread 정보를 나타냄
. Data File에 Fuzzy Bit이 하나라도 설정되어 있으면 Database를 Open할 수 없음
Recovery Types
DB Status Description
Recover
Database DB Mount
- Database의 모든 Data File을 복구하는 방법
- 복구 대상 Data File 상태는 Online이어야 함 (Offline Data File은 복구 안됨)
- Complete 및 Incomplete 복구가 가능
- 모든 Data File은 같은 시점으로 복구해야함
- Incomplete 복구는 Time/SCN/CANCEL/SEQ Base 복구가 가능
SQL> recover database (until time 'yyyy-mm-dd:hh24:mi:ss'/change <scn>/cancel);
RMAN> recover database until sequence <seq#> thread <thread#>;
- Current Control File없이 Backup Control File로 복구가 가능
→ 이때는 resetlogs 옵션으로 Open해야 함
- Data File이 Control File에는 없고 Dictionary Table(sys.file$)에만 있는 경우 rename해
야 함
SQL> alter database rename file 'MISSING<file#>' to '<file_name>';
Recover
Tablespace DB Open
- 특정 테이블스페이스만 복구하는 방법
- 복구 대상 Tablespace 상태는 Offline이어야 함(SYSTEM Tablespace는 불가)
- SQL에서는 반드시 Complete 복구를 해야 함
SQL> recover tablespace <tablespace_name>(,<tablespace_name>);
- RMAN에서는 특정시점까지 복구가 가능함(TSPITR)
RMAN> recover tablespace <tablespace_name>(,<tablespace_name>) until time
"to_date('20101111 13:43:00','yyyymmdd hh24:mi:ss')";
. 11gR2 이상 부터는 Drop Tablespace를 복구 가능함
Recover
Datafile
DB Mount
/Open
- 특정 Data File만 복구하는 방법
- Complete 복구를 해야 함
SQL> recover datafile '<file_name>'(,'<file_name>');
<Tab IV-2-1> Recovery Types
- 33 -
IV. Recovery Types 2. Media Recovery
Step Description
1
- Recovery 시작 SCN을 결정함
- 모든 대상 Data File Header의 Checkpoint SCN중 가장 낮은 SCN이 Recovery 시작 SCN임
- 만약 Data File Checkpoint SCN이 Offline Range 범위에 있으면 Offline-End Checkpoint SCN이 사용됨
2 - Enable된 Thread마다 Redo Reading Buffer가 할당
3 - Enable된 Thread의 Redo Log File이 Open됨
- 만약 Online Redo Log이면 자동으로 Open되고 Archived Log이면 Log File 입력 Prompt가 나타남
4 - 다른 Session이 동시에 Recovery 작업을 할 수 없게 복구 대상인 Data File에 대해서 MR(Media Recovery)
Lock을 획득함
5 - Inconsistency 상태에서 DB를 Open할 수 없게 Data File Header에 MR Fuzzy Bit이 설정
6 - 여러 Thread의 Redo Record가 SCN 오름차순으로 정렬되고 필요한 경우 Switching하면서 복구가 진행
(Thread-Merged Media Recovery)
7
- Media Recovery중에 Media Recovery Checkpoint가 발생
(Log Boundaries 지점,Stop SCN에 도달하였을 경우)
- Checkpoint가 발생하면 모든 Dirty Recovery Buffer가 Data File에 Write되고 Data File Header에
Checkpoint SCN이 Update됨
- 만약 Recovery Process가 Fail이 발생했을때는 이 Checkpoint SCN부터 Recovery 작업이 다시 시작
8 - Stop SCN이 유한한 Data File(Offline/Read Only)은 Stop SCN까지 Media Recovery가 수행
9
- Complete Media Recovery일 경우 모든 Enabled Thread의 EOT (End Of Thread) Marker가 있는
Current Redo Log까지 Media Recovery를 진행
- Incomplete Media Recovery일 경우 기 설정된 SCN이나 Time까지 진행
- UNTIL CHANGE option은 지정된 SCN 바로 전까지 적용됨 (지정된 SCN까지 적용하려면 SCN+1을 해야함)
10 - MR Fuzzy Bit이 Clear됨
<Tab IV-2-2> Thread-Merged Media Recovery
- Backup Control File을 이용한 Media Recovery
. Backup Control File에는 Current Online Redo Log 정보, Stop SCN, Enabled Threads 정보가 없음
. Media Recovery는 Stop SCN이 무한값인 것으로 가정
. Redo Log File의 EOT Marker에서 Recovery가 끝남
. Data File Header에서 Enabled Threads정보(enabled thread bitvec)와 Start SCN (Checkpoint SCN)
정보가 제공
. 현재는 Read-Write상태의 Data File인데 Backup Control File에는 Read-Only나 Offline상태로 되어
있으면 Control File의 상태 정보를 변경한 후 복구해야 함
. Backup Control File이 Data File 보다 오래된 경우 Control File을 복구하기 위해서 Backup Control File
시점부터 Media Recovery가 수행됨
- RAC에서 Media Recovery는 Thread-Merged Media Recovery 기법으로 복구를 수행함
- 34 -
IV. Recovery Types 3. Block Recovery
Types Description
Memory Block
Recovery
- Memory Block Recovery는 DB 운영 중에 PMON이나 Server Process에 의해 자동으로 수행함
- 발생 원인
. 변경 중이던 Buffer(Data Block)의 Server Process가 죽거나 Error를 만날 때 수행
. Change Vector를 적용하는 Redo Application이 취소될 때 발생
- 복구 절차
. 해당 Block을 Disk에서 읽고
. Online Redo Log를 적용하고
. 복구된 Buffer를 디스크에 다시 Write함
. 만일 복구에 실패하면 Block의 Sequence#를 0으로 만들고 Logical Corrupt Block상태로
만들면서 ORA-01578메시지를 뿌림
- Redo를 적용하는 Server Process가 비정상적으로 Error Signal이 뿌려지면, 해당 Process는
Block Recovery를 시도함
- 만약 Server Process가 Redo 적용 중에 죽게되면 PMON이 Block Recovery를 시도
RMAN Block
Recovery
- RMAN은 DB Open상태에서 해당 Block만 Copy한 후 Redo Log를 적용하여 손상된 Block을
Recovery할 수 있음
RMAN> blockrecover datafile <file#> block <block#>
- User-Managed Backup을 RMAN Catalog에 등록하면 RMAN Block Recovery 기능을 사용할 수
있음 (이 경우에는 백업 당시 Empty상태의 Block은 복구가 안됨)
RMAN> catalog datafilecopy '<file_name>';
ADG Automatic
Block Media
Repair
- ADG 환경에서는 Block 손상 발생시 자동으로 Standby DB의 Block을 이용하여 복구가 됨
- User에게는 에러를 Return하지 않고 자동으로 복구한 후 복구된 Block정보를 alert.log에만 기록
- 반대로 Standby DB의 Block이 손상되었을 경우 Primary DB의 Block을 이용하여 복구함
User-Managed
Backup
Recovery
- User-Managed Backup을 이용할 경우 최소한 손상된 Block이 속한 Data File을 Offline 한 후
손상되지 않은 백업을 Restore하여 복구하여야 함
- Data Block이 손상되었을때 손상되지 않은 Data Block을 Copy한 후 Redo Log를 적용하여
Data Block을 복구하는 작업
. 손상되지 않은 Data Block을 Copy할 수 없을 때는 해당 Block을 Skip한 상태에서 복구할 수도 있음
이때에는 손상된 Block의 Data는 유실됨
. 손상된 Block이 Index일 경우 Index Rebuild 작업으로 손상된 Block을 복구할 수 있음
- Block 손상의 원인은 다음과 같다.
. HW 문제 (IO/Memory/CPU/Firmware/OS) 문제
. Oracle 문제 (Bug, Nologging 등)
<Tab IV-3-1> Block Recovery Types
Block Recovery
- 35 -
IV. Recovery Types 3. Block Recovery
Types Description
Event설정 후
Recovery
- Corrupt된 Block을 Skip하는 Event를 설정하여 Data를 복구하는 방법
. Data
SQL> alter session set events '10231 trace name context forever, level 10';
. Index
SQL> alter session set events '10233 trace name context forever, level 10';
DBMS_ROWID
Package
- 손상된 Block을 제외한 나머지 Block의 Rows을 추출하는 방법
. 손상된 Segment 및 Object# 확인
SQL> SELECT tablespace_name, segment_type, owner, segment_name FROM dba_extents
WHERE file_id = <file#> and <block#> between block_id AND block_id + blocks – 1
SQL> select data_object_id from dba_objects where owner=<owner> and
object_name='<object_name>';
. Row ID 생성 (Corrupt된 Block의 Min/Max Row ID 생성하여 이 범위를 제외한 Data 추출)
<Min Row Id>
SQL> select dbms_rowid.rowid_create(1,<object#>,<file#>,<Corrupted_block#>,0) from dual;
<Max Row Id>
SQL> select dbms_rowid.rowid_create(1,<object#>,<file#>,<Corrupted_block#+1>,0) from dual;
DBMS_REPAIR
Package
- Block Repair Steps
. Use DBMS_REPAIR.ADMIN_TABLES to create the admin tables
. Use DBMS_REPAIR.CHECK_OBJECT to find problem blocks
. Get any good data out of problem blocks before corrupting them.
. Use DBMS_REPAIR.FIX_CORRUPT_BLOCKS to mark the found problem
blocks as corrupt so that they will then signal ORA-1578
. If required use DBMS_REPAIR.SKIP_CORRUPT_BLOCKS to skip corrupt blocks on the table.
<Tab IV-3-1> Block Recovery Types (Continued)
- 36 -
IV. Recovery Types 4. Logical Recovery
Types Description
User-Managed
Clone DB
- 사용자가 실수로 Data를 변경하였을 경우 백업을 이용하여 별도의 복제DB를 구성한 후
변경되기 직전까지의 Data를 복구하는 방법
- 절차
. Clone DB용 Oracle SW를 설치
. Control File 및 복구가 필요한 Table의 Tablespace 및 SYSTEM, Undo Tablespace를 Clone DB에
Restore함
. 복구에 필요한 Data File만 Online하고 나머지 Data File은 Offline함
. Until Time Option으로 변경되기 직전까지 Incomplete Recovery를 수행
SQL> recover database using backup controlfile until time 'yyyy-mm-dd:hh24:mi:ss';
. Resetlogs Option으로 DB를 Open
. 변경되기 전 Table을 export하여 운영 DB에 import
. Tablespace 전체를 복구하기 위해서는 Transportable Tablespace기능을 사용하여 복구할 수도
있음
RMAN
Duplicate DB
- RMAN의 Duplicate Database 기능을 사용하여 변경 전 Data를 복구하는 방법
- 절차
. Duplicate DB용 Oracle SW를 설치
. 운영DB를 Target으로 설정하고 Duplicate DB를 Auxiliary로 설정하여 RMAN을 실행
$ rman target sys/xxxx@<alias> rcvcat=rman/xxxx@<alias> auxiliary /
. Until Time 옵션을 이용하여 Point In Time DB를 생성
. 복구하는데 불필요한 Tablespace는 SKIP 옵션을 사용하여 제외할 수 있음
$ rman target sys/xxxx@<alias> rcvcat=rman/xxxx@<alias> auxiliary /
RMAN> duplicate target database to "<dup_dbname>" nofilenamecheck
until time "to_date('2010/11/14 03:00:00','YYYY/MM/DDHH24:MI:SS')"
SKIP TABLESPACE <tablespace_name>,<tablespace_name>;
. Duplicate DB 생성 후 복구해야 할 Table을 export/import함
RMAN TSPITR
- RMAN의 TSPITR(Tablespace Point-in-Time Recovery)기능을 이용하여 운영DB의 특정
Tablespace를 과거의 특정 시간으로 되돌리는 복구 방법
- Auxiliary Instance에서 특정 Tablespace만 Incomplete 복구를 수행해 내부적으로
Transportable Tablespace기능을 이용하여 운영DB의 특정 Tablespace를 과거 시점으로 복구
- RMAN에서는 recover tablespace until time 구문만으로 완전 자동화하여 운영DB의 특정
Tablespace를 과거 시점으로 바꾸기 때문에 조심해서 사용하여야 함
- 사용자 실수에 의한 변형 또는 유실된 Data를 복구하는 작업
. 일반적으로 운영DB의 Clone DB를 별도로 구성하여 복구하는 방법과 운영DB에서 Flashback기능을
이용하는 복구 방법이 있음
<Tab IV-4-1> Logical Recovery Types
Logical Recovery
- 37 -
IV. Recovery Types 4. Logical Recovery
Types Description
Flashback 기능
- Database의 Undo Segments/Flashback Log 등을 이용하여 DB의 일부 Data 또는 전체 Database
를 특정시점으로 되돌리는(Flashback) 기능
- Flashback Database
. Flashback log를 이용하여 전체 Database를 과거의 특정시점으로 되돌리는 기능
. 백업 Restore없이 신속하게 전체 DB를 과거시점으로 되돌리기가 가능함
. 운영DB에 적용하면 성능과 업무에 영향이 있기 때문에 Data Guard환경하에서 Standby
Database에 적용하면 효과적
- Flashback Table
. Table전체를 특정 시점으로 되돌리는 기능
- Flashback Query
. 과거의 특정시점의 Data를 Select문으로 Query할 수 있는 기능
- Flashback Drop
. Recycle Bin을 이용하여 Drop된 테이블을 복원하는 기능
- Flashback Version Query
. Transaction의 변경된 History 정보를 보여주는 기능
- Flashback Transaction Query
. 특정 Transaction을 과거 시점으로 돌리기 위한 Undo SQL문을 생성한 기능
- Flashback Data Archive
. Historical Data를 별도의 Tablespace에 보관하여 과거 Data를 보여주는 기능
. Undo Segment를 사용하지 않기 때문에 장기간의 Data 변경 이력 정보를 보관할 수 있다.
- Flashback Transaction Backout
. 과거에 실행된 Transaction 및 관련된 종속 Transaction을 확인하고 Rollback하는 기능
Log Miner
- Logminer는 Redo Log File이나 Archived Log File의 Redo Record를 읽어 UNDO 또는
REDO SQL 문장으로 변환해주는 Tool
- 사용자 실수로 변경한 Data를 Logminer의 UNDO SQL로 복구할 수 있음
Export/import - Export Utility로 Backup 받은 Dump File을 Import Utility로 복구하는 방법
<Tab IV-4-1> Logical Recovery Types (Continued)
- 38 -
IV. Recovery Types 5. Disaster Recovery
Types Description Advantages Disadvantages
Physical Standby Database (Physical Redo Apply)
- Redo를 전송하여 DB Data 를 이중화 하는 방식 - Redo전송 및 적용 방식에 따라 실시간 또는 시간차 (delay) DB 구성 가능 - Physical Standby DB
- Logical Disk 장애 보호 장치 및 자동 Block 손상 복구 기능 - Standby DB를 실시간 Report 용 DB로 이용 가능 (Active Data Guard) - DB Layer에서 Role 변경 작업 으로만 Switch-Over가 가능 하기 때문에 Switch-Over시 업무 Down 시간이 매우 짧음 - 저 사양 HW 장비로 구성 가능 - 기존에 구축된 네트워크(LAN) 을 이용하여 구성 가능
- Fail Over 발생 후에는 Standby DB 재구성 작업이 필요함 - Redo적용 방식이기 때문에 Nologging 옵션이 무효화됨 - Standby DB를 관리하기 위한 DBA 부담이 증가함 - Redo Log의 Logical 손상 대응 제한적
Logical Standby Database (Logical Redo Apply)
- Commit된 Redo Record 를 Capturing하여 SQL로 변환 후 DR쪽 DB에 SQL 문장으로 복제 하는 Solution - Logical Standby DB, Oracle Golden Gate, Quest SharePlex
- DR 서버를 Active하게 운영 가능 - 논리적인 Block 손상 대응 - 유연한 Platform - 빠른 DR 전환 - Down시간을 최소화하여 DB Upgrade이나 이기종 Migration 작업이 가능
- Object에 대한 제약 사항 많음 - Supplemental Logging 필요 - Transaction이 많은 시스템에서는 Local↔DR간 Gap 발생 가능성이 큼 - 운영관리 난해
Storage DR Solution (HW Mirroring)
- 스토리지 Layer에서 디스크 Mirroring 기술을 이용한 DB 이중화 구성 - EMC SRDF, Hitachi TrueCopy/UR, IBM XRC/PPRC, HP CA
- 운영 용이
- 스토리지 이중화를 위한 전용 네트워크(SAN) 구성이 필요함 - Remote 서버로 전환 시 Switch Over 절차가 길기 때문에 업무 중 단이 발생 함 - Remote 서버로 전환 시 Disk/File System/IP/DB에 대한 구동 절차가 필요함 - 디스크 Mirroring방식이기 때문에 SwitchOver시 File System/DB 복구 작업이 필요하기도 함 - Logical Disk 장애 및 Block 손상 장애에 대해서 취약한 구조임 - 제한적인 Platform
Extended RAC (SW Mirroring)
- RAC 및 Host-based Mirroring 솔루션(LVM Mirror, ASM 등)을 이용 하여 DR 구축하는 방법 - Oracle RAC/ASM, Symantec LVM
- 1개의 DB를 여러 개 의 DB 서버가 동시에 사용 가능 - 평상시 DR DB 서버 및 Storage가 Active한 상태이기 때문에 자원 효율성이 높고 Fail Over 시간이 거의 발생 하지 않음 - SW Mirroring 구성으로 Down Time없이 Storage Migration 및 작업 가능
- Logical DB 장애에 대해 대응이 안됨 - DR Network 문제 시 운영 서버에 영향 가능 - RAC 구성을 위해서는 병렬 처리를 지원하는 디스크 서비스 (Raw Device/ASM/CFS)와 DB 옵션 (RAC)이 설치되어 있어야 함 - DB에 여러 서버에서 동시에 트랜잭션이 발생하기 때문에 Global Lock에 의한 성능 저하 문제가 발생 할 수 있으므로 업무 분산 설계가 중요
- 정전, 화재, 누수, 전쟁 등의 재난에 대비하여 DB를 사전에 구성 후 재해시 전환 가동하는 것
. 사전 구성된 시스템을 Disaster Recovery System이라고도 함
- Disaster Recovery 종류
. Oracle DB의 DR Solution은 서버 Level에서 Redo Log를 이용한 복제 방식과 Disk Mirroring을 이용한
방식으로 나눌 수 있음
. Redo Log를 이용한 복제 방식은 Physical하게 Redo Log를 적용하는 방식과 Redo Log를 SQL로 전환하여 적용하는 2가지 방식으로 나눌 수 있음 . Disk Mirroring 방식은 Volume Manager Layer에서 이중화하는 SW Mirroring 방식과 Storage Layer에서 이중화하는 HW Mirroring 방식으로 나눌 수 있음
<Tab IV-5-1> Disaster Recovery Types
Disaster Recovery
- 39 -
- 여러 가지 유형의 장애로부터 Database 보호
. Physical 장애, Logical 장애, 사용자 실수, 재난, Software Bug 등 여러 가지 유형의 장애를
List Up하고 Recovery 계획 수립
- 목표 장애 Recovery 시간 산정
. 업무 담당자와 협의 하여 해당 시스템의 목표 장애 시간을 설정
. 장애 유형별 Recovery 시간 측정
Backup 주기, Disk Restore 속도, Tape Restore 속도, Archive Log 발생량, Recovery 적용 속도,
Recovery 서버 구성 시간, Recovery 인력 도착 시간 등 Recovery와 관련된 모든 요소들에 대한
시간을 측정을 하여 장애 유형별 Recovery 시간을 산정
. 측정된 예상 Recovery 시간을 업무 담당자와 협의하여 목표 장애 Recovery 시간을 협의
. 협의된 목표 장애 Recovery 시간에 대응하는 Backup 개선 계획 수립
- Data Loss 극소화
. Data Loss를 극소화할 수 있는 Backup 전략을 수립
. Data Loss가 허용되지 않는 업무는 Redo Log File 및 Archive Log File의 물리적/논리적 이중화 구성,
Checksum 기능 활성화, Logical Standby Database, Flashback Database 구성 등이 필요
. Current Redo Log 손상 같이 Data Loss가 발생할 가능성이 있는 장애에 대해서는
업무 담당자 및 Application담당자에게 인지시키고 대책을 협의
- Disaster에 대한 대비
. 정전, 화재, 누수, 전쟁 같은 재난 상황에 대한 Recovery 전략 필요
- DBA 인력 관리
. 잘 훈련되고 Recovery 경험이 많은 DBA를 확보해야 함
. DBA 부재 시 대책 수립
- Backup & Recovery 전략 평가
. 정기적으로 Backup의 유효성 및 Recovery 테스트 실시
. Recovery 테스트 결과 평가 및 개선점 도출
. 주기적인 업무 요구 사항 업데이트
- 신중한 Recovery 작업 수행
. 잘못된 Recovery 시점 산정, Hidden Parameter 사용, Backup Control File의 사용 유무 등에 따라
Recovery 시간이 지연되거나 경우에 따라 Recovery가 불가능하게 될 수도 있음
. 중요한 시스템일 수록 Oracle Support에 연락하여 Confirm을 받는 것과 같이 Recovery 절차에 대해
확신이 선 후 작업을 진행하도록 함
Appendixes 1. Backup & Recovery Strategy
- 40 -
Type of Outages Actions Error Detection
Instance Database Crash During Hot Backup
- Startup mount - Alter database end backup - Alter database open
ORA-01113, ORA-01110
Database Crash Without Logging - Full Export/Import Using DUL ORA-00354, ORA-00353, ORA-00312, ORA-00607, ORA-00600 [4194]
Control File Loss of Single Control File
- Shutdown abort
- Change Init.ora file
- Startup instance
ORA-00447, ORA-00201,ORA-00202
Loss of All Control Files
- Shutdown abort
- Create Control File
- Start Recovery Processes
- Crash Recovery
- Open DB
ORA-00447, ORA-00202
Redo Log File Loss One Of The Online Redo Log Members - Drop Log File Member
- Add Log File Member ORA-00313, ORA-00312, ORA-00316, ORA-00321
Loss Of Inactive Archived Redo Log Group - Drop the problem redo log
- Add new log file group. ORA-00313, ORA-00312, ORA-07366
Loss of Inactive Redo Log Group That Has Not Archived
- Shutdown abort
- Startup mount
- Alter database noarchivelog
- Drop the problem redo log
- Alter database open (crash recovery)
- Shutdown normal
- Startup mount
- Alter database archivelog
- Alter database open
alter database clear unarchived logfile
ORA-00255, ORA-00286, ORA-16038, ORA-00312
Loss Of The Current Online Redo Log Group
A.
- Restore Database
- Commence Incomplete Recovery
B.
- Commence Disaster Recover Plan
ORA-00313, ORA-00312, ORA-00447, ORA-07366
Internal Redo Corruption
A. - Restore Database - Commence Incomplete Recovery B.
- Commence Disaster Recover Plan
ORA-00600 [3020], ORA-10567, ORA-00355, ORA-00353
System Data File Loss Of System Tablespace Data File - Restore Appropriate Data Files
- Commence Full Recovery ORA-01110, ORA-01116
Corruption Of Data Dictionary
A.
- Restore Appropriate Data Files
- Commence Full Recovery
B.
- Restore Database
- Commerce Point In Time Recovery
C.
- Commence Disaster Recover Plan
ORA-01578, ORA-00600, ORA-07445
Running Out Of Space In System Tablespace - Add Appropriate Size Of Data File ORA-01653, ORA-01654, ORA-01655
Undo Data File Undo Segment Corruption
A. - Restore Appropriate Data Files - Commence Full Recovery B. - Restore Database - Commerce Point In Time Recovery C. - Commence Disaster Recover Plan
ORA-00600 [4193], ORA-00600 [4152], ORA-01555, ORA-01578
Loss Of Undo Tablespace Data File
A.
- Restore Appropriate Data Files
- Commence Full Recovery
B. - Commence Disaster Recover Plan
ORA-01110
User Data File Loss Of Temporary Tablespace Data File
- Drop current temporary tablespace.
- Create another temporary tablespace
- Run alter user
ORA-01110
Loss Of Non-System Data File Without Undo Segment
- Alter tablespace offline
- Restore backup datafiles
- Set autorecovery on
- Alter database recover automatic tablespace
(apply archived redo logs)
- Alter tablespace online
ORA-01110
Read-Only Tablespace And Recovery - Restore READ-ONLY files from backup. ORA-01110
Offline Tablespace And Media Recovery
- Restore backup datafile - alter database datafile online - recover database
ORA-01110
Create Data File When Backups Are Unavailable - alter database create datafile ORA-01110
Recovery With a Backup Control File Through An Added Datafile - rename datafile
- Recover ORA-01244
Add Data File To Unclustered Filesystem in RAC A. alter tablespace drop datafile B. copy and rename datafile
ORA-01110
User Segment NOLOGGING Table/Index Recovery - Recreate Table/Index ORA-01578
Loss of A Data Partition
- Alter tablespace offline - Restore backup datafiles - Set autorecovery on - Alter database recover automatic tablespace (apply archived redo logs) - Alter tablespace online
ORA-01110
Loss Of Index Segments
A. Rebuild or Re-Create Index B. Restore and recovery tablespace B. Disaster Recvery Plan
ORA-01578
Loss Of Table Or Cluster Data
A. Recreate tables with Imports or with backup B. Restore and recover tablespace C. Disaster Recovery Plan
ORA-01578, ORA-01110
Cannot allocate extents or Tablespace Fragmentation - Add Datafile ORA-01631, ORA-01632, ORA-01653, ORA-01654, ORA-01655
Database Logical Error
A. Disaster Recovery Plan B. Restore from backup and recover to a point in time prior to loss of data C. Object recovery such as export/import, unloader/loader, snapshots, replication, flashback
Appendixes 2. List Of Outages
- 41 -
from Oracle Troubleshooting (R. Velpuri & A. Adkoli)
3. Recovery Flow Charts
Can I do Complete Recovery
Options:
Database Recovery, Datafile Recovery
Options:
Database Recovery
Options:
Database Recovery, Tablespace Recovery, Datafile Recovery
Options:
Database Recovery,
Datafile Recovery
Bring Tablespace or Datafile
Online
Use command:
RECOVER DATABASE UNTIL
| TIME|CANCEL|CHANGE;
Options: Use backup control file and use command:
RECOVER DATABASE USING BACKUP CONTROL FILE
UNTIL
|TIME|CANCLE|CHANGE;
Use command:
RECOVER DATABASE;
Take datafiles that belong to “read-only” tablespace(s)
OFFLINE
done
Need to recover till end of a log file?
Can I Perform ONLINE
Recovery?
Need to recover
till end of a log file?
Can I use current control
file or newly created control
file with NORESETLOGS
option?
Can I use current control file or newly created control file with NORESETLOGS
option?
Use command:
ALTER DATABASE OPEN;
Use command:
RECOVER DATABASE USING BACKUP CONTROL FILE;
Use command:
ALTER DATABASE OPEN RESETLOGS;
Point in time
Recovery?
Point in time
Recovery?
Use command:
RECOVER DATABASE USING BACKUP CONTROL FILE
UNTIL CANCLE;
Use command:
RECOVER DATABASE
UNTIL CANCLE;
Use command:
RECOVER DATABASE
UNTIL CANCLE;
Use command:
ALTER DATABASE OPEN RESETLOGS;
Bring “read-only” tablespaces ONLINE
Full Database Backup
1
YES NO
YES
NO NO
NO NO
YES YES
YES
NO
YES YES
1 1
NO NO
Use command:
RECOVER DATABASE USING BACKUP CONTROL FILE
UNTIL CANCLE;
Appendixes
- 42 -
Opcodes for Oracle 9.2 from kco3.h
Eg: OPCODE=11.2 implies the operation was: KCOCODRW row operation, KDOIRP Insert Row Piece
Layer 1 : Transaction Control - KCOCOTCT
Opcode 1 : KTZFMT
Opcode 2 : KTZRDH
Opcode 3 : KTZARC
Opcode 4 : KTZREP
Layer 2 : Transaction Read - KCOCOTRD
Layer 3 : Transaction Update - KCOCOTUP
Layer 4 : Transaction Block - KCOCOTBK [ktbcts.h]
Opcode 1 : Block Cleanout
Opcode 2 : Physical Cleanout
Opcode 3 : Single Array Change
Opcode 4 : Multiple Changes to an Array
Opcode 5 : Format Block
Layer 5 : Transaction Undo - KCOCOTUN [ktucts.h]
Opcode 1 : Undo block or undo segment header - KTURDB
Opcode 2 : Update rollback segment header - KTURDH
Opcode 3 : Rollout a transaction begin
Opcode 4 : Commit transaction (transaction table update)
- no undo
record
Opcode 5 : Create rollback segment (format) - no undo record
Opcode 6 : Rollback record index in an undo block - KTUIRB
Opcode 7 : Begin transaction (transaction table update)
Opcode 8 : Mark transaction as dead
Opcode 9 : Undo routine to rollback the extend of a rollback segment
Opcode 10 :Redo to perform the rollback of extend of rollback segment
to the segment header.
Opcode 11 :Rollback DBA in transaction table entry - KTUBRB
Opcode 12 :Change transaction state (in transaction table entry)
Opcode 13 :Convert rollback segment format (V6 -> V7)
Opcode 14 :Change extent allocation parameters in a rollback segment
Opcode 15 :
Opcode 16 :
Opcode 17 :
Opcode 18 :
Opcode 19 : Transaction start audit log record
Opcode 20 : Transaction continue audit log record
Opcode 24 : Kernel Transaction Undo Relog CHanGe - KTURLGU
Layer 6 : Control File - KCOCODCF [tbs.h]
Layer 10 : INDEX - KCOCODIX [kdi.h]
Opcode 1 : load index block (Loader with direct mode)
Opcode 2 : Insert leaf row
Opcode 3 : Purge leaf row
Opcode 4 : Mark leaf row deleted
Opcode 5 : Restore leaf row (clear leaf delete flags)
Opcode 6 : Lock index block
Opcode 7 : Unlock index block
Opcode 8 : Initialize new leaf block
Opcode 9 : Apply Itl Redo
Opcode 10 :Set leaf block next link
Opcode 11 :Set leaf block previous link
Opcode 12 :Init root block after split
Opcode 13 :Make leaf block empty
Opcode 14 :Restore block before image
Opcode 15 :Branch block row insert
Opcode 16 :Branch block row purge
Opcode 17 :Initialize new branch block
Opcode 18 :Update keydata in row
Opcode 19 :Clear row's split flag
Opcode 20 :Set row's split flag
Opcode 21 :General undo above the cache (undo)
Opcode 22 :Undo operation on leaf key above the cache (undo)
Opcode 23 :Restore block to b-tree
Opcode 24 :Shrink ITL (transaction entries)
Opcode 25 :Format root block redo
Opcode 26 :Undo of format root block (undo)
Opcode 27 :Redo for undo of format root block
Opcode 28 :Undo for migrating block
Opcode 29 :Redo for migrating block
Opcode 30 :IOT leaf block nonkey update
Opcode 31 :Cirect load root redo
Opcode 32 :Combine operation for insert and restore rows
Layer 11 : Row Access - KCOCODRW [kdocts.h]
Opcode 1 : Interpret Undo Record (Undo)
Opcode 2 : Insert Row Piece
Opcode 3 : Drop Row Piece
Opcode 4 : Lock Row Piece
Opcode 5 : Update Row Piece
Opcode 6 : Overwrite Row Piece
Opcode 7 : Manipulate First Column (add or delete the 1rst column)
Opcode 8 : Change Forwarding address
Opcode 9 : Change the Cluster Key Index
Opcode 10 :Set Key Links (change the forward & backward key links
on a cluster key)
Opcode 11 :Quick Multi-Insert (ex: insert as select ...)
Opcode 12 :Quick Multi-Delete
Opcode 13 :Toggle Block Header flags
Layer 12 : Cluster - KCOCODCL [?]
Layer 13 : Transaction Segment - KCOCOTSG [ktscts.h]
Opcode 1 : Data segment format
Opcode 2 : Merge
Opcode 3 : Set link in block
Opcode 4 : Not used
Opcode 5 : New block (affects segment header)
Opcode 6 : Format block (affects data block)
Opcode 7 : Record link
Opcode 8 : Undo free list (undo)
Opcode 9 : Redo free list head (called as part of undo)
Opcode 9 : Format free list block (freelist group)
Opcode 11 :Format new blocks in free list
Opcode 12 :free list clear
Opcode 13 :free list restore (back) (undo of opcode 12)
Opcode 14 :undo for BMB
Opcode 15 :redo for index map
Opcode 16 :undo for index map
Layer 14 : Transaction Extent - KCOCOTEX [kte.h]
Opcode 1 : Add extent to segment
Opcode 2 : Unlock Segment Header
Opcode 3 : Extent DEaLlocation (DEL)
Opcode 4 : Undo to Add extent operation (see opcode 1)
Opcode 5 : Extent Incarnation number increment
Opcode 6 : Lock segment Header
Opcode 7 : Undo to rollback extent deallocation (see opcode 3)
Opcode 8 : Apply Position Update (truncate)
Opcode 9 : Link blocks to Freelist
Opcode 10 :Unlink blocks from Freelist
Opcode 11 :Undo to Apply Position Update (see opcode 8)
Opcode 12 :Convert segment header to 6.2.x type
Layer 15 : Table Space - KCOCOTTS [ktt.h]
Opcode 1 : Format deferred rollback segment header
Opcode 2 : Add deferred rollback record
Opcode 3 : Move to next block
Opcode 4 : Point to next deferred rollback record
Layer 16 : Row Cache - KCOCOQRC
Layer 17 : Recovery (REDO) - KCOCORCV [kcv.h]
Opcode 1 : End Hot Backup : This operation clears the hot backup
in-progress flags in the indicated list of files
Opcode 2 : Enable Thread : This operation creates a redo record
signalling that a thread has been enabled
Opcode 3 : Crash Recovery Marker
Opcode 4 : Resizeable datafiles
Opcode 5 : Tablespace ONline
Opcode 6 : Tablespace OFFline
Opcode 7 : Tablespace ReaD Write
Opcode 8 : Tablespace ReaD Only
Opcode 9 : ADDing datafiles to database
Opcode 10 : Tablespace DRoP
Opcode 11 : Tablespace PitR
Layer 18 : Hot Backup Log Blocks - KCOCOHLB [kcb.h] / [kcb6.h]
Opcode 1 : Log block image
Opcode 2 : Recovery testing
Opcode 3 : Object/Range reuse
Layer 19 : Direct Loader Log Blocks - KCOCODLB [kcbl.h]
Opcode 1 : Direct block logging
Opcode 2 : Invalidate range
Opcode 3 : Direct block relogging
Opcode 4 : Invalidate range relogging
Layer 20 : Compatibility Segment operations - KCOCOKCK [kck.h]
Opcode 1 : Format compatibility segment - KCKFCS
Opcode 2 : Update compatibility segment - KCKUCS
Layer 21 : LOB segment operations - KCOCOLFS [kdl2.h]
Opcode 1 : Write data into ILOB data block - KDLOPWRI
Layer 22 : Tablespace bitmapped file operations - KCOCOTBF [ktfb.h]
Opcode 1 : format space header - KTFBHFO
Opcode 2 : space header generic redo - KTFBHREDO
Opcode 3 : space header undo - KTFBHUNDO
Opcode 4 : space bitmap block format - KTFBBFO
Opcode 5 : bitmap block generic redo - KTFBBREDO
Layer 23 : write behind logging of blocks - KCOCOLWR [kcbb.h]
Opcode 1 : Dummy block written callback - KCBBLWR
Layer 24 : Logminer related (DDL or OBJV# redo) - KCOCOKRV [krv.h]
Opcode : common portion of the ddl - KRVDDL
Opcode : direct load redo - KRVDLR
Opcode : lob related info - KRVLOB
Opcode : misc info - KRVMISC
Opcode : user info – KRVUSER
4. Redo Operation Codes
Appendixes
- 43 -
Redo Code Description
IUR Intepret Undo Record
Intepret Undo Record. Pins the requisite block if necessary. Converts the undo to redo and passes it to kcbchg(), along with non-null auxpth-auxkcocv. It is expected that all the converted undo's will be able to achieve the correct results using the redo's already defined. See those for setting of the argument fields. This is only to be called by the cache; no user setup is required other than to set up a correct undo record to match each redo record submitted to ktuchg. This is the only undo call-back. The undo callback has also been expanded to take another component; the kdoo for comparing object ids as a sanity check to make sure the undo should be applied. This is the very last component in the undo record, and is not passed onto to the redo routines.
IRP Insert Row Piece Inserts a row piece into the currently pinned block. The row piece is passed in as described above and must fit within the block that is pinned.
DRP Delete Row Piece The indicated row piece is marked as deleted and the current transaction is credited with the space for all of the row except for the remaining stub and its row index.
LKR Lock Row Piece Locks the indicated row piece by setting the lock as described in the kdol.
URP Update Row Piece
Update the indicated row piece. Only the columns that change need be before and after imaged (added to the change vector.) The indices of these columns are in an array pointed to by ptr[2]. This list may include columns which do not already exist in the row piece (are suppressed trailing nulls,) and a piece may be made to have fewer columns (trailing values go to null,) by specifying the resulting number of columns in the piece in kdomncol.
ORP Overwrite Row Piece
Overwrites the indicated row piece with the new row piece as described by the kdoi and the given column values, if any. Additional: Will also get an entry like : Null: -N---N- Which means that the 2nd and 6th columns are null.
MFC Manipulate First Column
Adds or deletes the first column (fragment) in a row piece, according to the option set in kdocflag. Note that there is no lock value field in the kdoc; you must note whether or not this is the first change to the piece and set the UNLock flag accordingly in kdocflag. This is for dealing with continued columns; when you delete the first column, the P flag in the row header is cleared. When you add the first column, it is set.
CFA Change Forwarding Address
This can be used to change the forwarding address of a row piece. It need not already have one; it can be change to have one, or not to have one if it already does (thus making it the Last piece of a row,) or to simply change the current value of one. There is also an option to apply this without undo for cases where other changes to the piece (with undo) would cover the necessary undo for this.
CKI Change Cluster Index This changes the cluster key index of the target row. The row must have previously been clustered already.
SKL Set Key Links This changes the forward and backward key links on a cluster key. Either or both may be changed in a single operation.
QMI Quick Multi-Insert
Quick multi-insert inserts many rows into a block all at once. The rows should be written into a memory buffer as they will appear in the block (probably using kdrwr[ib].) This will just be copied into the block with one memcpy. The slot numbers for the rows must be supplied in the kdoq, and the offsets will be computed based on where the block is copied to, and using the array of lengths. The lock values in the written form of the rows are ignored, and all replaced with kdoqlock after copying. The rows must all be in the same table. NB: this is currently not implemented to be used as an undo yet.
QMD Quick Multi-Delete Deletes many rows from a block, all at once. The rows must all be in the same table. NB: this is currently not implemented to be used as an redo yet.
TBF Toggle Block Flags This toggles the block header flags that are set in the kdot. These are the kdbhflag flags. There is no undo for this can it can only be applied with kcbchg, because there is no kdo in the change record.
Layer 11 (Row Access) Description
4. Redo Operation Codes
Appendixes
- 44 -
KCCDIMRE 0x00000001 whether media recovery enabled
KCCDICKD 0x00000002 if dictionary must be checked with control file
KCCDIRLR 0x00000004 DB OPEN RESETLOGS required
KCCDISNC 0x00000008 Standby NOT Cluster consistent
KCCDIMRC 0x00000010 was/is last mounted READ_COMPATIBLE
KCCDICNV 0x00000020 controlfile was just created by convert from v6
KCCDIIRA 0x00000040 Incomplete Recovery Allowed when resetting logs
KCCDIINS 0x00000080 Instantly protected standby database
KCCDICCF 0x00000100 Controlfile was created with CREATE CONTROFILE
KCCDIINV 0x00000200 Invalid control file or database-still creating
KCCDISBD 0x00000400 StandBy Database - control file for hot standby
KCCDIORL 0x00000800 Opened ResetLogs - set until dictionary check
KCCDICFC 0x00001000 valid ControlFile Checkpoint in backup cf
KCCDISSN 0x00002000 SnapShot controlfile fileName pointer valid
KCCDIUCD 0x00004000 lazy file header Update Checkpoint cycle Done
KCCDICLO 0x00008000 clone database
KCCDINDL 0x00010000 standby database No Data Loss
KCCDISPK 0x00020000 Supplemental log primary keys
KCCDISUI 0x00040000 Supplemental log unique indexes
KCCDISFK 0x00080000 Supplemental log foreign keys
KCCDIGDA 0x00100000 Database guard all
KCCDIGDS 0x00200000 Database guard standby data
KCCDIIMR 0x00400000 Group Membership Recovery is supported
KCCDIEAR 0x00800000 End-of-redo Archival Received
KCCDITRB 0x01000000 Terminal Recovery Begin
KCCDILSB 0x02000000 Logical StandBy database
KCCDINIP 0x04000000 New Id operation in progress
KCCDIRPD 0x08000000 Rapid protected Standby database
KCCDIFOR 0x10000000 Database force logging mode
KCCDITRE 0x20000000 Terminal Recovery End
KCCDISML 0x40000000 Minimal Supplemental logging
KCCDIMLA 0x80000000 Manual Log Archival (if MRE) e added in 10.2
Control File - Database entry
Database flags (from kcc3.h) for Oracle 10.2
5. Database Flags
Appendixes
- 45 -
Hidden Parameter Description
_allow_resetlogs_corruption=true - allow resetlogs even if it will cause corruption
_offline_rollback_segments=(comma separated list of Automatic Undo segments)
- take the rollback segments offline during transactions recovery.
- temporarily prevents SMON from cleaning up the uncommitted
transaction in the rollback segments involved.
_corrupted_rollback_segments=(comma separated list of Automatic Undo segments)
- the uncommitted transactions are marked as committed.
- as a result, the blocks are made good enough, yet might be out of sync
with respect to the application data.
- even a database rebuild does not guarantee user data integrity.
- in UNIX you can issue this command to get the undo segment names:
$ strings system01.dbf | grep _SYSSMU | cut -d $ -f 1 | sort -u
_allow_read_only_corruption =true
- allows the database to be opened even if it has corruption.
this should only be used to export as much data from a corrupted
database as is possible before re-creating a database.
_corrupt_blocks_on_stuck_recovery - number of times to corrupt a block when media recovery stuck
- recover database allow N corruption (>=9i)
_two_pass = false - Oracle doesn't use two pass recovery feature and we can complete crash recovery. (ORA-600[KCRATR1_LOSTWRT] or ORA-397)
_db_block_cache_protect
- forces every process to lock a block in memory before writing to it.
- if a process writes it in a location memory that it hasn't locked.
- then access violation occurs, giving diagnostics trace information.
- VMS,MVS,OS/2, NEC, DGAviion,not implemented on most UNIX
_db_block_compute_checksums
- used to debug from disk to cache, oracle will computes and write
a checksum to the block. next time the same block is read,
oracle computes the checksum again and compares it with the value
that‘s in the block. if that differs, the block is corrupted on disk.
_check_block_after_checksum
- provided this parameter is set to TRUE the block check routine is run
after the point in the code where the checksum is normally calculated
(even if checksums are not enabled).
- if the block check fails, the calling process (usually DBWn) will error
and the block is not written to disk. In the case of DBWn this will cause
the instance to crash.
- the default value for this parameter is TRUE.
6. Recovery-Related Hidden Parameters
Appendixes
- 46 -
ADJUST_SCN Event
~~~~~~~~~~~~~~~~
*** WARNING ***
This event should only ever be used under the guidance
of an experienced Oracle analyst.
If an SCN is ahead of the current database SCN, this indicates
some form of database corruption. The database should be rebuilt
after bumping the SCN.
****************
The ADJUST_SCN event is useful in some recovery situations where the
current SCN needs to be incremented by a large value to ensure it
is ahead of the highest SCN in the database. This is typically
required if either:
a. An ORA-600 [2662] error is signalled against database blocks
or
b. ORA-1555 errors keep occuring after forcing the database open
or ORA-604 / ORA-1555 errors occur during database open.
(Note: If startup reports ORA-704 & ORA-1555 errors together
then the ADJUST_SCN event cannot be used to bump the
SCN as the error is occuring during bootstrap.
Repeated startup/shutdown attempts may help if the SCN
mismatch is small)
or
c. If a database has been forced open used
_ALLOW_RESETLOGS_CORRUPTION (See )
The ADJUST_SCN event acts as described below.
**NOTE: You can check that the ADJUST_SCN event has fired as it
should write a message to the alert log in the form
"Debugging event used to advance scn to %s".
If this message is NOT present in the alert log the event
has probably not fired.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If the database will NOT open:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Take a backup.
You can use event 10015 to trigger an ADJUST_SCN on database open:
startup mount;
alter session set events '10015 trace name adjust_scn level 1';
(NB: You can only use IMMEDIATE here on an OPEN database. If the
database is only mounted use the 10015 trigger to adjust SCN,
otherwise you get ORA 600 [2251], [65535], [4294967295] )
alter database open;
If you get an ORA 600:2256 shutdown, use a higher level and reopen.
Do *NOT* set this event in init.ora or the instance will crash as soon
as SMON or PMON try to do any clean up. Always use it with the
"alter session" command.
2 2147483648
3 3221225472
~~~~~~~~~~~~~~~~~~~~~~~~~~
If the database *IS* OPEN:
~~~~~~~~~~~~~~~~~~~~~~~~~~
You can increase the SCN thus:
alter session set events 'IMMEDIATE trace name ADJUST_SCN level 1';
LEVEL: Level 1 is usually sufficient - it raises the SCN to 1 billion
(1024*1024*1024)
Level 2 raises it to 2 billion etc...
If you try to raise the SCN to a level LESS THAN or EQUAL to its
current setting you will get - See below.
Ie: The event steps the SCN to known levels. You cannot use
the same level twice.
Calculating a Level from 600 errors:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To get a LEVEL for ADJUST_SCN:
a) Determine the TARGET scn:
ora-600 [2662] See Use TARGET >= blocks SCN
ora-600 [2256] See Use TARGET >= Current SCN
b) Multiply the TARGET wrap number by 4. This will give you the level
to use in the adjust_scn to get the correct wrap number.
c) Next, add the following value to the level to get the desired base
value as well :
Add to Level Base
~~~~~~~~~~~~ ~~~~~~~~~~~~
0 0
1 1073741824
2 2147483648
3 3221225472
EVENT: ADJUST_SCN - Quick Reference (Note:30681.1)
7. ADJUST_SCN Event
Appendixes
- 47 -
- Books
. Oracle 8i Backup & Recovery Handbook (Rama Velpuri, Anand Adkoli) 2000
. Oracle Real Application Clusters (Vallath Murali) 2003
. Oracle Troubleshooting (Rama Velpuri, Anad Adkoli) 1998
- Manuals
. Backup and Recovery Advanced User's Guide 10g Release 2 (B14191-03) 2008
. Data Guard Concepts and Administration 11g Release 2 (E10700-01) 2009
. Reference 10g Release 2 (B14237-04) 2009
- Technical Papers
. Internals of Recovery (Andrea Borr, Bill Bridge) 1995
. Outage Prevention, Detection, And Repair (Brian Quigley) 1995
. List of Database Outages (Brian Quigley, Oracle COE) 1999
. What's the Point of Oracle Checkpoints? (Harald van Breederode) 2009
. Checkpointing in Oracle (Ashok Joshi, William Bridge, Juan Loaiza, Tirthankar Lahiri)
. Redo Internal (Julian Dyke) 2005
. Oracle Forensics Part 1: Dissecting the Redo Logs (Davie Litchfield) 2007
. Redo Waits (Kyle Hailey) 2006
- Web Sites
. IXORA, Steve Adams. http://www.ixora.com.au
. Oracle Internals, Julian Dyke. http://juliandyke.com
. Metalink and Tech Net, Oracle Corporation. https://support.oracle.com
. google. http://www.google.com
References