疑惑: exp 的时候也会用到回滚段吗?为什么exp 的时候还会保 1555 的错误呢?想不清楚

会的，exp出来的状态是一致的，也就是到某个时间点的数据。

会用到的，却省的是是以表为单位作事务，所以需要undo ，如果加上 consistent=y，那么整个
exp 就是个big 事务，需要更多的undo.

这里想起以前一个朋友问我关于exp时的回滚段的设置问题。
通常情况下，我们在跑大事务的时候可以指定一个大的回滚给他用。但是在exp的时候如何这么做？想不出有什么好的办法，有人有好的建议提下啊。

在exp的时候，系统要维护一个当前时间点的数据库快照；
假如是exp一张表，系统要维护这张表的这个时间点上的快照；假如在exp的过程中有
人对表进行更新，就必须在回滚段中产生导出时间点的数据的一个备份，而且这个备份必须到exp完成后才能释放，这是为了保证exp的一致性读取；
我个人认为表级的exp 在数据库中是一次table full scan，正常情况下不需要回滚的；

贴一段来自AskTom的帖子

You Asked (Jump to Tom's latest followup)

When running exp from a unix environment and getting ORA-1555
is there any way to use the command(or its equivalant)
'set transaction use rollback segment RBSbig' or do I have to
think about increasing the size of all my rollback segments

Regards,
       Michael   

and we said...

see


http://asktom.oracle.com/pls/ask ... 15756923,%7B1555%7D

for a discussion on this error and what causes it.

The solution you attempted, "create one big rollback" segment won't work in any
case since a 1555 is not caused by the transaction that GETS the error -- its
caused by all of the other transactions that have happened.  What you need to do
is make all of your rollback segments larger.  For example, I do a regular
export of a 6 gig image table full of blobs.  I've never hit an ora1555 in my
life.  I have large or many rollback segements though.  In my one instance I
have 6 250meg (1.5 gig total) rollback segments.  It takes a very very long time
for these to wrap around.  In my other instance I have 30 25meg rollback
segments (3/4's of a gig).  The difference between the 2 databases is the one
with few really big rollback segments has mostly fewer concurrent transactions
that do "big transactions".  The other instance has lots of concurrent
transactions that do "small or medium".  I keep lots of PERMANTLY big rollback
segments out there.  I do not attempt to skimp on rollback space (and I never
let them "shrink" to some optimal size -- I let them grow and then manually
shrink them when I want to - when i know i won't be needing that space).

So, its not that the EXPORT needs to be assigned to a big rollback -- its that
you need to let your rollback hang around for a longer period of time.  I would
recommend using recommendation #1 and #4 in the referenced URL:

  1.  Increase size of rollback segment which will reduce the likelihood of
overwriting rollback information that is needed.

  4.  Add additional rollback segments. This will allow the updates etc. to be
spread across more rollback segments thereby reducing the chances of overwriting
required rollback information.

have many large -- permanently allocated rollback segments.