人非圣贤，孰能无过！再怎么小心翼翼，也难免有失误的时候！

       看见ldf文件太大了，于是想着缩小一下，结果一不小心将其删掉了。这下惨了，数据库连不上、打不开，SELECT、UPDATE是休想，更别提DELETE了。眼睁睁的看着数据库名字孤零零的显示在SQL Server Management Studio中，于心不忍，于是心血来潮将其删除。这样一来，无疑于雪上加霜。

       子曾日过：知之为知之，不知google之！无奈之下，google一把，相同情况出来不少，大体提供了2种方案：

1.       先分离再附加。看了一下，试了一下，发现此种情况已不适合于我，因为数据库都让我删了，只剩个数据文件。而此方案在日志文件被强行删除，数据文件还在，并且数据库未删除的情况下或许可以解决问题，有这种情况的兄弟可以一试以验证。对于俺，此种方案则弃置不用了。

相关T-SQL：

EXEC   sp_detach_db   @dbname   =   'dbName'   
 EXEC   sp_attach_single_file_db   @dbname   =   'dbName ',     
        @physname   =   'c:\Program   Files\Microsoft   SQL   Server\MSSQL\Data\'dbName.mdf'

2.       新建同名数据库，使用原数据库文件覆盖后，强行修复。步骤如下

(1). 停止数据库服务，移走原数据库文件，启动数据库服务后新建同名数据库，生成的数据库文件名要与原数据库文件名相同。并且新数据库日志文件所在目录最好与原数据库日志文件所在目录相同。

(2). 停止数据库服务，将原数据库文件覆盖新数据库文件，重启数据库服务，此时发现数据库处于不可用状态。

(3). 执行如下T-SQL：

USE MASTER  
GO  
SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE  
GO  
ALTER DATABASE DbName SET EMERGENCY  
GO 
sp_dboption 'DbName', 'single user', 'true' 
GO 
DBCC CHECKDB('DbName','REPAIR_ALLOW_DATA_LOSS')  
GO 
ALTER DATABASE DbName SET ONLINE 
GO 
sp_configure 'allow updates', 0 reconfigure with override  
GO 
sp_dboption 'DbName', 'single user', 'false' GO

其中DBCC CHECKDB('DbName','REPAIR_ALLOW_DATA_LOSS') 是关键，主要是数据校验。特别提醒的是，第二步要求新数据库日志文件与原数据库日志文件处于同一目录，就是因为这个语句，假如2者不在同一目录，并且原数据库日志文件所在目录下没有同名日志文件，则此语句执行不通过，数据库恢复也就不会成功。

此为鄙人在恢复过程中所遇到的问题，所幸根据error message加以分析后将新建的数据库日志附加copy一份到原数据库日志文件所在目录下。恢复成功后为了是数据文件与日志文件处于同一目录，将数据文件与日志文件copy到同一目录下后采用附加方式恢复。

灾后重建总结：

1.       数据库一定要建立备份任务。根据数据重要程度采取不同的备份策略。

2.       备份文件最好不要与数据库文件处于同一硬盘分区。使用数据库备份服务器最佳，当然，开发过程就免了。

3.       数据库文件与日志文件最好不要处于同一硬盘分区。

4.       在没有备份数据库的情况下，出现删除日志的情况，一定要保存好原数据库文件。进行恢复时使用原数据库文件副本进行恢复。

5.       但个mdf文件恢复数据库过程遇到的问题均有解决之道，关键在于对症下药。仔细分析error message，其实大部分无非是命令错误，或者命令执行过程错误。命令执行过程错误以路径问题最为常见。所以只有加以分析，开动脑筋，问题总会迎刃而解。

6.       切忌照葫芦画瓢，要做到具体情况具体分析，网上提供的解决方案有其适用的场景，要认真分析后，以免使用不当造成二次灾难。

7.       操作数据库一定要小心再小心，用写代码时的谨慎去操作数据库。