工作中常見問題分析

1、一、BW DTP非法字符問題無非就是業(yè)務(wù)上搞出一堆亂七八糟的字符，這些字符到了BW這邊，就變成了井號（#）這個解決辦法有這么幾種：1、直接改 PSAPSA可以修改，可是這樣治標(biāo)不治本，頂多是我們這邊數(shù)據(jù)上載正常了，可是數(shù)據(jù)跟業(yè)務(wù)上 的錄入還是有差別2、在轉(zhuǎn)換中寫 Start Routine 方法類似，不過是把 # 替換成 或者 也是和方法 1 類似， 只不過是升級了一下， 不用手工操作， 代價就是上載的效率和傳輸?shù)牧?程3、增強數(shù)據(jù)源這個方法比較慘，因為井號（#）在源系統(tǒng)中指不定是啥字符呢，仔細(xì)算算得有十幾個，都控制的話代價比較大，不如寫Start Routine，只不過一個PSA可能會上載到

2、多個模型，就得寫多個 Start Routine 。4、找業(yè)務(wù)修改R3的數(shù)據(jù)這個好，改完了 BW再抽一遍完事兒，不過協(xié)調(diào)起來比較復(fù)雜5、增強業(yè)務(wù)系統(tǒng)在用戶輸入或者批導(dǎo)的時候，控制輸入， 當(dāng)遇到這種垃圾字符的時候， 就提示錯誤，禁止寫 入，這是最好的辦法。二、現(xiàn)在有一個 QUERY 運行十分慢 , 所以我想在 BW 里找到一個工具來分析這個 QUERY 是怎么運行的 . 想知道慢在什么地方 , 用了多少時間等一些具體信息 .1、在 BW 中使用交易代碼 RSRT2、填上需要測試的報表的技術(shù)名稱3、單擊執(zhí)行 + 調(diào)試4、勾選彈出的調(diào)試選項對話框的其他中的顯示統(tǒng)計數(shù)據(jù)和未使用高速緩存5、輸入 Que

3、rry 的所需要的變量，運行結(jié)果回來之后， F3 返回 統(tǒng)計數(shù)據(jù)界面：將持續(xù) 時間求和減去時間等待時間、用戶的時間，得到的時間作為該報表的統(tǒng)計時間 報表執(zhí)行的速度一般都是cache BIA Aggregate Cube自身 .所以第二次執(zhí)行，能從 cache （緩存） 取數(shù)的話，自然就快了三、我在激活一個 DSO 時，由于數(shù)據(jù)量比較大，差不多有 2 千多萬條的數(shù)據(jù)，之前的傳 輸進(jìn)程都是綠燈，可在激活過程中， 就變成了紅燈，不管激活多少次也是紅燈，請問這個是 什么原因啊 ？這個 DSO 是主要做報表用，還是做數(shù)據(jù)存放及 delta 用，如果是后者的話，更改 DSO 的 屬性把 “SIDs Gen

4、eration upon Activation激活之后生產(chǎn)主數(shù)據(jù)標(biāo)識” 的勾棄掉，如果是前者，可以通過事務(wù)“ RSODSO_SETTINGS調(diào)整相應(yīng)參數(shù)來提高你的active 的效率。Parameter for SID Generation 中， Maximum package Size 是 2 萬， maximum wait time for process 是 600（10 分鐘 ） ，這個數(shù)字是否是越大越好 ?Maximum package Size 是根據(jù)你的內(nèi)存來設(shè)的， maximum wait time for process 可以長 一點。四、執(zhí)行 “ 分配工作簿 ” 后，收到了

