小编Ale*_*sko的帖子

在生产 SQL Server 上，我们有以下配置：

3 台 Dell PowerEdge R630 服务器，合并到可用性组中
所有 3 台都连接到作为 RAID 阵列的单个戴尔 SAN 存储单元

有时，在 PRIMARY 上，我们会看到类似于以下内容的消息：

SQL Server 在数据库 ID 8 中
的文件 [F:\Data\MyDatabase.mdf] 上遇到了 11 次 I/O 请求需要超过 15 秒才能完成。操作系统文件句柄为 0x0000000000001FBC。
最近一次 long I/O 的偏移量为：0x000004295d0000。
长 I/O 的持续时间为：37397 毫秒。

我们是性能故障排除的新手

解决此与存储相关的特定问题的最常见方法或最佳实践是什么？

必须使用哪些性能计数器、工具、监视器、应用程序等来缩小此类消息的根本原因？

可能有一个扩展事件可以提供帮助，或者某种审计/日志记录？

更新：添加了我自己的答案（见下文），解释了我们为解决问题所做的工作

我们有一种情况，开发人员没有任何UPDATE权限，但他们使用应用程序并查看连接字符串 -> 他们知道来自某些SQLLogin1具有 UPDATE 权限的SQL 帐户（示例）的密码。我们目前的操作并不完善，有时需要修改生产数据（目前还没有 GUI）。

开发人员没有联系 DBA 并要求他修改数据，而是（不正确地）使用 SQL 帐户SQLLogin1（有权修改数据），并通过 SQL Server Management Studio 连接自己修改数据。

DBA 无法SQLLogin1在 Developer 看到新连接字符串和新密码的情况下更改密码，因为使用的应用程序连接字符串SQLLogin1是由 Developer 维护的。

题：

有没有办法拒绝访问SQLLogin1SQL 登录，但前提是它通过 SSMS 连接？

同时如果SQLLogin1正在连接.Net SqlClient Data Provider（program_name在sys.dm_exec_sessions），必须允许登录。

这样我们就不想让开发人员使用 SSMS 连接SQLLogin1，而使用的应用程序SQLLogin1仍然可以连接。

我有一个繁忙的数据库，它已经繁忙多年，并且我看到事务日志大小每天约为几 GB。

在过去几周内，事务日志大小已增加到每 6 小时 40-50 GB。这对我的备份产生了很大的影响，并且磁盘的大小也令人担忧。

我每隔一天进行一次完整备份，每 6 小时进行一次日志备份。

日志备份按预期减少了事务日志使用量的大小，但它又开始迅速增加。

如何发现导致交易量相对突然增加的原因？

• 我的开发人员正在对可能影响过去几周的变化进行空白
• 没有长时间运行的进程
• 没有计划的作业来执行索引操作
• Redgate 监控未显示任何过度写入

我该如何进一步调查？

我们一直在监控一些SQLServer: Memory Manager指标，并注意到在DBCC CheckDB工作后，指标

Database Cache Memory (KB)

大幅下降。准确地说，它从 140 GB 缓存数据库内存下降到 60 GB。之后，在一周内再次缓慢上升。（“ Free Memory KB”的数量，紧随其后从 20 GB 增加到 100 GB CheckDB）

DBCC CheckDB 每周日运行，因此数据库缓存内存必须每周再次增加

What is the behavior of this ? Why CheckDB pushes database pages out of memory ?

第二个问题是为什么“ buffer cache hit ratio”DBCC CheckDB完成后没有变化？

平均为 99.99%，在DBCC CheckDB工作后它下降到 ~98.00%，并很快恢复到 99%，而我预计“ buffer cache hit ratio”会显着下降，因为数据库数据必须再次从存储读取到 RAM？

我有几个关于数据缓存如何工作的问题
想象一下我们有以下情况：

服务器重新启动或我们刚刚运行 DBCC DROPCLEANBUFFERS

我们有一个Table150 GB 并且有列A, B, C, D, E。
列A是聚集索引键，列B和C对他们的非聚集索引。

