Oracle History #14

http://www.ggola.com 장 경 상
7. 자가관리(self-management) Database System...................................................................6
7.1. 자동진단(automatic diagnostic) 시스템.................................................................7
7.1.1. ADDM (Automatic Database Diagnostic Management)...........................7
7.1.1.1. ADDM 관리 point................................................................................7
7.1.1.2. ADDM 성능 모니터.............................................................................7
7.1.1.3. ADDM의 분석방향..............................................................................9
7.1.2. ADDM Configuration..................................................................................10
7.1.2.1. Initial Parameter.................................................................................10
7.1.2.2. ADDM Report....................................................................................11
7.1.3. ADDM using em...........................................................................................18
7.1.3.1. em Start...............................................................................................18
7.1.3.2. Advisor Central (중앙 권고자)..........................................................21
7.1.3.3. ADDM Report using em...................................................................23
7.1.4. I/O 속성.........................................................................................................24
7.2. SGA Memory 관리 자동화....................................................................................26
7.2.1. 빈번한 Memory 오류 유형...........................................................................26
7.2.2. Automatic Shared Memory Management.................................................26
7.2.2.1. SGA Size..............................................................................................26
7.2.2.2. Initial Parameter.................................................................................27
7.2.3. Memory 자동관리 체계와 Limit.................................................................31
7.2.3.1. Memory 자동관리 Process................................................................31
7.2.3.2. Pool의 자동관리 와 Limit..................................................................32
7.2.3.3. spfile....................................................................................................34
7.2.4. Memory 자동관리 Using em.......................................................................35
7.3. 통계정보 자동관리..................................................................................................37
7.3.1. 변화된 통계수집............................................................................................37
7.3.2. Automatic 통계수집의 구조........................................................................38
7.3.2.1. 기본 개념.............................................................................................38
7.3.2.2. 기본 Components...............................................................................38
7.3.2.3. 통계수집 자동화의 의미....................................................................41
7.3.2.4. 통계수집 Control................................................................................41
7.3.3. 통계정보의 Locking 과 Overriding............................................................42
7.3.3.1. Lock Statistics.....................................................................................42
7.3.3.2. Override Statistics..............................................................................44
7.3.4. 통계정보 History..........................................................................................45
7.3.4.1. History 구조........................................................................................45
JKSPARK@HANAFOS.COM 1

7.3.4.2. History 활용하기................................................................................45
7.3.5. 통계수집 자동화 Limit.................................................................................48
7.4. Undo & Checkpoint 자동 Tuning........................................................................50
7.4.1. Undo Management.......................................................................................50
7.4.1.1. Undo Retention 자동 관리................................................................50
7.4.1.2. Rollback Time 추측............................................................................50
7.4.2. Checkpoint....................................................................................................51
7.4.3. Fast Ramp-Up...............................................................................................53
7.5. AWR (Automatic Workload Repository)............................................................55
7.5.1. AWR 개요......................................................................................................55
7.5.1.1. AWR의 구조.......................................................................................55
7.5.1.2. 통계 Access.........................................................................................55
7.5.1.3. 기본통계(Base Statistics)와 측정(Metrics).......................................63
7.5.1.4. Repository와 Snapshot......................................................................65
7.5.2. AWR Control.................................................................................................66
7.5.2.1. Snapshot Schedule 조정 (Manually)................................................66
7.5.2.2. Snapshot Schedule 조정 (Using em)................................................68
7.5.2.3. Snapshot Baseline (Manually)..........................................................70
7.5.2.4. Snapshot Baseline (Using em)..........................................................72
7.5.2.5. Other Snapshot Control....................................................................74
7.5.3. AWR Report & em........................................................................................75
7.5.3.1. 직접 report 산출하기..........................................................................75
7.5.3.2. Report Script 사용하기......................................................................78
7.5.3.3. Using em.............................................................................................82
7.5.4. Active Session History(ASH)......................................................................84
7.5.4.1. ASH 개요 및 속성...............................................................................84
7.5.4.2. ASH Access.........................................................................................84
7.5.4.3. ASH Example.....................................................................................88
7.5.5. Advisor (문제 해결사) .................................................................................91
7.5.5.1. Advisor의 구조...................................................................................91
7.5.5.2. 기본 Advisor.......................................................................................92
7.5.5.3. Advisor 사용하기...............................................................................92
7.5.5.4. Using em.............................................................................................94
7.6. Alert & Notification (경보와 알림기능)...............................................................96
7.6.1. Alert 개요.......................................................................................................96
7.6.1.1. Server Generated Alert......................................................................96

