FAQ: SAP MaxDB indexes

admin — Sat, 28 Nov 2009 03:36:04 +0000

Symptom

This note consists of questions and answers about indexes in MaxDB/liveCache /content server/SAP DB databases.
General and frequent questions about indexes are answered, although this note does not claim to be exhaustive.

1. What is an index?2. What are indexes used for?3. What is the technical structure of indexes?4. Is the primary key for MaxDB also stored in a separate index-B* tree?5. How is data accessed using an index?6. How can I display the structure of an index?7. How can I view information about the state of indexes?8. Can I deactivate indexes?9. What do I need to consider when I create new indexes?10. What must I take into consideration with regard to index design?11. How can I create an index?12. What search strategies are there with indexes?13. Can indexes fragment in the MaxDB?14. Can I check individual indexes for consistency?15. Can an index become larger than the table to which it belongs?16. Can I create an index on a view?17. Can the table or indexes become smaller after a data loading process with R3load?18. What are BAD indexes, how do they come about, and how can I eliminate them?19. What happens if a UNIQUE index is set to BAD?20. What is the parallel index creation?21. Which phases occur during the index creation?22. Why may it take a long time until a task is available again after you cancel the user task to cancel the creation of an index?23. Can I create several indexes simultaneously?24. Will locks be set with “Create Index”?25. How can I speed up the index build?26. Must I carry out an update statistics for indexes?27. Where can I find more information on indexes?Other terms

FAQ, MaxDB, indexes, index, secondary key, primary key
Reason and Prerequisites

You use the SAP MaxDB database system.
Further FAQ notes about MaxDB/liveCache are available on SDN (SAP Developer Network):
https://wiki.sdn.sap.com/wiki/x/GkM
Solution
1. What is an index?
You can create an index (also known as secondary key) to speed up the search for database records in a table. An index is a database object that can be defined for a single column or a sequence of columns of a database table.
In technical terms, indexes are data structures (consisting of one or more inverting lists), which store parts of the data of a table in a separate B* tree structure. This storage sorts the data according to the inverting key fields that were used. Due to this type of storage, the table data can be accessed faster using the indexed columns than without the relevant index.
Indexes, unlike tables, do not include any independent business data, and therefore can always be created again by the table. For example, this is relevant if corruption occurs on the index due to hardware problems.2. What are indexes used for?
Indexes enable faster access to the rows of a table.
You can build indexes for a single column or for a sequence of columns.
The definition of indexes determines whether the column value of different rows in the indexed columns must be unique or not (UNIQUE or NON-UNIQUE index).
An assigned index name and the table names must be unique.
Therefore, there can be several indexes with the same name, but not for the same table, for each database user or scheme.3. What is the technical structure of indexes?
Indexes, like tables, are implemented as B* trees in the MaxDB. These consist of a root node that forms a tree with the subsequent nodes.
The complete index key and the references to the table data are in the lowest level of the index tree, otherwise known as the leaf level. The MaxDB does not use physical items to identify these references, but instead these are saved in the primary key of the data records. You can identify the data record using the primary key. (The physical position of this data record is determined by the converter.)
Since access to the data does not follow the sequence Primary key -> Data, but rather Data -> Primary key, it is also known as an inversion.
The idea behind this is that the relational table design provides for the fact that all data is dependent on a unique primary key.
While the access Primary key -> Data always collects one or no rows, the access Data -> Primary key collects no, one or multiple rows.4. Is the primary key for MaxDB also stored in a separate index-B* tree?
Each database table has a primary key (primary index). The primary key is either defined by the user or generated by the system. A user-defined primary key can consist of one or more columns. The primary key must have a unique value for each row of the table.
The primary key is implemented directly on the data tree, which means there is no separate primary key tree. There is no ROWID or anything similar. The unique identification of a record is the primary key (for multiple keys, this is the combination of fields that are defined as the primary key).5. How is data accessed using an index?
If the MaxDB optimizer evaluates access using the index as the best solution, the primary keys of the table that match the index key fields used are determined in the table tree.
The corresponding rows are read from the table using this list of primary keys.6. How can I display the structure of an index?
You can display the CREATE INDEX command, with which the index is created, using Problem analysis -> Indexes in transaction DB50.
The indexes of a table can be determined using the system table ‘indexcolumns’.
SELECT owner, tablename, indexname, type, columnname,
sort, columnno, datatype, len, createdate
FROM domain.indexcolumns
WHERE owner =
AND schemaname =
AND tablename =

ORDER BY owner, tablename, indexname, columnno
The index structure is relevant for the later analysis of the SQL statement. Using the indexed columns (columnname), you can determine whether an SQL statement can be processed with this index, or if a new index with another index structure should be created.7. How can I view information about the state of indexes?
This information is contained in the system table INDEXES:
SELECT tablename, indexname, index_used, indexusedresetdate, indexusedresettime, filestate , disabled
FROM domain.indexes
WHERE owner =
AND schemaname =
AND tablename =

ORDER BY tablename, indexname
If structural inconsistencies are detected when you access an index, access to this index is locked, and the index is set to BAD (filestate column):
If the index is deactivated, the column DISABLED is set to YES.
If the column INDEX_USED has a value less than 0, the index has already been used to access a table. As of Release 7.6.00 build 19, the columns INDEXUSEDRESETDATE and INDEXUSEDRESETTIME can also be output in the system table INDEXES. They specify when the counter for INDEX_USED was last initialized.
This counter can be initialized with the following SQL statement: ALTER INDEX On
INIT USAGE
In transaction DB50, the information can be displayed using Problem analysis -> Indexes.
Comment: Even if SAP standard indexes were not previously used, they may not be deleted, since inconsistencies between the SAP data dictionary and the database catalog would arise and could lead to problems during an SAP upgrade.
8. Can I deactivate indexes?
Yes. Indexes can be deactivated implicitly by the database system or also explicitly by the administrator. Indexes that are deactivated are no longer used by the optimizer for access, but are still maintained by the database system, that means, each change to the table data is also maintained in the index.
Indexes can be deactivated to exclude indexes (for test purposes) from the optimization of the data access using the following SQL command:
ALTER INDEX on .
DISABLE
To activate the index again, use the command:
ALTER INDEX on .
DISABLE
In SAP WebAS, indexes can be deactivated or activated using transaction DB50. To find this function, use transaction DB50 -> Problem analysis -> Indexes. The buttons there are called “Allow index access” and “Forbid index access”.9. What do I need to consider when I create new indexes?
Indexes are additional data structures that must be maintained with each change to the table data. Therefore, the effort involved in a data change (insert, update, delete) in the database increases with the number of indexes in a table. You should therefore ensure that the indexes you create in the customer namespace are actually used by the application also.10. What must I take into consideration with regard to index design?
Indexes of the MaxDB always contain the primary key information.
Therefore, it is normally pointless to include the field MANDT in an index in an SAP system.
In addition, you should also ensure that fields that are not always part of a selection are added to the end of index fields, since subsequent fields can no longer be used for a search.
Example:
SELECT * FROM SFLIGHT WHERE MANDT=’100′ AND SEATSOCC >0;
If an INDEX SFLIGHT~Z01 in the form (MANDT, SEATSOCC, SEATSMAX) now exists in the table SFLIGHT, you can use it.
However, if the sequence is (MANDT, SEATSMAX, SEATSOCC), for example, then the MaxDB cannot skip the information about SEATSMAX, so that only MANDT can be used here for the index access. This results here in a table (range) scan, since MANDT belongs to the primary key.
Furthermore, fields that enable a strict restriction of data volume should be primarily included in indexes.
The average size for this purpose can be the ratio of different values in a field (NUM DISTINCT) to the total number of table rows (NUM ROWS). You can find this data in the view .OPTIMIZERSTATISTICS, as well as in transaction DB50 -> Problem analysis ->Tables/View/Synonyms -> Optimizer statistics.11. How can I create an index?
In SAP WebAS, indexes are initially created in the ABAP/4 dictionary (SE80/SE11), activated and thereby created in the database (SE14).
An index can be created in the SQL studio for test purposes. For this purpose, you must call the point “New” -> “Index Definition” using the context menu for a table in the object tree of the “Catalog Manager”. You can then enter the index names in a dialog box, and select the columns to be indexed from the fields of the table.
The index is created in the database using F8 or by choosing “Execute” (the button with the [!] icon).
The SQL command for this is:
CREATE [UNIQUE] INDEX ON .
(
, , …)
If the values to be indexed must be unique, you must specify the option UNIQUE. If the option is omitted, the index then accepts duplicate entries also.
Indexes, which are created by SQL studio in the SAP environment, must then be created in the SAP data dictionary (SE11) also.12. What search strategies are there with indexes?
You will find a description of the strategies used by the MaxDB optimizer under ‘Strategy’ in the glossary of the MaxDB documentation (Note 767598).13. Can indexes fragment in the MaxDB?
No. The MaxDB does not have an index fragmentation problem like that of Oracle (Note 771929). Here, indexes are kept optimal permanently, and storage space is immediately allocated to the freespace again.14. Can I check individual indexes for consistency?
As of Version 7.8, individual indexes can be checked for consistency. For more information about the command CHECK INDEX, see the FAQ Note 940420 Database structure check (VERIFY).
15. Can an index become larger than the table to which it belongs?
Yes. This is possible, for example, if the index is created on a little used field (that is, a field filled with too little data), but the primary key requires too much memory.
The key information is stored in a reduced form at index level in the B* tree of the table, while the secondary index must store each complete primary key.16. Can I create an index on a view?
No. Views are views on tables, and the tables involved together with the views are known as base tables.
These views on base tables are implemented as SELECT statements on the base tables. Technically, views can be compared to saved SELECT statements.
Therefore, no indexes can be created on views, but they can be created on the base tables of views.17. Can the table or indexes become smaller after a data loading process with R3load?
This is possible. For example, if data is inserted in ascending order using R3load, less index or leaf pages must be used than for unsorted data loads. The pages of the index are then filled more.
You can check this as follows:
Select * from tablestatistics where tablename = ‘
‘
(Comment: Only carry out this SELECT for small tables, since the entire B* tree will be analyzed and locked as a result.)
You will find the following values:
‘Rows’ number of data records
‘Leaf pages’ number of data pages used for them
‘Space used in leaf pages (%)’ average load
‘Space used in leaf pages (%) min’ minimum load
‘Space used in leaf pages (%) max’ maximum load18. What are BAD indexes, how do they come about, and how can I eliminate them?
If structural inconsistencies are detected when you access an index, the access to this index will then be locked. The index tree will be set to BAD. The index is no longer maintained by the database system and can no longer be used for the access. This may cause performance problems.
If an index is set to BAD, then a corresponding entry occurs in the files knldiag or knlmsg and knldiag.err or knlmsgarchive. Transactions DB50 and RZ20 report BAD indexes in the SAP system.
In MaxDB Version 7.5, the system table INFO_BAD_INDEXES includes an entry for each BAD index. If a table has no entries, then it has no BAD indexes.
As of MaxDB Version 7.6, the column FILESTATE is also maintained in the system table INDEXES.
Indexes that are set to BAD should be created again when you have minimal work loads to avoid performance problems. This can be done using “DBMGUI -> Recovery -> Index” or “DBStudio -> Administration”.
See also Note: 26837 – MaxDB: Data corruption.19. What happens if a UNIQUE index is set to BAD?
If a UNIQUE index is set to BAD, the corresponding table is set to READ ONLY. This lock is necessary since the UNIQUE option of the index can no longer be ensured for each additional write operation that concerns this index in the table. At the latest when the database is restarted, UNIQUE indexes that are set to BAD are automatically recreated.
As of Version 7.8, the DBMServer command auto_recreate_bad_index is available. You can use this command to activate the automatic recreation of UNIQUE indexes. For more information, see the MaxDB documentation in Note 767598.20. What is the parallel index build?
The data for the index is read in parallel by several server tasks to create the index build as quickly as possible. Only one parallel index build can be carried out at a time – if several CREATE INDEX statements are executed at the same time, these other indexes are then processed by only one server task. This is noticeably slower than a parallel index build. Therefore, you should always ensure that indexes are only created successively.21. Which phases occur during the index creation?
A user task starts the create index. This task activates server tasks that read the data in the tables and create several index lists.
Once these lists are created, the server tasks transfer processing back to the user task. The user task begins to merge the index lists. This is CPU-intensive and may take some time depending on the size and number of lists.
A savepoint completes the creation of an index.
The following entries exist in the knldiag, for example, for MaxDB 7.6:
Create index parallel – final index statistics
+ Perm leaf pages 348 – record count 11411
Create index parallel – start final merge step
Create index parallel – temp pages 42 – temp files 2
Create index parallel – stop final merge step [count 1]
Savepoint (CreateIndex) started by T77
SVP(1) Start Write Data
SVP(1) Stop Data IO, Pages: 2304 IO: 643 643
SVP(2) Wait for last task: 453 453
SVP(2) Stop Wait for last task, Pages: 0 IO: 0
B20PREPARE_SVP: 16116
SVP(3) Start Write Data
SVP(3) Stop Data IO, Pages: 11 IO: 10
SVP(3) Start Write Converter
SVP(3) Stop Converter IO, Pages: 1582 IO: 1582
B20SVP_COMPLETED: 16116
22. Why may it take a long time until a task is available again after you cancel the user task to cancel the creation of an index?
If you cancel a create index command, the cancel indicator is set for the user task. However, before the tasks can be re-released, the task must clear all index lists that were created before by the server tasks for index creation. This ensures that there are no unrequired objects left in the system. This may take some time depending on the number and size of the lists.

