SQL Server 2014 introduced WAIT_AT_LOW_PRIORITY option which enhanced the performance of ONLINE REBUILD INDEX.

In the previous version of SQL Server, REBUILD INDEX had to wait for the running transaction.
But now in SQL Server 2014, you can give options like MAX_DURATION in minutes, ABORT_AFTER_WAIT with different options.

For ABORT_AFTER_WAIT, took the reference from Microsoft:

ABORT_AFTER_WAIT = [NONE | SELF | BLOCKERS]

NONE: Continue waiting for the lock with normal (regular) priority.

SELF: Exit the online index rebuild DDL operation currently being executed without taking any action.

BLOCKERS: Kill all user transactions that block the online index rebuild DDL operation so that the operation can continue. The BLOCKERS option requires the login to have ALTER ANY CONNECTION permission.

Please check the below demonstration, where I am comparing old and new approach of REBUILD INDEX:

Create a sample table:

CREATE TABLE tbl_DumpData
(
	ID INT 
	,RandomID VARCHAR(MAX)
	,CONSTRAINT pk_tbl_DumpData_ID PRIMARY KEY(ID)
)
GO

Insert dummy data:

;WITH CTE AS
(
	SELECT 1 ID
	UNION all
	SELECT ID + 1
	FROM CTE   
	WHERE ID + 1 <= 100000
)
INSERT INTO tbl_DumpData(ID,RandomID)
SELECT 
	ID
	,NEWID() AS RandomID
FROM CTE 
OPTION (MAXRECURSION 0)
GO

Open new session/query window, execute below update:

BEGIN TRANSACTION
UPDATE tbl_DumpData SET RandomID = 39840972340234 WHERE ID = 8

Jump to old session window, and execute below REBUILD:
It is Running… Running… Running…, because table is locked by another transaction

ALTER INDEX pk_tbl_DumpData_ID ON tbl_DumpData REBUILD
WITH
(
   ONLINE = ON
)
GO

Check the lock table:
You can find that your REBUILD query is in WAIT mode.

SELECT *FROM sys.dm_tran_locks

Now stop the execution of the previous REBUILD, and execute below REBUILD WITH WAIT_AT_LOW_PRIORITY:
Set MAX_DURATION for one minute and ABORT_AFTER_WAIT type is SELF.

ALTER INDEX pk_tbl_DumpData_ID ON tbl_DumpData REBUILD
WITH
(
   ONLINE = ON
   (
	WAIT_AT_LOW_PRIORITY 
	(
		MAX_DURATION = 1
		,ABORT_AFTER_WAIT = SELF
	)
   )
)
GO

Above REBUILD will wait for One minute and then it will throw an error message:

Msg 1222, Level 16, State 56, Line 1
Lock request time out period exceeded.

Now, test with BLOCKER option:
It will wait for one minute, and then it will kill the open UPDATE transaction to finish the REBUILD operation.

ALTER INDEX pk_tbl_DumpData_ID ON tbl_DumpData REBUILD
WITH
(
   ONLINE = ON
   (
	WAIT_AT_LOW_PRIORITY 
	(
		MAX_DURATION = 1
		,ABORT_AFTER_WAIT = BLOCKERS 
	)
   )
)
GO

Now, go to another transaction where UPDATE transaction was there:
Try to execute any query, you will get below error message because this session is terminated by REBUILD + BLOCKERS.

SELECT *FROM tbl_DumpData

Error:

Msg 0, Level 20, State 0, Line 0
The connection is broken and recovery is not possible.  The connection is marked by the server as unrecoverable.  No attempt was made to restore the connection.

In the previous two posts, I shared basic about Forwarding Records of Heap Table and shared a script to find the count of Forwarded Records in SQL Server.

In this post, I am sharing a practical demonstration on Forwarding Records like generate Forwarding Records and then Remove those Forwarding Records.

Please check the below full demonstration:

Create a sample HEAP table:

CREATE TABLE tbl_Heap
(
	Col1 INT IDENTITY(1,1)
	,Col2 VARCHAR(1000)	
)
GO

Insert sample records with VARCHAR(5) size:

INSERT INTO tbl_Heap (Col2) VALUES
('dbrnd')
GO 1000

Now, Update the data from VARCHAR(5) to VARCHAR(31):

UPDATE tbl_Heap
SET Col2 = 'Database Research & Development'
GO

Check the count of Forwarding Records:

For removing Forwarding Records, we should REBUILD the table:

ALTER TABLE tbl_Heap REBUILD
GO

Now, Check the new count of Forwarding Records:
The count is 0 now.

To complete this article, you must visit my yesterday’s post where I explained about the use of sp_estimate_data_compression_savings system stored procedure of SQL Server.

In this post, I continue my demonstration and am using the same example of a table from the previous post. SQL Server 2016 introduced the Data Compression algorithm for compressing or reducing the size of an object.

For more detail – visit this official LINK.

In this previous post, We can see 40% space that we can reduce of a tbl_Dumpdata table.

How?

I created a clustered index on that table, so for data compression, we have to REBUILD that index with option DATA_COMPRESSION.

Rebuild Index with DATA_COMPRESSION:

ALTER INDEX pk_tbl_DumpData_ID 
ON dbo.tbl_DumpData
REBUILD PARTITION = ALL 
WITH (DATA_COMPRESSION = PAGE)
GO

Now, check the space for PAGE option:
Check the below result, you can find the same value of column size_with_current_compression_setting and size_with_requested_compression_setting.

EXEC sp_estimate_data_compression_savings 
    @schema_name = 'dbo', 
    @object_name = 'tbl_DumpData', 
    @index_id = NULL, 
    @partition_number = NULL, 
    @data_compression = 'PAGE'