увеличение статистики "physical reads" автоматически влечет за собой увеличение статистики

orabin
Дата: 29.07.2005 17:21:52
Вот такой вопрос
Barkovsky
Дата: 29.07.2005 17:23:45
это ужасно.
orabin
Дата: 29.07.2005 17:32:02
увеличение статистики "physical reads" автоматически влечет за собой увеличение статистики "logical reads"?
извините остаток съелся...


грубо говоря если мы считали 100 блоков с диска- это уже физически считанные блоки и они прибавляются(или нет) в счет логически считанных?
SkyNet77
Дата: 29.07.2005 17:36:39
горе то какое, а самая большая беда скрыта в доке, только видимо до Вас она еще не докатилась
.dba
Дата: 29.07.2005 17:49:32
orabin
грубо говоря если мы считали 100 блоков с диска- это уже физически считанные блоки и они прибавляются(или нет) в счет логически считанных?
Прибавление яблок к апельсинам не увеличивает кол-во апельсинов!
Barkovsky
Дата: 29.07.2005 17:57:45
orabin
грубо говоря если мы считали 100 блоков с диска- это уже физически считанные блоки и они прибавляются(или нет) в счет логически считанных?

если бы вопрос был обратный - увеличивает ли LIO -> PIO, он бы еще имел смысл. а так-то чего?
уверены, что спросили то, что хотели?))
Oracle newbie
Дата: 30.07.2005 15:03:00
orabin
увеличение статистики "physical reads" автоматически влечет за собой увеличение статистики "logical reads"?
извините остаток съелся...


грубо говоря если мы считали 100 блоков с диска- это уже физически считанные блоки и они прибавляются(или нет) в счет логически считанных?


Я думаю ты неправильно интерпретируешь слова Томаса Кайта. я прав насчет Кайта?

Что такое логическое чтение. Это чтение блока либо в consistent mode (consistent gets) либо в current mode (db block gets). Не зависимо от того , где будет находится этот блок -- в кеше или на диске . Но это будет вызвано из одной функции по взятию блока, называемая LIO! Примерно так:

1. Если блок в кеше, то перейти на пункт 3
2. Если блок не в кеше то
-- дать команду чтения этого блока с диска
-- закешировать его в нужный LRU order
3. привести в соответствующий вид (consistent mode)
4. и получить нужный блок из кеша.

То есть зависимость не та что ты привел, а та что привел Barkovsky

Чем больше LIO тем возможно будет больше и PIO а вот величина LIO велична "постоянная" для данного плана выполнения.
Хотя LIO не совсем постоянная величина и будет зависить от количества fetch выполняемых со стороны клиента. Каждый фетч будет инициировать новый LIO.

Regards.

P.S. Если хочешь по этой теме углубится или расшириться,
На www.hotsos.com есть статья C. Millsap
Why You Should Focus on LIOs Instead of PIOs
Там алгоритм, что я привел более подробно расписывается.
Я и ёжик
Дата: 30.07.2005 18:06:56
Я бы добавил , что physical reads возникают не только как следствие вызова lio, но и например, при чтении временных объектов из temporary tablespace, допустим, при больших сортировках.
Поэтому в листинге tkprof можно иногда наблюдать pio > lio.
Oracle newbie
Дата: 31.07.2005 00:52:01
Я и ёжик ,
Очень верное дополнение, спасибо.
Я полагаю что при сортировках увеличивается только статистика physical reads потому что блоки TEMP не кешируются в буфферный кеш, при чтении
то есть :
1)не проходят обработку помещения блок в LRU/MRU списки
2) и из них не конструируются CR блоки , как в случае чтения обычных блоков с данными.

Поэтому как бы с блоками TEMP сегментов нет никакого LIO .
LIO я называю не просто операцию по взятию блока из кеша, а целый ряд действий, обеспечивающих этому блоку место в LRU/MRU списков, конструирование блока до нужного нам SCN увеличение статистик и еще много нужного и ненужного что Оракл делает с блоком перед отдачей процессу строк из этого блока.


Regards.
Oracle newbie
Дата: 31.07.2005 17:54:31
global temporary tables.
Про них я забыл . У них блоки то проходят через попадание в буфферный кеш, хотя они лежат во временных сегментах! Значит
" как бы с блоками TEMP сегментов есть обычные операции LIO " если это работа с global temporary tables.
моя невнимательно, сорри