ORA-01555: table Re-org

Hi,
While doing Re-org ,we getting Ora-01555.We using 11g.
Alter table CMAR.HISTT move;
ERROR at line 1:
ORA-01555: snapshot too old: rollback segment number 85 with name "_SYSSMU85_4050276716$" too small.
Can we restart again?
Thanks

user13809017 wrote:
Hi,
While doing Re-org ,we getting Ora-01555.We using 11g.
Alter table CMAR.HISTT move;
ERROR at line 1:
ORA-01555: snapshot too old: rollback segment number 85 with name "_SYSSMU85_4050276716$" too small.
Can we restart again?I give up.
Can you?
I would expect the same error as log as DML occurs against CMAR.HISTT table

Similar Messages

ORA-01555 while gathering table statistics

Hello All,
While running a job to gather table statics it failed and I saw in my alert logs ORA-01555, below is the job:
DBMS_STATS.GATHER_TABLE_STATS (SCHEMA_NAME, TABLE_NAME, PARTITION_NAME, ESTIMATE_PERCENT => DBMS_STATS.AUTO_SAMPLE_SIZE, METHOD_OPT=> 'FOR ALL COLUMNS SIZE AUTO');What is the reason behind the ORA-01555 ?
How can I prevent it in the future ?
Regards,

There are two queries,
Below query for optimal undo size based on your undo retention
select d.undo_size / (1024 * 1024) "ACTUAL UNDO SIZE (MEGS)",
substr(e.value, 1, 25) "UNDO RETENTION (Secs)",
(to_number(e.value) * to_number(f.value) * g.undo_block_per_sec) /
(1024 * 1024) "NEEDED UNDO SIZE (MEGS)"
from (select sum(a.bytes) undo_size
from v$datafile a, v$tablespace b, dba_tablespaces c
where c.contents = 'UNDO'
and c.status = 'ONLINE'
and b.name = c.tablespace_name
and a.ts# = b.ts#) d,
v$parameter e,
v$parameter f,
(select max(undoblks / ((end_time - begin_time) * 3600 * 24)) undo_block_per_sec
from v$undostat) g
where e.name = 'undo_retention'
and f.name = 'db_block_size';
Below is the result from my database;
        ACTUAL UNDO SIZE (MEGS)     UNDO RETENTION (Secs)     NEEDED UNDO SIZE (MEGS)
       20860                     900          955.6171875
Another query is based how much undo retention you have to configure as per the undo size
select d.undo_size / (1024 * 1024) "ACTUAL UNDO SIZE (MEGS)",
substr(e.value, 1, 25) "UNDO RETENTION (Secs)",
round((d.undo_size / (to_number(f.value) * g.undo_block_per_sec))) "OPTIMAL UNDO RETENTION (Secs)"
from (select sum(a.bytes) undo_size
from v$datafile a, v$tablespace b, dba_tablespaces c
where c.contents = 'UNDO'
and c.status = 'ONLINE'
and b.name = c.tablespace_name
and a.ts# = b.ts#) d,
v$parameter e,
v$parameter f,
(select max(undoblks / ((end_time - begin_time) * 3600 * 24)) undo_block_per_sec
from v$undostat) g
where e.name = 'undo_retention'
and f.name = 'db_block_size';
Below is the result from my database;
        ACTUAL UNDO SIZE (MEGS)     UNDO RETENTION (Secs)     OPTIMAL UNDO RETENTION (Secs)
     20860                           900                         19646
BTW, have you tried again by executing the same ?Yes with no problem, it only happened once
In the link you mention I read the below
"The ORA-1555 happens when people try to save space typically. They'll have small
rollback segments that could grow if they needed (and will shrink using OPTIMAL). So,
they'll start with say 10 or so 1meg rollback segments. These rollback segments COULD
grow to 100meg each if we let them (in this example) however, they will NEVER grow unless
you get a big transaction.
If your database does lots of little transactions, the RBS will never grow on their own.
They will stay small.
Now, someone needs to run a query that will take 5 minutes. On your system however the
rollback wraps every 2 minutes due to lots of little transactions going on. In this
system, ORA-1555's will happen frequently. What you need to do here is size rollback so
that it wraps less frequently (less frequently then your long running queries). Here if
I sized the rollback so that I had 10, 10meg segments (not so they could GROW to 10meg
but that they are starting at 10meg) we would wrap maybe every 20minutes now. that'll
give that 5minute query plenty of time to complete without reusing rollback it needs.
I Think this is exactly my case, how can I resize my redo segments ? and how can I check its current size?

Diagnosing ORA-01555: what table had the unreconstructable block?

We have some very long-running batch processes (i.e. > 20 hours for a single INSERT statement) and we sometimes get ORA-01555 (snapshot too old) failures. Our undo_retention is 10800 seconds=3 hours.
We have discussed (with the development team) the combination of events that are needed for this situation to arise. They are unable to think of a situation where any of the tables (in today's incident, there are 7 of them) would have been updated after this job started.
Is there a method for analyzing the trace file to determine which table had the block that could not be reconstructed due to overwritten UNDO? This might give us ideas for how to avoid this via operational changes (i.e. changing the job schedule).
Of course, we are also pursuing tuning efforts for this query.
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
PL/SQL Release 10.2.0.5.0 - Production
CORE 10.2.0.5.0 Production
TNS for Solaris: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production
Thanks,
Mike

Well you could still check to see if there are any uncommitted transactions for those tables:
Query the DBA_DML_LOCKS view (and/or DDL view)
http://docs.oracle.com/cd/E11882_01/server.112/e25513/statviews_3157.htm
select * from DBA_DML_LOCKS
SESSION_ID,OWNER,NAME,MODE_HELD,MODE_REQUESTED,LAST_CONVERT,BLOCKING_OTHERS
10,SCOTT,EMP_READ_ONLY,Row-X (SX),None,1163,Not Blocking
69,SCOTT,EMP_READ_ONLY,Row-X (SX),None,1648,Not Blocking
That shows that two session are holding exclusive row lock on the EMP_READ_ONLY TABLE. As a test I inserted a row from two different sessions but did NOT commit it yet.
The DDL version of the view can be used in addition.
See my reply Sep 4, 2013 12:23 AM in this thread from yesterday for more info.
https://forums.oracle.com/message/11174417#11174417
At least in 10g you can tell before you start if there are any issues to resolve. If there are no issues then once you start your query there won't be any issues that could cause the snapshot problem since your query will be first in line.

ORA-01555 in importing table

i have used a script to export a table from a database located in a machine and i'm importing the content of the table to another machine.
The table has 207 7390260 records.
But in the process of importing the data, it occurs the error: ORA-01555: snapshot too old: rollback segment number 2 with name "_SYSSMU2$" too small.
i've tried to change my undo_retention parameter to 1800, but the error continues to occur. i'm not sure if i can increase the undo_retention to a much bigger size. can i?
I'm using oracle 10g
here are some information about the undo tablespace:
AUTOEXT Tablespace Name File Name Size (M) Size (MaxMBytes) Used (M) Free (M)
YES UNDOTBS1 undotbs01.dbf 6000 131071,94 15,25 5967,88

there is no information in the alert.log about the query.
i only have a log file created that says:
ORA-39125: Worker unexpected fatal error in KUPW$WORKER.GET_TABLE_DATA_OBJECTS while calling DBMS_METADATA.FETCH_XML_CLOB [TABLE_DATA:"SCHEMA"."TABLE1":"D090502H1559"]
ORA-01555: snapshot too old: rollback segment number 2 with name "_SYSSMU2$" too small
ORA-06512: at "SYS.DBMS_METADATA", line 1546

Why ORA-01555 (Snapshot too old) occures on an unchanged table

Hello,
we have to add a not null column into a large table. The simple update is not good, due to UNDO space.
alter table T add F INTEGER default 0 not null;
ORA-30036: unable to extend segment by in undo tablespace ''It is OK. (We cannot use create + insert + drop + rename due to not enough free space. The table is not partitioned current) So we try this script:
--create the column without default and not null
alter table T add F INTEGER;
--create temp table with the rowids of T (nologging -> minimal log)
create table TMP (row_id rowid) nologging;
--save the rowid-s. (direct -> minimal undo usage)
insert /*+APPEND*/ into TMP(row_id) select rowid from T;
commit;
--the "insert method"
--set the column to "0" with frequently commit
declare
i integer := 0;
commit_interval integer := 10000;
begin
for c in (select * from TMP) loop
    update T set F=0 where rowid=c.row_id;
    i := i + 1;
    if( mod(i,commit_interval)=0) then commit;
    end if;
end loop;
commit;
end;
--set to not-null
alter table T modify F default 0 not null;
--drop the temp table
drop table TMP;the insert method occures
ORA-01555: Snapshot too old (in row 5)The row 5 is the cursor "select * from TMP" in the insert method. The undo usage of this method is below 2 MB.
My question is:
Why oracle need snapshot, while the TMP table does not change during the insert method? The TMP table was populated and commited before the insert method. Why oracle try to read the rows of the TMP table from the undo tablespace?
Thx: lados.

Thank, I have read this article, but there is something, what I don't understand.
As I see, the DML does not clear all the modified datablock header, but it clears only the rollback segment slots. Only the next SQL (even if this is a query) clears the datablock header. This next SQL can clear only when the info is still available in the rollback segment, else ORA-1555 occures.
My question is:
What happens when the next SQL comes only one year later on this block? I don't believe that oracle doesn't handle this situation, but I didn't find how it is handled.
Thx: lados.

ORA-01555 and v$undostat


Hi,
My application was getting ORA-01555 (this is confirmed in alert.log).
When I query v$undostat for the involved period:

<blockquote>

select UnxpStealCnt, UnxpBlkRelCnt, UnxpBlkReuCnt, ExpStealCnt, ExpBlkRelCnt, ExpBlkReuCnt, NoSpaceErrCnt
from v$undostat where SSoldErrCnt != 0

</blockquote>

I do not understand why all theses columns have a zero value.
I was expecting to have at least 1 in ExpBlkReuCnt or in ExpStealCnt.
How is it possible to have (because I have) ORA-01555 without any value in thoses columns ?
Thanks for your bright explanations,
Leo.

Edited by: Leo Anderson on 24 oct. 2008 10:28

Leo Anderson wrote:
During the "fatal" period, the MaxQueryLen = 6000 and the Tuned_UndoRetention = 6800
All columns UnxpStealCnt, UnxpBlkRelCnt, UnxpBlkReuCnt, ExpStealCnt, ExpBlkRelCnt, ExpBlkReuCnt, NoSpaceErrCnt has zero value
So, I presume increasing undo_retention parameter will have no effect ?
But why no columns has non-zero value ? (in particular ExpBlkReuCnt)
EDIT : The datafile underlying my UNDOTBS is autoextensible, and bytes/maxbytes is about 32% so it could still grow
In this case I would assume that you might suffer from an ORA-01555 due to "delayed block cleanout". This errors occurs if delayed block cleanout is being performed, the transaction slot has been overwritten and some other conditions apply. For a very good explanation under what circumstances this could happen, read MetaLink note 45895.1 (although the note applies to manual rollback segment management the explanation of the "delayed block cleanout" case still applies to automatic undo management, but the solutions mentioned there do not)
You can check if your query generates a lot of redo (and you can make sure that this redo is not generated by some other DML of the same session) then it performs "delayed block cleanout".
The best solution to prevent this from happening is to attempt to generate "clean" blocks right from the start, e.g. by using direct-path inserts (APPEND hint) or Create Table As Select (CTAS). This way you prevent the "delayed block cleanout" from happening.
Other means are performing full table scans on the modified object, e.g. by gathering statistics using DBMS_STATS or explicitly running a query on the object using a full table scan right after large modifications.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

ORA-01555: snapshot too old

Hi,
We have audit component, one responsibility of which is to archive audit messages from Oracle database. The component fails on a simple select statement (provided below) that retrieves number of records to be archived based on age parameter:
SELECT COUNT(*) FROM blobobjtable blbt, auditmessagetable msgt WHERE msgt.blobobjtablepk = blbt.blobobjtablepk AND trunc(to_number(substr((SYSTIMESTAMP-msgt.credtimeutc),1,instr(SYSTIMESTAMP-msgt.credtimeutc,' ')))) >= age
We tried the following 3 select statements directly from SQL Plus. The result was that the first two succeeded and the last one failed with "ORA-01555: snapshot too old" exception. We tried these select statements after restart of Oracle database but still got last select statement failed. One thing that we noticed was that the last select statement takes extremely long time to complete. Also, analyzing the index table used during the join failed with the same exception. The same is true when the primary key indices are analyzed.
1) select count(*) from blobobjtable
2) select count(*) from auditmessagetable
3) select count(*) from blobobjtable blbt, auditmessagetable msgt WHERE msgt.blobobjtablepk = blbt.blobobjtablepk
Can somebody explain what might be the cause of ORA-01555 exception for such simple select statement? Does Oracle persists information of UNDO buffers before restart? Is there any way to clean UNDO buffers manually?
If somebody has experience in resolving "ORA-01555: snapshot too old" exception problem please share you experience with us. Any help will be appreciated.
Thanks,
Aleks

