CellCLI是Exadata上存储节点的一个命令，是管理和监控存储节点的一个重要接口。例如，可以通过它收集各种指标（metric）和警报（alert）。了解这些指标的一个好方法是通过CELLCLI命令，从中挖掘出最新的信息。

可以通过以下命令得到存储节点所支持的所有指标：

list METRICDEFINITION attributes objectType,metricType,Name,UNIT,description

稍做整理，可以得到下面的表格：

信息很丰富，对objectType做下汇总，可以得到存储节点所支持的监控类型：

• CELL
• CELL_FILESYSTEM
• CELLDISK
• FLASHCACHE
• FLASHLOG
• GRIDDISK
• HOST_INTERCONNECT
• IORM_CATEGORY
• IORM_CONSUMER_GROUP
• IORM_DATABASE

对metricType（指标类型）做下汇总，可以得到指标的不种类型：

■ Cumulative: Statistics since the metric was created.
■ Instantaneous: Values at the time the metric is collected.
■ Rate: Computed value for metric by averaging statistics over a period of time.

大家接下来关注的另一个问题可能是如何得到这些指标的值。有两种方式：

• LIST METRICCURRENT，用于显示指标的当前值
• LIST METRICHISTORY，用于显示指标过去一段时间的历史值

要注意的是，LIST METRICCURRENT不是说CellCLI会帮你发出命令去收集当前指标的值，而只是显示出刚过去一分钟系统所收集到的指标值。下面是一个例子：

CellCLI> list metriccurrent where name=’CG_IO_UTIL_LG’ and metricObjectName=’DBM.OTHER_GROUPS’ ATTRIBUTES name, collectionTime, objectType, metricObjectName, metricType, metricValue
         CG_IO_UTIL_LG   2012-05-10T05:01:58-05:00       IORM_CONSUMER_GROUP     DBM.OTHER_GROUPS     Instantaneous   0 %

CellCLI> list metriccurrent where name=’CG_IO_UTIL_LG’ and metricObjectName=’DBM.OTHER_GROUPS’ ATTRIBUTES name, collectionTime, objectType, metricObjectName, metricType, metricValue
         CG_IO_UTIL_LG   2012-05-10T05:01:58-05:00       IORM_CONSUMER_GROUP     DBM.OTHER_GROUPS     Instantaneous   0 %

CellCLI> list metriccurrent where name=’CG_IO_UTIL_LG’ and metricObjectName=’DBM.OTHER_GROUPS’ ATTRIBUTES name, collectionTime, objectType, metricObjectName, metricType, metricValue
         CG_IO_UTIL_LG   2012-05-10T05:02:58-05:00       IORM_CONSUMER_GROUP     DBM.OTHER_GROUPS     Instantaneous   0 %

所以，如果你期望当前的某个指标值已经重置或者说清零了，而通过list metriccurrent还能看到非零值，就不是什么奇怪的事情了。

如果我有这么一扇窗，那该多惬意！工作闷了，看书闷了，看看窗外，真是心旷神怡的啊。

那是到乌鲁木齐飞机上的第一份礼物。

最近半年多，我们一直在鼓捣一本书。有图有真相，它就是Expert Oracle Exadata。

Exdata是Oracle软硬件相结合的一个产品，可以说它是技术上的先驱与创新的结合，甚至可以说它代表着Oracle数据库未来的发展方向。本书的三个作者Kerry Osborne, Randy Johnson, and Tanel Põder有着丰富的现实世界Exadata实施经验，他们为你尽力掀开Exadata的神秘面纱，使你真正理解Exadata的工作机制，还有如何充分利用Exadata平台所提供的各种优势。

如在书的背面所写，你将学会：

• 安装配置Exadata的方法
• 高效移植大数据量到Exadata的方法
• 如何连接Exadata到外部系统
• 如何配置Exadata的高可用性特性，包括RAC和ASM
• 如何使用资源管理器（DBRM和IORM）支持数据库整合
• 如何利用Exdata特性（Smart Scan etc.）实施调优策略

三个作者论述的侧重点各有不同。

Kerry是OakTable的成员和Oracle ACE Director，他的blog是http://kerryosborne.oracle-guy.com。在本书中他专注于对Exadata相关特性的描述。通过大量的例子深入浅出地介绍了Exadata的主要特性，同时还大量地挖掘了各个特性后面的细节。

Randy是Enkitec公司的首席咨询顾问，在本书中具体关注Exadata的管理，包括对数据库资源管理器，配置和恢复，存储节点和计算节点的详细剖析，可以在http://blog.enkitec.com找到他的文章。

