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

Сервер состоит из двух компонентов:

1. Экземпляр СУБД. Экземпляр состоит из собой память + фоновые процессы. Память – Системная Глобальная Область (System Global Area, SGA), разделяемая, к ней имеют
доступ все процессы. Каждый раз при запуске экземпляра выделяется SGA и запускаются фоновые процессы. SGA содержит данные и управляющую информацию для
одного экземпляра.
2. Непосредственно сама база данных – в виде файлов данных, управляющих файлов , оперативных журналов.
 Подключение к БД

Под подключением пользователя к БД подразумевается соединение пользовательского процесса с экземпляром СУБД, а точнее с одним из серверных процессов, предназначенных
для обслуживания пользовательских запросов. Соотношение пользовательских процессов к обслуживающим их серверным может настраиваться. В зависимости от таких настрое
разделяют два режима подключений: режим выделенного сервера и режим разделяемого сервера.
В режиме разделяемого сервера меньшее кол-во серверных процессов обслуживает большее кол-во пользовательских, что позволяет экономить ресурсы системы. Т.е. такая
конфигурация выбирается в случае дефицита ресурсов. В таком случае обслуживание пользовательских запросов будет происходить через очередь и контролироваться одним или
несколькими процессорами диспетчера.
Для обработки запросов на подключение по сети на сервере запущен специальный процесс Listner, который осуществляет «прослушку» порта на наличие запросов на подключение.
Listener порождает серверный процесс в случае работы в режиме выделенного сервера или передает управление диспетчеру в случае разделяемого сервера.
При подключении в режиме выделенного сервера Listener порождает серверный процесс с отдельной областью программной выделенной памяти (PGA).
Глобальная системная область(SGA) памяти доступна всем серверным процессам, программная область (PGA) – только процессам ее породившим.
Подключение и сессия тесно связаны с процессами пользователя, но разные по смыслу:
- подключение является путем связи между пользовательским процессом и экземпляром. Подключение устанавливается с помощью доступных механизмов межпроцессного
соединения или посредством сети
- Сессия представляет собой текущее состоянии авторизации пользователя на экземпляре СУБД. Сессия существует с момента подключения под определенным логином до момента
отключения или выхода из приложения. Одновременно может существовать несколько сессий для одного пользователя.

User Global Area (UGA)

UGA это область памяти, которая выделяется для хранения различных переменных сессии, таких как информация о логине, и другой необходимой информации. В том числе UGA
хранит состояние сессии. UGA должна быть доступна в течении всего времени жизни сессии. По этой причине, UGA не может располагаться в PGA, если используется режим
разделяемого сервера, поскольку PGA выделяется для каждого серверного процесса отдельно. Таким образом UGA распологается в SGA при работе в редиме разделяемого сервера
и доступна всем серверным процессам. В режиме разделяемого сервера UGA располагается в PGA.

Program Global Area (PGA)

PGA - это область памяти, которая выделяется отдельно каждому рабочему процессу или потоку, которые не доступны другим процессам и потокам системы. Поскольку PGA
доступна только тому процессц, для которого была выделена, она не хранится в SGA.

PGA хранит в себе сессионно зависимую информацию, необходимую серверному процессу. Серверные процессы размещают в PGA необходимую им информацию.

PGA может состоять из следующих областей (не обязательно включает в себя все):
Private SQL Area

PGA хранит сессионно-зависимую информацию, в том числе разобранные SQL запросы. Когда серверный процесс выполняет SQl или PL/SQL код, то он использует PGA для хранения
значений связанных переменных, информации о состоянии извлечения запроса, а также области извлечения sql запроса.

Курсор является именем или указателем на соответствующую Private SQL Area.

Private SQL area состоит из следующих областей::

 run-time area
Хранит в себе информацию о состоянии извлечения sql запроса. Она создается на первом шаге извлечения запросов
 persistent area
Здесь хранятся значения связанных переменных(bind variable), которые подставляются в запрос при извлечении
Ответственность за управление private SQL area лежит на клиентском процессе. Выделение и освобождение private SQL area по большей части лежит зависит от приложения, за
исключением того, что со стороны сервера установлен лимит на количество private SQL area, которые могут быть выделены.
Чаще всего используется автоматическое управление курсорами с помощью различных инструментов и интерфейсов. Но в любом случае, приложение должно закрыть все курсоры,
которые не будут более использованы, чтобы освободить persistent area.

