Есть 2 Базы с одинаковыми метаданными, отличаются только данными.

Одна из Баз стала сильно тормозить, выяснилось что в сохраненке у 1 запроса изменился план, из за чего и появились тормоза.

По какой причине запрос мог изменить свой план? баг или фича оптимизатора запросов?

зы Бекап/ресторе базы вернул изначальный план.
firebird 2.0.3



Это сообщение отредактировал(а) Frees - 26.7.2010, 08:51

Нужно было сделать пересчет статистики индексов.

Deniz, поясни, зачем пересчет?

Со временем индексы "устаревают" и оптимизатор может перестать использовать индекс.
Если осталась старая БД с тормозами, проверь поможет ли пересчет индексов.

К сожалению я ее восстановил рестором.

 

как понять что в базе есть устаревшие индексы, из за чего они "стареют"?

Добавлено через 2 минуты и 8 секунд
еще такой момент если я явно дописывал "сломавшемуся" запросу plan, то он начинал правильно работать.

Посмотри вот эту статью, точнее в ней параграф "Автоматическое планирование"

Добавлено через 3 минуты и 6 секунд
PS: ручное "планирование" не есть гуд, данные (может и метаданные) меняются и оптимизатор может со временем предложить лучший план.

получается изменения плана запроса это все таки фича...

актуальность статьи 93 год,она все еще верна? все еще проблема решается только принудительным обновление статистики индекса?

как с этим в последних версиях firebird?

про сильно последние версии сказать не могу, но в 1.5 периодически статистику собираю.

да, к сожалению, программист сам должен периодически обновлять статистику индексов.
Я в своих приложениях даже такую команду вставляю.
дельфи + FibPlus

и когда эту акцию выполняешь, или это кнопка для пользователя (типо "нажми если тормозит")?

а время выполнения этого кода на много быстрее чем бекап - ресторе?

подумаваю о кнопке  "бекап - рестор"




Это сообщение отредактировал(а) Frees - 26.7.2010, 13:57

сбор статистики по всем индексам намного быстрее.
Цитата из IBAnalystкак-то так звучало.

Добавлено через 2 минуты и 51 секунду
В том же IBAnalyst можно примерно отследить разницу в индексах (реально и текущее) и решить как часто запускать.
Далее в автомате настроить такой запрос по ночам, хоть каждый день.

это нужно с умом делать.

кнопка для пользователя, но всё хочу реализовать в базе какую-то таблицу, где хранить кол-во добавленных, отредактированных, удалённых записей (можно на триггеры повесить), и через каждые, например, 100 записей в фоне выполнять пересчёт индексов.


конечно, если небольшая база, то ваще секунду, и пользователей не нужно отключать

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


Это сообщение отредактировал(а) Frees - 26.7.2010, 18:30

Это не правильно.
Возможно в след. версиях это поведение как-то изменят.
В любом случае, надо же делать периодический backup так вот в скрипте (там же где backup) можно собрать статистику по индексам (написав небольшую консольную программку).

Добавлено через 10 минут и 46 секунд
В дополнение несколько ссылок:
SET STATISTICS INDEX name;
скрипт для деактивации всех индексов
Для перестройки индекса:
ALTER INDEX

может и не правильно но как минимум будет предсказуемое поведение.


бекап надо, но то что надо делать еще и рестор не всем клиентам очевидно, поэтому и думал сделать бекап рестор в один клик ,тут много своих проблем.

пока есть 2 варианта:
1) делать SET STATISTICS при бекапе, тут опять плохо что многие не делают бекап а просто сохраняют копию файла бд (как не объясняй что это плохо)

2) кнопка для пользователя, тут другой минус пользователю сложно объяснить зачем он должен ее нажимать