OS与Oracle

在检查客户的代码中，有时会深刻地感觉到原代码编写者在调试代码时的无奈。
这使我想起以前调试代码时的经历。一个SQL迟迟不返回结果，一小时过去了，又一小时过去了…… 于是，想了好多调优的方法，调整系统参数，为这个SQL建立很多Index，加上各种各样的Hint ……
于是，现在在代码中看到似曾相识的/*+ index(t_xx, idx_xx) */时，有时会发自内心的笑了，同时，轻巧地把里面的+号删掉了，我就让这些个hint不起作用，不强迫CBO走index了，结果当然是CBO选择了Hash Join，而不是原代码编写者指定的Nested Loop，于是，执行速度嗖一下上去了。
有另一个有趣的事情……

准备写一系列的文章，专门分析下Exadata的架构。时间真过得很快，自从Exadata问世以来，一直围绕着它做各种各样的性能测试，从V1过渡到V2。Exadata在大踏步地前进着，我总认为，这应该是一个很优秀的产品，而我也相信时间会证明这一点的。
这些文章不会有很严谨的结构，或许某天，某时发现的一个特性，一个特点，一个最佳实践，一个有意思的地方，一个令人惊讶的数据，一个令人鼓舞的图形，都会成为这一系列文章的一部分。
Flash Cache是V2里引入的一个特性，大家或许都认为Flash Cache 主要是用于OLTP场合，为OLTP提高更高的IOPS，这点当然没错，Flash Cache相比于一般磁盘，会带来上十倍的IOPS的性能提升。但即使对于DSS场合，Flash Cache也是提升性能的一个利器……

Materialized Views, 其实不是View。我觉得把它归类于Index可能还准确一些。
View在我们的印象里总是逻辑存在的。即使前面加上一个Materialized，我们只会觉得奇怪，干嘛要对View进行物化呢？
把它理解为一种特殊的Index未尝不可，况且，它与Index有一些相同点：
They consume storage space.
They must be refreshed when the data in their master tables changes.
They improve the performance of SQL execution when they are used for query rewrites.
Their existence is transparent to SQL applications and users…….