Виталий Перевозчиков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), только без выходного файла