Автор: oracledb_ru

 Single-Instance архитектура

Oracle server это экземпляр БД подключенный к БД

Экземпляр БД – это область разделяемой памяти и набор процессов

БД – это набор файлов на диске

Пользовательская сессия – это пользотельский процесс соединённый с серверным процессом

Структуры памяти экземпляра БД

Разделяемая (общая) память называется system global area (SGA)

Неразделяемая (частная) память сессий – это program global area (PGA)

SGA состоит из подсруктур, часть из которых обязательные (кэш буфера БД (database

buffer cache), буфер логов, разделяемая область (shared pool)) и которые необязательные (large pool, Java pool, Streams pool)

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

Процессы экземпляра БД

Серверный процесс (для сессии) запускается когда пользователь подключается

Фоновые процессы запускаются когда стартует экземпляр БД и существуют до его остановки

Серверные процесс ы читают информацию из БД; фоновые процессы записывают изменения в БД

Некоторые фоновые процессы писутствуют во всех серверах БД (SMOM, PMON, DBWn, LGWR, CKPT и MMON); остальные будут или не будут запущены в зависимости от найстроек сервера

Структуры хранения БД

Существуют три необходимых типа файлов в БД: controlfile, online redo log файлы и файлы данных

Controlfile хранит ограничители целостности и указатели для работы со всей БД

Online redo log файлы содержат последние вектора изменений (change vectors)

Сами данные хранятся в файлах данных

Дополнительные файлы как файл параметров запуска (parameter file pfile and spfile), файлы паролей, архивные логи (archive redo logs) и log and trace файлы.

Логические структуры (segment-ы) асбтрагированы от физической информации на диске (файлов данных) с помощью понятия табличное пространство (tablespace)

Табличное пространство может включать в стебя много файлов данных

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

Сегменты могут храняться в нескольких различных файлах данных

БД Oracle предоставляет полностью независимое определение логических и физических структур данных. Логическим элементом данных является сегмент. Существуют различные виды сегментов; типичным примером является таблица. Сегменты физически хранятся в файлах данных. Разделение физического и логического представления данных осуществляется путём ввода понятия tablespace. Связь физических и логических представлений хранится в словаре данных.

Физические структуры БД

Существуют три основных типа файлов из которых состоит БД Oracle, плюс дополнительные файлы которые хранятся отдельно от БД и грубо говоря не необходимы. Необходимые файлы это файл управления (controlfile), файл логов (online redo log files) и файлы данных. Дополнительные файлы которые обычно присутствуют (существуют ещё другие для дополнительной настройки) это файл параметров инициализации, файл паролей, архив логов и т.п.

Файл контроля / Controlfile

Разберёмся с терминологией: кто-то говорит что у БД может быть несколько controlfile-ов, а другие утверждают что файл один, который может иметь несколько копий. Мы придержимся последнего определения, так как согласно Oracle “multiplexing control files” означает именно возможность иметь копии.

Controlfile – файл небольшого объёма, но он жизненно важный. Внутри содержатся указатели для всей БД: место online redo log-а, файлов данных, критически важную системную информацию для обеспечения целостности ( значение sequence и timestamp). Размер файла обычно не превышает несколько мегабайт но БД не существует без этого файла.

У каждой БД есь один controlfile, но хороший DBA всегда будет создавать копии файла, чтобы в случае проблем с какой либо копией всегда можно было быстро восстановить систему. Если все копии утеряны, то теоретичеески можно попробовать восстановить базу, но лучше никогда не попадать в такую ситуацию. Oracle сервер сам синхронизирует controlfile-ы – задача DBA решить сколько копий необходимо и где их хранить.

Если вы в момент создания базы данных не указали количество или путь – это можно изменить после, но потребует включения выключения БД, так что лучше планировать заранее. Нету определенного значения сколько копий делать, минимум – один файл, максимум – восемь. Проблемы с любой копией controlfile приводят к немедленной остановке экземпляра БД.

Файлы логов / Online redo log files

Redo log – это набор хрогологически упорядоченных записей, об изменениях в БД. Это минимально необходимое количество информации, которая необходима чтобы восстановить все действия, которые совершались над БД. Если файлы данных пропали или удалены, эти записи изменений могут быть использованы чтобы повторить все действия с определенной точки времени до момента возникновения ошибки над резервной копией файлов данных. Этот лог может состоять из двух типов файлов: online redo log файлы (необходимые файлы для работы БД) и archive log файл-ы (которые не обязательны для работы, но необхоидмы для восстановления данных к точке времени).

У любой БД есть минимум два online redo log файла, но как и в случае с controlfile-ом, хороший DBA создаёт копии каждого файла. Online redo log состоит из групп файлов, каждый файл в которой называется member. У БД Oracle должно быть минимум две группы, состоящие минимум из одного member для работы. Вы можете создать больше чем две группы для улучшения производительности, и больше чем один member для сохранности данных. Две группы минимум нужны для того, чтобы в одну писать текущие изменения, а другую можно было в это время использовать для создания архивной копии.

Одна из групп в момент времени является текущей (current group) – в неё LGWR будет записывать изменения из буфера логов. В момент времени когда файлы группы заполнятся – LGWR совершит так называемую операцию log switch. Вторая группа становится текущей и LGWR начинает писать данные в файлы второй группы, и, если у вас настроен archive log mod, ARCn сделает резервные копии файлов первой группы. Когда вторая группа заполнится, LGWR опять сделает текущей первую группу а ARCn сделает резеврную копию второй группы. Таким образом группы redo log работают по кругу и каждая операция log switch создаёт файл архивного лога.

Так же как и для controlfile, если у вас настроено несколько файлов в группе (желательно иметь несколько копий!) не нужно никаких дополнительных настроек для их синхронизации и т.п. LGWR сам запишет во все копии в параллели одинаковую информацию. Если к примеру какая-либо копия на каком либо диске оказалась недоступна – до тех пор пока есть хотя бы одна копия – БД может нормально функционировать.

Размер и количество груп – задача оптимизации БД. В общем, необходимо выбирать значения в зависимтости от активности работы с БД. Минимальный размер – пятьдесят мегабайт, но активно используемые БД с большим количество пользователей могут использовать файлы размером до нескольких гигабайт. Количество копий файлов в группе – вопрос какой уровень отказоустойчивости вы хотите достигнуть. В любом случае – задание этих параметров не критично на этапе создание БД, так как они могут изменять в режиме «онлайн» — без перезагрузки экземпляра БД.

Файлы данных / Datafiles

Третий тип необходимых файлов для работы это файлы данных. Как минимум требуется два файла, которые создаются в момент созданий БД.  До версии 10g – можно было создать базу с одним файло – после создаются два файла, по одному для табличного пространства SYSTEM и SYSAUX. Как бы то ни было, в рабочей базе будет больше файлов.

Файлы данных – это хранилище для данных. Их размер и количество неограниченны. Маленькие БД размером в несколько гигабайт могут состоять из пол-дюжины файлов, каждый размером в несколько сот магабайт. Большие БД могут состоять из тысяч файлов, размер которых ограничен только возможностями ОС и аппаратным обеспечением.

Файлы данных с физической точки зрения – это системные файлы, которые видят системные администраторы. Логическая же структура файлов данных, это хранилище сегментов (segments) в которых хранятся пользовательские данных и логическая структура доступна программистам, а также сегментов словаря данных. Сегмент – это структура хранения для данных; типичные сегменты это таблицы и индексы. Файлы данных могут быть переиенованы, перемещены, удалены, добавлены в любое время жизни БД. Но важно помнить что некоторые операции требуют перезапуска экземпляра БД.

С точки зрения ОС, файлы данных состоят из набора блоков операционной системы. Внутри файлов, они отформатированы на Oracle блоки (blocks). Эти блоки последовательно пронумерованы внутри каждого файла. Размер блока фиксирован и в большинстве случаев будет одинаковым для всей БД. Выбор размера блока задача для оптимизации. Допустимы значения от 2КБ до 64КБ. Нет взаимосвязи между размерами системных блоков и блоков Oracle.

Многие DBA используют одинаковый размер системного блока и Oracle блока. С точки зрения производительности системный блок не должен быть больше чем блок Oracle. Однако ничто не мешает системному блоку быть меньше чем блоку Oracle. К примеру системный блок в 1Кб и блок Oracle размеров в 8КБ вполне допустимая конфигурация.

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

Когда пользовательскйо сессии необходимо работать с данными из блока, серверный процесс находит блок с нужными данными на диске и копирует этот блок в свободный буфер в database buffer cache. Если затем данные изменяются – в какой-то момент времени DBWn запишет этот блок обратно на диск.

