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

Откуда: Россия, Краснодар
Сообщений: 110
Уважаемые DBA!

Есть несколько вопросов к Вам ...

Преамбула: высокий уровень Cache buffer chains

Решение:
- увеличить количество hash buckets
-- _db_block_hash_buckets = 300007
-- _db_blcok_hash_latches = 2048

т.е считывая блоск из кэша буферов, серверный процесс устанавливает защелку на цепочку, в которой находиться этот блок. Поскольку защелок всего 2048, а цепочек 300007, то установка одной защелки приводит к блокировке сразу (в среднем) 146 цепочек .. я правильно понимаю механизм?
Если да, быть может правильнее увеличить количество защелок на цепочки?
1 май 06, 11:50    [2618398]     Ответить | Цитировать Сообщить модератору
 Re: Cache buffer chains  [new]
Ааз
Member

Откуда: Москва/Протвино
Сообщений: 4274
Мои два копейка:

Не лечите симптомы (latch free).
Лечите болезнь (LIO)

Всего
1 май 06, 14:26    [2618578]     Ответить | Цитировать Сообщить модератору
 Re: Cache buffer chains  [new]
-=SwiMMeR=-
Member

Откуда: Россия, Краснодар
Сообщений: 110
что подразумевается под (LIO)?
1 май 06, 14:46    [2618596]     Ответить | Цитировать Сообщить модератору
 Re: Cache buffer chains  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18339
-=SwiMMeR=-
что подразумевается под (LIO)?

Logical Input/Output
1 май 06, 14:47    [2618599]     Ответить | Цитировать Сообщить модератору
 Re: Cache buffer chains  [new]
-=SwiMMeR=-
Member

Откуда: Россия, Краснодар
Сообщений: 110
Позвольте узнать какие конкретно шаги принимать?

Дело в том, что приложение куплено и советы типа "Выкинь и купи то-то или то-то" не принимаются. Имеем то, что имеем. Правильно ли я поинмаю совет:
что надо уменьшить логический ввод/вывод, т.е.
- разнести объекты с hot blocks по разным пулам
- увеличить pctfree в объектах с hot blocks?

Существуют ли еще какие-то методы воздействия на LIO?

ЗЫ: Админ я начинающий, а БД работает 24х7. Поэтому тренироваться можно только ограниченное количество раз ...
2 май 06, 03:44    [2619408]     Ответить | Цитировать Сообщить модератору
 Re: Cache buffer chains  [new]
Q u a d r o
Member

Откуда: Canada
Сообщений: 1987
-=SwiMMeR=-
Позвольте узнать какие конкретно шаги принимать?


Посмотрите на запросы, создающе больше всего LIO (с учётом количества их выполнений). Убедитесь, что они используют настолько мало LIO, насколько это возможно.

Например, разработчики часто страдают "любовью" к индексам:

SQL> select *
  2   from t1, t2
  3   where t1.object_id=t2.object_id;

55070 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 2959412835

-----------------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      | 53619 |    13M|       |   281   (5)| 00:00:04 |
|*  1 |  HASH JOIN         |      | 53619 |    13M|  7344K|   281   (5)| 00:00:04 |
|   2 |   TABLE ACCESS FULL| T2   | 53619 |  6702K|       |    35  (12)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| T1   | 54699 |  6837K|       |    35  (12)| 00:00:01 |
-----------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("T1"."OBJECT_ID"="T2"."OBJECT_ID")

Note
-----
   - dynamic sampling used for this statement


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       4409  consistent gets
          0  physical reads
          0  redo size
    4737222  bytes sent via SQL*Net to client
      40753  bytes received via SQL*Net from client
       3673  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      55070  rows processed

два фулл скана это плохо (у нас же есть индекс по object_id), поэтому мы щас нарисуем любимый хинт "rule":

SQL> select /*+ rule */ *
  2   from t1, t2
  3   where t1.object_id=t2.object_id;

55070 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 2640328345