7.6.1.2. Server Alert의 장점............................................................................96
7.6.2. Alert 구조.......................................................................................................97
7.6.2.1. Alert 생성 시점...................................................................................97
7.6.2.2. Server Alert & em Alert.....................................................................97
7.6.2.3. Alert Model.........................................................................................98
7.6.3. Alert Types....................................................................................................99
7.6.3.1. Stateful Alert.......................................................................................99
7.6.3.2. Stateless Alert...................................................................................100
7.6.3.3. Out-of-Box Server Alert...................................................................100
7.6.4. Alert Control...............................................................................................101
7.6.4.1. Threshold 조절 (Manually).............................................................101
7.6.4.2. Alert 확인 및 Threshold 조절 (Using em).....................................109
7.6.4.3. Alert Message 확인 (Manually)......................................................113
7.7. Cost & Optimizer.................................................................................................118
7.7.1. Query Optimization...................................................................................118
7.7.2. 확장된 Statistics..........................................................................................120
7.7.2.1. Dictionary를 위한 통계....................................................................120
7.7.2.2. 통계 수집의 New Values.................................................................123
7.7.3. Optimizer Mode의 변화.............................................................................124
7.8. Support SQL Tuning............................................................................................127
7.8.1. Optimizer를 통한 SQL Tuning 자동환.....................................................127
7.8.1.1. Tuning을 위한 Enhanced Optimizer.............................................127
7.8.1.2. DBA SQL Tuning과 Advisor..........................................................127
7.8.2. SQL Tuning Advisor..................................................................................128
7.8.2.1. 통계분석 (Statistics Analysis).........................................................128
7.8.2.2. SQL Profile........................................................................................129
7.8.2.3. SQL Access Advisor : 접근경로 분석(Access Path Analysis)......130
7.8.2.4. SQL 구조 분석(Structure Analysis)................................................131
7.8.3. Tuning SQL (Using em).............................................................................132
7.8.3.1. SQL Tuning Set.................................................................................132
7.8.3.2. Running SQL Tuning Advisor.......................................................133
7.8.3.3. STS 생성.............................................................................................135
7.8.3.4. Tuning Result...................................................................................136
7.8.4. SQL Tuning Package (Manually)..............................................................138
7.8.4.1. Using Snapshot ID...........................................................................139
7.8.4.2. Using STS..........................................................................................141

