可传输的表空间闪回版本查询等待界面回滚监视 Oracle 数据泵闪回表

Oracle 10g 数据库的基本特性 • 可传输的表空间 • 闪回版本查询 • 等待界面 • 回滚监视 • Oracle数据泵 • 闪回表

可传输的表空间 介绍：您如何将数据从一个数据库转移到另一个数据库？在现有的几种方法，有一种方法尤为出色：可传输表空间。定义：在这种方法中，您使用一组自包含、只读的表空间，只导出元数据，在操作系统层将这些表空间的数据文件拷贝至目标平台，并将元数据导入数据字典。

新、旧版本的区别 旧版本：在oracle以前的版本中,可传输的表空间的特性可以让表空间在相同的体系结构和操作系统之间迁移.可传输表空间仅限于在目标数据库和源数据库都运行在同一操作系统平台上的少数情况下才有用。新版本：在 Oracle 数据库 10g中，这个局限消失了：只要操作系统字节顺序相同,您就可以在平台之间传输表空间。

字节顺序 关于字节顺序：一些操作系统（包括 Windows）在低位内存地址中用最低有效字节存储多字节二进制数据－－这种系统被称为低地址低字节序。相反，其它的操作系统将最高有效字节存储在低位内存地址中，因此这种系统被称为低地址高字节序。当一个低地址高字节序的系统试图从一个低地址低字节序的系统中读取数据时，需要一个转换过程。否则，字节顺序将导致不能正确解释读取的数据。当然，在相同字节顺序的平台之间传输表空间时，不需要任何转换。（如何转换：后文中有提到。）

Oracle 10g的发展 进一步的让你使用可传输的表空间的特性,在平台之间进行传输.这样简化了从数据仓库到数据超市之间的分发,超市通常是运行在较小的平台上的. 同时，它也容许数据库通过重新建立数据字典和传输用户表空间来从一个平台移植到另外一个平台.

跨平台移植的优点： 可传输表空间现在可以跨平台移植，从而使得数据发布更快更容易。此外，外部表下载使得通过转换进行数据转移的任务更简单更快。

实现跨平台移植的条件 为了能够从一个平台到另外一个平台传输数据文件： ◆需要保证源系统和目标系统运行在支持的平台上； ◆需要相同的字符集；　　 ◆最小兼容性；　　 ◆源和目标数据库都必须设置compatible为10.0.0或更高；　　 ◆数据文件头是平台相关的；　　　　 ◆在传输之前,确信所有的只读和脱机文件是平台相关的；（只读和脱机的意思是文件头无log号和checkpoint号）　　 ◆两个必须是10g数据库;

高低位转换 要从一个平台传输表空间到另外一个平台,这个表空间的数据文件必须转换到源和目标数据库都能认的格式.尽管在10g,磁盘结构都符合公共格式,但是在源和目标数据库用不同的高低位也是可以的.当要传输到不同的高低位的平台的时候,你需要使用rman的convert命令来转换高低位.这个操作既可以在源也可以在目标数据库做.

高低位的查看 如果平台的高低位是相同的,那就没有必要做转换了. 查看平台的高低位： select tp.endian_formatfrom v$transportable_platform tp,v$database dwhere tp.platform_name = d.platform_name;

闪回版本查询 在 Oracle9i Database 中，我们看到它推出了以闪回查询形式表示的“时间机器”。该特性可以看到特定时间的列值，只要在还原段中提供该数据块此前镜像的拷贝即可。但是，闪回查询只提供某时刻数据的固定快照，而不是在两个时间点之间被更改数据的运行状态。某些应用程序，如涉及到外币管理的应用程序，可能需要了解一段时期内数值数据的变化，而不仅仅是两个时间点的数值。

旧版本的闪回版本查询 查询对表的更改在本示例中，我使用了一个银行外币管理应用程序。其数据库含有一个名称为 RATES 的表，用于记录特定时间的汇率。 SQL> desc rates Name Null?Type ----------------- -------- ------------ CURRENCY VARCHAR2(4) RATE NUMBER(15,10) 该表显示 US$ 与各种其他货币的汇率，在 CURRENCY 列中显示。在金融服务行业中，汇率不但在变更时进行更新，而且被记录在历史中。需要这种方式（即闪回查询）的原因是银行交易可能在“过去时间”生效，以便适应由于汇款而耗费的时间。例如，对于一项在上午 10:12 发生但在上午 9:12 生效的交易，其有效汇率是上午 9:12 的汇率，而不是现在的汇率。