Желательно регулярно делать копии файлов данных. В отличие от controlfile и redo log файлов, Oracle не поррерживает копии файлов данных (хотя вы можете построить RAID массив или использовать другие аппаратные возможности и возможности операционной системы). Если файлы данных повреждаются, они могут быть восстановлены из архивной копии и затем recovered (recovered  — означает что к копии файлов данных будут применены изменения из redo log).

Логические структуры БД

Физические структуры БД есть ни что иное как системные файлы. Пользователи видят логические структуры, такие как таблица. Oracle использует термин segment для описания любой структуры, которая содержит данные. Типичный сегмент – это таблица, состоящая из строк данных, однако существует ещё более 12 возможных типов используемых в Oracle. Нас интересуют таблицы, индексы и UNDO сегменты. Таблица содержат собственно данные, индексы используются для быстрого доступа к конкретным данным, UNDO сегменты используются для хранения временной информации, изменений которые могут быть отменены.

Oracle позволяет абстрагировать физичесую структуру от логической путём ввода понятия табличное пространство (tablespace). Tablespace – логически это коллекция одного или несколько сегментов, а физически коллекция одного или нескольких файлов данных. В терминах реляционной алгебры – мы видим отношение многие-ко-многим между сегментами и файлами данных: одна таблица может находиться в разных файлах даных, и, с другой стороы, в одном файле данных может находиться много таблиц. Путём добавления понятия «табличное пространство» — Oracle управляет этими отношениями.

Несколько сегментов создаются во время создания БД: это сегменты которые составляют словарь данных. Эти сегменты хранятся в двух табличных пространствах SYSTEM и SYSAUX. SYSAUX появилось только после версии 10g: в прошлых весь словарь данных хранился в табличном пространстве SYSTEM. Процесс создания обязательно создаст минимум два табличных пространства с минимум одним файлом данных в каждом, для хранения словаря данных.

Сегмент состоит из блоков. Файлы данных также отформатированных с использованием блоков и блоки из файла данных назначаются к сегментам по мере роста последних. Управление дисковым пространством по одному блоку – было бы сильно затратным занятием, поэтому блоки группируются в extent-ы. Extent – это группа последовательных блоков в файле данных, и размер сегментов будет увеличиваться на размер extent-а. Extent-ы для одного сегмента не  обязательно должны быть рядом в файле и вообще даже могут находиться в разных файлах, но файлы должны прнадлежать табличному пространству этого сегмента.

Рисунок 1-8 отображает отношения структур Oracle с отделением логических структур от физической. Табличное пространство может содержать множество сегментов, каждый из которых состоит из extent-ов. Extent – это набор блоков Oracle. Файл данных состоит из блоков операционной системы. Как итог табличное пространство состоит из множества файлов данных и блок Oracle состоит из одного или нескольких блоков операционной системы.

Словарь данных

Словарь данных хранит метаданные описывающие логическую и физическую структуру БД и её содержимое. Информация о пользователях, пароли, ограничения целостности и (начиная с 10g) информация о производительности – всё это хранится в словаре данных. Эти данные хранятся в виде набора сегментов в табличных пространствах SYSTEM и SYSAUX.

В целом, сегменты составляющие словарь данных такие же как и остальные сегменты – обычные таблицы и индексы. Главное отличие – эти сегменты создаются в момент создания БД и нет прямого доступа к информации в них. Конечно ничто не может остановить DBA от прямого доступа в словарь данных – однако их любое изменение может привести к разрушению БД.

Управление словарём данных осуществляется командами DML.  Когда вы выполняете команду CREATE TABLE – на самом деле осуществляется вставка строк в таблицы словаря данных. Точно такое же механизм работы у команд CREATE USER и GRANT и т.д.

Для просмотра словаря данных Oracle предоставляет определённый набор представлений (view). Большинство из них начинаются с префикса DBA_, ALL_ или USER_. Все представления начинающиеся с USER_ будут отображать объекты БД принадлежащие текущему пользователю. Если пользователь JOHN будет простматривать представление USER_TABLES он увидит только те таблица, которые принадлежат ему. Таким образом никогда два пользователя не увидят одинаковой информации. Представления начинающиеся с ALL_ отображают информацию об объектах к которым у текущего пользователя есть доступ – то есть все объекты которые во создали плюс объекты к которым есть соответсвующее разрешение. Представления с префиксом DBA_ отображают информацию о всех объектах БД. Если вы просмотрите DBA_TABLES – то увидите строку для каждой таблицы, не важно кто создал её. Эти представления создаются в момент создания БД, а также генерируется большое количество PL/SQL пакетов. Эти пакеты предоставляются Oracle в помощь администраторам и разработчикам. PL/SQL код также хранится в словаре данных.

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

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

Background process-ы экземпляра запускает при запуске инстанса и работают до его выключения. Пять процессов, которые существуют очень давно: Sysmte Monitor (SMON), Process Monitor (PMON), Database Writer (DBWn), Log Writer (LGWR) и Checkpoint process (CKPT). Другие процессы добавлены не так давно, достойны внимания Manageability Monitor (MMON) и Memory Manager (MMAN). Другие не основные процессы которые будут запущены в большинстве экземпляров БД это Archiver (ARCn) и Recoverer (RECO). Так же некоторые процессы будут запущены только если включить определенные надстройки. Ещё группа процессов предназначения для управления RAC и Streams. Так же существуют процессы которые не имеют описания.

На рисунке 1-6 можно увидеть пример типичного взаимодействия процессов и обалсти памяти SGA. Под сервер процессом подразумевается клиент-серверное соединение, где клиентская часть состоит из пользовательской сессии и пользовательского процесса. Серверный процесс взаимодействует с файлами данных, для записи данных в buffer cache. Потом путем выполнения DML команд данные могут быть изменены в buffer cache. Векторы изменений копируются в буфер логов, откуда LGWR процесс в режиме почти реального времени записыват инфомрацию в журнал. Если режим архивирования настроен, то Archiver (ARCn) копирует журнал в место для резервных копий. Данные могу записаться из грязных блоков buffer cache в файлы данных DBWn процессом.

В засисимости от платформы есть разница в организации процессов. На linux/unix подобных операционныз системах, все процессы являются отдельными системными процессами. В Windows создаётся всего один системный процесс, внутри которого отдельными потоками (threads) работают процессы Oracle.

SMON (системный монитор)

Основной задаче этого процесса является «подключение» (mounting) и «открытие» базы данных. Более подробно этот процесс описан в части 3. Вкратце, SMON «подключается» используя файл управления (control file). Затем «открывает» базу для работы путём поиска и проверки всех файлов данных и файлов журнало изменений. Как только база запущена, SMON ответственен за разные задачи к примеру за объединение пустого места в файлах данных.

PMON (process monitor)

Пользовательская сессия это пользовательский процесс подключенный к серверному процессу. Серверный процесс запускается когда сессия создается и уничтожается когда сессия заканчивается. Обычное завершение сессии влючает в себя выход пользователя. Когда это происходит, серверный процесс будет аккуратно завершён. Если сессия прерывается «неожиданным» образов (например пользовательский компьютер перезагрузился), то сессия остаётся «висеть» в памяти и должна быть как-то закрыта. PMON смотрит за всеми серверными процессами и ищет «висящие» сессии. Если найдена такая сессия, PMON остановит серверный процесс, вернёт PGA память операционной системе и отменит все наподтверждённые операции пользователя.

DBWn (Database Writer)

Всегда надо помнить что сессии не работают с информацией на диске. Они работают с данными в buffer cache. А уже database writer в дальнейшем записывает информацию из buffer cache на диск. Database writer процессов может быть несколько (максимально 12) которые будут называться DBW0, DBW1 и т.д. Отсюда в сокращении буква n в конце. По умолчанию один database writer на 8 процессоров.

Сколько DBW необходимо? Обычно используется значение по умолчанию. Изменение значения может повысить производительность но сначала надо оптимизировать использование памяти. Примите за правило, если есть необходимость оптимизации операций чтения/записи, необходимо понять в чём необходимость этих операций.

