repair full request(转)_小七_新浪博客-CSDN博客

本文链接：https://blog.csdn.net/weixin_42559081/article/details/109654923

在多个地方看到过关于repair full request的面试问题，之前因为BW全程没学完一直搞不懂是什么。今早再次看到，所以一上午都在SDN上查看相关信息。算是摸了个大概出来。

先上NOTE。（原来SAP OSS NOTE是需要有授权的人才能看得到的，幸好SDN上有人把它贴了出来。）

OSS Note 739863 'Repairing data in BW'

"Symptom Some data is incorrect or missing in the PSA table or in the ODS object (Enterprise Data Warehouse layer). There may be a number of reasons for this problem: Errors in the relevant application, errors in the user exit, errors in the Delta Queue, handling errors in the customers posting procedure (for example, a change in t he extract structure during production operation if the Delta Queue was not yet empty; postings before the Delta Init was completed, and so on), extractor errors, unplanned system terminations in BW and in R/3, and so on.

Solution

Read this note in full BEFORE you start actions that may repair your data in BW. Contact SAP Support for help with troubleshooting before you start to repair data.

BW offers you the option of a full upload in the form of a repair request (as of BW 3.0B).

If you want to use this function, we recommend that you use the ODS object layer.

Note that you should only use this procedure if you have a small number of incorrect or missing records.

Otherwise, we always recommend a reinitialization (possibly after a previous selective deletion, followed by a restriction of the Delta-Init selection to exclude areas that were not changed in the meantime).

1. Repair request: Definition if you flag a request as a repair request with full update as the update mode, it can be updated to all data targets, even if these already contain data from delta initialization runs for this Data Source/source system combination. This means that a repair request can be updated into all ODS objects at any time without a check being performed. The system supports loading by repair request into an ODS object without a check being performed for overlapping data or for the sequence of the requests. This action may therefore result in duplicate data and must thus be prepared very carefully. The repair request (of the "Full Upload" type) can be loaded into the same ODS object in which the 'normal' delta requests run. You will find this request under the "Repair Request" option in the Info Package (Maintenance) menu.

2. Prerequisites for using the "Repair Request" function

2.1. Troubleshooting Before you start the repair action, you should carry out a thorough analysis of the possible cause of the error to make sure that the error cannot recur when you execute the repair action. For example, if a key figure has already been updated incorrectly in the OLTP system, it will not change after a reload into BW. Use transaction RSA3 (Extractor Checker) in the source system for help with troubleshooting. Another possible source of the problem may be your user exit. To ensure that the user exit is correct, first load a user exit with a Probe-Full request into the PSA table and check whether the data is correct. If it is not correct: Search for the error in the exit user. If you do not find it, we recommend that you deactivate the user exit for testing purposes and request a new Full Upload. It If the data arrives correctly, it is highly probable that the error is indeed in the user exit.

We always recommend that you load the data into the PSA table in the first step and check the result there.

2.2. Analyze the effects on the downstream targets Before you start the Repair request into the ODS object, make sure that the incorrect data records are selectively deleted from the ODS object. However, before you decide on selective deletion, you should read the Info Help for the "Selective Deletion" function, which you can access by pressing the extra button on the relevant dialog box. The activation queue and the ChangeLog remain unchanged during the selective deletion of the data from the ODS object, which means that the incorrect data is still in the change log afterwards. After the selective deletion, you therefore must not reconstruct the ODS object if it is reconstructed from the ChangeLog. (Reconstruction is usually from the PSA table but, if the data source is the ODS object itself, the ODS object is reconstructed from its ChangeLog). You MUST read the recommendations and warnings about this (press the "Info" button). You MUST also take into account the fact that the delta for the downstream data targets is created from the changelog. If you perform selective deletion and then reload data into the deleted area, this may result in data inconsistencies in the downstream data targets. If you only use MOVE and do not use ADD for updates in the ODS object, selective deletion may not be required in some cases (for example, if incorrect records only have to be changed, rather than deleted). In this case, the DataMart delta also remains intact.

