База данных Oracle db: работа в составе информационных систем

Ядром каждой информационной системы является база данных, в которой хранятся настройки системы, данные, вводимые персоналом организации, и результаты обработки данных. В составе информационной системы Oracle EBS работает система управления базами данных Oracle db. Рассмотрим, как функционирует эта СУБД.

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

После запуска СУБД Oracle на компьютере начинает работать экземпляр Oracle — комплекс структур памяти и процессов операционной системы, позволяющий эффективно работать с базой данных Oracle. Он состоит из глобальной системной области (ГСО) и фоновых процессов, функционирующих в оперативной памяти компьютера (рис. 6.1).

Рис. 6.1. Экземпляр Oracle.

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

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

ГСО состоит из следующих компонентов:

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

В кэше библиотеки хранятся текст операторов SQL, форматы лексического анализатора, план выполнения операторов SQL, заголовки процедур и пакетов PL/SQL, которые ранее исполнялись. После поступления на выполнение процедуры система сначала производит поиск заголовка этой процедуры в кэше библиотеки. Если такая процедура или пакет PL/SQL находится, то используется соответствующее дерево лексического анализа и лексический анализатор не запускается. Тем самым экономится время, затрачиваемое на выполнение процедур. При этом система чувствительна к регистру символов в заголовках процедур и пакетов.

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

Кэш словаря хранит строки словаря данных, которые использовались для лексического анализа.

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

Все данные в кэш-буфере упорядочиваются в списке LRU (Least recently used — использованные наиболее давно) в зависимости от частоты обращения к ним. Данные, которые часто используются, помещаются в ту часть списка LRU, которая называется MRU (Most recently used — использованные недавно).

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

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

Модифицированные блоки данных называются грязными {duty) и помещаются в соответствующий dirty-список. В этом списке отслеживаются все данные, которые были изменены за время нахождения в кэш-буфере, но при этом не записаны на диск. Как только программа изменила данные, они сразу помечаются как грязные и помещаются в dirty-список. Одновременно в журнале транзакций делается соответствующая запись.

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

Все данные о завершившихся транзакциях хранятся в буфере журнала транзакций до тех пор, пока эти данные не будут переписаны в файл оперативного журнала транзакций с помощью процесса LGWR. Как уже говорилось, сведения из журнала транзакций используются для восстановления базы данных в случае ее повреждения. Буфер журнала транзакций — обычный циклический буфер. После его заполнения вся информация переписывается на диск в оперативный журнал транзакций, буфер освобождается. Если размер буфера невелик, то процесс очень часто будет переписывать информацию из него в файл и тем самым замедлять работу системы. Такая ситуация возможна при большой интенсивности работы с БД. Задача администратора — найти оптимальный размер буфера.

В Oracle используют такое понятие, как «защелка» {latch) — это блокировка некоторой структуры в памяти процессом: процесс Oracle блокирует посторонние обращения к блоку памяти, выделенной для буфера журнала транзакций. «Защелка» работает также как блокировка файла или строки таблицы. Если процесс наложил «защелку» на буфер, то обратиться к нему будет можно только после ее снятия. Процедура блокирования блоков памяти используется для того, чтобы гарантировать последовательный характер записи в буфер журнала транзакций.

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

Существуют следующие фоновые процессы:

• • SMON, PMON — управление процессами и восстановление экземпляра при открытии БД;
• • DBWR — запись на диск измененных блоков данных;
• • LGWR — запись на диск в файлы оперативного журнала транзакций данных из буфера журнала транзакций;
• • ARCH — архивирование файлов оперативного журнала транзакций;
• • СКРТ — обработка контрольных точек;
• • RECO — восстановление работоспособности распределенной БД;
• • SPNn — обновление снимков;
• • LCKn — управление параллельными подключениями к экземпляру;
• • Рппп — обслуживание параллельных запросов;
• • Dnnn — фоновые процессы диспетчера.

Четыре процесса: SMON, PMON, DBWR, LGWR — являются обязательными, без них экземпляр Oracle работать не будет. Остальные процессы запускают при необходимости. Рассмотрим каждый из них подробнее.

