数据工人

本课程对象：
服务商售前顾问、DBA
客户IT主管、DBA

培训日期：2011年12月18日

课程大纲
————————————————–
上午 9:00～12:00 Oracle一体机产品架构
Exadata 架构介绍与冗余性测试实战
Exadata Essentials 认证考试必杀技

中午 12:00~13:00 午餐

下午 13:00～17:00 Exadata迁移最佳实践
Exadata 迁移方略 40分钟
Exadata 性能优化 160分钟
Exadata 补丁应用 40分钟
————————————————–
考虑到课程效果，一次开班仅限10人。
课程结束后，随机抽取一人赠送Exadata Essentials 认证考试券（价值 195美元 ，参考http://www.oracle.com/partners/en/knowledge-zone/database/1z1-536-exam-page-169969.html）

课程费用：
1.2011年11月25日前报名 800元人民币
2.2011年12月10日前报名 1000元人民币
3.2011年12月18日前报名 1500元人民币
4.若需报销发票，需增收10%税点。

课程要求：
1.对Oracle有一定了解，熟悉Oracle11g
2.自带笔记本电脑。

培训地点：上海市浦东新区东方路818号众城大厦16楼B座（地铁2、4、6、9号线世纪大道站12号出口）

报名请发邮件: frankat20@yahoo.com

网上有许多安装文档了，我仅熟一下我遇到的问题：
1、将oinstall写成ointall了
2、要将普通用户“注销”，搞了好久才发现在“苹果”里，否则会遇到xclock无法启动的情况
3、make命令没有，在 S.L DVD里.

其余太顺利了，啥补丁都不需要，装完就是10.2.0.4.
启动起来，还是发觉很亲切啊。

顺便再装一个SQL Developer for mac.
11g的mac版啥时候发布呢：）
lion

Exadata的补丁还是用OPatch,不过对版本有要求，至少是11.2.0.1.5 版本，目前最新是11.2.0.1.8 版本。
跟其他补丁集一样，BP也是只需要打最新版本的即可，有所不同的是，需要先做冲突检查。
一个小提醒是最好在BP出来一周以后再打（曾经在一个case上遇到最新的patch打不上去，最后原厂工程师只好不做任何解释的回退了）。所以现在可以打BP12了：）

简述步骤如下：
1.OPatch 版本确认。满足要求。

[oracle@boydb01 tmp]$ $ORACLE_HOME/OPatch/opatch version
Invoking OPatch 11.2.0.1.6

OPatch Version: 11.2.0.1.6

OPatch succeeded.
[oracle@boydb01 tmp]$

2.冲突检查。根据readme依次检查（包含GI和Database），确认没有冲突才可以继续，运气不好可能要开SR去解决问题，这次比较幸运。

———————————————
[oracle@boydb01 ~]$ /u01/app/11.2.0/grid/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /tmp/12902308/12902308
Invoking OPatch 11.2.0.1.6

Oracle Interim Patch Installer version 11.2.0.1.6
Copyright (c) 2011, Oracle Corporation. All rights reserved.

PREREQ session

Oracle Home : /u01/app/oracle/product/11.2.0/dbhome_1
Central Inventory : /u01/app/oraInventory
from : /etc/oraInst.loc
OPatch version : 11.2.0.1.6
OUI version : 11.2.0.2.0
Log file location : /u01/app/oracle/product/11.2.0/dbhome_1/cfgtoollogs/opatch/opatch2011-10-18_11-06-52AM.log

Invoking prereq “checkconflictagainstohwithdetail”

…….

未发现冲突，可继续。

3.停grid control，需要在所有节点进行。

[oracle@boydb01 ~]$ export ORACLE_UNQNAME=boydb
[oracle@boydb01 ~]$ /u01/app/oracle/product/11.2.0/dbhome_1/bin/emctl stop dbconsole
Oracle Enterprise Manager 11g Database Control Release 11.2.0.2.0
Copyright (c) 1996, 2010 Oracle Corporation. All rights reserved.

https://boydb01.boypoo.com:1158/em/console/aboutApplication

Stopping Oracle Enterprise Manager 11g Database Control …
… Stopped.

4.生成ocm response file，这个必须做，不过可以在一边做完后拷贝到其他节点。

