自动增长配置不合理导致的性能抖动
1.SQL SERVER日常运维巡检系列之-日志2.关于SQL Server镜像的一个小误区3.一切从“简”,解放IT运维人员4.CPU问题定位与解决5.数据库优化案例——————某市中心医院HIS系统6.系统隐形杀手——阻塞与等待7.SQL Server常见问题介绍及快速解决建议8.tempdb日志文件暴增分析9.数据库服务器CPU不能全部利用原因分析10.如何快速定位TempDB产生问题11.索引的重要性12.SQL语句的优化建议13.通过分析等待类型解决系统产生问题14.磁盘问题定位与解决15.内存问题定位与解决16.写给数据库运维的兄弟17.为什么带NOLOCK的查询语句还会造成阻塞18.链接服务器查询导致的阻塞19.CXPACKET等待类型分析20.为什么sleeping的会话会造成阻塞(2)21.为什么sleeping的会话会造成阻塞22.为SQL Server配置连接加密23.SQL SERVER——高可用技术概述24.数据库服务器CPU不能全部利用原因分析25.管理工具造成的阻塞
26.自动增长配置不合理导致的性能抖动
27.Profiler导致的严重性能问题28.CPU持续100%分析并解决分析29.tempdb大量闩锁等待问题分析30.探究SQL SERVER 更改跟踪31.tempdb数据文件暴增分析32.SQL SERVER 2016 AlwaysOn 无域集群+负载均衡搭建与简测33.Moebius兼容AlwaysOn34.Moebius for SQL Server35.SQL SERVER日常运维巡检系列——数据库备份36.SQL SERVER日常运维巡检系列——结构设计37.Moebius for SQL Server38.SQL SERVER日常运维巡检系列之-数据库39.【能力提升】SQL Server常见问题介绍及快速解决建议40.CDC作业历史记录无法删除问题41.为Oracle链接服务器使用分布式事务42.大事务导致数据库恢复时间长43.SQL Server关于AlwaysOn的理解-读写分离的误区(一)44.链接服务器导致SQL Server停止响应45.简单配置Sql专家云46.SQL专家云回溯某时间段内的阻塞47.SQL专家云快速解决阻塞48.SQL专家云汇总低效的SQL语句49.数据库优化案例—某市中心医院HIS系统50.细说数据库协作运维51.医院核心数据库一体化建设实践52.【能力提升】SQL Server常见问题介绍及快速解决建议53.Moebius数据库多活集群54.30分钟带你熟练性能优化的那点儿事儿(案例说明)55.SQL Server底层架构技术对比56.Moebius兼容AlwaysOn57.透过等待看数据库58.数据库自动收缩造成的阻塞59.CPU持续100%分析并解决背景
客户收到了SQL专家云告警邮件,在凌晨2点到3点之间带有资源等待的会话数暴增,请我们协助分析。
现象
登录SQL专家云,进入活动会话的趋势分析页面,下钻到2点钟一个小时内的数据,看到每分钟的等待数都在100左右,2点15分时达到200。

转到活动会话原始数据页面,看到大量会话都在等待,等待类型是LATCH_EX,等待资源是LOG_MANAGER,数据库都是MIIS****。SQL语句是INSERT、UPDATE、DELETE等写入的语句。

等待资源是LOG_MANAGER,说明数据库MIIS****的日志文件在发生变化。转到数据库空间页面,发现日志文件从2点钟开始增长,2点20时增长到90GB,3点时降到初始值(因为3点有自动收缩日志文件的计划任务)。

分析
首先要分析的是什么语句导致数据库日志文件的暴增。进入慢语句汇总页面,汇总2点钟一个小时内的慢语句, 根据执行时间、CPU消耗、读次数、写次数等指标排序, 找到一个非常大的SQL语句,2点开始执行,2点18分结束。这是迁移历史数据的作业,把当前时间一年前数据迁移到历史表(插入到历史表,然后从当前表中删除),作业很久以前被停止了,昨天才开启,因为要迁移的数据很多,导致了日志文件的暴增。

接下来分析LOG_MANAGER的等待,日志文件空间不够时就会触发自动增长,文件增长时,写入数据的会话必须等待,此时会看到Latch等待类型,增长花费的时间越长,等待的时间越长,造成的性能抖动越严重。
从2点钟开始日志文件频繁自动增长,日志文件的自动增长增量设置为10%,随着日志文件的空间越来越大,每次增加会达到几GB甚至更多,基于磁盘的性能,最少造成十几秒的性能抖动。

解决
- 修改数据文件和日志文件的自动增长为200MB。 每次自动增长很快就能完成,基本不会有性能抖动。
- 调整自动收缩日志文件的维护计划,每次收缩的时候预留10GB的空间,避免频繁的自动增长。
- 定期检查数据文件的空间,一次性增长一定的空间,避免频繁的自动增长。
其它
除非磁盘空间严重不足,否则不要收缩数据文件,详细请参考:数据库自动收缩造成的阻塞。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 分享4款.NET开源、免费、实用的商城系统
· 全程不用写代码,我用AI程序员写了一个飞机大战
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了
· 上周热点回顾(2.24-3.2)