讨厌的Oracle数据库
记得大三的时候有一门数据库的课程，那门课程给我留下的最深刻的印象莫过于课程实验中使用Oracle数据库编程的经历。当时课上使用的非常古老的Oracle 6(也许是5或者7)之类的版本，实验内容是用C语言编写访问数据库的程序，但访问数据库的方法是要在C语言里面用宏之类的语法写SQL，然后用一个专门的预处理程序把这个程序变成C可以识别的语法，再用C的编译器编译执行。对于已经熟悉Delphi和LAMP环境的我来说，这种编写MIS程序的方式几乎可以用“可笑”来形容。所以就用最快的速度完成任务，然后忙活自己的事情去了。这是我第一次接触到Oracle数据库，也是大学里唯一一次使用Oracle，剩下的时候，基本都在用MySQL。
2000年毕业以后，开始在学校刚刚成立的现代远程教育学院工作，第一个任务就是要给这个新成立的学院做个网站。那时网络中心是这个工作名义上的技术指导方，见到网络中心领导后，她就问了我是不是用过Oracle数据库，然后说要先建表空间才能建表什么的。于是，在那个炎热的夏季，我抱着一台256M内存的破台式机开始装Oracle 8i，盯着它闪动的硬盘灯好几个小时后，发现它死机了。而我内心只有一个想法：用一个几百兆的软件去管理一张软盘就能装下的数据，真是有病。后来，貌似是跟那位领导闹翻了，于是我开始用自己熟悉的东西干活儿，因为要做的“网站”最后其实是个远程教育的教务系统，考虑到那时的MySQL对于事务处理还不支持，就选择了PostgreSQL来完成工作。
那时每每在论坛上看到有人问如何安装Oracle，我都会在下面回上一句：年纪轻轻的干什么不好非去装Oracle，别浪费生命了……
比Oracle数据库更讨厌的是RAC
再遇到Oracle数据库，是十年以后，还是在网络中心。那时数字校园一期建设刚刚开始没多久，我从厂商项目经理的嘴里，第一次听到了RAC，在机房见到了传说中的AIX。但很不幸，运行在这个体系上的某个系统第一次使用就宕机了。后来，我花了很多时间去学习AIX+RAC，搞明白原来可以用AIX做双机，也可以用RAC自身的机制做，然后经过各种尝试，放弃了。有那么多事情要做，为什么要在这种奇葩的环境下浪费时间呢？
令人很无奈的是，高校信息化领域，几乎所有厂商提供的软件都是运行在Oracle数据库上的，随着各种系统的增加和不断集中，必须要有一个稳定的Oracle数据库运行环境。在熟悉了NetApp存储，大致搞懂了FC交换机的配置之后，经过两周的反复尝试和数次重装系统之后，我终于在两台X86服务器上装好了一个Oracle RAC环境。当然，刚刚装好以后就再也不敢碰这个系统了，生怕一不小会心它就坏了。
经过长时间的使用，发现RAC还是挺好的，但要想自己搭建一个高可用RAC环境可真是够麻烦的。要有至少一台存储、两台光交换机、两台服务器、可恶的内网交换机（这东西用小的不靠谱，但弄个高级的好浪费），连接十几跟电源线、八对多模光纤、一堆网线，还要在存储上配置至少五个LUN、在光交换机上建一堆ZONE，装系统前要还要打一堆补丁，把一连串配置过程记到印象笔记里。更重要的还要看着这一堆东西，哪个都别坏，坏了赶快修，想想都恶心。
比RAC更讨厌的是给RAC打补丁
后来知道，原来网上下载的Oracle虽然可以用，但其实是盗版的。除了遭受盗版的良心谴责以外，最麻烦的事情便是这个公开版本是有各种问题的，当然Oracle会给用户提供补丁。那时，单位还没有采购正版的软件，于是我费了九牛二虎之力，从一个俄文网站BT了一大堆Oracle 11g的补丁包，这是又一个悲剧的开始。
Oracle数据库的补丁，可不像RPM或DEB软件包那么容易安装，不仅要手工操作，还要按照顺序来，前面的小补丁可能跟后面的大补丁冲突，打大补丁之前要先把小补丁卸载，很有可能经过一阵折腾，数据库就起不来了。而给RAC打补丁，还要两台机器一个一个来，最要命的是集群基础组件出了补丁，要关了所有的实例才能弄。经过了两次惊心动魄的折腾，就再也不去找补丁包了，眼不见为净。
在采购了正版的数据库软件以后，这个问题反而更严重了，每每看到EM里面报告的安全补丁建议就觉得不安。虽然EM里面自带了所谓的生命周期管理，但也不是每一次打补丁都能成功的。看着一堆问题报告和一堆能够解决问题的补丁却无能为力，对于有升强迫症的人来说，是一种煎熬。
ODA来了，跟“讨厌的Oracle”说拜拜
ODA是Oracle数据库一体机的简称。这东西最初给我的感觉，是把一台存储和两台服务器塞进一个箱子里，但即便是这样也挺好，再不用盯着那一大堆硬件了，真坏了直接叫Oracle的人来修，再也不用先判断问题出在哪里了。
在见到ODA的庐山真面目以后，真还是感觉有很多惊喜的：
1. 整个机器只有六根电源线和四根用于内部连接的控制线，再就是跑业务的网线了，好清爽啊。
2. 代替讨厌的内网交换机的是内嵌的InfiniBand。对于IB，我只知道这东西响应速度极快，带宽极高，通常用在超算的内部网络中。有了IB，以后EM应该不会再报内网速度慢的警告了。
3. 两组共八块SSD硬盘，一组用来存放重做日志，一组用来做数据访问加速甚至直接存数据。 十六块8T机械盘，用来存放数据（这大小估计用十年也够了）。所有这些硬盘是通过ASM直接管理的，好处在于ASM将每个数据块存在两块儿或者三块儿硬盘上，也就是可以同时坏两块盘。跟整盘级别的RAID5/6不同的是，ASM会在空间够用的情况下，将坏盘上的数据块再复制到仍然可用的盘片上。也就是说假设坏盘没有被及时更换时又坏了更多的盘，只要时间空间够，就不会丢数据。
如果说上面这些，只是硬件的堆砌和整合，那么ODA里最大的惊喜便是OAK这个工具了。为什么呢，因为有了OAK，以下操作就都简单了：
1. 升级整个系统，包括硬件的固件和各种软件：
oakcli update -patch 12.1.2.7.0
厂商工程师部署的是 12.1.2.6.0，我在 MOS 888888.1 的指引下下载了最新版，然后升级了，居然没出问题。
2. 新建CDB数据库实例：
oakcli create database -db TEST -version 12.1.0.2.160419 -params default -cdb
用OAK建立数据库，系统会自动做到重做日志、闪存加速、恢复区和数据区的正确配置，不用自己去改配置了。
3. 创建不同版本的数据库实例：
oakcli create database -db TEST11 -version 11.2.0.4.160419 -params default
在一个RAC环境下同时运行11g和12c的数据库，这事儿对牛逼的DBA来说可能不是问题，但对我这种二把刀的人来说是绝对不可能做得到的。不过在ODA下只要通过一个命令配置一下，然后就能这么干了。
看来可以干掉两台因应用问题无法迁移到12c上的独立11g数据库服务器了。
4. 删除数据库实例：
oakcli delete database -db TEST
各种测试之后可以随便删除，不用担心留下垃圾。
简单的说，就是ODA的硬件体系解决了过去系统管理员必须要解决的问题，而OAK解决了数据库管理员必须要解决的初级问题。而我，只要做个普通用户愉快的使用数据库就行了。
等把ODA彻底搞熟以后，就可以把各个数据库向ODA迁移了，希望这是2026年前最后一次迁移数据库，希望这以后可以跟“讨厌的Oracle”说拜拜，跟“可爱的ODA”一起愉快的工作下去。