o10g miscellaneous 17

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

10. 그 밖의 것들....................................................................................10-2

10.1. Monitoring and Tracing............................................................10-3

10.1.1....................................................Rollback and Recovery by SMON

10-3

10.1.2...................................................................................세밀화된 Trace

10-3

10.1.2.1..........................................................................................개요

10-3

10.1.2.2.................................................................End-to-End Tracing

10-4

10.1.2.3..................................................................................Example

10-6

10.1.2.4.................................................................................Using em

10-16

10.2. Simple Configuration............................................................10-19

10.2.1........................................................................동적인 Shared Server

10-19

10.2.2....................................................................................No Client 설정

10-21

10.3. Resumable Space and Flush Buffer.......................................10-24

10.3.1..................................................RESUMABLE_TIMEOUT parameter

10-24

10.3.2.......................................................................................Flush Buffer

10-24

10.4. Enhanced Packages..............................................................10-26

10.4.1...........................................................................................UTL_MAIL

10-26

10.4.1.1..........................................................................................개요

10-26

10.4.1.2...........................................................................Package 생성

10-26

10.4.1.3...........................................................................e-mail 사용법

10-27

10.4.2................................................................................UTL_COMPRESS

10-27

10.4.2.1..........................................................................................개요

[email protected] 1


10-27

10.4.2.2.......................................................................................사용법

10-27

10.4.2.3..................................................................................Example

10-28

10.4.3................................................................................DBMS_LOGMNR

10-30

10.4.3.1..........................................................................................개요

10-30

10.4.3.2.................................................New Options and Procedure

10-31

10.4.3.3..................................................................................Example

10-31

10.5. Clone and Compatibility........................................................10-37

10.5.1.............................................................................Database Cloning

10-37

10.5.1.1..........................................................................................개요

10-37

10.5.1.2............................................................................Cloning 속성

10-37

10.5.2........................................................................................Compatible

10-38

[email protected] 2


10. 그 밖의 것들

다음은 앞서 소개한 chapter들과 달리 조금은 독립적으로 사용될 수 있는 또는

부분적으로 기능이 확장되거나 추가된 oracle10g features이다.

대략적으로 정리를 해보면 monitoring 측면으로서의 view의 변화와 사용자 tracing

기법의 강화, shared server 및 client 구성의 편리함, resumable 설정의 변화와

flush buffer, 마지막으로 몇 가지 신규 및 확장된 packages를 통해 강화된

oracle10g 기능을 설명할 것이다.

[email protected] 3


10.1.Monitoring and Tracing

10.1.1. Rollback and Recovery by SMON

Oracle의 parallel transaction recovery를 monitoring하기 위하여 보통

“v$fast_start_transaction” 과 “v$fast_start_servers”을 활용해왔다. 이 제

oracle10g부터 이 views를 확장하여 SMON이 진행하는 일반적인(normal)

transaction rollback 및 recovery의 정보를 확인할 수 있게 되었고 이 정보들은

instance가 shutdown될 때까지 계속 보존된다. 추가된 column은 다음과 같다.

Column Description

XID transaction ID

PXID parent transaction ID

RCSERVERS 작업하는 server processes 수 (coordinator server를

포함한다)

따라서 이 view를 통해 특정 시점간 정보의 변화를 확인하여(undo할 전체 block의

수와 실제 진행된 undo block수의 변화) 보다 정확한 SMON transaction rollback or

recovery를 예측할 수 있게 된다. 그러나 이 정보들은 작은 transaction 즉, undo

blocks의 사용량이 적은 경우엔 track하지 않는다.

위와 관련하여 oracle10g는 parallel transaction recovery의 slave processes상태

정보를 확인하는 view “v$fast_start_servers”에도 XID가 추가되어 이 두 views를

join한 결과를 쉽게 찾아볼 수 있도록 하고 있다.

CF. “v$session_longops”에서 다양한 정보가 monitoring될 수 있음을 잊지 말자.

10.1.2. 세밀화된 Trace

10.1.2.1. 개요일반적으로 session trace를 생성하고 이를 분석하는 일은 DBA의 주요작업 중의

하나이다. 그러나 shared server 환경에서는 여러 session이 shared server를

공유하기 때문에 session단위로 trace를 생성하는 것은 거의 불가능했었다.

Oracle10g는 shared server환경에서 trace를 생성할 때 shared server가 아닌

dispatcher로부터 trace를 생성하도록 할 수 있다. 가장 일반적인 tracing 형식은

다음과 같으며 이는 앞으로 계속 설명되는 client 중심의 trace를 지원하는데 매우

유용한 oracle의 OS command이다.

SQL> trcsess output = name.trc clientid = name *.trc

[email protected] 4

표 10-1

New Transaction 정보


요즘 대부분의 시스템이 multi-tier를 지향하면서 client의 call이 database에서는

어떤 server를 통해 처리되는지 알 수 없는 경우가 많다. 이는 shared server환경이나

connection pooling을 사용하는 경우도 마찬가지다. 따라서 이런 경우에 특정 client

의 혹은 특정 업무의 trace를 생성하는 일은 여간 까다롭지가 않다. 특히나 운영중인

production database 시스템에서는 거의 어려운 일이다.

10.1.2.2. End-to-End Tracing

Oracle10g는 이러한 특정 client를 위해 구성하는 trace를 end-to-end tracing

이라고 부르며 위에서 언급한 trcsess를 활용하여 사용자가 원하는 tracing을

통합하는 기능도 제공한다. 이는 oracle10g가 client_identifier 단위로 trace를

enable/disable할 수 있기 때문에 가능한 것이다.

