Oracle optimal flexible architecture это

Обновлено: 06.07.2024

ORACLE_BASE: Основа структуры каталогов Oracle. Рекомендуется установить ее перед установкой.

ORACLE_HOME: Среда, в которой работают продукты Oracle. Не требуется перед установкой, если установлена ORACLE_BASE .

ORACLE_SID: Не требуется перед установкой, но полезна впоследствии для простоты взаимодействия с определенным экземпляром

NLS_LANG: Дополнительная переменная окружения, которая управляет языком, территорией, и клиентскими настройками набора символов

Есть множество переменных окружения Oracle, включенных в каждую среду Oracle. Упомянутые здесь важны для успешной установки и использования базы данных Oracle. Ни одна из них не обязана быть установленной, но можно избежать будущих проблем, если установить эти переменные.

ORACLE_BASE: Определяет основу структуры каталогов Oracle для Оптимальной Гибкой Архитектуры (OFA), которая рекомендуется Oracle Support. Использование является опциональным; если используется, это может облегчить будущие установки и обновления. Это - путь к каталогу, как показано в следующем примере:

ORACLE_HOME: Среда, в которой работают продукты Oracle. Не обязательна перед установкой, если установлена ORACLE_BASE. OUI может использовать ORACLE_BASE, чтобы определить рекомендуемый ORACLE_HOME для Вашей установки. Наличие этой переменной окружения облегчает обслуживание и управление программным обеспечением Oracle. Это - путь к каталогу, как показано в следующем примере:

ORACLE_SID: системный идентификатор для экземпляра Oracle, такого как orcl для базы данных или +ASM для экземпляра ASM. Не требуется перед установкой, но полезен впоследствии для простоты взаимодействия с определенным экземпляром.

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

Для получения дополнительной информации о допустимых языках, территориях, наборы символов, и поддержка языка, см. Oracle Database Globalization Support Guide.

[Стандартный] Введение в оптимальную гибкую архитектуру Oracle (OFA)

на OFA （ Optimal Flexible Architecture ) Стандартное введение

Эта статья взята из интерпретации OFA на официальном сайте Oracle, адрес следующий:

1 .Overview of the Optimal Flexible Architecture Standard

The Optimal Flexible Architecture standard helps you to organize database software and configure databases to allow multiple databases, of different versions, owned by different users to coexist. Optimal Flexible Architecture assists in identification of ORACLE_BASE with its Automatic Diagnostic Repository (ADR) diagnostic data to properly collect incidents.
  • Стандарт OFAАрхитектураПомогите нам организовать ПО Oracle, настроитьбаза данных. Благодаря архитектуре OFA мы можем установить несколько баз данных, которые могут использовать разные версии и разных пользователей. Архитектура Oracle OFA может помочь базе данных автоматической диагностики (ADR) идентифицировать каталог ORACLE_BASE и правильно собрать данные о диагностическом событии.
All Oraclecomponents on the installation media are compliant with Optimal Flexible Architecture. Oracle Universal Installer places Oracle Database components in directory locations, assigning the default permissions that follow Optimal Flexible Architecture guidelines.
  • Все компоненты базы данных на установочном носителе Oracle совместимы со стандартами OFA. OUI поместит компоненты базы данных для установки в фиксированный каталог, указанный OFA, и назначит соответствующие разрешения по умолчанию.
Oracle recommends that you use Optimal Flexible Architecture, especially if the database is huge, or if you plan to have multiple databases.
  • Oracle официально рекомендует использовать стандартную структуру каталогов OFA, особенно если наша база данных очень большая или мы планируем установить несколько баз данных в одном каталоге.

2.Advantages of Multiple Oracle Homes and OFA

When you install Oracle database, you are installing a large application that your computer can support. Using multiple Oracle homes and Optimal Flexible Architecture provides many advantages when administering large databases. The following advantagesare important:
  • Когда база данных, которую мы устанавливаем и которой мы управляем, будет очень большой, использование множественного механизма ORACLE_HOMS OFA будет очень полезным.

