BW的Repair Full Request

       确实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是在发现有recordmissing 或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来修补。

 

这是一个非常实际的需求。想想，也是做为了一个BW顾问必须了解的知识点。（果然老师只是给个方向，关键还是得靠自己呀！）

下面这个链接是对repair full request一个非常好的tread，SDN上的，回答得非常详细到位。

 

 

http://forums.sdn.sap.com/thread.jspa?threadID=121265&start=0&tstart=0

 

 

 

repair full request  Posted: Mar 13, 2006 6:26 PM
When to use repair full request??? Lemme pen down my scenario... I was asked to test in Development box for Item and header in sales..... Last delta was done at last year dec.....now can I make use of same Delta Infopackage for pulling 3 months of data... I was told to do repair full request???? Should I do this by creating one more info package with full load...to pull 3 months of data.... I got many inputs from my friends... Input 1: One says if there is delta Infopackage and to do full load we have to select Repair full request cos, it will not allow us to do full load after delta has been intialised... Input 2: If there are full loads earlier and to initialise delta we need to select Repair full request while creating Delta Infopack.... Which is the correct one???If both are not correct then lemme know when to use repair full request??? Thanks in advance and waiting for ur valuable suggestions

 

 

BW

Welcome back. Check this link hope this helps. By the way what happened to your previous query could you able to load Delta from ODS to Cube successfully?

http://help.sap.com/saphelp_nw04/helpdata/en/1b/df673c86d19b35e10000000a11402f/frameset.htm

Check this link also for some more details

http://help.sap.com/saphelp_nw04/helpdata/en/80/1a65dce07211d2acb80000e829fbfe/frameset.htm

Thnaks
Sat

Message was edited by: Sat

Message was edited by: Sat

 

 

 

	Re: repair full request  Posted: Mar 13, 2006 6:57 PM  in response to:BW
Hello, Go for Repair Full Request. In order not to disturb your delta selections you need to do the repair full load. After your repair full load you can continue loading deltas normally. Create a new InfoPackage and mark this as Repair and then choose full upload and execute. There is no repair flag for deltas. GSM.

 

 

 

 

Re: repair full request  Posted: Mar 13, 2006 7:21 PM  in response to:BW
Hello BW, If you are doing a Full load to InfoCube, before you load you have to ensure that the data that you are trying to load doesn’t exist in InfoCube already. If data exists in InfoCube then do a selective deletion first in the InfoCube and then do the Full load. As values will be incorrect as InfoCube has Addition update only. If the data that you are trying to load doesn’t exist then do the full directly. In the existing system the data load from ODS to InfoCube, using a delta load or a full load ? Hope this helps, GSM.
Re: repair full request  Posted: Mar 13, 2006 7:38 PM  in response to:GSM
Currently Loading is delta ....Last delta load was on last december.....since I have 3 months of data to be pulled from R/3... I am planning to create a new Infopack with Full load by selecting Full repair request... Thats what u have said right????
Re: repair full request  Posted: Mar 13, 2006 8:38 PM  in response to:BW
BW, You have delta runs till december 2005, and you are only missing 2 1/2 months data, so you can run even directly just run the delta run. But make sure in RSA3 whether you have delta records for 01, 02 & 03 of 2006. All the records are in delta queue then, just do the delta. Dont even run the full repair. Then do the reconciliation. By chance if it doesn’t match, then you can do the selective delete for Dec 2005 till 03/2006 and then run the full repair request for the missing periods. GSM.
Re: repair full request  Posted: Mar 13, 2006 9:59 PM  in response to:GSM
Hey GSM, I am seeing only data for 2002 in RSA3 and even in RSA7 also.... Not only in development box but also in production box also....what would have happened to 2003, 4, 5 and 6 data????
	Re: repair full request  Posted: Mar 14, 2006 9:41 PM  in response to:BW		Reply
Hello BW, For your case Full Repair is not an option. Because even after you do the full repair, when you do delta, system is gonna get all the records, after your previous delta. Then your records will be doubled(if it is loading into the cube). If you are getting the data into the ODS either delta or full you are good no problems. As in ODS it will overwrite for the existing records. But if it is in the Infocube that you are loading, then no option for you except delta. Dont cross check anything in RSA3. First just schedule the delta load in your case. Once the delta load is done, using manage or listcube check the records came in for till march 2006 or not. after the load, your delta will be pointing to current date. Then you check in BW and source system whether you have all the data or not. If not, then can think for alternatives...for full repair. (One more time full repair you need to use for preserving your delta selections. Also when you think that data which you have already pulled into BW is incorrect or missing in those cases you can do full repair.) Hope this helps, GSM.

 

 

 越学越觉得太多东西不懂了。没办法，只有继续加油了！！！

 

 补充：

原来，如果不想要setup table里面的数据，只想抽取增量，可以在建infopackage的时候，initial delta update选择without data transfer，这样，就只是建了一个delta mechnism,并不抽取实际数据，这样做是为了做delta update。因为必须要先做initial delta update，才能做delta update.

如果需要setup table 里面的内容，initial delta update就选with data transfer，这样数据就会从setup table里面读出来；

如果不需要setup table里面的内容，initial delta update就选without date transfer，这样数据就不会从setup table里面读出来了，等delta update 包建好后，数据直接从RSA7中读取。