John Eisbrener's questions

我正在运行支持供应商软件的最新补丁/CU 级别的本地 SQL Server 2017 Enterprise，这将在稍后变得重要。

服务器统计：

• 虚拟机（内存已固定）
• Windows Server 2016 数据中心
• 16 个虚拟 CPU
• 192 GB RAM（179 GB 分配给 SQL Server）
• 30 GB 页面文件（我宁愿这个不存在，但这不是我赢得的战斗）
• 托管 5 个用户数据库，其中 1 个大小约为 4TB
• 供应商要求的服务器默认值为 1max degree of parallelism

如上所述，该系统支持流行的供应商平台，虽然供应商在自定义索引或其他透明数据模型调整方面做得很好，但他们往往不赞成需要调整其应用程序代码的功能更改（原因很明显，因为这会影响成千上万的客户）。

我遇到的情况是这个供应商应用程序运行长时间运行的row mode查询，这些查询将在其应用程序代码中逐项处理的项目列表排队。如果我们允许这些查询可以（并且确实）运行数天甚至数周（ASYNC_NETWORK_IO如预期的那样显示等待）。当这些查询被启动时，他们请求的数量与他们真正需要SerialDesiredMemory的数量相比是巨大的。SerialRequiredMemory结果是MEMORYCLERK_SQLQERESERVATIONS内存管理员中的请求/授予的内存远远超过了使用的内存。例如：

-- What amount of query execution memory is asked for and used
SELECT    SUM(granted_memory_kb) / 1024 AS granted_memory_mb
        , SUM(requested_memory_kb) / 1024 AS requested_memory_mb
        , SUM(used_memory_kb) / 1024 AS used_memory_mb
        , (SUM(granted_memory_kb) - SUM(used_memory_kb)) / 1024 AS excess_memory_grant_mb
FROM    sys.dm_exec_query_memory_grants
OPTION (RECOMPILE)

回报：

这绝对是可怕的，这是在启用资源池RESOURCE GOVERNOR并将REQUEST_MAX_MEMORY_GRANT_PERCENT这些查询降至% 之后，尽管根据我所看到5的情况，我可能会一直将其降低到SQL 2017 的最小值。1

REQUEST_MAX_MEMORY_GRANT_PERCENT我的问题是，当我被困在 SQL 2017 时，除了进一步将资源池的价值降低到1%之外，我还能做些什么来限制查询执行计划中浪费的 RAM 数量？

由于这是一个供应商应用程序，因此查询计划指南可能是一种选择，但调整MAX_GRANT_PERCENT并没有给我带来任何好处，而不仅仅是调整REQUEST_MAX_MEMORY_GRANT_PERCENT资源池中的值。我可以在计划指南中做些什么来强制batch mode执行，希望这会触发 SQL 2017 中提供的批处理模式内存反馈功能？同样，由于这是我正在使用的供应商应用程序代码，因此我无法更改查询，因此标准的汤姆愚弄方法可能在这里不起作用。

升级到 SQL 2019（或者最好是 SQL 2022）是显而易见的答案，因为它使我可以访问在这种情况下可以使用的许多功能，例如行模式内存反馈和浮点值REQUEST_MAX_MEMORY_GRANT_PERCENT，但是还有其他可用的选项吗使用 SQL 2017 我还没有接触过？如果没有，那很好，我只是想用尽我还没有想到的任何出色的选择。

我目前正在一个需要我们在企业范围内启用SQL Server Audit的环境中工作。我们生成.sqlaudit文件，因为我们有保留和访问指南，我发现我们需要编译有关生成的文件的趋势信息，例如每小时创建的数量、审计信息的总量等。目前，我只知道提供审计定义信息的 DMV/DMF 的数量（可以在此处找到列表），但与 SQL Server 审计过程的输出无关。

我目前正在运行 PowerShell 脚本来从.sqlaudit文件的元数据中收集这些信息，但如果可能的话，我不希望依赖外部进程。我研究了扩展存储过程，例如xp_dirtree，但它只返回文件数而不是大小信息，所以它没有提供我需要的完整图片。 xp_cmdshell，虽然可行，但出于明显的安全原因是不允许的，因为NIST 合规性明确禁止其使用。数据库引擎中是否有任何方法（我问的是我可以用 TSQL 解决的问题）我可以获得这些信息，例如我还没有遇到的扩展事件或隐藏的 DMV？我觉得我已经进行了一些广泛的挖掘，但如果我错过了什么，我从不感到惊讶。

我有一个 4 节点 AG 设置，如下所示：

所有节点的VM硬件配置：

• Microsoft SQL Server 2017 企业版 (RTM-CU14) (KB4484710)
• 16 个 vCPU
• 356 GB RAM（长篇大论……）
• 最大并行度：1（根据应用供应商的要求）
• 并行性的成本阈值：50
• 最大服务器内存 (MB)：338944 (331 GB)

AG 配置：

