Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
DenKrep
Member

Откуда: Киев
Сообщений: 74
Привет,
Ситуация.
Oracle 10.2.0.4. Undo = 2 Gb (сразу говорю - больше не дадут).

Есть таблица. Назовём её ttt.
Volume ~= 70 mln records. ~=20 Gb.

Заполняется daily процессом, который длится где-то 2.5 часа.

Truncate table ttt;

For ... loop
insert into ttt select from bla_bla; -- aprx 1 mln record
commit
end loop;
по окончанию
update flag_table set flag = sysdate;
commit;

Как только процесс закончился, по этому флагу ( там пуллинг стоит) начинается (из другой сессии)
select * from ttt where date_date>sysdate-25; -- По сути выпадает в full scan, ибо под это условие попадает порядка 50% таблицы.

Select этот идёт долго (ибо клиент находится далеко по сети и fetch 40 лямов проходит не быстро, и если быть точным - 1000 строк в секунду).

И вот где-то на середине (часа через 3-4 где то) выпадает процес по ORA-01555.

НО! Никто больше не трогает эту таблицу. Проверено по логам, подняли DBA. Никаких DML с ней никто не делал. select идёт чётко после коммита последнего изменения. Undo ему уже по идее нафиг не нужен!!
После падения по ORA-01555 процесс перезапускается и теперь уже выполняется чётко и без ошибок.

В чём может быть дело и как можно лечить? Накопали на металинке и по и-нету про Delayed block cleanout. Делать после заливки select с фулсканом по ttt, а только потом запускать селект пробовали. Не помогло! :( Да и зачем ему может быть undo при truncate - insert ? Я чего-то не понимаю?

Заранее спасибо за ответы... Задавайте доп-вопросы если что прояснить.
10 июн 10, 01:33    [8920146]     Ответить | Цитировать Сообщить модератору
 Re: Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
Жук в муравейнике
Member

Откуда:
Сообщений: 717
А чего не дают больше увеличить анду? Странно как-то ей богу-то
10 июн 10, 01:41    [8920157]     Ответить | Цитировать Сообщить модератору
 Re: Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
DenKrep
Member

Откуда: Киев
Сообщений: 74
Вован, тебе как раз это известно лучше других :) Жизнь как она есть.
Не троли, а подскажи чё делать то.

PS: Да, кстати, забыл сказать - за время жизни заливки данных и селекта - параллельно происходит много и других заливок и селектов. НО С ДРУГИМИ ТАБЛИЦАМИ!!! Undo юзается вдоль и поперёк, думаю что перетирается по самое нимагу :)
10 июн 10, 01:45    [8920164]     Ответить | Цитировать Сообщить модератору
 Re: Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4917
Блог
DenKrep,

ну вообще ощущение, что архитектурно где-то фигня у вас. чего-то менять надо.
вариант сделать временную табличку с помощью CTAS, а потом уже из нее дергать не пробовали?
10 июн 10, 02:29    [8920243]     Ответить | Цитировать Сообщить модератору
 Re: Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
DenKrep
Member

Откуда: Киев
Сообщений: 74
Alexander Ryndin,
в чём фигня архитектурная то? Можно конструктивнее?
Моё виделение - архитектурно это вполне стандартный подход для хранилища. Кстати ttt - ничто иное как summary table построенная на основе fact и ряда static data.
т.е.

insert into ttt_summart as select ... from fact ....

Ну это грубо говоря.

Процесс изменения процесса на инкременальный - in progress - тут не всё очень просто, но может и спасёт... временно.

Тем не менее - это всё равно бомба замедленного действия. Завтра инкремент снова станет достаточно большой - и что тогда? И вообще - вина ли БОЛЬШОГО размера insert-ов? При insert statement undo ведь не растёт практически - проверял :) Чего ему расти то? Старых то значений нету!

Хотелось бы понять the root cause такого поведения Оракла и как с таким бороться.
10 июн 10, 02:45    [8920262]     Ответить | Цитировать Сообщить модератору
 Re: Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
DenKrep
Member

