Если параметр инициализации PARALLEL_AUTOMATIC_TUNING выставлен в TRUE, буфер параллельных вычислений выделяется в большом пуле.

Общий объем разделяемого пула определяется параметром инициализации SHARED_POOL_SIZE.

Помимо этого, можно определять

Библиотечный кэш

Библиотечный кэш в общем случае включает в себя:

- разделяемые области SQL;

- PL/SQL процедуры и пакеты;

- Некоторые управляющие структуры (напр. блокировки).

Разделяемые области SQL доступны для всех пользователей. Каждое выполняемое SQL-выражение Oracle проводит через частную и приватную SQL области. Если несколько пользователей выполняют одно и то же выражение, то эти пользователи используют одну и ту же разделяемую область. Но, при этом каждый имеет копию этого же выражения в своей частной области.

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

Oracle выделяет память в разделяемом пуле, когда туда поступает новое, еще не разбиравшееся выражение. Происходит разбор, (подробнее см. главу «Выполнение SQL-выражений») и полученный план выполнения сохраняется в разделяемой SQL области библиотечного кэша. Если свободного места в разделяемом пуле нет, то происходит освобождение памяти путем очищения некоторых уже существующих разделяемых областей, к которым происходило на данный момент меньше всего обращений, согласно алгоритму LRU (least recently used), подобно тому, как это происходит в кэше данных. Если план выполнения некоторого SQL-выражения был вытеснен из библиотечного кэша, то для последующего его выполнения снова будет произведен разбор и формирование плана выполнения, который будет помещен в разделяемую область библиотечного кэша.

Модули, написанные на языке PL/SQL (процедуры, функции, анонимные блоки, пакеты и триггеры) обрабатываются подобно SQL-выражениям: происходит разбор, компиляция и в разделяемой области сохраняется этот модуль в разобранной и откомпилированной форме. При этом в частных областях пользовательских сессий сохраняются значения, специфические для каждой сессии (хотя эти сессии и выполняют один и тот же программный модуль): локальные, глобальные, пакетные переменные и др.

Кэш словаря данных

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

Доступ к словарю данных требуется настолько часто, что для ускорения работы с ним были задействованы две области: кэш словаря данных, (другое название – row cache), где хранятся строки из таблиц и представлений словаря данных, и часть библиотечного кэша, предназначенная для хранения данных словаря. Все пользовательские процессы имеют доступ к этим областям для получения необходимой информации из словаря данных.

Большой пул

АБД может настроить эту дополнительную область SGA, в которой может происходить выделение больших объемов памяти для:

- Памяти сессий для разделяемых серверов;

- Операций резервирования/восстановления (с использованием RMAN);

- Операций параллельного выполнения (только если параметр PARALLEL_AUTOMATIC_TUNING выставлен в TRUE).

В большом пуле кэширование производится не так, как в разделяемом пуле. Если в разделяемом пуле используется алгоритм LRU, то в большой пул устроен в виде т.н. «кучи» (heap), и данные, попадающие в него, не сохраняются для дальнейшего использования (подобно тому, как это происходит в пуле RECYCLE кэша данных).

Размер большого пула определяется параметром LARGE_POOL_SIZE.

Файлы

В состав БД входят следующие файлы:

- Файлы данных (связаны с табличными пространствами);

- Файлы (журналы) регистрации транзакции (или журналов повтора);

- Архивированные файлы журналов регистрации транзакций;

- Контрольные (управляющие) файлы;

- Файлы временных табличных пространств;

- Файлы паролей.

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

В контексте экземпляра БД также рассматривается файл параметров, необходимый для его корректного запуска. Более подробно см. главу «Файл параметров инициализации».

Для настройки сетевого взаимодействия также используются специальные файлы параметров: TNSNAMES.ORA, LISTENER.ORA, SQLNET.ORA и др. Более подробно см. главу «Работа в сети – Oracle Net».

Файлы данных

В БД Oracle в самом примитивном случае может существовать всего один файл данных (для табличного пространства SYSTEM). Он жизненно необходим БД. На деле файлов в производственной базе данных гораздо больше.

Каждый файл данных связан с каким-то табличным пространством БД и может быть использован для хранения различных объектов БД: таблиц, индексов, кластеров, материализованных представлений и т.д. Файл данных может принадлежать только одному табличному пространству. Более подробно см. главу «Иерархия хранения данных».

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

Первый файл данных БД – файл данных табличного пространства SYSTEM, и он обязательно создается при создании БД.

Когда создается файл данных, ассоциированный с определенным табличным пространством, он изначально пуст. Т.е. происходит резервирование места для будущего использования. Это место будет со временем заполняться данными БД.

В контексте Windows и файловой системы NTFS рекомендуется создавать файлы данных большого размера, с запасом (либо сразу создавать несколько файлов данных для табличного пространства). Это делается для того, чтобы максимально избежать фрагментации файлов данных при росте данных – они будут добавляться в зарезервированное место, что будет хорошо влиять на дисковую производительность. Более подробно см. главу «Настройка производительности – дисковая подсистема».

Файлы данных можно легко добавлять в режиме эксплуатации БД. Удаление файла данных – более сложная задача, если не удаляется все табличное пространство целиком. Также см. главу «Использование файлов под управлением Oracle».

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

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

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

