John Kanagaraj, DB Soft IncExpert Session #319 (2 hour)

ORACLE DATABASE 10GR2: AN ENLIGHTENED REVISIT

(BEFORE WE GIVE UP AND MOVE TO 11G!)

Speaker Qualifications

• John is a Principal Consultant @ DB Soft Inc.• Executive Editor for IOUG’s SELECT Journal• Co-author of “Oracle Database 10g Insider Solutions”• Technical Editor for various books• Frequent presenter – IOUG/OAUG/OOW/NoCOUG• Published in SELECT, OAUG Insight, SQL Server

Magazine and other publications• Recognized by Oracle Corp as an “Oracle ACE”

SELECT: Call for Articles/Reviewers

– The SELECT Journal is IOUG’s Technical Quarterly– Distributed to all IOUG members worldwide – Yearly Best Practices and Tips booklet

• Submit an article or Review one!• Contact ‘select@ioug.org’

What this presentation is about

• Oracle Database 10g now in “full production” mode• R1 released in 2003 (?), R2 in 2005 (?)• A little history lesson – book, papers• Lead time between books/initial articles and

“consolidation” / “better understanding”• Need to revisit and update the “first revelation”• Reconsider “new features” – fresh look• Hidden surprises and little bonuses• A peek into the future – 11g titbits

Audience survey

• Using Oracle Database 11g in production?• Still using Oracle 7 or 8i?• Migrating to Oracle Database 10g?• Read the “New features” manual for every release?• Used Advisories in 9i?• Used Active Session History for troubleshooting?• Read AWR/ADDM/ASH reports?• Used SQL Profiles to fix SQL issues?

Overview of new perf features

• Strictly related to performance related features• Need to “unlearn the old and embrace the new”• AWR – The Performance Warehouse• ASH – What happened to the sessions?!?• ADDM – Your inbuilt (and unpaid!) expert• Tuning advisors – Bonus freebies• In-Memory metrics and Server generated alerts• Where to look for more details

Philosophy behind Oracle DB 10g

• Automation– Incremental steps in 9i (Advisors, Time)– Most significant change in Performance

management– “Out of the box” setups– GUI “hides” the complexity (and details!)

• Consistency– Common/Unified interface– Stats storage and presentation– Interpretation

Reality check before we proceed

• Licensing changes in Oracle Database 10g• A tale of two packs:

– Oracle Diagnostic Pack• Automatic Workload Repository (AWR)• Automatic Database Diagnostic Monitor (ADDM)• Monitoring and Event notifications and history

– Oracle Tuning Pack• SQL Access Advisor• SQL Tuning Advisor and STS• Object Advisor

• Required even to access Views directly!!!

AWR – Performance Warehouse

• Performance Data Warehouse for 10g• Basis for most of the problem detection and reporting• AWR collects, stores performance data

– Direct memory access (MMNL/MMON)– In-memory component (V$/Metric views)– “Persisted” in WR tables (SYSAUX) – 162 tables – WRI$, WRH$, WRM$– Exposed via DBA_HIST_* Views

• Self managing “out of the box”• Set retention, frequency, baseline

AWR Contents

• Active Session History (ASH)• High-load SQL statements• Time model statistics (both System/Session)• Object usage - access counts for segments• Snapshots of V$ and some Metrics• Host CPU and Memory statistics (V$OSSTAT)• Baseline information• “Management” type information

– Snapshot details– Advisor and other parameters

AWR – “Statspack on Steroids”

• Similar to STATSPACK “snapshots”• Reportable – AWRRPT.SQL• AWR snapshot automatically analyzed• Accessible via GUI and API/SQL (*)• High-impact SQL captured differently• Stores session level info as well

* Read the fine print : License required, even for SQL access!

AWR Baselining and comparison

• Enables performance “baselining”• Collection of two or more snapshots• Stored in “_BL” tables; data not purged• View using WRM$_BASELINE/DBA_HIST_BASELINE• Reports diff via AWRDDRPT.SQL• Execution statistics for specific SQL statement using

AWRSQRPT.SQL

ASH – What’s up with sessions

