标签: sql-server-2012

在过去的一个月里，我的一台服务器遇到了 SQL Server 代理问题。它会自动停止并出现以下错误，这是随机发生的：

Sql 代理输出文件
[097] 检测到内存泄漏 [204 字节]
在文件 e:\sql9_sp2_t\sql\komodo\src\core\sqlagent\src\alerter.cpp 的第 403 行捕获到异常 5。SQLServerAgent 启动自我终止

我用谷歌搜索了这个错误，但没有得到太多关于它的信息。SQL Server 和代理都使用相同的域帐户运行；但是，问题仅与 SQL Server 代理服务有关。

我也无法在 SQL Server 配置管理器中看到 SQL Server 代理服务。我检查了 SQL Server 错误日志和 Windows 事件查看器日志，但没有看到任何可疑活动。

我的内存设置配置正确。服务器有 32GB RAM，SQL Server 被分配使用 26GB 的最大内存。

系统详情：

• SQL Server 2012 SP2 标准版 11.0.5058 64 位
• Windows Server 2008 R2 Ent Edition 64 位
• 专用于 SQL Server（服务器上没有运行其他应用程序）
• 服务器几个月前从 SQL Server 2005 EE 升级到 2012 SE。
• 我们没有使用事件转发服务器。

我也检查了msdb数据库。运行 checkdb 并成功完成，没有任何错误。我需要你的帮助来解决两件事：

1. 修复 SQL …

我需要优化一个SELECT语句，但 SQL Server 总是执行索引扫描而不是查找。这是查询，当然，在存储过程中：

CREATE PROCEDURE dbo.something
  @Status INT = NULL,
  @IsUserGotAnActiveDirectoryUser BIT = NULL    
AS

    SELECT [IdNumber], [Code], [Status], [Sex], 
           [FirstName], [LastName], [Profession], 
           [BirthDate], [HireDate], [ActiveDirectoryUser]
    FROM Employee
    WHERE (@Status IS NULL OR [Status] = @Status)
    AND 
    (
      @IsUserGotAnActiveDirectoryUser IS NULL 
      OR 
      (
        @IsUserGotAnActiveDirectoryUser IS NOT NULL AND       
        (
          @IsUserGotAnActiveDirectoryUser = 1 AND ActiveDirectoryUser <> ''
        )
        OR
        (
          @IsUserGotAnActiveDirectoryUser = 0 AND ActiveDirectoryUser = ''
        )
      )
    )

这是索引：

