这个系统的环境是这样的，在整个系统中，大部分的机器放在192.168.1网段，为trust area，数据库主机也在此网段；另外有几台机器在192.168.3网段，为DMZ area。发送邮件不能直接在数据库主机上直接发送，需要通过192.168.3网段上的一台smtp server进行relay。我们假设这台smtp server的IP为192.168.3.99，下面我们来开始配置db主机，使得db主机上用mailx命令发送的邮件能中继到smtp server上进行发送。

在这里，db主机的os环境是aix 5.3，需要配置的文件为/etc/sendmail.cf。我们先备份一下这个文件，然后来进行修改：
在这个文件中，找到有如下相关的行（如果没有需要自行添加）：

其中DSsmtp:[192.168.3.99]表示smtp server的IP为192.168.3.99
Dw后面直接跟本机的主机名
Cw后面跟localhost

修改上面的参数后，重启sendmail服务：

此时即可在db主机上，通过mailx命令将监控的告警邮件，relay到smtp sever，然后通过smtp sever集中发送：

OCM考试分成8个section，时间安排为：

section 0的手工建库，相关文章见：《OCM考试-create the database》，注意牢记在线文档中create database的例句在administrator guide-Part I Basic Database Administration-2 creating an oracle database - Step 7: Issue the CREATE DATABASE Statement。

section 1：侦听部分见文章《OCM考试-listener》，另外还会涉及到表空间管理，需要注意以下知识点，
1、big tablespace 的建立，相关文档Administrator’s Guide-8 Managing Tablespaces-Creating Tablespaces和SQL Reference-16 SQL Statements: CREATE SYNONYM to CREATE TRIGGER-CREATE TABLESPACE 。
例子：

2、tablespace group的建立，相关文档也可以在Administrator’s Guide和SQL Reference里面找。
例子 ：

3、冗余logifle，相关文档见SQL Reference-10 SQL Statements: ALTER CLUSTER to ALTER JAVA-ALTER DATABASE -logfile_clauses 。
例子：

4、resource manager的配置：
4.1、配置一个用户，拥有resource manager的administration权限：

或者直接用语句：

注意这里的ADMINISTER_RESOURCE_MANAGER system privilege。

4.2、创建2个consumer groups，分别为OLTP和DSS：

4.3、创建一个名为WEEKDAYS的resource plan：

该resource plan的相关设置：

4.4、将OLTP_USER的默认资源组分配成OLTP，注意转到user界面

4.5、将SH的默认资源组分配成DSS：

4.6、将instance的默认资源计划定位WEEKDAYS：
点Activate this plan

section2的gc安装配置见《OCM考试-安装grid control》

section 3：备份和恢复会用到之前的文件存储路径的冗余，还有之前的rman备份。

section 4：数据仓库管理，主要是物化视图和sqlldr以及external table。
1、建立一个能快速刷新的物化视图，且能去除表中的重复行：

2、建立一个外部表，类型是datapump
（相关知识：Utilities-Part III External Tables）

3、sqlldr的使用（相关知识：Utilities-Part II SQL*Loader）：

section 5:数据库管理
1、表空间传输(相关知识：Administrator’s Guide-8 Managing Tablespaces-Transporting Tablespaces Between Databases-Example)

2、打开一个表上所有的索引监控(相关知识：Administrator’s Guide-16 Managing Indexes-Monitoring Index Usage)：

3、建立分区表(相关知识： SQL Reference-CREATE INDEX)：

4、建立带LOB字段表（相关知识： SQL Reference-CREATE TABLE-LOB_storage_clause::=和LOB Column Example）：

5、FGA审计（相关知识 PL/SQL Packages and Types Reference-40 DBMS_FGA-ADD_POLICY Procedure)：

section 6:数据库性能管理
1、创建IOT表(相关知识：Administrator’s Guide-Managing tables-Creating an Index-Organized Table 或者 SQL Reference-CREATE TABLE-Index-Organized Table Example )：

2、keep 在cache中：

3、创建bitmap index：

4、创建reverse index：

5、创建function base index：

6、收集统计信息：

section 7:部署Oracle RAC数据库，相关文章见：《ocm考试-rac安装》

sectoin 8:部署dataguard数据库 ，相关文章见：《OCM考试-DG安装》