이 값은 v$session의 같은 이름의 column 혹은 sys_context(‘USERENV’,

‘CLIENT_IDENTIFIER’)를 통해서 알 수 있다.

정리하면 다음과 같은 순서로 tracing을 진행하게 된다. 예를 들어 현재 database에

접속하는 session중에서 특정 팀 “회계팀”의 trace가 필요하다. 그리고 이 팀이 작업을

수행할 때에 client_identifier는 “accounting”이다.

1. client identifier “accounting”에 대하여 trace를 enable한다.

SQL> exec dbms_monitor.client_id_trace_enable(‘accounting’);

2. 회계팀에서 application을 구동하여 작업을 수행한다. 이 때 내부적으로 client

identifier가 설정된다. 다음과 같은 SQL이 session이 연결될 때(혹은 application이

call될 때) 사용될 것이다.

SQL> exec dbms_session.set_identifier('accounting');

3. 필요하다면 다음과 같이 trace를 중지한다.

SQL> exec dbms_monitor.client_id_trace_disable('accounting');

4. 생성된 trace files을 tkprof로 분석작업을 수행한다.

$ tkprof source.trc output.trc

5. 만일 여러 개의 trace files이 생성되었다면(사실은 server를 공유하는 경우 거의

그렇겠지만) 다음과 같이 이를 하나로 통합하여 tkprof 분석을 수행한다.

$ trcsess output = source.trc clientid = accounting *.trc

$ tkprof source.trc output.trc

보다 세밀한 trace 조정을 위해 client identifier외에 service, module, action의

값도 trace를 handling하기 위한 조건으로 사용할 수 있다. 이 경우에 사용되는

[email protected] 5


procedure는 “serv_mod_act_trace_enable/disable”이다. 따라서 trcsess를 통해

분석을 할 때도 원한다면 각각의 값들을 argument로 주어야 한다. 다음은 trcsess의

사용 형식이다.

$ trcsess [output=<output file name >] [session=<session ID>]

[clientid=<clientid>] [service=<service name>] [action=<action name>]

[module=<module name>] <trace file names>

CF. 물론 service, module, action의 값도 v$session의 동 columns에서 확인할 수

있다.

부가적으로 dbms_monitor를 이용하여 trace를 enable/disable할 때에 여러분이

추가적인 trace 정보 및 통계정보의 수집을 원한다면 다음과 같은 procedure를 call할

수 있다.

SQL> exec dbms_monitor.client_id_stat_enable/disable

SQL> exec dbms_monitor.serv_mod_act_stat_enable/disable

CF. 위와 같이 통계작업을 수행하게 하면 해당 data는(차후 예제의 em화면에서

보겠지만) em의 “consumer”화면에서도 확인이 되지만 다음과 같은 views에서도

각종 정보를 함께 확 인할 수 있다. (단, service level의 통계는 자동으로 누적된다)

View Description

dba_enabled_aggregatio

ns

통계수집이 enable되었는지 확인

CF. dba_enabled_traces는 SQL trace enable정보

v$client_stats 지정된 client_id의 통계

v$service_stats 성능통계 정보

v$serv_mod_act_stats v$service_stats중 지정된 service/module/action의

성능통계

전통적인 방식의 session id를 이용한 trance enable/disable도 dbms_monitor를

통해 여전히 사용할 수 있다.

SQL> exec dbms_monitor. session_trace_enable/disable

이 package “dbms_monitor”내 procedures를 정리해보면 다음과 같다.

Trace Level Procedure Argument

client id client_id_trace_enable client_id

waits

[email protected] 6

표 10-2

Trace와 관련 View List

표 10-3

DBMS_MONITOR Procedure List


binds

client_id_trace_disable client_id

service / module /

action

serv_mod_act_trace_enable service_name

module_name

action_name

waits

binds

instance_name

serv_mod_act_trace_disable service_name

module_name

action_name

instance_name

session session_trace_enable session_id

serial_num

waits

binds

session_trace_disable session_id

serial_num

client statistics client_id_stat_enable client_id

client_id_stat_disable client_id

service / module /

action

statistics

serv_mod_act_stat_enable service_name

module_name

action_name

serv_mod_act_stat_disable service_name

module_name

action_name

CF. waits, binds는 trace에 wait event와 bind variable의 정보표시 여부를

결정하며 default는 TRUE, FALSE이다.

CF. “serv_mod_act_trace_enable”은 database전체에 대하여 globally 적용되기

때문에 원한다면 이를 특정 instance에 한정시킬 수 있고 그때 사용할 수 있는 것이

instance_name argument이다.

10.1.2.3. Example

현재 테스트중인 database를 shared server 환경으로 구성하여 database를 restart

[email protected] 7


해 보자. 이 shared server 환경을 마치 multi-tier를 통한 server process를

공유하는 application의 접근으로 생각해 보자.

[NEWSVC]LIRACLE:/app/oracle/admin/NEWSVC/pfile> vi initNEWSVC.ora

# -------------------------- SHARED SERVER parameters ------------------------

dispatchers = '(pro=tcp)(dis=2)'

max_dispatchers = 5

shared_servers = 5

…..

…..

~

~

~

:wq

[NEWSVC]LIRACLE:/app/oracle/admin/NEWSVC/pfile> sqlplus / as sysdba

SQL*Plus: Release 10.1.0.4.0 - Production on Tue Oct 18 17:13:12 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

SYS> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SYS> startup

ORACLE instance started.

Total System Global Area 473956352 bytes

Fixed Size 779736 bytes

Variable Size 136583720 bytes

