Posts made by Rob Fitzpatrick
RE: ProTop Version 3.141 Crashs but F3 makes it work
I'm seeing this thread late, but in case you haven't seen it yet, it looks like the carriage returns were stripped from the original post. You can see the rest if you scroll to the right. This is the relevant bit.
--> checkDBX lib/getdba.p at line 712 (/u1/pulse/protop/lib/getdba.r) lib/ getdba.p at line 2609 (/u1/pulse/protop/lib/getdba.r) lib/vstlib.p at line 648 (/u1/pulse/protop/lib/vstlib.r) protop.p at line 1550 (/u1/pulse/protop/protop.r)
Web portal | General Info | Connections
I'm looking at the numbers from a client site and they don't make sense to me. At a given time stamp today, I see the following user connection counts:
I know this client has self-service users. I believe that most if not all of those 30 batch users are also self-service. Looking at historical data, most of the time this database shows zero self-service users, with occasional spikes of 1.
What criteria are used to determine that a client is self-service?
It seems the dashboard layout changed recently.
I am looking at "Main Dashboard" for a monitored database. I have the following panes:
- Latest Status (13 panels)
- a new unlabelled one that says "CPU: Unknown • Memory: Unknown • OS: Unknown"
- General info (3 panels)
- Database I/O (3 panels)
- Transactions & Locks (3 panels)
- Record activity (3 panels)
- Network metrics (3 panels)
- Async Writers Statistics (3 panels)
There used to be panes for BI and AI info. Have they been relocated? Will they be returning?
SQL Servers are double-counted in 3.141x
case _Connect-type: ... when "sqsv" then tt_Dashboard.con_sqlServ = tt_Dashboard.con_sqlServ + 1. ... end. //case if _Connect-type begins "SQSV" then tt_Dashboard.con_SQLServ = tt_Dashboard.con_SQLServ + 1.
This may also be in previous versions; I haven't checked.
RE: 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.
Alert re lkHWM near lkTableSize
Maybe this belongs in "Roadmap" rather than "Using", but anyway...
Looking at alert.cfg:
# # Metric Type Compare Target Sensitivity Notify Message Action # ====== ==== ======= ====== =========== ====== ==================== ======================= # LogRd num > 100000 3:5 Always "Hit Ratio &1 &2 &3" alert-message,alert-log # # Metric The ui-det name of the field being monitored. # # Type Data type -- char or num (string or numeric). # # Compare Operator -- >, <, =, <>, <=, >= # # Target The threshold value of the metric to be tested.
Since it isn't stated explicitly, does "Target" have to be a constant? Could it be another metric of the same data type as "Metric"? Or an expression on constants or metrics (e.g. lkHWM * 0.8)?
Use case: let's say I want to configure an alert to fire when the lock HWM is getting close to -L, and have it work regardless of the value of -L, which could possibly vary over time or from one DB to another. Is that possible? Or do I just need to decide which number (say, 7000) I care about and configure it to alert when lkHWM > 7000?
Food for thought: the alerting mechanism would become more powerful if the target values could be dynamic in some way. Maybe passed to the back end via the API.