powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Oracle [игнор отключен] [закрыт для гостей] / ora01555 - SNAPSHOT TOO OLD
25 сообщений из 67, страница 2 из 3
ora01555 - SNAPSHOT TOO OLD
    #32183976
Simon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а мне кажется что никаких проблем не будет
если на диске много места
и админ правильно настроит ролбэк сегменты
...
Рейтинг: 0 / 0
ora01555 - SNAPSHOT TOO OLD
    #32183977
cdk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хочу прояснить еще больше, на примере.
for ... in (select ... from одна_большая_таблица where ... group by ...) loop -- здесь данные статичны однозначно, другими сессиями не меняются)

-- далее группа операторов, в некоторых таблицах данные могут меняться другими сессиями
select ... from ...
...
end loop;
commit;
Допустим, цикл работает 2 часа. Через 2 часа другая сессия меняет данные в таблицах, использующихся в теле цикла и сразу фиксирует изменения. При этом цикл еще не доходит до измененных блоков. А вот когда доходит, то происходит... что?
Что-то я тут недопонимаю. Там, в другой сессии все пофиксено и записано на диск, сегменты отката сто раз перезаписаны. А селект в теле, который дошел наконец-то до тех измененных записей, он разве не читает данные из буферного кэша (который, в свою очередь, с диска)? Зачем ему лазить в сегменты отката? Ведь данные в той сессии пофиксены,а уровень изоляции read commited допускает неповторяемость при чтении...
...
Рейтинг: 0 / 0
ora01555 - SNAPSHOT TOO OLD
    #32183984
cdk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Simon
да решение проблемы в принципе понятно
место есть навалом и роллбаки я увеличу
суть хочется понять до конца
...
Рейтинг: 0 / 0
ora01555 - SNAPSHOT TOO OLD
    #32184001
Фотография softy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
to cdk:

Чего ты мучаешься? В документации чётко приписано почему это происходит и что делать :
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
This error can occur when the transaction that made the
change has already committed and:
• The transaction slot in the rollback header has been reused
• The before-image in the rollback segment has been overwritten by another
transaction
Solution
Read-consistency errors can be minimized by ensuring that rollback segments are
created with:
• A higher MINEXTENTS value
• Larger extent sizes
• A higher OPTIMAL value
Note that these errors cannot be avoided by increasing MAXEXTENTS.
...
Рейтинг: 0 / 0
ora01555 - SNAPSHOT TOO OLD
    #32184009
Simon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
все просто

если у тебя есть транзакция работающая два часа
то все ее измененые данные записываются в ролбэк сегмент,
если другая транзакция пытается к ним обратится, то она, например, при выполнении селекта доходит до измененной строки, убеждается что она (транзакция) началась позже чем транзакция, которая изменила эту строку и которая еще работает, после этого лезет в ролбэк сегмент за нужными тебе данными, если на этот момент из-за нехватки места в ролбэк сегментах эти данные уже перезаписанны, то вылазит ошибка ora01555


самое главное правило:
commit надо делать только тогда, когда это надо по логике, а не тогда когда заканчиваются ролбэк сегменты, так как проблема в них
...
Рейтинг: 0 / 0
ora01555 - SNAPSHOT TOO OLD
    #32184020
Simon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
в оракле два уровня изоляции read commited и serializable

в первом случае согласованность по чтению на момент начала выполнения оператора, во втором транзакции

в первом случае это значит что при выполнении оператора для него все данные бд остаются такими которыми они были в момент начала его выполнения, т.е

есть 1 селект на два часа, параллельно делается 100 инсертов с коммитами
он вставленные данные никогда не увидит, и для доступа к тем данным которые ему нужны полезет в ролбэк сегмент
...
Рейтинг: 0 / 0
ora01555 - SNAPSHOT TOO OLD
    #32184030
Violina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Зачем ему лазить в сегменты отката? Ведь данные в той сессии пофиксены,а уровень изоляции read commited допускает неповторяемость при чтении

Запросы насколько я знаю не выполняютя в режиме read committed, они всегда консистентны на время начало их выполнения, поэтому и лезут в сегменты отката, чтобы получить состояние изменненных данных на то время.
...
Рейтинг: 0 / 0
ora01555 - SNAPSHOT TOO OLD
    #32184044
Фотография softy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
"Запросы насколько я знаю не выполняютя в режиме read committed"

Эх Violina, Violina..........
...
Рейтинг: 0 / 0
ora01555 - SNAPSHOT TOO OLD
    #32184062
Violina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
to softbuilder

А что не так? Работающий запрос ведь не читает данные даже если они были закоммичены во время его выполнения.

Если не так выразилась так уж извини, я просто в унисон вопросу ответила

Ведь данные в той сессии пофиксены,а уровень изоляции read commited допускает неповторяемость при чтении

В вопросе cdk как раз и предположил что запрос работает в режиме read commited.
...
Рейтинг: 0 / 0
ora01555 - SNAPSHOT TOO OLD
    #32184089
cdk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
что-то запутали совсем меня... может объясняю проблему не так...
сессия 1 - тот самый 15-часовой процесс
сессия 2 - очень быстрая _закомиченная_ транзакция, запущенная уже после запуска 1-ой сессии, менящая блоки, которые понадобятся в будущем для с.1
в сессии 1 цикл потихоньку подходит к тому моменту, где менялись блоки в сессии 2
вопрос такой: откуда будут операторы select читать эти данные, если они уже давно зафиксированы раннее сессией 2?
...
Рейтинг: 0 / 0
ora01555 - SNAPSHOT TOO OLD
    #32184093
Фотография softy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
to Violina:\r
\r
В Oracle чтение данных всегда происходит непротиворечивое, то есть консистентное, то есть как правило read commited. \r
\r
Есть только два варианта: read commited и serializable и оба они консистентны и непротиворечивы. Serializable отличается только тем, что если изменения тех данных которые входят в активной набор текущей транзакции изменились другой транзакцией - такое чтение вываливается с ошибкой. А в случае read commited не вываливается, просто они не замечаются, даже если они той другой транзакцией закомитились. И первая транзакция не будет обращаться к сегментам отката, если данные были изменены после начала первой транзакции, так как активный набор определяется на начало транзакции.\r
\r
\r
Можешь здесь почитать\r
/topic/29583\r
\r
И читай книгу Т. Кайта, там про это написано.
...
Рейтинг: 0 / 0
ora01555 - SNAPSHOT TOO OLD
    #32184122
Simon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2cdk

из ролбэков

т.к. тому запросу который был запущен два года назад нужны данные которые были актуальными на момент его запуска (оракл это так сделал)
а они есть только в ролбэках
...
Рейтинг: 0 / 0
ora01555 - SNAPSHOT TOO OLD
    #32184123
Violina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Про транзакции мне все ясно, я долгое время экспериментировала в уровнями изоляции, я подраумевала случай выполение одиночного долгоработающего запроса, в ходе выполения которго были закомичены данные в другом сеансе, нужные этому запросу. Именно так и ставит вопрос cdk

А селект в теле, который дошел наконец-то до тех измененных записей, он разве не читает данные из буферного кэша (который, в свою очередь, с диска)? Зачем ему лазить в сегменты отката? Ведь данные в той сессии пофиксены,а уровень изоляции read commited допускает неповторяемость при чтении...
...
Рейтинг: 0 / 0
ora01555 - SNAPSHOT TOO OLD
    #32184175
cdk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Violina
почти так, но не одному долгоиграющему запросу, а запросам очередной итерации цикла (которые в совокупности не так долго выполняются для одной итерации) и где выполняются разнородные селекты

Если данные берутся из роллбака (скорее всего так и есть), то возникновение 1555 понятно. Но по идее уровень read commited может допускать чтение измененных данных...
...
Рейтинг: 0 / 0
ora01555 - SNAPSHOT TOO OLD
    #32184191
Violina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
to cdk

в сессии 1 цикл потихоньку подходит к тому моменту, где менялись блоки в сессии 2
вопрос такой: откуда будут операторы select читать эти данные, если они уже давно зафиксированы раннее сессией 2?


Если уровень изоляции транзакции в сессии 1 read comitted и изменения в сессии 2 закомичены к моменту начала select в сессии 1 то будут читаться закомиченые данные.

Если уровень изоляции serializable или транзакция в read only, то запрос будет пытаться извлечь данные на момент начала транзакции. Для этого ему могут понадобится данные из сегментов отката. Если они были перезаписаны, вывалится ora-01555.
...
Рейтинг: 0 / 0
ora01555 - SNAPSHOT TOO OLD
    #32184364
cdk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Violina
Если уровень изоляции транзакции в сессии 1 read comitted и изменения в сессии 2 закомичены к моменту начала select в сессии 1 то будут читаться закомиченые данные.
Я тоже пришел к тому же выводу. А на основании этого можно сделать еще вывод, что запрос(ы) в какой-то (или в каких-то) итерации(ях) выполняется довольно долго, что позволяет возникнуть ora-1555... Больше искать причину негде?
...
Рейтинг: 0 / 0
ora01555 - SNAPSHOT TOO OLD
    #32184369
Фотография softy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
"Больше искать причину негде?"

to cdk:

Думаю, что внутри запроса, который 15 часов длится.
...
Рейтинг: 0 / 0
ora01555 - SNAPSHOT TOO OLD
    #32184386
cdk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 softbuilder
один запрос не длится 15 часов!
весь процесс (а точнее цикл) выполняется 15 часов, в котором довольно тяжелые вычисления для каждой итерации
...
Рейтинг: 0 / 0
ora01555 - SNAPSHOT TOO OLD
    #32184395
