Day 8.1 system_admin_tasks

810 views
693 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
810
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
123
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Day 8.1 system_admin_tasks

  1. 1. Day 8 SAP BW Training
  2. 2. System Administration Tasks
  3. 3. 3 Purpose Daily and periodic tasks needed to maintain the data warehouse List the tools available for administration of the warehouse System Administrator's job
  4. 4. 4 Challenges Modelling parallelization for optimal performance Avoid lock situations Guarantee correct sequence of administration processes Avoid unwanted dependencies Performance Stability Requirements Cost
  5. 5. 5 BI Admin Cockpit (1)
  6. 6. 6 Process Chains
  7. 7. 7
  8. 8. 8 BI Admin Cockpit (2) 1. 2. 3. Change Run (updates) 4. Broadcasting (mailing lists) 5. Analysis Authorization (RSECADMIN) 6. Meta-Data Search and Documents (RSODADMIN) 7. Remodeling (RSMRT) 8. Repartitioning (table-level partitioning) 9. Request Administration Archiving (archive old request) 10.Analysis of BI Objects (RSRV) 11.Current Settings (Standard Config. Tasks)
  9. 9. 9 Admin of InfoCubes . Contents 1. View data 2. Selective Deletion . Performance (Indexes) 1. Delete Indexes, 2. Repair Indexes, and 3. Create Index (Batch) . Requests • Request ID # and Status [Green/Yellow/Red] . Roll-Up (Aggregate-it for baby-infocubes) . Compress (zip the data) . Reconstruct ( Only valid with 3.x data flow objects)
  10. 10. 10 Admin of InfoCubes
  11. 11. 11 Requests
  12. 12. 12 Compressing Cubes
  13. 13. 13 Admin of DSO: Overview
  14. 14. 14 Admin of DSO: Contents
  15. 15. 15 Admin of DSO: Requests
  16. 16. 16 Admin of DSO: Change-Log Deletion In management for the DSO, choose Environment→ Delete Change Log Data.
  17. 17. 17 Virtual Provider VirtualProviders are InfoProviders with transaction/master data that is not stored in the object itself, but which is read directly in reporting.
  18. 18. 18 Basic InfoCube vs. VirtualProvider
  19. 19. 19 Infoproviders vs. Data Targets
  20. 20. 20 Direct Access by Virtual-Provider
  21. 21. 21 Virtual Providers - Types Various VirtualProviders are available depending upon their use in these different scenarios: 1. VirtualProviders based on Data Transfer Processes (Direct-access DTP). 2. VirtualProviders with BAPIs 3. VirtualProviders with function modules
  22. 22. 22 Direct Access by DTP
  23. 23. 23 [1] Direct Access – Virtual Providers Use this VirtualProvider if:  You need very up-to-date data from an SAP source system  You only access a small amount of data from time to time  Only a few users execute queries simultaneously on the database Do not use this VirtualProvider if:  You request a large amount of data in the first query navigation step, and no  appropriate aggregates are available in the source system  A lot of users execute queries simultaneously  You frequently access the same data
  24. 24. 24 Other Virtual Providers [2] The BAPI-based option allows reporting using data from non-SAP systems. The external system transfers the requested data to the OLAP processor via the BAPI. [3] The function-module-based VirtualProvider supplies a clean interface to allow your custom code to be the source data. • It is a very flexible way to populate a VirtualProvider, • but it is also more work, as you own code must be created. – One example of the use of these function-module-filled providers is in Business Consolidation.
  25. 25. 25 ‘Re’- Modeling
  26. 26. 26 Options for changing the data model of an InfoCube There are different options for changing a data model of an InfoCube: 1. Adding a navigation attribute or a hierarchy 2. Adding a characteristic 3. Adding a key figure 4. Changing the dimension tables Concern 1: If you want to include a navigation attribute in your data model, you can activate an existing display attribute in a characteristic from a navigation attribute. If the required attribute is not available, you can include it in the attribute table; however, you must then load the relevant master data of the characteristic. Concern 2 & 3: If you also want to enrich your historical data with the new information, you must delete the data in your InfoCube, insert the new InfoObject and reload the data. You must also add the new information, that is, integrate it in the data flow. Concern 4: In this case, you must first delete the data in your InfoCube; you can then rebuild the dimension tables and load the data again.
  27. 27. 27 Prerequisites Before you start remodeling, we recommend that you backup data for security. In addition, ensure the following: 1. You must stop process chains that run at regular intervals and affect the relevant InfoProvider until the remodeling is complete. 2. There must be sufficient tablespace on the database. 3. After remodeling, you must check which BI objects linked to the InfoProvider were deactivated (for example, transformation rules, MultiProviders, queries). You must manually reactivate these. Caution: During the remodeling process, the InfoCube is locked against loading and changes. All dependent objects are deactivated and must be reactivated manually afterwards. Aggregates and BI accelerator indexes must be reconstructed. The valid authorization objects are the same as those for maintaining InfoCubes.
  28. 28. 28 Features A remodeling rule is a collection of changes to your InfoCube that you perform simultaneously. For InfoCubes, you have the following remodeling options: For characteristics: 1. You can add or replace characteristics with the following:  A Constant  An attribute of an InfoObject of the same dimension  A value of another InfoObject of the same dimension  A customer exit (for user-specific source code) 2. You can delete characteristics. For key figures:  You can add a constant.  You can add a customer exit (for user-specific source code).  You can replace key figures using a customer exit (for user-specific source code).  You can delete key figures. Note: It is not yet possible to remodel InfoObjects and DataStore objects. This function is planned for future releases.
  29. 29. 29 DataSources Based on Flat Files
  30. 30. 30 DataSources Based on Flat Files Object that contains all the settings necessary to load and parse a file when it is initiated by the InfoPackage:
  31. 31. 31 RDA – Real Time Data Acquisition Analysis reporting (OLAP) vs. Operational reporting (OLTP)
  32. 32. 32 RDA: Definition and Features
  33. 33. 33 RDA Implementation Data can be transferred from the source to the entry layer in BI (the PSA) in two ways: 1. Using a Web Service push: – A Web service push can write the data directly from the source to the PSA. – The data transfer is not controlled by BI. – An InfoPackage (for full upload) is required only to specify request-related settings for RDA; – it is never executed, as the data is pushed into the BI PSA by a Web service. 2. Using the BI Service API: – If the source data is based on a source in an SAP source system, the BI Service API is used. – Many of the steps are the same as with normal delta extractions, such as the requirement for an InfoPackage to initialize delta. This step allows for delta loads to occur in the future. • DataSources used for RDA cannot be used for standard extraction (scheduling using InfoPackages). – DataSource can have one extraction mechanism only (RDA or scheduled data transfer). – Reason: Delta Mechanism & Delta-Queue (1 DataSource per Client only)
  34. 34. 34 RDA Architecture
  35. 35. Thank You.

×