How To Simplify Database Snapshots Creation in SQL Server
Database Snapshots is a powerful feature that can be used for quick reverts of the database to the state as it was in when a given database snapshot was created, as well as data and schema comparison between a source database and a snapshot.
While this feature was shipped in SQL Server 2005 it was available only in the enterprise edition. In release SQL Server 2016 SP1 Microsoft made a generous step and unlocked plenty of such enterprise-grade features. Since that snapshots become ready to use in all editions, including Express.
Warning: Database snapshots are dependent on the source database. Therefore, database snapshots are not to substitute your primary backup and restore strategy. Performing all your scheduled backups remains essential.
Problem and solution
While this feature has a clear T-SQL syntax SSMS has no wizard or GUI for it, so creation of multiple snapshots requires some tedious coding like:
CREATE DATABASE [AdventureWorks2016_snapshot] ON ( NAME = [AdventureWorks2016_Data] , FILENAME ='H:\SQL_Data\Data\AdventureWorks2016_Data.mdf.snapshot' ) AS SNAPSHOT OF [AdventureWorks2016];
Because of absence of UI and other helpers I created a stored procedure
Helpful SQL Server trace flags
SQL Server can be configured in various ways. It can be done via well-documented commands like
ALTER SERVER or via system stored procedure
SP_CONFIGURE. However, there is another way and sometimes it brings changes to behavior that cannot be achieved using other knobs – the name of it is a trace flag. Trace flags are special switches that can make an impact on the overall behavior of the data engine on a global scope or for some certain session.
Just an example
A famous error message:
String or binary data would be truncated. It happens often and its content and meaning do not help that much in searching for the column or value that causes the error. An example:
CREATE TABLE Tempdb.dbo.Test (Col1 CHAR(2)) INSERT Tempdb.dbo.Test ( Col1 ) VALUES ('abc' ) --Msg 8152, Level 16, State 30, Line 6 --String or binary data would be truncated.
However, if trace flag 460 is enabled and SQL Server version is higher than SQL Server 2017 CU11 the error message going to be much different and helpful:
DBCC TRACEON(460,-1) INSERT Tempdb.dbo.Test ( Col1 ) VALUES ('abc' ) --Msg 2628, Level 16, State 1, Line 2 --String or binary data would be truncated in table 'tempdb.dbo.Test', column 'Col1'. Truncated value: 'ab'.Continue reading…
TRUNCATE PARTITION in SQL Server
TRUNCATE TABLE removes all rows from a table, but the table structure and its columns, constraints, indexes, and so on remain. That is what the documentation says and that is what we daily use in our scripts, jobs and SSIS packages. Starting with SQL Server 2016 such operation can be done also on a partition level giving extra flexibility and convenience.
Directly to an example:
Partition truncation in SQL Server 2016 as simple as following line of code:
--SQL Server Execution Times: CPU time = 0 ms, elapsed time = 324 ms. TRUNCATE TABLE dbo.PartitionedTable WITH (PARTITIONS (1, 6 TO 10));
The command has removed partitions: 1, 6, 7, 8, 9, 10. Each one held one million rows, therefore, 6 000 000 rows removed in a 324 ms. This is amazing result which outperform
PARTITION SWITCHING timings.
Behind of the hood,
TRUNCATE is a DDL command and this fact is a reason of superior performance of rows/pages release. However, it also leads to requirement of the minimum permission level on an object –
Another necessary part of the command is the list of partition ids to remove corresponding segment. Partition Id can be obtained multiple ways. As example, via
$PARTITION.partition function call. Following query has been executed before and after truncation:
SELECT $PARTITION.[PartitioningByRowID] (RowId) AS PartitionID , COUNT(*) AS [RowCount] , MIN(RowId) AS MinRowID , MAX(RowId) AS MaxRowID FROM dbo.PartitionedTable GROUP BY $PARTITION.[PartitioningByRowID] (RowId)
Alternative way to get partition ids and metadata is by querying querying dynamic management object – sys.dm_db_partition_stats.Continue reading…
SQL Server 2016: Temporal Tables. Changing the Schema
In the previous blog post, I made an introduction to the basic concepts behind temporal tables. This time I would like to cover, in a little bit more detailed way, one difficult topic – schema change: how it can be applied to temporal tables and what impact on the system it can bring.
This post contains performance measurements of certain DDL commands. However, the absolute value of such metrics makes not so much sense due to the no-reproducibility of execution environment on the reader side. Therefore, I will provide command execution time not just for schema change operations, but also for data load, index creation, data manipulation commands, so all timespans can be matched with each other to make overall understanding about the impact.Continue reading…
SQL Server 2016: Temporal Tables. Introduction
SQL Server 2016 CTP2 finally available for the public and it brings many new features, which are worth checking. However, one of those new initiatives, I believe, can bring some discussions in DWH/BI environments. The name of it is Temporal table.
It seems, the feature can bring another naming confusion. Currently SQL Server ships temporary tables and table variables. But, with a new release, temporal table is a new guy in a toolbox, however, the usage of the new tool is completely different:
A temporal table is a table for which a PERIOD definition exists and which contains system columns with a datatype of datetime2 into which the period of validity is recorded by the system, and which has an associated history table into which the system records all prior versions of each record with their period of validity. With a temporal table, the value of each record at any point in time can be determined, rather than just the current value of each record. A temporal table is also referred to as a system-versioned table. Read more in online documentation.