Что такое сегмент oracle
Управление пространством (доступным «местом») осуществляется на нескольких уровнях. Вначале место выделяется для табличного пространства (путём изменения размеров файлов данных). Затем пространство внутри табличного пространства выделяется для сегментов (путём выделения экстентов). И наконец пространство внутри сегментов выделяется для строк. Это происходит путём управления битовыми масками (bitmaps) которые отслеживают сколько свободного места в каждом блоке.
Логические структуры БД
Физические структуры БД есть ни что иное как системные файлы. Пользователи видят логические структуры, такие как таблица. Oracle использует термин segment для описания любой структуры, которая содержит данные. Типичный сегмент – это таблица, состоящая из строк данных, однако существует ещё более 12 возможных типов используемых в Oracle. Нас интересуют таблицы, индексы и UNDO сегменты. Таблица содержат собственно данные, индексы используются для быстрого доступа к конкретным данным, UNDO сегменты используются для хранения временной информации, изменений которые могут быть отменены.
Oracle позволяет абстрагировать физичесую структуру от логической путём ввода понятия табличное пространство (tablespace). Tablespace – логически это коллекция одного или несколько сегментов, а физически коллекция одного или нескольких файлов данных. В терминах реляционной алгебры – мы видим отношение многие-ко-многим между сегментами и файлами данных: одна таблица может находиться в разных файлах даных, и, с другой стороы, в одном файле данных может находиться много таблиц. Путём добавления понятия «табличное пространство» — Oracle управляет этими отношениями.
Несколько сегментов создаются во время создания БД: это сегменты которые составляют словарь данных. Эти сегменты хранятся в двух табличных пространствах SYSTEM и SYSAUX. SYSAUX появилось только после версии 10g: в прошлых весь словарь данных хранился в табличном пространстве SYSTEM. Процесс создания обязательно создаст минимум два табличных пространства с минимум одним файлом данных в каждом, для хранения словаря данных.
Сегмент состоит из блоков. Файлы данных также отформатированных с использованием блоков и блоки из файла данных назначаются к сегментам по мере роста последних. Управление дисковым пространством по одному блоку – было бы сильно затратным занятием, поэтому блоки группируются в extent-ы. Extent – это группа последовательных блоков в файле данных, и размер сегментов будет увеличиваться на размер extent-а. Extent-ы для одного сегмента не обязательно должны быть рядом в файле и вообще даже могут находиться в разных файлах, но файлы должны прнадлежать табличному пространству этого сегмента.
Рисунок 1-8 отображает отношения структур Oracle с отделением логических структур от физической. Табличное пространство может содержать множество сегментов, каждый из которых состоит из extent-ов. Extent – это набор блоков Oracle. Файл данных состоит из блоков операционной системы. Как итог табличное пространство состоит из множества файлов данных и блок Oracle состоит из одного или нескольких блоков операционной системы.
Управление отменой
Когда вы проводите изменения в базе данных, вы должны иметь возможность отменить или откатить это изменение при необходимости. Информация, необходимая для отмены или отката изменений транзакции, которая в основном состоит из информации таблицы, предшествующей изменению, называется данными отмены (векторами изменений) и хранится в записях отмены (undo records). При выдаче команды ROLLBACK Oracle использует эти записи отмены для замены измененных данных их исходными версиями. Записи отмены жизненно важны для восстановления базы данных, когда незавершенные или незафиксированные транзакции должны быть отменены, чтобы оставить базу в согласованном состоянии.
Oracle настоятельно рекомендует использовать средство автоматического управления изменениями (Automatic Undo Management - AUM), при котором сам сервер oracle будет поддерживать и управлять сегментами отмены (отката). Все, что вам нужно сделать – это предоставить выделенное табличное пространство undo и установить параметр инициализации UNDO_MANAGEMENT в auto. Oracle создаст необходимое количество сегментов отмены, которые структурно подобны традиционным сегментам отката, и будет расширять их по мере необходимости. Нет ничего необычного в том, что будут создаваться новые сегменты отмен, а старые – деативизироваться в зависимости от количества транзакций, проводимых в базе данных.
Поскольку Oracle самостоятельно управляет размерами индивидуальных сегментов отмены, два решения, которые вы должны принять, касаются размера табличного пространства undo и установки инициализационного параметра UNDO_RETINTION (который определяет, насколько долго Oracle будет стараться хранить для вас записи об отмене в табличном пространстве undo). Помните, что ваше табличное пространство undo должно не только вместить все долговременные транзакции, но так же быть достаточно большим, чтобы позволить работать всем средства ретроспективы (flashback), которые вы можете реализовать в вашей базе данных; средства ретроспективы Oracle позволяют отменять изменение данных на различных уровнях. Некоторые из них, такие как Flashback Query, Flashback Versions Query и Flashback Table используют данные отмены.
Вы можете использовать Undo Advisor Oracle через OEM для нахождения идеального размера табличных пространств undo и идеальной длительности, чтобы специфицировать параметр UNDO_RETENTION. Посредством статистики текущего использования пространства отмены можно оценить оптимальные параметры генерации данных отмены для вашего экземпляра.
Блоки данных (Data Block) - мельчайший строительный блок базы данных Oracle, состоящий из определенного количества байт на диске. Блок данных Oracle - логический компонент базы данных. Диски на которых располагаются блоки Oracle, сами делятся на блоки данных. Обычно блоки данных диска соответствуют блокам данных Oracle. Размер блока базы данных Oracle устанавливается параметром DB_BLOCK_SIZE в файле init.ora. Размер блока следует воспринимать, как минимальную единицу обновления, выбора или вставки данных. Общепринятый размер блока - 8 KByte. Если выбрать размер блока 64 KByte, то даже при извлечении имени длиной в четыре символа, придется прочесть весь блок размером 64 KByte, в котором содержатся интересующие четыре буквы.
Все блоки данных можно разделить на две основные части: часть строк данных и часть свободного пространства.
Файлы логов / Online redo log files
Redo log – это набор хрогологически упорядоченных записей, об изменениях в БД. Это минимально необходимое количество информации, которая необходима чтобы восстановить все действия, которые совершались над БД. Если файлы данных пропали или удалены, эти записи изменений могут быть использованы чтобы повторить все действия с определенной точки времени до момента возникновения ошибки над резервной копией файлов данных. Этот лог может состоять из двух типов файлов: online redo log файлы (необходимые файлы для работы БД) и archive log файл-ы (которые не обязательны для работы, но необхоидмы для восстановления данных к точке времени).
У любой БД есть минимум два online redo log файла, но как и в случае с controlfile-ом, хороший DBA создаёт копии каждого файла. Online redo log состоит из групп файлов, каждый файл в которой называется member. У БД Oracle должно быть минимум две группы, состоящие минимум из одного member для работы. Вы можете создать больше чем две группы для улучшения производительности, и больше чем один member для сохранности данных. Две группы минимум нужны для того, чтобы в одну писать текущие изменения, а другую можно было в это время использовать для создания архивной копии.
Одна из групп в момент времени является текущей (current group) – в неё LGWR будет записывать изменения из буфера логов. В момент времени когда файлы группы заполнятся – LGWR совершит так называемую операцию log switch. Вторая группа становится текущей и LGWR начинает писать данные в файлы второй группы, и, если у вас настроен archive log mod, ARCn сделает резервные копии файлов первой группы. Когда вторая группа заполнится, LGWR опять сделает текущей первую группу а ARCn сделает резеврную копию второй группы. Таким образом группы redo log работают по кругу и каждая операция log switch создаёт файл архивного лога.
Так же как и для controlfile, если у вас настроено несколько файлов в группе (желательно иметь несколько копий!) не нужно никаких дополнительных настроек для их синхронизации и т.п. LGWR сам запишет во все копии в параллели одинаковую информацию. Если к примеру какая-либо копия на каком либо диске оказалась недоступна – до тех пор пока есть хотя бы одна копия – БД может нормально функционировать.
Размер и количество груп – задача оптимизации БД. В общем, необходимо выбирать значения в зависимтости от активности работы с БД. Минимальный размер – пятьдесят мегабайт, но активно используемые БД с большим количество пользователей могут использовать файлы размером до нескольких гигабайт. Количество копий файлов в группе – вопрос какой уровень отказоустойчивости вы хотите достигнуть. В любом случае – задание этих параметров не критично на этапе создание БД, так как они могут изменять в режиме «онлайн» — без перезагрузки экземпляра БД.
Писатель базы данных и протокол опережающей записи
Писатель базы данных, как вы видели ранее, отвечает за запись в файлы данных всех модифицированных буферов из буферного кэша базы данных. Кроме того, он следует за наличием свободного пространства в буферном кэше, чтобы серверный процесс мог читать новые данные из файлов данных при необходимости. Протокол опережающей записи (журнала) также требует, чтобы записи повторного выполнения в буфере журнала повторного выполнения, ассоциированные с измененной информацией в буферном кэше, были записаны в буфер журнала повторного выполнения перед тем, как они отразятся в файлах данных. Важность содержимого журнала повторного выполнения диктует Oracle обязательность записи содержимого файла журнала повторного выполнения в постоянное хранилище перед тем, как изменения данных будут проведены в фалах данных на диске.
Когда пользователь фиксирует транзакцию, процесс-писатель журнала немедленно вносит в файлы журналов повторного выполнения запись о фиксации. Полный набор записей, затронутых зафиксированной транзакцией, может и не записываться одновременно в в файлы данных. Механизм быстрой фиксации, наряду с журналом опережающей записи, гарантирует, что базада нных не будет ждать завершения всех физических операций записи после каждой транзакции. Как вы можете себе представить, огромные базы данных OLTP с многочисленными изменениями на протяжении всего дня не могли бы функционировать оптимально, если бы им пришлось выполнять запись на диск после каждого зафиксированного изменения данных.
При наличии огромного числа транзакций и, как следствие, огромного количества запросов на фиксацию, процесс-писатель журнала может и не вносить немедленно запись о каждой зафиксированной транзакции в журнал повторного выполнения. Он может накапливать по нескольку запросов на фиксацию, если очень занят в данный момент. Такая пакетированная запись информации о множестве зафиксированных транзакций называется групповой фиксацией.
Управление экстентами
Метод управления экстентами устанавливается для табличного пространства и применяется для вссех сегментов этого табличного пространства. Существует два метода управления: управление с помощью словаря (dictionary management) или локальное управление (local management). Разница предельно проста: всегда надо использовать local management; dictionary management никогда не надо использовать. Dictionary management пока ещё поддерживается, и только. Это ограничение для поддержки предыдущих версий Oracle.
Dictionary management использует две таблицы в словаре данных. SYS.UET$ содержит строки описывающие использованные экстенты и SYS.FET$ хранит информацию о свободных экстентах. Каждый раз когда БД необходимо добавить экстент к таблице, необходимо прочитать FET$ таблицу чтобы найти свободный экстент и затем выполнить DML команды к таблицам FET$ и UET$ так как экстент становится не свободным. Этот механизм существенно снижает производительность, так как все операции по управлению пространством в БД (они могут инициироваться параллельно) должны выполняться согласно механизму управления транзакциями.
Локальный механизм был введён начиная с версии 8i и стал значением по умолчанию начиная с версии 9i. Он использует битовую маску которая хранится в каждом файле данных. Каждый бит управляет определённым набором блоков и когда место выделяется, значение соответсвующего бита устанавливается в единицу. Такой механизм гораздо более эффективен чем dictionary management. Время на выделение экстентов распределено между битовыми масками каждого файла, и битовые маски разных файлов могут обновляться параллельно, в отличие от использования двух общих таблиц. Битовая маска хранится в шапке файла данных (размер header по умолчанию = 64 Кб до 11g и 1 Мб после 11g. Надо добавлять размер шапки когда вы считаете размер файла).
Когда вы создаёте табличное пространство с механизмом локального управленяи, важным параметром является uniform size (равномерный размер). Если указывается эта опция, каждый экстент выделяемый в этом табличном пространтсве будет фиксированного размера.Это позволяет управлять пространством ещё более эффективно, так как количество блоков управляемых каждым битом в маске будет больше: один бит для экстента. Рассмотрим пример
create tablespace large_tabs datafile ‘large_tabs_01.dbf’ size 10g extent management local uniform size 160m;
Каждый экстент выделяемый в этом табличном пространстве будет размером 160 МБ, т.е. во всего будет около 64 экстентов. Битовой маске нужно всего 64 бита и 160 МБ можно выделить обновив всего один бит. Это может быть очень эффективно – если сегменты в этом табличном пространстве будут большими. Если будет создан сегмент которому надо место всего для нескольких строк – все равно будет выделен экстент в 160 МБ. Маленьким объектам лучше создавать отдельно таблично пространство
create tablespace small_tabs datafile ‘small_tabs_01.dbf’ size 1g extent management local uniform size 160k;
Альтернативой этой команде (и командой по умолчанию) будет команда
create tablespace any_tabs datafile ‘any_tabs_01.dbf’ size 10g extent management local autoallocate;
Когда сегмент будет создаваться в этом табличном пространстве, Oracle выделит экстент размером в 64Кб. Когда сегмент будет расти и требовать больше места, Oracle будет выделять экстенты по 64Кб до тех пор, пока их число не станет 16, а затем размер выделяемых экстентов будет постепенно увеличиваться.
Если база данных была обновлена, возможно что будут табличные пространства с dictionary-management управлением. Вы можете проверить это выполнив запрос
select tablespace_name, extent_management from dba_tablespaces
Любые dictionary-management табличные пространства могут быть сконвертированы в локально управляемые с помощью PL/SQL программы, которую можно вызвать
Экстенты (extent)
Экстенты (extent) - это два или более последовательных блоков данных Oracle, представляющий собой единицу выделения места на диске. Когда комбинируется несколько непрерывных блоков данных, они называются экстентом. Когда вы создаете объект базы данных вроде таблицы или индекса, вы выделяете им некоторый начальный объем пространства, называемый начальным экстентом, и, кроме того, указываете размер следующего экстента. Однажды размещенные в таблице или индексе, экстенты остаются выделенными конкретному объекту, пока вы не удалите этот объект из базы данных - тогда пространство, занимаемое им, вернется в пул свободного пространства базы данных.
Физические структуры БД
Существуют три основных типа файлов из которых состоит БД Oracle, плюс дополнительные файлы которые хранятся отдельно от БД и грубо говоря не необходимы. Необходимые файлы это файл управления (controlfile), файл логов (online redo log files) и файлы данных. Дополнительные файлы которые обычно присутствуют (существуют ещё другие для дополнительной настройки) это файл параметров инициализации, файл паролей, архив логов и т.п.
Сегменты, экстенты, блоки и строки
Данные хранятся в сегментах. Представление словаря данных DBA_SEGMENTS хранит инфомрацию обо всех сегментах в базе данных. Запрос ниже отображает все типы сегментов в простой БД
Рассмотрим эти сегменты:
- Таблица (Table) — это структура которая хранит строки данных. Несмотря на то что наиболее часто встречающийся сегмент это таблица, никогда нельзя путать таблицу и сегмент, и что существуют гораздо более сложеные в организации таблицы которые используют другой тип сегмента
- Индекс (Index) это сортированный список ключей-значений, каждая из которых зранит указатель ROWID на физическое расположение строки. ROWID определяет в каком блоке Orace какого файла данных находится строка, и номер строки внутри блока.
- TYPE2 UNDO Это сегменты undo которые хранят данные перед изменениями для обеспечения транзакционной целостности: отмены транзакий, целостности чтения данных и обеспечения изоляции
- ROLLBACK сегменты rollback не должны использоваться в нормальном режиме работы начиная с версии 9i. Начиная с версии 9i используется автоматическое управление отмены операций основанное на сегментах TYPE2 UNDO (или просто undo). Всегда будет существовать один rollback сегмент для поддержки транзакций в момент создания БД (так как в момент создания ещё не существуют undo сегменты) но он не должен использоваться после создания БД
- Партиция таблицы( TABLE PARTITION) Таблица может быть разбита на несколько партиций. Если это настроено, то каждая партиция будет отдельным сегментом, а сама партицированная таблица не будет сегментом: она будет существовать как итог всех партиций. Каждая партиция будет таблицей, отдельным сегментом. Так как каждый сегмент может быть в отдельном табличном пространстве, то появляется возможность разбить таблицу между несколькими табличными пространствами
- Партиция индекса (INDEX PARTITION) по умолчанию индекс это один сегмента, но индексы как и таблицы могут быть партицированы. Если вы партицируете таблицу, обычно необходимо также партицировать и индекс
- Сегменты больших объектов (LOBSEGMENT, LOBINDEX, LOB PARTITION) Если столбец объявлен с типом large object, тогда в таблице хранится только указатель на запись в отдельном сегменте где хранятся данные этого столбца. Большие объекты могут быть индексированы для более быстрого доступа к данным внутри объекта и партицированы
- Кластер (CLUSTER) это сегмент которых содержит несколько таблиц. В отличие от партицирования которое позволяет распределять таблицы между разными сегментами, кластеризация позволяет собрать много таблиц в один сегмент
- Вложенные таблицы (NESTED TABLE) Если столбец внутри таблицы объявлен как определяемый пользователем объект (user defined object) который в свою очередь содержит столбцы, то такие столбцы хранятся в одельном сегмента, как вложенная таблица.
Каждый сегмент состоит из одного или более экстентов. Когда сегмент создаётся, 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 предоставляет полностью независимое определение логических и физических структур данных. Логическим элементом данных является сегмент. Существуют различные виды сегментов; типичным примером является таблица. Сегменты физически хранятся в файлах данных. Разделение физического и логического представления данных осуществляется путём ввода понятия tablespace. Связь физических и логических представлений хранится в словаре данных.
Файлы данных / Datafiles
Третий тип необходимых файлов для работы это файлы данных. Как минимум требуется два файла, которые создаются в момент созданий БД. До версии 10g – можно было создать базу с одним файло – после создаются два файла, по одному для табличного пространства SYSTEM и SYSAUX. Как бы то ни было, в рабочей базе будет больше файлов.
Файлы данных – это хранилище для данных. Их размер и количество неограниченны. Маленькие БД размером в несколько гигабайт могут состоять из пол-дюжины файлов, каждый размером в несколько сот магабайт. Большие БД могут состоять из тысяч файлов, размер которых ограничен только возможностями ОС и аппаратным обеспечением.
Файлы данных с физической точки зрения – это системные файлы, которые видят системные администраторы. Логическая же структура файлов данных, это хранилище сегментов (segments) в которых хранятся пользовательские данных и логическая структура доступна программистам, а также сегментов словаря данных. Сегмент – это структура хранения для данных; типичные сегменты это таблицы и индексы. Файлы данных могут быть переиенованы, перемещены, удалены, добавлены в любое время жизни БД. Но важно помнить что некоторые операции требуют перезапуска экземпляра БД.
С точки зрения ОС, файлы данных состоят из набора блоков операционной системы. Внутри файлов, они отформатированы на Oracle блоки (blocks). Эти блоки последовательно пронумерованы внутри каждого файла. Размер блока фиксирован и в большинстве случаев будет одинаковым для всей БД. Выбор размера блока задача для оптимизации. Допустимы значения от 2КБ до 64КБ. Нет взаимосвязи между размерами системных блоков и блоков Oracle.
Многие DBA используют одинаковый размер системного блока и Oracle блока. С точки зрения производительности системный блок не должен быть больше чем блок Oracle. Однако ничто не мешает системному блоку быть меньше чем блоку Oracle. К примеру системный блок в 1Кб и блок Oracle размеров в 8КБ вполне допустимая конфигурация.
Внутри блока находтся заголовок, область данных и возможно неиспользуемое место. Заголовок содержит информацию такую как: каталог строк, в котором перечислено расположение строк в области данных (если блок используется как часть таблицы), информация о блокировках строк, если данные используются в транзакциях. В области данных хранятся сами данные, такие как строки если блок является частью таблицы, или ключи индекса, если блок – часть индекса.
Когда пользовательскйо сессии необходимо работать с данными из блока, серверный процесс находит блок с нужными данными на диске и копирует этот блок в свободный буфер в database buffer cache. Если затем данные изменяются – в какой-то момент времени DBWn запишет этот блок обратно на диск.
Желательно регулярно делать копии файлов данных. В отличие от controlfile и redo log файлов, Oracle не поррерживает копии файлов данных (хотя вы можете построить RAID массив или использовать другие аппаратные возможности и возможности операционной системы). Если файлы данных повреждаются, они могут быть восстановлены из архивной копии и затем recovered (recovered — означает что к копии файлов данных будут применены изменения из redo log).
Системный номер изменения
Системный номер изменения, или SCN (system change number) – важный оценочный фактор, используемый базой данных Oracle для отслеживания состояния в каждый данный момент времени. Когда вы читаете (SELECT) данные в таблицах, то не затрагиваете состояния базы данных, но когда модифицируете, вставляете или удаляете строку, то состояние базы данных по отношению к тому, каким оно было до операции. Oracle использует SCN для слежения за всеми изменениями, проведенными в базе данных со временем. SCN – это логическая временная метка, используемая Oracle для упорядочивания событий, происходящих с базой данных. SCN очень важен по нескольким причинам, не последняя из которых – восстановление базы данных после сбоя.
SCN подобны возрастающим номерам последовательности, и Oracle сначала увеличивает их в SGA. Когда транзакция модифицирует или вставляет данные, Oracle сначала пишет новый SCN в сегмент отката. Процесс-писатель журналов затем немедленно вносит запись о фиксации транзакции в журнал повторного выполнения, и эта запись получает уникальный SCN в сегмент отката. Процесс-писатель журналов, затем немедленно вносит запись о фиксации транзакции в журнал повторного выполнения, и эта запись получает уникальный SCN новой транзакции. Фактически запись этого SCN в журнал повторного выполнения отмечает зафиксированную транзакцию в базе данных Oracle.
SCN помогает Oracle определять необходимость восстановления после сбоя, после внезапного прерывания работы экземпляра базы данных или после издания команды SHUTDONW ABORT. Всякий раз, когда база данных выполняет операцию контрольной точки, Oracle пишет команду START SCN в заголовки файлов данных. Управляющий файл поддерживает значение SCN для каждого файла данных, называемый STOP SCN, который обычно устанавливается в бесконечность, и всякий раз, когда экземпляр останавливается нормально (командой SHUTDOWN NORMAL или SHUTDOWN IMMEDIATE). Oracle копирует номер START SCN в заголовках файлов данных в номера STOP SCN ля файлов данных в управляющем файле. Когда вы перезапускаете базу данных после успешного останова, нет необходимости ни в каком восстановлении, потому что номера SCN в файлах данных и управляющих файлах соответствуют. С другой стороны, внезапное прерывание работы экземпляра не оставляет времени на приведение в соответствие номеров SCN, и Oracle обнаруживает необходимость восстановления экземпляра, потому что отличаются номера SCN в файлах данных с одной стороны, и управляющем файле - с другой. Они играют ключевую роль в восстановлении базы данных. Oracle определяет, на сколько нужно вернуться, применяя архивные журналы повторного выполнения во время восстановления на основе SCN.
Файл контроля / Controlfile
Разберёмся с терминологией: кто-то говорит что у БД может быть несколько controlfile-ов, а другие утверждают что файл один, который может иметь несколько копий. Мы придержимся последнего определения, так как согласно Oracle “multiplexing control files” означает именно возможность иметь копии.
Controlfile – файл небольшого объёма, но он жизненно важный. Внутри содержатся указатели для всей БД: место online redo log-а, файлов данных, критически важную системную информацию для обеспечения целостности ( значение sequence и timestamp). Размер файла обычно не превышает несколько мегабайт но БД не существует без этого файла.
У каждой БД есь один controlfile, но хороший DBA всегда будет создавать копии файла, чтобы в случае проблем с какой либо копией всегда можно было быстро восстановить систему. Если все копии утеряны, то теоретичеески можно попробовать восстановить базу, но лучше никогда не попадать в такую ситуацию. Oracle сервер сам синхронизирует controlfile-ы – задача DBA решить сколько копий необходимо и где их хранить.
Если вы в момент создания базы данных не указали количество или путь – это можно изменить после, но потребует включения выключения БД, так что лучше планировать заранее. Нету определенного значения сколько копий делать, минимум – один файл, максимум – восемь. Проблемы с любой копией controlfile приводят к немедленной остановке экземпляра БД.
Сегменты (segments)
Сегменты (segments) - набор экстентов, которые вы выделяете логической структуре, такой как таблица или индекс (или некоторый другой объект). Набор экстентов формирует следующую более крупную единицу хранения, именуемую сегментом. Oracle называет сегментом все пространство, выделенное любому конкретному объекту базы данных. Поэтому если у вас есть таблица по имени Customer, вы просто ссылаетесь на пространство, выделенное для нее, как на “сегмент Customer”. Когда вы создаете индекс, он получает свой собственный сегмент, названные его именем. Сегменты данных и индексов - наиболее распространенный тип сегментов Oracle. Есть также временные сегменты, которые база данных использует в транзакциях, включающих сортировку, а также сегменты отката, которые база использует для хранения информации отката. Когда все экстенты сегмента заполнены, Oracle автоматически выделяет дополнительные экстенты при необходимости и эти сегменты могут быть непрерывными.
Мы рассмотрели процесс взаимодействия экземпляра и сессий: процессы и структуры памяти. В этой главе мы будем рассмотривать саму БД. Все процессы обработки информации происходят в памяти экземпляра БД, но хранение данных происходит в файлах базы данных на диске. База данных состоит из трех типов файлов: файл контроля, файлы логов и файлов даных. Данные хранятся в файлах данных.
Пользователи никогда не видят физический файл данных. Они видят логические сегменты. Системные администраторы ничего не знают о логических сегментах – они видят файлы. В базе данных Oracle физическая структура абстрагирована от логической. Это одно из требования парадигмы реляционных баз данных. Как DBA вы должны знать связь между логической и физической структурой БД. Мониторинг и администрирование этих структур – задача часто называемая как управление пространством (space management) является большой частью работы DBA. Средства предусмотренные в последних версиях БД могут автоматизировать задачу управления пространством в определенной степени, и они безусловно позволяют DBA настроить хранилище таким образом, чтобы максимально облегчить задачу обслуживания сервера.
Данные логически хранятся в сегментах (обычно таблицах), физически в файлах данных. Табличное пространтсво абстрагирует эти два понятия: в одном табличном пространтсве может храниться несколько сегментов и состоять из нескольких файлов данных. Нету прямой взаимосвязи между сегментом и файлом данных. Файлы данных могуть быть как файлами в файловой системе или (начиная с версии 10g) устройствами Automatic Storage Management (ASM).
Управление пространством сегмента
Метод управления пространством для сегмента устанавливается для табличного пространства и применяется ко всем сегментам в таблично пространстве. Существует два метода: manual и automatic. Автоматическое управление надо всегда использовать, а ручное – всего лишь ограничение для поддержки старых версий.
Автоматический метод был введён в версии 9i и стал значением по умолчанию начиная с версии 11g. Каждый сегмент создаваемый в автоматически управляемом табличном пространстве имеет набор битовых масок описывающих насколько заполнены блоки в нём. Всего хранится 5 битовых масок для каждого сегмента, и каждый блок существует только в одной битовой маске. В битмапах хранится информация о использованном пространстве по группам: битмап для полностью заполненных блоков, блоков где заполнено от 75% до 100%, от 50 до 75%, от 25 до 50 и от 0 до 25%. Когда нужен блок для записи сроки, серверный процесс сессии смотрит на размер строки, чтобы определить в какой битовой маске искать блок. Например если размер блока 4КБ и строка для вставки 1500 байт, то соответствующий блок необходимо искать в группе блоков где заполнено от 25 до 50%. Каждый блок в этой группе гарантированно имеет 2КБ свободного места. Когда строки доабвляются, удаляются или изменяются – битовые маски тоже обновляются.
Старый ручной способ управления использовал обычный список, известный как free list, в котором хранился список блоков доступных для записи, но без какой-либо информации о том сколько места свободно. Такой метод не оптимален так как необходимо проверять каждый блок хватает ли места и место распределяется непропорционально (может появиться много неиспользованного места). Для проверки метода управления можно выполнить запрос
select tablespace_name,segment_space_management from dba_tablespaces;
Невозможно изменить метод для управления пространством сегментов, но можно создать новое таблично пространство с автоматическим методом, перенсти туда все сегменты и удалить старое табличное пространство.
До сих пор вы знакомились с компонентами системы базы данных Oracle: необходимыми файлами и распределением памяти, а также способами их настройки. Теперь пришло время посмотреть, как Oracle обрабатывает пользовательские запросы и как проводит изменение в данных. Важно понимать механизм обработки транзакций SQL, потому что все взаимодействие с базой данных Oracle происходит либо в форме запросов SQL, которые читают данные, либо операций SQL (или PL/SQL), которые модифицируют, вставляют или удаляют данные.
Транзакция – это логическая единица работы в базе данных Oracle, состоящая из одного или более операторов SQL. Транзакция начинается с первого исполняемого опертартора SQL и завершается, когда вы фиксируетет или отказываете транзакцию. Фиксация (commiting) транзакции закрепляет проведенные вами изменения, а откат (roll back) – конечно же, отменяет их. Как только вы зафиксировали транзакцию, все прочие транзакции других пользователей, которые начались после нее, смогут видеть изменения, проведенные вашими транзакциями.
Когда транзакция вообще не может выполниться (скажем, из-за отключения электропитания), то она вся целиком должна быть отменена. Oracle откатывает все изменения, проведенные предшествующими операторами SQL, возвращая данные в исходное состояние (которое они имели перед началом транзакции). Весь процесс построен так, чтобы поддерживать целостность данных – т.е. концепцию «все или ничего».
Следующий простой пример вставки строки описывает то, как Oracle обрабатывает транзакцию.
Словарь данных
Словарь данных хранит метаданные описывающие логическую и физическую структуру БД и её содержимое. Информация о пользователях, пароли, ограничения целостности и (начиная с 10g) информация о производительности – всё это хранится в словаре данных. Эти данные хранятся в виде набора сегментов в табличных пространствах SYSTEM и SYSAUX.
В целом, сегменты составляющие словарь данных такие же как и остальные сегменты – обычные таблицы и индексы. Главное отличие – эти сегменты создаются в момент создания БД и нет прямого доступа к информации в них. Конечно ничто не может остановить DBA от прямого доступа в словарь данных – однако их любое изменение может привести к разрушению БД.
Управление словарём данных осуществляется командами DML. Когда вы выполняете команду CREATE TABLE – на самом деле осуществляется вставка строк в таблицы словаря данных. Точно такое же механизм работы у команд CREATE USER и GRANT и т.д.
Для просмотра словаря данных Oracle предоставляет определённый набор представлений (view). Большинство из них начинаются с префикса DBA_, ALL_ или USER_. Все представления начинающиеся с USER_ будут отображать объекты БД принадлежащие текущему пользователю. Если пользователь JOHN будет простматривать представление USER_TABLES он увидит только те таблица, которые принадлежат ему. Таким образом никогда два пользователя не увидят одинаковой информации. Представления начинающиеся с ALL_ отображают информацию об объектах к которым у текущего пользователя есть доступ – то есть все объекты которые во создали плюс объекты к которым есть соответсвующее разрешение. Представления с префиксом DBA_ отображают информацию о всех объектах БД. Если вы просмотрите DBA_TABLES – то увидите строку для каждой таблицы, не важно кто создал её. Эти представления создаются в момент создания БД, а также генерируется большое количество PL/SQL пакетов. Эти пакеты предоставляются Oracle в помощь администраторам и разработчикам. PL/SQL код также хранится в словаре данных.
Свзяь табличных пространств и файл данных управляется controlfile-ом. Внутри перечислены все файлы данных и информация частю какого табличного пространства они являются. Без файла контроля БД не сможет найти файлы данных и определить какие из них хранят данные табличного пространства SYSTEM. Только после того как табличное пространство SYSTEM найдено и доступно для чтения информации – становится возможным чтение информации из словаря данных, что позволяет открыть БД.
SQL команды всегда ссылаются на объекты определённые в словаре данных. Чтобы выполнить простой запрос в таблицу, сервер Oracle вначале должен проверить в словаре данных существует ли такая таблица и какие столбцы в ней. Затем найти файлы где физически хранятся данные, т.е. прочитать список какие extent-ы хранят данные этого сегмента. В этом списке хранится информация в какой файле данных хранится каждый extent, с какого блока файла данных extent начинается и как много блоков входит.
Фиксация и откат
Вы должны четно понимать два фундаментальных термина, касающихся транзакций: фиксаций (commiting) и откат (rolling back) транзакций. Ниже кратко объясняются оба термина.
Фиксация транзакции
Когда вы фиксируете транзакцию, скажем, посредством оператора COMMIT, Oracle делает все имзееения, выполненные всеми операторами SQL, в рамках этой транзакции, постоянной частью базы данных. Прежде, чем Oracle зафиксирует результаты транзакции, он делает следующее.
- Генерирует информацию отмены (undo), которая состоит из значений данных, подлежащих модификации, до изменений. Эти данные сохранятся в сегменте undo, расположенном в табличном пространстве undo.
- Он также генерирует данные повторного выполнения (redo), содержащие изменения в блоках данных и в блоках отката, в буфер журнала повторного выполнения. База данных может писать на диск содержимое буферов журнала повторного выполнения перед фиксацией транзакций.
- Проводит изменения в буферах базы данных, находящихся в SGA. База данных может писать модифицированные буферы на диск перед фиксацией транзакции.
База данных может писать изменения транзакции, которые были выполнены первыми, из буферов базы данных в SGA в файлы данных немедленно или же спустя какое-то время после фиксации транзакции, либо даже перед ее фиксацией. Когда баз данных фиксирует транзакцию, она выполняет следующее.
- База данных назначает и записывает SCN для фиксируемой транзакции.
- Писатель журналов пишет элементы журнала повторного выполнения в файл журнала повторного выполнеяия на диске из буфера журнала повторного выполнения в SGA: он также записывает SCN транзакции в файл журнала повторного выполнения, помечая тем официальную фиксацию транзакции.
- База данных освобождает все блокировки таблиц и строк.
- База данных помечает транзакцию как завершенную.
Откат транзакции
Отменить изменения, выполненные транзакцией, которые еще не были зафиксированы можно с помощью команды ROLLBACK. В то время как журнал повторного выполнения содержит все изменения, проведенные в транзакции, сегмент отмены (undo) содержит все старые значения, которые существовали до момента проведения изменений. Вы можете либо откатить изменения, проведенные всей транзакцией, либо просто вернуться к маркеру, который поместили ранее внутри транзакции, называемому точкой сохранения (savepoint). Существует несколько типов отката, среди которых перечислены ниже:
- Откат , запрошенный пользователем.
- Откат, произошедший из-за ненормального прерывания работы процесса или экземпляра.
- Откат незафиксированных транзакций во время восстановления.
- Откат уровня оператора, произошедший из-за ошибки выполнения этого оператора.
Независимо от причины отката, процедура всегда одна и та же.
- База данных использует данные в виде, который они имели до изменения в табличном пространстве undo, чтобы отменить все изменения, проведенные во время транзакции.
- База данных освобождает все блокировки транзакции и таблицы.
- База данных завершает транзакцию
Модель хранения данных 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.
Целостность данных и параллелизм данных
База данных была бы не слишком полезной, если бы множество пользователей не могли обращаться к данным и модифицировать их одновременно. Под параллелизмом данных (a concurrency) понимают способность базы данных обеспечивать параллельный доступ для множества пользователей. Чтобы обеспечить согласованные результаты, база данных нуждается в механизме, который гарантирует, что пользователи не будут натыкаться на изменения, проводимые друг другом. Целостность данных (data consistence) - это возможность для пользователя получать согласованное представление данных, включая все изменения, проведенные в них другими пользователями.
Для обеспечения целостности данных, Oracle использует специальные структуры, именуемые сегментами отмены (undo segments). Например, когда вы читаете набор данных для транзакции, Oracle обеспечивает, чтобы прочитанные данные были согласованы по набору транзакций т.е. гарантирует, что данные, которые вы видите, отражают один набор зафиксированных транзакций. Oracle также обеспечивает согласованность данных по чтению, что означает, что все данные, выбранные вашими запросами, относятся к одному моменту времени. Сегменты отмены Oracle – это часть табличного пространства undo, упомянутого ранее в этой главе.
Oracle использует механизм блокировок для обеспечения параллелизма данных. Позволяя одному пользователю блокировать индивидуальные строки или целые таблицы, он гарантирует ему исключительное использование таблицы в целях обновления. Важной характеристикой механизмов блокировки Oracle является то, что они по большей части происходят автоматически. Вам не нужно беспокоиться о деталях блокировки объектов, которые вы хотите модифицировать – Oracle «за кулисами» позаботится об этом.
Oracle использует две базовые модели блокировок. Модель исключительной блокировки применяется для обновлений, а модель разделяемой блокировки используется для операции SELECT на таблицах. Модель разделяемой блокировки позволяет нескольким пользователям одновременно читать один и те же строки таблицы. Модель исключительной блокировки, поскольку включает обновление таблицы, может использоваться только одним пользователем в любой заданный момент времени. Исключительные блокировки почти всегда применяются к определенным строкам, подлежащим обновлению, позволяя одновременно использовать базы данных множеству пользователей. После выполнения команды COMMIT или ROLLBACK Oracle автоматически освобождает блокировки на таблицах и прочие важные ресурсы.
Блокировки Oracle сложны, и вы детально познакомитесь с ними в главе 8, вместе с тем, как Oracle обеспечивает согласованность и параллелизм данных.
Читайте также: