Re: Interpretation of Statspack reports

This is really interesting :) I hear of such design for a first time. Each table in it's own tablespace, interesting. I wonder who could come up with such an idea?? :) It's no doubt you would have problems with such a system... by the way, what problems do you have exactly? It seems you forgot to tell us.

Privyet Andrei,

I'm not sure what reasoning is behind the one-to-one relation of tables and tablespaces. It isn't very relevant for the problems encountered with the database, but i wanted to give you a taste of the level of expertise that this application has been built with. Seeing 900 tablespaces is most promising for further finds if you're looking for obvious wrongs in the databasedesign.

The application owner assured me that the database is growing way beyond the prognoses, and that the loading cannot be the cause - please check out what this database is doing. So i ran a statspack to return the top-sql, the loading is indeed the main process.

But i'm just curious about the report and i am looking into it in order to increase my knowledge on this topic. ( And, i was secretly hoping to find more interesting design features). It's hard to find consistent and at the same time advanced information about this reportreading. Thanks for pointing out that the CPU time needed to be divided over the CPU's - i didn't think about that. And thanks about the link, i'll read it :)

H.
PS I didn't want to present the whole report burb of information because there is not yet an urgent problem at hand, i don't want to burden everyone here with me playing around. ;-) Received on Wed Aug 22 2007 - 09:24:12 CDT