|
rman бэкап - уменьшился объем бэкапа
|
||
|---|---|---|
Участник
Откуда: Frankfurt am Main
Сообщения: 382 |
||
| 17.02.2022, 14:44 |
|
|
|
|
|
rman бэкап - уменьшился объем бэкапа
|
|||
|---|---|---|---|
|
#18+
Здравствуйте, кто-нибудь может объяснить произошедшее: резко и без видимых причин уменьшился размер полного бэкапа оракловой базы. Оно, конечно, приятно, но подозрительно: - скрипты бэкапа никто не трогал, они как работали на автомате, так и работают; - никаких ошибок или предупреждений в логах или в выводе rman нет, все отрабатывает идеально; - схема бэкапа тоже не изменилась, все файлы базы в нее входят и в логах появляются; - глобальных изменений в базу тоже не вносилось, единственное - недавно добавлялся файл в пространство undo, но это все. Но между тем на дисках бэкап теперь занимает не 650 гиг, как раньше, а только 400. И еще - раньше это был один крупный save set, теперь - несколько десятков более мелких по несколько гиг или десятков гиг каждый. И вот их общий объем как раз 400 гиг всего. Главный вопрос - можно ли полагаться на эти бэкап теперь? Ну и если нет - то есть какие-нибудь предположения "что делать"? Я лично вообще не пойму, что произошло и в какую сторону нужно смотреть. Заранее спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2022, 15:31 |
|
||
|
rman бэкап - уменьшился объем бэкапа
|
|||
|---|---|---|---|
|
#18+
Sergey_AVГлавный вопрос - можно ли полагаться на эти бэкап теперь? ....делятся на 3 категории: те кто еще не делает бэкапы, те, кто уже делает бэкапы, и тех, кто уже делает и проверяет возможность восстановления Вы уверены что делаете бэкап ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2022, 16:26 |
|
||
|
rman бэкап - уменьшился объем бэкапа
|
|||
|---|---|---|---|
|
#18+
Код: plsql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2022, 16:29 |
|
||
|
rman бэкап - уменьшился объем бэкапа
|
|||
|---|---|---|---|
|
#18+
Sergey_AV, Если не хотите/не можете провести полное тестовое восстановление из подозрительной резервной копии, то выполните хотя бы RESTORE ... VALIDATE . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2022, 16:34 |
|
||
|
rman бэкап - уменьшился объем бэкапа
|
|||
|---|---|---|---|
|
#18+
Sergey_AV, > И еще - раньше это был один крупный save set, теперь - несколько десятков более мелких по несколько гиг или десятков гиг каждый. И вот их общий объем как раз 400 гиг всего. Народная мудростьЧудес не бывает... Размер мог уменьшиться за счет оптимизации операций/отключение некоторых задач (уменьшилось количество archivelog), но вот произвольное изменение количества backupset само по себе случится вряд ли. Даже если не меняли скрипт, могли поменять настройки rman по умолчанию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2022, 18:57 |
|
||
|
rman бэкап - уменьшился объем бэкапа
|
|||
|---|---|---|---|
|
#18+
Asmodeus Sergey_AV, Если не хотите/не можете провести полное тестовое восстановление из подозрительной резервной копии, то выполните хотя бы RESTORE ... VALIDATE . Или ещё как вариант RESTORE... PREVIEW . Vadim Lejnin Размер мог уменьшиться за счет оптимизации операций/отключение некоторых задач (уменьшилось количество archivelog), но вот произвольное изменение количества backupset само по себе случится вряд ли. Даже если не меняли скрипт, могли поменять настройки rman по умолчанию. Вообще, уменьшение размера бекапа с 650 ГБ до 400 ГБ выглядит как переход с простого бекапа на COMPRESSION BACKUPSET, а "вместо одного большого файла теперь несколько десятков небольших файлов" выглядит как включение опции MAXPIECESIZE. Хоть по описанию ситуации, скрипты / команды бекапа вроде бы как не менялись. Но мы то знаем что "чудес не бывает". Так что надо искать, что поменялось в командах RMAN. Вот тут в соседнем топике Восстановление БД Oracle на новом сервере из бэкапа. RMAN-06025: no backup of archived log я предлагал почитать документ "10 проблем с Вашим RMAN скриптом" - в текущей ситуации, если бы был использован Совет #1, то был бы включён ECHO ON , и у Вас в логах было бы чётко видно, какая команда выполнялась когда бекап был 650 ГБ, и какая команда выполнялась когда бекап стал 450 ГБ. Возможно не пришлось бы гадать. И ещё одна идея - вчера (по отношению ко дню создания этого топика) как раз было 15-ое число, Вы знаете систему, которая работает с этой базой? Может быть в середине месяца запускаются какие-то запланированные задания, которые как-то оптимизируют базу, подтирают какие-то ненужные / промежуточные данные, может считают какие-то агрегаты и стирают исходные данные - и тд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2022, 14:44 |
|
||
|
rman бэкап - уменьшился объем бэкапа
|
|||
|---|---|---|---|
|
#18+
Спасибо за советы. Значит, все это время - больше суток - оно выполняло команду RESTORE ... VALIDATE, и никаких ошибок не обнаружило, что уже радует. Знание системы мною... просто я единственный оставшийся, который знает хоть что-то. Пытаюсь потихоньку разбираться, конечно. Прошлый АБД недоступен, спросить не у кого. Вот, спрашиваю на форуме. Но, насколько я знаю, ничего особенного именно 15 числа не запускается. Да и вообще - все очистки у нас проводятся раз в неделю, тоже на автомате, и тоже ошибок не было. А по поводу размера - все равно непонятно. Вот строчка из v$rman_backup_subjob_details - именно того бэкапа, о котором речь OUTPUT_DEVICE_TYPE SBT_TAPE AUTOBACKUP_DONE NO STATUS COMPLETED INPUT_TYPE DB FULL OPTIMIZED NO COMPRESSION_RATIO 1,121777088 INPUT_BYTES_DISPLAY 738.00G OUTPUT_BYTES_DISPLAY 657.88G Примерно такой объем (650 гиг) и был у бэкапа раньше. Так почему же теперь он стал 400 гиг на дисках / лентах - непонятно. Или это уже не rman такой результат дает - но что тогда? Ладно, пойду скрипт посмотрю и статью почитаю, может, найдется что. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2022, 09:36 |
|
||
|
|
start [/forum/topic.php?fid=52&fpage=2&tid=1879505]: |
0ms |
get settings: |
25ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
45ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
217ms |
get tp. blocked users: |
4ms |
| others: | 303ms |
| total: | 633ms |
| 0 / 0 |
