Rac 的GES/GCS原理6（图文解释cache fusion机制6）

System Change Numbers (SCNs)
In order to track changes to data blocks, Oracle assigns a numeric identifier to each version of the block.This identifier is effectively a logical time stamp and is known as an SCN. Oracle records the SCN in the redo record header for each set of changes in the redo log. It is also included in both the undo and data block changes.
为了跟踪对数据块的改变，ORACLE 分配了一个连续的数字字符来识别数据块的每个版本。
这个标识符是一有效地逻辑时间戳，被叫做SCN。Oracle 在redo log的 头部记录了每次
改变量 SCN。它也每次都记录在undo 和数据块改动中。

When a session requests a consistent-read for a block, it specifies the block number and the SCN.
If the current version of the block contains changes applied after the requested SCN (i.e., the current
version of the block has a higher SCN), the current version will be cloned to a new buffer and
undo will be applied to roll back the changes on the data block to the requested SCN.

当一个会话需要某个数据块的一致性读镜像，它将指定数据块号以及SCN。如果当前版本的数据块
包含了在要求SCN时间点之后改动的数据（即数据块的当前版本比我们要的时间版本更高），
当前版本将被克隆到一个新的buffer中，而undo将被应用来把数据块恢复到所要求的时间点。

The SCN is also sometimes called the System Commit Number, because on OLTP systems with
short transactions, it appears that a new SCN is issued every time a transaction commits. However,
this is not entirely correct; for a long-running transaction, several SCNs may be used during the lifetime
of the transaction. In this case, changes written to the redo log for the same transaction will
have different SCNs.

SCN也叫做系统提交号，因为在OLTP系统中有很多短的事务，你会发现每次一个事务提交的时候
一个新的SCN就会产生。然而，这不是完全正确的；针对一个长时间运行的事务，它的生命
周期里可能会使用多个SCN。在这种情况下，针对同样的事务，写入redo log的记录可能会有不同
的SCN。

Therefore, the name System Change Number is more appropriate.
Changes are written to the redo log in SCN order; therefore, if the database needs to be recovered,
the redo log files can be scanned sequentially.

因此，名字系统改变号可能比系统提交号更加合适。写给redo 日志的改动 是以SCN的顺序
提交的。因此，如果这个数据库需要被修复，我们可以顺序的扫描redo 日志文件。

In a RAC environment, the SCN is used to order data block change events within each instance
and across all instances. When a RAC database is recovered, the SCN is used to synchronize the
application of changes recorded in each of the redo logs.

在RAC环境中，SCN 是用来在一个实例内或在所有的实例间 对数据块的改变事件进行排序的。
当一个RAC数据库被恢复的时候，SCN将被用来同步应用对数据库的改变，这些改变都被记录
在每个redo 日志里了。

The generation of SCNs in a RAC database is more complex. Conceptually SCNs are generated
by a single, central point similar to a sequence in a single-instance database. However, in reality,
each instance generates SCNs independently of the other databases.

在RAC数据库中,SCN的产生更加麻烦。概念化的说，SCN是被一个单独的中间点，
有点类似单实例数据库的序列产生的。然而，现实中，每个实例产生的SCN和其它数据库
是独立的。

As each instance can generate its own series of SCNs, a busy instance may generate more SCNs than a quiet instance. If this were allowed to happen, synchronizing the redo logs of the two instances during recovery processing would not be possible; SCNs must be regularly synchronized between instances to ensure that all instances are using the same SCN.
因为每个实例可以产生它自己的一系列SCN，一个繁忙的实例可能比一个安静的实例产生
更多的SCN。如果我们允许这个现象发生，在恢复过程中 对两个实例的redo 日志的同步
将变得不再可能。SCN 必须在实例间定期的同步，保证所有的实例使用同样的SCN。

Therefore, Oracle maintains the SCN globally. On Linux, by default, the SCN is maintained by
GCS using the Lamport SCN generation scheme. This scheme generates SCNs in parallel on all
instances.
因此，ORACLE在全局范围内维护SCN。在linux上，默认的SCN 将被GCS 所维护，使用
Lamport SCN 产生体系。

These generated SCNs are piggybacked on all messages passed between instances. If
a local instance receives an SCN from a remote instance that is higher than its current SCN, then the
SCN of the remote instance is used instead. Therefore, multiple instances can generate SCNs in parallel without additional messaging between the instances.

这些SCN 被实例间传输的信息所承载。如果本地实例收到了远程实例的SCN，这个SCN比
当前的SCN更高，那么远程实例的SCN将被使用。因此，多个实例的进程可以并行的产生
SCN，而不需要进程之间额外的通信。

Note that if the instances are idle, messages will still be exchanged between instances at regular
intervals to coordinate the SCN. Each change to the SCN is recorded in the redo log. Therefore, an
idle instance will always be performing a small amount of work and generating redo.
注意，如果实例是空闲状态，在实例间仍然将频繁的传输信息来协同SCN。每个SCN的改变
都记录在redo 日志中。因此，一个空闲的实例也总会做一些小量的工作并产生SCN 日志。

Consequently, it is more difficult to perform controlled tests in a RAC environment than in single-instance Oracle.
因此，在RAC 环境中 比在单节点环境中，做一个可控的测试往往更难。

Prior to Oracle 10.2, the Lamport SCN generation scheme was used when the value for the
MAX_COMMIT_PROPAGATION_DELAY parameter was larger than the default value of 7 seconds. If this
parameter was set to a value less than 7, Oracle would use the hardware clock for SCN generation.
在ORACLE 10.2之前，Lamport SCN产生机制在这种情况下使用，即 MAX_COMMIT_PROPAGATION_DELAY 参数比默认的 7秒更大。如果这个参数被修改到比
7小，oracle将使用硬件时钟机制来产生SCN。

In Oracle 10.2 and above, the broadcast on commit scheme is the default. You can verify which
SCN generation scheme is in use by checking the alert log. For example, the alert log may contain
the following:
Picked broadcast on commit scheme to generate SCNs
which indicates that the broadcast on commit SCN generation scheme is in use.

在ORACLE 10.2以及以上，broadcast on commit （提交即传播）机制是默认的机制。你可以
通过检查告警日志来确认那个SCN 产生算法被使用。比如说，报警日志可能包含下面的
信息：
Picked broadcast on commit scheme to generate SCNs.
这暗示broadcast on commit SCN generation 算法正在被使用。

In Oracle 10.2 and above, Oracle recommends that the MAX_COMMIT_PROPAGATION_DELAY parameter
is always set to 0.

在ORACLE 10.2以及以上，oracle建议设置 MAX_COMMIT_PROPAGATION_DELAY参数
为0。