Database Buffers 331350016 bytes

[email protected] 8


Redo Buffers 5242880 bytes

Database mounted.

Database opened.

이제 테스트를 진행할 scott계정의 두 개 session을 만들어 보자. 마치 remote

process처럼 인식되도록 tnsnames.ora를 통해 연결하도록 “@newsvc”를 사용할

것이다.

SCOTT #1 :

[NEWSVC]LIRACLE:/app/oracle/temp> sqlplus scott/tiger@newsvc

SQL*Plus: Release 10.1.0.4.0 - Production on Wed Oct 19 10:35:03 2005


Connected to:



SCOTT>

SCOTT #2 :




Connected to:



SCOTT>

[email protected] 9


위 sessions이 shared server를 사용하고 있는지 확인하기 위하여 다른 창에서 SO

command를 통해 server process를 찾아보자.

[NEWSVC]LIRACLE:/app/oracle/temp> ps -ef | grep NEWSVC | grep LOCAL

[NEWSVC]LIRACLE:/app/oracle/temp>

아무런 server process를 찾을 수가 없다. 하지만 SQL문으로 이 들을 찾아보면 더

확실히 알 수가 있다. 같은 창에서 다음과 같이 진행해 보자. 보다 확실한 테스트를

위하여 기존의 trace files을 모두 삭제한 후 확인 작업을 시작하자.