23. Can I create several indexes simultaneously?
You can create several indexes simultaneously. However, since only one index build can be carried out by several server tasks, we recommend (to speed up the creation of indexes) that you ensure that indexes on large tables are only started if no other CREATE INDEX is active, when you are creating several indexes simultaneously. You can create indexes on small tables, even if a CREATE INDEX is active.24. Will locks be set with “Create Index”?
Yes. Up to and including MaxDB Version 7.6, a lock is set on the relevant tables during the index creation.
As of MaxDB Version 7.7, the system only sets a lock for the entire duration of the index creation if the following conditions apply:
- if it is a UNIQUE index
- if the transaction that executes the create index has already set other locks.25. How can I speed up the index build?
You can speed up the index build on large tables by ensuring that only one CREATE INDEX is active, and therefore several server tasks are carrying out the index build.
The data cache should be configured sufficiently large, so that preferably all data for the index build can be loaded in the cache.
26. Must I carry out an update statistics for indexes?
No. You are not required to explicitly create the statistics for the indexes by carrying out an update statistics.
For more information about update statistics, refer to Note 927882.27. Where can I find more information on indexes?
For more information on the B* tree and indexes, see the MaxDB documentation (see Note 767598):
You can access this information using the following keywords in the glossary:
B* tree, Index, Indexed Column, Inversion list and Primary key.
Alternatively, you can use the SDN to access the MaxDB documentation.
https://www.sdn.sap.com/irj/sdn/maxdb

Exploding structured articles

admin — Sat, 28 Nov 2009 03:35:34 +0000

Symptom

Data records are deleted from the data package in the start routines of InfoSources 2LIS_02_SCL, 2LIS_03_BX and 2LIS_03_BF.
Other terms

2lIS_02_SCL;2LIS_03_BF;2LIS_03_BX
Reason and Prerequisites

The start routines were implemented to explode structured articles in mySAP ERP 2005.
Solution

The start routines prevent the extracted transaction data in SAP BW from being updated several times, which would lead to incorrect values.
The explosion of structured articles in mySAP ERP 2005 is possible for InfoSources 2LIS_02_SCL, 2LIS_03_BF and 2LIS_03_BX. For this, the WRF_BWEXT_STRUKTART implementation of the RS05_SAPI_BADI Business Add-In must be activated. This implementation explodes a document record into the individual components of a structured article.
To ensure that the data is correct in the connected data targets also after the Business Add-In has been activated, the InfoSources specified above contain a start routine that separates the “exploded” and the “unexploded” data records. This separation occurs in the RSBCT_RFASH_MATERIAL_EXPLO function module that is called. The E_T_DATA_NOR parameter contains the unexploded structured article records and the E_T_DATA_EXP parameter contains the exploded structured article records. You can use the SPLIT parameter to control if the system returns the exploded records at all. If you set this parameter, the system also returns the exploded records while they are deleted in the standard call.
The following scenarios are possible:
Case 1: You want to analyze only the unexploded structured article records in SAP BW.
Solution: You can use the delivered Content without any further adjustments because the function module mentioned above ensures that the records are separated.
Case 2: You want to analyze both the unexploded structured article records and the exploded structured article records in SAP BW.
Solution: In this case, you should create separate data targets for the unexploded and the exploded structured article records. You can then implement the same source code in the start routine of the update of the relevant data target as is delivered in the start routine of the transfer rule in the Business Content. The E_T_DATA_EXP parameter is updated in the data target update of the exploded structured article records and the E_T_DATA_NOR parameter is updated in the data target update of the unexploded structured article records.
As the last step, you can then delete the start routine from the transfer rules.
Important: If you delete the start routine from the transfer rules, the data must be separated in all connected data targets because otherwise incorrect data may be created.

Changes to extraction structures in Customizing Cockpit

admin — Sat, 28 Nov 2009 03:35:03 +0000

Symptom

If you change an extraction structure in the Customizing Cockpit (transaction LBWE) by importing a support package or a transport or by carrying out an upgrade, if this had already been activated for update for a certain time, various errors may occur:
The initialization of data that was created before the change no longer works (CONNE_IMPORT_WRONG_COMP_LENG).Delta requests terminate (CONNE_IMPORT_WRONG_COMP_LENG).The V3 update is no longer processed.The update from the extraction queue (update mode “Delta Queued”, as of PI(-A) 2002.1) is no longer processed.The log terminates (CONNE_IMPORT_WRONG_COMP_TYPE).

The same symptoms may be caused by a change to one of the LIS communication structures assigned to the application (such as MCMSEG or MCBEST for application 03) or, in individual cases, to other application tables also, or to one of the other extraction structures or DataSources belonging to the application (for application 11, for example).
The activation of a DataSource that was previously not used, for example, may also cause problems in an extraction structure that belongs to another DataSource (which belongs to the same application).
Furthermore, in individual cases, a change to an extraction structure may also have a negative effect on the update of another extraction structure (that belongs to the same application).

Other terms

LBWE, CONNE_IMPORT_WRONG_COMP_LENG, CONNE_IMPORT_WRONG_COMP_TYPE
IMPORT_ALIGNMENT_MISMATCH, CONNE_IMPORT*, IMPORT, V3, SM13, update
MCEX_UPDATE_02, MCEX_UPDATE_03, MCEX_UPDATE_04, MCEX_UPDATE_05
MCEX_UPDATE_05_1, MCEX_UPDATE_08, MCEX_UPDATE_11, MCEX_UPDATE_12
MCEX_UPDATE_13, MCEX_UPDATE_17, MCEX_UPDATE_17_1, MCEX_UPDATE_18
MCEX_UPDATE_18_1, MCEX_UPDATE_40, MCEX_UPDATE_43, MCEX_UPDATE_44
MCEX_UPDATE_45, MCEX_UPDATE_45_1, MCEX_BW_LO_API

Reason and Prerequisites

When you change a structure, the data that is stored in the old form of the structure may no longer be interpreted correctly.
Since changes to extraction structures (or other update-relevant structures) and to basic data definitions can also be made during an R/3 upgrade or a plug-in upgrade and (in very rare cases) when you import an R/3 standard or plug-in Support Package, the precautions described below should also be taken beforehand.

Solution

You must carry out the following steps before a change to a structure:
1. Make sure that you carry out the following steps at a time when no updates are performed, so that no data is lost.2. Start the update collective run directly from the Customizing Cockpit. Up to PI(-A) 2001.2 , this collective run concerns only the V3 update. As of PI(-A) 2002.1, depending on the configuration of the update mode of the application, the collective run concerns either the V3 update or the update from the extraction queue (”Delta Queued”, see Note 505700).3. Load all the data of the relevant DataSource into the BW System.

