喜欢就来多看看

Data Pump-2

上一篇 / 下一篇 2007-02-13 00:00:00 / 个人分类：11g&Grid

检验的结果如下。

=============================================================================
处理内容                                          时间(分)           文件尺寸
----------------------------------------------------------------------------
1．以原来的Export执行数据的unload               47            19.86GB
2．以原来的Export执行数据的direct unload        32            18.69GB
3．以Data Pump执行unload                       29            19.87GB
4．以原来的Import执行数据load                   63
5．以Data Pump执行load                         26
=============================================================================

在上次的load处理中，因为同一磁盘上发生Read和Write的冲突，妨碍性能的提升。这次数据文件所在磁盘和创建dump文件的磁盘不同，重新进行一次物理检验。

Data Pump(数据泵)的架构(architecture)的关键在于目录级别上并行处理。进行load处理的时候，重点在于以并行处理将直接写入多线程化，让磁盘性能发挥到最大。

上次的磁盘结构
数据文件：4个磁盘的RAID0结构
dump文件：和上面相同的磁盘

这次的磁盘结构
数据文件：4个磁盘的RAID0结构
dump文件：和上面不同的独立磁盘

=============================================================================
=============================================================================
处理内容                                          时间(分)           文件尺寸
----------------------------------------------------------------------------
1．以原来的Export执行数据的直接unload            16             18.69GB
2．以Data Pumpun执行load                        12             19.87GB
3．以原来的Import执行数据load                    56
4．以Data Pump执行load                          10
=============================================================================

原来的Import执行load处理是56分钟，速度并没有太大的改变，不过Data Pump执行load处理的速度大幅提升，load处理的速度大约是上次的5.5倍。

此外，说到直接路径的写入很多人会想到SQL*Loader的直接模式，那么系统的动作是一样的吗？SQL*Loader的情况是，在high water mark（HWM）以下执行直接写入，然后将HWM拉高。因此，可以不必寻找数据文件内的空闲空间然后进行coalesce。所以，这次我们想用Data Pump看看HWM的动作。

1．创建表

   SQL> create table hign_water_mark (id number, text varchar2(128))
    2 > tablespace test;

创建数据

   SQL> begin
    2 >     for i in 10000 loop
    3 >         insert into high_water_mark values (i,'test text : '||i');
    4 >         if (mod(i,1000)=0) then
    5 >             commit;
    6 >         end if;
    7 >     end loop;
    8 >     commit;
    9 > end;
    10> /

2．确认现在的HWM

   SQL> var total_blocks                number
   SQL> var total_bytes                 number
   SQL> var unused_blocks               number
   SQL> var unused_bytes                number
   SQL> var last_used_extent_file_id    number
   SQL> var last_used_extent_block_id   number
   SQL> var last_used_block             number
   SQL> 
   SQL> exec dbms_space.unused_space('TPC','HIGH_WATER_MARK','TABLE'
    2 >                             ,:total_blocks
    3 >                             ,:total_bytes
    4 >                             ,:unused_blocks
    5 >                             ,:unused_bytes
    6 >                             ,:last_used_extent_file_id
    7 >                             ,:last_used_extent_block_id
    8 >                             ,:last_used_block);

以上面的SQL语句，HWM是896 block。上面的SQL语句会在SYS创建Directory对象，给TPC用户读取和写入的权限。接下来，终于要以Data Pump进行资料的unload了。

3．Delete处理
不调低HWM而将数据删除

4．平常的load处理

5．确认现在的HWM
以2.的SQL语句确认，就会看到HWM依然是896block，没有改变。

6．Delete处理

7．以Data Pump进行load处理
不调低HWM而将数据删除

8．确认现在的HWM
以2.的SQL语句确认，就会看到HWM上升到1536 block。

换句话说，以Data Pump进行load处理会把HWM提高，导致进行全表扫描的时候性能会恶化。尤其在TABLE_EXISTS_ACTION参数设为APPEND，以追加到既有的数据的方式进行load处理的时候，更要特别注意。

此外，在SQL*Loader以直接路径load数据的时候，需要在load之前让触发器(trigger)无效，等到正常load结束之后再设回有效。如果改用Data Pump执行数据load，触发器是不是就能正常动作？

首先，对Warehouse表执行insert，然后对WARE_TMP表执行update，创建触发器(trigger)。

SQL> create table ware_tmp (id number default 0);

表已经建立。

SQL> create trigger ware_test_trg after insert
  2  on warehouse for each row
  3  begin
  4     update ware_tmp set id=id+1;
  5  end;
  6  /

触发器创建完毕。

SQL> insert into ware_tmp values (0);

创建了1行。

SQL> commit;

提交结束。

现在就以Data Pump执行数据的load处理。

-------------------------------------------------------------------------------
Import: Release 10.1.0.2.0 - Production on 星期日, 13日6月, 2004 20:11

Copyright (c) 2003, Oracle.  All rights reserved.

连接: Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options
Maser table"TPC"."SYS_IMPORT_TABLE_01"已经正常load/unload
正在启动"TPC"."SYS_IMPORT_TABLE_01": 
tpc/******** directory=pump_dir2 dumpfile=exp_pump_obj.dmp tables=warehouse
content=data_only logfile=imp_pump_obj.log parallel=2 table_exists_action=append
正在处理物件型TABLE_EXPORT/TABLE/TBL_TABLE_DATA/TABLE/TABLE_DATA

. . "TPC"."WAREHOUSE"            7.898 KB       导入了5行

Job "TPC"."SYS_IMPORT_TABLE_01"在20:11正常结束
-------------------------------------------------------------------------------

确认触发器是否正常动作：

SQL> select * from ware_tmp;

        ID
----------
         5

可见情况和SQL*Loader不同，即使是直接路径触发器也会正常动作。
同样地，在SQL*Loader的直接load处理对于有Primary Key限制的表，碰到Primary Key插入重复的数据时，会接受重复的数据插入，导致Index无法使用。这时候，Data Pump的直接load处理会有什么动作？

首先，在Warehouse表设定Primary Key限制。

SQL> alter table warehouse add constraint ware_pk primary key(w_id);

表改变了。

现在以Data Pump执行直接load处理。

-------------------------------------------------------------------------------
Import: Release 10.1.0.2.0 - Production on 星期日, 13日6月, 2004 20:04

Copyright (c) 2003, Oracle.  All rights reserved.

-------------------------------------------------------------------------------
连接: Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options
Master table "TPC"."SYS_IMPORT_TABLE_01"已经正常load/unload
正在启动"TPC"."SYS_IMPORT_TABLE_01"：
tpc/******** directory=pump_dir2 dumpfile=exp_pump_obj.dmp tables=warehouse 
content=data_only logfile=imp_pump_obj.log parallel=2 table_exists_action=append
正在处理物件型TABLE_EXPORT/TABLE/TBL_TABLE_DATA/TABLE/TABLE_DATAの处理中です
ORA-31693: 表数据物件"TPC"."WAREHOUSE"的load/unload失败
           因为出错所以跳过:
ORA-00001: 违反单一限制(TPC.WARE_PK)
Job "TPC"."SYS_IMPORT_TABLE_01"结束，但是在20:04发生了1项错误。