Thanks, but the other thread talks about changes being made to the tables at the same time as the export occurs, or the making use of the CONSISTENT=Y. In my case, the tables are not changing, they are READONLY access to users AFTER the snapshot refreash has occured and I'm not using the CONSISTENT paramerter in the par file. Therefore, what I'm wondering is, just becasue the REFREASH process has completeted, is there still data needed to make a consistent read of the data.
I've also exported large GB database without any problems with rollbacks, and when the rollback segments have been tiny and the RBS tablesapce being about 500 MB, so I don't believe the ROLLBACK SEGMENTS are used in every export function unless of course they are used for a consistent read.
Check to see who is using the rbs whilst performing the export. I would expect that this will be the user doing the export.
The next thing to do would be to pass a table list (via the export parfile) and therefore only export the tables not the snapshots, see if this stops the error.
I am not sure if this is a valid workaround or not, but the snapshots are just copies of data elsewhere so why should they be backed up???
Getting back to it. Basically the Origional tables is from another system, and the snapshot are refreased via a DBLINK. After the the snapshots are refreashed the clients wants us to maintain exports of the SNAPSHOT data for historical purposes, therefore we then export the snapshots from our systemTherefore, after the snapshot refrash process completes the export process starts, and then we have the rollback issue. I'm going to have to set up a script to capture the rollback activity during the export.
I mean nobody is quering the data at the time, and the Refreash has completed, I can't understand why the export would be using a rollback segment for read consistency if the data in the SNAP$ table is consistent.
Originally posted by grjohnson I mean nobody is quering the data at the time, and the Refreash has completed, I can't understand why the export would be using a rollback segment for read consistency if the data in the SNAP$ table is consistent.
Try performing a full scan of those snapshots before you do your export. One of the frequent causes of ORA-1555 is "delayed block cleanout", which means that even only reading the block might change the block content.
Are you sure nobody is actualy reading your snapshots while export is going on? Are only snapshots exported, no other table? Are you sure you are getting ORA-1555 while exporting snapshot?
Jurij Modic ASCII a stupid question, get a stupid ANSI
24 hours in a day .... 24 beer in a case .... coincidence?