sql 时态表的意义

背景 (Background)

With the release of Microsoft SQL Server 2016 a lot of new features were introduced, one of which was Temporal Tables, a feature that gives you the ability to view the state of your data at a given point in time. This means you can go back in time with your data. Another very popular feature is Stretch Databases which allows for remote archiving of data to Azure Stretch region.

随着Microsoft SQL Server 2016的发布，引入了许多新功能，其中之一是临时表，该功能使您能够在给定的时间点查看数据状态。 这意味着您可以及时返回数据。 另一个非常流行的功能是Stretch Databases，它允许将数据远程存档到Azure Stretch区域。

讨论区 (Discussion)

I am very fascinated by the concept of temporal tables and started to play around with it as early as CTP2 was released. As usual, I started to think about where I can use this in our environment and what would the benefit to the business be. The benefits that I could think of was some form of Data Auditing, Data warehouse Slowly Changing Dimensions and maybe even anomaly detection, but with this added abilities I very soon found that I am now consuming far more space than usual. Logging every event in your data seems like a good idea until you start running out of space.

我对时态表的概念非常着迷，并早在CTP2发布时就开始使用它。 像往常一样，我开始考虑在环境中可以在哪里使用它，以及对业务有何好处。 我可以想到的好处是某种形式的数据审核，数据仓库尺寸变化缓慢甚至可能是异常检测，但是有了这些附加功能，我很快发现我现在比平时消耗了更多的空间。 在您开始用尽空间之前，在数据中记录每个事件似乎是一个好主意。

So my next steps were to find a way to minimize the space the history tables use. So I started to think about what new features did Microsoft include in MS SQL 2016 that can help me with this problem, and naturally I started to think of Azure and how I can utilize this. I then started to think of how I can use this new feature (Stretch Databases) in conjunction with my history tables.

因此，我的下一个步骤是找到一种方法来最小化历史记录表使用的空间。 因此，我开始考虑微软在MS SQL 2016中提供了哪些新功能可以帮助解决此问题，因此自然而然地，我开始考虑Azure和如何利用此功能。 然后，我开始考虑如何与历史记录表一起使用此新功能（Stretch数据库）。

注意事项 (Considerations)

I know the one biggest challenge we have with moving data into Azure is our country’s data governance laws. So be sure to have a chat with your companies legal and compliance department before you decide to move company data into Azure.

我知道将数据迁移到Azure时遇到的最大挑战是我国的数据治理法律。 因此，在决定将公司数据移至Azure之前，请确保与公司法律和合规部门进行聊天。

Microsoft has just recently changed the way Stretch Databases get stored and processed in Azure, meaning that they also changed the way the pricing model works around this. From my experience, this works out quite expensive with the new pricing model.

微软最近更改了拉伸数据库在Azure中存储和处理的方式，这意味着它们还更改了定价模型的工作方式。 根据我的经验，使用新的定价模型计算出来的费用非常昂贵。

先决条件 (Prerequisites)

• Azure Subscription Azure订阅
• Azure SQL Server Azure SQL服务器
• SQL Server 2016 SQL Server 2016

目的 (Objective)

We will create a simple temporal (History) table and then set up the history table to be stretched to Azure. This will allow us to utilize the great new features of SQL Server 2016 and at the same time play with Azure. The goal is not to show how Temporal Tables work as there are more than enough great articles available to show you how this works. We want to be able to use Temporal Tables without the added space constraint.

我们将创建一个简单的时态（历史）表，然后设置历史表以扩展到Azure。 这将使我们能够利用SQL Server 2016的强大新功能，并同时使用Azure。 目的不是要显示时间表的工作原理，因为有足够多的精彩文章向您展示其工作原理。 我们希望能够在不增加空间限制的情况下使用临时表。

解 (Solution)

First, let’s create a temporal table with some sample data. I created a simple Author table with some randomly generated data in the TemporalDemo database.

首先，让我们用一些样本数据创建一个时态表。 我用TemporalDemo数据库中的一些随机生成的数据创建了一个简单的Author表。

