개발은 너무해

제목과 같이 갑자기 의문이 들었다.파일은 복사하는 중인데, 인서트는 계속 되고 있는 상황이 발생하였다.이론적으로 생각하였을 때는 아카이브 파일을 불러와 복구가 되겠다는 생각은 들어지만..정말 그렇게 될까?ㅎㅎ테스트를 해보자.session 을 sys 와 scott 계정 2개를 열었다.users 테이블스페이스를 제외한 나머지 테이블스페이스에 대해서는 미리 hotbackup을 진행 완료.users 테이블스페이스를 남겨놓기 위해 alter database begin backup; 명령어를 사용하지 않고,alter tablespace system begin backup; 명령어를 사용하였다.(참고로 작업환경은 윈도우에서 하였음.)SQL> select * from v$backup; FILE# STATUS CHANG..

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 or..

요즘 나태해지고 자만심으로 인하여 큰 화를 부르게 되었다.대용량 테이블의 2월7일이후 데이터를 삭제한다는 것이 1월7일이후 데이터를 삭제하고 말았다. 데이터 복구 할려고 처음부터 배치작업을 하게 되었고, 시간과 기존데이터와 맞지않아 또 다시 돌리고 검증하고..한마디로 개고생을 했다. 배치를 처음부터 돌리기 전에 지식인에 물어봐서 flashback이라는 것을 알게 되었다.아래와 같이 명령어를 실행을 시켰다. 그러나 워낙 큰 대용량이라서 끝날 기미가 보이지가 않았다.그래서 취소를 시키고 롤백하는데도 엄청난 시간이 걸렸다.이작업을 포기하고 배치를 처음부터 돌리기 시작하였던 것이다. insert /*+parallel(a,8)*/ into temp_pgheo_delete_table aselect /*+parall..

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 ---------------- ------------------------------------ -------------- --------..