Мультиарендная архитектура СУБД | С нами строить легко

Мультиарендная архитектура СУБД

Новая архитектура СУБД Oracle позволяет упростить сопровождение множества баз данных Oracle и повысить эффективность использования оборудования. В традиционной архитектуре для каждой новой БД создается свой набор файлов этой БД на дисках, а для работы с ней запускается отдельный экземпляр Oracle (Instance), который занимает часть оперативной памяти компьютера и запускает набор фоновых процессов. Если на одном компьютере необходимо развернуть 10 баз данных, то создается 10 наборов файлов на дисках, запускается 10 наборов фоновых процессов и в оперативной памяти выделяется 10 областей. Про администрирование субд oracle читайте тут.

В случае мультиарендной (multitenant) архитектуры создается одна контейнерная база данных (Container Database, CDB), которую обслуживает один экземпляр Oracle.  А все вновь создаваемые БД (они называются подключаемыми – Pluggable Database, PDB) помещаются в эту контейнерную БД. При этом для обслуживания множества независимых БД используются один набор процессов и одна область оперативной памяти.

Мультиарендная архитектура

Cтарый словарь БД разделяется на 2 части. Общая для всех PDB часть словаря хранится в CDB, а в каждой PDB хранится информация словаря, специфичная для данной PDB.  Мультиарендная БД имеет один набор журнальных файлов (redo logs) и один набор управляющих файлов, общих для всех PDB в контейнерной БД.

Такой подход позволяет на одном компьютере разместить гораздо больше БД и избежать проблем дублирования и несовместимости объектов, которую мы имеем  при консолидации схем БД. Как показывает тестирование, на одном и том же компьютере помещается в 50 раз больше БД новой архитектуры за счет более эффективного использования памяти, процессоров и дисков. Подключаемые БД (PDB) не зря так называют и изображают в виде флешки. Их можно легко отключить от одной CDB и подключить к другой. Например, при переносе PDB из CDB версии 12с в CDB версии 20с, PDB автоматически обновляется до версии 20с.

Новая архитектура значительно упрощает администрирование множества баз данных. Если раньше DBA приходилось администрировать, скажем, 10 баз данных и экземпляров, то, превратив эти БД в PDB, потребуется администрировать только один экземпляр СУБД Oracle. Больше не надо делать бэкап для каждой БД – достаточно сделать один для CDB, откуда можно будет восстановить нужную PDB. Теперь можно создать одну резервную базу данных для CDB и все текущие и вновь создаваемые PDB будут иметь резервную БД. Кроме того, для CDB можно сконфигурировать кластер (RAC), это автоматически повысит надежность всех подключенных PDB. Чтобы обеспечить изолированность и масштабируемость, отдельные PDB можно закрепить за конкретными узлами RAC. В CDB очень просто делать клоны PDB, существующих в этой или другой CDBкоторые будут обновляться по мере обновления исходных PDB.

И, конечно, упрощается апгрейд и патчирование баз данных.  Вместо 10 обновлений для 10 БД достаточно обновить CDB и все PDB автоматически обновятся до новой версии. Если же апгрейд или патчирование нужны не для всех PDB, а лишь для части, то их просто надо перенести в CDB новой версии. Перенос PDB из одной CDB в другую осуществляется одной командой (или кликом мышки в Enterprise Manager), по которой метаинформация о PDB выгружается в xml-файл, а затем загружается в другую CDB. Если CDB размещаются на одном компьютере, то даже копировать файлы БД PDB не придется.

В новой CDB можно сделать клон PDB из другой CDB. При клонировании в режиме горячего обновления (hot refreshable) исходная PDB остается открытой для изменений во время клонирования. После окончания клонирования изменения применяются к клону. Далее синхронизация клона и исходной PDB периодически повторяется в автоматическом или ручном режиме. Таким образом, всегда имеется открытая на чтение свежая копия мастер-клона в новой CDB, где можно создавать новые клоны PDB, доступные для изменений. Это очень удобно для разработчиков приложений.

