ODS Activation queue not getting cleared after activation

Question

Dear Experts,
I have a strange situation in my BI 7.0 system. Within one ODS I have an activation queue (new data table) of around 34Gb in size. As far as I know, this table should be empty, because all requests are activated correctly.
Every night a delta is loaded into the ODS and there are no errors. But still the data remains also in the activation queue.
In fact: All requests since the initialization still reside in the activation queue.
My question is: Can I savely delete all data from the activation queue?
It is only occuring for one ODS, all other ODS'es do clear the activation queue succesfully.
Here is a part of the log for the last delta load, which might lead to the actual problem:
07.10.2008 00:07:39 Program RSBATCH_EXECUTE_PROZESS successfully scheduled as job BIBCTL_D48V1ORBHRBOPNPN3S8I1RUEC with ID 00073900        RSM            703
07.10.2008 00:07:40 Parallel processes (for Activation); 000003                                                                       RSODSO_TOOLS        018
07.10.2008 00:07:40 Timeout for parallel process (for Activation): 000600                                                             RSODSO_TOOLS        019
07.10.2008 00:07:40 Package size (for Activation): 020000                                                                             RSODSO_TOOLS        020
07.10.2008 00:07:40 Task handling (for Activation): Backgr Process                                                                    RSODSO_TOOLS        021
07.10.2008 00:07:40 Server group (for Activation): No Server Group Configured                                                         RSODSO_TOOLS        022
07.10.2008 00:07:40 Parallel processes (for SID Gener.); 000003                                                                       RSODSO_TOOLS        018
07.10.2008 00:07:40 Timeout for parallel process (for SID Gener.): 000600                                                             RSODSO_TOOLS        019
07.10.2008 00:07:40 Package size (for SID Gener.): 020000                                                                             RSODSO_TOOLS        020
07.10.2008 00:07:40 Task handling (for SID Gener.): Backgr Process                                                                    RSODSO_TOOLS        021
07.10.2008 00:07:40 Server group (for SID Gener.): No Server Group Configured                                                         RSODSO_TOOLS        022
07.10.2008 00:07:40 Activation started (process is running under user OLTP_RFC)                                                     RSODSO_PROCESSING     029
07.10.2008 00:07:40 All data fields updated in mode "overwrite"                                                                       RSODSO_TOOLS        023
07.10.2008 00:07:40 Process 000001 for determining SID for InfoObject 0STORNO started                                               RSODSO_PROCESSING     045
Thanks,
Steven Groot

Answer 1

Dear Experts,
Finally I got some input from SAP about this issue, which resolved the error.
Within the table RSODSACTREQ, there was an entry with an errorstatus. This entry was the cause of the activation queuenot being deleted.
As quoted by SAP in response to my OSS Message:
The RSODSACTREQ table records requests which have been activated.
However, sometimes this table can contain requests which have actually
already been deleted.
The timestamp for this request (REQU_ELCCK3YPESODU19NXQH9BQZ70) is the
19th of Feb 07, yet there is no such request in the ODS (first request
is the 20.02.2007).
Such a request, which has an entry in RSODSACTREQ with status "2"
will prevent deletion of the new data table.
If the request does not exist anymore in the change log table and there
is no data for the request in the active table, then you can resolve
this inconsistency by deleting the entries for this request from table
RSODSACTREQ, and then the activation queue will be truncated with the
next successful activation.
Maybe you can use this information if it is applicable to your situation as well.
Regards,
Steven Groot