"Startup Parameters" screen in promon V11.7 contains the lines:
Diagnostic directory (-diagDir): Not Enabled
Diagnostic events value (-diagEvent): LockTable:0,BiThold:0,SysErr:0
Diagnostic event level (-diagEvtLevel): 0
Diagnostic field separator (-diagFS): ' '
Diagnostic data format (-diagFormat): csv
Diagnostic pause length (-diagPause): 0
Diagnostic prefix value (-diagPrefix): diagEvent_
Diagnostic procedure (-diagProc): Not Enabled
What are the "Diagnostic events"?
How can we use them?
In 11.7.0, these are only available as a Tech Preview and have been explained to certain customers for previewing and feedback purposes and not meant for production and that is why they were not documented. The DB Diagnostics will be released with 11.7.1 along with the appropriate documentation.
In a nutshell, this provides the ability to dump certain chosen VST information in various formats as well as perform certain actions at the time of an event/incident as chosen by the DBA. Three such events will be supported in the first release: lock table overflow, bi space exhaustion and system error with the option to always report when the event occurs or to only report if the action is fatal to the database.
I will be doing a presentation on this at the America PUG Challenge this year. Hope to see you there!
Richard, thanks for explanation! Diagnostic events suspiciously look like the first steps to implement the Artificial Intelligence in Progress. DBAs should be scared, should not they? ;-)
of course not. this is a tool that gives more information to DBA’s.
anyhow, what we need is not artificial intelligence but /real/ intelligence.
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.
Update: Progress can rarefy the recent statistics snapshots. I mean it can store (and dump when needed) only the snapshots for 1, 2, 4, 8, …, 128 seconds ago and, of course, the statistics since db startup. What else we need to analyze the incidents or just the current performance?
470: Database Diagnostics - Richard Banville
DB Diagnostics is a very cool new feature. Looking forward to using it (though hopefully not too often). ;)
Thanks engine crew! :)