7.8.5. SQL Profile 적용 (Manually).....................................................................144
7.8.5.1. Accept Profile...................................................................................144
7.8.5.2. Profile Category...............................................................................145
7.8.5.3. Profile 수정........................................................................................145
7.8.6. STS Control (Manually).............................................................................146
7.8.6.1. STS의 생성과 SQL Load..................................................................146
7.8.6.2. STS와 SQL의 조정............................................................................148
7.8.7. SQL Access Advisor...................................................................................149
7.8.7.1. 대상 SQL...........................................................................................150
7.8.7.2. Access Path 분석 Option과 권고사항............................................151
7.8.7.3. Access 분석 (Using em)...................................................................152
7.8.7.4. Access 분석 (Manually)...................................................................164
7.9. Instance Monitoring.............................................................................................175
7.9.1. Monitoring 방안..........................................................................................175
7.9.2. Database Control........................................................................................175
7.9.3. em의 성능 진단 및 관리.............................................................................175
7.10. Resource Manger...............................................................................................180
7.10.1. Oracle10g New Features..........................................................................180
7.10.2. Original Consumer Group으로 돌아가기..............................................180
7.10.2.1. Switch Time(Top Call)...................................................................181
7.10.2.2. Using em.........................................................................................187
7.10.3. Idle Time의 설정.......................................................................................188
7.10.3.1. Session Idle Time............................................................................188
7.10.3.2. Session Blocking Time...................................................................190
7.10.3.3. Using em.........................................................................................193
7.10.4. 유연한 Resource Group의 할당...............................................................193
7.10.4.1. Resource Group Mapping.............................................................195
7.10.4.2. Resource Group Priority...............................................................197
7.10.4.3. Using em.........................................................................................206
7.10.5. New Resource 할당 방법.........................................................................207
7.10.5.1. CPU 할당 방식................................................................................207
7.10.5.2. CPU RATIO 할당의 예...................................................................208
7.10.6. Monitoring Resource Manager...............................................................213
7.11. Space 관리 자동화..............................................................................................215
7.11.1. 개요.............................................................................................................215
7.11.2. Tablespace.................................................................................................215

7.11.2.1. Tablespace Usage...........................................................................215
7.11.2.2. Threshold의 설정과 의미..............................................................217
7.11.3. Segment와 Block 관리방식......................................................................218
7.11.3.1. Segments내부의 관리방식 변화....................................................218
7.11.3.2. Shrink Segment 속성......................................................................220
7.11.3.3. Shrink Command, 속성, Oracle9i Coalesce.................................221
7.11.3.4. Shrink Example..............................................................................222
7.11.3.5. Using em.........................................................................................228
7.11.4. Segment Advisor......................................................................................231
7.11.4.1. 개요 및 Segment 분석....................................................................231
7.11.4.2. Segment Advisor (Using em)........................................................235
7.11.4.3. Segment Trend...............................................................................239
7.11.4.4. Segment Size Estimation ..............................................................241
7.11.5. Undo Management...................................................................................245
7.11.5.1. Undo 관리 화면..............................................................................245
7.11.5.2. Undo Advisor.................................................................................247

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 본인이 알고 있는 지식과 노력만큼 작업부담도
줄어드는 것임을 명심하자.
표 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가 제기되는 특정 시점간의 분석을

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 18076 1 0 Aug11 ? 00:00:00 ora_arc1_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 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관련 동의를 묻는 화
면이 나오면 동의를 누르고 넘어가면 된다) 화면은 크게 진단에 내역과 경고성 메시지를
나타내는 부분이 상중하로 나뉘어 지며 아래 화면 우측 상단에서처럼 자동으로 refresh를
하거나 사용자가 원할 때 수동으로 refresh를 하도록 선택할 수도 있다.
상단화면 :
그림 7-1
em login
창

중단화면 :
하단화면 :
그림 7-2
em 초기
화면
그림 7-3
em 초기
화면

7.1.3.2. Advisor Central (중앙 권고자)
위 하단화면에서 ADDM 분석을 해보기 위해선 Advisor Central(중앙 권고자)로 이동을
해야 한다. 이를 click한다.
CF. 위 화면에서 하단을 보면 현재 권고사항이 있는 작업내역이 보인다. 현재는 ADDM
부문에서 분석된 자료가 있다는 뜻이다. 이것을 click해서 곧 바로 oracle이 제안하는 문
제를 파악하고 그 해결책에 접근할 수도 있다.
이제 좌측 상단의 ADDM을 선택하여 분석화면으로 이동한다.
그림 7-4
em 초기
화면
그림 7-5
em 중앙
권고자

다음은 위 화면에서 분석을 시작할 시간과 마지막 시간을 설정하는 과정이다. 먼저 시작
시간 radio button을 선택한 후 화면 하단 그래프 밑에서 원하는 시간대를 click하면 자동
으로 선택이 된다.
같은 방법으로 종료시간을 설정하면 다음과 같이 선택이 완료된다. 현재는 그래프 우측
에서 약간의 작업이 있었던 것으로 추측되는 시간대를 선택했다. 확인을 눌러보자.
그림 7-6
ADDM
설정화면
그림 7-7
ADDM
설정화면
그림 7-8
ADDM
설정화면

