Hello,
we had the same issue in virtual appliance PI after upgrading to 3.2 (from 3.0 or 3.1). About 1500 IOPS for read, 500-600 MB/s sustained, usually continues from 1 hour to few, dissappeares by itself, reoccures after few hours. No any tasks/heavy deploys or activity during that time, that might correlate, no even logged on users to GUI. Having investigated closely from VM shell found up to 15 threads in Oracle DB persistently doing table full access through some 50-60 K records table, each taking 30 to 60 MB/s read. With help of strong DBA competence created an index over 1 or 2 columns, and the behaviour disappeares. So we have mitigated negative impact of excessive IO by DB data tier optimisation reducing physical read / fetches from disk. Once we did that (by our own) and shared results with TAC we got an expected reply that this is not supported config and we should not proceed further.
Having conducted few webex and all those mandatory check for virtual hardware sizing and ESX resource priority aspects TAC came up with same solution - create a combined index for 2 columns.
So at the end of the day we still have enormous numbers of SELECt statement execution, however they are effective from DB read perspective.
Obviously this need to be fixed at the code level / business logic.
Hope this helps,
Irakli
