gotqn's questions

我一直认为CONCAT函数实际上是+（字符串连接）的包装，并带有一些额外的检查，以使我们的生活更轻松。

我还没有找到任何关于这些功能是如何实现的内部细节。至于性能，当数据在循环中连接时，调用似乎会产生开销CONCAT（这似乎很正常，因为有额外的 NULL 句柄）。

几天前，一位开发人员修改了一些字符串连接代码（从+到 ，CONCAT)因为不喜欢语法并告诉我它变得更快。

为了检查情况，我使用了以下代码：

DECLARE @V1 NVARCHAR(MAX)
       ,@V2 NVARCHAR(MAX)
       ,@V3 NVARCHAR(MAX);

DECLARE @R NVARCHAR(MAX);

SELECT  @V1 = REPLICATE(CAST('V1' AS NVARCHAR(MAX)), 50000000)
       ,@V2 = REPLICATE(CAST('V2' AS NVARCHAR(MAX)), 50000000)
       ,@V3 = REPLICATE(CAST('V3' AS NVARCHAR(MAX)), 50000000);

这是变体一：

SELECT @R = CAST('' AS NVARCHAR(MAX)) + '{some small text}' + ISNULL(@V1, '{}') + ISNULL(@V2, '{}') + ISNULL(@V3, '{}'); 
SELECT LEN(@R); -- 1200000017

这是变体二：

SELECT @R = CONCAT('{some small text}',ISNULL(@V1, '{}'), ISNULL(@V2, '{}'), ISNULL(@V3, '{}'))
SELECT LEN(@R); -- 1200000017

对于较小的字符串，没有差异。在某些时候，CONCAT变体会变得更快：

我想知道有人可以分享一些内部结构或解释其行为，因为似乎可能存在一条规则，最好使用CONCAT.

版本：

Microsoft SQL Server 2022 (RTM-CU8) (KB5029666) - 16.0.4075.1 (X64) 2023 年 8 月 23 日 14:04:50 版权所有 (C) 2022 Windows Server 2019 Standard 10.0（内部版本 17763）上的 Microsoft Corporation 标准版（64 位） :)（管理程序）

确切的脚本如下所示：

DECLARE @V1 NVARCHAR(MAX)
       ,@V2 NVARCHAR(MAX)
       ,@V3 NVARCHAR(MAX);

DECLARE @R NVARCHAR(MAX);

SELECT  @V1 = REPLICATE(CAST('V1' AS NVARCHAR(MAX)), 50000000)
       ,@V2 = REPLICATE(CAST('V2' AS NVARCHAR(MAX)), 50000000)
       ,@V3 = REPLICATE(CAST('V3' AS NVARCHAR(MAX)), 50000000);



--SELECT @R = CAST('' AS NVARCHAR(MAX)) + '{some small text}' + ISNULL(@V1, '{}') + ISNULL(@V2, '{}') + ISNULL(@V3, '{}'); -- 00:00:45 -- 00:01:22 -- 00:01:20
--SELECT LEN(@R); -- 300000017

SELECT @R = CONCAT('{some small text}',ISNULL(@V1, '{}'), ISNULL(@V2, '{}'), ISNULL(@V3, '{}')) -- 00:00:11 -- 00:00:16 -- 00:00:10
SELECT LEN(@R); -- 300000017

我正在更改 REPLICATE 函数的最后一个参数，以便为连接生成更大的字符串。然后，我将每个变体执行三次。

在 SQL Server 实例之一中，我无法执行任何查询。我认为这是由于负载过重所以我尝试执行sp_execeute whoisactive并得到：

]

昨晚，DBA 已升级到 SQL Server 2022 CU5，并告诉我有一个问题，已通过 CU7 解决。因此，升级到 CU7，但没有任何变化。

DBA 发给我这个：

之后：

但我不确定发生了什么事。DBA 停止了查询存储和所有扩展事件会话，但没有任何变化。现在，DBA 认为问题是由此引起的，但它应该在 CU4 中修复，并且它会在升级过程中（而不是升级后）引起问题。

DBA已向MS开票，但我想知道是否有人知道可能导致此问题的原因是什么？

