1.Oracle ORA-01555快照过旧的错误首先了解Oracle在什么情况下会产生ORA-01555错误:假设有一张6000万行数据的testdb表，预计testdb全表扫描1次需要2个小时，参考过程如下：1、在1点钟，用户A发出了select * from testdb;此时不管将来testdb怎么变化，正确的结果应该是用户A会看到在1点钟这个时刻的内容。
2、在1点30分，用户B执行了update命令，更新了testdb表中的第4100万行的这条记录，这时，用户A的全表扫描还没有到达第4100万条。
毫无疑问，这个时候，第4100万行的这条记录是被写入了回滚段，假设是回滚段UNDOTS1，如果用户A的全表扫描到达了第4100万行，是应该会正确的从回滚段UNDOTS1中读取出1点钟时刻的内容的。
3、这时，用户B将他刚才做的操作提交了，但是这时，系统仍然可以给用户A提供正确的数据，因为那第4100万行记录的内容仍然还在回滚段UNDOTS1里，系统可以根据SCN到回滚段里找到正确的数据，但要注意到，这时记录在UNDOTS1里的第4100万行记录已经发生了重大的改变：就是第4100万行在回滚段UNDOTS1里的数据有可能随时被覆盖掉，因为这条记录已经被提交了！4、由于用户A的查询时间漫长，而业务在一直不断的进行，UNDOTS1回滚段在被多个不同的transaction使用着，这个回滚段里的extent循环到了第4100万行数据所在的extent，由于这条记录已经被标记提交了，所以这个extent是可以被其他transaction覆盖掉的！5、到了1点45分，用户A的查询终于到了第4100万行，而这时已经出现了第4条说的情况，需要到回滚段UNDOTS1去找数据，但是已经被覆盖掉了，这时就出现了ORA-01555错误。
原因分析："报表"程序执行时间漫长，在程序查询的过程中其他用户对"报表"进行了更新，被更新的数据写入了回滚段，当程序到回滚段找数据时，发现数据已经被覆盖掉，于是就出现了ORA-01555错误。
另外"报表"程序执行效率不高也会造成ORA-01555错误。
解决办法：1、扩大回滚段，因为回滚段是循环使用的，如果回滚段足够大，那么那些被提交的数据就能保存足够长的时间，使那些大事务完成一致性读取。
之前EBS系统UNDO表空间为9GB，目前为10GB。
见下图:2、增加undo_retention时间，因为UNDO回滚段是循环使用，里面的数据可能随时被循环覆盖掉，如果设置undo_retention时间更长，那么在retention规定的时间内，任何其他事务都不能覆盖这些数据。
目前EBS系统undo_retention为10800秒(3个小时)。
见下图：3、最重要的一点就是优化程序相关查询语句，减少查询语句的一致性读，降低读取不到回滚段数据的风险。
所有的出错信息都会纪录到数据库日志alert_PROD.log文件中，下图红线部分是一条SQL查询词句，ORA-01555很有可能是这条语句造成，把这条语句提供给开发人员来分析和优化程序代码。
ORA-01578racle的坏块即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<sid>.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<sid>.log，找到ORA-01578的报错信息，并记录下file#及block的值，我这里是126和88490。
B、执行以下语句看哪个段坏了SQL>Select * from dba_extents2 where file_id=<F>3 and <B> between block_id and block_id+blocks-1;这里的F指的是file#,B指的是block#我的显示结果指出是tg_bill03出现了坏块。
2、假如确定下来坏的是索引段，这时你就可以轻舒一口气了，只要把这个索相删除然后重建一下就可以了，假如出现坏的是表段，则应往下走了。
3、记录下这个表的建表语句为我方便，建议使用PL/SQL Developer来完成，假如你没有可以在/plsqldev.Html去下载一个，操作步骤是这样的。
A、以表的owner用pl/sql developer连入oracleB、在左面的树状栏中找到这个表tg_bill03,右击该表->view->View SQL,记录下sql，以备以下步骤中重建索引。
4、实际处理了，以我的那个表为例A、以tg_bill03的owner连入oracleB、使用诊断事件10231SQL> 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_bill03SQL>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、要及时的检查硬件的状态，及时更换驱动器部件。
ORA-01548: 已找到活动回退段'_SYSSMU1$'，终止删除表空间的解决办法出现原因：在oracle的服务期控制台直接进行了数据文件的脱离的操作，提示如下：ORA-01145:除非启用了介质恢复,否则不允许紧急脱机ALTER DATABASEDATAFILE 'E:\ORACLE\ORADATA\SHAOMF\UNDOTBS01.DBF' OFFLINE DROP;症状：删除回滚段表空间（drop tablespace undotbs1 including contents）的时候报下面的错ORA-01548: 已找到活动回退段'_SYSSMU1$'，终止删除表空间处理过程：1 create undo tablespace undotBS2 datafile'E:\oracle\oradata\shaomf\UNDOTBS2.DBF' size 100m;alter system set undo_tablespace=undotBS2;drop tablespace undotbs1 including contents;(进行这部操作的时候会报下面的错)：ORA-01548: 已找到活动回退段'_SYSSMU1$'，终止删除表空间2 修改文件E:\oracle\admin\shaomf\pfile\init.ora.162007221035，如下：undo_management=manualundo_retention=10800undo_tablespace=undotBS2_CORRUPTED_ROLLBACK_SEGMENTS=(_SYSSMU1$,_SYSSMU2$,_SYSSMU3$,_SYSSMU3$,_SYSSMU4$,_SYSSMU5$,_SYSSMU 6$,_SYSSMU7$,_SYSSMU8$,_SYSSMU9$,_SYSSMU10$)3 启动服务startup pfile=E:\oracle\admin\shaomf\pfile\init.ora.1620072210354 删除表空间drop tablespace undotbs1 including contents;create undo tablespace undotBS1 datafile'E:\oracle\oradata\shaomf\UNDOTBS01.DBF' size 200m;drop tablespace undotBS2 including contents;5 修改init.ora.162007221035，如下：undo_management=autoundo_retention=10800undo_tablespace=undotBS1#_CORRUPTED_ROLLBACK_SEGMENTS=(_SYSSMU1$,_SYSSMU2$,_SYSSMU3$,_SYSSMU3$,_SYSSMU4$,_SYSSMU5$,_SYSSMU 6$,_SYSSMU7$,_SYSSMU8$,_SYSSMU9$,_SYSSMU10$)6 关闭服务，并且用下面的命令重新启动服务startup pfile=E:\oracle\admin\shaomf\pfile\init.ora.1620072210357 拷贝spfile文件，原先的spfile文件做好备份create spfile='E:\oracle\ora92\database\SPFILESHAOMF.ORA' FROMpfile='E:\oracle\admin\shaomf\pfile\init.ora.162007221035';8 关闭服务器，重新启动服务器，即可。