Solution Overview — For DBAs
You are the person who gets called when an application team says the database is slow. Most of your day is spent constructing, by hand, the picture iWatch already has — what ran, in which session, how long it took, against which plan. iWatch puts that picture in front of you, indexed and searchable, for every database you own.
What changes day-to-day
| Task | Before iWatch | With iWatch |
|---|---|---|
| Find the worst SQL in the last hour | Trigger an event session, wait, parse, correlate against application logs. | One SQL query against the repository. Ranked by total elapsed time, not average. |
| Reproduce a user complaint | Ask the user for a screenshot of the URL, ask the app team for the corresponding session id, trawl logs. | Jump to the timestamp and the user’s session in the repository. Read off every statement, in order. |
| Track a regression after a release | Hope someone captured a baseline. Try to remember what last week looked like. | Compare the same SQL template, side by side, across release tags — the timeline is already in the repository. |
| Catch a bind-value plan flip | Suspect it; struggle to prove it. | Filter by template and bind shape. The correlation is in the data. |
| Hand evidence to the application team | Screenshots of monitoring tools and a verbal account. | An exported result set, with the exact statements, bind values, and timings. |
Overhead, honestly
The single objection you have heard a hundred times is “but we can’t put another agent on production.” iWatch is not an agent. It does not run inside the database. It does not connect as a client. In the co-resident install it is a separate process on the host using ~1–2% of one CPU core; in the separate-host install the database host sees zero additional load.
This is materially less than the cost of a server-side trace, an extended-events session, or a database-level audit trail, all of which routinely cost 10–15% on the database host and which become more expensive the more detail you ask for.
What you can stop doing
- Reactively enabling and disabling server-side traces every time a user complains.
- Asking the application team to add logging to find out what the database saw.
- Maintaining a wallet of bespoke SQL scripts against system tables that change between releases.
- Apologising for not knowing what happened on the database five minutes after it happened.
Multi-database estates
If you carry an Informix system and a SQL Server system, or a Db2 system and a PostgreSQL system, you are presently learning two performance-tooling vocabularies. iWatch gives you one vocabulary and one repository for both. The same query that ranks the top templates by total elapsed time on the Informix side ranks them on the SQL Server side. The same query that reproduces the user’s session does so against either.
Next step
Request a trial against a non-production instance. Half an hour to install, half an hour to learn the schema, then evaluate it against this week’s real incidents. Email support.info@oninit.com.