SQL Server 2017 Temporal Enhancements

One of the most popular features in my talks about SQL Server 2016 has been the temporal tables feature. If you aren’t familiar with this feature you can read more about it on Books Online here. In a nutshell, you get a second table that tracks the lineage of your data. This is fantastic for all sorts of scenarios up to and including auditing, data recovery, fraud detection, or even slowly changing dimensions.

th

This is implemented in SQL Server via a history table—a second copy of your data that maintains timestamps of when the data is valid. As you can imagine this table can grow quite large—Microsoft does us a couple of favors: the history table is page compressed by default (you can use columnstore) and you could put the history table on a different filegroup. The only major issue was to truncate or delete data from history table for pruning purposes, you had to turn of system versioning, or the glue that makes that this feature work.

Starting with SQL Server 2017 (and Azure SQL Database) you can define a retention period and have SQL Server prune records for you. This is awesome and easy—see how to implement here.

Always On Availability Groups transport has detected a missing log block…

If you are running SQL Server 2016 (especially before CU3) you have received this error:

DATE/TIME:    8/21/2017 11:24:53 AM

DESCRIPTION:    Always On Availability Groups transport has detected a missing log block for availability database "Database". LSN of last applied log block is (99939:95847:0). Log scan will be restarted to fix the issue. This is an informational message only. No user action is required.

COMMENT:    (None)

JOB RUN:    (None)

Image result for missing block

I’ve talked with the product team about it, and its just something that happens, and is more of an informational message. Based on some discussions I’ve have on #sqlhelp on Twitter, it may be related to not enough network bandwidth between nodes. But if you see these sporadically, relax, it’s nothing major.

Managed Instances versus Azure SQL Database—What’s the Right Solution for You?

Last week at Microsoft Ignite, Microsoft introduced the public preview of the Managed Instances for Azure SQL Database. This is a new product that is a hybrid between running fully platform as a service (PaaS, in this case being Azure SQL Database) or infrastructure as a service (IaaS, or in this case SQL Server running on a VM). It has built-in support for cross-database queries and basically looks and feels just like your on-premises SQL Server. Probably my favorite part is the ability to just migrate a backup directly into the service from Azure Blob storage. There is also the benefit of being able to bring your own license to reduce some of the costs. Additionally, you can have much larger databases, up to 35 TB.

Image result for instance

Managed instances will be a good fit for you if:

  • You don’t own your code and need it to work with SQL Server
  • Your application makes a lot of cross database calls
  • You need to be able to migrate with near zero downtime
  • You have large databases that are not a good fit for the Azure SQL Database model

I think Azure SQL DB and Managed Instances will co-exist for the foreseeable future as each platform has a good use case.

%d bloggers like this: