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 или скрытым параметром)