DBW-ы записывают «грязные» буфферы из буфера базы данных в файлы данных – но не обязательно в момент времени когда произошли изменения. Напротив: записывается минимально возможное количество изменений. Основная идея почему так сделано в том, что операция чтения записи низкопроизводительны, поэтому не стоит их выполнять до тех пор, пока в этом нет необходимости. Если данные были изменены сессией, есть вполне вероятная возможность что эти данные будут использованы снова, этой или другой сессией. Зачем записывать данные на диск, если они могут быть использованы снова в ближайшем будущем? Алгоритм DBW выбирает только те «грязные» блоки для записи на диск, которые давно не использовались. Таким образом если буффер используется сессиями для чтения или изменения данных, он не будет записываться на диск. Сотни и тысячи операций могут использовать буфер пока DWB не запишет информацию на диск (сделает буфер «чистым»). В буфер кэше может быть миллион буфферов, сто тысяч из них «грязные» — но только пару сотен из них DBW запишет на диск. Это будут буферы которые не использовались в последнее время.

Алгоритм работы DBW реализован по принципам: записывать минимально возможный объём изменений, как можно реже. Существует четыре обстоятельства которые заставляют DBWn записывать данные на диск:

• Отсутствие пустых буферов
• Слишком много «грязных» буферов
• Трехсекундный таймаут
• Контрольная точка

Для начала рассмотрим ситуация когда нет свободных буфферов. Когда серверному процессу необходимо скопировать блок данныз из файла данных в ауфер кэш – для начала он должен найти свободный буфер.Свободный буфер это буфер который не «грязный» (данные изменены и не записаны на диск) и не используемый (используемый буфер это буфер который используется другой сессией в данный момент). «Грязный» буфер нельзя использовать потому что в случае перезаписи будут утеряны данные, используемый буфер не даст использовать системный механизм работы с памятью. Если серверный процесс тратит очень много времени для поиска свободного буфера (этот интервал определяется Oracle сервером), то он посылает сигнал DBWn, что нужно записать данные на диск. Когда DBWn запишет данные из буферов, они станут чистыми, свободными и доступными для использования.

Второй случай – когда слишком много грязных буферов. Слишком много – это тоже внутреннее понятие Oracle сервера (нельзя влиять на это значение). Если у серверных процессов нет проблем со свободными буферами, но общее количество «грязных» буферов слишком велико – это тоже приведёт к записи DBWn какого-то количество буферов на диск.

Трехсекундный таймаут: каждые три секунды DBWn будет чистить какое-то количество буферов. На практике этого может и не случаться так как первые два пункта будут вызывать запись, но этот таймаут значит что если три последние секунды система бездействовала и есть «грязные» буферы, то это буферы будут очищаться.

И наконец, контрольная точка. Все описанные выше случаи приведут к тому что только частично данные из буфера запишутся в файлы данных. Когда создаётся контрольная точка – все «грязные» буфферы очищаются. Во время создания контрольной точки, I/O могут загрузить сервер польностью, использование CPU достигает 100%, пользователи ощущают падение производительности и люди могут начать жаловаться. После завершения (что может занять несколько минут), производительность вырастает назад. Так зачем использовать контрольные точки? Ответ на этот вопрос простой, не используйте их, пока в этом нет необходимости.

Единственный момент времени когда контрольная точка необходима – это остановка базы данных – мы рассмотрим этот процесс детальнее чуть позже. Контрольная точка запустит процесс который запишет все буферы на диск – синхронизирует буфер кэш и файлы данных. Во время работы эксемпляра БД, файлы данных всегда содержат не последнюю инфомрацию. Это не имеет значения так как вся работа осуществляется с буфером. Во время выключения экземпляра, необходимо записать всю информацию на диск. Автоматические контрльные точки создаются только при остановке, но так же их можно создать командой

 

ALTER SYSTEM CHECKPOINT;

Такая контрольная точка называется full checkpoint. Частичные контрольные точки создаются более часто: они сигналят DBWn очистить буферы которые содержат информацию из одного или нескольких файлов данных, а не всей базы данных.

LGWR, Log Writer

LGWR записывает информацию из буфера логов в файл лога на диске. Этот процесс часто называют flushing log buffer. Когда сессия изменяет данные (выполняются команды INSERT, UPDATE, DELETE) в блоках буфера, перед тем как изменить данные вектор изменений записывается в буфер логов. Чтобы избежать потери данных, эти вектора изменений должны быть записаны на диск максимально приближенно к режиму реального времени. А когда сессия выполняет комманду COMMIT – LGWR запишет вектор изменений в реальном времени: сессии будут ждать пока LGWR запишет информацию из буфера на диск. Только после этого транзация записывается как подтверждённая (commited). LGWR — это самое узкое место в архитектуре Oracle. Невозможно выполнять DML команды быстрее чем LGWR записывает векторы изменений на диск. Существует три ситуации которые вызовут очистку буфера логов: команда COMMIT, заполнение буфера логов больше чем на треть, DBWn собирается записать данные на диск.

Запись по команде COMMIT. Чтобы обработать команду COMMIT серверный процесс записывает данные в лог буфер. Потом процесс ждёт пока LGWR запишет данные из буфера логов на диск. Только когда запись успешна – серверный процесс может продолжать свою работу. Этот процесс гарантирует, что данные не будут потеряны: любое подтверждённое изменение (COMMITED) имеет записанный на диск вектор изменений и может быть восстановлено путём исполнения этих изменений на восстановленную копию файла данных.

Вторая ситуация когда записывается лог – это заполнение буфера на одну треть. Это делается для увеличения производительности. Если буфер логов маленький (а он обычно должен быть небольшой) тогда заполнение на одну треть будет заставлять LGWR записывать векторы изменений на диск почти в режиме реального времени даже если никто не выполняет команду COMMIT. Размер буфера логов для большинства приложений должен быть несколько мегабайт. Работа с базой будет приводить к тому что такой буфер будет быстро заполняться на одну треть за долю секунды и LGWR будет вынужден записывать векторы изменений постоянно, почти в режиме реального времени. Далее когда пользователь выполнит команду COMMIT будет очень мало информации для записи и команда COMMIT отработает практически мгновенно.

И третья ситуация наступает когда DBWn должен записать данные из кэша буфера в файлы данны. Перед этим DBWn посылает сигнал LGWR очистить буфер логов. Это необходимо для того, чтобы была возможность отменить неподтверждённые транзакции. Неподтверждённые изменения данных могут быть записаны в файлы данных. Это нормально пока у нас гарантированно есть вектора изменений чтобы отменить эти изменения.

CKPT, Checkpoint Process

Итак, когда приложение запрашивает данные, база складывает их в буферный кэш — область памяти в SGA. Когда данные изменяются, база производит изменения не непосредственно в файле данных, а в буферном кэше. Одновременно в отдельную область памяти — redo log buffer — записывается информация, по которой, в случае необходимости, можно будет повторить произошедшее изменение. Когда изменение фиксируется (commit), оно, опять же, не сбрасывается сразу в файл данных, но информация из redo log buffer сбрасывается в online redo лог — специально для этого предназначенный файл. До тех пор, пока изменение не записано в файл данных, необходимо хранить информацию о нём где-то на диске на тот случай, если база упадёт. Если, к примеру, выключится питание сервера, то, само собой, все данные, хранящиеся в памяти, будут потеряны. В этом случае redo лог — это единственное место, где хранится информация о произошедшем изменении. После рестарта базы Oracle фактически повторит прошедшую транзакцию, вновь изменит нужные блоки и сделает commit. Поэтому до тех пор, пока информация из redo лога не будет сброшена в файл данных, повторно использовать этот redo лог невозможно.
Специальный фоновый процесс базы данных DBWn по мере необходимости освобождает буферный кэш, а также выполняет событие контрольной точки (checkpoint). Контрольная точка — это событие, во время которого «грязные» (изменённые) блоки записываются в файлы данных.

За событие контрольной точки отвечает процесс CKPT (checkpoint process), который и пишет информацию о контрольной точке в control file (о том, что такое control file, чуть ниже) и заголовки файлов данных. Событие контрольной точки обеспечивает согласованность данных и быстрое восстановление базы. Восстановление данных ускоряется, т.к. все изменения до контрольной точки пишутся в файлы данных. Это избавляет от необходимости во время восстановления применять redo логи, сгенерированные до контрольной точки. Контрольная точка гарантирует, что все изменённые блоки в кэше действительно записаны в соответствующие файлы данных. Существует несколько видов контрольных точек.

Потоковые контрольные точки (thread checkpoins). В файл данных пишутся подряд все изменения, произошедшие в рамках определённого экземпляра до определённого момента. Случаются они в следующих ситуациях:

• полная остановка базы;
• altersystemcheckpoint;
• переключение online redo лога;
• alter database begin backup.

