O10g data control_10

http://www.ggola.com 장 경 상

3. Data Control & Management.................................................................3-3

3.1. External Table...........................................................................3-4

3.1.1. New External Table...............................................................3-4

3.1.2. External Table Access Driver................................................3-4

3.1.2.1......................................................................ORACLE_LOADER

3-4

3.1.2.2..................................................................ORACLE_DATAPUMP

3-4

3.1.3. Example...............................................................................3-5

3.2. DataPump.................................................................................3-9

3.2.1. DataPump 개요.....................................................................3-9

3.2.2. DataPump Architecture(구조)...............................................3-9

3.2.3. Unload(datapump export), Load(datapump import)...........3-10

3.2.4. Datapump 이점...................................................................3-11

3.2.5. Datapump 처리 절차............................................................3-12

3.2.6. Direct Path 와 External Table..............................................3-13

3.2.7. DataPump File....................................................................3-14

3.2.7.1............................................DataPump에 사용되는 3개의 Files

3-14

3.2.7.2.....................................................................Directory 우선순위

3-14

3.2.7.3.......................................................................Dump File의 속성

3-15

3.2.8. DataPump Usage................................................................3-16

3.2.8.1..........................................................................................Mode

3-16

3.2.8.2......................................................................................Filtering

3-16

3.2.8.3.............................................................Import Existing Object

3-17

3.2.8.4..............................................Load Data With Transformation

3-17

3.2.8.5.................................................................................Monitoring

3-18

3.2.9. Example.............................................................................3-19

[email protected] 1


3.2.10...................................................................................Network Mode

3-38

3.2.11..............................................................................비정상 종료의 처리

3-42

3.3. New Cluster Features..............................................................3-46

3.3.1. Clustering 개요....................................................................3-46

3.3.1.1.......................................................................................Cluster

3-46

3.3.1.2..............................................................................Hash Cluster

3-46

3.3.2. Sorted-Hash Cluster...........................................................3-51

3.3.2.1.............................................................................................개요

3-51

3.3.2.2.....................................................................................Example

3-51

3.3.2.3.................................................................................주의할 점들

3-54

3.4. Tablespaces.............................................................................3-56

3.4.1. User Default Tablespace (Default Permanent Tablespace). 3-56

3.4.2. Rename Tablespace............................................................3-58

3.4.3. SYSAUX Tablespace............................................................3-62

3.4.4. Transportable Tablespace...................................................3-64

3.4.4.1.............................................................................................개요

3-64

3.4.4.2.....................................................................................기본 조건

3-64

3.4.4.3..........................................................................Endian Format

3-66

3.4.4.4..................................................이 기종간 tablespace 이동절차

3-68

3.4.5. Big File Tablespace.............................................................3-78

3.4.5.1......................................Bigfile Tablespace의 주요 특징과 속성

3-78

3.4.5.2.........................................................Bigfile Tablespace의 이점

3-79

[email protected] 2


3.4.5.3.........................Create and Alter Tablespace with New Type

3-80

3.4.5.4.............................................Management Bigfile Tablespace

3-82

3.4.5.5.......................................................Bigfile Tablespace ROWID

3-83

3.4.6. Temporary Tablespace Group.............................................3-85

3.5. Files.........................................................................................3-91

3.5.1. File Copy.............................................................................3-91

3.5.1.1..........................................................................Local File Copy

3-91

3.5.1.2......................................................................Remote File Copy

3-95

3.5.1.3............................................................Oracle의 File Copy 속성

3-96

3.5.2. Redo Log File Size...............................................................3-97

3.6. LOB.......................................................................................3-103

3.6.1. LOB Size Limit..................................................................3-103

3.6.2. Implicit LOB Conversion...................................................3-103

3.7. Segments..............................................................................3-107

3.7.1. Maxtrans 삭제...................................................................3-107

3.7.2. Example...........................................................................3-107

[email protected] 3


3. Data Control & Management

여기서는 oracle10g부터 새롭게 추가되거나 변경된 data를 조작하는 기능들 (예를

들어 data와 database간의 관계나 datatype과 관련한 부분들)과 data의

관리차원에서 변경되거나 새로운 부분들(예를 들어 tablespace나 datafile등과

관련한 변화들)에 대하여 이야기를 할 것이다.

[email protected] 4


3.1. External Table

3.1.1.New External Table

이미 oracle9i(ORACLE_LOADER)에서 외부 file을 읽어 들여서 마치 table처럼

사용할 수 있도록 해준 이 기능은 사실 read-only라는 한계를 분명히 가지고 있었다.

이제 oracle10g(ORACLE_DATAPUMP)부터는 write가 가능해졌다. 몰론, Direct

Path API를 이용하여 “create table as select”구문으로도 write가 가능해 졌으며

platform에 상관없이 대량의 data를 flat files로 변화하고 또한 이를 대상 시스템으로

load하는 등의 작업에 매우 유용하다. 여기에는 두 가지 access driver가 사용되는데

SQL*Loader와 같은 ORACLE_LOADER driver(oracle9i)와 datapump API를 직접

사용하는 datapump와 같은 ORACLE_DATAPUMP driver가 그것이다.

CF. 사실 oracle10g에서 새로 추가된 external table type중 oracle_datapump는

내부적은 datapump access driver를 사용하는데 이 내용들은 다음 장에서 다룬다.

여기서는 기능위주로만 볼 것이며 새롭게 추가된 oracle_datapump를 다루게 될

것이다.

CF. 이 기능은 ETL에 매우 유용할 수 있지만 복잡한 형태의 모든 ETL에 다 적용될 수는

없다. (복잡한 source table의 join결과는 manually 만든 external table로 unload

하게 된다)

3.1.2.External Table Access Driver

3.1.2.1. ORACLE_LOADER

기존의(oracle9i) external 방식을 뜻하며 “create table…… organization external

… type ORACLE_LOADER….” 형식으로 구현한다. 이미 만들어진 files을 directory

와 location을 지정함으로써 SQL table처럼 사용하는 방식이다.

3.1.2.2. ORACLE_DATAPUMP

1. 이 기능이 oracle10g에서 소개하는 것이다. 다음 장에서 배울 datapump 기능이

들어가있는 것으로 전통적인 방식인 file로부터 table을 만드는 것이 아니라 table을

file로 write하면서 만들 수 있다. 다음과 같이 sub-query를 이용하여 “create

table…… organization external … type ORACLE_DATAPUMP…. as select …..”

만들어질 files을 directory와 location을 통해 지정한다. 물론, 이렇게 만들어진

datafiles은(dumpfile) 타 database(혹은 동일 database)에서metadata가 동일한

다른 external table의datafiles로 충분히 사용될 수 있지만 반드시 access driver

로서 “ORACLE_DATAPUMP”를 사용해야 한다.

[email protected] 5


CF. 여기서 write를 할 수 있다는 의미는 위와 같이 files을 만든다는 의미일 뿐임으로

추후에 rows의 DML이나 index작업과 같은 write는 불가하다.

2. 성능의 향상을 위해 parallel option으로 multiple files을 생성하여 external

table작업을 진행할 수도 있다. 단, 이 경우 parallel degree와 location의 files의

수는 일치해야 하며 files이 더 많으면 남는 files은 무시되고 degree가 더 많으면

degree를 location의 files수 만큼 줄여서 작업을 진행한다.

CF. 다른 external table로 만들어진 files을 또 다른 external table의 datafile로

사용할 때에는 별다른 조치 없이 해당 file을 directory와 location으로 지정하되

driver type으로 oracle_datapump를 지정하고 “as select …” 구문을 제거하면 된다.

3.1.3.Example

다음은 이미 만들어 놓은 1백만 건의 특정 table을 이용하여 external table을 만드는

과정이다. 먼저 directory 및 권한을 설정한 후 작업을 진행한다.

[NEWSVC]LIRACLE:/app/oracle> cd oradata

[NEWSVC]LIRACLE:/app/oracle/oradata> mkdir oraext

[NEWSVC]LIRACLE:/app/oracle/oradata> cd oraext

[NEWSVC]LIRACLE:/app/oracle/oradata/oraext> sqlplus system/manager

SQL*Plus: Release 10.1.0.4.0 - Production on Thu Jun 30 11:27:03 2005

Copyright (c) 1982, 2005, Oracle. All rights reserved.

Connected to:

Oracle Database 10g Enterprise Edition Release 10.1.0.4.0 - Production

With the Partitioning, OLAP and Data Mining options

SQL> create directory dirext as '/app/oracle/oradata/oraext';

Directory created.

SQL> grant read, write on directory dirext to public;

Grant succeeded.

[email protected] 6


SQL> conn scott/tiger

Connected.

SQL> select count(*) from se_nabip;

COUNT(*)

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

1000000

SQL> create table x_ext_nabip organization external

2 (type oracle_datapump default directory dirext

3 location ('ext_nab1.dmp', 'ext_nab2.dmp', 'ext_nab3.dmp'))

4 parallel 3

5 as select * from se_nabip;

Table created.

SQL> select count(*) from x_ext_nabip;

COUNT(*)

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

1000000

SQL> exit

Disconnected from Oracle Database 10g Enterprise Edition Release

10.1.0.4.0 - Production


[NEWSVC]LIRACLE:/app/oracle/oradata/oraext> ls -ltr

total 148772

-rw-r----- 1 oracle dba 51286016 Jun 30 13:08 ext_nab2.dmp



-rw-r--r-- 1 oracle dba 82 Jun 30 13:09 X_EXT_NABIP_16237.log



[email protected] 7



[NEWSVC]LIRACLE:/app/oracle/oradata/oraext>

성능향상을 위해 parallel degree 3을 주어 작업을 진행했으며 결과적으로 dumpfile

3개와 log files이 생성되었음을 알 수 있다.

[email protected] 8


OCP point

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

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

1. oracle_datapump driver를 사용하는 external table의 parallel option과 files

수의 관계에 대한 이해

참조

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

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

external table : o9i 188p

DML : Data Manipulation Language (insert, update, delete등 data조작 SQL)

[email protected] 9


3.2. DataPump

3.2.1.DataPump 개요현재까지 대부분의 data 이동 작업 또는 단순한 table의 data나 구조의 보관을 위해

export & import utility를 사용해왔다. 아시다시피 그 속도는 data의 양에 따라 큰

차이를 보이며 import의 경우 그 속도가 현저히 늦어서(dump files 개개의 row data

를 일일이 insert함으로) 많은 불만이 있었던 것도 사실이다. 이제 oracle10g에서

새롭게 소개되는 datapump기능은 그 불만을 상당부분 잠재우게 된다.

Datapump는 export, import 전체 process 구성을 나타내며 SQL이 아닌 API를 통해

빠른 속도로 data를 load, unload할 수 있다. 또한 기존의 export, import에서

제공하지 않았던 procedure와 같은 특정 유형의 objects만을 load, unload할 수 있게

되었다. DBMS_DATAPUMP package를 사용하며 command line에서는 기존의 “exp

& imp”처럼 “expdp & impdp”라는 client command를 제공한다.

CF. oracle10g부터는 data를 받고 이식하는 작업들을 load, unload라 표현한다.

3.2.2.DataPump Architecture(구조)

1. Direct Path API(DPAPI) : data의 load, unload시에 data의 변형이나 parsing

time을 최소화 하기 위해 direct path로 API를 call해서 사용할 수 있도록 interface를

제공한다.

[email protected] 10

그림 3-1

Datapump Architecture


2. External table API : oracle9i에서 제공이 되는 external table read를 위해

제공하는 oracle_loader driver와 external table의 read/write를 제공하는

oracle_datapump driver를 사용한다.

3. Metadata API : 이미 oracle9i에서 새로운 기능으로 metadata를 추출하는 API를

사용한다. DBMS_METADATA package를 통해 모든 load, unload대상의 object

정의를 처리한다.

4. DBMS_DATAPUMP : bulk data를 빠른 속도로 export/import하고 metadata를

이동하는 package를 사용한다.

5. SQL*Loader : 기존의 SQL*Loader는 external table로 통합되고 loader control

file은 external table의 access parameter로 자동으로 변경된다.

6. expdp, impdp : datapump 작업을 초기화 하고 모니터링을 하는

DBMS_DATAPUMP를 call하는 역할을 한다.

7. Other Clients : 기존의 export, import와 달리 DPAPI인 DBMS_DATAPUMP

package를 사용함으로 SQL*Plus와 같은 client나 user application에서도 이 기능을

사용할 수 있게 되었다. 차차 설명이 되겠지만 datapump는 client가 아닌 server에

있는 file을 이용하기 때문에 가능한 것이라 생각된다.

3.2.3.Unload(datapump export), Load(datapump import)

아래 그림은 datapump를 이용한 unload, load를 단순화 시킨 개념도이다.

datapump export는 unload 대상이 되는 data(이하 metadata포함)를

server상의(operating system) file set로 unload하며 이때에 이 file구조를 “dump

file sets”라 한다. 반대로 datapump import는 이 dump file sets을 대상

시스템으로 data를 load하는데 사용된다.


그림 3-2

Load, Unload 상관도


따라서 이런 구조적인 기능으로 remote database에 대하여 즉, 원격

데이터베이스에서 dump file set으로 export하거나 원격 데이터베이스로 dump file

set의 data를 load하는 것도 가능하다. 이를 network mode라 표현하는데 이 기능은

read-only source database를(특정한 목적으로 data source를 가지고 읽기만을

허용하는 database) 운영하는 경우 data를 export하는데 매우 유용할 수 있을 것이다.

이런 일련의 datapump operation의 중심에는 “Master Table”(이하 MT)이라는 것이

존재한다. 사실 이 table이 모든 datapump job을 관리하게 된다. 이 MT는 export

job이 수행되는 동안 작업관리를 위해 만들어지고 마지막에 dump file set에 write

된다. 그러므로 import시에는 제일 먼저 이 MT가 현재 작업을 하는 schema로 load

되고 import되는 모든 objects의 순서를 관리하게 된다. 따라서 이러한 MT의 속성을

통해 우리는 예측하지 못한 또는 어쩔 수 없이 중단된 datapump작업을 나중에 다시

재개하는데 문제가 없도록 해준다.

CF. network mode 즉, database link를 이용하여 data pump작업 시 network_link

parameter를 사용하는 경우 load작업은(import) dumpfile을 사용하지 않는다. 직접

source database에 database link를 통해 연결 후 data를 읽어서 바로 load시키는

과정으로 이루어진다.

CF. 과거 상당히 진행이 이루어진 import가 중단될 때에 재 작업의 불편함을

생각해보면 “Master Table”의 역할은 매우 효과적일 것으로 생각된다.

CF. 기존의 export & import와는 별도의 features임으로 현재도 oracle10g에서 exp

& imp command는 유효함을 잊지 말자.

3.2.4.Datapump 이점1. datapump는 어떤 방식으로 data를 access할 것인가를 스스로 결정한다. 따라서

사용자가 access유형에 대한 걱정을 할 필요가 없다. 앞서 datapump architecture

에서 설명한 direct path 방식과 external table 방식 중에서 적절한 선택을 해준다.

2. 현재 datapump 작업이 이루어지고 있는 동안에도 작업에 아무런 영향을 주지 않고

작업을 추가하거나 제거할 수 있으며 작업이 중단되는 어떤 경우라도 data loss없이 재

작업이 가능하다.

3. object의 유형에 상관없이 data를 unload, load할 수 있다. 즉, procedure와 같은

유형의 object만 따로 작업할 수 있다. 이를 fine-grained object selection이라

표현하며 “EXCLUDE, INCLUDE, CONTENT”와 같은 parameter를 사용하게 된다.

4. dump file set을 만들 때 명시적으로 database version을 지정함으로써 이전



version의 database와 호환이 되도록 할 수 있다. “VERSION” parameter를

사용한다.

5. 보다 향상된 작업 성능을 위해 parallel 작업이 가능하도록 할 수 있다. enterprise

edition를 install하는 경우에 한해 가능하며 “PARALLEL” parameter를 사용한다.

6. 실제 작업을 하기 전에 가용 space를 확인하기 위하여 실제로 필요한 space를

예측하는 기능을 제공한다. “ESTIMATE_ONLY” parameter를 사용한다.

7. remote database와의 datapump작업을 위해 dump file set의 이동 없이

network mode를 제공한다.

8. import가 진행되는 동안에도 target datafile name, schema 그리고 tablespace

도 변경할 수 있다. 이는 object metadata가 XML로 dump file set에 저장이 되기

때문에 상대적으로 쉽게 이루어질 수 있는 것이다.

CF. oracle10g release 2에서는 성능이 더욱 더 향상된다.

3.2.5.Datapump 처리 절차아래 그림은 datapump의 일반적인 작업 흐름도이다.


그림 3-3

Datapump 작업구조


1. 최초 client가 database에 login을 하면 datapump API를 담당할 shadow

process가 생성된다. 이 때에 “DBMS_DATAPUMP.OPEN”을 call하고 다음의

creation 작업을 바로 실시하여 master table(MT), 상태, 에러 등의 정보를 담는 Q와

새로 만들어지는 work process를 control하는 Q, master control process(MCP)를

생성한다. 그리고 나서 shadow process는 주로 client로부터의 GET_STATUS

request를 처리하게 된다.

2. MCP는 datapump job의 순서 및 수행을 조절하고 job의 상태, 내용, 재 시작 등과

dump file의 정보 등에 대하여 유지보수 하는 역할을 담당하게 된다. 이 때에 MCP는

(DMnn)의 이름으로 생성된다.

3. MCP는 START_JOB request를 받음과 동시에 worker processes를 생성하는데

parameter로 설정된 “PARALLEL”의 값에 따라 그 수를 조절하게 되고 이 worker

process는 MCP의 요청에 따라 unloading, loading 작업을 수행한다.

4. 일단 작업이 수행되면 최초 caller client가 아닌 다른 client도 이 datapump job에

대하여 monitor, detach 및 attach등의 부가 작업을 진행할 수 있다.

5. 만일 datapump가 external table path를 선택했다면 위 그림처럼 work process

는 unload 또는 load의 할당 양에 따라 parallel sever process의 수를 coordinate

하는 역할을 담당한다.

3.2.6.Direct Path 와 External Table

앞서 설명에서 datapump는 direct path 방식이나 external table 방식을

사용한다고 했다. 또한 그 선택은 datapump 스스로 가장 적절한 방식을 자동선택

한다고도 했다. 그렇다면 어떤 기준에 의해서 그 선택이 이루어 지는가! 자동이라고

