> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Microsoft SQL Server on Vortex IQ
> Monitor Microsoft SQL Server health, cost and reliability signals, and catch incidents and runaway spend early.
Monitor Microsoft SQL Server health, cost and reliability signals, and catch incidents and runaway spend early.
[Connect or manage this source](https://app.vortexiq.ai/workbench/settings/sources) · [How connecting works](/integrations/connector-catalogue) · [Create a workflow](https://app.vortexiq.ai/workbench/flows/create?connector=mssql)
performance signals
automated checks
prepared fixes
proven workflows
API operations
### What you can achieve
Capabilities are grouped around merchant outcomes, not API terminology.
Keep tracking, access and change under governed control.
Monitor orders, fulfilment, delivery and settlement.
Find storefront, speed, accessibility and journey problems.
Find failures, leaks and risks before they cost sales.
### From connection to verified outcome
The controlled sequence every capability follows. Nothing changes a connected system without the approval step.
Authorise the source. Scopes are shown before access is granted.
Watch the signals against your own baselines, not universal defaults.
Run checks and gather evidence specific to your store.
Explain what happened, why it matters and the proposed action.
You review scope, risk and reversibility before anything changes.
Apply through governed connector operations.
Confirm the intended result and keep the receipt.
No changes are made without the configured approval policy. Read-only operations do not modify the connected system; schedules, access scopes, API usage and data handling remain governed by Vortex IQ controls.
### Monitor performance
31 performance signals. Open an outcome to see its signals and how each one alerts. Read-only operations do not modify the connected system.
| Signal | Alert behaviour | What it tracks |
| -------------------------------------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| **AG Replica Health (state)** | Watch only | Always On AG only - synchronization\_health\_desc + synchronization\_state\_desc per replica from sys.dm\_hadr\_database\_replica\_states. |
| **AG Secondary NOT SYNCHRONIZED / Lag >10s** | Alert band 1 / 10 | Always On AG only - gated when no AG is configured. |
| **Active Sessions** | Watch only | COUNT of sys.dm\_exec\_sessions where status != 'sleeping'. |
| **Blocked Sessions** | Merchant rule | sys.dm\_exec\_requests where blocking\_session\_id != 0. Long blocking chains stall the app. |
| **Blocking Chain >30s** | Merchant rule | Alerts for Blocking Chain >30s. |
| **Connection Saturation %** | Alert band 70 / 90 | Active sessions / @@MAX\_CONNECTIONS (or Azure SQL workload-group cap). >90% = login timeouts imminent. |
| **Database Disk Usage %** | Alert band 70 / 90 | Data + log file used vs allocated from sys.dm\_db\_file\_space\_usage / sys.master\_files. Azure SQL: sys.dm\_db\_resource\_stats. |
| **Instance Uptime** | Watch only | GETDATE() - sqlserver\_start\_time from sys.dm\_os\_sys\_info. |
| **Last Log Backup (minutes ago)** | Merchant rule | FULL/BULK\_LOGGED recovery DBs only - gap in log backups grows the transaction log and shrinks the recovery window (RPO). |
| **Last Successful Backup (hours ago)** | Alert band 24 / 72 | MAX(backup\_finish\_date) from msdb.dbo.backupset per database. Azure SQL backups are automatic (PITR) - use sys.dm\_db\_log\_stats / Azure REST. |
| **Page Life Expectancy (sec)** | Merchant rule | SQL Server-distinctive - Page life expectancy counter. Sharp drop = memory pressure flushing the buffer pool. |
| **SQL Server Health Score** | Merchant rule | Composite of wait-stats, blocking, AG health, backup recency. \<70 = investigate. |
| **TempDB Space Used %** | Merchant rule | SQL Server-distinctive - sys.dm\_db\_file\_space\_usage on tempdb. Full tempdb stalls every sort/hash/version-store op server-wide. |
| Signal | Alert behaviour | What it tracks |
| --------------------------------------- | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| **Avg Query Duration (ms)** | Alert band 50 / 200 | total\_elapsed\_time / execution\_count across sys.dm\_exec\_query\_stats. p95/p99 not natively percentile - derived from per-query averages. |
| **Batch Requests / Second (live)** | Watch only | Batch Requests/sec delta from sys.dm\_os\_performance\_counters - primary throughput signal. |
| **Buffer Cache Hit Ratio %** | Alert band 95 / 80 | Buffer cache hit ratio from sys.dm\_os\_performance\_counters. Low = data being read from disk not memory. |
| **Deadlocks (last 5m)** | Alert band 0 / 5 | Number of Deadlocks/sec counter delta (sys.dm\_os\_performance\_counters) - corroborated by system\_health XEvent ring buffer. |
| **Lock Waits / Second** | Merchant rule | Lock Waits/sec from sys.dm\_os\_performance\_counters. Climbing = contention building before deadlocks appear. |
| **Missing-Index Recommendations** | Merchant rule | SQL Server-distinctive - sys.dm\_db\_missing\_index\_details + group\_stats. High avg\_user\_impact rows = index candidates. |
| **Query Error Rate %** | Alert band 0.1 / 1 | Errors/sec counter (sys.dm\_os\_performance\_counters) over batch requests. Spikes flag failing queries / app retry storms. |
| **Slow-Query Rate %** | Alert band 1 / 5 | Share of executions over the slow threshold (default 200ms) from sys.dm\_exec\_query\_stats deltas. |
| **Top 10 Slowest Queries** | Watch only | Ordered by total\_worker\_time / total\_logical\_reads from sys.dm\_exec\_query\_stats + sql\_text. |
| **Top Wait Types (signal vs resource)** | Watch only | SQL Server-distinctive - sys.dm\_os\_wait\_stats grouped by wait\_type. CXPACKET / PAGEIOLATCH / LCK\_M\_\* climbing = bottleneck. |
| Signal | Alert behaviour | What it tracks |
| ---------------------------------------------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **AG Redo Queue (KB)** | Merchant rule | Always On AG only - redo\_queue\_size from sys.dm\_hadr\_database\_replica\_states. Large backlog = secondary falling behind / failover-readiness risk. |
| **Blocking / Slow Queries During Checkout Window** | Merchant rule | Blocking / Slow Queries During Checkout Window, broken down by row. |
| **Failed Logins (24h)** | Merchant rule | Logins Failed/sec counter or error log scrape (msg 18456). Bursts = brute force or stale app credentials. |
| **SQL Connection Saturation vs Traffic Burst** | Alert band 70 / 90 | SQL Connection Saturation vs Traffic Burst, broken down by row. |
| **SQL Load Spike vs Ecom Order Rate** | Merchant rule | Description pending editorial review; the signal is live. |
| **SQL Product Table Row Count vs Ecom Catalog Size** | Merchant rule | SQL Server-distinctive XC - many merchants keep their product master in SQL Server; row-count drift vs ecom = sync failure. |
| Signal | Alert behaviour | What it tracks |
| -------------------------------------- | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **AG Secondary Lag (seconds)** | Alert band 1 / 10 | Always On AG only - estimated from redo\_queue\_size / redo\_rate or last\_commit\_time delta in sys.dm\_hadr\_database\_replica\_states. Gated when no AG is c |
| **Query Error Rate Spike (>1% in 5m)** | Alert band 0.1 / 1 | Alerts for Query Error Rate Spike (>1% in 5m). |
### Audit risks and opportunities
A fix status appears only where the action, inputs, approval, verification and recovery controls are mapped. Candidate remediations are never executable. Open a check for the detail.
**Severity** critical · **Outcome** Customer experience · **Fix status** Report only
At 90% of the connection pool in use, the database is close to refusing new connections outright. Once it does, every part of the application that needs a fresh database connection, including new customer sessions and checkout, starts failing, not just slowing down.
Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.
Reference: `DB-CAP-001`
**Severity** critical · **Outcome** Run operations · **Fix status** Report only
A database that runs out of disk stops accepting writes entirely, which for most stores means orders, inventory updates and customer records stop being saved, not just that the database gets slower. There is very little runway left at 90%.
Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.
Reference: `DB-CAP-002`
**Severity** critical · **Outcome** Run operations · **Fix status** Report only
More than 1 in 100 queries is failing right now. Depending on what those queries do, this can mean orders not saving, pages failing to load product or customer data, or background jobs silently dropping work, and a rate this high in a 5-minute window is an active incident, not background noise.
Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.
Reference: `DB-ERR-001`
**Severity** high · **Outcome** Run operations · **Fix status** Report only
If something goes wrong with this database right now, the most recent point it can be restored to is over 3 days old. Every order, customer record and inventory change since that backup would be unrecoverable in a real incident, not just delayed.
Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.
Reference: `DB-BAK-001`
**Severity** high · **Outcome** Run operations · **Fix status** Report only
Anything reading from the replica, reports, dashboards, or read traffic split off the primary for capacity, is now up to 10+ seconds stale. If the primary fails while lag is this high, the replica is also that far behind on failover, which is a bigger problem than the staleness alone.
Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.
Reference: `DB-REP-001`
**Severity** high · **Outcome** Customer experience · **Fix status** Report only
More than 1 in 20 queries is landing in the slow bucket. That is frequent enough to be a pattern, not noise, and it means a meaningful share of every page load or job that touches this database is paying the slow-query cost, not just an unlucky occasional request.
Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.
Reference: `DB-PERF-002`
**Severity** high · **Outcome** Customer experience · **Fix status** Report only
One in twenty queries against this database is taking over 200ms, sustained for at least 15 minutes, not a brief spike. Any storefront page, checkout step or order sync that depends on this database inherits that slowness directly, and a sustained p95 this high is usually already visible to customer
Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.
Reference: `DB-PERF-001`
**Severity** medium · **Outcome** Run operations · **Fix status** Report only
More than 1 in 5 reads is missing the cache and going to disk instead, which is markedly slower. This shows up as everything the database does feeling incrementally heavier, rather than as one obvious failure.
Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.
Reference: `DB-CACHE-001`
**Severity** medium · **Outcome** Protect revenue · **Fix status** Report only
A deadlock means two operations blocked each other and the database had to kill one of them; whatever that transaction was doing (placing an order, updating stock, writing a record) failed and, depending on how the application handles it, may not have been retried.
Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.
Reference: `DB-PERF-003`
#### Build your own automated fixes
Turn any finding into an automated fix with a Vortex IQ workflow: **over 13,000 read and write operations across more than 200 connectors** are available as building blocks, with approval, verification and rollback on every change.
### Automate approved work
Vortex IQ is integrated with **12 read** and **0 write** operations across msdbdbobackupsets, sydmdbfilespaceusages, sydmdbmissingindexdetails, sydmdbresourcestats, sydmexecconnections, sydmexecquerystats on Microsoft SQL Server. Combine them with anything from the **over 13,000 operations across more than 200 connectors** to automate the work in your own words.
Changes follow your configured approval policy: the target, proposed change, affected records, risk, reversibility and verification plan are shown before execution.
[Create a workflow](https://app.vortexiq.ai/workbench/flows/create?connector=mssql)
#### Ready to build your first Microsoft SQL Server workflow
Pick a trigger, add the operations above as steps, and every step that changes data pauses for your approval. Monitoring and audits are live now and can start any workflow you build.
| Resource | Read operations | Write operations |
| ------------------------- | --------------- | ---------------- |
| msdbdbobackupsets | 1 | 0 |
| sydmdbfilespaceusages | 1 | 0 |
| sydmdbmissingindexdetails | 1 | 0 |
| sydmdbresourcestats | 1 | 0 |
| sydmexecconnections | 1 | 0 |
| sydmexecquerystats | 1 | 0 |
| sydmexecrequests | 1 | 0 |
| sydmexecsessions | 1 | 0 |
Signed-in users see the full catalogue in the workflow builder, filtered to the sources they have connected.