急高手指点：一个事物的长度有无限制，如果太长，恢复或者回滚的时候有无影响，能保证正常吗？

[garlic523]

急高手指点：一个事物的长度有无限制，如果太长，恢复或者回滚的时候有无影响，能保证正常吗？
能具体阐述一下 事务恢复的时候 是如何进行的吗
检查点是怎样一个概念？

[愉快的登山者]

事物的长度越长，回滚时就越需要时间，回滚的成功率可以会因此而降低。
应该将有数据关联的写数据，放到一个事务中；没有关联的要分开成两个以上的事务。
一个事务可以分成几个检测点，在检测点对有关的数据是否成功写入数据库进行检查，若没有成功，可以回滚到前面的某个事务点，而不是全部回滚。

[wanghu]

没有什么限制，事务甚至可以跨批处理。当然这样性能就大受影响了。
在提交事务时，脏页必须写入日志文件(但不一定要立即写入mdf)并确认才算提交成功。否则提交失败。

checkpoint指这样的时刻（shut server,或一定时间间隔后）：部分脏页被写入日志文件或数据文件。大体如此，具体可参见bol的"检查点和日志的活动部分"条。

[garlic523]

问：愉快的登山者
一个事务可以分成几个检测点，在检测点对有关的数据是否成功写入数据库进行检查，若没有成功，可以回滚到前面的某个事务点，而不是全部回滚。
您的意思是说：一个事物可以回滚到某个事务点，那整个事物的回滚是不完整的，
哪有意义吗，能保证数据正确完整吗

检查点的作用是什么呢

[glboy]

事务只是一种最坏情况下的保障措施，事实上，平时系统的运行可靠性都是相当高的，错误很少发生，因此，在每次事务执行之前都检查其有效性显得代价太高——绝大多数的情况下这种耗时的检查是不必要的。我们不得不想另外一种办法来提高效率。

事务存储点提供了一种机制，用于回滚部分事务。因此，我们可以不必在更新之前检查更新的有效性，而是预设一个存储点，在更新之后，如果没有出现错误，就继续执行，否则回滚到更新之前的存储点。存储点的作用就在于此。要注意的是，更新和回滚代价很大，只有在遇到错误的可能性很小，而且预先检查更新的有效性的代价相对很高的情况下，使用存储点才会非常有效。

[w_rose]

（本地而非分布式的）事务是这样操作：

1. 开始一个事务。
2. 修改（包括新增和删除）任何数据时，将原记录（或者更大范围，比如页面、表等等）加锁，然后保存要修改的结果。重复这个过程。
3. 事务提交命令则开始提交事务过程，即将保存的更改结果真正写入数据原来的位置。
4. 事务回滚命令则比较简单，将保存的数据修改计划丢弃就是了。因此此过程与事务中更新的数据的多少无关。

如果在事务未提交也未回滚的过程中，服务器崩溃了，那么服务器重新启动时自动回滚此事务。

如果此事务在回滚过程中服务器崩溃了，服务器启动时仍然回滚。

如果此事务在提交过程中服务器崩溃了，服务器启动时可以根据保存的数据更新计划再次进行提交，这样即使服务器经常宕机数据也会尽量完好地提交到数据库。这最后一点才是事务处理的“真谛”。

SQL Server某些版本为了有一个好的“性能”，而牺牲了可靠性。他将数据更新资料保存在内存中而不是硬盘上。数据库遇到意外故障时很容易丢失最后的事务中的数据。

[w_rose]

事务持续时间没有什么硬性规定。但是，我觉得最好不要将一个事务持续3秒钟以上。如果有这种情况，你需要重新考虑事务背后的业务逻辑，从而将事务拆分成许多离散执行的小事务。

比如一个零售销售系统，需要实时地从库存中减数量，并且当库存数量不够时需要立即拒绝前台的销售活动。你不要将前台整个操作作为一个事务，而可以建立一个“待销售存货”表，在前台开始登记存货销售列表时经此存货的库存一部分数量移动（就是在库存中减少）到“待销售存货”中（即增加），当前台付款时则真正从“待销售存货“总出帐，当前台放弃交易时将相应的存货移回库存。当存货被转出超过10分钟还没有被卖掉时也背后台自动移回库存。

我举这个例子用来说明业务流程是可以代替简单的数据库事务操作的，从而避免在用户是用高峰时服务器性能迅速下降。这要看你是不是一个真正的程序员，还是只是一个“只知道给数据库做备份”的数据库爱好者。

[w_rose]

我发现大多数包括很多自称数据库程序员的人，都认为事务的性能就决定于需要保存的更新计划的数量。显然这是错误的。当数据记录被锁时，所有访问磁记录的用户进程都要排队等待。而用户的查询更新动作通常要访问很多分布在数据库中不同部分的数据，因此数据库中记录锁发生碰撞的情况非常常见，因此在此及时改进一点性能也是非常有意义的。

但是关键是：不仅仅需要修改的数据，即使需要读取的数据也会被锁住，从而使用户进程停顿。

比如，一个用户的应付款余额为1万元，现在有一个结算程序将这个余额要增加5千，同时另一个结算程序要将余额增加8千，那么结果这个用户的余额是1万5千呢？还是1万8千呢？当然应该是2万3千。

真正正确的事务，在其中凡是读取过的记录都要加锁（其他用户不能读取），并不是仅仅要修改的数据才上锁。

所以对事务处理要非常谨慎，尽可能用编程的努力换得程序在高峰期的事务处理的平稳性。

多年以前我写过一个小程序，20个终端联调测试时性能完全可以。结果一使用就赶上了年度使用高峰，本来5分钟可以作完的工作这下子几个小时也做不完了。

至于那些认为有事务和没事务都没有大差别的人，我想应该改行不要再做程序员或者DBA了，否则用户丢了的钱谁赔？

[愉快的登山者]

一个事务可以分成几个检测点的情况，要根据具体情况看是否需要，简单的事务可以不用，而比较复杂的情况，可能就会用到的。