В каждой из форм секционирования индексов может проявляться независимость секций. Какой бы ни была форма индекса, построенного для секционированной таблицы, имеет место также независимость секций на табличном уровне. Благодаря этому индексный поиск выполняется при наличии и возможности использования требуемой секции индекса, и такой поиск может вызвать выборку строки, если при этом доступна требуемая секция таблицы. Поэтому локально секционированные индексы (где индекс и таблица равносекционированы) отличаются наилучшими показателями доступности.
Непригодные для использования индексные секции
Уникальные индексы создаются для ускорения запросов и поддержки ограничений целостности. Если индекс (или хотя бы требуемая секция) недоступен, ограничение установить нельзя, поэтому выполнение DML-one-раций над данными не допускается. По этой причине делайте, где возможно, уникальные индексы локально, а не глобально секционированными.
В Oracle неуникальные индексы используются исключительно для поддержки обработки запросов (включая фазу запроса для операций обновления и удаления). Отметим, что можно обновлять таблицу (или секцию) даже тогда, когда индекс недоступен. Однако если вы обновите таблицу, то индекс станет устаревшим. В данном случае он отмечается как непригодный для использования до тех пор, пока не будет перестроен, для чего может понадобиться время.
Локально нрефнксировапныс секции
При использовании индекса, лидирующим компонентом которого является ключ секционирования таблицы, мы получаем самую высокую степень интеграции между табличными и индексными секциями. Всякий раз, когда требуется индексный поиск, оптимизатор может определить по словарю данных, в какой индексной секции будет расположен этот ключ (если он существует). Для выполнения поиска должна быть доступна только данная индексная секция. Поскольку она локальна, при выполнении DML-операций над секцией таблицы должна быть доступна только одна индексная секция. Это гарантирует, что данный индекс всегда будет актуальным. На первый взгляд такой метод секционирования индекса, возможно, покажется наиболее предпочтительным. Но мы не поддерживаем идею выбора ключа секционирования для таблицы в зависимости от того, как проектировщик хочет использовать локально префик-сированный секционированный индекс.
Локально нспрефиксироваиные секции
К сожалению, найти составной ключ, который был бы по-настояшему полезен и имел бы в качестве лидирующего компонента ключ секционирования, непросто. В нашем примере с телефонными звонками вполне вероятно, что большинство условий для call_start будут указаны в виде диапазона (оператор BETWEEN). Мы могли бы разбить call_from на код региона или
64	Orach-8