标签: sql-server-2019

默认情况下，SQL Server 允许最大并发连接数为 32767，这是可以同时登录 SQL Server 实例的最大用户数。

我正在开发 10 个 Web api，它们将使用自己的登录名查询 sql 服务器（因此最多 10 个登录名，加上管理员/开发人员）。预计并发登录数不超过20。

然而，每个登录 (api) 可以发出多个（也许 500 个）并发查询请求。因此，实际上 10 个 api * 500 个请求 = 5000 个并发查询请求。有时请求会较少或没有。

假设有足够的内存和磁盘 io 能力，我正在规划 cpu 要求。

据我所知，sql 请求被分配给工作线程，并且根据处理器的数量，有一定数量的默认工作线程。目前我的开发机器有 24 个处理器，因此默认的最大工作线程是 832。

假设查询可能超出线程占用成本（40），这意味着 SQL Server 可能决定使用并行性（最大 dop）。

假设 MAX DOP = 1，则一次可以处理 832 个请求。

假设 MAX DOP = 4，则一次可以处理 208 个请求。

超出此范围的任何查询请求都必须等待，直到为其分配工作线程。

那么，为了确保能够满足 5000 个请求的峰值负载，估计我至少需要大约 145 个 cpu 是否正确？

((145-4)*32)+512 = 5024

从页面预期寿命开始，它应该远高于 300。这告诉您页面在缓冲池中停留的时间，值 300 相当于 5 分钟。如果您有 120GB 的缓冲池，并且其运行时间超过 5 分钟，则相当于系统持续的磁盘 I/O 速度为 409.6 MB/秒，这是必须维持的大量磁盘活动。

链接： https: //deltabravo.ai/delta-bravo-performance-counters-sql-server-target-vs-total-memory/

使用的公式好像是->磁盘IO吞吐量=缓冲池内存*1024/PLE

这是确定磁盘 IO 吞吐量的正确方法吗？

链接：https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/basic-availability-groups-always-on-availability-groups ?view=sql-server-ver16

我使用的是 sql 标准版，它支持基本可用性组（每个 AG 1 db）。

我已经浏览了上面的文档，没有提到 Windows 集群。

我的理解是，由于它支持自动故障转移，因此应该需要一个 Windows 集群。请有人帮我确认并指出文档。

注意-文档引用如下：

它的创建和管理方式与企业版的传统（高级）Always On Availability Groups (SQL Server) 非常相似。

普通（高级/企业）AG 有 2 种类型 -

1. HA（这需要集群）；
2. 非 HA [只读/无自动故障转移]（这不需要集群）。

因此，我正在寻找有关此问题的文档，以明确基本 AG 是否需要集群进行自动故障转移，以及是否不需要集群进行手动故障转移。

我拥有所有默认的 WSFC 和 AG 设置。同步和自动故障转移模式。

AG 有 2 个节点：Node1 和 Node2

Node1 是主节点。

我在 Node1 上重新启动了 sql server 服务，导致故障转移到 Node2。

然后，我在Node2上重新启动了sql server服务。但它并没有导致故障转移到 Node1。

当我在新的主节点 (Node2) 上重新启动 sql 服务时，为什么 SQL AG 故障转移不起作用？

尝试将 MSDB 恢复到替换服务器并收到以下消息：

消息 3168，级别 16，状态 1，第 4 行 设备 e:\sqlbackup\2024-02-27_msdb_DEV.bak 上的系统数据库备份无法还原，因为它是由不同版本的服务器创建的 ( 15.00.4335）比该服务器（15.00.4355）。消息 3013，级别 16，状态 1，第 4 行 RESTORE DATABASE 异常终止。

当我通过 Management Studio 运行 dbcc checkdb 时，我会得到完整的报告作为输出。

但是，当我通过 sql 代理作业运行 dbcc checkdb 时，我认为如果 dbcc checkdb 未检测到错误，则作业状态将显示为成功；或者如果 dbcc checkdb 未检测到错误，则作业状态将显示为成功。否则作业状态将显示为失败。那是对的吗？

通过 sql 代理作业运行 dbcc checkdb 时如何获取报告？

链接： https: //www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/sql-server-on-vmware-best-practices-guide.pdf

\n

这种具有最终优势的架构也带来了一些需要考虑的权衡，其中最重要的是\xe2\x80\x94访问内存中数据的时间根据相应内存缓存线的本地或远程放置而变化。执行请求的 CPU 核心，远程访问速度比本地速度慢²⁹倍。

\n

---

\n

²⁹根据实现和处理器系列，这种差异可能高达 3 倍（来源：pdf，第 6 页）

\n

以下是互连的示例（https://www.sqlskills.com/blogs/jonathan/understanding-non-uniform-memory-accessarchitectures-numa/ ）：

根据上面的引用 - 访问远程内存中的数据（通过互连）的时间比本地慢 X 倍。

如果没有 NUMA，并且 CPU 访问内存（从中央位置），那么与互连访问相比，它会更慢还是更快？

我的职业生涯多种多样，但我从未在SQL Server 错误日志中找到相关信息。什么情况下我应该考虑检查？

我想为 M 个用户自动保留 N 个对象的库存。

我有两张库存跟踪表，一张用于全球库存，一张用于个人库存。

• 全局清单表列：ObjectID uniqueidentifier、Count int
• 个人库存表列：UserID nvarchar(64)、ObjectID uniqueidentifier、Count int

有两个表，因为我必须为每个对象以及每个用户强制执行最大允许保留。例如，一个对象可能被限制为总共保留 1000 个，每个用户最多保留 10 个该对象。

全局清单表以 [ObjectID] 为唯一键，个人清单表以 [UserID, ObjectID] 为唯一键。

• 主键是每个表上的唯一索引，因此只对行进行锁定，而不会对其他索引键进行锁定。
• 全局清单表将始终驻留在单个数据库中。
• 个人库存表可以跨多个数据库进行分片，因此更新全局和一个或多个个人表的事务可能是分布式的。
• 此“保留库存”事务是将在这些表上执行的唯一事务。

为 3 个对象保留库存的示例请求如下所示。一些对象有限制，而另一些则没有。

[
    {ObjectID: 'A', QuantityToReserve: 1},
    {ObjectID: 'C', QuantityToReserve: 2, GlobalMax: 1000, PersonalMax: 10},
    {ObjectID: 'B', QuantityToReserve: 5}
]

• 这种为多个对象保留库存的请求必须以原子方式完成，并且必须对所有对象都成功。
• 在尝试在个人表上取任何锁之前，总是在全局表上取一组完整的锁。

原子预留是通过启动一个事务，然后首先更新全局清单表中的行来实现的，对于所有对象 ID，按升序排列。

没有限制的对象的更新语句如下所示：

UPDATE [GlobalInventory] WITH (ROWLOCK, XLOCK, HOLDLOCK)
SET [Count] = [Count] + @QuantityToReserve
WHERE [ObjectID] = @ObjectID

具有限制的对象的更新语句如下所示：

UPDATE [GlobalInventory] WITH (ROWLOCK, XLOCK, HOLDLOCK)
SET …