что такое табличное пространство oracle
Обзор табличных пространств (tablespace) и файлов данных
Мы рассмотрели процесс взаимодействия экземпляра и сессий: процессы и структуры памяти. В этой главе мы будем рассмотривать саму БД. Все процессы обработки информации происходят в памяти экземпляра БД, но хранение данных происходит в файлах базы данных на диске. База данных состоит из трех типов файлов: файл контроля, файлы логов и файлов даных. Данные хранятся в файлах данных.
Пользователи никогда не видят физический файл данных. Они видят логические сегменты. Системные администраторы ничего не знают о логических сегментах – они видят файлы. В базе данных Oracle физическая структура абстрагирована от логической. Это одно из требования парадигмы реляционных баз данных. Как DBA вы должны знать связь между логической и физической структурой БД. Мониторинг и администрирование этих структур – задача часто называемая как управление пространством (space management) является большой частью работы DBA. Средства предусмотренные в последних версиях БД могут автоматизировать задачу управления пространством в определенной степени, и они безусловно позволяют DBA настроить хранилище таким образом, чтобы максимально облегчить задачу обслуживания сервера.
Данные логически хранятся в сегментах (обычно таблицах), физически в файлах данных. Табличное пространтсво абстрагирует эти два понятия: в одном табличном пространтсве может храниться несколько сегментов и состоять из нескольких файлов данных. Нету прямой взаимосвязи между сегментом и файлом данных. Файлы данных могуть быть как файлами в файловой системе или (начиная с версии 10g) устройствами Automatic Storage Management (ASM).
Модель хранения данных Oracle
Разделение логической и физической структур является необходимой частю парадигмы реляционных баз данных. Парадигма гласит что программисты должны работать только с логическими структурами и позволять базе данных управлять их соответствием физическим структурам. Это значит что физическая структура может быть преобразована, или к примеру целиком база данных переведена на новое аппаратное обеспечение и операционную системы, а на работу приложений это не должно оказывать никакого влияния.
На рисунке 5-1 отображена модель Oracle как диаграмма сущность-связь, с логическими структурами слева и физическими структурами справа.
На этом рисунке одна линия связи отображена пунктирной линией: связь многие-ко-многим между сегментами и файлами данных. Эта линия выделена пунктиром, так как её не должно быть, отношение многие-ко-многим не допускаются хорошими DBA. Преобразование этой взаимосвязи к нормализованному виду и есть задача организации модели хранения.
Введение сущности табличное пространство (tablespace) разрешает взаимосвязь многие-ко-многим между сегментами и файлами данных. Одно табличное пространство может содержать несколько сегментов и состоять из нескольких файлов данных. Т.е. один сегмент может быть разделён между многими файлами данных, и один файл данных может содержать данные разных сегментов. Это решает много проблем организации хранения данных. В некоторых более старых РСУБД использовалась связь один-к-одному между сегментом и файлом данных: каждая таблица или индекс хранилась как отдельный файл. Это вызывало две большие проблемы для больших систем.
Во первых, в приложении могут использоваться тысячи таблиц и ещё больше индексов; управление тысячами файлов нелёгкая задача для системных администраторов. Во вторых, максимальный размер таблицы ограничен максимальным размером файла. Даже в современных ОС в которых нет ограничений по размеру файла – могут возникнуть проблемы из-за ограничений на аппаратном уровне. Использование табличных пространств решает обе эти проблемы. Табличным пространствам в базе данных присваиваются уникальные имена. Сущность сегмент (segment) представляет собой любой объект базы данных который хранит информаци и таким образом нуждается в пространстве внутри табличного пространства. Типичным примеро сегмента является таблица, но существуют и другие типы сегментов, индексы и сегменты undo. Сегмент может хранится тоьлко в одном табличном пространстве, но само табличное пространство может быть разбитым между многими файлами, которые составляют это табличное пространство. Таким образом размер таблицы больше не ограничивается максимальным размером одного файла. Так как много сегментов могут использовать одно табличное пространство, то становится возможным иметь куда больше сегментов, чем файлов данных. Сегменты это объекты которые принадежат схеме и идентифицируются они именем сегмента с именем схемы-владельца. Программируемые объекты схемы (такие как PL/SQL процедуры, представления или последовательности) не являются сегментами: они не хранят данные и хранятся в словаре данных.
Блоки Oracle это базовая единица операций чтения и записи для базы данных. Файлы данных форматированны на последовательно пронумерованные блоки Oracle. Размер блока определяется для табличного пространства (в общем он един для всех табличных пространств в пределах базы данных), по умолчанию (версия 11g) используется значения 8Кб. Строка может занимать всего несколько сотен байт, поэтому внутри одного блока может хранится несколько строк, но когда сессия хочет получить строку, будет вычитываться целый блок с диска и помещаться в кэш буфера. Также если изменилось значение только одного столбца для одной строки в буфере кэша – DBWn перезапишет на диск весь блок в файл данных откуда он был считан затерев старый. Размер блока Oracle может быть от 2ух до 16 Кб на операционных системах Linux или Windows и до 32 Кб в некоторых других системах. Размер блока контролируется параметром DB_BLOCK_SIZE. После создания базы данных нельзя изменить значение этого параметра, так как он используется для форматирования файлов данных табличного пространства SYSTEM. Если позже оказалось что необходимо изменить значение этого параметра, единственным решением будет создать новую базу и скопировать в неё все из уже созданной. Блок внутри файла можно идентифицировать по его уникальному номеру.
Управление дисковым пространством по одному блоку за раз было бы очень трудоёмкой задачей, поэтому блоки группируются в экстенты (extent). Экстентом называется набор последовательных блоков внутри одного файла данных. Каждый сегмент состоит из одного или более экстентов, последовательно пронумерованных. Эти экстенты могут находиться в любом или во всех из доступных для табличного пространства файлов данных. Экстент можно идентифицировать как внутри сегмента (экстенты последовательно пронумерованы в пределах сегмента начиная с нуля) так и внутри файла данных (каждый сегмент находится только в одном файле данных, начиная с определённого блока Oracle).
Файл данных физически состоит из блоков операционной системы. Как структурированы блоки операционной системы внутри файла данных целиком зависит от файловой системы используемой операционной системой. Некоторые файловые системы имеют общеизвестные ограничения и поэтому не используются в современных системах (например старая файловая система MS-DOS FAT поддерживает файлы размером до 4 Гб и всего 512 файлов в одной директории). Большинство баз данных устанавливается на файловые системы без практических огранчений, такие как NTFS в Windows или ext3 в Linux. Альтернативой файловой системе является хранение файлов данных на raw device-ах или Automatic Storage Management (ASM).
Блок операционной системы это базовый элемент операция записи чтения для файловой системы. Если процесс хочет прочитать один байт с диска подсистема ввода-вывода всё равно считает системный блок целиком. Размер блока операционной системы можно настраивать на некоторых ОС (например когда форматируется диск под файловую систему NTFS можно указать размер блока от 512 байт до 64 Кб), но обычно системные администраторы оставляют значения по умолчанию (512 Б для NTFS и 1Кб для ext3). Вот почему обычно отношение между блоками Oracle и блоками ОС обычно один-ко-многим, как показано на рисунке 5-1. Ничего не мешает сделать размер блока ОС равным размеру блока Oracle если ваша операционная система позволяет сделать это. Единственная конфигурация которой стоит избегать это когда размер системного блока больше чем размер блока Oracle.
Сегменты, экстенты, блоки и строки
Данные хранятся в сегментах. Представление словаря данных DBA_SEGMENTS хранит инфомрацию обо всех сегментах в базе данных. Запрос ниже отображает все типы сегментов в простой БД
Рассмотрим эти сегменты:
Каждый сегмент состоит из одного или более экстентов. Когда сегмент создаётся, Oracle выделяет инициализационный экстент в указанном табличном пространстве. Когда данные будет добавлятся экстент будет заполняться, и Oracle выделит другой экстент, в том же табличном пространстве, но не обязательно в том же файле данных. Если вы знаете что сегменту понадобится больше дискового пространства, вы можете вручную выделить экстент для этого сегмента. На рисунке 5-2 показано как определить расположение сегмента. Вначале создаётся таблица HR.NEWTAB используя параметры по умолчанию. Затем результат выполнения запроса к DBA_EXTENTS отображает, что сегмент состоит из одного экстента с номером ноль. Этот экстент находится в файле номер четыре и занимает 8 блоков. Первый из восьми блоков имеет номер 1401. Разме экстента 64 Кб, что говорит о том что размер блока 8 Кб. Следующая команда указывает Oracle что необходимо выделить ещё один сегмент для этого сегмента несмотря на то что первый экстент ещё не заполнен. Следующий запрос отображает что номер нового экстента равено единице, файл данных также с номером четыре и блоки выделены сразу после блоков первого экстента.
Отметим что из этого примера не совсем понятно из скольки файлов состоит табличное пространство, потому что алгоритм выбора файла для создания следующего экстента не просто очередь. Если табличное пространство состоит из нескольких файлов данных вы может указать в каком конкретно файле выделить экстент используя следующий синтаксис
ALTER TABLE tablename ALLOCATE EXTENT STORAGE (DATAFILE ‘filename’);
Последний запрос на рисунке 5-2 обращается к представлению DBA_DATA_FILES для нахождения имени файла в котором был выделен экстент, и название табличного пространства которому принадлежит файл данных. Для определения табличного пространства таблицы также можно использовать представление DBA_SEGMENTS.
Экстент состоит из набора последовательно пронумерованных блоков. У каждого блока есть область заголовок и область данных. Область заголовка имеет не фиксированный размер и записывается от начала блока. Помимо прочего, заголовок содержит информацию о строках (откуда в блоке начинается каждая строка) и информацию о блокировках. Область данных заполняется с конца блока. Между этимя двумя областями может быть (или не быть) пустое место. Событиями которые приведут к увеличению области заголовка является вставка данны и блокировка строки. Область данных вначале пусткая и затем заполняется по мере того как записываются новые строки (или ключи индекса если это блок сегмента индекса). Пусте пространство будет фрагментировано по мере вставки, удаления и изменения (что может привести к изменение размера строки) строк, но это не важно так как все операции с данными производятся в кэше буфера. Фрагментированное пространство объединяется когда это необходимо, обычно перед записью блока назад в файл данных процессом DBWn.
Табличные пространства Oracle: типы, виды, назначение и управление
Размер ваших табличных пространств зависит от размера ваших таблиц и индексов, а также общего объема данных в баз — здесь не существует правил о минимальном и максимальном размере табличного пространства (максимально возможный размер слишком велик, чтобы принимать это ограничение во внимание). Обычным делом являются табличные пространства размером в 100 Гбайт, сосуществующие в одной и той же базе данных с табличными пространствами в 1 Гбайт и даже намного меньше.
Файлы данных, содержащие данные табличных пространств, все вместе составляют общий объем физического пространства, выделенного определенной базе данных. Размер табличного пространства складывается из размеров файлов, содержащих данные, и если вы сложите все размеры табличных пространств или размеры всех файлов данных, то получите размер самой базы данных. Если вы выйдете за пределы базы данных, добавляя новые данные, вам понадобится добавить новые табличные пространства с новыми файлами данных, добавить новые файлы данных к существующим табличным пространствам, или же увеличить существующие файлы данных табличных пространств. Как это делается будет показано в следующих моих статьях.
Не существует простого и общеприменимого правила, регламентирующего количество табличных пространств, которые вы можете иметь в одной базе данных Oracle.
Следующие пять табличных пространств обычно представляют собой табличные пространства по умолчанию, которые должны иметь все базы данных, даже несмотря на то, что в принципе можно создать базу данных включающую всего два из них:
Традиционно администраторы Oracle используют десятки, а иногда и сотни табличных пространств для хранения всех прикладных таблиц и индексов, и если вы уверены, что действительно потребуется большое количество табличных пространств для группирования всех взаимосвязанных прикладных таблиц и индексов, то это нормально. Однако вы не обязаны использовать большое количество табличных пространств. Сегодня большинство организаций применяют диспетчер Logical Volume Manager для разнесения логических томов и файлов данных на множество физических дисков. Таким образом, крупные табличные пространства могут занимать несколько физических дисков. Раньше приходилось создавать разные табличные пространства на разных физических дисках, чтобы избежать конкуренции ввода-вывода, но современные структуры организации дисков устранили эту проблему, и вы при желании можете обойтись меньшим числом табличных пространств. Вы можете использовать только одно табличное пространство для всех прикладных данных, по-скольку файлы данных, являющиеся частью табличного пространства, могут быть “размазаны” по нескольким дискам. Именно поэтому традиционное требование размещать таблицы и индексы в разных табличных пространствах отныне не так важно.
Для чего нужны табличные пространства?
Табличные пространства выполняют ряд ключевых функций в базе данных Oracle, но концепция табличного пространства не является общей для всех реляционных баз данных. Так, например, в базе данных Microsoft SQL Server эта концепция не используется вообще. Ниже приведен краткий список преимуществ использования табличных пространств.
Табличные пространства теперь используются, прежде всего, для разделения определенных групп таблиц и индексов. Это может быть важно, если вы хотите перемещать табличные пространства между разными базами данных и платформами, используя утилиту Oracle Data Pump, или если вы применяете разные размеры блоков данных в разных табличных пространствах. Если вы полагаете, что вам не придется выполнять эти административные задачи с использованием табличных пространств, то можете применять всего пару табличных пространств для хранения всех данных базы.
Размеры блоков и табличные пространства
Каждое табличное пространство использует размер блока по умолчанию, установленный для базы данных, если только вы не создадите табличного пространства с нестандартным размером блока. Как уже говорилось, Oracle позволяет иметь несколько размеров блоков в дополнение к размеру блока по умолчанию. Поскольку табличные пространства в конечном итоге состоят из блоков данных Oracle, это означает, что можно иметь табличные пространства с разными размерами блоков Oracle в одной и той же базе данных. Это замечательное средство, которое предоставляет возможность выбирать наиболее подходящий размер блока для табличного пространства, в зависимости от структуры данных содержащихся в нем таблиц.
Настройка размера блока для табличного пространства обеспечивает несколько преимуществ
Оптимизация операций дискового ввода-вывода. Помните, что сервер базы данных Oracle должен читать табличные данные с физических дисков в область буфера кэширования для дальнейшей обработки. Одной из главных ваших целей,как администратора базы данных, является оптимизация дорогостоящего ввода-вывода при чтении и записи на диск. Если у вас есть таблицы с очень длинными строками, лучше выбрать большой размер блока — тогда каждое чтение извлечет больше данных, чем вы получите при меньшем размере блока, и в результате для получения того же объема данных понадобится меньше операций чтения. Таблицы с большими объектами (LOB) также выиграют от очень блоков очень большого размера. С другой стороны, таблицы с малой длиной строки могут использовать блоки малого размера в качестве строительных блоков табличного пространства. Если у вас в базе есть индексы огромного размера, вам понадобится большой размер блока для их табличного пространства, чтобы каждое чтение извлекало большее количество указателей индекса.
Оптимальное кэширование данных. Oracle выделяет отдельные пулы для блоков различного размера, что приводит к лучшему использованию памяти Oracle. Мы поговорим об этом в последующих разделах.
Облегчение переноса табличных пространств. Если есть табличные пространства с несколькими размерами блоков, легче будет использовать средство “переносных табличных пространств”. В дальнейшем я планирую опубликовать статью, в которой вы найдете примеры, демонстрирующие процесс переноса табличных пространств между базами данных Oracle (готово! читайте эту статью).
На заметку! Каждое табличное пространство Oracle состоит из одного или более файлов операционной системы с данными, и каждый такой файл может относиться только к одному табличному пространству. Во время создания базы данных только два табличных пространства должны присутствовать обязательно. Это табличное пространство System (ключевое табличное пространство Oracle, содержащее данные словаря Oracle) и табличное пространство Sysaux (которое является вспомогательным табличным пространством для System и содержит данные, используемые различными продуктами и средствами Oracle). При инсталляции Oracle сначала автоматически создает табличное пространство System, а за ним — Sysaux, но вы указываете файл данных для каждого из них. Позднее можно добавлять и удалять табличные пространства по своему желанию, однако нельзя удалить или переименовать табличные пространства System и Sysaux.
Конечно, вы должны также создать отдельные табличные пространства приложений, чтобы хранить данные и индексы. Именно эти табличные пространства будут составлять основную часть размера базы данных.
Локально управляемые табличные пространства Oracle сами хранят информацию для управления пространством в файлах данных и отслеживают состояние свободы или занятости блоков каждого файла данных. Информация о свободном и занятом пространстве в файлах данных хранится в виде битовых карт внутри заголовков файла данных. Битовые карты (bitmaps) — это структуры, использующие отдельные биты для описания места в блоке или группе блоков. Помните, что когда объекту нужно расти,Oracle выделяет ему новое пространство, измеряемое в экстентах, а не в индивидуальных блоках данных. Поэтому когда новый экстент должен быть выделен объекту, Oracle выбирает первый свободный файл данных и просматривает его битовую карту в поисках свободных непрерывных блоков данных. Если подходящий блок найден, то Oracle выделяет экстент и затем изменяет битовую карту в файле данных, чтобы изменить статус занятости блоков в экстенте.
Во время этого процесса словарь данных никак не используется, поэтому рекурсивные операции SQL значительно сокращены. Информация отката (rollback) не генерируется во время этого обновления битовых карт файлов данных. Это преимущество особенно существенно, если база данных относится к типу OLTP, с многочисленными вставками, удалениями и обновлениями, которые происходят непрерывно.
Типы табличных пространств
Помимо табличных пространств System и Sysaux, скорее всего, у вас будут табличные пространства Undo и Temporary. У вас также будет несколько других “постоянных” табличных пространств для хранения данных и индексов.
Ниже перечислены ключевые типы табличных пространств, с которыми вам, вероятно, придется встретиться.
Создание и управление табличными пространствами
Табличные пространства это хранилище для данных схемы, включая словарь данных (который находится в схеме SYS). У всех баз данных обязаны быть табличные пространства SYSTEM и SYSAUX и (для работы с БД) временное табличное пространство и пространство undo. Обычно эти четыре табличных пространства создаются на этапе создания БД. В дальнейшем DBA может создавать много других табличных пространств для пользовательских данных, и возможно дополнительные пространства для undo и временных данных.
Создание табличного пространства
Для создания табличного пространства с помощью Enterpise Manager Database Control с домашней страницы базы данных перейдите на вкладку Server и нажмите на ссылку Tablespaces в разделе Storage. На рисунке 5-3 отображается результат для БД по умолчанию.
Рисунок 5-3 – Табличные пространства в БД ocp11g
Для каждого табличного пространства отображаются:
Эту же информацию можно получить написав запрос к предсатвлениям словаря данных DBA_TABLESPACES, DBA_DATA_FILES, DBA_SEGMENTS и DB_FREE_SPACE. К примеру результатом выполнения запроса
select t.tablespace_name name, d.allocated, u.used, f.free,
t.status, d.cnt, contents, t.extent_management extman,
from dba_tablespaces t,
(select sum(bytes) allocated, count(file_id) cnt from dba_data_files
where tablespace_name=’EXAMPLE’) d,
(select sum(bytes) free from dba_free_space
where tablespace_name=’EXAMPLE’) f,
(select sum(bytes) used from dba_segments
where tablespace_name=’EXAMPLE’) u
На этой же странице нажмите кнопку CREATE для создания нового табличного пространства. Новое окно создания запросит название нового табличного пространства, значения для Extent Management, Type и Status. В большинстве случаев значения по умолчанию валидны: Local, Permanent и Read Write. Затем кнопка ADD позволяет указать один или более файлов данных для нового табличного пространства. Для каждого файла необходимо указать имя файла и размер, также опционально можно включить autoextend до максимального допустимого размера файла. Возможность autoxtend позволяет Oracle серверу самому увеличиваться размер файлов данных при необходимости, что позволит избежать ошибок из-за нехватки места. На рисунках 5-4 и 5-5 отображены окна Database Control для создания табличного пространства NEWTS с одним файлом данных.
Рисунок 5-4 Окно создания табличного пространства 
Рисунок 5-5 Окно добавления файла данных
Нажав кнопку CONTINUE вы вернётесь к окну создания табличного пространства. Нажатие кнопки SHOW SQL отобразит сгенерированный запрос
Рассмотрим эту команду построчно
1 CREATE SMALLFILE TABLESPACE «NEWTS» – табличное пространство будет пространством типа SMALLFILE. Это значит что оно может состоять из множества файла данных. Альтернативой является BIGFILE, в этом случае невозможно добавить новый файл данных (но всё так же можно изменить размер). Флаг Use Bigfile Tablespace на рисунке 5-4 определяет это значение
2 DATAFILE – ‘/u02/oradata/ocp11g/newts01.dbf’ Имя и расположение файла данных
3 SIZE 100M AUTOEXTEND ON NEXT 100K MAXSIZE 200M – Файл данных будет создан размеров 100 Мб, при заполнении будет автоматически выделяться 100Кб до максимально допустимого значения в 200 Мб. По умолчанию автоматическое выделения места не включено.
4 LOGGING – Все операции над сегментами в табличном пространстве будут генерировать данные для повтора изменений (redo): это значение по умолчанию. Возможно отключить генерацию redo только для нескольких операция (таких как создание индекса)
5 EXTENT MANAGEMENT LOCAL – табличное пространство будет использовать битовые карты для выделения экстентов; значение по умолчанию
6 SEGMENT SPACE MANAGEMENT AUTO – Сегменты в табличном пространстве будут использовать битовые карты для отслеживания использования блоков; значение по умолчанию
Если выбрать вкладку Storage в окне создания табличного пространства то можно управлять параметрами управления экстентами и сжатия – Рисунок 5-6.
Рисунок 5-6 Дополнительные параметры создания табличного пространства
Когда используется локальное управление экстентами, возможно включить функционал согласно которому все экстенты в табличном пространстве будут одного размера. Также доступны опции сжатия, логирования.
Пример команды создания табличного пространства выполненной в SQL* Plus показан на рисунке 5-7.
Табличное пространство STORETABS состоит из двух файлов данных, оба без автоинкремента. Единственное различие от команды по умолчанию это указание размера extent-а в 5 МБ. Первый запрос на рисунке показывает что файлы не большие иначе нельзя было бы создать два файла данных. Второй запрос на рисунке отображает информацию о табличном пространстве TEMP, используемом для хранения временных объектов. Важно понимать что временное табличное пространство использует временные файлы, а не файлы данных. Временные файлы перечислены в пресдатвлении V$TEMPFILE и DBA_TEMP_FILES, когда файлы данных перечислены в V$DATAFILE и DBA_DATA_FILES. Также важно отметить что V$ и DBA показывают разную информацию. В V$TABLESPACE находится информация является ли табличное пространтсво «большим» и в V$TEMPFILE (или V$DATAFILE) размер файлов. Этой информации нет в представлениях DBA. Но представления DBA содержат детальную информацию о экстентах и сегментах. Разная информация доступна либо там либо там, так как некоторая информация хранится в файле контроле (и доступна только в V$ представлениях), а другая хранится в словаре данных (и видима в DBA представлениях). Остальная информация дублируется.
Изменение табличных пространств
Изменения происходящие над табличным пространством после создания обычно
Переименование табличного пространтсва и его файлов
ALTER TABLESPACE tablespaceoldname RENAME TO tablespacenewname;
Синтаксис очень прост но выполнение команды может доставить проблемы в будущем. Множество установок полагаются на название файлов чтобы соотносить файлы данных с табличными пространствами. На наших примерах видно что просто доавляется имя табличного пространства в имя файла и доабвляется номер. Oracle всё равно: взаимосвязь определяется нормерами табличных пространств и файлов. Эти номера доступны в столбцах TS# представления V$TABLESPACE и FILE# представления V$DATAFILE. Если вы зависите от названий, тогда вам нужно так переименовать файлы. Табличное пространство может быть переименовано в любое время, в том время как файлы можно переименовать только когда они не используются (offline). Это необходимо так как файлы переименовываются и на уровне операционной системы и все дескрипторы станут невалидными. Рисунок 5-8 показывает пример такого процесса над табличным пространством созданным на рисунке 5-7.
Первая команда изменяет имя табличного пространства. Это самая легкая часть. Затем табличное пространство выключается, и выполняются команды операционной среды переименовать файлы. Затем две команды ALTER DATABASE изменяют имена файлов в файле контроля, и Oracle сможет их найти. И наконец табличное пространство включается.
Включение и выключение табличного пространтсва (Online/Offline)
Включенным табличным пространством является пространство готовое к использованию; выключенное табличное пространство определено в словаре данны и файле контроля, но его нельзя использовать. Табличное пространтсво может быть включенным, но один или несколько файлов данных внутри него могут быть выключены. Такая ситуация может привести к неожиданным результатам и следует избегать её возникновения.
Синтаксис для выключения табличного пространства
ALTER TABLESPACE tablespacename OFFLINE [NORMAL|IMMEDIATE|TEMPORARY]
Обычное выключение (NORMAL – значение по умолчанию) запустит создание контрольной точки для всех файлов данных этого пространства. Все грязные буфферы в кэше которые содержат блоки из табличного пространтсва будут записаны в файлы данных и табличное пространство и файлы данных будут выключены.
Режим IMMEDIATE выключает табличное пространтсво и файлы данных сразу, без очищения буфера. Это значит что файлы данных станут повреждёнными (не содержат подтверждённые изменения) и необходимо будет восстанавливать их состояние (путём чтения и применения лога изменений) перед тем как можно будет их включить. Этот режим стоит использовать только если файлы были повреждены и контрольная точка не может быть создана.
Режим TEMPORARY создаст контрольную точку для всех файлов для которых она может быть создана и затем по порядку выключит файлы и табличное пространство. Любые повреждённые файлы будут выключены сразу. Если только один некоторые файлы были повреждёны, этот режим поможет ограничить количество файлов которые надо восстанавливать.
Режим только-чтения (Read only)
Чтобы понять эффект режима только чтения изучите рисунок 5-9. Синтаксис команды говорит сам за себя
ALTER TABLESPACE tablespacename [READONLY|READ WRITE];
После перевода в режим только-чтения, объекты не могут быть созданы используя DML команды. Но они могут быть удалены. Выглядит нелогично но давайте подумаем. Удаление таблицы на самом деле не выполняет каких-либо действий над таблицей. Это транзакция над словарём данных, которая удаляет строки описывающие таблицу и её столбцы; словарь данных находится в табличном пространстве SYSTEM и оно не только для чтения. Создание таблицы в пространстве находящемся в режиме только для чтения также будет неуспешно, так как кроме DDL запроса должно выделиться физическое место для первого экстента таблицы (если не включен deferred segment creation. Если включен то место не будет выделяться и запрос выполниться успешно, однако при попытке добавить строки в созданную таблицу будет ошибка).
Изменение размера табличного пространста
Размер табличного пространства может быть изменён как добавлением файлов данных в него так и изменением размера существующих файлов. Файлы данных могут быть увеличены автоматически при необходимости если была указана опция AUTOEXTEND при создании. Иначе вам придётся делать это вручную используя команду ALTER DATABASE
ALTER DATABASE DATAFILE filename RESIZE n [M|G|T]
M G и T это мегабайт, гигабайт и терабайт соответсвенно.
alter dtabase datafile ‘/oradata/users_02.dbf’resize 10m;
Из команды вы не знаете станет ли файл больше или меньше. Размер может быть увеличен только если в файловой системе достаточно свободного места. Уменьшение размера возможно только если внутри файла сущесвует достаточно места не выделенного под сегменты.
Для того чтобы добавить новый файл в табличному пространству выполняется команда
ALTER TABLESPACE tablespacename ADD DATAFILE ‘filename’ SIZE 50m;
Параметр AUTOEXTEND можно указать при создании или включить позже выполнив команду
alter database datafile ‘filename’ autoextend on next 50m maxsize 2g;
Результатом выполнения команды будет автоматическое увеличение файла на 50 МБ до достижения максимального размера в 2 ГБ.
Изменение уровня предупреждений
Процесс MMON экземпляра практически в режиме реального времени наблюдает за свободным местом в табличных пространствах. Если табличное пространтсво заполняется до определённого уровня MMON создаёт предупреждение. Уровень по умолчанию для создания предупреждения – 85%, для создания критического предупреждения – 97%. Увидить эти предупреждения можно по разному, самый лёгкий способ — посмотреть на домашнуюю страницу Database Control.
Чтобы посмотреть или изменить эти значения в Database Control можно выбрать Tablespace на вкладкe Server и нажать EDIT. Затем в окне управления пространством перейти на вкладку Thresholds. На рисунке 5-10 показан пример для пространства EXAMPLE.
Рисунок 5-10 Окно управления предупреждениями
На этом рисунке “Available Space” указано как 32Гб. Что полностью неверно, так как выделенное место как видно на рисунке 5-3 всего 100МБ. Это происходит так как включен AUTOEXTENSION. Если AUTOEXTEND указан для файла и не установленм MAXSIZE, тогда файл может увеличиваться до платформо-зависимого ограничения, в нашем случае 32 ГБ. Конечно это не значит что у системы есть место для таких файлов. Система предупреждения рассчитыает лимиты и использует максимально допустимый размер файла как основу для вычисления, и это абсолютно быссмесленно если у вас включен AUTOEXTEND и не указан MAXSIZE.
Становится понятно что при использовании автоматического управления размером желательно указывать максимальное значение. Это можно сделать и Database Control или командой ALTER DATABASE.
Удаление табличных пространств
Для удаления табличного пространтсва используется команда
DROP TABLESPACE tablespacename [INCLUDING CONTENTS [AND DATAFILES]];
Если не указано INCLUDING CONTENS то удаление не выполнится если существуют объекты в табличном пространстве. Используя этот параметр вы указываете Oracle вначале удалить все объекты, а затем удалить табличное пространство. И даже эта команда может быть выполнена неуспешно если например в табличном пространстве создана таблица родитель для внешнего ключа таблицы созданной в другом табличном пространстве.
Если не указано AND DATAFILES тогда табличное пространство и его содержимое будет удалено однако файлы данных не будут удалены с диска. Oracle не будет знать ничего об этих файлах после удаления табличного пространства и файлы можно будет удалить только командами операционной системы.
Oracle Managed Files (OMF)
Использование OMF должно избавить DBA от необходимости знать что-либо о файловой системе. Создание файлов БД может быть полностью автоматическим. Для включения OMF необходимо установить параметры экземпляра
Параметр DB_CREATE_FILE_DEST определяет путь по умолчанию дял файлов данных. Параметры DB_CREATE_ONLINE_LOG_DEST_n указывают путь файла текщих логов. Параметр DB_RECOVERY_FILE_DEST определяет путь к файлам архивных логовов и резервных копий. OMF будет использовать эти пути и создавать файлы со сгенерированными именами и (по умолчанию) устанавливать размер файлов. При включенном OMF всё равно можно указать имя вручную при создании табличного пространства.