旧版本的闪回版本查询 直到现在，有一种选择是创建一个汇率历史表来存储汇率的变更，然后查询该表是否提供历史记录。另一种选择是在 RATES 表本身中记录特定汇率适用性的开始和结束时间。当发生变更时，现有行中的 END_TIME 列被更新为 SYSDATE，并插入一个具有新汇率的新行，其 END_TIME 为 NULL。

10g的闪回版本查询 但是在 Oracle Database 10g 中，闪回版本查询特性不需要维护历史表或存储开始和结束时间。使用该特性，您不必进行额外的设置，即可获得某行在过去特定时间的值。即 10g 能够更方便高效地执行该任务。

10g的闪回版本查询 例如，假定该 DBA 在正常业务过程中数次更新汇率 — 甚至删除了某行并重新插入该行： insert into rates values ('EURO',1.1012); commit; update rates set rate = 1.1014; commit; update rates set rate = 1.1013; commit; delete rates; commit; insert into rates values ('EURO',1.1016); commit; update rates set rate = 1.1011; commit;

10g的闪回版本查询 在进行了这一系列操作后，DBA 将通过以下命令获得 RATE 列的当前提交值 SQL> select * from rates; CURR RATE ---- ---------- EURO 1.1011 此输出显示 RATE 的当前值，没有显示从第一次创建该行以来发生的所有变更。这时使用闪回查询，您可以找出给定时间点的值；但我们对构建变更的审计线索更感兴趣 — 有些类似于通过便携式摄像机来记录变更，而不只是在特定点拍摄一系列快照。

10g的闪回版本查询 以下查询显示了对表所做的更改： select versions_starttime, versions_endtime, versions_xid, versions_operation, rate from rates versions between timestamp minvalue and maxvalue order by VERSIONS_STARTTIME / VERSIONS_STARTTIME VERSIONS_ENDTIME VERSIONS_XID V RATE ---------------------- ---------------------- ---------------- - ---------- 01-DEC-03 03.57.12 PM 01-DEC-03 03.57.30 PM 0002002800000C61 I 1.1012 01-DEC-03 03.57.30 PM 01-DEC-03 03.57.39 PM 000A000A00000029 U 1.1014 01-DEC-03 03.57.39 PM 01-DEC-03 03.57.55 PM 000A000B00000029 U 1.1013 01-DEC-03 03.57.55 PM 000A000C00000029 D 1.1013 01-DEC-03 03.58.07 PM 01-DEC-03 03.58.17 PM 000A000D00000029 I 1.1016 01-DEC-03 03.58.17 PM 000A000E00000029 U 1.1011 注意，此处显示了对该行所作的所有更改，甚至包括该行被删除和重新插入的情况。VERSION_OPERATION 列显示对该行执行了什么操作 (Insert/Update/Delete)。所做的这些工作不需要历史表或额外的列。

10g的闪回版本查询 在上述查询中，列 versions_starttime、versions_endtime、versions_xid、versions_operation 是伪列，与 ROWNUM、LEVEL 等其他熟悉的伪列相类似。其他伪列 —如 VERSIONS_STARTSCN 和 VERSIONS_ENDSCN — 显示了该时刻的系统更改号。列 versions_xid 显示了更改该行的事务标识符。有关该事务的更多详细信息可在视图 FLASHBACK_TRANSACTION_QUERY 中找到，其中列 XID 显示事务 id。例如，使用上述的 VERSIONS_XID 值 000A000D00000029，UNDO_SQL 值显示了实际的语句。 SELECT UNDO_SQL FROM FLASHBACK_TRANSACTION_QUERY WHERE XID = ‘000A000D00000029’; UNDO_SQL ---------------------------------------------------------------------------- insert into “ANANDA”.“RATES”(“CURRENCY”,“RATE”) values (‘EURO’,‘1.1013’); 除了实际语句之外，该视图还显示提交操作的时间标记和 SCN（系统检查点）、查询开始时的 SCN 和时间标记以及其他信息。

