Delta Queue Diagnosis  |
|
Many times we come across situation where there may be inconsistencies in the delta queue. To check these we can use a diagnostic tool. The report is explained in detail here.
RSC1_DIAGNOSIS Program is Diagnosis Tool for BW Delta Queue
How to use this report?
Execute the report RSC1_DIAGNOSIS from SE38/SA38, With datasource and destination details.
Use
With the RSC1_DIAGNOSIS check program, the most important information about the status and condition of the delta queue is issued for a specific DataSource.
Output
You get the following details once the report is executed
- General information about datasource and version.
- Meta data of Datasource and Generated objects for the datasource
- ROOSPRMSC table details of datasource like GETID and GOTID
- ARFCSSTATE Status
- TRFCQOUT Status
- Records check with Recorded status
- Inconsistencies in delta management tables
- Error details if available.
Let see the output format of the report.
How to analyze?
Before analyzing this output we need to know some important tables and concepts. Let us see
The delta management tables
DeltaQueue Management Tables : RSA7
Tables
ROOSPRMSC : Control Parameter Per DataSource Channel
ROOSPRMSF : Control Parameters Per DataSource
TRFCQOUT : tRFC Queue Description (Outbound Queue)
ARFCSSTATE : Description of ARFC Call Status (Send)
ARFCSDATA : ARFC Call Data (Callers)
The delta queue is constructed of three qRFC tables namely ARFCSDATA which has the data and AFRCSSTATE, TRFCQOUT which is to control dataflow to BI systems.
Now we need to know about TID (Transaction ID). You can see two things GETTID and GOTTID. Now we will see what those are.
GETTID and GOTTID can be seen in table ROOSPRMSC.
GETTID: Delta Queue, Pointer to Maximum Booked Records in BW (i.e.) this refers
<address> to The last but one delta TID</address><address> </address><address>GOTTID: Delta Queue, Pointer to Maximum Extracted Record I (i.e.) this refers to the </address><address> Last delta TID that has reached BW. (Used in case of repeat delta)</address>System will delete the LUW'S greater than GETTID and less than or equal to GOTTID. This is because delta queue have last but one delta and loaded delta only.
Now we will see about the TID in detail
TID = ARFCIPID+ ARFCPID+ ARFCTIME+ ARFCTIDCNT field content.
All the four fields can be seen in the table ARFCSSTATE.
<address>ARFCIPID : IP Address</address><address>ARFCPID : Process ID.</address><address>ARFCTIME : UTC time stamp since 1970.</address><address>ARFCTIDCNT : Current number</address>To know how this is split I am taking the GETTID
GETTID = 0A10B02B0A603EB2C2530020
This is separated like this ( 8 + 4 + 8 + 4 ) and it is sent to the four table.
GETTID : 0A10B02B 0A60 3EB2C253 0020
<address>ARFCIPID = 0A10B02B</address><address>ARFCPID = 0A60</address><address>ARFCTIME = 3EB2C253</address><address>ARFCTIDCNT = 0020</address>Give this as selection in table ARFCSSTATE.Here you can find the details of the TID.
Here you find details of TID.
Now we move on to the output of the report.
How to get the generated program?
20001115174832 = Time of generation
/BI0/QI0HR_PT_20001 = Generated extract structure
E8VDVBZO2CTULUAENO66537BO = Generated program
But to display the generated program you need to add "GP" to the prefix of the generated program and can be seen from SE38.
Adding prefix ‘GP' = GPE8VDVBZO2CTULUAENO66537BO
How to check details in STATUS ARFCSSTATE?
The output displays an analysis of the ARFCSSTATE status in the form
STATUS READ 100 times
<address>LOW <Date> <Time> <TID> <SID-CLNT></address><address>HIGH <Date> <Time> <TID> <SID-CLNT></address>STATUS RECORDED 200 times
<address>LOW <Date> <Time> <TID> <SID-CLNT></address><address>HIGH <Date> <Time> <TID> <SID-CLNT></address>READ = Repeat delta entries with TID.
RECORDED = Delta entries
Using this analysis, you can see whether there are obvious inconsistencies in the delta queue. From the above output, you can see that there are 100 LUWs with the READ status (that is, they are already loaded) and 200 LUWs with the Recorded status (that is, they still have to be loaded). For a consistent queue, however, there is only one status block for each status. That is, 1 x Read status, 1 x Recorded status. If there are several blocks for a status, then the queue is not consistent. This can occur for the problem described in note 516251.
How to check details in STATUS TRFCQOUT?
Only LUWs with STATUS READY or READ should appear in TRFCQOUT. Another status indicates an error. In addition, the GETTID and GOTTID are issued here with the relevant QCOUNT.
Status READ = Repeat delta entries with low and high TID
Status READY = Delta entries ready to be transferred.
If the text line "No Record with NOSEND = U exists" is not issued, then the problem from note 444261 has occurred.
In our case we did not get the READ and READY or RECORDED status, That's why it is showing as ‘No Entry in ARFCSSTATE' and ‘No Entry in TRFCQOUT'. But you will normally find that.
Checking Table level inconsistencies
In addition, this program lists possible inconsistencies between the TRFCQOUT and ARFCSSTATE tables.
If you see the following in the output
"Records in TRFCQOUT w/o record in ARFCSSTATE"
This shows inconsistency at table level, to correct this check the note 498484.
The records issued for this check must be deleted from the TRFCQOUT table. This allows the additional delta without reinitialization.However, if you are not certain that data was loaded correctly in BW (see note 498484) and that it was not duplicated, you should carry out a reinitialization.
