sqlserver 2005 备份文件没法恢复

sqlserver 2005 备份文件无法恢复
备份文件将近47G，由于突然停电，后来数据库显示正在恢复。
我进行了如下的操作，停止服务，删除了数据库，之后用备份的文件进行恢复，在选择文件的时候就出现了如下错误：

只有停电之前的两个备份文件，停电之后当天的备份文件大小为0，觉得原文件出现了错误，现在的问题，停电之前的两个备份文件都无法恢复，验证那一步就过不去了。网站急着用呢，可是数据库恢复不了。其他的数据库能恢复，主要是这个数据库特别大。是文件坏了吗，还是文件太大了，如何解决呀？
[解决办法]
--#1.停电后，再启动。数据库显示正在恢复，是一种正常状态，等待事务回滚即可。楼主应该等待一段时间后再看。
--#2.删除数据库前，应该把mdf,ldf文件COPY出来，备份一下。哎
--#3.下面再说说早些的两个备份不能用的问题：你的备份是*.bak文件吧。用下面SQL还原一下试试：

--设置还原参数
declare 
@BackupFilePath nvarchar(100),   --备份文件所在路径
@NewDataName nvarchar(100), --新数据库名称
@NewMdfPath nvarchar(120), --新.Mdf数据文件存储路径
@NewLdfPath nvarchar(120)        --新.Ldf日志文件存储路径

set @BackupFilePath = 'E:\数据库备份.bak'
set @NewDataName = 'New_Databasename'--用备份新建一个数据库
set @NewMdfPath = 'D:\test\' + @NewDataName + '.mdf'  --新数据库Data路径,一定不能和其它路径重复,否则会覆盖
set @NewLdfPath = 'D:\test\' + @NewDataName + '_log.ldf'  --新数据库Log路径,一定不能和其它路径重复,否则会覆盖

--#1.查看备份文件中的逻辑文件名
restore filelistonly from disk = @BackupFilePath  --查询出备份文件中Data文件及Log文件的名称,用于Restore Database时MOVE x TO y 中的x参数

--#2.2 还原数据库(还原成一个新数据库)
restore database @NewDataName from disk = @BackupFilePath
WITH MOVE '#1中查出的mdf逻辑文件名' TO @NewMdfPath,
 MOVE '#1中查出的ldf逻辑文件名' TO @NewLdfPath

go

[解决办法]

引用:

谢谢提醒，真是有些删后悔了。正在用命令行进行恢复，没有出错。还有一个问题，就是我的数据库日志文件限制了大小，怎么还无限增大呢？现在已经740G还多，数据库文件是48个G多，怎么不让日志文件增大呢？

#1.如果你的数据库恢复模式是：完整模式，且从来不曾做过日志备份，日志文件就一直在涨，不可收缩，不可回收。
#2.虽然设置了大小，但如果遇见下面情况：完整模式且无日志备份过；有复制且未完成；有未提交的事务。则从那个最小LSN往后的日志都不会被被回收。
#3.把数据库恢复模式改成：简单模式。收缩一下日志文件，一般都可以搞定。你试试
[解决办法]
由于每个修改操作都会记日志（这个是必须的），即使设置了大小，由于不能利用旧的日志空间，就只能增长了。
[解决办法]

引用:

还有一个问题，我发现备份时间的相当长，从凌晨0时到下午15时多，另一个到16时多，备份的时间用了15个多小时，这是什么呢？是日志文件太大吗？日志文件740G还多，数据库文件是48个G多，怎么限制呢？

#1.全库备份的话，根日志文件没有关系。全库备份的原理是备份所有数据，但只备份一小部分日志（从备份开始到结束这段时间内提交的事务）
#2.数据库文件和日志文件没有限制不限制一说。但你可以把数据库的恢复模式改成：简单，使日志空间可以重用。
#3.至于为什么时间那么长，备份时看一下IO，的吞吐率，算一下48G，大概要用多长时间？

[解决办法]

引用:

通过命令行最终运行的结果,系统的内存是8G。除了扩充内存，还有其它的办法吗？

这个还真不知道。个人认为没有其它方法，如果有的话，当时开发SQL SERVER时应该把此功能加上。
[解决办法]

引用:

消息 3013，级别 16，状态 1，第 1 行
RESTORE DATABASE 正在异常终止。
消息 701，级别 17，状态 123，第 1 行
没有足够的系统内存来运行此查询。

通过命令行最终运行的结果,系统的内存是8G。除了扩充内存，还有其它的办法吗？

把BUFFERCOUNT设置为一个比较小的值看看。
http://technet.microsoft.com/zh-cn/library/ms186858.aspx
[解决办法]
did you use ssms do the restore? Have you tried to use T-SQL command to restore? Maybe T-SQL can work. 
[解决办法]

引用:

问题还在继续。找了另外一台机器，用命令行的方法进行恢复，都已经进行了将近45小时了，还在继续，请问各位高手，这正常不呀？是数据库备份文件有问题吗？还是……

45小时应该不正常，你可以用命令看恢复进度的，看一下是否还正在跑 sys.dm_exec_request
[解决办法]

引用:

问题还在继续。找了另外一台机器，用命令行的方法进行恢复，都已经进行了将近45小时了，还在继续，请问各位高手，这正常不呀？是数据库备份文件有问题吗？还是……

1.另外一台机器是PC? 建议找性能稍好,特别是磁盘读写速度.

2.数据库恢复时可加stats参数,显示恢复的进度百分比.

restore database [数据库名] 
 from disk='[备份文件]'
 with replace,stats=1

3.恢复过程中,看进程等待类型是什么? 如果有阻塞应及时排除.

select spid,blocked,lastwaittype
 from sys.sysprocesses
 where spid=[进程ID]

[解决办法]
try this,

restore database WSS_Content 
 from disk='d:\sql\WSS_Content_backup_201308270000.bak'
 with replace,stats=1

查看更多 下一篇