(SAPBW学习笔记精选版二.docVIP

性能优化 InfoCube为什么快 之所以cube比ods速度快，和它采用的SID机制分不开的。众所周知integer是比char检索速度要快很多的。 再就是cube的index，cube里的所有characteristics都是key，都有索引，不然IO的效率就大大降低了。 颗粒度尽量大：尽量不要在Cube里放太detail的数据，这种需求首先考虑R3用ABAP解决，如果非要在BW，可以考虑在DSO出明细报表，在Cube出汇总报表，通过RRI接口调用明细报表。 查分多个：当Cube的数据量很大时，可以拆分成多个Cube, 再用MultiProvider拼起来，这样query会在N个Cube中并行，提高效率。这就是所谓的逻辑分区。常见的分区方式有按年月，按国家，按BU，按类型等。 压缩（慎用，最好是半年甚至一年以上的数据）：给Cube做Compression。 Compression 本质上是去掉Data Dimension，这样fact table就被压缩了，但是request id 也消失了，将无法通过request id去管理数据。 索引：数据库的索引可以加快查询速度 分区：对于很大的Cube，可以做partition, 这是物理分区，只支持按时间分区。 聚集：使用Aggregation可以提高性能。但是Aggregation本身是cube的一个子集，提高性能的同时也加大了数据冗余，所以不要用太多。 Staitics：定期刷新DB Statistics?可以提高reporting的效率。 使用MP：维度设计上，避免很多数据量很大char.放在一个维度上，因为这样会让维度表变得很大。通常，尽可能拆分成更多的维度，然后在 multiprovider层面，把相关的char都放一个维度里，然后做好Mapping，这样可以让用户更容易理解MultiProvider. 不过维度太多会导致fact table巨大，所以要做好平衡。 Line item Dimension：对于material等很大的主数据，使用Line item Dimension. BIA:使用BIA是比Aggregation更有效的方法，就是要花不少钱。 DSO Standard 标准DSO（生成主数据标识、对于相同关键字段的值进行合并、可直接出具报表）对应后台3个表，NEW TABLE/LOG TABLE/ACTIVE TABLE，即保存了DELTA增量的CHANGE LOG数据。一般通过DTP来更新数据。这种DSO也是我们用的最多的类型。 标准DSO需注意的问题 如果是激活业务内容的DSO，然后复制出来作为自己的DSO使用的话，一般不需考虑关键字段的问题，系统的设置一 般会保证DSO数据与PSA数据完全一致，但如果是自己通过直接输入信息对象创建的DSO，则需考虑值的合并，因为在标准DSO对于相同关键字段的值系统 会自动合并，这个时候需注意转换中的规则明细是覆盖还是合计，如果有合并的字段，即DSO更新的数据少于PSA的数据，建议把转换中值字段的规则明细全部 修改为合计，以保证值的正确，总之，在使用标准DSO时需考虑值的合并问题，并考虑转换的规则明细，但使用写优化的DSO则不存在该问题 建议如果采用三层数据模型架构的话，可考虑第一层使用写优化的DSO，保证该层DSO数据与PSA完全一致，第二层DSO使用标准DSO，第三层使用CUBE完全更新的数据源情况下，写优化DSO在新增数据时，会重复计算以前已抽取数据，在建立DSO时需仔细考虑DSO类型、数据更新方式、DSO关键字段和数据字段设置、以及转换中的明细规则中的集合设置为覆盖还是合计 Write-Optimized 写入优化的：（不生成主数据标识、不合并相同关键字段的值、速度快可用于存储大容量数据）这种DSO类型，用来处理大量的数据，但后台也只对应ACTIVE TABLE。通过DTP来更新数据。 一张active表，一般用于大数据量的加载。由技术关键值、语义键、数据列组成。技术关键值又包括Request GUID、Data PackageID、Data Record Number组合而成，他们确保了数据的唯一性。 优化的数据存储对象的设置中，以下的设置选项是特有的:语义的数据存储键值不惟一。这一选项仅与写优化的数据存储对象相关。数据表的技术关键字经常由数据请求标识、数据包和数据记录号组成。我们定义DSO 时指定的关键字段组成了写优化的数据存储对象的语义键。如果未设置此标识，那么系统检查语义关键字的惟一性并为关键字组合生成带有技术名称KEY 的惟一索引，出现任何相关键字组合的记录都会报错。如果设置了此标识，那么数据存储对象的数据表可以包含几个带有相同组合键的记录，它们由技术关键值区别开来，在报表的结果