[root@boydb01 12902308]# /u01/app/11.2.0/grid/OPatch/ocm/bin/emocmrsp
OCM Installation Response Generator 10.3.4.0.0 – Production
Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved.

Provide your email address to be informed of security issues, install and
initiate Oracle Configuration Manager. Easier for you if you use your My
Oracle Support Email address/User Name.
Visit http://www.oracle.com/support/policies.html for details.
Email address/User Name: NONE
Invalid email address.

Email address/User Name: aa@aa.com
Provide your My Oracle Support password to receive security updates via your My Oracle Support account.
Password (optional):
Unable to establish connection to Oracle Configuration Manager server.
Hostname (https://ccr.oracle.com) is unknown.

Unable to establish a network connection to Oracle. Specify the URL for an
Oracle Support Hub in this format:
http[s]://:
If you do not wish to configure OCM through an Oracle Support Hub, enter NONE
Oracle Support Hub URL: NONE

Unable to establish a network connection to Oracle. If your systems require a
proxy server for outbound Internet connections, enter the proxy server details
in this format:
[@][:]
If you want to remain uninformed of critical security issues in your
configuration, enter NONE
Proxy specification: NONE

The OCM configuration response file (ocm.rsp) was successfully created.

5.在每个节点上依次打Grid Infrastructure和database software的补丁

[root@boydb01 12902308]# opatch auto /tmp/12902308 -oh /u01/app/11.2.0/grid
Executing /usr/bin/perl /u01/app/11.2.0/grid/OPatch/crs/patch112.pl -patchdir /tmp -patchn 12902308 -oh /u01/app/11.2.0/grid -paramfile /u01/app/11.2.0/grid/crs/install/crsconfig_params
opatch auto log file location is /u01/app/11.2.0/grid/OPatch/crs/../../cfgtoollogs/opatchauto2011-10-18_11-37-40.log
Detected Oracle Clusterware install
Using configuration parameter file: /u01/app/11.2.0/grid/crs/install/crsconfig_params
OPatch is bundled with OCM, Enter the absolute OCM response file path:
/tmp/12902308/ocm.rsp

Successfully unlock /u01/app/11.2.0/grid
patch /tmp/12902308/12902308 apply successful for home /u01/app/11.2.0/grid
patch /tmp/12902308/12421404 apply successful for home /u01/app/11.2.0/grid
patch /tmp/12902308/12914289 apply successful for home /u01/app/11.2.0/grid
ACFS-9300: ADVM/ACFS distribution files found.
ACFS-9312: Existing ADVM/ACFS installation detected.
ACFS-9314: Removing previous ADVM/ACFS installation.
ACFS-9315: Previous ADVM/ACFS components successfully removed.
ACFS-9307: Installing requested ADVM/ACFS software.
ACFS-9308: Loading installed ADVM/ACFS drivers.
ACFS-9321: Creating udev for ADVM/ACFS.
ACFS-9323: Creating module dependencies – this may take some time.
ACFS-9327: Verifying ADVM/ACFS devices.
ACFS-9309: ADVM/ACFS installation correctness verified.
CRS-4123: Oracle High Availability Services has been started.
[root@boydb01 12902308]#

6.打完后可以查看

[oracle@boydb01 ~]$ /u01/app/11.2.0/grid/OPatch/opatch lsinventory -detail -oh /u01/app/11.2.0/grid

7.先到ORACLE_HOME（否则由于目录的原因会出错）,然后运行升级脚本，对数据库本身进行修改。

[oracle@boydb01 ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Tue Sep 20 12:38:17 2011

Copyright (c) 1982, 2010, Oracle. All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 – 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options

SQL> set time on timing on
12:38:27 SQL> @rdbms/admin/catbundle.sql exa apply
SP2-0310: unable to open file “rdbms/admin/catbundle.sql”
12:38:32 SQL> @?/rdbms/admin/catbundle.sql exa apply

PL/SQL procedure successfully completed.

最后检查文件：
catbundle_EXA__APPLY_.log
catbundle_EXA__GENERATE_.log
检查命令：
grep ^ORA | sort -u

正常情况是没有返回的。

最后启动GC，结束。

正常情况整个过程耗时1小时以内，中间apply命令自动会起停数据库，所以打补丁的时间还是需要考虑下的。
–注：命令和输出有masking

做好《购买准备》，恰好也购买了exadata之后，如果就立马上线了，那我觉得除了佩服你之外，再无话可说了。工欲善其事，必先利其器。所以不花上很大的精力做些测试，终究是不得法的。
前几日碰到一朋友，购买的是Exadata2-8，好家伙，那可是exadata目前的顶配阿。但本身工作就很繁忙的DBA们，没有时间花大力气来做这些各种各样的测试怎么办呢？从最大化资源利用率和资本效率的角度来看，outsourcing可能是最优的方式，相比起上线之后总觉得还差点什么相比，前期的付出永远是值得的。
闲话到此，我们先进行ehcc的测试。对于datawarehouse来说，动辄上百TB甚至PB的数据量，如果能在不影响查询性能的前提下，大幅降低存储空间，那对于IT部门成本的节约就不是几块磁盘那么简单了。
本次测试的基本情况如下：
基础表：boypoo  记录数：约9500万行
测试表: boypoo_ehcc   记录数：完全复制boypoo
测试内容（所有测试都在同一台exadata机器上）：
a.建表速度
b.数据加载速度没有测试
c.同一个复杂SQL语句的查询速度（出于业务安全的目的，不贴出具体的SQL语句）
d.差异之处：原表是分区表，ehcc后没有分区
e.SQL脚本名：非压缩表SQL boypoo_test.sql ,压缩表SQL： boypoo_ehcc_test.sql
原始SQL的执行情况：

SQL> set autot trace statics timing on
SQL> @boypoo_test.sql
12 rows selected.
Elapsed: 00:01:48.08
Statistics
———————————————————-
2872  recursive calls
0  db block gets
26147198  consistent gets
2270136  physical reads
1108  redo size
1291  bytes sent via SQL*Net to client
524  bytes received via SQL*Net from client
2  SQL*Net roundtrips to/from client
2  sorts (memory)
0  sorts (disk)
12  rows processed

创建压缩表：

SQL>  create table boypoo_ehcc compress for archive low as select * from boypoo;
Table created.
Elapsed: 00:29:28.94

查看压缩后的SQL查询:

SQL> @boypoo_ehcc.sql
12 rows selected.
Elapsed: 00:01:16.74
Statistics
———————————————————-
27  recursive calls
0  db block gets
22071073  consistent gets
569532  physical reads
6508  redo size
1301  bytes sent via SQL*Net to client
524  bytes received via SQL*Net from client
2  SQL*Net roundtrips to/from client
1  sorts (memory)
0  sorts (disk)
12  rows processed

压缩前后的空间占用比：

SQL> select segment_name,sum(bytes) from dba_segments where segment_name like ‘BOYPOO%’ group by segment_name;
SEGMENT_NAME                                                             SUM(BYTES)
——————————————————————— —————-
BOYPOO_EHCC                                                          4676648960
BOYPOO                                                               25761415168
Elapsed: 00:00:00.00

通过以上测试，我们可以看出：

        响应时间（秒）   逻辑读   物理读   SIZE(MB)
boypoo :     108    26147198   2270136    24568
boypoo_ehcc:  76    22071073   569532     4460
变化*倍数 :    29%       15%       75%       82%

*注：变化是用公式（ehcc-boypoo)/boypoo 计算得出，响应时间和SIZE是减少，其余两个是提高。
也许表的类型、字段类型不同，上述比值会有差异，不过从上面的对比我们可以看出，ehcc还是值得尝试的。

PS:最后一个表格的编辑很浪费时间哦

前面两篇一直没有说，其实Exadata对Oracle的版本是有要求的－－－－必须是Oracle11gR2。
为啥呢？别人的开发都是基于这个版本，仅此而已。目前的最新版是11.2.0.2 BP10。

也就是说，如果你对这玩意感兴趣，那就要考虑你的业务要能够在11g上走得溜，因为这才是艰巨的任务。
比起几百万的投入，也许派几个小弟花点时间先学习下Exadata的一些基本特点更加合适。
那么花点小费用让他们参加下Exadata essentials的考试更是顺利成章的事了。Oracle官方链接
的报价是195美刀，不过在pearsonVUE的报价是125美刀，也就是说，价格与任何一门OCP考试的价格一样，如果你是Oracle partner，

那么，你可以只需要676元人民币就可以了（25off)。

这门考试总共69道题，通过的分数是67%，也就是说答对43题就pass了。
考试时间是120分钟，相对于考过OCP的人来说，这些考题都太小儿科了。题目简短、答案更是简短。
所以我本是抱着试试看的心态去考的（因为前面赵宇写过好像很难的样子），结果考试前后签字的时间相差只是36分钟，
考试成绩可以达到A-。
当然了，这得益于在带孩子的三个月里我很有空，偶尔仔细的看了一点东西。

这个考试严格来说是一个售前工程师的考试，因为没有什么具体的命令细节、安装细节、调优细节的题目（我本来在这方面也做了些许准备）。
以其中一题举例，题目的大意是，一个客户的数据库有25T的有效数据，你应该向他推荐什么样的机型？
这样的题目占了75%以上。
另外考的比较多一些的是IORM（IO Resource Manager），围脖上*Exadata在中国*说这可以满足客户的SLA，我觉得是挺操蛋的想法。
有多少客户会考虑把许多生产系统迁移到一台机器靠一个软件来平衡资源的利用？
不过，没有关系，以上内容，基本上只需要读一本书－－－《Exadata Database Machine Owner's Guide》，网上有下载的。
当然，如果你有机会参加Oracle针对partner的2天Exadata bootcamp免费培训，哪个讲义扫一眼也可以增加点你的信心。