------------------------------------------------------
| Id  | Operation                   | Name           |
------------------------------------------------------
|   0 | SELECT STATEMENT            |                |
|   1 |  TABLE ACCESS BY INDEX ROWID| T2             |
|   2 |   NESTED LOOPS              |                |
|   3 |    TABLE ACCESS FULL        | T1             |
|*  4 |    INDEX RANGE SCAN         | I_T2_OBJECT_ID |
------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   4 - access("T1"."OBJECT_ID"="T2"."OBJECT_ID")

Note
-----
   - rule based optimizer used (consider using cbo)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
      70522  consistent gets
          0  physical reads
          0  redo size
    4737222  bytes sent via SQL*Net to client
      40753  bytes received via SQL*Net from client
       3673  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      55070  rows processed

отлично - включились индексы, разработчик с чистой совестью чувствует что выполнил свою задачу по оптимизации, ведь индексы это хорошо и быстро.

Вот только если посмотреть на LIO... 4409 в первом случае и 70522 в втором. Результат тот же, а LIO на порядок выше (из-за доступа по индексу). Бывает и обратная картина.

Ищите раличные возможностьи по снижению LIO у самых "прожорливых запросов".
2 май 06, 04:45    [2619421]     Ответить | Цитировать Сообщить модератору
 Re: Cache buffer chains  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8553
-=SwiMMeR=-
Позвольте узнать какие конкретно шаги принимать?

Дело в том, что приложение куплено и советы типа "Выкинь и купи то-то или то-то" не принимаются. Имеем то, что имеем. Правильно ли я поинмаю совет:
что надо уменьшить логический ввод/вывод, т.е.
- разнести объекты с hot blocks по разным пулам
- увеличить pctfree в объектах с hot blocks?

да нет, просто переписать приложение... или просто продумать индексы.
стабилизировать планы.
по поводу hot blocks - увеличить inittrans в параметрах хранения для
таблиц и индексов (для таблиц и PK индесков - по ср. количеству
активных сессий, для прочих индексов - можно чуть меньше)...

можно попробовать также использовать реверсивные индексы
на первичные ключи... но лучше не стоит - до появления RAC.

-=SwiMMeR=-

Существуют ли еще какие-то методы воздействия на LIO?

увеличение селективности индексов и пересмотр/стабилизация
планов запросов ;)

P.S.

и что за версия Oracle ? упомянутые параметры в статусе obsolete как бы еще не с времен Oracle7
2 май 06, 04:47    [2619422]     Ответить | Цитировать Сообщить модератору
 Re: Cache buffer chains  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8553
Q u a d r o


разработчики с любовью к индексам...

уточнять нужно, батенька, применимость последних, а не про rule
вспоминать..

одно дело - FIRST_ROWS (отобразить пользователю чего-то там), другое -
пакетом какие расчеты выполнить (ALL_ROWS).

и при том, что любимый наглядный метод HASH_JOIN - на практике -
почти неприменим, если, конечно, не стоит цель сделать массовую
пакетную миграцию данных
2 май 06, 04:52    [2619423]     Ответить | Цитировать Сообщить модератору
 Re: Cache buffer chains  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8553
а также всяко полезно упоминать мощность выборки...
т.е. количество строк.

hash_join хорош, когда этот хеш массив в память можно помесить (и если она еще и автоматически тюнится), а если начинается выгрузка в TEMP - то вся эта видимая
оптимизация довольно липовой оказывается.
2 май 06, 04:56    [2619425]     Ответить | Цитировать Сообщить модератору
 Re: Cache buffer chains  [new]
Q u a d r o
Member

Откуда: Canada
Сообщений: 1987
Я прекрасно знаю когда и что хорошо и полное описание поведения оптимизатора вы можете найти в Performance Tuning Guide и оно слишком большое, чтобы преводит его на форуме.

Я лишь привёл один из возможных примеров.

Я смотрю вы в соседней ветке уже посоветовали выключить HASH JOIN и сделали это вообще без всяких объяснений и примеров.
2 май 06, 05:04    [2619428]     Ответить | Цитировать Сообщить модератору
 Re: Cache buffer chains  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8553
Q u a d r o

Я смотрю вы в соседней ветке уже посоветовали выключить HASH JOIN и сделали это вообще без всяких объяснений и примеров.