how many rows in ur tables.
select count(*) from blobobjtable blbt
SQL> show parameter undo
NAME                                 TYPE        VALUE
undo_management                      string      AUTO
undo_retention                       integer     300
undo_tablespace                      string      UNDOTBS1
SQL> select count(*) from sm;
COUNT(*)
   1326661
Elapsed: 00:00:03.53
SQL> select count(*) from sm;
COUNT(*)
   1326661
Elapsed: 00:00:03.45
SQL> select count(*) from sm ss,ac_taj@taj ac
2 where ss.nserial = ac.nserial;
COUNT(*)
     88763
Elapsed: 00:00:38.35
SQL> show parameter db_name
NAME                                 TYPE        VALUE
db_name                              string      db02
SQL>i have some configuration of undo tbs. but i am not getting any error. also i am just startup my database if right know i am only one user connected to database.
SQL> select bytes/1024/1024 "UNTO MB" from dba_data_files
2 where tablespace_name = 'UNDOTBS1'
3 /
   UNTO MB
       930

Direct Path SQL Loader get error ORA-01555

Hi All,
11.2.0.1 DB
Has anyone here used sqlloader direct path option?
Is there special setting I need for the Undo TS?
I am testing my sqlloader direct path but I got error : ORA-01555: snapshot too old: rollback segment number 10 with name "_SYSSMU10$" too small
I am only testing 100 records and I shutdown the database. And I am only the one using it. :(
Does dropping the Undo TS and creating new one help resolve my issue?
Thanks a lot,
Kinz
Edited by: KinsaKaUy? on 07-Nov-2012 03:33

I drop my UNDOTS1 and recreate it to resolve if there are framentation in the TS itself , but to no avail, the same error persist :(
Record 1: Rejected - Error on table EMPLOYEE.
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number with name "" too small
SYSTEM                         ONLINE
_SYSSMU87_2780657351$          ONLINE
_SYSSMU88_120427686$           ONLINE
_SYSSMU89_1588874193$          ONLINE
_SYSSMU90_2571046414$          ONLINE
_SYSSMU91_1803654754$          ONLINE
_SYSSMU92_2477693864$          ONLINE
_SYSSMU93_1908993412$          ONLINE
_SYSSMU94_985867735$           ONLINE
_SYSSMU95_4165893730$          ONLINE
_SYSSMU96_1502488804$          ONLINE
_SYSSMU97_3533816217$          ONLINE
_SYSSMU98_3954380786$          ONLINE
_SYSSMU99_1314687851$          ONLINE
_SYSSMU100_3542148152$         ONLINE
_SYSSMU101_1249002234$         ONLINE
_SYSSMU102_1520886654$         ONLINE
_SYSSMU103_2785416951$         ONLINE
_SYSSMU104_1530388055$         ONLINE
_SYSSMU105_1995830672$         ONLINE
_SYSSMU106_4584952$            ONLINE
_SYSSMU107_1177768351$         ONLINE
_SYSSMU108_3896986945$         ONLINE
_SYSSMU109_2576315174$         ONLINE
_SYSSMU110_2786589320$         ONLINE
_SYSSMU111_1195961439$         ONLINE
_SYSSMU112_2612035115$         ONLINE
_SYSSMU113_1697198479$         ONLINE
_SYSSMU114_3939726644$         ONLINE
_SYSSMU115_467875145$          ONLINE
_SYSSMU116_2826382876$         ONLINE
_SYSSMU117_3650068864$         ONLINE
_SYSSMU118_92260707$           ONLINE
_SYSSMU119_2322108460$         ONLINE
_SYSSMU120_2583709550$         ONLINE
_SYSSMU121_1279604730$         ONLINE
_SYSSMU122_2128414833$         ONLINE
_SYSSMU123_1365970622$         ONLINE
_SYSSMU124_1855929876$         ONLINE
_SYSSMU125_1511578664$         ONLINE
_SYSSMU126_3219352797$         ONLINE
_SYSSMU127_2412556110$         ONLINE
_SYSSMU128_2102547636$         ONLINE
_SYSSMU129_447164998$          ONLINE
_SYSSMU130_3851265156$         ONLINE
_SYSSMU131_3046352603$         ONLINE
_SYSSMU132_2987406815$         ONLINE
_SYSSMU133_983809304$          ONLINE
_SYSSMU134_928979873$          ONLINE
_SYSSMU135_3248183819$         ONLINE
_SYSSMU136_811112856$          ONLINE
_SYSSMU137_1958351427$         ONLINE
_SYSSMU138_2222543$            ONLINE
_SYSSMU139_3962620689$         ONLINE
_SYSSMU140_2711665463$         ONLINE
_SYSSMU141_3724825495$         ONLINE
_SYSSMU142_1818253355$         ONLINE
_SYSSMU143_1370485269$         ONLINE
_SYSSMU144_2442636386$         ONLINE
59 rows selected.
SQL>Is there something missing in my sqlloader parameter? but if I use "ordinary" path it will load successfully. But not with "direct" path :( Any ideas please

Receiving error ORA-01555: snapshot too old:

Need some info...
Currently seeing ORA-01555: snapshot too old: rollback segment number 18 with name "_SYSSMU18$" too small.
Info:
SQL> show parameter undo
NAME TYPE VALUE
undo_management string AUTO
undo_retention integer 4200
undo_suppress_errors boolean FALSE
undo_tablespace string UNDOTBS_1
SQL> select max(maxquerylen) from v$undostat;
MAX(MAXQUERYLEN)
35792
SQL>
run this based on threads in here:
SQL> select (35792/60)/60 query,(4200/60)/60 retention from dual;
QUERY RETENTION
9.94222222 1.16666667
I need some help figuring out what to set my undo_retention to? Should it be 36000?
Any help is appreciated.
Thanks

Jamie CC wrote:
The query that was in the alert log was running against a table with 779 rows. The query uses the index (not worried if it wouldn't for that small a table) and came back in one second... This makes no sense. Is it possible that there was a sub-query running and the wrong query was put into the alert log?More likely the query in the alert log was one that died, but the cause was a different query. Remember, the meaning of an ORA-1555 is that the query needed to go back to undo in order to gather a view of the data to a certain SCN, and the data had already been aged out. So the alert log gets the one that died, but the cause is another one. Feel lucky at that, in older versions it was considered an app error IIRC.
Search for the error on asktom.oracle.com for a number of scenarios, and you might want to review the part of the concepts manual about read consistency to make sense of it all. You might also find Tom's book explanation about it with a google search.
Also, depending on your version, there may be things to set like retention guarantee.
I've found on the ERP/MRP systems I work on these errors will appear weekly from people leaving sessions connected after they go home, so I kill 'em off at night. And that's with an undo nearly as big as the db data, that's normally almost empty.

The nature of "ORA-01555: snapshot too old..." error

Hi all,
Please help me to understand the nature of this error:
ORA-01555: snapshot too old: rollback segment number 23 with name "_SYSSMU23_755263746$" too small
One of reports returns this error. Yes, I googled it, but honestly I can't understand deeply what causes it. Usually I resolve it by performing sql request on yesterday's copy of production database. Is it correct to say that this error happens when I try to perform request on tables that are changed in the same moment? What is correct solution to resolve it other than using yesterday's copy of production database?

marco wrote:
Antonio,
The problem is generally small segments of undo, you need to add more space or put guaranty the tablespaces.
How do I describe it for our DBA (how much extra space do I need and what is the name of tablespace)?
Before you go to your DBA, you should figure out how much space your largest query/update uses. That is, your biggest transaction, how much space does it need? 10M? 100M? 1G? From there, your DBA can then size your UNDO properly (or at least "more better" ). Yes he "name of the tablespace" is just called "UNDO").
As mentioned before, the solution might not even be to increase your UNDO size, but rather to identify the "problem job", and fix it. That's not easy, however, talk to your DBA, he may be able to help with that as well.
Things to look for:
1) a job that issues a lot of commits. (suspicious - try to reduce # of commits).
2) a job that runs for a long time and updates along the way (suspicious - try to reduce run time).
3) a job that runs for a long time and has no updates (try to reduce run time - in this case, if this job starts running, and then takes a long time, a lot of other jobs may be reasonably doing updates, and this long run query needs to reference a row that was updated - it might lose it in the UNDO, though).
4) long running queries running at same time as updates on same table. (not always possible, but think about it: a "long running query" is often a "report" of some sort (not always, but often). Try to schedule the reports when less update activity is expected. Or, if the updates are part of the same batch, try to schedule them after each other so they don't overlap. (if the updates are online users, there isn't much you can do except try to decrease runtime of the long running query).
You DBA can help find candidates for those cases.

