TimesTen

 

在标准文档replication.pdf中，有一段讲了缓冲区的大小和数据持久性之间的关系，现摘录翻译如下：

 

关于日志缓冲去的大小和数据的持久化

 

一个普通的误解就是日志缓冲区的大小和可能丢失的事务之间存在着某种关系，实际上日志缓冲区的大小不会对数据的持久化有影响。

 

当DSN配置为DurableCommits=0的时候，事务在如下情况下被永久化写入磁盘：

 

Log Buffer 满的时候

 

当显式调用ttDurableCommit 或者连接中的事务配置成DurableCommits=1的时候

 

当Replication Agent发送一包数据，且Replication被配置成Transmit Durable的时候

 

当Replication Agent定时执行Durable Commit的时候

 

当DSN配置有LogFlushMethod=2，且在控制返回给应用之前，写入已经完成。

 

所以综上所述，在上述的环境下，日志缓冲区的大小对数据的持久化没有冲击。个人理解是在DurableCommits=1的情况下，没什么好说的，每次提交都是同步到磁盘，所以数据的持久化上最好，但性能很差。在DurableCommits=0的情况下，只要牵涉到其中隐藏有DurableCommits=1的情形，即可导致数据的持久化。所以在此之前的数据也就不用担心事务丢失了。

 

但如果不在上述情况下，发生断电或者其它异常，且DurableCommits=0时，肯定还是存在一定的时间窗口会导致事务的丢失的，但个人觉得和缓冲区的大小也没什么关系，按照TimesTen的架构，异步写入磁盘的过程是能做多快就做多快的，所以即使丢失，也只是丢失最后一部分没有被写入的事务。如果要做到高性能且数据零丢失的话，就只能用Replication了。单节点理论上总是存在着限制。

 

 

 

 

原文如下：

 

A common misconception among TimesTen users is that there is a relationship between the size of the log buffer and lost transactions. The size of the log buffer has no impact on persistence.
If your DSN is configured with DurableCommits=0, then transactions are written durably to disk only under the following circumstances:

When the log buffer fills up.
When a ttDurableCommit is called or when a transaction on a connection with DurableCommits=1 is committed or rolled back.
When the replication agent sends a batch of transactions to a subscriber and the master has been configured for replication with the TRANSMIT DURABLE attribute (the default).
When the replication agent periodically executes a durable commit, whether the primary store is configured with TRANSMIT DURABLE or not.
When your DSN is configured with LogFlushMethod=2, writes are written to disk before control is returned to the application.
 

The size of the log buffer has no influence on the ability of TimesTen to write data to disk under any of the circumstances listed above.