本文已参与「新人创作礼」活动．一起开启掘金创作之路。
公司客户系统突然访问提示超时,经检查发现是数据库可疑造成.
停掉SQLSERVER服务,停掉所有程序
把出问题的数据库文件及日志拷贝到其他目录进行备份.
尝试脱机,或分离等,均无效果.
在其他机器尝试还原问题数据库,提示日志文件被破坏.
在网上搜索其他帮助并求助朋友后,恢复成功,操作如下:
-------------------------备份并新建同名数据库，并替换原数据文件-----------------------------
1 把问题数据库备份后直接删除（需先备份出原数据库）
停掉SQLSERVER服务,把服务器上出问题的数据库, 假设名称为 ErrorDB的数据库文件及日志文件备份到其他目录,然后直接将其删除,把其数据库文件及日志文件也删除。（小技巧：最好放在同一个磁盘里面，把新建的数据库主文件删掉或移开，再把要恢复的数据库主文件剪切过去，这样就可以节省时间。）
2 新建同名数据库
启动SQLSERVER服务,新建同名数据库ErrorDB,文件目录和日志和原来一致
3 用备份的数据库文件替换新的数据库文件
停掉SQLSERVER服务,把备份的数据库文件替换新的数据库文件（只替换数据库文件，不替换日志文件）
启动SQLSERVER服务,打开数据库，这时数据库应该是不能访问的
-------------------设置应急模式、单用户模式、检查修复数据，取消单用户模式----------------------
4 将数据库设置为应急状态
alter database ErrorDB set emergency
执行后，为了保险起见，重新停止、开启的SQLSERVER服务
再打开数据库，已经可以看到里面的内容了，如表，视图，存储过程等
数据库名称后有紧急标志，能看到数据库结构，但无法进行备份等操作
5 将数据库设置为单用户模式
ALTER **DATABASE **ErrorDB **SET SINGLE_USER
6 对数据库进行检查修复
dbcc checkdb(tzgjdata,REPAIR_ALLOW_DATA_LOSS)
--如此操作失败，执行下一句进行数据库修复操作
dbcc checkdb(tzgjdata,REPAIR_REBUILD)
操作后，仍然停止启动SQLSERVER服务（不确定是否需要，我只是为了想无干扰查看执行后的数据库状况）
重新打开数据库,已经是正常状态了，没有应急提示了
7 取消单用户模式
ALTER DATABASE FyiCenterComData SET MULTI_USER
至此，数据库恢复完毕，对数据库进行BAK
重启网站，访问正常。
上面步骤只是着火后的救急，不知道怎样做好预防或其他更好的解决办法
触发器重命名：
exec sp_rename trig_ddsjb_insertddsjbD16, trig_ddsjb_insertddsjbD16_01
数据库表修复：
declare @i int, @val nvarchar(100)
set @i = 1
while @i <= 5397
begin
select @val = name from
(select ROW_NUMBER() over(order by name) rowid, name from sys.tables) a
where rowid = @i
if object_id(@val,N'U') is not null
begin
dbcc checktable(@val,REPAIR_ALLOW_DATA_LOSS)
dbcc checktable(@val,REPAIR_REBUILD)
end
set @i = @i + 1
end
