Earl Shaffer will give a presentation on using Automatic Workload Repository (AWR), Automatic Database Diagnostic Monitor (ADDM), and Active Session History (ASH) to monitor and tune an Oracle database. He has over 30 years of experience as an Oracle DBA. The presentation will cover the basics of AWR, real examples of AWR reports and queries, and tips on using AWR, ADDM, and ASH to proactively manage database performance.
Apidays Singapore 2024 - Building Digital Trust in a Digital Economy by Veron...
Earl Shaffer Oracle Performance Tuning pre12c 11g AWR uses
1. 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”
2. 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
3. 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
4. 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
5. 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
6. 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
7. 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
8. 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
9. 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.
10. 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
11. 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
13. 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
14. 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.
15. 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
16. 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
17. 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
18. 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
19. 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
20. 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.
21. 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'
22. 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'
23. 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'
24. 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