在创建SQLserver数据库时，用户所建立的数据存储结构中，至少包括一个容纳数据库对象的数据文件和一个事务日志文件。

      本单位有一台运行SQLserver数据库系统的远程教学服务器，由6块73.4GB热插拔硬盘，通过RAID卡配置成一台具有RAID 5级的磁盘阵列。从2002年投入运行以来，一直都保持着良好的运行状态。前不久，服务器启动时，出现了数据库初始化时间过长的现象。由于并未影响到教学使用，没有引起网管太多的注意。直到有一天教学平台的web发布出现数据库连接错误时，才发现问题的严重性。进入SQLserver企业管理器发现教学数据库subedu被标示为“置疑”，数据库物理文件subedu.mdf自行脱机，日志文件subedu.ldf的容量异常，超过了16GB。

　　这台服务器的磁盘阵列实际配置的存储空间是274GB。其中10GB指定为操作系统分区，234GB作为数据分区，用以随机存储网络课件和教学资源。远程教学系统及其数据库配置的应用系统分区总共是30GB。正常运行状态下，不超过16GB。设计有45%的预留磁盘存储空间。这种状况的出现几乎耗尽了应用系统分区的全部动态容量 ,导致整个网络教学平台陷于瘫痪。

　　原因分析

　 在创建SQLserver数据库时，用户所建立的数据存储结构中，至少包括一个容纳数据库对象的数据文件和一个事务日志文件。

　 为了维护数据库的一致性，便于进行数据库恢复，日志文件能够自动跟踪数据库的更新状态。将各种类型的事务记录写进事务日志中。通常事物日志文件大约占据数据库文件空间的10%-15%。日志文件对磁盘空间的开销采取随机模式。

　　在网络教学过程中，频繁的数据交互会形成大量的事务动态，被作为数据记录被存储在日志中，致使物理文件subedu.ldf无限制增长，数据库系统正常运行所必需的磁盘空间不能得到有效的确定与保障，是造成上述故障产生的根本原因。

　　处理方法

　　必须主动、定期地对数据库中的日志文件进行分离，保留近期具有应用动态的日志数据。对于早期随机生成的日志文件应该及时进行清理。保持数据库的存储容量相对日志文件的增长速度，具有一定的临界性。从而使数据库的运行保持正常、稳定。因此，作为日志文件的维护，定期运行下述SQL脚本也不失为一种简捷可行的、主动把握数据库运行状态的好方法。

进入查询分析器，加载下面SQL脚本，点击运行。如果SQLserver管理多个数据库时，必须注意一定要选择、正确指定待要分离日志文件的数据库名称。

　　DUMP TRANSACTION database_name WITH NO_LOG

　　BACKUP LOG database_name WITH NO_LOG

　　DBCC SHRINKDATABASE(database_name)

　　EXEC sp_dboption 'database_name', 'autoshrink', 'TRUE'

　　其中database_name是待要分离日志文件的数据库名称。

　　建议分离完日志文件后，进行数据库备份。根据笔者的经验，以十天作为周期进行比较合理。

感谢原创者的辛勤劳动，希望对您有所帮助，转载请注明原出处。

您可能对 [SQL Server] 的这些文章也感兴趣： 数据库升迁从sqlserver6.5到sqlserver2000  Sql server2000数据堵塞的测试分析 SQL Server 7.0 入门（七）  SQL SERVER实用经验技巧集 [三] SQL Server日志清除两种方法  使用Transact-SQL计算SQL Server处理器的数量 如何设置SQL Server数据库全文索引服务  在SQL Server 2005中构造模糊查找包 SQL Server 2005: 利用新的ranking函数实现高效的数据分页操作  在SQL2000查询中使用XDR的例子 SQL Server性能分析参数  SQL Server 2005 Service Broker 初探(1) SQL Server 2008的四项新特性  在SQLServer中怎么样恢复数据的存储？ SQL Server中动态和静态内存分配问题解答  使用SQL Server时最容易忽略的21个问题 修复SQLSERVER2000数据库之实战经验  使用SQL Server数据转换服务升迁Access数据库 在Linux下访问MS SQL Server数据库  一些罕见但实用的SQL Server DBCC命令

两种方法

　　对于已经出现置疑故障的数据库，可

　　以采纳二种方法进行处理。

　　第一种方法:对于条件允许的，准备一台高端计算机，磁盘容量足够大，最好不小于100GB，模拟故障服务器的系统环境，安装SQLserver。

　　1.进入企业管理器，新建数据库（必须与故障数据库同名）。还原最近的故障数据库备份；

　　2.运行上面的SQL脚本，分离事务日志。重新备份该数据库；

　　3.进入故障服务器，删除标示为”置疑”的数据库，重建同名数据库。还原第二步中已经备份好的数据库。

　　至此，全部恢复工作结束。

　　第二种方法:也可以通过以下七个步骤进行。笔者很顺利地完成了二次“置疑”数据库的修复。

　　其中database_name必须替换成真实的、待要恢复的数据库名字。

　　步骤1：创建一个新的数据库，命名为原来数据库的名字；

　　步骤2：停止SQL Server；

　　步骤3：用老数据库的MDF文件替换新数据库的相应的MDF文件，并把LDF文件删除；

　　步骤4：重新启动SQL Server服务，然后运行脚本：

　　Use Master

　　Go

　　sp_configure 'allow updates', 1

　　reconfigure with override

　　Go

　　begin tran

　　update sysdatabases set status = 32768 where name = 'database_name'

　　commit tran

　　步骤5：停止SQL然后重新启动SQL Server服务，运行脚本：

　　DBCC TRACEON(3604)

　　DBCC REBUILD_LOG('database_name','C:\Program Files\Microsoft SQL Server\MSSQL\Data\database_name_log.ldf')

　　Go

　　步骤6：停止SQL然后重新启动SQL Server服务，运行脚本：

　　use master

　　update sysdatabases set status = 8 where name = 'database_name'

　　Go

　　sp_configure 'allow updates', 0

　　reconfigure with override

　　Go

　　步骤7：运行dbcc checkdb('database_name') 检查数据库的完整性。

　　因此，在SQLserver中，事务日志的运行与维护是一个非常重要的管理环节。通过积极地运作，可以非常有效地保障数据体系的安全，但是前提必须是做好性能维护和运行动态的监控，否则会带来很多不必要的麻烦的。另外，通过对SQLserver系统参数的设定与修改，也可以实现对日志文件的管理。但是，在出现某些意外的系统状态时，有可能会还原默认参数，以致于之前的参数设置失效。