在Exadata上面的Retail Demo展示始于Exadata在2008年底在OOW上的发布。经过几年的发展与完善，在Oracle Real World Performance Group在全球各地所举行的各种培训活动中，Retail Demo极好的展示了Exadata各方面的卓越性能，使听众们对Exadata有着一个真实切身的体验。Retail Demo包括了众多数据仓库上的典型内容，如数据加载，增量数据加载，统计信息收集，数据验证和转换，随机查询，并发查询等等内容，里面融合着Oracle所提倡的最佳实践。

btw, 上次我在ACOUG分享的10分钟加载1TB数据的Demo即来源于此。

20分钟可以做哪些事情，下面是Retail Demo对此做的一个回答：

应广大人民群众的要求，Oracle Real World Performance Group终于推出了Retail Demo的录制视频，并共享在了youtube上面。总共分为四部分：

第一部分主要内容：
整个Demo的整体介绍，22节点实时性能监控窗口，EM监控窗口
数据仓库硬件发展趋势分析，硬件规划
1TB数据构成与HCC压缩
数据加载的特征,IO瓶颈? CPU瓶颈? 内存瓶颈？
Demo： 加载1TB 数据

第二部分主要内容：
数据压缩和分区对数据加载的影响
外部表的使用
Demo: 统计信息收集
11g的新特性:增量统计信息

第三部分主要内容：
使用服务进行增量加载
数据的有效性检查与转换
Demo：有效性检查
Demo: 数据转换

第四部分主要内容:
Demo: 随机复杂查询
数据库资源管理
Demo: 并发随机查询

在做Exadata相关的培训时，Ad-Hoc Query是经常被提及的一个词，中文的翻译应该就叫做随机查询吧，望文生义，就是随机的，不能预料到的查询。但究竟有多随机呢，一些活生生的例子可能更能说明问题。

我们组设计了一个查询，每次show出来的时候，底下总有人暗底里偷笑不止。挺好玩的一件事情。这个查询是这样的：

我们要查询在2009年5月份第一个星期在北京市的所有百货超市里最受某一类型的消费者欢迎的前十个商品，这一类型的购物者有以下的购物癖好：购物的时候不买banana。

这个查询其实是基于一个零售业系统，里面存贮着全国所有超市的交易记录，这是一个TB级的数据库。如果有人说他能通过设计索引让这个查询跑得飞快，我可真不敢相信。

这种查询是有可能的，或许某天某位业务经理就跑到你(DBA)面前，帮我查查…，多久能给我结果？你的答案会是分钟，小时，天，还是月呢？

做个类推，中国移动版的:

我们要查询在2009年5月份第一个星期在北京市最受某一类型的手机用户欢迎的前十个热线号码，这一类型的手机用户有以下的癖好：发送的短消息里面从没有出现过类似”I love you”的语句。

或者你可以针对任一个数据库系统构造出类似的ad-hoc查询语句了。

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.

而一般的View呢？

• They don’t consume storage space.
• They don’t need to be refreshed when the data in their master tables changes.
• They don’t improve the performance of SQL execution, database just maps the View to the underlying Table when executing.
• Their existence is transparent to SQL applications and users.

不过，Materialized View为什么特殊，我觉得在于它的应用场合——数据仓库。或许我们可以说，Materialized View 是专门用于数据仓库的Index。

问题在于，数据仓库场合和OLTP场合对Index的要求有哪些不同，干嘛需要一个专门的Materialized View？

数据仓库的查询一般都是”大”查询。何谓大？多表联合（n个大表join在一起），多维度分析（一长串的group by），聚合统计（avg, count, sum,rank,cube）。

数据库如何跑这种查询呢？硬件方面，用更多的CPU和硬盘；软件方面，采用数据分区，并行执行。软硬件一起提供的厂商，如Oracle的Exadata, Teradata, Netezza, 可能做到数据库软件与硬件的紧密结合，从而实现对数据的智能扫描（在IO这一层实现对不需要数据的过滤）等技术。

这种做法可以很好地应对数据仓库里一类重要的查询：随机查询。例如，某位领导突然想到了一个决策方案，开发人员必须为这种决策提供分析数据。

另一方面，如果某类“大”查询经常被执行，我们就得想办法对其进行优化了。最直接的方法就是缓存中间结果，多表连接的结果，多维度分析的结果，聚合统计的结果，对了，这就是Materialized View的用武之地了。

Materialized View缓存了中间结果，Oracle通过Query Rewrite的技术把对基表的访问转换成对Materialized View的访问。这个对性能的提高可以是成千上万倍的。

如何创建Materialized View以便让Query Rewrite用到，这也许是Materialized View里面最重要的部分，也是理解Query Rewrite如何工作的一个途径。最好的参考文献当然是Oracle的Oracle® Database Data Warehousing Guide.

以后的文章再回来看看Query Rewrite的实现。