Система Oracle: структура и процессы

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

На рис. 1. показаны структура файлов данных базы, состоящая из двух типов файлов. Файлы с данными, хранящие «настоящие» данные, и файлы журнала повтора (redo log files, часто их называют просто файлами журнала), хранящие непрерывный поток всех изменений, производимых в файлах данных.

 Схема процессов в базе данных Oracle

Рис. 1. Схема процесса Oracle, содержащая «только самое необходимое»

Файлы с данными поддерживают произвольный доступ, а для большей эффективности, каждому из них назначается размер единицы ввода/вывода – размер блока который может быть равен 2 Кбайта, 4 Кбайта, 8 Кбайт (наиболее типичное значение по умолчанию), 16 Кбайт или (на некоторых платформах) 32 Кбайта. Файлы с данными могут объединяться в логические объекты, которые называют табличными пространствами (tablespace). Табличное пространство можно рассматривать, как естественную «крупномасштабную» единицу базы данных – простые объекты данных связываются с табличными пространствами, а не с файлами данных.

Существует три основных типа табличных пространств, лежащих в основе системы Oracle Database: табличные пространства отмены (undo tablespaces), временные табличные пространства (temporary tablespaces) и «все остальное».

Временные табличные пространства появилось в версии базы данных Oracle 8, а табличные пространства отмены – в Oracle 9. До этого (начиная с версии 6, когда вообще появились табличные пространства) все табличные пространства были одинаковыми. Среди «всех остальных» имеется несколько табличных пространств, считающихся специальными (даже при том, что они интерпретируются так же, как другие табличные пространства): системное табличное пространство system и вспомогательное системное табличное пространство sysaux, которые не должны использоваться для хранения пользовательских данных.

Табличное пространство sysaux появилось в версии Oracle 10g и служит для хранения наиболее динамических и потенциально объемных данных, сгенерированных внутренними механизмами управления и обслуживания. Табличное пространство system служит для хранения словаря данных (data dictionary) – метаинформации, описывающей базу данных.

Файлы журналов поддерживают последовательный ввод/вывод, и для них назначается минимальный размер блока, обычно 512 байт, для записи. Некоторые файлы журналов называются оперативными файлами журналов повтора (online redo log files) и находятся в постоянном использовании. Остальные называются архивными файлами журналов повтора (archived redo log files) и являются простыми копиями оперативных файлов журналов, которые создаются по мере их заполнения.

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

Когда программное обеспечение выполняется под управлением ОС UNIX (и во многих других ОС), в памяти создается несколько копий одного и того же процесса, и эти копии совместно используют значительный сегмент памяти. В Windows создается единственный процесс с именем oracle, в рамках которого выполняется множество независимых потоков. В последнем случае немного проще представить потоки, совместно использующие сегмент памяти. Формально,
файлы с данными называют базой данных (database), а комбинацию памяти и действующую программу (или программы) – экземпляром (instance). При использовании кластеризованной версии Real Application Clusters (RAC) можно настроить несколько компьютеров так, чтобы на каждом выполнялся отдельный экземпляр, но все они совместно использовали одну базу данных.

Сегмент совместно используемой памяти (формально: системная глобальная область (System Global Area), иногда ее называют разделяемой глобальной областью (Shared Global Area), но чаще просто используют аббревиатуру SGA) хранит массу разнообразной информации. Самыми важными хранимыми компонентами являются: кэш данных (окно в файлы с данными, хранящее копии некоторых блоков), буфер журнала (очень небольшой фрагмент памяти, используемый как циклический буфер для хранения информации, которая в скором времени будет записана в файлы журналов) и кэш библиотек (хранит информацию об инструкциях SQL и блоках PL/SQL, выполнявшихся последними). Формально, кэш библиотек является частью разделяемого пула (shared pool), но это слишком широкий термин и, к тому же, он часто применяется для обозначения любой памяти в SGA, используемой в текущий момент.

Примечание. Существует еще несколько не менее важных компонентов системы Oracle, а именно: пул потоков данных (streams pool), Java-пул и большой пул (large pool). Но все они являются обычными областями памяти, изолированными от разделяемого пула и предназначенными для поддержки специализированных механизмов.

Если вы сможете разобраться с разделяемым пулом, вы без труда разберетесь и с другими пулами. В SGA имеется сегмент, заслуживающий отдельного упоминания: «часы» (clock), используемые экземплярами для координации действий. Это простой счетчик, который называется системным номером
изменения (System Change Number, SCN) иногда его называют (не совсем правильно) системным номером подтверждения транзакции (System Commit Number).

Все процессы, имеющие доступ к SGA, могут читать и изменять SCN. Обычно процессы читают текущее значение в начале каждого запроса или транзакции (с помощью подпрограммы kcmgss – Get Snapshot SCN), и каждый раз, когда процесс подтверждает транзакцию, он увеличивает значение SCN (с помощью
подпрограммы kcmgas – Get and Advance SCN). Значение SCN увеличивается также в других случаях, именно поэтому название «системный номер изменения» (System Change Number) лучше соответствует его сути, чем название «системный номер подтверждения транзакции» (System Commit Number).

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

Существует отдельный процесс, копирующий информацию из буфера журнала в файлы. Его так и называют – процесс записи в журналы (log writer, известный также как lgwr). Каждый экземпляр имеет только один процесс lgwr. Аналогично существует отдельный процесс, копирующий информацию из кэша в файлы данных. Это – процесс записи в базу данных (database writer, известный также как dbwr). Часто экземпляры имеют только один такой процесс, но в очень больших и высоконагруженных системах возможно (а часто и необходимо) обеспечить запуск нескольких процессов записи в базу данных, которые получат имена dbwN (где диапазон возможных значений N отличается для разных версий Oracle).

Наконец, в каждом экземпляре существует несколько копий серверных процессов. Эти процессы выполняют операции с SGA и читают файлы с данными от имени конечного пользователя. Программы конечных пользователей передают инструкции и принимают результаты через конвейер SQL*Net. Администратор базы данных (то есть, вы!) может выбирать в настройках между двумя типами серверных процессов: выделенные (dedicated) серверные процессы и разделяемые (shared, прежде их называли многопоточными (multithreaded)).

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


Что действительно нужно знать о системе Oracle?

В конечном счете все сводится к следующему:

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

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

 

Заключение 

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

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

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

В заключение мы быстренько пройдемся по кластеризованной версии (RAC). Выясним, какие проблемы возникают из-за необходимости синхронизировать работу нескольких экземпляров на разных компьютерах.

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

Процессы Oracle
Процессы Oracle 10456 просмотров Antoniy Sun, 02 Sep 2018, 15:37:58
Создание базы данных Oracle
Создание базы данных Oracle 34271 просмотров Александров Попков Wed, 14 Nov 2018, 12:44:39
Видеокурс по администрированию...
Видеокурс по администрированию... 10719 просмотров Илья Дергунов Mon, 14 May 2018, 05:08:47
Oracle и непроцедурный доступ ...
Oracle и непроцедурный доступ ... 8511 просмотров Antoni Tue, 21 Nov 2017, 13:32:50
Войдите чтобы комментировать