Revisiting SQL Server Window Functions- A Practical Walkthrough
A look at window functions in SQL and how they can be used to query data without the restrictions of a GROUP BY.
2025-09-12
6,614 reads
A look at window functions in SQL and how they can be used to query data without the restrictions of a GROUP BY.
2025-09-12
6,614 reads
In Level 1 of the Stairway to Azure SQL Hyperscale, we learn about the architecture and create a hyperscale instance.
2025-09-03
3,460 reads
Page splits are an often-overlooked performance killer in SQL Server. In this article, we take a forensic look at how serial inserts differ from mid-table inserts, revealing why inserting rows out of order causes hidden page splits, increased IO, and fragmentation. Using a wide-column table, we demonstrate both scenarios and decode their impact with page-level analysis.
2025-09-02 (first published: 2025-08-05)
2,458 reads
TEXT, NTEXT, and IMAGE columns have been deprecated for nearly two decades, yet they still silently haunt many SQL Server environments. This article explains their hidden limitations with practical demos and shows why migrating to VARCHAR(MAX), NVARCHAR(MAX), and VARBINARY(MAX) is critical for modern performance, maintainability, and future upgrades.
2025-09-02 (first published: 2025-08-06)
2,221 reads
Most DBAs are familiar with full and differential ...
2025-09-02 (first published: 2025-08-01)
872 reads
Learn about delayed durability in SQL Server and how it might help you with a heavily loaded server.
2025-08-29
8,342 reads
Learn about the TABLESAMPLE option in T-SQL and uncover some of the pitfalls of assuming this works as you think it does.
2025-08-22
2,109 reads
When a SQL Server Express-based factory app started crawling, the culprit wasn’t hardware or network — it was a decades-old WHILE loop migrated from C/C++ to SQL. This real-world story breaks down how procedural habits, memory grants, and lack of window functions nearly derailed a production floor.
2025-07-28
14,337 reads
Introduction It was the week before Black Friday — the biggest online ad rush of the year. Our US-based ad-tech platform was gearing up for an insane traffic spike. Hundreds of real-time campaigns were about to go live across multiple brands, each with thousands of user sessions flowing through our system. Every incoming user impression […]
2025-07-22
2,362 reads
In this article, I wanted to test a common assumption we DBAs make – that adding INCLUDE columns to indexes is harmless. I created a FULL recovery test database with a realistic wide Orders table containing extra large VARCHAR columns to simulate an ERP workload. I ran updates and measured transaction log backup sizes before and after adding INCLUDE columns to a nonclustered index. The results shocked me. The update without INCLUDE columns generated a 10 MB log backup, while the same update with INCLUDE columns produced over 170 MB – a 17x increase in log volume. I explain why this happens: INCLUDE columns are physically stored in index leaf rows, so updates affecting them write bigger log records. I also clarify that updating key columns generates even more log than INCLUDE updates because it involves row movement (delete + insert), but INCLUDE updates still cost more log than if those columns weren’t indexed at all. The takeaway is clear – INCLUDE columns are powerful, but they silently increase transaction log generation, impacting backup sizes, replication lag, and DR readiness. Always measure their real cost before deploying to production.
2025-07-18
678 reads
By alevyinroc
T-SQL Tuesday is a monthly blog party hosted by a different community member each...
By DataOnWheels
It has been a while since my last T-SQL Tuesday blog. When I saw...
The last T-SQL Tuesday of the year is hosted by my good friend Mike...
Comments posted to this topic are about the item What is the PRODUCT
Comments posted to this topic are about the item Metadata Driven Pipelines (Incremental Load):...
Comments posted to this topic are about the item Metadata Driven Pipelines (Incremental Load):...
In SQL Server 2025, what does this return?
CREATE TABLE Numbers ( n INT) GO INSERT dbo.Numbers ( n ) VALUES (1), (2), (3) GO SELECT PRODUCT(n) FROM dbo.NumbersSee possible answers