Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Необъяснимы задержки в стримсах  [new]
Дядя Жора
Member

Откуда: Одесса
Сообщений: 817
HP-UX 11iv3 64 bit + Oracle 11.2.0.3 64 bit

Потоки работали годами и вдруг пошли какие-то непонятные задержки
Wait Class: Queueing
Wait Event: LogMiner reader: buffer

При в общем-то небольшом объёме изменений Capture стало тормозить совершенно непозволительно.
Ещё замечено, что стала бурно расти таблица SYSTEM.LOGMNR_RESTART_CKPT$
Пробовали играться параметром checkpoint_retention_time - не помогает.
Посоветуйте где начинать копать?
30 ноя 15, 17:37    [18493533]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: Необъяснимы задержки в стримсах  [new]
Avector
Member

Откуда: Санкт-Петербург
Сообщений: 362
Коллеги, такая же проблема возникла

Oracle 11.2.0.3 64 bit, Solaris

Долгое время работали стримзы, пока в субботу неожиданно не появилось ожидание Wait Event: LogMiner reader: buffer и enq: MN - contention. Накат логов идет, но с большой задержкой. За одну минуту накатывается 20 секунд логов, то есть логи не успевают накатываться.

Изменений в конфигурацию стримзов полгода не вносили, на source db также никаких DDL операций не было. Пробовал выставлять _SGA_SIZE, checkpoint_retention_time, _SEND_STREAMS_DICTIONARY, результата нет. Статистику пересобирал по c

Пока что других идей, кроме как обновления на последний патч 11.2.0.3 или 11.2.0.4 нет.
29 янв 19, 12:23    [21796684]     Ответить | Цитировать Сообщить модератору
 Re: Необъяснимы задержки в стримсах  [new]
Щукина Анна
Member

Откуда:
Сообщений: 1254
Avector,

конфигурация распределения памяти какая? по пулам как-то минимальные значения выставляете (особенно для пула стримзов - STREAMS_POOL_SIZE) или всё отдали на откуп ораклу?
29 янв 19, 12:29    [21796697]     Ответить | Цитировать Сообщить модератору
 Re: Необъяснимы задержки в стримсах  [new]
Avector
Member

Откуда: Санкт-Петербург
Сообщений: 362
Щукина Анна
Avector,

конфигурация распределения памяти какая? по пулам как-то минимальные значения выставляете (особенно для пула стримзов - STREAMS_POOL_SIZE) или всё отдали на откуп ораклу?



streams_pool_size было указано минимальное значение 10G, увеличил до 15G после появления проблем.

SQL> show parameter sga

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
sga_max_size                         big integer 100G
sga_target                           big integer 100G
SQL> show parameter streams

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
streams_pool_size                    big integer 15G

SQL> show parameter memory

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
memory_max_target                    big integer 0
memory_target                        big integer 0
29 янв 19, 12:32    [21796704]     Ответить | Цитировать Сообщить модератору
 Re: Необъяснимы задержки в стримсах  [new]
Avector
Member

Откуда: Санкт-Петербург
Сообщений: 362


К сообщению приложен файл. Размер - 41Kb
29 янв 19, 13:10    [21796766]     Ответить | Цитировать Сообщить модератору
 Re: Необъяснимы задержки в стримсах  [new]
Avector
Member

Откуда: Санкт-Петербург
Сообщений: 362


К сообщению приложен файл. Размер - 35Kb
29 янв 19, 13:11    [21796769]     Ответить | Цитировать Сообщить модератору
 Re: Необъяснимы задержки в стримсах  [new]
Avector
Member

Откуда: Санкт-Петербург
Сообщений: 362


К сообщению приложен файл. Размер - 38Kb
29 янв 19, 13:11    [21796771]     Ответить | Цитировать Сообщить модератору
 Re: Необъяснимы задержки в стримсах  [new]
Avector
Member

Откуда: Санкт-Петербург
Сообщений: 362


К сообщению приложен файл. Размер - 35Kb
29 янв 19, 13:12    [21796772]     Ответить | Цитировать Сообщить модератору
 Re: Необъяснимы задержки в стримсах  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4894
Блог
Сколько у вас процессов Capture? Какие процессы висят в Wait Queuing? Какие процессы Capture (builder, reader, preparer) в ожиданиях?
29 янв 19, 15:45    [21796984]     Ответить | Цитировать Сообщить модератору
 Re: Необъяснимы задержки в стримсах  [new]
Avector
Member

