Хотел бы вам показать краем глаза одну очень крутую вещь. То, чего вообще ни у кого нет, но чуть более детально.
Это вещь при этом оттестирована на десятках тысячах серверов с профилями нагрузки, какие в природе вообще существуют. Поэтому цэ - не только моя заслуга. Но может иметь статус полноценного Энерпрайза.

Правовой статус: Это моя разработка, но собственность компании. То есть показать могу. А дать ее вам - нет. Купить ее вы тоже не можете. Но может кто то догадается сделать.

Здесь вы можете строить отчеты в любом интервале с глубиной 14 дней и дискретизацией 1 мин.

Все запросы, все ожидания БД и все нагруженные и завершившиеся запросы. Есть кое что, чего и в Оракле нет )

1. первое на что смотрят - это в каком интервале построен отчет. Напомню что гулубина хранения - 2 недели, дискретизация 1 мин. В оракле дискретизация 1 час. то есть короткие проблемы в историческом интервале исследовать в Оракл почти невозможно.

Начальный и конечный снапшот. И также общее время сессий. в данном случае, как сидим был значительный всплеск с 200 до 1200

Также есть информация об интервале снапшота и uptime БД.

Шапка.

1. Оперативная информация о версии БД

2. Утилизация соединений и лимиты на начальном снимке

3. Утилизация соединений и лимиты на конечном снимке

4. Изменение размера БД на начальном и конечном снимке.

5. Информация о хосте , его ресурсах и платформе.

6. max_connections

Он лучше чем оракловый. Но да в целом похоже и по оформлению и частично по структуре

Общий профиль нагрузки.

Всё то же самое что и в pg_stat_database , но в интервале времени , а не с момента сброса статистики (!)

здесь можно видеть динамику INSERT/DELETE/UPDATE , чтений из Shared buffers и дисков на физическом уровне блоков.

Статистика ожиданий на уровне БД.

Как общая, так и с разбивкой по БД и пользователям.

Здесь можно видеть в общем в чем могут быть проблемы. То ли это удержание прикладом например на idle in transactions, либо на уровне ввода вывода IO, или разделяемой памяти.

Две секции Top CPU и Top MEM

Сюда могут попадать и незавершившиеся запросы, то чего нет в pg_stat_statements

Фактически это джоин pg_stat_activity и htop по pid. таким образом чтобы понимать как именно утилизирует конкретный pid ресурсы. В Оракле это сделано через агент unux. Здесь же мы выполним системные bash запросы прями из pg, без необходимости в агенте.

История блокировок (то чего в Оракле нет)

Слева кто блокирует и кого в данный момент времени. И на каких ожиданиях.

Длинные транзакции.

Всё что более 5 мин. С информацией о транзакции и времени начала запроса.

Прогресс VACUUM FULL/CLUSTER, VACUUM, CREATE INDEX

Если в этом интервале они были запущены.

Далее идет сnатистика по pg_stat_statements с разными сортировками.

Особенность ее в том, что она показывает статистику только по завершенным запросам.

Наиболее интересная секция:

SQL ordered by Shared blocks hit

Она показывает косвенно то что в запросах либо нет индексов, либо они неоптимальны. Что весьма полезно для анализа.

Далее идут секции, показывающие работу чек пойнтера, генерацию WAL и статистику по их арахивации а также общую статистику БД по номеру транзакции и возрасту БД (полезно для анализа VACUUM FREEZE)

И в самом конце ora.init. Куда же без него.

Список всех параметров БД.

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

А какая шикарная архитектура у этой системы... ) По этому поводу как раз и напишу статейку.

Полковник Кедра Митрей доклад закончил!

Да, а показывал её на WD conf правда. Но видишь это не совсем все правильно. Зачем показывать то, что дать людям все равно не можем. Надеюсь что кто тотзаймется этим для народа. Но рассказать как это сделать я могу.