数据库之十二星座 ---- 狮子座的獠牙

写过了双子座的 MYSQL  白羊座的 SQL SERVER 水瓶座的MONGODB ，这次终于轮到狮子座 ORACLE 数据库，为何是狮子座，敢问那个星座能有狮子座霸道，强悍，并且就是霸道也是正面冲击，从来不在侧面和你迂回。

Oracle 在数据库界也是这个地位，或者说曾经有这个地位，得过数据库界的格莱美。 借用《金刚经》里面的一句“过去心不可得，现在心不可得，未来心不可得”。随着时间的流逝，ORACLE 从以前数据库界的北斗泰山，转而变得江河日下。或许说，这不是ORACLE的错，而是世界变化太快，数据库的业界，勇者辈出，而ORACLE 变化却没有带来新的流量，上云的想法也并未能拯救颓势。

但ORACLE必然是有些斤两的，或许以前的地位不在，但要想推翻这个数据库曾经的霸主，那有那么容易。你还得承接狮子座的 几个绝招

1   狮牙拳

当Oracle执行delete,update,insert,select for update  DML语句时，oracle首先自动在所要操作的表上申请TM类型的锁。当TM锁获得后，再自动申请TX类型的锁，并将实际锁定的数据行的锁标志位(lb 即lock bytes)进行置位。在记录被某一会话锁定后，其他需要访问被锁定对象的会话会按先进先出的方式等待锁的释放，对于select操作而言，并不需要任何锁，所以即使记录被锁定，select语句依然可以执行，实际上，在此情况下，oracle是用到undo的内容进行一致性读来实现的。

就这一招，就可以让其他的数据库吃不消。MYSQL, SQL SERVER ,斩落马下，但另一星座的 POSTGRESSQL 有类似的功能（下期在说）

与所有数据库一样，同一行的 DML 在同一个时间点都是不被允许的。

2 粒子光速拳

ORACLE 的 FLASHBACK 功能想必是无人不知无人不晓，ORACLE 在2009 就有这个特性了具体的时间  2009-10-15 日 ORACLE 11 G 就有这个功能了，而同是商业数据库的 SQL SERVER 至今 2017版本 才搞出一个四不像的类功能，还很蹩脚。  在这方面ORACLE 绝对是领先对手们 不是一般二般的强。 MYSQL 更是连影子都没有，还在吃奶呢，ORACLE 可以轻易的使用这个功能 虐死 这两个数据库 （别和我说 MYSQL BINLOG 使用各种耍手段 恢复修改的数据） 别再硬撑，你们都不是 ORACLE 的FLASHBACK的对手

还的说，后来者居上，虽然也没有多上，还是有另一个星座的对手，虽然也要花些力气来应对 “离子光速拳” FLUSHBACK的挑战， 但还是能使用数据库本身的手段来应对。

3 闪电光速拳

作为狮子座最强之拳，ORALCE 底层的存储结构是值得被称颂的，相对MYSQL SQL SERVER 初始底层存储设计的针对性，ORACLE 在底层存储之初就充分考虑了大数据量，并发数据插入的问题，通过各种调整，插入可以避免热块竞争，堆表的插入方式更是让插入的速度飞一般的，这足以让SQL SERVER （老版本）MYSQL （8.0） 以下的版本看的魂飞魄散。

另外通过哈希分区来打散数据的方法也让热表的查询变得简单，配合ORACLE 强大的 CBO ，查询速度也是很快。 另外如果你使用了 ORACLE ASM 那将会让 ORACLE 的 存储更上一个台阶，这无疑也是其他数据库都不能与之抗衡的。

而另一个星座的数据库则仅仅使用先进的算法和朴实的堆表存储结构，也可以和狮子的 闪电光速拳 较量一番。

据某一线的云尝试公布的测试结果，1000万的数据，神秘的星座（数据库）采用堆表的方式 120秒插入就结束了，数据合计44G，如果采用了目前此（AO表的方式，有局限性，适合大事务，和CASSANDRA 在数据处理方式有类似） 1000万的数据，在 80秒内就插入完毕，并且将44G数据压缩至 577MB。

——————————————————————————————

有人说，你为什么不提 RAC ，不提ORACLE 12 C 的多租户，不提ORACLE 12从的 IN-MEMORY ，以及 ORACLE  12C的 SHARDING 功能，这些.........

说实在的，真是不能提，

怎么样 非要提

OK  RAC 功能 强大 多少银行 ，金融行业都在用，强大的FAILOVER 功能.........

哎，你还是住口吧，已经是 2019年了，RAC 功能，连微软SQL SERVER 的 CLUSTER 都不用了好吧，那个功能 和你的 RAC 有什么不一样，还是一个存储，多个节点使用，已经老掉牙了，别再提了，现在都是分布式数据库的天下了，好好看看，现在还有哪家用这样的东西，就只有你ORACLE 了, 什么多节点操作，实现数据的唯一性，拜托没有强大的存储给你顶锅，你还能拽吗， 你用的那套存储，放到 SQL SERVER 我一样给你强大的多节点数据一致性。这个功能真不能在称道了，和 TIDB 新型数据库的存储模式相比，更是天上地下了。

ORACLE 12 C 的多租户, 这不就是炒别的数据库的冷饭，人家一个INSTANCE 多个数据库，你非要 一个INSTANCE 把一堆不同SCHEMA 的表放到一起，现在弄个多租户，其他数据库分分钟灭了你这个功能，谁不能在一台机器上装多个 INSTANCE，这个也不能提，纯属亡羊补牢的功能。

ORACLE 12从的 IN-MEMORY ，说道这个功能，SQL SERVER 笑了，你丫的不就抄袭我的 IN-MEMORY 功能， 我早就有这个功能了，别再抄了。

——————————————————————————————

以上算是搞笑，ORACLE 的窗口函数，函数索引，分区表的强大，这些的确是值得称道的， 但随着其他数据库的 奋勇向前，有的在窗口函数有所进步，有的在索引方面有所进步，分区表方面虽然ORACLE 值得炫耀，但不知道还有多少时间，另外随着分布式数据库的及 NEWSQL数据库的出现，分区这种对数据库的操作，很可能会被抛弃，世界发展之快，又有谁知道下一个谁是 诺基亚。

结语， ORACLE 作为 上世纪，数据库界神一样的存在，让人不能忘记，也必须被学习。 还是借助 《金刚经》 “过去心不可得，现在心不可得，未来心不可得”。 ORACLE 的未来 一定有他的席位，但要想要上世纪的闪耀，大概率的可能是  NO

——————————————————————————

下期就说说 ，那个被誉为  MYSQL 终结者， ORACLE  接班人的 数据库