到这里，你已经可以稳拿该证书了。
但是，这不是目的。
更重要的是oracle相关工程师、销售跟你聊的时候，你可以问出比较有水准的问题，而显然的，也进一步可以觉得你是否要上Exadata。
1.这些问题别人是否能快速、有效的回答?
2.别人是否能从中衍生出一些更有价值的信息供你参考
3.发生问题了，谁可以提供支持，解决问题的有效时间大概会怎样

当然，有些集成商可能还要借证书装点门面，你也可以友情出租，甚至收点租金哦：）

在上一篇，简单介绍了Exadata是什么玩意，接下来，看看如果要购买，应该有些什么可以注意的。

一般来说，买Exadata跟买小型机有些类似，却跟买PC机完全不一样。但是却有人把它当PC机一样采购，最终导致机器的开机时间推迟了3个月之久。
为什么呢？Exadata目前分 X2-2和X2-8两种型号，其中X2-8是最高端的，只提供全配机型。
为满足客户吃螃蟹的心态，Oracle对比X2-8低一级配置的X2-2向用户提供了三种配置：四分之一配（quarter）、半配（half）和全配（full Rack）。
目前在国内，卖得最多的就是Quarter Rack的机器。

在owner guide里，这四种机器的详细情况有个表格，全配的X2-2/X2-8将近1000公斤重，Quarter配置的也将近410公斤重，所以机房里都需要重新特制Exadata承载地砖。
同时，一台满配Exadata X2-8需要最高17KW的电力支持，还有对温度、湿度，以及非常关键的网络资源的要求。
Exadata需要用户准备三个网段的网址，否则在Oracle工程师进场后，使用dbm_configurator配置安装脚本时，将会提示错误，无法进行。
当然了，准备网络地址也是很费精神的事情，一台满配的X2－2需要将近100个IP地址（包含以太网IP地址和infiniband网络地址）。
也正因为如此，所以安装所花费的沟通时间可能不比具体实施的时间要少。这也就是会又客户让机器等待数月之久的原因。
Oracle的license是从下单日开始计算的，从下单到机器从美国运到国内来，至少要一个月时间，如果用户自己再等待一段时间，那明显不太核算了。

一般行为正常的客户在购买之前都会要求Oracle针对自己的应用提供POC测试，以此来初步检验购买该设备后可能会给自己带来多大的IT收益。
不过由于Exadata的封闭性，如果你的业务逻辑很复杂，又多层中间件之类的话，所有的业务逻辑都只能使用Oracle procedure的方式来体现，所以在POC时，可能会有一定的性能误差。
所以，做好POC的准备工作也是购买Exadata前不可绕过的一道工序。

值得庆幸的是，Oracle目前已经在大陆有3台Exadata可供用户测试了，所以，测试时间等各方面都会更加有保证。以前机器在美国的时候，光是申请测试等待的时间可能都会超过一个月之久。