Tanel是全球Oracle社区的著名人物，同样是OakTable的成员和Oracle ACE Director。性能优化的相关章节主要由他执笔，既有全局的系统方法论的阐述，也有对每个性能指标含义的具体说明，还有对SQL，存贮节点的调优监控思路。这些论述即使在非Exadata平台也有非常大的借鉴意义。他的blog是http://blog.tanelpoder.com。

Tanel和Randy还合作编写了移植的主题，这也是充满实践性的真知灼见的一章，里面提到的方案在实施中会有很好的借鉴意义。

由三位各有所长的作者联名执笔，终于成就了这本恢宏巨作。

说了这么多，其实我前面说的鼓捣就是合作翻译这么一部大块头的巨著了。另两位合作者是Kamus和Jacky。当然，王婆卖瓜，自卖自夸。我也介绍一下Jacky和Kamus。

Kamus是云和恩墨的技术总监，同样是Oracle ACE Director，ACOUG（www.acoug.org）联合创始人。他的Blog是http://www.dbform.com。

Jacky是阿里巴巴的架构师，负责数据库性能优化与应用架构改进，主导推动了阿里巴巴数据库技术的变革历程。现致力于推动Flash存储技术在数据库领域的应用，研究软硬件结合的数据库解决方案。他的Blog是http://www.hellodb.net。

如上面所言，这是一本信息量极其丰富的书。这本即将出版的中文译著，我想它的最大的特色在于，我们不仅和原作者一起讨论校对了原版本的已有的和我们所发现的众多瑕疵，使它成为原著全球的最新版本；而且我们以译者注的方式加入了很多自己的理解，这些理解对于准确理解原著和扩展认识将是非常有帮助的。

即便如此，我还有余兴未尽的感觉，我特别想对译者注和一些可能关键点再做进一步的扩展，进一步挖掘Exadata平台后面更多规律性的东西，并把它们尽情地展现出来。这本书或许是一个载体，凭借本书的脉络，可以串起Exadata平台的所有关键点，并加入更加的实践性或理论性的东西。

这也许是我写这篇文章的另一目的，我想在后面的一系列可能的文章中分享对本书涉及主题的一些扩展思考——不管是对我负责翻译的章节，还是做为校对者对Kamus和Jacky所负责章节。希望这是精彩旅程的起点！

6年多前，只身来到上海。在火车上，用笔规划着即使到来的实习生活，带着一股青春的稚气，追求新生活的豪情壮志。那是第一次独自一人为着自己将来的生活跨出广东省，如果不算上和导师去北京验收项目的话。出发前，回了趟家，爸爸妈妈把我送到大路边，上车瞬间，我的眼睛湿润了，不自觉紧握爸爸的粗糙而温暖的手，而后上车，远去，体验着一种成长的悲壮。

上海火车站，就这样成为了到上海后的起点。倏忽间，工作后，到上海几乎成为家常便饭。外滩抑或豫园，金桥抑或外高桥，浦东、虹桥机场抑或虹桥火车站，基本上就是工作的三点一线。上海火车站，好象慢慢地从记忆中消失了一样。而突然地，当的士带着我从虹桥机场慢慢逼近上海火车站旁边所住宿的酒店时，第一次到上海火车站的记忆终于复活了。

那已经是6年光阴。6年，发生了太多的事情了。站在酒店房间的窗口边，正好可以俯视着下面的火车站，车水马龙。还记得那时在上海，对上海的地铁系统再熟悉不过，从长宁区到外滩，到张江，到莘庄，到闵行。而现在，却对上海的高架桥有进一步的接触，从内环，中环到外环。那时在火车站，一定也没有注意到在火车站及在附近酒店里频繁出现的众多的老外。每个人总有自己的生活圈及其视野，或许再过几年，眼中的上海又发生着更多的变化。其实，上海没变，变的是我自己。现实与回忆交叉，竟有一种好玩的成长的感觉。

下一个Oracle Real World Performace Group所录制的Demo视频是关于OLTP性能的。与Retail Demo对应，这个Demo内部的名字叫做Connection Demo。Retail Demo主要展现的是数据仓库的性能，而Connection Demo展现的主要是OLTP的性能。这个Demo首次出现于2010年的OOW，往事不堪回首，那段时间我刚好在Oracle总部负责这个Demo的开发工作，怀念那段与bug做斗争的日子。

这个Demo的功能比较多，录制好的视频主要有两个主题：

