1291人阅读
BW、BI（14）
现在有一个 QUERY
运行十分慢 , 所以我想在
BW 里找到一个工具来分析这个 QUERY
是怎么运行的 . 想知道慢在什么地方 ,
用了多少时间等一些具体信息 .
中使用交易代码 RSRT 填上需要测试的报表的技术名称 单击执行 +
调试 勾选弹出的调试选项对话框的其他中的显示统计数据和未使用高速缓存
输入 Querry
的所需要的变量，运行 结果回来之后， F3
返回 统计数据界面：将持续时间求和减去时间等待时间、用户的时间，得到的时间作为该报表的统计时间 报表执行的速度一般都是
cache & BIA & Aggregate & Cube 自身 ..
所以第二次执行，能从 cache
取数的话，自然就快 了
我在激活一个 DSO
时，由于数据量比较大，差不多有 2 千多万条的数据，之前的传输进程都是绿灯，可在激活过程中，就变成了红灯，不管激活多少次也是红灯，请问这个是什么原因啊
DSO 是主要做报表用，还是做数据存放及 delta
用，如果是后者的话，更改 DSO 的属性把 “SIDs Generation upon Activation”
的勾弃掉，如果是前者，可以通过事务 “RSODSO_SETTINGS”
调整相应参数来提高你的 active 的效率。
Parameter for SID Generation
中， Maximum package Size
是 2 万， maximum wait time for process
是 600(10 分钟
) ，这个数字是否是越大越好 ?
Maximum package Size 是根据你的内存来设的， maximum wait time for process
可以长一点。
分配工作簿 ” 后，收到了邮件，可是
Excel 里的中文都是井号 “#######”
，请问该怎么解决？谢谢！
BW 是 3.5 的。
BW 系统，关闭所有 BW
系统的窗口和 EXCEL 的窗口；
右键点击 “ 我的电脑
” ，选择 “ 属性
”――&“ 高级 ”――&“
环境变量 ”--“ 系统变量 ”--“
新建 ” ，变量名： SAP_CODEPAGE
变量值： 8400
依次点击 “ 确定
” ，保存新增的环境变量 .
不行的话，重启下机器，另外注意用户名密码输入界面下的语言输入 ZH
我目前在做一个
供应商分析 的报表的时候碰到了一个过滤不出过滤条件的问题，望各位大侠能帮忙！谢谢！
报表是在信息提供者：设备主数据
上出的。供应商是 设备主数据
的一个 属性（导航）。在 query
里制作报表的时候行上是 ‘ 供应商 ’
，列上是 ‘ 设备数 ’
。目的是分析该供应商都提供了多少设备。当然自由特性里有个设备号，可以追溯。
但当我用 rsrt 测试报表的时候，
* 正常显示是没有问题的 *
，但想过滤出特定的供应商的时候总是过滤不出来。再追踪的时候出现如下提示：
’ 在特性 ZZCZZS
的主数据表中不存在特性值 ##################### 。因此，无法将此值传输到内部
SID 中。 ‘
在 ecc 的时候
供应商就是中文，并不像其他的设备的属性一样有个编号，然后编号可以对应一个中文。 是不是和中文有关，因为在提示里的特性值是
##### 。 有没有解决的办法？
谢谢了！！！
还有在不论是设备主数据还是供应商主数据中中文显示都正常，我在过滤的时候是选择的，而不是输入问题。
RSRC check 你的那二个特征，并修复。
工具 -- 应用层次结构 /
属性更改 -- 信息对象清单，检查设备特性是否在列表里，选中执行属性更改
SAP 后勤数据的抽取，使用的增量队列，
财务数据的抽取，使用的是时间戳，
这句话对不对？
财务数据使用时间戳，就是说不通过增量队列，数据由业务系统直接到达 BW
似乎与实际情况不符。
1 、使用 RSA7 查看增量队列时，确实可以看到财务数据源：
0FI_GL_4, 0FI_GL_6,
2 、总账凭证过账后，立即进行数据抽取， 0FI_GL_4
并不能立刻抽取到数据，而 0FI_GL_6 立刻就可以抽取到最新数据，
这是怎么回事呢？
或者我哪里理解错了？
后勤数据的抽取，使用的增量队列，
财务数据的抽取，使用的是时间戳，
这句话是对的，
总账凭证过账后，立即进行数据抽取， 0FI_GL_4
并不能立刻抽取到数据，而 0FI_GL_6 立刻就可以抽取到最新数据，
这是怎么回事呢？
那是原因这二个的时间戳的粒度不一样，一个是到时分秒的，一个只是到 posting date
和 0FI_GL_14 都是为 new GL
提供的 datasouce.
0FI_GL_4 和 0FI_GL_6
在 BW 7.x 也都是可用的
请求数据，在 R3 端执行对应的 FM
操作，获取数据，写入增量队列 。
我现在有个问题，对于同一个
Transformation ，其中有个字段，需要针对不同的 DTP
，赋予不同的值，请问如果处理，谢谢！
可以在表 tvarvc 中建一个变量
2 然后在不同的 dtp 中的
transfert routine 里写 赋值给上面变量
的 code : 比如
dtp A 执行则赋变量的值 为
A 若 dtp B 则变量的
值为 B 。。。。
3 然后在 transformation start routine
中 去读 变量的值
看是从哪个 dtp 过来的 ，然后更改处理规则
1、 建立一个表；
DTP 的过滤条件中写代码给表插入一条记录；
3、 在转换中去读取该表中的记录，并在结束例程中删除表中记录。
DSO 用来存储明细数据，其结构比较简单
, 对于值的转换 ,
既可以使用合计，也可以使用覆盖的方式。因在源端 , 　如果存在相同的
customer 记录 , 需要合并
, 为了省事 , 并没有写
abap 代码 ,
直接启用了合计的方式 , 如果使用合计的方式，可以用 delta
吗（最终的 DSO ）
? 如果可以 , 该用什么类型的
delta. 如果不可以 ,
又不想写代码 , 如何能实现合计和 delta
的两种功能 .
确定你的情况必须要要用合计
? 用合计的 kf
一般要谨慎的 确定你在的 kf
合计出的结果的正确性 ，不然整个 dso
里的数据都会错误。 delta 是
适用的 recordmode 用 after image
RSA2 查到每个数据源的 delta
属性，比如 2lis_03_bf 是 ABR,
这表示这个数据有 after image 、
before image 、 revise image.
ods 用合计不能做 delta
， 而是说 ods 一般用来记录的是合计每条数据的详细情况，如果
ods 里不做报表 你可以把
kf 当 charactestic
来理解 ，而在 cube 里面来合计
是相对于不同的 diemension 来合计你的
kf 这样是为报表多维分析服务的 。
ods的 delta是把 change log表的变化记录往上更新 , &合计 &是 key值相同下 ,keyfigure累加的
DSO, 但是得用两层 DSO,
第一层 DSO1 用 Overwrite
方式 , 用来正确获取 Delta
的 Change log 数据 ,
第二层 DSO2 从 DSO1
更新 , 可以使用 Sum
由于每隔一段时间需要对
PSA 进行清理， PSA 的数量多，而且每一个我只懂用右键
-& 管理，然后一条一条地选择需要删除的记录（批量一个时间段的，如 1-3
个月的每日 Delta ）。
请问各位高手，有没有更好的方法可以清理 PSA
1、 仅成功登记
/ 更新请求 ====
就是指成功更新到 DSO 或者 CUBE
的数据请求
2 、仅那些未在数据目标中登记的带有错误的请求 ====
就是出错了，没有更新到 DSO 或者 CUBE
3 、仅删除装载请求，不要删除激活请求（ ODSR...)====
这个应该是说成功装载但是没有上传到 DSO 或者 CUBE
的请求吧。
一般来说，我们是删除前 30 天的请求，保留一个月的请求数据即可，这样做的好处是还能节省一下磁盘空间
怎么抽取当天的数据？
、 AR 的设计就是抽取前面一天的数据，因此增量不能抽取到当天的数据。
如果数据量不大的话，建议进行全量抽取，然后在 BW
使用 DSO 进行增量的处理 。
安全上下限
中，存在两种数据抽取方式，完全更新与增量更新，完全更新是每次把截至到某个时间的数据全部抽取，增量抽取则只抽取上次和本次抽取之间更新的数据，很显然，增量抽取能够提高系统效率，根据
SAP 帮助的说法，增量更新又分为时间戳和增量队列两种方法，其中财务数据的抽取为时间戳增量法，后勤数据的抽取为增强队列法。对于增量更新，都需要先对数据抽取进行初始化，然后再进行增量的抽取。对于时间戳增量法，系统存在一个延迟时间，即时间戳设置时间与记账时间的差异，比如时间戳是根据创建时间（或输入时间）来确定是否更新的依据，而在抽取开始时（时间戳已标记），此时凭证已创建而未记账（即未更新至数据库），则此次无法抽取到该凭证，但下次抽取时，由于已在时间戳范围之外，也不再进行抽取，从而导致抽取数据遗漏，避免此问题，
SAP 帮助上给出了通过设置安全抽取时间的方法，设置视图为 BWOM2_V_SAFETY
，可根据不同的数据源设置不同的安全时间，两个小时为推荐设置
这个安全时间是对于已经创建但未保存在凭证而言，如果在这个安全时间内保存了，则此次抽取将包含在内
比如你 6小时抽取一次数据，假如你第一次在 12:00抽取，那么下次应该是 18:00抽取，那么应该来说 18:00抽取的数据是 12:00-18:00的数据才对，但是有种情况需要你考虑，比如我
11:55在做一个凭证，但是中间我去吃饭， 12:30才回来完成这个凭证，那么这个凭证就是 11:55创建的，在 12:00抽取的时候，由于凭证没有产生，因此无法抽取，但是下次 18:00抽取的时候，由于这个凭证是在 11:55创建的，所以也无法抽取到。
做 BW数据仓库最重要的一条准则就是 “不重复、不遗漏 ”，那么这样你就遗漏了数据，那么 SAP就想了个办法，就是比如这次我抽取从 06:00-12:00，那么下次我抽取从 11:30-18:00，这样上面的凭证就能抽取出来了吧，这时候
11:30-12:00就有半个小时的重复，这个就叫做 Lower Limit。
同上，比如我 12:00抽取的时候，不想抽取 06:00-12:00，而是想抽取 06:00-11:30，那么我就设置一个 Higher Limit
为 30分钟，则抽取的时候就不会到最新的时间，而是需要过账半小时前的凭证。
比如我设置了 30分钟的 Lower Limit， 30分钟的 Higher Limit，那么我 12:00抽取的数据应该是 05:00-11:30的数据，下次抽取的数据时
11:00-17:30,在下次就是 17:00-23:30，在下次就是 23:00-05:30，在下次就是 05:00-11:30，如此循环。
但是如果设置了 Lower Limit和 Higher Limit之后，请记得在 BW中使用 DSO来处理数据。
query 中把默认的转换汇率改成期末汇率
query 中默认的汇率转换类型都是 “M”
，但现在我需要把一个报表的转换汇率改成期末汇率，即汇率类型为 “V”.
该如何解决这个问题 ?
RSCUR 中创建新的货币转换类型就可以了，不过 3.5
版本中事务代码为 rrc1.
大家都知道从
dso 到 cube
进行增量抽取数据时 , 只有未被抽入 cube
的那部分增量数据才会进入 cube. 而系统具体是怎么从
change log 中判断出那部分增量数据的 ?
具体通过那些表 , 那位给讲解一下 .
DSO 数据进行激活更新时，都会在 change log
表产生一个 request ，这个 request
对应这次请求发生改变的所有记录，如果是新记录， change log table
中的 recordmode = N, 如果是更改，那么会产生
2 条记录，一条 recordmode = X
代表修改前，另外一条 recordmode = ' ' 表示修改后。
往 cube 上
delta 更新的时候，就是靠这些来获取变化量的，新产生的 request
中的那些记录。
1. Promotion detail information
如何在 BW 中取得？
2. 如何取得 weekly stock
， monthly stock by article （
quantity ， inventory value
）？（已经在使用 BI content infocube ：
0IC_C03 ）
3. 对于 trasaction data
，在 r3 做过 enhancement
的时候，加上一些 fields ，如果想在 r3
中修改这些 fields （仅仅修改这些
fields 的值），如何让修改过的 transaction data
进入 delta queue ？
4. 在 datasource
： 2LIS_03_BF 已经 daily update
到 0ic_c03 的情況下，在
R3 中用 rsa3
发现 2LIS_03_UM 有很多重复记录，该如何做使得该
datasource 中的数正常？
5. master data 从 R3
到 BW 是不是都 full load
？ Location Product infoobject ：
0MAT_PLANT 是 daily update
，但是数据量比较大（目前 600 多万），如果 full load
的话会不会时间比较久并且耗资源？有没有其他解决方案？
6. inventory management 的问题：关于 infocube
： 0IC_C03 是应该从两个
datasource ： 2LIS_03_BF
， 2LIS_03_BX 取数，还是应该从三个 datasource
： 2LIS_03_BF ，
2LIS_03_BX ， 2LIS_03_UM
7. retail price 如何在 BW
中取得？ Moving average price(MAP) 如何在
BW 中取得？
8. 在 process chain
中调用 analysis process ， auto run
的时候 analysis procee 经常会报错：
Value D4QG5ZUPU5NZBG0M4RTH9W7ZC for characteristic D4QG5ZUPU5N7MTOUT8DV7GTPK unknown
。在出错后人手去跑这个 analysis process
又正常。不知道是什麽原因 ？
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：25136次
排名：千里之外
转载：12篇
(1)(4)(14)BW后勤模块中抓取业务数据前初始化的过程_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
BW后勤模块中抓取业务数据前初始化的过程
上传于|0|0|文档简介
&&BW,填充设置表。对标准数据源的初始化需要的步骤。
阅读已结束，如果下载本文需要使用1下载券
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，查找使用更方便
还剩1页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢7378人阅读
BW数据抽取过程中，会对源系统的数据源进行相关的操作，在R/3系统中，SBIW是数据源处理的Tcode,以下对SBIW的使用进行小结：
1.一般设置（ORZ都说是一般设置了，没啥好说的）
2.业务内容数据源：在R/3端装BIC的设置，如果在BW装BIC，远程登录到R/3进行安装设置的地方就是这里.
3.用于特定应用程序数据源的设置（pi基础）：额...这个师傅也没有用过,我也没有用过,以后用到再补充了...
4.用于特定应用程序数据源的设置pi: 这个地方很有用,一般logistic的数据源,在R/3端需要进行setup,这里就可以设置,用于特定应用程序数据源的设置pi-&后勤-&管理提取结构-&初始化-&填充设置表-&找到对应的数据源进行初始化.(注意:如果对BIC数据源进行增强,需要先删除后勤数据在R/3的初始化,否则报错,增强处理自动结束,删除的方法是后勤-&管理提取结构-&初始化-&删除设置表的内容-&找到对应的数据源进行删除).如果无法判断是否已经进行初始化设置,建议删除填充表内容后再进行一次初始化,初始化时间可以定为一天(一般情况下一天足够,当然也不排除PA教材上忽悠你的N天初始化的可能性).初始化相关的log日志,可以查询.
5.一般数据源: 可以新建FILE文件或者ZTABLE数据源.
6.数据源的后处理: 这里也很有用,可以对标准数据源进行增强处理,详情参见blog文章:BW数据抽取增强.
以上内容是实际使用的小结,还有很多地方没有说明,有待日后使用进一步补充.
最后注意点: BI7.0后,一般对数据源进行增强或修改以后,需要在BI端进行replicated.否则一切的工作只存在于R/3,BW没有任何改变,自然一切就是白搭.
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：15702次
排名：千里之外Detal方式_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
上传于|0|0|暂无简介
阅读已结束，如果下载本文需要使用0下载券
想免费下载更多文档？
定制HR最喜欢的简历
你可能喜欢}