Beruflich Dokumente
Kultur Dokumente
DOCID: top_three_sql_scripts_oracle_dba
top_three_sql_scripts_oracle_dba 12-18-2015
Table Of Contents
I. Why?
1. ASH Monitoring
2. LOCK Monitoring
3. SPACE Monitoring
II. Conclusion
III. Additional Resources
Why?
Currently I have 68 SQL scripts that were battle tested on a very busy database serving a popular
internet site. However if you asked me what are the TOP 3 sql scripts that I consider most useful - I
would say its the scripts that allow me to Monitor ASH, LOCKS and SPACE. Because if you have all
three areas covered to the point that it only takes you a few seconds to answer questions such as:
then your life as an Oracle DBA is much easier than a DBA next door!
Do I have your attention? If so, lets dive in and Ill show you the three scripts I use that do
exactly that!
ASH Monitoring
h1.sql is a little gem that I reach for when I am asked to troubleshoot a performance problem that
was reported hours ago. For example lets say its 9:30am and I get a call from a dev saying that her
APEX web application is hanging - she suspects a locking issue. All I need to know at this point is
when the problem was first reported - armed with the start time (lets say 7:00am) I simply do this:
wget https://s3.amazonaws.com/mve-shared/sql/h1.sql
sqlplus / as sysdba
@h1 0700 0930 0 -1 -1
Can you spot the problem? Its SQL*Net message from dblink, there are no locks - its a simple
problem of a badly written distributed query that is waiting on remote DB. That was easy! One other
hidden benefit of this script is that it saves its output in a table under a RUN_ID (in this case
RUN_ID=81) allowing you to compare the output of two RUN_IDs and clearly spot the dierences in
values grouped by WAIT EVENT. This is extremely valuable especially when someone says - this
used to work last week!, you simply do this:
sqlplus / as sysdba
@h1 0700 0930 7 -1 -1
The 7 in the third parameter instructs the script to look 7 days back for the same time frame (7
9:30am). The output of the above report will have its own RUN_ID=82 (next in sequence) and you
can now compare the two using a special script h1d.sql like so:
@h1d 81 82
We didnt need OEM or any GUI apps to get to the bottom of the problem - all because the
diagnostics data is already in AWR tables and is available to us directly from command line /
sqlplus. Years ago - wed have to sample v$session_wait to get similar diagnostics, in fact, I
wrote a complete monitoring system that utilized such technique. But now, Oracle built this into the
core engine in a form of Active Session History (ASH) that automatically samples this data every
second with practically no overhead to the database! That is an incredible level of instrumentation
available to us and it would be a shame not to utilize it beyond what the OEM reports are
capable of.
LOCK Monitoring
My #2 most used script is one that can detect and drill down into Oracles Blocking LOCKs across
an entire Oracle RAC Cluster - locks.sql. Heres how to use it:
wget https://s3.amazonaws.com/mve-shared/locks.sql
sqlplus / as sysdba
@locks.sql
NOTE: if you dont have wget on your system try curl instead:
25 3 2368 3 0 APPUSER_OWNER.DBJOBREQUESTS
Page 7 of 13 HASHJOIN Corporation 2015
top_three_sql_scripts_oracle_dba 12-18-2015
25 3 2368 3 0 APPUSER_OWNER.DBJOBREQUESTS
26 3 2243 3 0 APPUSER_OWNER.DBJOBREQUESTS
27 3 2134 3 0 APPUSER_OWNER.DBJOBREQUESTS
28 3 2132 3 0 APPUSER_OWNER.DBJOBREQUESTS
29 6 3854 3 0 APPUSER_OWNER.DBJOBREQUESTS
30 6 3507 3 0 APPUSER_OWNER.DBJOBREQUESTS
31 6 3417 3 0 APPUSER_OWNER.DBJOBREQUESTS
32 6 3303 3 0 APPUSER_OWNER.DBJOBREQUESTS
33 6 3222 3 1 APPUSER_OWNER.DBJOBREQUESTS
34 6 3135 3 0 APPUSER_OWNER.DBJOBREQUESTS
35 6 2804 3 0 APPUSER_OWNER.DBJOBREQUESTS
36 6 2786 3 0 APPUSER_OWNER.DBJOBREQUESTS
37 4 3818 3 0 APPUSER_OWNER.DBJOBREQUESTS
38 4 2869 3 0 APPUSER_OWNER.DBJOBREQUESTS
39
40 25 rows selected.
41
42 Elapsed: 00:00:00.03
43 blocked sessions from GV$LOCK
44
45 INST_ID BLOCKER_SID INST_ID BLOCKED_SID MIN_BLOCKED REQUEST
46 ---------- ----------- ---------- ----------- ----------- ----------
47 4 3084 6 3135 0 6
48 4 3084 6 3485 0 6
49
50 2 rows selected.
51
52 Elapsed: 00:00:00.02
53 blocked session details from GV$SESSION and GV$SQLTEXT
54
55 Instance........ : 6
56 Sid ............ : 3135
57 Serial ......... : 30604
58 Username ....... : APP1USER_NAME
59 SQL Id ......... : null
60 Prev SQL Id .... : gm424t8fyx3w6
61 Displayed SQL Id : gm424t8fyx3w6
62 Client Info .... : null
63 Machine ........ : dbt4.dc1.mydomain.com
64 OSuser ......... : dbt
65 Process ........ : 1234
This script presented few performance challenges because a self-join query against gv$lock
joined with sys.obj$ to get a list of blocked objects is very expensive in a cluster environment, in
fact its expensive even in a single instance environment. We also have to join gv$session with a
result of self-join query against gv$lock in order to get the SQL_TEXT of the sessions doing
blocking and being blocked - thats extremely slow as well.
To solve the above performance challenges I created two tables and indexed them appropriately:
gv table mapping
Once that was done it was a simple matter of replacing GV$ Table name with COPY Table name on
the key joins and performance improved dramatically. In fact, the script ran so fast that I created a
custom event in my monitoring system and started to trap occurrences of these locks for historical
purposes so that when a developer came to our team and asked if there were any DB locks/blocks
3 hours ago we could simply review our alerts and answer that question with authority providing
exact details on the race condition that caused a block. This was much more helpful than the
generic alert email wed get from OEM stating that session 123 is blocking many sessions on
instances 1,4 and 5 for example.
SPACE Monitoring
I dont buy into the space is cheap mantra because when we are dealing with SAN/FC storage -
its actually quite expensive especially if its FLASH based. If you can eectively find the root cause
of the vanishing space in an Oracle database you can save a good chunk of money for your
organization and make your own life much easier by having fewer requests for new LUNs from the
storage team.
Back in 2014 I was working for a company that operated a very large internet site and our space
consumption was at the rate of 800GB every month, we were adding 4x400GB LUNs to our RAC
cluster every two months. Then, one month we almost doubled our space consumption rate for no
apparent reason. I decided that it was time to find the root cause of the issue and developed a
series of scripts that helped us find the root cause in no time. Ill show you how it works so you can
adopt it in your workflow and DB monitoring.
exec dbms_workload_repository.create_snapshot();
Once you have a fresh AWR Snapshot created its very easy to use the scripts - simply login to the
Oracle DB in question via sqlplus and call the script:
For example to find which segments grew in the last 60 minutes in a tablespace DATA run
segs2.sql as follows:
wget https://s3.amazonaws.com/mve-shared/segs2.sql
sqlplus / as sysdba
@segs2.sql 60 DATA
or if you are interested in what segments grew in a tablespace DATA since the last datafile was
added run segs3.sql as follows:
wget https://s3.amazonaws.com/mve-shared/segs3.sql
sqlplus / as sysdba
@segs3.sql DATA
Conclusion
I am hopeful that the TOP 3 Oracle DBA scripts I described above will make it into your own toolkit
or will give you an inspiration to write your own versions that tackle these three key areas of an
Oracle Database Monitoring: ASH, LOCKs and SPACE.
Additional Resources
If you liked this article and would like more like it, then please subscribe to my newsletter -
Confessions of an Oracle DBA where I share tips, scripts and tricks Ive learned during almost two
decades in the tech field as an Oracle DBA: http://www.dbatoolz.com/subscribe
End.