Автономные базы данных

Автономные базы данных

Марк Ривкин, SC Director, Oracle CIS

       Все системы хранения и обработки данных можно разделить на две группы: простые и сложные. Простые системы можно быстро и просто развернуть даже не специалисту, загрузить/ввести в них данные и начать использовать. Примерами таких систем могут служить MS Excel,  почта mail. ru или, если говорить про СУБД, очень популярная в 80-90 годы простенькая СУБД DBASE. Никто не говорит, что для работы с этими продуктами нужен администратор на стороне пользователя. Никто не обеспечивает многопользовательский режим или настройку производительности для MS Excel, обеспечение защиты данных сводится к установке пароля для файла, надежность обеспечивается копированием файла Excel и т д.  Мы догадываемся, что администраторы mail. ru поддерживают свою систему, но мы, как пользователи, просто создаем учетную запись и пользуемся почтой.

       Обратной стороной такой простоты является то, что сложные, бизнес критичные системы хранения и обработки данных на таких продуктах не делаются. Для этого созданы специальные коммерческие СУБД, такие как MS SQL Server, Oracle, DB2, PostgreSQL и т д. Они позволяют обеспечить высокую производительность, надежность, масштабируемость, безопасность, но за это приходится платить содержанием большого штата администраторов баз данных (АБД), постоянным выполнением ручных или автоматизированных операций по установке, настройке, сопровождению, бэкапированию и восстановлению баз данных (БД).

       Новое направление в области СУБД - Автономные базы данных призвано устранить это противоречие, совместить простоту создания и эксплуатации БД с мощностью современных  коммерческих СУБД.  В какой-то степени идея автономных БД перекликается с модной сегодня темой беспилотного или автономного  автомобиля.  В определении такого автомобиля выделяются пять уровней автономности (от 0 - есть только система уведомлений, до 5 - не требуется действия человека, кроме старта системы и указания пункта назначения) [Wukipedia]. Т е в случае автономного автомобиля 5 уровня человеку достаточно сесть в автомобиль и сообщить, куда нужно ехать. Все остальное выполнит система управления и поддержки  автономного автомобиля.

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

       Что же должна делать за администратора БД автономная БД? Если проанализировать наиболее трудоемкие задачи, выполняемые АБД, то они сведутся к следующим:

Конфигурирование операционной системы, сети, подсистемы хранения данных Установка СУБД Oracle, установка новых версий, установка патчей Резервное копирование, восстановление Развертывание новых сред (для тестирования, разработки  и т д) Построение отказоустойчивого решения Защита данных,  устранение дыр в безопасности Оптимизация работы БД,  настройка SQL Управление жизненным циклом данных Выявление ошибок в ПО и их устранение Выделение дополнительных вычислительных ресурсов (эластичность)

       Не забудем еще, что до начала работы  АБД  нужно получить IT инфраструктуру для установки БД и приложений (т е  компьютеры, сетевую инфраструктуру, систему хранения и т д). В случае автономной БД все эти задачи снимаются с АБД, их выполняет сама автономная БД.

       Итак, автономная БД  обеспечивает три основные функции:

       - Самоуправляемость (автоматически создает БД, выполняет апгрейды и патчирование,  бэкапы, настройку производительности, обеспечивает эластичность)

       - Самозащиту (защита от внешних и внутренних атак, оперативное исправление дыр в безопасности, шифрование данных, маскирование)

       - Самовосстановление (автоматическое восстановление после сбоев, защита от простоев, обеспечение заданного уровня сервиса (SLA))

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

       Архитектура автономной БД

       Какова же архитектура автономной БД Oracle?  Конечно в ее основе лежит  СУБД Oracle, начиная с версии 18с, но было бы ошибкой говорить, что Oracle 18c - автономная БД.  Автономная БД состоит из трех компонент, каждая из которых отвечает за разные аспекты автономности. Это: облачная инфраструктура Oracle Cloud, СУБД Oracle 18c и некоторое дополнительное программное обеспечение, дополняющее работу СУБД и облака и управляющее всей конструкцией [Рисунок 1].

