I would not expect something different in such a case…

Cheers,
Chris

I try to think the impact on real applications, thus extract a testcase:

create table t2 as select rownum id from dual connect by level <= 100;

select /*+ leading(t2) use_nl(t) */ count(*) from t, t2; 

it seems that “physical reads direct” of table t repeats 100 times (100 * 10003)
due to the 100 nested loops on t.

> what I meant is that after I insert (ie before the
> select count (*)…) saw a number dirty blocks in SGA

> the image of those blocks does not match that on disk
> also because some blocks there have never been on disk, right?

Yes, a regular insert writes into the buffer cache only.

> when I run “select count (*) from t” and I see that Oracle uses
> “Direct reads” …
>
> … this means that Oracle has done in the meantime
> a checkpoint and then brought up the disc, even blocks that
> were in SGA?

Yes.

And now I understand what bothers you :-) It is effectively so that the DBWR has to write some blocks to disk and just after that the server process has to read them back.

HTH
Chris

I have explained myself badly, I understood from what you had written that
a key prerequisite is that a checkpoint has been executed,
but what I meant is that after I insert (ie before the
select count (*)…) saw a number bi dirty blocks in SGA

D   COUNT(*)
- ----------
Y      21578
N       1582

and this means that (the image of those blocks does not match that on disk
also because some blocks there have never been on disk, right?).
I’d like to have only confirmed the following concept:

when I run “select count (*) from t” and I see that Oracle uses
“Direct reads” …

NAME                        VALUE
--------------------------- ----------
physical reads                      51
physical reads direct                0

select count(*) from t;

NAME                        VALUE
--------------------------- ----------
physical reads                   50553
physical reads direct            50118

… this means that Oracle has done in the meantime
a checkpoint and then brought up the disc, even blocks that
were in SGA? If not, I would not expect “direct reads”
but “conventional reads.

Thanks

I’m not sure to fully understand what do you mean… This is probably because you are confused by the dirty blocks in the SGA. The important thing you have to remember is that before doing direct reads a segment checkpoint has to be performed. Because of the segment checkpoint, all blocks are on disk and, therefore, every time that they are read through a direct read a deferred cleanout has to be performed.

HTH
Chris

dsettembrino>alter session set "_serial_direct_read" = true;

dsettembrino>create table t (x char(1000), y char(1000), z char(1000));

dsettembrino>insert into t select 'x', 'y', 'z' from dual connect by level <= 200000;

dsettembrino>commit;

I check if there are dirty blocks, as lawful expect:

dsettembrino>select v.dirty, count(*)
  2  from v$bh v
  3  where v.objd = (select object_id from user_objects where object_name = 'T')
  4  group by v.dirty;

D   COUNT(*)
- ----------
Y      21578
N       1582

This means that there are dirty blocks in buffer cache, insert’s blocks are
by definition. I run some statistical checks before executing my query:

dsettembrino>select n.name, m.value
  2  from  v$mystat m, v$statname n
  3  where m.STATISTIC# = n.STATISTIC#
  4  and   n.name in ('redo size', 'cleanouts only - consistent read gets' 
  5                    , 'direct path read', 'consistent gets'
  6                    , 'physical reads', 'physical reads'
  7                    ,'physical reads direct', 'undo change vector size');

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
consistent gets                                                       92975
physical reads                                                           51
physical reads direct                                                     0
redo size                                                         634580860
undo change vector size                                             5829132
cleanouts only - consistent read gets                                     0

I run my query:

dsettembrino>select count(*) from t;

  COUNT(*)
----------
    200000

So,I rerun the statistics:

dsettembrino>select n.name, m.value
  2  from  v$mystat m, v$statname n
  3  where m.STATISTIC# = n.STATISTIC#
  4  and   n.name in ('redo size', 'cleanouts only - consistent read gets' 
  5                   , 'direct path read', 'consistent gets'
  6                   , 'physical reads', 'physical reads'
  7                   ,'physical reads direct', 'undo change vector size');

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
consistent gets                                                      183930
physical reads                                                        50553
physical reads direct                                                 50118
redo size                                                         634586868
undo change vector size                                             5829132
cleanouts only - consistent read gets                                 40506

My interpretation is the following:

