반응형

제목과 같이 갑자기 의문이 들었다.

파일은 복사하는 중인데, 인서트는 계속 되고 있는 상황이 발생하였다.

이론적으로 생각하였을 때는 아카이브 파일을 불러와 복구가 되겠다는 생각은 들어지만..정말 그렇게 될까?ㅎㅎ


테스트를 해보자.

session 을 sys 와 scott 계정 2개를 열었다.


users 테이블스페이스를 제외한 나머지 테이블스페이스에 대해서는 미리 hotbackup을 진행 완료.

users 테이블스페이스를 남겨놓기 위해 alter database begin backup; 명령어를 사용하지 않고,

alter tablespace system begin backup; 명령어를 사용하였다.(참고로 작업환경은 윈도우에서 하였음.)


SQL> select * from v$backup;


     FILE# STATUS                CHANGE# TIME

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

         1 NOT ACTIVE             175887 12/09/23

         2 NOT ACTIVE             175909 12/09/23

         3 NOT ACTIVE             175923 12/09/23

         4 NOT ACTIVE                  0                       <-- users 테이블스페이스

         5 NOT ACTIVE             175940 12/09/23


파일 용량이 적어 미리 잽싸게 scott 계정에서 dml 작업을 하기 위해 스크립트를 만들어주었다.

* sequence 생성

SQL> create sequence seq_hot

  2  start with 1

  3  increment by 1

  4  nomaxvalue

  5  nocycle

  6  ;


* scott_insert.sql

insert into temp_hot_table select seq_hot.nextval,'AA',sysdate from dual connect by level <= 100000;

commit;

select count(*) cnt,max(id) max_id from temp_hot_table;


불완전 복구가 되었을 시 어느 단계까지 복구가 되는지 확인을 하기 위해, 단계별로 insert를 수행함.


 순서

 sys

scott 

 1

  

 @scott_insert.sql
 cnt : 100000, max_id : 100000

 2

 alter tablespace users begin backup;


 3

 

 @scott_insert.sql
 cnt : 200000, max_id : 200000

 4

$copy D:\PROD\DATA2\ORADATA\USERS01.DBF D:\PROD\BACKUP\USERS01.DBF

 @scott_insert.sql
 cnt : 300000, max_id : 300000

 5

 alter tablespace users end backup;

 

 6

 

 @scott_insert.sql
 cnt : 400000, max_id : 400000

 7

 alter database backup controlfile to 'D:\PROD\BACKUP\control.bak';

 


SQL> select * from v$backup;


     FILE# STATUS                CHANGE# TIME

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

         1 NOT ACTIVE             175887 12/09/23

         2 NOT ACTIVE             175909 12/09/23

         3 NOT ACTIVE             175923 12/09/23

         4 NOT ACTIVE             175961 12/09/23   <-- 백업이 완료 되었음.

         5 NOT ACTIVE             175940 12/09/23


백업은 완료가 되고, 해당 데이터 파일이 깨졌을 때의 상황을 만들자.


SQL> shutdown immediate;

데이터베이스가 닫혔습니다.

데이터베이스가 마운트 해제되었습니다.

ORACLE 인스턴스가 종료되었습니다.

SQL> $del D:\PROD\DATA2\ORADATA\USERS01.DBF


SQL> startup

ORACLE 인스턴스가 시작되었습니다.


Total System Global Area  612368384 bytes

Fixed Size                  1250428 bytes

Variable Size             171969412 bytes

Database Buffers          432013312 bytes

Redo Buffers                7135232 bytes

데이터베이스가 마운트되었습니다.

ORA-01157: 데이터 4 파일을 식별 또는 잠금 할 수 없습니다- DBWR 추적 파일을 보십시오

ORA-01110: 4 데이터 파일: 'D:\PROD\DATA2\ORADATA\USERS01.DBF'


데이터 파일이 깨져 복구를 해야하는 단계이다.


SQL> alter database datafile 4 offline;


데이타베이스가 변경되었습니다.


SQL> alter database open;


데이타베이스가 변경되었습니다.


SQL> $copy d:\PROD\backup\users01.dbf d:\PROD\data2\oradata\users01.dbf  : hotbackup 한 파일로 복원하자.

        1개 파일이 복사되었습니다.


SQL> recover datafile 4

매체 복구가 완료되었습니다.    <-- 데이터가 적다보니 아카이브 파일을 만들어 지지 않아 필요가 없나보다. 바로 복구가 된다.

SQL> alter database datafile 4 online;


데이타베이스가 변경되었습니다.


SQL> conn scott/tiger

연결되었습니다.

SQL> select count(*), max(id) from temp_hot_table;


  COUNT(*)    MAX(ID)

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

    400000     400000