• 节点 1：主节点或同步提交不可读辅助节点，配置为自动故障转移
• 节点 2：主节点或同步提交不可读辅助节点，配置为自动故障转移
• 节点 3：具有异步提交的可读辅助集，配置为手动故障转移
• 节点 4：具有异步提交的可读辅助集，配置为手动故障转移

有问题的查询：

这个查询并没有什么特别疯狂的地方，它提供了应用程序中各个队列中未完成工作项的摘要。您可以从下面的执行计划链接之一查看代码。

主节点上的执行行为：

在 Primary 节点上执行时，执行时间一般在 1 秒左右。这是执行计划，下面是从主节点的 STATISTICS IO 和 STATISTICS TIME 捕获的统计信息：

(347 rows affected)
Table 'Worktable'. Scan count 647, logical reads 2491, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'workitemlc'. Scan count 300, logical reads 7125, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Workfile'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'schedulertask'. Scan count 1, logical reads 29, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'wfschedulertask'. Scan count 1, logical reads 9, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'schedulerservice'. Scan count 1, logical reads 12, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'schedulerworkerpool'. Scan count 1, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'itemlc'. Scan count 1, logical reads 26372, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(1 row affected)

 SQL Server Execution Times:
   CPU time = 500 ms,  elapsed time = 656 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

只读辅助节点上的执行行为：

在任一只读辅助节点（即节点 3 或节点 4）上执行时，此查询使用相同的执行计划（这是不同的计划链接）并显示大致相同的执行统计信息（例如，可能还有更多页面扫描，因为这些结果总是在变化），但除了 CPU 时间之外，它们看起来非常相似。以下是从只读辅助节点的 STATISTICS IO 和 STATISTICS TIME 捕获的统计信息：

(347 rows affected)
Table 'Worktable'. Scan count 647, logical reads 2491, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'workitemlc'. Scan count 300, logical reads 7125, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Workfile'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'schedulertask'. Scan count 1, logical reads 29, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'wfschedulertask'. Scan count 1, logical reads 9, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'schedulerservice'. Scan count 1, logical reads 12, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'schedulerworkerpool'. Scan count 1, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'itemlc'. Scan count 1, logical reads 26372, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(1 row affected)

 SQL Server Execution Times:
   CPU time = 55719 ms,  elapsed time = 56335 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

其他详情：

在执行此查询时，我还在辅助服务器上同时运行了sp_WhoIsActivePaul Randal 的WaitingTasks.sql脚本，但我没有看到任何等待发生的情况，坦率地说，这令人沮丧：

这看起来也不是 AG 延迟的情况，因为 Synchronization 状态实际上非常好：

--https://sqlperformance.com/2015/08/monitoring/availability-group-replica-sync

SELECT 
       ar.replica_server_name, 
       adc.database_name, 
       ag.name AS ag_name, 
       drs.is_local, 
       drs.synchronization_state_desc, 
       drs.synchronization_health_desc, 
       --drs.last_hardened_lsn, 
       --drs.last_hardened_time, 
       drs.last_redone_time, 
       drs.redo_queue_size, 
       drs.redo_rate, 
       (drs.redo_queue_size / drs.redo_rate) / 60.0 AS est_redo_completion_time_min,
       drs.last_commit_lsn, 
       drs.last_commit_time
FROM sys.dm_hadr_database_replica_states AS drs
INNER JOIN sys.availability_databases_cluster AS adc 
       ON drs.group_id = adc.group_id AND 
       drs.group_database_id = adc.group_database_id
INNER JOIN sys.availability_groups AS ag
       ON ag.group_id = drs.group_id
INNER JOIN sys.availability_replicas AS ar 
       ON drs.group_id = ar.group_id AND 
       drs.replica_id = ar.replica_id
ORDER BY 
       ag.name, 
       ar.replica_server_name, 
       adc.database_name;

这个查询似乎是最严重的违规者。在主节点上也需要亚秒级时间的其他查询在辅助节点上可能需要 1 到 5 秒，虽然行为不那么严重，但它看起来确实会导致问题。

最后，我还查看了服务器并检查了外部进程，例如 A/V 扫描、产生意外 I/O 的外部作业等，但都空手而归。我不认为这是由 SQL Server 进程之外的任何东西引起的。

问题：

我现在才中午，而且已经是漫长的一天，所以我怀疑我在这里遗漏了一些明显的东西。要么是这样，要么我们有一些错误配置，这是可能的，因为我们已经多次调用与此环境相关的供应商和 MS。

对于我所有的调查，我似乎无法找到导致这种性能差异的原因。我希望在辅助节点上看到某种等待，但什么也没有。如何进一步解决此问题以确定根本原因？有没有人见过这种行为并找到解决方法？

更新 #1 在将第三个节点（只读副本之一）的状态交换为不可读，然后作为测试返回为可读后，该副本仍被打开的事务占用，任何客户端查询都显示HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING等待。

运行DBCC OPENTRAN命令会产生以下结果：

Oldest active transaction:
    SPID (server process ID): 420s
    UID (user ID) : -1
    Name          : QDS nested transaction
    LSN           : (941189:33148:8)
    Start time    : May  7 2019 12:54:06:753PM
    SID           : 0x0
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

