BW的Repair Full Request

fog911811發表於2012-08-13
AI
       確實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中讀取。

 

相關文章