Физические структуры базы данных Oracle: файлы данных, управляющие, журналы

Oracle Databases - файлы и структурыФизические структуры базы данных Oracle (Oracle Database) — это действительные файлы данных Oracle на уровне операционной системы. База данных Oracle состоит из следующих трех основных типов файлов.



В дополнение к этим трем типам файлов база данных Oracle использует несколько других системных файлов операционной системы для управления своими операциями. Сюда относятся инициализационные файлы (такие как init.ora и файл параметров сервера [SPFILE]), файлы сетевого администрирования (типа tnsnames.ora и listener.ora), файлы журналов предупреждений, файлы трассировки и файл паролей. Вдобавок также имеются файлы резервных копий, из которых выполняется восстановление базы в случае сбоя носителя.

 

Файлы данных Oracle

Файлы данных Oracle составляют самую большую часть физического хранилища вашей базы данных. Файл данных может принадлежать только одной базе данных, и один или более файлов данных составляют логическую сущность — табличное пространство,о которой мы говорили ранее в этой главе. Файлы данных Oracle составляют большую часть общего пространства базы данных.

Когда экземпляр базы данных нуждается в чтении данных таблицы или индекса,он читает их из файлов данных на диске, если только нужные данные уже не кэшированы в памяти Oracle. Аналогично база данных пишет новые данные таблиц или индексов либо обновляет существующие данные в файлах данных на диске постоянного хранилища.

Чтобы иметь возможность использовать диск для хранения ваших данных, каталоги и файловая система должна быть создана для вас системным администратором.Также понадобятся соответствующие права для чтения и записи в эти каталоги и файлы. Затем, когда вы создаете табличное пространство, то назначаете ему эти файлы данных. Прежде чем вы создадите базу данных, системный администратор выделит определенное дисковое пространство для базы на основе начальных оценок требуемого места. Все, что предоставляет администратор — это точки монтирования различных дисков (например, /prod01, /prod02, /prod03 и т.д.). Затем потребуется создать структуру каталогов под этими точками монтирования. После того, как вы инсталлируете необходимое программное обеспечение и создадите административные каталоги Oracle,можете использовать остальное пространство файловой системы для хранения объектов базы, таких как таблиц и индексов.

Управляемые Oracle файлы, которые были представлены в Oracle8i (и о которых речь пойдет ниже), упрощают администрирование баз данных Oracle. Средство Oracle Managed File (OMF) исключает необходимость в управлении файлами операционной системы. Вы просто специфицируете операции базы данных в терминах объектов базы данных, не используя имен файлов.

Средство OMF предназначено для облегчения DBA выполнения традиционных задач управления файлами. Когда вы используете средство OMF, вам не нужно заботиться об именах и местоположении физических файлов. Вместо этого вы можете сосредоточить свое внимание на объектах, которые создаете. Oracle при необходимости автоматически создаст и удалит файлы операционной системы.

Файлы на основе OMF идеальны для тестовых и небольших баз данных, но если вы имеете дело с базой данных терабайтного размера с огромным числом архивных журналов, то читайте мою следующую статью, которая научит создавать и управлять файлами на основе OMF.

Например, предположим, что вы создаете табличное пространство под названием customer01 с файлом данных в 500 Мбайт. По мере загрузки данных в вашу базу Oracle будет распределять новые экстенты для таблиц базы данных, выделяя место в файле данных. Когда таблица займет почти все начальное выделенное пространство в 500 Мбайт, понадобится увеличить табличное пространство, добавляя к нему новый файл данных. В качестве альтернативы можно также увеличить размер существующего файла данных. Если вы этого не сделаете, таблица не сможет увеличиться в размерах,и любые попытки добавить данные приведут к ошибке.

Хотя база помещает данные в существующие файлы данных, нет прямой связи между таблицами и индексами и файлами данных, в которые они помещаются. Эти объекты привязаны лишь к логическому табличному пространству, а табличное пространство,в свою очередь, привязано к файлам данных. Таким образом, Oracle поддерживает разделение между логическими объектами (такими как таблицы) и физическими файлами данных. Другими словами, при создании объекта нет прямой связи между объектом и файлами данных, в которых он размещается. Вы можете создавать или перемещать существующую таблицу или индекс, специально указывая табличное пространство, но вы не можете указать файл данных, куда их следует поместить.

 

Управляющий файл Oracle (control files)

Управляющий файл (control file) — это файл, который СУБД Oracle поддерживает для управления состоянием базы данных, и это, вероятно, наиболее важный файл в базе данных Oracle. Каждая база данных имеет один управляющий файл, но в связи с его важностью поддерживается несколько его идентичных копий (обычно три); когда база данных пишет в управляющий файл, все его копии обновляются. Управляющий файл критично важен для работы базы данных, и ее восстановление невозможно без доступа к свежему управляющему файлу. Oracle создает управляющий файл (и его копии) во время начального процесса создания базы данных.

Управляющий файл содержит имена и местоположения файлов данных, файлов журналов redo, текущие номера журнальных файлов, детали о множестве резервных копий и важнейший номер системного изменения ( system change number — SCN), который указывает наиболее свежую версию зафиксированных изменений в базе данных — информацию, которая недоступна пользователям даже для чтения. Только Oracle может писать информацию в управляющий файл, и сервер Oracle выполняет постоянное обновление управляющего файла во время работы базы данных.

Управляющие файлы жизненно важны для работы экземпляра Oracle. Когда вы запускаете экземпляр, Oracle читает в управляющем файле местоположения файлов данных и журналов. Во время нормальной работы базы данных она периодически заглядывает в управляющий файл за необходимой информацией почти о каждой структуре базы данных.

Управляющий файл также важен для проверки целостности базы данных и при ее восстановлении. Процесс контрольной точки инструктирует базу данных о необходимости записи данных на диск при наступлении определенного условия, а управляющий файл фиксирует всю информацию контрольной точки из онлайновых файлов журнала redo. Эта информация пригодится для восстановления: информация о контрольной точке из управляющего файла позволяет Oracle решить, насколько далеко ему следует вернуться при восстановлении данных из онлайновых файлов журнала redo. Контрольная точка указывает SCN, до которого была выполнена запись в файлы данных, так что процесс восстановления не будет зависеть от информации в онлайновых файлах журналов redo перед тем, как контрольная точка была помечена в управляющем файле.

Когда вы запускаете экземпляр Oracle, сначала он проверяет управляющий файл,чтобы идентифицировать все файлы данных и файлы журналов, которые должны быть открыты для операций с базой данных.

 

Ввиду его очевидной важности, Oracle рекомендует иметь несколько копий управляющего файла. Динамическое представление V$CONTROLFILE предоставит имена всех управляющих файлов. Столбец STATUS будет содержать NULL, если имя может быть определено.Если же имя не может быть определено (что вообще-то не должно случаться), вы увидите в столбце STATUS значение INVALID. Столбец IS_RECOVER_DEST_FILE содержит YES, если управляющий файл был создан в области пакетного восстановления, и NO — в противном случае. Ниже показан пример вывода запроса к представлению V$CONTROLFILE:

SQL> SELECT status, name, is_recovery_dest_file FROM V$CONTROLFILE;
STATUS                    NAME                    IS_RECOVERY_DEST
----------- ------------------------------------- ----------------
            C:\ORACLE\ORADATA\MARK1\CONTROL01.CTL         NO
            C:\ORACLE\ORADATA\MARK1\CONTROL02.CTL         NO
            C:\ORACLE\ORADATA\MARK1\CONTROL03.CTL         NO
SQL>
 

Файлы журналов повторного выполнения (redo log files)

Файлы журналов повторного выполнения (redo log files или фалы журнала повтора) записывают все изменения,проводимые в базе данных, и являются жизненно важными для восстановления базы данных. Если вы хотите восстановить базу данных из резервной копии, то последние изменения, проведенные в базе, можно восстановить именно из файлов журналов redo.Набор файлов журналов повторного выполнения, используемый в данный момент для записи изменений в базе данных, называется онлайновыми файлами журналов повторного выполнения. Эти журналы могут быть архивированы (скопированы) в другое место перед тем, как использоваться, и такие сохраненные журналы называются архивными журналами повторного выполнения (archived redo logs).

Oracle записывает все финальные изменения, проведенные в данных (зафиксированные данные) сначала в файлы журналов повторного выполнения, прежде чем провести эти изменения в самих файлах данных. Oracle использует журналы повторного выполнения для восстановления транзакций, которые были зафиксированы (commited),но которые не удалось провести в файлах данных. Таким образом, файлы журналов повторного выполнения гарантируют, что зафиксированные данные никогда не будут потеряны. Имея все архивные журналы повторного выполнения с момента последнего резервирования базы данных, а также полный набор текущих журналов повторного выполнения, всегда можно привести базу в актуальное состояние.


На заметку! Текущие файлы журналов повторного выполнения часто называют онлайновыми журналами повторного выполнения, чтобы отличать их от более старых журналов — сохраненных или архивных журналов повторного выполнения.


Файлы журналов повторного выполнения состоят из записей повторного выполнения (redo records), представляющих собой группы векторов изменений (change vectors),каждый из которых ссылается на определенное изменение, проведенное в блоке данных базы Oracle. Одна транзакция может включать множество изменений в блоках данных,поэтому они могут иметь более одной записи повторного выполнения. Изначально содержимое журнала хранится в области памяти, называемой буфером журнала повторного выполнения (redo log buffer), но оттуда оно очень быстро передается на диск. Если ваша база была остановлена без предупреждения, журнал повторного выполнения может помочь определить, все ли транзакции были зафиксированы перед аварией, или же некоторые остались незавершенными.

Файлы журналов повторного выполнения Oracle содержат следующую информацию об изменениях в базе данных, проведенных транзакциями:

  • индикаторы начала транзакции;
  • наименование транзакции;
  • имя объекта данных, который был обновлен (например, прикладной таблицы);
  • образ “перед” транзакцией (данные в том виде, который они имели до проведения изменений);
  • образ “после” транзакции (данные в том виде, который они имели после проведения изменений транзакцией);
  • индикаторы фиксации, указывающие на то, была ли завершена транзакция, и когда.

Когда база данных терпит крах, все транзакции, как зафиксированные, так и не зафиксированные, должны быть применены к данным на диске с использованием информации из файлов журналов повторного выполнения. Транзакции из журнала, которые имеют начало и фиксацию, должны быть повторно выполнены, а все транзакции,имеющие начало, но без фиксации — отменены. (Повторение, или “накат”, транзакции в этом контексте просто означает, что вы применяете информацию из файлов журналов повторного выполнения к базе данных. Вы не перезапускаете саму транзакцию.) Зафиксированные транзакции, таким образом, воссоздаются применением образов записей “после” из журналов повторного выполнения к базе данных, а незавершенные транзакции отменяются применением образов записей “перед” из табличного пространства undo. Файлы журналов повторного выполнения — важнейшая часть управления базой данных и главное средство поддержания ее целостности.

Oracle требует, чтобы каждая база данных имела, как минимум, две группы файлов журналов повторного выполнения, каждая из которых состоит из минимум одного индивидуального члена — файла журнала. Oracle пишет в один файл журнала повторного выполнения до тех пор, пока не достигнет его конца, после чего осуществляет переключение и начинает писать во второй файл журнала (а затем, в третий, если он есть).

По умолчанию Oracle будет писать поверх содержимого файла журнала повторного выполнения, если только вы не решите архивировать эти файлы журналов. Oracle рекомендует архивировать заполненные файлы журналов, чтобы иметь запись всех изменений, проведенных в базе данных с момента последнего резервного копирования.Если вы архивируете файлы журналов повторного выполнения, то считается, что вы запускаете базу данных в режиме archivelog. В противном случае вы работаете в режиме noarchivelog.

Ввиду крайней важности файлов журналов повторного выполнения для восстановления базы данных после сбоев, Oracle рекомендует мультиплексировать (multiplexing;поддержание нескольких копий) этих файлов журналов. Мультиплексирование файлов журналов повторного выполнения посредством помещения дух или более копий этих файлов на разные диски гарантирует, что вы не потеряете изменений данных, которые не были записаны в файлы данных.

 

Прочие файлы СУБД Oracle

Хотя база данных Oracle состоит из файлов данных, файлов журналов повторного выполнения наряду с управляющими файлами, есть также и некоторые другие файлы,необходимые для правильной работы базы. К этим файлам относится SPFILE, файл паролей, файл журналов предупреждений (alert log file), а также различные файлы трассировки и резервных копий. Эти файлы рассматриваются в следующих разделах.

 

Файл SPFILE

Когда вы создаете новую базу данных, то указываете параметры инициализации экземпляра Oracle в специальном конфигурационном файле, называемом файлом параметров сервера (server parameter file), или SPFILE. Вы можете также использовать более старую версию конфигурационного файла под названием init.ora, но Oracle рекомендует использовать более сложный файл SPFILE. В нем вы специфицируете ограничения памяти экземпляра, расположение управляющих файлов, наличие и расположение архивных файлов, а также прочие установки, регламентирующие поведение сервера баз данных Oracle. Однако вы не можете редактировать SPFILE вручную, как это допускается в отношении файла init.ora, поскольку SPIFILE является двоичным.

SPFILE всегда находится на сервере базы данных, и это предотвращает размножение файлов параметров, что иногда случается при использовании init.ora. По умолчанию SPFILEinit.ora) размещается в каталоге ORACLE_HOME/dbs систем UNIX и в каталоге ORACLE_HOME\database системы Windows. Каталог ORACLE_HOME является стандартным местоположением для исполняемых программ Oracle.

 

Oracle позволяет изменять ряд инициализационных параметров после запуска экземпляра; такие параметры называются динамическими параметрами инициализации.В отличие от традиционного файла инициализации init.ora, SPFILE может автоматически и динамически записывать новые значения динамических параметров после того, как вы измените их, гарантируя, что вы не забудете применить изменения. Вы не можете динамически изменить остальные параметры, называемые статическими параметрами инициализации. Для их изменения понадобится перезапустить экземпляр.

Вы можете использовать представление словаря данных V$SPPARAMETER для просмотра значений параметров инициализации, которые были явно установлены в SPFILE для вашей базы данных. (Аналогичным представлением для файла init.ora является V$PARAMETER.) В дополнение к значениям параметров, которые вы можете явно установить в SPFILE, представление V$SPPARAMETER показывает значения по умолчанию всех параметров конфигурации базы данных (значения, имеющие силу в экземпляре в данный момент).


Внимание! Иногда вы увидите ссылки на недокументированные или скрытые параметры Oracle. Эти параметры обычно имеют префикс — знак подчеркивания (_). Не используйте их, если только вам не порекомендуют это сделать эксперты из службы поддержки Oracle или какие-то другие достойные доверия источники.


 

Файл паролей (password)

Файл паролей (password) — необязательный файл, в котором вы можете специфицировать имена пользователей базы данных, которым выданы специальные административные привилегии SYSTEM и SYSOPER, что позволяет им выполнять привилегированные операции, такие как запуск, останов, резервное копирование и восстановление баз данных. В главе 12 будет показано, как создавать и сопровождать файл паролей.

 

Файл журнала предупреждений (alert log)

Каждая база данных Oracle имеет журнал предупреждений (alert log) под названием alertdb_name.log (где db_name — имя базы данных). Этот журнал фиксирует основные изменения и события, происходящие во время работы экземпляра Oracle, включая переключения журналов повторного выполнения, любые связанные с Oracle ошибки, предупреждения и прочие сообщения. Вдобавок всякий раз при запуске экземпляра Oracle выводит в журнал предупреждений список параметров инициализации вместе с полной последовательностью процесса запуска. Вы можете также использовать журнал предупреждений для автоматического отслеживания создаваемых табличных пространств, а также добавления и изменения размеров файлов данных.

Журнал предупреждений может пригодиться для поиска причин неполадок. Обычно это первое место, которое следует проверить, чтобы получить представление о том, что случилось внутри базы данных при возникновении проблемы. Фактически, служба поддержки Oracle может попросить вас скопировать соответствующие разделы журнала предупреждений для анализа проблем, возникших в базе данных.

В Oracle Database 11g рекомендуемая процедура состоит в создании диагностического репозитория, называемого Automatic Diagnostic Repository (ADR), который представляет собой общее место для хранения всех ошибок, связанных с базой данных, файлов трассировки и файлов дампов. Если вы установите ADR, указав новый инициализационный параметр DIAGNOSTIC_DEST, то Oracle создаст и будет поддерживать два файла журналов предупреждений, один в текстовом формате, а другой — в формате XML.В противном случае Oracle поместит журнал предупреждений в место, указанное в параметре инициализации BACKGROUND_DUMP_DEST. Если вы не укажете значение этого параметра, Oracle поместит журнал предупреждений в место по умолчанию.