Рисунок 1.  Компоненты автономной базы данных

       Из сказанного выше уже понятно, что автономная БД Oracle может работать только в облачной инфраструктуре Oracle Cloud, т к эта инфраструктура обеспечивает IT ресурсы, быстрое развертывание, бэкап и патчирование. Конечно заказчик может установит в своем ЦОД просто СУБД Oracle 18c или заказать сервис DBaaS в облаке, но это не будет автономной БД. Поэтому очевидно, что автономная БД Oracle это специальный сервис, который может работать только в облаке Oracle или на Oracle Cloud&Customer (Cloud  машина Oracle, установленная в ЦОД заказчика и администрируемая удаленно сотрудниками Oracle).  Более того, автономная БД работает  только на платформе Exadata (машина баз данных Oracle), котрая и обеспечивает высокую производительность работы СУБД, иногда компенсируя невозможность ручной настройки СУБД.

       Exadata позволяет автономной БД использовать такие уникальные механизмы, как smart scan на ячейках, storage index, гибридное колоночное сжатие, операции в памяти, кэширование данных на флеш для OLTP, шифрование всех данных БД  разделение и приоритезация ресурсов ввода вывода, параллельная обработка, Real Application Cluster (RAC),  мультирендные БД.  Но для пользователей автономной БД это не важно, т к они не видят IT инфраструктуру.

       СУБД Oracle - универсальная СУБД. Она может использоваться для создания разных систем - OLTP, DSS, хранилищ данных, геоинформационных систем, работы с графами, документами и т д. Эффективность работы СУБД для конкретной задачи обеспечивается конфигурированием и настройкой СУБД. Для того, чтобы автономная БД эффективно поддерживала конкретные задачи пользователь должен заказать не просто БД, а конкретный специализированный сервис, и тогда  при создании БД она будет автоматически сконфигурирована  и настроена под его задачу. Уже сейчас можно заказать автономный сервис хранилищ данных (Autonomous DataWarehouse service - ADWS), который удобен для создания витрин и небольших хранилищ данных.  За  ним последует автономный сервис для OLTP систем и смешанной нагрузки. Планируются отдельные сервисы для работы с графами, документами, NoSQL  и т д.

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

       Из концепции автономных БД понятно, что администрированием всего стека (от оборудования до ПО) занимается сам Oracle. Он отвечает за поддержку оборудования и операционной системы, выпуск патчей,  исправление ошибок. Oracle постоянно мониторит систем. Для облегчения управления и сопровождения огромного количества автономных БД они реализуются в виде PDB (Pluggable Database).

       Для обеспечения самовосстановления автономная БД создает архитектуру максимальной доступности, необходимую для обеспечения уровня сервиса, заданного пользователем. В зависимости от этих требований она может создать RAC (защита от сбоя узла),  архитектуру с резервной (Standby)  БД для защиты от катастрофических сбоев, использовать ASM для защиты от сбоя дисков, перестартовывать СУБД в случае сбоя и т д. Патчи и апгрейды не приводят к длительным простоям т к используют стандартные механизмы Oracle, такие как Rolling RAC Upgrade (последовательное патчирование/апгрейд узлов кластера), краткосрочный логический Standby,  Gold Image сервис, создание в оффлайн нового Oracle Home и быстрое переключение на него, Flashback (борьба с человеческими ошибками), online redefinition (изменение приложений на лету) и т д. Максимальный уровень надежности который может обеспечить Oracle для автономной БД - 99,995.  Это 2,5 минуты простоя в месяц или 30 минут простоя в год, включая регламентные работы

       Для обеспечения самозащиты автономная БД обязательно шифрует все данные БД, автоматически применяет патчи безопасности по мере их появления, механизмы машинного обучения и аудит позволяют выявлять внешние атаки и внутренние злонамеренные действия. Можно применять стандартные средства защиты Oracle, такие как  шифрование, маскирование данных, Database Vault (сокрытие данных от привелегированных пользователей).  .

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

       Сегодня опытный АБД  использует множество советчиков (advisors) и механизмов мониторинга и автоматического управления, встроенных в СУБД.  Из этих "кирпичиков" и будет в будущем строиться автономная БД, обеспечивающая высокую производительность без участия человека. Рассмотрим эти кирпичики подробнее.

       Какие механизмы обеспечат высокое качество работы автономной БД

       Мощный оптимизатор запросов. Он позволяет эффективно выполнять даже плохо написанные запросы, динамически менять планы выполнения запросов при изменении статистики

       Советчики (Advisors). В СУБД существует более д. жины советчиков, которые дают рекомендации по улучшению работы БД и ее оптимальной настройке. Они также помогут настроить СУБД, например, создадут профайлы или индексы. Наиболее популярные советчики:

