블로그 이미지
redkite

카테고리

분류 전체보기 (291)
00.SI프로젝트 산출물 (0)
00.센터 운영 문서 (0)
01.DBMS ============.. (0)
01.오라클 (117)
001.DB 관리 (19)
002.DB 마이그레이션 (8)
003.DB 백업 및 복구 (20)
004.DB 보안 (8)
005.DB 설치 (7)
006.DB 스크립트 (0)
007.DB Knowledge Bas.. (38)
008.DB 통계 및 공간 관리 (3)
009.DB Trouble Shoot.. (14)
010.교육자료 (0)
999.테스트 (0)
01.MS-SQL (15)
01.MySQL (30)
01.PostgreSql (0)
01.DB튜닝 (28)
====================.. (0)
02.SERVER ==========.. (0)
02.서버-공통 (11)
02.서버-Linux (58)
02.서버-Unix (12)
02.서버-Windows (2)
====================.. (0)
03.APPLICATION =====.. (11)
====================.. (0)
04.ETC =============.. (0)
04.보안 (5)
====================.. (0)
05.개인자료 (1)
06.캠핑관련 (0)
07.OA관련 (1)
Total
Today
Yesterday

달력

« » 2024.4
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30

공지사항

최근에 올라온 글

Data Pump (Master Table)

      1) External Table 확장
      2) expdp, impdp
      * DB Link를 이용한 Network Mode (NETWORK_LINK 옵션)
      * Directory Object가 반드시 필요(DIRECTORY 옵션)
      * expdp 옵션에 의한 객체 단위 포함/제외 가능(EXCLUDE/INCLUDE 옵션 및 향상된 QUERY 옵션)
      * 제한적이긴 하지만 Parallel 가능(PARALLEL 옵션)
      * Master Table에 의한 중지 작업 재시작 및 작업 변경(추가 및 삭제)이 가능
      * REMAP_SCHEMA, REMAP_DATAFILE, REMAP_TABLESPACE 등 새로운 옵션

## 실습 01 ######################################################################

sqlplus system/oracle  또는 conn system/oracle

host mkdir C:\oracle10g\EXP_PUMP1
host mkdir C:\oracle10g\EXP_PUMP2

CREATE OR REPLACE DIRECTORY exp_pump_dir1 AS 'C:\oracle10g\EXP_PUMP1' ;
CREATE OR REPLACE DIRECTORY exp_pump_dir2 AS 'C:\oracle10g\EXP_PUMP2' ;

grant read, write on directory exp_pump_dir1 to public ;
grant read, write on directory exp_pump_dir2 to public ;

exit


cd c:\oracle10g\exp_pump

1)
expdp hr/hr DUMPFILE=exp_pump_dir1:exp_hr03.dmp LOGFILE=exp_pump_dir2:exp_hr03.log

expdp hr/hr DUMPFILE=exp_pump_dir:expdp_hr01.dmp NOLOGFILE=y

2)                                                                 
expdp hr/hr DIRECTORY=exp_pump_dir1 DUMPFILE=exp_hr02.dmp LOGFILE=exp_pump_dir2:exp_hr02.log

3)
set DATA_PUMP_DIR=exp_pump_dir

expdp system/oracle DUMPFILE=exp_hr_emp01.dmp NOLOGFILE=y tables=hr.employees
expdp system/oracle DUMPFILE=exp_hr05.dmp LOGFILE=exp_hr04.log SCHEMAS=hr


## 실습 02 expdp impdp 기본 옵션 ################################################

(실습 준비)

mkdir c:\oracle10g
mkdir c:\oracle10g\dptest

cd c:\oracle10g\dptest
sqlplus /nolog
conn sys/oracle as sysdba

create directory dp_test_dir as 'c:\oracle10g\dptest' ;

grant read, write on directory dp_test_dir to hr ;

conn hr/hr

create table emps03_02 tablespace example
as
  select * from hr.employees ;

insert into emps03_02 select * from emps03_02 ; --> 12회 정도 실행

commit ;

select sum(bytes)/1024/1024 AS "SIZE_MB" from user_segments
where  segment_name = 'EMPS03_02' ;

conn system/oracle

alter system checkpoint ;

exec dbms_stats.gather_table_stats('HR','EMPS03_02' -
     ,estimate_percent => dbms_stats.auto_sample_size -
     ,method_opt => 'FOR ALL COLUMNS SIZE AUTO' , cascade => TRUE) ;

select sum(bytes)/1024/1024 AS "SIZE_MB" from dba_segments
where  owner='HR' and segment_name = 'EMPS03_02' ;

exit

------------------------------------------------------------------------
## exp_test01_par01.txt 파일 작성

userid=hr/hr
directory=dp_test_dir
job_name=exptest01
logfile=exp_test01.log
filesize=2M
tables=emps03_02
estimate=statistics
estimate_only=y           <- 실제로 익스포트 안받고 확인받하는거야? 사용공간 분석이야

- 아래 애는 절대경로를 사용한다..
expdp parfile=exp_test01_par01.txt

------------------------------------------------------------------------
## exp_test01_par02.txt 파일 작성

userid=hr/hr
directory=dp_test_dir
job_name=exptest0102
logfile=exp_test0102.log
filesize=5M
tables=emps03_02
dumpfile=exp_test02_%U.dmp

expdp parfile=exp_test01_par02.txt

------------------------------------------------------------------------
## imp_test01_par03.txt 파일 작성

userid=hr/hr
directory=dp_test_dir
job_name=imptest0103
logfile=imp_test0103.log
tables=emps03_02
dumpfile=exp_test02_%U.dmp
table_exists_action=append


sqlplus system/oracle
truncate table hr.emps03_02 ;
exit

impdp parfile=imp_test01_par03.txt


## exp_test01_par04.txt  파일 작성

userid=hr/hr
directory=dp_test_dir
job_name=exptest0104
logfile=exp_test0104.log
filesize=5M
dumpfile=exp_test04_%U.dmp
EXCLUDE=VIEW
EXCLUDE=PACKAGE
EXCLUDE=INDEX:"LIKE 'EMP_%'"
EXCLUDE=TABLE:"LIKE 'EMPS03%'"
EXCLUDE=TABLE:"LIKE 'JOB%'"
QUERY=HR.employees:"WHERE department_id IN (10,20) and salary<1600"

expdp parfile=exp_test01_par04.txt


(참고)
CONTENT=METADATA_ONLY
CONTENT=DATA_ONLY
CONTENT=ALL

 

## 실습 03 Attach & JOB STOP & JOB RESTART ######################################

(준비작업)

sqlplus hr/hr

select sum(bytes)/1024/1024 AS "SIZE_MB" from user_segments
where  segment_name = 'EMPS03_02' ;

insert into emps03_02 select * from emps03_02 ; <--2회 실행

commit ;

conn system/oracle

alter system checkpoint ;

exit

## 작업내용 확인(현재 진행중이거나, 에러 후 중단된 작업내역을 확인가능.)

sqlplus /nolog
conn sys/oracle as sysdba

grant select on dba_datapump_jobs to hr ; <--조회 권한할당

conn hr/hr

desc dba_datapump_jobs

col OWNER_NAME format a10
col JOB_NAME format a15
col OPERATION format a15
col JOB_MODE format a10
col STATE format a15
set linesize 120

select * from dba_datapump_jobs ;

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

(SESSION 1)--------------------------------------------------------

## exp_test02_par01.txt 파일 작성

userid=hr/hr
directory=dp_test_dir
job_name=exptest0201
logfile=exp_test0201.log
filesize=30M
tables=emps03_02
dumpfile=exp_test0201_%U.dmp

sqlplus hr/hr


(SESSION 2)--------------------------------------------------------
cd c:\oracle10g\dptest
expdp parfile=exp_test02_par01.txt


(SESSION 1) 작업확인-----------------------------------------------

select * from dba_datapump_jobs ;  <--JOB_NAME 필드 확인


(SESSION 3) <--현재 작업중인 export에 연결.------------------------

expdp hr/hr attach=exptest0201  <--job이름

Export>


(SESSION 1)--------------------------------------------------------

select * from dba_datapump_jobs ;  <--ATTACHED_SESSIONS 수가 증가

(SESSION 3) 현재 작업 중단-----------------------------------------

Export> stop_job

yes 입력 --> 시간걸림 그동안에 다음 수행


(SESSION 1)

select * from dba_datapump_jobs ;  <--ATTACHED_SESSIONS 수가 감소

그 동안에 (SESSION 3) 중단 작업 완료
   --> 원래 SESSION 2도 중단됨

(SESSION 2) 강제 종료

(SESSION 1)

select * from dba_datapump_jobs ;  <-- NOT RUNNING

===================================================================
## 중단작업에 attach 및 작업 재시작 실습
===================================================================

(SESSION 3)

expdp hr/hr attach=exptest0201  <--job이름

Export>

(SESSION 1)

select * from dba_datapump_jobs ;


(SESSION 3) 중단 작업 재개

Export> start_job

Export> status=10  <-- 매 10초간 상태 확인

Export> continue_client <-- Session 2에서 시작된 작업인데 클라이언트가 종료되었으므로
                            Session 3에서 진행 결과를 받도록 설정.

작업완료 후에

(SESSION 1)

select * from dba_datapump_jobs ;

 

 

DBA_DATAPUMP_JOBS

>DBA_DATAPUMP_JOBS identifies all active Data Pump jobs in the database, regardless of their state, on an instance (or on all instances for Real Application Clusters). It also show all Data Pump master tables not currently associated with an active job.

Related View

>USER_DATAPUMP_JOBS displays the Data Pump jobs owned by the current user. This view does not display the OWNER_NAME column.

Column Datatype NULL Description
OWNER_NAME VARCHAR2(30)   User that initiated the job
JOB_NAME VARCHAR2(30)   User-supplied name for the job (or the default name generated by the server)
OPERATION VARCHAR2(30)   Type of job
JOB_MODE VARCHAR2(30)   Mode of job
STATE VARCHAR2(30)   Current job state
DEGREE NUMBER   Number of worker processes performing the operation
ATTACHED_SESSIONS NUMBER   Number of sessions attached to the job
DATAPUMP_SESSIONS NUMBER   Number of Data Pump sessions participating in the job

Posted by redkite
, |

아카이브 로그 모드(Archive Log Mode)란?

  우리가 오라클데이터베이스에 접속을해서 DML이나 DDL등의 명령어로 작업을 수행하면, 모든 작업의 기록이 리두로그 파일에 저장이 된다.


  작업의 양이 많아지면 리두로그파일에 기록하는 내용도 굉장히 많아지게 되겠죠. 그렇게 되면 데이터를 기록하기 위해서 리두로그파일을 늘려야 하는 일이 발생을 한다.


  그런데 오라클 리두로그파일은 계속 증가하는 것이 아니라 몇 개의 리두로그 파일을 만들어 놓고 번갈아 가면서 기록하는 구조로 되어 있다.


  이렇게 번갈아 가면서 기록을 하게 되면 새로운작업의 내용이 예전의 작업내용을 덮어쓰므로 예전의 작업한 내용을 잃게 된다는 단점이 있다. 그래서 예전의 작업한 내용에 데이터 손실이 발생하면 복구하기 어렵다는 단점이 있다.


  이런 단점을 해결하기 위한 방법이 리두로그파일의 내용을 다른 디렉토리에 자동으로 복사해서 저장하도록 운영하는 방법이다. 이렇게 운영하는 방법을 아카이브 로그 모드(Archive Log Mode)라고 한다.


  오라클데이터베이스는 기본적으로 No Archive Log Mode 이고, Archive Log Mode로 운영하기 위해서는 따로 설정을 해주어야 한다.


PFILE을 수정하여 데이타베이스를 archivelog mode로 설정하기

  NO ARCHIVE LOG 상태의 데이터베이스를 ARCHIVE LOG 모드 상태로 변경하기 위해서는 다음과 같은 순서로 작업해야 한다.


1) INIT.ORA 파라미터 파일을 수정한다.

2) 데이터베이스 인스턴스를 종료(SHUTDOWN)한다.

3) 데이터베이스 인스턴스를 MOUNT한다.(OPEN하지 않습니다)

4) 데이터베이스를 ARCHIVE LOG 모드로 변경한다.

5) 데이터베이스 인스턴스를 OPEN한다.

1) INIT.ORA파일의 parameter 수정

  INIT.ORA 파일에서 아래 부분을 수정하고, 주석(#)을 제거하고 저장합니다.


 

# 아카이브 프로세스를 오라클 시작과 함께 실행하도록 설정

# log switch 발생시 자동으로 archive를 수행 합니다

LOG_ARCHIVE_START = TRUE

 

# 아카이브 로그 파일을 저장할 디렉토리 설정

LOG_ARCHIVE_DEST = "C:\oracle\ora92\database\archive"  

 

# 아카이브 로그 파일의 이름 설정

LOG_ARCHIVE_FORMAT = %S.ARC

    

  ※ LOG_ARCHIVE_FORMAT 옵션


  - %S : redo 로그 시퀀스 번호를 표시하여 자동으로 왼쪽이 0으로 채워져 파일 이름 길이를 일정하게 만든다.


  - %s : redo 로그 시퀀스 번호를 표시하고, 파일 이름 길이를 일정하게 맞추지 않는다.


  - %T : redo 스레드 넘버를 표시하며, 자동으로 왼쪽이 0으로 채워져 파일 이름 길이를 일정하게 만든다.


  - %t : redo 스레드 넘버를 표시하며, 파일 이름 길이를 일정하게 맞추지 않는다.


2) 데이터베이스 인스턴스를 종료

 

-- SQLPLUS 실행

SQLPLUS /nolog

 

-- SYSDBA 권한으로 접속 합니다. 

SQL>CONN SYS/MANAGER AS SYSDBA

  

SQL> SHUTDOWN IMMEDIATE

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

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

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

    

3) 데이터베이스 인스턴스를 MOUNT

 

SQL> STARTUP MOUNT pfile=C:\oracle\ora92\database\INITORA9I.ORA

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

    

4) DATABASE를 ARCHIVE LOG MODE로 전환.

 

SQL> ALTER DATABASE ARCHIVELOG; 

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

    

5) DATABASE OPEN

 

SQL> ALTER DATABASE OPEN; 

    

6) ARCHIVE LOG MODE가 정상적으로 설정되어 있는지 확인한다.

 

SQL> ARCHIVE LOG LIST

데이터베이스 로그 모드              아카이브 모드

자동 아카이브             사용

아카이브 대상            C:\oracle\ora92\database\archive

가장 오래된 온라인 로그 순서     16

아카이브할 다음 로그   18

현재 로그 순서           18

    

7) 강제로 로그 스위치를 발생시켜서 아카이브 로그 파일이 저장되는지 확인

  C:\oracle\ora92\database\archive 디렉토리에 파일이 생성되었는지 확인 한다.


 

SQL> ALTER SYSTEM SWITCH LOGFILE;

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

    

ARCHIVELOG MODE에서 NO ARCHIVELOG MODE로 전환하기

  먼저, 위에서 setting 했던 INIT.ORA 파일에서 설정했던 부분을 (#)으로 주석처리 한다.


 

#LOG_ARCHIVE_START = TRUE

#LOG_ARCHIVE_DEST = "C:\oracle\ora92\database\archive"  

#LOG_ARCHIVE_FORMAT = %S.ARC


-- 데이터베이스 종료

SQL> SHUTDOWN IMMEDIATE

 

-- 데이터베이스 인스턴스를  mount 

SQL> STARTUP MOUNT pfile=C:\oracle\ora92\database\INITORA9I.ORA

 

-- 데이터베이스를  no archive log mode로 전환.

SQL> ALTER DATABASE NOARCHIVELOG;

 

--  database open

SQL> ALTER DATABASE OPEN; 

 

-- 아카이브 로그 모드 상태 확인

SQL> ARCHIVE LOG LIST 

데이터베이스 로그 모드              아카이브 모드가 아님

자동 아카이브             사용 안함

아카이브 대상            C:\oracle\ora92\RDBMS

가장 오래된 온라인 로그 순서     17

현재 로그 순서           19    

    

SPFILE(서버 파라미터 파일)을 수정하여 데이타베이스를 ARCHIVELOG MODE로 설정

  Oracle9i 이상의 경우 서버 파라미터 파일을 사용 할 경우 아래와 같은 과정을 거쳐서 아카이브 로그모드로 변경해야 한다.


 

1) 파라미터 설정

 

-- sqlplus 실행

SQLPLUS /nolog

 

-- SYSDBA 권한으로 접속 합니다. 

SQL> CONN / AS SYSDBA

 

-- LOG_ARCHIVE_START 파라미터 변경

SQL> ALTER SYSTEM SET 

     LOG_ARCHIVE_START=TRUE SCOPE=SPFILE;

 

-- LOG_ARCHIVE_DEST 파라미터 변경

SQL> ALTER SYSTEM SET 

     LOG_ARCHIVE_DEST='C:\oracle\ora92\database\archive' 

     SCOPE=SPFILE;

 

-- LOG_ARCHIVE_FORMAT 파라미터 변경

SQL> ALTER SYSTEM SET 

     LOG_ARCHIVE_FORMAT='%S.ARC' SCOPE=SPFILE;

 

 

2) DB Shutdown 

SQL> SHUTDOWN IMMEDIATE

 

 

3) Mount 상태로 Startup

SQL> STARTUP MOUNT

 

 

4) 아카이브 로그 모드 활성화

SQL>ALTER DATABASE ARCHIVELOG;

 

 

5) 데이타베이스 오픈

SQL> ALTER DATABASE OPEN; 

 

 

6) 아카이브 로그 모드가 정상적으로 설정되어 있는지 확인한다.

SQL> ARCHIVE LOG LIST;

데이터베이스 로그 모드              아카이브 모드

자동 아카이브             사용

아카이브 대상            C:\oracle\ora92\database\archive

가장 오래된 온라인 로그 순서     17

아카이브할 다음 로그   19

현재 로그 순서           19    

    

SPFILE(서버 파라미터 파일)에서 NO ARCHIVE LOG모드로 전환하기

 

1) 자동 아카이브 모드를 false로 변경 한.

SQL> ALTER SYSTEM SET 

     LOG_ARCHIVE_START=FALSE SCOPE=SPFILE;

 

 

2)DB shutdown 

SQL> SHUTDOWN IMMEDIATE

 


3) mount 상태로 startup

SQL> STARTUP MOUNT

 


4) 데이터베이스를  no archive log mode로 전환.

SQL> ALTER DATABASE NOARCHIVELOG;

 

 

5) 데이타베이스 오픈

SQL> ALTER DATABASE OPEN; 

 

 

6) 아카이브 로그 모드 상태 확인

SQL> ARCHIVE LOG LIST;

데이터베이스 로그 모드              아카이브 모드가 아님

자동 아카이브             사용 안함

아카이브 대상            C:\oracle\ora92\database\archive

가장 오래된 온라인 로그 순서     17

현재 로그 순서           19    

    

10g에서는 

ALTER SYSTEM SET LOG_ARCHIVE_START=TRUE, FALSE SCOPE=SPFILE; 

제외하고 archive mode or noarchive mode 로 설정하시면 됩니다. 

그렇지 않고 

ALTER SYSTEM SET LOG_ARCHIVE_START=TRUE, FALSE를 실행한다면 아래와 같은 에러가 발생합니다. 

"ORA-32004: obsolete and/or deprecated parameter(s) specified"



SQL> archive log list 

Database log mode Archive Mode 

Automatic archival Enabled 

Archive destination /u02/oracle/DB/arch/arch 

Oldest online log sequence 4 

Next log sequence to archive 6 

Current log sequence 6 

SQL> show parameters log_archive_dest_1 


NAME TYPE VALUE 

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

log_archive_dest_1 string LOCATION=/u02/oracle/DB/arch/a 

rch MANDATORY REOPEN 

log_archive_dest_10 string 

SQL> alter system set log_archive_dest_1='LOCATION=/u02/oracle/DB/arch2/arch MANDATORY REOPEN' scope=both ; 


System altered. 


SQL> !ls -lrt /u02/oracle/DB/arch2/ 

total 0 


SQL> alter system switch logfile ; 


System altered. 


SQL> !ls -lrt /u02/oracle/DB/arch2/ 

total 17356 

-rw-r----- 1 oracle oinstall 17746432 Dec 20 11:16 archTLO_1_6_735939596.dbf 

Posted by redkite
, |

Closed 백업(=Cold 백업)

  - Closed 백업은 데이터베이스가 Shutdown된 상태에서 백업을 하는 방법을 의미합니다.

  - ARCHIVE LOG MODE와 NOARCHIVE LOG MODE 둘 다 가능합니다.

  - 모든 DATA FILE, CONTROL FILE, REDOLOG FILE이 대상입니다.(정상적인 종료(normal, transactional, immediate)는 REDO LOG FILE을 반드시 백업할 필요는 없으나 복구할 때 간단하게 하기 위하여 백업을 해 두는 것이 좋습니다.)

  - 초기화 파라미터 파일은 변경되었을 경우에는 백업해 놓습니다.

  - 개념적으로 단순하여, 백업 및 복구방법이 용이 합니다.

  - NOARCHIVE LOG MODE일 경우에는 백업받은 시험 이후의 데이터는 보장하지 않으므로 장애가 발생하였을 경우는 변경된 사항은 수동으로 입력해 주어야 합니다.

1. 데이터파일, 컨트롤 파일, redo 로그 파일의 위치와 이름을 확인한다.
 
-- sqlplus를 실행합니다.
C:\> SQLPLUS /NOLOG

-- SYSDBA권한으로 접속합니다.
SQL> CONN / AS SYSDBA

-- Controlfile의 위치 및 이름을 확인합니다.
SQL> SELECT name FROM V$CONTROLFILE;




-- 데이터 파일들의 위치 및 이름을 확인합니다.
SQL> SELECT name,status FROM V$DATAFILE;




--Redo Log 파일들의 위치 및 이름을 확인 합니다.
SQL> SELECT * FROM V$LOGFILE;


    

2. 데이터베이스를 shutdown 합니다.
 
  
    

3. 대상 파일들을 전부 백업(copy)합니다.
 
  
    

4. 데이터베이스를 오픈 합니다.
 
  

Posted by redkite
, |

COLD BACKUP(오프라인 백업)

  - COLD BACKUP이란 오라클 SHUTDOWN후 DATAFILE, REDO LOG FILE, CONTROL FILE, PARAMETER FILE등을 OS의 복사명령으로 백업을 수행하는 방법을 말한다.

  - 백업받을 파일들의 목록은 V$DATAFILE, V$LOGFILE, V$CONTROLFILE에서 찾을 수 있다.

  - COLD BACKUP을 위해서 데이타베이스를 SHUTDOWN 할 때에는 NORMAL, IMMEDIATE 옵션을 사용해야 하며 ABORT 를 사용해서는 안 된다. ABORT 를 사용한 경우에는 SHUTDOWN 후에 다시 STARTUP 하고 NORMAL 로 SHUTDOWN 하도록 한다.

  - SHUTDOWN ABORT 옵션을 쓸 경우 Checkpoint 정보가 일치하지 않아 복구가 수행되지 않을 수 있으므로 이 옵션을 사용하지 말아야 한다.

  - SHUTDOWN 하지 않고 OPEN 된 상태에서 백업을 받으면 백업받은 내용을 나중에 사용할 수가 없으므로 유의해야 한다.

  - 콘트롤 화일과 데이타 화일 및 로그 화일의 위치를 확인하여 이들을 tar, cpio 등의 명령을 이용하여 백업 받도록 한다.

  - NT 에서는 COPY 명령이나 탐색기를 이용해서 백업을 받으면 된다.

  - 장점 : 읽기 일관성이 보장됨, 가장 간편하다.

  - 단점 : 데이터베이스 SHUTDOWN이 필요하므로 백업받는 동안 데이터베이스를 사용할 수 없으며, 백업이 수행된 시점까지만 복구가 가능하다

파일확인 방법

  오라클은 반드시 SHUTDOWN된 상태이어야 하며, 아래에서 확인한 세 종류의 파일들을 OS명령어(ex cp)로 백업받으면 된다. 필요에 따라서 파라미터(init.ora) 파일까지 받아두는 것이 좋다.

 
-- Oracle 8.1.7 sqlplus에서 system/manager로 접속

-- 콘트롤 파일 확인 
SQL> SELECT name FROM V$CONTROLFILE;

NAME
------------------------------------------
C:\ORACLE\ORADATA\ORACLE\CONTROL01.CTL
C:\ORACLE\ORADATA\ORACLE\CONTROL02.CTL
C:\ORACLE\ORADATA\ORACLE\CONTROL03.CTL


-- 데이타 파일 확인 
SQL> SELECT name FROM V$DATAFILE;

NAME
--------------------------------------------------
C:\ORACLE\ORADATA\ORACLE\SYSTEM01.DBF
C:\ORACLE\ORADATA\ORACLE\INDX01.DBF
C:\ORACLE\ORADATA\ORACLE\TOOLS01.DBF
C:\ORACLE\ORADATA\ORACLE\USERS01.DBF
C:\ORACLE\ORADATA\ORACLE\STORM.DBF
C:\ORACLE\ORADATA\ORACLE\STORMIDX.DBF
C:\ORACLE\ORADATA\ORACLE\TEST.DBF


-- 로그 파일 확인
SQL>SELECT member FROM V$LOGFILE; 

MEMBER
------------------------------------
C:\ORACLE\ORADATA\ORACLE\REDO03.LOG
C:\ORACLE\ORADATA\ORACLE\REDO02.LOG
C:\ORACLE\ORADATA\ORACLE\REDO01.LOG 
    

오프라인 복구 예제

  COLD BACKUP 백업에 대한 복구는 장애가 발생한 시점까지가 아니라, 가장 최근의 백업시점 까지만 복구가 가능 하며, 백업 시점에서 현 시점까지의 데이터는 모두 잃어 버리게 된다.

동일한 디스크에 위치한 데이터파일 복구

  1. DB를 SHUTDOWN ABORT로 닫는다.

  2. 백업해두었던 DATAFILE, REDO LOG FILE, CONTROL FILE, PARAMETER FILE(init.ora) 들을 현재의 DB 데이터파일들이 위치한 곳으로 이동 시킨다(copy 작업).

  3. STARTUP MOUNT를 수행 한다.

  4. ALTER DATABASE OPEN RESETLOS 수행

상이한 디스크에 위치한 데이터파일 복구

  만일 디스크가 교체될 수 없는 경우, 파일들을 다른 디스크로 이동시켜 복구한다.

  1. DB를 SHUTDOWN ABORT로 닫는다.

  2. 백업해두었던 DATAFILE, REDO LOG FILE, CONTROL FILE, PARAMETER FILE(init.ora), PASSWORD FILD(orapwSID) 들을 다른 디스크로 이동

  3. PARAMETER FILE에서 CONTROL_FILES 파라미터를 수정한다.

  4. STARTUP MOUNT EXCLUSIVE 수행

  5. 새로운 디스크에 위치한 데이터파일들의 위치를 control파일에 갱신

 
ALTER DATABASE RENAME 
FILE '/u01/oracle/data/data01.dbf' 
TO '/u02/oracle/data/data01.dbf'
    

  6. DB백업(형식적인 절차)

  7. ALTER DATABASE OPEN RESETLOGS 수행

Posted by redkite
, |
1. raw device에는 LVCB(Logical Volume Control Block)가 있지만
   file system에는 없음.

 

   - bs    : 파일 입출력의 block(버퍼) 크기

   - skip  : 입력 파일에서 처리하지 않고 통과할 블록의 개수
             (Raw Device to Filesystem 복사 시 지정해야 함)
   - seek  : 출력 파일에서 처리하지 않고 통과할 블록의 개수
             (Filesystem to Raw Device 복사 시 지정해야 함)

   - count : 복사할 회수 or 블록의 개수 (생략 시 모든 데이터 복사 )

             (Raw Device to Filesystem 복사 시 반드시 명시해야 함,
              그 이외의 경우는 생략 가능)

플랫폼
LVCB
플랫폼
LVCB
Solaris
0
True64
64KB
HP-UX
0
Linux
0
AIX
4KB
Windows
0

 

2. dbfsize로 확인

   $ORACLE_HOME/bin/dbfsize <Oracle Datafile 명>

   [file system 결과]
   /data05/TESTDB] dbfsize UNDO01_01.dbf
   Database file: UNDO01_01.dbf
   Database file type: file system             : File Type
   Database file size: 128000 8192 byte blocks :8192 byte Block이 128000 개

 

   [raw device 결과]

   Database file type: raw device             :

File Type
   Database file size: 1408 8192 byte blocks  : 8192 byte Block이 1408 개

   ※ dbsize로 조회한 결과(Dictionary View에서 select로 조회한
      block 수도 마찬가지)에는 Datafile Header Block 및 LVCB가 포함되지 않음
 
      다음과 같은 경우에는 파일이 손상된 경우이므로 다시 복사
      Header block file size is bad;            trying raw file format...
      Header block magic number is bad
 
3. 참고사항
1) Raw Device 에서 Filesystem으로 변환
   dd if=/dev/rv_data001 of=/data01/TESTDB/data001.dbf bs=4096
      skip=1 count=2818
2) Filesystem 에서 Raw Device로 변환
   dd if=/data01/TESTDB/data001.dbf of=/dev/rv_data001 bs=4096 seek=1
3) Raw Device 에서 Raw Device로 복사
   dd if=/dev/re_data001 of=/dev/rv_data001_bk bs=4096 skip=1 seek=1
4) Filesystem 에서 file system으로 복사
   cp /data01/TESTDB/data001.dbf /data01/TESTDB/data001.bak
Posted by redkite
, |
1. export / import
  가. 여러개의 테이블 중에서 특정 table만 백업/복구 하고자 할 때
  나. 오라클의 버전, 플랫폼이 서로 다른 상황에서의 서버간 데이터 이동 시(migration)

2. export 방식
  가. Conventional Path export : Evaluation Buffer를 사용하는 방식, DB Buffer cache에서 필요데이터를 Evaluation Buffer로 복사 후 데이터를 가공(text -> binary)하여 디스크에 파일로 저장함. export 작업 중에 발생하는 DDL, DML 등의 명령들은 백업파일에 반영되지 않는다.(백업 파일은 Evaluation Buffer을 이용하여 작업하기 때문)

  나. Dircet Path export : DB Buffer Cache에서 데이터를 가공(text -> Binary)하여 디스크에 파일로 저장함, export 명령 이후에 백업대상이 되는 테이블스페이스나 테이블에 Lock이 발생하기 때문에 DDL, DML 작업은 실패 또는 보류 된다.

사용자 삽입 이미지사용자 삽입 이미지



3. export 옵션 및 사용예제
  가. 옵션
    - userid/passwd : export를 수행하는 계정/패스워드
    - buffer : Evaluation Buffer크기 지정(용량이 클 수록 export 작업이 빨라진다)
    - file : export 결과를 저장할 파일명
    - full : 전체 DB를 export 할 것인가 지정
    - owner : export 받을 사용자 이름지정
    - tables : export 받을 테이블 이름 지정
    - tablespaces : exprot 받을 테이블스페이스 이름지정
    - parfile : export 옵션을 미리 지정한 파라미터 파일지정

  나. 사용예제
exp system/oracle full=y file=/backup/export/test01.dmp

exp system/oracle full=y file=/backup/export/test02.dmp direct=y

exp system/oracle tables=emp \
file=('/backup/export/test03_1.dmp', '/backup/export/test03_2.dmp') filesize=10M

exp system/oracle tablespaces=(example, undotbs1) file=/backup/export/test04.dmp

exp system/oracle file=/backup/export/test05.dmp owner=(scott, hr)

exp system/oracle file=/backup/export/test06.dmp full=y buffer=1024000

vi par_full.dat
file=/backup/export/test07.dmp
full=y
dircet=y

exp system/oracle parfile=par_full.dat

exp scott/tiger query=\"where ename like \'F%\'\" tables=emp \
file=/backup/export/test07.dmp


4. import 옵션 및 사용예제
  가. 옵션(export의 옵션과 유사하다)
    - userid/passwd : import를 수행하는 계정/패스워드
    - buffer : Evaluation Buffer크기 지정(용량이 클 수록 import 작업이 빨라진다)
    - full : export  파일의 모든 데이터를 import 한다.
    - file : import 할 export 파일명 지정
    - show : 데이터를 import 하지 않고 내용만 확인함
    - ignore : import 작업 중 발생할 수 있는 에러를 무시하고 다음단계의 작업을 진행함
    - fromuser : export 할 당시의 object의 소유자 지정
    - touser : import 할 object의 새 소유자 지정
    - tables : import 할 테이블 이름 지정
    - parfile : import 옵션을 미리 지정한 파라미터 파일지정

  나. 사용예정

imp system/oracle file=/backup/export/test01.dmp ignore=y full=y

imp system/oracle file=/backup/export/test02.dmp \ 
fromuser=scott touser=hr ignore=y

imp system/oracle file=/backup/export/test03.dmp full=y show=y log=test03.log


참고 : export/import 계정
import 할 때 사용하는 계정은 export 할 때 사용한 계정이어야 한다. 이 계정이 같지 않으면 import 수행 시 오류가 발생한다.만일 export 계정을 잊었다면 덤프파일을 vi 편집기로 열어 확인할 수 있다.(2번째 줄)
참고 : import 작업 중 에러발생 시
import 작업을 진행하던 도중 에러가 발생해 같은 작업을 반복하게 되면, import 대상이 되는 테이블(제약조건이 없는)에 데이터가 중복 저장될 수 있다. 그러므로 같은 작업을 반복시에는 import 대상이 되는 테이블의 내용을 지우고(drop 또는 truncate) 진행해야 한다.
참고 : SYS 계정으로 생성된 Object export
일반적으로 SYS계정에서 생성된 객체는 export 명령어로 백업할 수 없으므로 주의해야 한다.
(단, 경우에 따라서 system 계정으로 백업이 가능하기도 하다)

4. Import 대상 서버에서 필요한 사전 작업
  가. Export 한 서버와 동일한 Tablespace 생성
  나. 충분한 크기의 Temporary Tablespace 확보
  다. Export 한 서버와 동일한 사용자 생성


참고 : 오라클 레퍼런스 사이트

Export and Import Modes : http://docs.oracle.com/cd/B19306_01/server.102/b14215/exp_imp.htm#i1004890

Export Parameters : http://docs.oracle.com/cd/B19306_01/server.102/b14215/exp_imp.htm#CEGFIAGE

Import Parameters : http://docs.oracle.com/cd/B19306_01/server.102/b14215/exp_imp.htm#i1021478  

* export

- 전체 데이터베이스가 export 방법

ex.) C:>exp userid=system/manager file='C:/full.dmp' full=y
- 서비스명 포함
ex.) C:>exp userid=system/manager@서비스명 file='c:/full.dmp' full=y
- exp-00091 불완전한 통계를 엑스포트 중입니다. 메시지 출력시 (oracle 버전 확인과 NLS_LANG가 달라서 발생)
ex.) C:>exp userid=system/manager@서비스명 file='c:/full.dmp' full=y statistics=none
이관 데이터에는 상관없고 실행 후 dbms_stats.gather_schema_stats 를 사용하여 통계정보를 생성하면 됨


- user별 EXPORT하는 방법.
ex.) C:>exp userid=scott/tiger file='C:scott.dmp'
- SYSTEM/MANAGER로 접속한 DBA가 여러 user소유의 오브젝트들을 EXPORT 하는 방법
ex.) C:>exp userid=system/manager owner=scott file='C:scottuser.dmp'
- system user로 다른 유저의 table 몇 개만 Export하는 방법
C:>exp userid=system/manager file='C:exp.dmp' tables=(scott.EMP, scott.DEPT)
=> 위와 같이 table의 schema(user)명까지 지정해야만 export가 성공합니다.
- scott user로 table 몇 개만 EXPORT하는 예
C:>exp userid=scott/tiger file='C:exp.dmp' tables=(EMP, DEPT) log=exp.log
추가 옵션
full=y : 전체 데이터 추출 여부 (기본값 n)
direct : 직접경로 방식으로 export(기본값 n)
indexs : 인덱스 포함 여부(기본값 y)
triggers : 트리거 포함 여부(기본값 y)
rows=n : 오브젝트에 대한 정의만 export (테이블의 저장된 데이터는 export 제외)
buffer : 작업 단위 크기 설정
compress : 익스텐트 통합여부 지정(기본값 y)
grants : 오브젝트 권한 설정에 대한 정보 추출 여부(기본값 y)
log : 로그를 저장할 파일 지정
row : 테이블의 데이터 추출 여부(기본값 y)
consistents : 대상 테이블의 읽기 일관성 지정(기본값 n)
prfile : 필요한 옵션을 파라미터 파일에 설정한 후 해당 파라미터 파일을 export 시 적용
query : 쿼리 조건에 맞는 데이터만 적용 ex) query=\"where id\=100\"

Export 활용