我将附上跟踪数据。更多信息 - 我们有 SQL Server 2022 CU5 实例和另一个运行 CU7 副本的实例。

另一位 DBA 认为问题出在始终在线的副本上，因此它们被停止 - 副本不断崩溃。

当数据库（SQL Server 数据库）中发生某些事件时，我们有一个业务需求能够请求 HTTP 端点。我们有一个我们控制的端点目录。我们同时使用 SQL Server 2019 和 2022。

目前我们使用Service Broker External Activator，效果很好，但这项技术已经过时，据我们所知，微软不再支持它。此外，设置/实施相当复杂，管理层将其标记为“不可行”。

当我们在 Azure 中工作时，我们将使用新的 sp_invoke_external_rest_endpoint 来调用将发出请求的 Azure 函数。这工作正常，我们将在 Azure 中使用它。

不幸的是，此过程在 SQL Server 2022 的标准本地版本中不可用。这就是我们计划使用EXECUTE sp_execute_external_script @language = N'Python'请求 HTTP 端点的原因。

我们已经在生产中使用了 SQL Server 机器学习服务，因此我们在 SQL Server 2019 和 2022 上都提供了这些服务。我们测试了该实现，它似乎运行良好，尽管有点慢。

我们想知道：使用 Python 调用 HTTP 端点是否存在我们目前在评估中遗漏的重大缺点？

以下是我们用于概念验证的代码示例：

CREATE PROCEDURE [dbo].[usp_APICalls_HTTPRequest]
    @URL NVARCHAR(100),
    @Method VARCHAR(50),
    @HeadersJSON NVARCHAR(MAX),
    @BodyJSON NVARCHAR(MAX) = NULL,
    @BodyParams NVARCHAR(MAX) = NULL,
    @StatusCode VARCHAR(50) = NULL OUTPUT,
    @ResponseBody NVARCHAR(MAX) = NULL OUTPUT
AS
    EXECUTE sp_execute_external_script @language = N'Python',
    @script = N'
import datetime
import json
import requests
 
print("")
print("Script started {:%Y-%m-%d %H:%M:%S}".format(datetime.datetime.now()))
print("")
 
objHeaders = json.loads(HeadersJSON)

if BodyJSON:
    payload = json.dumps(json.loads(BodyJSON))
else:
    payload = BodyParams
 
objReqResponse = requests.request(Method, URL, headers=objHeaders, data=payload)
 
objResponse = {
    "StatusCode": [objReqResponse.status_code],
    "Body": [objReqResponse.text]
}
 
StatusCode = str(objReqResponse.status_code)
ResponseBody = objReqResponse.text
 
print("")
print("Script complete {:%Y-%m-%d %H:%M:%S}".format(datetime.datetime.now()))
print("")
 
    ',
        @params = N'@URL NVARCHAR(100),
                    @Method VARCHAR(50),
                    @HeadersJSON NVARCHAR(MAX),
                    @BodyJSON NVARCHAR(MAX),
                    @BodyParams NVARCHAR(MAX),
                    @StatusCode VARCHAR(50) OUTPUT,
                    @ResponseBody NVARCHAR(MAX) OUTPUT',
        @URL = @URL,
        @Method = @Method,
        @HeadersJSON = @HeadersJSON,
        @BodyJSON = @BodyJSON,
        @BodyParams = @BodyParams,
        @StatusCode = @StatusCode OUTPUT,
        @ResponseBody = @ResponseBody OUTPUT
 
GO

我有一些数据损坏，无法通过备份恢复数据。它主要影响非聚集索引，因此在删除索引后问题得到解决。

最后，我有：

消息 8905，级别 16，状态 1，第 3 行范围 (1:896320) 中的数据库 ID 15 在 GAM 中标记为已分配，但没有 SGAM 或 IAM 已分配它。CHECKDB 发现 1 个分配错误和 0 个与任何单个对象无关的一致性错误。CHECKDB 在数据库“db_name”中发现 1 个分配错误和 0 个一致性错误。repair_allow_data_loss 是 DBCC CHECKDB (db_name) 发现的错误的最低修复级别。

