这是微软社区精英项目传过来的一个案例。 我当时给了解决方案。
问题描述：
环境说明：
操作系统 win2003
数据库 SQL SERVER 2000 SP4
数据库数据大小 150GB左右
具体故障描述：
连接门户系统
提示无法连接到配置服务器
去服务器本地查看
右下角提示
数据库所在的磁盘已满
于是把SQL服务停掉
该磁盘立即有十几GB的空间释放
重新启动SQL服务
连接门户系统
依然提示无法连接配置数据库
在SQL控制台连接该数据库也是连不上
门户系统共三台服务器 ：
10.205.1.6 应用系统服务器 SharePoint
10.205.1.7 门户DB 服务器 数据库服务器 SQL 2000
10.205.1.5 DC服务器
出现该错误的是10.205.1.7 数据库服务器
错误截屏:
解决方案:
这个问题初步看起来是SharePoint_Config和tempdb数据库的日志文件占用过大空间，以致于所在磁盘空间满了。
要解决这个问题，要稍微麻烦点。因为磁盘空间已满，SqlServer服务有可能无法正常启动。先不要让应用程序连接数据库，SharePoint也不要连接数据库。试着启动SqlServer服务。看看能否启动起来。如果不能，需要腾出来一点空间来。删除一些暂时不要的软件。总之要让SqlServer服务启动起来。如果SqlServer服务能起来，就做下面的。
打开Sql Analyzer, 执行如下语句:
backup log tempdb with no_log --清除事务日志
go
backup log SharePoint_Config with no_log --清除事务日志
go
use tempdb
go
dbcc shrinkfile (tempdev, 10240) --调整tempdb的主数据文件大小为10240 MB, 可根据需要调整, 这个命令不是必须执行的。
go
dbcc shrinkfile (templog, 10240) --调整tempdb的事务日志文件大小为10240 MB, 可根据需要调整
go
--对于SharePoint_Config数据库, 通常, 它的主数据文件的logic name应该是SharePoint_Config, 它的事务日志数据文件名是SharePoint_Config_log, 也可能不是这个
--可以用 如下的命令来查它的数据文件的logic name,
use SharePoint_Config
go
select name from sysfiles;
go
知道了事务日志文件的logic name, 就写命令:
use SharePoint_Config
go
dbcc shrinkfile (SharePoint_Config_log, 10240) --调整SharePoint_Config数据库的事务日志文件大小为10240 MB, 可根据需要调整, SharePoint_Config_log应该是前面的select name from sysfiles查出来的名字。这里暂时用SharePoint_Config_log。
go
以上能解决当前的问题。
更深的问题
为什么事务日志会出现占满空间？
通常事务日志文件是这样的文件名: <数据库名>_log.ldf。它有个初始大小。比如500MB。我们对数据库的增删改都会对数据库中数据作出改动。所有的改动都被SqlServer记录到事务日志中了。随着时间的推移，事务日志文件<数据库名>_log.ldf就会慢慢被事务日志占满，当事务日志文件<数据库名>_log.ldf被占满时，SqlServer会根据某些特定策略来处理，一个常见的做法是增加事务日志文件<数据库名>_log.ldf 10%的空间。这避免了事务日志文件<数据库名>_log.ldf满而使数据库事务失败。磁盘空间不是无限的。总有一天事务日志文件<数据库名>_log.ldf就不能再增加体积了。就出现了上面的情况。
什么才是正确的做法？
1. 为事务日志文件<数据库名>_log.ldf分配固定的大小， 不能自动增长。其实针对数据库主文件<数据库名>.mdf也是如此。
2. 制作数据库监视任务，事务日志将满的时候， 自动备份事务日志来减小事务日志占用的空间.
