Report SDB1FADA runs 3 hours....

[Former Member]

Hi.

I run ERP2005 (SAP ECC 6.0 with Basis 7.0) on MaxDB 7.6.00.036.

With the daily run of SAP_COLLECTOR_FOR_PERFMONITOR every day at 07:30 the report SDB1FADA is being executed - as customized in TCOLL.

The job every day runs 3 hours!!!

Also the job SAP_CCMS_MONI_BATCH_DP with report RSAL_BATCH_TOOL_DISPATCHING takes more than 2.5 hours.

Looking into SM50 I can see that the reports are reading data from system tables such as domain.tables, domain.indexes etc.

SAP sais, this is not a bug, but I should take out the report from TCOLL. This seems to me like not driving a damaged car as it is damaged instead of repairing it.

Does anybody have experienced similar performance problems with system tables under MaxDB 7.6.00.036?

Thanks for your help,

Michael

[Former Member]

Unfortunatelly the same tonight and this morning.

Clearing monitor statistics did not help.

SDB1FADA has always very poor performance on "DOMAIN.*" tables

[former_member204746]

You did not supply the OS...

anyways, if you can, you can delete old table statistics, this should help this report to run faster, especially if you are on Windows 32-bit.

[Former Member]

Oh, sorry... SUSE 10, 64 bit.

I update statistics regularly. Old ones have to be deleted?

[former_member204746]

I was not talking about database table statistics .

I am talking about things such table size statistics that DB02 keeps in its database.

These tables can become very big and may be the cause of your problem.

[Former Member]

Hi Eric,

I deleted some statistics. Table MONI now has about 4'000 entries, which should be OK... Let's wait, what will happen tomorrow morning. The strange thing is, that the report is being started 2 times a day. At 7:00 and at 20:00. At 7:00 it takes 3 hours, at 20:00 only some seconds.

To check the performance, I started a refresh of table/index analysis in DB02 which took 37 minutes.

It is report RSSQDM01. The select statement gives back entry by entry, as I can see in ST05.

hh:mm:ss.ms Dauer Programm Objektname Oper Curs Array Sätze RC Con Anweisung

18:13:49.336 49.226 RSSQDM01 domain.taX PREPARE 978 0 R/3 SELECT WHERE TYPE = 'TABLE' AND OWNER = ? ORDER BY TABLENAME

18:13:49.385 1.248.572.400 RSSQDM01 domain.taX OPEN 978 0 R/3 SELECT WHERE TYPE = 'TABLE' AND OWNER = 'SAPR3' ORDER BY TABLENAME

18:34:37.958 32 RSSQDM01 domain.taX FETCH 978 1 1 0 R/3

18:34:37.958 8 RSSQDM01 domain.taX FETCH 978 1 1 0 R/3

18:34:37.958 7 RSSQDM01 domain.taX FETCH 978 1 1 0 R/3

18:34:37.958 7 RSSQDM01 domain.taX FETCH 978 1 1 0 R/3

18:34:37.958 8 RSSQDM01 domain.taX FETCH 978 1 1 0 R/3

.

.

18:34:37.959 7 RSSQDM01 domain.taX FETCH 978 1 1 0 R/3

18:34:37.959 7 RSSQDM01 domain.taX FETCH 978 1 1 0 R/3

18:34:37.959 7 RSSQDM01 domain.taX FETCH 978 1 1 0 R/3

18:34:37.959 85.215 RSSQDM01 domain.taX FETCH 978 1 1 0 R/3

18:34:38.045 16 RSSQDM01 domain.taX FETCH 978 1 1 0 R/3

18:34:38.045 7 RSSQDM01 domain.taX FETCH 978 1 1 0 R/3

18:34:38.045 7 RSSQDM01 domain.taX FETCH 978 1 1 0 R/3

18:34:38.045 7 RSSQDM01 domain.taX FETCH 978 1 1 0 R/3

.

.

18:34:38.055 7 RSSQDM01 domain.taX FETCH 978 1 1 0 R/3

18:34:38.055 38.054 RSSQDM01 domain.taX FETCH 978 1 1 0 R/3

18:34:38.093 9 RSSQDM01 domain.taX FETCH 978 1 1 0 R/3

.

.

18:34:38.102 7 RSSQDM01 domain.taX FETCH 978 1 1 0 R/3

18:34:38.102 76.832 RSSQDM01 domain.taX FETCH 978 1 1 0 R/3

18:34:38.179 10 RSSQDM01 domain.taX FETCH 978 1 1 0 R/3

.

.

Most of the entries are delivered quite fast, but sometimes it takes longer.

And now look at this:

18:34:47.392 66.629 RSSQDM01 domain.inX PREPARE 872 0 R/3 select from domain.indexcolumns where owner = ? order by tablename, indexname

18:34:47.458 1.178.417.996 RSSQDM01 domain.inX OPEN 872 0 R/3 select from domain.indexcolumns where owner = 'SAPR3' order by tablename, indexname

18:54:25.877 33 RSSQDM01 domain.inX FETCH 872 1 1 0 R/3

18:54:25.877 9 RSSQDM01 domain.inX FETCH 872 1 1 0 R/3

18:54:25.877 8 RSSQDM01 domain.inX FETCH 872 1 1 0 R/3

18:54:25.877 8 RSSQDM01 domain.inX FETCH 872 1 1 0 R/3

The select statement is being executed at 18:34:47.458 and gives back the first entry at 18:54:25.877. After 20 minutes.

If you have a look at RSSQDM01 in debugging, you can see that the program tries to select the fields TABLENAME, OWNER, TYPE, PRIVILEGES (instead of TABLENAME, SCHEMANAME, TYPE, PRIVILEGES), as "IF kernelversion_long < '007.006.000.003'." or "IF kernelversion_long(7) < '007.006'. " is always true as field kernelversion_long is initial.

By the way, I have a hot package level of SAPKA70010 and SAPKB70010.

Maybe the problem I reported at the beginning of the thread is related to that one?