标签: sql-server-2016

我在 Always On 可用性组中有一对 Microsoft SQL Server 2016 节点。我正在尝试对BULK INSERT位于 Windows Server 2016 文件服务器故障转移群集上的文件执行（使用 SQL Server 2016 Management Studio 查询），但出现以下错误：

消息 4861，级别 16，状态 1
无法批量加载，因为无法打开文件“\nas2.my.domain\Microsoft SQL Server 2016 Enterprise\test.txt”。操作系统错误代码 5（访问被拒绝。）。

无论我使用活动节点名称 ( nas2.my.domain) 还是故障转移群集侦听器 ( nas.my.domain)，都会发生这种情况。

环顾四周后，我发现这是由于 SQL Server 由于与BULK INSERT.

如果您使用 Windows 身份验证连接到 SQL Server，则 SQL Server 服务帐户在连接到文件服务器时会尝试模拟您的用户帐户。如果您使用 SQL Server 身份验证进行连接，它将以 SQL Server 服务帐户的身份连接到文件服务器。

如果委派和模拟配置不正确（默认状态），SQL Server 服务将无法模拟您的用户帐户，并将退回尝试以匿名用户身份连接到文件服务器。

这可以通过查看文件服务器上的安全事件日志来确认。这些事实以及有关配置无约束和约束委派的指南记录在以下链接中：

• 如何：具有约束委派的 SQL Server 大容量插入（访问被拒绝）

• 批量插入和 Kerberos

我已经尝试按照thesqldude的指南中的说明进行操作，但它仍然无法正常工作。

我尝试使用的数据库BULK INSERT不是可用性组的一部分，因此只有 MSSQL1 节点应该相关。文件服务器在 …

我有一个查询在我们的服务器上运行大约需要 3 个小时——而且它没有利用并行处理。（大约 115 万条记录dbo.Deidentified， 300 条记录dbo.NamesMultiWord）。服务器可以访问 8 个内核。

  UPDATE dbo.Deidentified 
     WITH (TABLOCK)
  SET IndexedXml = dbo.ReplaceMultiWord(IndexedXml),
      DE461 = dbo.ReplaceMultiWord(DE461),
      DE87 = dbo.ReplaceMultiWord(DE87),
      DE15 = dbo.ReplaceMultiWord(DE15)
  WHERE InProcess = 1;

和ReplaceMultiword是一个过程定义为：

SELECT @body = REPLACE(@body,Names,Replacement)
 FROM dbo.NamesMultiWord
 ORDER BY [WordLength] DESC
RETURN @body --NVARCHAR(MAX)

是呼吁ReplaceMultiword阻止形成平行计划吗？有没有办法重写它以允许并行？

ReplaceMultiword 以降序运行，因为某些替换是其他替换的简短版本，我希望最长的匹配成功。

例如，可能有“乔治华盛顿大学”和另一个来自“华盛顿大学”。如果“华盛顿大学”比赛是第一场，那么“乔治”就会被甩在后面。

从技术上讲，我可以使用 CLR，只是我不熟悉如何使用。

查询存储强制计划功能似乎没有执行该计划。

我知道Query Store - Forced 并不总是意味着 Forced；然而，我的计划可能不会发生微不足道的变化，但查询优化器可能会继续选择不正确的索引、循环选择等。

基本上：它不尊重我被迫的计划选择。我强迫了很多计划，但它根本行不通。

1. 当我查看sys.query_store_plan force_failure_count.
2. 扩展事件query_store_plan_forcing_failed不会产生任何结果。0 事件。

例如，在 20.09 强制执行的计划。只有 1 个编译碰巧使用了强制计划。

计划大相径庭，一个使用带有 INDEX 1 的 Hash Match join，另一个使用带有 INDEX 2 的 Loop Join。

版本：Microsoft SQL Server 2016 (SP1-GDR) (KB3210089) - 13.0.4202.2 (X64)

我在这里缺少什么？

我们正在尝试让 Service Broker 在我们的环境中工作以解决业务案例。我不知道消息标题是否合适，但我的问题如下。但这可能不是一个好问题，所以在那之后是我们正在做的事情以及为什么我认为这是一个正确的问题。

在结束对话之前，应该在对话中发送多少条消息？

我们想使用 Service Broker 来异步更新结果表。结果表变平且快速。我们在基表上有触发器，它们发送带有表和主键的消息。我们有三个队列：

• 低延迟 - 目标是处理 15 秒。它处理与特定项目相关的更改项目。
• 批量队列 - 目标是处理 5 分钟。它处理影响数百（或数千）项的变化。它会列出受影响的项目并将它们提供给延迟低延迟队列。
• 延迟低延迟 - 目标是处理 30 分钟。这会处理项目，但仅来自批量队列。

基本上，如果客户的信息更新，则会影响许多产品，因此会被发送到批量队列以进行较慢的处理。但是，如果产品更新，则会将其发送到低延迟队列。

我们重用类似于 Remus Rusanu 的博客http://rusanu.com/2007/04/25/reusing-conversations/ 的对话，除了我们根据主键的模数来做。这具有辅助主键重复数据删除的附带好处。