USE Master;
GO
DROP DATABASE IF EXISTS TemporalDemoCREATE DATABASE TemporalDemo;
GOUSE TemporalDemo;
GOCREATE TABLE Author
(Id INT IDENTITY(1,2) PRIMARY KEY NOT NULL,Name VARCHAR(50) NOT NULL,Surname VARCHAR(50) NOT NULL,StartTime datetime2 GENERATED ALWAYS AS ROW START NOT NULL, EndTime datetime2 GENERATED ALWAYS AS ROW END NOT NULL,   PERIOD FOR SYSTEM_TIME (StartTime,EndTime)
)
WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.Author_History) );
GOSET IDENTITY_INSERT [dbo].[Author] ON
INSERT [dbo].[Author] ([Id], [Name], [Surname]) VALUES (1, N'Stefanie', N'Regina')
INSERT [dbo].[Author] ([Id], [Name], [Surname]) VALUES (3, N'Sandy', N'Roy')
INSERT [dbo].[Author] ([Id], [Name], [Surname]) VALUES (5, N'Lee', N'Dewayne')
INSERT [dbo].[Author] ([Id], [Name], [Surname]) VALUES (7, N'Regina', N'Beth')
INSERT [dbo].[Author] ([Id], [Name], [Surname]) VALUES (9, N'Daniel', N'Jolene')
INSERT [dbo].[Author] ([Id], [Name], [Surname]) VALUES (11, N'Dennis', N'Nicolas')
INSERT [dbo].[Author] ([Id], [Name], [Surname]) VALUES (13, N'Myra', N'Tricia')
INSERT [dbo].[Author] ([Id], [Name], [Surname]) VALUES (15, N'Teddy', N'Hilary')
INSERT [dbo].[Author] ([Id], [Name], [Surname]) VALUES (17, N'Annie', N'Shane')
SET IDENTITY_INSERT [dbo].[Author] OFF
GO

We have now created a sample database with a temporal table and inserted some dummy data for demonstration purposes.

现在，我们创建了一个带有时态表的示例数据库，并插入了一些虚拟数据以进行演示。

Now the next step will be to ensure that there is some data in the history table that we have created. We will do this by updating all records where the author name starts with a “T”.

现在，下一步将是确保历史记录表中已创建一些数据。 为此，我们将更新所有作者姓名以“ T”开头的记录。

UPDATE Author
SET Surname = CONCAT(Surname,'_',LEFT(Name,1))
WHERE to Name LIKE 'T%'SELECT *
FROM    Author
FOR SYSTEM_TIME ALL
WHERE  Name LIKE 'T%'SELECT   *
FROM    Author_History

From the above scripts we are returning all the records that we have updated to show that the system versioning caught the changes we made and just to be sure we also query the History table, we have created directly (this is not recommended by Microsoft). The following screenshot shows the expected output.

从上面的脚本中，我们将返回所有已更新的记录，以表明系统版本控制已捕获我们所做的更改，并确保我们也查询了直接创建的History表（Microsoft不建议这样做）。 以下屏幕截图显示了预期的输出。

You will notice the first select statement returns the changed record before and after the change, this is indicated by the “end time” field.

您会注意到，第一条select语句在更改前后都返回更改后的记录，这由“结束时间”字段指示。

Once we are happy with the data we can proceed to prepare the database for Stretch archive.

一旦我们对数据满意，我们就可以为Stretch存档准备数据库。

sp_configure 'remote data archive', 1
GORECONFIGURE;
GO

We first have to enable remote data archive for the instance before we can setup Stretch, this can be achieved by running the script above. Before you go ahead please ensure that you have added a firewall rule to your azure SQL server to allow connections from your current IP. The steps to do this can be found here. Next, we want to configure the database to connect to Azure for the Stretch functionality.

