Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: про однопоточное случайное чтение  [new]
artemg
Member

Откуда: Санкт-Петербург
Сообщений: 593
вы таки будете смеяться
но в 11.2 db file sequential read читается посредством aio
25 апр 10, 20:55    [8686467]     Ответить | Цитировать Сообщить модератору
 Re: про однопоточное случайное чтение  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
artemg
а не подскажете тест-кейс?
Не уверен что 100% воспроизводим, но у меня на 10.2.0.4 вот так:
create table tst as select rownum n1, rownum n2 from dual 
  2    connect by level <= 100000 order by dbms_random.random;

Table created.

exec dbms_stats.gather_table_stats(ownname => null, tabname => 'tst');

PL/SQL procedure successfully completed.

create index idx_tst on tst(n1);

Index created.

alter system flush buffer_cache;

System altered.

alter session set events '10046 trace name context forever, level 8';

Session altered.

select /*+ index(tst) */ count(n2) from tst where n1 is not null;

 COUNT(N2)
----------
    100000

alter session set events '10046 trace name context off';

Session altered.

select name, value from v$sesstat a, v$statname b where a.statistic#=b.statistic# and name like '%prefetch%'
  2  and a.sid = (select sid from v$mystat where rownum = 1) order by name;

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
index crx upgrade (prefetch)                                              0
physical reads cache prefetch                                           366
physical reads prefetch warmup                                            0
prefetch clients - 16k                                                    0
prefetch clients - 2k                                                     0
prefetch clients - 32k                                                    0
prefetch clients - 4k                                                     0
prefetch clients - 8k                                                     0
prefetch clients - default                                                0
prefetch clients - keep                                                   0
prefetch clients - recycle                                                0
prefetch warmup blocks aged out before use                                0
prefetch warmup blocks flushed out before use                             0
prefetched blocks aged out before use                                     0
table lookup prefetch client count                                        0

15 rows selected.
10046:
select /*+ index(tst) */ count(n2) 
from
 tst where n1 is not null


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.63       0.95        428      99736          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4      0.63       0.95        428      99736          0           1

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 5  

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                       2        0.00          0.00
  db file sequential read                       235        0.07          0.19
  db file parallel read                          15        0.07          0.15
  SQL*Net message from client                     2        0.00          0.00
********************************************************************************
artemg
вы таки будете смеяться
но в 11.2 db file sequential read читается посредством aio
Сейчас возможности проверить нет, но звучит странно.
26 апр 10, 05:30    [8687182]     Ответить | Цитировать Сообщить модератору
 Re: про однопоточное случайное чтение  [new]
artemg
Member

Откуда: Санкт-Петербург
Сообщений: 593
> Не уверен что 100% воспроизводим, но у меня на 10.2.0.4 вот так:

спасибо большое!
попробую воспроизвести
может ещё и ссылкой поделитесь на статью или ноту после прочтения которой родился тест-кейс?
ну или подскажете автора, ключевые слова (ну кроме очевидных)
а то я что-то про этот wait event, и сам префетчинг ничего внятного найти не смог

> Сейчас возможности проверить нет, но звучит странно