• Historical view of active sessions• Active sessions sampled every second• Stored in circular memory buffer• Every 10th sample persisted in AWR• V$ACTIVE_SESSION_HISTORY : “In-memory”• WRH$_ACTIVE_SESSION_HISTORY : “Persisted”• Enables “after-the-fact” analysis!!!• Reported via ASHRPT (Not available in 10gR1)• “Slice-and-dice” analysis can reveal a lot of info

ASH – Session states exposed!

• “On-the-spot” analysis• Retroactive analysis

– From memory buffer (V$ACTIVE_SESSION_HISTORY)– From persisted AWR data

(WRH$_ACTIVE_SESSION_HISTORY connected via SNAP_ID)

– Supports manual drill down from AWR/ADDM

• Tracks High load SQL execution behavior• Determine Blocking sessions and “hot” segments• SESSION_STATE : “ON CPU” or “WAITING”

ADDM – Your unpaid Tuning Expert!

• Starting point for most investigations• Runs after every AWR snapshot• Determines and records performance issue• Recommends corrective action• Generates probable benefit• Suggest use of other advisors• Common currency - “DB Time” (qualitative!)• Oracle DB 11g – new “Instance ADDM”

ADDM – Partial check list

• CPU bottlenecks• Excessive parsing• Lock contention• Concurrency• I/O capacity• Incorrect sizing of Oracle memory and file structures• High-load SQL, Java and PL/SQL statements• Poor connection management• Hot objects• RAC-specific issues

ADDM – Findings/Recommendations

• Qualitative rather than Quantitative analysis• Hardware changes• Database-configuration changes• Schema-level changes• Application changes• Using other advisors (for example)

– SQL Tuning Advisor / SQL Access Advisor– Segment Advisor

• Don’t stare at the screen – Use SQL to summarize– Details in my 2007 paper

Advisors – A step beyond

• Builds on 9i advisors– Buffer cache advisor– Shared pool advisor– MTTR (Mean Time To Recover) advisor– Summary (MVIEW) advisor– PGA Target Advisor

• New in 10g– SQL Tuning Advisor– SQL Access Advisor– Segment Advisor

SQL Tuning Advisor

• Frontend to Automatic Tuning Optimizer• Extension (reuse) of Optimizer (CBO)• Performs “what-if” analysis• Not restricted by “time to optimize”

(_optimizer_max_permutations = 2000)• The following advice is provided

– Gather missing or stale statistics– Create new indexes– Restructure SQL statement– SQL profiles

SQL Tuning Advisor

• SQL Profile – Collects additional information via sampling/partial

execution techniques– Verifies and adjusts CBO’s estimates at runtime– Similar in function to Outlines– Enabled by category : “test-and-set”– Access/manipulate – DBMS_SQLTUNE– Precedence given to Stored Outlines– Runs against individual SQL or SQL Tuning Sets

(STS)

Other Advisors

• SQL Access Advisor– Works alongside SQL Tuning Advisor– Advice on MV, Indexes, MV logs– Considers space usage vs performance – Inputs: STS, User-defined, Hypothetical– Advanced: Workload type (RO), Drop unused indexes,

Filters (Top N, Module)

• Segment Advisor• Undo Advisor• Memory Advisor• Metrics and Server Generated Alerts

Avoiding Advisor Pitfalls

• Out-of-the-box thinking (redesign; rethink approach)• False positives (check validity for all situations – e.g.

Index non-usage)• Changing workload or environment (additional load,

new code, H/W or S/W changes)

Features revisited

• STATSPACK – Not dead yet!• New and changed views – tons of goodies!• Event Breakout – Greater visibility• Mutexes – Boon or Bane?• Operating System Statistics – all in one place• Time and Wait Model – aids better understanding• Hidden Surprises – watch out!• Useful AWR sections – Segstats and much more• Extracting Data from AWR – Drill down example• DBMS_XPLAN – in-depth view

STATSPACK – Not dead yet!

• STATSPACK is still available in Oracle DB 10g• No license required to track performance stats• Setup/maintenance/reporting : same as before

– Default is Level 5, set at Level 7 to get Segment stats

