How Does Stretch Database Works in SQL Server 2016

New feature which was introduced with SQL Server 2016 is Stretch Database which migrates our historical data transparently and securely to the Microsoft Azure cloud. Stretch Database provides many benefits to the users, but also has its own limitations which make it less likely to be used as of now, unless Microsoft comes up with significant improvements. Some of the benefits to decide on using SQL Server 2016 Stretch Database feature are, Provides cost-effective availability for cold data(historical data which is not accessed much, but still available to support user queries from Azure SQL database). Using this feature does not require any changes to the applications, this feature takes care of it internally and transparently. Moving cold or not frequently used data to Azure SQL database will reduce the maintenance efforts on the production data like less times required for backups, indexing statistics updates, etc. Stretch Database in a SQL Server instance requires at least one table. It then silently begins to migrate the historical data to Azure SQL Database. If we are storing historical data in a separate table, then we can migrate the entire table. If our table contains both historical and current data, then we can specify a filter predicate to select the rows which need to be moved to Azure SQL database. Also, importantly, Stretch Database ensures that no data is lost if a failure occurs during migration. There is also retry logic to handle intermittent connection issues that may occur during migration.

Before deciding to this new feature in production environment, it is important to understand how does Stretch Database works and its behavior. First, to enable stretch database, we need to enable the instance level configuration option “remote data archive”, after which we will be able to Enable a Stretch Database for a database or table. Once we enable stretch database for atleast one database and one table, it will internally start to migrate our historical data to Azure SQL database. If the historical data is stored in a separate archive table already, then we can migrate the entire table, if table contains both historical and current data then we need to specify a filter predicate to select the rows which are to be migrated to the Azure SQL database. Some of the cool features with the Stretch Database is that it ensures that no data is lost in case a failure occurs during the data migration to Azure SQL database. It also has retry logic to handle connection issues that may occur during migration. A dynamic management view also provides us with the status of migration.

Also there us option to pause data migration to troubleshoot problems on the local server or to maximize the available network bandwidth or to migrate data only during non-business hours or during low activity period. Another cool thing about using stretch database is that we don’t have to change existing queries or client applications. We can continue to have seamless access to both local and remote data, even during data migration. There is a small amount of latency for remote queries, but you only encounter this latency when you query the historical data.