используется разумная политика индексации, то нет причин для возникновения проблем с производительностью при нормальной работе. Однако такие таблицы могут стать весьма неудобными для администрирования и восстановления. Например, резервное копирование табличного пространства, содержащего такую таблицу, как правило, занимает много времени, и, поскольку таблица в Oracle? не может охватывать несколько табличных пространств, копировать нужно все или ничего. Большие таблицы часто загружаются огромным количеством данных, и, если механизм загрузки данных использует опцию прямой загрузки утилиты SQL*Loader, таблицу во время обновления использовать нельзя.
Такие административные проблемы вынуждают разработчиков хранилищ данных секционировать большие таблицы данных. В Oracle? они делают это путем создания ряда таблиц меньшего размера, как правило, для соответствующих дат. Давайте в качестве примера рассмотрим телефонную компанию. Вместо того чтобы создавать одну таблицу для регистрации всех вызовов, производимых абонентами, создается таблица CALLS для каждого месяца — CALLS9801, CALLS9802 и т.д. (рис. 4.1). Когда приложению требуется общая картина данных, оно обращается к этим таблицам через представление, которое выполняет с отдельными таблицами операцию UNION ALL. Данный метод очень хорошо работает с запросами, но, к сожалению, обновление непосредственно через такое представление выполнять нельзя, и приложение должно внимательно следить за тем, чтобы команды DML выполнялись по отношению к соответствующей таблице. Для приложений, не связанных с хранилищами данных, ручное секционирование подходит в меньшей степени.
CALLS OLD
CALLS9801	CALLS9802
Рис. 4.1. Секционированная таблица
50
Oracle 8