标签: sql-server-2017

是否有任何系统目录视图或 DMV 可用于从 SQL Server:Memory Manager 查询（例如在 SSMS 中）以下性能计数器？

Free Memory (KB)
Target Server Memory
Total Server Memory
Maximum Workspace Memory (KB)
Database Cache Memory (KB)
Granted Workspace Memory (KB)
Lock Memory (KB)
Log Pool Memory (KB)
Optimizer Memory (KB)
Connection Memory (KB)
SQL Cache Memory (KB)
Reserved Server Memory (KB)
Stolen Server Memory (KB)

我编写了一个程序来测试对单个数据库表的并发读取。我预计未来会有大量读取（无删除、插入或更新）流量，使用即席查询，这就是我预先测试以模拟这一点的原因。根据下面的日志，您可以看到随着并发读取数量的增加，完成请求所需的时间也会增加。从单个请求的 3 秒到 20 个并发请求的最长 15 秒。

我认为我不是不合理，当我向数据库发送垃圾邮件请求时，我预计它需要更长的时间来处理，但不是这么大的因素。尤其是因为服务器不受 CPU 限制，正如 SQL Server 性能仪表板在 20 个并发请求期间 CPU 使用率为 40% 所证明的那样。

Started 1.
Ended 1. Elapsed milliseconds: 2938

Started 2.
Started 4.
Started 5.
Started 3.
Started 1.
Ended 1. Elapsed milliseconds: 3204
Ended 3. Elapsed milliseconds: 4486
Ended 5. Elapsed milliseconds: 5185
Ended 2. Elapsed milliseconds: 5261
Ended 4. Elapsed milliseconds: 6075

Started 1.
Started 5.
Started 7.
Started 3.
Started 6.
Started 4.
Started 8.
Started 9.
Started 2.
Started …

我们计划在这个物理架构上安装一个 SQL Server：

• 基于windows server 2019的hyper-v集群
• 所有虚拟机所在的集群共享卷
• 包含 CSV 的全闪存 SAN

我一直读到，为数据文件、日志文件、临时数据库文件等拥有多个磁盘是一种常见的最佳实践......

但该最佳实践指的是裸机安装。

所以，我要问的是：在上述架构（如果有的话）上这样做的实际好处是什么？

有人可以帮我弄清楚我的理解是否正确：

在我的可读辅助副本的 AG 仪表板上，我看到：

• 预计恢复时间（秒） - 4598
• REDO 队列 - 将近 24 GB

那么，如果我的辅助 AG 需要将节点/故障转移或 SQL 重新启动作为活动的一部分，这究竟意味着什么？

这是否意味着我的二级数据库需要 4598 秒才能使用 24 GB 的重做队列启动这个数据库？

我很担心，因为我们的一个生产秒方在白天的大部分时间里重做大小为 400 GB，而从 AG 仪表板恢复时间将近 10 小时。这是否意味着所谓的 DR 受到了损害？

我刚刚做了一个测试故障转移，正如我从错误日志消息中看到的那样，数据库按预期进行了恢复，并看到它在 1235 秒内完成。只是好奇，因为估计恢复的数量还差得很远。这只是为了解释我的业务用户帮助他们我们正在谈论的中断窗口。

我有一种情况，我需要对大量类似的数据库运行查询。他们中的大多数人都会有一个表，我需要更新其中的一些行，但其中一些人没有该表。

我想编写一个查询，该查询具有IF检查表是否存在EXEC sp_executesql的UPDATE语句，而无需使用该语句。有没有办法在 SQL Server 中做到这一点？

这是我今天正在做的一个例子：

IF EXISTS (SELECT * FROM dbo.sysobjects WHERE id = object_id(N'[dbo].[MyTableName]') AND OBJECTPROPERTY(id, N'IsUserTable') = 1)
BEGIN
  -- this is what I want to be able to do but cannot
  UPDATE [dbo].[MyTableName] SET [SomeColumn] = NULL WHERE [SomeColumn] NOT IN (1, 2, 3)

  -- this is the only way I know to do this without an error
  EXEC sp_executesql N'UPDATE [dbo].[MyTableName] SET [SomeColumn] = NULL WHERE [SomeColumn] NOT …

出于我无法解决的原因，我们正在寻找WSUS和SCCM 的替代方案来自动化 SQL CU 修补（特别是在 SQL 2017+ 上）

有一些简洁的 Powershell 解决方案，例如Adam Bertram 的这个解决方案，我通过相关帖子在 Windows 上自动修补 SQL Servers 中找到

我知道有很多商业解决方案，谷歌很容易找到。我正在寻找我们可以在内部管理的解决方案。

