Rob is correct, and ProTop already has the equivalent alarm: it's called the heartbeat. If monitoring is NOT running OK for any given monitored resource, the web portal generates an alert saying "HEY! I haven't heard anything from the ProTop agent for siteName.ResourceName for the past x minutes!!". This is much more interesting than getting an hourly or daily "Everything is OK!" email as you may not notice if you miss one or two or five.

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.

@tom said in Configure the User Information Viewer:

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.

That didn't take long!

Thanks for the tip, I'll look into it 👀

@tom said in Alert re lkHWM near lkTableSize:

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.

As Paul says every block with data in it must be read - even for an incremental backup. Which is why an incremental backup takes about as long to run as a full backup.

-Bp 10 helps to prevent the entire -B buffer pool getting flushed as a result of a backup running and the follow-on impact that that will have to the hit ratio. During the backup itself though you will still almost certainly see a poor hit ratio.

Done.

Got it. Fixed in patch 01.

I dunno, you're a pretty shady character...

Yes, it's true.

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

etc/appsrv.cfg is your friend

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

# appsrv.cfg # # type name "query command" # # - names (column 2) are case sensitive! # - the "name" field will be substituted for "&1" when the command is run # # i.e. # ws ws1 "wtbman -i &1 -query 2>&&1" # # admin proadsv "proadsv -q 2>&&1" # admin server does not actually use the name field -- but we need a name entry # ns NS1 "nsman -i &1 -q 2>&&1" # apsv asbroker1 "asbman -i &1 -q 2>&&1" # ws wsbroker1 "wtbman -i &1 -q 2>&&1"

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):

# pt3agent.cfg # # you must restart after changes -- this cfg file is not monitored # # pt3agent.friendlyName.cfg will override this config for a friendlyName instance of pt3agent # ptInitDC "AppSrvStatus"

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

protop 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.

It is ugly and annoying but it should be harmless.

The issue has been fixed in the next release.

Something like that will probably occur. I need to start mucking about with oe12 now that it is actually available.

Portal v4 has a lot of enhancements to stuff like this. Real Soon Now.

I think I probably need more visuals. I'm not forming a picture in my head of what you are describing.

This is almost always for one of these reasons:

The -tablerangesize or -indexrangesize parameters are not set to cover the active tables & indexes. The ChUI "T" command will show you what values are recommended and create a sample .pf file for you in the ProTop temp directory. Unfortunately you cannot change these values online. A db restart will be needed.

The activity on the tables and indexes does not meet the threshold criteria. You can review the thresholds on the portal "Resource" screen. For development and test environments you probably want very low values. For Production you want higher values -- a chart with 2,000 objects on it will be unusable (that is why we have a minimum activity threshold).

You should also verify that etc/pt3agent*.cfg has the TableActivity and IndexActivity data collectors enabled. If they are missing from ptInitDC then that data is not being sent to the portal.

if ( not _Connect-device matches "*batch*" ) and _connect-batch <> "yes" then tt_Dashboard.con_self = tt_Dashboard.con_self + 1.

So "self" is counted for non-batch self-service connections. It (mostly) equates to local interactive connections.

Somehow I suspect that you are going to suggest that that might be sub-optimal 😉

tick, tick, tick...

The time for pre-release feedback is drawing to a close!