у него база за уши притянута с 8.1.7

какой там HASH_JOIN ? ;))
2 май 06, 05:06    [2619429]     Ответить | Цитировать Сообщить модератору
 Re: Cache buffer chains  [new]
-=SwiMMeR=-
Member

Откуда: Россия, Краснодар
Сообщений: 110
to Q u a d r o
Попробую отловить "прожорливые запросы" ...

to grexhide
Переписать приложение нет возможности. Оно куплено. С остальным обязательно потренируюсь ...
Кста, Oracle 9.2.0.6 ...
2 май 06, 05:09    [2619430]     Ответить | Цитировать Сообщить модератору
 Re: Cache buffer chains  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8553
-=SwiMMeR=-

to grexhide
Переписать приложение нет возможности. Оно куплено. С остальным обязательно потренируюсь ...
Кста, Oracle 9.2.0.6 ...


возьми сразу quest spotlight. ловить будет не только полезно, но еще и приятно.

а переписать - всегда есть возможность.

обзоры, пакеты, стабилизация планов запроса.

правда после патчей это приходится делать заново, но селяви.

в принципе - каждый переписанный запрос или перестроенный набор индексов
- это способ ткнуть разработчиков в их же собственное... кхм..

потому что на практике - в 95% случаев эти недоразработчики аж никак не
тестируют свои поделия ни под нагрузкой данных, ни под нагрузкой конкурентными
сессиями - тем более..
2 май 06, 05:14    [2619432]     Ответить | Цитировать Сообщить модератору
 Re: Cache buffer chains  [new]
Q u a d r o
Member

Откуда: Canada
Сообщений: 1987
grexhide
у него база за уши притянута с 8.1.7

какой там HASH_JOIN ? ;))


Может Вы и не в курсе - но есть еще пара десятков фич оптимизатора в 9i, и это регулируется параметром OPTIMIZER_FEATURES_ENABLE. Чем Вам из всей плеяды именно HASH JOIN не угодил?

Если они не собирали статитику - никакого HASH JOIN у них и сейчас не будет. Если собирали - HASH JOJN в большинстве случаев займёт место MERGE JOIN, что будет только к лучшему.

Моя позиция - не стоит советовать придпринимать какие-либо конкретные действия до выяснения причины.
2 май 06, 05:35    [2619436]     Ответить | Цитировать Сообщить модератору
 Re: Cache buffer chains  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8553
Q u a d r o
HASH JOJN в большинстве случаев займёт место MERGE JOIN

осталось только понять, кто кого заменит, и в каком случае это будет лучшим.

В данном случае я лишь привел наиболее типовую проблему перехода с 8i на 9i, в т.ч. с с RBO на CBO.

А так, безусловно - Вы правы. Нужно выяснять причины.

Только не понятно, как можно выловить в формате форума реальные проблемы достаточно большой базы.
2 май 06, 05:55    [2619440]     Ответить | Цитировать Сообщить модератору
 Re: Cache buffer chains  [new]
Q u a d r o
Member

Откуда: Canada
Сообщений: 1987
grexhide
осталось только понять, кто кого заменит, и в каком случае это будет лучшим.

Если они уже были на CBO - то HASH JOIN у них уже был и на 8i.

Если они были на RBO и на нём же и остались - то HASH JOIN'а у них не было и на 9i его так же не будет.

Только в случае, если вместе с переходом на 9i они заодно решили перйти на CBO они могли поиметь проблемы с HASH JOIN.

В первых двух случаях отключение HASH JOIN будет просто способом замедлить производительность нуждающихся в нём запросов.

В третьем случае решением будет опять же не отключение HASH JOIN, а возврат на RBO проблемного приложения (удаление статитики) с последующим разбирательством "что пошло не так".

grexhide
...перехода с 8i на 9i, в т.ч. с с RBO на CBO.

Скорее это типовая проблема перехода на 10G (т.к. CBO там является оптимизатором по умолчанию, но и там вы можете прикуртить optimizer_mode=rule для сессий проблемных приложений на время разброк).
2 май 06, 07:11    [2619464]     Ответить | Цитировать Сообщить модератору
 Re: Cache buffer chains  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18339
