Module 3

Advanced Table Designs

Module Overview

• Partitioning Data
• Compressing Data
• Temporal Tables
Lesson 1: Partitioning Data

• Common Scenarios for Partitioning

• Partition Functions
• Partition Schemes
• Creating a Partitioned Table
• Partitioned Indexes
• SWITCH, MERGE and SPLIT Operations
• Designing Partition Strategies for Common
Scenarios
• Demonstration: Creating a Partitioned Table
Common Scenarios for Partitioning

• Partitioned tables and indexes make managing

large tables more efficient
• Tables are partitioned horizontally in rows
• Common scenarios for table partitioning include:
• Implementing a sliding window: move data into and
out of tables based on date ranges
• Separating maintenance operations: perform
maintenance operations, such as rebuilding and
reorganizing indexes on a partition-by-partition basis,
which is more efficient than doing it for the whole table
• Performing partial backups: use multiple filegroups to
store partitioned tables and indexes
• Available in all editions after SQL 2016 SP1
Partition Functions

• When partitioning data, it is common practice to

partition using a datetime value
• Use CREATE PARTITION FUNCTION statement
• RANGE LEFT
• The default value
• The maximum value of the partition boundary
• RANGE RIGHT
• The minimum value of the partition boundary
• The function can be used on multiple objects
Partition Schemes

• Partition schemes map table or index partitions

to filegroups:
• Common practice to use one filegroup per partition
• Use multiple filegroups for your partitioned tables to
back up discrete parts of the table
• Partitioned data can be stored in a single filegroup, but
best for read-only data
• A partition function must be created before creating
the partition scheme
Creating a Partitioned Table

• Use the CREATE TABLE statement to create a

partitioned table
• Specify the partition scheme in the ON clause
• The scheme determines the filegroup for each row
• The scheme uses a partitioning key column to
determine how each row is partitioned
• The data type of this column must match the type
declared in the scheme
Partitioned Indexes

• Use CREATE INDEX or CREATE TABLE to create an

index:
• Partition the index using the ON clause to specify
schema
• Nonclustered indexes can use a different partition
scheme to the table
• Clustered index must use the same scheme as the table
• The column used for partition does not have to be part
of the index
• Indexes using same scheme as table are aligned
• Rebuild or reorganize the entire index, or one
partition
SWITCH, MERGE and SPLIT Operations

• Use the following functions to manage partitions:

• SPLIT
• Add a new boundary to split a single partition into two
partitions
• SWITCH
• Switch a partition between partitioned tables, or between a
partitioned table and a nonpartitioned table
• MERGE
• Remove a boundary to merge two partitions into a single
partition
Designing Partition Strategies for Common
Scenarios

• Use SWITCH, MERGE, and SPLIT to implement a

sliding window strategy to archive or purge data
• Switch old data to a staging table, and then
archive it
• Efficient—as metadata is updated, data is not
moved
• Considerations:
• Choose partition boundary carefully, as SQL Server
performs explicit rounding of time in datetime values
• Create a CHECK constraint on the staging table to
which you will switch the partition so it contains the
same dates; NULLs are not allowed
Demonstration: Creating a Partitioned Table

• In this demonstration, you will see how to

partition data
Lesson 2: Compressing Data

• Why Compress Data?

• Page Compression
• Row Compression
• Unicode Compression
• Considerations for Compression
• Demonstration: Compressing Data
Why Compress Data?

• Data compression:
• Helps save storage space
• Improves performance for workloads requiring heavy
disk I/O activity, as queries accessing compressed data
retrieve fewer pages
• Can be added to the following objects:
• Tables stored as heaps
• Tables stored as clustered indexes
• Nonclustered indexes
• Indexed views
• Individual partitions
• Spatial indexes
Page Compression

• Page compression:
• Adds a compression information (CI) structure below
the page header on each compressed page
• Takes advantage of data redundancy to claim space

• Compresses data in three ways:

• Row compression: page compression incorporates row
compression
• Prefix compression: replaces common prefix values
with smaller identifier, which is stored in the CI
structure
• Dictionary compression: similar to prefix, but replaces
repeated values with smaller identifier, also stored in
the CI structure
Row Compression

