工作中常见问题分析

1、一、BW DTP非法字符问题无非就是业务上搞出一堆乱七八糟的字符，这些字符到了BW这边，就变成了井号（#）这个解决办法有这么几种：1、直接改 PSAPSA可以修改，可是这样治标不治本，顶多是我们这边数据上载正常了，可是数据跟业务上 的录入还是有差别2、在转换中写 Start Routine 方法类似，不过是把 # 替换成 或者 也是和方法 1 类似， 只不过是升级了一下， 不用手工操作， 代价就是上载的效率和传输的流 程3、增强数据源这个方法比较惨，因为井号（#）在源系统中指不定是啥字符呢，仔细算算得有十几个，都控制的话代价比较大，不如写Start Routine，只不过一个PSA可能会上载到

2、多个模型，就得写多个 Start Routine 。4、找业务修改R3的数据这个好，改完了 BW再抽一遍完事儿，不过协调起来比较复杂5、增强业务系统在用户输入或者批导的时候，控制输入， 当遇到这种垃圾字符的时候， 就提示错误，禁止写 入，这是最好的办法。二、现在有一个 QUERY 运行十分慢 , 所以我想在 BW 里找到一个工具来分析这个 QUERY 是怎么运行的 . 想知道慢在什么地方 , 用了多少时间等一些具体信息 .1、在 BW 中使用交易代码 RSRT2、填上需要测试的报表的技术名称3、单击执行 + 调试4、勾选弹出的调试选项对话框的其他中的显示统计数据和未使用高速缓存5、输入 Que

3、rry 的所需要的变量，运行结果回来之后， F3 返回 统计数据界面：将持续 时间求和减去时间等待时间、用户的时间，得到的时间作为该报表的统计时间 报表执行的速度一般都是cache BIA Aggregate Cube自身 .所以第二次执行，能从 cache （缓存） 取数的话，自然就快了三、我在激活一个 DSO 时，由于数据量比较大，差不多有 2 千多万条的数据，之前的传 输进程都是绿灯，可在激活过程中， 就变成了红灯，不管激活多少次也是红灯，请问这个是 什么原因啊 ？这个 DSO 是主要做报表用，还是做数据存放及 delta 用，如果是后者的话，更改 DSO 的 属性把 “SIDs Gen

4、eration 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 可以长 一点。四、执行 “ 分配工作簿 ” 后，收到了

5、邮件，可是 Excel 里的中文都是井号 “# #” ，请问该怎么解决？谢谢！BW 是 3.5 的。退出 BW 系统，关闭所有 BW 系统的窗口和 EXCEL 的窗口；右键点击“我的电脑”，选择 “属性” 高级” 环境变量”-“系统变量”-“新建”，变量名： SAP_CODEPAGE 变量值： 8400依次点击“ 确定” ，保存新增的环境变量 .不行的话，重启下机器，另外注意用户名密码输入界面下的语言输入ZH1. 我目前在做一个 供应商分析 的报表的时候碰到了一个过滤不出过滤条件的问题，望各位大侠能帮忙！谢 谢！报表是在信息提供者：设备主数据 上出的。供应商是 设备主数据 的一个 属性(导航)

6、。在 quer y 里制作报表的时候行上是 供应商 ，列上是 设备数 。目的是分析该供应商都提供了多少设 备。当然自由特性里有个设备号，可以追溯。但当我用 rsrt 测试报表的时候， * 正常显示是没有问题的 * ，但想过滤出特定的供应商的时候总 是过滤不出来。再追踪的时候出现如下提示：在特性 ZZCZZS 的主数据表中不存在特性值 #。因此，无法将此值传输到内部 SID 中。另外在 ecc 的时候供应商就是中文， 并不像其他的设备的属性一样有个编号，然后编号可以对应一个中文。是不是和中文有关，因为在提示里的特性值是 # 。有没有解决的办法？ 谢谢了！还有在不论是设备主数据还是供应商主数据中中

7、文显示都正常，我在过滤的时候是选择的，而不是输 入问题。用 RSRC check 你的那二个特征，并修复。rsa1- 工具 - 应用层次结构 / 属性更改 - 信息对象清单，检查设备特性是否在列表里，选中执行 属性更改1. SAP 后勤数据的抽取，使用的增量队列， 财务数据的抽取，使用的是时间戳，这句话对不对？财务数据使用时间戳，就是说不通过增量队列，数据由业务系统直接到达BW 系统，似乎与实际情况不符。、使用 RSA7 查看增量队列时，确实可以看到财务数据源：0FI_GL_4,0FI_GL_6,、总账凭证过账后，立即进行数据抽取， 0FI_GL_4 并不能立刻抽取到数据，而 0FI_GL_6

