明天想想聊一下 ORACLE 数据库的倒退。
这个问题有点儿敏感，因为聊完明天的话题，必定会有人说我崇洋媚外，不合乎以后大力发展国有数据库产品，去“O”的趋势背景。
而且我自己也是 ORACLE 出身，多少会有些“自卖自夸”的嫌疑。然而，作为关系数据库的一个巅峰，我置信 ORACLE 数据库是任何一个 IT 技术者都绕不开的话题。那我也就本着尽可能中立的态度，来说一下 ORACLE 数据库的倒退历程和能够借鉴的中央吧。
做过软件开发的人都有这样的教训，就是一开始的时候，无论是最终客户还是产品经理都对本人须要的货色隐隐约约，需要改了又改，加了又加。而后，原来薄弱的代码，越来越饱满，最初甚至瘦削起来。ORACLE 数据库也是这样一步步成长起来的。
话说 RSI（ORACLE 公司前身）在 1979 年公布了在 PDP-11 计算机上的商用 ORACLE 2.0 版商业产品（Ellison 认为客户更违心购买第 2 个版本，而不是第一个版本，所以他间接省略了 1.0 版，厉害吧！）。这个版本是采纳 PDP-11 计算机的 Macro-11 汇编语言开发的。也就是说，给 PDP-11 开发的 ORACLE 数据库不能用在 IBM 主机和 DEC 的 VAX 上。所以，为了满足第一个 ORACLE 数据库用户 (美国中央情报局) 的在多种计算机上同时应用的需要。OARCLE 从第三版（事实上的第二版）就开始用 C 语言进行重写。要晓得，C 语言过后推出不久，用它来写 ORACLE 软件也是具备肯定的危险的，但除此之外，别无他法。但侥幸的是，很快就证实了这样做是如许的正确，C 编译器便宜而又无效。从那时起，ORACLE 产品有了一个要害的个性：可移植性。
这也对 ORACLE 之后的数据库产生很大影响，绝大多数的数据库的开发语言都采纳了 C 语言进行开发。
然而，应用了 C 语言重写后的 ORACLE 数据库也并不是从此一帆风顺。幸好在经验种种磨难之后，登上了关系数据库的巅峰。
上面咱们给 ORACLE 数据库的倒退做一个简略的总结：
1979 年冬季，公布了 PDP-11 计算机上的商用 ORACLE Ver2.0 产品，这个数据库产品整合了比拟残缺的 SQL 实现，其中包含子查问、连贯及其他个性。
1983 年 3 月，公布了应用 C 语言重写的 ORACLE Ver3.0 产品，推出了 SQL 语句和事务处理的“原子性”和“非阻塞查问”，应用存储在 ”before image file” 中的数据来查问和回滚事务，从而防止了读锁定（read lock）的应用（尽管通过应用表级锁定限度了它的吞吐量）。
遗憾的是，因为厌倦了无休止的软件调试，RSI 的第一个员工 Scott 带着他的猫 Tiger 来到了公司。
1984 年 10 月，ORACLE 公布了 Ver4.0 产品。产品的稳定性总算失去了失去了肯定的加强，达到了“工业强度”。这一版减少了读一致性（read consistency），这是数据库的一个要害个性，能够确保用户在查问期间看到统一的数据。
1985 年，ORACLE 公布了 Ver5.0 产品。实现了能够在 Client/Server 模式下运行的的 RDBMS 产品。还公布了 ORACLE 并行服务器（ORACLE Parallel Server，OPS）提供集群服务。
1986 年，公布了 Ver5.1 产品。反对分布式查问，容许通过一次性查问拜访存储在多个地位的数据。并且，在 1986 年 3 月 12 日，ORACLE 公司以每股 15 美元公开上市。
1988 年，ORACLE 公布了 Ver6.0 产品。因为过来的版本在性能上屡受诟病，Miner 率领着工程师对数据库外围进行了从新的改写。引入了行级锁（row-level locking）这个重要的个性，也就是说，执行写入的事务处理只锁定受影响的行，而不是整个表。这个版本引入了还算不上欠缺的 PL/SQL（Procedural Language extension to SQL）语言。第 6 版还引入了联机热备份性能，使数据库可能在应用过程中创立联机的备份，这极大地加强了可用性。同时在这一年，ORACLE 开始研发 ERP 软件。
到此为止，ORACLE 曾经实现了原始积累，看起来当前的路线会越来越顺利，但恰好就在这个时候，两个高速倒退留下的弊病裸露了进去。
第一个是测试有余。ORACLE 数据库从一开始就是只有开发，没有业余的测试和业余的测试人员，都是客户给收费测试。这种开发模式在晚期软件规模较小时没有太大问题，然而随着各项性能减少，软件规模的变大，Bug 数开始变得不可管制。客户的忍受也到了止境，在第六版刚公布之后，很多急不可待开始应用的用户就口碑载道。这个问题也实在的反映了软件开发产业的一个通病，就是市场部门为了销售业绩会对产品的平安和性能进行各种夸张的宣传，并且给开发部门压力，放慢产品的迭代速度，而开发部门只能为了速度就义平安和性能，把显著测试有余的产品仓促的推向市场，让客户帮忙测试（这一点从 ORACLE 的 Bug DB 里记录的数十万个 Bug 就能够想到了）。
第二个是财务问题。这也是一个一般公司到上市公司的初始阶段的通病。因为没有上市之前财务管理不标准，上市之后各项监管制度欠缺之后，就会把以前的各种问题裸露进去。ORACLE 也是一样，1990 财年第三季度报表的颁布引爆了所有。财务人员发现了 1500 万美元的坏帐，并且公司利润间隔预期相差甚远。接下来的工夫里，大公司病的诸般症状接踵而来，面对股东的指控，股票一泻千里，公司前景黯淡，甚至面临破产。
幸好 ORACLE 公司的管理者及时地发现问题，一方面加大开发投入，放缓迭代速度，一方面下大力气整顿财务，削减开销，裁退大量销售人员，同时聘用了专门的治理人才。
终于在 1992 年 6 月，ORACLE Ver7.0 产品才终于闪亮退场。这一次公司汲取了以前的教训，听取了用户的多方面的倡议，集中力量对新版本进行了大量而粗疏的测试。该版本减少了许多新的性能个性：分布式事务处理性能、加强的治理性能、用于利用程序开发的新工具以及安全性办法。ORACLE7 还蕴含了一些新性能，如存储过程、触发过程和说明性援用完整性等，并使得数据库真正的具备可编程能力。这个版本还在原有的基于规定的优化器（RBO）之外引入一种新的优化器：基于开销的优化器（Cost-Based Optimizer , CBO）。CBO 依据数据库本身对对象的统计来计算语句的执行开销，从而得出具体的语句执行打算。在当前的几个重大版本中，ORACLE 的工程师们逐渐对这个优化器进行改良，CBO 逐步取代了 RBO。这也是 ORACLE 数据库里含金量最高的两个中央之一（另一个是 RAC 的 Cache Fusion）。
1997 年 6 月，ORACLE 8i 产品公布。“i”代表 Internet，这一版本中增加了大量为反对 Internet 而设计的个性。这一版本还为数据库用户提供了全方位的 Java 反对。反对面向对象的开发及新的多媒体利用。
2001 年 6 月，ORACLE 9i 产品公布。这一版本中公布了 Real Application Clusters（RAC）性能。尽管第五版 ORACLE 就开始开发 ORACLE 并行服务器（ORACLE Parallel Server，OPS），并在当前的版本中逐步的欠缺了其性能，不过，严格来说，OPS 只是一个集群环境，然而并没有体现出集群技术应有的长处。9i 的 RAC 使得多个集群计算机可能共享对某个繁多数据库的拜访，以取得更高的可伸缩性、可用性和经济性，称得上是真正的利用集群软件。
2002 年 3 月，ORACLE 9i 第 2 版产品公布。这一版本中公布了本地的 XML 数据库、主动治理、Data Guard 等高可用方面的个性。
2003 年 9 月，ORACLE 10g 产品公布。“g”代表“grid , 网格”。这一版的最大的个性就是退出了网格计算的性能。何谓网格计算？网格计算能够把散布在世界各地的计算机连贯在一起，并且将各地的计算机资源通过高速的互联网组成充沛共享的资源集成。通过正当调度，不同的计算环境被综合利用并共享。听起来玄幻无比，然而却没有啥具体新性能推出。不过，ORACLE 从这一个版本，开始把重点放在了软件的自动化治理（例如 ASM）和性能优化（例如 AWR 和 ASSM），还有 DBMS_SCHEDULER 和 Datapump 之类的管理工具。
2005 年 9 月，ORACLE 10g 第 2 版产品公布。增强了平安方面的性能（例如 TDE、ROLE、PASSWORD）和 SQL、PL/SQL 的性能。
2007 年 8 月，ORACLE 11g 第 1 版产品公布。这一版本推出了泛滥新性能和加强性能，具体内容能够参考以下网址：http://www.orafaq.com/wiki/Oracle_11gR1
2009 年 9 月，ORACLE 11g 第 2 版产品公布。这一版本推出了“RAC One Node”性能，使得单机数据库也能够应用 RAC 形成的高可用性等高级性能。https://www.orafaq.com/wiki/Oracle_11gR2
2013 年 7 月，ORACLE 12c 第 1 版产品公布。这一版本推出了“multi-tenant”性能和“In-Memory”性能，“multi-tenant”性能即 CDB/PDB 架构，使得以前一台服务器上多个 INSTANCE 的形成办法变成了多个数据库以独特数据库（CDB）下挂载多个 Plugin 数据库（PDB）的形成形式。“In-Memory”性能即在 SGA 中开拓出一块空间，以“列存储”形式加载数据，提供相似数据仓库须要 OLAP 计算反对。另外，“c”代表“cloud , 云”。示意 ORACLE 数据库开始向“cloud”发力了。
2017 年 3 月，ORACLE 12c 第 2 版产品公布。这个版本并没有推出革命性的新性能，然而在传统 RDBMS 之外的性能（例如相似分布式计算的 sharding 性能，原生的 Json 反对性能等等）。另外，这个版本也是传统的基于性能版本升级体制的最初一个版本，从下一个版本开始，ORACLE 数据库开始以年度为单位进行 Release，例如，18c、19c、20c、21c……。你兴许会说，这不是又走回头路了。的确像回到了老路上，但又有很大不同，因为：第一，ORACLE 曾经不是几十个人的小公司了，而是一个领有数万名研发工程师的巨无霸，有能力在较短的工夫内进行产品的迭代。第二，尽管以年度为单位安顿 Release 打算，然而并没有保障每一个版本都有 Release 产品，就像去年的 20c 就没有真正 Release，而是作为一个开发版本存在。
Release Schedule of Current Database Releases (ドキュメント ID 742060.1)
上面是一个能够查问 11.2 之后的新性能的网页，有趣味的同学能够自行参照。
https://apex.oracle.com/database-features/
絮絮叨叨的写了几千字，有点儿累了，明天就写到这儿吧。
下次想从面向用户性能之外的角度谈谈 ORACLE 数据库能够借鉴的中央。
1. OWI 的设计
2. 动静视图
3. Diagnostics
上面说一下上篇文章里留下的思考题。
既然 flash memory 的寿命无限，那为什么咱们在应用的过程中没有发现容量逐步变小呢？
因为，每个 SSD 厂商都预留了 flash memory 颗粒，也就是说你买的 1GB 的 SSD 硬盘上理论粘贴的闪存颗粒要比 1GB 多得多。每当有的颗粒到了寿命之后，就会被弃用，所以你在相当长的工夫内是不会看到 SSD 的容量变小的。
Do you get it?