TIP1.COMPRESS 옵션은 모든 익스텐트를 하나의 익스텐트로 통합하여 구성하는 옵션이다. 이 경우 하나의 데이터 파일로만 모든 데이터가

적재되기 때문에 I/O분산 측면에서 분리하다. 그러므로 실제 운영에서는 이와 같이 익스텐트들이 통합되는 것은 좋지 않으므로 Export를 수행할

경우 반드시 COMPRESS 옵션을 N으로 설정하기를 권장한다.

TIP 2. DIRECT 옵션은 오라클 메모리 영역인 SGA를 사용하지 않고 Export를 수행하는 옵션이다. 직접 경로로 수행하여 추출된 파일은

Import시에도 기본적으로 직접 경로로 적재된다. 그러므로 DIRECT옵션을 Y로 설정하면 추출 및 적재 잡업시 보다 빠른 속도를 보장받을

수 있다.

TIP 3.CONSISTENTS 옵션은 Export를 수행한 시점의 데이터를 추출하게 된다. Export 중 변경된 데이터는 언두 데이터를 이용하여 이전 값을

추출하게 되는데 이때 'Snap Shot Too Old' 에러가 발생하기 쉽다. 그래서 CONSISTENTS옵션을Y로 설정하기를 권장한다.

TIP 4. STATISTICS 옵션은 oracle 9i버전에서 특수 통계정보를 수집하는 옵션이다. "EXP-00091: 불완전한 통계를 엑스포트 중입니다." 에러가

발생하지 않게 하기 위해서는STATISTICS옵션을NONE으로 설정하기를 권장한다.


* import
-전체 데이터베이스가 IMPORT됩니다. (Full Level)
C:>imp userid=system/manager file='C:full.dmp' full=y

- scott의 유저 IMPORT를 실행 합니다.(User Level)
C:>imp userid=scott/tiger file='C:scott.dmp'

- 다른 계정으로 IMPORT하기
scott유저의 데이터를 EXPORT받아서 test 유저에게 IMPORT하는 예제 입니다.
C:>exp userid=system/manager file='C:scott.dmp' owner=scott
C:>imp userid=system/manager file='C:scott.dmp' fromuser=scott touser=test

===================================================================================
오라클 홈디렉토리 또는 Base 디렉토리에 가시면 bin 디렉토리가 있습니다.
bin 디렉토리 안에는 여러가지 툴이 있는데 그중에 exp 와 imp 가 mysql dump 와 같은 기능을
가지고 있습니다.
exp help=y 하시면 도움말이 나옵니다.
대화형식으로 백업 하시려면 exp 만 치시면 순서대로 필요한 사항을 입력하시면 dump 가능하
구요
예제) exp scott/tiger file=/home/backup/daily_backup.dmp
log=/home/backup/daily_backup.log grants=y
물론 위의 디렉토리에는 oracle user의 쓰기 권한이 있어야 겠지요.
imp 인경우도 도움말을 보시면 편합니다.
예제) imp scott/tiger file=/home/backup/daily_backup.dmp
log=/home/backup/daily_backup_imp.log ignore=y grants=y buffer=2048000 full=y
여기서 log 는 imp , exp 시 남는 log 입니다. table 이 정상적으로 export 또는 import 되는지
보여주는 옵션입니다.

 

 

exp는 보조 백업의 의미로 테이블 단위의 복구가 필요할 때 주로 사용한다.

하지만 장애시점까지의 복구가 아니라 백업받은 시점으로의 복구만 가능하다.

0. exp/imp 제한
   - Export 파일(.dmp)을 네트워크를 통해 전송할 때는 반드시

     이진(Binary) 형태로 전송
   - SQL*Net 을 이용해서 exp/imp를 수행할 수 있음

     (exp userID/password@TNS_ALIAS ...)
   - Stored Procedure, 함수, 패키지를 Import 할 때 재 컴파일의

     필요성이 생길 수 있음
   - exp 도중에 시퀀스(sequence)를 사용하게 된다면,

     시퀀스 번호는 skip 될 수 있음
   - imp할 때 Long Type의 컬럼은 언제나 성공적으로 수행되는 것은 아님

     (imp 대신 copy 명령 사용)

1. 일반적으로 많이 사용하는 exp/imp 명령어

exp userid/password file=exp.dmp owner=vnet direct=y buffer=10240000 grants=y compress=n constraints=y indexes=y rows=y feedback=10000 statistics=none log=vnet.log

imp system/qkrgustlr file=c:\vnet.dmp fromuser=vnet touser=vnet commit=y ignore=y buffer=10240000 grants=y constraints=y indexes=y rows=y feedback=10000 log=c:\imp.log
   ---------------------------------------
   % exp userid/password file=./dmp/TEST.dmp          \
         direct=y buffer=10240000 grants=y            \
         compress=n constraints=y indexes=y rows=y    \
         triggers=n tables=XXXX,YYYY,ZZZZ             \
         feedback=10000 log=./log/exp_test.log

   % imp dbaid/password file=./dmp/TEST.dmp           \
         fromuser=userid touser=otherid               \
         commit=y ignore=y buffer=10240000 grants=y   \
         constraints=y indexes=y rows=y               \
         tables=XXXX,YYYY,ZZZZ                        \
         feedback=10000 log=./log/imp_test.log

2. pipe를 통하여 백업 & 압축하는 exp/imp 명령어
   --------------------------------------------
   % rm /tmp/exp_test
   % /usr/sbin/mknod /tmp/exp_test p
   % compress </tmp/exp_test> ./dmp/TEST.dmp.Z &
   % exp userid/password file=/tmp/exp_test           \
         direct=y buffer=10240000 grants=y            \
         compress=n constraints=y indexes=y rows=y    \
         triggers=n tables=XXXX,YYYY,ZZZZ             \
         feedback=10000 log=./log/exp_test.log
   % rm /tmp/exp_test

   % rm -f /tmp/imp_test
   % /usr/sbin/mknod /tmp/imp_test p
   % uncompress<./dmp/TEST.dmp.Z> /tmp/imp_test &
   % imp dbaid/password file=/tmp/imp_test            \
         fromuser=userid touser=otherid               \
         commit=y ignore=y buffer=10240000 grants=y   \
         constraints=y indexes=y rows=y               \
         tables=XXXX,YYYY,ZZZZ                        \
         feedback=10000 log=./log/imp_test.log
   % rm -f /tmp/imp_test

    참고) exp와 imp를 연결하여 실행
          ftp가 지원되지 않고 TNS로 연결이 가능한 경우 사용한다.
          (파이프를 이용하여 exp하고 곧바로 imp로 연결하여 실행)
          % vi exp_and_imp.sh

            rm  /tmp/exp_node
            /usr/sbin/mknod /tmp/exp_node p
            exp dbaid/password@TNS_ALIAS FILE=/tmp/exp_node OWNER=us_test \

                INDEXES=n BUFFER=204800000 DIRECT=y LOG=exp_test.log &
            imp dbaid/password FILE=/tmp/exp_node FROMUSER=us_test        \

                TOUSER=us_test INDEXES=n COMMIT=y BUFFER=204800000        \

                FEEDBACK=100000 IGNORE=y LOG=imp_test.log
            rm  /tmp/exp_node
                 :wq


3. 파티션된 테이블의 파티션 exp 명령어
   --------------------------------------------
   % exp userid/password file=./dmp/TEST.dmp                     \
         direct=y buffer=10240000 grants=y                       \
         compress=n constraints=y indexes=y rows=y               \
         triggers=n tables=XXX:PT_XXX_2007,YYY:PT_YYY_2007       \
         feedback=10000 log=./log/exp_test.log

   % imp dbaid/password file=./dmp/TEST.dmp                      \
         fromuser=userid touser=otherid                          \
         commit=y ignore=y buffer=10240000 grants=y              \
         constraints=y indexes=y rows=y                          \
         tables=XXX:PT_XXX_2007,YYY:PT_YYY_2007                  \
         feedback=10000 log=./log/imp_test.log
   % rm -f /tmp/imp_test

4. FILESIZE를 이용한 SPLIT exp/imp 명령(8i)
   --------------------------------------------
   % exp userid/password file=./dmp/TEST01.dmp,                  \
                              ./dmp/TEST02.dmp,                  \
                              ./dmp/TEST03.dmp                   \
         direct=y buffer=10240000 grants=y                       \
         compress=n constraints=y indexes=y rows=y               \
         feedback=10000 filesize=100M log=./log/exp_test.log     \
         tables=TEST

   % imp dbaid/password file=./dmp/TEST01.dmp,                   \
                             ./dmp/TEST02.dmp,                   \
                             ./dmp/TEST03.dmp                    \
         fromuser=userid touser=otherid                          \
         commit=y ignore=y buffer=10240000 grants=y              \
         constraints=y indexes=y rows=y                          \
         tables=TEST                                             \
         feedback=10000 log=./log/imp_test.log

5. remote에서 exp하는 명령어
   --------------------------------------------
   % exp userid/password@TNS_ALIAS file=./dmp/TEST.dmp          \
         direct=y buffer=10240000 grants=y                      \
         compress=n constraints=y indexes=y rows=y              \
         triggers=n tables=XXXX,YYYY,ZZZZ                       \
         feedback=10000 log=./log/exp_test.log

 

참고) \는 UNIX에서 다음 라인과 이어진다는 표시의 기호임.

 

Posted by redkite
, |

RAC Archive log 모드를 NoArchive log모드로 변경

 

아카이브 로그의 모드를 변경할 때는 cluster_database를 False로 변경한 후

여러 RAC 노드 중 한 개의 노드에서만 아카이브 로그의 모드를 변경 작업하고,

cluster_database를 True로 변경한 후 startup하면 모든 RAC노드에 함께 적용된다.

 

-----------------------------------------------
[방법1] 여러 Parameter를 함께 변경할 경우
-----------------------------------------------

환경 : AIX5L Oracle10gR2 EE RAC 2-NODE, Raw Device

       (spfile도 Raw Device에 생성하여 양쪽노드가 공유)

 

0] 모든 노드 : DB SHUTDOWN

   srvctl stop instance -d RACDB -i RACDB1

   srvctl stop nodeapps -n dbhost1

   srvctl stop instance -d RACDB -i RACDB2

   srvctl stop nodeapps -n dbhost2

   (CRS stop하지 않음)

 

1] NODE 1 : DB STARTUP 상태에서 시작


   SQL> connect / as sysdba
   SQL> STARTUP NOMOUNT
   Archive log mode 확인
   SQL> archive log list
        Database log mode              Archive Mode
        Automatic archival             Enabled
        Archive destination            /arch/RACDB1
            :

 

2] NODE 1 : spfile에서 pfile 생성 후 SHUTDOWN
   SQL> !cat initRACDB1.ora
        SPFILE='/dev/rspfileRACDB'

   SQL> !cp initRACDB1.ora initRACDB1.ora.20100316
   SQL> create pfile from spfile;

   SQL> shutdown immediate

 

3] NODE 1 : initRACDB1.ora의 cluster_database 주석처리 후 저장
   SQL> !vi initRACDB1.ora
         # cluster_database           = TRUE

         RACDB1.log_archive_dest_1  = "location=/arch/RACDB1 MANDATORY"
         RACDB2.log_archive_dest_1  = "location=/arch/RACDB2 MANDATORY"
         RACDB1.log_archive_format  = RACDB%t_%s_%r.arc
         RACDB2.log_archive_format  = RACDB%t_%s_%r.arc

             # LOG_ARCHIVE_START=TRUE = TRUE # 10g에서는 사용하지 않음

 

4] NODE 1 : Noarchivelog mode 적용
   SQL> startup mount
   SQL> alter database noarchivelog;
   SQL> alter database open;
   SQL> shutdown immediate

 

5] NODE 1 : initRACDB1.ora의 주석 처리했던 cluster_database를 원상복구 후 저장
   SQL> !vi initRACDB1.ora
         cluster_database           = TRUE

         RACDB1.log_archive_dest_1  = "location=/arch/RACDB1 MANDATORY"
         RACDB2.log_archive_dest_1  = "location=/arch/RACDB2 MANDATORY"
         RACDB1.log_archive_format  = RACDB%t_%s_%r.arc
         RACDB2.log_archive_format  = RACDB%t_%s_%r.arc

         # LOG_ARCHIVE_START=TRUE = TRUE # 10g에서는 사용하지 않음

 

6] NODE 1 : spfileRACDB를 다시 생성 후 initRACDB1.ora 원상복구
   SQL> create SPFILE='/dev/rspfileRACDB' from pfile;

   SQL> !mv initRACDB1.ora.20100316 initRACDB1.ora
   SQL> !cat initRACDB1.ora
        SPFILE='/dev/rspfileRACDB'

 

7] 모든 노드 : 데이터베이스 startup

   srvctl start nodeapps -n dbhost1

   srvctl start instance -d RACDB -i RACDB1

   srvctl start nodeapps -n dbhost2

   srvctl start instance -d RACDB -i RACDB2

   Archive log mode 확인

   SQL> connect / as sysdba
   SQL> archive log list
        Database log mode              No Archive Mode
        Automatic archival             Disabled
        Archive destination            /arch/RACDB1
           :

 

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

[방법2] Parameter 중에 CLUSTER_DATABASE 만 변경할 경우

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

다른 init Parameter를 바꿀 필요없을 때는 다음과 같이 작업한다.

 

1] NODE 1 : DB STARTUP 상태에서 시작
   SQL> connect / as sysdba
   Archive log mode 확인
   SQL> archive log list
        Database log mode              Archive Mode
        Automatic archival             Enabled
        Archive destination            /arch/RACDB1
           :

 

2] NODE 1 : spfile에 cluster_database=FALSE 설정
   SQL> ALTER SYSTEM SET CLUSTER_DATABASE=FALSE SCOPE=spfile;

 

3] 모든 노드 : RAC 노드 1, 2 모두 shutdown
   srvctl stop instance -d RACDB -i RACDB1

   srvctl stop nodeapps -n dbhost1

   srvctl stop instance -d RACDB -i RACDB2

   srvctl stop nodeapps -n dbhost2

   (CRS stop하지 않음)

 

4] NODE1 : Noarchivelog mode 적용하고 Open한 후 SHUTDOWN
   SQL> connect / as sysdba
   SQL> startup mount
   SQL> alter database noarchivelog;
   SQL> alter database open;
   SQL> shutdown immediate

 

5] NODE1 : spfile에 cluster_database=TRUE 설정
   SQL> connect / as sysdba
   SQL> startup mount
   SQL> ALTER SYSTEM SET CLUSTER_DATABASE=TRUE SCOPE=spfile; 
   SQL> shutdown immediate

 

6] 모든 노드 : 데이터베이스 startup 
   srvctl start nodeapps -n dbhost1

   srvctl start instance -d RACDB -i RACDB1

   srvctl start nodeapps -n dbhost2

   srvctl start instance -d RACDB -i RACDB2

   No Archive log mode 확인

    SQL> archive log list
        Database log mode              No Archive Mode
        Automatic archival             Disabled
        Archive destination            /arch/RACDB1

 

Posted by redkite
, |

RAC NoArchive log 모드를 Archive log모드로 변경

 

아카이브 로그의 모드를 변경할 때는 cluster_database를 False로 변경한 후

여러 RAC 노드 중 한 개의 노드에서만 아카이브 로그의 모드를 변경 작업하고,

cluster_database를 True로 변경한 후 startup하면 모든 RAC노드에 함께 적용된다.

 

-----------------------------------------------
[방법1] 여러 Parameter를 함께 변경할 경우
-----------------------------------------------

환경 : AIX5L Oracle10gR2 EE RAC 2-NODE, Raw Device
       (spfile도 Raw Device에 생성하여 양쪽노드가 공유)

 

0] 모든 노드 : DB SHUTDOWN
   srvctl stop instance -d RACDB -i RACDB1

   srvctl stop nodeapps -n dbhost1

   srvctl stop instance -d RACDB -i RACDB2

   srvctl stop nodeapps -n dbhost2

   (CRS stop하지 않음)

 

1] NODE 1 : DB STARTUP 상태에서 시작
   SQL> connect / as sysdba
   SQL> STARTUP NOMOUNT
   Archive log mode 확인
   SQL> archive log list
        Database log mode              No Archive Mode
        Automatic archival             Disabled
        Archive destination            /arch/RACDB1
           :

 

2] NODE 1 : spfile에서 pfile 생성 후 SHUTDOWN
   SQL> !cat initRACDB1.ora
        SPFILE='/dev/rspfileRACDB'
   SQL> !cp initRACDB1.ora initRACDB1.ora.20100316
   SQL> create pfile from spfile;
   SQL> shutdown immediate

 

3] NODE 1 : initRACDB1.ora의 cluster_database 주석처리 후 저장
   SQL> !vi initRACDB1.ora
         # cluster_database           = TRUE

         RACDB1.log_archive_dest_1  = "location=/arch/RACDB1 MANDATORY"
         RACDB2.log_archive_dest_1  = "location=/arch/RACDB2 MANDATORY"
         RACDB1.log_archive_format  = RACDB%t_%s_%r.arc
         RACDB2.log_archive_format  = RACDB%t_%s_%r.arc
         #LOG_ARCHIVE_START  = TRUE # 10g에서 없어짐
         
4] NODE 1 : Archivelog mode 적용하고 Open한 후 SHUTDOWN
   SQL> startup mount
   SQL> alter database archivelog;
   SQL> alter database open;
   SQL> shutdown immediate

 

5] NODE 1 : initRACDB1.ora의 주석 처리했던 cluster_database를 원상복구 후 저장
   SQL> !vi initRACDB1.ora
         cluster_database           = TRUE
         RACDB1.log_archive_dest_1  = "location=/arch/RACDB1 MANDATORY"
         RACDB2.log_archive_dest_1  = "location=/arch/RACDB2 MANDATORY"
         RACDB1.log_archive_format  = RACDB%t_%s_%r.arc
         RACDB2.log_archive_format  = RACDB%t_%s_%r.arc

 

6] NODE 1 : spfileRACDB를 다시 생성 후 initRACDB1.ora 원상복구
   SQL> create SPFILE='/dev/rspfileRACDB' from pfile;

   SQL> !mv initRACDB1.ora.20100316 initRACDB1.ora
   SQL> !cat initRACDB1.ora
        SPFILE='/dev/rspfileRACDB'

 

7] 모든 노드 : 데이터베이스 startup

   srvctl start nodeapps -n dbhost1

   srvctl start instance -d RACDB -i RACDB1

   srvctl start nodeapps -n dbhost2

   srvctl start instance -d RACDB -i RACDB2

   Archive log mode 확인

   SQL> connect / as sysdba

   SQL> archive log list
        Database log mode              Archive Mode
        Automatic archival             Enabled
        Archive destination            /arch/RACDB1
           :

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

[방법2] Parameter 중에 CLUSTER_DATABASE 만 변경할 경우

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

다른 init Parameter를 바꿀 필요없을 때는 다음과 같이 작업한다.

1] NODE 1 : DB STARTUP 상태에서 시작
   SQL> connect / as sysdba
   Archive log mode 확인
   SQL> archive log list
        Database log mode              No Archive Mode
        Automatic archival             Disabled
        Archive destination            /arch/RACDB1
                :

 

2] NODE 1 : spfile에 cluster_database=FALSE 설정
   SQL> ALTER SYSTEM SET CLUSTER_DATABASE=FALSE SCOPE=spfile;

 

3] 모든 노드 : RAC 노드 1, 2 모두 shutdown
   srvctl stop instance -d RACDB -i RACDB1

   srvctl stop nodeapps -n dbhost1

   srvctl stop instance -d RACDB -i RACDB2

   srvctl stop nodeapps -n dbhost2

   (CRS stop하지 않음)

 

4] NODE 1 : archivelog mode 적용하고 Open한 후 SHUTDOWN
   SQL> connect / as sysdba
   SQL> startup mount
   SQL> alter database archivelog;
   SQL> alter database open;
   SQL> shutdown immediate

 

5] NODE1 : spfile에 cluster_database=TRUE 설정
   SQL> connect / as sysdba
   SQL> startup mount
   SQL> ALTER SYSTEM SET CLUSTER_DATABASE=TRUE SCOPE=spfile; 
   SQL> shutdown immediate

 

6] 모든 노드 : 데이터베이스 startup 
   srvctl start nodeapps -n dbhost1

    srvctl start instance -d RACDB -i RACDB1

   srvctl start nodeapps -n dbhost2

   srvctl start instance -d RACDB -i RACDB2

   Archive log mode 확인

     SQL> archive log list
        Database log mode              Archive Mode
        Automatic archival             Enabled
        Archive destination            /arch/RACDB1

Posted by redkite
, |

백업과 복구 원리에서 알아보았듯이 사용자의 모든 변경 정보는 기본적으로 로그버퍼 영역과 리두로그 파일에 저장되어 데이터베이스 복구 시 사용됩니다. 이러한 환경을 노-아카이브 모드라고 하며 오라클 데이터베이스를 설치하면 기본적으로 노-아카이브 모드로 설정됩니다. 이 모드는 사용자의 모든 변경정보가 리두로그 파일에 백업되기 때문에 리두로그 파일의 크기와 개수가 백업할 수 있는 데이터의 크기를 좌우하게 됩니다. 결론적으로 데이터베이스를 복구해야 할 때 리두로그 파일이 아주 오래 전의 복구 데이터를 가지고 있지 않다면 복구를 할 수 없는 단점을 가지고 있습니다.

 

3장 노-아카이브와 아카이브 모드

  3-1 백업과 복구의 종류

오라클 데이터베이스에는 4 가지 백업 방법과 8 가지 복구 방법이 제공됩니다.

백업 방법은 다시 두 가지 방법으로 실행할 수 있는데, 첫 번째, 물리적 방법(PHYSICAL MODE)은 오라클 데아터베이스와 관련된 모든 파일들(데이터 파일, 컨트롤 파일, 리두로그 파일, 파라메터 파일)을 운영체계에서 제공하는 복사 명령어(도스-COPY,UNIX-cp, cpio, ufsdump 등)로 다른 물리적 장치에 복사하는 방법을 의미합니다.

두 번째 논리적 방법(LOGICAL MODE)은 오라클 사에서 제공하는 EXPORT 유틸리티를 통해 데이터베이스 내의 테이블, 뷰, 인덱스, PL/SQL 블록 등을 운영체제 상의 파일형태로 복사하는 방법을 의미합니다.

다음은 복구방법 입니다. 복구 방법도 두 가지 모드에서 실행할 수 있습니다. 첫 번째 방법은 노-아키이브 모드(NOARCHIVE MODE))입니다. 백업과 복구 원리에서 알아보았듯이 사용자의 모든 변경 정보는 기본적으로 로그버퍼 영역과 리두로그 파일에 저장되어 데이터베이스 복구 시 사용됩니다. 이러한 환경을 노-아카이브 모드라고 하며 오라클 데이터베이스를 설치하면 기본적으로 노-아카이브 모드로 설정됩니다. 이 모드는 사용자의 모든 변경정보가 리두로그 파일에 백업되기 때문에 리두로그 파일의 크기와 개수가 백업할 수 있는 데이터의 크기를 좌우하게 됩니다. 결론적으로 데이터베이스를 복구해야 할 때 리두로그 파일이 아주 오래 전의 복구 데이터를 가지고 있지 않다면 복구를 할 수 없는 단점을 가지고 있습니다.

두 번째 방법은 아카이브 모드(ARCHIVE MODE)입니다. 이 모드에는 완전복구(COMPLETE RECOVERY)와 불완전 복구(INCOMPLETE RECOVERY) 방법이 있습니다. 모든 복구 데이터를 가지고 있으며 데이터베이스에 문제가 발생했던 시점까지 복구할 수 있는데 이러한 방법을 완전복구(Complete Recovery)라고 하며, 반대로, 복구할 수 있는 데이터가 백업되어 있지 않다면 문제가 생겼던 시점까지 복구할 수 없는데 이러한 방법을 불완전 복구(In-Complete Recovery)라고 합니다. 사용자들은 이러한 다양한 백업과 복구방법을 통해 데이터베이스의 가용성을 높일 수 있습니다.

자~ 그럼 노-아카이브 모드와 아카이브 모드에 대해 자세히 알아 보도록 하겠습니다.


  3-2 노-아카이브 모드

오라클 서버는 사용자들이 입력, 수정, 삭제작업을 수행할 때 마다 발생하는 모든 변경 전 데이터와 변경 후 데이터들을 리두로그 버퍼 영역에 백업하게 됩니다. 이어, LGWR 백그라운드 프로세스는 리두로그 버퍼의 데이터들을 영구히 저장할 수 있는 리두로그 파일로 저장하게 됩니다. 이것이, 오라클 서버가 제공하는 백업 메커니즘입니다.

그런데, 기본적으로 오라클 데이터베이스를 설치하면 3개의 리두로그 파일이 제공됩니다.

최초, LGWR 프로세스는 첫번째 리두로그 파일에 데이터를 저장하며, 이 파일이 모두 사용되면, 두 번째 리두로그 파일로 이동하여 계속적으로 데이터를 저장하게 됩니다. 
두 번째 리두로그 파일도 모두 저장되고 나면 세 번째 리두로그 파일에 쓰기 작업을 계속하게 됩니다. 그런데, 세 번째 리두로그 파일도 모두 사용되고 나면, 더 이상 제공되는 리두로그 파일이 없기 때문에 다시 첫 번째 리두로그 파일에 백업 데이터들을 저장하게 됩니다. 
이때, 이전에 저장되어 있는 백업 데이터 위에 새로운 백업 데이터들을 저장하기 때문에 이전 백업 데이터들은 모두 유실되는 문제가 발생하게 됩니다.

이미 소개 드린 대로 리두로그 파일의 용도는 오라클 데이터베이스에 장애가 발생하는 경우 백업된 리두로그 파일의 데이터들을 통해 데이터베이스를 복구하기 위한 용도라고 배웠습니다. 그런데, 위 그림처럼, 백업될 충분한 공간이 확보되지 못한 경우에는 결국 이전에 사용된 리두로그 파일을 재사용할 수 밖에 없게 되는 문제가 발생하게 됩니다.

오라클 데이터베이스에서는 이러한 환경을 노-아카이브 모드(No-Archive Mode)라고 하며 기본적으로 오라클 데이터베이스 설치하면 노-아카이브 모드가 기본 환경입니다.

다음은 사용 중인 데이터베이스의 아카이브 모드 상태를 확인하는 방법입니다.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> CONNECT /AS SYSDBA SQL> ARCHIVE LOG LIST Database log mode No Archive Mode ← 노-아카이브 모드 Automatic archival Disabled Archive destination C:\oracle\ora92\database\arch Oldest online log sequence 51 Current log sequence 53

이 결과를 참조했을 때 "Database log mode"의 결과가 "No Archive Mode"임을 확인할 수 있습니다.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> SET LINESIZE 1000 SQL> SELECT GROUP#, SEQUENCE#, ARCHIVED, STATUS FROM V$LOG; GROUP# SEQUENCE# ARC STATUS ---------- ---------- ---- ----------- 1 52 NO INACTIVE 2 53 NO CURRENT 3 51 NO INACTIVE

이 결과를 참조했을 때 ARC 컬럼의 값이 "NO"는 노-아키이브 모드라는 것을 의미합니다.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp> SQL> SELECT ARCHIVER FROM V$INSTANCE; ARCHIVE ------- STOPPED

이 결과를 참조했을 때 "STOPPED"는 노-아키이브 모드라는 것을 의미합니다.


  3-3 오프라인 백업

오라클 사에서 제공하는 백업방법 중에 가장 대표적인 방법이며 또한 가장 쉽고 간단하게 수행할 수 있는 방법입니다. 하지만, 경우에 따라서는 가장 수행하기 어려운 방법 중에 하나이기도 합니다.

오프라인 백업 방법은 버전에 따라 콜드백업(Cold Backup), 전체백업(Whole Backup)이라고도 부르며 다음과 같은 주요 특징이 있습니다.

1) 반드시, 오라클 서버를 종료(Shutdown) 해야 합니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] sqlplus "/as sysdba" SQL> SHUTDOWN SQL> EXIT

여기서, 한가지 주의해야 할 점은 오라클 서버를 종료할 때 반드시 정상적인 종료 옵션(NORMAL, TRANSACTIONAL, IMMEDIATE)을 사용하셔야 합니다. 만약, ABORT와 같은 비정상적인 옵션을 사용하여 데이터베이스를 종료한 후 백업작업을 수행한다면, 이 백업 데이터는 장애 발생 시 사용하지 못하게 됩니다. 즉, 데이터베이스를 복구할 수 없게 되는 치명적인 난관에 부딪히게 됩니다. 그 이유는 간단합니다. ABORT 옵션의 의미는 현재 오라클 서버에 할당된 메모리 공간을 즉시 종료하고 사용 중이던 모든 파일의 상태를 비정상적인 상태로 남긴 후 데이터베이스를 종료 시키기 때문입니다. 예를 들어, WINDOWS 환경에서 어떤 작업을 수행하다가 시스템을 종료해야 한다면 [시작] 버튼을 클릭한 후 [시스템 종료]를 선택합니다. 이것은 정상적인 방법으로 시스템을 종료하는 방법이지요.

하지만, 때로는, 갑작스런 정전으로 인해 미처 정상적인 방법으로 시스템을 종료하지 못하는 경우도 있게 마련입니다. 이런 경우, 다시 시스템을 부팅하게 되면 운영체계는 시스템을 복구모드로 전환하여 갑작스런 다운 시 정상적인 종료를 하지 못한 파일들을 정상적으로 종료 시킨 후 다시 오픈 시켜주는 작업을 수행하게 됩니다.

오라클 데이터베이스 환경에서 SHUTDOWN ABORT 옵션의 의미는 바로 갑작스런 정전으로 인해 데이터베이스가 비정상적으로 종료된 경우와 동일한 상태를 의미하게 됩니다.

결론적으로, 이런 경우, 데이터베이스를 다시 재 시작(Startup)하게 되면 오라클 서버는 내부적으로 복구 작업을 수행하게 됩니다. 이때 , 복구작업을 수행하는 백그라운드 프로세는 SMON(System Monitor) 입니다.

사용자의 순간적인 실수로 백업된 모든 데이터들이 사용되지 못하는 경우가 실제 기업 환경에서 종종 볼 수 있습니다. 이러한 백업 작업을 안전하게 수행할 때는 2번 ~ 3번 확인하신 후 절차에 의해 작업 하셔야 합니다.


2) 오라클 데이터베이스와 관련된 모든 파일 (데이터 파일, 컨트롤 파일, 리두로그 파일, 파라메터 파일)을 같은 시점에 운영체계 명령어(UNIX의 경우는 cp, mv, ufsdump/WINDOW의 경우 copy, move 등)를 사용하여 디스크 또는 테이프 장치에 복사합니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] mkdir C:\BACKUP [C:\] CD C:\ORACLE\ORADATA\ORA92 [C:\] COPY *.DBF C:\BACKUP ← 데이터 파일의 백업 [C:\] COPY *.CTL C:\BACKUP ← 컨트롤 파일의 백업 [C:\] COPY *.LOG C:\BACKUP ← 라두로그 파일의 백업 [C:\] COPY C:\ORACLE\ORA92\DATABASE\*.ORA C:\BACKUP ← 파라메터 파일 백업

오라클 사에서 제공하는 오프라인 백업이라는 것은 결론적으로 운영체계 상에서 현재, 오라클 데이터베이스가 구성하고 있는 모든 파일(데이터 파일, 컨트롤 파일, 리두로그 파일, 파라메터 파일)들을 지정한 장치로 복사하는 것을 의미합니다. 이런 경우, 가장 주의해야 할 점은 백업 데이터가 저장될 디스크 또는 테이프 장치에 충분한 사용공간이 존재하는지를 확인하는 것 입니다.

또한, 한가지 더 주의해야 할 점은 반드시 관련된 모든 파일들을 복사하셔야 합니다. 
예를 들어, 오늘은 데이터 파일 만 백업하고 내일은 컨트롤 파일을 백업하고 모레에는 리두로그 파일만 백업하는 방법은 정상적인 오프라인 백업 방법이 아니며, 이렇게 백업된 데이터들은 복구 시 사용할 수 없게 됩니다. 그 이유는 다음과 같습니다.

위 그림처럼, ① 현재시점 2001년 6월 30일 SCN(시스템 변경번호)이 100 번인 경우, 데이터베이스를 종료하고 오프라인 백업을 수행하였습니다. 당시, 모든 백업 파일들은 같은 시점의 SCN 100 번인 시점의 데이터들 이었습니다.

② 한 달의 시간이 흘렀고, 현재시점 2001년 7월 31일 SCN이 101 번인 경우, 데이터베이스를 종료한 후 오프라인 백업을 수행하였습니다. 모든 백업 파일들은 SCN이 101번인 시점의 데이터들 이었습니다.

③ 또다시, 한 달의 시간이 흘렀고 현재 시점 2001년 8월 31일에 컨트롤 파일이 저장되어 있는 디스크에 장애가 발생하면서 모든 컨트롤 파일이 사용될 수 없는 치명적인 상태가 되었습니다.

이 경우, 데이터베이스를 복구하기 위해서는 마지막으로 백업되었던 2001년 7월 31일의 백업 데이터를 이용해야 합니다. 위 그림처럼, SCN이 101번을 가지고 있는 7월 31일 백업된 컨트롤 파일을 SCN이 102번을 가지고 있는 현재시점의 데이터베이스 환경으로 재설치를 하고 있습니다. 하지만, 현재 시점의 데이터베이스 환경에서 장애가 발생하지 않은 데이터 파일, 리두로그 파일들은 SCN이 102번 인데, 조금 전에 재 설치된 컨트롤 파일은 SCN이 101번을 나타내는 문제점을 가지게 됩니다.

이 경우, 데이터베이스를 시작(Startup)하게 되면 컨트롤 파일과 다른 파일들이 같은 시점의 데이터들이 아니므로 정상적으로 시작되지 않습니다.

위 그림에서, ③의 경우 데이터베이스의 OPEN 단계는 현재 컨트롤 파일, 리두로그 파일, 데이터 파일들의 SCN을 확인하여 모두 같은 시점의 SCN을 가지고 있는지를 비교하게 되는데 이때, 같은 SCN 번호가 아닌 파일이 발견되면 오라클 데이터베이스에 장애가 발생한 것으로 확인하여 더 이상 OPEN 단계를 수행하지 않으며 다음과 같은 에러 메시지를 출력하게 됩니다.(다음 예제는 USERS01.DBF 데이터 파일의 경우입니다.)

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] sqlplus "/as sysdba" SQL> STARTUP MOUNT; SQL> ALTER DATABASE OPEN; alter database open * ORA-01113: 9 파일이 매체 복구되어야 합니다. ORA-01110: 9 데이터 파일: C:\ORALCE\ORADATA\ORA92\USERS01.DBF

이 에러 메시지의 의미는 USERS01.DBF 데이터 파일의 SCN 번호와 다른 데이터 파일, 컨트롤 파일, 리두로그 파일의 SCN 번호가 일치하지 않는 것을 의미합니다. 
즉, 데이터베이스에 장애가 발생한 것이며, USERS01.DBF 파일에 대한 복구가 요구 된다는 의미이기도 합니다.

결론적으로, 데이터베이스에 장애가 발생한 경우 오프라인 백업에 의해 데이터를 복구하기 위해서는 같은 시점에, 같은 SCN 번호를 가진 모든 파일들이 필요하다는 것 입니다. 
즉, 오프라인 백업 시 모든 파일을 같은 시점에 백업해야 합니다.


3) 노-아카이브 모드 또는 아카이브 모드에 관계없이 사용할 수 있습니다.

오프라인 백업 방법은 노-아카이브 모드에서 수행할 수 있으며, 앞으로 소개할 아카이브 모드에서도 수행할 수 있는 방법입니다.


다음은 오프라인 백업의 단점에 대해서 알아 보도록 하겠습니다.

1) 주요 특징에서 설명 드린 대로 이 방법은 데이터베이스를 종료(Shutdown)한 후 관련된 모든 파일들을 운영체계 상에서 복사해야 합니다. 문제는 복사해야 할 파일들의 크기가 작은 경우에는 문제되지 않겠지만, 파일들의 크기가 매우 큰 경우(몇 십, 몇 백 기가바이트 또는 테라 바이트)에는 많은 시간이 소요될 수 있기 때문에 그 동안 데이터베이스를 계속적으로 종료상태로 두어야 한다는 것 입니다. 결국, 오프라인인 백업이 수행되는 동안에 어떤 사용자도 데이터베이스에 접속할 수 없으며 데이터를 참조할 수 도 없다는 것 입니다.


2) 오프라인 백업이 수행되기 위해서는 충분한 디스크 공간이 확보되어야 합니다. 현재 데이터 파일과 리구로그 파일의 크기 만큼 사용공간이 확보되어 있어야 만 오프라인 백업을 수행할 수 있기 때문입니다. 만약, 충분한 사용공간이 확보되지 않는다면 백업작업을 효과적으로 진행할 수 없게 됩니다.


사례-1

