小编use*_*827的帖子

我如何在生产框中检查我的 SQL 服务器的内存使用情况。我正在使用 SQL Server 2016。当我检查任务管理器时，它显示在 90% 以上。我不认为这是 sql server 的真实内存使用情况。

我有一个 SQL 性能工具 grafana，它显示的 CPU 使用率比我在任务管理器中看到的少得多。我检查了资源监视器，可以看到平均 CPU 值。我对 SQL 服务器内存使用情况感到困惑。我正在尝试确定内存压力是否是我的某些问题的一个问题。

有人可以直接给出一个好的/正确的解释。

我的一个查询在发布后以串行执行模式运行，我注意到在从应用程序生成的 LINQ to SQL 查询中引用的视图中使用了两个新函数。所以我将这些 SCALAR 函数转换为 TVF 函数，但查询仍然以串行模式运行。

早些时候我在其他一些查询中做了 Scalar 到 TVF 的转换，它解决了强制串行执行的问题。

这是标量函数：

CREATE FUNCTION [dbo].[FindEventReviewDueDate]
(
       @EventNumber VARCHAR(20),
       @EventID VARCHAR(25),
          @EventIDDate BIT
)

RETURNS DateTime
AS
BEGIN

DECLARE @CurrentEventStatus VARCHAR(20)
DECLARE @EventDateTime DateTime
DECLARE @ReviewDueDate DateTime


SELECT @CurrentEventStatus = (SELECT cis.EventStatus
                                 FROM CurrentEventStatus cis 
                                 INNER JOIN Event1 r WITH (NOLOCK) ON (cis.Event1Id = r.Id)
                                 WHERE (r.EventNumber = @EventNumber) AND r.EventID = @EventID)