2.3. Analysis of the selections You must be very precise when you perform selective deletion: Some applications do not provide the option of selecting individual documents for the load process. Therefore, you must first ensure that you can load the same range of documents into BW as you would delete from the ODS object. This note provides some application-specific recommendations to help you "repair" the incorrect data records. If you updated the data from the ODS object into the InfoCube, you can also delete it there using the "Selective deletion" function. However, if it is compressed at document level there and deletion is no longer possible, you must delete the InfoCube content and fill the data in the ODS object again after repair. You can only perform this action after a thorough analysis of all effects of selective data deletion. We naturally recommend that you test this first in the test system. The procedure generally applies for all SAP applications/extractors. The application determines the selections. For example, if you cannot use the document number for selection but you can select documents for an entire period, then you are forced to delete and then update documents for the entire period in the data target. Therefore, it is important to look first at the selections in the InfoPackage exactly before you delete data from the data target. Some applications have additional special features: Logistics cockpit: As preparation for the repair request, delete the SetUp table (if you have not already done so) and fill it selectively with concrete document numbers (or other possible groups of documents determined by the selection). Execute the Repair request. Caution: You can currently use the transactions that fill SetUp tables with reconstruction data to select individual documents or entire ranges of documents (at present, it is not possible to select several individual documents if they are not numbered in sequence). FI: The Repair request for the Full Upload is not required here. The following efficient alternatives are provided: In the FI area, you can select documents that must be reloaded into BW again, make a small change to them (for example, insert a period into the assignment text) and save them -> as a result, the document is placed in the delta queue again and the previously loaded document under the same number in the BW ODS object is overwritten. FI also has an option for sending the documents selectively from the OLTP system to the BW system using correction programs (see note 616331).

3. Repair request execution How do you proceed if you want to load a repair request into the data target? Go to the maintenance screen of the InfoPackage (Scheduler), set the type of data upload to "Full", and select the "Scheduler" option in the menu -> Full Request Repair -> Flag request as repair request -> Confirm. Update the data into the PSA and then check that it is correct. If the data is correct, continue to update into the data targets."

经过几个小时的了解，现在回头来想，确实repair full request很重要，实际项目中也应该经常用到。因为虽然initial delta做好了，delta update也做好了，processing chain也做好了，并不是表示从此以后系统就规规矩矩地按常理来出牌了。它时不时还是会跳出个missing record，或者corrupt record给你，让你伤伤脑筋。

对于已经走了很长时间的delta update，BW target infoprovider已经存储了相当大的数量了，如果突然发现有missing record或者corrupt record是件很头痛的事，不可能全部删掉重新做，RSA7 delta repetition只能repete上一次的delta，假如是很久以前的delta中间的record是没有办法重新上载的。

于是，repair full request就出现了。

repair full request是在发现有record missing 或corrupt后，（如果数据是直接传往CUBE, 则需先delete CUBE中的受影响的record，不然数据再次传上来会duplicate；如果是传往DSO，这个不需要delete了，因为DSO有覆盖功能。）新建一个infopackage，选择full update模式，然后scheduler-->repair full request,并且在package的extract中设置好要重新抽取的data record period，然后就可以start infopackage了。后续动作DTP，transformation照做。

repair full request的最大好处就是它的执行并不会影响到initial delta update和delta update的执行。或者说，两者是平行的。

比如说，发现DSO中有一条record错误，这时就可以新建package，full update,repair full request, extract里面只选投这一条数据，重新抽取一下就行了。

当然，可以先到RSA3中（setup table）中确认一下此条数据是否正确，正确的话就可以按上面的步骤进行抽取了。

这里需要讲一下full update和delta update的不同。（也是今天上午查阅了很多资料才弄懂的。）

full update是直接从setup table中直接读取数据，所以repair full request才成为可能。

delta update是从RSA7 (queued delta)中读取数据，（数据从R3端进入SM13或者LBWQ，JOB 运行后进行RSA7）；所以如果有record missing，那么RSA7中肯定不会有这个missing record的，再怎么delta repetition也没有用，只能用repair full request来修补。