ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Необъяснимы задержки в стримсах
25 сообщений из 28, страница 1 из 2
  1  все
Необъяснимы задержки в стримсах
    #39116597
Фотография Дядя Жора
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дядя Жора
Участник
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 - не помогает.
Посоветуйте где начинать копать?
...
Рейтинг: 0 / 0
30.11.2015, 17:37
| Ответить | Цитировать | Написать  
Период между сообщениями больше года.
Необъяснимы задержки в стримсах
    #39766428
Avector
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Avector
Участник
Коллеги, такая же проблема возникла

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 нет.
...
Рейтинг: 0 / 0
29.01.2019, 12:23
| Ответить | Цитировать | Написать  
Необъяснимы задержки в стримсах
    #39766439
Фотография Щукина Анна
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Щукина Анна
Участник
Avector,

конфигурация распределения памяти какая? по пулам как-то минимальные значения выставляете (особенно для пула стримзов - STREAMS_POOL_SIZE) или всё отдали на откуп ораклу?
...
Рейтинг: 0 / 0
29.01.2019, 12:29
| Ответить | Цитировать | Написать  
Необъяснимы задержки в стримсах
    #39766445
Avector
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Avector
Участник
Щукина АннаAvector,

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


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

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
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
...
Рейтинг: 0 / 0
29.01.2019, 12:32
| Ответить | Цитировать | Написать  
Необъяснимы задержки в стримсах
    #39766484
Avector
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Avector
Участник
...
Рейтинг: 0 / 0
29.01.2019, 13:10
| Ответить | Цитировать | Написать  
Необъяснимы задержки в стримсах
    #39766487
Avector
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Avector
Участник
...
Рейтинг: 0 / 0
29.01.2019, 13:11
| Ответить | Цитировать | Написать  
Необъяснимы задержки в стримсах
    #39766489
Avector
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Avector
Участник
...
Рейтинг: 0 / 0
29.01.2019, 13:11
| Ответить | Цитировать | Написать  
Необъяснимы задержки в стримсах
    #39766490
Avector
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Avector
Участник
...
Рейтинг: 0 / 0
29.01.2019, 13:12
| Ответить | Цитировать | Написать  
Необъяснимы задержки в стримсах
    #39766616
Alexander Ryndin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexander Ryndin
Участник
Сколько у вас процессов Capture? Какие процессы висят в Wait Queuing? Какие процессы Capture (builder, reader, preparer) в ожиданиях?
...
Рейтинг: 0 / 0
29.01.2019, 15:45
| Ответить | Цитировать | Написать  
Необъяснимы задержки в стримсах
    #39766631
Avector
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Avector
Участник
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)
...
Рейтинг: 0 / 0
29.01.2019, 15:58
| Ответить | Цитировать | Написать  
Необъяснимы задержки в стримсах
    #39766813
Alexander Ryndin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexander Ryndin
Участник
1) Ожидание enq: MN - contention - это блокировка, которая упорядочивает доступ к словарю Logminer со стороны нескольких процессов
2) В этом плане сама идея иметь много capture - она не очень хорошая. Для нее должны быть причины.
3) Но есть также и баги с похожими симптомами. Я бы проверил установку последних патчей. 11.2.0.3 - это довольно древняя база. Лучше иметь 11.2.0.4 с последними Bundle Patch.
4) Ноты по тем багам, которые мне удалось найти, переведены в состояние Internal. Не знаю почему. Я бы завел SR.
...
Рейтинг: 0 / 0
30.01.2019, 01:58
| Ответить | Цитировать | Написать  
Необъяснимы задержки в стримсах
    #39766827
Avector
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Avector
Участник
Alexander Ryndin1) Ожидание 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.
...
Рейтинг: 0 / 0
30.01.2019, 08:07
| Ответить | Цитировать | Написать  
Необъяснимы задержки в стримсах
    #39766864
KoTTT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KoTTT
Участник
Alexander Ryndin3) ........ Лучше иметь 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 работает по схожему принципу? Не получим ли те же проблемы, но с другим названием и под другой вывеской?
...
Рейтинг: 0 / 0
30.01.2019, 09:49
| Ответить | Цитировать | Написать  
Необъяснимы задержки в стримсах
    #39766870
