которое является следствием неравномерности распределения по кодам зон. Хотя мы и можем иметь в одной секции несколько смежных небольших кодовых зон, у нас нет той свободы, которую хотелось бы иметь.
Давайте вернемся к стратегии секционирования по датам. Этот подход в любом случае более удобен для нас, потому что мы знаем, что должны иметь возможность сразу удалить из таблицы данные за один месяц. Мы также в курсе, что можем делать это очень эффективно, используя одну секцию для месяца. Кроме того, несмотря на возможные сезонные пики в общем количестве звонков, все секции будут иметь приблизительно одинаковые размеры. Далее, ключ секционирования является частью первичного ключа, поэтому нам не понадобится глобальный уникальный индекс, чтобы обеспечить целостность первичного ключа. Все это просто здорово!
Когда мы выдадим запрос:
SELECT call_from, call_to, call_start, call_seconds
FROM calls
WHERE call_secs > 86400 /* длительность разговора больше 24 часов */ AND call_start BETWEEN '03-MAR-98' AND '10-MAR-98';
ему нужно будет просмотреть лишь секцию за март 1998 года. Да-да, ему следует просмотреть только одну секцию, но наши тесты показывают, что на самом деле он просматривает все секции. Если же мы изменим запрос так, чтобы он содержал равенство по ключу секционирования (и в данном случае выдавал сообщение только по одному дню):
SELECT call_from, call_to, call_start, call_seconds
FROM calls
WHERE call_secs > 86400 /* длительность разговора больше 24 часов */ AND call_start = '03-MAR-98';
оптимизатор обнаружит, что все заданные строки должны находиться в секции за март 1998 года, и будет просматривать только эту секцию.
Нам удалось обойти данную проблему, создав секционированные индексы (см. следующий раздел), но обнаружилось, что результат выполнения EXPLAIN PLAN для таких запросов оказался обманчивым. В конце концов, мы проверили, к каким секциям производится доступ, поместив разные секции в разные табличные пространства и переведя в автономное состояние пространства, доступ к которым не требовался. В этом случае мы знали, что, если запрос выполнялся без ошибок, он пытался обращаться только к тем секциям, к которым и должен был обращаться.
Мы выполнили эти тесты с одной из первых версий OracleS и за то время, которое у нас было, не смогли найти эффективного решения. (Дайте нам знать, если что-нибудь придумаете!) Наш совет: не полагайтесь ни на какие заявленные показатели производительности, а тщательно проверьте, до какой степени оптимизатор запросов использует знание вашей структуры секционирования.
4.  "Большие" особенности OrnclcS	61