oracle history #14
Post on 29-Jun-2015
324 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
JKSPARK@HANAFOS.COM 1
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 2
http://www.ggola.com 장 경 상
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 사용하기
JKSPARK@HANAFOS.COM 3
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 4
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 5
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 6
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 7
http://www.ggola.com 장 경 상
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 본인이 알고 있는 지식과 노력만큼
작업부담도 줄어드는 것임을 명심하자.
JKSPARK@HANAFOS.COM 8
표 7-1
DBA 작업유형
http://www.ggola.com 장 경 상
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가 제기되는 특정 시점간의
JKSPARK@HANAFOS.COM 9
http://www.ggola.com 장 경 상
분석을 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
JKSPARK@HANAFOS.COM 10
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 11
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 12
http://www.ggola.com 장 경 상
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
----------------------------------------------------------------------------------------------------
JKSPARK@HANAFOS.COM 13
http://www.ggola.com 장 경 상
--
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
JKSPARK@HANAFOS.COM 14
http://www.ggola.com 장 경 상
…….
…….
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;
JKSPARK@HANAFOS.COM 15
http://www.ggola.com 장 경 상
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);
PL/SQL procedure successfully completed.
SYS> exec dbms_advisor.set_task_parameter(:v_task, 'END_SNAPSHOT',
1295);
PL/SQL procedure successfully completed.
SYS> exec dbms_advisor.set_task_parameter(:v_task, 'INSTANCE', 1);
PL/SQL procedure successfully completed.
SYS> exec dbms_advisor.set_task_parameter(:v_task, 'DB_ID',
JKSPARK@HANAFOS.COM 16
http://www.ggola.com 장 경 상
3941507194);
PL/SQL procedure successfully completed.
SYS> exec dbms_advisor.execute_task(:v_task)
PL/SQL procedure successfully completed.
위 과정을 통해서 직접 특정 시간대에 대한 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
-----------------------------------------------------------------------------------------------
Analysis Period: 17-AUG-2005 from 08:00:52 to 11:00:22
Database ID/Instance: 3941507194/1
Database/Instance Names: NEWSVC/NEWSVC
Host Name: LIRACLE
Database Version: 10.1.0.4.0
Snapshot Range: from 1292 to 1295
Database Time: 2432 seconds
Average Database Load: .2 active sessions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~
FINDING 1: 55% impact (1327 seconds)
-----------------------------------------------------
SQL statements consuming significant database time were found.
…………..
JKSPARK@HANAFOS.COM 17
http://www.ggola.com 장 경 상
…………..
…………..
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
JKSPARK@HANAFOS.COM 18
http://www.ggola.com 장 경 상
…..
…..
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
-------------------------------------------------------------------------------------------
Analysis Period: 16-AUG-2005 from 08:00:27 to 12:00:54
Database ID/Instance: 3941507194/1
Database/Instance Names: NEWSVC/NEWSVC
JKSPARK@HANAFOS.COM 19
http://www.ggola.com 장 경 상
Host Name: LIRACLE
Database Version: 10.1.0.4.0
Snapshot Range: from 1268 to 1272
Database Time: 20 seconds
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 분석을 수행하고 확인할
수 있다.
JKSPARK@HANAFOS.COM 20
http://www.ggola.com 장 경 상
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관련 동의를 묻는
화면이 나오면 동의를 누르고 넘어가면 된다) 화면은 크게 진단에 내역과 경고성
JKSPARK@HANAFOS.COM 21
그림 7-1
em login 창
http://www.ggola.com 장 경 상
메시지를 나타내는 부분이 상중하로 나뉘어 지며 아래 화면 우측 상단에서처럼
자동으로 refresh를 하거나 사용자가 원할 때 수동으로 refresh를 하도록 선택할 수도
있다.
상단화면 :
중단화면 :
JKSPARK@HANAFOS.COM 22
그림 7-2
em 초기화면
그림 7-3
em 초기화면
http://www.ggola.com 장 경 상
하단화면 :
7.1.3.2. Advisor Central (중앙 권고자)
위 하단화면에서 ADDM 분석을 해보기 위해선 Advisor Central(중앙 권고자)로
이동을 해야 한다. 이를 click한다.
JKSPARK@HANAFOS.COM 23
그림 7-4
em 초기화면
그림 7-5
em 중앙권고자
http://www.ggola.com 장 경 상
CF. 위 화면에서 하단을 보면 현재 권고사항이 있는 작업내역이 보인다. 현재는 ADDM
부문에서 분석된 자료가 있다는 뜻이다. 이것을 click해서 곧 바로 oracle이 제안하는
문제를 파악하고 그 해결책에 접근할 수도 있다.
이제 좌측 상단의 ADDM을 선택하여 분석화면으로 이동한다.
다음은 위 화면에서 분석을 시작할 시간과 마지막 시간을 설정하는 과정이다. 먼저
시작시간 radio button을 선택한 후 화면 하단 그래프 밑에서 원하는 시간대를 click
하면 자동으로 선택이 된다.
JKSPARK@HANAFOS.COM 24
그림 7-6
ADDM 설정화면
http://www.ggola.com 장 경 상
같은 방법으로 종료시간을 설정하면 다음과 같이 선택이 완료된다. 현재는 그래프
우측에서 약간의 작업이 있었던 것으로 추측되는 시간대를 선택했다. 확인을 눌러보자.
최종적으로 아래와 같은 결과를 확인할 수 있다.
JKSPARK@HANAFOS.COM 25
그림 7-7
ADDM 설정화면
그림 7-8
ADDM 설정화면
그림 7-9
ADDM 결과
http://www.ggola.com 장 경 상
좌측에는 시스템에 준 영향순서대로 우측에는 그 내용과 권고사항이 나타난다. 이제
여러분은 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으로부터 기대하는 성능의 지표를
JKSPARK@HANAFOS.COM 26
그림 7-10
ADDM Report
http://www.ggola.com 장 경 상
의미하는데 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);
JKSPARK@HANAFOS.COM 27
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 28
http://www.ggola.com 장 경 상
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, 설정하면
JKSPARK@HANAFOS.COM 29
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 30
표 7-2
자동유지 SGA 요소
http://www.ggola.com 장 경 상
#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!
[NEWSVC]LIRACLE:/app/oracle/temp>
위와 같이 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:
JKSPARK@HANAFOS.COM 31
http://www.ggola.com 장 경 상
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과 거의 일치함을 확인할 수 있다.
JKSPARK@HANAFOS.COM 32
http://www.ggola.com 장 경 상
자, 현재 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의 범위 안에서는 유효하다.
SYS> alter system set sga_target=400M;
System altered.
SYS> select current_size from v$buffer_pool;
CURRENT_SIZE
----------------------
260
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
JKSPARK@HANAFOS.COM 33
http://www.ggola.com 장 경 상
large pool 4
shared pool 120
SYS> alter system set sga_target=450M;
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
JKSPARK@HANAFOS.COM 34
http://www.ggola.com 장 경 상
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_
[NEWSVC]LIRACLE:/app/oracle/temp>
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로 설정된다.
JKSPARK@HANAFOS.COM 35
표 7-3
자동관리 Memory 요소와
Parameter 종류
http://www.ggola.com 장 경 상
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.
SYS> select current_size from v$buffer_pool;
CURRENT_SIZE
-----------------------
308
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 8
shared pool 120
이 때에 large pool은 바로 8MB로 늘어나고 다른 자동 tuning 대상 memory의
영역이 줄어든다. 위의 경우 buffer cache가 줄어 들었다.
그러나 DBA가 직접 이 값을 현재 보다 줄이게 되면 다른 현상이 일어난다. 예를 들어
다시 4MB로 줄여보자.
SYS> alter system set large_pool_size=4M;
JKSPARK@HANAFOS.COM 36
http://www.ggola.com 장 경 상
System altered.
SYS> select current_size from v$buffer_pool;
CURRENT_SIZE
----------------------
308
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 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에 영향을 미치게 된다.
JKSPARK@HANAFOS.COM 37
http://www.ggola.com 장 경 상
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 관리화면의 예
JKSPARK@HANAFOS.COM 38
그림 7-11
em 메모리 권고자 (SGA)
그림 7-12
em 메모리 권고자 (PGA)
http://www.ggola.com 장 경 상
JKSPARK@HANAFOS.COM 39
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 40
http://www.ggola.com 장 경 상
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가 통계수집을 위해 다른
JKSPARK@HANAFOS.COM 41
표 7-4
통계수집 방식의 변화
http://www.ggola.com 장 경 상
절차를 취할 필요가 없어졌다. 따라서 잘못된 통계정보로 인한 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
JKSPARK@HANAFOS.COM 42
http://www.ggola.com 장 경 상
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
-------------------------------- ----------------------------------------------------------
JKSPARK@HANAFOS.COM 43
http://www.ggola.com 장 경 상
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을 보자.
JKSPARK@HANAFOS.COM 44
http://www.ggola.com 장 경 상
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함으로써
통계정보를 자동으로 수집할 것이다.
JKSPARK@HANAFOS.COM 45
http://www.ggola.com 장 경 상
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에 대해서도 통계작업을 수행할 것이다.
JKSPARK@HANAFOS.COM 46
그림 7-13
em 스케쥴러
http://www.ggola.com 장 경 상
하지만 사실 이런 류의 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');
PL/SQL procedure successfully completed.
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 ALL
SYSTEM> exec dbms_stats.lock_schema_stats('SCOTT');
JKSPARK@HANAFOS.COM 47
http://www.ggola.com 장 경 상
PL/SQL procedure successfully completed.
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 ALL
SCOTT EMP ALL
위 결과를 통해 table 단위와 schema 단위의 통계정보 lock변화를 확인했다. 반대
작업을 진행해 보자.
SYSTEM> exec dbms_stats.unlock_table_stats('SCOTT', 'EMP');
PL/SQL procedure successfully completed.
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 ALL
SCOTT EMP
SYSTEM> exec dbms_stats.unlock_schema_stats('SCOTT');
PL/SQL procedure successfully completed.
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
JKSPARK@HANAFOS.COM 48
http://www.ggola.com 장 경 상
------------ ----------------------- ---------
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
JKSPARK@HANAFOS.COM 49
http://www.ggola.com 장 경 상
2 from dual;
GET_STATS_HISTORY_RETENTION
---------------------------------------------------
31
SYSTEM> exec dbms_stats.alter_stats_history_retention(61);
PL/SQL procedure successfully completed.
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
JKSPARK@HANAFOS.COM 50
표 7-5
수집된 통계의 Restore Procedure List
http://www.ggola.com 장 경 상
-------------------------------------------------------
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');
PL/SQL procedure successfully completed.
위의 예는 scott의 x_emp table의 통계정보를 현재 보존하고 있는 가장 오래된 old
version 통계정보인 2005년 8월 3일 오후 10시 시점의 자료로 restore한 것이다.
마지막으로 더 이상 필요가 없다고 판단된 old version의 통계정보를 삭제하는 작업을
해보자. 위의 예에서 여러분이 현재보다 2주일 전 통계는 모두 의미가 없어서
삭제하겠다면 다음과 같이 할 수 있다.
SYSTEM> exec dbms_stats.purge_stats(systimestamp - interval '14' day);
JKSPARK@HANAFOS.COM 51
http://www.ggola.com 장 경 상
PL/SQL procedure successfully completed.
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는 자동화되지 않는다)
JKSPARK@HANAFOS.COM 52
http://www.ggola.com 장 경 상
OCP point
==============================================
=================
1. automatic 통계수집에서 사용하는 두 가지 window와 그 내용
2. 특정 table만을 대상으로 불필요한 통계작업을 제거하는 방법
3. 통계정보 history 보관일자 변경 procedure 사용방법
JKSPARK@HANAFOS.COM 53
http://www.ggola.com 장 경 상
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 = ….
JKSPARK@HANAFOS.COM 54
http://www.ggola.com 장 경 상
또한 이 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 없음
log_checkpoint_inter
val
log_checkpoint_time
out
fast_start_io_target
log_checkpoint_inter
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을 원하지 않는다면 이
JKSPARK@HANAFOS.COM 55
표 7-6
Checkpoint 설정과 Parameter
http://www.ggola.com 장 경 상
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
[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
JKSPARK@HANAFOS.COM 56
http://www.ggola.com 장 경 상
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변경 시
JKSPARK@HANAFOS.COM 57
http://www.ggola.com 장 경 상
online할 undo segments의 수를 바로 결정할 수 있다.
JKSPARK@HANAFOS.COM 58
http://www.ggola.com 장 경 상
참조
==============================================
=================
undo retention : o9i 80p, o9i 302p
fast_start_mttr_target : o9i 76p
AUM : o9i 302p
JKSPARK@HANAFOS.COM 59
http://www.ggola.com 장 경 상
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) 통계의 누적시간
JKSPARK@HANAFOS.COM 60
그림 7-14
AWR 연결구조
표 7-7
통계와 Views
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 61
표 7-8
OS 통계와 의미
http://www.ggola.com 장 경 상
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 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
JKSPARK@HANAFOS.COM 62
표 7-9
Advisor 관련 View List
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 63
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 64
http://www.ggola.com 장 경 상
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.
JKSPARK@HANAFOS.COM 65
표 7-10
HWM 종류와 의미
표 7-11
Database Feature 와 의미
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 66
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 67
http://www.ggola.com 장 경 상
Maximum Performance Maximum Performance.
Protection Mode -
Maximum Protection
Data Guard configuration data protection mode is
Maximum Protection.
Protection Mode -
Unprotected
Data Guard configuration data protection mode is
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.
JKSPARK@HANAFOS.COM 68
http://www.ggola.com 장 경 상
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정보
JKSPARK@HANAFOS.COM 69
표 7-12
Metric 관련 v$View List
http://www.ggola.com 장 경 상
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 수 등)
JKSPARK@HANAFOS.COM 70
표 7-13
Metric관련 dba View List
표 7-14
Database Feature 통계
http://www.ggola.com 장 경 상
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하기 위해 필요한 대부분의 중요한
통계를 취합한다.
JKSPARK@HANAFOS.COM 71
http://www.ggola.com 장 경 상
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
------------------------- --------------------
JKSPARK@HANAFOS.COM 72
http://www.ggola.com 장 경 상
+00000 01:00:00.0 +00007 00:00:00.0
SYSTEM> exec dbms_workload_repository.modify_snapshot_settings(-
> interval => 30, retention => 10*24*60);
PL/SQL procedure successfully completed.
SYSTEM> select snap_interval, retention
2 from dba_hist_wr_control;
SNAP_INTERVAL RETENTION
------------------------- --------------------
+00000 00:30:00.0 +00010 00:00:00.0
위 결과로 볼 때 system의 기본 값이 1시간 주기의 snapshot을 7일 보관하는 것으로
설정되어 있고 이를 수정하여 30분 주기의 snapshot을 10일 보관하는 것으로 수정이
되는 것을 알 수 있다.
원래의 system 기본 값으로 다시 수정해 보자.
SYSTEM> exec dbms_workload_repository.modify_snapshot_settings(-
> interval => 60, retention => 7*24*60);
PL/SQL procedure successfully completed.
SYSTEM> select snap_interval, retention
2 from dba_hist_wr_control;
SNAP_INTERVAL RETENTION
------------------------- --------------------
+00000 01:00:00.0 +00007 00:00:00.0
CF. 앞서 argument를 설명할 때 0을 지정하는 경우 각각 최대 값인 interval 1년과
retention 100년이 설정된다고 했다. 그러나 실제로 테스트를 해보면 둘 다 110년이
지정되는 것을 볼 수 있다. 그다지 중요하지는 않지만 oracle문서의 설명과 실제결과가
틀리게 나왔다는 것을 알 필요가 있다고 생각되어 그 결과를 보여준다. (굳이 테스트할
JKSPARK@HANAFOS.COM 73
http://www.ggola.com 장 경 상
필요는 없으니 아래 예를 보고 넘어가도 좋다)
SYSTEM> exec dbms_workload_repository.modify_snapshot_settings(-
> interval => 0, retention => 0);
PL/SQL procedure successfully completed.
SYSTEM> select snap_interval, retention
2 from dba_hist_wr_control;
SNAP_INTERVAL RETENTION
------------------------- --------------------
+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에 대한 편집이
가능하다.
JKSPARK@HANAFOS.COM 74
http://www.ggola.com 장 경 상
위에서 편집을 선택하면 snapshot의 생성 및 보관주기를 다음과 같은 화면에서 수정할
수 있다. 위 그림에서 “보관된 스냅샷 집합”은 다음에 설명하는 baseline을 의미한다.
아직 baseline이 없는 database라면 여기서 나타나지 않을 것이다. 이 부분은 추후
설명되는 “snapshot baseline”의 em 부분에서 다시 확인하도록 한다.
JKSPARK@HANAFOS.COM 75
그림 7-15
AWR snapshot 상태화면
http://www.ggola.com 장 경 상
원하는 보존기간과 수집간격을 설정한 후 위 화면의 맨 우측에(지면상 여기서는 보이지
않지만) 있는 확인 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들을 계속 유지함으로써 차후에도 비교자료로 사용하겠다는 숨은
JKSPARK@HANAFOS.COM 76
그림 7-16
AWR snapshot 편집화면
http://www.ggola.com 장 경 상
뜻이 있다.
다음은 특정 시점의 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
2 from dba_hist_snapshot
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');
JKSPARK@HANAFOS.COM 77
http://www.ggola.com 장 경 상
PL/SQL procedure successfully completed.
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을 확인하여 조정하는 방법을 보자. 앞서 보았던 작업로드저장소의 그림을
다시 확인해 보자.
JKSPARK@HANAFOS.COM 78
그림 7-15
AWR snapshot 상태화면
http://www.ggola.com 장 경 상
위 그림에서 “보관된 스냅샷 집합”을 보면 앞서 만들었던 baseline의 baseline id가
나타나면 link가 되어있다.
이 link을 click하면 다음과 같은 화면으로 이동한다.
이 화면은 현재 존재하는 baseline의 목록을 보여주며 우측의 dropdown 메뉴를
선택하여 실행함으로써 drop을 하거나 향후 설명할 보고서를 작성하는 등의 작업을
진행할 수 있다.
위 화면에서 우측 상단의 “보관된 스냅샷 집합 생성”을 click하거나 또는 이 그림의 전
그림인 “작업로드저장소”의 하단에 있는 스냅샷에 link된 숫자를 선택하거나 또는 최초
em의 database control에서 “성능 스냅샷”의 화면을 선택하면 다음과 같은
화면으로 이동한다. 여기서 snapshot에 대한 다양한 편집이 가능하다.
JKSPARK@HANAFOS.COM 79
그림 7-17
Snapshot과 Baseline 정보
그림 7-18
Snapshot
편집화면
http://www.ggola.com 장 경 상
우측의 dropdown 메뉴를 통해 다양한 작업을 할 수 있다. 현재 설명하고 있는
snapshot baseline을 만들기 위해서는 이 메뉴 중 “보관된 스냅샷 집합 생성”을
선택하고 좌측에서 시작 스냅샷을 선택한 후 우측의 실행 버튼을 click한다. (좌측
상단에서 시간 또는 일자를 선택하여 찾고자 하는 snapshot list를 추출할 수도 있다)
그러면 다음과 같이 종료 snapshot을 선택하는 화면에서 원하는 snapshot을 선택한
후 확인 버튼을 click하면 baseline이 만들어진다.
아래 그림은 최종 baseline이 생성된 화면이다.
JKSPARK@HANAFOS.COM 80
그림 7-19
Baseline 생성화면
http://www.ggola.com 장 경 상
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);
JKSPARK@HANAFOS.COM 81
그림 7-20
Baseline 생성결과
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 82
http://www.ggola.com 장 경 상
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
--------------------------------------------------------------------------------
JKSPARK@HANAFOS.COM 83
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 84
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 85
http://www.ggola.com 장 경 상
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
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
JKSPARK@HANAFOS.COM 86
http://www.ggola.com 장 경 상
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;
………….
………….
JKSPARK@HANAFOS.COM 87
http://www.ggola.com 장 경 상
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와 그 결과가 동일하다)
JKSPARK@HANAFOS.COM 88
http://www.ggola.com 장 경 상
CF. ADDM의 report는 지정된 snapshot 범위에서 발생한 문제를 해결하는 advisor용
report이고 AWR report는 지정된 snapshot 범위에서 분석한 database의 전반에
걸친 성능 결과보고서다.
7.5.3.3. Using em
다음은 em에서 report를 산출하는 방법이다. 사실 앞서 설명한 em의 화면을 눈 여겨
보았으면 벌써 알았겠지만 database control에서 “성능 스냅샷”의 화면에서
JKSPARK@HANAFOS.COM 89
그림 7-21
AWR Report
그림 7-15
http://www.ggola.com 장 경 상
dropdown 메뉴 중 “보고서 보기”를 선택하면 된다.
아래 그림은 위에서 보고서 보기를 선택하여 start snapshot과 end snapshot을
지정한 후 최종 보고서 화면이다.
JKSPARK@HANAFOS.COM 90
그림 7-23
Snapshot Report
그림 7-22
Snapshot Report 설정하기
http://www.ggola.com 장 경 상
여기서 우측 상단의 “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를 통해 접근할 수 있다.
JKSPARK@HANAFOS.COM 91
http://www.ggola.com 장 경 상
이 내용과 부가적인 정보를 확인한 후 다음의 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
P2 event관련 parameter #2
value
P3 event관련 parameter #3
JKSPARK@HANAFOS.COM 92
표 7-15
ASH 항목과 의미
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 93
표 7-16
SQL 종류별 Code 값
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 94
http://www.ggola.com 장 경 상
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을 보자.
JKSPARK@HANAFOS.COM 95
http://www.ggola.com 장 경 상
[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 15884 1 0 Aug19 ? 00:00:13 ora_arc0_NEWSVC
oracle 15886 1 0 Aug19 ? 00:00:00 ora_arc1_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 7107 1 0 04:42 ? 00:00:00 ora_q001_NEWSVC
oracle 18092 1 0 13:20 ? 00:00:01 ora_j000_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;
JKSPARK@HANAFOS.COM 96
http://www.ggola.com 장 경 상
5 commit;
6 end;
7 /
PL/SQL procedure successfully completed.
SCOTT> exit
Disconnected from Oracle Database 10g Enterprise Edition Release
10.1.0.4.0 - Production
With the Partitioning, OLAP and Data Mining options
[NEWSVC]LIRACLE:/app/oracle/temp>
분명히 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
JKSPARK@HANAFOS.COM 97
http://www.ggola.com 장 경 상
------ ---------- --------------------- --- --------------------------------------- --------- ---------
---------------
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의 변화와 무관하지 않을 것이다.
JKSPARK@HANAFOS.COM 98
http://www.ggola.com 장 경 상
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는 다음과 같은 구조하에 작동된다.
JKSPARK@HANAFOS.COM 99
그림 7-24
Advisor Architecture
http://www.ggola.com 장 경 상
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
------------------ ------------------------------ ----------------
JKSPARK@HANAFOS.COM 100
http://www.ggola.com 장 경 상
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를 설명하면서 이미 살펴본 바 있다
JKSPARK@HANAFOS.COM 101
http://www.ggola.com 장 경 상
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 부분을 다시 살펴보라.
JKSPARK@HANAFOS.COM 102
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 103
http://www.ggola.com 장 경 상
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함으로 별다른 부하를
JKSPARK@HANAFOS.COM 104
http://www.ggola.com 장 경 상
주지 않고 모니터링 작업이 이루어진다.
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에
JKSPARK@HANAFOS.COM 105
http://www.ggola.com 장 경 상
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을 도식화한 그림이다.
JKSPARK@HANAFOS.COM 106
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 107
그림 7-25
Alert Architecture
http://www.ggola.com 장 경 상
으로 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
JKSPARK@HANAFOS.COM 108
http://www.ggola.com 장 경 상
------------------------ --------------------------
--------------------------------------------------------------------------
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
JKSPARK@HANAFOS.COM 109
http://www.ggola.com 장 경 상
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의 비교연산자
(아래 parameter type 참조)
warning_value out warning value
critical_operator out critical threshold의 비교연산자
(아래 parameter type 참조)
critical_value out critical value
observation_perio
d
out threshold 와 metric을 비교하는 주기
JKSPARK@HANAFOS.COM 110
표 7-17
Threshold 설정 Parameter
http://www.ggola.com 장 경 상
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”이다)
(아래 parameter type 참조)
간단하게 예를 들어서 현재 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');
PL/SQL procedure successfully completed.
보기에는 무척 난감하다. 잘 모르는 용어들이 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
JKSPARK@HANAFOS.COM 111
표 7-18
Metric 종류와 의미
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 112
http://www.ggola.com 장 경 상
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
second)Scans for each Second
JKSPARK@HANAFOS.COM 113
http://www.ggola.com 장 경 상
TOTAL_TABLE_SCANS_TXNTotal Table Scans (for each
transaction)
Scans for each
Transaction
FULL_INDEX_SCANS_SECFast Full Index Scans (for each
second)Scans for each Second
FULL_INDEXE_SCANS_TXNFast Full Index Scans (for each
transaction)
Scans for each
Transaction
TOTAL_INDEX_SCANS_SECTotal Index Scans (for each
second)Scans for each Second
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
JKSPARK@HANAFOS.COM 114
http://www.ggola.com 장 경 상
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
session count)Count of sessions
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
session count)Count of sessions
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
session count)Count of sessions
DBR_IO_LIMIT_WAIT_TIMEResource Mgr I/O Limit Wait (by
time)Microseconds
JKSPARK@HANAFOS.COM 115
http://www.ggola.com 장 경 상
DBR_CPU_LIMIT_WAIT_SCTResource Mgr CPU Limit Wait (by
session count)Count of sessions
DBR_CPU_LIMIT_WAIT_TIMEResource Mgr CPU Limit Wait (by
time)Microseconds
DBR_USR_LIMIT_WAIT_SCTResource Mgr User Limit Wait (by
session count)Count of sessions
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
session count)Count of sessions
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
JKSPARK@HANAFOS.COM 116
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 117
http://www.ggola.com 장 경 상
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
PX_DOWNGRADED_50_SECDowngraded to 50% and more
(for each second)
Operations for each
Second
PX_DOWNGRADED_75_SECDowngraded to 75% and more
(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
Microseconds for each
call
CPU_TIME_PER_CALLCPU time for each user call for
each service
Microseconds for each
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와 다르다 (<>, !=)
JKSPARK@HANAFOS.COM 118
표 7-19
Threshold 연산자
http://www.ggola.com 장 경 상
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에 있는 내용들이 포함된다)
JKSPARK@HANAFOS.COM 119
표 7-20
설정가능한
Object
http://www.ggola.com 장 경 상
빨갛게 표시된 box에 alerts의 내용들이 나타난다.
2. 다음은 위 화면의 하단에 있는 “측정 단위 관리”를 선택하여 현재 metric과
threshold를 확인하는 화면이다.
여기서 좌측의 metrics과 우측의 operator 및 warning, critical value를 확인할 수
있다.
3. 다음은 위 화면에서 우측의 “임계값 편집”을 선택하여 원하는 값을 설정하는
화면이다. (앞서 설명한 dbms_server_alert package를 사용하는 것 보다 훨씬 쉽다)
JKSPARK@HANAFOS.COM 120
그림 7-26
Alert와 Threshold
그림 7-28
Threshold 설정
그림 7-27
Threshold 확인
http://www.ggola.com 장 경 상
4. 다음은 위 화면에서 multiple threshold의 설정이 필요한 경우이다. 원하는 metric
을 선택한 후 위 화면 우측의 “다중 임계값 지정”을 선택하면 된다.
예를 들면 위와 같이 tablespace별로 threshold의 값을 다르게 주는 경우가 다중
임계값 설정이 될 수 있다.
5. 사용자가 원하는 경우 em을 사용한다는 전제아래 위 3번 화면의 우측 “측정 단위
스냅샷에서 임계값 복사”를 선택하면 snapshot에서 설명했던 baseline을 선택하여 그
값을 threshold로 적용할 수 있다. 이는 현재 em에서만 지원한다.
6. 다음으로 특정 metric의 상황을 분석해서 보여주는 화면을 보자. 예를 들어 위 1
번에서 보여준 alert중 archive destination의 점유에 관심이 있다면 해당 alert를
click하면 아래와 같은 화면을 볼 수 있다.
JKSPARK@HANAFOS.COM 121
그림 7-30
Alert와 링크
그림 7-29
Multiple Threshold 설정
http://www.ggola.com 장 경 상
물론, metrics을 확인하는 어떤 화면에서도 원하는 metric의 link을 선택하면 해당
화면으로 이동된다. 예를 들면 위 1번 화면의 하단에 있는 “모든 측정 단위”를 선택하여
list된 metric중 관심 metric을 선택해도 마찬가지라는 뜻이다. 아래 화면은 “모든 측정
단위”를 선택하여 그 중에서 archive destination의 사용량을 KB로 표시한 metric을
click한 화면이다.
7. 마지막으로 notification과 관련하여 여러분이 em을 운영하는 서버에서 SNMP
메일이 가능하다면 다음과 같은 절차를 통해 e-mail notification을 할 수 있다.
찾아가는 절차는 다음과 같다. 먼저 “관리” tab 우측의 Enterprise Manager 관리의
“관리자” 좌측 메뉴에서 “통지 방법”을 선택하여 각자의 환경에 맞게 설정하면 된다.
JKSPARK@HANAFOS.COM 122
그림 7-31
Metric과 링크
그림 7-32
Alert Notification
http://www.ggola.com 장 경 상
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');
PL/SQL procedure successfully completed.
SYS> exec dbms_aqadm.add_subscriber(queue_name => 'ALERT_QUE', -
JKSPARK@HANAFOS.COM 123
http://www.ggola.com 장 경 상
> subscriber => aq$_agent('USRMON_AGT', '', 0));
PL/SQL procedure successfully completed.
SYS> exec dbms_aqadm.enable_db_access(agent_name => 'USRMON_AGT',
-
> db_username => 'SYSTEM');
PL/SQL procedure successfully completed.
SYS> exec dbms_aqadm.grant_queue_privilege(privilege => 'DEQUEUE', -
> queue_name => 'ALERT_QUE', grantee => 'SYSTEM', grant_option =>
FALSE);
PL/SQL procedure successfully completed.
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;
JKSPARK@HANAFOS.COM 124
http://www.ggola.com 장 경 상
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;
/
JKSPARK@HANAFOS.COM 125
http://www.ggola.com 장 경 상
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
PL/SQL procedure successfully completed.
원래의 상태로 돌아가기 위해서는 다음과 같은 반대의 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));
JKSPARK@HANAFOS.COM 126
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 127
http://www.ggola.com 장 경 상
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
…
JKSPARK@HANAFOS.COM 128
http://www.ggola.com 장 경 상
…
~
~
~
~
:wq!
[NEWSVC]LIRACLE:/app/oracle/temp>
위에서 굵게 표시된 두 parameter를 remark하였다. 이제 database를 restart하자.
[NEWSVC]LIRACLE:/app/oracle/temp> sqlplus / as sysdba
SQL*Plus: Release 10.1.0.4.0 - Production on Fri Aug 26 17:41:10 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>
JKSPARK@HANAFOS.COM 129
http://www.ggola.com 장 경 상
정상적으로 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로
JKSPARK@HANAFOS.COM 130
http://www.ggola.com 장 경 상
조절할 수 있다.
다음은 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’);
JKSPARK@HANAFOS.COM 131
http://www.ggola.com 장 경 상
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. 위 내용을 도식화 하면 다음과 같다.
JKSPARK@HANAFOS.COM 132
http://www.ggola.com 장 경 상
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)
JKSPARK@HANAFOS.COM 133
그림 7-33
System 통계와 권한
표 7-21
통계수집의 Option
http://www.ggola.com 장 경 상
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부터는 이러한
JKSPARK@HANAFOS.COM 134
http://www.ggola.com 장 경 상
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)에서도 적절하게
수정해야 한다.
JKSPARK@HANAFOS.COM 135
http://www.ggola.com 장 경 상
OCP point
==============================================
=================
1. PGA관리 자동화 개념
2. dictionary 통계 수집방법
3. dbms_stats을 통한 통계자료 수집 시 GRANULARITY option의 의미
참조
==============================================
=================
PGA 자동관리 : o9i 327p
pga_aggregate_target, workarea_size_policy : o9i 328p
JKSPARK@HANAFOS.COM 136
http://www.ggola.com 장 경 상
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의 대상이
되기 이전에 이미 해결이 되는 경우가 대부분이고 그 외의 것들이 항상 숙제로 남아
JKSPARK@HANAFOS.COM 137
표 7-22
Optimizer Mode
http://www.ggola.com 장 경 상
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에 대하여 적절한 통계 수집의 필요성을 권고
JKSPARK@HANAFOS.COM 138
http://www.ggola.com 장 경 상
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로
JKSPARK@HANAFOS.COM 139
http://www.ggola.com 장 경 상
저장되고 일반 사용자가 종전과 다름없이 해당 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의 처리를 도식화한 것이다.
JKSPARK@HANAFOS.COM 140
그림 7-34
Optimizer와 SQL Profile
http://www.ggola.com 장 경 상
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를 해주지는 않는다는 뜻이다. 왜냐하면 바로
JKSPARK@HANAFOS.COM 141
http://www.ggola.com 장 경 상
언급했듯이 “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이 진행된다.
JKSPARK@HANAFOS.COM 142
http://www.ggola.com 장 경 상
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을 통해 접근해
JKSPARK@HANAFOS.COM 143
그림 7-35
em SQL Tuning Advisor
http://www.ggola.com 장 경 상
보자.
위 화면에서 보듯이 주요 SQL들을 볼 수 있고 이를 복수로 선택하여 위 화면 하단
중앙의 “Run SQL Tuning Advisor”를 통해 직접 tuning을 수행할 수도 있고 “Create
SQL Tuning Set”을 통해 STS를 만들 수도 있다.
CF. 만일 여러분이 ADDM을 통해 그 분석결과를 가지고 SQL tuning advisor를
수행하려 한다면 다음과 같은 ADDM 분석결과 화면에서 바로 “Run SQL Tuning
Advisor”를 수행할 수 있다.
JKSPARK@HANAFOS.COM 144
그림 7-36
em SQL Tuning Advisor
http://www.ggola.com 장 경 상
7.8.3.3. STS 생성위 Top SQL 화면에서 몇 개의 SQL을 가지고 STS를 만들어 보자. 다음과 같이 주요
SQL을 선택해 보자.
STS 생성 버튼을 누르면 다음과 같다.
JKSPARK@HANAFOS.COM 145
그림 7-37
em SQL Tuning Advisor
그림 7-38
SQL Tuning Set 설정
그림 7-39
SQL Tuning Set 생성
http://www.ggola.com 장 경 상
원하는 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을
실시하여 그 결과를 본 화면이다.
JKSPARK@HANAFOS.COM 146
그림 7-40
SQL Tuning Set 생성
http://www.ggola.com 장 경 상
상단에는 분석대상이 되는 SQL이 나오고 하단에는 다음과 같은 화면을 볼 수 있다.
위 화면에서 scope의 “Limited…”는 앞서 설명한 ATO가 실시하는 각종 분석작업을
통해 tuning을 하겠다는 의미이고 “Comprehensive…”는 “Limited…”에 추가적으로
SQL Profile을 만들겠다는 뜻이다. 그리고 하단의 schedule은 지금 tuning을 실시할
것인지 아니면 시간을 지정하여 차후에 적절한 시간에 schedule을 통해 수행할
것이라는 의미이다. 일단 위와 같이 default 상태에서 tuning을 실시해보자. 우측
하단의 “OK”버튼을 눌러보자.
JKSPARK@HANAFOS.COM 147
그림 7-41
SQL List
그림 7-42
SQL Tuning Option
http://www.ggola.com 장 경 상
이제 위 화면에서 원하는 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의
사용법 정도는 알고 있어야겠다.
JKSPARK@HANAFOS.COM 148
그림 7-43
SQL Tuning 결과
그림 7-44
SQL Tuning 추천결과
http://www.ggola.com 장 경 상
제일 먼저 할 일은 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,
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
------------- -----------------------
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%';
JKSPARK@HANAFOS.COM 149
http://www.ggola.com 장 경 상
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');
PL/SQL procedure successfully completed.
SYSTEM> print :task_id
TASK_ID
--------------------------------------------------------------------------------
TASK_1831
SYSTEM> exec dbms_sqltune.execute_tuning_task(task_name => :task_id);
PL/SQL procedure successfully completed.
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
----------------------------------------------------
JKSPARK@HANAFOS.COM 150
http://www.ggola.com 장 경 상
SYSTEM> set long 1000000 pagesize 0 longchunksize 1000
SYSTEM> select dbms_sqltune.report_tuning_task(:task_id)
2 from dual;
GENERAL INFORMATION SECTION
-------------------------------------------------------------------------------
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
JKSPARK@HANAFOS.COM 151
http://www.ggola.com 장 경 상
-------------------------------------------- ------------------------------
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');
PL/SQL procedure successfully completed.
이제 다시 tuning 절차를 수행한다.
SYSTEM> exec :task_id := dbms_sqltune.create_tuning_task(-
> sqlset_name => 'STS_20050905_002');
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_sqltune.execute_tuning_task(task_name => :task_id);
PL/SQL procedure successfully completed.
SYSTEM> select dbms_sqltune.report_tuning_task(:task_id)
2 from dual;
DBMS_SQLTUNE.REPORT_TUNING_TASK(:TASK_ID)
--------------------------------------------------------------------------------
GENERAL INFORMATION SECTION
-------------------------------------------------------------------------------
Tuning Task Name : TASK_1833
Scope : COMPREHENSIVE
Time Limit(seconds) : 1800
JKSPARK@HANAFOS.COM 152
http://www.ggola.com 장 경 상
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;
....
....
-------------------------------------------------------------------------------
There are no recommendations to improve the statement.
....
....
Object ID: 3
....
....
-------------------------------------------------------------------------------
There are no recommendations to improve the statement.
....
....
Object ID: 4
....
....
-------------------------------------------------------------------------------
There are no recommendations to improve the statement.
....
....
Object ID: 5
....
....
-------------------------------------------------------------------------------
JKSPARK@HANAFOS.COM 153
http://www.ggola.com 장 경 상
There are no recommendations to improve the statement.
....
....
-------------------------------------------------------------------------------
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');
PL/SQL procedure successfully completed.
JKSPARK@HANAFOS.COM 154
http://www.ggola.com 장 경 상
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의 수정은 다음과 같다.
JKSPARK@HANAFOS.COM 155
http://www.ggola.com 장 경 상
SYSTEM> exec dbms_sqltune.alter_sql_profile(-
> '1st_profile_advice', 'CATEGORY', 'XTEST');
PL/SQL procedure successfully completed.
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');
PL/SQL procedure successfully completed.
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”권한이 필요하다. 먼저 만들어 보자.
JKSPARK@HANAFOS.COM 156
http://www.ggola.com 장 경 상
SYSTEM> exec dbms_sqltune.create_sqlset('X10G_STS', 'FromAWR');
PL/SQL procedure successfully completed.
위 내용은 “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 /
JKSPARK@HANAFOS.COM 157
http://www.ggola.com 장 경 상
PL/SQL procedure successfully completed.
위 작업은 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로 이를
확인해 보자.
SYSTEM> select count(*) from
2 table(dbms_sqltune.select_sqlset('X10G_STS', 'disk_reads > 10'));
COUNT(*)
--------------
2
JKSPARK@HANAFOS.COM 158
http://www.ggola.com 장 경 상
이 결과는 위에서 지정한 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');
PL/SQL procedure successfully completed.
SYSTEM> select count(*) from
2 table(dbms_sqltune.select_sqlset('X10G_STS', 'disk_reads > 10'));
COUNT(*)
---------------
0
SYSTEM> select id, name, statement_count
2 from dba_sqlset
3 where description = 'FromAWR';
ID NAME STATEMENT_COUNT
---------- ------------------------------ --------------------------------
9 X10G_STS 56
위 결과는 2개의 SQL이 삭제되었음을 보여준다. 만일 더 이상 STS가 필요하지 않다고
판단되면 다음과 같이 drop을 하면 된다.
SYSTEM> exec dbms_sqltune.drop_sqlset('X10G_STS');
PL/SQL procedure successfully completed.
SYSTEM> select id, name, statement_count
2 from dba_sqlset
3 where description = 'FromAWR';
JKSPARK@HANAFOS.COM 159
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 160
http://www.ggola.com 장 경 상
라 칭한다)의 구성요소 이다. 이미 언급했지만 필수 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를 해주는
JKSPARK@HANAFOS.COM 161
표 7-23
SQL 정보 List
http://www.ggola.com 장 경 상
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.
JKSPARK@HANAFOS.COM 162
표 7-24
SQL Access 분석 Mode
http://www.ggola.com 장 경 상
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를 선택한다
JKSPARK@HANAFOS.COM 163
그림 7-45
em Advisor Central
그림 7-46
SQL Access Advisor
http://www.ggola.com 장 경 상
현재는 user-defined workload를 선택하여 앞서 생성한 table을 지정했다.
좌측 하단에 option을 선택하면(여러분이 필요하다면 수행하라) 다음 화면이 나타난다.
JKSPARK@HANAFOS.COM 164
http://www.ggola.com 장 경 상
이 화면에서는 여러 분석유형 및 filtering 조건을 줄 수 있다. 현재 테스트를 위해
만들어진 user-defined workload “X_WKLD_SCOTT”은 SQL문과 사용자 명만을
가지고 있기 때문에 위의 option 화면에서 filtering을 할 수 없을 것이다.
다음은 “Next” 버튼을 통해 두 번째 단계인 recommendation option화면으로 이동한
것이다.
Step #2 : 분석 유형을 선택한다
JKSPARK@HANAFOS.COM 165
그림 7-47
SQL Access Advisor
http://www.ggola.com 장 경 상
여기서 index와 MView 혹은 둘 다 분석할 것인가를 선택하고 앞서 설명한 분석 유형인
limited와 comprehensive중에서 하나를 선택한다.
좌측 하단의 option을 선택하면(역시 필요하다면 선택하라) 다음과 같은 창을 볼 수
있다.
여기서는 분석 결과에 대한 용량제한, tuning option(buffer gets과 같은 통계 선택),
분석 결과에 나타나는 storage option의 default값 들을 조정할 수 있다.
이제 다음 단계로 이동을 위해 “Next”를 선택하면 schedule 창이 나타난다.
JKSPARK@HANAFOS.COM 166
그림 7-48
SQL Access Advisor
그림 7-49
SQL Access Advisor
http://www.ggola.com 장 경 상
Step #3 : 분석 schedule을 정의한다
이 단계는 access advisor가 언제 분석 작업을 수행할 것인가를 설정한다. 미리
정의된 schedule이 없으면 위에서처럼 Standard를 선택하라. 그러면 다음과 같은
창이 하단에 추가적으로 나타난다.
JKSPARK@HANAFOS.COM 167
그림 7-50
SQL Access Advisor
http://www.ggola.com 장 경 상
이 화면에서 여러분이 직접 수행시간을 설정할 수 있다. 반복적으로 그리고 나중에 분석
작업을 수행할 수도 있다. 현재는 지금 바로 분석을 하도록 설정된 default값들을
수정하지 않고 그대로 다음 단계로 이동한다.
Step #4 : 전체적으로 분석작업에 대한 review를 한다
JKSPARK@HANAFOS.COM 168
그림 7-51
SQL Access Advisor
http://www.ggola.com 장 경 상
이제 마지막 단계로 현재까지의 작업설정을 점검하는 화면이다. 최종적으로 “Submit”
을 하면 다음과 같은 화면으로 이동한다.
CF. 필요하다면 여기서 우측 상단의 “Show SQL”을 통해 이 작업들을 직접 수행할 수
있도록 SQL code를 만들어 사용할 수도 있다.
Result #1 : task를 선택하여 작업 결과를 확인한다
위 화면에는 advisor task가 만들어 졌음을 보여준다. 여기서 적절한 task를 선택한 후
JKSPARK@HANAFOS.COM 169
그림 7-52
SQL Access Advisor
그림 7-53
SQL Access 분석결과
http://www.ggola.com 장 경 상
중앙 하단에 “View Result”를 누르면 분석결과를 볼 수 있다. 이 작업은 경우에 따라
상당한 시간이 소요될 수 있다. 따라서 여러분이 능숙하게 이 작업을 할 수 있게 된다면
앞서 step3의 schedule을 잘 활용하면 좋을 것이다.
Result #2 : 최종 분석결과를 확인한다
위 화면에서 최종 결과를 확인할 수 있다. 그래프 형식을 통해 recommendation id별
cost benefit을 보여주고 하단에는 그 내역을 보여준다. 하단의 id를 선택하면 해당 id
의 action list 즉, 어떤 권장사항들을 수행해야 하는지 알 수 있다.
Result #3 : 세부 action list를 확인한다.
JKSPARK@HANAFOS.COM 170
그림 7-54
SQL Access 분석결과
http://www.ggola.com 장 경 상
유지할 index와 새로 생성할 필요가 있는 index에 대해 list를 보여준다. 하단에는 이
action list로 인해 영향을 받을 수 있는 SQL 내역을 보여주고 있다. “OK”를 통해 다시
Result #2화면으로 돌아가보자. 그리고 “Show SQL” 버튼을 click하라.
Result #4 : SQL scripts 생성
JKSPARK@HANAFOS.COM 171
그림 7-55
SQL Access 분석결과
http://www.ggola.com 장 경 상
위와 같은 종류의 권장사항을 수행할 script를 볼 수 있다. 만일, 앞서 Result #2
화면에서 tablespace와 같이 조정이 가능한 항목을 수정했다면 그 내용은 위 화면에서
그대로 반영된다. 예를 들어 Result #2에서 tablespace를 “TOOLS”로 지정했다면
아래와 같은 결과를 볼 수 있을 것이다.
JKSPARK@HANAFOS.COM 172
그림 7-56
SQL Access 분석결과
http://www.ggola.com 장 경 상
여러분이 이 script를 사용하여 다른 SQL session에서 필요한 작업을 해도 되지만
만일 위 script를 그대로 수행하고 싶다면 “OK” 버튼을 통해 Result #2화면으로
돌아가라. 그리고 “Schedule Implementation” 버튼을 click하라.
Result #5 : 작업 schedule을 선택하라.
JKSPARK@HANAFOS.COM 173
그림 7-57
SQL Access 분석결과
http://www.ggola.com 장 경 상
이제 위 화면에서 scheduling을 통해 권장사항으로 나타난 SQL script를 그대로
수행시킬 수 있다. Option을 통해 schedule을 만들 수도 있지만 지금 바로 수행을
원한다면 위와 같이 default “Immediately”상태에서 “Submit”을 수행한다. (안전한
작업의 진행을 위해 “Submit”전에 “Show SQL”을 통해 script를 확인하는 것도 좋은
습관이다) “Submit”이 수행되면 다음 화면으로 이동된다. 모든 작업이 종료되었다.
다음의 SQL 결과는 위의 작업이 제대로 수행되었음을 확인 시켜준다. 마지막 index의
이름과 생성일자를 비교해 보라.
SYSTEM> col crdte for a20
SYSTEM> col object_name for a20
SYSTEM> select object_name, to_char(created, 'YYYYMMDD HH24:MI:SS')
crdte
JKSPARK@HANAFOS.COM 174
그림 7-58
SQL Access 분석결과
그림 7-59
SQL Access 분석결과
http://www.ggola.com 장 경 상
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');
PL/SQL procedure successfully completed.
SYSTEM> declare
2 snap_ref_cursor dbms_sqltune.sqlset_cursor;
3 begin
4 open snap_ref_cursor for
5 select value(X) from table
JKSPARK@HANAFOS.COM 175
http://www.ggola.com 장 경 상
6 (dbms_sqltune.select_workload_repository(1734, 1764)) X;
7 dbms_sqltune.load_sqlset('MANUAL_STS01', snap_ref_cursor);
8 end;
9 /
PL/SQL procedure successfully completed.
위 결과는 성공적으로 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';
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_advisor.create_sqlwkld(:wkld_name, 'FROM STS');
PL/SQL procedure successfully completed.
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);
PL/SQL procedure successfully completed.
SYSTEM> print :success_row
SUCCESS_ROW
----------------------
13
JKSPARK@HANAFOS.COM 176
http://www.ggola.com 장 경 상
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';
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_advisor.create_task('SQL Access
Advisor', :task_id, :task_name);
PL/SQL procedure successfully completed.
SYSTEM> print :task_id
TASK_ID
--------------
1915
Step #4 : 이제 위에서 만든 advisor task에 새로 생성한 workload를 연결한다.
SYSTEM> exec dbms_advisor.add_sqlwkld_ref(:task_name, :wkld_name);
PL/SQL procedure successfully completed.
JKSPARK@HANAFOS.COM 177
http://www.ggola.com 장 경 상
Step #5 : SQL access advisor task를 수행한다.
SYSTEM> exec dbms_advisor.execute_task(:task_name);
PL/SQL procedure successfully completed.
이제 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%
----------- ---------- -------------- ---------------- --------------
JKSPARK@HANAFOS.COM 178
http://www.ggola.com 장 경 상
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를 그대로 유지하라는 것뿐 실제 수행할 것은 없다.
JKSPARK@HANAFOS.COM 179
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 180
http://www.ggola.com 장 경 상
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")
JKSPARK@HANAFOS.COM 181
http://www.ggola.com 장 경 상
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');
dbms_advisor.mark_recommendation('MANUAL_ACS_TSK001',2,'IMPLEMENTED');
dbms_advisor.mark_recommendation('MANUAL_ACS_TSK001',3,'IMPLEMENTED');
dbms_advisor.mark_recommendation('MANUAL_ACS_TSK001',4,'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
JKSPARK@HANAFOS.COM 182
http://www.ggola.com 장 경 상
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.
JKSPARK@HANAFOS.COM 183
http://www.ggola.com 장 경 상
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”를 참조하라)
JKSPARK@HANAFOS.COM 184
표 7-25
Workload Procedure List
http://www.ggola.com 장 경 상
OCP point
==============================================
=================
1. SQL tuning advisor의 4가지 결과물
2. SQL access advisor를 통해 creation을 권고 받을 수 있는 object의 종류
JKSPARK@HANAFOS.COM 185
http://www.ggola.com 장 경 상
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 첫 화면을 보자. 이미 여러분은 이 화면에 익숙해져
있을 것이다.
JKSPARK@HANAFOS.COM 186
http://www.ggola.com 장 경 상
이 화면은 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
하라.
JKSPARK@HANAFOS.COM 187
그림 7-60
em 초기화면
http://www.ggola.com 장 경 상
위 화면에서 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
해 보자.
JKSPARK@HANAFOS.COM 188
그림 7-61
성능측정 화면
http://www.ggola.com 장 경 상
보다 자세하게 정보를 보여주고 있다. 관련된 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을 맡겨도 좋겠다.
JKSPARK@HANAFOS.COM 189
그림 7-62
세부 성능측정 화면
http://www.ggola.com 장 경 상
OCP point
==============================================
=================
1. em database control의 performance tab에 나타나는 항목들
JKSPARK@HANAFOS.COM 190
http://www.ggola.com 장 경 상
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을 여러
JKSPARK@HANAFOS.COM 191
http://www.ggola.com 장 경 상
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 ;
JKSPARK@HANAFOS.COM 192
http://www.ggola.com 장 경 상
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.create_plan('move_plan', 'execution above
10 sec') ;
PL/SQL procedure successfully completed.
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') ;
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.create_consumer_group('long_grp', 'long
working') ;
PL/SQL procedure successfully completed.
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 ) ;
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.create_plan_directive('move_plan',
'long_grp',-
> 'rule for long job', cpu_p1 => 0, cpu_p2 => 100);
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.create_plan_directive('move_plan',-
JKSPARK@HANAFOS.COM 193
http://www.ggola.com 장 경 상
> 'other_groups', 'other groups for normal', cpu_p1 => 0, cpu_p2 => 0, cpu_p3 =>
100) ;
PL/SQL procedure successfully completed.
Step #3 : 다음은 resource plan설정을 완료한 후 테스트할 계정인 xrsrc에게
consumer group을 switch할 수 있는 권한을 부여하고 initial group을 설정한다.
SYSTEM> exec dbms_resource_manager.validate_pending_area ;
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.submit_pending_area ;
PL/SQL procedure successfully completed.
SYSTEM> exec
dbms_resource_manager_privs.grant_switch_consumer_group(-
> 'xrsrc', 'short_grp', FALSE) ;
PL/SQL procedure successfully completed.
SYSTEM> exec
dbms_resource_manager_privs.grant_switch_consumer_group(-
> 'xrsrc', 'long_grp', FALSE) ;
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.set_initial_consumer_group('xrsrc',
'short_grp') ;
PL/SQL procedure successfully completed.
Step #4 : 다음은 내용이 좀 복잡해 보이지만 별로 어려운 것은 아니다. 앞으로 작업할
내용을 하나씩 정리하면 다음과 같다.
1. 현재 설정된 initial consumer group 즉, 현재 설명하고 있는 original consumer
JKSPARK@HANAFOS.COM 194
http://www.ggola.com 장 경 상
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.
JKSPARK@HANAFOS.COM 195
http://www.ggola.com 장 경 상
XRSRC> set timing on
XRSRC> select resource_consumer_group
2 from v$session where username = 'XRSRC';
RESOURCE_CONSUMER_GROUP
------------------------------------------------
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의
변화를 먼저 확인하자.
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 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);
JKSPARK@HANAFOS.COM 196
http://www.ggola.com 장 경 상
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
9 where username = 'XRSRC';
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
16 where username = 'XRSRC';
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
PL/SQL procedure successfully completed.
Elapsed: 00:00:34.51
위 결과를 보면 call이 10초 이상 수행되었고 따라서 print된 “Before Group”의 값과
“Switched Group”의 값의 변화를 통해 이미 switch 작업이 발생했었음이 확인된다.
Step #7(SYSTEM 창) : 이제 consumer group의 switch로 인한 CPU usage를 다시
확인해 보자.
SYSTEM> select name, cpu_wait_time, consumed_cpu_time
2 from v$rsrc_consumer_group;
NAME CPU_WAIT_TIME CONSUMED_CPU_TIME
JKSPARK@HANAFOS.COM 197
http://www.ggola.com 장 경 상
-------------------------------- ------------------------- ----------------------------------
LONG_GRP 0 11516
OTHER_GROUPS 2974 5897
SHORT_GRP 0 7085
분명히 long_grp의 CPU 사용량이 증가 했음을 확인할 수 있다.
Step #8(XRSRC 창) : 이제 마지막으로 테스트 계정의 session에서 consumer
group이 original group으로 되돌려 졌는지를 확인하는 것으로 테스트를 종료한다.
XRSRC> select resource_consumer_group
2 from v$session where username = 'XRSRC';
RESOURCE_CONSUMER_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한다.
JKSPARK@HANAFOS.COM 198
그림 7-63
Resource Plan List
그림 7-64
Plan 설정화면
http://www.ggola.com 장 경 상
이상하겠지만 위 그림에서 보듯 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_pending_area ;
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.create_consumer_group(-
> 'idle_grp', 'working for idle features');
PL/SQL procedure successfully completed.
JKSPARK@HANAFOS.COM 199
http://www.ggola.com 장 경 상
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);
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.validate_pending_area ;
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.submit_pending_area ;
PL/SQL procedure successfully completed.
SYSTEM> exec
dbms_resource_manager_privs.grant_switch_consumer_group(-
> 'xrsrc', 'idle_grp', FALSE);
PL/SQL procedure successfully completed.
이제 테스트를 위해 테스트 계정으로 login한 후 다른 창에서 system 계정으로 해당
계정의 consumer group을 “IDLE_GRP”로 변경하자.
테스트 계정 : 현재의 consumer group을 확인하고 session정보를 추출하자.
XRSRC> select resource_consumer_group
2 from v$session where username = 'XRSRC';
RESOURCE_CONSUMER_GROUP
-----------------------------------------------
SHORT_GRP
XRSRC> select sid, serial# from v$session
2 where audsid = userenv('SESSIONID');
JKSPARK@HANAFOS.COM 200
http://www.ggola.com 장 경 상
SID SERIAL#
---------- ------------
522 14064
SYSTEM 계정 : 이제 위 정보를 바탕으로 테스트계정의 consumer group을 idle_grp
로 변경해 보자.
SYSTEM> exec dbms_resource_manager.switch_consumer_group_for_sess(-
> 522, 14064, 'idle_grp');
PL/SQL procedure successfully completed.
테스트 계정 : consumer group의 변동사항을 확인한다.
XRSRC> select resource_consumer_group
2 from v$session where username = 'XRSRC';
RESOURCE_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으로
지정하자.
JKSPARK@HANAFOS.COM 201
http://www.ggola.com 장 경 상
SYSTEM> exec dbms_resource_manager.create_pending_area ;
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.delete_plan_directive('move_plan',
'idle_grp');
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.create_plan_directive('move_plan',
'idle_grp' -;
> 'test for idle session', cpu_p4 => 100,-
> max_idle_blocker_time => 10);
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.validate_pending_area ;
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.submit_pending_area ;
PL/SQL procedure successfully completed.
테스트 계정 #1 : 현재 consumer group을 확인하자.
XRSRC> conn xrsrc/xrsrc
Connected.
XRSRC> select resource_consumer_group
2 from v$session where username = 'XRSRC';
RESOURCE_CONSUMER_GROUP
-----------------------------------------------
SHORT_GRP
XRSRC> select sid, serial# from v$session
JKSPARK@HANAFOS.COM 202
http://www.ggola.com 장 경 상
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로 변경하자.
SYSTEM> exec dbms_resource_manager.switch_consumer_group_for_sess(-
> 521, 5005, 'idle_grp');
PL/SQL procedure successfully completed.
테스트 계정 #1 : consumer group의 변동사항을 확인하고 table에 lock을 만들어
보자.
XRSRC> select resource_consumer_group
2 from v$session where username = 'XRSRC';
RESOURCE_CONSUMER_GROUP
-----------------------------------------------
IDLE_GRP
SHORT_GRP
XRSRC> set timing on
XRSRC> delete from rsrc_cnt;
JKSPARK@HANAFOS.COM 203
http://www.ggola.com 장 경 상
1 row deleted.
Elapsed: 00:00:00.00
테스트 계정 #2 : 이제 위에서 lock을 잡고 있는 data에 access하여 blocking을
발생시킨다.
XRSRC> set timing on
XRSRC> delete from rsrc_cnt;
1 row deleted.
…………waiting………….
테스트 계정 #2 : 시간이 흐르면서 변화를 지켜본다. 현재 session의 blocking time
이 10초이니 최대 1분 안에 다음과 같이 응답이 올 것이다.
XRSRC> delete from rsrc_cnt;
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에서
JKSPARK@HANAFOS.COM 204
http://www.ggola.com 장 경 상
간단히 정의할 수 있다. “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가
JKSPARK@HANAFOS.COM 205
그림 7-65
Plan 설정내역 확인
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 206
표 7-26
Resource Group Mapping
http://www.ggola.com 장 경 상
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();
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.create_pending_area();
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.set_consumer_group_mapping(-
> dbms_resource_manager.module_name, 'MAP_LONG_QUERY',
'LONG_GRP');
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.submit_pending_area();
PL/SQL procedure successfully completed.
JKSPARK@HANAFOS.COM 207
http://www.ggola.com 장 경 상
이제 현재 테스트를 진행하고 있는 계정 xrsrc로 login을 하자.
XRSRC> conn xrsrc/xrsrc
Connected.
XRSRC> select resource_consumer_group from v$session
2 where audsid = userenv('sessionid');
RESOURCE_CONSUMER_GROUP
-----------------------------------------------
SHORT_GRP
이제 application module의 이름을 앞서 resource group mapping에 사용한
이름으로 설정한 후 그 변화를 확인해 보자.
XRSRC> exec dbms_application_info.set_module(-
> 'MAP_LONG_QUERY', '1st Action');
PL/SQL procedure successfully completed.
XRSRC> select resource_consumer_group from v$session
2 where audsid = userenv('sessionid');
RESOURCE_CONSUMER_GROUP
-----------------------------------------------
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
JKSPARK@HANAFOS.COM 208
http://www.ggola.com 장 경 상
에서 module혹은 action을 변경할 때마다 resource group이 계속해서 변경될
것이다.
CF. 위 mapping items 중에는 복수의 combination 구성이 있다. 즉, module name
과 action을 설정하거나, service name과 module등으로 구성하는 것이 그것이다.
이런 구성으로 resource를 mapping하기 위해서는 “.”을 사용해서 구분하면 된다.
다음의 예는 module_action의 값을 구현하기 위하여 “.”을 사용하는 방식이다.
SYSTEM> exec dbms_resource_manager.set_consumer_group_mapping(-
> 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보다 높게 설정한 것이다.
SYSTEM> exec dbms_resource_manager.clear_pending_area();
JKSPARK@HANAFOS.COM 209
http://www.ggola.com 장 경 상
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.create_pending_area();
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.set_consumer_group_mapping(-
> dbms_resource_manager.service_name,-
> 'NEWSVC', 'DEFAULT_CONSUMER_GROUP');
PL/SQL procedure successfully completed.
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);
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.submit_pending_area();
PL/SQL procedure successfully completed.
이제 테스트 계정으로 다음과 같이 두 가지 방식의 session을 연결해 보자. 첫 번째는
보통의 connection이고 두 번째는 tnsnames.ora를 이용하여 listener를 통해
연결하는 것이다. 이 resource consumer group의 변화를 살펴보자.
XRSRC> conn xrsrc/xrsrc
Connected.
XRSRC> select resource_consumer_group from v$session
2 where audsid = userenv('sessionid');
RESOURCE_CONSUMER_GROUP
JKSPARK@HANAFOS.COM 210
http://www.ggola.com 장 경 상
-----------------------------------------------
SHORT_GRP
XRSRC> conn xrsrc/xrsrc@newsvc
Connected.
XRSRC> select resource_consumer_group from v$session
2 where audsid = userenv('sessionid');
RESOURCE_CONSUMER_GROUP
-----------------------------------------------
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');
PL/SQL procedure successfully completed.
XRSRC> select resource_consumer_group from v$session
2 where audsid = userenv('sessionid');
RESOURCE_CONSUMER_GROUP
-----------------------------------------------
LONG_GRP
이제 module name을 설정하였고 module_name의 우선 순위가 service_name의
우선 순위보다 높음으로 long_grp가 할당되었음이 확인된다. 다음은 system 계정의
창에서 이 우선순위를 반대로 바꾸는 과정이다. 우선순위의 속성인 service_name과
module_name의 순위를 서로 맞바꾸어 보자.
SYSTEM> exec dbms_resource_manager.clear_pending_area();
JKSPARK@HANAFOS.COM 211
http://www.ggola.com 장 경 상
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.create_pending_area();
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.set_consumer_group_mapping_pri(-
> explicit => 1, service_module_action => 2,-
> service_module => 3, module_name => 6,-
> module_name_action => 5, service_name => 4,-
> oracle_user => 7, client_program => 8,-
> client_os_user => 9,client_machine => 10);
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.submit_pending_area();
PL/SQL procedure successfully completed.
이제 다시 테스트 계정으로 가서 어떤 변경이 있는지 확인하자.
XRSRC> select resource_consumer_group from v$session
2 where audsid = userenv('sessionid');
RESOURCE_CONSUMER_GROUP
------------------------------------------------
DEFAULT_CONSUMER_GROUP
우선순위의 변경으로 resource consumer group의 변경도 확인된다. 하나 더 확인해
보자. 이번에는 우리가 직접 설정하지는 않았던 oracle_user의 우선순위를
service_name과 맞바꾸어 보자.
SYSTEM> exec dbms_resource_manager.clear_pending_area();
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.create_pending_area();
JKSPARK@HANAFOS.COM 212
http://www.ggola.com 장 경 상
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.set_consumer_group_mapping_pri(-
> explicit => 1, service_module_action => 2,-
> service_module => 3, module_name => 6,-
> module_name_action => 5, service_name => 7,-
> oracle_user => 4, client_program => 8,-
> client_os_user => 9,client_machine => 10);
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.submit_pending_area();
PL/SQL procedure successfully completed.
이제 또다시 테스트 계정의 창으로 이동하여 그 변화를 확인해 보자.
XRSRC> select resource_consumer_group from v$session
2 where audsid = userenv('sessionid');
RESOURCE_CONSUMER_GROUP
-----------------------------------------------
SHORT_GRP
원래의 initial resource consumer group으로 변경이 되었다. 앞서도 잠깐 언급이
되었지만 initial group을 할당함과 동시에 resource mapping이 일어난 것을 어렵지
않게 추측할 수 있을 것이다.
마지막으로 직접 consumer group을 변경했을 때(explicitly) 우선순위의 변경에 따라
그 변화를 확인해 보자. 먼저 테스트 계정의 창에서 새로 login을 하여 resource
consumer group을 확인하고 system 창에서 explicit의 우선순위가 어떤지 보자.
테스트 창 :
XRSRC> conn xrsrc/xrsrc
Connected.
XRSRC> select resource_consumer_group from v$session
JKSPARK@HANAFOS.COM 213
http://www.ggola.com 장 경 상
2 where audsid = userenv('sessionid');
RESOURCE_CONSUMER_GROUP
-----------------------------------------------
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);
PL/SQL procedure successfully completed.
XRSRC> select resource_consumer_group from v$session
2 where audsid = userenv('sessionid');
RESOURCE_CONSUMER_GROUP
-----------------------------------------------
IDLE_GRP
XRSRC> exec dbms_application_info.set_module('MAP_LONG_QUERY',-
> 'TEST ACTION');
PL/SQL procedure successfully completed.
JKSPARK@HANAFOS.COM 214
http://www.ggola.com 장 경 상
XRSRC> select resource_consumer_group from v$session
2 where audsid = userenv('sessionid');
RESOURCE_CONSUMER_GROUP
------------------------------------------------
IDLE_GRP
제대로 변경이 되었음을 물론 최 상위 priority로 인하여 앞서 생성했던
module_name의 설정도 반영되지 않고 있음을 알 수 있다.
이제 system창에서 explicit의 priority를 가장 낮은 10단계로 변경한 후 테스트
창에서의 변화를 보자.
SYSTEM 창 :
SYSTEM> exec dbms_resource_manager.clear_pending_area();
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.create_pending_area();
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.set_consumer_group_mapping_pri(-
> explicit => 10, service_module_action => 2,-
> service_module => 3, module_name => 6,-
> module_name_action => 5, service_name => 4,-
> oracle_user => 7, client_program => 8,-
> client_os_user => 9,client_machine => 1);
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.submit_pending_area();
PL/SQL procedure successfully completed.
JKSPARK@HANAFOS.COM 215
http://www.ggola.com 장 경 상
테스트 창 :
XRSRC> select resource_consumer_group from v$session
2 where audsid = userenv('sessionid');
RESOURCE_CONSUMER_GROUP
-----------------------------------------------
LONG_GRP
위 결과는 자동으로 explicit보다 상위에 있는 module_name이 적용되어 resource
group이 저절로 변화 했음을 보여준다.
이제 앞에서처럼 직접 resource group의 변경을 시도해 보자.
테스트 창 :
XRSRC> exec dbms_session.switch_current_consumer_group(-
> 'IDLE_GRP', :oldgrp, FALSE);
PL/SQL procedure successfully completed.
XRSRC> select resource_consumer_group from v$session
2 where audsid = userenv('sessionid');
RESOURCE_CONSUMER_GROUP
-----------------------------------------------
LONG_GRP
위 결과는 explicit의 우선순위가 낮기 때문에 resource consumer group의 변경이
안되고 있음을 보여준다.
그런데 한가지 주의할 점이 있다. 만일 여러분이 위에서처럼 자기자신의 resource
consumer group을 변경하는 것이 아니라 system과 같은 다른 창에서 자신의
resource consumer group을 바꾸는 행위가 발생하면 이 것은 우선순위와 상관없이
반영이 된다는 사실이다. 예를 들어 위 상태에서 system창으로 가서 테스트 창의
resource consumer group을 변경해 본 후 그 결과를 테스트 창에서 확인해 보자.
테스트 창:
XRSRC> select sid, serial# from v$session
JKSPARK@HANAFOS.COM 216
http://www.ggola.com 장 경 상
2 where audsid = userenv('sessionid');
SID SERIAL#
---------- ------------
534 10892
SYSTEM 창:
SYSTEM> exec dbms_resource_manager.switch_consumer_group_for_sess(-
> 534, 10892, 'IDLE_GRP');
PL/SQL procedure successfully completed.
테스트 창 :
XRSRC> select resource_consumer_group from v$session
2 where audsid = userenv('sessionid');
RESOURCE_CONSUMER_GROUP
-----------------------------------------------
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
JKSPARK@HANAFOS.COM 217
http://www.ggola.com 장 경 상
하면서 취소하고자 하는 속성을 명명하고 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”를 선택하면 다음과 같은 화면에서 우선순위도
설정할 수 있다.
JKSPARK@HANAFOS.COM 218
그림 7-66
Resource Mapping
http://www.ggola.com 장 경 상
원하는 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”방식이라
부른다.
JKSPARK@HANAFOS.COM 219
그림 7-67
Resource 우선순위
http://www.ggola.com 장 경 상
CF. 물론, “EMPHASIS”방식으로 single-level plan을 만든다고 문제될 것은 없다.
7.10.5.2. CPU RATIO 할당의 예다음은 새로운 group을 만들 때 oracle10g의 새로운 CPU 할당 방식을 사용해 보자.
SYSTEM> exec dbms_resource_manager.clear_pending_area();
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.create_pending_area();
PL/SQL procedure successfully completed.
SYSTEM> exec
dbms_resource_manager.create_consumer_group('XRTC_CPU_GRP',-
> 'New CPU appliction to complete', 'RUN-TO-COMPLETION');
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.submit_pending_area();
PL/SQL procedure successfully completed.
다음은 새로운 plan을 만들어 ratio 방식의 CPU 설정을 해보자. 다음의 예는 앞서
테스트를 통해 만들어진 group을 새로운 plan에 적용하면서 ratio 방식의 CPU 사용을
설정한 것이다.
SYSTEM> exec dbms_resource_manager.clear_pending_area();
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.create_pending_area();
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.create_plan('XRATIO_PLAN',-
> 'Plan for Ratio Policy', 'RATIO');
JKSPARK@HANAFOS.COM 220
http://www.ggola.com 장 경 상
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.create_plan_directive(-
> 'xratio_plan', 'short_grp', '1st grade', cpu_p1 => 4);
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.create_plan_directive(-
> 'xratio_plan', 'long_grp', '2nd grade', cpu_p1 => 3);
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.create_plan_directive(-
> 'xratio_plan', 'idle_grp', '3rd grade', cpu_p1 => 2);
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.create_plan_directive(-
> 'xratio_plan', 'other_groups', 'other grade', cpu_p1 => 1);
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.submit_pending_area();
PL/SQL procedure successfully completed.
새로 생성한 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를 사용하여 같은
JKSPARK@HANAFOS.COM 221
http://www.ggola.com 장 경 상
작업을 해보자.
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
SYSTEM> exec dbms_resource_manager.create_simple_plan (-
> simple_plan => 'SINGLE_PLANX',-
> consumer_group1 => 'short_grp', group1_cpu => 5,-
> consumer_group2 => 'long_grp', group2_cpu => 3,-
> consumer_group3 => 'idle_grp', group3_cpu => 2);
PL/SQL procedure successfully completed.
위 결과를 보면 보통의 plan directive설정과 달리 pending area를 따로 지정할
필요가 없으며 other_groups도 지정하지 않는다는 것을 알 수 있다. 그렇다면 위
방식은 우리가 앞서 했던 plan의 할당과 동일한 결과를 가져올까! 사실 그렇지 않다.
현재 위 방식은 CPU method가 지정되지 않은 상태이며 지정할 수 있는 parameter도
없다. 아래처럼 먼저 RATIO 방식을 사용하는 plan을 생성하여 이를 지정하는 simple
plan을 해보자.
SYSTEM> exec dbms_resource_manager.create_pending_area ;
JKSPARK@HANAFOS.COM 222
http://www.ggola.com 장 경 상
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.create_plan('single_plan',-
> 'single ratio', 'RATIO');
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_resource_manager.create_simple_plan (-
> simple_plan => 'SINGLE_PLAN',-
> consumer_group1 => 'short_grp', group1_cpu => 5,-
> consumer_group2 => 'long_grp', group2_cpu => 3,-
> consumer_group3 => 'idle_grp', group3_cpu => 2);
PL/SQL procedure successfully completed.
이제 관련 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> col p2 for 999
JKSPARK@HANAFOS.COM 223
http://www.ggola.com 장 경 상
SYSTEM> col p3 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
JKSPARK@HANAFOS.COM 224
http://www.ggola.com 장 경 상
에만 적용이 되는 것이고 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
그리고 여러 정보를 한 눈에 볼 수 있다.
JKSPARK@HANAFOS.COM 225
그림 7-68
Resource Monitor
http://www.ggola.com 장 경 상
JKSPARK@HANAFOS.COM 226
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 227
http://www.ggola.com 장 경 상
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확인이 가능하다.
JKSPARK@HANAFOS.COM 228
http://www.ggola.com 장 경 상
여기서 주요 관심이 있는 tablespace를 직접 click하면 다음과 같은 화면에서 다양한
속성을 정의할 수 있게 된다. 예를 들어 위에서 “AUTOTBS”를 click하면 다음과 같은
화면을 볼 수 있다.
우측 상단의 “Thresholds” tab을 선택하면 바로 다음과 같은 화면에서 앞서 이야기한
usage에 대한 속성을 편집할 수 있게 된다.
JKSPARK@HANAFOS.COM 229
그림 7-69
Tablespace Monitor
그림 7-70
Tablespace Monitor
http://www.ggola.com 장 경 상
의 내용을 보면 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( -
> 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');
2. 다음은 특정 tablespace usage의 warning, critical value를 default인 85, 97로
하겠다는 의미이다.
exec dbms_server_alert.set_threshold( -
> dbms_server_alert.TABLESPACE_PCT_FULL, -
> NULL,NULL, NULL, NULL, 1, 1, NULL, -
JKSPARK@HANAFOS.COM 230
그림 7-71
Tablespace Monitor
http://www.ggola.com 장 경 상
> dbms_server_alert.OBJECT_TYPE_TABLESPACE,'USER_DEFAULT');
3. 다음은 지정한 tablespace에 대하여 usage monitoring을 하지 않겠다는
의미이다.
(앞서 잠깐 언급했던 read-only, offline tablespace를 생각해 보라)
exec dbms_server_alert.set_threshold( -
> dbms_server_alert.TABLESPACE_PCT_FULL, -
> dbms_server_alert.OPERATOR_DO_NOT_CHECK,'0', -
> dbms_server_alert.OPERATOR_DO_NOT_CHECK,'0', 1, 1, NULL, -
> dbms_server_alert.OBJECT_TYPE_TABLESPACE,'USER_DEFAULT');
4. 다음은 database 전체에 걸쳐서 모든 tablespace usage의 monitoring 값을
warning 50, critical 80으로 변경한다는 의미이다.
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, NULL);
5. 다음은 tablespace usage의 monitoring 값을 database 전체 default인
warning 85, critical 97로 원상복구 하겠다는 의미이다.
exec dbms_server_alert.set_threshold( -
> dbms_server_alert.TABLESPACE_PCT_FULL, -
> 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에서의 기능을
순차적으로 표현한 것이다.
JKSPARK@HANAFOS.COM 231
http://www.ggola.com 장 경 상
위 그림은 전형적인 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은 여전히 비어있다.
JKSPARK@HANAFOS.COM 232
그림 7-72
Segment 관리체계
http://www.ggola.com 장 경 상
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이
JKSPARK@HANAFOS.COM 233
http://www.ggola.com 장 경 상
발생하기 때문이 아닌가 생각된다.
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이 이동될 때 매우 짧은 시간이기는 하지만 해당
JKSPARK@HANAFOS.COM 234
http://www.ggola.com 장 경 상
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;
JKSPARK@HANAFOS.COM 235
http://www.ggola.com 장 경 상
5 end;
6 /
PL/SQL procedure successfully completed.
SCOTT> commit;
Commit complete.
SCOTT> var unfbs number
SCOTT> var unfbt number
SCOTT> var fs1bs number
SCOTT> var fs1bt number
SCOTT> var fs2bs number
SCOTT> var fs2bt number
SCOTT> var fs3bs number
SCOTT> var fs3bt number
SCOTT> var fs4bs number
SCOTT> var fs4bt 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);
5 dbms_output.put_line('FS2 BLK = '||:fs2bs||' BTS = '||:fs2bt);
6 dbms_output.put_line('FS3 BLK = '||:fs3bs||' BTS = '||:fs3bt);
7 dbms_output.put_line('FS4 BLK = '||:fs4bs||' BTS = '||:fs4bt);
8 dbms_output.put_line('Full BLK = '||:fbs||' BTS = '||:fbt);
9 end;
10 /
FS1 BLK = 0 BTS = 0
FS2 BLK = 0 BTS = 0
JKSPARK@HANAFOS.COM 236
http://www.ggola.com 장 경 상
FS3 BLK = 0 BTS = 0
FS4 BLK = 48 BTS = 393216
Full BLK = 454 BTS = 3719168
PL/SQL procedure successfully completed.
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
6 delete from x_shrink_obj where sno = i*100;
7 end loop;
8 for i in 200000..250000 loop
9 delete from x_shrink_obj where sno = i*100;
10 end loop;
11 end;
JKSPARK@HANAFOS.COM 237
http://www.ggola.com 장 경 상
12 /
PL/SQL procedure successfully completed.
SCOTT> commit;
Commit complete.
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);
5 dbms_output.put_line('FS2 BLK = '||:fs2bs||' BTS = '||:fs2bt);
6 dbms_output.put_line('FS3 BLK = '||:fs3bs||' BTS = '||:fs3bt);
7 dbms_output.put_line('FS4 BLK = '||:fs4bs||' BTS = '||:fs4bt);
8 dbms_output.put_line('Full BLK = '||:fbs||' BTS = '||:fbt);
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
PL/SQL procedure successfully completed.
SCOTT> select blocks from user_segments
2 where segment_name = 'X_SHRINK_OBJ';
BLOCKS
------------
512
위 결과는 block내의 fragmentation이 발생했음을 보여준다. 이는 delete를 통해
JKSPARK@HANAFOS.COM 238
http://www.ggola.com 장 경 상
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
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);
5 dbms_output.put_line('FS2 BLK = '||:fs2bs||' BTS = '||:fs2bt);
6 dbms_output.put_line('FS3 BLK = '||:fs3bs||' BTS = '||:fs3bt);
7 dbms_output.put_line('FS4 BLK = '||:fs4bs||' BTS = '||:fs4bt);
8 dbms_output.put_line('Full BLK = '||:fbs||' BTS = '||:fbt);
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
PL/SQL procedure successfully completed.
SCOTT> select blocks from user_segments
2 where segment_name = 'X_SHRINK_OBJ';
JKSPARK@HANAFOS.COM 239
http://www.ggola.com 장 경 상
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
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);
5 dbms_output.put_line('FS2 BLK = '||:fs2bs||' BTS = '||:fs2bt);
6 dbms_output.put_line('FS3 BLK = '||:fs3bs||' BTS = '||:fs3bt);
7 dbms_output.put_line('FS4 BLK = '||:fs4bs||' BTS = '||:fs4bt);
8 dbms_output.put_line('Full BLK = '||:fbs||' BTS = '||:fbt);
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
PL/SQL procedure successfully completed.
SCOTT> select blocks from user_segments
2 where segment_name = 'X_SHRINK_OBJ';
JKSPARK@HANAFOS.COM 240
http://www.ggola.com 장 경 상
BLOCKS
------------
384
Free space 공간이 database로 return되어 HWM이 줄어들었음을 segment내
blocks 수의 변화로도 알 수가 있다.
다음은 shrink시 index와 같은 dependent object도 정리해주기 위하여 option을
사용한 예이다. 앞서 만든 index의 blocks 변화를 눈 여겨 보자.
SCOTT> select blocks from user_segments
2 where segment_name = 'IK_XSHRINK_OBJ';
BLOCKS
------------
768
SCOTT> alter table x_shrink_obj shrink space cascade;
Table altered.
SCOTT> select blocks from user_segments
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.
JKSPARK@HANAFOS.COM 241
http://www.ggola.com 장 경 상
7.11.3.5. Using em
이 shrink 역시 em을 통해서 할 수 있다. 먼저 다음과 같이 table 화면으로 이동한다.
“Administration Tables(Schema)”
아래 table 화면에서 schema와 table name을 선택 혹은 입력한 후 “Go” 버튼을
누른다.
JKSPARK@HANAFOS.COM 242
그림 7-73
em 관리화면
http://www.ggola.com 장 경 상
아래 화면의 하 단에 서 원하는 table을 선택한 후 우측 중앙 “Actions”의 item중
“Shrink Segment”를 선택하고 “Go” 버튼을 click한다.
다양한 작업이 가능한 화면이다. 여기서 앞서 배운 options을 선택하고 우측 상단의
“Continue”를 선택한다.
JKSPARK@HANAFOS.COM 243
그림 7-74
Segment Shrink
그림 7-75
Segment Shrink
http://www.ggola.com 장 경 상
아래 화면은 이제 많이 익숙한 화면이다. 어떤 작업을 할 때 최종적으로 즉시 수행할
것인가 아니면 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
로 이루어지게 된다.
JKSPARK@HANAFOS.COM 244
그림 7-76
Segment Shrink
그림 7-77
Segment Shrink
http://www.ggola.com 장 경 상
다음은 PL/SQL을 통해 tablespace level의 분석결과를 확인하는 예이다.
SYSTEM> var task varchar2(100);
SYSTEM> var objno number;
SYSTEM> exec :task := 'SADV_TBS';
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_advisor.create_task('Segment Advisor', :task,-
> 'check shrinking in tablespace');
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_advisor.create_object(:task, 'TABLESPACE',-
> 'USER_DEFAULT', NULL, NULL, NULL, NULL, object_id => :objno);
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_advisor.set_task_parameter(:task,-
> 'MODE', 'COMPREHENSIVE');
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_advisor.execute_task(:task);
PL/SQL procedure successfully completed.
위 분석 결과를 보고 싶다면 다음과 같은 views를 join하여 다음과 같은 SQL
command를 사용해 보라.
SYSTEM> col owner for a10
SYSTEM> col type for a5
SYSTEM> col object_name for a20
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,
JKSPARK@HANAFOS.COM 245
http://www.ggola.com 장 경 상
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
Perform shrink, estimated savings is 1181473 bytes.
Allocated Space:6291456: Used Space:5059389: Reclaimable
Space :1181473:
alter index "SCOTT"."GG_GGNAME_I" shrink space;
SCOTT INDEX GG_GGTI_CODE_I
Perform shrink, estimated savings is 1170560 bytes.
Allocated Space:5242880: Used Space:4032000: Reclaimable
Space :1170560:
alter index "SCOTT"."GG_GGTI_CODE_I" shrink space;
SCOTT INDEX GG_PK_I
Perform shrink, estimated savings is 2742227 bytes.
Allocated Space:8388608: Used Space:5590476: Reclaimable
JKSPARK@HANAFOS.COM 246
http://www.ggola.com 장 경 상
Space :2742227:
alter index "SCOTT"."GG_PK_I" shrink space;
SCOTT INDEX PK_EMP_BTM
Perform shrink, estimated savings is 1816545 bytes.
Allocated Space:97517568: Used Space:94753488: Reclaimable
Space :1816545:
alter index "SCOTT"."PK_EMP_BTM" shrink space;
SCOTT INDEX IK_DEPT_NAME
Perform shrink, estimated savings is 3023351 bytes.
Allocated Space:111149056: Used Space:107055153: Reclaimable
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
JKSPARK@HANAFOS.COM 247
http://www.ggola.com 장 경 상
SCOTT> var vn_resize number
SCOTT> exec :vn_resize := 500
PL/SQL procedure successfully completed.
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.
PL/SQL procedure successfully completed.
위 결과에서 여러분이 “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”를 진행한다. 여기서는
JKSPARK@HANAFOS.COM 248
그림 7-78
Segment Advisor
그림 7-79
Segment Advisor
http://www.ggola.com 장 경 상
tablespace에 대해 알아볼 것이다.
다음 화면에서 우측 중앙의 “Add”를 통해 tablespace list를 확인한다.
다음 화면에서 적절한 tablespace를 선택한 후 “Ok”를 선택한다.
이제 “Next”를 통해 다음 단계로 간다.
JKSPARK@HANAFOS.COM 249
그림 7-80
Segment Advisor
그림 7-81
Segment Advisor
그림 7-82
Segment Advisor
http://www.ggola.com 장 경 상
여기서부터는 익숙한 화면이다. 차례 차례 “Next”를 통해 이동한다.
수행 시간을 정하는 schedule 화면이다.
JKSPARK@HANAFOS.COM 250
그림 7-83
Segment Advisor
그림 7-84
Segment Advisor
http://www.ggola.com 장 경 상
최종 설정이 완료된 화면이다. “Submit”을 통해 작업을 수행할 수 있다.
하단에 생성된 “Segment Advisor”항목을 볼 수 있다.
JKSPARK@HANAFOS.COM 251
그림 7-85
Segment Advisor
그림 7-86
Em의 전체 Advisor 결과 List
http://www.ggola.com 장 경 상
이제 분석 작업이 완료가 되면 해당 task를 선택하여 다음과 같은 결과를 확인할 수
있다. 아래 화면은 각 segment별 분석 및 추정결과를 보여준다. 물론, 원한다면 아래
화면의 우측상단 “Show SQL”을 통해 추천하는 SQL script도 확인할 수 있다.
7.11.4.3. Segment Trend
Oracle10g가 제공하는 또 하나의 유용한 기능은 바로 segment의 trend이다. 현재
필자도 그러하지만 상당수의 site들은 storage 예측을 위해 전체 혹은 중요 tables에
JKSPARK@HANAFOS.COM 252
그림 7-87
Segment Advisor 결과
그림 7-88
Segment Trend 분석
http://www.ggola.com 장 경 상
대하여 변화추이를 기록하여 따로 분석하는 작업을 진행하게 된다. 앞서 shrink에서
보았던 em database control에서 “Administration Tables(Schema)”를 선택한
후 다음과 같이 원하는 table을 선택 혹은 입력한다.
그리고 나서 하단의 list에서 해당 table을 click하면 아래 화면으로 이동한다. 여기서
상단 좌측의 “Segments” tab을 선택한다.
아래 화면에서 해당 segment의 space usage가 graph로 나타나고 날짜를 선택해서
볼 수도 있다.
JKSPARK@HANAFOS.COM 253
그림 7-89
Segment Trend 분석
그림 7-90
Segment Trend 분석
http://www.ggola.com 장 경 상
위의 예는 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
07-SEP-05 04.46.09.825070 PM 227579 1048576 INTERPOLATED
08-SEP-05 04.46.09.825070 PM 227579 1048576 INTERPOLATED
09-SEP-05 04.46.09.825070 PM 227579 1048576 INTERPOLATED
10-SEP-05 04.46.09.825070 PM 227579 1048576 INTERPOLATED
11-SEP-05 04.46.09.825070 PM 227579 1048576 INTERPOLATED
JKSPARK@HANAFOS.COM 254
http://www.ggola.com 장 경 상
12-SEP-05 04.46.09.825070 PM 227579 1048576 INTERPOLATED
13-SEP-05 04.46.09.825070 PM 227579 1048576 INTERPOLATED
14-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”를 선택한다.
JKSPARK@HANAFOS.COM 255
그림 7-91
Segment Size 분석
그림 7-92
Segment Size 분석
그림 7-93
Segment Size 분석
http://www.ggola.com 장 경 상
이제 예측하고 있는 data 건수를 입력한 후 중앙의 “Estimate Tab le Size”를
선택해보라.
이제 중앙에 계산된 결과값을 볼 수 있다. 즉, 위 그림의 “Unavailable”이 계산된
값으로 변경된다. 여러분은 이 결과를 기준으로 수 차례 estimation을 통해 적합한
storage 구성을 하는데 도움을 받을 수 있을 것이다.
JKSPARK@HANAFOS.COM 256
그림 7-94
Segment Size 분석
http://www.ggola.com 장 경 상
물론, 위 기능 역시 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);
PL/SQL procedure successfully completed.
SYSTEM> print :usb_bt :alc_bt
USB_BT
------------
12419072
ALC_BT
------------
12582912
JKSPARK@HANAFOS.COM 257
그림 7-95
Segment Size 분석
http://www.ggola.com 장 경 상
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);
PL/SQL procedure successfully completed.
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
JKSPARK@HANAFOS.COM 258
http://www.ggola.com 장 경 상
위 결과는 만일 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 속성을 변경할 수 있다.
JKSPARK@HANAFOS.COM 259
그림 7-96
Undo 관리화면
http://www.ggola.com 장 경 상
화면 좌측 하단의 “Show Graph”를 선택하면 다음과 같이 undo 생성 비율과 undo
tablespace 사용량과 관련한 부분을 graph로 보여준다. 다음 화면을 보라.
7.11.5.2. Undo Advisor
위 화면에서 “Undo Advisor”를 선택하게 되면 다음과 같은 화면을 볼 수 있다.
이 화면에서 undo 관리에 대한 분석된 결과를 볼 수 있으며 그 결과에 따라 여러분은
JKSPARK@HANAFOS.COM 260
그림 7-97
Undo Tablespace 사용량
그림 7-98
Undo Advisor
http://www.ggola.com 장 경 상
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,
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
--------------- ------------------------
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';
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_advisor.create_task('Undo Advisor', :task, 'Undo
Analysis');
JKSPARK@HANAFOS.COM 261
http://www.ggola.com 장 경 상
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_advisor.create_object(:task, 'UNDO_TBS',-
> NULL, NULL, NULL, 'NULL', :objno);
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_advisor.set_task_parameter(:task,
'TARGET_OBJECTS', :objno);
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_advisor.set_task_parameter(:task, 'START_SNAPSHOT',
1956);
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_advisor.set_task_parameter(:task, 'END_SNAPSHOT',
1964);
PL/SQL procedure successfully completed.
SYSTEM> exec dbms_advisor.execute_task(:task);
PL/SQL procedure successfully completed.
안타깝게도 위에서 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
JKSPARK@HANAFOS.COM 262
http://www.ggola.com 장 경 상
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의 사용을 권장한다.
JKSPARK@HANAFOS.COM 263
http://www.ggola.com 장 경 상
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
JKSPARK@HANAFOS.COM 264
top related