在 中查找此 SPID 时sp_who2，它会将其显示为一个BACKGROUND进程，QUERY STORE BACK并以命令的形式列出。

虽然我们能够进行 TLog 备份，但我怀疑我们遇到了这个已解决错误的类似功能，所以我计划今天就这个特定问题向 MS 开一张票。

根据该票的结果，我将尝试根据 Joe 的建议捕获调用堆栈跟踪，然后看看我们要去哪里。

最终更新（问题自行解决）

在超过 Query Store 事务打开的 52 小时标记之后（如上所述），AG 决定自动进行故障转移。在这发生之前，我确实提取了一些额外的指标。根据Sean 提供的这个链接，有问题的数据库有一个非常大的版本存储专用于该数据库，特别是在某一时刻，我在该reserved_page_count字段中记录了 1651360 个页面和 13210880 个reserved_space_kb值。

QDS base transaction根据错误日志，故障转移是在与事务相关的事务强化失败 5 分钟后发生的QDS nested transaction。

就我而言，故障转移确实导致了大约 10 分钟的中断。该数据库的大小约为 6TB，并且非常活跃，因此在我看来这实际上非常好。虽然新的主节点在此期间在线，但没有客户端查询可以完成，因为它们都在等待QDS_LOADDB等待类型。

故障转移后，版本存储数量减少到 176reserved_page_count和 1408 reserved_space_kb。对辅助只读副本的查询也开始像从主副本运行一样快地执行，因此看起来该行为完全消失了，这是故障转移的结果。

我在 4 个 vCPU 虚拟机上运行 Microsoft SQL Server 2016 SP2-CU6 (13.0.5292.0)并max degree of parallelism设置为.2cost threshold for parallelism50

早上，当尝试显示SELECT TOP 100 查询的估计执行计划时，我遇到了大量等待，呈现估计计划的操作需要几分钟，通常在 5 到 7 分钟范围内。同样，这不是查询的实际执行，这只是显示Estimated Execution Plan的过程。

sp_WhoIsActive将显示PAGEIOLATCH_SH等待或LATCH_EX [ACCESS_METHODS_DATASET_PARENT]等待，当我在操作期间运行Paul Randal 的 WaitingTasks.sql脚本时，它显示CXPACKET等待，工作线程显示PAGEIOLATCH_SH等待：

*资源描述字段=exchangeEvent id=Port5f6069e600 WaitType=e_waitPortOpen waiterType=Coordinator nodeId=1 tid=0 ownerActivity=notYetOpened waiterActivity=waitForAllOwnersToOpen

工作线程看起来将整个stats表带入内存（因为这些页码以及从 Paul Randal 的查询中显示的后续页码指向stats表的聚集键）。一旦计划确实回来了，它在一天的剩余时间里基本上是即时的，即使在我看到stats缓存中的大部分表磨损只剩下各种记录之后（我假设这些记录是由于来自类似查询的查找操作而被提取的）。

如果查询实际上是使用使用 SCAN 运算符的计划执行的，我会期望这种初始行为，但是为什么在评估执行计划时这样做只是为了到达 SEEK 运算符，如上面链接的计划中所示？我可以做什么（除了在办公时间之前运行此语句以便我的数据被适当缓存）来帮助提高这里的性能？我假设一对覆盖索引会是有益的，但它们真的能保证行为的任何变化吗？我必须在此处的一些存储和维护窗口限制范围内工作，并且查询本身是从供应商解决方案生成的，因此此时欢迎任何其他建议（除了更好的索引）。

长话短说

我正在寻找一种方法来有效地识别最靠近SQL Server数据文件末尾的对象。这种方法需要保持对大型数据文件的性能。

到目前为止我所拥有的

以下查询使用 SQL 2012 附带的未记录的动态管理函数：sys.dm_db_database_page_allocations; 这个 DMF 提供了一个粗略的DBCC IND命令等价物。

以下查询标识给定数据文件中的最后一个对象（警告：不要对大于 25 GB 的数据库运行此查询，除非您想在某个时候取消它）：

-- Return object with highest Extent Page ID
SELECT   files.name as logical_file_name
        , files.physical_name as physical_file_name
        , OBJECT_SCHEMA_NAME(object_id) + N'.' + OBJECT_NAME(object_id) AS object_name
        , alloc.*
FROM sys.dm_db_database_page_allocations(DB_ID(), NULL, NULL, NULL, NULL) alloc
    INNER JOIN sys.database_files files
        ON alloc.extent_file_id = files.file_id
WHERE is_allocated = 1
    AND files.name = 'Logical_FileName'
ORDER BY files.name , files.physical_name, extent_page_id DESC

这种方法有什么问题

正如上面的警告所暗示的那样，随着数据库大小的增加，此查询将运行得更慢，因为该函数实际上是为查看特定对象而不是查看有问题的特定数据文件的有针对性的方法而设计的。当像我一样传递NULL参数时，此函数可能会在后台遍历数据库中的所有对象并吐出组合输出。这完成了我需要的，但它以一种非常蛮力的方式完成，不适合优化。

