如何处理大数据量抽数长期无响应

在一个项目上线过程中，由于一些模型数据量巨大，抽数十分缓慢，长期在黄灯状态，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. 若监控器的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时，最好按时间段或凭证号分次上数。