похоже я обманул, сейчас у меня уже не получается воспроизвести
но вчера перед тем как запостить на форум я пару раз перепроверил
я даже отдельно табличное пространство с датафайлом на файловой системе сделал, чтобы не спутать с асмным read(21, "MSA\
Два раза перепроверил трейс - никаких других событий ожидания кроме db file sequential read ну и SQL*Net message from/to client в трейсе не было.
Но может быть я что-то напутал.
И похоже в 11.2 трейсы автоматом из diag трутся.
Так что прошу прощения.
26 апр 10, 21:53    [8692405]     Ответить | Цитировать Сообщить модератору
 Re: про однопоточное случайное чтение  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
artemg
может ещё и ссылкой поделитесь на статью или ноту после прочтения которой родился тест-кейс?
Я читал ссылку, которую привел Эталон Этанолович. Вот тут была дискуссия про методы доступа. Ну а тесткейс я получил просто - у меня есть табличка с индексом на 36 Gb и плохим clustering factor. Я запустил range scan и сразу увидел кучу db file parallel read (в том топике как раз приводил trace). Ну а сейчас просто воспроизвел для меньшего объема.
27 апр 10, 05:52    [8693012]     Ответить | Цитировать Сообщить модератору
 Re: про однопоточное случайное чтение  [new]
artemg
Member

Откуда: Санкт-Петербург
Сообщений: 593
Воспроизвёл на 10.2.0.4 (на 11.2 не получилось, возможно чёто не то накрутил)
Итак

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, Data Mining and Real Application Testing options

SQL> alter system flush buffer_cache;

System altered.

SQL> conn test
Enter password: *******
Connected.
SQL> select spid from v$session a, v$process b where b.addr = a.paddr and a.sid = (select sid from v$mystat where rownum=1);

SPID
------------
21874

SQL> set timing on
SQL> set autot traceonly stat
SQL> alter session set events '10046 trace name context forever, level 12';

Session altered.

Elapsed: 00:00:00.00
SQL> alter system flush buffer_cache;

System altered.

Elapsed: 00:00:00.44
SQL> select * from t where val between 400 and 450;

25125 rows selected.

Elapsed: 00:01:01.85

Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
      27137  consistent gets
      25630  physical reads
          0  redo size
    1111230  bytes sent via SQL*Net to client
      18906  bytes received via SQL*Net from client
       1676  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      25125  rows processed

SQL> alter session set events '10046 trace name context off';

Session altered.

Elapsed: 00:00:00.01
SQL> set autot off
SQL> set timing off
SQL> select name, value from v$sesstat a, v$statname b where a.statistic#=b.statistic# and name like '%prefetch read%' and a.sid = (select sid from v$mystat where rownum = 1) order by name;

no rows selected

SQL> select name, value from v$sesstat a, v$statname b where a.statistic#=b.statistic# and name like '%physical reads cache prefetch%' and a.sid = (select sid from v$mystat where rownum = 1) order by name;

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
physical reads cache prefetch                                         21774

SQL> select name, value from v$sesstat a, v$statname b where a.statistic#=b.statistic# and name like '%table fetch by rowid%' and a.sid = (select sid from v$mystat where rownum = 1) order by name;

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
table fetch by rowid                                                  25133



FETCH #1:c=0,e=36577,p=15,cr=16,cu=0,mis=0,r=15,dep=0,og=1,tim=1242632037971945
WAIT #1: nam='SQL*Net message from client' ela= 167 driver id=1650815232 #bytes=1 p3=0 obj#=174121 tim=1242632037972142
WAIT #1: nam='db file sequential read' ela= 7 file#=11 block#=493626 blocks=1 obj#=174122 tim=1242632037972199
WAIT #1: nam='db file parallel read' ela= 30911 files=2 blocks=14 requests=14 obj#=174121 tim=1242632038003185
WAIT #1: nam='db file sequential read' ela= 7 file#=9 block#=89037 blocks=1 obj#=174121 tim=1242632038003239
WAIT #1: nam='SQL*Net message to client' ela= 1 driver id=1650815232 #bytes=1 p3=0 obj#=174121 tim=1242632038003266
FETCH #1:c=0,e=31178,p=16,cr=17,cu=0,mis=0,r=15,dep=0,og=1,tim=1242632038003348
WAIT #1: nam='SQL*Net message from client' ela= 168 driver id=1650815232 #bytes=1 p3=0 obj#=174121 tim=1242632038003545
WAIT #1: nam='db file parallel read' ela= 22653 files=2 blocks=14 requests=14 obj#=174121 tim=1242632038026289
WAIT #1: nam='db file sequential read' ela= 7 file#=9 block#=428209 blocks=1 obj#=174121 tim=1242632038026341
WAIT #1: nam='SQL*Net message to client' ela= 0 driver id=1650815232 #bytes=1 p3=0 obj#=174121 tim=1242632038026364
FETCH #1:c=0,e=22865,p=15,cr=16,cu=0,mis=0,r=15,dep=0,og=1,tim=1242632038026436
WAIT #1: nam='SQL*Net message from client' ela= 162 driver id=1650815232 #bytes=1 p3=0 obj#=174121 tim=1242632038026628
WAIT #1: nam='db file parallel read' ela= 24392 files=2 blocks=14 requests=14 obj#=174121 tim=1242632038051116
WAIT #1: nam='db file sequential read' ela= 4002 file#=9 block#=323928 blocks=1 obj#=174121 tim=1242632038055165
WAIT #1: nam='SQL*Net message to client' ela= 0 driver id=1650815232 #bytes=1 p3=0 obj#=174121 tim=1242632038055190
FETCH #1:c=1000,e=28614,p=15,cr=16,cu=0,mis=0,r=15,dep=0,og=1,tim=1242632038055268
WAIT #1: nam='SQL*Net message from client' ela= 162 driver id=1650815232 #bytes=1 p3=0 obj#=174121 tim=1242632038055460
WAIT #1: nam='db file parallel read' ela= 20259 files=2 blocks=14 requests=14 obj#=174121 tim=1242632038075814
WAIT #1: nam='db file sequential read' ela= 2542 file#=9 block#=247194 blocks=1 obj#=174121 tim=1242632038078402
WAIT #1: nam='SQL*Net message to client' ela= 1 driver id=1650815232 #bytes=1 p3=0 obj#=174121 tim=1242632038078426
FETCH #1:c=0,e=23019,p=15,cr=16,cu=0,mis=0,r=15,dep=0,og=1,tim=1242632038078506
WAIT #1: nam='SQL*Net message from client' ela= 166 driver id=1650815232 #bytes=1 p3=0 obj#=174121 tim=1242632038078703
WAIT #1: nam='db file sequential read' ela= 7 file#=11 block#=493627 blocks=1 obj#=174122 tim=1242632038078765
WAIT #1: nam='db file parallel read' ela= 26310 files=2 blocks=14 requests=14 obj#=174121 tim=1242632038105156
WAIT #1: nam='db file sequential read' ela= 6 file#=11 block#=239653 blocks=1 obj#=174121 tim=1242632038105210


select *
from
 t where val between :"SYS_B_0" and :"SYS_B_1"


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch     1676      0.80      60.00      25630      27137          0       25125
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total     1678      0.80      60.00      25630      27137          0       25125

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 44

Rows     Row Source Operation
-------  ---------------------------------------------------
  25125  FILTER  (cr=27137 pr=25630 pw=0 time=61081044 us)
  25125   TABLE ACCESS BY INDEX ROWID T (cr=27137 pr=25630 pw=0 time=61055901 us)
  25125    INDEX RANGE SCAN TVALIDX (cr=2012 pr=505 pw=0 time=50610 us)(object id 174122)


Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                    1677        0.00          0.00
  SQL*Net message from client                  1677        9.24          9.53
  db file sequential read                      2181        0.05          4.13
  db file parallel read                        1675        1.40         55.47


Читали мы по ~14 блоков (см сырой трейс) 1675 раз (см tkprof), что на 2 тысячи отличается от physical reads cache prefetch 21774, но наверна всёж не каждый раз по 14.
Плюс если посмотреть на Row Source Operation, то там время выполнения шага TABLE ACCESS BY INDEX ROWID T похоже на время db file parallel read (большую часть времени выполнения ~55-60c).
Т.е. получается посредством db file parallel read мы префетчили блоки таблицы, а не индекса?

SQL> select OBJECT_NAME, OBJECT_TYPE  from dba_objects where OBJECT_ID=174121;

OBJECT_NAM OBJECT_TYPE
---------- -------------------
T          TABLE
28 апр 10, 16:14    [8703360]     Ответить | Цитировать Сообщить модератору
 Re: про однопоточное случайное чтение  [new]
wildwind
Member

Откуда: Москва
Сообщений: 1296
artemg
Т.е. получается посредством db file parallel read мы префетчили блоки таблицы, а не индекса?
Об этом однозначно говорит obj#=174121
28 апр 10, 17:10    [8704020]     Ответить | Цитировать Сообщить модератору
 Re: про однопоточное случайное чтение  [new]
artemg
Member

Откуда: Санкт-Петербург
Сообщений: 593
ну и да, оно через aio выполняется
а ещё на размер префетча влияет например sqlplus-овый arraysize

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, Data Mining and Real Application Testing options

SQL> conn test
Enter password: *******
Connected.
SQL> select spid from v$session a, v$process b where b.addr = a.paddr and a.sid = (select sid from v$mystat where rownum=1);

SPID
------------
25820

SQL> set autot traceonly stat
SQL> alter system flush buffer_cache;

System altered.

SQL> select * from t where val between 100 and 150;

[root@localhost ~]# strace -e io_submit -p 25820
Process 25820 attached - interrupt to quit
io_submit(47393327943680, 1, {{0x7fff912cd450, 0, 0, 0, 12}}) = 1
io_submit(47393327943680, 1, {{0x7fff912cdb50, 0, 0, 0, 13}}) = 1
io_submit(47393327943680, 14, {{0x18154858, 0, 0, 0, 12}, {0x18154a10, 0, 0, 0, 12}, {0x18154bc8, 0, 0, 0, 12}, {0x18154d80, 0, 0, 0, 12}, {0x18154f38, 0, 0, 0, 12}, {0x181550f0, 0, 0, 0, 12}, {0x181552a8, 0, 0, 0, 12}, {0x18155460, 0, 0, 0, 12}, {0x18155618, 0, 0, 0, 12}, {0x181557d0, 0, 0, 0, 13}, {0x18155988, 0, 0, 0, 13}, {0x18155b40, 0, 0, 0, 13}, {0x18155cf8, 0, 0, 0, 13}, {0x18155eb0, 0, 0, 0, 13}}) = 14
io_submit(47393327943680, 14, {{0x18154858, 0, 0, 0, 12}, {0x18154a10, 0, 0, 0, 12}, {0x18154bc8, 0, 0, 0, 12}, {0x18154d80, 0, 0, 0, 12}, {0x18154f38, 0, 0, 0, 12}, {0x181550f0, 0, 0, 0, 12}, {0x181552a8, 0, 0, 0, 13}, {0x18155460, 0, 0, 0, 13}, {0x18155618, 0, 0, 0, 13}, {0x181557d0, 0, 0, 0, 13}, {0x18155988, 0, 0, 0, 13}, {0x18155b40, 0, 0, 0, 13}, {0x18155cf8, 0, 0, 0, 13}, {0x18155eb0, 0, 0, 0, 13}}) = 14
io_submit(47393327943680, 14, {{0x18154858, 0, 0, 0, 12}, {0x18154a10, 0, 0, 0, 12}, {0x18154bc8, 0, 0, 0, 12}, {0x18154d80, 0, 0, 0, 12}, {0x18154f38, 0, 0, 0, 12}, {0x181550f0, 0, 0, 0, 12}, {0x181552a8, 0, 0, 0, 12}, {0x18155460, 0, 0, 0, 13}, {0x18155618, 0, 0, 0, 13}, {0x181557d0, 0, 0, 0, 13}, {0x18155988, 0, 0, 0, 13}, {0x18155b40, 0, 0, 0, 13}, {0x18155cf8, 0, 0, 0, 13}, {0x18155eb0, 0, 0, 0, 13}}) = 14
io_submit(47393327943680, 14, {{0x18154858, 0, 0, 0, 12}, {0x18154a10, 0, 0, 0, 12}, {0x18154bc8, 0, 0, 0, 12}, {0x18154d80, 0, 0, 0, 12}, {0x18154f38, 0, 0, 0, 12}, {0x181550f0, 0, 0, 0, 12}, {0x181552a8, 0, 0, 0, 12}, {0x18155460, 0, 0, 0, 12}, {0x18155618, 0, 0, 0, 12}, {0x181557d0, 0, 0, 0, 12}, {0x18155988, 0, 0, 0, 13}, {0x18155b40, 0, 0, 0, 13}, {0x18155cf8, 0, 0, 0, 13}, {0x18155eb0, 0, 0, 0, 13}}) = 14
io_submit(47393327943680, 14, {{0x18154858, 0, 0, 0, 12}, {0x18154a10, 0, 0, 0, 12}, {0x18154bc8, 0, 0, 0, 12}, {0x18154d80, 0, 0, 0, 12}, {0x18154f38, 0, 0, 0, 12}, {0x181550f0, 0, 0, 0, 12}, {0x181552a8, 0, 0, 0, 12}, {0x18155460, 0, 0, 0, 12}, {0x18155618, 0, 0, 0, 13}, {0x181557d0, 0, 0, 0, 13}, {0x18155988, 0, 0, 0, 13}, {0x18155b40, 0, 0, 0, 13}, {0x18155cf8, 0, 0, 0, 13}, {0x18155eb0, 0, 0, 0, 13}}) = 14
io_submit(47393327943680, 14, {{0x18154858, 0, 0, 0, 12}, {0x18154a10, 0, 0, 0, 12}, {0x18154bc8, 0, 0, 0, 13}, {0x18154d80, 0, 0, 0, 13}, {0x18154f38, 0, 0, 0, 13}, {0x181550f0, 0, 0, 0, 13}, {0x181552a8, 0, 0, 0, 13}, {0x18155460, 0, 0, 0, 13}, {0x18155618, 0, 0, 0, 13}, {0x181557d0, 0, 0, 0, 13}, {0x18155988, 0, 0, 0, 13}, {0x18155b40, 0, 0, 0, 13}, {0x18155cf8, 0, 0, 0, 13}, {0x18155eb0, 0, 0, 0, 13}}) = 14
io_submit(47393327943680, 14, {{0x18154858, 0, 0, 0, 12}, {0x18154a10, 0, 0, 0, 12}, {0x18154bc8, 0, 0, 0, 12}, {0x18154d80, 0, 0, 0, 12}, {0x18154f38, 0, 0, 0, 12}, {0x181550f0, 0, 0, 0, 12}, {0x181552a8, 0, 0, 0, 12}, {0x18155460, 0, 0, 0, 12}, {0x18155618, 0, 0, 0, 12}, {0x181557d0, 0, 0, 0, 12}, {0x18155988, 0, 0, 0, 13}, {0x18155b40, 0, 0, 0, 13}, {0x18155cf8, 0, 0, 0, 13}, {0x18155eb0, 0, 0, 0, 13}}) = 14



SQL> set arraysize 100
SQL> select * from t where val between 200 and 250;

[root@localhost~]# strace -e io_submit -p 25820
Process 25820 attached - interrupt to quit
io_submit(47393327943680, 39, {{0x2b1a9ebc7e38, 0, 0, 0, 12}, {0x2b1a9ebc7ff0, 0, 0, 0, 12}, {0x2b1a9ebc81a8, 0, 0, 0, 12}, {0x2b1a9ebc8360, 0, 0, 0, 12}, {0x2b1a9ebc8518, 0, 0, 0, 12}, {0x2b1a9ebc86d0, 0, 0, 0, 12}, {0x2b1a9ebc8888, 0, 0, 0, 12}, {0x2b1a9ebc8a40, 0, 0, 0, 12}, {0x2b1a9ebc8bf8, 0, 0, 0, 12}, {0x2b1a9ebc8db0, 0, 0, 0, 12}, {0x2b1a9ebc8f68, 0, 0, 0, 12}, {0x2b1a9ebc9120, 0, 0, 0, 12}, {0x2b1a9ebc92d8, 0, 0, 0, 12}, {0x2b1a9ebc9490, 0, 0, 0, 12}, {0x2b1a9ebc9648, 0, 0, 0, 12}, {0x2b1a9ebc9800, 0, 0, 0, 12}, {0x2b1a9ebc99b8, 0, 0, 0, 12}, {0x2b1a9ebc9b70, 0, 0, 0, 12}, {0x2b1a9ebc9d28, 0, 0, 0, 12}, {0x2b1a9ebc9ee0, 0, 0, 0, 12}, {0x2b1a9ebca098, 0, 0, 0, 12}, {0x2b1a9ebca250, 0, 0, 0, 12}, {0x2b1a9ebca408, 0, 0, 0, 12}, {0x2b1a9ebca5c0, 0, 0, 0, 12}, {0x2b1a9ebca778, 0, 0, 0, 13}, {0x2b1a9ebca930, 0, 0, 0, 13}, {0x2b1a9ebcaae8, 0, 0, 0, 13}, {0x2b1a9ebcaca0, 0, 0, 0, 13}, {0x2b1a9ebcae58, 0, 0, 0, 13}, {0x2b1a9ebcb010, 0, 0, 0, 13}, {0x2b1a9ebcb1c8, 0, 0, 0, 13}, {0x2b1a9ebcb380, 0, 0, 0, 13}, {0x2b1a9ebcb538, 0, 0, 0, 13}, {0x2b1a9ebcb6f0, 0, 0, 0, 13}, {0x2b1a9ebcb8a8, 0, 0, 0, 13}, {0x2b1a9ebcba60, 0, 0, 0, 13}, {0x2b1a9ebcbc18, 0, 0, 0, 13}, {0x2b1a9ebcbdd0, 0, 0, 0, 13}, {0x2b1a9ebcbf88, 0, 0, 0, 13}}) = 39
io_submit(47393327943680, 39, {{0x2b1a9ebc7e38, 0, 0, 0, 12}, {0x2b1a9ebc7ff0, 0, 0, 0, 12}, {0x2b1a9ebc81a8, 0, 0, 0, 12}, {0x2b1a9ebc8360, 0, 0, 0, 12}, {0x2b1a9ebc8518, 0, 0, 0, 12}, {0x2b1a9ebc86d0, 0, 0, 0, 12}, {0x2b1a9ebc8888, 0, 0, 0, 12}, {0x2b1a9ebc8a40, 0, 0, 0, 12}, {0x2b1a9ebc8bf8, 0, 0, 0, 12}, {0x2b1a9ebc8db0, 0, 0, 0, 12}, {0x2b1a9ebc8f68, 0, 0, 0, 12}, {0x2b1a9ebc9120, 0, 0, 0, 12}, {0x2b1a9ebc92d8, 0, 0, 0, 12}, {0x2b1a9ebc9490, 0, 0, 0, 12}, {0x2b1a9ebc9648, 0, 0, 0, 12}, {0x2b1a9ebc9800, 0, 0, 0, 12}, {0x2b1a9ebc99b8, 0, 0, 0, 12}, {0x2b1a9ebc9b70, 0, 0, 0, 13}, {0x2b1a9ebc9d28, 0, 0, 0, 13}, {0x2b1a9ebc9ee0, 0, 0, 0, 13}, {0x2b1a9ebca098, 0, 0, 0, 13}, {0x2b1a9ebca250, 0, 0, 0, 13}, {0x2b1a9ebca408, 0, 0, 0, 13}, {0x2b1a9ebca5c0, 0, 0, 0, 13}, {0x2b1a9ebca778, 0, 0, 0, 13}, {0x2b1a9ebca930, 0, 0, 0, 13}, {0x2b1a9ebcaae8, 0, 0, 0, 13}, {0x2b1a9ebcaca0, 0, 0, 0, 13}, {0x2b1a9ebcae58, 0, 0, 0, 13}, {0x2b1a9ebcb010, 0, 0, 0, 13}, {0x2b1a9ebcb1c8, 0, 0, 0, 13}, {0x2b1a9ebcb380, 0, 0, 0, 13}, {0x2b1a9ebcb538, 0, 0, 0, 13}, {0x2b1a9ebcb6f0, 0, 0, 0, 13}, {0x2b1a9ebcb8a8, 0, 0, 0, 13}, {0x2b1a9ebcba60, 0, 0, 0, 13}, {0x2b1a9ebcbc18, 0, 0, 0, 13}, {0x2b1a9ebcbdd0, 0, 0, 0, 13}, {0x2b1a9ebcbf88, 0, 0, 0, 13}}) = 39
io_submit(47393327943680, 19, {{0x18154858, 0, 0, 0, 12}, {0x18154a10, 0, 0, 0, 12}, {0x18154bc8, 0, 0, 0, 12}, {0x18154d80, 0, 0, 0, 12}, {0x18154f38, 0, 0, 0, 12}, {0x181550f0, 0, 0, 0, 12}, {0x181552a8, 0, 0, 0, 12}, {0x18155460, 0, 0, 0, 12}, {0x18155618, 0, 0, 0, 12}, {0x181557d0, 0, 0, 0, 13}, {0x18155988, 0, 0, 0, 13}, {0x18155b40, 0, 0, 0, 13}, {0x18155cf8, 0, 0, 0, 13}, {0x18155eb0, 0, 0, 0, 13}, {0x18156068, 0, 0, 0, 13}, {0x18156220, 0, 0, 0, 13}, {0x181563d8, 0, 0, 0, 13}, {0x18156590, 0, 0, 0, 13}, {0x18156748, 0, 0, 0, 13}}) = 19
io_submit(47393327943680, 39, {{0x2b1a9ebc7e38, 0, 0, 0, 12}, {0x2b1a9ebc7ff0, 0, 0, 0, 12}, {0x2b1a9ebc81a8, 0, 0, 0, 12}, {0x2b1a9ebc8360, 0, 0, 0, 12}, {0x2b1a9ebc8518, 0, 0, 0, 12}, {0x2b1a9ebc86d0, 0, 0, 0, 12}, {0x2b1a9ebc8888, 0, 0, 0, 12}, {0x2b1a9ebc8a40, 0, 0, 0, 12}, {0x2b1a9ebc8bf8, 0, 0, 0, 12}, {0x2b1a9ebc8db0, 0, 0, 0, 12}, {0x2b1a9ebc8f68, 0, 0, 0, 12}, {0x2b1a9ebc9120, 0, 0, 0, 12}, {0x2b1a9ebc92d8, 0, 0, 0, 12}, {0x2b1a9ebc9490, 0, 0, 0, 12}, {0x2b1a9ebc9648, 0, 0, 0, 12}, {0x2b1a9ebc9800, 0, 0, 0, 12}, {0x2b1a9ebc99b8, 0, 0, 0, 12}, {0x2b1a9ebc9b70, 0, 0, 0, 12}, {0x2b1a9ebc9d28, 0, 0, 0, 12}, {0x2b1a9ebc9ee0, 0, 0, 0, 12}, {0x2b1a9ebca098, 0, 0, 0, 12}, {0x2b1a9ebca250, 0, 0, 0, 13}, {0x2b1a9ebca408, 0, 0, 0, 13}, {0x2b1a9ebca5c0, 0, 0, 0, 13}, {0x2b1a9ebca778, 0, 0, 0, 13}, {0x2b1a9ebca930, 0, 0, 0, 13}, {0x2b1a9ebcaae8, 0, 0, 0, 13}, {0x2b1a9ebcaca0, 0, 0, 0, 13}, {0x2b1a9ebcae58, 0, 0, 0, 13}, {0x2b1a9ebcb010, 0, 0, 0, 13}, {0x2b1a9ebcb1c8, 0, 0, 0, 13}, {0x2b1a9ebcb380, 0, 0, 0, 13}, {0x2b1a9ebcb538, 0, 0, 0, 13}, {0x2b1a9ebcb6f0, 0, 0, 0, 13}, {0x2b1a9ebcb8a8, 0, 0, 0, 13}, {0x2b1a9ebcba60, 0, 0, 0, 13}, {0x2b1a9ebcbc18, 0, 0, 0, 13}, {0x2b1a9ebcbdd0, 0, 0, 0, 13}, {0x2b1a9ebcbf88, 0, 0, 0, 13}}) = 39


28 апр 10, 17:15    [8704069]     Ответить | Цитировать Сообщить модератору
 Re: про однопоточное случайное чтение  [new]
Филарет
Member

Откуда:
Сообщений: 539
Эксгумируем топик

Занимался копанием в ASM, ну и походу решил отключить чтение мимо кэша:
sys@db11> alter system flush buffer_cache;

Система изменена.

sys@db11> conn u1@db11
Введите пароль:
Соединено.
u1@db11> alter session set events '10046 trace name context forever, level 8';

Сеанс изменен.

u1@db11> alter session set events '10949 trace name context forever, level 1';

Сеанс изменен.

--контрольный выстрел
u1@db11> alter session set "_serial_direct_read"=false;

Сеанс изменен.

u1@db11> select count(*) crazy from sys.t;

     CRAZY
----------
   8768384

u1@db11> select count(*) crazy from sys.t1;

     CRAZY
----------
   8768384

u1@db11> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
PL/SQL Release 11.2.0.1.0 - Production
CORE    11.2.0.1.0      Production
TNS for Solaris: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production
t1 лежит на файловой системе. В трассе по ней видно:
*** 2010-10-18 16:54:19.026
WAIT #3: nam='direct path read' ela= 8157 file number=6 first dba=106880 block c
nt=64 obj#=86544 tim=2436292956259
WAIT #3: nam='direct path read' ela= 17815 file number=6 first dba=106944 block
cnt=64 obj#=86544 tim=2436292977630
WAIT #3: nam='direct path read' ela= 2472 file number=6 first dba=107008 block c
nt=64 obj#=86544 tim=2436292983528
WAIT #3: nam='direct path read' ela= 8693 file number=6 first dba=107072 block c
nt=64 obj#=86544 tim=2436292995598
WAIT #3: nam='direct path read' ela= 16949 file number=6 first dba=107136 block
cnt=64 obj#=86544 tim=2436293015881
WAIT #3: nam='direct path read' ela= 878 file number=6 first dba=107200 block cn
t=64 obj#=86544 tim=2436293020336
solaris 10 sparc.

Как отключить serial_direct_path_read? Или у меня что-то с глазами?
18 окт 10, 10:00    [9624146]     Ответить | Цитировать Сообщить модератору
 Re: про однопоточное случайное чтение  [new]
Окулист Георгинович
Guest
Филарет
Как отключить serial_direct_path_read? Или у меня что-то с глазами?

http://forum.sql.ru/forum/actualthread.aspx?tid=774143
http://shallahamer-orapub.blogspot.com/2010/01/mystery-surrounding-11g-and-direct.html
http://dioncho.wordpress.com/2009/07/21/disabling-direct-path-read-for-the-serial-full-table-scan-11g/
18 окт 10, 10:22    [9624246]     Ответить | Цитировать Сообщить модератору
 Re: про однопоточное случайное чтение  [new]
Филарет
Member

Откуда:
Сообщений: 539
я читал первую и третью ссылку. Предлагаешь еще попробовать _small_table_threshold?
18 окт 10, 10:28    [9624286]     Ответить | Цитировать Сообщить модератору
 Re: про однопоточное случайное чтение  [new]
Тюльпан Пионович
Guest
Филарет
я читал первую и третью ссылку. Предлагаешь еще попробовать _small_table_threshold?
У меня все отключается. Попробуй _small_table_threshold. На всякий случай:
http://www.rhinocerus.net/forum/databases-oracle-server/277839-_serial_direct_read-effect.html

Jonathan Lewis
One of the oddities about serial_direct_read is that
it seems to become an attribute of the cursor. This
means that you won't see a difference in your test
because the second run of the SQL uses the cursor
opened in the first part of the test, and therefore does
not do direct reads. You need to have two slightly
different statements if you want to see the effects
in the stats and latches.
18 окт 10, 10:54    [9624440]     Ответить | Цитировать Сообщить модератору
 Re: про однопоточное случайное чтение  [new]
Филарет
Member

Откуда:
Сообщений: 539
Версия про атрибут курсора интересная тем, что в сети встречалось упоминание что вообще-то serial_direct_path_read это фишка execute engine а CBO про нее как бы не знает. И опять же 10046 к примеру иногда сбрасывает план, а 10949 получается нет.

В общем, помогло только задирание вверх параметра _small_table_threshold. Что, имхо, не есть гуд. Кто виноват 11.2 или спарковая соляра, а скорее их комбинация не в курсе. Если не забуду проверю на 11.2.0.2

Собственно остались вопросы:

1.
http://structureddata.org/2008/08/14/automatic-db_file_multiblock_read_count/ Vyacheslav Rasskazov
Size of diect reads is driven by _db_file_direct_io_count parameter (1MB), but NOT by db_file_multiblock_read_count
У меня оно не так: параметр по умолчанию выставлен в 1М, а читает он по 512к(из трассы).

2. Нигде не нашел формулы для расчета dbfmrc в 11Г при его невыставлении в файле параметров. Как его оракл расчитывает?

3. А началось все собственно с au_size в ASM. Не могу понять на кой ляд там значения в 4М и выше. Или это работает только для всякой экзотики типа экзадата? Потому как неоднократно читал что оракл не умеет читать больше 1М.
19 окт 10, 03:45    [9630643]     Ответить | Цитировать Сообщить модератору
 Re: про однопоточное случайное чтение  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Филарет

Собственно остались вопросы:

1.
http://structureddata.org/2008/08/14/automatic-db_file_multiblock_read_count/ Vyacheslav Rasskazov
Size of diect reads is driven by _db_file_direct_io_count parameter (1MB), but NOT by db_file_multiblock_read_count
У меня оно не так: параметр по умолчанию выставлен в 1М, а читает он по 512к(из трассы).

Это мой комментарий и он неверен. Чтением рулит db_file_multiblock_read_count.
Филарет
2. Нигде не нашел формулы для расчета dbfmrc в 11Г при его невыставлении в файле параметров. Как его оракл расчитывает?

Troubleshooting
Oracle Performance
As of Oracle Database 10g Release 2, it is also possible to instruct the database engine
to automatically configure the value of the initialization parameter db_file_multiblock_
read_count. To use this feature, simply do not set it. As shown in Formula 5-3, the database
engine will then try to set it to a value that allows 1MB physical reads. At the same time, however, a
kind of sanity check is applied to reduce the value if the size of the buffer cache is quite small
compared to the number of sessions supported by the database.

db_file_multiblock_read_count=min(1048756/db_block_size,db_cache_size/(sessions*db_block_size))

Филарет
3. А началось все собственно с au_size в ASM. Не могу понять на кой ляд там значения в 4М и выше. Или это работает только для всякой экзотики типа экзадата? Потому как неоднократно читал что оракл не умеет читать больше 1М.
Мы используем большие au_size чтобы уменьшить область SGA под карту экстентов.
19 окт 10, 04:36    [9630659]     Ответить | Цитировать Сообщить модератору
 Re: про однопоточное случайное чтение  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18486
Вроде, что-то у него там с наездом не получилось :)
19 окт 10, 04:37    [9630660]     Ответить | Цитировать Сообщить модератору
 Re: про однопоточное случайное чтение  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18486