起因是这样的，5月底6月初开始，某个客户上海的项目遭遇客户抱怨，SDM异常紧张，现场的PM压力也非常大，召集各个team频繁会议，最终在网络工程师的努力下，发现系统变慢是由于某个感染病毒的客户端连接上来，造成了应用服务器的cpu消耗过高，当隔离该客户端之后，问题就解决了。

问题解决后，客户要求提供相关的文档，说明解决思路和日后的处理方法。ok，这也没问题，客户的要求很合理，考虑也很周到，因为万一相关人员离职了，后续的工作谁来做，没有文档记录，每个人有每个人的处理方法，就没有了标准的作业流程。于是，大家就是忙着准备各自领域内的操作文档。

本来，事情应该告一段落，但是又跳出一个架构的项目经理，说数据库也存在性能问题，列举了几条performance issue。我不太清楚当初的这几条performance issue是怎么提交上去的，首先说说这几条issue，从我的观点看，表空间的大小调整，死锁的发生，还有数据的加载时间段——这些，其实应该算是一个troubleshooting的问题，而不是放到performance tunning来做。所以，第一，问题的引入就不是非常的恰当。因为performance tunning，必须是有一个明确的问题和目标，比如，cpu idle过小，内存使用率过高，应用的某个模块执行过慢。通过tunning，我系统cpu idle达到多少，内存使用率降低到多少，应用模块执行在多少秒内完成，等等。有了具体的目标，我们才能针对目标进行tunning。而不是说你去查一下数据库中的parameter，看看有没有设置不合理的，我们调整这些参数来改变数据库。tunning的第一步，就是应该设立一个明确的问题和目标。

当确立tunning目标之后，开始tunning。就tunning的工作来说，这是一个没有尽头的工作，谁也无法说，我将这个tunning的工作做到了极致了，已经没有可以再优化的东西了。正确的tunning，应该是根据之前确立的目标，一旦到达这个目标，后续的事情就应该停止了。而在这个案例中，系统的瓶颈不是出在数据库，而是一个感染病毒的客户端，查出问题，解决问题，ok，tunning就应该到此为止。

退一步讲，如果数据库确实存在问题，而且客户提出了tunning要求，ok，那么dba进行介入。这里就涉及到一个用人的问题。我向来的观点是：用人不疑，疑人不用。但是在我收到邀请我参加performance issue meeting之后，我得知还有一个北京的DBA会来参与这个tunning。本来，多一个人，多一种思路，大家集思广益，观点和思想互相交锋，这是有好处的。但是当我了解到，这是因为上面的领导觉得我们team不够skill去做这个事情，特地的从北京的team要了一个dba来临时帮忙cover这个事情，我就觉得非常的气愤了。

我们不是不够skill，我们只是have no time。进入IBM之后，我就发现大家的工作量非常的饱和，当然，这个工作量不仅仅是在处理事情上，也有很大的一部分时间，是在会议上，在写报告上，在参加公司政策的培训上，在对流程的熟悉上，在不断的填写自己的个人信息个人计划个人目标个人总结上，在不断的create change，approve change和做change上（当然很多change不是在上班时间做，很多change是在下班时间做，连alter tablespace add datafile这样的常规维护操作，也要安排到晚上，也有人会跑过来问你这个操作有没有在测试环境上做过——虽然可能他也不知道我们有没有测试环境）。在team中，似乎流行着一种心态，就是我加班你不加班，我就嫉妒你，你应该留下来陪我们一起加班。这本来就是一种不正常的心态，之前在推上听过一句话，不希望别人幸福的人，自己永远得不到幸福。由于这种变态的加班心理存在，感觉每次上班的心情和上坟差不多了。但是，为什么会有这样的心态产生呢？说到底，还是工作量的缘故。从数据库的数量上来说，我们已经接近快500个instance了，但是维护的人员只有4个。IBM的库虽然都不大，也就几十百来G，但是由于数量多，出问题的概率就大了。而且不仅仅是出问题，平常的一些简单操作，比如执行某个应用的脚本，也需要dba，这就造成了dba在整个系统中充当的角色，是个消防员。

在进一步想一下，是什么造成了我们这么大的工作量？是近500台db吗？其实不是，500台的db，如果一开始的架构做的好，就完全不会有那么多的麻烦。在我接触到的这个项目中，一台sever上多个instance比比皆是，某项目一台server上有24个instance，另外还有生产库和测试库混杂在一起，oltp和dss混杂在一起。作为一开始的架构，db服务器就应该是一个专用的机器，一般情况下，都是可以一个instance里面多个schema来解决，如果真的不行，需要分离，那么比如像上面说一台server上24个db，可以采用intel的虚拟化技术，通过建立多个虚拟机来实现。操蛋的架构，导致了后续维护成本的升高。

