G
George Potemkin
Guest
Dealing with the incidents on the customer’s sides the hardest part for me is to get from a customer the right statistics gathered at the right time. It was a main reason why I wrote my dbmon script. I’m very glad that Progress is going to give us new solution. I personally would like for Progress database to have an ability to store in memory a few (let’s say 10) most recent snapshots of db statistics. Sampling interval could be as short as possible - up to one second. These snapshots could be dumped automatically during the certain incidents including an abnormal db shutdown or by the requests from the DBAs. We can’t monitor db statistics with such short intervals in 24/7 mode – it would be a huge volume of information to store and to analyze. Also the frequent reads of VSTs are costly compared to a copying the whole area(s) with statistics counters stored in shared memory - time to read all needed VSTs can be about a second on a database with large number of objects or users. But to analyze the incidents we need the most detailed statistics for a short time interval preceding the incident. And, of course, we currently can’t gather the statistics when an abnormal shutdown is already initiated. By the way the low-hanging fruit, IMHO, is to add the USR1 signal as a first signal that a db broker sends to the connected sessions during an abnormal shutdown. At least with an option to turn it on/off. The analysis of statistics is a rather simple task. If Progress will introduce a standard format for the dumped db statistics someone sooner or later will write a tool that will automatically highlight the issues in the gathered data – like a spellchecker does it with the texts.
Continue reading...
Continue reading...