|
Восстановление БД при нехватке места в табличном пространстве
|
|||
---|---|---|---|
#18+
Всем привет! Есть на винде БД 11.2.0.2 на которой в один момент закончилось место в пользовательском тэблспейсе и в алертлоге ожидаемо появились ошибки вида ORA-1653. Спустя неделю добавили к тэблспейсу новый датафайл и данные снова начали писаться. Логично, что при этом в данных есть лакуна на период, когда места в тэблспейсе не было. БД бежит в архивлог режиме и архлоги исправно создавались, есть хотбэкап до сбоя без редо логов и контрольников (снимался с помощью alter database begin backup и копированием датафайлов и архлогов в сторонку) и весь поток архлогов до текущего момента. Вопросы: 1) Что находится в этих архлогах? Можно предположить, что в них все нужные транзакции остались? 2) Каким-то образом можно восстановиться из хотбэкапа при этом увеличив размер датафайла или добавить новый датафайл к этому табличному пространству перед RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL, чтобы при накатке на бэкап архлогов он не упирался в ту же нехватку места в табличном пространстве? 3) Иной вариант увидеть данные несброшенные на диск из архлогов (если они там есть, см. п.1)? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.06.2021, 19:58 |
|
Восстановление БД при нехватке места в табличном пространстве
|
|||
---|---|---|---|
#18+
BTM Можно предположить, что в них все нужные транзакции остались? Нет, что не закоммичено то в redo log file не пишется. Во время сбоя все данные, которые Oracle пытался записать в tablespace с дефицитом свободного места, не сохранились, соответственно их нет и в archived redo log files. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.06.2021, 20:49 |
|
Восстановление БД при нехватке места в табличном пространстве
|
|||
---|---|---|---|
#18+
flexgen Нет, что не закоммичено то в redo log file не пишется. Другое дело, что при нехватке свободного места до собственно оператора вставки/изменения как правило дело и не доходит -- все ломается на рекурсивном операторе выделения нового экстента ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2021, 04:16 |
|
Восстановление БД при нехватке места в табличном пространстве
|
|||
---|---|---|---|
#18+
flexgen BTM Можно предположить, что в них все нужные транзакции остались? Нет, что не закоммичено то в redo log file не пишется. Во время сбоя все данные, которые Oracle пытался записать в tablespace с дефицитом свободного места, не сохранились, соответственно их нет и в archived redo log files. Печально, если это действительно так. Вячеслав Любомудров flexgen Нет, что не закоммичено то в redo log file не пишется. Другое дело, что при нехватке свободного места до собственно оператора вставки/изменения как правило дело и не доходит -- все ломается на рекурсивном операторе выделения нового экстента Если нет возможности выделит экстент, то что происходит дальше с данными? Из буферов улетают в пустоту вместо редо логов? Архивлоги то объемненькие и откладываются с той же частотой, что и при штатной работе. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2021, 18:26 |
|
Восстановление БД при нехватке места в табличном пространстве
|
|||
---|---|---|---|
#18+
С каких буферов? В кеше буфера не сами по себе болтаются -- они соответствуют блокам, которые на диске Начинается процесс вставки -- ищется блок, куда можно вставить запись, нет такого -- заряжаем рекурсивную транзакцию на выделение экстента. Если получается -- формируем редо запись из векторов для обновления словаря и отмены, применяем, подтверждаем (сбрасываем в редо-лог) и уже после этого начинаем обновлять блок данных Если нет -- возвращаем ошибку Т.е. до изменения блока данных дело еще не дошло, соответсвенно ни записи повторения, ни отмены не формируются ... |
|||
:
Нравится:
Не нравится:
|
|||
29.06.2021, 02:59 |
|
|
start [/forum/topic.php?fid=52&fpage=16&tid=1880074]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
39ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
2ms |
others: | 13ms |
total: | 146ms |
0 / 0 |