최종적으로 아래와 같은 결과를 확인할 수 있다.
좌측에는 시스템에 준 영향순서대로 우측에는 그 내용과 권고사항이 나타난다. 이제 여
러분은 tuning하고자 하는 대상을 click하여 하나씩 문제를 해결할 수 있게 된다.
7.1.3.3. ADDM Report using em
앞서 언급한 3번째 ADDM report는 em을 이용하는 것이다. 위 화면에서 “보고서 보기”
를 선택하면 아래와 같은 보고서를 볼 수 있으며 이를 버튼을 통해 file로 저장할 수도 있
다.
그림 7-9
ADDM
결과
그림 7-10
ADDM
Report

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으로부터 기대하는 성능의 지표를 의미하는데
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 19091 1 0 15:31 ? 00:00:00 ora_q000_NEWSVC
oracle 19171 1 0 15:34 ? 00:00:00 ora_j000_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로 설정된다.
CF. 물론, 자동 tuning의 대상이 아닌 memory의 값이 변경되면 sga_target의 총 size에도
당연히 영향을 주게 된다. 즉, non-standard block cache가 50MB 더 늘어나면 위의 예에
서 sga_target은 400 – 50 = 350MB로 더 줄어들게 된다.
표 7-3
자동관리
Memory
요소와
Paramete
r 종류

자동관리의 대상이 되는 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
에 대해서도 통계작업을 수행할 것이다.
하지만 사실 이런 류의 table은 굳이 통계정보가 필요치 않으며 거기에 system이
resource를 낭비하는 것을 그냥 두고 보기에는 너무 아쉬울 것이다. 지금 설명하는 통계
정보의 locking은 특정 table에 대한 통계정보를 수행하지 않도록 해줄 수 있다.
그림 7-13
em 스케
쥴러

이런 통계정보 수집을 막기 위해 사용하는 것은 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
-------------------------------------------------------
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'
표 7-5
수집된 통
계의
Restore
Procedur
e List

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_interval fast_start_mttr_target fast_start_mttr_target
(0 보다 크거나 unset)log_checkpoint_timeout log_checkpoint_timeout
fast_start_io_target
UNSET 없음 log_checkpoint_interval log_checkpoint_timeout
fast_start_io_target log_checkpoint_interval
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을 원하지 않는다면 이 parameter의 값을 명시적으로 0으로 설정하면
된다.
현재의 database에서 checkpoint tuning을 자동화하기 위해 parameter를 조정한 후 다시
database를 start해보자.
[NEWSVC]LIRACLE:/app/oracle/admin/NEWSVC/pfile> vi initNEWSVC.ora
…..
…..
…...
표 7-6
Checkpoi
nt 설정과
Paramete
r

……
#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
[NEWSVC]LIRACLE:/app/oracle/temp> sqlplus / as sysdba
SQL*Plus: Release 10.1.0.4.0 - Production on Fri Aug 19 14:11:41 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>
관련 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) 통계의 누적시간
v$sysmetric_history system의 모든 metric value정보
그림 7-14
AWR 연
결구조
표 7-7
통계와
Views

v$system_wait_class wait class의 전체 wait 시간(commit, idle, system I/O 등)
v$active_session_history 초당 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 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, averaged over all
processors
OS_CPU_WAIT_TIME Total number of hundredths of a second that processes have
표 7-8
OS 통계
와 의미

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, averaged
over all processors
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
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
표 7-9
Advisor
관련
View List

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.
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.
표 7-10
HWM 종
류와 의미
표 7-11
Database
Feature
와 의미

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

Oracle History #14

Recommandé

Recommandé

Contenu connexe

Similaire à Oracle History #14

Similaire à Oracle History #14 (9)

Plus de Kyung Sang Jang

Plus de Kyung Sang Jang (16)

Oracle History #14