除了架构，还有什么？除了架构，还是架构！不过这个架个不是系统的架构，而是项目管理的架构。这个项目中的哪个项目经理是老大？我该听谁的话，我该对谁负责？PM M？PM L？还是PM J？每一个都会蹦出来邀请我参加会议，会议完之后一堆任务。项目管理架构的混乱，导致人员疲于准备会议、参加会议、总结会议、完成会议的任务、汇报任务的情况、最后在召开会议大家一起回顾。

除了架构，还有什么？除了架构，还是架构！不过这个架个不是系统的架构，而是人员的架构。由于在外企，人们都是被摁在一个框一个框之内，接触到的东西就只有眼前的那么一点，要站在整体的角度去看问题，就非常困难，成本很高。很多情况下，会出现这样的问题：客户抱怨说系统慢的不行了，然后应用检查说没问题，网络检查说没问题，主机检查说没问题，数据库检查说没问题，中间件检查说没问题。那么既然大家都没问题，为什么客户那边就发生了问题？那是因为大家都只盯着眼前的一块，没有站在高处去看这个问题，没有一个能掌控整个架构的人出现。

作为一个dba，应该有整体运维的思维，而不仅仅局限在db上的一点。从开始的容量预估，架构设计，高可用方案设计，容灾设计，备份设计，集成部署，到中间的日常维护，监控（监控数据库、监控集群情况、监控网络、监控备份、监控主机三驾马车：cpu、内存、io），从监控的数据得到性能的基线和波动曲线，了解业务的峰值和空闲时间，定期的巡检，还有性能优化，到后来，还要关注补丁计划，迁移计划，版本升级计划，以及容灾演练的操作……

回到之前的那个performance issue，其实我挺佩服北京的dba那哥们，他确实是一个很不错的dba，站的角度也很高，从主机参数到磁盘IO各项性能指标都进行询问。另外，我们深圳dba team的内部也对这个case进行了讨论，在讨论中，大家都对该issue发表了很有针对性的看法，Dean、Rainny都是一等一的好手，我觉得我们的team完全有实力去解决这个问题！我不知道为什么在我接手之前，上面的领导会觉得我们team不够skill。我只是觉得：我们不是不够skill，我们只是have no time——no time到没有生活（同事去东部华侨城玩的时候还背着笔记本电脑），no time到没有自我提升（晚上做完change回到家基本可以洗洗睡了，不用看什么书了），no time到没有改进（工作就是让你去完成的，你想改进，连个测试的时间都没有），no time到没有思考（我们的这种状态正常吗？需要反思吗？需要改进吗？什么是我们的追求？）

2.没有用户密码，用dba用户也可以直接操作该用户的表。

这个操作比较适合不想建synonym只是临时用来对数据的操作上。注意alter session之后，是否对schema的表有操作权限取决于你之前登录的用户，之前登录的用户需要对当前schema的用户的表有操作权限。

这个库是在aix的上一个9208的库，前段时间刚刚打了CPUApr2010。应该来说，做全库导出，是不会有这样的报错的，做全库导出的用户也给了connect，resource，dba的权限。全库导入的话，可能会遇到system用户中唯一性约束的问题，但是全库导出不应该有报错。

查询了metalink，发现原来是和CPU的patch有关，在打过9208上的Oct07 CPU时就会有这个报错（ID 465018.1）：

在按照metalink的指示进行grant之后，果然没有报错了。我很怀疑这个报错也是在应用了CPUAri2010引起的。其实我的观点是，没有遇到bug，还是不要打补丁，不会触发新的bug，也省事。

同时，在gc的$ORACLE_BASE/OracleHomes/oms10g/sysman/log/中看到：

查询metalink似乎是个bug（Bug 7342584），于是，从最简单的角度出发，我觉得手工建dg。

手工建dg的方式也比较简单。对于考试的库，由于比较小，我们可以用hot backup的方式也进行复制。以下是操作的方式：

1.由于我们的主库（ocmdb）和备库（dg2）都是在同一的机器上（奇数机），因此，有几个convert的参数需要配置，结合其他要调整的参数，在这里，我在主库上改了如下几个参数：

