СУБД для облаков

При обозначении версий СУБД Oracle обычно применяются суффиксы для указания их предназначений. Например, (i,g) — платформа для интернет- и грид-приложений, а недавно появился суффикс (c) в версии Oracle Database 12c, указывающий на «облачность» версии (cloud). Одновременно оказалось, что интересные новшества этой СУБД тоже начинаются с буквы «c»: консолидация баз данных (consolidation), средства автоматического сжатия данных (compression) и повтора прервавшихся транзакций (continuity).

Консолидация и мультиарендность

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

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

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

Третий вариант — консолидация схем из разных баз данных в одной. Это пока самый эффективный способ, но он и сложнее, так как схемы конфликтуют между собой по имени объектов, используют разные варианты процедур, требуют разных параметров настройки СУБД и т. д.

В Oracle Database 12c реализован еще один вариант консолидации, потребовавший изменения всей архитектуры СУБД, и теперь у пользователя есть выбор — развернуть СУБД по старой традиционной архитектуре или реализовать мультиарендную (multitenant) архитектуру.

Каждая база данных Oracle — это набор файлов на дисках; для работы с базой запускается один (в случае кластера — несколько) экземпляр СУБД, который получает SQL-запросы, выполняет их и возвращает результат. При запуске каждый экземпляр забирает себе область оперативной памяти и запускает набор процессов ОС, использующих эту общую разделяемую область памяти и обеспечивающих работу базы. Однако, в отличие от того варианта, когда на одном физическом компьютере размещается несколько баз, в мультиарендной архитектуре (рис. 1) для консолидации создается одна контейнерная база данных (Container Database, CDB). Все консолидируемые базы помещаются в этот контейнер, а один экземпляр Oracle обслуживает все базы в нем. При таком подходе ресурсы компьютера используются эффективнее, причем базы можно не только помещать в контейнерную, но и извлекать из нее и переносить в другие контейнерные базы (подключаемые базы назвали Pluggable Database, PDB). После помещения в контейнерную базу все PDB остаются изолированными и независимыми — приложения, которые работают с ними, менять не надо.

Рис. 1. Мультиарендная архитектура

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

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

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

В новой архитектуре облегчается процесс передачи базы заказчикам — достаточно отключить PDB от контейнерной базы и передать получившийся XML-файл и файлы отключенной базы заказчику, после чего тот выполнит операцию подключения и начнет работать с новой базой.

Для повышения надежности и скорости работы консолидированных баз лучше использовать несколько экземпляров СУБД, применяя Real Application Cluster для действий с консолидированной базой и ее PDB. При этом механизм сервисов позволит определить, какие узлы кластера будут работать с узлами PDB.

Оптимизация хранения

Объемы данных, хранимых в базах, постоянно растут, и справляться с ними становится все труднее — надо либо сжимать данные (но желательно без ущерба для производительности), либо перемещать редко используемые данные на более дешевые и медленные носители. В СУБД Oracle имеется механизм управления жизненным циклом — ILM Assistant, подсказывающий администратору, какие данные можно сжимать/перемещать. Однако выполнять эти операции до сих пор приходилось вручную, а рекомендации формировались не на основе реальной информации об использовании данных, а исходя из значения данных (например, сжимались данные о продажах прошлого года или данные о конкретных регионах). Кроме того, известно, что введенные в базу данные сначала очень активны (горячие данные) — их часто запрашивают и изменяют, а затем они начинают «остывать» (они еще запрашиваются, но уже редко обновляются). В Oracle Database 12c вводится понятие температурной карты (Heat Map), на которой можно видеть «температуру» данных (горячие, теплые, холодные). Температурная карта уровня базы данных показывает, как используются таблицы и секции (partitions), а карта уровня блока показывает, когда последний раз изменялся блок данных. На основе этой информации можно указать, когда надо выполнять те или иные действия по сжатию/перемещению данных — например, блоки данных, которые не менялись более недели, можно сжать в два-три раза, оставляя доступными для быстрой модификации данных, а таблицы/секции, которые не менялись более года, можно сжать в 15–50 раз для архивного хранения. Имея информацию по политикам перемещения данных и температурную карту, Oracle Database 12c автоматически выполняет действия по сжатию/перемещению данных.

