标签: sql-server-2017

数据库 SQL Server 2017 Enterprise CU16 14.0.3076.1

我们最近尝试从默认的 Index Rebuild 维护作业切换到 Ola Hallengren IndexOptimize。默认的索引重建作业已经运行了几个月没有任何问题，并且查询和更新的执行时间在可接受的范围内。在IndexOptimize数据库上运行后：

EXECUTE dbo.IndexOptimize
@Databases = 'USER_DATABASES',
@FragmentationLow = NULL,
@FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationLevel1 = 5,
@FragmentationLevel2 = 30,
@UpdateStatistics = 'ALL',
@OnlyModifiedStatistics = 'Y'

性能极度下降。之前花费 100 毫秒的更新语句在之后IndexOptimize花费了 78.000毫秒（使用相同的计划），并且查询的性能也差了几个数量级。

由于这仍然是一个测试数据库（我们正在从 Oracle 迁移生产系统），我们恢复到备份并禁用IndexOptimize，一切恢复正常。

但是，我们想了解什么IndexOptimize与Index Rebuild可能导致这种极端性能下降的“正常”不同，以确保我们在投入生产后避免这种情况。任何关于寻找什么的建议将不胜感激。

更新语句缓慢时的执行计划。即
IndexOptimize 之后的
实际执行计划（即将推出）

我一直无法发现差异。
快速时为同一个查询做
计划 实际执行计划

我 在 Ubuntu (Linux) 上安装了mssql-server和mssql-tools。当我尝试使用以下命令行使用bcp命令导出数据时：

bcp DBname.dbo.Täble_Name out Täble_Name -c -k  -S127.0.0.1 -Usa -PpassWord -r ~

我收到此错误：

SQLState = 37000，NativeError = 102
错误 = [Microsoft][ODBC Driver 13 for SQL Server][SQL Server]'?' 附近的语法不正确。

该?是ä。

如果我Täble_Name用方括号括起来：

 bcp DBname.dbo.[Täble_Name] out Täble_Name -c -k  -S127.0.0.1 -Usa -PpassWord -r ~

我在对象名称上收到此错误：

SQLState = S0002，NativeError = 208
错误 = [Microsoft][ODBC Driver 13 for SQL Server][SQL Server]无效的对象名称“DBname.dbo.Täble_Name”。

我进一步添加了单引号''以及-q选项（启用带引号的标识符）：

bcp 'DBname.dbo.[Täble_Name]' out …

我正在寻找有关如何使用手动播种设置分布式可用性组的分步演练。我可以让自动播种工作，但是当我尝试手动播种时，我无法将辅助数据库放入转发器上的 AG。

如果我在尝试将数据库添加到常规 AG 之前将分布式 AG 添加到辅助服务器，则会收到以下消息：

Msg 41190, Level 16, State 7, Line 22
Availability group 'MYDB' failed to process add-database command.  The local availability replica is not in a state that could process the command.  Verify that the availability group is online and that the local availability replica is the primary replica, then retry the command. 

如果我尝试先添加数据库而不加入辅助数据库上的分布式 AG，我会收到以下消息，因为它认为它应该是主数据库：

Msg 927, Level 14, State 2, Line 22
Database 'MYDB' cannot be opened. It is in the middle of a …

我正在尝试生成一个示例查询计划来说明为什么联合两个结果集比在 JOIN 子句中使用 OR 更好。我写的一个查询计划让我很难过。我正在使用 StackOverflow 数据库和 Users.Reputation 上的非聚集索引。

查询是

CREATE NONCLUSTERED INDEX IX_NC_REPUTATION ON dbo.USERS(Reputation)
SELECT DISTINCT Users.Id
FROM dbo.Users
INNER JOIN dbo.Posts  
    ON Users.Id = Posts.OwnerUserId
    OR Users.Id = Posts.LastEditorUserId
WHERE Users.Reputation = 5

查询计划位于https://www.brentozar.com/pastetheplan/?id=BkpZU1MZE，我的查询持续时间为 4:37 分钟，返回 26612 行。

我以前从未见过从现有表创建这种类型的常量扫描 - 我不熟悉为什么对每一行都运行常量扫描，而常量扫描通常用于用户输入的单行例如 SELECT GETDATE()。为什么用在这里？我非常感谢阅读此查询计划的一些指导。

