refine 发表于 2010-12-27 13:19:49

连续的ORA-01555错误

请教各位：
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>


oraunix 发表于 2010-12-27 13:45:10

你的undo没有损坏过吗？

oraunix 发表于 2010-12-27 13:51:09

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
执行时间很长啊。

refine 发表于 2010-12-27 14:25:34

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

SQL>

chenyu 发表于 2010-12-27 16:16:17

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

refine 发表于 2010-12-28 10:51:10

谢谢回复

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

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

oraunix 发表于 2010-12-28 17:44:31

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

oraunix 发表于 2010-12-28 17:54:51

将session重新连接一下，问题可能会解决。
页: [1]
查看完整版本: 连续的ORA-01555错误