When I run my query (the select count (*) from t;) there are
blocks in buffer cache. I see from the statistic that Oracle
has solved my query using direct reads. To do that, Oracle
must make changes to blocks, to download it from SGA and then
bring these blocks into PGA, since the engine Oracle has
established that the circumstances require the use of direct reads.

1)Is it correct what I say?

2)If my hypothesis is correct, it means that during the query
(select count (*) from t) were performed delayed block cleanout
for a number of blocks (the ones on disk) + fast commit to a number
blocks (those who were SGA) before the engine execute direct reads?

Kind Regards,
Donatello

Yes, your interpretation is correct. Just note that the initialization _serial_direct_read exists from a long time (8i?) and, probably for that reason, it is not (directly) related to the serial direct reads that are used in recent releases.

Cheers,
Chris

I did two tests, the first on DB version 10g, the other in 11g to try to
understand if the principle is the same for the two versions DB. I know
that a condition for Oracle decides to perform direct reads is that the
number of blocks should be about 5 times the value of hidden parameter
_small_table_threshold.

test 10g

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE    10.2.0.4.0      Production
TNS for IBM/AIX RISC System/6000: Version 10.2.0.4.0 - Productio
NLSRTL Version 10.2.0.4.0 - Production

NAME                     VALUE      DEFLT      TYPE         DESCRIPTION                      
------------------------ ---------- ------------------------------------------------------------
_serial_direct_read      FALSE      TRUE       boolean      enable direct read in serial

SQL> select ksppstvl small_tab_threshold, ksppstvl * 5 as block_for_direct_reads
  2  from sys.x_$ksppi x, sys.x_$ksppsv y
  3  where (x.indx = y.indx)
  4  and ksppinm='_small_table_threshold';

SMALL_TAB_THRESHOLD   BLOCK_FOR_DIRECT_READS
--------------------  ----------------------
2130                                  10650

so with a number of blocks greater than 10650, the direct reads should be used

SQL> create table t (x char(1000), y char(1000), z char(1000));

SQL> insert into t select 'x', 'y', 'z' from dual connect by level <= 200000;

SQL> commit;

SQL> alter system flush buffer_cache;

NAME                                          VALUE
---------------------------------------- ----------
physical reads                                  178
physical reads direct                             0

SQL> select count(*) from t;

  COUNT(*)
----------
    200000

NAME                             VALUE
--------------------------- ----------
physical reads                   50626
physical reads direct                0

but this doesn’t happen. For completeness, I also see the number of blocks of the table

SQL> select num_rows, blocks from user_tables where table_name = 'T';

  NUM_ROWS     BLOCKS
---------- ----------
    200000      50437

I run the same test at 11g:

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production
PL/SQL Release 11.1.0.6.0 - Production
CORE    11.1.0.6.0      Production
TNS for IBM/AIX RISC System/6000: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production

NAME                     VALUE      DEFLT      TYPE         DESCRIPTION                      
------------------------ ---------- ------------------------------------------------------------
_serial_direct_read      FALSE      TRUE       boolean      enable direct read in serial      

SMALL_TAB_THRESHOLD   BLOCK_FOR_DIRECT_READS
--------------------  ----------------------
1424                                    7120

So, I have the same situation that I had in 10g, but with a different value _small_table_threshold

SQL> create table t (x char(1000), y char(1000), z char(1000));

SQL> insert into t select 'x', 'y', 'z' from dual connect by level <= 200000;

SQL> commit;

SQL> alter system flush buffer_cache;

NAME                          VALUE
------------------------ ----------
physical reads                  156
physical reads direct             0

SQL> select count(*) from t;

  COUNT(*)
----------
    200000

NAME                                VALUE
------------------------------ ----------
physical reads                      50754
physical reads direct               50183

I noticed that in 11g, on equal terms with the test conducted in the version
10g, then with _serial_direct_read -> FALSE and the number of blocks (50437) exceeds 5
times the value of _small_table_threshold (7120) the direct reads are applied
as not done in 10g

SQL> select num_rows, blocks from dba_tables where TABLE_NAME = 'T';

  NUM_ROWS     BLOCKS
---------- ----------
    200000      50437

But then this means that even if Oracle version 11g
_serial_direct_read = FALSE (but the number of blocks is greater than 5 times the value
_small_table_threshold most of the other conditions to which I referred you)
the direct reads are performed?

Is my interpretation correct?

Thanks a lot

Donatello