BfinkДобрый день! Неожиданно налетел на новую для себя проблему. Обычно информация о проблемах с базой данных проявляется в различных мониторингах или внешних признаках. В данном случае идет речь про сервер, на котором производится активная разработка и тестирование нескольких информационных систем. В рассматриваемом случае, мониторинги справились плохо, хотя определенные признаки - рост количества активных сесиий и "зависания" базы данных проявлялись. Все это в той или иной мере время от времени происходило. В анализах отмечалась конкуренция за блоки и конфигурация. В топе появлялись явно не являющиеся причиной запросы типа анализа аудита или записи аудита.
Но к счастью произошел модельный случай - один программист запустил объемное удаление из одной таблицы части записей, отобранных по некой колонке типа дата, одним оператором. Табличка размером 1.3 ГБ. В процессе удаления сессия изменила больше 250 млн. блоков. Удаление шло 9 часов. Причины такого странного поведения базы данных рассмотрим отдельно, а сейчас выявившаяся проблема. В результате объемного изменения генерилось очень много redo и все группы оказывались активными, так как транзакция шла 9 часов и ее изменения попадали во все группы. В результате все сессий становились активными и останавливалось переключение redo. Добавление новой группы позволяло продолжить работу. В результате было создано больше 40 групп по 500МБ каждая и операцию удалось довести до конца.
Вопрос следующий - неужели так просто затопорить работу базы данных забив одной длинной транзакцией все группы redo? Обычно на продуктиве используются три группы redo, получается, что дастаточно двух длинных транзакций, занявщих по группе Redo, чтобы блокировать работу? Как мониторить такую проблему? Пока видится проверка процента активных сессий и процента свободных блоков. Enterprise manager на этом же инстансе с мониторингом не справился (возможно я его не умею готовить) - он все записывал, а в критический момент зависал или падал.

Написано много, но чтобы уловить в чем проблема, надо приложить немало усилий.
У меня такие вопросы образовались:
1. База в archive log mode?
2. Архивирование red log groups производится?
3. Как выполнялось удаление, построчно или был удален набор строк по условию?
4. Когда выполнился commit?
4. 250 млн блоков по 8 Kbytes каждый - это 1.9 Гб, ты указал размер таблицы как 1.3 Гб. Каков размер блока?

Еще вопрос - что было в wait events? Что насчет блокировок? Есть ли partitions? Есть ли подходящий индекс? Было бы интересно и на план выполнения взглянуть.