5、郵件，可是 Excel 里的中文都是井號 “# #” ，請問該怎么解決？謝謝！BW 是 3.5 的。退出 BW 系統(tǒng)，關(guān)閉所有 BW 系統(tǒng)的窗口和 EXCEL 的窗口；右鍵點擊“我的電腦”，選擇 “屬性” 高級” 環(huán)境變量”-“系統(tǒng)變量”-“新建”，變量名： SAP_CODEPAGE 變量值： 8400依次點擊“ 確定” ，保存新增的環(huán)境變量 .不行的話，重啟下機器，另外注意用戶名密碼輸入界面下的語言輸入ZH1. 我目前在做一個 供應(yīng)商分析 的報表的時候碰到了一個過濾不出過濾條件的問題，望各位大俠能幫忙！謝 謝！報表是在信息提供者：設(shè)備主數(shù)據(jù) 上出的。供應(yīng)商是 設(shè)備主數(shù)據(jù) 的一個 屬性(導(dǎo)航)

6、。在 quer y 里制作報表的時候行上是 供應(yīng)商 ，列上是 設(shè)備數(shù) 。目的是分析該供應(yīng)商都提供了多少設(shè) 備。當(dāng)然自由特性里有個設(shè)備號，可以追溯。但當(dāng)我用 rsrt 測試報表的時候， * 正常顯示是沒有問題的 * ，但想過濾出特定的供應(yīng)商的時候總 是過濾不出來。再追蹤的時候出現(xiàn)如下提示：在特性 ZZCZZS 的主數(shù)據(jù)表中不存在特性值 #。因此，無法將此值傳輸?shù)絻?nèi)部 SID 中。另外在 ecc 的時候供應(yīng)商就是中文， 并不像其他的設(shè)備的屬性一樣有個編號，然后編號可以對應(yīng)一個中文。是不是和中文有關(guān)，因為在提示里的特性值是 # 。有沒有解決的辦法？ 謝謝了！還有在不論是設(shè)備主數(shù)據(jù)還是供應(yīng)商主數(shù)據(jù)中中

7、文顯示都正常，我在過濾的時候是選擇的，而不是輸 入問題。用 RSRC check 你的那二個特征，并修復(fù)。rsa1- 工具 - 應(yīng)用層次結(jié)構(gòu) / 屬性更改 - 信息對象清單，檢查設(shè)備特性是否在列表里，選中執(zhí)行 屬性更改1. SAP 后勤數(shù)據(jù)的抽取，使用的增量隊列， 財務(wù)數(shù)據(jù)的抽取，使用的是時間戳，這句話對不對？財務(wù)數(shù)據(jù)使用時間戳，就是說不通過增量隊列，數(shù)據(jù)由業(yè)務(wù)系統(tǒng)直接到達(dá)BW 系統(tǒng)，似乎與實際情況不符。、使用 RSA7 查看增量隊列時，確實可以看到財務(wù)數(shù)據(jù)源：0FI_GL_4,0FI_GL_6,、總賬憑證過賬后，立即進(jìn)行數(shù)據(jù)抽取， 0FI_GL_4 并不能立刻抽取到數(shù)據(jù)，而 0FI_GL_6

8、 立刻 就可以抽取到最新數(shù)據(jù)， 這是怎么回事呢？或者我哪里理解錯了？SAP 后勤數(shù)據(jù)的抽取，使用的增量隊列，財務(wù)數(shù)據(jù)的抽取，使用的是時間戳，這句話是對的，總賬憑證過賬后，立即進(jìn)行數(shù)據(jù)抽取， 0FI_GL_4 并不能立刻抽取到數(shù)據(jù)，而 0FI_GL_6 立刻就可 以抽取到最新數(shù)據(jù)， 這是怎么回事呢？ 那是原因這二個的時間戳的粒度不一樣，一個是到時分秒的，一個只是到 posting date 的。0FI_GL_10 和 0FI_GL_14 都是為 new GL 提供的 datasouce.0FI_GL_4 和 0FI_GL_6 在 BW 7.x 也都是可用的 。BW 請求數(shù)據(jù)，在 R3 端執(zhí)行對應(yīng)

9、的 FM 操作，獲取數(shù)據(jù)，寫入增量隊列 。1. 我現(xiàn)在有個問題，對于同一個 Transformation ，其中有個字段，需要針對不同的 DTP ，賦予不同 的值，請問如果處理，謝謝！可以在表 tvarvc 中建一個變量然后在不同的 dtp 中的 transfert routine 里寫 賦值給上面變量 的 code : 比如 dtp A 執(zhí)行 則賦變量的值 為 A 若 dtp B 則變量的 值為 B 。然后在 transformation start routine 中 去讀 變量的值 看是從哪個 dtp 過來的 ，然后更改處 理規(guī)則 。、 建立一個表；、 在 DTP 的過濾條件中寫代碼給表

10、插入一條記錄；、 在轉(zhuǎn)換中去讀取該表中的記錄，并在結(jié)束例程中刪除表中記錄。1. DSO 用來存儲明細(xì)數(shù)據(jù)， 其結(jié)構(gòu)比較簡單 , 對于值的轉(zhuǎn)換 , 既可以使用合計， 也可以使用覆蓋的方式。 因在源端 , 如果存在相同的 customer 記錄 , 需要合并 , 為了省事 , 并沒有寫 abap 代碼 , 直 接啟用了合計的方式 , 如果使用合計的方式，可以用 delta 嗎（最終的 DSO ） ? 如果可以 , 該用 什么類型的 delta. 如果不可以 , 又不想寫代碼 , 如何能實現(xiàn)合計和 delta 的兩種功能 .確定你的情況必須要要用合計 ? 用合計的 kf 一般要謹(jǐn)慎的 確定你在的 k

11、f 合計出的結(jié)果的正確性 不然整個 dso 里的數(shù)據(jù)都會錯誤。 delta 是 適用的 recordmode 用 after image 即可 .可以用 RSA2 查到每個數(shù)據(jù)源的 delta 屬性，比如 2lis_03_bf 是 ABR, 這表示這個數(shù)據(jù)有 after image 、 before image 、 revise image.不是說 ods 用合計不能做 delta ， 而是說 ods 一般用來記錄的是合計每條數(shù)據(jù)的詳細(xì)情況， 如果 ods 里不做報表 你可以把 kf 當(dāng) charactestic 來理解 ，而在 cube 里面來合計 是相對于不同的 diemension 來合

12、計你的 kf 這樣是為報表多維分析服務(wù)的 。ods 的 delta 是把 change log 表的變化記錄往上更新 , 合計 是 key 值相同下 ,keyfigure 累加 的 .你可以用 DSO, 但是得用兩層 DSO, 第一層 DSO1 用 Overwrite 方式 , 用來正確獲取 Delta 的 Change log 數(shù)據(jù) , 第二層 DSO2 從 DSO1 更新 , 可以使用 Sum 方式 .O的數(shù)據(jù)源都是 ADD的，差額鏡像，E，可以直接上述到 cube,如果上述到dso，則需要 設(shè)置成 sum，不能設(shè)置 overwrite。FI的基本都是AIE,后鏡像，E，不能直接上述到cu

13、be，必須先上述到dso，并且要設(shè)置overwrite ； LO的基本都是 ABR,這個就不用說了，很明細(xì)，新、前、后、翻轉(zhuǎn)的鏡像都存，量很大，可是上述cube，可以上述dso，對于dso的設(shè)置也沒有關(guān)系，D自建的默認(rèn)是 AIE同F(xiàn)I（ BT的是沒有提供更改方法，所以自建的統(tǒng)一都是AIE），E主數(shù)據(jù)的一般采用 AIE、AIM和NEWE,說明比較側(cè)重結(jié)果和新增數(shù)據(jù)下面簡述下 AIE和ABR的區(qū)別：ABR的方式注定了，不僅適合直接上載到DSO,可以直接上載到 CUBE不通過DSO,因為不僅序列化，而且是連帶各種鏡像。AIE不同，只支持后鏡像，也就是說，只能首先加載到DSO,然后進(jìn)行分析，會在激活數(shù)

