★★★请教关于『备份』和『恢复』数据库的问题？

[suihu]

自己想写一个『备份』和『恢复』数据库的小程序

每次都是完全备份，备份的文件名用bak + 时间戳

在备份的同时，我也存储了该文件名，供恢复时使用

================================================================================
下面是我写的『备份』和『恢复』的语句，但是有问题，不知道怎么解决，请各位帮忙看看。
================================================================================

『备份』
-------------------------------------------------------------------
alter database People set recovery bulk_logged
backup database People to disk='d:\data\bak_data_20061003105920.bak'
backup log People to disk='d:\data\bak_log_20061003105920.bak'
-------------------------------------------------------------------

『恢复』
------------------------------------------------------------------------------------
alter database People set offline with rollback immediate
restore database People from disk='d:\data\bak_data_20061003105920.bak'with norecovery
restore log People from disk='d:\data\bak_log_20061003105920.bak'with norecovery
alter database People set online with rollback immediate
------------------------------------------------------------------------------------


备份的时候没有出现错误，但恢复的时候就出现也错了，下面是恢复时的错误信息。

------------------------------------------------------------------------------------
正在回滚不合法事务。估计回滚已完成: 100%。
已处理 136 页，这些页属于数据库 'People' 的文件 'People_dat'（位于文件 1 上）。
已处理 1 页，这些页属于数据库 'People' 的文件 'People_log'（位于文件 1 上）。
RESTORE DATABASE 操作成功地处理了 137 页，花费了 1.705 秒（0.654 MB/秒）。
已处理 1 页，这些页属于数据库 'People' 的文件 'People_log'（位于文件 1 上）。
RESTORE LOG 操作成功地处理了 1 页，花费了 0.026 秒（0.137 MB/秒）。
服务器: 消息 927，级别 14，状态 2，行 4
无法打开数据库 'People'。该数据库正处于还原操作中途。
服务器: 消息 5069，级别 16，状态 1，行 4
ALTER DATABASE 语句失败。
------------------------------------------------------------------------------------

[feiyun0112]

恢复时连到master数据库

*****************************************************************************
欢迎使用CSDN论坛阅读器 : CSDN Reader(附全部源代码)
http://www.cnblogs.com/feiyun0112/archive/2006/09/20/509783.html

[suihu]

up

[suihu]

我再顶

[gahade]

use master
alter database People set offline with rollback immediate
restore database People from disk='d:\data\bak_data_20061003105920.bak'with norecovery
restore log People from disk='d:\data\bak_log_20061003105920.bak'with norecovery
alter database People set online with rollback immediate

设置People脱机是不能连在People上的.

[suihu]

感谢，我试试。

[谢良]

Ding

[allright_flash]

gahade(沙果) 说的很对阿，试试看。或者摆渡一下，有很多你想要的解决方法

[suihu]

╰⊙ō⊙╯

[oraTomSawyer]

你的SQL Server备份做好了吗？可以安心睡觉了吗？

如果你是一位DBA老手，在看完我的文章后，如果发现有错误之处，欢迎批评指正。

如果你做DBA时间不长，对数据库的备份有些担心，希望能找到一种让你放心的备份方
案，那么本文绝对适合你。

关于数据库的备份恢复原理，大家多少都比较熟悉了。但是，你目前做的数据库备份有
多可靠？你可以安心睡觉了吗？如果答案是肯定的，那就不用多花时间看下文了，如果
觉得还不够安心，总担心数据库哪一天坏了修不好，那么请接着看：