Tuning advisor Access advisor In-memory advisor Compression advisor Optimizer statistics advisor Redo Log File size advisor MTTR advisor MAA  advisor Repair advisor SQL repair advisor Cluster Health advisor Sharding advisor

       ASM (Automatic Storage manager) позволяет не управлять файлами и томами, а отдать  СУБД  некоторый объем сырого дискового пространства для эффективного размещения там БД. Ранее Oracle либо использовал для хранения файлов БД операционную систему (просто, но медленно), либо рекомендовал использовать сырые устройства (raw devices) (быстро, но сложно администрировать). ASM решил эту проблему и снял многие ограничения ввода вывода. Кроме того, он осуществляет ребалансировку ввода вывода при добавлении дискового пространства и обеспечивает двойное или тройное зеркалирование кусочков логических файлов на разные диски, что защищает от сбоев диска.

       Автоматическое управление памятью (Automatic Memory Management).  Экземпдяр Oracle создает в оперативной памяти различные кэши (DB Buffer Cache, Redo Log Buffer, Library Cache и т д),  от их размера зависит  скорость работы. При изменении нагрузки размеры кэшей надо оперативно менять. Oracle делает это автоматически

       ADDM (Automatic Data Diagnostic Monitor). Во время  работы экземпляр Oracle постоянно собирает информацию о своей работе и сохраняет ее. ADDM периодически анализирует эту информацию и выдает АБД рекомендации о проблемах, негативных тенденциях и т д.  В алгоритмах ADDM заложен весь богатый опыт Oracle по настройке БД.

       AWR (Automatic Workload Repository). Собираемая экземпляром Oracle во время работы статистика хранится в репозитории AWR. AWR отчеты - главный инструмент АБД, по ним он может понять, что происходит или происходило в БД и выявить возникшие проблемы. AWR - элемент Diagnostics Pack и его информацию часто используют средства диагностики и настройки БД других производителей

       ASH Analytics (Active Session History Analytics). В дополнение к AWR Oracle в онлайн режиме собирает информацию о выполняющихся сессиях, что они делают, время работы и ожидания и т д. ASH Analytics позволяет легко анализировать эту информацию, использовать  OLAP подход для анализа разных разрезов этой информации, быстро выявлять проблемы.

       Automatic Undo Tablespace. Для отката  незавершенной транзакции, обеспечения многоверсионного чтения (без блокировок), восстановления БД, отката БД в прошлое используются Undo сегменты. Они накапливаются, хранятся и удаляются в табличном пространстве Undo Tablespace.  Oracle  сам динамически управляет хранением этих сегментов. Неверное ручное управление ранее могло привести к потере Undo сегментов и невозможности выполнения долгого оператора select.

       Автоматический сбор статистики. Основой работы оптимизатора запросов является статистика, собираемая во время работы экземпляра Oracle. При неверной или устаревшей статистике  оптимизатор может строить неоптимальные планы запросов. Статистика может собираться автоматически, без участия АБД, в заданное время, например ночью.  Перед публикацией новой статистики можно проверить ее влияние на будущую производительность SQL операций с помощью SPA Quick Check

       Automatic Standby Management. Для защиты от катастрофических сбоев обычно используется резервная (Standby) БД, являющаяся непрерывно обновляющейся копией основной БД. Она постоянно "догоняет" основную БД и на нее можно быстро переключиться в случае сбоя. Automatic Standby Management позволяет создавать, конфигурировать и мониторить эту Standby БД, конфигурировать передачу вектора изменений компонентой DataGurad, задавать режим автоматического переключения на Standby в случае отказа основной БД

       Automatic Query Rewrite. Oracle может на ходу переписывать текст запроса. Например, если есть материализованное представление для большой таблицы, он может автоматически изменить запрос и брать агрегаты из материализованного представления. Если используется PVD (Private Virtual Database), Oracle может на лету добавлять к запросу дополнительные условия, ограничивающие данные, которые получит пользователь. Это позволяет реализовать политику безопасности для просмотра таблиц

       Tuning Advisor. Оптимизатор запросов должен построить оптимальный план выполнения запроса быстро. Он не может проверить все варианты. Tuning Advisor может применять все знания и наработки по настройке БД для того, чтобы найти оптимальный план выполнения запроса и создать профиль (profile), который укажет оптимизатору, как надо изменить план запроса. Tuning Advisor также дает рекомендации по улучшению структуры БД, рекомендует и помогает построить индексы, партиции и т д. Можно включить режим, когда Tuning Advisor будет выполняться автоматически (например, ночью) для самых тяжелых SQL запросов. И если он найдет новый план выполнения, намного превосходящий имеющиеся, он автоматически построит новый profile, чтобы этот запрос выполнялся быстрее

       RAT: Automatic Workload Replay, SPA, SPA Quick Check. Прежде чем вносить в БД или IT инфраструктуру изменения, их надо протестировать, чтобы оценить их влияние на производительность и работоспособность приложения. DB Replay и SPA (SQL Performance Analyzer) позволяют захватить реальную нагрузку на работающей БД, проиграть ее до и после изменений на тестовой или (для SPA Quick Check) основной БД, сравнить и оценить результаты и принять решение о допустимости изменений. Можно также вызвать Tuning Advisor, который исправит SQL запросы, которые могут замедлиться после этих изменений

       Automatic SQL Monitor.  Он позволяет в режиме реального времени анализировать выполнение SQL запросов, определять как и почему расходуется время выполнения, смотреть статистику выполнения (например, степень параллелизма, количество обработанных строк на каждом этапе плана выполнения, план запроса и т д) Это упрощает выявление долгих и неэффективных запросов и их оптимизацию
       ADO (Automatic Data Optimization).  Невозможно все данные БД хранить на быстрых дорогих дисках. Поэтому в большинстве приложений используется механизм ILM (Information Lifecycle Management),  который позволяет мало используемые данные автоматически сжимать и перемещать на более дешёвые устройства хранения.  ADO позволяет это делать с учётом температуры данных,  то есть существует температурная карта,  в которой отмечено какие данные читались, изменялись или создавались недавно,  а какие давно не использовались. На основе этой температурный карты механизм АDO  автоматически перемещает или сжимает редко  использующееся данные.

