Can you email to me log\dbmonitor.log and tmp\dbmonitor.debug and err please?

Regarding the specific alert: there is a lkTblPct field which I use for a similar purpose. Rather than the HWM it reflects the locks in use at that moment. In some ways that is better -- the HWM sticks around until you restart and if something went bump in the night is going to keep alerting once you hit the threshold.

Good to know, thanks.

But I'll add it to the "think about it" list 🎣

Lastly, I also (sneakily) patched the pt3.14 release a week or so ago. If your "as of" date on that is in May rather than March then you should also have the oe12 changes (but not the "4" hotkey).

That explains it, I got the error from the original March version.

I'm thinking that the statement cache should automatically appear or disappear based on whether or not it is enabled for a particular client.

That's reasonable. Though I'd still like to be able to turn the individual browses on or off. 😉

It would also be nice to have the act of turning off User Information Viewer revert to a view that is more useful, as opposed to just removing the header section. E.g. if the act of going into it cached the current list of displays (e.g. d, t, i, u), so they could be restored when u is pressed again. Food for thought.

which time didn't find a time command.

Upshot: I installed time and then syncio.sh worked as expected.

The code that sets TIMECMD may need to be a little more robust.

The default heartbeat check interval is 1200 seconds. After that, a heartbeat alert is generated. Note however that you must configure in ProTop where your heartbeat alerts are sent. They can stay in the web portal, they can be sent to an email list, or they can be sent to an emergency "pager" list (typically to your mobile phone).

The various web portals around the world also ping each other via email to make sure that outbound alerting is always working. if one of the portals fails to send emails for more than a few minutes, one of the other portals alerts our devOps team so that we can investigate.

The extensive and highly detailed documentation in the header servers as your "user guide":

You can then add a resource in the usual manner. Just use -1 for the dbname 😉

Unless you only have one db or you have one that it makes sense to tie the app servers to, you will probably want an etc/pt3agent.resource.cfg file dedicated to your app servers.

Regardless the ptInitDC needs to have AppSrvStatus added to it. If it is a stand-alone app server agent (no db) then you will probably not want any other data collectors running. Something like this (etc/pt3agent.appsrv.cfg):

As always, you can (and should) test your configuration with the ChUI ProTop before getting too crazy. If you called your resource "appsrv":

Will fire up the ChUI client. The dashboard and other db centric screens will be null but you can dismiss them if you'd like. The "@" command brings up app server data.

I blame Paul. He keeps taking time off instead of "working"...