Контрольные точки файлов данных и табличных пространств. Случаются, когда происходят операции с табличными пространствами и файлами данных (alter tablespace offline, alter tablespace read only, ужатие файла данных и.т.п.)

Инкрементальные контрольные точки. Подвид контрольной точки экземпляра, предназначенный для того, чтобы избежать записи на диск огромного количества блоков во время переключения redo логов. Процесс DBWn как минимум раз в три секунды проверяет, появились ли новые «грязные» блоки для записи на диск. Если появились, то они заносятся в файлы данных, метка контрольной точки в redo лог сдвигается (чтобы в следующий раз пришлось просматривать меньше логов), но заголовки файлов данных при этом не изменяются.

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

MMON, Manageability Monitor

MMON — это процесс, который появился после версии 10g, и он позволяет использовать различные функции мониторинга и оптимизации системы. Инстанс собирает различную статистику о работе с БД и производительности. Эти данные хранятся в SGA и текущие значения можно посмотрить используя SQL запросы. Для оптимизации производительности, исторического анализа и анализа тренда изменений надо эти значения сохранять на протяжении отрезка времени. MMON регулярно (по умолчанию каждый час) сохраняет значения из SGA в словарь данных, где эти данные могут храниться бесконечно (по умолчанию хранятся последние восемь дней).

Каждый раз при сохранении набора статистических данны (такой набор называют snapshot), MMON также запускаем Automatic Database Diagnostic Monitor (ADDM). ADDM – это иснтрумент анализа работы БД с помощью, разрабатываемый на протяжении многих лет различными DBA. Он сравнивает два snapshot-а (текущий и предыдущий) и на основании анализа предлагает рекомендации по настройке БД.

Помимо сохранения данных и запуска ADDM, MMON также следит не произошли ли какие-нибудь системные события, о которых надо уведомить DBA.

ARCn, Archiver

Все записи об изменениях данных в буфере записываются в буфер логов и затем на диск процессом LGWR. Количество и разимер этих логов фиксированны. Когда они заполняются, LGWR будет перезаписывать их новой информацией. Это значит что только последние изменения будут доступны. Чтобы сохранить полную историю – файлы логово (online redo logs) необходимо скопировать перед тем как перезаписывать. Этим занимаются процессы ARCn. Если у нас есть эти копии (archive redo logs) то мы можем восставонить информацию после любых сбоев. Вначале восстанавливается копия файлов данных на определенный момент времени, затем «накатываются» изменения из архива логов с момента создания копии файлов данных, и в последнюю очередь восстанавливаются изменения из online redo log-ов.

Экземпляр БД Oracle состоит из блоков разделяемой памяти, называемых system global area (SGA) и background процессов. SGA содержит три обязательные структуры данных:

• Thedatabasebuffercache / содержит копии блоков данных считанные из файлов данных
• Thelogbuffer / содержит данные о транзакциях которые ещё не записаны в redolog
• Thesharedpool / содержит проверенные SQL выражения и кэш словаря данных, содержащий таблицы, представления и триггеры.

Также дополнительно могут быть:

• Largepool
• Javapool
• Streemspool

Эти структруры показаны на рисунке 1-5 и мы обсудим обязательные структуры.

Пользовательские сессии тоже требуют памитя на сервере. Как мы помним это неразделяемая область памяти, которая называется PGA. У каждой сессии своя PGA.

Управление объёмом памяти может осуществляться автоматически, или управляться администратором базы данных. Рекомендуется использовать автоматический способ управления.

Database buffer cache

Database buffer cache – это область где выполняются SQL команды. Когда мы обновляем данные, они не изменяются непосредственно в файлах данных на жёстком диске. Блоки данных, которые содержат данные с которыми мы работает вначале копируются в buffer cache (если они ещё не находятся там). Изменения (вставка, измнение или удаление данных) применяются к этим копиям данных в буфферном кэше. Затем эти блоки данных остаются в памяти некоторое время, пока место которое они занимают не понадобится для работы над какими-либо другими данными.

Когда мы хотим посмотреть какие-то данные – операция выдачи информации тоже происходит через кэш. Вначале находятся блоки данных которые мы запросили и копируются в буфер кэш (опять же если их ещё там нет); затем нужные данные переносятся в PGA для дальнейшей обработки.

Термин блок. Файлы данных представляют из себя данные сгруппированые в блоки фиксированной длины. Данные в таблицах (строки) и другие объекты такие как индексы и т.п. хранятся в этих блоках. Buffer cache также сгруппирован в структуры в памяти, чтобы вмещать в себя ровно один блок. Строки же могут быть разной длины: длина строки зависит от количества столбцов в ней, не важно есть ли в этих столбцах данные или нет. В зависимости от размера блока (размер выбирается администратором базы данных) и размера строки может быть несколько строк в блоке, или строка занимать несколько блоков. Структуру блока мы более детально рассмотрим в теме организация данных.

В идеале – блоки данных содержащие наиболее часто используемые данные будут в buffer cache, таким образом снижая количество операций чтения/записи. Как типичный пример работы буфер кэша рассмотрим пример типичной операции продавца в магазине, который получает данные о клиенте и обновляет их. Будут использованы примерно такие запросы:

 

SELECT CUSTOMER_ID,CUSTOMER_NAME FROM CUSTOMERS;

UPDATE CUSTOMERS SET CUSTOMER_NAME=’Вася’ WHERE CUSTOMER_ID=100;

COMMIT;

 

Для того чтобы выполнить SQL команду селект пришедшую от пользователя, серверный процесс этой сессии вначале посмотрим есть ли уже в буфере блок данных, который содержит необходимую информацию. Если эта информация найдена, данные будут прочитаны (hit) из буфера. Преположим что данные не в буфере (miss), тогда серверный процесс считает блоки из файлов данных и поместит их в буфер, перед тем как вернуть данные пользователю.

Потом пользователь запускает команды UPDATE и COMMIT, которые будут обработаны серверным процессом. Допуская, что данные всё ещё доступны в buffer cache на момент выполнения этого запроса, строка будет обновлена в буфер кэше. В данном примере мы получим эффективность использования буфера – 50%. 2 раза доступ к данным в кэше буфера, один раз чтение данных с диска. Формула расчёта: 1-«кол-во чтений с диска»/кол-во чтений с буфера»). В хорошо оптимизированных базах данных этот показатель может достигать 90%.

Буффер в котором данные в блоках отличаеются от данных этих блоков на дисковом пространстве – называбтся грязными (dirty buffers). Буфер будет чистым (clean) когда блок только скопирован с диска в память: в этот момент времени данные одинаковые и в памяти и на диске. В итоге, грязные блоки данных должны быть записан назад на диск и тогда буфер опять станет чистым. Но даже после записи на диск, блоки остаются в памяти, пока их не перепишут другими блоками.

Важно, что нету прямой зависмости количества обновлений данных в буфере (комманд COMMIT) и количества операция записи данных назад в файлы данных. Запись в файлы данных производится background process-ом – database writer.

Размер buffer cache очень важен для производительности. Значение должно быть адекватно рассчитано, не минимальное — чтобы все часто используемые блоки (неважно чистые или грязные) находились в буфере, но не настолько большое чтобы даже редко используемые данные тоже находились в буфере. Недостаточный объём приведёт к избыточному использованию чтения/записи с диска, так как блоки будут читаться с диска, тут же переписываться и снова читаться. Слишком большой объём не настолько плохо как слишкомй маленький (пока он меньше чем размер реальной доступной оперативной памяти) но тоже может вызывать определённые проблемы: например запуск базы данных будет дольше, так как требуется форматирование большого объёма памяти.

Память для buffer cache выделяется на этапе запуска экземпляра БД. До версии 9i нельзя изменить размер буфер кэша без перезапуска инстанса. Начиная с версии 10 g – размер буфера кэша можно изменять как автоматически (включить механизм автоматическго управления), так и вручную.

Буфер логов (log buffer)

Буфер логов – это небольшая, краткосрочная выделенная область памяти для хранения записей изменений (change vector) до записи их в журнал (redo log) на диске. Запись изменений – это изменение произошедшее с чем либо; выполнений DML команда создаёт записи изменений. Сохранение всех таких записей – это гарантия того, что данные никогда не будут утеряны. Когда бы не изменились данные в блоке – запись изменений в блоке должна быть записана  в журнал. Впоследствии эти записи могут быть считаны и применены к резервной копии файлов данных, если возникла необходимость.