首先，我们必须为实例启用远程数据存档，然后才能设置Stretch，这可以通过运行上面的脚本来实现。 在继续之前，请确保已将防火墙规则添加到Azure SQL服务器以允许来自当前IP的连接。 可在此处找到执行此操作的步骤。 接下来，我们要配置数据库以连接到Azure以使用Stretch功能。

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'SuperSecurePassword'CREATE DATABASE SCOPED CREDENTIAL remoteArchive WITH IDENTITY = 'AzureSqlServerUsername' , SECRET = 'AzureSqlServerSupersecurepassword'
GO  ALTER DATABASE TemporalDemo  SET REMOTE_DATA_ARCHIVE = ON  (  SERVER = '*********.database.windows.net' ,  CREDENTIAL = remoteArchive ) ;
GO;  

With the above scripts, we created a master encryption key for our database and created a database scoped credential that we will use to connect to our Azure SQL server. Once this is created we can alter our database to connect to our Azure SQL server by setting REMOTE_DATA_ARCHIVE = ON for our test database. This might take a few moments and once this is done we are ready to enable remote archive for our history table.

使用上述脚本，我们为数据库创建了主加密密钥，并创建了数据库范围的凭据，将用于连接到Azure SQL服务器。 创建此文件后，我们可以通过为测试数据库设置REMOTE_DATA_ARCHIVE = ON来更改数据库以连接到Azure SQL服务器。 这可能需要一些时间，一旦完成，我们就可以为历史记录表启用远程归档了。

ALTER TABLE Author_History--THE NAME OF OUR HISTORY TABLE
SET ( REMOTE_DATA_ARCHIVE = ON (MIGRATION_STATE = OUTBOUND))

We have now setup our history table to stretch to Azure, you can check this by looking at the query plan when you query the history table. You will also notice that it might be a lot slower when you query the history table now as SQL now have to first fetch the data from your remote data archive.

现在，我们已经设置了历史表以扩展到Azure，可以在查询历史表时通过查看查询计划来进行检查。 您还将注意到，现在查询历史记录表时，它可能会慢很多，因为SQL现在必须首先从远程数据归档中获取数据。

SELECT  *
FROM    Author
FOR     SYSTEM_TIME ALL
WHERE   Name LIKE 'T%'

This can also be visible in your Azure portal if you go to your SQL Server, you will see SQL Server has created a new database in Azure. According to Microsoft, this is a special region for Stretch and not just a normal Azure SQL Database.

如果您转到SQL Server，这也可以在Azure门户中看到，您将看到SQL Server在Azure中创建了新数据库。 根据Microsoft的说法，这是Stretch的特殊区域，而不仅仅是普通的Azure SQL数据库。

最后的想法 (Final Thoughts)

This is a great way to use temporal tables and not having to worry about the added space it will consume. I know your executions will be a lot slower now, but let’s be honest how often are you going to retrieve data from the history tables? If you are going to do this very often then maybe you should rather be thinking of adding a clustered columnstore index on the history tables rather than stretching the history tables. Maybe I will write a post on how to achieve this as well.

这是使用时态表的好方法，而不必担心它将占用的额外空间。 我知道您的执行速度现在会慢很多，但是老实说，您将多久从历史记录表中检索一次数据？ 如果您要经常执行此操作，那么您可能宁愿考虑在历史记录表上添加群集的列存储索引，而不是扩展历史记录表。 也许我也会写一篇关于如何实现这一目标的文章。

If archiving is the only objective then maybe you should consider using Azure BLOB storage and create external tables to the BLOB storage. Will take some development, but we have implemented a solution like this for an APS as this was the only way we could do backups on the APS. This will not allow you to utilize the benefits Temporal Tables at all which was sort of the point of this article.

如果归档是唯一目标，那么也许您应该考虑使用Azure BLOB存储并为BLOB存储创建外部表。 需要做一些开发，但是我们已经为APS实现了这样的解决方案，因为这是我们可以在APS上进行备份的唯一方法。 这根本不允许您利用“时态表”的好处，这正是本文的重点。

翻译自: https://www.sqlshack.com/stretching-temporal-history-tables-in-sql-server-2016/

sql 时态表的意义