在一个项目上线过程中,由于一些模型数据量巨大,抽数十分缓慢,长期在黄灯状态,monitor的消息是:missing messages.
处理几次类似问题后,总结了一点经验:
处理几次类似问题后,总结了一点经验:
首先检查系统的一些参数设置是否正确,和抽数相关的参数包括:
1. 检查系统链接是否正常:SM59
2. SBIW进行传输设置:
IDOC频率:多少个数据IDOC后返回一个消息IDOC(monitor中,要收到消息IDOC才能确认数据传输完成,否则一直等待直到报missing messages错误)。当IDOC数据包比较大时,建议降低频率,这样可以及时发现问题。一般在5-10之间,不超过20。
IDOC数据包:每个数据包包含几条记录,通常在5000~20000之间。一般,每个加载进程不要超过100个数据包,因此大抽取大量业务数据时,最好将该值设得大一点。例如:50000(oracle/sql server)或10000(informix)
3. 根据数据量,估计设置infopackage执行时的最长等待时间, 并设置好timeout的时间
4. 设置TRFC最大连接数:SM58
1. 检查系统链接是否正常:SM59
2. SBIW进行传输设置:
IDOC频率:多少个数据IDOC后返回一个消息IDOC(monitor中,要收到消息IDOC才能确认数据传输完成,否则一直等待直到报missing messages错误)。当IDOC数据包比较大时,建议降低频率,这样可以及时发现问题。一般在5-10之间,不超过20。
IDOC数据包:每个数据包包含几条记录,通常在5000~20000之间。一般,每个加载进程不要超过100个数据包,因此大抽取大量业务数据时,最好将该值设得大一点。例如:50000(oracle/sql server)或10000(informix)
3. 根据数据量,估计设置infopackage执行时的最长等待时间, 并设置好timeout的时间
4. 设置TRFC最大连接数:SM58
然后,根据监控器反馈的信息及时处理问题:
1. 若监控器的xxxx from yyyy一直在变化,说明数据一直在传输中,正常情况下会一直到xxxx=yyyy,yyyy为源的数据量。
2. 若监控器的xxxx from yyyy不动了,则有问题,应当看看detail的消息。一般会出现missing messages, 是抽数线程太多造成SQL 死锁。这时,则应通过SM50观察抽数进程是否扔在工作。若抽数进程不动了,应去SM58观察TRFC的情况,手工执行(F6)死锁的TRFC以及长时间等待的TRFC。此时SM50中的进程应该继续工作了。
3. 观察监控器,直到数据全部抽取到BW并完成处理。若数据全部抽完(xxxx=yyyy),但一直出于missing messages的黄灯或红灯状态,则可以手工置红request,然后手工更新数据包,然后再手工置绿。有时,还需要手工roll up.
4. 数据量大的话,最好先做full update,然后再做无数据的initial
5. 数据量很大的话(千万以上),full update时,最好按时间段或凭证号分次上数。
1. 若监控器的xxxx from yyyy一直在变化,说明数据一直在传输中,正常情况下会一直到xxxx=yyyy,yyyy为源的数据量。
2. 若监控器的xxxx from yyyy不动了,则有问题,应当看看detail的消息。一般会出现missing messages, 是抽数线程太多造成SQL 死锁。这时,则应通过SM50观察抽数进程是否扔在工作。若抽数进程不动了,应去SM58观察TRFC的情况,手工执行(F6)死锁的TRFC以及长时间等待的TRFC。此时SM50中的进程应该继续工作了。
3. 观察监控器,直到数据全部抽取到BW并完成处理。若数据全部抽完(xxxx=yyyy),但一直出于missing messages的黄灯或红灯状态,则可以手工置红request,然后手工更新数据包,然后再手工置绿。有时,还需要手工roll up.
4. 数据量大的话,最好先做full update,然后再做无数据的initial
5. 数据量很大的话(千万以上),full update时,最好按时间段或凭证号分次上数。