OSS Notes Please

Question

Dear Gurus,
Can anyone send me the following OSS notes if u have.  567747, 130253 and 417307.  Your kind help will be definitely awarded.
My mail ID is [email protected]
Best Regards
Mohan Kumar
Message was edited by: mohan kumar

Answer 1

hi Mohan,
i think you will need to have access to oss yourself,
note 567747 is composite one that contains several notes.
sent to you mail ...
130253
Symptom
Uploading transaction data to BW takes too long
Other terms
Business Warehouse, data upload, batch upload, transaction data upload,
performance, runtime, data load, SPLIT_PARTITION_FAILED ORA00054
Reason and Prerequisites
Loading data from a mySAP system (for example, R/3) or from a file takes a very long time.
Solution
The following tips are a general check list to make the mass data upload to the Business Warehouse (BW) System as efficient as possible.
Tip 1:
Check the parameter settings of the database as described in composite Note 567745.
Check the basis parameter settings of the system.
Note 192658 Setting basis parameters for BW Systems
See the following composite notes:
Note 567747 Composite note BW 3.x performance: Extraction & loading
Note 567746 Composite note BW 3.x performance: Query & Web applications
Tip 2:
Import the latest BW Support Package and the latest kernel patch into your system.
Tip 3:
Before you upload the transaction data you should make sure that ALL relating master data has been loaded to your system. If no master has been loaded yet, the upload may take up to 100 percent longer because in this case, the system must retrieve master data IDs for the characteristic attributes and it must add new records to the master data tables.
Tip 4:
If possible, always use TRFC (PSA) as the transfer method instead of
IDocs. If you (have to) use IDocs, keep the number of data IDocs as low
as possible. We recommend an IDoc size of between 10000 (Informix) and 50000 (Oracle, MS SQL Server).
To upload from a file, set this value in Transaction RSCUSTV6.
To upload from an R/3 system, set this value in R/3 Customizing (SBIW -> General settings -> Control parameters for data transfer).
Tip 5:
If possible, load the data from a file on the application server and not from the client workstation as this reduces the network load. This also allows you to load in batch.
Tip 6:
If possible, use a fixed record length when you load data from a file (ASCII file). For a CSV file, the system only carries out the converison to a fixed record length during the loading process.
Tip 7:
When you load large data quantities from a file, we recommend that you split the file into several parts. We recommend using as many files of the same size as there are CPUs. You can then load these files simultaneously to the BW system in several requests. To do this, you require a fast RAID.
Tip 8:
When you load large quantities of data in InfoCubes, you should delete
the secodary indexes before the loading process and then recreate them afterwards if the following applies: The number of the records that are loaded is big in comparison to the number of records that already exist in the (uncompressed) F fact table. For non-transactional InfoCubes, you must delete the indexes to be able to carry out parallel loading.
Tip 9:
When you load large quantities of data in an InfoCube, the number range buffer should be increased for the dimensions that are likely to have a high number of data sets.
To do this, proceed as follows. Use function module RSD_CUBE_GET to find the object name of the dimension that is likely to have a high number of data sets.
Function module settings:
I_INFOCUBE = 'Infocube name'
I_OBJVERS = 'A'
I_BYPASS_BUFFER = 'X'
The numbers for the dimensions are then contained in table 'E_T_DIME', column 'NUMBRANR'. If you enter 'BID' before this number, you get the relevant number range (for example BID0000053).
You can use Transaction SNRO (-> ABAP/4 Workbench -> Development --> Other tools --> Number ranges) to display all number ranges for the dimensions used in BW if you enter BID*. You can use the object name that was determined beforehand to find the required number range.
By double-clicking this line, you get to the number range maintenance. Choose Edit -> Set-up buffering -> Main memory, to define the 'No. of numbers in buffer'.
Set this value to 500, for example. The size depends on the expected data quantity in the initial and in future (delta) uploads.
!! Never buffer the number range for the package dimension !!
Tip 10:
When you load large quantities of data, you should increase the number
range buffer for the info objects that are likely to have a high number of data sets. To do this, proceed as follows:
Use function module RSD_IOBJ_GET to find the number range name of the info object that is likely to have a high number of data sets.
Function module settings:
I_IOBJNM = 'Info object name'
I_OBJVERS = 'A'
I_BYPASS_BUFFER = 'X'
The number for the info object is in table 'E_S_VIOBJ', column 'NUMBRANR'. Enter 'BIM' in front of this number to get the required number range (for example BIM0000053).
Use Transaction SNRO (-> ABAP/4 Workbench -> Development --> Other tools --> Number ranges) to display all number ranges used for the info objects in BW by entering BIM*. By entering the object name determined beforehand you can find the desired number range.
By double-clicking this line you get to the number range object maintenance. Choose Edit -> Set-up buffering -> Main memory, to define the 'No. of numbers in buffer'.
Set this value to 500, for example. The size depends on the expected data quantity in the initial and in future (delta) uploads.
!! Never buffer the number range object for the characteristic 0REQUEST!!
417307
Symptom
Performance load is too high/not justifiable during data load.
Customizing settings via extractors IMG path (Transaction SBIW in the OLTP system; can be called directly in the OLTP or using Customizing, from the BW system) do not yield any considerable improvement or are not clear.
The settings in Table ROIDOCPRMS or in the Scheduler in the BW system are not taken into account by some extractors. How is the data package size defined for the data transfer to the BW? Are there application-specific features to determine the package size? If so, what are they?
Other terms
SBIW, general settings extractors, MAXSIZE, data volume, OLTP, service API, data package size, package size, performance
Reason and Prerequisites
The general formula is:
      Package size = MAXSIZE * 1000 / size of the transfer structure,
                    but not more than MAXLINES.