다음 사례는 노-아카이브 모드에서 사용자의 데이터 파일이 유실되는 경우 장애를 복구하는 방법입니다. 현재, 오라클 서버는 노-아카이브 모드이며 이미 오프라인 백업방법에 의해 데이터베이스 전체 백업이 수행되어 있는 상태입니다.

어느날, 오라클 데이터베이스에 장애가 발생하였고 관련 백업 파일들을 재 설치하려고 합니다. 그런데, 모든 백업 파일들은 정상적으로 재 설치 하였는데, USERS01.DBF 파일은 원래 디스크 경로에 재 설치할 수가 없었습니다. 왜냐하면, 해당 경로의 디스크에 베드 블록(Bad Block)이 발생하여 읽기, 쓰기 작업을 더 이상 수행할 수가 없기 때문입니다.

노-아카이브 모드에서 이런 경우가 발생하면 어떻게 오라클 데이터베이스를 복구할 수 있을까요?


1) 먼저, 오프라인 백업 경로에서 백업된 파일들을 확인한 후 관련 경로에 재설치 하십시오. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\]cd c:\backup [C:\] dir System01.dbf …………………. init.ora …………………. [C:\] copy *.ctl c:\oracle\oradata\ora92\*.ctl ← 컨트롤 파일을 재설치 [C:\] copy *.dbf c:\oracle\oradata\ora92\*.dbf ← 데이터 파일을 재설치 [C:\] copy *.log c:\oracle\oradata\ora92\*.log ← 리두로그 파일을 재설치 [C:\] copy *.ora c:\oracle\ora92\database ← 파라메터 파일을 재설치 [C:\] cd c:\oracle\oradata\ora92 [C:\] dir users01.dbf redo01b.log redo02b.log log3b.log ………………. [C:\] move users01.dbf d:\oracle\oradata\users01.dbf → USERS01.DBF 파일은 원래 디스크 경로에 재설치 할 수 없어 일단 다른 디스크 경로에 재설치합니다. [C:\]cd c:\oracle\ora92 [C:\] dir users*
2) USERS01.DBF 파일은 본래 경로에 재 설치하진 못했지만 기타 모든 파일들은 재설치 하였으므로 오라클 서버를 시작해 보십시오. 오픈 단계에서 USERS01.DBF 파일의 본래 경로로부터 관련 파일을 검색해 보지만 파일이 존재하지 않으므로 에러가 발생할 것 입니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] sqlplus "/as sysdba" SQL> startup mount SQL> alter database open; alter database open * ORA-01157: cannot identify data file 3 - file not found ORA-01110: data file 3: 'c:\oracle\oradata\ora92\users01.dbf' SQL> select name from v$datafile; NAME ---------------------------------------------------……………………………………. c:\oracle\oradata\ora92\users01.dbf → 오라클 서버는 USERS01.DBF 파일이 처음에 있던 디렉토리 경로에 계속 있는 걸로 알고 있습니다.
3) 이런 경우, 오라클 서버에게 재 설치된 경로가 어디인지 알려주게 되면 해당 경로로부터 관련 파일을 검색하게 됩니다. 오라클 서버의 구조 중에 관련 파일의 경로와 파일명이 저장되어 있는 곳은 컨트롤 파일입니다. 다음 명령문을 수행하게 되면 컨트롤 파일 내의 해당 정보가 변경되며 오픈 단계에서 이 정보를 통해 데이터베이스를 오픈하게 됩니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> alter database rename file 'c:\oracle\oradata\ora92\users01.dbf' to 'd:\oracle\ora92\users01.dbf ';
4) 다시 오라클 서버를 시작해 보십시오. 오라클 서버는 컨트롤 파일 내에 변경된 경로로부터 USERS01.DBF 파일을 검색하여 정상적으로 오픈하게 됩니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> alter database open; → 정상적으로 오픈 됩니다.
3-4 아카이브 모드

지금까지, 노-아카이브 모드에 대한 개념과 데이터베이스에 장애가 발생한 경우 노-아카이브 모드에서 복구하는 방법과 절차에 대해서 자세히 알아 보았습니다.

이번에는 아카이브 모드에 대해서 자세히 알아 보도록 하겠습니다.

노-아카이브 모드에서 사용자가 실행한 DML문에 의해 발생하는 모든 데이터(변경 전 데이터와 변경 후 데이터)들은 리두로그 버퍼에 백업된 다음 LGWR 프로세스에 의해 리두로그 파일에 저장됩니다. 또한, 오라클 서버는 데이터베이스 생성 시 기본적으로 3개의 리두로그 파일을 제공하며 LGWR 프로세스는 첫 번째 파일에서 두 번째 파일로, 두 번째 파일에서 세 번째 파일로 쓰기 작업을 계속하게 됩니다. 이때, 마지막 세 번째 리두로그 파일도 모두 쓰여지고 나면 다시 첫 번째 리두로그 파일로 이동하여 쓰기 작업을 계속하게 됩니다.

문제는 첫 번째 리두로그 파일에 저장되어 있던 이전 백업 데이터는 새로운 백업 데이터에 의해 재작성(Rewrite) 되어 삭제된다는 것 입니다.

"1편 오라클 서버구조와 백업/복구원리"에서도 자세히 설명 되었던 대로 리두로그 파일에 백업되는 데이터들은 장애 발생 시 데이터베이스를 복구하기 위한 용도입니다. 그런데. 이 데이터들이 LGWR 프로세스에 의해 재 작성된다는 것은 만약, 데이터베이스에 장애가 발생하는 경우 복구해야 할 백업 데이터들이 유실된다는 것을 의미합니다. 즉, 복구작업을 수행할 수 없게 된다는 것 입니다. 바로 이런 문제점을 개선하기 위해 오라클 사는 아카이브 모드(Archive Mode)라는 백업 메커니즘을 제공합니다.

위 그림에서, LGWR 프로세스가 첫 번째 리두로그 파일에 모든 변경 데이터를 저장한 후, 두 번째 리두로그 파일로 이동하는 순간, ARCH 백그라운드 프로세스는 첫 번째 리두로그 파일을 사용자가 미리 지정한 경로로 복사하게 됩니다. 
그리고, 두 번째 파일에서 세 번째 리두로그 파일로 이동할 때도 두 번째 리두로그 파일을 ARCH 프로세스가 지정한 경로로 복사합니다. 마지막으로, 세 번째 리두로그 파일에서 다시 첫 번째 리두로그 파일로 이동할 때도 세 번째 리두로그 파일을 지정한 경로로 복사하게 됩니다. 그런 후, 다시 첫 번째 파일에 백업 데이터들을 재 작성하여 저장하게 됩니다.

아카이브 모드에서는 다시 첫 번째 리두로그 파일에 백업 데이터를 저장하더라도 이전 백업데이터는 이미 사용자가 지정한 경로에 ARCH 프로세스에 의해 복사되어 있기 때문에 데이터베이스에 장애가 발생하더라도 아카이브 파일을 통해 복구작업을 수행할 수 있게 됩니다.

즉, 데이터베이스에서 발생하는 모든 데이터(변경 전 데이터와 변경 후 데이터)들이 ARCH 프로세스에 의해 항상 백업되는 메커니즘을 아카이브 모드(Archive Mode)라고 합니다.
기본적으로 오라클 데이터베이스는 노-아카이브 모드이며 설치 후 아카이브 모드로 전환하는 작업을 수행하셔야 합니다.

3-4-1 아카이브 모드의 환경설정 방법

다음은 데이터베이스를 노아카이브 모드에서 아카이브 모드로 전환하는 방법입니다.


1) 먼저, init<sid>.ora 파일에 아카이브 모드와 관련된 파라메터를 설정하십시오. </sid>

[LOG_ARCHIVE_START] 파라메터는 ARCH 백그라운드 프로세스에 의해 데이터베이스를 아카이브 모드로 전환하고 로그스위치가 발생하면 자동으로 아카이브를 실행합니다.

[LOG_ARCHIVE_DEST] 파라메터는 리두 로그 파일에 대한 아카이브 파일이 생성될 기본 저장 경로를 의미합니다.

LOG_ARCHIVE_DEST_n] 파라메터는 아카이브 경로를 여러 군데 지정할 때 사용합니다. 최대 10개의 경로지정이 가능합니다

[LOG_ARCHIVE_FORMAT] 파레메터는 [LOG_ARCHIVE_DEST] 또는 [LOG_ARCHIV E_DEST_n] 파라메터에 의해 지정된 경로에 생성될 아카이브 파일의 파일 포맷를 결정합니다.

파일의 포맷은 다음과 같습니다.

[ %s ] 자동으로 생성될 아카이브 파일의 일련번호를 결정해 줍니다. 
(예) 1, 2, 3,,, 

[ %S ] 자동으로 생성될 아카이브 파일의 일련번호를 0 값으로 채워서 결정해 줍니다. 
(예) 00001, 00002, 00003 …… 

[ %t ] 데이터베이스가 하나의 인스턴스인지 또는 여러 개의 인스턴스(OPS 환경)로 구성되어 있는지를 구분하여 표시해 줍니다. 
(예) 1, 2, 3, ,,, 

[ %T ] 데이터베이스가 하나의 인스턴스인지 또는 여러 개의 인스턴스(OPS 환경)로 구성되어 있는지를 0 값으로 채워서 결정해 줍니다. 
(예) 001, 002, 003,,,

[ %r ] 오라클 데이터베이스의 백업과 복구작업을 수행하다 보면 백업되었던 시점은 다르지만 동일한 아카이브 파일명이 생성되는 경우가 있습니다. 이런 경우, 현재 생성된 아카이브 파일과 이전에 생성된 아카이브 파일명이 동일하여 아카이브 파일을 저장, 관리하는데 혼돈을 유발시키게 됩니다. 이런 문제를 해결하기 위해 ALTER DATABASE OPEN RESETLOGS 명령어에 의해 데이터베이스가 재 시작된 후 새롭게 생성되는 아카이브 파일의 번호를 초기화할 수 있습니다. 이 구분 값은 오라클 10g 버전부터 제공됩니다.

(예) 0533062963 , 0533062973

2) 데이터베이스를 아카이브 모드로 전환하기 위해서는 데이터베이스를 다시 시작해야 하며 마운트(mount) 단계에서 'ALTER DATABASE ARCHIVELOG' 명령어를 실행해야 합니다. 
반대로, 아카이브 모드에서 노아카이브 모드로 전환할 때는 'ALTER DATABASE NOARCHIVELOG' 명령어를 실행하십시오. 아카이브 모드로 전환이 되었으면 데이터베이스를 오픈 시키십시오.
 


3) 전환작업이 완료되었으면 환경설정이 제대로 되었는지 확인해 보십시오.

다음은 사용 중인 데이터베이스에서 아카이브 모드 상태를 확인하는 방법입니다.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> CONNECT /AS SYSDBA SQL> ARCHIVE LOG LIST Database log mode Archive Mode ← 아카이브 모드 Automatic archival Enabled Archive destination C:\oracle\ora92\database\arch Oldest online log sequence 51 Current log sequence 53

이 결과를 참조했을 때 "Database log mode"의 결과가 "Archive Mode"임을 확인할 수 있습니다.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> SET LINESIZE 1000 SQL> SELECT GROUP#, SEQUENCE#, ARCHIVED, STATUS FROM V$LOG; GROUP# SEQUENCE# ARC STATUS ---------- ---------- ----- ---------------- 1 52 YES INACTIVE 2 53 NO CURRENT 3 51 NO INACTIVE

이 결과를 참조했을 때 ARC 컬럼의 값이 "YES"는 아키이브 모드라는 것을 의미합니다.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> SELECT ARCHIVER FROM V$INSTANCE; ARCHIVE ------- STARTED

이 결과를 참조했을 때 "STARTED"는 아키이브 모드라는 것을 의미합니다.

Posted by redkite
, |

온라인 백업방법은 반드시 아카이브 모드이어야 합니다. 왜냐하면, 오라클 서버가 사용자들에 의해 사용되고 있는 와중에 백업되는 방법이기 때문에 노-아카이브 모드에서는 수행될 수 없기 때문입니다. 만약, 어떤 데이터 파일을 온라인 백업하고 있는데 그 파일에 존재하는 테이블에 대해 누군가가 변경작업을 수행한다면 백업작업이 완료된 후 변경된 데이터를 해당 데이터 파일에 반드시 변경해야 하기 때문입니다.

 

 

6장 ON-Line 백업을 이용한 장애복구

  6-1 테이블스페이스 온라인 백업

오라클 데이터베이스를 사용하는 사용자들의 기업환경은 매우 다양합니다. 아침에 출근해서 저녁에 퇴근하는 기업이 있는가 하면, 퇴근 후에도 24시간 동안 인터넷을 통해 계속해서 고객으로부터 제품에 대한 주문 또는 서비스 요청을 받는 기업들도 있습니다. 
지금까지 소개되었던 대표적인 백업방법은 오라클 서버를 종료한 후 관련된 모든 파일들을 복사하는 방법인 오프라인(Off-Line) 백업이 소개되었습니다.
그리고, 오프라인 백업된 파일들을 통해 오라클 데이터베이스에 장애가 발생한 경우 복구하는 방법과 절차에 대해서도 자세히 알아 보았습니다.
만약, 24시간 동안 계속적인 기업활동을 수행하는 회사에서 오라클 데이터베이스를 백업하기 위해 반드시 오프라인 백업을 수행해야 한다면 백업을 수행하는 시간 동안에는 고객으로부터 어떤 주문 접수도 처리할 수 없는 상태가 될 수 밖에 없을 것 입니다.
기업 입장에서는 오라클 서버를 종료할 수도 없고, 주문접수도 수행할 수 없는 지경에 이르게 되어 궁극적으로는 불안한 시스템 운영을 할 수밖에 없을 것 입니다. 
이런 문제점을 해결하기 위해, 오라클 사는 24시간 365일 동안 데이터베이스를 사용하는 기업환경에서 오라클 서버를 종료하지 않고도 효과적인 백업작업을 수행할 수 있도록 온라인(On-Line) 백업방법을 제공하고 있습니다.
이 백업방법은 오픈(OPEN) 백업 또는 핫(HOT) 백업방법이라고 불리어지기도 합니다.
그리고, 온라인 백업은 반드시 아카이브 모드에서 만 수행할 수 있는 백업방법 입니다.
온라인 백업에는 2가지 백업 방법이 있습니다. 첫 번째는 테이블스페이스 단위의 백업이며 두 번째는 전체 데이터베이스 온라인 백업 방법입니다. 첫 번째 방법은 오라클 10g 이전 버전에서도 제공되었으며 두 번째 방법은 10g 버전부터 제공되었습니다. 
자~ 그럼, 테이블스페이스 단위의 온라인 백업 방법부터 자세히 알아 보도록 합시다.

다음은 온라인 백업의 방법과 절차에 대한 자세한 설명입니다.

(1) 먼저, 오라클 데이터베이스는 사용 가능한 상태이어야 합니다. STARTUP 명령어에 의해 정상적으로 시작되어야 하며 사용자들의 SELECT, UPDATE, INSERT, DELETE 작업이 정상적으로 수행 가능해야 합니다.

(2) 다음은, 오라클 데이터베이스가 아카이브 모드로 운영되고 있는지 확인하십시오. 
온라인 백업방법은 반드시 아카이브 모드이어야 합니다. 왜냐하면, 오라클 서버가 사용자들에 의해 사용되고 있는 와중에 백업되는 방법이기 때문에 노-아카이브 모드에서는 수행될 수 없기 때문입니다. 만약, 어떤 데이터 파일을 온라인 백업하고 있는데 그 파일에 존재하는 테이블에 대해 누군가가 변경작업을 수행한다면 백업작업이 완료된 후 변경된 데이터를 해당 데이터 파일에 반드시 변경해야 하기 때문입니다.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> archive log list 데이터베이스 로그모드 아카이브 모드 가장 오래된 온라인 로그순서 1 아카이브할 다음 로그 1 현재 로그순서 1

(3) 다음은, 해당 테이블스페이스에 대한 온라인 백업하는 방법입니다. 온라인 백업은 테이블스페이스 단위로 관련된 데이터 파일을 복사할 수 있습니다.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> MKDIR C:\ONLINE_BACKUP -- SYSTEM 테이블스페이스에 대한 온라인 백업 SQL> ALTER TABLESPACE SYSTEM BEGIN BACKUP; SQL> HOST COPY c:\oracle\oradata\ora92\system01.dbf c:\online_backup SQL> ALTER TABLESPACE SYSTEM END BACKUP; --TEMP 테이블스페이스에 대한 온라인 백업 SQL> ALTER TABLESPACE TEMP BEGIN BACKUP; SQL> HOST COPY c:\oracle\oradata\ora92\temp01.dbf c:\online_backup SQL> ALTER TABLESPACE TEMP END BACKUP; -- UNDOTBS 테이블스페이스에 대한 온라인 백업 SQL> ALTER TABLESPACE UNDOTBS BEGIN BACKUP; SQL> HOST COPY c:\oracle\oradata\ora92\undotbs01.dbf c:\online_backup SQL> ALTER TABLESPACE UNDOTBS END BACKUP; -- QUERY 테이블스페이스에 대한 온라인 백업 SQL> ALTER TABLESPACE QUERY BEGIN BACKUP; SQL> HOST COPY c:\oracle\oradata\ora92\query01.dbf c:\online_backup SQL> ALTER TABLESPACE QUERY END BACKUP;
< 주의 >
온라인 백업을 수행하면서 가장 주의해야 할 점은 ALTER TABLESPACE ~ BEGIN BACKUP; 명령문과 ALTER TABLESPACE ~ END BACKUP; 명령문을 수행하는 시간의 차이입니다. 
BEGIN BACKUP문을 실행하는 순간부터 관련 테이블스페이스의 모든 파일들에는 CHECKPOINT가 더 이상 발생하지 않게 되며 END BACKUP문을 실행하는 순간 CHECKPOINT가 다시 발생하게 됩니다.(CHECKPOINT의 기본원리에 대해서는 "2편 데이터베이스의 논리적/물리적 구조설계"를 참조 하십시오.) 
오라클 서버는 이러한 원리에 의해, 해당 테이블스페이스에 대한 백업시점을 관리하게 됩니다. 결론적으로 테이블스페이스를 생성할 때 너무 큰 크기의 데이터 파일을 생성하게 되면 온라인 백업을 수행할 때 CHECKPOINT의 시점관리에 문제가 발생하여 에러가 발생할 수도 있습니다. 너무 큰 크기의 데이터 파일들은 2~3개 정도로 나누어 스트라이핑(Striping) 하시는 것이 원활한 백업과 복구작업에 도움이 될 수 있습니다.

(4) 온라인 백업된 모든 데이터 파일들을 확인하십시오.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] CD C:\ONLINE_BACKUP [C:\] DIR SYSTEM01.DBF UNDOTBS01.DBF TEMP01.DBF QUERY01.DBF
6-2 데이터베이스 전체 온라인 백업

오라클 사에서 제공하는 2가지 온라인 백업방법 중에 먼저 테이블스페이스 단위의 백업 방법을 알아 보았습니다. 
온라인 백업방법은 24시간 365일 동안 오라클 데이터베이스를 종료할 수 없는 기업환경에서 매우 적절하게 수행할 수 있는 백업방법 중에 하나라는 것은 두말하면 잔소리일 것 입니다. 하지만, 이 백업방법의 가장 큰 단점은 오라클 데이터베이스를 구성하고 있는 모든 테이블스페이스에 대한 전체 백업이 요구되는 경우입니다.
ALTER TABLESPACE ~ BEGIN BACKUP과 ALTER TABLESPACE ~ END BACKUP 명령어를 반복적으로 수행해야 하기 때문에 번거로울 뿐만 아니라 READ ONLY 모드의 테이블스페이스와 OFFLINE 모드의 테이블스페이스에 대해서는 수행할 수 없는 것이 단점이기도 합니다.
이러한 문제점을 개선한 백업방법이 바로 전체 데이터베이스 온라인 백업방법 입니다.
이 백업방법은 오라클 10g 버전부터 제공됩니다.


(1) ALTER DATABASE BEGIN BACKUP과 ALTER DATABASE END BACKUP 명령어

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> ALTER DATABASE BEGIN BACKUP; ← 전체 DB 온라인 백업 시작 SQL> host copy c:\oracle\oradata\ora92\system01.dbf c:\full_online_backup SQL> host copy c:\oracle\oradata\ora92\undotbs01.dbf c:\full_online_backup SQL> host copy c:\oracle\oradata\ora92\temp01.dbf c:\full_online_backup SQL> host copy c:\oracle\oradata\ora92\temp02.dbf c:\full_online_backup SQL> host copy c:\oracle\oradata\ora92\users01.dbf c:\full_online_backup SQL> host copy c:\oracle\oradata\ora92\query01.dbf c:\full_online_backup SQL> ALTER DATABASE END BACKUP; ← 전체 DB 온라인 백업의 종료

(2) 오프라인 상태의 테이블스페이스는 테이블스페이스 단위의 온라인 백업을 수행할 수 없지만, 전체 데이터베이스 온라인 백업방법으로는 가능합니다.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> ALTER TABLESPACE users OFFLINE IMMEDIATE; SQL> SELECT tablespace_name, status FROM dba_tablespaces; TABLESPACE_NAME STATUS ------------------------------ --------- SYSTEM ONLINE UNDOTBS ONLINE TEMP ONLINE USERS OFFLINE SQL> ALTER TABLESPACE users BEGIN BACKUP; * ERROR at line 1: ORA-01128 : cannot start online backup - file 4 is offline ORA-01110 : data file 4 : 'c:\oracle\oradata\ora92\users01.dbf' SQL> ALTER DATABASE BEGIN BACKUP; SQL> host copy c:\oracle\oradata\ora92\users01.dbf c:\full_online_backup SQL> ALTER DATABASE END BACKUP;

(3) READ ONLY 상태의 테이블스페이스는 테이블스페이스 단위의 온라인 백업을 수행할 수 없지만, 전체 데이터베이스 온라인 백업방법으로는 가능합니다

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> select tablespace_name, status from dba_tablespaces; TABLESPACE_NAME STATUS ------------------------------------ QUERY READ ONLY ← READ ONLY 상태를 확인하십시오. SQL> ALTER TABLESPACE query BEGIN BACKUP; alter tablespace users begin backup 1행에 오류: ORA-01642: 읽기 전용 'USERS' 테이블스페이스에는 초기 백업이 필요하지 않습니다. SQL> ALTER DATABASE BEGIN BACKUP; SQL> host copy c:\oracle\oradata\ora92\query01.dbf c:\full_online_backup SQL> ALTER DATABASE END BACKUP;
6-3 온라인 백업을 이용한 완전 복구

온라인 백업파일을 이용한 오라클 데이터베이스의 복구방법에 대해서 알아 보도록 하겠습니다. 지금까지 대부분의 사례 내용들이 오프라인 백업파일을 이용한 복구 방법이었다면 이번 사례는 온라인 백업된 파일을 이용하는 방법입니다.
결론적으로 말씀 드리면, 오라클 데이터베이스의 모든 복구방법은 백업된 파일이 오프라인 백업 파일이든, 온라인 백업 파일이든 상관없이 모두 동일한 방법과 절차에 의해 수행하게 됩니다. 지금부터 설명하는 방법과 절차는 이미 소개된 완전복구 방법과 동일합니다. 다만, 복구작업을 수행할 때 온라인 백업된 파일을 이용하는 것 입니다.

위 그림에서, 현재 시점 2001년 6월 10일 오전 12시에 데이터베이스의 상태에서 온라인 백업을 통해 SCN 번호가 95인 USERS01.DBF 데이터 파일을 백업하고 있습니다. 현재, 데이터베이스는 아카이브 모드이며, 온라인 백업 이후 발생한 모든 트랜잭션 데이터들은 아카이브 파일과 리두로그 파일에 기록되어 있습니다. 첫 번째 아카이브 파일 ARC1.LOG 에는 마지막 오프라인 백업 이후부터 2001년 6월 11일 오전 12시까지의 백업 데이터들이 저장 되었다고 합니다. 그리고, 두 번째 아카이브 파일 ARC2.LOG 에는 2001년 6월 11일 오전 12시부터 2001년 6월 12일 오전 12시까지의 백업 데이터들이 저장되었으며, 2001년 6월 12일 오전 12시부터 6월 12일 오후 13시까지의 데이터들은 ARC3.LOG 파일에 기록되어 있다고 합니다.
현재시점, 2001년 6월 12일 오후 13시에 USERS01.DBF 데이터 파일이 저장되어 있는 디스크에 장애가 발생하여 더 이상 데이터베이스를 사용할 수 없다고 합니다.


사례-9

컨트롤 파일들이 저장되어 있는 모든 디스크에 장애가 발생하였습니다. 또한 모든 데이터 파일이 저장되어 있던 디스크에도 치명적인 문제가 발생하였습니다. 마지막, 온라인 백업 파일을 이용하여 완전 복구작업을 수행해 보도록 하겠습니다.


(1) 오라클 서버가 사용 가능한 상태인지 확인하고 MOREDEPT.SQL을 실행한 후 아카이브 파일들이 정상적으로 생성되는지 확인하십시오

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] sqlplus "/as sysdba" SQL> startup SQL> @moredept alter system switch logfile; insert into scott.dept values(1,'Personnel','Pusan'); insert into scott.dept values(2,'Account','Pusan'); insert into scott.dept values(3,'Q.C','Pusan'); alter system switch logfile; insert into scott.dept values(4,'Personnel','Seoul'); insert into scott.dept values(5,'Account','Seoul'); insert into scott.dept values(6,'Q.C','Seoul'); alter system switch logfile; insert into scott.dept values(7,'Personnel','Daejeon'); insert into scott.dept values(8,'Account','Daejeon'); insert into scott.dept values(9,'Q.C','Daejeon'); commit; select count(*) from scott.dept; SQL> host dir c:\oracle\ora92\database\arch\*.arc

(2) 이번 시나리오는 모든 컨트롤 파일과 데이터 파일이 함께 장애가 발생했다고 합니다.
마지막으로 온라인 백업된 파일을 이용하여 오라클 데이터베이스를 복구해 봅시다.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> shutdown abort ← 갑작스런 정전상태를 만들기 위해 ABORT 옵션으로 오라클 서버를 강제 종료합니다. SQL> exit [C:\] del c:\oracle\oradata\ora92\system01.dbf [C:\] del c:\oracle\oradata\ora92\undotbs01.dbf [C:\] del c:\oracle\oradata\ora92\temp01.dbf [C:\] del c:\oracle\oradata\ora92\temp02.dbf [C:\] del c:\oracle\oradata\ora92\users01.dbf [C:\] del c:\oracle\oradata\ora92\query01.dbf → 모든 데이터 파일들에 장애가 발생합니다. [C:\] del c:\oracle\oradata\ora92\*.ctl → 모든 컨트롤 파일들에 장애가 발생합니다.

(3) 자~ 지금부터 온라인 백업파일을 이용하여 완전복구 작업을 수행해 보도록 하겠습니다.
먼저, 장애가 발생한 모든 컨트롤 파일과 데이터 파일에 대한 온라인 백업 파일들을 현재 경로로 재 설치하십시오.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] cd c:\online_backup [C:\] dir [C:\] copy system01.dbf c:\oracle\oradata\ora92 [C:\] copy undotbs01.dbf c:\oracle\oradata\ora92 [C:\] copy temp01.dbf c:\oracle\oradata\ora92 [C:\] copy temp02.dbf c:\oracle\oradata\ora92 [C:\] copy users01.dbf c:\oracle\oradata\ora92 [C:\] copy query01.dbf c:\oracle\oradata\ora92 → 장애가 발생한 모든 데이터 파일들을 재 설치합니다. [C:\] copy backup_control.ctl c:\oracle\oradata\ora92\control01.ctl [C:\] copy backup_control.ctl c:\oracle\oradata\ora92\control02.ctl [C:\] copy backup_control.ctl c:\oracle\oradata\ora92\control03.ctl [C:\] copy backup_control.ctl c:\oracle\oradata\ora92\control04.ctl → 장애가 발생한 모든 컨트롤 파일들을 재 설치합니다. 만약, 컨트롤 파일의 개수가 4개이면 백업된 파일을 4번 해당 경로에 복사해야 합니다. [C:\] cd [C:\] sqlplus "/as sysdba" SQL> startup mount SQL> recover database using backup controlfile → 복구해야 할 대상 파일에 이전의 컨트롤 파일이 포함되어 있으므로 USING BACKUP CONTROLFILE 옵션절을 사용하여 복구작업을 수행해야 합니다. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed ORA-00280: Change 8050 for thread 1 is in sequence #5 Specify log: {<ret>=suggested | filename | AUTO | CANCEL} AUTO ← AUTO 키워드를 사용하여 모든 아카이브 파일을 적용합니다. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed ORA-00280: Change 8050 for thread 1 is in sequence arch_n.arc ERROR 발생 ← AUTO 키워드를 적용하여 아카이브를 적용했지만 마지막 아카이브 파일 을 적용할 때 에러가 발생하는 경우가 있습니다. 왜냐하면, 적용해야 할 마지막 백업 데이터는 아카이브 파일에 저장되어 있지 않고 CURRENT 리두로그 파일에 존재하기 때문입니다. SQL> recover database using BACKUP controlfile; → 에러가 발생하는 경우에는 다시 RECOVER DATABASE ~ 명령어를 실행하십시오. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed ORA-00280: Change 8050 for thread 1 is in sequence arch_n.arc Specify log: {<ret>=suggested | filename | AUTO | CANCEL} c:\oracle\oradata\ora92\redo01.log ← 마지막 백업 데이터가 저장되어 있는 CURRENT 리두로그 파일을 입력해 주십시오. Log Applied. Media Complete Recovery. ← 복구작업이 완료되었습니다. SQL> alter database open resetlogs; → 백업된 컨트롤 파일을 이용한 복구작업은 수행과정과 절차는 완전복구 방법과 동일하지만, OPEN 단계에서 반드시 RESETLOGS 옵션을 사용해야 합니다. 왜냐하면, 컨트롤 파일은 현재 시점으로 복구되었지만 데이터베이스 내의 상태정보는 여전히 일치하지 않기 때문입니다. 반드시, 모든 상태정보를 초기화 해야만 OPEN 할 수 있습니다. SQL> select count(*) from scott.dept; → 정상적으로 복구된 것을 확인하십시오. SQL> shutdown SQL> exit</ret></ret>

(4) 불완전 복구를 수행하고 나면 반드시 이전의 마지막 백업파일은 재 사용될 수 없기 때문에 다시 오프라인 백업을 수행해야 합니다. 또한, 이전의 아카이브 파일, 트레이스 파일들도 제거 하십시오.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] copy c:\oracle\oradata\ora92\*.* c:\backup [C:\] copy c:\oracle\admin\ora92\init.ora c:\backup [C:\] del c:\oracle\oradata\ora92\arch\*.arc
사례-9

데이터베이스의 컨트롤 파일이 존재하는 디스크에 장애가 발생하여 더 이상 입력, 수정, 삭제 작업을 수행할 수 없습니다. 모든 컨트롤이 유실된 상태이며 마지막으로 백업된 컨트롤 파일 만이 사용 가능한 상태입니다. 어떻게 복구해야 할까요 ?


(1) 오라클 서버가 사용 가능한 상태인지 확인하고 MOREDEPT.SQL을 실행한 후 아카이브 파일들이 정상적으로 생성되는지 확인하십시오.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] sqlplus "/as sysdba" SQL> startup SQL> @moredept alter system switch logfile; insert into scott.dept values(1,'Personnel','Pusan'); insert into scott.dept values(2,'Account','Pusan'); insert into scott.dept values(3,'Q.C','Pusan'); alter system switch logfile; insert into scott.dept values(4,'Personnel','Seoul'); insert into scott.dept values(5,'Account','Seoul'); insert into scott.dept values(6,'Q.C','Seoul'); alter system switch logfile; insert into scott.dept values(7,'Personnel','Daejeon'); insert into scott.dept values(8,'Account','Daejeon'); insert into scott.dept values(9,'Q.C','Daejeon'); commit; select count(*) from scott.dept; SQL> host dir c:\oracle\ora92\database\arch\*.arc

(2) 이번 사례는 데이터베이스의 모든 상태정보와 오라클 서버의 시작과 종료 시 반드시 필요한 컨트롤 파일에 대한 내용입니다. 
여러 개의 컨트롤 파일 중 하나라도 장애가 발생하면 더 이상 오라클 서버를 사용할 수 없기 때문에 오라클 데이터베이스 구조 중에 가장 중요한 파일 중에 하나입니다. 
먼저, 현재 사용하고 있는 오라클 서버에서 컨트롤 파일의 위치와 개수를 확인하십시오. 그리고, 모든 컨트롤 파일을 삭제하여 장애가 발생한 시나리오를 만들어 보시기 바랍니다.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> shutdown abort --> 오라클 서버가 비정상적으로 종료됩니다. SQL> exit [C:\] del c:\oracle\oradata\ora92\*.ctl ← 사용자의 실수로 인해 모든 컨트롤 파일이 삭제됩니다. (실제 기업환경에서는 임의로 컨트롤 파일을 삭제해서는 안됩니다.)

(3) 결론적으로 모든 컨트롤 파일에 장애가 발생하면 더 이상 오라클 데이터베이스를 사용할 수 없게 됩니다. 이런 현상이 발생하는 경우에는 불완전 복구방법을 사용합니다. 
마지막 오프라인 백업된 백업 파일로부터 모든 컨트롤 파일을 현재 경로로 재 설치하십시오.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\]copy c:\backup\*.ctl c:\oracle\oradata\ora92\*.ctl [C:\] sqlplus "/as sysdba" SQL> startup mount SQL> recover database using BACKUP controlfile ← 현재 환경은 컨트롤 파일 만 이전의 백업 파일이고 다른 파일들은 현재 시점의 파일들이기 때문에 컨트롤 파일 만의 복구작업을 수행하기 위해 USING BACKUP CONTROLFILE 절을 사용하여 복구작업을 수행해야 합니다. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed for thread 1 Specify log: {<ret>=suggested | filename | AUTO | CANCEL} C:\oracle\oradata\ora92\arch\arch_1.arc ← 만약, 적용해야 할 아카이브 파일이 지정되지 않으면 직접 첫 번째 아카 이브 파일의 경로와 이름을 입력해야 합니다. 적용해야 할 아카이브 파일 명이 출력되는 경우에는 AUTO 키워드를 입력하여 자동으로 아카이브를 적용하시면 됩니다. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed ORA-00280: Change 8050 for thread 1 is in sequence arch_2.arc Specify log: {<ret>=suggested | filename | AUTO | CANCEL} AUTO ← 첫 번째 아카이브를 적용하면 두 번째 아카이브 파일의 이름과 경로가 출력되고 해당 파일을 적용할 것 인지가 나타납니다. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed ORA-00280: Change 8050 for thread 1 is in sequence arch_n.arc ← 여러 개의 아카이브 파일을 적용하다 마지막 아카이브 파일을 적용하려고 했을 때 에러가 발생할 수 도 있습니다. 이런 경우는 적용해야 할 마지막 백업 데이터가 아카이브 파일로 저장되어 있는 것이 아니라, CURRENT 리두 로그 파일에 저장되어 있기 때문입니다. 이러 경우에는 마지막 CURRENT 리두로그 파일의 경로와 이름을 지정해 주시면 됩니다. SQL> recover database using BACKUP controlfile 에러가 발생하면 다시 리두로그 파일을 적용해 줄 수 없으므로 RECOVER DATABASE 명령어를 재 수행하시면 됩니다. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed ORA-00280: Change 8050 for thread 1 is in sequence arch_n.arc Specify log: {<ret>=suggested | filename | AUTO | CANCEL} c:\oracle\oradata\ora92\redo01.log --> 마지막 CURRENT 리두로그 파일명을 입력하십시오 Log applied. Media recovery complete. SQL> alter database open resetlogs; ← 절차와 방법은 완전복구 방법과 같지만 결론적으로 이 방법은 불완전 복구입니다. 왜냐하면, 데이터베이스의 모든 상태정보가 저장되어 있는 컨트롤 파일이 삭제되었 기 때문에 컨트롤 파일은 복구되었지만 상태정보는 복구되지 않았기 때문입니다. SQL> select count(*) from scott.dept; --> 정상적으로 검색이 가능합니다. SQL> shutdown SQL> exit</ret></ret></ret>

(4) 불완전 복구를 수행하고 나면 반드시 이전의 마지막 백업파일은 재 사용될 수 없기 때문에 다시 오프라인 백업을 수행해야 합니다. 또한, 이전의 아카이브 파일, 트레이스 파일들도 제거 하십시오.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] cd c:\oracle\oradata\ora92 [C:\] copy *.* c:\backup [C:\] copy c:\oracle\ora92\database\init.ora c:\backup
사례-10

