How to monitor on a compression-process?

[marco_simon2]

Hi specialists,

I'd like to know how I can keep an eye on the status of a compression-process.

I need to compress aprox. 800 requests and would like to monitor the proceeding.

So far I realized that there is no kind of process-bar in the RSA1 Cube-management. Even worse - while the the compression is running, cube-management isn't possible at all because calling the cube-management ends up in an timeout and dump because the compression locks the E/F-Tables exclusively.

Same is for SM16 - I've no chace to check how many records already have been inserted into the E-table.

All I can do is monitoring the process in SM50 - but that doesn't give me any hint about the status of the processing.

Perhaps you'd like to give a guess how long it will last until 800 requests (and 70 Mio records) got compressed. Hint: It's more than 12 hours at least.

Edited by: Marco Simon on Apr 28, 2008 9:10 AM

[Former Member · Accepted solution]

Hi Marco,

Perhaps you can try to monitor the compression job via SM37? A background job is scheduled when you kick off the compression. Furthermore, there's a log being generated as the job runs.

Hope this helps.

Regards,

LP

[marco_simon2 · Accepted solution]

Hi LLP,

thanks for your reply.

Basicaly this is a good idea - but the hatch ist:

The compression doesn't write any intermediate-state information to the batch-log.

Only at the very beginning and at the very end of the compression-process some log-entries are written.

Have a look at this out-take:

27.04.2008 16:11:43 Request '102.175'; DTA 'ZCO_PA01'; Action 'C'; Mit Dialog 'X'

27.04.2008 16:11:43 Verlasse RSM1_CHECK_DM_GOT_REQUEST in Zeile 70; Req_State ''

27.04.2008 16:11:43 FB RSM1_CHECK_DM_GOT_REQUEST aufgerufen von PRG RSSM_PROCESS_COMPRESS; Zeile 000200

27.04.2008 16:11:43 Request '102.358'; DTA 'ZCO_PA01'; Action 'C'; Mit Dialog 'X'

27.04.2008 16:11:43 Verlasse RSM1_CHECK_DM_GOT_REQUEST in Zeile 70; Req_State ''

28.04.2008 20:28:52 InfoCube ZCO_PA01 erfolgreich komprimiert bis Request 102.358

28.04.2008 20:28:52 Verdichten von InfoCube ZCO_PA01 bis Request 102358

28.04.2008 20:28:52 Massensinsert von Bewegungen ausgeführt (5966085 Datensätze)

28.04.2008 20:28:52 P-Dimid 6591 aus Tabelle /BIC/DZCO_PA01P (InfoCube ZCO_PA01) gelöscht

28.04.2008 20:28:52 Request 12637 wurde korrekt verdichtet

28.04.2008 20:28:52 Massensinsert von Bewegungen ausgeführt (6896112 Datensätze)

28.04.2008 20:28:52 P-Dimid 6592 aus Tabelle /BIC/DZCO_PA01P (InfoCube ZCO_PA01) gelöscht

28.04.2008 20:28:52 Request 12701 wurde korrekt verdichtet

28.04.2008 20:28:52 Massenupdate von Bewegungen ausgeführt (00052240 Datensätze)

As you can see, there's a big gap between 27.04. 16:11 (that's aprox. the starting time!) and 28.04. 20:28 (which is aprox. the end of the compression-process) in which no log-entries have been written.

FYI: 65 Mio records in 800 requests need aprox. 28 hours for compression.

In the meanwhile I figured out an different way: During the compression the F/E-tables aren't readable - but the Dim-tables are! From time to time you can monitor that the requests got deleted from the Dim-(P)-table, which gives you some idea of the processing-time. The number of records in that dimensions is targeting 1 till the end of the compression-process.

Another idea would be, directly to write the records to the E-Tables (without the intermediate-step in the F-table+compression). Is that possible in any kind?

[marco_simon2]

Thread seems to be dead - so I'm closing.

[Former Member]

Dear Marco,

You can monitor teh compression job in SM37. The job name starts with BI_COMP*.

Get teh PID from SM37 an dcheck for that job in SM50.

Hope this helps.

-RajNi.