[1] 我有RAID，还需要做数据库备份吗？需要。有了RAID，万一部份磁盘损坏，可以修
复数据库，有的情况下数据库甚至可以继续使用。但是，如果哪一天，你的同事不小心
删除了一条重要的记录，怎么办？RAID是无能为力的。你需要合适的备份策略，把那条
被误删的数据恢复出来。所以有了RAID，仍需要做备份。
集群，磁盘镜像同理。
[2] 如果你只做全备份，那么受限于全备份的大小和备份时间，不可能常做。而且只有
全备份，不能将数据库恢复至某个时间点。所以，我们需要全备份+日志备份。比如每
天一个全备份，每隔1小时或若干分钟一个日志备份。说到差异备份，因为微软的差异
备份记录的是上一次全备份以来发生的变化，所以，如果数据库的改动很频繁的话，没
过多久，差异备份就会和全备份的大小接近，因此这种情况下就不合适了。因此，全备
份+日志备份的方案适合绝大多数的用户。
[3] 如果你仅在数据库本地做备份，万一磁盘损坏，或者整个服务器硬件损坏，备份也
就没了，就没法恢复数据库。因此，你需要把备份文件传送至另一个物理硬件上。大多
数用户不用磁带机，因此不考虑。一般，我们需要另一台廉价的服务器或者PC来存放数
据库的备份，来防止硬件损坏造成的备份丢失。
[4] 你可以在数据库服务器本地做完备份，然后使用某些方式将备份文件传送至备机。
你是在备份完成后就马上穿送的吗？其实可以考虑将传送备份的脚本用T-SQL语句来
写。
[5] 备份文件传送至备机后，就可以高枕无忧了吗？不。作为DBA的你还需要检查备机
上的备份文件是否能将数据库恢复至最新，如果采用日志备份，会不会因为丢失某一个
日志备份文件而导致数据库不能恢复至最新？如何检查日志备份文件之间存在断档？
[6] 为了将数据库尽可能的恢复到最新，你可能会每隔10分钟（甚至1分钟）执行一次
日志备份，那么万一数据库坏了，在恢复的时候，手动恢复成百上千个日志文件，是不
是不太现实？
[7] 如果你所在公司有很多的数据库服务器（就像我所在的公司），而且磁盘空间有限
，那么你不得不经常登录服务器来删除旧的备份文件，如果哪天忘了，或者五一十一长
假，磁盘空间用完了，就麻烦了。
[8] 数据库在备份的时候，并不会检查数据页面的完整性，如果数据页坏了，备份作业
仍会执行，而且不会报错，等到你发现数据页有错误的时候，你也很可能已经因为磁盘
空间不足，而删除了早期的备份，而此时剩下的那些备份可能都是包含损坏的数据页，
如果损坏的数据页是某个表的表头的话，那这个表你就再也没办法恢复了。
[9] 所以你需要定期执行DBCC检查，来尽早发现数据库页面的完整性。在未作完DBCC检
查之前，你不能删除旧的备份，以防止新的备份存在问题。所以，删除备份文件的工作
变的有些麻烦。
[10] 你可能知道SQL Server提供了数据库维护计划。没错，使用它可以定期做备份，
执行DBCC检查，但这一切仅限于本机操作。为了使数据库可靠，你还是需要自己把本地
备份传送至备机。

综上，你的备份做好了吗？检查了吗？删除旧的备份是不是花去你很多时间，特别是在
网络条件不好的时候？如果数据库备份文件的传送在某一时刻停止了，你多久才能发现
？公司值晚班的同事有权限检查数据库的备份情况吗？

如果有兴趣的话，可以尝试使用我的解决方案，花一点小钱，帮你解决以上所有问题，
让你安心睡觉。
本人多年从事MSSQL的管理和开发，曾在上海多个高校及培训中心讲授相关课程。对
MSSQL有较好的认识和理解，以及较丰富的工作经验，N次的将数据库从灾难中恢复出
来。
现在和朋友一起设计了一款针对MSSQL的备份恢复系统。该系统安全可靠，第一版本已
经在我目前工作的公司运行了一年，近50台MSSQL服务器，已经历了多次的数据库灾难
，每次都成功的救回了数据库。目前设计的第二版，采用第一版的核心技术，根据第一
版的使用反馈，融入了很多更可靠、管理更轻松的理念，是我本人和一些同行都感到较
为满意的一个产品。使用该产品：

[1] 你可以安心睡觉了。如果不放心的话，尽管测试，把各种可能的灾难都测试几遍，
就放心了。
[2] 可靠安全。系统会检查备机上的备份文件，分析这些文件的内部信息，并报告可以
将数据库恢复到什么时刻，如果可恢复时刻与数据库当前时刻的差达到预定义的值（比
如某一时刻起网络故障导致备份文件无法传送至备机），就会报警，这样你就有尽可能
多的时间来排除故障。
[3] 最大程度减少工作量。所有数据库服务器的备份信息和可恢复信息都集中在一台主
控制机上显示，不用逐个登录检查。系统自动执行备份，自动执行检查，自动删除旧的
备份，保证磁盘上剩下的备份文件能将数据库恢复至最新。所以，如果数据库备份正常
，你不用做任何维护操作，只需有人看着主控制机显示器的报告信息，就足够了。
[4] 万一数据库坏了，主控制机会提供给你恢复数据库所需的脚本，用于将数据库恢复
至最新/恢复至时间点/恢复成另一个数据库。你可以方便的将该脚本粘贴到备机的
Terminal服务器上执行。如果你的恢复策略中需要执行上千个日志文件的恢复，没有问
题，这些脚本都会由主控制机提供，不需要任何的改动，只需要运行就可以了。

我和公司的劳动合同马上要到期了，之后，打算暂时不找新的工作，推广我的备份恢复
系统，希望给广大的朋友提供方便的同时，自己也能得到些许回报。
相信很多高手也有自己的备份方案，但相信也有很多入门不久的朋友，需要一个可靠的
备份方案，数据库的备份恢复是个不算简单的问题，要保证可靠的话，需要投入很多的
时间和精力去学习，还可能需要一些经验的积累。有的朋友可能也不是以数据库为主，
也不打算在这方面花太多的时间，所以我的产品应该是有一定的市场的。但是我也不想
打没有准备的仗，所以在此先提出这样的想法，想听听大家的意见和建议。

[1] 有兴趣使用我介绍的这款备份恢复系统吗？
[2] 你已经找到类似的替代品了吗？收费的还是免费的？
[3] 如果该产品能满足你的需求，你愿意承担的价位是？

如果有兴趣的话，可以发送邮件至 [e-mail] 索取演示版，邮件中麻烦
回答一下上述的3个问题。谢谢！另外，本人承接企业培训项目。