현재, 데이터베이스는 아카이브 모드입니다. 최근에 온라인 백업과 오프라인 백업도 정상적으로 수행되었습니다. 
백업 작업 이후에 새로운 데이터 파일이 생성되었고 사용자의 데이터가 입력되었습니다.
하지만, 곧 해당 디스크에 장애가 발생하였습니다. 마지막 백업파일에는 존재하지 않는 새로 생성된 데이터 파일은 어떻게 복구할 수 있을까요 ?


(1) 오라클 서버가 사용 가능한 상태인지 확인하고 MOREDEPT.SQL을 실행한 후 아카이브 파일들이 정상적으로 생성되는지 확인하십시오.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] sqlplus "/as sysdba" SQL> startup SQL> @moredept alter system switch logfile; insert into scott.dept values(1,'Personnel','Pusan'); insert into scott.dept values(2,'Account','Pusan'); insert into scott.dept values(3,'Q.C','Pusan'); alter system switch logfile; insert into scott.dept values(4,'Personnel','Seoul'); insert into scott.dept values(5,'Account','Seoul'); insert into scott.dept values(6,'Q.C','Seoul'); alter system switch logfile; insert into scott.dept values(7,'Personnel','Daejeon'); insert into scott.dept values(8,'Account','Daejeon'); insert into scott.dept values(9,'Q.C','Daejeon'); commit; select count(*) from scott.dept; SQL> host dir c:\oracle\ora92\database\arch\*.arc

(2) 마지막 백업 이후에 NEW_DATA 테이블스페이스가 추가로 생성되었다고 합니다. 그리고, NEW_TEST 테이블을 NEW_DATA 테이블스페이스에 생성한다고 합니다.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> create tablespace new_data datafile 'c:\oracle\oradata\ora92\new_data.dbf' size 500k; SQL> create table scott.new_test tablespace new_data as select * from scott.dept; SQL> @moredept.sql

(3) 갑작스런 정전이 발생하고 새로 생성한 NEW_DATA 테이블스페이스에 장애가 발생한다고 합니다.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> shutdown abort ← 갑작스런 정전이 발생합니다. SQL> exit [C:\] dir c:\oracle\oradata\ora92 [C:\] del c:\oracle\oradata\ora92\new_data.dbf a NEW_DATA 테이블스페이스에 장애가 발생합니다. [C:\] dir c:\oracle\oradata\ora92

(3) 그런데, 문제가 있군요 ~ 
NEW_DATA 테이블스페이스는 마지막 백업 시에는 존재하지 않던 데이터 파일이기 때문에 복구작업을 수행하기 위해 재 설치할 백업 파일이 존재하지 않기 때문입니다. 
백업 파일이 존재하지 않는 복구는 어떻게 수행해야 할까요 ? 
결론적으로 말하면, 마지막 백업 이후에 발생한 모든 작업내용은 리두로그 파일과 아카이브 파일에 남아있기 때문에 오라클 서버가 아카이브 모드라면 쉽게 복구할 수 있습니다.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] sqlplus "/as sysdba" SQL> startup ORA-01157: 데이터 4 파일을 식별 또는 잠금할 수 없습니다-DBWR 추적파일 ORA-01110: data file 7: ' dir c:\oracle\oradata\ora92\new_data.dbf' SQL> alter database create datafile 'c:\oracle\oradata\ora92\new_data.dbf' as 'c:\oracle\oradata\ora92\new_data.dbf'; → 아카이브 파일에는 모든 작업에서 발생한 변경 데이터 만 존재하기 때문에 데이터 파일(NEW_DATA.DBF)에 대한 구조는 별도로 생성해 주어야 합니다. SQL> host dir c:\oracle\oradata\ora92 SQL> recover datafile 'c:\oracle\oradata\ora92\new_data.dbf' AUTO ← 새로 생성해준 NEW_DATA.DBF 파일에 아카이브 파일이 가지고 있는 백업 데이터를 적용하여 복구작업을 수행합니다. Log Applied. Media Complete Recovery. SQL> alter database open;

(4) 백업 파일이 없는 데이터 파일은 새로운 데이터 파일을 생성한 후 아카이브 파일을 적용하면 복구작업을 수행할 수 있습니다. 데이터들이 정상적으로 복구되었는지 확인하십시오.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> select count(*) from scott.new_test;

Posted by redkite
, |

완전복구(Complete Recovery) 방법은 데이터베이스에 장애가 발생한 경우 그 시점까지의 모든 백업 데이터를 아카이브 파일과 리두로그 파일에 저장해 둔 후 복구 작업 시 사용하는 방법입니다. 실제 기업환경에서 데이터베이스를 운영하다 보면 예기치 못한 원인으로 인해 장애가 발생하는 경우 거의 대부분의 경우는 문제가 발생한 시점까지 모든 데이터를 복구하는 것이 원칙일 것 입니다. 하지만, 특별한 경우에는 문제가 생긴 시점이 아닌 그 이전 시점의 어느 순간까지 만 복구해야 하는 경우도 때로는 발생하게 됩니다. 이런 경우, 완전복구 방법으로는 과거 어느 시점까지의 복구는 할 수 없기 때문에, 반드시 불완전 복구방법을 사용해야 합니다.

 

5장 OFF-Line 백업을 이용한 불완전 복구

  5-1 불완전 복구

완전복구(Complete Recovery) 방법은 데이터베이스에 장애가 발생한 경우 그 시점까지의 모든 백업 데이터를 아카이브 파일과 리두로그 파일에 저장해 둔 후 복구 작업 시 사용하는 방법입니다. 실제 기업환경에서 데이터베이스를 운영하다 보면 예기치 못한 원인으로 인해 장애가 발생하는 경우 거의 대부분의 경우는 문제가 발생한 시점까지 모든 데이터를 복구하는 것이 원칙일 것 입니다. 
하지만, 특별한 경우에는 문제가 생긴 시점이 아닌 그 이전 시점의 어느 순간까지 만 복구해야 하는 경우도 때로는 발생하게 됩니다. 이런 경우, 완전복구 방법으로는 과거 어느 시점까지의 복구는 할 수 없기 때문에, 반드시 불완전 복구방법을 사용해야 합니다.

오라클 사에서는 시간기반 불완전 복구(Time Based Incomplete Recovery), 취소기반 불완전 복구(Cancel Based Incomplete Recovery), 변경기반 불완전 복구(Change Based Incomplete Recovery) 방법을 제공하고 있습니다.


5-1-1 시간기반 불완전 복구

자~ 그럼, 불완전 복구의 대표적 방법인 시간기반 복구에 대해서 먼저 알아보겠습니다. 데이터베이스를 운영하다 보면 대부분의 경우는 물리적 구조(시스템, 디스크 장치 등)의 장애로 인해 더 이상 데이터베이스를 사용할 수 없는 경우를 보게 됩니다. 하지만, 사용자가 DML문을 수행한 후 실수로 COMMIT문을 실행하게 되는 경우나 DROP 또는 ALTER 문장으로 원치 않게 데이터가 변경되는 경우가 발생하게 됩니다.

시간기반 불완전 복구방법은 주로 사용자의 실수로 인해 해당 테이블의 데이터가 변경되어 데이터베이스의 신뢰성이 깨지는 경우 데이터베이스를 변경 이전상태로 복구하기 위해 사용되는 복구방법 중에 하나 입니다.

위 그림에서, 현재 시점 2001년 6월 10일 오전 12시에 데이터베이스를 종료한 후 오프라인 백업을 통해 SCN 번호가 95인 모든 파일(데이터 파일, 컨트롤 파일, 리두로그 파일)들을 백업하고 있습니다. 현재, 데이터베이스는 아카이브 모드이며, 오프라인 백업 이후 발생한 모든 트랜잭션 데이터들은 아카이브 파일과 리두로그 파일에 기록되어 있습니다. 
ARC1.LOG, ARC2.LOG, ARC3.LOG 파일에 모든 백업 데이터들이 저장되었다고 합니다. 
현재시점, 2001년 6월 11일 오후 12시 10분 11초에 사용자가 실수로 EMP 테이블을 삭제했다고 합니다. 이 사실을 모른체 사용자들은 다른 테이블에 대해 입력, 수정, 삭제작업을 계속 수행했다고 합니다. 현재시점, 2001년 6월 12일 13시 USERS01.DBF 데이터 파일이 저장되어 있는 디스크에 장애가 발생하여 더 이상 데이터베이스를 사용할 수 없다고 합니다. 
데이터베이스 관리자는 완전복구 방법을 통해 장애가 발생한 USERS01.DBF 데이터 파일을 복구하려고 합니다. 하지만, 완전복구 작업을 수행하게 되면 EMP 테이블은 여전히 DROP된 상태로 복구되기 때문에 테이블을 복구할 수 없다고 합니다. EMP 테이블이 복구되기 위해서는 장애가 발생한 시점까지 복구해서는 안되며, EMP 테이블이 DROP 되기 이전 상태까지만 복구해야 합니다.

사례-7.

사용자가 실수로 테이블을 DROP 했다고 합니다. 완전복구 작업을 수행하게 되면 해당 테이블이 삭제된 상태로 복구되기 때문에 반드시 불완전 복구작업을 수행해야 합니다.


(1) 오라클 서버가 사용 가능한 상태인지 확인하고 MOREDEPT.SQL을 실행한 후 아카이브 파일들이 정상적으로 생성되는지 확인하십시오.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] sqlplus "/as sysdba" SQL> @moredept.sql alter system switch logfile; insert into scott.dept values(1,'Personnel','Pusan'); insert into scott.dept values(2,'Account','Pusan'); insert into scott.dept values(3,'Q.C','Pusan'); alter system switch logfile; insert into scott.dept values(4,'Personnel','Seoul'); insert into scott.dept values(5,'Account','Seoul'); insert into scott.dept values(6,'Q.C','Seoul'); alter system switch logfile; insert into scott.dept values(7,'Personnel','Daejeon'); insert into scott.dept values(8,'Account','Daejeon'); insert into scott.dept values(9,'Q.C','Daejeon'); commit; select count(*) from scott.dept;

(2) 데이터베이스를 사용하던 중 개발자가 실수로 DEPT 테이블을 삭제하였다고 합니다. 이 테이블은 전체 업무에서 사용되는 아주 중요한 데이터를 저장하고 있기 때문에 반드시 필요한 테이블이라고 합니다. 하지만, DROP 명령어는 AUTO-COMMIT을 자동 수행하기 때문에 삭제된 테이블은 더 이상 사용할 수 없게 됩니다.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> host date → 현재 날짜를 메모해 두십시오. SQL> host time → 현재 시간을 메모해 두십시오, SQL> drop table scott.dept cascade constraints; --> 개발자가 실수로 DEPT 테이블을 삭제하였다고 합니다. SQL> select * from scott.dept; select * from scott.dept * ERROR at line 1: ORA-00942: table or view does not exist

(3) 지금까지 대부분의 시나리오는 운영체계 상에서 관련된 파일들을 더 이상 사용할 수 없게 되는 경우에 대한 물리적 복구 방법이었다면, 이번 시나리오는 데이터베이스 내에서 중요한 테이블이 삭제된 경우의 논리적 복구방법을 소개하게 될 것 입니다. 이전에 오프라인 백업된 파일들 중에 모든 데이터 파일들 만 해당 경로에 재설치 하십시오. 
반드시, 데이터 파일들 만 재 설치하셔야 하며 컨트롤 파일과 리두로그 파일들은 정상적으로 사용 가능한 상태이므로 재 설치하실 필요는 없습니다.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> shutdown immediate SQL> exit [C:\] cd c:\backup [C:\] copy *.dbf c:\oracle\oradata\ora92 → 반드시, 모든 데이터 파일들 만 재 설치하십시오.

(4) 자, 그럼, 삭제된 하나의 테이블을 복구하기 위해 시간기반 불완전 복구작업을 수행해 보도록 하겠습니다.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] sqlplus "/as sysdba" SQL> startup mount SQL> recover database until time '2001-01-23:16:44:47'; ORA-00279: Change 7220 generated at 02/24/97 23:51:30 needed ORA-00289: Suggestion : c:\oracle\oradata\ora92\arch\arch_219.arc ORA-00280: Change 7220 for thread 1 is in sequence #219 Specify log: {<ret>=suggested | filename | AUTO | CANCEL} Auto ← 관련된 모든 아카이브 파일들을 자동으로 적용해 줍니다. Media Complete Recovery → 마지막, 오프라인 백업파일을 재 설치하고 그 이후에 생성된 아카이브 파일들을 순차적으로 적용하면서 실수로 테이블을 DROP한 이전 시점까지 만 복구한다면 삭제된 테이블을 복구할 수 있을 것 입니다. (2) 단계에서 메모해 둔 날자와 시간정보를 'YYYY-MM-DD HH:MM:SI'포맷으로 정의하시면 됩니다. 반드시, 날자 포맷을 임의로 변경해서는 안됩니다. SQL> alter database open resetlogs; → 불완전 복구가 수행되었으면 데이터베이스를 RESETLOG 옵션을 사용하여 OPEN 하십시오. 불완전 복구에 의한 복구작업 시에는 반드시 이 옵션을 사용하셔야 합니다. 현재, 데이터베이스는 과거 DEPT 테이블이 삭제되기 이전 상태로 복구된 상태 입니다. 그런데, 컨트롤 파일과 리두로그 파일은 복구작업을 수행하기 이전의 현 상태 에 대한 정보를 가지고 있기 때문에 시점이 일치하지 않는 문제점이 발생하게 됩니다. 결국, 이 상태에서는 데이터베이스를 정상적으로 OPEN 할 수 없기 때문에 RESETLOG 옵션을 사용하여 모든 상태정보를 초기화할 수 밖에 없게 됩니다. SQL> archive log list 데이터베이스 로그모드 아카이브 모드 가장 오래된 온라인 로그순서 1 ← 상태정보가 초기화된 것을 확인하십시오. 아카이브할 다음 로그 1 현재 로그순서 1 SQL> select * from scott.dept; → 삭제되었던 DEPT 테이블이 다시 검색됩니다. 현재, 데이터베이스는 DEPT 테이블이 삭제되기 이전 상태로 복구되어 있기 때문에 DEPT 테이블을 검색할 수 있는 것 입니다. SQL> shutdown immediate SQL> exit</ret>

5) 불완전 복구가 완료되었으면 현재 시점의 오프라인 백업을 수행하십시오. 대부분의 개발자들이 불완전 복구를 수행한 후 오프라인 백업을 수행하지 않다가 여가지 문제로 인해 데이터베이스를 복구하지 못하는 경우가 종종 발생합니다. 현재 시점에서는 마지막 오프라인 백업된 파일들은 더 이상 복구작업에 사용될 수 없는 무의미한 파일들에 불과합니다. 이유는 불완전 복구를 수행하게 되면, 데이터베이스 내의 모든 상태 정보들이 초기화되기 때문에 이전의 오프라인 백업 파일들이 가지고 있는 상태정보와 일치될 수 없기 때문 입니다.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] cd c:\oracle\oradata\ora92 [C:\] copy *.* c:\backup [C:\] copy c:\oracle\ora92\database\init.ora c:\backup → 관련된 모든 데이터 파일, 컨트롤 파일, 리두로그 파일, 파라메터 파일들을 오프라인 백업 하십시오. [C:\] del c:\oracle\oradata\ora92\arch\*.arc → 불완전 복구에 의해 데이터베이스의 모든 상태 정보들이 초기화되면 이전까지 생성 되었던 아카이브 파일들도 이젠 더 이상 필요 없는 파일들이 됩니다. 아카이브 파일들은 사용 가능한 마지막 오프라인 백업파일 이후에 생성된 것 들만 사용 가능하므로 초기화된 현재 시점에서는 이전의 아카이브 파일은 사용될 수 없습니다.
5-1-2 취소기반 불완전 복구

이번에는 불완전 복구의 두 번째 방법인 취소기반 복구방법에 대해서 알아 보도록 하겠습니다. 대부분의 기업환경에서 데이터베이스에 장애가 발생하면 장애가 발생한 시점까지의 모든 데이터를 안전하게 복구하는 것이 원칙일 것 입니다. 하지만, 백업 데이터 파일과 아카이브 파일의 보관 및 관리 상의 문제로 인해 복구를 정상적으로 수행하지 못하는 경우도 때로는 발생하게 됩니다. 이런 경우에는 사용 가능한 백업 데이터를 이용하여 복구할 수 있는 시점까지 만이라고 최대한 복구작업을 수행해야 할 것 입니다. 
바로 이런 경우의 복구방법을 취소기반 불완전 복구라고 합니다.

위 그림에서, 현재 시점 2001년 6월 10일 오전 12시에 데이터베이스를 종료한 후 오프라인 백업을 통해 SCN 번호가 95인 모든 파일(데이터 파일, 컨트롤 파일, 리두로그 파일)들을 백업하고 있습니다. 현재, 데이터베이스는 아카이브 모드이며, 오프라인 백업 이후 발생한 모든 트랜잭션 데이터들은 아카이브 파일과 리두로그 파일에 기록되어 있습니다. 
ARC1.LOG, ARC2.LOG, ARC3.LOG 파일에 모든 백업 데이터들이 저장되었다고 합니다. 
현재시점, 2001년 6월 12일 오후 13시, 시스템 관리자가 실수로 USERS01.DBF 데이터 파일을 삭제했다고 합니다. 이 사실을 모른체 사용자들은 해당 데이터 파일에 저장되어 있는 테이블에 대해 입력, 수정, 삭제작업을 수행하려고 합니다. 하지만, 이 시점에 해당 디크크에는 USERS01.DBF 파일은 존재하지 않기 때문에 사용자들은 더 이상 데이터베이스를 사용할 수 없게 됩니다. 문제는, 이 데이터 파일에 대한 복구 작업을 수행하기 위해 복구작업 시 사용되어야 할 모든 아카이브 파일들 중에 몇 개가 유실되어 사용될 수 없다고 합니다.


사례-8

어느 날, 모든 리두로그 파일이 존재하는 디스크에 장애가 발생했다고 합니다. 현재 데이터베이스는 아카이브 모드이며 최근에 전체 데이터베이스 백업이 수행되었다고 합니다. 

장애가 발생한 시점까지의 모든 데이터는 복구할 수 있을까요 ? 

결론적으로 말씀드리면, 마지막 백업 데이터가 저장되어 있던 온라인 리두로그 파일이 아카이브 되지 않은 상태에서 유실되었기 때문에 완전복구 작업은 수행할 수 없는 상태입니다. 
즉, 불완전 복구작업을 수행해야 합니다.


(1) 오라클 서버가 사용 가능한 상태인지 확인하고 MOREDEPT.SQL을 실행한 후 아카이브 파일들이 정상적으로 생성되는지 확인하십시오.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] sqlplus "/as sysdba" SQL> startup SQL> @moredept.sql alter system switch logfile; insert into scott.dept values(1,'Personnel','Pusan'); insert into scott.dept values(2,'Account','Pusan'); insert into scott.dept values(3,'Q.C','Pusan'); alter system switch logfile; insert into scott.dept values(4,'Personnel','Seoul'); insert into scott.dept values(5,'Account','Seoul'); insert into scott.dept values(6,'Q.C','Seoul'); alter system switch logfile; insert into scott.dept values(7,'Personnel','Daejeon'); insert into scott.dept values(8,'Account','Daejeon'); insert into scott.dept values(9,'Q.C','Daejeon'); commit; select count(*) from scott.dept;

(2) 이번 시나리오는 여러 개의 리두로그 파일들 중에 LGWR 프로세스에 의해 현재 쓰여지고 있는 CURRENT 리두로그 파일에 장애가 발생한 경우 복구하는 방법과 절차를 소개합니다. 먼저, 현재 사용하고 있는 오라클 서버에서 CURRENT 상태의 리두로그 파일을 확인하십시오. 그리고, CURRENT 리두로그 파일을 삭제하여 장애가 발생한 시나리오를 만들어 보시기 바랍니다.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> select member from v$log where status = 'CURRENT'; MEMBER --------------------------------------------------- c:\oracle\oradata\ora92\redo01.log → 만약, 현재 데이터베이스에서 REDO01.LOG 파일이 CURRENT 상태의 리두로그 파일이 라면 다음과 같이 화면에 출력됩니다. SQL> host dir c:\oracle\oradata\ora92 SQL> host del c:\oracle\oradata\ora92\redo01.log → Windows 환경의 운영체계에서는 서버에 의해 삭제가 안됩니다. SQL> host del c:\oracle\oradata\ora92\redo01b.log → Windows 환경의 운영체계에서는 서버에 의해 삭제가 안됩니다. SQL> host dir c:\oracle\oradata\ora92 SQL> @moredept.sql → 온라인 리두로그 파일이 유실되었기 때문에 에러가 발생합니다. 또는, 무한정 대기상태에 빠지게 되기도 합니다. SQL> shutdown abort → 에러가 발생하는 경우에는 오라클 서버가 자동 종료됩니다. 경우에 따라서는 무한정 대기상태에 빠지기도 하는데 이런 경우에는, 정상적인 복구작업을 수행하기 위해서 강제로 오라클 서버를 종료 시켜야 합니다. 바로 이때, SHUTDOWN 명령어의 ABORT 옵션을 이용하시면 오라클 서버를 강제 종료 시킬 수 있습니다.

(3) 자~ 그럼, CURRENT 리두로그 파일이 유실된 경우 불완전 복구를 수행해 봅시다. 
오라클 서버가 자동 종료되었거나, ABORT 옵션에 의해 강제 종료된 다음 다시 오라클 서버를 MOUNT 단계까지 만 시작한 다음 불완전 복구를 수행하기 위해 마지막 오프라인 백업 파일들 중에 모든 데이터 파일들 만 재 설치합니다.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> startup SQL> alter database drop logfile group 그룹번호; → 일반적으로 INACTIVE 리두로그 파일이 유실된 경우에는 관련 리두로그 파일을 제거한 후 다시 재 생성함으로써 복구작업을 완료할 수 있었습니다. 같은 방법으로 복구가 가능한지 수행해 보십시오. 하지만, CURRENT 리두로그 파일은 ALTER DATABASE DROP LOGFILE~ 명령어로는 더 이상 삭제할 수 없습니다. 왜냐하면, CURRENT 상태의 리두로그는 현재 쓰여지고 있는 파일을 의미하기 때문에 데이터베이스 관리자도 삭제할 수 없기 때문 입니다. SQL> shutdown immediate SQL> exit

(4) 다음은 정상적인 불완전 복구를 수행하는 방법과 절차입니다. 
먼저, 현재 생성되어 있는 마지막 아카이브 파일이 몇 번인지 확인해 두십시오. 다음과 같이 여러 가지 방법을 통해 확인할 수 있습니다.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>첫 번째 방법은 ALERT 파일의 로그 내용을 분석해 보면 마지막 아카이브 파일의 번호를 알아 낼 수 있습니다. [C:\] cd c:\oracle\admin\ora92\bdump [C:\] dir [C:\] edit ALERT_<db>명>.log → 파일의 끝부분으로 이동해서 Archiving을 실패한 기록과 Sequence 번호 확인 예를 들어, ORA-00255: error archiving log 1 of thread 1, sequence # 15 sequence # 15번이라면 마지막 아카이브 파일번호가 15번 입니다. 두 번째 방법은 아카이브 파일이 생성되어 있는 경로로 이동하여 마지막 파일 번호를 확인하는 방법입니다. [C:\] DEL C:\ORACLE\ORA92\DATABASE\ARCH [C:\] dir</db명>

(5) 이전에 마지막으로 오프라인 백업된 파일들 중에 모든 데이터 파일들만 재설치하십시오. 컨트롤 파일과 리두로그 파일들은 재 설치할 필요가 없습니다. 모든 파일들을 재 설치하게 되면 완전복구 방법이 되며, 데이터 파일들 만 설치하면 불완전 복구가 됩니다.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] cd c:\backup [C:\] copy *.dbf c:\oracle\oradata\ora92 [C:\] sqlplus "/as sysdba" SQL> startup mount SQL> recover database until cancel ORA-00279: Change 7220 generated at 02/24/97 23:51:30 needed ORA-00289: Suggestion : c:\oracle\oradata\ora92\arch\arch_1.arc ORA-00280: Change 7220 for thread 1 is in sequence #1 Specify log: {<ret>=suggested | filename | AUTO | CANCEL} Enter ← 1번 아카이브 파일을 적용해 줍니다. ORA-00279: Change 7220 generated at 02/24/97 23:51:30 needed ORA-00289: Suggestion : c:\oracle\oradata\ora92\arch\arch_2.arc ORA-00280: Change 7220 for thread 1 is in sequence #2 Specify log: {<ret>=suggested | filename | AUTO | CANCEL} Enter ← 2번 아카이브 파일을 적용해 줍니다. ………………………….. ORA-00279: Change 7220 generated at 02/24/97 23:51:30 needed ORA-00289: Suggestion : c:\oracle\oradata\ora92\arch\arch_15.arc ORA-00280: Change 7220 for thread 1 is in sequence #15 Specify log: {<ret>=suggested | filename | AUTO | CANCEL} Enter ← 15번 아카이브 파일을 적용해 줍니다. ORA-00279: Change 7220 generated at 02/24/97 23:51:30 needed ORA-00289: Suggestion : c:\oracle\oradata\ora92\arch\arch_16.arc ORA-00280: Change 7220 for thread 1 is in sequence #16 Specify log: {<ret>=suggested | filename | AUTO | CANCEL} CANCEL ← 아카이브 파일을 적용하기 전에 현재 시점까지 생성되어 있는 마지막 아카이브 파일이 15번까지 생성되어 있는 것을 확인하였습니다. 그렇다면, 16번 아카이브 파일은 존재하지 않으므로 더 이상 복구작업을 수행할 수 없습니다. CANCEL을 입력하면 복구작업은 중단됩니다. Media Complete Cancel. ← 불완전 복구작업이 완료되었습니다. SQL> alter database open resetlogs; → 불완전 복구는 데이터베이스의 모든 상태가 불 일치하기 때문에 복구작업을 완료한 후 반드시 RESETLOGS 옵션을 사용하여 OPEN 해야 합니다. 이 명령어를 실행하면 유실된 모든 리두로그 파일들이 자동으로 생성됩니다. SQL> archive log list 데이터베이스 로그모드 아카이브 모드 가장 오래된 온라인 로그순서 1 ← 모든 상태정보가 초기화 된 것을 확인하십시오. 아카이브할 다음 로그 1 현재 로그순서 1 SQL> shutdown immediate SQL> exit</ret></ret></ret></ret>

(6) 데이터베이스의 모든 상태정보가 초기화되는 불완전 복구방법이 수행되고 나면 마지막으로 백업되었던 백업파일은 더 이상 사용할 수 없으므로 반드시 오프라인 백업을 수행해야 합니다. 또한, 오프라인 백업이 수행되고 나면 이전의 모든 트레이스 파일와 로그 파일, 아카이브 파일들을 삭제하십시오.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] cd c:\oracle\oradata\ora92 [C:\] copy *.* c:\backup [C:\] copy c:\oracle\ora92\database\init.ora c:\backup [C:\] del c:\oracle\admin\ora92\udump\*.trc [C:\] del c:\oracle\admin\ora92\bdump\alert_<db>명>.log [C:\] cd c:\oracle\ora92\database\arch [C:\] del *.arc [C:\] dir</db명>
사례-9

데이터베이스의 컨트롤 파일이 존재하는 디스크에 장애가 발생하여 더 이상 입력, 수정, 삭제 작업을 수행할 수 없습니다. 모든 컨트롤이 유실된 상태이며 마지막으로 백업된 컨트롤 파일 만이 사용 가능한 상태입니다. 어떻게 복구해야 할까요 ?


(1) 오라클 서버가 사용 가능한 상태인지 확인하고 MOREDEPT.SQL을 실행한 후 아카이브 파일들이 정상적으로 생성되는지 확인하십시오.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] sqlplus "/as sysdba" SQL> startup SQL> @moredept alter system switch logfile; insert into scott.dept values(1,'Personnel','Pusan'); insert into scott.dept values(2,'Account','Pusan'); insert into scott.dept values(3,'Q.C','Pusan'); alter system switch logfile; insert into scott.dept values(4,'Personnel','Seoul'); insert into scott.dept values(5,'Account','Seoul'); insert into scott.dept values(6,'Q.C','Seoul'); alter system switch logfile; insert into scott.dept values(7,'Personnel','Daejeon'); insert into scott.dept values(8,'Account','Daejeon'); insert into scott.dept values(9,'Q.C','Daejeon'); commit; select count(*) from scott.dept; SQL> host dir c:\oracle\ora92\database\arch\*.arc

(2) 이번 사례는 데이터베이스의 모든 상태정보와 오라클 서버의 시작과 종료 시 반드시 필요한 컨트롤 파일에 대한 내용입니다. 
여러 개의 컨트롤 파일 중 하나라도 장애가 발생하면 더 이상 오라클 서버를 사용할 수 없기 때문에 오라클 데이터베이스 구조 중에 가장 중요한 파일 중에 하나입니다. 
먼저, 현재 사용하고 있는 오라클 서버에서 컨트롤 파일의 위치와 개수를 확인하십시오. 그리고, 모든 컨트롤 파일을 삭제하여 장애가 발생한 시나리오를 만들어 보시기 바랍니다.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> shutdown abort --> 오라클 서버가 비정상적으로 종료됩니다. SQL> exit [C:\] del c:\oracle\oradata\ora92\*.ctl ← 사용자의 실수로 인해 모든 컨트롤 파일이 삭제됩니다. (실제 기업환경에서는 임의로 컨트롤 파일을 삭제해서는 안됩니다.)

(3) 결론적으로 모든 컨트롤 파일에 장애가 발생하면 더 이상 오라클 데이터베이스를 사용할 수 없게 됩니다. 이런 현상이 발생하는 경우에는 불완전 복구방법을 사용합니다. 
마지막 오프라인 백업된 백업 파일로부터 모든 컨트롤 파일을 현재 경로로 재 설치하십시오.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\]copy c:\backup\*.ctl c:\oracle\oradata\ora92\*.ctl [C:\] sqlplus "/as sysdba" SQL> startup mount SQL> recover database using BACKUP controlfile ← 현재 환경은 컨트롤 파일 만 이전의 백업 파일이고 다른 파일들은 현재 시점의 파일들이기 때문에 컨트롤 파일 만의 복구작업을 수행하기 위해 USING BACKUP CONTROLFILE 절을 사용하여 복구작업을 수행해야 합니다. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed for thread 1 Specify log: {<ret>=suggested | filename | AUTO | CANCEL} C:\oracle\oradata\ora92\arch\arch_1.arc ← 만약, 적용해야 할 아카이브 파일이 지정되지 않으면 직접 첫 번째 아카이브 파일의 경로와 이름을 입력해야 합니다. 적용해야 할 아카이브 파일명이 출력 되는 경우에는 AUTO 키워드를 입력하여 자동으로 아카이브를 적용하시면 됩니다. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed ORA-00280: Change 8050 for thread 1 is in sequence arch_2.arc Specify log: {<ret>=suggested | filename | AUTO | CANCEL} AUTO ← 첫 번째 아카이브를 적용하면 두 번째 아카이브 파일의 이름과 경로가 출력되고 해당 파일을 적용할 것 인지가 나타납니다. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed ORA-00280: Change 8050 for thread 1 is in sequence arch_n.arc ← 여러 개의 아카이브 파일을 적용하다 마지막 아카이브 파일을 적용하려고 했을 때 에러가 발생할 수 도 있습니다. 이런 경우는 적용해야 할 마지막 백업 데이터가 아카이브 파일로 저장되어 있는 것이 아니라, CURRENT 리두로그 파일에 저장되어 있기 때문입니다. 이러 경우에는 마지막 CURRENT 리두로그 파일의 경로와 이름을 지정해 주시면 됩니다. SQL> recover database using BACKUP controlfile 에러가 발생하면 다시 리두로그 파일을 적용해 줄 수 없으므로 RECOVER DATABASE 명령어를 재 수행하시면 됩니다. ORA-00279: Change 8050 generated at 01/20/98 15:22:26 needed ORA-00280: Change 8050 for thread 1 is in sequence arch_n.arc Specify log: {<ret>=suggested | filename | AUTO | CANCEL} c:\oracle\oradata\ora92\redo01.log --> 마지막 CURRENT 리두로그 파일명을 입력하십시오 Log applied. Media recovery complete. SQL> alter database open resetlogs; ← 절차와 방법은 완전복구 방법과 같지만 결론적으로 이 방법은 불완전 복구입니다. 왜냐하면, 데이터베이스의 모든 상태정보가 저장되어 있는 컨트롤 파일이 삭제되었 기 때문에 컨트롤 파일은 복구되었지만 상태정보는 복구되지 않았기 때문입니다. SQL> select count(*) from scott.dept; --> 정상적으로 검색이 가능합니다. SQL> shutdown SQL> exit</ret></ret></ret>

(4) 불완전 복구를 수행하고 나면 반드시 이전의 마지막 백업파일은 재 사용될 수 없기 때문에 다시 오프라인 백업을 수행해야 합니다. 또한, 이전의 아카이브 파일, 트레이스 파일들도 제거 하십시오.

<xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] cd c:\oracle\oradata\ora92 [C:\] copy *.* c:\backup [C:\] copy c:\oracle\ora92\database\init.ora c:\backup

 

Posted by redkite
, |

오라클 사에서 제공하는 완전복구 방법에 대해 소개하기 전에 데이터베이스 관리자로써 장애와 복구에 대한 전반적인 내용을 이해하고 장애가 발생한 경우 효과적으로 복구작업을 수행하기 위해서 반드시 준비하셔야 할 내용이 있습니다. 
그것은 바로, 여러분들이 관리하고 계시는 오라클 데이터베이스의 모든 파일에 대한 구조와 시스템에 대한 기본적인 정보입니다. 
데이터베이스 관리자가 평소에 얼마나 정확하게 자신이 관리하고 있는 데이터베이스의 물리적 구조를 잘 이해하느냐는 장애 발생 시 얼마나 빠르고 효과적으로 데이터베이스를 복구할 수 있느냐를 결정하는 첫 번째 기준이 됩니다.

 

4장 OFF-Line 백업을 이용한 완전복구

  4-1 데이터베이스의 구조분석

먼저, 오라클 사에서 제공하는 완전복구 방법에 대해 소개하기 전에 데이터베이스 관리자로써 장애와 복구에 대한 전반적인 내용을 이해하고 장애가 발생한 경우 효과적으로 복구작업을 수행하기 위해서 반드시 준비하셔야 할 내용이 있습니다.

그것은 바로, 여러분들이 관리하고 계시는 오라클 데이터베이스의 모든 파일에 대한 구조와 시스템에 대한 기본적인 정보입니다.

데이터베이스 관리자가 평소에 얼마나 정확하게 자신이 관리하고 있는 데이터베이스의 물리적 구조를 잘 이해하느냐는 장애 발생 시 얼마나 빠르고 효과적으로 데이터베이스를 복구할 수 있느냐를 결정하는 첫 번째 기준이 됩니다.

다음은 오라클 데이터베이스의 모든 물리적 구조정보를 분석하는 방법입니다.


1) 현재 생성되어 있는 모든 물리적 구조를 분석한 다음 그 정보를 파일로 생성하십시오.
<xmp></xmp>[C:\] sqlplus "/as sysdba" SQL> SPOOL oracle_files.dat - 먼저, 모든 데이터 파일의 구조를 분석하십시오. <xmp></xmp>SQL> COL TABLESPACE_NAME FORMAT A15 SQL> COL FILE_NAME FORMAT A50 SQL> SELECT file_id, file_name, tablespace_name FROM dba_data_files; FILE_ID FILE_NAME TABLESPACE_NAME -------- ------------------------------------- --------------- 1 C:\ORACLE\ORADATA\ORA92\SYSTEM01.DBF SYSTEM 2 C:\ORACLE\ORADATA\ORA92\UNDOTBS.DBF UNDOTBS 3 C:\ORACLE\ORADATA\ORA92\TEMP01.DBF TEMP 4 C:\ORACLE\ORADATA\ORA92\USERS01.DBF USERS- 다음은, 모든 컨트롤 파일의 구조를 분석하십시오. <xmp></xmp>SQL> COL NAME FORMAT A50 SQL> SELECT * FROM v$controlfile; STATUS NAME ------------------------------------------------ C:\ORACLE\ORADATA\ORA92\CONTROL01.CTL C:\ORACLE\ORADATA\ORA92\CONTROL02.CTL C:\ORACLE\ORADATA\ORA92\CONTROL03.CTL- 마지막으로, 모든 리두로그 파일의 구조를 분석하십시오. <xmp></xmp>SQL> COL MEMBER FORMAT A50 SQL> SELECT * FROM v$logfile; GROUP# STATUS TYPE MEMBER ---------- --------- ------ ---------------------------------- 1 ONLINE C:\ORACLE\ORADATA\ORA92\REDO01.LOG 2 ONLINE C:\ORACLE\ORADATA\ORA92\REDO02.LOG 3 ONLINE C:\ORACLE\ORADATA\ORA92\REDO03.LOG SQL> SPOOL OFF ← 운영체계 상에 ORACLE_FILE.DAT 파일이 생성됩니다. SQL> EXIT [C:\] EDIT ooracle_files.dat ← 저정된 물리적 구조정보를 참조할 수 있습니다.

