sql2005 数据库不增长 log文件一直为2M

[zhulong1111]

大家十一快乐。悲催的娃在加班。。。


我遇到一个问题请教：项目数据库是还原BAK文件。以前日志肯定不会才2M，28号的时候突然访问延迟。感觉很卡。早上到晚上越来越慢。到下午4点就重启服务器。系统下午6点才正常运行。后面日志一直才2M不增长。现有几个疑问


1.这状况是是数据库日志损坏么？损坏了。重启系统会自检么？会修护日志文件？（项目在外地。状况都是维护人员反映的。都不懂技术）
2.访问卡是否跟系统有关。类似占用100%状况。（专用10W+服务器应该不存在 系统运行了一年了 就出现这一次）
3.网络是没问题，光纤。而且当时出问题ping服务器不掉包。
4.4个客户端访问服务器都慢。客户端直接访问数据库的。

十一没别的就分多。解决了在开5贴送500分。

[shoppo0505]

看看日志文件的大小有没有限制了。
手动设置为不限制。还有就是查查磁盘空间是否够用。

[發糞塗牆]

1.这状况是是数据库日志损坏么？损坏了。重启系统会自检么？会修护日志文件？（项目在外地。状况都是维护人员反映的。都不懂技术） 2.访问卡是否跟系统有关。类似占用100%状况。（专用10W+服务器应该不存在 系统运行了一年了 就出现这一次） 3.网络是没问题，光纤。而且当时出问题ping服务器不掉包。 4.4个客户端访问服务器都慢。客户端直接访问数据库的。 回答： 1、日志损坏的话估计你数据库都运行不了，所以我觉得是没有损坏，如果真损坏了，重启也是不会自动修复的。 2、访问卡真的太多问题了，比如阻塞、磁盘碎片、索引碎片等，甚至之前有人做了什么误操作。具体要通过多种手段定位瓶颈。 3、网络有没有问题，要监控一下网络流量和性能计数器里面对网络相关的计数器。 4、如果这个情况，那问题应该出在服务器端。 下面我说说我的建议，仅供参考

[發糞塗牆]

1、ldf不增长的原因我个人觉得有： a.数据库的恢复模式，

SELECT recovery_model_desc FROM sys.databases

如果为simple，不增长也正常。 b.数据库ldf初始化大小就是2M，重启后一般会帮你初始化。 c.事务量少，并且有常规的日志备份，这个维持2M的话有点难度，但是并不是不可能的。 2、服务器卡有以下几个可能： a.日志过大，数据库维护开销大，在一些后台进程处理数据库的时候很吃力。 b.查看等待状态，

SELECT * FROM sys.dm_os_waiting_tasks ORDER BY wait_duration_ms DESC
SELECT * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC

这两个语句，看看最高的几个等待状态是什么，然后去搜索一下这几个状态代表什么，再进行优化 c.性能计数器：我这里有几篇文章你可以参考一下http://blog.csdn.net/dba_huangzj/article/details/8614817 d.统计信息，由于你是还原过来的，所以上面的统计信息可能不适用，手动更新一下统计信息。 e.丢失索引，绝大部分性能问题都是查询不优化或者丢失索引，这里有个脚本你参考一下：

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
 SELECT TOP 30
         ROUND(s.avg_total_user_cost * s.avg_user_impact * ( s.user_seeks
                                                             + s.user_scans ),
               0) AS [Total Cost] ,
         s.avg_total_user_cost * ( s.avg_user_impact / 100.0 ) * ( s.user_seeks
                                                               + s.user_scans ) AS Improvement_Measure ,
         DB_NAME() AS DatabaseName ,
         d.[statement] AS [Table Name] ,
         equality_columns ,
         inequality_columns ,
         included_columns
 FROM    sys.dm_db_missing_index_groups g
         INNER JOIN sys.dm_db_missing_index_group_stats s ON s.group_handle = g.index_group_handle
         INNER JOIN sys.dm_db_missing_index_details d ON d.index_handle = g.index_handle
 WHERE   s.avg_total_user_cost * ( s.avg_user_impact / 100.0 ) * ( s.user_seeks
                                                               + s.user_scans ) > 10
 ORDER BY [Total Cost] DESC ,
         s.avg_total_user_cost * s.avg_user_impact * ( s.user_seeks
                                                       + s.user_scans ) DESC

后续的结论需要你给出这些操作后的结果才能分析

[LongRui888]

你看看你的数据库不会设置了自动收缩把

select name,is_auto_shrink_on
from sys.databases
where name = '数据库名称'

否则的话，是不会自动就变小的呀，而且收缩时，也会导致系统变慢。

[zhulong1111]

引用 3 楼 DBA_Huangzj 的回复:

1、ldf不增长的原因我个人觉得有： a.数据库的恢复模式，

SELECT recovery_model_desc FROM sys.databases

如果为simple，不增长也正常。 b.数据库ldf初始化大小就是2M，重启后一般会帮你初始化。 c.事务量少，并且有常规的日志备份，这个维持2M的话有点难度，但是并不是不可能的。 2、服务器卡有以下几个可能： a.日志过大，数据库维护开销大，在一些后台进程处理数据库的时候很吃力。 b.查看等待状态，

