Stai preparando un nuovo sito MECM 2303 su SQL Server 2022 e SSMS propone il livello 160? La scelta più sicura oggi è impostare la compatibilità del database a 150, mantenendo l’engine 2022. In questa guida trovi perché farlo, come eseguirlo e come validare l’ambiente senza rischi.
Panoramica del problema
Quando si allestisce un’infrastruttura Microsoft Endpoint Configuration Manager (MECM) 2303 sopra SQL Server 2022, capita spesso di trovarsi davanti a un apparente paradosso. L’installer e la prassi operativa consolidata suggeriscono di utilizzare la semantica di ottimizzazione di SQL Server 2019, cioè compatibilità 150, mentre l’interfaccia di SQL Server Management Studio (SSMS) propone per impostazione predefinita “SQL Server 2022 (160)”. Il dubbio che ne deriva è legittimo: conviene davvero abbassare manualmente il livello di compatibilità? La risposta breve è sì: per il database del sito di ConfigMgr è consigliabile impostare 150 fino a quando il prodotto non verrà ufficialmente convalidato per 160. In questo modo si preserva la stabilità del Query Optimizer e si riduce il rischio di piani di esecuzione non previsti, continuando comunque a utilizzare il motore, le patch e la telemetria di SQL 2022.
Cosa significa livello di compatibilità
Il livello di compatibilità è una proprietà del singolo database che orienta il comportamento del motore in aree chiave: semantica T‑SQL, stimatori di cardinalità, feature del Query Optimizer e porzioni del framework Intelligent Query Processing. Non è la versione del motore. In altre parole, impostando la compatibilità a 150 su un’istanza 2022:
- si resta su engine 2022 con le sue patch cumulative, il modello di memoria, lo scheduler e le migliorie di base;
- si chiede però al database di adottare la semantica ottimizzativa e i guardrail di SQL 2019, riducendo la probabilità di regressioni su workload che non sono stati testati con 160.
Soluzione rapida passo‑passo
| Passo | Azione | Nota |
|---|---|---|
| 1 | Creare il database normalmente (può restare temporaneamente a 160). | Il motore resta comunque SQL 2022. |
| 2 | Impostare il livello di compatibilità a 150. | Puoi: • selezionare “SQL Server 2019 (150)” dal menu a discesa in Opzioni → Compatibility level; oppure • eseguire la T‑SQL: ALTER DATABASE <NomeDB> SET COMPATIBILITY_LEVEL = 150; |
| 3 | Verificare con SELECT name, compatibility_level FROM sys.databases;. | Deve risultare 150. |
Perché non usare il livello predefinito
- Convalida del prodotto – MECM 2303 è stato testato e ottimizzato con la semantica di compatibilità 150. Fino all’aggiornamento della matrice di supporto, adottare 160 può produrre piani diversi o tocchi di funzionalità non esercitati nei test di regressione.
- Separazione tra motore e setting – Il numero di compatibilità governa il comportamento del database, non la versione dell’istanza. Benefici e patch di SQL 2022 restano attivi anche con compatibilità 150.
- Aggiornabilità più semplice – Quando ConfigMgr verrà certificato per la semantica più recente, sarà sufficiente alzare la compatibilità con un semplice ALTER DATABASE, senza reinstallare né spostare i dati.
Guida dettagliata con SQL Server Management Studio
- Apri SSMS e connettiti all’istanza che ospiterà il database del sito.
- Se hai già pre‑creato il database, espandi Databases, fai clic destro sul database (ad esempio
CM_ABC) e apri Properties. - Vai alla scheda Options e cerca Compatibility level.
- Seleziona SQL Server 2019 (150) dall’elenco.
- Applica con OK. L’operazione è online e non richiede riavvio dell’istanza.
- Verifica:
SELECT name, compatibility_level FROM sys.databases WHERE name = N'CM_ABC';
Nota operativa: se stai installando un nuovo sito, la via più lineare resta lasciare che il setup di MECM crei il database. In tal caso il livello corretto viene impostato automaticamente e riduci il margine di errore umano.
Guida dettagliata con T‑SQL
Se preferisci uno script ripetibile, esegui la seguente sequenza:
-- imposta la compatibilità
ALTER DATABASE [CMABC] SET COMPATIBILITYLEVEL = 150;
GO
-- opzionale: forzare ricompilazioni per il database
-- valutare l'impatto fuori orario di punta
ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;
GO
-- verifica
SELECT name, compatibility_level
FROM sys.databases
WHERE name = N'CM_ABC'; Il comando agisce solo sul database di destinazione. L’istanza continua a eseguire SQL 2022 con tutte le correzioni applicate. La pulizia della procedure cache è opzionale ma utile per evitare che piani compilati con semantica precedente restino in memoria più del necessario. Pianificala in una finestra di manutenzione per evitare picchi improvvisi di CPU al primo giro di ricompilazioni.
Automazione per ambienti enterprise
In ambienti con più siti o istanze è comodo standardizzare il controllo. Ecco due approcci rapidi.
Approccio T‑SQL
-- elenca i database utente con compatibilità diversa da 150
SELECT name, compatibility_level
FROM sys.databases
WHERE database_id > 4 -- esclude master, tempdb, model, msdb
AND name LIKE 'CM[_]%' -- focalizzato su database MECM
AND compatibility_level <> 150;
-- applica 150 a tutti i database CM_* online
DECLARE @db sysname, @sql nvarchar(4000);
DECLARE c CURSOR FAST_FORWARD FOR
SELECT name
FROM sys.databases
WHERE database_id > 4
AND name LIKE 'CM[_]%'
AND state_desc = 'ONLINE';
OPEN c;
FETCH NEXT FROM c INTO @db;
WHILE @@FETCH_STATUS = 0
BEGIN
SET @sql = N'ALTER DATABASE [' + @db + N'] SET COMPATIBILITY_LEVEL = 150;';
PRINT @sql;
EXEC (@sql);
FETCH NEXT FROM c INTO @db;
END
CLOSE c; DEALLOCATE c; Approccio PowerShell
Senza dipendenze da SMO avanzate, usa Invoke-Sqlcmd del modulo SqlServer:
$instances = @("SQLPROD01\INST", "SQLPROD02\INST")
$dbName = "CM_ABC"
$tsql = "ALTER DATABASE [$dbName] SET COMPATIBILITY_LEVEL = 150;
SELECT name, compatibility_level FROM sys.databases WHERE name = N'$dbName';"
foreach ($i in $instances) {
Write-Host "Aggiorno $dbName su $i"
Invoke-Sqlcmd -ServerInstance $i -Database master -Query $tsql
} Considerazioni su disponibilità elevata e ripristino
- Always On Availability Groups – La modifica si esegue sul primario e viene trasferita alle repliche come normale transazione. Verifica che la replica sia in stato sano, quindi applica la validazione anche sui secondari leggendo la proprietà
compatibility_level. - Log shipping – La proprietà è parte del database e viene mantenuta sul secondario. Se l’ambiente ha catene di log shipping, esegui la modifica in una finestra coordinata e controlla eventuali alert finché la latenza non torna a zero.
- Cluster di failover – La proprietà resta nel database; nessuna azione specifica è richiesta oltre alla convalida post‑failover.
- Backup e ripristino – Il livello di compatibilità viaggia con il backup. Prima di cambiare setting, prendi comunque un backup recente per policy.
Indicazioni operative specifiche per MECM
- Creazione database dal setup – Quando possibile evita la pre‑creazione manuale. Il setup di MECM imposta proprietà, filegrowth e compatibilità adeguati.
- Upgrade del sito – Se aggiorni un sito esistente spostato su SQL 2022, verifica che il database non sia rimasto a 160 per effetto di un ripristino o di una migrazione. Se lo è, valuta l’impostazione a 150 prima di riprendere le operazioni di produzione.
- Co‑locazione con WSUS – Non è necessario uniformare la compatibilità degli altri database dell’istanza. Concentrati su
CM_<SiteCode>. Gestisci gli altri DB secondo i loro requisiti applicativi. - Collation e filegroup – Se pre‑crei il database, rispetta i prerequisiti del prodotto in termini di collation e layout dei file. Il livello di compatibilità è una dimensione separata.
Validazione post‑modifica
Dopo l’impostazione a 150, effettua una validazione strutturata. Ecco un percorso consigliato.
Query di controllo
-- compatibilità e versione engine
SELECT
d.name, d.compatibility_level,
SERVERPROPERTY('ProductVersion') AS ProductVersion,
SERVERPROPERTY('ProductUpdateLevel') AS ProductUpdateLevel,
SERVERPROPERTY('Edition') AS Edition
FROM sys.databases AS d
WHERE d.name = N'CM_ABC';
Verifica applicativa
- Esegui i task di manutenzione del sito e osserva i log principali:
ConfigMgrSetup.log,smsexec.log, eventuali log di replica e di sincronizzazione. Qualsiasi warning legato a semantica SQL deve essere assente. - Apri la console di ConfigMgr e verifica operazioni quotidiane: discovery, inventory, distribuzione contenuti, sincronizzazione Software Update Point, reporting di base.
- Controlla tempi di risposta delle query note (ad esempio report SSRS più usati) confrontandoli con un baseline, meglio se acquisita prima del cambio.
Impatto, rischi e mitigazioni
Il passaggio a compatibilità 150 è tipicamente trasparente, ma è buona pratica governare il cambiamento.
- Ricompilazioni – Una parte dei piani verrà ricompilata; programma l’operazione in un periodo di basso carico o svuota la cache in modo controllato solo per il database.
- Query Store – Se utilizzi Query Store, assicurati che sia in modalità Read Write e con cattura pianificata. Dopo il cambio, lascia “raffreddare” il sistema e verifica eventuali regressioni; se necessario, forza i piani noti buoni.
- Monitoraggio – Osserva i contatori chiave: compilazioni/sec, CPU, attesa su CXPACKET/CXCONSUMER, tempi di risposta sulle query di riferimento. Eventuali anomalie lontane dal cambio di compatibilità tendono a indicare cause esterne.
Domande frequenti
È obbligatorio abbassare subito la compatibilità se il database è nato a 160?
Non è obbligatorio, ma è consigliabile per allinearsi al comportamento su cui MECM 2303 è stato convalidato. Il motore resta 2022, quindi non perdi patch né funzionalità di base dell’istanza.
Il cambio è reversibile?
Sì. Quando l’applicazione sarà certificata per la semantica più recente, potrai rialzare con:
ALTER DATABASE [CMABC] SET COMPATIBILITYLEVEL = 160;
Esegui poi una validazione come descritto sopra.
Il setup di MECM interviene automaticamente?
Se lasci creare il database al setup, viene impostata la compatibilità corretta in autonomia. Se invece pre‑crei tu il database, dovrai adeguarla manualmente.
Serve riavviare l’istanza o disconnettere i client?
No. La modifica è online e interessa solo il database. I client MECM non richiedono alcuna azione.
Checklist operativa
- Backup recente del database del sito.
- Finestra di manutenzione definita e stakeholder informati.
- Esecuzione di
ALTER DATABASE ... SET COMPATIBILITY_LEVEL = 150. - Verifica con
sys.databasese, facoltativamente, svuotamento della cache del solo database. - Esecuzione guidata dei task MECM e review dei log principali.
- Monitoraggio post‑cambio per qualche ora sulle metriche chiave.
- Registrazione della modifica nel sistema di change management.
Tabella di riferimento dei livelli
| Compatibilità | Release associata | Uso tipico |
|---|---|---|
| 120 | SQL Server 2014 | Legacy, da aggiornare |
| 130 | SQL Server 2016 | Legacy, da aggiornare |
| 140 | SQL Server 2017 | Legacy, da aggiornare |
| 150 | SQL Server 2019 | Consigliato oggi per MECM 2303 |
| 160 | SQL Server 2022 | Da adottare quando ConfigMgr sarà certificato |
Procedure di rollback e avanzamento
Se durante il collaudo emergono regressioni inattese, puoi tornare al livello precedente con un semplice ALTER DATABASE. Ricorda di annotare data e ora della modifica; così potrai correlare eventuali metriche anomale al momento del cambio. Quando deciderai di avanzare alla semantica più recente, applica il percorso inverso: alza la compatibilità, valida i processi critici e osserva i tempi di risposta prima di rendere permanente la scelta.
Log e segnalazioni utili
I log principali da considerare dopo il cambio sono:
ConfigMgrSetup.log– utile in fase di installazione o aggiornamento del sito;smsexec.log– supervisione del core del servizio;- eventuali log di replica del database e dei componenti di sincronizzazione aggiornamenti.
Eventuali warn di tipo SQL dovrebbero scomparire una volta allineata la compatibilità.
Buone pratiche di performance
- Dimensionamento del database – Crescita dei file a step fissi e ragionevoli, filegroup separati se la tua policy lo prevede, autogrowth non troppo piccoli per evitare frammentazione.
- Indice e statistiche – Esegui un ciclo di aggiornamento statistiche dopo il cambio, così il Query Optimizer lavora con dati freschi.
- Query Store – Mantieni una retention congrua e monitora le regressioni; i hint di plan forcing possono essere un paracadute.
Conclusione
Impostare il database di MECM 2303 su compatibilità 150 è una scelta pragmatica che coniuga stabilità e modernità: sfrutti il motore SQL Server 2022 con le sue patch e i miglioramenti infrastrutturali, ma adotti una semantica di ottimizzazione già convalidata per ConfigMgr. La modifica si effettua in minuti, è reversibile e si presta ad automazione e controllo centralizzato. Con le verifiche suggerite, potrai mettere in produzione l’ambiente con tranquillità, mantenendo una via di aggiornamento semplice quando sarà il momento di passare alla semantica più recente.
Riepilogo operativo
- Crea o individua il database del sito.
- Imposta la compatibilità a 150 via SSMS o T‑SQL.
- Conferma con
sys.databasese, se necessario, svuota la cache del database. - Valida MECM con i suoi task e i log chiave.
- Monitora e documenta il cambio.
In sintesi, sì: imposta il database a compatibility level 150. Così mantieni il motore SQL 2022 pienamente supportato, evitando al contempo possibili problemi di compliance e ottimizzazione con MECM 2303.