使用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