Successfully reported this slideshow.

Oracle History #14

528 views

Published on

Self Management Database

Published in: Education
  • Be the first to comment

  • Be the first to like this

Oracle History #14

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 19. http://www.ggola.com 장 경 상 2. 다음과 같은 초기 화면에서 현재 database의 전반적인 상태를 보여주는 database control화면(기본화면)이 나타나게 된다. (물론, 이 화면 전에 license관련 동의를 묻는 화 면이 나오면 동의를 누르고 넘어가면 된다) 화면은 크게 진단에 내역과 경고성 메시지를 나타내는 부분이 상중하로 나뉘어 지며 아래 화면 우측 상단에서처럼 자동으로 refresh를 하거나 사용자가 원할 때 수동으로 refresh를 하도록 선택할 수도 있다. 상단화면 : JKSPARK@HANAFOS.COM 19 그림 7-1 em login 창
  20. 20. http://www.ggola.com 장 경 상 중단화면 : 하단화면 : JKSPARK@HANAFOS.COM 20 그림 7-2 em 초기 화면 그림 7-3 em 초기 화면
  21. 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. 22. http://www.ggola.com 장 경 상 다음은 위 화면에서 분석을 시작할 시간과 마지막 시간을 설정하는 과정이다. 먼저 시작 시간 radio button을 선택한 후 화면 하단 그래프 밑에서 원하는 시간대를 click하면 자동 으로 선택이 된다. 같은 방법으로 종료시간을 설정하면 다음과 같이 선택이 완료된다. 현재는 그래프 우측 에서 약간의 작업이 있었던 것으로 추측되는 시간대를 선택했다. 확인을 눌러보자. JKSPARK@HANAFOS.COM 22 그림 7-6 ADDM 설정화면 그림 7-7 ADDM 설정화면 그림 7-8 ADDM 설정화면
  23. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 49. http://www.ggola.com 장 경 상 OCP point =============================================================== 1. automatic 통계수집에서 사용하는 두 가지 window와 그 내용 2. 특정 table만을 대상으로 불필요한 통계작업을 제거하는 방법 3. 통계정보 history 보관일자 변경 procedure 사용방법 JKSPARK@HANAFOS.COM 49
  50. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×