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

Предисловие

Данный материал является конспектом темы «Архитектура Oracle Database». В первую очередь составлял его для себя. В книге  «Oracle для профессионалов» Том Кайт (на момент написания актуально 3 издание)  идет дублирование информации с разным уровнем детализации. Конспект позволяет быстро вспомнить опорные точки в повествовании, вернуться к ним и при необходимости перечитать заново.

Нужно ли разработчику базы данных понимать как устроен Oracle DB?

Ответ: да!

Для чего?

1. Разработчик баз данных (DBD) – должен иметь представление об устройстве инструмента с которым он работает. Это знание поможет ему создавать более эффективные приложения, понять почему работает так, а не иначе. 

2. Для общения на одном языке с администраторами баз данных (DBA). Когда совместно разбирается какая-то проблема, то DBA начинают сыпать непонятными словами, с которыми разработчик БД в повседневной жизни обычно не сталкивается. 

Определение базы данных и экземпляра

Существуют два термина, которые при использовании в контексте Oracle вызывают наибольшую путаницу: база данных и экземпляр. В терминологии Oracle они определяются следующим образом.

База данных. Коллекция физических файлов операционной системы. Начиная с версии Oracle Database 12с существуют три типа баз данных (об этом далее).

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

Рис. 1. Схема экземпляра и базы данных.

База данных

Три типа базы данных

С версии Oracle 12с существенно изменилась архитектура. Мы получили три типа базы данных:

База данных с единственным владельцем (single tenant). Это обособленный набор файлов данных, управляющих файлов, журнальных файлов для восстановления, файлов параметров и т.д. Этот набор содержит метаданные (например, определение ALL_OBJECTS), программный код (такой как код для DBMS_OUTPUT) необходимый для работы самого движка Оракл. Плюс здесь же содержатся метаданные, программный код необходимый для работы бизнес-приложения. В версиях, предшествующих 12с, это был единственный тип базы данных.

Контейнерная (container) или корневая (root) база данных. Это обособленный набор файлов данных, управляющих файлов, журнальных файлов для восстановления, файлов параметров и т.д. Этот набор содержит ТОЛЬКО метаданные (например, определение ALL_OBJECTS), программный код (такой как код для DBMS_OUTPUT) необходимый для работы самого движка Оракл. Здесь отсутствуют данные бизнес-приложения. База данных является обособленной в том смысле, что она может быть смонтирована и открыта без дополнительных поддерживающих физических структур.

Подключаемая (pluggable) база данных. Это набор одних лишь файлов данных. Такая база данных не является обособленной. Чтобы появилась возможность открытия и доступа, подключаемая база данных должна быть " вставлена" в контейнерную базу данных. Файлы данных содержат только метаданные для объектов бизнес-приложений, данные приложений и код для приложений. 

Рис. 2. Схема экземпляра и базы данных (multitenant database).

Плюсы подключаемых БД

1.Для заметного уменьшения объема ресурсов, необходимых при размещении многих баз данных — многих приложений — на единственном хосте

2.Для сокращения объема работ по обслуживанию, выполняемых администратором баз данных в отношении множества баз данных — множества приложений — на единственном хосте.

3.С точки зрения разработчика подключаемая база данных ничем не отличается базы с единственным владельцем.

Основные типы файлов

1. Файлы данных (data file). Эти файлы предназначены для базы данных: они хранят таблицы, индексы и все остальные сегменты.  

2.Временные файлы (temp file). Эти файлы используются для выполнения дисковых сортировок и в качестве временного хранилища. 

3.Управляющие файлы (control file). Эти файлы указывают местоположение файлов данных, временных файлов, журнальных файлов повторения действий (файлов с измененными данными), а также содержат другие важные метаданные об их состоянии. 

4.Журнальные файлы повторения действий (redo log file). Эти файлы представляют собой журналы транзакций. Основное назначение: восстановления данный после сбоя, например аварийного выключения питания. Дополнительное: используются при обслуживании резервных копий, в Goden Gate. Как обслуживаются журналы транзакций-это отдельная интересная тема, рассмотрим ее позже. 

Прочие файлы:

1.Файлы параметров (parameter file). Эти файлы указывают экземпляру базы данных Oracle, где искать управляющие файлы, а также задают набор параметров инициализации, которые определяют размеры ряда структур памяти и т.д. Например tnsname.ora, listener.ora, spfile<ORACLE_SID>. ora и init.ora  (файл параметров БД)

2.Трассировочные файлы (trace file). Эти диагностические файлы создаются процессом сервера по большей части в ответ на возникновение некоторых необычных ошибок. Являются источником отладочной информации.

3.Сигнальный файл (alert file). Этот файл подобен трассировочным файлам, но содержит информацию об «ожидаемых» событиях, а также служит единым централизованным файлом для хранения оповещений администратора базы данных о многих событиях, связанных с базой данных. 

4.Файлы паролей (password file). Эти файлы применяются для аутентификации пользователей(SYSDBA, SYSOPER), выполняющих административные действия. 

