Optimizing performance of ODS objects(来自sap notes 384023)

  1. 1. Size of the table for new data (techn. M-table)

              The size of the table for new data of the ODS object should not exceed 1 million data records. The system stores up to 1 million data records in the main memory and the verification to existing records in the table for new data is made in a common request. However, this only applies when the ODS object is being updated by an InfoSource that contains all the InfoObjects of the ODS object. If only individual key figures are changed, then the update is implemented by individual selects.

With more than 1 million data records, this validation is made by individual selects, which prolongs the load time.
              Therefore note:

    1. a) Activate more frequently so that the size of the table with new data remains small.
    1. b) However, if the table increases to more than 1 million data records, you should split the data packets into several requests in order to ensure a good performance. This can be achieved by generating several requests which are loaded more frequently.

              Simultaneously,

    1. c) the data packets within a request should be greater than 10% of the table for new data, that means greater than 10% of the newly loaded, not yet activated records. Example: For a number of 1 million data records, that means that the number of records within the data packet is at least 100 000. If this is not the case, the system does not load the data into the main memory but executes a sinle select against the table for new data, which in turn would affect the performance.
  1. 2. Initialization before deltas

              In order to load data into an ODS object, you should first make an initialization and afterwards load deltas. That the table for new data should not exceed 1 million data records applies also to the initialization. If necessary, you must make the initialization in several steps by using selection criteria.

  1. 3. Avoiding SIDs

              The creation of SIDs is time-consuming and can be avoided in the following cases:

    1. a) You should not set the indicator for BEx Reporting if you use the ODS object only as a data storage. Otherwise, setting this indicator will have the effect that SIDs are generated for all new characteristic values.
    1. b) If you use line items (for example document number, time stamp and so on) as characteristics in the ODS object, you should mark them as 'Exclusively attribute' in the Characteristics Maintenance.
  1. 4. DB partitioning on the table for active data (techn. A table)

              You can accelerate the deletion of data from the ODS object by partitioning on database level. Select the characteristic according to which you want to delete as partitioning criterion. Refer to the database documentation (DBMS CD) for more details on the partitioning of database tables. Partitioning is supported on the following databases: Oracle, DB2/390, Informix.

  1. 5. Indexing

              You should use selection criteria for queries on ODS objects. If the key fields are specified, the system uses the existing primary index. The characteristic to which the system accesses frequently should be left-aligned.

              However, if the key fields are only incompletely specified in the selection criteria (recognizable in the SQL trace), you can optimize the runtime of the query by creating additional indexes. You must maintain these secondary indexes manually in Transaction SE11.

  1. 6. Locking by parallel loading

              First,you should always load data into the PSA and only if this activity is completed, you should update the data into an ODS object. If you update directly into an ODS object from a source system, the system may parallel the load process. However, in the case of parallel processing,the first process triggers a table lock (for consistency reasons and performance reasons) so that the subsequent process can no longer write into the ODS table and thus a termination occurs.

              These locks can also occur when you use the Data Mart interfaces. For this reason you should set field DREQSER of the entry for DELTA = 'CUBE' from '0' to '2' in table RODELTAM if you extract within the BW via the Myself connection from InfoCubes into an ODS object. As a result, the data packets run into the ODS object in sequence. 



Trackback: http://tb.blog.youkuaiyun.com/TrackBack.aspx?PostId=1601739


课程设计报告:总体方案设计说明 一、软件开发环境配置 本系统采用C++作为核心编程语言,结合Qt 5.12.7框架进行图形用户界面开发。数据库管理系统选用MySQL,用于存储用户数据与小精灵信息。集成开发环境为Qt Creator,操作系统平台为Windows 10。 二、窗口界面架构设计 系统界面由多个功能模块构成,各模块职责明确,具体如下: 1. 起始界面模块(Widget) 作为应用程序的入口界面,提供初始导航功能。 2. 身份验证模块(Login) 负责处理用户登录与账户注册流程,实现身份认证机制。 3. 游戏主大厅模块(Lobby) 作为用户登录后的核心交互区域,集成各项功能入口。 4. 资源管理模块(BagWidget) 展示用户持有的全部小精灵资产,提供可视化资源管理界面。 5. 精灵详情模块(SpiritInfo) 呈现选定小精灵的完整属性数据与状态信息。 6. 用户名录模块(UserList) 系统内所有注册用户的基本信息列表展示界面。 7. 个人资料模块(UserInfo) 显示当前用户的详细账户资料与历史数据统计。 8. 服务器精灵选择模块(Choose) 对战准备阶段,从服务器可用精灵池中选取参战单位的专用界面。 9. 玩家精灵选择模块(Choose2) 对战准备阶段,从玩家自有精灵库中筛选参战单位的操作界面。 10. 对战演算模块(FightWidget) 实时模拟精灵对战过程,动态呈现战斗动画与状态变化。 11. 对战结算模块(ResultWidget) 对战结束后,系统生成并展示战斗结果报告与数据统计。 各模块通过统一的事件驱动机制实现数据通信与状态同步,确保系统功能的连贯性与数据一致性。界面布局遵循模块化设计原则,采用响应式视觉方案适配不同显示环境。 资源来源于网络分享,仅用于学习交流使用,请勿用于商业,如有侵权请联系我删除!
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值