В Oracle 7.0 появился стоимостный оптимизатор, и была по этому поводу ра­дость в Ораклундии. Это ведет нас назад, в начало 1990-х. Мы начали говорить, словно старые ворчуны. В любом случае, фундаментальным рациональным обо­снованием, кроющимся за появлением стоимостного оптимизатора, стало же­лание обеспечить больше гибкости при формировании планов выполнения

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

С приходом нового оптимизатора в воздухе запахло магией. Люди возрадова­лись и стали веселиться, празднуя его рождение, так как ожидалось, что он бук­вально изменит лицо оптимизации SQL Oracle и эвентуально придет на смену своему старшему брату - основанному на системе правил оптимизатору, кото­рый верно служил нам многие годы. Но радость была недолгой. Как бы люди ни

любили новый стоимостный оптимизатор, он был всего лишь ребенком. Во

многих случаях он мог хорошо выполнять работу по оптимизации SQL. В ре­зультате люди начали возвращаться назад к старшему брату, который был на­много надежнее.

Процесс взросления стоимостного оптимизатора

Самым большим недостатком стоимостного оптимизатора (на заре Oracle версий 7.0 - 7.2) была наивность. Он полагал, что мир наилучшим образом при­способлен для жизни в нем, и твердо верил в сказки типа равномерного распре­деления данных. Что это значит? Для примера предположим, у нас есть таблица с именем Саг, у которой 100000 строк, а к ней индекс по столбцу Color. Как часть рутинной работы по администрированию, необходимо вычислять статистику и хранить ее в словаре данных, чтобы стоимостный оптимизатор мог, когда это необходимо, использовать статистику для помощи при определении стоимости данного плана оптимизации.

Одна такая коллекция статистики (которая собирается на протяжении мно­гих часов, если среда содержит большие таблицы) заполняет словарь данных сведениями, представляющими 100 разных значений индекса по столбцу Color. В исполнительном периоде, когда оптимизатор строит план выполнения опера­тора SQL для этой таблицы, выдвигается ошибочное предположение, что каж­дый цвет в этой таблице встречается (100000/100) = 1000 раз. Если вам приходилось иметь дело с настоящими промышленными системами, вы пони­маете, что с такими предположениями ничего не стоит остаться в дураках. Те­перь вам понятно, что значит недостаток взрослости.

Добрые старые времена: оптимизатор, основанный на системе правил

Множество попыток ускорить процесс обучения стоимостного оптимизато­ра оказались напрасными. Его время учиться и взрослеть еще только должно было наступить. В результате многие из нас отказались от применения стоимо­стного оптимизатора, пообещав себе вернуться к его использованию позже, когда он подрастет и поумнеет. Это было связано с тем, что его старший брат

(основанный на системе правил оптимизатор) прекрасно работал и справлялся

с 

реальными системами, причем с гораздо большей надежностью и предсказуе­мостью. Но факт есть факт: старший брат, надежный и предсказуемый, тем не менее, оставался негибким (странно, мы часто становимся такими по мере того,

как стареем).