我想找出哪些是扩展页面，然后查看这些页面中的数据是什么。然后，决定使用repair_allow_data_loss运行CHECHDB命令或尽可能保存一些数据。

在 Service Broker 队列中，当一条消息随着时间的推移继续进行时，我们正在执行一个存储过程，该过程正在使用临时表执行一些繁重的操作。

我猜这sp_WhoIsActive是显示 tempdb 分配和 CPU 使用率的汇总值，因为队列正在使用一个会话。

问题是，当前存储过程完成时是否释放分配？

我有一个具有以下结构的表：

ItemID           int
ItemType         char(1)
Language         char(2)
Localization     char(2)
Literal          nvarchar(4000)

它用于将特定的文本翻译ItemID成Literal一个。该Literal列可能包含HTML标签。对于一组特定的查询，HTML需要删除这些标签，并且因为清理是使用 SQL CLR 对数千行进行的，所以我不希望在读取时执行此类操作。

所以，我添加了一个这样的持久列：

ALTER TABLE [dbo].[table]
ADD [LiteralSanitized] AS NULLIF(CAST(LTRIM(RTRIM([dbo].[fn_Utils_RemoveAllHtmlTags] ([Literal]))) AS NVARCHAR(4000)), '') PERSISTED;

该表只有一个索引（主键），定义如下：

ItemID, ItemType, Language, Localization

所以查询速度更快，但我看到这个表有一些额外的读取：

Scan count    - 2     vs 12,230 
Logical reads - 3,234 vs 43,472 

由于该列，这可能是正常的，因为现在我读取了更多数据。所以，我添加了以下索引：

(ItemID ASC, ItemType ASC, Language ASC, Localization ASC) INCLUDE ([LiteralSanitized])

但它不被引擎使用。所以，我尝试强制引擎使用它：

UPDATE #temp
SET [QuestionText] = PSGQ.[LiteralSanitized]
FROM #temp PQD                                            
INNER JOIN [dbo].[table_with_translations] PSGQ WITH(INDEX = [the_new_index])
    ON PQD.[ProtoQuestionID] = PSGQ.[ItemID] 
WHERE PSGQ.[ItemType] = 'Q' 
    AND PSGQ.[Language] = @language 
    AND RTRIM(PSGQ.[Localization]) = ''
    AND PSGQ.[LiteralSanitized] IS NOT NULL;

但引擎正在执行以下操作：

• 执行索引扫描（在我的新索引上）
• 然后使用聚集索引执行嵌套循环和键查找
• 提取literal列

如果我的列是Persisted，为什么引擎继续尝试返回该Literal列，因为它甚至不需要？

我在用于记录的表上有一个聚集列存储索引 - 仅插入（但不是批量插入）。当前的表统计数据是：

• 35.41 亿行
• 6.6 GB 预留空间

我今天早上通过以下方式看到了以下操作sp_whoisactive：

ALTER INDEX [...] ON [...].[...] 
REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = COLUMNSTORE_ARCHIVE);

我使用以下查询来检查我们有多少行row_group_id：

SELECT
    tables.name AS table_name,
    indexes.name AS index_name,
    partitions.partition_number,
    dm_db_column_store_row_group_physical_stats.row_group_id,
    dm_db_column_store_row_group_physical_stats.total_rows,
    dm_db_column_store_row_group_physical_stats.deleted_rows,
    dm_db_column_store_row_group_physical_stats.state_desc,
    dm_db_column_store_row_group_physical_stats.trim_reason_desc
FROM sys.dm_db_column_store_row_group_physical_stats
INNER JOIN sys.indexes
ON indexes.index_id = 
    dm_db_column_store_row_group_physical_stats.index_id
AND indexes.object_id = 
    dm_db_column_store_row_group_physical_stats.object_id
INNER JOIN sys.tables
ON tables.object_id = indexes.object_id
INNER JOIN sys.partitions
ON partitions.partition_number = 
    dm_db_column_store_row_group_physical_stats.partition_number
AND partitions.index_id = indexes.index_id
AND partitions.object_id = tables.object_id