SQL Work Areas

Work area - приватная область в PGA, которая используется для интенсивных операций работы с данными. Например, операции сортировки производятся в sort area, для
выполнения hash join построение хэш-таблиц производится в hash area, для bitmap merge используется соответствующая область bitmap merge area.
Если все необходимые данные не помещаются в sql work area, то они разбиваются на более мелкие кусочки и обрабатываются частями с промежуточной выгрузкой во времннное
хранилище на диске.
При использовании автоматического режима управления размером памяти, объем sql work area изменяется самой БД.
-> Интерактивная архитектура сервера
Структура SGA

1. Database buffer cache -

часть SGA, в которой хранятся копии блоков данных, прочитанные из файлов БД. Все пользователи, подключенные к экземпляру, имеют доступ к этому кэшу.
В первый момент, когда серверному процессу требуются какие-либо данные, он пытается найти их в Database buffer cache. Если процесс находит данные в кэше (cache hit),
он может прочитать их сразу из памяти, иначе процессу необходимо скопировать блоки данных из файла на диске, перед тем как получить к ним доступ (cache miss).
Доступ к данным по cache hit происходит быстрее.
Управление буфером происходит по комплексному алгоритму, использующему комбинацию листов данных о времени последнего использования (least recently used, LRU) и
количестве обращений к отдельным блокам.
Модификация данных происходит в кэше. Блоки, в которых произведена модификация, но на диск еще не записана называются «грязными»(dirty). Запись изменений на
диск производится специальным процессом DB Writer при достижении определенного кол-ва «грязных» блоков, либо при нехватке памяти в буфере и необходимости
освобождения блоков.
Буфферный кэш может работать в двух режимах: текущий(Current mode) и согласованный(Consistent mode)

 Current mode

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

 Consistent mode

В согласованном режиме получается согласованная для чтения версия блока данных, т.е. та версия данных, которая не имеет незафиксированных изменения на момент
начала запроса. Для этого используется данные undo. Например, незафиксированная транзакция обновила в блоке данных две строки, и в этот момент другая сессия
пытается обратиться к этому блоку. Тогда с использованием данных undo будет создана согласованная версия этого блока(consistent read clone), которая не будет содержать
незафиксированных изменений.

Таким образом, с помощью режима согласованного чтения решается проблема обращения к данным, которые в данный момент изменяются в другой сессии (Oracle - не
блокировщик! (с) Великие предки)
2. Redo Log Buffer -
циклический буфер, содержащий информацию об изменениях, производимых в БД. Redo-записи содержат всю информацию об изменениях данных, и зафиксированную и
незафиксированную, необходимую для восстановления или повтора изменений, сделанных в БД с помощью DML операций.
Чтобы сделать изменения сессия генерирует вектор изменений, который копируется серверным процессом из PGA в SGA. Этот вектор содержит в себе как изменения
данных, так и необходимые изменения в undo. Redo-записи занимают непрерывное, последовательное пространство в буфере. Фоновый процесс LGWR (log writer),
отвечающий за асинхронный ввод-вывод, пишет redo-записи в активный redo-log файл на диске при выполнении команды commit, достижении определенного количества
"грязных" блоков(checkpoint) или при переключении с одного журнала логов на другой. Redo-логи на диске обычно представлены группой файлов, которые последовательно
заполняются информацией, а после переполнения - перезаписываются, начиная с первого файла.
 3. Shared Pool (Разделяемый пул) -
часть SGA, содержащая следующие элементы:
 Library Cache
 Data Dictionary Cache
 Server Result Cache
 Reserved Pool

Library Cache

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

Когда SQL-команда пытается выполниться, бд пытается повторно использовать ранее извлеченный код. Если разобранное представление SQL-команды существует в кэше и может
быть использовано, то так и происходит. Это называется soft parse или library cache hit. В противном случае бд должно построить новую исполняемую версию кода, что называется
hard parse или library cache miss.

БД представляет каждую SQL команду, которую запускает, следующими областями:

 Shared SQL area

БД использует разделяемую область SQL для обработки первого вызова запроса. Эта область доступна всем пользователям и содержит дерево разбора sql-запроса(statement
parse tree) и план выполнения(execution plan). Для одного уникального запроса существует только одна разделяемая область.
 Для определения идентичности запросов используется хэш-алгоритм: для каждого sql-запроса генерируется хэш, при поиске в Shared SQL area ищется соответствующий хэш