Упс... А вот и автор
19 окт 10, 04:38    [9630661]     Ответить | Цитировать Сообщить модератору
 Re: про однопоточное случайное чтение  [new]
Филарет
Member

Откуда:
Сообщений: 539
wurdu
Это мой комментарий и он неверен. Чтением рулит db_file_multiblock_read_count.

"Это другие не влезут, а мой влезет! Гляди, Пятачок!" (с) :)

В трассе видно что при чтении минуя кэш буферов он читает по 512к. dbfmrc не выставлен и оракл показывает расчетный 88. Переключая параметром чтения на чтения в кэш он начинает читать по 88 блоков - как надо.

wurdu

db_file_multiblock_read_count=min(1048756/db_block_size,db_cache_size/(sessions*db_block_size))

Спасибо, но сессии немного не те:
sys@db11> show parameter db_file_mul

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_file_multiblock_read_count        integer     88
sys@db11> show parameter session

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
java_max_sessionspace_size           integer     0
java_soft_sessionspace_limit         integer     0
license_max_sessions                 integer     0
license_sessions_warning             integer     0
session_cached_cursors               integer     50
session_max_open_files               integer     10
sessions                             integer     172
shared_server_sessions               integer
sys@db11> show parameter cache_s

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
client_result_cache_size             big integer 0
db_cache_size                        big integer 96M
db_flash_cache_size                  big integer 0
db_keep_cache_size                   big integer 0
db_recycle_cache_size                big integer 0
db_16k_cache_size                    big integer 0
db_2k_cache_size                     big integer 0
db_32k_cache_size                    big integer 0
db_4k_cache_size                     big integer 0
db_8k_cache_size                     big integer 0
sys@db11> select 96*1024*1024/(172*8192) from dual;