해도 어떤 기준이 있어 그것에 부합하는가 안 하는가를 판단하는 것은 당연한 일일

것이다.

다음은 datapump가 external 방식을 선택하게 되는 경우들을 나타내고 있다. 이

조건들 중 하나라도 만족하면 external 방식을 선택하게 된다.

1. oracle8i에서 소개되어 oracle9i에서 보다 강화된 security policy를 제공하는

find-grained access control이 select 나 insert에 대하여 적용이 되어 있는 table

2. Lob column을 가진 domain index

3. Cluster table

4. Active trigger가 있는 table

5. Single partition을 load하는 해당 partitioned table에 global index가 있는 경우

6. BFILE 이나 opaque type column

7. Referential integrity constraint가 있을 때



8. VARRAY column이 opaque type을 embedding할 때

9. encrypted column을 가진 table

10. load시에 대상 table의 partitioning이 unload했을 때와 달라진 경우

CF. datapump작업이 어떤 방법으로 unload가 되던지 간에 다시 load될 때 꼭 동일한

방식으로 load될 필요는 없다. 즉, unload와 load의 방식이 항상 같은 방식을 취해야

한다는 조건은 없다.

3.2.7.DataPump File

3.2.7.1. DataPump에 사용되는 3개의 Files

앞서 설명한 바와 같이 datapump는 server-based 작업 이기 때문에 관련 files도

모두 server상에 존재한다. 따라서 이들 files을 access하기 위해 oracle은 directory

object를 사용한다. 이는 server상의 OS directory가 아니라 oracle의 directory

object를 말한다. 또한 보안상의 이유로 절대경로를 사용하지 않도록 하고 있다.

이런 directory로 관리하는 files은 다음과 같다.

1. dump files : data를 담고 있다. (앞서 설명한 바와 같이 metadata를 포함한다)

2. log files : 작업과 관련한 messages를 기록한다.

3. SQL files : SQLFILE로 지정한 file에 import 대상의 SQL DDL script를 생성한다.

CF. 지금 설명하는 내용들은 server상에서 이루어지는 작업임으로 기본적으로 access

하려는 directory의 O/S permission은 이미 부여 받았다는 전제하에서 기술되고 있다.

3.2.7.2. Directory 우선순위이들 files을 찾아가는 순서는 다음과 같은 우선순위에 의해 결정된다.

1. file의 이름을 설정할 때 각 file마다 directory를 지정하는 경우(directory object와

file name은 “:”으로 구분한다)

$ expdp scott/tiger DUMPFILE=my_dir:expdp_scott.dmp NOLOGFILE=Y

2. “DIRECTORY” parameter를 사용하여 directory object 이름을 지정하는 경우

$ expdp scott/tiger DIRECTORY=my_dir DUMPFILE=expdp_scott.dmp

LOGFILE=my_dir_log:expdp_scott.log

3. 작업자의 환경변수 “DATA_PUPM_DIR”에 설정된 directory값을 사용하는 경우

$ export DATA_PUMP_DIR=MY_DIR

$ expdp scott/tiger DUMPFILE=expdp_scott.dmp

LOGFILE=my_dir_log:expdp_scott.log



CF. 환경변수 DATA_PUMP_DIR의 값은 case sensitive(대소문자구분)함으로

유의해야 하며 현재 환경이 windows라면 export 대신 set command를 사용하여

환경을 설정한다.

4. 위 조건을 모두 만족하지 않을 때 해당 user가 적절한 권한을 가지고 있는 경우에

한해 default directory가 사용된다. (권한의 예. EXP_FULL_DATABASE,

IMP_FULL_DATABASE)

CF. 단, default directory는 사전에 DBA가 만들어 놓아서 해당 권한을 부여 해야만

사용할 수 있다.

SQL> CREATE OR REPLACE DIRECTORY data_pump_dir AS '/usr/temp';

SQL> GRANT read, write ON DIRECTORY data_pump_dir TO scott;

$ expdp system/manager DUMPFILE=expdp_scott.dmp

LOGFILE=expdp_scott.log SCHEMAS=scott

3.2.7.3. Dump File의 속성1. file naming : dump file은 하나 이상의 file set으로 구성될 수 있음으로 몇 가지

형식을 갖는다. “DUMPFILE” parameter를 사용하여 (directory.)file을 지정할 수

있으며 또는 여러 개의 dump file을 지정하기 위하여 “,”로 구분된 file lists로 기술할

수도 있고 또는 각각 “DUMPFILE” parameter를 따로 지정할 수도 있다.

Dump file이 복수의 file set으로 구성이 될 때엔 template “%U”를 지정할 수 있는데

이 값은 dump file이름에서 두 개의 문자로 구성된 숫자로 치환되며 그 값은 “01”부터

순차적으로 증가한다.

CF. 아무것도 지정하지 않을 경우엔 default로 “expdat.dmp”로 설정된다. (과거

export를 할 때도 default는 이 이름이었다)

2. file sizing : “FILESIZE” parameter를 사용하여 그 사이즈를 지정하면(byte) 해당

file은 이 크기로 생성된다. 그러나 이 경우 해당 file은 자동적으로 지정된 크기

이상으로 확장되지 않기 때문에 앞서 이야기한 “%U” template을 함께 사용하여

자동으로 file의 수를 증가시키는 것이 좋다. 만일, 이 template도 사용하지 않았고

해당 file의 크기가 parameter값만큼 커지게 되면 client는 새로운 file을 추가하도록

메시지를 받게 된다.

3. file counting : template “%U”를 지정했다면 dump file의 수는 최초엔

“PARALLEL” parameter의 값 만큼 생성된다. 또한 dump file은 overwrite를 하지

않기 때문에 동일한 이름의 file이 존재하면 error를 발생시키고 작업을 중단한다.

CF. 여러 개의 dump file template을 지정할 수도 있는데 이 경우엔 round-robin



방식으로 결정된다. 예를 들어 template을 사용하여 다음과 같이 “expdpA%U.dmp,

expdpB%U.dmp, expdpC%U.dmp”로 설정하였고 PARALLEL을 3개로 설정했다면

최초엔 “expdpA01.dmp, expdpB01.dmp, expdpC01.dmp”로 설정되고 더 file이

필요하게 되면 “expdpA02.dmp, expdpB02.dmp, expdpC02.dmp”로 추가된다.

3.2.8.DataPump Usage

3.2.8.1. Mode

Datapump를 사용하여 data의 이동 시 사용할 수 있는 mode는 과거 export &

import와 비교해서 크게 달라지진 않았지만 기능상의 확장 측면은 있다.

1. Full (EXP_FULL_DATABASE role 권한)

2. Schema ( 1의 권한 또는 자기 자신만의 schema)

3. Table (2의 권한과 동일)

4. Tablespace (EXP_FULL_DATABASE role 권한)

5. Transportable tablespace (EXP_FULL_DATABASE role 권한)

CF. transportable tablespace mode로 작업 시 한 번 중단되면 다시 시작될 수 없고

1 보다 큰 parallel degree도 사용할 수 없다.

3.2.8.2. Filtering

기존의 export & import는 index, trigger, grant, constraint만을 include하거나

ignore할 수 있었지만 이제 datapump는 어떤 유형의 object도 exclude, include할

수 있다.

1. fine-grained object selection : EXCLUDE, INCLUDE parameter를 사용하여

유형을 정의하거나 동시에 “:”를 사용하여 object name도 제어할 수 있다. 다음의

예는 “FUNCTION”을 제외하고 또한 INDEX 중에서 “DEPT”로 시작하는 모든 것을

제외시킨다.

EXCLUDE=FUNCTION

EXCLUDE=INDEX:”LIKE ‘DEPT%’”

CF. 위의 예에서 EXCLUDE를 INCLUDE로 가정하고 FULL mode로 export한다면 모든

“FUNCTION”과 “DEPT”로 시작하는 INDEX만을 unload할 것이다.

2. data selection : “CONTENT” parameter를 사용하여 “ALL, METADATA_ONLY,

DATA_ONLY”를 설정할 수 있고 “QUERY” parameter를 사용하여 필요한 조건을 충족

시키는 data만을 처리할 수 있다.

CONTENT= ALL 모든 data

METADATA_ONLY object definition만



DATA_ONLY definition없이 data만

QUERY=schema.table:”where 조건절”

CF. QUERY parameter는 과거 export 기능에도 존재했었지만 datapump는 table

명을 지정할 수도 있고 load시에도 사용이 가능하도록 확장되었다.

3.2.8.3. Import Existing Object

새로 구현된 datapump는 기 존재하는 object에 대하여 다양한 방식의 import

option을 제공한다.

TABLE_EXISTS_ACTION={SKIP | APPEND | TRUNCATE | REPLACE}

물론, default는 skip이어서 이미 존재하면 import하지 않는 것을 원칙으로 한다.

하지만 바로 앞에서 보았듯 parameter content를 사용하고 “DATA_ONLY”를

설정하였다면 이 때에는 default가 “APPEND”로 바뀌어진다.

1. SKIP : 기 존재하는 object는 import하지 않는다.

2. APPEND : 현재 존재하는 rows는 그대로 두고 dumpfile의 rows를 import한다.

3. TRUNCATE : 현재 존재하는 rows는 delete하고 dumpfile의 rows를 import한다.

4. REPLACE : 현재 존재하는 table을 drop한 후 dumpfile로부터 table을 생성하고

rows를 import한다.

다음은 이들 option을 사용할 때에 주의사항이다.

1. TRUNCATE, REPLACE : 이 option을 사용할 때에는 referential constraints에

의해 제약을 받고 있지 않은가를 확인한다. 필요하다면 현재의 constraint를 disable한

후 load가 끝나고 enable작업을 다시 하도록 한다.

2. SKIP, APPEND, TRUNCATE : 존재하는 table에 dependent한 objects는

무시된다. (EX. index, grants, trigger, constraints) 그러나 REPLACE를 사용하면

EXCLUDE등으로 dependent objects를 제외하지 않고 그 objects가 dumpfile에

있는 한 완전히 새로 재 생성 된다.

3. APPEND : 사실 이 option을 사용하면 load되는 data는 현재 object내에 존재하는

space를 재사용하지 않고 새로운 space를 할당 받아 import를 진행한다. (당연히

전통적인 insert 방식의 import보다 빠른 이유중의 하나라 할 것이다. 하지만 반대로

table의 fragmentation이 이미 많다면 data load전에 이를 처리하거나 또는 나중에

table 재 구성에 대한 고려사항의 하나로 이런 부분들을 기억해 둘 필요가 있다.)

CF. 단, TRUNCATE option은 clustering table 및 network link를 통하는 경우

사용할 수 없다.



3.2.8.4. Load Data With Transformation

datapump import는 몇 가지 변형을 통한 loading이 가능하다.

1. datafile 변경 : load시 다른 platform간의 이동이나 위치의 변경이 필요한 경우

datafile의 이름을 바꾸는 것이 가능하다. 물론, “IMP_FULL_DATABASE” 권한이 있는

경우에 한한다.

REMAP_DATAFILE= ‘C:\DATA\users01.dbf’:’/u01/data/user01.dbf’

2. tablespace 변경 : load시 원 tablespace에서 다른 tablespace로의 변경이

가능하다.

REMAP_TABLESPACE= ‘USERS’:’USER’

3. schema의 변경 : 과거의 FROMUSER/TOUSER parameter와 같이 schema를

변경할 때 사용한다.

REMAP_SCHEMA=SCOTT:STEALTH

CF. 단, 다음과 같은 경우 아래 (4)처럼 사용하는 schema변경에 대한 이 option은

error이다. 즉, 현재 존재하지 않는 계정에 대해서는 이 option을 사용할 수 없다.

(1) expdp를 통해 database “PROD”에서 user scott의 emp를 export하였다.

(2) impdp를 통해 database “TEST”에 user scottx로 위 dumpfile을 import하려

한다.

(3) 그러나 현재 “TEST”에는 user scottx가 없다.

(4) impdp schema=scott remap_schema=scott:scottx

4. 속성의 변경 : load시 object creation의 속성을 제어할 수 있다.

“SEGMENT_ATTRIBUTES” parameter를 통해 load되는 table(index)의

tablespace절과 storage절을 제어하거나 “STORAGE” parameter를 통해 storage

절만을 제어할 수 있다. 아래 예에서 첫 번째 것은 table생성시 tablespace 및

storage절 모두 제거하라는 뜻이며 두 번째 것은 storage절만을 제거하라는 뜻이다.

CF. 형식 TRANSFORM=SEGMENT_ATTRIBUTES|STORAGE:y|n:table|index

TRANSFORM=SEGMENT_ATTRIBUTES:n:table

TRANSFORM=STORAGE:n:table

3.2.8.5. Monitoring

대부분의 monitoring 작업과 마찬가지로 datapump또한 적절한 dictionary view를

통해 SQL문으로 조회를 하게 된다. 단, datapump 작업은 자동으로

v$session_longops에 등록이 됨으로 이를 통해 작업 시간에 대한 예측이 가능하다.

다음의 두 가지 view가 datapump를 위해 사용된다.

1. DBA_DATAPUMP_JOBS : 모든 active pump job이 현재 상태와 상관없이


표 3-1

dba_datapump_jobs 내역


등록되며 RAC의 경우 모든 node의 job을 볼 수 있다.

Column Datatype Description

OWNER_NAME VARCHAR2(30) Job을 시작한 user

JOB_NAME VARCHAR2(30) 사용자가 정한 job의 이름

OPERATION VARCHAR2(30) Job의 유형

JOB_MODE VARCHAR2(30) Job의 mode

STATE VARCHAR2(30) Job의 상태

DEGREE NUMBER Worker Processes의 수

ATTACHED_SESSIONS NUMBER Job에 연결된 session의 수

2. DBA_DATAPUMP_SESSIONS : pump job에 연결되어있는 모든 session정보를 볼

수 있다.

Column Datatype Description

OWNER_NAME VARCHAR2(30) Job을 시작한 user

JOB_NAME VARCHAR2(30) 사용자가 정한 job의 이름

SADDR RAW(4) Session Address(V$SESSION)

CF. Job의 이름을 지정하지 않은 경우 default로 oracle에 의해 자동으로 생성된다.

다음은 “V$SESSION_LONGOPS”와 datapump와의 연관관계이다.

V$SESSION_LONGOP

S

DataPump

USERNAME Job owner

OPNAME Job name

TARGET_DESC Job operation

SOFAR Job 수행 동안 전송된 크기(Megabytes)

TOTALWORK 추측되는 전체 작업량(MB)

UNITS MB

MESSAGE 다음과 같은 형식의 message로 기록됨

<job_name>: <operation_name> : nnn out of mmm

MB done

CF. 차후 예제에서 이런 값들이 어떻게 일치되는지 주의 깊게 살펴보도록 하자.

3.2.9.Example

이제 datapump에 대한 테스트를 위해 새로운 창을 열고 작업을 해보자. 다음은


표 3-2

dba_datapump_sessions

내역

표 3-3

datapump와

session


datapump를 위한 directory를 만들어 작업 user인 scott에게 적절한 권한을

부여하는 과정이다.

[NEWSVC]LIRACLE:/app/oracle> cd oradata

[NEWSVC]LIRACLE:/app/oracle/oradata> mkdir datapump

[NEWSVC]LIRACLE:/app/oracle/oradata> cd datapump

[NEWSVC]LIRACLE:/app/oracle/oradata/datapump> sqlplus "/as sysdba"

SQL*Plus: Release 10.1.0.4.0 - Production on Mon Jun 27 10:23:18 2005


Connected to:



SQL> create directory dirpump as '/app/oracle/oradata/datapump';

Directory created.

SQL> grant read, write on directory dirpump to scott;

Grant succeeded.


Connected.

대용량 unload에 대한 테스트를 위해 scott으로 많은 양의 data를 가지는 table을

생성한 후 다음과 같이 진행해보자. 현재의 예는 150MB정도되는 table에 대하여 data

를 추가적으로 입력하여 size를 증가 시킨 후 진행하는 과정이다.

CF. 여러분이 현재 사용중인 PC(서버급 이면 상관이 없겠지만)의 사양에 따라 향후

작업의 성능에 차이가 있을 것이다. 그로 인한 성능문제는 어쩔 수 없으니 너무

느리다고 생각지 말고 상대적으로 빠른지 아닌지를 주의 깊게 살펴보도록 하자.

SQL> select sum(bytes)/1024/1024 from user_segments



2 where segment_name = 'SE_NAPIB';

SUM(BYTES)/1024/1024

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

168

SQL> insert into se_napib select * from se_napib;

1000000 rows created.

SQL> commit;

Commit complete.

SQL> insert into se_napib select * from se_napib;

2000000 rows created.

SQL> commit;

Commit complete.

SQL> select sum(bytes)/1024/1024 from user_segments

2 where segment_name = 'SE_NAPIB';

SUM(BYTES)/1024/1024

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

669

SQL> conn sys/manager

Connected.

