Безопасный AI-мониторинг Oracle в закрытом контуре с использованием Python, Ollama и V$WAITCLASSMETRIC

Введение

В существующей системе мониторинга Oracle уже использовалось разработанное мной решение, которое с интервалом в 1 минуту собирало метрики производительности из представления V$WAITCLASSMETRIC и отображало их в Grafana. Графики наглядно показывали изменения времени ожиданий в классах User I/O, Commit, Concurrency и других, однако они показывали лишь сам факт изменения нагрузки, не объясняя его причины.

Возникла идея: если метрики уже собираются для построения дашбордов, почему бы одновременно не отправлять их локальной языковой модели? Тогда вместе с графиком можем сразу отображать текстовое объяснение происходящего, список наиболее вероятных причин изменения показателей и рекомендации, с чего начать дальнейшую диагностику.

Так появился небольшой эксперимент — дополнить существующую систему мониторинга Oracle локальным AI-ассистентом.

Для эксперимента я выбрал Ollama с моделью Qwen. Моей целью было не заменить DBA, а дополнить существующую систему мониторинга возможностью автоматически интерпретировать всплески на графиках производительности и предлагать наиболее вероятные причины их возникновения.

Решение работает полностью внутри корпоративного контура без доступа в Интернет,

что очень важно особенно для банковского сектора.

Все исходные тексты, использованные в статье, включая SQL-скрипты, PL/SQL-процедуры и Python-агент для взаимодействия с Ollama, доступны в открытом репозитории GitHub:

https://github.com/rchzhen-orcl/oracle-ai-dba

Архитектура решения

На рисунке показан общий поток данных в системе. Метрики производительности Oracle преобразуются во вью TELE_GRAF, после чего процедура REFRESH_TELE_GRAF_HISTORY ищет аномальные измерения. Python-агент передает их локальной модели Ollama, сохраняя результаты анализа в TELE_GRAF_ALERTS, а Grafana отображает как графики производительности, так и рекомендации AI.

Подготовка данных

Первой задачей было привести метрики производительности к формату, удобному не только для построения временных рядов (Time Series) в Grafana, так и для последующего анализа и передачи локальной LLM.

Представление V$WAITCLASSMETRIC возвращает данные в виде набора строк, где каждая строка соответствует определенному классу ожиданий (User I/O, System I/O, Commit, Concurrency и т.д.). Такой формат удобен для отображения текущих значений, но плохо подходит для хранения истории, сравнения последовательных измерений и передачи данных внешним приложениям.

Такой подход позволил решить сразу несколько задач:

• хранить историю измерений в компактном виде;

• сравнивать последовательные снимки производительности;

• упростить SQL-запросы для поиска аномалий;

• передавать готовый набор метрик в Python-агент и локальную LLM без дополнительной обработки;

• использовать тот же набор данных для построения дашбордов Grafana.

Поэтому было создано представление TELE_GRAF, в котором данные из V$WAITCLASSMETRIC преобразуются из строк в отдельные столбцы (pivot-представление). В результате каждое измерение представляет собой одну запись со всеми ключевыми метриками производительности.

Из V$WAITCLASSMETRIC брались агрегированные данные   time_waited,  wait_class_id  по классам ожиданий

Первоначально использовалось только  TIME_WAITED – абсолютное время ожидания по классам ожиданий,  потом добавлено  DBTIME_IN_WAIT – время в % от общего DB Time. Использование обоих параметров  более наглядно показывает реальную нагрузку в базе.

 

Поиск аномалий

Процедура REFRESH_TELE_GRAF_HISTORY запускается один раз в минуту. При каждом запуске она сохраняет очередной снимок метрик из представления TELE_GRAF в архивную таблицу TELE_GRAF_ALL.

Одновременно выполняется проверка ключевых показателей производительности. Для каждого класса ожиданий задаются пороговые значения двух параметров:

• p_* — доля класса ожиданий в общем времени ожиданий (в процентах);

• t_* — абсолютное время ожидания (в миллисекундах).

Например, запись считается аномальной, если выполняется хотя бы одно из следующих условий:

(v.p_userio > 50 AND v.t_userio > 1000) OR (v.p_concurrency > 20 AND v.t_concurrency > 500) OR (v.p_systemio > 40 AND v.t_systemio > 1000) OR (v.p_commit > 30 AND v.t_commit > 500) OR (v.p_network > 20 AND v.t_network > 500) OR (v.p_application > 10 AND v.t_application > 500) OR (v.p_configuration > 5 AND v.t_configuration > 500) OR (v.t_administrative > 0)

Фрагмент процедуры REFRESH_TELE_GRAF_HISTORY, выполняющей сохранение только аномальных измерений.

Если хотя бы одно из условий выполняется, соответствующее измерение записывается в таблицу TELE_GRAF_HISTORY.

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

Все пороговые значения (p_* и t_*) являются настраиваемыми. Они подбираются с учетом особенностей конкретной информационной системы, характера нагрузки и требований к чувствительности обнаружения аномалий.

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

Анализ аномалий с помощью локальной LLM

Ключевым компонентом разработанного решения является Python-агент ora_ollama.py. Именно он объединяет Oracle Database, локальную LLM и систему мониторинга Grafana в единый процесс автоматического анализа производительности.

После того как процедура REFRESH_TELE_GRAF_HISTORY обнаруживает аномалию и сохраняет ее в таблице TELE_GRAF_HISTORY, дальнейшую обработку берет на себя ora_ollama.py.