Изменения не пишутся в журнал серверными процессами сессий. Если бы это было реализовано таким образом, сессиям пришлось бы ждать выполнения операций чтения/записи чтобы закончить выполнения любой DML команды. Вместо этого сессии пишут в буфер логов в памяти. Это гораздо быстрее чем писать на диск. Уже из буфера логов записи изменений (сформированные из разных сессий) пишутся в журнал.Одна операция записи в журнал может влючать множество изменений. Эти изменения пишутся примерно в реальном времени – но как только какая-нибудь сессия исполняет команду COMMIT – тут же происходит запись в журнал. Запись осуществляется background процессом – log writer-ом (LGWR).

Буфер логов небольшая (по сравнению с другими) область памяти, потому что время жизни данных там очень короткое. Изменения записываются в этот буфер и почти в тот же момент времени пишутся на диск. Нет необходимости делать размер больше чем несколько мегабайт, и более того, использование значение сильно большего чем значение по умолчанию может плохо сказаться на производительности. Значение по умолчанию устанавливается сервером Oracle в зависимости от количества процессоров на серверах.

Невозможно задать значение, меньше чем значение по умолчанию. Если попробовать сделать это, Oracle просто установит значение по умолчанию. Можно установить большее значение, но обычно этого делать не стоит. Основаная проблема в том, что когда выполняется команда COMMIT, запускается запись изменений из буфера на диск, и пока операции записи осуществляется, сессия которая запустила команду COMMIT будет ждать. Запись изменений важная часть архитектуры Oracle. Идея того что подтверждённые изменения никогда не будут утеряны в том, что выполнение команды commit считается успешным только  тогда, когда данные изменены в buffer cache и записи зименений (vector change) записаны в журнал на диске (это значит что изменения могуть быть повторены при необходимости). Большой буфер логов может привести к тому что операция записи из него на диск будет занимать длительное время, а в это время сессия не может продолжать работу.

Память для буфера логов выделяется в момент запуска экземпляра БД и размер не может быть изменен без перезапуска. Это круговой буффер. Серверные процессы пишут записи изменений, и текущий указатель перемещается. Log writer записывает эти изменения на диск группами, и когда он это делает, место занятое этими записями становится снова доступным и может быть переписано новыми записями. В момент самой высокой нагрузки на сервер, может случиться так, что новые векторы должны быть записаны быстрее чем log writer может записать их на диск. Если такое случается все команды манипулированяи данными будут «подвисать» на некоторое время, пока log writer не очистит буфер.

Процесс записи изменений из буфера на диск одно из самых главных узких мест в архитектуре Oracle. Команды изменения не могут выполняться быстрее чем запись log writer-ом из буфера на диск.

The shared pool

Shared pool самая сложная область в SGA. Она состоит из под-областей, которые управляются Oracle сервером. Мы обсудим только 4 кмпонента:

Library cache

Data dictionary cache

PL/SQL area

SQL PL/SQL function result cache

Управление этими структурами происходит автоматически. Размер изменяется динамически в зависимости от писпользования, но не превышает размер всей области памяти. Shared pool может тоже изменять размер или посредством настройки автоматического управления или командами администратора базы данных.

Library cache

Library cache это область памяти где хранятся последние выполненные запросы в разобранном виде. Разбор (parsing) – это процесс преобразования инструкция написанный программистом в исполняемые команды понятные Oracle. Этот процесс Oracle запускает по требованию. Хранение разобранных команд очень сильно увеличивает производительность, потому что процесс разбора занимает время. Рассмотрим пример простого запроса:

SELECT * FROM PRODUCTS WHERE PRODUCT_ID=100;

Перед тем как выполнять запрос, надо узнать что написано в запросе и как его выполнять. Начиная с того, что такое PRODUCTS? Мжет быть это таблица? Или синоним, представление? Вообще существует ли такой объект? Дальше символ «звездочка» — какие столбцы в таблице PRODUCTS (если это действительно таблица)? Есть ли у пользователя необходимые права чтобы просматривать эту таблицу? Вопросы на эти ответы и многие другие надо найти в словаре данных. Важное замечание – алгоритм поиска разобранного запроса в кэше базируется на ASCII символах которые использованы в запросе. Небольшое различие (к примеру использование строчных символов вместо прописных) может привести к тому что запрос будет разбираться опять.

После разбора запроса, сервер должен решить как наиболее оптимально выполнять его. Есть ли индекс для поля PRODUCT_ID? Если он есть, будет ли быстрее использовать индекс чтобы найти нужную строку, или проще просмотреть всю таблицу? И ещё больше и больше запросов в словарь данных. Бывает что для простого запроса надо создать много запросов в словарь данных и разбор занимает больше времени чем выполнение самого запроса. Смысл library cache – хранить запросы в разобранном виде, готовые к выполнению. Первый вызов необходимо обработать – второй вызов такого же запроса, тут же готов к выполнению. В хороших приложениях запросы подготавливаются один раз – а выполняются миллионы раз. Это позволяет сэкономить огромное количество времени.

Кэш словаря данных (Data dictionary cache)

Data dictionary cache иногда называют row cache. В нём хранятся определения использованных объектов: описания таблиц, индексов, пользователей и другие мета-данные. Хранения этих данные в кэше в памяти SGA, где они доступны для всех сессий, в отличии от чтения их со словаря данных с диска, сильно увеличивает производительность разбора команд.

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

 

SELECT SUM(ORDER_AMOUNT) FROM ORDERS;

SELECT * FROM ORDERS WHERE ORDER_NO=100;

 

Два запроса нужно разобрать, поскольку они разные, но разбор первого запроса загрузит информацию о таблице ORDERS в кэш, и разбор второга запроса будет быстрее, потому что уже не нужно считывать информацию.

Область PL/SQL (PL/SQL Area)

Объектами PL/SQL являются процедуры, функции, пакеты, сложные типы, триггеры. Все они хранятся в словаре данных в виде исходного когда и скомпилированной программы. Когда PL/SQL объект вызывается сессией, необходимо прочитать нужную информацию из словаря данных. Для того чтобы исключить повторное чтение, эти объекты кэшируются в области PL/SQL в shared pool.

Первый вызод займёт некоторое время, так как нужно считать информацию, но следующие вызовы будут гораздо быстрыее так как объект уже будет в области PL/SQL.

SQL Query and PL/SQL Function Result Cache

Данный кэш появился в версии 11 g. Во многих приложениях, одинаковые запросы выполняются много раз,  или одной сессией или разными. Создание этого кэша позволило Oracle серверу хранит результаты подобных запросов в памяти. Когда запрос будет выполняться повторно вместо его реального выполнения, результат возьмётся из кэша.

Механизм кэширования отслеживает изменились ли данные в таблицах, которые используются в такого рода запросах. Если данные изменились, запрос будет перевыполнен. Это позволяет устранить проблему выдачи некорретных данных.

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

По умолчанию, SQL Query PL/SQL function result cache отключен. Но если его включить – можно получить очень существенное ускорение производительности. Для данного вида кэша администратор может установить максимальный размер памяти.

Управление размером shared pool

Выбор оптимального объёма shared pool-а очень важен для производительности. Он должен быть достаточно большой для хранения всех часто используемых запросов и объектов, но не настолько большой чтобы хранить кэши для всех запросов и объектов. Слишком маленький размер снижает производительность так как сессиям нужно выделять память и записывать данные для запросов, потом другой запрос может переписать эту информацию и придётся повторять операцию опять. Слишком большой размер плохо влияет на производительность так как увеличивается время поиска в кэше.

Память в shared pool выделятся согласно алгоритму LRU (least recently used). Когда нужно выделить место в shared pool, сервер будет искать объекты которые не использовались дольше всех. Если этот объект потом понадобится опять – его придется перезагрузить (возможно снова удалив другой объект).

Shared pool выделяет память в момент запуска экземпляра БД. Начиная с версии 9i размер может изменяться динамически без перезапуска, либо механизмом атовматического управления, либо администратором.

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

Процессы, которые являются частью экземпляра базы данных обычно называют background processes, так как они существуют и запущены всё время пока instance активен. Эти процессы не требуют дополнительного администрирования, хотя в некоторых случаях администратор может повлиять на них. Структуры памяти расположенные в разделяемой области памяти операционной системы назыываются system global area или SGA. Эта область памяти выделяется при запуске и освобождается при остановке инстанса. В зависимости от определённых условий, SGA в экземпляре БД версии 11g  может быть перемещена в памяти либо автоматически либо как результат выполнения команд администратора.

