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'

In this post, I am sharing the use of sp_estimate_data_compression_savings system stored procedure which we can use to check the object size + object expected saving space in SQL Server.

Many times, I have found that people are using CHAR data type for fix length store, but it is also true that people are not storing a correct length of data in CHAR column.

I just gave one example of CHAR column; there might be many reasons where we have to check the table actual size and the size of saving space.

Once we got the actual size and expected saving space, we can apply proper compression algorithm on objects. If your table has multiple indexes, you can compare space of all indexes and can take the decision to which index requires to compress.

We can use sp_estimate_data_compression_savings for the table of a clustered index, non-clustered index and heap table. You can also evaluate object for ROW size and PAGE SIZE.

Check the below small demonstration on this:

Create a sample table:

CREATE TABLE tbl_DumpData
(
	ID INT 
	,RandomNumber BIGINT
	,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 <= 1000000
)
INSERT INTO tbl_DumpData(ID,RandomNumber)
SELECT 
	ID
	,convert(int, convert (varbinary(4), NEWID(), 1)) AS RandomNumber
FROM CTE 
OPTION (MAXRECURSION 0)
GO

Check the inserted records:

SELECT *
FROM tbl_DumpData

Check space for ROW:

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

Result: Check the difference between size_with_current_compression_setting and size_with_requested_compression_setting

After data compression, we can make the object size upto size_with_requested_compression_setting.

Check space for PAGE:

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

Result: Check the difference between size_with_current_compression_setting and size_with_requested_compression_setting

After data compression, we can make the object size upto size_with_requested_compression_setting.