数据库还原需要很长时间，如何优化处理

[cwdhubin]

情况是这样的，数据库是医院每天日常处理的数据文件，很大，我用backup database chisdev to disk='d:\mybackdev.dat' with init 命令每天进行数据库指定文件名备份，然后把这个备份文件还原到另外一台机器的数据库上，我通过作业来定时执行每天的备份和还原任务。前一个星期每天的备份与还原都能短时间的执行成功，现在出了这样的问题，每天的备份所花时间为16分钟左右，可还原任务每天运行三个小时都无法执行完毕。各位大哥给指点一下，可能会是什么原因，数据量很大，有17G多。在线等待。

[iwl]

收缩并清空日志

[vivianfdlpw]

dump transaction xiaokang with no_log
========>
xiaokang..........

[tian790317]

第一，清理日志文件
第二: 升级电脑硬件;
第三: 如果是查询慢1就要建素印优化数据库了

[cwdhubin]

对了，我还原用的语句是这样的，
alter database chisdev
set offline
restore database chisdev from disk='d:\mybackdev.dat'（路径可以修改）
alter database chisdev
set online

[wgsasd311]

我以前也碰到过类似情况，你日志文件太大了，你可以清空日志文件再操作就行了。
dump transaction xiaokang with no_log --清空日志文件
然后到企业管理器里再收缩数据库操作就行了。

[缪军]

同意一楼，收缩并清空日志

[zjcxc]

备份语句会自动清空日志,只是不会收缩日志文件大小.

所以你应该把收缩日志文件大小的语句加入备份处理语句的后面,这样每次备分后都可以压缩日志文件.

也可以用SQL语句来完成
--收缩数据库
DBCC SHRINKDATABASE(库名)

--收缩指定数据文件,1是文件号,可以通过这个语句查询到:select * from sysfiles
DBCC SHRINKFILE(1)

[zjcxc]

主要原因是随着数据的增长,数据库越来越大,对应的恢复时间也越来越长.

其实楼主是采用完全备份/恢复,可以直接在恢复前删除数据库. 这样不用 set off/on line

[zjcxc]

可以考虑采用日志传送的功能来实现,这样每次只需要处理上次处理后的事务日志部分的数据就行了.

具体的参考:
SQL Server 2000之日志传送功能 DigJim（原作）

具体的配置方法,常见错误和启用备用服务器的方法参考:
http://blog.csdn.net/digjim/category/12527.aspx

[缪军]

呵呵，看来我是班门弄斧了，
冲着楼上的答复，我明天去书店
买一本你出的SQL书，同志们学习学习

[wgsasd311]

哇塞。学习：)