Re: Comparing apples to apples on Exadata

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:

   BUFFERS BLOCKS
---------- ----------

     33445 386032

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

Database 2:

   BUFFERS BLOCKS
---------- ----------

    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
> http://blog.tanelpoder.com
>

--
http://www.freelists.org/webpage/oracle-l