数据库启动时遇到ORA-01578错误

简介:

数据库启动的时候遇到坏块,特别是SYSTEM表空间中的一些底层表,如UNDO$,OBJ$等一些表,会导致数据库不能正常open,当然我们可以通过增加一些隐藏参数来达到跳过坏块来启动数据库,也可以通过bbed工具来手动修复块来。下面是自己的一个测试环境遇到这样的错误,通过bbed工具来修复

 

欢迎大家加入ORACLE超级群:17115662 免费解决各种ORACLE问题,以后BLOG将迁移到http://www.htz.pw

 

1,数据库版本

SQL> select * from v$version;

 

BANNER

--------------------------------------------------------------------------------

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

PL/SQL Release 11.2.0.3.0 - Production

    

TNS for Linux: Version 11.2.0.3.0 - Production

NLSRTL Version 11.2.0.3.0 - Production

 

[oracle@www.htz.pw ~]$sqlplus / as sysdba

 

SQL*Plus: Release 11.2.0.3.0 Production on Sun May 25 04:36:03 2014

 

  

 

Connected to an idle instance.

 

SQL> startup

ORACLE instance started.

 

  

                  

             

           

                

Database mounted.

ORA-01092: ORACLE instance terminated. Disconnection forced

ORA-00604: error occurred at recursive SQL level 1

ORA-00607: Internal error occurred while making a change to a data block

ORA-00600: internal error code, arguments: [kdBlkCheckError], [1], [225],

[6108], [], [], [], [], [], [], [], []

Process ID: 12178

Session ID: 1 Serial number: 5

2,启动报错

[oracle@www.htz.pw ~]$sqlplus / as sysdba

 

SQL*Plus: Release 11.2.0.3.0 Production on Sun May 25 04:20:44 2014

 

  

 

Connected to an idle instance.

 

SQL> startup

ORACLE instance started.

 

  

                  

             

           

                

Database mounted.

ORA-01092: ORACLE instance terminated. Disconnection forced

ORA-00604: error occurred at recursive SQL level 1