10g的闪回版本查询 现在，让我们来看如何有效地使用这些信息。假设我们需要找出下午 3:57:54 时 RATE 列的值。我们可以执行： select rate, versions_starttime, versions_endtime from rates versions between timestamp to_date('12/1/2003 15:57:54','mm/dd/yyyy hh24:mi:ss') and to_date('12/1/2003 16:57:55','mm/dd/yyyy hh24:mi:ss') / RATE VERSIONS_STARTTIME VERSIONS_ENDTIME ---------- ---------------------- ---------------------- 1.1011 此查询与闪回查询类似。在以上的示例中，开始和结束时间为空，表示汇率在该时间段中没有更改，而是包含一个时间段。还可以使用 SCN 来找出过去的版本值。可以从伪列 VERSIONS_STARTSCN 和 VERSIONS_ENDSCN 中获得 SCN 号。以下是一个示例： select rate, versions_starttime, versions_endtime from rates versions between scn 1000 and 1001

10g的闪回版本查询 使用关键词 MINVALUE 和 MAXVALUE，可以显示还原段中提供的所有变更。您甚至可以提供一个特定的日期或 SCN 值作为范围的一个端点，而另一个端点是文字 MAXVALUE 或 MINVALUE。例如，以下查询提供那些只从下午 3:57:52 开始的变更，而不是全部范围的变更： select versions_starttime, versions_endtime, versions_xid, versions_operation, rate from rates versions between timestamp to_date('12/11/2003 15:57:52', 'mm/dd/yyyy hh24:mi:ss') and maxvalue order by VERSIONS_STARTTIME

最终的分析 闪回版本查询随取随用地复制表变更的短期易变数值审计。这一优点使得 DBA 能够获得过去时间段中的所有变更而不是特定值，只要还原段中提供数据，就可以尽情使用。

等待界面 “数据库太慢了！” 　　这句话通常出自一位严格的用户之口。　　　　那么，您又怎样解决该问题呢？除了对用户置之不理之外，您可能要做的第一件事就是查看是否有任何会话在等待数据库内部或外部的任何事件。

V$SESSION_WAIT 视图 Oracle 提供了一个简单但一流的机制来达到此目的：VSESSION_WAIT 视图。该视图显示了有助于您的诊断的各种信息，如一个会话正在等待或已经在等待的事件，以及等待了多长时间和多少次。例如，如果会话在等待事件 "db file sequential read"，列 P1 和 P2 将显示会话正在等待的块的 file_id 和 block_id。

V$SESSION_WAIT 视图缺点 对于大多数等待事件而言，这个视图足够了，但它还不是一个强健的调整工具，之所以如此说，至少是因为以下两个重要原因：　　★该视图是当前情况的一个快照。当等待不再存在时，会话先前出现的那些等待的历史也将消失，从而使得事后诊断非常困难。 ★V$SESSION_WAIT 包含了只与等待事件相关的信息；要获得所有其它的相关信息（如用户 ID 和终端），您必须将它和 V$SESSION 视图结合使用。

10g中的改进 在 Oracle 数据库 10g 中，等待界面经过了彻底的重新设计，从而只需更少的 DBA（Oracle 数据库管理员）干预即可提供更多的信息。对于大多数性能问题，您可以从自动数据库诊断管理器 (ADDM) 中获得扩展分析，同时，对于还没有被 ADDM 捕获的即时问题，等待界面将提供有价值的诊断数据。在下文中，我们将浏览这些新的特性，并通过例子了解它们如何帮助我们诊断性能问题。

10g 增强的特性 ①增强的会话等待 : 第一个增强涉及到 V$SESSION_WAIT 本身。这一点通过以下示例可以很好地说明。

增强的会话等待 假定您的用户抱怨会话挂起了。您查明了该会话的 SID，并在 V$SESSION_WAIT 视图中选中了该 SID 的记录。输出显示如下。 SID: 269 SEQ#: 56 EVENT:enq:TX - row lock contention P1TEXT:name|mode P1: 1415053318 P1RAW: 54580006 P2TEXT:usn<<16 | slot P2: 327681 P2RAW: 00050001 P3TEXT:sequence P3: 43 P3RAW:0000002B WAIT_CLASS_ID: 4217450380 WAIT_CLASS#: 1 WAIT_CLASS: Application WAIT_TIME: -2 SECONDS_IN_WAIT: 0 STATE:WAITED UNKNOWN TIME 　　在这些列中，WAIT_CLASS_ID、WAIT_CLASS# 和 WAIT_CLASS 是 10g 中新增的列。列 WAIT_CLASS 指示等待的类型，指示用户是将其作为有效的等待事件解决还是将其作为空闲的等待事件退出。在上面的例子中，等待类显示为 Application，这表示它是一个需要您注意的等待。　