Automatic Storage Indexes.  На Exadata при использовании гибридного поколоночного сжатия данные таблицы разделены на колонки и колонки хранятся порциями.  Данные внутри порции отсортированы и storage индекс хранит информацию о  минимальном и максимальном значение каждой порции.  На основании этой информации Oracle знает какие порции при выполнении запроса можно пропустить, т к они не соответствуют условию запроса. Storage индексы строятся и используются автоматически.

Automatic Columnar Cache  Oracle позволяет использовать обработку данных таблиц в  оперативной памяти.  Это обеспечивает опция In-memory, которая сильно ускоряет выполнение аналитических запросов.  Необходимые таблицы  разрезаются по столбцам и эти столбцы (или их части) хранятся в оперативной памяти в In-memory кэше.  Но размер оперативной памяти компьютера ограничен  и не все колонки могут поместиться в памяти. Поэтому приходится периодически выбрасывать из памяти неиспользуемые колонки и загружать туда новые. Механизм Automatic Columnar Cache делает это автоматически,  на основе температурные карты использования данных.

AHF (Autonomous Health Framework).  Существует около десятка утилит которые позволяют онлайн анализировать состояние  оборудования кластеров БД и кластеров компьютеров,  проверять их,  анализировать журналы и файлы трассировки и т д.  Это множество утилит было объединено  в специальной Autonomous Health Framework с единым репозитортем.  AHF анализирует состоянии кластеров и отдельных компьютеров и предпринимает заданные  действия в случае ухудшения их работы

