Документация Oracle на русском языке





Сайт посвящен разработке информационных систем с использованием технологий Oracle. На сайте можно найти полезную литературу и документацию на русском языке по программированию и администрированию Oracle.Программирование баз данных на Oracle, техническая документация, литература, статьи и публикации.

Главная :: Карта


Oracle Database или Oracle RDBMS — объектно-реляционная система управления базами данных компании Oracle.



 

DeepEdit!

Программирование баз данных на Oracle, техническая документация, литература, статьи и публикации

  • Увеличить размер шрифта
  • Размер шрифта по умолчанию
  • Уменьшить размер шрифта

Жесткая и мягкая разборки


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

дежа ею. 

И это хорошо. Поскольку оператор уже выполнялся по крайней мере один раз, у него имеется дерево разборки и связанный с ним план выполнения, следовательно, нет необ­ходимости их перестраивать. Ну, что же, сэкономим время.
Если основной объект, на который ссылается оператор SQL, в промежутке времени между предьщущим и текущим выполнением претерпел какие-то струк­турные изменения (команды alter, analyze и т. п.), оператор будет помечен флажком INVALID. Теперь текущий процесс сервера, выполняющий этот опера­тор SQL, может перестроить план выполнения разбираемого оператора. На­пример, в случае analyze все SQL в библиотечном кэше, ссылающиеся
на подвергшийся анализу объект, должны быть признаны недействительными.
Почему?
Если ваша таблица первоначально содержала 1 млн строк и пакетное задание только что влило в нее еще 5 млн строк, вы, как ответственный АБД, непремен­но выполните свою работу и обязательно используйте команду analyze для ва­шей таблицы, как только будет закончен процесс закачки данных. А не кажется ли вам, что оптимизатор Oracle тоже имеет право знать о том, что вы прогнали для вашей таблицы команду analyze?
Если оптимизатор даже не подозревает о появлении новой        как
он может хотя бы подумать об изменении плана выполнения для рассматривае­мого оператора SQL, несмотря на такое существенное изменение объема дан­ных в таблице? Без признания операторов недостоверными в принципе невозможно понять, нуждаются ли планы выполнения содержащихся в библио­течном кэше операторов в перестраивании. Следовательно, признание опера­торов SQL из библиотечного кэша недостоверными выполняется для всех
операторов DDL, модифицирующих структуру любого объекта или любой кол­лекции статистики объектов. Теперь вернемся к противостоянию жесткой и
мягкой разборок.
Процесс сервера переходит к фазе связывания (описанной в предыдущем разделе), а потом к фазам выполнения и выборки. И, наконец, напомним еще раз, что фаза выборки выполняется только в том случае, если оператор SQL яв­ляется оператором 

select.

Пропустив шаг построения дерева разборки и плана выполнения, можно сэ­кономить значительное количество ресурсов, не говоря уже о заметном умень­шении конкуренции за различные внутренние ресурсы, необходимые для выполнения жесткой разборки. В случае мягкой разборки время и ресурсы тра­тятся на работу оператора, а не на попытки вычислить, как его следует выпол­нять. Четыре дантиста из четырех рекомендуют: лучше никаких разборок, чем
мягкие разборки. А может быть, они говорят о зубных щетках?
Замечание
Необходимо, чтобы любое старение операторов SQL из области коллективного пула также вызывало жесткую разборку этих операторов, если они не присутствуют в области коллективного пула по вычисленному хеш-адресу. Но когда эти операторы будут разобраны повторно, они отобразятся на тот же хеш-адрес (при условии, что оператор не был каким-либо образом модифицирован).
 


Продвижение сайта москва. Продвижение сайта описание.
jAntivirus