See the full comparison: SQL_2022_To_2025_DMV_Comparison

How I built the comparison list

I exported the list of system views from the sys schema using the query below. I also filtered out anything under INFORMATION_SCHEMA because I wanted to focus on the “real” system catalog/DMV surface area.

SELECT * 
FROM [sys].[system_objects] [so] 
    INNER JOIN [sys].[schemas] [sch] ON [sch].[schema_id] = [so].[schema_id] 
WHERE [type] = 'V' AND [sch].[name] = 'sys';

Headline numbers

• Added: 28
• Removed: 6
• Modified: 39
• Identical: 565

These counts are straight from the SQL Compare report.

New system objects in SQL Server 2025 (added)

The most interesting additions fall into a few “themes”: newer query processing diagnostics, automatic tuning internals, memory/OS health visibility, governance/security metadata, and new metadata areas like JSON and vector indexing.

• sys_dm_database_backup_lineage
• sys_dm_db_information_protection_label_properties
• sys_dm_db_internal_auto_tuning_create_index_recommendations
• sys_dm_db_internal_auto_tuning_recommendation_impact_query_metrics
• sys_dm_db_internal_auto_tuning_recommendation_metrics
• sys_dm_db_internal_auto_tuning_workflows
• sys_dm_db_internal_automatic_tuning_version
• sys_dm_db_logical_index_corruptions
• sys_dm_db_xtp_undeploy_status
• sys_dm_exec_ce_feedback_cache
• sys_dm_exec_distributed_tasks
• sys_dm_external_governance_synchronizing_objects
• sys_dm_external_policy_excluded_role_members
• sys_dm_hadr_internal_availability_groups
• sys_dm_hadr_internal_availability_replicas
• sys_dm_io_network_traffic_stats
• sys_dm_os_memory_allocations_filtered
• sys_dm_os_memory_health_history
• sys_dm_os_memory_nodes_processor_groups
• sys_dm_os_parent_block_descriptors
• sys_dm_pal_ring_buffers
• sys_dm_server_managed_identities
• sys_external_models
• sys_external_table_schema_changed_mdsync
• sys_information_protection_label_mapping
• sys_json_index_paths
• sys_json_indexes
• sys_vector_indexes

System objects that disappeared in SQL Server 2025 (removed)

Only six objects were flagged as removed.

• sys_dm_dw_locks
• sys_dm_pal_spinlock_stats
• sys_dm_pal_wait_stats
• sys_dm_toad_tuning_zones
• sys_dm_toad_work_item_handlers
• sys_dm_toad_work_items

Modified objects (what changed, at a high level)

The report shows 39 modified objects. In practice, these changes are typically “column-level” updates to internal catalog tables and DMVs to support new features and diagnostics in SQL Server 2025.

• Query processing and tuning: changes around query profiling and memory grants, plus new cardinality-estimation feedback exposure (sys_dm_exec_ce_feedback_cache is new, and related surfaces like sys_dm_exec_query_memory_grants show changes).
• Query Store & plan feedback: system objects related to plan feedback/forcing locations are modified (sys_query_store_plan_feedback, sys_query_store_plan_forcing_locations).
• Availability groups / HADR: both catalog views and DMVs around AGs are modified (sys_availability_groups, sys_dm_hadr_availability_replica_states, sys_dm_hadr_database_replica_states), and there are new “internal” HADR DMVs in 2025 (listed above).
• Memory/OS internals: multiple sys_dm_os_* objects are modified, and new memory-health/history DMVs appear in 2025.
• Governance and labeling: new information protection label mapping and governance-sync related surfaces appear, and existing governance DMVs are modified (sys_dm_external_governance_sync_state, sys_dm_database_external_governance_sync_state).
• Core catalog internals: classic internal objects like sys_all_columns, sys_columns, sys_parameters, sys_stats, and “system_*” internals show updates, which is typical when a major version adds metadata flags and new engine behaviors.

What changed in SQL Server 2025