• Number of new sections available– OS Statistics– DB Time reporting– Response time Histograms (Event, File and Temp)– Additional SQL sections in Report

• Comparison to AWR• Check Metalink Note: 394937.1 (incomplete)

STATSPACK – Host StatisticsHost CPU (CPUs: 32) ~~~~~~~~ Load Average Begin End User System Idle WIO WCPU ------- ------- ------- ------- ------- ------- -------- 0.04 0.03 3.38 1.06 95.56 3.13 ####### Instance CPU ~~~~~~~~~~~~ % of total CPU for Instance: 3.64 % of busy CPU for Instance: 81.90 %DB time waiting for CPU - Resource Mgr: Memory Statistics Begin End ~~~~~~~~~~~~~~~~~ ------------ ------------ Host Mem (MB): 65,274.7 65,274.7 SGA use (MB): 6,144.0 6,144.0 PGA use (MB): 2,038.8 2,233.6 % Host Mem used for SGA+PGA: 12.5 12.8 -------------------------------------------------------------

STATSPACK – Host Statistics

• Calculation of Total and Busy CPU (spcpkg.sql)% of total CPU for Instance:' ch45n, 100*

((:dbcpu+:bgcpu)/1000000) / (:ttics) pctval% of busy CPU for Instance:' ch45n, 100*

((:dbcpu+:bgcpu)/1000000) / ((:btic)/100) pctval

• Available in Time Model (V$SYS_TIME_MODEL)• Discrepancy between estimated and actual CPU

– (Busy_Time + Idle_Time) vs. (No.of.secs * No. of CPUs)– Usually present when load is high (queue depth/wait for

CPU)

• Note memory statistics – tracked in V$OSSTAT• This section not reported in AWR Report!!!

STATSPACK – Response HistogramsWait Event Histogram DB/Inst: MYRAC/MYRAC1 Snaps: begin_snap-end_snap -> Total Waits - units: K is 1000, M is 1000000, G is 1000000000 -> % of Waits - column heading: <=1s is truly <1024ms, >1s is truly >=1024ms -> % of Waits - value: .0 indicates value was &lt.05%, null is truly 0 -> Ordered by Event (idle events last) Total ----------------- % of Waits ------------------ Event Waits <1ms <2ms <4ms <8ms <16ms <32ms <=1s >1s -------------------------- ----- ----- ----- ----- ----- ----- ----- ----- ----- enq: TX - row lock content 7561 4.1 .0 .0 .1 .1 95.8 enq: WF - contention 7 57.1 42.9 enq: WL - contention 4 75.0 25.0 gc buffer busy 1893 74.2 4.5 3.4 11.5 3.4 1.2 1.7 gc cr block busy 33K 21.9 8.4 3.5 5.0 5.0 27.3 28.7 gc cr block congested 117 3.4 23.1 53.8 18.8 .9 gc cr disk read 1626 99.6 .4 .1 gc cr failure 1 100.0 <snip>SQL*Net break/reset to cli 2276 99.3 .5 .1 .2 SQL*Net message from dblin 683 43.6 25.0 14.5 4.2 6.4 2.0 4.1 SQL*Net message to dblink 683 100.0 <snip>db file scattered read 2070K 91.4 7.3 .7 .5 .1 .0 .0 db file sequential read 1413K 96.4 1.2 .6 1.5 .3 .0 .0

STATSPACK – Response Histograms

• Response Time Histograms• Snapped for Event, File and Temp

– V$EVENT_HISTOGRAM– V$FILE_HISTOGRAM– V$TEMP_HISTOGRAM

• Helpful in seeing spread, bumps in wait events– Troubleshooting network response (example later)

• SQL*Net break/reset to client - Client traffic

• SQL*Net message to client (and “to dblink”) – Inter server

• gc cr block congested (Internode traffic) – Intra instance

• Not present in AWR (neither snapped or reported)

STATSPACK – New SQL sections

• New SQL reporting sections in Oracle DB 10g SP– SQL ordered by CPU : From CPU_TIME in V$SQL– SQL ordered by Elapsed: From ELAPSED_TIME in V$SQL– SQL ordered by Cluster Wait Time: From new

