For a short period in time we had a concurrency issue that lead to subsequent faults in our application (Java, Spring, Hibernate).
Since we are using dictionary managed tablespaces, I first thought about too small sequence cache sizes, but we are using locally managed tablespaces. However, the top statement’s sequence does have a sequence cache size of 1,000. Other frequently used sequences only have a cache size of 20.
Do you know a good starting point for further investigation?
Feel free to request more detailed statistics.
Additional Information
Begin Snap: 19-Mrz-15 22:00:28, 525, 75.8
End Snap: 19-Mrz-15 22:30:48, 695, 43.9
Top 10 Foreground Events by Total Wait Time
-------------------------------------------
| Event | Waits | Total Wait Time (sec) | Wait Avg(ms) | % DB time | Wait Class |
|------------------------------------------|-----------|-----------------------|--------------|-----------|-------------|
| cursor: mutex S | 2,966,994 | 18K | 6 | 18.8 | Concurrency |
| cursor: pin S wait on X | 5,515 | 17,1K | 3094 | 17.9 | Concurrency |
| library cache lock | 96,812 | 13,7K | 142 | 14.3 | Concurrency |
| latch: shared pool | 1,039 | 11,8K | 11314 | 12.3 | Concurrency |
| latch free | 7,105 | 7198 | 1013 | 7.5 | Other |
| library cache: mutex X | 151,055 | 6594,4 | 44 | 6.9 | Concurrency |
| log file sync | 463,819 | 5384,6 | 12 | 5.6 | Commit |
| DB CPU | | 2859,4 | | 3.0 | |
| SGA: allocation forcing component growth | 92 | 1253,3 | 13623 | 1.3 | Other |
| db file sequential read | 403,533 | 1139,1 | 3 | 1.2 | User I/O |
Top Activity (anonymized)
-------------------------
11s4xj38uffuw | update [SESSIONDATA: no triggers, 4 b-tree indices] set [22 COLUMNS] where [ID]=:23
90wgukkg0du5c | select count(*) from [USER_SPECIFIC_DATA] where [OWNED_BY_USER, uses bindings]
d8da2d7yddqv9 | insert into [USER_SPECIFIC_DATA2]
I found out that for many tables in the top activity statements a histogram was created (HEIGHT BALANCED or FREQUENCY), possibly for adaptive cursor sharing.