Your SlideShare is downloading. ×
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Oracle History #14
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Oracle History #14

224

Published on

Self Management Database

Self Management Database

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
224
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. http://www.ggola.com 장 경 상 7. 자가관리(self-management) Database System...................................................................6 7.1. 자동진단(automatic diagnostic) 시스템.................................................................7 7.1.1. ADDM (Automatic Database Diagnostic Management)...........................7 7.1.1.1. ADDM 관리 point................................................................................7 7.1.1.2. ADDM 성능 모니터.............................................................................7 7.1.1.3. ADDM의 분석방향..............................................................................9 7.1.2. ADDM Configuration..................................................................................10 7.1.2.1. Initial Parameter.................................................................................10 7.1.2.2. ADDM Report....................................................................................11 7.1.3. ADDM using em...........................................................................................18 7.1.3.1. em Start...............................................................................................18 7.1.3.2. Advisor Central (중앙 권고자)..........................................................21 7.1.3.3. ADDM Report using em...................................................................23 7.1.4. I/O 속성.........................................................................................................24 7.2. SGA Memory 관리 자동화....................................................................................26 7.2.1. 빈번한 Memory 오류 유형...........................................................................26 7.2.2. Automatic Shared Memory Management.................................................26 7.2.2.1. SGA Size..............................................................................................26 7.2.2.2. Initial Parameter.................................................................................27 7.2.3. Memory 자동관리 체계와 Limit.................................................................31 7.2.3.1. Memory 자동관리 Process................................................................31 7.2.3.2. Pool의 자동관리 와 Limit..................................................................32 7.2.3.3. spfile....................................................................................................34 7.2.4. Memory 자동관리 Using em.......................................................................35 7.3. 통계정보 자동관리..................................................................................................37 7.3.1. 변화된 통계수집............................................................................................37 7.3.2. Automatic 통계수집의 구조........................................................................38 7.3.2.1. 기본 개념.............................................................................................38 7.3.2.2. 기본 Components...............................................................................38 7.3.2.3. 통계수집 자동화의 의미....................................................................41 7.3.2.4. 통계수집 Control................................................................................41 7.3.3. 통계정보의 Locking 과 Overriding............................................................42 7.3.3.1. Lock Statistics.....................................................................................42 7.3.3.2. Override Statistics..............................................................................44 7.3.4. 통계정보 History..........................................................................................45 7.3.4.1. History 구조........................................................................................45 JKSPARK@HANAFOS.COM 1
  • 2. http://www.ggola.com 장 경 상 7.3.4.2. History 활용하기................................................................................45 7.3.5. 통계수집 자동화 Limit.................................................................................48 7.4. Undo & Checkpoint 자동 Tuning........................................................................50 7.4.1. Undo Management.......................................................................................50 7.4.1.1. Undo Retention 자동 관리................................................................50 7.4.1.2. Rollback Time 추측............................................................................50 7.4.2. Checkpoint....................................................................................................51 7.4.3. Fast Ramp-Up...............................................................................................53 7.5. AWR (Automatic Workload Repository)............................................................55 7.5.1. AWR 개요......................................................................................................55 7.5.1.1. AWR의 구조.......................................................................................55 7.5.1.2. 통계 Access.........................................................................................55 7.5.1.3. 기본통계(Base Statistics)와 측정(Metrics).......................................63 7.5.1.4. Repository와 Snapshot......................................................................65 7.5.2. AWR Control.................................................................................................66 7.5.2.1. Snapshot Schedule 조정 (Manually)................................................66 7.5.2.2. Snapshot Schedule 조정 (Using em)................................................68 7.5.2.3. Snapshot Baseline (Manually)..........................................................70 7.5.2.4. Snapshot Baseline (Using em)..........................................................72 7.5.2.5. Other Snapshot Control....................................................................74 7.5.3. AWR Report & em........................................................................................75 7.5.3.1. 직접 report 산출하기..........................................................................75 7.5.3.2. Report Script 사용하기......................................................................78 7.5.3.3. Using em.............................................................................................82 7.5.4. Active Session History(ASH)......................................................................84 7.5.4.1. ASH 개요 및 속성...............................................................................84 7.5.4.2. ASH Access.........................................................................................84 7.5.4.3. ASH Example.....................................................................................88 7.5.5. Advisor (문제 해결사) .................................................................................91 7.5.5.1. Advisor의 구조...................................................................................91 7.5.5.2. 기본 Advisor.......................................................................................92 7.5.5.3. Advisor 사용하기...............................................................................92 7.5.5.4. Using em.............................................................................................94 7.6. Alert & Notification (경보와 알림기능)...............................................................96 7.6.1. Alert 개요.......................................................................................................96 7.6.1.1. Server Generated Alert......................................................................96 JKSPARK@HANAFOS.COM 2
  • 3. http://www.ggola.com 장 경 상 7.6.1.2. Server Alert의 장점............................................................................96 7.6.2. Alert 구조.......................................................................................................97 7.6.2.1. Alert 생성 시점...................................................................................97 7.6.2.2. Server Alert & em Alert.....................................................................97 7.6.2.3. Alert Model.........................................................................................98 7.6.3. Alert Types....................................................................................................99 7.6.3.1. Stateful Alert.......................................................................................99 7.6.3.2. Stateless Alert...................................................................................100 7.6.3.3. Out-of-Box Server Alert...................................................................100 7.6.4. Alert Control...............................................................................................101 7.6.4.1. Threshold 조절 (Manually).............................................................101 7.6.4.2. Alert 확인 및 Threshold 조절 (Using em).....................................109 7.6.4.3. Alert Message 확인 (Manually)......................................................113 7.7. Cost & Optimizer.................................................................................................118 7.7.1. Query Optimization...................................................................................118 7.7.2. 확장된 Statistics..........................................................................................120 7.7.2.1. Dictionary를 위한 통계....................................................................120 7.7.2.2. 통계 수집의 New Values.................................................................123 7.7.3. Optimizer Mode의 변화.............................................................................124 7.8. Support SQL Tuning............................................................................................127 7.8.1. Optimizer를 통한 SQL Tuning 자동환.....................................................127 7.8.1.1. Tuning을 위한 Enhanced Optimizer.............................................127 7.8.1.2. DBA SQL Tuning과 Advisor..........................................................127 7.8.2. SQL Tuning Advisor..................................................................................128 7.8.2.1. 통계분석 (Statistics Analysis).........................................................128 7.8.2.2. SQL Profile........................................................................................129 7.8.2.3. SQL Access Advisor : 접근경로 분석(Access Path Analysis)......130 7.8.2.4. SQL 구조 분석(Structure Analysis)................................................131 7.8.3. Tuning SQL (Using em).............................................................................132 7.8.3.1. SQL Tuning Set.................................................................................132 7.8.3.2. Running SQL Tuning Advisor.......................................................133 7.8.3.3. STS 생성.............................................................................................135 7.8.3.4. Tuning Result...................................................................................136 7.8.4. SQL Tuning Package (Manually)..............................................................138 7.8.4.1. Using Snapshot ID...........................................................................139 7.8.4.2. Using STS..........................................................................................141 JKSPARK@HANAFOS.COM 3
  • 4. http://www.ggola.com 장 경 상 7.8.5. SQL Profile 적용 (Manually).....................................................................144 7.8.5.1. Accept Profile...................................................................................144 7.8.5.2. Profile Category...............................................................................145 7.8.5.3. Profile 수정........................................................................................145 7.8.6. STS Control (Manually).............................................................................146 7.8.6.1. STS의 생성과 SQL Load..................................................................146 7.8.6.2. STS와 SQL의 조정............................................................................148 7.8.7. SQL Access Advisor...................................................................................149 7.8.7.1. 대상 SQL...........................................................................................150 7.8.7.2. Access Path 분석 Option과 권고사항............................................151 7.8.7.3. Access 분석 (Using em)...................................................................152 7.8.7.4. Access 분석 (Manually)...................................................................164 7.9. Instance Monitoring.............................................................................................175 7.9.1. Monitoring 방안..........................................................................................175 7.9.2. Database Control........................................................................................175 7.9.3. em의 성능 진단 및 관리.............................................................................175 7.10. Resource Manger...............................................................................................180 7.10.1. Oracle10g New Features..........................................................................180 7.10.2. Original Consumer Group으로 돌아가기..............................................180 7.10.2.1. Switch Time(Top Call)...................................................................181 7.10.2.2. Using em.........................................................................................187 7.10.3. Idle Time의 설정.......................................................................................188 7.10.3.1. Session Idle Time............................................................................188 7.10.3.2. Session Blocking Time...................................................................190 7.10.3.3. Using em.........................................................................................193 7.10.4. 유연한 Resource Group의 할당...............................................................193 7.10.4.1. Resource Group Mapping.............................................................195 7.10.4.2. Resource Group Priority...............................................................197 7.10.4.3. Using em.........................................................................................206 7.10.5. New Resource 할당 방법.........................................................................207 7.10.5.1. CPU 할당 방식................................................................................207 7.10.5.2. CPU RATIO 할당의 예...................................................................208 7.10.6. Monitoring Resource Manager...............................................................213 7.11. Space 관리 자동화..............................................................................................215 7.11.1. 개요.............................................................................................................215 7.11.2. Tablespace.................................................................................................215 JKSPARK@HANAFOS.COM 4
  • 5. http://www.ggola.com 장 경 상 7.11.2.1. Tablespace Usage...........................................................................215 7.11.2.2. Threshold의 설정과 의미..............................................................217 7.11.3. Segment와 Block 관리방식......................................................................218 7.11.3.1. Segments내부의 관리방식 변화....................................................218 7.11.3.2. Shrink Segment 속성......................................................................220 7.11.3.3. Shrink Command, 속성, Oracle9i Coalesce.................................221 7.11.3.4. Shrink Example..............................................................................222 7.11.3.5. Using em.........................................................................................228 7.11.4. Segment Advisor......................................................................................231 7.11.4.1. 개요 및 Segment 분석....................................................................231 7.11.4.2. Segment Advisor (Using em)........................................................235 7.11.4.3. Segment Trend...............................................................................239 7.11.4.4. Segment Size Estimation ..............................................................241 7.11.5. Undo Management...................................................................................245 7.11.5.1. Undo 관리 화면..............................................................................245 7.11.5.2. Undo Advisor.................................................................................247 JKSPARK@HANAFOS.COM 5
  • 6. 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 6 표 7-1 DBA 작 업유형
  • 7. 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 7
  • 8. 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 resource에 대 한 성능 분석이 더욱 포괄적으로 더 자세하게 분석이 가능해 지고 RMAN, AQ(advanced JKSPARK@HANAFOS.COM 8
  • 9. http://www.ggola.com 장 경 상 queuing)와 같은 oracle server components의 분석도 지원된다. 그리고 특정 시점간의 성 능차이에 대한 분석 report인 “Compare Periods Report”가 제공된다. 7.1.1.3. ADDM의 분석방향 이제 ADDM은 어떻게 분석을 수행하고 처리하는 절차를 담고 있는지를 알아 보도록 하 자. 이를 ADDM methodology(방법론)이라고 하는데 대체적으로 resource bottleneck 즉, 리소스에 대한 wait 현상을 top-down 방식으로 접근하여 처리한다. Oracle10g는 새로운 time 통계정보를 통해 oracle이 소비한 시간이 어디에서 이루어졌는 가를 판단할 수 있도록 해줌으로써 매우 유용한 정보를 분석할 수 있게 된다. 이러한 정보 들은 tuning이 가능한 모든 요소들을 tree형태로 관리함으로써 결국은 top-down approach를 가능하도록 해주게 되는데 이를 “new wait model statistics” 즉, oracle의 새 로운 wait 통계모델이라 할 수 있다. 바로 이것이 ADDM의 핵심 기반이 된다. 이 모델은 각종 현상들을 중심에 두고 이들 각각의 문제들을 time base로 진단을 하도록 tree 구조를 제공하게 된다. 예를 들어 시스템 wait “A” 항목을 하나의 현상이라 하면 해 당 wait이 발생했을 때 그것의 문제점을 세부적으로 분석해 들어가 최종적인 문제를 찾 아내는 것이다. 만일, 그 wait “A”가 memory에서 왔다면 memory중 문제가 된 sub tree 를 찾게 되고 해당 sub tree 중 buffer cache가 문제라면 그 buffer cache의 어떤 문제인지 를 찾게 되는 top-down형식의 진단이 되는 것이다. CF. ADDM 분석은 길어도 3초를 넘지 않기 때문에 운영 database에 별다른 부담을 주지 는 않는다. 다음은 oracle10g가 이야기 하는 ADDM의 주요 성능 모니터 요소로서 사용되는 용어들 은 oracle이 제공하는 그대로다. 성능관련 용어임으로 말 그대로 익숙해 지도록 하자. 1. excessive logon/logoff 2. memory undersizing 3. hot blocks and objects w/SQL 4. RAC service issues 5. locks and ITL contention 6. checkpointing causes 7. PL/SQL, Java time 8. Top SQL 9. I/O issues 10. parsing JKSPARK@HANAFOS.COM 9
  • 10. http://www.ggola.com 장 경 상 11. configuration issues 12. application usage 7.1.2. ADDM Configuration 7.1.2.1. Initial Parameter ADDM을 사용하기 위해서는 통계 level parameter인 “statistics_level”의 값을 설정해야 한다. 이 parameter는 dynamic parameter로 “alter system, alter session”의 command로 수정할 수 있다. 이 parameter에 줄 수 있는 값은 “typical”, “all”, “basic”이 있는데 ADDM을 위해선 반드시 “typical”이나 “all”을 설정해야 한다. 기본적으로 설정되는 값 은 typical로서 대부분의 중요한 통계정보를 ADDM을 위해 수집하게 되는데 대부분의 시스템에서는 이 default 값으로 충분하다. 만일 이 값을 all로 설정하게 되면 typical의 정 보와 함께 time base의 OS정보와 execution plan 정보를 추가적으로 취합한다. 이런 정보가 필요 없다면 “basic”을 설정하면 되는데 이 경우엔 다음과 같은 자가진단 database에 필요한 정보들을 취합하지 않는다. 1. Automatic Workload Repository (AWR) Snapshots 2. Automatic Database Diagnostic Monitor (ADDM) 3. All server-generated alerts 4. Automatic SGA Memory Management 5. Automatic optimizer statistics collection 6. Object level statistics 7. End to End Application Tracing (V$CLIENT_STATS) 8. Database time distribution statistics (v$sess_time_model and v$sys_time_model) 9. Service level statistics 10. Buffer cache advisory 11. MTTR advisory 12. Shared pool sizing advisory 13. Segment level statistics 14. PGA Target advisory 15. Timed statistics 16. Monitoring of statistics CF. oracle10g가 강력하게 추천하는 것은 ADDM을 enable하는 것이다. 즉, 이 parameter 의 값을 “basic”으로 설정하여 중요한 통계정보를 누락시키지 않을 것을 권고하고 있다. JKSPARK@HANAFOS.COM 10
  • 11. http://www.ggola.com 장 경 상 7.1.2.2. ADDM Report ADDM 결과를 확인하기 위한 report는 향후에 설명할 em을 통하는 방법도 있지만 SQL 이나 report script를 활용할 수도 있다. 1. SQL을 통해 report 만들기 이 방법은 두 가지 의미를 가진다. ADDM으로 분석된 결과를 확인하는 경우나 dbms_advisor의 sub-stored procedure call을 통해 직접 분석을 수행한 후 그 결과를 확 인하는 방식을 말한다. 먼저 가장 최근의 ADDM 분석결과를 확인하는 방법을 해보자. 먼저, task 이름을 확인하 고 이를 이용하여 report를 산출한다. 단, report를 산출하는 function의 return type은 CLOB임으로 너무 큰 값을 여기서 다 보여줄 수가 없다. 따라서 여기서는 전체 결과 report 중에서 처음의 약간만을 보도록 하겠다. (여러분은 spool을 통해 file로 받는 것이 좋은 방법이 되겠다) SYS> select task_name from dba_advisor_tasks where task_id = 2 (select max(ts.task_id) from dba_advisor_tasks ts, dba_advisor_log tl 3 where ts.task_id = tl.task_id and ts.advisor_name = 'ADDM' 4 and tl.status = 'COMPLETED'); TASK_NAME ------------------------------------ ADDM:3941507194_1_1294 SYS> set long 1000000 pagesize 0 longchunksize 1000 SYS> select dbms_advisor.get_task_report('ADDM:3941507194_1_1294') 2 from dual; DETAILED ADDM REPORT FOR TASK 'ADDM:3941507194_1_1294' WITH ID 1299 ------------------------------------------------------------------------------------------------------ Analysis Period: 17-AUG-2005 from 09:00:31 to 10:00:10 Database ID/Instance: 3941507194/1 Database/Instance Names: NEWSVC/NEWSVC Host Name: LIRACLE Database Version: 10.1.0.4.0 Snapshot Range: from 1293 to 1294 JKSPARK@HANAFOS.COM 11
  • 12. http://www.ggola.com 장 경 상 Database Time: 1644 seconds Average Database Load: .5 active sessions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ FINDING 1: 49% impact (804 seconds) --------------------------------------------------- SQL statements consuming significant database time were found. RECOMMENDATION 1: SQL Tuning, 30% benefit (494 seconds) ACTION: Run SQL Tuning Advisor on the SQL statement with SQL_ID "6pb9k95mbvzfw". RELEVANT OBJECT: SQL statement with SQL_ID 6pb9k95mbvzfw and PLAN_HASH 1 INSERT INTO MGMT_METRICS_RAW(COLLECTION_TIMESTAMP, KEY_VALUE, METRIC_GUID, STRING_VALUE, TARGET_GUID, VALUE) VALUES ( :1, NVL(:2, :"SYS_B_0"), :3, :4, :5, :6) RECOMMENDATION 2: SQL Tuning, 13% benefit (211 seconds) ACTION: Run SQL Tuning Advisor on the SQL statement with SQL_ID "91h2x42zqagcm". RELEVANT OBJECT: SQL statement with SQL_ID 91h2x42zqagcm and PLAN_HASH 2315018254 UPDATE MGMT_CURRENT_METRICS SET COLLECTION_TIMESTAMP = :B3 , VALUE = :B2 , STRING_VALUE = :B1 WHERE TARGET_GUID = :B6 AND METRIC_GUID = :B5 AND KEY_VALUE = :B4 AND COLLECTION_TIMESTAMP < :B3 ……. ……. SYS> 위의 결과는 SQL Tuning이 시급한 문제이며 해당 SQL의 ID를 알려주고 있다. 즉, 위와 같은 report는 최근의 결과를 확인하는 방법이 되겠다. 만일, 여러분이 이 package를 직접 사용하여 특정 시점간의 ADDM 분석을 직접 수행하 JKSPARK@HANAFOS.COM 12
  • 13. http://www.ggola.com 장 경 상 고 report를 추출하고 싶다면 다음과 같이 package를 사용하면 되겠다. 먼저 check할 시 간대를 인지한 후 해당 시간대의 snapshot id 범위를 확인하고 이를 이용하면 된다. 다음 은 최근의 시간대를 이용한다는 가정하에 작업을 진행한 것이다. SYS> set pagesize 100 SYS> col snap_start for a20 SYS> select * from ( select snap_id, 2 to_char(BEGIN_INTERVAL_TIME, 'YYYYMMDD HH24:MI:SS') "snap_start" 3 from dba_hist_snapshot 4 order by 2 desc) where rownum < 10; SNAP_ID snap_start ------------- ------------------------ 1297 20050817 12:01:01 1296 20050817 11:00:22 1295 20050817 10:00:10 1294 20050817 09:00:30 1293 20050817 08:00:51 1292 20050817 07:00:09 1291 20050817 06:00:30 1290 20050817 05:00:51 1289 20050817 04:00:18 9 rows selected. SYS> select dbid from v$database; DBID --------------- 3941507194 SYS> select instance_number from v$instance; INSTANCE_NUMBER ------------------------------- 1 JKSPARK@HANAFOS.COM 13
  • 14. http://www.ggola.com 장 경 상 위의 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', 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) JKSPARK@HANAFOS.COM 14
  • 15. http://www.ggola.com 장 경 상 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. ………….. ………….. ………….. 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 JKSPARK@HANAFOS.COM 15
  • 16. http://www.ggola.com 장 경 상 Current Instance ~~~~~~~~~~~~~~~~ DB Id DB Name Inst Num Instance ----------------- -------------- ------------ ------------ 3941507194 NEWSVC 1 NEWSVC ..... ..... Listing the last 3 days of Completed Snapshots Snap Instance DB Name Snap Id Snap Started Level -------------- ------------- ---------- ----------------------- -------- NEWSVC NEWSVC 1212 14 Aug 2005 00:00 1 1213 14 Aug 2005 01:00 1 1214 14 Aug 2005 02:00 1 1215 14 Aug 2005 03:00 1 1216 14 Aug 2005 04:01 1 1217 14 Aug 2005 05:00 1 ….. ….. Specify the Begin and End Snapshot Ids ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Enter value for begin_snap: 1268 Begin Snapshot Id specified: 1268 Enter value for end_snap: 1272 Specify the Report Name JKSPARK@HANAFOS.COM 16
  • 17. http://www.ggola.com 장 경 상 ~~~~~~~~~~~~~~~~~~~~~~~ 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 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 ------------------------------------------- JKSPARK@HANAFOS.COM 17
  • 18. http://www.ggola.com 장 경 상 There was no significant database activity to run the ADDM. The analysis of I/O performance is based on the default assumption that the average read time for one database block is 10000 micro-seconds. An explanation of the terminology used in this report is available when you run the report with the 'ALL' level of detail. SYS> 3. em을 이용하기 위 두 결과보다 em을 사용하면 훨씬 유연하고 편하게 ADDM 분석을 수행하고 확인할 수 있다. 7.1.3. ADDM using em 7.1.3.1. em Start 먼저 em을 활용하기 위해 dbconsole을 start한다. [NEWSVC]LIRACLE:/app/oracle/temp> emctl start dbconsole TZ set to ROK Oracle Enterprise Manager 10g Database Control Release 10.1.0.4 Copyright (c) 1996, 2004 Oracle Corporation. All rights reserved. http://LIRACLE:5501/em/console/aboutApplication Starting Oracle Enterprise Manager 10g Database Control ................. started. ------------------------------------------------------------------------------------ Logs are generated in directory /app/oracle/product/10.1.0/LIRACLE_NEWSVC/sysman/log [NEWSVC]LIRACLE:/app/oracle/temp> URL 확인 후 다음과 같이 접속을 해보자. 1. 다음과 같이 접속을 시도하면 JKSPARK@HANAFOS.COM 18
  • 19. http://www.ggola.com 장 경 상 2. 다음과 같은 초기 화면에서 현재 database의 전반적인 상태를 보여주는 database control화면(기본화면)이 나타나게 된다. (물론, 이 화면 전에 license관련 동의를 묻는 화 면이 나오면 동의를 누르고 넘어가면 된다) 화면은 크게 진단에 내역과 경고성 메시지를 나타내는 부분이 상중하로 나뉘어 지며 아래 화면 우측 상단에서처럼 자동으로 refresh를 하거나 사용자가 원할 때 수동으로 refresh를 하도록 선택할 수도 있다. 상단화면 : JKSPARK@HANAFOS.COM 19 그림 7-1 em login 창
  • 20. http://www.ggola.com 장 경 상 중단화면 : 하단화면 : JKSPARK@HANAFOS.COM 20 그림 7-2 em 초기 화면 그림 7-3 em 초기 화면
  • 21. http://www.ggola.com 장 경 상 7.1.3.2. Advisor Central (중앙 권고자) 위 하단화면에서 ADDM 분석을 해보기 위해선 Advisor Central(중앙 권고자)로 이동을 해야 한다. 이를 click한다. CF. 위 화면에서 하단을 보면 현재 권고사항이 있는 작업내역이 보인다. 현재는 ADDM 부문에서 분석된 자료가 있다는 뜻이다. 이것을 click해서 곧 바로 oracle이 제안하는 문 제를 파악하고 그 해결책에 접근할 수도 있다. 이제 좌측 상단의 ADDM을 선택하여 분석화면으로 이동한다. JKSPARK@HANAFOS.COM 21 그림 7-4 em 초기 화면 그림 7-5 em 중앙 권고자
  • 22. http://www.ggola.com 장 경 상 다음은 위 화면에서 분석을 시작할 시간과 마지막 시간을 설정하는 과정이다. 먼저 시작 시간 radio button을 선택한 후 화면 하단 그래프 밑에서 원하는 시간대를 click하면 자동 으로 선택이 된다. 같은 방법으로 종료시간을 설정하면 다음과 같이 선택이 완료된다. 현재는 그래프 우측 에서 약간의 작업이 있었던 것으로 추측되는 시간대를 선택했다. 확인을 눌러보자. JKSPARK@HANAFOS.COM 22 그림 7-6 ADDM 설정화면 그림 7-7 ADDM 설정화면 그림 7-8 ADDM 설정화면
  • 23. http://www.ggola.com 장 경 상 최종적으로 아래와 같은 결과를 확인할 수 있다. 좌측에는 시스템에 준 영향순서대로 우측에는 그 내용과 권고사항이 나타난다. 이제 여 러분은 tuning하고자 하는 대상을 click하여 하나씩 문제를 해결할 수 있게 된다. 7.1.3.3. ADDM Report using em 앞서 언급한 3번째 ADDM report는 em을 이용하는 것이다. 위 화면에서 “보고서 보기” 를 선택하면 아래와 같은 보고서를 볼 수 있으며 이를 버튼을 통해 file로 저장할 수도 있 다. JKSPARK@HANAFOS.COM 23 그림 7-9 ADDM 결과 그림 7-10 ADDM Report
  • 24. http://www.ggola.com 장 경 상 7.1.4. I/O 속성 ADDM으로 관리되는 여러 진단요소들 중에서 I/O와 관련하여 고려할 부분이 있다. 보 통 자가진단 database를 구성할 때 oracle10g가 제공하는 기본 값들을 가지고 자동으로 분석이 진행되지만 I/O의 경우 사용자의 필요에 의해 기준 값을 변경할 필요가 있을 수 있다. 그것은 I/O의 기준 값이 현재 database를 구성하는 system의 hard disk system특 성에 의존적인 측면이 있기 때문에 광범위하게 적용되는 기준 값으로는 충분치 않은 경 우가 존재할 수 있기 때문이다002E 이 값은 oracle10g의 새로운 view인 “dba_advisor_def_parameters”를 통해서 확인할 수 있고 새로운 package “dbms_advisor”의 “set_default_task_parameter” procedure를 통 해 수정할 수 있다. 보통 이 값은 ADDM의 “DBIO_EXPECTED”로 표현되고 단위는 microseconds이며 이 값의 default는 10000 microseconds (10 milliseconds)로 설정이 되어있다. Parameter “DBIO_EXPECTED”는 I/O subsystem으로부터 기대하는 성능의 지표를 의미하는데 single database block을 read하는데 걸리는 평균 기대시간을 의미한다. 대부분의 시스템 에서는 default로 제공되는 값인 “10000” microseconds가 일반적으로 적용될 수 있지만 만일 여러분이 사용하는 disk I/O system이 좀 특수하여 이 값을 수정할 필요가 있다면 즉, 기대하는 block read 시간이 따로 있다면 다음과 같이 관련 package를 call해서 이를 변경해야만 적절한 ADDM결과를 얻을 수 있을 것이다. 예를 들어 이 값을 9000으로 해야 한다면 다음과 같이 변경할 수 있다. (by sys) SQL> exec dbms_advisor.set_default_task_parameter(‘ADDM’, ‘DBIO_EXPECTED’, 9000); JKSPARK@HANAFOS.COM 24
  • 25. 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 25
  • 26. 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, 설정하면 enable JKSPARK@HANAFOS.COM 26
  • 27. http://www.ggola.com 장 경 상 이 되겠다. 각자 현재의 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 27 표 7-2 자동유지 SGA 요소
  • 28. 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 28
  • 29. 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 29
  • 30. 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 large pool 4 JKSPARK@HANAFOS.COM 30
  • 31. http://www.ggola.com 장 경 상 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 oracle 18328 1 0 15:01 ? 00:00:00 ora_mmnl_NEWSVC JKSPARK@HANAFOS.COM 31
  • 32. http://www.ggola.com 장 경 상 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로 설정된다. CF. 물론, 자동 tuning의 대상이 아닌 memory의 값이 변경되면 sga_target의 총 size에도 당연히 영향을 주게 된다. 즉, non-standard block cache가 50MB 더 늘어나면 위의 예에 서 sga_target은 400 – 50 = 350MB로 더 줄어들게 된다. JKSPARK@HANAFOS.COM 32 표 7-3 자동관리 Memory 요소와 Paramete r 종류
  • 33. http://www.ggola.com 장 경 상 자동관리의 대상이 되는 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; System altered. SYS> select current_size from v$buffer_pool; JKSPARK@HANAFOS.COM 33
  • 34. http://www.ggola.com 장 경 상 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에 영향을 미치게 된다. 7.2.3.3. spfile 만일 여러분이 parameter file로 spfile을 사용하고 있다면 위와 같이 자동관리가 된 memory parameters의 값이 항시 유지될 수 있음으로 database의 shutdown과 상관없이 항상 적절한 값을 취할 수 있는 장점이 있다. 그러나 spfile이 사용되지 않으면 database가 JKSPARK@HANAFOS.COM 34
  • 35. http://www.ggola.com 장 경 상 restart될 때마다 database는 sga_target에 맞게 적절한 값을 optimizing하는 작업을 계속 할 것이다. 7.2.4. Memory 자동관리 Using em 위 작업을 em에서 하기 위해서는 초기 database화면 하단의 “중앙 권고자  메모리 권 고자” 를 선택하여 아래와 같은 화면에서 현재 SGA상태를 확인하고 원하는 값으로 조정 하면 된다. CF. PGA 관리화면의 예 JKSPARK@HANAFOS.COM 35 그림 7-11 em 메모 리 권고자 (SGA) 그림 7-12 em 메모 리 권고자 (PGA)
  • 36. 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 36
  • 37. 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 37 표 7-4 통계수집 방식의 변 화
  • 38. 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 38
  • 39. 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 -------------------------------- ---------------------------------------------------------- STORED_PROCEDURE dbms_stats.gather_database_stats_job_proc JKSPARK@HANAFOS.COM 39
  • 40. http://www.ggola.com 장 경 상 앞서 언급한 procedure가 “STORED_PROCEDURE”의 형태로 등록되어 있음이 확인된 다. 다음으로 이 job이 속한 job class를 통해 이 job이 사용하는 resource consumer group을 확인해 보자. SYSTEM> select resource_consumer_group 2 from dba_scheduler_job_classes 3 where job_class_name = 'AUTO_TASKS_JOB_CLASS'; RESOURCE_CONSUMER_GROUP ------------------------------------------------- AUTO_TASK_CONSUMER_GROUP 위 결과로 이 job이 resource consumer group으로 auto_task_consumer_group을 할당 받았음을 알 수 있다. 그러나 이 group은 선언만 되어있지 resource를 가지고 있지 않다. 언제 사용하는지는 후에 언급한다. 다음으로 스케쥴을 확인해보자. 현재 확인한 schedule은 window group임으로 window group과 그에 속한 window의 속성을 확인해야 한다. SYSTEM> col window_name for a18 SYSTEM> col repeat_interval for a70 SYSTEM> select window_name, resource_plan, schedule_name 2 from dba_scheduler_windows where window_name in 3 (select window_name from dba_scheduler_wingroup_members 4 where window_group_name = 'MAINTENANCE_WINDOW_GROUP'); WINDOW_NAME RESOURCE_PLAN SCHEDULE_NAME -------------------------------------- ------------------------- ---------------------------- WEEKNIGHT_WINDOW WEEKEND_WINDOW 현재 이 window group은 두 개의 window를 가지고 있으며 모두 resource plan과 schedule이 없다. 따라서 schedule은 직접 지정을 했다는 말이다. 다음 SQL을 보자. SYSTEM> col duration for a15 SYSTEM> select repeat_interval, duration JKSPARK@HANAFOS.COM 40
  • 41. http://www.ggola.com 장 경 상 2 from dba_scheduler_windows where window_name = 'WEEKNIGHT_WINDOW'; REPEAT_INTERVAL DURATION - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - freq=daily;byday=MON,TUE,WED,THU,FRI;byhour=22;byminute=0; bysecond=0 000 08:00:00 SYSTEM> select repeat_interval, duration 2 from dba_scheduler_windows where window_name = 'WEEKEND_WINDOW'; REPEAT_INTERVAL DURATION - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - freq=daily;byday=SAT;byhour=0;byminute=0;bysecond=0 +002 00:00:00 위 결과를 보면 평일과 주말에 적용되는 두 개의 window가 서로 다른 속성을 가지고 있 음을 알 수 있다. 평일 window는 매일(월 ~ 금) 오후 10시에 open되어 8시간 즉, 22시에 서 06시까지 유지되고, 주말 window는 토요일 자정에 open되어 2일간 즉, 48시간 동안 유지되도록 설정이 되어있다. 7.3.2.3. 통계수집 자동화의 의미 앞서 살펴본 SQL의 결과를 토대로 oracle10g가 이야기 하는 통계수집의 자동화 정책은 역시 oracle10g의 new features인 job을 통해서 이루어진다는 것을 확인할 수 있었다. 이 를 종합해서 판단하면 다음과 같이 정리할 수 있다. Oracle10g는 database를 생성함과 동시에 resource consumer group “auto_tasks_consumer_group”에 속한 job “gather_stats_job”을 생성 및 등록을 하게 된 다. 이 job은 window group “maintenance_window_group”에 의해 scheduling되는데 이 group은 평일용과 주말용 두 가지로 나누어져 있다. 평일용은 월요일부터 금요일까지 매일 저녁 10시부터 새벽 6시까지, 주말용은 매주 토요일 자정부터 48시간 동안 open 되 어 program “gather_stats_prog”에 등록된 procedure “dbms_stats.gather_database_stats_job_proc”를 call함으로써 통계정보를 자동으로 수 집할 것이다. 7.3.2.4. 통계수집 Control 지금까지 살펴본 내용으로 볼 때 DBA가 oracle의 통계수집 자동화에 간여할 수 있는 부 분은 두 가지이다. 1. 현재 관리하는 database의 실제 운영작업 시간대와 oracle10g가 제공하는 통계작업을 JKSPARK@HANAFOS.COM 41
  • 42. http://www.ggola.com 장 경 상 위한 default schedule이 맞지 않는다면 앞서 살펴본 window를 조정할 수 있다. 생각해 보라. 현재 운영 database가 주말과 평일 밤에 주로 사용되는 data분석용 system이라면 오히려 default로 제공되는 schedule은 실제 현실과 동떨어진 최악의 상황이 될 수도 있 다. 이런 경우는 당연히 이 schedule을 고쳐야 할 것이다. 2. 위에서 살펴본바 resource consumer group은 현재 아무 plan도 할당이 되어있지 않고 plan을 할당 받는 window 또한 아무 plan도 가지고 있지 않다. 따라서 원활한 통계작업 을 위해 여러분이 설정 가능한 resource plan이 있다면 이를 window에 적용함으로써 보 다 적절한 통계수집을 가능하게 할 수 있다. 이런 속성들을 수정하기 “dbms_scheduler.set_attribute”을 사용할 수 있지만 보다 쉽게 이를 적용하기 위해 다음과 같이 em을 활용할 수도 있다. 초기화면에서 하단의 “관리” tab을 click한 후 우측 하단의 “스케줄러” 부분의 “창”을 선택하면 다음화면을 볼 수 있다. 위 화면에서 원하는 window를 선택한 후 “편집” 버튼을 통해 수정을 할 수 있다. 7.3.3. 통계정보의 Locking 과 Overriding 7.3.3.1. Lock Statistics 간단한 시나리오를 생각해보자. 어떤 특정 분석시스템을 지원하는 database가 있다. 그런 이 database는 특정 몇 개의 table을 staging영역처럼 사용하며 대량의 data를 insert하고 delete하는 용도로서 일시적으로만 사용하는(항상 full table scan이 필요한) tables이다. 그런데 oracle10g의 통계수집 자동화는 모든 table이 대상이 될 것임으로 이 대용량 table 에 대해서도 통계작업을 수행할 것이다. 하지만 사실 이런 류의 table은 굳이 통계정보가 필요치 않으며 거기에 system이 resource를 낭비하는 것을 그냥 두고 보기에는 너무 아쉬울 것이다. 지금 설명하는 통계 정보의 locking은 특정 table에 대한 통계정보를 수행하지 않도록 해줄 수 있다. JKSPARK@HANAFOS.COM 42 그림 7-13 em 스케 쥴러
  • 43. http://www.ggola.com 장 경 상 이런 통계정보 수집을 막기 위해 사용하는 것은 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'); 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'); JKSPARK@HANAFOS.COM 43
  • 44. http://www.ggola.com 장 경 상 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 ------------ ----------------------- --------- SCOTT DEPT SCOTT EMP 7.3.3.2. Override Statistics 통계정보를 locking한 경우 dbms_stats package를 통해 통계자료에 대한 작업을 하는 경 JKSPARK@HANAFOS.COM 44
  • 45. http://www.ggola.com 장 경 상 우 몇 가지 유의할 점이 있다. 1. dbms_stats.export_*_stats procedure를 사용하는 경우 table의 locking정보 즉, 대상 objects가 locked인지 아니면 unlocked인지 그 상태는 export되지 않는다. 2. 통계정보가 locking이 되어 있는 objects에 대하여 dbms_stats.set_*_stats, delete_*_stats, import_*_stats, restore_*_stats procedure를 사용하는 경우 error가 발생 된다. 그러나 이들 procedure의 새로운 argument인 force의 값을 true로 하면 locking을 override할 수 있다. 즉, locked 상태라도 이를 무시하고 통계정보를 overwrite할 수 있다. SQL> exec dbms_stats.delete_table_stats(‘owner’, ‘table_name’, force => ‘TRUE’); 7.3.4. 통계정보 History 7.3.4.1. History 구조 Oracle은 dbms_stats package를 통해 통계정보를 수집하게 되면 그 정보들을 미래의 사 용가능성을 염두에 두고 이를 “old version”으로 관리한다. 따라서 이 정보들은 나중에 필요하면 dbms_stats.restor_*_stats을 통해 restore할 수 있다. 즉, 이전 oracle version에서 old 통계정보를 사용하기 위해 export & import statistics를 사용했다면 oracle10g에서는 그럴 필요가 없다는 것이다. 이 정보들은 default로 한달(31 일)간 “dba_tab_stats_history“에 유지된다. CF. analyze command를 사용하거나 사용자가 정의한 통계정보들은 old version으로 보 존되지 않는다. CF. database나 schema level에서 수행된 통계정보의 시작 및 끝난 시간에 대한 기록들은 “dba_optstat_operations”를 통해 확인할 수 있다. 7.3.4.2. History 활용하기 먼저 통계정보의 유지시간을 앞서 언급한 default 한달(31일)이 아니라 변경을 하고자 할 때 어떻게 하는지 알아보자. 먼저 현재의 설정을 확인하고 이를 조정해 보자. SYSTEM> select dbms_stats.get_stats_history_retention 2 from dual; GET_STATS_HISTORY_RETENTION --------------------------------------------------- 31 SYSTEM> exec dbms_stats.alter_stats_history_retention(61); JKSPARK@HANAFOS.COM 45
  • 46. http://www.ggola.com 장 경 상 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 ------------------------------------------------------- 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' JKSPARK@HANAFOS.COM 46 표 7-5 수집된 통 계의 Restore Procedur e List
  • 47. http://www.ggola.com 장 경 상 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); 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 JKSPARK@HANAFOS.COM 47
  • 48. http://www.ggola.com 장 경 상 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 48
  • 49. http://www.ggola.com 장 경 상 OCP point =============================================================== 1. automatic 통계수집에서 사용하는 두 가지 window와 그 내용 2. 특정 table만을 대상으로 불필요한 통계작업을 제거하는 방법 3. 통계정보 history 보관일자 변경 procedure 사용방법 JKSPARK@HANAFOS.COM 49
  • 50. 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 50
  • 51. 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_interval fast_start_mttr_target fast_start_mttr_target (0 보다 크거나 unset)log_checkpoint_timeout log_checkpoint_timeout fast_start_io_target UNSET 없음 log_checkpoint_interval log_checkpoint_timeout fast_start_io_target log_checkpoint_interval fast_start_io_target 1. oracle8i는 DBA가 적절한 값을 설정하여 checkpoint를 조절했다. 2. oracle9i는 fast_start_mttr_target을 통해 checkpoint조절에 도움을 받을 수 있다. 3. oracle10g는 fast_start_mttr_target을 통해 아무런 설정 없이 자동화된 checkpoint tuning을 해준다. 이 parameter를 설정하지 않거나 0보다 큰 값으로 하면(나머지 관련 3 개 parameters를 설정하지 않거나 0으로(disable)하라) 자동 tuning이 enable 된다. 단, 이 fast_start_mttr_target의 값을 낮게 설정하면 transaction당 DBWR이 write하는 평균회수 가 많아지고 높게 설정하면(또는 설정을 하지 않으면) 반대로 그 회수가 적어진다. 여러 분이 자동 tuning을 원하지 않는다면 이 parameter의 값을 명시적으로 0으로 설정하면 된다. 현재의 database에서 checkpoint tuning을 자동화하기 위해 parameter를 조정한 후 다시 database를 start해보자. [NEWSVC]LIRACLE:/app/oracle/admin/NEWSVC/pfile> vi initNEWSVC.ora ….. ….. …... JKSPARK@HANAFOS.COM 51 표 7-6 Checkpoi nt 설정과 Paramete r
  • 52. http://www.ggola.com 장 경 상 …… #fast_start_io_target = 1600 #log_checkpoint_timeout = 1800 #log_checkpoint_interval = 0 #fast_start_mttr_target = 120 ….. ….. ….. ….. ~ ~ ~ ~ ~ :wq! [NEWSVC]LIRACLE:/app/oracle/admin/NEWSVC/pfile> cd [NEWSVC]LIRACLE:/app/oracle> cd temp [NEWSVC]LIRACLE:/app/oracle/temp> sqlplus / as sysdba SQL*Plus: Release 10.1.0.4.0 - Production on Fri Aug 19 14:11:41 2005 Copyright (c) 1982, 2005, Oracle. All rights reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.1.0.4.0 - Production With the Partitioning, OLAP and Data Mining options SYS> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SYS> startup ORACLE instance started. JKSPARK@HANAFOS.COM 52
  • 53. http://www.ggola.com 장 경 상 Total System Global Area 473956352 bytes Fixed Size 779736 bytes Variable Size 136583720 bytes Database Buffers 331350016 bytes Redo Buffers 5242880 bytes Database mounted. Database opened. SYS> 관련 parameter를 모두 “unset”으로 하여 checkpoint의 자동 tuning을 enable하였다. 7.4.3. Fast Ramp-Up Oracle10g가 undo segment와 관련하여 소개하는 것 중에서 fast ramp-up time이란 것이 있다. 이는 oracle9i에서 소개된 rollback segment의 자동화 mode인 AUM(automatic undo management)을 사용하는 경우(AUM mode로 initial parameter 설정을 하게 되면) undo tablespace만 지정하는 것으로 거의 모든 rollback segment관리가 끝나게 된다. 따 라서 최초 instance가 start되거나 undo tablespace를 변경할 때에 oracle은 자동으로 적 절한 수의 undo segments를 online하는 작업을 수행하게 된다. Oracle은 이 시간을 ramp-up time이라고 부르며 oracle10g에서 이 시간이 매우 짧아졌다 는 것이다. 그 이유는 앞서 이야기한 자동으로 수집되는 통계 data를 이용하여 oracle 스 스로 얼마나 많은 수의 undo segments를 online할 것인지 바로 결정할 수 있기 때문이다. 다시 정의하면 자동으로 수집된 통계 data들이 다음에 이야기 하는 AWR로 저장이 되고 oracle10g는 이 AWR을 통해 instance startup 혹은 undo tablespace변경 시 online할 undo segments의 수를 바로 결정할 수 있다. JKSPARK@HANAFOS.COM 53
  • 54. http://www.ggola.com 장 경 상 참조 =============================================================== undo retention : o9i 80p, o9i 302p fast_start_mttr_target : o9i 76p AUM : o9i 302p JKSPARK@HANAFOS.COM 54
  • 55. 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) 통계의 누적시간 v$sysmetric_history system의 모든 metric value정보 JKSPARK@HANAFOS.COM 55 그림 7-14 AWR 연 결구조 표 7-7 통계와 Views
  • 56. http://www.ggola.com 장 경 상 v$system_wait_class wait class의 전체 wait 시간(commit, idle, system I/O 등) v$active_session_history 초당 1회 sampling한 database session의 action 정보 CF. OS 통계 : 다음은 oracle이 이야기하는 OS 통계의 설명을 그대로 보여준다. 통계 Description NUM_CPUS Number of CPUs or processors available IDLE_TICKS Number of hundredths of a second that a processor has been idle, totalled over all processors BUSY_TICKS Number of hundredths of a second that a processor has been busy executing user or kernel code, totalled over all processors USER_TICKS Number of hundredths of a second that a processor has been busy executing user code, totalled over all processors SYS_TICKS Number of hundredths of a second that a processor has been busy executing kernel code, totalled over all processors IOWAIT_TICKS Number of hundredths of a second that a processor has been waiting for I/O to complete, totalled over all processors NICE_TICKS Number of hundredths of a second that a processor has been busy executing low-priority user code, totalled over all processors AVG_IDLE_TICKS Number of hundredths of a second that a processor has been idle, averaged over all processors AVG_BUSY_TICKS Number of hundredths of a second that a processor has been busy executing user or kernel code, averaged over all processors AVG_USER_TICKS Number of hundredths of a second that a processor has been busy executing user code, averaged over all processors AVG_SYS_TICKS Number of hundredths of a second that a processor has been busy executing kernel code, averaged over all processors AVG_IOWAIT_TICKS Number of hundredths of a second that a processor has been waiting for I/O to complete, averaged over all processors AVG_NICE_TICKS Number of hundredths of a second that a processor has been busy executing low-priority user code, averaged over all processors OS_CPU_WAIT_TIME Total number of hundredths of a second that processes have JKSPARK@HANAFOS.COM 56 표 7-8 OS 통계 와 의미
  • 57. http://www.ggola.com 장 경 상 been in a ready state, waiting to be selected by the operating system scheduler to run RSRC_MGR_CPU_W AIT_TIME Total number of hundredths of a second that Oracle processes have been in a ready state, waiting for CPU to be available for their consumer group in the currently active resource plan IN_BYTES Total number of bytes that have been paged in OUT_BYTES Total number of bytes that have been paged out FS_IN_BYTES Total number of bytes that have been paged in due to the file system FS_OUT_BYTES Total number of bytes that have been paged out due to the file system AVG_IN_BYTES Number of bytes that have been paged in, averaged over all processors AVG_OUT_BYTES Total number of bytes that have been paged out, averaged over all processors AVG_FS_IN_BYTES Total number of bytes that have been paged in due to the file system, averaged over all processors AVG_FS_OUT_BYTES Total number of bytes that have been paged out due to the file system, averaged over all processors 2. data dictionary view : Description View Name Advisor 결과를 query dba_advisor_actions dba_advisor_commands dba_advisor_definitions dba_advisor_findings dba_advisor_journal dba_advisor_log dba_advisor_object_types dba_advisor_objects dba_advisor_parameters dba_advisor_rationale dba_advisor_recommendations dba_advisor_sqla_rec_sum dba_advisor_sqla_wk_map JKSPARK@HANAFOS.COM 57 표 7-9 Advisor 관련 View List
  • 58. http://www.ggola.com 장 경 상 dba_advisor_sqla_wk_stmts dba_advisor_sqlw_journal dba_advisor_sqlw_parameters dba_advisor_sqlw_stmts dba_advisor_sqlw_sum dba_advisor_sqlw_tables dba_advisor_sqlw_templates dba_advisor_tasks dba_advisor_templates dba_advisor_usage 통계 history를 query dba_hist_active_sess_history dba_hist_baseline dba_hist_bg_event_summary dba_hist_buffer_pool_stat dba_hist_cr_block_server dba_hist_current_block_server dba_hist_database_instance dba_hist_datafile dba_hist_db_cache_advice dba_hist_dlm_misc dba_hist_enqueue_stat dba_hist_event_name dba_hist_filemetric_history dba_hist_filestatxs dba_hist_instance_recovery dba_hist_java_pool_advice dba_hist_latch dba_hist_latch_children dba_hist_latch_misses_summary dba_hist_latch_name dba_hist_latch_parent dba_hist_librarycache dba_hist_log dba_hist_metric_name dba_hist_mttr_target_advice JKSPARK@HANAFOS.COM 58
  • 59. http://www.ggola.com 장 경 상 dba_hist_optimizer_env dba_hist_osstat dba_hist_osstat_name dba_hist_parameter dba_hist_parameter_name dba_hist_pga_target_advice dba_hist_pgastat dba_hist_resource_limit dba_hist_rollstat dba_hist_rowcache_summary dba_hist_seg_stat dba_hist_seg_stat_obj dba_hist_service_name dba_hist_service_stat dba_hist_service_wait_class dba_hist_sessmetric_history dba_hist_sga dba_hist_sgastat dba_hist_shared_pool_advice dba_hist_snap_error dba_hist_snapshot dba_hist_sql_plan dba_hist_sql_summary dba_hist_sql_workarea_hstgrm dba_hist_sqlbind dba_hist_sqlstat dba_hist_sqltext dba_hist_stat_name dba_hist_sys_time_model dba_hist_sysmetric_history dba_hist_sysmetric_summ Database feature 사용 통계 dba_feature_usage_statistics 각 종 database의 maximum value dba_high_water_mark_statistics Table 통계의 수정 history dba_tab_stats_history JKSPARK@HANAFOS.COM 59
  • 60. http://www.ggola.com 장 경 상 CF. high water mark : database 통계의 maximum value와 의미한다. 다음은 그 값이 의 미하는 바를 oracle 설명 그대로 기술한 것이다. Name Description USER_TABLES Number of User Tables SEGMENT_SIZE Size of Largest Segment (Bytes) PART_TABLES Maximum Number of Partitions belonging to an User Table PART_INDEXES Maximum Number of Partitions belonging to an User Index USER_INDEXES Number of User Indexes SESSIONS Maximum Number of Concurrent Sessions seen in the database DB_SIZE Maximum Size of the Database (Bytes) DATAFILES Maximum Number of Datafiles TABLESPACES Maximum Number of Tablespaces CPU_COUNT Maximum Number of CPUs QUERY_LENGTH Maximum Query Length SERVICES Maximum Number of Services CF. database feature : database feature의 사용 통계를 보여주는 data dictionary view인 “dba_feature_usage_statistics”에서 그 feature의 이름이 의미하는 바를 oracle의 설명 그 대로 살펴보자. Features Description Advanced Replication Advanced Replication has been enabled. Advanced Security External Global users are configured. Audit Options Audit options in use. Automatic Database Diagnostic Monitor A task for the Automatic Database Diagnostic Monitor has been executed. Automatic Segment Space Management (system) Extents of locally managed tablespaces are managed automatically by Oracle. Automatic Segment Space Management (user) Extents of locally managed user tablespaces are managed automatically by Oracle. Automatic SQL Execution Memory Sizing of work areas for all dedicated sessions (PGA) is automatic. Automatic Storage Manager Automatic Storage Management has been enabled Automatic Undo Management Oracle automatically manages undo data using an UNDO tablespace. JKSPARK@HANAFOS.COM 60 표 7-10 HWM 종 류와 의미 표 7-11 Database Feature 와 의미
  • 61. http://www.ggola.com 장 경 상 Automatic Workload Repository A manual Automatic Workload Repository (AWR) snapshot was taken in the last sample period. Change-Aware Incremental Backup Track blocks that have changed in the database. Client Identifier Application User Proxy Authentication: Client Identifier is used at this specific time. Data Guard Data Guard, a set of services, is being used to create, maintain, manage, and monitor one or more standby databases. Data Guard Broker Data Guard Broker, the framework that handles the creation maintenance, and monitoring of Data Guard, is being used Data Mining Oracle Data Mining option is being used. Dynamic SGA The Oracle SGA has been dynamically resized through an ALTER SYSTEM SET statement. File Mapping File Mapping, the mechanism that shows a complete mapping of a file to logical volumes and physical devices, is being used. Flashback Database Flashback Database, a rewind button for the database, is enabled Internode Parallel Execution Internode Parallel Execution is being used. Label Security Oracle Label Security, that enables label-based access control Oracle applications, is being used. Locally Managed Tablespaces (system) There exists tablespaces that are locally managed in the database. Locally Managed Tablespaces (user) There exists user tablespaces that are locally managed in the database. Messaging Gateway Messaging Gateway, that enables communication between non-Oracle messaging systems and Advanced Queuing (AQ), link configured. MTTR Advisor Mean Time to Recover Advisor is enabled. Multiple Block Sizes Multiple Block Sizes are being used with this database. OLAP - Analytic Workspaces OLAP the analytic workspaces stored in the database. JKSPARK@HANAFOS.COM 61
  • 62. http://www.ggola.com 장 경 상 OLAP - Cubes OLAP number of cubes in the OLAP catalog that are fully mapped and accessible by the OLAP API. Oracle Managed Files Database files are being managed by Oracle. Parallel SQL DDL Execution Parallel SQL DDL Execution is being used. Parallel SQL DML Execution Parallel SQL DML Execution is being used. Parallel SQL Query Execution Parallel SQL Query Execution is being used. Partitioning (system) Oracle Partitioning option is being used - there is at least one partitioned object created. Partitioning (user) Oracle Partitioning option is being used - there is at least one user partitioned object created. PL/SQL Native Compilation PL/SQL Native Compilation is being used - there is at least one natively compiled PL/SQL library unit in the database. Protection Mode - Maximum Availability Data Guard configuration data protection mode is Maximum Availability. Protection Mode - Maximum Performance Data Guard configuration data protection mode is 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. JKSPARK@HANAFOS.COM 62
  • 63. http://www.ggola.com 장 경 상 Segment Advisor A task for Segment Advisor has been executed. Server Parameter File The server parameter file (SPFILE) was used to startup the database. SGA/Memory Advisor SGA/Memory Advisor has been used. Shared Server The database is configured as Shared Server, where the server process can service multiple user processes. Spatial There is at least one usage of the Oracle Spatial index metadata table. SQL Access Advisor A task for SQL Access Advisor has been executed. SQL Tuning Advisor SQL Tuning Advisor has been used. SQL Tuning Set A SQL Tuning Set has been created in the database. Standby Archival - LGWR Data Guard configuration: Remote archival is done by LGWR. Standby Archival - ARCH Data Guard configuration: Remote archival is done by ARCH. Standby Transmission Standby database: Network transmission mode was chosen for a standby destination. Streams (system) Oracle Streams has been configured Streams (user) Users have configured Oracle Streams Tablespace Advisor Tablespace Advisor has been used. Transparent Gateway Heterogeneous Connectivity, access to a non-Oracle system, has been configured. Undo Advisor Undo Advisor has been used. Virtual Private Database (VPD) Virtual Private Database (VPD) policies are being used. 7.5.1.3. 기본통계(Base Statistics)와 측정(Metrics) Database의 상태를 측정 하기 위해서는 기준점이 필요하다. 즉, 기준과 비교하여 현시점 의 차이를 확인해야 정확한 측정이 가능하기 때문이다. 예를 들어 현 시점의 logical reads 의 수가 1만이라 할지라도 그 비교기준의 값이 9만 9천이면 1만이라는 수치는 크지 않겠 지만 그 기준이 1천 이었다면 현 시점의 1만은 매우 큰 값이 될 수도 있다. Database가 지금 startup 되었다면 현 시점의 통계들은 기본 값 즉, base statistics가 되고 시간이 흐른 후 이 값을 기준으로 두 번째 통계가 수립되었다면 이 값들은 metrics가 된 다. 따라서 매 60분마다 추출되는 통계를 기준으로 볼 때 마지막 시점에서의 통계들의 평 균 값은 metrics가 된다. JKSPARK@HANAFOS.COM 63
  • 64. http://www.ggola.com 장 경 상 이런 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_history 마지막 1시간 동안의 v$servicemetric정보 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_history 지난 1시간 동안 v$waitclassmetric의 누적정보 2. data dictionary view : View Description dba_hist_metric_name database id별 v$metricname의 snapshot dba_hist_filemetric_history workload repository에 취합된 file metric의 history dba_hist_sessmetric_history 중요 session metric의 history dba_hist_sysmetric_history v$sysmetric_history의 sanpshot을 가지고 있으며 현재 JKSPARK@HANAFOS.COM 64 표 7-12 Metric 관 련 v$View List 표 7-13 Metric관 련 dba View List
  • 65. http://www.ggola.com 장 경 상 database에 존재하는(저장되어있는) 전체 system-wide metric dba_hist_sysmetric_summary v$sysmetric_summary의 snapshot을 가지고 있으며 현 재 database에 존재하는(저장되어있는) 전체 system- wide summary metric CF. MMON이 제공하는 또 다른 정보로 database features에 대한 통계자료가 있다. View Description dba_feature_usage_statistics oracle10g가 제공하는 각종 features들(AQ, VPD, Replication 등)의 사용 통계 (얼마나 자주 사용되는지 확인할 수 있다) dba_high_water_mark_statistics database resource(최대 sessions, tables 수 등)의 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에 공간이 부족하게 되면 먼저 JKSPARK@HANAFOS.COM 65 표 7-14 Database Feature 통계
  • 66. http://www.ggola.com 장 경 상 가장 오래된 snapshot set을 reuse(overwrite)한 후 DBA에게 alert message를 보내 sysaux tablespace의 공간부족을 알린다. 5. “snapshot too old” error나 “replication”에서 말하는 snapshot, 그리고 여기서의 snapshot은 그 내용과 사용처에 있어서 다른 것이니 헛갈리지 말자. 6. 이미 앞서 언급이 되었던 initial parameter “statistics_level”의 값이 반드시 “typical”, “all”중의 하나로 설정이 되어 있어야 하며 “basic”으로 설정하면 snapshot은 생성되지 않는다. CF. 매우 중요한 “statistics_level” parameter를 다시 정리하면 다음과 같다. 1. BASIC : AWR 통계와 metrics을 취합하지 않는다. 2. TYPICAL : database의 action을 monitor하기 위해 필요한 대부분의 중요한 통계를 취 합한다. 3. ALL : 모든 사용 가능한 통계를 취합한다. (SQL Plan, OS통계 등) CF. 이전 version에서 사용하던 oracle의 statspack은 oracle10g의 workload repository를 사용할 수 없고 또한 자동으로 migration을 해주지도 않는다. 따라서 필요하다면 statspack을 이용해 작성한 application code들을 직접 수정해주어야 한다. 7.5.2. AWR Control 7.5.2.1. Snapshot Schedule 조정 (Manually) 먼저 앞서 설명한 automatic snapshot의 주기를 확인하는 방법과 조정하는 command를 확인해보자. SQL> exec dbms_workload_repository.modify_snapshot_settings(interval => 30, retention => 10*24*60); 위의 예는 snapshot 주기를 30분단위로 하고 그 결과를 10일간 유지하겠다는 뜻이다. 각 argument의 의미를 자세히 보면 다음과 같다. 1. interval : 분단위로 표시되며 최소 10분에서 최대 1년을 지정한다. 만일 0을 지정하면 최대 값인 1년으로 설정되며(이는 사실상 snapshot을 disable하는 것과 마찬가지라 볼 수 있다) NULL이 지정되면 현재의 값을 유지한다. (default 1시간) 2. retention : 역시 분단위로 지정되며 최소 1일에서 최대 100년까지 지정이 가능하다. 만 일 0을 지정하면 최대 값인 100년으로 설정되고(이는 사실상 지우지 않겠다는 즉, automatic purge(삭제)를 disable하겠다는 의미가 될 것이다) NULL이 지정되면 이전 값 이 유지된다. (default 7일) JKSPARK@HANAFOS.COM 66
  • 67. http://www.ggola.com 장 경 상 CF. 앞서 언급 했지만 sysaux tablespace가 부족하면 위 설정보다 우선하여 가장 오래된 snapshot set의 공간을 reuse한다. 위의 예를 실제로 수행해서 그 결과를 확인해 보자. SYSTEM> col snap_interval for a20 SYSTEM> col retention for a20 SYSTEM> select snap_interval, retention 2 from dba_hist_wr_control; SNAP_INTERVAL RETENTION ------------------------- -------------------- +00000 01:00:00.0 +00007 00:00:00.0 SYSTEM> exec dbms_workload_repository.modify_snapshot_settings(- > interval => 30, retention => 10*24*60); 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. JKSPARK@HANAFOS.COM 67
  • 68. http://www.ggola.com 장 경 상 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문서의 설명과 실제결과가 틀리게 나왔다는 것을 알 필요가 있다고 생각되어 그 결과를 보여준다. (굳이 테스트할 필요는 없 으니 아래 예를 보고 넘어가도 좋다) 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 68
  • 69. http://www.ggola.com 장 경 상 위에서 편집을 선택하면 snapshot의 생성 및 보관주기를 다음과 같은 화면에서 수정할 수 있다. 위 그림에서 “보관된 스냅샷 집합”은 다음에 설명하는 baseline을 의미한다. 아 직 baseline이 없는 database라면 여기서 나타나지 않을 것이다. 이 부분은 추후 설명되는 “snapshot baseline”의 em 부분에서 다시 확인하도록 한다. JKSPARK@HANAFOS.COM 69 그림 7-15 AWR snapshot 상태화면
  • 70. 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 70 그림 7-16 AWR snapshot 편집화면
  • 71. 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 71
  • 72. 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 72 그림 7-15 AWR snapshot 상태화면
  • 73. http://www.ggola.com 장 경 상 위 그림에서 “보관된 스냅샷 집합”을 보면 앞서 만들었던 baseline의 baseline id가 나타 나면 link가 되어있다. 이 link을 click하면 다음과 같은 화면으로 이동한다. 이 화면은 현재 존재하는 baseline의 목록을 보여주며 우측의 dropdown 메뉴를 선택하 여 실행함으로써 drop을 하거나 향후 설명할 보고서를 작성하는 등의 작업을 진행할 수 있다. 위 화면에서 우측 상단의 “보관된 스냅샷 집합 생성”을 click하거나 또는 이 그림의 전 그 림인 “작업로드저장소”의 하단에 있는 스냅샷에 link된 숫자를 선택하거나 또는 최초 em 의 database control에서 “성능  스냅샷”의 화면을 선택하면 다음과 같은 화면으로 이 동한다. 여기서 snapshot에 대한 다양한 편집이 가능하다. JKSPARK@HANAFOS.COM 73 그림 7-17 Snapshot 과 Baseline 정보 그림 7-18 Snapshot 편집화면
  • 74. http://www.ggola.com 장 경 상 우측의 dropdown 메뉴를 통해 다양한 작업을 할 수 있다. 현재 설명하고 있는 snapshot baseline을 만들기 위해서는 이 메뉴 중 “보관된 스냅샷 집합 생성”을 선택하고 좌측에서 시작 스냅샷을 선택한 후 우측의 실행 버튼을 click한다. (좌측 상단에서 시간 또는 일자를 선택하여 찾고자 하는 snapshot list를 추출할 수도 있다) 그러면 다음과 같이 종료 snapshot을 선택하는 화면에서 원하는 snapshot을 선택한 후 확인 버튼을 click하면 baseline이 만들어진다. 아래 그림은 최종 baseline이 생성된 화면이다. 7.5.2.5. Other Snapshot Control 앞서 설명한 snapshot을 control하는 package는 다른 기능도 가지고 있다. 그 사용법을 JKSPARK@HANAFOS.COM 74 그림 7-19 Baseline 생성화면 그림 7-20 Baseline 생성결과
  • 75. http://www.ggola.com 장 경 상 소개한다. 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); 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 을 사용하라) 결과값이 너무 길기 때문에 일부만 보여주도록 한다. JKSPARK@HANAFOS.COM 75
  • 76. http://www.ggola.com 장 경 상 SYSTEM> select dbid, baseline_id, start_snap_id, end_snap_id from dba_hist_baseline; DBID BASELINE_ID START_SNAP_ID END_SNAP_ID --------------- ------------------- ------------------------- --------------------- 3941507194 1 1274 1279 SYSTEM> select instance_number from v$instance; INSTANCE_NUMBER ------------------------------- 1 SYSTEM> select output from table( 2 dbms_workload_repository.awr_report_text(3941507194, 1, 1274, 1279)); OUTPUT -------------------------------------------------------------------------------- WORKLOAD REPOSITORY report for DB Name DB Id Instance Inst Num Release Cluster Host ------------- --------------- -------------- ------------- ------------- ----------- ------------- NEWSVC 3941507194 NEWSVC 1 10.1.0.4.0 NO LIRACLE Snap Id Snap Time Sessions Curs/Sess ---------- ------------------------- ----------- ------------- Begin Snap: 1274 16-Aug-05 14:01:00 17 9,137.6 End Snap: 1279 16-Aug-05 19:01:01 17 9,529.8 Elapsed: 300.01 (mins) OUTPUT -------------------------------------------------------------------------------- DB Time: 0.50 (mins) Cache Sizes (end) ~~~~~~~~~~~~~ JKSPARK@HANAFOS.COM 76
  • 77. http://www.ggola.com 장 경 상 Buffer Cache: 200M Std Block Size: 8K Shared Pool Size: 144M Log Buffer: 5,120K ............ ............ Instance Efficiency Percentages (Target 100%) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Buffer Nowait %: 99.99 Redo NoWait %: 100.00 Buffer Hit %: 99.71 In-memory Sort %: 100.00 Library Hit %: 99.19 Soft Parse %: 98.69 Execute to Parse %: 51.81 Latch Hit %: 100.00 Parse CPU to Parse Elapsd %: 80.00 % Non-Parse CPU: 87.23 OUTPUT -------------------------------------------------------------------------------- Shared Pool Statistics Begin End ------ ------ Memory Usage %: 93.97 94.02 % SQL with executions>1: 89.47 89.76 % Memory for SQL w/exec>1: 88.38 88.92 Top 5 Timed Events ~~~~~~~~~~~~~~~~~~ % Total Event Waits Time (s) DB Time Wait Class --------------------------------------------- ------------ ---------------- --------------- --------------------- OUTPUT ----------------------------------------------------------------------------------------------------------------- JKSPARK@HANAFOS.COM 77
  • 78. http://www.ggola.com 장 경 상 log file parallel write 1,100 24 78.90 System I/O CPU time 16 53.82 log file sync 334 11 37.47 Commit control file parallel write 6,058 10 32.16 System I/O process startup 223 7 22.04 Other ------------------------------------------------------------------------------------ ............ ............ OUTPUT -------------------------------------------------------------------------------- workarea_size_policy AUTO ------------------------------------------------------------- End of Report 1943 rows selected. 7.5.3.2. Report Script 사용하기 앞서 ADDM에서 보았던 script처럼 AWR도 oracle이 제공하는 script를 사용하는 것이 일반적인 방식이다. 위치는 “$ORACLE_HOME/rdbms/admin”에 있으며 script 이름은 “awrrpt.sql”이다. SYSTEM> @?/rdbms/admin/awrrpt Current Instance ~~~~~~~~~~~~~~~~ DB Id DB Name Inst Num Instance --------------- -------------- ------------ ------------- 3941507194 NEWSVC 1 NEWSVC Specify the Report Type ~~~~~~~~~~~~~~~~~~~~~~~ Would you like an HTML report, or a plain text report? JKSPARK@HANAFOS.COM 78
  • 79. http://www.ggola.com 장 경 상 Enter 'html' for an HTML report, or 'text' for plain text Defaults to 'html' Enter value for report_type: html 바로 위에서 굵은 글자로 표시한 html이 첫 번째로 선택하는 report type이다. 여러분은 html과 text중 하나를 입력하면 된다. (default는 html이다) Type Specified: html Instances in this Workload Repository schema ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ DB Id Inst Num DB Name Instance Host ----------------- ------------- ------------- ------------- ------------ * 3941507194 1 NEWSVC NEWSVC LIRACLE Using 3941507194 for database Id Using 1 for instance number Specify the number of days of snapshots to choose from ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Entering the number of days (n) will result in the most recent (n) days of snapshots being listed. Pressing <return> without specifying a number lists all completed snapshots. Listing the last 3 days of Completed Snapshots Snap Instance DB Name Snap Id Snap Started Level ------------- -------------- --------- ------------------------ ------- NEWSVC NEWSVC 1380 21 Aug 2005 00:00 1 JKSPARK@HANAFOS.COM 79
  • 80. http://www.ggola.com 장 경 상 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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의 내용을 확 인하는 과정이다. JKSPARK@HANAFOS.COM 80
  • 81. http://www.ggola.com 장 경 상 Using the report name awr_1440_1443.html <HTML><HEAD><TITLE>AWR Report</TITLE><style type="text/css">body.awr {font:bold 10pt Arial,Helvetica,Geneva,sans-serif;color:black ; background:White;} pre.awr {font:8pt Courier;color:black; background:White;}h1.awr {font:bold 20pt Arial,Helvetica,Geneva,sans-serif;color:#336699 ;background-color:White;border-bottom:1px solid #cccc99;margin-top:0pt; margin- bottom:0pt;padding:0px 0px 0px 0px;} h2.awr {font:bold 18pt Arial,Helvetica,Geneva,sans-serif;color:#336699;background- color:White;margin-top:4pt; margin-bottom:0pt; …………. …………. SYSTEM> !more awr_1440_1443.html <HTML><HEAD><TITLE>AWR Report</TITLE><style type="text/css">body.awr {font:bold 10pt Arial,Helvetica,Geneva,sans-serif;color:black ; background:White;} pre.awr {font:8pt Courier;color:black; background:White;}h1.awr {font:bold 20pt Arial,Helvetica,Geneva,sans-serif;color:#336699 ;background-color:White;bo …………. …………. SYSTEM> AWR report를 html로 만들었기 때문에 위에서처럼 그냥 text로는 알아볼 수가 없다. 이 제 마지막으로 이 file을 download하여 web browser를 통해 확인한 결과를 보자. (앞서 확인한 text와 그 결과가 동일하다) JKSPARK@HANAFOS.COM 81
  • 82. 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에서 “성능  스냅샷”의 화면에서 dropdown JKSPARK@HANAFOS.COM 82 그림 7-21 AWR Report 그림 7-15
  • 83. http://www.ggola.com 장 경 상 메뉴 중 “보고서 보기”를 선택하면 된다. 아래 그림은 위에서 보고서 보기를 선택하여 start snapshot과 end snapshot을 지정한 후 최종 보고서 화면이다. JKSPARK@HANAFOS.COM 83 그림 7-23 Snapshot Report 그림 7-22 Snapshot Report 설 정하기
  • 84. 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 84
  • 85. 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_VA LUE Sampling 당시 수행하던 SQL 의 plan(hash value) 없음 SQL_OPCODE Sampling 당시 수행하던 SQL의 대표 code v$session.command SERVICE_HASH Service hash value v$active_services.name_hash 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 value WAIT_TIME 0  sampling시 waiting > 0  last wait total v$session.wait_time TIME_WAITED waiting으로 소비한 시간 위 session_state가 WAITING인 경우에 한해 (만일, wait event가 1초 이상 지 JKSPARK@HANAFOS.COM 85 표 7-15 ASH 항 목과 의미
  • 86. http://www.ggola.com 장 경 상 속되고 해당 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_mo dule) ACTION 실행중인 module의 action name v$session.action (dbms_application_info.set_acti on) 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 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 JKSPARK@HANAFOS.COM 86 표 7-16 SQL 종류 별 Code 값
  • 87. http://www.ggola.com 장 경 상 29 COMMENT 30 AUDIT OBJECT 31 NOAUDIT OBJECT 32 CREATE DATABASE LINK 33 DROP DATABASE LINK 34 CREATE DATABASE 35 ALTER DATABASE 36 CREATE ROLLBACK SEG 37 ALTER ROLLBACK SEG 38 DROP ROLLBACK SEG 39 CREATE TABLESPACE 40 ALTER TABLESPACE 41 DROP TABLESPACE 42 ALTER SESSION 43 ALTER USER 44 COMMIT 45 ROLLBACK 46 SAVEPOINT 47 PL/SQL EXECUTE 48 SET TRANSACTION 49 ALTER SYSTEM 50 EXPLAIN 51 CREATE USER 52 CREATE ROLE 53 DROP USER 54 DROP ROLE 55 SET ROLE 56 CREATE SCHEMA 57 CREATE CONTROL FILE 59 CREATE TRIGGER 60 ALTER TRIGGER 61 DROP TRIGGER 62 ANALYZE TABLE 63 ANALYZE INDEX 64 ANALYZE CLUSTER 65 CREATE PROFILE 66 DROP PROFILE 67 ALTER PROFILE 68 DROP PROCEDURE 70 ALTER RESOURCE COST 71 CREATE MATERIALIZED VIEW LOG 72 ALTER MATERIALIZED VIEW LOG 73 DROP MATERIALIZED VIEW LOG 74 CREATE MATERIALIZED VIEW 75 ALTER MATERIALIZED VIEW 76 DROP MATERIALIZED VIEW 77 CREATE TYPE 78 DROP TYPE 79 ALTER ROLE 80 ALTER TYPE 81 CREATE TYPE BODY 82 ALTER TYPE BODY 83 DROP TYPE BODY 84 DROP LIBRARY 85 TRUNCATE TABLE 86 TRUNCATE CLUSTER 91 CREATE FUNCTION 92 ALTER FUNCTION 93 DROP FUNCTION 94 CREATE PACKAGE 95 ALTER PACKAGE 96 DROP PACKAGE 97 CREATE PACKAGE BODY 98 ALTER PACKAGE BODY 99 DROP PACKAGE BODY 100 LOGON 101 LOGOFF 102 LOGOFF BY CLEANUP 103 SESSION REC 104 SYSTEM AUDIT JKSPARK@HANAFOS.COM 87
  • 88. http://www.ggola.com 장 경 상 105 SYSTEM NOAUDIT 106 AUDIT DEFAULT 107 NOAUDIT DEFAULT 108 SYSTEM GRANT 109 SYSTEM REVOKE 110 CREATE PUBLIC SYNONYM 111 DROP PUBLIC SYNONYM 112 CREATE PUBLIC DATABASE LINK 113 DROP PUBLIC DATABASE LINK 114 GRANT ROLE 115 REVOKE ROLE 116 EXECUTE PROCEDURE 117 USER COMMENT 118 ENABLE TRIGGER 119 DISABLE TRIGGER 120 ENABLE ALL TRIGGERS 121 DISABLE ALL TRIGGERS 122 NETWORK ERROR 123 EXECUTE TYPE 157 CREATE DIRECTORY 158 DROP DIRECTORY 159 CREATE LIBRARY 160 CREATE JAVA 161 ALTER JAVA 162 DROP JAVA 163 CREATE OPERATOR 164 CREATE INDEXTYPE 165 DROP INDEXTYPE 167 DROP OPERATOR 168 ASSOCIATE STATISTICS 169 DISASSOCIATE STATISTICS 170 CALL METHOD 171 CREATE SUMMARY 172 ALTER SUMMARY 173 DROP SUMMARY 174 CREATE DIMENSION 175 ALTER DIMENSION 176 DROP DIMENSION 177 CREATE CONTEXT 178 DROP CONTEXT 179 ALTER OUTLINE 180 CREATE OUTLINE 181 DROP OUTLINE 182 UPDATE INDEXES 183 ALTER OPERATOR 7.5.4.3. ASH Example 간단하게 위 내용들을 확인해 보자. 먼저 새로운 다음의 예에서 굵게 표시된 background process MMNL을 보자. [NEWSVC]LIRACLE:/app/oracle/temp> ps -ef | grep ora_ oracle 15862 1 0 Aug19 ? 00:00:00 ora_pmon_NEWSVC oracle 15864 1 0 Aug19 ? 00:00:00 ora_mman_NEWSVC oracle 15866 1 0 Aug19 ? 00:00:15 ora_dbw0_NEWSVC oracle 15868 1 0 Aug19 ? 00:00:22 ora_lgwr_NEWSVC oracle 15870 1 0 Aug19 ? 00:00:01 ora_ckpt_NEWSVC oracle 15872 1 0 Aug19 ? 00:00:32 ora_smon_NEWSVC oracle 15874 1 0 Aug19 ? 00:00:00 ora_reco_NEWSVC JKSPARK@HANAFOS.COM 88
  • 89. http://www.ggola.com 장 경 상 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; 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 - JKSPARK@HANAFOS.COM 89
  • 90. http://www.ggola.com 장 경 상 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 ------ ---------- --------------------- --- --------------------------------------- --------- --------- --------------- 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 JKSPARK@HANAFOS.COM 90
  • 91. http://www.ggola.com 장 경 상 2 where object_id = 61818; OBJECT_NAME OBJECT_ID ------------------------------ ---------------- X_ASH 61818 SYSTEM> select tablespace_name from dba_data_files 2 where file_id = 16; TABLESPACE_NAME ------------------------------ USER_DEFAULT 보다 구체적이다. Table X_ASH에 대한 insert작업이 일어났고 그 tablespace는 user_default이라는 것도 확인이 된다. 여기서는 간단하게 살펴보았으나 이 view를 잘 이 용하면 보다 많은 정보들을 유추해낼 수 있을 것이다. CF. 아마도 여러분 중 일부는 이 ASH와 관련하여 v$session의 변화를 인식한 사람이 있 을지도 모르겠다. 아직 확인을 하지 못했다면 v$session을 조회해 보라. 이전과 달라진 매 우 많은 columns이 추가된 것을 확인할 수 있을 것이다. 특히나 우리가 자주 사용하던 v$session_wait의 columns도 볼 수 있다는 것은 신선한 느낌을 준다. ASH의 기능은 v$session의 변화와 무관하지 않을 것이다. CF. oracle10g release 2부터는 ASH report를 통해 즉각적인 분석 즉, immediate spot 분 석이 가능해진다. 7.5.5. Advisor (문제 해결사) Advisors는 database의 성능 및 자원(performance and resource)에 대한 유용한 정보를 제공해주는 server components이다. 여러 종류의 advisor가 존재하며 여기서는 그 기반 구조 및 구성요소에 대해 설명한다. 7.5.5.1. Advisor의 구조 앞서 설명한 ADDM은 system 진단 결과에 대한 Top-Down 형식의 분석을 진행하면서 파악된 문제들에 대한 적절한 해결책을 제공하는 것이 그 중요한 기능의 하나라고 했다. 사실 이 기능도 진단된 문제들에 대하여 각각의 advisor를 call함으로써 문제해결에 대한 접근방식을 제공하는 것이다. JKSPARK@HANAFOS.COM 91
  • 92. http://www.ggola.com 장 경 상 CF. 결국은 workload repository에서 추출된 정보들이 이러한 일들을 가능하게 만들어 주는 것이다. 그 만큼 workload repository는 중요하다. 잘못된 정보는 잘못된 결과를 제 안한다는 것을 명심하자. Oracle10g가 제공하는 기본 advisor는 다음과 같은 구조하에 작동된다. 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를 산출하는 방법을 설명한 바 있다. 거기에서 JKSPARK@HANAFOS.COM 92 그림 7-24 Advisor Architect ure
  • 93. http://www.ggola.com 장 경 상 report를 산출하는 여러 가지 방법들을 제시했고 특히 dbms_advisor package를 이용하 여 task를 설정하여 분석을 수행한 후 report를 산출하는 예도 설명된 바 있다. 그 과정을 다시 정리해보면 다음과 같다. 이 과정은 dbms_advisor의 sub procedure와 function을 call함으로써 이루어진다. 먼저 아래의 과정은 id와 task를 받는 변수 v_id와 v_task가 있다고 가정한다. 1. create_task('advisor_name', :v_id, :v_task); 2. set_task_parameter(:v_task, 'START_SNAPSHOT', start_snap_id); 3. set_task_parameter(:v_task, 'END_SNAPSHOT', end_snap_id); 4. set_task_parameter(:v_task, 'INSTANCE', instance_id); 5. set_task_parameter(:v_task, 'DB_ID', database_id); 6. execute_task(:v_task) 7. 마지막으로 결과를 보기 위해 SQL> select dbms_advisor.get_task_report(:v_task) from dual; 그러나 이 advisor를 위한 task를 생성할 때 그 종류가 무엇이 있는지는 언급하지는 않았 다. 즉, dbms_advisor.create_task를 통해 task를 생성할 때 입력을 해야 하는 advisor의 값은 어떤 것들이 있는지 알아보자. 다음의 SQL 결과는 현재 database에서 제공하는 (dbms_advisor.create_task의 advisor_name parameter로 줄 수 있는) advisor의 종류를 보여준다. SYSTEM> select * from dba_advisor_definitions; ADVISOR_ID ADVISOR_NAME PROPERTY ------------------ ------------------------------ ---------------- 1 ADDM 1 2 SQL Access Advisor 15 3 Undo Advisor 1 4 SQL Tuning Advisor 3 5 Segment Advisor 3 6 SQL Workload Manager 0 7 Tune MView 31 7 rows selected. 다음은 위에서 설명한 것 외에 advisor의 control을 위해 자주 사용하는 중요한 sub JKSPARK@HANAFOS.COM 93
  • 94. http://www.ggola.com 장 경 상 stored-procedure에 대한 설명이다. 1. delete_task : repository로부터 지정된 task를 삭제한다. 2. cancel_task : soft interrupt라 한다. 현재 작업중인 task를 종료한다. (그러나 “CTRL+C”처럼(hard interrupt) low-level database access를 강제로 중단하지는 않는다. 따라서 약간 혹은 생각보다 많은 시간이 소요될 수도 있다) 3. interrupt_task : 현재 수행중인 task를 중단한다. 하지만 이 작업은 정상적인 exit처럼 작동하기 때문에 중단하는 시점까지의 분석 결과는 사용이 가능하다. 4. resume_task : 현재 중단된 task를 다시 수행한다. 5. get_task_script : buffer의 advisor제안 사항을 실행하는 SQL script로 return한다. 6. mark_recommendation : 특정 task의 특정 recommendation의 상태를(ACCEPT, IGNORE, IMPLEMENTED, REJECT) 설정한다. 이 값은 분석에 대한 제안을 위해 만들어 지는 scripts에 영향을 주게 된다. 예를 들어 어떤 분석이 reject이면 그 항목에 대한 recommendation이 나타나지 않게 된다. 7. update_task_attributes : 이미 만들어진 task의 속성을 변경하기 위해 사용된다. (task 의 이름 변경, 설명 및 사용상태의 변경 등) 8. reset_task : 지정한 task을 초기화 한다. 따라서 기존에 존재하는 해당 task의 제안들은 삭제된다. 9. create_file : 분석결과를 file로 만들어준다. (분석결과는 CLOB type임으로 이를 file로 저장하여 보기 쉽게 해준다) CF. advisor와 관련한 정보를 담고 있는 dictionary들은 앞서 AWR의 통계정보에 대한 access를 설명하면서 이미 살펴본 바 있다 CF. 특별한 권한인 “advisor”를 grant받으면 모든 advisor관련 stored-procedures, views 에 access가 가능하다. 이는 앞서 chapter 4에서 materialized view관리 부분에서 살펴본 바 있다. 7.5.5.4. Using em 이 부분은 여기서 따로 보여줄 것이 없다. 잘 생각해 보라. 앞서 우리는 이미 ADDM을 설 명하면서 em과의 관계를 살펴본 바 있다. 물론, 거기서 “Advisor Central (중앙 권고자)” 를 통해 advisor에 접근하고 Top-Down형식으로 문제를 찾아가는 방법도 살펴보았다. 기억이 나지 않는다면 ADDM 부분을 다시 살펴보라. JKSPARK@HANAFOS.COM 94
  • 95. 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 95
  • 96. 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 96
  • 97. 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에 write된다. 이를 종합해서 볼 때 만일 em의 database control을 사용하지 않고 queuing된 alerts를 받 JKSPARK@HANAFOS.COM 97
  • 98. http://www.ggola.com 장 경 상 기 위해서는 앞서 설명한 “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 98 그림 7-25 Alert Architect ure
  • 99. 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으로 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”에서 확인할 수 있으며 JKSPARK@HANAFOS.COM 99
  • 100. http://www.ggola.com 장 경 상 문제가 해결되면 “dba_alert_history”로 이동된다. 그 밖에 alerts의 type을 확인하는 것은 “v$alert_types”에서 가능하다. 다음은 현재 필자의 database에서 alert message를 확인 해본 예이다. 실제 결과 중 recovery area message는 너무 길어서 메시지를 “…..”으로 축약하여 표시 했다. SYSTEM> select object_name, object_type, reason 2 from dba_outstanding_alerts; OBJECT_NAME OBJECT_TYPE REASON ------------------------ -------------------------- -------------------------------------------------------------------------- RECOVERY AREA RECOVERY AREA db_recovery_file_dest_size of 524288... bytes is 85.12%.. AUTOTBS TABLESPACE Tablespace [AUTOTBS] is [96 percent] full SYSTEM SYSTEM Metrics "Current Open Cursors Count" is at 1249 7.6.3.2. Stateless Alert Database event와 연동되는 alert로서 threshold가 없는 non-threshold alert를 stateless alert라 칭한다. 이런 류의 server alert로 “snapshot too old”, “recovery area space”, “resumable session suspended”같은 것들이 있는데 이 alerts는 event발생시 바로 history table로 이동된다. 이런 stateless alert는 database control의 repository에 저장되 기 때문에 clear하는 작업 또한 database control에서 이루어 진다. CF. 이런 용어들과 metrics을 확인하다 이상한 점이 있었다. 이유를 확인하진 못했으나 v$alert_types을 보면 snapshot too old를 제외한 recovery area나 session suspended는 stateful로 정의가 되어있었기 때문이다. 필자가 보기에 보다 구체적이고 정확하게 alert 를 구분하기 위해서는 threshold level인가(threshold based alerts) 아니면 non-threshold level인가로 구분을 하는 것이 더 옳을 것으로 생각된다. 7.6.3.3. Out-of-Box Server Alert 이 용어는 oracle10g가 default로 enable하여 사용하는 database event관련 server alert를 말한다. (물론, tablespace 사용량과 관련된 alert는 앞서 말한바 대로 threshold based alert이다) 1. tablespace usage(default warning 85%, critical 97%) 2. snapshot too old 3. resumable session suspended (oracle9i에서 소개된 session의 작업이 진행 중에 tablespace가 부족하게 되는 경우 해당 session의 작업을 holding할 수 있는 기능을 말한 다) JKSPARK@HANAFOS.COM 100
  • 101. http://www.ggola.com 장 경 상 4. recovery area usage (initial parameter “db_recovery_file_dest_size”의 사용량을 말한 다) CF. oracle10g database관련 자료에서는 구체적인 설명이 없지만 위 alerts은 em과의 연 관성 때문에 따로 분류하는 것이라고 생각된다. 즉, 현재까지는 database event와 관련된 alerts중 위와 같은 것들만 server alerts에서 볼 수 있고 나머지는(예를 들면 archive destination size alert) em에서만 가능하다. 따라서 이런 종류의 alerts은 em의 관리를 통 해서만 alert를 받을 수 있는 것이지만 위 4가지 database events관련 alerts은 server alerts에 존재하기 때문에(ALERT_QUE에 쌓이기 때문에) “out-of-box”라는 용어를 사용 하는 것으로 생각된다. 굳이 수식으로 표현하자면 “em alerts > server alerts = (general alerts + out-of-box alerts) or (threshold level alerts + non-threshold level alerts)” 정도 가 될 것이다. CF. 앞서 조회한 dba_outstanding_alerts에서 recover area정보는 나타났지만 em에서 나 타난 archive destination size가 부족하다는 정보가 안 보이는 것도 out-of-box alert에 속 한 것이냐 아니냐에 따라 server에서 받을 수 있는 것과 그렇지 않은 것으로 나뉘어지기 때문으로 생각된다. 7.6.4. Alert Control 7.6.4.1. Threshold 조절 (Manually) 여러분이 PL/SQL을 통해 manually alert을 위한 threshold를 설정하기 위해서는 package “dbms_server_alert”를 사용해야 한다. 이 package에서 threshold를 조절하기 위해 사용하는 procedure로 threshold를 확인하는 get_threshold와 threshold를 설정하 는 set_threshold는 다음과 같은 parameter를 갖는다. 단, parameter in/out의 설정은 set_threshold의 경우 모두 in parameter이고 get_threshold의 경우는 아래와 같다. CF. server alert queue를 확인하는 sub procedure인 expand_message function은 나중에 설명하는 “Alert 확인(Manually)” 부분의 예제에서 다룬다. Argument In/Out Description metrics_id in 내부적으로 사용되는 metrics id (아래 parameter type 참조) warning_operator out warning threshold의 비교연산자 (아래 parameter type 참조) warning_value out warning value JKSPARK@HANAFOS.COM 101 표 7-17 Threshol d 설정 Paramete r
  • 102. http://www.ggola.com 장 경 상 critical_operator out critical threshold의 비교연산자 (아래 parameter type 참조) critical_value out critical value observation_period out threshold 와 metric을 비교하는 주기 consecutive_occurre nces 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_TIME Service 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 JKSPARK@HANAFOS.COM 102 표 7-18 Metric 종 류와 의미
  • 103. http://www.ggola.com 장 경 상 REDO_ALLOCATION_HIT Redo Log Allocation Hit % of redo allocations TRANSACTION_RATE Number of Transactions (for each second) Transactions for each Second PHYSICAL_READS_SEC Physical Reads (for each second) Reads for each Second PHYSICAL_READS_TXN Physical Reads (for each transaction) Reads for each Transaction PHYSICAL_WRITES_SEC Physical Writes (for each second) Writes for each Second PHYSICAL_WRITES_TXN Physical Writes (for each transaction) Writes for each Transaction PHYSICAL__READS_DIR_SEC Direct Physical Reads (for each second) Reads for each Second PHYSICAL_READS_DIR_TXN Direct Physical Reads (for each transaction) Reads for each Transaction PHYSICAL_WRITES_DIR_SEC Direct Physical Writes (for each second) Writes for each Second PHYSICAL_WRITES_DIR_TXN Direct Physical Writes (for each transaction) Writes for each Transaction PHYSICAL_READS_LOB_SEC Direct LOB Physical Reads (for each second) Reads for each Second PHYSICAL_READS_LOB_TXN Direct LOB Physical Reads (for each transaction) Reads for each Transaction PHYSICAL_WRITES_LOB_SEC Direct LOB Physical Writes (for each second) Writes for each Second PHYSICAL_WRITES_LOB_TXN Direct LOB Physical Writes (for each transaction) Writes for each Transaction REDO_GENERATED_SEC Redo Generated (for each second) Redo Bytes for each Second REDO_GENERATED_TXN Redo 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_SEC Cumulative Logons (for each second) Logons for each Second LOGONS_TXN Cumulative Logons (for each transaction) Logons for each Transaction LOGONS_CURRENT Current Number of Logons Number of Logons OPEN_CURSORS_SEC Cumulative Open Cursors (for each second) Cursors for each Second OPEN_CURSORS_TXN Cumulative Open Cursors (for each Cursors for each JKSPARK@HANAFOS.COM 103
  • 104. http://www.ggola.com 장 경 상 transaction) 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_TXN User Commits (for each transaction) Commits for each Transaction USER_ROLLBACKS_SEC User Rollbacks (for each second) Rollbacks for each Second USER_ROLLBACKS_TXN User 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_TXN Recursive Calls (for each transaction) Calls for each Transaction SESS_LOGICAL_READS_SEC Session Logical Reads (for each second) Reads for each Second SESS_LOGICAL_READS_TXN Session Logical Reads (for each transaction) Reads for each Transaction DBWR_CKPT_SEC DBWR Checkpoints (for each second) Checkpoints for each Second LOG_SWITCH_SEC Background Checkpoints (for each second) Checkpoints for each Second REDO_WRITES_SEC Redo Writes (for each second) Writes for each Second REDO_WRITES_TXN Redo Writes (for each transaction) Writes for each Transaction LONG_TABLE_SCANS_SEC Scans on Long Tables (for each second) Scans for each Second LONG_TABLE_SCANS_TXN Scans on Long Tables (for each transaction) Scans for each Transaction TOTAL_TABLE_SCANS_SEC Total Table Scans (for each second) Scans for each Second TOTAL_TABLE_SCANS_TXN Total Table Scans (for each transaction) Scans for each Transaction FULL_INDEX_SCANS_SEC Fast Full Index Scans (for each second) Scans for each Second FULL_INDEXE_SCANS_TXN Fast Full Index Scans (for each transaction) Scans for each Transaction TOTAL_INDEX_SCANS_SEC Total Index Scans (for each second) Scans for each Second TOTAL_INDEX_SCANS_TXN Total Index Scans (for each Scans for each Transaction JKSPARK@HANAFOS.COM 104
  • 105. http://www.ggola.com 장 경 상 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_TXN Parse Failures (for each transaction) Parses for each Transaction DISK_SORT_SEC Sorts to Disk (for each second) Sorts for each Second DISK_SORT_TXN Sorts to Disk (for each transaction) Sorts for each Transaction ROWS_PER_SORT Rows Processed for each Sort Rows for each Sort EXECUTE_WITHOUT_PARSE Executes Performed Without Parsing % of all executes SOFT_PARSE_PCT Soft Parse (%) % of all parses CURSOR_CACHE_HIT Cursor Cache Hit (%) % of soft parses USER_CALLS_PCT User Calls (%) % of all calls TXN_COMMITTED_PCT Transactions Committed (%) % of all transactions NETWORK_BYTES_SEC Network Bytes, for each second Bytes for each Second RESPONSE_TXN Response (for each transaction) Seconds for each Transaction DATA_DICT_HIT Data Dictionary Hit (%) % of dictionary accesses DATA_DICT_MISS Data Dictionary Miss (%) % of dictionary accesses SHARED_POOL_FREE_PCT Shared Pool Free(%) % of shared pool AVERAGE_FILE_READ_TIME Average File Read Time Microseconds AVERAGE_FILE_WRITE_TIME Average File Write Time Microseconds DISK_IO Disk I/O Milliseconds PROCESS_LIMIT_PCT Process Limit Usage (%) % of maximum value SESSION_LIMIT_PCT Session Limit Usage (%) % of maximum value USER_LIMIT_PCT User Limit Usage (%) % of maximum value AVG_USERS_WAITING Average Number of Users Waiting on a Class of Wait Events Count of sessions DB_TIME_WAITING Percent of Database Time Spent Waiting on a Class of Wait Events % of Database Time APPL_DESGN_WAIT_SCT Application Design Wait (by session count) Count of sessions APPL_DESGN_WAIT_TIME Application Design Wait (by time) Microseconds PHYS_DESGN_WAIT_SCT Physical Design Wait (by session Count of sessions JKSPARK@HANAFOS.COM 105
  • 106. http://www.ggola.com 장 경 상 count) PHYS_DESGN_WAIT_TIME Physical Design Wait (by time) Microseconds CONTENTION_WAIT_SCT Internal Contention Wait (by session count) Count of sessions CONTENTION_WAIT_TIME Internal Contention Wait (by time) Microseconds PSERVICE_WAIT_SCT Process Service Wait (by session count) Count of sessions PSERVICE_WAIT_TIME Process Service Wait (by time) Microseconds NETWORK_MSG_WAIT_SCT Network 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_SCT Operating System Service Wait (by session count) Count of sessions OS_SERVICE_WAIT_TIME Operating System Service Wait (by time) Microseconds DBR_IO_LIMIT_WAIT_SCT Resource Mgr I/O Limit Wait (by session count) Count of sessions DBR_IO_LIMIT_WAIT_TIME Resource Mgr I/O Limit Wait (by time) Microseconds DBR_CPU_LIMIT_WAIT_SCT Resource Mgr CPU Limit Wait (by session count) Count of sessions DBR_CPU_LIMIT_WAIT_TIME Resource Mgr CPU Limit Wait (by time) Microseconds DBR_USR_LIMIT_WAIT_SCT Resource Mgr User Limit Wait (by session count) Count of sessions DBR_USR_LIMIT_WAIT_TIME Resource Mgr User Limit Wait (by time) Microseconds OS_SCHED_CPU_WAIT_SCT Operating System Scheduler CPU Wait (by session count) Count of sessions OS_SCHED_CPU__WAIT_TIME Operating System Scheduler CPU Wait (by time) Microseconds CLUSTER_MSG_WAIT_SCT Cluster Messaging Wait (by session count) Count of sessions CLUSTER_MSG_WAIT_TIME Cluster Messaging Wait (by time) Microseconds JKSPARK@HANAFOS.COM 106
  • 107. http://www.ggola.com 장 경 상 OTHER_WAIT_SCT Other Waits (by session count) Count of sessions OTHER_WAIT_TIME Other Waits (by time) Microseconds ENQUEUE_TIMEOUTS_SEC Enqueue Timeouts (for each second) Timeouts for each Second ENQUEUE_TIMEOUTS_TXN Enqueue Timeouts (for each transaction) Timeouts for each Transaction ENQUEUE_WAITS_SEC Enqueue Waits (for each second) Waits for each Second ENQUEUE_WAITS_TXN Enqueue Waits (for each transaction) Waits for each Transaction ENQUEUE_DEADLOCKS_SEC Enqueue Deadlocks (for each second) Deadlocks for each Second ENQUEUE_DEADLOCKS_TXN Enqueue Deadlocks (for each transaction) Deadlocks for each Transaction ENQUEUE_REQUESTS_SEC Enqueue Requests (for each second) Requests for each Second ENQUEUE_REQUESTS_TXN Enqueue Requests (for each transaction) Requests for each Transaction DB_BLKGETS_SEC DB Block Gets (for each second) Gets for each Second DB_BLKGETS_TXN DB Block Gets (for each transaction) Gets for each Transaction CONSISTENT_GETS_SEC Consistent Gets (for each second) Gets for each Second CONSISTENT_GETS_TXN Consistent Gets (for each transaction) Gets for each Transaction DB_BLKCHANGES_SEC DB Block Changes (for each second) Changes for each Second DB_BLKCHANGES_TXN DB Block Changes (for each transaction) Changes for each Transaction CONSISTENT_CHANGES_SEC Consistent Changes (for each second) Changes for each Second CONSISTENT_CHANGES_TXN Consistent Changes (for each transaction) Changes for each Transaction SESSION_CPU_SEC Database CPU (for each second) Microseconds for each Second SESSION_CPU_TXN Database CPU (for each transaction) Microseconds for each Transaction CR_BLOCKS_CREATED_SEC CR Blocks Created (for each second) Blocks for each Second CR_BLOCKS_CREATED_TXN CR Blocks Created (for each transaction) Blocks for each Transaction CR_RECORDS_APPLIED_SEC CR Undo Records Applied (for each second) Records for each Second CR_RECORDS_APPLIED_TXN CR Undo Records Applied (for each transaction) Records for each Transaction RB_RECORDS_APPLIED_SEC Rollback Undo Records Applied (for Records for each Second JKSPARK@HANAFOS.COM 107
  • 108. http://www.ggola.com 장 경 상 each second) RB_RECORDS_APPLIED_TXN Rollback Undo Records Applied(for each transaction) Records for each Transaction LEAF_NODE_SPLITS_SEC Leaf Node Splits (for each second) Splits for each Second LEAF_NODE_SPLITS_TXN Leaf Node Splits (for each transaction) Splits for each Transaction BRANCH_NODE_SPLITS_SEC Branch Node Splits (for each second) Splits for each Second BRANCH_NODE_SPLITS_TXN Branch Node Splits (for each transaction) Splits for each 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_SEC Downgraded Parallel Operations (for each second) Operations for each Second PX_DOWNGRADED_25_SEC Downgraded to 25% and more (for each second) Operations for each Second PX_DOWNGRADED_50_SEC Downgraded to 50% and more (for each second) Operations for each Second PX_DOWNGRADED_75_SEC Downgraded to 75% and more (for each second) Operations for each Second PX_DOWNGRADED_SER_SEC Downgraded to serial (for each second) Operations for each Second BLOCKED_USERS Number of Users blocked by some Session Number of Users PGA_CACHE_HIT PGA Cache Hit (%) % bytes processed in PGA ELAPSED_TIME_PER_CALL Elapsed time for each user call for each service Microseconds for each call CPU_TIME_PER_CALL CPU 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를 적용 JKSPARK@HANAFOS.COM 108 표 7-19 Threshol d 연산자
  • 109. http://www.ggola.com 장 경 상 하지 않는다 OPERATOR_EQ threshold와 같다. (=) OPERATOR_GE threshold와 크거나 같다. (>=) OPERATOR_GT threshold보다 크다. (>) OPERATOR_LE threshold와 작거나 같다. (<=) OPERATOR_LT threshold보다 작다. (<) OPERATOR_NE threshold와 다르다 (<>, !=) 3. object types (현재 지원되는 metrics는 그 list를 표시한다) Object Type Description OBJECT_TYPE_SYSTEM system level (대부분의 instance metrics) OBJECT_TYPE_FILE file level 1. AVERAGE_FILE_READ_TIME, 2. AVERAGE_FILE_WRITE_TIME OBJECT_TYPE_SERVICE service level 1. ELAPSED_TIME_PER_CALL 2. CPU_TIME_PER_CALL OBJECT_TYPE_TABLESPACE tablespace level 1. TABLESPACE_PCT_FULL OBJECT_TYPE_EVENT_CLASS 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 109 표 7-20 설정가능 한 Object
  • 110. http://www.ggola.com 장 경 상 빨갛게 표시된 box에 alerts의 내용들이 나타난다. 2. 다음은 위 화면의 하단에 있는 “측정 단위 관리”를 선택하여 현재 metric과 threshold 를 확인하는 화면이다. 여기서 좌측의 metrics과 우측의 operator 및 warning, critical value를 확인할 수 있다. 3. 다음은 위 화면에서 우측의 “임계값 편집”을 선택하여 원하는 값을 설정하는 화면이 다. (앞서 설명한 dbms_server_alert package를 사용하는 것 보다 훨씬 쉽다) JKSPARK@HANAFOS.COM 110 그림 7-26 Alert와 Threshol d 그림 7-28 Threshol d 설정 그림 7-27 Threshol d 확인
  • 111. 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 111 그림 7-30 Alert와 링크 그림 7-29 Multiple Threshol d 설정
  • 112. 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 112 그림 7-31 Metric과 링크 그림 7-32 Alert Notificati on
  • 113. 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', - > subscriber => aq$_agent('USRMON_AGT', '', 0)); JKSPARK@HANAFOS.COM 113
  • 114. http://www.ggola.com 장 경 상 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; dbms_aq.dequeue(queue_name => 'SYS.ALERT_QUE', dequeue_options => u_dequeue_options, message_properties => u_message_properties, JKSPARK@HANAFOS.COM 114
  • 115. http://www.ggola.com 장 경 상 payload => u_message, msgid => u_message_handle); -- print the alerts message dbms_output.put_line('Dequeued alert message'); dbms_output.put_line('O_ID : ' || u_message.organization_id); dbms_output.put_line('C_ID : ' || u_message.component_id); dbms_output.put_line('MSG Type : ' || u_message.message_type); dbms_output.put_line('MSG Group : ' || u_message.message_group); dbms_output.put_line('MSG Level : ' || u_message.message_level); dbms_output.put_line('Host ID : ' || u_message.host_id); dbms_output.put_line('Host Network Addr : ' || u_message.host_nw_addr); dbms_output.put_line('Reason: ' || dbms_server_alert.expand_message(userenv('LANGUAGE'), u_message.message_id, u_message.reason_argument_1, u_message.reason_argument_2, u_message.reason_argument_3, u_message.reason_argument_4, u_message.reason_argument_5)); dbms_output.put_line('SEQ : ' || u_message.sequence_id); dbms_output.put_line('Reason ID : ' || u_message.reason_id); dbms_output.put_line('OBJ Name : ' || u_message.object_name); dbms_output.put_line('OBJ Type : ' || u_message.object_type); dbms_output.put_line('Inst Name : ' || u_message.instance_name); dbms_output.put_line('Suggested : ' || dbms_server_alert.expand_message(userenv('LANGUAGE'), u_message.suggested_action_msg_id, u_message.action_argument_1, u_message.action_argument_2, u_message.action_argument_3, u_message.action_argument_4, u_message.action_argument_5)); dbms_output.put_line('Advisor : ' || u_message.advisor_name); dbms_output.put_line('Scope : ' || u_message.scope); end; / SYSTEM> set serveroutput on SYSTEM> @get_alert Dequeued alert message JKSPARK@HANAFOS.COM 115
  • 116. http://www.ggola.com 장 경 상 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 116
  • 117. 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 117
  • 118. 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 118
  • 119. 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 119
  • 120. 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 120
  • 121. 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’); CF. oracle관련 문서에 따르면 procedure를 “gather_schema_stats(‘SYS’)”처럼 call해도 JKSPARK@HANAFOS.COM 121
  • 122. http://www.ggola.com 장 경 상 같은 위와 같이 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 122
  • 123. 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) AUTO Orcle10g의 new default이며 partition type에 따라 다르게 수집 JKSPARK@HANAFOS.COM 123 그림 7-33 System 통계와 권 한 표 7-21 통계수집 의 Option
  • 124. http://www.ggola.com 장 경 상 (subpartition이 LIST이면 global, partition 및 subpartition 통계 를 그렇지 않으면 global 및 partition 통계를 수집) GLOBAL global 통계를 수집 GLOBAL AND PARTITION subpartition의 유무와 상관없이 global, partition 통계를 수집 PARTITION partition 통계를 수집 SUBPARTITION subpartition 통계를 수집 CF. 과거 사용하던 “DEFAULT”라는 option은 obsolete되었고 이 값은 “GLOBAL AND PARTITION”과 같다. 2. DEGREE의 값으로 oracle10g부터 “auto_degree”가 추가되었다. 이 argument 값들의 의미를 살펴보자. Values Description ? 사용자가 지정하는 값을 적용 NULL default로 적용되며 table에 설정된 degree 값을 적용 DEFAULT_DEGREE CPU의 수와 initial parameter의 값을 기준으로 설정되는 system default값을 적용 AUTO_DEGREE oracle이 스스로 판단하되 대상 object의 size에 따라 1 또는 default_degree를 적용 CF. 여러분이 특별하게 dbms_stats를 통한 통계수집의 적절한 방법을 가지고 있지 않다 면 granularity의 default “auto”와 degree의 새로운 값 “auto_degree”를 사용해 보기 바 란다. 7.7.3. Optimizer Mode의 변화 Oracle10g는 더 이상 RBO(Rule Based Optimizer) mode의 optimizer를 지원하지 않는 다. 이 말은 곧 initial parameter optimizer_mode의 값에 변화를 준다. RBO가 더 이상 유 효하지 않음으로(오직 CBO만 사용함으로) 이 parameter의 값으로 “CHOOSE”나 “RULE” 모두 사용하지 않는다는 의미가 된다. 이 값의 default는 “all_rows”로 설정된다. 뻔한 이야기지만 oracle10g가 통계정보의 수집을 자동화했기 때문에 이러한 변화는 당연 한 것이다. CF. 여러분이 여전히 “CHOOSE”, “RULE” 혹은 rule hint를 사용한다고 error가 return 되지는 않는다. 그 기능들은 내부적으로 존재하지만 oracle10g부터는 이러한 optimizer 의 판단에 따른 bug나 새로운 기법 등을 전혀 제공하지 않으며 차후 version에서는 아예 사라질 것이다. (desupported values) JKSPARK@HANAFOS.COM 124
  • 125. http://www.ggola.com 장 경 상 다음은 현재의 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 125
  • 126. 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 126
  • 127. 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의 대상이 되 기 이전에 이미 해결이 되는 경우가 대부분이고 그 외의 것들이 항상 숙제로 남아 DBA의 능력을 시험대에 오르게 하기 때문이다. Oracle10g는 이러한 일련의 manual tuning 작업 JKSPARK@HANAFOS.COM 127 표 7-22 Optimize r Mode
  • 128. http://www.ggola.com 장 경 상 의 어려움을 극복할 수 있도록 도와주는 features를 소개하고 있다. Oracle10g는(앞서도 설명했지만) ADDM을 통해 문제가 예상되는 SQL을 감지하여 DBA 에게 보여주고 이를 advisor와 연결하여 automatic tuning을 지원하는 일련의 체계를 가 지고 있다. 이는 다른 자동 tuning features와 마찬가지로 Top-Down(Drill 방식)형식의 접근을 가능하게 함으로 DBA에게 많은 도움을 줄 수 있도록 SQL tuning advisors를 제 공한다. 그러나 자주 변화하고 배포되는 새로운 application나 SQL은 SQL workload를 끊임없이 변화시키기 때문에 계속적으로 반복되는 감시와 tuning은 여전히 매우 중요하 며 많은 resource들(CPU, I/O, temporary space등)을 점유하는 SQL을 판단하는 것 역시 DBA의 주요 관심사가 되어야 한다. SQL tuning advisor는 SQL을 input으로 받아서 다음과 같은 결과물을 생산한다. 1. execution plan을 어떻게 optimizing해야 하는가 2. advisor가 제안을 하는 이유는 무엇인가 3. 성능측면의 이점들을 측정한 결과 4. advisor의 제안을 구현할 command CF. tuning mode에서 optimizer의 SQL에 대한 분석은 적지 않은 시간을 소요하게 된다. 따라서 tuning에 필요한 SQL을 감지하여 선택적으로 분석하는 능력과 advisor가 제시하 는 action에 대한 해독능력 또한 DBA의 주요 능력이 될 것이다. 이런 기능들을 종합해서 판단해 볼 때(필자가 보기엔), 적어도 이러한 종류의 oracle10g의 새로운 기능들은 DBA 를 편하게 해주기는 하지만 전문성이 부족한 DBA를 눈감아주는 것은 아니라고 생각된 다. 7.8.2. SQL Tuning Advisor SQL tuning advisor는 optimizer를 ATO로 invoke하여 필요한 분석을 수행하게 하는 driver와 같은 역할을 한다. 여기에서 분석하는 내용들은 다음과 같이 크게 4가지로 구분 되는데 통계분석, SQL Profile, Access 경로분석, SQL 구조분석이 그것이다. 이제 그 각각 의 의미와 쓰임새에 대해 알아보자. 7.8.2.1. 통계분석 (Statistics Analysis) 이 작업은 query의 대상이 되는 objects의 통계 값이 잘못되거나 빠진 것이 없는가를 검증 하는 부분이다. 이 작업에서 ATO는 스스로 sampling한 data를 이용하여 현재 존재하는 통계 값들을 검증하고 다음의 두 가지 유형의 결과물을 생성한다. 1. 문제가 있는(missing(no statistics) or stale(실효성이 없는) statistics를 가진) objects에 대하여 적절한 통계 수집의 필요성을 권고 2. 권고사항이 이행되지 않는 경우 이를 보완하기 위해 통계자료의 형태로 보조정보 JKSPARK@HANAFOS.COM 128
  • 129. http://www.ggola.com 장 경 상 (auxiliary information)를 생성 (이 data는 다음에 설명하는 SQL profile에 저장된다) DBA는 위 작업 권고사항에 따라 적절한 시점에 통계수집을 다시 수행할 필요성이 있는 가를 판단해야 한다. 그리고 필요하다면 통계수집을 다시 한 후에 해당 SQL에 대한 분석 을 다시 수행할 필요가 있는지를 결정한다. CF. ATO는 dynamic sampling을 사용한다. 7.8.2.2. SQL Profile 이 단계에서는 optimizer가 판단하고 있는 대상 SQL의 비용, 선택성, cardinality를 검증 하게 된다. ATO의 이런 작업은 optimizer estimates(optimizer가 SQL을 분석하여 측정 하고 판단한 결과)의 정확도를 검증하고 오류의 가능성을 제거하거나 줄여준다. 이 검증작업은 ATO가 dynamic sampling을 통해 생성한 새로운 estimate와 원래의 estimate를 비교하여 차이가 크다면 원래의 estimate에서 수정할 부분을 만들어내는 sampling method와 대상 SQL을 나누어 수행하여 estimate를 검증하는 partial execution method가 있다. Oracle은 스스로 적절한 method를 선택하게 되는데 만일, partial execution의 개별 access paths가 효율적이면 sampling method보다 partial execution method가 더 효과적일 수 있다. ATO는 통계분석 단계에서(또는 이 단계에서) 보조정보(auxiliary information)가 생성되 었으면 SQL profile을 build하고 profile을 만들기 위해 사용자를 위한 권고사항을 만든다. CF. ATO의 검증작업에서는 대상 SQL의 과거 execution history를 살펴보고 적절한 optimizer mode의 설정을 결정할 수도 있다. 이렇게 ATO가 진행되는 동안 생성되는 auxiliary information이 모아지면 이 정보들이 SQL profile이라는 이름으로 저장된다. 우리가 access하는 통계 값들이 table이나 index 로부터 계산되는 것처럼 SQL profile은 문제가 되는 SQL문장으로부터 만들어지기 때문 에 이 profile은 매우 중요한 역할을 할 수 있다. 이 profile의 결과가 DBA가 받아들일 수 있다고 판단되면 그 때 data dictionary로 저장되 고 일반 사용자가 종전과 다름없이 해당 SQL(혹은 application)을 call할 때 optimizer는 대상 SQL을 compile하면서 이미 만들어진 profile을 사용하게 된다. 그 결과 잘 tuning된 execution plan으로 SQL이 수행될 수 있는 것이다. 이 점이 매우 중요한 이유는 사용자는 어떤 변경도 없이 동일한 작업을 하고 application의 변화도 없지만 성능의 향상이 이루 JKSPARK@HANAFOS.COM 129
  • 130. http://www.ggola.com 장 경 상 어질 수 있기 때문이다. CF. 그렇다면 이 기능은 어떤 경우에 가장 효과적일까. 여러 유형의 database를 관리해본 사람이면 package로 들여온 system에서 문제가 발생하고 있는 application code를 잡아 내고(detect) 이를 수정하고자 했던 경험이 있을 것이다. 이런 package 형태의 system을 tuning하기는 쉽지가 않다. 이제 여러분은 oracle10g를 이용하여 package내 SQL의 최적 화된 tuning plan을 만들어보시기 바란다. CF. 이는 마치 oracle8i에서 소개된 stored outline을 연상케 한다. 물론, profile이 만들어진다고 해도 index의 추가 또는 삭제, table size의 변화 등에 따라 plan이 변경될 수도 있다. 그러나 database에 매우 큰 변화가 생기거나 오랫동안 누적된 변화로 인해 발생하는 예기치 못한 상황이 발생하면 이 profile의 data도 다시 refresh할 (new profile로 다시 만들) 필요가 있다. 이쯤 되면 ADDM에 의해 해당 SQL이 다시 bad SQL로 나타날 것이다. 역시나 반복적인 tuning이 항상 중요함을 잊지 말자. 다음은 현재 설명한 profile과 optimizer의 처리를 도식화한 것이다. 7.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를 통해 이루어진다) JKSPARK@HANAFOS.COM 130 그림 7-34 Optimize r와 SQL Profile
  • 131. http://www.ggola.com 장 경 상 CF. ATO의 access path분석은 필요한 index에 대한 권고 혹은 전체적인 분석을 위해 SQL access advisor를 수행할 것을 권고하게 된다. 하지만 이런 index에 대한 분석은 database 전반에 걸쳐 전체 SQL workload상황에서 분 석하는 것이 아니기 때문에 새로운 index 사용으로 인한 영향이 다른 부분에 걸쳐서 악영 향을 줄 수도 있는지는 판단하지 못한다. 그렇기 때문에 제대로 access advisor를 사용하 기 위해서는 현재 운영하는 database의 대표적인 SQL workload에서 분석을 하는 것이 중요할 수 있다. 이렇게 되면 access advisor는 workload 전반에 걸쳐서 통합된 recommend를 해 준다. CF. 이미 AWR은 workload 정보를 가지고 있음으로 access paths분석을 할 때 필요하다 면 대표적인 시간대의 workload를 지정하여(나중에 설명이 되지만 SQL Tuning Set을 만 들어 사용한다) 분석을 수행할수록 보다 정확한 정보를 얻을 수 있다. 7.8.2.4. SQL 구조 분석(Structure Analysis) DBA는 SQL을 tuning할 때 먼저 그 구조를 파악하게 된다. 물론, 간단할 수도 있지만 대 부분 data의 성격을 제대로 알면 SQL의 내용은 바꾸지 않고 형식의 변화만 주어도 상당 한 효과를 보는 경우가 많다. 가장 대표적인 것이 where절의 column에 대한 type 변경 function으로 인해 index를 사용하지 못하거나 불필요한 “union”절의 사용 혹은 불필요 한 “not in”등을 사용하는 경우이다. 사실 이런 문제들은 type의 변환을 column이 아닌 값으로 “union”대신 “union all”절로, 그리고 “not in”대신 “not exists”로 바꾸어도 효과 를 볼 수 있는 경우가 있다. 물론, 출력되는 data에 대하여 지식이 있어야만 가능한 일이 다. ATO는 이런 유형의 문제들을 해결하기 위하여 SQL structure analysis를 소개하고 있다. 이 기능은 잘못 쓰여진 SQL을 감지하고 rewrite를 권고하는 기능이다. 말 그대로 권고이 다. 즉, 자동으로 rewrite를 해주지는 않는다는 뜻이다. 왜냐하면 바로 언급했듯이 “union all”과 “union”, “not in”과 “not exists”가 비슷하기도 하지만 확실히 다른 결과를 줄 수 도 있기 때문이다. 따라서 여전히 DBA는 관련 data에 대한 속성을 이해하고 있어야만 한 다. 그렇지 않으면 이런 훌륭한 권고사항도 이해하지 못하고 넘어가는 수 밖에는 없다. 이를 정리해보면 다음과 같다. 1. 의미론적인 문제(semantic) : 앞서 예로 든 “union”과 “union all” 그리고 “not in”과 “not exists”와 같은 것들이다. 2. 문법적인 문제(syntax) : 앞서 예로 든 column의 형 변환 function의 사용과 같은 것들 JKSPARK@HANAFOS.COM 131
  • 132. http://www.ggola.com 장 경 상 이다. 또 한가지 예를 들자면 varchar2 type의 column A와 비교하기 위해 “where A = 5” 와 같이 사용하게 되면 A는 index가 있더라도 to_number(A)로 변환이 될 것임으로 index를 사용하지 못하게 된다. 3. design의 문제 : 이는 SQL을 사용하는데 있어 발생하는 cartesian products와 같은 것 들이다. SQL을 작성하면서 많은 수의 table을 join하는 경우 가끔씩 특정 table을 join에서 제외하는 경우가 있는데 이런 경우를 뜻한다. 7.8.3. Tuning SQL (Using em) 7.8.3.1. SQL Tuning Set 앞서 설명한 바 tuning이 필요한 SQL을 input으로 하여 ATO를 가동하는 과정이 SQL을 tuning하는 일반 절차이다. 그러나 대상이 되는 SQL은 매우 다양한 source로부터 추출될 수 있고 또한 하나 이상의 SQL을 묶어서 처리하는 것이 보다 효율 적이다. 그래서 oracle10g는 새로운 object인 STS(SQL Tuning Set)를 통해 특정 SQL들을 묶어서 저장해 준다. 따라서 이 STS를 가지고 ATO를 가동하는 것이 합리적이다. STS는 각 SQL의 execution context(parsing schema, bind variables, application module name과 action, cursor 환경), execution statistics(수행시간, CPU시간, buffer gets, disk reads, rows processed, 수행횟수, 완전히 수행된 횟수, cursor fetches, optimizer cost, command type)를 가지고 저장하며 다음과 같은 sources로부터 추출될 수 있다. 1. ADDM에 의해 나타난 high load SQL 2. 현재 상태에서 추출되는 SQL 3. AWR에서 추출되는 SQL (snapshot이나 baseline을 사용할 수 있다) 4. 사용자 지정 SQL (사용자가 원하는 SQL을 가지는 custom workload를 만들어 사용할 수 있다. 따라서 이 경우에 나타나는 SQL는 AWR이나 ADDM에서 high load로 나타나지 않을 수도 있다) 따라서 보통 다음과 같은 절차를 통해 Automatic SQL tuning이 진행된다. 1. 다양한 source로부터 SQL을 추출 2. execution statistics를 가지고 추출된 SQL들을 filtering및 raking처리 3. 주요 SQL들을 묶어서 STS로 저장 4. SQL Tuning Advisor에게 tuning을 의뢰 5. tuning 결과를 분석하여 적용 CF. 물론, STS가 아닌 SQL을 input으로 개별적인 tuning도 가능하다. 다만 STS object를 만드는 것은 여러 SQL들을 효율적으로 묶어서 tuning하기 위한 매우 좋은 방법이 될 수 있다. JKSPARK@HANAFOS.COM 132
  • 133. http://www.ggola.com 장 경 상 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 133 그림 7-35 em SQL Tuning Advisor
  • 134. 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 134 그림 7-36 em SQL Tuning Advisor
  • 135. http://www.ggola.com 장 경 상 7.8.3.3. STS 생성 위 Top SQL 화면에서 몇 개의 SQL을 가지고 STS를 만들어 보자. 다음과 같이 주요 SQL 을 선택해 보자. STS 생성 버튼을 누르면 다음과 같다. JKSPARK@HANAFOS.COM 135 그림 7-37 em SQL Tuning Advisor 그림 7-38 SQL Tuning Set 설정 그림 7-39 SQL Tuning Set 생성
  • 136. 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 136 그림 7-40 SQL Tuning Set 생성
  • 137. http://www.ggola.com 장 경 상 상단에는 분석대상이 되는 SQL이 나오고 하단에는 다음과 같은 화면을 볼 수 있다. 위 화면에서 scope의 “Limited…”는 앞서 설명한 ATO가 실시하는 각종 분석작업을 통 해 tuning을 하겠다는 의미이고 “Comprehensive…”는 “Limited…”에 추가적으로 SQL Profile을 만들겠다는 뜻이다. 그리고 하단의 schedule은 지금 tuning을 실시할 것인지 아 니면 시간을 지정하여 차후에 적절한 시간에 schedule을 통해 수행할 것이라는 의미이 다. 일단 위와 같이 default 상태에서 tuning을 실시해보자. 우측 하단의 “OK”버튼을 눌 러보자. JKSPARK@HANAFOS.COM 137 그림 7-41 SQL List 그림 7-42 SQL Tuning Option
  • 138. 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 138 그림 7-43 SQL Tuning 결과 그림 7-44 SQL Tuning 추천결과
  • 139. 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%'; TXT SQL_ID LAST_LOAD_TIME JKSPARK@HANAFOS.COM 139
  • 140. http://www.ggola.com 장 경 상 ------------------------------------------ ----------------------- -------------------- 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 ---------------------------------------------------- SYSTEM> set long 1000000 pagesize 0 longchunksize 1000 JKSPARK@HANAFOS.COM 140
  • 141. http://www.ggola.com 장 경 상 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 -------------------------------------------- ------------------------------ SYS_SQLPROF_050905141344965 DEFAULT JKSPARK@HANAFOS.COM 141
  • 142. http://www.ggola.com 장 경 상 현재 위 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 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 JKSPARK@HANAFOS.COM 142
  • 143. http://www.ggola.com 장 경 상 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 .... .... ------------------------------------------------------------------------------- There are no recommendations to improve the statement. .... .... ------------------------------------------------------------------------------- JKSPARK@HANAFOS.COM 143
  • 144. http://www.ggola.com 장 경 상 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. SYSTEM> print :sprfile SPRFILE -------------------------------------------------------------------------------- JKSPARK@HANAFOS.COM 144
  • 145. http://www.ggola.com 장 경 상 1st_profile_advice 위 작업은 권고사항을 적용하는 function에서 추가적으로 “name” argument를 사용하여 system이 만들어주는 알아보기 힘든 profile의 이름 대신에 사용자가 직접 입력하는 이름 으로 profile을 생성하여 accept한 것이다. CF. profile의 accept를 위해 “CREATE ANY SQL PROFILE”권한이 필요하다. 7.8.5.2. Profile Category 앞서 profile을 검색하고 drop할 때 나타났던 category를 상기하자. 이 category는 현재 session 혹은 system의 SQL category와 연관이 있다. 다음의 SQL결과를 보자. SYSTEM> select value from v$parameter 2 where name = 'sqltune_category'; VALUE -------------------------------------------------------------------------------- DEFAULT 위 결과는 앞서 dba_sql_profiles에서 나타난 category의 값과 동일하다. 즉, 현재 SQL은 “DEFAULT”라는 category에서 적용된다는 의미이다. 사실 아무런 지정을 하지 않으면 default로 “DEFAULT” category가 적용된다. 즉, 위에서 profile의 accept를 할 때 category argument를 지정하여 자신이 원하는 category로 해당 profile을 저장할 수도 있 다는 말이다. 이 category는 session 혹은 system level에서 어떤 SQL profile을 적용할 것인가를 결정 하게 된다. 따라서 여러분이 위 profile을 “ XTEST”라는 이름으로 accept했다면 현재의 “DEFAULT” category 상태에서는 tuning의 효과를 볼 수가 없게 된다. 반대로 현 재 sqltune_category가 “XTEST”라면 위에서 accept한 profile은 사용할 수가 없다는 뜻이 된다. 만일 그런 상황이면 다음과 같이 profile을 수정할 수 있다. 7.8.5.3. Profile 수정 위에서 언급한 category의 수정은 다음과 같다. SYSTEM> exec dbms_sqltune.alter_sql_profile(- > '1st_profile_advice', 'CATEGORY', 'XTEST'); PL/SQL procedure successfully completed. JKSPARK@HANAFOS.COM 145
  • 146. http://www.ggola.com 장 경 상 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”권한 이 필요하다. 먼저 만들어 보자. SYSTEM> exec dbms_sqltune.create_sqlset('X10G_STS', 'FromAWR'); PL/SQL procedure successfully completed. 위 내용은 “X10G_STS”라는 이름의 STS object를 만들고 그 설명으로 “FromAWR”을 입 JKSPARK@HANAFOS.COM 146
  • 147. http://www.ggola.com 장 경 상 력한 결과이다. 이제 만들어진 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 / PL/SQL procedure successfully completed. 위 작업은 workload repository에 있는 baseline “1st_oltp_baseline”의 SQL을 추출하여 STS “X10G_STS”로 load를 하되 조건으로 실행 횟수가 6회 이상인 것을 대상으로 load한 것이다. JKSPARK@HANAFOS.COM 147
  • 148. http://www.ggola.com 장 경 상 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 이 결과는 위에서 지정한 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'); JKSPARK@HANAFOS.COM 148
  • 149. http://www.ggola.com 장 경 상 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'; 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 JKSPARK@HANAFOS.COM 149
  • 150. http://www.ggola.com 장 경 상 tuning의 절차에서 indexes나 MView, MView log등에 대한 oracle의 recommend 사항 을 독립적으로 접근할 수 있기 때문이다. ATO의 마지막 과정으로 SQL access advisor를 살펴보자. CF. 앞서 보았지만 SQL tuning advisor는 dbms_sqltune package를 사용해왔다. 하지만 SQL access advisor는 dbms_advisor package를 사용한다. CF. SQL access advisor를 사용하려면 “ADVISOR”권한이 있어야 한다. 7.8.7.1. 대상 SQL SQL access advisor를 사용하기 위해 input data로 사용되는 SQL들은 다음과 같은 방식 이 가능하다. 물론, 이런 방식들은 실제로 사용되는 advisor인 dbms_advisor package의 sub procedure를 통해 이루어진다. 1. 현재 SQL cache에서 즉, v$sql을 이용하는 방법: dbms_advisor.import_sqlwkld_sqlcache 2. 사용자가 정의하는 workload table을 이용하는 방법(여기서 사용하는 table은 최소한 SQL_TEXT, USERNAME column을 가지고 있어야 한다) : dbms_advisor.import_sqlwkld_user 3. hypothetical 방식 (이것은 특정 schema나 table을 지정한다) : dbms_advisor.import_sqlwkld_schema 4. STS(SQL Tuning Set)을 이용하는 방법 : dbms_advisor.import_sqlwkld_sts CF. 위에서 2번째 방식인 user-defined workload라 함은 사용자가 access 분석을 하고 싶 은 SQL을 모아 이를 하나의 workload로 간주하여 SQL access advisor의 source로 사용 하고자 할 때 사용하는 방식이다. 이 방식은 사용자가 필요에 추출한 SQL문들 뿐만 아니 라 아직 database에 반영되지 않은 application의 SQL도 미리 점검할 수 있는 방안이 될 수 있다. 즉, DBA는 이런 기능을 얼마나 적절히 사용할 수 있는가도 중요한 임무이다. 다 음은 사용자 정의 workload table(일명 user_workload라 칭한다)의 구성요소 이다. 이미 언급했지만 필수 columns은 sql_text(CLOB, LOGN, VARCHAR2)와 username(VARCHAR2(30))이고 다른 columns의 생성여부는 option이다. Column Data Type Default Description MODULE VARCHAR2(64) empty string application module name ACTION VARCHAR2(64) empty string application action BUFFER_GETS NUMBER 0 전체 buffer-gets CPU_TIME NUMBER 0 전체 CPU time (sec) ELAPSED_TIME NUMBER 0 전체 수행 시간 (sec) JKSPARK@HANAFOS.COM 150 표 7-23 SQL 정보 List
  • 151. http://www.ggola.com 장 경 상 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를 해주는 full(comprehensive) mode와 단순히 SQL문에 대한 advice를 해주는 partial(limited) mode가 있다. 1. comprehensive : 주어진 workload의 전체적인 분석을 실시하여 권장사항을 만들어 준 다. 이 경우엔 주어진 workload가 전체 database활동에서 사용되는 application의 SQL set(전체 혹은 대표성을 갖는 SQL 모음)이라고 가정하게 된다. 2. limited : 주어진 workload에 SQL은 문제가 있는 SQL이라 가정하고 권장사항을 만든 다. 따라서 이러한 분석의 결과는 특정 application의 일부에 대한 성능향상을 위한 권장 사항이 된다. 다음은 위 두 mode사이의 분석 결과에 어떤 차이가 있는지를 보여준다. 권장사항 Comprehensive Limited JKSPARK@HANAFOS.COM 151 표 7-24 SQL Access 분 석 Mode
  • 152. http://www.ggola.com 장 경 상 새로운 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. SYSTEM> commit; Commit complete. 현재는 계정 scott의 table중 첫 번째 column이 number인 table에 대하여 summary를 하 는 SQL을 무작위로 만들어서 등록을 하였다. 실무에서는 이 SQL들이 실제로 application 에서 사용되는 혹은 사용할 SQL들이어야 할 것이다. 지금 진행하는 작업은 현재 필자의 database에서 이루어 지고 있음으로 여러분 각자가 사 용하는 database에서는 다른 결과가 나올 것이다. 그러나 아래 step은 모두 동일하며 다 만 마지막 권고사항에 대한 결과와 그 내역만 다를 것이다. JKSPARK@HANAFOS.COM 152
  • 153. http://www.ggola.com 장 경 상 이제 em에서 작업을 위해 먼저 advisor central화면으로 이동하자. SQL Access Advisor를 선택하면 다음화면으로 이동하여 작업을 시작할 수 있다 . Step #1 : 여기서 앞서 설명한 여러 유형의 SQL source를 선택한다 현재는 user-defined workload를 선택하여 앞서 생성한 table을 지정했다. 좌측 하단에 option을 선택하면(여러분이 필요하다면 수행하라) 다음 화면이 나타난다. JKSPARK@HANAFOS.COM 153 그림 7-45 em Advisor Central 그림 7-46 SQL Access Advisor
  • 154. http://www.ggola.com 장 경 상 이 화면에서는 여러 분석유형 및 filtering 조건을 줄 수 있다. 현재 테스트를 위해 만들어 진 user-defined workload “X_WKLD_SCOTT”은 SQL문과 사용자 명만을 가지고 있기 때문에 위의 option 화면에서 filtering을 할 수 없을 것이다. 다음은 “Next” 버튼을 통해 두 번째 단계인 recommendation option화면으로 이동한 것 이다. Step #2 : 분석 유형을 선택한다 JKSPARK@HANAFOS.COM 154 그림 7-47 SQL Access Advisor
  • 155. http://www.ggola.com 장 경 상 여기서 index와 MView 혹은 둘 다 분석할 것인가를 선택하고 앞서 설명한 분석 유형인 limited와 comprehensive중에서 하나를 선택한다. 좌측 하단의 option을 선택하면(역시 필요하다면 선택하라) 다음과 같은 창을 볼 수 있다. 여기서는 분석 결과에 대한 용량제한, tuning option(buffer gets과 같은 통계 선택), 분석 결과에 나타나는 storage option의 default값 들을 조정할 수 있다. 이제 다음 단계로 이동을 위해 “Next”를 선택하면 schedule 창이 나타난다. Step #3 : 분석 schedule을 정의한다 JKSPARK@HANAFOS.COM 155 그림 7-48 SQL Access Advisor 그림 7-49 SQL Access Advisor
  • 156. http://www.ggola.com 장 경 상 이 단계는 access advisor가 언제 분석 작업을 수행할 것인가를 설정한다. 미리 정의된 schedule이 없으면 위에서처럼 Standard를 선택하라. 그러면 다음과 같은 창이 하단에 추가적으로 나타난다. JKSPARK@HANAFOS.COM 156 그림 7-50 SQL Access Advisor
  • 157. http://www.ggola.com 장 경 상 이 화면에서 여러분이 직접 수행시간을 설정할 수 있다. 반복적으로 그리고 나중에 분석 작업을 수행할 수도 있다. 현재는 지금 바로 분석을 하도록 설정된 default값들을 수정하 지 않고 그대로 다음 단계로 이동한다. Step #4 : 전체적으로 분석작업에 대한 review를 한다 JKSPARK@HANAFOS.COM 157 그림 7-51 SQL Access Advisor
  • 158. http://www.ggola.com 장 경 상 이제 마지막 단계로 현재까지의 작업설정을 점검하는 화면이다. 최종적으로 “Submit”을 하면 다음과 같은 화면으로 이동한다. CF. 필요하다면 여기서 우측 상단의 “Show SQL”을 통해 이 작업들을 직접 수행할 수 있 도록 SQL code를 만들어 사용할 수도 있다. Result #1 : task를 선택하여 작업 결과를 확인한다 위 화면에는 advisor task가 만들어 졌음을 보여준다. 여기서 적절한 task를 선택한 후 중 JKSPARK@HANAFOS.COM 158 그림 7-52 SQL Access Advisor 그림 7-53 SQL Access 분 석결과
  • 159. 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 159 그림 7-54 SQL Access 분 석결과
  • 160. http://www.ggola.com 장 경 상 유지할 index와 새로 생성할 필요가 있는 index에 대해 list를 보여준다. 하단에는 이 action list로 인해 영향을 받을 수 있는 SQL 내역을 보여주고 있다. “OK”를 통해 다시 Result #2화면으로 돌아가보자. 그리고 “Show SQL” 버튼을 click하라. Result #4 : SQL scripts 생성 JKSPARK@HANAFOS.COM 160 그림 7-55 SQL Access 분 석결과
  • 161. http://www.ggola.com 장 경 상 위와 같은 종류의 권장사항을 수행할 script를 볼 수 있다. 만일, 앞서 Result #2 화면에서 tablespace와 같이 조정이 가능한 항목을 수정했다면 그 내용은 위 화면에서 그대로 반영 된다. 예를 들어 Result #2에서 tablespace를 “TOOLS”로 지정했다면 아래와 같은 결과를 볼 수 있을 것이다. JKSPARK@HANAFOS.COM 161 그림 7-56 SQL Access 분 석결과
  • 162. http://www.ggola.com 장 경 상 여러분이 이 script를 사용하여 다른 SQL session에서 필요한 작업을 해도 되지만 만일 위 script를 그대로 수행하고 싶다면 “OK” 버튼을 통해 Result #2화면으로 돌아가라. 그리고 “Schedule Implementation” 버튼을 click하라. Result #5 : 작업 schedule을 선택하라. JKSPARK@HANAFOS.COM 162 그림 7-57 SQL Access 분 석결과
  • 163. 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 2 from dba_objects JKSPARK@HANAFOS.COM 163 그림 7-58 SQL Access 분 석결과 그림 7-59 SQL Access 분 석결과
  • 164. http://www.ggola.com 장 경 상 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 6 (dbms_sqltune.select_workload_repository(1734, 1764)) X; JKSPARK@HANAFOS.COM 164
  • 165. http://www.ggola.com 장 경 상 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 SYSTEM> print :fail_row JKSPARK@HANAFOS.COM 165
  • 166. http://www.ggola.com 장 경 상 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. Step #5 : SQL access advisor task를 수행한다. SYSTEM> exec dbms_advisor.execute_task(:task_name); JKSPARK@HANAFOS.COM 166
  • 167. http://www.ggola.com 장 경 상 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% ----------- ---------- -------------- ---------------- -------------- 106 1 40536 27 99.93 107 1 27024 18 99.93 108 1 9008 6 99.93 111 1 81036 54 99.93 JKSPARK@HANAFOS.COM 167
  • 168. http://www.ggola.com 장 경 상 113 1 76517 51 99.93 112 1 18004 12 99.93 109 1 4502 3 99.93 105 2 4800 4 99.92 114 3 266 76 71.43 9 rows selected. Result #3 : 다음으로 권장사항을 수행하는데 필요한 action을 확인해 보자. SYSTEM> col action for a30 SYSTEM> select rec_id, action_id, substr(command,1,30) action 2 from dba_advisor_actions 3 where task_name = 'MANUAL_ACS_TSK001' 4 order by rec_id, action_id; REC_ID ACTION_ID ACTION ---------- ------------------ ---------------------------------------------------- 1 1 CREATE MATERIALIZED VIEW LOG 1 3 CREATE MATERIALIZED VIEW 1 4 GATHER TABLE STATISTICS 1 7 CREATE INDEX 2 1 CREATE MATERIALIZED VIEW LOG 2 5 CREATE MATERIALIZED VIEW 2 6 GATHER TABLE STATISTICS 3 8 CREATE INDEX 3 9 RETAIN INDEX 4 10 RETAIN INDEX 10 rows selected. 마지막 두 action은 index를 그대로 유지하라는 것뿐 실제 수행할 것은 없다. Result #4 : 이제 권장사항을 script로 받아 보자. 사실 여러 advisor의 결과를 SQL로 받아 보는 방법들은 앞서 oracle10g의 advisor 전반에 대하여 설명을 할 때에 다루어본 부분이 다. 여기서는 function을 통해 직접 script로 return을 받아보자. JKSPARK@HANAFOS.COM 168
  • 169. http://www.ggola.com 장 경 상 SYSTEM> select dbms_advisor.get_task_script('MANUAL_ACS_TSK001') from dual; DBMS_ADVISOR.GET_TASK_SCRIPT(' -------------------------------------------------------------------------------- Rem SQL Access Advisor: Version 10.1.0.1 - Production Rem Rem Username: SYSTEM Rem Task: MANUAL_ACS_TSK001 Rem Execution date: 06/09/2005 17:44 Rem set feedback 1 set linesize 80 set trimspool on set tab off set pagesize 60 whenever sqlerror CONTINUE CREATE MATERIALIZED VIEW LOG ON "SCOTT"."EMP2" WITH ROWID, SEQUENCE("EMP_ID","SALARY","RECOMMENDER") INCLUDING NEW VALUES; CREATE MATERIALIZED VIEW "SYSTEM"."MV$$_077B0001" REFRESH FAST WITH ROWID ENABLE QUERY REWRITE AS SELECT SCOTT.EMP2.EMP_ID C1, "SCOTT"."EMP2"."EMP_ID" M1, SUM("SCOTT"."EMP2"."SALARY") M2, COUNT("SCOTT"."EMP2"."SALARY") M3, COUNT(*) M4 FROM SCOTT.EMP2 GROUP BY SCOTT.EMP2.EMP_ID; begin dbms_stats.gather_table_stats('"SYSTEM"','"MV$ JKSPARK@HANAFOS.COM 169
  • 170. http://www.ggola.com 장 경 상 $_077B0001"',NULL,dbms_stats.auto_sample_size); end; / CREATE MATERIALIZED VIEW "SYSTEM"."MV$$_077B0000" REFRESH FAST WITH ROWID ENABLE QUERY REWRITE AS SELECT SCOTT.EMP2.RECOMMENDER C1, SCOTT.EMP2.EMP_ID C2, "SCOTT"."EMP2"."E MP_ID" M1, SUM("SCOTT"."EMP2"."SALARY") M2, COUNT("SCOTT"."EMP2"."SALARY") M3, COUNT(*) M4 FROM SCOTT.EMP2 GROUP BY SCOTT.EMP2.RECOMMENDER, SCOTT.EMP2.E MP_ID; begin dbms_stats.gather_table_stats('"SYSTEM"','"MV$ $_077B0000"',NULL,dbms_stats.auto_sample_size); end; / CREATE INDEX "SYSTEM"."_IDX$$_077B0007" ON "SYSTEM"."MV$$_077B0001" ("C1") COMPUTE STATISTICS; CREATE INDEX "WMSYS"."WM$VERSIONED_TA_IDX$$_077B0008" ON "WMSYS"."WM$VERSIONED_TABLES" ("DISABLING_VER","OWNER") COMPUTE STATISTICS; /* RETAIN INDEX "WMSYS"."WM$VERSIONED_TABLES__PK" */ /* RETAIN INDEX "WKSYS"."SYS_C001725" */ JKSPARK@HANAFOS.COM 170
  • 171. http://www.ggola.com 장 경 상 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 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 JKSPARK@HANAFOS.COM 171
  • 172. http://www.ggola.com 장 경 상 10 NEVER MODIFY INDEX 11 SET INDEX MAXIMUM COUNT 12 SET INDEX SCHEMA 13 SET INDEX TABLESPACE 14 SET MATERIALIZED VIEW SCHEMA 15 SET MATERIALIZED VIEW TABLESPACE 16 SET STORAGE SIZE 17 DROP INDEX 18 DROP MATERIALIZED VIEW 19 DROP MATERIALIZED VIEW LOG 20 RETAIN INDEX 21 RETAIN MATERIALIZED VIEW 22 RETAIN MATERIALIZED VIEW LOG 23 CREATE SUB MATERIALIZED VIEW 24 DROP SUB MATERIALIZED VIEW 25 CREATE REWRITE EQUIVALENCE 26 DROP REWRITE EQUIVALENCE 27 ALTER MATERIALIZED VIEW LOG 28 GATHER TABLE STATISTICS 29 GATHER INDEX STATISTICS 30 SET UNDO_RETENTION 31 SET UNDO TABLESPACE SIZE 32 ACCEPT SQL PROFILE 33 REWRITE QUERY 34 RUN SEGMENT ADVISOR 35 ALTER PARAMETER 36 SHRINK SPACE 37 rows selected. CF. 위 결과를 보면 access advisor를 통해 SQL을 사용하여 직접 creation 추천을 받을 수 있는 object는 index, mview 및 mview log정도임을 알 수 있다. 즉, SQL tuning은 무언가 를 생성하는 것 보다 훨씬 더 많은 종류의 방향이 있음을 잊지 말자. 위 작업들과 관련하여 workload를 handling하는 또 다른 procedures를 대략 살펴보면 JKSPARK@HANAFOS.COM 172 표 7-25 Workloa d Procedur e List
  • 173. http://www.ggola.com 장 경 상 다음과 같은 것들이 있다. 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 173
  • 174. http://www.ggola.com 장 경 상 OCP point =============================================================== 1. SQL tuning advisor의 4가지 결과물 2. SQL access advisor를 통해 creation을 권고 받을 수 있는 object의 종류 JKSPARK@HANAFOS.COM 174
  • 175. 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 175
  • 176. 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 176 그림 7-60 em 초기 화면
  • 177. 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 177 그림 7-61 성능측정 화면
  • 178. 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 178 그림 7-62 세부 성능 측정 화면
  • 179. http://www.ggola.com 장 경 상 OCP point =============================================================== 1. em database control의 performance tab에 나타나는 항목들 JKSPARK@HANAFOS.COM 179
  • 180. 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을 여러 end user가 공유하고 각 end user가 application을 call하면 middleware에서 그 call을 받아 oracle과 연동하여 작 JKSPARK@HANAFOS.COM 180
  • 181. http://www.ggola.com 장 경 상 업을 처리한다. 따라서 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 ; PL/SQL procedure successfully completed. JKSPARK@HANAFOS.COM 181
  • 182. http://www.ggola.com 장 경 상 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',- > '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 ; JKSPARK@HANAFOS.COM 182
  • 183. http://www.ggola.com 장 경 상 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 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'; JKSPARK@HANAFOS.COM 183
  • 184. http://www.ggola.com 장 경 상 INITIAL_RSRC_CONSUMER_GROUP ---------------------------------------------------- SHORT_GRP SYSTEM> alter system set resource_manager_plan = 'MOVE_PLAN'; System altered. SYSTEM> select name, cpu_wait_time, consumed_cpu_time 2 from v$rsrc_consumer_group; NAME CPU_WAIT_TIME CONSUMED_CPU_TIME -------------------------------- ------------------------- ---------------------------------- LONG_GRP 0 0 OTHER_GROUPS 0 403 SHORT_GRP 0 0 SYSTEM> grant select on v_$session to xrsrc; Grant succeeded. XRSRC> conn xrsrc/xrsrc Connected. XRSRC> set timing on XRSRC> select resource_consumer_group 2 from v$session where username = 'XRSRC'; RESOURCE_CONSUMER_GROUP ------------------------------------------------ SHORT_GRP Elapsed: 00:00:00.03 XRSRC> create table rsrc_cnt (dummy number(20)); JKSPARK@HANAFOS.COM 184
  • 185. http://www.ggola.com 장 경 상 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); 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 JKSPARK@HANAFOS.COM 185
  • 186. http://www.ggola.com 장 경 상 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 -------------------------------- ------------------------- ---------------------------------- 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'; JKSPARK@HANAFOS.COM 186
  • 187. http://www.ggola.com 장 경 상 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한다. 이상하겠지만 위 그림에서 보듯 oracle10g의 새로운 parameter인 switch_time_in_call은 보이지 않고 이전의 switch_time(Execution Time)만 나타난다. 이는 현재 oracle10g em database control에서 지원하지 않기 때문이다. 향후에 oracle10g R2에서 이 부분이 어떻 게 변화가 되는지는 여러분 각자가 살펴보시기 바란다. JKSPARK@HANAFOS.COM 187 그림 7-63 Resource Plan List 그림 7-64 Plan 설정 화면
  • 188. http://www.ggola.com 장 경 상 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. 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 ; JKSPARK@HANAFOS.COM 188
  • 189. http://www.ggola.com 장 경 상 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'); 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'; JKSPARK@HANAFOS.COM 189
  • 190. http://www.ggola.com 장 경 상 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으로 지정하자. 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 ; JKSPARK@HANAFOS.COM 190
  • 191. http://www.ggola.com 장 경 상 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 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(- JKSPARK@HANAFOS.COM 191
  • 192. http://www.ggola.com 장 경 상 > 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; 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. JKSPARK@HANAFOS.COM 192
  • 193. http://www.ggola.com 장 경 상 Elapsed: 00:00:30.73 테스트 계정 #1 : 이제 테스트 계정 #1이 PMON에 의해 정리되었음을 확인해 보자. XRSRC> select sysdate from dual; select sysdate from dual * ERROR at line 1: ORA-02396: exceeded maximum idle time, please connect again Elapsed: 00:00:00.00 이제 session의 idle과 관련한 두 가지 기능 session idle time, session locking time이 제대 로 작동되고 있음을 확인하였다. 7.10.3.3.Using em 위에서 약간은 복잡하게 처리한 idle time은 다음과 같이 em database control에서 간단 히 정의할 수 있다. “Administration  Resource Plans  PLAN 이름  Idle time tab” 여기서는 move_plan을 선택한 화면이다. 7.10.4. 유연한 Resource Group의 할당 우리가 resource manager를 사용하는 가장 큰 이유는 resource consumer group을 user 에게 할당하고 그 user로 하여금 적절한 resource의 사용을 제한하기 위해서다. 그래서 resource group을 switch하는 기능도 필요한 것이다. 하지만 잠깐 눈을 돌려 생각해 보면 여기에도 맹점은 있다. 대개의 (특히나 3-tier의 session pooling구조의 경우) application user가 사용하는 oracle 계정은 한, 두 개를 가지고 공유하게 되며 따라서 application 사 용자는 그 수가 아무리 많더라도 그리고 아무리 다른 종류의 작업을 수행한다고 해도 동 JKSPARK@HANAFOS.COM 193 그림 7-65 Plan 설정 내역 확인
  • 194. http://www.ggola.com 장 경 상 일한 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가 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_name client tnsnames.ora의 service_name client_os_user Login osuser OS username(ex. windows 사용자 이름) JKSPARK@HANAFOS.COM 194 표 7-26 Resource Group Mapping
  • 195. http://www.ggola.com 장 경 상 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_module module_name_action Runtim e module, action application module name and action ex. dbms_application_info.set_mod ule dbms_application_info.set_actio n service_module Runtim e service_name , module service_name + module_name service_module_actio n Runtim e service_name , 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. JKSPARK@HANAFOS.COM 195
  • 196. http://www.ggola.com 장 경 상 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. 이제 현재 테스트를 진행하고 있는 계정 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에 이미 JKSPARK@HANAFOS.COM 196
  • 197. http://www.ggola.com 장 경 상 mapping이 되어있는 것이며 다만 다음에 설명하는 우선순위에서 module_name이 oracle_user보다 더 높은 순위를 가지고 있기 때문에 위와 같은 결과가 나온 것이다. 이를 확인해 보기 위해 “dba_rsrc_group_mappings”를 참조해 보라. CF. 각 계정이 각각 oracle_user로 mapping이 되어있다는 말은 곧 resource group을 mapping하는 각각의 parameter는 resource group과 상관없이 복수로 설정이 가능하다 는 의미가 된다. 예를 들어 module_action의 값을 10가지로 정하고 각기 다른 resource group을 mapping해도 된다는 뜻이다. 물론, 이렇게 되면 application에서 module혹은 action을 변경할 때마다 resource group이 계속해서 변경될 것이다. CF. 위 mapping items 중에는 복수의 combination 구성이 있다. 즉, module name과 action을 설정하거나, service name과 module등으로 구성하는 것이 그것이다. 이런 구성 으로 resource를 mapping하기 위해서는 “.”을 사용해서 구분하면 된다. 다음의 예는 module_action의 값을 구현하기 위하여 “.”을 사용하는 방식이다. 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”를 할당 받을 것이다. JKSPARK@HANAFOS.COM 197
  • 198. http://www.ggola.com 장 경 상 간단하게 priority를 조정하여 resource consumer group의 변화를 확인해 보자. 다음은 앞서 설정한 module_name 속성을 그대로 두고 service_name의 속성을 추가한 후 그 우 선순위를 module_name이 service_name보다 높게 설정한 것이다. 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.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 JKSPARK@HANAFOS.COM 198
  • 199. http://www.ggola.com 장 경 상 Connected. XRSRC> select resource_consumer_group from v$session 2 where audsid = userenv('sessionid'); RESOURCE_CONSUMER_GROUP ----------------------------------------------- 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의 우선 순 JKSPARK@HANAFOS.COM 199
  • 200. http://www.ggola.com 장 경 상 위보다 높음으로 long_grp가 할당되었음이 확인된다. 다음은 system 계정의 창에서 이 우선순위를 반대로 바꾸는 과정이다. 우선순위의 속성인 service_name과 module_name 의 순위를 서로 맞바꾸어 보자. 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 => 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과 맞바꾸어 보자. JKSPARK@HANAFOS.COM 200
  • 201. http://www.ggola.com 장 경 상 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 => 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 JKSPARK@HANAFOS.COM 201
  • 202. http://www.ggola.com 장 경 상 group을 확인하고 system 창에서 explicit의 우선순위가 어떤지 보자. 테스트 창 : XRSRC> conn xrsrc/xrsrc Connected. XRSRC> select resource_consumer_group from v$session 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 JKSPARK@HANAFOS.COM 202
  • 203. http://www.ggola.com 장 경 상 XRSRC> exec dbms_application_info.set_module('MAP_LONG_QUERY',- > 'TEST ACTION'); PL/SQL procedure successfully completed. 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. JKSPARK@HANAFOS.COM 203
  • 204. http://www.ggola.com 장 경 상 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 ----------------------------------------------- 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을 바꾸는 행위가 발생하면 이 것은 우선순위와 상관없이 반영이 된다는 JKSPARK@HANAFOS.COM 204
  • 205. http://www.ggola.com 장 경 상 사실이다. 예를 들어 위 상태에서 system창으로 가서 테스트 창의 resource consumer group을 변경해 본 후 그 결과를 테스트 창에서 확인해 보자. 테스트 창: XRSRC> select sid, serial# from v$session 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할당의 우선순위를 확인하고 싶다면 이 정보를 가 JKSPARK@HANAFOS.COM 205
  • 206. http://www.ggola.com 장 경 상 지고 있는 “dba_rsrc_mapping_priority”를 확인해 보기 바란다. CF. 현재 설정된 mapping을 취소하고자 할 때에는 dbms_resource_manager.set_consumer_group_mapping procedure를 call하면서 취소 하고자 하는 속성을 명명하고 3번째 parameter인 consumer_group을 NULL을 설정하면 된다. 7.10.4.3.Using em 다음은 위에서 설정한 resource consumer group의 mapping을 em database control에서 어떻게 하는지 알아보자. 먼저, “Administration  Resource Consumer Group Mappings  (General)”을 선택한다. 그러면 아래와 같은 화면에서 원하는 mapping item을 찾아 “Add Another Row”를 click하면 resource mapping을 추가할 수 있다. 위와 동일한 방식으로 위의 “Priorities”를 선택하면 다음과 같은 화면에서 우선순위도 설 정할 수 있다. JKSPARK@HANAFOS.COM 206 그림 7-66 Resource Mapping
  • 207. 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”방식이라 부른다. CF. 물론, “EMPHASIS”방식으로 single-level plan을 만든다고 문제될 것은 없다. JKSPARK@HANAFOS.COM 207 그림 7-67 Resource 우선순위
  • 208. http://www.ggola.com 장 경 상 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'); PL/SQL procedure successfully completed. JKSPARK@HANAFOS.COM 208
  • 209. http://www.ggola.com 장 경 상 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를 사용하여 같은 작업을 해보자. SYSTEM> exec dbms_resource_manager.create_simple_plan (- > simple_plan => 'SINGLE_PLANX',- > consumer_group1 => 'short_grp', group1_cpu => 4,- JKSPARK@HANAFOS.COM 209
  • 210. http://www.ggola.com 장 경 상 > 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 ; PL/SQL procedure successfully completed. SYSTEM> exec dbms_resource_manager.create_plan('single_plan',- > 'single ratio', 'RATIO'); JKSPARK@HANAFOS.COM 210
  • 211. http://www.ggola.com 장 경 상 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 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') JKSPARK@HANAFOS.COM 211
  • 212. http://www.ggola.com 장 경 상 5 order by 1, 2, 3 desc, 4 desc; PLAN GROUP_OR_SUB P1 P2 P3 COMMENTS ----------------------- ------------------------- ------ ----- ------ ----------------------------------- SINGLE_PLAN IDLE_GRP 0 2 0 Level 2 Group 3 SINGLE_PLAN LONG_GRP 0 3 0 Level 2 Group 2 SINGLE_PLAN OTHER_GROUPS 0 0 100 OTHER_GROUPS Level 3 SINGLE_PLAN SHORT_GRP 0 5 0 Level 2 Group 1 SINGLE_PLAN SYS_GROUP 100 0 0 SYS Level 1 SINGLE_PLANX IDLE_GRP 0 2 0 Level 2 Group 3 SINGLE_PLANX LONG_GRP 0 3 0 Level 2 Group 2 SINGLE_PLANX OTHER_GROUPS 0 0 100 OTHER_GROUPS Level 3 SINGLE_PLANX SHORT_GRP 0 5 0 Level 2 Group 1 SINGLE_PLANX SYS_GROUP 100 0 0 SYS Level 1 XRATIO_PLAN IDLE_GRP 2 0 0 3rd grade XRATIO_PLAN LONG_GRP 3 0 0 2nd grade XRATIO_PLAN OTHER_GROUPS 1 0 0 other grade XRATIO_PLAN SHORT_GRP 4 0 0 1st grade 14 rows selected. 위 결과를 통해 “RAITO”방식의 “XRATIO_PLAN”은 모두 cpu_p1만으로 설정되었고 (level 1 only single-level plan) 나머지는 create_simple_plan을 통해 다음과 같은 default 규칙이 적용되었다. 우선 “SYS_GROUP”은 cpu_p1에 100%, cpu_p2는 plan 설정 시 기술 된 값대로 그리고 cpu_p3에 other_groups에 100%가 설정된 것이다. 따라서 위 single_plan, single_planx의 CPU는 비율이 아니라 percent로 할당되었기 때문에 cpu_p2 는 2%, 3%, 5%밖에 안 되는 값으로 지정된 것이다. CF. 사실 create_simple_plan이 최대 8개 groups까지 single-level resource plan을 쉽게 구현하기 위해 만들어진 procedure이지만 그 내용을 보면 이는 모두 level2에만 적용이 되는 것이고 level 1은 “SYS_GROUP”을 위해 level 3은 “OTHER_GROUPS”을 위해 자 동으로 CPU 100%가 설정됨을 확인할 수 있다. 따라서 엄밀히 말하면 create_simple_plan은 level 2에만 적용되는 single-level plan이라 할 것이다. CF. 앞서 소개했던 oracle10g위 “switch_time_in_call”과 마찬가지로 oracle10g의 new JKSPARK@HANAFOS.COM 212
  • 213. http://www.ggola.com 장 경 상 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 213 그림 7-68 Resource Monitor
  • 214. 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 214
  • 215. 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 215
  • 216. http://www.ggola.com 장 경 상 여기서 주요 관심이 있는 tablespace를 직접 click하면 다음과 같은 화면에서 다양한 속성 을 정의할 수 있게 된다. 예를 들어 위에서 “AUTOTBS”를 click하면 다음과 같은 화면을 볼 수 있다. 우측 상단의 “Thresholds” tab을 선택하면 바로 다음과 같은 화면에서 앞서 이야기한 usage에 대한 속성을 편집할 수 있게 된다. JKSPARK@HANAFOS.COM 216 그림 7-69 Tablespa ce Monitor 그림 7-70 Tablespa ce Monitor
  • 217. 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 217 그림 7-71 Tablespa ce Monitor
  • 218. 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 218
  • 219. 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 219 그림 7-72 Segment 관리체계
  • 220. 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 220
  • 221. 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이 이동될 때 매우 짧은 시간이기는 하지만 해당 object에 대한 exclusive lock을 잠깐 획득해야 하며 동시에 dependent cursor는 invalidate된다. JKSPARK@HANAFOS.COM 221
  • 222. http://www.ggola.com 장 경 상 다음의 command 형식을 기억해 보자. 다음의 내역은 실제로 수행한 것이 아니라 이 책 의 전작인 oracle9i new features에서 따온 것이다. SQL> alter table emp_iot coalesce; Table altered. SQL> alter index ik_empname_iot_2nd coalesce; Index altered. 위 내용은 oracle9i에서 space 관리의 효율화를 위해 소개했던 oracle9i new feature의 일 부이다. 첫 번째 SQL은 iot table에 대한 coalesce이고 두 번째 SQL은 index에 대한 coalesce의 예이다. 다시 말해 space를 효율화 하는 기능은 이미 oracle9i에서 시작되었다. 위 두 command의 예(index, iot coalesce)는 아래와 같은 oracle10g의 new feature와 같은 역할을 한다. SQL> alter table|index ..name.. shrink space compact ; 7.11.3.4.Shrink Example 다음은 특정 table에 data를 생성한 후 fragmentation의 변화와 block의 변화를 확인하는 과정이다. 이 table은 shrink 기능을 확인하기 위하여 계속 사용될 것이다. 또한 여기서 사 용되는 package dbms_space 역시 이미 이 책의 전작인 oracle9i new features에서 새롭 게 소개된 tablespace의 segment관리 방식을 설명하면서 사용한 것이다. 먼저 table 생성  insert  space check를 해보자. SCOTT> create table x_shrink_obj (sno number); Table created. SCOTT> begin 2 for i in 1..300000 loop 3 insert into x_shrink_obj values (i*100); 4 end loop; 5 end; 6 / JKSPARK@HANAFOS.COM 222
  • 223. http://www.ggola.com 장 경 상 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 FS3 BLK = 0 BTS = 0 FS4 BLK = 48 BTS = 393216 Full BLK = 454 BTS = 3719168 JKSPARK@HANAFOS.COM 223
  • 224. http://www.ggola.com 장 경 상 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; 12 / PL/SQL procedure successfully completed. JKSPARK@HANAFOS.COM 224
  • 225. http://www.ggola.com 장 경 상 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를 통해 block내 rows가 부분적으로 free space로 변화했다는 것이며 oracle block관리 특성상 blocks의 수도 변화가 없다는 것을 알 수 있다. 이제 shrink를 위해 row movement 속성을 추가하고 compact 기능을 사용해 보자. 그리 고 그 결과를 확인하자. JKSPARK@HANAFOS.COM 225
  • 226. http://www.ggola.com 장 경 상 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'; BLOCKS ------------ 512 위 결과는 총 blocks의 수는 줄지 않았어도 segment에서 현재 사용되고 있는 blocks의 수 는 줄어들었음을 보여준다. 즉, 내부 free space가 정리가 되었다는 것이고 delete후 발생 JKSPARK@HANAFOS.COM 226
  • 227. http://www.ggola.com 장 경 상 한 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'; BLOCKS ------------ 384 Free space 공간이 database로 return되어 HWM이 줄어들었음을 segment내 blocks 수의 변화로도 알 수가 있다. JKSPARK@HANAFOS.COM 227
  • 228. http://www.ggola.com 장 경 상 다음은 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. 7.11.3.5.Using em 이 shrink 역시 em을 통해서 할 수 있다. 먼저 다음과 같이 table 화면으로 이동한다. “Administration  Tables(Schema)” JKSPARK@HANAFOS.COM 228
  • 229. http://www.ggola.com 장 경 상 아래 table 화면에서 schema와 table name을 선택 혹은 입력한 후 “Go” 버튼을 누른다. JKSPARK@HANAFOS.COM 229 그림 7-73 em 관리 화면
  • 230. http://www.ggola.com 장 경 상 아래 화면의 하 단에 서 원하는 table을 선택한 후 우측 중앙 “Actions”의 item중 “Shrink Segment”를 선택하고 “Go” 버튼을 click한다. 다양한 작업이 가능한 화면이다. 여기서 앞서 배운 options을 선택하고 우측 상단의 “Continue”를 선택한다. JKSPARK@HANAFOS.COM 230 그림 7-74 Segment Shrink 그림 7-75 Segment Shrink
  • 231. 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로 이루어지게 된다. 다음은 PL/SQL을 통해 tablespace level의 분석결과를 확인하는 예이다. JKSPARK@HANAFOS.COM 231 그림 7-76 Segment Shrink 그림 7-77 Segment Shrink
  • 232. http://www.ggola.com 장 경 상 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, 4 dba_advisor_recommendations ar, dba_advisor_actions aa 5 where aa.task_name = 'SADV_TBS' and ar.task_name = 'SADV_TBS' JKSPARK@HANAFOS.COM 232
  • 233. http://www.ggola.com 장 경 상 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 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: JKSPARK@HANAFOS.COM 233
  • 234. http://www.ggola.com 장 경 상 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 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 JKSPARK@HANAFOS.COM 234
  • 235. http://www.ggola.com 장 경 상 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”를 진행한다. 여기서는 tablespace에 대해 알아볼 것이다. 다음 화면에서 우측 중앙의 “Add”를 통해 tablespace list를 확인한다. JKSPARK@HANAFOS.COM 235 그림 7-78 Segment Advisor 그림 7-79 Segment Advisor
  • 236. http://www.ggola.com 장 경 상 다음 화면에서 적절한 tablespace를 선택한 후 “Ok”를 선택한다. 이제 “Next”를 통해 다음 단계로 간다. 여기서부터는 익숙한 화면이다. 차례 차례 “Next”를 통해 이동한다. JKSPARK@HANAFOS.COM 236 그림 7-80 Segment Advisor 그림 7-81 Segment Advisor 그림 7-82 Segment Advisor
  • 237. http://www.ggola.com 장 경 상 수행 시간을 정하는 schedule 화면이다. 최종 설정이 완료된 화면이다. “Submit”을 통해 작업을 수행할 수 있다. JKSPARK@HANAFOS.COM 237 그림 7-83 Segment Advisor 그림 7-84 Segment Advisor
  • 238. http://www.ggola.com 장 경 상 하단에 생성된 “Segment Advisor”항목을 볼 수 있다. 이제 분석 작업이 완료가 되면 해당 task를 선택하여 다음과 같은 결과를 확인할 수 있다. 아래 화면은 각 segment별 분석 및 추정결과를 보여준다. 물론, 원한다면 아래 화면의 우 측상단 “Show SQL”을 통해 추천하는 SQL script도 확인할 수 있다. JKSPARK@HANAFOS.COM 238 그림 7-85 Segment Advisor 그림 7-86 Em의 전 체 Advisor 결과 List
  • 239. http://www.ggola.com 장 경 상 7.11.4.3.Segment Trend Oracle10g가 제공하는 또 하나의 유용한 기능은 바로 segment의 trend이다. 현재 필자도 그러하지만 상당수의 site들은 storage 예측을 위해 전체 혹은 중요 tables에 대하여 변화 추이를 기록하여 따로 분석하는 작업을 진행하게 된다. 앞서 shrink에서 보았던 em database control에서 “Administration  Tables(Schema)”를 선택한 후 다음과 같이 원 하는 table을 선택 혹은 입력한다. 그리고 나서 하단의 list에서 해당 table을 click하면 아래 화면으로 이동한다. 여기서 상단 좌측의 “Segments” tab을 선택한다. JKSPARK@HANAFOS.COM 239 그림 7-87 Segment Advisor 결과 그림 7-88 Segment Trend 분 석
  • 240. http://www.ggola.com 장 경 상 아래 화면에서 해당 segment의 space usage가 graph로 나타나고 날짜를 선택해서 볼 수 도 있다. 위의 예는 9월 14일(현재 날짜)부터는 사용량이 늘어나는 것으로 보인다. 이것은(14일부 터) 오늘부터 이 segment에 data가 생성이 될 것이라는 가정하에 trend 추측을 한 것이다. 현재 table은 테스트를 위해서 사용한 것임으로 지속적인 변화가 없었다. 따라서 위의 14 일 이후 추측은 현재로서는 정확하지 않다. 그러나 빈번한 변화가 일어나는 실제 (여러분 이 운영하는)업무 table에 대하여 위 trend를 살펴보면 매우 정확한 예측 결과를 볼 수 있 을 것이다. 원한다면 위 과정을 아래와 같이 dbms_space package를 통해 확인할 수도 있다. 역시 14 일 이후로는 예측이다. JKSPARK@HANAFOS.COM 240 그림 7-89 Segment Trend 분 석 그림 7-90 Segment Trend 분 석
  • 241. http://www.ggola.com 장 경 상 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 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해보자. JKSPARK@HANAFOS.COM 241 그림 7-91 Segment Size 분석
  • 242. http://www.ggola.com 장 경 상 이제 다음 화면에서 table의 유형을 선택하고 “Continue”를 한다. 이제 아래화면에서 각종 storage 등 필요한 설정을 한 후 중앙의 “Estimate Table Size”를 선택한다. 이제 예측하고 있는 data 건수를 입력한 후 중앙의 “Estimate Tab le Size”를 선택해보라. JKSPARK@HANAFOS.COM 242 그림 7-92 Segment Size 분석 그림 7-93 Segment Size 분석 그림 7-94 Segment Size 분석
  • 243. http://www.ggola.com 장 경 상 이제 중앙에 계산된 결과값을 볼 수 있다. 즉, 위 그림의 “Unavailable”이 계산된 값으로 변경된다. 여러분은 이 결과를 기준으로 수 차례 estimation을 통해 적합한 storage 구성 을 하는데 도움을 받을 수 있을 것이다. 물론, 위 기능 역시 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); JKSPARK@HANAFOS.COM 243 그림 7-95 Segment Size 분석
  • 244. http://www.ggola.com 장 경 상 PL/SQL procedure successfully completed. SYSTEM> print :usb_bt :alc_bt USB_BT ------------ 12419072 ALC_BT ------------ 12582912 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 ----------- JKSPARK@HANAFOS.COM 244
  • 245. http://www.ggola.com 장 경 상 346164 ALC_BT ----------- 720896 SYSTEM> select 346164/1024/1024, 720896/1024/1024 from dual; 346164/1024/1024 720896/1024/1024 ------------------------- ------------------------ .330127716 .6875 위 결과는 만일 index를 생성하게 되면 사용 및 필요 space가 1MB가 안 된다는 점을 보여 준다. 7.11.5. Undo Management 7.11.5.1.Undo 관리 화면 특별한 segment중 하나인 undo segment를 관리하는 기법은 여러 가지이다. 과거의 rollback segment에서 undo segment로의 변화 그리고 undo retention을 비롯한 여러 가 지의 관리 parameters등 조금 더 자세히 모니터링하고 관리하고자 하면 많은 SQL문을 사용해야 한다. Oracle10g의 em database control이 제공하는 다음과 같은 화면은 여러분 으로 하여금 한눈에 쉽게 undo관련 정보를 취득하고 수정작업을 할 수 있도록 도와준다. “Administration  Undo Management(Instance)”로 이동해 보자. JKSPARK@HANAFOS.COM 245
  • 246. http://www.ggola.com 장 경 상 우리는 이 화면에서 3단계로 이루어진 undo관련 내역을 확인할 수 있다. 즉, 현재 설정된 undo의 속성을 보여주는 부분, undo 관리에 문제가 있는지 없는지 분석하여 권고하는 부분, 그리고 현재 사용중인 undo 사용량과 관련된 부분을 한눈에 확인할 수 있다. 중앙 에 있는 “Update Analysis”버튼은 undo 분석 period를 일주일, 하루, 한 시간 전부터 여 러분이 직접 설정하는 시간까지 분석기간을 정의하고 수행할 수 있게 해준다. 물론, 여기 서 “Undo Advisor”로 이동할 수도 있고 “Change Tablespace”버튼을 통해 undo tablespace의 변경이 가능하며 “Edit Undo Tablespace”버튼을 통해 tablespace 속성을 변경할 수 있다. 화면 좌측 하단의 “Show Graph”를 선택하면 다음과 같이 undo 생성 비율과 undo tablespace 사용량과 관련한 부분을 graph로 보여준다. 다음 화면을 보라. JKSPARK@HANAFOS.COM 246 그림 7-96 Undo 관 리화면
  • 247. http://www.ggola.com 장 경 상 7.11.5.2.Undo Advisor 위 화면에서 “Undo Advisor”를 선택하게 되면 다음과 같은 화면을 볼 수 있다. 이 화면에서 undo 관리에 대한 분석된 결과를 볼 수 있으며 그 결과에 따라 여러분은 oracle10g가 recommend하는 내용들을 적용하거나 계획하는 등의 작업을 손쉽게 할 수 있다. 상단 중앙을 보면 undo retention의 조정 및 분석기간의 선택 등을 할 수 있고 JKSPARK@HANAFOS.COM 247 그림 7-97 Undo Tablespa ce 사용량 그림 7-98 Undo Advisor
  • 248. http://www.ggola.com 장 경 상 “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'); PL/SQL procedure successfully completed. SYSTEM> exec dbms_advisor.create_object(:task, 'UNDO_TBS',- JKSPARK@HANAFOS.COM 248
  • 249. http://www.ggola.com 장 경 상 > 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 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 JKSPARK@HANAFOS.COM 249
  • 250. http://www.ggola.com 장 경 상 no rows selected 현재 이 부분에 대해서 그 원인을 파악 중이며 확인이 되는 즉시 홈페이지 게시판을 통해 올리도록 할 예정이다. 어찌 되었든 이 문제와는 상관없이 undo에 대한 분석은 ADDM 전체 분석에서는 문제없 이 나타나고 있고 또 따로 em의 undo management를 통한 분석이 충분히 유효하기 때문 에 가급적 undo management의 사용을 권장한다. JKSPARK@HANAFOS.COM 250
  • 251. 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 251

×