小编Jos*_*ell的帖子

我试图了解 SQL Server 2016 SP3 系统上缓存元数据的一些执行计划，但我无法将我所看到的内容与文档相一致。

文档sys.dm_exec_cached_plans说它包含：

SQL Server 缓存每个查询计划的一行，以加快查询执行速度。

在我正在观察的系统上，该视图现在有 41,283 行。其中绝大多数（37,594 行）是cacheobjtype =“Compiled Plan”和objtype =“Adhoc”。

文档sys.dm_exec_query_stats说它包含：

缓存计划中每个查询语句一行，行的生命周期与计划本身相关。当从缓存中删除计划时，相应的行将从该视图中删除。

我预计此视图中至少有 37,594 行（每个缓存计划一个，如果某些缓存计划有多个语句，则可能更多）。但是，该视图总共有 6,867 行。

这种差异是如此之大，以至于我必须假设我误解了这些视图中应该包含的内容。

sys.dm_exec_query_stats有人可以帮助我理解为什么与 相比 的行数如此之少吗sys.dm_exec_cached_plans？

我尝试在 上将表内部连接在一起plan_handle，唯一的匹配是 1:1 - 换句话说，有数以万计的缓存计划，没有“查询统计”行。

我还认为差异可能是由sys.dm_exec_procedure_stats或中的许多行来解释的sys.dm_exec_trigger_stats，但事实并非如此（分别为 93 行和 2 行）。

对于任何对这个问题的“为什么”感到好奇的人，我试图查看缓存中的各种计划有多旧，并且我不确定除了加入和sys.dm_exec_query_stats检查之外还有什么方法可以做到这一点creation_time。

以下是我用来获取上面引用的数字的查询：

-- total cached plans
SELECT COUNT_BIG(*) AS total_cached_plans
FROM sys.dm_exec_cached_plans decp

-- totals by type
SELECT decp.cacheobjtype, decp.objtype, COUNT_BIG(*) AS plan_count
FROM sys.dm_exec_cached_plans …

我们最近在我们的一个存储过程中发现，通过从这里更改查询的连接语法/样式，我们获得了显着的性能改进......

SELECT b.bla, c.foo, d.bar
FROM dbo.TableB b
JOIN dbo.TableC c
    JOIN dbo.TableD d  -- <-- Nested join syntax
    ON d.yyy = c.yyy
ON c.xxx = b.xxx

对此...

SELECT b.bla, c.foo, d.bar
FROM dbo.TableB b
JOIN dbo.TableC c
ON c.xxx = b.xxx
JOIN dbo.TableD d   -- <-- Regular way
ON d.yyy = c.yyy

注意：在实际查询中，有 10 个连接表，包括内连接和外连接。就sql数据而言，这些表并不大。没有聚合。输出中有一个 DISTINCT。所有连接都指向一个主键，但外键不一定被索引。

我们肯定会改变我们的方式，但我仍然很好奇关于这种风格的正确“指导”。我经常使用“缩进”样式来表示诸如查找表之类的“更具可读性”的连接。

考虑这个表定义：

CREATE TABLE [dbo].[Post]
(
    [Id] INT IDENTITY(1,1) NOT NULL,
    [PostType] VARCHAR(10) NOT NULL,

    CONSTRAINT [CK_Post_PostType] CHECK ([PostType] IN ('Question', 'Answer', 'Comment'))
)

如果我运行它然后查看sys.check_constraints：

select [definition] 
from sys.check_constraints
where [name] = 'CK_Post_PostType';

这是输出：

([PostType]='Comment' OR [PostType]='Answer' OR [PostType]='Question')

所以它将我的“in”语句改为一系列“或”语句。

同样的事情也是如此（至少）

• BETWEEN（更改为OR语句）和
• CAST（变为CONVERT）。

我意识到这不是 SQL Server 中的功能问题，因为表达式在逻辑上是等效的。但它会导致 SSDT 等模式比较工具出现问题，因为源代码与部署的代码不同步。我在博客上更详细地介绍了这个问题：SSDT 问题：一遍又一遍地部署相同的更改

这个转换过程/行为有名称吗？是否有可能发生的不同转换的任何文档，以便我们可以为它们计划（或尝试避免它们）？

我刚刚在sp_who使用MEMORY_OPTIMIZED表的SQL Server 2016 实例上XTP_THREAD_POOL运行，我看到几个进程正在运行：

有关输出的其他一些详细信息：

• XTP_THREAD_POOL结果集中正好有 6行
• 我的系统有两个逻辑核心
  • 具体来说，它是一个带有 2 个插槽的 VM - 每个插槽都装有一个 1 核处理器
• 所有这些任务都作为后台运行（sa）

这些进程在做什么？我在 Google 上没有找到太多关于此任务名称的信息。

TIA

我有一封电子邮件失败，函数返回值为“101”，@@error 值为“0”（没有添加行sysmail_allitems）。

在哪里可以找到有关此函数返回代码的文档？

显示我如何获得上述值的示例代码：

exec @result = msdb.dbo.sp_send_dbmail
    @profile_name = 'OBFUSCATED',  
    @recipients = @DL,  
    @subject = 'OBFUSCATED',
    @body = @emailBody,
    @body_format='html',
    @query = @reportQuery,
    @exclude_query_output = 1,
    @attach_query_result_as_file = 1,
    @query_attachment_filename = @filename,
    @query_result_separator = @temp,
    @query_result_header = 1,
    @mailitem_id = @mailitem_id
    ;

    set @temp = @@ERROR;