You can then make the change.
After making a change, you may no longer be able to use statistical data that was already set up. If such data still exists, you must delete it (transaction LBWG).
We recommend in particular that you upload the data immediately after a setup and (after checking in BW) delete it from the setup tables.
Furthermore, the update log (transaction LBWF) can no longer be read. In this case, you must post a document, so that the last log entry is overwritten. This log entry then has the correct new format of the extraction structure.
As of PI 2000.2, the program RMCEXDELETELOG is provided, which you can use to delete log entries.
Note the following:
The program RMCEXDELETELOG is available in the current PI 2000.1 patch. However, no success message is displayed.
You can also import the program from the SAPSERV hosts. It can be found in the directory /general/R3server/abap/note.0328181. However, only German texts have been maintained.
If you forget to execute the update collective run before a change, the only option you have is to delete the records that still exist. This means that this data is lost.
To do this,
in the case of V3 update methods, navigate to the update overview (transaction SM13), select the records (user *, V2 executed, restrict date), and select Update records -> Delete -> All records. Do not forget to deactivate the flag “Only incorrect”.in the case of the update method “Delta Queued” (as of PI(-A) 2002.1), navigate to the logistics queue overview (transaction LBWQ). Select the queues for the relevant applications one after the other (MCEXnn, nn = number of the logistics application, see transaction LBWE), and choose the display function. Choose the display function again to list all the entries in the queue. Then select and delete all of the entries that had been saved before the structure change. In case of a very large number of entries in a queue, it may be necessary to delete the entire contents of the queue. This can be done on the initial screen of transaction LBWQ.

Aggregation of scheduling lines and statistics

admin — Sat, 28 Nov 2009 03:34:31 +0000

Symptom

You use ME85 to aggregate and renumber schedule lines for a scheduling agreement. When you look at the data in business warehouse, the changes to these schedule lines has not registered.
There is no delta update of BW from ME85.
Other terms

OLI3BW, setup, scheduling lines, delta update
Reason and Prerequisites

This is the normal behaviour of the system.
It is not possible to do a delta update of statistics in purchasing when schedule lines have been aggregated and renumbered. This is because the datasource 2LIS_02_SCL relies on unchanged schedule line numbers to recognize changes.
A delta extraction is based on being able to tell statistics that an object is changed. All statistics is based on objects and these objects are identified by key values. For the purchasing datastructure 2LIS_02_SCL these key values are the purchase order number (EBELN), the item number (EBELP), and the schedule line number (ETENR).
When you make a change to a schedule line, by updating its quantity, or through a goods receipt or an invoice, the object in statistics that is changed is identified by these key values.
Without these consistant and unchanging values it would not be possible to identify what object in BW was being updated. Renumbering changes a key value and so statistics must be recreated to bring the purchasing datasources into sync again.

Solution

You must run OLI3BW (RMCENEUA) for the changed document after using ME85 to aggregate and renumber schedule lines.

Consulting: Loading of Datastore object using routines

admin — Sat, 28 Nov 2009 03:34:00 +0000

Symptom

You load a Datastore object (DSO) using either of the following scenario:
You use 3.x mode of loading using Infopackage andTransfer rulesandUpdate ruleswithStart RoutineYou use the 7.x mode of loading using Data Transfer Process (DTP),TransformationusingStart Routine,End RoutineorExpert Routine

You may end up in incorrect results for the characteristics which have not been used as key fields and the technical aggregation type is ‘MOV’ ( description: ‘overwirte / move’) for that characteristics.
Key figures which are updated by aggregation type ‘overwirte / move’ could also have the wrong aggregated values after processing a datapackage.
Other terms

Transfer rules, Update rules, Start routine
Transformation, Start routine, End Routine, Expert Routine
Chronological sequence of records;
Incorrect data; unexpected data
Reason and Prerequisites

REASON: This works as designed for Data aggreated by ‘MOV’ option. Records with the same key are always aggregated by principle ‘the last records wins’.
Solution

By activating data of a Datastore, datapackages are always process in the correct chronological sequence. Therefore it doesn’t matter whether the datapackages are loaded in ’serial’ or ‘parallel’. By using the following kind of routine, which are more easyly named aspackage routines:
Start routine in the Transfer Rules
( record sequence given by column = ‘RECORD’ )Start routine in Update Rules
( record sequence given by column = ‘RECNO’ )Start, Endroutine or Expert Routine in Transformation
( record sequence given by column = ‘RECORD’ )

It mustbe ensuredthat thechronological sequenceof the records inside a single datapackageisn’t changedafter processing a package routine.
The chronological sequence inside a datapackage is determined by the values of column ‘RECORD’ or ‘RECNO’ of the inbound data package.
If you need due to technical reasons inside a package routine adifferent orderyou must bring the outbound data at the end of the processing into thecorrect choronological sequenceagain.
You could da that by a abap statement like “SORT BY ‘RECORD’ or ‘RECNO’ ASCENDING” or you could ensure by your own logic the correct sequence of rows of the outbound datapackage.
Limitation: If you add new records you have to ensure the right sequence by your own logic. For details on adding records in package routines refer to consulting notes:
Transformations: 1258089, 1227667, 1223532Transfer rules: 710673Update rules: The behavior described in note 710673 is also valid.

Num. var. with replacement from attrib. or hierarchy attrib.

admin — Sat, 28 Nov 2009 03:33:30 +0000

Symptom

A query that has a numeric variable with a replacement path attribute takes a long time to run. Large volumes of data are processed both in the data manager and in the online analytical processing (OLAP) processor.

Other terms

Query, FAGGR, replacement path

Reason and Prerequisites

The OLAP processor must read the data so that the reference characteristic of the relevant attribute is drilled down (see also Notes 1228378 and 1385580; you can display these required drilldowns by choosing RSRT -> Technical Information -> Not Visible Drilldown Characteristics).

Solution

Logic was implemented in Release 3.X so that this background drilldown is only carried out if the variable is used in a basis formula (FST_K, see Note 379832). Since this implicit switch is very difficult to control and to understand, it is no longer supported as of Release 7.0, and an automatic drilldown is always carried out.
As of Release 7.0, however, the system contains a replacement path hierarchy attribute, and such a numeric variable is always replaced after the aggregation (see Notes 1385580 and 1384942).
Therefore, you can decide between the following:
1. The numeric variable is always replaced if you select the option of replacement path from attribute (FLAGR=’4′). However, this may negatively affect performance, memory space, and runtime. This corresponds to the 3.x case if the attribute variable is used in a basis formula (FST_K).2. The numeric variable is only to be replaced if the reference characteristic is drilled down or explicitly filtered. The replacement then has almost no negative effects, but in all other cases, it delivers a NOT_EXIST. This corresponds approximately to the 3.x case if the attribute variable is used in a formula element (FST_F). You achieve this if you select the option to replace with hierarchy attribute (FLAGR=’6′) in the replacement path.

BI_CONT 724 FA: syntax errors in UPARI_ … Objects

admin — Sat, 28 Nov 2009 03:32:58 +0000

Symptom

Compatible source code adjustments to support future releases.
Other terms

CL_RSD_DTA, factory, UPARI_BUDGA, Budgetmonitor, UPARI_REL, Release-Workbench
Reason and Prerequisites

To be compatible with future releases the instantiation of objects of class CL_RSD_DTA is done by a static public method FACTORY and not by the statement CREATE OBJECT anymore.
Solution

Apply the attached correction instructions.

Oracle Metalink access for SAP customers

admin — Sat, 28 Nov 2009 03:32:28 +0000

Symptom

Access to http://metalink.oracle.com
Other terms

Oracle Metalink
Oracle Metalink Notes
TAR
ITAR
metalink
metalink note
Reason and Prerequisites

Use Metalink as additional means for error analysis or to retrieve background information on a particular problem.
Solution

Oracle Metalink now is also accessible for SAP customers that do not have an additional oracle License with oracle. The type of access that is available to customers allows you to query the oracle formums and retrieve oracle notes about a particular problem.
It is an information-only account that does not provide you with any change functionality neither allows you to open TARS nor ITARS.
Last Password change: 10/20/2008
username: orasupport@sap.com
password: sapt1ger

NOTE: We will be changing this password on a regular basis. So please, should this username/password combination not work; check back with this note to find the most current combination. We will also inform all users that are on our ‘metalink distribution list’ when the password was updated. If you are not on our list yet, please send an email to orasupport@sap.com and we will add you to the list.
You will not get any emails other than metalink account related information or any serious oracle bugs through this email list.
Please note that you are sharing that user with all the other sap/oracle customers; so please do not make any changes to the user preferences/settings of this user.
PLEASE ALSO DO NOT HIT THE ‘forget your password?’ link. This will change the password for that username and a new password will be generated. This will prevent any user (including you!) from being able to logon until we reset the password to its default.
Currently it happens almost on a weekly basis that someone that way denies access to all other users.
If you do get a message ‘invalid Login Credentials’ please try at least twice with the same password, sometimes it has to redirect you to a different server until it works. If it doesn’t work, try again a few hours or days later – it may just have been a maintenance issue on oracle side that could be over a few minutes later. If however you hit the ‘forget your password’ button; logon will only be available again once someone notified us about a problem and we know to reset the password again. (which could be several days later).
Since in the past it happened a couple of times, that a customer has changed the user information and with this prevented everybody else from being able to logon again until we detected the issue and changed the password back, we have created two backup users now that can be tried in these situations
username: orasupport2@sap.com and
username: orasupport3@sap.com
The password for all three of these users is set the same. So use the password mentioned above also for these two users.
If you detect any user to not work with the password provided; please send an email to the email-address in question and we will changed it back.
Please understand that this user only allows you to have read-only access to metalink. You will not be able to create service requests or download patches with this. Should you need one-off fixes/patchsets,
please go to the sap service marketplace
http://service.sap.com/swcenter-3pmain and download them from there.
The patches you find there are tested to run in the SAP environment and it was excluded that they cause conflicts with any other of the one-off fixes we recommend.

Error message RD 159/RD 117 during extraction from CO-PA

admin — Sat, 28 Nov 2009 03:32:00 +0000

Symptom

When you extract transaction data from the profitability analysis, the system displays error message RD 159 “Incorrect field name for selection”, or RD 117 “Syntax error in generated program”.
Other terms

RD159, RD 159
Reason and Prerequisites

When you change the structure of the operating concern (by deleting fields, for example), the system does not adjust the extract structure for the DataSource. This means that the field catalog of the operating concern and the DataSource are inconsistent during the extraction, and this causes the system to display the error message.
Solution

