ASCRUS gardenmanНа счет хранения планов я могу сказть, что как правило существует наиболе оптимальный план выполнения запросов, не зависящий даже от статистики.
если рассмативать что-то типа:
select * from A,B where A.a=? and A.id>=? and b.id=a.id order by A.a,A.id
fetch first 50 rows only
то естественно нужно построить два индекса A(a,id) и B(id) (если B- какой-то справочник для A), то неужто нужно чтобы оптимизатор срабатывал для таких запросов? Для таких вещей лучше раз и навсегда построить план и не мучать систему, особенно, когда таких запросов приходят пачки за секунду.
Такие примитивные запросы разве что клиентские приложения посылают. Они оседают в кэше оптимальных планов, раз строятся и работают. Если информация кардинально изменилась, планы перестраиваются, оседают в кэше и снова наступает затишье без перекомпиляции.

gardenmanА разве ни у кого не бывало так, что по мере наполнения базы данных вдруг
(даже при актуальной статистике) все начинает тормозить, появляются tablescan или порядок соединения в запросе меняется?
Честно говоря, оптимизатор - вещь хорошая, но я слегка нигиллист, и не могу полностью на него положиться. А если планы перестраиваются часто, - их трудно контролировать. Например если дабавил какой-то индекс на таличку, то по идее оптимизатор должен перестроить планы. А мне это не всегда нужно. Изменилась статистика - опять перестроить. Что в результате получится - я не знаю. Конечно можно просто положиться на оптимизатор, но у кого нет ошибок?
Ну во первых в результате добавления, изменения индексов/статистики не факт, что оптимальные планы будут перестроены - с чего бы это вдруг, если существующие в кэше отрабатывают в разумное время ? Во вторых для действительно сложных запросов с использованием параметров планы будут разные в зависимости от значения этих параметров - где то выгоднее индекс, где то хэш-соединение, а где то и Table Scan. Причем планы могут получатся кардинально разными, соединения в них между таблицами/процедурами не будут статичны в плане, а значит статически сгенерить и запомнить план, который бы подходил для любого случая в жизни да еще и для любой БД с своей информацией по моему не реальная задача. В третьих извиняюсь, если один и тот же запрос/представление/ХП используется в других запросах, которые могут быть как OLTP с различными уровнями изоляции (что актуально для блокировочников), так и OLAP с нарастающими функциями (те же Window функции), то и тут планы запросов могут кардинально отличаться, в ASA при построении планов запросов оптимизатор учитывает не только момент как быстрее выполнить, но и как не просадить выполнением сервер по отношению к другим сессиям в отношении ресурсов и блокировок и где например, несмотря на наличие более удачного индекса предпочтение может отдасться PK или Unique только из за того, что запрос выполняется на высшем уровне изоляции и уникальный индекс позволяет снизить нагрузку на блокировки в плане ресурсов и деятельности других сессий.

gardenmanДа и вы сами знаете что все планы выполнения просмотреть иной раз невозможно. Я предпочитаю знать что и как у меня обрабатывается в системе и не пускть это дело на самотёк. Это вообще что-то из темы - почему откомпилированное (в машинные коды естесс-но) приложение работает быстрее чем интерпретируемое или откомпилированное в байт-код.
В жизнь не поверю, что в DB2 нет профайлера ХП, консультанта индесов и дебаггера. Запускаем профайлер, он собирает статистику по выполнению всех ХП, триггеров и функций, далее визуально видим полный список того, что выполнилось, сколько в процентном и временном отношении это заняло, соотвествующе тормозные ХП при сортировке по времени выполнения будут стоять первыми в гриде. Далее опять же в профайлере уже по коду этих ХП по строкам смотрим время и процент выполнения и сразу же видим запросы которые тормозят. Далее по желанию - можем запустить консультант индексов, который во время реальной работы БД соберет всю информацию по выполненным с ХП запросам и на каждый запрос даст рекомендации по недостающим/лишним индексам, показав тут же план запроса "Как есть" и "Как может быть". Или же в дебаггере на этих тормозящих строчках в ХП шлепнем бряк-пойнты, выполним их, остановимся в нужных местах и вполне культурно тут же в дебагере повыполняем запросы из этих ХП, посмотрим их планы, статистику, значения глобальных и локальных переменных, посоздаем виртуальных индексов и посмотрим насколько они нравятся оптимизатору, ну и т.д. По моему так или иначе любая РСУБД имеет более чем достаточно средств для мониторинга и профайлинга выполнения запросов и ХП, разве что у кого то удобнее, у кого то не так удобно сделано.

gardenmanА вообще я не понимаю зачем вы приплели сюда репликацию? Она тут вообще нипричем.
А затем, что репликация тоже дает нагрузки на сервер, особенно если ей сказано не протоколировать действия триггеров и ХП, а дублировать на консолидированных/удаленных БД их вызовы. Надо думать здесь тоже начинает работать оптимизатор и для каждой БД план запросов для ХП и триггеров может отличаться и при выполнении репликации.

Гм, отсюда пару моралей (конечно лично моих и спорных с точки зрения специалистов других РСУБД):
1. Оптимизатора не нужно боятся, его нужно понимать и вести совместную работу, как партнером, который конечно же тоже может ошибаться и подвести.
2. Для серверов, ориентированных на распределенную работу с множеством удаленных точек, как самостоятельных серверов посредством репликаций, правила игры будут одни (это нулевое администрирование всех частей СУБД), для тех, у кого решения базируются на централизованной работе правила игры могут быть другими (думаю тут впервую очередь будет идти масштабируемость, гибкость настроек и скорость работы). Может быть здесь статическая компиляция планов/статистики и прокатит, в моих решениях на ASA кроме геммора бы она ничего не принесла, поэтому я очень рад, что ее в природе не существует :)

О МНОГОСЛОВНЫЙ ASCRUS! Ты опять создал видимость своей значимости потоком predefined-true's высказываний.
Ты ВЕЛИК!

Вы что, хотите свою траву впихнуть вместо:
Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД . (1,2,3,4,5,6,7,8,9 ..81,все)

Не выйдет!