В СУБД Oracle имеется механизм FLASHBACK QUERY, позволяющий на текущей базе сделать запрос данных в прошлом.  Например, указав в операторе SELECT фразу «AS OF ‘1-JAN-2013’», вы получите результат без учета изменений данных, произошедших после 1 января 2013 года. Этот механизм (Transaction-Time Temporal) учитывает только информацию о реальном изменении данных. Представим, что имеется таблица, в которую занесены сотрудники, и надо нанять нового, но он выйдет на работу не сегодня, а только 1 сентября 2014 года. Более того, три месяца у него будет зарплата испытательного периода, а с 1 декабря станет штатной. Если сейчас ввести сведения об этом сотруднике, то запрос к таблице покажет эту информацию сразу, хотя она вступит в силу только 1 сентября. Новый механизм Valid-Time Temporal позволяет ввести данные о сотруднике сейчас, но указать в отдельных полях даты начала и конца актуальности записи.

Надежность

Больше всего нововведений в Oracle Database 12c связано с обеспечением надежности работы СУБД и приложений.

При заказе билетов или товаров через Интернет многие сталкивались с такой ситуацией, когда, выбрав товар и введя данные кредитной карты, не получали подтверждения о выполнении операции, тогда как при повторной попытке подтверждение приходило. Однако часто оказывается, что товар оплачен дважды — пришедшая в базу транзакция выполнилась первый раз успешно, но получить подтверждение сервер приложения или клиент не успел. Чтобы избежать этого, в Oracle Database 12c встроен компонент Transaction Guard, работающий на сервере и знающий, зафиксирована или нет транзакция. Например, при работе в кластере баз данных можно в случае сбоя клиента выполнять транзакцию через первый узел, а сервер приложений, получив информацию об ошибке, при выполнении транзакции через другой узел кластера сможет спросить у Transaction Guard, а была ли зафиксирована эта транзакция. Если да, то повторять ее не надо и клиент получит информацию об успешном завершении транзакции. Transaction Guard имеет свой API, но в большинстве случаев драйвер JDBC все сделает автоматически через механизм Application Continuity — зная, что транзакция не завершилась, можно ее повторить.

Пользователи кластера Oracle знакомы с механизмом TAF (Transparent Application Failover) — если через один узел кластера выполняется оператор SELECT, выводящий данные из базы, и происходит сбой этого узла, то клиент получит сообщение о сбое и повторяет этот запрос через другой узел кластера. Вывод данных прерванного оператора продолжается с той точки, где произошел сбой, и пользователь нничего не замечает. Похожий механизм (но для транзакции) реализует Application Continuity. В случае если драйвер JDBC получит сообщение о сбое при выполнении транзакции, он проверит, восстановимый ли это сбой и действительно ли транзакция не зафиксирована, а затем повторит выполнение транзакции, поэтому сбой не приведет к ошибке приложения. Разработчик приложения может указать, какие транзакции нельзя повторять автоматически.