简而言之，我想了解数据库中物理和逻辑读/写之间的区别。什么时候（哪个阈值）我应该担心它们？是这个职位的准确描述？（即使在那种情况下，我仍然有点不清楚什么可以被认为是高读取或写入）。

目前我正在做 2 级支持，我们的生产数据库所在的驱动器遇到了严重的性能问题：

我运行了Glenn Berry 的2 个诊断信息查询，以查看在总逻辑写入和平均 I/O 方面排名前 10 的存储过程，并得到以下结果：

我的任务是确定可能导致低空闲时间百分比的存储过程，以便我们的产品团队可以查看代码。

设置

3 节点 Alwayson 群集 - 1 个同步和 1 个异步辅助副本 - SQL Server 2012

情况

从异步辅助副本读取时，我们正在目睹 PageIOLatches。这主要是由于 SAN 的吞吐量受到限制造成的。托管合作伙伴告诉我们，由于硬件限制，无法立即缓解此限制。
主副本和同步副本使用具有更高吞吐量的其他 SAN。虽然这种情况远非理想，但这是一个很快就会解决的暂时情况，不是我的问题。

在调查 IO 等待时，我们注意到这些与检查点页数/秒的增加同时发生。

我的印象是检查点不会出现在 AG 中的辅助副本上，就像这里讨论的那样。

为了验证这种行为，我设置了一个扩展事件来监视异步副本上的检查点事件。正如预期的那样，没有为此数据库捕获任何检查点，也没有从其他数据库中找到与该模式匹配的任何检查点。

接下来，我在主副本上创建了相同的扩展事件，并启动了一个 perfmon 来验证我们是否可以见证相同的行为。在这里，我们能够捕获（自动）检查点，它们大约发生。每分钟一次。这些检查点与辅助（和主要）副本上检查点页数/秒的增加同时发生。似乎正在主副本上生成检查点并在辅助副本上重做。这意味着检查点确实隐式发生在 AG 中的辅助副本上。

题

我的假设是否正确，在 AG 检查点是在主副本上生成并在所有辅助副本上重做？
因此，如果TARGET_RECOVERY_TIME未设置数据库，recovery interval主副本的设置将规定这些数据库的所有辅助副本上的检查点。

我将 SQLPackage.exe 与数据库发布配置文件结合使用，将数据库更改部署到 DEV 和 QC 实例。我的数据库处于简单恢复模式。但是当我使用 SQLPackage 部署更改时，它将它们恢复为完全恢复模式。

这就是我正在使用的，

"C:\Program Files (x86)\Microsoft SQL Server\110\DAC\bin\SqlPackage.exe" /Action:Publish /SourceFile:"FILE PATH TO .DACPAC" /Profile:"PUBLISH PROFILE.XML"

如果我使用 Visual Studio 使用相同的发布项目来部署项目更改，则会发生同样的情况。

我在这里缺少什么？据我所知，Profile 中没有这样的标志。这是 SQLPackage 的预期行为吗？

我正在使用以下查询来获取过滤器中所有行的字段数量的总和：

SELECT SUM(Amount)
FROM dbo.[CompanyName$Detailed Cust_ Ledg_ Entry]
WHERE [Customer No_] = 'XYZ'

结果是

这个结果不等于行的总和

SELECT [Customer No_], Amount
FROM dbo.[CompanyName$Detailed Cust_ Ledg_ Entry]
WHERE [Customer No_] = 'XYZ'

行的结果是：

计算行的等位基因数量时，结果为：-29,59 而不是 -59,18

有人可以解释这种行为吗？

SP_Helpindex 输出：

查询计划：

XML 查询计划

<?xml version="1.0" encoding="utf-16"?>
<ShowPlanXML xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" Version="1.481" Build="14.0.3045.24" xmlns="http://schemas.microsoft.com/sqlserver/2004/07/showplan">
  <BatchSequence>
    <Batch>
      <Statements>
        <StmtSimple StatementCompId="1" StatementEstRows="9.00002" StatementId="2" StatementOptmLevel="FULL" StatementOptmEarlyAbortReason="GoodEnoughPlanFound" CardinalityEstimationModelVersion="140" StatementSubTreeCost="0.029753" StatementText="SELECT 'XYZ' [Customer No_],[Amount] FROM [dbo].[CompanyName$Detailed Cust_ Ledg_ Entry] WHERE [Customer No_]=@1" StatementType="SELECT" QueryHash="0x97A8CCC9F15EC998" QueryPlanHash="0x7502550BCACA55B0" RetrievedFromCache="false" SecurityPolicyApplied="false">
          <StatementSetOptions …

我有一个包含 unix 时间日期和一个单独的毫秒字段的表。我现在尝试从两个字段中创建一个日期以供以后计算（例如过滤时间范围）。将毫秒添加到通过...创建的日期后

 dateadd(S, [timestamp_s], '1970-01-01')

通过添加另一个DATEADD...

dateadd(MS, [timestamp_ms], dateadd(S, [timestamp_s], '1970-01-01')) eventdate

...然后输出日期毫秒有时关闭一毫秒。出于好奇，我然后尝试提取毫秒，看看这给出了什么，然后又减少了 1 毫秒。

我认为这与内部浮点精度有关，但我在数据中看不到任何规则。有时每个操作都会减少 1 毫秒，有时第一个会减 1，但 DATEPART 然后会再次加 1，等等。

由于这可能会导致某些用户感到沮丧，因此我想了解这种行为并在理想情况下找到问题的解决方案。提前致谢。