Самоуправление, самодиагностика, самолечение
СУБД становятся все сложнее и сложнее, и для их быстрой и надежной работы требуется все более опытные администраторы. Но даже они не могут оперативно реагировать на постоянно меняющуюся нагрузку СУБД, изменение режима работы приложений и т.д. Кроме того, растет число СУБД в организации, которые надо администрировать.
Единственный выход решить эти проблемы – сделать СУБД самоуправляемыми, самодиагностирующимися, самолечащимися. Большинство производителей СУБД уже идут по этому пути, но возможностей развития остается еще много. Основная идея здесь проста. Во время работы СУБД постоянно собирает информацию о своей работе, анализирует ее (оперативно и в фоновом режиме), принимает решения, и либо автоматически их реализует (например, меняет размеры областей в памяти, выполняет процедуры, запрашивает у ОС дополнительные ресурсы, меняет планы выполнения запросов), либо информирует администратора о проблеме, рекомендует ему последовательность действий для решения проблемы и после одобрения выполняет эти действия. При анализе работы применяются лучшие практики и знания, накопленные лучшими администраторами этой СУБД. Их список постоянно совершенствуется. Системы учатся реагировать проактивно (т.е. заранее, до возникновения проблем), выявляют причины, а не следствия возникновения проблем, учитывают множество факторов, которые администратору в условиях стресса учесть трудно.
Системы контроля и самонастройки могут настраивать размеры областей памяти, ввод/вывод, давать рекомендации по оптимизации запросов, выявлять проблемы безопасности (например, незакрытые порты, неизмененные пароли и т.д.) и производительности, нехватки места и ресурсов, отклонения от заданных или типичных стандартов поведения и т.д.
В фоновом режиме СУБД постоянно проверяет свое состояние, целостность данных, ищет и исправляет сбойные блоки и файлы, сверяет контрольные суммы и т.д. Ведется работа по встраиванию алгоритмов data mining для выявления и контроля зависимостей между данными. Многие СУБД научились сегодня автоматически (без участия DBA) выполнять Backup и восстановление, собирать информацию о сбоях и отправлять ее в службу технической поддержки, отслеживать появление новых важных патчей.
Продолжается совершенствование оптимизаторов SQL-запросов, они учитывают все больше важных факторов (например, взаимовлияние кардинальности столбцов, параметры оборудования и среды эксплуатации и т.д.). Детальная оптимизация, которая требует много вычислительных ресурсов, проводится в фоновом режиме, выявляя и тестируя новые, более перспективные планы выполнения запросов, автоматически выявляя и настраивая наиболее ресурсоемкие SQL.
Еще одной важной тенденцией является уменьшение количества “ручек”, которые может подкрутить не очень опытный администратор БД, и переход к заданию бизнес-критериев работы, таких как допустимое время простоя системы при сбоях, максимально допустимое время отклика, минимальная пропускная способность системы и т.д. На основе этих критериев СУБД сама регулирует свои параметры, чтобы обеспечить требуемый результат. Благодаря всему этому время обучения администратора мощных коммерческих СУБД снизилось до нескольких дней. Однако у опытного DBA все еще остается возможность детально контролировать и настраивать работу СУБД, поскольку ни один оптимизатор пока не может сравниться с гуру – администратором.
