Что такое AWR-отчет?

AWR-отчет (Automatic Workload Repository)

AWR — это инструмент в Oracle Database, который автоматически собирает и сохраняет статистику производительности работы базы данных. Для Java разработчика, работающего с Oracle, понимание AWR критично для диагностики проблем с производительностью.

Что такое AWR

Automatic Workload Repository — это встроенный механизм Oracle Database, который каждый час автоматически снимает "снимок" (snapshot) текущего состояния системы. Эти снимки содержат информацию о:

• Активности базы данных
• Расходе ресурсов (CPU, дисковые операции)
• SQL-запросах, потребляющих больше всего ресурсов
• Блокировках и ожиданиях
• История производительности за последние дни

Структура AWR

AWR состоит из:
├── Snapshots (снимки) - делаются каждый час автоматически
├── Baseline (базовая линия) - эталонные показатели
├── Retention Policy (политика хранения) - по умолчанию 7 дней
└── AWR Report (отчет) - анализ между двумя снимками

Как использует Java разработчик

Когда приложение работает медленно, я бы:

1. Сгенерировал AWR-отчет

-- Подключиться как SYSDBA
SQL> @?/rdbms/admin/awrrpt.sql

-- Выбрать тип отчета (html, txt)
-- Выбрать ID первого и второго snapshot
-- Отчет сохранится в файл

2. Анализировал ключевые метрики из отчета:

• Load Profile - нагрузка на систему (transactions, database calls)
• Top 10 Events - топ 10 операций, ждущих ресурсы. Пример:
  • db file sequential read - медленное чтение с диска
  • db file scattered read - полное сканирование таблицы
  • CPU time - использование процессора

3. Смотрел Top SQL

SQL ID      | Exec | CPUtime | Reads
----------- | ---- | ------- | -----
abc123      | 5000 | 45.2s   | 1.5M

Эти SQL запросы потребляют больше всего ресурсов — нужно их оптимизировать!

Практический пример из работы

Однажды приложение начало работать медленно после добавления нового функционала. AWR-отчет показал:

Top Event: "db file sequential read" - 70% времени
Top SQL: SELECT * FROM orders WHERE customer_id = ?

Проблема была ясна — на колонке customer_id не было индекса! После добавления индекса:

// Создать индекс в миграции
CREATE INDEX idx_orders_customer_id ON orders(customer_id);

Производительность улучшилась в 10 раз.

Ключевые метрики в AWR

Связь с Java приложением

Для Java приложения, использующего Hibernate/JPA:

// Плохо - N+1 problem, много SQL запросов
List<Order> orders = session.createQuery(
    "SELECT o FROM Order o"
).list();
// Для каждого order идет отдельный запрос Customer
for (Order order : orders) {
    System.out.println(order.getCustomer().getName()); // N запросов!
}

// Хорошо - eager loading, один запрос
List<Order> orders = session.createQuery(
    "SELECT DISTINCT o FROM Order o JOIN FETCH o.customer"
).list();

Eager loading снижает количество SQL запросов, что видно в AWR-отчете как уменьшение db file reads.

Заключение

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