|
ORA-01548: active rollback segment
|
|||
---|---|---|---|
#18+
Добрый день! Во время операции импорта (IMP_DP) переполнился сегмент отката, процесс завис намертво, прерывать пришлось аварийно. UNDO так и остался заполненным в статусе ACTIVE вся память табличного пространства. Создал новый сегмент, переключился на него: Код: plsql 1. 2. 3.
Последняя операция не прошла, выяснилось, что появился некий сегмент со статусом PARTLY AVAILABLE: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
Нашел руководство по которому дошел до пункта Код: plaintext
Код: plsql 1. 2. 3.
Теперь имеется следующее: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
Таблица, в которую производился импорт реагирует следующим образом: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Подскажите, как исправить ситуацию? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2014, 19:16 |
|
ORA-01548: active rollback segment
|
|||
---|---|---|---|
#18+
Добавлю: Код: plsql 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2014, 19:33 |
|
ORA-01548: active rollback segment
|
|||
---|---|---|---|
#18+
Ceib, А просто дать транзакциям завершиться не пробовал? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2014, 19:55 |
|
ORA-01548: active rollback segment
|
|||
---|---|---|---|
#18+
-2-Ceib, А просто дать транзакциям завершиться не пробовал? Во время выполнения импорта (после переполнения UNDO) все зависло, никакой активности не наблюдалось. После прерывания процесса подождал несколько часов (при том, что импорт на момент остановки не продолжался и часа) - откат не произошел, пришлось переходить к экстренным мерам, тем более что накануне на другой табличке в аналогичной ситуации аналогичное прерывание процесса с пересозданием табличного пространства прошло без проблем. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2014, 20:21 |
|
ORA-01548: active rollback segment
|
|||
---|---|---|---|
#18+
Ceib, отложенный rollback (deferred rollback) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2014, 03:54 |
|
ORA-01548: active rollback segment
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2014, 03:57 |
|
ORA-01548: active rollback segment
|
|||
---|---|---|---|
#18+
SMON че кажет в логах ? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2014, 04:11 |
|
ORA-01548: active rollback segment
|
|||
---|---|---|---|
#18+
Да че кажет -- срет он там кирпичами, что не может прочитать файл старого пространства отката, который наш герой нашел способ удалить (ведь предупреждала его команда DROP TABLESPACE, но нет, он нашел лом) А аффтару, похоже, придется все начинать сначала (с создания чистой БД) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2014, 04:16 |
|
ORA-01548: active rollback segment
|
|||
---|---|---|---|
#18+
Код: plaintext
Файл восстановился, пошел процесс отката. Сижу, жду, надеюсь на лучшее. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2014, 10:00 |
|
ORA-01548: active rollback segment
|
|||
---|---|---|---|
#18+
drop tablespace UNDOTBS2....drop rollback segment.... круто... что сказать :) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2014, 12:46 |
|
ORA-01548: active rollback segment
|
|||
---|---|---|---|
#18+
Доброго времени суток. А если drop tablespace UNDOTBS2 including contents and datafiles; прошел сразу, но файл остался, почему это могло произойти и что с этим делать? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.08.2021, 16:56 |
|
ORA-01548: active rollback segment
|
|||
---|---|---|---|
#18+
Ondayl ... и что с этим делать? Базу перезагрузить (когда сможете). У Вас ведь Unix*, правда? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.08.2021, 17:35 |
|
ORA-01548: active rollback segment
|
|||
---|---|---|---|
#18+
Ondayl, lsof |grep <имя файла> если никто не держит, просто удалить руками ... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2021, 06:40 |
|
ORA-01548: active rollback segment
|
|||
---|---|---|---|
#18+
Я понял ... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2021, 22:52 |
|
ORA-01548: active rollback segment
|
|||
---|---|---|---|
#18+
landy если никто не держит, просто удалить руками Я на это и намекал - была же старая история, что то ли на Linux'е, то ли на Solaris'е (то ли и там и там) нельзя было удалить файл, который "держит" какой-то из процессов Oracle. И помогал только рестарт базы (или ASM), причём это все смешно до тех пор пока ситуация не упиралась в нехватку места. Удаляешь Tablespace, файлы на месте. Удаляешь файлы из ОС - команда (rm) отрабатывает без ошибки, но файл на месте (и места свободного не становится больше). Были вроде и баги зарегистрированы на MOS по этой теме, и может даже патчи соответствующие. Правда, был трюк - не удалять датафайл, а уменьшить его размер, если файл внутри пустой (но это нужно было заранее догадаться, что будут такие проблемы, и сразу же идти по пути уменьшения файлов, а не удаления. Хотя я тут подумал - возможно прокатил бы вариант, если TBS удалён, но файл остался - попытаться снова добавить его к базе через ALTER TABLESPACE ADD DATAFILE <file> REUSE - может быть получилось бы). Доходило до смешного - можно было "студентов пугать" - удалить всю базу, все файлы данных базы (rm -rf *.dbf) - но база продолжала работать как ни в чем не бывало. И можно было (если файлы базы удалили по ошибке), скрестив пальцы, чтобы база не включилась, быстренько базу забекапить, и тем самым ее не потерять. И потом уже reboot - и все, файлы таки пропадали, и место появлялось. Но это я уже отвлёкся. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2021, 13:22 |
|
|
Start [/forum/topic.php?fid=52&tid=1879979&gotonew=1]: |
0ms |
get settings: |
0ms |
get forum list: |
7ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
26ms |
get topic data: |
4ms |
get first new msg: |
1ms |
get forum data: |
1ms |
get page messages: |
20ms |
update_topic_read_status (1879979): 13.08.2021 13:22:59: |
0ms |
get tp. blocked users: |
1ms |
get online users: |
20ms |
check new: |
1ms |
others: | 74ms |
total: | 157ms |
0 / 0 |