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

Это наиболее распространённая архитектура. Один экземпляр на компьютере, работающий с файлами базы данных на локальных жётских дисках. 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 команд используя механизм потоков.