ORA-1578/ORA-26040 NOLOGGING损坏的块-错误说明和解决方案（文档ID 794505.1）

最新推荐文章于 2021-04-05 17:29:29 发布

张玉龙

最新推荐文章于 2021-04-05 17:29:29 发布

阅读量1.2k

点赞数

分类专栏： oracle

原文链接：https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=425292891957148&id=794505.1&_adf.ctrl-state=cf8u63hxk_102

版权

oracle 专栏收录该内容

79 篇文章 2 订阅

订阅专栏

ORA-1578 / ORA-26040 Corrupt blocks by NOLOGGING - Error explanation and solution (Doc ID 794505.1)

PURPOSE

This note is intended to describe how Oracle reports a corruption caused by a NOLOGGING operation with ORA-1578 / ORA-26040 and how to fix the errors. 本说明旨在描述Oracle如何报告由ORA-1578/ORA-26040的NOLOGGING操作引起的损坏，以及如何修复错误。

IMPORTANT 重要

When ORA-26040 is not produced along with ORA-1578 the block is then corrupt by a different reason and RMAN Block Media Recovery can be used to repair the corruption. Refer to Doc ID 1578.1

当未与ORA-1578一起生成ORA-26040时，该块会由于其他原因而损坏，并且RMAN块介质恢复可用于修复损坏。请参阅Doc ID 1578.1

SCOPE

This document is intended for Customers and Oracle Support.

DETAILS

When a segment is defined with the NOLOGGING attribute and if a NOLOGGING/UNRECOVERABLE operation updates the segment or if datapump import parameter disable_archive_logging:y is used, the online redo log file is updated with minimal information to invalidate the affected blocks when a RECOVERY is later performed.
如果使用NOLOGGING属性定义了一个段，并且如果NOLOGGING/UNRECOVERABLE操作更新了该段，或者使用了datapump导入参数disable_archive_logging:y，online redo log将以最少的信息进行更新，在以后执行恢复时使受影响的块无效。
If the associated redo/archived log file is used to RECOVER the data files, Oracle invalidates such blocks and the error ORA-26040 along with error ORA-1578 are reported by SQL statements in the next block reads.
如果将关联的 redo/archived log 文件用于恢复数据文件，则Oracle使此类块无效，并且在下一个块读取中，SQL语句将报告错误ORA-26040和错误ORA-1578。
Errors Example:

SQL> select * from test_nologging;