KoTTT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KoTTT
Участник
Или может быть еще увеличить streams pool? Как оценить нужный размер непонятно. Сейчас стоят рекомендованные 1ГБ на каждый процесс.
...
Рейтинг: 0 / 0
30.01.2019, 09:59
| Ответить | Цитировать | Написать  
Необъяснимы задержки в стримсах
    #39766904
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
KoTTTИли может быть еще увеличить streams pool? Как оценить нужный размер непонятно. Сейчас стоят рекомендованные 1ГБ на каждый процесс.
У ГГ integrated apply работает через тот же самый streams pool.
Размер пула должен позволить полностью разместить набор изменений самой-самой жирной, истекающей изменениями транзакции и всех изменений параллельно работающих потоков одновременно, иначе будет мучительно больно всем процессам без исключения, поскольку streams pool - один на всех.
...
Рейтинг: 0 / 0
30.01.2019, 10:53
| Ответить | Цитировать | Написать  
Необъяснимы задержки в стримсах
    #39766906
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
andrey_anonymousполностью разместить набор изменений самой-самой жирной, истекающей изменениями транзакции
Помимо увеличения размера streams pool можно на уровне приложения специальным образом помечать bulk-транзакции, что позволяет captute пропустить захват, а на apply по получению указанного сигнала воспроизвести активность. В теории. :)
...
Рейтинг: 0 / 0
30.01.2019, 10:58
| Ответить | Цитировать | Написать  
Необъяснимы задержки в стримсах
    #39766907
KoTTT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KoTTT
Участник
Ну вот сейчас capture и apply в одной базе.
А с GG думается просто сделать репликацию набора таблиц в другую базу, и уже в ней пусть там CDC корячится как ему угодно, не мешая процессам на основной БД.
В таком виде GG extract будет тупить на первой базе с длинными транзакциями?
...
Рейтинг: 0 / 0
30.01.2019, 10:59
| Ответить | Цитировать | Написать  
Необъяснимы задержки в стримсах
    #39766910
KoTTT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KoTTT
Участник
andrey_anonymousРазмер пула должен позволить полностью разместить набор изменений самой-самой жирной, истекающей изменениями транзакции
Так те "длинные" транзакции все маленькие. Ну пара строчек изменена и коммит/роллбэк, скажем, через 2 суток.
CDC начинает обрабатывать заново еще и все параллельные этим длинными транзакциям? Но зачем?
...
Рейтинг: 0 / 0
30.01.2019, 11:03
| Ответить | Цитировать | Написать  
Необъяснимы задержки в стримсах
    #39766920
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
KoTTT коммит/роллбэк, скажем, через 2 суток.
CDC начинает обрабатывать заново еще и все параллельные этим длинными транзакциям? Но зачем?
Жесткая какая-то идея про двое суток... Я бы попробовал изменить процесс так, чтобы подобного избежать.
Что прикажете aplly-процессу делать с такой транзакцией? Если он не закоммитится, то не сможет обрабатывать другие транзакции, если закоммитится а по транзакции придет отмена - то что с этим дальше делать?
...
Рейтинг: 0 / 0
30.01.2019, 11:29
| Ответить | Цитировать | Написать  
Необъяснимы задержки в стримсах
    #39766927
KoTTT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KoTTT
Участник
Это клиентское "толстое" приложение. Оператор там что-то ковыряет, забывает, потом уходит на обед, на выходные (или в отпуск, да).
Ответственные за это приложение пока не прониклись нашими просьбами что-то в консерватории исправить. Поэтому вот что имеем...
...
Рейтинг: 0 / 0
30.01.2019, 11:34
| Ответить | Цитировать | Написать  
Необъяснимы задержки в стримсах
    #39766930
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
KoTTTЭто клиентское "толстое" приложение. Оператор там что-то ковыряет, забывает, потом уходит на обед, на выходные (или в отпуск, да).
Ответственные за это приложение пока не прониклись нашими просьбами что-то в консерватории исправить. Поэтому вот что имеем...
Ну дык профиль им прикрутить и резать по idle time часиков 8... Или лучше на сетевом оборудовании простаивающие соединения рубить, если позволяет.