Пользовательские сессии состоят из пользовательского процесса, запущенного на машине пользователя, который подключается к серверному процессу, работающему на сервере. Технология запуска серверного процесса по запросу пользовательской сессии мы расмотрим в главе четыре. Взаимодействие между пользовательским процессом и серверным обычно происходит посредством локальной сети используя закрытый протокол Oracle Net поверх стандартного сетевого протокола (обычно TCP). Данный подход реализует клиент-серверную модель: пользовательский процесс генерирует SQL команды; серверный процесс выполняет. Серверные процессы обычно называют foreground процессами, в противовес background процессам которые составляют экземпляр БД. Для каждого пользовательского процесса выделяется область неразделяемой памяти, называемой program global area или PGA. Это область в отличие от SGA доступна только пользовательской сессии. Примечание: у background процессов тоже есть PGA. Область такой памяти для конкретной сессии может отличаться в зависимости от памяти необходимой для даннйо сессии в момент времени. Администратор базы данных может установить предельное значение для всех областей PGA и Oracle будет контролировать выделение памяти автоматически.

Управление памятью в версии 11g может быть полностью автоматическим: администратор может не делать ничего кроме указания полного объема памяти доступного для SGA и PGA и позволить Oracle серверу управлять им как ему угодно. Но также администратор может и устанавливать ограничения на выделение памяти вручную. Администратору доступна настройка определенных ограничений для автоматического управления памятью.

Физические структуры из которых состоит база данных – это файлы данныx (data files), журнал изменений (redo log) и файл управления (control file). Внутри физической структуры файлов данных лежит логическая структура доступная для конечных пользователей (разработчиков, бизнес аналиттиков и т.п.). Такая архитектура позволяет абстрагировать логическую структуру от физической: программисту нет необходимости знать где физически находится информация, так как он взаимодействует только с логическими структурами, такими как таблица. Таким же образом, системный администратор не знает какие данные лежат в физических структурах, он видит только системные файлы, а не то что внутри них. Только администратор базы данных видит обе стороны.

Данные хранятся в data файлах. Нету практических ограничений к количеству этих файлов или их размеру, и разделение физической и логической структуры означает, что можно переместить, изменить размер или добавить новые файлы, а пользователя это не затронет. Эта взаимосвязь между физической и логической структурами хранится в словаре данных (data tictionary), которые содержит мета-данные для всез базы данных. Путем просмотра определенных представлений (views) в словаре данных, администратор базы данных (DBA) может точно определить где какая часть таблица находится в физической структуре.

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

Стандартное требование к реляционной системе управления базами данных (RDBS) – данные не могут быть потеряны. Это значит что должны быть резервные копии, и более того, все изменения в данных между резервными копиями должны храниться в таком виде, чтобы было возможным применить их к восстановленной копии. Такой тип восстановления реализован в Oracle с помощью файла изменений (redo log). В этом файле последовательно хранятся все изменения в данных (change vector). Эти изменения – это изменения данных сделанные с помощью команд DML (Data Manipulation Language: INSERT, UPDATE или DELETE). Любое изменение сделанное пользовательской сессией, изменяет данные в файле и записывается в файл изменений в виде, позволяющем повторить это действие. В случае нарушения работы файлов данных, последняя копия может быть востановлена и Oracle последовательно выполнит все изменения из файла изменения, таким образом восстановив состояние данных внутри файла. Это гарантирует что никакие изменения данных не будут потеряны, только в случае если нарушения настолько серъёзные что затронули и файлы данных, и резервные копии и файл изменений.

Файл управления (control file) содержит данные о физической структуре базы данных и является отправной точкой для её связи с логической структурой. Когда экземпляр стартует, процесс начинается с чтения файла управления. Внутри этого файла информация, которая позволит подключится к собственно базе данных и словарю данныx (data dictionary) внутри базы.

Архитектура single-instance в общем состоит из 4 взаимодействующих процессов:

• Пользователь взаимодействует с пользовательским процессом
• Пользовательский процесс взаимодействует с серверным процессом
• Серверный процесс взаимодействует с экземпляром БД
• Экзмепляр БД работает с базой данных.

Абсолютно невозможно как-то повлиять на базу данных со стороны пользователя напрямую: пользователь может создать команду, а уже сервер выполнит её.

Распределенные системные архитектуры

В single-instance архитектуре, один экземпляр работает с одной базой данных. В распределенных системах, различные комбинации группировки экземпляров и баз данных возможны. Главным образом:

Real Application Cluster (RAC) когда множество экземпляров работает с одной базой данных;

Потоки (Streams) – когда разные сервера обмениваются информацией об изменениях друг с другом;

Dataguard — когда основная база обновляет состояние вспомогательной.

Используя комбинации этих архитектур, можно добиться работы системы 365/24/7 без каких либо потерь данных с неограниченными возможностями масштабирования и производительности.

Real Application Cluster (RAC)

RAC предоствляет поразительные возможности для увеличения производительности, отказоустойчивости и масштабирования и является частью концепции сетевой инфраструктуры Oracle (Grid). Раньше RAC (и его предшественник Oracle Parallel Server) был отдельной дорогой надстройкой, но начиная с версии 10 g, RAC доступен с лицензией Standard Edition. Это показывает насколько сильно Oracle хочет популяризировать данную технологию. Standard Edition RAC имеет ограничения к количеству серверов и используемых ядер, но даже с этими ограничениями это достаточно мощная среда. Enterprise лицензия доступна за отдельную плата, но она предоставляет возможности, ограниченные только операционной системой и физическими характеристиками серверов.

Архитектура RAC может быть сконфигурирована таким образом, чтоб обеспечить 100 % доступность базы данных. Один экземпляр данных можно выключить (напирмер для ремонтных работ), а база данных будет доступна за счёт других экземпляров работающих на других серверах. Пользовательские сессии с выключенного экземпляра будут распределены между остальными инстансами без каких-либо неудобств для пользователей.

Прозрачная масштабируемость даёт возможность добавлять экземпляры, работающие на разных серверах динамически. Они будут автоматически забирать часть нагрузки с других экземпляров БД.

Некоторые приложения определенно выиграют при переходе на RAC архитектуру. Параллельное выполнение улучшает производительность определённых задач, таких как длительные запросы или большие обновления данных. В single-instance архитектуре включение механизма параллельного выполнения поможет, но все запросы будут работать на одном экземпляре на одном сервере. В RAC – параллельное выполнение будет работать на разных машинах, что может позволить обойти некоторые узкие места присущие архитектуре single-instance. Другие задачи, такие как обработка большого количества небольших атомарных операций (transaction), присущие OLTP системам, не получат преимуществ при переходе на RAC.

Streams

 Существует много обстоятельств, которые делают нужным передачу данных из одной базы данных в другую. Одна из причин для этого – это отказоустойчивость. Она может  быть достигнута таким образом: если имеются 2 или более географически разделённых серверов, содержащих одни и те же данные и доступные для работы, тогда не важно что случится с одним из них, работа может продолжаться на других. Другая причина – разделение задач. К примеру одна база может быть сконфигурирована под OLTP систему, а вторая под хранилище данных.

Задачи синхронизации баз данных должна происходить полностью автоматически, и все изменения из в базах данных должны быть переданы в режиме реального (или около реального) на другие базы данных. Для хранилищ данных данные из OLTP систем должны быть переданы в базу данных хранилища и впоследствии периодически обновляться. Потом данные передаются дальше, возможно в витрины данных, каждая из которых работает с хранилищем данных. Потоки – это возможность сбора изменений, произошедших с таблицей и затем применения этих изменения на удалённые копии таблиц.

Потоки могут быть двунаправленными: одинаковые таблицы с двух или более серверов и все атомарные операции пользователей по изменению данных применяются на всех серверах. Эта модель используется для обеспечения отказоустойчивости. Другая модель использования – для предоставления данных в хранилище, как описано выше. В такой модели поток поднонаправленные, и структуры таблиц могут быть не одинаковы.

Dataguard

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

Вспомогательные сервера бывают двух видов. Физический тип – это побитовая копия основной машина и основная цель такого вспомогательного сервера – обеспечение отсутствия потерь данных. Даже если главные сервер будет полностью разрушен – вся информация доступна на вспомогательном сервере. Изменения с главного сервера передаются на вспомогательный в форме записей изменений (redo records) и происходит процесс применения этихз ихменений, схожий с восстановлением из резервной копии и записью файла изменений. Логический вспомогательный сервер содержит те же данные что и главный, но с возможными различиями в структуре данных, к примеру для обеспечения быстродействия при выполнения запросов. На главном сервере могуть быть созданы индексы (для обеспечения быстродействия OLTP системы), а на вспомогательном индексы будут отсутствовать, для обеспечения быстрого выполнения задач типичных для хранилищ данных. Изменения в таком случае передаются в форме SQL команд используя механизм потоков.