Из всех перечисленных файлов наиболее важными являются файлы данных и журнальные файлы повторения действий, т.к. они содержат  бизнес-данные. Утеря любых или даже всех остальных файлов не приведет к безвозвратной утрате данных. Утеря журнальных файлов может привести к потере некоторых данных. Утеря файлов данных и их резервных копий неизбежно приведет к безвозвратной потере данных.

Логическая и физическая структура данных

Логическая структура введена для удобства управления. База данных может состоять из одного или большего числа табличных пространств. 

Рис. 3. Логическая и физическая структура Oracle Database.

Табличное пространство

Табличное пространство содержит в себя сегменты. Логически группирует физические файлы на диске.  Табличное пространство является точкой соединения логической и физической структуры.

Табличное пространство данных бизнес приложения

CREATE TABLESPACE userdata
  DATAFILE #ff0000;">'data/file_userdata_01.dbf' 
    SIZE 500M  -- начальный размер
    AUTOEXTEND ON 
    NEXT 10M 
    MAXSIZE 1000M 
  EXTENT MANAGEMENT LOCAL;

Временное табличное пространство

CREATE TEMPORARY TABLESPACE temp01 DATAFILE #ff0000;">'temp/temp01.dbf';

Табличное пространство для хранения информации отмены

CREATE UNDO TABLESPACE undo01 DATAFILE #ff0000;">'undo/undo01.dbf';

Сегмент, экстент, блок данных

Сегмент (таблица, индекс, партиция и т.д.) формируется одним или большим количеством экстентов. 

Экстент – состоит из непрерывистого набор блоков на диске. Расширение пространства  в сегменте происходит экстентами.

Блок — это наименьшая единица данных в базе данных. Блок является наименьшим элементом ввода-вывода, используемым базой данных при взаимодействии с файлами данных.

Рис. 4. Структура блока данных Oracle Database.

Рис. 5. Структура блока данных Oracle Database.

Экземпляр – основные структуры памяти и процессы

Рис. 6. Схема экземпляра и базы данных с детализацией.

Структура памяти

Глобальная область системы (System Global Area — SGA). Это большой совместно используемый сегмент памяти, к которому в тот или иной момент времени будут обращаться практически все процессы Oracle. Выделяется при старте, обслуживает экземпляр Oracle.

Глобальная область процесса (или проrраммы) (Process (Prorgam) Global Area PGA). Это закрытая область отдельного процесса или потока; из других процессов или потоков она не доступна. Создается в режиме выделенного сервера. Содержит области памяти для хранения информации о сеансе, а также области для сортировок.

Глобальная область пользователя (User Global Area — UGA). Эта область памяти связана с конкретным сеансом. Она располагается либо в области SGA (если подключение к базе данных выполнено посредством разделяемого сервера), либо в области PGA (если подключение к базе данных осуществлено через выделенный сервер).

Структура памяти SGA

1.Разделяемый пул (Shared Pool) состоит из:

• Библиотечного кеша (library cache) – содержит информацию о последних выполненных операторах SQL и PL/SQL (план разбора, откомпилированные процедуры и функции и пр)
• Кеша словаря (data dictionary cache)  — сдержит информацию о определениях объектов базы данных (нужно для синтаксического разбора для получения метаданных о запрашиваемых объектах)

2.  Буферный кеш Buffer Cache. Буферный кеш содержит блоки данных, запрошенные пользователями. Дает большой выигрыш в производительности т.к. позволяет избежать обращений к диску. Работает по принципу LRU (самые горячие блоки живут дольше).Каждый блок запрошенный или измененный пользователем сперва помещается в буферный кеш (кроме CREATE T ABLE AS). Состоит из трех независимых подкешей, определяемых параметрами:

        DB_CACHE_SIZE – основной размер кеша

        DB_KEEP_CACHE_SIZE – данных, которые принудительно запихнули в кеш, часто-используемые блоки.

        DB_RECYCLE_CACHE_SIZE – для редко-используемых блоков, которые после использования сразу могут быть удалены из кеша

3. Журнальный кеш(Redo log buffer cache). Журнальный кеш перезаписывается по кругу. Содержит изменения, которые происходят во время транзакции и сбрасываются потом в файлы журнала повтора.

4. Большой пул (Large Pool). Большой пул необязательная область. Содержит области памяти, которые без него сдержались бы в SGA и тем самым снимает нагрузку. Например, используется для хранения области UGA в режиме разделяемого сервера. Используется RMAN-ом.

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

Каждый процесс в Oracle выполняет отдельную задачу или набор задач, и каждый из них имеет внутреннюю память (память PGA), выделенную им для выполнения своего задания.

FOREGRAUND – процесс обслуживающий пользователей (серверный процесс)

BACKGRAUND – процессы самого движка Oracle (фоновые процессы)

Основные фоновые процессы BACKGRAUND.

PMON — очищает ресурсы после сбоев процессов. Откатывает транзакции пользователя, снимает блокировки, перезапускает сбойнувшие диспетчеры.

SMON — восстанавливает базу после сбоев. Накатывает успешные транзакции, либо откатывает незавершенные транзакции. Выполняет также объединение пирлегающих свободных экстентов и освобождает пространство временных сегментов.

