|
|
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
Ну что с этим делать? Я в цикле commit делаю уже 1 раз на 50 вставленных в таблицу записей. Работа скрипта закончится может бы через дня 3 - а как мне тогда контролировать что он там считатет (может я где логическую ошибку допустил). Сто записей итак несколько часов генерятся. Может что-то надо с RBS-ами сделать? Но на RBS tablespace итак 2GB и все свободны, max extents везде unlimeted, сервер ничем не занят кроме этого скрипта ... Подскажите пожалуйста, что я делаю не так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2002, 13:55:42 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
Попробуй создать БОЛЬШОЙ сегмент отката, переведи его в оффлайн. Убрать коммит из цикла и оставить только завершающий коммит. При запуске явно привяжи транзакцию к этому сегменту отката через set rollback segment. Непосредственно перед запуском переводишь сегмент в онлайн. Запускаешь транзакцию (см. выше) и немедленно из другой сессии переводишь сегмент отката в оффлайн. Молишься, чтобы тебе хватило места в табличном пр-ве RBS ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2002, 14:14:00 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
Спасибо, буду пробовать. Но коммит в цикле ну очень хотелось бы иметь ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2002, 14:42:56 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
Тогда не получится привязки к определенному сегменту и весь метод работать не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2002, 15:12:03 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
может действительно логическая ошибка? Интересно было бы на сам скрипт посмотреть. а сколько собственно ролбек сегментов в этом 2Гб тейблспейсе? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2002, 15:31:37 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
и не выставлен ли параметр OPTIMAL? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2002, 15:34:42 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
Для устранения проблемы SNAPSHOT TOO OLD надо понимать, что его причина: ВРЕМЯ ЖИЗНИ сегмента отката но НЕ РАЗМЕР. т.е КОЛИЧЕСТВО других транзакций больше, чем могут принять ВСЕ экстенты ВСЕХ RBS. Устранение: - увеличение количества RBS - увеличения количества экстентов RBS По поводу OPTIMAL в данной ситуации он не работает (почти) поскольку это параметр RBS который действует ПОСЛЕ транзакции но не ВО ВРЕМЯ ТРАНЗАКЦИИ О размере RBS его нужно расчитывать исходя из : INESRT/DELETE - исходя из однократного размера всех записей UPDATE - исходя из двухкратного размера всех записей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2002, 17:01:44 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
>Для устранения проблемы SNAPSHOT TOO OLD надо >понимать, что его причина: >ВРЕМЯ ЖИЗНИ сегмента отката но НЕ РАЗМЕР. >т.е КОЛИЧЕСТВО других транзакций больше, чем могут >принять ВСЕ экстенты ВСЕХ RBS. Если б это было так, то выдавалась бы не ошибка 1555, а конкуренция за ундо блоки. Там у него вообще только одна транзакция. Поэтому рекомендация увеличить колличество сегментов абсолютно не поможет, а наоборот. >По поводу OPTIMAL в данной ситуации он не работает >(почти) >поскольку это параметр RBS который действует ПОСЛЕ >транзакции но не ВО ВРЕМЯ ТРАНЗАКЦИИ OPTIMAL влияет на то будет ли сокращаться роллбек сегмент по окончанию транзакции. А если он сократиться, то значит будет перезаписан. Т.е. исторические данные потеряются, что и может быть причиной ora 1555. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2002, 17:29:55 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
ORA-01555 snapshot too old: rollback segment number string with name "string" too small Cause: Rollback records needed by a reader for consistent read are overwritten by other writers. If in system only 1 transaction where we can get "other writers" ---------------------------------------------------------------------------------- About mait question: U can use TRANSACTION SPECIFIC GLOBAL TEMPORARY TABLE, timelife data in that table 1 trancaction, Oracle don't create RBS of this kind of table never. After genetate your rows into GTT u can use : insert into YOUR_MAIN_TABLE select * from GTT; commit; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2002, 18:05:08 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
теперь вопрос смещается в плоскость "а хватит ли места в TEMP ? :-)) 2softbuilder: у тебя хватит? ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2002, 18:14:48 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
>ORA-01555 snapshot too old: rollback segment number >string with name "string" too small >Cause: Rollback records needed by a reader for consistent >read are overwritten by other writers противоречия никакого нет - да в каждый момент времени - только одна транзакция. Но ей нужны данные, которые уже перезаписаны. Решение с temporary таблицами не подойдет, т.к. ему надо делать выборка->апдейт->коммит в цикле. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2002, 18:21:13 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
I tested size of temp tablespace for gtt, it not big. This is my post about GTT and temporary TS Tarry, Ly ALTER ... = commit in any situation --------------------------------------------------------------------------------------------------------------------- Try to discover situation with temporary tables : I opened 2 session: 1) with system account (system user) 2) with train account (training user) then in train session i did: -- alter sort area size (made it smaller) -- got summary USA and PGA for train user (from system session) and -- got sotrt segments for this session (train user) SQL> alter session set sort_area_size=32000; Session altered. (IN system session ) --------------------------------------------------------------------------------------------------------------------------------- O/S PGA PGA UGA UGA User User User Oracle Login Memory MaxMemory Memory MaxMemory MaxMemory Sid Spid PROCESS User ID ID TERM STAT KB KB KB KB KB ----- ----- ---------- ------------ -------- -------------------- -------- ---------- ---------- ---------- ---------- ---------- .. 6497 *? ? ? ACTIVE 74.797 74.797 19.113 19.113 93.910 13 14267 *8673 TRAIN sgene pts/4 INACTIVE 108.047 108.047 44.305 44.305 152.352 .. 6511 *? ? ? ACTIVE 74.797 74.797 19.113 19.113 93.910 (IN Train session) SQL> select USER, TABLESPACE, SEGTYPE, sum(BLOCKS) from v$sort_usage where USER='TRAIN' group by USER, TABLESPACE, SEGTYPE, session_num ; no rows selected default temporary ts for user train -> TEMP then I created global temporary table in train session: create global temporary table temp_train as select * from all_objects where rownum <= 10; --------------------------------------------------------------------------------------------------------------------------------- O/S PGA PGA UGA UGA User User User Oracle Login Memory MaxMemory Memory MaxMemory MaxMemory Sid Spid PROCESS User ID ID TERM STAT KB KB KB KB KB ----- ----- ---------- ------------ -------- -------------------- -------- ---------- ---------- ---------- ---------- ---------- 13 14267 *8673 TRAIN sgene pts/4 INACTIVE 684.762 684.762 63.922 63.922 748.684 30 6499 *? ? ? ACTIVE 74.797 74.797 19.113 19.113 93.910 14 rows selected. Oracle increased PGA from 74.797 up to 684.762 bytes WITHOUT SORTS IN THIS SESSION SQL> commit; Commit complete. SQL> select count(*) from temp_train; COUNT(*) ---------- 0 SQL> insert into temp_train select * from all_objects where rownum <=5000 order by object_id; 2000 rows created. select USER, TABLESPACE, SEGTYPE, sum(BLOCKS) from v$sort_usage where USER='TRAIN' group by USER, TABLESPACE, SEGTYPE, session_num ; USER TABLESPACE SEGTYPE SUM(BLOCKS) ------------------------------ ------------------------------- --------- ----------- TRAIN TEMP DATA 50 SQL> commit; Commit complete. select USER, TABLESPACE, SEGTYPE, sum(BLOCKS) from v$sort_usage where USER='TRAIN' group by USER, TABLESPACE, SEGTYPE, session_num ; no rows selected After any kind of commit statment (we remember ALTER..=COMMIT oracle deallocate all temporary segments from temp ts for this session. Then I increased sort area size for sessin: SQL> alter session set sort_area_size=4000000; Session altered. SQL> select count(*) from temp_train; COUNT(*) ---------- 0 insert into temp_train select * from all_objects where rownum <=2000; 2000 rows created. SQL> select count(*) from temp_train; COUNT(*) ---------- 2000 SQL> select USER, TABLESPACE, SEGTYPE, sum(BLOCKS) from v$sort_usage where USER='TRAIN' group by USER, TABLESPACE, SEGTYPE, session_num ; no rows selected SQL> insert into temp_train select * from all_objects where rownum <=2000; 2000 rows created. SQL> select count(*) from temp_train; COUNT(*) ---------- 4000 SQL> select USER, TABLESPACE, SEGTYPE, sum(BLOCKS) from v$sort_usage where USER='TRAIN' group by USER, TABLESPACE, SEGTYPE, session_num ; USER TABLESPACE SEGTYPE SUM(BLOCKS) ------------------------------ ------------------------------- --------- ----------- TRAIN TEMP DATA 100 OK!!! oracle use temporary ts ONLY it couldn't allocate enogth memory. But still question --> Which memory oracle used? O/S PGA PGA UGA UGA User User User Oracle Login Memory MaxMemory Memory MaxMemory MaxMemory Sid Spid PROCESS User ID ID TERM STAT KB KB KB KB KB ----- ----- ---------- ------------ -------- -------------------- -------- ---------- ---------- ---------- ---------- ---------- 7 6497 *? ? ? ACTIVE 74.797 74.797 19.113 19.113 93.910 13 14267 *8673 TRAIN sgene pts/4 INACTIVE 684.762 684.762 47.480 64.027 748.789 14 6511 *? ? ? ACTIVE 74.797 74.797 19.113 19.113 93.910 PGA and UGA size still the same! SQL> commit; Commit complete. SQL> select count(*) from temp_train; COUNT(*) ---------- 0 SQL> insert into temp_train select * from all_objects where rownum <=5000 order by object_id; 4361 rows created. User User Oracle Login Memory MaxMemory Memory MaxMemory MaxMemory Sid Spid PROCESS User ID ID TERM STAT KB KB KB KB KB ----- ----- ---------- ------------ -------- -------------------- -------- ---------- ---------- ---------- ---------- ---------- 10 6503 *? ? ? ACTIVE 74.797 74.797 19.113 19.113 93.910 13 14267 *8673 TRAIN sgene pts/4 INACTIVE 1236.723 1236.723 47.480 64.027 1300.750 14 6511 *? ? ? ACTIVE 74.797 74.797 19.113 19.113 93.910 SQL> insert into temp_train select * from all_objects where rownum <=5000 order by object_id; 4361 rows created. SQL> select count(*) from temp_train; COUNT(*) ---------- 8722 I used sort (order by) in two selects Conclusion 1 --> oracle use temp segments for temporty tables and probably for sort. I espesially used 2 statments because: -- it has to increase size of temporary table -- it hasn't use a lot of sort_area Results: User User Oracle Login Memory MaxMemory Memory MaxMemory MaxMemory Sid Spid PROCESS User ID ID TERM STAT KB KB KB KB KB ----- ----- ---------- ------------ -------- -------------------- -------- ---------- ---------- ---------- ---------- ---------- 10 6503 *? ? ? ACTIVE 74.797 74.797 19.113 19.113 93.910 13 14267 *8673 TRAIN sgene pts/4 INACTIVE 1236.723 1236.723 47.480 64.027 1300.750 14 6511 *? ? ? ACTIVE 74.797 74.797 19.113 19.113 93.910 USER SESSION_NUM TABLESPACE SEGTYPE SUM(BLOCKS) ------------------------------ ----------- ------------------------------- --------- ----------- TRAIN 39424 TEMP DATA 225 Oracle used temp tablespase probably for temporary table only and sort area for sort operation only. Because afrer second insert with order by PGA/UGA didn't insrease. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2002, 18:27:09 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
> Решение с temporary таблицами не подойдет, т.к. ему надо делать выборка->апдейт->коммит в цикле. Who says that we can't write pieses of data from GTT, after data will write into main table we don't need keep rows in GTT. We may reuse this table again "in scratch" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2002, 18:56:51 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
Don't you think that I'll get the same problem after inserting -> commiting data from gtt into main table? Все таки с местом для RBS-ов проблемы нет - тоад показывает что оно почти не используется (во время работы скрипта естественно). Экстенты во всех RBS unlimited. RBS-ов 3 штуки. Таблицы из которых делается выборка по 100GB, SGA в сумме 1GB. Таблицы правильно индексированы. Что-то ORA делает странное ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2002, 10:23:03 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
я воспользуюсь этой веткой, если не против... в принципе ситуация ora-01555 довольно ясно, когда дело касается одного сегмента отката... но у меня такая проблема: имеется: 4 малых сегмента отката (размер экстента=5 мб, minextents=5); 1 очень большой (экстент=100мб, minextetnts=6); 1 поменьше (экстент=50 мб, minextents=4); процесс, работающий около 15-20 часов, там цикл по огромной таблице в 10 млн. записей с одним коммитом в конце, но! использующий жесткую привязку (set transaction use ... ) к огромному сегменту отката (который на 600 мб); и, наконец, ошибку ora-01555, вылезающую произвольно (может на 20-30% процесса, а может на 70-80%) при запуске процесса выше. Но самое странное, что в этой ошибке указывается rollback segment number ... with name имя_малого_сегмента!!! too small. Т.е. используется малый сегмент. Вопрос: почему??? (если отключить все малые сегменты, то все ок). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2003, 10:21:51 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
у меня возникала данная ошибка вовсе не изза rbs. Выше было сказано, что используется select, update. т.е. открывается курсор и на основе него делается update. Была конкретная ситуация: открываем курсор с id абонента и для каждого запускаем расчёт абонентской платы. Для каждого абонента делается commit. Пока был расчёт с пробежкой по курсору была данная ошибка. как только стал id считывать в массив, а потом уже бегать по нему, то проблема ушла. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2003, 10:56:11 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
1. Сделать сегменты отката изначально достаточно большими. 2. Выполнить следуюющее: - создать сегменты отката (или изменить существующие) так, чтобы они могли достаточно авторасширяться (это вроде уже имеем); - заблокировать каждый сегмент отката короткой транзакцией: set transaction use rollback segment ... (столько сеансов сколько RBS); - запустить скрипт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2003, 11:37:06 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
Опытные знатоки-оракловоды! Я же именно спрашивал "почему?", а не "как лечить?". Отключения 4-х малых меня пока вполне устраивает. Но гложет вопрос, почему так происходит, зачем процесс лезет в другие сегменты и что он там изменяет, если уже задана ему жесткая привязка к большому сегменту. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2003, 14:05:09 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
2 cdk: > процесс, работающий около 15-20 часов, там цикл по огромной таблице в 10 > млн. записей с одним коммитом в конце, но! использующий жесткую > привязку (set transaction use ... ) к огромному сегменту отката (который на > 600 мб); >и, наконец, ошибку ora-01555, вылезающую произвольно (может на 20-30% > процесса, а может на 70-80%) при запуске процесса выше. >Но самое странное, что в этой ошибке указывается rollback segment > number ... with name имя_малого_сегмента!!! too small. Т.е. используется > малый сегмент. Вопрос: почему??? (если отключить все малые сегменты, то > все ок). This is a classic situation of MISunderstanding ora-01555. Many people concentrate on their transaction only without realizing some other session can be the reason of them getting ora-01555. In your example, you start process which runs for 15 hours. Since Oracle maintains read consistensy, it needs to be able to reconstruct table(s) contents as it was at the time SELECT was issued. Assume some other session modifies table(s) used in your select. And it modifies row(s) your transaction did not fetch yet. N hours later your transaction tries to fetch the row. It realizes that row changed since SELECT was issued and it needs to get read-consistent data from a rollback segment of TRANSATION THAT MODIFIED THAT ROW. So now you at mercy of SOMEONE ELSE's TRANSACTION. If that transaction committed and rollback segment was reused - you are out of luck and even 6000 MB of rollback space will not help you. And since your process runs 15 hours, chance of someone else updating the table(s) is pretty high. SY ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2003, 17:06:27 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
Сенкс. Тогда правильно ли я понял, что происходит: Цикл идет по большой таблице через селект. Но. Данные в этой таблице статичны, не изменяются (тел. трафик). (Таблица, кстати, партиционная, в ней гораздо больше данных; 10 млн. тока в одной партиции, но эта партиция, повторяю, статична.). Но в самом цикле есть куча селектов из прочих таблиц, для которых изменения в их данных в процессе работы этого цикла допустимы. Коммит, как я уже говорил, только после цикла. Правильно ли я понял, что селект(ы) внутри цикла запрашивают данные на момент _начала_ транзакции? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2003, 09:50:20 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
если при выполнении долгих селектов появляется ora01555 то надо сделать все сегменты отката доволно большими и желательно одинаковыми (если так не сделать, то ошибка будет с самым маленьким сегментом отката) при выполнении запросов autoextend сегментов отката не происходит (т.е он происходит только при выполнении Insert update и delete) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2003, 10:27:20 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
2 cdk Нет. Селект запрашивает данные на момент выполнения. - началась твоя длинная транзакция, всё то, что она изменяет, предварительно пишется в RBS (например BIG_RBS); - в ней же имеются селекты - оракл обеспечивает целостность чтения для этих селектов (на уровне команд) за счет (возможно) обращения к RBS (в том случае, если данные были изменены другими транзакциями (например, берет из RBSn)); - вот когда эти другие транзакции зафиксены, те данные в RBSn (рано или поздно) будут переписаны ораклом для других транзакций и те самые селекты тогда получат ошибку snapshot too old; - твоя длинная транзакция зафиксена - соответственно то, что она изменяла, может быть переписано в BIG_RBS, т.е. никакого отношения к тем селектам это не имеет; Я уже писал как этого можно избежать (см. выше). Чтобы обеспечить целостность чтения для транзакции можно, например использовать транзакции только на чтение, но тогда ничего изменять не сможешь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2003, 10:38:04 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
2 Simon Чтобы "сделать все сегменты отката доволно большими" надо "довольно точно" :) знать длительность операции и транзакционную активность во время ее выполнения - задача на любителя :) (практически, это невыполнимо) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2003, 10:44:26 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
2Angel а что такое транзакция для чтения??? я знаю два уровня изоляции SERIALIZABLE и READ COMMITED другие оракл не поддерживает отличаются тем, что в serializable оракл чтение согласовано на момент начала транзакции (сессии) а не на момент выполнения оператора ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2003, 11:06:14 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
2 Simon можно, конечно, и сериализацию использовать, но это уже вопрос дизайна - а, как мне кажется, если уж вылезает snapshot too old, то обеспечить сериализацию будет тоже проблематично (я бы не побоялся сказать, что невозможно - скрипт то на 3 дня :)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2003, 11:16:10 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=32183904&tid=1989952]: |
0ms |
get settings: |
7ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
193ms |
get topic data: |
6ms |
get forum data: |
13ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 233ms |
| total: | 513ms |

| 0 / 0 |
