1

我们使用时间戳来确保日志表中的条目是按顺序记录的，但我们发现了一个潜在的缺陷。例如，我们的 RAC 中有两个节点，节点时间戳相差 1000 毫秒。我们的应用服务器在 30ms 秒内插入两个日志条目。第一个插入由 Node1 提供服务，第二个由 Node2 提供服务。由于两个节点之间有 1000 毫秒的差异，时间戳可能会显示日志条目以错误的顺序出现！（我只会使用一个序列，但是出于性能原因我们的序列被缓存了......）

NTP 同步对这种情况没有帮助，因为 NTP 具有 128 毫秒的容错能力——当记录发生的频率高于此值时，这为记录乱序记录敞开了大门。

我有一种感觉，我以错误的方式看待这个问题。我的最终目标是能够检索记录日志条目的实际顺序。它不必是时间戳列。

4

3 回答 3

3

指定的Oracle 序列ORDER保证在 RAC 集群中按顺序返回数字。所以

create sequence my_seq
  start with 1
  increment by 1
  order;

现在，为了做到这一点，这意味着您将进行大量的节点间通信，以确保对序列的访问被适当地序列化。这将使这比正常序列贵得多。但是，如果您需要保证订单，这可能是您将拥有的最有效的方法。

于 2015-12-02T20:08:41.400 回答
1

请记住，行上的附加时间戳是在插入或更新时生成的，但是对数据库的实际更改发生的时间是提交发生的时间 - 这取决于事务的复杂性，第 1 行可能会在第 2 行之前插入，但之后会被提交。

在 Oracle 中，我所知道的唯一能够保证订单的节点是 Oracle 附加到事务的 SCN，并且可以通过这些 SCN 对 RAC 环境中的事务进行排序，例如 Streams 复制。

于 2015-12-02T18:30:43.187 回答
0

1000 毫秒？一秒钟，不是吗？恕我直言，很多。如果你真的需要精确时间，那么干脆放弃全球时间的想法。在日志服务器上生成时间戳并假设每个日志服务器都有自己的本地时间。如果您需要一些理论，请阅读有关兰波特时代的信息。但也许你的问题的根源在其他地方。RAC 在节点之间同步时间，它会记录一些更大的差异。

如果两个不同的连接记录了两个连续的事件，那么同一个线程是否同时使用了这两个连接？还是将这些事件传递给后台线程，然后这些线程写入数据库？即它是顺序记录还是并行记录？

于 2015-12-02T22:25:32.493 回答