SOLUTION
Note that the data inside the affected blocks is not salvageable. Methods like "Media Recovery" or "RMAN blockrecover" will not fix the problem unless the data file was backed up after the NOLOGGING operation was registered in the Redo Log.
Is error after RMAN DUPLICATE?
If the error is after a RMAN DUPLICATE or RESTORE, enable FORCE LOGGING at SOURCE database and perform the DUPLICATE or RESTORE (after new BACKUP) steps again:
alter database force logging;
Is error produced in a PHYSICAL STANDBY Database?
If the error is produced in a PHYSICAL STANDBY database, the option is to restore the affected file from the primary database (only if the problem is not present in the PRIMARY) or use the method described in Doc ID 958181.1
In 12c there is the option to use the RMAN command: RECOVER NONLOGGED BLOCK with DATAFILE,TABLESPACE,DATABASE granularity. An example for DATABASE is:
RMAN> RECOVER DATABASE NONLOGGED BLOCK;
To avoid the problem from being introduced, force logging in the PRIMARY database with:
alter database force logging;
If the same datafile in primary has other different blocks marked as nologging whereas in the current standby those blocks are not marked as nologging then manual intervention to skip those corrupt blocks in both databases, either using event 10231 or dbms_repair, might be required before copying the file from primary to standby; the final result will be a merged table from primary and standby databases. Nologging blocks in the primary database could be the result of a recovered primary database either from backup or because it was a former standby database and is now primary after switchover.
In 12c
In order to resolve the errors and if it is not an INDEX the segment can be recovered from a backup like an export dump or from another source. If backups are not available the segment might be recreated following the next steps:
Identify the affected segment
Identify the affected segment as described in Doc ID 819533.1 or identify all the corrupt objects as described in Doc ID 472231.1, then:
Is it a FREE Block?
If the NOLOGGING Block is a FREE Block (the associated extent is in dba_free_space), which could be discovered by running DBVerify with error DBV-00201 or shown in view v$database_block_corruption, there is the option to wait until the block is reused which will automatically re-format the block or force re-formatting the block using Doc ID 336133.1
Is it an INDEX?
If it is an INDEX, drop and create the index
Is it a TABLE?
If it is a TABLE, procedure DBMS_REPAIR.SKIP_CORRUPT_BLOCKS can be used to skip the corrupt block in SQL statements; Doc ID 556733.1 has a DBMS_REPAIR example. Then decide to re-create the segment:
by moving the table: alter table &table_name move;
OR
by saving the data (export, Create Table as Select, etc) and then truncate or drop/create.
Example:
Mark the table to skip corrupt blocks:
BEGIN
DBMS_REPAIR.SKIP_CORRUPT_BLOCKS (
SCHEMA_NAME => '&schema_name',
OBJECT_NAME => '&table_name',
OBJECT_TYPE => dbms_repair.table_object,
FLAGS => dbms_repair.SKIP_FLAG);
END;
/
Confirm that skipping corrupt blocks is ENABLED for the table:
select SKIP_CORRUPT
from dba_tables
where owner = '&schema_name'
and table_name = '&table_name';
Move the table:
alter table &table_name move;
OR if decided to save the data:
export (datapump or conventional export)
or
Create Table &newtable as Select * From &nologging_corrupted_table;
Is it a LOB?
If it is a LOB use Doc ID 293515.1
When the issue is fixed by dropping the segment, the block is marked as free and may be later allocated for a different segment; it may remain marked as NOLOGGING. A DML/query will not fail; the block will be re-formatted with no errors when it is reused by a new segment. At that time if the corruption is still reported in v$database_block_corruption or v$nonlogged_block (12c+), run a rman validate to clear that view.
