Note 888889 - Automatic checks for security notes using RSECNOTE
Summary
SymptomThe
SAP EarlyWatch Alert report contains selected checks about "Security".
Among other things, there is a check to determine whether or not
selected and required security-relevant notes or HotNews have been
implemented in the system. The report displays an overall status. An
administrator uses the tool RSECNOTE to create the detailed evaluation
of the required security-relevant notes in the system to be analyzed.
This note responds to the following situations:
Reason and PrerequisitesThe tool RSECNOTE is part of the software component ST-A/PI as of Release 01M_*. Correction instructions are available for the installation in Release 01L_*.
As of Support Package 3 for the Service Content Plug-In ST-SER 701_2008_2, various services in the Solution Manager require the tool RSECNOTE on the managed system to check whether or not security-relevant notes are implemented.
The service report shows that this tool is missing and makes reference to this present Note 888889.
SolutionBelow you will find:
- a guide to implementing the tool RSECNOTE
- documentation on using the tool and information about the background and further procedures
Guide for creating the tool RSECNOTE
You use transaction ST13 to start the tool RSECNOTE. In transaction ST13, select the tool and start it by choosing "Execute" or F8.
Comment: As of SAP_BASIS Release 620 Support Package 55, SAP_BASIS Release 640 Support Package 13, SAP_BASIS Release 700 and subsequent releases, you can also start the tool as the report RSECNOTE by using transaction SA38, for example.
As a result of the tool RSECNOTE, notes that contain security corrections and notes that are relevant for your system due to the existing software components (taking the releases and the Support Packages into account) are displayed.
The report shows the following three sections:
For Note 1298433 "Security note: Bypassing security in reginfo & secinfo", however, the system checks only that at least the required kernel patch is installed. It does not check whether the gateway has also been safeguarded.
An overview of other security-relevant notes or HotNews is provided on the SAP Service Marketplace under the quick link /SECURITYNOTES (https://service.sap.com/securitynotes).
Updating recommendationsThe quantity of checked notes or HotNews is managed online by SAP. During a check, a system loads the list automatically using the service connection to SAPNet once a day. You can also use the tool RSECNOTE to update the list manually (menu path: List -> Refresh from SAPNet).
If the system to be checked does not have an online connection to SAPNet, then you can also use a transport to import the current recommendations from another system that has a connection to SAPNet. To do this, create a "Transport of Copies" and enter the object key R3TR TABU /SSF/PTAB. Enter ND* as the table key. This means that all recommendations are selected, including the recommendations for the tools RTCCTOOL and RSECNOTE. Make sure that you have specified a table key. Start the tool RTCCTOOL or RSECNOTE before you export the transport request, to update the recommendations.
Attached to this note is the file
Transport_Files_.zip, which contains the recommendations for the tool RSECNOTE for the specified date. Use the transport files contained in it if you do not have any systems that have an online connection to SAPNet.
EarlyWatch Alert report
The SAP EarlyWatch Alert report also provides a summary of the results of the tool RSECNOTE. For further information on the SAP EarlyWatch Alert report, see Note 863362.
Note Assistant
You can use the Note Assistant (transaction SNOTE) to implement the correction instructions. You can find additional information about the Note Assistant on SAP Service Marketplace under the quick link /NOTE-ASSISTANT (https://service.sap.com/note-assistant).
This note responds to the following situations:
- In the SAP EarlyWatch Alert report, the "Service Preparation Check" unit complains that Note 888889 is not implemented. As a result, the check for security-relevant notes can only be carried out partially in the "Security" section.
- You want to use the tool RSECNOTE to check the implementation status of security-relevant notes in your system. However, this tool is not yet available in your system.
- You require detailed information on implementing and executing the tool RSECNOTE, and on interpreting the results.
- You call transaction ST13. In the F4 help for the "Tool Name" field, the entry RSECNOTE is missing. If you manually enter RSECNOTE and then execute it, the system issues the message "The tool RSECNOTE does not exist".
- The tool RTCCTOOL shows that the tool RSECNOTE is missing.
Reason and PrerequisitesThe tool RSECNOTE is part of the software component ST-A/PI as of Release 01M_*. Correction instructions are available for the installation in Release 01L_*.
As of Support Package 3 for the Service Content Plug-In ST-SER 701_2008_2, various services in the Solution Manager require the tool RSECNOTE on the managed system to check whether or not security-relevant notes are implemented.
The service report shows that this tool is missing and makes reference to this present Note 888889.
SolutionBelow you will find:
- a guide to implementing the tool RSECNOTE
- documentation on using the tool and information about the background and further procedures
Guide for creating the tool RSECNOTE
- 1.
Install the tool RSECNOTE in all systems in which you want to use the
tool. SAP recommends that you install Release 01M_* of the software
component ST-A/PI. See Note 69455 for more information.
You can also install the tool RSECNOTE in Release 01L_* by implementing the correction instructions using transaction SNOTE. Go to "System Change Option" in transaction SE06 and set the software component ST-A/PI and the namespaces/name ranges "General SAP Name Range", /SSA/, and /SSF/ to "Modifiable". Enter /SSA/RTC if you are asked to specify a main program for /SSA/INT.
- 2. Assign the following authorizations to all the users for whom you want to provide access to the tool.
| Object | Field | Value |
|---|---|---|
| S_TCODE | TCD | ST13 |
| S_ADMI_FCD | S_ADMI_FCD | ST0R |
| S_PTCH_ADM | TABLE | ' (or empty) |
| COMPONENT | SECURITY-CHECK | |
| ACTVT | 02 (change) | |
You use transaction ST13 to start the tool RSECNOTE. In transaction ST13, select the tool and start it by choosing "Execute" or F8.
Comment: As of SAP_BASIS Release 620 Support Package 55, SAP_BASIS Release 640 Support Package 13, SAP_BASIS Release 700 and subsequent releases, you can also start the tool as the report RSECNOTE by using transaction SA38, for example.
As a result of the tool RSECNOTE, notes that contain security corrections and notes that are relevant for your system due to the existing software components (taking the releases and the Support Packages into account) are displayed.
The report shows the following three sections:
- "Missing recommendations"
This section shows the required security-relevant SAP Notes and HotNews.
HotNews are flagged with a red traffic light and notes are flagged with a yellow traffic light.
- "Manually confirmed recommendations"
Report messages can also be confirmed manually. This should only happen in exceptional cases that require it.
For example: You cannot implement a specific note using transaction SNOTE because you manually changed the affected program beforehand. In this case, implement the corrections manually and confirm the message.
- "Successfully implemented recommendations"
This section shows the security-relevant notes and HotNews that are required for the system and that are implemented successfully.
A note or a HotNews is no longer required if your system release or Support Package level already contains the correction. After the system is upgraded or Support Packages are imported, a note that was implemented earlier may no longer be listed.
For Note 1298433 "Security note: Bypassing security in reginfo & secinfo", however, the system checks only that at least the required kernel patch is installed. It does not check whether the gateway has also been safeguarded.
An overview of other security-relevant notes or HotNews is provided on the SAP Service Marketplace under the quick link /SECURITYNOTES (https://service.sap.com/securitynotes).
Updating recommendationsThe quantity of checked notes or HotNews is managed online by SAP. During a check, a system loads the list automatically using the service connection to SAPNet once a day. You can also use the tool RSECNOTE to update the list manually (menu path: List -> Refresh from SAPNet).
If the system to be checked does not have an online connection to SAPNet, then you can also use a transport to import the current recommendations from another system that has a connection to SAPNet. To do this, create a "Transport of Copies" and enter the object key R3TR TABU /SSF/PTAB. Enter ND* as the table key. This means that all recommendations are selected, including the recommendations for the tools RTCCTOOL and RSECNOTE. Make sure that you have specified a table key. Start the tool RTCCTOOL or RSECNOTE before you export the transport request, to update the recommendations.
Attached to this note is the file
Transport_Files_.zip, which contains the recommendations for the tool RSECNOTE for the specified date. Use the transport files contained in it if you do not have any systems that have an online connection to SAPNet.
EarlyWatch Alert report
The SAP EarlyWatch Alert report also provides a summary of the results of the tool RSECNOTE. For further information on the SAP EarlyWatch Alert report, see Note 863362.
Note Assistant
You can use the Note Assistant (transaction SNOTE) to implement the correction instructions. You can find additional information about the Note Assistant on SAP Service Marketplace under the quick link /NOTE-ASSISTANT (https://service.sap.com/note-assistant).
Header Data
| Release Status: | Released for Customer |
| Released on: | 03.05.2010 07:08:40 |
| Master Language: | German |
| Priority: | Recommendations/additional info |
| Category: | Advance development |
| Primary Component: | SV-SMG-SER SAP Support Services |
| Secondary Components: | XX-INT-SR Security Response |
Note 1144998 - Incorrect data for DataStores with option "Unique records"
Summary
Symptom
You activate data of a request in a DataStore object for which the option "only unique data records" has been selected.
The request to be activated contains deletion records (Delete/Reverse-Images) and change records (Before/After/New-Images) for a key.
The following symptoms may occur due to incorrect handling of deletion records:
RSODSO_PROCESSING 003, RSODSO_PROCESSING003, INSERT ONLY, D-Image, R-Image, ' '-Image, delete, incorrect, inconsistent, incorrect data
Reason and Prerequisites
The symptoms described above only occur if the change records and deletion records are distributed among different data packages during extraction.
This case may occur if
In urgent cases, you can implement the correction instructions as an advance correction.
You must first read Note 875986, which provides information about transaction SNOTE.
To provide information in advance, the notes mentioned above may already be available before the Support Package is released. In this case, the short text of the note contains the words "Preliminary version".
You activate data of a request in a DataStore object for which the option "only unique data records" has been selected.
The request to be activated contains deletion records (Delete/Reverse-Images) and change records (Before/After/New-Images) for a key.
The following symptoms may occur due to incorrect handling of deletion records:
- An inconsistent change log is updated. As a result, there are inconsistent records in the table of the active data when the request is deleted.
- Activation terminates with the error "Error during update of data records for data package [DP]".
- The deletion record is ignored, and this leads to incorrect records in the table of the active data.
RSODSO_PROCESSING 003, RSODSO_PROCESSING003, INSERT ONLY, D-Image, R-Image, ' '-Image, delete, incorrect, inconsistent, incorrect data
Reason and Prerequisites
The symptoms described above only occur if the change records and deletion records are distributed among different data packages during extraction.
This case may occur if
- The changes or deletions are posted in different transactions in the source system
- You update data from a DataStore object to another DataStore object using delta.
- SAP NetWeaver 7.0 BI
In urgent cases, you can implement the correction instructions as an advance correction.
You must first read Note 875986, which provides information about transaction SNOTE.
To provide information in advance, the notes mentioned above may already be available before the Support Package is released. In this case, the short text of the note contains the words "Preliminary version".
Header Data
| Release Status: | Released for Customer |
| Released on: | 04.04.2008 12:53:58 |
| Master Language: | German |
| Priority: | HotNews |
| Category: | Program error |
| Primary Component: | BW-WHM-DBA-ODS DataStore-Object/ODS-Object |
| Secondary Components: | BW-WHM-DBA Data Basis |
This note maintained here for my quick reference and for those dont have SAP Notes access :-)
Question 1:
What does the number in the 'Total' column in Transaction RSA7 mean?
Answer:
The 'Total' column displays the number of LUWs that were written in the delta queue and that have not yet been confirmed. The number includes the LUWs of the last delta request (for repeating a delta request) and the LUWs for the next delta request. An LUW only disappears from the RSA7 display when it has been transferred to the BW System and a new delta request has been received from the BW System.
Question 2:
What is an LUW in the delta queue?
Answer:
An LUW from the point of view of the delta queue can be an individual document, a group of documents from a collective run or a whole data packet from an application extractor.
Question 3:
Why does the number in the 'Total' column, in the overview screen of Transaction RSA7, differ from the number of data records that are displayed when you call up the detail view?
Answer:
The number on the overview screen corresponds to the total number of LUWs (see also question 1) that were written to the qRFC queue and that have not yet been confirmed. The detail screen displays the records contained in the LUWs. Both the records belonging to the previous delta request and the records that do not meet the selection conditions of the preceding delta init requests are filtered out. This means that only the records that are ready for the next delta request are displayed on the detail screen. The detail screen of Transaction RSA7 does not take into account a possibly existing customer exit.
Question 4:
Why does Transaction RSA7 still display LUWs on the overview screen after successful delta loading?
Answer:
Only when a new delta has been requested does the source system learn that the previous delta was successfully loaded into the BW System. The LUWs of the previous delta may then be confirmed (and also deleted). In the meantime, the LUWs must be kept for a possible delta request repetition. In particular, the number on the overview screen does not change if the first delta is loaded into the BW System.
Question 5:
Why are selections not taken into account when the delta queue is filled?
Answer:
Filtering according to selections takes place when the system reads from the delta queue. This is necessary for performance reasons.
Question 6:
Why is there a DataSource with '0' records in RSA7 if delta exists and has been loaded successfully?
Answer:
It is most likely that this is a DataSource that does not send delta data to the BW System via the delta queue but directly via the extractor . You can display the current delta data for these DataSources using TA RSA3 (update mode ='D')
Question 7:
Do the entries in Table ROIDOCPRMS have an impact on the performance of the loading procedure from the delta queue?
Answer:
The impact is limited. If performance problems are related to the loading process from the delta queue, then refer to the application-specific notes (for example in the CO-PA area, in the logistics cockpit area, and so on).
Caution: As of PlugIn 2000.2 patch 3, the entries in Table ROIDOCPRMS are as effective for the delta queue as for a full update. Note, however, that LUWs are not split during data loading for consistency reasons. This means that when very large LUWs are written to the delta queue, the actual package size may differ considerably from the MAXSIZE and MAXLINES parameters.
Question 8:
Why does it take so long to display the data in the delta queue (for example approximately 2 hours)?
Answer:
With PlugIn 2001.1 the display was changed: you are now able to define the amount of data to be displayed, to restrict it, to selectively choose the number of a data record, to make a distinction between the 'actual' delta data and the data intended for repetition, and so on.
Question 9:
What is the purpose of the function 'Delete Data and Meta Data in a Queue' in RSA7? What exactly is deleted?
Answer:
You should act with extreme caution when you use the delete function in the delta queue. It is comparable to deleting an InitDelta in the BW System and should preferably be executed there. Not only do you delete all data of this DataSource for the affected BW System, but you also lose all the information concerning the delta initialization. Then you can only request new deltas after another delta initialization.
When you delete the data, this confirms the LUWs kept in the qRFC queue for the corresponding target system. Physical deletion only takes place in the qRFC outbound queue if there are no more references to the LUWs.
The delete function is intended for example, for cases where the BW System, from which the delta initialization was originally executed, no longer exists or can no longer be accessed.
Question 10:
Why does it take so long to delete from the delta queue (for example half a day)?
Answer:
Import PlugIn 2000.2 patch 3. With this patch the performance during deletion improves considerably.
Question 11:
Why is the delta queue not updated when you start the V3 update in the logistics cockpit area?
Answer:
It is most likely that a delta initialization had not yet run or that the the delta initialization was not successful. A successful delta initialization (the corresponding request must have QM status 'green' in the BW System) is a prerequisite for the application data to be written to the delta queue.
Question 12:
What is the relationship between RSA7 and the qRFC monitor (Transaction SMQ1)?
Answer:
The qRFC monitor basically displays the same data as RSA7. The internal queue name must be used for selection on the initial screen of the qRFC monitor. This is made up of the prefix 'BW, the client and the short name of the DataSource. For DataSources whose name is shorter than 20 characters, the short name corresponds to the name of the DataSource. For DataSources whose name is longer than 19 characters (for delta-capable DataSources only possible as of PlugIn 2001.1) the short name is assigned in Table ROOSSHORTN.
In the qRFC monitor you cannot distinguish between repeatable and new LUWs. Moreover, the data of a LUW is displayed in an unstructured manner there.
Question 13:
Why is there data in the delta queue although the V3 update has not yet been started?
Answer:
You posted data in the background. This means that the records are updated directly in the delta queue (RSA7). This happens in particular during automatic goods receipt posting (MRRS). There is no duplicate transfer of records to the BW system. See Note 417189.
Question 14:
Why does the 'Repeatable' button on the RSA7 data details screen not only show data loaded into BW during the last delta but also newly-added data, in other words, 'pure' delta records?
Answer:
It was programmed so that the request in repeat mode fetches both actually repeatable (old) data and new data from the source system.
Question 15:
I loaded several delta inits with various selections. For which one
is the delta loaded?
Answer:
For delta, all selections made via delta inits are summed up. This
means a delta for the 'total' of all delta initializations is loaded.
Question 16:
How many selections for delta inits are possible in the system?
Answer:
With simple selections (intervals without complicated join conditions or single values), you can make up to about 100 delta inits. It should not be more.
With complicated selection conditions, it should be only up to 10-20 delta inits.
Reason: With many selection conditions that are joined in a complicated way, too many 'where' lines are generated in the generated ABAP source code which may exceed the memory limit.
Question 17:
I intend to copy the source system, i.e. make a client copy. What will happen with may delta? Should I initialize again after that?
Answer:
Before you copy a source client or source system, make sure that your deltas have been fetched from the delta queue into BW and that no delta is pending. After the client copy, an inconsistency might occur between BW delta tables and the OLTP delta tables as described in Note 405943. After the client copy, Table ROOSPRMSC will probably be empty in the OLTP since this table is client-independent. After the system copy, the table will contain the entries with the old logical system name which are no longer useful for further delta loading from the new logical system. The delta must be initialized in any case since delta depends on both the BW system and the source system. Even if no dump 'MESSAGE_TYPE_X' occurs in BW when editing or creating an InfoPackage, you should expect that the delta has to be initialized after the copy.
Question 18.
Am I permitted to use the functions in Transaction SMQ1 to manually control processes?
Answer:
Use SMQ1 as an instrument for diagnosis and control only. Make changes to BW queues only after informing BW Support or only if this is explicitly requested in a note for Component 'BC-BW' or 'BW-WHM-SAPI'.
Question 19.
Despite the delta request only being started after completion of the collective run (V3 update), it does not contain all documents. Only another delta request loads the missing documents into BW. What is the cause for this "splitting"?
Answer:
The collective run submits the open V2 documents to the task handler for processing. The task handler processes them in one or several parallel update processes in an asynchronous way. For this reason, plan a sufficiently large "safety time window" between the end of the collective run in the source system and the start of the delta request in BW. An alternative solution where this problem does not occur is described in Note 505700.
Question 20.
Despite deleting the delta init, LUWs are still written into the DeltaQueue
Answer:
In general, delta initializations and deletions of delta inits should always be carried out at a time when no posting takes place. Otherwise, buffer problems may occur: If you started the internal mode at a time when the delta initialization was still active, you post data into the queue even though the initialization had been deleted in the meantime. This is the case in your system.
Question 21.
In SMQ1 (qRFC Monitor) I have status 'NOSEND'. In the Table TRFCQOUT, some entries have the status 'READY', others 'RECORDED'. ARFCSSTATE is 'READ'. What do these statuses mean? Which values in the field 'Status' mean what and which values are correct and which are alarming? Are the statuses BW-specific or generally valid in qRFC?
Answer:
Table TRFCQOUT and ARFCSSTATE: Status READ means that the record was read once either in a delta request or in a repetition of the delta request. However, this still does not mean that the record has successfully reached the BW. The status READY in the TRFCQOUT and RECORDED in the ARFCSSTATE means that the record has been written into the delta queue and will be loaded into the BW with the next delta request or a repetition of a delta. In any case only the statuses READ, READY and RECORDED in both tables are considered to be valid. The status EXECUTED in TRFCQOUT can occur temporarily. It is set before starting a delta extraction for all records with status READ present at that time. The records with status EXECUTED are usually deleted from the queue in packages within a delta request directly after setting the status before extracting a new delta. If you see such records, it means that either a process which confirms and deletes records loaded into the BW is successfully running at the moment, or, if the records remain in the table for a longer period of time with status EXECUTED, it is likely that there are problems with deleting the records which have already been successfully been loaded into the BW. In this state, no more deltas are loaded into the BW. Every other status indicates an error or an inconsistency. NOSEND in SMQ1 means nothing (see note 378903). However the value 'U' in field 'NOSEND' of table TRFCQOUT is of concern.
Question 22.
The extract structure was changed when the delta queue was empty. Afterwards new delta records were written to the delta queue. When loading the delta into the PSA, it shows that some fields were moved. The same result occurs when the contents of the delta queue are listed via the detail display. Why is the data displayed differently? What can be done?
Answer:
Make sure that the change of the extract structure is also reflected in the database and that all servers are synchronized. We recommend resetting the buffers using Transaction $SYNC. If the extract structure change is not communicated synchronously to the server where delta records are being created, the records are written with the old structure until the new structure has been generated. This may have disastrous consequences for the delta. When the problem occurs, the delta needs to be re-initialized.
Question 23.
How and where can I control whether a repeat delta is requested?
Answer:
Via the status of the last delta in the BW Request Monitor. If the request is RED, the next load will be of type 'Repeat'. If you need to repeat the last load for any reason, manually set the request in the monitor to red. For the contents of the repeat, see Question 14. Delta requests set to red when data is already updated lead to duplicate records in a subsequent repeat, if they have not already been deleted from the data targets concerned.
Question 24.
As of PI 2003.1, the Logistic Cockpit offers various types of update methods. Which update method is recommended in logistics? According to which criteria should the decision be made? How can I choose an update method in logistics?
Answer:
See the recommendation in Note 505700.
Question 25.
Are there particular recommendations regarding the maximum data volume of the delta queue to avoid danger of a read failure due to memory problems?
Answer:
There is no strict limit (except for the restricted number area of the 24-digit QCOUNT counter in the LUW management table - which is of no practical importance, however - or the restrictions regarding the volume and number of records in a database table).
When estimating "soft" limits, both the number of LUWs and the average data volume per LUW are important. As a rule, we recommend bundling data (usually documents) as soon as you write to the delta queue to keep number of LUWs low (this can partly be set in the applications, for example in the Logistics Cockpit). The data volume of a single LUW should not be much larger than 10% of the memory available to the work process for data extraction (in a 32-bit architecture with a memory volume of about 1 GByte per work process, 100 MByte per LUW should not be exceeded). This limit is of rather small practical importance as well since a comparable limit already applies when writing to the delta queue. If the limit is observed, correct reading is guaranteed in most cases.
If the number of LUWs cannot be reduced by bundling application transactions, you should at least make sure that the data is fetched from all connected BWs as quickly as possible. But for other, BW-specific, reasons, the frequency should not exceed one delta request per hour.
To avoid memory problems, a program-internal limit ensures that no more than 1 million LUWs are ever read and fetched from the database per delta request. If this limit is reached within a request, the delta queue must be emptied by several successive delta requests. We recommend, however, to try not to reach that limit but trigger the fetching of data from the connected BWs as soon as the number of LUWs reaches a 5-digit value.
---> Some more related Notes....
873694 - Consulting: Delta repeat and status in monitor/data target
771894 - No data during delta upload: Selection on Z* fields
723935 - Adding the TID display to the DeltaQueue monitor
691721 - Restoring lost data from a delta request
576896 - Checks when PSA contains incorrect data for delta requests
574601 - BW-SAPI: Endless loop when confirming qRFC LUWs
417307 - Extractor package size: Collective note for applications
417189 - BW/SAPLEINS - Online update of delta queue
405943 - Calling an InfoPackage in BW causes short dump
377732 - Collective SAP note SAP BW BCT 2.1C for EBP 2.0 and 3.0
Question 1:
What does the number in the 'Total' column in Transaction RSA7 mean?
Answer:
The 'Total' column displays the number of LUWs that were written in the delta queue and that have not yet been confirmed. The number includes the LUWs of the last delta request (for repeating a delta request) and the LUWs for the next delta request. An LUW only disappears from the RSA7 display when it has been transferred to the BW System and a new delta request has been received from the BW System.
Question 2:
What is an LUW in the delta queue?
Answer:
An LUW from the point of view of the delta queue can be an individual document, a group of documents from a collective run or a whole data packet from an application extractor.
Question 3:
Why does the number in the 'Total' column, in the overview screen of Transaction RSA7, differ from the number of data records that are displayed when you call up the detail view?
Answer:
The number on the overview screen corresponds to the total number of LUWs (see also question 1) that were written to the qRFC queue and that have not yet been confirmed. The detail screen displays the records contained in the LUWs. Both the records belonging to the previous delta request and the records that do not meet the selection conditions of the preceding delta init requests are filtered out. This means that only the records that are ready for the next delta request are displayed on the detail screen. The detail screen of Transaction RSA7 does not take into account a possibly existing customer exit.
Question 4:
Why does Transaction RSA7 still display LUWs on the overview screen after successful delta loading?
Answer:
Only when a new delta has been requested does the source system learn that the previous delta was successfully loaded into the BW System. The LUWs of the previous delta may then be confirmed (and also deleted). In the meantime, the LUWs must be kept for a possible delta request repetition. In particular, the number on the overview screen does not change if the first delta is loaded into the BW System.
Question 5:
Why are selections not taken into account when the delta queue is filled?
Answer:
Filtering according to selections takes place when the system reads from the delta queue. This is necessary for performance reasons.
Question 6:
Why is there a DataSource with '0' records in RSA7 if delta exists and has been loaded successfully?
Answer:
It is most likely that this is a DataSource that does not send delta data to the BW System via the delta queue but directly via the extractor . You can display the current delta data for these DataSources using TA RSA3 (update mode ='D')
Question 7:
Do the entries in Table ROIDOCPRMS have an impact on the performance of the loading procedure from the delta queue?
Answer:
The impact is limited. If performance problems are related to the loading process from the delta queue, then refer to the application-specific notes (for example in the CO-PA area, in the logistics cockpit area, and so on).
Caution: As of PlugIn 2000.2 patch 3, the entries in Table ROIDOCPRMS are as effective for the delta queue as for a full update. Note, however, that LUWs are not split during data loading for consistency reasons. This means that when very large LUWs are written to the delta queue, the actual package size may differ considerably from the MAXSIZE and MAXLINES parameters.
Question 8:
Why does it take so long to display the data in the delta queue (for example approximately 2 hours)?
Answer:
With PlugIn 2001.1 the display was changed: you are now able to define the amount of data to be displayed, to restrict it, to selectively choose the number of a data record, to make a distinction between the 'actual' delta data and the data intended for repetition, and so on.
Question 9:
What is the purpose of the function 'Delete Data and Meta Data in a Queue' in RSA7? What exactly is deleted?
Answer:
You should act with extreme caution when you use the delete function in the delta queue. It is comparable to deleting an InitDelta in the BW System and should preferably be executed there. Not only do you delete all data of this DataSource for the affected BW System, but you also lose all the information concerning the delta initialization. Then you can only request new deltas after another delta initialization.
When you delete the data, this confirms the LUWs kept in the qRFC queue for the corresponding target system. Physical deletion only takes place in the qRFC outbound queue if there are no more references to the LUWs.
The delete function is intended for example, for cases where the BW System, from which the delta initialization was originally executed, no longer exists or can no longer be accessed.
Question 10:
Why does it take so long to delete from the delta queue (for example half a day)?
Answer:
Import PlugIn 2000.2 patch 3. With this patch the performance during deletion improves considerably.
Question 11:
Why is the delta queue not updated when you start the V3 update in the logistics cockpit area?
Answer:
It is most likely that a delta initialization had not yet run or that the the delta initialization was not successful. A successful delta initialization (the corresponding request must have QM status 'green' in the BW System) is a prerequisite for the application data to be written to the delta queue.
Question 12:
What is the relationship between RSA7 and the qRFC monitor (Transaction SMQ1)?
Answer:
The qRFC monitor basically displays the same data as RSA7. The internal queue name must be used for selection on the initial screen of the qRFC monitor. This is made up of the prefix 'BW, the client and the short name of the DataSource. For DataSources whose name is shorter than 20 characters, the short name corresponds to the name of the DataSource. For DataSources whose name is longer than 19 characters (for delta-capable DataSources only possible as of PlugIn 2001.1) the short name is assigned in Table ROOSSHORTN.
In the qRFC monitor you cannot distinguish between repeatable and new LUWs. Moreover, the data of a LUW is displayed in an unstructured manner there.
Question 13:
Why is there data in the delta queue although the V3 update has not yet been started?
Answer:
You posted data in the background. This means that the records are updated directly in the delta queue (RSA7). This happens in particular during automatic goods receipt posting (MRRS). There is no duplicate transfer of records to the BW system. See Note 417189.
Question 14:
Why does the 'Repeatable' button on the RSA7 data details screen not only show data loaded into BW during the last delta but also newly-added data, in other words, 'pure' delta records?
Answer:
It was programmed so that the request in repeat mode fetches both actually repeatable (old) data and new data from the source system.
Question 15:
I loaded several delta inits with various selections. For which one
is the delta loaded?
Answer:
For delta, all selections made via delta inits are summed up. This
means a delta for the 'total' of all delta initializations is loaded.
Question 16:
How many selections for delta inits are possible in the system?
Answer:
With simple selections (intervals without complicated join conditions or single values), you can make up to about 100 delta inits. It should not be more.
With complicated selection conditions, it should be only up to 10-20 delta inits.
Reason: With many selection conditions that are joined in a complicated way, too many 'where' lines are generated in the generated ABAP source code which may exceed the memory limit.
Question 17:
I intend to copy the source system, i.e. make a client copy. What will happen with may delta? Should I initialize again after that?
Answer:
Before you copy a source client or source system, make sure that your deltas have been fetched from the delta queue into BW and that no delta is pending. After the client copy, an inconsistency might occur between BW delta tables and the OLTP delta tables as described in Note 405943. After the client copy, Table ROOSPRMSC will probably be empty in the OLTP since this table is client-independent. After the system copy, the table will contain the entries with the old logical system name which are no longer useful for further delta loading from the new logical system. The delta must be initialized in any case since delta depends on both the BW system and the source system. Even if no dump 'MESSAGE_TYPE_X' occurs in BW when editing or creating an InfoPackage, you should expect that the delta has to be initialized after the copy.
Question 18.
Am I permitted to use the functions in Transaction SMQ1 to manually control processes?
Answer:
Use SMQ1 as an instrument for diagnosis and control only. Make changes to BW queues only after informing BW Support or only if this is explicitly requested in a note for Component 'BC-BW' or 'BW-WHM-SAPI'.
Question 19.
Despite the delta request only being started after completion of the collective run (V3 update), it does not contain all documents. Only another delta request loads the missing documents into BW. What is the cause for this "splitting"?
Answer:
The collective run submits the open V2 documents to the task handler for processing. The task handler processes them in one or several parallel update processes in an asynchronous way. For this reason, plan a sufficiently large "safety time window" between the end of the collective run in the source system and the start of the delta request in BW. An alternative solution where this problem does not occur is described in Note 505700.
Question 20.
Despite deleting the delta init, LUWs are still written into the DeltaQueue
Answer:
In general, delta initializations and deletions of delta inits should always be carried out at a time when no posting takes place. Otherwise, buffer problems may occur: If you started the internal mode at a time when the delta initialization was still active, you post data into the queue even though the initialization had been deleted in the meantime. This is the case in your system.
Question 21.
In SMQ1 (qRFC Monitor) I have status 'NOSEND'. In the Table TRFCQOUT, some entries have the status 'READY', others 'RECORDED'. ARFCSSTATE is 'READ'. What do these statuses mean? Which values in the field 'Status' mean what and which values are correct and which are alarming? Are the statuses BW-specific or generally valid in qRFC?
Answer:
Table TRFCQOUT and ARFCSSTATE: Status READ means that the record was read once either in a delta request or in a repetition of the delta request. However, this still does not mean that the record has successfully reached the BW. The status READY in the TRFCQOUT and RECORDED in the ARFCSSTATE means that the record has been written into the delta queue and will be loaded into the BW with the next delta request or a repetition of a delta. In any case only the statuses READ, READY and RECORDED in both tables are considered to be valid. The status EXECUTED in TRFCQOUT can occur temporarily. It is set before starting a delta extraction for all records with status READ present at that time. The records with status EXECUTED are usually deleted from the queue in packages within a delta request directly after setting the status before extracting a new delta. If you see such records, it means that either a process which confirms and deletes records loaded into the BW is successfully running at the moment, or, if the records remain in the table for a longer period of time with status EXECUTED, it is likely that there are problems with deleting the records which have already been successfully been loaded into the BW. In this state, no more deltas are loaded into the BW. Every other status indicates an error or an inconsistency. NOSEND in SMQ1 means nothing (see note 378903). However the value 'U' in field 'NOSEND' of table TRFCQOUT is of concern.
Question 22.
The extract structure was changed when the delta queue was empty. Afterwards new delta records were written to the delta queue. When loading the delta into the PSA, it shows that some fields were moved. The same result occurs when the contents of the delta queue are listed via the detail display. Why is the data displayed differently? What can be done?
Answer:
Make sure that the change of the extract structure is also reflected in the database and that all servers are synchronized. We recommend resetting the buffers using Transaction $SYNC. If the extract structure change is not communicated synchronously to the server where delta records are being created, the records are written with the old structure until the new structure has been generated. This may have disastrous consequences for the delta. When the problem occurs, the delta needs to be re-initialized.
Question 23.
How and where can I control whether a repeat delta is requested?
Answer:
Via the status of the last delta in the BW Request Monitor. If the request is RED, the next load will be of type 'Repeat'. If you need to repeat the last load for any reason, manually set the request in the monitor to red. For the contents of the repeat, see Question 14. Delta requests set to red when data is already updated lead to duplicate records in a subsequent repeat, if they have not already been deleted from the data targets concerned.
Question 24.
As of PI 2003.1, the Logistic Cockpit offers various types of update methods. Which update method is recommended in logistics? According to which criteria should the decision be made? How can I choose an update method in logistics?
Answer:
See the recommendation in Note 505700.
Question 25.
Are there particular recommendations regarding the maximum data volume of the delta queue to avoid danger of a read failure due to memory problems?
Answer:
There is no strict limit (except for the restricted number area of the 24-digit QCOUNT counter in the LUW management table - which is of no practical importance, however - or the restrictions regarding the volume and number of records in a database table).
When estimating "soft" limits, both the number of LUWs and the average data volume per LUW are important. As a rule, we recommend bundling data (usually documents) as soon as you write to the delta queue to keep number of LUWs low (this can partly be set in the applications, for example in the Logistics Cockpit). The data volume of a single LUW should not be much larger than 10% of the memory available to the work process for data extraction (in a 32-bit architecture with a memory volume of about 1 GByte per work process, 100 MByte per LUW should not be exceeded). This limit is of rather small practical importance as well since a comparable limit already applies when writing to the delta queue. If the limit is observed, correct reading is guaranteed in most cases.
If the number of LUWs cannot be reduced by bundling application transactions, you should at least make sure that the data is fetched from all connected BWs as quickly as possible. But for other, BW-specific, reasons, the frequency should not exceed one delta request per hour.
To avoid memory problems, a program-internal limit ensures that no more than 1 million LUWs are ever read and fetched from the database per delta request. If this limit is reached within a request, the delta queue must be emptied by several successive delta requests. We recommend, however, to try not to reach that limit but trigger the fetching of data from the connected BWs as soon as the number of LUWs reaches a 5-digit value.
---> Some more related Notes....
873694 - Consulting: Delta repeat and status in monitor/data target
771894 - No data during delta upload: Selection on Z* fields
723935 - Adding the TID display to the DeltaQueue monitor
691721 - Restoring lost data from a delta request
576896 - Checks when PSA contains incorrect data for delta requests
574601 - BW-SAPI: Endless loop when confirming qRFC LUWs
417307 - Extractor package size: Collective note for applications
417189 - BW/SAPLEINS - Online update of delta queue
405943 - Calling an InfoPackage in BW causes short dump
377732 - Collective SAP note SAP BW BCT 2.1C for EBP 2.0 and 3.0
Note 396647 - FAQ: V3 update: Questions and answers
Question 1
Update records are written to the SM13, although you do not use the extractors from the logistics cockpit (LBWE) at all.
Active datasources have been accidentally delivered in a PI patch.For that reason, extract structures are set to active in the logistics cockpit. Select transaction LBWE and deactivate the active structures. From now on, no additional records are written into SM13.
If the system displays update records for application 05 (QM) in transaction SM13, even though the structure is not active, see note 393306 for a solution.
Question 2
How can I selectively delete update records from SM13?
Start the report RSM13005 for the respective module (z.B. MCEX_UPDATE_03).
MAXFBS : The number of processed records without Commit.
ATTENTION: The delta records are deleted irrevocably after executing report RSM13005 (without flag IN_VB). You can reload the data into BW only with a new delta-initialization!Question 3
What can I do when the V3 update loops?
Refer to Note 0352389. If you need a fast solution, simply delete all entries from SM13 (executed for V2), however, this does not solve the actual problem.
ATTENTION: THIS CAUSES DATA LOSS. See question 2 !Question 4
Why has SM13 not been emptied even though I have started the V3 update?
The entries from SM13 have not been retrieved even though I followed note 0328181!
Check whether all entries were actually deleted from SM13 for all clients. Look for records within the last 25 years with user * .
Question 6
Can I schedule V3 update in parallel?
The V3 update already uses collective processing.You cannot do this in parallel.
Question 7
The Logistics Cockpit extractors deliver incorrect numbers. The update contains errors !
Have you installed the most up-to-date PI in your OLTP system?
You should have at least PI 2000.1 patch 6 or PI 2000.2 patch 2.
Question 8
Why has no data been written into the delta queue even though the V3 update was executed successfully?
You have probably not started a delta initialization. You have to start a delta initialization for each DataSource from the BW system before you can load the delta.Check in RSA7 for an entry with a green status for the required DataSource. Refer also to Note 0380078.
Question 9
Why does the system write data into the delta queue, even though the V3 update has not been started?
You are using the automatic goods receipt posting (transaction MRRS) and start this in the background.In this case the system writes the records for DataSources of application 02 directly into the delta queue (RSA7).This does not cause double data records.This does not result in any inconsistencies.
Question 10
Why am I not able to carry out a structural change in the Logistics Cockpit although SM13 is blank?
Inconsistencies occurred in your system. There are records in update table VBMOD for which there are no entries in table VBHDR. Due to those missing records, there are no entries in SM13. To remove the inconsistencies, follow the instructions in the solution part of Note 67014. Please note that no postings must be made in the system during reorganization in any case!
Question 11
Why is it impossible to plan a V3 job from the Logistics Cockpit?
The job always abends immediately. Due to missing authorizations, the update job cannot be planned. For further information see Note 445620.
Update records are written to the SM13, although you do not use the extractors from the logistics cockpit (LBWE) at all.
Active datasources have been accidentally delivered in a PI patch.For that reason, extract structures are set to active in the logistics cockpit. Select transaction LBWE and deactivate the active structures. From now on, no additional records are written into SM13.
If the system displays update records for application 05 (QM) in transaction SM13, even though the structure is not active, see note 393306 for a solution.
Question 2
How can I selectively delete update records from SM13?
Start the report RSM13005 for the respective module (z.B. MCEX_UPDATE_03).
- Status COL_RUN INIT: without Delete_Flag but with VB_Flag (records are updated).
- Status COL_RUN OK: with Delete_Flag (the records are deleted for all modules with COL_RUN -- OK)
MAXFBS : The number of processed records without Commit.
ATTENTION: The delta records are deleted irrevocably after executing report RSM13005 (without flag IN_VB). You can reload the data into BW only with a new delta-initialization!Question 3
What can I do when the V3 update loops?
Refer to Note 0352389. If you need a fast solution, simply delete all entries from SM13 (executed for V2), however, this does not solve the actual problem.
ATTENTION: THIS CAUSES DATA LOSS. See question 2 !Question 4
Why has SM13 not been emptied even though I have started the V3 update?
- The update record in SM13 contains several modules (for example, MCEX_UPDATE_11 and MCEX_UPDATE_12). If you start the V3 update only for one module, then the other module still has INIT status in SM13 and is waiting for the corresponding collective run. In some cases, the entry might also not be deleted if the V3 update has been started for the second module.In this case, schedule the request RSM13005 with the DELETE_FLAG (see question 2).
- V3 updating no longer functions after the PI upgrade because you did not load all the delta records into the BW system prior to the upgrade.Proceed as described in note 328181.
The entries from SM13 have not been retrieved even though I followed note 0328181!
Check whether all entries were actually deleted from SM13 for all clients. Look for records within the last 25 years with user * .
Question 6
Can I schedule V3 update in parallel?
The V3 update already uses collective processing.You cannot do this in parallel.
Question 7
The Logistics Cockpit extractors deliver incorrect numbers. The update contains errors !
Have you installed the most up-to-date PI in your OLTP system?
You should have at least PI 2000.1 patch 6 or PI 2000.2 patch 2.
Question 8
Why has no data been written into the delta queue even though the V3 update was executed successfully?
You have probably not started a delta initialization. You have to start a delta initialization for each DataSource from the BW system before you can load the delta.Check in RSA7 for an entry with a green status for the required DataSource. Refer also to Note 0380078.
Question 9
Why does the system write data into the delta queue, even though the V3 update has not been started?
You are using the automatic goods receipt posting (transaction MRRS) and start this in the background.In this case the system writes the records for DataSources of application 02 directly into the delta queue (RSA7).This does not cause double data records.This does not result in any inconsistencies.
Question 10
Why am I not able to carry out a structural change in the Logistics Cockpit although SM13 is blank?
Inconsistencies occurred in your system. There are records in update table VBMOD for which there are no entries in table VBHDR. Due to those missing records, there are no entries in SM13. To remove the inconsistencies, follow the instructions in the solution part of Note 67014. Please note that no postings must be made in the system during reorganization in any case!
Question 11
Why is it impossible to plan a V3 job from the Logistics Cockpit?
The job always abends immediately. Due to missing authorizations, the update job cannot be planned. For further information see Note 445620.
Note 1039393 - DATAPUMP creates corruptions in tables with LONG (RAW)
Summary
Symptom***********************************************************************
This note is issued as a Hot News. Check the note regularly for updates. Otherwise, you will not be aware of important changes regarding prerequisites, consequences and solutions. A new Hot News is not issued if a note is updated.
***********************************************************************
After you reorganize a table with a LONG or LONG RAW column using the Oracle Data Pump
LONG RAW
Corruption
Reorganization
R3Check
DBverify
Analyze
Reason and Prerequisites
This problem is caused by Oracle Bug 5941030.
Only tables with LONG RAW or LONG columns are affected.
You installed database version 10.2.0.2.
Solution
The bug is corrected as of Oracle Release 10.2.0.4.
For Oracle Release 10.2.0.2, install the bug fix that is relevant for your platform. The bug fixes are available on SAP Service Marketplace in the software center under:
http://service.sap.com/swcenter-3pmain
in the following directories:
AIX 5L with Oracle 64 bit
/Oracle/Oracle 64-bit/Oracle 10.2.0. 64-bit/Oracle 10.2.0.2/
AIX_5L_64/p5941030_10202_AIX64-5L.zip
Linux 32-bit
/Oracle/Oracle 32-bit/Oracle 10.2.0. 32-bit/Oracle 10.2.0.2/
Linux_32/p5941030_10202_LINUX.zip
Linux x86-64
/Oracle/Oracle 64-Bit/Oracle 10.2.0. 64-bit/Oracle 10.2.0.2/
Linux_x86_64/p5941030_10202_Linux-x86-64.zip
LINUX Itanium 64
/Oracle/Oracle 64-bit/Oracle 10.2.0. 64-bit/Oracle 10.2.0.2/
LINUX_IA_64/p5941030_10202_LINUX-IA64.zip
LINUX IBMPower 64-bit
/Oracle/Oracle 64-bit/Oracle 10.2.0. 64-bit/Oracle 10.2.0.2/
Linux_ppc_64/p5941030_10202_IBMPower.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/p5941030_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/p5941030_10202_HPUX-IA64.zip
HP TRU64
/Oracle/Oracle 64-bit/Oracle 10.2.0. 64-bit/Oracle 10.2.0.2/
HP_TRU64/p5941030_10202_TRU64.zip
SUN Solaris 64-bit
/Oracle/Oracle 64-bit/Oracle 10.2.0. 64-bit/Oracle 10.2.0.2/
Solaris_SPARC_64/p5941030_10202_SOLARIS64.zip
SUN Solaris x86-64
/Oracle/Oracle 64-Bit/Oracle 10.2.0. 64-bit/Oracle 10.2.0.2/
Solaris_x86_64/p5941030_10202_Solaris86-64.zip
Windows 32-bit / 64-bit (Windows IA64 / x86-64)
Patch 4883635 is available for Oracle 10.2.0.2 as of patch 16.
For availability, see Note 871735.
Workaround:
Do not perform table reorganizations for tables with LONG or LONG RAW columns using the Oracle Data Pump.
Do not use the option from BR*Tools.
Use the previous method using exp/imp instead.
This note will be updated as soon as more patches are made available.
This note is issued as a Hot News. Check the note regularly for updates. Otherwise, you will not be aware of important changes regarding prerequisites, consequences and solutions. A new Hot News is not issued if a note is updated.
***********************************************************************
After you reorganize a table with a LONG or LONG RAW column using the Oracle Data Pump
- the dbv reports: "kdbchk: the amount of space used is not equal to block size"
- ora-01498 is reported when the table is accessed
- block corruptions in the relevant table are reported by R3Check (provided that this table is a cluster table)
LONG RAW
Corruption
Reorganization
R3Check
DBverify
Analyze
Reason and Prerequisites
This problem is caused by Oracle Bug 5941030.
Only tables with LONG RAW or LONG columns are affected.
You installed database version 10.2.0.2.
Solution
The bug is corrected as of Oracle Release 10.2.0.4.
For Oracle Release 10.2.0.2, install the bug fix that is relevant for your platform. The bug fixes are available on SAP Service Marketplace in the software center under:
http://service.sap.com/swcenter-3pmain
in the following directories:
AIX 5L with Oracle 64 bit
/Oracle/Oracle 64-bit/Oracle 10.2.0. 64-bit/Oracle 10.2.0.2/
AIX_5L_64/p5941030_10202_AIX64-5L.zip
Linux 32-bit
/Oracle/Oracle 32-bit/Oracle 10.2.0. 32-bit/Oracle 10.2.0.2/
Linux_32/p5941030_10202_LINUX.zip
Linux x86-64
/Oracle/Oracle 64-Bit/Oracle 10.2.0. 64-bit/Oracle 10.2.0.2/
Linux_x86_64/p5941030_10202_Linux-x86-64.zip
LINUX Itanium 64
/Oracle/Oracle 64-bit/Oracle 10.2.0. 64-bit/Oracle 10.2.0.2/
LINUX_IA_64/p5941030_10202_LINUX-IA64.zip
LINUX IBMPower 64-bit
/Oracle/Oracle 64-bit/Oracle 10.2.0. 64-bit/Oracle 10.2.0.2/
Linux_ppc_64/p5941030_10202_IBMPower.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/p5941030_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/p5941030_10202_HPUX-IA64.zip
HP TRU64
/Oracle/Oracle 64-bit/Oracle 10.2.0. 64-bit/Oracle 10.2.0.2/
HP_TRU64/p5941030_10202_TRU64.zip
SUN Solaris 64-bit
/Oracle/Oracle 64-bit/Oracle 10.2.0. 64-bit/Oracle 10.2.0.2/
Solaris_SPARC_64/p5941030_10202_SOLARIS64.zip
SUN Solaris x86-64
/Oracle/Oracle 64-Bit/Oracle 10.2.0. 64-bit/Oracle 10.2.0.2/
Solaris_x86_64/p5941030_10202_Solaris86-64.zip
Windows 32-bit / 64-bit (Windows IA64 / x86-64)
Patch 4883635 is available for Oracle 10.2.0.2 as of patch 16.
For availability, see Note 871735.
Workaround:
Do not perform table reorganizations for tables with LONG or LONG RAW columns using the Oracle Data Pump.
Do not use the option from BR*Tools.
Use the previous method using exp/imp instead.
This note will be updated as soon as more patches are made available.
Header Data
| Release Status: | Released for Customer |
| Released on: | 21.01.2008 15:45:43 |
| Master Language: | German |
| Priority: | HotNews |
| Category: | External error |
| Primary Component: | BC-DB-ORA Oracle |
Note 1520462 - Unauthorized call of operating system command
Summary
SymptomA
malicious user can execute an operating system command with a parameter
string by calling a certain ABAP function because the function does not
perform any authorization checks.
In SAP terminology, these calls are referred to as 'external programs' or 'external commands' (See Note 677435 also.).
Other termsExternal programs, external commands
Reason and PrerequisitesThis is caused by a design error.
A malicious user who is very familiar with SAP source code may recognize this security hole.
SolutionImport the Support Package or implement the correction instructions.
For technical reasons, you cannot extend the start of the validity of the correction instructions to older Support Packages. However, the problem described in this note exists from the outset in all releases.
When you implement these corrections, the authorization check that must be performed for external commands and external programs is now also performed in the aforementioned function.
(For more information about the authorizations that are checked, see Notes 859104 and 854060.)
You will not notice any changes to the system behavior, apart from the following very unlikely exception:
Now, when you start an external program as a step of a background job, the system also checks whether the step user has system administrator authorization. Therefore, it checks the authorization S_RZL_ADM (field ACTVT = 01).
If the step user does not have this authorization, the job terminates with a relevant message in the job log and the external program is not executed.
For security reasons, the new authorization check is imperative.
The new check will probably have no effect for your existing batch jobs because the step user is always the job scheduler by default, and an external program can only be scheduled as a job step if the job scheduler has system administrator authorization.
However, if there are batch jobs in your system with the following properties:
- the job has an external program as the job step
AND
- the step user of this step is not the job scheduler
AND
- this step user has no system administrator authorization
these jobs will terminate after you implement these correction instructions.
To identify these jobs, the program Z_FIND_JOBS_WITH_EXTPROG is attached to this note.
Execute this program. If the program detects jobs with the properties mentioned above, change the step user for these jobs, or assign system administrator authorization to the step user.
After you have implemented the corrections, you can no longer create background jobs with the aforementioned properties.
In SAP terminology, these calls are referred to as 'external programs' or 'external commands' (See Note 677435 also.).
Other termsExternal programs, external commands
Reason and PrerequisitesThis is caused by a design error.
A malicious user who is very familiar with SAP source code may recognize this security hole.
SolutionImport the Support Package or implement the correction instructions.
For technical reasons, you cannot extend the start of the validity of the correction instructions to older Support Packages. However, the problem described in this note exists from the outset in all releases.
When you implement these corrections, the authorization check that must be performed for external commands and external programs is now also performed in the aforementioned function.
(For more information about the authorizations that are checked, see Notes 859104 and 854060.)
You will not notice any changes to the system behavior, apart from the following very unlikely exception:
Now, when you start an external program as a step of a background job, the system also checks whether the step user has system administrator authorization. Therefore, it checks the authorization S_RZL_ADM (field ACTVT = 01).
If the step user does not have this authorization, the job terminates with a relevant message in the job log and the external program is not executed.
For security reasons, the new authorization check is imperative.
The new check will probably have no effect for your existing batch jobs because the step user is always the job scheduler by default, and an external program can only be scheduled as a job step if the job scheduler has system administrator authorization.
However, if there are batch jobs in your system with the following properties:
- the job has an external program as the job step
AND
- the step user of this step is not the job scheduler
AND
- this step user has no system administrator authorization
these jobs will terminate after you implement these correction instructions.
To identify these jobs, the program Z_FIND_JOBS_WITH_EXTPROG is attached to this note.
Execute this program. If the program detects jobs with the properties mentioned above, change the step user for these jobs, or assign system administrator authorization to the step user.
After you have implemented the corrections, you can no longer create background jobs with the aforementioned properties.
Header Data
| Release Status: | Released for Customer |
| Released on: | 08.02.2011 |
| Master Language: | German |
| Priority: | HotNews |
| Category: | Program error |
| Primary Component: | BC-CCM-BTC-EXT External and Logical Commands |
Note 1418122 - Insufficient error handling in inbound processing
Summary
SymptomDuring
the inbound processing of a message, an error occurs. This error is to
be transferred as a SOAP fault message in the response to the caller. If
an error occurs during the setup of the SOAP fault message, the error
is not transferred to the caller.
You have activated the inbound lock of the Integration Server. If a message package is transferred from cross-component business process management (ccBPM) to the Integration Server, this is not processed there, but no error is returned to ccBPM. As a result, ccBPM assumes that the messages have been processed successfully, which means that the messages are lost.
Reason and PrerequisitesThis problem is caused by an error in the source code.
SolutionImplement the correction instructions or import the
Support Package specified below.
You have activated the inbound lock of the Integration Server. If a message package is transferred from cross-component business process management (ccBPM) to the Integration Server, this is not processed there, but no error is returned to ccBPM. As a result, ccBPM assumes that the messages have been processed successfully, which means that the messages are lost.
Reason and PrerequisitesThis problem is caused by an error in the source code.
SolutionImplement the correction instructions or import the
Support Package specified below.
Header Data
| Release Status: | Released for Customer |
| Released on: | 15.01.2010 09:34:59 |
| Master Language: | German |
| Priority: | HotNews |
| Category: | Program error |
| Primary Component: | BC-XI-IS-IEN Integration Engine |
Note 1407285 - Security hole in BEx tools
Summary
SymptomThere
is a security hole in BW 3.5 Frontend for SAP GUI 7.10 and BI 7.0
Frontend for SAP GUI 7.10 that allows operating system functions to be
called. This means that the affected client PC may be controlled
(depending on the rights of the corresponding user account). This error
also allows you to access the affected PC remotely.
Other termsSecurity, BEx tools, BEx Web Application Designer (WAD), Query Designer, BEx Analyzer, Report Designer
Reason and PrerequisitesBW 3.5 Frontend for SAP GUI 7.10 and/or BI 7.0 Frontend for SAP GUI 7.10 is installed on the client PC.
Solution
BW 3.5 Frontend for SAP GUI 7.10 (WDBCBEXC.dll):
BI 7.0 Frontend für SAP GUI 7.10 (BExCommon.dll):
In the precalculation server (3.5 and 7.0 precalculation server), the security hole is closed by installing the above frontend patches.
Other termsSecurity, BEx tools, BEx Web Application Designer (WAD), Query Designer, BEx Analyzer, Report Designer
Reason and PrerequisitesBW 3.5 Frontend for SAP GUI 7.10 and/or BI 7.0 Frontend for SAP GUI 7.10 is installed on the client PC.
Solution
BW 3.5 Frontend for SAP GUI 7.10 (WDBCBEXC.dll):
- The security breach is corrected with the following patch level:
- BW 3.5 Frontend for SAP GUI 7.10: Frontend Patch (FEP) 8
- With patch level 7 of GUI 7.10, the kill bit is set by default, which prevents an instantiation of the ActiveX control critical to security in the browser.
- You can find additional information about how you can set the kill bit for GUI ActiveX controls in Note 1092631. This note also provides scripts for automatically setting the kill bits in the registry of client.
BI 7.0 Frontend für SAP GUI 7.10 (BExCommon.dll):
- The security breach is corrected with the following patch level:
- BI 7.0 Frontend for SAP GUI 7.10: Frontend Patch (FEP) 1100
- Since no COM/ActiveX technology is used in this version, an instantiation of the ActiveX controls critical to security in the browser is no longer possible by default. This correction ensures that the function critical to security within the DLL can no longer be activated and executed externally.
In the precalculation server (3.5 and 7.0 precalculation server), the security hole is closed by installing the above frontend patches.
Header Data
| Release Status: | Released for Customer |
| Released on: | 03.02.2010 |
| Master Language: | German |
| Priority: | HotNews |
| Category: | Program error |
| Primary Component: | BW-BEX-ET Enduser Technology |
Note 1603033 - Performance problem in Program RBDAPP01
Summary
SymptomPerformance Problem in the program RBDAPP01 in BDT objects
Other termsRBDAPP01 , LBUSSF00 , gt_tbz1
Reason and PrerequisitesDuring the inbound processing of idocs through program RBDAPP01 the BDT objects were called to get the business partner relationship details .
When reading the relationship details due to the improper handling of read statement in OBJAP_CHECK routine causes duplicate entries in the internal table resulting in the performance issue.
SolutionImplement the notes to resolve the issue
Other termsRBDAPP01 , LBUSSF00 , gt_tbz1
Reason and PrerequisitesDuring the inbound processing of idocs through program RBDAPP01 the BDT objects were called to get the business partner relationship details .
When reading the relationship details due to the improper handling of read statement in OBJAP_CHECK routine causes duplicate entries in the internal table resulting in the performance issue.
SolutionImplement the notes to resolve the issue
Header Data
| Release Status: | Released for Customer |
| Released on: | 24.06.2011 08:41:14 |
| Master Language: | English |
| Priority: | Correction with high priority |
| Category: | Program error |
| Primary Component: | CA-GTF-BDT Business Data Toolset |
Note 719941 - CALL_FUNCTION_WAIT_ERROR in ALE environment
Summary
SymptomIf
you have scheduled the RBDAPP01 program as background job and have
maintained the relevant variant in an incorrect way, the system may
issue an ABAP CALL_FUNCTION_WAIT_ERROR runtime error.
Other termsRFC, ALE, CALL_FUNCTION_WAIT_ERROR, RBDAPP01
Reason and PrerequisitesThe problem arises if the RBDAPP01 program is terminated before the responses of the sent asynchronous tasks are returned by the RFC server program.
Remark:Note that the CALL_FUNCTION_WAIT_ERROR ABAP runtime error can also occur with other applications if the calling program is terminated before it receives the responses of the sent asynchronous tasks of the RFC server program.
SolutionIf the RBDAPP01 program is scheduled as a background job and you used an asynchronous RFC with a response in the variant to set up a parallel processing, also set the indicator
"Wait for end of processing".
For Example:
Parallel X
Server group idoc_processing
Wait for end of processing X <=====
Voraussetzung:Note that you must first implement the correction from Note 547253.
Other termsRFC, ALE, CALL_FUNCTION_WAIT_ERROR, RBDAPP01
Reason and PrerequisitesThe problem arises if the RBDAPP01 program is terminated before the responses of the sent asynchronous tasks are returned by the RFC server program.
Remark:Note that the CALL_FUNCTION_WAIT_ERROR ABAP runtime error can also occur with other applications if the calling program is terminated before it receives the responses of the sent asynchronous tasks of the RFC server program.
SolutionIf the RBDAPP01 program is scheduled as a background job and you used an asynchronous RFC with a response in the variant to set up a parallel processing, also set the indicator
"Wait for end of processing".
For Example:
Parallel X
Server group idoc_processing
Wait for end of processing X <=====
Voraussetzung:Note that you must first implement the correction from Note 547253.
Header Data
| Release Status: | Released for Customer |
| Released on: | 07.03.2006 10:35:13 |
| Master Language: | German |
| Priority: | Recommendations/additional info |
| Category: | Consulting |
| Primary Component: | BC-MID-RFC RFC |
| Secondary Components: | BC-MID-ALE Integration Technology ALE |
Note 830576 - Parameter recommendations for Oracle 10g
Summary
SymptomThis note contains SAP's recommendations for the configuration of Oracle Database 10g.
Other terms
init.ora, SPFILE, server parameter file
Reason and PrerequisitesThis note contains SAP's recommendations for the optimal configuration of the Oracle database with Release 10g in SAP environments.
Parameter recommendations for Oracle Release 11.2 can be found in SAP Note 1431798.
For Oracle Release 9i or lower, refer to Note 124361 and the notes referenced there.
Note that the recommendations given in this note may be changed. Therefore, we recommend that you check the latest version of this note once a month and make the necessary changes.
Previously, some parameter settings for the Oracle database (for example, for the cost-based optimizer) depended on whether your system was a normal R/3 system or a BW-based system. As of Oracle 10g, there is a uniform parameterization recommendation for all systems, which is described in this note. A few exceptions to this are indicated explicitly.
General recommendationsYou should delete obsolete initialization parameters from the profile. To determine which obsolete parameters are currently set, proceed as follows:
SELECT NAME FROM V$OBSOLETE_PARAMETER WHERE ISSPECIFIED = 'TRUE';
You should not set any parameters that are not explicitly mentioned in this note. Exceptions:
Parameter changes are implemented as required (see patch day).
Change history:
Notation:
n := Number of the Windows patch collection
Example: WIN 10.2.0.4.nP (n >= 11)
x := unspecified placeholder for UNIX PSU
that correlates with the date variable
date := Date of the SBP
Example: UNIX 10205x_date (date >= 201103)
For information about the automatic check of the parameter, see Note 1171650.
For more information on individual parameters, see Note 1289199.
STANDARD PARAMETER RECOMMENDATIONS FOR ORACLE 10.2.0
************************************************
Other terms
init.ora, SPFILE, server parameter file
Reason and PrerequisitesThis note contains SAP's recommendations for the optimal configuration of the Oracle database with Release 10g in SAP environments.
Parameter recommendations for Oracle Release 11.2 can be found in SAP Note 1431798.
For Oracle Release 9i or lower, refer to Note 124361 and the notes referenced there.
Note that the recommendations given in this note may be changed. Therefore, we recommend that you check the latest version of this note once a month and make the necessary changes.
Previously, some parameter settings for the Oracle database (for example, for the cost-based optimizer) depended on whether your system was a normal R/3 system or a BW-based system. As of Oracle 10g, there is a uniform parameterization recommendation for all systems, which is described in this note. A few exceptions to this are indicated explicitly.
General recommendationsYou should delete obsolete initialization parameters from the profile. To determine which obsolete parameters are currently set, proceed as follows:
SELECT NAME FROM V$OBSOLETE_PARAMETER WHERE ISSPECIFIED = 'TRUE';
You should not set any parameters that are not explicitly mentioned in this note. Exceptions:
- The parameter is recommended as the solution or workaround for a problem in another note.
- The parameter is required for implementing an individual configuration (for example, multiple archiver destinations, check functions, special memory settings).
- For detailed information about the maintenance of parameters with SFILEs, see Note 601157.
- If several EVENT parameters are specified in init.ora, they must appear in consecutive rows. You must avoid entering several events separated by ":" in one row.
- You
should not set parameters that are indicated with "Do not set!" and
parameters that are not mentioned at all in the note (and for which
there is no individual customer requirements). In this case, you use the
Oracle default value, which then also appears in V$PARAMETER or in the
ST04 parameter overview. This is the intended behavior. If you want to
ensure that a parameter has not been explicitly set, you can enter the
following query ( in lower case):
SELECT ISDEFAULT FROM V$PARAMETER2
WHERE NAME = '';
- You can only optimize memory parameters and resource parameters such as DB_CACHE_SIZE or DB_WRITER_PROCESSES individually. Therefore, this note cannot give any general recommendations. However, you can determine options for optimization on the basis of a database performance analysis (see Notes 618868, 619188, 789011).
- The parameterization described below is directed towards the use of the features of the dynamic SGA (Note 617416) and the automatic PGA administration (Note 619876).
- refers to the value of the environment variable SAPDATA_HOME.
- Paths are given in UNIX syntax. On WINDOWS, you must replace the forward slashes ("/") with back slashes ("\").
- The terms OLAP system and OLTP system have the following meaning:
- OLAP system: These are systems with mainly BW functions (BW / BI, APO with mainly DP usage, SEM-BPS, BW-based SEM-BCS).
- OLTP system: Systems with mainly non-BW functions (this also includes, for example, Bank Analyzer systems)
- Configure systems with a pure Java stack as you would an OLTP system.
- Configure double stack systems (that is, systems with both ABAP and JAVA stacks) as you would an OLTP or OLAP system, depending on degree to which you use BW functions (see above).
- In a few exceptional cases, if you have a system without OLAP, you can refrain from setting OLAP specific parameters such as STAR_TRANSFORMATION_ENABLED, _FIX_CONTROL or _INDEX_JOIN_ENABLED to avoid problems (for example, ORA-04031 due to _FIX_CONTROL, Note 997889) or to use functions (for example, index joins). Note that such scenarios are only relevant in very rare situations. Therefore, you do not usually have to deviate from the standard recommendations.
- If you set parameters depending on a bugfix implementation, the relevant bugfix is specified. The notes referenced contain dependent fixes such as WINDOWS patches or merge fixes.
Parameter changes are implemented as required (see patch day).
Change history:
- 10.11.2011 / 18.11.2011
- Updated recommendation for parameter REMOTE_OS_AUTHENT (Note 1622837)
- 13.09.2011: _DISABLE_OBJSTAT_DEL_BROADCAST = FALSE
- is added for UNIX and Windows with 10.2.0.5.
- 10.08.2011: Note inserted:
- "If 10.2.0.4 or 10.2.0.5 are not mentioned explicitly,
- the parameter recommendation applies to both Oracle versions. Since 10.2.0.2
- is no longer supported, the parameter recommendations for
- 10.2.0.2 are no longer maintained either."
- 12.05.2011:
- _fix_control 6055658:OFF is added for 10.2.0.4 and 10.2.0.5
- _fix_control 4728348:OFF is adjusted for 10.2.0.5
- 12.04.2011:
- _fix_control 4728348:OFF is adjusted for 10.2.0.4
- Restriction to OLTP for _B_TREE_BITMAP_PLANS is removed.
- 11.03.2011:
- Parameter recommendations for Windows based on the Windows patch
Notation:
n := Number of the Windows patch collection
Example: WIN 10.2.0.4.nP (n >= 11)
x := unspecified placeholder for UNIX PSU
that correlates with the date variable
date := Date of the SBP
Example: UNIX 10205x_date (date >= 201103)
- 11.02.2011:
- 10.2.0.5: EVENT 10753 removed
- 11.01.2011:
- 10.2.0.4, 10.2.0.5: _FIX_CONTROL 4728348:OFF, Note 1547676
- 10.2.0.5: EVENT 10753 (Level 2)
- 22.11.2010:
- Parameter recommendations for 10.2.0.5 in general and for
- SBP 10205X_DATE (DATE >=201011) maintained
- 10.10.2010:
- _OPTIMIZER_BETTER_INLIST_COSTING removed
- 10.09.2010: No Changes
- 10.08.2010:
- 10.2.0.4 with Fix 8575528: _CURSOR_FEATURES_ENABLED = 10
- 10.07.2010:
- 10.2.0.4: _FIX_CONTROL 9196440
- 10.06.2010:
- 10.2.0.4: Adjustments _FIRST_SPARE_PARAMETER, _SECOND_SPARE_PARAMETER
- 10.05.2010:
- 10.2.0.4, OLTP: _B_TREE_BITMAP_PLANS = FALSE
- 10.2.0.4 with Fix 9495669: _FIX_CONTROL '9495669:ON'
- 10.04.2010: No Changes
- 10.03.2010: No Changes
- 10.02.2010: No Changes
- 10.01.2010: Do not set NLS_LENGTH_SEMANTICS.
- 10.12.2009: No Changes
- 10.11.2009: No Changes
- 10.10.2009:
- 10.2.0.4: EVENT 10891 no longer necessary
- 10.09.2009: No Changes
- 10.08.2009: No Changes
- 10.07.2009:
- 10.2.0.4: EVENT 10753 (Level 2)
- 10.06.2009:
- 10.2.0.4 without Fix 8366255: EVENT 10753 (Level 2)
- 10.2.0.4 with Fix 5099019: _FIX_CONTROL '5099019:ON'
- 10.05.2009:
- OLTP: Do not set OPTIMIZER_DYNAMIC_SAMPLING
- 10.2.0.4 with Fix 7891471: _FIX_CONTROL '7891471:ON'
- 10.04.2009:
- 10.2.0.x with Fix 6399597: _FIX_CONTROL '6399597:ON'
- 10.2.0.4 with Fix 6795880: _CURSOR_FEATURES_ENABLED = 10
- 10.03.2009:
- 10.2.0.4: _OPTIMIZER_BETTER_INLIST_COSTING = OFF
- 10.2.0.4 with Fix 7692248: _FIX_CONTROL '7692248:ON'
- 10.02.2009:
- 10.2.0.2: _FIX_CONTROL '6120483:OFF' adjusted
- 10.2.0.4: set _FIRST_SPARE_PARAMETER if required
- 10.01.2009:
- 10.2.0.2: _IN_MEMORY_UNDO generally set to FALSE
- 10.2.0.2 with fixes: _FIX_CONTROL '6430500:ON' and '7325597:ON'
- 10.2.0.4: _FIX_CONTROL '6670551:ON'
- 10.12.2008:
- 10.2.0.2: EVENT 44951 (Level 1024)
- 10.2.0.4: Event 10142 (Level 1)
- 10.2.0.4: _FIX_CONTROL 5765456 from Level 7 to Level 3
- 14.11.2008: _FIX_CONTROL changes for 10.2.0.4
- 10.11.2008: OPTIMIZER_INDEX_CACHING Do not generally set
- 10.10.2008: No Changes
- 23.09.2008: EVENT 10049 (LEVEL 2)
- 17.09.2008: "_FIX_CONTROL"='6329318:OFF'
- 25.08.2008: EVENT 10091 (LEVEL 1)
- 14.08.2008: "_FIX_CONTROL"='6120483:OFF'
- 17.07.2008: Parameterization for Oracle 10.2.0.4 is integrated.
- 27.06.2008: HPUX_SCHED_NOAGE = 178, _DB_BLOCK_NUMA = 1, _ENABLE_NUMA_OPTIMIZATION = FALSE
- 21.05.2008: "_FIX_CONTROL"='6626018:ON', "_FIX_CONTROL"='6660162:ON', "_FIX_CONTROL"='6440977:ON'
- 18.04.2008: LOG_ARCHIVE_DEST replaced with LOG_ARCHIVE_DEST_1
- 28.11.2007: _BLOOM_FILTER_ENABLED = FALSE
- 08.11.2007: EVENT 10891 (LEVEL 1)
- 01.11.2007: _TABLE_LOOKUP_PREFETCH_SIZE = 0
- 08.10.2007: EVENT 38087 (LEVEL 1)
- 11.09.2007: "_FIX_CONTROL"='5705630:ON'
For information about the automatic check of the parameter, see Note 1171650.
For more information on individual parameters, see Note 1289199.
STANDARD PARAMETER RECOMMENDATIONS FOR ORACLE 10.2.0
************************************************
| Parameter | Recommendation |
|---|---|
| ------------------------------- | ------------------------------------ |
| BACKGROUND_DUMP_DEST | /saptrace/background |
| COMMIT_WRITE | Do not set |
| COMPATIBLE | 10.2.0 |
| CONTROL_FILES | At least three copies on |
| different disk areas | |
| CONTROL_FILE_RECORD_KEEP_TIME | 30 or higher |
| CORE_DUMP_DEST | /saptrace/background |
| DB_BLOCK_SIZE | 8192 |
| DB_CACHE_SIZE | Size depends on the available |
| memory (Notes 789011, 617416) | |
| DB_FILES | Larger than the number of data files |
| to be expected in the short term | |
| DB_FILE_MULTIBLOCK_READ_COUNT | Do not set |
| DB_NAME | |
| DB_WRITER_PROCESSES | Only set in case of increased |
| DBWR load (Notes 79341, 793113) | |
| EVENT | |
| "10027 trace name context forever, level 1" (Note 596420) | |
| "10028 trace name context forever, level 1" (Note 596420) | |
| "10049 trace name context forever, level 2" (Note 1253845) | |
| WIN 10.2.0.4.nP (5 <= n <= 9) | |
| "10091 trace name context forever, level 1" (Note 1227227, | |
| 10.2.0.2 or 10.2.0.4 without fix 7188932) | |
| UNIX 10.2.0.4 without SBP and without fix 7188932 | |
| WIN 10.2.0.4.nP (n <= 6 and WIN 32bit) | |
| 10.2.0.4.nP (n <= 8 and WIN 64bit) | |
| "10142 trace name context forever, level 1" (Note 1284478) | |
| "10162 trace name context forever, level 1" (Notes 977319, | |
| 1040300, 10.2.0.2) | |
| "10183 trace name context forever, level 1" (Note 128648) | |
| "10191 trace name context forever, level 1" (Note 128221) | |
| "10411 trace name context forever, level 1" (is required to activate | |
| fix 6768114, Note 1137346, 10.2.0.4 or higher) | |
| UNIX 10.2.0.4 and 10.2.0.5 | |
| WIN 10.2.0.4.nP (n >= 2) | |
| 10.2.0.5.nP (n >= 3) | |
| "10629 trace name context forever, level 32" (Note 869521, | |
| other settings of event 10626 or 10629 also allowed) | |
| "10753 trace name context forever, level 2" (Note 1351737, | |
| 10.2.0.4) | |
| UNIX 10.2.0.4 | |
| WIN 10.2.0.4 | |
| "10891 trace name context forever, level 1" (Note 1037651, | |
| 10.2.0.2) | |
| "14532 trace name context forever, level 1" (Note 1031682, | |
| 10.2.0.2 with fix 5618049 or 10.2.0.4 or higher) | |
| "38068 trace name context forever, level 100" (Note 176754) | |
| "38085 trace name context forever, level 1" (Note 176754, | |
| >= 10.2.0.4) | |
| "38087 trace name context forever, level 1" (Note 948197, | |
| 10.2.0.2 with fix 5842686 or 10.2.0.4 or higher) | |
| "44951 trace name context forever, level 1024" (Note 1166242, | |
| 10.2.0.2 with fix 6376915 or 10.2.0.4 or higher) | |
| FILESYSTEMIO_OPTIONS | SETALL (Note the restrictions from |
| Note 999524) | |
| HPUX_SCHED_NOAGE | 178 (HP-UX only, without RAC) |
| LOG_ARCHIVE_DEST | Do not set! |
| LOG_ARCHIVE_DEST_1 | |
| "LOCATION=/oraarch/arch" | |
| LOG_ARCHIVE_FORMAT | %t_%s_%r.dbf |
| LOG_BUFFER | 1048576 (Actual value may |
| be different, see Note 1289199) | |
| LOG_CHECKPOINTS_TO_ALERT | TRUE |
| MAX_DUMP_FILE_SIZE | 20000 |
| NLS_LENGTH_SEMANTICS | Do NOT set |
| OPEN_CURSORS | 800 (up to a maximum of 2000) |
| OPTIMIZER_DYNAMIC_SAMPLING | OLTP: Do not set. |
| OLAP: 6 (>= 10.2.0.4) | |
| OPTIMIZER_FEATURES_ENABLE | Do not set |
| OPTIMIZER_INDEX_CACHING | Do not set! |
| OPTIMIZER_INDEX_COST_ADJ | OLTP: 20 |
| OLAP: Do not set. | |
| OPTIMIZER_MODE | Do not set |
| PARALLEL_EXECUTION_MESSAGE_SIZE | 16384 |
| PARALLEL_MAX_SERVERS | #DB-CPU-Cores * 10 |
| PARALLEL_THREADS_PER_CPU | 1 |
| PGA_AGGREGATE_TARGET | OLTP: 20 % of available memory |
| OLAP: 40 % of available memory | |
| PROCESSES | #ABAP work processes * 2 + |
| #J2EE server processes * | |
| + | |
| PARALLEL_MAX_SERVERS + 40 | |
| QUERY_REWRITE_ENABLED | FALSE |
| RECYCLEBIN | OFF |
| REMOTE_OS_AUTHENT | TRUE (optional; no longer recommended, |
| but still SAP Inst. Default) | |
| Do not set (=FALSE) for | |
| -SAP installations with SSFS for ABAP | |
| (see Note 1622837), or | |
| -SAP installations without ABAP stack, | |
| or | |
| -homogeneous SAP installations on | |
| Windows | |
| REPLICATION_DEPENDENCY_TRACKING | FALSE (if no replication |
| is used) | |
| SESSIONS | 2 * PROCESSES |
| SHARED_POOL_SIZE | 400 MB or greater, refer to Note 690241 |
| STAR_TRANSFORMATION_ENABLED | TRUE |
| UNDO_MANAGEMENT | AUTO (Note 600141) |
| UNDO_RETENTION | set if required (refer to Note 600141) |
| UNDO_TABLESPACE | PSAPUNDO (Note 600141) |
| USER_DUMP_DEST | /saptrace/usertrace |
| _B_TREE_BITMAP_PLANS | FALSE (10.2.0.2) |
| FALSE (10.2.0.4, without fix 9770451, | |
| Note 1461804) | |
| UNIX SBP 10204x_date (date <= 201009) | |
| UNIX 10.2.0.5 without SBP | |
| WIN 10.2.0.4.nP (n <= 39) | |
| 10.2.0.5.nP (n <= 2) | |
| _BLOOM_FILTER_ENABLED | FALSE (10.2.0.2, Note 1119194) |
| _CURSOR_FEATURES_ENABLED | 10 (10.2.0.4 with Fix 8575528 |
| Note 1273790) | |
| UNIX SBP 10204x_date (date >= 201005) | |
| WIN 10.2.0.4.nP (n >= 27) | |
| _DB_BLOCK_NUMA | 1 (HP-UX only, see Note 1225732) |
| _DISABLE_OBJSTAT_DEL_BROADCAST | FALSE |
| UNIX 10.2.0.5 | |
| WIN 10.2.0.5 | |
| _ENABLE_NUMA_OPTIMIZATION | FALSE (HP-UX only, see Note 1225732) |
| _FIRST_SPARE_PARAMETER | 1 (WINDOWS: 10.2.0.4 or higher, w/ fix |
| 6904068 from Note 1273790; | |
| UNIX: 10.2.0.4, w/ fix | |
| 6904068 from Note 1273790 and | |
| without fix 7291739 from Note 1475173 | |
| UNIX: 10.2.0.5, Note 1527468) | |
| UNIX SBP 10205x_date (date >= 201011) | |
| WIN 10.2.0.4.nP (n >= 13) | |
| WIN 10.2.0.5.nP (n >= 3) | |
| _FIX_CONTROL | |
| '4728348:OFF' (10.2.0.2 without fix 5397482 from Note 981875, | |
| refer to Notes 964858 and 997889) | |
| (10.2.0.4, Note 1547676 | |
| 10.2.0.5, Note 1547676) | |
| UNIX SBP 10204x_date (date <= 201103) | |
| UNIX SBP 10205x_date ( date = 201105 or earlier) | |
| WIN 10.2.0.4 | |
| WIN 10.2.0.5.nP (n <= 5) | |
| '5099019:ON' (10.2.0.4 with fix 5099019 from Note 1165319 | |
| and 10.2.0.5) | |
| UNIX SBP 10204x_date (date >= 201005) | |
| UNIX 10.2.0.5 | |
| WIN 10.2.0.4.nP (n >= 16) | |
| WIN 10.2.0.5 | |
| '5705630:ON' (10.2.0.2 with fix 5705630 from Note 981875 | |
| or 10.2.0.4 or higher) | |
| '5765456:3' (>= 10.2.0.4) | |
| '6055658:OFF' (10.2.0.4 with fix 6055658 from Note 1165319, | |
| 10.2.0.5 with fix 6055658 from Note 1525673) | |
| UNIX SBP 10204x_date (date >= 201105) | |
| UNIX SBP 10205x_date (date >= 201105) | |
| '6120483:OFF' (10.2.0.4 or lower with fix 6120483 and without fix 7325597 from | |
| Note 981875 (10.2.0.2) or Note 1165319 (10.2.0.4)) | |
| UNIX 10.2.0.4 | |
| WIN 10.2.0.4.nP (1 <= n <= 10) | |
| '6221403:ON' (10.2.0.4, Note 1165319) | |
| UNIX 10.2.0.4 | |
| WIN 10.2.0.4.nP (n >= 6 and WIN 32bit) | |
| WIN 10.2.0.4.nP (n >= 8 and WIN 64bit) | |
| '6329318:OFF' (10.2.0.4 with fix 6329318 and without fix 7211965 | |
| from Note 1165319) | |
| UNIX 10.2.0.4 without SBP but | |
| with fix 6329318 and without fix 7211965 | |
| WIN 10.2.0.4.nP (6 <= n <= 10 and WIN 32bit) | |
| WIN 10.2.0.4.nP (8 <= n <= 10 and WIN 64bit) | |
| '6329318:ON' (10.2.0.4 with fix 7211965 from Note 1165319) | |
| UNIX SBP 10204x_date (date >= 201005) | |
| WIN 10.2.0.4.nP (n >= 11) | |
| '6399597:ON' (10.2.0.2 with fix 6399597 from Note 981875, | |
| 10.2.0.4 with fix 6399597 from Note 1165319, | |
| 10.2.0.5) | |
| UNIX SBP 10204x_date (date >= 201005) | |
| UNIX 10.2.0.5 | |
| WIN 10.2.0.4.nP (n >= 8) | |
| WIN 10.2.0.5 | |
| '6430500:ON' (10.2.0.2 with fix 6430500 from Note 981875, | |
| 10.2.0.4 with fix 6430500 from Note 1165319) | |
| UNIX SBP 10204x_date (date >= 201005) | |
| UNIX SBP 10205x_date (date >= 201011) | |
| WIN 10.2.0.4.nP (n >= 11) | |
| WIN 10.2.0.5 | |
| '6440977:ON' (10.2.0.2 with fix 6440977 from Note 981875 | |
| or 10.2.0.4 or higher) | |
| UNIX 10.2.0.4 and 10.2.0.5 | |
| WIN 10.2.0.4.nP (n >= 6 and WIN 32bit) | |
| WIN 10.2.0.4.nP (n >= 8 and WIN 64bit) | |
| WIN 10.2.0.5 | |
| '6626018:ON' (10.2.0.2 with fix 6626018 from Note 981875 | |
| or 10.2.0.4 or higher) | |
| UNIX 10.2.0.4 and 10.2.0.5 | |
| WIN 10.2.0.4.nP (n >= 1 and WIN 32bit) | |
| WIN 10.2.0.4.nP (n >= 5 and WIN 64bit) | |
| WIN 10.2.0.5 | |
| '6660162:ON' (10.2.0.2 on UNIX with fix 6660162 from Note 981875) | |
| '6670551:ON' (10.2.0.4 with fix 6670551 from Note 1165319 | |
| 10.2.0.5) | |
| UNIX SBP 10204x_date (date >= 201005) | |
| UNIX 10.2.0.5 | |
| WIN 10.2.0.4.nP (n >= 1 and WIN 32bit) | |
| WIN 10.2.0.4.nP (n >= 5 and WIN 64bit) | |
| WIN 10.2.0.5 | |
| '6972291:ON' (10.2.0.4 or higher, Note 1165319) | |
| UNIX 10.2.0.4 and 10.2.0.5 | |
| WIN 10.2.0.4.nP (n >= 6 and WIN 32bit) | |
| WIN 10.2.0.4.nP (n >= 8 and WIN 64bit) | |
| WIN 10.2.0.5 | |
| '7325597:ON' (10.2.0.2 with fix 7325597 from Note 981875, | |
| 10.2.0.4 with fix 7325597 from Note 1165319) | |
| UNIX SBP 10204x_date (date >= 201005) | |
| WIN 10.2.0.4.nP (n >= 11) | |
| '7692248:ON' (10.2.0.4 with fix 7692248 from Note 1165319 | |
| 10.2.0.5) | |
| UNIX SBP 10204x_date (date >= 201005) | |
| UNIX 10.2.0.5 | |
| WIN 10.2.0.4.nP (n >= 20) | |
| WIN 10.2.0.5 | |
| '7891471:ON' (10.2.0.4 with fix 7891471 from Note 1165319 | |
| 10.2.0.5) | |
| UNIX SBP 10204x_date (date >= 201005) | |
| UNIX 10.2.0.5 | |
| WIN 10.2.0.4.nP (n >= 23) | |
| WIN 10.2.0.5 | |
| '9196440:ON' (10.2.0.4 with fix 9196440 from Note 1165319 | |
| SBP 10205X_DATE (DATE >=201011)) | |
| UNIX SBP 10204x_date (date >= 201007) | |
| UNIX SBP 10205x_date (date >= 201011) | |
| WIN 10.2.0.4.nP (n >= 38) | |
| WIN 10.2.0.5.nP (n >= 2) | |
| '9495669:ON' (10.2.0.4 with fix 9495669 from Note 1165319 | |
| SBP 10205X_DATE (DATE >=201011)) | |
| UNIX SBP 10204x_date (date >= 201005) | |
| UNIX SBP 10205x_date (date >= 201011) | |
| WIN 10.2.0.4.nP (n >= 37) | |
| WIN 10.2.0.5.nP (n >= 2) | |
| _INDEX_JOIN_ENABLED | FALSE (10.2.0.2, refer to Notes |
| 964858 and 1165319) | |
| _IN_MEMORY_UNDO | FALSE (10.2.0.2) |
| _OPTIM_PEEK_USER_BINDS | FALSE (see Note 755342) |
| _OPTIMIZER_MJC_ENABLED | FALSE (Note 176754 (30)) |
| _PUSH_JOIN_UNION_VIEW | FALSE (10.2.0.4, without fix 7155655 |
| from Note 1248584) | |
| UNIX 10.2.0.4 without SBP and | |
| without fix 7155655 | |
| WIN 10.2.0.4.nP (n <= 10) | |
| _SECOND_SPARE_PARAMETER | 1 (UNIX, 10.2.0.4 with fix 6904068 |
| from Note 1273790 and with fix | |
| 7291739 from Note 1475173) | |
| UNIX SBP 10204x_date (date >= 201005) | |
| _SORT_ELIMINATION_COST_RATIO | 10 (see Note 176754 (16)) |
| _TABLE_LOOKUP_PREFETCH_SIZE | 0 (10.2.0.2, refer to Notes |
| 1109753 and 1165319) | |
Header Data
| Release Status: | Released for Customer |
| Released on: | 13.12.2011 12:24:39 |
| Master Language: | German |
| Priority: | Recommendations/additional info |
| Category: | Installation information |
| Primary Component: | BC-DB-ORA Oracle |
Note 562388 - Runtime error "START_CALL_SICK"
Summary
SymptomThe
following error appears in the syslog after you import one of the
following kernels on Solaris machines with the operating system release
5.5.1:
"START_CALL_SICK" runtime error
Transaction termination SY 002 (inconsistency with the database:
Start transaction SICK.
The specified transaction returns the message: OS release SunOS 5.5.1 Generic_103640-29 sun4u is not supported with this kernel (45B)
Other termsSICK Solaris 5.5.1 START_CALL_SICK
Reason and PrerequisitesThe validity for this release was removed from the kernel information. The message appears after you import the following patch level:
3.1I patch level 681
4.0B patch level 946
4.5B patch level 832
Since September 22, 2002, SUN only provides limited support for this operating system release. New OS patches are no longer created.
SolutionThe message is supposed to remind you that your operating system release is no longer current. R/3 functions are not affected in any way.
Update your operating system to a release supported by SUN.
"START_CALL_SICK" runtime error
Transaction termination SY 002 (inconsistency with the database:
Start transaction SICK.
The specified transaction returns the message: OS release SunOS 5.5.1 Generic_103640-29 sun4u is not supported with this kernel (45B)
Other termsSICK Solaris 5.5.1 START_CALL_SICK
Reason and PrerequisitesThe validity for this release was removed from the kernel information. The message appears after you import the following patch level:
3.1I patch level 681
4.0B patch level 946
4.5B patch level 832
Since September 22, 2002, SUN only provides limited support for this operating system release. New OS patches are no longer created.
SolutionThe message is supposed to remind you that your operating system release is no longer current. R/3 functions are not affected in any way.
Update your operating system to a release supported by SUN.
Header Data
| Release Status: | Released for Customer |
| Released on: | 07.01.2003 10:30:54 |
| Master Language: | German |
| Priority: | Correction with medium priority |
| Category: | Program error |
| Primary Component: | BC-OP-SUN SUN Solaris |
Note 436685 - Blank screen when you first logon after system restart
Summary
SymptomWhen
you first logon after restarting an SAP System, the a blank screen
without menus is displayed instead of the usual logon screen (only icons
for "Enter", "Create a new session", "Generate a shortcut on the
desktop", "Customizing of local layout" are shown).
When you logon again, the normal logon screen appears.
Additional key wordsBEAD
Cause and prerequisitesThe internal consistency checks have detected an error in the system configuration. Until now, an error screen with an OK code message of the type "Inconsistency with database: start transaction SICK" was generated during the first login. This no longer happens (the reasons have not yet been clarified). Instead a blank screen appears.
Under ST22 (display ABAP runtime error), a corresponding short dump START_CALL_SICK should be listed.
SolutionAfter logon, execute transaction SICK to determine the cause of the inconsistency. SICK should also provide information on how to remedy the error.
Productive operation can only be resumed when the inconsistency has been eliminated.
In relation to this, please note the following:
Due to an error in SQL 2000 relating to NULL values, customers (with SQL 2000 or SQL 2000 SP1) should switch as soon as possible to SQL 2000 service package 2. Alternatively, if this is not possible, they must import a hotfix (see note 425946). This is now also checked in the consistency check. If SICK issues the following messages
SAP System Check
--------------------------------------------------------------
DB CHECK Invalid MSSQL 2000 release
DB CHECK Please see note 126973
--------------------------------------------------------------
Severe problems were detected during initial system check.
Please, do not use that system before fixing these problems.
, you must procees as described in note 126973 (or 425946).
When you logon again, the normal logon screen appears.
Additional key wordsBEAD
Cause and prerequisitesThe internal consistency checks have detected an error in the system configuration. Until now, an error screen with an OK code message of the type "Inconsistency with database: start transaction SICK" was generated during the first login. This no longer happens (the reasons have not yet been clarified). Instead a blank screen appears.
Under ST22 (display ABAP runtime error), a corresponding short dump START_CALL_SICK should be listed.
SolutionAfter logon, execute transaction SICK to determine the cause of the inconsistency. SICK should also provide information on how to remedy the error.
Productive operation can only be resumed when the inconsistency has been eliminated.
In relation to this, please note the following:
Due to an error in SQL 2000 relating to NULL values, customers (with SQL 2000 or SQL 2000 SP1) should switch as soon as possible to SQL 2000 service package 2. Alternatively, if this is not possible, they must import a hotfix (see note 425946). This is now also checked in the consistency check. If SICK issues the following messages
SAP System Check
--------------------------------------------------------------
DB CHECK Invalid MSSQL 2000 release
DB CHECK Please see note 126973
--------------------------------------------------------------
Severe problems were detected during initial system check.
Please, do not use that system before fixing these problems.
, you must procees as described in note 126973 (or 425946).
Header Data
| Release Status: | Released for Customer |
| Released on: | 19.09.2001 22:00:00 |
| Master Language: | German |
| Priority: | Recommendations/additional info |
| Category: | Program error |
| Primary Component: | BC-DB-MSS Microsoft SQL Server |
Question 1
Update records are written to the SM13, although you do not use the extractors from the logistics cockpit (LBWE) at all.
Active datasources have been accidentally delivered in a PI patch.For that reason, extract structures are set to active in the logistics cockpit. Select transaction LBWE and deactivate the active structures. From now on, no additional records are written into SM13.
If the system displays update records for application 05 (QM) in transaction SM13, even though the structure is not active, see note 393306 for a solution.
Question 2
How can I selectively delete update records from SM13?
Start the report RSM13005 for the respective module (z.B. MCEX_UPDATE_03).
MAXFBS : The number of processed records without Commit.
ATTENTION: The delta records are deleted irrevocably after executing report RSM13005 (without flag IN_VB). You can reload the data into BW only with a new delta-initialization!Question 3
What can I do when the V3 update loops?
Refer to Note 0352389. If you need a fast solution, simply delete all entries from SM13 (executed for V2), however, this does not solve the actual problem.
ATTENTION: THIS CAUSES DATA LOSS. See question 2 !Question 4
Why has SM13 not been emptied even though I have started the V3 update?
The entries from SM13 have not been retrieved even though I followed note 0328181!
Check whether all entries were actually deleted from SM13 for all clients. Look for records within the last 25 years with user * .
Question 6
Can I schedule V3 update in parallel?
The V3 update already uses collective processing.You cannot do this in parallel.
Question 7
The Logistics Cockpit extractors deliver incorrect numbers. The update contains errors !
Have you installed the most up-to-date PI in your OLTP system?
You should have at least PI 2000.1 patch 6 or PI 2000.2 patch 2.
Question 8
Why has no data been written into the delta queue even though the V3 update was executed successfully?
You have probably not started a delta initialization. You have to start a delta initialization for each DataSource from the BW system before you can load the delta.Check in RSA7 for an entry with a green status for the required DataSource. Refer also to Note 0380078.
Question 9
Why does the system write data into the delta queue, even though the V3 update has not been started?
You are using the automatic goods receipt posting (transaction MRRS) and start this in the background.In this case the system writes the records for DataSources of application 02 directly into the delta queue (RSA7).This does not cause double data records.This does not result in any inconsistencies.
Question 10
Why am I not able to carry out a structural change in the Logistics Cockpit although SM13 is blank?
Inconsistencies occurred in your system. There are records in update table VBMOD for which there are no entries in table VBHDR. Due to those missing records, there are no entries in SM13. To remove the inconsistencies, follow the instructions in the solution part of Note 67014. Please note that no postings must be made in the system during reorganization in any case!
Question 11
Why is it impossible to plan a V3 job from the Logistics Cockpit?
The job always abends immediately. Due to missing authorizations, the update job cannot be planned. For further information see Note 445620.
Update records are written to the SM13, although you do not use the extractors from the logistics cockpit (LBWE) at all.
Active datasources have been accidentally delivered in a PI patch.For that reason, extract structures are set to active in the logistics cockpit. Select transaction LBWE and deactivate the active structures. From now on, no additional records are written into SM13.
If the system displays update records for application 05 (QM) in transaction SM13, even though the structure is not active, see note 393306 for a solution.
Question 2
How can I selectively delete update records from SM13?
Start the report RSM13005 for the respective module (z.B. MCEX_UPDATE_03).
- Status COL_RUN INIT: without Delete_Flag but with VB_Flag (records are updated).
- Status COL_RUN OK: with Delete_Flag (the records are deleted for all modules with COL_RUN -- OK)
MAXFBS : The number of processed records without Commit.
ATTENTION: The delta records are deleted irrevocably after executing report RSM13005 (without flag IN_VB). You can reload the data into BW only with a new delta-initialization!Question 3
What can I do when the V3 update loops?
Refer to Note 0352389. If you need a fast solution, simply delete all entries from SM13 (executed for V2), however, this does not solve the actual problem.
ATTENTION: THIS CAUSES DATA LOSS. See question 2 !Question 4
Why has SM13 not been emptied even though I have started the V3 update?
- The update record in SM13 contains several modules (for example, MCEX_UPDATE_11 and MCEX_UPDATE_12). If you start the V3 update only for one module, then the other module still has INIT status in SM13 and is waiting for the corresponding collective run. In some cases, the entry might also not be deleted if the V3 update has been started for the second module.In this case, schedule the request RSM13005 with the DELETE_FLAG (see question 2).
- V3 updating no longer functions after the PI upgrade because you did not load all the delta records into the BW system prior to the upgrade.Proceed as described in note 328181.
The entries from SM13 have not been retrieved even though I followed note 0328181!
Check whether all entries were actually deleted from SM13 for all clients. Look for records within the last 25 years with user * .
Question 6
Can I schedule V3 update in parallel?
The V3 update already uses collective processing.You cannot do this in parallel.
Question 7
The Logistics Cockpit extractors deliver incorrect numbers. The update contains errors !
Have you installed the most up-to-date PI in your OLTP system?
You should have at least PI 2000.1 patch 6 or PI 2000.2 patch 2.
Question 8
Why has no data been written into the delta queue even though the V3 update was executed successfully?
You have probably not started a delta initialization. You have to start a delta initialization for each DataSource from the BW system before you can load the delta.Check in RSA7 for an entry with a green status for the required DataSource. Refer also to Note 0380078.
Question 9
Why does the system write data into the delta queue, even though the V3 update has not been started?
You are using the automatic goods receipt posting (transaction MRRS) and start this in the background.In this case the system writes the records for DataSources of application 02 directly into the delta queue (RSA7).This does not cause double data records.This does not result in any inconsistencies.
Question 10
Why am I not able to carry out a structural change in the Logistics Cockpit although SM13 is blank?
Inconsistencies occurred in your system. There are records in update table VBMOD for which there are no entries in table VBHDR. Due to those missing records, there are no entries in SM13. To remove the inconsistencies, follow the instructions in the solution part of Note 67014. Please note that no postings must be made in the system during reorganization in any case!
Question 11
Why is it impossible to plan a V3 job from the Logistics Cockpit?
The job always abends immediately. Due to missing authorizations, the update job cannot be planned. For further information see Note 445620.
This note maintained here for my quick reference and for those dont have SAP Notes access :-)
Question 1:
What does the number in the 'Total' column in Transaction RSA7 mean?
Answer:
The 'Total' column displays the number of LUWs that were written in the delta queue and that have not yet been confirmed. The number includes the LUWs of the last delta request (for repeating a delta request) and the LUWs for the next delta request. An LUW only disappears from the RSA7 display when it has been transferred to the BW System and a new delta request has been received from the BW System.
Question 2:
What is an LUW in the delta queue?
Answer:
An LUW from the point of view of the delta queue can be an individual document, a group of documents from a collective run or a whole data packet from an application extractor.
Question 3:
Why does the number in the 'Total' column, in the overview screen of Transaction RSA7, differ from the number of data records that are displayed when you call up the detail view?
Answer:
The number on the overview screen corresponds to the total number of LUWs (see also question 1) that were written to the qRFC queue and that have not yet been confirmed. The detail screen displays the records contained in the LUWs. Both the records belonging to the previous delta request and the records that do not meet the selection conditions of the preceding delta init requests are filtered out. This means that only the records that are ready for the next delta request are displayed on the detail screen. The detail screen of Transaction RSA7 does not take into account a possibly existing customer exit.
Question 4:
Why does Transaction RSA7 still display LUWs on the overview screen after successful delta loading?
Answer:
Only when a new delta has been requested does the source system learn that the previous delta was successfully loaded into the BW System. The LUWs of the previous delta may then be confirmed (and also deleted). In the meantime, the LUWs must be kept for a possible delta request repetition. In particular, the number on the overview screen does not change if the first delta is loaded into the BW System.
Question 5:
Why are selections not taken into account when the delta queue is filled?
Answer:
Filtering according to selections takes place when the system reads from the delta queue. This is necessary for performance reasons.
Question 6:
Why is there a DataSource with '0' records in RSA7 if delta exists and has been loaded successfully?
Answer:
It is most likely that this is a DataSource that does not send delta data to the BW System via the delta queue but directly via the extractor . You can display the current delta data for these DataSources using TA RSA3 (update mode ='D')
Question 7:
Do the entries in Table ROIDOCPRMS have an impact on the performance of the loading procedure from the delta queue?
Answer:
The impact is limited. If performance problems are related to the loading process from the delta queue, then refer to the application-specific notes (for example in the CO-PA area, in the logistics cockpit area, and so on).
Caution: As of PlugIn 2000.2 patch 3, the entries in Table ROIDOCPRMS are as effective for the delta queue as for a full update. Note, however, that LUWs are not split during data loading for consistency reasons. This means that when very large LUWs are written to the delta queue, the actual package size may differ considerably from the MAXSIZE and MAXLINES parameters.
Question 8:
Why does it take so long to display the data in the delta queue (for example approximately 2 hours)?
Answer:
With PlugIn 2001.1 the display was changed: you are now able to define the amount of data to be displayed, to restrict it, to selectively choose the number of a data record, to make a distinction between the 'actual' delta data and the data intended for repetition, and so on.
Question 9:
What is the purpose of the function 'Delete Data and Meta Data in a Queue' in RSA7? What exactly is deleted?
Answer:
You should act with extreme caution when you use the delete function in the delta queue. It is comparable to deleting an InitDelta in the BW System and should preferably be executed there. Not only do you delete all data of this DataSource for the affected BW System, but you also lose all the information concerning the delta initialization. Then you can only request new deltas after another delta initialization.
When you delete the data, this confirms the LUWs kept in the qRFC queue for the corresponding target system. Physical deletion only takes place in the qRFC outbound queue if there are no more references to the LUWs.
The delete function is intended for example, for cases where the BW System, from which the delta initialization was originally executed, no longer exists or can no longer be accessed.
Question 10:
Why does it take so long to delete from the delta queue (for example half a day)?
Answer:
Import PlugIn 2000.2 patch 3. With this patch the performance during deletion improves considerably.
Question 11:
Why is the delta queue not updated when you start the V3 update in the logistics cockpit area?
Answer:
It is most likely that a delta initialization had not yet run or that the the delta initialization was not successful. A successful delta initialization (the corresponding request must have QM status 'green' in the BW System) is a prerequisite for the application data to be written to the delta queue.
Question 12:
What is the relationship between RSA7 and the qRFC monitor (Transaction SMQ1)?
Answer:
The qRFC monitor basically displays the same data as RSA7. The internal queue name must be used for selection on the initial screen of the qRFC monitor. This is made up of the prefix 'BW, the client and the short name of the DataSource. For DataSources whose name is shorter than 20 characters, the short name corresponds to the name of the DataSource. For DataSources whose name is longer than 19 characters (for delta-capable DataSources only possible as of PlugIn 2001.1) the short name is assigned in Table ROOSSHORTN.
In the qRFC monitor you cannot distinguish between repeatable and new LUWs. Moreover, the data of a LUW is displayed in an unstructured manner there.
Question 13:
Why is there data in the delta queue although the V3 update has not yet been started?
Answer:
You posted data in the background. This means that the records are updated directly in the delta queue (RSA7). This happens in particular during automatic goods receipt posting (MRRS). There is no duplicate transfer of records to the BW system. See Note 417189.
Question 14:
Why does the 'Repeatable' button on the RSA7 data details screen not only show data loaded into BW during the last delta but also newly-added data, in other words, 'pure' delta records?
Answer:
It was programmed so that the request in repeat mode fetches both actually repeatable (old) data and new data from the source system.
Question 15:
I loaded several delta inits with various selections. For which one
is the delta loaded?
Answer:
For delta, all selections made via delta inits are summed up. This
means a delta for the 'total' of all delta initializations is loaded.
Question 16:
How many selections for delta inits are possible in the system?
Answer:
With simple selections (intervals without complicated join conditions or single values), you can make up to about 100 delta inits. It should not be more.
With complicated selection conditions, it should be only up to 10-20 delta inits.
Reason: With many selection conditions that are joined in a complicated way, too many 'where' lines are generated in the generated ABAP source code which may exceed the memory limit.
Question 17:
I intend to copy the source system, i.e. make a client copy. What will happen with may delta? Should I initialize again after that?
Answer:
Before you copy a source client or source system, make sure that your deltas have been fetched from the delta queue into BW and that no delta is pending. After the client copy, an inconsistency might occur between BW delta tables and the OLTP delta tables as described in Note 405943. After the client copy, Table ROOSPRMSC will probably be empty in the OLTP since this table is client-independent. After the system copy, the table will contain the entries with the old logical system name which are no longer useful for further delta loading from the new logical system. The delta must be initialized in any case since delta depends on both the BW system and the source system. Even if no dump 'MESSAGE_TYPE_X' occurs in BW when editing or creating an InfoPackage, you should expect that the delta has to be initialized after the copy.
Question 18.
Am I permitted to use the functions in Transaction SMQ1 to manually control processes?
Answer:
Use SMQ1 as an instrument for diagnosis and control only. Make changes to BW queues only after informing BW Support or only if this is explicitly requested in a note for Component 'BC-BW' or 'BW-WHM-SAPI'.
Question 19.
Despite the delta request only being started after completion of the collective run (V3 update), it does not contain all documents. Only another delta request loads the missing documents into BW. What is the cause for this "splitting"?
Answer:
The collective run submits the open V2 documents to the task handler for processing. The task handler processes them in one or several parallel update processes in an asynchronous way. For this reason, plan a sufficiently large "safety time window" between the end of the collective run in the source system and the start of the delta request in BW. An alternative solution where this problem does not occur is described in Note 505700.
Question 20.
Despite deleting the delta init, LUWs are still written into the DeltaQueue
Answer:
In general, delta initializations and deletions of delta inits should always be carried out at a time when no posting takes place. Otherwise, buffer problems may occur: If you started the internal mode at a time when the delta initialization was still active, you post data into the queue even though the initialization had been deleted in the meantime. This is the case in your system.
Question 21.
In SMQ1 (qRFC Monitor) I have status 'NOSEND'. In the Table TRFCQOUT, some entries have the status 'READY', others 'RECORDED'. ARFCSSTATE is 'READ'. What do these statuses mean? Which values in the field 'Status' mean what and which values are correct and which are alarming? Are the statuses BW-specific or generally valid in qRFC?
Answer:
Table TRFCQOUT and ARFCSSTATE: Status READ means that the record was read once either in a delta request or in a repetition of the delta request. However, this still does not mean that the record has successfully reached the BW. The status READY in the TRFCQOUT and RECORDED in the ARFCSSTATE means that the record has been written into the delta queue and will be loaded into the BW with the next delta request or a repetition of a delta. In any case only the statuses READ, READY and RECORDED in both tables are considered to be valid. The status EXECUTED in TRFCQOUT can occur temporarily. It is set before starting a delta extraction for all records with status READ present at that time. The records with status EXECUTED are usually deleted from the queue in packages within a delta request directly after setting the status before extracting a new delta. If you see such records, it means that either a process which confirms and deletes records loaded into the BW is successfully running at the moment, or, if the records remain in the table for a longer period of time with status EXECUTED, it is likely that there are problems with deleting the records which have already been successfully been loaded into the BW. In this state, no more deltas are loaded into the BW. Every other status indicates an error or an inconsistency. NOSEND in SMQ1 means nothing (see note 378903). However the value 'U' in field 'NOSEND' of table TRFCQOUT is of concern.
Question 22.
The extract structure was changed when the delta queue was empty. Afterwards new delta records were written to the delta queue. When loading the delta into the PSA, it shows that some fields were moved. The same result occurs when the contents of the delta queue are listed via the detail display. Why is the data displayed differently? What can be done?
Answer:
Make sure that the change of the extract structure is also reflected in the database and that all servers are synchronized. We recommend resetting the buffers using Transaction $SYNC. If the extract structure change is not communicated synchronously to the server where delta records are being created, the records are written with the old structure until the new structure has been generated. This may have disastrous consequences for the delta. When the problem occurs, the delta needs to be re-initialized.
Question 23.
How and where can I control whether a repeat delta is requested?
Answer:
Via the status of the last delta in the BW Request Monitor. If the request is RED, the next load will be of type 'Repeat'. If you need to repeat the last load for any reason, manually set the request in the monitor to red. For the contents of the repeat, see Question 14. Delta requests set to red when data is already updated lead to duplicate records in a subsequent repeat, if they have not already been deleted from the data targets concerned.
Question 24.
As of PI 2003.1, the Logistic Cockpit offers various types of update methods. Which update method is recommended in logistics? According to which criteria should the decision be made? How can I choose an update method in logistics?
Answer:
See the recommendation in Note 505700.
Question 25.
Are there particular recommendations regarding the maximum data volume of the delta queue to avoid danger of a read failure due to memory problems?
Answer:
There is no strict limit (except for the restricted number area of the 24-digit QCOUNT counter in the LUW management table - which is of no practical importance, however - or the restrictions regarding the volume and number of records in a database table).
When estimating "soft" limits, both the number of LUWs and the average data volume per LUW are important. As a rule, we recommend bundling data (usually documents) as soon as you write to the delta queue to keep number of LUWs low (this can partly be set in the applications, for example in the Logistics Cockpit). The data volume of a single LUW should not be much larger than 10% of the memory available to the work process for data extraction (in a 32-bit architecture with a memory volume of about 1 GByte per work process, 100 MByte per LUW should not be exceeded). This limit is of rather small practical importance as well since a comparable limit already applies when writing to the delta queue. If the limit is observed, correct reading is guaranteed in most cases.
If the number of LUWs cannot be reduced by bundling application transactions, you should at least make sure that the data is fetched from all connected BWs as quickly as possible. But for other, BW-specific, reasons, the frequency should not exceed one delta request per hour.
To avoid memory problems, a program-internal limit ensures that no more than 1 million LUWs are ever read and fetched from the database per delta request. If this limit is reached within a request, the delta queue must be emptied by several successive delta requests. We recommend, however, to try not to reach that limit but trigger the fetching of data from the connected BWs as soon as the number of LUWs reaches a 5-digit value.
---> Some more related Notes....
873694 - Consulting: Delta repeat and status in monitor/data target
771894 - No data during delta upload: Selection on Z* fields
723935 - Adding the TID display to the DeltaQueue monitor
691721 - Restoring lost data from a delta request
576896 - Checks when PSA contains incorrect data for delta requests
574601 - BW-SAPI: Endless loop when confirming qRFC LUWs
417307 - Extractor package size: Collective note for applications
417189 - BW/SAPLEINS - Online update of delta queue
405943 - Calling an InfoPackage in BW causes short dump
377732 - Collective SAP note SAP BW BCT 2.1C for EBP 2.0 and 3.0
Question 1:
What does the number in the 'Total' column in Transaction RSA7 mean?
Answer:
The 'Total' column displays the number of LUWs that were written in the delta queue and that have not yet been confirmed. The number includes the LUWs of the last delta request (for repeating a delta request) and the LUWs for the next delta request. An LUW only disappears from the RSA7 display when it has been transferred to the BW System and a new delta request has been received from the BW System.
Question 2:
What is an LUW in the delta queue?
Answer:
An LUW from the point of view of the delta queue can be an individual document, a group of documents from a collective run or a whole data packet from an application extractor.
Question 3:
Why does the number in the 'Total' column, in the overview screen of Transaction RSA7, differ from the number of data records that are displayed when you call up the detail view?
Answer:
The number on the overview screen corresponds to the total number of LUWs (see also question 1) that were written to the qRFC queue and that have not yet been confirmed. The detail screen displays the records contained in the LUWs. Both the records belonging to the previous delta request and the records that do not meet the selection conditions of the preceding delta init requests are filtered out. This means that only the records that are ready for the next delta request are displayed on the detail screen. The detail screen of Transaction RSA7 does not take into account a possibly existing customer exit.
Question 4:
Why does Transaction RSA7 still display LUWs on the overview screen after successful delta loading?
Answer:
Only when a new delta has been requested does the source system learn that the previous delta was successfully loaded into the BW System. The LUWs of the previous delta may then be confirmed (and also deleted). In the meantime, the LUWs must be kept for a possible delta request repetition. In particular, the number on the overview screen does not change if the first delta is loaded into the BW System.
Question 5:
Why are selections not taken into account when the delta queue is filled?
Answer:
Filtering according to selections takes place when the system reads from the delta queue. This is necessary for performance reasons.
Question 6:
Why is there a DataSource with '0' records in RSA7 if delta exists and has been loaded successfully?
Answer:
It is most likely that this is a DataSource that does not send delta data to the BW System via the delta queue but directly via the extractor . You can display the current delta data for these DataSources using TA RSA3 (update mode ='D')
Question 7:
Do the entries in Table ROIDOCPRMS have an impact on the performance of the loading procedure from the delta queue?
Answer:
The impact is limited. If performance problems are related to the loading process from the delta queue, then refer to the application-specific notes (for example in the CO-PA area, in the logistics cockpit area, and so on).
Caution: As of PlugIn 2000.2 patch 3, the entries in Table ROIDOCPRMS are as effective for the delta queue as for a full update. Note, however, that LUWs are not split during data loading for consistency reasons. This means that when very large LUWs are written to the delta queue, the actual package size may differ considerably from the MAXSIZE and MAXLINES parameters.
Question 8:
Why does it take so long to display the data in the delta queue (for example approximately 2 hours)?
Answer:
With PlugIn 2001.1 the display was changed: you are now able to define the amount of data to be displayed, to restrict it, to selectively choose the number of a data record, to make a distinction between the 'actual' delta data and the data intended for repetition, and so on.
Question 9:
What is the purpose of the function 'Delete Data and Meta Data in a Queue' in RSA7? What exactly is deleted?
Answer:
You should act with extreme caution when you use the delete function in the delta queue. It is comparable to deleting an InitDelta in the BW System and should preferably be executed there. Not only do you delete all data of this DataSource for the affected BW System, but you also lose all the information concerning the delta initialization. Then you can only request new deltas after another delta initialization.
When you delete the data, this confirms the LUWs kept in the qRFC queue for the corresponding target system. Physical deletion only takes place in the qRFC outbound queue if there are no more references to the LUWs.
The delete function is intended for example, for cases where the BW System, from which the delta initialization was originally executed, no longer exists or can no longer be accessed.
Question 10:
Why does it take so long to delete from the delta queue (for example half a day)?
Answer:
Import PlugIn 2000.2 patch 3. With this patch the performance during deletion improves considerably.
Question 11:
Why is the delta queue not updated when you start the V3 update in the logistics cockpit area?
Answer:
It is most likely that a delta initialization had not yet run or that the the delta initialization was not successful. A successful delta initialization (the corresponding request must have QM status 'green' in the BW System) is a prerequisite for the application data to be written to the delta queue.
Question 12:
What is the relationship between RSA7 and the qRFC monitor (Transaction SMQ1)?
Answer:
The qRFC monitor basically displays the same data as RSA7. The internal queue name must be used for selection on the initial screen of the qRFC monitor. This is made up of the prefix 'BW, the client and the short name of the DataSource. For DataSources whose name is shorter than 20 characters, the short name corresponds to the name of the DataSource. For DataSources whose name is longer than 19 characters (for delta-capable DataSources only possible as of PlugIn 2001.1) the short name is assigned in Table ROOSSHORTN.
In the qRFC monitor you cannot distinguish between repeatable and new LUWs. Moreover, the data of a LUW is displayed in an unstructured manner there.
Question 13:
Why is there data in the delta queue although the V3 update has not yet been started?
Answer:
You posted data in the background. This means that the records are updated directly in the delta queue (RSA7). This happens in particular during automatic goods receipt posting (MRRS). There is no duplicate transfer of records to the BW system. See Note 417189.
Question 14:
Why does the 'Repeatable' button on the RSA7 data details screen not only show data loaded into BW during the last delta but also newly-added data, in other words, 'pure' delta records?
Answer:
It was programmed so that the request in repeat mode fetches both actually repeatable (old) data and new data from the source system.
Question 15:
I loaded several delta inits with various selections. For which one
is the delta loaded?
Answer:
For delta, all selections made via delta inits are summed up. This
means a delta for the 'total' of all delta initializations is loaded.
Question 16:
How many selections for delta inits are possible in the system?
Answer:
With simple selections (intervals without complicated join conditions or single values), you can make up to about 100 delta inits. It should not be more.
With complicated selection conditions, it should be only up to 10-20 delta inits.
Reason: With many selection conditions that are joined in a complicated way, too many 'where' lines are generated in the generated ABAP source code which may exceed the memory limit.
Question 17:
I intend to copy the source system, i.e. make a client copy. What will happen with may delta? Should I initialize again after that?
Answer:
Before you copy a source client or source system, make sure that your deltas have been fetched from the delta queue into BW and that no delta is pending. After the client copy, an inconsistency might occur between BW delta tables and the OLTP delta tables as described in Note 405943. After the client copy, Table ROOSPRMSC will probably be empty in the OLTP since this table is client-independent. After the system copy, the table will contain the entries with the old logical system name which are no longer useful for further delta loading from the new logical system. The delta must be initialized in any case since delta depends on both the BW system and the source system. Even if no dump 'MESSAGE_TYPE_X' occurs in BW when editing or creating an InfoPackage, you should expect that the delta has to be initialized after the copy.
Question 18.
Am I permitted to use the functions in Transaction SMQ1 to manually control processes?
Answer:
Use SMQ1 as an instrument for diagnosis and control only. Make changes to BW queues only after informing BW Support or only if this is explicitly requested in a note for Component 'BC-BW' or 'BW-WHM-SAPI'.
Question 19.
Despite the delta request only being started after completion of the collective run (V3 update), it does not contain all documents. Only another delta request loads the missing documents into BW. What is the cause for this "splitting"?
Answer:
The collective run submits the open V2 documents to the task handler for processing. The task handler processes them in one or several parallel update processes in an asynchronous way. For this reason, plan a sufficiently large "safety time window" between the end of the collective run in the source system and the start of the delta request in BW. An alternative solution where this problem does not occur is described in Note 505700.
Question 20.
Despite deleting the delta init, LUWs are still written into the DeltaQueue
Answer:
In general, delta initializations and deletions of delta inits should always be carried out at a time when no posting takes place. Otherwise, buffer problems may occur: If you started the internal mode at a time when the delta initialization was still active, you post data into the queue even though the initialization had been deleted in the meantime. This is the case in your system.
Question 21.
In SMQ1 (qRFC Monitor) I have status 'NOSEND'. In the Table TRFCQOUT, some entries have the status 'READY', others 'RECORDED'. ARFCSSTATE is 'READ'. What do these statuses mean? Which values in the field 'Status' mean what and which values are correct and which are alarming? Are the statuses BW-specific or generally valid in qRFC?
Answer:
Table TRFCQOUT and ARFCSSTATE: Status READ means that the record was read once either in a delta request or in a repetition of the delta request. However, this still does not mean that the record has successfully reached the BW. The status READY in the TRFCQOUT and RECORDED in the ARFCSSTATE means that the record has been written into the delta queue and will be loaded into the BW with the next delta request or a repetition of a delta. In any case only the statuses READ, READY and RECORDED in both tables are considered to be valid. The status EXECUTED in TRFCQOUT can occur temporarily. It is set before starting a delta extraction for all records with status READ present at that time. The records with status EXECUTED are usually deleted from the queue in packages within a delta request directly after setting the status before extracting a new delta. If you see such records, it means that either a process which confirms and deletes records loaded into the BW is successfully running at the moment, or, if the records remain in the table for a longer period of time with status EXECUTED, it is likely that there are problems with deleting the records which have already been successfully been loaded into the BW. In this state, no more deltas are loaded into the BW. Every other status indicates an error or an inconsistency. NOSEND in SMQ1 means nothing (see note 378903). However the value 'U' in field 'NOSEND' of table TRFCQOUT is of concern.
Question 22.
The extract structure was changed when the delta queue was empty. Afterwards new delta records were written to the delta queue. When loading the delta into the PSA, it shows that some fields were moved. The same result occurs when the contents of the delta queue are listed via the detail display. Why is the data displayed differently? What can be done?
Answer:
Make sure that the change of the extract structure is also reflected in the database and that all servers are synchronized. We recommend resetting the buffers using Transaction $SYNC. If the extract structure change is not communicated synchronously to the server where delta records are being created, the records are written with the old structure until the new structure has been generated. This may have disastrous consequences for the delta. When the problem occurs, the delta needs to be re-initialized.
Question 23.
How and where can I control whether a repeat delta is requested?
Answer:
Via the status of the last delta in the BW Request Monitor. If the request is RED, the next load will be of type 'Repeat'. If you need to repeat the last load for any reason, manually set the request in the monitor to red. For the contents of the repeat, see Question 14. Delta requests set to red when data is already updated lead to duplicate records in a subsequent repeat, if they have not already been deleted from the data targets concerned.
Question 24.
As of PI 2003.1, the Logistic Cockpit offers various types of update methods. Which update method is recommended in logistics? According to which criteria should the decision be made? How can I choose an update method in logistics?
Answer:
See the recommendation in Note 505700.
Question 25.
Are there particular recommendations regarding the maximum data volume of the delta queue to avoid danger of a read failure due to memory problems?
Answer:
There is no strict limit (except for the restricted number area of the 24-digit QCOUNT counter in the LUW management table - which is of no practical importance, however - or the restrictions regarding the volume and number of records in a database table).
When estimating "soft" limits, both the number of LUWs and the average data volume per LUW are important. As a rule, we recommend bundling data (usually documents) as soon as you write to the delta queue to keep number of LUWs low (this can partly be set in the applications, for example in the Logistics Cockpit). The data volume of a single LUW should not be much larger than 10% of the memory available to the work process for data extraction (in a 32-bit architecture with a memory volume of about 1 GByte per work process, 100 MByte per LUW should not be exceeded). This limit is of rather small practical importance as well since a comparable limit already applies when writing to the delta queue. If the limit is observed, correct reading is guaranteed in most cases.
If the number of LUWs cannot be reduced by bundling application transactions, you should at least make sure that the data is fetched from all connected BWs as quickly as possible. But for other, BW-specific, reasons, the frequency should not exceed one delta request per hour.
To avoid memory problems, a program-internal limit ensures that no more than 1 million LUWs are ever read and fetched from the database per delta request. If this limit is reached within a request, the delta queue must be emptied by several successive delta requests. We recommend, however, to try not to reach that limit but trigger the fetching of data from the connected BWs as soon as the number of LUWs reaches a 5-digit value.
---> Some more related Notes....
873694 - Consulting: Delta repeat and status in monitor/data target
771894 - No data during delta upload: Selection on Z* fields
723935 - Adding the TID display to the DeltaQueue monitor
691721 - Restoring lost data from a delta request
576896 - Checks when PSA contains incorrect data for delta requests
574601 - BW-SAPI: Endless loop when confirming qRFC LUWs
417307 - Extractor package size: Collective note for applications
417189 - BW/SAPLEINS - Online update of delta queue
405943 - Calling an InfoPackage in BW causes short dump
377732 - Collective SAP note SAP BW BCT 2.1C for EBP 2.0 and 3.0
No comments:
Post a Comment