How to Decide If Stretch Database Can Be Used in Your Environment


Stretch Database is an interesting and popular new feature introduced with new SQL Server 2016. Stretch database helps in migrating our historical or less frequently used or archived or cold data transparently and securely to the Microsoft Azure cloud. Stretch Database provides many benefits to the organizations like reducing the storage costs, automatically archiving the old data to Azure, etc. However, stretch database also has its own limitations which make it less likely to be used as of now with SQL Server 2016 RTM release. Hopefully Microsoft comes up with significant improvements soon in service packs or with another release in another couple of years, like it has been releasing since year 2008. 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. Once we enable it at instance level, database level and table level, it then silently begins to migrate the historical data to Azure SQL Database on Microsoft cloud. If we are storing historical data in a separate table on-premise database, then we can migrate the entire table to Azure cloud. 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. However, most important question from many organizations management and DBAs or developers is how to decide if stretch database suits their environment or requirement. Below are some points to help decide if Stretch Database can help in meeting your requirements and solve the existing problems.

– Are you looking to store historical data, and do not want to get rid of very old data, as it may be still required to be accessed rarely, then stretch database will be of great help in reducing the storage and maintenance costs of the old data and still allows you to access the old data from the azure cloud.
– Are you looking for archival solution to archive old data from the frequently accessed production data, then stretch database feature is a very good solution to your problem, as you can archive old data on to Azure SQL database cloud, and best thing is you do not need to change anything in your application, as the data storage and access is taken care purely by SQL Server itself.
– If you are looking to reduce storage, compute and memory costs, then this is ideal solution.
– If you see that some tables are very large and causing issues with maintenance like backups, reindexing, stats update, etc, then archiving is best solution and stretch database will be very good solution.
– If your backup/restore are taking too long and missing SLAs, then moving old data to Azure cloud using stretch database will move old data, thus reduces the size of on=premise tables and thus reduces size of on-premise database and now the backup/restore times will be less and should meet the SLA requirements.

Hope this was helpful.

This is applicable for below versions of SQL Server

SQL Server 2016

SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, Frequently asked questions, SQL Server Trainings


Leave a Reply

Your email address will not be published. Required fields are marked *