将以上参数create pfile from spfile。

2.将pfile rename成initdg2.ora，同时修改下面几行：
*.db_name=’ocmdb’
*.db_unique_name=ocmdb_site1
*.instance_name=’dg2′
再修改控制文件的名字
生成备库的密码文件，然后用该pfile启动备库到nomount状态。

3.配置tnsnames.ora，在里面添加备库的信息。

4.在备库alter system register，使得备库在主库能动态注册。

5.在主库做几次checkpoint，检查scn是否一致：select CHECKPOINT_CHANGE#,CONTROLFILE_CHANGE# from v$database;和select distinct CHECKPOINT_CHANGE# from v$datafile_header;。再运行alter database begin backup。

6.alter database create standby controlfile as ‘某路径’;

7.将控制文件复制到对应的路径，将数据文件、日志文件复制到对应路径。

8.启动备库，alter database mount standby database;alter database recover managed standby database disconnect from session;

9.检查RFS服务是否对日志的传送情况和mrp进程是否apply了传送的日志。

作为一个球迷，能看世界杯的比赛是一件很幸福的事情；而更幸福的事情，就是把老婆也带成一个球迷，一起看球。

在若干年后，你可能不记得有一届世界杯是在南非举行了，但是说到2010年夏天的那场嗡嗡祖拉，你肯定记忆犹新。像马蜂般的嗡嗡祖拉，像苍蝇般的嗡嗡祖拉，驱赶狒狒的嗡嗡祖拉，让人崩溃的嗡嗡祖拉，出口转内销的嗡嗡祖拉，韩大嘴吹嗡嗡祖拉。正是这惹人争议的嗡嗡祖拉，造就了南非世界杯独特的印象，在人的记忆深处划下一道深深的痕。

伴随着嗡嗡祖拉的声音，我和老婆在一个月的时间里，一起看了本次世界杯的好几场比赛，有些是19：30场次，有些是22：00的场次，还有些是半夜2：30熬夜的场次；看了开幕式，看了闭幕式，看了亚洲球队挺进淘汰赛，看了南美球队止步8强，看到了郑大世的眼泪，看到了梅西的灵动，看到了查巴拉拉进球后的舞蹈，看到科维尔的悲情，看到了马拉多纳的可爱，看到了上届世界杯的冠军意大利和亚军法国一起无法小组赛出线，看到了无冕之王荷兰仍然无冕，看到了德国队如行云流水般的进攻：4：1拿下英格兰，4：0狂扫阿根廷，最后却束手束脚0：1不敌西班牙，看到了葡萄牙像打筛子一样7：0狂扫朝鲜，更见识了连猜8场比赛全中的神奇章鱼保罗。

伴着嗡嗡祖拉的声音，我们一起买了啤酒、鱿鱼丝、绝味鸭脖、豆腐干、酸梅汤、恰恰瓜子，该死的豆干还害得我iphone屏幕进油！伴着嗡嗡祖拉的声音，我们常常在凌晨的那场煮方便面吃；伴着嗡嗡祖拉的声音，老婆学会了什么叫角球，什么叫任意球，什么叫越位；伴着嗡嗡祖拉的声音，我和老婆还在老丈人家和老丈人还有丈母娘一起看了一场球；伴着嗡嗡祖拉的声音，老婆认识了梅西、C罗、卡卡，并且喜欢上了梅西的那个腾讯广告。伴着嗡嗡祖拉的声音，我也离开了卓望到了IBM工作。伴着嗡嗡祖拉的声音，我们在Chinaunix论坛猜球赢积分，虽然开始的时候连猜5场全错，但是后面几场相信章鱼帝，到世界杯结束，老婆略有盈余，我却离持平还差几十积分。

最后的那场比赛，看完开幕式老婆就忍不住睡意在沙发睡去，到比赛开始前半小时，被我叫醒，擦了把脸嘟着个嘴起来看球，最终再加时赛的时候再次倒下睡去。伪球迷的姿态原形毕露了，哈哈。不过在我的惊呼中：西班牙进球了！老婆再次惊醒，和我一起欢呼，直到最后的西班牙举起大力神杯，老婆一直都是很激动的。

今晚，世界杯已经结束，嗡嗡祖拉的声音也渐渐远去。不过，2010年那年夏天的事情，将永远的刻在我和老婆的脑海中，我们到时候要讲给我们的小孩听：想当年……

