AnTeСитуация печальная. Есть корпоративная система, сейчас с нею работают около 400 человек. Работали. Потому что сегодня утром она внезапно впала в кому.

Ясно, что контролируемых данных очень много, попытаюсь коротко описать хоть что-то.

Есть две машины, работают на виртуальных машинах VmWare
- сервер БД Oracle 11.2.0.4
- на сервере приложений Apache TomCat в составе Spring Boot 1.5.4
С базой данных сервер приложений работает через стандартный пул Apache Tomcat.

Всё работало "как часы" и при гораздо больших нагрузках уже не менее полугода, но:
- пару месяцев назад была подобная ситуация, но пару часов вдруг само собой всё нормализовалось.
- через две недели ситуация повторилась, и на этот раз система была в коме около шести часов.
- сегодня её не удаётся завести вовсе

Симптомы следующие:
- запросы выполняются на порядок дольше
- мониторинг на гипервизоре и внутри самой VM показывает "высокие операции чтения" с диска (скорость чтения возрастает на 1-2 порядка от обычного).
- по данным мониторинга на стороне гипервизора проблемы ввода вывода в обоих случаях начались ночью – при минимально нагруженной системе (через некоторое время после завершения операций бэкапа ВМ а затем базы)

Возможно, проблемы в среде виртуализации.

Но есть ещё момент. На БД много не оптимизировано - многие запросы можно было бы улучшить, в том числе не проиндексированы некоторые базовые таблицы: "забивали" на это, т.к. в ближайших планах был перевод запросов к Elastic Search.

Может ли БД так резко менять своё поведение только по причине неоптимизированных запросов?

Как подобные ситуации отлавливать, где можно узнать о произошедших изменениях?

при болезни, для диагностики, обычно начинают с осмотра и анализов

Причиной может быть что угодно:
кривой запрос воткнутый разработчиком
протухшая батарейки рейда
слетевшая статистика БД, в результате которой поплыли планы
увеличилось количества запросов, естественно от увеличившегося количества клиентов, или DOS атаки, в результате которой банально кончилась память и начался swapping системы

Это далеко не все причины, которые могли привести к такому поведению

начните с описания системы, версии ОС и ПО и так далее
результаты мониторинга (например /var/log/sa файлы)
отчеты awr или statspack

AnTeЗдравствуйте! Спасибо всем за ответы с вариантами. Уточню немного по своему вопросу.

Конечно же, мы контролируем много параметров, просто не понятно, что же сюда можно написать. Nagios для VM, сейчас переключили на stand by - дубликат, который находится в нашей зоне контроля, т.е. свой гипервизор и хранилка своя

Система заработала, но тормоза неимоверные. Поэтому и возникло подозрение, что раз по факту поменяли виртуальную среду и всё особо не наладилось - дело всё-таки в неоптимизированных запросах (отсутствие индексов).

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

Как "вернуть всё взад, отключив ИИ" - они не в курсе. Вообще, всё это лишь предположение.

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

Смущает неожиданность перехода БД в такое состояние. Нагрузки на процы и память нет и не было, "объёмы чтения" - были на порядок меньше. Прирост в базе данных ежедневный небольшой (это документы, поручения по ним). Что произошло и как можно вернуть всё взад хотя бы на два дня? Сейчас ещё докидаем памяти в два раза больше, но память и так не нагружена.

Может, ещё какие варианты?

1) Системная статистика, для unix систем
установи sysstat пакет
начнет собираться в фоновом режиме sar, нагрузка минимальная
достаточно прикрепить /var/log/sa/saDD файл, где DD - интересующее число месяца
и можно будет посмотреть большое количество параметров нагрузки системы
это удобнее чем разбираться в обобщенных портянках систем мониторинга



2) Статистика базы
Если куплен diagnostic pack и у Вас Enterprise Edition, то сбор awr отечета
иначе statspack



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

3) дополнительно приложить alert.log базы

Без этого, гадание на кофейной гуще