<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>《Query Duration=0与ORA-01555》的评论</title>
	<atom:link href="https://www.xifenfei.com/2012/02/query-duration0%e4%b8%8eora-01555.html/feed" rel="self" type="application/rss+xml" />
	<link>https://www.xifenfei.com/2012/02/query-duration0%e4%b8%8eora-01555.html</link>
	<description>提供7*24专业数据库(Oracle,SQL Server,MySQL,PostgreSQL等)恢复和技术支持@Tel:17813235971</description>
	<lastBuildDate>Thu, 11 Dec 2025 02:46:14 +0000</lastBuildDate>
		<sy:updatePeriod>hourly</sy:updatePeriod>
		<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>作者：惜分飞</title>
		<link>https://www.xifenfei.com/2012/02/query-duration0%e4%b8%8eora-01555.html/comment-page-1#comment-1014</link>
		<dc:creator><![CDATA[惜分飞]]></dc:creator>
		<pubDate>Wed, 12 Sep 2012 14:48:17 +0000</pubDate>
		<guid isPermaLink="false">https://www.xifenfei.com/?p=2513#comment-1014</guid>
		<description><![CDATA[Primary Key Index Corruption Generates ORA-01555 With Small Query Duration or with Query Duration as 0 Seconds (Doc ID 977902.1)
[shell]
Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 11.2.0.3 - Release: 10.2 to 11.2
Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 11.2.0.3   [Release: 10.2 to 11.2]
Information in this document applies to any platform.
Symptoms

 When running a select statement an incorrect ORA-01555 with query_duration=0 is reported 
as a side effect of an PK index corruption under the following conditions:

* The error ORA-01555 is reported even if the database has just been restarted

* The error is always reproducible when running the select statement

* The &quot;analyze validate structure cascade&quot; command returns the same error:

SQL&gt; analyze table MIPI_OWNER.MIPI_PUBL_OBJ_DATA validate structure cascade;
analyze table MIPI_OWNER.MIPI_PUBL_OBJ_DATA validate structure cascade
*
ERROR at line 1:
ORA-01555: snapshot too old: rollback segment number 12 with name &quot;_SYSSMU12$&quot; too small

* Without cascade option the analyze command doesn&#039;t report the error:
SQL&gt; analyze table MIPI_OWNER.MIPI_PUBL_OBJ_DATA validate structure;
Table analyzed

* The &quot;analyze validate structure&quot; command executed for the PK index generates the same ORA-01555

* The trace file generated as a result of ORA-01555 with the following events set: 
SQL&gt;alter system set events &#039;10442 trace name context forever, level 1&#039;;
SQL&gt;alter system set events &#039;1555 trace name errorstack level 10&#039;;

contains the following information:

*** SERVICE NAME:(SYS$USERS) 2009-12-04 04:21:45.777
*** SESSION ID:(537.68) 2009-12-04 04:21:45.776
ORA-01555 occurred - Dump of diagnostics information
--- This does not indicate any errors
SSOLD: SQL ID: at4t8hum4xctr, Statement:
SELECT * FROM MIPI_PUBL_OBJ_DATA WHERE PUBLICATION_OBJECT_ID 
IN (&#039;PUBOB19&#039;,&#039;PUBOB20&#039;) AND APPLICABLE_FOR=TRUNC(SYSDATE) ORDER BY 1 DESC
SSOLD: Query Length = 0 (sttm=1259900505, fchtm=1259900505, curtime=1259900505) 
SSOLD: Undo Retention = 10854
SSOLD: Scan Time Dump
env: (scn: 0x0219.2e46e8a8 xid: 0x0000.000.00000000 uba: 0x00000000.0000.00 
statement num=0 parent xid: xid: 0x0000.000.00000000 
scn: 0x0000.00000000 0sch: scn: 0x0000.00000000)
................
*** 2009-12-04 04:21:51.140
ksedmp: internal or fatal error
Current SQL statement for this session:
SELECT * FROM MIPI_PUBL_OBJ_DATA WHERE PUBLICATION_OBJECT_ID IN
 (&#039;PUBOB19&#039;,&#039;PUBOB20&#039;) AND APPLICABLE_FOR=TRUNC(SYSDATE) ORDER BY 1 DESC
----- Call Stack Trace -----
calling call entry argument values in hex 
location type point (? means dubious value) 
-------------------- -------- -------------------- ----------------------------
ksedmp ktussto kturbk ktrgcm ktrget kdifxs1 qerixtFetch qertbFetchByRowID qerilFetch 
opifch2 kpoal8 opiodr ttcpip opitsk opiino opiodr opidrv sou2o opimai_real main start

Cause

The Primary Key Index is corrupted and ORA-01555 in this case is a false error.
Solution

Disable and enable the PK constraint in order to recreate the PK index associated with 
the primary key constraint and to solve the primary key index corruption.
Example :
SQL&gt; alter table MIPI_OWNER.MIPI_PUBL_OBJ_DATA disable primary key;
SQL&gt; alter table MIPI_OWNER.MIPI_PUBL_OBJ_DATA enable primary key;
[/shell]]]></description>
		<content:encoded><![CDATA[<p>Primary Key Index Corruption Generates ORA-01555 With Small Query Duration or with Query Duration as 0 Seconds (Doc ID 977902.1)</p>
<pre class="brush: bash; title: ; notranslate">
Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 11.2.0.3 - Release: 10.2 to 11.2
Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 11.2.0.3   [Release: 10.2 to 11.2]
Information in this document applies to any platform.
Symptoms

 When running a select statement an incorrect ORA-01555 with query_duration=0 is reported 
as a side effect of an PK index corruption under the following conditions:

* The error ORA-01555 is reported even if the database has just been restarted

* The error is always reproducible when running the select statement

* The &quot;analyze validate structure cascade&quot; command returns the same error:

SQL&gt; analyze table MIPI_OWNER.MIPI_PUBL_OBJ_DATA validate structure cascade;
analyze table MIPI_OWNER.MIPI_PUBL_OBJ_DATA validate structure cascade
*
ERROR at line 1:
ORA-01555: snapshot too old: rollback segment number 12 with name &quot;_SYSSMU12$&quot; too small

* Without cascade option the analyze command doesn't report the error:
SQL&gt; analyze table MIPI_OWNER.MIPI_PUBL_OBJ_DATA validate structure;
Table analyzed

* The &quot;analyze validate structure&quot; command executed for the PK index generates the same ORA-01555

* The trace file generated as a result of ORA-01555 with the following events set: 
SQL&gt;alter system set events '10442 trace name context forever, level 1';
SQL&gt;alter system set events '1555 trace name errorstack level 10';

contains the following information:

*** SERVICE NAME:(SYS$USERS) 2009-12-04 04:21:45.777
*** SESSION ID:(537.68) 2009-12-04 04:21:45.776
ORA-01555 occurred - Dump of diagnostics information
--- This does not indicate any errors
SSOLD: SQL ID: at4t8hum4xctr, Statement:
SELECT * FROM MIPI_PUBL_OBJ_DATA WHERE PUBLICATION_OBJECT_ID 
IN ('PUBOB19','PUBOB20') AND APPLICABLE_FOR=TRUNC(SYSDATE) ORDER BY 1 DESC
SSOLD: Query Length = 0 (sttm=1259900505, fchtm=1259900505, curtime=1259900505) 
SSOLD: Undo Retention = 10854
SSOLD: Scan Time Dump
env: (scn: 0x0219.2e46e8a8 xid: 0x0000.000.00000000 uba: 0x00000000.0000.00 
statement num=0 parent xid: xid: 0x0000.000.00000000 
scn: 0x0000.00000000 0sch: scn: 0x0000.00000000)
................
*** 2009-12-04 04:21:51.140
ksedmp: internal or fatal error
Current SQL statement for this session:
SELECT * FROM MIPI_PUBL_OBJ_DATA WHERE PUBLICATION_OBJECT_ID IN
 ('PUBOB19','PUBOB20') AND APPLICABLE_FOR=TRUNC(SYSDATE) ORDER BY 1 DESC
----- Call Stack Trace -----
calling call entry argument values in hex 
location type point (? means dubious value) 
-------------------- -------- -------------------- ----------------------------
ksedmp ktussto kturbk ktrgcm ktrget kdifxs1 qerixtFetch qertbFetchByRowID qerilFetch 
opifch2 kpoal8 opiodr ttcpip opitsk opiino opiodr opidrv sou2o opimai_real main start

Cause

The Primary Key Index is corrupted and ORA-01555 in this case is a false error.
Solution

Disable and enable the PK constraint in order to recreate the PK index associated with 
the primary key constraint and to solve the primary key index corruption.
Example :
SQL&gt; alter table MIPI_OWNER.MIPI_PUBL_OBJ_DATA disable primary key;
SQL&gt; alter table MIPI_OWNER.MIPI_PUBL_OBJ_DATA enable primary key;
</pre>
]]></content:encoded>
	</item>
	<item>
		<title>作者：惜 分飞</title>
		<link>https://www.xifenfei.com/2012/02/query-duration0%e4%b8%8eora-01555.html/comment-page-1#comment-671</link>
		<dc:creator><![CDATA[惜 分飞]]></dc:creator>
		<pubDate>Tue, 14 Feb 2012 03:04:29 +0000</pubDate>
		<guid isPermaLink="false">https://www.xifenfei.com/?p=2513#comment-671</guid>
		<description><![CDATA[[shell]
Applies to:
Oracle Server - Enterprise Edition - Version: 9.2.0.8
This problem can occur on any platform.

Symptoms
ORA-1555 error reported intermittently with query duration as 0 seconds.

Changes
This may be impacted by bug:5475085 currently being worked by development which identified that not all undo statistics are being updated when they should be, such as V$UNDOSTAT.EXPBLKREUCNT.
Cause
This is currently being investigated by development in bug:6799685.

Solution
Increase the size of the UNDO tablespace and increase the UNDO_RETENTION parameter value to try to prevent required undo expiring too quickly until a solution to bug:6799685 can be identified.

References
BUG:6799685 - ORA-1555 ERROR WITH QUERY DURATION=0 AND UNDO_RETENTION=1800
BUG:5475085 - V$UNDOSTAT.EXPBLKREUCNT IS NEVER INCREMENTED
[/shell]]]></description>
		<content:encoded><![CDATA[<pre class="brush: bash; title: ; notranslate">
Applies to:
Oracle Server - Enterprise Edition - Version: 9.2.0.8
This problem can occur on any platform.

Symptoms
ORA-1555 error reported intermittently with query duration as 0 seconds.

Changes
This may be impacted by bug:5475085 currently being worked by development which identified that not all undo statistics are being updated when they should be, such as V$UNDOSTAT.EXPBLKREUCNT.
Cause
This is currently being investigated by development in bug:6799685.

Solution
Increase the size of the UNDO tablespace and increase the UNDO_RETENTION parameter value to try to prevent required undo expiring too quickly until a solution to bug:6799685 can be identified.

References
BUG:6799685 - ORA-1555 ERROR WITH QUERY DURATION=0 AND UNDO_RETENTION=1800
BUG:5475085 - V$UNDOSTAT.EXPBLKREUCNT IS NEVER INCREMENTED
</pre>
]]></content:encoded>
	</item>
</channel>
</rss>
