WaitScopeUpload the trace. See where every second went.
WaitScope reads Oracle event 10046 traces and builds the session's response time profile: CPU, each wait and each SQL statement, adding up exactly to the total time. Nothing to install on the database.
The trace is deleted as soon as the analysis finishes. Only the report remains.
Trace excerpt (.trc)
FETCH #1:c=200,e=1600,p=1,cr=10,cu=0,mis=0,r=1,dep=0
WAIT #1: nam='db file sequential read' ela= 1000 file#=1 block#=100
WAIT #1: nam='SQL*Net message from client' ela= 5000 driver id=1
STAT #1 id=1 cnt=1 op='TABLE ACCESS BY INDEX ROWID T (cr=10 pr=1 time=1500 us)'
Response time profile
| Component | Share | % of total |
|---|---|---|
| SQL*Net message from client | 71.3% | |
| db file sequential read | 18.5% | |
| unaccounted-for time between calls | 4.1% | |
| CPU: FETCH dbcalls | 2.8% | |
| 5 other components | 3.3% | |
| Total time | 100.0% |
The session spent most of its time waiting for the application SQL tuning does not reduce this time: look at the application, the network and the number of round trips.
From trace to profile in three steps
It works with the trace Oracle itself writes. No agent, no connector, no access to your database.
-
Turn on tracing for the slow session
Use DBMS_MONITOR with waits and without bind values. ALTER SESSION with event 10046 works too.
EXEC DBMS_MONITOR.SESSION_TRACE_ENABLE( session_id => 123, serial_num => 4567, waits => TRUE, binds => FALSE); -- run the slow operation EXEC DBMS_MONITOR.SESSION_TRACE_DISABLE( session_id => 123, serial_num => 4567); -
Upload the file
From the browser or the Android app: the .trc, compressed as zip, gz, bz2 or tar, or the whole folder. Files from the same operation can become a single analysis.
-
Read the profile
When the analysis finishes, the report opens with the total time, the profile by component and by wait class, the SQL statements with their plans, and the diagnosis.
A report that accounts for all of the time
Each line of the profile is a part of the total time, and the lines add up to 100%. From there, the report drills down to the statements, plans and objects that mattered.
Response time profile
Total time split into CPU by call type, each wait event and unaccounted-for time, also grouped by Oracle wait class.
SQL statements and plans
Each statement by its contribution to total time, with its calls, the plan from the STAT lines and the operations where the optimizer misestimated row counts.
Diagnosis
Patterns that usually explain the profile: waiting on the application, slow reads, hard parsing, row-by-row PL/SQL loops, commits and locking.
Objects and PL/SQL
The objects with the most wait time and ready-to-run queries for the database: columns, indexes, statistics and the PL/SQL source.
Deadlocks (ORA-00060)
The wait-for graph, the sessions, and the SQL and PL/SQL stack of the session that got the error, with a diagnosis by lock type.
Several traces from one operation
When the application changes tracefile_identifier, one operation spreads across several files. WaitScope joins the pieces in time order.
The trace does not stay on the server
Production traces carry SQL and, sometimes, personal data. WaitScope keeps only what it needs to show the report.
- Deleted after the analysis
- The uploaded file leaves the server as soon as the analysis finishes, whether it succeeded or failed. Only the report remains, for the retention period.
- Hosted in Brazil
- The analysis runs, and the report is stored, on a server in Brazil.
- Only you see your analyses
- Each account sees only what it uploaded. Not even the console administrator can see the content.
- Literals hidden
- Quoted text and numbers with 6 or more digits show as *** in the SQL you view and download. It is on by default and can be turned off in your account.
- Two-step verification
- Every account signs in with a password and a code from an authenticator app.
- Nothing on your database
- No agent, no schema and no database connection: WaitScope only sees the file you choose to upload.
Frequently asked questions
Which traces does WaitScope read?
Event 10046 traces with waits (level 8 or 12) and deadlock traces (ORA-00060). Old traces, with times in centiseconds, work too. Other Oracle files, such as 10053 traces and the alert log, are recognized and refused with instructions on how to produce a 10046 trace.
How is it different from TKPROF?
TKPROF organizes the trace by statement. WaitScope starts from the session's total time and shows how much each part weighed, including time outside the database, such as waiting on the application, and time the trace does not explain. Statements and plans come next, in order of contribution.
Does it handle large traces?
Yes. Each upload can be up to 4 GiB, and the file can be compressed. Reading is streamed: a 119 MB trace with 2.1 million lines is read in about 4 seconds.
Is it a monitoring tool?
No. WaitScope analyzes the trace of one operation when you need to understand where its time went. It does not connect to the database or collect anything continuously.
How long is the report available?
For the retention period, 7 days by default. You can download the report as HTML or JSON and delete the analysis earlier.
Is there an app?
There is an Android app. It uploads large traces in chunks, resumes the upload if the connection drops and opens the reports. Reports and screens are available in English, Portuguese and Spanish.
How much does it cost?
Plans have not been published yet. During early access, write to contato@waitscope.com to arrange your use.
Analyze your next trace with WaitScope
Request access and upload the trace of the slow operation. The report is ready as soon as the analysis finishes.