[NEWSVC]LIRACLE:/app/oracle/temp> rm ../admin/NEWSVC/bdump/*.trc

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



Connected to:



SYSTEM> select p.program, p.spid from v$session s, v$process p

2 where s.username = 'SCOTT' and s.paddr = p.addr;

PROGRAM SPID

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

oracle@LIRACLE (D001) 28117

oracle@LIRACLE (D001) 28117

SYSTEM> !ps -ef | grep 28117

oracle 28117 1 0 Oct18 ? 00:00:18 ora_d001_NEWSVC

oracle 17656 17544 0 10:50 pts/2 00:00:00 /bin/bash -c ps -ef | grep

28117

oracle 17658 17656 0 10:50 pts/2 00:00:00 grep 28117

위 결과를 통해 server를 공유하는 형태로 두 개의 scott 계정이 연결되어 있음을 알 수

있다. 먼저, 위 화면에서 client identifier를 ‘accounting’으로 설정하여 trace를

[email protected] 10


enable 시켜보자.

SYSTEM> exec dbms_monitor.client_id_trace_enable('accounting');

PL/SQL procedure successfully completed.

이제 두 개의 scott 화면에서 각각 client identifier를 설정하자.

SCOTT #1 :

SCOTT> exec dbms_session.set_identifier('accounting');


SCOTT #2 :

SCOTT> exec dbms_session.set_identifier('accounting');


이제 system계정의 창으로 이동하여 scott계정에 설정된 client identifier 정보가

제대로 확인되는지 살펴보자.

SYSTEM> select client_identifier

2 from v$session where username = 'SCOTT';

CLIENT_IDENTIFIER

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

accounting

accounting

이제 각 scott계정의 창에서 서로 다른 SQL을 하나씩 수행한다.

SCOTT #1 :

SCOTT> select count(*) from emp;

COUNT(*)

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

2

SCOTT #2 :



SCOTT> select count(*) from dept;

COUNT(*)

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

3

현재 각 창에서 서로 다른 table에 대한 SQL을 수행하였다. 이제 system계정의

창에서 trace를 중지하자.

SYSTEM> exec dbms_monitor.client_id_trace_disable('accounting');


이제 trace가 중지된 상태에서 다시 scott계정의 창에서 각각 다른 SQL을 수행한다.

SCOTT #1 :

SCOTT> select sum(1) from emp;

SUM(1)

----------

2

SCOTT #2 :

SCOTT> select sum(1) from dept;

SUM(1)

----------

3

마지막으로 system계정의 창을 종료하고 bdump directory로 이동하여 trace를

확인하자. 먼저, 새로 소개된 trcsess를 통해 client identifier를 기준으로 trace를

통합한 후 output file을 가지고 tkprof를 수행한다.

SYSTEM> exit

Disconnected from Oracle Database 10g Enterprise Edition Release

10.1.0.4.0 - Production


[NEWSVC]LIRACLE:/app/oracle/temp> cd ../admin/NEWSVC/bdump



[NEWSVC]LIRACLE:/app/oracle/admin/NEWSVC/bdump> trcsess

output=scott_act.trc clientid=accounting *.trc

[NEWSVC]LIRACLE:/app/oracle/admin/NEWSVC/bdump> tkprof scott_act.trc

accounting.trc explain=scott/tiger table=scott.plan_table sys=no

[NEWSVC]LIRACLE:/app/oracle/admin/NEWSVC/bdump>

다음은 위 trace의 실제 최종 분석결과를 그대로 보여주는 것이다.

[NEWSVC]LIRACLE:/app/oracle/admin/NEWSVC/bdump> cat accounting.trc

TKPROF: Release 10.1.0.4.0 - Production on Wed Oct 19 12:32:04 2005


Trace file: scott_act.trc

Sort options: default

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

count = number of times OCI procedure was executed

cpu = cpu time in seconds executing

elapsed = elapsed time in seconds executing

disk = number of physical reads of buffers from disk

query = number of buffers gotten for consistent read

current = number of buffers gotten in current mode (usually for update)

rows = number of rows processed by the fetch or execute call

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

BEGIN dbms_session.set_identifier('accounting'); END;

call count cpu elapsed disk query current rows

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

Parse 0 0.00 0.00 0 0 0 0

Execute 2 0.00 0.00 0 0 0 2

Fetch 0 0.00 0.00 0 0 0 0

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



total 2 0.00 0.00 0 0 0 2

Misses in library cache during parse: 0

Misses in library cache during execute: 1

Optimizer mode: ALL_ROWS

Parsing user id: 61 (SCOTT)

Elapsed times include waiting on following events:

Event waited on Times Max. Wait Total Waited

---------------------------------------- Waited ------------- -----------------

SQL*Net message to client 2 0.00 0.00

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

select count(*)

from

emp


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

Parse 1 0.00 0.02 0 0 0 0

Execute 1 0.00 0.00 0 0 0 0

Fetch 2 0.00 0.01 1 1 0 1

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

total 4 0.00 0.03 1 1 0 1




Rows Execution Plan

-------

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

0 SELECT STATEMENT MODE: ALL_ROWS

0 SORT (AGGREGATE)



0 INDEX MODE: ANALYZED (FULL SCAN) OF 'EMP_SAL_COM_IK' (INDEX)



---------------------------------------- Waited ------------- -----------------


db file sequential read 1 0.01 0.01

SQL*Net message from client 1 0.00 0.00

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

select count(*)

from

dept


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

Parse 1 0.03 0.01 0 0 0 0

Execute 1 0.00 0.00 0 0 0 0

Fetch 2 0.00 0.02 1 1 0 1

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

total 4 0.03 0.03 1 1 0 1




Rows Execution Plan

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

0 SELECT STATEMENT MODE: ALL_ROWS

0 SORT (AGGREGATE)

0 INDEX MODE: ANALYZED (FULL SCAN) OF 'PK_DEPT_ID' (INDEX

(UNIQUE))





---------------------------------------- Waited --------------- -----------------



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

OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS


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

Parse 2 0.03 0.03 0 0 0 0

Execute 4 0.00 0.00 0 0 0 2

Fetch 4 0.00 0.03 2 2 0 2

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

total 10 0.03 0.07 2 2 0 4





------------------------------------------ Waited --------------- -----------------


SQL*Net message from client 4 0.00 0.00


OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS




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

Parse 31 0.03 0.05 0 0 0 0

Execute 233 0.20 0.21 0 0 0 0

Fetch 281 0.10 0.31 40 737 0 1088

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

total 545 0.33 0.58 40 737 0 1088





------------------------------------------ Waited --------------- -----------------


4 user SQL statements in session.

31 internal SQL statements in session.

35 SQL statements in session.

2 statements EXPLAINed in this session.

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

Trace file: scott_act.trc

Trace file compatibility: 10.01.00

Sort options: default

0 session in tracefile.

4 user SQL statements in trace file.

31 internal SQL statements in trace file.

35 SQL statements in trace file.

18 unique SQL statements in trace file.

2 SQL statements EXPLAINed using schema:

scott.plan_table

Schema was specified.

Existing table was used.

800 lines in trace file.



15 elapsed seconds in trace file.

위 분석 결과를 보면 두 session에서 수행한 client identifier “accounting”

sessions의 SQL이 통합되어 있으며 또한 trace를 disable한 후의 “select sum(1)

from” 문장은 나타나지 않고 있음도 확인된다. 그리고 default TRUE가 적용된 waits

argument을 통해 wait event도 나타난다.

10.1.2.4. Using em

위 작업을 database 성능 모니터링을 수행하면서 선택적으로 처리할 수도 있다. 이는

em database control의 성능 부분에서 monitoring 요소를 추출하여 처리하는

것이다. 예를 들면 아래처럼 “Performance Top Consumers”에서 여러 유형의

조회를 통해(상단의 Top ????) 필요한 clients를 check하여 중앙에 있는 각종 button

을 선택함으로써 trace 분석을 진행할 수도 있다.


그림 10-1

현재 Top Resource 점유정보


OCP point

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

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

1. dbms_monitor를 이용한 trace 방식에 대한 이해

2. dbms_monitor를 이용한 통계수집과 그 결과를 확인하는 view



10.2.Simple Configuration

10.2.1. 동적인 Shared Server

Oracle10g는 새로워진 shared server의 dynamic 속성을 소개하고 있다. 이는

oracle instance가 start될 때에 자동으로 하나의 TCP dispatcher를 start하여

database server를 간단한 alter command로 shared server환경으로 변환하도록

지원하는 것이다.

다음은 앞서 테스트를 위해 구성한 shared server 환경을 disable하고 다시 원래의

dedicated 환경으로 server를 restart하는 과정이다.

[NEWSVC]LIRACLE:/app/oracle/admin/NEWSVC/pfile> vi initNEWSVC.ora

# -------------------------- SHARED SERVER parameters ------------------------

#dispatchers = '(pro=tcp)(dis=2)'

#max_dispatchers = 5

#shared_servers = 5

…..

…..

~

~

~

:wq

[NEWSVC]LIRACLE:/app/oracle/admin/NEWSVC/pfile> sqlplus / as sysdba

SQL*Plus: Release 10.1.0.4.0 - Production on Tue Oct 18 17:13:12 2005


Connected to:



SYS> shutdown immediate

Database closed.

Database dismounted.



ORACLE instance shut down.

SYS> startup

ORACLE instance started.

Total System Global Area 473956352 bytes

Fixed Size 779736 bytes

Variable Size 136583720 bytes

Database Buffers 331350016 bytes

Redo Buffers 5242880 bytes

Database mounted.

Database opened.

다른 창에서 접속을 시도해 보자.




Connected to:



SCOTT>

이제 sys 창에서 session을 확인한 후 shared server를 start하자.

SYS> select type, server from v$session where username = 'SCOTT';

TYPE SERVER

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

USER DEDICATED

SYS> alter system set shared_servers=2;



System altered.

다음으로 앞서 연결한 scott창을 재 연결한다. (기존 연결은 disconnect될 것이다)

SCOTT> conn scott/tiger@newsvc

Connected.

이제 sys창에서 session 상태를 다시 확인하자.

SYS> select type, server from v$session where username = 'SCOTT';

TYPE SERVER

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

USER NONE

위의 결과는 새로 접속한 session이 shared server를 사용하도록 연결이 되었고

따라서 dispatcher에 할당이 되었기 때문에 server의 값이 “SHARED, DEDICATED”

가 아닌 “NONE”으로 나타난다.

최종적으로 dispatcher 관련 view를 조회해서 server가 start되면서 자동으로 start

된 1개의 dispatcher process와 조금 전에 start시킨 2개의 shared server

processes도 확인해 보자.

SYS> select name, dispatchers from v$dispatcher d, v$dispatcher_config c

2 where d.conf_indx = c.conf_indx;

NAME DISPATCHERS

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

D000 1

SYS> select name, status from v$shared_server;

NAME STATUS

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

S000 WAIT(COMMON)

S001 WAIT(COMMON)

10.2.2. No Client 설정Oracle10g는 client의 설정이 없이 database로 session연결을 할 수 있다. 단,



기본적인 조건으로 “host, port, service_name”을 알고 있는 경우에 한한다. 형식은

다음과 같다.

$ sqlplus username/password@//host:port/service_name

이제 현재 연결되어있는 scott창에서 재 연결하는 방법과 sqlplus 최초 login시에 이

방법을 사용한 예를 살펴보자. 현재 필자가 테스트하는 서버의(PC의) ip address는

“21.111.200.84”이다.

SCOTT> conn scott/tiger@//21.111.200.84:1521/newsvc

Connected.

SCOTT> select * from global_name;

GLOBAL_NAME

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

NEWSVC

SCOTT> exit




[NEWSVC]LIRACLE:/app/oracle> sqlplus

scott/tiger@//21.111.200.84:1521/newsvc



Connected to:



SCOTT> exit






다음은 현재 테스트를 진행중인 server에서(oracle10g client) 하위 version으로의

connection을 해도 아무 문제가 없음을 보여주는 예이다. 즉, 다른 장비에 존재하는

oracle8i server로의 연결을 실제로 해본 것이다. 여러분도 다른 장비가 있다면 아래와

같이 직접 해보시기 바란다. Oracle version에 상관없이 이 connection형식이 잘

수행될 것이다.

[NEWSVC]LIRACLE:/app/oracle> sqlplus

scott/tiger@//21.113.61.215:1521/AZFRONT01

SQL*Plus: Release 10.1.0.4.0 - Production on Fri Oct 21 09:38:18 2005


Connected to:

Oracle8i Enterprise Edition Release 8.1.7.4.0 - Production

With the Partitioning option

JServer Release 8.1.7.4.0 - Production

AZFRONT01> exit

Disconnected from Oracle8i Enterprise Edition Release 8.1.7.4.0 - Production

With the Partitioning option

JServer Release 8.1.7.4.0 - Production

[NEWSVC]LIRACLE:/app/oracle/temp>

CF. 이 방식은 기존의 configuration이 필요 없고 server에서 막지 않는 한 TCP/IP를

native로(or common) 사용하는 모든 platform에서 사용할 수 있다.



10.3.Resumable Space and Flush Buffer

10.3.1. RESUMABLE_TIMEOUT parameter

Oracle9i에서 소개된 resumable space 기능을 보다 세밀하게 control할 수 있도록

oracle10g는 새로운 parameter를 소개하고 있다. 기존에는 아래와 같은 형식을 통해

조절을 했었다.

SQL> alter session enable/disable resumable [timeout ?] [name ‘text’];

Oracle10g는 새로운 parameter를 통해 이를 system level에서 조절할 수 있게

해주고 있다. 따라서 이제 이 parameter의 설정을 통해 system level에서

resumable 기능을 설정하고 timeout도 설정할 수 있게 된 것이다. 또한 이

parameter는 “alter system, session”으로 모두 변경이 가능한 dynamic

parameter이다. 이제 다음과 같이 간단한 형식을 사용하면 된다.

SQL> alter system set resumable_timeout = 1800;

10.3.2. Flush Buffer

시스템 개발하는 도중에 SQL tuning의 효과를 판단하기 위해 tuning 전, 후의 SQL을

수행하여 비교하는 일은 빈번한 작업이다. 그러면서 아쉽게 느껴졌던 부분들 중 하나가

buffer cache의 hit율이 tuning 전, 후의 SQL의 성능에 영향을 줄 수 있어 아주

정확한 테스트가 어려웠다는 점이다. Oracle10g는 buffer cache를 shard pool처럼

flush할 수 있도록 하여 buffer cache miss를 강제하도록 하고 있다. 현재 테스트

시스템을 운영 중 이라면 보다 정확한 값을 확인하기 위해 이 기능을 사용하는 것도

좋겠다. 실제로 다음과 같이 해보자.

SYS> alter system flush buffer_cache;

System altered.



OCP point

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

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

1. new initial parameter resumable_timeout 이해

2. buffer flush command

참조

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

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

resumable space : o9i 98p



10.4.Enhanced Packages

10.4.1. UTL_MAIL

10.4.1.1. 개요이전의 oracle은 e-mail 통신을 위해 utl_smtp package를 지원했었다. 하지만 이

방식은 매우 복잡하여 이른바 user-friendly interface를 제공하지 못했다. 이제

oracle10g는 utl_mail package를 통해 SMTP API를 기반으로 e-mail을 쉽게 처리할

수 있는 기능을 제공하고 있다.

10.4.1.2. Package 생성이 기능을 사용하기 위해서는 다음의 두 scripts를 수행해야 한다.

[NEWSVC]LIRACLE:/app/oracle/temp> cd $ORACLE_HOME/rdbms/admin

[NEWSVC]LIRACLE:/app/oracle/product/10.1.0/rdbms/admin> ls -l *mail*

-rw-r--r-- 1 oracle dba 3410 Mar 7 2005 prvtmail.plb

-rw-r--r-- 1 oracle dba 6780 Jun 13 14:00 utlmail.sql

다음은 utl_mail package를 설치하는 과정이다.

[NEWSVC]LIRACLE:/app/oracle/product/10.1.0/rdbms/admin> cd

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

[NEWSVC]LIRACLE:/app/oracle/temp> sqlplus / as sysdba



Connected to:



SYS> @?/rdbms/admin/utlmail.sql

Package created.



Synonym created.

SYS> @?/rdbms/admin/prvtmail.plb

Package body created.

No errors.

10.4.1.3. e-mail 사용법보통 e-mail은 5가지 부분으로 나누어져 있다. “첨부, 송수신 id, 참조인 id, 제목,

본문”이 그것이다. 지금 설치된 utl_package는 3가지 send 방식이 있다. 첨부가 없는

procedure “send”, raw type의 첨부를 지원하는 “send_attach_raw”, 마지막으로

varchar2 type의 첨부를 지원하는 “send_attach_varchar2”가 있다.

다음의 형식은 liracle.com의 master가 audit.com의 manager에게 정규감사 보고를

e-mail로 보낸다는 가정의 가장 간단한 e-mail 사용법이다.

SQL> exec utl_mail.send('[email protected]', '[email protected]', -

> subject => 'regular auditing result', message => 'There is no specific

issue.');

10.4.2. UTL_COMPRESS

10.4.2.1. 개요Oracle10g는 utl_compress package를 통해 압축 기법을 제공한다. 이 package를

통해 data를 압축하고 다시 원 상태의 format으로 압축을 해제할 수 있다.

당연히 이 기능은 disk space의 효율성을 증대 시킬 수 있다. 압축은 data의 반복된

pattern을 byte와 number로 표시하여 진행되기 때문에 압축의 대상이 되는 data의

성질에 따라서 그 효율성에 차이가 많이 날 수도 있다. 반복경향이 강한 data 일수록 그

효과가 커질 것이다.

10.4.2.2. 사용법이 package로 compress하는 방식에서 사용되는 argument “quality”로 compress

를 제어할 수가 있다. 즉, compress가 빨라지면 압축비율이 떨어지고 반대로 속도가

느려지면 그 만큼 압축비율이 높아지게 된다. 이 값의 default는 6이며 가장 빠른 1

부터 가장 느린 9까지 설정할 수 있다. 따라서 9를 설정하면 가장 확실한 압축작업이

이루어 지게 된다.



대표적인 compress procedure syntax는 다음과 같다.

SQL> exec utl_compress.lz_compress(in_BLOB(BFILE), inout_BLOB, quality);

대표적인 uncompress procedure syntax는 다음과 같다.

SQL> exec utl_compress.lz_uncompress(in_BLOB(BFILE), inout_BLOB);

만일, output 변수가 아닌 function type를 사용하게 되면 raw type input은 raw를

blob or bfile input은 blob을 return하게 된다.

utl_compress.lz_compress(in_RAW_OR_BLOB(BFILE), quality) return raw or

blob

utl_compress.lz_uncompress(in_RAW_OR_BLOB(BFILE)) return raw or blob

10.4.2.3. Example

예를 들어 blob image를 압축하여 특정 table에 insert하고 또 이를 read하여 압축을

해제한 후 다른 table에 원본 상태로 insert하는 작업이 있다고 가정해 보자. 먼저 두

개의 대상 table과 압축, 압축해제를 하여 insert하는 두 개의 procedure를 생성한다.

압축비율은 최고 등급인 “9”를 사용하도록 한다.

SCOTT> create table x_comp (seq number, comp_image blob);

Table created.

SCOTT> create table x_normal (seq number, image blob);

Table created.

SCOTT> create or replace procedure x_put_compress

2 (an_seq in number, ab_lob in blob) is

3 begin

4 insert into x_comp values (an_seq, utl_compress.lz_compress(ab_lob,

9));

5 commit;

6 end;

7 /

Procedure created.



SCOTT> create or replace procedure x_get_uncompress(an_seq in number)

is

2 vb_lob blob;

3 begin

4 select utl_compress.lz_uncompress(comp_image) into vb_lob

5 from x_comp where seq = an_seq;

6 insert into x_normal values (an_seq, vb_lob);

7 commit;

8 end;

9 /

Procedure created.

다음은 위 procedure를 이용하여 문자 “1”을 5만 번 concatenation 즉, 5만 bytes

크기의 lob data를 만들어 이를 압축한 후와 압축을 해제한 후 data 크기의 변화를

측정해보는 과정이다. 절차는 먼저 1부터 5만까지 loop를 돌면서 문자 1을 붙여서

CLOB으로 받는다. 즉, 5만 bytes의 lob data가 생성된다. 그리고 이를 package

dbms_lob을 이용하여 BLOB datatype으로 변환한 다음 앞서 생성한 procedure

x_put_compress call을 통해 insert 작업을 진행한다.

SCOTT> declare

2 vs_col varchar2(10);

3 vc_temp_lob clob;

4 vb_lob blob;

5 vn_dest number;

6 vn_src number;

7 vn_csid number;

8 vn_lang number;

9 vn_warn number;

10 begin

11 vn_dest := 1;

12 vn_src := 1;

13 vn_csid := dbms_lob.default_csid;

14 vn_lang := dbms_lob.default_lang_ctx;

15 for i in 1..50000 loop

16 vc_temp_lob := vc_temp_lob || '1';



17 end loop;

18 dbms_lob.createtemporary(vb_lob, TRUE);

19 dbms_lob.converttoblob(vb_lob, vc_temp_lob, dbms_lob.lobmaxsize,

vn_dest,

20 vn_src, vn_csid, vn_lang, vn_warn);

21 x_put_compress(1, vb_lob);

22 end;

23 /


다음으로 x_get_uncompress를 통해 x_put_compress로 생성된 x_comp table의

comp_image를 read하여 압축을 해제한 후 x_normal로 insert한다.

SCOTT> exec x_get_uncompress(1);


자 이제 두 table의 blob data를 확인하자. 압축하지 않은 경우 이 data의 길이는 최초

생성시 5만 loop를 생각해 볼 때 당연히 50000이 나와야 할 것이고 모두 동일한 문자

“1”로 구성이 되어있는 만큼 압축비율도 상당히 좋아야 할 것이다.

SCOTT> select dbms_lob.getlength(image) from x_normal;

DBMS_LOB.GETLENGTH(IMAGE)

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

50000

SCOTT> select dbms_lob.getlength(comp_image) from x_comp;

DBMS_LOB.GETLENGTH(COMP_IMAGE)

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

2215

위 결과로 볼 때 압축비율은 49KB에서 2KB로 즉, 실제 data의 96%가량이 압축된

것이다.



CF. 이 package를 통해 압축된 file은 “gzip –n”과 “gunzip”과 호환된다.

10.4.3. DBMS_LOGMNR

10.4.3.1. 개요Oracle은 version이 upgrade될 때마다 logminer를 보다 더 쉽게 사용할 수 있는

기능을 제공해왔다. Oracle9i에서 보다 쉬운 dictionary access를 위해 online

dictionary를 사용할 수 있도록 해준데 이어 oracle10g는 dbms_logmnr package에

새로운 options과 procedure를 추가하여 보다 편리하고 확장된 몇 가지 기능을

제공한다.

10.4.3.2. New Options and Procedure

Oracle10g는 dbms_logmnr.start_logmnr 로 logminier를 start할 때에 다음과

같은 추가된 options을 제공한다.

(1) start time 혹은 SCN 설정하고 option “continuous_mine”을 지정함으로써

자동으로 필요한 log files을 add하여 logminer를 start할 수 있다.

(2) option “no_rowid_in_stmt“을 지정함으로써 rowid없이 SQL 재구성을 지원할 수

있도록 logminer를 start할 수 있다.

또한 dbms_logmnr.remove_logfile을 통해 이전과 달리 add_logfile의 removefile

option을 사용하지 않고 직접 remove하는 procedure를 사용할 수 있게 되었다.

이 기능들을 사용함으로써 oracle10g는 이전보다 더 단순하게 logminer를 수행할 수

있다. 기존에는 logminer를 처리할 log files을 add_logfile을 한 후 start_logmnr을

진행하였고 필요 없어진 log files은 add_logfile(‘filename’,

dbms_logmnr.removefile)을 사용했었지만 이제 oracle10g는 start_logmnr을 통해

자동으로 log files이 등록 되도록 하여 logminer를 가동할 수 있고 필요 없는 log files

이 있으면 remove_logfile(‘file_name’)을 통해 간단히 처리할 수 있다.

CF. rowid 없이 SQL이 재 구성이 될 수 있는 것은 chapter 6에서 설명했듯이

supplemental logging을 하게 되면 DML이 발생할 때에 key값에 변화가 없다고 할

지라도 key columns의 이름 등 자세한 정보를 logging하기 때문에 설사 물리적인

위치 변화가 발생한 data나 row chaining등이 발생한 data도 rowid없이 복구가

가능할 수 있다는 뜻이다.

10.4.3.3. Example

테스트를 위해 scott 사용자가 dbms_logmnr을 사용할 수 있도록 설정을 진행한다.

이는 계정 sys를 통해 이루어 진다.



SCOTT> conn sys/manager

Connected.

SYS> grant execute on dbms_logmnr to scott ;

Grant succeeded.

SYS> create public synonym dbms_logmnr for dbms_logmnr ;

Synonym created.

SYS> conn scott/tiger

Connected.

다음은 log files을 add하고 새로운 remove_logfile procedure를 통해 log file을

제거한 후 rowid없이 logminer를 start 및 end하는 절차는 다음과 같은 순서를

따른다.

SCOTT> exec dbms_logmnr.add_logfile('/app/oracle/oradata/NEWSVC/redoNEWSVC04a.log');


SCOTT> exec dbms_logmnr.add_logfile('/app/oracle/oradata/NEWSVC/redoNEWSVC05a.log');


SCOTT> exec

dbms_logmnr.remove_logfile('/app/oracle/oradata/NEWSVC/redoNEWSVC04a.log');


SCOTT> exec dbms_logmnr.start_logmnr(options =>

dbms_logmnr.no_rowid_in_stmt);


SCOTT> exec dbms_logmnr.end_logmnr;




다음의 예는 add_logfile을 하지 않고 자동등록을 지원하는 oracle10g의 option을

사용하여 logminer를 start한 후 그 결과를 확인하는 과정이다. 먼저 테스트 대상이

되는 transaction을 구성하여 테스트 범위로 생각하는 SCN을 추출한다.

SCOTT> create table x_miner_log (name varchar2(10));

Table created.

SCOTT> insert into x_miner_log values ('KSJANG');

1 row created.

SCOTT> insert into x_miner_log values ('HYLEE');

1 row created.

SCOTT> commit;

Commit complete.

SCOTT> select current_scn from v$database;

CURRENT_SCN

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

9727687270

SCOTT> delete from x_miner_log where name = 'KSJANG';

1 row deleted.

SCOTT> insert into x_miner_log values ('JSPARK');

1 row created.



SCOTT> commit;

Commit complete.

SCOTT> select current_scn from v$database;

CURRENT_SCN

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

9727687294

이제 추출한 SCN을 기준으로 add_logfile없이 logminer를 start하여 sql_redo,

sql_undo를 확인해 보자.

SCOTT> exec dbms_logmnr.start_logmnr(startscn => 9727687270, -

> endscn => 9727687294, options => dbms_logmnr.continuous_mine + -

> dbms_logmnr.dict_from_online_catalog);


SCOTT> select sql_redo from v$logmnr_contents

2 where seg_owner = 'SCOTT' and seg_name = 'X_MINER_LOG' ;

SQL_REDO

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

---------

delete from "SCOTT"."X_MINER_LOG" where "NAME" = 'KSJANG' and ROWID

= 'AAAQV+AAEAAAI4FAAA';

insert into "SCOTT"."X_MINER_LOG"("NAME") values ('JSPARK');

SCOTT> select sql_undo from v$logmnr_contents


SQL_UNDO

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

---------



insert into "SCOTT"."X_MINER_LOG"("NAME") values ('KSJANG');

delete from "SCOTT"."X_MINER_LOG" where "NAME" = 'JSPARK' and ROWID

= 'AAAQV+AAEAAAI4FAAC';



다음은 위의 과정을 다시 반복하되 앞서 설명한 rowid없이 SQL문을 재구성하는

방법을 사용한 것이다.

SCOTT> exec dbms_logmnr.start_logmnr(startscn => 9727687270, -

> endscn => 9727687294, options => dbms_logmnr.continuous_mine + -

> dbms_logmnr.dict_from_online_catalog + dbms_logmnr.no_rowid_in_stmt);


SCOTT> select sql_redo from v$logmnr_contents


SQL_REDO

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

delete from "SCOTT"."X_MINER_LOG" where "NAME" = 'KSJANG';

insert into "SCOTT"."X_MINER_LOG"("NAME") values ('JSPARK');

SCOTT> select sql_undo from v$logmnr_contents


SQL_UNDO

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

insert into "SCOTT"."X_MINER_LOG"("NAME") values ('KSJANG');

delete from "SCOTT"."X_MINER_LOG" where "NAME" = 'JSPARK';





OCP point

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

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

1. logminer 새로운 option continuous_mine, no_rowid_in_stmt의 의미

2. logminer 새로운 procedure dbms_logmnr.remove_logfile의 의미

참조

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

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

logminer : o8i 126p, o9i 87p



10.5.Clone and Compatibility

10.5.1. Database Cloning

10.5.1.1. 개요Oracle10g는 database cloning 기능을 제공한다. 따라서 완전하게 잘 tuning된

database를 구성한 후 여러 목적으로 이를 보존 혹은 배포하기를 원한다면 이제

oracle10g부터는 어렵지 않게 원본 database를 다른 곳으로 cloning할 수 있다.

CF. database clone은 내부적으로 RMAN을 통해 backup and recovery과정을

수행함으로써 이루어 진다.

다음 화면은 이를 쉽게 해주는 em의 “Maintenance Clone Database“ 화면 중

destination을 선택하는 단계의 예이다.

10.5.1.2. Cloning 속성1. version 8.1.7 이상부터 가능하다.

2. database open상태에서 clone을 한다.

3. clone은 지정된 oracle home으로 source database를 backup하여 copy한 후

이를 새로운 database로 restore하여 archive logs를 가지고 recovery함으로써

이루어진다. 따라서 새로 생성된 database는 source database의 archive log의

backup 시점과 동일하다.

4. 새로 생성된 database instance는 password file생성, networking files 설정,


그림 10-2

Clone Database


parameter file생성(source instance를 기준으로), 그리고 open mode로 start된다.

10.5.2. Compatible

Oracle10g부터는 parameter compatible의 조정을 현재보다 낮은 값으로 설정할 수

없다. 즉, backward compatibility는 지원하지 않는다. 오로지 forward

compatibility만을 지원한다.

CF. default로 설정되는 compatible parameter의 값은 “10.0.0”이다.

예를 들어 parameter 설정을 “compatible = 9.2.0.0 compatible = 10.1.0.0”

와 같이 변경한 경우 다시 “compatible = 10.1.0.0 compatible = 9.2.0.0”으로

바꿀 수가 없다는 뜻이다. 물론, “compatible = 10.1.0.0 compatible =

10.1.0.4”처럼 더 높은 값으로 바꿀 수는 있다.

CF. 따라서 이전 버전에서 사용하던 command “alter database reset

compatibility”도 사용할 수 없다.



OCP point

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

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

1. database cloning 속성

2. compatible parameter의 backward 불가


o10g miscellaneous 17

Documents