ORA-01578: ORACLE data block corrupted (file # 1, block # 225)

ORA-01110: data file 1: '/oracle/app/oracle/oradata/orcl1123/system01.dbf'

Process ID: 1617

Session ID: 1 Serial number: 5

 

此块就是存储undo$基表的块,在数据库启动的时候,做恢复的时候,是需要去读undo块的,所以导致报错

3bbed修复坏块

BBED> verify

DBVERIFY - Verification starting

FILE = /oracle/app/oracle/oradata/orcl1123/system01.dbf

BLOCK = 225

 

Block Checking: DBA = 4194529, Block Type = KTB-managed data block

Found block already marked corrupted

 

DBVERIFY - Verification complete

 

         

Total Blocks Processed (Data) : 1

   

Total Blocks Processed (Index): 0

   

            

   

           

  

这里发现块被标记为坏块,其实这里知道就是把seq更改为FF了,下面我们修改回来就可以了

BBED> p kcbh

struct kcbh, 20 bytes                       @0      

   ub1 type_kcbh                            @0        0x06

   ub1 frmt_kcbh                            @1        0xa2

   ub1 spare1_kcbh                          @2        0x00

   ub1 spare2_kcbh                          @3        0x00

   ub4 rdba_kcbh                            @4        0x004000e1

   ub4 bas_kcbh                             @8        0x0021beaa

   ub2 wrp_kcbh                             @12       0x0000

                             

   ub1 flg_kcbh                             @15       0x04 (KCBHFCKV)

   ub2 chkval_kcbh                          @16       0x4cba

   ub2 spare3_kcbh                          @18       0x0000

 

BBED> set mode edit

        MODE            Edit

 

BBED> set count 16

        COUNT           16

 

BBED> modify /x 00 offset 14

Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y

 File: /oracle/app/oracle/oradata/orcl1123/system01.dbf (0)

 Block: 225              Offsets:   14 to   29           Dba:0x00000000

------------------------------------------------------------------------

 0004ba4c 00000100 00000f00 0000aabe

 

 <32 bytes per line>

 

 

BBED> set offset 8188

        OFFSET          8188

 

BBED> dump

 File: /oracle/app/oracle/oradata/orcl1123/system01.dbf (0)

 Block: 225              Offsets: 8188 to 8191           Dba:0x00000000

------------------------------------------------------------------------

 ff06aabe

 

 <32 bytes per line>

 

BBED> modify /x 00 offset 8188

 File: /oracle/app/oracle/oradata/orcl1123/system01.dbf (0)

 Block: 225              Offsets: 8188 to 8191           Dba:0x00000000

------------------------------------------------------------------------

 0006aabe

 

 <32 bytes per line>

 

BBED> p tailchk

                                 

 

 

BBED> sum apply

Check value for File 0, Block 225:

current = 0x4cba, required = 0x4cba

 

BBED> verify

DBVERIFY - Verification starting

FILE = /oracle/app/oracle/oradata/orcl1123/system01.dbf

BLOCK = 225

 

Block Checking: DBA = 4194529, Block Type = KTB-managed data block

data header at 0x2a98b8725c

kdbchk: row locked by non-existent transaction

   

   

Block 225 failed with check code 6101

 

DBVERIFY - Verification complete

 

         

Total Blocks Processed (Data) : 1

   

Total Blocks Processed (Index): 0

   

            

   

           

  

这里看到报了ITL相当的一些东西,原因是由于原来做实验的时候,手动提交了数据。

报错代码的意思是,slot=20的行被锁住,占用了itl2.

 

下面是dump数据库看一下第21号的lb标记符

  

  

  

  

  

  

  

  

  

  

  

  

  

col 12: *NULL*

col 13: *NULL*

col 14: *NULL*

col 15: *NULL*

  

 

BBED> p *kdbr[20]

rowdata[634]

------------

                            

 

BBED> set offset 1823

        OFFSET          1823

 

BBED> dump

 File: /oracle/app/oracle/oradata/orcl1123/system01.dbf (0)

 Block: 225              Offsets: 1823 to 1838           Dba:0x00000000

------------------------------------------------------------------------

 2c011102 c1150a5f 53595353 4d553230

BBED> modify /x 2c00

 File: /oracle/app/oracle/oradata/orcl1123/system01.dbf (0)

 Block: 225              Offsets: 1823 to 1838           Dba:0x00000000

------------------------------------------------------------------------

 2c001102 c1150a5f 53595353 4d553230

 

 <32 bytes per line>

 

 

 

BBED> sum apply

Check value for File 0, Block 225:

current = 0x6ec1, required = 0x6ec1

 

BBED> verify

DBVERIFY - Verification starting

FILE = /oracle/app/oracle/oradata/orcl1123/system01.dbf

BLOCK = 225

 

 

DBVERIFY - Verification complete

 

         

Total Blocks Processed (Data) : 1

   

Total Blocks Processed (Index): 0

   

            

   

           

  

 

块不在报错。验证通过

4,数据库正常打开

SQL> alter database open;

 

Database altered.

 

undo块能正常访问

SQL> select name from undo$;

 

NAME

------------------------------

SYSTEM

_SYSSMU1$

_SYSSMU10$

_SYSSMU11$

_SYSSMU12$

_SYSSMU13$

_SYSSMU14$

_SYSSMU15$

_SYSSMU16$

_SYSSMU17$

_SYSSMU18$

 

NAME

------------------------------

_SYSSMU19$

_SYSSMU2$

_SYSSMU20$

_SYSSMU3$

_SYSSMU4$

_SYSSMU5$

_SYSSMU6$

_SYSSMU7$

_SYSSMU8$

_SYSSMU9$

 

21 rows selected.






     本文转自7343696 51CTO博客,原文链接:http://blog.51cto.com/luoping/1416972,如需转载请自行联系原作者

相关文章
|
Java 测试技术 数据库
SpringBoot启动时设置不加载数据库
SpringBoot启动时设置不加载数据库
899 0
|
SQL Oracle 关系型数据库
Oracle数据库启动时:ORA-00119: invalid specification for system parameter LOCAL_LISTENER;
Oracle数据库启动时:ORA-00119: invalid specification for system parameter LOCAL_LISTENER;
|
缓存 Java 数据库
Springboot项目启动时加载数据库数据到内存
Springboot项目启动时加载数据库数据到内存
242 0
|
3月前
|
人工智能 运维 关系型数据库
数据库运维:mysql 数据库迁移方法-mysqldump
本文介绍了MySQL数据库迁移的方法与技巧,重点探讨了数据量大小对迁移方式的影响。对于10GB以下的小型数据库,推荐使用mysqldump进行逻辑导出和source导入;10GB以上可考虑mydumper与myloader工具;100GB以上则建议物理迁移。文中还提供了统计数据库及表空间大小的SQL语句,并讲解了如何使用mysqldump导出存储过程、函数和数据结构。通过结合实际应用场景选择合适的工具与方法,可实现高效的数据迁移。
631 1
|
4月前
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
3月前
|
SQL 关系型数据库 MySQL
Go语言数据库编程:使用 `database/sql` 与 MySQL/PostgreSQL
Go语言通过`database/sql`标准库提供统一数据库操作接口,支持MySQL、PostgreSQL等多种数据库。本文介绍了驱动安装、连接数据库、基本增删改查操作、预处理语句、事务处理及错误管理等内容,涵盖实际开发中常用的技巧与注意事项,适合快速掌握Go语言数据库编程基础。
244 62
|
2月前
|
SQL 存储 关系型数据库
MySQL功能模块探秘:数据库世界的奇妙之旅
]带你轻松愉快地探索MySQL 8.4.5的核心功能模块,从SQL引擎到存储引擎,从复制机制到插件系统,让你在欢声笑语中掌握数据库的精髓!
|
6月前
|
关系型数据库 MySQL Java
【YashanDB知识库】原生mysql驱动配置连接崖山数据库
【YashanDB知识库】原生mysql驱动配置连接崖山数据库
【YashanDB知识库】原生mysql驱动配置连接崖山数据库

热门文章

最新文章