SELECT * FROM sys.dm_os_waiting_tasks ORDER BY wait_duration_ms DESC
SELECT * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC

这两个语句，看看最高的几个等待状态是什么，然后去搜索一下这几个状态代表什么，再进行优化 c.性能计数器：我这里有几篇文章你可以参考一下http://blog.csdn.net/dba_huangzj/article/details/8614817 d.统计信息，由于你是还原过来的，所以上面的统计信息可能不适用，手动更新一下统计信息。 e.丢失索引，绝大部分性能问题都是查询不优化或者丢失索引，这里有个脚本你参考一下：

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
 SELECT TOP 30
         ROUND(s.avg_total_user_cost * s.avg_user_impact * ( s.user_seeks
                                                             + s.user_scans ),
               0) AS [Total Cost] ,
         s.avg_total_user_cost * ( s.avg_user_impact / 100.0 ) * ( s.user_seeks
                                                               + s.user_scans ) AS Improvement_Measure ,
         DB_NAME() AS DatabaseName ,
         d.[statement] AS [Table Name] ,
         equality_columns ,
         inequality_columns ,
         included_columns
 FROM    sys.dm_db_missing_index_groups g
         INNER JOIN sys.dm_db_missing_index_group_stats s ON s.group_handle = g.index_group_handle
         INNER JOIN sys.dm_db_missing_index_details d ON d.index_handle = g.index_handle
 WHERE   s.avg_total_user_cost * ( s.avg_user_impact / 100.0 ) * ( s.user_seeks
                                                               + s.user_scans ) > 10
 ORDER BY [Total Cost] DESC ,
         s.avg_total_user_cost * s.avg_user_impact * ( s.user_seeks
                                                       + s.user_scans ) DESC

后续的结论需要你给出这些操作后的结果才能分析

非常感谢大婶。。年底还胡去现场一次。到时候按你方法仔细检查一次。。希望能彻底找出原因

[發糞塗牆]

引用 5 楼 zhulong1111 的回复:

[quote=引用 3 楼 DBA_Huangzj 的回复:] 1、ldf不增长的原因我个人觉得有： a.数据库的恢复模式，

SELECT recovery_model_desc FROM sys.databases

如果为simple，不增长也正常。 b.数据库ldf初始化大小就是2M，重启后一般会帮你初始化。 c.事务量少，并且有常规的日志备份，这个维持2M的话有点难度，但是并不是不可能的。 2、服务器卡有以下几个可能： a.日志过大，数据库维护开销大，在一些后台进程处理数据库的时候很吃力。 b.查看等待状态，

SELECT * FROM sys.dm_os_waiting_tasks ORDER BY wait_duration_ms DESC
SELECT * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC

这两个语句，看看最高的几个等待状态是什么，然后去搜索一下这几个状态代表什么，再进行优化 c.性能计数器：我这里有几篇文章你可以参考一下http://blog.csdn.net/dba_huangzj/article/details/8614817 d.统计信息，由于你是还原过来的，所以上面的统计信息可能不适用，手动更新一下统计信息。 e.丢失索引，绝大部分性能问题都是查询不优化或者丢失索引，这里有个脚本你参考一下：

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
 SELECT TOP 30
         ROUND(s.avg_total_user_cost * s.avg_user_impact * ( s.user_seeks
                                                             + s.user_scans ),
               0) AS [Total Cost] ,
         s.avg_total_user_cost * ( s.avg_user_impact / 100.0 ) * ( s.user_seeks
                                                               + s.user_scans ) AS Improvement_Measure ,
         DB_NAME() AS DatabaseName ,
         d.[statement] AS [Table Name] ,
         equality_columns ,
         inequality_columns ,
         included_columns
 FROM    sys.dm_db_missing_index_groups g
         INNER JOIN sys.dm_db_missing_index_group_stats s ON s.group_handle = g.index_group_handle
         INNER JOIN sys.dm_db_missing_index_details d ON d.index_handle = g.index_handle
 WHERE   s.avg_total_user_cost * ( s.avg_user_impact / 100.0 ) * ( s.user_seeks
                                                               + s.user_scans ) > 10
 ORDER BY [Total Cost] DESC ,
         s.avg_total_user_cost * s.avg_user_impact * ( s.user_seeks
                                                       + s.user_scans ) DESC

后续的结论需要你给出这些操作后的结果才能分析

非常感谢大婶。。年底还胡去现场一次。到时候按你方法仔细检查一次。。希望能彻底找出原因[/quote]现成？

[發糞塗牆]

现场？年底？

[LongRui888]

数据库是否有问题，是否损坏了，这个其实数据库自己会显示的， 如果数据库有损坏，那么数据库会被sql server置为“置疑”状态。 另外，你可以通过下面的命令，来看数据库是否有问题： dbcc checkdb(数据库名称) 如果有损坏，那么在输出信息中会报错的。

[Felixzhaowenzhong]

很简单，你没有做完备。做一次完备就可以了。

[姐只会简单SQL语句]

十一的问题啊，解决了没有？