SELECT @EventDateTime = (SELECT EventDateTime FROM Event1 r 
                          WHERE (r.EventNumber = @EventNumber) AND r.EventID = …

我有一个禁用了页面级锁定的索引，现在我有该索引的索引碎片问题。

我知道我将无法Reorganize建立索引，但我相信我能够建立rebuild索引。

现在我认为重建也不起作用。我使用的默认填充因子为 100。我的数据库很大，所以我不希望通过将填充因子设置为 80% 或更少来增加表/数据库的大小。不工作是指在前一天晚上运行 Ola 的脚本后，平均碎片保持不变。

关于为什么禁用页面级锁定的一点背景。

我deadlocks在那个特定表中的这个索引上得到了很多交易。这张表是一种insert, update and delete每时每刻都在发生的事实表。并且与foreign key其他几个表有一些关系CASCADE deletes。所以，我遇到了很多锁/死锁，在禁用页面级锁之后，我能够摆脱所有这些死锁。

我开始使用 Ola Hallengren 的脚本，Index maintenance并对所有索引重组不起作用的索引应用了索引重建。但我注意到索引重建也不起作用。

现在，我看到索引的 AvgPageFragmentaiton 为 95.9413，页面计数为 1196826，这并不好。

附加信息：

我正在使用 Ola Hall 的脚本，如下所示。

 EXECUTE dbo.IndexOptimize
    @Databases = 'DB_NAME',
    @FragmentationLow = NULL,
    @FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE',
    @FragmentationHigh = ''INDEX_REORGANIZE,INDEX_REBUILD_ONLINE'',
    @FragmentationLevel1 = 5,
    @FragmentationLevel2 = 30,
    @SortInTempdb = 'Y',
    @MaxDOP = 0,
    @WaitAtLowPriorityMaxDuration = 0,
    @WaitAtLowPriorityAbortAfterWait= 'NONE',
    @Indexes = 'DB_NAME.[dbo].TB1,DB_NAME.[dbo].TB2' …

我创建了一个 sql 作业来查询计划缓存并单独获取串行计划，然后从计划缓存中清除它。作为 SQL 作业中第 1 步的一部分，我仅过滤串行计划并将其插入到我创建的表中。当我运行作业时，在第 1 步本身中，我收到以下错误；

INSERT failed because the following SET options have incorrect settings: 'QUOTED_IDENTIFIER'. Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or filtered indexes and/or query notifications and/or XML data type methods and/or spatial index operations. [SQLSTATE 42000] (Error 1934).  The step failed.

我做了研究并了解到这可能是由于 SET 选项。所以我检查了我创建的表，它是用

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

我看到有人有同样问题的帖子，并在将上述 SET 选项更改为 ON 后解决了它。我已经有了这个 SET，但仍然是同样的错误。我不知道为什么我会收到这个错误。

我在获取串行计划的查询中有这一行。

WITH XMLNAMESPACES ( 'http://schemas.microsoft.com/sqlserver/2004/07/showplan' …

我有一个来自分发数据库的 .mdf 文件，该文件正在增长。我知道缩小数据库/文件的优缺点。将 .mdf 文件缩小到更小的尺寸是否可以。在此期间是否有任何数据丢失，这是否会影响复制。？

我有一个从 .net 应用程序生成的查询，参数是 linq 参数。我用来调整查询的过程如下。

• 我运行应用程序并使用探查器捕获查询。

• 查询的形式是

  exec sp_executesql N'SELECT 
  [Extent1].[Id] AS [Id], 
  [Extent1].[GroupId] AS [GroupId], 
  [Extent1].[Agency] AS [Agency], 
  [Extent1].[Group] AS [Group], 
  [Extent1].[Claim] AS [Claim], 
  [Extent1].[StartDate] AS [StartDate], 
  [Extent1].[ExpireDate] AS [ExpireDate], 
  [Extent1].[IsActive] AS [IsActive]
  FROM [dbo].[Permissions] AS [Extent1]
  WHERE ([Extent1].[GroupId] = @p__linq__0) AND (([Extent1].[ExpireDate] IS NULL)
  OR ([Extent1].[ExpireDate] > @p__linq__1)) AND ([Extent1].[IsActive] <> 1)',
  N'@p__linq__0 int,@p__linq__1 datetime2(7)',
  @p__linq__0=15,@p__linq__1='2017-05-10 00:00:00'
  

  Run Code Online (Sandbox Code Playgroud)

这只是一个示例查询。实际查询要大得多，并且包括许多涉及多个视图和表等的连接。

我的问题是：

• 按原样运行查询时，执行时间约为 15 秒
• 当我单独取出查询sp_executesql并将过滤器值应用于查询时，它会在不到 1 秒的时间内运行。

我知道由于这些值是硬编码到查询中的，所以它会更快，但为什么执行时间会有这么大的差异？两者的执行计划也不同：

带有 sp_executesql 的 SQL 执行计划

使用硬编码 SQL 的执行计划

我是在这台服务器上工作的唯一用户，我在两种情况下都执行相同的参数。我已经申请OPTION(RECOMPILE) …

问题：

我有几个查询需要大量内存授权（~7GB）。这些查询经常运行，这导致其他查询等待内存。所以我看到 RESOURCE_SEMAPHORE 等待类型。服务器信息：

1. Microsoft SQL Server 2016 (SP2) (KB4052908) - Windows Server 2016 Standard 10.0（内部版本 14393：）上的 13.0.5026.0 (X64)
2. 128 GB 内存
3. 96 GB 作为最大服务器内存
4. 数据库大小为 1.6 TB
5. 启用事务复制
6. 查询存储已禁用

我知道我已经发布了有关此服务器性能的类似问题。我试图从不同的角度看待事物或尝试以不同的方式解决问题。正如这篇文章中提到的，我有某种内存压力。现在我正在尝试修复查询中的问题或摆脱这个巨大的内存授权。

这是帖子中提到的查询的计划。

执行计划

我了解到这SORT,HASH JOIN,EXCHANGE(parallel Distribute Stream and Parallel Re partition stream and Parallel Gather Stream)是消耗内存的迭代器，我在我的执行计划中看到了这些。

我怎样才能从这个查询中减少这个巨大的内存授权。？甚至我也很困惑内存压力是否是由于大量查询授予的巨大内存造成的。？

这是我使用 SQLServer 探查器捕获查询时的实际查询。

exec sp_executesql N'SELECT TOP (@p__linq__6) 
    [PJ2].[FormId] AS [FormId], 
    [PJ2].[TNUMId] AS [TNUMId], 
    [PJ2].[TNUMDateTime] AS [TNUMDateTime], 
    [PJ2].[TNUMEventNumber] AS [TNUMEventNumber], 
    [PJ2].[EventNumber] AS [EventNumber], 
    [PJ2].[SubUnit] AS [SubUnit], 
    [PJ2].[EventClass] AS [EventClass], …

我的数据库很大，最近我注意到几个月前添加的新表是罪魁祸首。

这是表脚本。

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[Entry_tracker](
    [S.Number] [int] IDENTITY(1,1) NOT NULL,
    [EntryId] [varchar](50) NOT NULL,
    [EventNumber] [varchar](18) NOT NULL,
    [Data] [varbinary](max) NOT NULL,
    [TrackDateTime] [datetime] NOT NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

ALTER TABLE [dbo].[Entry_tracker] ADD  CONSTRAINT [DF_Entry_tracker_TrackDateTime]  DEFAULT (getdate()) FOR [TrackDateTime]
GO

我收集了这张表的信息，了解到该表大约有1600万行，表大小为1.4TB。

尽管如此，我认为桌子的大小对于没有。的记录。

应用程序不查询该表。它只是存储来自另一个表的相同条目的不同版本。

我检查了碎片信息，它显示平均碎片为 0，平均空间使用率为 93%。

由于我使用的是 SQL Server 2016，我虽然可以使用表压缩，因此尝试sp_estimate_data_compression_savings估计可能的空间节省。但是，结果显示没有节省。

size_with_current_compression_setting(KB) 等于 size_with_requested_compression_setting(KB)

任何人都可以指导我找到这张表的问题吗？

这非常重要，因为这会占用大量磁盘空间。

感谢你的帮助。

CXCONSUMER当我运行时，我有一些等待时间的查询，sp_whoisactive如下面的屏幕截图所示。

当我检查状态时，它是suspended。这意味着它正在等待某个进程释放资源。据我所知CXPACKET，生产者CXCONSUMER是消费者，而 CXPACKET 是罪魁祸首，应该对此采取行动。但我不”没有看到任何CXPACKET。由于这是一个并行执行，我不确定应该从哪里开始修复。

任何人都可以建议我如何找出我的查询正在等待的过程（因为我将挂起视为状态）？

附加信息

当我查询时sys.dm_os_wait_stats，前两个条目是 CONSUMER 和 CXPACKETS。

• SQL Server 2016
• 128 GB 内存
• 最大 DOP : 8
• 门槛成本：20

我有一个查询，它与 8 的 MAXDOP 并行运行。当我查看时，sp_who2我看到相同的会话 ID 使用不同的连接 ID 重复多次（> 8）。

我使用了下面的查询，看到等待类型仍然是 CXCONSUMER 等待类型。但我看到 130 个不同的 exec_context id。

SELECT 
    dot.session_id,
    dot.exec_context_id,
    dot.task_state,
    dowt.wait_type,
    dowt.wait_duration_ms,
    dowt.blocking_session_id,
    dowt.resource_description
FROM sys.dm_os_tasks dot
    LEFT JOIN sys.dm_os_waiting_tasks dowt
        ON  dowt.exec_context_id = dot.exec_context_id
            AND dowt.session_id = dot.session_id
WHERE dot.session_id = 96
ORDER BY exec_context_id;

如果查询并行运行，当我将负载分配到不同的工作线程时，它是否具有不同的 spid。？

看了肯德拉·利特尔 (Kendra Little) 的文章。非常有帮助的一个。

我使用查询来查看并行处理查询中使用的不同调度程序。

我看到多次使用相同的shcheduler_id/worker地址。这正常吗？

我的 MAXDOP 也是 4，但我看到 5 个不同的 scheduler_ids，这很奇怪。