Для повышения надежности работы приложений и борьбы с катастрофическими сбоями пользователи СУБД Oracle часто применяют механизм создания резервных баз данных в удаленных резервных центрах обработки данных. Синхронизацией основной и резервных баз занимается компонент Data Guard с опцией Active Data Guard (ADG), позволяющий открыть резервную базу на чтение, не останавливая синхронизацию данных. Резервные базы могут синхронизироваться с основной либо в синхронном, либо в асинхронном режиме. При синхронном — работа основного узла продолжается только после получения информации о том, что изменения основного узла приняты и записаны резервным узлом. Это влияет на производительность основной базы, но защищает от потери данных. В случае асинхронной передачи основная база не ждет подтверждения, но тогда нет гарантии, что изменения достигли резервной базы. Задержка работы основной базы при синхронном режиме работы Data Guard прямо пропорциональна расстоянию между основным и резервным ЦОД, которое сегодня может быть весьма значительным. Чтобы не потерять данные и не снижать производительность основной базы, рядом с ней ставилась резервная, и ее Data Guard работал с основной в синхронном режиме (расстояние невелико). Вторая резервная создавалась далеко от первой, и ее Data Guard работал с первой резервной базой уже в асинхронном режиме — первая резервная выполняла роль посредника, хотя и представляла собой полномасштабную базу с данными. Новый механизм в Oracle Database 12c, получивший название Far Sync, позволяет заменить этот посредник на облегченный вариант экземпляра СУБД Oracle ADG Far Sync, который не содержит файлов данных, а имеет только управляющие и журнальные файлы. Посредник передает изменения даже после выхода из строя основной базы. Кстати, если после переключения на удаленную резервную базу надо перевести бывшую основную базу в резервный режим и организовать синхронизацию в обратную сторону, то можно разместить еще один ADG Far Sync возле бывшей удаленной резервной базы и заставить его работать с ней в синхронном режиме. А уже он будет в асинхронном режиме передавать изменения своему двойнику, размещенному рядом с бывшей основной базой.

В новой версии СУБД появился механизм Global Data Services (GDS), позволяющий решить проблему балансировки нагрузки между разными копиями одной промышленной базы данных. При работе с кластером, в котором несколько экземпляров СУБД Oracle работают с одной базой, при открытии сеанса экземпляр перебрасывается на наименее загруженный узел кластера. Тем самым осуществляется балансировка нагрузки, однако сегодня, когда имеется много неравномерно нагруженных копий одной и той же базы (резервные узлы, открытые на чтение; копии, синхронизирующиеся через Golden Gate и открытые для изменений), требуется осуществлять балансировку уже не между узлами кластера одной базы, а между ее копиями, возможно удаленными друг от друга. Именно эту задачу решает механизм GDS. Приложение устанавливает связь не с конкретным экземпляром базы или кластером, а с глобальным сервисом, который затем переключает эту связь на одну из баз глобального сервиса. Введено понятие пула GDS — набора одинаковых баз, которые могут предоставлять один сервис, и GDS региона — группы баз и клиентов отдельной сети. Это позволяет менеджеру глобальных сервисов выбрать конкретную базу данных с учетом ее загруженности и удаленности (регион) от клиента, учитывая время отклика каждой базы и отставание резервной копии от основной. Если одна из баз данных GDS-пула выходит из строя, то сервис может мигрировать на другую из того же региона, что позволяет приложениям всегда работать с наименее загруженными серверами (рис. 2).

Рис. 2. Восстановление после сбоя

В DataGuard появились такие возможности, как каскадный Data Guard в режиме реального времени (Real Time Cascade), проверка готовности к переключению основной и резервной базы, доступ к последовательностям и поддержка записи во временные таблицы на резервной базе.

В версиях СУБД Oracle с суффиксом i и g рекомендуется хранить базу не на обычной файловой системе, а через менеджер томов ASM (Automatic Storage Manager), обеспечивающий балансировку ввода-вывода, защиту от сбоев ввода-вывода за счет автоматической избыточности хранения блоков данных, увеличение скорости ввода-вывода за счет отсутствия файловой системы и т. д. Однако для этого необходимо было на каждом сервере баз данных и на каждом узле кластера запускать экземпляр ASM, что требовало дополнительных ресурсов, а при выходе из строя экземпляра ASM весь его сервер или узел кластера выходил из строя. Flex ASM позволяет разнести экземпляры ASM и Oracle по разным узлам кластера, причем один экземпляр ASM может обслуживать несколько экземпляров СУБД Oracle, которые могут находиться на разных узлах. Это расширяет пул ресурсов, доступных экземпляру СУБД Oracle, а при выходе из строя одного из экземпляров ASM экземпляры СУБД Oracle переключаются на оставшиеся работоспособные, что повышает надежность и производительность.