我也在寻找其他方法来考虑。经过广泛搜索，我什至可以想象的唯一其他方法是在服务器重新启动时运行的 SQL 作业（服务器修补通常在重新启动时定期发生）），它将在共享文件夹中查找最新的 CU，如果未安装则应用它。但我没有发现除上述之外的任何解决方案。

是否有任何自动化 SQL CU 补丁的方法，但我还没有找到示例？

如果 SQL 作业修补可行，是否有任何示例？

如果我有两台服务器（服务器 A 和服务器 B）属于同一个可用性组故障转移集群，并且在服务器 A 上运行的查询具有使用并行化的执行计划，那么该查询是否可以使用处理器的内核在服务器 B 上？

我们为 SQL Server 创建了一个非生产环境。
此环境使用 SQL Server Always-On 可用性组作为 HA 解决方案。

要使用 SQL Server AG，您必须将恢复模型设置为完整，以便日志可以与其他副本同步，但将恢复模型设置为完整也意味着如果您不进行备份，日志将继续增长。

由于这是一个非生产环境，我们对这些数据库的备份不感兴趣。你们认为在这种环境下最好的方法是什么？

• 创建备份到磁盘并删除它们
• 一定要备份这个环境
• 其他建议...

出于多种原因，但主要是数据量庞大，我们有 5 个 MS-SQL (2017) 分片服务器来分解任何单个服务器上的整体负载。其次，我们有一个按资产 ID 分区的实时表，以存储实时数据。每个资产的数据包大约每 2 秒到达一次。每个数据包可以有 300 到 12000 个数据点。

表分区和分片服务器运行良好。但是每隔一段时间，似乎其中一台服务器似乎停止使用分区，这会导致在删除旧数据和批量加载新数据时新数据到达时出现死锁和超时。

我的问题是为什么会发生这种情况，有没有办法检查何时或为什么会发生这种情况。我知道这是个问题，因为我可以将数据移动到临时表，删除原始表，使用相同的分区函数和方案重新创建原始表，最后将数据从临时表复制回新的“原始”表问题解决了。

根据要求的分区方案。资产 ID 是函数使用的内容，如上所述

CREATE PARTITION SCHEME [RMAPartitionScheme] AS PARTITION [RMAPartitionFunction] 
TO ([HULL269_484_LymanMartin], [HULL275_541_ClarenceTriche], 
    [HULL277_546_RussellAdams], [HULL278_550_CharlieComeaux], 
    [HULL281_561_CInstaller], [HULL284_587_GrandIsle], 
    [HULL290_621_ShipIsland], [HULL291_638_HornIsland], 
    [HULL296_653_StimStarIV], [HULL293_654_CatIsland], 
    [HULL292_655_SanibelIsland], [HULL297_678_DauphinIsland], 
    [HULL137_679_StimStarBrasil], [HULL809_680_Robin], 
    [HULL1304_690_FastTrack], [HULL174_691_CRuler], 
    [HULL1328_692_FastTiger], [HULL240_695_CFighter], 
    [HULL778_730_Kudu], [HULL064_738_FastCheetah], 
    [HULL063_739_FastServer], [HULLT100_746_ITS100BSM], 
    [HULLBT10_749_ITSBuckeye], [HULL315_779_Elrington], 
    [HULL302_780_MarshIsland], [HULL321_781_Courageous], 
    [HULL316_782_LaTouche], [HULL317_784_BainBridge], 
    [HULL324_787_Contender], [HULL325_788_Champion], 
    [HULL318_790_Ingot], [HULL326_792_Challenger], 
    [HULLN01_797_SeawayMoxie], [HULLAS1_799_IslandCommander], 
    [HULL301_800_DeerIsland], [HULL810_804_Lucy], 
    [DEFAULT_FILE_GROUP])

和功能

CREATE PARTITION FUNCTION [RMAPartitionFunction](int) 
AS RANGE LEFT 
FOR VALUES 
     (484, 541, 546, 550, 561, …

我没有维护计划，但我看到在后台创建索引（低 spid）。我不知道正在创建什么索引或为什么。使用标准 SQL Server 2017 - Azure 上安装了 SQL 的 VM。

我检查并没有看到自动索引管理的任何地方。您可以配置备份等，但我找不到索引位置。

我尝试EXEC sp_WhoIsActive @show_system_spids = 1;并得到了这个结果：

(542701ms)RESOURCE_SEMAPHORE

我认为正在发生的事情是我有一个“混乱的索引”并且系统正在尝试修复它。我无法删除任何索引或重建它。至少这是我的猜测。