Exadata的价格可以在官方网站上查到list价格，不过在国内的报价目前看来略显混乱，对用户极其不透明。
当然，如果销售人员能看到你购买的曙光，还是会尽力跟上级领导申请到好的distcount的。

Exadata在上一个Oracle财年卖了28台，新一财年据说目标是180台，很多客户都表示很感兴趣。但是Exadata到底是什么玩意呢？

我曾跟朋友开玩笑说，这玩意是神器，买了就万事无忧了。从我最近的项目来看，其实不然。

首先，这玩意为啥叫Exadata？ 其实是拉里.埃里森挑衅别人的一贯作风的延续，NCR之前的一体机叫TeraData（后独立），所以他就把新产品叫Exadata了。

如果你还不清楚，那就简单再说一下，这是数据量的单位：从字节开始往上按照千分位递进，分别就是KiloByte(KB)、MegaByte(MB)、GigaByte(GB)、TeraByte(TB)、PetaByte(PB)、ExaByte(EB)、ZettaByte(ZB)、YottaByte(YB)。

拉里一上来就要高别人几个数量级，好胜之心可知阿。

其实在这个产品刚出来（V1,HP做硬件部分）的时候，Exadata只是整个一体机存储部分的名称，数据库部分叫做Database Machine，不过现在更习惯把整体叫Exadata，存储部分叫Storage Server。

那这东西到底能干啥呢？今天在课上一位同学问我买个苹果的一体机如何？我一时没反应过来，一位苹果也出了个类似exadata的产品呢。

跟苹果的一体机不一样，Oracle的Exadata一体机是用来做大型数据库的。V1专门针对DW应用（也正式为啥要叫Exa的缘由吧），V2添加了一些功能支持OLTP应用。

Oracle的高级产品经理在《Achieving Extreme Performance with Oracle Exadata》一书中反复强调这是一个balanced system，是的，从存储、网络到Oracle Database

,它都实现了“网格化”，消除了单点故障，单点瓶颈。

那么客户为什么要买Exadata呢？很简单的一个因素就是只对应一个单一的厂商即可，不必数据库找oracle、操作系统找redhat，主机找IBM,存储找HDS，网络找cisco了，是不？

确实是这样，尽管oracle还是将硬件和软件单独由不同的服务部门来提供，遇到问题也会有不同服务部门的老板来关心，但总的来说，他们都叫oracle。

当然咯，如果你不是中冶这种一次能买几台full Rack的大户，或者像hair、移动、电信、华为这样的潜在大户，可能不一定会立即获得更高级别的支持。

不过话说回来，商人不都这样的么？

除了接口单一外，Exadata的优势还有几个方面：

1.infiniband组成的高速网络（40GB 40Gb），这使得RAC实例间 cache fusion争用的成本降低（当然这部分是可以被山寨的）

2.使用了smart scan和storage index这两项oracle密而不传的特有技术，使得数据的查询只返回少量数据到db server，大大缩减了IO消耗

3.使用了大内存（DBserver单节点至少96G，cell 24G），结合11g的cache result和client cache result技术，大幅提高响应时间

4.HCC高级压缩可根据应用需求在大幅节省存储空间的同时，很少影响到应用性能

5.业务多，数据量不大的客户，可以使用IORM将多种应用或需求的数据库建立在同一个Exadata上，而不互相影响性能