96*1024*1024/(172*8192)
-----------------------
             71,4418605

sys@db11> select 96*1024*1024/(150*8192) from dual;

96*1024*1024/(150*8192)
-----------------------
                  81,92
19 окт 10, 05:20    [9630671]     Ответить | Цитировать Сообщить модератору
 Re: про однопоточное случайное чтение  [new]
Филарет
Member

Откуда:
Сообщений: 539
Филарет
Спасибо, но сессии немного не те:

пардон, совсем не те (глаз цифры 82 и 88 замылил) Получается и формула для моей БД не работает. Чую надо 11.1 рядом тулить и на ней все проверять.
19 окт 10, 05:26    [9630672]     Ответить | Цитировать Сообщить модератору
 Re: про однопоточное случайное чтение  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Филарет
Филарет
Спасибо, но сессии немного не те:

пардон, совсем не те (глаз цифры 82 и 88 замылил) Получается и формула для моей БД не работает. Чую надо 11.1 рядом тулить и на ней все проверять.
Ну в книге стоит примерно равно :)
19 окт 10, 05:39    [9630678]     Ответить | Цитировать Сообщить модератору
 Re: про однопоточное случайное чтение  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
А при dbfmrc=128 он у тебя по мегабайту читает?
19 окт 10, 05:43    [9630679]     Ответить | Цитировать Сообщить модератору
 Re: про однопоточное случайное чтение  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18486
