Временные сегменты автоматически удаляются сервером базы данных, когда SQL-утверждение, для которого они были созданы, будет выполнено, или в конце сеанса пользователя, вставляющего данные во временную таблицу, сохраняющую данные до конца сеанса.
Поскольку выделение и освобождение временных сегментов происходит постоянно, имеет смысл создать отдельное табличное пространство для временных сегментов. В противном случае табличное пространство SYSTEM или другое табличное пространство, содержащее временные сегменты вместе с сегментами данных или индексными сегментами, будет подвержено фрагментации.
Изменения во временных сегментах не записываются в журнальные файлы и не используются при восстановлении экземпляра.
Начиная с версии Oracle 9i, стало возможным автоматическое управление сегментами отката. В режиме автоматического управления пространство для сегментов отката распределяется внутри табличного пространства UNDO. Чтобы использовать автоматический режим, администратору базы данных достаточно создать хотя бы одно табличное пространство UNDO для каждого экземпляра Oracle и установить значение параметра инициализации UNDO_MANAGEMENT равным ‘AUTO’.
В более ранних версиях Oracle управление сегментами отката было возможно только в ручном режиме. Ручное управление сегментами отката является более сложным, чем управление другими сегментами базы данных, поэтому необходимо разобраться во всех деталях функционирования сегментов отката.
Сегмент отката – это набор экстентов, в которых хранятся данные, используемые для отката транзакций, целостности чтения и восстановления. Каждой транзакции назначается уникальный идентификатор и сегмент отката. Сегмент отката является циклическим объектом, в который каждая транзакция может помещать несколько записей. При заполнении текущего экстента может быть использован следующий экстент. Если и в следующем экстенте нет свободного места, может быть выделен дополнительный экстент, при условии, что не достигнуто максимально допустимое количество экстентов.
Сегменты отката, кроме сегмента отката SYSTEM, могут сохранять изменения, сделанные в любых табличных пространствах. Системный сегмент отката SYSTEM находится в системном табличном пространстве SYSTEM и используется только для хранения данных отката этого табличного пространства, и никакого другого. Поэтому, если используется несколько табличных пространств, необходимо иметь кроме сегмента отката SYSTEM, по крайней мере, еще один сегмент отката.
Сегменты отката должны быть настроены для обработки одновременно выполняющихся транзакций, а также транзакций различной сложности. Чем больше сложность и время выполнения транзакции (например, обновление большого числа строк), тем большим должен быть размер сегмента отката. Чем больше пользователей одновременно обновляет данные, тем больше требуется сегментов отката. Поскольку сегменты отката могут динамически увеличиваться и уменьшаться до размера, заданного параметром OPTIMAL, следует точно определить, сколько пространства в действительности требуется сегменту отката.
Одна из наиболее общих проблем, с которыми сталкиваются администраторы баз данных, связана с фрагментацией, при которой напрасно расходуется пространство и снижается производительность системы. Под фрагментацией базы данных подразумевается фрагментация табличных пространств и фрагментация объектов базы данных.
Фрагментация базы данных возникает вследствие вставки, обновления и удаления строк, а также, создания и удаления объектов. Вновь создаваемая база не фрагментирована, признаки фрагментации начинают проявляться только после запуска приложений, активно работающих с данными или структурами данных.
Табличное пространство фрагментируется вследствие создания и удаления объектов базы данных внутри табличного пространства. Заметим, что табличное пространство не фрагментируется никакими действиями на уровне строк. При удалении объектов возникают фрагменты свободного пространства между используемыми экстентами. Образовавшиеся фрагменты могут использоваться повторно только в том случае, если создается объект, который помещается в пространство, освобожденное удаленным объектом.
Рассмотрим пример. Предположим, что в табличном пространстве имеется четыре таблицы: служащих (EMPLOYEE), заказчиков (CUSTOMER), компаний (COMPANY) и акций компании (STOCK). Каждый из этих объектов занимает экстент размером 10 Мбайт, в конце табличного пространства имеется свободный экстент размером, также, 10 Мбайт (Рисунок 2).
Рисунок 2 Табличное пространство до фрагментации
Из соображений повышения производительности (или секретности) таблицу заказчиков необходимо перенести в другое табличное пространство, а в этом табличном пространстве требуется создать таблицу полисов (POLICY), имеющую размер начального экстента 15 Мбайт. Наше табличное пространство имеет 20 Мбайт свободного пространства, но максимальный размер любого свободного экстента всего 10 Мбайт, поэтому создание таблицы полисов закончится неудачей (Рисунок 3).
Рисунок 3 Табличное пространство после удаления таблицы
При реальной работе с базой данных подобные проблемы возникают достаточно часто, т.к. постоянно удаляются и создаются с другими размерами объекты базы данных. В результате образуются фрагменты свободного пространства по всему табличному пространству. Общий объем свободного пространства может быть вполне достаточным, но отсутствие больших смежных экстентов ограничивает использование свободного пространства.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.