增强的会话等待 该列突出显示那些能够证明与您的调整最相关的少数几条记录。例如，您可以使用如下查询来获取事件的等待会话。 select wait_class, event, sid, state, wait_time, seconds_in_wait from v$session_wait order by wait_class, event, sid

增强的会话等待 下面是一个样例输出： WAIT_CLASSEVENTSID STATEWAIT_TIME SECONDS_IN_WAIT Application enq:TX -269 WAITING073 row lock contentionIdleQueue Monitor Wait270 WAITING040 IdleSQL*Net message from client 265 WAITING073 Idlejobq slave wait259 WAITING08485 Idlepmon timer280 WAITING073 Idlerdbms ipc message267 WAITING0184770 Idlewakeup time manager268 WAITING040 NetworkSQL*Net message to client272 WAITED SHORT TIME -10 在这，您可以看到几个事件（如 Queue Monitor Wait 和 JobQueue Slave）被明确地归为 Idle 事件（即空闲事件），您可以将它们作为非阻塞等待消除掉。

10g 增强的特性 ②会话也显示等待　　记得长期以来一直需要将 V$SESSION_WAIT 与 V$SESSION 结合使用以获得有关会话的其他详细信息吗？嗯，这已经成为历史了。现在，在 10g 中，V$SESSION 视图显示可以由 V$SESSION_WAIT 显示的等待。

会话显示等待 下面是 V$SESSION 视图其余的列，这些列显示了会话当前等待的等待事件。　 EVENT#NUMBER EVENTVARCHAR2(64) P1TEXTVARCHAR2(64) P1NUMBER P1RAWRAW(4) P2TEXTVARCHAR2(64) P2NUMBER P2RAWRAW(4) P3TEXTVARCHAR2(64) P3NUMBER P3RAWRAW(4) WAIT_CLASS_IDNUMBER WAIT_CLASS#NUMBER WAIT_CLASSVARCHAR2(64) WAIT_TIMENUMBER SECONDS_IN_WAITNUMBER STATEVARCHAR2(19) 　　这些列与 V$SESSION_WAIT 中的那些列相同，且显示相同的信息，从而不再需要在那个视图中查看它们了。因此，对于等待任意事件的任意会话，您仅需要查看一个视图。

10g 增强的特性 ③有多少等待？用户仍然在缠着您，因为用户的问题仍然没有得到满意的解答。为什么用户的会话花了这么长时间才完成？您可以执行以下命令来找出原因： select * from v$session_wait_class where sid = 269; 　　输出返回为： SID SERIAL# WAIT_CLASS_ID WAIT_CLASS# WAIT_CLASSTOTAL_WAITS TIME_WAITED ---- ------- ------------- ----------- ------------- ----------- ----------- 269110642174503801 Application873261537 269110632902558402 Configuration44 269110633864003675 Commit10 269110627231689086 Idle15148408 269110620001533157 Network150 269110617407597678 User I/O261 　　注意这里有关会话等待的大量信息。现在您知道了，该会话已经为与应用程序相关的等待等待了 873 次（共 261,537 厘秒），在与网络相关的事件中等待了 15 次等等。

闪回表 作用：删除表的恢复如果某个用户不小心删除了一个十分重要的表，后果将非常严重。在9i中提供的闪回特性只能恢复DML语句（DML是SQL的一个子集，主要用于查看或修改数据，如insert,delete,update,select）造成的影响，而无法恢复DDL语句（SQL数据定义语言，用于创建表、修改表的结构之类的操作）的影响。DBA只能通过重建一张表，然后从备份数据中导入。利用Oracle 10G中的闪回表的特性，DBA可以轻松完成这项工作，并将影响降到最小。

例子创建表： SQL> create table abc (f number(9)); 表已创建。 SQL> create index idx_test on abc(f); 索引已创建。 SQL> insert into abc values(1); 已创建 1 行。 SQL> insert into abc values(2); 已创建 1 行。 SQL> insert into abc values(3); 已创建 1 行。 SQL> select * from tab; TNAME TABTYPE CLUSTERID ------------------ -------------- ---------- ABC TABLE SQL> select index_name, index_type, table_name from ind; INDEX_NAME INDEX_TYPE TABLE_NAME ------------------- ------------------- ---------------------- IDX_TEST NORMAL ABC 删除表： SQL> drop table abc; 表已删除。 SQL> select * from tab; TNAME TABTYPE CLUSTERID ------------------ -------------- ---------- BIN$XXUGsbYvSqa8Mrd6GstP+g==$0 TABLE

