SQL.RU
 client/server technologies
Peoplemind  
 Главная | Документация | Статьи | Книги | Форум | Опросы | Рассылка | Работа | Поиск | FAQ |

Добро пожаловать в форум, Guest  >>  Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик  Ответить
 Вопрос по запросу   [new]
ils
Member

Откуда:
Сообщений: 92
Есть запрос
select a.id from numberbase a, pilotbase b where a.id=b.id
Есть план выполнения
Execution Plan
----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=2 Bytes=28) 1 0 NESTED LOOPS (Cost=1 Card=2 Bytes=28) 2 1 INDEX (FULL SCAN) OF 'PK_PILOTBASE' (UNIQUE) (Cost=1 Car d=2 Bytes=14) 3 1 INDEX (UNIQUE SCAN) OF 'PK_NUMBERBASE' (UNIQUE)


Вопрос такой
Следует ли из порядка размещения таблиц в плане то, что для каждого значения индекса PK_PILOTBASE каждый раз происходит сканирование индекса PK_NUMBERBASE?
И если да, то можно ли сделать наоборот, т.е. чтобы для каждого значения PK_NUMBERBASE происходил скан PK_PILOTBASE - поскольку таблица NUMBERBASE во много раз больше, чем PILOTBASE

Зараннее спасибо
22 июл 04, 16:20    [828191] Ответить | Цитировать    Сообщить модератору

 Re: Вопрос по запросу   [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1469
ils

Вопрос такой
Следует ли из порядка размещения таблиц в плане то, что для каждого значения индекса PK_PILOTBASE каждый раз происходит сканирование индекса PK_NUMBERBASE?
И если да, то можно ли сделать наоборот, т.е. чтобы для каждого значения PK_NUMBERBASE происходил скан PK_PILOTBASE - поскольку таблица NUMBERBASE во много раз больше, чем PILOTBASE

Зараннее спасибо


1) Оставьте оптимизатору право выбирать, что в каком порядке соединять.
Ваша задача (или администратора базы) обеспечить оптимизатору корректную статистику.

2) С чего Вы взяли, что Ваш вариант соединения будет лучше?
INDEX (UNIQUE SCAN) это не сканирование всех листьевых блоков индекса , а поиск нужного листа от головного блока индекса, т.е обычно около 3 операций чтения ( типичная глубина индекса 3).

Предположим, что PK_NUMBERBASE ( большой индекс) содержит ссылки на 100000 значений строк таблицы, и в один блок у нас влезает 100 пар значение-ссылка.
т.е мы будем иметь 1000 листьевых блоков по 100 ключей в каждом.

В PK_PILOTBASE ( маленький индекс), так же условно, будем считать содержится 10000 ключей, т.е 100 листьевых блоков по 100 ключей.

В вашем варианте Oracle должен выполнить чтение ( INDEX FULL SCAN) 1000 листьевых блоков индекса PK_NUMBERBASE (multiblock-reads учитывать не будем) и для каждого из 100000 значения ключа выполнить 3 чтения (INDEX UNIQUE SCAN) блоков индекса PK_PILOTBASE для проверки есть ли там соответствующий ключ.
Итого: 1000 + 100000*3 =301000 логических чтений.

В варианте, который выбрал оптимизатор, Oracle должен выполнить чтение 100 блоков индекса PK_PILOTBASE и для каждого из 10000 значения ключа выполнить 3 чтения блоков индекса PK_NUMBERBASE для проверки есть ли там соответствующий ключ.
Итого: 100 + 10000*3= 30100 логических чтений.

Разница на порядок в пользу оптимизатора.
22 июл 04, 17:34    [828641] Ответить | Цитировать    Сообщить модератору

 Re: Вопрос по запросу   [new]
ils
Member

Откуда:
Сообщений: 92
2 Я и ёжик
Сенкс за пищу для размышления
22 июл 04, 17:49    [828679] Ответить | Цитировать    Сообщить модератору

 Re: Вопрос по запросу   [new]
ils
Member

Откуда:
Сообщений: 92
2 Я и ёжик
Т.е. все зависит от своевременно собранной статистики?
И возможен вариант, когда после очередного сбора статистики оптимизатор поменяет порядок следования индексов в плане, я правильно понял?
22 июл 04, 17:53    [828696] Ответить | Цитировать    Сообщить модератору

 Re: Вопрос по запросу   [new]
igor2222
Member