Откуда: Киев
Сообщений: 74
PS: CTAS ( в одну итерацию ) не пройдёт - повторюсь объём данных не малый. Завалимся на нехватке ресурсов для выполнения столь большой операции одним балком. Да и выполняться будет дольше.
10 июн 10, 02:47    [8920266]     Ответить | Цитировать Сообщить модератору
 Re: Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
DenKrep
PS: CTAS ( в одну итерацию ) не пройдёт - повторюсь объём данных не малый. Завалимся на нехватке ресурсов для выполнения столь большой операции одним балком. Да и выполняться будет дольше.
Каких еще ресурсов не хватит... При приведенной схеме ресурсов тратится принципиально больше чем при CTAS...
10 июн 10, 03:12    [8920286]     Ответить | Цитировать Сообщить модератору
 Re: Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Если используется truncate, то логично грузить через direct path чтобы избавиться от undo. Т.е. удаляем индексы, грузим в direct path, создаем индексы. Грузить кусками через commit в этом случае не надо, т.к. undo не генерится. Остается странный update всех строк в sysdate. Почему бы не таблицу с одной строкой не проапдэйтить? Если мучает вопрос по отложенной очистке блоков - смотрим статистки по '%cleanout%' - есть ли большой рост. Для select логично использовать parallel.
10 июн 10, 03:18    [8920291]     Ответить | Цитировать Сообщить модератору
 Re: Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
DenKrep
Member

Откуда: Киев
Сообщений: 74
wurdu, каких имено ресурсов тратиться больше в приведённой схеме?
Что бы ни писал кайт, но 1 транзакции на 24 Гб логов (+ потребления temp и прочих ресурсов на joins, orders и тд.). Просто не хватит ресурсов сервера. Вы сейчас пытаетесь решить не ту задачу о которой спрашивают. Если не чего сказать по теме разговора - промолчите.

Поясните лучше происхождение ORA-01555 в данном случае и как с ним бороться.
10 июн 10, 10:13    [8920976]     Ответить | Цитировать Сообщить модератору
 Re: Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
DenKrep
Member

Откуда: Киев
Сообщений: 74
wurdu
Если используется truncate, то логично грузить через direct path чтобы избавиться от undo. Т.е. удаляем индексы, грузим в direct path, создаем индексы. Грузить кусками через commit в этом случае не надо, т.к. undo не генерится. Остается странный update всех строк в sysdate. Почему бы не таблицу с одной строкой не проапдэйтить? Если мучает вопрос по отложенной очистке блоков - смотрим статистки по '%cleanout%' - есть ли большой рост. Для select логично использовать parallel.


1) Сейчас данные грузяться через insert /+ appроnd*/
Таблица nolog.
Какие бенефиты даст ваш метод и как он позволит решить мою проблему? Каждая новая попытка (новый способ) - ещё день жизни проблемы на production. Просто стрелять в воздух я не могу.

2) А при НЕ direct path load, большой undo разве от inserts генерируется? :) А что в этот undo попадает, простите?

3) update делается не для всех строк, а для всего одной. И ни этой таблицы, а другой - флаговой. Это просто таблица с состояниями. Проставляется что данные для такой-то области обновлены до состояния времени systdate. Повторюсь - это просто флаговая таблица.

4) Селект работает в parallel enable 4.

5) Мучает собственно ORA-01555 там где он не должен быть.
10 июн 10, 10:19    [8921042]     Ответить | Цитировать Сообщить модератору
 Re: Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
DenKrep
Member

Откуда: Киев
Сообщений: 74
сорри набриал быстро. Конечно имелся в виду +apppend
10 июн 10, 10:31    [8921163]     Ответить | Цитировать Сообщить модератору
 Re: Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
env
Member

Откуда: Россия, Москва
Сообщений: 6712
DenKrep

1) Сейчас данные грузяться через insert /+ appрend*/
Таблица nolog.
Какие бенефиты даст ваш метод и как он позволит решить мою проблему? Каждая новая попытка (новый способ) - ещё день жизни проблемы на production. Просто стрелять в воздух я не могу.

2) А при НЕ direct path load, большой undo разве от inserts генерируется? :) А что в этот undo попадает, простите?

