-
> Пытаться уже очень давно стоит. > http://delphiplus.org/articles/ib/firebird-2-full-capability/1/index.htmlи где ты там увидел синтаксис access или mssql? или не понятен смысл сказанного? у mssql нет first, для access используется инструкция transform. для обоих, не обязательно (в одном случае даже нельзя подобную) делать процедуру, проще ограничится запросом. для access вложенные подзапросы группируются не так. а то, что в FB это как то возможно, так вроде ничего в моем высказывании этому не противоречит.
-
>ANB (04.05.09 15:15) [58]
>Чисто теоретически, есно, возможны расхождения. Пока не нарывался.
в любой сколько-нибудь "тяжелой"(миллионники, запутанная логика в SQL) системе - это данность
>Иначе и смысла бы в он-лайн просмотре планов бы не было.
большого смысла и нет
explain plan - это средство первой линии диагностики - поверхностной и приблизительной
-
>PEAKTOP © (04.05.09 16:57) [59]
>В Firebird это может аукнуться. Например, генеришь IBExpert-ом тестовых >записей миллиона два-три, чтобы скучно ему не было. Выполняешь скрипт - >вроде и план правильный подхватился. А потом на реальных данных "вес" >индекса другой получается, т.к реальные данные далеко не равномерно >распределенные случайные величины
именно так
это справедливо и для Oracle, и для MS SQL
правильная структура данных, грамотное индексирование, сбор статистики - рецепт эффективной БД
хинты уместны, как и говорил ANB, для разовых выборок, отчетов
хинт в серверном коде - зло
-
> миллионники
это что такое ?
-
>Игорь Шевченко © (05.05.09 12:41) [63]
имел в виду таблицы с порядком записей 10^6 и выше
-
Кщд (05.05.09 13:33) [64]
Понятно. А вот такой вопрос - есть таблица, с порядком записей 10^8. Есть запрос к этой таблице и еще нескольким (у одной из нескольких порядок записей 10^6, у других несущественный (меньше 10^4))
Оптимизатор определяет, что толстую таблицу он будет обрабатывать FULL SCAN, запрос выполняется порядка получаса. Создал я нужный индекс по толстой таблице (функция от одного поля и и еще набор полей), индекс стал использоваться, COST запроса сократился, IO сократились, запрос стал выполняться пару минут. Это при незагруженном сервере. А при загруженном сервере запрос выполняется полтора часа, то есть, в три раза медленней, чем при FULL SCAN толстой таблицы. Время выполнения запроса с FULL SCAN от загруженности сервера практически не зависит, полчаса, плюс-минус 5 минут.
Oracle 10.2.0.3 под Linux, сервер достаточно толстый по памяти, процессору и проч. Статистика собирается регулярно, в том числе и системная.
В сессии выставлены параметры:
Optimizer_Index_Caching=90
Optimizer_Index_Cost_Adj=40
Вопрос в следующем: В какую строну рыть ? :)
-
> В Firebird это может аукнуться. Например, генеришь IBExpert-
> ом тестовых записей миллиона два-три, чтобы скучно ему
> не было. Выполняешь скрипт - вроде и план правильный подхватился.
> А потом на реальных данных "вес" индекса другой получается,
> т.к реальные данные далеко не равномерно распределенные
> случайные величины, как в генераторе IBExpert-a. И план
> твоего запроса (имеется в виду внутри ХП) после первого
> backup/restore "поедет" куда-то. Так что все-таки бывают
> случаи, когда планы иногда надо указывать явно. Лично у
> мну есть пример запроса с "дефолтным" планом, выполняющийся
> за 18 секунд, и "ручным", выполняющимся за миллисекунды.
>
1) Я план то смотрю на реальных данных. План, есно, может поехать в любой момент, но на то у нас и админы есть, чтобы возникшие тормоза выявлять и нам на правку отдавать. За год ни одного такого случая не было.
2) У оракла - хинты - это комментарии, которые он волен игнорить.
-
> в любой сколько-нибудь "тяжелой"(миллионники, запутанная
> логика в SQL) системе - это данность
Скорее всего ваши админы вообще мышей не ловят.
У нас как раз запутанная логика в SQL, нету внешних ключей и все прочее, от чего нормальный архитектор БД пришел бы в ужас.
Таблица с несколькими миллионами записей у нас считается маленькой.
Однако, повторюсь, на наших базах ни разу не нарывался, что план на тесте по Ф5 не совпадает с планом на реалке по трэйсу.
-
> хинт в серверном коде - зло
Но неизбежное.
-
> Вопрос в следующем: В какую строну рыть ? :)
План покажи
-
> План покажи
Смотри --------------------------------------------------------------------------------
|Id |Operation | Name | Rows | Bytes | Cost |
--------------------------------------------------------------------------------
| 0 |SELECT STATEMENT | | 1940 | 251K| 30528 |
| 1 | HASH JOIN | | 1940 | 251K| 30528 |
| 2 | TABLE ACCESS FULL |SMALLT1 | 9 | 117 | 2 |
| 3 | NESTED LOOPS ANTI | | 2511 | 294K| 30525 |
| 4 | HASH JOIN | | 2582 | 252K| 30524 |
| 5 | NESTED LOOPS | | 2582 | 226K| 30519 |
| 6 | HASH JOIN | | 17517 | 821K| 23499 |
| 7 | INDEX FULL SCAN |IX_SMA_T2 | 80 | 2080 | 2 |
| 8 | TABLE ACCESS FULL | BIG_T3 | 50M| 1069M| 22488 |
| 9 | TABLE ACCESS BY INDEX ROWID| MED_T4 | 1 | 42 | 1 |
| 10 | INDEX UNIQUE SCAN | PK_MED_T4 | 1 | | 1 |
| 11 | TABLE ACCESS FULL | SMA_T5 | 13014 | 127K| 5 |
| 12 | INDEX UNIQUE SCAN | IX_MED_T6 | 655 | 13100 | 1 |
--------------------------------------------------------------------------------
-
>Игорь Шевченко © (05.05.09 13:50) [65]
>COST запроса сократился, IO сократились, запрос стал выполняться пару >минут. Это при незагруженном сервере. А при загруженном сервере >запрос выполняется полтора часа, то есть, в три раза медленней
если навскидку, то я бы посмотрел, чего ждет сессия(v$session_wait), в которой работает данный запрос, при выполнении на продуктивном сервере
затем - смотрел бы на план из трейса
кстати, ф-ция в function based index - deterministic?
PS и, конечно, патчился бы до 10.2.0.4
понимаю-понимаю, что патчить продуктив не всегда можно)
-
>Игорь Шевченко © (05.05.09 14:47) [70]
навскидочку, если 6-ой hash join заменить на nested loops?
-
> кстати, ф-ция в function based index - deterministic?
Явно задана в при создании индекса CREATE INDEX ix_ ON bigtable
(field2, (CASE WHEN TRANSLATE(TRIM(field1),'x01234567890', 'x') IS NULL
THEN TO_NUMBER(field1)
ELSE 999999
END),field3) Кщд (05.05.09 14:54) [72]
> навскидочку, если 6-ой hash join заменить на nested loops?
Это план без индекса
> если навскидку, то я бы посмотрел, чего ждет сессия(v$session_wait),
> в которой работает данный запрос
db_file_sequential_read она ждет
> затем - смотрел бы на план из трейса
а это исключено политикой безопасности план смотрелся из SQL*Plus с включенной опцией autotrace собственно план с индексом: -------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1940 | 251K| 7384 |
| 1 | HASH JOIN | | 1940 | 251K| 7384 |
| 2 | TABLE ACCESS FULL | SMALLT1 | 9 | 117 | 2 |
| 3 | NESTED LOOPS ANTI | | 2511 | 294K| 7381 |
| 4 | HASH JOIN | | 2582 | 252K| 7380 |
| 5 | NESTED LOOPS | | 2582 | 226K| 7375 |
| 6 | NESTED LOOPS | | 17517 | 821K| 355 |
| 7 | INDEX FULL SCAN | IX_SMA_T2 | 80 | 2080 | 2 |
| 8 | TABLE ACCESS BY INDEX ROWID| BIG_T3 | 219 | 4818 | 4 |
| 9 | INDEX RANGE SCAN | IX_ | 15 | | 1 |
| 10 | TABLE ACCESS BY INDEX ROWID | MED_T4 | 1 | 42 | 1 |
| 11 | INDEX UNIQUE SCAN | PK_MED_T4 | 1 | | 1 |
| 12 | TABLE ACCESS FULL | SMA_T5 | 13014 | 127K| 5 |
| 13 | INDEX UNIQUE SCAN | IX_MED_T6 | 655 | 13100 | 1 |
------------------------------------------------------------------------------- Из которого видно, что 6-ой HAS JOIN заменился на NESTED LOOPS
-
| 8 | TABLE ACCESS BY INDEX ROWID| BIG_T3 | 219 | 4818 | 4 |
| 9 | INDEX RANGE SCAN | IX_ | 15 | | 1 |
Сколько всего записей в BIG_T3 и сколько примерно из них попадает в запрос ?
Сколько записей в таблице индекса IX_SMA_T2 и сколько из них попадает в запрос при первичном отборе ?
Хотя даже навскидку - выкини нафик индекс. С нагрузкой сервера твои тормоза никак не связаны - скорее всего после создания индекса, он и таблица закэшировались в память, что дало временный эффект ускорения.
После он потерялся.
-
ANB (05.05.09 15:43) [74]
> Сколько всего записей в BIG_T3 и сколько примерно из них
> попадает в запрос ?
всего десятки миллионов, попадают десятки тысяч
> Сколько записей в таблице индекса IX_SMA_T2 и сколько из
> них попадает в запрос при первичном отборе ?
Сколько-то тысяч, сколько-то сотен попадает.
> Хотя даже навскидку - выкини нафик индекс
Какой именно ?
> С нагрузкой сервера твои тормоза никак не связаны - скорее
> всего после создания индекса, он и таблица закэшировались
> в память, что дало временный эффект ускорения.
>
> После он потерялся.
То есть, через неделю после создания, работы на сервер, в выходные на пустом сервере он все еще оставался в кэше ?
Любопытная жизнь у индексов.
-
Может у тебя 2 террабайта памяти...
-
Anatoly Podgoretsky © (05.05.09 17:03) [76]
Тогда бы не наблюдалось явления, описанного в [65], из двух Тб оно бы преспокойно быстренько выбиралось в течение недели, а не только по выходным. На выходные память не наращивают, это точно.
-
Кщд (05.05.09 14:51) [71]
Кстати, обманул насчет версии Oracle
SQL> select banner from v$version;
BANNER
----------------------------------------------------------------
Oracle Database 10g Release 10.2.0.4.0 - 64bit Production
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
-
>Игорь Шевченко © (05.05.09 17:35) [78]
покажите, пожалуйста, сам запрос
|
Есть новые 
Нет новых [134473 +31][b:0.001][p:0.004]