OS与Oracle

做了几个月的PoC终于降下帷幕，但是几个月来一直是通过SSH到服务器上工作的。

不过，见到它时还是觉得亲切，这台超大功率的家伙，这台超大发热量的家伙，这台Extreme Performance的家伙。

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.

11g里面有个很有用的新特性，对数据透视图的支持。简单而言，它可以实现宽表和窄表之间的转化。举一个例子，有一张表记录了全校所有班级所有学生的成绩(A,B,C,D,E)，现在想统计每个班级里每个分数级别对应的学生人数。

有一天，突然发现，自己的工作大部分就是对一系列数据的操作。CPU利用率，IO吞吐量，Memory利用率，SQL Elapsed Time，Wait Event History…有时是取得它们之间的平衡，如CPU, IO, Memory，有时是尽量缩少SQL的执行时间，有时则是利用它们得知某段时间系统的工作状况。于是，对数据的高效处理就成为了高效工作的瓶颈了。

这个世界上没有绝对的真理。大家都认为对的东西，在某种场合却是不适宜的。我们需要对系统资源利用情况进行综合的分析，才能最终确定一个最适宜的方式。这里并没有一个公式化的经验，证明multi_table_insert永远都是优于single table insert的。

Oracle也广泛地使用着Hash算法，Hash Partitioning就是在数据仓库应用中的一个典型例子。Hash Partitioning的一个最大的优势就是实现partition wise join.一个要考虑的问题在于hash partitions数目的选择，一个总的原则是它应该是2的乘方，如4,8,16,32,64,128…另一个要考虑的方面在于硬件的处理能力，对了，就是RAC里面的节点数，还有每个节点CPU Cores的多少。说得再具体一点，就是默认的DOP的大小(默认DOP = 2 * cpu_count * number of nodes in the cluster)。一般而言，把hash partitions的个数设置成默认的DOP是一个推荐的设置值。

如果问我Exadata给我的最深刻印象是什么？我脑海里最先浮现的莫过于每秒14GB的IO吞吐量。还有8个节点上100%的CPU使用率……

这是11g引入的一套新的自动化机制。Oracle的官方文档大而全，不过想理清楚里面的来龙去脉可不是一件容易的事情。

不过下面几点知识要点是应该记住的。
1. Oracle有三个已定义好的automated maintenance tasks.
2. 这些automated maintenace tasks在maintenance windows里得到执行。
3. 利用dbms_auto_task_admin进行配置。
4. 如何避免resource plan在进入maintenance windows时的切换。

做一件事情不是可以一蹴而就的。当你对要做的事情没有确切的理解，有的只是平时模糊的一些经验，知道有几种方式可以达成目标。如果这时就在心里谋划，哪种方式的效率高呢，是不是联合几种方式的优点效率更高？就着手实施自己假想的方案；那么，十有八九，这种做法是为时过早的……

Oracle总在不停的前进，于是，新的管理方式出现了，旧的管理方式慢慢地退出了历史舞台，与之相联系的参数也就慢慢的销声匿迹了。
这里要说的是空间管理方面。首当其冲的是Dictionary Managed Tablespaces。