对一个schema运行expdp导出，expdp命令：
nohup expdp HQ_X1/HQ_X1 DUMPFILE=HQ_X1.DMP DIRECTORY=DIR1 parallel=8 flashback_scn=10838324803 &
ORA-39095: Dump file space has been exhausted: Unable to allocate 8192 bytes
这一般是由于使用了parallel參数导致。官方文档的解释是parallel io server processes写文件不能同一时候写一个，
而且当一个io server process在写其余io server process在等待的时候就会报ORA-39095。
所以解决的方法：（1）.取消parallel。但这样会影响expdp的性能;
（2）在写导出语句的时候指定dumpfile中使用变量 %u(大写和小写均可)。让其自由分配转储文件就可以。
于是我使用了变量又一次导出：
nohup expdp HQ_X1/HQ_X1 DUMPFILE=HQ_X1%u.DMP DIRECTORY=DIR1 parallel=8 flashback_scn=10838324803 &
之前的问题已经攻克了，但遇到了新的报错：
ORA-31693: Table data object "HQ_X1"."TBL_BILL":"SYS_P109" failed to load/unload and is being skipped due to error:
ORA-02354: error in exporting/importing data
ORA-01466: unable to read data - table definition has changed
查看下dba_objects，果然在那个时间点有DDL操作：
LAST_DDL_TIME
2015-06-23/17:32:19
2015/1/12 22:57:10
怀疑是GRANT之类的可能性最大， 查下v$sql,果然有以下的SQL，时间也全然相应得上:
insert into objauth$(obj#, grantor#, grantee#, privilege#, sequence#, option$, col#) values(:1,:2,:3,:4,:5,:6,:7) 2015-06-23/17:32:19
--insert into objauth$(option$,grantor#,obj#,privilege#,grantee#,col#,sequence#) values(decode(:1,0,null,:1),:2,:3,:4,:5,decode(:6,0,null,:6),object_grant.nextval);
Oracle的一篇note是这样说的：
The issue is discussed in
Bug 8534161 - ORA-1466 REPORTED BY EXPDP WHEN USING FLASHBACK_SCN AND PRIVILEGES WERE GRANTED
Oracle Development confirmed this is expected behavior and not a bug.
而且给出给解决方法：
WORKAROUND
Do not grant any privileges to any object while Expdp is running with FLASHBACK_SCN.
另附一个我自己做的測试：
开2个session,
session1先open一个游标:
SQL> exec open :x for select * from b where user_id=100;
PL/SQL procedure successfully completed.
session2运行一个grant：
SQL> grant select on b to mine;
Grant succeeded.
session1打印游标：
SQL> print x
USERNAME USER_ID CREATED
------------------------------ ---------- --------------
HQ_X2 100 12-9月 -14
HQ_X2 100 12-9月 -14
能够看出对于SELECT操作，当运行期间在还有一个session运行grant时没有问题的，但在expdp下却不行，这就是一開始Oracle觉得这是一个BUG的原因。