请教各位：
HP-UX   10.2.0.4
同一个简单的SQL连续报ORA-01555错误。
以下是几天来的ALERT


Mon Dec 20 05:24:44 2010
ORA-01555 caused by SQL statement below (SQL ID: b208194bau9bp, Query Duration=189816 sec, SCN: 0x0ae9.42118553):
Mon Dec 20 05:24:44 2010
SELECT TRADE_ID, USER_ID ,CUST_ID ,RSRV_STR3 FROM TI_B_TRADE_IN


Tue Dec 21 05:20:38 2010
ORA-01555 caused by SQL statement below (SQL ID: b208194bau9bp, Query Duration=189749 sec, SCN: 0x0ae9.48bc2971):
Tue Dec 21 05:20:38 2010
SELECT TRADE_ID, USER_ID ,CUST_ID ,RSRV_STR3 FROM TI_B_TRADE_IN


Thu Dec 23 02:53:54 2010
ORA-01555 caused by SQL statement below (SQL ID: b208194bau9bp, Query Duration=180942 sec, SCN: 0x0ae9.564e1288):
Thu Dec 23 02:53:54 2010
SELECT TRADE_ID, USER_ID ,CUST_ID ,RSRV_STR3 FROM TI_B_TRADE_IN

Sun Dec 26 20:49:32 2010
ORA-01555 caused by SQL statement below (SQL ID: b208194bau9bp, Query Duration=158928 sec, SCN: 0x0ae9.7edff500):
Sun Dec 26 20:49:32 2010
SELECT TRADE_ID, USER_ID ,CUST_ID ,RSRV_STR3 FROM TI_B_TRADE_IN

但我查看这个表并不大，怎么能这么准的引起ORA-1555错误呢

SQL> select owner,bytes/1024/1024,tablespace_name from DBA_segments where segment_name='TI_B_TRADE_IN';
OWNER                          BYTES/1024/1024 TABLESPACE_NAME
------------------------------ --------------- ------------------------------
UCR_CRM1                                     2 TBS_CRM_DCHNL
SQL>

SQL> select count(*) from UCR_CRM1.TI_B_TRADE_IN;
  COUNT(*)
----------
     12696
SQL>



SQL> select owner,index_name,status from dba_indexes where table_name='TI_B_TRADE_IN';
OWNER                          INDEX_NAME                     STATUS
------------------------------ ------------------------------ --------
UCR_CRM1                       IDX_TI_B_TRADE_IN              VALID
SQL>

你的undo没有损坏过吗？

Sun Dec 26 20:49:32 2010
ORA-01555 caused by SQL statement below (SQL ID: b208194bau9bp, Query Duration=158928 sec, SCN: 0x0ae9.7edff500):
Sun Dec 26 20:49:32 2010
SELECT TRADE_ID, USER_ID ,CUST_ID ,RSRV_STR3 FROM TI_B_TRADE_IN
执行时间很长啊。

UNDO应该是正常的
是个比较繁忙的系统

Duration=158928 sec这个我不太明白是什么意思
这个时间是是从开始执行到结束的时间吗，我用sys用户SELECT 一下，很快就完成了，也没报错。
还有项老师
我做了个autotrace
但行数一个是8019一个是12696，这正常吗

SQL> SELECT TRADE_ID, USER_ID ,CUST_ID ,RSRV_STR3 FROM UCR_CRM1.TI_B_TRADE_IN;

12696 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 2421556737

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

| Id  | Operation         | Name          | Rows  | Bytes | Cost (%CPU)| Time
  |

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

|   0 | SELECT STATEMENT  |               |  8019 |   227K|    55   (0)| 00:00:0
1 |

|   1 |  TABLE ACCESS FULL| TI_B_TRADE_IN |  8019 |   227K|    55   (0)| 00:00:0
1 |

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



Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
       1084  consistent gets
        244  physical reads
          0  redo size
     550385  bytes sent via SQL*Net to client
       9798  bytes received via SQL*Net from client
        848  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      12696  rows processed

SQL>

1、重新收集这张表的统计信息
2、alter system set undo_retention=大一些，如1800
alter tablespace <undo tablespace> retention guarantee
3、增加undo表空间的大小

谢谢回复

统计信息每晚自动收集的，应该是正确的。我不明白的是这个表并不大啊
retention以前就是1800，
undo大小是80G左右，应该够用的，其它更大的事务都OK。

我现在不明白的是，用sys执行这个SELECT很轻松的通过了，但为什么老出现ORA-01555呢

按照官方的说法，Query Duration说的是从查询开始到出现问题所经历的时间。
但是这个值好像不正确，我们可以使用发生错误的时间-scn对应的时间（也就是查询开始的时间）（26 20:49:32 2010-SCN: 0x0ae9.7edff500）（scn需要进行时间换算）。
select scn_to_timestamp(to_number('scn','xxxxxxxx')) from dual;

将session重新连接一下，问题可能会解决。