14、據(jù)時幫我們補齊前鏡像，到 DSO的LOG表里，從而保證了 DSO的明細(xì)要求，又能在 CUBE提 取LOG表的時候獲得正確的數(shù)據(jù)。因為CUBE只有匯總，沒有覆蓋功能。Delete image上述時的kf是空，所有不能直接上述 cube，可以上述到dso，但是必須用 ove rwrite ；Reverse image翻轉(zhuǎn)像可以上述到 cube，也可上述到 dso可以設(shè)置成 sum和overwrite ；1. 由于每隔一段時間需要對 PSA 進(jìn)行清理， PSA 的數(shù)量多，而且每一個我只懂用右鍵 - 管理，然后 一條一條地選擇需要刪除的記錄（批量一個時間段的，如 1-3 個月的每日 Delta ）。

15、請問各位高手，有沒有更好的方法可以清理 PSA 的數(shù)據(jù)。、 僅成功登記 / 更新請求 = 就是指成功更新到 DSO 或者 CUBE 的數(shù)據(jù)請求、僅那些未在數(shù)據(jù)目標(biāo)中登記的帶有錯誤的請求 = 就是出錯了，沒有更新到 DSO 或者 CUBE 的請求、僅刪除裝載請求，不要刪除激活請求（ODSR.）=這個應(yīng)該是說成功裝載但是沒有上傳到 DSO或者 CUBE 的請求吧。一般來說， 我們是刪除前 30 天的請求， 保留一個月的請求數(shù)據(jù)即可， 這樣做的好處是還能節(jié)省一下磁盤空間1. FI 怎么抽取當(dāng)天的數(shù)據(jù)？FI-AP 、 AR 的設(shè)計就是抽取前面一天的數(shù)據(jù)，因此增量不能抽取到當(dāng)天的數(shù)據(jù)。 如果數(shù)據(jù)量不大的

16、話，建議進(jìn)行全量抽取，然后在 BW 使用 DSO 進(jìn)行增量的處理1. 安全上下限BW 中，存在兩種數(shù)據(jù)抽取方式，完全更新與增量更新，完全更新是每次把截至到某個時間的數(shù)據(jù)全 部抽取，增量抽取則只抽取上次和本次抽取之間更新的數(shù)據(jù)，很顯然，增量抽取能夠提高系統(tǒng)效率，根 據(jù) SAP 幫助的說法，增量更新又分為時間戳和增量隊列兩種方法， 其中財務(wù)數(shù)據(jù)的抽取為時間戳增量 法，后勤數(shù)據(jù)的抽取為增強隊列法 。對于增量更新，都需要先對數(shù)據(jù)抽取進(jìn)行初始化，然后再進(jìn)行增量 的抽取。對于時間戳增量法，系統(tǒng)存在一個延遲時間，即時間戳設(shè)置時間與記賬時間的差異，比如時間 戳是根據(jù)創(chuàng)建時間（或輸入時間）來確定是否更新的依據(jù)，

17、而在抽取開始時（時間戳已標(biāo)記），此時憑 證已創(chuàng)建而未記賬（即未更新至數(shù)據(jù)庫），則此次無法抽取到該憑證，但下次抽取時，由于已在時間戳 范圍之外，也不再進(jìn)行抽取，從而導(dǎo)致抽取數(shù)據(jù)遺漏，避免此問題， SAP 幫助上給出了通過設(shè)置安全 抽取時間的方法，設(shè)置視圖為 BWOM2_V_SAFETY ，可根據(jù)不同的數(shù)據(jù)源設(shè)置不同的安全時間，兩 個小時為推薦設(shè)置 這個安全時間是對于已經(jīng)創(chuàng)建但未保存在憑證而言， 如果在這個安全時間內(nèi)保存了， 則此次抽取將包含 在內(nèi)，比如你 6 小時抽取一次數(shù)據(jù)，假如你第一次在 12:00 抽取，那么下次應(yīng)該是 18:00 抽取，那么應(yīng)該來說 18:00 抽取的數(shù)據(jù)是 12:00-

