X

Блог Oracle в России и СНГ

Новое в СУБД Oracle: упрощение администрирования и эффективное использование оборудования с новой мультиарендной архитектурой

Автономность и искусственный интеллект, мультимодельность и конвергентность, база данных как сервис, работа с энергонезависимой памятью, эти и другие возможности, уже реализованные в СУБД Oracle, задают направления совершенствования современных СУБД. Сегодня в блоге мы публикуем первую часть статьи о тенденциях развития и возможностях баз данных, где объясняются основные особенности новой мультиарендной архитектуры и преимущества для системных администраторов баз данных, разработчиков и тестировщиков.

Коммерческие реляционные СУБД быстро развиваются и широко востребованы на рынке. Oracle непрерывно совершенствует свой флагманский продукт СУБД Oracle Database. Новые возможности версий Oracle Database 19с и 20c иллюстрируют перспективные направления развития современных средств работы с базами данных.:

  • Создание мощных коммерческих СУБД, одинаково эффективно работающих в разных средах (ЦОД заказчика, частное, публичное или гибридное облако, машина баз данных Exadata, Cloud at Customer – фрагмент публичного облака, развернутый в ЦОД заказчика). Иначе говоря, современная база данных может работать и как СУБД, и как сервис.
  • Самоуправляемость, автономность и одновременное управление множеством БД с использованием алгоритмов искусственного интеллекта
  • Мультимодельность и конвергентность – поддержка в одной СУБД множества типов данных  (реляционные, геоинформация, текст, JSON, NO SQL, XML, Hadoop, Spark, мультимедиа и пр.) и множества разных нагрузок (OLTP, системы поддержки принятия решений, интернет вещей, хранилища, блокчейн, «ключ-значение» и т. д.).
  • In-memory вычисления и использование векторных команд процессоров.
  • Работа с энергонезависимой памятью.
  • Разделение базы данных между несколькими серверами (шардинг).
  • Встраивание новых технологий в СУБД (блокчейн, машинное обучение, интернет вещей, JSON и т д).

Кроме того, естественно, продолжается работа над повышением надежности, производительности, безопасности, масштабируемости и управляемости СУБД.

С 2013 года, когда вышла версия 12.1,  в СУБД Oracle было добавлено множество новых возможностей, появились автономные БД и механизмы самоуправления. Новые версии выходят постоянно, однако, недавно порядок их выхода изменился. Раньше новая версия появлялась каждые 3-4 года и в течение этого времени выходили два релиза версии. Теперь, начиная с версии 18с, новая версия СУБД будет выпускаться каждый год и ее номер будет совпадать с номером года. Таким образом, теперь есть версии 18с, 19с, в 2020 году выходит версия 20с.

Все новые версии теперь делятся на промежуточные и долговременные. Промежуточные позволяют попробовать новые возможности и хороши для разработчиков и тех, для кого новые функции важны. Долговременные версии более стабильны, имеют долгий срок технической поддержки (4 года + 2 года расширенной поддержки) и предпочтительны для промышленной эксплуатации.  Первый долговременный релиз –  Oracle Database 19c, на него и рекомендуется переводить промышленные системы. Поэтому нет смысла отдельно говорить об отличиях СУБД Oracle 12.2, 18c, 19c.  Мы рассмотрим новые возможности в Oracle Database 19c по сравнению с Oracle Database 12.1 и коротко расскажем об основных новшествах Oracle Database 20c.  Наиболее важными являются следующие:

  • мультиарендная архитектура (опция Multitenant);
  • механизмы векторной обработки данных в оперативной памяти (опция In-Memory)
  • шардинг (параллельное хранение и обработка частей таблиц/групп таблиц на различных компьютерах);
  • автономные базы данных;
  • работа с энергонезависимой памятью.

Рассмотрим эти новые возможности подробнее и начнем с изменений в архитектуре СУБД и работе с большими базами данных.

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

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

В случае мультиарендной (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 превратится в доступный для чтения обновляемый мастер-клон, т.е. происходит переключение (PDB switchover) – смена ролей.

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

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

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

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

Серверные процессы ОС имеют доступ к файлам БД и могут читать или модифицировать файлы других PDB. Чтобы избежать этого, в версии 20с вводится механизм DB Nest. Все процессы ОС экземпляра 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.

Хранилища данных и большие БД

В Oracle Database 19c можно создавать гибридные секционированные таблицы. Часть секций такой таблицы – это обычные секции в БД, а часть – внешние (external), размещенные в файлах ОС или на системе облачного хранения. SQL-операторы видят этот набор секций как единую внутреннюю таблицу БД. Поддерживаются все виды внешних секций, которые можно загружать с помощью SQL Loader и Data Pump, можно использовать в качестве секций файлы Hadoop  (формат HDFS и Hive). Внешние секции доступны только для чтения. Гибридное секционирование позволяет, например, легко и быстро перемещать архивные данные из базы данных в Hadoop и сохранять доступ к ним, не переписывая приложения. Это позволяет заметно снизить стоимость хранения.

Многие приложения используют временные таблицы, но до версии 18с можно было создавать только глобальные временные таблицы. Они были видны для всех сессий и существовали в БД постоянно, но каждая сессия помещала туда свои данные для работы с ними. Затем данные автоматически удалялись по завершении транзакции (commit), либо при завершении сессии. Теперь для сессии можно создавать частные временные таблицы (private temporary table). Они размещаются в оперативной памяти, другие сессии их не видят и не имеют к ним доступа. Такая таблица автоматически удаляется либо по окончании транзакции, либо по окончании сессии. Частные временные таблицы можно создавать и на резервной БД.

Oracle стремится минимизировать время простоя и задержки при любых операциях с объектами БД. Теперь практически все операции с секциями таблиц и их индексами (создание, перемещение, удаление, изменение, расщепление, преобразование типа секционирования и т.д.) можно выполнять онлайн, без остановки работы с таблицами.

В следующей части мы подробнее расскажем о том, как опция In-Memory Database позволяет ускорить выполнение аналитических запросов, что такое шардинг и как он помогает повысить надежность СУБД.

Автор – Марк Ривкин, руководитель группы баз данных технологического консалтинга Oracle в России и СНГ

 

Авторский вариант статьи опубликован в журнале «Открытые системы. СУБД», #2, 2020

 

 

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.