완전 복구가 되었다...훌륭하네!ㅎㅎ

반응형
반응형

pfile의 undo_management 를 MANUAL로 수정한 후 pfil로 open 한다.


SQL> startup '$ORACLE_HOME/dbs/init$ORACLE_SID.ora;


SQL> drop tablespace undotbs1 including contents and datafiles cascade constraints;


재생성한다.

SQL> create undo tablespace undotbs1 datafile '/data1/oradata/undotbs01.dbf' size 10m

   2  autoextend on next  5m maxsize 50m;


SQL> shutdown immediate;


pfile의 undo_management 를 다시 AUTO로 수정한 후 startup 한다.



반응형
반응형
* 나는 핫백업이 끝나는 시점까지의 아카이브 파일들은 항상 백업을 해놓는다.
* 로그마이너를 사용하는데에 있어 내가 데이터를 삭제,수정한 시점을 대충이라도
   기억을 하면 좀 더 수월한 작업이 진행 되지 않을까 생각된다.

* 만약 오후 4시 10분 쯤에 DML 작업을 하였고, 그 이후에 잘못되었다는 것을 알았을 때
  archive 파일 쌓이는 곳을 확인하여 해당시간대에 쌓인 archive 파일을 dbms_logmnr 를 이용하여 복구 시킨다.


-rw-r----- 1 oracle dba 2769920 2011-08-30 16:07 1_17_760545262.dbf
-rw-r----- 1 oracle dba 2712064 2011-08-30 16:08 1_18_760545262.dbf
-rw-r----- 1 oracle dba 2759680 2011-08-30 16:09 1_19_760545262.dbf
-rw-r----- 1 oracle dba 1183232 2011-08-30 16:11 1_20_760545262.dbf
-rw-r----- 1 oracle dba 120832 2011-08-30 16:12 1_21_760545262.dbf
-rw-r----- 1 oracle dba 62976 2011-08-30 16:13 1_22_760545262.dbf
-rw-r----- 1 oracle dba 103424 2011-08-30 16:19 1_23_760545262.dbf
-rw-r----- 1 oracle dba 156160 2011-08-30 16:20 1_24_760545262.dbf
-rw-r----- 1 oracle oinstall 51224064 2011-08-30 17:04 1_25_760545262.dbf

* archive 파일이 /oracle/oradata/arch에 쌓이지만,
   arch_recovery라는 폴더를 생성하여 위 해당 파일들을 복사하였다.


cf. archive 파일 경로 확인 방법.
     show parameter log_archive_dest
     archive log list (sys계정에서만 가능)

* sys 접속
sqlplus "/as sysdba"

* archive 파일 등록
exec dbms_logmnr.add_logfile('/oracle/oradata/arch/arch_recovery/1_20_760545262.dbf');
exec dbms_logmnr.add_logfile('/oracle/oradata/arch/arch_recovery/1_21_760545262.dbf');
exec dbms_logmnr.add_logfile('/oracle/oradata/arch/arch_recovery/1_22_760545262.dbf');
exec dbms_logmnr.add_logfile('/oracle/oradata/arch/arch_recovery/1_23_760545262.dbf');
exec dbms_logmnr.add_logfile('/oracle/oradata/arch/arch_recovery/1_24_760545262.dbf');

* 등록된 archive 분석
exec dbms_logmnr.start_logmnr( options => dbms_logmnr.dict_from_online_catalog);

* 분석된 내용 조회
select * from v$logmnr_contents where operation = 'DELETE' and table_name = 'TEMP_DELETE_TABLE'; 

cf.  v$logmnr_contents : 활성화되지 않으면 조회할수 없다. 아래와 같은 에러 발생.
      ORA-01306: v$logmnr_contents에서 선택하기 전에 dbms_logmnr.start_logmnr()이 호출되어야 합니다

* 다른 계정으로 분석 데이터 복사.
create table scott.temp_logmnr_contents
select * from v$logmnr_contents where operation = 'UPDATE' and table_name='TEMP_DELETE_TABLE';

* dbms_logmnr 종료.
exec dbms_logmnr.end_logmnr;

* 데이터를 확인하여 보면 undo_sql과 redo_sql이 있다.
   로그파일 특성상 쿼리문이 저장되기 때문에 쿼리가 그대로 보여지게 된다.
반응형
반응형
요즘 나태해지고 자만심으로 인하여 큰 화를 부르게 되었다.
대용량 테이블의 2월7일이후 데이터를 삭제한다는 것이 1월7일이후 데이터를 삭제하고 말았다.

데이터 복구 할려고 처음부터 배치작업을 하게 되었고, 시간과 기존데이터와 맞지않아 또 다시 돌리고 검증하고..
한마디로 개고생을 했다.

배치를 처음부터 돌리기 전에 지식인에 물어봐서 flashback이라는 것을 알게 되었다.
아래와 같이 명령어를 실행을 시켰다. 그러나 워낙 큰 대용량이라서 끝날 기미가 보이지가 않았다.
그래서 취소를 시키고 롤백하는데도 엄청난 시간이 걸렸다.
이작업을 포기하고 배치를 처음부터 돌리기 시작하였던 것이다.

insert /*+parallel(a,8)*/ into temp_pgheo_delete_table  a
select /*+parallel(delete_table ,8)*/*
from delete_table as of timestamp(systimestamp - interval '20' minute);

이후(7시간 후가 되겠다) 다시 돌린 데이터가 작업시간 및 데이터 싱크가 맞질않아 또 다시 몇시간을 소비하게 되었고,
다시 flashback에 대해서 눈이 가기 시작하였다.

결론부터 말하면 아래명령어로 복구를 하였다. 똑같은 쿼리지만 where 을 추가하였다.
이런 단순한 생각을 못했다는게 안타까울따름이다.

alter session enable parallel dml;

insert /*+parallel(a,8)*/ into temp_pgheo_delete_table  a
select /*+parallel(delete_table ,8)*/*
from delete_table as of timestamp(systimestamp - interval '7' hour) 
where date >= '20110107' and date <= '20110109';

commit;

insert into delete_table  select * from temp_pgheo_delete_table;

복구를 완료하였다.

오늘 하루 지옥과 천당을 수천번 왔다갔다한 기분이다.

반응형
반응형

SQL> select * from tab;

TNAME                                          TABTYPE  CLUSTERID
---------------------------------- ---------- ------------
BIN$vZBAmE1rSaiCK+8QN9p98g==$0       TABLE                        : drop 된 table
BIN$JkwChjqZRbex7BzBEETFpQ==$0     TABLE                        : drop 된 table
HHH                                                    TABLE
BBB                                                    TABLE

4 개의 행이 선택되었습니다.

SQL> show recyclebin
ORIGINAL NAME    RECYCLEBIN NAME                        OBJECT TYPE  DROP TIME
---------------- ------------------------------------ -------------- -------------------

AAA                   BIN$JkwChjqZRbex7BzBEETFpQ==$0   TABLE             2008-11-30:12:13:12

GGG                  BIN$vZBAmE1rSaiCK+8QN9p98g==$0     TABLE             2008-11-29:21:02:52

SQL> conn /as sysdba

연결되었습니다.

 

SYSDBA 권한을 가진 계정은 show recyclebin 명령어가 되지 않는다.

SQL> desc dba_recyclebin

                       (sysdba권한으로 계정에 상관없이 휴지통에 있는 objects를 전부 확인할 수 있음.)

SQL> col owner for a6
SQL> col type for a6
SQL> col original_name for a15
SQL> select owner,original_name,object_name,type,droptime
  2  from dba_recyclebin;
OWNER  ORIGINAL_NAME   OBJECT_NAME                           TYPE   DROPTIME
-------- --------------- ---------------------------------- ------ -------------------

SYSTEM AAA                 BIN$8+y2KcS+QpCUoZ6Rn9sj6Q==$0 TABLE  2008-11-29:21:02:21

SCOTT   GGG                 BIN$vZBAmE1rSaiCK+8QN9p98g==$0 TABLE  2008-11-29:21:02:52

SCOTT   AAA                 BIN$JkwChjqZRbex7BzBEETFpQ==$0 TABLE  2008-11-30:12:13:12

SQL>

 

- 복구

SQL> flashback table system.aaa to before drop;

플래시백이 완료되었습니다.

SQL>

 

- 휴지통 삭제.

SQL> purge recyclebin; - 일반 계정에서 휴지통 비우기

SQL> purge dba_recyclebin; - sys권한으로 모든 휴지통 다 비우기

SQL> purge tablespace example; (해당 tablespace 내의 모든 object를 삭제)

SQL> purge tablespace example user scott;

                      (scott user에 속하는 example tablespace 내의 object를 삭제)

 

- 테이블 삭제시 휴지통에 넣지않고 바로 삭제.

SQL> drop table aaa purge;

 

일반계정은 show recyclebin 으로 지워진 object를 확인하여 복구를 하고,

sys 는 desc dba_recyclebin 으로 확인 후 복구를 할 수 있습니다.

 

- 휴지통 기능 off

 

SQL> show parameter recyclebin

NAME                       TYPE   VALUE
-------------------- ------ ---------
recyclebin                  string ON
SQL> alter system set recyclebin=off;

시스템이 변경되었습니다.

SQL>

반응형

+ Recent posts