С заданным интервалом (по расписанию cron в Linux или Планировщику заданий Windows) агент автоматически запускается и выполняет полный цикл анализа:

1. Проверяет наличие новых записей в таблице TELE_GRAF_HISTORY, которые еще не были обработаны.

2. Извлекает связанные с аномалией метрики производительности Oracle.

3. Преобразует полученные данные в структурированный JSON.

4. Формирует специализированный промпт, содержащий значения метрик, динамику их изменения и инструкции для языковой модели.

5. Отправляет запрос локальной модели через Ollama.

6. Получает текстовое заключение с интерпретацией обнаруженной аномалии, наиболее вероятными причинами ее возникновения и рекомендациями по дальнейшей диагностике.

7. Сохраняет результаты анализа в таблицу TELE_GRAF_ALERTS, связывая их с соответствующим инцидентом.

   

Пример метрики Oracle, передаваемые Python-агенту:

JSON {“dt”: “2026-07-01 14:21:52”, “t_userio”: 20745.2, “t_concurrency”: 77.3, “t_systemio”: 2759.7, “t_commit”: 25.5, “p_userio”: 60.8, “p_concurrency”: 0.2, “p_systemio”: 8.1, “p_commit”: 0.1}

Пример Prompt:

«Ты — ведущий инженер производительности СУБД Oracle (Senior DBA Performance Tuning). В базе данных зафиксирована критическая аномалия производительности!

Время сбоя: {anomaly_time} Метрики (t_ — абсолютное время ожидания, p_ — процент от общего DB Time): {compact_json}

Проанализируй эти данные и дай экстренное заключение для администратора строго по пунктам:

1. Что сломалось (Главный Bottleneck)?

2. Срочное действие для исправления ситуации (какую SQL-команду выполнить или что проверить).

Отвечай кратко, тезисно, на русском языке. Без лишних вступлений.»

Для взаимодействия с локальной моделью используется Python-библиотека Ollama. После формирования prompt агент отправляет запрос и получает текстовое заключение модели:

response = ollama.chat( model="qwen2.5:3b", messages=[ { "role": "user", "content": prompt } ])answer = response["message"]["content"]

Пример ответа OLLAMA:

1. Что сломалось: Главный Bottleneck — пользовательский I/O (t_userio: 4919.7), составляющий 92.6% общего времени ожидания.

2. Срочное действие для исправления ситуации: Проверить и оптимизировать SQL-запросы, вызывающие высокий трафик пользовательского I/O. Возможно, потребуется выполнение команды ALTER SYSTEM SET STATISTICS_LEVEL = ALL SCOPE=BOTH; для получения дополнительных метрик. Также рекомендуется провести анализ топ-таблиц и оптимизировать их использование в запросах. Убедиться в корректности настройки индексов и ограничений. Проверить наличие дублирования SQL-запросов и устранить, если это возможно. В случае необходимости, выполнить команду ALTER SYSTEM SET STATISTICS_LEVEL = ALL SCOPE=BOTH; для получения дополнительных метрик.

Это кратко и по пунктам, как требует твоя задача.

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

 

Сохранение результатов анализа

Результаты работы OLLAMA записываются и сохраняются в таблице TELE_GRAF_ALERTS. Которая служит журналом всех обработанных инцидентов и рекомендаций AI.

Для каждого обнаруженного инцидента сохраняются:

• время возникновения аномалии;

• исходные метрики производительности Oracle (в формате JSON);

• экспертное заключение, сформированное LLM;

• рекомендации по дальнейшей диагностике и возможным действиям DBA.

Из данных таблиц TELE_GRAF_HISTORY и TELE_GRAF_ALERTS в Grafana был создан дашборд, который отображает графики производительности, и текстовые рекомендации AI для каждого зарегистрированного инцидента. В результате получаем возможность сразу увидеть не только графики изменения метрик производительности, ее вероятные причины возникновения и рекомендации по ее устранению.

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

Предложенный подход имеет и ряд ограничений.

В текущей реализации анализ выполняется только по агрегированным метрикам классов ожиданий. Модель не определяет автоматически конкретный SQL-запрос, объект базы данных или сессию, вызвавшие проблему.

Поэтому после получения рекомендаций DBA при необходимости выполняет более глубокий анализ с использованием стандартных средств Oracle, таких как V$SESSION, V$SQL, V$SYSTEM_EVENT, AWR или ASH.

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

Заключение

Появление локальных больших языковых моделей открывает новые возможности для автоматизации задач администрирования баз данных.

В статье рассмотрен один из вариантов практического применения таких моделей — создание локального AI-ассистента для Oracle Database, который автоматически обнаруживает аномалии производительности, анализирует агрегированные метрики и формирует первичные рекомендации для администратора.

Даже компактная модель Qwen2.5, запущенная через Ollama, способна выполнять роль интеллектуального помощника DBA при решении типовых задач диагностики. Она не заменяет опытного администратора и не отменяет использование специализированных инструментов Oracle, однако позволяет значительно сократить время первичного анализа и быстрее определить вероятное направление поиска причины проблемы.

Представленная архитектура может служить основой для дальнейшего развития. В перспективе систему можно расширить анализом данных AWR и ASH, автоматическим поиском проблемных SQL-запросов, использованием технологий RAG и накопленной базы инцидентов, а также интеграцией с системами мониторинга и оповещения. Такой подход превращает Oracle Database из источника метрик в систему, способную не только фиксировать изменения производительности, но и автоматически интерпретировать их, помогая администратору принимать решения быстрее и эффективнее.