BackUp of SQL Server

大家好，很长时间没写东西了，最近在浩方干星际，真是输的连妈都不认，算了，还是回来搞数据库有前途一点，起码在这里我还能勉强找到那么点自信！！！
做备份就像买保险一样，你可以不做，每天提心吊胆的过日子，你也可以做，让系统运行的通常无阻，有顽强的再生能力，同时大家也会忽略你的存在，总是要出下乱子，然后你再来扮演下救世主，这样大家才会知道你的存在是有价值的，你的工资应该是×××的，所以个人感觉做备份是件不大讨好的事！！！
MICROSOFT SQL SERVER的备份机制比SYBASE的真是强大的好多，首先sybase不支持数据库的部分恢复，SQL SERVER的文件与文件组备份很好的实现了这一点，sybase对于错误删除记录的操作显得有点力不从心，因为load tran不支持指定时间点或命名事务，sybase也不存在恢复模型，这样对于不同企业间恢复机制的确定没有一个直观的尺度.我会在下面的文字中逐个说明SQL SERVER的这些优点(也许是下篇文章)
恢复模型：
SQL SERVER有3个恢复模型，简单恢复，完全恢复和大容量日志恢复，每个模型各有自己的特点，也适用于不同的企业备份需求，模型之间可以相互切换，这也是个比较容易出问题的地方
简单恢复：
就像其名字一样，这种恢复模型是最简单的，他只支持数据库完整备份和差异备份，另外对于节省日志文件空间也有很好的支持，因为在检查点处会自动截断日志，所以日志文件几乎不会增长，但提交较大的事务时情况令当别论，由于备份能力有限，其风险指数也是很高的，如果数据库损坏，只能恢复到上次完整备份或最后一次差异备份，对于后面的事务处理就无能为力了,准确一点应该是非活动的事务日志都被删除了
     
大容量日志恢复：
这个模型很像后面将提到的完全恢复，但还是有很多不同，他支持数据库完整，差异和日志备份，对于诸如SELECT INTO，BULK INSERT,BCP等操作大容量的日志操作提供了性能上的优化，在完全恢复模式下，日志会记录上述操作的具体细节，而本模式中只会在日志中记载有这么一回事，具体细节忽略不计，这样存储速度就有很大提高，也节约了日志空间，问题也就出现了，由于日志记录中包含有忽略细节的最小日志更改，所以大容量恢复模型不支持具体时间点的恢复，也就是说不能在restore log中指定stopat子句，下面是操作和出错信息
/*大容量日志恢复模型
restore database chj733 from disk = 'e:chj733_dat.bck' with norecovery