SQL> exec dbms_stats.gather_table_stats('SCOTT','SE_NAPIB',

estimate_percent => dbms_stats.auto_sample_size, method_opt => 'FOR

ALL COLUMNS SIZE AUTO', cascade => TRUE);



PL/SQL procedure successfully completed.

SQL> exit




[NEWSVC]LIRACLE:/app/oracle/oradata/datapump>

이제 총 669MB의 data를 가지고(실제 data size는 이보다 적겠지만) export 작업을

진행해보자. 편의상 알아보기 쉽도록 parameter file을 이용할 것이다. 먼저 estimate

를 통해 작업 space에 대한 추측을 한 후 실제 수행을 해보자.

[NEWSVC]LIRACLE:/app/oracle/oradata/datapump> cat expdp_check.par

userid=scott/tiger

directory=dirpump

job_name=datapump

estimate=statistics

estimate_only=Y

logfile=expdp_pump.log

filesize=100M

tables=se_napib

[NEWSVC]LIRACLE:/app/oracle/oradata/datapump> expdp parfile=expdp_check.par

Export: Release 10.1.0.4.0 - Production on Monday, 27 June, 2005 13:47

Copyright (c) 2003, Oracle. All rights reserved.

Connected to: Oracle Database 10g Enterprise Edition Release 10.1.0.4.0 -

Production


Starting "SCOTT"."DATAPUMP": parfile=expdp_check.par

Estimate in progress using STATISTICS method...

Processing object type

TABLE_EXPORT/TABLE/TBL_TABLE_DATA/TABLE/TABLE_DATA

. estimated "SCOTT"."SE_NAPIB" 557.3 MB

Total estimation using STATISTICS method: 557.3 MB



Job "SCOTT"."DATAPUMP" successfully completed at 13:56

[NEWSVC]LIRACLE:/app/oracle/oradata/datapump> cat expdp_pump.par

userid=scott/tiger

directory=dirpump

job_name=datapump

logfile=expdp_pump.log

dumpfile=expdp_pump%U.dmp

filesize=100M

tables=se_napib

[NEWSVC]LIRACLE:/app/oracle/oradata/datapump> date

Mon Jun 27 17:09:10 KST 2005

[NEWSVC]LIRACLE:/app/oracle/oradata/datapump> expdp parfile=expdp_pump.par

Export: Release 10.1.0.4.0 - Production on Monday, 27 June, 2005 17:09



Production


Starting "SCOTT"."DATAPUMP": parfile=expdp_pump.par

Estimate in progress using BLOCKS method...



Total estimation using BLOCKS method: 669 MB

Processing object type TABLE_EXPORT/TABLE/TABLE

Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS

. . exported "SCOTT"."SE_NAPIB" 580.1 MB 4000000 rows

Master table "SCOTT"."DATAPUMP" successfully loaded/unloaded

*****************************************************************************

*

Dump file set for SCOTT.DATAPUMP is:

/app/oracle/oradata/datapump/expdp_pump01.dmp










Mon Jun 27 17:18:35 KST 2005


현재 datapump export는 filesize parameter로 100M를 설정하였기 때문에 총

580MB정도를 unload하면서 dumpfile의 template “%U”의 영향으로 6개의

dumpfile이 “01 ~ 06”의 이름으로 생성되었음을 알 수 있다. 4백만건 580MB의

unload 시간은 대략 9분여의 시간이 소요되었다.

이제 과거의 방식대로 export를 해보자 먼저 exp_nopump.par라는 parameter file

을 만들어 parameter file을 설정한 후 작업을 해본다.

CF. 여러분이 datapump를 테스트하는 과정에서 너무 느리다고 CTRL+C등으로

작업을 끊어 prompt를 끊었다 할지라도 작업은 계속 진행된다. 앞서 datapump의

architecture에서 설명하였듯 datapump는 server작업이기 때문이다. 만일 여러분이

작업을 끊는 action을 취했다면 directory로 지정한 위치로 가서 나중에 살펴보면

작업이 계속 진행되었음을 알 수 있을 것이다. 생각해보면 이런 구조이기 때문에 작업을

나중에 restart할 수도 있고 attach할 수도 있지 않겠는가.

[NEWSVC]LIRACLE:/app/oracle/oradata/datapump> cat exp_nopump.par

userid=scott/tiger

log=exp_nopump.log

file=exp_nopump.dmp

tables=se_napib


Mon Jun 27 17:56:06 KST 2005

[NEWSVC]LIRACLE:/app/oracle/oradata/datapump> exp

parfile=exp_nopump.par

Export: Release 10.1.0.4.0 - Production on Mon Jun 27 17:56:06 2005





Production


Export done in KO16KSC5601 character set and AL16UTF16 NCHAR

character set

About to export specified tables via Conventional Path ...

. . exporting table SE_NAPIB 4000000 rows exported

Export terminated successfully without warnings.


Mon Jun 27 18:14:02 KST 2005


전통적인 방식인 export에서는 대략 13분 정도가 소요되었다.

CF. 현재 테스트를 진행하고 있는 장비는 일반 PC로서 CPU도 1장임으로 parallel을

통한 큰 효과는 볼 수 없다. 여러분이 서버에서 작업 중 이라면 반드시 위 parameter

에서 parallel의 값을 설정하고 테스트를 해보시기 바란다. 적게는 수배에서 많게는 열

배에 이르는 빠른 성능을 느낄 수 있을 것이다.

이제 load & import를 통한 성능의 변화를 알아볼 차례이다. 먼저 truncate를 하여

원본 table을 비우고 dumpfile을 통해 load를 해보자. 이번에도 parameter file을

만들어 놓고 작업을 진행한다. 앞서 설명한 import parameter중

table_exists_action 를 다시 상기하도록 하자.

[NEWSVC]LIRACLE:/app/oracle/oradata/datapump> sqlplus scott/tiger

SQL*Plus: Release 10.1.0.4.0 - Production on Tue Jun 28 10:01:57 2005


Connected to:





SQL> truncate table se_napib;

Table truncated.

SQL> exit




[NEWSVC]LIRACLE:/app/oracle/oradata/datapump> cat impdp_pump.par

userid=scott/tiger

directory=dirpump

job_name=datapump

logfile=impdp_pump.log

dumpfile=expdp_pump%U.dmp

tables=se_napib

table_exists_action=append


Tue Jun 28 10:47:00 KST 2005

[NEWSVC]LIRACLE:/app/oracle/oradata/datapump> impdp parfile=impdp_pump.par

Import: Release 10.1.0.4.0 - Production on Tuesday, 28 June, 2005 10:47



Production



Starting "SCOTT"."DATAPUMP": parfile=impdp_pump.par




. . imported "SCOTT"."SE_NAPIB" 580.1 MB 4000000 rows




ORA-39111: Dependent object type TABLE_STATISTICS skipped, base object

type TABLE:"SCOTT"."SE_NAPIB" already exists

Job "SCOTT"."DATAPUMP" completed with 1 error(s) at 10:52


Tue Jun 28 10:53:01 KST 2005

상당한 시간 단축이다. 대략 6분여 만에 400만 건 580MB가 load되었다. 이제 과거

import와 비교해보자. 왜 oracle10g에서 unload(export)보다도 data load(import)

의 가히 혁명적인 성능향상을 이야기 하는지 비교해 보자. 현재 load된 data를 다시

truncate한 후 전통적 방식의 import parameter를 사용해 보자.




Connected to:



SQL> select count(*) from se_napib;

COUNT(*)

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

4000000

SQL> truncate table se_napib;

Table truncated.

SQL> exit






[NEWSVC]LIRACLE:/app/oracle/oradata/datapump> cat imp_nopump.par

userid=scott/tiger

buffer=100000

commit=y

log=imp_nopump.log

file=exp_nopump.dmp

tables=se_napib

ignore=y


Tue Jun 28 11:29:22 KST 2005

[NEWSVC]LIRACLE:/app/oracle/oradata/datapump> imp parfile=imp_nopump.par

Import: Release 10.1.0.4.0 - Production on Tue Jun 28 11:29:22 2005



Production


Export file created by EXPORT:V10.01.00 via conventional path

import done in KO16KSC5601 character set and AL16UTF16 NCHAR

character set

. importing SCOTT's objects into SCOTT

. . importing table "SE_NAPIB" 4000000 rows imported

Import terminated successfully without warnings.


Tue Jun 28 12:05:07 KST 2005

전통적인 import를 수행한 결과 총 36분 정도 걸렸다. 먼저 수행했던 datapump의

load와 비교하면 가히 엄청난 속도의 차이다. 그 동안 지지부진 했던 import 작업의

어려움을 상당부분 해소될 것으로 보인다.



다음은 running중인 datapump 작업에 어떻게 access하여 운영작업을 할 수

있는가를 살펴보자. 몇 개의 session이 필요함으로 먼저 현재 열어놓은 창 외에 2개를

추가로 더 열고 작업을 시작하자.

> SESSION #1 : 테스트를 위한 환경준비를 먼저하고 적절한 SQL을 구사한다.

[NEWSVC]LIRACLE:/app/oracle/oradata/datapump> sqlplus "/as sysdba"



Connected to:



SQL> grant select on dba_datapump_jobs to scott;

Grant succeeded.


Connected.

SQL> desc dba_datapump_jobs

Name Null? Type

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

OWNER_NAME VARCHAR2(30)

JOB_NAME VARCHAR2(30)

OPERATION VARCHAR2(60)

JOB_MODE VARCHAR2(60)

STATE VARCHAR2(30)

DEGREE NUMBER

ATTACHED_SESSIONS NUMBER

SQL> col owner_name for a10

SQL> col job_name for a10



SQL> col operation for a15

SQL> col job_mode for a10

SQL> col state for a15

SQL> set linesize 100

SQL> select * from dba_datapump_jobs;

no rows selected

SQL>

> SESSION #2 : expdp 명령으로 작업을 시작한다.

[NEWSVC]LIRACLE:/app/oracle/oradata/datapump> rm expdp_pump??.dmp


Export: Release 10.1.0.4.0 - Production on Tuesday, 28 June, 2005 17:31



Production




---- waiting ----

> SESSION #1 : 현재 작업하는 내용을 확인하자.


OWNER_NAME JOB_NAME OPERATION JOB_MODE STATE DEGREE ATTACHED_SESSIONS

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

- - - - - -

SCOTT DATAPUMP EXPORT TABLE EXECUTING 1 1

> SESSION #3 : attach로 현재 작업중인 export에 연결하여 작업의 상태를

확인하자.



[NEWSVC]LIRACLE:/app/oracle/oradata/datapump> expdp scott/tiger

attach=datapump




Production


Job: DATAPUMP

Owner: SCOTT

Operation: EXPORT

Creator Privs: FALSE

GUID: FA97171F6B01B7C8E030007F010062D0

Start Time: Tuesday, 28 June, 2005 17:31

Mode: TABLE

Instance: NEWSVC

Max Parallelism: 1

EXPORT Job Parameters:

Parameter Name Parameter Value:

CLIENT_COMMAND parfile=expdp_pump.par

DATA_ACCESS_METHOD AUTOMATIC

ESTIMATE BLOCKS

INCLUDE_METADATA 1

LOG_FILE_DIRECTORY DIRPUMP

LOG_FILE_NAME expdp_pump.log

TABLE_CONSISTENCY 0

State: EXECUTING

Bytes Processed: 0

Current Parallelism: 1

Job Error Count: 0

Dump File: /app/oracle/oradata/datapump/expdp_pump%u.dmp

size: 104,857,600



Dump File: /app/oracle/oradata/datapump/expdp_pump01.dmp

size: 104,857,600

bytes written: 4,096

Worker 1 Status:

State: EXECUTING

Export>

> SESSION #1 : 그리고 나서 다시 session#1에서 상태를 보면 attach로 인해

session의 수가 2로 증가했음을 알 수 있다.



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

- - - - - -

SCOTT DATAPUMP EXPORT TABLE EXECUTING 1 2

> SESSION #3 : 작업중인 datapump를 stop 시키자.

Export> stop_job

Are you sure you wish to stop this job ([y]/n):yes

--- wating ---

이 때에 stop이 완전하게 이루어지기 까지는 시간이 좀 걸릴 것이다. 바로 아래처럼

session#1에서 조회를 해보자.

> SESSION #1 : 현재 session#3에서 stop을 진행했기 때문에 아래에 session의

수가 1로 다시 감소하였다.



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

- - - - - -

SCOTT DATAPUMP EXPORT TABLE STOP PENDING 1 1

> SESSION #3 : 이제 session#3에서 작업이 완전히 중단되어 prompt가



떨어졌다.

Export> stop_job

Are you sure you wish to stop this job ([y]/n):yes


CF. 위에서 “y/n”에 대한 답변은 그냥 enter를 치면 default “y”로 진행이 된다. 현재의

작업 환경에서는 테스트결과 환경에 따라 “y”, ”n”등 어떤 문자도 인식을 하지 못하고

오로지 “yes/no”만을 인식하는 문제가 있었다. 작업하는 platform이나 version에

따라 다를 수 있으니 “y/n”가 안되면 “yes/no”를 사용해 보자.

> SESSION #1 : 현재 session#3에서 stop이 완료되면서 원래 작업을 진행한

session#2도 종료되었기 때문에 현재 session의 수가 0으로 감소하면서 상태는

“NOT RUNING”으로 바뀌었다.



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

- - - - - -

SCOTT DATAPUMP EXPORT TABLE NOT RUNNING 0 0

> SESSION #2 : session#3에 의해 작업이 강제로 중단되었다.





Production










ORA-39014: One or more workers have prematurely exited.

Job "SCOTT"."DATAPUMP" stopped due to fatal error at 17:34


CF. 정상적인 경우라면 위의 마지막 메시지는 정상적으로 작업이 중단되었다고

나타나야 하지만 fatal error를 뿌리고 있다. 이는 oracle bug “BUG:3333076”로서

oracle10g Relase2인 10.2.0.x에서 해결이 된다.

이제 session#3에서 다시 attach를 진행하여 작업을 완료해 보자.

> SESSION #3 : attach로 중단된 작업에 연결하자.


attach=datapump




Production


Job: DATAPUMP

Owner: SCOTT

Operation: EXPORT

Creator Privs: FALSE

GUID: FA97171F6B01B7C8E030007F010062D0

Start Time: Tuesday, 28 June, 2005 17:31

Mode: TABLE

Instance: NEWSVC

Max Parallelism: 1

EXPORT Job Parameters:

Parameter Name Parameter Value:



CLIENT_COMMAND parfile=expdp_pump.par

DATA_ACCESS_METHOD AUTOMATIC

ESTIMATE BLOCKS

INCLUDE_METADATA 1

LOG_FILE_DIRECTORY DIRPUMP

LOG_FILE_NAME expdp_pump.log

TABLE_CONSISTENCY 0

State: IDLING

Bytes Processed: 608,380,176

Percent Done: 99


Job Error Count: 0


size: 104,857,600


size: 104,857,600


Worker 1 Status:

State: UNDEFINED

Export>

> SESSION #1 : 현재 session#3에서 attach가 되었기 때문에 session의 수가

다시 1로 바뀌었다. 간격을 두고 2차례 정도 조회해 보면 상태가 변한 것을 알 수 있다.

잠시 동안 “UNDEFINED”에서 마지막으로 “IDLING”으로 바뀌면서 degree가 0에서 1

로 같이 바뀐다. 즉, 작업할 준비가 된 것이다.



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

- - - - - -

SCOTT DATAPUMP EXPORT TABLE UNDEFINED 0 1





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

- - - - - -

SCOTT DATAPUMP EXPORT TABLE IDLING 1 1

> SESSION #3 : 중단된 작업을 재개해보자.

Export> start_job

Export> status=10

Job: DATAPUMP

Operation: EXPORT

Mode: TABLE

State: EXECUTING

Bytes Processed: 0


Job Error Count: 0


size: 104,857,600


size: 104,857,600


Worker 1 Status:

State: EXECUTING

Export> continue_client

Job DATAPUMP has been reopened at Tuesday, 28 June, 2005 17:35

Restarting "SCOTT"."DATAPUMP": parfile=expdp_pump.par





*****************************************************************************



*










작업을 재개하기 위해 start_job을 입력한 후 상태체크를 위해 매 10초간 확인을

하도록 status=10으로 설정을 했다. 그리고 session#2에서 client가 종료 되었으니

현재 session#3을 client mode로 전환하여 직접 작업결과를 받을 수 있도록

마지막으로 continue_client를 입력하였다.

작업이 완료되어 session#1에서 다시 조회를 하면 더 이상 data가 없음을 확인할 수

있다. 작업이 진행된 directory dirpump에서 logfile을 확인하면 정상적으로 작업이

완료되었음도 알 수 있다.


no rows selected

SQL> exit




[NEWSVC]LIRACLE:/app/oracle/oradata/datapump> cat expdp_pump.log

;;;



;;;




Production




;;; Export> stop_job





ORA-39014: One or more workers have prematurely exited.

Job "SCOTT"."DATAPUMP" stopped due to fatal error at 17:34

Job DATAPUMP has been reopened at Tuesday, 28 June, 2005 17:35

;;; Export> start_job

Restarting "SCOTT"."DATAPUMP": parfile=expdp_pump.par

;;; Export> status=10



;;; Export> continue_client



*****************************************************************************

*










최종 결과를 보여주는 이 logfile의 마지막 메시지는 1개의 error를 인식하지만

완료되었다고 말하고 있다. 그러나 그 1개의 error는 oracle bug로 인해 나온(최초

stop_job으로 인한 fatal error(39014))것 임으로 무시한다면 정상적으로 종료된



것이라 하겠다.

결론적으로 일반적인 datapump를 이용한 load & unload는 정상적으로 작동이

되었지만 다른 client를 통한 attach작업은 부분적으로 정확하지 못한 메시지들이

나타나는 것으로 보인다. 다음 버전인 oracle10g Release2에서 보다 완전해진

datapump를 기대해 보자.

CF. datapump를 진행하는 과정에서 attach후 stop을 늦게 하면 dumpfile set은

이미 구성이 된 상태에서 작업이 중단될 수 있다. 이런 경우 attach하여 start를

재개하면 작업이 끝남과 동시에 예기치 못한 error 메시지들을 받을 수 있다. 그러나 이

내역이 dumpfile과 무관한 내용이고 logfile을 확인하여 큰 이상이 없다면 이는 pump

작업으로 인한 data unload와는 무관한 내용으로 너무 놀랄 필요는 없다. 이러한 것도

역시 앞서 제기한 oracle bug가 있었기 때문으로 생각되며 관련 자료들에서 이런

메시지는 data작업과는 별도의 것으로 일단 작업 자체는(dumpfile set 구성) 이상이

없다고 봐도 된다. 가장 확실한 것은 아래와 같이 직접 이들 dumpfile로 import

작업을 수행해서 이상이 없음을 확인하면 되겠다. 다음은 위의 예가 아닌 작업종료

메시지가 정확히 안 나오고 error가 나오는 경우를 발생시켜 그 files을 가지고 다른

화면에서 load작업을 진행하여 dumpfile의 이상유무를 확인한 내역이다. 모두

정상적으로 작업이 되었다.

[NEWSVC]LIRACLE:/app/oracle/oradata/datapump> impdp parfile=impdp_pump.par

Import: Release 10.1.0.4.0 - Production on Wednesday, 29 June, 2005 10:38



Production



Starting "SCOTT"."DATAPUMP": parfile=impdp_pump.par




. . imported "SCOTT"."SE_NAPIB" 580.1 MB 4000000 rows





3.2.10. Network Mode

앞서 작업한 내역들은 모두 하나의 서버에서만 이루어졌다. 이제 network mode를

통해 remote database를 이용한 data load를 테스트해보자. 가상으로 network을

사용하기 위하여 현재의 동일한 장비에서 최초 database creation test를 위해

만들었던 database “CRT10G”에서 현재 환경을 연결하는 database link를 설정한다.

다음으로 다른 창에서 database “CRT10G”를 start하고 환경을 설정한다.

[NEWSVC]LIRACLE:/app/oracle> export ORACLE_SID=CRT10G

[CRT10G]LIRACLE:/app/oracle> sqlplus "/as sysdba"

SQL*Plus: Release 10.1.0.4.0 - Production on Wed Jun 29 17:14:26 2005


Connected to an idle instance.

SQL> startup

ORACLE instance started.

Total System Global Area 385875968 bytes

Fixed Size 779316 bytes

Variable Size 170138572 bytes

Database Buffers 209715200 bytes

Redo Buffers 5242880 bytes

Database mounted.

Database opened.

SQL> create user staff identified by staff

2 default tablespace users;

User created.

SQL> grant connect, resource to staff;

Grant succeeded.



SQL> conn staff/staff

Connected.

SQL> desc se_napib

ERROR:

ORA-04043: object se_napib does not exist

SQL> conn system/manager

Connected.

SQL> create public database link NEWSVC using 'NEWSVC';

Database link created.

SQL> select * from global_name@newsvc;

GLOBAL_NAME

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

NEWSVC

SQL> create directory dirpump2 as '/app/oracle/oradata/datapump2';

Directory created.

SQL> exit




[CRT10G]LIRACLE:/app/oracle> cd oradata

[CRT10G]LIRACLE:/app/oracle/oradata> mkdir datapump2

[CRT10G]LIRACLE:/app/oracle/oradata> cd datapump2

[CRT10G]LIRACLE:/app/oracle/oradata/datapump2>

이제 database link를 이용하여 network mode로 remote database인 “NEWSVC”

에서 scott의 se_napib table을 현재 작업하는 database “CRT10G”의 staff

schema로 load 해보자. 먼저 parameter file을 확인하고 작업 결과 및 확인을

해보자. 확인이 끝나면 이제 database “CRT10G”를 down하자.



[CRT10G]LIRACLE:/app/oracle/oradata/datapump2> cat impdp_netpump.par

userid=system/manager

job_name=datapump

directory=dirpump2

logfile=impdp_netpump.log

tables=scott.se_napib

network_link=newsvc

remap_schema=scott:staff

[CRT10G]LIRACLE:/app/oracle/oradata/datapump2> impdp

parfile=impdp_netpump.par

Import: Release 10.1.0.4.0 - Production on Wednesday, 29 June, 2005 17:20



Production


Starting "SYSTEM"."DATAPUMP": parfile=impdp_netpump.par






. . imported "STAFF"."SE_NAPIB" 4000000 rows


Job "SYSTEM"."DATAPUMP" successfully completed at 17:45

[CRT10G]LIRACLE:/app/oracle/oradata/datapump2> sqlplus staff/staff



Connected to:





SQL> select count(*) from staff.se_napib where rownum < 11;

COUNT(*)

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

10

SQL> exit




[CRT10G]LIRACLE:/app/oracle/oradata/datapump2> sqlplus "/as sysdba"



Connected to:



SQL> shutdown

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> exit




[CRT10G]LIRACLE:/app/oracle/oradata/datapump2>

3.2.11. 비정상 종료의 처리어떤 경우이든 load, unload 작업을 진행 하던 중 작업을 중지할 필요가 있을 수



있으며 이런 경우에는 앞서 “STOP_JOB”을 사용하는 방법을 보았다. 그러나 보다 더

많은 case는 잘못된 parameter의 구사로 작업을 아예 없애버리고 싶은 경우일

것이다. 이때엔 앞서의 예처럼 attach하여 “STOP_JOB”이 아니라 “KILL_JOB” 명령을

주면 된다.

CF. 주로 사용되는 datapump interactive command는 “START_JOB “,

“STOP_JOB”, “KILL_JOB”, “STATUS=n”과 같다.

CF. 작업 결과는 dba_datapump_jobs에서 해당 job이 없어졌는지를 보면 알 수 있다.

그러나 만일 여러분이 어떤 이유로 (직접 stop을 하든 다른 이유로 작업이 중단이 되든)

datapump작업을 진행하던 중 해당 작업이 stop 또는 not running등의 상태가 된

경우에 그리고 그 당시에 해당 작업에 대상이 되는 dumpfile을 삭제하거나 또는 해당

dumpfile이 corrupted 상태가 된 경우라면 여러분은 attach로 해당 작업에 접근할

수가 없다. 즉, “KILL_JOB”이 불가하다. 이런 경우엔 다음과 같이 직접 master table

을 삭제함으로써 해결해야 한다. 아래의 예는 중단된 datapump 작업에 해당되는

dumpfile을 삭제한 경우이다.

[NEWSVC]LIRACLE:/app/oracle/oradata/datapump> rm expdp_pump01.dmp


attach=datapump




Production


ORA-39002: invalid operation

ORA-39000: bad dump file specification

ORA-31640: unable to open dump file

"/app/oracle/oradata/datapump/expdp_pump01.dmp" for read

ORA-27037: unable to obtain file status

Linux Error: 2: No such file or directory

Additional information: 3






Connected to:





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

- - - - - -

SCOTT DATAPUMP EXPORT TABLE NOT RUNNING 1 1

SQL> select count(*) from datapump;

COUNT(*)

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

336

SQL> drop table datapump;

Table dropped.

SQL> purge table datapump;

Table purged.




no rows selected

SQL> exit





Master table인 “DATAPUMP”를 직접 제어해서 문제를 해결한 방식이다.

위 작업에서 drop 과 purge를 한번에 하고 싶으면 “SQL> drop table datapump

purge;”처럼 purge를 option으로 사용하면 된다.

CF. purge option(or command)에 대해서는 나중에 다시 다룰 것이다.



OCP point

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

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

1. datapump architecture 그림에 대한 이해

2. import를 위한 table_exists_action, remap_datafile,tablespace,schema

option 이해

3. datapump에서 사용하는 3가지 files의 종류와 의미

4. datapump에서 지정하는 directory의 우선순위

5. datapump의 주요 interactive command는 4가지

참조

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

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

varray : o8 42p



3.3. New Cluster Features

3.3.1.Clustering 개요Oracle10g가 새롭게 이야기 하는 sorted-hash cluster에 대하여 알아볼 것이다.

그러나 그냥 이 sorted-hash cluster를 이야기 하는 것 보다는 cluster에서 hash

cluster를 거쳐 왜 이 object가 소개되는가를 아는 것이 좋을 듯하여 간략하게 이전

개념을 살펴보고 sorted-hash cluster를 이해해보자.

3.3.1.1. Cluster

대부분의 DBA들은(필자를 포함해서) 특별한 경우가 아니라면 cluster를 경험하는

일이 많지 않다. 그 특성상 매우 한정적인 조건이 만족이 되어야 하기 때문이다. 보통의

경우 cluster를 만들 때에는 대상 tables이 insert, update 보다는 주로 query에

사용되고 그 query도 tables간의 join 형태처럼 함께 사용하는 경우가 대부분일 때

cluster를 고려하게 된다. 만일 cluster 생성을 결정하였다면 unique한 key 값을

가지고 cluster key를 구성하여 하나의 row가 하나의 block만을 access하도록

설계하여 그 효율성을 높이도록 하는 것이 일반적이다.

3.3.1.2. Hash Cluster

Oracle이 제공하는 또 다른 cluster인 hash cluster는 index(index cluster)를 가진

non-cluster table에 hash function을 적용하여 data 조회성능을 보다 더 높이기

위한 기법이다. 이는 hash cluster를 만들고 table을 load하는 방식으로 이루어진다.

이런 형태의 cluster는 숫자로 된(hash values) 값들을 분산하여 생성하는 hash

function을 사용하게 되는데 이 function을 통해 data를 찾고 저장한다. 따라서

보통의 indexing이 index block read와 실제 data block read라는 최소 2회의 data

를 찾는 I/O가 수반된다면 hash function을 통한 hash cluster에서는 단 1회의 I/O만

필요로 하게 된다.

Hash cluster는 cluster key를 가지고 equal 비교를(key = …) 하는 형태의 query를

주로 사용하는 tables에 대하여 유용하게 사용된다. 따라서 cluster key를 가지고 대소

비교와 같은 “=”이외의 operator를 사용하거나(한번의 hash function으로 원하는

data를 찾을 수 없음으로) 대상 table이 계속해서 커지고 full table scan이 발생하는

등 hash cluster table을 만들 때 미리 예측한 sizing, query 조건 등이 맞지 않으면

cluster의 이점이 없어짐은 물론이고 오히려 더 나쁜 결과를 초래할 수도 있다.

CF. 일반적으로 hash cluster를 생성할 때에는 그 전체 size(data 건수)를 예측하여

대략적으로 정해진 space를 사용하게 된다. 따라서 size 예측이 어려우면 hash

cluster의 좋은 후보자라 할 수 없다.



다음은 일반적인 table과 hash cluster table을 단순히 비교한 sample이다. 먼저

scott계정으로 일반적인 table의 insert 및 조회 결과를 보자.

SQL> create table key_t1 (key_no number primary key, key_desc

varchar2(10));

Table created.

SQL> insert into key_t1 values (1, 'a');

1 row created.

SQL> insert into key_t1 values (3, 'c');

1 row created.

SQL> insert into key_t1 values (2, 'b');

1 row created.

SQL> commit;

Commit complete.

SQL> select * from key_t1;

KEY_NO KEY_DESC

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

1 a

3 c

2 b

다음은 hash function이 적용된 동일한 작업의 결과를 비교해보자. 먼저 system

계정으로 login하여 cluster 생성 권한을 부여한 후 작업을 진행한다.

SQL> grant create cluster to scott;



Grant succeeded.


Connected.

SQL> create cluster key_hc1 (key_no number(5,0))

2 hash is key_no hashkeys 300;

Cluster created.

SQL> create table key_ht1 (key_no number(5, 0) primary key,

2 key_desc varchar2(10)) cluster key_hc1(key_no);

Table created.

SQL> insert into key_ht1 values (1, 'a');

1 row created.

SQL> insert into key_ht1 values (3, 'c');

1 row created.

SQL> insert into key_ht1 values (2, 'b');

1 row created.

SQL> commit;

Commit complete.

SQL> select * from key_ht1;

KEY_NO KEY_DESC

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



1 a

2 b

3 c

위 결과를 보면 hash function을 통해 data가 저장된 것이라는 추측을 할 수 있다.

따라서 두 query간의 cost도 분명 다르게 나올 것이다. 현재는 두 table 모두 full

table scan을 할 것이고 hash cluster가 더 안 좋은 cost가 나올 것으로 예측된다. 즉,

hash function을 사용하여 full table scan이 일어나면 더 안 좋다는 뜻이다. 비교를

해보면 다음과 같다.

CF. oracle10g의 기능이 제대로 수행되도록 oracle9i에서 만들어진 plan_table을

삭제한 후 oracle10g plan_table을 다시 만들어 plan을 확인해 보자.

SQL> drop table plan_table;

Table dropped.

SQL> @?/rdbms/admin/utlxplan

Table created.

SQL> explain plan set statement_id = 'test' for

2 select * from key_t1;

Explained.

SQL> select plan_table_output from

table(dbms_xplan.display('plan_table','test','serial'));

PLAN_TABLE_OUTPUT

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

Plan hash value: 633984868

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

| Id | Operation | Name |Rows | Bytes | Cost (%CPU)| Time |

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



| 0 | SELECT STATEMENT | | 3 | 60 | 62 (0)| 00:00:01 |

| 1 | TABLE ACCESS FULL| KEY_T1 | 3 | 60 | 62 (0)| 00:00:01 |

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

Note

-----

PLAN_TABLE_OUTPUT

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

- dynamic sampling used for this statement

12 rows selected.

SQL> explain plan set statement_id = 'test' for

2 select * from key_ht1;

Explained.

SQL> select plan_table_output from

table(dbms_xplan.display('plan_table','test','serial'));

PLAN_TABLE_OUTPUT

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

Plan hash value: 1518049598

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

| Id | Operation | Name |Rows | Bytes | Cost (%CPU)| Time |

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

| 0 | SELECT STATEMENT | | 1 | 20 | 318 (1)| 00:00:02 |

| 1 | TABLE ACCESS FULL| KEY_HT1 | 1 | 20 | 318 (1)| 00:00:02 |

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

Note

-----



PLAN_TABLE_OUTPUT

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

- dynamic sampling used for this statement

12 rows selected.

SQL> truncate table plan_table;

Table truncated.

3.3.2.Sorted-Hash Cluster

3.3.2.1. 개요Oracle10g는 hash cluster에 sort option을 적용하여 data를 조회할 때 자동으로

sorting된 data 출력을 지원하며 이를 이른바 sorted-hash cluster라 칭한다.

일반적으로 table에 저장되는 data의 순서는 사용자가 원하는 형태와는 상관이 없다.

그렇기 때문에 order by를 사용하지 않고 사용자가 원하는 순서대로 data를 보여주는

것은 보장할 수가 없는 것이다. (물론, index 혹은 group by등을 사용하여 자동으로

order by가 되는 종류의 oracle의 구조적인 sort기능은 예외이다) Oracle10g가

제공하는 sorted-hash cluster는 특정 cluster key에 따라 sort key columns을

지정하여 where절에 hash key가 사용될 때 기 정의된 sort key column을 default

order로 사용할 수 있게 해준다. 따라서 이 기능은 order by를 사용하지 않도록 하여

CPU time을 줄이고 sort를 위한 memory 사용량도 줄이는 성능상의 효과를 제공할

수 있는 것이다.

CF. hash key는 각각의 key value에 따라 관련 rows의 list에 link되어있고 각 list는

해당 oracle blocks으로 구성된다. 바로 sorted-hash cluster에서 이 list들은 sort

key columns에 따라 sort가 되어있다.

3.3.2.2. Example

Sorted-hash cluster를 구현하기 위하여 hash key와 sort column을 갖는 cluster를

만든 후 이를 table로 load해 보자.

SQL> create cluster key_hc2 (key_no number(5,0),

2 open_dte varchar2(8) sort, biz_number number sort)

3 hash is key_no hashkeys 300;



Cluster created.

SQL> create table key_ht2 (key_no number(5,0),

2 open_dte varchar2(8), biz_number number sort,

3 key_desc varchar2(10)) cluster key_hc2 (

4 key_no, open_dte, biz_number);

Table created.

다음, 무작위 순서로 data를 insert하자.

SQL> insert into key_ht2 values (1, '20050401', 10, 'c');

1 row created.

SQL> insert into key_ht2 values (1, '20050401', 4, 'a');

1 row created.

SQL> insert into key_ht2 values (1, '20050209', 9, 'd');

1 row created.

SQL> insert into key_ht2 values (1, '20050209', 1, 'a');

1 row created.

SQL> insert into key_ht2 values (1, '20050401', 6, 'b');

1 row created.

SQL> insert into key_ht2 values (1, '20050209', 7, 'c');

1 row created.

SQL> insert into key_ht2 values (1, '20050209', 5, 'b');



1 row created.

SQL> commit;

Commit complete.

이제 full table scan과 hash key를 통한 조회의 차이를 확인해 보자.

SQL> select * from key_ht2;

KEY_NO OPEN_DTE BIZ_NUMBER KEY_DESC

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

1 20050401 10 c

1 20050401 4 a

1 20050209 9 d

1 20050209 1 a

1 20050401 6 b

1 20050209 7 c

1 20050209 5 b

7 rows selected.

SQL> select * from key_ht2 where key_no = 1;

KEY_NO OPEN_DTE BIZ_NUMBER KEY_DESC

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

1 20050209 1 a

1 20050209 5 b

1 20050209 7 c

1 20050209 9 d

1 20050401 4 a

1 20050401 6 b

1 20050401 10 c

7 rows selected.



처음 SQL은 hash key가 한 가지 임으로 그냥 입력된 순서대로 data가 나왔지만 두

번째 SQL은 hash key 값을 통해 sorted 순서로 data를 보여주고 있다.

위의 예에서 확인할 수 있듯이 이 기능은 order by를 사용하지 않고 hash key를 위해

sort가 된 상태로 data를 보여준다. 즉 이 기능을 제공하여 자주 사용되는 key값과

order by를 미리 정하여 관련 query들의 성능을 더 높일 수 있는 것이다.

CF. 물론, hash key와 sorting columns에 대한 신중한 선택을 하지 못하면 오히려 그

반대의 역효과가 있을 수 있으니 주의해야 한다.

3.3.2.3. 주의할 점들Sorted-hash cluster를 만들 것인가를 고려할 때에는 앞서 이야기 했듯이 hash key

columns과 sorting columns에 대한 신중한 선택이 필수 일 것이다. 그러나 그런

사항을 잘 이해하고 제대로 판단하기 위해서는 다음과 같은 sorted-cluster의 주요한

속성을 알고 있어야 한다.

1. create index를 통해 index를 만드는 것은 문제가 되지 않으며 이 indexes는

oracle이 자동으로 관리해준다. (index와 관련하여 불필요한 걱정은 하지 말라)

2. 물론, cluster를 사용하는 주 이유가 query의 성능향상에 있고 대개의 경우 data의

생성이 일시적일 가능성이 높다. 특히나 sorted-hash cluster의 경우 data를

생성하는 시점에 그 순서대로 data가 insert된다면 가장 좋은 성능을 보여줄 수 있을

것이다. 물론, insert 순서와 상관없이 data가 sorting되어 보여지기는 하지만 insert

의 순서를 잘 고려하는 것은 oracle 내부적으로 발생하는 sorting을 제거하는 매우

좋은 방법이 될 수 있다.

3. 제대로 된 sorted-hash cluster를 보장하기 위해서는 반드시 cost-based

optimizer의 사용이 필요하고 당연히 해당 cluster에 대한 통계작업도 있어야 한다.

(사실 향후에 소개하는 oracle10g의 관리자동화 개념을 보면 oracle은 이제 스스로

통계작업을 진행하고 필요하다면 dynamic sampling도 실시하기 때문에 cost-based

optimizer의 사용과 통계작업이 필요하다라는 말은 큰 의미가 없지만 sorted-hash

cluster의 개념적 이해를 위해 알고 있어야 한다)

4. where절에 hash key가 equality(“=”)로 사용될 때 sorting columns에 따른

순서가 보장된다.

5. 직접 order by를 사용하면서 sort key columns이 아닌 다른 columns을 사용하면

그 query는 sorted-hash cluster의 이점을 살리지 못한다.



CF. sorted-hash cluster를 제대로 사용하기 위해서는 필요한 SQL문에 대한 plan을

통해 원치 않는 “SORT ORDER BY”가 사용되는지를 확인하는 것이 좋을 것이다.



참조

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

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

cluster : ob 35, 36p

hash cluster : ob 36, 37p



3.4. Tablespaces

3.4.1.User Default Tablespace (Default Permanent

Tablespace)

과거 oracle9i에서는 create database 혹은 alter database 명령으로 default

temporary tablespace를 지정할 수 있는 new feature를 선보인바 있다. 이는 user

생성시 temporary tablespace를 지정하지 않아 해당 user가 temporary segment

를 사용하는 것을 방지하고자 했기 때문이다. 같은 이유로 default tablespace를

지정하지 않은 user가 object 생성을 하면서 tablespace를 지정하지 않으면 (가급적

아무도 사용하지 말라는)system tablespace에 segment가 만들어지는 문제는

여전히 남아있었다. 왜냐하면 system tablespace가 default tablespace이기

때문이다.

이제 oracle10g는 default tablespace도 database level에서 지정함으로써 이런

문제들에서 벗어날 수 있게 되었다. 방식은 default temporary tablespace와

마찬가지로 create database 혹은 alter database를 통해 할 수 있다. 다음의 간단한

예를 살펴보자.

CF. 이를 default temporary tablespace와 구분하여 명확하게 default permanent

tablespace를 지정한다고 표현한다.

CF. system users인 “SYS, SYSTEM, OUTLN”은 이 default permanent

tablespace에 영향을 받지 않으며 여전히 system tablespace를 default로 사용하게

된다.

CF. default temporary tablespace와 마찬가지로 default permanent tablespace

는 그냥 drop을 할 수가 없다. 반드시 default permanent tablespace를 할당 받은

users의 default tablespace를 변경해야만 default permanent tablespace를 drop

하는 것이 가능하다.

[NEWSVC]LIRACLE:/app/oracle> sqlplus system/manager

SQL*Plus: Release 10.1.0.4.0 - Production on Thu Jun 30 17:27:34 2005




Connected to:



SQL> alter database default tablespace tools;

Database altered.

SQL> create user stand identified by byme;

User created.

SQL> grant connect, resource to stand;

Grant succeeded.

SQL> conn stand/byme

Connected.

SQL> create table basic_tbs (col1 number);

Table created.

SQL> create index ik_basic_tbs on basic_tbs(col1);

Index created.

SQL> col tablespace_name for a15

SQL> col segment_name for a15

SQL> select tablespace_name, segment_name from user_segments;

TABLESPACE_NAME SEGMENT_NAME

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

TOOLS BASIC_TBS

TOOLS IK_BASIC_TBS



SQL>

사용자를 만들 때도 object를 만들 때도 tablespace를 지정하지 않았지만 default

permanent tablespace의 영향으로 모두 tablespace “TOOLS”에 segment가

생성되어 있음을 확인할 수 있다.

이제 default tablespace의 변화와 해당 user와의 상관관계를 보자.

SQL> col default_tablespace for a15

SQL> select username, default_tablespace from user_users;

USERNAME DEFAULT_TABLESP

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

STAND TOOLS


Connected.

SQL> alter database default tablespace users;

Database altered.

SQL> select property_value from database_properties

2 where property_name = 'DEFAULT_PERMANENT_TABLESPACE';

PROPERTY_VALUE

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

USERS

SQL> select username, default_tablespace from dba_users

2 where username = 'STAND';

USERNAME DEFAULT_TABLESP

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

STAND USERS

SQL>



Default permanent tablespace를 변경하자 user “STAND”의 default tablespace

가 동시에 변화 되는 것을 확인할 수 있다. 또한 현재의 default tablespace정보는

위에서처럼 database_properties에서 확인할 수 있다.

3.4.2.Rename Tablespace

대용량 database 환경에서 data를 옮기기 보다는 tablespace를 옮기는 작업이 더

많이 발생할 수 있다. 또한 한 database내에서도 필요하다면 tablespace 이름을

바꾸고 싶을 때가있다. 그러나 그 동안은 tablespace의 이름을 바꾸는 방법이 없었기

때문에 이런 요구를 해결할 수 없었다. 이제 oracle10g의 new feature인 rename

tablespace를 이용하여 이를 가능하게 할 수 있게 되었다. 형식은 다음과 같이 하면

된다.

SQL> alter tablespace current_tablespace_name rename to

new_tablespace_name;

다음은 rename tablespace의 기본 제약사항과 속성에 대한 설명이다.

1. system 및 sysaux(바로 다음 항목에서 설명된다) tablespace의 이름은 변경할 수

없다. 하지만 undo를 비롯하여 default tablespace의 이름을 바꾸는 것은 문제가

되지 않는다. 즉, 바뀐 이름이 자동으로 적용된다.

2. tablespace 자체가 offline되어 있거나 tablespace를 구성하는 datafile중 offline

이 되어 있는 datafile이 있다면 rename tablespace를 할 수 없다.

3. rename tablespace는 data dictionary, controlfile 그리고 해당 datafile의

header를 update하게 되는데 만일 작업 대상 tablespace가 read only였다면

rename 작업 시 datafile header를 변경하지 못한다. 이 경우 alert log에 datafile

header가 변경되지 않았다는 메시지를 뿌리게 되고 나중에 tablespace가 read write

의 속성으로 변경이 될 때에 datafile header가 변경된다.

4. rename tablespace 기능을 사용하기 위해선 compatibility level이 10.0.0

이상으로 설정이 되어야 한다.

CF. 만일, undo tablespace를 rename하였고 그 undo tablespace가 initial

parameter undo_tablespace로 지정이 되어 있었다면 database의 새롭게 변경된

이름의 undo tablespace를 사용하면서 해당 parameter value를 memory와 spfile

모두 동시에 변경시킨다. 그러나 spfile을 사용하고 있지 않다면 관련정보들을 alert

log에 생성하여 DBA가 직접 parameter file을 수정할 수 있도록 권고를 하게 된다.

CF. rename tablespace는 해당 tablespace를 구성하는 datafile의 이름은 건들지



않기 때문에 만일 여러분이 datafile의 이름과 tablespace의 이름을 맞추는

나름대로의 naming rule을 가지고 있다면 rename tablespace로 인한 tablespace

이름의 변경으로 관리자가 헛갈리는 일이 없도록 주의해야 한다.


Connected.


2 where username in ('SCOTT','STAND');

USERNAME DEFAULT_TABLESPACE

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

SCOTT USERS

STAND USERS

SQL> alter tablespace users rename to user_default;

Tablespace altered.


2 where username in ('SCOTT','STAND');

USERNAME DEFAULT_TABLESPACE

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

SCOTT USER_DEFAULT

STAND USER_DEFAULT

SQL>

위에서 보듯 tablespace의 이름 변경은 매우 쉽게 이루어지고 있으며 그것이 default

permanent tablespace인 경우 자동으로 그 속성까지 유지하고 있음을 확인하였다.

이런 장점이 얼마나 큰 변화인가 하는 것은 대용량 database를 운영하는데 있어서

필요에 의해 tablespace의 이름 변경의 요구를 받아본 사람이면 다 느낄 수 있다.

다음은 그 변화를 그림으로 표현한 것이다. 여기 1G정도의 data를 가진 tablespace

“ORGIN”이 있다. 이 tablespace는 oracle8i에서 만들어 진 dictionary managed

tablespace이며 oracle9i를 거처 oracle10g로 upgrade가 된 database에



존재한다. 과거 잘 몰랐던 tablespace의 locally managed 속성의 이점을 살리기

위해 이 tablespace의 속성을 locally managed tablespace를 바꾸고자 한다.

그래서 작업을 하기 위한 중간단계의 임시작업 tablespace “WORKING”을

만들었다고 가정하자.

왼쪽은 oracle10g의 기능이고 오른쪽은 oracle9i에서의 방식이다. 즉, 녹색 화살표는

oracle10g를 빨간색 화살표는 oracle9i를 뜻한다. Rename tablespace를 사용하면

중간단계의 locally managed tablespace인 “WORKING”을 만 들어 object를 copy

하고 기존 origin tablespace를 drop 한 후 rename 명령으로 working을 origin으로

변경함으로써 모든 작업이 종료되지만 oracle9i까지는 origin tablespace를 drop한

후 새롭게 locally managed tablespace인 “ORIGIN”을 다시 만들어 working

tablespace에서 object를 다시 한번 copy한 후 working tablespace를 drop하는

방식을 취해야 했다. 즉, 이러한 유형의 작업을 하는 경우 oracle10g의 rename

tablespace기능은 과거에 비해 대략 2배정도의 시간을 단축시켜 줄 것이다.

CF. 과거 버전에서는 database간의 빠른 data이동을 위해 transportable

tablespace기법을 이용해왔다. 나중에 oracle10g에서 이 기능에 어떤 향상된 점이

있는가를 점검하겠지만 그 중에 하나가 지금 설명한 rename tablespace의 이점이다.

즉, 과거에는 “A” database에서 “B” database의 tablespace를 이동할 때 해당

tablespace의 이름이 “B” database에서 사용 중 이라면 tablespace 이동이 불가

했지만 이제 이 rename tablespace 기능이 이 문제를 해결해 준 셈이다.

CF. tablespace의 이름을 변경한 후 datafile을 사용하는 recovery issue가 생기는

경우 여러분은 당황할지도 모른다. 왜냐하면 backup당시의 datafile을 가진


그림 3-4

Tablespace 이동방식의 차이


tablespace와 현재 문제가 발생한 시점의 tablespace 이름이 다른 경우에 잘못되지

않을까 하고 의심을 갖기에 충분하기 때문이다. 물론, backup본으로부터 restore된

datafile의 header는 old tablespace이름을 가지고 있지만 oracle은 이를 문제삼지

않는다. 정상적으로 recovery가 완료되면 해당 datafile header는 다시 rename된

tablespace이름을 갖는다. (물론, rename tablespace시점을 지나서 recovery가

되는 경우에 한한다)

3.4.3.SYSAUX Tablespace

현재까지 우리는 SYSTEM tablespace가 oracle database의 주요 system 정보를

가지는 objects가 존재하는 곳이라 생각해왔고 그래서 이 system tablespace는

반드시 존재해야 했다. Oracle10g부터는 “SYSAUX”라는 tablespace를 database

생성시에 반드시 같이 만들게 되는데 여기에는 oracle database components

정보들이 존재하게 된다. “SYSAUX”(system auxiliary)란 말 그대로 system

tablespace의 보조 tablespace로 system tablespace에서 dictionary외의 여러

system 관리부분을 옮겨서 담고 있는 tablespace로 이해하면 되겠다.

1. datafile의 변경이나 tablespace online/offline외에 다른 어떤 속성의 변경도

drop/rename등도 허가되지 않는다. Transportable tablespace의 대상도 될 수

없다. 다만, 이 tablespace에 존재하는 special objects를 성능상의 문제 등으로 다른

tablespace로 옮길 필요가 있을 경우에만 다음과 같은 view

“V$SYSAUX_OCCUPANTS”를 조회해서 종류별로 어떻게 옮기는 가를 확인한 후

그대로 하면 된다. 다만 아래의 SQL 결과에서 move_procedure의 값이 없는

occupants는 이동할 수 없는 것들이다. 다음의 예를 통해 특정 occupant “WM”을

다른 tablespace로 이동 하는 move작업까지 해보자.


Connected.

SQL> col occupant_name for a20

SQL> col move_procedure for a40

SQL> select occupant_name, space_usage_kbytes, move_procedure

2 from v$sysaux_occupants

3 order by 3 desc, 1;

OCCUPANT_NAME SPACE_USAGE_KBYTES MOVE_PROCEDURE

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

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

JOB_SCHEDULER 256



ORDIM 0

ORDIM/PLUGINS 0

ORDIM/SQLMM 0

SM/ADVISOR 11136

SM/AWR 72320

SM/OPTSTAT 87616

SM/OTHER 8768

STATSPACK 0

STREAMS 192

EM 77184 emd_maintenance.move_em_tblspc

XDB 47360 XDB.DBMS_XDB.MOVEXDB_TABLESPACE

LOGSTDBY 896 SYS.DBMS_LOGSTDBY.SET_TABLESPACE

LOGMNR 7488 SYS.DBMS_LOGMNR_D.SET_TABLESPACE

ULTRASEARCH 0 MOVE_WK

ODM 0 MOVE_ODM

SDO 3456 MDSYS.MOVE_SDO

TEXT 0 DRI_MOVE_CTXSYS

XSOQHIST 18112 DBMS_XSOQ.OlapiMoveProc

WM 5952 DBMS_WM.move_proc

AO 18112 DBMS_AW.MOVE_AWMETA

XSAMD 15872 DBMS_AMD.Move_OLAP_Catalog

22 rows selected.

SYS> exec dbms_wm.move_proc('TOOLS');


CF. 최초 database생성시 sysaux tablespace의 default 속성은 “permanent/read

write/extent manage local/segment space management auto”이며 변경될 수

없다.

2. tablespace관리의 부담이 줄어들었다. 앞서 설명하였듯 oracle9i까지 oracle

features는 각각 자신만의 tablespace를 가지고 운용이 되었기 때문에 경우에 따라

매우 많은 tablespace를 관리해야 했었다. 그러나 이제 이러한 features는 모두

sysaux tablespace를 기본으로 사용하게 된다. 예를 들면 XDB, CWMLITE(OLAP),



ODM(MINING)등이 sysaux tablespace내에 자리를 잡게 된다. 이는 곧 사용되는

datafiles의 수도 줄이는 효과와 더불어 RAC 환경에서는 raw device관리 부담도

덜어주는 부수적 효과도 있다.

CF. 또한 일부 system tablespace에 있던 objects도 sysaux로 옮겨지면서 system

tablespace에 대한 부담을 줄일 수 있게 되었다.

다음은 sysaux tablespace와 과거 features간의 storage변화의 예이다.

SYSAUX in oracle10g Oracle9i

Text, Ultra Search DRSYS

Intermediate, spatial SYSTEM

OLAP CWMLITE

XML DB XDB_RESINFO

Workspace Manager SYSTEM

Data Mining ODM

Recovery catalog TOOLS

EM repository OEM_REPOSITORY

Analytical Workspace Object table SYSTEM

LogMiner, Log Standby, streams SYSTEM

Statspack User-specified

Scheduler New in oracle10g

Server Manageability Components New in oracle10g

3.4.4.Transportable Tablespace

3.4.4.1. 개요Oracle9i까지 사용되었던 transportable tablespace 기능은 대용량 database간의

많은 data이동을 손쉽게 해주는 역할을 해왔다. 그러나 platform과 database

version의 차이에 따라 그 사용에 제한이 있었던 것이 사실이다. 그러나 이제

oracle10g에서는 대부분의 platform에 대하여 이 기능을 지원하게 되었고 이를

“cross-platform transportable tablespace”라 부른다. 물론, 대상 tablespace는

dictionary managed이거나 locally managed이거나 상관없다.

CF. 따라서 이 기능은 data이동이 아니라 database를 다른 platform의 database로

migration하는 데에도 유용할 수 있다.


표 3-4

SYSAUX 내역


CF. 또한 read only tablespace가 이 기종 platform상에서 동시에 access 가능한

storage system상의 datafiles로 구성이 되어 있다면 이 기종 platform간의 서로

다른 database가 이 tablespace를 같이 공유할 수도 있다. 물론, 두 기종간의 endian

format이 같아야 가능한 구성이다. (endian format은 나중에 설명한다)

3.4.4.2. 기본 조건다음 현재 지원이 되고 있는 platform에 대한 정보이다.

Solaris[tm] OE (32-bit) HP-UX (64-bit)Microsoft Windows IA (64-

bit)

Solaris[tm] OE (64-bit) HP Tru64 UNIX IBM zSeries Based Linux

Microsoft Windows IA (32-

bit)

HP-UX IA (64-

bit)Linux 64-bit for AMD

Linux IA (32-bit)Linux IA (64-

bit)Apple Mac OS

AIX-Based Systems (64-bit) HP Open VMSMicrosoft Windows 64-bit for

AMD

다음은 transportable tablespace의 기본조건들이다.

1. source와 target database는 모두 동일한 character set과 national character

set을 가져야 한다.

2. 기본적으로 move하려는 tablespace가 target database에 존재하는 tablespace

이름과 중복이 되면 move할 수가 없지만 앞서 배운 방식 그대로 해당 tablespace를

rename하고 작업을 진행하면 가능하다.

3. transportable tablespace set에 포함되지 않은 underlying objects(M-View등)

와 contained objects(partitioned table등)은 이동할 수 없다.

4. system, sysaux tablespace는 transportable tablespace의 대상이 아니며 또한

sys 소유의 objects도 이동할 수 없다.

5. cross-platform transportable tablespace를 하려면 source와 target 모두가 다

compatibility가 10.0 이상인 경우만 가능하다.

6. cross-platform으로 tablespace를 이동한다는 의미는 대상 datafiles이 platform-

aware상태여야 한다는 뜻이다. 이 말은 compatibility 10.0 이상의 database에서

datafile이 open될 때 header block에 그 정보가 이식되기 때문이다. 따라서 현재

database의 compatibility가 10.0 이상이어도 read only tablespace의 경우

compatibility가 10.0 보다 적은 때에 open되어 read only로 변경된 후 아직 한번도

compatibility 10.0 이상에서 open된 적이 없는 tablespace가 있다면 이

tablespace도 cross-platform 간의 tablespace 이동은 할 수가 없을 것이다. 이런



경우에는 해당 datafile들을 compatibility 10.0 이상에서 한번 이상 read write로

변경한 후에 작업을 해야 한다. (물론, offline datafiles도 online으로 한번 이상

변경한 후에 작업을 해야 한다.)

다음은 최소 compatibility와 transportable tablespace matrix의 예이다.

Transport Scenario Source

Database

Target

Database

동일 platform상의 database 8.0 8.0

Block size가 다른 tablespace 9.0 9.0

Databases on different platforms 10.0 10.0

7. cross-platform으로 tablespace 이동 시 각 platform간의 endian format이

일치해야 한다. 그러나 서로 다른 endian format을 가진 경우엔 datafile convert

작업을 진행하면 tablespace이동이 가능하다.

CF. oracle10g release 2부터는 RMAN을 이용하여 tablespace가 online인

상태에서도 transportable 기능을 사용할 수 있게 된다.

3.4.4.3. Endian Format

다음은 앞서 잠깐씩 언급되었던 endian format에 대한 소개이다. 간단하게 그 의미를

파악을 해보면 다음과 같다. 이 format은 여러 바이트가 하나의 데이터를 저장할 때

(multi-byte) big endian과 little endian으로 나뉘는데 우리가 문장을 “왼쪽에서

오른쪽으로 읽는가, 오른쪽에서 왼쪽으로 읽는가”처럼 byte를 저장할 때 그 순서에

따라 이 형식이 정해진다. 즉, byte order가 어떻게 되어 있느냐의 차이다.(이 용어는

걸리버 여행기의 난쟁이와 거인의 관계로부터 파생되었다고 한다)

1. big endian : 큰 쪽 (바이트 열에서 가장 큰 값)이 먼저 저장 (most significant

byte를 최하위 메모리에 저장)

2. little endian : 작은 쪽 (바이트 열에서 가장 작은 값)이 먼저 저장 (least

significant byte를 최하위 메모리에 저장)

그렇다면 transportable tablespace를 cross-platform에 적용시킬 때 어떻게 확인할

수 있을까. Oracle은 이를 쉽게 알 수 있도록 다음과 같이 지원 가능한 platform list,

endian format(v$transportable_platform )과 자기 자신의

platform(v$database)을 알 수 있는 query를 제공하고 있다.


Connected.

SQL> col platform_name for a40


표 3-5

Compatible과

Tablespace 이동


SQL> col endian_format for a10

SQL> set pagesize 20

SQL> select * from v$transportable_platform order by platform_id;

PLATFORM_ID PLATFORM_NAME ENDIAN_FOR

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

1 Solaris[tm] OE (32-bit) Big

2 Solaris[tm] OE (64-bit) Big

3 HP-UX (64-bit) Big

4 HP-UX IA (64-bit) Big

5 HP Tru64 UNIX Little

6 AIX-Based Systems (64-bit) Big

7 Microsoft Windows IA (32-bit) Little

8 Microsoft Windows IA (64-bit) Little

9 IBM zSeries Based Linux Big

10 Linux IA (32-bit) Little

11 Linux IA (64-bit) Little

12 Microsoft Windows 64-bit for AMD Little

13 Linux 64-bit for AMD Little

15 HP Open VMS Little

16 Apple Mac OS Big

17 Solaris Operating System (x86) Little

16 rows selected.

SQL> select platform_name from v$database;

PLATFORM_NAME

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

Linux IA (32-bit)

SQL>

위 내용을 알고 있어야만 cross-platform tablespace 이동을 할 때 endian format이

일치하는가를 미리 확인할 수 있으며 만일 다를 경우 oracle RMAN utility를 통해



endian format을 맞추는 과정을 해야만 한다.

우리가 endian format과 관련하여 주의할 점이 하나 더 있다. 현재 transport할

tablespace에 CLOB data가 포함되어 있다면 다음과 같은 점을 알고 있어야 한다.

1. oracle10g 이전의 CLOB은 USC2 character로 표현되지만 oracle10g부터는

AL16UTF16으로 표현된다.

2. AL16UTF16은 endian-independent하며 big-endian USC2 CLOB은

AL16UTF16과 같음으로 conversion작업이 필요 없다.

3.little-endian CLOB은 AL16UTF16으로 transport할 때 conversion이 필요하며 이

경우 CLOB이 access될 때 즉, run-time시에 oracle이 자동으로 conversion처리를

한다.

4. 위 3과 같은 run-time overhead를 피하고 싶다면 create table as select를 통해

재생성을 함으로써 oracle이 자동으로 AL16UTF16으로 변환하게 하면 된다.

3.4.4.4. 이 기종간 tablespace 이동절차다음은 일반적인 cross-platform transportable tablespace 절차이다.

1. tablespace의 mode변경 : alter tablespace tbs_name read only;

2. 메타데이터 export(option) : transport_tablespaces= tbs_name

dumpfile=exp_tbs.dmp

3. dump file과 해당 tablespace의 datafile을 대상 서버로 copy

4. 메타데이터 import(option) : transport_

datafiles='/oracle/oradata/datafile_name.dbf' dumpfile=exp_tbs.dmp

앞서 만들었던 “CRT10G”를 open하여 각 instance가 서로 다른 장비에 있다고

가정하고 간단한 tablespace 이동 작업을 진행을 하고자 한다. 그러나 작업에 앞서서

transportable tablespace의 전제 조건 중 하나인 character set을 먼저 확인하여

source 와 target database를 맞춘 후 진행한다.

첫 번째 창에서 target database의 character set을 먼저 확인한다.

[NEWSVC]LIRACLE:/app/oracle> sqlplus "/as sysdba"

SQL*Plus: Release 10.1.0.4.0 - Production on Mon Jul 11 10:09:10 2005


Connected to:





SQL> col parameter for a30

SQL> col value for a30

SQL> select * from nls_database_parameters

2 where parameter like '%CHARACTERSET%';

PARAMETER VALUE

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

NLS_NCHAR_CHARACTERSET AL16UTF16

NLS_CHARACTERSET KO16KSC5601

SQL>

다른 창에서 source database의 character set을 확인한다.

[NEWSVC]LIRACLE:/app/oracle> export ORACLE_SID=CRT10G

[CRT10G]LIRACLE:/app/oracle> sqlplus "/as sysdba"



Connected to an idle instance.

SQL> startup







Database mounted.

Database opened.



SQL> col parameter for a30

SQL> col value for a30

SQL> select * from nls_database_parameters

2 where parameter like '%CHARACTERSET%';

PARAMETER VALUE

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

NLS_NCHAR_CHARACTERSET AL16UTF16

NLS_CHARACTERSET WE8ISO8859P1

SQL>

위 두 결과로 national character set은 같지만 character set이 서로 틀린 것을

확인하였다. 만일, 앞서 “CRT10G”를 만드는 scripts에서 character set을

변경하였다면 아무 문제가 없었고 아래 character set 변경과정을 할 필요가 없겠지만

default로 만든 경우라면 위에서처럼 character set이 틀린 것을 보게 될 것이다.

계속해서 이 두 번째 창에서 source database의 character set을 target database

와 동일하게 맞추어 보자.

CF. 사실, 이 작업을 하기 위해선 “$ORACLE_HOME/bin/csscan”을 통해 character

set의 변경에 별다른 문제가 없는가를 먼저 확인한 후 만일의 경우의 data 보존을 위해

backup절차를 먼저 수행해야 한다.

SQL> shutdown immediate;

Database closed.



SQL> startup mount;







Database mounted.



SQL> alter system enable restricted session;

System altered.

SQL> alter system set job_queue_processes=0;

System altered.

SQL> alter system set aq_tm_processes=0;

System altered.

SQL> alter database open;

Database altered.

SQL> alter database character set KO16KSC5601;

alter database character set KO16KSC5601

*

ERROR at line 1:

ORA-12712: new character set must be a superset of old character set

SQL>

위와 같은 절차를 통해 character set을 변경하면 되지만 현재는 error가 나타났다.

그것은 최초 “CRT10G”를 만들 때에 character set을 변경하지 않고 default 값을

사용했기 때문에 “CRT10G”는 “WE8ISO8859P1”로 만들어 졌고 따라서

KO16KSC5601 와 WE8ISO8859P1 두 character set은 둘 다 multiple byte

character set임으로 서로간에 super character set 관계가 성립되지 않기 때문이다.

즉, 위에서 보듯 error가 발생하는 것은 single-byte character set을 multi-byte

character set으로 바꾸는 superset 관계만이 가능하다는 증거이다. 따라서 현재로선

“CRT10G” database를 다시 만들지 않고서는 이를 해결할 수가 없다.

만일, 여러분의 각자 환경에서 위 작업이 성공했거나, “CRT10G”를 다시 만들었거나,



또는 최초 database 생성시 character set을 target database와 동일하게

설정했다면 다음의 과정을 통해 transportable tablespace 작업을 해볼 수 있다.

“CRT10G” 창에서 계속해서 다음 과정을 진행한다.

CF. 만일 제대로 character set을 변경하여 성공을 했다면 아래 과정을 진행하기 전에

“shutdown immediate”, “startup restrict”를 먼저 수행한 후 진행한다.

SQL> shutdown immediate

Database closed.



SQL> startup







Database mounted.

Database opened.

SQL> create tablespace trans_sum datafile

2 '/app/oracle/oradata/CRT10G/trans01.dbf'

3 size 10M;

Tablespace created.


Connected.

SQL> create table x_trans (x number)

2 tablespace trans_sum;

Table created.

SQL> insert into x_trans values (1);



1 row created.

SQL> commit;

Commit complete.

SQL>

이제 앞서 배운 절차대로 진행해보자. 먼저 tablespace 속성을 변경시키고 export를

한다. 최종적으로 datafile을 다른 위치로 copy하여 마치 다른 database로 datafile이

copy하는 것처럼 가정할 것이다.

SYS> create directory dirpumpx as '/app/oracle/temp';

Directory created.

SQL> alter tablespace trans_sum read only;

Tablespace altered.

SYS> exit




[CRT10G]LIRACLE:/app/oracle> export DATA_PUMP_DIR=DIRPUMPX

[CRT10G]LIRACLE:/app/oracle> expdp transport_tablespaces=trans_sum

dumpfile=trsns_sum.dmp

Export: Release 10.1.0.4.0 - Production on Tuesday, 01 November, 2005

10:44


Username: sys/manager as sysdba




Production


Starting "SYS"."SYS_EXPORT_TRANSPORTABLE_01": sys/******** AS SYSDBA

transport_tablespaces=trans_sum dumpfile=trsns_sum.dmp

Processing object type TRANSPORTABLE_EXPORT/PLUGTS_BLK

Processing object type TRANSPORTABLE_EXPORT/TABLE

Processing object type TRANSPORTABLE_EXPORT/TABLE_STATISTICS


TRANSPORTABLE_EXPORT/TTE_POSTINST/PLUGTS_BLK

Master table "SYS"."SYS_EXPORT_TRANSPORTABLE_01" successfully

loaded/unloaded

*****************************************************************************

*

Dump file set for SYS.SYS_EXPORT_TRANSPORTABLE_01 is:

/app/oracle/temp/trsns_sum.dmp

Job "SYS"."SYS_EXPORT_TRANSPORTABLE_01" successfully completed at

10:45

[CRT10G]LIRACLE:/app/oracle> ls -l ./temp/trs*

-rw-r----- 1 oracle dba 69632 Nov 1 10:45 ./temp/trsns_sum.dmp

[CRT10G]LIRACLE:/app/oracle> cp

/app/oracle/oradata/CRT10G/trans01.dbf ./temp/

[CRT10G]LIRACLE:/app/oracle> ls -l ./temp/trans01.dbf

-rw-r----- 1 oracle dba 10493952 Nov 1 11:00 ./temp/trans01.dbf

이제 3단계를 진행하기 위해 해당 dumpfile을 copy하면 되는데 현재는 한 서버에서

작업을 하고 있지만 마치 다른 서버라고 가정하고 있는 것임으로 dumpfile 및 해당

datafile “trans01.dbf”를 다른 target 서버의 “/app/oracle/temp”로 copy했다고

생각하자. 이제 마지막 4단계를 해보자. 다음은 target database창이다.

[NEWSVC]LIRACLE:/app/oracle> cd temp

[NEWSVC]LIRACLE:/app/oracle/temp> sqlplus / as sysdba

SQL*Plus: Release 10.1.0.4.0 - Production on Tue Nov 1 11:04:41 2005




Connected to:



SYS> create directory dirpumpx as '/app/oracle/temp';

Directory created.

SYS> exit




[NEWSVC]LIRACLE:/app/oracle/temp> export DATA_PUMP_DIR=DIRPUMPX

[NEWSVC]LIRACLE:/app/oracle/temp> impdp

transport_datafiles='/app/oracle/temp/trans01.dbf'

dumpfile=trsns_sum.dmp

Import: Release 10.1.0.4.0 - Production on Tuesday, 01 November, 2005

11:17


Username: sys/manager as sysdba


Production


Master table "SYS"."SYS_IMPORT_TRANSPORTABLE_01" successfully

loaded/unloaded

Starting "SYS"."SYS_IMPORT_TRANSPORTABLE_01": sys/******** AS SYSDBA

transport_datafiles=/app/oracle/temp/trans01.dbf dumpfile=tr

sns_sum.dmp



Processing object type TRANSPORTABLE_EXPORT/PLUGTS_BLK

ORA-39123: Data Pump transportable tablespace job aborted

ORA-29345: cannot plug a tablespace into a database using an incompatible

character set

Job "SYS"."SYS_IMPORT_TRANSPORTABLE_01" stopped due to fatal error at

11:17

[NEWSVC]LIRACLE:/app/oracle/temp> rm trans01.dbf

[NEWSVC]LIRACLE:/app/oracle/temp>

물론, 위에서는 error가 나타났지만 여러분의 테스트한 환경에서 두 database간의

character set이 일치했다면 아무런 문제가 없이 성공했을 것이다. 나중의 테스트를

위해 현재 위의 마지막 작업으로 copy했던 datafile을 삭제하였다.

CF. 물론, 애초에 character set을 맞추어 놓고서 예제를 보여주었으면 아주 간단히

작업을 끝낼 수 있으나 다양한 경우의 수를 보여주기 위하여 여러 형태의 작업과정을

보여주려고 위와 같은 error는 불가피하였음을 이해해 주시기 바란다. 여러분의

database의 character set이 일치했다면 위 과정은 정상적으로 진행될 것이고

작업이 끝난 후 scott 계정으로 접속하여 “X_TRANS”의 data를 볼 수 있었을 것이다.

위 절차는(절차대로 보자면) oracle10g 이전에 사용한 exp/imp의 transportable

tablespace방식과 그다지 많이 달라진 것은 없다. 그러나 만일, source 서버와 target

서버가 cross-platform이었다면 위 과정은 결국 실패했을 것이다. 그러나 oracle10g

부터는 아무 문제없이 성공이 된다는 것이다. 물론, 위 과정이 cross-platform이며

또한 endian format이 달랐다면 역시 실패하게 된다. 이 경우엔 3단계와 4단계

사이에 endian format을 맞추는 과정이 필요하다.

예를 들어 위 trans_sum tablespace를(trans01.dbf) source 서버가 Linux(little

endian)이고 target 서버가 AIX(big endian)이면 다음과 같은 형식으로 변환작업을

수행한 후에 4단계로 넘어가야 한다.

테스트를 위해 trans_sum tablespace(trans01.dbf)를 AIX 장비로 copy한다는

전제하에 little endian format을 big endian format으로 convert작업을

진행해보자. 물론, 이 작업은 source system이나 target system중 아무 곳에서

작업을 해도 무방하지만 일반적으로 target system에서 한다. 그 이유는 source



system의 tablespace mode를 read write로 변환시키는 시간이 짧아진다는 장점이

있고 또한 대부분의 시스템에서 이런 작업은 source data를 summary성 작업을 하는

target database로 이동하는데 주로 사용함으로 source system의 성능에 부하를

주지 않고 작업을 진행할 수 있기 때문이다. 여기서는 테스트 환경상 source system

에서 작업의 예를 살펴보자.

다음은 source system인 “CRT10G” database이다.

[CRT10G]LIRACLE:/app/oracle> cd temp

[CRT10G]LIRACLE:/app/oracle/temp> rman target=/

Recovery Manager: Release 10.1.0.4.0 - Production


connected to target database: CRT10G (DBID=3002645912)

RMAN> convert tablespace trans_sum

2> to platform = 'AIX-Based Systems (64-bit)'

3> db_file_name_convert = '/app/oracle/oradata/CRT10G',

'/app/oracle/temp';

Starting backup at 11-JUL-05

using target database controlfile instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=535 devtype=DISK

channel ORA_DISK_1: starting datafile conversion

input datafile fno=00005 name=/app/oracle/oradata/CRT10G/trans01.dbf

converted datafile=/app/oracle/temp/trans01.dbf

channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:03

Finished backup at 11-JUL-05

RMAN> exit

Recovery Manager complete.



[CRT10G]LIRACLE:/app/oracle/temp> ls -l trans*

-rw-r----- 1 oracle dba 10493952 Jul 11 13:39 trans01.dbf

[CRT10G]LIRACLE:/app/oracle/temp> sqlplus "/as sysdba"



Connected to:



SQL> alter tablespace trans_sum read write;

Tablespace altered.

SQL>

이제 위 file을 IBM AIX장비로 copy하여 4단계부터 transportable tablespace

작업을 진행하면 된다.

CF. 만일, 위 cross-platform간의 처리를 위한 convert작업을 target system에서

하려고 했다면 해당 files을 copy한 후 “convert tablespace”가 아니라 “convert

datafile” 명령을 사용해야 하며 “to”가 아닌 “from”절을 사용해야 했을 것이다.

예를 들어 위 과정을 AIX장비로 files을 copy한 후 convert작업을 하려 했다면 다음과

같은 형식으로 진행을 해야 한다.

RMAN> convert datafile '/app/oracle/temp/trans01.dbf'

2> from platform='Linux IA (32-bit)'

3> db_file_name_convert='/app/oracle/temp/trans01.dbf',

'/app/oracle/temp/trans01_linux.dbf';

Starting backup at 11-JUL-05

using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile conversion



input filename=/app/oracle/temp/trans01.dbf

converted datafile=/app/oracle/temp/trans01_linux.dbf

channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:00

Finished backup at 11-JUL-05

3.4.5.Big File Tablespace

Database의 추세가 점점 더 대용량화가 되어 가면서 VLDB(Very Large DataBase)

에 대한 요구들도 증가하고 있다. 이번에 oracle10g에서는 이러한 VLDB의 요구에

맞추어 대용량 file을 지원하는 tablespace가 소개되었다. 이런 feature의 소개로 인해

기존의 multiple small datafiles을 갖는 tablespace와 대용량 big datafile을 갖는

tablespace를 구분하기 위하여 bigfile tablespace와 smallfile tablespace라는

용어를 사용하게 된다.

3.4.5.1. Bigfile Tablespace의 주요 특징과 속성1. 하나의 datafile이 최대 40억 data blocks까지 가질 수 있다.

2. 최대 file size는 4TB에서 128TB까지 가능하다.

3. 이러한 대용량 file을 생성하기 위해서 oracle10g에서는 새로운 addressing

기법을 도입하였다.

4. 이런 대용량 tablespace은 하나의 datafile을 갖도록 설계되며 따라서 tablespace

와 해당 datafile은 논리적으로 동일하다. 그러므로 기존에 datafile에 대하여 사용하던

모든 operations은 bigfile tablespace를 대상으로 수행할 수 있다. (즉, bigfile

tablespace는 datafile transparent하기 때문에 datafile operation과 bigfile

tablespace operation이 같다. 예를 들면 alter tablespace를 통한 resize 명령이

유효하다는 말이다)

5. tablespace의 관리를 locally management로 하여 bitmap segment를

사용해야 하며 동시에 automatic segment space로 설정해야 한다. 이는 data

dictionary 방식으로는 bigfile tablespace처럼 대용량 tablespace에 대한

addressing을 할 수가 없기 때문이다.

6. bigfile을 사용함으로 해당 file은 stripping, mirror등의 (RAID)관리가 확실해야

한다. Logical volume manager나 앞으로 소개되는 oracle10g의 ASM(Automated

Storage Management)과 같은 기능을 이용하여 file관리를 제대로 함으로써 bigfile

을 대상으로 하는 parallel과 같은 방식의 data scan 또는 RMAN의 parallel 작업과

같은 문제들을 확실히 피해야 한다.

7. bigfile tablespace내의 extent 관리는 최초 tablespace creation시 지정하는

extent management local에 의해 결정되는데 default로 적용하는

“AUTOALLOCATE”를 통해 oracle 스스로 판단하도록 하는 것이 좋다. 원한다면



“UNIFORM SIZE ?”를 지정해도 좋지만 이 경우엔 oracle에 추천하는 다음과 같은

기준을 벗어나지 않도록 하자.

Block Size Maximum Extent 수

2KB 100,000

4KB 200,000

8KB 400,000

16KB 800,000

32KB 1,600,000

CF. 이런 recommend 사항을 무시하게 되면 동시 사용자의 접근이나 DDL operation

과 같은 작업 시 performance에 대한 손해를 감수할 수도 있다.

CF. 사실 위에서 32KB block size에 대한 oracle recommend value는 찾을 수

없었으나 내용적으로 볼 때 160만으로 추측된다.

3.4.5.2. Bigfile Tablespace의 이점다음은 이러한 bigfile tablespace를 사용하게 됨으로써 얻어지는 이점들이다.

1. oracle database가 사용 가능한 data 용량을 대폭 향상 시켰다.

(D X F X B = 8EB(8백만 TB)까지 database 용량을 확장할 수 있고 이는 database

의 용량 한계를 거의 느낄 수 없는 크기이다)

2. 단일 big file을 지원하는 tablespace의 사용으로 매우 많은 small datafiles를

사용할 때와 달리 datafile의 수가 줄어듦으로 DBA의 datafile의 관리가 편해졌다.

3. OS상의 disk 관리를 포함하여 backup and recovery에도 관리상의 편이를

증가시킬 수 있다.

4. 이런 효과들은 부수적으로 SGA의 datafile information을 위한 space나

controlfile size에 대한 감소효과를 줄 수 있으며(db_files parameter 값의 조정이나

controlfile생성에 사용되는 maxdatafiles 값의 조정) 또한 database open,

checkpoint, DBWR의 처리 시간 등에 향상을 줄 수 있다. (반대로 recovery같은

작업을 위해 필요한 datafile restore나 creation 등의 작업 시간은 더 늘어날 수 있는

단점도 있다)

CF. database의 저장용량을 계산하는 단위의 의미는 다음과 같다.

D : 최대 datafiles 수, F : 최대 blocks 수(per datafile), B : 최대 block size

CF. 이전 버전의 F는 4M이었으나 oracle10g부터 4G까지 확장 되었다. (앞서 40억

blocks까지 가질 수 있다고 이미 설명한 바 있다) 따라서 oracle database의 용량은


표 3-6

Block size와

Uniform size


최대 datafiles 수(64KB)와 최대 block size(32KB)기준으로 oracle10g 이전, 최대

8PT에서 oracle10g의 8EB까지 늘어난 것이다.

3.4.5.3. Create and Alter Tablespace with New Type

Tablespace를 생성할 때 이제 bigfile인가, smallfile인가를 구분할 필요가 생겼다.

새로운 기능에 따라 option도 설정할 필요가 생긴 것이다. 기본적인 syntax는 다음과

같다.

SQL> create [bigfile | smallfile] [undo | (default) temporary] tablespace

tbs_name ……

Tablespace 생성시 위 option을 직접 지정하면 되지만 보통은 이를 지정하지 않고

사용하게 된다. 그러나 default tablespace type이 위 2개중 일정하게 정해진 것이

아니라 database를 생성할 때나 또는 alter database 명령으로 속성을 변경하는

절차를 통해 지정된 default tablespace type이 위 2개중 하나이고 이것이 default로

적용된다. 따라서 default tablespace type이 bigfile이면 option이 없이 만들어지는

모든 tablespace는 locally management에 automatic space management

속성을 가지게 될 것이다.

다음의 예는 alter 명령으로 default tablespace type을 설정하는 예이다.

SQL> alter database set default [bigfile | smallfile] tablespace;

다음은 bigfile tablespace를 사용하여 datafile operation을 하는 예이다. 이러한

것들이 bigfile tablespace가 datafile transparent하다는 용어의 의미이다.


Connected.

SQL> create bigfile tablespace bigdata datafile

2 '/app/oracle/oradata/NEWSVC/big01.dbf' size 10M;

Tablespace created.

SQL> alter tablespace bigdata resize 50M;

Tablespace altered.

SQL> alter tablespace bigdata autoextend on;



Tablespace altered.

SQL> !ls -l /app/oracle/oradata/NEWSVC/big*

-rw-r----- 1 oracle dba 52436992 Jul 25 16:48

/app/oracle/oradata/NEWSVC/big01.dbf

위 예에서 alter tablespace 명령으로 datafile operation이 제대로 이루어지고

있음을 확인할 수 있다. 마지막에 file size를 보면 최초 10M에서 50M로 늘어난 것도

확인이 된다.

CF. oracle10g에서 bigfile tablespace가 소개되면서 과거 size를 지정할 때 사용하던

K, M에 추가적으로 G(Giga), T(Tera)를 사용할 수 있게 되었다.

다음은 bigfile tablespace feature로 인한 dictionary의 변화를 알아보자.

SQL> select name, bigfile from v$tablespace

2 where name in ('BIGDATA', 'TOOLS');

NAME BIG

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

TOOLS NO

BIGDATA YES

SQL> select tablespace_name, bigfile from dba_tablespaces

2 where tablespace_name in ('BIGDATA', 'TOOLS');

TABLESPACE_NAME BIG

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

BIGDATA YES

TOOLS NO


2 where property_name = 'DEFAULT_TBS_TYPE';

PROPERTY_VALUE

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



SMALLFILE

3.4.5.4. Management Bigfile Tablespace

Oracle은 datafile의 문제점들을 확인하기 위하여 dbverify를 제공하며 이는

전통적으로 OS 상에서 dbv라는 명령을 통해 수행해 왔다. 그리고 특정 tablespace의

datafiles을 이런 dbv를 통해 검증할 때 그 성능의 향상을 위해 각각의 datafiles을

한번에 수행하는 방법을 사용했지만 single datafile을 갖는 bigfile tablespace의

경우 이러한 방식은 사용할 수가 없다. 그러나 해당 datafile의 start block과 end

block을 지정하는 방식으로 bigfile tablespace의 parallel dbv도 가능하다.

예를 들어 smallfile tablespace인 sft_data의 datafile이 sft01.dbf 와 sft02.dbf로

이루어져 있고 bigfile tablespace인 big_data는 100 blocks으로 구성된 bft01.dbf

로 이루어져 있다고 가정하자. 둘 간의 parallel dbv를 사용한다면 아래와 같은 방식이

가능할 것이다.

Smallfile tablespace : 동시에 다음을 수행한다.

#1 창>

$ dbv file=sft01.dbf

#2 창>

$ dbv file=sft02.dbf

Bigfile tablespace : 동시에 다음을 수행한다.

#1 창>

$ dbv bft01.dbf start=1 end=50

#2 창>

$ dbv bft01.dbf start=51

CF. dbv와 달리 package로 제공하는 dbms_utility의 file및 block address를 return

받기 위해 사용하는 data_block_address_file(), data_block_address_block()

function은 tablespace type을 가지지 않기 때문에 bigfile tablespace를 대상으로

사용할 수 없다. (사실 single file을 갖는 bigfile tablespace의 file number는 file이

1개 뿐임으로 항상 1024이다)

CF. 이미 정해진 tablespace의 type을 바꿀 수는 없지만 각 tablespace내에 존재하는

objects의 이동함으로써 smallfile tablespace와 bigfile tablespace간의 objects

migration은 가능하다. (사실 특별한 기능을 사용하는 것이 아니라 “alter table

move(index rebuild)”나 “create table… as select …”, “datapump”와 같은

기존의 명령이나 data utility를 이용한다)



3.4.5.5. Bigfile Tablespace ROWID

Oracle8에서 VLDB를 주창하면서 partitioned object개념이 소개되었고 더불어

ROWID가 확장되었다. 그래서 extended ROWID는 다음과 같은 구조를 가지게 된다.

OOOOOO FFF BBBBBB

RRR

O : segment를 구별하는 data object number

F : relative file number(rows를 가지고 있는 tablespace내의 file number)

B : rows를 가지고 있는 block number(F가 틀리면 B는 여러 rows가 같은 값을 가질

수 있다)

R : slot number (block내의 row number)

Oracle10g에서는 bigfile tablespace가 소개되었고 이는 single file로 이루어 짊으로

file number는 의미가 없게 되었다. (항상 1024이다) 따라서 bigfile tablespace

전체를 통틀어 모든 rows의 block number는 항상 unique함으로 rowid에 file

number가 필요하지 않다. 그러므로 oracle10g의 bigfile tablespace내 rows의

rowid는 “data object number-block number-row number”로 구성이 된다.

OOOOOO LLL LLLLLL RRR

L : encoding을 통해 F와 B를 상징하도록 하여 40억 개의 blocks을 가질 수 있도록

unique한 block id가 만들어 질 수 있다.

이렇게 다른 형식을 갖는 bigfile tablespace를 사용하는 table data의 extended

rowid components를 추출하기 위해서는 dbms_rowid package를 사용해야 한다.

그러나 oracle10g이전 version의 database를 대상으로 rowid components를

추출하는 applications이 이미 존재하고 있고 그 applications이 dbms_rowid를

사용하지 않았다면 oracle10g로 upgrade된 database의 bigfile tablespace를

대상으로 하는 해당 작업들은(extended rowid components) 문제가 될 수 있을

것이다. 따라서 굳이 필요에 의해 bigfile tablespace내 rows의 rowid components

operation을 하려면 이와 같은 사항들을 미리 점검할 필요가 있겠다.

지금 살펴본 것처럼 bigfile tablespace와 smallfile tablespace의 extended rowid

format이 다르기 때문에 dbms_rowid package중에서 relative file number와

block number를 처리하는 function과 procedure는 변경이 필요하다. Tablespace

type에 따라서 다른 결과가 나타나야 하기 때문이다. 보통 전체 rowid 정보를 추출하는

procedure rowid_info와 file 및 block number를 return하는 functions에

tablespace type을 지정하는 argument가 추가된 것이다. 다음은 두 가지 function



에 대한 예이다. 먼저 간단한 테스틀 위해 bigfile tablespace내에 object를 생성하고

환경을 확인한다.


Connected.

SQL> create table x_rowid (a number);

Table created.

SQL> insert into x_rowid values (1);

1 row created.

SQL> commit;

Commit complete.

SQL> create table x_big_rowid tablespace bigdata

2 as select * from x_rowid;

Table created.

SQL> select rowid from x_rowid where rownum = 1;

ROWID

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

AAAOiCAAQAAAneXAAA

SQL> select rowid from x_big_rowid where rownum = 1;

ROWID

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

AAAOiDAAAAAAAAUAAA

이제 functions을 수행하여 결과를 확인해 보자.

SQL> select dbms_rowid.rowid_relative_fno(rowid, 'SMALLFILE') "sf",



2 dbms_rowid.rowid_block_number(rowid, 'SMALLFILE') "sb"

3 from x_rowid where rownum = 1;

sf sb

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

16 161687

SQL> select dbms_rowid.rowid_relative_fno(rowid, 'BIGFILE') "bf",

2 dbms_rowid.rowid_block_number(rowid, 'BIGFILE') "bb"

3 from x_big_rowid where rownum = 1;

Bf bb

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

1024 20

3.4.6.Temporary Tablespace Group

전통적인 oracle의 temporary tablespace는 그 개수는 상관이 없지만 이를 사용하는

계정들은 각각 1개의 temporary tablespace만을 사용하도록 계정마다 직접 지정을

해왔다. 또한 oracle9i부터는 각 계정에 temporary tablespace를 직접 지정을 하지

않으면 그 이전(oracle8i까지는 system tablespace를 사용) oracle과 달리 default

temporary tablespace가 자동으로 지정이 되었다.

Oracle10g는 이번 temporary tablespace group이라는 feature를 소개한다. 기본

속성은 다음과 같다.

1. 하나의 temporary tablespace group은 최소 1개 이상의 temporary

tablespace로 구성이 되며 그 개수에 제한은 없다.

2. group과 tablespace는 namespace가 동일함으로 서로 이름이 틀려야 한다. 이는

곧 temporary tablespace를 지정하는 어떤 곳에서나 temporary tablespace대신

그 group name을 사용할 수 있다는 의미이다. 따라서 temporary tablespace 한

개를 직접 지정하지 않고 group을 지정하면 group내 temporary tablespace들을

모두 사용할 수 있다.

3. temporary tablespace group은 group만을 따로 만들지 못하며(not explicitly

created) 최초 temporary tablespace를 assign할 때 자동으로 만들어진다. 또한

group내의 모든 temporary tablespace가 drop되면 해당 group도(removed

implicitly) 제거된다.

4. 따라서 하나의 사용자가 서로 다른 session을 통해 접속하여 동시에(multiple



session) 여러 개의 temporary tablespace를 사용할 수 있게 된다. 물론, parallel

operation을 통해 한 사용자가 slave process를 통해 여러 temporary tablespace

를 사용할 수도 있다.

5. 이러한 속성은 database level에서 default temporary tablespace를 하나이상

사용할 수 있도록 해준다.

CF. 새로운 feature인 이 기능을 통해 과거 temporary tablespace의 부족으로

발생할 수 있는 out of temporary space 오류 가능성을 많이 줄일 수 있게 되었다.

CF. 또한 parallel operation처럼 분산된 temporary tablespace를 동시에

사용하거나 동일한 사용자 계정으로 운영하는 applications이 동시에 수행될 때

성능향상도 기대해 볼 수 있을 것이다.

다음은 temporary tablespace를 만들면서 group을 만드는 것과 추가적으로

temporary tablespace를 생성하면서 group을 지정하는 예이다.


Connected.

SQL> create temporary tablespace temp_1 tempfile 't1.dbf'

2 size 10M tablespace group tg1;

Tablespace created.


2 size 10M tablespace group tg1;

Tablespace created.


2 size 10M tablespace group '';

Tablespace created.


2 size 10M;



Tablespace created.

위에서 첫 번째 SQL은 temporary tablespace를 생성함과 동시에 group을

지정함으로써 implicitly temporary tablespace group이 만들어진 것이고 두 번째

SQL은 첫 번째 SQL에서 만들어진 group을 지정하여 temporary tablespace를 만든

것이다. 세 번째와 네 번째는 group을 지정하지 않는 일반적인 방법으로 temporary

tablespace를 만든 것이다.

CF. 세 번째 SQL처럼 group이름을 아무것도 지정하지 않고 single quotation만을

사용하면 네 번째 SQL과 같은 의미를 가진다는 점을 헛갈리지 말자. (세 번째 SQL은

곧, alter tablespace command로 지정하는 temporary tablespace를 소속 group

에서 제거하는 기능이 가능하다는 것을 암시해 준다)

이제 group을 표현하기 위해 oracle10g가 새롭게 제공하는 view를 확인하고 alter

명령으로 어떻게 변하는지를 확인해보자.

SQL> desc dba_tablespace_groups

Name Null? Type

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

GROUP_NAME NOT NULL VARCHAR2(30)

TABLESPACE_NAME NOT NULL VARCHAR2(30)

SQL> select * from dba_tablespace_groups;

GROUP_NAME TABLESPACE_NAME

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

TG1 TEMP_1

TG1 TEMP_2

SQL> alter tablespace temp_4 tablespace group tg1;

Tablespace altered.

SQL> alter database default temporary tablespace tg1;

Database altered.



SQL> alter user scott temporary tablespace tg1;

User altered.



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

TG1 TEMP_1

TG1 TEMP_2

TG1 TEMP_4


2 where property_name = 'DEFAULT_TEMP_TABLESPACE';

PROPERTY_VALUE

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

TG1

위 과정을 통해 temporary tablespace group을 할당하거나 database level, user

level에서 지정하는 방식을 확인했다. 이게 drop을 통해 이 tablespace가 어떻게

변화되는지 확인하자. 먼저 temporary tablespace group내의 tablespace 1개를

group에서 제거하고(group에서만 빼고) default temporary tablespace에 속하는

tablespace를 drop하기 위해 default temporary tablespace를 temp로 변경하자.

SQL> alter tablespace temp_1 tablespace group '';

Tablespace altered.

SQL> alter database default temporary tablespace temp;

Database altered.

이제 group tg1에 있는 temporary tablespace temp_4를 drop해 보자.

SQL> drop tablespace temp_4 including contents and datafiles;



Tablespace dropped.



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

TG1 TEMP_2


Tablespace dropped.


no rows selected

Group내에 있는 모든 temporary tablespace를 drop하자 temporary tablespace

group도 제거되었다. 그렇다면 앞서 scott에게 할당했던 temporary tablespace

group tg1은 어떻게 되었는가.

SQL> select temporary_tablespace from dba_users

2 where username = 'SCOTT';

TEMPORARY_TABLESPACE

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

TEMP

앞서 alter database로 변경한 default temporary tablespace가 자동으로 scott

에게 할당이 되었음이 확인된다.

마지막으로 temp_1을 drop하여 테스트 과정에서 만들어진 temporary tablespace

drop과정을 마무리하자.


Tablespace dropped.



OCP point

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

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

1. default permanent tablespace의 개념과 설정 및 drop 방법

2. 위와 같은 속성을 확인할 수 있는 view “database_properties” 기억

3. rename tablespace의 기본 제약사항과 속성

4. sysaux tablespace내 이동 가능한 occupant와 이동 방법

5. transportable tablespace을 위한 기본조건과 view v$transportable_platform

기억

6. oracle10g 이전과 이후의 CLOB character set의 변화

7. bigfile tablespace 및 default tablespace type 설정방법

8. bigfile tablespace에 alter tablespace명령으로 변경 가능한 datafile 속성

9. temporary tablespace group의 개념 및 생성방법

10. temporary tablespace group지정시 '' (single quotation만 지정)의 의미

참조

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

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

default temporary tablespace : o9i 296p

dictionary managed tablespace : o8i 99p

locally managed tablespace : o8i 99p

extent manage local : o8i 99p

segment space management auto : o9i 194p

csscan : o9i 572p;

transportable tablespace : o8i 101p, o9i 104p

DDL : Data Definition Language (create, alter, drop 등)

dbv : o8i 134p, o9i 476p

extended ROWID : o8 33p



3.5. Files

3.5.1.File Copy

Oracle10g 이전에 database내에서 file을 copy하는 방안은 없었다. 따라서 항상

copy작업이 필요하면 OS level에서 copy작업을 진행하곤 했었다. 이제 oracle이

제공하는 package를 통해 database level에서 copy를 할 수 있게 되었다.

3.5.1.1. Local File Copy

Oracle level에서 datafile을 copy하기 위해서는 기본적으로 source file과

destination file이 있는 directory를 등록을 한 후 dbms_file_transfer package를

사용한다.

아래의 예는 앞서 수 차례 테스트를 진행한 “trans01.dbf” copy본과 일반 OS files을

만들어 진행한 것이다.

[NEWSVC]LIRACLE:/app/oracle/temp> cd ..

[NEWSVC]LIRACLE:/app/oracle> mkdir copy

[NEWSVC]LIRACLE:/app/oracle> mkdir copy/src

[NEWSVC]LIRACLE:/app/oracle> mkdir copy/dst

[NEWSVC]LIRACLE:/app/oracle> cp ./temp/trans01.dbf ./copy/src/

[NEWSVC]LIRACLE:/app/oracle> more ./copy/src/os2m512.txt

aa aa aa aa aa aa aa aa aa aa aa aa……………

………………………………..

[NEWSVC]LIRACLE:/app/oracle> more ./copy/src/osgeneral.txt

aa aa aa aa aa aa aa aa aa aa aa aa……………

………………………………..

[NEWSVC]LIRACLE:/app/oracle> ls -l ./copy/src

total 10272

-rw-r--r-- 1 oracle dba 1024 Jul 11 15:03 os2m512.txt

-rw-r--r-- 1 oracle dba 893 Jul 11 15:05 osgeneral.txt

-rw-r----- 1 oracle dba 10493952 Jul 11 14:52 trans01.dbf

[NEWSVC]LIRACLE:/app/oracle>

현재 datafile 1개를 copy한 후 2개의 text file을 만들었다. 주의할 점은 text file 1

개는 893 byte이고 다른 1개는 1024 byte라는 점이다. 왜 이것이 중요한 것인가는

다음의 예를 통해 확인할 수 있다.

[NEWSVC]LIRACLE:/app/oracle> sqlplus sys/manager as sysdba





Connected to:



SQL> create directory cpsrc_dir as '/app/oracle/copy/src';

Directory created.

SQL> create directory cpdst_dir as '/app/oracle/copy/dst';

Directory created.

SQL> grant read, write on directory cpsrc_dir to public;

Grant succeeded.

SQL> grant read, write on directory cpdst_dir to public;

Grant succeeded.

SQL> grant execute on dbms_file_transfer to scott;

Grant succeeded.


Connected.


Connected.

SQL> desc dbms_file_transfer

PROCEDURE COPY_FILE



Argument Name Type In/Out Default?

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

SOURCE_DIRECTORY_OBJECT VARCHAR2 IN

SOURCE_FILE_NAME VARCHAR2 IN

DESTINATION_DIRECTORY_OBJECT VARCHAR2 IN

DESTINATION_FILE_NAME VARCHAR2 IN

PROCEDURE GET_FILE


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



SOURCE_DATABASE VARCHAR2 IN



PROCEDURE PUT_FILE


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





DESTINATION_DATABASE VARCHAR2 IN

SQL> begin

2 dbms_file_transfer.copy_file (

3 'cpsrc_dir', 'trans01.dbf', 'cpdst_dir', 'local_trans.dbf');

4 end;

5 /


SQL> !ls -l ./copy/dst/

total 10264

-rw-r----- 1 oracle dba 10493952 Jul 11 14:53 local_trans.dbf



SQL> begin


3 'cpsrc_dir', 'os2m512.txt', 'cpdst_dir', 'local_os2m512.txt');

4 end;

5 /


SQL> !ls -l ./copy/dst/

total 10268

-rw-r----- 1 oracle dba 1024 Jul 11 15:04 local_os2m512.txt

-rw-r----- 1 oracle dba 10493952 Jul 11 14:53 local_trans.dbf

SQL> begin


3 'cpsrc_dir', 'osgeneral.txt', 'cpdst_dir', 'local_osgeneral.txt');

4 end;

5 /

begin

*

ERROR at line 1:

ORA-19505: failed to identify file "/app/oracle/copy/src/osgeneral.txt"

ORA-27046: file size is not a multiple of logical block size

Additional information: 1

ORA-06512: at "SYS.DBMS_FILE_TRANSFER", line 84

ORA-06512: at "SYS.DBMS_FILE_TRANSFER", line 193

ORA-06512: at line 2

SQL>

작업이 원활이 수행되었다. 단, file “osgeneral.txt”는 실패하였으며 그 이유는 위

error에서 보듯이 file size가 logical block size의 배수가 아니기 때문이다. 다시 말해

oracle이 제공하는 package “dbms_file_transfer “를 통해 file을 copy하기 위해선

해당 file이 512 byte단위 (배수의)의 file이어야 하다는 것이다. 그래서 1024



byte(512 X 2) file은 성공하였고 893 byte file은 실패한 것이다.

CF. 사실 이 말은 oracle의 datafile이 아니면 실질적으로 이 package를 통한 file

copy는 별 의미가 없다는 것과 마찬가지이다. 내가 copy하려는 file의 size가 항상

512 byte의 배수라는 가정은 할 수가 없기 때문이다.

3.5.1.2. Remote File Copy

원격지의 database를 대상으로 file을 copy하기 위해선 두 가지 방법이 있다. 이는

흔하게 사용하는 FTP처럼 GET과 PUT을 의미한다. 즉, 어디에서 작업을 진행하느냐의

차이일 뿐 기본 조건은 같다. 다음은 “CRT10G” database에서 원격지에 있는

(“NEWSVC” database를 remote database로 가정하자) “NEWSVC” database의

특정 file을 copy하는 예이다.

먼저, “CRT10G”에서 기본 환경구성을 하면 다음과 같다.

SQL> conn sys/manager as sysdba

Connected.

SQL> grant execute on dbms_file_transfer to scott;

Grant succeeded.

SQL> create directory cpdst_dir as '/app/oracle/copy/dst';

Directory created.

SQL> grant read, write on directory cpdst_dir to public;

Grant succeeded.


Connected.

SQL> select * from global_name@newsvc;

GLOBAL_NAME

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

NEWSVC



SQL>

원격지의 database로부터 file을 가져와 write하기 위한 directory object를 만들고

이에 대한 적절한 권한을 부여한 후 이를 대상 계정인 “scott’에게 부여하였다. 그리고

앞서 datapump 작업을 할 때 만든 database link가 제대로 작동 중 인가를

확인하였다.

사용법은 copy_file, get_file, put_file 모두 동일하지만 get_file은 가운데(3번째),

put_file은 마지막(5번째) parameter로 database link 이름을 입력하도록 한다.

여기서는 원격지 database(NEWSVC)로부터 file을 가져올 것임으로 get_file을 할

것이다.

SQL> begin

2 dbms_file_transfer.get_file(

3 'cpsrc_dir', 'trans01.dbf', 'newsvc', 'cpdst_dir', 'remote_trans.dbf');

4 end;

5 /


SQL> begin

2 dbms_file_transfer.get_file(

3 'cpsrc_dir', 'os2m512.txt', 'newsvc', 'cpdst_dir', 'remote_os2m512.txt');

4 end;

5 /


SQL> !ls -l ./copy/dst/remote*


./copy/dst/remote_os2m512.txt


./copy/dst/remote_trans.dbf

SQL>



3.5.1.3. Oracle의 File Copy 속성1. copy하려는 대상 file의 크기는 반드시 512 byte의 배수이어야 한다. (이미

테스트를 통해 확인하였다)

2. copy가 가능한 최대 file의 크기는 2 TeraByte를 넘을 수 없다.

3. copy가 진행되는 동안 oracle은 대상 files을 binary로 처리하며 character set의

변환 같은 작업은 이루어지지 않는다.

4. UNIX system처럼 file의 소유주가 명확히 표시되는 시스템에서는 이러한 작업을

통해 copy되는(사실은 transfer라 해야 맞겠지만) file은 oracle database의 owner

가 그 소유주가 된다. (일반적으로 database를 계정 “oracle”로 만듦으로 file의

owner는 oracle이 될 것이다)

5. copy를 통해 만들어진 files은 모두 원본과 동일한 file type을 갖는다.

6. 당연하겠지만 copy하려는 원본 file의 size가 크다면 작업시간이 오래 걸릴 것이며

이러한 경우엔 v$session_longops를 통해 그 진행상황을 check할 수 있다.

3.5.2.Redo Log File Size

새롭게 나타난 이 기능은 oracle10g가 redo log file에 대한 sizing을 자동으로

모니터링을 해서 적절한 값을 추천한다는 내용을 담고 있다. 특별히 DBA가 어떤

action을 취해야 하는 것은 아니지만 추천을 받기 위해선 한가지 전제조건이 필요하다.

그것은 oracle10g가 redo log file을 모니터링하기 위한 기준으로 필요한 parameter

“fast_start_mttr_target”이 이미 설정이 되어 있어야 한다. 이런 경우에 oracle이

판단한 적절한 redo log file의 size가 oracle10g에서 새롭게 추가된 column인

“optimal_logfile_size”를 view “v$instance_recovery”에서 조회함으로써 판단할

수 있다. 단위는 megabyte이다.

적절한 redo log file의 size를 찾기가 어렵거나 database 운영기간이 늘어나면서

alert.log에 “Checkpoint not complete” 메시지가 빈번하게 나타날 때 도움을 받을

수 있다.

CF. fast_start_mttr_target은 oracle9i에서 새로이 추가된 instance crash발생시

recovery time을 초단위로 지정하는 parameter이다.

다음은 이러한 도움을 받아 redo log file size를 수정하는 과정이다.


Connected.

SQL> select value from v$parameter

2 where name = 'fast_start_mttr_target';



VALUE

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

120

SQL> select group#, bytes from v$log;

GROUP# BYTES

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

1 8388608

2 8388608

3 8388608

SQL> select optimal_logfile_size from v$instance_recovery;

OPTIMAL_LOGFILE_SIZE

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

67

SQL>

현재 120초 즉, 대략 2분내에 instance crash로부터 recovery를 가능하도록

parameter가 설정이 되어 있으며 현재 redo log file의 size는 “8388608” byte

(8MB)이며 oracle이 추천하는 size는 67MB이다.

SQL> alter database add logfile group 4

2 ('/app/oracle/oradata/NEWSVC/redoNEWSVC04a.log',

3 '/app/oracle/oradata/NEWSVC/redoNEWSVC04b.log')

4 size 67M;

Database altered.




4 size 67M;



Database altered.




4 size 67M;

Database altered.

SQL>

이제 새로 추가된 redo log file을 활성화 시키고 기존의 redo log file을 drop하는

과정을 진행한다.

SQL> select group#, status from v$log;

GROUP# STATUS

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

1 INACTIVE

2 INACTIVE

3 CURRENT

4 UNUSED

5 UNUSED

6 UNUSED

6 rows selected.

SQL> alter system switch logfile;

System altered.


GROUP# STATUS

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



1 INACTIVE

2 INACTIVE

3 ACTIVE

4 CURRENT

5 UNUSED

6 UNUSED

6 rows selected.

SQL> alter database drop logfile group 1;

Database altered.


Database altered.


Database altered.


GROUP# STATUS

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

4 CURRENT

5 UNUSED

6 UNUSED

SQL> select group#, bytes from v$log;

GROUP# BYTES

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

4 70254592

5 70254592



6 70254592

SQL> !rm /app/oracle/oradata/NEWSVC/redoNEWSVC01*



SQL> exit




[NEWSVC]LIRACLE:/app/oracle>



OCP point

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

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

1. oracle file copy 속성 및 제한

2. redo log file의 optimal size 확인방법

참조

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

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

fast_start_mttr_target : o9i 76p

recovery time : o9i 75p



3.6. LOB

3.6.1.LOB Size Limit

oracle에서 지원하는 대용량 datatype인 LOB은 그 size의 한계가 4GB였다.

Oracle10g부터 이 한계를 대폭적으로 증가시켰으며 사용하는 block size에 따라

유동적으로 결정된다.

Maximum LOB size는 [(4GB -1) X (CHUNK value)] 이 공식에 의해 결정된다.

CHUNK란 lob column을 설정한 후 storage절에서 lob의 세부적인 storage 속성을

정할 때 사용하는 것으로 lob data의 저장단위를 말한다. Database block size의

수를 이용하여 정하게 되는데 그로 인하여 oracle9i부터 제공되는 multi-block size를

사용하게 되면 lob data가 저장되는 tablespace에 따라 그 size limit도 바뀌게 된다.

예를 들어 standard block size가 8KB인데 lob data를 저장하는 tablespace의

block size가 16KB이면 이 tablespace에 저장되는 lob datatype의 size는 (4GB -1)

X (16 X CHUNK value)가 될 것이다. 만일, CHUNK를 2로 했다면 (4GB -1) X (16

X2KB) = 128TB가 이 lob의 한계가 될 것이다. CHUNK는 지정하지 않으면 default로

해당 tablespace의 one block size를 사용함으로 오라클 data block size 2K ~ 32

K까지 각 1 CHUNK로 생각해보면 다음과 같은 maximum size가 나올 것이고 이 값에

CHUNK 값을 곱하면 해당 lob data의 한계를 알 수 있을 것이다.

Block Size LOB Limit ( 1 CHUNK) LOB Limit ( n CHUNK)

2KB 8TB 8TB X n

4KB 16TB 16TB X n

8KB 32TB 32TB X n

16KB 64TB 64TB X n

32KB 128TB 128TB X n

CF. 이미 존재하는 작업대상이 되는 lob의 limit을 쉽게 알려면 package dbms_lob을

이용하여 function get_storage_limit을 call하여 return value를 확인하면 된다.

CF. oracle OCI를 통한 API call도 4GB 이상의 lob을 지원한다.

3.6.2.Implicit LOB Conversion

Oracle10g 이전에는 CLOB과 NCLOB의 implicit conversion을 위해 TO_CLOB,

TO_NCLOB과 같은 internal function을 사용해야 했다. 이제는 implicit란 말 그대로

function을 사용하지 않고 내부적으로 변환이 가능해 졌다.


표 3-7

Block size와

LOB size


간단한 테스트를 통해 이를 확인해 보자. 다음의 예는 NCLOB column을 가진 table에

CLOB data를 넣어서 자동으로 변환된 해당 table의 NCLOB data를 다시 CLOB으로

받아서 출력해보는 과정이다.

[NEWSVC]LIRACLE:/app/oracle> sqlplus scott/tiger

SQL*Plus: Release 10.1.0.4.0 - Production on Thu Jul 14 09:32:41 2005


Connected to:



SQL> create table lob_test (lob_conv varchar2(1), nclob_data nclob);

Table created.

SQL> declare

2 ls_clob clob;

3 begin

4 ls_clob := 'Original CLOB';

5 insert into lob_test values ('Y', ls_clob);

6 end;

7 /


SQL> select count(*) from lob_test;

COUNT(*)

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

1

SQL> commit;



Commit complete.

CLOB data를 NCLOB column에 아무런 변환작업이 없이 insert하였다. 다음은

반대로 NCLOB data를 CLOB으로 받아서 문제없이 출력이 되는지 확인해 보자.

SQL> set serveroutput on

SQL> declare

2 ls_clob clob;

3 ls_key varchar2(1);

4 begin

5 select lob_conv, nclob_data into ls_key, ls_clob from lob_test;

6 dbms_output.put_line('----------------------------------------');

7 dbms_output.put_line('Conversion : ' || ls_key);

8 dbms_output.put_line('Real data : ' || ls_clob);

9 end;

10 /

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

Conversion : Y

Real data : Original CLOB




참조

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

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

LOB : o8 38p, o8 46p, o8i 81p, o9i 546p



3.7. Segments

3.7.1.Maxtrans 삭제Oracle은 table, index등 실제 data와 연관된 segment를 생성할 때 “maxtrans”

라는 속성을 설정하도록 하고 있다. 이는 block에 대하여 동시에 변경하는 transaction

의 최대 수를 지정하는 것이다.

이제 oracle10g부터는 이 속성을 지정하지 않아도 된다. Oracle10g는 이 속성의

값으로 최대 값을 자동으로 설정한다. 다만, 과거 version과의 연관성 문제로 이 속성을

지정한다고 해도 error는 나지 않지만 지정된 값은 완전히 무시된다.

3.7.2.Example

다음의 예를 확인을 해보자. 하나는 maxtrans의 값을 지정하지 않았고 다른 하나는

작은 값을 이 속성에 지정한 것이다.

SQL> create table x_emp10 (a number);

Table created.

SQL> create table x_dept10 (b number) maxtrans 50;

Table created.

이제 실제 이 속성의 값이 어떻게 설정이 되었는지 확인해 보자.

SQL> select table_name, max_trans from user_tables

2 where table_name in ('X_EMP10', 'X_DEPT10');

TABLE_NAME MAX_TRANS

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

X_DEPT10 255

X_EMP10 255

모두 255로 설정되었음을 확인할 수 있다.



참조

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

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

maxtrans : ob 30p


O10g data control_10

Documents

Transcript of O10g data control_10