CLUSTER_WAIT_TIME in 10g V$SQL• Report compares total time for SQL statements captured to total

time reported in the DB

SQL ordered by CPU DB/Inst: MYRAC/MYRAC1 Snaps: begin_snap-end_snap -> Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code. -> Total DB CPU (s): 1,826 -> Captured SQL accounts for 202.4% of Total DB CPU -> SQL reported below exceeded 1.0% of Total DB CPU CPU CPU per Elapsd Time (s) Executions Exec (s) %Total Time (s) Buffer Gets ---------- ------------ ---------- ------ ---------- --------------- 947.13 437 2.17 51.9 3503.86 29,619,674 select q_name, state, delay, expiration, rowid, msgid, dequeue _msgid, chain_no, local_order_no, enq_time, enq_tid, step_no,

New and changed views

• Large number of new as well as changed views• (Sometimes) Inadequate documentation, but

powerful uses!• Classified by

– Services related– In-memory metrics– Response Histograms– Extensions to existing views– Interesting views– Common columns

Service related views

• “Service” concept created in Oracle 8.0• Provides ability to connection to an abstract entity• SERVICE_NAME column in various views• New views

– V$SERVICES : Services description (failover and load balancing information included)

– V$SERVICE_STATS : Workload statistics– V$SERVICE_EVENT : Events by service

Service related viewsSQL> select name, goal, dtp, aq_ha_notification, clb_goal 2* from v$services;

NAME GOAL D AQ_HA_NOTIFICATION CLB_GOAL-------------------- ---------- - ------------------ ----------APPLSYS.WF_CONTROL NONE N NO LONGMYRAC1.MYDOM.COM NONE N NO LONGSYS$BACKGROUND NONE N NO SHORTSYS$USERS NONE N NO SHORT

SQL> select service_name, stat_name, value 2 from v$service_stats 3 where stat_name in 4 ('cluster wait time','db block changes'); -- among 28 different stats

SERVICE_NAME STAT_NAME VALUE-------------------- ------------------------------ ----------------SYS$USERS db block changes 34,618,836MYRAC1.MYDOM.COM db block changes 471,456,178APPLSYS.WF_CONTROL db block changes 0SYS$BACKGROUND db block changes 2,383,337SYS$USERS cluster wait time 52,810,072,281MYRAC1.MYDOM.COM cluster wait time 798,080,328,466APPLSYS.WF_CONTROL cluster wait time 0SYS$BACKGROUND cluster wait time 4,405,806,181

Service related viewsSQL> select service_name, event, total_waits, 2 total_timeouts, time_waited 3 from v$service_event 4 where event in ( 5 'latch: library cache', 'read by other session'); -- from 114 events

SERVICE_NAME EVENT TOTAL_WAITS TIMEOUTS TIME_WAITED---------------- --------------------- ----------- -------- -----------MYRAC1.MYDOM.COM read by other session 25107023 23985 10848655MYRAC1.MYDOM.COM latch: library cache 420975 0 4352231SYS$BACKGROUND read by other session 29 0 14SYS$BACKGROUND latch: library cache 6742 0 104454SYS$USERS read by other session 27368974 435 3657701SYS$USERS latch: library cache 144347 0 734451

• Ability to segment and measure workload• Needs to be setup (becomes complex in RAC environments)

In-memory metrics

• V$METRIC/V$SYSMETRIC (V$SYSSTAT) -> V$SYSMETRIC_HISTORY

• V$EVENTMETRIC (V$SYSTEM_EVENT) -> V$EVENT_METRIC_HISTORY

• V$SYSMETRIC_SUMMARY (Avg/Min/StDev)• WRH$_SYSMETRIC_SUMMARY• V$METRICNAME / V$METRICGROUP• Metrics -> Rate of change of statistics counters• Alerts on rate -> Server Generated Alerts

(changeable via EM)• Short-lived (3 mins of 15 secs, 1 hr of 60 secs)

