Виталий Перевозчиков1. На включенной БД через редактор поправил файл данных.
Что именно поправил?
Мож этот блок и не бэкапится
Или бОльшая часть этого блока не читается в принципе

Достаточно при бэкапе сказать CHECK LOGICAL

Правда, это не поможет при [слегка] битых архивлогах

Но если уж совсем нарушен формат блока, что в датафайле, что в архивлоге, обычный бэкап это сразу поймает

fortnetBy default, the BACKUP command computes a checksum for each block and stores it in the backup.
The BACKUP command ignores the values of DB_BLOCK_CHECKSUM because this initialization parameter applies to datafiles in the database, not backups

т.е. считает и сохраняет в бэкапе, но не проверяет.

Поэтому validate (database | backup | datafile)...Как раз проверяет, как и любой читатель

Но может не сохранять.

Тут еще есть такой момент -- бэкап не пишет копию блока 1:1 -- он использует знание формата ораклового блока для оптимизации его хранения, не бэкапит неиспользованное место, пишет инкрементальные бэкапы и т.д. Поэтому, КС, которую пишет RMAN при бэкапе, по идее, никак не относится к исходному блоку, а относится к блоку бэкапа. И защищает, соответственно, его
Что, собственно, уже и проверяется при VALIDATE BACKUP и RESTORE

Большую часть физических повреждений определятся и без этого.
Ну а CHECK LOGICAL по идее именно и пытается не только блок прочитать (соответствие физического формата, соответствие заголовка и подписи, контрольная сумма) но и читабельность каждой строки, что в табличках, что в индексах
Ну, по крайней мере, я так понял

Есть еще нота "Top 10 Backup and Recovery Best Practices (Doc ID 388422.1)"

Ты решил окончательно загрузить свою БД проверкой своей целостности?
Ей больше нечем заняться?

Периодические проверки своих бэкапов в виде восстановления тестовой БД дадут тебе вполне достаточный уровень контроля качества
Еще, конечно, если так заботишься, желателен стендбай

И, естественно, использовать сертифицированные операционки (и, что сейчас совсем не трудно) железяки
Как правило, этого вполне достаточно для работы как минимум, десятки лет без внутренних повреждений

Ежели софт постоянно развивается, используются новые фичи, то отслеживание ошибок в alert.log и соответствующее реагирование (например, правка кода) позволяет безбедно жить даже без техподдержки

Надо, кстати, сразу понимать, что система с кучей девяток доступности обязательно требует той самой техподдержки -- и не только в смысле переложения ответственности. Велосипеды здесь неуместны. Просто из-за отсутствия знаний как оно там "внутре".

А сломаться может любая програма/железяка, и массив, и память и т.п. Соответственно и насрано в блоке может быть неплохо.

Но сдается тут не тот случай. Тогда уж выполняй ежедневный/еженедельный экспорт и уж во что-нибудь ты ее восстановишь

fortnet<Как раз проверяет, как и любой читатель>

А где это можно прочитать?Это где-то нужно читать?
RMAN CHANNEL читает блок как обычный серверный процесс (и если не может получить консистентную, NON-FRACTURED копию блока, перечитывает его, вроде до 5 раз), т.е. и поведение как у обычного серверного процесса
Вроде и ноту я приводил, не помню, но вроде там сказано такое
Ну и попробуй через BBED (а то и шестнадцатиричным редактором) установить кривую КС для блока в SYSTEM или при установленном DB_BLOCK_CHECKING -- нарвешься на block corruption

fortnetНе за этим ли добавлен VALIDATE?Насколько я понимаю -- то же самое, что и просто BACKUP (можно даже с CHECK LOGICAL), только без выходного файла

fortnetSYSTEM не привлекать - у него особый статус.Установи соответствующий DB_BLOCK_CHECKING и такой статус появится у всех
fortnetОсновываясь на доке остаюсь при своем :
VALIDATE - проверка без выполнения бэкапаНо и не более чем просто BACKUP. Можешь также указать ему CHECK LOGICAL
fortnetBACKUP - запись без чтения/проверки контрольной суммы , записанной процессом DBW c записью своей контрольной суммы, если не перебито опцией NOCHECKSUM.NOCHECKSUMIf DB_BLOCK_CHECKSUM is typical, then the database computes a checksum for each block during normal operations and stores it in the block before writing it to disk. When the database reads the block from disk later, it recomputes the checksum and compares it to the stored value . If they do not match, then the block is damaged.
...
If you specify the NOCHECKSUM option, then RMAN does not perform a checksum of the blocks when writing the backup .
fortnetBACKUP logical check - проверка всех возможных ошибок в БЭКАПЕ.CHECK LOGICAL Tests data and index blocks that pass physical corruption checks for logical corruption
...
Examples of logical corruption are corruption of a row piece or index entry. If RMAN finds logical corruption, then it logs the block in the alert log and server session trace file. The SET MAXCORRUPT command specifies the total number of physical and logical corruptions permitted in a data file .

Ты путаешь сканирование и выходной файл
А также NULL compression (никогда не использовались) и Unused block compression (уже не используется)

Я просто показывал, что это твое утверждение неверно
fortnetНапример, с прямым бэкапом на ленту так называемый null compression не пройдет - будет всё записано один в один.
Возможно, ты просто описАлся и имел ввиду Unused block compression -- достаточно просто об этом сказать

fortnetНу, пример достаточно экзотичен. Здесь показана NULL compression - которая на нормальной рабочей БД имеет не более 5%. Основная масса приходится на Unused block compression , которая и имеет ограничения в применении.Вот это еще интересней. Либо ты не понимаешь, что такое Unused block compression, либо как раз именно у тебя экзотические БД, где достаточно часто происходит TRUNCATE/MOVE постоянных таблиц и REBUILD индексов в новое место.
Может ты не в курсе, но в некоторых случаях Unused block compression не работает и при бэкапе на диск
Иметь резерв свободного места -- это, как раз, нормально. И NULL compression намного более актуальней, особенно, когда ты не хочешь по каким-то причинам использовать AUTOEXTEND, а добавляешь, например, целиком новый LUN -- тебе становится пофиг, ты знаешь, что размер бэкапа (и время, на него потраченное) при этом не увеличится.
Нет, конечно, есть специфические варианты -- типа stage-area, где все подготавливается для массовой загрузки, а потом TRUNCATE-ится. Но, как правило, там и бэкап нафиг не нужен, да и наверняка NOLOGGING на табличном пространстве стоит.

Опять же почему не реализовано Unused Block Compression (а также Undo block compression) для "3rd party media managers". Дык это просто политика, точно также как на них не работает "Encrypted Backup". Просто впаривание своего продукта OSB. Технических ограничений для этого нет (в отличии, например, от выполнении BACKUP AS COPY на ленту -- тут уже не важно "3rd party" или OSB)

И кстати, то, что не выполняется Unused Block compression позволяет отловить сбойные блоки, которые не относятся к используемым в данный момент. А мож там физическое повреждение на диске и уже пора что-то с этим решать. VALIDATE ведь их тоже пропустит. Единственный вариант -- прогонять время от времени DBVERIFY или отключить Unused block compression (выполнять бэкап на "3rd party media managers", установить гарантированную RP или скрытым параметром)