BW:处理链报错解决步骤
昨晚的进程链居然报错了，问题很诡异
这是一个GL的模型，infopackage每次执行都说Error occurred in the data selection ，在BW这边查过ST22和SM21，都没有异常。
后来一想，人家都说了，问题出在Extraction的时候，应该去R3查啊
于是Environment--》Job Overview--》Source System
果然啊，是被取消的，也就是说这个东西并不是现在出的错，而是源于过去
PS：之前碰到过一次很恶心的，是因为R3那边后台进程占用了Extractor的资源，一直黄灯而且数据保持0条。
另外，也不能小看Monitor的Step-By-Step Analysis，有些时候还是很好用的，不过最好用EN登陆，翻译上会有问题。这里也会告诉你问题出在Source System。
好吧，既然问题出在R3，那到底是什么问题呢。
SM59，测下RFC连接，没问题啊
SM51，看看server，active，很正常
SM50
去看看后台有啥在跑呢，点了下CPU那个按钮，发现有一个Process已经执行了大约19个小时，账号居然是我的...嘿，这不是昨天下班儿那会儿的嘛
折回到SM21，看了下果然有错误
于是乎，二话不说，直接干掉Process，回来再做抽取，万事OK
其实总结起来，也蛮简单的，要么是BW这边出了问题，也许是激活呀，例程呀，数据呀，或者比较变态的FI数据源上载顺序呀，等等，有的时候会因为session、process到了阀值啊，或者RFC的问题，日志满了，表空间满了，节点满了，都有可能影响数据抽取。不过相对来说比较好找，毕竟有Basis在。
到了R3那边就相对麻烦了，问题也很繁琐，特别是对于增强过的数据源，我遇到过那种直接跑死的不过跑到SM50干进程也倒是一劳永逸的方式，但是要注意安全。
另外，陈老师有一篇博客，讲的也蛮好，不过没怎么用到过这么复杂的。转来
如何处理大数据量抽数长期无响应？
在一个项目上线过程中，由于一些模型数据量巨大，抽数十分缓慢，长期在黄灯状态，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时，最好按时间段或凭证号分次上数。
这个是很早之前写的，讲的不够全面，先放上来，有时间再慢慢改。欢迎大家补充...
满怀希望，期待未知的旅程。
Pasted from <http://blog.vsharing.com/WKingChen/A1151720.html>