Prashanth Jayaram

SQL Server 2016 enhancements – Truncate Table and Table Partitioning

April 18, 2017 by

The idea behind this article is to discuss the importance and the implication of SQL Partition and understand the truncate command partitioning enhancements in SQL 2016

One of the biggest challenges for a DBA is to identify the right candidate for table partitioning, as it requires expertise in design and implementation.

The following are the various truncating options available in SQL 2016

  • Truncate individual partitions
  • Truncate multiple individual partitions
  • Truncate a Range of partitions
  • Truncate a Range with multiple individual partitions

Article Highlights

  • Define the importance and the implication of SQL table partitioning
  • Identify the right candidate for table partitioning
  • Provide inline comparison of features available in the different editions of SQL 2016
  • Discuss the truncate partition enhancements in SQL 2016
  • Demonstrate the truncate table partition use cases

SQL Partition

Let’s understand the objective of SQL partitioning, why we need partitioning, and the factors that are vital to decide on a Table Partitioning Strategy.

Partitions are logical mapping of the physical data. A well-designed partition gives us an option to scale out the data. It optimizes the performance and simplifies the management of data by partitioning each table into multiple separate partitions. Although, not all tables are good candidates for partitioning. If the answer is ‘yes’ to all or most of the following questions, table partitioning may be a viable database design strategy; if the answer is ‘no’ to most of the following questions, table partitioning may not be the right solution for that table.

  • Is the table large enough?
    Large fact tables are good candidates for table partitioning. If we have millions or billions of records in a table, we may see performance benefits from breaking that data up into logically smaller chunks. Since smaller tables are less susceptible to performance problems, the administrative overhead of maintaining the partitions will outweigh any performance benefits we might see by partitioning.
  • Does your application or system maintain a window of historical data?
    Another consideration for partition design is your organization’s data retention policy. For example, your data warehouse may require that you keep the data from the past twelve months. If the data is partitioned by month, you can easily drop the oldest monthly partition from the warehouse and load current data into the most recent monthly partition.
  • Are you experiencing performance issues on database maintenance tasks?
    As we deal with larger tables, it is more difficult to perform the rebuilding operations. In such scenarios, one can rely on table partitioning, so that maintenance operations can be seamlessly performed.
  • Can the data be divided into equal parts based on a certain criteria?
    Choose the partition criteria that will divide the data as evenly as possible. This will let the SQL Query Optimizer to decide and select the best plan for query execution. The monthly partition as mentioned in the second point is a good example for this.
  • Is concurrency an issue?
    Does the system involve a huge volume of data loading and reporting? Are user queries frequently getting locked or blocked? If yes, partitioning could be an option to ease the situation, since the Query Optimizer would be able to handle the execution better.

If someone complains about slowness of a query, it isn’t necessary that the related tables need to be partitioned. In most cases, partitioning would not improve performance. A proper indexing strategy may suffice for some of the performance problems in many such use cases. For instance, if a query is written to use a partition key, then the query execution improves; deterioration in performance may be linked to not using the partition key in this case

The earlier versions of SQL Server required a lot of extra effort in restoring the database with partitioned tables to a non-Enterprise edition of SQL Server. Any attempt to restore resulted in dropping of the Partition Function and the Partition Scheme prior to the database backup and restore process; this is not the case with SQL 2016.

The data truncation/deletion/reshuffling operations had to rely on partition switching and merge mechanism. However, with SQL Server 2016, some interesting features with the truncate command have been introduced, which serve the purpose of data removal with minimal logging.

Feature Support

The Partitioning feature has been an Enterprise edition feature, starting from SQL 2005, but for the first time, it has been made available on all the editions of SQL 2016.

Feature Enterprise Standard Web Express with Advanced Services Express
Table and
Index Partitioning
Yes Yes  Yes  Yes  Yes 

Truncate table syntax and its usage

TRUNCATE TABLE and using WITH PARTITIONS () option enables the mechanism to truncate the data within the defined partition number(s) or a range of partitions.

  • Provide partition number , for example: 
  • Provide the partition numbers for multiple individual partitions separated by commas, for example:
  • Provide both range and multiple individual partitions, for example:
  • Using the world TO, partition numbers separated by the word TO, for example: 

How and when to use the truncate table with Partition clause?

The following section discusses the scenario of how to use the truncate Table option for data removal for partitioned table

The Quick Archival/Purging process involves switching out the partitions. Though Switch Partition is a metadata update operation and doesn’t involve movement of physical data between the data files, in some cases like high transactional databases, it requires exclusive locks, and this causes the table being blocked for loading and removing the data.

Data purging (deletion) from specific partition or partitions was a tedious task in the previous versions of SQL. Data caused slowness and locked the table, which prevented the users from querying the table; it also ended up using a lot of transaction log space. Prior to SQL 2016, the following steps were performed for data deletion or to remove files from the partition

  • Create a new table for switching out with the same definition and clustered index as of the partitioned table
  • Switch partition out to the other table 
  • Alter the Partition function and Partition Scheme to get rid of the file group
  • by merging the boundary
  • Remove the file group

Note: This is challenging when we deal with a huge number of rows

What about introducing the new TRUNCATE TABLE command in this scenario?

This is a quite seamless and an efficient way to delete the rows from the partitioned table, as it works as a normal Truncate Table operation.

  • Execute TRUNCATE TABLE with partition clause
  • Execute MERGE command
  • Remove the empty filegroup

Demonstration

In SQL Server 2016 we have the feature to truncate data at the partition level. It’s pretty straight forward and simple. Let’s go through the simple steps to show how it works.

Create a sample database powerSQLPartitionTest and add new filegroups. These files are physical representation of SQL data

The below SQL gives SQL partition internal details

Now, the filegroup_2017 is empty and ready for removal. Make sure the dependency is broken from every part of its usage. Once done, merge the boundary point this will remove the entry from Partition Function

Conclusion

This article details the use of Partitioning in SQL Server and the factors which are vital for considering before partitioning a table. It also outlines the use of the truncate table partition enhancement. With SQL Server 2016, one can plan for a better index maintenance and data management strategies.

See more

Consider these free tools for SQL Server that improve database developer productivity.

References


Prashanth Jayaram

Prashanth Jayaram

I’m a Database technologist having 11+ years of rich, hands-on experience on Database technologies. I am Microsoft Certified Professional and backed with a Degree in Master of Computer Application.

My specialty lies in designing & implementing High availability solutions and cross-platform DB Migration. The technologies currently working on are SQL Server, PowerShell, Oracle and MongoDB.

View all posts by Prashanth Jayaram
Prashanth Jayaram
3,575 Views