标签: 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 2016 数据库中的某些现有表启用系统版本控制。我正在遵循Microsoft 的这些说明。

其中一张表如下所示：

CREATE TABLE [dbo].[ClientBeacon](
    [ClientId] [int] NOT NULL,
    [BeaconId] [int] NOT NULL,
    [FromDate] [datetime] NOT NULL,
    [ToDate] [datetime] NULL,
    [Deleted] [bit] NOT NULL,
    [ModifiedByUserId] [nvarchar](128) NOT NULL,
    [ModifiedOn] [datetime] NOT NULL,
    [Timestamp] [timestamp] NOT NULL,
    CONSTRAINT [PK_ClientBeacon] PRIMARY KEY CLUSTERED 
    (
        [ClientId] ASC,
        [BeaconId] ASC
    )
)

我试图运行的脚本如下所示：

CREATE SCHEMA History;   
GO

ALTER TABLE dbo.ClientBeacon   
   ADD   
      SysStartTime datetime2(0) GENERATED ALWAYS AS ROW START HIDDEN CONSTRAINT DF_ClientBeacon_SysStartTime DEFAULT SYSUTCDATETIME(),
      SysEndTime datetime2(0) GENERATED ALWAYS …

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

DBCC SHRINKFILE (N'myfile' , EMPTYFILE)'

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

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

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

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

我最近一直致力于了解存储在系统健康扩展事件事件文件中的数据或指标。

我们正在尝试使用此处提供的系统运行状况来实现性能指标的数据收集

有一些报告提供了从名为的系统运行状况事件收集的 CPU 利用率、其他进程利用率等指标

scheduler_monitor_system_health_ring_buffer_recorded

对于一些繁忙的服务器，我无法理解为什么报告中列为 SQL CPU 利用率的字段“process_utilization”大部分时间都在 100 以上。在高峰时间，它在 120-160 之间变化，因此报告是始终显示 CPU 高于 100，即使当我从服务器活动监视器中检查时，情况并非如此。

我在 Github 中提出了这个问题，但似乎没有修复或回应。

因此，我的问题是

1. 如何使用记录的系统运行状况环缓冲区获取服务器的 SQL CPU 利用率的准确数字？

2. 报告还显示根据其报告计算的以下 2 个字段的计数器

1. 100-System_idle-process_utilization 作为 OtherProcessUtil

2. 100-system_idle 作为 SystemUtil

这些OtherProcessUtil和SystemUtil需要/有什么帮助？

3. 我也看到内存利用率每次总是显示为 100。这似乎也不正确。有人注意到了吗？

其他工具（如 Idera 和 sentry [我测试过的]）不会显示相同服务器的 CPU 使用率超过 100%。我对相同的负载进行了并排比较。

在 3 节点可用性组中，由于 Microsoft 文档中涵盖的原因，辅助副本通常会受到重做延迟的影响：

故障排除：主副本上的更改未反映在辅助副本上

根据我的经验，我最常看到的问题似乎是：

主要副本上长时间运行的事务会阻止在次要副本上读取更新。

和

辅助副本上的重做线程被长时间运行的只读查询阻止进行数据定义语言 (DDL) 更改。重做线程必须先解除阻塞，然后才能为读取工作负载提供进一步的更新。

我可以通过查看扩展事件会话“AlwayOn Health”来观察这一点：

当应用程序向辅助副本发出只读查询时，如果在主副本上运行大量记录的操作（如索引优化），同步滞后变得明显，并且我看到辅助副本上未提交的日志记录中有大量积压，如所述在上面的 MS 文档中。

我的问题是为什么我看到 CMEMTHREAD 在主副本上进行索引重组时在辅助副本上等待：

这是正常/预期的行为还是其他什么？

虽然辅助副本上有一些读取活动，但这些查询在运行时通常<1 秒，偶尔<10 秒查询。CPU 使用率在 5% 左右。

Output of @@VERSION: Microsoft SQL Server 2016 (SP1-CU10-GDR) (KB4293808) - 
13.0.4522.0 (X64)   Jul 17 2018 22:41:29   Copyright (c) Microsoft Corporation  
Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2012 R2 
Standard 6.3 <X64> (Build 9600: ) (Hypervisor) 

• 仅在辅助副本上观察到 CMEMTHREAD 等待
• 显示此等待（和滞后）的副本是主动查询的同步副本

更新：我刚刚发现在索引优化期间再次发生此 WAIT。我终止了索引作业，然后显然停止了同步延迟的增加，但是 CMEMTHREAD 等待继续并且重做似乎很慢。我还注意到偶尔 PARALLEL_REDO_FLOW_CONTROL 在重做线程上等待，所以我只是简单地执行，DBCC TRACEON (3459, -1)然后重做速度突然增加，积压开始非常快地清除。

您可以看到我在下午 …

我正在尝试提出一个递归 CTE 和/或窗口函数来创建一个函数。

几天后，我将函数归结为（伪代码），我拥有N和B，并且需要生成E：

E _n = B _n * (1 - SUM( E ₁ , E ₂ , ... E _n-1 ))

例子：

?????????????????????????????????
? N ? B           ? E           ?
?????????????????????????????????
? 0 ? 0.142857143 ? 0.142857143 ?
? 1 ? 0.285714286 ? 0.244897959 ?
? 2 ? 0.285714286 ? 0.174927114 ?
? 3 ? 0.285714286 ? 0.124947938 ?
? 4 ? 0.285714286 ? 0.089248527 ?
? 5 ? 0.4         ? 0.089248527 …

我正在尝试找出提高非常慢查询性能的方法。它有更明显的问题，但我注意到的一件事是 WHERE 子句中的条件之一是 'AND t.data IS NOT NULL' 而表 t 的 'data' 列没有为 NULL 的条目并且确实有一个 NOT NULL 约束。

所以我想知道查询优化器是否能够忽略条件。我的想法是，它不能仅仅因为约束而这样做（因为不能保证它是否是用 NOVALIDATE 创建的），但可能足够“聪明”以使用有关列中 NULL 字段数量的统计信息。

我自己的测试是不确定的，我无法找到有关此主题的任何进一步信息。

我一直在使用旧提供程序 (SQLNCLI) 的链接服务器，没有任何问题，正如Microsoft推荐的那样，我计划切换到新提供程序 (MSOLEDBSQL)。安装驱动程序后，我可以使用以下 T-SQL 添加链接服务器

EXEC sp_addlinkedserver     
   @server=N'SQL02\DEV1',   
   @srvproduct=N'',  
   @provider=N'MSOLEDBSQL',   
   @datasrc=N'SQL02,1933';  

不幸的是，当我尝试查询新的链接服务器时出现以下错误：

我试过的查询：

--- example 1
select * from OPENQUERY ([SQL02\DEV1], 'select name from sys.databases');

--- example 2
select name from [SQL02\DEV1].master.sys.databases;


--- example 3 (without linked server dependency)
SELECT c.* FROM OPENROWSET(
      'MSOLEDBSQL'
    , 'Server=SQL02,1933;Database=master;Integrated Security=True;'
    , 'SELECT name FROM sys.databases;'
    ) c;

从所有示例中得到相同的错误：

不支持 OLE DB 提供程序“MSOLEDBSQL”与 SQL Server 的进程外使用。

这是否真的意味着 SQL-2016 不支持使用新的提供程序 MSOLEDBSQL，尤其是在链接服务器中，或者除了重新安装驱动程序和重新启动 SQL Server 之外，我还有什么遗漏。