oracle的坏块即ora-01578错,同时还可能伴随ora-01110错,这种错误对于初学者或是那些没有实践经验的dba来说无疑是非常棘手的。我当初就深受其害,写下这篇文章则是希望对大家有所帮助。
一、出问题时的情景
1、 我的一个计费的入库的进程停掉,报的便是ora-01578错,对应用相关的表tg_bill03做sql>select from tg_cdr03 where rownum<10;这样是能的,但做sql>select count(*) from tg_bill03;时则报ora-01578错。
2、 检查alter.log中看到一几条报错信息:
errors in file /oracle816/app/admin/billing/udump/ora_7281_billing.trc:
ora-01578: oracle data block corrupted (file # 126, block # 88490)
ora-01110: data file 126: /dev/vgjf7/rdata471
二、事后分析产生这种问题的原因
1、 十之八九这个oracle的数据库server打开了异步i/o(async io)或增加了写进程。
2、 硬件的i/o出现了错误。
3、 操作系统的i/o或缓存出现我问题,比如操作系统对于异步i/o的补丁没有打。
4、 手动的修改了数据文件中的数据,我模拟这个错误用的便是这种方式。
三、解决方法
这种问题的解决方法是非常多的,如果你用的是归档方式,则能基于时间点恢复来解决。不过这里介绍一种比较方便的解决方式,因为我的库没有开归档。metaline关于ora-01578的文字也非常多,不过我看过后总觉得都不那么实用,不能解决实际的问题。
1、 解决这种问题的第一步是首先你要确定是什么段、哪个段坏了,是索引还是表?
a、 打开alter.log,找到ora-01578的报错信息,并记录下file#及block的值,我这里是126和88490。
b、 执行以下语句看哪个段坏了
sql>select * from dba_extents
2 where file_id=
3 and between block_id and block_id+blocks-1;
这里的f指的是file#,b指的是block#
我的显示结果指出是tg_bill03出现了坏块。
2、如果确定下来坏的是索引段,这时你就能轻舒一口气了,只要把这个索相删除然后重建一下就能了,如果出现坏的是表段,则应往下走了。
3、 记录下这个表的建表语句
为我方便,建议使用pl/sql developer来完成,如果你没有能在http://www.allroundautomations.com/plsqldev.html去下载一个,操作步骤是这样的。
a、 以表的owner用pl/sql developer连入oracle
b、 在左面的树状栏中找到这个表tg_bill03,右击该表->view->view sql,记录下sql,以备以下步骤中重建索引。
4、 实际处理了,以我的那个表为例
a、 以tg_bill03的owner连入oracle
b、 使用诊断事件10231
sql> alter system set events ‘10231 trace name context forever,level 10’;
c、创建一个临时表tg_bill_tmp的表中除坏块的数据都检索出来
sql>create table tg_bill03_tmp as select * from tg_bill03;
c、 更名原表,并把tg_bill03_tmp为tg_bill03
sql>alter table tg_bill03 rename to tg_bill03_bak;
sql>alter table tg_bill03_tmp to tg_bill03;
d、在tg_bill03上重新创建索引、约束、授权、trigger等对象
e、 利用表之间的业务关系,把坏块中的数据补足。
四、怎么尽量减少问题及问题的损失呢
分析了产生问题的原因,我认为能采取以下几个措施
1、 在为提高性能为操作系统打开异步i/o时,一定要和oracle及操作系统技术支持联系把操作系统和异步i/o相关的补丁要打全。
2、 制定一个良好的备份恢复策略,最佳有表的exp备份
3、 要及时的检查硬件的状态,及时更换驱动器部件。
结篇:其实坏块涉及的内容非常多的,如果坏块发生的回滚段表空间、数据字典(system表空间)或联机日志,这些处理都是特难的,需要和oracle的supporter联系。不过这些方面的坏的机率非常少非常少的,在以后的文章中我也会做介绍。
一、出问题时的情景
1、 我的一个计费的入库的进程停掉,报的便是ora-01578错,对应用相关的表tg_bill03做sql>select from tg_cdr03 where rownum<10;这样是能的,但做sql>select count(*) from tg_bill03;时则报ora-01578错。
2、 检查alter.log中看到一几条报错信息:
errors in file /oracle816/app/admin/billing/udump/ora_7281_billing.trc:
ora-01578: oracle data block corrupted (file # 126, block # 88490)
ora-01110: data file 126: /dev/vgjf7/rdata471
二、事后分析产生这种问题的原因
1、 十之八九这个oracle的数据库server打开了异步i/o(async io)或增加了写进程。
2、 硬件的i/o出现了错误。
3、 操作系统的i/o或缓存出现我问题,比如操作系统对于异步i/o的补丁没有打。
4、 手动的修改了数据文件中的数据,我模拟这个错误用的便是这种方式。
三、解决方法
这种问题的解决方法是非常多的,如果你用的是归档方式,则能基于时间点恢复来解决。不过这里介绍一种比较方便的解决方式,因为我的库没有开归档。metaline关于ora-01578的文字也非常多,不过我看过后总觉得都不那么实用,不能解决实际的问题。
1、 解决这种问题的第一步是首先你要确定是什么段、哪个段坏了,是索引还是表?
a、 打开alter.log,找到ora-01578的报错信息,并记录下file#及block的值,我这里是126和88490。
b、 执行以下语句看哪个段坏了
sql>select * from dba_extents
2 where file_id=
3 and between block_id and block_id+blocks-1;
这里的f指的是file#,b指的是block#
我的显示结果指出是tg_bill03出现了坏块。
2、如果确定下来坏的是索引段,这时你就能轻舒一口气了,只要把这个索相删除然后重建一下就能了,如果出现坏的是表段,则应往下走了。
3、 记录下这个表的建表语句
为我方便,建议使用pl/sql developer来完成,如果你没有能在http://www.allroundautomations.com/plsqldev.html去下载一个,操作步骤是这样的。
a、 以表的owner用pl/sql developer连入oracle
b、 在左面的树状栏中找到这个表tg_bill03,右击该表->view->view sql,记录下sql,以备以下步骤中重建索引。
4、 实际处理了,以我的那个表为例
a、 以tg_bill03的owner连入oracle
b、 使用诊断事件10231
sql> alter system set events ‘10231 trace name context forever,level 10’;
c、创建一个临时表tg_bill_tmp的表中除坏块的数据都检索出来
sql>create table tg_bill03_tmp as select * from tg_bill03;
c、 更名原表,并把tg_bill03_tmp为tg_bill03
sql>alter table tg_bill03 rename to tg_bill03_bak;
sql>alter table tg_bill03_tmp to tg_bill03;
d、在tg_bill03上重新创建索引、约束、授权、trigger等对象
e、 利用表之间的业务关系,把坏块中的数据补足。
四、怎么尽量减少问题及问题的损失呢
分析了产生问题的原因,我认为能采取以下几个措施
1、 在为提高性能为操作系统打开异步i/o时,一定要和oracle及操作系统技术支持联系把操作系统和异步i/o相关的补丁要打全。
2、 制定一个良好的备份恢复策略,最佳有表的exp备份
3、 要及时的检查硬件的状态,及时更换驱动器部件。
结篇:其实坏块涉及的内容非常多的,如果坏块发生的回滚段表空间、数据字典(system表空间)或联机日志,这些处理都是特难的,需要和oracle的supporter联系。不过这些方面的坏的机率非常少非常少的,在以后的文章中我也会做介绍。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/15149581/viewspace-670097/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/15149581/viewspace-670097/