我们在最后一行和几3383行分组，如下所示：1048576

问题是我们使用的是标准版（本地）并且重建操作没有在线执行并导致大量阻塞。

我以前从未见过这样的问题。几周前，我们已经从SQL Server 2016 SP1SQL升级Server 2019。

我的问题是：

• 如果只应用插入，应该是操作reorganize并且更快
• 如果不是，如果我们应用分区，例如在表用于日志记录时以年份为基础，自动化过程是否只会重建最后一个分区的数据

我遇到了以下表格设计，用于以非规范化方式记录引用：

RecordGUID              uniqueidentifier
DestinationEntity       uniqueidentifier
DestinationRecordGUID   uniqueidentifier

例如，Users对于描述对 的引用的表Countries，我们将有：

 RecordGUID                             DestinationEntity                       DestinationRecordGUID   
 79282C80-4474-4617-9C40-C21E97F5AC52   3A462EF8-DAB6-4B98-BA1B-FBD957A1737C    5842E524-8C5D-4DEE-A553-0857FB9C12F4
 B25DA064-8DAF-4EEB-8894-D540B3A929EA   3A462EF8-DAB6-4B98-BA1B-FBD957A1737C    C2B0AA1A-E688-4E2C-BD5F-16309C496774

因此，3A462EF8-DAB6-4B98-BA1B-FBD957A1737C表示Countries、 while5842E524-8C5D-4DEE-A553-0857FB9C12F4和C2B0AA1A-E688-4E2C-BD5F-16309C496774是指Counries表中的记录。

我们在这里有很多关系 - 例如，usersto languages，companies等。并且因为使用GUID以加入表不是用户友好的，我们为每个关系建立了索引视图，如下所示：

CREATE VIEW [dbo].[users_countries]
WITH SCHEMABINDING
AS
SELECT [RecordGUID]
      ,[DestinationEntity]
      ,[DestinationRecordGUID]
FROM (the relationship table)
WHERE [DestinationEntity] = '3A462EF8-DAB6-4B98-BA1B-FBD957A1737C';

因此，人们可以轻松地将此视图连接到counties表并对其进行查询 - 此外，由于使用视图（没有展开）并在其上有索引，并非原始表中的所有记录都被读取（它更快）。

系统可能有数百个索引视图，与原始表上的过滤索引相比，我担心引擎管理它们的成本。我的意思是view只创建这样的索引：

CREATE INDEX (index_Name) ON (the relationship table)
(
    [RecordGUID]
   ,[DestinationRecordGUID]
)
WHERE [DestinationEntity] = '3A462EF8-DAB6-4B98-BA1B-FBD957A1737C'

我们不再能够以友好的方式查询该表，但这会影响性能吗？

我找不到任何关于索引视图损害性能的话题——但面对这样的设计让我怀疑。

我想知道我们可以说视图索引的维护和表上的相同索引（如上）是相同的吗？

我知道问题的答案可能会有所不同，具体取决于每个文件中究竟损坏了什么.mdf- 只有在有另一种方法可以解决这个问题时才寻求建议。

所以，我从数据库管理员那里收到了一些坏消息。昨晚发生了这样的事情（这是我从他那里得到的唯一信息）：

1. 驱动器发生故障
2. 驱动器已更换，但在重建过程中再次失败......
3. 它是新驱动器，因此已移至机箱上的不同驱动器插槽
4. 执行上述操作时，我错误地拉出了 cachcade 驱动器，该驱动器又锁定了具有 cachecade 保护的任何卷
5. 重新插入 cachecade 驱动器后，驱动器活动恢复（驱动器进入“锁定”状态）

似乎上述步骤导致.mdf文件损坏并且无法正常工作。force attached因此，我们按照以下步骤开始为他们创建新的 SQL 实例：

1. 创建新数据库
2. 删除它的文件