4-2 완전복구 방법
4-2-1 전체 완전 복구

아카이브 모드 환경에서 데이터베이스에 장애가 발생하면 2가지 방법으로 복구작업을 수행할 수 있습니다. 첫 번째 방법은 완전 복구(Complete Recovery) 이며, 두 번째 방법은 불완전 복구(InComplete Recovery) 입니다.

장애가 발생한 시점에 어떤 복구 방법에 의해 데이터베이스를 복구할 것인지를 결정하는 것은 장애의 발생상태 및 복구 전략에 따라 선별적으로 사용할 수 있습니다.

예를 들어, 장애가 발생한 상태를 확인했을 때, 데이터 파일 만 문제가 생긴 경우와 데이터 파일과 리두로그 파일 모두에 문제가 발생한 경우에 복구 방법은 달라질 수 있다는 것 입니다. 또는, 오라클 데이터베이스를 구성하는 파일구조에 문제가 발생한 것이 아니라, 특정 테이블을 사용자가 실수에 의해 DROP 한 경우 복구 방법은 달라질 수 있습니다.

결론적으로, 장애가 발생한 시점에 먼저, 장애 원인을 정확하게 분석할 수 있어야 하며, 그 결과에 따라 적절한 복구 방법을 선택해야 한다는 것 입니다.

이러한 과정을 통해 장애 복구를 원활하게 수행하기 위해서는 오라클 서버의 구조를 완벽하게 이해해야 하며, 또한 각각의 복구 방법과 절차에 대한 명확한 이해와 장단점을 잘 알고 있어야 합니다.

자 ~ 그럼 아카이브 모드에서 수행할 수 있는 완전복구에 대해 보다 자세히 알아 봅시다.

완전복구(Complete Recovery)는 데이터베이스에 장애가 발생한 경우 마지막으로 수행한 오프라인 백업 데이터와 그 이후 생성된 아카이브 파일 그리고 아카이브 되지 않은 현재 시점의 백업 데이터를 저장하고 있는 리두로그 파일을 통해 장애가 발생한 시점까지의 모든 데이터를 완전하게 복구하는 방법입니다.

위 그림에서, 현재시점 2001년 6월 10일 오전 12시에 데이터베이스를 종료한 후 오프라인 백업을 통해 SCN 번호가 95인 모든 파일(데이터 파일, 컨트롤 파일, 리두로그 파일)들을 백업하고 있습니다. 현재, 데이터베이스는 아카이브 모드이며, 오프라인 백업 이후 발생한 모든 트랜잭션 데이터들은 아카이브 파일과 리두로그 파일에 기록되어 있습니다.

첫 번째 아카이브 파일 ARC1.LOG 에는 마지막 오프라인 백업 이후부터 2001년 6월 11일 오전 12시까지의 백업 데이터들이 저장 되었다고 합니다.

그리고, 두 번째 아카이브 파일 ARC2.LOG 에는 2001년 6월 11일 오전 12시부터 2001년 6월 12일 오전 12시까지의 백업 데이터들이 저장되었으며, 2001년 6월 12일 오전 12시부터 6월 12일 오후 13시까지의 데이터들은 ARC3.LOG 파일에 기록되어 있다고 합니다.

현재 시점, 2001년 6월 12일 오후 13시에 USERS01.DBF 데이터 파일이 저장되어 있는 디스크에 장애가 발생하여 더 이상 데이터베이스를 사용할 수 없다고 합니다.


사례-4.

아카이브 모드에서 DB 내의 특정 데이터 파일들이 장애가 발생하여 더 이상 입력, 수정, 삭제 작업을 수행할 수 없다고 합니다. 다행히 최근에 백업된 데이터 파일들과 아카이브 파일들은 정상적으로 사용 가능한 상태라고 합니다. 전체 데이터베이스 완전 복구를 수행해 보도록 하겠습니다.


1) 오라클 서버가 사용 가능한 상태인지 확인하고 아카이브 파일들이 정상적으로 생성되는지 확인하십시오. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] sqlplus "/as sysdba" SQL> startup SQL> host dir c:\oracle\oradata\ora92\arch\*.arc → 현재, 아카이브 파일의 개수와 마지막 아카이브 파일번호를 메모해 두십시오. SQL> host more moredept.sql alter system switch logfile; insert into scott.dept values(1,'Personnel','Pusan'); insert into scott.dept values(2,'Account','Pusan'); insert into scott.dept values(3,'Q.C','Pusan'); alter system switch logfile; insert into scott.dept values(4,'Personnel','Seoul'); insert into scott.dept values(5,'Account','Seoul'); insert into scott.dept values(6,'Q.C','Seoul'); alter system switch logfile; insert into scott.dept values(7,'Personnel','Daejeon'); insert into scott.dept values(8,'Account','Daejeon'); insert into scott.dept values(9,'Q.C','Daejeon'); commit; select count(*) from scott.dept; → 이 스크립트를 실행하면 아카이브 파일들이 생성됩니다. SQL> @moredept.sql SQL> shutdown immediate SQL> exit [C:\] dir c:\oracle\oradata\ora92\arch\*.arc → MOREDEPT.SQL을 실행한 후 아카이브 파일이 몇 개 추가생성 되었는지 확인하십시오.
2) 이 사례를 위해 USERS01.DBF 파일을 삭제한 후 오라클 서버를 다시 시작해 보십시오. OPEN 단계에서 파일의 삭제로 인해 데이터베이스의 무결성이 보장되지 않아 에러가 발생할 것 입니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\]dir c:\oracle\oradata\ora92\*.dbf → USERS 테이블스페이스를 구성하는 데이터 파일 [C:\]del c:\oracle\oradata\ora92\users01.dbf → 해당 파일이 존재하는 디스크에 장애가 발생한 것으로 시나리오를 만듭니다. [C:\] dir c:\oracle\oradata\ora92\*.dbf [C:\] sqlplus "/as sysdba" SQL> startup ORA-01157 데이터 9파일을 식별 또는 잠금할 수 없습니다-DBWR 추적파일을 보십시오 ORA-01110 : 9 데이터 파일: C:\ORALCE\ORADATA\ORA92\USERS01.DBF SQL> shutdown SQL> exit
3) 이전에 받은 전체 오프라인 백업파일로부터 손상된 데이터 파일들을 재설치 한 후 전체 완전복구 방법으로 복구작업을 수행합니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\]cd c:\backup [C:\] dir [C:\]copy users01.dbf c:\oracle\oradata\ora92\users01.dbf [C:\]sqlplus "/as sysdba" SQL> startup Database mounted. ORA-01113: 9 파일이 매체 복구되어야 합니다. ORA-01110: 9 데이터 파일: C:\ORALCE\ORADATA\ORA92\USERS01.DBF SQL> SELECT * FROM V$RECOVER_FILE; FILE# ONLINE ERROR CHANGE# --------------------------------------------- 9 ONLINE 406577 SQL> recover database ORA-00279: Change 7474 generated at 04/24/97 22:52:31 ORA-00289: Suggestion : c:\oracle\oradata\ora92\arch\arch_256.arc ORA-00280: Change 7474 for thread 1 is in sequence #256 Specify log: {<ret>=suggested | filename | AUTO | CANCEL} AUTO ← AUTO를 입력한 후 Enter를 누르면 모든 아카이브 파일들을 자동으로 적용해줍니다. Media recovery complete. → 정상적으로 복구작업이 완료되면 반드시 이 메시지가 출력됩니다. SQL> alter database open; → 현재 오라클 서버는 마운트 상태이므로 OPEN 합니다.</ret>
4) 오라클 데이터베이스가 정상적으로 복구 되었는지 확인해 보십시오. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> select count(*) from scott.DEPT; SQL> shutdown immediate SQL> exit
4-2-2 테이블스페이스 완전복구

이번에는, 완전복구(Complete Recovery) 3가지 방법 중에 테이블스페이스 완전복구에 대해 알아 보도록 하겠습니다. 전체 완전복구는 MOUNT 단계에서 모든 데이터 파일을 대상으로 복구작업을 수행하는 방법이라면, 테이블스페이스 완전복구는 OPEN 단계에서, 장애가 발생한 데이터 파일의 테이블스페이스를 기준으로 복구 작업을 수행하게 됩니다.

위 그림에서, 현재시점 2001년 6월 10일 오전 12시에 데이터베이스를 종료한 후 오프라인 백업을 통해 SCN 번호가 95인 모든 파일(데이터 파일, 컨트롤 파일, 리두로그 파일)들을 백업하고 있습니다. 현재, 데이터베이스는 아카이브 모드이며, 오프라인 백업 이후 발생한 모든 트랜잭션 데이터들은 아카이브 파일과 리두로그 파일에 기록되어 있습니다.

ARC1.LOG, ARC2.LOG, ARC3.LOG 파일에 모든 백업 데이터들이 저장되었다고 합니다.

현재시점, 2001년 6월 12일 오후 13시에 USERS01.DBF 데이터 파일이 저장되어 있는 디스크에 장애가 발생하여 더 이상 관련 테이블스페이스를 사용할 수 없다고 합니다.


사례-5.

아카이브 모드에서 DB 내의 특정 데이터 파일들이 장애가 발생하여 더 이상 입력, 수정, 삭제 작업을 수행할 수 없다고 합니다. 다행히 최근에 백업된 데이터 파일들과 아카이브 파일들은 정상적으로 사용 가능한 상태라고 합니다. 그리고, 문제가 발생한 데이터 파일은 특정 테이블스페이스에 포함된 데이터 파일이라고 합니다.

이런 경우, 데이터베이스 전체를 대상으로 복구작업을 수행하게 되면 많은 시간이 소요될 수 있으므로 테이블스페이스 완전 복구방법을 수행해 보도록 하겠습니다.


1) 오라클 서버가 사용 가능한 상태인지 확인하고 아카이브 파일들이 정상적으로 생성되는지 확인하십시오. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] sqlplus "/as sysdba" SQL> startup SQL> host dir c:\oracle\ora92\database\arch\*.arc → 현재, 생성되어 있는 아카이브 파일의 개수 및 마지막 파일명을 메모해 두십시오. SQL> host more moredept.sql alter system switch logfile; insert into scott.dept values(1,'Personnel','Pusan'); insert into scott.dept values(2,'Account','Pusan'); insert into scott.dept values(3,'Q.C','Pusan'); alter system switch logfile; insert into scott.dept values(4,'Personnel','Seoul'); insert into scott.dept values(5,'Account','Seoul'); insert into scott.dept values(6,'Q.C','Seoul'); alter system switch logfile; insert into scott.dept values(7,'Personnel','Daejeon'); insert into scott.dept values(8,'Account','Daejeon'); insert into scott.dept values(9,'Q.C','Daejeon'); commit; select count(*) from scott.dept; SQL> @moredept.sql SQL> shutdown immediate SQL> exit [C:\]dir c:\oracle\ora92\database\arch\*.arc → MOREDEPT.SQL을 실행한 후 생성된 아카이브 파일의 개수와 마지막 파일명을 메모해 두십시오.
2) 이 실습을 위해 USERS01.DBF 파일을 삭제한 후 오라클 서버를 재 시작해 보십시오. OPEN 단계에서 해당 파일이 존재하지 않으므로 에러가 발생할 것 입니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\]dir c:\oracle\oradata\ora92\*.dbf → USERS 테이블스페이스를 구성하고 있는 데이터 파일명을 확인하십시오. [C:\]del c:\oracle\oradata\ora92\users01.dbf → 이 실습을 위해 해당 파일을 삭제합니다. [C:\] dir c:\oracle\oradata\ora92\*.dbf [C:\] sqlplus "/as sysdba" SQL> startup ORA-01157 데이터 9파일을 식별 또는 잠금할 수 없습니다-DBWR 추적파일을 보십시오 ORA-01110 : 9 데이터 파일: C:\ORALCE\ORADATA\ORA92\USERS01.DBF SQL> shutdown SQL> exit
3) 이전에 수행된 전체 오프라인 백업 파일들로부터 손상된 USERS01.DBF 파일을 재설치한 후 테이블스페이스 완전복구 방법을 이용한 복구작업을 수행하십시오, <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\]cd c:\backup [C:\]dir [C:\]copy users01.dbf c:\oracle\oradata\ora92\users01.dbf [C:\]sqlplus "/as sysdba" SQL> startup Database mounted. ORA-01113: 9 파일이 매체 복구되어야 합니다. ORA-01110: 9 데이터 파일: C:\ORALCE\ORADATA\ORA92\USERS01.DBF SQL> SELECT * FROM V$RECOVER_FILE; FILE# ONLINE ERROR CHANGE# ------ ----------- ------------- ------------ 9 ONLINE 406577 SQL> select FILE#, STATUS, NAME from v$datafile; ← USERS01.DBF 파일의 상태는 ONLINE SQL> alter database datafile 'c:\oracle\oradata\ora92\users01.dbf' offline; SQL> select FILE#, STATUS, NAME from v$datafile; ← USERS01.DBF 파일의 상태는 OFFLINE SQL> alter database open; SQL> select TABLESPACE_NAME, STATUS from dba_tablespaces; TABLESPACE_NAME STATUS ----------------------- -------------------------- USERS ONLINE SQL> alter tablespace users offline immediate; SQL> select TABLESPACE_NAME, STATUS from dba_tablespaces; TABLESPACE_NAME STATUS ------------------------ ------------------------ USERS OFFLINE SQL> recover tablespace users ORA-00279: Change 7220 generated at 02/24/97 23:51:30 ORA-00289: Suggestion : /DBAX/DBA805/dba숫자/arch_219.arc ORA-00280: Change 7220 for thread 1 is in sequence #219 Specify log: {<ret>=suggested | filename | AUTO | CANCEL} AUTO → 관련된 모든 아카이브 파일들을 자동 적용해 줍니다. SQL> select count(*) from scott.dept; ← 에러 발생, 복구는 되었지만 offline 상태 ORA-00376: 현재 파일 9를 읽을 수 없습니다. ORA-01110: 9 데이터 파일 SQL> alter tablespace users online; SQL> select count(*) from scott.dept; → 정상적으로 수행 됨 SQL> shutdown immediate SQL> exit</ret>
4-2-3 데이터 파일 완전복구

이번에는, 완전복구의 마지막 방법 인 데이터 파일 완전복구 방법을 소개하도록 하겠습니다.

위 그림에서, 현재시점 2001년 6월 10일 오전 12시에 데이터베이스를 종료한 후 오프라인 백업을 통해 SCN 번호가 95인 모든 파일(데이터 파일, 컨트롤 파일, 리두로그 파일)들을 백업하고 있습니다. 현재, 데이터베이스는 아카이브 모드이며, 오프라인 백업 이후 발생한 모든 트랜잭션 데이터들은 아카이브 파일과 리두로그 파일에 기록되어 있습니다. 
ARC1.LOG, ARC2.LOG, ARC3.LOG 파일에 모든 백업 데이터들이 저장되었다고 합니다. 
현재시점, 2001년 6월 12일 오후 13시에 USERS01.DBF 데이터 파일이 저장되어 있는 디스크에 장애가 발생하여 더 이상 관련 파일을 사용할 수 없다고 합니다.


사례-6

아카이브 모드에서 DB 내에 특정 데이터 파일들이 장애가 발생하여 더 이상 입력, 수정, 삭제 작업을 수행할 수 없다고 합니다. 다행히 최근에 백업된 데이터 파일들과 아카이브 파일들은 정상적으로 사용 가능한 상태라고 합니다. 현재, 장애가 발생한 데이터 파일은 하나의 데이터 파일이라고 합니다. 
이런 경우, 전체 데이터베이스 또는 특정 테이블스페이스 완전 복구방법을 수행하게 되면 불필요한 복구 시간이 소요될 수 있으므로 이번에는 데이터 파일 완전 복구 방법을 수행해 보도록 하겠습니다.


1) 오라클 서버가 사용 가능한 상태인지 확인하고 아카이브 파일들이 정상적으로 생성되는지 확인하십시오. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] sqlplus "/as sysdba" SQL> startup SQL> host dir c:\oracle\ora92\database\arch\*.arc → 현재 생성되어 있는 아카이브 파일의 개수와 마지막 파일명을 메모해 두십시오. SQL> host more moredept.sql alter system switch logfile; insert into scott.dept values(1,'Personnel','Pusan'); insert into scott.dept values(2,'Account','Pusan'); insert into scott.dept values(3,'Q.C','Pusan'); alter system switch logfile; insert into scott.dept values(4,'Personnel','Seoul'); insert into scott.dept values(5,'Account','Seoul'); insert into scott.dept values(6,'Q.C','Seoul'); alter system switch logfile; insert into scott.dept values(7,'Personnel','Daejeon'); insert into scott.dept values(8,'Account','Daejeon'); insert into scott.dept values(9,'Q.C','Daejeon'); commit; select count(*) from scott.dept; SQL> @moredept.sql SQL> shutdown immediate SQL> exit [C:\]dir c:\oracle\ora92\database\arch\*.arc → MOREDEPT.SQL을 실행한 후 추가 생성된 아카이브 파일의 개수와 마지막 파일명을 메모해 두십시오.
2) 이 실습예제를 수행하기 위해 USERS01.DBF 파일을 삭제한 후 오라클 서버를 다시 시작해 보십시오. 해당 파일이 더 이상 존재하지 않기 때문에 OPEN 단계에서 에러가 발생할 것 입니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\]dir c:\oracle\oradata\ora92\*.dbf → USERS 테이블스페이스가 구성하는 테이터 파일을 확인하십시오. [C:\]del c:\oracle\oradata\ora92\users01.dbf → 실습 시나리오를 위해 USERS01.DBF 파일을 삭제하십시오. [C:\] dir c:\oracle\oradata\ora92\*.dbf [C:\] sqlplus "/as sysdba" SQL> startup ORA-01157 데이터 9파일을 식별 또는 잠금할 수 없습니다-DBWR 추적파일을 보십시오 ORA-01110 : 9 데이터 파일: C:\ORALCE\ORADATA\ORA92\USERS01.DBF SQL> shutdown SQL> exit
3) 이전에 수행된 전체 오프라인 백업 파일로부터 해당 파일을 재설치하고 데이터 파일 완전복구 방법을 이용한 복구작업을 수행하십시오. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] cd c:\backup [C:\] copy users01.dbf c:\oracle\oradata\ora92\users01.dbf [C:\]sqlplus "/as sysdba" SQL> startup Database mounted. ORA-01113: 9 파일이 매체 복구되어야 합니다. ORA-01110: 9 데이터 파일: C:\ORALCE\ORADATA\ORA92\USERS01.DBF SQL> SELECT * FROM V$RECOVER_FILE; FILE# ONLINE ERROR CHANGE# ------ --------- ------------- ----------------- 9 ONLINE 406577 SQL> select FILE#, STATUS, NAME from v$datafile; ← USERS01.DBF 파일은 삭제되었지만 데이터 딕션어리에는 해당 파일이 아직 사용 가능한 상태로 나타납니다.(ONLINE 컬럼이 ONLINE) 데이터 파일 완전복구 작업을 수행하기 위해서는 OFFLINE 상태이어야 합니다. SQL> alter database datafile 'c:\oracle\oradata\ora92\users01.dbf' offline; SQL> alter database open; ← 컨트롤 파일 내에 USERS01.DBF 파일의 상태가 OFFLINE 되었기 때문에 오라클 서 버를 오픈할 수 있습니다. 이 의미는 USERS01.DBF가 ONLINE 상태에서는 항상 파 일의 존재 유무를 확인하게 되지만, OFFLINE 상태에서는 확인하지 않기 때문에 오라클 서버를 오픈할 수 있게 됩니다. SQL> recover datafile ' c:\oracle\oradata\ora92\users01.dbf' ; ORA-00279: Change 7220 generated at 02/24/97 23:51:30 needed ORA-00289: Suggestion : c:\oracle\oradata\ora92\arch\arch_219.arc ORA-00280: Change 7220 for thread 1 is in sequence #219 Specify log: {<ret>=suggested | filename | AUTO | CANCEL} Auto ← 관련된 모든 아카이브 파일들을 자동으로 적용해 줍니다. Media Complete Recovery … ← 정상적으로 복구작업이 완료되었습니다. SQL> select count(*) from scott.dept; - → USERS01.DBF 파일은 아직 OFFLINE 상태이기 때문에 검색할 수 없습니다. SQL> alter database datafile 'c:\oracle\oradata\ora92\users01.dbf ' online; SQL> select count(*) from scott.dept; → 정상적으로 수행 됨</ret>

 

Posted by redkite
, |
백업방법
오라클 DB 백업은 1)물리적 백업(physical backup)과, 2)논리적 백업(Logical backup)의 두가지 방법이 있다.

물리적 백업

물리적인 백업은 데이터베이스 파일(데이터 파일, 컨트롤 파일)을 백업하는 것을 뜻하며, DB가 아카이브 모드에서 수행중인 경우에는 아카이브 리두 로그 파일이 자동적으로 생성되므로 데이터 파일, 컨트롤 파일, 아카이브 리두 로그 파일이 백업된다. 
물리적 백업은 다음과 같이 두 가지가 가능하다.

 • 오프라인 백업
 • 온라인 백업

오프라인 백업
Off-line backup은 테이블스페이스나 데이터 파일이 오프라인일 때 실행되는 백업으로, 가장 수행하기 쉬운 백업방법중의 하나이다. 오프라인 백업은 DB를 종료하고, Db와 관련된 모든 물리적인 파일(데이터 파일, 컨트롤 파일, 매개변수 파일)을 운영체제 명령어를 이용하여 복사한다.

이 백업은 데이터 파일의 크기가 매우 큰 경우, 많은 시간이 소요될 수 도 있다. 그래서 오프라인 백업을 whole-backup 또는 cold-backup이라 한다.

$ sqlplus system/manager as sysdba   ☜ DBA로 접속

SQL> select name from v$controlfile;   ☜ 컨트롤 파일의 위치를 확인
 
NAME
--------------------------------------------------------------------------------
/export/home/oracle/app/oracle/oradata/orcl/control01.ctl
/export/home/oracle/app/oracle/oradata/orcl/control02.ctl
/export/home/oracle/app/oracle/oradata/orcl/control03.ctl
 
SQL> select file_name from dba_data_files;   ☜ 데이터 파일의 확인
 
FILE_NAME
--------------------------------------------------------------------------------
/export/home/oracle/app/oracle/oradata/orcl/users01.dbf
/export/home/oracle/app/oracle/oradata/orcl/sysaux01.dbf
/export/home/oracle/app/oracle/oradata/orcl/undotbs01.dbf
/export/home/oracle/app/oracle/oradata/orcl/system01.dbf
 
SQL> select group#,member from v$logfile;   ☜ 리두 로그 파일을 확인
 
    GROUP# MEMBER
---------- ------------------------------------------------------------
         3 /export/home/oracle/app/oracle/oradata/orcl/redo03.log
         2 /export/home/oracle/app/oracle/oradata/orcl/redo02.log
         1 /export/home/oracle/app/oracle/oradata/orcl/redo01.log
 
SQL>
SQL> shutdown normal;    ☜ normal, transaction, immediate중 하나로 DB를 종료
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> !    ☜ 쉘 프롬프트로 일시 복귀함
$ su     ☜ root의 권한을 가짐
Password: 
# cp /export/home/oracle/app/oracle/oradata/orcl/control0*.ctl /export/home/work/.     ☜ 컨트롤 파일 복사
# cp /export/home/oracle/app/oracle/oradata/orcl/redo*.log /export/home/work/.    ☜ 리두 로그 파일 복사
# cp /export/home/oracle/app/oracle/oradata/orcl/*.dbf /export/home/work/.     ☜ 데이터 파일 복사
# cp dbs/*.ora /export/home/work/.    ☜ 파라미터 파일 복사
# ls -l /export/home/work     ☜ 복사되었나 확인
-rw-r-----   1 root     other      2867200 Jan  4 11:07 control01.ctl
-rw-r-----   1 root     other      2867200 Jan  4 11:07 control02.ctl
-rw-r-----   1 root     other      2867200 Jan  4 11:07 control03.ctl
-rw-r--r--   1 root     other         8384 Jan  4 11:14 init.ora
-rw-r--r--   1 root     other        12920 Jan  4 11:14 initdw.ora
-rw-r-----   1 root     other     10486272 Jan  4 11:09 redo01.log
-rw-r-----   1 root     other     10486272 Jan  4 11:09 redo02.log
-rw-r-----   1 root     other     10486272 Jan  4 11:09 redo03.log
-rw-r-----   1 root     other         2560 Jan  4 11:14 spfileorcl.ora
-rw-r-----   1 root     other    461381632 Jan  4 11:10 sysaux01.dbf
-rw-r-----   1 root     other    471867392 Jan  4 11:11 system01.dbf
-rw-r-----   1 root     other     20979712 Jan  4 11:11 temp01.dbf
-rw-r-----   1 root     other     26222592 Jan  4 11:11 undotbs01.dbf
-rw-r-----   1 root     other      5251072 Jan  4 11:11 users01.dbf

# exit     ☜ root 권한에서 빠져나옴
$ exit       ☜ 쉘프롬프트에서 오라클 프롬프트로 복귀
 
SQL> startup   ☜ Instance 기동
ORACLE instance started.
 
Total System Global Area  289406976 bytes
Fixed Size                   778796 bytes
Variable Size              99360212 bytes
Database Buffers          188743680 bytes
Redo Buffers                 524288 bytes
Database mounted.
Database opened.
SQL> 

자동으로 오프라인 백업실행하기
오프라인 백업은 데이터 파일의 크기가 작은 경우 쉽고, 간단하게 실행할 수 있지만, 데이터 파일이 큰 경우는 많은 시간이 소요되므로 스크립트를 사용하여 운영체제의 스케듈러에 의해 백업이 자동으로 실행되도록 할 수 있다.
다음과 같이 오프라인 자동 백업 스크립트를 작성하여 실행한다.

1단계 : 오라클 인스턴스 종료
 $ORACLE_HOME/bin/sqlplus system/manager as sysdba
 SHUTDOWN IMMEDIATE
 EXIT

