建模时遇到过哪些问题
CUBE与DSO的选择,CUBE中数据尽量保持粒度不要太明细;
上线遇到过什么问题?
软件环境,一点就报错,提示BW函数出错,实际是GUI的问题,覆盖两个OCX文件,用Regsrv32.exe注册一下就好了
数据上传出错怎么办?
点开错误堆栈,查看报错,分析报错内容,看是由请求引起的还是数据本身有问题
处理链出错怎么办?
SM59 测试RFC连接,SM50查看后台运行的进程,是否有执行时间超长的进程,可能是进程卡死导致,手动停止该进程。sm37查看后台job,任务被取消了
如何抽取汇率?
RSCUR 设置汇率转换
如何在 query 中把默认的转换汇率改成期末汇率 ? 在 query 中默认的汇率转换类型都是 “M” ,但现在我需要把一个报表的转换汇率改成期末汇率,即汇率类型为 “V”. ?
在 RSCUR 中创建新的货币转换类型就可以了
现在有一个 QUERY 运行十分慢 , 所以我想在 BW 里找到一个工具来分析这个 QUERY 是怎么运行的 . 想知道慢在什么地方 , 用了多少时间等一些具体信息 .
在 BW 中使用交易代码 RSRT
填上需要测试的报表的技术名称
单击执行 + 调试
勾选弹出的调试选项对话框的其他中的显示统计数据和未使用高速缓存
输入 Querry 的所需要的变量,运行
结果回来之后, F3 返回 统计数据界面:将持续时间求和减去时间等待时间、用户的时间,得到的时间作为该报表的统计时间
报表执行的速度一般都是
cache > BIA > Aggregate > Cube 自身 ..
所以第二次执行,能从 cache 取数的话,自然就快 了
现在有个问题,对于同一个 Transformation ,其中有个字段,需要针对不同的 DTP ,赋予不同的值,请问如果处理,谢谢!
1 可以在表 tvarvc 中建一个变量
2 然后在不同的 dtp 中的 transfert routine 里写 赋值给上面变量 的 code : 比如 dtp A 执行则赋变量的值 为 A 若 dtp B 则变量的 值为 B 。。。。
3 然后在 transformation start routine 中 去读 变量的值 看是从哪个 dtp 过来的 ,然后更改处理规则 。
1、 建立一个表;
2、 在 DTP 的过滤条件中写代码给表插入一条记录;
3、 在转换中去读取该表中的记录,并在结束例程中删除表中记录。
确定你的情况必须要要用合计 ? 用合计的 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 方式 .
1、 仅成功登记 / 更新请求 ==== 就是指成功更新到 DSO 或者 CUBE 的数据请求
2 、仅那些未在数据目标中登记的带有错误的请求 ==== 就是出错了,没有更新到 DSO 或者 CUBE 的请求
3 、仅删除装载请求,不要删除激活请求( ODSR...)==== 这个应该是说成功装载但是没有上传到 DSO 或者 CUBE 的请求吧。
一般来说,我们是删除前 30 天的请求,保留一个月的请求数据即可,这样做的好处是还能节省一下磁盘空间 。
FI-AP 、 AR 的设计就是抽取前面一天的数据,因此增量不能抽取到当天的数据。
如果数据量不大的话,建议进行全量抽取,然后在 BW 使用 DSO 进行增量的处理 。
BW 中,存在两种数据抽取方式,完全更新与增量更新,完全更新是每次把截至到某个时间的数据全部抽取,增量抽取则只抽取上次和本次抽取之间更新的数据,很显然,增量抽取能够提高系统效率,根据 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来处理数据。
每次 DSO 数据进行激活更新时,都会在 change log 表产生一个 request ,这个 request 对应这次请求发生改变的所有记录,如果是新记录, change log table中的 recordmode = N, 如果是更改,那么会产生 2 条记录,一条 recordmode = X 代表修改前,另外一条 recordmode = " " 表示修改后。
往 cube 上 delta 更新的时候,就是靠这些来获取变化量的,新产生的 request 中的那些记录。