3. 添加损坏的.mdf文件ldf并使用以下脚本恢复它们：

   USE master GO
   ALTER DATABASE [] MODIFY FILE(NAME='', FILENAME= '') 
   ALTER DATABASE [] MODIFY FILE(NAME='', FILENAME= '') 
   GO
   
   ALTER DATABASE [] SET ONLINE 
   GO
   DBCC TRACEON(3604) 
   GO
   ALTER DATABASE [] SET EMERGENCY 
   GO
   
   ALTER DATABASE [] SET SINGLE_USER 
   GO
   DBCC CHECKDB('[]', REPAIR_ALLOW_DATA_LOSS) 
   WITH ALL_ERRORMSGS 
   GO
   
   ALTER DATABASE [] SET MULTI_USER 
   GO
   

   他还告诉我，Repair errors are different per database有些database根本无法修复。

那么，我是否还有其他选择，或者我需要检查每个数据库的上述情况，并将一些数据（如果可能）移动到手动从旧副本恢复的数据库中？

我想知道是否：

• 隔离级别为已提交读
• 数据被插入、删除或读取

与传统的行存储表一样，用于全局临时表的锁是相同的锁（读取共享，插入/删除独占）。

对于临时表，我相信它在当前上下文中“存在”时不会发生阻塞，因此我无法同时读取和插入数据。

但是对于全局临时表，假设我有很多操作——一些正在插入新数据，一些正在删除数据，还有一些要读取的数据将被删除。

假设表的结构是：

GroupID EntityID
1       101
1       102
1       103
2       101
2       104
3       100

这里是否适用相同的规则？

在docs中，我们提供了如何用内存表替换临时表的示例，因为内存优化表：

• 仅存储在内存中，并且在磁盘上没有组件
• 不涉及 IO 活动
• 不涉及 tempdb 使用或争用

他们说：

内存优化导致速度提高，通常快 10 倍或更多。

我想知道我们的系统是否已经将 ram 用于 tempdb 数据库，哪些好处仍然适用？我猜他们正在硬盘驱动器或 ssd 上测试 temdb 并且怀疑获得如此好的结果。

更多细节。系统最常用的表变量函数之一是计算对特定实体的访问。然后，将结果连接到各个表以获取请求数据。为了优化后面的连接，我将此函数的结果存储在临时表中，结果很好。

但是对于非常大的数据量（例如，当函数返回 1-2 百万个实体时），函数本身的执行速度很慢（这也是正常的，因为我们在表变量中插入了这么多行）。

所以，我正在考虑将此函数重写为存储过程并将实体插入内存表中，希望对表的 CRUD 操作能够10 times faster or more。

微软在 SQL Server 2019 中引入了对数据类型的UTF-8 支持，CHAR并表示：VARCHAR

此功能可能会显着节省存储空间，具体取决于使用的字符集。例如，使用启用 UTF-8 的排序规则将具有 ASCII 字符串的现有列数据类型从 NCHAR(10) 更改为 CHAR(10)，可以将存储需求减少近 50%。这种减少是因为 NCHAR(10) 需要 22 个字节来存储，而 CHAR(10) 需要 12 个字节来存储相同的 Unicode 字符串。

UTF-8 似乎支持所有脚本，所以基本上我们可以开始将 Unicode 数据存储在varchar和char列中。正如文档中所说，这可以减少表和索引的大小，并且从那里我们可以获得更好的性能，因为读取的数据量更少。

我想知道这是否意味着我们可以停止使用实现 UTF-16 的列nvarchar？nchar

任何人都可以指出一个场景和理由，不要使用带有UTF编码的 char 数据类型并继续使用 n-chars 吗？

我目前使用的是SQL Server 2016 SP标准版，想安装 R 服务。在文档Machine Learning Server (Standalone)中说，仅允许在 Enterprise ( )上进行独立安装。

另外，我发现了一个帖子，里面有人说在标准上我无法使用并行操作并且存在内存限制：

谁能说出确切的内存/处理器限制是什么？

我需要使用繁重的 R 计算等详细信息，目前的测试表明标准版中的实现没有像我希望的那样工作。

我正在使用以下查询来检查默认架构是否设置为dbo.

SELECT DB_NAME() AS [database] 
      ,[name]
      ,[type_desc]
      ,[default_schema_name]
FROM [sys].[database_principals]
WHERE [type] IN ('U', 'G')
    --AND [default_schema_name] <> 'dbo';

