powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / cost-based optimizers
6 сообщений из 31, страница 2 из 2
cost-based optimizers
    #32998944
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А пра оракл кто раскажет ?
...
Рейтинг: 0 / 0
cost-based optimizers
    #32998960
nkulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
DB2 не будет каждый раз компилировать динамический запрос, а запишет его в кэш динамических запросов.
...
Рейтинг: 0 / 0
cost-based optimizers
    #32998961
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nkulikovQuery Patroller - это инструмент управления нагрузкой (workload)
Хм. Мне казалось, что он же определял использование объектов и контролировал соответствие оценки плана реальной стоимости. И там была такая стрелочка обратной связи - мол, когда оценка сильно расходится, пора собирать статистику. Все наврал?
...
Рейтинг: 0 / 0
cost-based optimizers
    #32998982
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nkulikovDB2 не будет каждый раз компилировать динамический запрос, а запишет его в кэш динамических запросов.
С планом ?
...
Рейтинг: 0 / 0
cost-based optimizers
    #32999010
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivА пра оракл кто раскажет ?
Про оракл трудно рассказать коротко и полно.

Прежде всего - у оракла, как полагаю и у любого сервера, есть кэш запросов. Соответственно, если запрос находится в кэше - каждое новое выполнение пользуется ранее составленным планом. В ряде случаев требуется перестроение плана - и соответственно, кэш сбрасывается; например, после любого DDL, затрагивающего объекты запроса.

В режиме, используемом по умолчанию, запросы, отличающиеся значениями констант, считаются разными запросами; запросы, отличающиеся значениями подстановочных переменных, считаются одним запросом. Таким образом, программист может гибко выбирать между минимизацией работы оптимизатора и максимальным использованием статистики - выбирать между ними внутри одного запроса. Стоит отметить, что для по-настоящему нагруженных OLTP использование кэша запросов - ключевой фактор; если в удачный момент времени дать команду "alter system flush shared pool", сервер может просто упасть. Также - после перезагрузки серверу требуется заметное время, чтобы выйти на полную скорость (наполнить кэш, вытеснив оттуда случайные запросы и сохраняя постоянные).

Запросы, подаваемые любым способом, обрабатываются одинаково.

Ряд деталей связаны с различными "развитыми" возможностями Oracle. В частности: (могу что-то забыть)

- Синонимы. Обычно, если два пользователя выполняют "select * from a" - это два разных запроса, поскольку обращаются к разным таблицам. Oracle, однако, дает возможность определить синоним "a" для таблицы "user1.a" - и тогда это могут быть как разные запросы, так и один запрос.

- Права на процедуры. ХП в Oracle могут выполняться как с правами владельца процедуры, так и с правами вызвавшего процедуру. Это соответственно влияет на использование динамического sql, вызываемого из процедур.

- FGAC. В Oracle реализован механизм virtual private database; грубо его можно описать, как "к запросу, поданному пользователем 22, автоматически добавляется "where user_id = 22". Также понятным образом влияет на кэш.

- Не помню как называется. Система прав на поля записей. Пользователю, у которого нет прав, просто вернется null в соответствующей колонке. Тоже может влиять на план, если колонка употреблена в where - не проверял.
...
Рейтинг: 0 / 0
cost-based optimizers
    #32999011
Yo!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
MasterZivА пра оракл кто раскажет ?

http://www.oracle.com/technology/oramag/webcolumns/2003/techarticles/burleson_cbo_pt1.html


а в 10ке еще:

Фактически Automatic SQL Tuning основана на усовершенствованной версии оптимизатора запросов. Обычный оптимизатор запросов был усовершенствован в Oracle 10g для выполнения дополнительного анализа перед процессом построения плана выполнения SQL-предложения. Мы будем называть такое состояние оптимизатора запросов, как Automatic Tuning Optimizer, для того, чтобы отличать это состояние от стандартного. Оптимизатор запросов (в обычном состоянии) имеет строгие ограничения на время и системные ресурсы, которые он может использовать для поиска наилучшего плана выполнения заданного SQL-предложения. Приемлемое время оптимизации обычно меньше секунды и не больше, чем несколько секунд. Из-за этого строгого требования оптимизатор может выполнять лишь ограниченный план поиска, используя эвристику тогда и только тогда, когда это может сократить время на оптимизацию. Следовательно, оптимизатор запросов не может выполнить трудоемкий анализ и этапы проверки перед процессом генерации плана.

Напротив, выполнение Automatic Tuning Optimizer обычно занимает намного больше времени, обычно несколько минут для того чтобы выполнить необходимые исследования и этапы проверки, как части процесса настройки. Таким образом, Automatic Tuning Optimizer имеет гораздо более высокую вероятность сгенерировать хорошо отлаженный план. Automatic Tuning Optimizer использует динамический отбор и частичное выполнение (то есть, выполнение фрагментов SQL-предложений), для проверки собственной оценки стоимости, избирательности и кардинального числа (cardinality). Он также использует предысторию выполнения SQL-предложений для определения оптимальных параметров настройки (например, режима оптимизатора).

http://www.citforum.ru/database/oracle/dev_sql_tuning1/
...
Рейтинг: 0 / 0
6 сообщений из 31, страница 2 из 2
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / cost-based optimizers
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]