如果我将 OR 拆分为 UNION，它会生成一个标准计划，运行 12 秒，返回相同的 26612 行。

SELECT Users.Id
FROM dbo.Users
    INNER JOIN dbo.Posts
       ON Users.Id = Posts.OwnerUserId
WHERE Users.Reputation = 5
UNION 
SELECT Users.Id
FROM dbo.Users
    INNER JOIN dbo.Posts
       ON …

我正在尝试对实际执行计划使用显示计划分析 (SSMS) 来解决执行缓慢的查询。分析工具指出，在计划中的几个地方，对行数的估计与返回的结果不一致，并进一步给了我一些隐式转换警告。

我不明白这些 int 到 Varchar 的隐式转换 - 引用的字段不是查询中任何参数/过滤器的一部分，并且在所有涉及的表中，列数据类型是相同的：

我收到以下 CardinalityEstimate 警告：

表达式中的类型转换 (CONVERT_IMPLICIT(varchar(12),[ccd].[profileid],0)) 可能会影响查询计划选择中的“CardinalityEstimate”——这个字段在我的数据库中到处都是整数

表达式中的类型转换 (CONVERT_IMPLICIT(varchar(6),[ccd].[nodeid],0)) 可能会影响查询计划选择中的“CardinalityEstimate”——这个字段在我的数据库中到处都是 smallint

表达式中的类型转换 (CONVERT_IMPLICIT(varchar(6),[ccd].[sessionseqnum],0)) 可能会影响查询计划选择中的“CardinalityEstimate”——这个字段在我的数据库中到处都是 smallint

表达式中的类型转换 (CONVERT_IMPLICIT(varchar(41),[ccd].[sessionid],0)) 可能会影响查询计划选择中的“CardinalityEstimate”——这个字段在我的数据库中到处都是小数

[编辑]这里是查询和实际执行计划供参考 https://www.brentozar.com/pastetheplan/?id=SysYt0NzN

和表定义..