Q u a d r o
Если они были на RBO и на нём же и остались - то HASH JOIN'а у них не было и на 9i его так же не будет.

Q u a d r o, Вы немного увлеклись.
При всем том, что в споре с grexhide Ваша позиция представляется более близкой к истине, процитированное утверждение... ммм.... не вполне корректно.
Продемонстрировать займет пол-странички и 15 секунд, но, полагаю, Вы и сами это знаете :)
2 май 06, 10:29    [2619805]     Ответить | Цитировать Сообщить модератору
 Re: Cache buffer chains  [new]
Q u a d r o
Member

Откуда: Canada
Сообщений: 1987
Если вы готовы продемострировать использование RBO hash join - буду рад посмотреть :-)
2 май 06, 10:42    [2619851]     Ответить | Цитировать Сообщить модератору
 Re: Cache buffer chains  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18339
Q u a d r o
Если вы готовы продемострировать использование RBO hash join - буду рад посмотреть :-)

Не совсем.
Просто попробуйте получить RBO при доступе к секционированному объекту или к IOT ;)
Именно поэтому утверждение "HASH JOIN'а у них не было и на 9i его так же не будет" слишком сильное.
Мог быть. Может случиться и при переходе. И никакой rule не спасет.
2 май 06, 10:46    [2619870]     Ответить | Цитировать Сообщить модератору
 Re: Cache buffer chains  [new]
Q u a d r o
Member

Откуда: Canada
Сообщений: 1987
не надо поттасовывать факты :-)

Это уже будет CBO, а я говорил про RBO.
2 май 06, 10:50    [2619884]     Ответить | Цитировать Сообщить модератору
 Re: Cache buffer chains  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18339
Q u a d r o
не надо поттасовывать факты :-)
Это уже будет CBO, а я говорил про RBO.

А я не подтасовываю. Ваше утверждение адресует "у них". Т.е. речь идет как минимум о системе, а не о конкретной oracle7-style таблице.
Поэтому справедливо лишь в отношении систем, не применяющих oracle8 new features.
А таких осталось ооочень мало :)
Причем и сами авторы не всегда осознают, что, указав /*+ rule */ или выставив соответствующий параметр, они просто насмешили оба оптимизатора ;)
Далее вспоминаем дядю Тома "CBO without stats ..." и полностью перестаем удивляться поехавшим при переходе 8->9 планам.
2 май 06, 10:58    [2619915]     Ответить | Цитировать Сообщить модератору
 Re: Cache buffer chains  [new]
Q u a d r o
Member

Откуда: Canada
Сообщений: 1987
Они бы и на 8i без статистик получили проблемы, поэтому если бы у них были IOT, партиции, B*Tree/HASH-кластера - они уже были бы на CBO, пколько фраза "CBO without stats...." и к 8i отношение имеет.
2 май 06, 11:02    [2619933]     Ответить | Цитировать Сообщить модератору
 Re: Cache buffer chains  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18339
Q u a d r o
Они бы и на 8i без статистик получили проблемы, поэтому если бы у них были IOT, партиции, B*Tree/HASH-кластера - они уже были бы на CBO, пколько фраза "CBO without stats...." и к 8i отношение имеет.

Не совсем так. У меня достаточно богатый опыт в этой области, показывающий, что и без статистики с CBO работать вполне можно.
Я больше скажу - полный переход на CBO моя компания приурочила к переходу на 10g, и то со значительными оговорками ;)
2 май 06, 11:10    [2619971]     Ответить | Цитировать Сообщить модератору
 Re: Cache buffer chains  [new]
Q u a d r o
Member

Откуда: Canada
Сообщений: 1987
т.е. то, что на 8i без статистик работало нормально - на 9i значит уже нормально без статистик не работает? :-)
2 май 06, 11:15    [2619991]     Ответить | Цитировать Сообщить модератору
 Re: Cache buffer chains  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18339
Q u a d r o
фраза "CBO without stats...." и к 8i отношение имеет.

Уточнюсь: CBO CBO рознь. Особенно при смене релиза.
2 май 06, 11:16    [2619995]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Oracle Ответить