8、 立刻 就可以抽取到最新数据， 这是怎么回事呢？或者我哪里理解错了？SAP 后勤数据的抽取，使用的增量队列，财务数据的抽取，使用的是时间戳，这句话是对的，总账凭证过账后，立即进行数据抽取， 0FI_GL_4 并不能立刻抽取到数据，而 0FI_GL_6 立刻就可 以抽取到最新数据， 这是怎么回事呢？ 那是原因这二个的时间戳的粒度不一样，一个是到时分秒的，一个只是到 posting date 的。0FI_GL_10 和 0FI_GL_14 都是为 new GL 提供的 datasouce.0FI_GL_4 和 0FI_GL_6 在 BW 7.x 也都是可用的 。BW 请求数据，在 R3 端执行对应

9、的 FM 操作，获取数据，写入增量队列 。1. 我现在有个问题，对于同一个 Transformation ，其中有个字段，需要针对不同的 DTP ，赋予不同 的值，请问如果处理，谢谢！可以在表 tvarvc 中建一个变量然后在不同的 dtp 中的 transfert routine 里写 赋值给上面变量 的 code : 比如 dtp A 执行 则赋变量的值 为 A 若 dtp B 则变量的 值为 B 。然后在 transformation start routine 中 去读 变量的值 看是从哪个 dtp 过来的 ，然后更改处 理规则 。、 建立一个表；、 在 DTP 的过滤条件中写代码给表

10、插入一条记录；、 在转换中去读取该表中的记录，并在结束例程中删除表中记录。1. DSO 用来存储明细数据， 其结构比较简单 , 对于值的转换 , 既可以使用合计， 也可以使用覆盖的方式。 因在源端 , 如果存在相同的 customer 记录 , 需要合并 , 为了省事 , 并没有写 abap 代码 , 直 接启用了合计的方式 , 如果使用合计的方式，可以用 delta 吗（最终的 DSO ） ? 如果可以 , 该用 什么类型的 delta. 如果不可以 , 又不想写代码 , 如何能实现合计和 delta 的两种功能 .确定你的情况必须要要用合计 ? 用合计的 kf 一般要谨慎的 确定你在的 k

11、f 合计出的结果的正确性 不然整个 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 来合

12、计你的 kf 这样是为报表多维分析服务的 。ods 的 delta 是把 change log 表的变化记录往上更新 , 合计 是 key 值相同下 ,keyfigure 累加 的 .你可以用 DSO, 但是得用两层 DSO, 第一层 DSO1 用 Overwrite 方式 , 用来正确获取 Delta 的 Change log 数据 , 第二层 DSO2 从 DSO1 更新 , 可以使用 Sum 方式 .O的数据源都是 ADD的，差额镜像，E，可以直接上述到 cube,如果上述到dso，则需要 设置成 sum，不能设置 overwrite。FI的基本都是AIE,后镜像，E，不能直接上述到cu

13、be，必须先上述到dso，并且要设置overwrite ； LO的基本都是 ABR,这个就不用说了，很明细，新、前、后、翻转的镜像都存，量很大，可是上述cube，可以上述dso，对于dso的设置也没有关系，D自建的默认是 AIE同FI（ BT的是没有提供更改方法，所以自建的统一都是AIE），E主数据的一般采用 AIE、AIM和NEWE,说明比较侧重结果和新增数据下面简述下 AIE和ABR的区别：ABR的方式注定了，不仅适合直接上载到DSO,可以直接上载到 CUBE不通过DSO,因为不仅序列化，而且是连带各种镜像。AIE不同，只支持后镜像，也就是说，只能首先加载到DSO,然后进行分析，会在激活数

14、据时帮我们补齐前镜像，到 DSO的LOG表里，从而保证了 DSO的明细要求，又能在 CUBE提 取LOG表的时候获得正确的数据。因为CUBE只有汇总，没有覆盖功能。Delete image上述时的kf是空，所有不能直接上述 cube，可以上述到dso，但是必须用 ove rwrite ；Reverse image翻转像可以上述到 cube，也可上述到 dso可以设置成 sum和overwrite ；1. 由于每隔一段时间需要对 PSA 进行清理， PSA 的数量多，而且每一个我只懂用右键 - 管理，然后 一条一条地选择需要删除的记录（批量一个时间段的，如 1-3 个月的每日 Delta ）。

