Per anni, chi doveva generare carico su un’istanza SQL Server per un test di performance aveva un solo riferimento informale: ostress.exe, il tool scritto dal supporto Microsoft (Keith Elmore e Robert Dorr) mai distribuito ufficialmente ma passato di mano in mano tra DBA e sviluppatori .NET. Il problema è che ostress si appoggia a SQL Server Native Client, un componente che Microsoft non distribuisce più a partire da SQL Server 2022, e che su Linux non ha mai avuto cittadinanza. Microsoft ha ora rilasciato il suo sostituto ufficiale, open source: sqlsimtools.

Cos’è sqlsimtools

sqlsimtools (github.com/microsoft/sqlsimtools, licenza MIT) è in realtà una suite di tre strumenti pensati per generare, eseguire, confrontare e replayare carichi di lavoro su SQL Server e Azure SQL in modo ripetibile:

• sqlsim: il motore nativo a riga di comando, scritto in C++ sopra ODBC Driver 18. Gira su Windows (x64 e ARM64) e su Linux x64 (Ubuntu 24.04 e 26.04).
• sqlpysim: la versione Python, basata sul driver mssql-python di Microsoft. Nei benchmark pubblicati raggiunge circa un decimo del throughput di sqlsim con 50 thread concorrenti, quindi va vista più come strumento di prototipazione e scripting che come generatore di carico ad alte prestazioni.
• sqlsim Studio: un’applicazione locale, servita nel browser, per configurare visivamente un workload, eseguirlo, monitorarlo in tempo reale, confrontarlo con un run precedente e fare il replay. Al momento gira solo su Windows x64 in public preview; le altre piattaforme sono in anteprima privata su invito.

I target supportati coprono l’intero spettro Microsoft lato dati relazionali: SQL Server 2019, 2022 e 2025 on-premise, Azure SQL Database, Azure SQL Managed Instance e SQL database in Microsoft Fabric. L’autenticazione copre sia le credenziali SQL classiche sia Microsoft Entra ID, con supporto per access token, managed identity e service principal: un dettaglio non secondario per chi deve lanciare questi test da una pipeline CI/CD senza stoccare password in chiaro.

Primo avvio

I pacchetti si scaricano dalla pagina delle release del repository. Su Windows, dato che gli eseguibili non sono firmati digitalmente, Microsoft raccomanda di sbloccare l’archivio prima di estrarlo, per evitare che SmartScreen blocchi silenziosamente i binari:

Unblock-File .\sqlsimtools-<versione>-win-x64.zip

Avviare sqlsim Studio è immediato: si estrae l’archivio e si lancia l’eseguibile, che apre l’interfaccia nel browser predefinito.

.\sqlsimstudio\sqlsimstudio.exe

Il motore nativo si invoca invece da riga di comando, con una sintassi che richiama volutamente quella storica di sqlcmd/osql: -S per il server, -E per l’autenticazione integrata, -Q per la query. Un esempio tipico, contro il database di esempio AdventureWorksLT, con due thread concorrenti e una singola iterazione:

sqlsim.exe -S localhost -d AdventureWorksLT -E `
  -Q "SELECT TOP (5) Name, ListPrice
      FROM SalesLT.Product ORDER BY ListPrice DESC" `
  -n 2 -r 1

L’equivalente in sqlpysim richiede prima l’installazione delle dipendenze Python, poi usa gli stessi flag principali (con l’aggiunta di -C per accettare il certificato del server in connessioni cifrate non attendibili):

python -m pip install -r .\sqlpysim\requirements.txt
python .\sqlpysim\sqlpysim.py -S localhost -d AdventureWorksLT -E -C `
  -Q "SELECT TOP (5) Name, ListPrice
      FROM SalesLT.Product ORDER BY ListPrice DESC" `
  -n 2 -r 1

Entrambi i comandi stampano un riepilogo con driver utilizzato, numero di thread, iterazioni, risultati della query e un conteggio di esecuzioni riuscite/fallite: output pensato per essere incollato così com’è in un ticket o in un report di performance, oppure esportato in JSON per l’elaborazione automatica.

Workload misti e automazione

Oltre alla singola query da riga di comando, sqlsimtools permette di descrivere workload misti in formato JSON, eseguire replay di carichi registrati in precedenza ed esportare i risultati in JSON per confronti automatizzati prima/dopo una modifica (un indice aggiunto, una riscrittura di query, un upgrade di versione). Per il riferimento completo dei flag e dello schema JSON, il progetto rimanda alla documentazione dedicata di ciascun componente (sqlsim/sqlsim.md e sqlpysim/sqlpysim.md nel repository), non ancora linkata direttamente dalla pagina principale.

L’integrazione con GitHub Copilot

Un aspetto che distingue sqlsimtools da un classico tool da riga di comando è l’integrazione nativa con gli agenti AI da sviluppo. Il repository pubblica skill installabili per GitHub Copilot (e, secondo la documentazione, anche per Claude Code, Codex e Cursor):

copilot plugin marketplace add microsoft/sqlsimtools
copilot plugin install sqlsim@sqlsimtools
copilot plugin install sqlpysim@sqlsimtools

Una volta installata, in VS Code è disponibile l’agente sqlsimtools Workload Builder: si apre la chat di Copilot, si descrive l’esperimento in linguaggio naturale (ad esempio “confronta questa query con e senza indice su AdventureWorksLT”) e l’agente costruisce i comandi di baseline e candidato, chiedendo conferma prima di eseguire qualunque cosa contro un target reale. Vale la pena notare che le skill forniscono solo la guida: l’eseguibile sqlsim o l’ambiente Python vanno comunque installati separatamente.

sqlsimtools contro ostress.exe: cosa cambia davvero

Un avviso importante prima di adottarlo in produzione: sqlsimtools non è un prodotto Microsoft ufficiale e non è coperto da supporto commerciale Microsoft. Bug e richieste di funzionalità vanno segnalati su GitHub Issues e Discussions del repository, come per qualunque progetto open source gestito dalla community.

Prima di lanciare un test di carico: qualche buona pratica

Indipendentemente dallo strumento usato, un test di workload ripetibile e utile richiede disciplina a monte: definire in anticipo query mix, dataset, concorrenza e durata attesa; usare sempre un database di non produzione con credenziali dedicate, verificando il target prima di ogni esecuzione; eseguire prima la baseline invariata, poi applicare una singola modifica alla volta e ripetere lo stesso run, conservando anche gli esiti dei run falliti; registrare versione dello schema, del tool e del driver insieme alla definizione del workload, così da poter riprodurre esattamente lo stesso test mesi dopo. Sono gli stessi principi che si applicavano con ostress, ma che il formato JSON e l’export dei risultati di sqlsimtools rendono molto più facili da automatizzare in una pipeline.

Conclusione

sqlsimtools colma un vuoto che l’ecosistema SQL Server si portava dietro da anni: un tool di load testing moderno, open source, multipiattaforma, che non dipende da un driver ormai ritirato e che parla la stessa lingua JSON degli strumenti di automazione contemporanei. È ancora in preview, quindi non va considerato “pronto per la produzione” senza le dovute verifiche, ma per chi oggi usa ancora ostress.exe o si affida a script fatti in casa per simulare carico su Azure SQL, è il momento di iniziare a valutarlo.

Fonte: Microsoft Tech Community – Introducing sqlsimtools. Repository ufficiale: github.com/microsoft/sqlsimtools. Approfondimento: IT-Connect.