2단계 : 데이터베이스와 관련된 모든 물리적 파일 복사
 cp /export/home/oracle/app/oracle/oradata/orcl/*.ctl backup/
 cp /export/home/oracle/app/oracle/oradata/orcl/*.dbf backup/
 cp /export/home/oracle/app/oracle/oradata/orcl/*.log backup/
 cp /export/home/oracle/app/oracle/oradata/orcl/*.ora backup/

3단계 : 데이터베이스 다시 시작
 $ORACLE_HOME/bin/sqlplus system/manager as sysdba
 STARTUP
  EXIT
 EOF

온라인 백업
오프라인 백업이 DB가 종료한 상태에서 백업하는 것에 반해, 온라인 백업은 DB를 운영하는 도중에 백업을 실행하는 방법이다. 온라인 백업은 테이블스페이스 단위로 백업을 수행하며 ALTER TABLESPACE 명령으로 테이블스페이스를 백업모드로 설정하고, 데이터 파일을 운영체제에 복사한다.
온라인 백업을 hot backup 또는 open backup이라 한다. 온라인 백업은 오프라인 백업과 달리 모든 파일을 백업할 수 없고, 필요한 테이블스페이스만 백업할 수 있다.
$ sqlplus '/as sysdba'
SQL> select tablespace_name, file_name from dba_data_files;
 
TABLESPACE_NAME FILE_NAME
--------------- ------------------------------------------------------------
USERS           /export/home/oracle/app/oracle/oradata/orcl/users01.dbf
SYSAUX          /export/home/oracle/app/oracle/oradata/orcl/sysaux01.dbf
UNDOTBS1        /export/home/oracle/app/oracle/oradata/orcl/undotbs01.dbf
SYSTEM          /export/home/oracle/app/oracle/oradata/orcl/system01.dbf
 
SQL> alter tablespace users begin backup; 
☜ 테이블스페이스내의 모든 객체에 대해 변경된 데이터들이 데이터 파일에 적용되고, 메모리 영역과 리두 로그 파일에 일시적으로 저장된다.
 
Tablespace altered.
 
SQL> !
$ cp /export/home/oracle/app/oracle/oradata/orcl/users01.dbf bkup/.
$ ls -l bkup
total 10272
-rw-r-----   1 oracle   oinstall 5251072 Jan  4 14:07 users01.dbf
$ exit
 
SQL> alter tablespace users end backup;  
☜ 복사후 sql문을 실행하여 데이터파일에 저장되었던 변경된 데이터를 실제 데이터 파일에 반영한다.
 
Tablespace altered.
 
SQL> 
SQL> ALTER SYSTEM SWITCH LOGFILE;
    ☜ 인위적으로 로그 스위치를 실행하여 모든 데이터 파일 헤더에 저장되어 있는 체크포인트 번호를 통합
 
System altered.
 
SQL>

논리적 백업

논리적 백업은 DB내의 논리적 객체들을 백업하는 방법으로, EXPORT 유틸리티를 사용하여 백업하고, IMPORT 유틸리티를 사용하여 복구한다.
EXPORT와 IMPORT 유틸리티가 백업/복구 이외에 다른 기능은 다음과 같다.

• 특정 사용자의 객체를 다른 사용자의 공간으로 이동시킬 수 있다.
• 운영체제가 다른 DB 사이에 데이터를 이동시킬 수 있다.
• 테이블, 뷰,인덱스 등을 백업하고 다시 복구함으로써 객체들의 구조가 재생성되어
   단편화(fragmentation)를 감소시킨다.
익스포트에서 사용 가능한 키워드는 EXP 유틸리티를 참조하고
또한 익스포트를 사용하여 논리적으로 DB를 백업하는 방법은 데이터 베이스 전체모드, 테이블스페이스 모드, 사용자모드, 테이블모드의 4 종류가 있다.

데이터베이스 전체모드 테이블스페이스 모드 사용자 모드 테이블 모드
•모든 테이블의 데이터
•인덱스
•테이블의 제약조건
•트리거
•클러스트
•시퀀스
•스냅샷
•스토어드 프로시저
•시노늄
•뷰
•프로파일/롤
•audit
•지정된 테이블스페이스의 테이블
•테이블의 데이터
•인덱스
•테이블의 제약조건
•트리거
•클러스트
•시퀀스
•스냅샷
•스토어드 프로시저
•시노늄
•뷰
•프로파일/롤
•audit
•정의된 사용자의 테이블
•테이블의 데이터
•사용자의 권한
•사용자의 인덱스
•테이블의 제약조건
•테이블의 트리거
•클러스트
•데이터베이스 링크
•스냅샷
•스토어드 프로시저
•시노늄
•뷰
•정의된 사용자의 테이블
•테이블의 데이터
•사용자의 권한
•사용자의 인덱스
•테이블의 제약조건
•트리거


전체백업과 부분백업


전체백업
모든 데이터 파일과 컨트롤 파일을 백업하는 방식으로, 가장 보편적인 방법이다. 전체 백업은 데이터베이스 모드에 관계없이 가능하지만, 아카이브 모드인 경우와 노아카이브 모드인 경우 전체 백업을 수행했을 때의 차이가 있다.
데이터베이스 전체에 대한 백업은 다음과 같은 방법으로 가능하다.
 • 컨트롤 파일 뿐만 아니라 모든 데이터 파일을 복사하는 운영체제가 제공하는 유틸리티
        • RMAN BACKUP DATABASE 명령어
        • 데이터베이스 내의 각 데이터 파일에 대해 수행되는 RMAN COPY DATAFILE 명령어와
  컨트롤 파일에 대해 실행되는 COPY CURRENT CONTROLFILE 명령어

부분백업
전체 데이터베이스를 백업하는 대신 테이블스페이스나 컨트롤 파일과 같이 일부분만을 백업하는 방법이다. 부분 백업은 아카이브 모드에서만 가능하므로, 현재 DB가 아카이브 모드인지 확인해야 한다. 부분 백업에는 테이블스페이스 백업, 데이터 파일 백업, 컨트롤 파일 백업, 아카이브 리두 로그 파일 백업이 있다.
데이터 파일의 백업 상태는 v$backup 뷰로 확인이 가능하다.
 SQL> select log_mode from v$database; ☜ 현제 DB의 아카이브 모드 확인
 SQL> alter database archivelog;  ☜ DB의 모드를 아카이브모드로 전환

테이블스페이스 백업/ 데이터 파일 백업

1) 온라인 테이블스페이스 백업하기
테이블스페이스 백업은 테이블스페이스를 구성하는 데이터 파일을 백업하는 것으로, DB가 아카이브모드라면, 온라인 또는 오프라인 상태에서도 가능하다.

SQL> select tablespace_name, file_name from dba_data_files;
 
TABLESPACE_NAME FILE_NAME
--------------- ------------------------------------------------------------
USERS           /export/home/oracle/app/oracle/oradata/orcl/users01.dbf
SYSAUX          /export/home/oracle/app/oracle/oradata/orcl/sysaux01.dbf
UNDOTBS1        /export/home/oracle/app/oracle/oradata/orcl/undotbs01.dbf
SYSTEM          /export/home/oracle/app/oracle/oradata/orcl/system01.dbf
 
SQL> alter tablespace users begin backup; ☜ users 테이블스페이스에 대해 백업 시작을 알림
 
Tablespace altered.
 
SQL> ! 
$ cp /export/home/oracle/app/oracle/oradata/orcl/users01.dbf bkup/.
$ exit
 
SQL> alter tablespace users end backup;  ☜ users 테이블스페이스에 대해 백업 종료를 알림
 
Tablespace altered.
 
SQL> select * from v$backup;
 
     FILE# STATUS                CHANGE# TIME
---------- ------------------ ---------- ------------
         1 NOT ACTIVE                  0
         2 NOT ACTIVE                  0
         3 NOT ACTIVE                  0
         4 NOT ACTIVE            2858563 04-JAN-06
 
SQL>
2) 오프라인 테이블스페이스 백업하기
사용중인 테이블스페이스를 오프라인시켜 백업할 수 있다. 그러나 SYSTEM 테이블스페이스와 현재 사용중인 롤백 세그먼트는 오프라인 시킬 수 없다는 것을 의미한다.
SQL> select tablespace_name, file_name from dba_data_files;
 
TABLESPACE_NAME FILE_NAME
--------------- ------------------------------------------------------------
USERS           /export/home/oracle/app/oracle/oradata/orcl/users01.dbf
SYSAUX          /export/home/oracle/app/oracle/oradata/orcl/sysaux01.dbf
UNDOTBS1        /export/home/oracle/app/oracle/oradata/orcl/undotbs01.dbf
SYSTEM          /export/home/oracle/app/oracle/oradata/orcl/system01.dbf
 
SQL> alter tablespace users offline normal;
 
Tablespace altered.
 
SQL> !
$ cp /export/home/oracle/app/oracle/oradata/orcl/users01.dbf bkup/.
$ exit
 
SQL> alter tablespace users online;
 
Tablespace altered.
 
SQL>

컨트롤 파일 백업
오라클 DB를 설치하면 CREATE DATABASE 문에 의해 기본적으로 생성되는 파일들이 있는데, 리두 로그 파일, SYSTEM 데이터 파일, UNDO 데이터 파일, TEMP 데이터 파일등의 경로와 파일명을 설정한다. 정상적으로 실행되면 컨트롤 파일이 생성된다
자동으로 생성된는 컨트롤 파일에는 CREATE DATABASE 문에 의해 정의된 파일의 모든 정보가 기록된다. DB가 MOUNT 단계가 되면 컨트롤 파일의 정보를 읽어 DB의 모든 상태를 점검한다. 이때 컨트롤 파일을 읽을 수 없으면 DB를 사용할 수 없다. 따라서 컨트롤 파일을 잘 관리해야 한다. DB를 설치하면 기본적으로 3개의 컨트롤 파일이 생성되는데 첫 번째 파일이 원본 컨트롤 파일고, 나머지 두 개의 파일은 원본에 대한 미러링(mirroring) 파일로 원본 컨트롤 파일에 문제가 발생하면 미러링 파일로 복구할 수 있다.
현재 DB에서 사용하고 있는 컨트롤 파일의 위치와 이름은 v$controlfile 뷰를 참조하여 확인할 수 있다.
SQL> select * from v$controlfile;
 
STATUS  NAME                                                         IS_
------- ------------------------------------------------------------ ---
        /export/home/oracle/app/oracle/oradata/orcl/control01.ctl    NO
        /export/home/oracle/app/oracle/oradata/orcl/control02.ctl    NO
        /export/home/oracle/app/oracle/oradata/orcl/control03.ctl    NO
 
SQL> 
컨트롤 파일을 백업하는 세가지 방법
방법1) 컨트롤 파일 백업
SQL> shutdown
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> !
$ cp /export/home/oracle/app/oracle/oradata/orcl/*.ctl bkup/.
$
$ ls dbs/*.ora
dbs/init.ora        dbs/initdw.ora      dbs/spfileorcl.ora
initDB명.ore 파일에 복사된 컨트롤 파일을 추가 한다.
 ...
 CONTROL_FILES=(control01.ctl,..,control04.ctl)
 ...
$ exit
 
SQL> startup
ORACLE instance started.
 
Total System Global Area  289406976 bytes
Fixed Size                   778796 bytes
Variable Size              99360212 bytes
Database Buffers          188743680 bytes
Redo Buffers                 524288 bytes
Database mounted.
Database opened.
SQL>
방법2) spfile을 사용한 컨트롤 파일 백업
SQL> ALTER SYSTEM SET control_files=
   '/export/home/oracle/app/oracle/oradata/orcl/control01.ctl',
   '/export/home/oracle/app/oracle/oradata/orcl/control02.ctl',
   '/export/home/oracle/app/oracle/oradata/orcl/control03.ctl', SCOPE=SPFILE;
SQL> SHUTDOWN
SQL> !
# cp control01.ctl control04.ctl
# exit
SQL> STARTUP
방법3) ALTER DATABASE 명령을 사용한 방법

 ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
alter database 명령을 실행하여 컨트롤 파일을 백업하면 생성된 복사본은 바이너리 파일로 생성되는 대신 텍스트 형식으로 백업 파일을 저장한다. 만일 원본 컨트롤 파일과 복사본 컨트롤 파일 모두를 사용할 수 없다면, 이 파일을 사용하여 모든 컨트롤 파일을 재생성할 수 있다.
백업된 파일은 initDB명.ora 파일의 user_dump_dest 매개변수가 지정하는 경로에 *.trc 확장자로 생성된다. 
이렇게 백업된 *.trc 콘트럴 파일로부터 컨트롤 파일을 다시 복구하는 방법은 이곳에 있음 
다음과 같은 경우 alter database 명령문을 실행하여 컨트롤 파일에 대한 trc 파일을 생성하는 것이 좋다.
• ALTER DATABASE 명령어에 의해 db의 구조가 변경될 때
• CREATE TABLESACE 명령어에 의해 테이블스페이스가 추가 되거나 변경될 때
• DROP TABLESPACE 명령어를 사용하여 테이블스페이스가 삭제될 때
SQL> alter database backup controlfile to trace;
 
Database altered.
 
SQL> show parameter user_dump_dest;
 
NAME              TYPE        VALUE
----------------- ----------- ------------------------------------------------
user_dump_dest    string      /export/home/oracle/app/oracle/admin/orcl/udump
SQL>

 

Posted by redkite
, |

효율적인 백업 및 복구

http://dinggur.tistory.com/category/Study




Export / Import
1. 특정테이블만 백업받고 싶다.
2. 특정 테이블만 옮기고 싶을때.
3. 구DB(윈도8i) → 신규DB(리눅스11g) 로 DATA 옮기고 싶을때

Migration(마이그레이션) : 데이터 옮기기
방법 1 : exp/imp
방법 2 : data pump


원리는 select와 같다 = DB open상태에서 실행한다.


Export 원리
: 서버에 있는 데이터를 빼올때.
: 시작시점의 데이터만 들어간다.
: sys계정은 exp 안된다 → system 사용자
temporary tablespace 공간 사용(관리법 잘알기)



① Conventional Path export
- 여러사람이 같이 쓸때
- evaluation buffer 사용

② Direct Path export
- 혼자 쓸때
- 단점 : 원본 테이블에 여러 process 가 동시에 접근을 해서 사용할 경우 속도 저하가 심해진다.


DB는 여러 사람이 동시에 사용하는 것이기 때문에, 기본적으로 conventional path 모드로 작동하게 되어있다.
conventional path 모드의 기본적인 속도는 과정이 다소 복잡하기 때문에 direct path에 비해 속도가 저하된다.

EXP 단점 : 속도가 느리다.
주의 : 편집하면 파일깨짐. EXP 처음부터 다시해야함.


Export 옵션

옵 션 명

Default value

의 미

userid

없음

export 를 수행하는 사용자의 계정과 암호

buffer

os에 따라 다름

evaluation buffer 크기를 바이트 단위로 지정

file

expdat.dmp

export 결과르 저장할 파일명

grants

yes

해당 스키마에 설정된 권한을 export 받을 것인가 유무

indexes

yes

인덱스를 export 받을 것인가 유무

rows

yes

데이터를 받을 것인가 유무

constraints

yes

제약 조건을 받을 것인가 유무

compress

yes

export 받을 때 데이터를 하나의 셋으로 압축 할지 유무

full

no

전체 데이터베이스를 export 받을 것인가 유무

owner

current user

export 받을 사용자 이름을 지정

tables

없음

export 받을 테이블 이름 지정

tablespaces

없음

export 받을 테이블 스페이스 이름 지정

recordlength

os 에 따라 다름

파일레코드의 바이트 단위 길이. evaluation buffer에서 데이터 파일로 저장할 때 운반바이트 단위 지정

inctype

없음

증분 export 의 유형설정, complete, cumulative, incremental

record

yes

증분 export 내용을 기록할지 지정, .sys.incvid, sys.incexp

parfile

없음

export 파라미터 파일을 지정

 

=칠판실습=

$ exp scott/tiger tables=emp file=emp.dmp

$ vi emp.dmp
바이너리파일
IMP에게 수행할 명령 쭉~ 적혀있음..
(수행할 SQL명령어들이 순서대로 들어있다)
- 내부순서 : create table → insert → create index → add constraints

EXP/IMP 계정이 동일해야 한다 : IMP때 아이디/암호는 EXP할때 아이디/암호 와같아야 한다.
- 예외 : system 계정으로 작업시 상관없다.

ex) 다른사람이 받아놓은 exp를 imp받아야 하는 경우. (계정을 모를때)
→ VI로 dmp파일 열어보면 2째줄 U뒤에 아이디 적혀있음

 



Export
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 실습 시작
exp 실습 1: conventional Path로 full export 받기

$ time exp system/oracle full=y log=full_log.log file=/home/oracle/full_test01.dmp


exp 실습 2: direct Path로 full export 받기

$ time exp system/oracle full=y log=full_log.log file=/home/oracle/full_test01.dmp direct=y


exp 실습 3: exp 를 저장하는 백업파일 분할해서 받기

$ time exp system/oracle full=y \
file=(/data/backup/export/test03_1.dmp,\
/data/backup/export/test03_2.dmp,\
/data/backup/export/test03_3.dmp,\
/data/backup/export/test03_4.dmp)\
filesize=20M direct=y


exp 실습 4: 특정 테이블스페이스만 받기

$ exp system/oracle file=/data/backup/export/ex_un.dmp \
tablespaces=(example, undotbs1)


exp 실습 5: 여러 사용자를 동시에 백업 받기

$ exp system/oracle file=/data/backup/export/scott_hr.dmp \
owner=(scott,hr)


exp 실습 6: evaluation Buffer 값을 조정하면서 export 수행

-----------
실습용 테이블 생성
SQL> create table scott.test01
2 (no number, name varchar2(20), address varchar2(50)) tablespace example;

테이블 스페이스 용량 충분히 늘려주고 대량의 데이터 입력시키기
SQL> begin
2 for i in 1..1000000 loop
3 insert into scott.test01
4 values (i, dbms_random.string('A',19),
5 dbms_random.string('Q',40) );
6 end loop;
7 commit;
8 end;
9 /

생성후 확인
SQL> select sum(bytes)/1024/1024 MB
2 from dba_segments
3 where owner='SCOTT'
4 and segment_name='TEST01';
--------------

① evaluation Buffer 값을 설정하지 않고 export 수행

$ time exp scott/tiger file=/data/backup/export/test02.dmp tables=test01

real 0m12.340s


② evaluation Buffer 값을 1M 로 설정후 export 수행

$ time exp scott/tiger file=/data/backup/export/test03.dmp buffer=1024000 tables=test01

real 0m6.156s


③ evaluation Buffer 값을 10M 로 설정후 export 수행

$ time exp scott/tiger file=/data/backup/export/test04.dmp buffer=10240000 tables=test01

real 0m2.919s


④ evaluation Buffer 값을 20M 로 설정후 export 수행

$ time exp scott/tiger file=/data/backup/export/test05.dmp buffer=20480000 tables=test01

real 0m3.267s


⑤ direct Path 로 export 수행

$ time exp scott/tiger file=/data/backup/export/test06.dmp direct=y tables=test01

real 0m7.150s

정리 : evaluation Buffer의 크기 / temporary tablespc의 크기 = exp/imp 속도에 영향을 준다.







exp 실습 7: 일반사용자(여기서는 scott)로 full export 수행

SYS> select * from dba_role_privs where grantee='SCOTT';
SYS> grant exp_full_database to scott;
설명 : 원래 일반 사용자는 DB전체백업을 받지 못한다. 그래서 DBA권한을 주거나 exp_full_database 라는 role을 주던지 해야 함.

$ time exp scott/tiger full=y file=/data/backup/export/test7.dmp buffer=10240000



exp 실습 8: parameter file 을 이용한 export 수행

$ vi par_full.dat
file=/data/backup/export/test09.dmp
full=y
direct=y
:wq!

$ exp system/oracle parfile=par_full.dat



exp 실습 9: 특정 조건만 export 받기 - query 옵션 사용(8i부터 가능)
OS에서 사용하는 특수문자 ' " < > 등을 쿼리로 사용할 경우 앞에 \(escape문자)를 붙여서 구분해 주어야 한다.

- emp 테이블에서 이름 첫 글자가 F인 사람만 export 받기
$ exp scott/tiger query=\"where ename like \'F%\'\" tables=emp file=/data/backup/export/emp.dmp

- emp 테이블에서 job이 CLERK 이고 급여가 1000인 사람만 export 받기
$ exp scott/tiger query=\"where job=\'CLERK\' and sal \> 1000 \" file=/data/backup/export/scott2.dmp tables=emp

- parameter file 에서 query 옵션 사용하기 - escape 문자(\) 안써도 됨
$ vi par_q.dat
tables=emp query="where job='CLERK' and sal>1000"
:wq!

$ exp scott/tiger parfile=par_q.dat



exp 실습 10: schema 별로 자동 export 백업 받는 스크립트

$ vi exp_script.sh
export LANG=C
export ORACLE_BASE=/home/oracle
export ORACLE_HOME=$ORACLE_BASE/product/10g
export PATH=$ORACLE_HOME/bin:$PATH
export ORACLE_SID=testdb
sqlplus /nolog << EOF3
conn / as sysdba
set head off
set time off
set timing off
set feedback off
set echo off
set line 200
col name for a100
spool /home/oracle/exp.tmp
select 'mkdir -p /data/backup/exp/'||to_char(sysdate,'YYYY-MM-DD-HH24-MI-SS') from dual;
select distinct 'exp system/oracle'||' owner='||lower(owner)||' file=/data/backup/exp/'||to_char(sysdate,'YYYY-MM-DD-HH24-MI-SS')||'/'||lower(owner)||'.dmp'||' filesize=100m direct=y' from dba_tables where owner not in('SYS','DBSNMP','WMSYS','IX','SYSTEM','OE','PM','EXFSYS','CTXSYS','OLAPSYS','MDSYS','SYSMAN','LOADER','XDB','ORDSYS',
'OUTLN','TSMSYS','DMSYS');
spool off

!cat /home/oracle/exp.tmp | egrep -v SQL | egrep -v SYS > /home/oracle/exp.sh
!sh /home/oracle/exp.sh
exit

EOF3




=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 실습 끝






Import
: export 를 수행해서 만든 파일을 다시 데이터베이스로 넣는 작업을 수행
: 대량의 DDL과 DML을 수행하는 것이므로, redo log와 undo segment를 사용 → 대량의 데이터 import시 큰 undo tablespace를 준비
만약 용량이 부족할 경우 마지막에 에러 나면서 전부 rollback 될수도 있다.
이런 위험 줄이려면 import할때 commit=y로 변경하면 된다. 기본값은 테이블전체가 입력완료된후 커밋되는데
이 옵션을 사용하면 array단위로 커밋수행.
: 만약 DBA로(system) export 받은 파일의 경우, DBA로(system) import 해야 한다.
일반 사용자(Ex. scott)로 import 시도하면 에러발생.


IMP 특징
- imp할때마다 자료는 추가됨.
- 중간에 에러나서 자료 입력이 다 안되었을때, 다시 imp하면 에러전까지 입력된 자료 남겨두고, 새로 또 입력됨.
에러나서 다시 imp해야 할 경우 에러 전까지 입력된 데이터 truncate나 drop으로 날리고 다시작업해야 데이터 중복없음.



Import 주요옵션

ignore : Import 도중 에러나도 무시하고 계속 진행함.
fromuser : export 할 당시 원래 주인 user
touser : import 할때 새로 지정해줄 주인 user

 

옵 션 명

Default value

설 명

userid

없음

import 를 수행하는 username / password

buffer

os 에 따라 다름

evaluation buffe 의 크기, export와 동일함

file

expdat.dmp

import 할 export 파일 명

show

no

데이터를 import 하지 않고 내용만 확인함

ignore

yes

import 도중 에러나도 무시하고 계속 진행함

grants

yes

권한도 import 할 것인지 설정

rows

yes

데이터를 import 할 것인지 설정

indexes

yes

index를 import 할 것인지 설정

full

no

전체 파일을 import 할 것인지 설정

fromuser

없음

export 할 당시 오브젝트의 소유자를 지정함

touser

없음

import 할 오브젝트의 새 owner 이름

tables

없음

import 할 테이블 목록

recordhength

os 별로 다름

한번에 import 할 record의 길이를 지정

inctype

없음

증분 import의 유형 지정, system 과 restore 가 적당함

commit

no

각 array의 입력 후 commit 할것인가 결정, 디폴트는 array가 아니라 테이블 전체가 입력 완료 된 후 커밋을 함. Array는 한번 입력되는 단위를 의미함

parfile

없음

import 의 파라미터를 적어둔 파라미터 파일을 지정함






Import
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 실습 시작
사전작업
$ exp system/oracle file=/data/backup/export/full01.dmp full=y dirct=y



imp 실습 1: DBA로 전체 데이터 import 수행
: DB전체를 이동할 때 사용. A서버의 데이터를 B서버로 import로 이동시킬때 B서버에 같은 테이블이나 데이터가 존재한다면 추가를 하게 된다.
그래서 만약 B서버에 제약조건이나 index가 존재한다면(unique index 나 primary key 등이 존재할 경우) 데이터가 추가되지 않고 에러가 발생한다.

$ imp system/oracle file=/data/backup/export/full01.dmp ignore=y full=y



imp 실습 2: 특정 사용자의 데이터만 import 수행
: 전체 export받은 full01.dmp 파일에서 scott 사용자의 test01테이블만 import하기

$ imp system/oracle file=/data/backup/export/full01.dmp fromuser=scott tables=test01 ignore=y




imp 실습 3: scott 사용자의 test02 테이블을 hr 사용자 소유로 변경하기
--------------------------------
테스트 테이블 생성

SCOTT> create table test02 (no number,addr varchar2(10));

SCOTT> begin
2 for i in 1..1000 loop
3 insert into test02 values (i, dbms_random.string('A',10));
4 end loop;
5 commit;
6 end;
7 /

SCOTT> select count(*) from test02;
COUNT(*)
--------
1000

$ exp scott/tiger file=/data/backup/export/test02.dmp tables=test02
--------------------------------

$ imp system/oracle file=/data/backup/export/test02.dmp fromuser=scott touser=hr ignore=y



imp 실습 4: 실제 데이터는 import 하지 않고 DDL 문장만 추출하기

$ imp system/oracle file=/data/backup/export/test02.dmp full=y show=y log=test02.log
$ vi test02.log



imp 실습 5: import 할 때 테이블과 index를 분리해내기

테이블과 인덱스는 다른 테이블스페이스에 저장해야 성능이 좋아진다.
exp/imp할때 같은 테이블스페이스에 있던 테이블과 인덱스를 다른 테이블 스페이스로 분리하려고 할때.

① 인덱스 스크립트가 있다면.
import 할때 indexes=n 옵션주고 import 한후 나중에 인덱스 스크립트에서 테이블스페이스만 변경하고 실행

② 인덱스 스크립트가 없다면.
import 할때 indexfile=파일이름 옵션주고 새로 생성되는 스크립트 수정(테이블스페이스)해서 실행

SCOTT> create index idx_test02_addr on test02(addr); ← 테이블스페이스 따로 지정 안해줘서 테이블과 같은 장소에 생성됨

$ exp scott/tiger file=/data/backup/export/test02_index.dmp tables=test02

$ imp system/oracle file=/data/backup/export/test02_index.dmp indexfile=test02_index.sql full=y

$ vi test02_index.sql
열어서 tablespace 부분 수정해주고 스크립트 실행


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 실습 끝




추가 사항

1. export 시
: buffer = evaluation buffer 크기 결정하는 파라미터
: recordlength = bufer의 내용을 OS파일로 내려쓸 때 사용하는 레코드의 크기를 결정하는 파라미터
→ 두 파라미터의 크기는 OS 블록의배수로 설정하기
: Array fetch → DB Buffer cache의 내용을 evaluation buffer 로 가져올때 한건씩 가져오는 것이 아니라 여러건의 데이터를 한꺼번에 가지고 옴

2. feedback=정수값
: 큰 데이터 exp/imp 할때 진행과정 보여주는 옵션

3. import 시 core dump/segmentation fault 에러 발생
: export 받은 DB와 import 하는 DB의 케릭터 셋이 다를 경우 발생
: 케릭터 셋을 일치시킨후 export 받는것이 정석
→ 이미 받아버린 덤프파일이라면 convert 프로그램을 이용하여 import 하는 곳의 케릭터 셋과 변경후 import 수행

현재 캐릭터 셋 확인 SQL
SQL> select value from nls_database_parameters where parameter='NLS_CHARACTERSET';


4. Array Fetch : export시 DB Buffer cache의 내용을 한문장씩 evaluation buffer 로 가져오면 I/O 하는 회수가 많아져 느려진다.
evaluation buffer에 일정량의 데이터가 쌓이게 되면 한꺼번에 파일에 내려써 I/O 하는 회수를 줄여 속도를 높이는 방법.
Array insert : import시 1row씩 insert 하게되면 비효율적. 여러 건의 데이터를 한꺼번에 insert 하여 효율을 높인다.


5. import 시 "ABNORMAL END OF FILE" 에러 : export 받은 파일에 문제가있다. 다시 export 받아야 함.

6. sys 계정은 dictionary 객체들을 소유한다. 새로운 데이터베이스는 이미 고유의 dictionary를 가지고 있다.
sys 계정의 객체를 export/import 하는것은 아주 큰 위험 부담이 있고 부하도 많이 걸리는 작업이라
sys 계정은 export 를 수행할 수 없도록 되어 있다.

7. A소유의 테이블에 B가 인덱스 만들었다면, DBA권한으로 exp받을때 B의 인덱스도 함께 export 받을 수 있다.

8. Exp는 select와 동일한 원리 이므로 offline 이나 shutdown 상태에서는 사용할 수 없다.

9. exp시 tablespaces 옵션을 주었다 하더라도,
imp시 tablespace를 생성하고 table 을 만드는 것이 아니다.
imp 하길 원하는 서버에 tablespace 를 먼저 만들어 두고 imp를 해야 한다.

10. DB1 - scott 의 디폴트테이블스페이스 USERS
DB2 - scott 의 디폴트테이블스페이스 EXAMPLE. USERS 존재.
인상황에서 DB1 exp 받아서 DB2 imp 한다면 해당테이블은 어느 테이블 스페이스로 들어갈까?
DB1에서 지정되어있던 USERS 테이블스페이스로 들어간다.

11. DB1 - scott 의 디폴트테이블스페이스 TS_B
DB2 - scott 의 디폴트테이블스페이스 EXAMPLE. TS_B는 존재하지 않음.
인상황에서 DB1 exp 받아서 DB2 imp 한다면 해당테이블은 어느 테이블 스페이스로 들어갈까?
imp는 정상적으로 된다. 하지만 테이블스페이스는 DB2의 디폴트테이블스페이스인 EXAMPLE에 들어간다.

 

마이그레이션 기본방법
AS-IS서버(현재서버)와 TO-BE서버(이전할서버)의
① 사용자 계정과 각 사용자의 default tablespace를 동일하게 설정
② Privilege와 role을 동일하게 설정
③ schema 별로 exp 를 수행해서 imp를 수행
→ AS-IS 서버에 schema가 많을 경우 수동으로 하나하나 조사해서 받기 어렵기 때문에,
위의 실습 10번 스크립트를 활용하여 schema 별로 자동으로 export 받을 수 있는 스크립트 활용

 

CLOB의 경우

char → varchar2 → CLOB
2000 4000 2기가이상데이터

LOB : 하나의 컬럼에 크기가 큰 데이터
L arge
OB ject

 

CLOB : 글자로 구성
Character
L arge
OB ject



BLOB
Binary
L arge
OB ject



ex)
대본 tabale → users 테이블스페이스에 존재
--------------------
code 드라마명 대본
--------------------
....

대본 컬럼이 너무 커서 CLOB의 경우 컬럼하나만 별도의 테이블스페이스 지정해준다.
export 후 import 할경우 해당 테이블스페이스가 없으면 에러남 → 미리 생성해주기


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 실습 시작
1. CLOB 컬럼을 포함한 테스트 테이블 생성
SQL> create tablespace ts_lob
2 datafile '~/ts_lob01.dbf' size 1M

SQL> create table scott.clobtest
2 (no number, name varchar2(10), contents clob)
3 lob(contents) store as (tablespace ts_log);

SQL> insert into scott.clobtest
2 values (1,'AAA','BBBBB');


2. 현재 LOB 목록 확인
col owner for a10
col table_name for a10
col column_name for a10
col segment_name for a30
col tablespace_name for a10
SQL> select owner, table_name, column_name, segment_name, tablespace_name
2 from dba_lobs
3 where table_name='CLOBTEST'


3. Export
$ exp scott/tiger table=cobtest file=clobtest.dmp

4. Import
해당 테이블스페이스 없으면 에러발생함
해당 테이블스페이스 생성후 import 해주기

SQL> create tablespace ts_lob
2 datafile '~/ts_lob01.dbf' size 1M

$ imp scott/tiger file=clobtest.dmp fromuser=scott ignore=y

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 실습 끝

Posted by redkite
, |

아카이브 복구

 

아래의 방법으로 하시면 됩니다.

- 현재 운영DB를 S, 복구대상 DB를 T라 하겠습니다.

1. S에서 Online Backup실행

$cd /data/work

$ sqlplus / as sysdba

SQL> @begin

SQL> alter database backup controlfile to '/data/oradata/emsdb/control.bak' reuse;

2. S의 DBF File Ftp

$ cd /data/oradata/emsdb

$ ftp 10.100.100.4

ftp > cd /data/oradata/emsdb

ftp > bin

ftp > prompt

ftp> hash

ftp > mput *

 

3. S에서 Online Backup종료 실행

$cd /data/work

$ sqlplus / as sysdba

SQL> @end

 

4. S의 DBF File Ftp

$ cd /data/oradata/emsdb

$ ftp 10.100.100.4

ftp > cd /data/oradata/emsdb

ftp > bin

ftp > prompt

ftp> hash

ftp > mput *

 

5. T에서 Backup받은 controlfile으로 변경

$ cd /data/oradata/emsdb

$ cp control.bak control01.ctl

$ cp control.bak control02.ctl

$ cp control.bak control03.ctl

 

6 T에서 복구 시작

$sqlplus / as sysdba

SQL> startup mount

SQL> recover database using backup controlfile until cancel;

auto

-> Archivelog을 이용 복구 진행후 더이상 복구할 Archive log가 없을때 종료

SQL.> alter database open resetlogs;

-> Open이 되지 않고 Error가 발생하는데 이유는 S는 10.2,0.3이고 T는 10.2.0.5라 Dictionary가 상이하여 발생

SQL> exit

 

7. T에서 Upgrade실행

$ sqlplus / as sysdba

SQL> startup upgrade

SQL> spool upgrade

SQL> @?/rdbms/admin/catupgrd

SQL> shutdown immediate

 

8. T에서 Invalid된 Object 재 Compile

$sqlplus / as sysdba

SQL> startup

SQL> @?/rdbms/admin/utlrp

Posted by redkite
, |

아카이브 모드 설정

오라클 아카이브 모드 설정하기(spfile, 10g 기준)

 


1. 운영 중인 오라클의 로그 모드를 확인 한다.

SQL> archive log list;
데이터베이스 로그 모드 아카이브 모드가 아님
자동 아카이브 사용 안함
아카이브 대상 USE_DB_RECOVERY_FILE_DEST
가장 오래된 온라인 로그 순서 54
현재 로그 순서 56

2. 관리자 계정으로 splplus 접속

SQL> alter system set log_archive_start=true scope=spfile;

SQL> alter system set log_archive_dest='원하는 경로' scope=spfile;

SQL> alter system set log_archive_format='%t_%s_%r.arc' scope=spfile;

log_archive_format의 옵션

%S : redo 로그 시퀀스 번호를 표시하여 자동으로 왼쪽이 0으로 채워져 파일 이름 길이를 일정하게 만든다.

%s : redo 로그 시퀀스 번호를 표시하지만 파일 이름 길이를 일정하게 맞추지는 않는다.

%T : redo 스레드 넘버를 표시하며, 자동으로 왼쪽이 0으로 채워져 파일 이름 길이를 일정하게 만든다.

%t : redo 스레드 넘버를 표시하며, 파일 이름 길이를 일정하게 맞추지 않는다.


3. 데이터 베이스를 종료(normal, immediate, transactional)한 후에 재시작, 변경

sql>shutdown immediate;

sql>startup mount;

sql>alter database archivelog;

sql>alter database open;

4. 확인과정

SQL> archive log list;

SQL> alter system switch logfile; --설정한 경로에 파일이 생성되는지 확인해본다.

5. Noarchive mode로 전환하기

관리자 계정으로 접속

sql>shutdown immediate;

sql>startup mount;

sql>alter database noarchivelog;

sql>alter database open;

Posted by redkite
, |

아카이브 모드 변경

# NO 아카이브 모드로 변경
ALTER SYSTEM SET LOG_ARCHIVE_START = FALSE SCOPE=SPFILE;
alter database mount
alter database noarchivelog;
archive log list
alter database open;

# 아카이브 모드로 변경
select name, value from v$parameter
where name = 'log_archive_start'
or name = 'log_archive_dest'
or name = 'log_archive_format' ;

ALTER SYSTEM SET LOG_ARCHIVE_START = TRUE SCOPE=SPFILE;
archive log list
startup mount
alter database archivelog;
archive log list
alter database open;

Oracle에서 Online Backup을 받거나 완벽한 Recovery 작업을 수행하기
위해서는 DB를 Archive log mode로 운영하여야 한다.

Archive log mod 란?

우리가 오라클데이터베이스에 접속을해서 DML이나 DDL등의 명령어로 작업을 수행하면,
모든 작업의 기록이 리두로그파일에 저장이 된다.

작업의 양이 많아지면 리두로그파일에 기록하는 내용도 굉장히 많아지게 되고
그렇게 되면 데이터를 기록하기 위해서 리두로그파일을 늘려야 하는 일이 발생을 한다.

그런데 오라클 리두로그파일은 계속 증가하는것이 아니라 몇개의 리두로그파일을 만들어 놓고
번갈아 가면서 기록하는 구조로 되어 있다.(리두로그파일은 2개 이상있어야 한다.)

이렇게 번갈아 가면서 기록을 하게 되면 새로운작업의 내용이 예전의 작업내용을 덮어쓰므로
예전의 작업한 내용을 잃게 된다는 단점이 있다.

그래서 예전의 작업한 내용에 데이터 손실이 발생하면 복구하기 어렵다는 단점이 있다.

이런 단점을 해결하기 위한 방법이 리두로그파일의 내용을 다른 디렉토리에 자동으로 복사해서 저장하도록
운영하는 방법이다. 이렇게 운영하는 방법을 아카이브 로그 모드(Archive Log Mode)라고 한다.

오라클데이터베이스는 기본적으로 No Archive Log Mode이다. 그리하여 Archive Log Mode로 운영하기 위해서는
따로 설정을 해주어야 한다.




[ Oracle 8i 까지의 방법(Noarchive -> Archive) ]

텍스트로 만들어진 파라미터 화일을 사용하는 경우
Archive log mode로 운영하기 위해서는 다음과 같이 변경하여야 한다.

1. initSID.ora file(ex. initORCL.ora)과 configSID.ora(ex. configORCL.ora)에 다음의 parameter가 이미 setting
되어 있는지 확인한 후에 없을 경우 initSID.ora 에 setting한다.

1) LOG_ARCHIVE_START = TRUE

* ARCH process 가 기동
* log switch 발생 시 automatic archive를 수행한다.
만약 이 parametrer가 false이면 manual archive를 실시하여야 한다.

2) LOG_ARCHIVE_DEST = /home/oracle7/dbs/archive_file/arc

* archive 장소의 디렉토리와 확장자를 포함하지 않는 파일명을 지정.
* 여기에서 archive_file까지는 directory이며 마지막에 있는 arc는
archive log file의 initial 명이다.
* 자신이 설치한 ORACLE_HOME/dbs/archive_file/arc 로 설정한다.

3) LOG_ARCHIVE_FORMAT = %s.log

* archive file의 확장자와 log sequence 번호의 형식을 지정.
* 이는 (2)에서 정의된 archive log의 initial file 명과 함께 나타난다.

[ 예 ] arc123.log, arc124.log
(123과 124는 log sequence number 이다.)
와 같은 형태의 화일이 생성된다.


2. 다음과 같이 작업하여 archive log mode로 변환한다.

$ svrmgrl

SVRMGR> connect internal
SVRMGR> startup mount - (1)
SVRMGR> alter database archivelog; - (2)
SVRMGR> archive log list - (3)
Database log mode ARCHIVELOG - (4)
Automatic archival ENABLED - (5)
Archive destination ?/dbs_ar/offline_log/offline - (6)
Oldest online log sequence 123 - (7)
Next log sequence to archive 125 - (8)
Current log sequence 125 - (9)
SVRMGR> alter database open; - (10)


(1) DB를 startup mount까지만 한다.
(2) 이 Command를 이용하여 archivelog mode로 DB를 변경한다.
(3) Archivelog mode로 변경되었는지를 확인한다.
(4) DB가 Archivelog mode임을 나타낸다.
만약 NOARCHIVELOG로 되어 있으면 변경되지 않은 것을 의미한다.
(5) initSID.ora file에서 LOG_ARCHIVE_START parameter를 TRUE로
정의하였음을 나타내며 false인 경우에는 DISABLED로 나타난다.
(6) initSID.ora file의 LOG_ARCHIVE_DEST parameter에서 정의한
archive할 장소이다.
(7) 3 개의 redo log 중 가장 오래된 redo log의 sequence가 123임을
의미한다.
(8) 다음에 archive 받을 file의 log sequence 번호를 나타낸다.
(9) 현재 사용 중인 redo log의 sequence가 125임을 의미한다.
만약 이전부터 archivelog mode로 운영 중이었다면 여기에서 archivelog
file은 log sequence 124까지 archiveing되어있다는 것을 의미한다.
(10) Archive mode로 변경 후 DB를 open한다.


[ Oracle 9i 부터의 방법(Noarchive -> Archive) ]

바이너리로 만들어진 파라미터 화일을 사용하는 경우
Archive log mode로 운영하기 위해서는 다음과 같이 변경하여야 한다.

1. Parameter 확인

$sqlplus /nolog

SQL>connect sys/passwd@orcl as sysdba
Connected.
SQL> archive log list
Database log mode No Archive Mode
Automatic archival Enabled
Archive destination /u01/oracle/dbs/
Oldest online log sequence 1
Current log sequence 3

SQL> select name, value from v$parameter
where name = 'log_archive_start'
or name = 'log_archive_dest'
or name = 'log_archive_format' ;

2. 다음과 같이 작업하여 archive log mode로 변환한다.

SQL> ALTER SYSTEM SET LOG_ARCHIVE_START = TRUE
SCOPE=SPFILE;

System altered.

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area 89201304 bytes
Fixed Size 453272 bytes
Variable Size 67108864 bytes
Database Buffers 20971520 bytes
Redo Buffers 667648 bytes
Database mounted.
SQL> archive log list
Database log mode No Archive Mode
Automatic archival Enabled
Archive destination /u01/oracle/dbs/archive/orcl/arc
Oldest online log sequence 1
Current log sequence 3
SQL> alter database archivelog;

Database altered.

SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /u01/oracle/dbs/archive/orcl/arc
Oldest online log sequence 1
Next log sequence to archive 3
Current log sequence 3
SQL> alter database open;

Database altered.


[ Oracle 8i 까지의 방법(Archive -> Noarchive) ]

반대로, archivelog mode에서 no archivelog mode로 전환하는 방법은 다음과같다.
archivelog mode에서 no archivelog mode로 전환하기 전에 데이터베이스는 반드시
immediate 또는 normal 로 셧다운 되어야만 전환이 가능 하다.

먼저, 위에서 setting 했던 initSID.ora file 와 configSID.ora 에 있는
다음 parameter 앞에 # 을 넣고 저장한다.(주석처리!!)

#LOG_ARCHIVE_START = TRUE
#LOG_ARCHIVE_DEST = /home/oracle7/dbs/archive_file/arc
#LOG_ARCHIVE_FORMAT = %s.log

$ svrmgrl
SVRMGR> connect internal;
SVRMGR> shutdown immediate
SVRMGR> startup mount
ORACLE instance started.
Database mounted.
SVRMGR> alter database noarchivelog;
Statement processed.
SVRMGR> alter database open;
Statement processed.


[ Oracle 9i 부터의 방법(Archive -> Noarchive) ]

Noarchive log mode로 운영하기 위해서는 다음과 같이 변경하여야 한다.

1. Parameter 확인

$sqlplus /nolog

SQL>connect sys/passwd@orcl as sysdba
Connected.
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /u01/oracle/dbs/archive/orcl/arc
Oldest online log sequence 1
Next log sequence to archive 3
Current log sequence 3

SQL> select name, value from v$parameter
where name = 'log_archive_start'
or name = 'log_archive_dest'
or name = 'log_archive_format' ;

2. 다음과 같이 작업하여 Noarchive log mode로 변환한다.

SQL> ALTER SYSTEM SET LOG_ARCHIVE_START = FALSE
SCOPE=SPFILE;
System altered.

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area 89201304 bytes
Fixed Size 453272 bytes
Variable Size 67108864 bytes
Database Buffers 20971520 bytes
Redo Buffers 667648 bytes
Database mounted.
SQL> alter database noarchivelog;

Database altered.
SQL> archive log list
Database log mode No Archive Mode
Automatic archival Enabled
Archive destination /u01/oracle/dbs/archive/orcl/arc
Oldest online log sequence 1
Current log sequence 3
SQL> alter database open;
Database altered.

'01.오라클 > 003.DB 백업 및 복구' 카테고리의 다른 글

[오라클]아카이브 복구  (0) 2012.12.19
[오라클]아카이브 모드 변경  (0) 2012.12.19
[오라클]VMware 백업 복구 작업  (0) 2012.12.19
[오라클]FlashBack  (0) 2012.12.19
[오라클]Data Pump  (0) 2012.12.19
Posted by redkite
, |

VMware 백업 복구 작업

아래 스크립트는 질문 올라온 것을 확인하고 노트북 vmware의 oracle 9.2.0.7 에서 만들어보았습니다.


온라인 백업은 말씀한 것과 같이 파라메터 파일 , 콘트롤 파일, 모든 데이터파일 , 아카이브로그를
백업후 다른 서버로 이동시키면 다른 서버로 복구할 수 있습니다.

하지만 online backup시에 datafile, controlfile만을 백업하므로 current redo log가 없으므로
until cancel 복구를 해야 합니다.(rman 백업도 마찬가지)

1) init파일,DB file, controlfile을 다른서버로 이동시킵니다.
보통 controlfile백업은 alter database backup controlfile to '~~'; 이렇게 하기 때문에
하나만 복사하므로 이것을 추가 복사해서 controlfile의 경로에 복사해줍니다.
2) init파일에 controlfile의 경로, background_dump_dest, user_dump_dest, core_dump_dest, log_archive_dest 를
경로에 맞게 지정해줍니다.
3) DB를 mount상태로 올립니다. 만약 mount하는 동안 에러가 난다면 controlfile에서
문제가 생겼으므로 controlfile의 백업을 확인합니다.
4) datafile, redolog file의 file_name을 변경합니다.
select name from v$datafile;
select member from v$logfile;
alter database rename file '현재경로' to '이동시킨 경로';
alter database rename file '현재경로' to '이동시킨 경로';
...
단 여기에서 tempfile은 백업대상도 아니고 rename이 안되므로 새로 생성해 주어야 합니다.
select name from v$tempfile;
select * from sys.props$;에서 default temporary tablespace를 찾거나
또는 select distiinct temporary_tablespace from dba_users 에서 찾습니다.
tempfile을 추가하는 방법은 더이상 말씀 안드립니다. NBR과정의 기본이니까요..
5) DB의 archive file을 log_archive_dest 에 설정된 곳으로 이동시키고 recovery를 수행합니다.
recover database until cancel using backup controlfile;
...
마지막 archvie까지 적용후 cancel하기
alter database open resetlogs;
resetlogs open하기


# 온라인 백업 스크립트(데이터파일, 컨트롤파일만 백업)
작업 이전에 /backup , /backup/control 이라는 디렉토리 생성

- 백업 메인
vi /backup/onbackup.sh
export LANG=C
export ORACLE_HOME=/u/ora9i/product/9.2.0
export PATH=$ORACLE_HOME/bin:$PATH
export ORACLE_SID=PROD

sh -x /backup/1_onbackup.sh
sh -x /backup/2_cp_backup.sh
sh -x /backup/3_control_backup.sh
sh -x /backup/4_offbackup.sh

- 백업 모드 변경
vi /backup/1_onbackup.sh
export LANG=C
export ORACLE_HOME=/u/ora9i/product/9.2.0
export PATH=$ORACLE_HOME/bin:$PATH
export ORACLE_SID=PROD

# backup mode on
sqlplus /nolog << EOF1
conn /as sysdba
set head off
set feedback off
set time off
set timing off
set echo off
spool /tmp/backup_online.tmp
select 'alter tablespace '||tablespace_name||' begin backup;' from dba_tablespaces where status='ONLINE' and contents 'TEMPORARY';
spool off
!cat /tmp/backup_online.tmp|grep -v spool|grep -v SQL > /tmp/backup_online.sql
@/tmp/backup_online.sql
exit
EOF1

- 데이터파일 백업할 쿼리
vi /backup/2_cp_backup.sql

select 'mkdir /backup/'||to_char(sysdate,'YYYYMMDD_HH24MI') from dual;
select 'cp '||name||' /backup/'||to_char(sysdate,'YYYYMMDD_HH24MI') from v$datafile;

- 데이터파일 copy하는 스크립트
vi /backup/2_cp_backup.sh

# cp backup, mkdir /backup/SYSDATE directory
export LANG=C
export ORACLE_HOME=/u/ora9i/product/9.2.0
export PATH=$ORACLE_HOME/bin:$PATH
export ORACLE_SID=PROD

sqlplus /nolog << EOF2
conn /as sysdba
set head off
set feedback off
set time off
set timing off
set echo off
spool /tmp/backup_script.tmp
@2_cp_backup.sql
spool off

!cat /tmp/backup_script.tmp |grep -v spool |grep -v SQL > /tmp/backup_script.sh
!chmod 755 /tmp/backup_script.sh
exit
EOF2
sh -x /tmp/backup_script.sh

- 컨트롤파일 백업

vi /backup/3_control_backup.sh

export LANG=C
export ORACLE_HOME=/u/ora9i/product/9.2.0
export PATH=$ORACLE_HOME/bin:$PATH
export ORACLE_SID=PROD

# controlfile backup
sqlplus /nolog << EOF3
conn /as sysdba
set head off
set feedback off
set time off
set timing off
set echo off
spool /tmp/control_backup.tmp
select 'alter database backup controlfile to ''/backup/control/'||to_char(sysdate,'YYYYMMDD_HH24MI')||'.ctl'';' from dual;
spool off
!cat /tmp/control_backup.tmp |grep -v spool|grep -v SQL > /tmp/control_backup.sql
@/tmp/control_backup.sql
exit
EOF3

- 백업모드 offline하기

vi /backup/4_offbackup.sh

export LANG=C
export ORACLE_HOME=/u/ora9i/product/9.2.0
export PATH=$ORACLE_HOME/bin:$PATH
export ORACLE_SID=PROD

# backup mode off
sqlplus /nolog << EOF4
conn /as sysdba
set head off
set feedback off
set time off
set timing off
set echo off
spool /tmp/backup_offline.spool
select 'alter tablespace '||tablespace_name||' end backup;' from dba_tablespaces where status='ONLINE' and contents 'TEMPORARY';
spool off
!cat /tmp/backup_offline.spool |grep -v SQL > /tmp/backup_offline.sql
@/tmp/backup_offline.sql
exit
EOF4


그리고 만약 파일리스트만 내리고 veritas netbackup으로 백업이 가능하다면 아래와 같이 하면
됩니다. veritas netbackup에서는 file리스트만 파일로 떨구면 그 파일을 백업해줍니다.

archvie backup은 아래와 같이 하면 되는데 아래는 archive file의 backup list만 만듭니다.
수정해서 backup list에서 YYYYMMDD_HH24MI의 분단위 디렉토리를 만들고 archive file을
다른 서버로 cp복사하도록 하면 됩니다. 꼭 아래 스크립트는 테스트 후에 사용하시길
바랍니다...

# 데이터파일 백업과 archvie백업 쉘은 아래와 같습니다.

1. begin backup할 스크립트를 수행합니다.
dbbegin.sh

TBS_INFO=/tmp/tbs_info~.$$

sqlplus /nolog << EOF > $TBS_INFO 2>&1
connect / as sysdba;
select 'tablespace '||tablespace_name from dba_tablespaces;
disconnect;
exit
EOF

cat $TBS_INFO | awk ''$1 == "tablespace" { print $2 }'' | while read LINE
do
export LINE
echo "Issuing alter tablespace $LINE begin backup;"
/usr/openv/netbackup/oracle/table_begin.sh
done

\rm $TBS_INFO

2. 위에서의 table_begin.sh 는 아래와 같습니다.

table_begin.sh

sqlplus /nolog << EOF > /dev/null 2>&1
connect / as sysdba;
alter tablespace $LINE begin backup;
disconnect;
exit
EOF

3. dbbegin.sh 을 하게 되면 테이블스페이스가 backup mode가 됩니다.

4. 데이터파일 리스트를 추출합니다.
datafile_list

#!/bin/ksh

DATAFILE_INFO=/tmp/datafile_info~.$$
datafile_list=/tmp/PROD_data_list

sqlplus /nolog << EOF > $DATAFILE_INFO 2>&1
connect / as sysdba;
select ''datafile_name ''||file_name from dba_data_files;
select ''logfile_name ''||member from v\$logfile;
select ''controlfile_name ''||name from v\$controlfile;
disconnect
EOF

cat $DATAFILE_INFO | awk ''$1 == "datafile_name" {print $2}''

/tmp/PROD_dbfile_list

cat $DATAFILE_INFO | awk ''$1 == "logfile_name" {print $2}''

/tmp/PROD_logfile_list

cat $DATAFILE_INFO | awk ''$1 == "controlfile_name" {print $2}''

/tmp/PROD_controlfile_list


cat /tmp/PROD_dbfile_list > $datafile_list
cat /tmp/PROD_logfile_list >> $datafile_list
cat /tmp/PROD_controlfile_list >> $datafile_list

\rm $DATAFILE_INFO

5. 데이터파일 리스트를 netbackup에서 tape백업을 하도록 합니다.
veritas netbackup에서 리스트만 주면 백업해줌..

6. end backup 을 만드는 스크립트를 수행
dbend.sh
#!/bin/ksh

TBS_INFO=/tmp/tbs_info~.$$

sqlplus /nolog << EOF > $TBS_INFO 2>&1
connect / as sysdba;
select ''tablespace ''||tablespace_name from dba_tablespaces;
disconnect;
exit
EOF

cat $TBS_INFO |awk ''$1 == "tablespace" { print $2 }''|while read LINE
do
export LINE
echo "Issuing alter tablespace $LINE end backup;"
/usr/openv/netbackup/oracle/table_end.sh
done
\rm $TBS_INFO

7. 위에서 table_end.sh 는 아래와 같습니다.

table_end.sh
sqlplus /nolog << EOF > /dev/null 2>&1
connect / as sysdba;
alter tablespace $LINE end backup;
disconnect;
exit
EOF

6. archive log가 없을 수 있으므로 수동으로 log switch 해줍니다.

arch_list_1
#!/bin/ksh

sqlplus /nolog << EOF > $LOG
connect / as sysdba;
alter system switch logfile;
disconnect;
exit;
EOF

7. archvie file의 리스트를 뽑아냅니다.

arch_list

#!/bin/ksh

TBS_INFO=/tmp/tbs_info~.$$
ARCHIVE_DIR=/tmp/PROD_archive_dir.txt

sqlplus /nolog << EOF > $LOG 2>&1
connect / as sysdba;
alter system switch logfile;
disconnect;
exit;
EOF

sqlplus /nolog << EOF > $TBS_INFO 2>&1
connect / as sysdba;
archive log list;
disconnect;
exit;
EOF

cat $TBS_INFO | awk ''$1 == "Archive" {print $3}'' > $ARCHIVE_DIR

ARCH_DIR=
cat $ARCHIVE_DIR

ARCH_LIST_PROD=
ls -ltr $ARCH_DIR/*.arc |wc -l

echo "ARCH_LIST_PROD : $ARCH_LIST_PROD" >> $LOG

ARCH_LIST_PROD_1=
expr$ARCH_LIST_PROD - 1

echo "ARCH_LIST_PROD_1 : $ARCH_LIST_PROD_1" >> $LOG

/usr/bin/ls -ltr $ARCH_DIR/*.arc |awk ''{print $9}'' |head -
$ARCH_LIST_PROD_1 > /tmp/PROD_arch_list

echo "Archive Log List Print.....O.k....
/usr/bin/date +%c
" >> $LOG
#\rm $TBS_INFO $ARCHIVE_DIR

8. 위에서 /tmp/PROD_arch_list에 있는 archive리스트를 veritas netbackup에서 넣어주면 tape백업이 됩니다.그리고 특이한 것은 archvie file은 archive file을 백업했으면
지우도록 설정하면 되겠지요.

https://kr.forums.oracle.com/forums/thread.jspa?threadID=419569

 

'01.오라클 > 003.DB 백업 및 복구' 카테고리의 다른 글

[오라클]아카이브 복구  (0) 2012.12.19
[오라클]아카이브 모드 변경  (0) 2012.12.19
[오라클]아카이브 모드 변경  (0) 2012.12.19
[오라클]FlashBack  (0) 2012.12.19
[오라클]Data Pump  (0) 2012.12.19
Posted by redkite
, |

Flashback

1.1. Flashback이란?

사용자 실수에 의한 손상된 데이터를 Database의 크기와 상관없이 복구를 할수 있는기능이다. 이 Flashback 기능은 일반적인 복구에서 우려되는 데이터베이스의크기를 걱정하지 않아도 된다.

보통의 사용자 실수는 커다란시스템 장애가수반되며, 이를 복구하기 위해서는많은 자원과 시간이 필요하다. 하지만 9i에서 지원되는 flashback query와 10g에서 지원하는 다양한 flashback을통하여 손쉽게 사용자실수를 손쉽게 복구한다.

Oracle 9i 부터는 AUM 환경하에서 Flashback 기능을 이용하여 잘못된 DML operation 으로 인한 복구를 쉽게 할 수 있다. 물론 이전까지 했던 방법인 Point in Time Recovery 또한 유효하다.

△ 9i : Flashback query
△ 10g : Flashback Database
Flashback Drop
Flashback Version Query
Flashback Transaction Query
Flashback Table
Oracle Flashback Feature는 10g Standard Edition에서는 지원하지 않는다.

Note : 여기서 한 가지 짚고 넘어갈 점은 Flashback table, Flashback Database, Flashback Drop, Flashback Version Query, Flashback Transaction Query는 아래의 표와 같이 각기 다른 영역을 사용한다는 점이다.

Flashback Technologies

Flashback Operation

Implementation

Flashback Database

Flashback logs + Redo logs

Flashback Drop

Recycle bin

Flashback Version Query

Undo

Flashback Transaction Query

Undo

Flashback Table

Undo

1.2. Flashback(9i)

1.2.1. Flashback Overview

- Oracle 9i New features
- Flashback은 사용자가 Database의 과거 시점의 Consistent view를 볼 수 있게 해준다.
- 사용자들은 System time or SCN 를 기초로 Read-only view를 생성할 수 있다.
- 그 시점의 Transaction committed 부분만 볼 수 있다.
- Self-service repair를 가능하게 해준다.
- DDL은 지원하지 않는다.
- Flashback은 AUM (Automate Undo Management) 사용시만 가능하다.
- Undo 정보는 System level의 Undo retention 기간 동안만 유지한다.
- Flashback은 Session level에서 Enabled 할 수 있다.
- Flashback 기능을 disable 하기 전에 open된 PL/SQL cursor를 이용하면 disable 시킨 후에는
DML를 통해서 self-service repair를 할 수 있다.

▲ Undo Retention 지정
SQL> connect /as sysdba
SQL> alter system set undo_retention = <seconds> ;

이 parameter은 dynamic하게 변경이 가능하며 initSID.ora에 지정할 수 있다.
undo_retention은 각 Site별로 업무 성격 및 Undo Size에 따라서 적절하게 산정해서 명시해 준다. 또한 undo_management=auto 인지 확인한다.

▲ 권한 부여
SQL> grant execute on dbms_flashback to scott;

1.2.2. 예제 1 (AS OF SCN)

▲ SCOTT session에서 SYSTEMSTAMP를 이용하여 현재 시간을 조회하시오.

▲ SCOTT 소유의 Table에서 부서번호가 20인 부서원, 부서정보를 모두 삭제, Commit 하시오.

▲ 삭제된 Data가 잘 못 삭제된 것을 알게 되었다. 삭제된 Data를 다시 되살리고자 한다.

1.2.3. 예제 2 (AS OF TIMESTAMP)

▲ HR_TEST01 session에서 SYSTEMSTAMP를 이용하여 현재 시간을 조회하시오.

▲ 삭제된 Data가 잘 못 삭제된 것을 알게 되었다. 삭제된 Data를 다시 되살리고자 한다.

1.2.4. 예제 3 (Package, SCN / timestamp)

▲ HR_TEST01 session에서 SYSTEMSTAMP를 이용하여 현재 시간을 조회하시오.

▲ 삭제된 Data가 잘 못 삭제된 것을 알게 되었다. 삭제된 Data를 다시 되살리고자 한다.

※ 또는, 위 내용을 Procedure를 생성해서 복구 할 수도 있다.(flash.sql)

Flashback을 이용해 과거 데이터 복구
SQL> @flash /* exam_flash procedure 생성 */
SQL> exec exam_flash

