昨天遇到一个乏味的问题：同一个 SQL 文在 RAC 环境多个节点的后果肯定雷同吗？
答案是：that depends
依存什么呢？当然是 SQL 文自身了。
举个简略的例子:
select *
from test T1
where T1.c1 > 'xxxx'
and rownum <= 10;
在下面的 SQL 文中，首先检索进去的是满足 ” T1.c1 > ‘xxxx’ “ 条件所有数据，而后再返回这个后果集的前 10 行。
于是，有了这样一种可能性：如果满足 ” T1.c1 > ‘xxxx’ “ 条件的两头后果集在不同 RAC 节点的排序不同的话，这个 SQL 文的后果就会不同。
这是不是 Bug 呢？当然不是。
因为 RAC 的每个节点返回的后果都是满足 SQL 文的所有的检索条件的。
也就是说，尽管返回后果不同，但没有 ” Wrong Result “ 产生。
那有哪些条件能够造成两头后果的 Sort 顺不同呢？
简略地说，如果没有应用 ” Order by “ 句指定程序，就是 SQL 文执行过程中外部解决程序，也就是数据块和数据块内 Records 的 Access 程序。如果应用了 ” Order by “ 句指定程序，那就在失去两头后果集
再进行 Sort 解决。
上面是两种以前遇到过的小例子。
第一个是 12c 导入的 ” Index BATCHED Access “，这种解决会把针对索引的单块随机拜访变为多块并行拜访，目标是改善 ” 随机 I /O “ 的影响。然而这种 I / O 会毁坏原有索引的程序拜访而带来的有序后果。使拜访后果程序变得不可预测。
第二种是 RAC 环境中，每个数据块都有 ” Master “ 节点，如果从 ” Master “ 节点以外的节点拜访这个数据块，就须要先通过 ” Cache Fusion “ 读取 ” Master “ 节点的数据块。如果在非 ” Master “ 节点发行的 SQL 文须要拜访其余节点的数据块和本人节点的数据，这就会因为外部解决的不同造成数据库 Access 程序的不同。
这个问题能够从 10046 Trace 里看出一点端倪。
--Node1
WAIT #139656782947424: nam='gc current block 2-way' ela= 124 p1=98 p2=364159 p3=1 obj#=113146 tim=10700529845367
--Node2
没有呈现下面的 Cache Fusion 待机。当初总结一下明天的话题：Rac 环境并不保障雷同的 SQL 文在不同的节点肯定失去雷同的后果。Rac 的每一个 Instance 都是独立的，只对 SQL 文负责，没有任务比照不同节点的后果。如果那样做，Rac 环境就会比单机环境还慢，没有存在的意义了。