Parse to Execute Ratio = 101

← →
EternalWonderer (2002-11-29 13:09) [0]

TOAD считает, что это нехороший показатель ( High parse to execute ratio). Вопрос: куда его двигать (уменьшать ?) и какими средствами? А может, ничего не надо делать - и так пойдёт?

Этот же вопрос относительно DBWR Average Scan Depth = 2 401. Он меня спрашивает: Number of DB FILES too high? Как ему ответить, что у меня кроме создаваемых по умолчанию всего два Tablespace, и оба по одному файлу (правда, один из них довольно большой)?

Заранее спасибо!

← →
Sergey13 (2002-11-29 13:25) [1]

High parse to execute ratio надо уменьшать. Это показывает что твой сервер больше времени тратит на разбор запросов чем на их собственно выполнение. Способ уменьшения - переменные в запросах и максимальный отказ от динамического создания SQL.
DBWR Average Scan Depth иногда у меня сразу после запуска инстанса ругается. Потом устаканивается.

← →
EternalWonderer (2002-12-15 11:02) [2]

Предположим, имеется копьютерная картотека:
количество карточек - 50 000
количество полей в карточке - 50
основная таблица - 1, справочников - 5.

Для формирования строки данных используется View, в котором объединяются данные нескольких таблиц, обращение к нему с клиента:
select <...> from view where id=<число>.
Данная схема работы не требует содержания дополнительного открытого курсора для каждого клиента, но вызывает High parse ratio.

Можно изменить логику работы, создавая при старте для каждого клиента курсор и обращаясь к нему, передавая значение в курсорную переменную (я не ошибаюсь в терминах?):
select <...> from view where id=:id

Вопрос: имеет ли это смысл, ведь снизив таким образом parse ratio, я буду при этом загружать SQL_AREA открытыми курсорами? А может, это не такая уж нагрузка на сервер, если открытые курсоры содержат лишь одну строку?

← →
Sergey13 (2002-12-15 11:43) [3]

2EternalWonderer (15.12.02 11:02)
При
select <...> from view where id=<число>
ты будешь каждый раз менять это "<число>" в тексте запроса и для сервака это будут РАЗНЫЕ запросы -> нужен разбор(парсинг). Кстати если написать select и Select результат будет тот же.
При
select <...> from view where id=:id
этого не происходит так как тексты посылаемых запросов полностью идентичны -> парсинга не нужно. Сразу биндуются переменные и начинается выборка.

>Данная схема работы не требует содержания дополнительного открытого курсора для каждого клиента
Не понял, почему? Хоть так хоть эдак - все равно курсор образуется.

← →
EternalWonderer (2002-12-16 12:55) [4]

Sergey13 © (15.12.02 11:43)
>Хоть так хоть эдак - все равно курсор образуется.
Образуется - то он образуется, да только в первом случае он сразу же после fetch уничтожается, а во втором -"висит", пока его не закроешь принудительно с клиента, при этом жрёт память SGA. Это очень наглядно видно из TOAD (Kill/trace->Open cursors)

Parse to Execute Ratio = 101 Найти похожие ветки