| title | Partition with temporal tables | |
|---|---|---|
| description | Learn how to use table partitioning, on both the current and the history table independently. | |
| author | rwestMSFT | |
| ms.author | randolphwest | |
| ms.date | 07/29/2024 | |
| ms.service | sql | |
| ms.subservice | table-view-index | |
| ms.topic | concept-article | |
| ms.custom |
|
|
| monikerRange | =azuresqldb-current || >=sql-server-2016 || >=sql-server-linux-2017 || =azuresqldb-mi-current || =fabric-sqldb |
[!INCLUDE sqlserver2016-asdb-asdbmi-fabricsqldb]
You can use partitioning on both the current and the history table independently. However, partitioning can't be used to change the content of the data without system-versioning.
Partitioning is an Enterprise edition feature in [!INCLUDE sssql16-md] before Service Pack 1 and earlier versions. Partitioning is supported in all editions in [!INCLUDE sssql16-md] with Service Pack 1, and later versions.
This section describes how to use SWITCH IN and SWITCH OUT with temporal tables.
SWITCH IN to the current table can be used to facilitate data loading and querying while SYSTEM_VERSIONING is ON.
SWITCH OUT isn't permitted while SYSTEM_VERSIONING is ON.
You can run SWITCH OUT from the history table while SYSTEM_VERSIONING is ON, to purge portions of history data that is no longer relevant.
SWITCH IN isn't allowed while SYSTEM_VERSIONING is ON, since it can invalidate temporal data consistency.
- Temporal tables
- Get started with system-versioned temporal tables
- Temporal table system consistency checks
- Temporal table considerations and limitations
- Temporal table security
- Manage retention of historical data in system-versioned temporal tables
- System-versioned temporal tables with memory-optimized tables
- Temporal table metadata views and functions