От дефолтового размера блока разве не зависит?
19 окт 10, 05:46    [9630684]     Ответить | Цитировать Сообщить модератору
 Re: про однопоточное случайное чтение  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Вячеслав Любомудров
От дефолтового размера блока разве не зависит?
Зависит конечно. Ну я предположил что у автора 8K.
19 окт 10, 05:50    [9630688]     Ответить | Цитировать Сообщить модератору
 Re: про однопоточное случайное чтение  [new]
Филарет
Member

Откуда:
Сообщений: 539
wurdu
Ну в книге стоит примерно равно :)

хорошо что я не купил эту книгу :) вчера наткнулся как автор рекламировал, типа в это книге есть формула.

автор
А при dbfmrc=128 он у тебя по мегабайту читает?

да, читает.
19 окт 10, 06:07    [9630705]     Ответить | Цитировать Сообщить модератору
 Re: про однопоточное случайное чтение  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Филарет
wurdu
Ну в книге стоит примерно равно :)

хорошо что я не купил эту книгу :) вчера наткнулся как автор рекламировал, типа в это книге есть формула.
Я бы сказал, что книга очень хорошая. А формула может меняться от патчсетов.
19 окт 10, 06:15    [9630708]     Ответить | Цитировать Сообщить модератору
 Re: про однопоточное случайное чтение  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18486
Это про Льюиса?
А чем плоха книга? Даже перевод ее не испортил
19 окт 10, 06:36    [9630719]     Ответить | Цитировать Сообщить модератору
 Re: про однопоточное случайное чтение  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Вячеслав Любомудров
Это про Льюиса?
А чем плоха книга? Даже перевод ее не испортил
Не, про Troubleshooting Oracle Performance. Christian Antognini.
19 окт 10, 06:58    [9630730]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Oracle Ответить