明天想想聊一下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?