In order to see exactly, grabbed an AWR report.
It is found that the load of the system is really serious, the redo per second is 1.6M, the load of the visible system is not mainly on select, there may be some operations such as DML is very frequent.
Looked at the waiting event. It's all about lock. It was a bit of a wonder at this time. What kind of operation can cause a serious lock wait.
Top 5 Timed Foreground Events
This time how to explain the execution plan is very efficient, but the execution time is very long problem.
The first conjecture is that the load on the system is increasing, and it may be slow to get the data. But on the other hand, it won't be so much slower.
So this conjecture is not tenable.
The second conjecture is that there is a lot of concurrent DML, and the update is done, causing some other update to wait. Of course, there is a problem with this design.
But the time has passed long, v$session inside already had no corresponding record. How to verify your own conjecture.
Or the use of ash. There is a chapter in the details of blocking sessions.
http://blog.itpub.net/23718752/viewspace-1285185/
A system problem (go) caused by an SQL statement that executes 4 seconds