ORA-01578和ORA-26040--NOLOGGING操作引起的壞塊-錯誤解釋和解決方案(文檔ID 1623284.1)
（一）NOLOGGING操作引起的壞塊（ORA-01578和ORA-26040）簡介
如果隻是錯誤ORA-01578，而沒有伴随ORA-26040，那麼這個壞塊是由其它的原因引起的壞塊，可以嘗試使用RMAN的BMR（Block Media Recovery）修複。
如果資料段（表段、索引段）被定義為NOLOGGING屬性，那麼當NOLOGGING加APPEND、UNRECOVERABLE操作修改該資料段或者使用資料泵（DATAPUMP）impdp參數DISABLE_ARCHIVE_LOGGING:Y時，聯機重做日志隻會記錄很少的日志資訊。如果這些聯機重做日志或歸檔日志被用來恢複資料檔案，那麼Oracle會将對應的資料塊标志為無效（Soft Corrupt），而且下一次通路這些資料塊時，會報ORA-01578和ORA-26040錯誤。
例如：
SQL> select * from test_nologging;
ORA-01578: ORACLE data block corrupted (file # 11, block # 84)
ORA-01110: data file 4: '/oradata/users.dbf'
ORA-26040: Data block was loaded using the NOLOGGING option
資料字典視圖DBA_TABLES、DBA_INDEXES、DBA_LOBS、DBA_TAB_PARTITIONS、DBA_LOB_PARTITIONS、DBA_TAB_SUBPARTITIONS中的LOGGING列記錄了NOLOGGING屬性。若LOGGING='NO'則表示NOLOGGING。
資料泵DATAPUMP的impdp參數DISABLE_ARCHIVE_LOGGING:Y在執行導入時會禁止LOGGING定義，而産生NOLOGGING操作。如果相應的datafile被restored和recovered，那麼接下來的涉及到目标表的查詢會報錯ORA-1578和ORA-26040。如果資料庫是FORCE LOGGING模式，那麼DISABLE_ARCHIVE_LOGGING選項不會關閉LOGGING。
impdp使用參數“DISABLE_ARCHIVE_LOGGING:Y”的一個例子:
impdp scott/tiger directory=DATA_PUMP_DIR dumpfile=dp transform=disable_archive_logging:y
NOLOGGING導緻的壞塊不會導緻RMAN備份失敗。一般來說soft corrupt block不會導緻RMAN備份失敗，不需要設定MAXCORRUPT。資料庫備份中就會含有soft corrupt block，如果使用這些備份恢複資料，那麼恢複的資料也含有soft corrupt block。
除ORA-26040錯誤之外，當還有一些其他通用資訊出現時，block dump可能會被産生。如果資料塊的block dump内有byte 0xff資訊或者屬于某個段，ORA-1578和ORA-26040會因為媒體恢複了NOLOGGING的部分導緻了corruption而出現。
（二）利用RMAN、DBV檢測NOLOGGING導緻的壞塊
DBV在檢測壞塊時，如果RDBMS版本小于10.2.0.4，那麼DBV列印錯誤DBV-200，如果RDBMS版本大于或等于10.2.0.4，那麼DBV列印錯誤DBV-201：
DBV-00200: Block, dba 46137428, already marked corrupted
DBV-00201: Block, DBA 46137428, marked corrupt for invalid redo application
RMAN的VALIDATE指令可以用來檢測NOLOGGING資料塊，檢查結果記錄在視圖V$DATABASE_BLOCK_CORRUPTION（小于12c的版本）和V$NONLOGGED_BLOCK（12c及其以上）。
下面的例子中檢查出DATAFILE 4有933壞塊，查詢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: /oracle/dbs/users.dbf
RMAN在檢測壞塊時，如果RDBMS版本小于10.2.0.5和11.1.0.7，RMAN列印如下錯誤：
10.2.0.4 and lower, 11.1.0.6, 11.1.0.7:
RMAN validate reports it in v$database_block_corruption with CORRUPTION_TYPE=LOGICAL
如果RDBMS版本大于或等于10.2.0.5和11.2.0.1，RMAN報告，檢視視圖v$database_block_corruption中CORRUPTION_TYPE=NOLOGGING的記錄。
10.2.0.5 and 11.2.0.1+:
RMAN validate reports it in v$database_block_corruption with CORRUPTION_TYPE=NOLOGGING
在12c及以後版本中，RMAN validate的結果不在視圖v$database_block_corruption中，而是在視圖v$nonlogged_block。從12.2 版本開始，可以使用新的指令：“validate .. nonlogged block”去驗證nologging的block。
在以下的例子中，資料檔案5和6有nologged的block：
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
在告警日志中會更新以下資訊：
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
（三）監控NOLOGGING操作
若執行了NOLOGGING操作，并且之後在沒有備份的情況下，RMAN指令“REPORT UNRECOVERABLE”可以查詢出被影響的datafile。
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 /oracle/dbs/users.dbf
當初始化參數db_unrecoverable_scn_tracking設定為true（預設值，該參數在10g中是不可用的），那麼V$DATAFILE中以下列會被更新；
[email protected]> select UNRECOVERABLE_CHANGE# ,
2 UNRECOVERABLE_TIME ,
3 FIRST_NONLOGGED_SCN ,
4 FIRST_NONLOGGED_TIME from v$datafile where file#=6;
UNRECOVERABLE_CHANGE# UNRECOVERABLE_TIME FIRST_NONLOGGED_SCN FIRST_NONLOGGED_TIM
--------------------- ------------------- ------------------- -------------------
2878238 2018-04-10 10:53:47 2878238 2018-04-10 10:53:47
在11.2.0.4 或12.1.0.2+版本中，設定event 16490的情況下，實體備庫的MRP程序會檢查出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: ..."
（四）識别資料塊什麼時候被标志為NOLOGGING
識别資料塊什麼時候被标志為NOLOGGING，可以将trace檔案中資料塊SCN或者v$database_block_coruption視圖中CORRUPTION_CHANGE#值轉換為時間：
① 使用trace檔案中資料塊SCN，例如：
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
提取SCN值0x0771.4fa24eb5,删除'.'，然後轉換0x07714fa24eb到十進制511453045995。
② 使用v$database_block_coruption視圖中CORRUPTION_CHANGE#值
如果運作RMAN validate指令後，v$database_block_coruption視圖中corruption_type='NOLOGGING' (10.2.0.5 和 11.2.0.1+)，那麼CORRUPTION_CHANGE#列的值就是十進制的SCN值。可以使用下面的方法獲得SCN Timestamp時間：
select scn_to_timestamp(&&decimal_scn) from dual;
如果運作RMAN validate:
select file#, block#, scn_to_timestamp(CORRUPTION_CHANGE#)
from v$database_block_corruption
where CORRUPTION_TYPE='NOLOGGING';
在12c中：
select file#, block#, scn_to_timestamp(NONLOGGED_START_CHANGE#) from v$nonlogged_block;
如果查詢gv$archived_log 或 gv$log_history遇到錯誤ORA-08181:
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#;
或
select first_time
from gv$log_history
where &decimal_scn between first_change# and next_change#;
如果運作RMAN validate:
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';
或
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';
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#;
或
select file#, block#, first_time
from v$nonlogged_block, v$log_history
where NONLOGGED_START_CHANGE# between first_change# and next_change#;
（五）SYSAUX表空間、AWR、EM等出現NOARCHIVELOG和NOLOGGING問題
如果資料庫版本是11.1.0.6 或 11.1.0.7 或 11.2.0.1，對NOLOGGING對象執行過DIRECT PATH操作，并且後續執行了RECOVER DATABASE指令，即使資料庫FORCE LOGGING是打開的情況下，會出現ORA-1578和ORA-26040錯誤。這種問題經常發生在SYSAUX表空間中的AWR或EM對象。請參考Note 1071869.1。注意資料庫目前版本可能已經大于11.1 或者 11.2.0.1但是問題可能是在更新之前産生的。這個限制在11.2.0.2以上版本中取消，這個問題在10g不會發生。
RDBMS版本變化：
| RDBMS版本 | 變化 |
| 10.2.0.4+ | DBverify報告NOLOGGING block錯誤資訊 "DBV-00201: Block, DBA <rdba>, marked corrupt for invalid redo application" |
| 10.2.0.5, 10.2.0.1+ | RMAN validate指令檢查NOLOGGING block，在v$database_block_coruption視圖中記錄corruption_type='NOLOGGING' |
| 11g+ | 引入db_unrecoverable_scn_tracking參數 |
| 11.1.0.6 or 11.1.0.7 or 11.2.0.1 | NOARCHIVELOG模式資料庫，對NOLOGGING對象執行了DIRECT PATH操作，并且以後手動恢複資料庫，即使打開了FORCE LOGGING，也會報ORA-1578 和 ORA-26040。這個限制在11.2.0.2以上版本取消，這個問題在10g不會發生。 |
| 12c | RMAN validate的結果不在視圖v$database_block_corruption中，而是在視圖v$nonlogged_block |
| 12.2 | 以下RMAN指令被引入： RMAN> validate [database / datafile] nonlogged block; RMAN> recover [database / datafile] nonlogged block; -> 對于 Standby 資料庫 |
（六）解決方法
NOLOGGING操作引起的壞塊是不能修複的，比如“Media Recovery”或“RMAN blockrecover”都無法修複這種壞塊。可行的方法是在NOLOGGING操作之後立刻備份對應的資料檔案。
如果錯誤是執行RMAN DUPLICATE 或 RESTORE之後産生的，那麼在源庫打開FORCE LOGGING，然後再重新運作RMAN DUPLICATE 或 RESTORE。
alter database force logging;
如果錯誤出現在實體STANDBY資料庫，那麼可以從主庫恢複被影響的資料檔案（隻有當主庫沒有這個問題的情況下）。參考文檔Doc ID 958181.1。在Oracle 12c中可以使用RMAN選項RECOVER NONLOGGED BLOCK with DATAFILE、TABLESPACE、DATABASE。例如：
RMAN> RECOVER DATABASE NONLOGGED BLOCK;
為了避免這個問題發生，在主庫強制生産日志：
alter database force logging;
如果同一個datafile的資料塊在主庫出現nologging壞塊，但是備庫沒有，可以通過手動跳過(dbms_repair)壞塊或者設定event 10231。主庫出現nologging壞塊可能是由于主庫執行過備份恢複或者之前是備庫，執行了switchover。
如果NOLOGGING資料塊位于空閑資料塊（dba_free_space視圖可以查詢到），那麼DBVerify檢查會發現這個問題，報錯DBV-00201或者在v$database_block_corruption視圖中顯示。對于這種情況，可以等待到這個資料塊被重用時會自動格式化或者手動強制格式化。
如果是索引，那麼可以重新建立（drop/create）索引。如果是表，那麼可以使用存儲過程DBMS_REPAIR.SKIP_CORRUPT_BLOCKS跳過壞塊，然後考慮是否重建表。
在删除有壞塊的段之後，這個壞塊就處于空閑狀态，後續可以被配置設定給其他對象或段，當這個壞塊被配置設定給其它對象或段時，這個資料塊被重新格式化。如果v$database_block_corruption視圖中還是顯示為壞塊，那麼可以手動運作rman validate來清除視圖中的資訊。
如果是LOB，那麼請參考Note 293515.1。
實驗一：DISABLE_ARCHIVE_LOGGING:Y
RMAN> list backupset of datafile 6;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
12 Full 352.78M DISK 00:03:21 2018-04-09 14:50:59
BP Key: 12 Status: AVAILABLE Compressed: YES Tag: TAG20180409T144738
Piece Name: /u04/flash_recovery_area/LHR121/backupset/2018_04_09/o1_mf_nnndf_TAG20180409T144738_fdp34bfm_.bkp
List of Datafiles in backup set 12
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- ------------------- ----
6 Full 2865977 2018-04-09 14:47:38 /u04/oradata/lhr121/users01.dbf
[[email protected] env_oracle]$ impdp scott/tiger dumpfile=log.dmp tables=T_LOG TRANSFORM=DISABLE_ARCHIVE_LOGGING:Y remap_schema=LHR:SCOTT
Import: Release 12.1.0.2.0 - Production on Tue Apr 10 10:53:17 2018
Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
ORA-39002: invalid operation
ORA-39166: Object SCOTT.T_LOG was not found or could not be exported or imported.
[[email protected] env_oracle]$ impdp lhr/lhr dumpfile=log.dmp tables=T_LOG TRANSFORM=DISABLE_ARCHIVE_LOGGING:Y remap_schema=LHR:SCOTT
Import: Release 12.1.0.2.0 - Production on Tue Apr 10 10:53:40 2018
Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
Master table "LHR"."SYS_IMPORT_TABLE_02" successfully loaded/unloaded
Starting "LHR"."SYS_IMPORT_TABLE_02": lhr into TEST_NOLOGGING select * from test_nologging;
3264 rows created.
[email protected] > commit;
Commit complete.
[email protected] > exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[[email protected] oradata]$ mv /u01/app/oracle/oradata/ora11g/users01.dbf /u01/app/oracle/oradata/ora11g/users01.dbf_bk
[[email protected] oradata]$
[[email protected] oradata]$ sas
SQL*Plus: Release 11.2.0.3.0 Production on Tue Apr 10 14:11:34 2018
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[email protected] > startup force mount
exit
ORACLE instance started.
Total System Global Area 409194496 bytes
Fixed Size 2228864 bytes
Variable Size 322964864 bytes
Database Buffers 75497472 bytes
Redo Buffers 8503296 bytes
Database mounted.
[email protected] > Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[[email protected] oradata]$
[[email protected] oradata]$
[[email protected] oradata]$
[[email protected] oradata]$
[[email protected] oradata]$ rman target /
Recovery Manager: Release 11.2.0.3.0 - Production on Tue Apr 10 14:11:57 2018
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: ORA11G (DBID=4270446895, not open)
RMAN> restore datafile 4;
Starting restore at 2018-04-10 14:12:07
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 datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00004 to /u01/app/oracle/oradata/ora11g/users01.dbf
channel ORA_DISK_1: reading from backup piece /u05/app/oracle/flash_recovery_area/ORA11G/backupset/2018_04_10/o1_mf_nnndf_TAG20180410T132739_fdrltcot_.bkp
channel ORA_DISK_1: piece handle=/u05/app/oracle/flash_recovery_area/ORA11G/backupset/2018_04_10/o1_mf_nnndf_TAG20180410T132739_fdrltcot_.bkp tag=TAG20180410T132739
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:01:16
Finished restore at 2018-04-10 14:13:24
RMAN> recover datafile 4;
Starting recover at 2018-04-10 14:13:34
using channel ORA_DISK_1
starting media recovery
archived log for thread 1 with sequence 330 is already on disk as file /u05/app/oracle/flash_recovery_area/ORA11G/archivelog/2018_04_10/o1_mf_1_330_fdrm7pm4_.arc
archived log for thread 1 with sequence 331 is already on disk as file /u05/app/oracle/flash_recovery_area/ORA11G/archivelog/2018_04_10/o1_mf_1_331_fdrmly0v_.arc
archived log for thread 1 with sequence 332 is already on disk as file /u05/app/oracle/flash_recovery_area/ORA11G/archivelog/2018_04_10/o1_mf_1_332_fdrn29bv_.arc
archived log for thread 1 with sequence 333 is already on disk as file /u05/app/oracle/flash_recovery_area/ORA11G/archivelog/2018_04_10/o1_mf_1_333_fdrnohdf_.arc
archived log for thread 1 with sequence 334 is already on disk as file /u05/app/oracle/flash_recovery_area/ORA11G/archivelog/2018_04_10/o1_mf_1_334_fdrnwqqw_.arc
archived log file name=/u05/app/oracle/flash_recovery_area/ORA11G/archivelog/2018_04_10/o1_mf_1_330_fdrm7pm4_.arc thread=1 sequence=330
archived log file name=/u05/app/oracle/flash_recovery_area/ORA11G/archivelog/2018_04_10/o1_mf_1_331_fdrmly0v_.arc thread=1 sequence=331
archived log file name=/u05/app/oracle/flash_recovery_area/ORA11G/archivelog/2018_04_10/o1_mf_1_332_fdrn29bv_.arc thread=1 sequence=332
media recovery complete, elapsed time: 00:00:01
Finished recover at 2018-04-10 14:13:37
RMAN> alter database open;
database opened
RMAN> exit
Recovery Manager complete.
[[email protected] oradata]$ sas
SQL*Plus: Release 11.2.0.3.0 Production on Tue Apr 10 14:14:15 2018
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[email protected] > select count(1) from lhr.test_nologging;
select count(1) from lhr.test_nologging
*
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 4, block # 180937)
ORA-01110: data file 4: '/u01/app/oracle/oradata/ora11g/users01.dbf'
ORA-26040: Data block was loaded using the NOLOGGING option
[email protected] > select UNRECOVERABLE_CHANGE# ,
2 UNRECOVERABLE_TIME ,
3 FIRST_NONLOGGED_SCN ,
4 FIRST_NONLOGGED_TIME
5 from v$datafile
6 where file#=4;
UNRECOVERABLE_CHANGE# UNRECOVERABLE_TIME FIRST_NONLOGGED_SCN FIRST_NONLOGGED_TIM
--------------------- ------------------- ------------------- -------------------
60522292 2018-04-10 14:11:22 60522291 2018-04-10 14:11:22
[email protected] > select * from v$database_block_corruption;
no rows selected
[email protected] > exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[[email protected] oradata]$ rman target /
Recovery Manager: Release 11.2.0.3.0 - Production on Tue Apr 10 14:15:42 2018
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: ORA11G (DBID=4270446895)
RMAN> validate datafile 4;
Starting validate at 2018-04-10 14:15:50
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=21 device type=DISK
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
input datafile file number=00004 name=/u01/app/oracle/oradata/ora11g/users01.dbf
channel ORA_DISK_1: validation complete, elapsed time: 00:00:35
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
4 OK 103 64922 196829 60543025
File Name: /u01/app/oracle/oradata/ora11g/users01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 19747
Index 0 5352
Other 0 106779
Finished validate at 2018-04-10 14:16:26
RMAN> exit
Recovery Manager complete.
[[email protected] oradata]$ sas
SQL*Plus: Release 11.2.0.3.0 Production on Tue Apr 10 14:16:44 2018
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[email protected] > select * from v$database_block_corruption;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
---------- ---------- ---------- ------------------ ---------
4 180937 15 60522291 NOLOGGING
4 180994 88 60522292 NOLOGGING
[email protected] > exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[[email protected] oradata]$ rmant target /
-bash: rmant: command not found
[[email protected] oradata]$ rman target /
Recovery Manager: Release 11.2.0.3.0 - Production on Tue Apr 10 14:21:04 2018
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: ORA11G (DBID=4270446895)
RMAN> BLOCKRECOVER CORRUPTION LIST;
Starting recover at 2018-04-10 14:21:08
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=133 device type=DISK
starting media recovery
media recovery complete, elapsed time: 00:00:00
Finished recover at 2018-04-10 14:21:10
RMAN> exit
Recovery Manager complete.
[[email protected] oradata]$ sas
SQL*Plus: Release 11.2.0.3.0 Production on Tue Apr 10 14:21:17 2018
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[email protected] > select * from v$database_block_corruption;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
---------- ---------- ---------- ------------------ ---------
4 180937 15 60522291 NOLOGGING
4 180994 88 60522292 NOLOGGING
About Me
.............................................................................................................................................
● 本文作者：小麥苗，部分内容整理自網絡，若有侵權請聯系小麥苗删除
● 本文在itpub（http://blog.itpub.net/26736162/abstract/1/）、部落格園（http://www.cnblogs.com/lhrbest）和個人微信公衆号（xiaomaimiaolhr）上有同步更新
● 本文itpub位址：http://blog.itpub.net/26736162/abstract/1/
● 本文部落格園位址：http://www.cnblogs.com/lhrbest
● 本文pdf版、個人簡介及小麥苗雲盤位址：http://blog.itpub.net/26736162/viewspace-1624453/
● 資料庫筆試面試題庫及解答：http://blog.itpub.net/26736162/viewspace-2134706/
● DBA寶典今日頭條号位址：http://www.toutiao.com/c/user/6401772890/#mid=1564638659405826
.............................................................................................................................................
● QQ群号：230161599（滿）、618766405
● 微信群：可加我微信，我拉大家進群，非誠勿擾
● 聯系我請加QQ好友（646634621），注明添加緣由
● 于 2018-04-01 06:00 ~ 2018-04-31 24:00 在魔都完成
● 最新修改時間：2018-04-01 06:00 ~ 2018-04-31 24:00
● 文章内容來源于小麥苗的學習筆記，部分整理自網絡，若有侵權或不當之處還請諒解
● 版權所有，歡迎分享本文，轉載請保留出處
.............................................................................................................................................
● 小麥苗的微店：https://weidian.com/s/793741433?wfr=c&ifr=shopdetail
● 小麥苗出版的資料庫類叢書：http://blog.itpub.net/26736162/viewspace-2142121/
● 小麥苗OCP、OCM、高可用網絡班：http://blog.itpub.net/26736162/viewspace-2148098/
.............................................................................................................................................
使用微信用戶端掃描下面的二維碼來關注小麥苗的微信公衆号（xiaomaimiaolhr）及QQ群（DBA寶典），學習最實用的資料庫技術。
ORA-01578和ORA-26040--NOLOGGING操作引起的壞塊-錯誤解釋和解決方案(文檔ID 1623284.1)... ORA-01578和ORA-26040--NOLOGGING操作引起的壞塊-錯誤解釋和解決方案(文檔ID 1623284.1) 
ORA-01578和ORA-26040--NOLOGGING操作引起的壞塊-錯誤解釋和解決方案(文檔ID 1623284.1)... ORA-01578和ORA-26040--NOLOGGING操作引起的壞塊-錯誤解釋和解決方案(文檔ID 1623284.1) ORA-01578和ORA-26040--NOLOGGING操作引起的壞塊-錯誤解釋和解決方案(文檔ID 1623284.1)... ORA-01578和ORA-26040--NOLOGGING操作引起的壞塊-錯誤解釋和解決方案(文檔ID 1623284.1) ORA-01578和ORA-26040--NOLOGGING操作引起的壞塊-錯誤解釋和解決方案(文檔ID 1623284.1)... ORA-01578和ORA-26040--NOLOGGING操作引起的壞塊-錯誤解釋和解決方案(文檔ID 1623284.1) 小麥苗的微信公衆号 小麥苗的DBA寶典QQ群2 《DBA筆試面試寶典》讀者群 小麥苗的微店
.............................................................................................................................................
ORA-01578和ORA-26040--NOLOGGING操作引起的壞塊-錯誤解釋和解決方案(文檔ID 1623284.1)... ORA-01578和ORA-26040--NOLOGGING操作引起的壞塊-錯誤解釋和解決方案(文檔ID 1623284.1) ORA-01578和ORA-26040--NOLOGGING操作引起的壞塊-錯誤解釋和解決方案(文檔ID 1623284.1)... ORA-01578和ORA-26040--NOLOGGING操作引起的壞塊-錯誤解釋和解決方案(文檔ID 1623284.1)
版權聲明：本文為CSDN部落客「weixin_33937499」的原創文章，遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明。
原文連結：https://blog.csdn.net/weixin_33937499/article/details/91904538