Hi Samuli,
You could write a custom script that takes snapshots of the system (processes, active statements, space usage, etc) at regular intervals and then another script to summarize the snapshots. Should be easy enough for example with perl.
Hm, that probably would be a bit much of an effort (as the main issue has gone after extending / reorganizing the data volumes). We still have some hickups in one application, but that seems to be a logical issue within the application (which we are not maintaining, we just run the AS java). So I am willing to analyse something with easy-to-be-used tools (for example, I still check some long running statements and check the existence of meaningful indexes), but to develop something just to show the original developers where they are going a bad way... no... ;-)
I assume your analysis is correct that the growth happens in the temporary area since it is released if the database is restarted.
Yeah, that's no question in the end; you can monitor the temp area immediately with the old and new tools.
Could it be that one of the monitors was switched on 12 days ago, causing the problem? With MaxDB 7.5 you shouldn't switch on any of the monitors if having patch level lower than 35, see SAP note 1098561 for details.
No, first the problem came up (for all app's and in the end for the complete server), then we started the analysis, not vice versa :-) Anyhow, this is a valid point, as we are really running patch level 32 (I know, I know, not my decision...).
Thanks for the hints anyway. I really like MaxDB and all support tools SAP offers around, but this concrete thing could have been handled better... Maybe in the future... :-)
Thanks & best regards
Detlev