среди существующих запросов. Хэш sql-запроса хранится в системной вьюхе V$SQL, в поле SQL_ID.

Из вышесказанного следует, что любое изменение в форматировании sql-запроса приведет к тому, что хэш запроса изменится и Oracle будет рассматривать его как новый
запрос, вызовет hard-parse и затратит больше ресурсов.

Также, в случае запросов с изменяющимися значениями параметром, следует использовать bind-переменные. Это также позволит избежать лишних hard-parse.

 Private SQL area

Каждая сессия, выполняющая SQL-запрос, имеет свою приватную SQL область в PGA. Каждый пользователь, который запускает одинаковый sql-запрос имеет приватную
область, которая ссылается на одну и ту же разделяемую область в SGA.

Запросы вытесняются из Shared SQL area тогда, когда для нового запроса не хватает места. Происходит это по алгоритму на основе данных LRU-листов и частоты использования.

Также данные о разделяемых запросов удаляются в следующих случаях:

  Если собирается статистика для таблицы, кластера, или индекса, то по умолчанию БД постепенно удаляет все разделяемые SQL-области, в которых содержатся обращения к
анализируемым объектам. В следующий раз, когда удаленный запрос будет вызван, БД заново выполнит его разбор и выделит новую область, чтобы учесть изменения в
статистике.
 Если объект, используемый в запросе, модержащемся в разделяемой области, был изменен с помощью DDL команды, то разделяемая область помечается как
недействительная(invalidate). При следующем вызове оптимизатор должен будет переразобрать запрос.
 Если изменилось глобальное имя БД, то вся информация из Shared pool удаляется.

Data Dictionary Cache

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

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

 Data dictionary cache

Данный кэш хранит информацию об объектах БД. Он также известен под названием row cache, поскольку хранит информацию как строки вместо буфера.

 Library cache

Все серверные процессы имеют доступ к словарю данных.

Server Result Cache
Кэш результатов это пул памяти, который в отличие от буферных пулов хранит результирующие наборы, а не блоки данных. Данный кэш состоит из SQL query result cache и
PL/SQL function result cache, которые имеют похожую структуру.

 SQL Query Result Cache

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

 PL/SQL function result cache

PL/SQL function result cache is часть серверного кэша результатов, которая хранит результаты результаты выполнения функций. Без кэширования 1000 вызовов функции, где
каждое выполнение = 1 секунда, - 1000 секунд. С кэшированием - 1 секунда на все. Отличными кандидатами на кэширование являются часто вызываемые функции,
использующие таблицы со статическими данными.
Reserved Pool

Область памяти в shared pool, которая может использоваться для выделения больших непрерывных кусочков памяти(размером более 5 Кб).

4. Large Pool

Необязательная область памяти, предназначенная для выделения памяти большей, чем есть в shared pool. Large pool предоставляет выделение памяти для следующих
целей:

 UGA для работы в режиме разделяемого сервера (очереди обслуживание запросов и ответов для пользователей)
 Буфер обмена сообщениями между потоками параллельно выполняемого запроса
 Буфер для восстановления БД

large pool используется для выделения памяти для сессии, чтобы избежать фрагментации, которая может возникать при выделении памяти в Shared Pool. Память, выделенная
для сессии в Large Pool, не может быть освобождена до тех пор, пока сессия сама не освободит ее. Это очень контрастирует с тем, как происходит освобождение памяти в Shared
Pool, где используются LRU листы и данные могут устаревать.
Логическая и физическая структура БД

БД можно представить в виде логической и физической структуры.

Tablespaces(Табличные пространства)
БД разделена на логические единицы, называемые табличными пространствами, группы которых могут объединятся в некие логические структуры. Например, могут группироваться
табличные пространства, относящиеся к одному приложению, для упрощения администрирования и других операций.

Databases, Tablespaces, and Data Files (БД, табличные пространства и файлы данных)
Связь между БД, табличными пространствами и файлами данных видна на картинке. Каждая БД логически подразделяется на одно или несколько табличных пространств. Один и
более файлов данных явно связаны с соответствующим табличным пространством и хранят его данные.
Schemas(Схемы)
Схема представляет собой совокупность объектов базы данных, владельцем которых является пользователь БД. Схемы являются логическими структурами, которые
непосредственно относятся к БД и включают в себя различные структуры, такие как таблицы, сиквенсы, процедуры и др.
 Data Blocks(Блоки данных)