In-memory metricsSQL> select event, wait_time_milli, wait_count 2 from v$event_histogram 3* where event like 'SQL*Net %to client'EVENT WAIT_TIME_MILLI WAIT_COUNT------------------------------ --------------- ----------SQL*Net message to client 1 137034612SQL*Net message to client 2 19183SQL*Net message to client 4 9922SQL*Net message to client 8 5446SQL*Net message to client 16 2931SQL*Net message to client 32 1519SQL*Net message to client 64 752SQL*Net message to client 128 310SQL*Net message to client 256 111SQL*Net message to client 512 29SQL*Net message to client 1024 1SQL*Net message to client 2048 1SQL*Net more data to client 1 8582781SQL*Net more data to client 2 34556SQL*Net more data to client 4 22114SQL*Net more data to client 8 20108

Existing/New views

• Number of existing views expanded– V$SQL, V$SESSION

• Information merged from various views– V$SESSION (V$SESSION_WAIT and V$LOCK)

• New visibility– V$SQL_BIND_CAPTURE– V$SQL_SHARED_CURSOR

• Common Columns– WAIT_CLASS and related

• WRH Tables exposed via DBA_HIST_% views• V$PROCESS_MEMORY – session wise memory• V$SQLSTATS – Low overhead access

V$SESSION view

• Wait information merged from V$SESSION_WAIT– EVENT, P1 – P3, SEQ#, WAIT_CLASS

• Lock information from V$LOCK– BLOCKING_SESSION, BLOCKING_SESSION_STATUS,

BLOCKING_INSTANCE

• Tons of new columns– SQL_ID (Current and Previous)– SQL_CHILD_NUMBER (Current and Previous)– PLSQL related information (Entry, Subprogram, Object, etc)– SQL_TRACE columns (binds and waits as well)– CLIENT_IDENTIFIER (DBMS_MONITOR)

• No need to join to V$SESSION_WAIT, V$LOCK now

V$SQL view

• Complete text in SQL_FULLTEXT• Parallel execution (PX_SERVERS_EXECUTION)• Different types of wait times

– APPLICATION_WAIT_TIME– CONCURRENCY_WAIT_TIME– CLUSTER_WAIT_TIME– USER_IO_WAIT_TIME– PLSQL_EXEC_TIME– JAVA_EXEC_TIME

• Additional details: – PARSING_SCHEMA_NAME– Optimizer details– BIND_DATA– LAST_LOAD_TIME (Docs: LAST_ACTIVE_TIME??)

V$SQL related views

• V$SQL_OPTIMIZER_VIEW– Optimizer parameters for SQL_ID and particular child cursor

• V$SQL_PLAN– TIMESTAMP, OTHER_XML, QBLOCK_NAME, etc.

• DBMS_XPLAN exposes details*• V$SQL_SHARED_CURSOR

– Why was a cursor not shared? – USER_BIND_PEEK_MISMATCH column– Groundwork for 11g bind-awareness/bind-sensitiveness

• V$SQL_BIND_CAPTURE– Use with ASH to get some bind values

* Undocumented : “ADVANCED” parameter to get OTHER_XML details

Event Breakout

• Event names for “blocking” type events changed• “latch free” now has 29 types (10.2.0.3)

– latch: cache buffers chains – latch: library cache – latch: library cache pin

• “enqueue” has 205 types (10.2.0.3)

– enq: TX - row lock contention (Waiting for Row lock)– enq: UL – contention (Waiting for User generated lock)– enq: XR - quiesce database (Waiting for DB Quiesce)– enq: ST – contention (Space transaction – rare now with LMT)

• “read by other session” (BBW with reason code 130)• Break out at all levels (session/system- compare R1)• Major change in monitoring / reporting code!!!

Mutexes – Boon or Bane?

• Low overhead mechanism replacing some latches• “Simulated” on certain platforms

– HP-UX uses a CAS (“compare-and-swap”) simulator– This itself is a latch: quite an overhead

• Track using V$MUTEX_SLEEP and V$MUTEX_SLEEP_HISTORY

• “_kks_use_mutex_pin = FALSE” turns this off• Snapshotted in STATSPACK, not in AWR

Operating System Statistics• Set SQL*Plus format to get right value! (issue in AWR)