Откуда: Санкт-Петербург
Сообщений: 362
Alexander Ryndin
Сколько у вас процессов Capture? Какие процессы висят в Wait Queuing? Какие процессы Capture (builder, reader, preparer) в ожиданиях?


Александр, здравствуйте, рад, что вы подключились.

12 процессов Capture + 12 процессов Apply. Downstream Capture.

12 процессов CAP$ORCL[1-12] - Logminer Builder. Ожидание enq: MN - contention (Класс Other)
12 процессов CAP$ORCL[1-12] - Logminer Reader. Ожидание LogMiner reader: buffer (Класс Queueing)
29 янв 19, 15:58    [21797009]     Ответить | Цитировать Сообщить модератору
 Re: Необъяснимы задержки в стримсах  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4894
Блог
1) Ожидание enq: MN - contention - это блокировка, которая упорядочивает доступ к словарю Logminer со стороны нескольких процессов
2) В этом плане сама идея иметь много capture - она не очень хорошая. Для нее должны быть причины.
3) Но есть также и баги с похожими симптомами. Я бы проверил установку последних патчей. 11.2.0.3 - это довольно древняя база. Лучше иметь 11.2.0.4 с последними Bundle Patch.
4) Ноты по тем багам, которые мне удалось найти, переведены в состояние Internal. Не знаю почему. Я бы завел SR.
30 янв 19, 01:58    [21797380]     Ответить | Цитировать Сообщить модератору
 Re: Необъяснимы задержки в стримсах  [new]
Avector
Member

Откуда: Санкт-Петербург
Сообщений: 362
Alexander Ryndin
1) Ожидание enq: MN - contention - это блокировка, которая упорядочивает доступ к словарю Logminer со стороны нескольких процессов
2) В этом плане сама идея иметь много capture - она не очень хорошая. Для нее должны быть причины.
3) Но есть также и баги с похожими симптомами. Я бы проверил установку последних патчей. 11.2.0.3 - это довольно древняя база. Лучше иметь 11.2.0.4 с последними Bundle Patch.
4) Ноты по тем багам, которые мне удалось найти, переведены в состояние Internal. Не знаю почему. Я бы завел SR.


Александр, завел SR через техническую поддержку. Тогда обновлюсь до 11.2.0.3.15 сначала, если не будет результата, до 11.2.0.4.x.
30 янв 19, 08:07    [21797413]     Ответить | Цитировать Сообщить модератору
 Re: Необъяснимы задержки в стримсах  [new]
KoTTT
Member

Откуда: Екб
Сообщений: 1481
Alexander Ryndin
3) ........ Лучше иметь 11.2.0.4 с последними Bundle Patch.
4) Ноты по тем багам, которые мне удалось найти, переведены в состояние Internal. Не знаю почему. Я бы завел SR.


По пункту 4 - еще вчера начался какой-то бардак с доступом к статьям на MOS. Самые безобидные, простые ноты не открываются.

А по пункту 3. Есть пропатченная всем чем можно 11.2.0.4 (включая рекомендованные патчи для GG и Streams). Периодически процесс отскакивает назад по времени на ~сутки-двое, и начинает быстро расти размер "apply shared t" в "streams pool". Да, в базе есть долгоиграющие (точнее "долго-ничего-не-делающие" открытые транзакции). Используется только CDC, запись журналов изменений набора таблиц в журнальные таблицы в той же базе. Потом уже эти журналы читает ODI ну и далее там, здесь оно не принципиально.

Capture parallelism 4, apply parallelism 16, streams pool выставлен в 20GB (уже увеличивали с 10 до 20). Когда "apply shared t" быстро сжирает все это, начинается нарастающее отставание capture/apply, которое самостоятельно уже не ликвидируется. Все висит в "resolve low memory condition", работает, но медленно. А из-за latch:shared pool начинают уже страдать остальные сессии. Помогает только стоп capture/apply и принудительный сдвиг SCN вперед с потерей части транзакций, вероятно.

А вопрос, собственно, всего один. Если всю эту конструкцию перевести на GG, что-то изменится в лучшую сторону? GoldenGate integrated extract работает по схожему принципу? Не получим ли те же проблемы, но с другим названием и под другой вывеской?
30 янв 19, 09:49    [21797466]     Ответить | Цитировать Сообщить модератору
 Re: Необъяснимы задержки в стримсах  [new]
KoTTT
Member