• SQL Server 2025 introduces an encryption-related breaking change that can cause linked server connections to fail after an upgrade.
• If the connection ends up requiring encryption with certificate validation, and the target server certificate isn’t trusted (or you connect by IP that doesn’t match the certificate name), the linked server can fail.
• The quickest “get it working” mitigation I’ve used is to add @provstr = N'Encrypt=Yes;TrustServerCertificate=yes' when creating the linked server.
• Best practice is still to use a proper CA-signed certificate and keep certificate validation enabled, but in real migrations you sometimes need the fast, pragmatic fix first.

SQL Server 2022 (working without explicit encryption settings)

USE [master]
GO

EXEC master.dbo.sp_addlinkedserver 
    @server = N'MyLinkedServer1', 
    @srvproduct = N'', 
    @provider = N'SQLNCLI', 
    @datasrc = N'123.123.123.123,1433'
GO

SQL Server 2025 script (explicit encryption in @provstr is required)

On SQL Server 2025, adding an explicit provider string makes the intent clear and prevents the upgrade from breaking existing linked servers. I also recommend switching away from the legacy SQLNCLI provider to MSOLEDBSQL if you still have old scripts around.

USE [master]
GO

EXEC master.dbo.sp_addlinkedserver 
    @server = N'MyLinkedServer1',
    @srvproduct = N'',
    @provider = N'MSOLEDBSQL',
    @datasrc = N'123.123.123.123,1433',
    @provstr = N'Encrypt=Yes;TrustServerCertificate=yes'
GO

References

• Database Engine breaking changes in SQL Server 2025 (linked server encryption)
• Linked servers (Database Engine) – encryption defaults and Encrypt settings
• sp_addlinkedserver (Transact-SQL) – SQL Server 2025 notes on encrypt in @provstr

The VM size was E2ds_v6, which includes ~110 GB local storage (NVMe / ephemeral).

The deployment failed during provisioning with this error:

