使用Datastage8.1快二個年頭了,期間一直使用DS來做數據中心ETL的工作。俗話說:"工欲善其事,必先利其器。",亦有人曰"勿在浮沙築高樓",熟練掌握工具的用處可見一斑,這也是我想寫下這一系列的原因。不過,工具終究是工具,如果不能深入理解和掌握承載在工具使用上的思路和方法,那么工具也僅僅是工具而已,謹以此提醒自己。
言歸正傳。工作中使用的DS環境:RHEL4 64bit,DS8.1 。
遇到問題的場景是:數據中心上線大半年時間后,其中有一台DS ETL服務器經常報errorcode=-1004,而另外一台DS ETL服務器從未出現問題。查看Datastage的文檔可以發現1004表示該JOB未編譯。 實際情況是該DS JOB確實是編譯過的。當時考慮下出現以下情況的原因:
(1)調度程序分配DS JOB的時候,分配不均。導致其中一台DS ETL服務器的並發過高,導致出現這個原因;
(2)出現問題的DS ETL服務器配置哪里出問題了。
經過對日志的分析,發現二者的DS JOB並發度 基本上差不多,而且DS的配置是一樣的,似乎進入死胡同了。於是,想起寫個腳本來抓高並發運行時ETL服務器的CPU,MEM的狀況(CPU>10或者MEM>5的都抓出來)。
checklog=checkcpu.log
filepath=/home/dsadm
i= 0
j= 200
while [ $i -lt $j ]
do
echo `date` >> $filepath/$checklog
top -b -n 1|sed -n 7p >> $filepath/$checklog
top -b -n 1|sed -n ' 8,$ 'p|awk ' {if($9 > 10.0 || $10 > 5.0)print $0} ' >> $filepath/$checklog
echo >> $filepath/$checklog
i=$[$i+ 1]
sleep 60
done
分析日志發現,db2sysc這個進程出現的頻率很高,這證明對DS的信息進行管理的db2數據庫的壓力很大。順着這個思路,找到IBM官網給出的方案
set -x
set -b
declare -i DSTAGENUM
declare -i THRESHOLD
if [ $# -ne 1 ];then
exit 1
fi
THRESHOLD=$ 1
if [ $THRESHOLD -le 10000 ];then
THRESHOLD= 10000
fi
function getnum()
{
DSTAGE=`su - db2inst1<<EOF
db2 connect to xmeta 1>/dev/ null 2>& 1
db2 -x " select count(*) from XMETA.LOGGING_XMETAGEN_LOGGINGEVENT1466CB5F t where CATEGORYNAME_XMETA = 'IIS-DSTAGE-RUN' "
EOF`
echo $DSTAGE
}
DSTAGENUM=`getnum`
if [ " $DSTAGENUM " -ge " $THRESHOLD " ];then
cd /opt/IBM/InformationServer/ASBServer/bin
./LoggingAdmin.sh -results result.log -user wasadmin -password Dw2011ds -create -schedule -name " DS job event purge task " -frequency -minutes 2 -threshold $THRESHOLD -percentage 20 -includeCategories IIS-DSTAGE-RUN
while true
do
sleep 120
DSTAGENUM=`getnum`
if [ " $DSTAGENUM " -ge " $THRESHOLD " ];then
continue
else
./LoggingAdmin.sh -user wasadmin -password Dw2011ds -delete -schedule -name " DS job event purge task "
su - db2inst1<<EOF
db2
connect to xmeta
REORG TABLE XMETA.LOGGING_XMETAGEN_LOGGINGEVENT1466CB5F use xmetatemp
quit
EOF
break
fi
done
fi
注1:https://www-304.ibm.com/support/docview.wss?uid=swg21370048