Новая команда ALTER DATABASE MOVE DATAFILE позволяет перемещать файлы данных базы на другие диски и в папки, не останавливая работу приложений и выполнение таких операций, как DROP INDEX (удаление индекса), ALTER INDEX UNUSABLE (пометить индекс как неиспользуемый), ALTER INDEX VISIBLE/UNVISIBLE (сделать индекс видимым или невидимым для SQL-оптимизатора), DROP CONSTRAINTS (удалить ограничение целостности), MOVE PARTITION (переместить секцию таблицы или индекса в другое табличное пространство).

Безопасность

Если требуется передать базу данных, содержащую конфиденциальные сведения, в другую организацию (разработчикам, тестировщикам), то можно замаскировать секретную информацию с помощью пакета OEM Masking Pack. Но что делать, если некоторым пользователям в процессе работы приложения надо показать незамаскированную информацию, а другим — искаженную, причем одновременно? Например, банковские программы должны видеть весь номер банковского счета, а пользователи из службы работы с заказчиками — только последние четыре цифры. Чтобы сделать это прозрачно на уровне базы данных, а не приложений, надо уметь искажать данные в момент выполнения запроса. Такое искажение выполняет механизм Data Redaction (рис. 3), работающий на основе политик, в которых описывается, для кого и как искажаются данные, причем для приложений все это прозрачно. Поддерживается четыре вида искажений: полное (подмена значения поля), частичное (подмена части значения — например, замена части символов звездочками), случайное (изменение символов на другие символы, но с сохранением формата), регулярные выражения (которые описывают правила искажения).

Рис. 3. Искажение данных на лету

Не секрет, что у многих пользователей имеются избыточные привилегии на выполнение операций, это увеличивает риски и снижает защиту, поэтому в Oracle Database 12c был введен механизм анализа привилегий. Администратор может посмотреть, какие привилегии реально требовал пользователь за определенный промежуток времени, сравнить их со списком имеющихся у него привилегий и отобрать лишние. В Oracle Database 12c также появились новые стандартные роли, которые ограничивают возможности администратора, выполняющего конкретный набор работ: роль SYSDG для администратора Data Guard и роль SYSBACKUP для выполнения операций резервного копирования и восстановления.

Управляемость

Еще одна интересная возможность Oracle Database 12c — оптимизация запросов на ходу путем перестраивания плана запроса. Теперь можно динамически изменять отдельные шаги плана выполнения SQL-запроса, если после первого выполнения оптимизатор распознал ошибочный план. Это позволяет решить проблему неактуальной статистики, поскольку теперь SQL-оптимизатор на ходу может перестраивать первоначально сгенерированный ошибочный план.

Для организации самоуправления в СУБД Oracle используется механизм ADDM (Automatic Data Diagnostic Manager), раз в час анализирующий статистику о работе СУБД, собранную в таблицах Automatic Workload Repository, и выявляющий проблемы и негативные тенденции. Обнаружив проблемы, менеджер либо их исправляет, либо сообщает администратору. Появившийся в Oracle Database 12c механизм Real Time ADDM работает в реальном времени, обновляя сведения каждые три секунды и оперативно обнаруживая проблемы, пики нагрузки, провалы производительности и т. д. Таким образом выполняется проактивный анализ. Кроме того, если СУБД «повисла» или работает медленно, то Real Time ADDM может напрямую подключиться к разделяемой области памяти и обнаружить причины проблем.

