ORACLE 11g v$datafile_header v1.0
|
12.11.05 |
1.0 |
|
|
|
|
|
|
|
|
|
1. v$datafile_header
|
Column |
Datatype |
Description |
|
FILE# |
NUMBER |
Datafile number (from control file) |
|
STATUS |
VARCHAR2(7) |
ONLINE | OFFLINE (from control file) |
|
ERROR |
VARCHAR2(18) |
데이터파일 헤더를 읽고 성공적으로 검증한 경우 NULL. 읽기를 실패한 경우 열 나머지는 NULL. 검증이 실패한 경우에는 열 나머지가 잘못된 데이터를 출력한다. 이를테면 에러가 있는 경우 보통 데이터 파일은 사용하거나 recover 하기 전에 백업으로부터 반드시 복원되어야 한다. |
|
FORMAT |
NUMBER |
헤더 블록의 포맷을 가리킨다. 가능한 값은 6, 7, 8, 혹은 0. 6 - indicates Oracle Version 6 7 - indicates Oracle Version 7 8 - indicates Oracle Version 8 0 - indicates the format could not be determined (for example, the header could not be read) |
|
RECOVER |
VARCHAR2(3) |
미디어 리커버리 필요여부 (YES | NO) |
|
FUZZY |
VARCHAR2(3) |
File is fuzzy (YES | NO) |
|
CREATION_CHANGE# |
NUMBER |
Datafile creation change# |
|
CREATION_TIME |
DATE |
Datafile creation timestamp |
|
TABLESPACE_NAME |
VARCHAR2(30) |
Tablespace name |
|
TS# |
NUMBER |
Tablespace number |
|
RFILE# |
NUMBER |
Tablespace relative datafile number |
|
RESETLOGS_CHANGE# |
NUMBER |
Resetlogs change# |
|
RESETLOGS_TIME |
DATE |
Resetlogs timestamp |
|
CHECKPOINT_CHANGE# |
NUMBER |
Datafile checkpoint change# |
|
CHECKPOINT_TIME |
DATE |
Datafile checkpoint timestamp |
|
CHECKPOINT_COUNT |
NUMBER |
Datafile checkpoint count |
|
BYTES |
NUMBER |
Current datafile size in bytes |
|
BLOCKS |
NUMBER |
Current datafile size in blocks |
|
NAME |
VARCHAR2(513) |
Datafile name |
|
SPACE_HEADER |
VARCHAR2(40) |
The amount of space currently being used and the amount that is free, as identified in the space header |
|
LAST_DEALLOC_SCN |
VARCHAR2(16) |
Last deallocated SCN |
2. Scenarioes
Read Only
Tablespace 가 Read Only 가 되는 경우 v$datafile_header 에 일어나는 변화를 확인해 보았다.
확인에 사용한 쿼리는 다음과 같다.
|
col error for a20 col ckpt_time for a15
select file#, status, error, recover, fuzzy, to_char(checkpoint_time,'yyyymmdd hh24miss') ckpt_time, LAST_DEALLOC_CHANGE# from v$datafile_header; |
Tablespace 를 Read only 로 변경하기 전의 결과 값은 아래와 같았다.
|
FILE# STATUS ERROR REC FUZ CKPT_TIME LAST_DEALLOC_CHANGE# ---------- ------- -------------------- --- --- --------------- -------------------------------- 1 ONLINE NO YES 20121112 112558 2 ONLINE NO YES 20121112 112558 3 ONLINE NO YES 20121112 112558 4 ONLINE NO YES 20121112 112558 5 ONLINE NO YES 20121112 112558 6 ONLINE NO YES 20121112 112558 7 ONLINE NO YES 20121112 112558 8 ONLINE NO YES 20121112 112558 9 ONLINE NO YES 20121112 112558 |
alter tablespace ogg read only;
ogg Tablespace 를 read only 로 변경하였다.
변경하자 file# 5번의 결과 값이 다음과 같이 변경되었다.
|
5 ONLINE NO NO 20121112 112934 |
변경 된 부분은 두 곳이다.
FUZZY 와 CKPT_TIME 이다.
FUZZY 의 사전적 의미는 ‘흐린’ 이란 뜻인데 이 값이 YES 에서 NO 로 변경되었다. 다시 말해 흐리지 않은 상태가 되었다란 뜻이며, 정황상 Data file 이 변경되지 않는다란 뜻으로 보인다.
또 변경 된 부분은 checkpoint_time 컬럼이다. alter 명령을 실행한 시점의 시각으로 값이 수정되었다.
위 상황에서 checkpoint 를 실행하면 read only 상태의 5번 파일은 대상에서 제외된다.
|
4 ONLINE NO YES 20121112 113136 5 ONLINE NO NO 20121112 112934 6 ONLINE NO YES 20121112 113136 |
위와 같이 5번 파일의 checkpoint_time 은 변함이 없다. 반면에 다른 데이터 파일의 checkpoint time 은 명령수행시각으로 갱신되었다.
위 상태에서 ogg 테이블스페이스를 read write 로 변경하면 read only 로 변경했을 때와 마찬가지로 checkpoint time 이 갱신되고 fuzzy 가 yes 상태로 변경된다.
|
4 ONLINE NO YES 20121112 113136 5 ONLINE NO YES 20121112 113400 6 ONLINE NO YES 20121112 113136 |
Begin Backup
ogg 테이블스페이스를 begin backup 상태로 변경하게 되면 read only 로 변경할 때와 마찬가지로
checkpoint time 이 갱신된다.
하지만 read only 와 다른 점은 fuzzy 가 yes 상태라는 것이다.
alter tablespace ogg begin backup;
|
4 ONLINE NO YES 20121112 131933 5 ONLINE NO YES 20121112 132004 6 ONLINE NO YES 20121112 131933 |
앞서 추정한 바로는 데이터파일의 변경여부가 fuzzy 의 YES 와 NO 를 판단하는 기준이 아닐까 이야기 했었다. /* fuzzy 가 begin backup 상태임에도 불구하고 yes 라는 것은 데이터 파일의 내용이 변경되고 있다는 이야기가 아닐까 추측해 본다. */
read write 변경할 때와 달리 end backup 의 경우 checkpoint time 을 갱신하지 않았다.
|
4 ONLINE NO YES 20121112 131933 5 ONLINE NO YES 20121112 132004 6 ONLINE NO YES 20121112 131933 |
Restore
앞서 사용했던 OGG TABLESPACE (FILE# = 5) 을 이용해 복원과정을 밟는 동안 v$datafile_header 정보가 어떻게 변하는지 보겠다.
14:34 시점에 다음과 같이 백업을 수행하였다.
RMAN> backup as copy datafile 5;
복원을 위 파일로 하기 위해 tag 정보를 보관하였다.
tag=TAG20121112T143426
백업을 완료 후 OS 상에서 파일을 강제 삭제했다.
test1[ogg1]@/home/oracle>rm -f /u01/app/oracle/oradata/ogg1/ogg1.dbf
이 후 v$datafile_header 를 확인한 결과 공란의 ERROR 에 메시지가 생겼다.
|
FILE# STATUS ERROR REC FUZ CKPT_TIME LAST_DEALLOC_CHANGE# ---------- ------- -------------------- --- --- --------------- -------------------------------- 5 ONLINE CANNOT OPEN FILE |
이 상황에서 복원 절차를 밟았다.
restore 전에 datafile 을 offline 으로 변경하였고 아까의 image copy 로부터 복원했다.
RMAN> sql 'alter database datafile 5 offline';
sql statement: alter database datafile 5 offline
RMAN> restore datafile 5 from tag=TAG20121112T143426;
이후 v$datafile_header 정보를 확인한 결과 REC = YES, FUZZY = NO 로 조회되었다.
|
FILE# STATUS ERROR REC FUZ CKPT_TIME LAST_DEALLOC_CHANGE# ---------- ------- -------------------- --- --- --------------- -------------------------------- 5 OFFLINE YES NO 20121112 143426 |
5번 데이터 파일이 RECOVERY 가 필요한 상황이다. RESTORE 된 checkpoint time 정보를 보면 백업시점과 동일하다.
RMAN> recover datafile 5;
|
4 ONLINE NO YES 20121112 143147 5 OFFLINE NO NO 20121112 144308 6 ONLINE NO YES 20121112 143147 |
Recover 이후 Checkpoint time 과 RECOVER 정보가 갱신되었다.
당연히도 Recover 과정을 거쳤기 때문에 RECOVER 가 불필요한 상황이 되었으며, RESTORE 상태에 변경된 블록이 적용 (RECOVER) 되었기 때문에 checkpoint time 이 갱신되었다.
RMAN> sql 'alter database datafile 5 online';
|
4 ONLINE NO YES 20121112 143147 5 ONLINE NO YES 20121112 144526 6 ONLINE NO YES 20121112 143147 |
3. References
A. V$DATAFILE_HEADER | http://docs.oracle.com/cd/E14072_01/server.112/e10820/dynviews_1099.htm