day 8.1 system_admin_tasks
TRANSCRIPT
Day 8
SAP BW Training
System Administration Tasks
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
Challenges
Modelling parallelization
for optimal performance
Avoid lock
situations
Guarantee correct
sequence of
administration
processes
Avoid
unwanted
dependencies
Performance
Stability
Requirements Cost
5
BI Admin Cockpit (1)
6
Process Chains
7
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
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
Admin of InfoCubes
11
Requests
12
Compressing Cubes
13
Admin of DSO: Overview
14
Admin of DSO: Contents
15
Admin of DSO: Requests
16
Admin of DSO: Change-Log Deletion
In management for the DSO, choose Environment→ Delete Change Log Data.
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
Basic InfoCube vs. VirtualProvider
19
Infoproviders vs. Data Targets
20
Direct Access by Virtual-Provider
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
Direct Access by DTP
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
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
‘Re’- Modeling
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
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
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
DataSources Based on Flat Files
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
RDA – Real Time Data Acquisition
Analysis reporting (OLAP) vs. Operational reporting (OLTP)
32
RDA: Definition and Features
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
RDA Architecture
Thank You.