例子请注意，在原表abc被删除后，abc没有了，却出现了一张新表BIN$XXUGsbYvSqa8Mrd6GstP+g==$0。这就是Oracle 10G中对删除表的处理，原表实际上并没有完全删除掉，而是被系统重新命名成了一个系统定的新表。它还存在于原先的表空间，并且保持了原有的结构。在新表中，依赖于原表的存储过程都失效了，而建在表上的索引和触发器也会被重新命名。

例子 SQL> select index_name, index_type, table_name from ind; INDEX_NAME INDEX_TYPE TABLE_NAME------------------- ------------------- ---------------------- BIN$1++ilvsQQ7mfPh2pvont5A==$0 NORMAL BIN$XXUGsbYvSqa8Mrd6GstP+g==$0 被删除的表及其相关对象都会被放置在一个称为recyclebin的逻辑容器中： SQL> show recyclebin ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME

例子 ABC BIN$XXUGsbYvSqa8Mrd6GstP+g==$0 TABLE 2005-08-29:18:03:10 显示了被删除对象的原有名字，删除后的名字，对象类型以及删除时间。通过使用flashback table语句就可以恢复表！ SQL> flashback table abc to before drop; 闪回完成。

例子 SQL> select * from tab; TNAME TABTYPE CLUSTERID ------------------ -------------- ---------- ABC TABLE 这样就轻松的将对象恢复了！注意，对象被恢复后，它在recyclebin中占用的空间并不会被释放。必须使用PURGERECYCLEBIN来清空占用的空间。 SQL> PURGE RECYCLEBIN; 回收站已清空。

回滚监视 定义：为用户提供对回滚操作时间的准确评估我们还在这地方吗？还要多长时间？听起来熟悉吗？这些问题可能是您在前往孩子们最喜爱的主题公园的路上，从汽车后座上提出来的，并且经常是不断地、越来越频繁地提出来。您不想告诉他们还确切需要多长时间吗 — 或者更简单些，您自己知道答案吗？同样，在回滚长期运行的事务时，经常会有些用户不停地询问相同的问题。这些问题是合理的，因为该事务进行了锁定，正常的处理经常受到回滚进程的影响。

旧版本 在 Oracle 9i Database 及更低的版本中，您可以执行以下查询：SELECT USED_UREC FROM V$TRANSACTION; 该语句返回由当前事务所使用的重做记录的数量，而如果重复地执行该语句，将会显示连续减少的数值，因为回滚进程在其处理过程中会释放重做记录。随后您可以通过对一段间隔进行快照来计算其速率，然后推断出评估结束时间的结果。虽然在视图 V$TRANSACTION 中有一个名为 START_TIME 的列，但该列只显示整个事务的起始时间（也就是在回滚执行之前）。因此，除了推断，您没有办法知道回滚实际上是在什么时间执行的。

新版本 在 Oracle Database 10g 中，这种操作很简单。当事务回滚时，事件被记录在视图 V$SESSION_LONGOPS 中，该视图显示长期运行的事务，用于回滚，如果进程耗时超过六秒，则记录出现在该视图中。在回滚执行以后，您可能会隐藏所查看的监视屏幕并执行以下的查询： select time_remaining from v$session_longops where sid = <sid of the session doing the rollback>;

新版本 V$SESSION_LONGOPS 视图在 Oracle Database 10g 的预览版中提供，但没有捕获关于回滚事务的信息。为了以一种易读的方式显示所有的列，我们将使用由 Tom Kyte 在 AskTom.com 中所描述的 PRINT_TABLE 函数。此过程简单地以表格方式而不是常用的行方式来显示列。

新版本 • SQL> set serveroutput on size 999999SQL> exec print_table('select * from v$session_longops where sid = 9')SID : 9SERIAL# : 68OPNAME :Transaction RollbackTARGET :TARGET_DESC :xid:0x000e.01c.00000067SOFAR : 20554TOTALWORK : 10234UNITS :BlocksSTART_TIME :07-dec-2003 21:20:07LAST_UPDATE_TIME :07-dec-2003 21:21:24TIME_REMAINING : 77ELAPSED_SECONDS : 77CONTEXT : 0MESSAGE :Transaction Rollback:xid:0x000e.01c.00000067 :10234 out of 20554 Blocks doneUSERNAME ：SYSSQL_ADDRESS :00000003B719ED08SQL_HASH_VALUE : 1430203031SQL_ID :306w9c5amyanrQCSID : 0 • 注意，此处显示对行的所有更改，即使删除并重新插入行时也是如此。VERSION_OPERATION 列显示对该行执行的操作 (Insert/Update/Delete)。完成这些操作不需要历史表或额外的列。

