标签: sql-server-2016

这是另一个查询优化器难题。

也许我只是高估了查询优化器，或者我遗漏了一些东西 - 所以我把它放在那里。

我有一张简单的桌子

CREATE TABLE [dbo].[MyEntities](
  [Id] [uniqueidentifier] NOT NULL,
  [Number] [int] NOT NULL,
  CONSTRAINT [PK_dbo.MyEntities] PRIMARY KEY CLUSTERED ([Id])
)

CREATE NONCLUSTERED INDEX [IX_Number] ON [dbo].[MyEntities] ([Number])

有一个索引和几千行，Number均匀分布在值 0、1 和 2 中。

现在这个查询：

SELECT * FROM
    (SELECT
        [Extent1].[Number] AS [Number],
        CASE
        WHEN (0 = [Extent1].[Number]) THEN 'one'
        WHEN (1 = [Extent1].[Number]) THEN 'two'
        WHEN (2 = [Extent1].[Number]) THEN 'three'
        ELSE '?'
        END AS [Name]
        FROM [dbo].[MyEntities] AS [Extent1]
        ) P
WHERE P.Number = 0;

是否 …

SQL Server 2016 中引入的新查询存储很棒。它很好地替代了我以前使用旧的 Profiler 工具所做的大部分工作。但是，我还没有找到一种方法来捕获与对它嗅出的高资源消耗查询的单个调用相关联的参数值。这可能吗？

我知道查询存储更多地处理聚合数据而不是单个调用，所以我怀疑我在这里可能不走运。当我发现一个缓慢的查询时，我发现将参数与其最慢的调用之一关联起来也很方便进行故障排除。我想知道如何使用最新最好的工具来做到这一点。（我不会错过使用 Profiler！）

在安全方面，查询存储比 Profiler 更容易锁定吗？我认为它需要从某个级别的单个调用中捕获数据才能计算聚合。只是不确定它是否存储了其中的任何一个。

SQL Server 2016 引入了STRING_SPLIT，它非常快，是人们在 2016 年之前推出的任何自制实现的绝佳替代品。

不幸的是，STRING_SPLIT 只支持单字符分隔符，这并不总是足够的。有谁知道允许在分隔符中使用多个字符的良好实现？

我从一开始说，我的问题/问题类似于此之前的一个，但因为我不知道的原因或起始信息是一样的，我决定后，我的问题有一些更多的细节。

手头问题：

• 在一个奇怪的时间（接近工作日结束），一个生产实例开始出现异常行为：
  • 实例的高 CPU（从大约 30% 的基线增加到大约两倍并且仍在增长）
  • 增加的事务数/秒（尽管应用程序负载没有看到任何变化）
  • 增加空闲会话数
  • 从未显示此行为的会话之间的奇怪阻塞事件（即使读取未提交的会话也会导致阻塞）
  • 间隔的顶部等待是非页面闩锁排在第一位，锁排在第二位

初步调查：

• 使用 sp_whoIsActive 我们看到我们的监控工具执行的查询决定运行速度极慢并占用大量 CPU，这是以前从未发生过的；
• 其隔离级别未提交读取；
• 我们查看了我们看到古怪数字的计划：StatementEstRows="3.86846e+010" 有大约 150 TB 的估计数据要返回
• 我们怀疑是监控工具的查询监控功能造成的，所以我们禁用了该功能（我们还向我们的提供商开了一张票，以检查他们是否知道任何问题）
• 从第一个事件开始，它又发生了几次，每次我们终止会话，一切都会恢复正常；
• 我们意识到该查询与MS 在 BOL 中用于查询存储监控的查询之一极为相似- 最近性能下降的查询（比较不同时间点）
• 我们手动运行相同的查询并看到相同的行为（CPU 使用不断增加，增加闩锁等待，意外锁定......等）

有罪查询：

Select qt.query_sql_text, 
    q.query_id, 
    qt.query_text_id, 
    rs1.runtime_stats_id AS runtime_stats_id_1,
    interval_1 = DateAdd(minute, -(DateDiff(minute, getdate(), getutcdate())), rsi1.start_time), 
    p1.plan_id AS plan_1, 
    rs1.avg_duration AS avg_duration_1, 
    rs2.avg_duration AS avg_duration_2,
    p2.plan_id AS plan_2, 
    interval_2 = DateAdd(minute, -(DateDiff(minute, getdate(), getutcdate())), rsi2.start_time), 
    rs2.runtime_stats_id AS runtime_stats_id_2
From sys.query_store_query_text AS qt 
Inner Join sys.query_store_query AS …

我正在尝试从以下位置插入结果集：

SELECT * FROM sys.database_scoped_configurations

进入临时表，因为我想检查服务器上所有数据库的设置。所以我写了这段代码：

DROP TABLE IF EXISTS #h
CREATE TABLE #h(dbname sysname, configuration_id INT, name sysname,     value SQL_VARIANT,  value_for_secondary SQL_VARIANT)
EXEC sys.sp_MSforeachdb 'USE ?; insert into #h(dbname, configuration_id, name, value,value_for_secondary)  SELECT ''?'' as dbname, * FROM sys.database_scoped_configurations  D'
SELECT * FROM #h H

但随后将只有每个数据库一行，而不是4行，我从在每个数据库中运行一个普通的选择期待。

我知道有比使用 sp_MSForEachDB 更好的编码方法，我尝试了几种方法。但是我每个数据库仍然只有一行。我在 SQL Server 2016 RTM 和 SP1 上都试过了

这是 SQL Server 2016 的错误，还是我做错了什么？

更新：@AmitBanerjee - Microsoft SQL Server 产品组的高级项目经理确认 MS 将调查该问题，因为它是一个缺陷。