You can look up the transfer structure (extract structure) in Table ROOSOURCE in the active version of the DataSource and determine its size via SE11 (DDIC) -> Utilities -> Runtime object -> Table length.
The system default values of 10,000 or 100,000 are valid for the MAXSIZE and MAXLINES parameters (see the F1 help for the corresponding fields in ROIDOCPRMS). You can use the IMG Transaction SBIW (in the OLTP system) "Maintain General settings for extractors" to overwrite these parameters in Table ROIDOCPRMS on a system-specific basis. You also have the option of overriding these values in the scheduler (in the target BW system). However, in the Scheduler (InfoPackage) you can only reduce the MAXSIZE. The advantage of using the Scheduler to carry out maintenance is that the values are InfoSource-specific.
However, some extractors have their own flow logic which MAXSIZE does not load 1:1 from the ROIDOCPRMS.
This Note does not cover all SAP applications.
Solution
Application/DataSource               Standard settings or note
Generic extractor                     Standard (Example: Note 409641)
Delta Extraction via DeltaQueue       Standard as of PlugIn 2000.2
                                           Patch 3
LO-LIS                                 Standard
Logistic Cockpit SD                       Notes 419465 and 423118
Logistic Cockpit MM-IM:
Extraction 2LIS_03_UM                     Notes 537235 and 585750
Extraction 2LIS_03_BF                     Note 454267
           In general, the following applies to Logistic Cockpit Extraction: The package size set only serves as guideline value.
            Depending on the application, contents and structure of the documents, and the selection in the reconstruction program, the actual size of the transfer packages may differ considerably. That is not an error.
            For 'Queued Delta' update mode the package size of 9999 LUWs (=Logical Unit of Work, in this particular case documents or posting units per transaction are concerned) is set for LO Cockpit. However, if a transaction updated more than 10000 documents at once, the number 9999 would be invalid. This is because an update process cannot be split.
            In the case of a 'Direct Delta' update mode there is no package size for LUW bundling. In the DeltaQueue (RSA1) every LUW is updated individually.
           Also note the following:
                     If you want to transfer large data sets into the BW System, it is a good idea to carry out the statistical data setup and the subsequent data transfer in several sub-steps. In doing so, the selections for the statistical data setup and in the BW InfoPackage must correspond to each other. For performance reasons, we recommend using as few selection criteria as possible. You should avoid complex selections. After loading init delta with selection 1, the setup table has to be deleted and rebuilt with selection 2.
                     Bear the following in mind: The delta is loaded for the sum of all selections from the init deltas. Remember that the selections are made so that they do not impede the delta load, for example, if you have initialized the delta for the periods January 1st, 1999 to December 1st, 2000 and December 2nd, 2000 to August 1st, 2001 then you get a time interval from January 1st, 1999 to August 1st, 2001 in the BW. Documents from August 2nd, 2001 are no longer loaded.
CO-OM                                     Note 413992
PS                                        Standard or according
                                           to Note 413992
