Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 Logical standby: зависание SQL Apply  [new]
logical_standby
Guest
Здравствуйте!

Есть основная база - 10.2.0.2, SunOS 5.10, logical standby - 10.2.0.2, SunOS 5.10. Есть проблемы, связанные с накатом. Проблемы заключаются в очень медленном накате DDL, в частности, truncate и в медленном накате удалений из больших таблиц.
По сути, в обоих случаях накат как бы зависает... В случае удаления работает только один Applier, остальные висят с сообщением ORA-16116: no work available. Остальные процессы (BUILDER, READER, PREPARER) висят с сообщением ORA-16127: stalled waiting for additional transactions to be applied.
В случае truncate Builder зависает с сообщением ORA-16231: DDL barrier. Далее остальные работающие транзакции докатывают до HIGH_SCN, который может быть достаточно большим иногда. Накат до этого SCN происходит ну оооо-чень медленно.

Вопрос простой: что делать??
Буду благодарен за любые советы и ссылки.
26 авг 08, 23:05    [6112447]     Ответить | Цитировать Сообщить модератору
 Re: Logical standby: зависание SQL Apply  [new]
logical_standby
Guest
Проблема с удалениями состоит в следующем, насколько я понимаю. Во-первых, вместо delete * from some_table на основном сервере, на логическом удаления выполняются построчно. Во-вторых, если транзакция идентифицируется как eager, то есть такая, которая не может целиком поместиться в LCR Cache, в том смысле, что BUILDER не способен полностью сформировать все выражения, и в результате транзакция выполняется "by trickling records into the standby database as they become available", все остальные при этом ждут, пока она "trickling". На практике это означает задержку в 4-8 часов и постепенное, но неуклонное отставание от основной базы.
Есть ли возможность что-то с этим сделать?
27 авг 08, 11:54    [6113879]     Ответить | Цитировать Сообщить модератору
 Re: Logical standby: зависание SQL Apply  [new]
logical_standby
Guest
Up?

Что, no comments?
27 авг 08, 22:35    [6117416]     Ответить | Цитировать Сообщить модератору
 Re: Logical standby: зависание SQL Apply  [new]
Жена логического стендбая
Guest
Спят усталые игрушки...
28 авг 08, 01:01    [6117709]     Ответить | Цитировать Сообщить модератору
 Re: Logical standby: зависание SQL Apply  [new]
Интересно
Guest
Интересно, как проблему решили?
28 авг 08, 17:15    [6121549]     Ответить | Цитировать Сообщить модератору
 Re: Logical standby: зависание SQL Apply  [new]
Alex Roudnev
Member

Откуда: Валнут Крик, Калифорния
Сообщений: 5547
Интересно
Интересно, как проблему решили?


Мы погоняли логический стендбай где то с годик.

Видели эту проблему раз 5. Раза 4 помогало терпение и ручной сбор статистики, в пятый помог топор палача - логического стендбая в лабе больше нет.
28 авг 08, 21:30    [6122424]     Ответить | Цитировать Сообщить модератору
 Re: Logical standby: зависание SQL Apply  [new]
logical_standby
Guest
2 Интересно:
Проблема пока далека от решения.

2 Alex Roudnev:
Пока что есть мнение увеличить _EAGER_SIZE и посмотреть, на каком значении отставание не будет таким значительным.
А как помогает ручной сбор статистики? Если уникальный индекс или первичный ключ на таблице есть, то они при удалении используются. Как может влиять статистика?
28 авг 08, 22:32    [6122551]     Ответить | Цитировать Сообщить модератору
 Re: Logical standby: зависание SQL Apply  [new]
Alex Roudnev
Member

Откуда: Валнут Крик, Калифорния
Сообщений: 5547
logical_standby
2 Интересно:
Проблема пока далека от решения.

2 Alex Roudnev:
Пока что есть мнение увеличить _EAGER_SIZE и посмотреть, на каком значении отставание не будет таким значительным.
А как помогает ручной сбор статистики? Если уникальный индекс или первичный ключ на таблице есть, то они при удалении используются. Как может влиять статистика?


Статистика у нас влияла так, что на стендбае она просто не собиралась автоматом (то ли по задумке авторов то ли _ну не шмогла я_). Руками запускали и стендбай шустренько так начинал бегать.

На самом деле все работало более-менее сносно - к моему изумлению ЛС встал через ОЕМ даже без проблемы с файл менеджментом которая всегда вылезает в физическом стендбае, и не разу не развалился при всех переключениях (он тоже стоял в автоматической файловер с автоматическим переключением клиентов).

А убила его двукратная переинсталляция одного инстанса (схемы в терминах оракла) в котором
оказался о...нных размеров CLOB набитый какими то xml-ями - добрые разработчики свалили туда аудит системы в формате xml. База честно пыталась его набить в логическом стендбае (там была пара гигабайтов) а наши DBA пытались раза три это соптимизировать - через месяц стало ясно, что наверное году так в 2010 оно синхронизуется, переустанавливать стендбай рменом смысла не было, а главное стало ясно, что штука реально достаточно ограниченно применимая в условиях активной разработки, если только не тестируется сразу у девелоперов, потому как все время думать, что там в следующий раз отстанет, никому не хочется - и ее прибили.

Хотя в целом оно работало исключительно стабильно.
29 авг 08, 01:14    [6122935]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить