repair full request和CUBE优化

关于repair full request

2011-05-13 23:10 152人阅读评论(0) 收藏举报

在多个地方看到过关于repair full request的面试问题，之前因为BW全程没学完一直搞不懂是什么。今早再次看到，所以一上午都在SDN上查看相关信息。算是摸了个大概出来。

先上NOTE。（原来SAP OSS NOTE是需要有授权的人才能看得到的，幸好SDN上有人把它贴了出来。）

经过几个小时的了解，现在回头来想，确实repair full request很重要，实际项目中也应该经常用到。因为虽然initial delta做好了，delta update也做好了，processing chain也做好了，并不是表示从此以后系统就规规矩矩地按常理来出牌了。它时不时还是会跳出个missing record，或者corrupt record给你，让你伤伤脑筋。

对于已经走了很长时间的delta update，BW target infoprovider已经存储了相当大的数量了，如果突然发现有missing record或者corrupt record是件很头痛的事，不可能全部删掉重新做，RSA7 delta repetition只能repete 上一次的delta，假如是很久以前的delta中间的record是没有办法重新上载的。

于是，repair full request就出现了。

repair full request是在发现有record missing或corrupt后，（如果数据是直接传往CUBE,则需先delete CUBE 中的受影响的record，不然数据再次传上来会duplicate；如果是传往DSO，这个不需要delete了，因为DSO 有覆盖功能。）新建一个infopackage，选择full update模式，然后scheduler-->repair full request,并且在package 的extract中设置好要重新抽取的data record period，然后就可以start infopackage了。后续动作DTP，transformation照做。

repair full request的最大好处就是它的执行并不会影响到initial delta update和delta update的执行。或者说，两者是平行的。

比如说，发现DSO中有一条record错误，这时就可以新建package，full update,repair full request, extract里面只选投这一条数据，重新抽取一下就行了。

当然，可以先到RSA3中（setup table）中确认一下此条数据是否正确，正确的话就可以按上面的步骤进行抽取了。

这里需要讲一下full update和delta update的不同。（也是今天上午查阅了很多资料才弄懂的。）

full update是直接从setup table中直接读取数据，所以repair full request才成为可能。

delta update是从RSA7 (queued delta)中读取数据，（数据从R3端进入SM13或者LBWQ，JOB运行后进行RSA7）；所以如果有record missing，那么RSA7中肯定不会有这个missing record的，再怎么delta repetition 也没有用，只能用repair full request来修补。

这是一个非常实际的需求。想想，也是做为了一个BW顾问必须了解的知识点。（果然老师只是给个方向，关键还是得靠自己呀！）

下面这个链接是对repair full request一个非常好的tread，SDN上的，回答得非常详细到位。

怎样delete CUBE中的受影响的record？（repair full request是在发现有record missing 或corrupt后，（如果数据是直接传往CUBE, 则需先delete CUBE中的受影响的record，不然数据再次传上来会duplicate；如果是传往DSO，这个不需要delete了，因为DSO有覆盖功能。）

请教一下：“如果数据是直接传往CUBE, 则需先delete CUBE中的受影响的record”这个怎么delete呢）答：select deletion （第三个按钮“选择性删除”，就是根据某些条件删除数据，例如某一些数据是不需要的数据，可以通过此办法删除，但是一般需要慎重，因为删除后即不可恢复。）

优化InfoCube性能

(2011-05-02 16:53:51)

转载▼

分类：BW

这个问题不仅实践中经常要遇到。

先说效率，之所以cube比ods速度快，和它采用的SID机制分不开的。众所周知integer是比char 检索速度要快很多的。

再就是cube的index，cube里的所有characteristics都是key，都有索引，不然IO的效率就大大降低了。

简单总结一下：

1. 尽量不要在Cube里放太detail的数据，这种需求首先考虑R3用ABAP解决，如果非要在BW，可以考虑在DSO出明细报表，在Cube出汇总报表，通过RRI接口调用明细报表。关于RRI，请看：

https://www.wendangku.net/doc/4a7261532.html,/saphelp_sm32/helpdata/en/99/08629bd3e41d418530c6849df303c9/content.htm

2. 当Cube的数据量很大时，可以拆分成多个Cube, 再用MultiProvider拼起来，这样query会在N 个Cube中并行，提高效率。这就是所谓的逻辑分区。常见的分区方式有按年月，按国家，按BU，按类型等。

3. 对于很大的Cube，可以做partition, 这是物理分区，只支持按时间分区。

4. 使用Aggregation可以提高性能。但是Aggregation本身是cube的一个子集，提高性能的同时也加大了数据冗余，所以不要用太多。

5. 使用BI A是比Aggregation更有效的方法，就是要花不少钱。

6. 维度设计上，避免很多数据量很大char.放在一个维度上，因为这样会让维度表变得很大。通常，尽可能拆分成更多的维度，然后在 multiprovider层面，把相关的char都放一个维度里，然后做好Mapping，这样可以让用户更容易理解MultiProvider. 不过维度太多会导致fact table巨大，所以要做好平衡。

7. 对于material等很大的主数据，使用Line item Dimension. 此类Dimension只可以有一个Char.

8. 定期刷新DB Statistics 可以提高reporting的效率。

9. 给Cube做Compression。 Compression 本质上是去掉Data Dimension，这样fact table就被压缩了，但是request id 也消失了，将无法通过request id去管理数据。

其实呢，这些都是大技巧，往往真正会使千里之堤崩溃的是蚁穴，一些小技巧。

前面提到，Cube的特征之一，所有的characteristic都是key，这是双刃剑，设计不好，也导致了一种很严重的问题。所以我们提倡，Cube要尽可能保证粒度，不要过于明细，否则会比ODS效果更差，甚至导致数据的错误。

最近就遇到一个很诡异的问题，Order在底层的ODS是正常的，可是到了Cube再做统计时，平白无故多出很多，这就是因为过于明细，所有的字段修改都会导致一条新数据的生成，这样如果用来统计条数，就杯具了。

哪些特性要加，哪些特性不要加，哪些用Cube，哪些用ODS，这都是需要慎重考虑的。

Query中特征限制和缺省值的区别<上一篇| 下一篇>

主要区别为：如果在特征限制中限制了特征值(不管是单值、多值或变量)，执行Query后，该特征值不可修改，如果在缺省值中限制了特征值(不管是单值、多值或变量)，执行Query后，该特征值可以进行修改，Portal 中，如通过缺省值限制，则点击“过滤器”后，可以在相应的特征处修改特征值，如通过特征限制对特征值进行限制，则不可以修改，但两者均可以通过点击“屏幕变量”重新输入特征值再次执行Query的方式修改特征值

BW之CUBE

2010-09-17 2:36

BW之CUBE

创建一个CUBE很简单，就是在需要的信息范围下，右键点击创建信息块即可，首先弹出的是需要输入的技术名称及描述，还可以选择从某个信息块复制，然后点击创建，就进入以下界面：

在上图的左边，是构成CUBE的信息对象目录，右边则是一个信息快的结构。

首先注意的是左图上方的几个小按钮，分别表示“信息源”、“信息对象”、“信息块（CUBE）”、“信息对象目录”及“所有信息对象”，一般来说根据需要选择自己需要的信息对象，如果我选择了某一目录后，则其下所有的信息对象会在左边呈现，如下图：

这样，我们就可以从左边选择需要的信息对象，拖动到右边对应的目录下，即开始自己的创建CUBE之旅了。

总体浏览一下这个CUBE的结构，首先是CUBE的状态，包括版本、保存状态等相关信息，一般情况下我们都是不会关心的。第二个是设置，这个地方表示这个信息块是什么类型的信息块，除了标准信息块，其他我自己也不知....；第三项就是比较关键的家伙维度了，系统首先已经给出了一些默认的维度了，包括数据包、时间及单位；一个个来看，第一个数据包，这个是跟数据加载有关的，系统记录的数据上载的ID等相关信息，

第二个是时间维度，一般来说，我们拖动一些系统自带的0CALDAY,0CALMONTH等信息对象进去就OK了，你拖其他自定义信息对象系统也不会睬你；接下来的是单位维度，这个不用我们自己考虑，当我们拖动关键值进入CUBE的时候，系统会根据关键值中的单位自动生成这样的维度。而接下来就是我们自由发挥的维度了，如下图：

右键点击维1，出现属性、这里可以设置这个维度的属性，如下

点击属性进入上图的对话框，其中描述更改维度描述，下方的两个选项都是跟CUBE数据查询效率相关，第一个“行项目维”表示当此维度只包含一个信息对象时候，勾选此项目不生成Dimension表，CUBE直接用SID与信息对象相连，提高系统访问效率；而第二个选项，则是当维度值达到一定数量（SAP说法是记录表的20%）时候，根据数据库索引等方式，提高系统查询效率；

剪切和删除略过不谈，信息对象直接输入就是加入需要的信息对象，点击后出现对话框，根据范围查找或者直接根据技术名查找即可。还可以根据需要插入其他维度，在维度编辑完成后，如果维度中信息对象带有导航属性，则可以在导航属性栏中设置是否带有导航属性，如下图所示，在勾选框中勾上√，则在查询中即可以以导航属性作为一个维度一样的来筛选数据了。

在设置好维度后，我们接下来可以设置我们CUBE的关键值字段了，选择合适的关键值信息对象拖入关键值中即可，如下图，其中可以看看每个关键值后面的属性，其中的“数据..”表示的关键值的数据类型，QUAN表示数量，CURR表示金额，而最重要的就是累计值与非累计值了，其中累计值就表示关键值是由自身的加减得到的，而非累计值则是存在流入流出的概念，其值等于流入-流出，这样实际在加载数据的时候，其本身并不需要加载数据，而只需要加载其相应的流入及流出信息对象即可，例如下图的数量总计库存。这个在库存模型中是最重要也是最困扰人的地方。