3) update делается не для всех строк, а для всего одной. И ни этой таблицы, а другой - флаговой. Это просто таблица с состояниями. Проставляется что данные для такой-то области обновлены до состояния времени systdate. Повторюсь - это просто флаговая таблица.

4) Селект работает в parallel enable 4.

5) Мучает собственно ORA-01555 там где он не должен быть.


1) Меньшая нагрузка на undo
2) А простите, undo change vectors для вашего inserta куда должны попадать?

0. Truncate идёт с drop storage или с reuse storage?
1. "select идёт чётко после коммита последнего изменения." - сразу? А LGWR, DBWR и ARCn у вас уже всё доотработали по предыдущему стейтменту?
10 июн 10, 11:28    [8921837]     Ответить | Цитировать Сообщить модератору
 Re: Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
Жук в муравейнике
Member

Откуда:
Сообщений: 717
DenKrep

select * from ttt where date_date>sysdate-25; -- По сути выпадает в full scan, ибо под это условие попадает порядка 50% таблицы.

А если эту хрень заставить выпасть в index scan
Или фулсканить в цикле с целью сделать cleanout
10 июн 10, 11:44    [8922038]     Ответить | Цитировать Сообщить модератору
 Re: Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
Жук в муравейнике
Member

Откуда:
Сообщений: 717
Деня, интересно, а чему undo_retention равен?
10 июн 10, 11:56    [8922197]     Ответить | Цитировать Сообщить модератору
 Re: Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
DenKrep
wurdu, каких имено ресурсов тратиться больше в приведённой схеме?
Что бы ни писал кайт, но 1 транзакции на 24 Гб логов (+ потребления temp и прочих ресурсов на joins, orders и тд.). Просто не хватит ресурсов сервера. Вы сейчас пытаетесь решить не ту задачу о которой спрашивают. Если не чего сказать по теме разговора - промолчите.

Поясните лучше происхождение ORA-01555 в данном случае и как с ним бороться.
Про ресурсы сервера все равно не ясно. Должна быть очень специфичная ситуация чтобы много проходов давали выигрыш. Судя по отсутствию знаний по undo, и про "Что бы ни писал кайт", решение принималось на основании фантазий, а не конкретных цифр. Про ORA-01555 из-за Delayed block cleanout уже написано - надо смотреть статистики. Судя по ошибке в слове append в обоих постах - не удивлюсь что на продакшине он не работает. Остается открытым вопрос про индексы - все это происходит без их удаления? По факту - если работает direct path, то блоки пишутся минуя buffer cache и собственно проблема с cleanout отсутствует. Так что остается убедиться что direct path работает, залочить таблицу после загрузки и запустить select.
10 июн 10, 12:03    [8922293]     Ответить | Цитировать Сообщить модератору
 Re: Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
env
Member

Откуда: Россия, Москва
Сообщений: 6712
DenKrep,

Что бы ни писал кайт
ссылка для потомков
10 июн 10, 12:10    [8922368]     Ответить | Цитировать Сообщить модератору
 Re: Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
автор
Таблица nolog
...
но 1 транзакции на 24 Гб логов
Ты определись, у тебя nologging или 24 Гб логов.
10 июн 10, 12:14    [8922425]     Ответить | Цитировать Сообщить модератору
 Re: Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
env
Member

Откуда: Россия, Москва
Сообщений: 6712
wurdu,

М.б. у вас "под руками" есть ссылки на доку, где подробно описывается механизм заполнения undo при insert?
10 июн 10, 12:15    [8922427]     Ответить | Цитировать Сообщить модератору
 Re: Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
DenKrep
Member

Откуда: Киев
Сообщений: 74
env,

Ссылка для потомков на сайт Кайта помогает мало. В этом своём ответе он лишь цитирует одну из двух основных нот с металинка по ora-01555 (эта с боолее углубленным пояснением), обе из которых уже изучено, предложенные solutions применены, (основное - прочитать таблицу с фулсканом сразу после загрузки, для cleanout). Время ETL увеличилось, а толку нет - не помогло.
10 июн 10, 12:19    [8922483]     Ответить | Цитировать Сообщить модератору
 Re: Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
env
wurdu,

