Symptoms:ODSUnable to do with another ODSDelta
Exception: runtime error raise_exception
Information: exception condition "not_exist" raised
Analysis: 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 CILS.
Actual processing process:
According to the system prompts, it will usually notify youManagementPersonnel to handle, so do it yourself.
1. view system monitor ---- "details
The data is normally sent, but no data is received.
2. When an ABAP exception occurs, the Status section of monitor displays the short dump overview. Click it to view the exception.
3. identify whether a simple ABAP exception is detected by exception. If not, paste the exception information to SDN to see if there are similar problems.
4. SDN has similar problems, but there are often a wide variety of answers. Therefore, you must be careful when selecting a solution. If you don't give it a try, it will often be counterproductive.
5. prompt to use program: zdmdeltarepair to fix the problem. After reading the original code, this is the first solution to solve the problem. We already have a lot of data, so the line is different, however, this program found two very important tables: the Delta control table rsdmdelta and rsbodslogstate, which store the following information:
Rsdmdelta: data mart Delta Management
Icname |
Infocube |
Rlogsys |
Source System of the specified er |
Partid |
Request ID |
Dmcount |
Internal Number of the request containing the request |
Request |
Request No. of request containing the request |
This table stores the request for accessing this ODS and the request after activation. Note that the last record here will have a major relationship with another table.
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 |
Here we will describe the field:
Active: the last request ID after activation, which can be seen in ODS management,
Process_all: The last requestid of Delta
Process_one: The first resutid of Delta
6. after checking, we found that the data of the two tables is inconsistent. By principle, the last one of the ODS tables is the last one we import to other ararget tables. In fact, the data displayed in the table is inconsistent. by querying the monitor, we found that the last detal request stored in the table rsdmdelta has been deleted, therefore, the information stored in the table rsbodslogstate is inconsistent with the information of the previously mentioned table. Therefore, we can delete the Request ID in rsdmdelta to be greater than the maximum Request ID in ODS, modify the data in rsbodslogstate to maintain all values according to our previous instructions.
7. re-import. The system import is normal.