我要的是什么

我希望有一种方法可以遍历GAM、SGAM和/或IAM 链，以快速识别给定数据文件末尾的对象。我假设我必须将这种方法从 TSQL 推到 PowerShell 之类的东西，然后返回使用DBCC PAGE调用或类似的东西，遍历页面分配映射以查找给定数据文件的最后一个对象是什么。...我希望有人已经将这些代码放在一起，或者比我更了解这些结构和/或这些未记录程序的输出。

为什么我需要这个？

这是许多人不可避免会问的问题，所以我只是开门见山地回答一下。我一直在做的项目是让遗留系统加快速度，但是在将一堆堆表整合在一起之后（由于其他原因这是一场噩梦），我现在在我的数据中留下了一堆可用空间文件。我想将这个空间释放回操作系统，但是，将对象迁移到不同数据文件的传统方法在这个阶段不可行，因为我没有足够的可用空间在系统上使用（直到我能够从此数据文件中释放更多空间）。

我采取了禁用文件增长并DBCC SHRINKFILE TRUNCATEONLY每晚运行命令来释放数据文件末尾的所有打开页面的方法，但这是一个缓慢而艰巨的过程，可能会经常发生，也可能不会发生。我希望确定文件末尾的对象是什么，以便我可以手动重建它们并在更快的时间表中释放空间。

总之

有没有办法快速识别位于给定数据文件末尾的对象的名称？我现在使用的方法不能满足我的需求，我愿意使用任何可用的方法。

我确定我错过了一个明显的解决方案，但我试图总结由显式组号和隐式排序定义的组的值。我敢肯定，这不会让这更清楚，所以假设我有这个示例源堆表：

GroupID     Value
----------- -----------
1           5
1           5
1           3
2           4
2           1
1           4
2           3
2           5
2           2
1           1

我想要一个为我提供以下结果的查询：

GroupID     Values
----------- -----------
1           13
2           5
1           4
2           10
1           1

隐含的顺序是我还没有找到解决方法的挑战……但是。任何帮助，将不胜感激。

我希望我可以使用类似于以下的查询创建确定性行排序：

SELECT    * 
        , ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS RowNum  
FROM Table WITH(TABLOCK)
OPTION (MAXDOP 1)

我希望这会强制进行分配顺序扫描，然后给我一个确定性的行顺序。

可悲的是，我坚持使用数据。我这里没有其他指标，例如日期等，可以提供任何固定顺序。我希望上面概述的技巧就足够了，但我不完全确定它会。

编辑：为了结束这个问题，因为我知道有人问我为什么要问这个问题，我有一系列堆表，按月/年命名，其中包含业务要汇总的行项目金额按天（它们与我问题中的隐含群体相关）。由于有效地执行此操作看起来不可行，我们决定在月（例如表）级别进行聚合，因此这篇文章帮助我证明了对业务需求的更改是合理的。感谢大家的投入！

我有一个通过存储过程 (SP) 填充的 SQL Server Reporting Services (SSRS) 2012 报告。SP 返回各种字段，其中之一是BIGINT数据类型。当我直接执行 SSRS 报告时，该值会正确显示，但当我将输出导出到 Excel 时，它会四舍五入到最接近的千分之一。

例如，这是我所看到的一个例子。

正确的价值：480758225903628660

Excel 文件中显示的值：480758225903629000

它四舍五入8660到9000。真令人沮丧，Microsoft 的文档对这种行为只字未提。我也在报告中到处挖掘我能想到的可能会影响这一点，例如文本框属性：

...占位符属性：

...以及字段本身的值：

CStr()我可以通过将字段值包装在or.ToString()函数中将字段转换为字符串来“修复”它，但这也将输出视为字符串而不是数字。有没有办法将其导出到 Excel，这样就不会发生四舍五入但仍保持该值为数字？

我怀疑我今天的 Google 技能还不够，但我正在寻找一个快速的 TSQL 脚本，该脚本将识别包存储中使用给定环境变量名称的所有 SSIS 包。

例如，当我配置一个包并查看参数页面时，我可以选择一个给定的环境变量。在下面的屏幕截图中，我关心的环境变量名为SMTP. 我想找到所有使用这个环境变量的包，这样我就可以在进行任何整体更改之前进行一些调查/测试。

如果有人有现成的脚本，如果您能发布它，我将不胜感激，否则我会在编写代码后发布一些内容。

谢谢！

我正在处理以下场景，其中我的时间数据落入islands 和 gaps中。每隔一段时间，我需要根据事件发生的时间将落在现有间隙内的事件与其最近的岛屿相关联。

为了演示，假设我有以下定义我的时间段的数据：

2此数据是连续的，除了 ID和之间存在的间隙，7时间段为。2017-07-26 00:03:002017-07-26 00:07:00

为了识别最近的岛屿，我目前将差距分为两个时期，如下所示：