新版本解决的问题 • 列 OPNAME 显示该记录用于“事务回滚”，这为我们指出了正确的方向。列 TIME_REMAINING 显示所评估的剩余时间秒数。而列 ELAPSED_SECONDS 显示到目前为止所消耗的时间。 • 那么该表如何提供对剩余时间的评估呢？可以在列 TOTALWORK 中找到线索，该列显示要完成的“工作”总量，还有 SOFAR 显示到目前为止已经完成了多少工作。工作的单位显示在列 UNITS 中。在本例中以数据块为单位；因此，到目前为止已经回滚了 20,554 个数据块中共计 10,234 个数据块。此操作到目前为止已消耗了 77 秒。因此，剩余数据块将消耗： • 77 * ( 10234 / (20554-10234) ) ? 77 秒 • 但您不必利用这种方法来获得该数值，它已经清楚地显示出来了。最后，列 LAST_UPDATE_TIME 显示有关当前视图内容的时间，这将用于加强您对结果的解释。

Oracle数据泵 Oracle 数据库 10g 中增加的叫做 Oracle Data Pump （数据泵）的新的导入和导出特性，彻底改变了数据库用户已经习惯的过去几代 Oracle 数据库的客户 / 服务器工作方式。现在服务器可以运行导出和导入任务。你可以通过并行方式快速装入或卸载大量数据，而且你可以在运行过程中调整并行的程度。导出和导入任务现在可以重新启动，所以发生故障不一定意味着要从头开始。 API（Application Programming Interface ，应用编程接口，系统所提供的位于应用程序和下层网络服务之间的接口）是公诸于众的，并且易于使用；用 PL/SQL （Procedural Language/SQL，过程化SQL语言）建立一个导入和导出任务非常简单。一旦启动，这些任务就在后台运行，但你可以通过客户端实用程序从任何地方检查任务的状态和进行修改。

旧版本 在 Oracle 数据库 10g 之前（从 Oracle7 到 Oracle9I ），导入和导出实用程序都作为客户端程序运行，并且完成大量工作。导出的数据由数据库实例读出，通过连接传输到导出客户程序，然后写到磁盘上。所有数据在整个导出进程下通过单线程操作。今天的数据量比这个体系结构最初采用的时候要大得多，使得单一导出进程成了一个瓶颈，因为导出任务的性能受限于导出实用程序所能支持的吞吐量。

新版本 • 在 Oracle 数据库 10g 和全新的数据泵（ Data Pump ）体系结构下，如今所有的工作都由数据库实例来完成。数据库实例可以用两种方法来并行处理这些工作：通过建立多个数据泵工作进程来读 / 写正在被导出 / 导入的数据，以及建立并行 I/O 服务器进程以更快地选取（ SELECT ）或插入（ INSERT ）这些数据。这样，单进程瓶颈再也就不存在了。

新版本 • 数据泵任务用新的 DBMS_DATAPUMP PL/SQL API 来建立、监测和调整。新的导入和导出实用程序（分别为 impdp 和 expdp ）对于这个 API 来说只是命令行接口。你可以使用数据泵导出实用程序初始化一个任务，例如一个导出任务。然后你就可以关闭你的客户端，而你的任务会一直运行。到了深夜，你可以重新连接到那个任务，检查其状态，甚至可以提高并行程度，以便在深夜系统没有用户在用的情况下多完成一些工作。第二天早上，你可以降低并行度甚至挂起该任务，为白天在线的用户释放资源。

Oracle数据泵 重新启动任务的功能是数据泵体系结构的一个重要特性。你可以随时停止和重启动一个数据泵任务，比如为在线用户释放资源。你还可以从文件系统的空间问题中轻松地恢复。如果一个 12 小时的导出任务在进行了 11 小时后因磁盘空间不够而失败，那么你再也不用从头开始重新启动该任务，重复前面 11 小时的工作。而是你可以连接到这个失败的任务，增加一个或多个新的转储（ dump ）文件，从失败的地方重新启动，这样只需一个小时你就可以完成任务了。这在你处理很大数据量时非常有用。

可传输的表空间闪回版本查询等待界面回滚监视 Oracle 数据泵闪回表