Transcript Архитектура

Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
Архитектура базы Oracle
1
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
Что необходимо знать
•
•
•
•
2
Архитектурные компоненты Oracle
Структуры в памяти
Фоновые процессы
Логические и физические структуры для хранения данных
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
Соединение с сервером
3
Существует 3 сценария, как пользователь соединяется с базой данных.
1. Пользователь входит в систему, на которой запущен экземпляр (instance)
Oracle. Важный момент: это должна быть та же машина, на которой запущен
экземпляр. Далее он запускает приложение или инструмент, обращающийся к
базе, в этой системе. В этом случае соединение с базой устанавливается с
использованием механизмов взаимодействия процессов, доступных в данной
ОС.
2. Пользователь запускает приложение или инструмент и через сеть
обращается к базе Oracle. Приложение может быть запущено на той же машине,
что экземпляр, главное, что отличает данный сценарий – что обращение
происходит через сеть. В этой конфигурации (клиент / сервер) для коммуникации
используется сетевые программы.
При архитектуре «клиент-сервер» есть 2 части: front end (что можно перевести
как «передний край», «внешний интерфейс») – клиент и back end («задняя
часть», «сервер») – сервер, которые соединяются через сеть.
Клиент – приложение баз данных – инициирует выполнение операции на
сервере, а затем обрабатывает и представляет пользователю данные,
возвращенные сервером. Клиентской машине не нужен большой жесткий диск
(данные хранятся на сервере), зато могут пригодиться графические
возможности. Часто клиент работает на другой машине, чем сервер, но это не
является обязательным условием. Для сервера, напротив, обычно используется
большой жесткий диск и мощный процессор. Это 2-х уровневая архитектура.
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
3. Многоуровневая архитектура (multitier architecture).
Клиент
4
Средний ярус (middle tier)
Сервер
Сервер приложений (application server)
Пользователь обращается к серверу приложений с помощью программы, как
правило, веб браузера. Сервере приложений затем взаимодействует с
сервером базы данных (back end) от имени клиента.
Компоненты многоуровневой архитектуры.
• Клиент или инициатор процесса, который начинает операцию
• Один или несколько серверов приложений (application server), которые
выполняют части операции. Сервер приложений содержит значительную
часть логики приложения, обеспечивает клиенту доступ к данным и выполняет
некоторую обработку, уменьшая нагрузку на сервер баз данных. Сервер
приложений может служить в качестве интерфейса между клиентами и
несколькими серверами баз данных и может обеспечить дополнительный
уровень безопасности.
• Сервер баз данных хранит данные.
При такой архитектуре сервер приложений выполняет следующие функции:
• Проверяет права клиента (например, веб браузера)
• Соединяется с сервером баз данных Oracle
• Выполняет запрошенные действия от имени клиента
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
Соединение с базой и сессия
Соединение (connection) – связь между пользовательским процессов и
экземпляром Oracle. Связь устанавливается с использованием механизмов
взаимодействия между процессами (если пользовательский процесс и база
работают на одной машине) или сетевых программ (если они работают на разных
машинах и соединение происходит через сеть).
Сессия (session) – конкретное соединение пользователя с экземпляром
посредством пользовательского процесса (user process). Сессия представляет
состояние работы пользователя с экземпляром базы. Например, когда
пользователь запускает SQL*Plus, он должен ввести логин и пароль, после чего
для него устанавливается сессия. Сессия длится с того момента, когда
пользователь соединяется, и длится до тех пор, пока пользователь не
отсоединяется от базы.
User
SQL> Select …
User
process
Server
process
Connection
Session
5
Разработка приложений в среде Oracle
Session
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура. Instance
Memory structures
SGA
PGA
Shared
SQL area
Server
process 1
User
process
Shared pool
Redo log
buffer
Database buffer
cache
Server
process 2
Processes
Other
Library
cache
PGA
Java pool
PGA
Background
process
DBWn
CKPT
LGWR
Data dictionary
cache
Streams
pool
SMON
PMON
I/O buffer
Free
memory
Response
queue
Request
queue
Large pool
ARCn
RECO
Database
Storage structures
Data files
6
Control
files
Разработка приложений в среде Oracle
Online redo
log files
Others
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
Взаимодействие с БД Oracle
Рассматривается сценарий взаимодействия через сеть.
1. Экземпляр стартует на сервере, где установлена БД Oracle (часто
называется host или database server).
2. Пользователь запускает приложение. Приложение пытается установить
соединение с сервером (соединение может быть локальным, клиент/сервер
или трехуровневым из среднего уровня).
3. На сервере запущен listener, у которого есть соответствующий Oracle Net
Services handler. Сервер обнаруживает запрос на соединение от приложение
и создает выделенный серверный процесс (dedicated server process).
4. Пользователь выполняет SQL-запрос типа DML и фиксирует транзакцию
(например, меняет адрес клиента).
5. Серверный процесс получает запрос и проверяет в shared pool (можно
перевести как «общий пул») – компонент SGA, нет ли shared SQL Area
(общей области SQL), в которой есть аналогичный SQL запрос. В SQL Area
сохраняются последние запросы. Если shared SQL Area содержит
аналогичный запрос, серверный процесс проверяет, есть ли у пользователя
права на запрошенные данные, и существующая shared SQL area
используется для обработки запроса. Если shared SQL Area не найдена, для
запроса создается новая shared SQL Area, далее запрос разбирается и
выполняется.
7
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
6. Серверный процесс (server process) получает все необходимые данные
либо из файла данных (таблицы), либо из данных, сохраненных в SGA (это
быстрее – некоторый кэш из данных).
7. Серверный процесс модифицирует данные в SGA. Поскольку транзакция
фиксируется (commited), процесс LogWriter (LGWR) (можно перевести как
«писатель логов») немедленно записывает транзакцию в redo log file (можно
перевести как «файл логов повтора»; называется так потому, что с
помощью данных файлов логов можно повторить (redo) действия). Процесс
Database Writer (DBWn) записывает измененные блоки на диск тогда, когда
это эффективно.
8. Если транзакция успешна, серверный процесс посылает сообщение
приложению через сеть. Если нет, посылается сообщение об ошибке.
9. Во время выполнения данной процедуры выполняются фоновые процессы,
проверяя, не требуется ли вмешательство. Помимо этого, сервер баз
данных управляет транзакциями других пользователей и предотвращает
конфликт между транзакциями, запрашивающими одни и те же данные.
8
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
Структуры памяти
2 базовые структуры памяти, связанные с экземпляром:
• System Global Area (SGA): Группа структур, находящихся в общей памяти,
которые содержат данные и информацию для управления для экземпляра
базы данных Oracle. SGA является общей для всех серверных и фоновых
процессов. Например, в SGA хранятся кэшированные блоки данных и shared
SQL areas.
• Program Global Areas (PGA): Области в памяти, которые содержат данные
и информацию для управления для серверного или фонового процесса. SGA
– это не общая память, которая создается, когда стартует серверный или
фоновый процесс. Доступ к PGA имеет только сам процесс. У каждого
процесса своя PGA.
9
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
SGA
• Database buffer cache (кэш базы): Кэширует блоки данных из базы
• Redo log buffer (буфер логов повтора): Кэширует информацию для повторения
(redo information) (используется для восстановления экземпляра), пока она не
будет записана физически в файлы redo log
• Shared pool (общий пул): Кэширует различные элементы, которые могут быть
общими для пользователей
• Large pool (большой пул): Необязательная область, которая обеспечивает
выделение больших областей памяти для больших процессов, таких, как создание
резервных копий (backup), операции восстановления (recovery), операции ввода /
вывода.
• Java pool (пул Java): Используется для кода и данных Java Virtual Machine (JVM)
• Streams pool (пул потоков): Используется Oracle Streams для хранения
информации (Oracle Streams – компонент для обмена информацией)
Когда экземпляр запускается при помощи Enterprise Manager или SQL*Plus,
отображается объем памяти, выделенной для SGA.
Инфраструктура SGA позволяет менять размеры database buffer cache, shared
pool, the large pool, the Java pool и Streams pool без остановки экземпляра.
База данных Oracle использует параметры инициализации, чтобы создавать и
управлять структурами памяти. Простейший способ управления – позволить СУБД
управлять автоматически. Для этого на большинстве платформ необходимо только
установить параметры инициализации MEMORY_TARGET (размер памяти) и
MEMORY_MAX_TARGET (максимальный размер памяти).
10
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
Database Buffer Cache
В свободном переводе – кэш базы данных.
• Часть SGA
• Хранит копии блоков данных, считываемых из файлов
• Все пользователи, которые подключены к базе, разделяют доступ к
database buffer cache
В первый раз, когда пользовательский процесс запрашивает данные, он ищет
данные в database buffer cache. Если процесс находит данные в кэше (cache hit
- попадание), данные можно считать непосредственно из памяти. Если процесс
не может найти данные в кэше (cache miss – промах), он должен скопировать
блок данных их файла на диске в кэш. Доступ к данным при cache hit быстрее,
чем при cache miss.
Буферы в кэше управляются при помощи сложного алгоритма, использующего
комбинацию алгоритмов least recently used (LRU) lists (наиболее давно
использованный) и touch count (количество обращений).
11
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
Redo Log Buffer
• Цикличный буфер в SGA
• Хранит информацию об изменениях, произведенных с базой
• Содержит redo-записи, в которых хранится информация о том, как
повторно внести изменения (redo), выполненные операциями DML, DDL и
внутренними операциями.
Redo entries (записи redo) могут также использоваться для восстановления
базы после сбоя.
Записи redo копируются процессами базы Oracle из области памяти
пользователя в redo log buffer. Записи redo располагаются в буфере
непрерывно и последовательно. Процесс LSWR записывает содержимое redo
log buffer в активный redo log file (файл логов redo) на диске (или группу
файлов).
12
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
Shared Pool
Это часть SGA, которая содержит library cache (кэш библиотеки), data dictionary
cache (кэш словаря данных), SQL query result cache (кэш результатов SQLзапросов), PL/SQL function result cache (кэш результатов функций PL/SQL),
buffers for parallel execution messages (буферы для сообщений о параллельном
выполнении) и control structures (структуры управления).
Data Dictionary (словарь данных) – это коллекция таблиц и представлений с
информацией о базе данных, ее структуре и пользователях. Эти таблицы
позволяют узнать, например, какие таблицы есть в базе (пример –
USER_TABLES позволяет получить перечень таблиц; USER_TABLES относится
к словарю данных). К словарю данных приходится часто обращаться при
разборе SQL запросов. Обращение происходит так часто, что для словаря
данных есть 2 области в памяти:
1. Data Dictionary Cache (кэш словаря данных), также известный как row cache
(кэш строк), поскольку хранит данные в виде строк, а не буферов.
2. Library Cache (кэш библиотеки) .
Все пользовательские процессы имеют общий доступ к этим двум кэшам для
доступа к информации словаря данных.
База Oracle представляет каждый выполняемый запрос SQL с помощью shared
SQL area (общей области SQL), находящейся в SGA, а также private SQL area
(частной области SQL), хранимой в PGA.
Oracle определяет, что 2
пользователя выполняют один и тот же SQL-запрос, и для таких пользователей
повторно используется та же shared SQL area.
13
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
Shared SQL area содержит дерево разбора и план выполнения для конкретного
SQLзапроса. Oracle экономит память благодаря тому, что, когда одинаковые
запросы выполняются несколько раз (это часто происходит, когда несколько
пользователей работают с одним приложением), используется одна и та же
область памяти. Когда встречается новое SQL-выражение, Oracle выделяет память
в shared pool, чтобы сохранить его в shared SQL area. Размер памяти зависит от
сложности выражения.
Oracle обрабатывает элементы PL/SQL (процедуры, функции, пакеты, анонимные
блоки и триггеры) во многом так же, как отдельные выражения SQL. Oracle
выделяет shared area (в SGA) для хранения разобранного и откомпилированного
программного модуля (program unit). Oracle выделяет частную область (в PGA) для
хранения специфичных для сессии значений (локальные, глобальные
переменные, переменные пакета (package variables, также известные как package
instantiation), буфер для выполнения SQL). Если более чем один пользователь
выполняет один и тот же программный модуль, всеми пользователями
используется одна и та же shared area, но у каждого своя private SQL area, в
которой хранятся значения, специфичные для сессии.
Отдельные выражения SQL, находящиеся в программе PL/SQL, обрабатываются
так же, как обычные выражения SQL. Несмотря на то, что они находятся в
программном модуле PL/SQL, эти выражения используют shared area для
хранения своих разобранных представлений и private area для каждой сессии, в
рамках которой выполняется запрос.
14
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
SQL query result cache и PL/SQL function result cache
В Oracle Database 11g появились SQL query result cache (кэш результатов SQLзапросов) и PL/SQL function result cache (кэш результатов функций PL/SQL). Эти
кэши используют одинаковую инфраструктуру, отображаются в одних и тех же
dynamic performance ($V) views (представлениях производительности) и
управляются одним и тем же пакетом, поставляемым Oracle. Результаты
запросов и фрагментов запросов могут кэшироваться в памяти в SQL query
result cache. База данных может в дальнейшем использовать эти результаты.
Поскольку получение результатов из SQL query result cache происходит
быстрее, чем повторное выполнение запроса, часто выполняемые запросы
благодаря кэшированию работают гораздо быстрее.
Функции PL/SQL иногда используются, чтобы вернуть результат вычисления,
основой для которого являются параметризированные запросы (parameterized
queries), выполняемые функцией (то есть функция вначале выполняет запросы,
а затем выполняет вычисления). В некоторых случаях данные, к которым
обращается с запросом функция, меняются гораздо реже, чем происходит
вызов функции. В исходный текст PL/SQL можно включить указания, чтобы
результаты кэшировались в PL/SQL function result cache и (для обеспечения
корректности) удалялись из кэша, когда происходят изменения данных в одной
из таблиц, указанных в списке.
15
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
Выделение и повторное использование памяти в shared pool
•
Серверный процесс проверяет, нет ли в shared pool области (SQL area) для
идентичного выражения SQL
•
Серверный процесс выделяет частную SQL area (в рамках сессии)
В общем случае, область памяти (shared SQL area или dictionary row) в shared
pool остается до тех пор, пока она не будет очищена в соответствии с
модифицированным алгоритмом LRU (least recently used – наименее
недавно использованное). Память под элементами, которая используется
редко, освобождается, если она требуется для новых элементов, которым
требуется место в shared pool. Модифицированный алгоритм LRU позволяет
элементам, которые активно используются, оставаться в памяти, даже если
процесс, их создавший, завершает свою работу.
Когда выражение на языке SQL передается в базу на выполнение,
автоматически выполняются следующие шаги, связанные с выделением
памяти:
1. База Oracle проверяет, нет ли в shared pool области SQL для идентичного
запроса. Если есть, эта область используется для последующего
выполнения запроса. Если нет, Oracle создает новую SQL area в shared pool.
2. Создается частная SQL area.
16
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
Примечание. Shared SQL area может быть очищена, даже если существует
открытый курсор, который некоторое время не использовался. Если курсор
повторно используется для выполнения выражения, Oracle повторно разбирает
выражение и создает новую shared SQL area.
Oracle также очищает shared SQL area в следующих случаях:
• Используется пакет DBMS_STATS для обновления или удаления статистики
таблицы, кластера или индекса. Все shared SQL areas, которые ссылаются на
анализируемые объекты, удаляются из shared pool. В следующий раз будет
создана новая shared SQL area. Это делается для того, чтобы использовалась
самая актуальная статистика, что позволит Oracle создавать более
эффективный план выполнения запроса.
• SQL area ссылается на объект, который изменяется (например, добавляется
столбец в таблицу)
• Меняется глобальное имя базы. В этом случае из shared pool убирается вся
информация.
Администратор может вручную очистить всю информацию из shared pool,
чтобы оценить производительность после запуска экземпляра (то есть когда
shared pool еще не заполнен) без перезапуска экземпляра. Для этого
используется SQL выражение ALTER SYSTEM FLUSH SHARED_POOL.
17
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
Large Pool
Администратор может сконфигурировать необязательную область памяти,
называемую Large Pool (большой пул), которая позволяет выделять большой
объем памяти для:
• Сессии для общего сервера (shared server) и интерфейса Oracle XA
(используется, когда транзакции взаимодействуют более, чем с одной базой)
• Процессов ввода-вывода
• Операция создания резервных копий и восстановления
Выделяя память для сессий из Large Pool для shared server, Oracle XA и parallel
query buffers, Oracle может использовать shared pool для исключительно для
кэширования SQL запросов и избежать издержек, связанных с уменьшением
shared SQL cache (так как иначе память выделялась бы из shared pool).
Кроме того, память для операций создания резервных копий, восстановления,
ввода/вывода, параллельных буферов выделяется размером несколько сотен
килобайт. Large pool лучше приспособлен для выделения таких больших
запросов к памяти, чем shared pool.
Large pool не содержит списка LRU и этим также отличается от shared pool.
18
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
Java Pool и Streams Pool
• Память Java pool используется для хранения специфичных для сессии кода и
данных в Java Virtual Machine (JVM). Java pool используется по-разному в
зависимости от режима, в котором работает база Oracle. Java Pool Advisor
statistics (статистика советника Java Pool) дает информацию о памяти library
cache, используемой для Java, и позволяет сделать прогноз, как изменение
размера Java pool повлияет на скорость разбора. Java Pool Advisor внутренне
включается, когда statistics_level устанавливается равным TYPICAL или выше.
Статистика сбрасывается, когда advisor выключается.
• Streams pool используется исключительно Oracle Streams для хранения
буферов очередей сообщений и выделения памяти для процессов Oracle
Streams. Если специально не указать, размер Streams pool изначально равен 0.
Размер растет динамически по мере необходимости, когда используется Oracle
Streams.
19
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
Архитектура процессов
Процессы (processes) в базе данных Oracle можно разделить на 2 группы.
• Пользовательские процессы (user processes). Запускаются, когда пользователь
соединяется с базой данных. Пользовательские процессы выполняют код
приложения или инструмента Oracle.
• Процессы базы данных (database processes). Выполняют код сервера базы
данных. В свою очередь, делятся на 2 группы:
• Серверные процессы (server processes). Запускаются, когда пользователь
устанавливает соединение.
• Фоновые процессы (background processes). Запускаются при старте
экземпляра Oracle.
Когда пользователь запускает приложение или инструмент Oracle (например,
SQL*Plus), база Oracle создает пользовательский процесс, который выполняет
приложение пользователя. Также Oracle создает серверный процесс, который
выполняет команды, переданные пользовательским процессом. Кроме того,
сервер Oracle имеет набор фоновых процессов, связанных с экземпляром,
которые взаимодействуют друг с другом и с операционной системой.
Структура процессов зависит от конфигурации базы Oracle, операционной
системы и выбранных опций.
20
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
Серверные процессы
База данных может быть сконфигурирована как выделенный сервер (dedicated
server) или общий сервер (shared server).
Выделенный сервер (dedicated server). Для каждого пользователя приложение
выполняется пользовательским процессом, который обслуживается отдельным
(выделенным) серверным процессом.
Общий сервер (shared server). Исключает необходимость отдельного
серверного процесса для каждого соединения. Диспетчер (dispatcher)
направляет входящие запросы пулу серверных процессов. Общий серверный
процесс обслуживает запрос любого клиента, а не одного, как в случае
выделенного сервера.
В некоторых ситуациях, если приложение и база данных Oracle работают на
одной машине, возможно соединить пользовательский процесс и
соответствующий серверный в единый процесс, чтобы уменьшить издержки.
Тем не менее, когда приложение и база находятся на разных машинах,
пользовательский процесс всегда взаимодействует с базой через отдельный
серверный процесс.
Серверные процессы могут выполнять следующие задачи:
• Разбирать (parse) и выполнять SQL запросы
• Считывать необходимые блоки данных из файлов данных на диске в shared
database buffers в SGA (если блоков еще нет в SGA)
• Возвращать результаты, чтобы приложение могло обработать информацию
21
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
Фоновые процессы
Для обеспечения максимальной производительности и работы нескольких
пользователей, база данных Oracle использует дополнительные фоновые
процессы (background processes). Фоновые процессы, которые обычно есть в
базе данных, не использующей RAC и ASM, включают:
Database writer process (DBWn)
Log writer process (LGWR)
Checkpoint process (CKPT)
System Monitor process (SMON)
Process monitor process (PMON)
Recoverer process (RECO)
Job queue processes
Archiver processes (ARCn)
Queue monitor processes (QMNn)
В других конфигурациях, например, включающих RAC, могут быть и другие
процессы. Для просмотра информации о процессах можно использовать
представление V$BGPROCESS. На большинстве ОС (в т.ч. Windows)
фоновые процессы создаются автоматически при запуске экземпляра.
22
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
Database Writer Process (DBWn)
Процесс записывает измененные, «грязные» (modified, dirty) фрагменты из
database buffer cache на диск. Это происходит двумя способами:
• Асинхронно при выполнении других задач
• Периодически для перемещения вперед контрольной точки (checkpoint)
Хотя для большинства систем достаточно одного Database Writer process
(DBW0), можно создать дополнительные процессы (DBW1 - DBW9 и DBWa DBWj), чтобы улучшить производительность, если данные активно
изменяются. Дополнительные процессы, однако, не принесут пользы на
однопроцессорных системах.
Когда буфер в database buffer cache модифицируется, он помечается как
«грязный» и добавляется в список LRUW (Least Recently Used Write –
наиболее давно использованных для записи) «грязных» буферов, которые
сохраняются в порядке SCN (System Change Number – системный номер
изменения). Этот порядок, таким образом, соответствует порядку действий,
которые записываются в redo логи. Когда число доступных фрагментов в
buffer cache становится меньше некоторого порогового значения (так, что для
серверного процесса становится сложно получить доступный буфер), DBWn
записывает грязные буферы в файлы данных в том порядке, в котором они
хранятся в списке LRUW (а так как этот порядок соответствует порядку
изменений, в том порядке, в котором производились изменения).
23
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
SGA хранит redo byte address (RBA) (адрес байта redo) позиции в потоке redo,
откуда должно начаться восстановление в случае сбоя. Эта структура (RBA)
действует как указатель на redo и записывается в контрольный файл (control file)
процессом CKPT каждые 3 секунды. Поскольку DBWn записывает грязные буферы
в порядке SCN, и поскольку redo также хранятся в порядке SCN, каждый раз, когда
DBWn записывает грязный буфер из списка LRUW, он также передвигает
указатель, находящийся в SGA, чтобы восстановление экземпляра (если
потребуется) началось с приблизительно нужной позиции и избежало ненужных
операций ввода/вывода. Этот процесс известен как incremental checkpointing.
Замечание. Существуют и другие случаи, когда DBWn производит запись
(например, когда табличные пространства (tablespaces) становятся «только для
чтения» или становятся автономными (place offline). В таком случае не происходит
incremental checkpoint, поскольку записываются только грязные буферы,
относящиеся к соответствующим файлам данных (data files)
независимо от
порядка SCN.
Алгоритм LRU оставляет блоки, к которым наиболее часто происходит обращение,
в buffer cache, так что когда буфер записывается на диск, маловероятно, что его
данные скоро понадобятся.
Число
процессов
DBWn
указывается
в
параметре
инициализации
DB_WRITER_PROCESSES. Максимальное число процессов равно 20. Если
параметр не указан пользователем при запуске, Oracle определяет, как установить
параметр DB_WRITER_PROCESSES, основываясь на числе процессоров.
24
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
LogWriter Process (LGWR)
Процесс записывает данные из redo log buffer (буфера redo-логов, или буфера
журнала отката) в redo log file (файл журнала отката) на диске. LGWR
записывает все записи redo, которые были помещены в буфер со времени,
когда запись производилась в прошлый раз.
Redo log buffer – цикличный буфер. Когда LGWR записывает элемент redo из
буфера в файл, серверный процесс может записать новые записи туда, где
находились записанные на диск записи. Обычно LGWR пишет достаточно
быстро, так что в redo log buffer достаточно места для новых записей, даже
если число записей велико. LGWR записывает одну непрерывную порцию из
буфера на диск.
LGWR записывает в следующих ситуациях:
• Когда пользовательский процесс (pLogWriter) фиксирует транзакцию
• Когда redo log buffer заполнен на треть
• Перед тем, как DBWn записывает измененные буферы на диск (если логи
еще не записаны)
Перед тем, как DBWn сможет записать измененный буфер, все записи redo,
связанные с изменениями в буфере, должны быть записаны на диск (протокол
write-ahead – вначале запись). Если DBWn обнаруживает, что какие-то записи
redo не были записаны, он сообщает об этом LGWR и ждет, пока LGWR не
запишет записи redo. Только после этого DBWn может записать данные в
файлы. LGWR пишет в текущую группу логов.
25
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
Если один из файлов поврежден или недоступен, LGWR продолжает писать в
другие файлы в группе и регистрирует ошибку в файле трассировки LGWR
(LGWR trace file) и в логе предупреждений системы (system alert log). Если все
файлы в группе повреждены или группа недоступна, поскольку не была
заархивирована, LGWR не может функционировать.
Когда пользователь фиксирует транзакцию, LGWR помещает запись о
фиксации в redo log buffer и записывает ее на диск немедленно вместе с
записями redo транзакции. Изменения в сами данные вносятся позже, тогда,
когда это наиболее эффективно. Этот механизм называется fast commit.
Атомарная запись redo, содержащая commit, - единственное событие, которое
определяет, была ли транзакция зафиксирована. Oracle возвращает код
успешного завершения, хотя физически блоки данных еще не были записаны
на диск.
Если не хватает места в буфере, LGWR может записать redo log entries до того,
как транзакция была зафиксирована. Эти записи становятся постоянными
только в том случае, если транзакция была позже зафиксирована. Когда
пользователь фиксирует транзакцию, ей присваивается SCN (system change
number), который Oracle записывает вместе с записями в redo log. SCN
записываются в redo log, так что операции восстановления могут
синхронизироваться в Real Application Clusters и распределенных базах.
26
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
Checkpoint Process (CKPT)
Процесс, связанный с контрольной точкой.
Контрольная точка (checkpoint) – это структура данных, которая определяет
system change number (SCN) в потоке redo базы данных. Контрольные точки
записываются в контрольный файл и в заголовок каждого файла данных. Они
критичны для восстановления системы.
Когда наступает контрольная точка, Oracle должен обновить заголовки всех
файлов данных, чтобы записать данные контрольной точки. Это выполняет
процесс CKPT. CKPT не записывает данные на диск; это выполняет DBWn.
Запись SCN в заголовки файлов гарантирует, что все изменения, внесенные
ранее, записаны на диск.
Статистические контрольные точки DBWR (statistic DBWR checkpoints),
отображаемые монитором SYSTEM_STATISTICS в Oracle Enterprise Manager,
показывают число запросов контрольных точек, которые завершились.
27
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
System Monitor Process (SMON)
Название процесса можно перевести как «Системный монитор».
System Monitor process (SMON) выполняет следующие задачи:
• Производит восстановление при запуске экземпляра. Если какие-то
завершенные транзакции были пропущены при восстановлении экземпляра
из-за ошибок чтения файла или автономности файла, SMON восстанавливает
их, когда табличное пространство (tablespace) или файл снова подключаются
(bring online).
• Очищает неиспользуемые временные сегменты.
SMON регулярно проверяет, нужен ли он. Другие процессы также могут
вызвать SMON.
28
Разработка приложений в среде Oracle
Раздел 1. Администрирование Oracle Database 11g. 2. Архитектура.
Process Monitor Process (PMON)
Process Monitor process (PMON) можно перевести как «Монитор процессов» уже судя по названию, он следит за тем, как работают процессы.
Выполняет восстановление процесса, когда пользовательский процесс дает
сбой. Выполняет следующие задачи:
• Восстанавливает процесс, когда пользовательский процесс дает сбой.
• Очищает буферный кэш (buffer cache).
• Освобождает ресурсы, используемые пользовательским процессом. В
частности, PMON сбрасывает статус текущей таблицы транзакции,
освобождает блокировки, удаляет идентификатор процесса из списка
активных процессов.
• Проверяет, не истек ли таймаут у сессии
• Динамически регистрирует службы в listener’ах (благодаря этому, в
частности, не важен порядок запуска листенера и службы)
PMON периодически проверяет статус диспетчера и серверных процессов и
перезапускает те из них, которые перестали работать (но не были намеренно
остановлены базой Oracle).
Как и SMON, PMON периодически проверяет, нужен ли он; он может быть
вызван другим процессом.
29
Разработка приложений в среде Oracle