从这个架构来看，这个server上的数据库属于库小且多的类型，虽然每个库都很小，也就几个G，但是数量不少。所以在做9207升级到9208时候，我选择了在升级完oracle软件之后，并发的升级数据字典，来提高效率。同时，由于升级数据字典大部分是sga内的操作，比如编辑，生成数据字典等，为了加快速度，我也将原来100M的shared_pool_size临时的加大了。同时为了保证并发，多个数据库能启动一起跑，也不能加太多。最后找到一个比较平衡的值：sga max size为600M，shared pool size 为200M，java pool为200M，执行catpatch脚本的时候，剩余的物理内存：

可以看到在2个instance起来后，并且同时跑catpatch脚本的时候，大约剩余的物理内存为4M左右（1000个页面，每个页面4K，因此大约为4M）。至于为什么只启动2个600M sga的库，就把物理内存压的那么死，后面我会进一步分析。

升级9207到9208的过程很顺利，原来估计每个库1小时左右的时间，在执行的时候，也就每个库6，7分钟左右。

升级完后，开始打CPUApr2010的补丁。

在利用opatch apply的时候，报错：
OPatch encounters the following issues during file patching:

ok，这是这个patch在read me中说到的issue：

于是按照wordround的方式操作，执行slibclean之后，再次执行opatch。没想到，这次报错的是：

由于用opatch rollback进行回滚，回滚成功，再次进行opatch，还是遇到libjox9.a的报错，再次运行rollback_ .sh 脚本，不过此次，不再提示脚本运行成功，而是提示libjox9.a正在被使用，无法回滚：

用fuser和lsof看，看不出是谁用在这个文件：

尝试重命名：
[resoprod:oracle:/u01/oracle/product/9.2.0/.patch_storage/9352224:] mv $OH//lib/libjox9.a $OH//lib/libjox9.a.bak20100710

再次opatch apply，成功！

这里遇到的一个问题，就是在opatch的时候，aix中会有写lib的文件会被占用，虽然在opatch的read me中会建议使用slibclean来清理，但是在实际的使用情况下往往会不适用，最好的方式就是用cp一个同名的，将原来被占用的那个mv成别的名字。再重新opatch。

最后，来说说那个机器的内存使用情况的问题。之前可能你会觉得奇怪，为什么只是启动了2个instance，每个instance的sga max size为600M，2个合计也就1.2G，为什么在执行catpatch的时候，剩余内存会那么少？

这个我在事后检查了主机的参数设置。

我们在数据库升级和patch完之后，恢复到原来sga大小，启动所有的实例，检查机器的剩余内存：

剩余内存大约为3926×4k=16M

继续检查内存情况：

我们看到maxperm为80%。我个人认为，maxperm是用来设置non-computational的分页，（参考《Overview of AIX page replacement》此文），而non-computational的分页，也就是用于文件系统buffer，一般如果database使用裸设备，不经过文件系统缓存，maxperm可以设置成3%～5%，而对于文件系统做datafile的database，这个值也只要设置成20%～30%左右即可。把太多物理内存用于文件系统buffer，是没有必要的，对于database来说，将数据块从datafile中读取之后，就是在db buffer cache中进行运算了。

并且，在IBM的官方文档中也找到相关的文章也印证我的猜想。可见《Oracle 9i在AIX上的性能调整 — 内存篇》：
在Oracle数据库应用的环境下，可以将MINPERM和MAXPERM分别设为5%和20%甚至更小，从而使内存更多地被用于Oracle的SGA而不是系统的文件缓存。

我们开始安装:
1、准备工作：
1.1 启动vnc server，其实这一步如果远端没有启动，或有任何vnc连接的问题，都可以向考场老师询问。

如果你进去看不到类似xmanager的界面，你可以修改这个文件：

将里面的twm & 注释掉，改成gnome-session &：

然后重启vnc服务：

ps:培训的时候问了ou的老师，vnc进去只有最简单的terminal界面，也就是twm &的方式。

1.2 检查2台主机裸设备的划分：此时的裸设备需要能在2个主机上都被看到。因此，如果没有划分好裸设备，需要自己划分，就在db01上用fdisk先划分好，划分好的情况如下所示：

1.3 检查2台主机裸设备的对应情况和启动裸设备的服务：

1.4 检查2台主机裸设备宿主情况：

1.5 配置主机间信任关系：
1.5.1 检查2个机器oracle的home目录权限是否为755：