You cannot change DataSources in PI1999 or PI2000. At the moment, the only solution is to create a new DataSource for the affected operating concern.
The attached corrections display the field names in the message variables to help you identify the error.
In addition to implementing the corrections, adjust the short text of the following error messages in transaction SE91:
RD 117:
Old text: Syntax error in generated program
New text: Syntax error in the generated program: &1 is inconsistent
RD 159:
Old text: Incorrect field name for selection
New text: Incorrect field name &1 in selection table

Repairs in the Code

Caution: Do NOT enter any more source code here. You must only maintain source code using the screen
“Corrections” -> “Correction Instructions”.
Lines entered here are DELETED automatically when you save.

BWA 7.00 & 7.20: Filling fails due to wrong date format

admin — Sat, 28 Nov 2009 03:31:27 +0000

Symptom

The filling of a BWA index fails with error code “1994″
Other terms

BIA, BWA, Explorer, Polestar, filling, indexing, date, invalid data
Reason and Prerequisites

Filling of BWA index fails due to a not valid data format in an attribute of type DATE. You can find the following trace entries in traces of TREXIndexServer:
DateAttributeValue::set(): attribute value is not a date or wrong syntax(6931), value “0919-98-30″
Additional info for previous 6931: index “sid_bi0:sdateen”, attribute “date0″, docid 474, value “0919-98-30″
sid_bi0:sdateen: prepareOptimizeAEandTM failed with rc=1994
prepareOptimize finished for index sid_bi0:sdateen with return code 1994
prepare failed for sid_bi0:sdateenwith rc=1994

In that example the invalid data is in database table SDATE in column DATE0. The format of the data of type date itself maybe invalid or a not defined character is booked in the database table.
Solution

Clean up the data of the info object in your BW.

BW Change Run

admin — Sat, 28 Nov 2009 03:30:55 +0000

Symptom

This note provides detailed information about what has changed regarding the Hierarchy/Attribute Change Run (CR) with BW7x. In combination with note 903886 (which is only valid for BW releases BW3x) it should give you a good overview of this important BW process from a technical point of view.

Other terms

attribute and hierarchy change run, ChangeRun, FAQ, Hierearchy/Attribute Changes for Reporting

Solution

What has changed:
(A)Multiple parallel Change Runs are possible
(B)Parallel processing of affected aggregates
(C)Determination of the change mode
(D)Compression of aggregates
(E)Locking concept
(F)Restart of Change Runs
(G)Change Run Monitor
(H)Aggegates are switched off for queries

(A)Multiple parallel Change Runs are possible

In contrast to BW3x systems it is possible to run multiple CRs in parallel with BW7x. This is only allowed if the CRs do not interfere with each other, meaning that the lists of master data and hierarchies to be activated are different, and that the changes affect different InfoCubes. Note 534630 (’Parallel processing of Change Run
‘) isn’t relevant any longer!

(B)Parallel processing of affected aggregates

The system collects all affected aggregates and then sorts them according to the estimated runtime. For each aggregate a seperate job is started, the name is made up of BICHNG_ and a long technical ID. Before the job gets executed it is checked whether the maximum number of parallel processes is already reached. In addition it’s verfied whether the ‘parant aggregate’ isn’t adapted right now and can be used as a ’source’.
The number of parallel processes can be customized with transaction RSBATCH. In case of process chains, it can be customized per chain. If nothing is maintained the default number 3 is taken.

(C)Determination of the change mode

As discussed in note 903886, there are three different modes how aggreagtes can be adapted. In the so called delta mode D, the aggregates are adjusted using a delta request that contains the changes. The way how the system estimates the percentange share of data in the aggregate which will change, has been improved with BW7x. In BW3x releases only the master data was taken into accout. With BW7x it is determined how often the changed values are booked in the cube.
Let’s discuss the details with the help of a simple example:
You have changed master data to 3 navigation attributes (B,C,G) of the two infoobjects A and D:
A__B was changed for 10 records
A__C was changed for 20 records
We assume that in total 25 data records were changed (in the P-table) of the infoobject A (meaning that there are 5 data records where both attributes were changed).
D__G was changed for 30 records
Aggregate AGGR1 uses the following navigation attributes (with * in the definition):
A__B
D__G
In general, two dimensions are affected in the corresponding cube: DIMA and DIMD. Lets assume that in both dimensions we have a total of 1000 records. Then its checked how often the changed values are booked in the dimensions. If we assume that the 25 values of the infoobject A are booked 50 times and the 30 values of infoobject B are booked 100 times, the following calculation is carried out:
%T = (50 / 1000)*100 + (100 / 1000)*100 = 15%
If %T is larger than the ‘DELTALIMIT’ the aggregate will be reconstructed. Please note that regarding A the total of 25 (and not 10) was taken.
Changes to Hierarchies are treated the same way and added to %T.

(D)Compression of aggregates

In contrast to BW3x, the aggreagtes are now compressed automatically at the end of the Change Run (up to the required request, e.g. see the field COMPR_AGGR of table RSMDATASTATE for the affected cube). For each aggregate a seperate job is started, the name is made up of BICOND_ and a long technical ID. As for the adjustment of aggregates, all this jobs are executed in parallel.
Please note that its still possible to avoid the compression by setting an RSADMIN paramter, for more details see note 1117724.

(E)Locking concept

Note 825927 describes in detail the two locks CHNGRUN_ST and CHANGERUN set during the change run. The main concept has remained the same with BW7x, but please take into account the following points:
- as already mentioned above, it’s possible to execute more CRs in parallel with BW7x (so more than one can be in the phase ‘WORK’).
- if a change run does not get the lock CHANGERUN it releases the lock CHNGRUN_ST as well. Then the system waits 30 seconds and tries it again. This is done as long as the time defined with the parameter CR_MAXWAIT has not been exceeded.

(F)Restart of Change Runs

If you want to restart a canceled Change Run CR1 you can do this e.g. in the Change Run Monitor. It might happen that another Change Run CR2 is executed in the meantime which contains one of the characteristics (or hierarchies) of the terminated one. In such a case CR1 (instead of CR2) is executed and you get a warning (RSDD117) in the log that not all characteristics and hierarchies were processed of CR2.
Please see notes 1326211 and 1085914 for further details to this topic.

(G)Change Run Monitor

The Change Run Monitor (transaction changerunmoni or program
RSDDS_CHANGERUN_MONITOR) has been improved as well with BW7x. In addition to many details to the current situation on the system you can now also get information displayed to already finished CRs (button ‘Details of earlier Change Run’).
If there is a canceled CR you can restart it by clicking on the button ‘Restart Change Run’. In case this canceled change run hasn’t yet adjusted any aggregate, the button ‘Reset Status’ appears. By using this feature you can restore the original status and immediately release the locks on processes like ‘loading master data’ and ‘roll up’.
As in BW3x systems, this monitr provides the information about which which aggregates have already been adapted and which are still waiting (regarding a certain running or terminated CR). In case of a terminated CR it might be reasonable to deactivate all the remaining aggregates and then start the CR again – for more details please see note 903886.
Another important point hasn’t changed either: please never ‘close’ a CR manually since this may lead to an inconsistent state (see note 1053605).

(H)Aggegates are switched off for queries

During the time when the aggregates are adjusted they are not used by any queries. In transaction RSDDV you then can see that these aggreagtes are switched off (grey light). For more details please see note 994005.

Wrong Result When Using DBMS_REDEFINITION in RAC environment

admin — Sat, 28 Nov 2009 03:30:26 +0000

Symptom

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
This note is released as a Hot News.
You must check the note regularly for updates. Otherwise, you will not be aware of important changes regarding prerequisites, consequences and solutions in the latest release. If this note is updated, no new Hot News is issued.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
When table redefinitions are done via DBMS_REDEFINITION package on one node and queries / activity is ongoing on the remote nodes, then the redefined queries will show different results on all nodes.
This issues occurs only in a RAC environment in Oracle 10.2.0.2 or 10.2.0.4 with more then 1 node.

Other terms

Wrong values, DBMS_REDEFINITION, Online reoganization, RAC
Reason and Prerequisites

When the table redefinition occur on e.g. node1, then the cursors of node2 are not totally invalidated. Hence they still use the old objects.
This is caused by the Oracle bug 7573151, which is fixed in Oracle Release 10.2.0.5.

Solution

Install the relevant patch for your platform.
You can find this on SAP Service Marketplace in the software center under: http://service.sap.com/swcenter-3pmain in the following directories:
Oracle 10.2.0.4
AIX5L (64-bit)
/Oracle/Oracle 10.2.0.4/Database RDBMS/AIX5L (64-bit)/
p7573151_10204_AIX5L.zip
HP-UX PA-RISC (64-bit)
/Oracle/Oracle 10.2.0.4/Database RDBMS/HP-UX PA-RISC (64-bit)/
p7573151_10204_HPUX-64.zip
HP-UX Itanium (64-bit)
/Oracle/Oracle 10.2.0.4/Database RDBMS/HP-UX Itanium (64-bit)/
p7573151_10204_HPUX-IA64.zip
HP Tru64 (64-bit)
/Oracle/Oracle 10.2.0.4/Database RDBMS/HP Tru64 (64-bit)/
p7573151_10204_Tru64.zip
Linux x86 (32-bit)
/Oracle/Oracle 10.2.0.4/Database RDBMS/Linux x86 (32-bit)/
p7573151_10204_Linux-x86.zip
Linux Itanium (64-bit)
/Oracle/Oracle 10.2.0.4/Database RDBMS/Linux Itanium (64-bit)7
p7573151_10204_Linux-IA64.zip
Linux x86-64 (64-bit)
/Oracle/Oracle 10.2.0.4/Database RDBMS/Linux x86-64 (64-bit)/
p7573151_10204_Linux-x86-64.zip
Linux on Power (64-bit)
/Oracle/Oracle 10.2.0.4/Database RDBMS/Linux on Power (64-bit)/
p7573151_10204_IBMPower.zip
Solaris SPARC (64-bit)
/Oracle/Oracle 10.2.0.4/Database RDBMS/Solaris SPARC (64-bit)/
p7573151_10204_Solaris-64.zip
Solaris x86-64 (64-bit)
/Oracle/Oracle 10.2.0.4/Database RDBMS/Solaris x86-64 (64-bit)/
p7573151_10204_Solaris86-64.zip
MS Windows (32-bit)
MS Windows Itanium (64-bit)
MS Windows x86-64 (64-bit)
Patch 7573151 is contained in Windows patch collection 14 for Oracle 10.2.0.4 and above.
For information about availability, see Note 1137346.