Ora-01555 in 9i Datawarehouse db

Hi,
We have some ora-01555 , mostly on insert /* append */ select from and create tables as select with big tables, the source tables are 2000 millions rows.
The undo tablespace has 49 Gb.
The undo_retention is set to 2500.
It`s true that the executions fails between 4000 and 9000 seconds and the undo_retention is lower, but in v$undostat UNXPSTEALCNT, EXPSTEALCNT, NOSPACEERRCNT, UNXPBLKRELCNT, UNXPBLKREUCNT ara alway 0 so my point of view is that there is no problem of space or undo_retention.
Could you please confirm this ?
If so, could it be a delayed block clenaout problem ?
Regars
Xavi

What is the value of TUNED_UNDORETENTION column of V$UNDOSTAT?
I think you should try increasing undo_retention.

Snapshot too old ORA-01555 from select statement (discoverer)??

Hi All
Am I loosing the plot .. but we have a select statement run from discoverer which is causing the famous snapshot too old error.
My understanding is that undo is generated from select/insert/update.
So why is the following discoverer Select statement causing the error?
from alert
ORA-01555 caused by SQL statement below (SQL ID: gk0wxgqmx66sh, Query Duration=3866 sec, SCN: 0x001e.089cf3f9):
SELECT ( ROUND(( TO_DATE(SYSDATE)-o101038.HIRE_DATE )/365,2) ) as
" bla bla
ORDER BY o101020.SUB_ORGANIZATION_NAME ASC
Thanks in Advance

simon.9999 wrote:
Hi All
Am I loosing the plot .. but we have a select statement run from discoverer which is causing the famous snapshot too old error.
My understanding is that undo is generated from select/insert/update.
So why is the following discoverer Select statement causing the error?
from alert
ORA-01555 caused by SQL statement below (SQL ID: gk0wxgqmx66sh, Query Duration=3866 sec, SCN: 0x001e.089cf3f9):
SELECT ( ROUND(( TO_DATE(SYSDATE)-o101038.HIRE_DATE )/365,2) ) as
" bla bla
ORDER BY o101020.SUB_ORGANIZATION_NAME ASC
Thanks in Advance
The SELECT statement is the victim.
Some session is doing DML against the same table against which the SELECT occurs & is likely doing COMMIT inside a LOOP.

Expdp fails with ORA-31693, ORA-02354 and ORA-01555

Hi,
Oracle Database 10.2.0.4.0, Windows Server 2003
I was doing a full database DATA PUMP export as follow:
expdp system/pass@SID FULL=y DIRECTORY=MY_EXPORT DUMPFILE=EXPORT_DB.dmp logfile=EXPORT_DB.log
It always worked fine but today I received an error message :
ORA-31693: Table data object "S"."TABL1" failed to load/unload and is being skipped due to error:
ORA-02354: error in exporting/importing data
ORA-01555: snapshot too old: rollback segment number 10 with name "_SYSSMU10$" too small
The undo_retention parameter is set to its default of 900 currently.
Datafile in UNDO tablespace is 5GB used and this datafile is autoextend up to 32GB.
Any idea of what may causes this error ?
Thanks!

This happens only with the two largest tables which are around 11GB.
Today I do several times export, but always with one error.
First time error with one table, second time with another table... Everything else is exported without errors.

ORA-01555: snapshot too old: rollback segment number with name "" too smal

Hi,
I'm working on Oracle Database 11g Release 11.1.0.6.0 - 64bit Production With the Real Application Clusters option.
I'm exepriencing the error in the subject executing a procedure.
This procedure run at 2am, reading from a table all records written the day before:
... WHERE date_write between d1 and d1+1 ....
d1 = trunc(sysdate-1)So I suppose that the recordset cannot be changed during the execution of the procedure.
The recordset extracs more or less 10milions of records.
The procedure than read few records from another table and then insert a new record into a table (trying to delete it if already existing).
I commit every 10k records.
What I noticed is that the procedure always fails after 1 hour, that's the undo_retention value.
I tried to change the param to 2 hours, and last run failed after 2 hours...
I think I understood the ORA-01555 causes, but I thought the commit would have avoid it.
So, any suggestion?
Thanks in advance!
Samuel

What's then the logic why the commit is causing it?When you commit a transaction, involved undo blocks are "released", and they might be overwritten : if those blocks are needed for consistency, then you get ORA-01555 error.

ORA-01555 error when assigning values based on geometry

Hello,
I have a table with 220,000+ records with street information, and I am trying to assign a municipal area (stored in another table) based on the geometry of the road line and the geometry of the municipal boundary.
CREATE TABLE TEMP AS SELECT A.ID, B.AREA FROM ROADS A, PLACES B WHERE B.TYPE IN (33,35,36,37) AND mdsys.sdo_relate (a.geometry,b.geometry,'
mask=inside querytype = window')='TRUE';
This took a long time to run and it came back with a series of errors, one of which was ORA--01555 'snapshot too old'. I was running other queries on the table (in a separate SQL window) because I'm under a deadline, so i figured that doing multiple things at one time while the spatial query was running was causing the problem. I didn't have time to run it again (it was the end of the day when the error came up, conveniently) so I am trying to work out a solution to this issue.
Would it be better if I: a) ran the statement again on the whole dataset and did nothing else while it is running, even though it will still take a while, or
b) broke it up into groups of 50,000 records and run the statement on one group at a time and hope for the best.
Thanks in advance!

Assuming you have less municipal areas than roads, the query should perform better by specifying the join order:
CREATE TABLE TEMP AS (
     SELECT /*+ ORDERED */ A.ID, B.AREA
     FROM PLACES B, ROADS A
     WHERE B.TYPE IN (33,35,36,37)
     AND mdsys.sdo_relate (a.geometry, b.geometry,'mask=inside querytype = window') = 'TRUE');Also, are you sure 'inside' is the right mask to use here? What if a road intersects the edge of the municipality? In that case it wouldn't be returned by this query.

ORA-01555: table Re-org

Similar Messages

Maybe you are looking for