В Oracle Database 12c инструмент администрирования СУБД — DB Control заменен на встроенный в базу компонент OEM Database Express 12c, доступный через браузер и позволяющий администратору управлять объектами базы, конфигурациями (параметры, используемые опции, память), пользователями и ролями, а также выполнять диагностику и настройку СУБД. Для выполнения более сложных операций надо использовать OEM Cloud Control 12c, Release 3, который поддерживает новые возможности Oracle Database 12c.

Улучшения для разработчиков

СУБД Oracle Database 12с предлагает ряд новых возможностей для разработчиков. Перечислим некоторые из них.

• Встроенное определение PL/SQL-процедуры в SQL-запросе. Непосредственно в тексте SQL-запроса теперь можно указывать текст функции на PL/SQL, которая вызывается внутри запроса. Цель этого нововведения — уменьшить время переключения между модулем выполнения SQL и виртуальной машиной PL/SQL в процессе выполнения запроса.
• Расширенные возможности значений по умолчанию в столбцах таблиц. Включает две новые функции: автоинкрементные столбцы identity columns (значения которых вставляются автоматически из последовательности); установка значения по умолчанию при вставке NULL в поле, при этом в строке таблицы фактически не происходит замены NULL на значение по умолчанию, а устанавливается ссылка на словарь. В предыдущих версиях единственной возможностью создания автоинкрементных столбцов (столбцов, значения которых автоматически генерируются увеличением счетчика при вставке новой записи в таблицу) была самостоятельная разработка триггера на операцию вставки записи в таблицу, который получал очередное новое значение столбца из последовательности.
• Транслятор SQL-запросов из синтаксиса других СУБД. При миграции приложений из других СУБД на платформу Oracle Database часто требуется переписать тексты SQL-запросов. Для решения этой проблемы в Oracle Database 12с появился механизм автоматической трансляции текста SQL-запросов из синтаксиса других СУБД в формат Oracle Database (доступны модули для трансляции из синтаксиса СУБД Sybase, SQL Server и DB2). В случае необходимости программист может разработать собственный модуль SQL-трансляции.
• Невидимые столбцы. Такие столбцы не видны в результатах  обращения оператора SELECT к таблице в случае отсутствия явного указания их имен. Как и обычные столбцы, невидимые столбцы могут быть ключом секционирования в таблице, могут участвовать в вычисляемых выражениях в виртуальном столбце, сами могут быть виртуальными столбцами. Невидимые столбцы полезны при плавных обновлениях (patching) приложения, когда в новой его версии нужно удалить некоторые столбцы. В сочетании с технологией обновления приложения Edition Base Redefinition, невидимые столбцы обеспечивают большую гибкость при переходе на новую версию прикладной программы.
• Упрощенная загрузка данных. Утилита SQL*Loader предназначена для быстрой загрузки данных в СУБД из текстовых файлов, но в предыдущих версиях необходимо было вручную создавать управляющий файл, описывающий поля загружаемого текстового файла и их соответствие столбцам таблицы СУБД. В Oracle Database 12c достаточно в параметрах утилиты указать имя файла с данными и имя таблицы в СУБД, куда эти данные будут загружаться.
• Поддержка сопоставления записей по образцу. Часто в приложениях бизнес-аналитики необходимо формировать отчет на основе последовательности записей, удовлетворяющих некоторому правилу изменения значений. Например, если имеется таблица с упорядоченными по времени ценами на акции, то аналитикам часто приходится искать в ней некоторую модель поведения, выбирая группу записей, удовлетворяющих определенному правилу распределения данных. Эту задачу, называемую сопоставлением записей по образцу (Row Pattern Matching), решать приходилось на уровне приложения, а в языке SQL Oracle Database 12с появился оператор MATCH_RECOGNIZE, позволяющий задать модель изменения данных для выбираемых записей.

***

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

Марк Ривкин (mark.rivkin@oracle.com) — менеджер отдела технологического консалтинга, Игорь Мельников (igor.melnikov@oracle.com) — консультант, компания Oracle (Москва).