Please note:The patches for bug 7573151 are released on the SAP Service Marketplace since 12-January-2009!

Oracle 10.2.0.2
AIX 5L 64-Bit
/Oracle/Oracle 64-Bit/Oracle 10.2.0. 64-Bit/Oracle 10.2.0.2/
AIX_5L_64/p7573151_10202_AIX64-5L.zip
Linux x86-64
/Oracle/Oracle 64-Bit/Oracle 10.2.0. 64-Bit/Oracle 10.2.0.2/
Linux_x86_64/p7573151_10202_Linux-x86-64.zip
HP-UX PA-RISC 64-Bit
/Oracle/Oracle 64-Bit/Oracle 10.2.0. 64-Bit/Oracle 10.2.0.2/
HP-UX_64/p7573151_10202_HP64.zip
HP UX Itanium 64-Bit
/Oracle/Oracle 64-Bit/Oracle 10.2.0. 64-Bit/Oracle 10.2.0.2/
HP_IA_64/p7573151_10202_HPUX-IA64.zip
SUN Solaris 64-Bit
/Oracle/Oracle 64-Bit/Oracle 10.2.0. 64-Bit/Oracle 10.2.0.2/
Solaris_SPARC_64/p7573151_10202_SOLARIS64.zip

Collective note: Performance of BI planning

admin — Sat, 28 Nov 2009 03:29:57 +0000

Symptom

This note gives you an overview of the most important factors which influence performance that you must take into account when you create planning applications in BI planning. The note discusses the following topics:
1.Background knowledge for BI planning architecture2.Important influencing factors for performance3.Recommendations for modeling4.Availability of optimizations

Other terms

BI planning, planning modeler, input-ready query, planning function, planning sequence, planning buffer, delta buffer, characteristic relationships, data slices, performance, memory consumption
Reason and Prerequisites

Customizing and design of BI planning
Solution

1. Background knowledge for BI planning architecture

The most important BI planning components for this note are:
Planning buffer: You can use this buffer to process queries from BI planning to the data manager. These queries occur using a technical query that is automatically generated by the system. As a result, the OLAP cache for this technical query can be reused to buffer queries.Delta buffer: The delta buffer contains all the delta records that occur during a planning session up until a “Save” operation. The delta records are generated from input-ready queries after each round trip (manual entry) and from planning functions.Input-ready queries: These are normal queries that are defined for InfoProviders that are supported in BI planning. In addition, at least one structural component is ready for input for these queries and the query is started in change mode.Planning functions: A planning function is a planning function type at the time of execution, that is, with all replaced parameters and variables. A planning function selects the data to be changed and, if necessary, reference data, using the planning buffer. It executes the algorithm (for example, copy), determines all delta records and writes them to the delta buffer.Characteristic relationships: These are rules that you can define for real-time InfoCubes so that you can maintain allowed characteristic combinations for BI planning. These rules also enable you to derive characteristic values or generate a quantity of valid characteristic combinations from a selection.Data slices: These are selection tables or rules (exit) that enable you to prevent data records from being changed by manual planning or planning functions.Planning application:This is an application created by the BEx Analyzer in MS Excel or a Web application created with the WAD (Web Application Designer).

Each data changing component (input-ready queries and planning functions) of BI planning must take into account the constraints of BI planning (characteristic relationships and data slices) and additional technical constraints (validity of master data and consistency of master data ID (SID) values) so that a consistent database status is transferred to a new consistent database status after you change and save data. There is also a locking concept for the data to be changed. Here, the quantity of data specified in a selection table is locked (regardless of whether it exists in the real-time InfoCube or not).
If you compare the runtime of reporting and input-ready queries, there may be considerable differences in the runtime due to the effort required to ensure the planning model is consistent. The more time consuming the planning model is, the higher the ‘price’ for the runtime. Note also that although redundant data generally has a positive effect on performance, in the planning area it can be counterproductive because even redundant information must be checked for consistency (for example, SIDs, navigation attributes and redundant times). You can find more detailed information about this later on in this note.
We now want to describe which activities the system carries out at runtime for planning functions and input-ready queries. We will only describe the work steps roughly here: For extreme data models (very large MultiProviders, a large number of variables, a very complex authorization concept), other steps may also be relevant for the performance of the whole application.

1.1 Planning functions at runtime.

Here, we assume that the planning functions are not executed in the context of a planning application (that is, in connection with an input-ready query). During the execution of a planning function, the system behaves as follows:
1. First it replaces variables in the parameters of the function. It also replaces the variables in the filter that describes the selection of the planning function. If you use a planning sequence, the system carries out this replacement for parameters and filters.2. Then, the system determines which data must be read in change mode (planning data) and, if necessary, which data must not be read in change mode (reference data). This data is read by the planning buffer. The planning buffer takes into account any delta records that may have been created in the session.3. The algorithm that forms the planning function is now executed. In this case, the system changes, creates or deletes data records. At this time, the system also checks the conditions.4. The system now checks whether the data records are consistent: Data records that have just been created must be contained in the planning function filter. In addition, all characteristic values must be valid (check against master data table, if it exists) and they must conform to the characteristic relationships. Changed or new data records are not allowed to be protected by data slices.5. if the data is consistent, the system determines the delta records and writes them to the delta buffer. In the delta buffer, the system determines which fields can be derived from the filled fields and the relationships of type derivation. Then the system fills these fields as necessary.

If you execute the planning functions several times or if the planning data or reference data required by a function already exists in the planning buffer, the system does not access the database (or SAP NetWeaver BI Accelerator (BIA), if it exists).
The system always carries out the three steps ‘read’, ‘process data’ and ‘write changes to the delta buffer’ for each planning function in a planning sequence. See section 3.4.3.

1.2 Input-ready queries at runtime.

Here, we assume that only queries and at least one input-ready query exist in the planning application. At the start of the application, the system executes the following actions:

1. The system replaces the variables of the query.2. Then it opens an online analytical processing (OLAP) instance (if necessary, additional instances for other queries) that now determines the required planning data and reference data. The system determines the reference data from the settings of the structural components of the query and, if necessary, from the restrictions on InfoProviders that are not relevant for planning. The data manager reads the data and then forwards the queries to the planning buffer.3. Now the system fills the data in the internal structures of the OLAP processor and filters it if necessary (for example, if there are queries with two structures). In addition, the system carries out the first checks against the planning model (data slices and characteristic relationships), however, only when all required characteristics have been defined uniquely from aggregation levels.4. Then there are queries from the front end to collect the data from the OLAP processor and transfer it into an abstract grid format. The concept of rows and columns is not defined until this point. As a result of the rows/columns structure, there are empty cells. The system must check if it is possible for these cells to be ready for input.5. Depending on the BI front end, the following tasks are to be carried out:a) BEx Analyzer: The system converts the data from the abstract grid format and uses Remote Function Call (RFC) to transfer it to the .NET runtime of the BEx Analyzer. This triggers rendering in Excel.b) BEx Web Analyzer: The system normalizes the data from the abstract grid format using an RFC (JCo) and transfers it to BICS (BI Consumer Services). Then the system creates HTML and sends the results to the browser and renders them.

After you make an entry, the system carries out the following steps:

1. The system carries out some basic checks in components related to the front end, for example, the validity of the characteristic values entered. If these checks are successful, the system transfers the data to the OLAP processor.2. In the OLAP processor, the system checks changed data or entries from the new rows against the planning model. Characteristic values from new rows must be contained in the current query filter, there must be valid combinations according to the characteristic relationships and the relevant data records are not allowed to be protected by data slices. If necessary, the system carries out further checks. If the changed data is consistent, the system determines the delta records and writes them to the delta buffer. Derivations are carried out there, if necessary.3. Now the front end requests the current data from the OLAP processor. The OLAP instances for input-ready queriesandreporting queries in the planning application are automatically sensitive to changes in the delta buffer: These instances therefore obtain the required data from the planning buffer and the delta buffers (one for each real-time InfoCube) and update the internal status of the OLAP instances. Then the system again transfers the data to the abstract grid format and sends it to the front end.

1.3 Planning applications with input-ready queries and planning functions
For the executions in sections1.1and1.2, it is necessary to explain how planning functions and input-ready queries communicate data changes between each other.
Here, data changes generally lead to new data records in the delta buffer. Therefore, according to sections1.1and1.2, the planning functions andallqueries in the planning application see the data changes that have taken place in the planning session using functions or manual entries.

2. Important influencing factors for performance

If you want to optimize the runtime of the created planning application or if the runtime is not what you expect, it generally makes sense to carry out the following procedure.
Proceed iteratively, as you would in any good project, that is, plan sufficient small steps and investigate the performance of components of a planning application individually at an early stage. Then there is generally time for you to adjust the data model appropriately and make other Customizing adjustments. Then combine the components in the application and test the performance.
Use transactionRSRT, for example, to analyze the performance of individual queries: You can use transaction SE30 to measure the runtime of this transaction.
You can use reportRSPLS_PLSEQ_EXECUTEto execute the planning sequence and then measure it using transaction SE30.
You can use transactionRSTTto record typical actions that are executed in a planning application (see Note 899572). You can use transaction SE30 to measure the RSTT trace and search for hotspots in the application.
If you open a customer message about the performance of a planning application, the RSTT traces of an application should always be available.
In BI planning, there are many parameters that can influence the performance of the application. Take at least the following points into account during the application design. Collect information about the following points and also take into account the recommendations from section 3.

2.1 Data model

The data model includes master data, the InfoProvider and the infrastructure of BI planning for each real-time InfoCube, that is, that characteristic relationships and data slices. Also relevant for BI planning are technical characteristic relationships for time characteristics (for a complete list, see the documentation), navigation attributes and technical relationships that ensure the SID consistency for compound characteristics.

2.2 Number of data records read and to be processed

In planning, you require data that is only read (reference data) and data that is changed in planning (planning data). Determine the number of these data records for queries and planning functions. The number of empty cells in an input-ready query can be relevant if the check for the ready for input status is time-consuming. Furthermore, it is important to know how many data cells are sent to the front end.

