The object CRUD stats support in promon is rudimentary at best. Better options: install
ProTop and/or roll your own code. Both require you to have set the -tablerangesize and -indexrangesize DB startup parameters appropriately. They determine the number of records in the _TableStat, _IndexStat, _UserTableStat, and _UserIndexStat virtual system tables (VSTs). Both promon and ProTop provide statistics about record locks.
Yes, you can export CRUD data, as the VSTs function programmatically like other tables. This is a quick way to find out if you have rapid readers or possible bracketing issues in your code.
The _TableStat/_IndexStat tables contain data from the start of the DB, for as many objects as are specified by the startup params mentioned above. Well, technically the params define the upper range of the object numbers, which isn't always the same as the number of objects. For example you might have 100 tables but the highest table number is 120. In that case you would want -tablerangesize of at least 120 to get stats on all your tables. I typically set them a bit higher than is necessary, to leave room in case schema changes are made online. Also, the stats can be zeroed out either programmatically or with the (undocumented) proutil zerostats qualifier.
The _UserTableStat/_UserIndexStat tables contain one record per object per user, but the data only persists for as long as the user is connected. So the sum of their stats won't add up to the sum of the stats in _TableStat/_IndexStat. They are very useful, once you see that a given table or index is very "hot", for determining who is hitting them the most.
In terms of tracking data by program it requires a little more work and you need to be able to modify the code. You can write a program that grabs the CRUD stats from the _User* VSTs into a temp-table, and call that at the beginning of your program to be monitored. Then call it again at the end and calculate the deltas. One of our devs made a class for tracking CRUD stats, and he can invoke it by setting a debug flag and spit out stats to the client log.
One last point: if you think about writing code to read the contents of _Lock, think again. There be dragons ahead.
