블로그 이미지
redkite

카테고리

분류 전체보기 (291)
00.SI프로젝트 산출물 (0)
00.센터 운영 문서 (0)
01.DBMS ============.. (0)
01.오라클 (117)
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.5
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 31

공지사항

최근에 올라온 글

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

최근에 달린 댓글

최근에 받은 트랙백

글 보관함