1.5.2 生产rsa和dsa的私有key和public key：
在rac1：

在rac2上：

1.5.3 将pub key加入到authorized_keys：
在rac1上：

在rac2上：

1.5.4 测试：
在2台机器上分别：

1.5.5 检查2台机器的网卡是否都工作正常，public的是否配置了default gateway（如果这个不配，在运行完root.sh之后，配置vipca的时候会报错的）。

1.6 运行runInstaller进行安装cluster。

这处主要改成crs_1，默认是db_1

添加一个cluster：

修改eth0为public：

指定orc和votingdisk：

运行完成后，运行orainstRoot.sh和root.sh注意执行完在节点2会报错vip的问题，我们需要再次vipca，进行配置后才能按ok：

配置vipca：

最后配置完成：

1.7 运行runInstaller安装asm：
最好选择一个独立的asm_home:

这里提醒下大家，由于指定了一个不同的asm_home，在手工停asm实例的时候，不仅必须export ORACLE_SID为asm是实例名，还要export ORACLE_HOME为你刚刚指定的asm_home。所以其实如果为了考试简单起见，也可以直接用db_1这个asm_home。

继续：

1.8 安装数据库软件：

1.9 安装实例：
1.9.1 先用crs_stat -t 检查一下是否状态正常，没有的话，用crs_stop -all或crs_stop -f/crs_start -all重启一下：

1.9.2 用dbca开始安装：
先在asm上再划一个存储用作一会需要的flash recovery area：

开始创建database：

后续db instance创建的截图这边就先略了。

以上，rac的安装只是一个很简单的题目，可以说是个送分的题目。rac的考点还是网络的设置：如侦听的设置，tnsnames的设置，service的设置，在考试的时候特别需要注意看清题意再做。

这里介绍一个rac service的增加，以节点1做available和节点2做preferred：

检查新建的service的情况：

检查在各个节点的情况：
在节点1：

在节点2：

测试：
杀掉节点1上的smon进程，此时数据库会自动将service转移到preferred节点：
节点2上：

在卓望，我度过了4年多的时间，在这4年多的时间里面，我从一名刚毕业一年什么都不会的学生，成长为一名合格的oracle dba。不得不说，卓望是个很好的平台，很锻炼人，很有机会，我是卓望培养出来的dba。如果有人想成为一名oracle dba，我会很强烈的推荐他们去卓望这个平台。真的很不错！

由于个人的原因，我离开了卓望。我快奔三了，趁着还没到30，还有激情，还有动力，还能吃点苦，我想给自己换个环境。获得更多的知识，再锻炼下自己。很偶然的一次机会，IBM选择了我，我也选择了IBM。

刚来第一周，所有的一切都是新的。新的工牌，新的座位，新的领导，新的同事。甚至于在刚进公司门的时候，还要想想自己的座位是在哪个方位。企业里面推行绅士文化，每周一到四只能穿正装，周五可以穿休闲正装，家里面的牛仔裤基本上就被废掉了。怪不得有人说IBM=Install B Man。不过还好，入职培训的时候，有一位US IBM退休的老前辈，和他交流他说穿polo shirt应该没问题。

电脑还没领到，一直在走流程，公司大了，流程就很复杂。没办法的事情！

IBM很多外文三字经，好多都是若干个英文单词的缩写，什么JPI、GCG、KT。本来一直很疑惑这个，幸好老大告诉我个网址可以查：http://acrobot.almaden.ibm.com/ 。呵呵，和老员工混就会有不少好处。

和同事交流，最近会有一个系统的oracle数据库需要从9207升级到9208。本来很easy的一个case，但是在沟通中发现原来是一个server上有20多个库需要升级！这边不少这样的架构，一个server中装n个库。我估计这可能很IBM的思维有关系，原来一直是用db2，而db2是一个实例下有n个数据库，一个数据库只属于一个实例，但一个实例管n多个数据库。而oracle却不是这样，oracle是一个实例一个库，一个库可以有多个实例，如rac。目前为止我还没发现哪个oracle server上有超过5个库的。对于oracle来说，只需要在一个server中建立一个库，对于不同的应用建立不同的schema就可以了。

看来，以后的任务任重而道远，改架构容易，改思维却很难。我需要利用我的oracle知识，在ibm传播oracle的思想，注入oracle的文化，架起oracle和ibm之间的桥梁。