SQL> select stat_name, value 2 from v$osstat;STAT_NAME VALUE---------------------------------------------------------------- ----------NUM_CPUS 24IDLE_TIME 802033123BUSY_TIME 878091185USER_TIME 489231709SYS_TIME 388859476IOWAIT_TIME 187539358AVG_IDLE_TIME 33398667AVG_BUSY_TIME 36564711AVG_USER_TIME 20362160AVG_SYS_TIME 16180042AVG_IOWAIT_TIME 7794964OS_CPU_WAIT_TIME 2.6867E+13RSRC_MGR_CPU_WAIT_TIME 0LOAD 2.359375NUM_CPU_SOCKETS 24PHYSICAL_MEMORY_BYTES 1.0287E+11VM_IN_BYTES 7868502024VM_OUT_BYTES 0

Time Model• CPU breakup; updated every 3 seconds!!!SQL> select stat_name, value from v$sys_time_model where value > 0;STAT_NAME VALUE--------------------------------------------- --------------DB time 893170091346 DB CPU 176244910473 sequence load elapsed time 10215471781 parse time elapsed 4524012412 hard parse elapsed time 3657262901 failed parse elapsed time 103540062 hard parse (sharing criteria) elapsed time 365217641 hard parse (bind mismatch) elapsed time 5923514 repeated bind elapsed time 14768010 connection management call elapsed time 328536127 PL/SQL execution elapsed time 5554924592 PL/SQL compilation elapsed time 333815896background elapsed time 13782131027 background cpu time 4572399582

Wait ModelSQL> select wait_class, time_waited, total_waits from v$system_wait_class;WAIT_CLASS TIME_WAITED TOTAL_WAITS-------------------- ---------------- ----------------Other 1370371162 10777690366Application 11031616 77468Configuration 433075 3972043Administrative 986 10Concurrency 5069513044 4023651698Commit 4187059 4606985Idle 26816217176 1179884266Network 1964510 152943745User I/O 845512795 3197266600System I/O 21813081 47778673

Wait Class

• Types of wait: classified by WAIT_CLASSSQL> select wait_class, count(*) from v$event_name 2 group by wait_class;WAIT_CLASS COUNT(*)----------------- -----User I/O 17Application 12Network 27Concurrency 25Administrative 46Configuration 23Scheduler 2Cluster 47Other 592Idle 62System I/O 24

Hidden surprises

• GROUP BY does not ensure ORDER BY– New code base avoids sort for GROUP BY operation– Order was never guaranteed– Large amount of legacy/custom code needs change– Investigate “_gby_hash_aggregation_enabled” parameter

• System Statistics– “CPU Cost” optional in 9i– Fully functional (by default) in 10g– Sample collected when DB installed/upgraded– Check in SYS.AUX_STATS$ view– See Metalink Notes: 457228.1, 153761.1, 149560.1– Collecting System Stats does NOT invalidate shared pool

Hidden surprises

• Dynamic sampling– 9i default was 1– 10g default is 2– all unanalyzed tables are sampled– Number of blocks sampled: twice default number (2x32=64)– Impact on Global Temp tables– Impact on parse (not affected by plan permutation limits)

• Statistics gathering and Table monitoring– Monitoring ON by default– Used by Automatic Stats gathering (Dictionary stats included)– Trigger fixed at 10%, changeable in 11g– Stats collection for Fixed table (new but optional)

Hidden surprises

• DBMS_STATS– 9i and below: Defaults were fixed– 10g and above: Defaults can be changed (boon or bane?)– Many parameters default to “decided by Oracle”– Examples:

• NO_INVALIDATE: DBMS_STATS.AUTO_INVALIDATE

• CASCADE: DBMS_STATS.AUTO_CASCADE

• ESTIMATE_PERCENT: DBMS_STATS.AUTO_SAMPLE_SIZE

• METHOD_OPT: FOR ALL COLUMNS SIZE AUTO

• GRANULARITY: AUTO (For partitioned objects only)

– Automatically stores past 31 days DBA_TAB_STATS_HISTORY– DIFF_TABLE_STATS_* function in 10.2.0.4

Useful sections: AWR Report• Segment statistics in AWR report

