I am passionate about using Cloud Technology.
So any questions/ feedback – please Get In Touch
Copyright © in accordance with the Copyright, Designs and Patents Act 1988. All rights reserved. You are free to use any of the content here for personal use but need permission to use it anywhere or by any means (electronic, mechanical, photocopying, recording or otherwise).
AgentDBA began as a command line. That suits one DBA on one server, but it’s a poor way to give a team a read-only advisor. The obvious fix is a web UI, which is also how you create your first real attack surface. So v1.17.0 was built around one question: How do you add a browser without handing out more power?
Continue reading“What exactly did it do on my server?” is the first question a DBA should ask about any AI agent. AgentDBA answers it from its own records: every decision in a run is written down with who made it, the reason given, what came back and how long it took.
I call it the flight recorder. This post replays one complete health check from those records, using two queries against the agent’s own database.
Read more: The flight recorder: Replaying what an AI agent did on my SQL Server
The first result set is one row per run. This run was a full health check on local server (lab).
| What the row records | This run |
|---|---|
| Trigger | health_check |
| Model | gpt-6.1-sol |
| Decisions | 6, of which the model made 4 |
| Route | db_status (HIGH) > error_log (LOW) > backup_failures (CRITICAL) > failed_jobs (HIGH) > log_file_health (MEDIUM) |
| Outcome | Concluded at CRITICAL, closed by the model |
Two columns matter before any detail. One says how many of the six decisions the model made. The other says who closed the run. An agent’s record should always separate what the AI chose from what code chose for it.
The second result set is the recorder itself: one row per decision, in order.
| Step | At (ms) | Decided by | Action | Reason given |
|---|---|---|---|---|
| 1 | 22 | code | db_status | Health check Phase A gate. |
| 2 | 67 | code | error_log | Health check Phase A gate. |
| 3 | 2,698 | LLM | backup_failures | Test whether the previously reported backup RPO breaches remain present |
| 4 | 5,253 | LLM | failed_jobs | Test whether previously disabled jobs remain disabled… |
| 5 | 8,220 | LLM | log_file_health | Check current log usage, truncation blockers, and VL… |
| 6 | 11,227 | LLM | CONCLUDE | Concluding: AREA51-AKS remains in breach of back… |
Steps 1 and 2 were not the model’s call. Every health check opens with database status and the error log, and code makes both calls. Had either come back CRITICAL, the agent would have escalated straight away with no model involved. They came back HIGH and LOW, so the run carried on.
From step 3 the model chose, inside a fixed boundary. It had three checks left, each allowed once, and then one verdict to write. It controls the order and the wording, and it has to state a reason with every action.
The five SQL checks took 413 milliseconds between them. Almost all of the other 10.8 seconds was the model deciding what to do next: four decisions at roughly two and a half to three seconds each. That split matters to a DBA.
Each tool step carries an audit_log_id. It points to one stored row holding two things: the raw resultset SQL Server returned, and the compact summary of it that the model was shown.
Here is the raw resultset stored behind step 3, audit ID 22016.
The model never sees the raw resultset. Each tool reduces its rows to a short, structured summary in ordinary code, and only that summary reaches the model. The raw rows are kept in the audit log, so a reviewer can check the agent’s conclusion against the data the tool actually read.
So a run can be followed end to end: the conclusion, every step that led to it, who decided each step, the reason the model gave, and the data behind it.
I did not want to ask a DBA to take an AI agent’s word for anything on a production server. The recorder is my answer: one row per decision, kept in your own database, readable with a SELECT.
AgentDBA has a free evaluation at agentdba.ai if interested.
When the evidence names the database, it says so. When it doesn’t, it stops.
Three databases have no recorded full backup. One backup job failed. Many tools would link the two and call it solved. This one linked the job to one database and said the cause for the other two is not determined.
Continue readingTransaction log issues are one of the quietest ways a healthy database turns into an incident. A log file fills up, backups fall behind, and by the time anyone notices it is a 2am page rather than a five-minute fix. AgentDBA runs against SQL Server and explains, in plain language, what is wrong and what to do about it. Below is a real example of it catching one.
Read more: Resolving SQL Server Transaction Log Issues EfficientlyThe check
A routine full server check comes back CRITICAL. Two databases have blown through their backup RPO entirely (recovery point objective — how much data would be lost if a restore were needed right now), and three have separate high-severity transaction log problems. Instead of a wall of undifferentiated alerts, AgentDBA groups the findings, ranks them by severity, and attaches a confidence score (51/95, “has supporting evidence, but should be reviewed”) so the DBA knows exactly how much to trust the read before acting on it.
Following the evidence
A quick follow-up question, “check tlog health,” drills straight into the detail: tlog_txn_test has an open transaction holding the log at 71.6% used, model is stuck waiting on a log backup, and tlog_vlf_test has 1,050 virtual log files — a telltale sign of small autogrow increments rather than a properly sized log. Each finding comes with a plain-English resolution, not just a symptom.
None of this is a guess. It is grounded in the same data a DBA would pull by hand — here, the log_reuse_wait_desc column straight from sys.databases, confirming the active transaction and the pending log backup wait.
Underlying evidence — verified directly against SQL Server, not inferred.
Connecting the dots
It also does this unprompted. Asking a separate question, “check database status,” pulls back the same underlying finding and says so explicitly: “you asked about db_status; this finding also draws on log_file_health, corroborated with a direct data link during the same investigation.”
Rather than treating each question as a fresh, isolated lookup, it recognises the two are related and merges the evidence — so the DBA gets one coherent picture instead of having to cross reference two separate answers themselves.
Why this matters for DBAs
Every DBA has a box like this. Sitting untouched for months. Nobody’s proud of it, nobody’s fixed it, it’s just there — a handful of small compliance gaps that never made it to the top of anyone’s list.
I pointed AgentDBA at exactly that kind of instance. Then I made it worse on purpose.
Continue reading