2.3. Construction type of the input-ready query

For input-ready queries, collect information about restrictions in the filter and the type of the selection there (single value, hierarchy, variable and so on) and about the setting “Access Type for Result Values”. The value that replaces the variable at runtime is important.
Does the query have one structure or two structures? How many components does each structure have? What restrictions are used in the structures? If there are two structures: Are restrictions carried out for each cell? How many cells are there? Are calculations made in the query (formulas)?
Are characteristics drilled down using structures? Are the drilldown characteristics different from the characteristics used in the structures? How many hierarchies are used in the query? How large are the hierarchies?

2.4 Number of components in the planning application

Determine the number of queries, query views (using the data provider) and planning functions that are used in the planning application. How many variables are used and how are they replaced? Are all queries executed at the start of the application or are they started later on using commands when they are required?

3. Recommendations for modeling

This section contains recommendations for the influencing factors mentioned in the second section.

3.1 Data model

Compound characteristics may require consistency checks if there are input-ready queries and special list geometries (when you use the characteristics for different axes of the query). Use characteristic compounding sparingly.
We recommend that you store planning data and actual data in different InfoCubes and use aggregation levels on a MultiProvider for planning. MultiProviders only require slightly more effort than InfoCubes. However, note that in BI planning, the additional effort of MultiProviders in comparison with reporting increases further since each record in the MultiProvider must be able to be assigned to a relevant InfoProvider of the MultiProvider without information being lost. The system carries out this check for each data record that can be changed. The more inhomogeneous the relevant InfoProviders of the MultiProviders, the larger the effort. Therefore, resist trying to create a universal MultiProvider, that is, create as small a MultiProvider as possible.
Use characteristic relationships sparingly since the system has to check the validity of each data record that can be changed and each delta record carries out all applicable derivation steps. The characteristics of the aggregation level determine which steps are applicable. The more relationships you use, the more checks are required. Refer to the documentation to find out exactly when a combination check or a derivation is carried out (see also Note 955993). For optimal modeling of characteristic relationships, proceed as follows:
Choose the characteristics in the relationships as ‘orthogonal’ as possible, that is, the characteristic quantity of combination checks must be as disjunctive as possible. For derivations, target characteristics should occur in only one relationship if possible. This makes it easier to keep the rules in the characteristic relationships as consistent as possible.Derivation: Combine as many steps into one relationship as possible if you only require the derivation for delta records, that is, the relationship does not work as a combination check as well. If this is the case, you should not create one relationship for each target characteristic during the derivation of characteristics from attributes of a master record. Here, enter only all required target characteristics. Keep the data model as simple as possible. If you want a derivation (for example, in a query) to also work as a combination check, you must ensure that the relationship does not contain too many target characteristics because this may result in the combination check not being called.Combination check: As for derivations that work as combination checks, you must choose the number of characteristics for each relationship so that the combination check is also called in queries and the planning function. Under this constraint, choose the maximum number of characteristics in the relationships.

In addition to the characteristic relationships explicitly defined for the InfoCube, the system recognizes characteristic relationships for redundant time characteristics, for navigation attributes and for technical characteristic relationships, for example the consistency check of SIDs for compound characteristics. Therefore, use as few redundant time characteristics as possible in the real-time InfoCube, navigation attributes and compound characteristics. See also section 3.3.

3.2 Number of data records to be processed

Recommendation: Select only the data that is actually required. Start by considering the number of characteristics in aggregation levels. Use only the required characteristics there. If you want data to be distributed top down, you can execute this with planning functions in the background, for example.
For input-ready queries, you should restrict the number of data cells to those that are relevant for manual planning. In Web applications, you should use the settings for paging in the Web template so that you can define the number of cells to be rendered.
During the parameterization of planning functions, ensure that the relationship of read data to changed data is balanced. If approximately 1500 records are read and only 100 are changed, the relationship is no longer balanced. Therefore, restrict the filter accordingly. Whenever possible, include the selections from conditions in the filter. It does not make sense to select a large number of data records using one filter and then to only edit a few of them using conditions.

3.3 Construction type of the input-ready query

Make the restrictions in the filter and the restrictions of structures as severe as possible. For the variables, ensure that the filter is also as restrictive as possible after the values have been replaced. Use the variables in the query filter because only the selection in the filter and in structural components of the query are used to set the locks. The restrictions from the default values are not used.
Severe restrictions are required if you use the setting ‘Access Type for Result Values’ according to characteristic relationships or master data.
If the query is defined for a MultiProvider (this may occur indirectly using an aggregation level), you should restrict characteristic 0INFOPROV into structural components if possible. A typical example here is the planned/actual comparison if the planning data is from a real-time InfoCube and the actual data is from a standard InfoCube.
Use as few redundant characteristics in the query as possible. If characteristics are redundant and are used in the drill downs, they should not be on different axes. For compound characteristics, it generally makes sense to restrict the higher-level characteristics to an individual value in the filter.
If possible, use only one structure. Characteristics that are restricted in the structures should not then also be used in drilldowns. In an extreme case, this makes it necessary for the intersection to be calculated for each cell to determine if it is ready for input.
A ‘formula-based’ construction of a cell/column structure can often be achieved with one structure and one drilldown. For this, you must use the ‘Access Type for Result Values’ option according to characteristic relationships and, if necessary, create relevant characteristic relationships that model the required characteristic combinations.
Queries with two structures and, if necessary, cell definitions are almost always ‘large’ in the following sense: Each cell is described by selections, in addition, there are selections from the filter. As a result, the query has a high fixed cost portion that is required just for the cell description. In addition, there is the effort required to assign movement data to these cells and, if necessary, also to determine whether the cells are ready for input. For queries with two structures, you should use one characteristic in exactly one structure or as a free characteristic. If you use variables in a structure, replace these by a single value butneverby a long list of single values.

3.4 Components of a planning application

The components of a planning application are all objects that work together to form the actual planning application, for example, variables, queries, planning functions and planning sequences. Here we sometimes notice a tendency to create universal planning applications, that is, large Web templates or large BEx Analyzer applications that contain everything that you need. However, with regard to good performance, these applications are difficult to optimize, many components are rarely required and they are then simply ‘overhead’. Therefore, planning applications should contain only the components that are actually required. If in doubt, create another application.

3.4.1 Variables

If you use a large number of variables, try to determine the runtime that is required to replace the variables. You can exclude the variables during a performance analysis and define the selections. Compare the result with the version of the application that uses variables. In particular, measure the runtime when you use variable exits that require a complex logic to determine the values.

3.4.2 Queries

You should first individually optimize queries that occur in a planning application. If you use several queries in a planning application, you should use the option of only starting queries using commands when you actually require them. Otherwise, the system will start all queries at the start of the application and the runtime increases accordingly.

3.4.3 Planning functions/planning sequences

If you use planning sequences that contain a large number of planning functions, check whether you can combine some functions or whether some functions are already contained in others (for example, ‘Delete’ may already be contained in a ‘Copy’ function). In some cases, it may be useful to use a good implementation of a FOX function that combines some planning functions into one function.

4. Availability of optimizations

Customizing for this application and the quantity of data to be processed have the largest influence on the performance of a planning application. Therefore, the emphasis of performance optimizations of planning applications should be in this area.
Below, we have listed notes that may further improve the performance of planning applications. However, note that they are not universal, that is, they do not improve every planning application. Therefore, we have grouped the notes according to their main topics. If your planning application falls under a particular area, implement the notes specified in that section.
In general, we recommend that you import the most current Support Package. We recommend Support Package Stack 14 (that is BI Support Package 16) or higher. You must import at least BI Support Package 12. Notes with a validity before this Support Package are not handled here.

Optimizations for queries (general)

1055044 Performance in SAPLRRK0, form s_data_fuellen
1063768 Performance of plan queries with high no. of key figures
1067433 Performance optimization when you use derivations
1084602 Performance of combination check in the input-ready query
1094422: Input-ready query: Corrections for various errors
1101187 The OLAP tunnel
Note: Bear in mind that Note 1101187 contains very complex correction instructions. Read this note carefully and do not forget the required manual steps. This note is also relevant for planning functions, in particular when processing mass data. This note also helps to reduce the memory consumption in complex planning scenarios.
1104114 Follow-on error: Optimizing the performance of derivations
1114620 No new lines after Note 1063768 & Note 1084602 implemented
1117348 Subsequent correction to Note 1101187

Optimizations for queries with two structures

1019326 Integrated planning: Ready for input status of cells
1020323: Input-ready query: Characteristic relationships, memory consumption
1039781: Input-ready query: Performance
1055965 Performance: Queries with two structures, collect_chafix
1056050 BI planning: Internal errors
1063768 Performance of plan queries with high no. of key figures
1084602 Performance of combination check in the input-ready query
1114620 No new lines after Note 1063768 & Note 1084602 implemented
1132992 Performance problem when initializing variables
Note:Notes 1063768 and 1084602 also help with queries with just one structure that processes a large amount of data. In this situation, you should also use Note 1067433.

Optimizations if you use a large number of data slices with variables

1059304 CL_RSPLFU_IOBJ_HELPER->VAR_EXISTS performance improvement
1060908 Performance when you instantiate data slices
1068150 Performance: Buffering of data slices and char. relationships

Optimizations when using planning functions

1096045 Planning functions: Parsing before the execution
1101313 Reading the planning buffer with the correct date
1115910 Planning functions: Performance improvements
1121202 Planning functions: Distribution with keys
1149337 Main memory consumption and planning functions

Optimizations if you have very large MultiProviders

1040293 IP: Optimizations for writable InfoProviders
1075101 Subsequent correction to Note 1040293
Note: Implement this note only after consultation with SAP development.This warning concerns all notes that have Note 1040293 as prerequisite. This note is very large and has many complex dependencies. Therefore, we recommend that you import Support Package 14 for MultiProvider optimizations.
1072982 Metadata buffer for MultiProvider is not deleted
1090490 Buffering the MultiProvider runtime object
1110997 Subsequent correction to Note 1090490
1128031 Correction instructions in Note 1090490
Note: Bear in mind that Note 1090490 contains very complex correction instructions. Read this note carefully and do not forget the required manual steps.

Optimizations for the runtime of characteristic relationships and data slices