从我自身的测试经验来看，Exadata对于比较简单的应用来说，确实效率惊人。比如1亿条记录(30个字段）表的count(*)大概在5秒钟左右完成.

很多国外的同行还做过许多关于smart scan、storage index的简单测试，确实是又震撼力的。不过，对于复杂的应用来说，Exadata对于人的高要求，却一点也不比其他小型机低。

更详细的情况，等待下一篇《怎样买Exadata》。

今天给一个JDE客户做oracle9i forwindows的移机恢复测试（外部审计要求），客户用了我没用过的backup exec做的media management layer（windows平台）,客户自己没用它做过恢复测试，代理商的人也没用过，比较折腾，先是jde用户组不对，后面发现找不到rman备份script，搞半天才veritas代理商的人打电话过来说exec没有script（是否事实暂时不知）。

还在处理过程中接到一个电话，说是oracle7.3.4的版本，win2003的操作系统，没有归档，没有备份，已经有5-6个人折腾过了。我也在忙着，所以就让小杨用QQ先过去跟客户联系着。

客户实在耐不住性子，说医院里病人都打起架来了，让我无论如何飞过去，说是常规方法许多工程师已经用过了，非AUL不行，他们已经查到最近的航班。我用dul/AUL恢复过10g、8i、9i的库，oracle7还是头一遭。看着用户这么急，就让他们先传几个文件过来，我边做恢复测试，边试试水。

先是传了system01.dbf和另一个用户数据文件，可是system怎么都读不对，然客户查下状态：

FILE#      STATUS   CHECKPOINT CREATE_BYT NAME                                                                           

———- ——-  ———- ———- ——————————————————————————–

         1 UNKNOWN   202619580  314572800 D:\HISDATA\DATABASE\SYS1ORCL.ORA                                                  

         2 RECOVER   202619580  104857600 D:\HISDATA\DATABASE\USER_DATA_1.ORA                                               

\……(skip data)         估计是被蹂躏坏了。

无奈，再传，幸亏QQ速度够快（QQ虽然无赖，但是用途还是挺大的）。

再弄，居然还是有问题。 

估计是被蹂躏坏了。

无奈，再传，幸亏QQ速度够快（QQ虽然无赖，但是用途还是挺大的）。

果然，很快搞定。但是oracle7下的control写法跟之后的版本不一样，不需要ts#，从7的v$dbfile和v$datafile里也看不到ts#。从sys.file$里是能看到的，后面使用老熊专门为这个case改写的ODU里用到了。

不得不提的是ODU很强大，而且用法比dul简单。

下面简单列列ODU的处理过程：

ODU> help

help      —-   get command list
spool     —-   spool information to file
host      —-   enter os terminal
rowid     —-   decode rowid components
rdba      —-   decode RDBA to rfile# and block#
time      —-   convert number to timestamp
exit      —-   exit from odu
load config —-   load config information from file
open      —-   load database filename and asm disk list from file
osdump    —-   dump file format hex
dump      —-   dump oracle datafile block
unload    —-   unload data
scan extent —-   scan extent
scan disk —-   scan asm disk or any disk or disk partition
list      —-   list schema object,partition,datafile
charset   —-   get or list supported charset name

    简洁,易用。

看看结果吧：

ODU> unload table HIS.YP_BYFF

Unloading table: YP_BYFF,object ID: 2989
Unloading segment,storage(Obj#=2989 DataObj#=2989 TS#=8 File#=9 Block#=667 Clust
er=0)
20991822 rows unloaded

ODU>
ODU>
ODU> unload table HIS.ZY_CFXM

Unloading table: ZY_CFXM,object ID: 3031
Unloading segment,storage(Obj#=3031 DataObj#=3031 TS#=8 File#=9 Block#=7462 Clus
ter=0)
59613327 rows unloaded

回来说说效率，80G的数据量（datafile size)耗时1小时。ODU确实越来越鲁棒了！

anyway，现在具备恢复从Oracle7.3~Oracle11g的无备份数据恢复实力了，but，any anyway，除非你是傻瓜，没备份的还是赶紧备份下吧，没有开归档的尽快开开吧。

最后得提醒一句，据称这个数据库的“损坏”的首犯是 fastcopy,百度百科有介绍的。使用的朋友们需要注意了。从这个case我们仍然可以看到，系统维护规范的重要性，是多么让人厌烦，又多么让人悔不当初啊。

在这个case处理过程中，得到如下人员的直接和间接帮助：dcba、ora-600、老熊、qiuby and yxyup，thanks a lot.

本来想写篇“人生无常，谨小慎微”的博文，可是还没等写，接二连三又发生了几起别的事情，所以就合并在一起。

自此购车以后，就常常做不那么好的梦，右眼也老跳。去合肥上牌的头一天晚上，不知是兴奋还是紧张，没怎么睡好，似乎梦见了两具尸体上盖着白布，旁边还有棺材。等到回程的时候，才把这个梦告诉了来回帮我开车的lawrence，闹的这家伙很生气。

