O10g flashback 13

http://www.ggola.com 장 경 상

6. Flashback - Time Machine.....................................................................6-3

6.1. Flashback Features...................................................................6-4

6.1.1. Overview..............................................................................6-4

6.1.2. Flashback Query Type..........................................................6-4

6.1.3. Flashback Level(Recovery Level)..........................................6-4

6.2. Row Level Recovery..................................................................6-6

6.2.1. Flashback Query...................................................................6-6

6.2.2. Flashback Version Query......................................................6-6

6.2.2.1..................................................................Version Query Limit

6-6

6.2.2.2..............................................................Version Query Syntax

6-7

6.2.2.3...........................................................Version Query Example

6-8

6.2.2.4..........New Conversion Functions with SCN and Timestamp

6-11

6.2.3. Flashback Transaction Query..............................................6-13

6.2.3.1.......................................FLASHBACK_TRANSACTION_QUERY

6-13

6.2.3.2...........................................................Transaction Query Limit

6-15

6.2.3.3....................................................Transaction Query Example

6-15

6.3. Tabel Level Recovery...............................................................6-20

6.3.1. Flashback Drop...................................................................6-20

6.3.1.1................................................................................Recycle Bin

6-20

6.3.1.2............................................................Recycle Bin Space 반환

6-21

6.3.1.3.....................................................Recycle Bin Space 자동반환

6-22

6.3.1.4........Recycle Bin Query와 Flashback Table Drop Command

6-22

6.3.1.5...............................................................Flashback Drop Limit

6-24

[email protected] 1


6.3.1.6.........................................................Flashback Drop Example

6-25

6.3.2. Flashback Table..................................................................6-30

6.3.2.1...........................................................Flashback Table Syntax

6-30

6.3.2.2...............................................................Flashback Table Limit

6-31

6.3.2.3........................................................Flashback Table Example

6-31

6.3.3. Undo Retention..................................................................6-35

6.4. Database Level Recovery........................................................6-39

6.4.1. Flashback Database...........................................................6-39

6.4.2. Database Configuration......................................................6-39

6.4.2.1..............................................................................일반적인 속성

6-40

6.4.2.2...............................................................Initial Parameter 설정

6-40

6.4.2.3....................................Open Database with Flashback Mode

6-42

6.4.3. Flashback Database 수행....................................................6-45

6.4.3.1....................................................Flashback Database Syntax

6-45

6.4.3.2.................................................Flashback Database Example

6-46

6.4.3.3.............................................Monitoring Flashback Database

6-48

6.4.3.4........................................................No Flashback Tablespace

6-50

6.4.4. Flashback Database Limit..................................................6-51

6.5. Flashback Guide......................................................................6-53

6.5.1. Corruption별 Flashback Type 과 필요환경............................6-53

6.5.2. Flashback Privilege 와 전제 작업..........................................6-53

6.5.3. Recovery 와 Flashback.......................................................6-53

[email protected] 2


6. Flashback - Time Machine

이번 장에서는 flashback의 확장된 개념, flashback any error에 대하여 다룰 것이다.

말 그대로 모든 error (혹은 어떤 error든지)를 원래 상태로 되돌려 줄 수 있다는

뜻이다. 즉, 사용자의 간단한 실수로부터 관리자의 큰 실수까지 어떤 형태의 오류라도

과거시점으로 돌아가 복구를 할 수 있도록 해준다.

어찌 보면 RMAN을 이용하는 backup and recovery를 backup본 없이 처리할 수

있는 online 대체 기능이라고 표현을 할 수도 있겠다.

[email protected] 3


6.1. Flashback Features

6.1.1.Overview

Oracle9i에서 time-machine이라는 별칭으로 태어난 flashback query는 과거의

특정 시점으로 돌아가 당시의 data를 보여줌으로써 작업자로 하여금 변경되기 이전의

과거 data를 가지고 다양한 종류의 online 복구작업을 지원하는 것이었다.

CF. 시스템의 오류가 아닌 사람의 실수를 recovery하는데 매우 유용한 방식이다.

과거 버전에서 이 기능은 row level의 한계 즉, row단위로만 가능하였고 undo

segment를 이용하여 처리할 수 있었다. 물론, oracle9i에서 소개된 새로운 undo 관리

방식인 automatic undo management를 사용하는 경우에만 가능한 방식이다.

이제 oracle10g에서는 이 기능을 확장하여 table level과 database level까지

recovery할 수 있도록 지원하고 그 flashback query type도 확장 되었다.

6.1.2.Flashback Query Type

1. flashback query : 특정 시점의 모든 data를 query하여 현재 변경된 값 이전의

row data를 retrieve한다.

2. flashback version query : 특정한 두 시점 사이에 발생한 schema objects및

row data의 변경 history를 보여줌으로써 rows를 변경한 transactions을 알 수 있다.

3. flashback transaction query : 특정 transaction에 의해 변경된 모든 내역을

보여준다.

6.1.3.Flashback Level(Recovery Level)

1. database level : database 전체를 특정 시점으로 되돌려준다.

2. table level : drop된 table을 이전 상태로 되돌리거나 과거 시점으로 특정 table의

모든 data를 되돌려준다.

3. row level : undo SQL문을 포함하여 metadata 변경사항까지 변경내역을 query

해준다.

[email protected] 4


참조

==============================================

=================

flashback : o9i 78p

flashback query : o9i 80p

[email protected] 5


6.2. Row Level Recovery

6.2.1.Flashback Query

이 기능은 oracle9i에서 소개된 flashback의 최초 개념으로 과거의 특정 시점에서

지정한 data 전체를 query하는 기능이다. 이런 flashback의 문제는 마치 time

machine을 타고 과거로 날아가서 볼 수는 있으되 무엇이든 변경은 할 수 없는

형태였다. 따라서 특정 시점으로 돌아가 볼 수는 있지만 DML은 할 수가 없었고 굳이

원한다면 PL/SQL block에서 과거 시점으로 cursor를 open한 후 flashback을

disable하고 DML을 사용해야 했다. 이제 oracle10g에서는 이런 불편을 다른 type의

query를 통해 해소할 수 있다.

CF. 물론, 이 기능은 여전히 특정 시점에서 data전체를 보는 방법으로 여전히

유효하다. 다만 새로운 oracle10g의 flashback query type이 보다 세부적이고

유연한 방식을 제공한다고 이해하자.

6.2.2.Flashback Version Query

Oracle9i가 특정 시점에 대한 flashback query를 소개했다면 oracle10g는 특정 시간

(time)대 또는 시점(SCN – system change number)사이의 모든 row values를

query함으로써 변경 history를 알 수 있게 해준다. 이를 flashback version query라

한다.

이 기능은 commit된 data만 추출함으로써 불필요한 rollback transaction을 제거할

수 있고 transaction id도 알 수 있기 때문에 이 id 정보를 가지고 향후 설명할

flashback transaction query를 사용하면 보다 자세한 정보도 얻을 수 있다.

6.2.2.1. Version Query Limit

1. external table, temporary table, fixed table, cluster의 일부, view를 대상으로

사용할 수는 없지만 view에 한해 definition으로 flashback version query를 사용할

수는 있다. (heap table 및 iot는 사용할 수 있다)

CF. view의 definition이 의미하는 바는 version query를 통해 create view 문장을

사용하는 형태 즉, “create view view_name as select version query”는

가능하다는 뜻이다.

2. DDL로 table의 구조가 바뀐 경우에는 DDL수행 이전의 data는 version query에

사용할 수 없다. (table level을 참조하라)

3. segment shrink operation 즉, move table과 같은 형식의 operation으로 table

row data의 block위치만 변경된 경우는 실제 data에 변경이 없는 internal delete

[email protected] 6


and insert이기 때문에 version query의 대상이 되지 않는다. (내부적으로 이 data

들은 phantom version으로 인식되어 filtering된다)

4. undo retention의 한계를 가진다. 즉, 과거와 마찬가지로 undo 방식을 automatic

management로 해야 하고 undo_retention의 값에 따라 최대 version query의

범위가 결정된다.

CF. IOT같은 table을 대상으로 발생한 update는 version query에서 update문

그대로 나타나지 않고 delete and insert의 두 version으로 표시된다.

6.2.2.2. Version Query Syntax

SQL> select version_columns, real_columns

from table

