在平時的工作中，可能需要匯入一些資料，有些表可能比較大，對於constraint的操作可能會耗費大量的時間，今天簡單做了一些相關的測試，也提出了一些相關的優化方案，對結果進行比較，看看哪種才是比較合理的方法。

首先監控redo,undo的生成量也是衡量的一個標準。本次測試就簡單從redo,undo,執行時間這三個方面進行總結。我準備採用shell指令碼來進行監控。指令碼內容見最後。

首先刪除原有的表，重新建立，這個過程中也可以監控redo,undo和執行時間。資料量目前在40萬左右，可以看到建立constraint的時候耗費了約70M左右的redo

然後在客戶的機器上進行了簡單的測試，配置要比本地好很多，測試的資料量是800萬的。為了放大某些細節，總結的測試結果如下。

各種多種場景最終都被否定了，最後可以考慮一下把constraint和index分離，加上parallel來處理。

採用這種方式，響應時間和redo的生成量都大幅度降低,從原來的17秒減少到了8秒

指令碼如下：

------------------------------------------------------------------------- 
sqlplus -s n1/n1 <<EOF 
set feedback off 
set termout off
set linesize 100 
set pages 50 
col name format a30 
variable redo number 
spool test_before_tmp.log 
@redo_stat.sql 
@undo_stat.sql 
spool off; 
set timing on 
$1 
set timing off 
--alter session enable parallel ddl;
spool test_after_tmp.log 
@redo_stat.sql 
@undo_stat.sql 
spool off; 
EOF 
echo '##################################################' 
echo 'redo, undo stats generated as below' 
echo '##################################################' 
sdiff test_before_tmp.log test_after_tmp.log|grep "|"|awk -F"|" '{print $2}' 
exit
 

引用到的sql指令碼內容如下：

--redo_stat.sql
select a.name ,b.value from v$statname a,v$mystat b 
where a.STATISTIC#=b.STATISTIC# 
and a.name like '%redo%' 
order by a.name;
--undo_stat.sql
select a.name ,b.value from v$statname a,v$mystat b 
where a.STATISTIC#=b.STATISTIC# 
and a.name like '%undo%' 
order by a.name;