我要评论前言
由于昨晚线上服务器数据库突然访问数据缓慢，任务管理里面sql server进程爆满等等，重大事故的排查拟写解决方案。
整体思路
- 查询数据库请求连接：排查连接池是否占满
- 查询数据库请求量：排查数据是否存在反复查询
- 查询数据库阻塞语句以及执行语句：排查数据库是否存在历史sql语句阻塞以及当前执行的sql语句是否存在问题
- 查询数据库语句执行时间：排查数据库是否因为数据量过大导致的
- 定位到问题指定位置
查询数据库请求连接
select db_name(dbid) as databasename, count(*) as connectioncount from sys.sysprocesses where dbid > 0 group by dbid;
查看连接池比较正常，除了master主数据库存在大量连接，其他业务数据库正常，猜测应该是排查人员的连接池，不太确定具体原因，但是排除连接池超量的问题。
查询数据库请求量
select client_net_address as '客户端ip', count(*) as '请求次数' from sys.dm_exec_connections group by client_net_address order by count(*) desc;
通过sql语句排查是否存在大量重复数据请求量，显然并不是请求次数的问题，也就是说没有频繁的请求量，因此排除数据请求频繁的问题。
查询数据库阻塞语句以及执行语句
select top 100 dest.[text] as 'sql语句',session_id,status,start_time from sys.[dm_exec_requests] as der cross apply sys.[dm_exec_sql_text](der.[sql_handle]) as dest order by [cpu_time] desc
查询到数据库正在执行的sql语句并不存在阻塞的sql语句，发现当前在执行的sql语句比较正常，单独执行这些sql语句并不存在大量数据访问，最多六千条数据量，这个量很小，因此无法确定，但是可以确定数据库不存在问题，sql语句也比较正常。
查询数据库语句执行时间
select --top 20
total_worker_time / 1000 as [自编译以来执行所用的cpu时间总量(ms)],
total_elapsed_time/1000 as [完成执行此计划所用的总时间],
total_elapsed_time / execution_count/1000 as [平均完成执行此计划所用时间],
execution_count as [上次编译以来所执行的次数],
creation_time as [编译计划的时间],
deqs.total_worker_time / deqs.execution_count / 1000 as [平均使用cpu时间(ms)],
last_execution_time as [上次开始执行计划的时间],
total_physical_reads [编译后在执行期间所执行的物理读取总次数],
total_logical_reads/execution_count [平均逻辑读次数],
min_worker_time /1000 as [单次执行期间所用的最小cpu时间(ms)],
max_worker_time / 1000 as [单次执行期间所用的最大 cpu 时间(ms)],
substring(dest.text, deqs.statement_start_offset / 2 + 1,
(case
when deqs.statement_end_offset = -1 then
datalength(dest.text)
else deqs.statement_end_offset
end - deqs.statement_start_offset
) / 2 + 1) as [执行sql],
dest.text as [完整sql],
db_name(dest.dbid) as [数据库名称],
object_name(dest.objectid, dest.dbid) as [对象名称]
,deqs.plan_handle [查询所属的已编译计划]
from sys.dm_exec_query_stats deqs with(nolock)
cross apply sys.dm_exec_sql_text(deqs.sql_handle) as dest
where (max_worker_time / 1000)>100
--完成执行此计划所用的总时间降序
order by total_elapsed_time/1000 desc
从sql语句执行时间分析出（后补的图忽略第一个删除的操作），整体分析下来是 tb_sn 和 tb_sns 两张表耗时严重，接下来只需使用查询语句查询两张表数量即可。
问题分析与定位
查询序列号表 tb_sn
select count(*) from tb_sn 243779 条
排查不是序列号表的问题，那么就只有序列号流水表的问题啦
查询序列号流水表 tb_sns
select count(*) from tb_sns
使用该命令果然执行时间缓慢，因此可以判断是数据量太大导致的。
使用压缩存储快速查看数据量
点击 tb_sns 流水表 【右键】【存储】【管理压缩】【下一步】
流水表五千万条数据，因此可以确定序列号流水表存在数据量过多导致的，整个和序列号流水相关的程序出现访问缓慢的问题。
竟然知道问题了，和相关领导咨询是否可以删除数据，并确定删除的时限范围，确定删除 2023 年以前的所有数据，释放数据量。
首先我们备份整个数据库防止误操作，然后复制并创建与 tb_sns 的数据结构相同的表，接下来将 2023 年以前的所有数据拷贝到该表上，最后在删除 tb_sns 的 2023 年以前的所有数据。
如此操作下，我们发现删除的数据量只有十万条，显然这是不对的，总共三年不到，不可能只有怎么点数据，因此判断是不是某个时间点插入大量数据，然后我们根据去年年份查询去年的数据量：
select top 10 count(*) from tb_sns where creationdate < '2024-01-01' 571638
五十万条显然是今年数据量突然增加的，因此开始查询月时间节点产生的数据，发现三月以前都正常，数据出现在三月份，接下来开始查询每日的数据量，三月五号正常，三月六号出现五千万数据，因此问题出现在昨天的时候。
解析问题
接下来问题就好解决啦，首先根据主要数据查询事故发生节点，再通过事故发生节点咨询是否出现错误操作。
- 查询负责人该节点人员工作安排
- 根据业务确定程序是否存在逻辑判断插入问题
- 判断数据是否可以删除
以上就是sql server内存问题排查方案的详细内容，更多关于sql server内存问题的资料请关注代码网其它相关文章！
发表评论