Earl Shaffer Oracle Performance Tuning pre12c 11g AWR uses
Upcoming SlideShare
Loading in...5
×
 

Earl Shaffer Oracle Performance Tuning pre12c 11g AWR uses

on

  • 347 views

Earl Shaffer

Earl Shaffer
OracleMan Consulting
Oracle Performance Tuning
pre12c
11g AWR uses

Statistics

Views

Total Views
347
Views on SlideShare
347
Embed Views
0

Actions

Likes
2
Downloads
11
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Earl Shaffer Oracle Performance Tuning pre12c 11g AWR uses Earl Shaffer Oracle Performance Tuning pre12c 11g AWR uses Presentation Transcript

  • NYOUG – Summer Meeting – AWR 11g ADDM, ASH and AWR A DBA’s Best Friends Earl D. Shaffer Senior Oracle DBA Planet Payment LinkedIn: “Earl D Shaffer”
  • NYOUG – Summer Meeting – AWR 11g My Oracle qualifications • • • • • • 30+ years of hands-on IS experience Oracle DBA since 1988, Unix, WIN, Linux Project Leader, Forms/Reports/Pro*C Presented Oracle technical papers at 10 international conferences, 25+ elsewhere Hands-on DBA v6, 7, 8i, 9i, 10g, 11g, 12c Oracle Corp Adv Cust Service team alumni
  • NYOUG – Summer Meeting – AWR 11g Format of the Presentation • • • • • • Survey of your Oracle DBA Experience Go through the basic slides Look at real AWR, ASH, and ADDM reports Go through screen captures, graphs, diagrams, and real-life examples See the AWR tables/views for DB 12c If time, go over real scripts that use AWR
  • NYOUG – Summer Meeting – AWR 11g The Bad Old Days • • • • • In 1988, V5.1 was out and 6.0 was coming Oracle v6 through v8.0 had BSTAT/ESTAT reports (but the tables were in SYSTEM) We tuned using “cache hit ratios” Wait info was captured, but hard to get to Before 8i, tuning was “an art” because it was subjective, and hard to repeat
  • NYOUG – Summer Meeting – AWR 11g Working hard to get any real Improvement • • • • • No one wants to get the “DB is slow” call Management usually does not want to buy more RAM or a new, faster server In most cases, you have to make what you have run faster with no additional resources Performance Tuning = Magic Trick? HINT – make a list of things that work, where they work, and use it again next time
  • NYOUG – Summer Meeting – AWR 11g Work Smarter Not Harder • • • • • • Cache hit ratios are deceptive You really want to know: 'what is going on' Need info on all resources inside the DB Need stats on all the SQL recently run Need a way to compare 1pm to 9am Would be nice if the DB did this for us
  • NYOUG – Summer Meeting – AWR 11g AWR to the Rescue • • • • • • • Automatic Workload Repository Auto gather of internal DB statistics Key – stats stored in DB managed tables Easy-to-use views help the DBA use the info Feeds into ADDM and the advisory suite Frequency of stats gather can be changed Statistics retention time can be changed
  • NYOUG – Summer Meeting – AWR 11g What about STATSPACK? • • • • • • Why not just use our friend STATSPACK? Was better than BSTAT/ESTAT Requires an external job to get a snapshot Physical tables need manual management Report is good, but limited Cannot easily compare REP4 to REP5
  • NYOUG – Summer Meeting – AWR 11g V$ACTIVE_SESSION_HISTORY • • • V$ACTIVE_SESSION_HISTORY displays sampled session activity in the database. It contains snapshots of active database sessions taken once a second. A database session is considered active if it was on the CPU or was waiting for an event that didn't belong to the Idle wait class.
  • NYOUG – Summer Meeting – AWR 11g The Players • • • • • ADDM – the AI sub-system of DB rules ASH – active session history, “back info” AWR – Automatic Workload Repository Enterprise Manager – info + GUI + graphs You – use ADDM, ASH, and AWR to monitor the DB, fix problems, proactively plan make the whole environment as effective as possible
  • NYOUG – Summer Meeting – AWR 11g The Basics • • • • • Each stat gather is called a SNAPSHOT A SNAPSHOT is specific to a point in time DBA_HIST_SNAPSHOT joins to the views Each DBA_HIST view has different kinds of stats, from different areas of the DB, but all are specific to a SNAPSHOT There are 40+ 11g DBA_HIST views
  • NYOUG – Summer Meeting – AWR 11g Examples of the DBA_HIST Views • DBA_HIST_SNAPSHOT - Displays snapshot information. • DBA_HIST_SYSSTAT - Displays detailed system statistics • DBA_HIST_FILESTATXS – Displays detailed datafile statistics • DBA_HIST_SQL_SUMMARY – Displays summary and higher level SQL statistics • DBA_HIST_SQLSTAT – Displays detailed SQL statistics • DBA_HIST_WAITSTAT – Displays detailed wait statistics
  • NYOUG – Summer Meeting – AWR 11g Input to AWR Reports Database time “DB Time” is: total time spent by user processes either actively working or actively waiting in a database call Time spent in the DB by foreground sessions includes: •CPU time •IO time •WAIT time Excludes •IDLE wait time
  • NYOUG – Summer Meeting – AWR 11g AWR Reports • • • AWR reports are superior to STATSPACK Based on the events between 2 snapshots Can be run from $ORACLE_HOME/rdbms/admin  awrrpt.sql statistics for a range of snapshot Ids.   awrsqrpt.sql statistics of a particular SQL statement for a range of snapshot IDs, to inspect the performance of a SQL statement. awrddrpt.sql compares detailed performance attributes and configuration settings between two selected time periods.
  • NYOUG – Summer Meeting – AWR 11g AWR Reports (2) • AWR reports can be run as PL/SQL call Call: dbms_workload_repository.awr_sql_report_text • Later we will look at “real” reports • Take report file and email it, or compress it and move it to a filesystem for later review Another example: www.dba-oracle.com/art_orafaq_awr_sql_tuning.htm
  • NYOUG – Summer Meeting – AWR 11g AWR Reports (3) • • AWR reports can be run via VARIABLES Define the variables, then call the report: define begin_snap = &1 define end_snap = &2 define report_name = &3 define report_type = 'text'; define db_name = 'SALES3'; define dbid = 994285834; @/ora/product/11106/rdbms/admin/awrrpti
  • NYOUG – Summer Meeting – AWR 11g Too Much Info? • • With all the DBA_HIST views there, it can get confusing as to which to use, and when Look at these general categories: File statistics General system statistics Concurrency statistics Instance tuning statistics SQL statistics Segment Statistics Undo Statistics Time-model statistics Recovery Statistics
  • NYOUG – Summer Meeting – AWR 11g Some Real Query Examples Look at Buffer Pool stats • HISTBUFPOOLSTAT.SQL Look at logon stats between 2 dates • LOGONHIST.SQL
  • NYOUG – Summer Meeting – AWR 11g Learn, Learn and Learn More • • • • • • Oracle Doc – CD, online Books by well-regarded authors On-line websites and Blogs National conferences and training classes Local Oracle User Groups Email with other local DBAs
  • NYOUG – Summer Meeting – AWR 11g What Never Changes • • • • • End users cannot explain what 'seems slow' really means You wont get more money for RAM More work, fewer people, multiple projects Fixing AA can break BB Everything affects everything else – other DBs, other applications, other programs/systems, SAN use, etc.
  • NYOUG – Summer Meeting – AWR 11g Using these new Powers • • • • • • Looking for SQL which consumes the most resources in your environment See which areas use the same SQL See IO Problems 'over time' See the 'hottest' datafile this week Explore the 'system metrics' Use Enterprise Manager to 'dig in'
  • NYOUG – Summer Meeting – AWR 11g Everyone Needs to Have this Data • • • • • That includes the SAs, DBAs, and Developers SAs can see IO and OS statistics Developers can see SQL and PL/SQL plans Data modelers can see Table/View use Others DBAs can see the statistics and compare them to issues they have seen elsewhere, learn, and share their 'fixes'
  • NYOUG – Summer Meeting – AWR 11g Things To Watch Out For • • • • Watch the size of SYSAUX Don't test fixes in PROD, 'test in test' Don't change the snapshot interval, it is a good balance between too often/too few Unless you run reports and save the output, you cant diagnose a 'down DB'
  • NYOUG – Summer Meeting – AWR 11g Final Tips • • • • • Use AWR in 10g and 11g, and remove STATSPACK from the DB entirely Set the retention to 60 or 90 days Develop your own set of scripts that you can run regularly, OEM 'steps' are often forgotten/lost Review the reports at least once a week Look into ASH also for more information