1.3. Flashback(10g)

1.3.1. Flashback Database

Flashback Database 개요

Oracle Database 10g 이전까지는 transactional point-in-time recovery를 위해서는 backup용 file과 redo log file을 이용하여 원하는 시간까지의 복구를 하였었다. 그러나 이 방법은 backup용 file이 오래된 것이며, archive log가 많이 쌓여 있을 때는 많은 시간이 소요된다. Oracle Database 10g부터는 flashback database를 이용하여 좀 더 빠른 recovery가 가능하게 되었다.

Flashback Database는 오라클 데이터베이스를 과거 시점으로 되돌리고, 논리적인 데이터 손상 또는 사용자 실수로 인해 발생한 문제를 해결할 수 있게 한다. Flashback Database는 데이터베이스를 위한 '되감기 버튼'과도 같다. 데이터베이스 백업본을 이용하여 복구 작업을 수행하지 않고도 데이터베이스를 과거의 시점으로 되돌릴 수 있다. 포인트-인-타임 복구 작업에는 테이프에 저장된 데이터베이스 백업을 복구하는 시간이 불필요하므로, 한층 신속한 복구가 가능하다.

Flashback Database 기능은 RMAN, SQL*Plus에서 FLASHBACK DATABASE 커맨드를 이용하여 실행되며, 그 효과 면에서 일반적인 포인트-인-타임 복구 방식과 매우 유사하다. 이 기능을 이용하면 과거 특정 시점으로 데이터베이스의 상태를 되돌릴 수 있다. Flashback Database 기능을 활성화하려면, 먼저 Flash Recovery Area를 설정해야 한다. Flash Recovery Area는 Oracle Database 10g에 추가된 새로운 기능으로, 오라클 데이터베이스 복구 관련 파일 및 작업을 위한 통합적인 저장 공간으로 활용된다. 복구 영역에는 Flash Database 로그 이외에도 아카이브 리두 로그, RMAN 백업 등이 저장된다.

오라클은 Flash Recovery Area 내에 Flashback Log를 자동 생성/관리 한다. Flash Recovery Area에는 쿼타(quota)가 설정되며, 따라서 Flashback Log에는 공간 제한이 적용된다. Flashback Log의 사이즈는 로그 저장 기간 동안의 데이터베이스 변경 과정에서 발생한 읽기/쓰기 작업량에 따라 크게 달라진다. 오래된 블록 버전의 복사본은 Flashback Log에 기록된다. 하루 동안 10%의 데이터베이스 블록이 업데이트되었다면, 24 시간 동안의 Flashback Log 사이즈는 전체 데이터베이스 용량의 10 분의 1 수준이 될 것이다. 데이터베이스를 과거 시점으로 복구하는 과정에서 더 많은 디스크 공간이 필요한 경우, DBA는 디스크 쿼타를 다이내믹하게 확장할 수 있다.

Flashback database의 사용 용도는 logical data corruption이나 user error시 유용하다.
(Physical data corruption은 H/W 문제이기 때문에 Flashback database로 recovery는 불가능하다.) Flashback Database의 장점은 기존의 traditional point-in-time recovery에 비해 매우 빠른 recovery가 가능하다는 것이다. 이러한 빠른 성능을 낼 수 있는 이유는 flashback database는 database의 크기에 비례해서 recovery시간이 늘어나는 것이 아니라, 변경된 data의 양에 비례해서 recovery시간이 걸린다는 점이다.

위의 그림, 앞의 설명과 같이 Flashback Database는 매우 빠른 시간의 recovery를 가능하게 한다.

Flashback Database를 수행하기 위한 3가지 구성요소

1. Archive Mode
Flashback Database 기능을 적용하기 위해서는 Archive Mode로 설정하여야 한다.

2. Flashback Log File
Flashback Log File은 오라클 Database를 구성하는 Block(변경되기 이전의 이미지 Block)을 저장하는 로그 파일로서 10g에서 새롭게 소개되고 있는 데이터베이스 복구영역(database recovery area)에 생성되어진다.
기존의 redo log와의 차이점 - redo log의 경우에는 archive할 수 있는 기능이 함께 제공되었지만, Flashback Log는 archive 기능이 따로 제공될 필요가 없다.(db_recovery_file_dest, db_recovery_file_dest_size)
- Flashback Log의 경우에는 물리적인 database 복구에는 사용될수 없다는 점이다.

3. RVWR Background Process
Flashback Database 기능이 활성화 되어지면, rvwr이라는 background process가 시작된다.

역할 : Flashback Database Data를 Flashback Log에 기록

• Flashback Database 테스트

Database 에 Flashback 기능이 ON 되어 있는지 확인한다.

Test Case 생성

Flashback Database 를 위해 Instance 를 종료시킨다.

Flashback Database 를 위해 Instance 를 Mount 시킨다.

원하는 시점으로 되돌아 가기 위해 조금전에 기록했던 SCN 으로 Flash Back 한다.

Database 를 read only로 open 하여 Data를 확인 후에, Resetlogs 로 Open 하여 truncate 전의 데이터를 복구한다.

관련 view
V$FLASHBACK_DATABASE_LOG;
V$FLASHBACK_DATABASE_STAT;

1.3.2. Flashback Drop

사용자와 DBA 모두에게 있어 실수로 오브젝트를 드롭(drop) 처리하는 경우는 흔하게 발생한다. 사용자들이 실수를 깨달았을 때에는 이미 때가 늦다. 과거에는 이렇게 드롭 처리된 테이블, 인덱스, 제약조건, 트리거 등을 쉽게 복구할 수 있는 방법이 없었다. Flashback Drop은 Oracle Database 10g 환경의 오브젝트 드롭 작업을 위한 안전망을 제공한다. 사용자가 테이블을 드롭하면, 오라클은 드롭된 오브젝트를 Recyble Bin에 보관한다.

△ 10g에서 DROP TABLE을 하게 되면 기본적으로 실제 그것을 DROP 하는 것보다 RECYCLE BIN에 이동 시키거나 이름을 바꾸게 된다.
△ Drop 된 Table을 복구한다.
△ Drop table이 완전 drop 되지 않고, window의 휴지통과 같은 recyclebin에 보관된다.
△ 이 drop된 table은 완전 삭제를 위해서는 purge 작업이 필요하며, space가 부족한 경우에는 자동 reuse된다.
△ Drop되어 recyclebin에 있는 bin$xxxxxx table에 대한 직접조회도 가능함.
△ 관련 view
- dba_recyclebin, user_recyclebin
△ 관련 parameter
_recyclebin = FALSE : recyclebin 기능을 사용하지 않는 경우 False로 지정
△ 제약사항 : table이 system tablespace에 있는 object는 복구 불가.
locally managed tablespace에 위치해 있는 table만 복구 가능.
Table이 복구되면 그 table의 index, trigger 등의 연관된 object도 함께 복구된다.
(bitmap join index제외)
Partioned index-organized table은 recycle bin에 의해 보호 받지 못한다. recycle bin은 참조 무결성을 보장하지 않는다.

• 예제 1

1) Table을 drop 하기 (장애 만들기)

2) Drop된 Table 복구하기 1

3) Drop된 table 복구하기 2 (동일 이름의 table이 이미 있는 경우, 다른 이름으로 복구하기)

Drop된 table 완전 삭제하기

SQL> drop table scott.emp purge; -- drop 시 바로 purge하는 경우
SQL> purge recyclebin;
or
SQL> purge dba_recyclebin;
or
SQL> purge table scott.emp

아래는 몇가지 PURGE 옵션의 예 입니다.

PURGE TABLE tablename;

Specific table

PURGE INDEX indexname;

Specific index

PURGE TABLESPACE ts_name;

All tables in a specific tablespace

PURGE TABLESPACE ts_name USER username;

All tables in a specific tablespace for a specific user

PURGE RECYCLEBIN;

The current users entire recycle bin

PURGE DBA_RECYCLEBIN;

The whole recycle bin

• 예제 2

휴지통(recyclebin)에 같은 이름의 table이 여러개 있을 때 PURGE and FLASHBACK TO BEFORE DROP 방법

같은 이름을 가지는 table이 휴지통(recyclebin)에 하나 이상있을 경우 다루는 방법입니다. table을 PURGE 하는 경우 가장 오래된 table이 휴지통에서 PURGE 되고 table을 restore(FLASHBACK BEFORE DROP)하는 경우 가장 최근의 table이 저장됩니다.

Example
========
5개의 table을 생성하고 drop 하자..

만일 table t1 을 purge 한다면 dropscn=2039107 가 purge 될것이다.

만일 table t1 을 restore 한다면 dropscn=2039252 이 restore 할 것이다.

=>이 문제를 해결하기 위해서..
================================
이 문제를 극복하기위해서 우리는 original 이름 대신에 drop된 object name을 사용하면 된다. object name 은 unique 하므로 원하는 것을 purge 와 restore 할 수 있다.

비슷한 방법으로 purge 할수 있다.

1.3.3. Flashback Versions Query

△ 과거의 어떤시점의 정보를 시간과 SCN(SystemChange Number)를 이용하여 Query하는 기능.
△ 9i 부터지원된 Flashback Query가 있으며, 10g에서는 그 기능이 확장되어 Versions between을 이용해서 일정시점이 아닌 시간간격의 데이터를 조회할 수 있는 기능.
△ Flashback versions query에 의해 추출된 row들은 transaction에 의해 변화된 row들의 history를 보여줌. 이 기능은 data가 어떻게 바뀌었는지 auditing 기능을 가능하게 하며 commit된 데이터만 추출 함.
△ Flashback versions query를 통해서 알수 있는 transaction id를 통하여 더 추가적인 정보를 Flashback Transaction Query를 통해 얻을수 있다.
△ DDL이 수행되어 table의 구조가 바뀌면 사용불가.
△ Flashback versions query는 undo를 이용하여 과거 데이터를 읽어오는 것은 undo_retention 값과 undo size에 의해 자동으로 관리됨. 만약 undo_retention이 아주 크다고 하더라도, undo size가 작아서 undo를 보관하지 않고 재사용하게 되면 flashback versions query가 수행되지 않을 수 있음.
△ Versions between은 시간과 SCN으로 지정 할 수 있음
△ 이기능을 지원하기 위해 scn_to_timestamp 와 timestamp_to_scn function이 지원된다.

• 과거의 시점에 대한 SCN 확인.

• 과거의 SCN을 이용하여 Time 확인.

△ Versions Query의 Pseudo column (Select절에 사용할 수 있음)
• Versions_startscn,
• Versions_starttime
• Versions_endscn
• Versions_endtime
• Versions_xid
• Versions_operation
△ 주의 : undo retention 보다 이전의 version을 query하면 ora-30052 : invalid lower limit snapshot expression 발생함.

• 예제

Data 변경(Update) 하기


2007 2월 25일 15시 50분 ~ 16시 00분 까지 empno가 7934인 data가 변한 내역조회

1.3.4. Flashback Query

Oracle9i에서 처음 소개된 Flashback Query는 과거 시점의 데이터를 조회하는 기능을 제공한다. 기본적으로 데이터베이스는 가장 최근에 커밋된 데이터를 기준으로 작업을 수행한다. 하지만 과거의 특정 시점을 기준으로 데이터베이스를 조회하고자 한다면, Flashback Query 기능을 이용할 수 있다. Flashback Query는 특정 시점 또는 SCN(System Change Number)을 기준으로, 해당 시점에 커밋된 데이터를 조회할 수 있게 한다. Flashback Query 메커니즘은 Automatic Undo Management를 이용하는 경우 가장 효과적으로 동작한다.

오라클 데이터베이스는 언두(undo)를 중요한 데이터베이스 오브젝트로 관리한다. 언두 데이터는 영구적으로 저장/관리되며 데이터베이스 시스템에 크래쉬, 셧다운이 발생하는 경우에도 유지된다. 또 다른 데이터베이스 오브젝트와 함께 데이터베이스 버퍼 캐시를 공유하므로 성능 보장이 가능하다. 오라클 데이터베이스는 트랜잭션이 커밋된 이후에도 언두 데이터를 관리하고, 필요한 경우 논리적 손상으로부터 복구할 수 있게 한다.

오라클 데이터베이스의 관리자는 보존할 언두 데이터의 양을 명시적으로 지정할 수 있다. 시스템은 새로운 트랜잭션의 언두 데이터를 생성하기 위해 만료된 언두 데이터를 자동으로 삭제한다. 언두 데이터의 보존 기간은 롱-러닝(long-running) 쿼리의 실행 시간 또는 논리적 손상에 대한 복구 요구사항에 따라 다르게 설정된다. 또는 언두 보존 기간을 설정하지 않고 데이터베이스가 알아서 최적의 보존 정책을 관리하도록 할 수도 있다. 그러면 데이터베이스는 롱-러닝 쿼리에 대한 실행 시간과 논리적 손상의 복구를 최대한 보장할 수 있는 방안을 자동으로 적용한다. 디폴트 상태에서 언두 데이터의 보존은 보장되지 않는다. 시스템은 현재 진행 중인 트랜잭션의 언두 데이터 기록을 위해 필요한 경우, 언제든 오래된 언두 데이터를 만료 처리할 수 있다.

10g R1부터는 UNDO_RETENTION이 5 일 이상으로 지정되어 있는 경우, 5 일 또는 그 이상 경과한 과거의 데이터를 쿼리할 수 있는 기능이 추가되었다. 오라클은 Undo Tablespace 데이터파일에 충분한 공간이 남아 있는 한, 언두 데이터를 유지한다. 데이터베이스에서 Flashback Query와 기타 언두 데이터 관련 플래시

1. 데이터베이스가 Undo Tablespace를 사용하고 있는지 확인한다. Undo Tablespace를 사용하려면 UNDO_MANAGEMENT 초기화 매개변수를 AUTO로 설정해 놓아야 한다.
2. 가장 긴 실행 시간을 갖는 쿼리를 성공적으로 복구할 수 있는 시간, 또는 사용자 에러로부터 복구하기에 충분한 시간으로 UNDO_RETENTION 초기화 매개변수를 설정한다.
3. 만료되지 않은 언두 데이터가 덮어씌워지지 않도록, 언두 테이블스페이스에 RETENTION GUARANTEE 조건을 추가한다.

Flashback Query 기능을 이용하면 과거의 데이터 시점의 데이터를 확인할 수 있을 뿐 아니라 데이터를 처리하는 방법을 선택하는 것도 가능하다. 분석 작업을 수행한 후에 모든 변경 작업을 취소하거나, 변경 데이터를 캡처하여 다른 작업에 활용할 수도 있다. Flashback Query 메커니즘은 다양한 상황에서 활용될 수 있는 유연성을 제공한다. 몇 가지 활용 예가 아래와 같다:

• 과거 시점의 데이터를 조회.
• 현재 데이터와 과거 데이터를 비교. (개별 로우를 비교하거나 Intersection, Union 등의 조건을 이용하여 복잡한 비교 작업을 수행할 수도 있다.)
• 삭제, 변경된 데이터의 복구.

△ Oracle9i에서 부터 지난 시점의 데이터를 질의 하기 위한 DBMS_PACKAGE를 제공 했으며 10g에서는 훨씬 기능을 유연하게 발전 시켰다.
△ Flashback Query는 AS OF 절을 사용하여 해당 시점에서의 데이터 값에 대한 질의가 가능하며, 이 기능은 DBMS_FLASHBACK 패키지의 기능과 유사하다.
△ Flashback versions query는 과거의 일정 시간구간에서 조회하는 것에 비해 Flashback query는, 과거의 일정한 시간에서 query를 하는 것.
△ Database는 현재의 시간이지만, 수행하는 SQL은 혼자 과거의 정보를 보게 됨.

• 예제

-- Data 삭제(장애 만들기)

-- 1시간 전 Data를 구하기

-- 1분 전 Data를 구하기
※ delete 후 바로 조회하면 아직 delete 되지 않은 것으로 보인다.

-- 1시간전 Data와 현재 Data의 차이를 알고 싶을때.
-- 즉, 1시간전과 같지 않은 데이터를 모두 찾는다.

※ 1시간 전의 Table을 Backup 해 놓을수 있다.

-- 급하게 복구를 해야 할때. 약 1시간전에 많은 건수를 삭제한 경우.

1.3.5. Flashback transaction query

테이블의 데이터 변경 작업이 잘못 수행되었음을 나중에야 발견하는 경우가 있다. 변경 내역을 조사하기 위해, DBA는 플래시백 쿼리를 실행하여 특정 시점의 로우 데이터를 조회할 수 있다. 또는 좀 더 효율적인 방법으로, Flashback Versions Query 기능을 이용하여 일정 기간 동안의 로우 변경 내역과 트랜잭션 ID를 한꺼번에 확인할 수도 있다. 이때 DBA는 SELECT 구문에 VERSIONS BETWEEN 절을 적용하고, SCN 또는 타임스탬프를 기준으로 일정 기간의 로우 변경 히스토리를 조회한다.

문제가 되는 트랜잭션을 발견했다면, 다시 Flashback Transaction Query 기능을 이용하여 해당 트랜잭션에 의해 수행된 다른 변경 사항을 확인한다. 그리고 변경 사항을 복구하기 위한 언두(undo) SQL을 요청한다. 이때 트랜잭션 히스토리와 언두 SQL을 확인하기 위해 사용되는 것이 바로 FLASHBACK_TRANSACTION_QUERY 뷰이다.

잘못 실행된 트랜잭션을 완전히 취소하기 위해, 언두 SQL 구문을 수동으로 실행하고 사용자/애플리케이션 에러를 쉽게 복구할 수 있다. Flashback Transaction Query는 데이터베이스의 온라인 진단 범위를 확장하고, 분석 및 트랜잭션 감사 환경을 개선할 수 있게 한다.

△ VERSIONS_XID 값이 트랜잭션의 ID라고 했는데, 이 값을 FLASHBACK_TRANSACTION_QUERY의 인자 값으로 줘서 쿼리를 실행 하면 해당 트랜잭션에 대한 정보를 볼 수 있다.
예를 들면 어떤 DML을 이용했으며 어떠한 SQL이 실행 되었는지 하는 것이 확인 가능하다.
△ Flashback transaction query는 Transaction level에서 Data의 변경사항을 추적하기 위한 기능
△ Transaction의 분석과 진단을 하는 기능 임.
△ 변경사항 뿐만 아니라, Undo SQL을 생성할 수 있으며, 이 SQL을 이용하여 Transaction level의 작업을 rollback할 수 있음
△ undo data를 index access 방식으로 조회하므로 logminor
주의 : xid column에 조건을 줄 때 반드시 hextoraw function을 사용해야 만 fixed view의 index를 사용함.
△ Flashback versions query와 마찬가지로 undo data를 이용함.
△ Flashback Transaction query를 사용하기 위해서는 Database level에 logging이 enable되어야 한다.
alter database add supplemental log data;
확인방법 : select supplemental_log_data_min from v$database ( YES 가정상)
△ 필요 권한 : grant select any transaction to XXX;
△ 기본적으로 flashback_transaction_query 라는 view table을 이용하여 query한다.
△ flashback_transaction_query columns.

• Database level에 logging이 enable되어있는지 확인 한다.

• emp와 dept를 각각 수정한 후, 이에 대한 transaction query를 하는 예제.

-- flashback versions query를 이용하여 xid를 찾는다.

-- 해당 Transaction을 rollback하기 위해서는 아래와 같이 undo_sql을 수행한다.

1.3.6. Flashback Table

Oracle9i Database에는 Flashback 질의 옵션 개념이 도입되어 데이타를 과거의 시점에서부터 검색하지만, 테이블 삭제 같은 DDL 작업을 순간적으로 되돌릴 수는 없습니다. 이 경우 유일한 수단은 다른 데이타베이스에서 테이블스페이스 적시 복구를 사용한 다음, 엑스포트/임포트 또는 기타 메서드를 사용해 현재 데이타베이스에 테이블을 다시 생성하는 것입니다. 이 프로시저를 수행하려면 복제를 위해 다른 데이타베이스를 사용하는 것은 물론, DBA의 많은 노력과 귀중한 시간이 요구됩니다.

하지만 Oracle Database 10g의 Flashback 테이블 기능으로 들어가면 몇 개의 문만 실행하여 삭제된 테이블을 간단히 검색할 수 있습니다.

△ Flashback Table은 잘못된 데이터 처리를 한 경우, 작업전의 시점으로 빠르게 돌려주기 위한기능. (SCN or 시간)
△ Flashback Table 명령을 통해 개별적인 테이블에 대해 시간에 준한 복구를 위해서는 아래에 있는 조건을 만족 해야 합니다. 테이블의 데이터에 대해 과거 시점으로 돌아가서 값들을 확인 하는 것이 가능 합니다.
△ Flashback any table 또는 해당 Table에 대한 Flashback object privilege를 가지고 있어야 합니다.
△ 테이블에 대한 SELECT, INSERT, DELETE, ALTER 권한이 있어야 합니다.
△ ROW MOVEMENT의 경우 테이블에 대해 ALTER TABLE tablename ENABLE ROW MOVEMENT;가 설정 되어 있어야 합니다.
△ Backup의 restore없이 Table을 지정한 시점까지 되돌려 줌.
△ Table의 데이터만을 과거시점의 데이터로 돌려주며, Table과 관련한 모든 object (index, constrains, trigger)등은 현재시점으로 유지됨
△ Table이 Flashback 하는 동안에는 exclusive lock을 잡게됨.
△ Flashback 한후, 다시 현재 시점의 Data로 돌아올 수 있음. 그러나 현재의 SCN을 알고 있어야 함.
SELECT current_scn FROM v$database; -- 현재 SCN알기
△ 다음의 Object들에는 Flashback table 안됨.
Cluster, Mview, AQ tables, static data dictionary, system tables, remote tables
△ Undo Data를 이용함.
△ undo retention 이전의 데이터는 복구 안됨.
△ flashback versions query로부터 원하는 SCN을 찾아서 flashback table을 할 수 있음.
(VERSIONS_STARTSCN, VERSIONS_ENDSCN)
△ 필요 권한 : flashback object, flashback any table, 해당 table에 대한 select, insert, update, delete, alter table 권한.
△ flashback table을 하기 위해서는 row movement 를 enable해 주어야 함.
alter table XXXX enable row movement;
△Table에 DDL의 변경 작업이 있었다면, flashback 불가 (moving, truncate, add, modify, drop,merging, split, coalescing)

• Flashback Table 예제: SCN을 이용한 과거시점으로 Flashback 하기

1.3.7. Flashback Use Case

• 장애의경우에 따라 Use Case를사용하여 신속히 복구한다.

장애 Case

Case 상세

복구 방법

Table이 Drop된경우

 