– Same as “Top 5 Segments” in Level 7 STATSPACK reports (9i+)– Segments by Global Cache Buffer Busy (RAC only, new section in 10g)– Segments by CR Blocks Received (RAC only)– Segments by Current Blocks Received (RAC only)

• New GC Load profile and GC Efficiency percentagesGlobal Cache Load Profile~~~~~~~~~~~~~~~~~~~~~~~~~ Per Second Per Transaction --------------- --------------- Global Cache blocks received: 1,375.70 2.90 Global Cache blocks served: 164.77 0.35 GCS/GES messages received: 5,165.31 10.88 GCS/GES messages sent: 8,684.54 18.30 DBWR Fusion writes: 0.63 0.00 Estd Interconnect traffic (KB) 15,028.80Global Cache Efficiency Percentages (Target local+remote 100%)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Buffer access - local cache %: 97.41Buffer access - remote cache %: 0.43Buffer access - disk %: 2.16

Extracting data from the AWR

• Complete source in paper• Adaptable for different types of extracts

/* This cursor fetches details of the current snapshot plus the next one using the LEAD function. We will use this to

make sure that there was no DB restart in-between */cursor snapshot isselect snap_id, lead(snap_id, 1, 0) OVER (ORDER BY snap_id),startup_time, lead(startup_time, 1) OVER (ORDER BY snap_id),to_char(begin_interval_time) begin_interval_time,to_char(end_interval_time) end_interval_timefrom sys.dba_hist_snapshotwhere instance_number = v_instance_number -- For RAC instancesand dbid = (select dbid from v$database);

Extracting data from the AWR-- We don't subtract for certain types such as NUM_CPUS, etc.cursor osstat isselect e.instance_number, e.stat_name,case when e.stat_name in

('NUM_CPU_SOCKETS','NUM_CPUS','NUM_CPU_CORES','LOAD') then e.value else e.value - b.valueend stat_valuefrom sys.dba_hist_osstat b, sys.dba_hist_osstat ewhere b.stat_id = e.stat_idand b.snap_id = v_begin_snap_id and e.snap_id = v_end_snap_idand b.instance_number = e.instance_numberand b.instance_number = v_instance_number;

Extracting data from the AWRv_instance_number := &1; -- Send this from command lineopen snapshot; LOOP fetch snapshot into v_begin_snap_id, v_end_snap_id, v_begin_startup_time, v_end_startup_time, v_begin_interval_time, v_end_interval_time; exit when snapshot%NOTFOUND; -- Run through only if the startup times for both snaps are same! -- also, avoid the last line (lead will return 0 for end_id) if ( v_begin_startup_time = v_end_startup_time ) and ( v_end_snap_id != 0 ) then open osstat; loop fetch osstat into v_instance_number, v_stat_name, v_value; exit when osstat%NOTFOUND; dbms_output.put_line(v_end_snap_id || ',' || to_char(v_end_interval_time, 'DD-MON-YY HH24:MI') || ',' || v_stat_name || ',' || v_value); end loop; close osstat; end if; END LOOP;close snapshot;end;

Extracting data from the AWRSample output: (portion of output)SQL> @awr_osstat 1old 38: v_instance_number := &1; -- Send this from command linenew 38: v_instance_number := 1; -- Send this from command line5363,18-FEB-08 00:00,NUM_CPUS,245363,18-FEB-08 00:00,IDLE_TIME,59751065363,18-FEB-08 00:00,BUSY_TIME,26647275363,18-FEB-08 00:00,USER_TIME,9709335363,18-FEB-08 00:00,SYS_TIME,16937945363,18-FEB-08 00:00,IOWAIT_TIME,5312655363,18-FEB-08 00:00,LOAD,.35058593755363,18-FEB-08 00:00,NUM_CPU_SOCKETS,245363,18-FEB-08 00:00,PHYSICAL_MEMORY_BYTES,05363,18-FEB-08 00:00,VM_IN_BYTES,235028645363,18-FEB-08 00:00,VM_OUT_BYTES,0--5364,18-FEB-08 01:00,NUM_CPUS,245364,18-FEB-08 01:00,IDLE_TIME,60183395364,18-FEB-08 01:00,BUSY_TIME,26840435364,18-FEB-08 01:00,USER_TIME,9677115364,18-FEB-08 01:00,SYS_TIME,17163325364,18-FEB-08 01:00,IOWAIT_TIME,600067<snip>

