Physical I/O

Last week I was involved in solving a performance problem for a customer that suffered from enormous performance slow downs. The funny thing was that there was a special task force assigned to this problem by the customer and they had been working since half december on this problem. That task force consisted of 22 people and some were actually flown in to help solve the problem. A consultant was asked to have a fresh look at the problem by installing Veritas i3 for Oracle (that was used succesfully used in another project). After installing the tool and getting the performance data, he quickly called me after one day to confirm his findings (basically all the wait time was I/O related) and while we spoke on the phone we checked the mount options for the file systems and guess what, the directio mount option was commented out. It was used on many other servers, but on this particular server it was not. After talking to the task force it wasn't clear why this was done. So the decision made to include the directio mount option again and at the same time change two init.ora paramters: optimzer_index_cost_adj and optimzer_index_caching. The database was bounced and a simple batch job was run to validate the performance improvement. That batch job ran before with 50-70 calculations per hour and after the changes it ran with 2500+ calculations per hour. There was a factor of 35-50 times improvement. So this was great news ofcourse, however the next day one of the other databases on the system reported a severe performance problem. And in fact a quick check revealed that it was waiting most of the time in I/O related events. A further analysis showed a couple of things:
1) The Oracle buffer cache was really small and so the File System buffer cache was heavily used to compensate for that small Oracle buffer cache.
2) It also showed that a handfull of statements were responsible for 80+ percent of the I/O workload.
3) In fact it was discovered that one statement did around 600K physical I/Os in just over 2 hours.
4) And there were a couple of other statements just like that.

So it was clear that a handfull of statements that were poorly tuned were responsible for bringing down the performance of the whole machine (when the directio mount was not used). The other team working on this database with the large number of I/Os blamed the other thing for causing a performance problem in their database (in principle they are right about this) and basically wanted the directio option removed. So the question becomes should that be done? Or should the second team fix their SQL and application so that less physical I/O is done and everybody will have good performance? My take on it is that the second team should fix their application and that would be my recommendation, but clearly that team doesn't see it that way.
And a conflict is born ....

So who should win?