- 現在有一個 QUERY 運行十分慢 , 所以我想在 BW 裏找到一個工具來分析這個 QUERY 是怎麼運行的 . 想知道慢在什麼地方 , 用了多少時間等一些具體信息 .
-
- 在 BW 中使用交易代碼 RSRT
- 填上需要測試的報表的技術名稱
- 單擊執行 + 調試
- 勾選彈出的調試選項對話框的其他中的顯示統計數據和未使用高速緩存
- 輸入 Querry 的所需要的變量，運行
- 結果回來之後， F3 返回 統計數據界面：將持續時間求和減去時間等待時間、用戶的時間，得到的時間作爲該報表的統計時間
- 報表執行的速度一般都是
cache > BIA > Aggregate > Cube 自身 ..
所以第二次執行，能從 cache 取數的話，自然就快 了
-
我在激活一個 DSO 時，由於數據量比較大，差不多有 2 千多萬條的數據，之前的傳輸進程都是綠燈，可在激活過程中，就變成了紅燈，不管激活多少次也是紅燈，請問這個是什麼原因啊 ？
這個 DSO 是主要做報表用，還是做數據存放及 delta 用，如果是後者的話，更改 DSO 的屬性把 “SIDs Generation upon Activation” 的勾棄掉，如果是前者，可以通過事務 “RSODSO_SETTINGS” 調整相應參數來提高你的 active 的效率。
Parameter for SID Generation
中， Maximum package Size
是 2 萬， maximum wait time for process
是 600(10 分鐘
) ，這個數字是否是越大越好 ?
Maximum package Size 是根據你的內存來設的， maximum wait time for process
可以長一點。
- 執行 “
分配工作簿 ” 後，收到了郵件，可是
Excel 裏的中文都是井號 “#######”
，請問該怎麼解決？謝謝！
BW 是 3.5 的。
a) 退出 BW 系統，關閉所有 BW 系統的窗口和 EXCEL 的窗口；
b) 右鍵點擊 “ 我的電腦 ” ，選擇 “ 屬性 ”――>“ 高級 ”――>“ 環境變量 ”--“ 系統變量 ”--“ 新建 ” ，變量名： SAP_CODEPAGE 變量值： 8400
c)
依次點擊 “ 確定
” ，保存新增的環境變量 .
不行的話，重啓下機器，另外注意用戶名密碼輸入界面下的語言輸入 ZH
- 我目前在做一個 供應商分析 的報表的時候碰到了一個過濾不出過濾條件的問題，望各位大俠能幫忙！謝謝！
報表是在信息提供者：設備主數據
上出的。供應商是 設備主數據
的一個 屬性（導航）。在 query
裏製作報表的時候行上是 ‘ 供應商 ’
，列上是 ‘ 設備數 ’
。目的是分析該供應商都提供了多少設備。當然自由特性裏有個設備號，可以追溯。
但當我用 rsrt 測試報表的時候，
* 正常顯示是沒有問題的 *
，但想過濾出特定的供應商的時候總是過濾不出來。再追蹤的時候出現如下提示：
’ 在特性 ZZCZZS
的主數據表中不存在特性值 ##################### 。因此，無法將此值傳輸到內部
SID 中。 ‘
另外 在 ecc 的時候 供應商就是中文，並不像其他的設備的屬性一樣有個編號，然後編號可以對應一箇中文。 是不是和中文有關，因爲在提示裏的特性值是 ##### 。 有沒有解決的辦法？ 謝謝了！！！
還有在不論是設備主數據還是供應商主數據中中文顯示都正常，我在過濾的時候是選擇的，而不是輸入問題。
用 RSRC check 你的那二個特徵，並修復。
rsa1-- 工具 -- 應用層次結構 / 屬性更改 -- 信息對象清單，檢查設備特性是否在列表裏，選中執行屬性更改
- SAP 後勤數據的抽取，使用的增量隊列，
財務數據的抽取，使用的是時間戳，
這句話對不對？
財務數據使用時間戳，就是說不通過增量隊列，數據由業務系統直接到達 BW 系統，
似乎與實際情況不符。
1 、使用 RSA7 查看增量隊列時，確實可以看到財務數據源： 0FI_GL_4, 0FI_GL_6,
2 、總賬憑證過賬後，立即進行數據抽取， 0FI_GL_4 並不能立刻抽取到數據，而 0FI_GL_6 立刻就可以抽取到最新數據， 這是怎麼回事呢？
或者我哪裏理解錯了？
SAP
後勤數據的抽取，使用的增量隊列，
財務數據的抽取，使用的是時間戳，
這句話是對的，
總賬憑證過賬後，立即進行數據抽取， 0FI_GL_4
並不能立刻抽取到數據，而 0FI_GL_6 立刻就可以抽取到最新數據，
這是怎麼回事呢？
那是原因這二個的時間戳的粒度不一樣，一個是到時分秒的，一個只是到 posting date
的。
0FI_GL_10
和 0FI_GL_14 都是爲 new GL
提供的 datasouce.
0FI_GL_4 和 0FI_GL_6
在 BW 7.x 也都是可用的
。
BW 請求數據，在 R3 端執行對應的 FM 操作，獲取數據，寫入增量隊列 。
- 我現在有個問題，對於同一個 Transformation ，其中有個字段，需要針對不同的 DTP ，賦予不同的值，請問如果處理，謝謝！
1
可以在表 tvarvc 中建一個變量
2 然後在不同的 dtp 中的
transfert routine 裏寫 賦值給上面變量
的 code : 比如
dtp A 執行則賦變量的值 爲
A 若 dtp B 則變量的
值爲 B 。。。。
3 然後在 transformation start routine
中 去讀 變量的值
看是從哪個 dtp 過來的 ，然後更改處理規則
。
1、 建立一個表；
2、 在 DTP 的過濾條件中寫代碼給表插入一條記錄；
3、 在轉換中去讀取該表中的記錄，並在結束例程中刪除表中記錄。
- DSO 用來存儲明細數據，其結構比較簡單 , 對於值的轉換 , 既可以使用合計，也可以使用覆蓋的方式。因在源端 , 如果存在相同的 customer 記錄 , 需要合併 , 爲了省事 , 並沒有寫 abap 代碼 , 直接啓用了合計的方式 , 如果使用合計的方式，可以用 delta 嗎（最終的 DSO ） ? 如果可以 , 該用什麼類型的 delta. 如果不可以 , 又不想寫代碼 , 如何能實現合計和 delta 的兩種功能 .
確定你的情況必須要要用合計 ? 用合計的 kf 一般要謹慎的 確定你在的 kf 合計出的結果的正確性 ，不然整個 dso 裏的數據都會錯誤。 delta 是 適用的 recordmode 用 after image 即可 .
可以用 RSA2 查到每個數據源的 delta 屬性，比如 2lis_03_bf 是 ABR, 這表示這個數據有 after image 、 before image 、 revise image.
不是說 ods 用合計不能做 delta ， 而是說 ods 一般用來記錄的是合計每條數據的詳細情況，如果 ods 裏不做報表 你可以把 kf 當 charactestic 來理解 ，而在 cube 裏面來合計 是相對於不同的 diemension 來合計你的 kf 這樣是爲報表多維分析服務的 。
ods的 delta是把 change log表的變化記錄往上更新 , "合計 "是 key值相同下 ,keyfigure累加的 .
你可以用 DSO, 但是得用兩層 DSO, 第一層 DSO1 用 Overwrite 方式 , 用來正確獲取 Delta 的 Change log 數據 , 第二層 DSO2 從 DSO1 更新 , 可以使用 Sum 方式 .
- 由於每隔一段時間需要對
PSA 進行清理， PSA 的數量多，而且每一個我只懂用右鍵
-> 管理，然後一條一條地選擇需要刪除的記錄（批量一個時間段的，如 1-3
個月的每日 Delta ）。
請問各位高手，有沒有更好的方法可以清理 PSA 的數據。
1、 僅成功登記
/ 更新請求 ====
就是指成功更新到 DSO 或者 CUBE
的數據請求
2 、僅那些未在數據目標中登記的帶有錯誤的請求 ====
就是出錯了，沒有更新到 DSO 或者 CUBE
的請求
3 、僅刪除裝載請求，不要刪除激活請求（ ODSR...)====
這個應該是說成功裝載但是沒有上傳到 DSO 或者 CUBE
的請求吧。
一般來說，我們是刪除前 30 天的請求，保留一個月的請求數據即可，這樣做的好處是還能節省一下磁盤空間
。
FI-AP
、 AR 的設計就是抽取前面一天的數據，因此增量不能抽取到當天的數據。
如果數據量不大的話，建議進行全量抽取，然後在 BW
使用 DSO 進行增量的處理 。
BW
中，存在兩種數據抽取方式，完全更新與增量更新，完全更新是每次把截至到某個時間的數據全部抽取，增量抽取則只抽取上次和本次抽取之間更新的數據，很顯然，增量抽取能夠提高系統效率，根據
SAP 幫助的說法，增量更新又分爲時間戳和增量隊列兩種方法，其中財務數據的抽取爲時間戳增量法，後勤數據的抽取爲增強隊列法。對於增量更新，都需要先對數據抽取進行初始化，然後再進行增量的抽取。對於時間戳增量法，系統存在一個延遲時間，即時間戳設置時間與記賬時間的差異，比如時間戳是根據創建時間（或輸入時間）來確定是否更新的依據，而在抽取開始時（時間戳已標記），此時憑證已創建而未記賬（即未更新至數據庫），則此次無法抽取到該憑證，但下次抽取時，由於已在時間戳範圍之外，也不再進行抽取，從而導致抽取數據遺漏，避免此問題，
SAP 幫助上給出了通過設置安全抽取時間的方法，設置視圖爲 BWOM2_V_SAFETY
，可根據不同的數據源設置不同的安全時間，兩個小時爲推薦設置
這個安全時間是對於已經創建但未保存在憑證而言，如果在這個安全時間內保存了，則此次抽取將包含在內
，
比如你 6小時抽取一次數據，假如你第一次在 12:00抽取，那麼下次應該是 18:00抽取，那麼應該來說 18:00抽取的數據是 12:00-18:00的數據纔對，但是有種情況需要你考慮，比如我
11:55在做一個憑證，但是中間我去吃飯， 12:30纔回來完成這個憑證，那麼這個憑證就是 11:55創建的，在 12:00抽取的時候，由於憑證沒有產生，因此無法抽取，但是下次 18:00抽取的時候，由於這個憑證是在 11:55創建的，所以也無法抽取到。
做 BW數據倉庫最重要的一條準則就是 “不重複、不遺漏 ”，那麼這樣你就遺漏了數據，那麼 SAP就想了個辦法，就是比如這次我抽取從 06:00-12:00，那麼下次我抽取從 11:30-18:00，這樣上面的憑證就能抽取出來了吧，這時候
11:30-12:00就有半個小時的重複，這個就叫做 Lower Limit。
同上，比如我 12:00抽取的時候，不想抽取 06:00-12:00，而是想抽取 06:00-11:30，那麼我就設置一個 Higher Limit
爲 30分鐘，則抽取的時候就不會到最新的時間，而是需要過賬半小時前的憑證。
比如我設置了 30分鐘的 Lower Limit， 30分鐘的 Higher Limit，那麼我 12:00抽取的數據應該是 05:00-11:30的數據，下次抽取的數據時
11:00-17:30,在下次就是 17:00-23:30，在下次就是 23:00-05:30，在下次就是 05:00-11:30，如此循環。
但是如果設置了 Lower Limit和 Higher Limit之後，請記得在 BW中使用 DSO來處理數據。
在 RSCUR 中創建新的貨幣轉換類型就可以了，不過 3.5 版本中事務代碼爲 rrc1.
- 大家都知道從 dso 到 cube 進行增量抽取數據時 , 只有未被抽入 cube 的那部分增量數據纔會進入 cube. 而系統具體是怎麼從 change log 中判斷出那部分增量數據的 ? 具體通過那些表 , 那位給講解一下 .
每次
DSO 數據進行激活更新時，都會在 change log
表產生一個 request ，這個 request
對應這次請求發生改變的所有記錄，如果是新記錄， change log table
中的 recordmode = N, 如果是更改，那麼會產生
2 條記錄，一條 recordmode = X
代表修改前，另外一條 recordmode = ' ' 表示修改後。
往 cube 上
delta 更新的時候，就是靠這些來獲取變化量的，新產生的 request
中的那些記錄。
- 1. Promotion detail information
如何在 BW 中取得？
2. 如何取得 weekly stock ， monthly stock by article （ quantity ， inventory value ）？（已經在使用 BI content infocube ： 0IC_C03 ）
3. 對於 trasaction data ，在 r3 做過 enhancement 的時候，加上一些 fields ，如果想在 r3 中修改這些 fields （僅僅修改這些 fields 的值），如何讓修改過的 transaction data 進入 delta queue ？
4. 在 datasource ： 2LIS_03_BF 已經 daily update 到 0ic_c03 的情況下，在 R3 中用 rsa3 發現 2LIS_03_UM 有很多重複記錄，該如何做使得該 datasource 中的數正常？
5. master data 從 R3 到 BW 是不是都 full load ？ Location Product infoobject ： 0MAT_PLANT 是 daily update ，但是數據量比較大（目前 600 多萬），如果 full load 的話會不會時間比較久並且耗資源？有沒有其他解決方案？
6. inventory management 的問題：關於 infocube ： 0IC_C03 是應該從兩個 datasource ： 2LIS_03_BF ， 2LIS_03_BX 取數，還是應該從三個 datasource ： 2LIS_03_BF ， 2LIS_03_BX ， 2LIS_03_UM ？
7. retail price 如何在 BW 中取得？ Moving average price(MAP) 如何在 BW 中取得？
8. 在 process chain 中調用 analysis process ， auto run 的時候 analysis procee 經常會報錯： Value D4QG5ZUPU5NZBG0M4RTH9W7ZC for characteristic D4QG5ZUPU5N7MTOUT8DV7GTPK unknown 。在出錯後人手去跑這個 analysis process 又正常。不知道是什麼原因 ？