Хранение данных отмены операций

Сегменты отмены операций могут существовать только в особых табличных пространствах, которые называются табличными пространствами отмены операций. (В табличном сегменте отмены операций невозможно создать сегмент другого типа, например таблицу.) Процесс установки автоматически создает файл SMALLFILE для табличного пространства отмены операций. Также для табличного пространства отмены операций можно создать BIGFILE. Однако в многотомной среде оперативной обработки транзакций (OLTP) с множеством коротких параллельных транзакций может возникнуть конкуренция за доступ к заголовку файла. Табличное пространство отмены операций, хранимое в нескольких файлах данных, может устранить данную проблему. Несмотря на то, что база данных может хранить много табличных пространств отмены операций, только одно из них может быть назначено текущим табличным пространством отмены операций для экземпляра базы данных. Сегменты отмены операций создаются автоматически и всегда принадлежат SYS. Так как сегменты отмены операций действуют как циклический буфер, каждый сегмент состоит как минимум из двух экстентов. Максимальное количество экстентов по умолчанию зависит от размера блока базы данных, но при этом оно достаточно велико (32765 для размера блока 8 Кбайт).

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

Рис.6. Архитектура процессов

Процессы в системе баз данных можно разделить на две основные группы:

• пользовательские процессы, выполняющие код приложения или инструмента

• процессы базы данных, выполняющие код сервера баз данных (включая серверные и фоновые процессы)

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

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

• Выделенный сервер: для каждого пользователя приложение базы данных запускается

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

• Разделяемый сервер: устраняет необходимость в выделенном серверном процессе для каждого подключения. Диспетчер направляет множество входящих сетевых запросов на установку сеансов пулу процессов разделяемого сервера. Любой запрос клиента обслуживается процессом разделяемого сервера.

Рис.7 Серверные процессы

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

Серверные процессы, созданные по запросу приложений каждого пользователя, могут выполнять одну или несколько функций:

• выполнять синтаксический разбор и обрабатывать SQL-операторы, переданные через приложение

• считывать нужные блоки данных из файлов данных на диске в разделяемые буферы базы данных SGA (если блоки еще не присутствуют в SGA)

• возвращать результаты в такой форме, в которой приложение сможет обрабатывать данные

Фоновые процессы

Чтобы максимально повысить производительность и обслуживать множество пользователей,

многопроцессная система баз данных использует некоторые дополнительные процессы базы данных, которые называются фоновыми процессами. Экземпляр базы данных может иметь множество фоновых процессов. Фоновые процессы обычно происходят в средах, отличных от RAC и ASM. К фоновым процессам относятся:

• Процесс записи в базу данных (Database writer – DBWn)

• Процесс записи в журнал (Log writer – LGWR)

• Процесс создания контрольной точки (Checkpoint – CKPT)

• Процесс системного монитора (System Monitor – SMON)

• Процесс монитора процессов (Process monitor – PMON)

• Процесс восстановления (Recoverer – RECO)

• Процессы обработки очереди заданий

• Процессы архивации (Archiver – ARCn)

• Процессы монитора очередей (Queue monitor – QMNn)

В более сложных конфигурациях, таких как RAC, можно встретить и другие фоновые процессы. Для получения дополнительных сведений о фоновых процессах см. представление V$BGPROCESS. Во многих операционных системах фоновые процессы создаются автоматически при запуске экземпляра.

Процесс записи в базу данных (DBWn) записывает содержимое буферов в файлы данных. Процессы DBWn осуществляют запись измененных (заполненных) буферов из буферного кэша базы данных на диск. Хотя одного процесса записи в базу данных (DBW0) достаточно для большинства систем, можно настроить дополнительные процессы (DBW1 – DBW9 и DBWa – DBWj), чтобы повысить производительность записи на случай интенсивного

изменения данных в системе. Дополнительные процессы DBWn бесполезны в однопроцессорных системах.