Файлы (журналы) повторного выполнения (регистрации транзакций, редо-логи)

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

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

В каждой БД должны существовать, как минимум, 2 файла повторного выполнения, потому что они используются циклически.

Рис. Цикличность работы журналов повтора

Предположим, что в системе существует 3 журнала повторного выполнения. Сервер выполняет запись в журнал 1, а когда он заполняется целиком, происходит переключение на журнал 2, который точно также заполняется от начала до конца, и далее происходит переключение на журнал 3. Когда заполнится журнал 3, активным снова становится журнал 1. Переход от заполненного активного журнала к другому называется переключением журналов (switch logfile).

Когда происходит переключение на ранее заполненный журнал (например, после журнала 3 – на журнал 1), будет проведена дополнительная проверка с использованием контрольной точки на предмет того, остались ли в кэше данных «грязные» (dirty) (не сохраненные в файле данных) блоки, информация об изменении которых также хранится в журнале, который должен стать активным (в данном примере, в журнале 1). Если таких блоков нет, то журналы спокойно переключатся.

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

Архивные журналы регистрации транзакций (архивные журналы повтора, архив-логи)

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

Управляющие (контрольные) файлы

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

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

Файлы паролей

Используются, если был выбран соответствующий способ аутентификации пользователя-АБД. Подробнее см. главы «Способы аутентификации» и «Управление пользователями».

Физические процессы

Рассмотрим основные процессы, составляющие экземпляр Oracle. Их можно разделить на 2 группы:

- Серверные процессы;

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

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

Серверные процессы – «рабочие лошадки» СУБД Oracle 10g. Они выполняют основную работу по обработке и выполнению SQL-выражений сессий пользователей. Именно они проводят разбор и получение плана выполнения выражения, а потом, согласно полученному плану, считывают необходимые данные из кэша данных, выполняя сортировки, группировки, соединения и многое другое.

Серверные процессы разделяются на выделенные процессы и разделяемые. (Подробнее см. в этой главе «Режимы работы сервера» и главу «Настройка OSS».)

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

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

Некоторые фоновые процессы существуют в любой БД Oracle, а некоторые запускаются только в случае включение каких-то опций или функциональных особенностей.

SMON – системный монитор (System MONitor). Выполняет восстановление экземпляра после аварийного завершения работы, очищает временное табличное пространство от неактуальных сегментов сортировок, восстанавливает транзакции, затрагивавшие файлы, временно бывшие недоступными, пытается объединять свободные экстенты в более крупные в словарно управляемых табличных пространствах.

PMON – монитор процессов (Process MONitor). Выполняет восстановление пользовательских (и не только, например, процессов-диспетчеров также) процессов в случае их сбоя, если восстановление возможно. Отвечает за очистку областей памяти и освобождение других ресурсов по завершении работы процесса (снятие блокировок, откат транзакций и др.).

DBW n – процесс записи в файлы БД (DataBase Writer). n – означает порядковый номер, т.е. этих процессов может быть запущено несколько (число процессов по умолчанию зависит от аппаратных характеристик системы, в частности, от количества процессоров, возможно до 20). Этот процесс записывает модифицированные («грязные») блоки данных из кэша данных на диск, в файлы данных.

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

ARC n – процессы архивирования заполненных активных журналов регистрации транзакций. Требуют работы БД в режиме ARCHIVELOG.

CKPT – процесс, отвечающий за генерацию контрольных точек (check points), которые сигнализируют о том, что процессам DBWn нужно выполнить операции записи модифицированных блоков данных в файлы данных.

RECO – процесс восстановления распределенных транзакций, незавершенных по причине сбоя.

D nnn – процессы-диспетчеры, работающие в режиме OSS (более подробно см. главу «Настройка OSS»).

FMON – отвечает за поддержку распределения файлов БД в системе хранения (обычно в подсистемах RAID), обеспечивая поддержку т.н. Oracle's File Mapping Interface. Стартует при установке динамического параметра инициализации FILE_MAPPING в TRUE. Помимо этого, требует библиотек вендора-производителя подсистемы хранения, без которых в представлениях словаря данных с префиксом V$MAP_ (именно они отражают состояние распределения файлов) не будет содержаться никаких данных.

J nnn – процесс выполнения пакетных заданий по расписанию. Создаются и удаляются динамически. См. главу «Работа с заданиями».

CJQ0 – координатор выполнения пакетных заданий. Просматривает таблицу словаря JOB$ и запускает требующие запуска задания (создавая некоторый процесс Jnnn). Сбой в работе процесса Jnnn либо процесса СJQ0 не приводит к сбою экземпляра.

P nnn – процессы параллельного выполнения SQL-выражений. Создаются автоматически при выполнении ресурсоемких выражений, если в системе настроена поддержка параллельного выполнения. Часто называются подчиненными, ибо вызываются другими процессами. Более подробно см. главу «Параллельное выполнение».

S nnn – серверные процессы, выполняющие обработку запросов клиентских приложений в режиме OSS. Подобный процесс не связан с конкретной пользовательской сессией, но в процессе работы обслуживает запросы многих сессий. Распределением запросов занимаются процессы-диспетчеры.

Существует ряд дополнительных фоновых процессов, работающих в среде Real Application Clusters, (такие как LMON, LMD0, LMSn, LCK0).