New features in DBMS_XPLAN

• Excellent alternative for EXPLAIN_PLAN• Introduced in 9i, expanded in 10g

– DISPLAY_AWR - Plan stored in the AWR– DISPLAY_CURSOR – V$SQL cursor cache– DISPLAY_SQLSET - Plan of a given statement

stored in a SQL tuning set (STS)– Simple to use:

• “select * from table(dbms_xplan.display_awr(‘<SQL_ID>’, options));”

– Displays all child cursors if present

New features in DBMS_XPLANSQL> select * from table(dbms_xplan.display_cursor('g6jzbgnku8024',NULL,'ADVANCED'));PLAN_TABLE_OUTPUT-------------------------------------------------------------------------------------------SQL_ID g6jzbgnku8024, child number 0-------------------------------------SELECT R.RESPONSIBILITY_NAME FROM FND_RESPONSIBILITY_VL R WHERE R.RESPONSIBILITY_ID = :1 AND R.APPLICATION_ID = :1Plan hash value: 3221072286---------------------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |---------------------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | | | 2 (100)| || 1 | NESTED LOOPS | | 1 | 51 | 2 (0)| 00:00:01 ||* 2 | INDEX UNIQUE SCAN | FND_RESPONSIBILITY_U1 | 1 | 10 | 1 (0)| 00:00:01 || 3 | TABLE ACCESS BY INDEX ROWID| FND_RESPONSIBILITY_TL | 1 | 41 | 1 (0)| 00:00:01 ||* 4 | INDEX UNIQUE SCAN | FND_RESPONSIBILITY_TL_U1 | 1 | | 0 (0)| |---------------------------------------------------------------------------------------------------------Query Block Name / Object Alias (identified by operation id):------------------------------------------------------------- 1 - SEL$F5BB74E1 2 - SEL$F5BB74E1 / B@SEL$2 3 - SEL$F5BB74E1 / T@SEL$2 4 - SEL$F5BB74E1 / T@SEL$2Outline Data-------------

/*+ BEGIN_OUTLINE_DATA IGNORE_OPTIM_EMBEDDED_HINTS OPTIMIZER_FEATURES_ENABLE('10.2.0.3') OPT_PARAM('_b_tree_bitmap_plans' 'false') OPT_PARAM('_fast_full_scan_enabled' 'false')*/

New features in DBMS_XPLAN

Peeked Binds (identified by position):--------------------------------------

1 - :1 (NUMBER): 50357 2 - :1 (NUMBER, Primary=1)

Predicate Information (identified by operation id):---------------------------------------------------

2 - access("B"."APPLICATION_ID"=:1 AND "B"."RESPONSIBILITY_ID"=:1) 4 - access("T"."APPLICATION_ID"=:1 AND "T"."RESPONSIBILITY_ID"=:1 AND "T"."LANGUAGE"=USERENV('LANG'))

Column Projection Information (identified by operation id):-----------------------------------------------------------

1 - "T"."RESPONSIBILITY_NAME"[VARCHAR2,100] 3 - "T"."RESPONSIBILITY_NAME"[VARCHAR2,100] 4 - "T".ROWID[ROWID,10]

SQL_ID g6jzbgnku8024, child number 1-------------------------------------SELECT R.RESPONSIBILITY_NAME FROM FND_RESPONSIBILITY_VL R WHERE R.RESPONSIBILITY_ID = :1 ANDR.APPLICATION_ID = :1

<snipped out further information about child cursor 1 and 2>

Items Learned in this Session

• So there you have it all!• This was a summary of a few of the useful features• Hopefully, this adds to the vast information out there• Where do you go from here?

– Papers, OTN, Blogs, and….. the Oracle manuals!

• What do you plan to use when you get back to the office?

Questions and feedback

Questions?

Contact information: ora_apps_dba_y@yahoo.com

Please fill up your evaluation form!

Session # 319

Oracle DB 10g: An enlightened revisit

Thank you!