（1）Structured organization of directories and files, and consistent naming for database files simplify database administration.

(2) Распределение операций ввода-вывода между несколькими дисками предотвращает возникновение узких мест в производительности, вызванных несколькими командами чтения или записи, отправленными одновременно на один диск.

（3）Distribution of applications across multiple disks safeguards against database failures.

（4）Login home directories are not at risk when database administrators add, move, or delete Oracle home directories.

（5）Multiple databases, of different versions, owned by different users can coexist concurrently.

（6）Software upgrades can be tested in an Oracle home in a separate directory from the Oracle home where your production database is located.

3.Implementing Optimal Flexible Architecture

3 .1 File Systems

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

Numberof File Systems

3.1.1 Number of FileSystems

To fully implement the Optimal Flexible Architecture recommendations for a database stored on file systems that are not striped or mirrored, you require at least three file systems located on separate physical devices.
  • Чтобы полностью реализовать архитектуру OFA, в среде базы данных, которая не реализует базовое чередование хранилища и зеркалирование, Oracle рекомендует хранить базу данных в файловой системе и требует трех независимых физических устройств.

3.1.2 Naming Conventions (Соглашение об именовании)

Назовите все точки монтирования файловой системы, используя синтаксис / pm, где p - строковая константа (константа), а m - уникальный ключ фиксированной длины (обычно двузначное число), используемый для различения каждой точки монтирования. Например: / u01 и / u02 или / disk01 и / disk02.
  • Имя файловой системы необходимо смонтировать в каталоге / pm, где p представляет собой строковую константу, а m представляет собой значение фиксированной длины, которое обычно состоит из двух чисел. Например: / u01, u02 или / disk01, / disk02.

3.2 Naming Directories(OFA Именованный каталог)

The following sections describe the naming conventions for directories that are compliant with the Optimal Flexible Architecture standard: （1）OracleBase Directory Naming Convention
（2）NamingMount Points for Very Large Databases (VLDBs)
（3）Referring to Path Names
（4）OracleHome Directory Naming Convention
（5）Naming Subdirectories Note:
Ensure that the paths you select for Oracle software, such as the Oracle home path and the Oracle base path, use only ASCII characters. Because installation owner names are used by default for some paths, this ASCII character restriction applies to user names, file names, and directory names.

3.2.1 Oracle Base Directory NamingConvention

The Oracle Base directory is the top level directory that you can use to install the various Oracle software products. You can use the same Oracle base directory for multiple installations. If different operating system users install Oracle software on the same system, then each user must create a separate Oracle base directory.
  • Каталог Oracle Base - это каталог верхнего уровня, мы можем установить несколько наборов Oracle в этот каталог. Разные базы данных могут использовать один и тот же каталог ORACLE BASE. Если разные пользователи ОС используются для установки Oracle в одной и той же операционной системе, каждый пользователь ОС должен создать отдельный каталог ORACLE BASE.
Name Oracle base directories using the syntax /pm/s/u. TableD-1 describes the variables used in this syntax.
  • Базовый каталог ORACLE использует следующий формат: / pm / s / u. Значение каждого параметра см. В таблице ниже:
  • Table D-1 Syntax for Naming Oracle BaseDirectories

For example, /u01/app/oracle is an Oracle base directory created by the oracle user and /u01/app/applmgr is an Oracle base directory created by the applmgr user.