DBWn — означает №. Т.е. их может быть несколько. Сбрасывает измененные блоки из кеша буферов в базу данных при заполнении кеша, либо срабатывании контрольной точки и др. событиях. Обновляет контрольную точку в контрольных файлах.

LGWn — пишет буфера из кеша буферов в журналы при фиксации транзакции, а также через каждые 3 секунды, а также если журнальный буфер заполнен более чем на 1/3 либо >1 Мб. Всегда срабатывает перед DBWn и даже может его вызывать.  Успешная запись подтверждает успешную транзакцию.

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

Посмотреть фоновые процессы можно запросом:

SELECT paddr, name , description FROM v$bgprocess  ORDER bу paddr DESC;

Или

SELECT * FROM v$PROCE t WHERE t.РNАМЕ IS NULL;

Прочие фоновые процессы BACKGRAUND:

ARCn — процесс архивирования журнальный файлов.

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

Dnnn -  диспетчер в многопотоковом сервере.

Pnnn — подчиненные процессы параллельного сервера.

Тезисы, которые надо запомнить:

1.Экземпляр может монтировать и открывать только одну базу данных (с единственным владельцем или контейнерную) в каждый момент времени.

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

3.База данных может обслуживаться несколькими экземплярами. В таком случае мы получаем RAC ( Real Application Clusters). 

Подключение к Oracle

Основной протокол, по которому происходит подключение к Oracle является TCP/IP.

1.Каждый клиент(любое клиентское приложение), который хочет подключиться к Oracle, создает пользовательский процесс и пробует подключиться использую host + port + sid.

2.Подключение происходит через посредника – LISTENER. Именно он принимает запрос на подключение и соединяет нас с серверным процессом базы данных.

Рис. 7. Место LISTENER-а в схеме подключения.

3.Для каждой новой сессии Oracle создает серверный процесс (есть нюансы), который и будет обслуживать запросы пользовательского процесса.

Сеанс и подключение

В терминологии Oracle: подключение — это не синоним сеанса.

1.Физический канал связи между клиентом и сервером – это подключение.

2.Oracle NET – протокол по которому связывается процесс клиента с процессом сервера. 

3.Сеанс(session)  — это логическая идентификация запросов конкретной сессии. 

4.В рамках одного подключения может быть 0 и более сеансов.

Демонстрация общего примера подключения

Рис. 8. Этапы подключения на примере SQLPLUS.

Виды подключения

DEDICATED – подключение (выделенный сервер). При таком подключении на один сеанс создается персональный серверный процесс. Он обслуживает этот сеанс от начала и до конца, ни на какие другие сеансы не переключается, т.е. выделен под этот сеанс. После того как сеанс завершен, серверный процесс тоже завершается. Такой способ подключения обычно используют в случае когда мало клиентов и время ожидания отклика некритично (например OLAP — системы).

Рис. 9. Схема подключения с выделенным сервером — DEDICATED.

SHARED — подключение (разделяемый сервер). При таком подключении создается пул серверных процессов (далее разделяемый сервер) и появляется диспетчер процессов. Клиентский процесс здесь обмениваться данными с диспетчером. Диспетчер помещает запрос клиента в очередь запросов внутри области SGA. Первый незанятый разделяемый сервер примет этот запрос и обработает его (например, запросом мог бы служить UPDATE т S ET Х=Х+5 WHERE У=2 ). По завершении этой команды разделяемый сервер поместит ответ в очередь ответов вызывающего диспетчера. Диспетчера будет отслеживать эту очередь и, обнаружив результат, переправит его клиенту. Такой тип систем применим к OLTP системам.

Рис. 10. Схема подключения с разделяемым сервером — SHARED.

Резидентный пул соединений с базой данных (DRCP — Database Resident Connection Pooling). Новый режим соединения (появился в 11g), который объединяет в себе преимущества выделенного и разделяемого сервера. Суть сводится к тому, что заранее создает пул серверных процессов и каждому подключению выделяется свободный процесс в режиме выделенного сервера.

Запросом можно посмотреть тип подключения:

SELECT username , sid, serial#, server, paddr , STATUS FROM v$session WHERE username = USER;

Отключение пользователя

1.Команда DISCONNECT.

2.ALTER SYSTEM KILL SESSION ‘SID,SERIAL#’ помечает сессию на удаление. Все транзакции откатываются. Сессия живет пока все не откатится.

3.ALTER SYSTEM DISCONNECT SESSION ‘SID,SERIAL#’ IMMEDIATE немедленное отключение сессии. За ней потом приберет PMON.

Системные представления

• DBA_TABLESPACES – информация о ТС
• DBA_DATA_FILES – инф. о файлах данных
• DBA_SEGMENTS – инф. о сегментах

• V$VERSION – инф. о версии ПО
• V$INSTANCE – инф. о экземпляре
• V$DATABASE – инф. о БД
• V$PROCESS – инф. о процессах
• V$SESSION – инф. о сессиях

и много других здесь:

SELECT * FROM dictionary;