База данных Oracle может быть установлена на различных комбинациях аппаратного обеспечения и операционных систем. Наиболее популярны UNIX-подобные операционные системы или Windows. Большинство людей, которые хотят изучать и работать с Oracle почему-то не понимают важность знания основ UNIX-подобных ОС. Крайне необходимо знать хотя бы основы администрирования и написания shell скриптов. В маленьких компаниях, администратор базы данных обычно выполняет роль и системного администратора (бывает что и разработчика). С ростом компании IT отдел становится более сегментирован и обычно идет разделение на под-отделы системного администрирования, безопасности, разработки и администрирования баз данных. В больших компаниях обычно администраторы баз данных работают только с определенной операционной системой.

Определения Oracle

База данных Oracle включает в себя два основных компонента: экземпляр БД (instance) и собственно базу данных. Это сбивает с толку так как часто термин «база данных» употребляется как синоним «сервер базы данных». Инстанс – это не что иное, как набор системных процессов и структурированных областей памяти инициализированных при запуске.  Тогда как база данных – это набор файлов на жёстких дисках используемых для хранения данных и операций над ними. Надо понимать, что Oracle использует оперативную память, процессорное время и память сервера. Oracle предоставляет разные инструменты, которые можно использовать для взаимодействия с базой данных. Наиболее популярными являются: Oracle Universal Installer (OUI), который используется для установки и удаления программного обеспечения Oracle; Database Configuration Assistant (DBCA), используемый для создания, изменения и удаления баз данных; SQL*Plus и SQL Developer, предоставляющие вохможность для написания и выполнения SQL запросов и т.д.

Определения SQL

SQL – это язык с широкими возможностями, применяемый для работы с базой данных Oracle. Рассмотрим понятия таблицы, строки, столбца и основной синтаксис команд, необходимых для выполнения задач администратора. Наиболее глубоко изучать SQL мы будем позднее.

Таблица, Строки и Столбцы

Данные в базе данных Oracle в основном хранятся в двумерных таблицах. Каждая таблица состоит из строк в свою очередь разделенных на столбцы. Таблица может содержать сколь-угодно много строк, однако количество столбцов должно быть зафиксировано. Данные о самой базе данных хранятся в специальном наборе таблиц называемом словарь данных (data dictionary tables). Рисунок 1-3 показывает таблицу DICTIONARY состоящую из 2ух столбцов TABLE_NAME и COMMENTS. 13 строк было получено из этой таблицы.

Таблицы подчиняются определённым правилам который ограничивают и определяют данные. На уровне столбцов – каждый столбец имеет тип данных, к примеру число, строка, дата. Строчный тип данных наиболее общий и может содержать любые символьные данные. На уровне строк также обычно указываются какие-либо уникальные характеристики, к примеру в столбце TABLE_NAME на рисунке значение не может повторяться в разных строках

Основы синтаксиса SQL запросов

На рисунке 1-3  показан стандартный запрос в SQL Developer. Существует много других инструментов для выполнения запросов, но самымй популярный это SQL*Plus. Мы детально рассмотрим запросы далее, но в целом они интуитивно понятны, и сейчас нам главное понять как работает запрос на рисунке 1-3. Ключевые слова в запросе это SELECT, FROM, WHERE и  LIKE. Звёздочка обозначает получить все столбцы из таблица под названием DICTIONARY. Таким образом оба столбца и TABLE_NAME и COMMENTS видим в результирующем наборе данных. Команда наложения условия WHERE во второй строчке ограничивает возвращаемые строки только теми, которые начинаются с “V$SYS” в столбце TABLE_NAME.

Определения операционной системы

Установка базы данных займёт место на жёстком диске, и это надо учитывать при выделении ресурсов для установки. Два основных потребителя – это исполняемые файлы Oracle (binaries) и файлы данных (data files). Binaries – это обычно скомпилированные программы, написанная на C и используемые для создания и поддержки базы данных. Обычно binaries занимают около 3 Gb свободного места на носителе и особо не увиличиваются в размере. Файлы данных, содержат актуальные данные и либо увеличаются, либо уменьшаются в размере в процессе использования базы данных. Объём по умолчанию занимаемый относительно пустой базой данных примерное 2Gb. Другой важный ресурс это оперативная память (RAM). Желательно для используемой системы предоставить не менее 1 Gb RAM.

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

Выделяют три группы продуктов в семействе технологий Oracle: база данных, сервер приложений и  система управления (Enterprise manager). Это основные компоненты для организации сетевых вычислений (grid computing). Основной концепцией для построения инфраструктуры (Grid-а) выступает виртуализация. Пользователи  работают с информацией (обычно посредством веб-приложения), но они не знают и не должны знать откуда и как эти данные выводятся. Упрощённо – база данных отвечает за хранения и выдачу информации, сервер приложений – за инфраструктуру и развертывание служб нужных пользователю и система управления используется для администрирования и управления. Платформа или физические сервера используемые для работы не имеют значения для конечного пользователя. Виртуализация позволяет эффективно рапределять ресурсы, предоставляя максимальную производительность там где это нужно (балансировка нагрузки).

Сервер баз данных

Сервер баз данных Оракл включает в себя экземпляр (instance) базы данных и саму базу данных с множеством возможностей таких как потоки, партицирование, хранилище данных, репликация и RAC (Real Application Cluster), но самое главное, это надёжное, высоко-производительное хранилище данных, построенное на объектно-ориентированной системе для баз данных. Исторически, один из проектов в поздних 70-ых для поддержки теории предложенной Dr. E.F Codd, привел к созданию реляционной системы управления базами данных (РСУБД), со временем ставшую известной как Oracle Server. Oracle Server это основной продукт Oracle, который продолжает активно развиваться и является ядром других продуктов.

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

Такая модель доступа является клиент-серверной моделью, также известной как двухуровненой (two-tier) модель. В клиент-серверной модели пользовательский интерфейс и логика приложения не зависят от управления данными. Для приложения разработанного с использованием SQL это значит, что пользовательская часть приложения создаёт SQL запросы, а серверная часть исполняет их. Это классическое разделение клиентской и серверной части, обычно соединённой локальной сетью. Сетевой протокол используемый в Oracle – закрытый и называется Oracle Net.

Клиентская часть состоит из 2ух компонентов: пользователей и пользовательских процессов. В серверной части три составляющие: серверный процесс, который исполняет SQL запросы, instance и сама база данных. Каждый пользователь взаимодействует с пользовательски процессом. Пользовательский процесс взаимодействует с серверным процессом, обычно посредством локальной сети. Серверный процесс взаимодействует с экземпляром, и экземпляр с базой данных. Рисунок 1-1 показывает это взаимодействие. Сессия – это пользовательский процесс с серверным процессом. Обычно это один пользовательскйи процесс для пользователя и серверный процесс для каждого пользовательского процесса. Сессия обычно создается по запросу пользователя и уничтожается когда она больше не нужна: это называется log-on и log-off цикл. Экземпляр и структуры в памяти нужные для работы запускаются администратором и существуют пока администратор не остановит их: это называется запуск и остановка экземпляра.

Пользовательским процессом может выступать любое клиент-серверное приложение которые можнт подключится к Oracle серверу.Мы будет использовать SQL*Plus и SQL Developer. Это программное обеспечение предоставляемое Oracle-ом для подключения к серверу и выполнения SQL запросов. Что использует пользователь абсолютно не важно для Oracle сервер-а. Когда пользователь вводит данные и нажимает кнопку «Выполнить» будет сгенерирована команда, к примеру INSERT и отправлена команда серверному процессу для исполнения  на инстансе и базе данных. Единственное требования это чтобы команда была корректной. Не стоит забывать что все взаимодействие осуществляется согласно клиент-серверной модели. Даже если пользовательский процесс запущен на той же самой системе что и сервер – клиент-серверное разделение всё равно работает и сетевой протокол использвется для взаимодействия между двумя процессами.

Сервер приложений

