虚拟列分区可能返回错误结果Virtual Column-Based Partition-Chris译客

TrackBack: http://antognini.ch/2009/02/virtual-column-based-partitioning-might-lead-to-wrong-results/

Oracle 11g(11.1.0.6 和 11.1.0.7),在虚拟列分区表里面,有许多列,当虚拟列或者源数据列排在后面时,修改数据和查询数据会产生意想不到的错误结果.
出错的情况是随机的, 比如数据被放进了错误的分区, 或者查询数据,返回错误结果

这里是测试用例:

SQL>
drop TABLE t;
CREATE TABLE t (
d1 NUMBER,
d2 NUMBER,
d3 NUMBER,
d4 NUMBER,
d5 NUMBER,
d6 NUMBER,
d7 NUMBER,
n1 NUMBER,
n2 AS (CASE n1 WHEN 1 THEN 1 WHEN 2 THEN 2 ELSE 0 END) VIRTUAL
)
PARTITION BY LIST (n2) (
PARTITION zero VALUES (0),
PARTITION one VALUES (1),
PARTITION two VALUES (2)
)
ENABLE ROW MOVEMENT;

INSERT INTO t (n1) VALUES (1);
commit;
UPDATE t SET n1 = 3;
commit;

SELECT rowid, n1, n2 FROM t PARTITION (zero);
SELECT rowid, n1, n2 FROM t PARTITION (one);

数据被放进了错误的分区.
SQL> SELECT rowid, n1, n2 FROM t PARTITION (one);

ROWID N1 N2
------------------ ---------- ----------
AAAd7XAAEAAABXCAAA 3 0

查询数据,返回错误结果
SQL> SELECT rowid, n1, n2 FROM t WHERE n2 = 1;

ROWID N1 N2
------------------ ---------- ----------
AAAd7XAAEAAABXCAAA 3 0

昨天在内港Delta酒店参加领导能力培训,南望华盛顿州,奥林匹亚山.

SQL跟踪文件里面哈希值的变化 - 启动TOP作者博客翻译

TrackBack: http://antognini.ch/2009/01/execution-plan-hash-value-in-sql-trace-files/

在征得了Christian Antognini的同意后, 木匠准备近乎实时的(near real-time)跟踪报道他的最新研究成果. 附带的好处是极大的增加了我的博客出版频率,完成年初定的每周一篇技术贴的目标.

在我理解有误的地方,欢迎各位DBA同仁给予指正. 木匠没有出钱买断Christian Antognini博客的中文翻译版权, 所以您也可以同时翻译相同的文章, 不过, 请一定指明原文的TrackBack.

我只会讲每篇的主旨和总结. 从2009年一月开始,

第一篇: SQL跟踪文件里面哈希值的变化(Execution Plan Hash Value in SQL Trace Files)

在Oracle 11.1.0.7版本, 在PARSE, EXEC 和FETCH这些行里边, 新出现了一个"plh"属性, 我猜是 Plan Hash 的缩写. plh是为了配合ACS(Adaptive cursor sharing), ACS就是根据不同的绑定变量(binding variable)产生不同的最优执行计划.

参见 http://antognini.ch/2008/12/automatic-evolution-of-sql-plan-baselines/ 第7个木匠的注释.

这里是一个SQL trace file样例,

SELECT count(pad) FROM t WHERE id < :id

PARSE #13:c=0,e=0,p=0,cr=0,cu=0, mis=0,r=0,dep=0,og=1,plh=4270555908
EXEC #13:c=0,e=0,p=0,cr=0,cu=0, mis=1,r=0,dep=0,og=1,plh=2966233522

当变量取值发生变化后,优化器决定选择一个不同的执行计划. 我们看到mis=1和plh=2966233522 出现在EXEC(执行)这一行,而且的plh数值不同于PARSE一行plh的数值 SQL优化器对游标(cursor)做了一个硬解析(hard parse), 然而PARSE部分没有硬解析.

由此改变了我们的传统认识, 不但PARSE部分会hard parse,而且EXEC部分也会hard parse.


去阿拉斯加的邮轮,在维多利亚Ogden Point港停靠.