Откуда: Харків
Сообщений: 933
По ходу вопрос
Если давать всем обычным юзерам дать селект на стат таблицы, то все юзера могут статистику и собирать, но одновременно самые умные могут и просматривать Сессион лист тем же PLSQL девелопером
А можно так чтоб и рыбку съесть...
Точнее вопрос - в книжках не нашел описания как собирать статистику каждому юзеру свою не имея привелегий на сис таблицы?
Заранее благодарен
22 июл 04, 17:59    [828717] Ответить | Цитировать    Сообщить модератору

 Re: Вопрос по запросу   [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1469
ils
2 Я и ёжик
Т.е. все зависит от своевременно собранной статистики?
И возможен вариант, когда после очередного сбора статистики оптимизатор поменяет порядок следования индексов в плане, я правильно понял?

От актуального состояния статистики, я бы сказал, она необязательно должна быть свежей, она должна соответствовать текущему состоянию объектов. А ещё от наличия необходимых индексов, настроек сервера, собранной системной статистики и.т.д.
Да, может поменять порядок следования индексов в плане, может отказаться от использования индексов, может применить другой метод соединения.
22 июл 04, 18:10    [828752] Ответить | Цитировать    Сообщить модератору

 Re: Вопрос по запросу   [new]
Ora-мучитель
Member

Откуда: Из зловещего мрака
Сообщений: 917
2 (Я и и ежик + автор)

В данный момент работаю над проектом с большим объемом данных (не очень много таблиц, но они большие (в плане объема) и партиционные (на каждой, в зависимости от настроек от 16 до 32 партиций + локальные индексы, тоже партиционные). Так вот, пишу ядро для работы с XML. Запросы в нем не очень сложные, но специфические и неоднозначные (многоуровневые преобразования в коллекции и т.п.). Были места, где Oracle (без статистики) вел себя "плохо". Стал собирать статистику. Собирал статистику сначала на 15%, потом затра%%%ся стал собирать на 5%, снова затра%%%ся (затра%%%ся - это значит притомился ждать, да и не помогло) и наконец пришел к решению полностью отказаться от сбора статистики и все запросы писать хинтами. Да, может какие-то запросы я не смогу оптимизировать как Oracle, но все узкие места, где он не справлялся удалось устранить, а вопрос о длительном процессе сбора статистики отпал сам собой.

Вывод: Удачно собрать статистику - еще не значит получить хорошую производительность.
22 июл 04, 18:15    [828776] Ответить | Цитировать    Сообщить модератору

 Re: Вопрос по запросу   [new]
denm
Member

Откуда: { empty }
Сообщений: 2792
2 Ора-мучитель.

Иногда сбор статистики можно оптимизировать.

У нас тоже есть относительно большие таблички с партициями по месяцам (>4Gb в месяц).
Но мы не анализируем каждый раз всю таблицу, а только текущую партицию (estimate 20%).
В старых партициях данные практически не меняются, поэтому статистика не пересобирается.
22 июл 04, 18:27    [828802] Ответить | Цитировать    Сообщить модератору

 Re: Вопрос по запросу   [new]
Markelenkov
Member

Откуда:
Сообщений: 2312
Ora-мучитель
Вывод: Удачно собрать статистику - еще не значит получить хорошую производительность.

Кто ж спорит. Это очень часто необходимое условие, но не достаточное.
22 июл 04, 18:43    [828848] Ответить | Цитировать    Сообщить модератору

 Re: Вопрос по запросу   [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1469
igor2222

Точнее вопрос - в книжках не нашел описания как собирать статистику каждому юзеру свою не имея привелегий на сис таблицы?

Не понятно в чем вопрос, оно по умолчанию так
Oracle10g Administration Guide

The schema object to be analyzed must be local, and it must be in your own schema or you must have the ANALYZE ANY system privilege.


Ora-мучитель

и наконец пришел к решению полностью отказаться от сбора статистики и все запросы писать хинтами.

Складывается ощущение что Вы что то не то , где то не там собирали...,
шутка, в общем как в том анекдоте Ваш тигр, Вы и спасайте...

А в 10g Вам еще придется отключить автоматический сбор статистики, впрочем он наверное всётаки сможет отличить что надо собирать, от того , что не надо.

Ora-мучитель

Вывод: Удачно собрать статистику - еще не значит получить хорошую производительность.

А вот вывод правильный. ( см. сооб. by Markelenkov)
22 июл 04, 18:51    [828867] Ответить | Цитировать    Сообщить модератору

 Re: Вопрос по запросу   [new]
igor2222
Member

Откуда: Харків
Сообщений: 933
2 Я и Ежик
А я по умолчанию скока оракл ставил (правда немного- всего раз 5) у таблицы v_$sysstat например паблик синонима по умолчанию как бы и нету...
22 июл 04, 19:02    [828904] Ответить | Цитировать    Сообщить модератору

 Re: Вопрос по запросу   [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1469
igor2222
2 Я и Ежик
А я по умолчанию скока оракл ставил (правда немного- всего раз 5) у таблицы v_$sysstat например паблик синонима по умолчанию как бы и нету...
А нужен?
22 июл 04, 19:06    [828912] Ответить | Цитировать    Сообщить модератору

 Re: Вопрос по запросу   [new]
igor2222
Member

Откуда: Харків
Сообщений: 933
как бы наверное ага
Есть другие способы?
22 июл 04, 19:10    [828923] Ответить | Цитировать    Сообщить модератору

 Re: Вопрос по запросу   [new]
Markelenkov
Member

Откуда:
Сообщений: 2312
igor2222
2 Я и Ежик
А я по умолчанию скока оракл ставил (правда немного- всего раз 5) у таблицы v_$sysstat например паблик синонима по умолчанию как бы и нету...
???
...Ora92\rdbms\admin\catalog.sql

...
create or replace view v_$sysstat as select * from v$sysstat;
create or replace public synonym v$sysstat for v_$sysstat;
grant select on v_$sysstat to select_catalog_role;
...

igor2222
Точнее вопрос - в книжках не нашел описания как собирать статистику каждому юзеру свою не имея привелегий на сис таблицы?

Что имеется ввиду? О DBMS_STATS написал Он с ёжиком, если имеется ввиду v$sysstat, то для каждой сессии есть ее собственный аналог - v$mystat:

SQL> connect scott/tiger
Connected.
SQL> select * from v$mystat;
select * from v$mystat
              *
ERROR at line 1:
ORA-00942: table or view does not exist


SQL> 

SQL> connect sys / as sysdba
Enter password: ***********
Connected.
SQL> grant select on v_$mystat to scott;

Grant succeeded.

SQL> grant select on v_$statname to scott;

Grant succeeded.

SQL> 

SQL> set pagesize 9999
SQL> select s.name, v.value from v$mystat v, v$statname s where v.statistic#=s.statistic# and v.value>0;

NAME                                                                  VALUE
---------------------------------------------------------------- ----------

logons cumulative 1 logons current 1 opened cursors cumulative 147 opened cursors current 1 user commits 1 user calls 97 recursive calls 2404 recursive cpu usage 1 session logical reads 579 CPU used when call started 7 CPU used by this session 7 session connect time 1090513206 process last non-idle time 1090513206 session uga memory 77008 session uga memory max 77008 messages sent 1 session pga memory 220508 session pga memory max 220508 enqueue requests 6 enqueue releases 6 db block gets 5 consistent gets 574 physical reads 34 db block changes 5 redo synch writes 1 free buffer requested 35 commit cleanouts 1 commit cleanouts successfully completed 1 switch current to new buffer 1 consistent gets - examination 309 shared hash latch upgrades - no wait 82 calls to kcmgas 2 calls to get snapshot scn: kcmgss 200 redo entries 3 redo size 560 no work - consistent read gets 178 deferred (CURRENT) block cleanout applications 1 table scans (short tables) 5 table scan rows gotten 3 table scan blocks gotten 3 table fetch by rowid 108 cluster key scans 78 cluster key scan block gets 79 rows fetched via callback 14 index fetch by key 100 index scans kdiixs1 74 cursor authentications 10 buffer is pinned count 38 buffer is not pinned count 271 workarea memory allocated 4 workarea executions - optimal 88 parse time cpu 2 parse time elapsed 27 parse count (total) 150 parse count (hard) 13 parse count (failures) 5 execute count 186 bytes sent via SQL*Net to client 32702 bytes received via SQL*Net from client 5502 SQL*Net roundtrips to/from client 85 sorts (memory) 107 sorts (rows) 748 62 rows selected.
22 июл 04, 20:30    [829056] Ответить | Цитировать    Сообщить модератору

 Re: Вопрос по запросу   [new]
B.
Guest
Следует ли из порядка размещения таблиц в плане то, что для каждого значения индекса PK_PILOTBASE каждый раз происходит сканирование индекса PK_NUMBERBASE?
--Da
И если да, то можно ли сделать наоборот, т.е. чтобы для каждого значения PK_NUMBERBASE происходил скан PK_PILOTBASE - поскольку таблица NUMBERBASE во много раз больше, чем PILOTBASE

Mozhno

ESLI vam nuzhno tol'ko ID, check timing i EXECUTION PLAN dla:

SELECT b. id FROM pilotbase b WHERE EXISTS (SELECT 'x'
FROM numberbase WHERE id= b.id);
22 июл 04, 20:53    [829076] Ответить | Цитировать    Сообщить модератору

 Re: Вопрос по запросу   [new]
igor2222
Member

Откуда: Харків
Сообщений: 933
2 Markelenkov
Спасибо! Я про мистат слышу первый раз. Наверное невнимательно читал литературу :-)
23 июл 04, 11:14    [829807] Ответить | Цитировать    Сообщить модератору

Все форумы / Oracle Ответить
Rambler's Top100 Powered by ActualForum 1.5.2 Copyright (c) Alex Sibilev 2000-2010