15、请问各位高手，有没有更好的方法可以清理 PSA 的数据。、 仅成功登记 / 更新请求 = 就是指成功更新到 DSO 或者 CUBE 的数据请求、仅那些未在数据目标中登记的带有错误的请求 = 就是出错了，没有更新到 DSO 或者 CUBE 的请求、仅删除装载请求，不要删除激活请求（ODSR.）=这个应该是说成功装载但是没有上传到 DSO或者 CUBE 的请求吧。一般来说， 我们是删除前 30 天的请求， 保留一个月的请求数据即可， 这样做的好处是还能节省一下磁盘空间1. FI 怎么抽取当天的数据？FI-AP 、 AR 的设计就是抽取前面一天的数据，因此增量不能抽取到当天的数据。 如果数据量不大的

16、话，建议进行全量抽取，然后在 BW 使用 DSO 进行增量的处理1. 安全上下限BW 中，存在两种数据抽取方式，完全更新与增量更新，完全更新是每次把截至到某个时间的数据全 部抽取，增量抽取则只抽取上次和本次抽取之间更新的数据，很显然，增量抽取能够提高系统效率，根 据 SAP 帮助的说法，增量更新又分为时间戳和增量队列两种方法， 其中财务数据的抽取为时间戳增量 法，后勤数据的抽取为增强队列法 。对于增量更新，都需要先对数据抽取进行初始化，然后再进行增量 的抽取。对于时间戳增量法，系统存在一个延迟时间，即时间戳设置时间与记账时间的差异，比如时间 戳是根据创建时间（或输入时间）来确定是否更新的依据，

17、而在抽取开始时（时间戳已标记），此时凭 证已创建而未记账（即未更新至数据库），则此次无法抽取到该凭证，但下次抽取时，由于已在时间戳 范围之外，也不再进行抽取，从而导致抽取数据遗漏，避免此问题， SAP 帮助上给出了通过设置安全 抽取时间的方法，设置视图为 BWOM2_V_SAFETY ，可根据不同的数据源设置不同的安全时间，两 个小时为推荐设置 这个安全时间是对于已经创建但未保存在凭证而言， 如果在这个安全时间内保存了， 则此次抽取将包含 在内，比如你 6 小时抽取一次数据，假如你第一次在 12:00 抽取，那么下次应该是 18:00 抽取，那么应该来说 18:00 抽取的数据是 12:00-

18、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 就

19、有半个小时的重复，这个就叫做 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-1

20、1:30 ，如此循环。但是如果设置了 Lower Limit 和 Higher Limit 之后，请记得在 BW 中使用 DSO 来处理数据。1. 如何在query 中把默认的转换汇率改成期末汇率?在query中默认的汇率转换类型都是“ M，但现在我需要把一个报表的转换汇率改成期末汇率，即汇率类型为“V”.该如何解决这个问题 ?在 RSCUR 中创建新的货币转换类型就可以了，不过 3.5 版本中事务代码为 rrc1.1. 大家都知道从 dso 到 cube 进行增量抽取数据时 , 只有未被抽入 cube 的那部分增量数据才会进入 cube. 而系统具体是怎么从 change log 中判断出那

21、部分增量数据的 ? 具体通过那些表 , 那位给 讲解一下 .每次 DSO 数据进行激活更新时，都会在 change log 表产生一个 request ，这个 request 对应 这次请求发生改变的所有记录，如果是新记录， change log table 中的 recordmode = N, 如果 是更改，那么会产生 2 条记录，一条 recordmode = X 代表修改前，另外一条 recordmode = 表示修改后。往 cube 上 delta 更新的时候，就是靠这些来获取变化量的，新产生的 request 中的那些记录。1. 1. Promotion detail information 如何在 BW 中取得？4. 在 datasource2LIS_03_BF已经 daily update 到 0ic_c03的情況下，在 R3 中用rsa3 发现 2LIS_03_UM有很多重复记录，该如何做使得该datasource 中的数正常？5. masterdata 从 R3 到 BW 是不是都 full load ？ LocationProductinfoo