Placing Oracle base directories at the same level in the UNIX file system is advantageous because it enables you to refer to the collection of Oracle base directories on different mount points using a single pattern matching string, /*/app/*.

3.2.2 Naming Mount Points for VeryLarge Databases (VLDBs)

If each disk drive contains database files from one application and there are enough drives for each database to prevent I/O bottle necks, use the syntax /h/q/d for naming mount points. TableD-2 describes the variables used in this syntax.
  • Если на каждом диске хранятся данные приложения, чтобы уменьшить узкое место дискового ввода-вывода, используйте формат / h / q / d для монтирования файловой системы. В таблице ниже приведены значения конкретных параметров:
  • Table D-2 Syntax for Naming Mount Points for Very Large Databases
For example, to allocate two drives exclusively for the test database, name the mount points /u01/app/oracle/oradata/test and /u02/app/oracle/oradata/test.

3.2.3 Referring to Path Names

Обращайтесь к явным именам путей только в файлах, специально предназначенных для их хранения, таких как файл паролей, / etc / passwd и файл Oracle oratab.См. Членство в группах только в файле / etc / group.

3.2.4 Oracle Home Directory NamingConvention

To help fulfill the Optimal Flexible Architecture requirement of simultaneously running multiple versions of Oracle software, install the software in a directory matching the pattern /pm/s/u/product/v/type_[n].
  • Чтобы обеспечить одновременную работу нескольких версий базы данных, каталог OFA должен иметь следующий формат: / pm / s / u / product / v / type_ [n]. См. Конкретную таблицу в следующей таблице. смысл:

TableD-3 Syntax for Naming Oracle Home Directories




/u01/app/oracle/product/11.2.0/dbhome_1 indicates the Oracle home directory for the first installation of Oracle Database on this system.

The ORACLE_HOME environment variable is set to the Oracle home directory.

3.2.5 Naming Subdirectories

To facilitate the organization of administrative data, Oracle recommends that you store database-specific administration files in subdirectories matching the pattern /h/admin/d/a/, where h is the Oracle base directory, d is the database name (DB_NAME), and a is a subdirectory for specific types of database administration files. TableD-4 describes the database administration file subdirectories.
  • Рекомендуемый подкаталог Oracle использует следующий формат: / h / admin / d / a, где h - OracleBase, d - имя экземпляра, а a - разные типы.

For example, /u01/app/oracle/admin/orcl/scripts/ is the scripts subdirectory associated with the database named orcl.

In Oracle Database11g, Automatic Diagnostic Repository (ADR) directories replace the bdump, cdump, and udump directories.The ADR diagnostic data goes into the /h/diag/rdbms/d/i/ directory.

h is Oracle Base，d is the database name，i is the instance name.

  • Следует отметить, что в Oracle 11g Oracle использует каталог ADR вместо bdump, cdump и udump. Структура каталогов ADR: / h / diag / rdbms / d / i.
The ADR home has the trace, alert, and incident sub-directories. TableD-5 describes the ADR directories.
  • В каталоге ADR есть подкаталоги трассировки, предупреждений и др. Эти подкаталоги выглядят следующим образом:
  • TableD-5 Locations for Diagnostic Traces

3.3 Naming Database Files

The following table lists the recommended file naming conventions for database files:

Note:
Oracle Managed Files (OMF) and files stored in Oracle Automatic Storage Management disk groups use different naming conventions.

Note:
Do not store files other than control files, redo log files, or data files associated with database d in the path /h/q/d.
  • Не храните в каталоге / h / q / d файлы, кроме управляющих файлов, оперативных повторов и файлов данных.
Using this convention, it is easy to determine the database to which the /u01/app/oracle/oradata/sab/system01.dbf file belongs.

3.4 Separating Segments with Different Requirements

Separate groups of segments with different life spans, I/O request demands, and backup frequencies across different tablespaces.

TableD-6 describes the special tablespaces that the Database Configuration Assistant creates for each Oracle database. If you manually create a database,you must create the required tablespaces. These tablespaces are in addition to those required for application segments.

  • Создайте соответствующие табличные пространства в соответствии с различными потребностями.В следующей таблице перечислены все табличные пространства, созданные с помощью команды DBCA, где Пример и пользователи - необязательные табличные пространства.
  • TableD-6 Special Tablespaces
Creating these special tablespaces is effective because data dictionary segments are never dropped, and no other segments that can be dropped are allowed in the SYSTEM tablespace.

3.5 Exploiting the Optimal Flexible Architecture Structure for Oracle Files

TableD-7 describes the syntax used for identifying classes of files.

3.6 Optimal Flexible Architecture File Mapping

TableD-8 shows a hierarchical file mapping of a sample Optimal Flexible Architecture-compliant installation with two Oracle home directories and two databases. The database files are distributed across three mount points, /u02, /u03,and /u04.

Note:
Oracle recommends that you use Oracle ASM to provide greater redundancy and throughput.

Перед запуском установщика необходимо выбрать аппаратное и программное обеспечение, структуру директорий для установки и настроить ОС.

Некоторые люди привержены их любимой ОС, однако в каждой есть свои минусы и плюсы и не для всех ОС есть все необходимые приложения. Oracle поддерживает все популярные платформы:

  • Linux на платформе Intel и AMD
  • Windows на платформе Intel и AMD
  • Solaris на платформе SPACE
  • AIX на платформе POWER
  • HPUX на платформе PA-RISC

Эти комбинации наиболее популярны, однако существует м ного других. Некоторые ОС поддерживают 32битную и 64битную архитектуру и Oracle обычно поддерживает обе. Когда выбираете платформу, необходимо оценивать такие факторы как

  • Стоимость
  • Простота в использование
  • Масштабирование
  • Отказоустойчивость
  • Производительность

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

Linux заслуживает отдельного обсуждения. Oracle широко использует и развивает Linux. Наиболее популярные дистрибутивы это Red Hat и Suse, но Oracle так же предоставляет свою сборку Oracle Linux Enterprise. Этот дистрибутив имеет все необходимые пакеты для работы и поддерживается компанией Oracle. Таким образом можно создать целую среду поддерживаемую одним поставщиком.

Программные ресурсы и ОС

Выбор программного обеспечения происходит обычно после анализа планируемого объёма данных и активность БД. Есть специальные учебные пособия по выбору аппаратного обеспечения для БД. Минимальные системные требования для системы

1ГБ оперативной памяти

1.5ГБ файл подкачки

400Мб свободного дискового пространства во временной директории

1.5-3.5 ГБ для домашней директории Oracle

1.5ГБ для БД примеров

2.4ГБ для архивов

Процессор с тактовой частотой не меньше 1 ГГц

Такой широкий диапазон для домашней директории обусловлен вариативностью платформ. 2.5 Гб обычно занимает установка на ОС Windows с файловой системой NTFS. 3.5 ГБ для ОС Linux с файловой системой ext3. Временная директория устанваливается системной переменной TEMP. ОС также проверяется на соотвествие

Архитектуре (32/64 битная архитектура)

Наличию необходимых компонентов

Эти проверки будут осуществелены OUI.

Optimal Flexible Architecture (OFA) Структура директорий

Домашняя директория будет установлена на файловую систем. Oracle разработал OFA – структуру директорий в файловой системе, благодаря которой можно легко поддерживать различные версии различных программ. Ключевым элементом OFA является две системные переменные: ORACLE_BASE и ORACLE_HOME. ORACLE_BASE это папка на сервере, внутри которой будут установленые все программы всех версий. Каждая версия каждого продукта имеет свою домашнюю директорию ORACLE_HOME. OFA стандарт для Linux и Unix ORACLE_BASE предполагает использование шаблона /pm/h/u где

m – числовое значение, к примеру 01

p – строка к примеру app

u – системный пользователь(владелец программ Oracle) к примеру oracle

В Windows стандартным значением ORACLE_BASE является структура \oracle\app в корневом каталоге любого системного тома.

Для домашней директории стандартом является значение переменной ORACLE_BASE плюс /product/v/db_n где

v – версия, к примеру 11.1.0

db_n – значение получаемое установщиком при работе, db – database и число увеличивающееся на единицу для каждой последующей установки программы.

Таким образом получаются следующие значения ORACLE_BASE и ORACLE_HOME для Linux

An Optimal Flexible Architecture for a Growing Oracle Database (OFA) - это набор стандартов, описывающих структуру каталогов и схему именования файлов для продуктов ORACLE.

Кратко синтакс для основных каталогов:

1. Точки монтирования:

где p - строка-константа,
m - 2х значный цифровой код
Пример: /u01 и /u02 , или /disk01 и /disk02 .

2. Oracle Base директория:

где pm - точка монтирования,
s - стандартное имя директории,
u - имя владельца директории
Пример: /u01/app/oracle базовая директория для пользователя oracle и /u01/app/applmgr для пользователя applmgr .

3. Oracle Home директория:

/ pm / s / u /product/ v / type _[ n ]

где pm - точка монтирования,
s - стандартное имя директории,
u - имя владельца директории,
v - версия продукта,
type - тип установки, например База данных ( dbhome_1 ), Клиент ( client ), или Oracle Grid ( grid )
n - 2х-значный цифровой код, позволяющий установить несколько одиннаковых продуктов в одну директорию Oracle Base.
Пример: /u01/app/oracle/product/11.2.0/dbhome_1

4. Вложенные директории:

где h - Oracle Base,
d - имя базы данных,
a - вложенная директория:
arch - архивные redo log файлы
adump - файлы аудита (путь в параметре AUDIT_FILE_DEST)
create - содержит data pump dp.log ,
dpdump - каталог для data pump операций, скрипты используемы для создания базы,
exp - файлы экспорта базы данных,
loogbook - файлы, хранящие статус и историю базы данных,
pfile - файл параметра экземпляра базы данных,
scripts - ad hoc SQL скрипты.
Пример, /u01/app/oracle/admin/orcl/scripts/ Директория scripts для базы данных с именем orcl .

5. ADR diagnostic Repository:

где h - Oracle Base,
d - имя базы данных,
i - имя экземпляра Базы данных.

6. Именование файлов базы данных:

6.1. контрольные файлы - / h / q / d /control.ctl
6.2. файлы повторного выполнения (redo log) - / h / q / d /redo n .log
6.3. файлы данных (data files) - / h / q / d / tn .dbf

где h - Oracle Base,
q - константа (обычно oradata ) для отличия данных Oracle от остальных файлов,
d - значение инициализационного параметра DB_NAME, обычно SID для БД с 1м экземпляром ,
t - имя табличного пространства,
n - 2х значный цифровой код.

Синтакс для определения классов файлов:

/u99 User data directories
/*/home/* User home directories
/*/app/* User application software directories
/*/app/applmgr Oracle applications software subtrees
/*/app/oracle/product Oracle software subtrees
/*/app/oracle/product/11.2.0 Oracle software subtree for release 11g products
/*/app/oracle/product/11.2.0/db* Oracle home directories for Oracle Database 11g
/*/app/oracle/product/11.2.0/grid* Oracle home directory for Oracle Grid Infrastructure 11g for a standalone server, for user oracle
/*/app/oracle/admin/orcl orcl database administrative subtrees
/*/app/oracle/admin/orcl/arch/* orcl database archived log files
/*/app/oracle/oradata Oracle data directories
/*/app/oracle/oradata/orcl/* orcl database files
/*/app/oracle/oradata/orcl/*.log orcl database redo log files


Высоконагруженные сайты, доступность «5 nines». На заднем фоне (backend) куча обрабатываемой информации в базе данных. А что, если железо забарахлит, если вылетит какая-то давно не проявлявшаяся ошибка в ОС, упадет сетевой интерфейс? Что будет с доступностью информации? Из чистого любопытства я решил рассмотреть, какие решения вышеперечисленным проблемам предлагает Oracle. Последние версии, в отличие от Oracle 9i, называются Oracle 10g (или 11g), где g – означает «grid», распределенные вычисления. В основе распределенных вычислений «как ни крути» лежат кластера, и дополнительные технологии репликации данных (DataGuard, Streams). В этой статье в общих чертах описано, как устроен кластер на базе Oracle 10g. Называется он Real Application Cluster (RAC).

Статья не претендует на полноту и всеобъемлемость, также в ней исключены настройки (дабы не увеличивать в объеме). Смысл – просто дать представление о технологии RAC.

Статью хотелось написать как можно доступнее, чтобы прочесть ее было интересно даже человеку, мало знакомому с СУБД Oracle. Поэтому рискну начать описание с аспектов наиболее часто встречаемой конфигурации БД – single-instance, когда на одном физическом сервере располагается одна база данных (RDBMS) Oracle. Это не имеет непосредственного отношения к кластеру, но основные требования и принципы работы будут одинаковы.

Введение. Single-instance.

  • область хранения данных, т.е. физические файлы на диске (datastorage) (сама БД)
  • экземпляр БД (получающая и обрабатывающая эти данные в оперативной памяти) (СУБД)


Во всех современных реляционных БД данные хранятся в таблицах. Таблицы, индексы и другие объекты в Oracle хранятся в логических контейнерах – табличных пространствах (tablespace). Физически же tablespace располагаются в одном или нескольких файлах на диске. Хранятся они следующим образом:
Каждый объект БД (таблицы, индексы, сегменты отката и.т.п.) хранится в отдельном сегменте – области диска, которая может занимать пространство в одном или нескольких файлах. Сегменты в свою очередь, состоят из одного или нескольких экстентов. Экстент – это непрерывный фрагмента пространства в файле. Экстенты состоят из блоков. Блок – наименьшая единица выделения пространства в Oracle, по умолчанию равная 8K. В блоках хранятся строки данных, индексов или промежуточные результаты блокировок. Именно блоками сервер Oracle обычно выполняет чтение и запись на диск. Блоки имеют адрес, так называемый DBA (Database Block Address).


При любом обращении DML (Data Manipulation Language) к базе данных, Oracle подгружает соответствующие блоки с диска в оперативную память, а именно в буферный кэш. Хотя возможно, что они уже там присутствуют, и тогда к диску обращаться не нужно. Если запрос изменял данные (update, insert, delete), то изменения блоков происходят непосредственно в буферном кэше, и они помечаются как dirty (грязные). Но блоки не сразу сбрасываются на диск. Ведь диск – самое узкое место любой базы данных, поэтому Oracle старается как можно меньше к нему обращаться. Грязные блоки будут сброшены на диск автоматически фоновым процессом DBWn при прохождении контрольной точки (checkpoint) или при переключении журнала.


  1. Что будет, если Oracle упадет где-то на середине длинной транзакции (если бы она вносила изменения)?
  2. Какие же данные прочтет первая транзакция, когда в кэше у нее «под носом» другая транзакция изменила блок?
  • журнал повтора (redo log)
  • сегмент отмены (undo)


Когда в базу данных поступает запрос на изменение, то Oracle применяет его в буферном кэше, параллельно внося информацию, достаточную для повторения этого действия, в буфер повторного изменения (redo log buffer), находящийся в оперативной памяти. Как только транзакция завершается, происходит ее подтверждение (commit), и сервер сбрасывает содержимое redo buffer log на диск в redo log в режиме append-write и фиксирует транзакцию. Такой подход гораздо менее затратен, чем запись на диск непосредственно измененного блока. При сбое сервера кэш и все изменения в нем потеряются, но файлы redo log останутся. При включении Oracle начнет с того, что заглянет в них и повторно выполнит изменения таблиц (транзакции), которые не были отражены в datafiles. Это называется «накатить» изменения из redo, roll-forward. Online redo log сбрасывается на диск (LGWR) при подтверждении транзакции, при прохождении checkpoint или каждые 3 секунды (default).

С undo немного посложнее. С каждой таблицей в соседнем сегменте хранится ассоциированный с ней сегмент отмены. При запросе DML вместе с блоками таблицы обязательно подгружаются данные из сегмента отката и хранятся также в буферном кэше. Когда данные в таблице изменяются в кэше, в кэше так же происходит изменение данных undo, туда вносятся «противодействия». То есть, если в таблицу был внесен insert, то в сегмент отката вносится delete, delete – insert, update – вносится предыдущее значение строки. Блоки (и соответствующие данные undo) помечаются как грязные и переходят в redo log buffer. Да-да, в redo журнал записываются не только инструкции, какие изменения стоит внести (redo), но и какие у них противодействия (undo). Так как LGWR сбрасывает redo log buffer каждые 3 секунды, то при неудачном выполнении длительной транзакции (на пару минут), когда после минуты сервер упал, в redo будут записи не завершенные commit. Oracle, как проснется, накатит их (roll-forward), и по восстановленным (из redo log) в памяти сегментам отката данных отменит (roll-back) все незафиксированные транзакции. Справедливость восстановлена.

Кратко стоит упомянуть еще одно неоспоримое преимущество undo сегмента. По второму сценарию (из схемы) когда select дойдет до чтения блока (DBA) 500, он вдруг обнаружит что этот блок в кэше уже был изменен (пометка грязный), и поэтому обратится к сегменту отката, для того чтобы получить соответствующее предыдущее состояние блока. Если такого предыдущего состояния (flashback) в кэше не присутствовало, он прочитает его с диска, и продолжит выполнение select. Таким образом, даже при длительном «select count(money) from bookkeeping» дебет с кредитом сойдется. Согласованно по чтению (CR).

Отвлеклись. Пора искать подступы к кластерной конфигурации. =)

Уровень доступа к данным. ASM.


Хранилищем (datastorage) в больших БД почти всегда выступает SAN (Storage Area Network), который предоставляет прозрачный интерфейс серверам к дисковым массивам.
Сторонние производители (Hitachi, HP, Sun, Veritas) предлагают комплексные решения по организации таких SAN на базе ряда протоколов (самым распространенным является Fibre Channel), с дополнительными функциональными возможностями: зеркалирование, распределение нагрузки, подключение дисков на лету, распределение пространства между разделами и.т.п.
Позиция корпорации Oracle в вопросе построения базы данных любого масштаба сводится к тому, что Вам нужно только соответствующее ПО от Oracle (с соответствующими лицензиями), а выбранное оборудование – по возможности (если средства останутся после покупки Oracle :). Таким образом, для построения высоконагруженной БД можно обойтись без дорогостоящих SPARC серверов и фаршированных SAN, используя сервера на бесплатном Linux и дешевые RAID-массивы.

На уровне доступа к данным и дискам Oracle предлагает свое решение – ASM (Automatic Storage Management). Это отдельно устанавливаемый на каждый узел кластера мини-экземпляр Oracle (INSTANCE_TYPE = ASM), предоставляющий сервисы работы с дисками.

Oracle старается избегать обращений к диску, т.к. это является, пожалуй, основным bottleneck любой БД. Oracle выполняет функции кэширования данных, но ведь и файловые системы так же буферизуют запись на диск. А зачем дважды буферизировать данные? Причем, если Oracle подтвердил транзакцию и получил уведомления том, что изменения в файлы внесены, желательно, чтобы они уже находились там, а не в кэше, на случай «падения» БД. Поэтому рекомендуется использовать RAW devices (диски без файловой системы), что делает ASM.

  • отсутствие необходимости в отдельном ПО для управления разделами дисков
  • нет необходимости в файловой системе
  • Зеркалирование данных:
    как правило, 2-х или 3-х ступенчатое, т.е. данные одновременно записываются на 2 или 3 диска. Для зеркалирования диску указываются не более 8 дисков-партнеров, на которые будут распределяться копии данных.
  • Автоматическая балансировка нагрузки на диски (обеспечение высокой доступности):
    если данные tablespace разместить на 10 дисках и, в некоторый момент времени, чтение данных из определенных дисков будет «зашкаливать», ASM сам обратится к таким же экстентам, но находящимся на зеркалированных дисках.
  • Автоматическая ребалансировка:
    При удалении диска, ASM на лету продублирует экстенты, которые он содержал, на другие оставшиеся в группе диски. При добавлении в группу диска, переместит экстенты в группе так, что на каждом диске окажется приблизительно равное число экстентов.

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

Пора на уровень повыше.

Clusterware. CRS.

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

CRS (Cluster-Ready Services) – набор сервисов, обеспечивающий совместную работу узлов, отказоустойчивость, высокую доступность системы, восстановление системы после сбоя. CRS выглядит как «мини-экземпляр» БД (ПО) устанавливаемый на каждый узел кластера. Устанавливать CRS – в обязательном порядке для построения Oracle RAC. Кроме того, CRS можно интегрировать с решениями clusterware от сторонних производителей, таких как HP или Sun.

Опять немного «терминологии»…

  • CSSD – Cluster Synchronization Service Daemon
  • CRSD – Cluster Ready Services Daemon
  • EVMD – Event Monitor Daemon

Как уже стало ясно из таблички, самым главным процессом, «самым могущественным демоном», является CRSD (Cluster Ready Services Daemon). В его обязанности входит: запуск, остановка узла, генерация failure logs, реконфигурация кластера в случае падения узла, он также отвечает за восстановление после сбоев и поддержку файла профилей OCR. Если демон падает, то узел целиком перезагружается. CRS управляет ресурсами OCR: Global Service Daemon (GSD), ONS Daemon, Virtual Internet Protocol (VIP), listeners, databases, instances, and services.

  • Node Membership (NM).Каждую секунду проверяет heartbeat между узлами. NM также показывает остальным узлам, что он имеет доступ к так называемому voting disk (если их несколько, то хотя бы к большинству), делая регулярно туда записи. Если узел не отвечает на heartbeat или не оставляет запись на voting disk в течение нескольких секунд (10 для Linux, 12 для Solaris), то master узел исключает его из кластера.
  • Group Membership (GM). Функция отвечает за своевременное оповещение при добавлении / удалении / выпадении узла из кластера, для последующей реконфигурации кластера.

Информатором в кластере выступает EVMD (Event Manager Daemon), который оповещает узлы о событиях: о том, что узел запущен, потерял связь, восстанавливается. Он выступает связующим звеном между CRSD и CSSD. Оповещения также направляются в ONS (Oracle Notification Services), универсальный шлюз Oracle, через который оповещения можно рассылать, например, в виде SMS или e-mail.

Стартует кластер примерно по следующей схеме: CSSD читает из общего хранилища OCR, откуда считывает кластерную конфигурацию, чтобы опознать, где расположен voting disk, читает voting disk, чтобы узнать сколько узлов (поднялось) в кластере и их имена, устанавливает соединения с соседними узлами по протоколу IPC. Обмениваясь heartbeat, проверяет, все ли соседние узлы поднялись, и выясняет, кто в текущей конфигурации определился как master. Ведущим (master) узлом становится первый запустившийся узел. После старта, все запущенные узлы регистрируются у master, и впоследствии будут предоставлять ему информацию о своих ресурсах.

Уровнем выше CRS на узлах установлены экземпляры базы данных.
Друг с другом узлы общаются по private сети – Cluster Interconnect, по протоколу IPC (Interprocess Communication). К ней предъявляются требования: высокая ширина пропускной способности и малые задержки. Она может строиться на основе высокоскоростных версий Ethernet, решений сторонних поставщиков (HP, Veritas, Sun), или же набирающего популярность InfiniBand. Последний кроме высокой пропускной способности пишет и читает непосредственно из буфера приложения, без необходимости в осуществлении вызовов уровня ядра. Поверх IP Oracle рекомендует использовать UDP для Linux, и TCP для среды Windows. Также при передаче пакетов по interconnect Oracle рекомендует укладываться в рамки 6-15 ms для задержек.

Читайте также: