|
|
|
Контроль групп Redo
|
|||
|---|---|---|---|
|
#18+
Добрый день! Неожиданно налетел на новую для себя проблему. Обычно информация о проблемах с базой данных проявляется в различных мониторингах или внешних признаках. В данном случае идет речь про сервер, на котором производится активная разработка и тестирование нескольких информационных систем. В рассматриваемом случае, мониторинги справились плохо, хотя определенные признаки - рост количества активных сесиий и "зависания" базы данных проявлялись. Все это в той или иной мере время от времени происходило. В анализах отмечалась конкуренция за блоки и конфигурация. В топе появлялись явно не являющиеся причиной запросы типа анализа аудита или записи аудита. Но к счастью произошел модельный случай - один программист запустил объемное удаление из одной таблицы части записей, отобранных по некой колонке типа дата, одним оператором. Табличка размером 1.3 ГБ. В процессе удаления сессия изменила больше 250 млн. блоков. Удаление шло 9 часов. Причины такого странного поведения базы данных рассмотрим отдельно, а сейчас выявившаяся проблема. В результате объемного изменения генерилось очень много redo и все группы оказывались активными, так как транзакция шла 9 часов и ее изменения попадали во все группы. В результате все сессий становились активными и останавливалось переключение redo. Добавление новой группы позволяло продолжить работу. В результате было создано больше 40 групп по 500МБ каждая и операцию удалось довести до конца. Вопрос следующий - неужели так просто затопорить работу базы данных забив одной длинной транзакцией все группы redo? Обычно на продуктиве используются три группы redo, получается, что дастаточно двух длинных транзакций, занявщих по группе Redo, чтобы блокировать работу? Как мониторить такую проблему? Пока видится проверка процента активных сессий и процента свободных блоков. Enterprise manager на этом же инстансе с мониторингом не справился (возможно я его не умею готовить) - он все записывал, а в критический момент зависал или падал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2017, 11:47 |
|
||
|
Контроль групп Redo
|
|||
|---|---|---|---|
|
#18+
Таджикистану привет! Ты извини, но столь текста читать сложно, когда пишут на языке соседних стран. Давай коротко - есть такая-то проблема... Реально, язык форума русский, а тут столько написано на таджикском. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2017, 12:39 |
|
||
|
Контроль групп Redo
|
|||
|---|---|---|---|
|
#18+
Q.Tarantino, Привет из солнечного таджикистана - ты, видимо, писатель, а не читатель! Имеешь полное право не читать! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2017, 12:47 |
|
||
|
Контроль групп Redo
|
|||
|---|---|---|---|
|
#18+
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 Гб. Каков размер блока? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2017, 15:39 |
|
||
|
Контроль групп Redo
|
|||
|---|---|---|---|
|
#18+
flexgen1. База в archive log mode? Да flexgen2. Архивирование red log groups производится? Да, и все кроме current были архивированы flexgen3. Как выполнялось удаление, построчно или был удален набор строк по условию? Один delete, условие по двум колонкам - по одной is null, по другой, типа date - >sysdate+100 flexgen4. Когда выполнился commit? После оператора. Само действие было оформлено как безымяный блок Pl/sql, в котором было присвоено значение переменной (sysdate+100), далее шел delete, в котором условие ссылалось на эту переменную и commit. Этот блок выполнялся 9 часов и в конце сделал единственный commit; flexgen4. 250 млн блоков по 8 Kbytes каждый - это 1.9 Гб, ты указал размер таблицы как 1.3 Гб. Каков размер блока? 8 Kbytes. Размер таблицы из статистики. Я не согласен, что "250 млн блоков по 8 Kbytes каждый - это 1.9 Гб" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2017, 18:36 |
|
||
|
Контроль групп Redo
|
|||
|---|---|---|---|
|
#18+
Bfink, Не могло оказаться так, что вы просто не дождались чекпоинта при исчерпании реду групп? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2017, 12:53 |
|
||
|
Контроль групп Redo
|
|||
|---|---|---|---|
|
#18+
проходил мимо..., Поясните, пожалуйста, как чекпоинт должен пройти, если все группы редо заняты? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2017, 15:33 |
|
||
|
Контроль групп Redo
|
|||
|---|---|---|---|
|
#18+
BfinkДа, и все кроме current были архивированы BfinkПоясните, пожалуйста, как чекпоинт должен пройти, если все группы редо заняты? сперва ты поясни, а то сам себе противоречишь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2017, 16:22 |
|
||
|
Контроль групп Redo
|
|||
|---|---|---|---|
|
#18+
Q.Tarantino, Чтобы на группу редо можно было бы переключиться необходимо выполнение двух условий - она должна быть архивирована и не находиться в статусе active. В моем случае все группы, кроме current, находились в статусе active, что не позволяло провести переключение групп redo. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2017, 17:04 |
|
||
|
Контроль групп Redo
|
|||
|---|---|---|---|
|
#18+
Bfinkпроходил мимо..., Поясните, пожалуйста, как чекпоинт должен пройти, если все группы редо заняты? Эээ... А как тёплое связанно с кислым? Чекпоинт ДОЛЖЕН пройти, чтобы группа перестала быть Актив, ибо Актив всего лишь означает надобность группы для крэш-рекавери. В момент переключения логов всегда создаётся контрольная точка, но не всегда полная. Но исчерпание групп - именно тот случай, когда без этого никак... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2017, 17:56 |
|
||
|
Контроль групп Redo
|
|||
|---|---|---|---|
|
#18+
проходил мимо..., Кстати, если это именно чекпоинт вас держал, в логе об этом должно было быть написано. Несколько раз... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2017, 17:58 |
|
||
|
Контроль групп Redo
|
|||
|---|---|---|---|
|
#18+
проходил мимо..., Вы правы сообщение Checkpoint not complete выскакивало периодически вместе с сообщением типа Thread 1 cannot allocate new log, sequence 448301 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2017, 18:30 |
|
||
|
Контроль групп Redo
|
|||
|---|---|---|---|
|
#18+
Bfink, Осталось понять, что так сильно держало чекпоинт, что вы воспринимали это как останов работы. Виртуальный сервер? Датафайлы на файловой системе? Или на RAID5? Или просто сторадж занят чем-то ещё? Вариантов масса... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2017, 18:36 |
|
||
|
Контроль групп Redo
|
|||
|---|---|---|---|
|
#18+
проходил мимо..., нет, реальная машина, HDD, датафайлы на файловой системе. А можно где-то посмотреть когда и какие были checkpoint-ы? подобные напряги были периодически последние 2 недели, но здесь известна причина, время и все остальное. Почему-то количество измененных сессией блоков многократно превышает размеры таблицы, откуда удалялись строки вместе с ее индексами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2017, 18:45 |
|
||
|
Контроль групп Redo
|
|||
|---|---|---|---|
|
#18+
Когда все "устаканилось" на 35 группах, то есть появлялись 1-2 неактивные группы, сообщение стало выскакивать другое - Private strand flush not complete и delete еще шел 3 часа. В этом случае беспокоит скорость, с которой все переходит в неуправляемое состояние. Не держать же в продуктивной системе столько групп. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2017, 18:57 |
|
||
|
Контроль групп Redo
|
|||
|---|---|---|---|
|
#18+
BfinkПочему-то количество измененных сессией блоков многократно превышает размеры таблицы, откуда удалялись строки вместе с ее индексами.Вы забыли анду, так что это нормально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2017, 19:07 |
|
||
|
Контроль групп Redo
|
|||
|---|---|---|---|
|
#18+
проходил мимо...BfinkПочему-то количество измененных сессией блоков многократно превышает размеры таблицы, откуда удалялись строки вместе с ее индексами.Вы забыли анду, так что это нормально. На мой взгляд все таки слишком - в 1000 раз больше. То есть во время удаления один блок правился 1000раз? Да и весь undo значительно меньше ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2017, 19:29 |
|
||
|
Контроль групп Redo
|
|||
|---|---|---|---|
|
#18+
Bfink, У вас есть понимание того, как из индекса удаляется запись и что при этом попадает в анду? Хотя, в 1000 раз, наверное, всё равно перебор. Хотя, если индексов много и удаление шло поиском по одному из индексов - можно и в 1000.. Но это, барин, помощник (в данном случае - индекс) нужен (с) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2017, 19:39 |
|
||
|
Контроль групп Redo
|
|||
|---|---|---|---|
|
#18+
проходил мимо...Bfink, У вас есть понимание того, как из индекса удаляется запись и что при этом попадает в анду? Нет, никак до этого не доходило - все-таки массовое удаление - редкая операция в информационных системах. А предположение об удалении по индексу проверю - вполне может быть правдой, тогда это может объяснить и множественное изменение одного и того же блока данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2017, 19:49 |
|
||
|
Контроль групп Redo
|
|||
|---|---|---|---|
|
#18+
BfinkЧтобы на группу редо можно было бы переключиться необходимо выполнение двух условий - она должна быть архивирована и не находиться в статусе active. В моем случае все группы, кроме current, находились в статусе active, что не позволяло провести переключение групп redo. BfinkДа, и все кроме current были архивированы значит ты сам себе противоречишь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2017, 19:53 |
|
||
|
Контроль групп Redo
|
|||
|---|---|---|---|
|
#18+
Q.TarantinoBfinkЧтобы на группу редо можно было бы переключиться необходимо выполнение двух условий - она должна быть архивирована и не находиться в статусе active. В моем случае все группы, кроме current, находились в статусе active, что не позволяло провести переключение групп redo. BfinkДа, и все кроме current были архивированы значит ты сам себе противоречишь. Нет, не противоречу - условия то два, и оба должны быть выполнены. А одного архивирования недостаточно для переключения ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2017, 20:14 |
|
||
|
Контроль групп Redo
|
|||
|---|---|---|---|
|
#18+
[quot Bfink]Q.Tarantinoпропущено... Нет, не противоречу - условия то два, и оба должны быть выполнены. А одного архивирования недостаточно для переключения Вам надо срочно начать писать свои книги по Oracle, просто новое слово в администрировании, я то наивный думал что или или или, а тут и! Писать и срочно в редакцию, Кэйта посрамите! А программисту оторвите руки, лучше сами, нежели пльзователи сначала Вам голову. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2017, 05:23 |
|
||
|
Контроль групп Redo
|
|||
|---|---|---|---|
|
#18+
Alexey DBA, Программисты как гидры - вместо одной оторванной головы вырастает десять. И от пользователей их головами не убережешься. Книги писать не получается - слишком заумный текст выходит… А чем Вам мое утверждение не нравится? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2017, 07:43 |
|
||
|
Контроль групп Redo
|
|||
|---|---|---|---|
|
#18+
Bfinkпроходил мимо..., Поясните, пожалуйста, как чекпоинт должен пройти, если все группы редо заняты? А что мешает добавить redo или увеличить их размер? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2017, 14:26 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39489488&tid=1885578]: |
0ms |
get settings: |
6ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
155ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 206ms |
| total: | 445ms |

| 0 / 0 |
