循序渐进调优ddl的案例（79天)

在平时的工作中，可能需要导入一些数据，有些表可能比较大，对于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;

循序渐进调优ddl的案例 （79天)

循序渐进调优ddl的案例（79天)