如果我有一个事件落在这个间隔内，GapWindowStart/ Endtimes 将决定我需要将事件与哪个岛相关联。因此，例如，如果我有一个事件发生在2017-07-26 00:03:20，我会将该事件与 ID 相关联，2反之，如果我有一个事件发生在 ，2017-07-26 00:05:35我会将该事件与 ID 相关联7。

到目前为止，我能够编写我的方法的最有效方法是使用Itzik Ben-Gan通过ROW_NUMBER窗口函数从 SQL Server MVP Deep Dives 书中的第 3 个解决方案来组装间隙，然后按照执行的CROSS APPLY语句拆分间隙就像一个简单的UNPIVOT操作。

这是我用来组装最近的岛屿集的方法的db<>fiddle计划。

确定最近的岛屿后，我使用事件的事件时间来确定最近的岛屿以将所述事件与之相关联。因为这些岛屿全天都在变化，所以我无法制作静态主表，而是必须依赖于遇到事件时在运行时构建所有内容。

这是一个db<>fiddle 计划，显示应该针对随机事件时间使用什么 NearestIsland 值。

有没有更好的方法来找出通常会落入缺口的给定事件的最近岛屿？例如，是否有更有效的方法来识别差距或更有效的方法来识别最近的岛屿？我什至以最合乎逻辑的方式来解决这个问题吗？这个问题没有什么关键的，但我一直在试图弄清楚是否有一种“更好”的方法来解决问题，我认为这个问题本身可以带来一些创造力，所以我很乐意看到其他高性能的选择。

我目前使用的环境是 SQL 2012，但我们很快就会迁移到 SQL 2016 环境，所以我对几乎所有东西都持开放态度。

第二个 db<>fiddle 链接的代码如下：

-- Creation of Test Data
CREATE TABLE #tmp
(
      ID            INT PRIMARY KEY CLUSTERED
    , WindowStart   DATETIME2
    , WindowEnd     DATETIME2
)

-- Create contiguous data set
INSERT INTO #tmp
SELECT    ID
        , DATEADD(HOUR, ID, CAST('0001-01-01' AS DATETIME2))
        , DATEADD(HOUR, ID + 1, CAST('0001-01-01' AS DATETIME2))