如果未设置为dbo并且有人在未指定架构标识符的情况下创建了一个对象，schema则会使用他/她的 Windows 凭据创建一个新对象。

因此，我想编写一个脚本来检查（在特定时间段内）是否一切都设置好（因为每天都会恢复/创建新机器和数据库）。

上面脚本的问题是我可以看到我的用户的默认架构不是dbo，但是当使用其他帐户执行时，我的用户没有列出。

我想那是因为WINDOWS_GROUP我们都是其中的一员，所以我需要检查它的设置，但总是NULL为团体获得价值。

本文解释了如何解密对称密钥。例如：

SELECT SK.name, SK.symmetric_key_id, SK.key_length, SK.algorithm_desc,
       KE.crypt_type_desc,
       COALESCE(C.name,AK.name,PSK.name) AS protector_name,
       KE.crypt_property AS encrypted_key,
       COALESCE(DECRYPTBYCERT(C.certificate_id,KE.crypt_property),
                DECRYPTBYASYMKEY(AK.asymmetric_key_id,KE.crypt_property)) AS decrypted_key
  FROM sys.key_encryptions AS KE
  JOIN sys.symmetric_keys AS SK
    ON KE.key_id = SK.symmetric_key_id
  LEFT JOIN sys.certificates AS C
    ON KE.thumbprint = C.thumbprint
  LEFT JOIN sys.asymmetric_keys AS AK
    ON KE.thumbprint = AK.thumbprint
  LEFT JOIN sys.symmetric_keys AS PSK
    ON KE.thumbprint = CAST(PSK.key_guid AS VARBINARY(50));

可以使用以下查询对其进行测试：

-- 
CREATE MASTER KEY ENCRYPTION
BY PASSWORD = 'smGK_MasterKeyPassword@';

-- 
CREATE CERTIFICATE [CERT_V001]
WITH SUBJECT = 'User for protecting SM symetric keys.'


--
CREATE SYMMETRIC KEY [SK_SecurityUsers_V001]
WITH ALGORITHM = AES_256 ENCRYPTION
BY CERTIFICATE [CERT_V001]
GO


DECLARE @Email NVARCHAR(128) = '[email protected]';
DECLARE @EmailEncrypted VARBINARY(256);

OPEN SYMMETRIC KEY [SK_SecurityUsers_V001] DECRYPTION
BY CERTIFICATE [CERT_V001];

SELECT @EmailEncrypted = ENCRYPTBYKEY(KEY_GUID('SK_SecurityUsers_V001'),@Email);
SELECT @EmailEncrypted;

CLOSE SYMMETRIC KEY [SK_SecurityUsers_V001];


OPEN SYMMETRIC KEY [SK_SecurityUsers_V001] DECRYPTION
BY CERTIFICATE [CERT_V001];

SELECT CONVERT(NVARCHAR(128), DECRYPTBYKEY(@EmailEncrypted));

CLOSE SYMMETRIC KEY [SK_SecurityUsers_V001];


--DROP SYMMETRIC KEY [SK_SecurityUsers_V001];
--DROP CERTIFICATE [CERT_V001];
--DROP MASTER KEY;

我想知道，这是否意味着数据根本不受保护？

文章中说：

但是，对于受密码保护和受对称密钥保护的密钥，这很遗憾地不起作用。

我想这意味着我需要使用其中一种加密类型来确保数据受到保护？

我想知道在特定数据库中创建的对称密钥是否存储在主文件组中？

或者它们存储在一些用户无法与之交互的特殊文件组中？

例如，如果我对文件组（主要或次要）执行部分备份，我能否确保备份不包含对称密钥？

了解安全对象层次结构后，我们可以看到，为了创建Symmetric Key和加密数据，我们需要创建：

1. Database Master Key受密码保护
2. Certificate这是受保护的Database Master key

3. Symmetric Key自身，受Certificate

   

在Always Encrypted中，我们可以使用EKM模块来简化这种层次结构。例如，我们可以将证书存储在中Windows Certification Store，这些证书正在保护我们的加密主密钥。