...с BATCHSQL_MODE на apply попробуйте поиграться.
...
Рейтинг: 0 / 0
30.01.2019, 11:39
| Ответить | Цитировать | Написать  
Необъяснимы задержки в стримсах
    #39766934
KoTTT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KoTTT
Участник
Так не в нашей зоне ответственности принимать решение рубить или не рубить. Может там какие-то супер-критичные данные (ясно, что нет, но не нам решать).
andrey_anonymous...с BATCHSQL_MODE на apply попробуйте поиграться.
Пошел читать.

Но все же я о другом.
Если оставить на исходной БД только GG extract, он будет отъедать память и мешать остальным в аналогичных ситуациях? А что там будет происходить на БД приемнике - вообще мало волнует.
...
Рейтинг: 0 / 0
30.01.2019, 11:49
| Ответить | Цитировать | Написать  
Необъяснимы задержки в стримсах
    #39766952
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
KoTTTGG extract, он будет отъедать память и мешать остальным в аналогичных ситуациях?
extract-y фиолетово на транзакции. Будет просто писать свои trail-файлы.
Если уж очень опасаетесь - поищите нотку про ALO MODE
...
Рейтинг: 0 / 0
30.01.2019, 12:09
| Ответить | Цитировать | Написать  
Необъяснимы задержки в стримсах
    #39768000
orac_list
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
orac_list
Гость
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)
...
Рейтинг: 0 / 0
01.02.2019, 11:21
| Ответить | Цитировать | Написать  
Необъяснимы задержки в стримсах
    #39768560
Фотография Дядя Жора
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дядя Жора
Участник
Эк мою тему откопали через 4 года.
У нас тогда всё закончилось перезаливкой очередей. Вообще мы этим занимались регулярно. Учитывая, что в стримах несколько террабайт, то приходилось по 2-3 ночи не спать.
Потому мы взяли курс на GoldenGate. Уже пол года как окончательно избавились от стримов и наконец стали спать спокойно.
Основные плюсы OGG, что все транзакции тупо пишутся в трэйл-файлы и плевать на косяки базы. А откуда их извлекают эксракторы не важно. Или из логмайнера (интэгрэйтед) или с редологов (классик). Всё равно всё оказывается в файлах. Причём записываются только закоммиченные транзакции. Незакоммиченные OGG держит в памяти. Если OGG остановить, то он начинает перечитывать редологи с момента самой старой открытой транзакции. Это кстати было большим глюком стримов, которые постоянно затыкались на длинных транзакциях и приходилось их пропускать от чего шла рассинхронизация данных.
Возможности мониторинга даже рядом со стримами не стоят. Пристегнули всё к OEM и всё прозрачно + тысяча метрик и алертов.
Достоинства можно перечислять долго + продукт развивается в отличие от давно мёртвых стримов.
Из недостатков пока только переход на стэндбай. Стримы шли через дблинк, который спокойно реагировал при переключении. Тут всё сложнее. При плановом переходе приходится руками переносить dirchk, dirdat, BR, dirpcs. Ну и следить чтобы dirprm совпадали. При аварийном переходе пока решения нет. Изучаем. В бест-практиках везде написано класть на общую файловую систему. Но к примеру на NFS класть не кошерно как-то. Предлагают на dbfs. Но предупреждают, что всё равно возможны задержки. Но у нас hp-ux и на 11-м Оракуле dbfs не поддерживается.
...
Рейтинг: 0 / 0
01.02.2019, 23:14
| Ответить | Цитировать | Написать  
25 сообщений из 28, страница 1 из 2
  1  все
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Необъяснимы задержки в стримсах
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=52&fpage=85&tid=1882834]:
 0ms
get settings:
 9ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 31ms
get topic data:
 13ms
get forum data:
 3ms
get page messages:
 67ms
get tp. blocked users:
 2ms
others: 12ms
total:  158ms
созд. / загр.: 158ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]