Исходная PDB и синхронизируемый с ней клон в другой CDB – это своего рода вариант резервной БД. Как и в случае резервной БД, PDB-клон можем переключить в режим основной, открытой для изменений PDB. Тогда исходная PDB превратится в доступный для чтения обновляемый мастер-клон, т.е. происходит переключение (PDBswitchover) – смена ролей.

Разработчикам и тестировщикам приложений часто требуется восстановить базу данных на определенный момент времени в прошлом. Для отдельной PDB это можно сделать с помощью механизма flashback, но можно применить новый механизм – карусель снэпшотов (snapshot carousel). При активированном режиме карусели ежедневно будет автоматически сохраняться копия PDB в архивном файле (такая копия называется снимком, или снэпшотом). По умолчанию хранятся последние 8 снимков. Если, например, в среду необходимо восстановить PDB по состоянию на 5 ч вечера понедельника, то мы просто восстанавливаем PDB из снэпшота за понедельник и далее накатываем архивные журналы, чтобы применить изменения, сделанные до 5 ч вечера.

Еще один интересный механизм мультиарендной базы данных – ApplicationContainer (AC). Если несколько PDB имеют одинаковые объекты (таблицы, процедуры, функции и т д), то их можно поместить в отдельную PDB, называемую application container. Все PDB, наследующие объекты этого контейнера, будут видеть эти объекты. Это устраняет дублирование и облегчает сопровождение объектов (они изменяются в одном месте – application container). Причем, если таким разделяемым объектом является таблица, то есть 3 варианта:

  • Хранить таблицу со всеми данными в AC (тогда PDB  будут видеть ее как таблицу, открытую на чтение)
  • Хранить таблицу и часть ее данных в АС (тогда каждая PDB будет видеть эти данные в режиме чтения, но может иметь свою открытую на изменение часть этой таблицы)
  • Хранить только описание структуры таблицы в АС (тогда каждая PDB будет иметь свой, скрытый от других, открытый для изменений вариант этой таблицы)

PDB базы изолированы друг от друга. Управлять разделением ресурсов компьютера (память, процессоры, ввод/вывод, параллелизм) между PDB можно с помощью менеджера ресурсов. Механизм блокирования профиля (lockdown profiles) позволяет ограничить выполнение отдельных команд SQL и их частей для конкретной PDB, запретить выполнение некоторых потенциально опасных команд (например: alter system) и команд операционной системы и даже блокировать прямой доступ к PDB.

Серверные процессы ОС имеют доступ к файлам БД и могут читать или модифицировать файлы других PDB. Чтобы избежать этого, в версии 20с вводится механизм DBNest. Все процессы ОС экземпляра Oracle можно разделить на две группы: фоновые и серверные (они обслуживают сессии и SQL отдельных пользователей).  DB Nest позволяет запретить серверным процессам конкретной PDB доступ к файлам БД, файлам трассировки, файлам настройки других PDB. Им также можно запретить доступ к областям памяти (pga) других PDB и выполнение команд ОС. Механизм схож с контейнеризацией в ОС: каждая PDB работает как бы в отдельном контейнере и изолирована от других.

С PDB можно работать как с обычной базой данных, соответственно, у нее есть и традиционные средства настройки.  Она имеет свой автоматический репозиторий для хранения статистики о работе базы данных (Automatic Workload Repository, AWR), периодически запускается анализ статистики для выявления проблем (Automatic Database Diagnostic Monitor, ADDM). Отчеты AWR можно строить на уровне PDB и получать рекомендации по настройке базы данных. Тестирование под нагрузкой (Real Application Testing, RAT) можно запускать на отдельной PDB, чтобы захватить, а потом и воспроизвести нагрузку и оценить влияние изменений на эту PDB.

Мультиарендная архитектура доказала свои преимущества, на ней построены все автономные базы данных Oracle и с версии 20с Oracle будет поддерживать только эту новую архитектуру. Те, кто хочет по-прежнему иметь один экземпляр Oracle для каждой БД, могут создавать CDB с одной PDB. Бесплатно можно создавать до 3 PDB в одной CDB, если требуется больше – следует лицензировать опцию Multitenant.