Чтобы увидеть, есть ли ошибки, связанные с Oracle в вашем журнале предупреждений, введите следующую команду (здесь finance — имя базы данных):

$ grep ORA- alert_finance.log
ORA-1503 signalled during: CREATE CONTROLFILE SET DATABASE "FINANCE" RESETLOGS...
ORA-1109 signalled during: ALTER DATABASE CLOSE NORMAL...
ORA-00600: internal error code, arguments:[12333], [0], [0], [0], [], [], [], [] 

Как видите, в журнале предупреждений базы данных finance перечислено несколько ошибок Oracle. Регулярное сканирование базы данных на предмет ошибок Oracle должно стать одной из ежедневных задач по сопровождению базы данных. Вы можете легко запланировать автоматический запуск сценария для сканирования журнала предупреждений с последующей отправкой результатов по электронной почте. Вы можете так-же использовать интерфейс Oracle Enterprise Manager (OEM) Database Control (или Grid Control) для быстрого просмотра ошибок в ваших файлах журналов предупреждений.

 

Файлы трассировки (alert)

Все диагностические файлы, включая файлы трассировки, хранятся в каталоге,который вы указываете в инициализационном параметре DIAGNOSTIC_DEST. Каталог trace в домашнем каталоге ADR содержит различные файлы трассировки, такие как отладочные файлы трассировки для фоновых процессов (писателя журналов, писателя базы данных и т.п.), которые Oracle пишет во время операций экземпляра. В каталоге alert внутри домашнего каталога ADR хранятся файлы журналов предупреждений экземпляра (о котором было сказано в предыдущем разделе).

Центральный каталог внутри домашнего каталога ADR содержит все центральные файлы, сгенерированные во время возникновения основных ошибок, таких как внутренние ошибки программного обеспечения Oracle ORA-600.

Сервер Oracle будет писать все отладочные трассировочные файлы пользовательских процессов в каталог trace. Все трассировочные файлы, которые вы сгенерируете с использованием средств SQL трассировки Oracle, будут помещены туда.

 

Файлы резервных копий Oracle

Вы можете использовать резервные файлы, созданные либо вами самостоятельно, либо инструментом резервирования и восстановления RMAN для восстановления базы данных после сбоев оборудования или ошибок пользователя. Сбой носителя может повлечь за собой ошибочное удаление файлов базы данных или повреждение файла с данными. Независимо от причин, файлы резервных копий помогут вам восстановить базу данных на момент сбоя с помощью архивных файлов журналов повторного выполнения.


Важно! Объект каталога Oracle — это псевдоним каталога файловой системы. Вы применяете объекты каталогов в основном при использовании внешних средств таблиц. Объекты каталогов обеспечивают гибкость сопровождения, позволяя ссылаться на каталоги операционной системы через имя объекта базы данных. Каталоги не принадлежат ни одной конкретной схеме. Вы должны выдавать пользователям привилегии доступа к определенному каталогу, прежде чем они смогут к ним обращаться.


 

Вас заинтересует / Intresting for you:

Создание базы данных Oracle
Создание базы данных Oracle 18709 просмотров Александров Попков Wed, 14 Nov 2018, 12:44:39
Oracle и непроцедурный доступ ...
Oracle и непроцедурный доступ ... 7382 просмотров Antoni Tue, 21 Nov 2017, 13:32:50
Видеокурс по администрированию...
Видеокурс по администрированию... 10461 просмотров Илья Дергунов Mon, 14 May 2018, 05:08:47
Поддерживаемые Oracle типы дан...
Поддерживаемые Oracle типы дан... 5653 просмотров Валерий Павлюков Wed, 24 Oct 2018, 08:00:37
Войдите чтобы комментировать

Vovan_ST аватар
Vovan_ST ответил в теме #9152 02 сен 2018 09:03
Отличное описание управляющих и журнальных файлов Оракл. И вообще про структуру файлов СУБД Oracle все объяснено четко!