Re: Comparing apples to apples on Exadata

From: Will Beldman <>
Date: Mon, 18 Dec 2017 15:27:13 -0500
Message-ID: <2143373.ITR9u0BbiI_at_wbeldma>

Yes, I understand. There's a few different possibilities and I'll have to dig deep.

Your blog post about direct path reads seems to be highly relevant. If I execute this query:
SELECT v$buffer_pool.buffers,dba_tables.blocks FROM v$buffer_pool, dba_tables WHERE table_name ='##TABLE_NAME##';

Here is what I see:
Database 1:

---------- ----------

     33445 386032

Table blocks are greater than the buffer cache so a direct read is triggered (?)

Database 2:

---------- ----------

    584588 434368

Table blocks are less than the buffer cache so a direct path read is not triggered (?)

Am I understanding this correctly? Would it make sense to consider *reducing* the buffer cache on Database 2? Does this force the database to bypass it's own buffer cache and consult the storage cache directly instead?

On Monday December 18 2017 09:00:36 PM Tanel Poder wrote:
> I just listed a few semi-educated guesses of what *could* be causing this,
> in addition to Jonathan's suggestions... but they are guesses.
> The easiest way to start narrowing this down would be to either run Snapper
> or just look into V$SESSTAT metrics after running both of these queries in
> their databases and looking for metrics like Jonathan mentioned (table
> fetch continued row, %undo records applied ones and cell blocks processed%
> ones). If you paste the numbers here, we can help :)
> --
> Tanel Poder

Received on Mon Dec 18 2017 - 21:27:13 CET

Original text of this message