作者:啃唯
Microsoft SQL Server 是 Microsoft 推出的关系型数据库解决方案,支持企业 IT 环境中的各种事务处理、商业智能和分析应用程序。Microsoft SQL Server 是市场领先的数据库技术之一。
关系引擎: 关系引擎控制存储引擎对数据的处理,并提供 SQL Server 组件来准确确定应如何执行查询。关系引擎由三个主要部分组成。CMD 解析器(parser)主要负责识别和消除语义和语法错误,并生成查询树。优化器(Optimizer)通过消除冗余任务和寻找最优计划,确保所请求的查询响应尽可能高效。查询执行器(Query Executoe)会生成数据获取逻辑的行为。
存储引擎: 当数据由存储引擎存储时,会从存储系统(例如 SAN 或磁盘)检索数据。存储引擎中存在三种类型的文件:主文件、辅助文件和日志文件。访问方法(Access Method)负责在缓存管理器和事务日志之间交换数据。缓存管理器(Buffer Manager)缓存当前的执行计划和页。事务管理器(Transaction Manager)使用日志和锁管理器对事务进行管理。
协议层: 该层支持客户端-服务器架构以及流。协议层支持 3 种类型的客户端服务器架构:共享内存、TCP/IP、命名管道。
Microsoft SQL Server 凭借其可视化界面及其所具有的选项和工具,非常适合在关系数据库中存储所有所需的信息,以及轻松管理此类数据。
SQL Server 2022:安全、性能、可用性等加强;查询存储和智能查询处理
SQL Server 2019:数据虚拟化和大数据群集;智能数据库、智能查询;内存数据库
SQL Server 2017:图形数据库功能、动态管理视图、内存优化等
SQL Server 2016:内存OLTP、Stretch Database、集成 Hadoop 等
这里介绍监控 SQL Server 服务中常见的关键指标。
启动状态是监控 SQL Server 最基础的指标,表示 SQL Server 实例是否在正常运行,或是否重启。SQL Server 重启时,没有 commit 的数据会丢失,小概率产生错误。
监控启动的 SQL Server 实例是否符合预期,是否是业务要求的 SQL Server 版本。保证 SQL Server 的本地时间与客户端保持一致,否则数据库返回的时间有可能发生错误。
页读写: 页是 SQL Server 存储引擎磁盘管理的最小单位,为数据库中的数据文件(.mdf 或 .ndf)分配的磁盘空间可以从逻辑上划分成页(从 0 到 n 连续编号)。磁盘 I/O 操作在页级执行。也就是说,SQL Server 读取或写入所有数据页。因此对页的读写监控尤为重要。通过读写页数量的指标,可以计算出页读写的速率,从而判断 SQL Server 的执行性能。
页在缓存的停留时间: 所有数据库软件的主要设计目标之一是尽量减少磁盘 I/O,因为磁盘的读取和写入操作占用大量资源。SQL Server 在内存中生成缓存池,用于保存从数据库读取的页。我们需要监控页在缓存池的生命时长,页在缓存池中存在的时间越长,表示其被命中的可能性越大,也就是说访问该页时不需要访问磁盘。
惰性写(lazy write): 在缓冲区缓存中修改页后,不会将其立即写回磁盘;而是将其标记为“脏”。也就是说在将页物理写入磁盘之前,可以将其逻辑写入多次。在正常运行的情况下,脏页定期地刷入磁盘。而当不断地有新数据写入 SQL Server 且缓存不够用的情况下,大量的脏页会被移出缓存。
检查点(checkpoint): 当检查点发生时,SQL Server 要求刷新所有脏页至磁盘,此时 SQL Server 性能受到一定影响。我们需要监控检查点的速度,确保检查点的刷新速度达到预期。
页错误(page fault): 当页错误发生时,表示需要的页在 SQL Server 可管理的内存区域之外。当遇到页面错误时,程序执行停止并设置为等待状态。操作系统在磁盘上搜索所请求的地址。当找到该页面后,操作系统将其从磁盘复制到空闲 RAM 页面中。操作系统允许程序随后继续执行。
SQL Server 数据库引擎为数据库中的每个操作写入日志记录,其中包括执行数据修改过程时、创建或删除数据库表或索引时以及每次分配或删除页面后开始或结束 SQL 事务。日志助于在系统或硬件发生故障时将数据库恢复到特定时间点。在具有过多日志记录操作的事务性很强的系统中,SQL Server 事务日志文件将快速增长,直到达到其最大大小,从而生成错误号 9002。如果启用自动增长选项,底层磁盘驱动器将耗尽可用空间。
I/O 等待时间是一个可用于检测 I/O 问题的指标。SQL Server 将数据写入文件或是从文件读数据时,都需要等待较长的时间,表示为 I/O 等待时间,停顿时间较长表明存在 I/O 问题和磁盘活动繁忙。文件 I/O 属于数据库的关键路径,等待的时间直接反应到客户端读写 SQL Server 的延迟。
每个数据库存储的文件不同,使用的存储介质也可能不同。因此除了监控整体的 I/O 等待时间,还需要监控各个数据库的 I/O 等待时间,以便运维做出针对性的优化。
在 SQL Server 中,执行查询都依赖于建立和维护客户端连接。当需要维护 SQL Server 的可用性和高性能,监控连接是运维工作的良好入口。当 SQL Server 并发连接数过多可能会使服务器超载。当连接成功建立,不管是否使用连接,每个连接都会产生开销。
如上文所述,尽管 SQL Server 将数据存储在磁盘中,但因为缓存池的存在,对 SQL Server 内存使用情况同样要重点关注。默认情况下,SQL Server 根据可用的系统资源动态管理其内存需求。如果 SQL Server 需要更多内存,它会查询操作系统以确定是否有可用的空闲物理内存并使用可用内存。如果操作系统的可用内存不足,SQL Server 会将内存释放回操作系统,直到内存不足的情况得到缓解,或者直到 SQL Server 达到最小服务器内存限制。
一个事务是指一个客户端向 SQL Server 发送请求然后 SQL Server 做出反应的过程。客户端在发送查询请求时开始计时,收到 SQL Server 响应后结束计时,以此来计算使用的时间和完成的事务个数。一般的,评价 SQL Server 性能均以每秒钟完成的客户端请求的数量来衡量。
T-SQL (Transact-SQL) 是 Sybase 和 Microsoft 的一组编程扩展,它为结构化查询语言 ( SQL ) 添加了多种功能,包括事务控制、异常和错误处理、行处理和声明的变量。所有与 SQL Server通信的应用程序都是通过向服务器发送 T-SQL 语句来实现的。
我们默认提供了 SQL Server Overview 大盘。
在该 panel 能看到 SQL Server 运行时需要重点关注的指标,在检查 SQL Server 状态时,首先查看总览中是否有异常状态,再检查具体的指标。
内存是 SQL Server 的重点关注硬件资源,通过该 panel 能了解 SQL Server 的内存使用情况:
在以下 panel 能看到 SQL Server 的运行效率,分为以下三类:
在以下 panel 能看到 SQL Server 的运行效率:
除了监控 SQL Server 的整体 I/O 等待时间,还需要分别监控数据库的 I/O 等待时间。每个数据库存储的文件不同,存储的磁盘可能不同,需要做出针对性优化方案。
需要随时检查 SQL Server 的连接情况,防止过高的并发影响性能。
监控各数据库是否正常运行,下表定义了数据库的状态。
状态 | 定义 |
---|---|
ONLINE | 可以对数据库进行访问。即使可能尚未完成恢复的撤消阶段,主文件组仍处于在线状态。 |
OFFLINE | 数据库无法使用。数据库由于显式的用户操作而处于离线状态,并保持离线状态直至执行了其他的用户操作。例如,可能会让数据库离线以便将文件移至新的磁盘。然后,在完成移动操作后,使数据库恢复到在线状态。 |
RESTORING | 正在还原主文件组的一个或多个文件,或正在脱机还原一个或多个辅助文件。数据库不可用。 |
RECOVERING | 正在恢复数据库。恢复进程是一个暂时性状态,恢复成功后数据库将自动处于在线状态。如果恢复失败,数据库将处于可疑状态。数据库不可用。 |
RECOVERY PENDING | SQL Server 在恢复期间遇到与资源相关的错误。数据库未损坏,但是可能缺少文件,或系统资源限制可能导致无法启动数据库。数据库不可用。需要用户另外执行操作来解决问题,并让恢复进程完成。 |
SUSPECT | 至少主文件组可疑或可能已损坏。在 SQL Server 启动过程中,数据库无法恢复。数据库不可用。需要用户另外执行操作来解决问题。 |
EMERGENCY | 用户更改了数据库,并将其状态设置为 EMERGENCY。数据库处于单用户模式,可以修复或还原。数据库标记为 READ_ONLY,禁用日志记录,并仅限 sysadmin 固定服务器角色的成员访问。EMERGENCY 主要用于故障排除。例如,可以将标记为“可疑”的数据库设置为 EMERGENCY 状态。这样可以允许系统管理员对数据库进行只读访问。只有 sysadmin 固定服务器角色的成员才可以将数据库设置为 EMERGENCY 状态。 |
在对 SQL Server 进行告警规则配置时,我们推荐基于以上采集得到的指标,从以下几个方面进行告警规则的配置,分别是运行情况、资源使用情况、连接使用情况。一般来说,我们默认生成影响 SQL Server 正常使用的告警规则,优先级较高。读写速率等与业务相关的告警则由用户自定义。以下是一些推荐的告警规则。
SQL Server 停机是 0/1 阈值的告警规则。一般来说,部署在 ACK 等阿里云环境的 SQL Server 服务具有高可用的能力,当一个 SQL Server 实例停止,其他的实例会继续工作。本报警引发的原因可能是所有的 SQL Server 都无法正常启动,或者 Exporter 错误无法获取数据。我们默认设定5分钟内 SQL Server 无法恢复的告警。
SQL Server 重启是 0/1 阈值的告警规则绝大部分情况下 SQL Server 因为有日志的存在,不存在数据丢失的情况。但 SQL Server 重启之后缓存池的内容被清空,造成暂时的查询缓慢。正在执行的事务要回退给客户端,引发一系列暂时的错误,需要客户端重新发起请求。
SQL Server 对服务器内存的使用策略是用多少内存就占用多少内存,不加限制的话有可能把节点的所有内存资源占用。当内存使用率过高,SQL Server 无法正常运行。我们设定的内存使用阈值为:危险值 80%,告警值 90%。当内存使用率为 80% 时,节点高负荷运转,但一般不影响正常使用。当内存长时间使用率为 90% 时,将发出告警,提示运维资源紧缺,尽早处理。
SQL Server 发生死锁是 0/1 阈值的告警规则,不考虑死锁的个数。一系统中遇到的死锁数通常很少,而一旦发生死锁,需要终止被线程执行的当前批处理,回滚死锁牺牲品的事务,回退给客户端一个错误信息。
SQL Server 发生连接错误是 0/1 阈值的告警规则。发生该错误可能有很多原因,如:远程主机强制关闭现有连接、超时过期。操作完成之前已过的超时期限或服务器未响应、无法生成 SSPI 上下文等,需要登录数据库并检查日志查看错误原因。
SQL Server 性能差体现在事务处理速率(TPS)、批处理(T-SQL)速率低的指标上, 性能差有许多原因可能导致,我们需要联系多个指标进行排查。
检查内存使用率
检查 I/O 等待时间
检查日志增长次数
检查检查点(checkpoint)
通常我们当前的 SQL Server 都是部署在 ECS 上,因此自建 Prometheus 监控 SQL Server 时,我们将面临的典型问题有:
由于安全、组织管理等因素,用户业务通常部署在多个相互隔离的 VPC,需要在多个 VPC 内都重复、独立部署 Prometheus,导致部署和运维成本高。
每套完整的自建监控系统都需要安装并配置 Prometheus、Grafana、AlertManager 等,过程复杂、实施周期长。
缺少与阿里云 ECS 无缝集成的服务发现(ServiceDiscovery)机制,无法根据 ECS 标签来灵活定义抓取 targets。如果自行实现类似功能,则需要使用 Golang 语言开发代码(调用阿里云 ECS POP 接口)、集成进开源 Prometheus 代码、编译打包后部署,实现门槛高、过程复杂、版本升级困难。
常用开源 Grafana SQL Server 大盘不够专业,缺少结合 SQL Server 原理/特征和最佳实践进行深入优化。
缺少 SQL Server 告警指标模板,需要用户自行研究、配置告警项,工作量大。
已接入的组件会显示在集成中心页面的已安装区域。单击该组件卡片,在弹出的面板中可以查看 Targets、指标、大盘、告警、服务发现配置、Exporter 等信息。
,您可以看到目前可观测监控 Prometheus 版提供的关键告警指标。
您可以在大盘页签,单击大盘缩略图,查看对应 Grafana 大盘。
您可以面板中单击告警页签,查看 SQL Server 的 Prometheus 告警。您还可以根据业务需求新增告警规则。创建 Prometheus 告警规则的具体操作,请参见 Prometheus 告警规则 [ 2] 。
可观测监控 Prometheus 版针对产品新用户,提供三个月每日 2000w 自定义指标上报额度,点击此处立即免费试用。
参考链接:
[1] https://learn.microsoft.com/zh-cn/sql/sql-server/what-s-new-in-sql-server-2022?view=sql-server-ver16#query-store-and-intelligent-query-processing
[2] https://www.sqlshack.com/sql-server-troubleshooting-disk-i-o-problems/
[3] https://learn.microsoft.com/en-us/sql/relational-databases/performance/monitor-and-tune-for-performance?view=sql-server-ver16
[4] https://learn.microsoft.com/zh-cn/sql/relational-databases/pages-and-extents-architecture-guide?view=sql-server-ver16
[5] https://learn.microsoft.com/zh-cn/troubleshoot/sql/database-engine/performance/troubleshoot-sql-io-performance
[6] https://learn.microsoft.com/zh-cn/sql/relational-databases/memory-management-architecture-guide?view=sql-server-ver16
[7] https://www.sqlshack.com/sql-server-memory-performance-metrics-part-1-memory-pagessec-memory-page-faultssec/
[8] https://www.sqlshack.com/sql-server-transaction-log-growth-monitoring-and-management/
[9] https://blog.csdn.net/Superman7658/article/details/130799559
[10] https://learn.microsoft.com/zh-cn/sql/relational-databases/databases/database-states?view=sql-server-ver16&redirectedfrom=MSDN
相关链接:
[1] ARMS 控制台
https://account.aliyun.com/login/login.htm?oauth_callback=https%3A%2F%2Farms.console.aliyun.com%2F#/home
[2] Prometheus 告警规则https://help.aliyun.com/zh/arms/prometheus-monitoring/create-alert-rules-for-prometheus-instances#task-2121615