有没有人遇到过在启用 TDE 并使用MAXTRANSFERSIZE> 65536（在我的情况下，我选择 65537 以便我可以压缩 TDE 数据库）的情况下恢复在 SQL Server 2016 上进行的备份的问题CHECKSUM？

下面是一个repro：

--- create database 
create database test_restore
go
-- create table
create table test_kin (fname char(10))
go
-- Enable TDE 

use master
GO
CREATE CERTIFICATE test_restore WITH SUBJECT = 'test_restore_cert'
GO
SELECT name, pvt_key_encryption_type_desc, * FROM sys.certificates WHERE name = 'test_restore'
GO
use test_restore
go
CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM …

我创建了一个包含 650 个 Numeric(19,4) 列的表。当我打开页面压缩时，通过运行

ALTER TABLE fct.MyTable REBUILD  WITH (DATA_COMPRESSION = PAGE);

我得到

消息 1975，级别 16，状态 1
索引“PK_Mytable”行长度超过了“8060”字节的最大允许长度。

但是 650 乘以 9 字节仅为 5850 字节，这与规定的 8060 字节的限制相去甚远。

服务器运行的是 Windows 2012 r2 和 SQL Server 2016 SP1 CU2

使用页面压缩时的行开销是多少？

这是一些代码来显示我的意思：

/* test script to demo MSG 1975 */
DECLARE @sql NVARCHAR(max)='', @i INT =0
drop table if exists dbo.mytable;

SET @sql = 'Create table dbo.Mytable (MyTableID bigint not null 
  identity(1,1) primary key clustered, '

WHILE @i < 593 BEGIN
    SET …

在 SQL Server 2012 中，我有一个策略设置为不允许在表名中使用空格。但是，当我在 SQL Server 2016 中使用相同的策略时，出现错误。

这是条件的代码：

DECLARE @condition_id INT
EXEC msdb.dbo.sp_syspolicy_add_condition @name=N'No Spaces', @description=N'No spaces in table names.', @facet=N'IMultipartNameFacet', @expression=N'<Operator>
  <TypeClass>Bool</TypeClass>
  <OpType>NOT_LIKE</OpType>
  <Count>2</Count>
  <Attribute>
    <TypeClass>String</TypeClass>
    <Name>Name</Name>
  </Attribute>
  <Constant>
    <TypeClass>String</TypeClass>
    <ObjType>System.String</ObjType>
    <Value>% %</Value>
  </Constant>
</Operator>', @is_name_condition=4, @obj_name=N'% %', @condition_id=@condition_id OUTPUT
SELECT @condition_id

这是策略的代码：

DECLARE @object_set_id INT
EXEC msdb.dbo.sp_syspolicy_add_object_set @object_set_name=N'Table Names_ObjectSet', @facet=N'IMultipartNameFacet', @object_set_id=@object_set_id OUTPUT
SELECT @object_set_id

DECLARE @target_set_id INT
EXEC msdb.dbo.sp_syspolicy_add_target_set @object_set_name=N'Table Names_ObjectSet', @type_skeleton=N'Server/Database/Sequence', @type=N'SEQUENCE', @enabled=False, @target_set_id=@target_set_id OUTPUT
SELECT @target_set_id

EXEC msdb.dbo.sp_syspolicy_add_target_set_level @target_set_id=@target_set_id, @type_skeleton=N'Server/Database', @level_name=N'Database', @condition_name=N'', @target_set_level_id=0
EXEC …

在 SQL Server 中，Except运算符如何在幕后工作的内部算法是什么？它是否在内部获取每一行的哈希值并进行比较？

David Lozinksi 进行了一项研究，SQL：在不存在新记录的地方插入新记录的最快方法他表明，对于大量行，Except 语句是最快的；与我们下面的结果密切相关。

假设：我认为 Left join 会最快，因为它只比较 1 列，Except 花费的时间最长，因为它必须比较所有列。
有了这些结果，现在我们的想法是，Except 自动并在内部获取每一行的哈希值？我查看了除非执行计划，它确实使用了一些哈希。

背景：我们的团队正在比较两个堆表。表 A 不在表 B 中的行被插入到表 B 中。

堆表（来自旧文本文件系统）没有主键/guids/标识符。有些表有重复的行，所以我们找到每一行的Hash，并去除重复，并创建主键标识符。

1）首先我们运行一个except语句，排除（哈希列）

select * from TableA
Except
Select * from TableB,

2）然后我们在HashRowId上的两个表之间运行左连接比较

select * 
FROM dbo.TableA A
left join dbo.TableB B
    on A.RowHash =  B.RowHash
where B.Hash is null

令人惊讶的是，Except Statement Insert 是最快的。

结果实际上与 David Lozinksi 的测试结果接近

我正在运行一些SHRINKFILE操作来清理文件组中的一堆微小的、不必要的文件。对于其中一种收缩，以下命令会导致错误：

DBCC SHRINKFILE (N'myfile' , EMPTYFILE)'

数据库 ID x 的文件 ID x 无法收缩，因为它正在被另一个进程收缩或为空

它不是空的，也不是被缩小的。它正在一个数据库上运行，除了我自己，其他人目前都没有使用它。自动收缩未启用且从未启用。但是，在我开始使用它之前，会定期对这个数据库进行手动收缩，如果这很重要的话。

在SQLServerCentral 上，十年前的一个线程建议向文件添加几 MB，因为这“会重置一个内部计数器或开关，告诉它现在不在缩小中间。”

这有效 - 太棒了。但是任何人都可以更详细地解释如何/为什么在 SQL Server 内部工作？