是不是oralce应当有alert日志，里面有记录不？一般报错的有可能会有事件日志的。看看是否有记录数据的file id#,block#等信息？
10年积累的网站建设、成都网站制作经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先网站设计后付款的网站建设流程，更有陆港免费网站建设让你可以放心的选择与我们合作。
AWR（ Automatic Workload Repository ）报告是对oracle的性能评定以及发现问题SQL语句的重要手段。 AWR报告的原理是基于oracle数据库的定时镜像功能。默认情况下，Oracle数据库后台进程会以一定间隔（一小时）收集系统当前状态镜像
这时候需要找出造成异常阻塞的session并清除。
oracle session通常具有三个特征：
（1）一个session可能阻塞多个session；
（2）一个session最多被一个session阻塞；
（3）session阻塞关系不会形成环路。（环路即死锁，oracle能自动解除）
因此session的阻塞关系为一棵树，进而DB系统所有session的BLOCK阻塞关系是一个由若干session阻塞关系树构成的森林，而异常session一定会在故障爆发时成为根（root）。因此，找寻异常锁表session的过程就是找出异常的root。
一般认为异常root有两个特征：（1）block树的规模过大，阻塞树规模即被root层层阻塞的session总数；（2）阻塞的平均等待时间过长。
查找异常session的方法一：
OEM— performance— Blocking Sessions
查找异常session的方法二：
select r.root_sid, s.serial#,
r.blocked_num, r.avg_wait_seconds,
s.username,s.status,s.event,s.MACHINE,
s.PROGRAM,s.sql_id,s.prev_sql_id
from (select root_sid, avg(seconds_in_wait) as avg_wait_seconds,
count(*) - 1 as blocked_num
from (select CONNECT_BY_ROOT sid as root_sid, seconds_in_wait
from v$session
start with blocking_session is null
connect by prior sid = blocking_session)
group by root_sid
having count(*) 1) r,
v$session s
where r.root_sid = s.sid
order by r.blocked_num desc, r.avg_wait_seconds desc;
该SQL语句即是根据v$session的字段blocking_session统计阻塞树根阻塞session的计数以及平均阻塞时间、并进行排序，排名最前的往往是异常session。
解决Oracle测试数据库中的ORA-1555错误:
现象：
应用的夜维从夜里00:00开始执行，但因为hang的原因(暂时猜测为夜维处理的某条数据和当前应用正常处理的某条数据相同，出现前后等待同一资源锁的现象)，直到第二天白天09:25左右才继续执行，但此时应用日志记录：
snapshot too old: rollback segment number 29 with name "_SYSSMU29$" too small
原因分析：
因hang导致夜维的DELETE语句一直处于等待状态(超过一天)，直到资源锁释放，但此时由于开始存放于UNDO中的前镜像超过UNDO_RETENTION参数设置的时间，且这是高并发的一个系统，很快可能就会被应用session覆盖UNDO中的记录，导致无法找到UNDO中的记录产生一致性读，因此报错ORA-1555，此次执行失败。
引申：
不过从这个报错现象可以接触到ORA-1555这个经典的错误号，尤其是在生产中，也是一种不多见的情况，尤其在现在UNDO基本都是用Oracle自动管理方式，且磁盘空间分配都比较大的情况下。
这个ORA-1555的错误是Oracle回滚段错误中的一种经典。UNDO用于记录DML操作数据的前镜像，ORA-1555的错误简单用一句话总结，我觉得就是当DML语句需要用UNDO记录的数据找到前镜像时，该记录已经被覆盖，导致无法利用UNDO中的记录完成一致性读。当然Oracle也有UNDO_RETENTION等参数避免这种情况的产生，但仍旧可能发生，原因有多种，解决方法也有多种，下面就简单说明介绍下。
从原因来讲，ORA-1555的错误原因归为两种，一是一致性读，一个是延迟块(锁)清除。
连接数据库服务器
(1) 启动服务器端监听器与数据库服务
Linux/Unix下，启动监听器：
$ lsnrctl start
关闭监听器：
$ lsnrctl stop
查看监听状态：
$ lsnrctl status
启动数据库：
$ sqlplus /nolog
SQLconn sys@myoracle as sysdba --这里的myoracle是前面配置的客户端本地服务名
或
SQLconn / as sysdba
SQLstartup
Windows下，启动监听器：
C:lsnrctl start
启动Oracle实例服务：
C:oradim ?a href="" class="none" title="cs" rel="external"cstartup –sid myoracle
关闭Oracle实例服务：
C:oradim –shutdown –sid myoracle
以上服务必须同时启动，客户端才能连接数据库。由于默认配置的监听器名称是Listener，上述命令可以正常启动监听器，如果监听器名称是其它名称，如aListener，则需要用下列方式才能启动：
Linux/Unix下：
$ lsnrctl start aListener
Windows下：
C:lsnrctl start aListener
(2) 测试连接数据库服务器
测试的方法多种多样，可以在上面配置本地服务名时进行测试，也可以是第三方客户端工具，如PL/SQL Developer，最方便的是用Oracle自带的sqlplus工具，以下利用sqlplus进行测试：
C:sqlplus /nolog
SQLconn zgh@myoracle
已连接。
方法一, 直接抛
SQL DECLARE
2 -- 测试异常.
3 e_test_exception EXCEPTION;
4 BEGIN
5
6 -- 直接抛出异常，测试下面的捕获
7 RAISE e_test_exception;
8
9 EXCEPTION
10 WHEN e_test_exception THEN
11 dbms_output.put_line('Test Error !');
12 WHEN OTHERS THEN
13 dbms_output.put_line('OTHERS Error!');
14 END;
15 /
Test Error !
PL/SQL procedure successfully completed.
方法二, 定义个错误代码与消息后， 再抛。
SQL BEGIN
2 -- 错误代码允许的范围是 -20,000～20,999
3 RAISE_APPLICATION_ERROR(-20000, 'My Error Happen!');
4
5 EXCEPTION
6 WHEN OTHERS THEN
7 dbms_output.put_line('Error Code = ' || TO_CHAR(SQLCODE) );
8 dbms_output.put_line('Error Message = ' || SQLERRM );
9 END;
10 /
Error Code = -20000
Error Message = ORA-20000: My Error Happen!
PL/SQL procedure successfully completed.