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

дежа ею. 

И это хорошо. Поскольку оператор уже выполнялся по крайней мере один раз, у него имеется дерево разборки и связанный с ним план выполнения, следовательно, нет необ­ходимости их перестраивать. Ну, что же, сэкономим время.

Если основной объект, на который ссылается оператор SQL, в промежутке времени между предьщущим и текущим выполнением претерпел какие-то струк­турные изменения (команды alter, analyze и т. п.), оператор будет помечен флажком INVALID. Теперь текущий процесс сервера, выполняющий этот опера­тор SQL, может перестроить план выполнения разбираемого оператора. На­пример, в случае analyze все SQL в библиотечном кэше, ссылающиеся

на подвергшийся анализу объект, должны быть признаны недействительными.

Почему?

Если ваша таблица первоначально содержала 1 млн строк и пакетное задание только что влило в нее еще 5 млн строк, вы, как ответственный АБД, непремен­но выполните свою работу и обязательно используйте команду analyze для ва­шей таблицы, как только будет закончен процесс закачки данных. А не кажется ли вам, что оптимизатор Oracle тоже имеет право знать о том, что вы прогнали для вашей таблицы команду analyze?

Если оптимизатор даже не подозревает о появлении новой        как

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

операторов DDL, модифицирующих структуру любого объекта или любой кол­лекции статистики объектов. Теперь вернемся к противостоянию жесткой и

мягкой разборок.

Процесс сервера переходит к фазе связывания (описанной в предыдущем разделе), а потом к фазам выполнения и выборки. И, наконец, напомним еще раз, что фаза выборки выполняется только в том случае, если оператор SQL яв­ляется оператором 

select.

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

мягкие разборки. А может быть, они говорят о зубных щетках?

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