关于调试包体的一个思路.docxVIP

Hi,当我们发现一个包体有问题的时候，往往因为它过大而没法进行调试，下面我讲下前几天我们遇到的一个情况。当然，这思路不是通用的，只提供借鉴，具体问题还要具体分析。同事反应说有一个库的自动同步停止了，经过分析，我们定位到包OLRSDWPKG_DATA_REF_PP中的过程proc_wms_trans_capture。因为这个过程不大，我帖一下代码。procedureproc_wms_trans_captureiscurSQLvarchar2(1600);rtnMsgvarchar2(4000);startTimedate;beginforiin(select derp.oid,derp.schema,derp.table_name,derp.tbalias,derp.dblink,derp.where_clause,derp.primary_keyfromdw_etl_replication_propderpwherederp.app_code=WMSandderp.valid=Yorderbyderp.replicate_seq)loopcurSQL:=insert into WMS_TRANSACTIONS(TNAME, PKNAME, PKOID, VERSIONS_STARTTIME, VERSIONS_ENDTIME, VERSIONS_STARTSCN, VERSIONS_ENDSCN, VERSIONS_OPERATION, STATUS) ||select ||i.table_name||,||i.primary_key||,||i.primary_key||, VERSIONS_STARTTIME, VERSIONS_ENDTIME, VERSIONS_STARTSCN, VERSIONS_ENDSCN, VERSIONS_OPERATION, N|| from ||i.schema||i.table_name||i.dblink|| VERSIONS BETWEEN timestamp (sysdate - 15/(24*60)) AND sysdate ||i.tbalias||i.where_clause|| and VERSIONS_STARTTIME sysdate - 15/(24*60) ;startTime:=sysdate;beginexecuteimmediatecurSQL;updatedw_etl_replication_propderpsetderp.remark=OK; Used:||to_char(round((sysdate-startTime)*24*60*60,1)),derp.last_rep_date=sysdatewhere derp.oid = i.oid;commit;exceptionwhenothersthenrtnMsg:=sqlerrm;updatedw_etl_replication_propderpsetderp.remark=rtnMsg||; Used:||to_char(round((sysdate-startTime)*24*60*60,1)),derp.last_rep_date=sysdatewhere derp.oid = i.oid;commit;end;endloop;endproc_wms_trans_capture;/由于是第一次见这个包，先分析下这个过程的作用，首先，它将dw_etl_replication_prop的条件查询做成一个循环，利用其中的字段拼凑成SQL语句。下面是一个嵌套的PL/SQL语句块，首先，执行上面拼凑好的SQL，然后再更新dw_etl_replication_prop这张纪录表说明同步成功，若有任何异常，也同样纪录这张表。我们暂时把这个拼凑的SQL称为SQL1，下面的2个对纪录表的更新SQL称为SQL2，SQL3。看到这里，可猜测问题出在SQL1语句上，或因表结构变动导致无法成功执行，当然，如果大家细心，会发现这段SQL3部分有不严密的地方，即在最下面插入发现异常被捕获后，立刻SQL3对插入失败进行了纪录。假如SQL1成功而SQL2失败了呢？按下面的语句，则是成功插入，但纪录了插入失败，交提交了。当然，这样的情况一般不会出现，只是希望大家在捕获异常部分，可能先判断前面有没有可能成功但要被撤消的SQL，保证逻辑上了一致性。我们继续来分析下解决的思路，因为这是一个包体，我们不方便修改后直接进行编译，否则可能会阻塞包体的正常应用或编译time out。这时我们留意下包体的头部，看下有没有公共变量的声明，结果没有，即这个过程是一个独立的过程，我们将代码复制，然后将过程更名，这样即得一个独立的过程，再进行分析。既然