AI SQL Tuner Recommendations
Executive Summary
This server is a SQL Server 2022 Developer Edition instance running on Windows 10 with 16 logical CPUs and ~32 GB RAM. The server was recently restarted (uptime < 1 day), so wait statistics and I/O data reflect a limited observation window.
Top Priorities
- CriticalEstablish Backup Strategy Immediately — Multiple databases (master, model, msdb, DigitsSolver, tpcc, CRM, tpch10) have no backup history. WideWorldImporters' last full backup is over 3.5 years old. This is the highest-risk finding.
- CriticalRun DBCC CHECKDB on All Databases — Six of seven user databases have never had CHECKDB run (reported as Jan 1, 1900). Without integrity checks, silent corruption could result in unrecoverable data loss.
- CriticalImplement Transaction Log Backups — Five databases (model, DigitsSolver, tpcc, tpch, CRM, tpch10) are in FULL recovery model but have no log backups, causing transaction logs to grow unbounded.
- HighEnable "Optimize for Ad Hoc Workloads" — This setting is disabled, leading to plan cache bloat from single-use ad hoc queries.
- HighUpgrade WideWorldImporters Compatibility Level — Currently at 130 (SQL Server 2016), missing significant SQL Server 2022 IQP features.
1. Backup & Recovery Strategy
Establish a Comprehensive Backup Plan
The current backup state represents the single greatest risk to this server. Multiple databases have zero backup history, meaning any storage failure results in complete, permanent data loss.
| Database | Recovery Model | Last Full Backup | Status |
|---|---|---|---|
| master | SIMPLE | Never | ⛔ No backup |
| model | FULL | Never | ⛔ No backup |
| msdb | SIMPLE | Never | ⛔ No backup |
| DigitsSolver | FULL | Never | ⛔ No backup |
| tpcc | FULL | Never | ⛔ No backup |
| CRM | FULL | Never | ⛔ No backup |
| tpch10 | FULL | Never | ⛔ No backup |
| tpch | FULL | Nov 2025 (147 days ago) | ⚠️ Stale |
| WideWorldImporters | SIMPLE | Oct 2022 (1,289 days ago) | ⛔ 3.5+ years old |
| SQLStorm | SIMPLE | Oct 2025 (175 days ago) | ⚠️ Stale |
Recommended Actions:
- Immediately take full backups of all databases.
- Establish a maintenance plan or SQL Agent jobs for regular backups (daily full, or weekly full + daily differential).
- Enable backup checksum validation for all backups.
- Store backups on a separate physical volume or off-site location.
- Periodically test restores to verify backup integrity.
Immediate Backup Script (run all full backups now):
-- Enable backup checksum as a server default
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'backup checksum default', 1;
RECONFIGURE;
EXEC sp_configure 'show advanced options', 0;
RECONFIGURE;
-- Full backups for all databases (adjust paths as needed)
BACKUP DATABASE [master] TO DISK = N'C:\Backups\master_full.bak'
WITH INIT, CHECKSUM, COMPRESSION, STATS = 10;
BACKUP DATABASE [msdb] TO DISK = N'C:\Backups\msdb_full.bak'
WITH INIT, CHECKSUM, COMPRESSION, STATS = 10;
BACKUP DATABASE [model] TO DISK = N'C:\Backups\model_full.bak'
WITH INIT, CHECKSUM, COMPRESSION, STATS = 10;
BACKUP DATABASE [WideWorldImporters] TO DISK = N'C:\Backups\WideWorldImporters_full.bak'
WITH INIT, CHECKSUM, COMPRESSION, STATS = 10;
BACKUP DATABASE [SQLStorm] TO DISK = N'C:\Backups\SQLStorm_full.bak'
WITH INIT, CHECKSUM, COMPRESSION, STATS = 10;
BACKUP DATABASE [DigitsSolver] TO DISK = N'C:\Backups\DigitsSolver_full.bak'
WITH INIT, CHECKSUM, COMPRESSION, STATS = 10;
BACKUP DATABASE [tpcc] TO DISK = N'C:\Backups\tpcc_full.bak'
WITH INIT, CHECKSUM, COMPRESSION, STATS = 10;
BACKUP DATABASE [tpch] TO DISK = N'C:\Backups\tpch_full.bak'
WITH INIT, CHECKSUM, COMPRESSION, STATS = 10;
BACKUP DATABASE [tpch10] TO DISK = N'C:\Backups\tpch10_full.bak'
WITH INIT, CHECKSUM, COMPRESSION, STATS = 10;
BACKUP DATABASE [CRM] TO DISK = N'C:\Backups\CRM_full.bak'
WITH INIT, CHECKSUM, COMPRESSION, STATS = 10;
Enable backup compression as the server default:
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'backup compression default', 1;
RECONFIGURE;
EXEC sp_configure 'show advanced options', 0;
RECONFIGURE;
2. Database Integrity Maintenance (CHECKDB)
DBCC CHECKDB Has Never Been Run on 6 of 7 User Databases
The "Jan 1 1900" date indicates DBCC CHECKDB has never been executed on these databases since they were created or attached to this instance. Without regular integrity checks, corruption can go undetected until it's too late to recover.
| Database | Last CHECKDB | Status |
|---|---|---|
| WideWorldImporters | Never (1900-01-01) | ⛔ Never checked |
| SQLStorm | Never (1900-01-01) | ⛔ Never checked |
| tpcc | Never (1900-01-01) | ⛔ Never checked |
| tpch | Never (1900-01-01) | ⛔ Never checked |
| CRM | Never (1900-01-01) | ⛔ Never checked |
| tpch10 | Never (1900-01-01) | ⛔ Never checked |
| DigitsSolver | Apr 12, 2026 (6 days ago) | ✅ OK |
Recommended Schedule:
- Weekly: Run DBCC CHECKDB on all user databases (or at minimum, before each full backup).
- Immediately: Run CHECKDB now on all databases that have never been checked.
-- Run immediately on all databases with no history
DBCC CHECKDB (N'WideWorldImporters') WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY;
DBCC CHECKDB (N'SQLStorm') WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY;
DBCC CHECKDB (N'tpcc') WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY;
DBCC CHECKDB (N'tpch') WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY;
DBCC CHECKDB (N'CRM') WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY;
DBCC CHECKDB (N'tpch10') WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY;
DBCC CHECKDB (N'DigitsSolver') WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY;
Consider implementing Ola Hallengren's Maintenance Solution for automated CHECKDB, backups, and index maintenance.
3. Transaction Log Management
Databases in FULL Recovery Without Log Backups
Five user databases and the model system database are in FULL recovery model but have no transaction log backups. This means:
- Transaction logs will grow continuously and may eventually fill the disk.
- There is no point-in-time recovery capability despite paying the overhead of FULL recovery.
- The FULL recovery model provides no benefit without log backups.
| Database | Recovery Model | Log Backups |
|---|---|---|
| model | FULL | None |
| DigitsSolver | FULL | None |
| tpcc | FULL | None |
| tpch | FULL | None |
| CRM | FULL | None |
| tpch10 | FULL | None |
Recommended Actions (choose one per database):
Option A: If point-in-time recovery is NOT required, switch to SIMPLE recovery:
-- Switch to SIMPLE if point-in-time recovery is not needed
-- (appropriate for dev/test workloads like tpcc, tpch, tpch10)
ALTER DATABASE [tpcc] SET RECOVERY SIMPLE;
ALTER DATABASE [tpch] SET RECOVERY SIMPLE;
ALTER DATABASE [tpch10] SET RECOVERY SIMPLE;
ALTER DATABASE [DigitsSolver] SET RECOVERY SIMPLE;
ALTER DATABASE [CRM] SET RECOVERY SIMPLE;
Option B: If point-in-time recovery IS required, implement regular log backups:
-- Example: Log backup every 30 minutes (adjust as needed)
-- Create a SQL Agent job for each database in FULL recovery
BACKUP LOG [CRM] TO DISK = N'C:\Backups\CRM_log.trn'
WITH INIT, CHECKSUM, COMPRESSION, STATS = 10;
Note: Since this appears to be a development workstation (Windows 10 Home, Developer Edition), SIMPLE recovery is likely the best choice for most of these databases. The model database's recovery model serves as the template for new databases, so consider setting it to SIMPLE as well to avoid this issue recurring.
4. Configuration Optimizations
Enable "Optimize for Ad Hoc Workloads"
Currently disabled (value: 0). When disabled, every unique ad hoc query statement stores a full compiled plan in the plan cache. Enabling this setting causes SQL Server to store only a small "plan stub" on first execution, promoting to a full plan only upon reuse. This significantly reduces plan cache memory consumption.
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'optimize for ad hoc workloads', 1;
RECONFIGURE;
EXEC sp_configure 'show advanced options', 0;
RECONFIGURE;
Enable Remote DAC (Dedicated Admin Connection)
Currently disabled (remote admin connections = 0). While only local DAC is needed most of the time, enabling remote DAC provides a critical emergency lifeline if the server becomes unresponsive and you cannot access it locally.
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'remote admin connections', 1;
RECONFIGURE;
EXEC sp_configure 'show advanced options', 0;
RECONFIGURE;
Review Max Server Memory Setting
Max server memory is set to 23,168 MB out of 32,527 MB total. This leaves ~9.4 GB for the OS and other processes, which is reasonable for a workstation running Windows 10 with desktop applications. The current setting is acceptable.
However, the min server memory is effectively 16 MB (running value), which means SQL Server can release nearly all buffer pool memory under OS memory pressure. Consider setting a reasonable minimum:
-- Optional: Set minimum memory to prevent excessive memory release
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'min server memory (MB)', 4096;
RECONFIGURE;
EXEC sp_configure 'show advanced options', 0;
RECONFIGURE;
Review Max Degree of Parallelism and Cost Threshold
Current settings:
- MAXDOP = 8 — Appropriate for 16 logical CPUs (half the core count). ✅ Good.
- Cost Threshold for Parallelism = 30 — Above the default of 5, which prevents small queries from going parallel unnecessarily. ✅ Good.
These settings are well-tuned. No changes recommended.
5. Compatibility Level
Upgrade WideWorldImporters Compatibility Level from 130 to 160
The WideWorldImporters database is running at compatibility level 130 (SQL Server 2016). On SQL Server 2022, this misses significant query processing improvements:
- Level 140: Adaptive joins, interleaved execution for MSTVFs, batch mode on rowstore
- Level 150: Batch mode on rowstore (full), scalar UDF inlining, table variable deferred compilation
- Level 160: Parameter Sensitive Plan (PSP) optimization, DOP feedback, cardinality estimation feedback, optimized plan forcing
Recommendation: Test the application with compat level 160, then upgrade. Query Store (already enabled) will help identify any plan regressions.
-- Step 1: Ensure Query Store is capturing baselines (already active)
-- Step 2: Upgrade compatibility level
ALTER DATABASE [WideWorldImporters] SET COMPATIBILITY_LEVEL = 160;
-- Step 3: Monitor Query Store for regressions over the next few days
-- If regressions occur, use Query Store plan forcing to fix them
6. Query Store Optimization
Query Store Is Well Configured — Minor Tuning Recommended
All user databases have Query Store enabled in READ_WRITE mode with AUTO capture and cleanup — this is excellent. Minor optimizations:
| Setting | Most Databases | WideWorldImporters | Recommended |
|---|---|---|---|
| Flush Interval | 15 min | 50 min | 15 min ✅ |
| Stats Interval | 60 min | 15 min | 15-60 min ✅ |
| Max Plans/Query | 200 | 1000 | 200 |
| Max Size | 1,000 MB | 500 MB | 1,000 MB |
Recommended: Normalize WideWorldImporters Query Store settings and reduce max plans per query from 1000 to 200:
ALTER DATABASE [WideWorldImporters] SET QUERY_STORE (
FLUSH_INTERVAL_SECONDS = 900,
MAX_PLANS_PER_QUERY = 200,
MAX_STORAGE_SIZE_MB = 1000
);
Since this is SQL Server 2022 with compat level 160 databases, consider enabling Query Store hints and Query Store for secondary replicas if you add HADR in the future.
7. TempDB Optimization
Enable TempDB Metadata Memory-Optimized
Currently disabled (tempdb metadata memory-optimized = 0). SQL Server 2022 supports memory-optimized tempdb metadata, which eliminates latch contention on tempdb system pages — a common bottleneck under heavy tempdb usage.
The server has 8 tempdb data files (matching 8 of the 16 cores), which is a good configuration.
-- Enable memory-optimized tempdb metadata (requires restart)
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'tempdb metadata memory-optimized', 1;
RECONFIGURE;
EXEC sp_configure 'show advanced options', 0;
RECONFIGURE;
-- Note: Requires SQL Server restart to take effect
Note: This is most impactful under heavy tempdb workloads (e.g., lots of temp tables, table variables). For a development workstation with light usage, this is a proactive optimization.
8. Security Enhancements
Security Posture Assessment
The overall security posture is acceptable for a development workstation:
- ✅ Sysadmin membership: Only 1 member (RockyPC\k_a_f) — appropriate.
- ✅ Connection encryption: 100% of connections encrypted.
- ✅ xp_cmdshell: Disabled.
- ✅ CLR: Disabled with strict security enforced.
- ✅ Cross-database ownership chaining: Disabled.
- ✅ Ad Hoc Distributed Queries: Disabled.
- ✅ Ole Automation: Disabled.
- ✅ No deadlocks detected in the past 7 days.
Minor recommendations:
- The server allows both Windows and SQL Authentication (
Integrated Security Only = No). If SQL Authentication is not needed, consider switching to Windows Authentication only for improved security. - The
remote accesssetting is enabled (legacy feature). Consider disabling if remote stored procedure calls via RPC are not needed:
-- Disable legacy remote access (if not using linked servers with RPC)
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'remote access', 0;
RECONFIGURE;
EXEC sp_configure 'show advanced options', 0;
RECONFIGURE;
-- Note: Requires SQL Server restart to take effect
9. Performance Assessment
Wait Statistics — No Significant Issues
The top wait types are all benign/background waits with very low accumulated times (total ~2.4 minutes combined, server recently restarted):
| Wait Type | Time | Assessment |
|---|---|---|
| PWAIT_DIRECTLOGCONSUMER_GETNEXT | 1.25 min (51%) | Benign — related to log consumer threads |
| QDS_PERSIST_TASK_MAIN_LOOP_SLEEP | 1.00 min (41%) | Benign — Query Store background sleep |
| SLEEP_DBSTARTUP | 0.04 min | Benign — startup related |
| WAIT_XTP_RECOVERY | 0.04 min | Benign — In-Memory OLTP recovery |
| PWAIT_ALL_COMPONENTS_INITIALIZED | 0.03 min | Benign — startup related |
No concerning wait types (CXPACKET, PAGEIOLATCH, LCK_*, WRITELOG, etc.) are present. This is expected for a lightly loaded development workstation shortly after restart.
I/O Performance — Excellent Latencies
All database files show sub-millisecond or 1ms average latencies. No I/O bottlenecks detected:
- Highest read latency: WideWorldImporters log file at 1 ms — excellent.
- All data files: 0 ms average latency.
- Good practice: Data files (C:\Data) and log files (C:\Logs) are on separate paths.
Note: System database files (master, model, msdb, tempdb) are on C:\Data\MSSQL16... while user databases are on C:\Data. Consider verifying these are separate physical volumes for optimal performance.
Plan Cache — No Concerning Queries
The top resource-consuming queries in the plan cache are all system/monitoring queries (DMV queries, system catalog queries, filetable update queries). No user workload queries appear to be consuming excessive resources. This is consistent with a recently restarted server with minimal activity.
10. Proactive Maintenance Suggestions
Implement a Maintenance Framework
This server lacks a structured maintenance approach. Recommended framework:
| Task | Frequency | Notes |
|---|---|---|
| Full Backup (all DBs) | Daily or Weekly | Include CHECKSUM, COMPRESSION |
| Log Backup (FULL recovery DBs) | Every 15-30 min | Or switch to SIMPLE recovery |
| DBCC CHECKDB | Weekly | Before full backups ideally |
| Index Maintenance | Weekly | Rebuild >30% fragmented, reorganize 10-30% |
| Statistics Update | Weekly or after large data changes | UPDATE STATISTICS with FULLSCAN for key tables |
| Cycle Error Logs | Weekly | sp_cycle_errorlog |
| Query Store Cleanup Review | Monthly | Review captured data, force plans if needed |
Recommended: Install Ola Hallengren's SQL Server Maintenance Solution which provides comprehensive, community-proven maintenance jobs.
Apply SQL Server Updates
The server is running SQL Server 2022 RTM-GDR (16.0.1175.1) from March 2026. While this is a recent GDR (security update), consider checking for the latest Cumulative Update (CU) which includes performance improvements and bug fixes in addition to security patches.
Check the latest CU at: Microsoft SQL Server Latest Updates
11. Concurrency Assessment
No Concurrency Issues Detected
- ✅ No deadlocks detected in the past 7 days.
- ✅ No LCK_* wait types in the top waits.
- The
blocked process thresholdis set to 0 (disabled). Consider enabling it for proactive monitoring:
-- Enable blocked process reporting (alerts for blocks lasting > 10 seconds)
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'blocked process threshold (s)', 10;
RECONFIGURE;
EXEC sp_configure 'show advanced options', 0;
RECONFIGURE;
-- Then set up an Extended Events session or Alert to capture blocked process reports
12. Index Assessment
No High-Impact Missing Indexes Detected
✅ No high-impact missing indexes were found across all databases. This is expected given the minimal workload observed since the recent server restart. As the workload increases, missing index DMVs will accumulate recommendations.
Recommendation: Re-evaluate missing indexes after the server has been running under typical workload for at least 1-2 weeks. Use the Index Tuning goal in AI SQL Tuner for comprehensive analysis of individual databases when the time comes.
Configuration Summary — Changes Recommended
| Setting | Current Value | Recommended Value | Priority | Restart Required |
|---|---|---|---|---|
| optimize for ad hoc workloads | 0 | 1 | High | No |
| backup compression default | 0 | 1 | High | No |
| backup checksum default | 0 | 1 | High | No |
| remote admin connections | 0 | 1 | High | No |
| tempdb metadata memory-optimized | 0 | 1 | Medium | Yes |
| blocked process threshold | 0 | 10 | Medium | No |
| min server memory (MB) | 16 | 4096 | Medium | No |
| remote access | 1 | 0 | Low | Yes |
| cost threshold for parallelism | 30 | 30 | ✅ OK | — |
| max degree of parallelism | 8 | 8 | ✅ OK | — |
| max server memory (MB) | 23168 | 23168 | ✅ OK | — |