Мельчайшая часть памяти в СУБД, данные непосредственно хранятся именно в блоках. Один блок данных соответствует определенному набору байт физического пространства
диска. Размер блока данных задается при создании соответствующего табличного пространства.
Extents(Экстент)
Следующей логической единицей является экстент. Экстент это определенное количество непрерывных блоков данных(хранящихся в одном пространстве).
Segments(Сегменты)
Сегмент представляет собой набор экстентов. Выделяют следующие виды сегментов:
• Data segments: Каждая некластеризованная, не индекс-организованная таблица имеет сегмент данных, за исключением внешних таблиц(external tables) и глоабльных временных
таблиц(global temporary tables), а также партиционированных таблиц, где каждая часть имеет один или более сегментов. Все данные таблицы хранятся в экстентах ее сегмента. Для
партиционированных таблиц каждая часть, каждый кластер имеет собственный сегмент.
• Index segments: Каждый индекс имеет свой индексный сегмент, в котором хранятся его данные. Для партиционированных индексов каждая их часть хранится в отдельнмо
сегменте.
• Undo segments: Для каждого экземпляра БД создается одно табличное пространство UNDO. оно содержит нумерованные undo сегменыт для времнного хранения информации.
• Temporary segments: Временные сегменты создаются, когда для выполнения sql-запроса необходимо расширение work area. Для создания таких сегментов используется
времеенное табличное пространство, которое может задаватсья для каждого пользователя отдельно или по умолчанию для всех пользователей.

SYSTEM and SYSAUX Tablespaces

Каждая база данных Оракл должна содержать табличные пространства SYSTEM и SYSAUX, которые автоматически создаются при создании БД. По умолчанию эти табличные
пространства создаются в небольших файлах, но можно создать их очень большими, которые могут позволить обрабатывать файлы размером до 8 экзабит. Табличное пространство
может быть онлайн(доступно) или оффлайн(недоступно). Табличное пространство SYSTEM всегда онлайн, когда открыта соответствующая БД. В этом табличном пространстве
хранятся таблиц. которые поддерживают базовую функциональность БД, такие как словари данных.
Табличное пространство SYSAUX является вспомогательным для SYSTEM и хранит множество дополнительных компоненто БД. Для корректной работы с БД оно должно быть также
доступна. Допускается что оно может быть недоступно в случае выполнения операций восстановления табличного пространства.

UNDO и REDO.
UNDO
Табличное пространство Undo - особое табличное пространство, преднаначенное для хранение undo информации. В этом табличном пространстве нельзя согдать иные типы
сегментов, кроме undo. Каждая БД содержит 0 или более табличных пространств UNDO. В режиме автоматического управления undo, каждый экземпляр содержит одно и только
одно табличное пространство UNDO.
Каждая база данных Оракл должна иметь возможность для отката или отмены изменений в бд. Именно така информация и хранится в undo и содержит в себе записи об изменениях,
сделанных различными транзакцияи в БД, особенно до того, как транзакция была зафиксированна.
Undo используется для:
 отката изменения после вызова команды ROLLBACK
 восстановления бд
 поддержки режима согласованного чтения
 выполнения ретроспективных запросов
Когда вызывается команда ROLLBACK, записи undo используются для отката изменения, сделанных незафиксированной транзакцией. Во время восстановления бд undo записи
используются для отката изменений, сделанных из redo лога в бд.
REDO
Записи в redo log являются результатом выполнения транзакций и других внутренних команд Oracle. Файлы Redo log защищают бд от потери изменений, связанных с падением
системы, отключением электроэнергии и другими технческими сбоями.
Файлы Redo log должны существовать в нескольких экземплярах, чтобы изменения не были потеряны даже в случае отказа диска. Поэтому redo log состоит из групп файлов, где
каждая группа состоит из файлов журналов, а также их копий.

Разница между REDO и UNDO:

UNDO REDO
Что хранит Как откатить изменения Как воспроизвести изменения
Используется для Отката(rollback), согласованного чтения(read consistence) Накатывания изменения в бд
Где хранится Сегменты Undo Redo log файлы
Защищает от Несогласованного чтения данных Потери данных