How to Reset VST statistics in 9.1E
- Thread starter kdaniel
- Start date
TomBascom
Curmudgeon
The simplest method is to restart the db 
With v9 there is no other general purpose method.
Happily the one exception is _tablestats (& _indexstats). If you change the _statbase._tablebase field to a range higher than that currently being viewed and then change it back you will obtain the effect of zeroing out the _tablestats. (_indexbase will do the same for _indexstats).
Depending on why you need this you might also find ProTop useful. It has table and index statistic monitoring built in to it already.
With v9 there is no other general purpose method.
Happily the one exception is _tablestats (& _indexstats). If you change the _statbase._tablebase field to a range higher than that currently being viewed and then change it back you will obtain the effect of zeroing out the _tablestats. (_indexbase will do the same for _indexstats).
Depending on why you need this you might also find ProTop useful. It has table and index statistic monitoring built in to it already.
I don't think restarting the db clears out the _tablestat. We restart the db every weekend for normal maintenance but our abs_mstr table is showing 1.2 billion reads. I can't believe that would be for just one week.
I've taken a look at ProTop and it does look good. However, I will probably use it as a start for logging the data into a side db. We also have ProMonitor and Fathom so I might not need to go that route.
thanks,
Kevin
I've taken a look at ProTop and it does look good. However, I will probably use it as a start for logging the data into a side db. We also have ProMonitor and Fathom so I might not need to go that route.
thanks,
Kevin
TomBascom
Curmudgeon
Restarting the db absolutely does clear the counters.
1.2 billion a week isn't impossible. It is, in fact, all too common. I've had customers with tables that were read that many times in an hour. (Sometimes on tables with just a few dozen records in them.) It is generally a sign of what is known as a rapid reader. Usually it is a serious programming problem -- often due to mistakes regarding index selection.
1.2 billion a week isn't impossible. It is, in fact, all too common. I've had customers with tables that were read that many times in an hour. (Sometimes on tables with just a few dozen records in them.) It is generally a sign of what is known as a rapid reader. Usually it is a serious programming problem -- often due to mistakes regarding index selection.
TomBascom
Curmudgeon
Thanks!
You can certainly do that. Or you could save yourself the trouble and become a DBAppraise subscriber:
DBAppraise
Userid: demo
Password: dbappraise
You might find the Table Stats report in the lower left of the metrics tab interesting.
TomBascom
Curmudgeon
There is no way to get the information that you need directly from the VSTs.
10.1B supports _userTableStat which tells you which user is responsible but you still don't know what that user is running (and it isn't always just one user).
10.1C is supposed to have a new VST that will tell you what a session is executing. That combined with _userTableStat should finally close the loop on diagnosing these sorts of problems. But we aren't there quite yet...
10.1B supports _userTableStat which tells you which user is responsible but you still don't know what that user is running (and it isn't always just one user).
10.1C is supposed to have a new VST that will tell you what a session is executing. That combined with _userTableStat should finally close the loop on diagnosing these sorts of problems. But we aren't there quite yet...