cancel
Showing results for 
Search instead for 
Did you mean: 

DDIC CL_SWNC_COLLECTOR_DB==========CP Update on SWNCMONI

tobias_gbel
Explorer
0 Kudos

Hi All,

in our productive ERP system we observer a strange behaviour since a few days:

- Serveral processes under user DDIC --> Report CL_SWNC_COLLECTOR_DB==========CP --> rapidly updating table SWNCMONI

- Massive changes on the DB leading to massive log switches and creation of numerous archive logs --> more than 400MB per minute

I already checked the following OSS:

- 1578639 --> implemented - no effect

- 1631033 --> not implemented --> does anyone have any experience with this?

Any Idea how i can get these processes under control?

Thanks in advance and kind regards,

Tobias Göbel

Accepted Solutions (1)

Accepted Solutions (1)

cris_hansen
Advisor
Advisor
0 Kudos

Hello Tobias,

Have you checked SAP note 1110822 (Workload collector: Reducing the size of aggregates)?

You can use the report SWNC_COLLECTOR_COMPRESSION from the note and select the checkboxes for:

  [VC] WEB server

         Technical name    Description in ST03N

         ACCOUNT, MANDT    Account, client

         HOST, PORT        Host name, port

         DESTINATION, PATH (*)Destination, Path/URL

         ENTRY_ID (*)      Report name, transaction name or name of the

         background job

In addition, you should also re-aggregate the data that already exists in the database for your selected profile(s). To do this select the option "Schedule background program" (at the bottom) when running the report. Then the additional report SWNC_COLLECTOR_RECOMPRESS is scheduled to run once in the background.

For further information on these statistics you can also refer to the following link:

Also interesting: SAP note 1362295 (SWNC_COLLECTOR_RECOMPRESS: No compression, short runtime).

I hope this helps,

Cris

Answers (3)

Answers (3)

tobias_gbel
Explorer
0 Kudos

Hi,

after excluding RFC* Data from the aggregation - no Short Dump came up anymore.

It seems that the amount of amount of RFC* Data to aggregate is so high, that the aggregation never finishes within a reasonable time.

We now focus on finding out where this big amount of data comes from.

Thanks again for your replys!

Tobias

tobias_gbel
Explorer
0 Kudos

Hi,

thanks for your answers so far.

I played a little bit with

ST03-->Collector and Performance DB-->Performance Monitor Collector-->Execution Time

and found out the following:

- SWNCCOLL is the report that starts the DDIC processes updating SWNCMONI. This report runs every day every hour. DDIC processes never stop updating the table SWNCMONI (at least not within an hour).

- SWNCTOTAL dumps every time it runs (7 times every day (turnus: 3 hours)) --> showing error "TSV_TNEW_PAGE_ALLOC_FAILED"

I already checked OSS 1578639 in this context - implementation without success.

Concerning OSS 1110822:

After checking all the Boxes for RFC* data aggegration (i.e. RFC Client Profile, RFC Client Destination Profile, RFC Server Profile and RFC Server Destination Profile) the amount of updates to SWNCMONI reduced rapidly. Please note that i had to kill the ddic processes and wait for the next runt of SWNCCOLL for the changes to take effect.

Still the DDIC processes that start with SWNCCOLL take almost half an hour to finish. And still i do not know, why the aggregation of data results in so many update statements.

:  Our Basis release in the corresponding system is NW 702 level 0012

Thanks again,

Regards,

Tobias Göbel

0 Kudos

Are you still getting the short dump or is it already solved after change the aggregation of some profiles?

If still the dump, you can check what is the profile responsible to trigger the biggest amount of data and can aggregate the correct profile.

You also can reduce the change the aggregation period for each profile under

collector and parformance DB

Workload Collector Database

- Control

Clebio

0 Kudos

Are you getting any kind of short dump?

This probably is some report started by the job SAP_COLLECTOR_FOR_PERFMONITOR.

This job start too many reports as per TCOLL table.

If you go to ST03

Collector and Performance DB

Performance Monitor Collector

Log

you do find the execution times of these reports. Try to pinpoint what is the report responsible by this long executions (maybe the long time report).

I do not think that the note 1578639 will help in this first moment if you are not getting the short dump. For sure that reduce the size of aggregation could help to reduce the amount of data. see also 1110822.

Anyway, after pinpoint the responsible report you can find further details (corrections) about this report.

I am not sure what is your BASIS release, but you also can check the content of TCOLL table in order to see if only the correct reports are scheduled. See for example note 966309.

Check also if all reports are with the correct times in TCOLL.

Regards

Clebio Dossa