CREATE INDEX not_relevent ON dbo.Employee
(
    [Status] …

我需要在完成之前从存储过程返回部分结果（作为简单的选择）。

有可能这样做吗？

如果是，如何做到这一点？

如果没有，有什么解决方法吗？

编辑：我有几个部分的程序。在第一部分我计算了几个字符串。我稍后会在过程中使用它们来进行附加操作。问题是调用者尽快需要字符串。因此，我需要计算该字符串并将其传回（不知何故，例如从选择中），然后继续工作。调用者更快地获得其有价值的字符串。

调用者是一个 Web 服务。

TRUSTWORTHY如果您不小心，该设置可能会相当危险，除特定情况外，建议将其关闭。但是默认情况下，MSDB数据库TRUSTWORHTY设置ON默认。我很好奇为什么？

我已阅读BOL 中的此条目

注意默认情况下，MSDB 数据库的 TRUSTWORTHY 设置设置为 ON。更改此设置的默认值可能会导致使用 M​​SDB 数据库的 SQL Server 组件出现意外行为。

但我对具体情况很好奇。为什么具体MSDB需要TRUSTWORTHY开启？什么功能使用它？

由于我的性能调优技巧似乎永远不够用，我总是想知道我是否可以针对某些查询执行更多优化。此问题涉及的情况是嵌套在子查询中的 Windowed MAX 函数。

我正在挖掘的数据是对不同组较大集的一系列事务。我有 4 个重要的字段，交易的唯一 ID，一批交易的组 ID，以及与各自唯一交易或交易组相关的日期。大多数情况下，集团日期与批次的最大唯一交易日期相匹配，但有时会通过我们的系统进行手动调整，并在捕获集团交易日期后进行唯一日期操作。此手动编辑不会按设计调整组日期。

我在此查询中确定的是唯一日期落在组日期之后的那些记录。以下示例查询构建了与我的场景大致相当的内容，SELECT 语句返回我正在查找的记录，但是，我是否以最有效的方式接近此解决方案？这需要一段时间才能在我的事实表加载期间运行，因为我的记录计数在前 9 位数字中，但主要是我对子查询的蔑视让我想知道这里是否有更好的方法。我并不关心任何索引，因为我相信它们已经到位；我正在寻找的是一种替代查询方法，它可以实现相同的目标，但效率更高。欢迎任何反馈。

CREATE TABLE #Example
(
    UniqueID INT IDENTITY(1,1)
  , GroupID INT
  , GroupDate DATETIME
  , UniqueDate DATETIME
)

CREATE CLUSTERED INDEX [CX_1] ON [#Example]
(
    [UniqueID] ASC
)


SET NOCOUNT ON

--Populate some test data
DECLARE @i INT = 0, @j INT = 5, @UniqueDate DATETIME, @GroupDate DATETIME

WHILE @i < 10000
BEGIN

    IF((@i + @j)%173 = 0)
    BEGIN
        SET @UniqueDate = GETDATE()+@i+5
    END
    ELSE
    BEGIN …

我的 SQL Server 数据库的性能有问题。我找到了这个工具sp_BlitzCache。命令执行后，我得到了这个语句：

您在过去 24 小时内创建了 92.00% 的计划，在过去 4 小时内创建了 92.00%。

虽然我发现了问题（使用 SQL Server Profiler，我检查了 StmtRecompile 事件发生），但我只能找到几个经常重建的全文搜索查询。但是，全文搜索查询仅占所有查询的 5% 左右。

您有什么建议可能会导致其余 87% 的计划重新创建？

我有 SQL Server 2012（版本 11.0.6567.0）。

编辑：我添加了我的性能计数器

+---------------------------+--------------------------------+--------------+
|        object_name        |          counter_name          |  cntr_value  |
+---------------------------+--------------------------------+--------------+
| SQLServer:Buffer Manager  | Background writer pages/sec    |            0 |
| SQLServer:Buffer Manager  | Buffer cache hit ratio         |        28436 |
| SQLServer:Buffer Manager  | Buffer cache hit ratio base    |        28436 |
| SQLServer:Buffer Manager  | Checkpoint pages/sec           | …

我们正在使用 SQL Server 2012 运行 Dynamics AX 2012 安装。我知道不应再使用游标，但 AX 正在使用它，我们无法更改此行为，因此我们必须使用它。

今天我发现了一个非常糟糕的查询，读取次数超过 5300 万次，执行时间超过 20 分钟。

我通过我们的监控工具 SentryOne 捕获了这个查询。

declare @p1 int
set @p1=1073773227
declare @p2 int
set @p2=180158805
declare @p5 int
set @p5=16
declare @p6 int
set @p6=1
declare @p7 int
set @p7=2
exec sp_cursorprepexec @p1 output,@p2 output,N'@P1 bigint,@P2 nvarchar(5),@P3 bigint,@P4 nvarchar(8),@P5 bigint,@P6 bigint,@P7 bigint,@P8 bigint,@P9 bigint,@P10 bigint,@P11 bigint,@P12 bigint,@P13 bigint,@P14 bigint,@P15 bigint,@P16 bigint,@P17 bigint,@P18 bigint,@P19 nvarchar(5),@P20 bigint,@P21 bigint,@P22 bigint,@P23 bigint,@P24 bigint',N'SELECT T1.PRODUCT,T1.EXTERNALVENDPARTY,T1.LIFECYCLESTATUS,T1.RECID,T2.ECORESPRODUCT,T2.ECORESDISTINCTPRODUCTVARIANT,T2.SGE,T2.ECORESREFORDERNUM,T2.ORDERNUM,T2.RECID,T3.ECORESREFORDERNUM,T3.NAME1,T3.NAME2,T3.NAME3,T3.RECID,T4.ECORESPRODUCT,T4.EXTERNALITEMID,T4.ECORESDISTINCTPRODUCTVARIANT,T4.RECID,T5.RECID,T5.PERSON,T6.RECID,T6.NAME,T6.INSTANCERELATIONTYPE,T7.RECID,T7.NAME,T7.INSTANCERELATIONTYPE,T8.PARTY,T8.ACCOUNTNUM,T8.RECID,T9.RECID,T9.DISPLAYPRODUCTNUMBER,T9.INSTANCERELATIONTYPE,T10.PRODUCT,T10.CATEGORY,T10.RECID,T11.RECID,T11.CODE,T11.NAME,T11.INSTANCERELATIONTYPE FROM INVENTTABLE T1 CROSS JOIN ECORESPRODUCTORDERNUM …

当我们从旧的全闪存阵列迁移到新的全闪存阵列（不同但成熟的供应商）时，我们开始看到检查点期间 SQL Sentry 中的等待增加。

版本：SQL Server 2012 Sp4

在我们的旧存储上，我们的等待时间约为 2k，在检查点期间“峰值”达到 2500，而新存储的峰值通常为 10k，峰值接近 50k。Sentry 将我们更多地指向PAGEIOLATCHwatis。做我们自己的分析，这似乎是PAGEIOLATCH and PAGELATCH等待的组合。使用 Perfmon，我们通常可以说我们检查点的页面越多，我们得到的等待就越多，但我们在检查点期间只刷新了大约 125 mb。我们的工作量主要是写入（主要是插入/更新）。

存储供应商已向我们证明，在这些检查点事件期间，光纤通道直连阵列的响应时间不到 1 毫秒。HBA 还会确认阵列的编号。我们也不认为这是 HBA 队列问题，因为队列深度从未超过 8。我们还尝试了更新的 HBA，更改 ZIO、执行限制和队列深度设置无济于事。我们还将服务器的内存从 500 GB 增加到 1 TB，没有任何变化。在检查点过程中，我们确实看到 2 - 4 个独立内核（共 16 个）飙升至 100%，但整体 CPU 约为 20%。BIOS 也设置为高性能。有趣的是，我们确实看到 CPU 通常处于 C2 睡眠状态，即使我们已经禁用了它，所以我们仍在研究为什么睡眠状态会超过 C1。

我们可以看到几乎所有的等待都在数据页上，偶尔会有 DCM 页面类型的 PFS。等待在用户数据库中，而不是 tempdb。我们还看到等待跨越多个数据页，一些 SPID 在同一页上等待。数据库设计确实有几个插入热点，但旧存储采用了相同的设计。

运行这个查询的循环 100 次，我们能够捕捉到有多少 SPID 在磁盘与内存上等待

SELECT
    [owt].[wait_type], count(*) as waitcount
FROM sys.dm_os_waiting_tasks [owt]
WHERE [owt].[wait_type] LIKE 'PAGE%'
group by [owt].[wait_type] …

我们的团队继承了一个应用程序和相关的数据库。以前的开发人员似乎强制执行了一个规则，即每个表上的每个索引都有一个 INCLUDE 子句，以始终添加不属于键的每一列。这些表平均有两到五个索引或唯一约束以及外键。

目的似乎是提高 SELECT 性能，无论向数据库抛出什么查询，因为访问是通过 ORM 进行的，默认情况下（但并非总是）检索所有列。我们预计这样做的副作用是增加了存储需求（可能显着增加）和 INSERT/UPDATE/DELETE 的额外开销时间。

问题是，这是一个明智的策略吗？我们的团队有使用 SQL Server 的历史，但没有成员认为自己是其内部行为的专家（尽管有人提出问题，如果这种策略是最佳的，现在不是默认吗？）。我们应该期待哪些其他副作用（数据库服务器 CPU/内存/TempDB 使用等），或者我们上面的一些假设是不正确的？

此外，该应用程序可以安装到本地 SQL Server（自 2012 年以来的版本）以及 Azure SQL 中——我们是否应该为两者之间的任何差异做好准备，或者因此对 Azure 产生额外的副作用方法？

我有一个运行多个数据库的 SQL2012 SP4 节点。

服务器有 20GB 可用内存，14GB 分配给 SQL（盒子上没有其他东西在运行）。

每隔几分钟，SQL 就会转储整个缓冲区缓存。页面预期寿命为零，缓冲区缓存描述符显示缓存中没有任何内容。

我查看了资源监视器通知，通知每隔几毫秒从高/稳定/低反弹：

RESOURCE_MEMPHYSICAL_HIGH RESOURCE_MEM_STEADY RESOURCE_MEMPHYSICAL_LOW

时间戳相隔几毫秒。PLE 本质上是一种锯齿图案。

我以前在 SQL2012 SP1 和这个问题中看到过这种情况：

未使用缓冲区缓存中的 SQL Server 2012 空闲页

似乎是一个类似的问题，虽然我已经更新到 SP4。

我试过为服务帐户打开 LPIM，我试过搞乱最大内存设置。降低最大内存似乎导致缓冲区缓存更频繁地清空。

关于下一步要检查什么的任何想法？

服务器工作负载实际上什么都没有（我正在浏览 ERP 系统中的项目列表，在缓存再次下降之前它达到了大约 40-50MB）。

这很有趣，因为我从 SP1 升级来尝试解决这个问题 - 那里的缓存达到了大约 500MB。从那以后，我将最大内存设置降低到 14GB，这似乎使情况变得更糟。

我想知道 Windows 是否会恐慌并在 SQL 处抛出错误的内存压力通知 - 因此将最大内存设置为无界的服务器似乎运行正常，但从未填充超过几百 MB 的缓存 - 但现在它勉强达到50...

更多信息：对于那些问

核心数： 4

数据库大小： 80GB

错误日志显示： A significant part of sql server process memory has been paged out. This may result in a performance degradation. Duration: 0 …