Part I

Table Optimizations
Objectives

 Partitioning Concepts
 Implementing Partitioning
 Sliding Windows
 Table Compression
 Memory-Optimized Tables
What is Table Partitioning
 Partitioning is a performance optimization
for large tables and indexes that splits the
object horizontally into smaller units.
 Only the required partitions to be read, as
opposed to the entire table.
 Each partition can be stored on a separate
filegroup.
Table Partitioning
Partitioning Concepts
 Partitioning key used to determine in which
partition each row of the table should be placed.
 If table has a clustered index, then the
partitioning key must be a subset of the clustered
index key.
 All other UNIQUE indexes on the table,
including the primary key, also need to include
the partitioning key.
 Partitioning Key can be a computed column
 The column you select should also be a column
that queries will use as a filter criterion.
Partition Function
Boundary points to set the upper and lower
limits of each partition.

Boundary points are configured in a database

object called the partition function.
When creating the partition function

CREATE PARTITION FUNCTION myRangePF2 (int)

AS RANGE RIGHT FOR VALUES (1, 100, 1000);
Partition Function
When creating the partition function
 RANGE LEFT FOR VALUES (1, 100, 1000)

 RANGE RIGHT FOR VALUES (1, 100, 1000)

The partition function also dictates the data type of the

partitioning key.
Partition Scheme
Each partition can be stored on a separate filegroup.
Partition scheme is an object, specifying which
filegroup each partition will be stored on.
Examples :
CREATE PARTITION FUNCTION myRangePF1 (INT)
AS RANGE LEFT FOR VALUES (1, 100, 1000);
GO
CREATE PARTITION SCHEME myRangePS1
AS PARTITION myRangePF1
TO (test1fg, test2fg, test3fg, test4fg);
Partitioning Hierarchy
Implementing Partitioning
Implementing partitioning involves creating the
partition function and partition scheme.
Creating the Partition Function
OrderNumber int
CREATE PARTITION FUNCTION
OrderDate date
PartFunc(Date)
CustomerID int
AS RANGE LEFT
ProductID int
FOR VALUES('2017-01-01',
Quantity int
'2019-01-01') ;
NetAmount money Creating the Partition Scheme
TaxAmount money
CREATE PARTITION SCHEME
InvoiceAddressID int
PartScheme
DeliveryAddressID int
AS PARTITION PartFunc
DeliveryDate date ALL TO ([PRIMARY]) ;
Implementing Partitioning
Creating a New Partitioned Table
CREATE TABLE dbo.Orders
(
OrderNumber int NOT NULL,
OrderDate date NOT NULL,
CustomerID int NOT NULL,
ProductID int NOT NULL,
Quantity int NOT NULL,
NetAmount money NOT NULL,
TaxAmount money NOT NULL,
InvoiceAddressID int NOT NULL,
DeliveryAddressID int NOT NULL,
DeliveryDate date NULL
) ON PartScheme(OrderDate) ;
Partitioning an Existing Table
Clustered index is always aligned with the base
table, the process of moving a table to a partition
scheme is as simple as dropping the clustered
index and then re-creating the clustered index on
the partition scheme.
CREATE TABLE dbo.ExistingOrders …Primary Key …
ALTER TABLE dbo.ExistingOrders DROP CONSTRAINT
PK_ExistingOrders …
ALTER TABLE dbo.ExistingOrders ADD CONSTRAINT
PK_ExistingOrders PRIMARY KEY CLUSTERED(…)
ON PartScheme(OrderDate) ;
Partitioning an Existing Table
Keep track of the number of rows in each
partition of table to ensure that rows are being
distributed evenly. There are two methods :
$PARTITION function and the Disk Usage by
Partition SSMS Report.
Partitioning an Existing Table
Using the $PARTITION function to assess
how a table would be partitioned against a
different partition function.
Sliding Windows
SQL Server provides us with the tools to create sliding
windows, using the SPLIT, MERGE, and SWITCH
operations.
 SPLIT operation adds a new boundary point, thus
creating a new partition.
 MERGE operation removes a boundary point, thus
merging two partitions together.
 SWITCH operation moves a partition into an empty
table or partition. SWITCH is a metadata operation,
and therefore, both partitions involved must reside on
the same filegroup.
Sliding Windows
SELECT
COUNT(*) 'Number of Rows'
,$PARTITION.thoigianxuat(thoigian) 'Partition'
FROM dbo.phieuxuat2
GROUP BY $PARTITION.thoigianxuat(thoigian) ;
--Switch the oldest partition to the phieuxuatStaging table
ALTER TABLE phieuxuat2
SWITCH PARTITION 1 TO phieuxuatStaging PARTITION 1;
--Remove the oldest partition
ALTER PARTITION FUNCTION thoigian()
MERGE RANGE(201701) ;
--Create the new partition
ALTER PARTITION FUNCTION thoigian()
SPLIT RANGE(201901) ;
Table Compression
 Compression in SQL Server can actually offer a
performance benefit.

 This means that if SQL Server needs to read

dramatically fewer pages from disk, then
performance will increase, even if this is at the
expense of CPU cycles.
Row Compression
When row compression is implemented for a table,
SQL Server uses the minimum amount of storage for
other data types as well.
Row Compression
For example :
An integer column : contain a NULL value in row 1, a
value of 50 in row 2, and a value of 40,000 in row 3.
 in row 1, column does not use any space at all; it
uses 1 byte in row 2 (TINYINT); and it uses 4 bytes
in row 3 (INT).
This is opposed to an uncompressed table using 4
bytes for every row, including row 1.

SQL Server also compresses Unicode columns so that

characters can be stored as a single byte, instead of 2
bytes when uncompressed.
Page Compression
When implementing page compression, row
compression is implemented first, comprised of two
different forms of compression : prefix compression
and dictionary compression.
Page Compression - Prefix Compression
Establishing a common prefix for a column
across rows within a page.

SQL Server chooses the longest value that

contains the full prefix as the anchor row and
stores all other values within the column, as a
differential of the anchor row.
Page Compression - Prefix Compression
Page Compression - Dictionary Compression
 Dictionary compression is performed after
all columns have been compressed using
prefix compression.
 It looks across all columns within a page and
finds values that match. The matching is
performed using the binary representation of
a value.
 When it finds duplicate values, it adds them
to a special dictionary at the top of the page,
and in the row, it simply stores a pointer to
the value’s location in the dictionary.
Page Compression - Dictionary Compression
Page Compression Structure
A special row is inserted in the page immediately
after the page header, containing the information
regarding the anchor record and dictionary.
Columnstore Compression
Columnstore indexes are always compressed,
automatically.
Create a clustered columnstore index on table
then table is also compressed.

Two types of columnstore compression :

COLUMNSTORE and COLUMNSTORE_ARCHIVE.
Implementing Compression
Selecting the Compression Level : row, page,
columnstore_archieve, none

EXEC sp_estimate_data_compression_savings 'dbo',

'ExistingOrders',NULL, NULL, 'ROW' ;

EXEC sp_estimate_data_compression_savings 'dbo',

'ExistingOrders',NULL, NULL, 'PAGE' ;
Implementing Compression
Compressing Tables and Partitions
Implementing Row Compression on the Entire Table
ALTER TABLE ExistingOrders
REBUILD WITH (DATA_COMPRESSION = ROW) ;
Implementing Row Compression for Specific Partitions
ALTER TABLE ExistingOrders
REBUILD PARTITION = 1 WITH (DATA_COMPRESSION =
ROW) ;
Remove compression from the whole table
ALTER TABLE ExistingOrders
REBUILD WITH (DATA_COMPRESSION = NONE) ;
Memory-Optimized Tables
The primary storage for memory-optimized
tables is the main memory.

Rows in the table are read from and written to

memory.
Memory-Optimized Tables
Storage for memory-optimized tables has following key
attributes:
 All memory-optimized tables are mapped to a
memory-optimized data-filegroup.
 There are no pages and the data is persisted as a row.
 All changes to memory-optimized tables are stored
by appending to active files.
 An update is implemented as a delete followed by an
insert.
 Unlike disk-based tables, storage for memory-
optimized tables is not compressed.
 A memory-optimized table can be durable or can be
non-durable.
Memory-Optimized Tables
 Rows in memory-optimized tables are
versioned, each row in the table potentially has
multiple versions.
 An automatic checkpoint is taken when
transaction log file becomes bigger than 1.5
GB since the last checkpoint.
 Memory-optimized tables support the
following types of indexes:
o Nonclustered hash index
o Nonclustered index