Two things about your comment (apart from the fact that this isn’t a forum):

a) it’s not hard to find out how to reach me – my email address is on the home page for the blog, and if you didn’t think of looking there then a google search for “jonathan lewis email” returns my home page as the first hit, showing my email address and cell-phone number.

b) you’ve previously posted this on the OTN database forum – I participate in the forum when I have time, so it’s particularly ill-mannered to post this on my blog when I’ve implicitly declined to take part in discussing your problem. It would have been slightly less rude to post a link to the original:
https://forums.oracle.com/forums/thread.jspa?threadID=2415815&tstart=0

As it stands to date: I think Hemant Chitale has made an interesting observation, and I would have dumped a couple of the blocks that you’ve reported as the targets of single block reads to see what’s in them.

I know what i am taking or asking is totally irrelevant to the above discussion but i have been working on one issue for quite some time so i though i could read you but i didn’t find way so i have chosen this plafform

why db file sequential read wait event shows up if table is accessing full table scan. I know sometime oracle choose to retrieve some blocks(Like segment header blocks, undo blocks) but in my case the only wait event i can see in whole trace file is db file sequential read wait event and i can assure you that whole table is accessing through single block request that i have verified through owi views.

In addition to this, i have used parallel hints to do the same but still both parallel process are again accessing single blocks instead of multiblocks.

So i have started looking into columns structure and something like that and finanlly i have identified two columns in the select clause of my select stmt is making this strange behaviour. If i keep those two columns in the select clause then it choose single block request(db file sequential read) and if i remove those from select clause then it works the way it’s supposed to work.

Sorry for posting this question in blog.

Thanks for the additional investigation on this. I raised the original question on OTN, and did a short follow up post on my own blog. As you say it is definitely something about the way that Oracle transforms ANSI SQL syntax into its own native equivalent before then optimizing it and producing an execution plan.

The real SQL is even more complex than the test case I gave – there are 7 tables being joined together. And the main problem is that most columns allow NULL values, which prohibits the use of certain indexes (but not all indexes). But the other tables are very small in size and have negligible access cost.

There are also some manual rewrites I can do to the SQL to improve things, such as replacing an OUTER join by an INNER join when the WHERE clause applies a constraint to a column from the OUTER table – if the OUTER join generated a pseudo row of NULL values then it could not match the WHERE constraint of being equal to a real value. I’ve not had a chance to do a full rewrite of the SQL yet, because of the complexity of it all and other more pressing problems. But I now know what is going on within the query, and am ready to deal with it when the time arises.

Thanks again for the additional information, and to the others that replied on the OTN forum.

John