1. Data Time Travel with Temporal Tables
Sam Nasr, MCSA, MVP
NIS Technologies
October 5, 2019

2. About Me Software Developer since 1995
Sam Nasr
Software Developer since 1995
Sr. Software Engineer (NIS Technologies)
Certifications: MCSA, MCAD, MCT, MCTS
President - Cleveland C#/VB.Net User Group
President - .Net Study Group
Author for Visual Studio Magazine
Microsoft Most Valuable Professional (since 2013)

3. General Info Down the hall (right side) Participation is encouraged
Please mute cell phones

4. Cleveland C#/VB.Net User Group
Meets every month
Free of charge , open to the public
All topics related to .Net
Meeting info:

5. Temporal Tables Temporal Table = System Versioned Table
Based on the ISO/ANSI SQL:2011 standard.
New Feature in SQL Server, not all Temporal features supported
Maintains current and past states of modified rows
Standard feature for all editions of SQL Server 2016
Implement via T-SQL, no additional configuration needed.
Application-Time Period Tables: where you can explicitly define the validity period of a row, including in the future.

6. T-SQL Requirements Primary Key
(2) Period columns (datetime2 type, any name, non-nullable)
Start column must include GENERATED ALWAYS AS ROW START
End column must include GENERATED ALWAYS AS ROW END
Designation: PERIOD FOR SYSTEM_TIME (<startcol>, <endcol>)
WITH SYSTEM_VERSIONING = ON
HISTORY_TABLE = DepartmentHistory
To actually turn on temporal for the table, we add WITH SYSTEM_VERSIONING = ON, and also set the name for the history table that SQL Server should create, and that must include the schema name; although if you leave out the HISTORY_TABLE name, SQL Server will generate one based on the main table’s internal object ID.
CREATE TABLE Department (
DepartmentID int NOT NULL IDENTITY(1,1) PRIMARY KEY,
DepartmentName varchar(50) NOT NULL,
ManagerID int NULL,
ValidFrom datetime2 GENERATED ALWAYS AS ROW START NOT NULL,
ValidTo datetime2 GENERATED ALWAYS AS ROW END NOT NULL,
PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo) )
WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = DepartmentHistory))

7. Enabling Temporal Existing Tables:
Must be done in two separate ALTER TABLE statements.
Set DEFAULT values that initialize the period columns with beginning-of-time ( :00: ) until end-of-time ( :59: )
Existing table:
Must be done in two separate ALTER TABLE statements.
Set DEFAULT values that initialize the period columns with beginning-of-time ( :00: ) until end-of-time ( :59: )
New table: CAN create and enable it in a single CREATE TABLE statement

8. Usage Scenarios
Allows for querying a table at a specific point-in-time
Slowly changing dimensions of a data warehouse
Auditing of when the change was made (not who)
Recovering from accidental loss of data
Anomaly Detection
Repairing row-level data corruption
Usage Scenarios:

9. Querying Temporal Tables
SELECT * FROM Department FOR SYSTEM_TIME AS OF DATEADD(d, -30, SYSDATETIME()) ORDER BY EmployeeId
Rows deleted in the past thirty days will be returned
Rows created in the past thirty days will NOT be returned.
Rows older than thirty days, but modified in the past 30 days are returned as they appeared exactly 30 days ago.

10. Sub clauses AS OF<date_time>
SysStartTime <= date_time AND SysEndTime > date_time
FROM<start_date_time>TO<end_date_time>
SysStartTime < end_date_time
AND
SysEndTime > start_date_time
BETWEEN<start_date_time>AND<end_date_time>
SysStartTime <= end_date_time
CONTAINED IN (<start_date_time> , <end_date_time>)
SysStartTime >= start_date_time
SysEndTime <= end_date_time
ALL
All rows