1. 当我们做

   select top 100 * from Table1
   

   Run Code Online (Sandbox Code Playgroud)

   整个聚集索引（表）是否从磁盘读取到内存，即使我们只需要 100 行？还是只有 100 行（它们的数据页）从磁盘读取到内存？

2. 与非聚集索引相同，当我们这样做时

   select top 100 * from Table1 where column B = 'some value'
   

   Run Code Online (Sandbox Code Playgroud)

   整个非聚集索引+聚集索引是否被加载到内存中？或者只有来自非聚集索引的 100 行和来自聚集索引的 100 行？

我们有一台 256 GB RAM 的机器。
SQL Server 的最大服务器内存设置为 180 GB。

在 180 GB 中，SQL Server 通常使用：

• 数据库缓存内存 - ~ 140-150 GB
• 计划缓存 - ~ 10 GB
• 被盗的服务器内存：~ 30 GB
• 可用内存：~ 9 GB
• 授予的工作空间内存：这通常相当低，峰值可能为 0.5-1 GB

缓冲区高速缓存命中率 - 始终徘徊在 99.9% 以上。
页面预期寿命是相当高的数字。

数据库数据文件的总大小 - 650 GB。
数据增长速度约为每天 500-1500 MB（但是！较旧的数据每 6-8 个月就会删除一次，因此基本上数据文件的增长速度要慢得多）。

问题

需要将SQL Server迁移到另一台机器。当 SQL Server 2022 发布时，就以它为目标。

它是混合 OLTP 和 OLAP 类型的工作负载，许多应用程序使用相同的数据库；大部分 RAM 被缓存的数据库页面使用，这意味着 SQL Server 不必一直从磁盘读取它。

感觉新机器 128 GB 就足够了，最大服务器内存设置为 ~ 110 GB，为操作系统留下 18-13 GB。

目标服务器将位于 Azure VM 中，您无法独立地扩展 …

我的目标是使用扩展事件跟踪单个存储过程的执行

在事件选择列表中，我可以找到以下内容：

sql_statement_completed
sql_batch_completed
sp_statement_completed
rpc_completed

我应该选择哪一个？我只需要一个不同的执行计数

要授予用户运行的能力Bulk Insert T-SQL command，需要授予登录/用户：

1. BULKADMIN服务器角色 - 或 -ADMINISTER BULK OPERATIONS服务器级别权限
2. 连接目标数据库
3. 插入目标表

BULKADMIN但是服务器角色和ADMINISTER BULK OPERATIONS服务器级权限有什么区别呢？

我有一项任务要更新生产表中的 500 万行，而无需长时间锁定整个表

所以，我使用了多次帮助我的方法 - 一次更新前 (N) 行，块之间的间隔为 1-N 秒

这次从一次更新前 (1000) 行开始，监视扩展事件会话中的lock_escalation事件

lock_escalation在每次更新操作期间出现，所以我开始将每个块1000 -> 500 -> 200 -> 100 -> 50行的行数降低到 1

之前（不是使用这个表，并且对于删除操作 - 不是更新），将行数降低到 200 或 100，有助于摆脱lock_escalation事件
但是这一次，即使每 1 次更新操作有 1 行，表lock_escalation仍然显示。每次更新操作的持续时间大致相同，无论是一次 1 行还是 1000 行

在我的情况下如何摆脱表锁升级？

@@TRANCOUNT 为零

扩展事件：

代码：

set nocount on

declare 
    @ChunkSize              int = 1000,                         -- count rows to remove in 1 chunk 
    @TimeBetweenChunks      char(8) = '00:00:01',               -- interval between chunks
    
    @Start                  datetime,
    @End …

让我们考虑在异步复制中有两个节点的 SQL Server AlwaysOn 群集。
有没有办法计算强制故障转移后丢失了多少数据？

我的意思是在时间方面，能够知道“我丢失了 1 小时的数据或 1 分钟”。我考虑过检查 LSN，但我不知道如何将它们转换为日期时间。