Oracle Technical Service
오라클 DB 장애 케이스 별 복구 방법 사례
복구 절차/방법 기술서
-
개요
여기에서는 오라클에서의 여러 가지 장애유형별로 복구절차에 대한 내용을 기술한다.
-
NOARHCIVELOG 모드에서의 복구
데이터베이스가 NOARCHIVELOG mode로 운영 중 데이터베이스 Crash가 발생했다면, 데이터베이스는 가장 최근의 Offline full backup을 restore하거나 full database export가 있다면 데이터베이스를 재생성하고 Data를 import함으로써 복구가 가능하다. 그러나, 이러한 경우는 가장 최근의 백업시점까지만 복구가 가능하므로 Data의 손실이 불가피하다.
-
Noarchivelog mode로 운영 중 datafile의 손실
-
상황 탐지
ORA-01157 error 발생
ORA-01157 : cannot identify data file 4 - file not found
ORA-01110 : data file 4 : '/home/orahome/data/users01.dbf'
-
복구 과정
-
사용자의 data를 포함하고 있는 경우
- 가장 최근의 offline full backup으로 부터 complete database - control files, data files, online redo log files-- 를 restore한다.
- Startup database.
- Temporary 테이블스페이스의 경우
- Startup mount
- alter database datafile '/home/orahome/data/temp01.dbf' offline drop;
- alter database open;
- drop tablespace TEMP including contents;
-
create tablespace TEMP datafile '/home/orahome/data/temp01.dbf' size 100m;
-
컨트롤파일
-
상황 탐지
만약 CKPT process가 존재 하면 CKPT process에 의해서, 그렇지 않으면 LGWR process에 의해서 error stack OPIRIP, ORA-00447, ORA-00302, ORA-00202가 발생한다.
-
ORA-00202 : CONTROL FILE : 'file name' < - 손상된 file이름 ORA-00302 : limit of %s logs exceeded ORA-00447 : fatal error in background process |
-
하나의 컨트롤파일 손실
-
복구 과정
- Shutdown abort
- 손상된 컨트롤파일을 확인하기 위해 Background process trace file을 점검한다.
- 손상된 컨트롤파일을 good control file로 대체하거나 ( OS상에서 cp등의 명령어 이용) , Init.ora의 Control_files parameter에서 손실된 컨트롤파일 이름을 삭제한다. (일반적으로, Init.ora의 ifile에 정의된 Config.ora에 Control_files parameter가 정의되어 있다.)
-
Startup
-
-
모든 컨트롤파일 손실
-
백업 컨트롤파일을 이용한 복구
백업 컨트롤파일을 사용할 경우 RESETLOGS option이용하여 데이터베이스를 Open해야 하므로, 사용할 수 있는 최후의 Option이다. 또한, RESETLOGS option을 이용하여 데이터베이스를 Open한 후 반드시 DB full backup을 해야 한다.
-
복구 과정
-
-
- Shutdown abort
- Backup 컨트롤파일을 restore한다.
- Startup mount
- Recover database using backup controlfile;
-
Alter database open resetlogs;
-
새로 생성된 컨트롤파일을 이용한 복구
'alter database backup controlfile to trace ' 명령에 의해 create controlfile script가 만들어져 있다고 가정한다.
-
복구 과정
-
- Shutdown abort
- Background process를 기동한다.
SVRMGR> startup nomount;
- 이전에 생성된 create control file script를 이용하여 CREATE CONTROLFILE 명령어를 수행한다.
- Media recovery를 수행한다.
SVRMGR> recover database ;
- DB를 Open한다.
SVRMGR> alter database open;
-
온라인 리두 로그
-
특정 group의 online redo log member 중 하나만 손실
-
상황 탐지
Redo log switch가 발생할 때, Alert.log에 ORA-00316, ORA-00312, ORA-00321가 기록된다. 추가적으로 LGWR도 ORA-00312를 발생시킨다.
-
ORA-00312 : online log 1 thread 1: 'file name' ORA-00316 : log 1 of thread 1, type %s in header is not log file ORA-00321 : log 1 of thread 1, cannot update log file header |
V$LOG의 status가 'STALE' 혹은 'INVALID'인지를 확인해야 한다.
-
복구 과정
- Invalid 이거나 Stale 상태인 redo log member를 drop한다.
SVRMGR> alter database drop logfile member 'file name';
-
Log member를 재 생성한다.
SVRMGR> alter database add logfile member 'file name' to group 1;
-
Archive된 redo log group의 손실
-
상황 탐지
LGWR process가 error stack OPIRIP, ORA-00447을 발생시킨다. LGWR의 fail은 다른 background process(PMON)의 fail도 야기한다.
-
복구 과정
-
- 손실된 log group을 drop하고 재 생성한다.
SVRMGR> alter database drop logfile group 1;
SVRMGR> alter database add logfile group 1 'log1RECO.dbf' size 500k;
- 만약 성공하지 못하면, 다음의 과정을 수행한다.
Shutdown abort
Startup mount
손실된 redo log group을 삭제한다.
SVRMGR> alter database drop logfile group 1;
Alter database open ( Crash recovery )
-
Archive되지 않은 redo log group의 손실
-
상황 탐지
ARCH process가 archival정지 메세지를 발생시킨다. – ARCH : Archival stopped, error occurred. 계속해서 online redo log의 문제를 알려 주는 ORA-00255, ORA-00312 error와 그 원인을 알려 주는 특정 error가 발생한다. 같은 error가 archival stoppage message와 함께 alert log file에도 발생한다.
-
복구 과정
-
- Shutdown abort
- Startup mount
- Alter database NoArchivelog
- 손실된 redo log를 삭제한다.
SVRMGR> alter database drop logfile group 1;
- Alter database Open ( Crash recovery )
- Shutdown normal
- Startup mount
- Alter database Archivelog
- Alter database Open
-
현재의 online redo log group의 손실
-
상황 탐지
LGWR process가 error stack OPIRIP, ORA-00447을 발생시킨다. LGWR의 fail은 다른 background process의 fail도 야기할 수 있으며, Alert.log에도 Background process fail error 메세지와 ORA-00312, ORA-00313 error가 발생한다.
-
ORA-00312: online log 1 thread 1: '/users2/chey/RECO/oradata/log1RECO.dbf' ORA-00313: open failed for members of log group 1 of thread 1 |
V$LOG와 V$LOGFILE을 통해 current log인지를 확인할 수 있다.
-
복구 과정
데이터베이스를 restore하고 Incomplete recovery를 수행해야 한다. (Archive log mode일 경우)
- Full database backup restore
- Startup mount
- Recover database until cancel
- Alter database open resetlogs
- Full database 백업을 한다.
예제) $ cp backup/*.dbf /users2/chey/RECO/oradata/ <--- Full database backup restore SVRMGR> startup <-- Database가 mount된 상태 ( startup mount ) ORACLE instance started. Total System Global Area 16963012 bytes Fixed Size 38868 bytes Variable Size 16506352 bytes Database Buffers 409600 bytes Redo Buffers 8192 bytes Database mounted. ORA-00313: open failed for members of log group 1 of thread 1 ORA-00312: online log 1 thread 1: '/users2/chey/RECO/oradata/log1RECO.dbf' ORA-01109: database not open SVRMGR> recover database until cancel ; <-- Incomplete recovery Media recovery complete. SVRMGR> alter database open ; alter database open * ORA-01589: must use RESETLOGS or NORESETLOGS option for database open SVRMGR> alter database open resetlogs; <-- RESETLOGS 를 사용하여 Open Statement processed. |
-
SYSTEM 테이블스페이스
-
System 테이블스페이스의 손실
-
상황 탐지
Disk failure를 검색하고, 그에 관련되는 data file을 찾는다.
Startup시 다음과 같은 error가 발생한다.
-
-
ORA-01157: cannot identify data file 1 - file not found ORA-01110: data file 1: '/users2/chey/RECO/oradata/systRECO.dbf' |
-
Data dictionary object의 corruption
-
상황 탐지
Data dictionary object에 ORA-1578 error가 발생하고, data dictionary corruption에 해당하는 ORA-600 error가 Alert file에 기록된다.
-
ORA-01578 : ORACLE data block corrupted (file # %s, block # %s) |
-
System 테이블스페이스의 손실에 따른 복구 과정
-
복구 과정
-
- 손상된 Datafile restore
- Startup mount
-
Alter database datafile 'system01.dbf' online;
<-- V$DATAFILE VIEW를 통해 file이 Online상태인지를 확인한다.
- Recover Database
- Alter database open
-
TEMP 테이블스페이스
-
Temporary 테이블스페이스 datafile의 손실
-
상황 탐지
Disk failure를 탐지하고 , 관계되는 Oracle file을 알아 낸다.
-
복구 과정
-
-
현재의 Temporary 테이블스페이스를 drop한다.
SVRMGR> Drop tablespace TEMP including contents;
-
다른 Temporary 테이블스페이스를 생성한다.
SVRMGR> Create tablespace TEMP datafile 'temp01.dbf' size 100m;
- 사용자에게 Temp 테이블스페이스 할당
SVRMGR> Alter user scott temporary tablespace TEMP;
-
애플리케이션 데이터파일의 손실
-
인덱스 데이터파일의 손실
-
복구 과정
- 인덱스 테이블스페이스 재생성
-
-
- Index 테이블스페이스를 drop한다.
- 다른 Index 테이블스페이스를 생성한다.
- 테이블스페이스내의 모든 Index를 재 생성한다.
-
백업을 restore하고 recover
- 테이블스페이스를 Offline한다.
- Hot backup으로부터 restore한다.
- Autorecovery를 on으로 set.
-
Recovery process를 수행한다.
Recover tablespace INDEX1.
Alter database INDEX1 online
-
테이블 데이터파일의 손실
-
복구 과정
-
-
테이블을 재생성.
- Table의 export를 import한다.
$ imp userid=system/manager tables=table_name file=exp
-
백업으로 부터 restore한 후 recover.
- 테이블스페이스를 Offline한다.
- Hot backup으로부터 restore한다.
- Autorecovery를 on으로 set.
-
Recovery process를 수행한다.
recover automatic tablespace APPL01.
Alter tablespace APPL01 online.
예제 ) Alert.log에 다음과 같은 Error가 발생한다. Errors in file /users2/chey/RECO/dump/dbwr_5757.trc: ORA-01157: cannot identify data file 4 - file not found ORA-01110: data file 4: '/users2/chey/RECO/oradata/usrRECO01.dbf' ORA-07360: sfifi: stat error, unable to obtain information about file. HP-UX Error: 2: No such file or directory SVRMGR> select status,name from v$datafile where status != 'ONLINE' ; STATUS NAME ---------- --------------------------------------------------------------- SYSTEM /users2/chey/RECO/oradata/systRECO.dbf RECOVER /users2/chey/RECO/oradata/usrRECO01.dbf <- V$DATAFILE의 STATUS를 확인한다. SVRMGR> alter tablespace USERS offline; alter tablespace users offline * ORA-01191: file 4 is already offline - cannot do a normal offline ORA-01110: data file 4: '/users2/chey/RECO/oradata/usrRECO01.dbf' $ cp usrRECO01.bak /users2/chey/RECO/oradata/usrRECO01.dbf <--- Hotbackup으로부터 USERS 테이블스페이스 datafile restore SVRMGR> set autorecovery on <-- Automatic recovery를 위해서 arhcive log는 Init.ora의 LOG_ARCHIVE_DEST에 지정된 위치에 있어야 한다. Autorecovery ON SVRMGR> Recover tablespace USERS; Statement processed. SVRMGR> alter tablespace USERS online; Statement processed. |
-
Flashback을 이용한 DELETE 복구
(ㄱ) timestamp를 이용한 방법
사용 가능 여부 조회(undo_management = auto)
SQL> show parameter undo
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_management string AUTO
undo_retention integer 1800
undo_tablespace string UNDOTBS1
권한 부여
SQL> grant execute on dbms_flashback to scott;
Grant succeeded.
현재 시간 조회
SQL> select systimestamp from dual ;
SYSTIMESTAMP
----------------------------------------
04-NOV-13 05.55.51.524776 PM +09:00
delete 작업
SQL> delete emp where deptno=20 ;
5 rows deleted.
commit
SQL> commit ;
Commit complete.
삭제 되었는지 조회
SQL> select empno from emp where deptno=20 ;
no rows selected
as of timestamp를 이용한 조회
SQL> select empno from emp as of timestamp(to_timestamp('04-NOV-13 05.55.51','DD-MON-YY:HH24:MI:SS')) where deptno=20 ;
EMPNO
----------
7369
7566
7788
7876
7902
현재 테이블에 있는지 다시 조회
SQL> select empno from emp where deptno=20 ;
no rows selected
as of timestamp를 이용해 insert
SQL> insert into emp select * from emp as of timestamp(to_timestamp('04-NOV-13 05.55.51','DD-MON-YY:HH24:MI:SS')) where deptno=20 ;
5 rows created.
commit
SQL> commit ;
Commit complete.
insert 작업 조회
SQL> select empno from emp where deptno=20 ;
EMPNO
----------
7369
7566
7788
7876
7902
-
Purge 휴지통 기능을 이용한 DROP TABLE 복구
SQL> conn scott/tiger
Connected.
SQL>
SQL>
SQL> select * from emp ;
...
14 rows selected.
SQL>
SQL> drop table emp ;
Table dropped.
SQL> commit ;
Commit complete.
SQL> select * from emp ;
select * from emp
*
ERROR at line 1:
ORA-00942: table or view does not exist
SQL> flashback table emp to before drop ;
Flashback complete.
SQL> select * from emp ;
...
14 rows selected
-
Table 을 Truncate 했을 때 복구
-
복구 과정
-
-
운영 DB 의 control file trace backup 하여 컨트롤 파일 생성 스크립작성
-
alter database backup controlfile to trace ; => udump 에 가서 trace file 을 아래와 같이 수정한다.
예)
CREATE CONTROLFILE REUSE DATABASE "TECHDATA" RESETLOGS ARCHIVELOG
MAXLOGFILES 192
MAXLOGMEMBERS 3
MAXDATAFILES 1024
MAXINSTANCES 32
MAXLOGHISTORY 4672
LOGFILE
GROUP 1 (
'/dev/rredolog01',
'/dev/rredolog11'
) SIZE 1000M,
GROUP 2 (
'/dev/rredolog02',
'/dev/rredolog12'
) SIZE 1000M,
GROUP 3 (
'/dev/rredolog03',
'/dev/rredolog13'
) SIZE 1000M,
GROUP 4 (
'/dev/rredolog04',
'/dev/rredolog14'
) SIZE 1000M,
GROUP 5 (
'/dev/rredolog05',
'/dev/rredolog15'
) SIZE 1000M,
GROUP 6 (
'/dev/rredolog06',
'/dev/rredolog16'
) SIZE 1000M,
GROUP 7 (
'/dev/rredolog07',
'/dev/rredolog17'
) SIZE 1000M,
GROUP 8 (
'/dev/rredolog08',
'/dev/rredolog18'
) SIZE 1000M,
GROUP 9 (
'/dev/rredolog09',
'/dev/rredolog19'
) SIZE 1000M,
GROUP 10 (
'/dev/rredolog10',
'/dev/rredolog20'
) SIZE 1000M
-- STANDBY LOGFILE
DATAFILE
'/dev/rtd_vg01_rlvol30'
,'/dev/rtd_vg07_rlvol35'
,'/dev/rdata08_36'
,'/dev/rtd_vg01_rlvol31'
,'/dev/rtd_vg22_rlvol17'
,'/dev/rtd_vg16_rlvol2 '
,'/dev/rtd_vg07_rlvol7 '
,'/dev/rtd_vg07_rlvol32'
,'/dev/rtd_vg07_rlvol10'
,'/dev/rdata08_06'
,'/dev/rdata16_22'
,'/dev/rdata08_65'
,'/dev/rdata08_94'
,'/dev/rti_vg23_rlvol13'
,'/dev/rti_vg21_rlvol18'
,'/dev/rti_vg15_rlvol3 '
,'/dev/rti_vg15_rlvol7 '
,'/dev/rti_vg08_rlvol5 '
,'/dev/rti_vg08_rlvol1 '
,'/dev/rindex08_04'
,'/dev/rindex08_10'
,'/dev/rindex08_11'
,'/dev/rindex04_13'
,'/dev/rindex04_19'
,'/dev/rindex08_54'
,'/dev/rtd_vg17_rlvol11'
,'/dev/rtd_vg16_rlvol1 '
,'/dev/rtd_vg14_rlvol1 '
,'/dev/rtd_vg16_rlvol3 '
,'/dev/rtd_vg17_rlvol10'
,'/dev/rdata08_15'
,'/dev/rdata08_35'
,'/dev/rdata04_22'
,'/dev/rdata16_26'
,'/dev/rtd_vg01_rlvol35'
,'/dev/rtd_vg07_rlvol8 '
,'/dev/rtd_vg15_rlvol1 '
,'/dev/rtd_vg14_rlvol7 '
,'/dev/rtd_vg17_rlvol4 '
,'/dev/rtd_vg20_rlvol9 '
,'/dev/rdata04_15'
,'/dev/rdata04_19'
,'/dev/rdata16_30'
CHARACTER SET KO16KSC5601
;
-
RAC => Single
컨트롤 파일 작성시는 테이블이 속한 TABLE, INDEX tablespace ,SYSTEM
Undo, redo, SYSAUX tablespace 포함한 datafile 을 위의 예처럼 열거한다
-
다른 DB 에서 init 파라미터를 만들어 startup nomount 한다.
startup nomount pfile='해당 경로명' ;
위의 컨트롤 파일 예처럼 control file 을 만든다. 컨트롤 파일을 만들면 자동으로 DB 는 Open 상태가 된다.
-
해당 시간 시점으로 복구
SQL>Recover database until time '2009-11-09:15:41:11' using backup controlfile ;
RAC => single로 복구 하기 위해선 해당 archive 파일을 처음 명시하여 입력해야 한다.
( 주의 auto 하면 자동으로 아카이브 파일을 못 찾는다 RAC 일 때)
해당 아카이브 모두 적용하고 데이터 베이스를 open 한다.
alter database open resetlogs ;
open 이후 alert log 를 보면 이상한 메시지들이 많이 떨어진다.
무시하고 다음 hidden parameter 적용하고 DB 를 재 기동 하여 mount까지 하고 다시
_no_recovery_through_resetlogs=TRUE
alter database open resetlogs ; 하여 open 한다.
< 참고 사항 >
아카이브 파일이 많아 파일시스템이 부족할 경우 nfs 에 마운트 하여 아카이브를 restore 할 때는 마운트 옵션을 알맞게 줘야 한다. 또한 AIX 에서나 다른 UNIX 시스템에
/etc/filesystems 에 nfs 마운트에 대한 정의를 해야 한다.
예) /etc/filesystems
/oraarch:
dev = '172.18…….
vfs = jfs2
log = /dev/hd8
mount = true
options = rw
account = false
'DB - ORACLE > Oracle Trouble Shooting' 카테고리의 다른 글
Oracle*NET DCD(DEAD CONNECTION DETECTION)과 KEEPALIVE의 관계 (0) | 2015.02.26 |
---|---|
DCD(Dead Connection Detection)설정 (0) | 2015.02.26 |
DB 백업데이타로 타 서버 DB Recovery 방법(1. 아카이브 존재 시 정상복구, 2. 아카이브 유실시 비정상복구) (0) | 2015.01.19 |
Redo Log File 장애 복구 (0) | 2015.01.19 |
접속이 느릴 때 보는 포인트 (0) | 2015.01.19 |