ORA-01578: ORACLE data block corrupted (file # 11, block # 84)
ORA-01110: data file 4: '/<path>/<datafilename>.dbf'
ORA-26040: Data block was loaded using the NOLOGGING option

The NOLOGGING attribute is stored in column LOGGING in data dictionary views like:
NOLOGGING属性存储在数据字典视图中的LOGGING列中，例如：
DBA_TABLES, DBA_INDEXES, DBA_LOBS, DBA_TAB_PARTITIONS, DBA_LOB_PARTITIONS, DBA_TAB_SUBPARTITIONS, etc.

LOGGING='NO' indicates NOLOGGING.

The block is then marked as Soft Corrupt meaning that the next block read will report the ORA-1578/ORA-26040 errors.

然后将该块标记为“软损坏”，这意味着下一个读取的块将报告ORA-1578/ORA-26040错误。

Please note :- If a tablespace is encrypted and it has NOLOGGING blocks, only the error ORA-28304 is reported.
请注意： -如果表空间已加密并且具有NOLOGGING块，则仅报告错误ORA-28304。
It requires to validate using RMAN and check v$nonlogged_block or dump the block to confirm the block has NOLOGGING format. 它要求使用RMAN进行验证并检查v$nonlogged_block或dump该块以确认该块具有NOLOGGING格式。

DATAPUMP parameter DISABLE_ARCHIVE_LOGGING

The DATAPUMP impdp parameter DISABLE_ARCHIVE_LOGGING:Y disables the LOGGING definition during import which will generate NOLOGGING operations for the table and index; if the associated datafile is restored and recovered, subsequent statement will fail with error ORA-1578 and ORA-26040. DATAPUMP impdp参数DISABLE_ARCHIVE_LOGGING:Y在导入期间禁用LOGGING定义，该定义将为表和索引生成NOLOGGING操作。如果还原和恢复了关联的数据文件，则后续语句将失败，并显示错误ORA-1578和ORA-26040。

"If the database is in FORCE LOGGING mode, then the DISABLE_ARCHIVE_LOGGING option will not disable logging when indexes and tables are created". “如果数据库处于FORCE LOGGING模式，那么在创建索引和表时 DISABLE_ARCHIVE_LOGGING 选项将不会禁用日志记录”。

An example of this parameter during import is: 导入期间此参数的示例为：

impdp <schema>/<schema_passwd> directory=DATA_PUMP_DIR dumpfile=dp transform=disable_archive_logging:y

RMAN/DBV and Corrupt Blocks by NOLOGGING

DBV prints the generic message DBV-200 in rdbms versions lower than 10.2.0.4 and error DBV-201 in versions greater or equal to 10.2.0.4 Doc ID 5031712.8: DBV在低于10.2.0.4的rdbms版本中打印通用消息DBV-200，而在大于或等于10.2.0.4的版本中显示错误DBV-201 Doc ID 5031712.8：

DBV-00200: Block, dba 46137428, already marked corrupted
DBV-00201: Block, DBA 46137428, marked corrupt for invalid redo application

The "VALIDATE" RMAN command is used to identify NOLOGGING blocks and populates the view v$database_block_corruption (versions lower than 12c) and v$nonlogged_block (12c and greater). In the next example the validate output reports 933 blocks marked as corrupt in datafile 4 then v$database_block_corruption or v$nonlogged_block will be updated with that information:

RMAN命令"VALIDATE"用于标识NOLOGGING块，并填充视图v$database_block_corruption(版本低于12c)和v$nonlogged_block(12c及更高版本)。在下一个示例中，validate输出报告933 blocks在datafile 4中标记为已损坏的块，然后将使用该信息更新v$database_block_corruption 或v$nonlogged_block：

RMAN> VALIDATE DATABASE;
...
.....
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
4    OK     933            1            6401            2275124   
  File Name: /<path>/<datafilename>.dbf

In versions lower than 10.2.0.5 and 11.1.0.7, RMAN validate reports it with a generic message like: 在低于10.2.0.5和11.1.0.7的版本中，RMAN validate会通过以下通用消息来报告该消息：

10.2.0.4 and lower, 11.1.0.6, 11.1.0.7:

The VALIDATE RMAN command reports the NOLOGGING blocks v$database_block_corruption with CORRUPTION_TYPE=LOGICAL

In version 10.2.0.5 or in 11.2.0.1 and forward, RMAN has been enhanced to report it with CORRUPTION_TYPE=NOLOGGING. Reference Doc ID 7396077.8 : 在10.2.0.5版或11.2.0.1及更高版本中，RMAN已得到增强，可以使用CORRUPTION_TYPE=NOLOGGING 进行报告。参考Doc ID 7396077.8：

10.2.0.5 and 11.2.0.1+:

The VALIDATE RMAN command reports the NOLOGGING blocks in v$database_block_corruption with CORRUPTION_TYPE=NOLOGGING

In version 12c and forward RMAN validate no longer populates view v$database_block_corruption; instead the new view v$nonlogged_block is updated: 在版本12c和更高版本的RMAN中，validate不再填充视图v$database_block_corruption；而是更新了新视图v$nonlogged_block：

12c:

RMAN validate reports it in v$nonlogged_block

In version 12.2 the new command "validate .. nonlogged block" is available to validate NOLOGGING Blocks. In the next example datafiles 5 and 6 have nologged blocks: 在版本12.2中，新命令"validate .. nonlogged block"可用于验证NOLOGGING块。在下一个示例中，数据文件5和6没有记录日志块：

RMAN> validate database nonlogged block;

Starting validate at ...
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=133 device type=DISK
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: validation complete, elapsed time: 00:00:35



List of Datafiles
=================
File Status Nonlogged Blocks Blocks Examined Blocks Skipped
---- ------ ---------------- --------------- --------------
1        OK 0                         106363 0
2        OK 0                          78919 0
3        OK 0                          96639 0
4        OK 0                           4991 0
5        OK 400                         2559 0
6        OK 569                         2559 0



Details of nonlogged blocks can be queried from v$nonlogged_block view

The alert log is updated with:

Started Nonlogged Block Replacement recovery(validate) on file 5 (ospid 26351 rcvid 10616970560844821494)
Finished Nonlogged Block Replacement recovery(validate) on file 5. 400 blocks found

Started Nonlogged Block Replacement recovery(validate) on file 6 (ospid 26351 rcvid 10616970560844821494)
Finished Nonlogged Block Replacement recovery(validate) on file 6. 569 blocks found

RMAN backups do not fail due to NOLOGGING corrupt blocks. In general RMAN does not fails with soft corrupt blocks; the MAXCORRUPT clause is not necessary in such cases. The backup will contain the soft corrupt block and a restore will leave the corruption as when the backup was made. RMAN备份不会因NOLOGGING损坏的块而失败。通常，RMAN不会因软损坏块而失败；在这种情况下，不需要MAXCORRUPT子句。备份将包含软损坏块，还原将保留进行备份时的损坏。

When there is a generic message besides the error ORA-26040, a block dump might be taken and see if the byte 0xff is along the block or if the block is associated to a segment, try to read it with a SQL statement for which errors ORA-1578/ORA-26040 will be produced because the block is corrupt due to media recovery with a NOLOGGING operation. 如果错误ORA-26040之外还有一条通用消息，则可能会进行块dump，并查看字节0xff是否位于该块上，或者该块是否与某个段相关联，请尝试使用带有错误的SQL语句读取它将产生ORA-1578/ORA-26040，因为该块由于使用NOLOGGING操作进行介质恢复而损坏。

Monitoring NOLOGGING Operations 监视NOLOGGING操作

The RMAN command "REPORT UNRECOVERABLE" reports when a data file has been changed by a NOLOGGING operation and the datafile has not been backed up since then. Example: 当通过NOLOGGING操作更改了数据文件并且此后没有备份数据文件时，RMAN命令"REPORT UNRECOVERABLE"将报告。例：

RMAN> report unrecoverable;

using target database control file instead of recovery catalog
Report of files that need backup due to unrecoverable operations
File Type of Backup Required Name
---- ----------------------- -----------------------------------
4    full or incremental     /<path>/<datafilename>.dbf

V$DATAFILE has several columns that are updated when a NOLOGGING operation takes place and parameter db_unrecoverable_scn_tracking is set to true (default value); db_unrecoverable_scn_tracking is not available in 10g. Reference the next V$DATAFILE columns in our Oracle Database Reference Documentation: 当执行NOLOGGING操作并将参数db_unrecoverable_scn_tracking设置为true（默认值）时，V$DATAFILE会更新几列。db_unrecoverable_scn_tracking在10g中不可用。请参考我们的Oracle数据库参考文档中的下一个V$DATAFILE列：

UNRECOVERABLE_CHANGE#     
UNRECOVERABLE_TIME    
FIRST_NONLOGGED_SCN
FIRST_NONLOGGED_TIME

In 11.2.0.4 or 12.1.0.2+ the MRP in a Standby Database can report NOLOGGING changes in the alert log when event 16490 is set to level 1.  The alert log is updated with these informative messages:    在11.2.0.4或12.1.0.2+中，将事件16490设置为级别1时，Standby Database中的MRP可以报告alert log中的NOLOGGING更改。alert log将使用以下信息性消息进行更新：

ORA-16490 "logging invalidated blocks on standby due to invalidation redo"

"INVD_BLKS: Invalidating (file <file number>, bno <block number>)"    
"fname: 'Datafile name'. rdba: ..."

Identify when a block was marked as NOLOGGING

To identify when a block was marked as NOLOGGING, use the block scn in the trace file or use the value in column CORRUPTION_CHANGE# in v$database_block_coruption to translate it to a timestamp:
要确定何时将某个块标记为NOLOGGING，请在trace文件中使用块scn或使用v$database_block_coruption中的CORRUPTION_CHANGE#列中的值将其转换为时间戳：

Use the block scn from a trace file 使用trace文件中的块scn

Example from trace file: trace文件中的示例：

  Start dump data blocks tsn: 60 file#: 4 minblk 84 maxblk 84
  buffer tsn: 3 rdba: 0x02c00054 (11/84)
  scn: 0x0771.4fa24eb5 seq: 0xff flg: 0x04 tail: 0x4eb500ff

Take 0x0771.4fa24eb5, remove the '.' and convert 0x07714fa24eb to decimal which is 511453045995

取 0x0771.4fa24eb5 删除 '.' 并将 0x07714fa24eb 转换为十进制 511453045995

Use the value in column CORRUPTION_CHANGE# in v$database_block_coruption

使用v$database_block_coruption中的CORRUPTION_CHANGE#列中的值

If RMAN validate is run the view v$database_block_coruption is populated with corruption_type='NOLOGGING' (10.2.0.5 and 11.2.0.1+) and column CORRUPTION_CHANGE# has the decimal scn value. 如果运行RMAN验证，则视图v$database_block_coruption 会填充corruption_type='NOLOGGING' (10.2.0.5 and 11.2.0.1+) ，并且CORRUPTION_CHANGE＃列的十进制scn值。

Get the SCN Timestamp 获取SCN时间戳

To get the timestamp use any of these methods: 要获取时间戳，请使用以下任何一种方法：

select scn_to_timestamp(&&decimal_scn) from dual;


If RMAN validate was run:


select file#, block#, scn_to_timestamp(CORRUPTION_CHANGE#)
from v$database_block_corruption
where CORRUPTION_TYPE='NOLOGGING';

In 12c:

select file#, block#, scn_to_timestamp(NONLOGGED_START_CHANGE#)
from v$nonlogged_block;


If error ORA-08181 is produced query gv$archived_log or gv$log_history to get a time interval approximation:

alter session set nls_date_format = 'DD-MON-YY HH24:MI:SS';

select first_time, next_time
from   gv$archived_log
where  &decimal_scn between first_change# and next_change#;

OR

select first_time
from   gv$log_history
where  &decimal_scn between first_change# and next_change#;


if RMAN validate was run:

alter session set nls_date_format = 'DD-MON-YY HH24:MI:SS';

select file#, block#, first_time, next_time
from   v$archived_log, v$database_block_corruption
where  CORRUPTION_CHANGE# between first_change# and next_change#
  and CORRUPTION_TYPE='NOLOGGING';

OR

select file#, block#, first_time
from   v$log_history, v$database_block_corruption
where  CORRUPTION_CHANGE# between first_change# and next_change#
  and CORRUPTION_TYPE='NOLOGGING';

In 12c:

alter session set nls_date_format = 'DD-MON-YY HH24:MI:SS';

select file#, block#, first_time, next_time
from v$nonlogged_block, v$archived_log
where NONLOGGED_START_CHANGE# between first_change# and next_change#;

OR

select file#, block#, first_time
from v$nonlogged_block, v$log_history
where NONLOGGED_START_CHANGE# between first_change# and next_change#;

NOARCHIVELOG and NOLOGGING in SYSAUX tablespace / AWR, EM, etc

If the database is running on rdbms versions 11.1.0.6 or 11.1.0.7 or 11.2.0.1, ORA-1578 and ORA-26040 can be produced due to NOLOGGING for DIRECT PATH operations after a manual RECOVER DATABASE in a NOARCHIVELOG mode database even if FORCE LOGGING is enabled in the database or even if LOGGING is defined for the segment.
如果数据库在rdbms版本11.1.0.6 or 11.1.0.7 or 11.2.0.1上运行，则即使在NOARCHIVELOG模式的数据库中手动执行RECOVER DATABASE之后，由于NOLOGGING for DIRECT PATH操作也会产生ORA-1578和ORA-26040，即使在数据库中启用了FORCE LOGGING，或者即使为该段定义了LOGGING。
This is most commonly seen in AWR or EM objects (Enterprise Manager) stored in the SYSAUX tablespace.
这在SYSAUX表空间中存储的AWR或EM对象（企业管理器）中最常见。
Reference Doc Id 1071869.1 for details and solution. Note that the database may currently be in a version greater than 11.1 or 11.2.0.1 but the problem could be introduced before upgrade from one of those affected versions. 参考Doc Id 1071869.1。请注意，当前数据库的版本可能大于11.1或11.2.0.1，但是在从那些受影响的版本之一升级之前，可能会引入问题。

The restriction has been lifted in 11.2.0.2+ and this issue did not occur in 10g.
该限制已在11.2.0.2+版本中取消，在10g中未发生此问题。

Changes by RDBMS versions RDBMS版本的更改

RDBMS Version	Change
10.2.0.4+	DBverify reports a NOLOGGING block with error "DBV-00201: Block, DBA <rdba>, marked corrupt for invalid redo application" DBverify报告一个NOLOGGING块，错误为"DBV-00201: Block, DBA <rdba>, marked corrupt for invalid redo application"
10.2.0.5, 11.2.0.1+	RMAN validate reports the NOLOGGING block in v$database_block_corruption with corruption_type='NOLOGGING' RMAN验证报告v$database_block_corruption中的NOLOGGING块，且该文件的corruption_type='NOLOGGING'
11g+	Parameter db_unrecoverable_scn_tracking is introduced. 引入了参数db_unrecoverable_scn_tracking。
11.1.0.6, 11.1.0.7, 11.2.0.1	ORA-1578 and ORA-26040 can be produced due to NOLOGGING for DIRECT PATH operations after a manual RECOVER DATABASE in a NOARCHIVELOG mode database even if FORCE LOGGING is enabled. The restriction has been lifted in 11.2.0.2+ and problem did not happen in 10g. 即使启用了FORCE LOGGING，在NOARCHIVELOG模式的数据库中手动恢复数据库后，由于直接路径操作的NOLOGGING也会产生ORA-1578和ORA-26040 。该限制已在11.2.0.2+中取消，在10g中未出现问题。
11.2.0.4, 12.1.0.2+	Managed Physical Standby Recovery (MRP) can report NOLOGGING changes in the alert log when event 16490 is set to level 1. The alert log is updated with message: 当事件16490设置为级别1时，受管物理备用恢复（MRP）可以报告警报日志中的NOLOGGING更改。警报日志更新为消息： ORA-16490 "logging invalidated blocks on standby due to invalidation redo" This improvement was introduced by the fix of Bug 16319519
12c	RMAN validate no longer populates view v$database_block_corruption; instead the new view v$nonlogged_block is updated RMAN验证不再填充视图v$database_block_corruption; 而是更新了新视图v$nonlogged_block
12.2	RMAN commands are introduced: 引入了RMAN命令 RMAN> validate [database / datafile] nonlogged block; RMAN> recover [database / datafile] nonlogged block; -> for Standby Databases

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. 请注意，受影响的块中的数据不可挽救。除非在重做日志中注册了NOLOGGING操作之后备份了数据文件，否则"Media Recovery" or "RMAN blockrecover"之类的方法将无法解决问题。

Is error after RMAN DUPLICATE? 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: 如果错误是在RMAN DUPLICATE or RESTORE之后，请在SOURCE数据库中启用FORCE LOGGING并再次执行DUPLICATE或RESTORE（在新的BACKUP之后）步骤：

alter database force logging;

Is error produced in a PHYSICAL STANDBY Database? 是否在PHYSICAL STANDBY数据库中产生错误？

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 如果在PHYSICAL STANDBY数据库中产生了错误，则该选项是从主数据库中还原受影响的文件（仅当PRIMARY中不存在问题时）或使用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: 在12c中，可以使用RMAN命令：RECOVER NONLOGGED BLOCK with(具有) DATAFILE, TABLESPACE, DATABASE granularity(粒度)。DATABASE的示例是：

RMAN> RECOVER DATABASE NONLOGGED BLOCK;

To avoid the problem from being introduced, force logging in the PRIMARY database with: 为避免引入此问题，请在PRIMARY数据库中使用force logging：

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. 如果主数据库中的同一数据文件还有其他不同的块标记为nologging，而在当前备用数据库中，这些块未标记为nologging，则在复制数据库之前可能需要使用事件10231或dbms_repair手动干预以跳过两个数据库中的那些损坏的块。从主文件到备用文件；最终结果将是主数据库和备用数据库的合并表。主数据库中没有日志记录块可能是从备份中恢复主数据库的结果，或者是因为它是以前的备用数据库，现在在切换后成为主数据库。

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: 为了解决错误，如果它不是INDEX，则可以从备份（如export dump）或其他源中恢复该段。如果备份不可用，则可以按照以下步骤重新创建该段：

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: 确定受影响的段中所描述Doc ID 819533.1或确定所有的损坏的对象中所描述的Doc ID 472231.1，然后：

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 如果NOLOGGING块是一个FREE块（关联的范围在dba_free_space中），可以通过运行DBVerify并发现错误DBV-00201或显示在视图v$database_block_corruption中来发现，则可以选择等到该块被重用为止自动重新格式化块或使用Doc ID 336133.1强制重新格式化块

Is it an INDEX? 是索引吗

If it is an INDEX, drop and create the index 如果它是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: 如果是TABLE，则可以使用过程DBMS_REPAIR.SKIP_CORRUPT_BLOCKS来跳过SQL语句中的损坏块；Doc ID 556733.1包含一个DBMS_REPAIR示例。然后决定重新创建该段：

by moving the table: alter table &table_name move;

by saving the data (export, Create Table as Select, etc) and then truncate or drop/create.

通过保存数据 (export, Create Table as Select, etc) ，然后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:   --Move表

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? 是LOB吗？

If it is a LOB use Doc ID 293515.1 如果是LOB，请使用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. 通过删除分段解决问题后，该块会被标记为空闲，并且以后可能会分配给其他分段；它可能仍标记为NOLOGGING。DML/query不会失败；该块在被新段重用时将被重新格式化而不会出错。那时，如果仍然在v$database_block_corruption or v$nonlogged_block (12c+) 中报告了损坏，请运行rman validate清除该视图。

REFERENCES

NOTE:958181.1 - Rolling a Standby Forward using an RMAN Incremental Backup To Fix The Nologging Changes
NOTE:819533.1 - How to identify the corrupt Object reported by ORA-1578 / RMAN / DBVERIFY
NOTE:1071869.1 - ORA-1578 ORA-26040 in 11g for DIRECT PATH with NOARCHIVELOG even if LOGGING is enabled
NOTE:293515.1 - ORA-1578 ORA-26040 in a LOB segment - Script to solve the errors
NOTE:556733.1 - DBMS_REPAIR SCRIPT
NOTE:290161.1 - The Gains and Pains of Nologging Operations
NOTE:472231.1 - How to identify all the Corrupted Objects in the Database with RMAN
NOTE:7396077.8 - Bug 7396077 - RMAN does not differentiate NOLOGGING corrupt blocks that produce ORA-1578/ORA-26040