oracle history #14

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

7. 자가관리(self-management) Database System......................................7-6

7.1. 자동진단(automatic diagnostic) 시스템.......................................7-7

7.1.1. ADDM (Automatic Database Diagnostic Management).......7-7

7.1.1.1.......................................................................ADDM 관리 point

7-7

7.1.1.2.....................................................................ADDM 성능 모니터

7-7

7.1.1.3.......................................................................ADDM의 분석방향

7-9

7.1.2. ADDM Configuration.........................................................7-10

7.1.2.1.......................................................................Initial Parameter

7-10

7.1.2.2............................................................................ADDM Report

7-11

7.1.3. ADDM using em................................................................7-18

7.1.3.1.....................................................................................em Start

7-18

7.1.3.2...................................................Advisor Central (중앙 권고자)

7-21

7.1.3.3...........................................................ADDM Report using em

7-23

7.1.4. I/O 속성..............................................................................7-24

7.2. SGA Memory 관리 자동화.........................................................7-26

7.2.1. 빈번한 Memory 오류 유형....................................................7-26

7.2.2. Automatic Shared Memory Management..........................7-26

7.2.2.1....................................................................................SGA Size

7-26

7.2.2.2.......................................................................Initial Parameter

7-27

7.2.3. Memory 자동관리 체계와 Limit............................................7-31

7.2.3.1.........................................................Memory 자동관리 Process

7-31

7.2.3.2............................................................Pool의 자동관리 와 Limit

7-32

7.2.3.3..........................................................................................spfile

7-34

[email protected] 1


7.2.4. Memory 자동관리 Using em...............................................7-35

7.3. 통계정보 자동관리.....................................................................7-37

7.3.1. 변화된 통계수집..................................................................7-37

7.3.2. Automatic 통계수집의 구조.................................................7-38

7.3.2.1.....................................................................................기본 개념

7-38

7.3.2.2......................................................................기본 Components

7-38

7.3.2.3...............................................................통계수집 자동화의 의미

7-41

7.3.2.4........................................................................통계수집 Control

7-41

7.3.3. 통계정보의 Locking 과 Overriding.......................................7-42

7.3.3.1...........................................................................Lock Statistics

7-42

7.3.3.2....................................................................Override Statistics

7-44

7.3.4. 통계정보 History.................................................................7-45

7.3.4.1...............................................................................History 구조

7-45

7.3.4.2........................................................................History 활용하기

7-45

7.3.5. 통계수집 자동화 Limit..........................................................7-48

7.4. Undo & Checkpoint 자동 Tuning...............................................7-50

7.4.1. Undo Management............................................................7-50

7.4.1.1.........................................................Undo Retention 자동 관리

7-50

7.4.1.2....................................................................Rollback Time 추측

7-50

7.4.2. Checkpoint........................................................................7-51

7.4.3. Fast Ramp-Up....................................................................7-53

7.5. AWR (Automatic Workload Repository)...................................7-55

7.5.1. AWR 개요...........................................................................7-55

7.5.1.1................................................................................AWR의 구조

7-55

7.5.1.2................................................................................통계 Access

[email protected] 2


7-55

7.5.1.3...............................기본통계(Base Statistics)와 측정(Metrics)

7-63

7.5.1.4.............................................................Repository와 Snapshot

7-65

7.5.2. AWR Control......................................................................7-66

7.5.2.1.......................................Snapshot Schedule 조정 (Manually)

7-66

7.5.2.2.......................................Snapshot Schedule 조정 (Using em)

7-68

7.5.2.3................................................Snapshot Baseline (Manually)

7-70

7.5.2.4................................................Snapshot Baseline (Using em)

7-72

7.5.2.5...........................................................Other Snapshot Control

7-74

7.5.3. AWR Report & em.............................................................7-75

7.5.3.1..................................................................직접 report 산출하기

7-75

7.5.3.2..............................................................Report Script 사용하기

7-78

7.5.3.3...................................................................................Using em

7-82

7.5.4. Active Session History(ASH)..............................................7-84

7.5.4.1........................................................................ASH 개요 및 속성

7-84

7.5.4.2...............................................................................ASH Access

7-84

7.5.4.3............................................................................ASH Example

7-88

7.5.5. Advisor (문제 해결사)..........................................................7-91

7.5.5.1...........................................................................Advisor의 구조

7-91

7.5.5.2...............................................................................기본 Advisor

7-92

7.5.5.3........................................................................Advisor 사용하기

[email protected] 3


7-92

7.5.5.4...................................................................................Using em

7-94

7.6. Alert & Notification (경보와 알림기능).......................................7-96

7.6.1. Alert 개요...........................................................................7-96

7.6.1.1............................................................Server Generated Alert

7-96

7.6.1.2....................................................................Server Alert의 장점

7-96

7.6.2. Alert 구조...........................................................................7-97

7.6.2.1...........................................................................Alert 생성 시점

7-97

7.6.2.2...........................................................Server Alert & em Alert

7-97

7.6.2.3................................................................................Alert Model

7-98

7.6.3. Alert Types........................................................................7-99

7.6.3.1.............................................................................Stateful Alert

7-99

7.6.3.2..........................................................................Stateless Alert

7-101

7.6.3.3............................................................Out-of-Box Server Alert

7-101

7.6.4. Alert Control....................................................................7-102

7.6.4.1.......................................................Threshold 조절 (Manually)

7-102

7.6.4.2.................................Alert 확인 및 Threshold 조절 (Using em)

7-110

7.6.4.3................................................Alert Message 확인 (Manually)

7-114

7.7. Cost & Optimizer...................................................................7-119

7.7.1. Query Optimization.........................................................7-119

7.7.2. 확장된 Statistics...............................................................7-121

7.7.2.1..............................................................Dictionary를 위한 통계

7-121

7.7.2.2............................................................통계 수집의 New Values

[email protected] 4


7-124

7.7.3. Optimizer Mode의 변화....................................................7-125

7.8. Support SQL Tuning...............................................................7-128

7.8.1. Optimizer를 통한 SQL Tuning 자동환.................................7-128

7.8.1.1.........................................Tuning을 위한 Enhanced Optimizer

7-128

7.8.1.2.......................................................DBA SQL Tuning과 Advisor

7-128

7.8.2. SQL Tuning Advisor.........................................................7-129

7.8.2.1...................................................통계분석 (Statistics Analysis)

7-129

7.8.2.2.................................................................................SQL Profile

7-130

7.8.2.3...SQL Access Advisor : 접근경로 분석(Access Path Analysis)

7-132

7.8.2.4...........................................SQL 구조 분석(Structure Analysis)

7-132

7.8.3. Tuning SQL (Using em)....................................................7-133

7.8.3.1..........................................................................SQL Tuning Set

7-133

7.8.3.2...................................................Running SQL Tuning Advisor

7-134

7.8.3.3.....................................................................................STS 생성

7-136

7.8.3.4.............................................................................Tuning Result

7-137

7.8.4. SQL Tuning Package (Manually)......................................7-139

7.8.4.1....................................................................Using Snapshot ID

7-140

7.8.4.2..................................................................................Using STS

7-142

7.8.5. SQL Profile 적용 (Manually)..............................................7-145

7.8.5.1............................................................................Accept Profile

7-145

7.8.5.2........................................................................Profile Category

7-146

[email protected] 5


7.8.5.3.................................................................................Profile 수정

7-146

7.8.6. STS Control (Manually)....................................................7-147

7.8.6.1.............................................................STS의 생성과 SQL Load

7-147

7.8.6.2......................................................................STS와 SQL의 조정

7-148

7.8.7. SQL Access Advisor.........................................................7-150

7.8.7.1.....................................................................................대상 SQL

7-151

7.8.7.2........................................Access Path 분석 Option과 권고사항

7-152

7.8.7.3............................................................Access 분석 (Using em)

7-153

7.8.7.4............................................................Access 분석 (Manually)

7-165

7.9. Instance Monitoring..............................................................7-176

7.9.1. Monitoring 방안...............................................................7-176

7.9.2. Database Control............................................................7-176

7.9.3. em의 성능 진단 및 관리.....................................................7-176

7.10. Resource Manger..................................................................7-181

7.10.1. Oracle10g New Features.................................................7-181

7.10.2. Original Consumer Group으로 돌아가기............................7-181

7.10.2.1. Switch Time(Top Call)..........................................7-182

7.10.2.2. Using em............................................................7-188

7.10.3. Idle Time의 설정...............................................................7-189

7.10.3.1. Session Idle Time................................................7-189

7.10.3.2. Session Blocking Time........................................7-191

7.10.3.3. Using em............................................................7-194

7.10.4. 유연한 Resource Group의 할당..........................................7-194

7.10.4.1. Resource Group Mapping....................................7-196

7.10.4.2. Resource Group Priority......................................7-198

7.10.4.3. Using em............................................................7-207

7.10.5. New Resource 할당 방법...................................................7-208

7.10.5.1. CPU 할당 방식......................................................7-208

7.10.5.2. CPU RATIO 할당의 예............................................7-209

[email protected] 6


7.10.6. Monitoring Resource Manager........................................7-214

7.11. Space 관리 자동화..................................................................7-216

7.11.1. 개요.................................................................................7-216

7.11.2. Tablespace......................................................................7-216

7.11.2.1. Tablespace Usage...............................................7-216

7.11.2.2. Threshold의 설정과 의미.......................................7-218

7.11.3. Segment와 Block 관리방식...............................................7-219

7.11.3.1. Segments내부의 관리방식 변화.............................7-219

7.11.3.2. Shrink Segment 속성...........................................7-221

7.11.3.3. Shrink Command, 속성, Oracle9i Coalesce..........7-222

7.11.3.4. Shrink Example...................................................7-223

7.11.3.5. Using em............................................................7-229

7.11.4. Segment Advisor.............................................................7-232

7.11.4.1. 개요 및 Segment 분석..........................................7-232

7.11.4.2. Segment Advisor (Using em)..............................7-236

7.11.4.3. Segment Trend....................................................7-240

7.11.4.4. Segment Size Estimation....................................7-242

7.11.5. Undo Management..........................................................7-246

7.11.5.1. Undo 관리 화면.....................................................7-246

7.11.5.2. Undo Advisor......................................................7-247

[email protected] 7


7. 자가관리(self-management) Database System

이번 장에서 설명되는 내용은 점점 복잡, 다양화되고 관리할 database의 수가

늘어남은 물론 그 크기도 대용량화 되어가는 database환경의 변화 추세에서 그 만큼

늘어나는 database관리의 부담을 줄여주기 위해 제공되는 oracle10g의 new

features인 자가관리 database 시스템이다.

Oracle의 자료에 따르면 대부분의 DBA가 시스템관리를 위해 소비하는 시간은 다음과

같은 유형을 보인다고 한다.

Item Rate

oracle install 6 %

database 생성 12 %

data loading 6 %

system 관리 55 %

S/W 유지보수 6 %

위 도표에서 보듯 가장 많은 시간을 소요하는 것은 system관리 부분으로 무려 55%나

된다. 그리고 그 나머지 부분들은 사실상 크게 시간을 줄이기가 어려운 부분이기도

하다. 다음은 이런 항목들이 앞서 배운 내용들을 토대로 oracle10g에서 어떻게 도움을

줄 수 있는지 나열한 것이다.

1. oracle database를 install하고 s/w를 관리하는 부분은 oracle10g의 관련 step

들이 많이 줄었기 때문에 비교적 간단해 졌다고 볼 수 있다.

2. database를 생성하는 것은 oracle10g의 seed database를 이용하면 DBA의

역량에 따른 많은 도움이 될 수 있다.

3. data loading부분은 oracle10g의 datapump기능과 새로운 transportable

tablespace방법을 잘 이용하면 또한 도움이 될 수 있다. (물론, DBA에 의존적이다)

4. system관리는 가장 중요하고 가장 많은 시간을 소비하는 부분이지만 현재까지 배운

내용을 토대로 보면 도움을 받을 수가 없다. 그러나 이번 장에서 소개하는 자가관리

database 시스템을 잘 이해하면 DBA의 부담을 많이 줄여줄 수 있을 것이다.

CF. 물론, 어느 것 하나 그냥 쉽게 database 관리의 부담을 벗어나게 해주는 것은

없다. 회사가 보유한 DBA의 역량에 따라 또 DBA 본인이 알고 있는 지식과 노력만큼

작업부담도 줄어드는 것임을 명심하자.

[email protected] 8

표 7-1

DBA 작업유형


7.1. 자동진단(automatic diagnostic) 시스템

7.1.1.ADDM (Automatic Database Diagnostic Management)

Database의 관리 부분에서 database의 상태를 스스로 진단하고 관리하는 시스템을

말한다. 이는 database의 유형에 상관없이(OLTP, DSS등) 내부에서 자동진단 engine

을 탑재하고 성능문제를 포함하는 분석자료를 Top-Down형식으로 제공해주고

해결책을 추천하는 oracle10g의 new feature를 말한다.

7.1.1.1. ADDM 관리 point

1. advisor 제공으로 진단결과에 대해 oracle이 권장하는 제안기능

2. space부족등과 같은 문제점을 경고하는 alert 기능

3. 미리 준비된 기능을 이용하여 resource에 대한 관리 및 통제기능

4. 운영중인 database의 관리를 위한 자동부하 저장소 관리기능

7.1.1.2. ADDM 성능 모니터여러 가지 표현으로 또는 여러 용어로 설명되는 이 내용들은 결국은 oracle이 제공하는

(새로 제공하거나 과거부터 제공해 왔던) 통계정보를 취합함으로 이루어진다.

Oracle10g는 이러한 통계정보를 SGA로부터 default로 1시간마다 한번씩 capture

하여 snapshot형식으로 저장하게 되는데 이곳이 향후 설명되는 Automatic

Workload Repository인 자동부하저장소(이하 AWR) 이다. 이는 이전 버전에서

제공되던 oracle statspack과 유사하나 oracle10g의 AWR은 이보다 더 상세한

내역들을 가지고 있다.

이러한 정보들은 oracle의 새로운 background process인 MMON(Manageability

Monitor) process에 의해 자동으로 snapshot되는데 이 때마다 ADDM이 마지막 두

snapshot을 가지고 분석을 수행하고 그 결과가 AWR에 저장된다.

CF. 사실 ADDM의 분석은 MMON process에 의해 trigger된다. 또한 필요하다면

manually 시점에 상관없이 ADDM으로 하여금 원하는 시기의 두 snapshot간의

분석을 수행하여 report를 산출할 수도 있다.

종합하면 다음과 같이 ADDM의 활동과 분석을 정리할 수 있겠다.

1. oracle10g는 스스로 분석에 필요한 통계정보를 snapshot 형태로 수집한다.

2. oracle10g는 주기적으로 자동 분석작업을 수행하며 항상 마지막 두 snapshot간의

분석결과를 저장한다.

3. 사용자는 기 분석된 자료를 통해 결과를 확인할 수 있다.

4. 필요하다면 사용자는 운영 database에서 성능 issue가 제기되는 특정 시점간의

[email protected] 9


분석을 ADDM snapshot을 이용하여 개별적으로 수행하도록 할 수 있다.

5. 여러분은 직접 advisor package나 addm script 또는 em을 사용하여 분석 결과를

확인할 수 있으며 report를 산출할 수도 있다.

다음은 새로운 background process MMON을 확인한 결과이다.

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

root 1786 1 0 Jul29 ? 00:00:00 /bin/su -l oracle -c exec

/app/oracle/product/10.1.0/bin/ocssd

oracle 1939 1786 0 Jul29 ? 00:00:00

/app/oracle/product/10.1.0/bin/ocssd.bin

oracle 1993 1 0 Jul29 ? 00:00:00

/app/oracle/product/10.1.0/bin/tnslsnr LISTENER -inherit

oracle 18052 1 0 Aug11 ? 00:00:00 ora_pmon_NEWSVC

oracle 18054 1 0 Aug11 ? 00:00:00 ora_mman_NEWSVC

oracle 18056 1 0 Aug11 ? 00:00:06 ora_dbw0_NEWSVC

oracle 18058 1 0 Aug11 ? 00:00:12 ora_lgwr_NEWSVC

oracle 18060 1 0 Aug11 ? 00:00:01 ora_ckpt_NEWSVC

oracle 18062 1 0 Aug11 ? 00:00:30 ora_smon_NEWSVC

oracle 18064 1 0 Aug11 ? 00:00:00 ora_reco_NEWSVC

oracle 18066 1 0 Aug11 ? 00:00:44 ora_cjq0_NEWSVC

oracle 18070 1 0 Aug11 ? 00:00:04 ora_rvwr_NEWSVC

oracle 18074 1 0 Aug11 ? 00:00:03 ora_arc0_NEWSVC


oracle 18078 1 0 Aug11 ? 00:00:00 ora_qmnc_NEWSVC

oracle 18080 1 0 Aug11 ? 00:00:09 ora_mmon_NEWSVC

oracle 18082 1 0 Aug11 ? 00:00:00 ora_mmnl_NEWSVC

oracle 7427 1 0 15:36 ? 00:00:00 ora_q000_NEWSVC

oracle 7431 1 0 15:38 ? 00:00:00 ora_j000_NEWSVC

oracle 7434 7433 0 15:38 pts/0 00:00:00 -bash

oracle 7463 7434 1 15:38 pts/0 00:00:00 ps -ef

oracle 7464 7434 0 15:38 pts/0 00:00:00 grep ora

CF. 위에서 굵게 표시된 process의 이름을 확인하라.

CF. oracle10g release 2부터는 CPU, paging, memory cache등 hardware

[email protected] 10


resource에 대한 성능 분석이 더욱 포괄적으로 더 자세하게 분석이 가능해 지고

RMAN, AQ(advanced queuing)와 같은 oracle server components의 분석도

지원된다. 그리고 특정 시점간의 성능차이에 대한 분석 report인 “Compare Periods

Report”가 제공된다.

7.1.1.3. ADDM의 분석방향이제 ADDM은 어떻게 분석을 수행하고 처리하는 절차를 담고 있는지를 알아 보도록

하자. 이를 ADDM methodology(방법론)이라고 하는데 대체적으로 resource

bottleneck 즉, 리소스에 대한 wait 현상을 top-down 방식으로 접근하여 처리한다.

Oracle10g는 새로운 time 통계정보를 통해 oracle이 소비한 시간이 어디에서

이루어졌는가를 판단할 수 있도록 해줌으로써 매우 유용한 정보를 분석할 수 있게 된다.

이러한 정보들은 tuning이 가능한 모든 요소들을 tree형태로 관리함으로써 결국은

top-down approach를 가능하도록 해주게 되는데 이를 “new wait model

statistics” 즉, oracle의 새로운 wait 통계모델이라 할 수 있다. 바로 이것이 ADDM의

핵심 기반이 된다.

이 모델은 각종 현상들을 중심에 두고 이들 각각의 문제들을 time base로 진단을

하도록 tree 구조를 제공하게 된다. 예를 들어 시스템 wait “A” 항목을 하나의

현상이라 하면 해당 wait이 발생했을 때 그것의 문제점을 세부적으로 분석해 들어가

최종적인 문제를 찾아내는 것이다. 만일, 그 wait “A”가 memory에서 왔다면

memory중 문제가 된 sub tree를 찾게 되고 해당 sub tree 중 buffer cache가

문제라면 그 buffer cache의 어떤 문제인지를 찾게 되는 top-down형식의 진단이

되는 것이다.

CF. ADDM 분석은 길어도 3초를 넘지 않기 때문에 운영 database에 별다른 부담을

주지는 않는다.

다음은 oracle10g가 이야기 하는 ADDM의 주요 성능 모니터 요소로서 사용되는

용어들은 oracle이 제공하는 그대로다. 성능관련 용어임으로 말 그대로 익숙해 지도록

하자.

1. excessive logon/logoff

2. memory undersizing

3. hot blocks and objects w/SQL

4. RAC service issues

5. locks and ITL contention



6. checkpointing causes

7. PL/SQL, Java time

8. Top SQL

9. I/O issues

10. parsing

11. configuration issues

12. application usage

7.1.2.ADDM Configuration

7.1.2.1. Initial Parameter

ADDM을 사용하기 위해서는 통계 level parameter인 “statistics_level”의 값을

설정해야 한다. 이 parameter는 dynamic parameter로 “alter system, alter

session”의 command로 수정할 수 있다. 이 parameter에 줄 수 있는 값은 “typical”,

“all”, “basic”이 있는데 ADDM을 위해선 반드시 “typical”이나 “all”을 설정해야 한다.

기본적으로 설정되는 값은 typical로서 대부분의 중요한 통계정보를 ADDM을 위해

수집하게 되는데 대부분의 시스템에서는 이 default 값으로 충분하다. 만일 이 값을 all

로 설정하게 되면 typical의 정보와 함께 time base의 OS정보와 execution plan

정보를 추가적으로 취합한다.

이런 정보가 필요 없다면 “basic”을 설정하면 되는데 이 경우엔 다음과 같은 자가진단

database에 필요한 정보들을 취합하지 않는다.

1. Automatic Workload Repository (AWR) Snapshots

2. Automatic Database Diagnostic Monitor (ADDM)

3. All server-generated alerts

4. Automatic SGA Memory Management

5. Automatic optimizer statistics collection

6. Object level statistics

7. End to End Application Tracing (V$CLIENT_STATS)

8. Database time distribution statistics (v$sess_time_model and

v$sys_time_model)

9. Service level statistics

10. Buffer cache advisory

11. MTTR advisory

12. Shared pool sizing advisory

13. Segment level statistics

14. PGA Target advisory



15. Timed statistics

16. Monitoring of statistics

CF. oracle10g가 강력하게 추천하는 것은 ADDM을 enable하는 것이다. 즉, 이

parameter의 값을 “basic”으로 설정하여 중요한 통계정보를 누락시키지 않을 것을

권고하고 있다.

7.1.2.2. ADDM Report

ADDM 결과를 확인하기 위한 report는 향후에 설명할 em을 통하는 방법도 있지만

SQL이나 report script를 활용할 수도 있다.

1. SQL을 통해 report 만들기

이 방법은 두 가지 의미를 가진다. ADDM으로 분석된 결과를 확인하는 경우나

dbms_advisor의 sub-stored procedure call을 통해 직접 분석을 수행한 후 그

결과를 확인하는 방식을 말한다.

먼저 가장 최근의 ADDM 분석결과를 확인하는 방법을 해보자. 먼저, task 이름을

확인하고 이를 이용하여 report를 산출한다. 단, report를 산출하는 function의 return

type은 CLOB임으로 너무 큰 값을 여기서 다 보여줄 수가 없다. 따라서 여기서는 전체

결과 report 중에서 처음의 약간만을 보도록 하겠다. (여러분은 spool을 통해 file로

받는 것이 좋은 방법이 되겠다)

SYS> select task_name from dba_advisor_tasks where task_id =

2 (select max(ts.task_id) from dba_advisor_tasks ts, dba_advisor_log tl

3 where ts.task_id = tl.task_id and ts.advisor_name = 'ADDM'

4 and tl.status = 'COMPLETED');

TASK_NAME

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

ADDM:3941507194_1_1294

SYS> set long 1000000 pagesize 0 longchunksize 1000

SYS> select dbms_advisor.get_task_report('ADDM:3941507194_1_1294')

2 from dual;

DETAILED ADDM REPORT FOR TASK 'ADDM:3941507194_1_1294' WITH ID

1299

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



--

Analysis Period: 17-AUG-2005 from 09:00:31 to 10:00:10

Database ID/Instance: 3941507194/1

Database/Instance Names: NEWSVC/NEWSVC

Host Name: LIRACLE

Database Version: 10.1.0.4.0

Snapshot Range: from 1293 to 1294

Database Time: 1644 seconds

Average Database Load: .5 active sessions

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~

FINDING 1: 49% impact (804 seconds)

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

SQL statements consuming significant database time were found.

RECOMMENDATION 1: SQL Tuning, 30% benefit (494 seconds)

ACTION: Run SQL Tuning Advisor on the SQL statement with SQL_ID

"6pb9k95mbvzfw".

RELEVANT OBJECT: SQL statement with SQL_ID 6pb9k95mbvzfw and

PLAN_HASH 1

INSERT INTO MGMT_METRICS_RAW(COLLECTION_TIMESTAMP, KEY_VALUE,

METRIC_GUID, STRING_VALUE, TARGET_GUID, VALUE) VALUES ( :1, NVL(:2,

:"SYS_B_0"), :3, :4, :5, :6)

RECOMMENDATION 2: SQL Tuning, 13% benefit (211 seconds)

ACTION: Run SQL Tuning Advisor on the SQL statement with SQL_ID

"91h2x42zqagcm".

RELEVANT OBJECT: SQL statement with SQL_ID 91h2x42zqagcm and

PLAN_HASH 2315018254

UPDATE MGMT_CURRENT_METRICS SET COLLECTION_TIMESTAMP = :B3 , VALUE =

:B2 , STRING_VALUE = :B1 WHERE TARGET_GUID = :B6 AND METRIC_GUID =

:B5 AND KEY_VALUE = :B4 AND COLLECTION_TIMESTAMP < :B3



…….

…….

SYS>

위의 결과는 SQL Tuning이 시급한 문제이며 해당 SQL의 ID를 알려주고 있다. 즉, 위와

같은 report는 최근의 결과를 확인하는 방법이 되겠다.

만일, 여러분이 이 package를 직접 사용하여 특정 시점간의 ADDM 분석을 직접

수행하고 report를 추출하고 싶다면 다음과 같이 package를 사용하면 되겠다. 먼저

check할 시간대를 인지한 후 해당 시간대의 snapshot id 범위를 확인하고 이를

이용하면 된다. 다음은 최근의 시간대를 이용한다는 가정하에 작업을 진행한 것이다.

SYS> set pagesize 100

SYS> col snap_start for a20

SYS> select * from ( select snap_id,

2 to_char(BEGIN_INTERVAL_TIME, 'YYYYMMDD HH24:MI:SS') "snap_start"

3 from dba_hist_snapshot

4 order by 2 desc) where rownum < 10;

SNAP_ID snap_start

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

1297 20050817 12:01:01

1296 20050817 11:00:22

1295 20050817 10:00:10

1294 20050817 09:00:30

1293 20050817 08:00:51

1292 20050817 07:00:09

1291 20050817 06:00:30

1290 20050817 05:00:51

1289 20050817 04:00:18

9 rows selected.

SYS> select dbid from v$database;



DBID

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

3941507194

SYS> select instance_number from v$instance;

INSTANCE_NUMBER

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

1

위의 snapshot 시간대를 보고 만일 17일 오전 07시부터 10시 사이에 database

system에 문제가 있었다고 판단되었고 이 시간대의 분석 report를 추출하고자 한다면

해당 시간대의 snapshot id와 dbid 및 instance number를 가지고 다음과 같이

작업을 수행한다.

SYS> var v_task varchar2(100)

SYS> var v_id number

SYS> exec dbms_advisor.create_task('ADDM', :v_id, :v_task);

PL/SQL procedure successfully completed.

SYS> exec dbms_advisor.set_task_parameter(:v_task, 'START_SNAPSHOT',

1292);


SYS> exec dbms_advisor.set_task_parameter(:v_task, 'END_SNAPSHOT',

1295);


SYS> exec dbms_advisor.set_task_parameter(:v_task, 'INSTANCE', 1);


SYS> exec dbms_advisor.set_task_parameter(:v_task, 'DB_ID',



3941507194);


SYS> exec dbms_advisor.execute_task(:v_task)


위 과정을 통해서 직접 특정 시간대에 대한 ADDM 분석을 수행하였다. 마지막 작업은

아래와 같이 report 추출 작업을 수행하면 된다. 역시 너무 긴 내용임으로 결과는 직접

확인하시기 바란다.

SYS> set long 1000000 pagesize 0 longchunksize 1000

SYS> select dbms_advisor.get_task_report(:v_task)

2 from dual;

DETAILED ADDM REPORT FOR TASK 'TASK_1305' WITH ID 1305

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




Host Name: LIRACLE




Average Database Load: .2 active sessions

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~

FINDING 1: 55% impact (1327 seconds)

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

SQL statements consuming significant database time were found.

…………..



…………..

…………..

SYS>

사실 위 절차들은 oracle이 제공하는 script를 사용하면 그대로 이루어진다. 굳이 직접

수행할 필요는 없지만 script가 없거나 remote에서 SQL*Plus login만 가능하다면 위

절차를 알아둘 필요는 있다.

2. report script 사용하기

다음은 oracle이 제공하는 report script를 통해 과거의 snapshot id로 범위를 주어

ADDM report를 만드는 방법이다. 아래 내역 중에서 굵게 표시된 부분이 여러분이

입력하는 snapshot id의 범위와 report이름이다.

SYS> @?/rdbms/admin/addmrpt

Current Instance

~~~~~~~~~~~~~~~~

DB Id DB Name Inst Num Instance

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

3941507194 NEWSVC 1 NEWSVC

.....

.....

Listing the last 3 days of Completed Snapshots

Snap

Instance DB Name Snap Id Snap Started Level

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

NEWSVC NEWSVC 1212 14 Aug 2005 00:00 1

1213 14 Aug 2005 01:00 1

1214 14 Aug 2005 02:00 1

1215 14 Aug 2005 03:00 1

1216 14 Aug 2005 04:01 1

1217 14 Aug 2005 05:00 1



…..

…..

Specify the Begin and End Snapshot Ids

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Enter value for begin_snap: 1268

Begin Snapshot Id specified: 1268

Enter value for end_snap: 1272

Specify the Report Name

~~~~~~~~~~~~~~~~~~~~~~~

The default report file name is addmrpt_1_1268_1272.txt. To use this name,

press <return> to continue, otherwise enter an alternative.

Enter value for report_name: addmrpt_test.txt

.....

.....

An explanation of the terminology used in this report is available when you

run the report with the 'ALL' level of detail.

SYS> !more addmrpt_test.txt

DETAILED ADDM REPORT FOR TASK 'TASK_1278' WITH ID 1278

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






Host Name: LIRACLE




Average Database Load: 0 active sessions

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~

THERE WAS NOT ENOUGH INSTANCE SERVICE TIME FOR ADDM ANALYSIS.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~

ADDITIONAL INFORMATION

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

There was no significant database activity to run the ADDM.

The analysis of I/O performance is based on the default assumption that the

average read time for one database block is 10000 micro-seconds.

An explanation of the terminology used in this report is available when you

run the report with the 'ALL' level of detail.

SYS>

3. em을 이용하기

위 두 결과보다 em을 사용하면 훨씬 유연하고 편하게 ADDM 분석을 수행하고 확인할

수 있다.



7.1.3.ADDM using em

7.1.3.1. em Start

먼저 em을 활용하기 위해 dbconsole을 start한다.

[NEWSVC]LIRACLE:/app/oracle/temp> emctl start dbconsole

TZ set to ROK

Oracle Enterprise Manager 10g Database Control Release 10.1.0.4

Copyright (c) 1996, 2004 Oracle Corporation. All rights reserved.

http://LIRACLE:5501/em/console/aboutApplication

Starting Oracle Enterprise Manager 10g Database Control .................

started.

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

Logs are generated in directory

/app/oracle/product/10.1.0/LIRACLE_NEWSVC/sysman/log

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

URL 확인 후 다음과 같이 접속을 해보자.

1. 다음과 같이 접속을 시도하면

2. 다음과 같은 초기 화면에서 현재 database의 전반적인 상태를 보여주는 database

control화면(기본화면)이 나타나게 된다. (물론, 이 화면 전에 license관련 동의를 묻는

화면이 나오면 동의를 누르고 넘어가면 된다) 화면은 크게 진단에 내역과 경고성


그림 7-1

em login 창


메시지를 나타내는 부분이 상중하로 나뉘어 지며 아래 화면 우측 상단에서처럼

자동으로 refresh를 하거나 사용자가 원할 때 수동으로 refresh를 하도록 선택할 수도

있다.

상단화면 :

중단화면 :


그림 7-2

em 초기화면

그림 7-3

em 초기화면


하단화면 :

7.1.3.2. Advisor Central (중앙 권고자)

위 하단화면에서 ADDM 분석을 해보기 위해선 Advisor Central(중앙 권고자)로

이동을 해야 한다. 이를 click한다.


그림 7-4

em 초기화면

그림 7-5

em 중앙권고자


CF. 위 화면에서 하단을 보면 현재 권고사항이 있는 작업내역이 보인다. 현재는 ADDM

부문에서 분석된 자료가 있다는 뜻이다. 이것을 click해서 곧 바로 oracle이 제안하는

문제를 파악하고 그 해결책에 접근할 수도 있다.

이제 좌측 상단의 ADDM을 선택하여 분석화면으로 이동한다.

다음은 위 화면에서 분석을 시작할 시간과 마지막 시간을 설정하는 과정이다. 먼저

시작시간 radio button을 선택한 후 화면 하단 그래프 밑에서 원하는 시간대를 click

하면 자동으로 선택이 된다.


그림 7-6

ADDM 설정화면


같은 방법으로 종료시간을 설정하면 다음과 같이 선택이 완료된다. 현재는 그래프

우측에서 약간의 작업이 있었던 것으로 추측되는 시간대를 선택했다. 확인을 눌러보자.

최종적으로 아래와 같은 결과를 확인할 수 있다.


그림 7-7

ADDM 설정화면

그림 7-8

ADDM 설정화면

그림 7-9

ADDM 결과


좌측에는 시스템에 준 영향순서대로 우측에는 그 내용과 권고사항이 나타난다. 이제

여러분은 tuning하고자 하는 대상을 click하여 하나씩 문제를 해결할 수 있게 된다.

7.1.3.3. ADDM Report using em

앞서 언급한 3번째 ADDM report는 em을 이용하는 것이다. 위 화면에서 “보고서 보

기”를 선택하면 아래와 같은 보고서를 볼 수 있으며 이를 버튼을 통해 file로 저장할

수도 있다.

7.1.4.I/O 속성ADDM으로 관리되는 여러 진단요소들 중에서 I/O와 관련하여 고려할 부분이 있다.

보통 자가진단 database를 구성할 때 oracle10g가 제공하는 기본 값들을 가지고

자동으로 분석이 진행되지만 I/O의 경우 사용자의 필요에 의해 기준 값을 변경할

필요가 있을 수 있다. 그것은 I/O의 기준 값이 현재 database를 구성하는 system의

hard disk system특성에 의존적인 측면이 있기 때문에 광범위하게 적용되는 기준

값으로는 충분치 않은 경우가 존재할 수 있기 때문이다002E

이 값은 oracle10g의 새로운 view인 “dba_advisor_def_parameters”를 통해서

확인할 수 있고 새로운 package “dbms_advisor”의

“set_default_task_parameter” procedure를 통해 수정할 수 있다.

보통 이 값은 ADDM의 “DBIO_EXPECTED”로 표현되고 단위는 microseconds이며 이

값의 default는 10000 microseconds (10 milliseconds)로 설정이 되어있다.

Parameter “DBIO_EXPECTED”는 I/O subsystem으로부터 기대하는 성능의 지표를


그림 7-10

ADDM Report


의미하는데 single database block을 read하는데 걸리는 평균 기대시간을 의미한다.

대부분의 시스템에서는 default로 제공되는 값인 “10000” microseconds가

일반적으로 적용될 수 있지만 만일 여러분이 사용하는 disk I/O system이 좀 특수하여

이 값을 수정할 필요가 있다면 즉, 기대하는 block read 시간이 따로 있다면 다음과

같이 관련 package를 call해서 이를 변경해야만 적절한 ADDM결과를 얻을 수 있을

것이다.

예를 들어 이 값을 9000으로 해야 한다면 다음과 같이 변경할 수 있다. (by sys)

SQL> exec dbms_advisor.set_default_task_parameter(‘ADDM’, ‘DBIO_EXPECTED’,

9000);



OCP point

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

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

1. ADDM 정의와 MMON process의 활동 주기

2. ADDM의 활동과 분석

3. ADDM 분석방향

4. ADDM 관련 parameter statistics_level의 의미와 설정 가능한 값의 정의

참조

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

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

RMAN : o8 73p, o8i 172p, o9i 470p

AQ : o8 58p, o8i 173p



7.2. SGA Memory 관리 자동화

7.2.1.빈번한 Memory 오류 유형Oracle error “ora-4031”은 oracle memory관련 error message중 가장 흔하게 (

빈번하지는 않더라도) 볼 수 있는 오류로 “unable to allocate …”류의 memory할당

문제를 표현하는 대표적인 메시지다.

이런 류의 오류메시지를 구체적으로 확인하면 shared pool의 부족이나 bind 변수를

제대로 사용하지 않는 SQL의 과도한 사용으로 shared pool의 fragmentation

발생문제, large pool의 부족 또는 java pool의 부족 등 결과적으로 SGA의 memory

설정이 원인이자 해결책인 것이 대부분이다. 즉, SGA를 구성하는 buffer cache,

shared pool, Java pool, large pool, redo log buffer와 같은 값들을 어떻게

설정하는가가 중요한 문제가 된다.

CF. 이들 구성요소 중 redo log buffer는 그 크기도 작고 성격도 다른 요소들과 틀리기

때문에 여기서의 주요 관심사는 아님으로 다른 요소들에 대하여 이야기를 할 것이다.

DBA가 직접 이런 값들을 잘 설정하여 운영하는 것은 매우 중요한 문제이지만 반대로

계속 변하는 application의 유형이나 data작업의 시간대 변경 또는 backup 정책의

변경 등은 위와 같은 parameters의 적절한 값을 설정한다는 것 자체가 불가능 하다는

반증이기도 하다. 오히려 정확하게 하려면 DBA 스스로 매 시간, 때마다 database의

작업내역을 파악하여 dynamic하게 그때그때 필요한 memory parameters의 값을

변경하는 것이 더 합리적일 것이다. (물론, 그러한 방식이 올바르지는 않더라도 말이다)

만일 oracle이 이런 작업을 스스로 해줄 수 있다면 database를 관리하는 입장에서는

얼마나 큰 도움이 될 것인가! Oracle10g가 소개하는 자동공유메모리관리가 바로 이런

기능을 제공해 준다.

7.2.2.Automatic Shared Memory Management

7.2.2.1. SGA Size

이 기능을 사용하기 위해(SGA 자동관리를 enable하기 위해) DBA가 할 일은 전체

SGA size만 지정하면 된다. 간단하게 initial parameter sga_target만 설정하면

된다는 것이다. 얼마나 많은 양을 사용할지 모르겠다면 간단히 현재의 SGA size를

확인하고 이를 먼저 적용하여 점차로 그 효율성을 확인할 수 있다.

CF. 따라서 sga_target를 설정하지 않으면 memory 자동관리는 disable, 설정하면



enable이 되겠다.

각자 현재의 SGA size를 확인해 보자.

SYS> select sum(value)/1024/1024

2 from v$sga;

SUM(VALUE)/1024/1024

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

408

현재는 408MB로 설정이 되어 있음을 확인할 수 있다.

7.2.2.2. Initial Parameter

이제 parameter를 수정한 후 database를 다시 start하자. 사실 sga_target을

설정하게 되면 아래와 같은 parameters가 자동으로 설정 및 유지관리가 됨으로 이

parameters를 없애거나 값을 0으로 설정하면 된다.

Parameter Value

shared_pool_size 0

large_pool_size 0

java_pool_size 0

db_cache_size 0

Initial parameter file을 수정하여 database를 start하자. 그리고 sga_target는 대략

450MB로 설정할 것이다.

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

…

…

...

# -------------------------- Memory and I/O 관련 parameters ------------------------

## estimated sga max size

#sga_max_size = 524288000 # 500M

sga_target = 450M

## Database block cache and I/O

db_block_size = 8192 # 8K

#db_cache_size = 209715200 # 200M


표 7-2

자동유지 SGA 요소


#db_4k_cache_size = 20971520 # 20M

#db_16k_cache_size = 31457280 # 30M

#db_keep_cache_size = 10485760 # 10M

#db_recycle_cache_size = 10485760 # 10M

## Redo log buffer size

log_buffer = 5242880 # 5M

## Shared and other pools

#shared_pool_size = 150944944 # for 10g

#java_pool_size = 50331648 # for 10g

#large_pool_size = 5242880 # 5M

## PGA, Sort, Hash Joins, Bitmap Indexes and others

pga_aggregate_target = 104857600 # 100M

workarea_size_policy = AUTO

…

…

~

~

~

~

:wq!


위와 같이 sga_target을 설정하고 sga 관련 parameters를 모두 주석처리 하였다.

Database가 restart된 후 그 변화를 살펴보자.

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

SQL*Plus: Release 10.1.0.4.0 - Production on Wed Aug 17 14:59:42 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

Redo Buffers 5242880 bytes

Database mounted.

Database opened.

SYS> select current_size from v$buffer_pool;

CURRENT_SIZE

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

316

SYS> select pool, sum(bytes)/1024/1024 MB

2 from v$sgastat

3 where pool is not null

4 group by pool;

POOL MB

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

java pool 8

large pool 4

shared pool 120

각 size의 합은 sga_target과 거의 일치함을 확인할 수 있다.



자, 현재 sga가 변경될 필요가 생겼다고 가정해 보자. 먼저, 500MB로 늘리고 싶다면

다음과 같이하면 된다.

SYS> alter system set sga_target=500M;

alter system set sga_target=500M

*

ERROR at line 1:

ORA-02097: parameter cannot be modified because specified value is

invalid

ORA-00823: Specified value of sga_target greater than sga_max_size

불행하게도 error가 return되었다. 그 이유는 parameter 설정 시 sga_max_size를

지정하지 않아서 sga_max_size의 값이 sga_target의 값과 같게 설정이 되었기

때문이다. 즉, 현재의 sga는 더 늘어날 수가 없는 것이다.

하지만 sga를 줄이는 것은 다음과 같이 가능하며 이를 다시 늘리는 것도

sga_max_size의 범위 안에서는 유효하다.


System altered.


CURRENT_SIZE

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

260


2 from v$sgastat


4 group by pool;

POOL MB

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

java pool 8



large pool 4

shared pool 120


System altered.

자연스럽게 줄어든 것을 확인할 수 있으며 다시 늘리는 것도 가능하다는 것을 볼 수

있었다.

7.2.3.Memory 자동관리 체계와 Limit

7.2.3.1. Memory 자동관리 Process

Oracle10g는 memory관리의 자동화를 위한 새로운 background process인 MMAN

즉, Memory Manager process를 사용한다. 이 process에 의해 주기적으로 system

의 workload정보를 취합하여 SGA를 자동으로 관리해주게 된다.

이 process는 항상 현재 시점에서 적절한 SGA의 설정이 이루어질 수 있도록 거의 몇

분 단위로 계속 check를 진행한다. 그리고 그 결과에 따라 memory를 이동하고 spfile

을 사용하는 경우 parameter file도 수정한다.

확인을 해보면 다음과 같다. 굵은 색의 이름을 확인하라.

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

oracle 18294 1 0 15:00 ? 00:00:00 ora_pmon_NEWSVC

oracle 18296 1 0 15:00 ? 00:00:00 ora_mman_NEWSVC

oracle 18298 1 0 15:00 ? 00:00:00 ora_dbw0_NEWSVC

oracle 18300 1 0 15:00 ? 00:00:00 ora_lgwr_NEWSVC

oracle 18302 1 0 15:00 ? 00:00:00 ora_ckpt_NEWSVC

oracle 18304 1 0 15:00 ? 00:00:01 ora_smon_NEWSVC

oracle 18306 1 0 15:00 ? 00:00:00 ora_reco_NEWSVC

oracle 18308 1 0 15:00 ? 00:00:00 ora_cjq0_NEWSVC

oracle 18312 1 0 15:00 ? 00:00:00 ora_rvwr_NEWSVC

oracle 18316 1 0 15:00 ? 00:00:00 ora_arc0_NEWSVC

oracle 18318 1 0 15:00 ? 00:00:00 ora_arc1_NEWSVC

oracle 18324 1 0 15:01 ? 00:00:00 ora_qmnc_NEWSVC

oracle 18326 1 0 15:01 ? 00:00:01 ora_mmon_NEWSVC



oracle 18328 1 0 15:01 ? 00:00:00 ora_mmnl_NEWSVC



oracle 19175 10761 0 15:35 pts/1 00:00:00 grep ora_


7.2.3.2. Pool의 자동관리 와 Limit

각 pool의 크기는 dynamic하게 oracle 스스로 자동으로 조정한다. 즉, database의

workload가 증가하면(작업 부담이 늘어나면) 그에 비례하여 각 pool의 size도

늘어나고 다른 pool의 size는 줄어들기도 한다.

CF. 예를 들어 RMAN 작업이 시작되거나 parallel query가 주로 시작되는 저녁 batch

시간대엔 large pool이 늘어나고 buffer cache가 줄어드는 식으로 관리가 된다.

그러나 표준 block 을 사용하지 않는 buffer cache(현재 필자의 database 경우는 2K,

4K, 16K, 32K block cache)나 keep, recycle cache size는 자동관리의 대상이

아니다. 물론, 처음에 언급했던 log buffer나 oracle10g의 새로운 memory 영역인

“streams pool”도 자동관리가 되지 않는다. 다시 정리하면 다음과 같다.

Parameter 자동관리 Example (MB)

shared_pool_size Y 0

large_pool_size Y 0

java_pool_size Y 0

db_cache_size Y 0

db_keep_cache_size N 10

db_recycle_cache_size N 10

db_?k_cache_size (?는 non-standard block

size)

N 10

log_buffer N 10

streams_pool_size N 10

위의 parameters에 값이 설정되면 설사 여러분이 sga_target에 적절한 값을 주었다

할지라도 실제 SGA size에 다른 영향을 주게 되는데 그 원칙은 다음과 같다. 위의

표에서 example에 있는 값들이 실제로 적용이 되었고 sga_target이 440MB였다면

실제로 자동 tuning이 대상이 되는 memory size는 450 – (10+10+10+10+10) =

400MB로 설정된다.


표 7-3

자동관리 Memory 요소와

Parameter 종류


CF. 물론, 자동 tuning의 대상이 아닌 memory의 값이 변경되면 sga_target의 총

size에도 당연히 영향을 주게 된다. 즉, non-standard block cache가 50MB 더

늘어나면 위의 예에서 sga_target은 400 – 50 = 350MB로 더 줄어들게 된다.

자동관리의 대상이 되는 parameters라 할지라도 그 값을 DBA가 수정하는 것은

가능하다. 예를 들어 현재 운영중인 database에서 자동 tuning된 large pool의 size

가 4MB인데 DBA가 이를 8MB로 늘리고 싶어서 다음과 같이 했다고 하자.

SYS> alter system set large_pool_size=8M;

System altered.


CURRENT_SIZE

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

308


2 from v$sgastat


4 group by pool;

POOL MB

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

java pool 8

large pool 8

shared pool 120

이 때에 large pool은 바로 8MB로 늘어나고 다른 자동 tuning 대상 memory의

영역이 줄어든다. 위의 경우 buffer cache가 줄어 들었다.

그러나 DBA가 직접 이 값을 현재 보다 줄이게 되면 다른 현상이 일어난다. 예를 들어

다시 4MB로 줄여보자.

SYS> alter system set large_pool_size=4M;



System altered.


CURRENT_SIZE

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

308


2 from v$sgastat


4 group by pool;

POOL MB

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

java pool 8

large pool 8

shared pool 120

위의 결과를 보면 수정은 되었지만 실제로 각 memory영역의 값은 전혀 변하지

않았음을 알 수 있다. 즉, 자동 tuning 대상이 되는 memory parameters의 값을 현재

값보다 크게 변경하면 즉시 반영이 되지만 이 값을 적게 변경하면 즉시 반영이 되지

않는다는 것을 알 수 있다. 그렇다면 적게 변경하는 것은 어떤 의미가 있는가!

다음은 자동 memory tuning parameters와 이 parameters에 대한 수동변경이

미치는 영향을 정리한 것이다.

1. auto-tuned memory parameter를 현재 tuning된 값보다 크게 변경하면 즉시 이

값으로 SGA가 재조정된다.

2. 위와 반대로 적게 변경하면 적용은 되지만 SGA가 바로 재조정 되지는 않는다.

3. 어떤 경우이든 DBA가 직접 변경을 한 값은 그 parameter의 최소 값으로 인식하게

된다. 따라서 위 2의 경우는 자동 tuning으로 해당 parameter의 값이 줄어들어서

최소화 될 수 있는 값을 지정한 것이고 위 1은 DBA가 원하는 parameter의 최소값을

늘린 것이다.

4. 따라서 위 1, 2의 작업이 발생하면 특정 parameter에 최소 값이 설정됨으로

memory 자동 tuning으로 변경되는 size에 영향을 미치게 된다.



7.2.3.3. spfile

만일 여러분이 parameter file로 spfile을 사용하고 있다면 위와 같이 자동관리가 된

memory parameters의 값이 항시 유지될 수 있음으로 database의 shutdown과

상관없이 항상 적절한 값을 취할 수 있는 장점이 있다. 그러나 spfile이 사용되지 않으면

database가 restart될 때마다 database는 sga_target에 맞게 적절한 값을

optimizing하는 작업을 계속할 것이다.

7.2.4.Memory 자동관리 Using em

위 작업을 em에서 하기 위해서는 초기 database화면 하단의 “중앙 권고자 메모리

권고자” 를 선택하여 아래와 같은 화면에서 현재 SGA상태를 확인하고 원하는 값으로

조정하면 된다.

CF. PGA 관리화면의 예


그림 7-11

em 메모리 권고자 (SGA)

그림 7-12

em 메모리 권고자 (PGA)


OCP point

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

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

1. SGA 자동 tuning 대상 parameter 4가지

2. SGA 자동 tuning을 위한 background process

3. SGA 자동 tuning 대상 parameter와 이 값의 수동변경과의 관계

참조

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

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

SGA size, sga_max_size : o9i 335p

workload : 작업량. 통상 시스템에 영향을 주는 작업전체의 부담 정도를 표현한다.

표준 block : o9i 319p



7.3. 통계정보 자동관리

7.3.1.변화된 통계수집과거에 특히 oracle8i까지 DBA의 눈에 보이지 않는 큰 역할 중 하나는 통계수집

절차에 있었다. 그리고 그것이 눈에 보이지 않는 이유는 통계수집 자체가 이상한 SQL

성능(사실은 이상한 것이 아니지만) 결과가 나타날 때까지 다른 사람들은 모르기

때문이다. 물론, optimizer mode를 rule base로 사용하는 site도 여전히 존재하고

그들의 일관된 주장은 oracle의 cost based optimizer에 대한 믿음이 부족하다는

것이다. 그러나 필자가 볼 때 가장 큰 문제는 적절한 통계정보를 제공하지 않는

상태에서 cost based optimizer의 믿음을 논한다는 것이다. 이러한 의심은 DBA

스스로 자신의 기본 역할 중 하나인 통계수집의 적절한 수행을 먼저 이행한 후에 논해도

늦지 않을 것이다..

Oracle10g에서는 이런 부담도 줄어들게 되었다. 이른바 optimizer의 통계수집 자동화

(“Automatic Optimizer Statistics Collection”)가 그 부담을 줄여준다. 다음은

oracle database version별 통계 수집과 관련한 DBA의 역할이다.

구 분 Oracle8i Oracle9i Oracle10g

어 떻 게DBA가 결정

간단한 command자동

언 제 DBA가 결정

system (OS) 통계 No Yes (optional) Yes (optional)

table monitoring Yes (optional) Yes (optional) 자동

1. 위에서 보듯 oracle8i까지는 DBA가 통계정보를 수집하기 위해 어떤 방식으로

통계를 수집할 것인지 그리고 언제 수행할 것인지를 일일이 다 정해야 했다.

그리고 그 방식 또한 매우 다양해서 그다지 쉽지 않은 작업이다.

CF. 물론, oracle8i부터는 dbms_stats이라는 통계 package가 제공이 되어 수월해

지기는 했지만.

2. oracle9i부터는 보다 정밀한 자료를 위해 system 통계도 수집이 가능해 졌고

비교적 간단하게 한 문장으로 처리가 가능하다. 물론, system 통계수집을 언제

수행하는 것이 적절한 가를 판단하는 것은 여전히 DBA의 몫이다.

CF. system 통계를 쉽게 만들기 위해서 다음과 같은 command가 가능하다.

SQL> exec dbms_stats.gather_system_stats;

3. oracle10g는 통계작업을 자동화 해주기 때문에 DBA가 통계수집을 위해 다른


표 7-4

통계수집 방식의 변화


절차를 취할 필요가 없어졌다. 따라서 잘못된 통계정보로 인한 bad SQL plan의

가능성이 줄어들었고 또한 보다 효율적인 optimizer의 역할도 기대할 수 있게 되었다.

4. 이전 version에서는 table monitoring이 option이어서 시스템 성능과 관련하여

table monitoring 여부를 DBA가 판단했었다. 그러나 oracle10g는 자동으로 table

monitoring을 사용한다. 물론, alter table과 같은 command로 이 속성을 제어할

수는 있지만 이는 command만 유효할 뿐 실제로 영향을 주지는 않는다. 만일, 이

기능을 원치 않으면 앞서 소개했던 통계 level parameter인 “statistics_level”의 값을

“basic”으로 설정하면 된다. 달리 말하면 이 parameter의 값이 typical이나 all로

설정이 되어야만 통계정보 자동관리가 가능하다는 뜻이다.

CF. 위와 같은 이유로 table monitoring을 제어하던 dbms_stats package의

ALTER_DATABASE_TAB_MONITORING, ALTER_SCHEMA_TAB_MONITORING 이

두 procedures도 더 이상 유효하지 않다. 따라서 정리하면 이 procedures와 table의

monitoring 제어 commands를 사용할 경우 error는 return되지 않지만 아무런

역할도 하지 않는다.

7.3.2.Automatic 통계수집의 구조

7.3.2.1. 기본 개념Database가 생성되면 oracle10g는 자동으로 gather_stats_job schedule을 만들고

이 schedule에 의해 통계정보를 수집하는 job이 수행된다. 바로 이 job이 oracle

통계정보 자동수집을 위해 사용하는 procedure

“dbms_stats.gather_database_stats_job”을 call하게 된다.

말 그대로 자동이기는 하지만 이 작업이 위에서 설명한 job을 이용하기 때문에 이 job을

disable시키면 수집작업은 진행되지 않는다. 또한 ADDM과 마찬가지로 initial

parameter “statistics_level”의 값을 “typical” 또는 “all”중의 하나로 설정해야

제대로 된 통계작업을 진행할 수 있다.

7.3.2.2. 기본 Components

이제 하나씩 통계정보 수집의 구조를 파악해 보자. 먼저, 이 job이 어떻게 등록되어

있고 어떤 속성을 가지고 있는지 확인하자.

SYSTEM> col owner for a5

SYSTEM> col job_name for a20

SYSTEM> col program_name for a20

SYSTEM> col schedule_name for a25

SYSTEM> col job_class for a20



SYSTEM> col last_start for a20

SYSTEM> select owner, job_name, program_name

2 from dba_scheduler_jobs

3 where job_name = 'GATHER_STATS_JOB';

OWNER JOB_NAME PROGRAM_NAME

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

SYS GATHER_STATS_JOB GATHER_STATS_PROG

SYSTEM> select schedule_name, job_class,

2 to_char(last_start_date, 'YYYYMMDD HH24:MI:SS') last_start

3 from dba_scheduler_jobs

4 where job_name = 'GATHER_STATS_JOB';

SCHEDULE_NAME JOB_CLASS LAST_START

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

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

MAINTENANCE_WINDOW_GROUP AUTO_TASKS_JOB_CLASS 20050817

22:00:02

알아보기 쉽게 하기 위하여 두 개의 동일한 SQL을 column만 달리하여 수행했다. 위

결과로 알 수 있는 것은 sys 소유의 job gather_stats_job이 2005년 8월 17일 오후

10시에 마지막으로 수행되었고 이 job은 schedule maintenance_window_group에

의해 gather_stats_prog라는 program을 call하고 있다. 또한 이 job은 job class

auto_tasks_job_class에 속한 job이다.

다음은 앞서 이야기한 통계수집 procedure를 확인해 보자. 위에서 확인한 program

이름을 가지고 다음 SQL을 진행한다.

SYSTEM> col program_action for a50

SYSTEM> select program_type, program_action

2 from dba_scheduler_programs

3 where program_name = 'GATHER_STATS_PROG';

PROGRAM_TYPE PROGRAM_ACTION

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



STORED_PROCEDURE dbms_stats.gather_database_stats_job_proc

앞서 언급한 procedure가 “STORED_PROCEDURE”의 형태로 등록되어 있음이

확인된다.

다음으로 이 job이 속한 job class를 통해 이 job이 사용하는 resource consumer

group을 확인해 보자.

SYSTEM> select resource_consumer_group

2 from dba_scheduler_job_classes

3 where job_class_name = 'AUTO_TASKS_JOB_CLASS';

RESOURCE_CONSUMER_GROUP

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

AUTO_TASK_CONSUMER_GROUP

위 결과로 이 job이 resource consumer group으로 auto_task_consumer_group을

할당 받았음을 알 수 있다. 그러나 이 group은 선언만 되어있지 resource를 가지고

있지 않다. 언제 사용하는지는 후에 언급한다.

다음으로 스케쥴을 확인해보자. 현재 확인한 schedule은 window group임으로

window group과 그에 속한 window의 속성을 확인해야 한다.

SYSTEM> col window_name for a18

SYSTEM> col repeat_interval for a70

SYSTEM> select window_name, resource_plan, schedule_name

2 from dba_scheduler_windows where window_name in

3 (select window_name from dba_scheduler_wingroup_members

4 where window_group_name = 'MAINTENANCE_WINDOW_GROUP');

WINDOW_NAME RESOURCE_PLAN SCHEDULE_NAME

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

WEEKNIGHT_WINDOW

WEEKEND_WINDOW

현재 이 window group은 두 개의 window를 가지고 있으며 모두 resource plan과

schedule이 없다. 따라서 schedule은 직접 지정을 했다는 말이다. 다음 SQL을 보자.



SYSTEM> col duration for a15

SYSTEM> select repeat_interval, duration

2 from dba_scheduler_windows where window_name = 'WEEKNIGHT_WINDOW';

REPEAT_INTERVAL DURATION

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

- - - - -

freq=daily;byday=MON,TUE,WED,THU,FRI;byhour=22;byminute=0; bysecond=0 000

08:00:00

SYSTEM> select repeat_interval, duration

2 from dba_scheduler_windows where window_name = 'WEEKEND_WINDOW';

REPEAT_INTERVAL DURATION

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

- - - - -

freq=daily;byday=SAT;byhour=0;byminute=0;bysecond=0 +002 00:00:00

위 결과를 보면 평일과 주말에 적용되는 두 개의 window가 서로 다른 속성을 가지고

있음을 알 수 있다. 평일 window는 매일(월 ~ 금) 오후 10시에 open되어 8시간 즉,

22시에서 06시까지 유지되고, 주말 window는 토요일 자정에 open되어 2일간 즉, 48

시간 동안 유지되도록 설정이 되어있다.

7.3.2.3. 통계수집 자동화의 의미앞서 살펴본 SQL의 결과를 토대로 oracle10g가 이야기 하는 통계수집의 자동화

정책은 역시 oracle10g의 new features인 job을 통해서 이루어진다는 것을 확인할

수 있었다. 이를 종합해서 판단하면 다음과 같이 정리할 수 있다.

Oracle10g는 database를 생성함과 동시에 resource consumer group

“auto_tasks_consumer_group”에 속한 job “gather_stats_job”을 생성 및 등록을

하게 된다. 이 job은 window group “maintenance_window_group”에 의해

scheduling되는데 이 group은 평일용과 주말용 두 가지로 나누어져 있다. 평일용은

월요일부터 금요일까지 매일 저녁 10시부터 새벽 6시까지, 주말용은 매주 토요일

자정부터 48시간 동안 open 되어 program “gather_stats_prog”에 등록된

procedure “dbms_stats.gather_database_stats_job_proc”를 call함으로써

통계정보를 자동으로 수집할 것이다.



7.3.2.4. 통계수집 Control

지금까지 살펴본 내용으로 볼 때 DBA가 oracle의 통계수집 자동화에 간여할 수 있는

부분은 두 가지이다.

1. 현재 관리하는 database의 실제 운영작업 시간대와 oracle10g가 제공하는

통계작업을 위한 default schedule이 맞지 않는다면 앞서 살펴본 window를 조정할

수 있다. 생각해보라. 현재 운영 database가 주말과 평일 밤에 주로 사용되는 data

분석용 system이라면 오히려 default로 제공되는 schedule은 실제 현실과 동떨어진

최악의 상황이 될 수도 있다. 이런 경우는 당연히 이 schedule을 고쳐야 할 것이다.

2. 위에서 살펴본바 resource consumer group은 현재 아무 plan도 할당이 되어있지

않고 plan을 할당 받는 window 또한 아무 plan도 가지고 있지 않다. 따라서 원활한

통계작업을 위해 여러분이 설정 가능한 resource plan이 있다면 이를 window에

적용함으로써 보다 적절한 통계수집을 가능하게 할 수 있다.

이런 속성들을 수정하기 “dbms_scheduler.set_attribute”을 사용할 수 있지만 보다

쉽게 이를 적용하기 위해 다음과 같이 em을 활용할 수도 있다. 초기화면에서 하단의

“관리” tab을 click한 후 우측 하단의 “스케줄러” 부분의 “창”을 선택하면 다음화면을 볼

수 있다.

위 화면에서 원하는 window를 선택한 후 “편집” 버튼을 통해 수정을 할 수 있다.

7.3.3.통계정보의 Locking 과 Overriding

7.3.3.1. Lock Statistics

간단한 시나리오를 생각해보자. 어떤 특정 분석시스템을 지원하는 database가 있다.

그런 이 database는 특정 몇 개의 table을 staging영역처럼 사용하며 대량의 data를

insert하고 delete하는 용도로서 일시적으로만 사용하는(항상 full table scan이

필요한) tables이다. 그런데 oracle10g의 통계수집 자동화는 모든 table이 대상이 될

것임으로 이 대용량 table에 대해서도 통계작업을 수행할 것이다.


그림 7-13

em 스케쥴러


하지만 사실 이런 류의 table은 굳이 통계정보가 필요치 않으며 거기에 system이

resource를 낭비하는 것을 그냥 두고 보기에는 너무 아쉬울 것이다. 지금 설명하는

통계정보의 locking은 특정 table에 대한 통계정보를 수행하지 않도록 해줄 수 있다.

이런 통계정보 수집을 막기 위해 사용하는 것은 dbms_stats의 새로운 procedure를

통해 가능하며 table 단위 혹은 schema 단위로 lock을 설정하고 해제할 수 있다. 만일

lock을 설정하면 oracle은 대상 table의 관련 dependent objects의 통계도 lock을

설정하며 대상 table의 통계치를 비어있는 상태로 유지하거나 또는 현재의 상태만을

그대로 유지한다. 간단한 예를 통해 그 절차와 확인하는 방법을 해보자. 사용되는

procedure와 view를 눈 여겨 보기 바란다.

SYSTEM> select owner, table_name, stattype_locked

2 from dba_tab_statistics

3 where owner = 'SCOTT' and table_name in ('EMP', 'DEPT');

OWNER TABLE_NAME STATT

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

SCOTT DEPT

SCOTT EMP

SYSTEM> exec dbms_stats.lock_table_stats('SCOTT', 'EMP');






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

SCOTT DEPT

SCOTT EMP ALL

SYSTEM> exec dbms_stats.lock_schema_stats('SCOTT');








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

SCOTT DEPT ALL

SCOTT EMP ALL

위 결과를 통해 table 단위와 schema 단위의 통계정보 lock변화를 확인했다. 반대

작업을 진행해 보자.

SYSTEM> exec dbms_stats.unlock_table_stats('SCOTT', 'EMP');






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

SCOTT DEPT ALL

SCOTT EMP

SYSTEM> exec dbms_stats.unlock_schema_stats('SCOTT');








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

SCOTT DEPT

SCOTT EMP

7.3.3.2. Override Statistics

통계정보를 locking한 경우 dbms_stats package를 통해 통계자료에 대한 작업을

하는 경우 몇 가지 유의할 점이 있다.

1. dbms_stats.export_*_stats procedure를 사용하는 경우 table의 locking정보

즉, 대상 objects가 locked인지 아니면 unlocked인지 그 상태는 export되지 않는다.

2. 통계정보가 locking이 되어 있는 objects에 대하여 dbms_stats.set_*_stats,

delete_*_stats, import_*_stats, restore_*_stats procedure를 사용하는 경우

error가 발생된다. 그러나 이들 procedure의 새로운 argument인 force의 값을 true

로 하면 locking을 override할 수 있다. 즉, locked 상태라도 이를 무시하고

통계정보를 overwrite할 수 있다.

SQL> exec dbms_stats.delete_table_stats(‘owner’, ‘table_name’, force =>

‘TRUE’);

7.3.4.통계정보 History

7.3.4.1. History 구조Oracle은 dbms_stats package를 통해 통계정보를 수집하게 되면 그 정보들을

미래의 사용가능성을 염두에 두고 이를 “old version”으로 관리한다. 따라서 이

정보들은 나중에 필요하면 dbms_stats.restor_*_stats을 통해 restore할 수 있다.

즉, 이전 oracle version에서 old 통계정보를 사용하기 위해 export & import

statistics를 사용했다면 oracle10g에서는 그럴 필요가 없다는 것이다. 이 정보들은

default로 한달(31일)간 “dba_tab_stats_history“에 유지된다.

CF. analyze command를 사용하거나 사용자가 정의한 통계정보들은 old version

으로 보존되지 않는다.

CF. database나 schema level에서 수행된 통계정보의 시작 및 끝난 시간에 대한

기록들은 “dba_optstat_operations”를 통해 확인할 수 있다.

7.3.4.2. History 활용하기먼저 통계정보의 유지시간을 앞서 언급한 default 한달(31일)이 아니라 변경을 하고자

할 때 어떻게 하는지 알아보자. 먼저 현재의 설정을 확인하고 이를 조정해 보자.

SYSTEM> select dbms_stats.get_stats_history_retention



2 from dual;

GET_STATS_HISTORY_RETENTION

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

31

SYSTEM> exec dbms_stats.alter_stats_history_retention(61);


SYSTEM> select dbms_stats.get_stats_history_retention

2 from dual;

GET_STATS_HISTORY_RETENTION

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

61

Old version의 통계정보를 restore하가 위해서는 timestamp로 지정한 특정 시점의

old version을 가져오는 restore_*_stats을 사용하는 것이다.

(이들 procedure는 gather_*_stats 만큼이나 다양하다)

Procedure 대상 old version 통계

RESTORE_DATBASE_STATS database내의 모든 table

RESTORE_DICTIONARY_STATS 모든 dictionary(sys, system, components

schema)

RESTORE_FIXED_OBJECTS_ 모든 fixed table

RESTORE_SCHEMA_STATS 특정 schema의 모든 table

RESTORE_SYSTEM_STATS system(cpu, io) 정보

RESTORE_TABLE_STATS 특정 table

다음은 위 procedure중에서 간단한 작업을 진행해 보자. 먼저 현재 유효한 old

version통계가 어디까지 존재하는지 확인해 보자.

SYSTEM> select dbms_stats.get_stats_history_availability

2 from dual;

GET_STATS_HISTORY_AVAILABILITY


표 7-5

수집된 통계의 Restore Procedure List


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

18-JUL-05 12.01.36.789356000 PM +09:00

위 결과로 보아 현재 restore가 가능한 old version 통계자료는 2005년 7월 18일까지

이다. 따라서 이 날짜보다 더 오래된 통계자료는 restore가 불가하다.

다음은 특정 table의 old version을 확인하여 이를 restore하는 예이다.

SYSTEM> select stats_update_time from dba_tab_stats_history

2 where owner = 'SCOTT' and table_name = 'X_EMP'

3 order by 1;

STATS_UPDATE_TIME

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

03-AUG-05 10.00.08.190609 PM +09:00

04-AUG-05 10.00.29.169742 PM +09:00

05-AUG-05 10.01.36.383087 PM +09:00

08-AUG-05 10.01.21.494808 PM +09:00

18-AUG-05 04.30.06.020435 PM +09:00

18-AUG-05 04.33.10.025454 PM +09:00

6 rows selected.

SYSTEM> exec dbms_stats.restore_table_stats(-

> 'SCOTT', 'EMP', '03-AUG-05 10.00.08.190609 PM +09:00');


위의 예는 scott의 x_emp table의 통계정보를 현재 보존하고 있는 가장 오래된 old

version 통계정보인 2005년 8월 3일 오후 10시 시점의 자료로 restore한 것이다.

마지막으로 더 이상 필요가 없다고 판단된 old version의 통계정보를 삭제하는 작업을

해보자. 위의 예에서 여러분이 현재보다 2주일 전 통계는 모두 의미가 없어서

삭제하겠다면 다음과 같이 할 수 있다.

SYSTEM> exec dbms_stats.purge_stats(systimestamp - interval '14' day);




SYSTEM> select stats_update_time from dba_tab_stats_history

2 where owner = 'SCOTT' and table_name = 'X_EMP'

3 order by 1;

STATS_UPDATE_TIME

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

04-AUG-05 10.00.29.169742 PM +09:00

05-AUG-05 10.01.36.383087 PM +09:00

08-AUG-05 10.01.21.494808 PM +09:00

18-AUG-05 04.30.06.020435 PM +09:00

18-AUG-05 04.33.10.025454 PM +09:00

7.3.5.통계수집 자동화 Limit

Oracle10g가 자랑하는 통계수집의 자동화도 부분적으로 해당되지 않는 것들이 있다.

다음의 case들은 DBA가 직접 통계자료를 수집해야 한다.

1. 대량의 data load작업을(bulk operation) 수행한 후에는 DBA가 작업 후 바로

통계작업을 실시해야 가장 최신의 통계정보를 유지할 수 있다.

2. external tables은 통계정보 자동화의 대상이 아니다.

3. system 통계를 수집하는 것은 직접 수행해야 한다.

SQL> exec dbms_stats.gather_system_stats;

4. fixed objects에 대한 통계수집도 자동화되지 않는다. (v$view와 같은 dynamic

performance view는 자동화되지 않는다)



OCP point

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

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

1. automatic 통계수집에서 사용하는 두 가지 window와 그 내용

2. 특정 table만을 대상으로 불필요한 통계작업을 제거하는 방법

3. 통계정보 history 보관일자 변경 procedure 사용방법



7.4. Undo & Checkpoint 자동 Tuning

7.4.1.Undo Management

7.4.1.1. Undo Retention 자동 관리Oracle10g는 default로 undo 생성 비율과 가장 긴 query 시간에 대한 통계를 통해

undo retention 자동 tuning을 수행한다. 이 말은 undo retention에 대한 자동

tuning이 매 30초마다 이루어 지는 query duration정보를 수집하여 가장 긴

query(longest running query)를 위해 이루어진다는 뜻이다.

물론, undo space가 부족하게 되면 점점 그 retention이 줄어들고 가장 오래된 undo

extents가 다시 사용된다.

Oracle10g에서 undo retention을 위해 설정한 undo_retention의 값은 자동으로

tuning하는 undo retention의 최소 값으로 인식된다. 즉, 스스로 더 긴 시간을

retention으로 삶을 수도 있고 더 줄어들 수도 있지만 최소 값은 이 parameter에

설정된 값이 된다는 뜻이다. 따라서 undo_retention을 설정하지 않거나 0으로 하게

되면 default로 900초가 설정됨으로 undo retention이 줄어들 수 있는 최소 값은

직접 설정한 undo_retention 값 또는 15분, 둘 중의 하나가 된다.

7.4.1.2. Rollback Time 추측DBA가 곧 잘 접수하는 문의 중에는 특정 사용자가 transaction을 수행하고 필요에

의해 또는 실수로 rollback을 발생 시키고 언제 끝날지 모르겠다고 알려달라는 경우다.

이런 질문에 답을 하기 위해 DBA는 해당 transaction을 찾아 다음의 query를 많이

이용해 왔다.

SQL> select used_urec from v$transaction where addr = (select taddr from

v$session where….);

즉, 위 query를 특정 시간 term을 두고 반복 수행하여 얼마나 더 기다려야 하는가를

예측하는 방식이었다.

Oracle10g는 이와 같은 상황을 보다 더 간단히 처리할 수 있게 되었다. 대부분의 DBA

가 알고 있는 view “v$session_longops”가 그것이다. 여러분은 이제 문제가 된

session의 sid만 알고 있으면 된다. Oracle10g는 6초 이상이 걸리는 rollback 작업은

이 view의 record로 추가를 해서 사용자에게 보여주기 때문이다. 이제부터 다음의

query를 사용해 보라.

SQL> select time_remaining from v$session_longops where sid = ….



또한 이 view를 이용하여 보다 쉽게 rollback 중인 SQL문을 추출할 수도 있다. 다음의

query는 이 view의 sql_id column을 사용하는 예이다.

SQL> select sql_text from v$sql where sql_id = (select sql_id from

v$session_longops where....);

7.4.2.Checkpoint

Oracle9i에서 소개된 initial parameter “fast_start_mttr_target”은 crash

recovery time을 제어하기 위해 설정하는 시간이었고 이 값은 checkpoint에 영향을

주어 dirty buffers를 write out하는데 영향을 주었다. Oracle10g의 checkpoint

자동 tuning이란 개념은 이 parameter의 설정에 따라 자동 tuning여부가 결정된다는

것을 말한다.

다음은 version별 checkpoint관련 parameter를 설정(set)하는 것과 자동화를 위해

설정하지 않는 경우를 구분한 것이다.

구 분 Oracle8i Oracle9i Oracle10g

SET

log_checkpoint_inter

val

fast_start_mttr_targe

t fast_start_mttr_targe

t

(0 보다 크거나 unset)

log_checkpoint_time

outlog_checkpoint_time

outfast_start_io_target

UNSET 없음


val

log_checkpoint_time

out

fast_start_io_target


val

fast_start_io_target

1. oracle8i는 DBA가 적절한 값을 설정하여 checkpoint를 조절했다.

2. oracle9i는 fast_start_mttr_target을 통해 checkpoint조절에 도움을 받을 수

있다.

3. oracle10g는 fast_start_mttr_target을 통해 아무런 설정 없이 자동화된

checkpoint tuning을 해준다. 이 parameter를 설정하지 않거나 0보다 큰 값으로

하면(나머지 관련 3개 parameters를 설정하지 않거나 0으로(disable)하라) 자동

tuning이 enable 된다. 단, 이 fast_start_mttr_target의 값을 낮게 설정하면

transaction당 DBWR이 write하는 평균회수가 많아지고 높게 설정하면(또는 설정을

하지 않으면) 반대로 그 회수가 적어진다. 여러분이 자동 tuning을 원하지 않는다면 이


표 7-6

Checkpoint 설정과 Parameter


parameter의 값을 명시적으로 0으로 설정하면 된다.

현재의 database에서 checkpoint tuning을 자동화하기 위해 parameter를 조정한

후 다시 database를 start해보자.

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

…..

…..

…...

……

#fast_start_io_target = 1600

#log_checkpoint_timeout = 1800

#log_checkpoint_interval = 0

#fast_start_mttr_target = 120

…..

…..

…..

…..

~

~

~

~

~

:wq!

[NEWSVC]LIRACLE:/app/oracle/admin/NEWSVC/pfile> cd

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


SQL*Plus: Release 10.1.0.4.0 - Production on Fri Aug 19 14:11:41 2005


Connected to:






Database closed.



SYS> startup







Database mounted.

Database opened.

SYS>

관련 parameter를 모두 “unset”으로 하여 checkpoint의 자동 tuning을 enable

하였다.

7.4.3.Fast Ramp-Up

Oracle10g가 undo segment와 관련하여 소개하는 것 중에서 fast ramp-up time

이란 것이 있다. 이는 oracle9i에서 소개된 rollback segment의 자동화 mode인

AUM(automatic undo management)을 사용하는 경우(AUM mode로 initial

parameter 설정을 하게 되면) undo tablespace만 지정하는 것으로 거의 모든

rollback segment관리가 끝나게 된다. 따라서 최초 instance가 start되거나 undo

tablespace를 변경할 때에 oracle은 자동으로 적절한 수의 undo segments를

online하는 작업을 수행하게 된다.

Oracle은 이 시간을 ramp-up time이라고 부르며 oracle10g에서 이 시간이 매우

짧아졌다는 것이다. 그 이유는 앞서 이야기한 자동으로 수집되는 통계 data를 이용하여

oracle 스스로 얼마나 많은 수의 undo segments를 online할 것인지 바로 결정할 수

있기 때문이다.

다시 정의하면 자동으로 수집된 통계 data들이 다음에 이야기 하는 AWR로 저장이

되고 oracle10g는 이 AWR을 통해 instance startup 혹은 undo tablespace변경 시



online할 undo segments의 수를 바로 결정할 수 있다.



참조

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

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

undo retention : o9i 80p, o9i 302p

fast_start_mttr_target : o9i 76p

AUM : o9i 302p



7.5. AWR (Automatic Workload Repository)

7.5.1.AWR 개요

7.5.1.1. AWR의 구조AWR은 앞서 ADDM에서 언급했지만 자가진단 database를 구현하기 위해 각종

통계를 모으고 관리하는 기반구조를 의미한다. Oracle10g가 취합한 통계들은 SGA에

저장되어(memory version) v$view(dynamic performance view)로 접근할 수

있으며 이 통계들은 주기적으로 oracle10g new background process인 MMON에

의해 disk로 이동된다.

다시 정리하면 memory version 통계들이 향후 historical 분석에 사용될 수 있도록

MMON에 의해 snapshot형태로 AWR로 이동된다. 아래 그림은 그 구조를 보여준다.

7.5.1.2. 통계 Access

1. dynamic performance view(v$view) :

View Description

v$sys(ses)stat database system(session) 통계

v$segment_statistics segment level 통계

v$osstat OS 통계

v$sys_time_model system(OS) 통계의 누적시간


그림 7-14

AWR 연결구조

표 7-7

통계와 Views


v$sysmetric_history system의 모든 metric value정보

v$system_wait_class wait class의 전체 wait 시간(commit, idle, system I/O

등)

v$active_session_hist

ory

초당 1회 sampling한 database session의 action 정보

CF. OS 통계 : 다음은 oracle이 이야기하는 OS 통계의 설명을 그대로 보여준다.

통계 Description

NUM_CPUS Number of CPUs or processors available

IDLE_TICKS Number of hundredths of a second that a processor

has been idle, totalled over all processors

BUSY_TICKS Number of hundredths of a second that a processor

has been busy executing user or kernel code, totalled

over all processors

USER_TICKS Number of hundredths of a second that a processor

has been busy executing user code, totalled over all

processors

SYS_TICKS Number of hundredths of a second that a processor

has been busy executing kernel code, totalled over all

processors

IOWAIT_TICKS Number of hundredths of a second that a processor

has been waiting for I/O to complete, totalled over all

processors

NICE_TICKS Number of hundredths of a second that a processor

has been busy executing low-priority user code,

totalled over all processors

AVG_IDLE_TICKS Number of hundredths of a second that a processor

has been idle, averaged over all processors

AVG_BUSY_TICKS Number of hundredths of a second that a processor

has been busy executing user or kernel code,

averaged over all processors

AVG_USER_TICKS Number of hundredths of a second that a processor

has been busy executing user code, averaged over all

processors

AVG_SYS_TICKS Number of hundredths of a second that a processor


표 7-8

OS 통계와 의미


has been busy executing kernel code, averaged over

all processors

AVG_IOWAIT_TICKS Number of hundredths of a second that a processor

has been waiting for I/O to complete, averaged over

all processors

AVG_NICE_TICKS Number of hundredths of a second that a processor

has been busy executing low-priority user code,


OS_CPU_WAIT_TIME Total number of hundredths of a second that

processes have been in a ready state, waiting to be

selected by the operating system scheduler to run

RSRC_MGR_CPU_W

AIT_TIME

Total number of hundredths of a second that Oracle

processes have been in a ready state, waiting for CPU

to be available for their consumer group in the

currently active resource plan

IN_BYTES Total number of bytes that have been paged in

OUT_BYTES Total number of bytes that have been paged out

FS_IN_BYTES Total number of bytes that have been paged in due to

the file system

FS_OUT_BYTES Total number of bytes that have been paged out due

to the file system

AVG_IN_BYTES Number of bytes that have been paged in, averaged

over all processors

AVG_OUT_BYTES Total number of bytes that have been paged out,


AVG_FS_IN_BYTES Total number of bytes that have been paged in due to

the file system, averaged over all processors

AVG_FS_OUT_BYTES Total number of bytes that have been paged out due

to the file system, averaged over all processors

2. data dictionary view :

Description View Name

Advisor 결과를 query dba_advisor_actions

dba_advisor_commands

dba_advisor_definitions


표 7-9

Advisor 관련 View List


dba_advisor_findings

dba_advisor_journal

dba_advisor_log

dba_advisor_object_types

dba_advisor_objects

dba_advisor_parameters

dba_advisor_rationale

dba_advisor_recommendations

dba_advisor_sqla_rec_sum

dba_advisor_sqla_wk_map

dba_advisor_sqla_wk_stmts

dba_advisor_sqlw_journal

dba_advisor_sqlw_parameters

dba_advisor_sqlw_stmts

dba_advisor_sqlw_sum

dba_advisor_sqlw_tables

dba_advisor_sqlw_templates

dba_advisor_tasks

dba_advisor_templates

dba_advisor_usage

통계 history를 query dba_hist_active_sess_history

dba_hist_baseline

dba_hist_bg_event_summary

dba_hist_buffer_pool_stat

dba_hist_cr_block_server

dba_hist_current_block_server

dba_hist_database_instance

dba_hist_datafile

dba_hist_db_cache_advice

dba_hist_dlm_misc

dba_hist_enqueue_stat

dba_hist_event_name

dba_hist_filemetric_history

dba_hist_filestatxs

dba_hist_instance_recovery



dba_hist_java_pool_advice

dba_hist_latch

dba_hist_latch_children

dba_hist_latch_misses_summary

dba_hist_latch_name

dba_hist_latch_parent

dba_hist_librarycache

dba_hist_log

dba_hist_metric_name

dba_hist_mttr_target_advice

dba_hist_optimizer_env

dba_hist_osstat

dba_hist_osstat_name

dba_hist_parameter

dba_hist_parameter_name

dba_hist_pga_target_advice

dba_hist_pgastat

dba_hist_resource_limit

dba_hist_rollstat

dba_hist_rowcache_summary

dba_hist_seg_stat

dba_hist_seg_stat_obj

dba_hist_service_name

dba_hist_service_stat

dba_hist_service_wait_class

dba_hist_sessmetric_history

dba_hist_sga

dba_hist_sgastat

dba_hist_shared_pool_advice

dba_hist_snap_error

dba_hist_snapshot

dba_hist_sql_plan

dba_hist_sql_summary

dba_hist_sql_workarea_hstgrm

dba_hist_sqlbind



dba_hist_sqlstat

dba_hist_sqltext

dba_hist_stat_name

dba_hist_sys_time_model

dba_hist_sysmetric_history

dba_hist_sysmetric_summ

Database feature 사용 통계 dba_feature_usage_statistics

각 종 database의 maximum value dba_high_water_mark_statistics

Table 통계의 수정 history dba_tab_stats_history

CF. high water mark : database 통계의 maximum value와 의미한다. 다음은 그

값이 의미하는 바를 oracle 설명 그대로 기술한 것이다.

Name Description

USER_TABLES Number of User Tables

SEGMENT_SIZE Size of Largest Segment (Bytes)

PART_TABLES Maximum Number of Partitions belonging to an User

Table

PART_INDEXES Maximum Number of Partitions belonging to an User

Index

USER_INDEXES Number of User Indexes

SESSIONS Maximum Number of Concurrent Sessions seen in the

database

DB_SIZE Maximum Size of the Database (Bytes)

DATAFILES Maximum Number of Datafiles

TABLESPACES Maximum Number of Tablespaces

CPU_COUNT Maximum Number of CPUs

QUERY_LENGTH Maximum Query Length

SERVICES Maximum Number of Services

CF. database feature : database feature의 사용 통계를 보여주는 data dictionary

view인 “dba_feature_usage_statistics”에서 그 feature의 이름이 의미하는 바를

oracle의 설명 그대로 살펴보자.

Features Description

Advanced Replication Advanced Replication has been enabled.

Advanced Security External Global users are configured.


표 7-10

HWM 종류와 의미

표 7-11

Database Feature 와 의미


Audit Options Audit options in use.

Automatic Database

Diagnostic Monitor

A task for the Automatic Database Diagnostic

Monitor has been executed.

Automatic Segment

Space Management

(system)

Extents of locally managed tablespaces are

managed automatically by Oracle.

Automatic Segment

Space Management

(user)

Extents of locally managed user tablespaces are

managed automatically by Oracle.

Automatic SQL

Execution Memory

Sizing of work areas for all dedicated sessions

(PGA) is automatic.

Automatic Storage

Manager

Automatic Storage Management has been enabled

Automatic Undo

Management

Oracle automatically manages undo data using an

UNDO tablespace.

Automatic Workload

Repository

A manual Automatic Workload Repository (AWR)

snapshot was taken in the last sample period.

Change-Aware

Incremental Backup

Track blocks that have changed in the database.

Client Identifier Application User Proxy Authentication: Client

Identifier is used at this specific time.

Data Guard Data Guard, a set of services, is being used to

create, maintain, manage, and monitor one or

more standby databases.

Data Guard Broker Data Guard Broker, the framework that handles

the creation maintenance, and monitoring of Data

Guard, is being used

Data Mining Oracle Data Mining option is being used.

Dynamic SGA The Oracle SGA has been dynamically resized

through an ALTER SYSTEM SET statement.

File Mapping File Mapping, the mechanism that shows a

complete mapping of a file to logical volumes and

physical devices, is being used.

Flashback Database Flashback Database, a rewind button for the

database, is enabled



Internode Parallel

Execution

Internode Parallel Execution is being used.

Label Security Oracle Label Security, that enables label-based

access control Oracle applications, is being used.

Locally Managed

Tablespaces (system)

There exists tablespaces that are locally managed

in the database.

Locally Managed

Tablespaces (user)

There exists user tablespaces that are locally

managed in the database.

Messaging Gateway Messaging Gateway, that enables communication

between non-Oracle messaging systems and

Advanced Queuing (AQ), link configured.

MTTR Advisor Mean Time to Recover Advisor is enabled.

Multiple Block Sizes Multiple Block Sizes are being used with this

database.

OLAP - Analytic

Workspaces

OLAP the analytic workspaces stored in the

database.

OLAP - Cubes OLAP number of cubes in the OLAP catalog that

are fully mapped and accessible by the OLAP API.

Oracle Managed Files Database files are being managed by Oracle.

Parallel SQL DDL

Execution

Parallel SQL DDL Execution is being used.

Parallel SQL DML

Execution

Parallel SQL DML Execution is being used.

Parallel SQL Query

Execution

Parallel SQL Query Execution is being used.

Partitioning (system) Oracle Partitioning option is being used - there is

at least one partitioned object created.

Partitioning (user) Oracle Partitioning option is being used - there is

at least one user partitioned object created.

PL/SQL Native

Compilation

PL/SQL Native Compilation is being used - there is

at least one natively compiled PL/SQL library unit

in the database.

Protection Mode -

Maximum Availability

Data Guard configuration data protection mode is

Maximum Availability.

Protection Mode - Data Guard configuration data protection mode is



Maximum Performance Maximum Performance.

Protection Mode -

Maximum Protection


Maximum Protection.

Protection Mode -

Unprotected


Unprotected.

Real Application

Clusters (RAC)

Real Application Clusters (RAC) is configured.

Recovery Area The recovery area is configured.

Recovery Manager

(RMAN)

Recovery Manager (RMAN) is being used to backup

the database.

RMAN - Disk Backup Recovery Manager (RMAN) is being used to backup

the database to disk.

RMAN - Tape Backup Recovery Manager (RMAN) is being used to backup

the database to tape.

Resource Manager Oracle Database Resource Manager is being used

to control database resources.

Segment Advisor A task for Segment Advisor has been executed.

Server Parameter File The server parameter file (SPFILE) was used to

startup the database.

SGA/Memory Advisor SGA/Memory Advisor has been used.

Shared Server The database is configured as Shared Server,

where the server process can service multiple user

processes.

Spatial There is at least one usage of the Oracle Spatial

index metadata table.

SQL Access Advisor A task for SQL Access Advisor has been executed.

SQL Tuning Advisor SQL Tuning Advisor has been used.

SQL Tuning Set A SQL Tuning Set has been created in the

database.

Standby Archival -

LGWR

Data Guard configuration: Remote archival is done

by LGWR.

Standby Archival -

ARCH

Data Guard configuration: Remote archival is done

by ARCH.

Standby Transmission Standby database: Network transmission mode

was chosen for a standby destination.



Streams (system) Oracle Streams has been configured

Streams (user) Users have configured Oracle Streams

Tablespace Advisor Tablespace Advisor has been used.

Transparent Gateway Heterogeneous Connectivity, access to a non-

Oracle system, has been configured.

Undo Advisor Undo Advisor has been used.

Virtual Private

Database (VPD)

Virtual Private Database (VPD) policies are being

used.

7.5.1.3. 기본통계(Base Statistics)와 측정(Metrics)

Database의 상태를 측정 하기 위해서는 기준점이 필요하다. 즉, 기준과 비교하여

현시점의 차이를 확인해야 정확한 측정이 가능하기 때문이다. 예를 들어 현 시점의

logical reads의 수가 1만이라 할지라도 그 비교기준의 값이 9만 9천이면 1만이라는

수치는 크지 않겠지만 그 기준이 1천 이었다면 현 시점의 1만은 매우 큰 값이 될 수도

있다.

Database가 지금 startup 되었다면 현 시점의 통계들은 기본 값 즉, base statistics

가 되고 시간이 흐른 후 이 값을 기준으로 두 번째 통계가 수립되었다면 이 값들은

metrics가 된다. 따라서 매 60분마다 추출되는 통계를 기준으로 볼 때 마지막

시점에서의 통계들의 평균 값은 metrics가 된다.

이런 metrics를 유지하는 것은 분석에 큰 도움이 된다. Database에 발생하는 특정

활동의 변화비율을 확인하는 것은 올바른 분석을 위해 꼭 필요한 사항이다. 이 정보들

즉, metrics는 MMON에 의해 매 분마다 update된다.

위 설명만 들으면 좀 헛갈릴지도 모르겠다. 하지만 다음에 설명하는 metric의 access

와 관련한 view들의 설명을 보고 확인을 해보면 이 내용들이 매우 유용한 정보이며

또한 모두가 다 익숙한 주요 통계 값들의 시간대별 metrics라는 것을 알 수 있다.

1. dynamic performance view(v$view) :

View Description

v$metricname metric이름과 id를 mapping

v$eventmetric 최근 60초간 발생한 wait event metric

v$filemetric datafile별 최근 10분간의 metric

v$filemetric_history 마지막 1시간 동안의 v$filemetric 정보

v$servicemetric 최근 60초간 발생한 service의 call수에 대한 metric

v$servicemetric_histor 마지막 1시간 동안의 v$servicemetric정보


표 7-12

Metric 관련 v$View List


y

v$sessmetric 최근 15초간 발생한 모든 session의 metric(memory,

parse, read)

v$sysmetric 최근 발생한 system-wide metric(system 전체에

대해여 metric별) (long 60초, short 15초간의 두

정보를 모두 보여준다)

v$sysmetric_history 60초 interval의 system metric통계의 1시간 누적정보,

15초 interval의 one-interval(대략 최근 60초 interval

정보의 세부 15초 interval) 누적정보

v$sysmetric_summary 60초 interval의 system metric통계의 1시간 총합(

표준과 평균을 포함)

v$waitclassmetric 최근 60초간의 wait class별 metric

v$waitclassmetric_hist

ory

지난 1시간 동안 v$waitclassmetric의 누적정보

2. data dictionary view :

View Description

dba_hist_metric_name database id별 v$metricname의 snapshot

dba_hist_filemetric_histor

y

workload repository에 취합된 file metric의 history

dba_hist_sessmetric_histo

ry

중요 session metric의 history

dba_hist_sysmetric_histor

y

v$sysmetric_history의 sanpshot을 가지고 있으며

현재 database에 존재하는(저장되어있는) 전체

system-wide metric

dba_hist_sysmetric_summ

ary

v$sysmetric_summary의 snapshot을 가지고

있으며 현재 database에 존재하는(저장되어있는)

전체 system-wide summary metric

CF. MMON이 제공하는 또 다른 정보로 database features에 대한 통계자료가 있다.

View Description

dba_feature_usage_statistic

s

oracle10g가 제공하는 각종 features들(AQ, VPD,

Replication 등)의 사용 통계 (얼마나 자주

사용되는지 확인할 수 있다)

dba_high_water_mark_statis database resource(최대 sessions, tables 수 등)


표 7-13

Metric관련 dba View List

표 7-14

Database Feature 통계


tics 의 HWM(High-Water Mark)정보

7.5.1.4. Repository와 Snapshot

여기서 말하는 repository란 AWR에서 분석을 위한 통계 data를 제공하는 작업부하

(workload) 통계 저장소를 말한다. 이 통계 data들은 모두 sys 소유이며 oracle10g의

new tablespace “SYSAUX”에 저장된다. 따라서 workload repository는 sysaux

tablespace에 존재하는 매우 중요한 data들 중 하나이다.

여기서 말하는 snapshot이란 특정 시점에 capture한 성능통계의 집합을 말한다.

당연히 그 시간대별 통계의 변화비율을 분석하는데 주로 사용되며 각각의 snapshot은

AWR에서 unique한 snap_id(snapshot sequence number)를 갖는다.

다음은 이 repository에 저장되는 snapshot의 속성을 정리한 것이다.

1. 몇 차례 언급이 되었지만 default는 매 60분마다 snapshot이 생성되지만 꼭

필요하다면 snapshot의 interval을 조정함으로써 이를 조정할 수는 있다. Oracle의

내부 권고자(internal advisor)들은 모두 이 data들을 근간으로 하고 있다.

2. RAC환경에서의 snapshot은 각 node별로 동일한 snap_id와 각각의 instance id

를 가지고 저장되며 대략적으로 동일한 시간에 각 node에서 snapshot이 capture된다.

3. 필요하다면 automatic snapshot이 아니라 여러분이 원하는 시점에 manual하게

snapshot을 capture할 수도 있다. 이렇게 취합된 snapshot도 system이 생성하는

automatic snapshot과 동일하게 지원된다. 보통 이런 방식은 system의 automatic

schedule과 다른 두 시점간의 비교분석을 위해 수행하게 된다.

4. repository에 저장되는 snapshot data들은 retention 주기(default 7일)에 따라

자동으로 삭제되는데 만일 이 data가 저장되는 tablespace sysaux에 공간이

부족하게 되면 먼저 가장 오래된 snapshot set을 reuse(overwrite)한 후 DBA에게

alert message를 보내 sysaux tablespace의 공간부족을 알린다.

5. “snapshot too old” error나 “replication”에서 말하는 snapshot, 그리고

여기서의 snapshot은 그 내용과 사용처에 있어서 다른 것이니 헛갈리지 말자.

6. 이미 앞서 언급이 되었던 initial parameter “statistics_level”의 값이 반드시

“typical”, “all”중의 하나로 설정이 되어 있어야 하며 “basic”으로 설정하면 snapshot

은 생성되지 않는다.

CF. 매우 중요한 “statistics_level” parameter를 다시 정리하면 다음과 같다.

1. BASIC : AWR 통계와 metrics을 취합하지 않는다.

2. TYPICAL : database의 action을 monitor하기 위해 필요한 대부분의 중요한

통계를 취합한다.



3. ALL : 모든 사용 가능한 통계를 취합한다. (SQL Plan, OS통계 등)

CF. 이전 version에서 사용하던 oracle의 statspack은 oracle10g의 workload

repository를 사용할 수 없고 또한 자동으로 migration을 해주지도 않는다. 따라서

필요하다면 statspack을 이용해 작성한 application code들을 직접 수정해주어야

한다.

7.5.2.AWR Control

7.5.2.1. Snapshot Schedule 조정 (Manually)

먼저 앞서 설명한 automatic snapshot의 주기를 확인하는 방법과 조정하는

command를 확인해보자.

SQL> exec dbms_workload_repository.modify_snapshot_settings(interval =>

30, retention => 10*24*60);

위의 예는 snapshot 주기를 30분단위로 하고 그 결과를 10일간 유지하겠다는 뜻이다.

각 argument의 의미를 자세히 보면 다음과 같다.

1. interval : 분단위로 표시되며 최소 10분에서 최대 1년을 지정한다. 만일 0을

지정하면 최대 값인 1년으로 설정되며(이는 사실상 snapshot을 disable하는 것과

마찬가지라 볼 수 있다) NULL이 지정되면 현재의 값을 유지한다. (default 1시간)

2. retention : 역시 분단위로 지정되며 최소 1일에서 최대 100년까지 지정이

가능하다. 만일 0을 지정하면 최대 값인 100년으로 설정되고(이는 사실상 지우지

않겠다는 즉, automatic purge(삭제)를 disable하겠다는 의미가 될 것이다) NULL이

지정되면 이전 값이 유지된다. (default 7일)

CF. 앞서 언급 했지만 sysaux tablespace가 부족하면 위 설정보다 우선하여 가장

오래된 snapshot set의 공간을 reuse한다.

위의 예를 실제로 수행해서 그 결과를 확인해 보자.

SYSTEM> col snap_interval for a20

SYSTEM> col retention for a20

SYSTEM> select snap_interval, retention

2 from dba_hist_wr_control;

SNAP_INTERVAL RETENTION

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



+00000 01:00:00.0 +00007 00:00:00.0

SYSTEM> exec dbms_workload_repository.modify_snapshot_settings(-

> interval => 30, retention => 10*24*60);





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

+00000 00:30:00.0 +00010 00:00:00.0

위 결과로 볼 때 system의 기본 값이 1시간 주기의 snapshot을 7일 보관하는 것으로

설정되어 있고 이를 수정하여 30분 주기의 snapshot을 10일 보관하는 것으로 수정이

되는 것을 알 수 있다.

원래의 system 기본 값으로 다시 수정해 보자.


> interval => 60, retention => 7*24*60);





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

+00000 01:00:00.0 +00007 00:00:00.0

CF. 앞서 argument를 설명할 때 0을 지정하는 경우 각각 최대 값인 interval 1년과

retention 100년이 설정된다고 했다. 그러나 실제로 테스트를 해보면 둘 다 110년이

지정되는 것을 볼 수 있다. 그다지 중요하지는 않지만 oracle문서의 설명과 실제결과가

틀리게 나왔다는 것을 알 필요가 있다고 생각되어 그 결과를 보여준다. (굳이 테스트할



필요는 없으니 아래 예를 보고 넘어가도 좋다)


> interval => 0, retention => 0);





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

+40150 00:00:00.0 +40150 00:00:00.0

SYSTEM> select 40150/365 from dual;

40150/365

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

110

7.5.2.2. Snapshot Schedule 조정 (Using em)

위 작업을 em을 통해 하려면 다음과 같이하면 된다. 다음은 em의 database control

에서 “관리 자동작업로드저장소”의 화면이다. 여기서 snapshot에 대한 편집이

가능하다.



위에서 편집을 선택하면 snapshot의 생성 및 보관주기를 다음과 같은 화면에서 수정할

수 있다. 위 그림에서 “보관된 스냅샷 집합”은 다음에 설명하는 baseline을 의미한다.

아직 baseline이 없는 database라면 여기서 나타나지 않을 것이다. 이 부분은 추후

설명되는 “snapshot baseline”의 em 부분에서 다시 확인하도록 한다.


그림 7-15

AWR snapshot 상태화면


원하는 보존기간과 수집간격을 설정한 후 위 화면의 맨 우측에(지면상 여기서는 보이지

않지만) 있는 확인 button을 click하면 된다.

7.5.2.3. Snapshot Baseline (Manually)

Database를 운영하다 보면 DBA들은 매우 중요한 시간대(특정 batch process 시점,

OLTP peak 시점 등)에 주로 관심을 갖게 된다. 즉, 같은 통계 값이라도 또는 같은

통계수치의 변화 비율이라 할 지라도 각 시간대에 따라 그 중요도가 달라질 수 있다는

말이다. 이런 경우 특정 시점을 하나의 분석 data로 만들어 다른 시점의 동 작업에 대한

분석 data를 비교하는 것은 database tuning 전, 후의 시스템 변화를 확인하는데

있어서 매우 중요한 작업이 된다. 이렇게 특정 시점의 분석 data에 대하여 이름을

붙이고 관리하는 것을 baseline이라 한다.

여러분이 baseline을 만들면 지정한 baseline 이름(동시에 system이 만들어주는 id

값)을 가지고 각 baseline이 구분된다. 이렇게 지정된 baseline에 포함되는 snapshot

data는 baseline이 drop될 때까지 계속 유지된다. 따라서 baseline은 매우 중요한

시점의 통계 data들을 계속 유지함으로써 차후에도 비교자료로 사용하겠다는 숨은


그림 7-16

AWR snapshot 편집화면


뜻이 있다.

다음은 특정 시점의 snapshot id를 가지고 baseline을 만들어보는 과정이다.

시나리오는 8월 16일 오후 1시부터 6시까지 peak time의 baseline을 만들어 향후

비교자료로 삼겠다는 것이다. 먼저 현재 만들어진 baseline이 있는가를

dba_hist_baseline를 통해 확인하고 dba_hist_snapshot로부터 적절한 snapshot id

를 check한 후 이를 가지고 baseline을 만들자.

SYSTEM> select * from dba_hist_baseline;

no rows selected

SYSTEM> col bgtime for a30

SYSTEM> select snap_id, begin_interval_time bgtime


3 where to_char(begin_interval_time, 'YYYYMMDD') = '20050816';

SNAP_ID BGTIME

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

1278 16-AUG-05 05.00.49.069 PM

1274 16-AUG-05 01.00.32.490 PM

1273 16-AUG-05 12.00.54.227 PM

1275 16-AUG-05 02.01.00.687 PM

1276 16-AUG-05 03.00.36.807 PM

1279 16-AUG-05 06.00.22.207 PM

1280 16-AUG-05 07.01.01.327 PM

1281 16-AUG-05 08.00.37.447 PM

1283 16-AUG-05 10.00.46.944 PM

1284 16-AUG-05 11.00.17.529 PM

1277 16-AUG-05 04.00.09.937 PM

1282 16-AUG-05 09.00.13.567 PM

12 rows selected.

SYSTEM> exec dbms_workload_repository.create_baseline(-

> 1274, 1279, '1st_oltp_baseline');




SYSTEM> col baseline_name for a20

SYSTEM> select baseline_id, baseline_name, start_snap_id, end_snap_id

2 from dba_hist_baseline;

BASELINE_ID BASELINE_NAME START_SNAP_ID END_SNAP_ID

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

1 1st_oltp_baseline 1274 1279

7.5.2.4. Snapshot Baseline (Using em)

위 작업을 em을 통해 control하는 것은 두 가지 방식이 있다. 먼저 앞서 이미 만들어진

baseline을 확인하여 조정하는 방법을 보자. 앞서 보았던 작업로드저장소의 그림을

다시 확인해 보자.


그림 7-15

AWR snapshot 상태화면


위 그림에서 “보관된 스냅샷 집합”을 보면 앞서 만들었던 baseline의 baseline id가

나타나면 link가 되어있다.

이 link을 click하면 다음과 같은 화면으로 이동한다.

이 화면은 현재 존재하는 baseline의 목록을 보여주며 우측의 dropdown 메뉴를

선택하여 실행함으로써 drop을 하거나 향후 설명할 보고서를 작성하는 등의 작업을

진행할 수 있다.

위 화면에서 우측 상단의 “보관된 스냅샷 집합 생성”을 click하거나 또는 이 그림의 전

그림인 “작업로드저장소”의 하단에 있는 스냅샷에 link된 숫자를 선택하거나 또는 최초

em의 database control에서 “성능 스냅샷”의 화면을 선택하면 다음과 같은

화면으로 이동한다. 여기서 snapshot에 대한 다양한 편집이 가능하다.


그림 7-17

Snapshot과 Baseline 정보

그림 7-18

Snapshot

편집화면


우측의 dropdown 메뉴를 통해 다양한 작업을 할 수 있다. 현재 설명하고 있는

snapshot baseline을 만들기 위해서는 이 메뉴 중 “보관된 스냅샷 집합 생성”을

선택하고 좌측에서 시작 스냅샷을 선택한 후 우측의 실행 버튼을 click한다. (좌측

상단에서 시간 또는 일자를 선택하여 찾고자 하는 snapshot list를 추출할 수도 있다)

그러면 다음과 같이 종료 snapshot을 선택하는 화면에서 원하는 snapshot을 선택한

후 확인 버튼을 click하면 baseline이 만들어진다.

아래 그림은 최종 baseline이 생성된 화면이다.


그림 7-19

Baseline 생성화면


7.5.2.5. Other Snapshot Control

앞서 설명한 snapshot을 control하는 package는 다른 기능도 가지고 있다. 그

사용법을 소개한다.

1. function create_baseline : 앞서 설명한 procedure create_baseline은 동일한

형식의 function으로도 존재한다. 즉, number type의 return 변수를 지정하여

function으로서 create_baseline을 수행하면 system이 생성한 baseline id값이

return된다.

2. drop_baseline : 이 procedure는 지정한 baseline을 drop한다.

SQL> exec dbms_workload_repository.drop_baseline(‘baseline_name’,

TRUE);

두 번째 argument TRUE는 baseline을 drop함과 동시에(dba_hist_baseline에서

삭제) underlying snapshot 즉, baseline에 묶여 있는 snapshot을 같이 drop

하겠다는 의미이다. 그러나 FALSE를 지정하면(아무 값도 지정하지 않으면 default는

FALSE) baseline만 drop되고 관련 snapshot은 그대로 유지된다.

3. crate_snapshot : 앞서 언급했던 사용자가 원하는 시점에 snapshot을 capture

하기 위해 사용한다. Baseline과 마찬가지로 procedure와 function 모두 같이

존재하며 function으로 수행하면 새로 만들어진 snapshot id를 return한다.

SQL> exec dbms_workload_repository.create_snapshot;

위 작업을 수 행시 argument로 flush_level을 줄 수 있는데 default로 “TYPICAL”이

사용되고 다른 값으로 “ALL”을 지정할 수 있다.

4. drop_snapshot_range : 위 create snapshot의 반대 기능을 하는 procedure

이다. 특정 range의 snapshot id를 지정하여 그 범위의 snapshot을 drop하는 역할을

수행한다. 따라서 이 procedure에서 지정된 범위의 snapshot들은 작업이 끝나면

dba_hist_snapshot에서 볼 수 없다.

SQL> exec dbms_workload_repository. drop_snapshot_range(1001, 1009);


그림 7-20

Baseline 생성결과


5. awr_report_html, awr_report_text : 이 두 function은 html 또는 text 형식의

AWR report를 argument “dbid, instance_number, snapshot start id, snapshot

end id”의 값에 따라 table type으로 return해 준다. 따라서 이 function을 직접 call

하기 보다는 아래 AWR report에서 설명하는 oracle이 제공하는 script를 사용할 것을

추천한다.

CF. 위 작업들은 앞서 보여준 em의 snapshot 화면에서 dropdown으로 제공되는

메뉴를 선택함으로써 역시 em에서도 가능한 것들이다.

7.5.3.AWR Report & em

7.5.3.1. 직접 report 산출하기추천하는 방법은 아니지만 다음에 설명하는 oracle의 report 산출 script도 사실은 이

기능을 포함하고 있다. 여기서는 간단하게 그 사용법만을 확인한다. 아래의 예는 text

형태의 report를 만드는 과정이다. (html을 원한다면 awr_report_text 대신에

awr_report_html을 사용하라) 결과값이 너무 길기 때문에 일부만 보여주도록 한다.

SYSTEM> select dbid, baseline_id, start_snap_id, end_snap_id from

dba_hist_baseline;

DBID BASELINE_ID START_SNAP_ID END_SNAP_ID

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

3941507194 1 1274 1279

SYSTEM> select instance_number from v$instance;

INSTANCE_NUMBER

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

1

SYSTEM> select output from table(

2 dbms_workload_repository.awr_report_text(3941507194, 1, 1274,

1279));

OUTPUT

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

WORKLOAD REPOSITORY report for



DB Name DB Id Instance Inst Num Release Cluster Host

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

NEWSVC 3941507194 NEWSVC 1 10.1.0.4.0 NO LIRACLE

Snap Id Snap Time Sessions Curs/Sess

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

Begin Snap: 1274 16-Aug-05 14:01:00 17 9,137.6

End Snap: 1279 16-Aug-05 19:01:01 17 9,529.8

Elapsed: 300.01 (mins)

OUTPUT

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

DB Time: 0.50 (mins)

Cache Sizes (end)

~~~~~~~~~~~~~

Buffer Cache: 200M Std Block Size: 8K

Shared Pool Size: 144M Log Buffer: 5,120K

............

............

Instance Efficiency Percentages (Target 100%)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Buffer Nowait %: 99.99 Redo NoWait %: 100.00

Buffer Hit %: 99.71 In-memory Sort %: 100.00

Library Hit %: 99.19 Soft Parse %: 98.69

Execute to Parse %: 51.81 Latch Hit %: 100.00

Parse CPU to Parse Elapsd %: 80.00 % Non-Parse CPU: 87.23

OUTPUT

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



Shared Pool Statistics Begin End

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

Memory Usage %: 93.97 94.02

% SQL with executions>1: 89.47 89.76

% Memory for SQL w/exec>1: 88.38 88.92

Top 5 Timed Events

~~~~~~~~~~~~~~~~~~

% Total

Event Waits Time (s) DB Time Wait Class

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

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

OUTPUT

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

-------

log file parallel write 1,100 24 78.90 System I/O

CPU time 16 53.82

log file sync 334 11 37.47 Commit

control file parallel write 6,058 10 32.16 System I/O

process startup 223 7 22.04 Other

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

............

............

OUTPUT

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

workarea_size_policy AUTO

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

End of Report



1943 rows selected.

7.5.3.2. Report Script 사용하기앞서 ADDM에서 보았던 script처럼 AWR도 oracle이 제공하는 script를 사용하는

것이 일반적인 방식이다. 위치는 “$ORACLE_HOME/rdbms/admin”에 있으며 script

이름은 “awrrpt.sql”이다.

SYSTEM> @?/rdbms/admin/awrrpt

Current Instance

~~~~~~~~~~~~~~~~

DB Id DB Name Inst Num Instance

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

3941507194 NEWSVC 1 NEWSVC

Specify the Report Type

~~~~~~~~~~~~~~~~~~~~~~~

Would you like an HTML report, or a plain text report?

Enter 'html' for an HTML report, or 'text' for plain text

Defaults to 'html'

Enter value for report_type: html

바로 위에서 굵은 글자로 표시한 html이 첫 번째로 선택하는 report type이다.

여러분은 html과 text중 하나를 입력하면 된다. (default는 html이다)

Type Specified: html

Instances in this Workload Repository schema

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

DB Id Inst Num DB Name Instance Host

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

* 3941507194 1 NEWSVC NEWSVC LIRACLE



Using 3941507194 for database Id

Using 1 for instance number

Specify the number of days of snapshots to choose from

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~

Entering the number of days (n) will result in the most recent

(n) days of snapshots being listed. Pressing <return> without

specifying a number lists all completed snapshots.

Listing the last 3 days of Completed Snapshots

Snap

Instance DB Name Snap Id Snap Started Level

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

NEWSVC NEWSVC 1380 21 Aug 2005 00:00 1

1381 21 Aug 2005 01:01 1

1382 21 Aug 2005 02:00 1

……………

……………

……………

1440 23 Aug 2005 12:00 1

1441 23 Aug 2005 13:00 1

1442 23 Aug 2005 14:00 1

1443 23 Aug 2005 15:00 1


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



Enter value for begin_snap: 1440

Begin Snapshot Id specified: 1440

Enter value for end_snap: 1443

End Snapshot Id specified: 1443

바로 위의 굵은 snapshot id가 두 번째로 지정하는 분석을 위한 시작 snapshot id와

마지막 snapshot id를 지정한 부분이다.

Specify the Report Name

~~~~~~~~~~~~~~~~~~~~~~~

The default report file name is awrrpt_1_1440_1443.html. To use this name,

press <return> to continue, otherwise enter an alternative.

Enter value for report_name: awr_1440_1443.html

바로 위의 굵은 report 이름이 마지막으로 지정하는 AWR report 결과를 기록하는 file

의 이름이다.

이제 report가 주어진 이름으로 생성된다. 최종 결과를 확인한 후 생성된 file의 내용을

확인하는 과정이다.

Using the report name awr_1440_1443.html

<HTML><HEAD><TITLE>AWR Report</TITLE><style

type="text/css">body.awr {font:bold 10pt Arial,Helvetica,Geneva,sans-

serif;color:black

; background:White;}

pre.awr {font:8pt Courier;color:black; background:White;}h1.awr

{font:bold 20pt Arial,Helvetica,Geneva,sans-serif;color:#336699

;background-color:White;border-bottom:1px solid #cccc99;margin-top:0pt;

margin-bottom:0pt;padding:0px 0px 0px 0px;}

h2.awr {font:bold 18pt Arial,Helvetica,Geneva,sans-

serif;color:#336699;background-color:White;margin-top:4pt; margin-

bottom:0pt;

………….

………….



SYSTEM> !more awr_1440_1443.html

<HTML><HEAD><TITLE>AWR Report</TITLE><style

type="text/css">body.awr {font:bold 10pt Arial,Helvetica,Geneva,sans-

serif;color:black

; background:White;}

pre.awr {font:8pt Courier;color:black; background:White;}h1.awr

{font:bold 20pt Arial,Helvetica,Geneva,sans-serif;color:#336699

;background-color:White;bo

………….

………….

SYSTEM>

AWR report를 html로 만들었기 때문에 위에서처럼 그냥 text로는 알아볼 수가 없다.

이제 마지막으로 이 file을 download하여 web browser를 통해 확인한 결과를 보자.

(앞서 확인한 text와 그 결과가 동일하다)



CF. ADDM의 report는 지정된 snapshot 범위에서 발생한 문제를 해결하는 advisor용

report이고 AWR report는 지정된 snapshot 범위에서 분석한 database의 전반에

걸친 성능 결과보고서다.

7.5.3.3. Using em

다음은 em에서 report를 산출하는 방법이다. 사실 앞서 설명한 em의 화면을 눈 여겨

보았으면 벌써 알았겠지만 database control에서 “성능 스냅샷”의 화면에서


그림 7-21

AWR Report

그림 7-15


dropdown 메뉴 중 “보고서 보기”를 선택하면 된다.

아래 그림은 위에서 보고서 보기를 선택하여 start snapshot과 end snapshot을

지정한 후 최종 보고서 화면이다.


그림 7-23

Snapshot Report

그림 7-22

Snapshot Report 설정하기


여기서 우측 상단의 “ADDM 실행 보기” 버튼을 click하면 현재 선택된 시점의 ADDM

분석을 수행할 수 있다.

CF. 사실 em에서 제공하는 메뉴의 이름이나 리스트 등이 너무 무리하게 한글화 되어

있어서 지금 필자가 설명하고 있는 oracle 원래의 용어와 헛갈리기 쉽다. 바로

위에서의 “baseline”은 “보관된 스냅샷”으로 표현되고 있으며 위에서 보여주지는

않았지만 또 다른 메뉴인 “materialized view”는 “구체화된 뷰” 같이 표현되고 있다.

사실 필자도 원하는 메뉴를 한글에서 찾는 것이 쉽지 않았다. 여러분도 em을 사용할

때는 이런 용어들에 대하여 헛갈리지 않도록 주의를 기울일 필요가 있을 것이다. 영어로

보길 원한다면 chapter 1의 “Explorer에서 Language(언어) 문제”부분을 확인하라.

7.5.4.Active Session History(ASH)

7.5.4.1. ASH 개요 및 속성이 용어가 소개되는 배경에는 앞서 설명한 AWR과 ADDM의 한계 때문이다. 이미

언급했지만 기본적으로 database를 분석하는 period는 1시간이기 때문에 가장

최신의 정보에 대한 분석은 어려울 수 밖에 없다. 보통 최근 5분에서 10분의 정보가

있어야 최신 분석이 가능하지만 이러한 짧은 period내에서 분석을 수행하게 되면 그

period마다 통계를 저장하고 분석하는 cost는 결코 무시할 수는 없기 때문이다.

그래서 지금 이야기 하는 이 ASH는 때로는 매우 효과적인 정보를 제공할 수 있다. 말

그대로 매 초마다 active session에 한해 sampling을 실시하여 저장한다. 따라서 그

정보들을 historical하게 볼 수 있음으로 이미 발생한 또는 계속 발생하고 있는

문제들에 대한 historical 접근이 가능하게 된다. 이 정보들은 해당 session의 과거

wait event와 당시 session 정보, SQL ID등 많은 정보들을 보여준다.

ASH는 기본적으로 memory상에 위치하는 rolling buffer로 만들어진다. 즉, SGA에

존재하며 shared pool의 5%를 넘지 않도록 구성되며 보통 CPU 1개당 2MB의 크기를

점유한다.

SGA에 위치하는 ASH는 주기적으로 MMON(매 60분)에 의해 disk로 write되고

oracle10g의 new background process인 MMNL(Manageability Monitor Light)

에 의해 ASH의 buffer가 full될 때마다 disk로 write된다. 그러나 그 많은 정보들을 다

보존할 수는 없기 때문에 disk로 write될 때마다 filtering을 하게 된다.

7.5.4.2. ASH Access

과거의 active session history는 v$active_session_history를 통해 접근할 수 있다.



이 내용과 부가적인 정보를 확인한 후 다음의 example을 확인하기 바란다.

Column Description Value 또는 타 view와 관계

SAMPLE_ID sample ID 없음

SAMPLE_TIME Sampling time 없음

SESSION_ID SID v$session.sid

SESSION_SERIAL# Session serial number v$session.serial#

USER_ID USER ID v$session.user#

SQL_ID Sampling 당시 수행하던 SQL

ID

없음

SQL_CHILD_NUMBER Sampling 당시 수행하던 SQL

의 child number

없음

SQL_PLAN_HASH_VAL

UE

Sampling 당시 수행하던 SQL

의 plan(hash value)

없음

SQL_OPCODE Sampling 당시 수행하던 SQL

의 대표 code

v$session.command

SERVICE_HASH Service hash value v$active_services.name_ha

sh

SESSION_TYPE Session type FOREGROUND,

BACKGROUND

SESSION_STATE Session state WAITING, ON CPU

QC_SESSION_ID Query coordinator session

ID

Parallel이 아니면 0

QC_INSTANCE_ID Query coordinator instance

ID

Parallel이 아니면 0

EVENT Sampling 당시 waiting 또는

마지막 wait한 event

위 session_state의 값이

WAITING current waiting

ON CPU last waited

EVENT# 위 해당 event의 number

SEQ# Wait의 unique ID (각 wait당

증가되는 번호)

P1 event관련 parameter #1

value


value



표 7-15

ASH 항목과 의미


value

WAIT_TIME 0 sampling시 waiting

> 0 last wait total

v$session.wait_time

TIME_WAITED waiting으로 소비한 시간 위 session_state가 WAITING

인 경우에 한해

(만일, wait event가 1초 이상

지속되고 해당 event가

sampling에서 계속 발생되면

마지막 sampling시의 값만이

유효하다)

CURRENT_OBJ# Object ID v$session.row_wait_obj#

CURRENT_FILE# File number v$session.row_wait_file#

CURRENT_BLOCK# Block ID v$session.row_wait_block#

PROGRAM OS program v$session.program

MODULE Module name v$session.module

(dbms_application_info.set_

module)

ACTION 실행중인 module의 action

name

v$session.action

(dbms_application_info.set_

action)

CLIENT_ID Client ID v$session.client_identifier

(dbms_session.set_identifier

)

CF. 위 data들이 flush되어 disk로 write되면 “desc dba_hist_active_sess_history”

를 통해 확인할 수 있다.

위 column중 sql_opcode의 값은 다음과 같다.

ID Description ID Description

1 CREATE TABLE 2 INSERT

3 SELECT 4 CREATE CLUSTER

5 ALTER CLUSTER 6 UPDATE

7 DELETE 8 DROP CLUSTER

9 CREATE INDEX 10 DROP INDEX

11 ALTER INDEX 12 DROP TABLE


표 7-16

SQL 종류별 Code 값


13 CREATE SEQUENCE 14 ALTER SEQUENCE

15 ALTER TABLE 16 DROP SEQUENCE

17 GRANT OBJECT 18 REVOKE OBJECT

19 CREATE SYNONYM 20 DROP SYNONYM

21 CREATE VIEW 22 DROP VIEW

23 VALIDATE INDEX 24 CREATE PROCEDURE

25 ALTER PROCEDURE 26 LOCK

27 NO-OP 28 RENAME

29 COMMENT 30 AUDIT OBJECT

31 NOAUDIT OBJECT 32 CREATE DATABASE LINK

33 DROP DATABASE LINK 34 CREATE DATABASE

35 ALTER DATABASE 36 CREATE ROLLBACK SEG

37 ALTER ROLLBACK SEG 38 DROP ROLLBACK SEG

39 CREATE TABLESPACE 40 ALTER TABLESPACE

41 DROP TABLESPACE 42 ALTER SESSION

43 ALTER USER 44 COMMIT

45 ROLLBACK 46 SAVEPOINT

47 PL/SQL EXECUTE 48 SET TRANSACTION

49 ALTER SYSTEM 50 EXPLAIN

51 CREATE USER 52 CREATE ROLE

53 DROP USER 54 DROP ROLE

55 SET ROLE 56 CREATE SCHEMA

57 CREATE CONTROL FILE 59 CREATE TRIGGER

60 ALTER TRIGGER 61 DROP TRIGGER

62 ANALYZE TABLE 63 ANALYZE INDEX

64 ANALYZE CLUSTER 65 CREATE PROFILE

66 DROP PROFILE 67 ALTER PROFILE

68 DROP PROCEDURE 70 ALTER RESOURCE COST

71 CREATE MATERIALIZED VIEW LOG 72 ALTER MATERIALIZED VIEW LOG

73 DROP MATERIALIZED VIEW LOG 74 CREATE MATERIALIZED VIEW

75 ALTER MATERIALIZED VIEW 76 DROP MATERIALIZED VIEW

77 CREATE TYPE 78 DROP TYPE

79 ALTER ROLE 80 ALTER TYPE

81 CREATE TYPE BODY 82 ALTER TYPE BODY

83 DROP TYPE BODY 84 DROP LIBRARY



85 TRUNCATE TABLE 86 TRUNCATE CLUSTER

91 CREATE FUNCTION 92 ALTER FUNCTION

93 DROP FUNCTION 94 CREATE PACKAGE

95 ALTER PACKAGE 96 DROP PACKAGE

97 CREATE PACKAGE BODY 98 ALTER PACKAGE BODY

99 DROP PACKAGE BODY 100 LOGON

101 LOGOFF 102 LOGOFF BY CLEANUP

103 SESSION REC 104 SYSTEM AUDIT

105 SYSTEM NOAUDIT 106 AUDIT DEFAULT

107 NOAUDIT DEFAULT 108 SYSTEM GRANT

109 SYSTEM REVOKE 110 CREATE PUBLIC SYNONYM

111 DROP PUBLIC SYNONYM 112 CREATE PUBLIC DATABASE LINK

113 DROP PUBLIC DATABASE LINK 114 GRANT ROLE

115 REVOKE ROLE 116 EXECUTE PROCEDURE

117 USER COMMENT 118 ENABLE TRIGGER

119 DISABLE TRIGGER 120 ENABLE ALL TRIGGERS

121 DISABLE ALL TRIGGERS 122 NETWORK ERROR

123 EXECUTE TYPE 157 CREATE DIRECTORY

158 DROP DIRECTORY 159 CREATE LIBRARY

160 CREATE JAVA 161 ALTER JAVA

162 DROP JAVA 163 CREATE OPERATOR

164 CREATE INDEXTYPE 165 DROP INDEXTYPE

167 DROP OPERATOR 168 ASSOCIATE STATISTICS

169 DISASSOCIATE STATISTICS 170 CALL METHOD

171 CREATE SUMMARY 172 ALTER SUMMARY

173 DROP SUMMARY 174 CREATE DIMENSION

175 ALTER DIMENSION 176 DROP DIMENSION

177 CREATE CONTEXT 178 DROP CONTEXT

179 ALTER OUTLINE 180 CREATE OUTLINE

181 DROP OUTLINE 182 UPDATE INDEXES

183 ALTER OPERATOR

7.5.4.3. ASH Example

간단하게 위 내용들을 확인해 보자. 먼저 새로운 다음의 예에서 굵게 표시된

background process MMNL을 보자.



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

oracle 15862 1 0 Aug19 ? 00:00:00 ora_pmon_NEWSVC

oracle 15864 1 0 Aug19 ? 00:00:00 ora_mman_NEWSVC

oracle 15866 1 0 Aug19 ? 00:00:15 ora_dbw0_NEWSVC

oracle 15868 1 0 Aug19 ? 00:00:22 ora_lgwr_NEWSVC

oracle 15870 1 0 Aug19 ? 00:00:01 ora_ckpt_NEWSVC

oracle 15872 1 0 Aug19 ? 00:00:32 ora_smon_NEWSVC

oracle 15874 1 0 Aug19 ? 00:00:00 ora_reco_NEWSVC

oracle 15876 1 0 Aug19 ? 00:00:33 ora_cjq0_NEWSVC

oracle 15880 1 0 Aug19 ? 00:00:06 ora_rvwr_NEWSVC



oracle 15888 1 0 Aug19 ? 00:00:00 ora_qmnc_NEWSVC

oracle 15890 1 0 Aug19 ? 00:00:09 ora_mmon_NEWSVC

oracle 15894 1 0 Aug19 ? 00:00:00 ora_mmnl_NEWSVC



oracle 18572 13347 0 13:45 pts/0 00:00:00 grep ora_

이제 직접 ASH에 접근하여 확인을 해보자. 먼저 session을 하나 만들어 DML을 수행한

후 해당 session을 close하는 과정을 진행한다.

SCOTT> select sid from v$session where username = 'SCOTT';

SID

----------

532

SCOTT> create table x_ash (col number);

Table created.

SCOTT> begin

2 for i in 1..10000 loop

3 insert into x_ash values (i);

4 end loop;



5 commit;

6 end;

7 /


SCOTT> exit

Disconnected from Oracle Database 10g Enterprise Edition Release

10.1.0.4.0 - Production



분명히 session을 close했다. 다음으로 SQL은 ASH에서 이미 close된 session의

historical 정보를 확인해 보자.

SYSTEM> select user_id from dba_users where username = 'SCOTT';

USER_ID

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

61

SYSTEM> col action_time for a10

SYSTEM> col event for a27

SYSTEM> col module for a10

SYSTEM> col usr for 999

SYSTEM> col scd for 99

SYSTEM> select user_id usr, to_char(sample_time, 'HH24:MI:SS')

action_time,

2 sql_id, sql_opcode scd, event, current_obj# obj_id, current_file# file_id,

module

3 from v$active_session_history

4 where session_id = 532 and user_id = 61 and sample_time > sysdate -

(1/24)

5 order by 2;

USR ACTION SQL_ID SC EVENT OBJ_ID FILE_ID MODULE



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

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

61 13:54:29 18q7jg3htxjnu 1 SQL*Net message from client 6244 1 SQL*Plus

61 13:59:07 4kbjqqz928apu 2 db file scattered read 61818 16 SQL*Plus

61 13:59:08 4kbjqqz928apu 2 db file sequential read 61818 16 SQL*Plus

61 13:59:09 3ayxa0s0ruqzw 47 db file sequential read 61818 16 SQL*Plus

위 결과로 해당 시간에 SCOTT 계정이 sqlplus를 통해 create table, insert, PL/SQL

execution을 했음을 확인할 수 있다. 매우 정확하게 그 기록이 확인된다. 위 data를

근거로 당시의 SQL도 확인이 가능하며 몇 가지 확장된 정보도 유추해 볼 수도 있다.

SYSTEM> col object_name for a30

SYSTEM> select object_name, object_id from dba_objects

2 where object_id = 61818;

OBJECT_NAME OBJECT_ID

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

X_ASH 61818

SYSTEM> select tablespace_name from dba_data_files

2 where file_id = 16;

TABLESPACE_NAME

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

USER_DEFAULT

보다 구체적이다. Table X_ASH에 대한 insert작업이 일어났고 그 tablespace는

user_default이라는 것도 확인이 된다. 여기서는 간단하게 살펴보았으나 이 view를 잘

이용하면 보다 많은 정보들을 유추해낼 수 있을 것이다.

CF. 아마도 여러분 중 일부는 이 ASH와 관련하여 v$session의 변화를 인식한 사람이

있을지도 모르겠다. 아직 확인을 하지 못했다면 v$session을 조회해 보라. 이전과

달라진 매우 많은 columns이 추가된 것을 확인할 수 있을 것이다. 특히나 우리가 자주

사용하던 v$session_wait의 columns도 볼 수 있다는 것은 신선한 느낌을 준다. ASH

의 기능은 v$session의 변화와 무관하지 않을 것이다.



CF. oracle10g release 2부터는 ASH report를 통해 즉각적인 분석 즉, immediate

spot 분석이 가능해진다.

7.5.5.Advisor (문제 해결사)

Advisors는 database의 성능 및 자원(performance and resource)에 대한 유용한

정보를 제공해주는 server components이다. 여러 종류의 advisor가 존재하며

여기서는 그 기반 구조 및 구성요소에 대해 설명한다.

7.5.5.1. Advisor의 구조앞서 설명한 ADDM은 system 진단 결과에 대한 Top-Down 형식의 분석을 진행하면서

파악된 문제들에 대한 적절한 해결책을 제공하는 것이 그 중요한 기능의 하나라고 했다.

사실 이 기능도 진단된 문제들에 대하여 각각의 advisor를 call함으로써 문제해결에

대한 접근방식을 제공하는 것이다.

CF. 결국은 workload repository에서 추출된 정보들이 이러한 일들을 가능하게

만들어 주는 것이다. 그 만큼 workload repository는 중요하다. 잘못된 정보는 잘못된

결과를 제안한다는 것을 명심하자.

Oracle10g가 제공하는 기본 advisor는 다음과 같은 구조하에 작동된다.


그림 7-24

Advisor Architecture


7.5.5.2. 기본 Advisor

1. SQL tuning : SQL문에 대한 tuning 충고를 제공한다.

2. SQL access : SQL문의 access 유형을 제안한다. (index, MView등)

3. PGA : work area에 대한 자세한 통계와 workload를 기반으로 하는 PGA의 적절한

사용과 관련한 제안을 한다.

4. SGA : SGA의 tuning 및 size에 대한 제안을 한다.

5. Segment : objects에 대한 space 문제와 size 증가에 대한 경향을 분석한다.

6. Undo : flashback을 위한 부가적인 용량 및 parameter 값에 대한 제안을 한다.

7.5.5.3. Advisor 사용하기그렇다면 advisor가 주는 제안들을 어떻게 받을 수 있을까. 사실 여러분은 이미 알고

있다. 앞서 ADDM을 설명하면서 report를 산출하는 방법을 설명한 바 있다. 거기에서

report를 산출하는 여러 가지 방법들을 제시했고 특히 dbms_advisor package를

이용하여 task를 설정하여 분석을 수행한 후 report를 산출하는 예도 설명된 바 있다.

그 과정을 다시 정리해보면 다음과 같다.

이 과정은 dbms_advisor의 sub procedure와 function을 call함으로써 이루어진다.

먼저 아래의 과정은 id와 task를 받는 변수 v_id와 v_task가 있다고 가정한다.

1. create_task('advisor_name', :v_id, :v_task);

2. set_task_parameter(:v_task, 'START_SNAPSHOT', start_snap_id);

3. set_task_parameter(:v_task, 'END_SNAPSHOT', end_snap_id);

4. set_task_parameter(:v_task, 'INSTANCE', instance_id);

5. set_task_parameter(:v_task, 'DB_ID', database_id);

6. execute_task(:v_task)

7. 마지막으로 결과를 보기 위해

SQL> select dbms_advisor.get_task_report(:v_task) from dual;

그러나 이 advisor를 위한 task를 생성할 때 그 종류가 무엇이 있는지는 언급하지는

않았다. 즉, dbms_advisor.create_task를 통해 task를 생성할 때 입력을 해야 하는

advisor의 값은 어떤 것들이 있는지 알아보자. 다음의 SQL 결과는 현재 database에서

제공하는(dbms_advisor.create_task의 advisor_name parameter로 줄 수 있는)

advisor의 종류를 보여준다.

SYSTEM> select * from dba_advisor_definitions;

ADVISOR_ID ADVISOR_NAME PROPERTY

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



1 ADDM 1

2 SQL Access Advisor 15

3 Undo Advisor 1

4 SQL Tuning Advisor 3

5 Segment Advisor 3

6 SQL Workload Manager 0

7 Tune MView 31

7 rows selected.

다음은 위에서 설명한 것 외에 advisor의 control을 위해 자주 사용하는 중요한 sub

stored-procedure에 대한 설명이다.

1. delete_task : repository로부터 지정된 task를 삭제한다.

2. cancel_task : soft interrupt라 한다. 현재 작업중인 task를 종료한다. (그러나

“CTRL+C”처럼(hard interrupt) low-level database access를 강제로 중단하지는

않는다. 따라서 약간 혹은 생각보다 많은 시간이 소요될 수도 있다)

3. interrupt_task : 현재 수행중인 task를 중단한다. 하지만 이 작업은 정상적인 exit

처럼 작동하기 때문에 중단하는 시점까지의 분석 결과는 사용이 가능하다.

4. resume_task : 현재 중단된 task를 다시 수행한다.

5. get_task_script : buffer의 advisor제안 사항을 실행하는 SQL script로 return

한다.

6. mark_recommendation : 특정 task의 특정 recommendation의 상태를

(ACCEPT, IGNORE, IMPLEMENTED, REJECT) 설정한다. 이 값은 분석에 대한 제안을

위해 만들어지는 scripts에 영향을 주게 된다. 예를 들어 어떤 분석이 reject이면 그

항목에 대한 recommendation이 나타나지 않게 된다.

7. update_task_attributes : 이미 만들어진 task의 속성을 변경하기 위해 사용된다.

(task의 이름 변경, 설명 및 사용상태의 변경 등)

8. reset_task : 지정한 task을 초기화 한다. 따라서 기존에 존재하는 해당 task의

제안들은 삭제된다.

9. create_file : 분석결과를 file로 만들어준다. (분석결과는 CLOB type임으로 이를

file로 저장하여 보기 쉽게 해준다)

CF. advisor와 관련한 정보를 담고 있는 dictionary들은 앞서 AWR의 통계정보에 대한

access를 설명하면서 이미 살펴본 바 있다



CF. 특별한 권한인 “advisor”를 grant받으면 모든 advisor관련 stored-procedures,

views에 access가 가능하다. 이는 앞서 chapter 4에서 materialized view관리

부분에서 살펴본 바 있다.

7.5.5.4. Using em

이 부분은 여기서 따로 보여줄 것이 없다. 잘 생각해 보라. 앞서 우리는 이미 ADDM을

설명하면서 em과의 관계를 살펴본 바 있다. 물론, 거기서 “Advisor Central (중앙

권고자)”를 통해 advisor에 접근하고 Top-Down형식으로 문제를 찾아가는 방법도

살펴보았다. 기억이 나지 않는다면 ADDM 부분을 다시 살펴보라.



OCP point

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

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

1. dba_feature_usage_statistics, dba_high_water_mark_statistics의 정의

2. AWR에 저장되는 snapshot의 속성

3. automatic snapshot의 주기를 변경하는 procedure의 사용법

4. ASH 개요 및 속성

5. ASH에 access하는 view의 이름

6. ASH관련 background process



7.6. Alert & Notification (경보와 알림기능)

7.6.1.Alert 개요

7.6.1.1. Server Generated Alert

Database를 운영하면서 DBA의 일상적인 업무 중 가장 반복적인 작업은 database의

성능이나 resource의 상태를 점검하고 문제점을 빠르게 인식, 해결하는 일이다.

하지만 이는 수작업에 의존하거나 3rd party tool 또는 실력 있는 DBA라면 스스로

프로그램을 만들어 처리하게 된다. 물론, 그 정확도는 다 다르기 때문에 무엇이 옳다고

할 수도 없다.

Oracle10g는 이런 부분까지도 자동화를 이루었다. 앞서 설명한 MMON process는

주기적으로 성능 및 resource의 문제를 감지하여 alert message를 보내고 합리적인

해결안을 제시하도록 해준다. 즉, server 스스로 문제를 진단하여 적절한 message를

생성한 후 알려준다는 말이다. 물론, 이 작업들은 통계를 제대로 수집해주는

oracle10g의 능력이기 때문에 DBA 스스로 data dictionary를 모니터링하고

처리하는 작업도 가능하게 해준다.

CF. 당연하겠지만 이런 data들은 workload repository에 history로서 관리되기

때문에 향후 tuning관련 작업에 사용될 수도 있다.

7.6.1.2. Server Alert의 장점이런 기능들은 다음과 같은 면에서 효율적이다.

1. pinging이 존재하지 않는다. 다른 tool이나 프로그램을 사용하여 이런 작업을

구현하기 위해서는 pining을 통해 상태를 check하는 작업이 필수적이다. 예를 들어

어떤 특정 tool을 설치해 database의 상태를 점검한다면 주기적으로 database가

startup되어 있는지를 항상 먼저 확인할 필요가 있을 것이지만 oracle10g alert는

그럴 필요가 없다는 것이다.

2. oracle10g alert는 모든 진단 tool이 가지는 또는 진단 tool을 사용하는 사용자가

우려하는 진단으로 인한 overhead를 걱정할 필요가 없다. Oracle 내부적으로

처리되는 이 작업은 매우 적은 resource만을 사용한다. (oracle의 주장은 0.1%

미만의 자원을 사용한다고 한다)

3. workload repository를 통해 관리가 이루어진다. 앞서 workload repository를

설명한 바 그 이점은 다 알겠지만 진단과 관련한 alert 내역 또한 historical data로서

workload repository에서 관리가 되기 때문에 미래의 분석에도 사용될 수 있고 그

관리 또한 자동화된다는 강점이 있다.

4. 작업을 담당하는 MMON은 SGA memory를 직접 access함으로 별다른 부하를



주지 않고 모니터링 작업이 이루어진다.

CF. 과거의 일반적인 monitoring system은 모두 정해진 시점에 polling을 통해 data

를 취합하는 방식이지만 oracle10g의 방식은 SGA에서 통계를 자체적으로 수집하는

형태이다. 그래서 이를 과거의 polling model과 구별하여 pushing model이라 하는

것도 그 이유다. (물론, em도 polling 방식이다)

7.6.2.Alert 구조

7.6.2.1. Alert 생성 시점Alert를 보내기 위해서는 당연히 조건이 필요하다. 즉, 어떤 resource의 사용량이 몇 %

를 넘었다라는 식의 조건이 있어야 한다는 말이다. Oracle10g는 internal하게 정해진

기준이나(alert에 따라 사용자가 변경 가능한 alerts도 있다) 사용자가 정의한 임계값

(threshold) 또는 특정 events가 발생했을 때 그 상황들을 기반으로 하여 alert를

생성한다. 즉, instance에서 측정된 기준 값(metric)을 기반으로 하는 alert와

database에서 특정 event가 발생할 때 그 event를 기준으로 하는 alert로 나누어진다.

7.6.2.2. Server Alert & em Alert

Oracle alert은 em(database control) alert과 server alert로 구분될 수 있는데 em

에서 사용하는 metrics은 자동으로 em daemon process로 server alert는 MMON

에서 수집되어 필요한 alerts가 생성된다

Oracle이 생성하는 server alert는 이미 만들어진 queue인 sys 소유의

“ALERT_QUE”에 쌓이게 되는데 앞서 여러분이 살펴보았던 em의 database control

도 바로 이 queue를 사용하는 subscriber중 하나이다. 따라서 em의 database

control화면에는 이 alerts과 em alerts이 함께 표시된다.

CF. 필요하다면 database control에서 적절한 설정을 통해 e-mail이나 pager로 DBA

에게 message를 보낼 수도 있다.

사용되는 queue인 alert_que는 multiple consumer queue이다. 즉, 여러

subscriber가 사용할 수 있기 때문에 queuing된 alert는 모든 subscriber가

dequeue할 때까지 purge되지 않는다. 따라서 한 subscriber가 dequeue를 하게

되면 그 subscriber는 더 이상 alert message를 볼 수 없지만 다른 subscriber에게는

여전히 유효하다

CF. alert가 alert queue에 write될 수 없다면 관련 message는 alert log file에



write된다.

이를 종합해서 볼 때 만일 em의 database control을 사용하지 않고 queuing된

alerts를 받기 위해서는 앞서 설명한 “ALERT_QUE”를 access하고 dequeue를 할 수

있는 모니터링 사용자를 만들어 이 queue의 subscriber로 등록을 해서 alert

notification을 받아야 함을 알 수 있다.

CF. 일반적인 queuing과 관련한 mechanism은 여기서 다룰 대상이 아니지만 위

정보만 가지고 있다면 관련 package를 이용하여 alert notification을 구현할 수 있을

것이다. (다음에 설명되는 alert control부분을 확인하라)

7.6.2.3. Alert Model

다음은 이 alert model을 도식화한 그림이다.



7.6.3.Alert Types

Oracle이 생성하는 alert는 두 가지 종류가 있다. 하나는 값을 기준으로 하는 즉,

threshold(임계값)를 기준으로 하며 다른 하나는 non-threshold로서 database

event에 따라 생성된다.

7.6.3.1. Stateful Alert

이 alert는 threshold를 기반으로 하는 alert를 지칭하는 용어이다. 여기서 사용되는

metric은 보통 두 가지 값으로 이루어진다. 이는 곧 alert message의 형식이 되는데

warning(경고)과 critical(위험) 값을 설정한다는 의미가 된다. 예를 들면 최초 system

에서 default로 설정하는 tablespace 사용량에 대한 metric은 85% 사용시 warning


그림 7-25

Alert Architecture


으로 97% 사용시 critical로 설정이 되어있다. 따라서 이런 threshold level의 alerts

는 threshold warning level과 critical level 둘 다에게 trigger되어 alert의

생성여부가 결정된다고 할 수 있겠다.

Stateful alert는 대부분 instance와 연관이 되며 threshold에 다다르면 즉, alert

condition에 부합되면 생성되고 문제가 해결되어 alert condition에 부합되지 않으면

clear된다. 다만, 매우 위험한 수준의 alert가 발생하면 문제가 해결되어도 해당

message는 alert history로 이동되어 workload repository에서 관리된다. 물론,

workload repository의 purging 주기에 부합되면 자동으로 purge된다.

Stateful alert를 위한 metric은 “초당 IO”, “CPU wait active session수”, “초당

commit수”등과 같은 것 들이다. 물론, 모두 instance와 연관되어 있지만 예외적으로

tablespace의 사용량과 관련된 alert만은 database event와 관련되어 있음에도

사용량에 대한 threshold를 줄 수 있기 때문에 stateful alert로 분류된다.

현재 설정되어 있는 threshold의 값은 “dba_thresholds”를 통해 확인할 수 있다.

다음은 앞서 언급한 tablespace의 설정 값을 확인하는 예이다.

SYSTEM> select metrics_name, warning_value, critical_value

2 from dba_thresholds

3 where object_type = 'TABLESPACE';

METRICS_NAME WARNING_VALUE CRITICAL_VALUE

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

Tablespace Space Usage 85 97

이미 발생한 outstanding server alert은 “dba_outstanding_alerts”에서 확인할 수

있으며 문제가 해결되면 “dba_alert_history”로 이동된다. 그 밖에 alerts의 type을

확인하는 것은 “v$alert_types”에서 가능하다. 다음은 현재 필자의 database에서

alert message를 확인해본 예이다.

실제 결과 중 recovery area message는 너무 길어서 메시지를 “…..”으로 축약하여

표시했다.

SYSTEM> select object_name, object_type, reason

2 from dba_outstanding_alerts;

OBJECT_NAME OBJECT_TYPE REASON



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

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

RECOVERY AREA RECOVERY AREA db_recovery_file_dest_size of 524288... bytes is

85.12%..

AUTOTBS TABLESPACE Tablespace [AUTOTBS] is [96 percent] full

SYSTEM SYSTEM Metrics "Current Open Cursors Count" is at 1249

7.6.3.2. Stateless Alert

Database event와 연동되는 alert로서 threshold가 없는 non-threshold alert를

stateless alert라 칭한다. 이런 류의 server alert로 “snapshot too old”, “recovery

area space”, “resumable session suspended”같은 것들이 있는데 이 alerts는

event발생시 바로 history table로 이동된다. 이런 stateless alert는 database

control의 repository에 저장되기 때문에 clear하는 작업 또한 database control에서

이루어 진다.

CF. 이런 용어들과 metrics을 확인하다 이상한 점이 있었다. 이유를 확인하진 못했으나

v$alert_types을 보면 snapshot too old를 제외한 recovery area나 session

suspended는 stateful로 정의가 되어있었기 때문이다. 필자가 보기에 보다

구체적이고 정확하게 alert를 구분하기 위해서는 threshold level인가(threshold

based alerts) 아니면 non-threshold level인가로 구분을 하는 것이 더 옳을 것으로

생각된다.

7.6.3.3. Out-of-Box Server Alert

이 용어는 oracle10g가 default로 enable하여 사용하는 database event관련

server alert를 말한다. (물론, tablespace 사용량과 관련된 alert는 앞서 말한바 대로

threshold based alert이다)

1. tablespace usage(default warning 85%, critical 97%)

2. snapshot too old

3. resumable session suspended (oracle9i에서 소개된 session의 작업이 진행

중에tablespace가 부족하게 되는 경우 해당 session의 작업을 holding할 수 있는

기능을 말한다)

4. recovery area usage (initial parameter “db_recovery_file_dest_size”의

사용량을 말한다)

CF. oracle10g database관련 자료에서는 구체적인 설명이 없지만 위 alerts은 em

과의 연관성 때문에 따로 분류하는 것이라고 생각된다. 즉, 현재까지는 database



event와 관련된 alerts중 위와 같은 것들만 server alerts에서 볼 수 있고 나머지는(

예를 들면 archive destination size alert) em에서만 가능하다. 따라서 이런 종류의

alerts은 em의 관리를 통해서만 alert를 받을 수 있는 것이지만 위 4가지 database

events관련 alerts은 server alerts에 존재하기 때문에(ALERT_QUE에 쌓이기

때문에) “out-of-box”라는 용어를 사용하는 것으로 생각된다. 굳이 수식으로

표현하자면 “em alerts > server alerts = (general alerts + out-of-box alerts) or

(threshold level alerts + non-threshold level alerts)” 정도가 될 것이다.

CF. 앞서 조회한 dba_outstanding_alerts에서 recover area정보는 나타났지만 em

에서 나타난 archive destination size가 부족하다는 정보가 안 보이는 것도 out-of-

box alert에 속한 것이냐 아니냐에 따라 server에서 받을 수 있는 것과 그렇지 않은

것으로 나뉘어지기 때문으로 생각된다.

7.6.4.Alert Control

7.6.4.1. Threshold 조절 (Manually)

여러분이 PL/SQL을 통해 manually alert을 위한 threshold를 설정하기 위해서는

package “dbms_server_alert”를 사용해야 한다. 이 package에서 threshold를

조절하기 위해 사용하는 procedure로 threshold를 확인하는 get_threshold와

threshold를 설정하는 set_threshold는 다음과 같은 parameter를 갖는다.

단, parameter in/out의 설정은 set_threshold의 경우 모두 in parameter이고

get_threshold의 경우는 아래와 같다.

CF. server alert queue를 확인하는 sub procedure인 expand_message function

은 나중에 설명하는 “Alert 확인(Manually)” 부분의 예제에서 다룬다.

Argument In/Out Description

metrics_id in 내부적으로 사용되는 metrics id

(아래 parameter type 참조)

warning_operator out warning threshold의 비교연산자


warning_value out warning value

critical_operator out critical threshold의 비교연산자


critical_value out critical value

observation_perio

d

out threshold 와 metric을 비교하는 주기


표 7-17

Threshold 설정 Parameter


consecutive_occur

rences

out alert를 발생하기 전에 observation period가 몇

회에 걸쳐 계속 threshold위반을 해야 하는가를

지정

instance_name in threshold 설정이 있는 instance이름

(database event alert는 NULL로 설정)

object_type in metric object type을 지정한다.

object_name in metric object 이름(NULL은 “SYSTEM”이다)


간단하게 예를 들어서 현재 default tablespace로 사용하고 있는 “USER_DEFAULT”

tablespace의 space관리가 워낙 중요하다고 생각해 보자. 그래서 해당 tablespace의

threshold를 warning 50%, critical 80%로 설정하고 싶다면 어떻게 할까. 다음은

실제 그 작업을 진행해 본 것이다.

SYSTEM> exec dbms_server_alert.set_threshold( -

> dbms_server_alert.TABLESPACE_PCT_FULL, -

> dbms_server_alert.OPERATOR_GE,'50', -

> dbms_server_alert.OPERATOR_GE,'80', 1, 1, NULL, -

> dbms_server_alert.OBJECT_TYPE_TABLESPACE,'USER_DEFAULT');


보기에는 무척 난감하다. 잘 모르는 용어들이 function type으로 많이 쓰였기

때문이다. 이들 type의 내용들을 알아야 여러분이 적절하게 원하는 값을 설정할 수

있을 것이다. 다음은 그 type의 3가지 종류 “metric id”, “operator”, “object type”

을 소개한 내용이다. 항상 그렇듯 oracle용어 그대로 이해하기 바란다.

1. metrics id

Metric Name Description 단위

SQL_SRV_RESPONSE_TIMEService Response (for each

execution)Seconds

BUFFER_CACHE_HIT Buffer Cache Hit (%) % of cache accesses

LIBRARY_CACHE_HIT Library Cache Hit (%) % of cache accesses

LIBRARY_CACHE_MISS Library Cache Miss (%) % of cache accesses

MEMORY_SORTS_PCT Sorts in Memory (%) % of sorts

REDO_ALLOCATION_HIT Redo Log Allocation Hit % of redo allocations

TRANSACTION_RATE Number of Transactions (for each Transactions for each


표 7-18

Metric 종류와 의미


second) Second

PHYSICAL_READS_SEC Physical Reads (for each second) Reads for each Second

PHYSICAL_READS_TXNPhysical Reads (for each

transaction)

Reads for each

Transaction

PHYSICAL_WRITES_SEC Physical Writes (for each second) Writes for each Second

PHYSICAL_WRITES_TXNPhysical Writes (for each

transaction)

Writes for each

Transaction

PHYSICAL__READS_DIR_SECDirect Physical Reads (for each

second)Reads for each Second

PHYSICAL_READS_DIR_TXNDirect Physical Reads (for each

transaction)

Reads for each

Transaction

PHYSICAL_WRITES_DIR_SECDirect Physical Writes (for each

second)Writes for each Second

PHYSICAL_WRITES_DIR_TXNDirect Physical Writes (for each

transaction)

Writes for each

Transaction

PHYSICAL_READS_LOB_SECDirect LOB Physical Reads (for

each second)Reads for each Second

PHYSICAL_READS_LOB_TXNDirect LOB Physical Reads (for

each transaction)

Reads for each

Transaction

PHYSICAL_WRITES_LOB_SECDirect LOB Physical Writes (for

each second)Writes for each Second

PHYSICAL_WRITES_LOB_TXNDirect LOB Physical Writes (for

each transaction)

Writes for each

Transaction

REDO_GENERATED_SECRedo Generated (for each

second)

Redo Bytes for each

Second

REDO_GENERATED_TXNRedo Generated (for each

transaction)

Redo Bytes for each

Transaction

DATABASE_WAIT_TIME Database Wait Time (%) % of all database time

DATABASE_CPU_TIME Database CPU Time (%) % of all database time

LOGONS_SECCumulative Logons (for each

second)Logons for each Second

LOGONS_TXNCumulative Logons (for each

transaction)

Logons for each

Transaction

LOGONS_CURRENT Current Number of Logons Number of Logons

OPEN_CURSORS_SEC Cumulative Open Cursors (for Cursors for each Second



each second)

OPEN_CURSORS_TXNCumulative Open Cursors (for

each transaction)

Cursors for each

Transaction

OPEN_CURSORS_CURRENT Current Number of Cursors Number of Cursors

USER_COMMITS_SEC User Commits (for each second)Commits for each

Second

USER_COMMITS_TXNUser Commits (for each

transaction)

Commits for each

Transaction

USER_ROLLBACKS_SEC User Rollbacks (for each second)Rollbacks for each

Second

USER_ROLLBACKS_TXNUser Rollbacks (for each

transaction)

Rollbacks for each

Transaction

USER_CALLS_SEC User Calls (for each second) Calls for each Second

USER_CALLS_TXN User Calls (for each transaction)Calls for each

Transaction

RECURSIVE_CALLS_SEC Recursive Calls (for each second) Calls for each Second

RECURSIVE_CALLS_TXNRecursive Calls (for each

transaction)

Calls for each

Transaction

SESS_LOGICAL_READS_SECSession Logical Reads (for each

second)Reads for each Second

SESS_LOGICAL_READS_TXNSession Logical Reads (for each

transaction)

Reads for each

Transaction

DBWR_CKPT_SECDBWR Checkpoints (for each

second)

Checkpoints for each

Second

LOG_SWITCH_SECBackground Checkpoints (for

each second)

Checkpoints for each

Second

REDO_WRITES_SEC Redo Writes (for each second) Writes for each Second

REDO_WRITES_TXNRedo Writes (for each

transaction)

Writes for each

Transaction

LONG_TABLE_SCANS_SECScans on Long Tables (for each

second)Scans for each Second

LONG_TABLE_SCANS_TXNScans on Long Tables (for each

transaction)

Scans for each

Transaction

TOTAL_TABLE_SCANS_SECTotal Table Scans (for each




TOTAL_TABLE_SCANS_TXNTotal Table Scans (for each

transaction)

Scans for each

Transaction

FULL_INDEX_SCANS_SECFast Full Index Scans (for each


FULL_INDEXE_SCANS_TXNFast Full Index Scans (for each

transaction)

Scans for each

Transaction

TOTAL_INDEX_SCANS_SECTotal Index Scans (for each


TOTAL_INDEX_SCANS_TXNTotal Index Scans (for each

transaction)

Scans for each

Transaction

TOTAL_PARSES_SEC Total Parses (for each second) Parses for each Second

TOTAL_PARSES_TXN Total Parses(for each transaction)Parses for each

Transaction

HARD_PARSES_SEC Hard Parses(for each second) Parses for each Second

HARD_PARSES_TXN Hard Parses(for each transaction)Parses for each

Transaction

PARSE_FAILURES_SEC Parse Failures (for each second) Parses for each Second

PARSE_FAILURES_TXNParse Failures (for each

transaction)

Parses for each

Transaction

DISK_SORT_SEC Sorts to Disk (for each second) Sorts for each Second

DISK_SORT_TXNSorts to Disk (for each

transaction)

Sorts for each

Transaction

ROWS_PER_SORT Rows Processed for each Sort Rows for each Sort

EXECUTE_WITHOUT_PARSEExecutes Performed Without

Parsing% of all executes

SOFT_PARSE_PCT Soft Parse (%) % of all parses

CURSOR_CACHE_HIT Cursor Cache Hit (%) % of soft parses

USER_CALLS_PCT User Calls (%) % of all calls

TXN_COMMITTED_PCT Transactions Committed (%) % of all transactions

NETWORK_BYTES_SEC Network Bytes, for each second Bytes for each Second

RESPONSE_TXN Response (for each transaction)Seconds for each

Transaction

DATA_DICT_HIT Data Dictionary Hit (%) % of dictionary accesses

DATA_DICT_MISS Data Dictionary Miss (%) % of dictionary accesses

SHARED_POOL_FREE_PCT Shared Pool Free(%) % of shared pool



AVERAGE_FILE_READ_TIME Average File Read Time Microseconds

AVERAGE_FILE_WRITE_TIME Average File Write Time Microseconds

DISK_IO Disk I/O Milliseconds

PROCESS_LIMIT_PCT Process Limit Usage (%) % of maximum value

SESSION_LIMIT_PCT Session Limit Usage (%) % of maximum value

USER_LIMIT_PCT User Limit Usage (%) % of maximum value

AVG_USERS_WAITINGAverage Number of Users

Waiting on a Class of Wait EventsCount of sessions

DB_TIME_WAITINGPercent of Database Time Spent

Waiting on a Class of Wait Events% of Database Time

APPL_DESGN_WAIT_SCTApplication Design Wait (by

session count)Count of sessions

APPL_DESGN_WAIT_TIME Application Design Wait (by time) Microseconds

PHYS_DESGN_WAIT_SCTPhysical Design Wait (by session

count)Count of sessions

PHYS_DESGN_WAIT_TIME Physical Design Wait (by time) Microseconds

CONTENTION_WAIT_SCTInternal Contention Wait (by


CONTENTION_WAIT_TIMEInternal Contention Wait (by

time)Microseconds

PSERVICE_WAIT_SCTProcess Service Wait (by session

count)Count of sessions

PSERVICE_WAIT_TIME Process Service Wait (by time) Microseconds

NETWORK_MSG_WAIT_SCTNetwork Message Wait (by


NETWORK_MSG_WAIT_TIME Network Message Wait (by time) Microseconds

DISK_IO_WAIT_SCT Disk I/O Wait (by session count) Count of sessions

OS_SERVICE_WAIT_SCTOperating System Service Wait

(by session count)Count of sessions

OS_SERVICE_WAIT_TIMEOperating System Service Wait

(by time)Microseconds

DBR_IO_LIMIT_WAIT_SCTResource Mgr I/O Limit Wait (by


DBR_IO_LIMIT_WAIT_TIMEResource Mgr I/O Limit Wait (by

time)Microseconds



DBR_CPU_LIMIT_WAIT_SCTResource Mgr CPU Limit Wait (by


DBR_CPU_LIMIT_WAIT_TIMEResource Mgr CPU Limit Wait (by

time)Microseconds

DBR_USR_LIMIT_WAIT_SCTResource Mgr User Limit Wait (by


DBR_USR_LIMIT_WAIT_TIMEResource Mgr User Limit Wait (by

time)Microseconds

OS_SCHED_CPU_WAIT_SCTOperating System Scheduler CPU

Wait (by session count)Count of sessions

OS_SCHED_CPU__WAIT_TIMEOperating System Scheduler CPU

Wait (by time)Microseconds

CLUSTER_MSG_WAIT_SCTCluster Messaging Wait (by


CLUSTER_MSG_WAIT_TIME Cluster Messaging Wait (by time) Microseconds

OTHER_WAIT_SCT Other Waits (by session count) Count of sessions

OTHER_WAIT_TIME Other Waits (by time) Microseconds

ENQUEUE_TIMEOUTS_SECEnqueue Timeouts (for each

second)

Timeouts for each

Second

ENQUEUE_TIMEOUTS_TXNEnqueue Timeouts (for each

transaction)

Timeouts for each

Transaction

ENQUEUE_WAITS_SEC Enqueue Waits (for each second) Waits for each Second

ENQUEUE_WAITS_TXNEnqueue Waits (for each

transaction)

Waits for each

Transaction

ENQUEUE_DEADLOCKS_SECEnqueue Deadlocks (for each

second)

Deadlocks for each

Second

ENQUEUE_DEADLOCKS_TXNEnqueue Deadlocks (for each

transaction)

Deadlocks for each

Transaction

ENQUEUE_REQUESTS_SECEnqueue Requests (for each

second)

Requests for each

Second

ENQUEUE_REQUESTS_TXNEnqueue Requests (for each

transaction)

Requests for each

Transaction

DB_BLKGETS_SEC DB Block Gets (for each second) Gets for each Second

DB_BLKGETS_TXNDB Block Gets (for each

transaction)

Gets for each

Transaction



CONSISTENT_GETS_SECConsistent Gets (for each

second)Gets for each Second

CONSISTENT_GETS_TXNConsistent Gets (for each

transaction)

Gets for each

Transaction

DB_BLKCHANGES_SECDB Block Changes (for each

second)

Changes for each

Second

DB_BLKCHANGES_TXNDB Block Changes (for each

transaction)

Changes for each

Transaction

CONSISTENT_CHANGES_SECConsistent Changes (for each

second)

Changes for each

Second

CONSISTENT_CHANGES_TXNConsistent Changes (for each

transaction)

Changes for each

Transaction

SESSION_CPU_SEC Database CPU (for each second)Microseconds for each

Second

SESSION_CPU_TXNDatabase CPU (for each

transaction)

Microseconds for each

Transaction

CR_BLOCKS_CREATED_SECCR Blocks Created (for each

second)Blocks for each Second

CR_BLOCKS_CREATED_TXNCR Blocks Created (for each

transaction)

Blocks for each

Transaction

CR_RECORDS_APPLIED_SECCR Undo Records Applied (for

each second)Records for each Second

CR_RECORDS_APPLIED_TXNCR Undo Records Applied (for

each transaction)

Records for each

Transaction

RB_RECORDS_APPLIED_SECRollback Undo Records Applied

(for each second)Records for each Second

RB_RECORDS_APPLIED_TXNRollback Undo Records

Applied(for each transaction)

Records for each

Transaction

LEAF_NODE_SPLITS_SECLeaf Node Splits (for each

second)Splits for each Second

LEAF_NODE_SPLITS_TXNLeaf Node Splits (for each

transaction)

Splits for each

Transaction

BRANCH_NODE_SPLITS_SECBranch Node Splits (for each

second)Splits for each Second

BRANCH_NODE_SPLITS_TXN Branch Node Splits (for each Splits for each



transaction) Transaction

GC_BLOCKS_CORRUPT Global Cache Blocks Corrupt Blocks

GC_BLOCKS_LOST Global Cache Blocks Lost Blocks

GC_AVG_CR_GET_TIME Global Cache CR Request Milliseconds

GC_AVG_CUR_GET_TIME Global Cache Current Request Milliseconds

PX_DOWNGRADED_SECDowngraded Parallel Operations

(for each second)

Operations for each

Second

PX_DOWNGRADED_25_SECDowngraded to 25% and more

(for each second)

Operations for each

Second


(for each second)

Operations for each

Second


(for each second)

Operations for each

Second

PX_DOWNGRADED_SER_SECDowngraded to serial (for each

second)

Operations for each

Second

BLOCKED_USERSNumber of Users blocked by

some SessionNumber of Users

PGA_CACHE_HIT PGA Cache Hit (%)% bytes processed in

PGA

ELAPSED_TIME_PER_CALLElapsed time for each user call

for each service


call

CPU_TIME_PER_CALLCPU time for each user call for

each service


call

TABLESPACE_PCT_FULL Tablespace space usage % full

2. operators

Operator Description

OPERATOR_CONTAINS threshold values를 가지고 있는가. (include)

OPERATOR_DO_NOT_CHECK OBJECT_TYPE_TABLESPACE metric에 default threshold를

적용하지 않는다

OPERATOR_EQ threshold와 같다. (=)

OPERATOR_GE threshold와 크거나 같다. (>=)

OPERATOR_GT threshold보다 크다. (>)

OPERATOR_LE threshold와 작거나 같다. (<=)

OPERATOR_LT threshold보다 작다. (<)

OPERATOR_NE threshold와 다르다 (<>, !=)


표 7-19

Threshold 연산자


3. object types (현재 지원되는 metrics는 그 list를 표시한다)

Object Type Description

OBJECT_TYPE_SYSTEM system level (대부분의 instance metrics)

OBJECT_TYPE_FILE file level

1. AVERAGE_FILE_READ_TIME,

2. AVERAGE_FILE_WRITE_TIME

OBJECT_TYPE_SERVICE service level

1. ELAPSED_TIME_PER_CALL

2. CPU_TIME_PER_CALL

OBJECT_TYPE_TABLESPACE tablespace level

1. TABLESPACE_PCT_FULL

OBJECT_TYPE_EVENT_CLAS

S

event class level

1. AVG_USERS_WAITING

2. DB_TIME_WAITING

OBJECT_TYPE_SESSION session level (instance level만 사용가능 즉, 이

metric은 object name을 지정하지 않는다)

1. BLOCKED_USERS

CF. 사실 이 package를 이용하여 설정하는 것은 매우 어렵다. 그 값을 확인하고

metric별로 warning 및 critical 값을 설정하는 것이 불편하기 때문이다. 다음에

설명하는 em을 통해 이 값을 설정하는 법을 확인하기 바란다. (em을 이용하는 것이

훨씬 쉬울 것이다)

7.6.4.2. Alert 확인 및 Threshold 조절 (Using em)

1. 다음은 em을 통해 초기 database control 화면(“홈”tab)에 있는 alerts를

확인하는 것이다. (사실 최초 login시 나타나는 이 화면에서 앞서 설명한 server의

alert_que에 있는 내용들이 포함된다)


표 7-20

설정가능한

Object


빨갛게 표시된 box에 alerts의 내용들이 나타난다.

2. 다음은 위 화면의 하단에 있는 “측정 단위 관리”를 선택하여 현재 metric과

threshold를 확인하는 화면이다.

여기서 좌측의 metrics과 우측의 operator 및 warning, critical value를 확인할 수

있다.

3. 다음은 위 화면에서 우측의 “임계값 편집”을 선택하여 원하는 값을 설정하는

화면이다. (앞서 설명한 dbms_server_alert package를 사용하는 것 보다 훨씬 쉽다)


그림 7-26

Alert와 Threshold

그림 7-28

Threshold 설정

그림 7-27

Threshold 확인


4. 다음은 위 화면에서 multiple threshold의 설정이 필요한 경우이다. 원하는 metric

을 선택한 후 위 화면 우측의 “다중 임계값 지정”을 선택하면 된다.

예를 들면 위와 같이 tablespace별로 threshold의 값을 다르게 주는 경우가 다중

임계값 설정이 될 수 있다.

5. 사용자가 원하는 경우 em을 사용한다는 전제아래 위 3번 화면의 우측 “측정 단위

스냅샷에서 임계값 복사”를 선택하면 snapshot에서 설명했던 baseline을 선택하여 그

값을 threshold로 적용할 수 있다. 이는 현재 em에서만 지원한다.

6. 다음으로 특정 metric의 상황을 분석해서 보여주는 화면을 보자. 예를 들어 위 1

번에서 보여준 alert중 archive destination의 점유에 관심이 있다면 해당 alert를

click하면 아래와 같은 화면을 볼 수 있다.


그림 7-30

Alert와 링크

그림 7-29

Multiple Threshold 설정


물론, metrics을 확인하는 어떤 화면에서도 원하는 metric의 link을 선택하면 해당

화면으로 이동된다. 예를 들면 위 1번 화면의 하단에 있는 “모든 측정 단위”를 선택하여

list된 metric중 관심 metric을 선택해도 마찬가지라는 뜻이다. 아래 화면은 “모든 측정

단위”를 선택하여 그 중에서 archive destination의 사용량을 KB로 표시한 metric을

click한 화면이다.

7. 마지막으로 notification과 관련하여 여러분이 em을 운영하는 서버에서 SNMP

메일이 가능하다면 다음과 같은 절차를 통해 e-mail notification을 할 수 있다.

찾아가는 절차는 다음과 같다. 먼저 “관리” tab 우측의 Enterprise Manager 관리의

“관리자” 좌측 메뉴에서 “통지 방법”을 선택하여 각자의 환경에 맞게 설정하면 된다.


그림 7-31

Metric과 링크

그림 7-32

Alert Notification


CF. 그러나 지금 보여주는 em도 무리한 한글번역으로 인해 metric의 이름을 찾아가는

것이 그다지 쉽지만은 않다. 필자가 가급적 oracle이 제공하는 본래의 용어를 자주

언급하며 그대로 사용하고자 하는 것도 무리한 한글화가 너무 주관적이어서

사용자에게 혼란을 주기 때문이다. 다시 한번 언급하지만 영어로 보길 원한다면

chapter 1의 “Explorer에서 Language(언어) 문제”부분을 확인하라.

7.6.4.3. Alert Message 확인 (Manually)

Alert를 직접 받기 위해서는 oracle8에서 소개되어 사용되고 있는 advanced

queuing feature를 활용해야 한다. 일반적인 절차는 다음과 같다.

1. agent 생성 : dbms_aqadm.create_aq_agent

2. subscriber 등록 : dbms_aqadm.add_subscriber

3. 권한부여 : dbms_aqadm.enable_db_access,

dbms_aqadm.grant_queue_privilege

4. dequeue : dbms_aq.dequeue

5. message 받기 : dbms_server_alert.expand_message

다음은 위 절차를 sys 계정으로 접속한 후 그대로 수행하여 system 계정으로 alert

message를 보는 과정이다.

SYS> exec dbms_aqadm.create_aq_agent(agent_name => 'USRMON_AGT');


SYS> exec dbms_aqadm.add_subscriber(queue_name => 'ALERT_QUE', -



> subscriber => aq$_agent('USRMON_AGT', '', 0));


SYS> exec dbms_aqadm.enable_db_access(agent_name => 'USRMON_AGT',

-

> db_username => 'SYSTEM');


SYS> exec dbms_aqadm.grant_queue_privilege(privilege => 'DEQUEUE', -

> queue_name => 'ALERT_QUE', grantee => 'SYSTEM', grant_option =>

FALSE);


SYS> conn system/manager

Connected.

SYSTEM> !cat get_alert.sql

declare

u_dequeue_options dbms_aq.dequeue_options_t;

u_message_properties dbms_aq.message_properties_t;

u_message alert_type;

u_message_handle raw(16);

begin

-- specify agent

u_dequeue_options.consumer_name := 'USRMON_AGT';

-- no lock while read the message(means select)

u_dequeue_options.dequeue_mode := dbms_aq.browse;

-- retrive first message and reset the poition to the beginning

u_dequeue_options.navigation := dbms_aq.first_message;

-- do not wait for message

u_dequeue_options.wait := dbms_aq.no_wait;



dbms_aq.dequeue(queue_name => 'SYS.ALERT_QUE',

dequeue_options => u_dequeue_options,

message_properties => u_message_properties,

payload => u_message,

msgid => u_message_handle);

-- print the alerts message

dbms_output.put_line('Dequeued alert message');

dbms_output.put_line('O_ID : ' || u_message.organization_id);

dbms_output.put_line('C_ID : ' || u_message.component_id);

dbms_output.put_line('MSG Type : ' || u_message.message_type);

dbms_output.put_line('MSG Group : ' || u_message.message_group);

dbms_output.put_line('MSG Level : ' || u_message.message_level);

dbms_output.put_line('Host ID : ' || u_message.host_id);

dbms_output.put_line('Host Network Addr : ' || u_message.host_nw_addr);

dbms_output.put_line('Reason: ' ||

dbms_server_alert.expand_message(userenv('LANGUAGE'),

u_message.message_id, u_message.reason_argument_1,

u_message.reason_argument_2, u_message.reason_argument_3,

u_message.reason_argument_4, u_message.reason_argument_5));

dbms_output.put_line('SEQ : ' || u_message.sequence_id);

dbms_output.put_line('Reason ID : ' || u_message.reason_id);

dbms_output.put_line('OBJ Name : ' || u_message.object_name);

dbms_output.put_line('OBJ Type : ' || u_message.object_type);

dbms_output.put_line('Inst Name : ' || u_message.instance_name);

dbms_output.put_line('Suggested : ' ||

dbms_server_alert.expand_message(userenv('LANGUAGE'),

u_message.suggested_action_msg_id, u_message.action_argument_1,

u_message.action_argument_2, u_message.action_argument_3,

u_message.action_argument_4, u_message.action_argument_5));

dbms_output.put_line('Advisor : ' || u_message.advisor_name);

dbms_output.put_line('Scope : ' || u_message.scope);

end;

/



SYSTEM> set serveroutput on

SYSTEM> @get_alert

Dequeued alert message

O_ID : oracle.com

C_ID : SMG

MSG Type : Warning

MSG Group : Performance

MSG Level : 5

Host ID : LIRACLE

Host Network Addr : 127.0.0.1

Reason: Metrics "Database Time Spent Waiting (%)" is at 59 for event class

"Commit"

SEQ : 1092

Reason ID : 121

OBJ Name : Commit

OBJ Type : EVENT_CLASS

Inst Name : NEWSVC

Suggested : Run ADDM to get more performance analysis about your

system.

Advisor : ADDM

Scope : Instance


원래의 상태로 돌아가기 위해서는 다음과 같은 반대의 procedure를 사용하면 된다.

(직접 테스트 해보라)

SQL> exec dbms_aqadm.disable_db_access('USRMON_AGT','SYSTEM');

SQL> exec dbms_aqadm.remove_subscriber('SYS.ALERT_QUE', -

aq$_agent('USRMON_AGT','',0));



OCP point

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

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

1. alert관련 view dba_alert_history, dba_outstanding_alerts의 의미

2. tablespace의 default 임계치(threshold level)

3. out-of-box alert의 종류

참조

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

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

resumable session suspended : o9i 98p, o9i 107



7.7. Cost & Optimizer

7.7.1.Query Optimization

Oracle8i까지는 query cost를 추측할 때 I/O를 사용했었고 oracle9i는 CPU 중심의

cost과 CPU만 사용하는 cost 두 가지를 소개했다. 이제 oracle10g는 CPU와 I/O를

함께 사용하는 것을 default로 적용한다. Oracle10g의 optimizing과 관련한 변화를

다시 정리하면 다음과 같다.

1. 통계를 취합할 때 보다 정확한 방식인 dynamic sampling이 default로 적용된다.

이는 initial parameter “optimizer_dynamic_sampling”의 값이 2로 설정되면서

이루어진다. (oracle9i에서는 이 값이 1이었다)

2. CPU + I/O정보를 함께 사용한다.

3. plan_table에 time column이 추가된다.

4. CPU 통계는 instance가 start될 때 capture된다.

5. default로 PGA관리를 해준다. 즉, pga_aggregate_target의 설정이 default로

자동화 되어 있다.

이제 PGA 자동관리 를 위해 parameter를 수정한 후 database를 다시 start 해보자.

PGA의 자동관리는 parameter pga_aggregate_target을 직접 0으로 설정하거나

workarea_size_policy parameter를 직접 “MANUAL”로 설정하지 않는 한 default로

자동 적용되며 초기 값은 SGA의 20%를 할당한다.

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

../admin/NEWSVC/pfile/initNEWSVC.ora

…

…

# -------------------------- Memory and I/O 관련 parameters ------------------------

...

## Shared and other pools

#shared_pool_size = 150944944 # for 10g

#java_pool_size = 50331648 # for 10g

#large_pool_size = 5242880 # 5M

## PGA, Sort, Hash Joins, Bitmap Indexes and others

#pga_aggregate_target = 104857600 # 100M

#workarea_size_policy = AUTO

…



…

~

~

~

~

:wq!


위에서 굵게 표시된 두 parameter를 remark하였다. 이제 database를 restart하자.


SQL*Plus: Release 10.1.0.4.0 - Production on Fri Aug 26 17:41:10 2005


Connected to:




Database closed.



SYS> startup







Database mounted.

Database opened.

SYS>



정상적으로 instance가 start되었다. PGA의 변화를 확인해 보자.

SYS> col name for a30

SYS> col value for a20

SYS> select name, value from v$parameter

2 where name in ('pga_aggregate_target', 'workarea_size_policy');

NAME VALUE

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

pga_aggregate_target 94791270

workarea_size_policy AUTO

SYS> select 94791270/1024/1024 from dual;

94791270/1024/1024

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

90.3999996

SYS> select 473956352/1024/1024 from dual;

473956352/1024/1024

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

452

PGA의 값으로 설정된 memory size와 SGA 전체 memory size를 비교해 보라. 거의

정확하게 SGA의 20%를 기본 PGA size로 시작하고 있다.

7.7.2.확장된 Statistics

7.7.2.1. Dictionary를 위한 통계Oracle10g는 oracle internal하게 사용되는 dictionary에 대한 통계수집을 해야

한다. 이를 바탕으로 최적의 성능을 이끌어낼 수 있기 때문이다. 물론, dbms_stats

package를 통해 수집을 할 수 있고 fixed tables과 data dictionary의 두 가지로

나누어진다. 다음은 이 통계들을 수집하기 위한 방법들이다.

1. dbms_stats.gather_[database|schema]_stats procedure의 argument로



조절할 수 있다.

다음은 database내 모든 objects를 대상으로 통계를 수집하는 예이다. 여기서

argument로 gather_sys의 값을 true로(default false) 하면 통계를 수집함과 동시에

sys 소유의 objects에 대한 통계도 같이 취합되고 gather_fixed의 값을 true로 하면

fixed tables에 대한 통계도 수집된다.

SQL> exec dbms_stats.gather_database_stats(gather_sys => TRUE, gather_fixed

=> TRUE);

다음은 schema를 대상으로 통계를 수집하면서 fixed tables에 대한 통계를 수집하는

예이다. (schema 대상에는 dictionary 즉, gather_sys argument는 없다)

SQL> exec dbms_stats.gather_schema_stats('SYS', gather_fixed => TRUE);

CF. 위 두 procedures를 사용하기 위해서는 sys 사용자로 login을 하든지(sysdba

권한) 아니면 “ANALYZE ANY” privilege가 있어야 한다.

2. 다음은 각각 독립된 procedure를 사용하는 방법이다.

먼저 dictionary에 대한 통계를 수집하는 procedure이다. 이 procedure는 sys,

system 및 각종 rdbms components schema들에 대한 통계를 수집한다.

SQL> exec dbms_stats.gather_dictionary_stats;

다음은 dynamic performance tables(fixed tables)에 대한 통계를 수집하는

procedure이다.

SQL> exec dbms_stats.gather_fixed_objects_stats;

CF. 위 procedure를 사용하기 위해서는 sys 사용자로 login을 하든지(sysdba 권한)

또는 “ANALYZE ANY DICTIONARY” privilege가 기본적으로 필요하며 특히, 첫 번째

소개한 gather_dictionary_stats procedure는 추가적으로 “ANALYZE ANY”

privilege도 있어야 한다.

3. 일반적으로 dictionary 와 fixed objects에 대한 통계를 추출하는 것은 보통 다음과

같은 방식을 사용한다. (아래 설명은 가장 보편화된 방식임으로 여러분도 이와 같은

방식을 사용할 것을 추천한다)

3.1 dictionary objects는 앞서 위 2에서 설명한 gather_dictionary_stats을

사용하거나 아니면 gather_database_stats의 argument “options”의 값으로

“GATHER AUTO”를 주어 자동으로 취합할 수 있다. 일반적으로 1회 통계수집으로

충분하지만 database 운영 중에 발생하는 DDL로 인해 dictionary의 변화가 상당히

발생했다고 판단되면 다시 한번 취합하는 것을 원칙으로 한다.

SQL> exec dbms_stats.gather_database_stats(options => ‘GATHER AUTO’);



CF. oracle관련 문서에 따르면 procedure를 “gather_schema_stats(‘SYS’)”처럼

call해도 같은 위와 같이 dictionary 통계를 취합하는 효과가 있는 것으로 설명을 하고

있으나 procedure gather_schema_stats의 oracle internal 통계수집과 관련한

arguments는 fixed tables의 통계를 취합하는 gather_fixed 밖에 없고 이것도

default가 FALSE이다. 따라서 이 procedure를 통한 dictionary 정보의 취합은

논리적으로 잘 이해할 수가 없다는 점을 지적하고 싶다. 여러분은 알고 있어야 할

것이다.

3.2 다음으로 fixed objects에 대한 통계는 운영중인 database의 가장 일반적인

workload의 상태에서 sys 계정으로 접속하여 다음과 같이 수행한다. 보통 1회

작업으로 충분하지만 운영중인 database의 workload가 크게 변했다고 판단되었을

때는 다시 한번 취합하는 것을 원칙으로 한다. 아래 argument 값 “ALL”은 내부적으로

사용되는 database의 전체 fixed tables 통계취합을 의미한다.

SQL> exec dbms_stats.gather_fixed_objects_stats(‘ALL’);

CF. 위 내용을 도식화 하면 다음과 같다.



7.7.2.2. 통계 수집의 New Values

통계 package dbms_stats의 적절한 사용을 위해 즉, 통계 수집의 최적화를 위해

사용하는 gather_*_stats의 주요 arguments인 다음의 두 가지 값의 의미를 확인해

보자.

1. GRANULARITY의 option들은 다음과 같은 원칙을 갖는다(이 값의 default는

oracle10g부터 “auto”이며 이전에 사용되던 “default”는 더 이상 사용하지 않는다)

Values Description

ALL 모든 통계를 수집(subpartition, partition, and global)


그림 7-33

System 통계와 권한

표 7-21

통계수집의 Option


AUTO Orcle10g의 new default이며 partition type에 따라 다르게

수집(subpartition이 LIST이면 global, partition 및

subpartition 통계를 그렇지 않으면 global 및 partition

통계를 수집)

GLOBAL global 통계를 수집

GLOBAL AND PARTITION subpartition의 유무와 상관없이 global, partition 통계를

수집

PARTITION partition 통계를 수집

SUBPARTITION subpartition 통계를 수집

CF. 과거 사용하던 “DEFAULT”라는 option은 obsolete되었고 이 값은 “GLOBAL AND

PARTITION”과 같다.

2. DEGREE의 값으로 oracle10g부터 “auto_degree”가 추가되었다. 이 argument

값들의 의미를 살펴보자.

Values Description

? 사용자가 지정하는 값을 적용

NULL default로 적용되며 table에 설정된 degree 값을 적용

DEFAULT_DEGREE CPU의 수와 initial parameter의 값을 기준으로 설정되는

system default값을 적용

AUTO_DEGREE oracle이 스스로 판단하되 대상 object의 size에 따라 1 또는

default_degree를 적용

CF. 여러분이 특별하게 dbms_stats를 통한 통계수집의 적절한 방법을 가지고 있지

않다면 granularity의 default “auto”와 degree의 새로운 값 “auto_degree”를

사용해 보기 바란다.

7.7.3.Optimizer Mode의 변화Oracle10g는 더 이상 RBO(Rule Based Optimizer) mode의 optimizer를 지원하지

않는다. 이 말은 곧 initial parameter optimizer_mode의 값에 변화를 준다. RBO가

더 이상 유효하지 않음으로(오직 CBO만 사용함으로) 이 parameter의 값으로

“CHOOSE”나 “RULE” 모두 사용하지 않는다는 의미가 된다. 이 값의 default는

“all_rows”로 설정된다. 뻔한 이야기지만 oracle10g가 통계정보의 수집을 자동화했기

때문에 이러한 변화는 당연한 것이다.

CF. 여러분이 여전히 “CHOOSE”, “RULE” 혹은 rule hint를 사용한다고 error가

return되지는 않는다. 그 기능들은 내부적으로 존재하지만 oracle10g부터는 이러한



optimizer의 판단에 따른 bug나 새로운 기법 등을 전혀 제공하지 않으며 차후 version

에서는 아예 사라질 것이다. (desupported values)

다음은 현재의 optimizer mode를 system level에서 수정한 예이다. 현재 필자가

테스트하는 database는 oracle9i시절에 사용하던 optimizer mode가 choose인

상태에서 migration하였기 때문에 이를 다음과 같이 수정한다.

SYS> alter system set optimizer_mode=all_rows;

System altered.

물론, 여러분은 각자 사용하는 initial parameter file(혹은 spfile)에서도 적절하게

수정해야 한다.



OCP point

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

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

1. PGA관리 자동화 개념

2. dictionary 통계 수집방법

3. dbms_stats을 통한 통계자료 수집 시 GRANULARITY option의 의미

참조

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

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

PGA 자동관리 : o9i 327p

pga_aggregate_target, workarea_size_policy : o9i 328p



7.8. Support SQL Tuning

7.8.1.Optimizer를 통한 SQL Tuning 자동환

7.8.1.1. Tuning을 위한 Enhanced Optimizer

DBA가 많은 시간을 할애하는 application tuning에서 가장 흔하고도 반복적인 작업은

개별 SQL에 대한 tuning이다. 이 작업은 또한 DBA의 skill에 따라 다르고 database

환경에 따라 다르기도 하다. Oracle10g가 제공하는 SQL tuning의 자동화 개념은

앞서 소개했던 “SQL Tuning Advisor”를 통해 이루어진다. 정리하면 high load SQL에

대한 detect(감지)를 통해 해당 SQL을 tuning하기 위하여 (oracle10g에서 더욱

강화된)optimizer를 tuning mode로 전환 후 해당 SQL에 대한 추가적인 분석을

실시하는 것이다. 이 때의 optimizer mode를 tuning mode 혹은 ATO(Automatic

Tuning Optimizer)라 한다. (따라서 평상시의 optimizer mode는 normal mode라

부른다) “SQL Tuning Advisor”는 바로 tuning mode로의 access 경로라 할 수 있다.

다음은 tuning mode와 optimizer의 역할에 대한 비교표이다.

Optimizer Mode Actions

normal mode 1. SQL compile

2. execution plan 생성

tuning mode 1. normal mode에서 생성된 plan의 향상 가능성 분석

2. tuning을 위한 조치사항들을 제안

7.8.1.2. DBA SQL Tuning과 Advisor

누구나 인지하고 있지만 다시 한번 SQL tuning을 정의해 보자. 일반적으로 SQL을

tuning한다 함은 문제가 있는 SQL을 찾아내고 그 SQL에 대한 optimizer의

execution plan을 검증하여 보다 낳은 execution plan을 만듦으로써 성능을

향상하는 작업이다. 이러한 성능향상의 과정들은 보통 다음과 같은 종류의 작업들로

이루어진다.

1. optimizer의 적절한 판단을 위해 통계를 수집 또는 수정하는 작업

2. optimizer_mode와 같은 parameter 값을 적절하게 설정하는 작업

3. SQL의 구성을 변경하는 즉, SQL을 적절하게 rewrite하는 작업

4. index, MView등과 같이 table에 access하는 object를 적절하게 생성 혹은 drop

하는 작업

5. table scan방식에 변화를 주기 위하여 optimizer hints를 지정하는 작업

위와 같은 작업들은 그다지 쉬운 것이 아니다. 사실 간단한 문제들은 tuning의 대상이

되기 이전에 이미 해결이 되는 경우가 대부분이고 그 외의 것들이 항상 숙제로 남아


표 7-22

Optimizer Mode


DBA의 능력을 시험대에 오르게 하기 때문이다. Oracle10g는 이러한 일련의 manual

tuning 작업의 어려움을 극복할 수 있도록 도와주는 features를 소개하고 있다.

Oracle10g는(앞서도 설명했지만) ADDM을 통해 문제가 예상되는 SQL을 감지하여

DBA에게 보여주고 이를 advisor와 연결하여 automatic tuning을 지원하는 일련의

체계를 가지고 있다. 이는 다른 자동 tuning features와 마찬가지로 Top-Down(Drill

방식)형식의 접근을 가능하게 함으로 DBA에게 많은 도움을 줄 수 있도록 SQL tuning

advisors를 제공한다. 그러나 자주 변화하고 배포되는 새로운 application나 SQL은

SQL workload를 끊임없이 변화시키기 때문에 계속적으로 반복되는 감시와 tuning은

여전히 매우 중요하며 많은 resource들(CPU, I/O, temporary space등)을 점유하는

SQL을 판단하는 것 역시 DBA의 주요 관심사가 되어야 한다.

SQL tuning advisor는 SQL을 input으로 받아서 다음과 같은 결과물을 생산한다.

1. execution plan을 어떻게 optimizing해야 하는가

2. advisor가 제안을 하는 이유는 무엇인가

3. 성능측면의 이점들을 측정한 결과

4. advisor의 제안을 구현할 command

CF. tuning mode에서 optimizer의 SQL에 대한 분석은 적지 않은 시간을 소요하게

된다. 따라서 tuning에 필요한 SQL을 감지하여 선택적으로 분석하는 능력과 advisor

가 제시하는 action에 대한 해독능력 또한 DBA의 주요 능력이 될 것이다. 이런

기능들을 종합해서 판단해 볼 때(필자가 보기엔), 적어도 이러한 종류의 oracle10g의

새로운 기능들은 DBA를 편하게 해주기는 하지만 전문성이 부족한 DBA를 눈감아주는

것은 아니라고 생각된다.

7.8.2.SQL Tuning Advisor

SQL tuning advisor는 optimizer를 ATO로 invoke하여 필요한 분석을 수행하게 하는

driver와 같은 역할을 한다. 여기에서 분석하는 내용들은 다음과 같이 크게 4가지로

구분되는데 통계분석, SQL Profile, Access 경로분석, SQL 구조분석이 그것이다. 이제

그 각각의 의미와 쓰임새에 대해 알아보자.

7.8.2.1. 통계분석 (Statistics Analysis)

이 작업은 query의 대상이 되는 objects의 통계 값이 잘못되거나 빠진 것이 없는가를

검증하는 부분이다. 이 작업에서 ATO는 스스로 sampling한 data를 이용하여 현재

존재하는 통계 값들을 검증하고 다음의 두 가지 유형의 결과물을 생성한다.

1. 문제가 있는(missing(no statistics) or stale(실효성이 없는) statistics를 가진)

objects에 대하여 적절한 통계 수집의 필요성을 권고



2. 권고사항이 이행되지 않는 경우 이를 보완하기 위해 통계자료의 형태로 보조정보

(auxiliary information)를 생성 (이 data는 다음에 설명하는 SQL profile에

저장된다)

DBA는 위 작업 권고사항에 따라 적절한 시점에 통계수집을 다시 수행할 필요성이

있는가를 판단해야 한다. 그리고 필요하다면 통계수집을 다시 한 후에 해당 SQL에 대한

분석을 다시 수행할 필요가 있는지를 결정한다.

CF. ATO는 dynamic sampling을 사용한다.

7.8.2.2. SQL Profile

이 단계에서는 optimizer가 판단하고 있는 대상 SQL의 비용, 선택성, cardinality를

검증하게 된다. ATO의 이런 작업은 optimizer estimates(optimizer가 SQL을

분석하여 측정하고 판단한 결과)의 정확도를 검증하고 오류의 가능성을 제거하거나

줄여준다.

이 검증작업은 ATO가 dynamic sampling을 통해 생성한 새로운 estimate와 원래의

estimate를 비교하여 차이가 크다면 원래의 estimate에서 수정할 부분을 만들어내는

sampling method와 대상 SQL을 나누어 수행하여 estimate를 검증하는 partial

execution method가 있다. Oracle은 스스로 적절한 method를 선택하게 되는데

만일, partial execution의 개별 access paths가 효율적이면 sampling method보다

partial execution method가 더 효과적일 수 있다.

ATO는 통계분석 단계에서(또는 이 단계에서) 보조정보(auxiliary information)가

생성되었으면 SQL profile을 build하고 profile을 만들기 위해 사용자를 위한

권고사항을 만든다.

CF. ATO의 검증작업에서는 대상 SQL의 과거 execution history를 살펴보고 적절한

optimizer mode의 설정을 결정할 수도 있다.

이렇게 ATO가 진행되는 동안 생성되는 auxiliary information이 모아지면 이

정보들이 SQL profile이라는 이름으로 저장된다. 우리가 access하는 통계 값들이

table이나 index로부터 계산되는 것처럼 SQL profile은 문제가 되는 SQL

문장으로부터 만들어지기 때문에 이 profile은 매우 중요한 역할을 할 수 있다.

이 profile의 결과가 DBA가 받아들일 수 있다고 판단되면 그 때 data dictionary로



저장되고 일반 사용자가 종전과 다름없이 해당 SQL(혹은 application)을 call할 때

optimizer는 대상 SQL을 compile하면서 이미 만들어진 profile을 사용하게 된다. 그

결과 잘 tuning된 execution plan으로 SQL이 수행될 수 있는 것이다. 이 점이 매우

중요한 이유는 사용자는 어떤 변경도 없이 동일한 작업을 하고 application의 변화도

없지만 성능의 향상이 이루어질 수 있기 때문이다.

CF. 그렇다면 이 기능은 어떤 경우에 가장 효과적일까. 여러 유형의 database를

관리해본 사람이면 package로 들여온 system에서 문제가 발생하고 있는

application code를 잡아내고(detect) 이를 수정하고자 했던 경험이 있을 것이다.

이런 package 형태의 system을 tuning하기는 쉽지가 않다. 이제 여러분은

oracle10g를 이용하여 package내 SQL의 최적화된 tuning plan을 만들어보시기

바란다.

CF. 이는 마치 oracle8i에서 소개된 stored outline을 연상케 한다.

물론, profile이 만들어진다고 해도 index의 추가 또는 삭제, table size의 변화 등에

따라 plan이 변경될 수도 있다. 그러나 database에 매우 큰 변화가 생기거나 오랫동안

누적된 변화로 인해 발생하는 예기치 못한 상황이 발생하면 이 profile의 data도 다시

refresh할(new profile로 다시 만들) 필요가 있다. 이쯤 되면 ADDM에 의해 해당 SQL

이 다시 bad SQL로 나타날 것이다. 역시나 반복적인 tuning이 항상 중요함을 잊지

말자.

다음은 현재 설명한 profile과 optimizer의 처리를 도식화한 것이다.


그림 7-34

Optimizer와 SQL Profile


7.8.2.3. SQL Access Advisor : 접근경로 분석(Access Path

Analysis)

SQL을 tuning하는데 있어서 full table scan의 영향을 해소하기 위해 필요한 index를

사용하는 것은 매우 쉽고도 빠르게 성능을 향상시키는 주요 포인트다. 따라서 어떤

index가 필요한 가를 분석해서 찾아내는 것도 DBA의 주요임무중의 하나이다. ATO의

또 다른 분석인 access path analysis는 이제 이런 작업시간을 줄여준다. ATO가

스스로 판단하여 어떤 index가 필요한지를 recommend해주기 때문이다. (이 기능은

SQL tuning advisor와 연동하여 SQL access advisor를 통해 이루어진다)

CF. ATO의 access path분석은 필요한 index에 대한 권고 혹은 전체적인 분석을 위해

SQL access advisor를 수행할 것을 권고하게 된다.

하지만 이런 index에 대한 분석은 database 전반에 걸쳐 전체 SQL workload

상황에서 분석하는 것이 아니기 때문에 새로운 index 사용으로 인한 영향이 다른

부분에 걸쳐서 악영향을 줄 수도 있는지는 판단하지 못한다. 그렇기 때문에 제대로

access advisor를 사용하기 위해서는 현재 운영하는 database의 대표적인 SQL

workload에서 분석을 하는 것이 중요할 수 있다. 이렇게 되면 access advisor는

workload 전반에 걸쳐서 통합된 recommend를 해 준다.

CF. 이미 AWR은 workload 정보를 가지고 있음으로 access paths분석을 할 때

필요하다면 대표적인 시간대의 workload를 지정하여(나중에 설명이 되지만 SQL

Tuning Set을 만들어 사용한다) 분석을 수행할수록 보다 정확한 정보를 얻을 수 있다.

7.8.2.4. SQL 구조 분석(Structure Analysis)

DBA는 SQL을 tuning할 때 먼저 그 구조를 파악하게 된다. 물론, 간단할 수도 있지만

대부분 data의 성격을 제대로 알면 SQL의 내용은 바꾸지 않고 형식의 변화만 주어도

상당한 효과를 보는 경우가 많다. 가장 대표적인 것이 where절의 column에 대한 type

변경 function으로 인해 index를 사용하지 못하거나 불필요한 “union”절의 사용 혹은

불필요한 “not in”등을 사용하는 경우이다. 사실 이런 문제들은 type의 변환을

column이 아닌 값으로 “union”대신 “union all”절로, 그리고 “not in”대신 “not

exists”로 바꾸어도 효과를 볼 수 있는 경우가 있다. 물론, 출력되는 data에 대하여

지식이 있어야만 가능한 일이다.

ATO는 이런 유형의 문제들을 해결하기 위하여 SQL structure analysis를 소개하고

있다. 이 기능은 잘못 쓰여진 SQL을 감지하고 rewrite를 권고하는 기능이다. 말 그대로

권고이다. 즉, 자동으로 rewrite를 해주지는 않는다는 뜻이다. 왜냐하면 바로



언급했듯이 “union all”과 “union”, “not in”과 “not exists”가 비슷하기도 하지만

확실히 다른 결과를 줄 수도 있기 때문이다. 따라서 여전히 DBA는 관련 data에 대한

속성을 이해하고 있어야만 한다. 그렇지 않으면 이런 훌륭한 권고사항도 이해하지

못하고 넘어가는 수 밖에는 없다.

이를 정리해보면 다음과 같다.

1. 의미론적인 문제(semantic) : 앞서 예로 든 “union”과 “union all” 그리고 “not in”

과 “not exists”와 같은 것들이다.

2. 문법적인 문제(syntax) : 앞서 예로 든 column의 형 변환 function의 사용과 같은

것들이다. 또 한가지 예를 들자면 varchar2 type의 column A와 비교하기 위해

“where A = 5”와 같이 사용하게 되면 A는 index가 있더라도 to_number(A)로

변환이 될 것임으로 index를 사용하지 못하게 된다.

3. design의 문제 : 이는 SQL을 사용하는데 있어 발생하는 cartesian products와

같은 것들이다. SQL을 작성하면서 많은 수의 table을 join하는 경우 가끔씩 특정 table

을 join에서 제외하는 경우가 있는데 이런 경우를 뜻한다.

7.8.3.Tuning SQL (Using em)

7.8.3.1. SQL Tuning Set

앞서 설명한 바 tuning이 필요한 SQL을 input으로 하여 ATO를 가동하는 과정이 SQL

을 tuning하는 일반 절차이다. 그러나 대상이 되는 SQL은 매우 다양한 source로부터

추출될 수 있고 또한 하나 이상의 SQL을 묶어서 처리하는 것이 보다 효율 적이다.

그래서 oracle10g는 새로운 object인 STS(SQL Tuning Set)를 통해 특정 SQL들을

묶어서 저장해준다. 따라서 이 STS를 가지고 ATO를 가동하는 것이 합리적이다. STS는

각 SQL의 execution context(parsing schema, bind variables, application

module name과 action, cursor 환경), execution statistics(수행시간, CPU시간,

buffer gets, disk reads, rows processed, 수행횟수, 완전히 수행된 횟수, cursor

fetches, optimizer cost, command type)를 가지고 저장하며 다음과 같은 sources

로부터 추출될 수 있다.

1. ADDM에 의해 나타난 high load SQL

2. 현재 상태에서 추출되는 SQL

3. AWR에서 추출되는 SQL (snapshot이나 baseline을 사용할 수 있다)

4. 사용자 지정 SQL (사용자가 원하는 SQL을 가지는 custom workload를 만들어

사용할 수 있다. 따라서 이 경우에 나타나는 SQL는 AWR이나 ADDM에서 high load로

나타나지 않을 수도 있다)

따라서 보통 다음과 같은 절차를 통해 Automatic SQL tuning이 진행된다.



1. 다양한 source로부터 SQL을 추출

2. execution statistics를 가지고 추출된 SQL들을 filtering및 raking처리

3. 주요 SQL들을 묶어서 STS로 저장

4. SQL Tuning Advisor에게 tuning을 의뢰

5. tuning 결과를 분석하여 적용

CF. 물론, STS가 아닌 SQL을 input으로 개별적인 tuning도 가능하다. 다만 STS

object를 만드는 것은 여러 SQL들을 효율적으로 묶어서 tuning하기 위한 매우 좋은

방법이 될 수 있다.

7.8.3.2. Running SQL Tuning Advisor

다음은 ADDM을 통해 작업하는 방법이다. 아래 화면은 영어로 표현되는 em의 화면을

기준으로 삶는다. 현재까지는 한글로 된 화면이었으나 여러 한글명칭을 찾는데

불편함이 있어 이제 영어로 표현된 화면도 살펴보도록 하자.

“최초 database control Advisor Central SQL Tuning Advisor”의 화면이다.

이 화면에서는 SQL tuning advisor가 다양한 source로부터 접근이 가능하다는 것을

보여준다.

좌측에서 다양한 source를 선택할 수 있음을 알 수 있다. 먼저 Top SQL을 통해 접근해


그림 7-35

em SQL Tuning Advisor


보자.

위 화면에서 보듯이 주요 SQL들을 볼 수 있고 이를 복수로 선택하여 위 화면 하단

중앙의 “Run SQL Tuning Advisor”를 통해 직접 tuning을 수행할 수도 있고 “Create

SQL Tuning Set”을 통해 STS를 만들 수도 있다.

CF. 만일 여러분이 ADDM을 통해 그 분석결과를 가지고 SQL tuning advisor를

수행하려 한다면 다음과 같은 ADDM 분석결과 화면에서 바로 “Run SQL Tuning

Advisor”를 수행할 수 있다.


그림 7-36



7.8.3.3. STS 생성위 Top SQL 화면에서 몇 개의 SQL을 가지고 STS를 만들어 보자. 다음과 같이 주요

SQL을 선택해 보자.

STS 생성 버튼을 누르면 다음과 같다.


그림 7-37


그림 7-38

SQL Tuning Set 설정

그림 7-39

SQL Tuning Set 생성


원하는 STS의 이름과 설명을 입력하고 OK를 선택한다.

STS가 잘 생성되었다. 위 화면 우측 하단을 보면 선택한 STS를 가지고 SQL Tuning

Advisor를 수행할 수 있는 버튼이 있음을 알 수 있다. 또한 그 옆에는 앞서 설명했던

SQL Access Advisor를 수행할 수 있는 버튼도 있음을 알 수 있다.

7.8.3.4. Tuning Result

지금까지는 앞서 설명한대로 여러 유형의 sources를 가지고 tuning을 할 수 있는

방식을 살펴보았다. 위와 같이 em을 사용하면 쉽게 tuning 접근이 가능하기 때문에

사용자는 tuning 결과만 잘 해독할 수 있으면 된다. 물론, 이런 방식들은 사실은

oracle10g가 제공하는 package dbms_sqltune을 내부적으로 사용하고 있고 직접 그

package를 사용하는 불편함을 em이 대신 해준다고 보면 된다.

다음은 위 STS화면에서 “Run SQL Tuning Advisor”버튼을 통해 SQL tuning을

실시하여 그 결과를 본 화면이다.


그림 7-40

SQL Tuning Set 생성


상단에는 분석대상이 되는 SQL이 나오고 하단에는 다음과 같은 화면을 볼 수 있다.

위 화면에서 scope의 “Limited…”는 앞서 설명한 ATO가 실시하는 각종 분석작업을

통해 tuning을 하겠다는 의미이고 “Comprehensive…”는 “Limited…”에 추가적으로

SQL Profile을 만들겠다는 뜻이다. 그리고 하단의 schedule은 지금 tuning을 실시할

것인지 아니면 시간을 지정하여 차후에 적절한 시간에 schedule을 통해 수행할

것이라는 의미이다. 일단 위와 같이 default 상태에서 tuning을 실시해보자. 우측

하단의 “OK”버튼을 눌러보자.


그림 7-41

SQL List

그림 7-42

SQL Tuning Option


이제 위 화면에서 원하는 SQL을 선택한 후 “View Recommendations”을 선택하자.

위 화면은 tuning 결과를 보여준다. 그러나 SQL문에 따라 tuning을 할만한 것이

없다고 판단을 하는 경우에는 “There is no recommendation”이라는 message가

출력이 되고 위처럼 추천사항이 있을 경우에는 간략하게 그 내용이 설명된다. 위의 경우

SQL Profile을 받아들일 것을 권고하고 있다. 필요하다면 우측 중앙의 “Implement”

버튼을 통해 권고사항을 받아들여 SQL Profile을 생성할 수 있다.

7.8.4.SQL Tuning Package (Manually)

앞서 잠깐 언급이 되었지만 oracle10g가 제공하는 package dbms_sqltune은 이

모든 tuning 절차에서 내부적으로 사용되는 매우 중요한 package다. 사실 em만 잘

사용하면 굳이 이 package를 몰라도 되겠지만 적어도 관리자라면 이 package의

사용법 정도는 알고 있어야겠다.


그림 7-43

SQL Tuning 결과

그림 7-44

SQL Tuning 추천결과


제일 먼저 할 일은 SQL tuning을 위한 task를 생성하는 일이다. 이 작업은 sub

function으로 제공되는 create_tuining_task를 사용한다. 모두 4가지 형식을 가지고

있는데 SQL문장을 직접 입력하는 방법과 SQL ID를 입력하는 방법, snapshot id를

입력하거나 SQL tuning set을 입력하는 방법이 그것이다. 두 가지 방법을 테스트

해보자.

7.8.4.1. Using Snapshot ID

여기서는 snapshot id를 지정하는 방법을 살펴보겠다. 먼저 원하는 snapshot id와

예측되는 SQL의 id를 찾아보자.

SYSTEM> col snap_start for a20

SYSTEM> select * from ( select snap_id,




SNAP_ID snap_start

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

1739 20050905 14:00:16

1738 20050905 13:01:03

1737 20050905 12:00:45

1736 20050905 11:00:31

1735 20050905 10:00:50

1734 20050905 09:00:25

1733 20050905 08:00:46

1732 20050905 07:00:13

1731 20050905 06:00:49

9 rows selected.

SYSTEM> col txt for a30

SYSTEM> col last_load_time for a20

SYSTEM> select substr(sql_text, 1, 30) txt, sql_id, last_load_time

2 from v$sql

3 where parsing_user_id = (select user_id from dba_users where username =

'SCOTT')

4 and last_load_time like '2005-09-05/13%';



TXT SQL_ID LAST_LOAD_TIME

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

select /*+ full(emp2) */ coun bf5f7vu28nx3f 2005-09-05/13:49:57

select /*+ full(a) */ count(* 7 dkctrmh091nv 2005-09-05/13:50:16

select /*+ full(emp2) */ count 0h266g57x5cm1 2005-09-05/13:48:29

select /*+ full(a) */ count(* 3 cmmnb64n5rwq 2005-09-05/13:52:26

select /*+ full(emp2) */ count bsdw95t4gyp6j 2005-09-05/13:48:04

위 정보들을 가지고 stand, end snapshot과 tuning의 필요성이 있는 SQL ID를

입력하여 tuning 절차를 수행해 보자.

SYSTEM> var task_id varchar2(100)

SYSTEM> exec :task_id := dbms_sqltune.create_tuning_task(1738, 1739,

'bsdw95t4gyp6j');


SYSTEM> print :task_id

TASK_ID

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

TASK_1831

SYSTEM> exec dbms_sqltune.execute_tuning_task(task_name => :task_id);


SYSTEM> set long 10000

SYSTEM> select dbms_sqltune.report_tuning_task(:task_id)

2 from dual;

DBMS_SQLTUNE.REPORT_TUNING_TASK(:TASK_ID)

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

GENERAL INFORMATION SECTION

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



SYSTEM> set long 1000000 pagesize 0 longchunksize 1000


2 from dual;


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

Tuning Task Name : TASK_1831

Scope : COMPREHENSIVE

Time Limit(seconds): 1800

Completion Status : COMPLETED

Started at : 09/05/2005 15:13:12

Completed at : 09/05/2005 15:13:12

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

SQL ID : bsdw95t4gyp6j

SQL Text: select /*+ full(emp2) */ count(*) from emp2

where emp_id > :"SYS_B_0"

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

There are no recommendations to improve the statement.

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

위에서 보듯 제대로 tuning 절차를 수행했지만 적절한 recommend 사항이 없는

것으로 나타나고 있다.

7.8.4.2. Using STS

이제 앞서 em에서 활용해 보았던 SQL Tuning Set(STS)를 이용해 보자. 일단 앞서

em의 tuning과정에서 “Implement”버튼을 통해 profile의 accept 여부를 결정하는

방법을 설명한 바 있다. 만일 그 때에 accept하였다면 다음과 같은 SQL을 통해 그

결과를 확인할 수 있다.

SYSTEM> select name, category from dba_sql_profiles;

NAME CATEGORY



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

SYS_SQLPROF_050905141344965 DEFAULT

현재 위 profile이 존재하고 있음을 알 수 있다. 동일한 STS를 가지고 다시 tuning을

수행할 것임으로 이 profile을 삭제하고 다시 다음과 같이 tuning 절차를 진행해 보자.

먼저 삭제는 다음과 같은 procedure를 사용하면 되는데 “DROP ANY SQL PROFILE”

권한이 있어야 한다.

CF. 위 결과에서 “CATEGORY”를 기억하자. 아래 SQL profile의 accept 작업이 끝나면

다시 설명한다.

SYSTEM> exec

dbms_sqltune.drop_sql_profile('SYS_SQLPROF_050905141344965');


이제 다시 tuning 절차를 수행한다.

SYSTEM> exec :task_id := dbms_sqltune.create_tuning_task(-

> sqlset_name => 'STS_20050905_002');


SYSTEM> exec dbms_sqltune.execute_tuning_task(task_name => :task_id);



2 from dual;

DBMS_SQLTUNE.REPORT_TUNING_TASK(:TASK_ID)

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


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

Tuning Task Name : TASK_1833

Scope : COMPREHENSIVE

Time Limit(seconds) : 1800



Completion Status : COMPLETED

Started at : 09/05/2005 15:30:36

Completed at : 09/05/2005 15:33:37

SQL Tuning Set (STS) Name : STS_20050905_002

Number of Statements in STS : 5

Number of Statements in Report: 5

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

Object ID: 2

SQL ID : 2b064ybzkwf1y

SQL Text : BEGIN EMD_NOTIFICATION.QUEUE_READY(:1, :2, :3); END;

....

....

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


....

....

Object ID: 3

....

....

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


....

....

Object ID: 4

....

....

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


....

....

Object ID: 5

....

....

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




....

....

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

Object ID: 6

SQL ID : 25j81dmzzn5w2

SQL Text : SELECT a.advisor_name, a.task_name, a.inst_id, a.description,

..............

..............

..............

1- SQL Profile Finding (see explain plans section below)

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

A potentially better execution plan was found for this statement.

Recommendation (estimated benefit: 80%)

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

Consider accepting the recommended SQL profile.

execute :profile_name := dbms_sqltune.accept_sql_profile(task_name =>

'TASK_1833', object_id => 6)

..............

..............

..............

위 tuning 결과를 보면 6번째 object(STS에 있는 SQL중 6번째 SQL)에 대하여

권고사항이 나타난다. 즉, profile을 accept하라는 것이며 그 사용법도 알려주고 있다.

7.8.5.SQL Profile 적용 (Manually)

7.8.5.1. Accept Profile

위 STS를 사용한 tuning의 권고 사항을 받아 들여보자.

SYSTEM> var sprfile varchar2(100)

SYSTEM> exec :sprfile := dbms_sqltune.accept_sql_profile(-

> 'TASK_1833', object_id => 6, name => '1st_profile_advice');




SYSTEM> print :sprfile

SPRFILE

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

1st_profile_advice

위 작업은 권고사항을 적용하는 function에서 추가적으로 “name” argument를

사용하여 system이 만들어주는 알아보기 힘든 profile의 이름 대신에 사용자가 직접

입력하는 이름으로 profile을 생성하여 accept한 것이다.

CF. profile의 accept를 위해 “CREATE ANY SQL PROFILE”권한이 필요하다.

7.8.5.2. Profile Category

앞서 profile을 검색하고 drop할 때 나타났던 category를 상기하자. 이 category는

현재 session 혹은 system의 SQL category와 연관이 있다. 다음의 SQL결과를 보자.

SYSTEM> select value from v$parameter

2 where name = 'sqltune_category';

VALUE

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

DEFAULT

위 결과는 앞서 dba_sql_profiles에서 나타난 category의 값과 동일하다. 즉, 현재

SQL은 “DEFAULT”라는 category에서 적용된다는 의미이다. 사실 아무런 지정을 하지

않으면 default로 “DEFAULT” category가 적용된다. 즉, 위에서 profile의 accept를

할 때 category argument를 지정하여 자신이 원하는 category로 해당 profile을

저장할 수도 있다는 말이다.

이 category는 session 혹은 system level에서 어떤 SQL profile을 적용할 것인가를

결정하게 된다. 따라서 여러분이 위 profile을 “ XTEST”라는 이름으로 accept했다면

현재의 “DEFAULT” category 상태에서는 tuning의 효과를 볼 수가 없게 된다. 반대로

현재 sqltune_category가 “XTEST”라면 위에서 accept한 profile은 사용할 수가

없다는 뜻이 된다. 만일 그런 상황이면 다음과 같이 profile을 수정할 수 있다.

7.8.5.3. Profile 수정위에서 언급한 category의 수정은 다음과 같다.



SYSTEM> exec dbms_sqltune.alter_sql_profile(-

> '1st_profile_advice', 'CATEGORY', 'XTEST');


SYSTEM> select name, category, status from dba_sql_profiles;

NAME CATEGORY STATUS

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

1st_profile_advice XTEST ENABLED

이 procedure는 두 번째 argument인 “attribute_name”의 값을 조정하여 다양한

작업을 가능하게 한다. 예를 들어 다음은 지정한 profile을 disable시키는 방법이다.

SYSTEM> exec dbms_sqltune.alter_sql_profile(-

> '1st_profile_advice', 'STATUS', 'DISABLED');


SYSTEM> select name, category, status from dba_sql_profiles;

NAME CATEGORY STATUS

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

1st_profile_advice XTEST DISABLED

CF. 위 작업은 “ALTER ANY SQL PROFILE”권한을 필요로 한다.

7.8.6.STS Control (Manually)

앞서 em을 통해 작업을 할 때는 “관리(Administration)”화면의 “작업로드(Work

Load)”에 아예 STS를 control하는 화면이 따로 있어 매우 편리하다. 그러나 어떤

이유로든 여러분이 직접 STS를 조정할 필요가 있다면 역시 dbms_sqltune package

를 사용해야 한다.

7.8.6.1. STS의 생성과 SQL Load

STS를 생성할 때에는 먼저 STS의 이름을 지정하여 object를 생성해야 한다. 이

과정에서는 “ADMINISTER SQL TUNING SET” 혹은 “ADMINISTER ANY SQL

TUNING”권한이 필요하다. 먼저 만들어 보자.



SYSTEM> exec dbms_sqltune.create_sqlset('X10G_STS', 'FromAWR');


위 내용은 “X10G_STS”라는 이름의 STS object를 만들고 그 설명으로 “FromAWR”을

입력한 결과이다.

이제 만들어진 STS로 필요한 SQL을 load해야 한다. 이는 load_sqlset procedure를

통해 가능한데 이 procedure는 STS이름과 cursor 형태로 만들어진 sqlset_cursor를

입력 받는다. 이 cursor의 값으로는 “select_workload_repository”와 같이 AWR의

snapshot id를 지정하거나 baseline을 지정하는 두 가지 방법과 현재 cursor cache

로부터 받아 들이는 “select_cursor_cache” 혹은 다른 STS로부터 입력을 받는

“select_sqlset”등을 활용할 수 있다. 모두 filtering, ranking을 통해 buffer gets,

disk reads등이 얼마 이상인 SQL만을 추출할 수도 있다. 여기서는 AWR에서 baseline

을 사용하여 해당 baseline의 SQL을 추출한 후 이를 위에서 만든 STS로 load하는

작업을 해보자. 먼저 앞서 baseline에 대해 설명할 때 만들었던 baseline을 확인해

보자.

SYSTEM> select baseline_name from dba_hist_baseline;

BASELINE_NAME

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

1st_oltp_baseline

AWR_1124785023920

이 값을 기준으로 다음의 STS로 SQL을 load하는 작업을 진행해보자.

SYSTEM> declare

2 base_ref_cursor dbms_sqltune.sqlset_cursor;

3 begin

4 open base_ref_cursor for

5 select value(rfc) from table(

6 dbms_sqltune.select_workload_repository('1st_oltp_baseline',

7 'executions > 5')) rfc;

8 dbms_sqltune.load_sqlset('X10G_STS', base_ref_cursor);

9 end;

10 /




위 작업은 workload repository에 있는 baseline “1st_oltp_baseline”의 SQL을

추출하여 STS “X10G_STS”로 load를 하되 조건으로 실행 횟수가 6회 이상인 것을

대상으로 load한 것이다.

7.8.6.2. STS와 SQL의 조정자 이제 위에서 만들어진 STS로 몇 건의 SQL이 생성되었는지 확인해 보자.

SYSTEM> select count(*) from

2 table(dbms_sqltune.select_sqlset('X10G_STS'));

COUNT(*)

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

58

SYSTEM> select id, name, statement_count

2 from dba_sqlset

3 where description = 'FromAWR';

ID NAME STATEMENT_COUNT

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

9 X10G_STS 58

위 두 방식은 앞서 baseline에서 SQL중 수행횟수가 6회 이상인 SQL이 총 58건이

존재한다는 것을 알려준다. 첫 번째 SQL은 STS에서 직접 SQL 추출하여 계산한 것이고

두 번째 SQL은 oracle제공하는 view를 통해 확인한 방법이다. 두 가지 방식으로

보여준 것은 첫 번째 SQL의 경우 다른 의미가 있기 때문이다. 다음의 SQL로 이를

확인해 보자.


2 table(dbms_sqltune.select_sqlset('X10G_STS', 'disk_reads > 10'));

COUNT(*)

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

2



이 결과는 위에서 지정한 baseline의 SQL중 수행횟수가 6회 이상인 SQL중에서도

disk_reads의 값이 10 이상인 SQL은 총 2건이라는 의미가 된다. 이와 같은 다양한

방식으로 STS에 대한 사용이 가능하다.

다음은 STS에 있는 disk_reads가 10 이상인 SQL의 tuning이 완료되어 이 SQL들을

삭제하고자 할 때 사용하는 방법이다.

SYSTEM> exec dbms_sqltune.delete_sqlset('X10G_STS', 'disk_reads > 10');



2 table(dbms_sqltune.select_sqlset('X10G_STS', 'disk_reads > 10'));

COUNT(*)

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

0


2 from dba_sqlset


ID NAME STATEMENT_COUNT

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

9 X10G_STS 56

위 결과는 2개의 SQL이 삭제되었음을 보여준다. 만일 더 이상 STS가 필요하지 않다고

판단되면 다음과 같이 drop을 하면 된다.

SYSTEM> exec dbms_sqltune.drop_sqlset('X10G_STS');



2 from dba_sqlset




no rows selected

CF. STS와 관련된 정보들을 보기 위해서는 “dba_sqlset”, “dba_sqlset_references”,

“dba_sqlset_statements”, “dba_sqlset_binds”와 같은 view들을 활용하면 된다.

7.8.7.SQL Access Advisor

우리는 ATO를 설명하면서 두 개의 advisor인 SQL tuning advisor와 SQL access

advisor의 역할에 대해 다루었다. ATO에서 SQL access advisor가 따로 소개된

이유는 SQL tuning의 절차에서 indexes나 MView, MView log등에 대한 oracle의

recommend 사항을 독립적으로 접근할 수 있기 때문이다. ATO의 마지막 과정으로

SQL access advisor를 살펴보자.

CF. 앞서 보았지만 SQL tuning advisor는 dbms_sqltune package를 사용해왔다.

하지만 SQL access advisor는 dbms_advisor package를 사용한다.

CF. SQL access advisor를 사용하려면 “ADVISOR”권한이 있어야 한다.

7.8.7.1. 대상 SQL

SQL access advisor를 사용하기 위해 input data로 사용되는 SQL들은 다음과 같은

방식이 가능하다. 물론, 이런 방식들은 실제로 사용되는 advisor인 dbms_advisor

package의 sub procedure를 통해 이루어진다.

1. 현재 SQL cache에서 즉, v$sql을 이용하는 방법:

dbms_advisor.import_sqlwkld_sqlcache

2. 사용자가 정의하는 workload table을 이용하는 방법(여기서 사용하는 table은

최소한 SQL_TEXT, USERNAME column을 가지고 있어야 한다) :

dbms_advisor.import_sqlwkld_user

3. hypothetical 방식 (이것은 특정 schema나 table을 지정한다) :

dbms_advisor.import_sqlwkld_schema

4. STS(SQL Tuning Set)을 이용하는 방법 : dbms_advisor.import_sqlwkld_sts

CF. 위에서 2번째 방식인 user-defined workload라 함은 사용자가 access 분석을

하고 싶은 SQL을 모아 이를 하나의 workload로 간주하여 SQL access advisor의

source로 사용하고자 할 때 사용하는 방식이다. 이 방식은 사용자가 필요에 추출한

SQL문들 뿐만 아니라 아직 database에 반영되지 않은 application의 SQL도 미리

점검할 수 있는 방안이 될 수 있다. 즉, DBA는 이런 기능을 얼마나 적절히 사용할 수

있는가도 중요한 임무이다. 다음은 사용자 정의 workload table(일명 user_workload



라 칭한다)의 구성요소 이다. 이미 언급했지만 필수 columns은 sql_text(CLOB,

LOGN, VARCHAR2)와 username(VARCHAR2(30))이고 다른 columns의

생성여부는 option이다.

Column Data Type Default Description

MODULE VARCHAR2(64) empty string application module

name

ACTION VARCHAR2(64) empty string application action

BUFFER_GETS NUMBER 0 전체 buffer-gets

CPU_TIME NUMBER 0 전체 CPU time (sec)

ELAPSED_TIME NUMBER 0 전체 수행 시간 (sec)

DISK_READS NUMBER 0 전체 disk-read 수

ROWS_PROCESSED NUMBER 0 전체 rows process 수

EXECUTIONS NUMBER 1 전체 수행 횟수

OPTIMIZER_COST NUMBER 0 계산된 optimizer's cost

LAST_EXECUTION_DATE DATE SYSDATE 마지막으로 수행된 시간

PRIORITY NUMBER 2 SQL의 중요도 설정

1- HIGH

2- MEDIUM

3- LOW

SQL_TEXT CLOB, LONG,

VARCHAR2

none SQL 문장

(필수 column)

STAT_PERIOD NUMBER 1 통계수집의

time period (sec)

USERNAME VARCHAR(30) current user 사용자 이름

(필수 column)

CF. 위에서 3번째 방식인 hypothetical 방식은 특별한 의미가 있다. 그냥 schema나

table을 지정한다고 생각하지 말고 여러분이 신규 project를 진행하고 있다고

생각해보자. 어느 정도 개발이 진행된 상태에서 이 방식을 사용하게 되면 현재의

상태에서 전반적으로 필요한 indexes등에 대한 정보를 얻을 수 있을 것이고 이를 통해

project의 개발에 좋은 권고사항들을 제시할 수 있게 될 것이다.

7.8.7.2. Access Path 분석 Option과 권고사항SQL access에 대한 분석을 수행할 때에는 최종적으로 어떤 방식으로 분석할 것인가를

선택하게 된다. 이는 oracle10g가 두 가지 방식을 제안하여 사용자가 선택을 할 수

있게 하기 때문인데 시간은 오래 걸리지만 global advice를 해주는


표 7-23

SQL 정보 List


full(comprehensive) mode와 단순히 SQL문에 대한 advice를 해주는

partial(limited) mode가 있다.

1. comprehensive : 주어진 workload의 전체적인 분석을 실시하여 권장사항을

만들어 준다. 이 경우엔 주어진 workload가 전체 database활동에서 사용되는

application의 SQL set(전체 혹은 대표성을 갖는 SQL 모음)이라고 가정하게 된다.

2. limited : 주어진 workload에 SQL은 문제가 있는 SQL이라 가정하고 권장사항을

만든다. 따라서 이러한 분석의 결과는 특정 application의 일부에 대한 성능향상을

위한 권장사항이 된다.

다음은 위 두 mode사이의 분석 결과에 어떤 차이가 있는지를 보여준다.

권장사항 Comprehensiv

e

Limited

새로운 index, MView 추가 O O

새로운 MView log의 추가 O O

현재 MView의 변경(column, clause 추가) O O

사용되지 않는 MView의 drop O X

사용되지 않은 index의 drop O X

현재 index의 type변경 O X

현재 index의 끝에 column 추가 O O

7.8.7.3. Access 분석 (Using em)

SQL access advisor도 em을 사용하는 것이 가장 편리하다. 여기서 테스트할 것은

user-defined workload를 만들어 할 것이다. 다음과 같이 대상 table을 만들어 SQL

을 등록해 보자.

Pre Step : (이 단계는 필요한 SQL source를 만드는 모든 과정을 포함한다)

SYSTEM> create table x_wkld_scott (sql_text varchar2(1000), username

varchar2(30));

Table created.

SYSTEM> insert into x_wkld_scott

2 select 'select sum(' || column_name || ') from ' || table_name, 'SCOTT'

3 from dba_tab_columns

4 where owner = 'SCOTT' and column_id = 1 and data_type = 'NUMBER';

107 rows created.


표 7-24

SQL Access 분석 Mode


SYSTEM> commit;

Commit complete.

현재는 계정 scott의 table중 첫 번째 column이 number인 table에 대하여

summary를 하는 SQL을 무작위로 만들어서 등록을 하였다. 실무에서는 이 SQL들이

실제로 application에서 사용되는 혹은 사용할 SQL들이어야 할 것이다.

지금 진행하는 작업은 현재 필자의 database에서 이루어 지고 있음으로 여러분 각자가

사용하는 database에서는 다른 결과가 나올 것이다. 그러나 아래 step은 모두

동일하며 다만 마지막 권고사항에 대한 결과와 그 내역만 다를 것이다.

이제 em에서 작업을 위해 먼저 advisor central화면으로 이동하자.

SQL Access Advisor를 선택하면 다음화면으로 이동하여 작업을 시작할 수 있다 .Step #1 : 여기서 앞서 설명한 여러 유형의 SQL source를 선택한다


그림 7-45

em Advisor Central

그림 7-46

SQL Access Advisor


현재는 user-defined workload를 선택하여 앞서 생성한 table을 지정했다.

좌측 하단에 option을 선택하면(여러분이 필요하다면 수행하라) 다음 화면이 나타난다.



이 화면에서는 여러 분석유형 및 filtering 조건을 줄 수 있다. 현재 테스트를 위해

만들어진 user-defined workload “X_WKLD_SCOTT”은 SQL문과 사용자 명만을

가지고 있기 때문에 위의 option 화면에서 filtering을 할 수 없을 것이다.

다음은 “Next” 버튼을 통해 두 번째 단계인 recommendation option화면으로 이동한

것이다.

Step #2 : 분석 유형을 선택한다


그림 7-47

SQL Access Advisor


여기서 index와 MView 혹은 둘 다 분석할 것인가를 선택하고 앞서 설명한 분석 유형인

limited와 comprehensive중에서 하나를 선택한다.

좌측 하단의 option을 선택하면(역시 필요하다면 선택하라) 다음과 같은 창을 볼 수

있다.

여기서는 분석 결과에 대한 용량제한, tuning option(buffer gets과 같은 통계 선택),

분석 결과에 나타나는 storage option의 default값 들을 조정할 수 있다.

이제 다음 단계로 이동을 위해 “Next”를 선택하면 schedule 창이 나타난다.


그림 7-48

SQL Access Advisor

그림 7-49

SQL Access Advisor


Step #3 : 분석 schedule을 정의한다

이 단계는 access advisor가 언제 분석 작업을 수행할 것인가를 설정한다. 미리

정의된 schedule이 없으면 위에서처럼 Standard를 선택하라. 그러면 다음과 같은

창이 하단에 추가적으로 나타난다.


그림 7-50

SQL Access Advisor


이 화면에서 여러분이 직접 수행시간을 설정할 수 있다. 반복적으로 그리고 나중에 분석

작업을 수행할 수도 있다. 현재는 지금 바로 분석을 하도록 설정된 default값들을

수정하지 않고 그대로 다음 단계로 이동한다.

Step #4 : 전체적으로 분석작업에 대한 review를 한다


그림 7-51

SQL Access Advisor


이제 마지막 단계로 현재까지의 작업설정을 점검하는 화면이다. 최종적으로 “Submit”

을 하면 다음과 같은 화면으로 이동한다.

CF. 필요하다면 여기서 우측 상단의 “Show SQL”을 통해 이 작업들을 직접 수행할 수

있도록 SQL code를 만들어 사용할 수도 있다.

Result #1 : task를 선택하여 작업 결과를 확인한다

위 화면에는 advisor task가 만들어 졌음을 보여준다. 여기서 적절한 task를 선택한 후


그림 7-52

SQL Access Advisor

그림 7-53

SQL Access 분석결과


중앙 하단에 “View Result”를 누르면 분석결과를 볼 수 있다. 이 작업은 경우에 따라

상당한 시간이 소요될 수 있다. 따라서 여러분이 능숙하게 이 작업을 할 수 있게 된다면

앞서 step3의 schedule을 잘 활용하면 좋을 것이다.

Result #2 : 최종 분석결과를 확인한다

위 화면에서 최종 결과를 확인할 수 있다. 그래프 형식을 통해 recommendation id별

cost benefit을 보여주고 하단에는 그 내역을 보여준다. 하단의 id를 선택하면 해당 id

의 action list 즉, 어떤 권장사항들을 수행해야 하는지 알 수 있다.

Result #3 : 세부 action list를 확인한다.


그림 7-54



유지할 index와 새로 생성할 필요가 있는 index에 대해 list를 보여준다. 하단에는 이

action list로 인해 영향을 받을 수 있는 SQL 내역을 보여주고 있다. “OK”를 통해 다시

Result #2화면으로 돌아가보자. 그리고 “Show SQL” 버튼을 click하라.

Result #4 : SQL scripts 생성


그림 7-55



위와 같은 종류의 권장사항을 수행할 script를 볼 수 있다. 만일, 앞서 Result #2

화면에서 tablespace와 같이 조정이 가능한 항목을 수정했다면 그 내용은 위 화면에서

그대로 반영된다. 예를 들어 Result #2에서 tablespace를 “TOOLS”로 지정했다면

아래와 같은 결과를 볼 수 있을 것이다.


그림 7-56



여러분이 이 script를 사용하여 다른 SQL session에서 필요한 작업을 해도 되지만

만일 위 script를 그대로 수행하고 싶다면 “OK” 버튼을 통해 Result #2화면으로

돌아가라. 그리고 “Schedule Implementation” 버튼을 click하라.

Result #5 : 작업 schedule을 선택하라.


그림 7-57



이제 위 화면에서 scheduling을 통해 권장사항으로 나타난 SQL script를 그대로

수행시킬 수 있다. Option을 통해 schedule을 만들 수도 있지만 지금 바로 수행을

원한다면 위와 같이 default “Immediately”상태에서 “Submit”을 수행한다. (안전한

작업의 진행을 위해 “Submit”전에 “Show SQL”을 통해 script를 확인하는 것도 좋은

습관이다) “Submit”이 수행되면 다음 화면으로 이동된다. 모든 작업이 종료되었다.

다음의 SQL 결과는 위의 작업이 제대로 수행되었음을 확인 시켜준다. 마지막 index의

이름과 생성일자를 비교해 보라.

SYSTEM> col crdte for a20


SYSTEM> select object_name, to_char(created, 'YYYYMMDD HH24:MI:SS')

crdte


그림 7-58


그림 7-59



2 from dba_objects

3 where owner = 'SCOTT' and object_type = 'INDEX' and

4 object_name in (select index_name from dba_indexes

5 where owner = 'SCOTT' and table_name = 'XXXX_LT');

OBJECT_NAME CRDTE

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

XXXX_PK 20040217 13:02:22

XXXX_PKI$ 20040217 13:02:22

_IDX$$_076B0001 20050906 16:07:54

7.8.7.4. Access 분석 (Manually)

여기에서 다루는 것은 앞서 em에서 보았던 내용들을 직접 SQL을 통해 작업하는

것이다. 가급적 em을 사용할 것을 권고한다. 대상이 되는 SQL source는 oracle

권장하는 STS를 사용할 것이다. 먼저 STS “MANUAL_STS01”을 최근 30개의

snapshot id로 생성하고 분석 작업을 수행해 보자.

Pre Step : snapshot으로부터 STS를 만들자.

SYSTEM> select max(snap_id) from dba_hist_snapshot

2 union all

3 select max(snap_id) - 30 from dba_hist_snapshot;

MAX(SNAP_ID)

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

1764

1734

SYSTEM> exec dbms_sqltune.create_sqlset('MANUAL_STS01');


SYSTEM> declare

2 snap_ref_cursor dbms_sqltune.sqlset_cursor;

3 begin

4 open snap_ref_cursor for

5 select value(X) from table



6 (dbms_sqltune.select_workload_repository(1734, 1764)) X;

7 dbms_sqltune.load_sqlset('MANUAL_STS01', snap_ref_cursor);

8 end;

9 /


위 결과는 성공적으로 import된 SQL의 수가 적게 나타났다. 그것은 현재 특별한

application을 수행하고 있는 것이 아니기 때문에 PL/SQL block과 oracle internal

SQL들이 제외된 실제 application SQL이 거의 없기 때문이다.

Step #1 : SQL Workload를 생성한다.

SYSTEM> var wkld_name varchar2(30);

SYSTEM> exec :wkld_name := 'WKLD_001';


SYSTEM> exec dbms_advisor.create_sqlwkld(:wkld_name, 'FROM STS');


Step #2 : STS를 위에서 만들어진 workload로 import한다.

SYSTEM> var success_row number

SYSTEM> var fail_row number

SYSTEM> exec dbms_advisor.import_sqlwkld_sts(:wkld_name,

'MANUAL_STS01',-

> saved_rows => :success_row, failed_rows => :fail_row);


SYSTEM> print :success_row

SUCCESS_ROW

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

13



SYSTEM> print :fail_row

FAIL_ROW

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

423

CF. 위에서 사용한 import procedure는 추가적으로 import_mode(default ‘NEW’와

priority(default 2)를 사용할 수 있다. 먼저 import mode는 현재 workload에 추가를

하는 것이면 “APPEND”를 기존의 것을 바꾸려면 “REPLACE”를 사용하며 새로 만드는

것은 “NEW”를 설정한다. 그리고 priority는 문장의 중요도를 설정하는 것으로 “1-

HIGH, 2-MEDIUM, 3-LOW“를 선택한다.

Step #3 : Advisor를 수행하기 위한 task를 구성한다.

SYSTEM> var task_id number

SYSTEM> var task_name varchar2(30)

SYSTEM> exec :task_name := 'MANUAL_ACS_TSK001';


SYSTEM> exec dbms_advisor.create_task('SQL Access

Advisor', :task_id, :task_name);


SYSTEM> print :task_id

TASK_ID

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

1915

Step #4 : 이제 위에서 만든 advisor task에 새로 생성한 workload를 연결한다.

SYSTEM> exec dbms_advisor.add_sqlwkld_ref(:task_name, :wkld_name);




Step #5 : SQL access advisor task를 수행한다.

SYSTEM> exec dbms_advisor.execute_task(:task_name);


이제 SQL access 분석이 모두 종료 되었다. 분석 결과를 보기 위하여 다음의 SQL들을

사용하라.

Result #1 : 분석결과에 대한 종합 내역을 보자.

SYSTEM> select rec_id, rank, benefit

2 from dba_advisor_recommendations

3 where task_name = 'MANUAL_ACS_TSK001';

REC_ID RANK BENEFIT

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

1 1 256456

2 2 4796

3 3 190

4 4 0

위 결과는 중요도에 따라 총 4개의 권장사항이 나타났으며 optimizer cost 이점을

보여주는 “BENEFIT”을 보면 실질적으로 첫 번째 권장사항이 매우 긴급한 것처럼

보인다.

Result #2 : 분석결과를 문장단위의 percent로 확인해 보자.

SYSTEM> select sql_id, rec_id, precost, postcost,

2 round((precost-postcost)*100/precost, 2) "BENEFIT%"

3 from dba_advisor_sqla_wk_stmts

4 where task_name = 'MANUAL_ACS_TSK001' and

5 workload_name = 'WKLD_001' and postcost < precost

6 order by rec_id;

SQL_ID REC_ID PRECOST POSTCOST BENEFIT%

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



106 1 40536 27 99.93

107 1 27024 18 99.93

108 1 9008 6 99.93

111 1 81036 54 99.93

113 1 76517 51 99.93

112 1 18004 12 99.93

109 1 4502 3 99.93

105 2 4800 4 99.92

114 3 266 76 71.43

9 rows selected.

Result #3 : 다음으로 권장사항을 수행하는데 필요한 action을 확인해 보자.

SYSTEM> col action for a30

SYSTEM> select rec_id, action_id, substr(command,1,30) action

2 from dba_advisor_actions

3 where task_name = 'MANUAL_ACS_TSK001'

4 order by rec_id, action_id;

REC_ID ACTION_ID ACTION

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

1 1 CREATE MATERIALIZED VIEW LOG

1 3 CREATE MATERIALIZED VIEW

1 4 GATHER TABLE STATISTICS

1 7 CREATE INDEX

2 1 CREATE MATERIALIZED VIEW LOG

2 5 CREATE MATERIALIZED VIEW

2 6 GATHER TABLE STATISTICS

3 8 CREATE INDEX

3 9 RETAIN INDEX

4 10 RETAIN INDEX

10 rows selected.

마지막 두 action은 index를 그대로 유지하라는 것뿐 실제 수행할 것은 없다.



Result #4 : 이제 권장사항을 script로 받아 보자. 사실 여러 advisor의 결과를 SQL로

받아보는 방법들은 앞서 oracle10g의 advisor 전반에 대하여 설명을 할 때에

다루어본 부분이다. 여기서는 function을 통해 직접 script로 return을 받아보자.

SYSTEM> select dbms_advisor.get_task_script('MANUAL_ACS_TSK001') from

dual;

DBMS_ADVISOR.GET_TASK_SCRIPT('

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

Rem SQL Access Advisor: Version 10.1.0.1 - Production

Rem

Rem Username: SYSTEM

Rem Task: MANUAL_ACS_TSK001

Rem Execution date: 06/09/2005 17:44

Rem

set feedback 1

set linesize 80

set trimspool on

set tab off

set pagesize 60

whenever sqlerror CONTINUE

CREATE MATERIALIZED VIEW LOG ON

"SCOTT"."EMP2"

WITH ROWID, SEQUENCE("EMP_ID","SALARY","RECOMMENDER")

INCLUDING NEW VALUES;

CREATE MATERIALIZED VIEW "SYSTEM"."MV$$_077B0001"

REFRESH FAST WITH ROWID

ENABLE QUERY REWRITE

AS SELECT SCOTT.EMP2.EMP_ID C1, "SCOTT"."EMP2"."EMP_ID" M1,

SUM("SCOTT"."EMP2"."SALARY")

M2, COUNT("SCOTT"."EMP2"."SALARY") M3, COUNT(*) M4 FROM SCOTT.EMP2



GROUP

BY SCOTT.EMP2.EMP_ID;

begin

dbms_stats.gather_table_stats('"SYSTEM"','"MV$

$_077B0001"',NULL,dbms_stats.auto_sample_size);

end;

/

CREATE MATERIALIZED VIEW "SYSTEM"."MV$$_077B0000"

REFRESH FAST WITH ROWID

ENABLE QUERY REWRITE

AS SELECT SCOTT.EMP2.RECOMMENDER C1, SCOTT.EMP2.EMP_ID C2,

"SCOTT"."EMP2"."E

MP_ID"

M1, SUM("SCOTT"."EMP2"."SALARY") M2, COUNT("SCOTT"."EMP2"."SALARY")

M3,

COUNT(*) M4 FROM SCOTT.EMP2 GROUP BY SCOTT.EMP2.RECOMMENDER,

SCOTT.EMP2.E

MP_ID;

begin

dbms_stats.gather_table_stats('"SYSTEM"','"MV$

$_077B0000"',NULL,dbms_stats.auto_sample_size);

end;

/

CREATE INDEX "SYSTEM"."_IDX$$_077B0007"

ON "SYSTEM"."MV$$_077B0001"

("C1")

COMPUTE STATISTICS;

CREATE INDEX "WMSYS"."WM$VERSIONED_TA_IDX$$_077B0008"

ON "WMSYS"."WM$VERSIONED_TABLES"

("DISABLING_VER","OWNER")



COMPUTE STATISTICS;

/* RETAIN INDEX "WMSYS"."WM$VERSIONED_TABLES__PK" */

/* RETAIN INDEX "WKSYS"."SYS_C001725" */

whenever sqlerror EXIT SQL.SQLCODE

begin

dbms_advisor.mark_recommendation('MANUAL_ACS_TSK001',1,'IMPLEMENTED');




end;

/

이제 여러분은 이 권장사항을 취사선택하여 반영하면 될 것이다.

위에서 나타난 권장사항(dba_advisor_actions .command) 즉, action은 그 종류가

다양하다. 상황에 따라 어떤 action이 필요한가는 매번 다르기 때문이다. 우리는

다음과 같은 view를 통해 그 종류가 어떠한 것들이 있는지 미리 알 수 있다.

SYSTEM> desc dba_advisor_commands;

Name Null? Type

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

COMMAND_ID NUMBER

COMMAND_NAME VARCHAR2(64)

SYSTEM> select * from dba_advisor_commands;

COMMAN COMMAND_NAME

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

0 UNDEFINED

1 RUN SQL TUNING ADVISOR

2 CREATE INDEX

3 CREATE MATERIALIZED VIEW



4 CREATE MATERIALIZED VIEW LOG

5 NEVER CREATE INDEX

6 NEVER CREATE MATERIALIZED VIEW

7 NEVER CREATE MATERIALIZED VIEW LOG

8 NEVER DROP INDEX

9 NEVER DROP MATERIALIZED VIEW

10 NEVER MODIFY INDEX

11 SET INDEX MAXIMUM COUNT

12 SET INDEX SCHEMA

13 SET INDEX TABLESPACE

14 SET MATERIALIZED VIEW SCHEMA

15 SET MATERIALIZED VIEW TABLESPACE

16 SET STORAGE SIZE

17 DROP INDEX

18 DROP MATERIALIZED VIEW

19 DROP MATERIALIZED VIEW LOG

20 RETAIN INDEX

21 RETAIN MATERIALIZED VIEW

22 RETAIN MATERIALIZED VIEW LOG

23 CREATE SUB MATERIALIZED VIEW

24 DROP SUB MATERIALIZED VIEW

25 CREATE REWRITE EQUIVALENCE

26 DROP REWRITE EQUIVALENCE

27 ALTER MATERIALIZED VIEW LOG

28 GATHER TABLE STATISTICS

29 GATHER INDEX STATISTICS

30 SET UNDO_RETENTION

31 SET UNDO TABLESPACE SIZE

32 ACCEPT SQL PROFILE

33 REWRITE QUERY

34 RUN SEGMENT ADVISOR

35 ALTER PARAMETER

36 SHRINK SPACE

37 rows selected.



CF. 위 결과를 보면 access advisor를 통해 SQL을 사용하여 직접 creation 추천을

받을 수 있는 object는 index, mview 및 mview log정도임을 알 수 있다. 즉, SQL

tuning은 무언가를 생성하는 것 보다 훨씬 더 많은 종류의 방향이 있음을 잊지 말자.

위 작업들과 관련하여 workload를 handling하는 또 다른 procedures를 대략

살펴보면 다음과 같은 것들이 있다.

Workload Sub Procedures Description

add_sqlwkld_statement

delete_sqlwkld_statement

update_sqlwkld_statement

SQL문장을 직접 추가, 삭제, 수정

delete_sqlwkld workload를 삭제

delete_sqlwkld_ref task에 연결된 workload를 제거

update_sqlwkld_attributes workload의 이름, 설명 등 속성을 변경

set_sqlwkld_parameter workload의 parameter 변경

set_default_sqlwkld_parameter workload의 default parameter 값 설정

CF. SQL access advisor를 사용하는 방법들은 워낙 다양하기 때문에 em을 통하는

것이 제일 편리하다. 내부적으로 사용되는 advisor package는 지금 설명한 SQL

workload관련 procedures를 제외하면 이미 여러 차례 다룬바 있다. 앞서 AWR과

Advisor 전반에 대해 설명한 부분을 다시 확인하기 바란다.

(보다 자세한 내역을 알고 싶다면 oracle OTN site document에서 manual을

download한 후 “PL/SQL Packages and Types Reference와 Oracle Database

Data Warehousing Guide”를 참조하라)


표 7-25

Workload Procedure List


OCP point

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

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

1. SQL tuning advisor의 4가지 결과물

2. SQL access advisor를 통해 creation을 권고 받을 수 있는 object의 종류



7.9. Instance Monitoring

7.9.1.Monitoring 방안이번 장에서 다루어온 많은 부분들은 궁극적으로 oracle 서버의 성능과 연관이 된다.

결국은 서버의 성능을 최적화 하는 것이 oracle10g가 이야기하는 automatic

tuning(혹은 self-health checking)의 목적이기 때문이다. 다시 정리해 보면 두 가지

유형의 monitoring이 존재하게 된다.

1. proactive : 이는 앞서 많이 다루었던 ADDM을 통한 진단과 alert기능을 통한 감시

등을 포괄하는 방식이다. 이는 이미 언급한 oracle10g의 new background process

인 “MMON”에 의해 snapshot 형태로 AWR에 저장된 정보를 ADDM으로 진단하고

필요하다면 alert을 발생시키는 구조를 뜻한다.

2. reactive : 위 방식이 사용자가 설정을 통해 결과를 reporting하는 것이라고 한다면

이 방식은 em database control을 통해 관심항목들을 mouse click으로 drill down

하는 방식이다. 즉, 사용자가 database control을 통해 몇 번의 mouse click만으로

SGA내 통계 및 AWR에 접근하면서 주요 문제점들을 확인하고 필요한 작업을 할 수

있도록 하는 구조이다.

7.9.2.Database Control

필자가 볼 때에 em의 database control을 활용하는 방법의 가장 큰 이점은 쉬운

접근성뿐만 아니라 em의 특성상 oracle instance의 문제와 host 즉, OS system의

문제를 동시에 볼 수 있다는 점이 아닐까 한다.

가장 대표적인 tuning 접근은 다음과 같은 방식이 될 것이다.

1. CPU 및 wait class에서 문제 부분을 확인

2. 확인된 class에서 SQL 혹은 sessions의 정보를 확인

3. SQL이나 sessions에서 최종 문제를(AWR, ASH로부터 분석된다) 해결

다음은 일련의 이런 과정이 어떻게 이루어지는 예를 통해서 알아보자.

7.9.3.em의 성능 진단 및 관리먼저 em의 database control 첫 화면을 보자. 이미 여러분은 이 화면에 익숙해져

있을 것이다.



이 화면은 database 전반에 걸친 정보를 요약해서 보여주고 있다. 중앙에는 oracle을

탑재하고 있는 server의 즉, host CPU 상태를 보여주고 우측으로 active session

정보와 SQL 성능에 대한 요약정보가 있다.

1. Host CPU는 database instance의 사용과 다른 부분의 사용률을 비교해서

보여준다.

2. active session은 현재 session의 waiting이 어떤 부분에서 어느 정도

발생하는지를 알려준다.

3. SQL 정보는 이전의 baseline과 비교하여 얼마나 SQL 응답시간이 증가했는지를

percent로 보여준다.

다음으로 성능을 표현해 주는 화면으로 이동해 보자. 상단의 “Performance”를 click

하라.


그림 7-60

em 초기화면


위 화면에서 host 정보와, session 그리고 instance 전반에 대한 정보를 시간대별

그래프로 볼 수 있다. 첫 번째로 host에서 CPU와 memory(host run queue &

paging)를 확인할 수 있고 “Sessions”에서 session의 활동과 관련한 waiting and

working정보를 볼 수 있다. 그리고 그 밑에서는 instance throughput chart를 통해

초당 혹은 transaction당(사용자 선택) 주요 instance 활동을 볼 수 있다.

만일 현재 database의 상태에 문제가 있다고 판단하였고 위 “Sessions”부분의

그래프에서 가장 많은 부분을 차지하는 것이 CPU가 아니라면 해당 항목을 click하여

보다 상세한 정보를 확인할 필요가 있을 것이다. 즉, 그 항목은 contention이 발생하고

있다고 가정할 수 있는 것이고 그 부분이 해결되면 보다 낳은 서버의 성능향상을 기대할

수 있을 것이다. 어떤 화면이 나타나는지 확인을 해보기 위해 “CPU used”항목을 click

해 보자.


그림 7-61

성능측정 화면


보다 자세하게 정보를 보여주고 있다. 관련된 SQL의 id와 session의 정보까지

나타난다. 하단의 “Top SQL”과 “Top Sessions”을 이용하면 보다 세부적인 정보를

확인할 수 있다. 모든 wait은 이런 식으로 접근을 할 수 있고 여러분은 mouse click 몇

번으로 문제점을 빠르게 찾아갈 수 있게 된다. 어떤 특정 문제를 인식하고 여러분이 이

단계까지 왔다면 이제 남은 일은 해당 문제점을 click하여 개선책을 결정하는 것이다.

예를 들어 SQL의 문제라 생각되면 mouse로 해당 SQL id를 click하여 SQL문장과

plan등을 확인하여 해결책을 찾으면 되는 것이다.

CF. 사실 이런 경우라면 해당 SQL문을 앞서 배운 SQL tuning advisor나 access

advisor의 source로 활용해서 oracle에게 tuning을 맡겨도 좋겠다.


그림 7-62

세부 성능측정 화면


OCP point

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

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

1. em database control의 performance tab에 나타나는 항목들



7.10. Resource Manger

7.10.1. Oracle10g New Features

Oracle8i에서 소개된 database resource manager는 database의 사용자 별

resource를 제어하는 기능이다. 물론, oracle9i에서 그 resource의 종류도

다양화되고 강화되었지만 구현자체가 약간은 복잡한 package 수행절차를 필요로

한다. Oracle10g는 효과적으로 resource를 관리하기 위하여 도움을 줄 수 있는

새로운 기능을 제공한다.

1. session이 consumer group을 switching한 후 call이 끝나면(현 session이 call을

받아 작업을 진행하면서 필요에 의해 consumer group switching이 발생하고 그

작업이 끝나면) 원래의 initial consumer group으로 다시 돌아간다.

2. session이 사용하는 총 idle time 또는 한 session이 다른 session을 blocking

하는 총 blocking time을 설정할 수 있게 되었다.

3. consumer group mapping 기능을 지원한다. 이는 최초 login시의 consumer

group 할당의 우선순위를 설정할 수 있게 해주며 또한 이미 연결된 한 session의

사용자를 다른 consumer group으로 mapping할 수 있게 해준다.

4. oracle10g는 plan directive의 설정을 위해 새로운 CPU 할당 방식을 지원한다.

이제 위 기능들을 하나씩 살펴보자.

7.10.2. Original Consumer Group으로 돌아가기다시 정리하면 이 기능은 top call이 끝나는 시점에 원래의 consumer group으로

되돌리겠다는 의미이다. 원래의 consumer group이란 session이 생성되는 시점에 즉,

login이 되는 시점에 할당 받는 group을 뜻한다. 이 말은 하나의 user가 각기 다른

시점에 login되면서 서로 다른 consumer group을 할당 받았다면 original

consumer group은 계정은 하나라도 각 session마다 다를 수 있다는 뜻이 된다.

따라서 이 session들이 call을 처리하면서 consumer group의 switching이 발생

했을 때 call이 끝난 후 돌아가는 원래의 consumer group도 다르게 된다.

Top call이란 전체 하나의 call을 지칭한다고 할 수 있는데 달리 이해해보면 last call이

끝나는 시점이라 보면 된다. 다음의 설명을 이해하면 그 의미가 보다 명확해 진다.

이 기능은 특히 3-tier구조에서 session pooling을 하는 경우에 매우 유용하다. 3-tier

에서 session pooling을 하게 되면 하나의 session을 여러 application user가

사용하게 된다. 대부분의 middleware를 사용하는 시스템은 하나의 session을 여러



end user가 공유하고 각 end user가 application을 call하면 middleware에서 그

call을 받아 oracle과 연동하여 작업을 처리한다. 따라서 end user 입장에서는 자신이

call한 한번의 call이(top call) 실질적인 작업단위가 된다. 그러므로 middleware가

end user로부터 call을 받아 처리하고 동일 session으로 들어온 다른 end user의 call

을 처리할 때에는 앞서 처리한 end user의 call이 뒤에 들어온 end user의 call에

영향을 주면 안될 것이다. 따라서 switch_time_in_call을 설정하게 되면 top call이

처리되는 시간에 따라 switch_group이 발생하게 되고 top call이 끝나는 시점에 다시

original consumer group으로 되돌린다.

Oracle8i에서는 consumer group을 switch하기 위해 sub procedure를 사용해 왔고

oracle9i에서는 directive를 설정할 때 switch_time parameter를 사용하여 session

의 active 시간에 따라 consumer group을 변경할 수 있었다. Oracle10g는

switch_time_in_call이라는 new parameter를 통해 call 단위의 consumer group

변경을 지원한다. 따라서 하나의 directive에서 switch_time과 switch_time_in_call

parameter를 동시에 지원할 수는 없다.

CF. oracle9i에서 소개된 switch_time parameter는 사실 client/server application

을 위한 속성이 강하지만 oracle10g의 switch_time_in_call은 session pooling을

통한 3-tier 구조를 지원하는 성격이 강하다.

7.10.2.1. Switch Time(Top Call)

정확한 테스트를 위해서는 middleware를 사용하는 3-tier구조를 구성해야 하지만

지금의 테스트환경이 그러하지 못함으로 database상에서 간단한 테스트를 통해 그

사용법을 이해하도록 하자. 테스트는 사용자 계정과 resource objects를 생성하여 이

기능을 확인하는 과정이다.

Step #1 : 사용자 계정과 call time에 따른 다른 action을 취하는 plan을 만든다.

SYSTEM> create user xrsrc identified by xrsrc;

User created.

SYSTEM> grant connect, resource to xrsrc;

Grant succeeded.

SYSTEM> exec dbms_resource_manager.create_pending_area ;




SYSTEM> exec dbms_resource_manager.create_plan('move_plan', 'execution above

10 sec') ;


Step #2 : original consumer group과 switch할 consumer group을 만들고 plan

directive를 설정한다. 이제 설정하는 short plan은 10초가 지나면 consumer group

을 switch하도록 한다.

SYSTEM> exec dbms_resource_manager.create_consumer_group('short_grp', 'short

working') ;


SYSTEM> exec dbms_resource_manager.create_consumer_group('long_grp', 'long

working') ;


SYSTEM> exec dbms_resource_manager.create_plan_directive('move_plan',

'short_grp',-

> 'rule for short job', cpu_p1 => 100, cpu_p2 => 0,-

> switch_group => 'long_grp', switch_time_in_call => 10 ) ;



'long_grp',-

> 'rule for long job', cpu_p1 => 0, cpu_p2 => 100);


SYSTEM> exec dbms_resource_manager.create_plan_directive('move_plan',-



> 'other_groups', 'other groups for normal', cpu_p1 => 0, cpu_p2 => 0, cpu_p3 =>

100) ;


Step #3 : 다음은 resource plan설정을 완료한 후 테스트할 계정인 xrsrc에게

consumer group을 switch할 수 있는 권한을 부여하고 initial group을 설정한다.

SYSTEM> exec dbms_resource_manager.validate_pending_area ;


SYSTEM> exec dbms_resource_manager.submit_pending_area ;


SYSTEM> exec

dbms_resource_manager_privs.grant_switch_consumer_group(-

> 'xrsrc', 'short_grp', FALSE) ;


SYSTEM> exec


> 'xrsrc', 'long_grp', FALSE) ;


SYSTEM> exec dbms_resource_manager.set_initial_consumer_group('xrsrc',

'short_grp') ;


Step #4 : 다음은 내용이 좀 복잡해 보이지만 별로 어려운 것은 아니다. 앞으로 작업할

내용을 하나씩 정리하면 다음과 같다.

1. 현재 설정된 initial consumer group 즉, 현재 설명하고 있는 original consumer



group으로 사용될 consumer group이 제대로 생성 되어있는지 확인한다.

2. 현재 database의 plan을 위에서 생성한 plan으로 activate시킨다.

3. 변경된 plan을 기준으로 현재 consumer group의 CPU usage를 조회하여 사용이

없음을 확인한다. 테스트 환경이 완료된다.

4. 테스트를 위해 consumer group을 v$session에서 읽을 수 있도록 select 권한을

부여한다.

5. 테스트 계정으로 login하여 initial consumer group을 확인한다.

6. 테스트에 사용할 table을 생성한다.

SYSTEM> select initial_rsrc_consumer_group

2 from dba_users

3 where username = 'XRSRC';

INITIAL_RSRC_CONSUMER_GROUP

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

SHORT_GRP

SYSTEM> alter system set resource_manager_plan = 'MOVE_PLAN';

System altered.

SYSTEM> select name, cpu_wait_time, consumed_cpu_time

2 from v$rsrc_consumer_group;

NAME CPU_WAIT_TIME CONSUMED_CPU_TIME

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

LONG_GRP 0 0

OTHER_GROUPS 0 403

SHORT_GRP 0 0

SYSTEM> grant select on v_$session to xrsrc;

Grant succeeded.

XRSRC> conn xrsrc/xrsrc

Connected.



XRSRC> set timing on

XRSRC> select resource_consumer_group

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


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

SHORT_GRP

Elapsed: 00:00:00.03

XRSRC> create table rsrc_cnt (dummy number(20));

Table created.

Elapsed: 00:00:00.39

Step #5(SYSTEM 창) : 이제 다른 창을 system 계정으로 열어서 CPU usage의

변화를 먼저 확인하자.




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

LONG_GRP 0 0

OTHER_GROUPS 0 2140

SHORT_GRP 0 393

위 결과에서 other_groups은 다른 사용자임으로 무시하고 short_grp의 CPU시간이

늘어났음을 인식하자.

Step #6(XRSRC 창) : 이제 테스트계정으로 login한 창에서 다음 작업을 수행해보자.

앞서 테스트를 위해 만든 table로 10초 이상이 걸리는 무의미한 insert 작업을 진행한

후 insert 전, 후의 consumer group의 값을 가져와 print하는 block을 수행한다.

XRSRC> set serveroutput on

XRSRC> declare

2 vs_rsrc_current varchar2(32);



3 vs_rsrc_after varchar2(32);

4 vn_cnt number;

5 begin

6 select resource_consumer_group

7 into vs_rsrc_current

8 from v$session


10 for vn_cnt in 1..50000 loop

11 insert into rsrc_cnt values (vn_cnt);

12 end loop;

13 select resource_consumer_group

14 into vs_rsrc_after

15 from v$session


17 dbms_output.put_line('Before Group : ' || vs_rsrc_current);

18 dbms_output.put_line('Switched Group : ' || vs_rsrc_after);

19 rollback;

20 end;

21 /

Before Group : SHORT_GRP

Switched Group : LONG_GRP


Elapsed: 00:00:34.51

위 결과를 보면 call이 10초 이상 수행되었고 따라서 print된 “Before Group”의 값과

“Switched Group”의 값의 변화를 통해 이미 switch 작업이 발생했었음이 확인된다.

Step #7(SYSTEM 창) : 이제 consumer group의 switch로 인한 CPU usage를 다시

확인해 보자.






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

LONG_GRP 0 11516

OTHER_GROUPS 2974 5897

SHORT_GRP 0 7085

분명히 long_grp의 CPU 사용량이 증가 했음을 확인할 수 있다.

Step #8(XRSRC 창) : 이제 마지막으로 테스트 계정의 session에서 consumer

group이 original group으로 되돌려 졌는지를 확인하는 것으로 테스트를 종료한다.




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

SHORT_GRP

Elapsed: 00:00:00.44

7.10.2.2. Using em

이와 관련한 설정을 em database control에서 하기 위해선 “Administration

Resource Plans”를 선택한다.

새로운 plan을 만들 때는 우측 중앙의 “Create”버튼을 사용하고 설정을 하려면 해당

plan을 click한다. 위에서는 “MOVE_PLAN Group Switching tab”을 click한다.


그림 7-63

Resource Plan List

그림 7-64

Plan 설정화면


이상하겠지만 위 그림에서 보듯 oracle10g의 새로운 parameter인

switch_time_in_call은 보이지 않고 이전의 switch_time(Execution Time)만

나타난다. 이는 현재 oracle10g em database control에서 지원하지 않기 때문이다.

향후에 oracle10g R2에서 이 부분이 어떻게 변화가 되는지는 여러분 각자가

살펴보시기 바란다.

7.10.3. Idle Time의 설정이 기능은 session의 idle time을 설정하여 조건을 만족하면 kill session이 되도록

하는 oralce10g의 새로운 plan directive이다. 모두 두 가지이며 session idle 시간을

check하는 max_idle_time과 session이 blocking하는 time을 check하는

max_idle_blocker_time parameter가 그것이다. Oracle의 background process

PMON은 이러한 session을 감지하여 정리해준다.

CF. 사실 PMON은 최대 1분당 1회씩 idle time을 check하기 때문에 너무 짧게 idle

time을 정하게 되면 원하는 시간만큼 짧은 시간 내에 session이 정리되지 않을 수 있다.

7.10.3.1. Session Idle Time

다음의 예는 새로운 plan directive를 갖는 consumer group “IDLE_GRP”을

만들어서 idle time과 관련한 parameter를 설정하는 것이다. 이제 session idle은 20

초 session의 blocking time은 10초로 설정하자. 테스트를 위해 최대 1분을 기다리지

않도록 설정한 것이다.



SYSTEM> exec dbms_resource_manager.create_consumer_group(-

> 'idle_grp', 'working for idle features');




SYSTEM> exec dbms_resource_manager.create_plan_directive(-

> 'move_plan', 'idle_grp',-

> 'test for idle session', cpu_p4 => 100,-

> max_idle_time => 20, max_idle_blocker_time => 10);






SYSTEM> exec


> 'xrsrc', 'idle_grp', FALSE);


이제 테스트를 위해 테스트 계정으로 login한 후 다른 창에서 system 계정으로 해당

계정의 consumer group을 “IDLE_GRP”로 변경하자.

테스트 계정 : 현재의 consumer group을 확인하고 session정보를 추출하자.




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

SHORT_GRP

XRSRC> select sid, serial# from v$session

2 where audsid = userenv('SESSIONID');



SID SERIAL#

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

522 14064

SYSTEM 계정 : 이제 위 정보를 바탕으로 테스트계정의 consumer group을 idle_grp

로 변경해 보자.

SYSTEM> exec dbms_resource_manager.switch_consumer_group_for_sess(-

> 522, 14064, 'idle_grp');


테스트 계정 : consumer group의 변동사항을 확인한다.




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

IDLE_GRP

테스트 계정 : session idle time인 20초가 경과한 후 session의 상태를 확인해 보자.

XRSRC> select sysdate from dual;

select sysdate from dual

*

ERROR at line 1:

ORA-02396: exceeded maximum idle time, please connect again

정상적으로 작동이 되고 있음을 확인할 수 있다.

7.10.3.2. Session Blocking Time

다음은 session이 blocking하는 시간을 확인하여 resource를 관리하는 plan

directive max_idle_blocker_time의 기능을 확인해 보자. 원활한 테스트를 위해

테스트계정으로 login하는 2개의 session(blocked session, blocker session)과

system계정의 session으로 작업을 진행한다.

먼저 blocker time을 확실하게 하기 위하여 위에서 만든 plan directive를 삭제한 후

다시 설정하자. 이번에는 max_idle_time은 지정하지 않고 blocker time만 10으로

지정하자.





SYSTEM> exec dbms_resource_manager.delete_plan_directive('move_plan',

'idle_grp');



'idle_grp' -;

> 'test for idle session', cpu_p4 => 100,-

> max_idle_blocker_time => 10);






테스트 계정 #1 : 현재 consumer group을 확인하자.


Connected.




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

SHORT_GRP




2 where audsid = userenv('SESSIONID');

SID SERIAL#

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

521 5005

테스트 계정 #2 : 두 번째 session을 생성한 후 앞서 만든 테스트 table에 data를

입력한다.

XRSRC> insert into rsrc_cnt values (10);

1 row created.

XRSRC> commit;

Commit complete.

SYSTEM 계정 : 이제 테스트계정 #1의 resource group을 idle_grp로 변경하자.


> 521, 5005, 'idle_grp');


테스트 계정 #1 : consumer group의 변동사항을 확인하고 table에 lock을 만들어

보자.




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

IDLE_GRP

SHORT_GRP


XRSRC> delete from rsrc_cnt;



1 row deleted.

Elapsed: 00:00:00.00

테스트 계정 #2 : 이제 위에서 lock을 잡고 있는 data에 access하여 blocking을

발생시킨다.



1 row deleted.

…………waiting………….

테스트 계정 #2 : 시간이 흐르면서 변화를 지켜본다. 현재 session의 blocking time

이 10초이니 최대 1분 안에 다음과 같이 응답이 올 것이다.


1 row deleted.

Elapsed: 00:00:30.73

테스트 계정 #1 : 이제 테스트 계정 #1이 PMON에 의해 정리되었음을 확인해 보자.

XRSRC> select sysdate from dual;

select sysdate from dual

*

ERROR at line 1:

ORA-02396: exceeded maximum idle time, please connect again

Elapsed: 00:00:00.00

이제 session의 idle과 관련한 두 가지 기능 session idle time, session locking

time이 제대로 작동되고 있음을 확인하였다.

7.10.3.3. Using em

위에서 약간은 복잡하게 처리한 idle time은 다음과 같이 em database control에서



간단히 정의할 수 있다. “Administration Resource Plans PLAN 이름 Idle

time tab” 여기서는 move_plan을 선택한 화면이다.

7.10.4. 유연한 Resource Group의 할당우리가 resource manager를 사용하는 가장 큰 이유는 resource consumer group

을 user에게 할당하고 그 user로 하여금 적절한 resource의 사용을 제한하기

위해서다. 그래서 resource group을 switch하는 기능도 필요한 것이다. 하지만 잠깐

눈을 돌려 생각해 보면 여기에도 맹점은 있다. 대개의 (특히나 3-tier의 session

pooling구조의 경우) application user가 사용하는 oracle 계정은 한, 두 개를 가지고

공유하게 되며 따라서 application 사용자는 그 수가 아무리 많더라도 그리고 아무리

다른 종류의 작업을 수행한다고 해도 동일한 oracle user를 그리고 거의(필요에 의해

혹은 switch 속성에 따라 바뀔 수도 있으니 꼭 그렇지는 않더라도) 동일한 resource

consumer group을 사용하게 된다.

A, B, C, D라는 사용자가 oracle 계정 scott을 통해 작업을 진행하면 scott의

resource consumer group이 작동을 하겠지만 각 사용자의 작업 load나 특성에 따라

유연하게 resource group이 작동해 주기를 바라는 것은 매우 어려울 것이다. 아무리

plan directive 설정을 잘 한다고 해도 그것은 resource group에 따라 변화하는

구조이기 때문이다.

Oracle10g가 이야기하는 resource mapping이란 바로 이런 문제점들을 해소해 준다.

즉, 위의 예처럼 scott이라는 계정으로 login한 A, B, C, D application users들에게

각자의 속성에 따라 각기 다른 resource consumer group을 할당하게 해줄 수 있다는

것이다. 만일, A와 C는 online(short transaction) 사용자, B는 batch(long

transaction) 사용자, 그리고 D는 DW 사용자(long-running query)라면 하나의

oracle 계정 scott을 공유한다고 해도 그 특성에 따라 적절한 resource group을

할당하면 훨씬 더 효율적인 resource관리가 가능해 질 것이다. 그래서 A, B, C, D가


그림 7-65

Plan 설정내역 확인


login할 때 oracle10g는 기 정의된 속성(resource group mapping)과 우선순위

(priority)에 따라 각기 다른 적절한 resource group을 할당해주는 기능을 제공한다.

혹시라도 여러분 중에 database logon trigger를 이용하여 session이 맺어질 때

oracle 계정과 상관없이(v$session.username) module(v$session.module)의

이름이 무엇인가에 따라 다른 resource consumer group을 할당하는 방식을 생각을

했다면 이제 접어두어도 좋겠다.

CF. 사실 database logon trigger를 이용해서 이를 구현한다고 해도 최초 login시 1

회만 resource consumer group을 바꿀 수 있음으로 3-tier환경에서 session

pooling을 사용하는 경우는 이런 trigger 개념이 맞지 않는다. 따라서 이 기능은 3-tier

session pooling을 사용하는 환경에서 매우 효율적인 resource 관리를 지원해 줄 수

있다.

다음은 resource group mapping이 가능한 속성과 그 의미에 대한 설명이다.

Item 시점 V$SESSION Description

explicit N/A 없음 사용자의 직접 설정

oracle_user Login username 접속한 oracle 계정

service_name Login service_na

me

client tnsnames.ora의

service_name

client_os_user Login osuser OS username(ex. windows

사용자이름)

client_program Login program session을 생성한 program 이름

client_machine Login machine client machine(ex. windows

컴퓨터 이름)

module_name Runtim

e

module application module name

ex.

dbms_application_info.set_mod

ule

module_name_acti

on

Runtim

e

module,

action

application module name and

action

ex.

dbms_application_info.set_

module

dbms_application_info.set_a


표 7-26

Resource Group Mapping


ction

service_module Runtim

e

service_na

me, module

service_name + module_name

service_module_act

ion

Runtim

e

service_na

me,

module,

action

service_name + module_name

+ action

7.10.4.1. Resource Group Mapping

사용법은 매우 간단하다 package sub procedure call을 통해 위 속성들 중 필요한

것을 정의만하면 되기 때문이다. 하지만 중요한 것은 application의 유형에 따라 그

속성들을 잘 알고 있어야만 적절한 속성에 적절한 resource group이 가능하다는

점이다.

다음은 resource mapping을 통해 동일한 계정(동일한 initial resource consumer

group을 갖는)으로 login해도 그 결과가 달라지는 것을 확인해 보자.

먼저 resource mapping을 해보자.

SYSTEM> exec dbms_resource_manager.clear_pending_area();


SYSTEM> exec dbms_resource_manager.create_pending_area();


SYSTEM> exec dbms_resource_manager.set_consumer_group_mapping(-

> dbms_resource_manager.module_name, 'MAP_LONG_QUERY',

'LONG_GRP');


SYSTEM> exec dbms_resource_manager.submit_pending_area();




이제 현재 테스트를 진행하고 있는 계정 xrsrc로 login을 하자.


Connected.

XRSRC> select resource_consumer_group from v$session

2 where audsid = userenv('sessionid');


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

SHORT_GRP

이제 application module의 이름을 앞서 resource group mapping에 사용한

이름으로 설정한 후 그 변화를 확인해 보자.

XRSRC> exec dbms_application_info.set_module(-

> 'MAP_LONG_QUERY', '1st Action');





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

LONG_GRP

CF. 사실 어떤 사용자의 initial resource consumer group을 설정하면 자동으로 해당

계정이 oracle_user의 속성으로 등록이 된다. 따라서 위 xrsrc 계정은 oracle_user에

이미 mapping이 되어있는 것이며 다만 다음에 설명하는 우선순위에서

module_name이 oracle_user보다 더 높은 순위를 가지고 있기 때문에 위와 같은

결과가 나온 것이다. 이를 확인해 보기 위해 “dba_rsrc_group_mappings”를 참조해

보라.

CF. 각 계정이 각각 oracle_user로 mapping이 되어있다는 말은 곧 resource group

을 mapping하는 각각의 parameter는 resource group과 상관없이 복수로 설정이

가능하다는 의미가 된다. 예를 들어 module_action의 값을 10가지로 정하고 각기

다른 resource group을 mapping해도 된다는 뜻이다. 물론, 이렇게 되면 application



에서 module혹은 action을 변경할 때마다 resource group이 계속해서 변경될

것이다.

CF. 위 mapping items 중에는 복수의 combination 구성이 있다. 즉, module name

과 action을 설정하거나, service name과 module등으로 구성하는 것이 그것이다.

이런 구성으로 resource를 mapping하기 위해서는 “.”을 사용해서 구분하면 된다.

다음의 예는 module_action의 값을 구현하기 위하여 “.”을 사용하는 방식이다.


> dbms_resource_manager.module_name_action,-

> 'MAP_LONG_QUERY.1st_Action', 'IDLE_GRP');

7.10.4.2. Resource Group Priority

다음은 이런 resource group의 속성과 priority사이의 연관성을 확인해 보자. 만일

필요에 의해 여러 가지의 resource group 속성을 설정했다면 어떤 것이 resource

consumer group을 설정하는데 가장 중요한 것인지 알 수가 없을 것이다. 예를 들어

저녁 6시까지는 module에 따라 long_grp를 할당 할 필요가 있고 그 이후에는

service_name에 따라 oracle이 default로 제공하는 default_consumer_group을

할당할 필요가 있다고 생각해 보자. 그렇다면 저녁 6시에 resource consumer group

의 priority를 조정하는 것으로 이 문제가 해결될 것이다.

또는 매번 priority를 조정하지 않고 최초 1회만 priority정책을 수립하는 방법도

생각해 볼 수 있다. 예를 들어 동일한 module name “GENERAL”이 설정된 #1, #2

application이 있다고 가정하자. 그리고 다음과 같은 resource consumer group의

할당정책을 세운다.

1. module이 “GENERAL”이면 resource consumer group 은 “A”

2. 위 1의 조건을 만족하고 action이 “BATCH”면 resource consumer group은 “B”

3. 우선 순위는 먼저 module_name_action, 그 다음은 module_name이다.

이때에 #1 application의 action이 “ONLINE”이고 #2 application의 action이

“BATCH”라면 #1 application은 group “A”를 #2 application은 group “B”를 할당

받을 것이다.

간단하게 priority를 조정하여 resource consumer group의 변화를 확인해 보자.

다음은 앞서 설정한 module_name 속성을 그대로 두고 service_name의 속성을

추가한 후 그 우선순위를 module_name이 service_name보다 높게 설정한 것이다.








> dbms_resource_manager.service_name,-

> 'NEWSVC', 'DEFAULT_CONSUMER_GROUP');


SYSTEM> exec dbms_resource_manager.set_consumer_group_mapping_pri(-

> explicit => 1, service_module_action => 2,-

> service_module => 3, module_name => 4,-

> module_name_action => 5, service_name => 6,-

> oracle_user => 7, client_program => 8,-

> client_os_user => 9,client_machine => 10);




이제 테스트 계정으로 다음과 같이 두 가지 방식의 session을 연결해 보자. 첫 번째는

보통의 connection이고 두 번째는 tnsnames.ora를 이용하여 listener를 통해

연결하는 것이다. 이 resource consumer group의 변화를 살펴보자.


Connected.






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

SHORT_GRP

XRSRC> conn xrsrc/xrsrc@newsvc

Connected.




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

DEFAULT_CONSUMER_GROUP

첫 번째 connection에서는 module name도 설정하지 않았고 또한 local

connection임으로 service_name도 없기 때문에 initial resource consumer group

인 short_grp가 할당되었다. 두 번째 connection은 listener를 통해 연결하였고

module name이 없음으로 앞서 설정한 정책에 따라 default_consumer_group이

할당되었다. 이제 module name을 설정한 후 그 결과를 보자.

XRSRC> exec dbms_application_info.set_module(-

> 'MAP_LONG_QUERY', '2nd Action');





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

LONG_GRP

이제 module name을 설정하였고 module_name의 우선 순위가 service_name의

우선 순위보다 높음으로 long_grp가 할당되었음이 확인된다. 다음은 system 계정의

창에서 이 우선순위를 반대로 바꾸는 과정이다. 우선순위의 속성인 service_name과

module_name의 순위를 서로 맞바꾸어 보자.
















이제 다시 테스트 계정으로 가서 어떤 변경이 있는지 확인하자.




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

DEFAULT_CONSUMER_GROUP

우선순위의 변경으로 resource consumer group의 변경도 확인된다. 하나 더 확인해

보자. 이번에는 우리가 직접 설정하지는 않았던 oracle_user의 우선순위를

service_name과 맞바꾸어 보자.
















이제 또다시 테스트 계정의 창으로 이동하여 그 변화를 확인해 보자.




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

SHORT_GRP

원래의 initial resource consumer group으로 변경이 되었다. 앞서도 잠깐 언급이

되었지만 initial group을 할당함과 동시에 resource mapping이 일어난 것을 어렵지

않게 추측할 수 있을 것이다.

마지막으로 직접 consumer group을 변경했을 때(explicitly) 우선순위의 변경에 따라

그 변화를 확인해 보자. 먼저 테스트 계정의 창에서 새로 login을 하여 resource

consumer group을 확인하고 system 창에서 explicit의 우선순위가 어떤지 보자.

테스트 창 :


Connected.






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

SHORT_GRP

SYSTEM 창 :

SYSTEM> select priority from dba_rsrc_mapping_priority

2 where attribute = 'EXPLICIT';

PRIORITY

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

1

이제 테스트 창에서 직접 resource group을 변경하여 제대로 바뀌고 있는지 확인해

보자.

테스트 창 :

XRSRC> var oldgrp varchar2(30)

XRSRC> exec dbms_session.switch_current_consumer_group(-

> 'IDLE_GRP', :oldgrp, FALSE);





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

IDLE_GRP

XRSRC> exec dbms_application_info.set_module('MAP_LONG_QUERY',-

> 'TEST ACTION');







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

IDLE_GRP

제대로 변경이 되었음을 물론 최 상위 priority로 인하여 앞서 생성했던

module_name의 설정도 반영되지 않고 있음을 알 수 있다.

이제 system창에서 explicit의 priority를 가장 낮은 10단계로 변경한 후 테스트

창에서의 변화를 보자.

SYSTEM 창 :
















테스트 창 :




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

LONG_GRP

위 결과는 자동으로 explicit보다 상위에 있는 module_name이 적용되어 resource

group이 저절로 변화 했음을 보여준다.

이제 앞에서처럼 직접 resource group의 변경을 시도해 보자.

테스트 창 :

XRSRC> exec dbms_session.switch_current_consumer_group(-

> 'IDLE_GRP', :oldgrp, FALSE);





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

LONG_GRP

위 결과는 explicit의 우선순위가 낮기 때문에 resource consumer group의 변경이

안되고 있음을 보여준다.

그런데 한가지 주의할 점이 있다. 만일 여러분이 위에서처럼 자기자신의 resource

consumer group을 변경하는 것이 아니라 system과 같은 다른 창에서 자신의

resource consumer group을 바꾸는 행위가 발생하면 이 것은 우선순위와 상관없이

반영이 된다는 사실이다. 예를 들어 위 상태에서 system창으로 가서 테스트 창의

resource consumer group을 변경해 본 후 그 결과를 테스트 창에서 확인해 보자.

테스트 창:





SID SERIAL#

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

534 10892

SYSTEM 창:


> 534, 10892, 'IDLE_GRP');


테스트 창 :




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

IDLE_GRP

위에서 resource consumer group이 바뀌는 것을 확인할 수 있다. 즉, 다른 창에서

명시적으로 resource consumer group을 변경하는 procedure는 resource

mapping 우선순위보다 더 우선하고 있음을 알 수 있다.

이와 같은 현상은 session단위가 아닌 전체 user를 대상으로 resource를 변경하는

procedure를 사용해도 동일한 결과를 볼 수 있다. 다음의 예를 system창에서 해본 후

각자 테스트 창에서 resource consumer group의 변화를 확인해 보라.

SYSTEM> exec dbms_resource_manager.switch_consumer_group_for_user(-

> 'XRSRC', 'DEFAULT_CONSUMER_GROUP');

CF. 현재의 resource consumer group할당의 우선순위를 확인하고 싶다면 이 정보를

가지고 있는 “dba_rsrc_mapping_priority”를 확인해 보기 바란다.

CF. 현재 설정된 mapping을 취소하고자 할 때에는

dbms_resource_manager.set_consumer_group_mapping procedure를 call



하면서 취소하고자 하는 속성을 명명하고 3번째 parameter인 consumer_group을

NULL을 설정하면 된다.

7.10.4.3. Using em

다음은 위에서 설정한 resource consumer group의 mapping을 em database

control에서 어떻게 하는지 알아보자. 먼저, “Administration Resource

Consumer Group Mappings (General)”을 선택한다. 그러면 아래와 같은

화면에서 원하는 mapping item을 찾아 “Add Another Row”를 click하면 resource

mapping을 추가할 수 있다.

위와 동일한 방식으로 위의 “Priorities”를 선택하면 다음과 같은 화면에서 우선순위도

설정할 수 있다.


그림 7-66

Resource Mapping


원하는 item을 선택한 후 화살표 모양의 버튼을 이용하여 아래위로 이동한 후 “Apply”

를 하면 변경된 우선순위가 반영된다.

7.10.5. New Resource 할당 방법

7.10.5.1. CPU 할당 방식Oracle10g는 새로운 방식의 CPU 자원분배 및 할당을 consumer group과 plan level

에서 설정할 수 있다.

1. create_consumer_group(cpu_mth => ‘RUN-TO-COMPLETION’) : 이는 동일

consumer group내 sessions이 CPU 자원을 분배 받는 방식을 뜻한다. 일반적인 CPU

분배방식이 “ROUND-ROBIN”방식이기 때문에 동일 group내 sessions은 모두

균등하게 자원을 할당 받고자 한다. Oracle10g가 consumer group에서 새로

소개하는 CPU 분배방식인 “RUN-TO-COMPLETION”은 동일 group내 sessions중

active 시간이 많은 session이 다른 sessions보다 먼저 분배 받는 방식을 뜻한다.

2. create_plan(cpu_mth => ‘RATIO’) : 이는 CPU 자원을 할당하는 방식을

정의한다. Oracle10g가 새롭게 소개하는 “RATIO”방식은 하나의 level로만 CPU를

할당하는 single-level plan을 만드는 것으로 무조건 정해진 percent로 CPU

자원할당을 하는 기존의 방식과 달리 현재 active한 sessions에 비례하여 CPU의

자원을 할당하는 것이다. 이는 특정한 값을 정하는 것이 아니라 비율로 할당하기 때문에

반드시 cpu_p1만 설정이 가능한 single-level plan에 적용된다. 따라서 기존의 multi-

level plan에 주로 사용하는 방식인 default “EMPHASIS”와 달리 level 1 CPU만을

(cpu_p1) 비율로 할당하여 single-level plan을 설정하는 이 방식을 “RATIO”방식이라

부른다.


그림 7-67

Resource 우선순위


CF. 물론, “EMPHASIS”방식으로 single-level plan을 만든다고 문제될 것은 없다.

7.10.5.2. CPU RATIO 할당의 예다음은 새로운 group을 만들 때 oracle10g의 새로운 CPU 할당 방식을 사용해 보자.





SYSTEM> exec

dbms_resource_manager.create_consumer_group('XRTC_CPU_GRP',-

> 'New CPU appliction to complete', 'RUN-TO-COMPLETION');




다음은 새로운 plan을 만들어 ratio 방식의 CPU 설정을 해보자. 다음의 예는 앞서

테스트를 통해 만들어진 group을 새로운 plan에 적용하면서 ratio 방식의 CPU 사용을

설정한 것이다.





SYSTEM> exec dbms_resource_manager.create_plan('XRATIO_PLAN',-

> 'Plan for Ratio Policy', 'RATIO');





> 'xratio_plan', 'short_grp', '1st grade', cpu_p1 => 4);



> 'xratio_plan', 'long_grp', '2nd grade', cpu_p1 => 3);



> 'xratio_plan', 'idle_grp', '3rd grade', cpu_p1 => 2);



> 'xratio_plan', 'other_groups', 'other grade', cpu_p1 => 1);




새로 생성한 plan은 총 4가지의 sub-group을 통해 자원할당을 하도록 되어있다.

그리고 그 비율을 4:3:2:1로 하였다. 따라서 이 4가지 group과 관련한 sessions이

모두 running이면 이 비율이 그대로 유지됨으로 총 CPU할당은 40%, 30%, 20%,

10%가 될 것이다. 그러나 예들 들어 idle_grp와 other_groups가 running하지

않으면 이 비율은 4:2가 될 것이고 총 CPU할당은 대략 67%(4/6), 33%(2/6)가 될

것이다.

위 방식은 single-level plan만을 설정함으로 다음과 같이 single-level resource

plan을 설정하는데 도움을 주는 create_simple_plan procedure를 사용하여 같은



작업을 해보자.

SYSTEM> exec dbms_resource_manager.create_simple_plan (-

> simple_plan => 'SINGLE_PLANX',-

> consumer_group1 => 'short_grp', group1_cpu => 4,-

> consumer_group2 => 'long_grp', group2_cpu => 3,-

> consumer_group3 => 'idle_grp', group3_cpu => 2,-

> consumer_group4 => 'other_groups', group4_cpu => 1);

BEGIN dbms_resource_manager.create_simple_plan ( simple_plan =>

'SINGLE_PLAN1', consumer_group1 => 'short_grp', group1_cpu => 4, c

onsumer_group2 => 'long_grp', group2_cpu => 3, consumer_group3 =>

'idle_grp', group3_cpu => 2, consumer_group4 => 'other_groups',

group4_cpu => 1); END;

*

ERROR at line 1:

ORA-29364: plan directive SINGLE_PLAN1, OTHER_GROUPS already exists

ORA-06512: at "SYS.DBMS_RESOURCE_MANAGER", line 686

ORA-06512: at line 1


> simple_plan => 'SINGLE_PLANX',-



> consumer_group3 => 'idle_grp', group3_cpu => 2);


위 결과를 보면 보통의 plan directive설정과 달리 pending area를 따로 지정할

필요가 없으며 other_groups도 지정하지 않는다는 것을 알 수 있다. 그렇다면 위

방식은 우리가 앞서 했던 plan의 할당과 동일한 결과를 가져올까! 사실 그렇지 않다.

현재 위 방식은 CPU method가 지정되지 않은 상태이며 지정할 수 있는 parameter도

없다. 아래처럼 먼저 RATIO 방식을 사용하는 plan을 생성하여 이를 지정하는 simple

plan을 해보자.





SYSTEM> exec dbms_resource_manager.create_plan('single_plan',-

> 'single ratio', 'RATIO');



> simple_plan => 'SINGLE_PLAN',-



> consumer_group3 => 'idle_grp', group3_cpu => 2);


이제 관련 view를 통해 CPU method를 확인하자.

SYSTEM> select plan, cpu_method from dba_rsrc_plans

2 where plan in ('XRATIO_PLAN', 'SINGLE_PLAN', 'SINGLE_PLANX');

PLAN CPU_METHOD

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

XRATIO_PLAN RATIO

SINGLE_PLAN EMPHASIS

SINGLE_PLANX EMPHASIS

위 결과를 보면 create_simple_plan을 통한 plan directive CPU 설정은 무조건

기존의 “EMPHASIS”방식을 사용한다는 것을 알 수 있다. 또한 이 procedure는 CPU

분배 방식도 “ROUND_ROBIN”방식을 사용하도록 되어있다. 그렇다면 이제 실제

생성된 directive는 어떤지 확인해 보자.

SYSTEM> col plan for a12

SYSTEM> col group_or_subplan for a12

SYSTEM> col comments for a20

SYSTEM> col p1 for 999





SYSTEM> select plan, group_or_subplan, cpu_p1 p1,

2 cpu_p2 p2, cpu_p3 p3, comments

3 from dba_rsrc_plan_directives

4 where plan in ('XRATIO_PLAN', 'SINGLE_PLAN', 'SINGLE_PLANX')

5 order by 1, 2, 3 desc, 4 desc;

PLAN GROUP_OR_SUB P1 P2 P3 COMMENTS

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

SINGLE_PLAN IDLE_GRP 0 2 0 Level 2 Group 3

SINGLE_PLAN LONG_GRP 0 3 0 Level 2 Group 2

SINGLE_PLAN OTHER_GROUPS 0 0 100 OTHER_GROUPS Level 3

SINGLE_PLAN SHORT_GRP 0 5 0 Level 2 Group 1

SINGLE_PLAN SYS_GROUP 100 0 0 SYS Level 1

SINGLE_PLANX IDLE_GRP 0 2 0 Level 2 Group 3

SINGLE_PLANX LONG_GRP 0 3 0 Level 2 Group 2

SINGLE_PLANX OTHER_GROUPS 0 0 100 OTHER_GROUPS Level 3

SINGLE_PLANX SHORT_GRP 0 5 0 Level 2 Group 1

SINGLE_PLANX SYS_GROUP 100 0 0 SYS Level 1

XRATIO_PLAN IDLE_GRP 2 0 0 3rd grade

XRATIO_PLAN LONG_GRP 3 0 0 2nd grade

XRATIO_PLAN OTHER_GROUPS 1 0 0 other grade

XRATIO_PLAN SHORT_GRP 4 0 0 1st grade

14 rows selected.

위 결과를 통해 “RAITO”방식의 “XRATIO_PLAN”은 모두 cpu_p1만으로 설정되었고

(level 1 only single-level plan) 나머지는 create_simple_plan을 통해 다음과 같은

default 규칙이 적용되었다. 우선 “SYS_GROUP”은 cpu_p1에 100%, cpu_p2는 plan

설정 시 기술된 값대로 그리고 cpu_p3에 other_groups에 100%가 설정된 것이다.

따라서 위 single_plan, single_planx의 CPU는 비율이 아니라 percent로 할당되었기

때문에 cpu_p2는 2%, 3%, 5%밖에 안 되는 값으로 지정된 것이다.

CF. 사실 create_simple_plan이 최대 8개 groups까지 single-level resource plan

을 쉽게 구현하기 위해 만들어진 procedure이지만 그 내용을 보면 이는 모두 level2



에만 적용이 되는 것이고 level 1은 “SYS_GROUP”을 위해 level 3은

“OTHER_GROUPS”을 위해 자동으로 CPU 100%가 설정됨을 확인할 수 있다. 따라서

엄밀히 말하면 create_simple_plan은 level 2에만 적용되는 single-level plan이라

할 것이다.

CF. 앞서 소개했던 oracle10g위 “switch_time_in_call”과 마찬가지로 oracle10g의

new CPU 할당 method parameter “cpu_mth”의 설정이 em database control

에서 지원하고 있지 않다. Oracle의 em은 여러 가지 이유로 모든 database 기능을 다

지원하지는 않는다는 점을 인식하도록 하자. 이런 부분들은 각자 oracle10g R2와

같이 새로운 version이 나올 때 마다 em에서의 변화도 확인하는 습관을 갖도록 하자.

7.10.6. Monitoring Resource Manager

앞서 resource consumer group의 상태를 확인하면서 사용한 view

“v$rsrc_consumer_group”의 내용을(switch time에 대한 예를 들면서 다룬바 있다)

em database control에서 보면 아래와 같이 graph와 함께 사용자에게 보기 편하게

monitoring을 해준다. Resource consumer group별 CPU time과 wait time

그리고 여러 정보를 한 눈에 볼 수 있다.


그림 7-68

Resource Monitor


OCP point

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

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

1. switch_time_in_call과 top call의 의미

2. idle time의 두 가지 parameters의 의미

3. resource group을 mapping하고 priority를 설정하는 방법

4. resource group의 priority 종류 10가지

5. 새로 추가된 CPU 할당방식의 종류와 의미

참조

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

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

resource manager, consumer group, plan directive : o8i 105p, o9i 112p

switch_time : o9i 115p



7.11.Space 관리 자동화

7.11.1. 개요보통 oracle에서의 공간관리의 문제는 file system(또는 OS)의 문제가 아니라면

대부분 tablespace의 공간관리와 segment의 extent관리에서 나타난다. 지속적으로

oracle이 upgrade 되면서 locally managed tablespace(oracle8i), resumable

tablespace(oracle9i), automatic segment 관리(oracle9i)등으로 space관리에

대한 향상된 기능들이 탑재되고는 있지만 이는 효율적인 관리를 해주기는 하지만

문제를 해결해 주지는 않았다.

Oracle10g의 새로운 기법은 문제를 경고하고 advisor를 통해 해결방식을 제시하는

보다 진보적인 구조를 가지고 있다.

7.11.2. Tablespace

사실 우리는 tablespace의 공간관리와 관련한 문제의 대부분을 앞서 “Alert” 부분을

다루면서 이미 설명하고 테스트를 진행한 바 있다. 굳이 다시 정리하자면 tablespace

와 관련한 공간관리는 “Alert”를 통한 message설정하고 이를 확인하는 작업이라

하겠다.

다음은 tablespace usage를 monitoring하고 alert를 발생시키는 기능의 기본

속성이다.

1. tablespace usage는 default 85%는 warning, 97%는 critical이다.

2. read-only 혹은 offline tablespace에 대해서는 alert를 보내지 않는다.

3. temporary tablespace의 usage는 곧 현재 sessions에 의해 점유되고 있는 size

다.

4. undo tablespace의 usage는 곧 active 혹은 unexpired extents의 size다.

5. 설정된 tablespace의 datafile이 autoextensible 속성을 가지고 있으면 usage

계산은 해당 file에 지정된 maximum file size나 OS상의 maximum size를 기준으로

한다.

7.11.2.1. Tablespace Usage

이미 살펴본 내용이지만 em database control의 tablespace 화면에서 이를

확인하는 것도 가능하다. 초기 em화면에서 “Administration

Tablespaces(Storage)”를 보면 다음과 같이 한눈에 대략적인 usage확인이 가능하다.



여기서 주요 관심이 있는 tablespace를 직접 click하면 다음과 같은 화면에서 다양한

속성을 정의할 수 있게 된다. 예를 들어 위에서 “AUTOTBS”를 click하면 다음과 같은

화면을 볼 수 있다.

우측 상단의 “Thresholds” tab을 선택하면 바로 다음과 같은 화면에서 앞서 이야기한

usage에 대한 속성을 편집할 수 있게 된다.


그림 7-69

Tablespace Monitor

그림 7-70

Tablespace Monitor


의 내용을 보면 tablespace 전체에 대한 default와 해당 tablespace만 따로 지정하는

방법, 그리고 아예 monitoring을 하지 않도록 disable하는 방법을 선택할 수 있도록

되어 있다. 물론, 여기서의 설정은 앞서 “Alert”부분에서 이미 설명한 바 PL/SQL을

통해 직접 하는 것도 가능하다.

7.11.2.2. Threshold의 설정과 의미이미 앞서 “Alert”를 설명하면서 살펴본 바 있으나 정리하는 차원에서 threshold의

설정을 살펴보자.

1. 다음은 특정 tablespace usage를 warning 50, critical 80로 설정하는 것이다.

exec dbms_server_alert.set_threshold( -





2. 다음은 특정 tablespace usage의 warning, critical value를 default인 85, 97로

하겠다는 의미이다.



> NULL,NULL, NULL, NULL, 1, 1, NULL, -


그림 7-71

Tablespace Monitor



3. 다음은 지정한 tablespace에 대하여 usage monitoring을 하지 않겠다는

의미이다.

(앞서 잠깐 언급했던 read-only, offline tablespace를 생각해 보라)



> dbms_server_alert.OPERATOR_DO_NOT_CHECK,'0', -

> dbms_server_alert.OPERATOR_DO_NOT_CHECK,'0', 1, 1, NULL, -


4. 다음은 database 전체에 걸쳐서 모든 tablespace usage의 monitoring 값을

warning 50, critical 80으로 변경한다는 의미이다.





> dbms_server_alert.OBJECT_TYPE_TABLESPACE, NULL);

5. 다음은 tablespace usage의 monitoring 값을 database 전체 default인

warning 85, critical 97로 원상복구 하겠다는 의미이다.



> NULL,NULL, NULL, NULL, 1, 1, NULL, -

> dbms_server_alert.OBJECT_TYPE_TABLESPACE, NULL);

7.11.3. Segment와 Block 관리방식

7.11.3.1. Segments내부의 관리방식 변화다음 그림은 table 생성 후 insert가 지속적으로 발생하고 나서 random하게 delete가

발생했다는 가정하에 일반적인 segment의 변화와 oracle10g에서의 기능을

순차적으로 표현한 것이다.



위 그림은 전형적인 oracle의 segment관리를 보여준다. 즉, oracle9i까지의 방식과

oracle10g의 새로운 기능의 차이를 확연하게 보여주고 있다. 위 그림의 첫 번째 부분은

insert가 발생해서 HWM이 증가하였고 두 번째 그림은 delete로 인해 free block이

생기더라도 HWM이 줄어들지 않고 있는 block관리 정책을 보여준다.

이러한 segment관리는 oracle로 하여금 다음과 같은 space관리속성의 한계점을

나타나게 하며 이런 문제를 해소하기 위하여 위 그림의 세 번째 부분과 같은 기능이

출현하게 된 것이다.

1. full table scan이 필요한 경우 위 그림의 첫 번째나 두 번째나 모두 HWM이 같기

때문에 읽어야 하는 disk I/O는 변함이 없다.

2. direct path를 사용한 SQL hint나 SQL*Loader등으로 data insert가 발생하면

모두 HWM 이후에 data가 생성됨으로 HWM 이전의 free block은 여전히 비어있다.


그림 7-72

Segment 관리체계


3. 이런 free block의 정리는(fragmentation 제거 혹은 reorganization) table

재생성을 위한 export & import, alter table move와 같은 방식으로 가능하지만

이는 offline이라는 한계점을 갖는다.

4. online상에서 이를 해소하기 위하여 online table redefinition을 할 수 있으나,

이는 space를 원본 table의 최소 두 배 공간이 필요하며 역시나 업무시간에 작업을

하기에는 부담이 있다.

Oracle10g의 공간관리 자동화(ASSM : Automatic Segment Space Management)

를 tablespace에 설정하면 위 그림의 세 번째 부분과 같이 oracle 스스로 segment

shrink를 통해 새로 정리된 free block을 제대로 재활용할 수 있게 해준다.

7.11.3.2. Shrink Segment 속성Oracle10g의 ASSM의 작동을 제대로 활용하기 위해서는 다음과 같은 ASSM 속성들을

이해해야 한다.

1. oracle9i에서 소개했던 online table redefinition처럼 작업을 위한 별도의 작업용

space 필요 없이 online으로 segment 안에서 이루어지는 operation이다. (이를

oracle은 online and in-place operation이라 부른다)

2. 사실 block관리의 효율화를 위해 ASSM을 설정하는 것은 이미 oracle9i에서

제공하는 oracle9i의 new feature이다. 따라서 oracle10g의 shrink 기능도 이 ASSM

의 제한을 따라야 한다. 즉, free list를 사용하지 않는 ASSM 속성을 지정한 locally

managed tablespace에서만 사용이 가능하다.

3. shrink기능은 주로 heap or iot tables, partitions, indexes, MViews를 위해 주로

사용하며 다음과 같은 objects는 shrink되지 않는다.

Cluster tables, long column이 있는 tables, on-commit MViews, rowid를

사용하는 MViews, LOB segments, IOT mapping tables, IOT overflow

segments, function based index를 가진 tables

4. block내부에서 row의 이동이 일어남으로 “row movement”속성을 가져야 하며

따라서 rowid가 변경될 수 있음으로 rowid를 기반으로 하는 trigger는 disable되어야

한다.

5. shrink 작업이 online operation임으로 대상 table에 속한 index도 자동으로

정리되어 shrink 발생 후에도 여전히 usable 상태를 유지한다.

6. 사실 shrink operation은 oracle internally 사용되는 대상 table에 대한

insert/delete를 통해 이루어진다. 다만, 이렇게 내부적으로 사용되는 insert/delete는

실질적인 data변경을 발생시키지 않기 때문에 DML trigger를 fire하지는 않는다.

CF. index가 자동으로 정리되는 것도 사실은 내부적인 insert/delete operation이



발생하기 때문이 아닌가 생각된다.

CF. segment가 shrink됨으로써 얻을 수 있는 부수적인 효과로 migrated rows의

수가 적어질 가능성이 있다. 그러나 row chaining은 block의 size와 상관이 있음으로

이 shrink와는 별개의 문제이다.

7.11.3.3. Shrink Command, 속성, Oracle9i Coalesce

Segment에 대한 shrink 작업은 shrink command로 이루어 진다. 두 가지 형식을

사용하게 된다. 첫 번째 형식은 다음과 같고 이 command는 shrink는 하되 HWM을

재조정하지 않고 free blocks을 재생성 한다.

SQL> alter table table_name shrink space [cascade] compact;

다음의 형식은 shrink와 함께 HWM을 최소값으로 재조정하고 free blocks을 모두

free space로 database에 반환한다.

SQL> alter table table_name shrink space [cascade];

CF. cascade option을 사용하면 대상 table의 dependent objects에 대해서도

동일한 operation을 수행한다. 단, dependent objects 중 MViews, LOB index, IOT

mapping tables, IOT overflow와 같은 것은 cascade되지 않는다. 작업이 끝난 후

직접 조정을 해주어야 할 것이다.

결국 위 두 command는 fragmentation을 없애는(defragmentation) 단계와 space

를 반환하는 단계로 나뉘어질 수 있다. 두 번째 command는 이 모든 것을 한번에

처리해 줄 수 있지만 각 사용자마다 혹은 사용하는 table의 성격에 따라 또는 어쩔 수

없이 첫 번째 단계의 command만 필요할 수도 있다. 따라서 각자 처한 상황에 맞게

적절한 command를 선택하여 사용해야 한다. 그럼 어떤 경우에 이를 구분하여

사용하는 것이 좋을까! 물론, 이 작업이 online operation이기는 하지만 data가

많으면 많을수록(fragmentation이 많으면 많을수록) 시간도 오래 걸리고 어느 정도의

trade off는 감수를 해야 한다.

1. 첫 번째 SQL처럼 compact option을 사용하는 경우 peak time과 같이 일반적으로

업무가 집중되는 시간이나 cursor invalidation을 일으키고 싶지 않을 때 사용한다. 즉,

이 시간 동안 다른 DML이나 (long running)query는 아무런 문제가 없다. 또한

compact가 진행되는 동안 oracle은 해당 segment의 bitmap block에 shrink

상태를 저장해 놓아서 나중에 compact option없이 shrink space를 진행할 때 oracle

은 스스로 compact 작업이 필요 없다는 것을 알 수 있게 된다.

2. 두 번째 SQL이 수행되는 동안 HWM이 이동될 때 매우 짧은 시간이기는 하지만 해당



object에 대한 exclusive lock을 잠깐 획득해야 하며 동시에 dependent cursor는

invalidate된다.

다음의 command 형식을 기억해 보자. 다음의 내역은 실제로 수행한 것이 아니라 이

책의 전작인 oracle9i new features에서 따온 것이다.

SQL> alter table emp_iot coalesce;

Table altered.

SQL> alter index ik_empname_iot_2nd coalesce;

Index altered.

위 내용은 oracle9i에서 space 관리의 효율화를 위해 소개했던 oracle9i new

feature의 일부이다. 첫 번째 SQL은 iot table에 대한 coalesce이고 두 번째 SQL은

index에 대한 coalesce의 예이다. 다시 말해 space를 효율화 하는 기능은 이미

oracle9i에서 시작되었다.

위 두 command의 예(index, iot coalesce)는 아래와 같은 oracle10g의 new

feature와 같은 역할을 한다.

SQL> alter table|index ..name.. shrink space compact ;

7.11.3.4. Shrink Example

다음은 특정 table에 data를 생성한 후 fragmentation의 변화와 block의 변화를

확인하는 과정이다. 이 table은 shrink 기능을 확인하기 위하여 계속 사용될 것이다.

또한 여기서 사용되는 package dbms_space 역시 이미 이 책의 전작인 oracle9i

new features에서 새롭게 소개된 tablespace의 segment관리 방식을 설명하면서

사용한 것이다. 먼저 table 생성 insert space check를 해보자.

SCOTT> create table x_shrink_obj (sno number);

Table created.

SCOTT> begin

2 for i in 1..300000 loop

3 insert into x_shrink_obj values (i*100);

4 end loop;



5 end;

6 /


SCOTT> commit;

Commit complete.

SCOTT> var unfbs number

SCOTT> var unfbt number

SCOTT> var fs1bs number

SCOTT> var fs1bt number







SCOTT> var fbs number

SCOTT> var fbt number

SCOTT> set serveroutput on

SCOTT> begin

2 dbms_space.space_usage('SCOTT', 'X_SHRINK_OBJ',

'TABLE', :unfbs, :unfbt,

3 :fs1bs, :fs1bt, :fs2bs, :fs2bt, :fs3bs, :fs3bt, :fs4bs, :fs4bt, :fbs, :fbt);

4 dbms_output.put_line('FS1 BLK = '||:fs1bs||' BTS = '||:fs1bt);




8 dbms_output.put_line('Full BLK = '||:fbs||' BTS = '||:fbt);

9 end;

10 /

FS1 BLK = 0 BTS = 0

FS2 BLK = 0 BTS = 0



FS3 BLK = 0 BTS = 0

FS4 BLK = 48 BTS = 393216

Full BLK = 454 BTS = 3719168


SCOTT> select blocks from user_segments

2 where segment_name = 'X_SHRINK_OBJ';

BLOCKS

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

512

위 결과는 총 512개의 blocks 중에서 free space의 4단계(75 ~ 100%) 48개의

block과 full blocks 454개를 제외한 다른 blocks은 block내에 free space가 아예

없거나 사용되지 않았음을 보여준다.

다음으로 random하게 delete를 발생시킨 후 blocks의 상태변화를 확인하자. 이

부분은 테스트 장비의 성능에 따라 결과를 확인하는데 시간상 큰 차이가 있을 수 있다.

그래서 index를 만들거나 각자 알아서 delete의 범위를 설정하도록 하자.

SCOTT> create index ik_xshrink_obj on x_shrink_obj(sno);

Index created.

SCOTT> begin

2 for i in 10001..20000 loop

3 delete from x_shrink_obj where sno = i*100;

4 end loop;

5 for i in 30001..50000 loop


7 end loop;

8 for i in 200000..250000 loop


10 end loop;

11 end;



12 /


SCOTT> commit;

Commit complete.

SCOTT> begin









9 end;

10 /

FS1 BLK = 0 BTS = 0

FS2 BLK = 2 BTS = 16384

FS3 BLK = 3 BTS = 24576

FS4 BLK = 166 BTS = 1359872

Full BLK = 331 BTS = 2711552




BLOCKS

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

512

위 결과는 block내의 fragmentation이 발생했음을 보여준다. 이는 delete를 통해



block내 rows가 부분적으로 free space로 변화했다는 것이며 oracle block관리

특성상 blocks의 수도 변화가 없다는 것을 알 수 있다.

이제 shrink를 위해 row movement 속성을 추가하고 compact 기능을 사용해 보자.

그리고 그 결과를 확인하자.

SCOTT> alter table x_shrink_obj enable row movement;

Table altered.

SCOTT> alter table x_shrink_obj shrink space compact;

Table altered.

SCOTT> begin









9 end;

10 /

FS1 BLK = 0 BTS = 0

FS2 BLK = 1 BTS = 8192

FS3 BLK = 0 BTS = 0

FS4 BLK = 0 BTS = 0

Full BLK = 325 BTS = 2662400






BLOCKS

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

512

위 결과는 총 blocks의 수는 줄지 않았어도 segment에서 현재 사용되고 있는 blocks

의 수는 줄어들었음을 보여준다. 즉, 내부 free space가 정리가 되었다는 것이고

delete후 발생한 shrink compaction의 결과로 blocks이 모두 full blocks이고 단지 1

개만인 25 ~ 50%의 free space를 갖는 block으로 변했다.

다음은 shrink space를 수행하여 그 결과를 확인하는 과정이다.

SCOTT> alter table x_shrink_obj shrink space;

Table altered.

SCOTT> begin









9 end;

10 /

FS1 BLK = 0 BTS = 0

FS2 BLK = 1 BTS = 8192

FS3 BLK = 0 BTS = 0

FS4 BLK = 50 BTS = 409600

Full BLK = 325 BTS = 2662400






BLOCKS

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

384

Free space 공간이 database로 return되어 HWM이 줄어들었음을 segment내

blocks 수의 변화로도 알 수가 있다.

다음은 shrink시 index와 같은 dependent object도 정리해주기 위하여 option을

사용한 예이다. 앞서 만든 index의 blocks 변화를 눈 여겨 보자.


2 where segment_name = 'IK_XSHRINK_OBJ';

BLOCKS

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

768

SCOTT> alter table x_shrink_obj shrink space cascade;

Table altered.


2 where segment_name = 'IK_XSHRINK_OBJ';

BLOCKS

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

512

다시 shrink를 수행하면서 cascade option을 사용하자 index segment의 blocks

수도 줄어드는 것을 볼 수 있다.

CF. 물론, 다음과 같이 index에 대해서만 독립적으로 shrink 작업을 할 수도 있다.

SCOTT> alter index ik_xshrink_obj shrink space;

Index altered.



7.11.3.5. Using em

이 shrink 역시 em을 통해서 할 수 있다. 먼저 다음과 같이 table 화면으로 이동한다.

“Administration Tables(Schema)”

아래 table 화면에서 schema와 table name을 선택 혹은 입력한 후 “Go” 버튼을

누른다.


그림 7-73

em 관리화면


아래 화면의 하 단에 서 원하는 table을 선택한 후 우측 중앙 “Actions”의 item중

“Shrink Segment”를 선택하고 “Go” 버튼을 click한다.

다양한 작업이 가능한 화면이다. 여기서 앞서 배운 options을 선택하고 우측 상단의

“Continue”를 선택한다.


그림 7-74

Segment Shrink

그림 7-75

Segment Shrink


아래 화면은 이제 많이 익숙한 화면이다. 어떤 작업을 할 때 최종적으로 즉시 수행할

것인가 아니면 schedule로 등록할 것인가를 선택하는 화면이다. 다른 작 업에서도

결국 이 화면으로 나오는 것을 앞서도 많이 경험한바 있다. 이제 여기서 바로 수행할

것이면 그대로 아니면 schedule을 선택한 후 우측 상단의 “Submit”을 통해 작업을

개시하면 된다.

7.11.4. Segment Advisor

7.11.4.1. 개요 및 Segment 분석Oracle10g의 또 다른 advisor인 segment advisor는 shrink 대상 table을 unused

space를 기반으로 분석하여 recommend하고 space 사용 trend를 분석하는 등

다양한 정보를 제공해 준다. 일반적으로 분석 대상은 segment 혹은 tablespace level

로 이루어지게 된다.


그림 7-76

Segment Shrink

그림 7-77

Segment Shrink


다음은 PL/SQL을 통해 tablespace level의 분석결과를 확인하는 예이다.

SYSTEM> var task varchar2(100);

SYSTEM> var objno number;

SYSTEM> exec :task := 'SADV_TBS';


SYSTEM> exec dbms_advisor.create_task('Segment Advisor', :task,-

> 'check shrinking in tablespace');


SYSTEM> exec dbms_advisor.create_object(:task, 'TABLESPACE',-

> 'USER_DEFAULT', NULL, NULL, NULL, NULL, object_id => :objno);


SYSTEM> exec dbms_advisor.set_task_parameter(:task,-

> 'MODE', 'COMPREHENSIVE');


SYSTEM> exec dbms_advisor.execute_task(:task);


위 분석 결과를 보고 싶다면 다음과 같은 views를 join하여 다음과 같은 SQL

command를 사용해 보라.

SYSTEM> col owner for a10

SYSTEM> col type for a5


SYSTEM> select do.attr1 owner, do.type, do.attr2 object_name,

2 af.message recommend, af.more_info detail, aa.attr1 || ';' action

3 from dba_advisor_objects do, dba_advisor_findings af,



4 dba_advisor_recommendations ar, dba_advisor_actions aa

5 where aa.task_name = 'SADV_TBS' and ar.task_name = 'SADV_TBS'

6 and af.task_name = 'SADV_TBS' and do.task_name = 'SADV_TBS'

7 and aa.rec_id = ar.rec_id and ar.finding_id = af.finding_id

8 and af.object_id = do.object_id;

OWNER TYPE OBJECT_NAME

RECOMMEND

DETAIL

ACTION

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

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

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

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

SCOTT INDEX GG_GGNO_I

Perform shrink, estimated savings is 2297713 bytes.

Allocated Space:9437184: Used Space:7068783: Reclaimable

Space :2297713:

alter index "SCOTT"."GG_GGNO_I" shrink space;

SCOTT INDEX GG_GGNAME_I



Space :1181473:

alter index "SCOTT"."GG_GGNAME_I" shrink space;

SCOTT INDEX GG_GGTI_CODE_I



Space :1170560:

alter index "SCOTT"."GG_GGTI_CODE_I" shrink space;

SCOTT INDEX GG_PK_I





Space :2742227:

alter index "SCOTT"."GG_PK_I" shrink space;

SCOTT INDEX PK_EMP_BTM



Space :1816545:

alter index "SCOTT"."PK_EMP_BTM" shrink space;

SCOTT INDEX IK_DEPT_NAME



Space :3023351:

alter index "SCOTT"."IK_DEPT_NAME" shrink space;

6 rows selected.

CF. 만일, 여러분이 tablespace가 아닌 특정 schema level의 분석을 원했다면 위의

advisor task parameter 설정의 create_object과정에서 다음과 같은 형식을

사용했을 것이다.

SQL> exec dbms_advisor.create_object(:task, 'TABLE',-

> 'username', table_name, NULL, NULL, NULL, object_id => :objno);

Database를 운영하면서 현 시스템에 대한 경험이 많은 DBA는 보통 위와 같은

전체적인 분석을 하지 않고도 특정 tables이 space의 문제가 있을 것이란 이미 알고

있는 경우가 많다. 그리고 대략 그런 tables의 size도 이미 알고 있는 것이 보통이다.

따라서 이러한 경우 특정 table만 어느 정도 원하는 size로 줄어들 수 있는지 미리

판단할 수 있다면 보다 빠르게 shrink작업을 할 수 있을 것이다.

예를 들어서 특정 거래 table “X_TRANS”가 있고 하루에도 수만 번의 insert와 delete

가 발생한다고 치자. 그래서 현재 size가 1G이고 delete의 빈도를 볼 때 적어도 500M

정도는 줄일 수 있을 것이란 예측을 하였다. 어떻게 할 것인가! 지금 소개하는 이

function은 boolean type으로 맞는지 틀리는지를 예측해준다.

SCOTT> set serveroutput on



SCOTT> var vn_resize number

SCOTT> exec :vn_resize := 500


SCOTT> begin

2 if (dbms_space.verify_shrink_candidate

3 ('SCOTT','X_TRANS','TABLE', :vn_resize*1024*1024)) then

4 dbms_output.put_line('Yes. You can reduce size by ' || :vn_resize || 'MB.');

5 else

6 dbms_output.put_line('No. You cannot reduce size by ' || :vn_resize ||

'MB.');

7 end if;

8 end;

9 /

No. You cannot reduce size by 500MB.


위 결과에서 여러분이 “Yes”를 확인할 수 있다면 이제 shrink를 하면 된다. 위 결과는

500MB size로 줄일 수 없다는 것을 알려준다. 물론, 주의 할 것은 원래 table

“X_TRANS”가 500MB보다 작다면 위 결과는 free space 조정과 상관이 없이 항상

“No”가 된다는 것이다. 즉, free space가 없어서 줄일 수 없는 경우와 원래 size가

작아서 줄이는 것 자체가 안 되는 경우는 구분이 되지 않음으로 조사할 table을

신중하게 선택하여 입력해야 한다.

7.11.4.2. Segment Advisor (Using em)

앞서 여러 차례에 걸쳐 다루었던 다른 advisor와 마찬가 지로 유사한 작업의 흐름을

갖는다. 먼저 “Adviser Central”에서 다음과 같이 “Segment Advisor”를 선택한다.

그리고 다음 화면에서 분석 대상을 선택한 후 “Continue”를 진행한다. 여기서는


그림 7-78

Segment Advisor

그림 7-79

Segment Advisor


tablespace에 대해 알아볼 것이다.

다음 화면에서 우측 중앙의 “Add”를 통해 tablespace list를 확인한다.

다음 화면에서 적절한 tablespace를 선택한 후 “Ok”를 선택한다.

이제 “Next”를 통해 다음 단계로 간다.


그림 7-80

Segment Advisor

그림 7-81

Segment Advisor

그림 7-82

Segment Advisor


여기서부터는 익숙한 화면이다. 차례 차례 “Next”를 통해 이동한다.

수행 시간을 정하는 schedule 화면이다.


그림 7-83

Segment Advisor

그림 7-84

Segment Advisor


최종 설정이 완료된 화면이다. “Submit”을 통해 작업을 수행할 수 있다.

하단에 생성된 “Segment Advisor”항목을 볼 수 있다.


그림 7-85

Segment Advisor

그림 7-86

Em의 전체 Advisor 결과 List


이제 분석 작업이 완료가 되면 해당 task를 선택하여 다음과 같은 결과를 확인할 수

있다. 아래 화면은 각 segment별 분석 및 추정결과를 보여준다. 물론, 원한다면 아래

화면의 우측상단 “Show SQL”을 통해 추천하는 SQL script도 확인할 수 있다.

7.11.4.3. Segment Trend

Oracle10g가 제공하는 또 하나의 유용한 기능은 바로 segment의 trend이다. 현재

필자도 그러하지만 상당수의 site들은 storage 예측을 위해 전체 혹은 중요 tables에


그림 7-87

Segment Advisor 결과

그림 7-88

Segment Trend 분석


대하여 변화추이를 기록하여 따로 분석하는 작업을 진행하게 된다. 앞서 shrink에서

보았던 em database control에서 “Administration Tables(Schema)”를 선택한

후 다음과 같이 원하는 table을 선택 혹은 입력한다.

그리고 나서 하단의 list에서 해당 table을 click하면 아래 화면으로 이동한다. 여기서

상단 좌측의 “Segments” tab을 선택한다.

아래 화면에서 해당 segment의 space usage가 graph로 나타나고 날짜를 선택해서

볼 수도 있다.


그림 7-89


그림 7-90



위의 예는 9월 14일(현재 날짜)부터는 사용량이 늘어나는 것으로 보인다. 이것은(14

일부터) 오늘부터 이 segment에 data가 생성이 될 것이라는 가정하에 trend 추측을

한 것이다. 현재 table은 테스트를 위해서 사용한 것임으로 지속적인 변화가 없었다.

따라서 위의 14일 이후 추측은 현재로서는 정확하지 않다. 그러나 빈번한 변화가

일어나는 실제 (여러분이 운영하는)업무 table에 대하여 위 trend를 살펴보면 매우

정확한 예측 결과를 볼 수 있을 것이다.

원한다면 위 과정을 아래와 같이 dbms_space package를 통해 확인할 수도 있다.

역시 14일 이후로는 예측이다.

SYSTEM> select timepoint, space_usage, space_alloc, quality

2 from table(dbms_space.object_growth_trend('XRSRC', 'RSRC_CNT',

'TABLE'))

3 where space_usage > 0;

TIMEPOINT SPACE_USAGE SPACE_ALLOC QUALITY

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

06-SEP-05 04.46.09.825070 PM 227579 1048576 INTERPOLATED











15-SEP-05 04.46.09.825070 PM 1010468 1048576 PROJECTED

16-SEP-05 04.46.09.825070 PM 1097455 1097455 PROJECTED

17-SEP-05 04.46.09.825070 PM 1184443 1184443 PROJECTED

18-SEP-05 04.46.09.825070 PM 1271431 1271431 PROJECTED

19-SEP-05 04.46.09.825070 PM 1358418 1358418 PROJECTED

14 rows selected.

7.11.4.4. Segment Size Estimation

Oracle10g가 제공하는 또 다른 기능으로 table 혹은 index를 생성할 때 size 예측을

해주는 기능이 있다. 다음과 같이 앞서 보았던 em의 “Administration

Tables(Schema)” 화면에서 우측 하단의 “Create”를 click해보자.

이제 다음 화면에서 table의 유형을 선택하고 “Continue”를 한다.

이제 아래화면에서 각종 storage 등 필요한 설정을 한 후 중앙의 “Estimate Table

Size”를 선택한다.


그림 7-91

Segment Size 분석

그림 7-92

Segment Size 분석

그림 7-93

Segment Size 분석


이제 예측하고 있는 data 건수를 입력한 후 중앙의 “Estimate Tab le Size”를

선택해보라.

이제 중앙에 계산된 결과값을 볼 수 있다. 즉, 위 그림의 “Unavailable”이 계산된

값으로 변경된다. 여러분은 이 결과를 기준으로 수 차례 estimation을 통해 적합한

storage 구성을 하는데 도움을 받을 수 있을 것이다.


그림 7-94

Segment Size 분석


물론, 위 기능 역시 oracle10g의 보다 강력해진 package dbms_space를 통해 직접

구현할 수도 있다. 아래의 예는 package를 이용해 필요 size를 MB로 추정해 본 것이다.

SYSTEM> var usb_bt number

SYSTEM> var alc_bt number

SYSTEM> exec dbms_space.create_table_cost('USER_DEFAULT',

avg_row_size => 8,-

> row_count => 1000000, pct_free =>10,-

> used_bytes => :usb_bt, alloc_bytes => :alc_bt);


SYSTEM> print :usb_bt :alc_bt

USB_BT

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

12419072

ALC_BT

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

12582912


그림 7-95

Segment Size 분석


SYSTEM> select 12419072/1024/1024, 12582912/1024/1024 from dual;

12419072/1024/1024 12582912/1024/1024

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

11.84375 12

다음은 동일한 방식으로 index에 대한 예측을 해보자. 앞서 shrink를 위해 생성한

테스트 table “X_SHRINK_OBJ”를 기준으로 이를 확인해 보자.

SYSTEM> drop index scott.ik_xshrink_obj;

Index dropped.

SYSTEM> exec dbms_space.create_index_cost(-

> ddl => 'create index scott.ik_xshrink_obj on scott.x_shrink_obj(sno)',-

> used_bytes => :usb_bt, alloc_bytes => :alc_bt);


SYSTEM> print :usb_bt :alc_bt

USB_BT

-----------

346164

ALC_BT

-----------

720896

SYSTEM> select 346164/1024/1024, 720896/1024/1024 from dual;

346164/1024/1024 720896/1024/1024

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

.330127716 .6875



위 결과는 만일 index를 생성하게 되면 사용 및 필요 space가 1MB가 안 된다는 점을

보여준다.

7.11.5. Undo Management

7.11.5.1. Undo 관리 화면특별한 segment중 하나인 undo segment를 관리하는 기법은 여러 가지이다. 과거의

rollback segment에서 undo segment로의 변화 그리고 undo retention을 비롯한

여러 가지의 관리 parameters등 조금 더 자세히 모니터링하고 관리하고자 하면 많은

SQL문을 사용해야 한다. Oracle10g의 em database control이 제공하는 다음과

같은 화면은 여러분으로 하여금 한눈에 쉽게 undo 관련 정보를 취득 하고 수정작업을 할

수 있도록 도와준다. “Administration Undo Management(Instance)”로 이동해

보자.

우리는 이 화면에서 3단계로 이루어진 undo관련 내역을 확인할 수 있다. 즉, 현재

설정된 undo의 속성을 보여주는 부분, undo 관리에 문제가 있는지 없는지 분석하여

권고하는 부분, 그리고 현재 사용중인 undo 사용량과 관련된 부분을 한눈에 확인할 수

있다. 중앙에 있는 “Update Analysis”버튼은 undo 분석 period를 일주일, 하루, 한

시간 전부터 여러분이 직접 설정하는 시간까지 분석기간을 정의하고 수행할 수 있게

해준다. 물론, 여기서 “Undo Advisor”로 이동할 수도 있고 “Change Tablespace”

버튼을 통해 undo tablespace의 변경이 가능하며 “Edit Undo Tablespace”버튼을

통해 tablespace 속성을 변경할 수 있다.


그림 7-96

Undo 관리화면


화면 좌측 하단의 “Show Graph”를 선택하면 다음과 같이 undo 생성 비율과 undo

tablespace 사용량과 관련한 부분을 graph로 보여준다. 다음 화면을 보라.

7.11.5.2. Undo Advisor

위 화면에서 “Undo Advisor”를 선택하게 되면 다음과 같은 화면을 볼 수 있다.

이 화면에서 undo 관리에 대한 분석된 결과를 볼 수 있으며 그 결과에 따라 여러분은


그림 7-97

Undo Tablespace 사용량

그림 7-98

Undo Advisor


oracle10g가 recommend하는 내용들을 적용하거나 계획하는 등의 작업을 손쉽게 할

수 있다. 상단 중앙을 보면 undo retention의 조정 및 분석기간의 선택 등을 할 수 있고

“Update Analysis and Graph” 버튼을 통해 해당 기간의 분석결과 및

recommendation을 확인할 수 있다.

다음은 package를 통해 직접 분석을 하는 과정이다. 최근 snapshot id를 가지고

분석을 수행하기 위해 snapshot id를 검색한 후 advisor를 수행해 보자.

SYSTEM> col snap_start for a30

SYSTEM> select * from ( select snap_id,




SNAP_ID snap_start

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

1964 20050915 13:00:37

1963 20050915 12:00:27

1962 20050915 11:00:14

1961 20050915 10:00:59

1960 20050915 09:00:37

1959 20050915 08:00:13

1958 20050915 07:00:58

1957 20050915 06:00:33

1956 20050915 05:00:09

9 rows selected.

SYSTEM> var task varchar2(100);

SYSTEM> exec :task := 'UNDO_ANA';


SYSTEM> exec dbms_advisor.create_task('Undo Advisor', :task, 'Undo

Analysis');




SYSTEM> exec dbms_advisor.create_object(:task, 'UNDO_TBS',-

> NULL, NULL, NULL, 'NULL', :objno);


SYSTEM> exec dbms_advisor.set_task_parameter(:task,

'TARGET_OBJECTS', :objno);


SYSTEM> exec dbms_advisor.set_task_parameter(:task, 'START_SNAPSHOT',

1956);


SYSTEM> exec dbms_advisor.set_task_parameter(:task, 'END_SNAPSHOT',

1964);


SYSTEM> exec dbms_advisor.execute_task(:task);


안타깝게도 위에서 dbms_advisor를 통해 생성한 undo task 분석 정보는 em의

undo management화면에서 선택할 수 있는 곳이 없다. 즉, 초기 “Advisor Central”

화면에서 분석 report를 생성하여 보아야 한다. 그러나 em에서나 아니면 위 화면에서

직접 package report를 추출하거나 다 error가 발생한다. 다음의 report 화면을 보자.

SYSTEM> set long 32000

SYSTEM> select dbms_advisor.get_task_report('TASK_3173') from dual;

ERROR:

ORA-14552: cannot perform a DDL, commit or rollback inside a query or

DML



ORA-06512: at "SYS.PRVT_ADVISOR", line 1750

ORA-13613: The requested operation is not supported for this advisor

object.

ORA-06512: at "SYS.DBMS_ADVISOR", line 569

ORA-06512: at line 1

no rows selected

현재 이 부분에 대해서 그 원인을 파악 중이며 확인이 되는 즉시 홈페이지 게시판을

통해 올리도록 할 예정이다.

어찌 되었든 이 문제와는 상관없이 undo에 대한 분석은 ADDM 전체 분석에서는

문제없이 나타나고 있고 또 따로 em의 undo management를 통한 분석이 충분히

유효하기 때문에 가급적 undo management의 사용을 권장한다.



OCP point

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

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

1. tablespace usage를 monitoring하고 alert를 발생시키는 기본 속성

2. shrink space 와 compact의 차이

3. shrink space cascade option의 의미

4. segment advisor의 개요 및 분석내용

5. em database control의 Undo Advisor graph 이해

참조

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

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

HWM : ob 30p

online table redefinition : o9i 133p

undo관련 정보를 취득 : o9i 310p


oracle history #14

Education

addm report

addm point

addm configuration

memory limit

sga memory

automatic diagnostic

undo management

memory process