Here's part two!
these are incredibly informative and a pleasure to read. looking forward to part 3.
Thanks! Part three will be out in the next 6 weeks or so.
very interesting - and I do think that the hand-written pictures make everything stick much better in my mind ... I wonder why.
I have a naive question I have been always curious about.
Even in the good old days of 9i, do you happen to know whether there was any good reason that prevented Oracle, after noticing a couple of cached blocks inside a big DB_FILE_MULTIBLOCK_READ_COUNT-sized (say, 128) intended multiblock read, from issuing a 128 read anyway and then simply discard the couple of blocks already cached?
Thanks in advance
Thanks for the feedback, I'm glad that you enjoyed my experiment in illustration approach!
Regarding the handling of partially cached blocks, I suspect that this did not happen because of the layered architecture of the Oracle kernel, combined with legacy. It was probably a complex job to undo much of the logic in the 'read through cache' codepath to support this rather than create a new (and simple) codepath to just read the blocks into the PGA. But it's just a guess
Enter your email address to subscribe to this blog and receive notifications of new posts by email.