其实梦也许是准的，因为我们回程的时候，一是晚上（6点从合肥出发12点多到的上海），二是雾大，所以遇到了两起车祸。一起是快到南京三桥前面，堵了小半个小时，只看见宝马的前脸大半个没有了，没看见其他事故车；第二起是快到昆山了，大货车的东西撒到了4个车道上，小汽车的第二排座位和后翼没了。害我最后自己从高架开回家的时候，手和脚都是抖的。

没过多久，一个同学她老公，做出租车遇上车祸了。出租车和一辆黑色BYD F3在转弯的时候，以较高的速度相撞，我同学老公飞出去了。幸运的是，没有内伤，目前还在医院治疗。我坐出租车基本不坐前排，除非是后面有比我更重要的人。而前排没有安全带是极其危险的。

我也曾在购车第12天，下火车站地库转弯的时候，右后门撞到了墙，虽然可以钣金，但还是去换了门。原因主要还是速度。

每一个动作或行为也许都不那么危险，但结果我们往往难以预料，也许是身体的伤害，也许是生命的结束。

对自己如此，对别人也是如此。

上周六，刚下课就接到一个同事电话。客户觉得业务系统性能慢，说是以前一分钟能跑4万笔的业务，现在一分钟只能跑1万笔。原因只是前一天，原厂工程师将其中一个60多G的表从普通表，改为hash partition 表而已。由于这个应用非常复杂，无法定位到某个session，最后只能采用alter system 的方式跟踪（注意，也许是10.2.0.3版本特殊，这种方式开启的跟踪无法用alter system关闭，使用oradebug可以正常关闭，配合ultraedit可以加快关闭速度）。跟踪发现有大量无谓的反复的direct path read。幸好这只是其中一个测试库，比较了对应的开发库，结构变更后的cache选项没有加上。然而，这并没有结束，加上cache后，只是将速度提到一分钟2万笔。

周五接到一个电话，说是由于掉电，导致存储坏了，现在存储由IBM修复好了，数据库起不来了，需要帮助一下。销售人员一个月前去拜访过这个客户，据说在4年前投资了3000万，不仅购买了oracle RAC和IBM小型机，还买了DS4800，且8个EXP810柜子和1个EXP710，但是由于买产品却没买服务，所以系统一直运行的徐徐停停的。EXP810是用来存储地理图片的，数据库存储在EXP710上，一年前的dmp文件40G左右。通过QQ远程连上去看了alert log才发现，这个数据库系统自十天前开始，就没有启动过。进一步与客户沟通，了解到基本情况如下：12号由于机房停电，存储发生故障，19号请IBM工程师到现场修复RAID信息后，除了数据库文件所在的LUNs，其余LUN均可以正常访问。Crs check healthy，ASM instance也能正常启动.

能找到asm disks的路径，但是没有asm的diskgroup.

使用kfed逐一查看asm disks，发现信息全部如下：

kfbh.endian:                        201 ; 0×000: 0xc9

kfbh.hard:                          194 ; 0×001: 0xc2

kfbh.type:                          212 ; 0×002: *** Unknown Enum ***

kfbh.datfmt:                        193 ; 0×003: 0xc1

kfbh.block.blk:                       0 ; 0×004: T=0 NUMB=0×0

kfbh.block.obj:                       0 ; 0×008: NUMB=0×0

kfbh.check:                           0 ; 0x00c: 0×00000000

kfbh.fcn.base:                        0 ; 0×010: 0×00000000

kfbh.fcn.wrap:                        0 ; 0×014: 0×00000000

kfbh.spare1:                          0 ; 0×018: 0×00000000

kfbh.spare2:                          0 ; 0x01c: 0×00000000

没有任何oracle的信息了。束手无策。如果IBM不能把原始的asd信息恢复，唯一的途径是从1年前的dmp还原，然后慢慢补录了。    

这不，快下班了，又接到一个电话，一个测试库由于aud$表增长太快，工程师一不留神把truncate敲成了drop。不过幸运的是，这个表可以重建。

Anyway，就算2012快要到了，大家还是悠着点，该干嘛干嘛，不要慌不要忙。就算一切就有宿命，像稻盛和夫说的，运我们还是可以掌握的！

