服务器是个普通的联想E20工作站，4G内存，但数据库也不是很大，最大的一个表才不到50W数据，数据库文件才1.29G，按理说不可能是性能不行吧？
由于曾经频繁停电，此电脑曾经无法启动，后来修复硬盘后正常了，也没在意。最近数据库发生这个问题，对磁盘进行了扫描，发现有坏道，就买了新的硬盘，然后将数据库文件从旧硬盘复制到了新硬盘，复制过程没有提示有问题，然后附加数据库，之后没什么问题，但几个小时后又出现无法连接的问题，最后似乎又是重启了几次或者说用windows账户登陆数据库管理器之后才恢复正常。因为最后一次重启后，也没试数据库是否正常，直接用windows账户登录了，然后就发现数据库是没问题的，所以不知道到底是自己恢复了，还是用windows账户登录导致数据库恢复了。我觉得应该不会有用windows账户登录就能修复数据库这种无稽的事情，但似乎这招还挺有用，至少不止一次把数据库救活了……
我自己觉得问题还是数据库的，select可以，update，insert，delete都不行，肯定是哪个地方有问题，无奈水平有限，不知道问题出在哪里啊~~~~~求助
------解决方案--------------------
我估计是你日志文件存储的磁盘满了，造成无法insert，delete，update数据的
因为这些操作都必须先写入日志
你备份一下日志，然后收缩日志文件，试试看
------解决方案--------------------
步骤：
1、换完整模式
2、做一次完整备份+日志备份
3、收缩日志文件到适当的大小
4、DBCC CHECKDB('你的库名') with physical_only
5、如果第四部没错误，重建所有表的聚集索引
6、再做一次2、3步
------解决方案--------------------
看你的情况，应该是索引坏了，给个脚本你重建所有表的索引吧，其实也可以在维护计划中做的
declare @table varchar(200)
declare cur_dbreindex cursor for select name from sysobjects
where xtype='u'
order by a.name
open cur_dbreindex
fetch next from cur_dbreindex into @table
while @@FETCH_STATUS=0
begin
exec('dbcc dbreindex ('+@table+')')
fetch next from cur_dbreindex into @table
end
close cur_dbreindex
deallocate cur_dbreindex