CO-PC                                     Standard
FI (0FI-AR/AP-3)                          First tables with open items(BSID for customers, BSIK for vendors) are read. The package size from the MAXISE field in Table ROIDOCPRMS is used in the extraction from these tables. If the packages are grouped together according to ROIDOCPRMS and a few data records still remain, these remaining records are transferred in one additional package.
After the open items are extracted, the system extracts from the table of cleared items (BSAD for customers, BSAK for vendors). In this extraction,the package size from the MAXSIZE field is adhered to.
FI (0FI-/AR/AP/-4 , new as of BW 30A) Like FI-AR/AP-3, but with one difference: if there are remaining records after the system reads the open items using the setting in the MAXSIZE field, they are not transferred in one extra package, but added to the first package of items read from the table of cleared items. For example, if 10 data packages with 15000 data records are extracted from Table BSID in accordance with ROIDOCPRMS, and 400 data records remain, the package size of the first data package from Table BSAD is 15400.
Both new and changed records are formatted in the following sequence in the delta transfer: 1) new BSIK/BSID records; 2) new BSAK/BSAD records; 3) changed BSIK/BSID records; 4) changed BSAK/BSAD records.
Package size 0FI_GL_4:
Prior to Note 534608 and the related notes, package size could vary considerably since the MAXLINES were applied to the document headers only. Then all documents lines for the document headers were read and transferred. As a result, the packages were 2 to 999 times as large as MAXLINES depending on the number of line items per document.
Note 534608 and the related notes changed the logic so that the MAXLINES is now also applied to the document lines. For each package, MAXLINES can be exceeded by up to 998 lines since a document is always transferred completely in one package. Smaller 'remaining packages' may also occur; for example if MAXLINES = 10000, and 10000 document headers with 21000 lines are selected, 2x10000 and the remainder of 1000 were were transferred in a separate package. Selection logic in 0FI_GL_4: Selection of the new FI documents via CPUDT -> the changed documents are then selected via Table BWFI_AEDAT. When changing the selection from new to changed documents, a package may occur which consists of the 'remainder' of the CPUDT selection and the first package of the BWFI_AEDAT selection. This package can then have a maximum size of 2 x MAXLINES.
FI-FM                                  Note 416669
EC-PCA                                 For the most part, the systemadheres to the standard settings but for technical reasons, packages packages smaller than the MAXSIZE or 7200 larger than the MAXSIZE may be omitted in Table ROIDOCPRMS
FI-SL                                  as in EC-PCA
PT                                     Standard (refer to Note
                                       397209)
PY                                     Standard
PA                                     Standard
RE                                     Standard
ISR-CAM (Category Management,
         new as of PlugIn 2001.1)     Standard
CO-PA                                  During the initialization and fullupdate in the profitability analysis, a join is always read from two tables (For details see Note 392635). To avoid terminations caused by Select statements that run for too long, access occurs with intervals for the object numbers (fixed size 10,000). New intervals are read until the package size requested by BW is reached. Therefore the size of the data package is always equal to or larger than the specification, but it can vary considerably.
Master data:
Business partner                       Standard
Product                                Standard
Customer                               Standard
Vendor                                 Standard
Plant                                  Standard
Material                               Standard
567747
Symptom
You want to improve the performance of the extraction and loading of your data into SAP BW 3.x.
Solution
This is a composite note that deals with performance-relevant topics in the area of extraction and loading.
If you encounter performance problems, ensure that the current Support Package has been imported.
This note is continually updated. You should therefore download a new version on a regular basis.
You will find further documents in the SAP Service Marketplace, alias bw under the folder "Performance".
Contents:
I.    Extraction from the OLTP
II.   Loading generally
III.  Master data
IV.   Roll-Up/aggregate structure
V.    Compression
VI.   Hierarchies/attribute realignment run
VII.  DataMart interface
VIII. ODS objects
IX.   Miscellaneous
I.    Extraction from the OLTP
Note 417307: extractor packet size: Collective note for applications
Note 505700: LBWE: New update methods from PI 2002.1
Note 398041: INFO: CO-OM/IM IM content (BW)
Note 190038: Composite note performance for InfoSource 0CO_PC_01 and
Note 436393: Performance improvement for filling the setup tables
Note 387964: CO delta extractors: poor performance for Deltainit
II.   Loading generally
Note 130253: Notes on uploading transaction data into BW
Note 555030: Deactivating BW-initiated DB statistics
Note 620361: Performance data loading/Admin. data target, many requests
III.  Master data
Note 536223: Activating master data with navigation attributes
Note 421419: Parallel loading of master data (several requests)
IV.   Roll-Up/aggregate structure
Note 484536: Filling aggregates of large InfoCubes
Note 582529: Rollup of aggregates & indexes (again as of BW 3.0B Support Package 9)
V.    Compression
Note 375132: Performance optimization for InfoCube condensation
Note 583202: Change run and condensing
VI.   Hierarchies/attribute realignment run
Note 388069: Monitor for the change run
Note 176606: Apply Hierarchy/Attribute change ... long runtime
Note 534630: Parallel processing of the change run
Note 583202: Change run and condensing
VII.  DataMart interface
Note 514907: Processing complex queries (DataMart, and so on)
Note 561961: Switching the use of the fact table view on/off
VIII. ODS objects
Note 565725: Optimizing the performance of ODS objects in BW 3.0B
IX.   Miscellaneous
Note 493980: Reorganizing master data attributes and master data texts
Note 729402: Performance when compiling and searching in the AWB