Автономная база данных Oracle как «скатерть-самобранка»: обзор волшебных механизмов

Автономные БД — это не продукт, это концепция, и по мере ее развития автономные БД будут становиться все умнее и качество их работы будет улучшаться: от версии к версии они будут использовать все больше механизмов, имеющихся сегодня у опытных администраторов. Тут важно понимать отличие БД со средствами автоматизации, которые существуют сегодня, от автономной БД. Вернемся к примеру с беспилотным автомобилем. В современном автомобиле с водителем есть много средств автоматизации – круиз-контроль, средства аварийной остановки у препятствия, GPS-навигатор, ABS, предупреждение об уходе с полосы или о падении давления в шинах и т. д. Их используют водители. В беспилотном автомобиле пассажир о них даже не знает. То же и в СУБД.
«Понятия автономных процессов прививаются нам с детскими сказками: «Скатерть-самобранка», «По щучьему веленью», «Двое из ларца» и т.д., где общий принцип – получить результат, не затрачивая никаких усилий. С автономными облачными базами данных сказка постепенно становится былью,в которой бизнес реализует свои желания, а ИТ сосредотачивается на других проблемах», — считает Александр Хохлов, заместитель начальника управления вычислительных комплексов департамента информационных технологий банка ВТБ, участник программы бета-тестирования Oracle ADWH.
Сегодня опытный DBA использует множество советчиков (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 периодически анализирует эту информацию и выдает DBA рекомендации о проблемах, негативных тенденциях и т д. В алгоритмах 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. При неверной или устаревшей статистике оптимизатор может строить неоптимальные планы запросов. Статистика может собираться автоматически, без участия DBA, в заданное время, например ночью. Перед публикацией новой статистики можно проверить ее влияние на будущую производительность 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. — На Oracle Exadata при использовании гибридного поколоночного сжатия данные таблицы разделены на колонки, и колонки хранятся порциями. Данные внутри порции отсортированы, и storage-индекс хранит информацию о минимальном и максимальном значение каждой порции. На основании этой информации Oracle знает, какие порции при выполнении запроса можно пропустить, так как они не соответствуют условию запроса. Storage-индексы строятся и используются автоматически.
“Концепция Автономной облачной базы данных Oracle понятна и чрезвычайно интересна. Мы внимательно изучаем ее возможности, потенциально решение подходит в качестве хранилища данных для части сервисов в нашей сервисной архитектуре. Наиболее ценны для нас — установка патчей без остановки БД, автоматическое выявление зависаний и блокировок, ADO (Automatic Data Optimization) и Automatic Storage Indexes. И время, которое освобождается от рутинной работы, мы хотели бы посвящать задачам развития”, — отмечает Валерий Капленко, Директор по информационным технологиям Faberlic.
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 характеристиками базового профиля. Если выявляются аномальные отклонения от базового профиля (базовой модели поведения), то система либо сообщает о них администратору, либо автоматически реагирует, выполняя корректирующие действия. При этом система реагирует только на отклонения от нормальных модели функционирования. Это уменьшает объем информации, которую должен изучать администратор.
«Хотя последние годы многие вендоры баз данных наращивали механизмы глубокой автоматизации процессов сопровождения и администрирования, но только Oracle вплотную подошла к реализации первого, действительно автономного хранилища. К механизмам глубокой автоматизации можно отнести многочисленных помощников по выбору оптимальных параметров СУБД, адаптивные планы выполнения запросов, технологию автоматического исправления ошибок и проактивного мониторинга – Oracle Management Cloud. Также у Oracle успешно развивалась одна из наиболее производительных платформ для ускорения аналитических запросов – Oracle Engineered Systems, которая отлично подходит под хранилища данных. Момент превращения в «скатерть-самобранку» наступил, когда перечисленные технологии были собраны внутри облака Oracle – Oracle Autonomous Data Warehouse Cloud (ADWH), — резюмирует Александр Хохлов.
Log Analytics. — Во время работы базы данных и приложений создается огромное количество журналов. Каждый узел и программа создает свой набор журналов, и трудно их всех анализировать при поиске ошибки или анализе работы БД и приложения. В каждом журнале содержится очень много информации, похожих сообщений, которые отличаются только кодом блока или именем табличного пространства. Работать с таким объем информации и находить причины неустойчивой работы системы очень сложно. Кроме того, добавление в систему новых узлов и программных компонент требует корректировки системы анализа журналов. Компонент OMC Log Analytics позволяет автоматизировать эту работу. Он собирает множество журналов из разных систем, выбирает из них сообщения и позволяет очень быстро анализировать эти сообщения в разных разрезах — по продукту, узлу, времени возникновения, критичности сообщения и т д. Использование алгоритмов машинного обучения позволяет объединять (кластеризовать) похожие сообщения. Это дает возможность очень просто анализировать непрерывно собираемые журналы и быстро находить причины возникающих проблем
IT Analytics. — Еще один элемент OMC позволяет оперативно собирать информацию о работе различных СУБД и автоматически выявлять, например, БД с деградацией производительности (у них увеличивается время отклика при отсутствии увеличения нагрузки). IT Analytics позволяет выявлять неэффективные БД, то есть базы, у которых растёт время ожидания, он также позволяет выявлять SQL-операции и базы с нестабильным временем выполнения. Все эти БД являются кандидатами на дальнейшее исследование. В работе IT Analytics также используются модели, полученные при машинном обучении.
Это далеко не полный список «кирпичиков», из которых строится автономная БД, но главное, что они уже есть в арсенале DBA, но пока их использует человек. Он должен решать, когда и в какой ситуации использовать эти инструменты. В автономной БД это будет происходить автоматически.
Автор: Марк Ривкин, руководитель группы баз данных технологического консалтинга Oracle в России и СНГ.
Источник

Top News