‘壹’ 创建数据库的日志文件被记事本程序打来，现在无法加载到sql上了，怎么恢复被记事本打开的日志文件
1. Microsoft SQL Server->企业管理器->控制台根目录->SQL Server组->新建SQL Server 注册->可用的服务器添加->windows身份验证->在现握戚唯有SQL Server组里添加SQL Server->完成
2. 找到图标下的“数据库”选项->右键,有任务->附加数据库->选择要附加数据库的MDF文件路径->确定完成
--右键段培"数据库"
--所有任务
--附加数据库
--选仔陪择你的.mdf文件名
--确定
--如果提示没有.ldf文件,是否创建,选择"是"?
‘贰’ sql附加数据库误删除，怎么恢复
SQL Server中误删除数据的恢复本来不是件难事，从事务日志恢复即可。但是，这个恢复需要有两个前提条件：
1. 至少有一个误删除之前的数据库完全备份。
2. 数据库的恢复模式（Recovery mode）是“完整（Full）”。
针对这两个前提条件，会有三种情况：
情况一、如果这两个前提条件都存在，通过SQL语句只需三步就能恢复（参考文章），无需借助第三方工具。
a) 备份当前数握孝蔽据库的事务日志：BACKUP LOG [数据库名] TO disk= N'备份文件名' WITH NORECOVERY
b) 恢复一个误删除之前的完全备份：RESTORE DATABASE [数据库名] FROM DISK = N'完全备份段州文件名' WITH NORECOVERY, REPLACE
c) 将数据库恢复至误删除之慎雀前的时间点：RESTORE LOG [数据库] FROM DISK = N'第一步的日志备份文件名' WITH STOPAT = N'误删除之前的时间点' , RECOVERY
‘叁’ MSSQL无数据库日志文件恢复数据库方法两则
方法一
1.新建一个同名的数据库
2.再停掉sql server(注意不要分离数据库)
3.用原数据库的数据文件覆盖掉这个新建的数据库
4.再重启sql server
5.此时打开企业管理器时会出现置疑，先不管，执行下面的语句（注意修改其中的数据库名)
6.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用
数据库的脚本创建一个新的数据库,并将数据导进去就行了.
USE MASTER
GO
SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE
GO
UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的数据库名'
Go
sp_dboption '置疑的数据库名', 'single user', 'true'
Go
DBCC CHECKDB('置疑的数据库名')
Go
update sysdatabases set status =28 where name='置疑的数据库名'
Go
sp_configure 'allow updates', 0 reconfigure with override
Go
sp_dboption '置疑的数据库名', 'single user', 'false'
Go
方法二
事情的起因
昨天，系统管理员告诉我，我们一个内部应用数据库所在的磁盘空间不足了。我注意到数据库事件日志文件XXX_Data.ldf文件已经增长到了3GB，于是我决意缩小这个日志文件。经过收缩数据库等操作未果后，我犯了一个自进入行业以来的最大最愚蠢的错误：竟然误删除了这个日志文件！后来我看到所有论及数据库恢复的文章上都说道：“无论如何都要保证数据库日志文件存在，它至关重要”，甚至微软甚至有一篇KB文章讲如何只靠日志文件恢复数据库的。我真是不知道我那时候是怎么想的？！
这下子坏了！这个数据库连不上了，企业管理器在它的旁边写着“(置疑)”。而且最要命的，这个数据库从来没有备份了。我唯一找得到的是迁移半年前的另外一个数据库服务器，应用倒是能用了，但是少了许多记录、表和存储过程。真希望这只是一场噩梦！
没有效果的恢复步骤
附加数据库
_Rambo讲过被删除日志文件中不存在活动日志时，可以这么做来恢复：
1，分离被置疑的数据库，可以使用sp_detach_db
2，附加数据库，可以使用sp_attach_single_file_db
但是，很遗憾，执行之后，SQL Server质疑数据文件和日志仔搜文件不符，所以无法附加数据库数据文件。
DTS数据导出
不行，无法读取XXX数据库，DTS Wizard报告说“初始化上下文发生错误”。
紧急模式
怡红公子讲过没有日志用于恢复时，可以这么做：
1，把数据库设置为emergency mode
2，重新建立一个log文件
3，把SQL Server 重新启动一下
4，把应用数据库设置成单用户模式
5，做DBCC CHECKDB
6，如果没有什么大问题就可以把数据库状态改回去了，记得别忘了把系统早弊表的修改选项关掉
我实践了一下，把应用数据库的数据文件移走，重新建立一个同名的数据库XXX，然后停掉SQL服务，把原来的数据文件再覆盖回来。之后，按照怡红公子的步骤走。
但是，也很遗憾，除了第2步之外，其他步骤执行非常成功。可惜，重启SQL Server之后，这个应用数据库仍然是置疑！
不过，让我欣慰的是，这么做之后，倒是能够Select数据了，让我大出一口气。只不过，组件使用数据库时，报告说：“发生错误：-2147467259,未能在数据库 'XXX' 中运行 BEGIN TRANSACTION，因为该数据库处于回避恢复模式。”陆戚族
最终成功恢复的全部步骤
设置数据库为紧急模式
停掉SQL Server服务；
把应用数据库的数据文件XXX_Data.mdf移走；
重新建立一个同名的数据库XXX；
停掉SQL服务；
把原来的数据文件再覆盖回来；
运行以下语句，把该数据库设置为紧急模式；
运行“Use Master
Go
sp_configure 'allow updates', 1
reconfigure with override
Go”
执行结果：
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
已将配置选项 'allow updates' 从 0 改为 1。请运行 RECONFIGURE 语句以安装。
接着运行“update sysdatabases set status = 32768 where name = 'XXX'”
执行结果：
（所影响的行数为 1 行）
重启SQL Server服务；
运行以下语句，把应用数据库设置为Single User模式；
运行“sp_dboption 'XXX', 'single user', 'true'”
执行结果：
命令已成功完成。
做DBCC CHECKDB；
运行“DBCC CHECKDB('XXX')”
执行结果：
'XXX' 的 DBCC 结果。
'sysobjects' 的 DBCC 结果。
对象 'sysobjects' 有 273 行，这些行位于 5 页中。
'sysindexes' 的 DBCC 结果。
对象 'sysindexes' 有 202 行，这些行位于 7 页中。
'syscolumns' 的 DBCC 结果。
运行以下语句把系统表的修改选项关掉；
运行“sp_resetstatus "XXX"
go
sp_configure 'allow updates', 0
reconfigure with override
Go”
执行结果：
在 sysdatabases 中更新数据库 'XXX' 的条目之前，模式 = 0，状态 = 28（状态 suspect_bit = 0），
没有更新 sysdatabases 中的任何行，因为已正确地重置了模式和状态。没有错误，未进行任何更改。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
已将配置选项 'allow updates' 从 1 改为 0。请运行 RECONFIGURE 语句以安装。
重新建立另外一个数据库XXX.Lost；
DTS导出向导
运行DTS导出向导；
复制源选择EmergencyMode的数据库XXX，导入到XXX.Lost；
选择“在SQL Server数据库之间复制对象和数据”，试了多次，好像不行，只是复制过来了所有表结构，但是没有数据，也没有视图和存储过程，而且DTS向导最后报告复制失败；
所以最后选择“从源数据库复制表和视图”，但是后来发现，这样总是只能复制一部分表记录；
于是选择“用一条查询指定要传输的数据”，缺哪个表记录，就导哪个；
视图和存储过程是执行SQL语句添加的。
这样，XXX.Lost数据库就可以替换原来的应用数据库了
‘肆’ 我把SQL数据库日志删除了,现在恢复不了了,,怎么办啊~~急呀!!
5.把数据库设成紧急状键银态:
在SQL查询分析器中逐条执行以下语句
sp_configure 'allow'清亮消,1
reconfigure with override
update sysdatabases set status=32768 where name='kmjxc'
6.重建日志文件（请将路径换成你的数据文件路径）
其中“D:\MSSQL$PROD\Data\”为存放数据库文件的路径
“KMJXC_log.ldf”为一个新的不存在的文件，在执行以下语句时将自动建立
dbcc rebuild_log('kmjxc','D:\MSSQL$PROD\Data\KMJXC_log.ldf')
7.逐条执行以答知下语句，取消紧急模式
update sysdatabases set status=0 where name='kmjxc'
restore database kmjxc with recovery
sp_configure 'allow',0
reconfigure with override
8.重起sql server
‘伍’ SQL Server2005 附加数据库的时候报错 事务日志已满
日志文件满而造成SQL数据库无法写入文件时，可用两种方法：
一种方法：清空日志。
1．打开查询分析器，输入命令
DUMP TRANSACTION 数据库名 WITH NO_LOG
2.再打开企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件--选择日志文件--在收缩方式里选择收缩至XXM,这里会给备世出一个允许收缩到的最小M数,直接输入这个数,确定就可以了。
另一种方法有一定的风险性，因为SQL SERVER的日志文件不是即时写入数据库主文件的，如处理不判神当，会造成数据的损失。
1: 删除LOG
分离数据库 企业管理器－＞服务器－＞数据库－＞右键－＞分离数据库
2：删除LOG文件
附加数据库 企业管理器－＞服务器－＞数据库－＞右键－＞附加数据库
此法生成新的掘滚亏LOG，大小只有500多K。
注意：建议使用第一种方法。
如果以后,不想要它变大。
SQL2000下使用：
在数据库上点右键->属性->选项->故障恢复-模型-选择-简单模型。
或用SQL语句：
alter database 数据库名 set recovery simple
另外，如上图中数据库属性有两个选项，与事务日志的增长有关：
Truncate log on checkpoint
(此选项用于SQL7.0，SQL 2000中即故障恢复模型选择为简单模型)
当执行CHECKPOINT 命令时如果事务日志文件超过其大小的70% 则将其内容清除在开发数据库时时常将此选项设置为True
Auto shrink
定期对数据库进行检查当数据库文件或日志文件的未用空间超过其大小的25%时，系统将会自动缩减文件使其未用空间等于25% 当文件大小没有超过其建立时的初始大小时不会缩减文件缩减后的文件也必须大于或等于其初始大小对事务日志文件的缩减只有在对其作备份时或将Truncate log on checkpoint 选项设为True 时才能进行。
‘陆’ SQL2000数据库被置疑分离后附加报错 3456:未能恢复日志记录
靠，才5分
‘柒’ SQL Server：无日志恢复数据库
事情的起因 昨天 系统管理员告诉我 我们一个内部应用数据库所在的磁盘空间不足了 我注意到数据库事件日志文件XXX_Data ldf文件已经增长到了 GB 于是我决意缩小这个日志文件 经过收缩数据库等操作未果后 我犯了一个自进入行业以来的最大最愚蠢的错误:竟然误删除了这个日志文件!后来我看到所有论及数据库恢复的文章上都说道: 无论如何都要保证数据库日志文件存在 它至关重要 甚至微软甚至有一篇KB文章讲如何只靠日志文件恢复数据库的 我真是不知道我那时候是怎么想的?!这下子坏了!这个数据库连不上了 企业管理器在它的旁边写着 (置疑) 而且最要命的 这个数据库从来没有备份了 我唯一找得到的是迁移半年前的另外一个数据库服务器 应用倒是能用了 但是少了许多记录 表和存储过程 真希望这只是一场噩梦!数据库日志文件的误删或别的原因引起数据库日志的损坏 方法一 新睁轮建一个同名的数据库 再停掉sql server(注意不要分离数据库) 用原数据库的数据文件覆盖掉这个新建的数据库 再重启sql server 此时打开企业管理器时会出现置疑 先不管 执行下面的语句(注意修改其中的数据库名) 完成后一般就可以访问数据库中的数据了 这时 数据库本身一般还要问题 解决办法是 利用数据库的脚本创建一个新的数据库 并将数据导进去就行了 USE MASTERGOSP_CONFIGURE ALLOW UPDATES RECONFIGURE WITH OVERRIDEGOUPDATE SYSDATABASES SET STATUS = WHERE NAME= 置疑的数据库名 Gosp_dboption 置疑雀腊的数据库名 single user true GoDBCC CHECKDB( 置疑的数据库名 )Goupdate sysdatabases set status = where name= 置疑的数据库名 Gosp_configure allow updates reconfigure with overrideGosp_dboption 置疑的数据库名 single user false Go 方法二 事情的起因昨天 系统管理员告诉我 我们一个内部应用数据库所在的磁盘空间不足了 我注意到数据库事件日志文件XXX_Data ldf文件已经增长到了 GB 于是我决意缩小这个日志文件 经过收缩数据库等操作未果后 我犯了一个自进入行业以来的最大最愚蠢的错误:竟然误删除了这个日志文件!后来我看到所有论及数据库恢复的文章上都说道: 无论如何都要保证数据库日志文件存在 它至关重要 甚至微软甚至有一篇KB文章讲如何只靠日志文件恢复数据库的 我真是不知道我那时候是怎么想的?!这下子坏了!这个数据库连不上了 企业管理器在它的旁边写着 (置疑) 而且最要命的 这个数据库从来没有备份了 我唯一找得到的是迁移半年前的另外一个数据库服务器 应用倒是能用了 但是少了许多记录 表和存储过程 真希望这只是一场噩梦!没有效果的恢复步骤附加数据库_Rambo讲过被删除日志文件中不存在活动日志时 可以这么做来恢复:悉岁信 分离被置疑的数据库 可以使用sp_detach_db 附加数据库 可以使用sp_attach_single_file_db但是 很遗憾 执行之后 SQL Server质疑数据文件和日志文件不符 所以无法附加数据库数据文件 DTS数据导出不行 无法读取XXX数据库 DTS Wizard报告说 初始化上下文发生错误 紧急模式怡红公子讲过没有日志用于恢复时 可以这么做: 把数据库设置为emergency mode 重新建立一个log文件 把SQL Server 重新启动一下 把应用数据库设置成单用户模式 做DBCC CHECKDB 如果没有什么大问题就可以把数据库状态改回去了 记得别忘了把系统表的修改选项关掉我实践了一下 把应用数据库的数据文件移走 重新建立一个同名的数据库XXX 然后停掉SQL服务 把原来的数据文件再覆盖回来 之后 按照怡红公子的步骤走 但是 也很遗憾 除了第 步之外 其他步骤执行非常成功 可惜 重启SQL Server之后 这个应用数据库仍然是置疑!不过 让我欣慰的是 这么做之后 倒是能够Select数据了 让我大出一口气 只不过 组件使用数据库时 报告说: 发生错误: 未能在数据库 XXX 中运行 BEGIN TRANSACTION 因为该数据库处于回避恢复模式 最终成功恢复的全部步骤设置数据库为紧急模式停掉SQL Server服务;把应用数据库的数据文件XXX_Data mdf移走;重新建立一个同名的数据库XXX;停掉SQL服务;把原来的数据文件再覆盖回来;运行以下语句 把该数据库设置为紧急模式;运行 Use MasterGosp_configure allow updates reconfigure with overrideGo 执行结果:DBCC 执行完毕 如果 DBCC 输出了错误信息 请与系统管理员联系 已将配置选项 allow updates 从 改为 请运行 RECONFIGURE 语句以安装 接着运行 update sysdatabases set status = where name = XXX 执行结果:(所影响的行数为 行)重启SQL Server服务;运行以下语句 把应用数据库设置为Single User模式;运行 sp_dboption XXX single user true 执行结果:命令已成功完成 ü 做DBCC CHECKDB;运行 DBCC CHECKDB( XXX ) 执行结果: XXX 的 DBCC 结果 sysobjects 的 DBCC 结果 对象 sysobjects 有 行 这些行位于 页中 sysindexes 的 DBCC 结果 对象 sysindexes 有 行 这些行位于 页中 syscolumns 的 DBCC 结果 ………ü 运行以下语句把系统表的修改选项关掉;运行 sp_resetstatus XXX gosp_configure allow updates reconfigure with overrideGo 执行结果:在 sysdatabases 中更新数据库 XXX 的条目之前 模式 = 状态 = (状态 suspect_bit = ) 没有更新 sysdatabases 中的任何行 因为已正确地重置了模式和状态 没有错误 未进行任何更改 DBCC 执行完毕 如果 DBCC 输出了错误信息 请与系统管理员联系 已将配置选项 allow updates 从 改为 请运行 RECONFIGURE 语句以安装 重新建立另外一个数据库XXX Lost;DTS导出向导运行DTS导出向导;复制源选择EmergencyMode的数据库XXX 导入到XXX Lost;选择 在SQL Server数据库之间复制对象和数据 试了多次 好像不行 只是复制过来了所有表结构 但是没有数据 也没有视图和存储过程 而且DTS向导最后报告复制失败;所以最后选择 从源数据库复制表和视图 但是后来发现 这样总是只能复制一部分表记录;于是选择 用一条查询指定要传输的数据 缺哪个表记录 就导哪个;视图和存储过程是执行SQL语句添加的 维护Sql Server中表的索引在使用和创建数据库索引中经常会碰到一些问题 在这里可以采用一些另类的方法解决… 第一步:查看是否需要维护 查看扫描密度/Scan Density是否为 %declare @table_id intset @table_id=object_id( 表名 )dbcc showcontig(@table_id) 第二步:重构表索引dbcc dbreindex( 表名 pk_索引名 ) 重做第一步 如发现扫描密度/Scan Density还是小于 %则重构表的所有索引 并不一定能达 % dbcc dbreindex( 表名 ) lishixin/Article/program/SQLServer/201311/22169
‘捌’ 日志文件丢失或出错的情况下如何恢复SQL数据库
1. 新建数据库（同名）
2. 停掉数据库
3. 删除新建数据库的日志文件，用要恢复的覆盖mdf文件
4. 启动数据库服务器
5. 设置数据库允许直接操作系统表
6. 设置数据库为紧急修复模式
update sysdatabases set status=-32768 where dbid=DB_ID('dbDataHome')
7. 重建数据库日志文件
dbcc rebuild_log('dbDataHome','D:\Data\dbData_Data.LDF')
8. 验证数据库一致性（可省略）
dbcc checkdb('dbDataHome')
9．设置数据库为正常状态
exec sp_dboption 'dbDataHome','dbo use only','false'
10. 最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。