Рис.8. Процесс записи в базу данных (DBWn)

Если буфер в буферном кэше базы данных изменяется, он помечается как заполненный и добавляется в список LRUW (LRU-запись) заполненных буферов, отсортированный по номеру SCN. Таким образом, порядок буферов совпадает с порядком операций повтора, записанных в журналы повторов для таких измененных буферов. Когда количество доступных буферов в буферном кэше становится меньше внутреннего порогового значения (при котором серверным процессам становится тяжело получать доступные буферы), DBWn записывает заполненные буферы в файлы данных в порядке их изменения, следуя порядку в списке LRUW.

SGA содержит структуру памяти, в которой находится журнальный байтовый адрес (RBA) позиции в потоке повторов, с которой следует начать восстановление в случае отказа экземпляра. Данная структура служит указателем на повтор и записывается в контрольный файл процессом CKPT один раз в три секунды. Поскольку процесс DBWn записывает заполненные буферы в порядке следования SCN, а журнал также формируется по порядку номеров SCN, то каждый раз, когда процесс DBWn записывает заполненные буферы из списка LRUW, он также перемещает указатель в структуре памяти SGA. Таким образом, при восстановлении экземпляра (если это необходимо) чтение начинается с приблизительно правильного размещения, что позволяет избежать лишних операций ввода-вывода. Это называется инкрементной установкой контрольных точек.

Рис.9. Процесс системного монитора

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

Процесс SMON регулярно проверяет необходимость выполнения этого процесса. Процесс SMON также может быть вызван другими процессами, выявившими в этом необходимость.

Рис.10. Процесс монитора процессов

Процесс монитора процессов (PMON) выполняет восстановление пользовательского процесса в случае сбоя. Процесс PMON осуществляет очистку буферного кэша базы данных и

освобождает ресурсы, использовавшиеся данным пользовательским процессом. Например, он сбрасывает состояние таблицы активных транзакций, снимает блокировки и удаляет идентификатор процесса из списка активных процессов.

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

Рис.11. Архитектура хранения БД

Файлы, из которых состоит база данных, делятся на следующие категории:

• Управляющие файлы: содержат данные о самой базе данных (то есть информацию о физической структуре базы данных). Это критически важные файлы для базы данных. Без них невозможно открыть файлы данных и получить доступ к БД.

• Файлы данных: содержат данные пользователя или приложения базы данных, а также метаданные и словарь данных.

• Оперативные файлы журнала повторов: используются для восстановления экземпляра БД. Если происходит сбой сервера БД, при котором не теряются файлы данных, экземпляр позволит восстановить базу данных с помощью информации, содержащейся в этих файлах.

Для надежного функционирования БД также важны следующие файлы:

• Файл параметров: используется для определения конфигурации экземпляра для запуска.

• Файл паролей: позволяет удаленно подключаться к БД пользователям sysdba, sysoper

и sysasm для выполнения задач администрирования.

• Резервные копии файлов: используются для восстановления БД. Обычно при сбое носителя или ошибке пользователя, вследствие которых был поврежден или удален исходный файл, для его восстановления используется резервная копия.

• Архивные файлы журнала повторов: содержат непрерывную историю изменений данных (повторных операций), которую создает экземпляр. С помощью этих файлов и резервной копии БД можно восстановить утраченные файлы данных. Таким образом, архивные журналы позволяют восстанавливать файлы данных.

• Файлы трассировки: любой серверный или фоновый процесс может выполнять запись в определенный файл трассировки. При обнаружении процессом внутренней ошибки он записывает дамп информации об ошибке в свой файл трассировки. Часть информации в файле трассировки предназначена для администратора БД, другая информация – для службы поддержки.

• Файлы журнала предупреждений: представляют собой особые записи трассировки.

Журнал предупреждений БД – это хронологический журнал сообщений и ошибок. Каждый экземпляр использует один файл журнала предупреждений.

Рис.12. База данных состоит из физических и логических структур.