Процесс PMON — Process Monitor (мониторинг процессов) — отвечает за очистку после всех некорректно завершенных подключений (например, сетевого сбоя или неожиданного отключения компьютера пользователя), удаление сеанса, закрепленного за прекратившимся процессом, снятие блокировок, которые были им установлены, и откат незафиксированных транзакций. Процесс освобождает ресурсы ГСО (SGA), выделенные прекратившему работу процессу. Он отслеживает работу других фоновых процессов сервера и диспетчера и при необходимости автоматически перезапускает их в случае останова.

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

Процесс DBWR — Database Block Writer (запись блоков данных) — отвечает за перенос измененных блоков данных (которые системой занесены в dirty-список) из кэш-буфера данных в ГСО (SGA) в файлы данных на диске. Система не записывает на диск данные сразу после внесения изменений, а ожидает выполнения одного из следующих условий:

• • количество элементов, занесенных в dirty-список, достигло заданной величины;
• • количество использованных буферов в кэш-буфере данных достигло заданной величины;
• • истекло время ожидания, по умолчанию 3 сек;
• • обнаружена контрольная точка.

После наступления одного из перечисленных событий процесс DBWR просматривает dirty-список и переписывает на диск все занесенные в него блоки. Такой способ записи позволяет уменьшить влияние скоростных характеристик жестких дисков на производительность системы, что способствует ее повышению.

Обычно DBWR использует асинхронный ввод-вывод. Процесс собирает блоки данных и передает их операционной системе для записи на диск. Далее он, не дожидаясь ответа операционной системы, собирает следующий пакет для записи. ОС после завершения записи передает процессу уведомление. Это позволяет значительно выиграть время.

Процесс LGWR — Log Writer (запись журнала транзакций) — отвечает за перезапись информации из буфера журнала транзакций в ГСО в файлы оперативного журнала транзакций на диске. Он выполняет запись при выполнении одного из условий:

• • истекло время ожидания, по умолчанию 3 сек;
• • производится фиксация транзакции;
• • буфер журнала транзакций заполнился на треть;
• • обнаружена контрольная точка.

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

Процесс ARCH — Archiver (архиватор) — копирует полностью заполненные процессом LGWR файлы оперативного журнала транзакций в архивные файлы журнала транзакций. Для запуска процесса ARCH требуется, чтобы система работала в режиме архивирования журнала транзакций. Во время копирования оперативного журнала в архив доступ к журналу блокируется, и система переходит в состояние ожидания. Архивные файлы журнала транзакций обычно используют для восстановления базы данных при повреждении диска.

Процесс СКРТ — Check Point (контрольная точка) — способствует формированию контрольных точек. Контрольная точка — момент, в который процессы LGWR и DBWR одновременно производят запись данных на диск. Период времени для формирования контрольных точек задается в настройках.

Процесс RECO — Recovery (восстановление) — отвечает за восстановление завершенных транзакций в распределенной системе. Если БД сконфигурирована как распределенная, то процесс запускается автоматически. В случае сбоя сети или возникновения какой-то другой ошибки транзакция становится сомнительной распределенной. После восстановления соединения дальнейшую обработку сомнительной транзакции выполняет процесс RECO. Он пытается связаться с базой данных, в которой сформирована эта транзакция, чтобы узнать ее исход, — до этого она остается незафиксированной. По результатам ответа процесс RECO восстановит либо откатит ее.

Процесс SNPn — Snapshot Process (процесс обработки снимков) — выполняет автоматические обновления снимков БД и запускает процедуры в соответствии с расписанием. В настройках задается количество запускаемых процессов и расписание выполнения задания (интервал времени, через который процесс «просыпается» и начинает работать).

Процесс LCKn — Parallel Server Lock (блокировка) — запускается в среде, в которой параллельно работают несколько экземпляров. Он координирует блокировки устанавливаемые разными экземплярами БД. Если в системе нет параллельного обслуживания, то запуск LCKn не требуется.

Процесс Pnnn — Parallel Query (процессы параллельных запросов) — обеспечивает параллельные запросы к БД. Количество запущенных процессов зависит от активности работы с базой данных. Pnnn принимает участие в формировании индексов, таблиц и запросов.