• Row compression:
• Saves space by storing fixed length data types as
variable length, such as integer types
• Does not work with variable length data types, XML,
image, text and ntext
• Adds an extra four bits to each compressed column to
store the length of the data type
• For NULL values, the four bits is the only space consumed
Unicode Compression

• Unicode compression uses the Standard

Compression Scheme for Unicode (SCSU)
algorithm
• nchar(n) and nvarchar(n) data types automatically
compressed with SCSU
• nvarchar(MAX) can be compressed with page but
not row compression
• Compression ratio varies between different
languages: English yields 50% savings, Japanese
yields 15%
Considerations for Compression

• Plan compression to save storage space:

• Consider the characteristic of the data to decide
whether a table or index is a good candidate for
compression
• Consider compressing tables with many fixed data type
columns, or with large amounts of redundant data
• Plan compression to improve performance:
• Compression can reduce disk I/O and increase the
amount of data that SQL Server can hold in memory
• Compression increases CPU utilization
• Balance the performance benefit against the increased
CPU utilization
Demonstration: Compressing Data

• In this demonstration, you will see how to

compress data
Lesson 3: Temporal Tables

• What are System-Versioned Temporal Tables?

• Creating a Temporal Table
• Adding System-Versioning to an Existing Table
• Temporal Table Considerations
• System-Versioned Memory-Optimized Tables
• Demonstration: Adding System-Versioning to an
Existing Table
What are System-Versioned Temporal Tables?

• System-versioned tables store a full history of

data changes:
• Current and historical tables operate as a pair
• SysStartTime and SysEndTime columns store the valid
dates of the data
• Current table must have a primary key
• All versioning is automatic, no developer intervention
required
• Can be added to existing tables
• Historical table can be named, or take system name
Creating a Temporal Table

• To create a temporal table

• SysStartTime column—or another datetime2 column
• SysEndTIme column—or another datetime2 column
• SYSTEM_VERSIONING = ON
• Optionally name the HISTORY_TABLE
Adding System-Versioning to an Existing Table

• Convert an existing table to a system-versioned

table:
• Add the start and end date columns
• Set the system-versioning flag on
Temporal Table Considerations

• Considerations when using system-versioned

tables:
• SysStartTime and SysEndTime must be datatime2
• Current table must have a primary key
• To name the history table, must include schema name
• By default the history table is PAGE compressed
• History table must reside in same database
• Does not support FILETABLE or FILESTREAM
• Blob data types can result in high storage requirements
• Data in the historical table cannot be directly modified
• Current table cannot be truncated when
SYSTEM_VERSIONING is ON
System-Versioned Memory-Optimized Tables

• Considerations for system-versioned memory-optimized

tables:
• Durability of current table must be SCHEMA_AND_DATA
• Primary key on current table must be nonclustered index
• Internal staging table stores recent changes for fast querying.
Flushed to disk-based table on regular interval
• Staging table includes 8 bytes bigint column for uniqueness, so
max row size reduced to 8052 bytes
• Include HIDDEN keyword with the period columns to exclude
them from SELECT * queries
• Use FOR SYSTEM_TIME to query historical data, including a
subclause: AS OF, FROM TO, BETWEEN AND, CONTAINED IN, or
ALL
Demonstration: Adding System-Versioning to an
Existing Table

In this demonstration, you will see how:

• System-versioning can be added to an existing
table
• Changes to the data are stored in the system-
versioned table
Lab: Using Advanced Table Designs

• Exercise 1: Partitioning Data

• Exercise 2: Compressing Data

Logon Information
Virtual machine: 20762C-MIA-SQL
User name: ADVENTUREWORKS\Student
Password: Pa55w.rd

Estimated Time: 30 minutes

Lab Scenario

You are a database developer for Adventure

Works who will be designing solutions using
corporate databases stored in SQL Server. You
have been provided with a set of business
requirements and will implement partitioning to
archive older data, and data compression to
obtain optimal performance and storage from
your tables.
Lab Review

• Discuss scenarios that you have experienced

where you think partitioning would have been
beneficial. Have you worked with databases that
could have had older data archived? Were the
databases large enough to split the partitions
across physical drives for better performance, or
to quicken the backup process? Furthermore,
could any of this data be compressed? Give
reasons for your answers.
Module Review and Takeaways

• Review Question(s)
• Best Practice