/****** Object:  Table [dbo].[agentconnectiondetail]    Script Date: 1/10/2019 9:10:04 AM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[agentconnectiondetail](
    [sessionid] [decimal](18, 0) NOT NULL,
    [sessionseqnum] [smallint] NOT NULL,
    [nodeid] [smallint] NOT NULL,
    [profileid] [int] NOT NULL,
    [resourceid] [int] NOT NULL,
    [startdatetime] [datetime2](7) NOT NULL,
    [enddatetime] [datetime2](7) NOT NULL, …

我有特定的清理代码试图删除一些重复项。

这在许多客户站点上完美运行。日志告诉我此查询至少消耗了 1 秒到 45 秒：

DELETE FROM [tbl]
WHERE [Id] NOT IN
(
    SELECT MIN([Id])
    FROM [tbl]
    GROUP BY [IdProject], [IdRepresentative], [TimeStart]
) 

但是我有一个客户，该查询运行了 4 个多小时（到现在为止还没有结束）！我检查了数据库 ( DBCC CHECKDB)，我已经更新了统计信息 ( sp_updatestats)，也UPDATE STATISTICS [tbl] WITH FULLSCAN显示没有变化。

我有来自客户的 DB 的原始备份。我在 SQL Server 14.0.2002.14 上运行它。我有标准版，客户用的是速成版。

我可以在活动监视器中看到没有其他人在使用数据库。没有等待，CPU 使用率为 25%（正好是我的 4 个 CPU 中的 1 个）。同样在我的测试用例中，没有其他人在使用数据库。

我重新查询并检查了以下语句：

DELETE FROM [tbl]
FROM [tbl] AS t
LEFT OUTER JOIN 
    (
        SELECT MIN([Id]) AS [IdMin]
        FROM [tbl]
        GROUP BY [IdProject], [IdRepresentative], [TimeStart]
    ) …

Parallel redo is shutdown for database '' with worker pool size [2].

Parallel redo is started for database '' with worker pool size [2].

Starting up database ''

我在客户端 PC 上的 Windows 事件查看器（事件 ID 49930 或 17137）中经常看到这种情况。这是一台普通的 Windows PC，而不是服务器，带有 SQL Server 2017 Express Edition 和 SSMS 的默认实例。

什么是并行重做？

这是错误日志的输出：

2019-05-28 12:23:03.360 spid16s A self-generated certificate was successfully loaded for encryption.
2019-05-28 12:23:03.360 spid16s Server is listening on [ 'any' <ipv6> 1433].
2019-05-28 12:23:03.360 spid16s Server is listening on [ 'any' …

我有几个用户在我的管理下共享 MS SQL Server 2017。他们不应该看到（甚至不知道）该服务器上的其他用户及其数据。每个用户都有自己的数据库。他们可以对他们的数据库做任何他们想做的事情。

我正在使用 SQL Server 的Partial Containment功能将用户锁定到位。登录名是在数据库中创建的。这很有效，因为他们不会以这种方式看到其他用户帐户或数据库。数据库登录名被添加到我使用以下命令创建的数据库角色中：

USE dbname
CREATE ROLE dbrole
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE TABLE, CREATE VIEW, ALTER ANY SCHEMA TO dbrole
DENY EXECUTE TO dbrole

我刚刚创建了一个 db 登录帐户，并将其添加到所述角色中。用户没有其他权限（我知道）。

剩下的唯一问题是 SSMS 仍然能够浏览服务器的文件系统。如果我右键单击数据库并选择Tasks -> Restore -> Database，然后选择Device: -> [...]并添加文件。这允许 SSMS 浏览服务器的文件系统，我想否认这一点。用户实际上不能恢复数据库，但他可以浏览文件系统。

这里的这个问题表明 SSMS 正在使用存储过程xp_fixeddrives，xp_dirtree并且xp_fileexist. 但是，当以具有该组权限的用户身份执行时，这些存储过程返回空结果。我读过这是当用户不是 sysadmin 角色的成员时的行为。这已经让我有点困惑，因为我明确拒绝对 dbrole 执行 EXECUTE，但用户仍然可以执行存储过程。但是，通过 SSMS 浏览文件系统时，它仍然不是空的。

SSMS 从哪里获取文件系统信息，如何防止这种情况发生？

编辑：我也刚刚注意到 SSMS 能够检索所有数据库的服务器上存在的所有数据库备份的列表。同样，我不知道它如何获取这些信息以及如何防止它。

稀疏

在对稀疏列进行一些测试时，正如您所做的那样，出现了性能下降，我想知道其直接原因。

数据线

我创建了两个相同的表，一个有 4 个稀疏列，一个没有稀疏列。

--Non Sparse columns table & NC index
CREATE TABLE dbo.nonsparse( ID INT IDENTITY(1,1) PRIMARY KEY NOT NULL,
                      charval char(20) NULL,
                      varcharval varchar(20) NULL,
                      intval int NULL,
                      bigintval bigint NULL
                      );
CREATE INDEX IX_Nonsparse_intval_varcharval
ON dbo.nonsparse(intval,varcharval)
INCLUDE(bigintval,charval);

-- sparse columns table & NC index

CREATE TABLE dbo.sparse( ID INT IDENTITY(1,1) PRIMARY KEY NOT NULL,
                      charval char(20) SPARSE NULL ,
                      varcharval varchar(20) SPARSE NULL,
                      intval int SPARSE NULL,
                      bigintval bigint SPARSE NULL
                      );

CREATE INDEX IX_sparse_intval_varcharval …

设置

DROP TABLE IF EXISTS #EmptyTable, #BigTable

CREATE TABLE #EmptyTable(A int);
CREATE TABLE #BigTable(A int);

INSERT INTO #BigTable
SELECT TOP 10000000 CRYPT_GEN_RANDOM(3)
FROM   sys.all_objects o1,
       sys.all_objects o2,
       sys.all_objects o3;

询问

WITH agg
     AS (SELECT DISTINCT a
         FROM   #BigTable)
SELECT *
FROM   #EmptyTable E
       INNER HASH JOIN agg B
                    ON B.A = E.A;

执行计划

问题

这是我今天之前没有注意到的现象的简化再现。我对内部散列连接的期望是，如果构建输入为空，则不应执行探测端，因为连接不会返回任何行。上面的示例与此相反，并从表中读取了 1000 万行。这使查询的执行时间增加了 2.196 秒 (99.9%)。

其他观察

1. 使用OPTION (MAXDOP 1)执行计划从#BigTable. 该ActualExecutions是0对哈希连接内所有的运营商。
2. 对于查询SELECT * FROM #EmptyTable E INNER …