{versions between {scn|timestatmp} { start_value(or minvalue) and

end_value(maxvalue }}

[as of {scn|timestamp values}]

where [version_columns condition]

조회를 할 때 선택할 수 있는 column은 해당 table의 column과 version query가

제공하는 column(이를 pseudocolumn이라 한다)이다. 이 pseudocolumn을

추출하기 위한 시점이나 시간은 table절 내의 versions절에서 지정하며 제한 조건은

where조건에서 줄 수 있다.

CF. as of 절만 사용한 경우는 지정된 시점의 (또는 시간의) single version만 조회하고

versions절과 함께 사용한 경우에 as of는 until의 의미 즉, 마지막 시점을 표시하게

된다. 따라서 versions절을 사용하고 as of절을 사용하지 않으면 as of는 가장 최근

즉, 현재시점을 의미하게 된다.

예를 들어 다음과 같은 SQL이 의미하는 바는

SQL> select version_xid, e_name

from emp

versions between scn minvalue and maxvalue

as of scn 2944993

where id = 111000;

직원 table emp에서 id가 111000인 직원의 사용 가능한 SCN중 가장 오래된 SCN과

가장 최신의 SCN 사이에서 모든 변경사항을 SCN 2944993까지만 version query를

하되 transaction id와 직원 이름을 표시하라는 뜻이다.

[email protected] 7


다음은 version columns 이른바 pseudocolumn의 의미를 정리한 것이다.

Columns Description

versions_starttime query에 의한 첫 번째 version의 timestamp

versions_startscn query에 의한 첫 번째 version의 SCN

versions_endtime query에 의한 마지막 version의 timestamp

versions_endscn query에 의한 마지막 version의 SCN

versions_xid 해당 version의 transaction id (raw type)

versions_operation rows data를 변경시킨 insert, update 또는 delete

operation 을 표현(I, U, D의 한 글자로 표현된다)

6.2.2.3. Version Query Example

앞서 테스트하던 table을 복제하여 version query의 결과를 확인해 보자.

CASE #1

SCOTT> create table x_version_emp as select * from x_emp;

Table created.

SCOTT> col x_addr for a10

SCOTT> select * from x_version_emp;

X_NAME X_ID X_PHONE X_ADDR

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

KIM 100001 345-3521 EAST

CHOI 400001 345-7600 SOUTH

JANG 200001 345-3520 WEST

SCOTT> update x_version_emp set x_name = 'KANG'

2 where x_id = '200001';

1 row updated.

SCOTT> delete from x_version_emp where x_id = '200001';

1 row deleted.

[email protected] 8

표 6-1

Version Column

s


SCOTT> select to_char(sysdate, 'HH24:MI:SS') from dual;

TO_CHAR(SYSDATE,'HH24:MI:SS')

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

17:06:26

SCOTT> commit;

Commit complete.

SCOTT> select versions_startscn st_scn, versions_endscn endscn,

2 versions_xid txid, versions_operation opt, x_name

3 from x_version_emp versions between scn minvalue and maxvalue

4 where x_id = '200001';

ST_SCN ENDSCN TXID O X_NAME

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

9722796763 01002900A2130000 D JANG

9722796763 JANG

마지막 delete 문장에 대한 정보만 나타나고 있다. 아래 다른 형태의 테스트 결과와

비교해보자. (큰 차이는 없다. 다만 commit의 시점과 그 수를 비교하라)

CAES #2

SCOTT> update x_version_emp set x_name = 'LEE'

2 where x_id = '400001';

1 row updated.

SCOTT> commit;

Commit complete.

SCOTT> delete from x_version_emp where x_id = '400001';

[email protected] 9


1 row deleted.

SCOTT> commit;

Commit complete.



3 from x_version_emp versions between scn minvalue and maxvalue

4 where x_id = '400001';


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

9722797149 03002500DD130000 D LEE

9722797141 9722797149 01001B00A5130000 U LEE

9722797141 CHOI

매우 다른 결과가 나왔다. Case #1의 경우 update와 delete를 같은 row에 대해

진행을 하고 한번에 commit을 했기 때문에 version query의 결과가 update내용을

표시하지 않았다. 즉, delete만이 의미를 가질 수 있는 data변경 이었다. 그러나 case

#2의 경우 update and commit 그리고 delete and commit을 했기 때문에 각기

다른 version을 가질 수 있다. 위 case #2의 결과는 다음과 같은 의미를 지닌다.

1. 첫 번째 version(마지막 row) x_name = ‘CHOI’는 현재 version query에서

endscn 9722797141 시점까지 유효하다는 의미를 가진다. 즉, 현재 version query

범위에서 최초의 현재 상태를 보여준다.

2. 두 번째 version x_name = ‘LEE’는 SCN 9722797141시점에 update가 되어

“CHOI”에서 “LEE”로 변경되었음을 보여준다. 그러나 endscn이 9722797149로

display되었으니 이 data의 유효기간은 SCN 9722797141에서 9722797149

까지다. 즉, start SCN이 9722797419인 transaction으로 인해 변경되었다는 뜻이다.

3. 세 번째 version(가장 최신 version, 첫 번째 row)은 SCN 9722797419시점에

delete되었다는 것을 보여주고 있다.

CASE #3

테스트를 진행하는 중에 위에서 설명한 versions 절이 VPD와 같은 정책에 대상이 되는

[email protected] 10


table에 대하여 사용되면 error가 발생하는 것을 확인할 수 있었다. 아래의 예를 확인해

보자.

SQL> select versions_startscn st_scn, versions_endscn endscn,


3 from x_bug_emp versions between scn minvalue and maxvalue

4 where x_id = '300001';

from x_bug_emp versions between scn minvalue and maxvalue

*

ERROR at line 3:

ORA-30051: VERSIONS clause not allowed here

SQL> exec dbms_rls.drop_policy('XBUG', 'X_BUG_EMP', 'VPD_BUG_MGR');

PL/SQL procedure successfully completed.

SQL> select versions_startscn st_scn, versions_endscn endscn,


3 from x_bug_emp versions between scn minvalue and maxvalue

4 where x_id = '300001';


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

9722832644 02000C0071140000 D KANG

9722832426 9722832644 030009001C140000 U KANG

9722832220 9722832426 030015001D140000 I LEE

위 결과로 볼 때 보안정책이 있는 table에 대한 version query는 error를 return

하지만 이 보안 정책을 해제하면 문제가 해결되는 것이 확인된다. 이 부분은 oracle

bug “4334975”와 연관이 있으며 대상 table의 보안정책이 data를 추출할 때 view의

형태로 인식하기 때문이다. 따라서 이는 bug라기 보다 구조적인 부분으로 이해를 해야

할 것 같다.

6.2.2.4. New Conversion Functions with SCN and

Timestamp

SCN과 시간을 match 시키는 것은 불편한 사항 중에 하나였다. Oracle10g는 이번에

new function을 통해 둘간의 conversion을 가능케 해준다. 이 기능을 이용하여 앞서



테스트한 SCN의 conversion을 진행해보자.

SCOTT> select scn_to_timestamp(9722796763) from dual;

SCN_TO_TIMESTAMP(9722796763)

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

08-AUG-05 05.06.28.000000000 PM

위 값은 앞서 case #1에서 commit을 하기 전에 수행한 sysdate를 조회한 값과

비교해 보면 매우 정확하다는 것을 알 수 있다. 약 2초 차이가 나지만 그 시간은

commit명령을 수행하기 전 임으로 거의 정확하다고 볼 수 있다.

이번에는 case #2의 update SCN을 시간으로 확인하고 또 현재 database로부터

SCN을 추출하여 그 conversion timestamp도 확인하는 법을 알아보자.

SCN_TO_TIMESTAMP(9722797141)

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

08-AUG-05 05.20.16.000000000 PM

SCOTT> select current_scn, scn_to_timestamp(current_scn) from

v$database;

CURRENT_SCN SCN_TO_TIMESTAMP(CURRENT_SCN)

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

9722797900 08-AUG-05 05.48.13.000000000 PM

이번에는 거꾸로 timestamp를 가지고 SCN을 역 추적해 보자. 바로 위의 case #2의

update timestamp 값을 가지고 SCN을 추출해 보자.

SCOTT> select timestamp_to_scn('08-AUG-05 05.20.16.000000000 PM')

from dual;

TIMESTAMP_TO_SCN('08-AUG-0505

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

9722797139

기대했던 값은 9722797141이지만 조금 더 빠른 SCN이 나왔다. SCN은 1초에도 계속

바뀔 수 있기 때문에 거의 이 function은 거의 정확한 값을 return한다고 이해하면



되겠다.

CF. 아래의 예를 보면 한 SQL에서 SCN의 차이를 알 수 있다. 따라서 이 conversion

functions은 대략적으로 거의 정확한 값을 conversion한다고 보면 된다.

SCOTT> select current_scn, timestamp_to_scn(systimestamp) from

v$database;

CURRENT_SCN TIMESTAMP_TO_SCN(SYSTIMESTAMP)

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

9722798194 9722798193

6.2.3.Flashback Transaction Query

Database관리자가 만나는 다양한 문제들 중 제일 불편한(?) 문제는 바로 사용자의

실수다. 사용자가 잘못하여 사라진 data의 복구를 요청 받으면 난감하기 때문이다.

물론, 불가능한 것은 아니지만 database backup본을 이용하거나 logminer를

이용하거나 등등의 방법들은 그다지 편한 방법은 아니다. 그래서 이런 부분들을

지원하기 위해 online 상태에서 data복구를 위한 방법인 flashback query는 이미

oracle9i에서 소개된 내용이기는 하지만 사실 oracle9i에서는 몇 가지 사전 작업과

불편함이 있었다.

Oracle10g는 이번에 flashback의 확장을 통해 매우 빠르고 쉽게 이들 방법을

지원한다. 앞서 이야기한 flashback version query를 통해 history를 파악할 수 있고

거기서 나온 정보를 바탕으로 oracle10g가 제공하는 system view인

flashback_transaction_query를 이용하면 transaction level별로 보다 더 자세한

정보를 쉽게 알 수 있게 되었다. 즉, 이 view는 undo segment를 조회하는 역할을

대행해주기 때문에 transaction id나 SCN 또는 time range별로 undo SQL까지

generation해주고 rowid까지 보여줄 수 있는 장점을 가진다. 따라서 flashback

transaction query를 통해 특정 시기 동안의 단일(single) 또는 모든(all)

transactions의 변화를 알 수 있다.

CF. 기능적으로 본다면 이 내용은 oracle9i의 flashback query + logminer와 같은

기능을 동시에 해결해 준다고 이해하면 되겠다.

CF. flashback version query와 마찬가지로 undo관련 parameter와 value에

영향을 받는다. 물론, undo tablespace를 충분히 하고 retention time만 많으면 그

활용범위는 얼마든지 높일 수 있을 것이다.



6.2.3.1. FLASHBACK_TRANSACTION_QUERY

Undo segment로부터 원하는 정보를 얻기 위해 사용하는 이 view는 다음과 같은

정보를 담고 있다. (사실은 정보를 담고 있는 segment를 대변한다)

Columns Description

XID transaction ID

START_SCN transaction이 시작한 때의 SCN 즉, DML등으로

발생한 transaction SCN

START_TIMESTAMP transaction start timestamp

COMMIT_SCN transaction이 수행된 후 최종 적으로 commit된

시점의 SCN 즉, 해당 transaction의 commit SCN

COMMIT_TIMESTAMP transaction commit timestamp

LOGON_USER transaction을 수행한 때의 database logon user

UNDO_CHANGE# undo system change # (1 or higher)

OPERATION transaction을 발생 시킨 DML operation type

(DELETE, INSERT, UPDATE, BEGIN, UNKNOWN)

TABLE_NAME DML이 수행된 table name

TABLE_OWNER DML이 수행된 table의 owner

ROW_ID DML로 인해 변경된 data의 rowid

UNDO_SQL 수행된 DML을 undo할 수 있는 undo SQL

CF. commit_scn과 commit_timestamp columns은 active transaction인 경우

null로 표시된다. 즉, DML이 수행되고 아직 commit을 하지 않은 상태인 경우 start

SCN은 있지만 아직 commit SCN은 없다는 뜻이다.

CF. 이 view는 오로지 commit된 transaction 정보만 보여준다. 따라서 rollback된

transaction 정보는 나타나지 않는다. 하지만 아직 rollback이 되지 않은 즉, commit

도 rollback도 되지 않은 상태의 transaction은 이 view를 통해 볼 수 있기 때문에

그런 상태인 경우 위에서 말한 데로 commit scn과 commit timestamp가 null로

나타나는 것이다.

CF. 위에서 operation이 “UNKNOWN”인 것은 undo segment로부터 원하는 정보를

찾지 못하는 경우를 뜻한다. Undo space의 부족 등의 이유로 undo data가 이미

사라져 없다면 그 때의 operation은 알 수 없음으로 “UNKOWN”이 되는 것이다.

그리고 “BEGIN”의 의미는(oracle관련 document에선) 정확한 설명이 없으나

transaction이 시작할 때 undo segment head block에서 transaction table의 slot


표 6-2

Transaction

Query의 내용


을 할당 받는 부분으로 보인다. 이 시점에서 oracle은 해당 transaction의 id를

할당하게 됨으로 DML을 수행하면, 예를 들어 update를 수행했다면 위

flashback_transaction_query에는 동일한 data에 대하여 operation이 “BEGIN”인

row와 “UPDATE”인 row가 나타나게 된다.

이 view를 query하기 위해서는 system privilege인 “select any transaction”

권한이 필요하다. 특히 flashback transaction query를 통해 보다 완전한 정보를

보기 위해서는(chained rows 혹은 cluster table과 같은) database의 상태가

“supplemental log”를 enable한 상태 이어야 한다. 만일 supplemental log가

enable되어 있지 않다면 다음의 command를 사용하라.

SQL> alter database add supplemental log data;

Supplemental log가 enable되면 column명이 undo segment 및 redo log file에

자세히 기록된다. 그리고 supplemental log의 enable 여부는 다음과 같이 확인한다.

SYSTEM> select supplemental_log_data_min from v$database;

SUPPLEME

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

YES

6.2.3.2. Transaction Query Limit

1. DDL은 dictionary update의 형식으로 나타난다.

2. IOT의 key column update는 insert, delete처럼 나타난다.

3. drop된 table은 object number로 나타난다.

4. drop된 계정은 username이 아니라 user ID로 나타난다.

6.2.3.3. Transaction Query Example

다음은 사용자의 실수를 복구하는 간단한 시나리오 예제다.

먼저 flashback query를 사용할 수 있는 권한을 부여한 후 테스트를 간단히 하기 위해

대상 table을 1개의 row만 갖도록 구성 하여 transaction을 발생시켜보자.

SYSTEM> grant select any transaction to scott;

Grant succeeded.

SYSTEM> conn scott/tiger

Connected.



SCOTT> create table x_tx_query as select * from x_version_emp;

Table created.

SCOTT> col x_addr for a10

SCOTT> select * from x_tx_query;


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

KIM 100001 345-3521 EAST

SCOTT> update x_tx_query set x_name = 'JANG';

1 row updated.

SCOTT> commit;

Commit complete.

SCOTT> update x_tx_query set x_addr = 'WEST';

1 row updated.

SCOTT> commit;

Commit complete.

지금 사용자는 x_tx_query에서 이름과 주소를 두 번에 걸쳐서 update를 한 후 각각

commit을 진행 하였다. 이때 사용자는 자신의 실수를 깨닫고 해당 data를 원래의

상태로 되돌려 달라는 요구를 하였다고 가정하자. 그렇다면 DBA는 앞서 설명한

version query를 통해 history를 파악하고 각각의 과거 transaction을 원복 시켜야

할 것이다.

물론, 이렇게 간단한 예인 경우엔 단지 flashback_transaction_query만을 조회하여

해결할 수 있겠지만 일반적인 경우라면 그렇지 못할 것이다. 따라서 보통의 절차를



생각하여 version query를 진행한 후 transaction query를 통해 recovery를 진행해

보자.

다음은 version query를 통해 transaction history를 알아보는 과정이다.


2 versions_xid txid, versions_operation opt, x_name, x_addr

3 from x_tx_query versions between scn minvalue and maxvalue;

ST_SCN ENDSCN TXID O X_NAME X_ADDR

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

9722841239 01001900F2130000 U JANG WEST

9722841232 9722841239 020012007F140000 U JANG EAST

9722841232 KIM EAST

위 결과를 통해 두 번의 commit(두 번의 transaction)을 통해 해당 data의 이름과

주소가 변경되었음을 알 수 있다. 이 SCN을 바탕으로 transaction query를 진행해

보자.

SCOTT> select undo_sql from flashback_transaction_query

2 where table_name = 'X_TX_QUERY' and

3 commit_scn between 9722841232 and 9722841239

4 order by start_timestamp desc;

UNDO_SQL

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

--------

update "SCOTT"."X_TX_QUERY" set "X_ADDR" = 'EAST' where ROWID =

'AAAOzfAAQAAAoCNAAA';

update "SCOTT"."X_TX_QUERY" set "X_NAME" = 'KIM' where ROWID =

'AAAOzfAAQAAAoCNAAA';

위 결과는 timestamp를 역순으로 출력한 것임으로 첫 번째 row부터 재 작업을

진행하면 원래의 table상태로 복구할 수 있도록 보여주고 있다. 복구를 진행해 보자.

SCOTT> update "SCOTT"."X_TX_QUERY" set "X_ADDR" = 'EAST'



2 where ROWID = 'AAAOzfAAQAAAoCNAAA';

1 row updated.

SCOTT> update "SCOTT"."X_TX_QUERY" set "X_NAME" = 'KIM'

2 where ROWID = 'AAAOzfAAQAAAoCNAAA';

1 row updated.

SCOTT> select * from x_tx_query;


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

KIM 100001 345-3521 EAST

SCOTT> commit;

Commit complete.



OCP point

==============================================

=================

1. flashback version query limit

2. flashback transaction query는 특정 시기 동안의 단일(single) 또는 모든(all)

transactions의 변화를 제공한다.

참조

==============================================

=================

heap table : o8 68p, o9i 174p

undo retention, retention time : o9i 80p, o9i 302p

undo 방식을 automatic management : o9i 302p

undo tablespace : o9i 303p, o9i 307p

undo segment : o9i 304p



6.3. Tabel Level Recovery

6.3.1.Flashback Drop

이전 버전까지 table에 대한 복구 즉, table recovery라는 개념은 없었다. 그것은

table의 drop command는 DDL이며 따라서 rollback이 없는 명령이었고 원한다면

database에 대한 recovery를 통해 매우 힘들게 point-in-time recovery를 수행해야

했다는 의미이다.

Flashback drop이란 이런 경우에 사용될 수 있는 database의 point-in-time

recovery가 없는 online rollback dropped table을 지원한다. 즉, 말 그대로

휴지통을 지원하게 되었다.

CF. 이제 여러분은 사용자가 실수로 (아주 가끔은 여러분 자신의 실수로) drop한 table

을 살릴 수 있는 방법을 얻게 될 것이다.

6.3.1.1. Recycle Bin

여러분이 매우 익숙한 windows환경에는 항상 휴지통이라는 것이 있다. 아주 예전에

DOS 시절엔 file을 지우면 DOS tool을 사용하여 지워진 file을 찾아 복구하는

방법들이 있었다. 요즘엔 물론, 휴지통에 들어간 file을 다시 꺼내오는 아주 간단한

절차를 통해 이를 해결할 수 있다. 이런 방식이 가능한 것은 file을 지우면 화면상에는

지워지지만 실제로는 이 file을 가리키는 주소만 지우고 실제 disk상에 쓰여진 data

들은 물리적으로 다른 file에 의해 overwrite가 되지 않는 한 다시 살릴 수 있는 방법이

가능하기 때문이다.

지금 소개하는 이 개념이 바로 휴지통과 같은 이점을 oracle에 도입했다고 생각하면

되겠다. 즉, table을 drop하는 순간 dba_free_space에서는 free space가 생기겠지만

아직 그 data들이 완전히 overwrite된 것은 아니라는 것이다.

그래서 oracle10g는 이와 유사하게 table이 drop되면 이를 recycle bin에 임시로

위치 시키고 그들의 ownership을 유지시키는 방식을 취하고 있다. 즉, table이 drop

되더라도 그 table이 차지하고 있던 공간에 대한 space 반환요구가 없다면 이를

유지한다.

지금 설명한 데로 dropped table을 ownership과 함께 그대로 유지한다는 말은

실제로는 아직 존재한다는 뜻이다. 따라서 dropped table의 이름이 그대로 유지되면

동일한 이름의 table을 생성할 수 없게 된다. 그래서 recycle bin에 있는 dropped

table은 자동으로(constraints를 포함하여) 이름이 바뀌게 되며 새로운 이름은 “BIN$”



를 접두어로 사용한다.

이런 이유로 여러분은 새로 바뀐 dropped table의 이름 “BIN$...”의 원래 drop되기

전의 이름을 알아야만 적절한 작업을 진행할 수 있다. 따라서 oracle10g는 새로운

view인 dba_recyclebin을 제공하고 있다.

6.3.1.2. Recycle Bin Space 반환새로운 방식의 drop 처리가 도입되었으니 당연히 새로운 command체계가 필요할

것이다. 다음의 drop command는 새로운 option을 보여주고 있다.

SQL> drop table table_name purge ;

마지막에 지정한 purge option은 바로 이런 recycle bin개념 때문에 생겨났다. 즉,

굳이 원한다면 table을 drop함과 동시에 차지하고 있던 data 공간을 반환하겠다는

말이다. 따라서 이 option을 사용하면 recycle bin을 사용하지 않음으로 복구를 할 수

없다. 이는 마치 windows에서 휴지통으로 보내지 않고 완전히 file을 삭제하여 공간을

효율적으로 사용하는 “shift + delete”와 같다.

그렇다면 purge option을 사용하지 않은 상태에서 dropped table의 원래 space

사용량이 너무 크고 지금 즉시 그 공간이 필요하거나 tablespace coalesce등의 작업

필요성이 있다면 어찌할 것인가. 다음의 new command를 보자.

SQL> purge table table_name ;

이 명령은 이미 drop된 table을 recycle bin에서 제거함으로써 space를 반환한다.

Purge command는 다양한 syntax를 제공한다.

SQL> purge table table_name

index index_name

recyclebin (user_recyclebin)

dba_recyclebin

tablespace tbs_name [user user_name]

1. table/index : 지정한 table 또는 index를 purge

2. recyclebin : current user’s recycle bin을 purge

3. dba_recyclebin : 모든 recycle bin을 purge (sysdba system privilege 필요)

4. tablespace : 지정한 tablespace에 있는 recycle bin의 모든 objects를 purge.

사용자 이름을 추가적으로 지정하면 지정한 tablespace에 있는 특정 user의 space를

반환.



CF. table/index를 지정하는 경우는 원래의 dropped object 이름을 사용할 수도 있고

system generated 이름을 사용할 수도 있다.

CF. recycle bin도 space를 점유하는 데에는 한계가 있을 수 밖에 없다. 휴지통을

보존하자고 원래의 data 영역을 낭비할 수는 없으니까. 따라서 이 bin내에서의 purge

는 FIFO 순서를 가지고 관리된다. 즉, 가장 오래된 dropped object가 가장 먼저

purge된다.

다음은 recycle bin과 purge가 자동으로 이루어지는 command의 유형을 추가로

소개한다.

SQL> drop tablespace tbs_name [including contents] ;

위 명령은 including option의 사용여부에 따라 다른 형태를 갖는다. 먼저, including

contents option을 사용한 경우 모든 objects가(현재 tablespace에 속한 dropped

objects를 포함하여) drop됨과 동시에 recycle bin으로 objects가 이동되는 일은

발생하지 않는다. 그러나 including contents option을 사용하지 않으면 해당

tablespace는 empty 상태이어야 하고 이 경우 지정된 tablespace에 속한 recycle

bin에 있는 objects는 자동으로 purge된다. 이 개념은 아래와 같은 사용자 drop에도

그대로 적용된다.

SQL> drop user username cascade ;

사용자가 drop되면 관련된 모든 objects는 삭제되고 관련 recycle bin내의 objects

역시 purge된다.

6.3.1.3. Recycle Bin Space 자동반환다음은 tablespace가 free space를 필요로 할 때 check하고 할당하는 순서로서 이

순서를 통해 purge 시키지 않은 recycle bin내의 objects space 자동반환이 언제

이루어지는가를 알 수 있다.

1. recycle bin내의 objects가 차지하지 않은 free space

2. 위 1의 space를 다 쓰고도 더 필요한 경우에는 recycle bin내의 objects space를

자동으로 purge시켜 사용 (이때 FIFO에 따라 purge를 진행)

3. 위 1, 2의 space를 다 사용하고도 모자라면 tablespace의 속성에 따라 할당. 만일,

auto extensible속성을 가진다면 자동으로 free space를 할당

CF. 위 단계 2가 지나면 flashback drop은 할 수 없다.



6.3.1.4. Recycle Bin Query와 Flashback Table Drop

Command

Dropped objects에 관한 다양한 정보를 확인하기 위해 사용하는 앞서 언급한 view

“dba_recyclebin”에 정보를 잘 파악하고 있어야 한다. 다음은 그 내역이다.

Columns Description

OWNER object owner

OBJECT_NAME 변경된 object name(system generated)

ORIGINAL_NAME 원래의 object name

OPERATION Recycle Bin으로 이동시킨 사용자 Operation :

DROP, TRUNCATE

TYPE object type : NORMAL INDEX, BITMAP INDEX, NESTED

TABLE, LOB, LOB INDEX, DOMAIN INDEX, IOT TOP

INDEX, IOT OVERFLOW SEGMENT, IOT MAPPING

TABLE, TRIGGER, CONSTRAINT, Table Partition, Table

Composite Partition, Index Partition, Index Composite

Partition, LOB Partition, LOB Composite Partition

TS_NAME object가 속한 tablespace name

CREATETIME object 생성 일자(timestamp)

DROPTIME object 삭제 일자(timestamp)

DROPSCN recycle bin으로 이동된 시점의 SCN

PARTITION_NAME dropped partition name

CAN_UNDROP undrop이 가능한가를 표시 : YES, NO

CAN_PURGE purge가 가능한가를 표시 : YES, NO

RELATED parent object number

BASE_OBJECT base object number

PURGE_OBJECT purged object number

SPACE 이 object가 점유하고 있는 blocks의 수

CF. 위에서 operation column은 drop이나 truncate를 표시하지만 현재 oracle10g

는 truncated table을 대상으로 하는 flashback drop은 지원하지 않는다.

CF. 이 view를 사용하는 것도 좋지만 SQL prompt 상에서 간단한 recycle bin 내역을

보는 방법도 있다. 아래와 같은 간단한 command를 사용해 보라.

SQL> show recyclebin


표 6-3

dba_recyclebin


다음은 이런 dropped table을 복구할 때 사용하는 flashback table command의

before drop syntax이다.

SQL> flashback table table_name to before drop [rename to new_name] ;

1. Dropped table을 flashback하기 위해 지정하는 table 이름은 original 이름이어도

되고 recycle bin내에서 system generated된 이름이어도 된다. 다만, 현재 original

이름과 동일한 objects가 존재하면 original 이름으로 복구할 수는 없다. 이런

경우에는 option으로 제공하는 rename절을 사용하여 복구되는 table의 이름을

바꾸어야 한다.

2. 만일, 복구하고자 하는 table이 같은 이름으로 여러 차례 drop 및 생성이

반복되었다면 recycle bin내에는 동일한 original 이름이 복수로 존재하게 된다. 이런

경우에는 system generated 이름을 사용하여 복구를 하면 된다. 그러나 original

이름으로 복구를 진행하게 되면 LIFO 즉, 가장 마지막에 drop된 table부터 차례차례

복구가 진행될 수 있다. 물론, 복구되는 table의 이름이 현재 사용 중 이거나 동일

original 이름의 table을 계속 복구하고 있다면 위 1에서 설명한 option인 rename

절을 효과적으로 구사해야 한다.

3. flashback drop이 되면 대상 table에 종속된 즉, dependent objects도 동시에

같이 복구되며 이때 object이름은 system generated name을 사용하게 됨으로 미리

그 이름을 확인하여 복구가 끝난 후 적절한 이름으로 바꾸어줄 필요가 있다.

4. flashback drop을 수행하지 않은 상태에서도 recycle bin내의 system

generated 이름을 사용하면 dropped table에 대한 조회 작업이 가능하다. 그러나

이런 방식은 조회만을 허용할 뿐 DML은 물론 DDL command도 사용할 수 없다. 단,

이 dropped table에 대해서도 앞서 설명한 flashback query는 여전히 유효하다.

6.3.1.5. Flashback Drop Limit

이런 좋은 기능도 무조건 이루어지지는 않는다. Recycle bin으로 이동 가능한 objects

는 다음과 같은 조건을 만족해야 한다.

1. non-system tablespace에 존재해야 한다.

2. tablespace의 저장 속성은 locally management 방식 이어야 한다.

CF. 단, dependent objects가 dictionary management tablespace에 속해 있는

것은 상관없다. 이들은 모두 recycle bin의 보호 대상이다.

3. 앞선 chapter에서 살펴본 VPD, FGA와 같은 보안 기능이 적용된 table은 recycle

bin의 적용 대상이 아니다.

다음은 table이 drop될 때 같이 recycle bin을 적용하지 않는 dependent objects



형태이다. 즉, 아래와 같은 dependent objects는 flashback drop과 동시에 같이

복구되지 않는다.

1. bitmap-join indexes

2. materialized view logs

3. referential integrity constraints

4. table이 drop되기 이전에 먼저 drop된 indexes

그 밖에 flashback drop은 다음과 같은 속성들을 가진다.

1. 이미 purge된 table은 flashback drop이 되지 않는다.

2. recycle bin을 적용하기 위해 따로 설정하는 parameter는 없지만 굳이 recycle

bin을 사용하고 싶지 않다면 initial parameter file에서 hidden parameter인

“_recyclebin=false”로 설정하라.

6.3.1.6. Flashback Drop Example

이제 이 기능들을 이용하여 간단한 실습을 해보자. 이해를 빠르게 하기 위해 새로운

user를 만들어 테스트 환경을 구성하고 시작하자.

SYSTEM> create user xbin identified by xbin;

User created.

SYSTEM> grant connect, resource to xbin;

Grant succeeded.

SYSTEM> conn xbin/xbin

Connected.

XBIN> create table rbtest1 (col1 number);

Table created.

XBIN> create table rbtest2 (rcol1 number);

Table created.

XBIN> insert into rbtest1 values (1);



1 row created.

XBIN> insert into rbtest2 values (2);

1 row created.

XBIN> commit;

Commit complete.

생성된 table을 drop하고 recycle bin을 query해 보자.

XBIN> drop table rbtest1;

Table dropped.


Table dropped.


Table created.

XBIN> select * from tab;

TNAME TABTYPE CLUSTERID

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

BIN$/fXsxWhyb6/gMAB/AQA7YA==$0 TABLE

BIN$/fXsxWhxb6/gMAB/AQA7YA==$0 TABLE

RBTEST1 TABLE

XBIN> sho recyclebin

ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME

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

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



RBTEST1 BIN$/fXsxWhxb6/gMAB/AQA7YA==$0 TABLE 2005-08-10:16:06:51

RBTEST2 BIN$/fXsxWhyb6/gMAB/AQA7YA==$0 TABLE 2005-08-10:16:07:00

XBIN> select original_name, ts_name, can_undrop

2 from user_recyclebin;

ORIGINAL_NAME TS_NAME CAN

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

RBTEST1 USER_DEFAULT YES


2개의 table을 drop하고 동일한 이름의 table을 만들어 tab을 조회하자 drop된 table

이 system generated 이름을 가지고 생성되어 있음이 확인되었다. 물론, recycle bin

에서도 그 내용들이 확인되었으며 위 맨 마지막 query를 통해 모두 flashback이

가능한 상태인 것도 확인이 된다.

다음은 recycle bin으로부터 data를 읽어 insert하는 방법이 가능함을 확인하고

동일한 이름의 table이 반복적으로 drop & create가 일어날 때를 확인하자.

XBIN> insert into rbtest1

2 select * from "BIN$/fXsxWhxb6/gMAB/AQA7YA==$0";

1 row created.

XBIN> commit;

Commit complete.


Table dropped.


Table created.





ORIGINAL_NAME TS_NAME CAN

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




Flashback drop을 통해 복구를 시도하고 purge도 사용해 보자.

XBIN> flashback table rbtest1 to before drop rename to rbtestx1;

Flashback complete.

XBIN> flashback table rbtest1 to before drop rename to rbtestx2;

Flashback complete.

XBIN> purge table rbtest2;

Table purged.



no rows selected

동일한 이름의 flashback table을 연속적으로 복구했다. 물론, rename절을 사용했기

때문에 복구되면서 중복 error는 발생하지 않았다.

제대로 복구가 되었는지 확인을 해보고 dependent object의 복구 테스트를

진행해보자.

XBIN> desc rbtest1;

Name Null? Type

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

COL3 NUMBER



XBIN> desc rbtestx1

Name Null? Type

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

COL2 NUMBER

XBIN> desc rbtestx2

Name Null? Type

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

COL1 NUMBER

XBIN> create index rbindex on rbtest1 (col3);

Index created.


Table dropped.

XBIN> col org for a10

XBIN> col type for a10

XBIN> select original_name org, object_name obj,

2 type, can_undrop can from user_recyclebin;

ORG OBJ TYPE CAN

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

RBINDEX BIN$/fXsxWh0b6/gMAB/AQA7YA==$0 INDEX NO

RBTEST1 BIN$/fXsxWh1b6/gMAB/AQA7YA==$0 TABLE YES

복구를 통해 dependent object의 변화를 살펴보자.

XBIN> flashback table rbtest1 to before drop;

Flashback complete.

XBIN> select original_name org, object_name obj,



2 type, can_undrop can from user_recyclebin;

no rows selected

XBIN> select index_name, status from user_indexes

2 where table_name = 'RBTEST1';

INDEX_NAME STATUS

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

BIN$/fXsxWh0b6/gMAB/AQA7YA==$0 VALID

XBIN> alter index "BIN$/fXsxWh0b6/gMAB/AQA7YA==$0"

2 rename to rbindex;

Index altered.

Dependent object의 복구도 제대로 이루어지는 것을 확인하였다. 물론, dependent

object는 recycle bin에 있는 system generated 이름으로 복구가 되었기 때문에 그

이름을 바꾸어서 완전히 복구를 진행하는 작업도 병행하였다.

6.3.2.Flashback Table

Oracle10g에서 새롭게 제공하는 이 기법은 database online 상태에서 특정 tables을

특정 시간대로 복구하는 역할을 한다. 앞서 flashback drop이 실수로 사라져버린

table을 복구했다면 이는 실수로 삭제하거나 잘못 들어간 data를 즉, DML문장으로

변경된 data를 원하는 시점으로 되돌기 위한 기능을 제공한다.

복구하는 형태는 지정된 tables과 dependent objects의 data만 rolling back을 하는

것으로 이루어 진다. 복수로 지정이 가능하며 flashback command 자체가 하나의

transaction으로 처리되기 때문에 모두 flashback이 되던지 아니면 모두 실패하게

된다.

CF. 앞서 배운 flashback version query와 transaction query는 이 flashback

table의 시점을 결정하는데 매우 유용하게 사용될 수 있을 것이다.

6.3.2.1. Flashback Table Syntax

사실 앞서 설명한 flashback drop도 flashback table command를 통해 이루어졌다.



다만, flashback table에 주는 절의 종류에 따라 그 역할이 바뀌는 것이다. 다음은

data복구를 위한 이 command의 syntax이다.

SQL> flashback table table_name [,table lists]

to {SCN|TIMESTAMP} value

[enable|disable triggers] ;

Flashback table을 위해서는 SCN이나 timestamp를 지정해야 하며 table은 “,”로

구분된 table list를 사용하여 복수로 지정할 있다. 마지막 option인 trigger절은

flashback이 진행되는 동안 trigger의 영향을 어떻게 할 것인가를 결정한다. 만일,

enable을 지정하면 flashback process동안 지정된 table의 trigger는 그대로

유지되지만 disable을 지정하면 flashback process전에 지정된 table의 모든

enabled trigger를 disable시키고 flashback이 끝나면 enable 시킨다.

CF. trigger절의 default value는 disable이다.

6.3.2.2. Flashback Table Limit

1. 단일 transaction으로 처리됨으로 지정된 tables에 대한 flashback은 모두

성공하던지 아니면 모두 실패하며 flashback table command 자체를 rollback할 수

없다.

2. flashback이 진행되는 동안 exclusive DML lock을 획득한다.

3. 통계정보는 flashback되지 않는다.

4. flashback이 진행되는 동안 dependent indexes는 모두 그대로 유지되지만 drop

된 index가 다시 만들어지지는 않는다.

5. 지정한 table에 대하여 on-commit materialized view가 있어도 자동으로

유지된다.

6. flashback table command가 수행되면 alert.log에 기록된다.

7. 대상 table의 constraints가 flashback이 진행되는 동안 violation을 일으키면

모든 작업은 중단되고 작업 전 상태로 원상 복구된다.

8. 대상 table에 대한 DDL작업이 있었다면 이 시점보다 더 이전의 시점으로

flashback을 하는 것은 불가하다. 단, 그 DDL이 storage 속성을 변경하는 것이었다면

상관없다.

9. flashback table을 통해 data를 복구하기 위해서는 대상 table의 “row

movement”속성을 enable해주어야 한다.

10. flashback table command는 다음과 같은 objects를 대상으로 할 수 없다.

EX. Cluster, Materialized View, AQ tables, static data dictionary tables(fixed

tables), system tables, remote tables



6.3.2.3. Flashback Table Example

원활한 작업을 위해 현재의 SCN과 작업시점의 SCN등을 활용할 것이다. 이를 위해

앞서 테스트한 환경에서 권한 조절을 한 후 특정 table을 생성하여 테스트를 진행한다.

XBIN> conn sys/manager

Connected.

SYS> grant select on v_$database to xbin;

Grant succeeded.

SYS> conn xbin/xbin

Connected.

XBIN> create table fbtest (col number);

Table created.

XBIN> insert into fbtest values (1);

1 row created.

XBIN> commit;

Commit complete.

XBIN> select current_scn from v$database;

CURRENT_SCN

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

9722893828

현재 시점에 테스트 table에는 숫자 1만 들어있다.

다음은 2회의 DML문장을 각각의 SCN을 확인하면서 수행하는 과정이다. 각 SCN을

통해 flashback을 진행할 것임으로 이 SCN 값을 잘 확인해 두어야 한다.

XBIN> insert into fbtest values (2);



1 row created.

XBIN> commit;

Commit complete.


CURRENT_SCN

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

9722893848

XBIN> delete from fbtest ;

2 rows deleted.

XBIN> commit;

Commit complete.


CURRENT_SCN

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

9722893885

XBIN> select * from fbtest;

no rows selected

테스트 table에 숫자 2를 insert한 후 다시 모두 delete를 진행했기 때문에 현재

시점에는 아무 data도 없다. 드물기는 하지만 가끔씩 사용자가 실수로 where절이

없는 delete를 사용하는 경우가 있다. 바로 위의 경우처럼 말이다



만일 이 상황에서 여러분이 사용자로부터 data가 1만 있었던 시점으로 돌아가고

싶다는 요청이 있었다면 다음과 같이 하면 된다. (SCN 값을 주의 깊게 살피도록 하자)

XBIN> flashback table fbtest to scn 9722893828;

flashback table fbtest to scn 9722893828

*

ERROR at line 1:

ORA-08189: cannot flashback the table because row movement is not

enabled

XBIN> alter table fbtest enable row movement;

Table altered.


Flashback complete.


COL

----------

1

처음에는 error가 났었다. Flashback table을 통해 data를 복구하기 위해서는 대상

table에 대해 “row movement” 속성이 필요하다는 것을 알 수 있다. 정상적으로

복구가 되었다.

자 이 시점에서 사용자가 다시 원상태로의 복구를 요구했다고 하자. 즉, flashback을

하지 않은 상태를 원했다면 어떻게 할까? 물론, 위의 예는 모두 delete였으니 그냥

delete를 한번 더 수행하면 되겠지만 만일 그 작업이 delete가 아닌 많은 rows를

대상으로 하는 매우 복잡한 update였다고 생각해 보자. 그렇다면 이 기능을 제대로

사용하지 않는 한 제대로 된 data 복구는 거의 불가능하다고 해도 과언이 아니다.

다음은 data가 2건 있을 때와 현재 시점의 data가 없는 상태로의 복구를 차례로

해보는 과정이다.




Flashback complete.


COL

----------

1

2


Flashback complete.


no rows selected

자주는 아니겠지만 가끔은 매우 요긴한 기능이라 아니할 수 없다. 위의 예는 이해를

쉽게 하기 위하여 SCN을 사용했지만 실제 상황에서 사용자는 SCN을 알고 있는 경우가

별로 없을 것임으로 해당 시점을 timestamp로 지정하는 경우가 더 많을 것이다.

CF. Timestamp를 사용하는 경우 interval을 사용하면 보다 쉽게 flashback을 진행할

수 있다. 예를 들어 사용자가 전화를 해서 실수했다고 복구를 요청했다고 하자.

그렇다면 여러분은 그 사람에게 언제 그랬냐고 물을 것이고 대부분 한 5, 6분이 넘은 것

같다는 식으로 대답을 할 것이다. 이런 경우 여러분은 대략 8분여 정도의 이전 시점으로

flashback을 하기 위하여 다음과 같이 interval type을 요긴하게 쓸 수 있다.

XBIN> flashback table fbtest to timestamp

2 (systimestamp - interval '8' minute);

Flashback complete.




COL

----------

1

6.3.3.Undo Retention

지금까지 소개한 새로운 flashback 기법들은 대부분 undo segment로부터 data를

추출하는 features이다. 따라서 automatic undo management 방식을 선택하고

undo tablespace의 크기 그리고 undo retention time의 적절한 설정 등은

flashback기능을 사용하는데 있어서 매우 중요한 요소가 아닐 수 없다.

여러 번 이야기 했지만 undo data를 보존하는 시간인 undo_retention의 값은 최소

보존 예측시간이지 보장시간은 아니다. 언제든 undo space가 모자라면

undo_retention time을 지키지 않고 overwrite가 될 수 있어서 항상 이 시간만큼

flashback이 유효하다는 보장은 없다. 그러나 지금 소개하는 oracle10g의 새로운

undo tablespace 속성을 지정하는 option “retention guarantee “는 설사 space에

문제가 생기더라도 undo_retention time을 보장하는 설정을 지원한다.

먼저 다음의 SQL 결과를 보자.

SYSTEM> select tablespace_name, retention

2 from dba_tablespaces

3 where tablespace_name in ('SYSTEM', 'UNDO01');

TABLESPACE_NAME RETENTION

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

SYSTEM NOT APPLY

UNDO01 NOGUARANTEE

Tablespace에 대한 새로운 속성의 추가는 바로 관련 view에 대한 새로운 column의

추가로 나타난다. 위에서 보는 retention column은 undo retention time에 대한

보장을 할 것인가 아닌가를 나타낸다. 현재 “NOT APPLY”는 해당 tablespace가 undo

retention time과는 관련이 없음을 나타내고 “NOGUARANTEE”는 해당 tablespace

는 undo retention time에 대한 보장을 하지 못함을 의미한다. 따라서 이 속성은

undo tablespace에 대하여 적용하는 option이며 create database 또는 create

undo tablespace를 통해 설정하거나 alter tablespace를 통해 수정할 수 있다.

다음은 undo retention time을 보장하도록 설정하여 확인하는 과정이다.



SYSTEM> alter tablespace undo01 retention guarantee;

Tablespace altered.

SYSTEM> alter tablespace user_default retention guarantee;

alter tablespace user_default retention guarantee

*

ERROR at line 1:

ORA-30044: 'Retention' can only specified for undo tablespace

SYSTEM> select tablespace_name, retention

2 from dba_tablespaces

3 where tablespace_name in ('SYSTEM', 'UNDO01');

TABLESPACE_NAME RETENTION

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

SYSTEM NOT APPLY

UNDO01 GUARANTEE

오로지 undo tablespace에 한해서만 이 option이 사용됨을 알 수 있다. 또한

CF. 가장 좋은 설정은 충분한 undo tablespace 공간을 확보한 후 automatic undo

management를 채택하고 여러분이 원하는 최대한의 시간만큼 undo retention time

을 계산한 후 undo tablespace를 “retention guarantee”로 만드는 것이다. 물론,

처음에는 이 설정이 적절하지 않을 수 있지만 반복적인 운영을 통해 undo space error

의 시점과 undo space 양 을 계속 살펴보면 최적의 설정이 가능할 것이다.



OCP point

==============================================

=================

1. flashback drop limit과 dependent objects와의 관계

2. flashback table의 역할 및 기능상의 limit

3. flashback을 위해 가장 좋은 선택인 undo retention time의 설정과 retention

guarantee의 적용의 의미에 대한 이해

참조

==============================================

=================

point-in-time recovery : o8 80p

undo space error의 시점과 undo space양 : o9i 310p



6.4. Database Level Recovery

6.4.1.Flashback Database

이 부분은 정말 예상치 못했던 oracle의 새로운 기능이다. 전통적인 recovery 방식을

거치지 않고 database전체를 특정 시점으로 되돌린다는 생각은 해 본적이 없기

때문이다. 이 기능은 치명적인 사용자의 실수 즉, logical error를 복구하기 위해

database전체가 특정 시점으로 돌아가야 하는 상황에서 매우 유용할 수 있다.

CF. 그러나 logical error가 아닌 물리적으로 files에 문제가 생긴 경우에는 할 수 없이

전통적인 recovery 절차를 따를 수 밖에 없다.

요즘처럼 database의 대용량화가 일반적인 상황에서 point-in-time recovery를

하려면 restore부터 그 부담이 적지 않다. Flashback database는 “back out

changes” 즉, 변경된 내역을 되돌리는 기능을 제공함으로써 logical error에 한해

point-in-time recovery가 필요한 상황에서 상당한 시간적 여유를 줄 수 있을 것이다.

CF. 상상해 보라. Database전체가 하나의 tape에 들어 있는데 5분전 상황을 알고

싶어서 tape를 rewind하는 것으로 문제가 해결된다면 얼마나 좋겠는가.

전통적인 point-in-time recovery는 restore하려는 datafiles의 backup 시점 및

restore시간, 그리고 적용해야 할 redo log의 양에 비례했지만 flashback database

는 back out할 SCN의 수에 비례한다. 따라서 database가 커지면 키질수록 오래

걸리는 전통적인 recovery에 비해 flashback databases는 그 size가 문제되지

않는다는 점을 이해하면 이 기능이 복구성능 면에서 큰 이점을 갖는다는 것을 알 수

있다.

6.4.2.Database Configuration

Oracle10g에서 이 기능을 사용하기 위해서는 새롭게 제공되는 log인 flashback

database log가 필요하다. 이 log는 주기적으로 data block의 before image를

저장하는데 나중에 원하는 시점으로 datafiles을 back out할 때 재 사용이 가능한

형태로 기록된다. 고맙게도 이 flashback database log는 따로 관리를 해 줄 필요가

없으며 이를 저장하는 영역인 “flashback recovery area”라 불리는 공간을 할당하는

disk space만 고려대상이다. 즉, flashback database logs는 flashback recovery

area안에서 자동으로 생성, 삭제되고 관리된다.

CF. flashback database log는 archive되지 않는다. 따라서 disk관리가 매우



중요하며 disk차원에서 RAID가 되어있는 공간을 사용하는 것이 좋을 것이다.

이런 기능들은 부가적으로 log를 기록하고 적용하는 부분, 그리고 사용할 disk의 공간

등이 요구됨으로 database차원에서 몇 가지 설정이 필요하다. 정리하면 flashback

log를 담을 수 있는 SGA내의 flashback buffer와 flashback 가능시간을 지정하는

parameter를 설정하고 flashback을 enable시켜야 한다. 일단, flashback이 enable

되면 새로운 background process인 recovery writer(“RVWR”)가 활성화 되고 이

process가 SGA로부터 undo block을 담고 있는 flashback buffer의 내용을

flashback log에 write한다. 이는 마치 buffer cache로부터 모든 변경사항을 담고

redo log buffer를 LGWR가 redo log file에 쓰는 형식과 유사하다.

CF. flashback buffer가 SGA로부터 undo block만을 저장한다는 점은 큰 강점이다.

이는 곧 전통적인 recovery가 redo log file의 transaction을 역순으로 적용한다는

점에 비추어 볼 때 flashback log내의 undo block을 적용하는 flashback database

가 훨씬 효율적이라는 것을 알 수 있게 해준다.

6.4.2.1. 일반적인 속성1. 전통적으로 대용량 database에서 log buffer를 최소 8MB로 설정하는 것이

일반적이다. 이 경우 flashback database를 구성하면 flashback buffer는 이의 두

배인 16MB로 설정된다.

2. SGA에서 undo block을 flashback buffer로 옮기는 작업은 대략 10분마다

이루어진다.

3. flashback database를 구성하려면 해당 database는 archive log mode로

운영해야 한다.

4. flashback database command를 사용하여 특정 시점으로 database를 되돌릴

때에는 반드시 mount exclusive 상태에서 작업을 진행해야 한다. 이 역시도 recovery

이기 때문에 다른 사용자가 database에서 어떤 작업도 진행하면 안되기 때문이다.

5. flashback database command는 RMAN에서도 사용할 수 있다.

6. flashback database log는 query 부분은 다루지 않음으로 database의

application의 write 집중도 만이 이 log의 overhead에 영향을 준다.

6.4.2.2. Initial Parameter 설정Flashback database를 구성하기 위해서는 flashback recovery area의 위치

(db_recovery_file_dest)와 기록가능 크기(db_recovery_file_dest_size : K, M, G),

그리고 flashback 유효시간을(db_flashback_retention_target : 분 단위) 지정하는

parameters를 설정해야 한다. 이들 parameters는 모두 alter system으로 변경이

가능한 dynamic parameter이다.



CF. flashback retention time은 원하는 시간일 뿐 반드시 일치하지는 않는다.

flashback recovery area가 부족하다면 이 시간을 지켜질 수 없기 때문이다. 즉,

중요한 것은 flashback recovery area의 공간이 얼마나 충분한가에 따라 flashback

retention time도 지켜질 수 있다는 점을 놓치지 말아야 한다는 것이다.

다음은 flashback database를 구성하기 위한 전제조건인 database를 archive log

mode로 운영하기 위해 archive log parameters를 설정하는 것과 flashback 구성을

위해 관련 parameters를 설정하는 과정이다. 먼저, database를 shutdown (normal

혹은 immediate)하고 archive할 directory와 flashback recovery directory를

만든 후 parameters를 설정한다.

CF. 단, 현재 여기서는 flashback recovery area를 database install시 만들어진

위치 “/app/oracle/flash_recovery_area”를 그대로 사용할 것이다. 여러분이 다른

위치를 원한다면 해당 directory를 생성한 후 그 위치를 아래 parameter에 적용하라.

[NEWSVC]LIRACLE:/app/oracle> sqlplus / as sysdba

SQL*Plus: Release 10.1.0.4.0 - Production on Thu Aug 11 14:46:05 2005

Copyright (c) 1982, 2005, Oracle. All rights reserved.

Connected to:

Oracle Database 10g Enterprise Edition Release 10.1.0.4.0 - Production

With the Partitioning, OLAP and Data Mining options

SYS> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SYS> exit

Disconnected from Oracle Database 10g Enterprise Edition Release

10.1.0.4.0 - Production


[NEWSVC]LIRACLE:/app/oracle> mkdir -p oradata/arch/NEWSVC/



[NEWSVC]LIRACLE:/app/oracle> vi ./admin/NEWSVC/pfile/initNEWSVC.ora

…….

…….

## Archive

log_archive_dest_1 = 'LOCATION=/app/oracle/oradata/arch/NEWSVC'

log_archive_format = arch_%t_%s_%r.arc

#log_archive_start = true

…….

…….

##flashback database configuration

db_recovery_file_dest_size = 500M

db_recovery_file_dest = '/app/oracle/flash_recovery_area'

db_flashback_retention_target = 1440 # 1 day

..

..

~

~

~

:wq

[NEWSVC]LIRACLE:/app/oracle>

현재 flashback 설정은 하루 분의 변경사항까지 기록이 되도록 설정하였고 그 size는

500M까지 가능하도록 되어있다.

Database를 archive mode로 운영하기 위해 archive destination을 설정하고

format을 구성했다. 주의할 점은 oracle10g에서 compatible 값을 “10.0”이상으로

한 경우 log_archive_format을 지정할 때 반드시 default로 적용되는 resetlogs ID를

뜻하는 “%r”을 사용해야 한다는 점이다. 이를 무시하면 database는 제대로 start되지

않는다.(이는 추후 chapter 8에서 다시 설명할 것이다) 또한 oracle10g부터는

log_archive_start parameter가 obsolete되어 설정할 필요가 없음으로 이를

주석으로 처리했다.

6.4.2.3. Open Database with Flashback Mode

다음은 위에서 설정한 parameters를 가지고 database를 flashback mode로

구성하는 단계이다. 먼저, archive log mode로 database 운영방식을 변경하고

flashback mode로 database를 open하자.



[NEWSVC]LIRACLE:/app/oracle> sqlplus / as sysdba

SQL*Plus: Release 10.1.0.4.0 - Production on Thu Aug 11 15:20:33 2005

Copyright (c) 1982, 2005, Oracle. All rights reserved.

Connected to an idle instance.

SYS> startup mount

ORACLE instance started.

Total System Global Area 427819008 bytes

Fixed Size 779516 bytes

Variable Size 212081412 bytes

Database Buffers 209715200 bytes

Redo Buffers 5242880 bytes

Database mounted.

SYS> archive log list

Database log mode No Archive Mode

Automatic archival Disabled

Archive destination /app/oracle/oradata/arch/NEWSVC

Oldest online log sequence 2538

Current log sequence 2540

SYS> alter database archivelog;

Database altered.

SYS> alter database flashback on;

Database altered.

SYS> alter database open;

Database altered.



SYS> alter system switch logfile;

System altered.

SYS> archive log list

Database log mode Archive Mode

Automatic archival Enabled

Archive destination /app/oracle/oradata/arch/NEWSVC

Oldest online log sequence 2539

Next log sequence to archive 2541

Current log sequence 2541

SYS> exit

Disconnected from Oracle Database 10g Enterprise Edition Release

10.1.0.4.0 - Production


CF. flashback mode를 해제할 때에는 “alter database flashback off” command

를 사용하면 된다. 이 경우엔 현재 존재하는 flashback database logs는 모두

자동으로 삭제된다. 또한 이 database flashback command는 database open

상태에서는 사용할 수 없다.

이제 archive mode가 제대로 운영 중인지, 그리고 flashback log가 제대로 활성화

되었는지를 각각의 file과 background processes를 통해 확인해 보자.

[NEWSVC]LIRACLE:/app/oracle> cd flash_recovery_area/NEWSVC/flashback

[NEWSVC]LIRACLE:/app/oracle/flash_recovery_area/NEWSVC/flashback> ls -l

total 8020

-rw-r----- 1 oracle dba 8200192 Aug 11 15:27 o1_mf_1hovxlxn_.flb

[NEWSVC]LIRACLE:/app/oracle/flash_recovery_area/NEWSVC/flashback> cd

[NEWSVC]LIRACLE:/app/oracle/oradata/arch/NEWSVC> ls -ltr

total 57788

-rw-r----- 1 oracle dba 59108352 Aug 11 15:35

arch_1_2540_500834362.arc

[NEWSVC]LIRACLE:/app/oracle/oradata/arch/NEWSVC> cd

[NEWSVC]LIRACLE:/app/oracle> ps -ef | grep ora_

oracle 17401 1 0 15:26 ? 00:00:00 ora_pmon_NEWSVC



oracle 17403 1 0 15:26 ? 00:00:00 ora_mman_NEWSVC

oracle 17405 1 0 15:26 ? 00:00:00 ora_dbw0_NEWSVC

oracle 17407 1 0 15:26 ? 00:00:00 ora_lgwr_NEWSVC

oracle 17409 1 0 15:26 ? 00:00:00 ora_ckpt_NEWSVC

oracle 17411 1 0 15:26 ? 00:00:00 ora_smon_NEWSVC

oracle 17413 1 0 15:26 ? 00:00:00 ora_reco_NEWSVC

oracle 17415 1 0 15:26 ? 00:00:00 ora_cjq0_NEWSVC

oracle 17423 1 0 15:26 ? 00:00:00 ora_rvwr_NEWSVC

oracle 17446 1 0 15:31 ? 00:00:00 ora_arc0_NEWSVC

oracle 17448 1 0 15:31 ? 00:00:00 ora_arc1_NEWSVC

oracle 17450 1 0 15:31 ? 00:00:00 ora_qmnc_NEWSVC

oracle 17452 1 7 15:31 ? 00:00:00 ora_mmon_NEWSVC

oracle 17454 1 0 15:31 ? 00:00:00 ora_mmnl_NEWSVC

oracle 17456 1 7 15:31 ? 00:00:00 ora_j000_NEWSVC

oracle 17461 17057 0 15:31 pts/0 00:00:00 grep ora_

[NEWSVC]LIRACLE:/app/oracle>

다음은 database가 flashback mode로 구성되었는지 확인하는 SQL이다.

SYSTEM> select flashback_on from v$database;

FLA

------

YES

6.4.3.Flashback Database 수행

6.4.3.1. Flashback Database Syntax

Flashback database command를 수행하면 먼저 online redo files이나 archived

log files에 복구에 충분한 data가 있는지를 검사하게 된다. 이때 복구할 data가

부족하면 전통적인 방식의 recovery를 진행할 수 밖에 없다. 그러나 일부 datafile만

문제라면 해당 datafiles을 offline시키고 flashback database를 수행한 후 offline된

datafiles에 대해서만 전통적인 recovery를 수행하는 것은 가능하다.

다음은 flashback database command의 syntax다

SQL> flashback (standby) database to (before) {scn|timestamp} value;



1. standby option은 standby database에 대한 flashback을 구현할 때에 사용한다.

2. before option은 뒤에 지정된 시점의 바로 전 시점으로 flashback하는 것을

의미하며 before를 사용하지 않으면 지정된 시점까지 flashback하는 것을 의미한다.

CF. before에서 SCN은 지정된 SCN의 바로 전 SCN까지를 timestamp는 지정된

timestamp의 1초 전을 의미한다.

6.4.3.2. Flashback Database Example

다음의 간단한 예제를 통해 먼저 flashback database를 경험해 보자. 아래 예제는

database를 운영하는 담당자가 실수로 사용자 계정을 drop해서 이를 복구할 필요가

생긴 경우 어떻게 flashback database를 구현하는가를 보여준다.

먼저 사용자 계정을 하나 만들어 object를 생성하고 현재의 SCN을 확인한 후 해당

사용자를 drop하자.

SYSTEM> conn sys/manager as sysdba

Connected.

SYS> create user xflash identified by xflash;

User created.

SYS> grant connect, resource to xflash;

Grant succeeded.

SYS> conn xflash/xflash

Connected.

XFLASH> create table flashtest (col number);

Table created.

XFLASH> insert into flashtest values (1);

1 row created.

XFLASH> commit;



Commit complete.

XFLASH> conn sys/manager as sysdba

Connected.

SYS> select username from dba_users

2 where username = 'XFLASH';

USERNAME

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

XFLASH

SYS> select current_scn from v$database;

CURRENT_SCN

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

9722944810

SYS> drop user xflash cascade;

User dropped.

SYS> select username from dba_users

2 where username = 'XFLASH';

no rows selected

현재 사용자 계정 xflash는 존재하지 않음을 확인할 수 있다. 이제 oracle10g의

flashback database를 구현해 보자.

SYS> flashback database to scn 9722944810;

flashback database to scn 9722944810

*

ERROR at line 1:

ORA-38757: Database must be mounted EXCLUSIVE and not open to

FLASHBACK.



위와 같이 database가 open된 상태에서는 flashback database를 진행할 수 없다.

반드시 mount exclusive 상태에서 진행을 해야 한다. 이제 database를 다시

remount하여 flashback database를 진행해 보자.

SYS> shutdown

Database closed.

Database dismounted.

ORACLE instance shut down.

SYS> startup mount exclusive;

ORACLE instance started.

Total System Global Area 427819008 bytes

Fixed Size 779516 bytes

Variable Size 212081412 bytes

Database Buffers 209715200 bytes

Redo Buffers 5242880 bytes

Database mounted.

SYS> flashback database to scn 9722944810;

Flashback complete

SYS> alter database open resetlogs;

Database altered.

정상적으로 완료되었다. 주의할 점은 database를 open할 때에 반드시 resetlogs

option으로 open을 해야 한다는 점이다. 만일, database를 open하기 전에 현재의

flashback database상태가 완전한지(여러분이 원하는 시점으로 제대로 복구가

되었는지) 먼저 알고 싶다면 database를 read only mode로 open하여

확인작업을 먼저 진행할 필요가 있다. 그래서 정상적으로 확인이 되면 resetlogs로

open을 하고 아니라면 flashback database를 다시 진행하도록 한다.

다음으로 사라진 계정과 그 data가 복구되었는지를 확인하자.

SYS> conn xflash/xflash

Connected.

XFLASH> select * from flashtest;



COL

----------

1

이미 drop한 계정으로 login도 하고 해당 계정의 data도 그대로 복구되었음을 확인할

수 있다.

6.4.3.3. Monitoring Flashback Database

Flashback database를 막상 시도하려고 하면 현재 flashback이 가능한 범위가

얼마나 되는지 알아야 실수를 미연에 방지할 수 있다. 그리고 현재 workload를 볼 때

얼마나 많은 양의 flashback space가 필요한지도 알 필요가 있다. 이런 경우에

oracle10g가 제공하는 view “v$flashback_database_log”를 참조하면 좋은 정보를

얻을 수 있다.

Columns Description

OLDEST_FLASHBACK_SCN flashback data에서 가장 낮은(빠른) SCN

OLDEST_FLASHBACK_TIME 위 SCN을 시간으로 표시

RETENTION_TARGET 분으로 표시되는 기대하는 retention time

FLASHBACK_SIZE 현재 flashback data의 size (bytes)

ESTIMATED_FLASHBACK_SIZE 현재 기준으로 현재 retention time을 충족할 수

있는 flashback space의 추정 크기

다음은 실제로 현재 이 view가 가지고 있는 내역을 확인한 것이다.

SYSTEM> alter session set nls_date_format='YYYYMMDD HH24:MI:SS';

Session altered.

SYSTEM> select oldest_flashback_scn oldscn, oldest_flashback_time

oldtime,

2 retention_target rt_min, flashback_size cursize,

3 estimated_flashback_size estsize

4 from v$flashback_database_log;

OLDSCN OLDTIME RT_MIN CURSIZE ESTSIZE

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

9722944814 20050811 17:53:20 1440 99876864 114622464


표 6-4

v$flashback_database_l

og


앞서 이야기한 flashback retention time은 실제로는 flashback recovery area에

따라 달라질 수 있다고 했다. 따라서 DBA가 이 area의 size를 얼마로 할 것인가를 잘

판단하는 것은 중요한 역할중의 하나가 될 것이다. 물론, 처음에는 확실치 않더라도

지속적으로 이 area를 monitoring하는 방법이 있다면 이는 나중에 좋은 정보가 될 수

있다. 다음은 oracle10g가 제공하는 view “v$flashback_database_stat”의

내용이다.

Columns Description

BEGIN_TIME 시작 시간

END_TIME 끝 시간

FLASHBACK_DATA interval 동안 write된 flashback data (bytes)

DB_DATA interval 동안 read, write한 data block size

REDO_DATA interval 동안 write된 redo data (bytes)

ESTIMATED_FLASHBACK_SIZE interval 시간에 필요로 했던 flashback space

추정크기(마지막 시간의

v$flashback_database_log의 동일 column과

같은 값)

CF. 이 view는 대략 1시간 간격으로 data를 유지하며 최근 24시간 동안의 flashback

log에 대한 I/O overhead를 판단하는 정보를 제공해 준다.

다음은 이 view를 이용하여 각 interval이 1시간 단위로 저장이 되었다고 가정할 때

시간당 flashback log의 평균 write size를 Mega Bytes로 확인하는 SQL이다.

SYSTEM> select round(avg(flashback_data)/1024/1024, 2)

2 from v$flashback_database_stat;

ROUND(AVG(FLASHBACK_DATA)/1024

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

6.18

6.4.3.4. No Flashback Tablespace

먼저 다음의 새로운 column 정보를 확인해 보자.

SYSTEM> select name, flashback_on from v$tablespace where rownum < 4;

NAME FLA

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


표 6-5

v$flashback_database_s

tat


SYSTEM YES

UNDO01 YES

TEMP YES

위 결과는 해당 tablespaces가 모두 flashback data에 적용되는 대상이라는 뜻이다.

이는 곧 tablespace별로 flashback을 원치 않으면 이 값을 “NO”로 할 수 있다는

뜻이기도 하다. 따라서 새로운 tablespace command가 하나 추가 되었다.

SQL> alter tablespace tbs_name flashback {on|off};

Tablespace는 생성이 될 때 default로 이 값을 “on” 즉, flashback data의 대상이

되도록 설정이 되며 필요하다면 “off”를 통해 flashback data를 write하지 않을 수

있다. 그러나 이 경우(off) database flashback이 필요하게 되면 해당 tablespaces는

모두 offline으로 변경을 해야만 flashback을 진행할 수 있으며 작업이 끝난 후 offline

tablespaces를 drop하거나 전통적인 방식으로 recovery를 진행해야 완전히

정상화된 database상태로 open할 수 있다.

CF. 여러분이 직접 tablespace의 flashback 상태를 off 상태로 해 주었다고 하더라도

control file이 재생성 되는 어떤 경우라도 만나게 되면 모든 tablespaces는 다 다시

on 상태로 변경된다.

6.4.4.Flashback Database Limit

다음의 경우에는 flashback database command를 사용할 수 없으며 경우에 따라

flashback database command와 전통적인 recovery 절차를 혼합하거나

tablespace나 datafile을 offline하여 작업을 진행해야 한다.

1. control file이 restore되거나 재 생성된 경우

2. tablespace가 drop된 경우

3. datafile이 drop된 경우

4. datafile이 shrunk된 경우. 단, datafile resize가 datafile의 속성인 auto

extensible로 인하여 늘어난 것이라면 상관없다.

5. 이미 resetlogs로 open한 시점보다 앞선 시점으로의 flashback

CF.특정 tablespaces나 datafiles에 문제가 생긴 경우에는 해당 tablespaces난

datafiles을 offline 상태로 변경한 후 flashback database command를 정상적으로

진행할 수 있다. 그리고 나서 문제가 된 tablespaces나 datafiles를 전통적인 방식으로

복구하거나 아니면 포기하고 database를 open할 수 있다.



OCP point

==============================================

=================

1. flashback database의 일반적인 속성

2. flashback database와 관련 initial parameters

3. flashback mode로 database open하는 방법

4. database가 flashback mode인가 그렇지 않은가를 판단하는 view와 column

이름

참조

==============================================

=================

before image : ob 20p

standby database : o8i 122p, o8i 125p, o9i 490p



6.5. Flashback Guide

6.5.1.Corruption별 Flashback Type 과 필요환경Case or Command 추천 Flashback Type 필요한 Objects 및 기법

drop user

flashback database

flashback database

logs, flashback buffer,

RVWR process, redo

logs, archive logs

truncate table

사용자의 batch job 복구

drop tableflashback table before

droprecycle bin

commit된 변경 data 복구 flashback table

undo segments

과거 data 변경이력 추적 flashback version query

특정 시점의 transaction

내역확인 및 undo SQL

생성

flashback transaction

query

6.5.2.Flashback Privilege 와 전제 작업다음은 flashback의 종류별 권한과 제대로 된 flashback을 위해 필요한 전제 작업을

정리한 내역이다.

Flashback Type Privilege 필요한 작업

flashback database sysdba connection mount exclusive

flashback table 자기 자신의 object

권한 또는 flashback

any table, object

권한

enable row movement

flashback version query versions 절 사용

flashback transaction

query

select any

transaction

enable supplemental

logging

6.5.3.Recovery 와 Flashback

다음은 전통적인 방식의 복구절차와 oracle10g의 flashback을 비교한 내역이다.

구분 flashback 방식 전통적인 recovery

총 작업 시간 빠르다 느리다.

restore 형태 changed data datafiles

access 유형 indexed by row, transaction database의 모든 변경내역

error 유형 논리적 오류(human error) 모든 장애

물리적 장애 불가 가능


표 6-6

Flashback Type과 조건

표 6-7

Flashback 권한과

필요작업

표 6-8

Flashback 과

Recovery


command 간단 복잡


O10g flashback 13

Documents

Transcript of O10g flashback 13