Со становлением Web-приложений как стандарта для работы пользователей появилась потребность в серверах приложений. Сервер приложений позволяет заменить установленное приложение на компютере пользователя, на приложения установленные в определенном хранилище. Интерфейс пользователю отображается посредством браузера. Такие приложения могут использовать данные, находящиеся в разных базах данных. Oracle сервер приложений – это платформа для разработки, установки и управления web-приложениями. Web-приложение — любая программа, работающая с ипользованием протокола HTTP. Web-приложения обычно используют трех-уровневую (three-tier’s) модель: уровень базы данных, для доступа к данным, пользовательский уровень (им обычно выступает веб-браузер) для отображения окон и диалогов для взаимодействия с пользователем, и уровень приложения между ними, который реализует бизнес-логику для генерации пользовательского интерфейса и выполнения запросов к базе данных.

Возможно использовать отдельное соединение для каждого пользователя: каждый польователь будет создавать сессию к серверу приложений, а сервер приложений в свою очередь создавать подключение к базе данных. Однако, эта модель признана очень неэффективной по сравнению с пулами подключений (connection pooling model). Согласно модели пула подключений сервер приложений создает относительно небольшое количество соединения с базой данных и делает их доступными  для запросов (помещая запросы в очередь при необходимости) для относительно большого количества пользователей сервера приложений. Рисунок 1-2 показывает трех-уровневую модель доступа и использованием пула запросов.

С точки зрения базы данных, нет абсолютно никакой разницы между запросами из SQL*Plus или пула запросов. В первом случае пользовательский процесс происходит на одной машине, во втором случае пользовательский процесс разбит на 2 уровня: сервер приложений генерирует пользовательский интерфейс и пользовательский уровень отображает его.

Enterprise Manager

Увеличение объёма и сложности IT установок может сделать управление компонентами достаточно сложной процедурой. Инструменты управления могут сделать эту задачу легче, и занчительно повысить производительность сотрудников.

Oracle Enterprise Manager включает в себя 3 группы инструментов:

*Управление базой данных (Database Control)

*Управление сервером приложений (Application Server Control)

*Управление инфраструктурой (Oracle Enterprise Manager Grid Control)

Управление базой данных – графический инструмент для управление одной базой данных, которая может быть RAC кластером. Есть возможности управления и мониторинга в режиме реального времени, планировщик задач и резервного копирования, генерация отчётности.

Управление сервером приложений – инстурмент для управления серверами приложений. Технология управления несколькими серврами зависит от версии. До 10gR2 включительно используется технологий «ферма», с ерпозиторием мета-данных и центральным управляющим входом. Эта модель закрытая и предоставляет отличные позможности для установки и поддержи приложений. Начиная с версии 10gR3 используется технологий основанная на J2EE кластеризации.

И Database Control и Application Server Control состоят из java процессов запущенных на сервере, которые ожидают HTTP или HTTPS подключений. Админстраторы подключаются к ним с помощью браузера. Database Control подключается к базе данных, а Application Server Control к серверу приложений.

Oracle Enterprise Manager Grid Control обобщает управление инфраструктурой. Репозиторий (находящийся внутри базы данных Oracle) и один или несколько серверов управляют всей средой: всеми базами данных и серверами приложений, расположенными где-угодно. Данный инструмент также может управлять узлами, или машинами на которых запущены сервера и, с помощью плагинов, различными сторонними продуктами. Каждый управляемый узел запускает процесс, который ответственнен за мониторинг управляемых процессов на узле: этот процесс выполняет разные задачи и возвращает результаты на сервер управления.

Oracle Enterprise Manager Grid Control даёт целостное представление обо всей инфраструктуре и может кардинально улучшать производительность администраторов.  С его помощью один администратор может обслуживать десятки и сотни серверов.

Инструменты разработчика Oracle

Oracle предоставляет различные инструменты для разработки программ и утилит и поддерживает раличные языки программирования. Языки программирования которые разбираются на инструкции и выполняются внутри Oracle сервером это SQL, PL/SQL и Java. Технологии для разработки вне базы данных можно найти в Oracle Developer Suite (Forms, Reports and Discoverer), Oracle Application Server и других языках третьего уровня (3GLs). Так же доступен широкий выбор инструментов которые могут быть использованы для подключения к базе данных Oracle. Например, Microsoft .NET, для которого Oracle предоставляет обширный набор средств разработчика.

Встроенные языки

SQL используется для работы с данными, но на нём нельзя создать полноценное приложение, так как нет возможности для создания пользовательского интерфейса и отсутствует поддержка сложных структур данных. Два других внутренних языка программирвоания устраняют эти пробелы. Это PL/SQL и Java. PL/SQL – язык третьего уровня и является собственностью Oracle. Он поддерживает стандартные управляющие конструкции: алгоритмы ветвления (if then else) и циклы, и имеет возможность создания пользовательского интерфейса. SQL запросы могуть быть частью PL/SQL кода, таким образом, программа PL/SQL может использовать SQL для получения данных из базы данных, выполнять определенные действия в зависимости от данных, и затем выполнять другие запросы для записи данных назад в базу. Java так же может выполнять SQL запросы, написанные внутри Java кода. Это стандарт технологии: любой Java программист должен быть способен написать код, который будет работать в базе данных Oracle (либо другой Java-совместимой базе данных).

Все администраторы баз данных должны хорошо знать SQL и PL/SQL. Это стандартное и необходимое требование.

Знание Java уже не особо обязательно, так как Java редко используется в базе данных. Раньше Oracle Application Server не мог запускать некоторые стандартные компоненты (к примеру Servlet-ы и EJB). Чтобы устранить это  Oracle разработали Java машину встроенную в базу данных, которая соответствует стандартам. Как бы то ни было, начиная с Oracle Application Server 9i, стало возможным запускать J2EE компоненты там, где им и положено быть: на сервере приложений. Благодаря этому стало запускать меньше Java кода внутри базы данных.

Обычно DBA (database administrator) проводят много времени над задачами повышения производительности и отладки SQL и PL/SQL кода. С точки зрения Oracle – администратор должен находить проблемные участки и передавать разработчику для исправления, однако на практике разработчикам не хватает знания (или желания) делать это и администраторам приходится брать на себя эту роль.

Сторонние языки программирования

Другие языки программирования доступные для создания клиент-серверных приложения запускают вне базы-данных. Наиболее широко используются С и Java, но возможно использовать почти все популярные запросы третьего-уровня. Для большинства языков Oracle предоставляет OCI (Oracle Call Interface) библиотеки, которые позволяют подключаться к базе данных и выполнять SQL запросы.

Программы написанные на C или другом процедурном языке используют OCI библиотеки для создания подключения к базе данных. Эти библиотеки являются собственностью Oracle. Это значит что любой код, написанный с использование этих библиотек написан только для Oracle базы данных и должен быть переписан для работы с другими базами данных. Программы написанные на языке Java могут избежать этой проблемы. Oracle предоставляет возможности для подключения к базе с помощью Java для «толстых» (thich) и «тонких» (thin) клиентов.

«Толстый» клиент направлен на работу с Oracle. Он использует OCI библиотеку и может использовать все возможности базы данных, включая структурные особенности Oracle. Но такой клиент не сможет работать с другими базами данных, и необходима OCI библиотека для работы.

«Тонкий» клиент работает вне зависимости от типа базы данных: он работает с виртуальной базой согласно Java стандарту, и позволяет соотносить виртуальную базу с базой. Это даёт приложению возможность работать с любой другой базой данных и такое приложение может быть развёрнуто в не-Oracle среде без изменений. Однако функциональность огранчена только Java Database Connectivity (JDBC) стандартом.

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

Набор разработчика от Oracle

Некоторые не хотят использовать языки программирования для разработки приложений для работы с базой данных. Оракл предлагает средства для разработки в составе Oracle Developer Suite. В принципе результат разработки с помощью этих средст примерно такой же: генерация SQL запросов, которые посылаются к базе данных для обработки.

С помощью Oracle Forms Developer можно создать приложение, которое запускается на сервере приложений Oracle и отображается в браузере. Такие приложения легко разрабатывать и они оптимизированы для взаимодействия с объетами базы данных. Специальные макросы и компоненты позволяют создавать веб-приложения с богатым функционалом.

Oracle Reports – это инструмент для создания и форматирования отчётов, как по запросу так и по расписанию. Готовые отчёты кешируются для выдачи. Oracle Reports, так же как и Oracle Forms, это среда разработки и требуются навыки программиста для создания специальных отчётов. Большим преимуществом при использовании Oracle Reports является то, что результат можно настраивать каким угодно способом, чтобы достичь желаемого результата.

Oracle Discoverer – это иснтрумент для генерации специальных отчётов, позволяющий пользователем самим создавать себе необходимую отчётность. Когда Oracle Discover установлен и настроен на сервере приложений, больше не нужны услуги программиста и пользователи сами делают что им нужно.