18、18:00 的數(shù)據(jù)才對，但是有種情況需要你考慮，比如我 11:55 在做一個憑證，但是 中間我去吃飯， 12:30 才回來完成這個憑證，那么這個憑證就是 11:55 創(chuàng)建的，在 12:00 抽取的時候，由于 憑證沒有產(chǎn)生，因此無法抽取，但是下次 18:00 抽取的時候，由于這個憑證是在 11:55 創(chuàng)建的，所以也無法 抽取到。做 BW 數(shù)據(jù)倉庫最重要的一條準(zhǔn)則就是 “不重復(fù)、不遺漏 ”，那么這樣你就遺漏了數(shù)據(jù)，那么 SAP 就想了個辦法，就是比如這次我抽取從 06:00-12:00 ，那么下次我抽取從 11:30-18:00 ，這樣上面的憑證就能抽取出來了吧，這時候 11:30-12:00 就

19、有半個小時的重復(fù)，這個就叫做 Lower Limit 。同上，比如我 12:00 抽取的時候，不想抽取 06:00-12:00 ，而是想抽取 06:00-11:30 ，那么我就設(shè)置一個Higher Limit 為 30 分鐘，則抽取的時候就不會到最新的時間，而是需要過賬半小時前的憑證。比如我設(shè)置了 30 分鐘的 Lower Limit ， 30 分鐘的 Higher Limit ，那么我 12:00 抽取的數(shù)據(jù)應(yīng)該是 05:00-11:30 的數(shù)據(jù)，下次抽取的數(shù)據(jù)時 11:00-17:30, 在下次就是 17:00-23:30 ，在下次就是 23:00-05:30 ，在下次就是 05:00-1

20、1:30 ，如此循環(huán)。但是如果設(shè)置了 Lower Limit 和 Higher Limit 之后，請記得在 BW 中使用 DSO 來處理數(shù)據(jù)。1. 如何在query 中把默認(rèn)的轉(zhuǎn)換匯率改成期末匯率?在query中默認(rèn)的匯率轉(zhuǎn)換類型都是“ M，但現(xiàn)在我需要把一個報表的轉(zhuǎn)換匯率改成期末匯率，即匯率類型為“V”.該如何解決這個問題 ?在 RSCUR 中創(chuàng)建新的貨幣轉(zhuǎn)換類型就可以了，不過 3.5 版本中事務(wù)代碼為 rrc1.1. 大家都知道從 dso 到 cube 進(jìn)行增量抽取數(shù)據(jù)時 , 只有未被抽入 cube 的那部分增量數(shù)據(jù)才會進(jìn)入 cube. 而系統(tǒng)具體是怎么從 change log 中判斷出那

21、部分增量數(shù)據(jù)的 ? 具體通過那些表 , 那位給 講解一下 .每次 DSO 數(shù)據(jù)進(jìn)行激活更新時，都會在 change log 表產(chǎn)生一個 request ，這個 request 對應(yīng) 這次請求發(fā)生改變的所有記錄，如果是新記錄， change log table 中的 recordmode = N, 如果 是更改，那么會產(chǎn)生 2 條記錄，一條 recordmode = X 代表修改前，另外一條 recordmode = 表示修改后。往 cube 上 delta 更新的時候，就是靠這些來獲取變化量的，新產(chǎn)生的 request 中的那些記錄。1. 1. Promotion detail information 如何在 BW 中取得？4. 在 datasource2LIS_03_BF已經(jīng) daily update 到 0ic_c03的情況下，在 R3 中用rsa3 發(fā)現(xiàn) 2LIS_03_UM有很多重復(fù)記錄，該如何做使得該datasource 中的數(shù)正常？5. masterdata 從 R3 到 BW 是不是都 full load ？ LocationProductinfoo