Откуда: Екб
Сообщений: 1481
Или может быть еще увеличить streams pool? Как оценить нужный размер непонятно. Сейчас стоят рекомендованные 1ГБ на каждый процесс.
30 янв 19, 09:59    [21797475]     Ответить | Цитировать Сообщить модератору
 Re: Необъяснимы задержки в стримсах  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 17182
KoTTT
Или может быть еще увеличить streams pool? Как оценить нужный размер непонятно. Сейчас стоят рекомендованные 1ГБ на каждый процесс.

У ГГ integrated apply работает через тот же самый streams pool.
Размер пула должен позволить полностью разместить набор изменений самой-самой жирной, истекающей изменениями транзакции и всех изменений параллельно работающих потоков одновременно, иначе будет мучительно больно всем процессам без исключения, поскольку streams pool - один на всех.
30 янв 19, 10:53    [21797539]     Ответить | Цитировать Сообщить модератору
 Re: Необъяснимы задержки в стримсах  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 17182
andrey_anonymous
полностью разместить набор изменений самой-самой жирной, истекающей изменениями транзакции

Помимо увеличения размера streams pool можно на уровне приложения специальным образом помечать bulk-транзакции, что позволяет captute пропустить захват, а на apply по получению указанного сигнала воспроизвести активность. В теории. :)
30 янв 19, 10:58    [21797545]     Ответить | Цитировать Сообщить модератору
 Re: Необъяснимы задержки в стримсах  [new]
KoTTT
Member

Откуда: Екб
Сообщений: 1481
Ну вот сейчас capture и apply в одной базе.
А с GG думается просто сделать репликацию набора таблиц в другую базу, и уже в ней пусть там CDC корячится как ему угодно, не мешая процессам на основной БД.
В таком виде GG extract будет тупить на первой базе с длинными транзакциями?
30 янв 19, 10:59    [21797547]     Ответить | Цитировать Сообщить модератору
 Re: Необъяснимы задержки в стримсах  [new]
KoTTT
Member

Откуда: Екб
Сообщений: 1481
andrey_anonymous
Размер пула должен позволить полностью разместить набор изменений самой-самой жирной, истекающей изменениями транзакции

Так те "длинные" транзакции все маленькие. Ну пара строчек изменена и коммит/роллбэк, скажем, через 2 суток.
CDC начинает обрабатывать заново еще и все параллельные этим длинными транзакциям? Но зачем?
30 янв 19, 11:03    [21797550]     Ответить | Цитировать Сообщить модератору
 Re: Необъяснимы задержки в стримсах  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 17182
KoTTT
коммит/роллбэк, скажем, через 2 суток.
CDC начинает обрабатывать заново еще и все параллельные этим длинными транзакциям? Но зачем?

Жесткая какая-то идея про двое суток... Я бы попробовал изменить процесс так, чтобы подобного избежать.
Что прикажете aplly-процессу делать с такой транзакцией? Если он не закоммитится, то не сможет обрабатывать другие транзакции, если закоммитится а по транзакции придет отмена - то что с этим дальше делать?
30 янв 19, 11:29    [21797583]     Ответить | Цитировать Сообщить модератору
 Re: Необъяснимы задержки в стримсах  [new]
KoTTT
Member

Откуда: Екб
Сообщений: 1481
Это клиентское "толстое" приложение. Оператор там что-то ковыряет, забывает, потом уходит на обед, на выходные (или в отпуск, да).
Ответственные за это приложение пока не прониклись нашими просьбами что-то в консерватории исправить. Поэтому вот что имеем...
30 янв 19, 11:34    [21797590]     Ответить | Цитировать Сообщить модератору
 Re: Необъяснимы задержки в стримсах  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 17182
KoTTT
Это клиентское "толстое" приложение. Оператор там что-то ковыряет, забывает, потом уходит на обед, на выходные (или в отпуск, да).
Ответственные за это приложение пока не прониклись нашими просьбами что-то в консерватории исправить. Поэтому вот что имеем...

Ну дык профиль им прикрутить и резать по idle time часиков 8... Или лучше на сетевом оборудовании простаивающие соединения рубить, если позволяет.

...с BATCHSQL_MODE на apply попробуйте поиграться.
30 янв 19, 11:39    [21797595]     Ответить | Цитировать Сообщить модератору
 Re: Необъяснимы задержки в стримсах  [new]
KoTTT
Member

Откуда: Екб
Сообщений: 1481
Так не в нашей зоне ответственности принимать решение рубить или не рубить. Может там какие-то супер-критичные данные (ясно, что нет, но не нам решать).
andrey_anonymous
...с BATCHSQL_MODE на apply попробуйте поиграться.

Пошел читать.

Но все же я о другом.
Если оставить на исходной БД только GG extract, он будет отъедать память и мешать остальным в аналогичных ситуациях? А что там будет происходить на БД приемнике - вообще мало волнует.
30 янв 19, 11:49    [21797601]     Ответить | Цитировать Сообщить модератору
 Re: Необъяснимы задержки в стримсах  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 17182
KoTTT
GG extract, он будет отъедать память и мешать остальным в аналогичных ситуациях?

extract-y фиолетово на транзакции. Будет просто писать свои trail-файлы.
Если уж очень опасаетесь - поищите нотку про ALO MODE
30 янв 19, 12:09    [21797625]     Ответить | Цитировать Сообщить модератору
 Re: Необъяснимы задержки в стримсах  [new]
orac_list
Member

Откуда:
Сообщений: 119
KoTTT
А по пункту 3. Есть пропатченная всем чем можно 11.2.0.4 (включая рекомендованные патчи для GG и Streams). Периодически процесс отскакивает назад по времени на ~сутки-двое, и начинает быстро расти размер "apply shared t" в "streams pool". Да, в базе есть долгоиграющие (точнее "долго-ничего-не-делающие" открытые транзакции). Используется только CDC, запись журналов изменений набора таблиц в журнальные таблицы в той же базе. Потом уже эти журналы читает ODI ну и далее там, здесь оно не принципиально.

Capture parallelism 4, apply parallelism 16, streams pool выставлен в 20GB (уже увеличивали с 10 до 20). Когда "apply shared t" быстро сжирает все это, начинается нарастающее отставание capture/apply, которое самостоятельно уже не ликвидируется. Все висит в "resolve low memory condition", работает, но медленно. А из-за latch:shared pool начинают уже страдать остальные сессии. Помогает только стоп capture/apply и принудительный сдвиг SCN вперед с потерей части транзакций, вероятно.

А вопрос, собственно, всего один. Если всю эту конструкцию перевести на GG, что-то изменится в лучшую сторону? GoldenGate integrated extract работает по схожему принципу? Не получим ли те же проблемы, но с другим названием и под другой вывеской?


На GG сталкивались с таким поведением (рост apply shared t и исчерпание shared pool). Оказался баг 27400598
Integrated Replicat Lag With Very High Usage Of Streams Pool (Doc ID 2453994.1)
1 фев 19, 11:21    [21799439]     Ответить | Цитировать Сообщить модератору
 Re: Необъяснимы задержки в стримсах  [new]
Дядя Жора
Member

Откуда: Одесса
Сообщений: 817
Эк мою тему откопали через 4 года.
У нас тогда всё закончилось перезаливкой очередей. Вообще мы этим занимались регулярно. Учитывая, что в стримах несколько террабайт, то приходилось по 2-3 ночи не спать.
Потому мы взяли курс на GoldenGate. Уже пол года как окончательно избавились от стримов и наконец стали спать спокойно.
Основные плюсы OGG, что все транзакции тупо пишутся в трэйл-файлы и плевать на косяки базы. А откуда их извлекают эксракторы не важно. Или из логмайнера (интэгрэйтед) или с редологов (классик). Всё равно всё оказывается в файлах. Причём записываются только закоммиченные транзакции. Незакоммиченные OGG держит в памяти. Если OGG остановить, то он начинает перечитывать редологи с момента самой старой открытой транзакции. Это кстати было большим глюком стримов, которые постоянно затыкались на длинных транзакциях и приходилось их пропускать от чего шла рассинхронизация данных.
Возможности мониторинга даже рядом со стримами не стоят. Пристегнули всё к OEM и всё прозрачно + тысяча метрик и алертов.
Достоинства можно перечислять долго + продукт развивается в отличие от давно мёртвых стримов.
Из недостатков пока только переход на стэндбай. Стримы шли через дблинк, который спокойно реагировал при переключении. Тут всё сложнее. При плановом переходе приходится руками переносить dirchk, dirdat, BR, dirpcs. Ну и следить чтобы dirprm совпадали. При аварийном переходе пока решения нет. Изучаем. В бест-практиках везде написано класть на общую файловую систему. Но к примеру на NFS класть не кошерно как-то. Предлагают на dbfs. Но предупреждают, что всё равно возможны задержки. Но у нас hp-ux и на 11-м Оракуле dbfs не поддерживается.
1 фев 19, 23:14    [21800217]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Oracle Ответить