数据库任意回退点的意义
数据库的任意回退可以解决数据库的逻辑错误，找回任意需要找回的数据，以保证数据库的完整和可用。
2013年10月份济南儿童医院数据表丢失，急需找回。但是几个冷备份的点数据表虽然在，但是表内的数据并不是最新的。因为这时候要找回的数据是表，且表内数据最新，这就需要恢复到这个表，而且是这个表内最新数据的那个点，这个点只有一个，是在输入数据的时候实际发生的，而不是预先设置的，因为在之前谁也不知道什么时候会出现这个故障。很显然，要记录这个点就必须事先记录所有的变化点。
数据库任意回退点和I/O任意回退时间点的区别
记录磁盘写入的任意点并不难，通过监控block块就可以做到。但是这些所有的变化点很大程度上不是应用的可用点。这个应用可以是数据库，也可以是某种特殊的文件。
另外就算是磁盘写入的I/O点，都是数据库的可用点，也肯定不是数据库的所有记录写入点。因为数据库在写入的时候会把某些操作合并成一个I/O。打个比方来说，数据库输入了100条记录，其中每5条记录合并为了一个I/O点，那就只有20个I/O回退点可以使用，而不是我们预期的100个。
而这时候我们要回退到100条中的任意某一条就无法实现了，因为只记录了20个点。对于删除操作亦是如此。
如何来测试区分数据库任意回退点和I/O任意回退时间点
首先我们进行数据库的数据模拟输入，此时要注意，数据的输入一定是没有规则的。这和数据库的种类以及数据库服务器的性能有关，性能越高，单位时间内输入的数据就会越多。有一些I/O监控厂商为了让I/O和数据库的记录点进行同步，他们在做测试的时候会对sql语句做手脚，比如加入“waitfor delay '00:00:01'”的语句，这实际上就是每延迟1秒输入一条，而I/O也以秒级监控的话，这样数据库的任意回退点和I/O的回退点就同步了。
但是在实际情况中，不可能我们的应用是每延迟1秒输入一条数据的。应用软件提供商不会这么写软件，就算这么写了，客户也不愿意。因为这是等于把数据库以及数据库服务器的性能阉割了！本来1秒钟可以处理成千上万条数据，却给限制在了1条，这种测试是不客观的，也是严重不合理的。
正确的测试应该是首先循环插入大量数据
declare @i int
set @i = 1
while @i <30000
begin
insert into test （a,b,c,d,e,f,g） values （'测试1','测试2
','测试3','测试4','测试5','测试6','测试7'）
set @i = @i + 1
end
上面的30000是指插入30000条数据，可以根据需求调整。后面的a,b,c,d,e,f,g是test表内的字段，测试1-7是赋予字段的具体内容，也可以把字段内容根据需要调长。
按照以上的语句插入后，应该至少有30000个回退点，且每个回退点都是数据库可用并且完整的。
插入测试完成以后，我们可以进行删除测试。
declare @num int
declare @datecount int
set @datecount=（select count（id） from test）
set @num=0
while
@num<@datecount
begin
delete test where id=（select top 1 id from test order by id desc ）
set
@num=@num+1
End
以上语句是将表内所有的数据倒序（正序也没有关系）逐条删除，同样也应该产生至少30000个回退点，且每个回退点都是数据库可用并且完整的。
只有按照上述的方法测试通过，才说明是满足了任意时间点回退的要求，否则都是不合理的，是解决不了用户实际问题的。
国产容灾备份软件北京和力记易科技有限公司的UPM备特佳容灾备份系统，完全满足数据库的任意时间点回退，可以经得住任何的测试。有兴趣的用户不妨一试。