以上如果一切搞定，则可以检查激活CUBE，这样CUBE就算建立成功了。

接下来，可以仔细端详一下CUBE中有哪些需要机关了，那么就要让“管理”这个管家一同带我们走入。先粗略了解一下CUBE的表结构，其中CUBE中首先存在的两张事实表F表与E表，其中F表为数据初始加载时候的数据，这样的数据中存在着加载的时候的数据包（DTP包）信息，正是由于这个数据包（P）维度的存在，会导致F表中的数据量很大，所以当我们确认每包数据没有问题后，我们就可以做压缩的动作，压缩后系统将数据包维度去掉，这样大大减少了Fact表的数据量，并且将数据从F表转移到E表；而对于CUBE每个维度，BW会建立一个Dimension表，Dimension表中包含DIMID及组成信息对象的SID,最后事实表与信息对象通过DIMID关联。

下面通过实际来看看CUBE中数据的奥妙，选中CUBE右键点击“管理”，首先看到的“内容”标签页

其中上方即为CUBE所包含的信息对象，其中的“维”栏指的是每个信息对象数据哪个维度。而信息块内容则是指当前CUBE中的数据，他包含压缩前和压缩后的所有数据；实际表格指的就是F表，点击实际表格后，就可以看到如下：

其中表名即为/BIC/F+CUBE名称；第三个按钮“选择性删除”，就是根据某些条件删除数据，例如某一些数据是不需要的数据，可以通过此办法删除，但是一般需要慎重，因为删除后即不

第二标签页为“性能”，顾名思义，这一屏是为CUBE性能考虑而设计的，见下图

其中上半部分为创建和删除索引下半部分为创建统计。其中第一部分检查、删除及创建、修正索引为对F表中的数据进行索引创建，索引可以提升查询速度，所以很重要，但是在加载数据的时候，请务必先删除索引在添加索引，否则很容易在大量数据加载时候产生死锁（Dead Lock）；所以在处理链中向CUBE加载数据时候，一般都是加载前删除CUBE索引，而加载成功后再创建索引；第二部分为压缩后的聚集索引，即为E表的索引。而其中的数据库统计，按照SAP的解释，即为系统做一个统计以便了解CUBE、信息对象以及查询等的使用频率等，为系统的优化做一个依据，见其解释如下:

BW statistics provides you with the following options that allow you to uate data from both the OLAP processor and warehouse management. You are able to

· get an overview of how InfoProviders, InfoObjects, In foSources, source systems, queries, and aggregates are used

· determine the system performance and improve it

· improve the way in which aggregates are selected and used and reduce the cost of updating them

CUBE的第三个标签页“请求”，此页主要记录了数据加载的信息，包括每个信息包的执行时间以及数据量等信息，而其中被压缩的数据包在“信息块的压缩状态”中会打上√，如果“聚集”被压缩，则在“汇集的压缩状态”中也会打上相应的√；在“请求的数据集市”栏下，如果该CUBE被作为数据集市（即作为其他信息提供者的数据源）且该信息包数据被抽走，则会标记上一个，如果是加载后的数据包没有做压缩等处理，则可以选中点击删除将一整包数据

接下来的屏幕为“滚动”（rollup）界面，这个界面目前我所知道的作用为点击集合生成聚集（Aggregate），在生成聚集后，系统会根据相应维度生成一个数量相对CUBE事实表数据量比较小的表，当查询访问CUBE时候，系统会先判断聚集中维度是否满足条件，如果满足则直接访问聚集而不用再次访问CUBE，提升查询速度。

生成聚集可以由系统根据查询中维度使用频率自动生成或者自己直接指定生成，其中自动生成的界面如下：

上图中其中的绿色状态便是根据系统提供的一个使用频率较高的几个维度组合生成的聚集；生成的方法是选中待生成的聚集然后激活保存即可。

“折叠”（应该翻译为压缩更为贴切，SAP的汉化真的不敢恭维），这一屏的作用就是前文多次提到的压缩的概念，在“请求标识”中输入标识序列，则将该序列前所有的数据包都压缩，如果勾选“使用零排除”，则会将关键值为0的记录排除，但是这个功能只对累计的关键值有效，而对于非累计的，由于是根据其他信息对象流入流出计算而得，所以并没有作用；执行压缩后的数据会自动存入E表，并且将原先的数据包序列全部变为0，这样如果再想删除已经压缩的请求包数据，是不可能实现了，这样实现了数据的固化，也大大提高了查询的效率。

最后一屏“重新建造”是3.5的遗留产物，不了解也不必要在继续了解了，所以不谈。