{
  "status": "Failed",
  "error": {
    "code": "Ext_StorageConfigurationSettings_ApplyNewTempDbSettingsError",
    "message": "Error: 'System Drive returned status not ready for use '"
}

What was happening

In my case, the root cause was surprisingly simple: the local NVMe disk was presented to Windows as RAW / uninitialized.

The SQL Server IaaS extension (the component Azure uses to apply storage configuration for SQL on a VM) tried to configure tempdb on that local disk. Because the disk had no partition, no file system, and no drive letter, the extension step failed, and the entire provisioning process ended as Failed.

This is especially annoying because local/ephemeral disks are exactly where you often want tempdb (fast IOPS), but only if the disk is actually usable at boot time.

The fix: initialize the NVMe temp disk at startup (idempotent script)

The solution that worked for me was to create a PowerShell script that runs on startup and does the following:

• Find the first non-OS NVMe disk ( you can edit it to get the drive based on name or a different attribute, as per your current setup)
• If it is RAW, initialize it (GPT), create one partition, and format it NTFS
• Force the drive letter to T: (so my tempdb path is stable)
• Create the folder T:\SQLTemp
• Grant permissions to the default instance service SID: NT SERVICE\MSSQLSERVER

Here is the script exactly as I used it:

# Pick the temp NVMe disk: non-OS, NVMe bus, and possibly RAW
$disk = Get-Disk | Where-Object {
    $_.IsBoot -eq $false -and $_.IsSystem -eq $false -and $_.BusType -eq 'NVMe'
} | Sort-Object Number | Select-Object -First 1

if ($null -eq $disk) { exit 0 }

# If RAW, initialize + partition + format and force drive letter T:
if ($disk.PartitionStyle -eq 'RAW') {
    Initialize-Disk -Number $disk.Number -PartitionStyle GPT -PassThru | Out-Null
    $part = New-Partition -DiskNumber $disk.Number -UseMaximumSize -DriveLetter T
    Format-Volume -Partition $part -FileSystem NTFS -NewFileSystemLabel "TEMP" -AllocationUnitSize 65536 -Confirm:$false | Out-Null
}

# If it’s already formatted but missing letter T, try to assign it
$vol = Get-Volume | Where-Object { $_.FileSystemLabel -eq 'TEMP' } | Select-Object -First 1
if ($vol -and $vol.DriveLetter -ne 'T') {
    Set-Partition -DriveLetter $vol.DriveLetter -NewDriveLetter T
}

# Ensure TempDB folder exists
$tempFolder = "T:\SQLTemp"
if (!(Test-Path $tempFolder)) { New-Item -ItemType Directory -Path $tempFolder | Out-Null }

# Grant SQL Server service account (default instance service SID) rights
icacls $tempFolder /grant "NT SERVICE\MSSQLSERVER:(OI)(CI)F" /T | Out-Null

# Start SQL
Start-Service "MSSQLSERVER"
Start-Service "SQLSERVERAGENT" -ErrorAction SilentlyContinue

Important detail: make sure SQL Server doesn’t start before the disk is ready

Just initializing the disk is not enough if SQL Server starts too early.

• Set the SQL Server (MSSQLSERVER) service startup type from Automatic to Manual
• Set the SQL Server Agent (MSSQLSERVER) service startup type from Automatic to Manual

Then create a new Windows Task (use Task Scheduler) to be run at system startup:

• Trigger: At startup
• Security options: Run whether the user is logged on or not
• Security options: Run with highest privileges
• Action: powershell.exe
• Arguments: -ExecutionPolicy Bypass -File C:\Scripts\Init-TempDisk-AndStartSql.ps1

After a reboot, the VM brought up the temp drive first, then SQL Server came online cleanly. The deployment succeeded, and tempdb could be placed where it belongs.

Alternative options (if you don’t want tempdb on local storage)

If you want a simpler/safer setup (at the cost of I/O), you can avoid placing tempdb on ephemeral storage entirely:

• Use a VM size where the temp disk is presented consistently and already formatted
• Place tempdb on a managed data disk (Premium SSD / Ultra Disk) and configure it that way from the start.

Important note: How SQL IaaS starts SQL Server (and why you should not edit its startup task)

When you deploy a SQL Server VM from the Azure Marketplace image, Azure installs the SQL Server IaaS Agent extension. One of the things this extension does is create a Windows Scheduled Task (running at system startup) that executesSqlIaaSExtension.SqlServerStarter.exe. This starter component is responsible for bringing the SQL Server services online in a predictable way (and for some configurations, it also validates or prepares required paths used by SQL Server).

A key detail is that this scheduled task is managed by the SQL IaaS extension. That means it is effectively treated as “desired state”: on every VM boot, the extension can recreate or reset the task to its default definition. Because of that, any manual edits (for example, adding a PowerShell step into the same task) are not persistent. If you add your PowerShell action directly into the SQL IaaS startup task, it will typically be deleted on the next VM startup, because the extension rewrites the task back to the default version.

The correct approach is to leave the SQL IaaS task untouched and create a separate startup scheduled task for your own script (for example, to initialize and format the ephemeral NVMe disk and create T:\SQLTemp). Your task can run at startup and ensure the drive and folder exist, and then (optionally) start or restart the SQL Server service if needed.

References

• SQL VM fails to deploy or SQL Server instance can’t come online after restart (Drive not ready)
• SQL Server IaaS Agent extension overview
• Configure storage for SQL Server on Azure VMs

With SQL Server 2025, that option is gone.

Microsoft has confirmed that SQL Server 2022 is the last version supporting Web Edition. From 2025 onward, if you want to stay current, Standard Edition becomes the default replacement — and that’s where the real problem starts.

In one of my Azure VM–based projects, we were running SQL Server Web Edition on a VM with 12 vCores and 48 GB RAM. The SQL licensing cost was roughly 70 USD per month, fully acceptable for the workload and business value.

After switching the same VM to SQL Server Standard Edition, the SQL license component alone jumped to ~870 USD per month.

Same VM.
Same workload.
Same databases.
Almost 12× higher SQL cost.

What changed — in practice

• SQL Server Web Edition is discontinued in 2025
• SQL Server 2022 Web Edition remains supported, but only as a temporary safe harbor until 2033
• Standard Edition becomes the lowest “future-proof” option
• Licensing is per-core, and costs scale aggressively with CPU count
• Even modest VMs suddenly become expensive SQL hosts

My takeaway

SQL Server Web Edition disappearing is not just a line in the release notes — it’s a budget-changing event.

If you’re running Web Edition today, my advice is simple: audit your environments now and calculate what Standard Edition will really cost you — before SQL Server 2025 forces the conversation.

Sometimes the most expensive SQL feature is not a feature at all — it’s the edition.

SET STATISTICS PROFILE , when enabled, returns detailed information about the execution of a query. This includes the execution plan and the number of rows affected by each operation. The command is helpful for understanding how SQL Server executes a query and where potential bottlenecks might be.

When SET STATISTICS PROFILE is ON, SQL Server returns two result sets. The first is the regular result of the query, and the second is a detailed report showing the actual execution plan with runtime statistics.

Syntax

SET STATISTICS PROFILE { ON | OFF }

How to Use SET STATISTICS PROFILE

To use SET STATISTICS PROFILE, you simply turn it ON before running your query and then turn it OFF afterward. Below is a step-by-step guide with a practical example.

Practical Example

Consider a scenario where you have a database with the following table:

CREATE TABLE Employees (
    EmployeeID INT PRIMARY KEY,
    FirstName NVARCHAR(50),
    LastName NVARCHAR(50),
    Department NVARCHAR(50),
    Salary DECIMAL(10, 2)
);

Let’s populate this table with some sample data:

INSERT INTO Employees (EmployeeID, FirstName, LastName, Department, Salary) VALUES
(1, 'John', 'Doe', 'Engineering', 60000),
(2, 'Jane', 'Smith', 'Marketing', 50000),
(3, 'Sam', 'Brown', 'Engineering', 75000),
(4, 'Sue', 'Johnson', 'HR', 45000);

Now, suppose you want to analyze the performance of a query that retrieves all employees from the Engineering department:

SET STATISTICS PROFILE ON;

SELECT * FROM Employees WHERE Department = 'Engineering';

SET STATISTICS PROFILE OFF;

Understanding the Output

When you run the above commands, SQL Server will return the query results as usual. Additionally, it will provide a second result set with the execution plan and statistics. Here’s an example of what the output might look like:

Key Columns in the Output

• StmtText: The text of the SQL statement being executed.
• NodeId: The identifier for the operation node within the execution plan.
• PhysicalOp: The physical operation performed (e.g., Index Scan, Table Scan).
• LogicalOp: The logical operation performed (e.g., Filter, Join).
• EstimateRows: The estimated number of rows that will be processed.
• EstimateIO: The estimated I/O cost.
• EstimateCPU: The estimated CPU cost.
• TotalSubtreeCost: The estimated total cost of the query.
• OutputList: The list of columns output by this operation.

Benefits of Using SET STATISTICS PROFILE

• Detailed Insights: Provides detailed execution plans with actual runtime statistics.
• Performance Tuning: Helps identify bottlenecks and inefficient operations in queries.
• Optimization: Assists in optimizing queries by giving visibility into the execution process.

Conclusion

SET STATISTICS PROFILE is a powerful tool in SQL Server for anyone looking to optimize their queries and improve performance. By providing detailed execution plans and runtime statistics, it allows developers and DBAs to gain a deeper understanding of how their queries are executed and where they can make improvements. Utilizing this command effectively can lead to significant performance gains and more efficient database operations.

Temporary stored procedures are created in the same way as temporary tables – by adding one or two # before their name. Based on this, they are distinguished as local and global, similar to temporary tables:

• local (#)
  • created by adding one hashtag (#) before their name
  • visible only in the connection (SPID) in which they were created
  • automatically removed after the connection is closed
  • can only be called by their creator – the owner (logically, the login that owns the active connection)
  • cannot grant the right to call them to other users
• global (##)
  • created by adding two hashtags (##) before their name
  • visible to all connections (SPIDs) of the given instance
  • automatically removed after the last connection using them is closed
  • can be called by all users and this right cannot be revoked

Temporary stored procedures can be created by all users and this right cannot be revoked.

An example of a simple local stored procedure might look like this:

CREATE PROCEDURE #PrintMessageUpperCase (
    @Msg NVARCHAR(100)
)
AS
BEGIN
    
     PRINT UPPER(@Msg)

END
GO

EXECUTE [dbo].[#PrintMessageUpperCase] @Msg = N'Test Message'
GO

DROP PROCEDURE [dbo].[#PrintMessageUpperCase]
GO

The use of temporary stored procedures is really useful in various deployment scenarios of database changes, where we need to run more complex scripts or achieve the desired behavior of SQL Server by wrapping the code in a stored procedure. Similarly, they are excellent for testing various optimizations, etc. In the end, we do not need to worry about cleaning the database of temporary objects.

What we really need to be careful about is security: EXECUTE rights cannot be restricted for global temporary stored procedures, so code that a user would not normally have access to can be run from another session.

What is the Maximum Column Limit?

In SQL Server, the maximum number of expressions (columns) that can be included in the SELECT list of a query is 4096. This limit is significant because it affects how data can be queried and structured within SQL Server. Exceeding this limit results in an error, preventing the execution of the query.

Why Does This Limit Exist?

The limit is primarily in place to ensure performance and manageability. SQL Server is optimized for handling queries that meet certain structural criteria, and overly large queries can degrade performance, not only for the query itself but for the server as a whole. By imposing a limit on the number of expressions in a SELECT list, SQL Server helps ensure that queries are designed efficiently and that system resources are not overwhelmed.

Demonstrating the Error

To illustrate what happens when the limit is exceeded, let’s look at a dynamic SQL script designed to create and execute a SELECT statement with more than 4096 columns. Here’s the script:

DECLARE @sql AS NVARCHAR(MAX);

-- Initialize the SQL statement
SET @sql = 'SELECT ';

-- Generate more than 4096 columns
DECLARE @i INT = 1;
WHILE @i <= 4100
BEGIN
    IF @i = 1
        SET @sql = @sql + ' ' + CAST(@i AS VARCHAR) + ' AS Col' + CAST(@i AS VARCHAR)
    ELSE
        SET @sql = @sql + ', ' + CAST(@i AS VARCHAR) + ' AS Col' + CAST(@i AS VARCHAR);
    
    SET @i = @i + 1;
END

PRINT @sql

-- Execute the dynamic SQL
EXEC [sys].[sp_executesql] @sql;

A loop runs from 1 to 4100, adding columns to the SQL command. Each iteration adds a new column named Col1, Col2, etc., until Col4100. The SQL command stored in @sql is then executed using sp_executesql. Since the command attempts to select more than 4096 columns, SQL Server will throw an error stating that the maximum number of columns in the SELECT statement has been exceeded:

Msg 1056, Level 15, State 1, Line 1
The number of elements in the select list exceeds the maximum allowed number of 4096 elements.

Conclusion

Understanding limitations such as the maximum number of expressions in a SELECT list is crucial for SQL Server developers to avoid runtime errors and design efficient queries. This knowledge ensures that database applications are robust, performant, and scalable.

Internal Implementation and Metadata

Internally, SQL Server implements sparse columns by not physically storing NULL values. Non-NULL values in sparse columns consume more storage space than their non-sparse counterparts due to the overhead associated with maintaining sparsity. This trade-off means that while sparse columns can significantly reduce the storage footprint of highly null columns, they might increase the size of columns with a low proportion of NULL values.

To manage sparse columns, SQL Server uses a special kind of row structure that includes a column set, which is an XML representation of all the sparse columns in a table. This column set is not stored physically in the table but can be queried to retrieve data from sparse columns as if they were part of a single XML document.

To explore metadata related to sparse columns in the current database, you can use the following query, which leverages the sys.columns catalog view:

SELECT
    OBJECT_NAME([object_id]) AS [TableName], [name] AS [ColumnName], [is_sparse]
FROM [sys].[columns]
WHERE [is_sparse] = 1

This query lists all sparse columns in the database, providing insights into which tables and columns are utilizing this feature.

Test it

This script is designed to demonstrate the storage efficiency of sparse columns in SQL Server compared to standard nullable columns when dealing with a large volume of NULL values:

SET NOCOUNT ON

DROP TABLE IF EXISTS [dbo].[StandardNulls]
DROP TABLE IF EXISTS [dbo].[SparseNulls]

CREATE TABLE [dbo].[StandardNulls] (
    [StandardNull] INT NULL
)

CREATE TABLE [dbo].[SparseNulls] (
    [SparseNull] INT SPARSE
)

DECLARE @i INT = 0
WHILE @i < 100000
BEGIN
    
	INSERT INTO [StandardNulls] ([StandardNull])
		VALUES (CASE WHEN @i % 1000 = 0 THEN @i ELSE NULL END)
    
	INSERT INTO [SparseNulls] ([SparseNull])
		VALUES (CASE WHEN @i % 1000 = 0 THEN @i ELSE NULL END)

	SET @i = @i + 1
END

EXEC [sp_spaceused] @objname = '[dbo].[StandardNulls]'
EXEC [sp_spaceused] @objname = '[dbo].[SparseNulls]'
GO

Let’s demonstrate it.

We will create two tables and fill in some data. These tables are absolutely the same including the IDENTITY specification. The only difference is their name.

DROP TABLE IF EXISTS [dbo].[To_Be_Deleted]
DROP TABLE IF EXISTS [dbo].[To_Be_Truncated]
GO

CREATE TABLE [dbo].[To_Be_Deleted] (
	Id INT IDENTITY(1,1) NOT NULL PRIMARY KEY
)
GO
CREATE TABLE [dbo].[To_Be_Truncated] (
	Id INT IDENTITY(1,1) NOT NULL PRIMARY KEY
)
GO

INSERT INTO [dbo].[To_Be_Deleted] DEFAULT VALUES
INSERT INTO [dbo].[To_Be_Deleted] DEFAULT VALUES
INSERT INTO [dbo].[To_Be_Deleted] DEFAULT VALUES
GO
INSERT INTO [dbo].[To_Be_Truncated] DEFAULT VALUES
INSERT INTO [dbo].[To_Be_Truncated] DEFAULT VALUES
INSERT INTO [dbo].[To_Be_Truncated] DEFAULT VALUES
GO

SELECT 'To_Be_Deleted', * FROM [dbo].[To_Be_Deleted] UNION ALL
SELECT 'To_Be_Truncated', * FROM [dbo].[To_Be_Truncated]
GO

We will also check the current identity value after data is inserted. It’s the same.

SELECT 'To_Be_Deleted',	'IDENT_CURRENT', IDENT_CURRENT('[dbo].[To_Be_Deleted]') UNION ALL
SELECT 'To_Be_Truncated', 'IDENT_CURRENT', IDENT_CURRENT('[dbo].[To_Be_Truncated]')
GO

Now is time to remove data from our tables. There is a difference coming: We will empty the first table via the DELETE command and the second one will be emptied using the TRUNCATE command.

DELETE FROM [dbo].[To_Be_Deleted]
TRUNCATE TABLE [dbo].[To_Be_Truncated]
GO

DBCC CHECKIDENT('[dbo].[To_Be_Deleted]', RESEED, 1)
DBCC CHECKIDENT('[dbo].[To_Be_Truncated]', RESEED, 1)
GO

SELECT 'To_Be_Deleted',	'IDENT_CURRENT', IDENT_CURRENT('[dbo].[To_Be_Deleted]') UNION ALL
SELECT 'To_Be_Truncated', 'IDENT_CURRENT', IDENT_CURRENT('[dbo].[To_Be_Truncated]')
GO

We will check the current identity value now: It’s the same.

Next, we will again insert some data into our tables. Exactly as before.

INSERT INTO [dbo].[To_Be_Deleted] DEFAULT VALUES
INSERT INTO [dbo].[To_Be_Deleted] DEFAULT VALUES
INSERT INTO [dbo].[To_Be_Deleted] DEFAULT VALUES
GO

INSERT INTO [dbo].[To_Be_Truncated] DEFAULT VALUES
INSERT INTO [dbo].[To_Be_Truncated] DEFAULT VALUES
INSERT INTO [dbo].[To_Be_Truncated] DEFAULT VALUES
GO

SELECT 'To_Be_Deleted', * FROM [dbo].[To_Be_Deleted] UNION ALL
SELECT 'To_Be_Truncated', * FROM [dbo].[To_Be_Truncated]
GO

SELECT 'To_Be_Deleted', 'IDENT_CURRENT', IDENT_CURRENT('[dbo].[To_Be_Deleted]') UNION ALL
SELECT 'To_Be_Truncated', 'IDENT_CURRENT', IDENT_CURRENT('[dbo].[To_Be_Truncated]')
GO

If we will check data in both tables, there is the surprise immediately visible:

The table which was emptied using the DELETE command has the first identity value 2 whereas the second table emptied using the TRUNCATE command has the first identity value 1!

This difference is also approved via the IDENT_CURRENT() function.

I know that this behavior isn’t too intuitive at first look. But what is positive (only:) about it is that it’s properly documented at the right place in the DBCC CHECKIDENT() command description:

The current identity value is set to the new_reseed_value. If no rows have been inserted into the table since the table was created, or if all rows have been removed by using the TRUNCATE TABLE statement, the first row inserted after you run DBCC CHECKIDENT uses new_reseed_value as the identity. If rows are present in the table, or if all rows have been removed by using the DELETE statement, the next row inserted uses new_reseed_value + the current increment value.

To be honest, seniors should know, for sure. But juniors are spending hours investigating this based on my experience. There is a good comparison of DELETE vs TRUNCATE on sqlhack.com, but still, the RESEED issue isn’t clearly explained there.

We will build a scalar function that will replace two HTML tags in the input string with string literals used for tags escaping. We will also build the same function as Inlined because that solution was used before SQL 2019 to address most of the scalar functions related issues. Table dbo.SamleTable will be filled with 100k records to be used in this test.

USE [tempdb]
GO

-- Scalar Function
CREATE FUNCTION [dbo].[f_Scalar_ReplaceHTMLTags](
	@Data NVARCHAR(MAX)
)
RETURNS NVARCHAR(MAX)
BEGIN
	
	RETURN REPLACE(REPLACE(@Data, '<', '&lt;'), '>', '&gt;')

END
GO

-- Inlined function
CREATE FUNCTION [dbo].[f_Inline_ReplaceHTMLTags](
	@Data NVARCHAR(MAX)
)
RETURNS TABLE
AS
	
	RETURN (SELECT REPLACE(REPLACE(@Data, '<', '&lt;'), '>', '&gt;') [Data])
GO

-- Sample data with 100k records
CREATE TABLE [dbo].[SampleTable] (
	[Data] NVARCHAR(MAX)
)

INSERT INTO [dbo].[SampleTable]
	( [Data] )
SELECT TOP 100000
	REPLICATE('<' + 'HTML_Tag_Name' + '>', 100)
FROM [msdb].[sys].[columns] [c1]
	CROSS JOIN [msdb].[sys].[columns] [c2]
GO

Let’s run two queries against the sample data and compare it between SQL Server 2019 and 2017 and review execution plans generated and query statistics. The first query will use the scalar function, the second one is using CROSS APPLY with the inlined function.

SET STATISTICS TIME ON
SET STATISTICS IO ON
GO

SELECT 
	[dbo].[f_Scalar_ReplaceHTMLTags]([Data]) [ReplacedData]
	INTO [#tmp1]
FROM [dbo].[SampleTable]
GO

SELECT 
	[f].[Data] [ReplacedData]
	INTO [#tmp2]
FROM [dbo].[SampleTable] [st]
	CROSS APPLY [dbo].[f_Inline_ReplaceHTMLTags]([st].[Data]) [f]
GO

SQL 2017

SQL 2019

2017

CPU time = 44797 ms, elapsed time = 55845 ms. Table ‘SampleTable’. Scan count 5, logical reads 50000.
CPU time = 41189 ms, elapsed time = 10511 ms. Table ‘SampleTable’. Scan count 5, logical reads 50000.

2019

CPU time = 34171 ms, elapsed time = 12179 ms. Table ‘SampleTable’. Scan count 5, logical reads 50000.
CPU time = 33828 ms, elapsed time = 15719 ms. Table ‘SampleTable’. Scan count 5, logical reads 50000

As we can see the only difference in execution plans is that in 2017 scalar function was blocking optimizer from parallel plan creation. We can get rid of this issue when an inlined version of the function will be used. This workaround is not necessary for then SQL Server 2019 where the scalar function was successfully inlined and the same parallel plan was generated for both queries (scalar and inlined).