Фотография softy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Значит нужно найти принципиально другое решение этой задачи, без циклов(которыми некоторые после перехода в частности с FoxPro на Oracle по привычке любят увлекаться, несмотря на то что SQL был еще в FoxPro 2.0 с 1991г) .
...
Рейтинг: 0 / 0
ora01555 - SNAPSHOT TOO OLD
    #32184399
Фотография softy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Попробуй изложить свою исходную задачу, может народ подскажет другие пути решения.
...
Рейтинг: 0 / 0
ora01555 - SNAPSHOT TOO OLD
    #32184400
Фотография SY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 cdk:

> Допустим, цикл работает 2 часа. Через 2 часа другая сессия меняет данные в таблицах, использующихся в теле цикла и
> сразу фиксирует изменения. При этом цикл еще не доходит до измененных блоков. А вот когда доходит, то происходит... что?
> Что-то я тут недопонимаю. Там, в другой сессии все пофиксено и записано на диск, сегменты отката сто раз перезаписаны.
> А селект в теле, который дошел наконец-то до тех измененных записей, он разве не читает данные из буферного кэша
> (который, в свою очередь, с диска)? Зачем ему лазить в сегменты отката? Ведь данные в той сессии пофиксены,
> а уровень изоляции read commited допускает неповторяемость при чтении...


What cache???

Oracle does not prefetch data. Therefore there is no cache for select results.
And therefore Oracle needs to get read consistent data from a rollback segment used by transaction which modified the data. And in fact, it could be the other transaction did not modify the row you transaction needs. It is enough if it modified any row in the same data block.

That is why long running transactions should be elevated to DESIGN and maybe even to ARCHITECHTURE level.

SY.
...
Рейтинг: 0 / 0
ora01555 - SNAPSHOT TOO OLD
    #32184437
cdk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 SY
понятно. ошибся я насчет кэша.
но все равно написанное тобой не противоречит выводу Если уровень изоляции транзакции в сессии 1 read comitted и изменения в сессии 2 закомичены к моменту начала select в сессии 1 то будут читаться закомиченые данные.
т.е. в такой ситуации ora-1555 не возникнет

2 softbuilder
Задача ясна, давно решена и в общем-то результаты выполнения хороши. А суть ее обычная - формирование начислений за телефонный трафик за месяц. Полностью переделывать процедуру смысла не имеет, да и сложна она (написана ессно не мной). Но слабые места видимо все же есть...
...
Рейтинг: 0 / 0
ora01555 - SNAPSHOT TOO OLD
    #32184460
Фотография softy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
to cdk:

Неужели используя только SELECT-ы с группированием, использованием аналитических функций(не путать с групповыми) нельзя решить твою задачу?
...
Рейтинг: 0 / 0
ora01555 - SNAPSHOT TOO OLD
    #32184467
Violina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
По поводу

Если уровень изоляции транзакции в сессии 1 read comitted и изменения в сессии 2 закомичены к моменту начала select в сессии 1 то будут читаться закомиченые данные.

Сделала такую проверку, изменив и закоммитив данные в таблице test в другом сеансе во время выполнения цикла.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
SQL> set transaction isolation level read committed;

Transaction set.

SQL> set serverout on
SQL> declare
   2     cnt number;
   3   begin
   4 
   5     for i in  1 .. 10  loop
   6       select count(*) into cnt from vio.test;
   7       dbms_output.put_line(cnt);
   8       DBMS_LOCK.SLEEP( 5 );
   9     end loop;
  10 
  11   end;
  12   /
 0 
 0 
 0 
 2 
 2 
 2 
 2 
 2 
 2 
 2 


То же самое для serializable дает

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
SQL> set transaction isolation level serializable;

Transaction set.

SQL> declare
   2     cnt number;
   3   begin
   4 
   5     for i in  1 .. 10  loop
   6       select count(*) into cnt from vio.test;
   7       dbms_output.put_line(cnt);
   8       DBMS_LOCK.SLEEP( 5 );
   9     end loop;
  10 
  11   end;
  12   /
 0 
 0 
 0 
 0 
 0 
 0 
 0 
 0 
 0 
 0 
...
Рейтинг: 0 / 0
ora01555 - SNAPSHOT TOO OLD
    #32184508
cdk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 softbuilder
тут уже пошли политические тонкости... я не имею права менять исходники в промышленной схеме... лицензированное ПО
могу только смотреть код и указывать на вероятное плохое место
а на тестовой схеме такую ситуацию создать невозможно (по техническим причинам)
...
Рейтинг: 0 / 0
25 сообщений из 67, страница 2 из 3
Форумы / Oracle [игнор отключен] [закрыт для гостей] / ora01555 - SNAPSHOT TOO OLD
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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