正准备下班来着，一个客户打电话过来了：RAC之中的一个节点无法访问，IBM工程师到机房看了后，说没有硬件故障，所有灯状态正常。但是显示屏无法显示（IBM的解释是上次启动的时候如果没有接显示器，那么这个时候是无法显示的，暂时无法佐证），ping heartbeat或service ip 都通，所以客户决定对这个机器进行重启。客户申请了2小时停机时间，目标是通过这2个小时的工作恢复两个节点正常运行，确保国庆7天不要再受干扰。要求我们现场standby。

国庆大假，所以外地的同事都已经购买了明天回家的票，本地同事都还在用户现场，所以只能是我自己过去了，正好公司新来了个实习生，就带着他一起过去了。也好，客户申请的停机时间是19:00~21:00,我正好可以先回家，开着车过去。银联的机房我去过几次，但是还是不记得了，所以在顾唐路口等了好久（客户在机房，手机是没有信号的，只有等他座机打过来）。等的过程中，这位实习生曾建议我继续往前开，而我选择了在龙东大道上等待。幸好等待了，因为机房就在顾唐路上，否则不知道在哪里可以掉头呢（GPS还没有送到）。客户电话终于来了，左转，右边2号门即是。

所以，方向比速度更重要，在不知道前方路况的时候，等待其实并非是最差选择。

银联的机房安全相当好，层层把关，层层刷卡，只有太保的漕河泾机房可以媲美，电信大楼的都比之差了许多。

话说终于见到了客户，正巧在19:00之前。客户又简单介绍了下情况，节点1目前正在提供服务，节点2则不知道具体状况，只有重启之唯一途径。两个IBM工程师已经在现场了，说是已经检查过了，没有异常。出于习惯，我建议客户先等等，如果可以的话我们先看一眼现场再重启不迟。首先登录了节点1，errpt明显可以看到上午8点54分有P-H错误，“对方节点VG 失败”，这居然是“没有异常”，现在的IBM工程师实在是太水了。但那又如何呢，事后聊了下，其实人家是备件工程师，虽然是属于MTS(maintenance Service)部门，但以跑腿居多，所以只是客户的级别不够而已，出的钱不够多，不是IBM工程师水。建议客户用串口登到节点2上看看，但由于银联管理太严格，电脑都在楼下柜子里，要拿上来还要许多银联上信的领导批准，而领导已经下班了，比较麻烦。再看看节点1的CRS 日志，在crsd目录已经产生了大量core dump。客户担心时间不足，作罢，先重启节点2。

节点2顺利重启，DB也正常启动。起来后看到8点多有VG failure/VG closing的报错，接下来是系统shutdown by user,但又没有正常关闭，所以就产生了这种状况。

建议客户将节点1也重启一下。

由于节点1的面板坏了，所以先关机，换面板。

可能这地方坏的人不多吧，浪费了不少时间。

但节点1重启时，异常发生了。 CRS无法正常启动，用crsctl check crs发现，CSSD和EVMD都healthy,但CRSD却是无法通讯。

用crs_stat -t ,却报：IOT/Abort trap，同时在crsd目录产生新的core dump。

检查crsd.log,发现了异常：

 info: directory for /u01/app/oracle/product/10.2.0/crs/crs/auth/A19543673 does not exist CLSC Fatal Accept Error.

 但auth目录后的内容是变化的。 这个目录之前没有关注过，幸好节点2已经重启正常了，所以进去看看。发现节点2上有auth目录，权限是root:oinstall，再下一级目录里有一些A开头的目录，但生成日期都是很早的了。

这说明A开头的目录应该只是临时产生，用完正常应该会删除的。

于是，参照节点2，在节点1上新建了个auth目录。

手动启动crs，正常启动。

手动启动数据库，正常启动。

建议客户重启一次节点1，但由于停机期限将到，遂罢。

但琢磨不透的是，为啥auth目录会凭空消失？

人为的？不可能，首先对这个客户工程师的作风我是相当了解的，平时没事是决不会碰生产系统半下的，而口令管理也是相当严格。

那是系统自动干的？CRS or HACMP? HACMP不可能动CRS的这么一个隐秘的目录的。

没错，我们撞到了bug，

Unpublished Bug 5467456: Abstract: DIRECTORY $ORA_CRS_HOME/CRS/AUTH WAS UNEXPECTEDLY REMOVED