1. OLTP Performance – The Trouble with Parsing
这是关于Oracle 里面的no parse, soft parse 和 hard parse。

这是一个老生常谈的问题，自从有了Oracle之后。

在no parse情况下，情况很理想，响应时间1毫秒，吞吐量30,000.
在soft parse情况下，情况有点糟糕了…
在hard parse情况下，情况更糟糕了… 关于shared pool的等待事件…

另一个展示的是不使用长连接而使用短连接有什么后果。究竟频繁地执行logon -> do some stuff -> logoff会导致什么严重的后果？服务器上的SYS% CPU为何会比USER% CPU还高？

还有，EM在这三种情况下的Performance Page会有什么直观的展示？

一切尽在这个Demo中，嗯。

2. OLTP Performance  – Concurrent Mid-Tier Connections
这是一个很有趣的Demo.

有多少客户的系统连接着成千上万个数据库连接？有多少个客户把实现成32000个并发连接做为系统的需求进行设计？

过度的连接会导致什么后果？

这个Demo模拟了两个应用服务器对一个数据库服务器的连接。应用会话数为9600个，使用JDBC Connection Pool连接到数据库。

开始时，Connection Pool有2048个连接。这时你会看到一个看起来非常常见的系统。CPU很忙，系统看起来很正常，等待事件看起来很多很常见。如buffer busy waits, enq: TX – index contention, log buffer space等等。嗯，DBA开始分析这些等待事件，开始调整参数。 过年过节的时间，系统变得更不稳定，DBA们开始提心吊胆渡过每一秒钟。

这个Demo起码回答了几个问题：
如果把Connection 的个数降到1024，会有什么结果？会话的等待时间会不会变得更长？吞吐量会不会下降？
如果把Connection 的个数降到96，又会有什么结果？
还有，EM在这三种情况下的Performance Page会有什么直观的展示？

看了，保证你会很惊讶。

在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: 并发随机查询

这是7月30号在北京远洋光华中心ACOUG所组织的一次技术活动。我的分享主题是《Exadata下的数据并行加载、并行卸载及性能监控》。另一位作者是邢海捷，早在几年前，就深深地拜读了他在《Oracle数据库性能优化》对锁的深入浅出的描述。

北京还是挺有技术氛围的，自愿自觉地参加，又能办得红红火火，很成功的组织。

和Eygle和yangtingkun的一张合影（左起:Kaya, Eygle,Yangtingkun）。我觉得这张图片很有意义。

更多图片，猛击http://www.douban.com/photos/album/54076276/

下面是演讲的PPT。

当然， 给大家留下深刻印象的，其实是里面的两个Live Demo， Eygle和Yangtingkun的blog/weibo里也不约而同地也提到了（一台满配的X2-2机器）：

• 加载1TB数据，用时10分钟，全表扫描读取这些数据用时 7 秒。总数据量行数在 76 亿左右。
• 卸载1TB数据，用时17分钟，同时实现把文件压缩成gzip格式。

11g里面的DBRM(Database Resource Manager)正越来越显示其重要性。特别地，随着Exadata的流行，DBRM管理的东西越来越多，有对硬件资源，如CPU, IO资源的分配；也有对软件资源，如并行进程数，活动会话数的分配。可以预见的是，Exadata做为一个一体机，DBRM发挥的作用将越来越大，如11g里面的Instance Caging可以在CPU层次实现多个数据库系统的Isolation，IORM可以实现多个数据库系统对IO的Isolation。而系统间相互的独立也是对多个应用系统进行整合的前提。

如Exadata这种强劲的机器，如何用好它是一个很重要的问题。一方面，Oracle会尽可能地实现其易用性与自我管理性，另一方面，也需要DBA，开发者掌握驾驭它的方法与技巧，以便更好地发挥Exadata的性能。

准备花点时间，整理一下使用DBRM的基本思路，与在现实中的实际运用。DBRM，本该走进千家万户。

这是云海，有点像大海的波浪呢。

太阳刚落到与云层同一高度，经过的是一处云层比较稀疏的地方。

现在看这照片，诡异的蓝色。

而又有多少个碌碌无为的昨天从你身边飘过，不留一点痕迹。

今天的难忘，终将成为明天的财富，无论是快乐，抑或痛苦。

人生终将老去，年轻人可以老态龙钟，老年人亦可以生龙活虎。态度决定行动。

其实，我们都很年轻，虽不是八九点钟的太阳，起码也是午后一点的阳光，暴晒无比。

回归，回归。