Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
План запроса в ХП: как посмотреть СОХРАНЁННЫЙ ПЛАН?
|
|||
|---|---|---|---|
|
#18+
Собственно, интересует именно ТЕКУЩИЙ, который есть в неудобоваримом виде в sysprocplan. Интересует, поскольку нет уверенности, что создав в EXPLAIN ON такую же ХП с другим именем или выполнив UPD STAT PROC, информикс не сформирует план отличный от бывшего... Или опасения напрасны? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2006, 14:26 |
|
||
|
План запроса в ХП: как посмотреть СОХРАНЁННЫЙ ПЛАН?
|
|||
|---|---|---|---|
|
#18+
Да, сорри, IDS 7.31 UD8, IDS 9.40 UC8... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2006, 14:28 |
|
||
|
План запроса в ХП: как посмотреть СОХРАНЁННЫЙ ПЛАН?
|
|||
|---|---|---|---|
|
#18+
Опасения не напрасны. Более того, я могу сказать, что и тот план, который сохранен в системном каталоге тоже может быть перестроен в любой момент - есть целая серия событий и зависимостей, от которых это зависит. И это правильно, так как за время, что прошло с момента компиляции ХП могло очень сильно поменяться как количество строк в задействованных таблицах, так и просто структура БД. Как увидеть сохраненный план - я не знаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2006, 15:11 |
|
||
|
План запроса в ХП: как посмотреть СОХРАНЁННЫЙ ПЛАН?
|
|||
|---|---|---|---|
|
#18+
vasilisОпасения не напрасны. Более того, я могу сказать, что и тот план, который сохранен в системном каталоге тоже может быть перестроен в любой момент - есть целая серия событий и зависимостей, от которых это зависит. И это правильно, так как за время, что прошло с момента компиляции ХП могло очень сильно поменяться как количество строк в задействованных таблицах, так и просто структура БД. Как увидеть сохраненный план - я не знаю. Возможно, Вам поможет syssqexplain в sysmaster'е? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2006, 15:39 |
|
||
|
План запроса в ХП: как посмотреть СОХРАНЁННЫЙ ПЛАН?
|
|||
|---|---|---|---|
|
#18+
Александр СпиринВозможно, Вам поможет syssqexplain в sysmaster'е? Это вряд-ли: имеющаяся информация в syssqexplain настолько скудна, что даже при запросе из одной таблицы скажет вам, к примеру, что индекс использовался, но какой КОНКРЕТНО... :( Что уж говорить о запросе к нескольким таблицам... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2006, 18:04 |
|
||
|
План запроса в ХП: как посмотреть СОХРАНЁННЫЙ ПЛАН?
|
|||
|---|---|---|---|
|
#18+
vasilisОпасения не напрасны. Более того, я могу сказать, что и тот план, который сохранен в системном каталоге тоже может быть перестроен в любой момент - есть целая серия событий и зависимостей, от которых это зависит. И это правильно, так как за время, что прошло с момента компиляции ХП могло очень сильно поменяться как количество строк в задействованных таблицах, так и просто структура БД. Как увидеть сохраненный план - я не знаю. Одновременно, есть шансы, что план запроса всё же не изменится при перекомпиляции , если не было существенных изменений. Всё же оптимизатор меняет план запроса не из-за самих изменений, а если находится более дешевый способ его исполнения... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2006, 17:44 |
|
||
|
План запроса в ХП: как посмотреть СОХРАНЁННЫЙ ПЛАН?
|
|||
|---|---|---|---|
|
#18+
Александр Спирин Одновременно, есть шансы, что план запроса всё же не изменится при перекомпиляции , если не было существенных изменений. " Есть шансы" в то время, когда приходится грызть оптимизацию - очень стрёмно :) Александр Спирин Всё же оптимизатор меняет план запроса не из-за самих изменений, а если находится более дешевый способ его исполнения... Вот-вот, в том-то и проблема... Есть случаи, когда оптимизатор меняет план запроса, но отнюдь не на более "дешёвый"... Привожу пример из жизни: п.1) таблица с одним "сильно разбалансированный" индексом №1 - то есть минимальное количество записей на один ключ и максимальное количество записей на один ключ ОЧЕНЬ сильно отличаются, а AVG этого количества сильно смещено в сторону MIN (надеюсь, выразился понятно, хотя может и своеобразно) п.2) имеем хранимые процедуры с запросами, использующими переменные. Оптимизатор использовал индекс №1 п.3) имеем тысячу вызовов разных ХП (совершенно условно назовём OLTP) с параметрами, кторые очень эффективно обрабатываются при использовании индекса №1 и десяток вызовов других ХП (совершенно условно назовём DSS), которые очень не эффективно обрабатываются при использовании индекса №1 п.4) с целью улучшения DSS добавляем второй "сильно разбалансированный" индекс №2, при использовании которого вызовы DSS должны обрабатываться гораздо эфективнее п.5) обновляем статистику по таблице и ХП п.6) информикс решает использовать в запросах ХП индекс №2. п.6) получаем расклад, при котором DSS запросы сами по себе начали работать быстрее, а вот OLTP - просто таки насилует систему... Вариант "А не пересмотреть ли реализацию или тем паче архитектуру?!" предлагаю не рассматривать в силу разных причин: трудозатратности, специфики сопровождения системы, точки зрения хорошего (с моей точки зрения :) администратора (всем вышеперечисленным стоит заниматься, если мои трудозатраты на достижение требуемого результата превысят 20% от трудозатрат на смену реализации/архитектуры) Так вот, приведённый пример кажется простым и понятным, когда он разложен по полочкам. А как вести себя разработчику/администратору в большой системе, чтобы ответить на вопрос: "А что изменится в оптимизации тысячи ХП, если я добавлю ещё один не бесполезный, IMHO, индекс?" Для того чтобы понять, что оптимизатор нашёл НОВЫЙ способ, вижу только три пути: 1) запросы до и после изменений отличаются по "скорости" выполнения - как видим по примеру, шишкоёмкий (с) способ 2) оптимизатор показал в sqexplain разную оптимизацию - для этого можно, например, сознательно включать и хранить историю expain при очередном обновлении статистики (хотя что делать с запросами, использующими временные таблицы, остаётся непонятным), а потом сравнивать (тоже отдельная песня :) 3) таки надеяться найти нужное в sysmaster :) Ещё варианты или уточнения к предложенным вариантам есть? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2006, 12:17 |
|
||
|
План запроса в ХП: как посмотреть СОХРАНЁННЫЙ ПЛАН?
|
|||
|---|---|---|---|
|
#18+
Есть .... OLCP (OLTP+DSS) - режи .... не совсем подходит для версий INFOMRIX 7.x, 9.x, 10.x ... и т.д. Новый редиз INFORMIX - 11.x по всей видимости сможет решать проблему оптимизации OLCP - запросов (с использованием технологий MQT и MDC - используемых d DB2 9.1 и т.д.) .... при условии, что указанные технологии будут перенесены в новую версию INFORMIX .... Далее, как вариант ... можно использовать внешние директивы .... свойство IDS 10.0 или разбалансировать выполнение OLCP-запросов на два сервера INFORMIX (один - OLTP, другой DSS) ... механизмов может быть несколько .... - с использование репликации, - монитора транзакций (CICS, Tuxdo .... - менеджера очередей (WebSphere MQ .... - сервера прилоджений и т.д. С уважением, Вадим. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2006, 12:38 |
|
||
|
План запроса в ХП: как посмотреть СОХРАНЁННЫЙ ПЛАН?
|
|||
|---|---|---|---|
|
#18+
АнатоЛойп.5) обновляем статистику по таблице и ХП п.6) информикс решает использовать в запросах ХП индекс №2.Т.е. теже oltp запросы без хр.п, по прежнему выбирают первый индекс? АнатоЛой Так вот, приведённый пример кажется простым и понятным, когда он разложен по полочкам. А как вести себя разработчику/администратору в большой системе, чтобы ответить на вопрос: "А что изменится в оптимизации тысячи ХП, если я добавлю ещё один не бесполезный, IMHO, индекс?" Это редкий случай в часто встречающихся ненормализованных системах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2006, 12:57 |
|
||
|
План запроса в ХП: как посмотреть СОХРАНЁННЫЙ ПЛАН?
|
|||
|---|---|---|---|
|
#18+
АнатоЛой п.4) с целью улучшения DSS добавляем второй "сильно разбалансированный" индекс №2, при использовании которого вызовы DSS должны обрабатываться гораздо эфективнее п.5) обновляем статистику по таблице и ХП п.6) информикс решает использовать в запросах ХП индекс №2. п.6) получаем расклад, при котором DSS запросы сами по себе начали работать быстрее, а вот OLTP - просто таки насилует систему... Попробуйте пересобрать статистику 2 раза подряд сначала с опцией drop destributions потом без. Мне несколько раз выручало в подобного рода случаях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2006, 13:09 |
|
||
|
План запроса в ХП: как посмотреть СОХРАНЁННЫЙ ПЛАН?
|
|||
|---|---|---|---|
|
#18+
сильно порезано GVF112GVF 1. OLCP (OLTP+DSS) - режим - новый релиз INFORMIX - 11.x 2. IDS 10.x - внешние директивы 3 два сервера INFORMIX С уважением, Вадим. Согласен - тоже варианты... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2006, 13:43 |
|
||
|
План запроса в ХП: как посмотреть СОХРАНЁННЫЙ ПЛАН?
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис АнатоЛойп.5) обновляем статистику по таблице и ХП п.6) информикс решает использовать в запросах ХП индекс №2.Т.е. теже oltp запросы без хр.п, по прежнему выбирают первый индекс? Да (т.е. запросы с константами вместо переменных выбирают индекс №1. Судя по всему, приятный выбор обеспечивает информация о распределении ключей... Журавлев Денис Это редкий случай в часто встречающихся ненормализованных системах. "Ненормализованных" - в каком контексте в данном случае? С учётом известных нам нормальных форм... Простой пример (если с планом бухсчетов знакомы): Бухгалтерские проводки с аналитикой плана счетов в одной таблице. Пример таблицы для простоты: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Имеем: 1) 2НФ - не соответствие 3НФ ("Работник ..." зависит не только от первичного ключа, но и частично от "Счёт..." - для большинства проводок (счетов) аналитики по работнику нет...) 2) "дисбаланс" индексов, использующих поля "Работник ..." Стоит подумать, нормализация до 3НФ (выделение таблицы Код: plaintext 1. 2. Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2006, 14:28 |
|
||
|
План запроса в ХП: как посмотреть СОХРАНЁННЫЙ ПЛАН?
|
|||
|---|---|---|---|
|
#18+
onstat-Попробуйте пересобрать статистику 2 раза подряд сначала с опцией drop destributions потом без. Мне несколько раз выручало в подобного рода случаях. Прямо сейчас не могу - но позже попробую и расскажу... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2006, 14:29 |
|
||
|
План запроса в ХП: как посмотреть СОХРАНЁННЫЙ ПЛАН?
|
|||
|---|---|---|---|
|
#18+
АнатоЛой Для того чтобы понять, что оптимизатор нашёл НОВЫЙ способ, вижу только три пути: 1) запросы до и после изменений отличаются по "скорости" выполнения - как видим по примеру, шишкоёмкий (с) способ 2) оптимизатор показал в sqexplain разную оптимизацию - для этого можно, например, сознательно включать и хранить историю expain при очередном обновлении статистики (хотя что делать с запросами, использующими временные таблицы, остаётся непонятным), а потом сравнивать (тоже отдельная песня :) 3) таки надеяться найти нужное в sysmaster :) Ещё варианты или уточнения к предложенным вариантам есть? :) Чтобы узнать, как повлияют внесенные изменения в структуру БД, на скорость выполнения запросов есть только один способ - все запросы проверить на время (скорость) выполнения :) (мрачная шутка). На самом деле, зачем искать изменения в планах, если они могут наступить не только от изменения структуры БД, а и от изменения размеров таблиц в любой момент времени? Может проще "зафикисировать" планы ? Т.е. в нужных запросах указать (принудить) использовать индекс 1, а в других запросах использовать индекс 2. Тогда вы уже "почти гарантированно" будете иметь один и тот же план. Еще предложение. Возможно, что лучше сказать оптимизатору не быть таким умным и не вычислять оптимальные планы по стоимости, а указать optcompind=0 (см. http://www.sql.ru/faq/faq_topic.aspx?fid=681). Некоторім сильно помогало. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2006, 21:16 |
|
||
|
План запроса в ХП: как посмотреть СОХРАНЁННЫЙ ПЛАН?
|
|||
|---|---|---|---|
|
#18+
Скорость это еще что... У нас бывали случаи, когда хранимая процедура просто переставала "правильно работать" с логической точки зрения. Ее перегенерация исправляла положение. Первый раз я очень долго лазил по тексту процедуры, по трассировке и ничего не мог понять.. Уж полез за старыми иходниками серверстудио с горя. Ну и был случай, когда результат запроса "портился" и только пересоздание индекса исправляла положение. Но несмотря на все люблю я его, Информикс в смысле :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2006, 23:19 |
|
||
|
План запроса в ХП: как посмотреть СОХРАНЁННЫЙ ПЛАН?
|
|||
|---|---|---|---|
|
#18+
vasilis Еще предложение. Возможно, что лучше сказать оптимизатору не быть таким умным и не вычислять оптимальные планы по стоимости, а указать optcompind=0 (см. мне всегда казалось что optcompind просто уменьшает стоимость прохода по индексу, или ты про set optimization low? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2006, 08:48 |
|
||
|
План запроса в ХП: как посмотреть СОХРАНЁННЫЙ ПЛАН?
|
|||
|---|---|---|---|
|
#18+
АнатоЛой Журавлев Денис АнатоЛойп.5) обновляем статистику по таблице и ХП п.6) информикс решает использовать в запросах ХП индекс №2.Т.е. теже oltp запросы без хр.п, по прежнему выбирают первый индекс? Да (т.е. запросы с константами вместо переменных выбирают индекс №1. Судя по всему, приятный выбор обеспечивает информация о распределении ключей... А второй индекс нельзя сделать таким что бы он не подходил для oltp запросов? Порядок полей поменять? ЗЫЖ В оракле у меня часто такое бывает (из-за кеширования планов запросов), хинтую запросы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2006, 08:51 |
|
||
|
План запроса в ХП: как посмотреть СОХРАНЁННЫЙ ПЛАН?
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис vasilis Еще предложение. Возможно, что лучше сказать оптимизатору не быть таким умным и не вычислять оптимальные планы по стоимости, а указать optcompind=0 (см. мне всегда казалось что optcompind просто уменьшает стоимость прохода по индексу, или ты про set optimization low? Наверное, так и есть, но главное то, что использование индексов становится почти обязательным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2006, 11:34 |
|
||
|
План запроса в ХП: как посмотреть СОХРАНЁННЫЙ ПЛАН?
|
|||
|---|---|---|---|
|
#18+
Александр ФедоренкоНу и был случай, когда результат запроса "портился" и только пересоздание индекса исправляла положение. Ну, у нас такое было несколько раз (и я уже об этом упоминал неоднократно). Т.е. индекс(-ы) по какой то причине (чаще всего, вполне определенной и связанной с неожиданными отключениями сервака) портятся, но узнать об этом можно ТОЛЬКО выполнив oncheck, т.е. битый индекс продолжает работать и возвращать фантастические результаты. Вот почему очень важно перед бэкапом всегда выполнять проверку целостности БД утилитой oncheck (и проверять эти результаты, естественно :)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2006, 11:46 |
|
||
|
План запроса в ХП: как посмотреть СОХРАНЁННЫЙ ПЛАН?
|
|||
|---|---|---|---|
|
#18+
Александр ФедоренкоСкорость это еще что... У нас бывали случаи, когда хранимая процедура просто переставала "правильно работать" с логической точки зрения. Ее перегенерация исправляла положение. Первый раз я очень долго лазил по тексту процедуры, по трассировке и ничего не мог понять.. Ты хочешь сказать, что портился псевдокод процедуры, хрянящийся в системном каталоге ? А вот такого, кажется, никогда не было, хотя процедур в различных системах было по несколько сотен и их размеры и сложность были очень большими. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2006, 12:05 |
|
||
|
План запроса в ХП: как посмотреть СОХРАНЁННЫЙ ПЛАН?
|
|||
|---|---|---|---|
|
#18+
vasilis Вот почему очень важно перед бэкапом всегда выполнять проверку целостности БД утилитой oncheck (и проверять эти результаты, естественно :)) А какие именно проверки рекомендуется запускать из "арсенала" oncheck ПЕРЕД бэкапом? И является ли правилом хорошего тона делать проверки БД с помощью oncheck (опять-таки - какие?) на регулярной основе (планировщик задач/cron)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2006, 17:17 |
|
||
|
План запроса в ХП: как посмотреть СОХРАНЁННЫЙ ПЛАН?
|
|||
|---|---|---|---|
|
#18+
svat2 vasilis Вот почему очень важно перед бэкапом всегда выполнять проверку целостности БД утилитой oncheck (и проверять эти результаты, естественно :)) А какие именно проверки рекомендуется запускать из "арсенала" oncheck ПЕРЕД бэкапом? И является ли правилом хорошего тона делать проверки БД с помощью oncheck (опять-таки - какие?) на регулярной основе (планировщик задач/cron)? По опыту своей рабты с Informix могу сказать, что битые индексы всегда ходят парами с ошибками несоответствия временных меток на страницах. В моей практике не приходилось сталкиваться с битым индексом и правильными метками. Когда серветр обнаруживает страницу с неправильными метками он делает об этом запись в лог файл и создает af файл с дампом страницы. ontape об этом тоже рапортует в лог , при работе с onbar у меня небыло битых страниц, Слава Богу. Прежде чем пускать oncheck внимательно на лог и af файлы на предмет ошибочных страниц. Запускать рекомендуется oncheck -cDI это оптом индексы и данные или почереди сначала oncheck -cI если есть ошибки то пускать oncheck -cD А потом по обстоятельствам. Если есть битые данные, то перестраивать индексы пока не будет исправлена ошибка никакого смысла нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2006, 20:37 |
|
||
|
План запроса в ХП: как посмотреть СОХРАНЁННЫЙ ПЛАН?
|
|||
|---|---|---|---|
|
#18+
vasilisТы хочешь сказать, что портился псевдокод процедуры, хрянящийся в системном каталоге ? А вот такого, кажется, никогда не было, хотя процедур в различных системах было по несколько сотен и их размеры и сложность были очень большими. Да , именно так. Процедур много, и самое главное много перегенераций процедур "на лету" - т.е при активной работе сотни юзеров. Наверное это причина. Хотя "портились процедуры", которые давно не трогали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 00:55 |
|
||
|
План запроса в ХП: как посмотреть СОХРАНЁННЫЙ ПЛАН?
|
|||
|---|---|---|---|
|
#18+
svat2 vasilis Вот почему очень важно перед бэкапом всегда выполнять проверку целостности БД утилитой oncheck (и проверять эти результаты, естественно :)) А какие именно проверки рекомендуется запускать из "арсенала" oncheck ПЕРЕД бэкапом? И является ли правилом хорошего тона делать проверки БД с помощью oncheck (опять-таки - какие?) на регулярной основе (планировщик задач/cron)? Исходить нужно из реалий текущего инстанса и требований бизнеса. Если сервер у вас работает все время без перезагрузок и различные проблемы энергетического питания вам не страшны, а также зеркалируется всё (все ДБ-пространства), да еще и архивы храняться по несколько месяцев, то проверку oncheck-ом можно делать только при необходимости или при подозрении на нарушения в целостности информации. Если же выше перечисленное отсутствует, то тогда очень даже желательно перед каждым бэкапом проверять целостность (выше уже подсказывали основные ключи утилиты, можно добавить еще проверку экстентов -ceq), что бы потом при восстановлении не обнаружить битый индекс, восстановленный из архива ontape. В этой проверке есть тоже свои минусы: для больших баз - время проверки, усиленная работа и износ дисковой подсистемы, хорошая нагрузка сервера во время работы системы (можно проверять в online). С другой стороны, если вам никто голову не оторвет за потерянную информацию или лишние пару часов, потраченные на восстановление (вероятность восстановления не нулевая, но и не большая :), то зачем вам этот геморрой ? Так что надо соизмерять затраты и полученный эффект. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 16:51 |
|
||
|
|

start [/forum/topic.php?fid=44&msg=34139675&tid=1608544]: |
0ms |
get settings: |
7ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
46ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
35ms |
get tp. blocked users: |
1ms |
| others: | 206ms |
| total: | 318ms |

| 0 / 0 |