1016632: Unnecessary instantiation of characteristic relationships
1020059 Inconsistent filter in input-ready query
1044708 IP: Performance of generic time derivation
1067433 Performance optimization when you use derivations
1104114 Follow-on error: Optimizing the performance of derivations

Optimizations if you have large hierarchies

1058679 Several key selections in the select statement
1065041 Performance Problems in Queries with huge key selections
1068357 Planning functions: Selections on hierarchy nodes
See also the section ‘Optimizations of the BEx Web Analyzer’

Optimizations of the memory requirements

1020323: Input-ready query: Characteristic relationships, memory consumption
1042896 Release of memory after you close query
1090119 Table SELDR requires a large amount of memory space
1098057 Query: Dump NO_ROLL_MEMORY or other memory overflow
1107072 Improving the input help for 0INFOPROV
1112519 Inaccuracies in OLAP cache
1118671 Unnecessary memory consumption
1144702 Memory release, additional corrections to Note 1101187
1146957 Releasing memory OLAP_CACHE
1149337 Main memory consumption and planning functions

Optimizations of the BEx Analyzer

1017965 Variable screen takes a long time to appear and to close
1044219 Analyzer variable screen: Performance and documentation
1054168 Performance problems during conversion to formulas
Tip:If you use BEx Analyzer queries with two structures,
the time until the variable screen is called may be significant if you use the reference view option in the data provider settings.
1094799 Corrections in the BEx Analyzer server runtime
Caution:This note requires manual activities before implementation.
1118671 Unnecessary memory consumption
1150242 Improving performance/memory in the BEx Analyzer

Optimizations of the BEx Web Analyzer

1055003 Performance probs for hierarchies in Java Runtime (1062537)
1053054 Poor performance in hierarchy nodes in the filter
1062608 Long runtimes if you use an info field item
1085446 Poor performance due to result suppression
1086332 Long runtimes: Queries with many characteristics/attributes
1092068 ‘Dropdown Box’ Web item: Performance problems
1111470 Poor performance during filtering with many single values
1113195 Improving performance when there are several data providers
1128508 Performance improvements for web template with multiple tabs
1162580 Analysis item: Slow line selection performance

Various optimizations

1024554 Improving performance in queries in SAPLRSEC_CHECKS
1055044 Performance in SAPLRRK0, form s_data_fuellen
1059381 InfoProvider restriction in input help using MultiProviders
1060170 Performance improvement during analysis authorizations
1069675 Further performance improvement
1121993 Analysis auth’s: Performance optimization for special situ’s
1132992 Performance problem when initializing variables

Open hub: internal format in output file (neg numbers, …)

admin — Sat, 28 Nov 2009 03:29:24 +0000

Symptom

You load data into a file using an InfoSpoke. The internal format is always used for this. This can have the following undesired effects
1. If there are negative numbers under the extracted data, the minus sign is positioned after the number in the output file. However, you want the minus sign to be positioned before the number.2. If there are currency key figures under the extracted data, these are always written to the output file with two decimal places.3. If the extracted data contains currency key figures that are in a currency that does not use decimal places (such as Japanese Yen), these figures are too small by the factor 100 in the output file.4. If, among those currency key figures, there are currency key figures that have more than two decimal places in the external format, all decimal places over two are truncated from the key figure before they are converted to the two-character format. For example, a currency key figure that has the value 20001.23 in the external format is transferred as 2000.12. Bear this conversion in mind for the evaluation of the key figure.Other terms

Open hub, Business Add-In, less than zero, comma separated values (CSV), number, negative, minus
Reason and Prerequisites

When the data is copied from the open hub interface, it is copied from the display in the internal format directly to the string that is finally written to the file. In the internal display of a negative number, the minus sign is displayed after the number.
Solution

To correct the effects listed under ‘Symptom’, proceed as follows:
1. Minus sign for negative numbers: Create a Business Add-In implementation that has a copy of the source structure as its target structure (copy using Transaction SE11, for example, /BIC/CYMYSPOKE to ZMYSPOKE). Replace the negative number field (for example, MYNUMBER) with a sufficiently long character field (for example, MYNUMBER_CHAR with the data element CHAR20). Use the Business Add-In to move the minus sign in front of the number when you copy the data.

Sample source code:

zmyspoke-mynumber_char = /bic/cymyspoke-mynumber.
if zmyspoke-mynumber_char ca ‘-’.
shift zmyspoke-mynumber_char right deleting trailing ‘-’.
shift zmyspoke-mynumber_char left deleting leading ‘ ‘.
concatenate ‘-’ zmyspoke-mynumber_char into zmyspoke-mynumber_char.
endif.2. Number of decimal places: Create a Business Add-In (BAdI) implementation that has a copy of the source structure as its target structure (copy using Transaction SE11, for example, /BIC/CYMYSPOKE to ZMYSPOKE). Replace the key figure field in Transaction SE11 by an appropriately long DEC field with the required number of decimal places, for example, by choosing ‘Built-in type’. In the BAdI implementation, replace the contents of the field by dividing the original value by the power of 10 or multiplying the figure by the power of 10.
In the sample source code, a currency key figure MYNUMBER is multiplied by the factor 100 to provide a key figure MYNUMBER_YEN, which is defined without decimal places. This is required for the key figure for the currency Yen, for example:

zmyspoke-mynumber_yen = /bic/cymyspoke-mynumber * 100.

Error 2032 – Federated Portal Network and Xcelsius

admin — Sat, 28 Nov 2009 03:28:51 +0000

Symptom

When embedding a BEx Query via the SAP NW BI Connection you receive the error message 2032 immediatly after the BEx query selection dialog.
Please note that this is only relevant during Xcelsius design time and not during launching of the Xcelsius Dashboard (runtime).

Other terms

Xcelsius Design Time, Federated Portal Network, Error 2032, FPN,

Reason and Prerequisites

Prerequisite:
1. The landscape is configured as federated portal network. Details can be found in the SAP help portal:
http://help.sap.com/saphelp_nw70ehp1/helpdata/en/5b/9f2d4293825333e10000000a155106/frameset.htm
2. The default portal maintained in table RSPOR_T_PORTAL references the consumer portal. See SAP note 1149597 for more details.
The reason for the error 2032: Xcelsius receives the URL to the consumer portal as it is the default portal. When trying to invoke the Web Service to retrieve the BEx Query meta data the web service execution fails.

Solution

The NetWeaver BW system used for Xcelsius Dashboard design must return the URL to the producer portal. This can be achieved by following one of the options:
1. Elaborate reason for chosing the consumer portal as default portal. Example: in case it is a development system the producer portal might be allow to be called directly.
2. The default portal can be set per user. Set the producer portal as default portal for all users involved in creating and maintaining Xcelsius Dashboards.
3. The default portal can be set per user. Create a special user for maintaing and creating Xcelsius Dashboard with the producer as default.
A detailed description for setting the default portal per user is available here:
http://help.sap.com/saphelp_nw70ehp1/helpdata/de/45/fe8e3066bc3482e10000000a1553f6/frameset.htm

Error 2032 – Web Service is not available

admin — Sat, 28 Nov 2009 03:28:20 +0000

Symptom

When embedding a BEx Query via the SAP NW BI Connection you receive the error message 2032 immediatly after the BEx query selection dialog.

Other terms

Xcelsius, Error 2032, Java Support Package, Web Service, BicsRemote, version

Reason and Prerequisites

The Xcelsius Designer calls the Web Service BicsRemote to retreive Bex Query Meta Data. If the Web Service is not found on the portal an error 2032 is raised.

Solution

Follow the steps to check if the Web Service BicsRemote exists on the default portal of the BEx Web Runtime (table RSPOR_T_PORTAL). Please note that administrator rights are required perform the checks:
- launch the Webservice navigator on the java server by
/wsnavigator
e.g. http://:/wsnavigator
Hint: you can create the first part of URL by logging onto the
ABAP server -> Transaction RSRT -> Button “Java Web”
- select the webservice called “BicsRemote” -> document
- choose the test option
- select the operation: getWebServiceVersion
- on the next screen: press button “Send”
If this procedure does go through successfully and a Web Service version is displayed the error 2032 is not triggered by a missing Web Service.

Performance Optimierungen: Merkmalsbeziehungen Datenscheiben

admin — Sat, 28 Nov 2009 03:27:49 +0000

Symptom

Sie verwenden Merkmalsbeziehungen und/oder Datenscheiben in real-time InfoCubes, die in InfoProvider vorkommen, die f黵 eingabebereite Queries genutzt werden. Das System pr黤t dann jede laut Query Designer potentiell eingabebereite Zelle, ob diese zur Laufzeit eingabebereit sein kann.
Folgende Arten von Pr黤ungen werden vorgenommen, wenn diese f黵 den InfoProvider relevant sind, auf den die eingabebereite Query aufsetzt:
Merkmalsbeziehungen, die 黚er den Planning Modeler angelegt wurdenDatenscheiben, die 黚er den Planning Modeler angelegt wurdenRelationen, die die Konsistenz von Navigationsattributen zum Basismerkmal des Attributes pr黤enRelationen, die die Konsistenz der BW Zeitmerkmale pr黤enRelationen, die die Konsistenz von geklammerten Merkmalen pr黤en, die gemeinsam genutzte bzgl. der Klammerung 黚ergeordnete Merkmale benutzenStammdatenpr黤ungen f黵 Merkmale mit einer Stammdatenpr黤tabelle’Konsistenz’ des Query Filters zu eingeschr鋘kten Kennzahlen