PDB Hot  clone и перемещение  Контейнерная БД oracle может содержать множество Plugguble баз (PDB) и позволяет управлять ими как единым целым.  Иногда бывает нужно переместить PDB из одной контейнерной БД  в другую. Это бывает нужно для того,  чтобы изменить её версию,  или  для того, чтобы сделать  копию PDB для независимого использования. PDB Hot  clone позволяет копировать базу данных не останавливая её работу.  То есть вы работаете с БД  и в тоже время она перемещается или копируется в другую контейнерную БД. Поскольку за время перемещения исходная БД  изменялась, далее происходит автоматический  накат этих изменений и в результате Вы получаете согласовано копию PDB

On-line patching,  Upgrade  Большинство патчей можно накатывать на работающую базу данных без ее остановки.  Некоторые патчи и апгрейды  требует  останови и перестарта экземпляра Oracle. Но в кластерной архитектуре можно использовать  Rolling upgrade  кластера или Grid инфраструктуры. Это означает,  что из строя выводится один узел кластера или один узел Grid инфраструктуры. Остальные узлы продолжают работать.  На этот узел  накатываются патчи или делается апгрейд,  после этого узел добавляется в кластер и стартует.  После того, как он  начинает использоваться системой та же операция повторяется со следующими узлами кластера

Advanced compression.  Данные занимают много места на диске и в памяти и  конечно хочется их сжать. Но механизм разжатия данных замедляет работу и требует дополнительных  процессорных ресурсов.  Advanced compression обеспечивает умное сжатие,  то есть свежие данные в блоке,  которые скорее всего будут часто использоваться, не сжимаются сразу. После заполнения блока в фоновом режиме данные автоматически сжимаются в 2-3  раза,  но вновь поступающие данные опять лежат несжатыми,  таким образом достигается совмещение преимуществ сжатия и возможности  быстро работать со свежими данными

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

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

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

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

Maintenance window  Многие сервисные операции  нужно выполнять регулярно,  но так,  чтобы они не мешали выполнять другие операции. Вы можете описать временное окно,  когда целесообразно выполнять эти операции.  Тогда, скажем, сбор статистики или  оптимизация тяжелых запросов будут выполняться в это указанное время

OMC. Контроль отклонений (аномалии)  Многие механизмы Oracle Management Cloud (OMC) построены на основе механизма  контроля отклонений.  Система создает базовый профиль  работ  БД  или приложения  и сравнивает непрерывно собираемые текущие  характеристики работы c  характеристиками базового профиля.  Если выявляются аномальные отклонения от базового профиля (базовой модели поведения), то  система либо сообщает о них администратору,  либо автоматически реагирует,  выполняя корректирующие действия. При этом система реагирует только на отклонения от нормальных модели функционирования.  Это уменьшает объем информации,  которую должен изучать администратор

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

