前2周出现一件怪异的事情。一个新版本下发到生产环境之后,某个岗位的某个页面展示异常的慢,展示达到了20秒,提交一笔页面则达到了10秒......
问题都是这样,当你过后觉得十分十分十分的简单,但是当时对你来说简直是晕头转向,一方面是行方不断追问,另一方面是业务人员电话都要打爆的质疑。在这样环境下你需要的是冷静的思考和逻辑的推断去排查问题。
在排除了服务器CPU,内存使用率瓶劲的可能之后,问题就集中在了数据库查询身上。联系业务部分和科技人员部分密码管理员打开数据库的Admin权限,使用查询事件探查器(SQL-Profiler)。再联系一个业务在本地直接用LocalHost登入获取页面,同时执行SQL-Profiler,真的有新发现:发现该页面执行某条语句去查询某张View的时候十分的慢,Duration达到了9000+,即9秒多。
这时候想起这次版本下发,针对这张View下的一个Table进行了全部删除再导入数据的操作(之前由于某些原因导致该表数据冗余,达到了原表大小的3倍,10W多条的记录,导入的数据来自和生产环境一样的SIT环境)。但是没有考虑到对Table进行索引重构。马上要求发起业务维护申请,对该View下面的2个Table进行ReIndex:
DBCC DBREINDEX (TableName1,Index_Name1)
DBCC DBREINDEX (TableName1,Index_Name2)
DBCC INDEXDEFRAG (TableName2,Index_Name3)
DBCC INDEXDEFRAG (TableName2,Index_Name4)
UPDATE STATISTICS TableName1
UPDATE STATISTICS TableName2
执行语句之后,该岗位业务恢复正常。一下是摘自网上文章:
解决碎片问题
一旦你确定表或索引有碎片问题,那么你有4个选择去解决那些问题:
1.