Recyclebin을 조회하여 drop한 table의 복구가능성을 확인 한다.
Flashback Drop을 이용하여 복구 한다.

Table에 데이터를 잘못
변경하고 commit한 경우

많은 데이터 변경시

변경시점으로 Table을 flashback하는 방법.

적은 데이터 변경시

Table에 대해 Version query를 이용하여 해당data의 변경 tx를 찾는 방법.

Program이 잘못 수행되어 여러개의 table에 변경되었을 경우.

Commit이
한번일 경우

하나의 Table에서, 변경된 Data에 대한 Versions query를 하여 Transaction을 찾은 후, Transaction에 대한 undo를 뽑아 복구.

Commit이 여러 번인 경우

Flashback query를 통해 여러 Table을 Select하여 backup본 구성.

데이터에 대한 변경이력 추적시

 

Flashback Version Query를 이용하여 변경 이력 추적

Pro-Active Tuning Service 소개

1. 실제 사용자(End-User) 관점의 응답시간 튜닝

Pro-active tuning service는 사용자 관점의 모니터링 및 분석을 통하여 실제 End-User가 느끼는 응답시간(Response Time)을 튜닝합니다. APM(Application Performance Management) 툴을 이용하여 End-User의 Request 결과를 반환받기까지의 모든 구간(Client PC, Internet 구간, FireWall, DNS, Web Server, WAS, DBMS) 을 분석하여 가장 Delay Time 이 많이 소요된 구간을 찾아 냅니다.

2. 최상의 성능 상태로 비즈니스 고가용성을 유지

Pro-Active Tuning Service

  • 매 업무 단위 프로젝트 마다 참여하여 업무 적용(Open) 前 문제 요소를 분석하여 튜닝.
  • 단위 업무 적용(Open) 후 매 3개월(데이터량 갱신 주기) 마다 튜닝 포인트를 설정, 성능 둔화 요소를 해결.
  • 전사적으로 새롭게 추가되는 업무 단위 프로젝트의 모든 SQL 쿼리를 검토 및 튜닝.
    다양한 대용량 데이터베이스 관리/튜닝 기법을 도입하여 최적의 DB 상태를 1년 내내 상시 유지.
  • 전략적 튜닝 Factor를 분석, 투자 대비 효율이 높은 Targeting 기법 적용. (비중도 높은 SQL을 튜닝함)

    3. Knowledge Transfer

    Pro-Active Tuning Service는 고객의 Business Process를 이해하고 시스템을 분석한 후 튜닝하는 것으로 완료되지 않습니다. 실제로 고객사 환경에서 튜닝한 내용을 그대로 실무자들에게 전수하여 내부 임직원의 역량을 제고시킵니다. 또한, Oracle RDBMS 신 버젼의 New Features를 교육함으로써, 이용자(관리자 및 개발자)가 스스로 개발 업무의 효율 및 생산성을 향상시킬 수 있도록 지원합니다. 이외에도 DBMS 관리자를 위한 관리 노하우(고급 Trouble-Shooting, 대용량 DB 처리, 병렬 처리 등)를 전수함으로써, 최상의 시스템을 최고의 기술로 유지할 수 있도록 지원합니다.

    UAS (User Adapted Seminar) 진행 사례 및 내용 (Contents)

Posted by redkite
, |

 

Data Pump

create directory cms_pump as '/oracle/redkite';
expdp \"/ as sysdba \" schemas=ADMINIBDEMO,ADMINIBDEMO30 directory=cms_pump dumpfile=mig
create directory cms_pump as '/oracle/redkite';
impdp \"/ as sysdba \" schemas=ADMINIBDEMO,ADMINIBDEMO30 REMAP_TABLESPACE=ADMIN_TS:ADMIN_TS directory=cms_pump dumpfile=mig


expdp userid=\"/ as sysdba\" full=y dumpfile=db1.dmp logfile=db1_exp.log
expdp \"/ as sysdba \" schemas=quicsusr,adminibusr,ibfusr directory=kbst2nd_pump dumpfile=mig

create directory kbst2nd_pump as '/oracle/app/oracle/product/1020/db/work';
impdp \"/ as sysdba \" schemas=quicsusr,adminibusr,ibfusr REMAP_TABLESPACE=usrtbl:usertbl directory=kbst2nd_pump dumpfile=mig

impdp userid=\"/ as sysdba\" full=y dumpfile=db1.dmp logfile=db1_imp.log

 

*. Data Pump

-------------------------
Oracle 10g의 기능인 Data Pump는 Oracle Database data와 metadata의 이동을 위한
DBMS_DATAPUMP 패키지를 통하여 상당히 빠른 Data Pump infrastructure를 제공하고 있다.

기존 Oracle 9i까지 사용되던 exp, imp 유틸리티보다 더욱더 향상된 성능을 목적으로
만들어진 유틸리티다.

Data Pump는 exp/imp보다 훨씬 많은 기능이 있으며, 대량의 데이터를 작업할 때

무척이나 빠르게 작업할 수 있다. 다음은 간단한 사용방법 및 샘플이다.

 

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

*. expdp

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

1. 디렉토리 조회
   SQL> SELECT * FROM dba_directories;  

 

2. 디렉토리 추가
   SQL> DROP DIRECTORY dpump_dir2;                       -- 기존 디렉토리 dpump_dir2 drop
   SQL> CREATE DIRECTORY dpump_dir2 as '/backup/dpump';  -- /backup/dpump 에 대한 디렉토리 dpump_dir2 생성

 

3. 디렉토리에 대한 권한 설정
   SQL> GRANT READ, WRITE ON DIRECTORY dpump_dir2 to 사용자;

 

4. expdp
   # expdp system/1239 DIRECTORY=dpump_dir2 schemas=MESS_ADM   DUMPFILE=MESS_ADM_20081223.dmp \

           logfile=MESS_ADM_20081223.log

 

   # expdp SYSTEM/1239 DIRECTORY=DPUMP_DIR2 DUMPFILE=expdp_alldata_0106.dmp \

           LOGFILE=expdp_alldata_0106.log PARFILE=expdp.par CONTENT=DATA_ONLY

 

   # expdp system/1239 DIRECTORY=dpump_dir2 tables=MESS_ADM.TB_ABC110      \

           DUMPFILE=tb_ABC110_20100601.dmp logfile=tb_ABC110_20100601.log CONTENT=DATA_ONLY

 

* expdp(또는 impdp) 작업 진행 중 Control+C를 누르면 export> 프롬프트(또는 import> 프롬프트) 상태가 됨.
  Control+C 했다고 해서 작업이 중단되지는 않고, interactive mode로 변경되어 expdp(또는 impdp) 작업을

  모니터링하고 제어 가능

  [interactive mode에서 사용할 수 있는 명령어]
  - STATUS          : 현재 작업진행정도 확인 가능
  - CONTINUE_CLIENT : 다시 원래 모드로 돌아감
  - KILL_JOB
  - STOP_JOB
  - 나머지 명령어는 HELP 참고


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

*. impdp

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

1. 디렉토리 조회
   SQL> SELECT * FROM dba_directories;  

 

2. 디렉토리 추가
   SQL> DROP DIRECTORY dpump_dir2;                       -- 기존 디렉토리 dpump_dir2 drop
   SQL> CREATE DIRECTORY dpump_dir2 as '/backup/dpump';  -- /backup/dpump 에 대한 디렉토리 dpump_dir2 생성

 

3. 디렉토리에 대한 권한 설정
   SQL> GRANT READ, WRITE ON DIRECTORY dpump_dir2 to 사용자;

 

4. impdp


   # impdp system/1239 dumpfile=PT_ABC110_02.dmp directory=dpump_dir2 \
      job_name=job_impdp2 logfile=impdp_PT_ABC110_02.log TABLES=MESS_ADM.TB_ABC110 \
      parallel=4 TABLE_EXISTS_ACTION=APPEND

 

   [TABLE_EXISTS_ACTION 옵션]
    같은 이름의 테이블이 존재할 때 SKIP / APPEND / TRUNCATE / REPLACE

 

 

[샘플]

 

*. expdp(파티션 테이블)

------------------------
   # expdp system/1239 DIRECTORY=dpump_dir2 tables=MESS_ADM.TB_ABC110:PT_ABC110_01 \

           DUMPFILE=PT_ABC110_01.dmp logfile=PT_ABC110_01.log CONTENT=DATA_ONLY
   # expdp system/1239 DIRECTORY=dpump_dir2 tables=MESS_ADM.TB_ABC110:PT_ABC110_02 \

           DUMPFILE=PT_ABC110_02.dmp logfile=PT_ABC110_02.log CONTENT=DATA_ONLY
   # expdp system/1239 DIRECTORY=dpump_dir2 tables=MESS_ADM.TB_ABC110:PT_ABC110_03 \

           DUMPFILE=PT_ABC110_03.dmp logfile=PT_ABC110_03.log CONTENT=DATA_ONLY

                 :

 

*. impdp(파티션 테이블)

------------------------
   # impdp system/1239 dumpfile=PT_ABC110_02.dmp directory=dpump_dir2 \
      job_name=job_impdp2 logfile=impdp_PT_ABC110_02.log TABLES=MESS_ADM.TB_ABC110 \
      parallel=4 TABLE_EXISTS_ACTION=APPEND

 

    Import: Release 10.2.0.2.0 - 64bit Production on Wednesday, 02 June, 2010 0:31:37

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

    Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bit Production
    With the Partitioning and Data Mining options
    Master table "SYSTEM"."JOB_IMPDP2" successfully loaded/unloaded
    Starting "SYSTEM"."JOB_IMPDP2":  system/******** dumpfile=PT_ABC110_02.dmp directory=dpump_dir2 job_name=job_impdp2

    logfile=impdp_PT_ABC110_02.log TABLES=MESS_ADM.TB_ABC110 parallel=4 TABLE_EXISTS_ACTION=APPEND
    Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
    . . imported "MESS_ADM"."TB_ABC110":"PT_ABC110_02"       746.4 MB 18653423 rows
    Job "SYSTEM"."JOB_IMPDP2" successfully completed at 00:32:53


 

1.1. Oracle Data pump란?

Oracle Data Pump는 Oracle Database 10g 버전에서 제공되는Utility로 향상된 데이터 이동을 가능하게 한다.
이전 버전의 오라클을 설치한 홈 디렉토리에는 ‘imp’,’exp’라는 실행 파일이 있다. 이는 오라클에서 제공하는 backup 및 recovery 에 사용되는 도구 이다.
Exp는 데이터베이스에 저장되어 있는 데이터들을 OS의 바이너리 파일로 전환하는 도구이고, imp는 바이너리 파일을 데이터베이스 안의 데이터로 전환하는 도구이다. 새로 등장한Data Pump는 exp 와 imp를 대체하기 위하여 오라클 10g 버전부터 제공되는 유틸리티로 Exp / Imp 와 유사한 동작을 하지만 data pump 가 훨신 효율적으로 동작한다.
Exp/Imp와 비교하여 그 효율성을 예를 들자면 exp시 single thread 에서 2배가 빠르고 imp시 15~45배 빠르므로 데이터베이스간의 bulk data 와 meta data의 전송시간을 줄이는데 효율적으로 사용될 수 있다.

1.2. Data pump Key features

1.2.1. Fast Performance

앞에서 말한 것과 같이Data Pump Export and Import 유틸리티는 기존의 Export and Import 유틸리티보다 훨씬 빠르다. Data Pump Export 에서 direct path method를 사용시 single stream data unload에서 기존의 export 보다 2배가 빠르다. 이는 direct path API가 더 효과적으로 수정 되었기 때문이다. Parallelism 의 level에 따라서는 더욱 향상된 performance를 보일 수 있다.

Data pump import 에서는 single stream 의 data load 시 기존의 import 보다 15~45배가 빠르다. 이는 기존의 import 에서 단순히 export dump파일에서 레코드를 읽고 일반적인 insert into 명령을 사용해서 대상 테이블에 삽입 하는 대신에 Data pump import 는Direct path method loading 을 사용하기 때문이다.


1.2.2. Improved Management Restart


모든 Data Pump operation은 Data Pump job을 실행하는 스키마에 만들어진 master table을 가지고 있다. Master table은 현재 수행중인 모든 export또는 import시 객체의 상태정보와 dump file set에서의 위치정보를 가지고 있다. 이는 갑작스런 job의 중단에도 job 의 성공적인 종료에 상관 없이 어떤 object의 작업이 진행 중이었는지 알 수 있게 해 준다. 그래서 master table 과 dump file set 이 있는 한 모든 정지된 data pump job은 데이터 손실 없이 다시 시작할 수 있다.

1.2.3. Fine-Grained Object Selection

Data Pump job 은 거의 모든 type의 object를 exclude 또는 include 시킬 수 있다.
아래의 parameter 가 사용된다.
* EXCLUDE - 특정 객체 유형을 제외한다. (예: EXCLUDE=TABLE:EMP)
* INCLUDE - 특정 객체 유형을 포함한다. (예: INCLUDE=TABLE_DATA)
* CONTENT - 로드를 취소할 데이터를 지정한다.
적합한 키: (ALL), DATA_ONLY 및 METADATA_ONLY.
* QUERY - 테이블의 부분 집합을 엑스포트하기 위해 사용되는 술어 절이다.

1.2.4. Monitoring and Estimating Capability

Data Pump는 Standard progress , error message를 log file에 기록할 뿐만 아니라 현재 operation의 상태를 대화식모드 ‘command line’으로 보여 준다. Job의 completion percentage를 측정하여 보여주며 초 단위의 지정한 time period에 따라 자동으로 update하여 표시한다.

1개 이상의 client가 running job에 attach 수 있기 때문에 업무환경에서 job을 실행하고, detach 한 후 집에 가서 job을 reattach 하여 끊김 없이 모든 job을 모니터링 할 수 있다.
모든export job이 시작할 때 대략적인 전체unload양을 측정해 준다. 이는 사용자가 dump file set을 위한 충분한양의 disk space를 할당할 수 있게 한다.

1.2.5. Network Mode

Data Pump Export and Import는 job의 source가 리모트 인스턴스 일 경우를 위한 network mode를 지원한다.

Network을 통해 import를 할 때 source가 dump file set이 아닌 다른 database에 있기 때문에 dump file이 없다.

Network를 통해 export를 할 때 souce가 다른시스템에 있는 read-only database 일 수 있다. Dumpfile은 local(non-networked)export 처럼 local 시스템에 쓰이게 된다.

1.3. Data pump overview

1.3.1. Data Pump Overview

- expdp/impdp로 제공 되어 진다.
- exp/imp의 superset 이다.
- Data 와 metadata를 매우 빠른 속도로 load/unload 하는 Server-based facility이다.
==> dump file sets은 Server에 생성
- DBMS_DATAPUMP PL/SQL Package를 이용하여 사용 가능 하다.
- Web-based interface <--access from EM Database Control이 가능하다.
- Data Pump job을 실행하는 schema에 master table(MT)이 만들어 진다.

MT는 해당 job의 모든 것(aspects)을 관리하며 data pump(expdp)의 마지막 단계에서 pump file sets에 기록된다.


file based import 작업(impdp)시 dump file에 있는 MT 내용을 current user의 schema에 제일먼저 loading한다.


계획 또는 예상치 못한 job의 중단 시 재가동수 있게 하는 Data Pump의 핵심이 MT 이다.



Client process는 Data Pump API를 call한다.


-여러 개의 clients가 모니터링하고 control하기 위해서 job을 attach/detach 한다.

1.3.2. Data Pump Benefit

- Data Access Methods : Direct Path, External Tables
- Detach from, reattach to log-running jobs
- Restart Data Pump Jobs
- Find-grained object selection <-- 원하는 rows만(EXCLUDE, INCLUDE, CONTENT)
- Explicit database version specification
- Parallel execution
- Estimate export job space <--ESTIMATE_ONLY
- Network Mode에서는 Remote의 server process가 DB link를 이용하여 Local에 dump file을 직접 만들어 준다..
- Import 과정에서 target data file name, schema, tablespace 을 변경할 수 있다.

1.3.3. Data Pump File Locations

- Data pump file 종류

- DUMP file : data와 metadata를 포함한다.
- LOG file : operation과 관련된 message를 기록한다.
- SQL file : impdp에서 SQLFILE operation의 결과를 기록한다.
- Data Pump는 server-based 이므로 Oracle directory path를 통해서 Data Pump file에 access한다.
Absolute path는 보안상 지원되지 않는다.

- Order of precedence of file locations

1) per-file directory
- dump file, log file, sql file 마다 지정될 수 있다. 콜론(:)으로 directory 와 file name 을 구분한다.
예) dumpfile=AA:A.dmp

2) DIRECTORY parameter

- directory object를 사용한다.
Create Directory DIR_PJH as '/home/oracle10g/test/';
Grant read, write On Directory DIR_PJH to SCOTT;
Directory=AA
Dumpfile=A.dmp


3) DATA_PUMP_DIR 환경변수

- DIRECTORY Parameter를 대신하여 directory object name을 설정한다.
export DATA_PUMP_DIR=AA
Dumpfile=A.dmp
- 위의 모든 경우에 시도하려는 operation에 대해 directory object에 대해 적절한 access privs가 있어야 한다.
Export할 경우 모든 file에 대해 write access가 필요하다.
Import할 경우 dump file에 대해 read access, log file과 sql file에 대해 write access가 필요하다.

1.3.4. Data Pump File Naming and size

(1) DUMPFILE
- file list는 , 로 분리한다.
- %U template --> two-character, fix-width, 01부터 증가하는 integer 를 가진다.
- DUMPFILE 이 지정되어 있지 않으면 expdat.dmp 가 default로 사용된다. Default는 autoextensible이다.

(2) FILESIZE
- FILESIZE 가 지정되어 있으면 각 file은 FILESIZE안으로 만들어지고 늘어날 수 없다. dump 공간이 더 필요하고 template %U가 지정되었다면, 새로운 파일이 생성된다. 그렇치 않으면 사용자는 new file을 add하라는 메세지를 받는다.

(3) PARALLEL
- %U가 지정되면 PARALLEL parameter의 개수만큼 초기에 file이 생성된다.
- 기존에 존재하는 file과 이름이 중복될 경우 overwrite하지 않고 에러를 발생시키고 job이 abort된다.
- 복수개의 dump file template가 제공되면 round-robin fashion으로 dump file을 생성하는 데 사용한다.

1.3.5. Data Pump Filtering

(1) Find-grained object selection
- 기존의 exp/imp는 index, trigger, grant, constraint를 포함하거나 제외하는 것이 있으나
data pump는 virtually any type of object를 포함하거나 제외할 수 있다.
- EXCLUDE 와 IMCLUDE는 mutually exclusive 하다.
- INCLUDE = object_type[:"name_expr"]
- EXCLUDE = object_type[:"name_expt"]
- 모든 view, 모든 package, EMP로 시작하는 Index만 제외한다.
EXCLUDE=view
EXCLUDE=package
EXCLUDE=INDEX:"LIKE 'EMP%' "

(2) Data Selection
- CONTENT = ALL(def) | METADATA_ONLY | DATA_ONLY
- QUERY = [Schema.][table_name:]"query_clause"
- CONTENT에 data_only가 사용되면 EXCLUDE 와 INCLUDE를 사용할 수 없다.QUERY=hr.employees:"WHERE department_id in (10,20) and salary < 1600 ORDER BY department_id"
<--특정 table을 지정해서 해당 table로 한정. imp시에도 적용.

1.3.6. Data Pump Job Monitoring

- 데이터베이스 뷰에서 실행되는 Data Pump 작업에 관해서도 자세한 정보를 확인할 수 있다.
- DBA_DATAPUMP_JOBS – 작업에서 실행되는 작업자 프로세스(DEGREE 열)의 수를 확인 할 수 있다.
- DBA_DATAPUMP_SESSIONS –이전 뷰 및 V$SESSION과 조인하여 foreground 프로세스 세션의 SID확인 할 수 있다.

select sid, serial#
from v$session s, dba_datapump_sessions d
where s.saddr = d.saddr;


- V$SESSION_LONGOPS - 작업 완료에 걸리는 시간을 예측하는 또 다른 유용한 정보를 얻을 수 있다.

select sid, serial#, sofar, totalwork
from v$session_longops
where opname = 'CASES_EXPORT' and sofar != totalwork;

totalwork 열에는 총 작업량이 표시되는데, 이 중 현재까지 sofar 작업량을 완료했으므로 이를 통해 얼마나 더 시간이 걸릴지 예측할 수 있다.

1.3.7. Data Pump Export and Import

1) Parallel Full Export and Import

> expdp system/manager full=y parallel=4
dumpfile=DATADIR1:full1%U.dat,
DATADIR2:full2%U.dat,
DATADIR3:full3%U.dat,
DATADIR4:full4%U.dat
filesize=2G

<--4개의 work process를 가진 full export,
Pump file은 DATADIR1, DATADIR2, DATADIR3, DATADIR4 네 곳에 라운드로빈 방식으로 생성된다.
2G를 넘지 않으면서 최소4개 생성.
Job 과 master table 이름은 default로 SYSTEM_EXPORT_FULL_01 를 가진다.

>impdp system/manager directory= NET_STORGAE_1 parallel=4
dumpfile= full1%U.dat,
full2%U.dat,
full3%U.dat,
full4%U.dat

<--expdp로 받은 dump file을 network를 통해 NET_STORAGE_1 이라는 directory object위치로 보내졌다. Default import는 dump set 전체를 import하는 것이므로 Full=y 는 필요 없다.
Job 과 master table 이름은 default로 SYSTEM_IMPORT_FULL_01 를 가진다.

2) Limited Schema Export (fine-grained)

incluse=function include=procedure include=pacakge include=type include=view:"like 'PRODUCT%'"
> expdp system/manager schemas=hr,oe
directory=USR_DATA
dumpfile=schema_hr_oe.dat
parfile=exp_par.txt <----------------------------

<--HR, OE schema에서 모든 func, prod, pkg, user-defined type, PRODUCT로 시작하는 view를 export한다.
Schema definition과 system priv graints는 export되지 않는다.

> impdp system/manager directory=USR_DATA
dumpfile=schema_hr_oe.dat
sqlfile=schema_hr_oe.dat

<--실제 import는 하지 않고 dmp file에서 DDL 문장만 뽑아낸다.

3) Network Mode Import (DB Link)

network_link=finance.hq.com <--db link
remap_schema=payroll:finance

> impdp system/manager schemas=hr,sh,payroll
parfile=imp_par.txt <--------------------------------

<--Source DB에 dblink로 붙어서 hr, sh, payroll schema를 가져온 다음 imp 한다.
이때 payroll schema로 finance schema로 만들어 진다.
SYSTEM은 IMPORT_FULL_DATABASE role을 가지고 있고 Source DB에 대해서는 EXPORT_FULL_DATABASE role을 가지므로 Target DB에 해당 schema definition이 없으면 만들어진다.
flashback_time은 예전의 CONSISTENT와 동일하다.

4) Data-Only Unload

> expdp hr/hr parfile=exp_par.txt dumpfile=expdat.dmp content=data_only
include=table:"in ('DEPARTMENTS','DEPARTMENTS_HIST','EMPLOYEES','EMP_HIST')"
query="where DEPARTMENT_ID != 30 order by DEPARTMENT_ID"

1.3.8. Data Pump restarting

1) Attaching to Existing Job
> expdp system/manager attach=EXP_TS1


<--Job name(MT name) :dba_datapump_jobs
해당 스키마에 active export job 이 하나만 있을 경우 안 적어도 된다..

job: EXP_TS1
owner: SYSTEM
mode:
status:
Export> STOP_JOB
<--중지.
Attach session은 terminate 되고 실행되던 job은 controlled fashion으로 run down 된다.

해당 Job은 dump file과 SYSREM.EXP_TS1 table이 disturbed 되지 않는 한 startable 하다.

2) Restarting Stopped Job

> expdp system/manager attach=exp_ts1
<--같은 schema안에 여러 개의 outstanding job이 있으면 job name지정한다.

Export> parallel=4
Export> start_job
Export> status =600 <--10분

<-- detailed per-work process가 10분 단위로 regular status message를 보여준다.
KILL_JOB로 job을 kill한다.

<--status, status=600(초)
stop_job,
start_job,
continue_client: attach한 session이 계속 받아서 expdp 실행한다.(logging mode로 전환)
exit_client: Attach를 빠져 나옴. expdp는 background로 실행한다.

1.4. Data pump 실습

1.4.1. 전체 데이터베이스 export 실습

SQL> conn /as sysdba
연결되었습니다.

SQL> create directory dump as 'C:₩oracle/backup'; ->directory를 생성한다.

디렉토리가 생성되었습니다.
SQL> grant read ,write on directory dump to public; -> directory에 권한을 부여한다.

권한이 부여되었습니다.

SQL> host

Microsoft Windows XP [Version 5.1.2600]

(C) Copyright 1985-2001 Microsoft Corp.
C:₩oracle>expdp system/oracle dumpfile=full.dmp directory=dump full=y job_name=Lucie

Export: Release 10.2.0.1.0 - Production on 화요일, 29 5월, 2007 17:17:41

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

접속 대상: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the OLAP and Data Mining options
"SYSTEM"."LUCIE" 시작 중: system/******** dumpfile=full.dmp directory=dump full=y job_name=Lucie
BLOCKS 메소드를 사용하여 예측 진행 중...
객체 유형 DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA 처리 중
BLOCKS 메소드를 사용한 총 예측: 66.56 MB ->대략적인dmp파일 size를 예측할 수 있다.
객체 유형 DATABASE_EXPORT/TABLESPACE 처리 중
객체 유형 DATABASE_EXPORT/SYS_USER/USER 처리 중
객체 유형 DATABASE_EXPORT/SCHEMA/USER 처리 중
객체 유형 DATABASE_EXPORT/SCHEMA/TABLE/POST_INSTANCE/PROCDEPOBJ 처리 중

. . "SCOTT"."DEPT" 48.00 MB 2097152행이 엑스포트됨
. . "SYSMAN"."MGMT_JOB_CRED_PARAMS" 11.70 KB 18행이 엑스포트됨
. . "SYSMAN"."MGMT_JOB_PROP_PARAMS" 8.820 KB 12행이 엑스포트됨
. . "SYSMAN"."MGMT_JOB_STEP_PARAMS" 127.3 KB 1128행이 엑스포트됨

Control + c ->중간에 끊어도 job이 끊기지 않고 명령모드로 들어간다.

Export>status
작업: LUCIE
작업: EXPORT
모드: FULL
상태: EXECUTING
처리된 바이트: 50,337,376
완료율: 84 -> 진행률을 알 수 있다.
현재 병렬도: 1
작업 오류 수: 0
덤프 파일: C:₩ORACLE₩BACKUP₩FULL.DMP
기록된 바이트: 55,226,368

작업자 1 상태:
상태: EXECUTING
객체 스키마: SYSMAN
객체 이름: MGMT_JOB_EXECUTION
객체 유형: DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA

완료된 객체: 45
총 객체: 408
작업자 병렬도: 1

Export> stop_job -> job 을 정지시킨다.
이 작업을 정지하겠습니까([예]/아니오):

C:₩oracle>

C:₩oracle>sqlplus "/as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on 화 5월 29 17:32:59 2007

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

다음에 접속됨:

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the OLAP and Data Mining options

SQL>select owner_name,job_name,operation,job_mode,state from dba_datapump_jobs;
OWNER_NAME JOB_NAME OPERATION JOB_MODE STATE
---------- ---------- ------------ ----------- ------------
SYSTEM LUCIE EXPORT FULL NOT RUNNING
->job 상태를 확인할 수 있다.

SQL> exit

C:₩oracle>expdp system/oracle attach=lucie ->job을 다시 attach한다.

Export: Release 10.2.0.1.0 - Production on 화요일, 29 5월, 2007 17:35:54

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

접속 대상: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the OLAP and Data Mining options

작업: LUCIE
소유자: SYSTEM
작업: EXPORT
생성자 권한: FALSE
GUID: 18405C1B820C4ABB9B30C4948E0D356F
시작 시간: 화요일, 29 5월, 2007 17:35:56
모드: FULL
인스턴스: ora10
최대 병렬도: 1
EXPORT 작업 매개변수:
매개변수 이름 매개변수 값:
CLIENT_COMMAND system/******** dumpfile=full.dmp directory=dump full=y job_name=Lucie
상태: IDLING
처리된 바이트: 51,646,000
완료율: 99
현재 병렬도: 1
작업 오류 수: 0
덤프 파일: C:₩oracle/backup₩full.dmp
기록된 바이트: 55,914,496

작업자 1 상태:
상태: UNDEFINED

SQL>select owner_name,job_name,operation,job_mode,state from dba_datapump_jobs;
OWNER_NAME JOB_NAME OPERATION JOB_MODE STATE
---------- ---------- ------------ ----------- ------------
SYSTEM LUCIE EXPORT FULL IDLING
->job 상태를 확인할 수 있다.

Export> start_job ->Job을 다시restar한다.

Export> status

작업: LUCIE
작업: EXPORT
모드: FULL
상태: COMPLETING
처리된 바이트: 51,646,001
완료율: 100
현재 병렬도: 1
작업 오류 수: 0
덤프 파일: C:₩oracle/backup₩full.dmp
기록된 바이트: 64,684,032

작업자 1 상태:
상태: WORK WAITING

C:₩oracle>

Logfile 확인

지정한 directory 위치에 “export” log file을 확인 한다. 파일의 끝부분을 보면 성공적으로 완료됨을 확인할 수 있다.

"SYSTEM"."LUCIE" 작업이 17:18:56에서 사용자 요청에 의해 정지됨
LUCIE 작업이 화요일, 29 5월, 2007 17:35 에서 다시 열림 ->작업을 정지했다 다시 시작한 것을 확인 할 수 있음


"SYSTEM"."LUCIE" 재시작 중: system/******** dumpfile=full.dmp directory=dump full=y job_name=Lucie
마스터 테이블 "SYSTEM"."LUCIE"이(가) 성공적으로 로드됨/로드 취소됨
******************************************************************************
SYSTEM.LUCIE에 대해 설정된 덤프 파일:
C:₩oracle/backup₩full.dmp
"SYSTEM"."LUCIE" 작업이 17:37:12에서 성공적으로 완료됨

1.4.2. 특정 스키마 DDL 스크립트 생성 실습

SQL> conn /as sysdba
연결되었습니다.


SQL> create directory dump as 'C:₩oracle/backup'; ->directory를 생성한다.
디렉토리가 생성되었습니다.

SQL> grant read ,write on directory dump to public; -> directory에 권한을 부여한다.
C:₩oracle>impdp system/oracle directory=dump dumpfile=full.dmp schemas=scott sqlfile=ddl_scott.sql
<이 명령은 dump로 지정된 디렉터리에 ddl_scott.sql로 명명된 파일을 생성하며 엑스포트 덤프 파일 내의 객체 스크립트를 생성한다.>


Import: Release 10.2.0.1.0 - Production on 화요일, 29 5월, 2007 19:12:13

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

접속 대상: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the OLAP and Data Mining options
마스터 테이블 "SYSTEM"."SYS_SQL_FILE_SCHEMA_01"이(가) 성공적으로 로드됨/로드 취소됨


"SYSTEM"."SYS_SQL_FILE_SCHEMA_01" 시작 중: system/******** directory=dump dumpfile=full.dmp schemas=
scott sqlfile=ddl_scott.sql
객체 유형 DATABASE_EXPORT/SCHEMA/USER 처리 중
객체 유형 DATABASE_EXPORT/SCHEMA/GRANT/SYSTEM_GRANT 처리 중
객체 유형 DATABASE_EXPORT/SCHEMA/ROLE_GRANT 처리 중
객체 유형 DATABASE_EXPORT/SCHEMA/DEFAULT_ROLE 처리 중
객체 유형 DATABASE_EXPORT/SCHEMA/PROCACT_SCHEMA 처리 중
객체 유형 DATABASE_EXPORT/SCHEMA/TABLE/TABLE 처리 중
객체 유형 DATABASE_EXPORT/SCHEMA/TABLE/STATISTICS/TABLE_STATISTICS 처리 중
"SYSTEM"."SYS_SQL_FILE_SCHEMA_01" 작업이 19:12:22에서 성공적으로 완료됨

Logfile 확인

- dump로 지정된 C:₩oracle/backup에 ddl_scoot.sql파일이 생성된다.

-- CONNECT SYSTEM
-- new object type path is: DATABASE_EXPORT/SCHEMA/USER
CREATE USER "SCOTT" IDENTIFIED BY VALUES 'F894844C34402B67'
DEFAULT TABLESPACE "USERS"
TEMPORARY TABLESPACE "TEMP";
-- new object type path is: DATABASE_EXPORT/SCHEMA/GRANT/SYSTEM_GRANT
GRANT UNLIMITED TABLESPACE TO "SCOTT";
GRANT CREATE SESSION TO "SCOTT";
-- new object type path is: DATABASE_EXPORT/SCHEMA/ROLE_GRANT
GRANT "RESOURCE" TO "SCOTT";
-- new object type path is: DATABASE_EXPORT/SCHEMA/DEFAULT_ROLE
ALTER USER "SCOTT" DEFAULT ROLE ALL;
-- new object type path is: DATABASE_EXPORT/SCHEMA/PROCACT_SCHEMA
-- CONNECT SCOTT
BEGIN
sys.dbms_logrep_imp.instantiate_schema(schema_name=>SYS_CONTEXT('USERENV','CURRENT_SCHEMA'), export_db_name=>'ORA10', inst_scn=>'283762');
COMMIT;
END;
/
-- new object type path is: DATABASE_EXPORT/SCHEMA/TABLE/TABLE

-- CONNECT SYSTEM
CREATE TABLE "SCOTT"."EMP"
( "EMPNO" NUMBER(4,0) NOT NULL ENABLE,
"ENAME" VARCHAR2(10),
"JOB" VARCHAR2(9),
"MGR" NUMBER(4,0),
"HIREDATE" DATE,
"SAL" NUMBER(7,2),
"COMM" NUMBER(7,2),
"DEPTNO" NUMBER(2,0)
) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "USERS" ;
CREATE TABLE "SCOTT"."DEPT"
( "DEPTNO" NUMBER(2,0),
"DNAME" VARCHAR2(14),
"LOC" VARCHAR2(13)
) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "USERS" ;

1.4.3. 존재하는 table import

1) content=data_only 포함한 경우

C:₩oracle>Impdp system/oracle dumpfile=full.dmp directory= dump content=data_only job_name=data_import logfile=table_log tables=scott.dept

Import: Release 10.2.0.1.0 - Production on 화요일, 29 5월, 2007 19:42:15

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

접속 대상: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the OLAP and Data Mining options
마스터 테이블 "SYSTEM"."DATA_IMPORT"이(가) 성공적으로 로드됨/로드 취소됨
"SYSTEM"."DATA_IMPORT" 시작 중: system/******** dumpfile=full.dmp directory= dump content=data_only
job_name=data_import logfile=table_log tables=scott.dept
객체 유형 DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA 처리 중
. . "SCOTT"."DEPT" 48.00 MB 2097152행이 임포트됨
"SYSTEM"."DATA_IMPORT" 작업이 19:42:52에서 성공적으로 완료됨

2) content=data_only 포함하지 않은 경우

C:₩oracle>Impdp system/oracle dumpfile=full.dmp directory= dump job_name=data_import logfile=table_log tables=scott.dept

Import: Release 10.2.0.1.0 - Production on 화요일, 29 5월, 2007 19:41:02

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

접속 대상: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the OLAP and Data Mining options
마스터 테이블 "SYSTEM"."DATA_IMPORT"이(가) 성공적으로 로드됨/로드 취소됨
"SYSTEM"."DATA_IMPORT" 시작 중: system/******** dumpfile=full.dmp directory= dump job_name=data_impo
rt logfile=table_log tables=scott.dept
객체 유형 DATABASE_EXPORT/SCHEMA/TABLE/TABLE 처리 중
ORA-39151: "SCOTT"."DEPT" 테이블이 존재합니다. 건너 뛰기 table_exists_action으로 인해 모든 종속 메타 데이터 및 데이터를 건너 뜁니다.
객체 유형 DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA 처리 중
객체 유형 DATABASE_EXPORT/SCHEMA/TABLE/STATISTICS/TABLE_STATISTICS 처리 중
"SYSTEM"."DATA_IMPORT" 작업이 1 오류와 함께 19:41:09에서 완료됨
* 임포트 프로세스의 기본 작업 방식은 테이블 및 연관된 모든 객체를 생성하고 테이블이 있는 상태에서 오류를 만들어 낸다.

* 임포트 프로세스의 기본 작업 방식은 테이블 및 연관된 모든 객체를 생성하고 테이블이 있는 상태에서 오류를 만들어 낸다.

다음 명령은 대화형 모드에서 적합합니다.
참고: 약어도 허용됨

다음 명령은 대화형 모드에서 적합합니다.
참고: 약어도 허용됨

Posted by redkite
, |

최근에 달린 댓글

최근에 받은 트랙백

글 보관함