сделать определенные допущения: поскольку цель секционирования — распределение таблицы, у вас должны быть секции приблизительно одинакового размера, и вам следует очень тщательно спланировать конфигурацию разделов. Впоследствии изменить конфигурацию будет нелегко — придется просмотреть и перезагрузить все данные в задействованных секциях. Для этого Oracle предлагает набор опций ALTER TABLE, но для больших объемов данных их выполнение потребует много времени. Кроме того, существует опция SPLIT PARTITION, однако опция MERGE PARTITIONS отсутствует (по крайней мере, пока). Она, кажется, является очевидным кандидатом на реализацию в будущем.
Совет:
Oracle позволяет создавать как секции без указания имен для них, так и неименованные ограничения (unnamed constraints). Как и в случае с ограничениями, сервер формирует имя для каждой неименованной секции, и вам придется отыскивать это имя в словаре данных, если в какой-то из последующих операций нужно будет сослаться на конкретную секцию (например, в операции DROP или SPLIT).
Требуйте, чтобы все секции именовались явно и пользуйтесь правилом, которое мы применяем в данной главе: указывайте в имени диапазон ключа секционирования. Однако нет необходимости предварять имя секции именем таблицы, поскольку имена секций относятся к пространству имен объектов, а не схем.
Одна из целей секционирования — уменьшить область возможного разрушения данных. По этой причине в большинстве случаев применяются как минимум двузначные номера секций. Нам приходилось видеть таблицу более чем с 1000 секциями (при этом каждая секция охватывала один день из трехлетнего периода). Если бы мы хотели предложить для нашей таблицы CALLS другую стратегию секционирования, то могли бы просто проверить каждый столбец в качестве ключа секционирования (причем, когда одиночные столбцы недостаточно избирательны, можно проверить комбинации столбцов). Например, таблицу CALLS нам, возможно, пришлось бы разбить по столбцу call_from, чтобы секционировать ее по коду зоны или по коду АТС. Однако если при этом мы попытаемся секционировать таблицу по трехзначному коду зоны в Северной Америке, то получим перекос секций. Почему? Потому что в зоне Нью-Йорка (код 212) производится гораздо больше звонков, чем на Аляске (код 907). Если мы собираемся определять область возможного разрушения данных, ориентируясь на Нью-Йорк (Лос-Анджелес, Чикаго и т.д.), то придем к выводу, что наличие нескольких десятков маленьких секций не решит задачу, поэтому попробуем слить несколько таких секций в одну. К сожалению, эта операция значительно осложняется синтаксисом, который используется для задания значений диапазонов ключей секционирования (значения всех ключей в данной секции должны находиться в непрерывном диапазоне).
4. "Большие" особенности OracleS	55