某次BW 異常處理過程
症狀:ODS無法向另外一個ODS做Delta
異常:Runtime Error RAISE_EXCEPTION
資訊:Exception condition "NOT_EXIST" raised
分析:Error analysis
A RAISE statement in the program "SAPLRSSM" raised the exception
condition "NOT_EXIST".
Since the exception was not intercepted by a superior program
in the hierarchy, processing was terminated.
Short description of exception condition:
For detailed documentation of the exception condition, use
Transaction SE37 (Function Library). You can take the called
function module from the display of active calls.
實際處理過程:
按照系統的提示,它一般會叫你通知管理員去處理,所以自己動手吧。
1. 檢視系統 Monitor----》Details
顯示資料發出正常,但是接收沒有資料
2. 在ABAP異常的情況下,Monitor的Status部分會出現Short Dump Overview,點選進去看看異常情況
3. 通過異常判斷是否是簡單的ABAP異常,如果不是,那麼將異常資訊貼到SDN,看看有沒有相似的問題
4. SDN有相似問題,但是往往解答五花八門,所以選擇方案一定要慎重,不要來一個試一個,往往會適得其反。
5. 提示使用Program:ZDMDELTAREPAIR進行修復,看了一下原始碼,這個是修復第一筆有問題的處理,而我們是已經有很多資料了,所以行不同,不過通過此程式發現了兩個非常重要的表:即Delta控制表rsdmdelta和rsbodslogstate,這兩個表儲存的資訊分別為:
rsdmdelta:Data Mart Delta Management
ICNAME | InfoCube |
RLOGSYS | Source system of the receiver |
PARTID | Request ID |
DMCOUNT | Internal number of the request containing the request |
REQUEST | Request no. of request containing the request |
這個表儲存的是進入此ODS的Request,以及啟用之後的Request,注意這裡的最後一筆會和另一個表有重大關係
rsbodslogstate:Changelog Status for ODS Object
ODSOBJECT | ODS Object |
DELTAINA | DataMart delta update status |
ACTIVE | Max. Delta Slice in Change Log |
PROCESSED_ALL | Max. delta slice that was extracted by all receivers |
PROCESSED_ONE | Max. delta slice extracted until now |
COMPR_ODS | Delta slice up to which compression has taken place |
ODSVERSION | Active version of the Operational Data Store |
這裡要對欄位進行說明一下:
Active:啟用後的最後一筆Request ID,在ODS的Management裡面可以看到,
Process_ALL:已Delta的最後一筆RequestID
Process_ONE:已Delta的最先一筆的ResutID
6.通過核對,我們發現這兩個表的資料不一致,按道理,目前此ODS的最後一筆也是我們匯入到其他DataTarget的最後一筆,而實際上,表中顯示的資料他們是不一致的,通過查詢Monitor我們發現,在表rsdmdelta裡面存的最後一筆Detal到其他地方的Request,已經被我們刪除了,所以表rsbodslogstate中存的資訊就和之前提到的表的資訊不一致,所以我們的處理方法為,刪掉rsdmdelta中的Request ID大於ODS中最大的Request ID,並且修改rsbodslogstate裡面的資料將所有的值都按照我們之前的說明進行維護
7. 重新匯入,系統匯入正常了。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/554557/viewspace-490913/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 異常處理過程
- MySQL儲存過程的異常處理方法MySql儲存過程
- MVC使用異常過濾器處理異常MVC過濾器
- BW Conversion Routine 探究以及例項操作和異常處理
- 一次資料庫異常的處理過程資料庫
- 異常篇——異常處理
- MySQL 儲存過程定義條件和異常處理MySql儲存過程
- 異常處理
- 異常處理遇到過的那些坑
- Nginx部署HTTPS服務過程與異常處理實踐NginxHTTP
- oracle 儲存過程遊標中處理並記錄異常Oracle儲存過程
- 異常-throws的方式處理異常
- 異常處理與異常函式函式
- [MySQL光速入門]017 儲存過程中的"異常處理"MySql儲存過程
- DRF 過濾排序分頁異常處理排序
- JavaScript 異常處理JavaScript
- ThinkPHP 異常處理PHP
- React 異常處理React
- 08、異常處理
- JAVA 異常處理Java
- JAVA異常處理Java
- Abp 異常處理
- oracle異常處理Oracle
- PowerShell 異常處理
- plsql異常處理SQL
- Swift 異常處理Swift
- JS異常處理JS
- app異常處理APP
- Oracle 處理異常Oracle
- MySQL異常處理MySql
- 異常處理 (轉)
- golang - 異常處理Golang
- 異常處理2
- 異常處理1
- 異常的處理
- Java 異常處理Java
- 異常處理機制(二)之異常處理與捕獲
- JSP 異常處理如何處理?JS