IT  Analytics. Еще один элемент OMC позволяет оперативно собирать информацию о работе различных СУБД  и автоматически выявлять, например,  БД  с деградацией производительности (то есть у них увеличивается время отклика при отсутствии увеличения нагрузки).  IT  Analytics позволяет выявлять неэффективные БД,  то есть базы, у которых растёт время ожидания,  он также позволяет выявлять SQL  операции и базы с нестабильным временем выполнения. Все эти БД  являются кандидатами на дальнейшее исследование.  В работе IT Analytics также используются модели, полученные при машинном обучении.

       Это далеко не полный список "кирпичиков",  из которых будет строиться автономная БД,  но главное,  что они уже есть в арсенале ДБА,  но пока их использует человек. Он должен решать,  когда и в какой ситуации использовать эти инструменты.  В  автономной БД это будет делаться автоматически.

       Машинное обучение (Machine learning)

       Автономный базы данных немыслимы  без использования алгоритмов машинного обучения.  Такие алгоритмы и модели  используются в OMC (Log Analitycs и IT Analitics),  трех компонентах  Autonomous Health Framework (Trace File Analyzer, Cluster  Health Advisor, Hang Manager),  при защите БД от внешнего и внутреннего вторжения, в работе служб технической поддержки для выявления самых важных и приоритетных для исправления ошибок и т д. Log Analitics, как уже говорилось,  использует механизм кластеризации,  в других системах используется байесовская сеть для поиска причин возникновения нештатной ситуации или причин возникновения негативных тенденций. Как правило все эти компоненты работают по следующему принципу:  Автоматически строится базовая модель нормального  поведения системы.  Далее при работе системы выявляются отклонения от базовой модели, производится анализ этих отклонений и на основе результатов  анализа либо выявляются тенденции ухудшения работы,  либо выявляются причины отклонений. После чего, если необходимо, автоматически  выполняются корректирующие действия.  Например,  так работает Cluster Health Advisor. При работе Trace File Analyzer  также выявляются аномалии в работе,  но на их основе определяется список файлов,  которые  нужно собрать и отправить в службу технической поддержки для разрешения проблем и  поиска причин возникновения ошибок.

Модели, используемые для работы  этих компонентов генерируются с помощью алгоритмов машинного обучения.  В составлении этих алгоритмов участвуют эксперты по машинному обучению.  Далее эти модели загружаются в систему и  используются для анализа работы подсистем.  Модели постоянно совершенствуются и обновляются. В будущем планируется ещё более широкое использование машинного обучения в автономных базах данных (Рисунок 2)

Рисунок 2.  Машинное обучение.  Создание и использование моделей

       Autonomous DataWarehouse Service

       Первый специализированный сервис  автономной БД  Oracle  называется  "Сервис Автономного Хранилища Данных"  (Autonomous DataWarehouse Service - ADWS). Его архитектура приведена на рисунке. (Рисунок 3). Он позволяет за несколько минут  создать базу данных для витрины или хранилища данных. Затем пользователь может  создать в этой БД  таблицы и начать  работать с ними.  Работать с ADWS  можно через хорошо всем знакомый SQL Developer,  интегрировать  с ней другие системы можно через различные интеграционные сервисы от Oracle или других производителей, причем эти интеграционные сервисы могут работать как в облаке так и в вашем ЦОД.  Для загрузки данных в таблицы созданного хранилища их  нужно поместить на облачную систему Oracle (Oracle Object Storage)  или Amazon. В базе данных есть процедура для загрузки этих данных или для работы с ними как с внешними таблицами. 

Рисунок 3.  Архитектура  ADWS

       Для анализа загруженных в таблицы данных можно использовать любые BI инструменты, умеющие работать с БД по SQL*Net,  работающие как в облаке так и в  Вашем ЦОД.  ADWS  имеет веб консоль для контроля его работы и встроенный инструмент для простого анализа данных и машинного обучения.

       Новая роль администратора БД

       Может показаться,  что автономная база данных полностью исключает работу администраторов баз данных и им срочно нужно переквалифицироваться или  искать новую работу. Так ли это?  Нет, автономная база данных автоматизирует только рутинные работы. Администратор может поддерживать теперь больше баз данных,  больше времени тратить на инновационные проекты.

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

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