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

Подчиненные процессы ввода/вывода используются в нескольких компонентах Oracle 8i - процессы DBWn и LGWR используют их для имитации асинхронного ввода/вывода, а утилита RMAN (Recovery MANager - диспетчер восстановления) использует их при записи на ленту.

Использование подчиненных процессов ввода/вывода управляется двумя параметрами инициализации.

BACKUP TAPE IO SLAVES. Этот параметр указывает, используются ли подчиненные процессы вода/вывода утилитой RMAN для резервного копирования или восстановления данных с ленты. Поскольку этот параметр предназначен для ленточных устройств, а к ленточным устройствам в кажд1й момент времени может обращаться только один процесс, он - булева типа, а не задает количество используемых подчиненных процессов, как можно было ожидать. Утилита RMAN запускает необходимое количество подчиненных процессов, в соответствии с количеством используем1х физических устройств. Если параметр BACKUP TAPE IO SLAVES имеет значение TRUE, то для записи или чтения с ленточного устройства используется подчиненный процесс ввода/вывода. Если этот параметр имеет (стандартное) значение FALSE, подчиненные процессы ввода/вывода не используются при резервном копировании. К ленточному устройству тогда обращается фоновый процесс, выполняющий резервное копирование.

DBWn IO SLAVES. Задает количество подчиненных процессов ввода/вывода, используемых процессом DBWn. Процесс DBWn и его подчиненные процессы всегда записывают на диск измененные буфера буферного кэша. По умолчанию этот параметр имеет значение 0, и подчиненные процессы ввода/вывода не используются.

Подчиненные процессы параллельных запросов

В Oracle 7.1 появились средства распараллеливания запросов к базе данных. Речь идет о возможности создавать для SQL-операторов типа SELECT, CREATE TABLE, CREATE INDEX, UPDATE и т.д. план выполнения, состоящий из нескольких планов, которые можно выполнять одновременно. Результаты выполнения этих планов объединяются. Это позволяет выполнить операцию за меньшее время, чем при последовательном выполнении. Например, если имеется большая таблица, разбросанная по десяти различным файлам данных, 16-процессорный сервер, и необходимо выполнить к этой таблице запрос, имеет смысл разбить план выполнения этого запроса на 16 небольших частей и полностью использовать возможности сервера. Это принципиально отличается от использования одного процесса для последовательного чтения и обработки всех данных.

134 Глава 2

Резюме

Вот и все компоненты СУБД Oracle. Мы рассмотрели файлы, используемые в СУБД Oracle: небольшой, но важный файл параметров инициализации init.ora, файлы данных, файлы журнала повторного выполнения и т.д. Мы изучили структуры памяти, используемые экземпляром Oracle как в серверных процессах, так и в области SGA. Было показано, как различные конфигурации сервера, например подключение в режиме MTS и к выделенному серверу, принципиально влияют на использование памяти в системе. Наконец, мы рассмотрели процессы (или потоки - в зависимости от базовой ОС), обеспечивающие выполнение функций сервера Oracle. Теперь мы готовы к рассмотрению других возможностей сервера Oracle - управления блокированием и одновременным доступом, и поддержки транзакций.

Блокирование и одновременный доступ

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

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