因此，我们正在重复使用对话并且符合我们的指导方针。使用两个线程，我能够每秒处理 125 条消息（人工丢弃数千条消息），这足以跟上生产速度（估计为 15 条消息/秒）。

但是，我们遇到的问题是，经过一段时间（约 4 小时或 120K 条消息）后，我们开始在 sysdesend 和队列表中看到阻塞和高争用。锁是 LCK_M_U 和 KEY 锁。有时，hobt 解析为 sysdesend，有时解析为特定的队列表 (queue_)。

我们有一个流程可以在 24 小时或 30 分钟不活动后结束对话，我们可以增加对话循环之前的时间。

我们使用的是 SQL 2016 Enterprise (13.0.4001.0)

1. 触发火灾（发送到低延迟或批量）
2. 查找或创建会话句柄。
3. 发信息
4. 队列激活程序
5. 更新结果表

清理过程每 10 分钟运行一次，以查看是否有任何空闲对话。ltd 它连续发现它们超过 3 次，它将其标记为不活动并结束对话。

如果有任何可能有益的其他细节，请告诉我。我对 Service Broker 没有太多经验，所以我不知道我们的消息/秒是低、高还是无动于衷。

更新

所以我们今天再次尝试，遇到了同样的问题。我们将对话生命周期更改为 2 小时，但没有任何影响。所以我们然后实现了 …

我想看看是否有办法欺骗 SQL Server 为查询使用某个计划。

1. 环境

想象一下，您有一些在不同进程之间共享的数据。因此，假设我们有一些占用大量空间的实验结果。然后，对于每个过程，我们知道我们想要使用哪一年/哪月的实验结果。

if object_id('dbo.SharedData') is not null
    drop table SharedData

create table dbo.SharedData (
    experiment_year int,
    experiment_month int,
    rn int,
    calculated_number int,
    primary key (experiment_year, experiment_month, rn)
)
go

现在，对于每个过程，我们都将参数保存在表中

if object_id('dbo.Params') is not null
    drop table dbo.Params

create table dbo.Params (
    session_id int,
    experiment_year int,
    experiment_month int,
    primary key (session_id)
)
go

2. 测试数据

让我们添加一些测试数据：

insert into dbo.Params (session_id, experiment_year, experiment_month)
select 1, 2014, 3 union all
select 2, 2014, 4 
go

insert into …

以下查询SUM对列存储表执行窗口化处理1500 total rows，每个表的值为 0 或 1，并溢出INT数据类型。为什么会这样？

SELECT a, p, s, v, m, n,
    SUM(CASE WHEN n IS NULL THEN 0 ELSE 1 END)
        OVER (PARTITION BY s, v, a ORDER BY p) AS lastNonNullPartition
FROM (
    SELECT a, p, s, v, m, n,
        RANK() OVER (PARTITION BY v, s, a, p ORDER BY m) AS rank
    FROM #t /* A columnstore table with 1,500 rows */
)  x
WHERE x.rank = 1
--Msg 8115, …

在测试从 SQL Server 2014 SP1 (12.0.4422.0) 到 SQL Server 2016 CTP 3.2 (13.0.900.73) 的升级时，我遵循推荐的更新过程并遇到了一个问题，即故障转移后数据库无法在旧的主数据库上启动到更新的辅助。我们的设置是一个主副本和一个辅助副本，我完成的步骤是：

1. 删除同步提交辅助副本上的自动故障转移
2. 将辅助服务器实例升级到新版本
3. 手动故障转移到辅助副本
4. 验证数据库在新的主副本上是否在线
5. 将以前的主副本升级到新版本

升级辅助节点和故障转移使其成为主节点完全按预期工作。但是在升级以前的主副本后，我注意到其上的数据库在 SSMS 中列为Not Synchronizing / In Recovery。尝试访问它们也会生成错误消息：

数据库...无法访问。（对象浏览器）

通过我看到的 SQL Server 日志检查

无法打开数据库 '...' 版本 782。将数据库升级到最新版本。

查询master..sysdatabases表，确实是旧版本，升级过程中没有更新：

不幸的是，日志没有指出它为什么没有更新，并且可用性组仪表板只给出了一个通用警告，表明某些可用性数据库的数据同步状态不健康，没有任何原因。

我尝试使用 TSQL 分离数据库或将它们设置为离线以“踢”它进行更新，但由于它们是 SQL AG 的一部分，因此这些命令不起作用。

当数据库是 SQL AG 的一部分时，如何将数据库升级到最新版本？

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

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

我有一张简单的桌子

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;

是否 …

我有一台运行 Windows 2012 R2 Datacenter 64 位的服务器。我使用 SQL 2016 RC3 没有问题，我想用我们从 MSDN 获得的 RTM 版本替换它。

卸载RC3然后安装RTM后，我无法远程连接到服务器。经过检查，我在配置管理器中看到“SQL Server 网络配置”没有节点。列出了 32 位版本，并启用了 TCP/IP。如何安装这个缺失的节点？

我已启动 SQL Browser 服务并尝试修复 2016 安装。似乎没有什么可以恢复这个缺失的组件。

我发现有趣的是，我无法卸载 RC3 和 RTM 安装的某些部分。我不确定这是否相关。我按照微软关于卸载 SQL Server 的说明进行操作，所以我觉得我做的一切都是正确的。

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

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

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