我想知道，如果我不想使用Always Encrypted内置的加密功能，我可以使用EKM模块来创建和管理我的对称密钥（如图所示）。在CREATE SYMMETRIC KEY文档中，我们有provider选项，但没有足够的关于可能的提供者和示例的信息。

我对Certificate在外部存储中存储保护对称密钥或对称密钥很感兴趣，因为这样数据与密钥是分开的，在数据​​库中我们只存储对密钥的引用（就像总是加密的）。Windows Certification Store 对我来说是最佳选择，但我猜 Azure Key Vault 或其他东西也可以。

我有：

• 包含现有数据的表
• SQL Server 2016 SP1
• SQL Server 管理工作室 17.5

我正在使用以下语句使我的表成为临时表：

ALTER TABLE [dbo].[AnalysisCustomRollupsV2JoinGroups]
ADD [SysStartTime] DATETIME2(0) GENERATED ALWAYS AS ROW START HIDDEN CONSTRAINT DF_AnalysisCustomRollupsV2JoinGroups_SysStart DEFAULT GETUTCDATE()  
   ,[SysEndTime] DATETIME2(0) GENERATED ALWAYS AS ROW END HIDDEN CONSTRAINT DF_AnalysisCustomRollupsV2JoinGroups_SysEnd DEFAULT CONVERT(DATETIME2(0), '9999-12-31 23:59:59'),   
PERIOD FOR SYSTEM_TIME ([SysStartTime], [SysEndTime]); 

ALTER TABLE [dbo].[AnalysisCustomRollupsV2JoinGroups]   
SET (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.AnalysisCustomRollupsV2JoinGroupsChanges));

问题：

在我的本地 SQL 实例上，我有很多数据库；很奇怪，查询在其中一些上成功运行，而在其中一些上它给了我以下错误：

消息 13542，级别 16，状态 0，第 51 行在表 'dbo.AnalysisCustomRollupsV2JoinGroups' 上添加 PERIOD FOR SYSTEM_TIME 失败，因为有打开的记录的开始时间设置为将来的值。

有时，当我调试/执行查询时，初始查询会成功运行。

我读到，这可能是因为我在表中有现有数据。所以，我改变了这样的逻辑：

• 创建缓冲区表并用所有记录填充它
• 从原始表中删除记录
• 创建临时表
• 将记录移回并删除缓冲表

同样，在某些数据库上可以，而在其他数据库上则不行。试图解决这个问题，我发现了以下内容：

对于 StartDate，我指定了当前的 UTC 日期——这可以是任何不在未来的日期和时间，但请注意它应该是 UTC 日期和时间。如果我尝试使用 GETDATE，因为我目前在英国夏令时，我会收到以下错误：Msg 13542, Level 16, State 0, Line 51 ADD PERIOD FOR SYSTEM_TIME on table 'TestAudit.dbo.SomeData'失败，因为有打开的记录将期初设置为将来的值。

以上是什么意思？我需要更改机器时间吗？或者因为我的本地机器不是UTC时间我有时会收到这个错误？

我正在测试always encrypted功能，加密列的操作完成后，我有一个包含数百个对象的文件无法通过该sp_refresh_parameter_encryption过程刷新。

我应该调查这些错误并自行执行刷新吗？不这样做的风险是什么？

我正在使用以下 PowerShell 代码创建可用作 Always Encrypted 功能的列主密钥的证书：

New-SelfSignedCertificate -Subject "AlwaysEncryptedSecurityLevelNormalV001" -CertStoreLocation Cert:LocalMachineMy -KeyExportPolicy Exportable -Type DocumentEncryptionCert -KeyUsage KeyEncipherment -KeySpec KeyExchange -KeyLength 2048 -NotAfter (Get-Date).AddYears(100)

然后我导出证书并将其导入到运行 SQL Server 的机器中。在导出过程中，我禁用了导出证书私钥的选项。因此，如果有人尝试导出它，他/她将得到以下信息：

这很好，因为证书私钥受保护以供导出。

我想知道在 Always Encrypted 功能的上下文中是否存在我可能只需要导出没有私钥的证书的情况（作为此证书的工作，它仅保护列加密密钥）？