11. Demo
Temporal Tables
History table appears below the related current table.
SSMS identifies the tables as System-Versioned and History in parentheses.
Programmatically: OBJECTPROPERTY(TableTemporalType)
1 for a history table
2 for a system versioned table;
Default Name Pattern: MSSQL_TemporalHistoryFor_<object_id>.

12. Design Constraints
The column type FILESTREAM is not supported, as it stores data outside of the database.
The history table cannot be modified directly, you can only add to it by updating or deleting data from the current table.
INSTEAD OF triggers are not supported and AFTER triggers are only allowed on the current table.
You cannot change the schema of a Temporal Table without changing current table schema.
Changes to records of current table will reflect on Temporal Table automatically.
Indexing must be manually enabled
An optimal indexing strategy will include a clustered columns store index and / or a B-tree rowstore index on the current table and a clustered columnstore index on the history table for optimal storage size and performance.
If you create / use your own history table, we strongly recommend that you create such an index that consists of the primary keys from the current table plus the period columns to speed up temporal querying as well as the queries that are part of the data consistency check. If your history table is a rowstore, we recommend a clustered rowstore index.
The default history table has a clustered rowstore index created for you. At a minimum, a non-clustered rowstore index is recommended.
See

13. Schema Checks Before SYSTEM_VERSIONING = ON …
The names and number of columns is the same in both the current table and the history table.
The datatypes match for each column between the current table and the history table.
The period columns are set to NOT NULL.
The current table has a primary key constraint and the history table does not have a primary key constraint.
No table or column constraints are defined on the history table. However, default column values on the history table are permitted.
The history table is not configured for change tracking or change data capture.
The history table is not placed in a read-only filegroup.
No IDENTITY columns are defined in the history table.
No triggers are defined in the history table.
No foreign keys are defined in the history table.
Temporal Table System Consistency Checks
Before SYSTEM_VERSIONING is set to ON, a set of checks are performed on the history table and the current table. These checks are grouped into schema checks and data checks (if history table is not empty). In addition, the system also performs a runtime consistency check.
For more info, visit
In addition, temporal checks have been added to the DBCC CHECKCONSTRAINTS statement.

14. Security Principles Principle Description
Enabling/disabling system-versioning requires privileges on affected objects
Enabling and disabling SYSTEM_VERSIONING requires CONTROL permission on both the current and the history table
History data cannot be modified directly
When SYSTEM_VERSIONING is ON users cannot alter history data regardless of their actual permissions on current or the history table. This includes both data and schema modifications.
Querying history data requires SELECT permission on the history table
Merely because a user has SELECT permission on the current table does not mean that they have SELECT permission on the history table.
Audit surfaces operations affecting history table in specific ways:
Auditing on history table regularly captures all direct attempts to access the data (regardless if they were successful or not).  SELECT with temporal query extension shows that history table was affected with that operation.  CREATE/ALTER temporal table expose information that permission check happens on history table as well. Audit file will contain additional record for history table. DML operations on current table surface that history table was affected but additional_info provides necessary context (DML was result of system_versioning).

15. Temporal vs. CT vs. CDC Change Tracking (CT):
Stores the last change made to the row (no history)
Change Data Capture (CDC):
Also records DML activity changes in a table.
Also needs to be enabled at the database level first and then at the table level.
Has a lot complex features out of the box.
Requires database owner be a sysadmin.

16. Best Practices
For converting an existing table, consider using the HIDDEN clause to hide the new PERIOD columns to avoid impacting existing applications that are not designed to handle new columns.
Caution to Closed/Open intervals ( < vs <= )
Use separate schema for History tables
FOR SYSTEM_TIME filters out row versions with the same validity start and end times

17. Recap

18. Resources Introducing Temporal Tables in SQL Server 2016 (Part 1)
Introducing Temporal Tables in SQL Server 2016 (Part 2)
Temporal Table Considerations and Limitations
SQL Server 2016: Temporal Tables

19. Consulting Education Custom Apps www.nistechnologies.com

21. Contact Info
@SamNasr Thank you for attending!