Die mit diesem Hinweis ausgelieferten Optimierungen vermindern die Anzahl der vorzunehmenden Pr黤ungen, wenn die Listgeometrie der Query so ist, dass Merkmalsbeziehungen und Datenscheiben nicht erst pro Zelle sondern ggf. schon pro Zeile, Spalte oder pro eingeschr鋘kter Kennzahl gepr黤t werden k鰊nen.
Auch mit den Optimierungen aus diesem Hinweis kann es jedoch notwendig sein, jede Zelle aus dem Resultset der Query auf Konsistenz zu pr黤en. Daher beachten Sie folgenden Empfehlungen bzgl. der Modellierung von Merkmalsbeziehungen, Datenscheiben und eingabebereiten Queries.
1. Die Pr黤ung von Datenscheiben ist sehr effizient, wenn die Datenscheibe schon f黵 Strukturelemente der Query (z.B. f黵 eingeschr鋘kte Kennzahlen) gepr黤t werden kann. Dieser Fall tritt h鋟fig bei einer rollierenden Planung auf, wo etwa jeder Periode eines Jahres eine eingeschr鋘kte Kennzahl entspricht und der Planungshorizont die aktuelle Periode bis zum Jahresende umfasst. Mit einer Datenscheibe kann man alle Perioden vor der aktuellen Periode gegen 膎derungen sch黷zen. Diese Datenscheibe kann schon f黵 jede eingeschr鋘kte Kennzahl ausgewertet werden.2. Wenn Punkt 1 nicht zutrifft, achten Sie darauf, dass Merkmalsbeziehungen und Datenscheiben m鰃lichst ganz in den Zeilen oder Spalten einer Query liegen. Dann k鰊nen die Pr黤ungen pro Zeile bzw. pro Spalte vorgenommen werden, eine Pr黤ung pro Zelle ist dann nicht erforderlich. Diese Situation liegt z.B. vor, wenn Sie in einer Kostenstellenplanung in den Zeilen die Merkmale Kostenstellen, Kostenart verwenden und die erlaubten Kombinationen in einer Merkmalsbeziehung festgelegt wurden. Die Kennzahlstruktur enth鋖t nur Kennzahlen, die ggf. auf InfoProvider (z.B. Plan- und Ist-Cube) und auf jeweils eine Einheit eingeschr鋘kt sind. Weiterhin ist evtl. 黚er die Kennzahlstruktur ein Zeitmerkmal aufgerissen, auf welchem ggf. eine Datenscheibe liegt. Dann k鰊nen die Merkmalsbeziehung und die Datenscheibe unabh鋘gig voneinander jeweils auf den Zeilen bzw. Spalten gepr黤t werden.

Vermeiden Sie in eingabebereiten Queries Listgeometrien, in denen Merkmalsbeziehungen oder Datenscheiben erst auf Ebene einer Zelle gepr黤t werden k鰊nen. Das ist z.B. dann der Fall, wenn eine Merkmalsbeziehung zwei Merkmale enth鋖t, von denen eines in den Zeilen und eines in den Spalten der Query verwendet wird.
Die obigen Hinweise zur Modellierung sind auch hilfreich f黵 eine Verbesserung der Performance der Disaggregation, da das System ebenfalls bei einer Disaggregation pr黤en muss, ob alle Datens鋞ze, auf die ein Wert verteilt werden soll, auch 鋘derbar bzw. konsistent sind. Da f黵 eine Disaggregation ggf. sehr viele Datens鋞ze nachgelesen und gepr黤t werden m黶sen, sollten Sie die obige Hinweise zur Modellierung umsetzen, dann ist i.a. auch die Disaggregation signifikant schneller.
Weitere Begriffe

eingabebereite Query, Merkmalsbeziehungen, Datenscheiben, Performance
Ursache und Voraussetzungen

Sie verwenden Merkmalsbeziehungen und/oder Datenscheiben, die ganz in eingeschr鋘kten Kennzahlen oder einer Achse der Query enthalten sind.
Nur dann k鰊nen die Pr黤ungen von Merkmalsbeziehungen und Datenscheiben so ausgeklammert werden, dass weniger Pr黤ungen notwendig sind.
L鰏ung

Beachten Sie, dass vor dem Einbau des Hinweises mit der Transaktion SNOTE folgende manuelle T鋞igkeiten notwendig sind:
1. Erweitern Sie mit der Transaktion SE11 die StrukturRRK0_S_AXES_CIum die KomponenteIS_STRUCTUREmit dem KomponententypRRXISSTRUCTURE. Aktivieren Sie dann diese Struktur, ggf. auftretende Warungen k鰊nen Sie ignorieren.
2. Legen Sie mit der Transaktion SE91 folgende Meldungen in der Meldungsklasse BRAIN an:
Nachricht Nachrichtenkurztext
900 ‘&1 &2′ ist nicht eingabebereit, die Einschr鋘kung liegt nicht im Filter
901 ‘&1 &2′ ist nicht eingabebereit: Datenscheiben, Merkmalsbeziehungen
Die Langtexte zu diesen Meldungen werden mit SP06 f黵 Release 7.01 ausgeliefert.
Ein Downport dieses Hinweises auf ein Support Package zu Release 7.0 ist aufgrund der Komplexit鋞 der erforderlichen 膎derungen nicht m鰃lich.

SAP NetWeaver BI 7.01 (SAP NW BI7.0 EnhP 1)Spielen Sie das Support Package 06 f黵 SAP NetWeaver BI 7.01 (SAPKW70106) in Ihr BI-System ein. Das Support Package ist verf黦bar, wenn Hinweis 1369212 mit Kurztext “SAPBINews NW BI 7.01 ABAP SP06″, welcher dieses SP detailierter beschreibt, f黵 Kunden freigegeben ist.SAP NetWeaver BI 7.02 (SAP NW BI7.0 EnhP 2)Spielen Sie das Support Package 02 f黵 SAP NetWeaver BI 7.02 (SAPKW70202) in Ihr BI-System ein. Das Support Package ist verf黦bar, wenn Hinweis 1367863 mit Kurztext “SAPBINews NW BI 7.02 ABAP SP02″, welcher dieses SP detailierter beschreibt, f黵 Kunden freigegeben ist.SAP NetWeaver BI 7.20Spielen Sie das Support Package 02 f黵 SAP NetWeaver BI 7.20 (SAPKW72002) in Ihr BI-System ein. Das Support Package ist verf黦bar, wenn Hinweis 1387280 mit Kurztext “SAPBINews NW BI 7.2 ABAP SP02″, welcher dieses SP detailierter beschreibt, f黵 Kunden freigegeben ist.

In dringenden F鋖len kann die Korrekturanleitung als Vorabkorrektur verwendet werden.
Vorher sollten Sie unbedingt den Hinweis 875986 zur Transaktion SNOTE beachten.
Die genannten Hinweise k鰊nen bereits vor der Freigabe des Support Packages verf黦bar sein, um vorab Informationen zur Verf黦ung zu stellen. In diesem Fall enth鋖t der Kurztext allerdings noch das Wort “Vorabversion”.

Request finishes correctly but unavailable for reporting.

admin — Sat, 28 Nov 2009 03:27:21 +0000

Symptom

The Manage option through Context Menu in the InfoCube shows a request loaded with a yellow status and data is not available for reporting. The light remains yellow and the data never becomes available for reporting…
Other terms

yellow request
Reason and Prerequisites

A load into an Infocube was finished with success. The monitor shows everything green lights and the data was written into the fact tables correctly. In the Infocube manage the load appears as yellow.
Solution

Please check the infocube settings. Go to your infocube and check if the option “Set Quality Status to OK(Confirm Quality of Data)” was set. If this option was not set, then the load is executed into the infocube but the info is not available for reporting.
You can do it following these steps:
RSA1 >> >> Right Click >> Manage >> Environment >> Automatic Request Procesing >>
Check this option:
Set Quality Status to OK(Confirm Quality of Data).

After this please load a new request and check if it will be available for reporting automatically.

SAPBWNews NW2004 BI Add-OnFrontend SP08 -GUI 7.10

admin — Sat, 28 Nov 2009 03:26:46 +0000

Symptom

Error in Business Explorer Componenten like Analyzer, Browser, Formatted Reporting, Web Application Designer, Query Designer, Map, OLE DB for OLAP Provider
Other terms

Version, sapservX, Setup, Patch, Installation, Frontend, BW, Business Explorer, OCS
Reason and Prerequisites

.
Solution
General Information

This note contains information about NetWeaver 7.0 BI Add-On front-end
Support Package SP 8. It contains the most important information about:
o Import
o New errors
o Error corrections
o New improvements
Import

Take the following into account when you import the BI front-end Support Package: (This section is updated regularly)
New errors

New errors that may occur after you import the front-end Support
Package:

Error corrections

This BI front-end Support Package corrects the following errors:

inSAP Business Explorer Web Application Designer

inSAP Business Explorer Analyzer

inQuery Designer

inNavigator (Query 鋘dern lokal)

inVariablen Editor

inSAP Business Explorer Browser

inOpen-Dialog, Save-Dialog

inSAP Business Explorer Download Scheduler

inSelektor (Merkmalswerteinschr鋘kung/Filterauswahl)

New improvements

This front-end Support Package provides the following new enhancements:

inWeb Application Designer

inQuery Designer

inSAP Business Explorer Download Scheduler

RRI jump to R/3 – transaction “RSBBS_WEB” is unknown

admin — Sat, 28 Nov 2009 03:26:16 +0000

Symptom

You’ve configured a RRI jump to a R/3 transaction. If you do the RRI jump in the web the ITS window throws an error message like this:
Transaction RSBBS_WEB+RSRR_WEB-H is unknown

The issue occurs after applying a new support package to the R/3 target system.
Other terms

web RRI, transaction unknown, RSBBS_WEB+, ITS
Reason and Prerequisites

The issue is caused by a wrong Basis Support Package
Solution

The solve the issue please follow the instructions from SAP Note 1360904

SAP Netweaver Business Intelligence BI / BW

FAQ: SAP MaxDB indexes

Exploding structured articles

Changes to extraction structures in Customizing Cockpit

Aggregation of scheduling lines and statistics

Consulting: Loading of Datastore object using routines

Num. var. with replacement from attrib. or hierarchy attrib.

BI_CONT 724 FA: syntax errors in UPARI_ … Objects

Oracle Metalink access for SAP customers

Error message RD 159/RD 117 during extraction from CO-PA

BWA 7.00 & 7.20: Filling fails due to wrong date format

BW Change Run

Wrong Result When Using DBMS_REDEFINITION in RAC environment

Collective note: Performance of BI planning

Open hub: internal format in output file (neg numbers, …)

Error 2032 – Federated Portal Network and Xcelsius

Error 2032 – Web Service is not available

Performance Optimierungen: Merkmalsbeziehungen Datenscheiben

Request finishes correctly but unavailable for reporting.

SAPBWNews NW2004 BI Add-OnFrontend SP08 -GUI 7.10

RRI jump to R/3 – transaction “RSBBS_WEB” is unknown