FROM
(
    SELECT TOP (1500000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS ID
    --SELECT TOP (87591200) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS ID  -- Swap line with above for larger dataset
    FROM master.sys.configurations t1
    CROSS JOIN master.sys.configurations t2
    CROSS JOIN master.sys.configurations t3
    CROSS JOIN master.sys.configurations t4
    CROSS JOIN master.sys.configurations t5
) x


--DELETE 1000000 random records to create random gaps
DELETE FROM #tmp
WHERE ID IN (
    SELECT TOP 1000000 ID
    --SELECT TOP 77591200 ID -- Swap line with above for larger dataset
    FROM #tmp
    ORDER BY NEWID()
)


-- Create RandomEvent Times
CREATE TABLE #tmpEvent
(
    EventTime DATETIME2
)

INSERT INTO #tmpEvent
SELECT DATEADD(SECOND, X.RandomNum, Y.minWindowEnd) AS EventDate
FROM (VALUES (ABS(CHECKSUM(NEWID())))
           , (ABS(CHECKSUM(NEWID())))
           , (ABS(CHECKSUM(NEWID())))
           , (ABS(CHECKSUM(NEWID())))
           , (ABS(CHECKSUM(NEWID())))
           , (ABS(CHECKSUM(NEWID())))
           , (ABS(CHECKSUM(NEWID())))
           , (ABS(CHECKSUM(NEWID())))
           , (ABS(CHECKSUM(NEWID())))
           , (ABS(CHECKSUM(NEWID())))) AS X(RandomNum)
    CROSS JOIN (SELECT MIN(WindowEnd) AS minWindowEnd FROM #tmp) AS Y


SET STATISTICS XML ON
SET STATISTICS IO ON

--Desired Output Format - Best Execution I've found so far
;WITH rankIslands AS (
    SELECT    ID
            , WindowStart
            , WindowEnd
            , ROW_NUMBER() OVER (ORDER BY WindowStart) AS rnk
    FROM    #tmp
), rankGapsJoined AS (
    SELECT    t1.ID AS NearestIslandID_Lower
            , t1.WindowEnd AS GapStart_Lower
            , DATEADD(MINUTE, (DATEDIFF(MINUTE, t1.WindowEnd, t2.WindowStart) / 2), t1.WindowEnd) AS GapEnd_Lower
            , t2.ID AS NearestIslandID_Higher
            , DATEADD(MINUTE, -1 * (DATEDIFF(MINUTE, t1.WindowEnd, t2.WindowStart) / 2), t2.WindowStart) AS GapStart_Higher
            , t2.WindowStart AS GapEnd_Higher
    FROM rankIslands t1 INNER JOIN rankIslands t2
        ON t1.rnk + 1 = t2.rnk
            AND t1.WindowEnd <> t2.WindowStart
), NearestIsland AS (
    SELECT  xa.*
    FROM    rankGapsJoined t1
            CROSS APPLY ( VALUES (t1.NearestIslandID_Lower, t1.GapStart_Lower, t1.GapEnd_Lower)
                                ,(t1.NearestIslandID_Higher, t1.GapStart_Higher, t1.GapEnd_Higher) ) AS xa (NearestIslandId, GapStart, GapEnd)
)
-- Only return records that fall into the Gaps
SELECT e.EventTime, ni.*
FROM    #tmpEvent e INNER JOIN NearestIsland ni
                ON e.EventTime > ni.GapStart
                AND e.EventTime <= ni.GapEnd

SET STATISTICS XML OFF
SET STATISTICS IO OFF


DROP TABLE #tmp
DROP TABLE #tmpEvent

问题：（@MaxVernon）

• 期望的结果是包含差距的表格吗？

• 或者您是否试图将传入的行分配给最近的邻居？

• 或者您是否希望重现您在示例中显示的确切输出？

回答：

简而言之，是、是和否。期望的结果是确定任何（其他/更多）有效的方法来识别通常落在间隙内的事件时间的最近岛屿。我试图扩展这个问题，以表明理想的最终结果是什么。

当我将一些测试数据集放在一起时，我注意到临时表有一些有趣的行为。在通过并行执行计划填充的集群临时表中处理大量数据时，集群键在选择数据时看起来并不重要。这个问题似乎也会影响我测试过的所有 SQL Server 版本（包括 vNext）。

这是测试的dbfiddle.uk示例。您可能需要执行几次才能得到我找到的结果，但执行一次或两次以上才能产生相同的结果。此外，这是我在我的环境中获得的本地执行计划，它表明大数据集和小数据集之间的唯一区别是数据被馈送到表中的方式（例如并行计划与串行计划）。

如果你想在家玩，这是我正在运行的测试：

-- Large Data Set
CREATE TABLE #tmp
(
    ID  INT PRIMARY KEY CLUSTERED
)

INSERT INTO #tmp
-- Purposely insert in reverse order
SELECT TOP 100 PERCENT RN
FROM
(
    SELECT TOP (10000000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) RN
    FROM master..spt_values t1
    CROSS JOIN master..spt_values t2
) x
ORDER BY RN DESC


-- Smaller Data Set
CREATE TABLE #tmp2
(
    ID  INT PRIMARY KEY CLUSTERED
)

INSERT INTO #tmp2
-- Purposely insert in reverse order
SELECT TOP 100 PERCENT RN
FROM
(
    SELECT TOP (10000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) RN
    FROM master..spt_values t1
    CROSS JOIN master..spt_values t2
) x
ORDER BY RN DESC

-- Large Record Set
-- Clustered Key Not Honored*
SELECT TOP 10 *
FROM #tmp

-- Small Record Set
-- Clustered Key Honored
SELECT TOP 10 *
FROM #tmp2

DROP TABLE #tmp
DROP TABLE #tmp2

我没有找到任何表明这是预期行为的参考资料，但在我提交连接项目之前，我首先想联系并确认这不是本地化问题。有人可以指点我识别这是预期行为的文档，或者确认这实际上是一个错误吗？

编辑：为了回应关于不包含ORDER BY子句的评论，我总是假设 TOP 关键字按插入顺序返回数据，在这种情况下，应该是聚集键指定的顺序。对正式表运行相同的语句时，将返回预期的行为：

-- Large Data Set with a Formal Data Table
CREATE TABLE tmp
(
    ID  INT PRIMARY KEY CLUSTERED
)

INSERT INTO tmp
-- Purposely insert in reverse order
SELECT TOP 100 PERCENT RN
FROM
(
    SELECT TOP (10000000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) RN
    FROM master..spt_values t1
    CROSS JOIN master..spt_values t2
) x
ORDER BY RN DESC

-- Large Record Set
-- Clustered Key Not Honored*
SELECT TOP 10 *
FROM tmp

DROP TABLE tmp

(6325225 row(s) affected)


(1 row(s) affected)
ID
-----------
1
2
3
4
5
6
7
8
9
10

(10 row(s) affected)



(1 row(s) affected)

即使执行计划相同，为什么临时表和正式定义表之间的结果集不同？

最后，向Joe Obbish 大声疾呼，因为我无偿地借鉴了他的 CROSS JOIN 方法来构建大量测试数据，因为它非常高效！

我正在使用 SQL Server 2012 企业版。我遇到了一个 SQL 计划，它表现出一些我不觉得完全直观的行为。在大量并行索引扫描操作之后，发生并行（重新分区流）操作，但它正在杀死索引扫描（Object10.Index2）返回的行估计，将估计减少到 1。我做了一些搜索，但是没有遇到任何解释这种行为的东西。查询非常简单，尽管每个表都包含数百万的记录。这是 DWH 加载过程的一部分，这个中间数据集在整个过程中被触及了几次，但我遇到的问题尤其与行估计有关。有人可以解释为什么在 Parallelism (Repartition Strems) Operator 中准确的行估计会变为 1 吗？还，

我已将完整计划发布到粘贴计划。

这是有问题的操作：

包括计划树以防添加更多上下文：

我会遇到 Paul White 提交的这个 Connect 项目的一些变体吗（在他的博客上进一步深入解释）？至少它是我发现的唯一一个似乎与我遇到的情况很接近的东西，即使没有 TOP 操作员在玩。

显然，在调整时看到实际的执行计划是一件大事，通常我启用查询计划输出SET STATISTICS XML ON并运行任何需要一些 TLC 的查询，但是我如何才能看到计划历史运行或我不能的进程的实际记录计数轻松手动运行（或在测试环境中模拟）？

sys.dm_exec_query_plan当我通过其中一个或sys.dm_exec_text_query_plan仅显示估计的行数从查询缓存中提取此信息时。使用查询存储 DMV 时存在相同的行为sys.query_store_plan。由于所有这些 DMV 都在提取已使用的实际计划，我希望看到实际的行执行计数包含在计划的图形表示中，但它们不存在。

从sys.dm_exec_query_statsDMV 返回的信息只是有点用处，因为它返回声明的总计数，但计划中的详细操作员计数似乎隐藏在历史计划中。在 2014 年，我们可以使用sys.dm_exec_query_profilesDMV，这有助于当前正在执行的计划，但这在查看历史执行时也无济于事。

这些信息是否存储在其他地方？我是否应该将估计行计数视为实际计数（我对此表示怀疑，但既然我在问......）？是否有连接项目请求此功能我可以投票？

我试图了解我在一个相当大且不守规矩的查询计划中看到的一些行为。特别是，我正在查看在其谓词中包含标量操作的聚簇索引查找操作。我怀疑 Scalar 操作只是其中一个表的别名（如Seek Predicate 中的 Scalar Operator 中所述），因为两列的类型相同，并且此操作馈入并行嵌套循环（左外连接）运算符。

不过，我的问题更多是关于行估计数为 1 而不是更接近实际行数（约 670 万）的数字。标量操作是否会破坏优化器正确估计行的能力？我假设是这样，也假设这会损害我的查询执行计划的最佳状态，但我真的不确定。有人可以证实或反驳我的怀疑以及为什么吗？

这是有问题的操作：

版本：SQL Server 2012 企业版

这是困扰我的事情，虽然从来没有引起任何真正的问题，因为我通常可以通过其他方式找到这些信息，但是有人可以解释为什么NULL可能会在DMV 的 、 和 列中返回，但在dbid列objectid中number产生结果？我理解为什么输出会反向返回（例如所有列但会产生数据），但我已经在多个 SQL Server 版本中多次看到这种行为，并且文档似乎并不暗示这应该是可能的，或者我只是读错了。sys.dm_exec_sql_texttexttext

这是我正在运行的查询的示例：

SELECT TOP 100 
      t.*
    , s.*
    , c.*
FROM    sys.dm_exec_query_stats s
        LEFT JOIN sys.dm_exec_connections c
               ON c.most_recent_sql_handle = s.sql_handle
        CROSS APPLY sys.dm_exec_sql_text(s.sql_handle) t
WHERE s.execution_count > 1 AND DATEDIFF (second, creation_time, GETDATE()) > 0
        AND t.dbid IS NULL

这是该列中的一个结果的示例，text这意味着这与临时对象无关，而我通常认为这是原因。

select * from [dbo].[Map_ProviderSpecialty]

NULL这些列返回值的情况是什么？

由于我的性能调优技能似乎永远不够用，我总是想知道是否可以针对某些查询执行更多优化。这个问题涉及的情况是嵌套在子查询中的 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
        SET @UniqueDate = GETDATE()+@i
    END

    SET @GroupDate = GETDATE()+(@j-1)

    INSERT INTO #Example (GroupID, GroupDate, UniqueDate)
    VALUES (@j, @GroupDate, @UniqueDate)

    SET @i = @i + 1

    IF (@i % 5 = 0)
    BEGIN
        SET @j = @j+5
    END
END
SET NOCOUNT OFF

CREATE NONCLUSTERED INDEX [IX_2_4_3] ON [#Example]
(
    [GroupID] ASC,
    [UniqueDate] ASC,
    [GroupDate] ASC
)
INCLUDE ([UniqueID])

-- Identify any UniqueDates that are greater than the GroupDate within their GroupID
SELECT UniqueID
     , GroupID
     , GroupDate
     , UniqueDate
FROM (
    SELECT UniqueID
         , GroupID
         , GroupDate
         , UniqueDate
         , MAX(UniqueDate) OVER (PARTITION BY GroupID) AS maxUniqueDate
    FROM #Example
    ) calc_maxUD
WHERE maxUniqueDate > GroupDate
    AND maxUniqueDate = UniqueDate

DROP TABLE #Example

dbfiddle在这里

我们有许多运行 PostGIS 1.4 的 4.2.3.2 Greenplum 数据库。我们正在尝试将这些数据库安装到更新版本的 Greenplum 上，例如 4.3.8.1 或重新发布的 4.3.9.1 版本，但是在尝试将 PostGIS 升级到 2.0 版时我们遇到了一堆问题。我们已经尝试了多种不同的方法来升级数据库，而不会影响依赖于 PostGIS 1.4 的数据和功能，但看起来当我们使用新的 PostGIS 扩展运行gppkg实用程序时，我们只会出现错误，类似于以下内容：

gppkg -i postgis-ossv2.0.3_pv2.0.1_gpdb4.3orca-rhel5-x86_64.gppkg 
20160919:13:21:20:024675 gppkg:s-md-pv-gp-01-01:gpadmin-[INFO]:-Starting gppkg with args: -i postgis-ossv2.0.3_pv2.0.1_gpdb4.3orca-rhel5-x86_64.gppkg
20160919:13:21:20:024675 gppkg:s-md-pv-gp-01-01:gpadmin-[CRITICAL]:-gppkg failed. (Reason='__init__() got an unexpected keyword argument 'postupdate'') exiting...

我们还通过 -u 标志运行 gppkg，结果相似：

gppkg -u postgis-ossv2.0.3_pv2.0.1_gpdb4.3orca-rhel5-x86_64.gppkg 
20160919:13:35:52:024930 gppkg:s-md-pv-gp-01-01:gpadmin-[INFO]:-Starting gppkg with args: -u postgis-ossv2.0.3_pv2.0.1_gpdb4.3orca-rhel5-x86_64.gppkg
20160919:13:35:52:024930 gppkg:s-md-pv-gp-01-01:gpadmin-[WARNING]:-WARNING: The process of updating a package includes removing all
20160919:13:35:52:024930 gppkg:s-md-pv-gp-01-01:gpadmin-[WARNING]:-previous versions of the system objects related to the package. For
20160919:13:35:52:024930 gppkg:s-md-pv-gp-01-01:gpadmin-[WARNING]:-example, previous versions of shared libraries are removed.
20160919:13:35:52:024930 gppkg:s-md-pv-gp-01-01:gpadmin-[WARNING]:-After the update process, a database function will fail when it is
20160919:13:35:52:024930 gppkg:s-md-pv-gp-01-01:gpadmin-[WARNING]:-called if the function references a package file that has been removed.
Do you still want to continue ? Yy|Nn (default=N):
> y
20160919:13:35:59:024930 gppkg:s-md-pv-gp-01-01:gpadmin-[CRITICAL]:-gppkg failed. (Reason='__init__() got an unexpected keyword argument 'postupdate'') exiting...

一个主要的警告可能也与以下事实有关，即只有Greenplum 版本 4.2.6.X 到 4.2.8.X 同时支持 postGIS 的 1.4 和 2.0 版本。在这一点上，我们正在寻找一些关于如何进行的方向，希望其他人可能已经遇到了其中的一些障碍。

我们已经与供应商 Pivotal 取得了联系，但这些都没有取得成果，所以我在这里发帖，希望社区能为我指明方向。

谢谢，

约翰

我们通过 CRON 作业运行 RMAN 备份，但使用 CRON 找到开箱即用的电子邮件几乎可以满足我们的需求。我知道我们可以将 RMAN 输出引导到 /dev/null，因此不会发送任何电子邮件，这对于任何成功运行 RMAN 来说都是期望的结果，但是如果 RMAN 作业遇到错误，我想要整个标准输出通过电子邮件发送给 DBA 团队进行审核。我怀疑我可以用 bash shell 脚本包装我的 RMAN 脚本，该脚本仅在发生故障时将标准输出通过管道传输到 cron，但是有更好的方法吗？

总结一下：

1. 如果发生错误，我可以通过管道将标准输出发送到电子邮件（如果不存在错误则忽略标准输出），以便我们可以在 cron 中使用默认邮件功能？
2. 如果不是，我是否应该用逻辑包装我的 RMAN 备份脚本，以便在遇到错误时只返回 shell 脚本的输出？
3. 是否有另一种我看不到或无法在网上找到的方法来实现这一目标？

如果这已经被问到，我很抱歉。我发现了许多一次性的问题和场景，但我觉得没有一个与我想要的结果完全匹配。

谢谢！

我必须相信这是有原因的，但对于我的生活我无法弄清楚。看起来任何中央管理服务器中的服务器名称排序都是区分大小写的，而不管充当 CMS 的服务器本身的排序规则如何。

附件是我本地机器上托管的 CMS 示例，它配置了 SQL_Latin1_General_CP1_CI_AS 的服务器排序规则。CI 表示不区分大小写。当从包含 CMS 对象的系统表中进行选择时，将返回正确的顺序，但是正如您在此屏幕截图中看到的那样，服务器在 UI 中列出的方式显然以区分大小写的方式处理顺序。

由于它似乎与服务器级别无关，我假设它与客户端工具相关，但在工具中没有任何地方可以识别会影响此的排序规则级别（甚至区分大小写设置）。

显然这个问题没有什么关键的，但如果有人知道如何强制 UI 不区分大小写，我会很感激，因为我喜欢 Camel Case 我的服务器名称，这会打乱顺序。