【翻译自mos文章】检测并解决datafile os header(Block Zero)的 损坏- - ORA-27047 DBV-107 ORA-1157/ORA-27048
2015-02-25 18:41
483 查看
怎么检测并解决datafile os header(Block Zero)的 损坏- - ORA-27047 DBV-107 ORA-1157/ORA-27048
来源于:
How to Detect and Fix a Corruption in the Datafile OS Header/Block Zero - ORA-27047 DBV-107 ORA-1157/ORA-27048 (文档 ID 360032.1)
适用于:
Oracle Database - Enterprise Edition - Version 8.0.5.0 to 12.1.0.2 [Release 8.0.5 to 12.1]
Information in this document applies to any platform.
***Checked for relevance on 02-FEB-15***
症状:
症状:
1.当 os block header 无效时,创建控制文件可能会报某一个特定datafile上的ORA-27047
下面是hpux的一个例子:
2.低于11g版本的dbv实用工具不会报数据文件上的corruption,11g的dbv 会报错误 "DBV-00107: Unknown header format"
3.database upgrade(open migrate) 或者 normal open 可能会失败,报错误: ORA-01157 ORA-27048
原因:
datafile中的OS block header (Block 0) 被损坏
1.通过Oracle 实用工具dbfsize可以辨别corruption
dbfsize辨别的其他错误还有:
2.无效的datafile copy 会导致该问题。 一个例子是当使用os命令 dd 来进行裸设备和文件系统的file copying时。 Reference Bug 4307836 (closed as not a bug) in HPUX.
3.文件系统损坏可能会导致此问题。
4.NetBackup 可能会导致该问题,请见Note:373595.1
5.Bug 4721022 / Bug 4724358 may also cause it. See Note 4724358.8
解决方案:
使用好的控制文件拷贝 open database, 并 resize datafile
1.resizing datafile 将会重新格式化 os block header
运行dbfsize 来确认block 已经被修复:
注意:resize 原大小,重建还是报错,需要resize一个不同的大小。--依据来源:http://www.cnblogs.com/rootq/archive/2012/12/12/2814579.html
2.如果是文件系统损坏导致的该问题,在该文件系统上运行fsck,可能会fix该问题。
3.解决该问题的另外一个方法就是:从backup中restore recover 受到影响的file
References
NOTE:4724358.8 - Bug 4724358 - ORA-27045 ORA-1578 ORA-27047 corruption caused by DBMS_LDAP
BUG:4721022 - ORA-27045 REPORTED INTERMITTENTLY AND WITH BLOCK CORRUPTIONS
BUG:4724358 - USING DBMS_LDAP WITH CONNECTION POOLING CAN CAUSE CORRUPTION / ORA-27045
NOTE:373595.1 - ORA-1578 ORA-27047 ORA-27048 Corrupt blocks when using RMAN / NetBackup
来源于:
How to Detect and Fix a Corruption in the Datafile OS Header/Block Zero - ORA-27047 DBV-107 ORA-1157/ORA-27048 (文档 ID 360032.1)
适用于:
Oracle Database - Enterprise Edition - Version 8.0.5.0 to 12.1.0.2 [Release 8.0.5 to 12.1]
Information in this document applies to any platform.
***Checked for relevance on 02-FEB-15***
症状:
oracle file中的os block知识: 1.The OS Block Header 是datafile 中的第一个block,它被oracle用来存储 操作系统信息。 2.它的block号是零(It is the Block Zero),而 datafile的header 的 block号是1,这两个header不是一回事。 3.Block Zero 的损坏 不会导致data的损坏,在oracle 11g之前,Block Zero的损坏不能被dbv 或者rman 检测出来。 在11g的dbv已经被改进(enhanced),11g的dbv 能检测到Block Zero的损坏。 4.dbfsize 可以用来 检测Block Zero的一致性. 注意:关于dbfsize的示例,请见我的文章:http://blog.csdn.net/msdnchina/article/details/43345445 5.当Block Zero被损坏时,有时 database可能被open起来,并且没有错误(no errors)。 Block Zero在如下情况下被检查(checked): 5.1 一些特定的数据库操作,比如'CREATE CONTROLFILE' 5.2 在11g版本中,在database 被open的过程中。
症状:
1.当 os block header 无效时,创建控制文件可能会报某一个特定datafile上的ORA-27047
ORA-27047 : unable to read the header block of file.
下面是hpux的一个例子:
ORA-1503: CREATE CONTROLFILE failed ORA-1565: error in identifying file '/oradata/users.dbf' ORA-27047: unable to read the header block of file HP-UX Error: 22: Invalid argument Additional information: 2
2.低于11g版本的dbv实用工具不会报数据文件上的corruption,11g的dbv 会报错误 "DBV-00107: Unknown header format"
3.database upgrade(open migrate) 或者 normal open 可能会失败,报错误: ORA-01157 ORA-27048
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file ORA-01110: data file 1: '/oracle/dbs/system.dbf' ORA-27048: skgfifi: file header information is invalid
原因:
datafile中的OS block header (Block 0) 被损坏
1.通过Oracle 实用工具dbfsize可以辨别corruption
$ dbfsize /oradata/users.dbf Header block magic number is bad
dbfsize辨别的其他错误还有:
/oradata/users.dbf: Header block file size is bad; trying raw file format... /oradata/users.dbf: Header block magic number is bad
2.无效的datafile copy 会导致该问题。 一个例子是当使用os命令 dd 来进行裸设备和文件系统的file copying时。 Reference Bug 4307836 (closed as not a bug) in HPUX.
3.文件系统损坏可能会导致此问题。
4.NetBackup 可能会导致该问题,请见Note:373595.1
5.Bug 4721022 / Bug 4724358 may also cause it. See Note 4724358.8
解决方案:
使用好的控制文件拷贝 open database, 并 resize datafile
1.resizing datafile 将会重新格式化 os block header
alter database datafile '/oradata/users.dbf' resize <new size>;
运行dbfsize 来确认block 已经被修复:
$ dbfsize /oradata/users.dbf Database file: /oradata/users.dbf Database file type: file system Database file size: 51200 8192 byte blocks
注意:resize 原大小,重建还是报错,需要resize一个不同的大小。--依据来源:http://www.cnblogs.com/rootq/archive/2012/12/12/2814579.html
2.如果是文件系统损坏导致的该问题,在该文件系统上运行fsck,可能会fix该问题。
3.解决该问题的另外一个方法就是:从backup中restore recover 受到影响的file
References
NOTE:4724358.8 - Bug 4724358 - ORA-27045 ORA-1578 ORA-27047 corruption caused by DBMS_LDAP
BUG:4721022 - ORA-27045 REPORTED INTERMITTENTLY AND WITH BLOCK CORRUPTIONS
BUG:4724358 - USING DBMS_LDAP WITH CONNECTION POOLING CAN CAUSE CORRUPTION / ORA-27045
NOTE:373595.1 - ORA-1578 ORA-27047 ORA-27048 Corrupt blocks when using RMAN / NetBackup
相关文章推荐
- 【翻译自mos文章】当 在os上的datafile已经不存在的情况下 将该tablespace删除
- 【翻译自mos文章】解释 datafile name中的MISSING关键字
- 【翻译自mos文章】在不同au size的asm diskgroup 之间move datafile
- 【翻译自mos文章】怎么获得datafile备份的 增长信息
- 【翻译自mos文章】 在错误的从os级别remove掉 trace file 之后,怎么找到该trace file的内容?
- 【翻译自mos文章】在rac中,使用asmcmd命令从 文件系统 move system datafile 到asm磁盘组的方法
- 【翻译自mos文章】V$BACKUP_DATAFILE 中显示file#=0 有损坏
- 【翻译自mos文章】使用aum( Automatic Undo Management) 时遇到 ORA-01555错误--- 原因和解决方式。
- 【翻译自mos文章】 在错误的从os级别remove掉 trace file 之后,怎么找到该trace file的内容?
- 【翻译自mos文章】怎么检查Oracle GoldenGate(OGG)的checkpoint file 是否被locked?
- 【翻译自mos文章】使用aum( Automatic Undo Management) 时遇到 ORA-01555错误--- 原因和解决方案。
- 【翻译自mos文章】运行utlpwdmg.sql之后报ORA-28003, ORA-20001, ORA-20002, ORA-20003, ORA-20004 错误
- 【翻译自mos文章】注意: ASMB process exiting due to lack of ASM file activity
- ORA-1157, cannot identify/lock data file - see DBWR trace file
- 【精】ORA-01157: cannot identify/lock data file 6 - see DBWR trace file ORA-01110: 解决方法
- 【翻译自mos文章】对于每一个文件的 file.id and file.incarnation number,重命名文件别名
- 【翻译自mos文章】Weblogic AdminServer 启动fail,报错为"unable to get file lock, will retry"
- 【翻译自mos文章】使用asmcmd命令在本地和远程 asm 实例之间 拷贝asm file的方法
- 【翻译自mos文章】在11gR2/12c 的GI中,ORA_CRS_HOME 环境变量必须被unset
- ORA-01210: data file header is media corrupt