Всем привет!
У нашего сервера Oracle произошло резкое падения производительности.
Абсолютно все запросы выполняются в десятки раз медленнее.
Вообще, прежде чем лезть в саму базу, имеет смысл "осмотреть пациента наружно". Вы к сожалению ничего не указали про сервер (физический / виртуальный, вендор, модель, параметры / спецификации), диски (внутренние / внешний SAN), версию OS (какой-то *nix / Linux / Windows) и версию самой базы. Часто когда "все стало медленно", причина в том что банально села батарейка в дисковом контроллере и он перестал кешировать, скорость I/O может и в 10 раз упасть. Если сервер виртуальный - может появился "noisy neighbour" (ака "шумный сосед"), т.е. кто-то ещё на этом же гипервизоре (другой виртуальный сервер) стал потреблять намного больше ресурсов чем до этого, а гипервизор не совсем честно изолирует виртуалки друг от друга и Вашему Oracle серверу стало не хватать ресурсов. Или просто ещё одну виртуальную машину запустили на этом же гипервизоре, и начался overallocation / overprovisioning. Или тоже самое на SAN (если используется) - кто-то ещё, какая-то другая система, стала утилизировать SAN сильно больше чем до этого, и все остальные системы кто использует этот же SAN стали испытывать деградацию производительности I/O.
Как можно с помощью запросов определить хотя бы общее состояние сервера?
И, по возможности, найти причину падения производительности.
Можно посмотреть, что сама база "думает" про сервер на котором работает. Есть системное представление, содержащее значения т.н. System Stats - называется SYS.AUX_STATS$, заполняется при вызове системного пакета DBMS_STATS.GATHER_SYSTEM_STATS. Содержит значения в неких внутренних оракловских "попугаях", как база оценивает производительность CPU и пропускную способность I/O. Если тот Ваш "DBA, который на аутсорсе и который не справляется" позаботился заранее, то у Вас должна быть документация по базе (и серверу), где значения из этой вьюхи записаны (IMHO это считается хорошим тоном делать такую документацию по всем обслуживаемым базам клиента, как минимум я так работаю со своими клиентами). Если Вы сейчас ещё раз запустите DBMS_STATS.GATHER_SYSTEM_STATS, значения в AUX_STATS$ обновятся, и Вы сможете сравнить, что изменилось (если изменилось!) и дальше уже думать, чинить HW, или все же с железом все нормально и что-то "поплыло" в самой базе (планы, как было сказано выше, статистика, просто нагрузка выросла / количество одновременных параллельных сессий и тд).
Кстати, давно-давно тут на форуме было общенародное "мерянье сами_понимаете_чем" (в хорошем смысле) - народ собирал статистику по их серверам и как их параметры Oracle отображает в представлении AUX_STATS$ - суть 2 поля там важны, CPUSPEEDNW и IOSEEKTIM. Сам тред:
https://www.sql.ru/forum/682014-a/cpuspeed-na-intel-xeon-5500-nehalem
Тред этот от 2009 года (последние сообщения в 2012 году), померили даже старенькую Exadata X2, в общем 10-12 лет назад уже, так что все цифры что представлены там не сильно актуальны и представляют интерес скорее в общеобразовательном плане. К тому же тогда небыло ещё виртуализации, как минимум в том виде что мы знаем и используем её сейчас. Там все цифры с реальных физических серверов.
