Simple answer is that there is enough activity on the db while you are exporting it for the database to be unable to locate the SCN for the export query consistency point in the rollback, and therefore can't validate that the data it is exporting is consistent. Bigger rollback segments would be nice.
oracle needs the full image of the database
from the export's start to end.
if the data block has been changed after your export
has started it goes to rollback segment to get the
if it fails to get for any of the block you get this error.
droping and recreating "rb5" alone will not solve the problem.
you will have to create all the rollback segments with high
minextents.(this is the oracle recommentation)
if yours is a transaction intensive then:
you can try adding more rollback segments.
you can set transactions_per_rollback_segment to high.
how much time your export takes to complete.
what is number of transactions that can execute
during the exporting period.
(count of rollback segments) * transactions_per_rollback_segment
should be greater than the number of transactions executed
during that exporting period.
the table that is being exported currently
should be read consistent.
once the table is exported then this image
can be destroyed.
oracle exports tables in the order of
userid, table name.
the frequently modified tables can be
named in such a way that it gets
exported first. (say starts with a, b, c..)
(you can create some relevant synonyms for tables).
this is also a way you can eliminate this problem.
how do you say that
setting "transactions_per_rollback_segment" to high
will worse the situation.
do you mean
one transaction will overwrite another transaction's
undo data if they are sharing the same rollback segment.