М.б. у вас "под руками" есть ссылки на доку, где подробно описывается механизм заполнения undo при insert?
Вот тут неплохо написано: AUTOMATIC UNDO INTERNALS
10 июн 10, 12:21    [8922507]     Ответить | Цитировать Сообщить модератору
 Re: Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
wildwind
Member

Откуда: Москва
Сообщений: 1296
DenKrep,

Может у вас перетираются не undo блоки, а слоты в таблице транзакций в заголовке undo сегмента. Это бывает при большой dml активности. Проверьте.
10 июн 10, 12:49    [8922845]     Ответить | Цитировать Сообщить модератору
 Re: Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
Bfink
Member

Откуда: Москва
Сообщений: 2797
DenKrep,

а какие индексы на табличке?
10 июн 10, 12:53    [8922893]     Ответить | Цитировать Сообщить модератору
 Re: Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
env
Member

Откуда: Россия, Москва
Сообщений: 6712
wurdu,

Огромное спасибо. Буду читать.
10 июн 10, 13:29    [8923283]     Ответить | Цитировать Сообщить модератору
 Re: Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
DenKrep
Member

Откуда: Киев
Сообщений: 74
2Wurdu - cпасибо за статью - новая информация для размышления. Почитаю - вернусь...
2Bfink - 3 b*tree index.

Wurdu
... nologging или 24 Гб логов.

По estimate, чтобы покрыть этот запрос полностью надо было бы иметь undo на без мелкого 24 Gb. Это только на него. Плюс ещё море других запросов параллельно бегает. 100 Gb undo нам никто не даст.

Жук
А если эту хрень заставить выпасть в index scan

То будем ждать до следующего пришествия. Смысл? Выборочность запроса - около 50%.

env
. "select идёт чётко после коммита последнего изменения." - сразу? А LGWR, DBWR и ARCn у вас уже всё доотработали по предыдущему стейтменту?

Может и не успели доработать. Не знаю. По сути - там стоит отдельный процесс, которые раз в несколько минут пулает табличку с флагом. Как только видит, что флаг проставился - начинает селектить. Как правило получалось так, что стартовал процесс не позже чем через минуту...

>Судя по ошибке в слове append в обоих постах - не удивлюсь что на продакшине он не работает
Интересно, а Вы никогда не опечатываетесь? Особенно поспав всего 4 часа...

> ...решение принималось на основании фантазий, а не конкретных цифр
Решение принималось на основе проб, проверок и расчётов. Но за давностью этой работы, у меня под рукой этих цифр нету, потому в студию их привести не могу. Единому insert as select банально не хватало ресурсов. Сейчас уже и не вспомню чего именно. Добавить ресурсов (undo / temp итд) - не предлагать ибо не применимо.

По поводу direct path - постараюсь проверить. Можете подсказать как лучше убедиться? (с учётом того, что это insert-ы, сам undo сильно расти не будет. Собрать статистику по v$statname и v$session?

>Деня, интересно, а чему undo_retention равен?

SQL> show parameter undo;
 
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
undo_management                      string      AUTO
undo_retention                       integer     7200
undo_tablespace                      string      UNDO
10 июн 10, 14:56    [8924277]     Ответить | Цитировать Сообщить модератору
 Re: Delayed block cleanout ? (ORA-01555). Как бороться.  [new]
DenKrep
Member

Откуда: Киев
Сообщений: 74
Ещё немного информации по теме:
-------------------------------------------------- 
*                     UNDO Health                * 
-------------------------------------------------- 
Problem                             : Undo tablespace cannot support required undo retention 
Recommendation                      : Size undo tablespace to 23779 MB 
Rationale                           : Increase undo tablespace size so that long running queries will not fail 
undo_retention (secs)               : 7200 
undo_retention (hrs/mins)           : 2 hrs 0 mins 
Guaranteed Retention                : FALSE 
Longest Run Query (secs)            : 15549 
Longest Run Query (hrs/mins)        : 4 hrs 19 mins 
Recommended Undo T/S Size (MB)      : 23779 
Current Undo T/S Size (MB)          : 2000 
10 июн 10, 15:03    [8924363]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Oracle Ответить