Digest Net

阿里云李飞飞：云数据库战争下半场的数据库格局

2019-07-19T03:03:27Z

原文链接：https://juejin.im/post/5d15ceb3e51d455d6d535869

【编者按】DTCC 2019已经结束，云栖社区沉淀了很多阿里巴巴所分享的优质演讲整理稿件。这篇转载自IT168&ITPUB执行总编老鱼的公众号，分享给大家。

李飞飞，现任阿里巴巴集团副总裁、高级研究员，阿里云智能数据库事业部总负责人。加入阿里巴巴之前为美国犹他大学计算机系终身教授。研究成果多次获得了IEEE ICDE、ACM SIGMOD最佳论文奖等重要学术奖项。

2018年，李飞飞加入阿里巴巴达摩院，带领团队投入到具有自主知识产权的研究当中。目前，带领的阿里云智能数据库事业部所研发的新一代分布式数据库系统，支撑了阿里巴巴集团的复杂业务、海量数据和双11交易洪峰的挑战，已经被应用于多个城市的智能城市交通网络管理，并服务了金融、零售、物流、制造等行业企业。

2018年，阿里云数据库成功进入Gartner数据库魔力象限，这是该榜单首次出现中国公司，近日，阿里云数据库再次入选Forrester数据库评估报告，成为国内首个获得两大顶级机构认可的科技公司。

2019年5月10日，DTCC 2019(第十届中国数据库技术大会)在北京举办，李飞飞来到现场发表了精彩的主题演讲，并在大会期间接受了IT168&ITPUB执行总编老鱼的深度专访，众多独特观点精彩纷呈。

透露两条信息：

1、PolarDB从去年10月开始商业化到目前，已经成为阿里云上增长最快的数据库产品；

2、AnalyticDB已经通过TPC-DS打榜，做到了世界第一，性价比第一，数据在TPC-DS官网上已发布；

部分精彩观点摘录：

1、目前市面上所有的自研云原生数据库并不是真正意义上的分布式数据库，只能称之为分布式存储的数据库，因此，在下半场这或许会是一个突破点；

2、NoSQL和传统关系型数据库的边界会越来越模糊；

3、有很多厂商说自己的数据库是NewSQL，严格来讲，其实只是在某些维度实现了一到两个点，并没有完美解决NewSQL所有的技术挑战；

4、MongoDB协议修改得非常巧妙，其目的是为了获取云厂商的托管平台去做自己的云托管服务。

5、上半场各云厂商核心的竞争力其实是底层的托管平台，因此，云厂商绝对不可能去托管修改协议后的最新版开源数据库，让自身管控平台开源；

6、下半场两个发力重点：一个是不断地提升托管平台竞争力，二是一定要有自己自研的数据库内核，这是为什么大家都在自研数据库的原因，因为，仅仅靠托管平台的竞争力是拉不开身位差距的；

............................................................

以下是专访原文，为了便于阅读，在不影响原意的前提下，略做修改。

问：请从阿里云数据库产品线重要的产品节点和突破，来谈一谈阿里云在数据库领域的竞争力？

答：众所周知，数据库市场主要分为了以下几个板块：

一个是传统的OLTP，即所谓的RDBMS线上交易系统。最经典的商业的有Oracle、SQL Server，开源的有MySQL、Postgresql，OLTP是阿里云很大的一个板块。

第二个板块是OLAP在线分析，如Teradata，AWS Redshift都属于这个板块。

第三个板块是非结构化、半结构化数据处理需求带来的NoSQL数据库，如Hbase, Cassandra以及现在非常火的MongoDB、Redis都是属于这个板块。

最后一个版块是工具类生态的产品、数据传输、数据备份以及数据管理板块。

四大板块下面，又有运维管控平台，也就是俗称的云数据库托管平台，这几个模块就构成了云数据库体系和架构。

以上是数据库市场较大的板块，下面来讲讲阿里云在每个模块里最核心的一些产品和技术积累。首先，是最重要的OLTP板块，可以细分成两类：

一类是托管产品，即第三方的商业数据库和开源数据库，比如像SQL Server、MySQL、Postgresql等，主要是为了给客户提供丰富的选择，使客户可以无缝地把线下数据库迁移上云。

第二类是自研云原生数据库，这里面最主要的重量级产品就是PolarDB。PolarDB是一个基于分布式共享存储的云原生数据库，利用分布式共享存储，带来的好处是存储和计算进行了分离、解耦，解耦以后可以在存储和计算分别进行弹性扩容，做到极致的弹性，对云上客户极具吸引力。因为，云上客户需求一个很关键的点就是按需按量使用，同时进行按需按量计费。

除此之外，PolarDB还有很多技术，比如高可用，利用三副本及分布式数据一致性协议，Parallel-Raft做到金融级高可用的性能，使客户不用担心RPO、RTO的问题。另一个就是在分布式存储以及上面一写多读的多计算节点再上层又做了一个智能化的代理层，可以做到智能、自动的Low balance，计算节点之间的负载均衡分配技术等。这些结合起来，使得PolarDB在云原生上的OLTP数据库处理上具有很大的优势。

比如说，PolarDB可以做到分钟级的弹性缩扩容，从2个Core弹到32个Core只需要大概五分钟，从2个节点弹到4个节点也只需要几分钟，缩扩容从几个TB支持到一百个TB都没问题，可以支持单机点百万QPS处理性能，对云上客户、对弹性、高可用、负载均衡等等都有非常好的解决的方案。在云上的应用是非常有竞争力的，相对于传统On- Premise数据库的架构，PolarDB有非常大的竞争力。

我可以非常自信地说，在阿里云上的PolarDB，无论是从性能、技术上，都已经达到甚至在某些地方超越了AWS Aurora。阿里云也在国际顶级的技术分享会议如SIGMOD、VLDB发表了论文介绍阿里的技术。

从商业上来讲，从去年10月开始商业化到目前，PolarDB已经是阿里云上增长最快的数据库产品，实际使用PolarDB的客户从新零售到金融，再到传统的制造业，各个行业都有，非常多的企业开始将数据库应用迁移到PolarDB上面，这是OLTP板块的情况。

在OLAP板块，我们一样也会分成托管产品和自研产品。托管比如说像传统的BI工具Tableau等，自研最主要的产品是AnalyticDB分析型分布式数据库，其主要特点是行列混存，能够做到多表复杂的中文查询，在秒级甚至毫秒级进行响应。

技术细节不展开讲，讲两个具体的例子，一个是最近做的TPC-DS打榜，TPC-DS大家知道是业界公认的对分析型数据库非常重要的一个Benchmark，我们有一个好消息，AnalyticDB已经通过TPC-DS层层考验，做到了世界第一，性价比第一，这个数据在TPC-DS官网上已经发布。另外，介绍整个AnalyticDB系统的论文，也会在今年的VLDB上宣讲，这两方面都可以从技术上来证明它的先进性。

从业务上来讲，AnalyticDB支持了从税务、城市大脑到公有云，从金融到地产等一系列各行业对海量数据高并发秒级在线分析的诉求，与PolarDB形成了一个天然的互补，从OLTP到OLAP形成了完整的数据链路。

最后,阿里云在NoSQL和工具类方面也有很强的技术布局，主要是通过集团的应用多年锻打出来的一些核心产品。比如，在工具方面我们有DTS数据传输，在不同的库之间，云上云下以及云上不同实例之间进行实时的数据增量一致性备份传输等等，这样可以使得客户快速的进行数据库的迁移，还有数据备份DBS服务。这一系列的产品都是从客户的角度出发，客户需要什么？客户的痛点是什么？我们拿到客户的需求来反推我们技术上要做哪些东西，做到了今天这样一个状态。

问：PolarDB对标的是Aurora，AnalyticDB对标的是Redshift，那么，阿里云数据库研发是有着自己既定的研发策略，还是采取的跟随策略？

答：从客观上来讲，在云上，不仅是数据库板块，从IaaS到PaaS，AWS绝对是先行者。他们的先进经验以及他们避免走过的弯路，我们没有必要一定要走完全跟他们不同的道路，我个人认为还是要集百家之长，要有一种开放的心态。

所以，回答您刚才的问题，我觉得我们一开始是一个Follower（跟随者），这个没什么不好意思承认的。但是我们要从Follower做到超越者，做到leader。通过几年的努力，我们现在已经做到了能够走出一条不同的路，做到了leader位置。那是怎样从Follower变成Leader的？核心诉求是从客户的需求出发。

阿里云有什么优势？阿里云的优势是能接触到中国广大的客户需求。AWS主要的市场在美国，美国客户需求和中国的客户需求有相同的地方，但也有不同的地方，比如说，很多大中型国有企业，美国没有这种组织架构，其需求和美国的商业公司肯定有不同。这是一个很具体的例子，会对我们的技术演进之路提出一些新的思考、新的挑战，也就会使我们最终会走出一条不同于Aurora的技术之路。

另外，我们背靠阿里巴巴集团，身处复杂的生态环境，从电商到线下的新零售，像盒马以及线上娱乐如优酷等等，不仅对我们的技术提出了非常大的挑战，也提供了极为丰富的练兵场。这是我们能够持续走下去并不断衍生出新技术的一个核心保障。

问：到目前为止，阿里云数据库产品线服务总计有多少个？

答：我们现在从托管产品到自研产品，加起来在16个产品左右。这些产品分成四大个板块：OLTP、OLAP 加NoSQL加工具，最后还有一个用户看不到的底层托管平台。底层托管产品不是独立的产品，它就是一个隐形存在。

从数据库产品数量上讲，大家其实大同小异，基本上都是在同一数量级，没有太大的差别。核心的差别是在OLTP和OLAP 板块。

阿里云已经从Follower做到基本与AWS持平，甚至在技术上某些领域做到了领先。比如说刚才讲的OLAP ， AnalyticDB的性能已经在TPC-DS上打榜，并排到了第一。通过和AWS官方Redshift对比（在AWS上去买Redshift跑同样的Workload），在TPC-DS的很多的Query，AnalyticDB的性能都是要优于Redshift。

另外，在某些领域，我们也做到了人无我有，即AWS不一定有，阿里云有。比如，在分布式数据库板块，因为集团的"双11"场景需求，我们需要做share-nothing的架构。因此，我们在PolarDB基础上做了PolarDB-X。这样一个share-nothing的分布式架构来支持"双11"海量高并发数据的应用场景支撑。

从AWS的角度看，没有和我们对标的产品。所以，现在云数据库时代是百花齐放、百家争鸣的状态，全球各个厂商，包括阿里，AWS、 Azure和Google大家在某些领域都有各自领先的地方，但在其他领域可能另外一个厂商又有领先的地方。客观来说，阿里云的数据库在国内无论是从市场、技术还是产品方面，都绝对处于领先地位，在国际上也完全是跟AWS拉齐的水平。希望后续竞争到下半场，我们能够在某些领域真正的做到领先者地位。

问：我们知道，像MongoDB等好几家开源数据库厂商都修改了许可协议，主要针对的就是云计算厂商，您觉得，未来两者之间会是一个怎样的关系？这是否是云厂商纷纷发布自研云原生数据库背后的推力之一？

答：这是个非常好的问题，我把这个问题延伸一下，不仅是开源数据库厂商会有动力和压力去做云原生方向的转变，传统的巨头如Oracle也绝对是不遗余力的要去往云原生云数据库这个方向去发展。

云原生数据库有很多技术点，最重要的是弹性、存储计算分离、隔离、多租户还有很重要的一点，要有自己的云托管平台。像Oracle或MongoDB要在云上提供服务，就必须要依赖于云厂商的管控平台，这也是为什么去年MongoDB修改协议的原因。

其实，MongoDB的协议修改得非常巧妙。它允许对MongoDB开源版本进行托管服务，但是如果要基于以后的版本继续提供服务，那么，下面的托管平台就必须要开源。也就是说，如果AWS或者阿里云要继续托管MongoDB的最新版本，底下的管控平台就要开源，开源以后MongoDB可以拿去做自己的云托管服务。事实上MongoDB也是这么做的，研发了自己的Atlas。从MongoDB最新的财报就能看到，其Atlas的增长已经达到了40%多，市场份额从去年年初只有百分之十几，到去年年底，Atlas云托管服务已经增长到MongoD整个营收的30%多。

MongoDB的思路很简单，比起让云厂商提供托管服务并基于MongoDB开源版来占领市场份额，它更希望自己做托管服务，加上自己的内核，来把蛋糕整个切下来，把云厂商定位成只是做IaaS（Infrastructure as a Service)的一层。MongoDB是一种策略，其他的开源数据库厂商包括商业数据库Oracle、SAP， Oracle做Oracle cloud，SAP也做自己的SAP Cloud，它们背后的思路和逻辑都是如出一辙。

云厂商的应对策略也很简单，继续托管产品，但只托管以前版本的产品，即对托管平台没有要求的开源版本，绝对不可能去托管最新版让自身的管控平台开源。云数据库之战上半场各个云厂商核心的竞争力在哪里？其实就是在底下的托管平台。因为，在上半场大家主要还是靠MySQL、PG以及商业的SQL Server这些数据库，来拉动线下的on- premise数据库市场往云上迁移，这是最核心的竞争力。

用户上云有两种选择，要么用托管的MySQL和PG或者SQL Server，或者就是在虚拟机里面自建。

这两个选择对客户来讲，云厂商的价值就是在托管平台来体现的。因为在内核上跟自建完全没区别。托管平台最核心的就是SLA的保证，Service-Level Agreement、RTO、RPO能够做到比自建要好很多或者说和自建SLA一样，但是成本要比它低。

对用户而言，可能需要强大的DBA团队，才能做到与托管平台一样的SLA保证。这可以极大减少运维的投入，这是上半场的态势。

下半场如果MongoDB等厂商做了自己的云托管服务，就会倒逼原来上了云托管服务的客户，回到虚拟机里面自建，把云厂商彻底地定位成IaaS。因为,现在对客户而言，比如说客户用MongoDB的Atlas，那相当于拿到了AWS或者阿里云托管平台提供的SLA的能力，但又不需要给云厂商直接付费，成本上有优势，可能就会去选择自建。

那云厂商怎么应对呢？有两点：第一是不断地提升托管平台竞争力。比如说我们阿里云上有一个叫SDDP的自动驾驶云托管平台，它是利用机器学习人工智能的技术，来对云托管平台上的数据库实例进行自动运维、自动优化等等，来确保托管平台的竞争力。第二个从内核的角度来说，为什么亚马逊、阿里和Google，都在自己做自己的云原生数据库？因为大家意识到，仅仅靠托管平台的竞争力是拉不开升位差距的，所以一定要有自己的自主可控的内核，而且这个内核能够和传统的on- premise DB有性能上的差异。针对云原生的一些特点，能够吸引客户从MySQL、PG、Aurora和MongoDB等迁移到自主开发的云原生数据库上来。

AWS是最典型的，率先推出了Aurora。在NoSQL领域又推出了DynamoDB，在分析领域推出了Redshift。MongoDB修改协议以后，它又推出了自己的DocumentDB。这一系列动作背后的逻辑，和前面讲的是一样的。我个人认为，这场比赛已经进入了下半场。总结来讲，作为云厂商，我们需要在两方面发力，一个是管控平台，通过智能化的手段，提高它的运维能力和效率，另外一个要提升它的安全可靠、可验证。AWS去年推出了QLDB、Quantum Ledger Database，利用区块链里面的Merkle tree技术，对数据库的运维日志进行验证。这样客户上云以后可以来验证运维日志，来确保做到了SLA的保障，这些是从管控平台要做的一些差异化。另外是从内核的角度，不断地去投入内核的研发，以能够和传统的数据库或者新生的像MongoDB数据库内核，进行差异化的竞争。以上是我认为的云数据库战场下半场的一些比较精彩的看点。

问：您提到了云原生数据库，我最近也总是听到几个词，云原生分布式数据库，分布式中间件等。如何去鉴别真正的云原生和伪云原生？

答：这个问题很好，传统的数据库架构是什么？是一种share-everything的架构，比如说一个本地磁盘上面可能有比较大的内存，可以插多个内存条，有比较大的内存池。再上面是计算，有共享的计算状态，有多个 Core。但是很关键的一点是transaction，或者有很多个 query进来，这些transaction和query在整个数据库从存储到内存，再到 Core都是共享状态的，这个就叫share-everything架构，也是传统的数据库架构，像Oracle、SQL Sever都是这种架构。

这种架构有它的优势，是共享状态所以Coordination比较容易做。但缺点是Scalebility（扩展性）会受很大的限制，所以就衍生出了分布式这个概念，分布式最核心的挑战就是要提供Scale Out以及Scale Up的能力。

Scale Out怎么做呢？比较经典的像Google Spanner的做法，是做一个share-nothing，然后做分库分表，做partition，做sharding。在shard之间如果有跨shard的查询和事务，就需要做分布式的查询和分布式的事务处理。这个就是分库分表、Spanner的架构，也是PolarDB-X的架构。这是一种，在share-nothing上面有两个分支，一个是原生的分布式架构。也就是说，实际上在底下是做了sharding和partition的，但客户不需要去感知。对客户来讲，业务逻辑不需要改，如果有分布式的事务处理，分布式查询就会自动搞定。客户不需要去担心怎么去分库分表，去拆分业务逻辑，这是一种。

还有一种就是您刚才问题里面提到的，利用中间件的形式做一个分库分表的解决方案，这个对业务逻辑是有侵害的。这需要数据库的服务商，或者是客户自己要对业务逻辑有很清晰的认识。比如说库存、订单，这两个库是分开的，平时也不会有交集。所以，在业务逻辑上，把它拆分成两个库，这两个库存在不同的节点，这就是一种中间件的解决方式，业界有很多这样的解决方案。

这种方案的好处是比较简单，劣势就是它没有像原生分布式数据库那样，对客户的业务逻辑有侵入式的改造。另外就是，它对事务分布式查询的支持，无法做到像原生的分布式数据库那么好。以上是关于share-noting分布式数据库。

现在，大家讲的所谓叫云原生分布式数据库。我认为这是一个伪命题、伪概念。实际上，现在所有的厂商在云数据库上还没有一个真正的分布式的架构，大部分都是利用分布式存储做共享存储，然后在上面做一写多读。比如PolarDB， Aurora都是这样的架构。它实际上是分布式的共享存储，上面做一写多读存储计算分离，这个是我认为现在所谓的云原生数据库或云原生分布式数据库最典型的一个架构，分布式利用RDMA快速网络做一个分布式共享存储。它看起来像一块盘，实际上它是一个分布式的磁盘，但对上层的kernel来讲，它看起来像一块本地盘。它带来的好处就是物理数据只有一份，它避免了像MySQL、PG这种传统的主备，需要在主库和备库之间做这种物理数据的备份的挑战。主库、备库写的节点和读的节点是一份物理数据，这样就带来很多很多好处。但严格来讲，它是一个分布式存储的数据库，不能把它叫一个分布式数据库。这和我们经典定义的分布式数据库还是有一些区别的，但是现在大家把这个叫云原生数据库或云原生分布式数据库。

在下半场再往前发展会出现一个什么现象？我个人认为，下半场可能会比较有突破点的地方，就是把刚才所说的真正的分布式架构通过shardin架构和云原生分布式共享存储的shared-storage架构（云原生分布式数据库从架构上来讲叫共享存储shared-storage架构）结合起来。这个结构的好处是什么？因为shared-storage用的是RDMA，RDMA是有限制的，比如跨AZ或者说更严重的情况，要跨区的时候，它不可能无限的扩，RDMA共享存储可能只能做到十几个节点、几十个节点。因为一旦跨了network swich以后，RDMA的性能损耗非常大，远程访问不可能做到和本地访问一样快，这样shared-storage架构就有限制。

最经典的Oracle RAC做到 10个节点、20个节点就没办法再往上了，但如果并发高到一定程度或者数量大到一定程度，只能再往上扩，Scale Out要一直往下该怎么办？这时候一定要做分布式partition、sharding这种架构，但是partition、sharding如果不用共享存储的话，带来什么影响呢？每个shard不能做太大，因为单节点就只能存这么多数据。也就是说可能要分很多个shard，分布式的transaction非常多，一旦有distributed commit，性能损耗是非常大的。所以这两个如果能结合起来，有一个好处就是还是可以Scale Out，因为我上面有share-nothing这一层，底下是共享存储的节点，每个shard就可以做得非常大。也就是说对同样的数据来讲，我只需要很少的shard就可以来支持。很少的shard也就意味着分布式跨shard的这种处理会大大减小，分布式的能力会大大提升。所以这两个结合起来，我觉得会是一个比较新、比较有意思的挑战。

问：接下来的一些问题，其实也一直比较困扰我。刚刚您说了分布式，其实过去还有一种分类，比如说SQL、NoSQL、NewSQL，那NewSQL和分布式数据库之间到底是一个什么关系？过去我会把它理解成SQL、NoSQL之外的就是NewSQL，分布式数据库和NewSQL之间是一个包含关系还是其他的关系？

答：这也非常好的一个问题，数据库的同仁和朋友很多时候会有一些混淆的地方。首先NoSQL虽然叫NoSQL，但它实际上含义并不是不要SQL，它是Not Only SQL的缩写，取了个巧叫NoSQL，但它实际上是指不仅仅是SQL的意思。NoSQL的最早发展是怎么来的？实际上来源于传统的关系型数据库，关系型数据库里面因为要保障强一致，也就是ACID，所以Scale Out能力是受到限制的，所以在做Atomicity、 Consistency、Avilability、Durability这些保证的Isolation的时候，和分布式fundamentally是有冲突的，当时的硬件技术、软件技术没有使得传统关系型数据库能够无限的水平拓展。

但以Google为代表的很多互联网公司，在当时确实需要数据和事务处理、查询处理能够无限的水平拓展，因为数据量太大了，每天运行的数据都要存，这是个无限增长的过程。而且这些数据还有个特点，它不一定是结构化的，它可能是半结构甚至非结构数据的，所以，就衍生出NoSQL这个概念。总结来讲，NoSQL最核心的理念就是把传统的关系型数据库里强一致的需求弱化，比如说Isolation level,传统关系型里可能要snapshot isolation，现在只要做到ReadCommitted就行了，只要没有脏读就可以。其它的应用，如果应用层需要更高的隔离机制，那就在应用层去写逻辑，用external Consistence的方法来解决，在数据库层面只需保证没有脏读，牺牲一定的数据一致性，换来几乎无限的水平拓展。这类系统最经典的就是Hbase、Google的BigTable、Cassandra等等，这就是NoSQL的来源。

总结来讲，就是为了提供无限的水平拓展Scale Out的能力，牺牲一定的一致性保障，主要是在Consistency 和Isolation上做一些牺牲，换来无限的水平拓展Scale Out的能力。

NewSQL怎么来的？在NoSQL大概发展了有十年左右，大概是在2008年、2009年那时候出来这个概念，到现在接近10年了。大家发现把一致性等推到应用逻辑层去写还是很多困难的，而且大家发现慢慢地发现对非结构化、半结构化数据也是有强一致性需求的。不是说传统的transaction事务处理只对结构化数据有需求，对非结构化、半结构化没这个需求。所以大家就发现NoSQL系统也得去保证ACID guarantee，所谓的eventual consistency，weak consistency guarantee在很多应用下不适用，所以还是要去做snapshot Isolation，在NoSQL的场景下，这是从事NOSQL的朋友发现有这个需求，从事关系型数据库的朋友发现了什么？比如说MySQL从5.7开始，PG11.0、11.2版本都加入了对Json的支持。典型的半结构化的数据结构，也就是说传统的关键性数据库仅仅支持结构化数据也不行了，它必须也要提供非结构化、半结构化数据的支持，也就是说两边都开始往中间靠。一个有强一致的guarantee，但是它只支持结构化数据，Scale Out能力有限。另外一个支持半结构化、非结构化数据，Scale Out能力很好，但没有一致性保证。两边都牺牲了一些东西，换来自己想要的，但后来越来越发现牺牲的东西客户也是需要的，不仅限于自己所保留的，所以两边都开始补齐缺失的功能。

两者都要有，就变成了"既要......又要......"的状态，这就变成了两方的结合，也就是NewSQL。所以最终我个人认为，如果NewSQL真能发展到最后变成比较常见的一个态势，传统的NoSQL和关系型数据库的边界就会越来越模糊。

也就是说,NewSQL它不等于分布式数据库，分布式数据库可以是NewSQL数据库。NewSQL里面很重要的是Scale Out能力，它首先肯定是一个分布式存储的架构。也就是说它不一定是分布式共享存储，但它肯定是有shard的，有partition。像HBase、MongDB都是shard default的最常见的一个态势。但分布式的数据不一定是分布式的数据库，这要看它是不是真正做到了分布式查询和分布式事务。因为有可能它做了shard，分布式的数据，但是查询和事务是所谓的叫perfect shardable workload。这个事务和查询只用看第一个shard就完成了，另一个查询只看第二个shard。所以虽然它有很多个shard，也有很多个查询和事务，但是具体到每一个查询和事务，都是单个shard搞定的。严格来讲，我认为它不是一个分布式数据库，只是对业务逻辑进行了比较巧的一个partition，使得它可以就完美地去并行处理。

真正的分布式数据库有两个特点：第一，数据肯定是分成了多个shard；第二，它的查询和transaction是有可能产生cross shard这种查询和cross shard transaction，这种叫分布式。传统的NoSQL只支持第一个特点或只支持第二个特点的。支持第二个特点的是牺牲了数据一致性(isolation level)，换来了它能够支持分布式事务、分布式查询的能力。

关于NewSQL，我个人认为一个真正好的NewSQL数据库，它必须是支持结构化、半结构化、非结构化数据，这第一点。

第二点是，优秀的NewSQL数据库要有非常好的水平拓展的能力和Scale Out能力，支持分布式查询、分布式事务，同时在单节点上又有非常好的弹性和Scale Out的能力。目前来看，还没有一个数据库可以做到完美的解决所有问题，还有一些其它的技术点像HTAP（混合的事务和分析处理）、读写并存怎样高效的去处理？还有多模multimode、多种数据形态在一个库里，怎样在统一界面去查询？如果能够完美地解决所有这些问题，我认为它就是一个比较优秀的NewSQL数据库。

目前来看NewSQL只是从技术概念上出现的一个东西。严格来讲，有很多厂商说自己的数据库是NewSQL，他可能只是在某些维度实现了一到两个点，但并没有完美解决我们刚才提到的NewSQL所有的技术挑战，所以我觉得，目前我们还是有比较长的路去探索的。

本文作者：老鱼笔记

NewSQL系统综述-NewSQL到底New在哪里

2019-06-26T08:28:57Z

原作者：Andrew Pavlo（卡内基梅隆大学）Matthew Aslett（451研究所）

转自：https://zhuanlan.zhihu.com/p/23866692

摘要

近年来出现了一种称为NewSQL的新型数据库管理系统（DBMS），它们号称有能力扩展现代在线交易处理（on-line transaction processing, OLTP）系统的工作负载，这对于以前的系统来说是无法做到的。NewSQL这个词是本文的作者之一在2011年的一篇讨论对传统巨头（Oracle，IBM，Microsoft）地位发起挑战的新型数据库系统的商业分析报告中提出来的。另一作者则曾经担任第一代NewSQL DBMS的系统的开发者。从2011年后，一些商业公司和研究项目开始使用NewSQL来描述他们的系统。

鉴于传统的DBMS已经发展了近40年，有必要仔细推敲一下NewSQL的优势是真如他们所说，还是仅仅是一种商业宣传行为。如果真的可以获得更好的性能，那么下一个问题自然就是它们是真的有技术突破，还是仅仅因为硬件方面的发展使得原来的问题已不再是瓶颈？

为了探讨这些问题，我们先讨论了数据库的发展历史，以此理解NewSQL出现的背景和原因。然后从一些细节方面深入讨论了NewSQL的概念，特点，分类，以及在各个分类下面的NewSQL系统。

数据库管理系统（DBMSS）的简要发展历史

第一代DBMS出现在1960年代中期。IBM开发的IMS用于记录土星V和阿波罗空间探索项目中的供应链和仓储信息。它第一个提出将应用代码和数据操作进行分隔的思想，使开发者只需要关注数据的产生和访问，无需考虑操作和访问这些数据的复杂性。1970年代，IBM和加州大学借鉴IMS的思想分别构建了System R和INGRES，成为第一代关系型的DBMS。其中INGRES很快被其他的大学用于信息系统，接着在1970年代后期进行了商业化。在同一时期，Oracle发布了第一版与System R的设计非常类似的DBMS。其他公司在1980年代早期也纷纷通过推出自己的DBMS系统获得了成功，包括Sybase和Informix。尽管IBM从未将System R开放给公众，但在它的基础代码上于1983年推出了一个新商用的关系型数据库系统----DB2。

为了克服关系模型和面向对象编程语言之间的失配问题，1980年代后期和1990年代早期左右出现了一种新型的DBMS。因为不具备像SQL语言那样的统一的标准接口，所以这种面向对象的DBMS并没有被市场大规模接受。不过，当主要的厂商在十年后添加了对象和XML支持，二十年后添加了面相文档的NoSQL系统之后，这类系统的许多设计思想最终被并入了关系型DBMS中。

在1990年代，另一个值得关注的事件是当今两大主要开源DBMS的诞生。1995年，MySQL起源于瑞典，它建立在ISAM的mSQL系统之上。PostreSQL则是在1994年由两个伯克利大学的研究生在QUEL的Postgres的代码上添加了SQL支持而诞生。

到了2000年代，由于互联网应用的兴起，对系统资源的需求受到了前所未有的挑战。互联网应用需要支持大规模的并发用户，并且要保持永远在线。但是这些新应用的数据库却因为无法支持如此大规模的数据和访问量而成为了整个系统的瓶颈。最简单直接的办法是不断升级DBMS的硬件系统，使用更多的CPU，内存和硬盘。但是这种方法只是提高了性能，并且呈现明显的收益递减效应。更糟糕的是，将数据库从一个机器迁移到另一个机器是一个比较复杂的过程，通常需要较长的停机时间。而这对于Web应用来说是不可接受的。为了解决这个问题，一些公司推出了数据库中间件，对原有的单节点数据库进行数据分片，并存放到由廉价机器组成的分布式的集群里。对于应用程序来说，数据库中间件是一个逻辑上的单节点数据库，但实际上它的存储横跨了多台物理机器。当应用向数据库发起操作时，数据库中间件会自动将操作指令发送到集群中的一个或多个节点来执行。节点执行之后将结果发送回中间件，再由中间件反馈给应用。比较著名的数据库中间件包括eBay的Oracle的集群和Google的MySQL集群。这种方法后来也被Facebook采用，建立了自己的MySQL集群并应用至今。

数据分片中间件在简单操作（如读取或更新单条记录）时能工作得很好，但对于在一个事务中更新多条记录或者JOIN表之类的复杂操作时就无能为力。例如eBay中间件要求开发者在其应用的代码里实现所有的JOIN操作。

于是一些公司不再使用数据库中间件，转而开发自己的分布式DBMS。原因有三个方面：1）传统的DBMS将重点放在一致性和正确性上，牺牲了可用性和性能。但是这种设计上的妥协不能满足Web应用大并发量和时时在线的需求。2）很多人认为使用一个完整功能的DBMS（如MySQL）的开销过大，3）同样地，使用SQL来执行简单的查询也被看做是一种过渡使用。

这些问题引发了2000年代NoSQL运动的诞生。NoSQL系统的关键是它们放弃了传统的DBMS强事务保证和关系模型，通过所谓最终一致性和非关系数据模型（例如键值对，图形，文档）来提高Web应用所注重的高可用性和可扩展性。其中最著名的系统是Google BigTable和Amazon的Dynamo。这两个系统最初并不对外开放（虽然现在都已经变成了云服务），所以其他的用户也创建了自己的开源克隆系统。包括Facebook的Cassandra（基于BigTable和Dynamo），PowerSet的Hbase（基于BigTable）。其他初创公司并没有使用Google或者Amazon系统的副本，但仍遵循了NoSQL的哲学，最著名的是MongoDB。

2000年代后期，出现了更具扩展性并且更廉价的分布式DBMS。使用NoSQL的好处（或者说人们想象中的好处）是开发者可以将精力集中在应用，业务或者组织方面，而不用担心DBMS的扩展性。但是，仍有许多应用不能使用NoSQL。因为它们无法放弃强事务和一致性的需求。通常这些都是需要处理复杂关联性数据的企业级应用（例如财务、订单系统，人力资源系统等）。包括Google在内的一些公司发现采用NoSQL DBMS会迫使程序员在应用开发过程中花费过多的精力来处理一致性数据以提高事务的执行效率。于是唯一的解决之道是：要么购买更强大的单节点机器来垂直扩展DBMS，要么开发自己的数据分片中间件来支持事务。无论哪种方法都非常昂贵，并不是所有人都能接受。在这种环境下NewSQL系统出现了。

NewSQL的兴起

本文关于NewSQL的定义是：这是一类现代关系型的DBMS，旨在为NoSQL的OLTP读写负载提供相同的可扩展性能，同时仍然提供事务的ACID保证。换句话说，这些系统希望达到NoSQL DBMS相同的可扩展性，又能保留从1970年代开始的关系模型和事务支持，使得应用可以执行大规模的并发事务，并使用SQL而不是特定的API来修改数据库的状态。如果应用使用了NewSQL DBMS，开发者不再需要像使用NoSQL一样在应用逻辑里处理最终一致性的问题。我们下面的讨论中，NewSQL的这个解释涵盖了许多学术系统和商业系统。

在2000年代中期出现了数据仓库DBMS，有人认为它们达到了这个标准。例如Vertica，Greenplum，Aster Data）。这些DBMS服务的对象是OLAP系统，并不能认为是NewSQL系统。OLAP DBMS重点是执行复杂的只读查询（例如聚合查询，多维度JOIN等），这些查询需要大量的计算，较长的执行时间，使用超大的数据集，并且每一个查询都是独一无二的。而NewSQL DBMS服务的系统则需要执行读写事务，并具备以下几个特征：1）短生存时间，即没有用户停顿；2）使用索引查询小数据集，不进行全表扫描或者大规模分布式JOIN；3）可重复执行，即不同的输入执行相同的查询。其他人提出了一个更窄的定义，其中NewSQL系统的实现必须使用：1）无锁并发控制方案；2）无共享分布式架构。第三节里列举所有的NewSQL DBMS都具备这个特征，因此我们也认同这个定义。

NewSQL的分类

基于上述的定义，我们可以来看看现在有哪些NewSQL DBMS。为了简化分析，我们将研究对象按照实现方式进行分组。我们分出了三个类：1）使用全新的架构；2）重新实现由Google和其他人在2000年代开发的数据分片基础架构，并在此基础上开发的数据库中间件；3）来自云服务提供商的database-as-a-service（DBaaS），同样基于全新的架构。

本文的两位作者都曾在NewSQL系统分类中考虑了替换现有单节点DBMS存储引擎的方案。最常见的例子是对MySQL默认InnoDB存储引擎的替换（例如，TokuDB，ScaleDB，Akiban，deepSQL）。使用新存储引擎的好处是用户可以获得更好的性能而无需修改应用，并且仍能够继续使用DBMS的周边工具和API。其中最有意思的是ScaleDB，它提供了透明的数据分片方案而不使用中间件，通过在不同的存储引擎之间重新分配执行。不过现在这个公司已经转向了其他问题领域。

除了MySQL，还有其他类似的扩展。Microsoft的内存Hekaton OLTP引擎用于SQL Server时几乎可以与传统的磁盘驻留表无缝集成。其他人使用Postgres的外部数据包装器和API钩子来实现相同类型的集成，但目标却是OLAP工作负载（例如Vitesse，CitusDB）。

现在我们认为这种单节点DBMS的存储引擎和扩展并不代表NewSQL系统，因此在我们的分类中将会省略掉它们。MySQL的InnoDB在可靠性和性能方面获得了长足的进步，因此为OLTP应用切换到其他的存储引擎变得没有十分的必要。我们承认从面向行的InnoDB引擎切换到列存储的引擎对于OLAP负载来说是有意义的（例如Infobright，InfiniDB），但一般来说，为OLTP负载替换MysQL的存储引擎业务是失败的数据库项目的墓地。

3.1 新型架构

这个分类包括了NewSQL系统最有趣的部分，因为它们是全新架构的，从头设计的DBMS。也就是说，跟扩展现有系统不同（如Microsoft的Hekaton for SQL Server），它们从一个全新的起点开始设计，摆脱了原有系统的设计束缚。这个分类中所有的DBMS都采用了分布式架构，对无共享资源进行操作，并且包含支持多节点并发控制，基于复制的容错，流控制和分布式查询处理等组件。使用一个全新的为分布式执行而设计的DBMS的好处是，系统所有的部分都可以针对多节点环境进行优化，包括查询优化，节点间通信协议优化等。例如，大部分的NewSQL DBMS都可以在节点之间直接发送内部查询数据，而不用像一些中间件系统一样需要通过中心节点进行转发。

在这个分类中的所有DBMS（Google的Spanner除外）都管理自己的主存储，有的是在内存中，有的是在磁盘中。也就是说，DBMS负责使用定制开发的引擎在其资源上分布其数据库，而不是依赖现成的分布式文件系统（例如HDFS）或存储结构（例如Apache Ignite）。这是很重要的一个特征，因为这使得DBMS能够"向数据发送查询"，而不是"将数据带给查询"，这意味着更少的网络流量。因为跟传输数据（不仅仅是元组，还包括索引，物化视图等）相比，传输查询所需的网络流量要少得多。

对主存储的管理还使DBMS可以使用比HDFS中使用的基于块的复制方案更为复杂灵活的复制方案，因此这种DBMS比那些建立在其他已有技术分层上的系统拥有更好的性能。在现有技术分层上建立的系统有所谓的"SQL on Hadoop"系统（如Trafodion），以及在Hbase上提供事务支持的Splice Machine等等，但我们认为这类系统并不是NewSQL。

但是新架构DBMS的使用情况是呈下降态势的。最重要的原因是许多用户担心这项技术太新，没有大规模的安装基础和实际的生产环境的验证。另外就是社群和有经验的用户数量比流行的DBMS要小许多，许多用户有可能无法使用现有的管理和报表生成工具。一些DBMS，例如Clustrix和MemSQL，通过兼容MySQL的网络协议避免了这类问题。

本类案例：Clustrix, Cockroach, Google Spanner, H-Store, HyPer, MemSQL, NuoDB, SAP HANA, VoltDB.

3.2 透明的数据分片中间件

现在有一些产品跟2000年代的eBay，Google和Facebook一样提供数据分片的中间件。用户可以借助它们将数据库分成多个部分，并存储到由多个单节点机器组成的集群中。数据分片比1990年代出现的数据库联合技术更难，因为每一个节点都要运行相同的DBMS，只维护整个数据库的一部分数据，且不能被不同的应用独立访问或修改。

集中化的中间件组件负责分配查询，协调事务，同时也管理数据的位置，复制和跨节点的数据分区。集群典型的架构是在每个节点上都安装一个中介层来与中间件通信。这个组件负责代替中间件在DBMS实例上执行查询并返回结果，最终由中间件整合。对应用来说中间件就是一个逻辑上的数据库，应用和底层的DBMS都不需要修改。

使用数据分片中间件的核心优势在于，它们通常能够非常简单地替换已经使用了单节点DBMS的应用的数据库，并且开发者无需对应用做任何修改。最常见的中间件目标系统是MySQL，这意味着为了保持与MySQL的一致性，中间件必须支持MySQL的网络协议。Oracle提供了MySQL Proxy和Fabric工具来做这些工作，但是其他公司也开发了自己的协议处理器来避免GPL授权问题。

尽管中间件使用户扩展数据库变得更容易，但它们仍需要在每个节点上安装传统的DBMS（例如MySQL，Post供热SQL，Oracle）。这些DBMS采用的是1970年代提出的面向磁盘存储架构，不能像新架构的NewSQL系统那样使用面向内存的存储管理和并发控制方案。以前的研究表明，面向磁盘的架构阻碍了传统的DBMS通过提升CPU核数和内存容量进行向上扩展。中间件方法会导致在分片节点上执行复杂查询操作的时候出现冗余的查询计划和优化操作（即在中间件执行一次，在单节点上再执行一次），不过所有节点可以对每个查询使用局部的优化方法和策略。

本类案例：AgilData Scalable Cluster, MariaDB MaxScale, ScaleArc, ScaleBase.

3.3 Database-as-a-Service

最后一个分类是云服务提供商的NewSQL方案，database-as-a-service，也称为DBaaS。通过这些云服务，用户不需要在自己的硬件设备上或者云端虚拟机上安装和维护DBMS。DBaaS的提供商负责维护所有的数据库物理机及其配置，包括系统优化（例如缓冲池调整），复制，以及备份。交付给用户的只是一个连接DBMS的URL，以及一个用于监控的仪表盘页面或者一组用于系统控制的API。

DBaaS的客户根据他们预计使用的系统资源来付费。因为不同的数据库查询在计算资源的利用上差距非常大，DBaaS提供商通常不会采用块存储服务（例如Amazon的S3，Google的Cloud Storage）常用的依据调用次数计费，而更倾向于采用预付费的订阅方式。即客户指定所需的最大的存储空间，CPU数量，内存空间等，服务提供商则会在服务期间保证这些资源的可用性。

因为从规模经济角度来看，DBaaS的主要提供商也是云计算服务的主要提供商，但几乎所有的DBaaS仅仅提供一个传统的单节点DBMS实例（例如MySQL）。Google Cloud SQL， Microsoft的Azure SQL, Rackspace Cloud Database, 以及Scaleforce Heroku都是这么做的。因为它们同样使用了从1970年代就沿用至今的面向磁盘的存储架构，我们不把这种单实例的系统算作NewSQL。一些提供商（例如Microsoft）对DBMS进行了一些改造，提供了对多租户的支持。

我们仅仅认为那些基于新型架构的DBaaS是NewSQL。最著名的例子是Amazon的Aurora for MySQL RDS，它与InnoDB的最大区别在于它使用日志结构化存储管理器来提高I / O并行性。

另外一些公司的产品并没有自己的数据中心，他们的DBaaS软件建立在公有云平台之上，例如ClearDB能够让客户将其部署在任何的主流云平台上。这么做的好处是用户可以把数据库建立在同一个地区不同的云平台上，以避免由于云服务中断而导致的停机。

Aurora和ClearDB是2016年这个分类下仅存的两个产品。我们注意到其他公司在这个领域的产品都失败了（例如GenieDB，Xeround），原有的客户不得不在他们关闭云服务前迁出他们的DBaaS并寻找下一个提供商。我们将他们的失败总结为超出市场需求，价格上与主要竞争对手没有拉开差距。

分类案例：Amazon Aurora，ClearDB

NewSQL的现状

接下来我们将讨论NewSQL DBMS的特点，以理解这些系统的创新之处。文末所附的列表是我们分析工作的总结。

4.1 主内存存储

自从1970年代以来，所有主流DMBS都采用了面向磁盘的存储架构设计。在这些系统中，数据库的主要的存储位置被假定为在一个可进行块寻址的永久性存储设备上，例如SSD，HDD。因为在这些设备上进行读写操作非常慢，DBMS使用内存来缓存从磁盘读取的块，并缓冲来自事务的更新。这是非常必要的，因为当时的内存非常昂贵，而且容量与磁盘相比非常有限。而现在内存的容量和价格都到达了可以将大部分的数据库都容纳进去的程度。使用内存作为主存储的好处是它支持针对性的优化，因为DBMS不必假设事务需要在任何时间随机地访问不在内存中的数据，许多需要处理诸如缓冲池或者重量级并发控制的组件不再是必须的，所以系统将获得更好的性能。

有一些NewSQL DBMS是基于主内存架构的，包括研究性的系统（例如H-Store, Hyper）和商业系统（例如MemSQL，SAP HANA，VoltDB）。这些面向主内存的系统的性能比面向磁盘的处理OLTP的DBMS要高很多。

将数据库全部放在主内存的思想并不是最新的。1980年代初，威斯康辛-麦迪逊大学的开创性研究为内存数据库DBMS的许多方面奠定了基础，包括索引，查询处理和恢复算法等。同时期第一个分布式主内存DBMS----PRISMA/DB被开发出来。第一个商用的主内存DBMS----Altibase则出现在1990年代。Oracle的TimesTen和AT&T的DataBlitz是这种方法的早期实现。

主内存NewSQL系统一个比较新的点是它有能力将数据库的部分子数据集驱逐到持久存储以减少内存的占用。这种类型的DBMS可以把容量比内存更大的数据库放到内存里，而无需切换回面向磁盘的存储架构。一般的方法是使用一个内部的跟踪机制，一旦发现那些不再被访问的数据元组，就立即将其驱逐出内存。H-Store的anti-caching组件可以将这些不被访问的数据元组存放到面向磁盘的存储器中，同时在数据库中添加一条"墓碑"信息来记录这些数据的位置。当事务试图通过"墓碑"记录访问元组时，它会被终止，然后另一个独立线程会将数据异步地放回到内存中。另一种支持"大于内存数据库"的变体是EPFL的一个学术项目，它在VoltDB中使用OS虚拟内存分页技术。为了避免假阴性，所有的DBMS在数据库的索引中保留了已驱逐元组的键，这使那些具有许多次级索引的应用在内存节省方面的效果变差。虽然不是NewSQL DBMS，Microsoft的Project Sibera for Heikaton的每个索引都保持了一个Bloom过滤器，以减少内存中用于跟踪已驱逐元组的内存开销。

MemSQL采用了完全不同的方法来实现"大于内存数据库"的功能。系统管理员可以手动设定DBMS将某个表存储为列格式。MemSQL并不为磁盘存储的元组在内存中保存任何跟踪元数据。它将这些数据组织在日志结构化存储中以减少更新的开销，这在传统的OLAP数据仓库通常很慢。

4.2 分区/分片

几乎所有的分布式NewSQL DBMS水平扩展方案都是将数据库分割成不相交的数据集，这称之为分区或者分片。

在分区的数据库上进行分布式事务处理并不是一个新的想法。这些系统的许多基本原理来自伟大的Phil Bernstein（和其他人）在1970年代后期的SDD-1项目中的开创性工作。1980年代的早期，两个开创性的单节点DBMS项目，Syste R和INGRES的小组同时创建了分布式版本。IBM的R系统是一个类似于SDD-1的，无共享的，面向磁盘的分布式DBMS。INGRES的分布式版本给人们留下最深刻印象的是它的动态查询优化算法，递归地将分布式查询分解成更小的部分。之后，威斯康辛-麦迪逊大学的GAMMA项目探索了不同的分区策略。

但是这些早期的分布式DBMS并没有真正获得成功，原因有两个。首先是当时硬件成本太高，大部分的客户不可能购买足够多的设备来构建数据库集群环境。其次是应用对分布式DBMS的高性能需求还没有成熟，当时对DBMS吞吐量的最高要求也只有每秒数千笔交易。而我们现在这两点原因都不复存在。构建大规模的数据密集型应用从未如此简单，部分原因是开源分布式系统工具，云计算平台和廉价的移动设备的激增。

数据库的表被水平划分为多个片段，划分的边界基于一个或多个列的值。这些列被称为分区属性。基于这些属性值，DBMS使用范围或散列的分区将每个元组分配给某一个片段。来自多个表的相关片段被组合在一起以形成由单个节点管理的分区。该节点负责执行所有访问存储在其分区中的数据的查询。只有DBaaS系统（Amazon Aurora，ClearDB）不支持此类型的分区。

理想情况下，DBMS应该能够在多个分区上分布式地执行查询，然后将所有结果合并为一个单一的结果返回给调用方。除了支持本地分区的ScaleArc之外的所有NewSQL系统都提供此功能。

分区是许多OLTP应用数据库都具备一个重要特性。这些数据库schema可以转换为树状结构，树的后代与根具有外键关系。然后依据这些关系关联的属性对表进行分区，使得单个实体的所有数据都能位于同一分区。举例来说，一个树的根节点可能是一个客户表，数据库将会根据每一个客户进行分区，将每个人的订单记录和账户信息存放在一起。这么做的好处是它使大部分的事务只需要访问一个单独的数据分区就够了。因为不需要使用原子通信协议（例如2阶段提交）来保证事务在不同节点上正确执行，又进一步减少了网络通信开销。

NewSQL DBMS中，NuoDB和MemSQL采用了与同质集群节点架构采用不同方案。NuoDB指定一个或多个节点作为每个数据库分区的存储管理器（简称为SM）。SM将数据库分成块（在NuoDB的术语中称之为原子）。集群中所有其他的节点被当做事务引擎（简称为TE），它是原子在内存中的缓存。当处理一个查询时，TE通过SM或其他TE可获得这个事务所涉及的所有原子。获得一个写入锁之后，对原子进行的任何更改都将广播给其他的TE和SM。为了避免原子在节点之间来回移动，NuoDB公开了负载均衡方案以确保使用的数据会驻留在同一个TE中。这意味着NuoDB最终会具备与其他分布式DBMS相同的分区，但它不必进行数据库的预分区或对表关系进行预定义。

MemSQL同样使用了一个类似的异构架构，包括只具备执行功能的聚合器节点和存储实际数据的叶节点。MemSQL与NuoDB最大的不同在于二者如何减少从存储节点拉到执行节点的数据量。在NuoDB中，TE会缓存原子来减少从SM中读取的数据量，而MemSQL的聚合节点不缓存任何数据，但叶子节点会执行部分查询，以此减少发送到聚合节点的数据量。这在NuoDB中是不可能的，因为存储管理器只有数据存储功能，没有执行查询的能力。

这两个系统都能够向DBMS集群中添加执行资源（NuoDB的TE，MemSQL的聚合节点）而无需对数据库进行重新分区。SAP HANA的一个研究性的原型系统同样采用了这个方法。不过，从性能和操作复杂度方面，异构架构是否比同构架构（即所有的节点都可以同时执行查询和存储数据）更优秀仍有待进一步通过实践来检验。

NewSQL分区的一个新的功能是部分系统支持实时迁移。它们允许DBMS将数据在物理资源间进行迁移，以达到系统重新平衡，缓解热点压力，动态增加/减少DBMS容量的目的。这一点跟NoSQL系统的重新平衡类似，但是难点在于NewSQL DBMS需要在迁移中仍然维持ACID的事务特性。有两种方法能够做到这点。第一种方法是将数据库组织成为许多粗粒度的"虚拟"（即逻辑）分区，并分布到各个物理节点上。这样当DBMS需要重新平衡的时候，它可以将虚拟分区在节点间移动。Clustrix和AgilData使用了这种方法，NoSQL中的Cassandra和DynamoDB也使用了这种方法。另一种方法是DBMS通过范围分区重新分布单个元组或多个元组来执行更细粒度的重新平衡。这类似于MongoDB NoSQL DBMS中的自动分片功能。 ScaleBase和H-Store等使用了这种方法。

4.3 并发控制

并发控制方案是事务处理DBMS中最突出和最重要的实现细节，因为它影响系统几乎所有的方面。并发控制允许最终用户通过多个程序访问数据库，而每个程序在都认为自己运行在专用数据库上。这一点非常重要，因为它提供了系统的原子性和隔离性保证，并由此影响了整个系统的行为。

除了系统并发控制方案外，分布式DBMS的设计的另一个重要方面是该系统使用集中式还是分散式事务协调协议。在集中式协调系统中，所有的事务操作都必须通过中央协调器，它负责决定事务是否得以执行。1970-1980年代的事务处理监控器（例如IBM的CICS，Oracle的Tuxedo）中采用了这种方法。而在分散式的协调系统中，每个节点维护访问其数据的事务的状态。节点之间相互协调来确定事务是否有冲突。分散式协调器具有更好的可扩展性，但为了产生和维护事务的全局顺序，DBMS的所有节点都需要与同一个高精度时钟保持同步。

1970-1980年代的第一代分布式DBMS系统使用了二阶段锁（two phase-locking，2PL）方案。SDD-1项目是第一个专用于由集中式协调器管理无共享节点集群中的分布式事务处理的DBMS。IBM的R类似于SDD-1，但是它的主要区别在于R系统的协调器是完全分散式的，它使用了分布式的2PL协议，这样事务可以锁定正在访问的节点中的数据项。INGRES的分布式版本中同样采用了分散的2PL和集中式的死锁监测。

几乎所有基于新架构的NewSQL系统都没有使用2PL，因为处理死锁问题的复杂度太高。当前的趋势是使用时间戳顺序并发控制的变体，其中DBMS假定那些违反串行顺序的事务不会执行交错的数据操作。在NewSQL系统中使用最广泛的协议是分散式的多版本并发控制（multi-version concurrency control, MVCC）。其中DBMS会在数据元组被事务更新时创建新的副本。维护多个版本的方案使事务即使是在其他事务同时更新相同数据时也能够成功地完成，也避免了长时间运行的只读事务阻塞写入操作。这个协议被多数基于新架构的NewSQL系统所采用，例如MemSQL， HyPer，HANA，CockroachDB等。虽然这些系统在实现MVCC的细节上使用了不同的工程方法进行优化，但是这个方案的基本概念并不是新的。MVCC最早是由在一篇MIT的博士论文中提出来的，第一个使用它的商业DBMS是1980年代Digital的VAX Rdb和InterBase。我们注意到InterBase的架构是由Jim Starkey设计的，他同时也是NuoDB最早的设计者，也是失败的Falcon MySQL存储引擎项目的设计者。

其他的系统使用了2PL和MVCC的组合方案。这种方案中事务仍然需要在2PL模式下请求锁来更新数据库，而同时当一个事务修改了一条记录时，DBMS也为这条记录创建一个副本。这个方案使只读查询可以避免请求锁，因此不会阻塞写事务。这个方法最著名的实现是MySQL的InnoDB。另外还有Google的Spanner，NuoDB，Clustrix也都用了这个方法。NuoDB改进了原始的MVCC，它使用gossip协议在节点间广播版本信息。

所有的中间件和DBaaS服务都继承了它们底层DBMS架构使用的并发控制方案，因为大部分都使用MySQL作为底层DBMS，所以大部分的都是使用的2PL加上MVCC方案。

我们认为Spanner（及其后代F1和SpannerSQL）中的并发控制实现是最新颖的NewSQL系统之一。实际方案本身是基于2PL和MVCC组合，但Spanner最大的不同是使用了硬件设备（例如GPS和原子时钟）来做高精度时钟同步，为事务分配时间戳，通过广域网络实施其多版本数据库的一致视图。CockroachDB声称会提供与Spanner一样的跨数据中心的事务一致性，但不使用原子钟。它们依赖于混合时钟协议，该协议组合了松散同步的硬件时钟和逻辑计数器。

Spanner引人注目的另一个原因是它预示着Google将在最关键的服务中重新使用交易。 Spanner的作者甚至表示，最好让他们的程序员去处理由于过度使用事务造成的性能问题，而不是像NoSQL DBMS那样编写代码来处理事务的缺失。

最后，唯一没有使用MVCC及其变体的商业NewSQL DBMS是VoltDB。它仍在使用TO并发控制，不像MVCC那样交错执行事务，它通过调度使每个分区一次只有一个事务被执行。它还使用一种混合架构，其中单分区事务以分散方式调度，但多分区事务使用集中式协调器调度。VoltDB通过逻辑时间戳对事务进行排序，然后调度它们以便在轮到它们时在分区上执行。当事务在一个分区上执行时，它对该分区中的所有数据具有独占访问，因此系统不必在其数据结构上设置细粒度的锁和锁存器。因为没有来自其他事务的竞争，那些必须访问单个分区的事务得以有效地执行。基于分区的并发控制的缺点是，如果事务跨越多个分区，它不能很好地工作，因为网络通信延迟会导致节点在等待网络消息时处于空闲状态。这种基于分区的并发控制也不是新的想法。它的早期变体首先在1992年Hector Garcia-Molina的文章中提出，并在1990年代末在kdb系统和HStore（VoltDB的学术版本的前身）中得以实现。

综上，我们发现除了值得称道的工程方法使这些算法在现代硬件和分布式操作环境中更为高效外，NewSQL系统中的核心并发控制方案没有任何显著的新特点。

4.4 次级索引

次级索引包含来自表的不同于其主键的属性集。它允许DBMS支持主键和分区键以外的快速查询。当整个数据库位于单个节点上时，在非分区DBMS中支持它们是没有太多意义的。但是在分布式DBMS中，不会总是以正好需要的属性值进行分区。举例来说，假设数据库根据客户表的主键进行了分区。但是可能会有一些情况希望通过客户的email地址反向查询客户的账户。因为数据库是按照客户主键进行的分区，DBMS不得不将这个查询广播到所有节点，这明显效率非常低下。

在分布式DBMS中支持次级索引有两个设计决策：1）系统在哪里存储它们 2）如何由事务上下文维护他们。在使用集中式协调器的系统中，类似数据分片中间件，次级索引可以同时放在协调器节点和分片节点。这个方法的好处是整个系统中只有一个版本的索引，更加容易维护。

所有基于新架构的NewSQL 系统都是分散式的，使用的是分区的次级索引。意思是说每个节点存储了索引的一部分，而不是一个完整的副本。分区索引和复制完整索引之间的折衷是，前面的查询可能需要跨越多个节点来找到他们正在寻找的东西，但是如果事务更新索引，它将只需要修改一个节点。在复制索引中，情况正好相反：查找查询可以仅由集群中的一个节点满足，但是任何时候事务修改次级索引关联的数据， DBMS必须执行一个分布式事务来更新索引所有副本。

Clustrix使用分散次级索引，将上述概念混合在一起。DBMS在每个节点上维护一个粗粒度（基于范围的）的索引的副本，而节点将索引值映射到分区。映射使用表分区属性之外的其他属性，这样DBMS可以利用映射关系将查询路由到适当的节点。因为次级索引将精确值映射到数据元组，于是查询通过索引就可以访问数据元组。这种两层的方法仅仅映射范围而不是单个的值，减少了保持索引副本在集群中同步所需的调度次数。

在使用不支持次级索引的NewSQL DBMS的过程中，开发人员创建次级索引最常见方法是使用内存中的分布式缓存（如Memcached）来部署索引。但是使用外部系统需要应用程序来维护缓存，因为DBMS不会自动更新外部缓存。

4.5 复制

客户为其OLTP应用保证数据的高可用性和持久性的最好的方法是复制数据库。所有现代的DBMS，包括NewSQL系统，都支持某种机制的复制。DBaaS有一个突出的优势是它将所有复制配置的细节都对客户隐藏，因此部署一个DBMS的副本变得极为简单，用户无需关心日志是否传输成功，数据是否同步。

在数据复制中有两个设计决策。第一个是DBMS如何使数据保持节点间的一致性。在强一致的DBMS中，事务的写入必须在被确认提交（即持久化）之前被确认并被安装到所有副本。这种方法的好处是副本可以提供只读的查询并且仍保持一致性。也就是说，当应用收到了事务提交的确认，则该事务对数据库的任何修改对于后续所有的事务都是可见的，无论它们访问哪一个DBMS节点。同时，这样意味着如果一个副本失效，系统并不会丢失任何更新，因为其他所有的节点都是同步的。但是维护这样的同步需要DBMS使用原子提交协议（例如两阶段提交）来确保所有的副本与事务的执行结果一致，而这带来了额外的开销，并且如果节点失败或者有网络分区延迟则，也可能导致系统停滞。这就是为什么NoSQL系统选择弱一致性模型（也称为最终一致性），其中并非所有副本都必须在DBMS通知应用程序写入成功之前确认修改。

我们所知道的所有NewSQL都支持强一致性复制。但是在系统如何保证一致性方面并没有任何创新。在1970年代研究了DBMS的状态机复制的基本原理。NonStop SQL是在1980年代构建的第一代分布式DBMS之一，它就使用了相同的强一致性复制提供容错能力。

除了DBMS将更新传播到副本的策略之外，还有两种不同的执行模型用于决定DBMS如何执行此传播。第一种是主动-主动复制，其中每个节点同时处理相同的请求。例如，当事务执行查询时，DBMS在所有副本处并行执行该查询。这不同于主动-被动复制，首先在单个节点处理请求，然后DBMS将所得状态传送到其他副本。大多数NewSQL DBMS实现第二种方法，因为它们使用非确定性并发控制方案。这意味着它们不能向副本发送查询，因为它们可能在不同副本上以不同的顺序执行，并且数据库的状态将在每个副本处出现分歧。因为执行顺序取决于很多因素，包括网络延迟，缓存停滞，时钟偏差等。

另一方面，确定性DBMS（例如，H-Store，VoltDB，ClearDB）不执行这些附加的协调步骤。这是因为这些DBMS要保证事务的操作在每个副本上以相同的顺序执行，从而保证数据库的状态相同。VoltDB和ClearDB还确保应用程序不会执行那些使用外部信息源的查询，因为这些信息在每个副本上可能是不同的（例如，将时间戳字段设置为本地系统时钟）。

另一个NewSQL系统的独特之处是通过广域网WAN来进行复制。这是现代操作环境的副产品，因为现在很少在远距离的数据中心之间部署系统。所有的NewSQL DBMS都可以通过配置实现广域网上的同步复制，但是这也会引起正常操作中很明显的延迟，所以异步复制的方式更为流行。据我们所知，NewSQL系统中只有Spanner和CockroachDB能提供广域网上强一致副本的复制方案。Spanner使用了原子钟和GPS来做时间同步，而CockroachDB使用的是混合时钟方案。

4.6 崩溃恢复

NewSQL系统容错功能的一个重要特征是使用了崩溃恢复机制。传统的DBMS容错方案的重点是保障数据的更新不会丢失，而NewSQL DBMS除了这点以外，还希望最小化停机时间。现代的Web应用希望能够一直保持在线，因为停机带来的成本实在是太大了。

单节点无备份系统中恢复的传统方法是，在DBMS修复后重新联机，它将加载从磁盘取得的最后一个检查点，然后重播其写入日志（write-ahead log, WAL）以使数据库到达崩溃前那一刻的状态。这种方法的经典实现被称为ARIES，是IBM研究人员在1990年代发明的。所有主流的DBMS都使用了ARIES的一些变体来实现故障恢复。

在有副本的分布式DBMS中，不能直接使用传统的单节点方法，因为当主节点崩溃时，系统将会自动提升某个从节点充当新的主节点，而之前崩溃的主节点重新联机后，因为DBMS已经有了新的数据，数据库并不停留在崩溃之前的状态，所以主节点不能直接从自己的检查点中恢复数据。恢复的节点需要从新的主节点或者其他副本中更新自己的数据，弥补在停机这段时间内缺失的数据。有两种方法来做这个事情：第一是恢复的节点仍然从自身的存储中加载最后的检查点和写入日志，然后从其他节点读取缺失的日志部分。如果这个节点处理日志的速度比数据更新快，节点上的数据最终会达到与其他节点上的副本相同的状态。如果DBMS使用物理日志，那么这种方法就是可行的，因为将日志更新直接应用到元组的时间远小于执行原始SQL语句所需的时间。另一种方法可以减少恢复的时间，即节点重新联机时丢弃其检查点，让系统给它另一个新的检查点，然后从这个点开始恢复。这种方法带来的一个额外的好处是，系统中加入新的副本节点时也可以用同样的机制。

中间件和DBaaS系统依靠底层单节点DBMS的内建机制来实现故障恢复，不过都增加了额外的主节点选择和其他管理能力。基于全新架构的NewSQL系统结合现成的组件（例如ZooKeeper, Raft）和他们实现的已有算法来做这类事情。所有这些都是自1990年代以来在商业分布式系统中可用的标准程序和技术。

未来趋势

我们预计，在不久的将来，数据库应用程序的下一个趋势是能够对新获取的数据执行分析查询和机器学习算法。这种通常也称为"实时分析"或者"混合事务分析处理（hybrid transaction-analytical processing，HTAP）"的应用通过分析新数据和历史数据的组合来进行知识推断，获得洞察力。比传统的商业智能只能基于历史数据进行操作要更为先进。对于现代应用来说，更短的周转时间非常重要，因为数据的价值在其创建时非常巨大，但随着时间推移逐渐减少。

在数据库应用里有三个方法支持HTAP。最为常见的一个方法是部署另一个DBMS，让其中一个专门处理事务，另一个处理分析查询。在这个架构下，前端的OLTP DBMS存储所有由事务创建的新数据，而在后端，系统使用抽取与转换（ETL，extract-transform-load）工具将数据从OLTP DBMS导入到另一个后台的数据仓库DBMS。应用在后端执行所有的复杂的OLAP查询，避免拖慢OLTP系统。所有在OLAP系统中产生的新数据也将会被推送到前端的DBMS中。

被称为λ架构的另一种主流系统设计是使用单独的批处理系统（例如，Hadoop，Spark）来计算历史数据视图，同时使用流处理系统（例如，Storm，Spark Streaming）来提供输入数据视图。在这个分离式的架构中，批处理系统周期性地对数据集进行重新扫描，并将结果批量上传到流处理系统，然后流处理系统将基于新的更新进行修改。

这两种方法都有一些固有的问题。最重要的一点是，在两个分离系统中进行数据传输的时间通常以分钟甚至小时来计算，而且在数据传输时应用程序不能进行数据处理。第二个问题是，部署和维护两种不同DBMS的管理开销巨大，因为人工成本占整个大规模数据库系统成本的的50%左右。

如果想要合并来自不同数据库的数据，还需要应用程序开发人员为多个系统编写查询语句。一些系统试图通过隐藏分离系统架构伪装成单个平台，例如Splice Machine，但是这种方法还有其他技术问题，因为在OLTP系统（Spark）中使用它之前，需要复制来自OLTP系统（Hbase）的数据。

第三个我们认为更好的方法是使用单个HTAP DBMS，它既支持OLTP工作负载的高吞吐量和低延迟需求，又允许在热数据（事务）和冷数据（历史数据）上运行复杂的长时间运行的OLAP查询。这些较新的HTAP系统与传统的通用DBMS不同的是，它们结合了最近十年来在OLTP（例如，内存存储，无锁执行）和OLAP（例如，列式存储，矢量化执行）领域的技术积累，而且只需要一个DBMS。

SAP HANA和MemSQL是最早的两个声称自己是HTAP系统的NewSQL DBMS。HAHA在内部使用多个执行引擎，一个用于更适合事务的行数据，另一个用于更适合于分析的列数据。MemSQL使用两个不同的存储管理器（一个管理行，一个管理列），但是混合在同一个执行引擎中。

HyPer原本使用H-Store风格的用于处理OLTP的并发控制。它切换到了带有MVCC的HTAP列存储体系结构，于是可以支持更复杂的OLAP查询。VoltDB甚至将他们的市场宣传策略从纯粹的OLTP性能转向提供流式语义。类似地还有S-Store项目，在H-Store架构之上增加了对流式处理操作的支持。始于2000年代中期的OLAP系统（例如，Greenplum）很可能将开始增强对OLTP的支持。

我们注意到HTAP DBMS的兴起意味着巨大的整体式OLAP数据仓库的衰落。这样的系统在短期内仍然是必要的，因为它们是所有前端OLTP应用孤岛通用的后端数据库。但是最终数据库技术的发展将允许用户执行跨越多个OLTP数据库（甚至包括多个供应商）的分析查询，而不需要移动数据。

结论

我们分析的主要结果是，NewSQL数据库系统并不是与现有的系统架构完全不同的新物种，而是代表数据库技术不断发展的下一篇章。这些系统使用的大多数技术已经存在于学术界和工业界的先前DBMS中很多年。但是以前这些技术只是独立地在某些系统中得到实现，因此NewSQL DBMS的创新之处在于它们将这些想法纳入了单一平台，而且人们付出了巨大的工程努力，作出了很多创新性的工作。虽然NewSQL DBMS是伴随着更廉价而丰富的计算资源出现的，但它们的应用范围和应用前景也因此而更为广泛。

同样有趣的是考虑NewSQL DBMS潜在的影响和未来的方向。鉴于传统的DBMS提供商的市场地位牢不可破，资金充足，NewSQL系统只能通过艰难的战斗赢得市场地位。在过去的五年中，一些NewSQL公司已经关闭（例如GenieDB，Xeround，Translattice）或者转向重点关注其他问题域（例如ScaleBase，ParElastic）。基于我们对一些公司的的分析和访谈，我们发现NewSQL系统的采用率相对较低，尤其是与开发人员驱动的NoSQL相比的时候。这是因为NewSQL DBMS的设计目标是支持事务性的工作负载，而这些应用大多数是企业应用。与Web应用相比企业应用对于数据库的选择更加保守。另外我们也发现NewSQL DBMS用于补充或者替换现有的RDBMS，但NoSQL通常用于新业务系统的开发。

2000左右OLAP DBMS刚刚兴起的时候，大部分开发商都被主要的技术公司收购。而NewSQL领域里目前还只有一家公司被收购。在2016年3月，Tableau宣布它收购了HyPer项目的初创公司。另外两个可能的例外是：

1）2015年3月苹果公司收购了FoundationDB，但是我们把它排除在外，因为这个系统底层是NoSQL的Key-Value存储，上面只有一层效率低下的SQL层；

2）ScaleArc收购了ScaleBase，但这起收购案发生在竞争对手之间。

这些案例中没有一个是传统巨头收购新兴公司的情况（例如2011年，Teradata收购Aster Data System）。反过来，我们看到巨头们更愿意在自己的系统上进行改进和创新，而不是去收购初创的NewSQL公司。2014年Microsoft在SQLServer上新增了内存Hekaton引擎来增强OLTP处理能力。Oracle和IBM的创新进度比较慢，他们最近才为系统添加了列存储扩展，与新兴的OLAP DMBS（例如HP Vertica和Amazon Redshift）展开竞争，并有可能在未来推出内存中的OLTP工作负载处理系统。

从更长期来看，我们将数据库的发展归纳为四类：

1）始于1980-1990年代的传统DBMS；

2）始于2000年代的OLAP数据仓库；

3）始于2000年代的NoSQL DBMS，

4）始于2010年代的NewSQL。

我们希望在这些分类中所有的核心系统将会支持某种形式的关系模型和SQL（即使它们还没有），并且会像HTAP DBMS一样同时支持OLTP操作和OLAP查询。当这一天到来时，这些标签将成为历史。

尚若水之品，怀君子之德 - 北京东城区分司厅小学

2019-04-22T06:17:33Z

东城区分司厅小学，2014年建校100周年，

校园内一棵300年历史的老槐树，见证了学校变迁的历史。

从最初的"京兆模范小学"到今天的"北京市东城区分司厅小学"，

不管时代如何变迁，学校始终坚持以德立校，以德育人，传承这一中华传统文化的精髓从未改变。

校门口，10个大字彰显了学校的立人之期："尚若水之品，怀君子之德"，

而雕刻着"向真向善向美"的文化石则是对学生们的培养目标。

学校梳理了 "怀德立范，一树百获"的文化核心价值观，

确定了"培养向真、向善、向美的社会人"的育人目标。

2019 Oracle的战略变化和 Don Johson 的裁员邮件

2019-03-25T04:57:07Z

在 Layoff 网站上，近期（2019-03-22）披露了一封 Don Johson 的邮件，其中阐述了Oracle战略的变化。Don 是Oracle的执行副总裁，带领 OCI 团队近万人的团队规模。这封邮件的信息可以一窥Oracle的变化。

原文链接：https://www.thelayoff.com/t/Ybg79FO

中文翻译：

团队，

我想与您分享今天发生的组织结构调整。

在过去几年中，随着Oracle逐渐发展成为云服务公司，我们已经看到了渐进式变革。这是整个公司的巨大转变，通常是我们的组织在其中心。它广泛而普遍地影响了整个业务 - 推动重组，重新调整投资，改变我们建立和运营服务的方式，以及发展我们与客户互动的方式。

在去年的Oracle Open World大会中，Larry明确了公司的愿景和方向：我们是一家企业云公司，为最严苛的客户需求和最具挑战性的工作负载提供支持。我们围绕两个重心重构组织：应用和基础设施。作为我们云计算业务的基础，OCI - Oracle的第2代云 - 为我们的客户提供安全，可靠的基础架构平台，支持我们业务，自治数据库和SaaS ERP。

公司的一切都围绕着这个清晰的愿景和方向。

今天OCI内部的变化将更好地与Larry的业务愿景保持一致。它将简化我们的产品和服务，将投资重点放在我们最具战略意义的优先事项上，并帮助我们更有效，更快地实现Oracle Gen 2 Cloud的全部承诺和覆盖范围。

请于3月22日星期日上午10点，也就是明天上午10点，参加OCI领导和我的全体会议，以获得有关这对我们的团队和业务意味着什么的更多信息。

OCI的业务比以往任何时候都更加强大，这个团队的未来是光明的。我要感谢大家的继续支持，因为我们加倍了解我们的战略要求。我们将建立区域，继续招聘和投资战略领域，并快速发展业务和客户。

--Don

英文原文：

Team,

I wanted to share with you context for the organizational restructuring happening today.

Over the past several years we've seen progressive change as Oracle has evolved into a cloud services company at its core. This is a giant shift across the company, often with our organization at its epicenter. It has affected the entire business broadly and pervasively - driving reorganizations, realigning investments, changing how we build and operate services, and evolving how we engage with our customers.

At last year's Oracle Open World, Larry was clear about the vision and direction of the company: We're an enterprise cloud company supporting the most demanding customers and the most challenging workloads. We're organized around two centers of gravity: Apps and Infrastructure. As the foundation of our cloud business, OCI - Oracle's Gen 2 Cloud - provides our customers with a secure, reliable infrastructure platform that supports the primary pillars of our business, Autonomous Database and SaaS ERP.

Everything in the company is aligning around this clear vision and direction.

Today's changes within OCI will better align with Larry's vision of the business. It will streamline our products and services, focus investments on our most strategic priorities, and help us to more effectively and rapidly deliver the full promise and reach of Oracle's Gen 2 Cloud.

Please join the OCI Leadership and me in an All Hands tomorrow, March 22nd, at 10:00 AM PDT to get more information about what this means for our team and the business.

OCI's business is stronger than ever, and this team's future is bright. I want to thank you all for your continued support as we double down on our strategic imperatives. We'll be building regions, continuing to hire and invest in strategic areas, and growing the business and our customers at a rapid pace.

--Don

以上信息仅供参考。

2019年Oracle 大举裁减工程师团队，或涉及上万人

2019-03-25T04:36:54Z

转引网络新闻：http://www.sohu.com/a/303383806_465914

本周Oracle效仿IBM的做法，实行未对外宣布的裁员，期望通过重组并向云计算转型来优化公司，对裁员一事几乎没有承认。

昨天Oracle挥起了裁员利斧。这家公司并没有透露确切的裁员人数和具体岗位，不过裁员规模显然很大。墨西哥裁员50人，新罕布什尔州裁员50人，印度裁员100人，硅谷也至少裁员100人――据theLayoff.com上的传闻报道和内部风声，裁员人数很快积少成多。这个网站为受裁员影响的人员开设了讨论区。

传闻满天飞，不过全球裁员数量似乎多达数千人。theLayoff.com上的一则匿名帖子似乎给出了实际的数字，表明裁员目标总数占Oracle全球员工总数的10%，2018年员工总数约137000人。发帖人表示，今年将分三个阶段裁员，第一个阶段约5000名员工将被裁。

裁员对Oracle来说根本就不是什么新鲜事；2017年，该公司在硅谷裁员近1000人，主要来自SPARC团队和Solaris团队。但这次裁员行动的突然性和隐秘性，还是让员工和观察人士大跌眼镜。这次裁员不但缺乏透明度，还很突然，这让人想起了IBM过去的裁员潮。

Oracle的裁员日始于太平洋夏令时上午5点，当时Oracle执行副总裁Don Johnson发送了一封标题为"组织重组"的电子邮件，发到了员工的收件箱。该邮件告知工作人员：将来，公司的一切工作都将围绕Oracle云基础设施（OCI）业务展开。

Johnson写道："今天OCI内部的变化与拉里•埃利森的公司愿景更保持一致。它将简化我们的产品和服务，将投资重心放在我们最具战略意义的优先事项上，并帮助我们更高效、更快速地兑现Oracle第二代云的全部承诺和覆盖范围。"

该邮件随后的一句话让员工大为光火："OCI的业务比以往任何时候都更强大，该团队的未来一片光明。"

据悉，大概上午10点左右，离邮件发送过去才5小时，裁员就开始了。据传闻报道，大规模裁员牵涉这个比以往任何时候都更强大、未来一片光明的云业务的至少一部分人。那些受影响的员工有30分钟的时间交出公司资产、离开大楼，并被告知周五是他们在公司的最后一天。

一名Oracle员工称："这天早上感觉就像是一场屠杀。一个接一个。影响我的人走了，帮助我取得成功的人走了，优秀聪明能干的人都走了。这是糟糕的一天。一家公司最宝贵的资产莫过于它雇用的人员。今天的大裁员让我很想知道Oracle是否会意识到裁掉这些人犯了多大的错误。"

该员工还说，裁员过程的处理方式非常糟糕，整支整支的团队被集体叫到会议室，告知他们被统统解雇。该员工表示，技术团队受到的打击似乎最大，尤其是参与产品开发的团队，以及专注于软件开发、数据科学和工程技术的团队。

并不是只有这名员工觉得本周的裁员过程特别残酷。

theLayoff.com上的一位匿名发帖人写道："刚接到一位朋友的电话，说他就解雇了。最令他烦恼的是，告知裁员消息的是一名不是他直属上司，之前也从来谈过话的高管。"

一位Oracle经理发帖到："前一天我接到通知，称公司要开除名单上的一位员工，随后人力资源部门强行要求我在通告会上向他宣读最无情的裁员声明。我听说其他经理连手下员工被开除的通知都没有接到，他们在员工联系自己后才获悉裁员。更为糟糕的是，那些不得不通知下属裁员的经理一小时后自己也被解雇了。昨天对某些部门来说就是一场不折不扣的血洗，Oracle的处理方式极不厚道。"

被要求发表评论时，Oracle只给出了下列准备好的声明："随着我们的云业务不断发展，我们将不断调整资源，并重组我们的开发团队，以帮助确保我们有合适的人员为全球各地的客户提供最佳的云产品。"

2016年中国数据库市场销售规模超过100亿元

2019-03-25T03:40:38Z

注：关于中国数据库市场的容量和规模，数据总是较难获得，以下是转引的一则报道，其中数据可以作为一个概要参考。帮助读者了解中国数据库市场的情况。

原文链接： http://www.chyxx.com/industry/201708/553364.html

我国数据库技术亦如计算机技术的发展，起步较晚，大约始于七十年代中期。1977年11月，由中国科技大学在黄山主办了第一次数据库技术研讨会，标志着中国数据库软件产业进入了技术跟踪期，其后经历了三十多年的发展，中国数据库软件产业相继经历了强势垄断期、创新发展期，最终进入了目前的产品成熟期。

数据库软件是一种非常重要的基础软件，是我国信息化建设中需求量最大、应用最广泛的软件之一。国产数据库软件经过多年发展，已成功应用于政府、军队、教育、电力、金融、农业、卫生、交通、科技等行业和领域，为国家信息安全和国民经济信息化作出了巨大贡献。

近年来，随着我国信息化的深入发展，数据库软件市场规模快速增长，国产数据库软件也迅速崛起。智研咨询发布的《2017-2023年中国数据库市场深度分析及未来发展前景预测报告》指出：2015年我国数据库软件市场规模为85.37亿元，2016年我国数据量软件市场规模增长至101.45亿元。

2016年我国国内主要数据库企业：

南大通用销售收入为2.35亿元，占同期国内数据库市场规模总量的2.3%；
山东瀚高销售收入为0.58亿元，市场份额为0.6%；
爱可生销售收入为0.76亿元，占比为0.7%；
2015年人大金仓销售收入为0.59亿元，2016年销售收入在0.65亿元左右。

我国引入数据库始于20 世纪70年代，2016年我国数据库软件市场规模为101.45亿元，Oracle 数据库占比超过40%，

国产数据库软件主要有人大金仓、武汉达梦、神舟通用、南大通用、山东瀚高等，其中南大通用市场份额为2.3%。

云时代下，我国数据库产业，特别是DBaaS 产业受益两大因素迎来黄金机遇期：

（1）政策鼓励云计算发展；

（2）去IOE 和分布式改造背景下，银行、电力等部门数据库国产化需求强烈。

Oracle跟踪和诊断的利器: ORADEBUG 手册

2018-09-30T03:52:13Z

转载自：http://psoug.org/reference/oradebug.html

Oracle ORADEBUG

Version 11.1

GENERAL

Background Processes List

SELECT b.name, p.pid
FROM gv$bgprocess b, gv$process p
WHERE b.paddr = p.addr
ORDER BY 1;

Dispatcher Processes List

SELECT d.name, p.pid
FROM gv$dispatcher d, gv$process p
WHERE d.paddr = p.addr;

Job Queue Process List

SELECT s.paddr, s.sid, j.job
FROM gv$session s, dba_jobs_running j
WHERE s.sid = j.sid;

SELECT pid
FROM gv$process
WHERE addr = '17';

Parallel Execution Slave Processes List

SELECT pid, server_name, status
FROM gv$px_process;

Shared Server Processes List

SELECT s.name, p.pid
FROM gv$shared_server s, gv$process p
WHERE s.paddr = p.addr;

SGA Variables List

SELECT ksmfsnam
FROM x$ksmfsv
WHERE ksmfsnam LIKE '%\_' ESCAPE '\';

Switches

Switch	Format	Description
-G		Parallel oradebug command prefix
-R		Parallel oradebug prefix return output

CALL

Invoke function with arguments

oradebug call [arg1] ... [argn]

SQL> oradebug call ?

CLOSE_TRACE

Close trace file

oradebug close_trace

SQL> oradebug close_trace

CORE

Dump core without crashing process

oradebug core

SQL> oradebug core

CURRENT_SQL

Get current SQL

oradebug current_sql

SYS	UWCLASS
conn / as sysdba	conn uwclass/uwclass
GRANT execute ON dbms_support TO uwclass;
	SELECT pid FROM gv$process WHERE addr = ( SELECT paddr FROM gv$session WHERE sid = sys.dbms_support.mysid);
oradebug setorapid 26
	SELECT t.tablespace_name FROM all_tables t, all_indexes i WHERE t.tablespace_name = i.tablespace_name;
oradebug core

DELETE

Delete a watchpoint

oradebug delete watchpoint

SQL> oradebug delete ?

DIRECT_ACCESS

Fixed table access

oradebug direct_access

TBD

DMPCOWSGA

Dump & map SGA as COW

oradebug dmpcowsga

SQL> oradebug dmpcowsga "c: emp"

DUMP

Invoke named dump

oradebug dump [addr]

-- dump_name values can be obtained from oradebug dumplist

SQL> oradebug setmypid
SQL> oradebug dump library_cache 4

Invoke ASH dump

SQL> oradebug setmypid
SQL> oradebug dump ashdump 10

DUMPLIST

Print a list of available dumps

oradebug dumplist

SQL> oradebug dumplist

Available Dumps
ADJUST_SCN	HANGDIAG_HEADER	MMAN_ALLOC_MEMORY
ALRT_TEST	HEAPDUMP	MMAN_CREATE_DEF_REQUEST
ARCHIVE_ERROR	HEAPDUMP_ADDR	MMAN_CREATE_IMM_REQUEST
ASHDUMP	HM_FW_TRACE	MMAN_IMM_REQUEST
ATSK_TEST	INSTANTIATIONSTATE	MMON_TEST
AWR_FLUSH_TABLE_OFF	IOERREMUL	MODIFIED_PARAMETERS
AWR_FLUSH_TABLE_ON	IOERREMULRNG	NEXT_SCN_WRAP
AWR_TEST	IR_FW_TRACE	OBJECT_CACHE
BC_SANITY_CHECK	JAVAINFO	OCR
BG_MESSAGES	KCBO_OBJ_CHECK_DUMP	OLAP_DUMP
BLK0_FMTCHG	KDLIDMP	OPEN_FILES
BUFFER	KRA_OPTIONS	PGA_DETAIL_CANCEL
BUFFERS	KRA_TRACE	PGA_DETAIL_DUMP
CALLSTACK	KRB_BSET_DAYS	PGA_DETAIL_GET
CHECK_ROREUSE_SANITY	KRB_CORRUPT_INTERVAL	PIN_BLOCKS
CONTEXTAREA	KRB_CORRUPT_REPEAT	PIN_RANDOM_BLOCKS
CONTROLF	KRB_CORRUPT_SIZE	POKE_ADDRESS
CROSSIC	KRB_CORRUPT_SPBAD_INTERVAL	POKE_LENGTH
CRS	KRB_CORRUPT_SPBAD_REPEAT	POKE_VALUE
CSS	KRB_CORRUPT_SPBITMAP_INTER	POKE_VALUE0
CURSOR_STATS	KRB_CORRUPT_SPBITMAP_REPEA	POOL_SIMULATOR
CURSORDUMP	KRB_CORRUPT_SPHEADER_INTER	PROCESSSTATE
CURSORTRACE	KRB_CORRUPT_SPHEADER_REPEA	REALFREEDUMP
DATA_ERR_OFF	KRB_FAIL_INPUT_FILENO	RECORD_CALLSTACK
DATA_ERR_ON	KRB_OPTIONS	RECOVERY
DBSCHEDULER	KRB_OVERWRITE_ACTION	REDOHDR
DROP_SEGMENTS	KRB_PIECE_FAIL	REDOLOGS
DUMP_ADV_SNAPSHOTS	KRB_SET_TIME_SWITCH	REFRESH_OS_STATS
DUMP_ALL_COMP_GRANULES	KRB_SIMULATE_NODE_AFFINITY	ROW_CACHE
DUMP_ALL_COMP_GRANULE_ADDR	KRB_TRACE	RULESETDUMP
DUMP_ALL_OBJSTATS	KRB_UNUSED_OPTION	RULESETDUMP_ADDR
DUMP_ALL_REQS	KRBMRSR_LIMIT	SAVEPOINTS
DUMP_PINNED_BUFFER_HISTORY	KRBMROR_LIMIT	SELFTESTASM
DUMP_TEMP	KRC_TRACE	SET_NBLOCKS
DUMP_TRANSFER_OPS	KSDTRADV_TEST	SET_TSN_P1
DUMPGLOBALDATA	KSFQP_LIMIT	SHARED_SERVER_STATE
ENQUEUES	KSKDUMPTRACE	SIMULATE_EOV
ERRORSTACK	KTPR_DEBUG	SYSTEMSTATE
EVENT_TSM_TEST	KSTDUMPALLPROCS	SYSTEMSTATE_GLOBAL
EXCEPTION_DUMP	KSTDUMPALLPROCS_CLUSTER	TEST_DB_ROBUSTNESS
FAILOVER	KSTDUMPCURPROC	TEST_GET_CALLER
FBHDR	KUPPLATCHTEST	TEST_SPACEBG
FBINC	KXFPCLEARSTATS	TEST_STACK_DUMP
FBTAIL	KXFPDUMPTRACE	TR_CRASH_AFTER_WRITE
FILE_HDRS	KXFPBLATCHTEST	TR_CORRUPT_ONE_SIDE
FLASHBACK_GEN	KXFXCURSORSTATE	TR_READ_ONE_SIDE
FLUSH_CACHE	KXFXSLAVESTATE	TR_SET_ALL_BLOCKS
FLUSH_JAVA_POOL	LATCHES	TR_SET_BLOCK
FULL_DUMPS	LDAP_KERNEL_DUMP	TR_SET_SIDE
GC_ELEMENTS	LDAP_USER_DUMP	TRACE_BUFFER_OFF
GES_STATE	LIBRARY_CACHE	TRACE_BUFFER_ON
GLOBAL_AREA	LOCKS	TREEDUMP
HANGANALYZE	LOGERROR	TR_RESET_NORMAL
HANGANALYZE_PROC	LOGHIST	UPDATE_BLOCK0_FORMAT
HANGANALYZE_GLOBAL	LONGF_CREATE	WORKAREATAB_DUMP

DUMPSGA

Dump fixed SGA

oradebug dumpsga

oradebug dumpsga

SQL> oradebug dumpsga
c:\oracle\product\admin\orabase\udump\orabase_ora_2120.trc

DUMPTYPE

Print/dump an address with type info

oradebug dumptype

TBD

DUMPVAR

Print/dump a fixed PGA/SGA/UGA variable

oradebug dumpvar [level]

SQL> oradebug setmypid
SQL> oradebug dumpvar SGA kcbnbh

EVENT

Set trace event in process

oradebug EVENT
TRACE NAME CONTEXT FOREVER, LEVEL

SQL> oradebug setmypid

SQL> oradebug EVENT 10046 TRACE NAME CONTEXT FOREVER, LEVEL 12

SQL> oradebug unlimit

FFBEGIN

Flash Freeze the Instance

oradebug ffbegin

SQL> oradebug ffbegin

FFDEREGISTER

FF deregister instance from cluster

oradebug ffderegistger

SQL> oradebug ffderegister

FFRESUMEINST

Resume the flash frozen instance

oradebug ffresumeinst

SQL> oradebug ffresumeinst

FFSTATUS

Flash freeze status of instance

oradebug ffstatus

SQL> oradebug ffstatus

FFTERMINST

Call exit and terminate instance

oradebug ffterminst

SQL> oradebug ffterminst

FLUSH

Flush the current contents of the trace buffer to the trace file use

oradebug flush

SQL> oradebug flush

HANGANALYZE

Analyze system hang for stand-alone

oradebug hanganalzye [level] [syslevel]

SQL> oradebug setmypid;
SQL> oradebug hanganalyze;
SQL> oradebug flush;

Analyze system hang for RAC

SQL> oradebug setmypid;
SQL> oradebug -g def hanganalyze 1
SQL> oradebug flush;

HELP

Describe one or all commands

oradebug help

oradebug help

SQL> oradebug help
SQL> oradebug help flush

LKDEBUG

Invoke global enqueue service debugger

oradebug lkdebug

SQL> oradebug lkdebug

MAPCOWSGA

Map SGA as COW

oradebug mapcowsga

SQL> oradebug mapcowsga "c: emp"

NSDBX

Invoke CGS name-service debugger

oradebug nsdbx

SQL> oradebug nsdbx

PEEK

Print/Dump memory

oradebug peek [level]

SQL> oradebug peek 0x20005F0C 12

POKE

Modify memory. Never perform this function on a production database!

oradebug poke

SQL> oradebug poke 0x20005F0C 4 0x46495845

PROCSTAT

Dump process statistics

oradebug procstat

SQL> oradebug setmypid

SQL> oradebug procstat

RESUME

Resume execution

oradebug resume

SQL> oradebug resume

SESSION_EVENT

Set trace event in session

oradebug session_event

SQL> oradebug session_event 10053 TRACE NAME CONTEXT FOREVER, LEVEL 1

SETINST

Set instance list

oradebug setinst

SQL> oradebug setinst "1"

SETMYPID

Sets the oradebug PID to the current process

oradebug setmypid

SQL> oradebug setmypid

SETORAPID

Set PID of Oracle process to debug

oradebug setorapid ['force']

SELECT pid
FROM gv$process
WHERE addr = (
SELECT paddr
FROM gv$session
WHERE sid = DBMS_SUPPORT.MYSID);

or

SELECT pid
FROM gv$process
WHERE addr = (
SELECT paddr
FROM gv$session
WHERE sid = (SELECT sid FROM gv$mystat WHERE ROWNUM = 1));

/*
or one of the processes from the background, dispatcher, job queue, parallel, or shared server process lists
*/

SQL> oradebug setorapid 19

SETOSPID

Set OS pid of process to debug

The operating system process ID is the PID on Unix systems and the thread number for Windows systems

oradebug setospid

Do not use as it often fails. Use setorapid instead.

SETORAPNAME

Set Oracle process name to debug

oradebug setorapname

TBD

SETVAR

Modify a fixed PGA/SGA/UGA variable

oradebug setvar

SQL> oradebug setvar SGA kcfdfk 200

SGATOFILE

Dump SGA to file

oradebug sgatofile

SQL> oradebug ffbegin
SQL> oradebug sgatofile "c: emp"
SQL> oradebug ffresumeinst

SHORT_STACK

Get abridged OS stack

oradebug short_stack

SQL> oradebug short_stack

SHOW

Show watchpoints

oradebug show watchpoint

SQL> oradebug show?

SKDSTTPCS

Helps translate PCs to names

oradebug skdsttpcs

SQL> oradebug skdsttpcs?

SUSPEND

Suspends the current process

oradebug suspend

SQL> oradebug suspend

TRACEFILE_NAME

Get trace file name

Will not return a value on Windows systems

oradebug tracefile_name

SQL> oradebug tracefile_name

UNLIMIT

Unlimit the size of the trace file

oradebug unlimit

SQL> oradebug unlimit

WAKEUP

Wake up Oracle process

oradebug wakeup

SELECT pid
FROM gv$process
WHERE addr = (
SELECT paddr
FROM gv$bgprocess
WHERE name = 'SMON');

SQL> oradebug wakeup 7

WATCH

Watch a region of memory

oradebug watch

SQL> oradebug watch?

Demo

Taking a heap dump during a large (sorting) query

-- This example requires two sessions, session 1 logged on SYS AS SYSDBA and session 2 which
-- executes the query. In session 2 identify the PID using

SELECT pid
FROM gv$process
WHERE addr IN (
SELECT paddr
FROM gv$session
WHERE sid = dbms_support.mysid);

In this example the PID was 12

In session 1 set the Oracle PID using

ORADEBUG SETORAPID 12

In session 2 start the query

SELECT ... FROM t1 ORDER BY ....

In session 1 suspend session 2

ORADEBUG SUSPEND

The query in session 2 will be suspended

In session 1 run the heap dump

ORADEBUG DUMP HEAPDUMP 1

The heapdump will show the memory structures allocated for the sort. At this point further dumps e.g. subheap dumps can be taken.

In session 1 resume session 2

ORADEBUG RESUME

The query in session 2 will resume execution

Percona最新发布XtraBackup for MySQL 8.0

2018-09-13T02:11:32Z

原文链接：http://www.enmotech.com/web/detail/1/593/1.html

相关文章链接：http://www.enmotech.com/web/detail/1/577/1.html

更多精彩请关注"数据和云"公众号

我们的产品：http://www.enmotech.com/services/software.html

zData 一体机：http://enmotech.com/web/classify/26.html

Bethune（白求恩）：https://bethune.enmotech.com/

SQM：http://www.enmotech.com/web/classify/25.html

ZONE：http://www.enmotech.com/web/classify/28.html

在下文所有的废话之前,先说正事:

Percona在9月12日,终于宣布第一个测试用的XtraBackup for MySQL 8.0版本给大家试用:

（复制链接打开）https://www.percona.com/blog/2018/09/12/announcement-experimental-build-of-percona-xtrabackup-8-0/

MySQL 8.0今年4月份GA以来,虽然大家多有测试,但实际上敢用到生产环境的,只是极少数.而我个人认为最重要的原因之一,就是缺乏一个可用的备份工具.而在MySQL备份这件事情上,功德无量的Percona公司,却迟迟没有见到发布针对MySQL 8.0的备份工具,着实让人着急.

在9月12日之前,已知的MySQL 8.0的备份方式有这些:

官方MySQL商业版备份工具. 这个名为 MySQL Enterprise Backup 的软件,是官方商业版本的一部分,如果需要用,得掏钱买授权.先不说用的人比较少,使用文档本身也不在 MySQL 的公开文档导致学都很繁琐,就只是照着实例数收钱这点,就断绝了现在这种千库万表的 MySQL 大规模部署形势下的使用.

使用mysqldump命令.mysqldump 本身只是导出数据的命令行工具,但结合事务选项,以及master data选项,就可以导出满足一致性的备份SQL文件,即原生,又省心省力,对于小型数据库来说,是非常不错的选择(这里的小型,一般指的是100GB以下的数据库),但对于非常大个头的数据库来说,一来mysqldump是单线程导出,速度比较慢,说不定得搞一天,又由于MySQL的事务可见性的要求,undo文件会被执行导出的事务一直拖着不让缩小(如果没有使用独立表空间,那问题就更严重了-ibdata1过大的问题早年困扰不知多少DBA),导致磁盘空间比较大.而另外一个比较少遇到,但遇到就非常心碎的问题是,由于导出的是单个文本文件,如果文本文件中,某一个字节的存储出现问题,那么整个数据库的恢复就到此为止了.

FLUSH TABLES WITH READ LOCK;见过很多以为备份数据库就是把数据文件直接复制走的哥们,如果他们在复制文件前,使用命令停掉所有的写入,之后再复制,也不能说人家有问题,奈何大部分人就是少这一步,而且,考虑到8.0开始,授权表都是innodb了,如果不小心,导致授权表损坏了,那可真是苦都没地方哭了.

考虑到很多人的备份不追求事务一致性,但速度要快,这种情况下,还有两个工具可以用,一个是mysql自带的mysqlpump,和 mysqldump 不同,mysqlpump支持表级别的并行导出,加快了导出速度,但放弃了事务的一致性要求.而mydumper则是早年,社区开发的一款并行导出MySQL数据的命令行工具,可以在一个表上,发起多个基于主键(或者唯一键)分区的并行导出,速度更快.

备份是为了恢复,恢复就要讲究恢复时间,那怎么样加快数据的恢复时间呢?那就是MySQL复制给出的答案: 建立一个开启了延迟备份的从库,在需要恢复数据到指定时间点的时候,直接用start slave until命令搞定. 注:个人建议是,对重要数据库,以及超大数据库(比如1TB以上的),都使用这种方式,来降低恢复时间,参考官方文档:（复制链接打开） https://dev.mysql.com/doc/refman/8.0/en/replication-delayed.html

既然说起从库,那么在从库上,就可以很方便地搞备份了,比如搞一个没有业务访问的从库,需要备份的时候,停掉slave(政治正确的叫法是replication)线程,然后用前面提到的方式3,4进行备份,也不是不可以,或者说,考虑到主库需要承担访问压力,这种备份方式从效率和一致性,以及对线上业务扰动综合看,实际上是非常好的一个方式.

数据文件存在磁盘上,既然方式3可以用cp命令拷贝,实际上就是允许使用所有文件系统/块设备/存储设备的快照备份了,只要记得执行前后FLUSH TABLES WITH READ LOCK;,那备份就有保障了.

我故意漏掉了myisam这过时玩意的备份恢复的手段,估计没人看也应该没人用,就不写了.

在前面列举的种种备份中,最理想的,实际上就是MySQL Enterprise Backup这种,所谓真正的热备份,在备份效率,与备份的一致性,安全性等方面,都是非常好的选择,开源世界中,对应的就是 XtraBackup.

这里也不多说XtraBackup本身的意义与使用方式,估计用MySQL的DBA,没有几个没有折腾过这玩意的,下文主要讨论的,还是Xtrabackup for MySQL 8.0.

首先看看Percona公司自己的说法(以下为作者提取的重点,原文参考前面的链接地址):

虽然已经发布了,但版本号是 8.0.1,并且提示为实验性质的(experimental)alpha版本.

innobackupex命令终于被彻底删除,宣告一个时代的正式落幕,当然,也宣告着,很多MySQL自动化备份脚本需要改了.

由于MySQL 8.0数据目录,以及redo格式的种种变化,新的Xtrabackup for MySQL 8.0,仅仅提供给MySQL 8.0(以及Percona自己基于MySQL 8.0改的Percona Server),对于5.x版本,依然需要使用XtraBackup 2.4来备份,当然,也宣告着,很多MySQL自动化备份脚本需要改的地方更多了.

目前提供支持的操作系统版本为(其中Ubuntu 14.04 Trusty以及Debian 8 Jessie后续可能不再支持):

RHEL/Centos 6.x

RHEL/Centos 7.x

Ubuntu 14.04 Trusty*

Ubuntu 16.04 Xenial

Ubuntu 18.04 Bionic

Debian 8 Jessie*

Debian 9 Stretch

5. 如果需要下载,需要从Percona的repo源中下载,没有单独的下载地址(打算从官方软件下载页面找进去的同志可以放弃了):

centos 7 http://repo.percona.com/experimental/7/RPMS/x86_64/percona-xtrabackup-80-8.0.1-1.alpha.el7.x86_64.rpm

centos 6 http://repo.percona.com/experimental/6/RPMS/x86_64/percona-xtrabackup-80-8.0.1-1.alpha.el6.x86_64.rpm

至于其他发行版的同志,可以参考 https://www.percona.com/doc/percona-repo-config/index.html 这个地址的方法进行设置并下载

使用方法还是没有变化,想要试一把的同志,可以开搞了.

原创：刘伟。

投稿：有投稿意向技术人请在公众号对话框留言。

转载：意向文章下方留言。

更多精彩请关注 "数据和云" 公众号。

招聘专栏

云和恩墨（北京）信息技术有限公司

Oracle 售前工程师（广州、深圳、上海、武汉、北京、石家庄）

Oracle 高级工程师（上海、深圳、北京、成都、昆明、贵州、西宁）

MySQL 技术经理（上海、南京、成都）

MySQL 工程师（上海、杭州）

超高待遇：丰厚的年终奖，五险一金，高额学习基金，团建旅游，法定节假日，福利假期等。

推荐他人成功入职有好礼（iPhone X）相送。

投递简历至邮箱：hr@enmotech.com

对话李飞飞：在谷歌听得见炮火回斯坦福看下个方向

2018-09-12T07:18:59Z

文：本刊记者谢丽容刘以秦引自:https://news.cnblogs.com/n/606943/

　人工智能产业进入快速上升通道，这一切既有赖于过去六十年学术界的知识沉淀，更得益于近些年学术界和工业界互动效率空前。

　　一边是人工智能产业界最大巨头谷歌，一边是人工智能学术研究皇冠上的明珠斯坦福大学，李飞飞数度进出，完成了学术界和产业界的串联。

　　2016 年 11 月，谷歌云 CEO Diane Greene 向外界宣布，斯坦福大学终身教授，斯坦福大学人工智能实验室主任李飞飞加入谷歌，任谷歌云机器学习负责人。今年 9 月 11 日，在外界传言"李飞飞将离职谷歌"一事逾两月后，Diane Greene 再次向外界宣布，李飞飞将回归斯坦福大学进行学术研究，她的谷歌职位接任者，是来自另一个 AI 顶尖学府的卡内基梅隆大学的计算机科学院院长 Andrew Moore 教授。

　　9 月，在北京参加斯坦福大学的一个学术会议期间，李飞飞接受了《财经》记者专访。她向《财经》记者确认，随着斯坦福新学年的开学，两年学术假将满，当初加入谷歌和如今回归斯坦福，均在预计日程表上。今后，她不会完全离开谷歌，还将继续担任谷歌云的 AI/ML（Machine Learning）顾问。

　　在全球人工智能学术界中，由于是女性、华人，李飞飞是一位在中国认知度较高的研究学者。

　　她的主要研究方向为机器学习、计算机视觉、认知计算神经学。最著名的项目是 ImageNet，可以被理解为一个极大程度上方便了计算机对海量图像进行快速和准确识别的"数据库"，被几乎所有主流大小公司的机器视觉研究所采用，成为了学界和业界的标准。改变了人工智能的发展历史，促进了深度学习的崛起。

　　尽管 ImageNet 项目备受产业界欢迎，但在加盟谷歌之前的长达 18 年时间，直到近几年，她才和谷歌等产业公司有实质性的交集。

　　在谷歌近两年，李飞飞干了两件事。

　　第一件事情，推动成立 Google AI 中国中心。全程参与 Google AI 中国中心的规划和建设，推动将这一中心的成立定义为公司级的战略。李飞飞的光环，吸引不少中国 AI 人才加入。除此之外，李飞飞还参与了谷歌云的日常业务决策。

　　第二件事情，在谷歌推行"AI 平民化"理论，两年来，谷歌云结合既定战略，确实在推动 AI 平民化、降低 AI 使用门槛上有不小进展。

　　在谷歌云期间，李飞飞主持了一项名为 Cloud AutoML 的项目。这个项目被业内称为"Google Cloud 发展的战略转型"，这意味着一直以来面向开发者的 Google Cloud，这次将服务对象转向了普罗大众。

　　今年 1 月，AutoML Vision 上线，这是 Cloud AutoML 大项目推出的第一项服务，提供自定义图像识别系统自动开发服务。据谷歌介绍，即使是没有机器学习专业知识的小白，只需了解模型基本概念，就能轻松搭建定制化的图像识别模型。

　　到了今年 7 月，AutoML Vision 产品线已经从图像拓展到翻译、和自然语言处理领域。

　　如近期谷歌博客对外公布的信息，接下来，李飞飞将按照原定计划回到斯坦福大学，继续 AI 方面的研究工作。

　　得益于深度学习技术的突破，人工智能产业在这几年进入快速上升通道，这一切有赖于过去六十年学术界的沉淀和坚持，更得益于近些年学术界和工业界互动效率空前。李飞飞作为学术研究者，过去两年的两栖经历是一个缩影。

　　李飞飞认为，下一阶段人工智能产业的良性发展的趋势，除了 AI 学术界，包括人类学、社会学、法律学、伦理学、生物学等更大范围的学术界也需参与进来，和产业界形成新的互动模式。

　　谷歌的"炮火" VS 斯坦福的"灯塔"

　　《财经》：在谷歌和在斯坦福做研究区别一定很大？

　　李飞飞：是的，区别很大，也相当必要。直到 2017 年，AutoML 还是一个基础科学，论文刚刚出来，谷歌的研究环境让我们意识到，这不仅是学术的问题，可以直接解决产业界痛点。谷歌两年，时刻被产业需求和场景所触动，很多问题学术界此前并没有关注。

　　《财经》：所以很多人说，这一轮人工智能热潮是产业界推动的，在产业界能够更好的听到前方的炮火，从应用反推了研究。

　　李飞飞：科学家有两个不同的"前方"，一个是产业界的"前方"，是需求、应用和产品，这个"前方"，通常是有需求声音的，更像一种反馈；另一个是学术界的"前方"，是高瞻远瞩的思想，思想要走在需求之前。60 年前提出 AI 的时候，谁需要 AI？那个时候连个人电脑都还没有，那就是思想的前方。

　　我们 6 年前开始做 AI 医疗相关科研时，可能前方有需求，但是听不到声音的，这也是思想的前方，要做吗？一定要做。

　　今天的 AI 走到了一个历史性的时刻，既有产业界大量需求，需要普世、通用的 AI，研发出更好的产品，这既包括给产业赋能，也包括给消费者带来更惊喜的产品。同时，在思想界、学术界，也需要新的 AI 研究，点亮未来道路。

　　人类科技发展，就像在大海航行，每一次探索，都是走进黑暗的海域，你并不知道这艘船开往哪个方向，思想界、学术界的使命是造一座灯塔，照亮前方，让产业界得以继续进行。

　　《财经》：如果出现多座灯塔，产业界应该看什么？

　　李飞飞：出现多个灯塔是正常现象，不止是斯坦福大学在做基础科研，历史会告诉我们，哪一个灯塔是正确的。

　　《财经》：今天 AI 的灯塔，应该照亮哪几个方向？

　　李飞飞：其一，深度学习绝对不是 AI 的终极。深度学习依然很重要，在 AI 商业化落地方面还有很强的生命力。AI 作为一门科学，还有很多没有解决的难题，比如无监督学习（unsupervised learning）、迁移学习（transfer learning）等，都是 AI 技术前沿。我们下一步需要把脑科学、认知科学、生命科学的精髓和 AI 工程学结合起来。

　　今天的深度学习，是五六十年前神经生物学的一个火花，这么小小的一个火花，今天给人类带来了第四次工业革命，人类需要更多火花。

　　其二，说起 AI，很多人会担心人类被 AI 取代，我认为不是取代，而是辅助、强化（enhance），是助力。

　　其三，学术界有责任和使命，去结合经济学、伦理学、法律学，甚至政治学等，去了解 AI 会对人类产生的文化、伦理的影响。

　　《财经》：中国一些科技公司开始试图探索基础科学研究的无人区，比如华为、阿里，大型商业公司有能力建立自己的灯塔吗？

　　李飞飞：企业替代不了高校，美国的科技公司有基础研究的传统，最著名的经典案例是贝尔实验室，拿了那么多诺贝尔奖，今天，IBM、微软、谷歌、脸书、亚马逊都在做基础研究。商业公司加大了基础研究的力度，最大的作用是搭建了一座桥----可以更好地与学术界互动，双方可以尽可能近地交流、合作。如果学术界只做技术研究，产业界只做产品开发，双方很可能连话都说不上。比如，我作为斯坦福的研究者，我想和谷歌对话，我可以通过谷歌 AI 的研发团队，这是一个桥梁。

　　我很鼓励产业界有一部分基础研究，但产业界的 DNA 会让基础研究更重视应用，他们也需要和学术界有更多互动。

　　这个时代，基础研究越来越重要，但这需要耐心和定力，60 年前学术界点燃的火花，今天才看到成果。

　　《财经》：作为斯坦福的教授，您可以休长达两年的学术假到谷歌任职，有人说斯坦福是硅谷的沃土，也有人说硅谷带给斯坦福灵感，您是如何看待的？

　　李飞飞：这是硅谷的文化，非常鼓励学术界和产业界的互动，包括方方面面：作为教授，我们学术上的合作者，既来自产业界，也来自学术界；我们可以休学术假，可以像我一样去谷歌，也鼓励学生们创业，既可以和教授合作，也可以在工业界自己打拼。

　　《财经》：像一个成熟运转的机器体系？

　　李飞飞：硅谷很自由，机器是严丝合缝，设计好了就不会改变的，我更愿意说它是一个"生态"。硅谷不断推陈出新，是一个自由、有机的生态。这套生态体系下，我很幸运，短短两年在谷歌，几乎从零建立了一个几百人的团队，产品线体系也基本搭建起来了，既做了基础研究，也推出了很多重要的产品。

　　硅谷的产业、高校、研究机构这些点自由、开放地连接起来，才能形成一个良好的生态。

　　《财经》：回到斯坦福大学会做什么？

　　李飞飞：一部分精力继续 AI 医疗相关领域和 AI 基础科学的研究。同时，斯坦福大学在筹备一个新的校级 AI 项目，将在不久的将来公诸于众，我是这个项目的负责人。这个项目我们已经筹备了一年，接下来，这个项目和产业界包括谷歌也会有密切的合作。

　　深度研究 VS 落地前景

　　《财经》：我们事先找了很多人聊最想你谈的话题，大家最关心 AI 的实际落地和应用。

　　李飞飞：这是国内外都关心的问题，我在谷歌最大的收获，就是接触了很多传统行业，真正要让 AI 渗透到生活的衣食住行，就要通过不同的垂直领域来进行。

　　我目前最看好的是医疗健康的 AI 落地。我给你举一个例子。有一个数字大家不能忽略，在美国，GDP 的 15-16% 花在医疗上，1% 花在重症监护室（ICU），ICU 的整个工作流程中，AI 其实可以做很多事情。现在，大家在 AI 医疗的实践上，主要集中在医疗影像和数据分析上，这是很基础的应用。

　　比如人工智能在 ICU 领域可以做的一个项目，是减少院内感染。

　　医疗是一个非常复杂的过程，每一个环节都跟人命相关，稍微出一个错，就是生与死。美国每年因为医院感染死亡的人数是 9 万，远高于每年车祸死亡人数的 3.3 万，看似小小的医院感染这一个程序，不仅造成大量医疗事故，还导致大量医疗资源的浪费。

　　医院感染的主要原因之一，是医护人员手部消毒不规范。美国医疗系统如此发达，但依然没有好的方式来实时监控手部消毒的问题，你可能完全不能相信，美国医院要做院感的监控，很多情况下还是只能派一个人站在走廊里拿一个板子计数，这简直是中世纪的方式。这是 AI 很快就可以做的一件事情。通过智能感应器和深度学习的算法，可以做到实时自动提醒医护人员。

　　另一个人工智能可以切入的场景是健康，尤其是养老健康和医疗。

　　老龄化是很多国家都在面临的社会问题，老人最关切的诉求是能在家自理生活，延续生活高质量。目前，老人日常生活的行为数据，医护人员和家属很难去全面了解，很多时候你不并知道老人在做什么，一不小心就出事了。

　　我看到有公司做了可穿戴式的设备，但是老人不爱戴，原因很简单，这些可穿戴设备通常只能监控一两个指标，有的是专门针对糖尿病人的，有的是报警器，那么问题来了，你要保证一个老人的安全，他（她）需要同时穿戴多少个设备？

　　我们在斯坦福大学正在做的一个研究，是把智能传感器背后的算法加进来，对整个家庭生活场景进行全面联网分析，打破一个设备一个功能的状态。

　　不过，这个项目目前还在实验室阶段。目前的合作对象是旧金山的一个养老院，也有斯坦福大学。但是你可以想象，不久的将来，假设有老人的家庭有了这样的一个装备，会是另一个场景。我还要强调一下，这项目研究包括老人，但不仅限于老人，也包括慢性病的长期康复等。

　　《财经》：医疗健康之外的其他领域有没有很快就落地的机会？

　　李飞飞：AI 在其他领域也会有机会，比如无人车、金融业、制造业等。金融行业的数据量非常大，天然适合 AI。

　　谷歌云已经与保险公司展开合作，用户自己通过拍照就可以自动评估、车辆定损。这在美国已经相对成熟，整个流程变得轻了很多，金融还有很多应用的场景，比如金融反欺诈等。

　　不过还有一个方向让我觉得很兴奋，但是我目前还没开始做，是农业。

　　AI 会是人类公敌吗？

　　《财经》：很多人在讨论，人工智能技术发展的终极，是逐步取代人类。

　　李飞飞：说起 AI，很多人联想到第一个英文单词就是 Replace，我认为不是取代，而是助力（Enhance）。不管医疗、教育、制造业，协助工具至关重要。我们希望让大家看到，做 AI 医疗是为了帮助人类，不是取代人类。

　　《财经》：但人们会简单粗暴地认为，AI 取代人力，本来医院需要 200 个医生，AI 技术成熟后，就只需要 100 个了。

　　李飞飞：确实太简单粗暴了。这个问题需要经济学家和技术人士一起来讨论，举个例子，银行的自动取款机出现之后，很多人说银行会减少很多前台工作人员，但是数据表示，ATM 机增加的同时，前台的工作人员也增加了，为什么呢？机器把简单重复的工作减少之后，银行可以把金融的产品做的更丰富了。

　　作为一个科学者，我特别不喜欢把一件事情说得很夸张，无限放大优点和缺点，我们需要准确、理性地去传递。

　　《财经》：我们看到很多科幻作品里，有机器人伤害、取代人类的场面。

　　李飞飞：这里有一个例子。我有一个人类学家朋友曾经跟我分享，现在的美国青少年，会经常嘲笑自己的父母，因为他们的父母在跟智能音箱聊天的时候，总是习惯性说"谢谢"。她很想跟我探讨：AI 会给人类的文化带来什么影响？我们会不会教出一群不懂礼貌的孩子，反正 AI 不需要礼貌。

　　这是一个很小的点，甚至很多人不会在意。但是我的那位人类学家朋友提醒我：我们确实还不清楚 AI 会给人类社会带来什么，会不会下一代的孩子都没有礼貌了？

　　学术界有责任和使命，去结合经济学、伦理学、法律学，甚至政治学等等，去了解 AI 会对人类产生的文化、伦理的影响。这个非常重要，就业是一个问题，还有 AI 的透明性，公平性，可解释性，安全性等。

　　相比机器人会不会杀死人类，我们目前更应该注意到，AI 技术是时候需要开始与其他领域的专业人士深度合作统筹研究了，他们包括但不仅限于社会科学家、人文主义者、律师、艺术家和政策制定者。

　　《财经》：提到公平性，有人提出，AI 只会成为一小部分人的工具，而非全人类。

　　李飞飞：这个问题很好。这也是为什么我之前一直在强调 AI 的普世性。AI 的普世性，也是人类的灯塔之一。我们需要重视怎么让 AI 的可解释性更好，这些都会促进它往更好的方向发展。如果你把技术做到完全可解释，就很难把它做得不公平。

　　《财经》：现在全世界都在加强数据保护，这对 AI 的发展是好是坏？

　　李飞飞：AI 是人类的一个工具，工具需要被良性、正面地应用，需要尊重人的需求，人的价值观，现在欧盟出台的 GDPR 也好，其他国家打击数据隐私泛滥也好，都是短痛。短痛之后，是秩序。机器没有独立的价值观，机器的价值观是人类的价值观。只有以人为本的科技才能真正地造福人类。

数据库流行度排行榜

2018-09-03T02:32:34Z

原文链接：http://www.enmotech.com/web/detail/1/578/1.html

zData 一体机：http://enmotech.com/web/classify/26.html

Bethune（白求恩）：https://bethune.enmotech.com/

SQM：http://www.enmotech.com/web/classify/25.html

ZONE：http://www.enmotech.com/web/classify/28.html

排行榜的前十名中，最大的变化是 Elasticsearch 前进一名超过了 Redis，以1.67分的微弱优势改变了排名；此外主要数据库产品前四名都录得下降，这可能和炎炎夏日以及季节性假期有关。

前三名表现最好的是 Oracle 数据库，在上个月狂增34分之后，本月下降2.9分，Oracle 在 8月发布了 Oracle 18c 自治数据库的 OLTP版本，简称 ATP ,也就是说 Oracle Cloud 上自 8月开始提供 OLTP 类型的自治数据库服务，这将进一步推动 Oracle 云数据库的市场推进。

同时，在中国8月初举行的『甲骨文云数据库大会』上，Oracle 宣称将于 8月正式发布和腾讯云合作的『Oracle中国云数据中心』，然而时至9月1日，市场毫无声息，Oracle的中国云战略『海誓山盟、言之凿凿』的宣称了三四个年头之后，依然不断跳票。在中国的云市场上，Oracle 一直是『犹抱琵琶半遮面』，我们最担忧的是未来可能不再有人关心Oracle的中国云。

虽然 9 月 Oracle 积分小跌，但是较2017年同比，降幅大大缩窄，相信Oracle的版本发布计划将会持续刺激用户市场的活跃性。

排在第二位的 MySQL ，积分下挫 26 分，已经将上个月的涨幅跌去，并且创出了历年新低。

第三位的 SQL Server ，积分下挫 21 分，同样录的历年最低积分。

从下图趋势可以看出，在前三名的表现中，Oracle 似乎稳住了下降趋势，而 MySQL 和 SQL Server 尚未摆脱向下的势头。

紧随前3强的是 PostgreSQL 和 MongoDB ，这两个兄弟长久以来相伴相生，在历史上已经经过了积分的3度交错，作为后起之秀的 MongoDB 可谓后生可畏，今年以来积分上升了 10%，本月更是前五名中唯一获得增长的数据库产品。并且 MongoDB 已经获得了连续11个月的增长。

MongoDB 于2018年6月发布了 4.0 版本，这一版本的发布获得了市场的广泛关注，并且其云数据库战略发展良好，预计其增长势头将会继续维持。

受益于MongoDB 云数据库的成功，在2018年内，其股价已经获得了 146% 的涨幅，年初每股价格仅仅 29.25 ，而现在则是高达 71.96美元，市值接近40亿美元：

MongoDB公司公布2018第一季度收入同比增长49%至4820万美元，订阅收入增长53%至4460万美元，服务收入增长14%至370万美元。市场普遍看好其增长前景。

我们顺便来看一下Oracle近年来的股价，整体看波动不大，近半年有所下跌，但是如何改变后续的走势，是Oracle要靠时间来证明的 Cloud 战略成败。

最后总结一下数据库排行榜9月的表现，那就是：Oracle 老骥伏枥，志在千里，MongoDB 另辟蹊径，逆风飞扬。

解析 vcard规范二维码名片的格式

2018-09-03T01:19:34Z

引自：https://blog.csdn.net/johnsuna/article/details/8482454

如果你希望生成的二维码名片可以被智能设备识别，并可以直接导入到通讯录中，那么就应遵循某种标准格式。常见的是生成vcard标准格式。一个简单的vcard名片格式例子参考如下：

BEGIN:VCARD
VERSION:3.0
FN:任侠
TEL;CELL;VOICE:15201280000
TEL;WORK;VOICE:010-62100000
TEL;WORK;FAX:010-62100001
EMAIL;PREF;INTERNET:lzw#lzwme
URL:http://lzwme
orG:工作室
ROLE:产品部
TITLE:CTO
ADR;WORK;POSTAL:北京市朝阳区北四环;100101
REV:2012-12-27T08:30:02Z
END:VCARD

如果你想更详细的定制所需要的格式，则需要详细的了解vcard的格式标准。

3.1 vcard格式简介

vCard（或称做Versitcard）最早是由Versit联盟于1995年提出的，当时联盟成员包括苹果公司，AT&T科技（后来的朗讯），IBM及西门子。在1996年十二月，格式的拥有权移至因特网邮件联盟（IMC），此联盟是由一些关注因特网电子邮件的公司所组成。

vCard标准的2.1版被电子邮件客户端广泛支持。3.0版是一个包含在RFC 2425和RFC 2426中的IETF标准跟踪提案。vCard的常用文件扩展名是.vcf。

不同的程序对vCard标准实现亦不同。Mac OS X中的Address Book允许把所有联系人导出到一个vcf文件，而Microsoft Outlook只能每人一个文件。Linux中KDE的Kontact允许每个文件导入或导出一人或多人。

3.2 vcard标准通信薄基本格式

3.2.1 VCard 数据格式的标识符 - VCARD

　　预定义的值类型：uri, date, date-time, float
　　新增加的值类型：binary, phone-number, utc-offset and vcard value
　　预定义的类型：SOURCE, NAME, PROFILE, BEGIN, END.
　　新增加的类型：FN, N, NICKNAME, PHOTO, BDAY, ADR, LABEL, TEL, EMAIL,
　　MAILER, TZ, GEO, TITLE, ROLE, LOGO, AGENT, orG, CATEGORIES, NOTE,
　　PRODID, REV, SORT-STRING, SOUND, URL, UID, VERSION, CLASS, KEY
　　预定义的参数：ENCODING, VALUE, CHARSET, LANGUAGE, CONTEXT.
　　新增加的参数：TYPE

3.2.2 vCard数据格式行: 类型 [;参数]:值

　　ADR;HOME;POSTAL;PARCEL:;;街道地址;深圳;广东;433330;中国
　　ADR：是一个类型，表示是一条地址信息
　　";"号是分隔符合
　　HOME;POSTAL;PARCEL表示参数，表示ADR的用途或者是类别
　　:;;街道地址;深圳;广东;433330;中国表示是一个ADR值，地址值

3.2.3 预定义类型的用法　　

3.2.3.1 BEGIN 和 END 类型

　　Vcard内容必须以BEGIN:VCARD开头，以END:VCARD结尾vcard的类型标志特征详解

3.2.3.2 标识类型

　　FN 类型定义

　　目的：vcard对象的名称，一个vcard对象必须包含FN类型。
　　例子：FN:Mr. John Q. Public\, Esq.

　　N类型定义

　　目的：FN表示一个vcard对象的名称，N表示这个对象名称的组成部分
　　例子：N:Public;John;Quinlan;Mr.;Esq.
　　N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.
　　各个组成部分可以用分号分号，每个组成部分可以用逗号。

　　NICKNAME类型定义

　　目的：表示别名
　　例子：NICKNAME:Robbie
　　NICKNAME:Jim,Jimmie

　　PHOTO类型定义

　　目的：vcard对象的图像信息
　　例子：PHOTO;VALUE=uri:图片地址

PHOTO;ENCODING=b;TYPE=JPEG:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
<...remainder of "B" encoded binary data...>

　　如果使用内联的二进制数据表示图片信息，那么;ENCODING=b

　　BDAY类型定义

　　目的：表示出生日期
　　例子：BDAY:1996-04-15
　　BDAY:1953-10-15T23:10:00Z
　　BDAY:1987-09-27T08:30:00-06:00

3.2.3.3 联系方式

　　ADR 类型定义

　　目的：是一个组合，用来表示一个地址信息，值类型是一个用分号分开的文本值
　　例子：ADR;TYPE=dom,home,postal,parcel:;;123 Main Street;Any Town;CA;91921-1234;A
　　ADR;HOME;POSTAL;PARCEL:;;街道地址;深圳;广东;444444;中国
　　组合由一下部分顺序的组成：

　　the post office box;
　　the extended address;
　　the street address;
　　the locality (e.g., city);
　　the region (e.g., state or province);
　　the postal code;
　　the country name

　　七个部分组成，如果，其他的一个部分没有，必须用分号分开

　　type 参数的说明
　　"dom" 国内地址
　　"intl" 国际地址
　　"parcel"包裹递送地址
　　"home" 居住地址;
　　"work"工作地址;
　　"pref" 有多个地址的时候，优先的地址
　　缺省的"TYPE=intl,postal,parcel,work"，可以替换

　　LABEL类型定义

　　目的：是一格式化的文本值，表示一个地址
　　例子：LABEL;TYPE=dom,home,postal,parcel:Mr.John Q. Public\, Esq.\n
　　Mail Drop: TNE QB\n123 Main Street\nAny Town\, CA 91921-1234
　　\nU.S.A.

　　和ADR的不同是 ADR的值是用分号分开的数据，LABEL就是一个格式化的文本。
电话通信地址类型

　　TEL类型定义

　　目的：指定一个电话号码
　　例子：TEL;TYPE=work,voice,pref,msg:+1-213-555-1234
　　说明：值是一个规范的全球唯一的电话号码
　　TYPE参数的值有：

　　"home"表示家庭电话
　　"msg" 表示这个号码支持语音
　　"work" 工作电话
　　"pref" 表示多个电话中最喜欢使用的电话
　　"voice" 声音电话号码
　　"fax"传真号码
　　"cell" 表示手机电话
　　"video" 视频电话
　　"pager" 调度电话，估计是总机的电话
　　"bbs" 公开的广播系统的电话
　　"modem" 调制解调器电话
　　"car"汽车电话
　　"isdn" ISDN连接电话号码
　　"pcs" 个人通信服务电话

　　缺省是 "voice".
　　TYPE参数的用法是TYPE=work;TYPE=voice或者"TYPE=work,voice"，缺省值可以被重置
　　"TYPE=work,home,voice,fax".

　　EMAIL类型定义

　　目的：指定一个电子邮件
　　例子：EMAIL;TYPE=internet:邮箱地址
　　EMAIL;TYPE=x400:邮箱地址
　　EMAIL;TYPE=internet,pref:邮箱地址

　　TYPE参数的使用

　　"internet" 表示一个internet 类型地址
　　"x400" 表示是一个 X.400 地址
　　"pref"最喜欢使用的邮件电子

　　缺省是"internet".

MAILER 类型定义

　　目的：指定一个电子邮件发送者
　　例子：MAILER:PigeonMail 2.1

3.2.3.4 地理类型

　　TZ类型定义

　　目的：时区信息
　　例子：TZ:-05:00
　　TZ;VALUE=text:-05:00; EST; Raleigh/North America
　　缺省是一个utc-offset值.

GEO类型定义

　　目的：地理位置信息
　　例子GEO:37.386013;-122.082932
　　CEO 经度；纬度

3.2.3.5 组织类型

　　TITLE类型定义

　　目的：工作位置，工作职能（job title）
　　例子TITLE:Director\, Research and Development

　　ROLE 类型定义

　　目的：公司的职业（occupation）
　　例子ROLE:Programmer

　　LOGO类型定义

　　目的：公司logo，是一个图像信息
　　例子LOGO;VALUE=uri:图片地址

LOGO;ENCODING=b;TYPE=JPEG:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
<...the remainder of "B" encoded binary data...>

　　说明：TYPE知道图像的格式，ENCODING=b表示是二进制的数据流
　　URI表示是一个外部图像对象

　　AGENT类型定义

　　目的：指定另外一个人替换他的个人行为
　　例子：AGENT;VALUE=uri: CID:JQPUBLIC.part3.960129T083020.邮箱地址
　　AGENT:BEGIN:VCARD\nFN:Susan Thomas\nTEL:+1-919-555-
　　1234\nEMAIL\;INTERNET:主机地址\nEND:VCARD\n
　　说明：缺省是一个Vcard对象，当时也可是一个URI指定的外部Vcard对象

　　ORG类型定义

　　目的：表示一个组织的名称
　　例子ORG:ABC\, Inc.;North American Division;Marketing

3.2.3.6 解释类型

　　CATEGORIES类型定义
　　目的：vcard应用的分类信息
　　例子：CATEGORIES:TRAVEL AGENT
　　CATEGORIES:INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY

　　NOTE 类型定义

　　目的：对vcard的注释和说明
　　例子：NOTE:This fax number is operational 0800 to 1715
　　EST\, Mon-Fri.

　　PRODID类型定义

　　目的：指定创建Vcard对象的产品的ID
　　例子：PRODID:-//ONLINE DIRECTORY//NONSGML Version 1//EN

　　REV类型定义

　　目的：指定当前Vcard的修改信息
　　例子：REV:1995-10-31T22:27:10Z
　　REV:1997-11-15

　　SORT-STRING类型定义

　　目的：指定家庭名称或者其他名称对FN和N类型排序
　　例子：

FN:Rene van der Harten
　　N:van der Harten;Rene;J.;Sir;R.D.O.N.
　　SORT-STRING:Harten
　　FN:Robert Pau Shou Chang
　　N:Pau;Shou Chang;Robert
　　SORT-STRING:Pau
　　FN:Osamu Koura
　　N:Koura;Osamu
　　SORT-STRING:Koura
　　FN:Oscar del Pozo
　　N:del Pozo Triscon;Oscar
　　SORT-STRING:Pozo
　　FN:Chistine d'Aboville
　　N:d'Aboville;Christine
　　SORT-STRING:Aboville

　　SOUND类型定义

　　目的：指定Vcard的数字声音信息，缺省是指定vcard的name类型的发音信息。
　　例子： SOUND;TYPE=BASIC;VALUE=uri:CID:JOHNQPUBLIC.part8.
　　19960229T080000.地址
　　SOUND;TYPE=BASIC;ENCODING=b:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 <...the remainder of "B" encoded binary data...>

　　可以用URI指定一个外部声音二进制流
　　可以是内置的声音二进制流，ENCODING=b

　　UID类型定义

　　目的：指定一个全球唯一的个人或资源标识。
　　例子：UID:19950401-080045-40000F192713-0052
　　URL类型定义
　　目的：指定Vcard 参考的路径。
　　例子：URL: 网址

　　VERSION类型定义

　　目的：指定Vcard使用的vcard规范的版本。
　　例子： VERSION:3.0

3.2.3.7 Security 类型

　　CLASS类型定义

　　目的：指定访问Vcard对象的访问分级。
　　例子： CLASS:PUBLIC
　　CLASS:PRIVATE
　　CLASS:CONFIDENTIAL
　　说明：安全分级需要参考目录服务的访问分级

　　KEY 类型定义

　　目的：指定Vcard的公共钥匙值（加密解密是使用）或者是授权认证。
　　例子：

KEY;ENCODING=b:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQA
　　wdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENbW11bmljYX
　　Rpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
　　ZW1zMRwwGgYDVQQDExNyb290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDYwNj
　　E5NDc1OVoXDTk3MTIwMzE5NDc1OVowgYkxCzAJBgNVBAYTAlVTMSYwJAYD
　　VQQKEx1OZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3JwLjEYMBYGA1UEAx
　　MPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBFhJob3dlc0BuZXRz
　　Y2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqGSIb3DQ
　　EBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2
　　dXcoX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MB
　　EGCWCGSAGG+EIBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau
　　+hUMbsQukjANBgkqhkiG9w0BAQQFAAOBgQBexv7o7mi3PLXadkmNP9LcIP
　　mx93HGp0Kgyx1jIVMyNgsemeAwBM+MSlhMfcpbTrONwNjZYW8vJDSoi//y
　　rZlVt9bJbs7MNYZVsyF1unsqaln4/vy6Uawfg8VUMk1U7jt8LYpo4YULU7
　　UZHPYVUaSgVttImOHZIKi4hlPXBOhcUQ==

3.2.3.8 扩展类型

可以定义自己的类型，自己定义的类型需要以"x-"开头
比如例子中的信息：

　　X-QQ:000000
　　X-ICQ:icq
　　X-WAB-GENDER:2

本文来源于:『志文工作室 - 计算机基础技术学习博客』详细地址:http://lzw.me/Category/Learning/php-qrcode-vcard.html

Phonebook registration function formats	Property name	Parameter description
Name	N:	Designates a text string to be set as the name in the phonebook. (0 or more characters) When a field is divided by a comma (,), the first half is treated as the last name and the second half is treated as the first name.
Reading	SOUND:	Designates a text string to be set as the kana name in the phonebook. (0 or more characters) When a field is divided by a comma (,), the first half is treated as the last name and the second half is treated as the first name.
TEL	TEL:	Designates a text string to be set as the telephone number in the phonebook. (1 to 24 digits)
TEL-AV	TEL-AV:	Designates a text string to be set as the videophone number in the phonebook. (1 to 24 digits)
E-mail	EMAIL:	Designates a text string to be set as the e-mail address in the phonebook. (0 or more characters)
Memo	NOTE:	Designates a text string to be set as the memo in the phonebook. (0 or more characters)
Birthday	BDAY:	Designates a text string to be set as the birthday in the phonebook. (8 digits) The 8 digits consist of the year (4 digits), month (2 digits) and day (2 digits), in order.
Address	ADR:	Designates a text string to be set as the address in the phonebook. (0 or more characters) The fields divided by commas (,) denote PO box, room number, house number, city, prefecture, zip code and country, in order.
URL	URL:	Designates a text string to be set as the homepage URL in the phonebook. (0 or more characters)
Nickname	NICKNAME:	Designates a text string to be set as the nickname in the phonebook. (0 or more characters)

上面是MECARD的格式，是日本的docomo公司制定的，一般手机应该都能用，详细的说明文档在这。

还有其他俩种：VCARD 或 MEMORY 格式，Vcard这个比较常见，文档在这！

举俩个例子：
1.

MECARD:URL:http://www.liero.tk;EMAIL:liero@liero.tk;NOTE:I'm an EE Student;NICKNAME:Liero;;

MECARD:N:陈某某;ORG:某某有限公司;TIL:人事经理;TEL:13800138000;URL:weibo.com/siphp;DIV:siphp;EMAIL:xxx@163.com;ADR:中国深圳;NOTE:QQ :123456;;

一般这个是和二维码QR Code

Jonathan Lewis：我很为DBA们的未来担心（图灵访谈）

2013-11-26T07:31:08Z

转引图灵访谈，原文地址：http://www.ituring.com.cn/article/62995

Jonathan Lewis 世界级Oracle资深专家，有20多年Oracle关系数据库管理经验。主要从事自由咨询顾问工作，其Oracle数据库引擎方面的培训课程和研讨会世界闻名。Jonathan曾是UKOUG（UK Oracle User Group）的负责人，他著有多本Oracle方面的畅销书，并维护自己的Oracle技术博客。他的博客：http://jonathanlewis.wordpress.com

图灵社区： Oracle的自动化程度变得越来越高，很多需要人为介入的优化手段也变得越来越简单。在这种情况下，DBA怎么才能跟上发展、更好地提高数据库的效率？

JL：要想跟上Oracle的发展是十分困难的。我之所以无法完成我想要写的书，就是因为我总是跟不上（笑）。虽然我可以解决很多实际问题，就算面对全新的难题，我也可以通过了解Oracle的表现，结合它的工作原理，很快诊断出问题。但是我却无法反向推断，如果你告诉我某种情况，我可能无法说出Oracle会做什么。我现在已经很难再进行预测了，但是我可以根据问题找原因。跟上发展的意思我认为应该是预前判断Oracle的工作状态，要做到这些，我认为要有足够的经验。

阅读手册是十分重要的事。我认为市面上还有两三本书，也可以帮助你掌握必要的信息。Christian Antognini有一本书叫做《Oracle性能诊断艺术》，在这本书中，他讲述了很多Oracle运作的知识，以及如何利用工具找到问题，同时也提出了如何解决问题的建议，这样的好书会教你Oracle怎么工作，然后会举一些例子告诉你Oracle能完成什么。如果你仔细读过手册，也读过这些书，你就知道如何构造模型，如何用特殊方式建立两个表，如何选择查询，如何选择Oracle的特性......你可以亲手实践手册或者从《Oracle性能诊断艺术》里学来的东西，然后自己创造出一个可以解决自己实际问题的办法。通过亲力亲为的实践这些知识，你就会知道Oracle可以做什么，什么又是错的了。我认为实践是最好的学习方法。

但是很多人没有时间来做这些事。你的公司可能会说：9点到岗，5点之前不许下班。这样你就没有空余时间，一直都忙着做别人安排好的事情。每天重复做同样的事，一做就是5年，于是你没有时间跳出来，尝试一些新方法。

有两个办法可以帮你获取更多的经验。第一个就是像今天这样的大会是很好的机会。你可以离开你的工作，听听别人分享的经验。你会得到很多新的启发，也会找到解决问题的不同方法。得到这样的启发是大有裨益的。

另外一点就是，我作为一个咨询师，我工作的方式会让我每年大概接触到20家公司，我就会知道20种运作方式。大多数人只能有机会看到 Oracle如何工作的冰山一角，但是我几乎有机会看到全貌。所以关于在Oracle上可以做什么，我可能更有经验。常规公司的DBA经常会说：我们公司在过去5年中就是这么做的，我们有其他的办法吗？DBA们应该经常安排自己重头思考一下，忘掉自己惯常的做法和思路，重新读手册，看看能不能想到一些新的办法。对于我来说，如果我看到你们在做的工作，我可能会想出5种不同的方式来达到同样的目的，因为我见过这些方式。对于 Oracle来说，完成任务的方式多种多样，而普通DBA只能看到他每天接触的方式。所以，要成为出类拔萃的DBA，你就必须去了解和尝试不同的做法。这些学习会花费你的时间，但是这也是必须要做的事。

图灵社区：你作为一位独立Oracle性能专家是如何工作的？在接到一个新案子之后你询问的第一个问题是什么？

JL：我还是挺出名的，所以经常会接到电话或者是邮件说：我们这出问题了，你下个礼拜哪天有时间能来一趟吗？我大概每天工作3天时间，我还要留出一天做一些很重要的试验，来了解Oracle，了解更好的运作方式，剩下一天我会从事写作，无论是书还是博客。所以接到这样的电话，我通常都是有时间的，也许是下周，也许是下下周。

一般我在接到工作的时候，他们都会告诉我，哪里出了问题，需要我来做什么。在整个解决问题的过程中，我第一步需要了解的永远都是：你们想要这个系统做什么？出现问题时的状况是什么样的？并不是Oracle在干什么，机器在干什么，而是用户在做什么。然后他们可能就会说，银行系统处理了大批量的境外交易，每个月我们在做账目核对的时候，就会出现性能问题。这就会告诉我他们平常的进程是什么，当在某天引入特殊进程的时候就会出现严重的性能问题，这两个进程之间哪里发生了冲突，它们的运行机制是什么。经常会有这样的情况，在得知业务在做什么，然后转入Oracle问题的时候，我就可以预测出数据库服务器上Oracle出现的是什么类型的问题。一旦我得到整体的情况，就可以追踪到具体的代码了，我开始检查数据库结构，询问为什么要建立这个索引，想通过它做什么。然后重新运行，如果不行就导出性能数据，找出AWR报告、历史信息存储，以及其他Oracle能提供的信息，由此得出下一条线索。

图灵社区：我知道您满世界解决Oracle难题，现在您已经去过超过50个国家了。你有没有在这过程中遇到过很棘手很难解决的问题？

JL：中国应该是第52个国家了（笑）。确实有这样的情况，很难判断问题究竟出在哪里。有的时候问题其实是一个Oracle bug，但是很难证明。有时候会遇到关于并发行为很稀有的问题，两件事必须严格在同一时间发生才能出现这个问题。于是我就只能说有可能是什么出了错，于是解决方法很有可能就是需要绕过这个问题。有那么几次，我最终也无法说出是哪里出了问题，虽然我知道在什么条件会产生这样的问题，但是我无法给出足够的信息来从根本上解决这个问题，甚至都没办法提供足够信息找到Oracle向他们寻求产品改进。我们能做的只能是建立历史记录，证明问题确实发生了。还有几次，在我找出问题后，其他人在我之前找到了解决方法。在我从业的25年中，有一两次这样的情况。

图灵社区：你有没有打算建一个团队来从事现在的咨询业务？

JL：大家总在问我这个问题。他们总是说：我可以为你的公司工作吗？事实上，我没有公司。我觉得有了公司之后就要为这个公司负责，这样就没法一直做自己喜欢的工作了。而这两点对我来说都没有什么吸引力。我不想为找到合适的工作者而发愁，我无法给出这就是他们需要用来养家糊口的工作的保障。所以，可以说我从来都没有考虑过成立一个公司。

图灵社区：当你的孩子还小的时候，你不仅要写书，还要忙着满世界做咨询服务，你是如何分配你的时间的？

JL：在1999年，当我的孩子还很小的时候，我开始写我的第一本书，当时还没有人像我一样做Oracle 的咨询工作，大家当时都忙着重新编写程序，所以我觉得很有必要写一本书。我下决心花上半年的时间写这本书，暂时放下平常的工作。我告诉我的家人：我要写书了！第二天，我的女儿对我说："你还在写那本书吗？"她以为我花了一整天写书，第二天肯定应该写完了！

在我的孩子很小的时候，大概是12岁之前，我会尽量少出门做咨询，可以说我基本没怎么出远门。在他们大一些之后，我重新开始我的咨询工作，但是我会保证周末一定在家。我不会在一周内工作超过5天。今天大概是我25年中第三次，我周末没有和家人在一起。

图灵社区：这可能是你作为独立专家的福利之一吧。

JL：是的，我已经把很多人引诱到加入这个行列了（笑）！我跟他们说：如果你们周末工作的话，就要花上两倍的时间，如果你们星期天工作的话，就要用上三倍的时间。

图灵社区：想以数据库作为事业的人通常面临两个选择，一个是作为DBA，另一个是作为开发者。你对面对这两个选择犹豫不决的人有什么建议吗？

JL：对我来说最大的问题就是我所看到的Oracle应用，它们没有体现出大家所说的DBA和开发者之间足够的合作性。有些人接受具体任务，他们写的代码需要和Oracle数据库交流，还有人管理Oracle数据库，他们整天看数据库的SQL。有时候他们会说：这人会不会写SQL啊？这写的是什么呀？我认为不应该有这样的分界线。如果你的应用背后有Oracle数据库，你应该知道数据库是如何工作的，这样开发者和DBA之间的对话就会更有效。

很多DBA抱怨，现在的数据库很大程度上就是按按钮。如果你是一位DBA，你可能这辈子都在做支持，没有机会接触像我所做的这些有趣的东西。如果你想精通如今的Oracle，并且享受你在Oracle上的工作，我认为你应该把自己放在两种工作的中间。这样你就会了解数据如何工作，就会享受和数据库交互的过程，也会喜欢和业务应用交流的过程，你会知道如何构建自己的代码和数据库更好的交流。所以，"DBA开发者"也许才是最合适的位置，并不仅仅作为一个程序员，而是一个和数据库有亲密接触的程序员，享受数据库所能提供的帮助。当然，这可能需要找到一家能够提供这样位置的公司。

图灵社区：对于内核和功能，你认为关注哪个更重要？

JL：我认为每个人都应该熟悉undo和redo的运行方法，每个人也应该了解一些类似库缓存如何工作的只是，因为他们应该知道，在完成一个很简单的任务时，后台都发生了些什么。也许你不需要对所有事情都知道得一清二楚，但是你需要知道什么时候需要干什么，需要对整体有一个把握。一旦你对所有事都有了大概的了解，我认为你不需要再有更深的考虑了。大多数人需要知道的就是索引表怎么工作，群怎么工作，压缩索引有什么好处。当你改变数据的时候，当你需要优化的时候，你就知道如何避免信息阻塞。基于此，你就可以去研究一下物理设计，这就是你需要掌握知识的上线了。

我对OTN数据库论坛上的一件事感到很有趣，几乎每周，论坛上都会有一个问题"如果我把这行上移到这里，而不提交，在这之后我们运行了很久，但是突然间数据库崩溃了，Oracle会如何处理这件事？"我对这类问题出现的频率感到惊讶，因为从很多方面来说，需要了解这些事的人非常少，你不需要知道如何解决和为什么这么解决，只需要知道它就是这样就够了。多掌握一些知识当然好，但是如果这需要耗费你大量的时间和精力的话就不划算了。人们总是不厌其烦的问我这些问题，这其实也是我写这本书的一个原因，你们来看书吧，别问了。

图灵社区：如果您的子女对计算机科学感兴趣，你会让他们选什么具体的方向呢？

JL：我的孩子对计算机科学一点都不感兴趣，甚至对科学都没什么兴趣。他们主修的都是艺术。如果要我给其他的人建议的话，我其实没法给出具体的建议。我对自己从事的工作很喜欢，我也鼓励别人做自己真正感兴趣的工作。如果你能通过这件事赚到钱，那就去试试吧。我不会和任何人说，你去做Oracle。我知道有些人他们并不对Oracle感兴趣，只是因为他们做的不赖，做其他的事又做不来，所以才从事这份工作。刚才这个问题的实质其实是预测这个市场：5年之后的就业市场会是什么样呢？

如果有人要根据未来就业市场的走向来定夺自己的未来。那我就大胆猜测一下。我认为对于Oracle顶级专家来说，会有一个很小的市场。5年后，可能很大部分的普通Oracle工种都会被挪到云端，只会有不多的用可插拔数据库的支持，来维持很少数量的数据库。而大部分小型企业，只要租赁 Oracle的云端数据库就可以了。他们不需要自己买硬件和软件，也不需要有自己的DBA，只要为自己的应用租赁一块可运行的数据库就可以了。如果你想在 5年后成为Oracle DBA，你要么就是为很大的公司工作，他们自己为了保护数据的隐密性，而把数据留在自己这里。要么就是为很大的机器工作，500台机器上运行着上百个数据库。小公司里的多数DBA，就不会存在了。除了Oracle，也会有其他的数据库技术也向这个方向发展。

事实上，需要维持大数据库的大公司数量并不很大。无论你的技术是什么，DBA都不会很多。我将在5年内退休，对此我长出一口气。很高兴我不是个初出茅庐的专家，因为我很担心在5年后很多DBA的命运，他们找工作也许会很困难。除非他们真的出类拔萃，而且大家也认可他的能力。

图灵社区：你会考虑开发某种工具让代码可以跨越各种版本的限制吗？

JL：绝对不会。我从来没有想过要把我做的东西变成某种产品。因为如果要有产品的话，那个产品就一定要尽善尽美，而且要完美适配所有版本的Oracle。这就意味着我要花很多时间对已经存在的东西改来改去。这对任何人来说，都是得不偿失的。我甚至都不会公布我的SQL代码，在我的博客上只有很少几个，我会说：这是一个很小的例子，这是2003年在某个版本的Oracle上运行的代码，它的作用是告诉你这个东西大概是怎么完成的。我绝不会说：这是一个在所有Oracle上都能运行的程序。看着我现在用的某些代码，我认为我可以把它们改得效率更高，这个高效版本可以在10上运行，也可以在11上运行，我十年前写的代码，现在仍然可以在9，10，11上用，对于我的要求来说完全适用。但是如果要我做一个产品来解释，我就需要它在所有产品上适用，而且还要回过头修改以前的代码。人们不会为不产生新的结果的事情付钱。所以从经济学上来说也是不合算的。

市场上有些工具，我不会说具体名字，当你仔细观察它们运行的SQL，你就会发现他们的效率很低，这不是做事的正确方法。但你会认识到，在十年前，没有改变的需求的时候，它们仍然能够运行。在很多年以前，当Oracle 9刚问世的时候，有一个公司有个这样的标准工具，我在一个大会上看到了，是一个很小的展台。他们有一个产品在Oracle 8上小有名气，当时展台上挂着一个巨大的条幅，上面写："Oracle 9的保证"。我就去问他们一些细节："你们说Oracle 9的保证是什么意思?你们能做这些那些吗？"最终他们终于承认，这句话的意思其实是，代码在Oracle 9上仍然可以运行。但是这样的产品并不是为Oracle 9设计的，而是为Oracle 8设计的，只是可以在9上运行罢了。可以说如果我是这个产品的顾客的话，我听到这些话可不会高兴的。但是商业公司有自己的考虑，也就是这种考虑上的差别，使得我做梦也不想把我做的东西变成产品。

图灵社区：《Oracle核心技术》和《基于成本的Oracle优化法则》是两本很受欢迎的技术书。在《基于成本的Oracle优化法则》中你说过，会有一系列关于此主题的书，《Oracle核心技术》是这个系列的第二本，这个系列的其他书也在准备中吗？

JL：事实上，《Oracle核心技术》并不是这个系列的第二本书。当我写完《基于成本》，我决定不再继续写那些复杂、耗费时间，但又不是十分必要的主题，比如分布查询和平行查询。因为这些很让人费神的东西的需求并不很大。但我确实有计划继续写书，主题是我所掌握的其他信息。这个决定的根源是Oracle的变化和升级太快了，就算是有我这样背景的人，也无法跟上Oracle发布的步伐，无法预测在所有情况下 Oracle的反应。虽然我一直尝试紧跟发展，写一本关于优化，内容丰厚的书，但是却一直无法开始。

《Oracle核心技术》其实是倒退了一步，它跟随的是我在2000年写的一本书《Practical Oracle 8i》，介绍了Oracle工作的核心机制。《Oracle核心技术》扩展讲述的就是这本书一、二章的内容。我要小声透露一个消息，我可能会写一本关于物理结构、索引，以及表方面的书，但是这件事还没有确定。这本书是要把《Oracle核心技术》中尚未展开的部分写出来，教你在写代码之前，通过如何选择不同的物理结构，让数据库变得更有效率。如果可能的话，这将是一本很有意思的书，但是让我完成另一本关于Oracle的书希望渺渺。《Practical Oracle 8i》是一本好书，现在仍有人在买，如果我真的能完成下一本书，内容会和这本书一、二章之后的内容相关。

感谢杨志洪、熊军、耿永辉三位译者协助采访。

吕海波（Vage）- 突然35岁：捡点我的职业生涯

2013-07-31T04:50:45Z

本文引自Vage个人网站，原文链接：http://www.mythdata.com/post/15.html

十五年前，你或许还不懂爱情，看Jack和Rose执手相看泪眼，只是蒙胧的心痛。十五年后，你会和谁一起走进影院，更会和谁一起，走到生命终点。
十五年前，我还不太懂技术，凭兴趣玩着C语言。十五年后，当铁达尼的旋律再次响起，我会选择和哪门技术，一起走到我职业生涯的终点。

序言
---- 回望雨中的园区，更是回望来时的路。

此时天空飘着小雨，正如丝丝织雨细如愁。我刚刚离职，一路走出园区，回望了一眼雨中阿里巴巴的大楼，思绪随着微风，四处飘散。突然想起几年前我刚到杭州哪天，也是细雨微风。我走进城西的创业大厦，终于见识了大师Biti的风采，也从此开始我的阿里巴巴之旅。
杭州的特点，是隐匿在山青水秀之间，有很多雅至的主题饭店，团队第一次出外聚餐，就是在山间绕来绕去，最后到了一处青山环绕、绿水长流之处。Biti在会议上就"什么是架构"进行了精彩的评论，高度已经超越普通技术人员，至今我仍记忆犹新。但不久之后，Biti调至支付宝，真是遗憾。而这让我面临了空前巨大的压力，因为Biti一走，我变成了团队级别最高的DBA。初来乍到，入职刚满一月，忽然成为阿里系一个子公司的"首席DBA"，惊喜之余，感觉压力之大、常常令我透不过气来。不过还好，时间总一晃而过，此时此刻，刚刚走出阿里，掏出手机，拍了一张照片，算作我在阿里的留念，更是我人生一段最重要经历的留念。

回望雨中的园区，更是回望来时之路。............

]]> 来时之路：硅谷，IT传奇的开始。

---- 人可以依靠梦想活一段时间，但不会一直下去。
"坐落在纵横交错的高速公路之间的，是巨型的商业园区和简陋的三卧两浴的平房住宅，其间最高的建筑是变电站的铁塔和架着电话线的水泥杆子。真正的工作是员工们在简陋的、用屏风隔开的小办公室里，眼睛盯着电脑屏幕静静完成的。每个人都试图做一些前人没有做过的东西。"
这就是李彦宏在《硅谷商战》中谈到的硅谷的样子。
曾经有两个在一家公司供职的工程师，去找硅谷著名的投资家史蒂夫·朱维森，这位资深风险投资家对他们提出网上数据库系统并不感兴趣，他问："你们还有其他主意吗？"
其中一个叫比尔·巴迪亚的工程师就说，他还想通过因特网来提供免费的电子邮件账户，从网上广告为获取收入。10天之后，朱维森连商业计划都没要便掏出30万美元帮助他们成立了Hotmail公司。Hotmail后来以10亿美元的天价买给了微软公司。
这在当时看来有些离谱，但这样的故事到处流传，充斥着各类励志杂志，也充满着我的心。
世界上赚钱的公司多的是，但没有哪家公司的口号是改变世界。看看现在的IT、互联网公司，每个公司的口号中几乎都包含着改变世界的梦想。而且从微软、苹果这类老一代革命家，到Google、Facebook这类硅谷新星，也的确有很多家公司或多或少的改变了世界，或至少是深深影响了世界。
IT，互联网，这是一个传奇的行业。当我的手抚过键盘，当眼光划过满屏自己写的代码，澎湃的激情，从来都没有息灭过。但无论多大的激情最终都会有息灭的时候。人可以依靠梦想活一段时间，但不会一直下去。
1996年，我职专毕业。职专，是差等生的代名词。职专生的梦想，一般都是成为某武侠小说的男主角，有一个酷酷的名字，有一堆惊艳的红艳。我也不例外。但这一切，在96年的夏天到来时，突然中止了。原因我应聘到了一个很小规模的计算机培训中心---"辰星计算培训中心"。还有，我看了辰星书柜中的电脑报合订本。
有一篇故事我仍然记得，《软件辉煌》，其中详细讲述了盖茨创办微软的经历，还有Word的开发历程，......。一群大男孩，用电脑改变世界。美国，硅谷，IT界，从来都不缺这样的故事。虽然这样的故事从来没有在东方某个伟大的国家发生过。
合上电脑报，一个想法出现在我的脑海中，哪就是我要做中国的比尔。盖茨。年轻人总有梦想，不是吗？
一年后，1997年的夏天，四个辰星公司的"核心"员工，告别辰星，踏上创业之路。四人熟读微软、乃至硅谷的历史，这些历史让他们热心沸腾。
40年前，晶体管之父肖克利博士的故乡，美国西海岸的圣克拉拉，八名怀着梦想的年轻人离开肖克利半导体实验室，创办了可谓硅谷摇篮的仙童半导体公司。这就是著名的八叛逆。而我们，则自许"四叛逆"。我们在和辰星仅一墙之隔的地方，买了二十台电脑，投资达十万，创办了红星计算培训中心。那一年，我们十八岁。

光辉岁月

---- 青春总是这样苦涩，但在长长生命之中，装在记忆这个坛子里，慢慢的发醇，最后却能化为无比的感纯。这或许就是生命的魔力。

..................
梦想总是遥不可及
是不是应该放弃
花开花落又是一季
春天啊你在哪里
青春如同奔流的江河
一去不回来不及道别
只剩下（平凡）的我没有了当年的热血
看那漫天飘零的花朵
在最美丽的时刻凋谢
..................

红星的创办，让我们的年青岁月，都达到了顶峰，此后再无超越。我们在同学中间成为传奇，成为创业的典泛。甚至有同学的同学，还幕名前来，向我们请教人生。
在红星除了讲课，我们还为一些传销公司开发核算、财务软件。我还用C和汇编，写各种有趣的程序。我用汇编写过一个DOS下内存驻留的程序，写完很有成就感，自信潢潢。但转念一想，要学的东西如此之多，不知何年何月才能学完，霎那间又充满急燥。
那段青春岁月真是难又形容。快乐与泪水，自信与自悲，坚持与旁徨，......，各种各样的感情交织着，匆匆的，过去了，不再来。
寒来暑去，花儿谢了又开、开了又谢，时间就如同夏日傍晚的凉风，轻轻的带走了岁月，只给人留下，多样的回忆，哪怕这回忆是如此的沈重。

小学三年级时，还是1987年，我在书店看到一本书，作者是诺查丹马斯。书中详细介绍了他的一系列预言，从狮心王理查的死期，到西特勒的出现。当然，最后是1999年人类大灾难，恐怖大王从天而降。很不巧，当时哥哥刚刚带我看完电影《超人》。超人故乡星球毁灭的特效，虽然在现在看来虽然拙劣不堪，但当时强烈震憾了我幼小的心灵。如今再看诺查丹马斯的预言，我几乎已经看到了地球在强烈的地震、大火中，变为一片废墟。出了书店，我万念俱灰。我马上找到我的一众好朋友，将这个恶耗讲给他们："我们只剩12年好活。"，未了，看着他们一个个脸如死灰，我却突然心情大好起来，悠载悠载的回家写作业去也。有了这种经历，使我完全相信微博上的一句话：不要向任何人诉苦，因为20%的人不关心，剩下的80%听到后很高兴。这是题外话，我们继续。
12年后，1999年到了，我却再无所谓。或许大家一起死了，比我迷茫的活着更好。曾经辉煌的红星，只不过几年，便已面目全非，曾经的朋友，分道扬镖。在千禧年来临的前夜，我和几个同样迷茫的年青人，喝着劣质的白酒，挥洒着青春，也挥洒着生命。
青春总是这样苦涩，但在长长生命之中，装在记忆这个坛子里，慢慢的发醇，最后却能化为无比的感纯。这或许就是生命的魔力。
我相信人生是一段段例行公事，一段忙完又一段，直到尽头。在红星的大门关上哪一刻，我告诉自已，一段生命结束了，要开始新的一段了。
2000年春暖花开之际，我踏上新的征程。通过以往学员的关系，到了我市一家百年老字号---五福糕点，做学徒。强烈的急燥心理，令我急切的寻找一条可以快速发家致富之路，我当时的选择是：糕点师。但我并没有忘记我的梦，我的盖茨之梦，我的程序员之梦。2000年周星驰贺岁片《喜剧之王》上映，其中一句"我是一个演员"，深深打动了我。我想，或许有一天，别人吃着我做的极品慕丝，我却告诉别人："其实，我是一个程序员"。
罗红可又先做糕点，开好利来，赚了钱再当摄影师，我也可以。成长就是这样，我的目标，已经从创办Intel的肖克利八叛逆，或盖茨等世界级大腕，变成了中国人罗红。其实，即便是罗红这样的成就，也是高高在上的。所又，我成熟了，但还不够成熟。我想成为一个不普通的人，原因就是我是一个太普通的人。
几个月后，我放弃糕点，拎起菜刀，成了一个饭店的帮厨学徒。
几个月后，我放下菜刀，在路边摆摊卖精品。
几个月后，我开了一家精品店。
几个月后，精品店倒闭，我赔光了所有钱。
这就是成长的代价。路不去走，就不知道原来走不通，更不知道哪条路可以走通。
其实，在这一年左右的时间中，也不是没有收获。在饭店做帮厨学徒时，我认识一个厨师。当其他厨师都是打台球、或站在街边对着过往的美女吹口哨时，他在练习刻花，或者学习。他说，
他的目标是要上天津一所厨师大学。我们一直保持着若有若无的联系，我要看看他的坚持是否会有结果。我想，他也这么想的，他也想看看，我的坚持，会不会有结果。因为，无论在干什么，我也从没有中断学习。我不会吹口哨，台球打的也不好，他在苦练刻花时，我通常会拿起严蔚敏《数据结构》、同济大学版的《离散数学》等等。从96年到现在，从我看完比尔。盖茨故事哪一刻起，无论的目标如何变化，我可以自豪的说，我的IT梦，从没有一天停止过。也从没有在哪个阶段，停止过学习。
还在五福糕点时，虽然这个决定有点晚了，但我还是决定放下DOS。开始看《Windows程序设计》这本号称Windows下的圣经。当我拿起菜刀时，同时，严蔚敏的数据结构，已经开始看第二遍了，这本书后来成为我走北上、南下必带的书。而在精品店时，对于始终不明所又的编译原理，我也没有放弃，买了本号称龙书的，但我最终对编译原理还是不明所以......
4年后，那名厨师告诉我，他并没有去上厨师大学，他在北京的一家饭店，一个月已经拿到八、九千块。6年后，他仍在北京，但薪水已经到达一万五了。到我入职阿里巴巴高级数据库专家时，他已经到了广州，薪水和我在阿里不相上下。之后，我们失去联系，不再有彼此的消息。因为我们在各自的身上，都已经找到结果。

残酷的青春
---- 在某一阶段，或许我们在寻找的和拒绝的都是自己。

中国最神密的部门是有关部门，最危险的工种是临时工。2001年的夏天，我来到郑州，到了我向往以久的事业单位，省计算中心，可惜从事最危险的职业：临时工。
从小，妈妈就教导我："要好好学习，长大了进事业单位，有个铁饭碗。"
我问妈妈："为什么只有事业单位才有铁饭碗，其他的就没有吗？"
"其他单位会破产啊，效益不好会倒闭，发不下工资。"妈妈没加思索的回答我。
我又不理解了，"哪会为什么事业单位就不会效益不好呢？"
"事业单位是国家吗，国家可以印钱啊。钱不够了就印。所以事业单位永远都不会缺钱。"妈妈回答我。
我想起阿甘正传中的一句话，Momma always had a way of explaining things so I could understand them. 妈妈总是有办法让我明白道理。
妈妈的目标，就是让我能进事业单位。现在，我终于进了，这多亏了一个亲戚。但我只是个临时工。我的工作是讲课，还有为其他各个大小企、事业单位开发各种程序。我在计算中心一共待
了7年，前2年，都是作为程序员，后来才转DBA。哪两年，我也为河南的不少企、事业单位开发了大大小小不少程序。现在想想，还有些后怕。常常午夜梦回，惊出一身冷汗。万一哪天我当年写的程序有问题，会不会被跨省追捕回去。或许我下半辈子最好待在，和中国没有引渡协议的国家，才能真正安全。
事业单位大家都互喊老师，在阿里的时候，大家都互喊同学。所以后来到阿里后，感觉年青了几岁，哈哈。在事业单位，正式的愁每天无事可做，临时的愁每天有太多事要做。常常一个上午
跑两个单位解决问题，下午又要回去参加会议、讨论新软件的架构。

在马不停蹄的忙碌中，我一直在考虑我将来的发展。谁都明白一个道理，如果想从一个行业中脱颖而出，只有两种常见的可能：要么技术牛逼，要么占得先手。技术牛逼这个，不容易做到，所以，对我来说，取得成功的最简单方法只有一个，"取得先机"。
我们都明白一个很简单的道理，当火焰烧起来的时候，你才想到去加柴火，只能收获一堆灰烬。于是，我开始以我自己的判断，从众多的技术种类中，找到一个还在发展中的技术。
经过苦苦的寻觅，了解了众多专家学者的一直看法，我选定了承载我希望的东西----VRML。VRML是HTML的3D版，当时一些专家预测，未来的网页，都将是这个样子的。
想想看，3D的网页，酷吧。打开网页，首先看到一扇门，用鼠标点一下，门打开了，随着鼠标的移动，你的虚拟形象走进房间，这是一个客厅，有三三两两的网友进进出出，大家互相在聊着天，还有几个网友在角落中私聊，............，怎么样，这样的网页够酷吧。
那是01年的仲夏，傍晚的凉风，让经历了一天酷暑的人，感到格外轻松。夕阳西下的天边，还飘着几朵云彩，恰到好处的点缀着色彩绚丽的天空。我骑着自行车，轻松的穿行在大街小巷。我的心情格外的好，因为我刚买了一本书，是专门讲VRML的。而且，我找遍了整个书店，只找到一本关于VRML的书。这更加证实了我的猜想，VRML目前还比较小众，是一门方兴末艾的技术。只要抓住时机，在VRML全面代替HTML前，将VRML学的比较精通。等到VRML大行其道时，我的名字将随着VRML一起，响彻全国。哈哈哈哈，......，想到末来的美好前景，我几乎忍不住要逛笑起来。但命运如同横穿马路的汽车，在你得意忘形时，将你的梦想击的粉碎。
2004年，一晃三年过去了。HTML势头不减，Flash红遍国内，之于我的未来希望：VRML，不提也罢。这从一个侧面证明，不要相信所谓专家、学者的预测。绝大多数的预测，都是错误的。就像IBM创史人托马斯·沃森曾经作出了："全球只需5台计算机"的预言一样。专家对未来的预测，往往是不靠谱的。企业家公开发表的预测，往往更不靠谱，他们的预测是为了对他们的产品和市场策略作宣传。就如同早些年Larry Ellison（拉里。埃里森）将预言未来PC将不再是主角，NC（网络计算机）都是主流。可惜早些年我不明白这些道理，浪费了几年时间。
如果能成功的抢占"先手"，无疑会以最小的代价、获得最大的成功。但是，如果你自以为是"先机"的东西没有发展起来，一切都将是竹蓝打水，一场空。
抢得"先手"固然可以使用自己更快的功成名就，但刻意的去抢，往往适得其反。成功抢得"先手"，这是上帝赐给你的礼物，可遇而不可求。这段经历让我明白，不要刻意追求快，欲速则
不达，还是一步一个脚印来得稳托。
其实仔细想一想，历史上固然有比尔。盖茨、乔布斯，有Google、FaceBook，等等人或者公司，以创新、抢先赢的市场和尊敬。但是，成功的人一定都是少数，还有更多的人，同样的才华横溢、同样的聪明无比，但是，他们的创新、他的"先机"，都失败了。历史不会记得他们，因为，历史，是胜利者的丰碑。
硅谷的风险投资商厉害吧，他们肯定不会将钱随便投给不靠谱的人、不靠谱的项目。但是，即使经过硅谷风投认定靠谱的事，成功率仍只能达到20%左右，80%的失败者没有人会记得。
几年的坚持，几年的努力，只不过去学了一个毫无用处的东西。其实从03年开始，我就想过要放弃，我可能压错了宝、选错了方向。无数个夜晚在孤灯前学习，换来的只是毫无价值的技术！
我的内心，很不愿意承认这个实事。人有时候最难否定的，就是自己。一直坚持到04年，还是一个仲夏的傍晚。依然是凉风习习，天空依然是绚丽多姿。我沿着金水河随意的漫步，我想，是不是要放弃了。一根接一根的抽着烟，买了几罐啤酒，一罐接一罐的喝着，夕阳将我的影子拖的老长老长。在某一阶段，或许我们在寻找的和拒绝的都是自己。你认为它错了，后来发现又对了，释然之后你担然承认，自己执着了。错和对重要吗，关键是它过去了。
是的，过去了。
这之后不久，因为工作需要，我开始接触一个新的东西，Form和Report，是一种很少人听说的，一种叫Oracle数据库的开发语言。各种语言对我来说是驾轻就熟，除了安装配置，这两种语言的开发，我很快就撑握了。我的历史，也因为这两个东西而转折。

灯塔：ITPUB

04、05年，我一直在做Oracle开发，主要使用的就是Form、Report，当然，还有OCI。在一些项目中使用OCI，纯粹是出于对C语言的偏爱。其实大多数我们的软件，可以全部使用Form和Report。
我从开发转型为DBA，是一个很偶然的事件。04年底，在给海关做一个项目时，认识了一名搞网络的技术人员，他刚刚考过CCNP，正在向CCIE努力。当时，我从没想过要考什么认证，因此，也不了解这些认证。听了CCIE，也没什么概念。他跟我讲，Oracle有一个很牛的认证，OCM。考过了后可以身价倍增。我回去在网上查了一下，说是当年亚州只有4名OCM等等，总之就是很牛逼。这个结果令我大吃一惊，我没想到一个认证，能有如此难度与作用。从此，我开始了我的转型之路。
其实我们单位从02年就开始使用Oracle，几年下来，也基于Oracle开发了不少项目。很多地方有时也要求我们在项目交付的同时，提供容灾、高可用方案。但这些是我不肖做的。曾经的我对
SA和DBA是如此的不肖一顾，"只是搬搬机器、装装系统的民工"。我的梦想是创造，创造独一无二的程序，获得巨额风投，凭一已之力改变世界，我能，我可以。当梦想的浮华散去，我发现，8年过去，我仍站在原地。
我是从备份、恢复切入到DBA这个行业的。04年底，我们为海关做了一个项目。项目完成后，我为他们搭建了DataGuard，同时，写了个脚本每周末备份DataGuard。当然，在项目软件中我也做了个按钮，如果需要，他们可以随时点这个按钮触发对备库的备份操作。软件中还有个按钮是将备库直接激活的，激活之后，备库要重搭，并且，如果Redo文件有问题的话，激活会丢失些数据，不过，这个项目的数据丢掉些他们可以接受。整个这些东西，我做为了高可用、容灾的方案，浓重的写进项目文档。当然，免不了介绍的天花乱缀。那个时代，大家对Oracle都没有什么概念，你只要能把库装上，都会有人说你牛。客户测试了备份、切换这些功能，再加上看了我天花乱缀的文档，对于灾备方案、高可用方案非常满意。我们领导后来得知这一情况后，专门问我是否有意转型做DBA，我自然没有问题。我已经厌倦了开发，或者说，厌倦了老是为了别人的需求，开发程序。听说DBA还算轻闲，我计划转做DBA，再利用剩余时间开发自己的程序。但不可否认的是，Oracle是有它独特的魅力的。随着对Oracle学习的越来越深，我慢慢的发弃了我的开发梦。
这一切的转变，都是很自然的，自然到我每每想起，总觉得那是命中注定。
数万年间我和Oracle相遇了，没有早一秒，也没有晚一秒，哪也没有别的话说，唯有说一句，原来你也在这里。

海关的项目之后，我开始考虑，如何让用户的数据在切换时也可以保持不丢。最后考虑的结果很简单，就是将Redo每组中设两个成员，每个成员都在不同的存储上。但当时有记得有人说这样做会对性能有影响，即使存放日志的两台存储一模一样。但也有人说没有影响。我在网上查了很多资料，大家的说法，莫衷一是。最后经过测试，结论很简单，有影响，但影响不大。对于这个结论，我想大部分读者也不会满意。到底影响在什么地方呢？每组中两个成员，每个成员在不同的存储中，存储性能是一致的。说这种情况下写Redo性能不会有影响的人，主要是认为LGWR会同时写两台存储中的两个Redo文件。如下图所示：

但是，我们考虑一点，LGWR进程只有一个，存储有两台，向A存储写和向B存储写，必然是两条语句，一个进程怎么可能同时执行两条语句呢。所以，上图不对，应该如下图所示才是：

LGWR发送命令写A存储中的RedoFile，不必等待写完成（因为是异步IO），LGWR再发送命令写B存储中的RedoFile。LGWR只有一个进程，不可能同时发命令写A存储和B存储中的两个Member，只能逐个来。但因为I/O是异步的，向B存储中写Redo Member，不必等向A存储中的写操作结束，而是如图中所示，有部分操作是平行的。
从总的时间消耗上看，图1中错误的理论，共耗时1.002 ms，图2中正确的理论，共耗时1.003 ms。当然，时间是我随意加上去的，但对于现代的计算机系统，"发出一条命令"，"接收一个通知"，消耗 0.001 ms 应该是过高的估计了。写磁盘的1 ms，应该是差不多了，大部分数据库写日志的响应时间，应该都是几ms左右的。
通过上面两个图的分析，可以得出结论，让LGWR写两个存储，对性能有影响，但影响不会太大。多了图2中最后一阶段的操作："B存储向LGWR发出写完成通知"。
有了这个结果，再后面的容灾架构，如果客户要求不丢数据，我都要求客户准备两套一模一样的存储，每个日志组的两个Member，分别放在不同的存储中。后来DBA逐渐增多，客户哪里，会有自己的甲方DBA，对于灾备系统，当我提出要两台一模一样的存储时，一些客户会有疑问。我会详细解释LGWR的原理，其实，向客户解释的过程，也是传播自己思想的过程。向客户解释的原理越多，客户对我的信任感也越强，后面的事情也越好办。
这些经历，也直接促成了我后面的学习习惯----重视原理。虽然原理这东西很虚无，但为了更好的说服客户、取得客户的信任，有时我不得不向客户解释这些东西。
说点题外话，总有人问研究内部有什么用，我觉得最重要的作用就是，可以更好的忽悠客户。
哈哈，这是玩笑话，有用没用看自己爱好。有兴趣就去研究，没兴趣就去做别的。这个问题不必纠结。
如果真有兴趣去研究了，也一定会有回报。如果没去研究，也可以当好一名普通的DBA。
言归正传，能为客户解释这么多东西，有一个网站功不可未，就是ITPUB。我05年注册了帐号，此后，只要有疑难问题，第一时间先上PUB上搜索。PUB成为了工作、学习必不可少的网站。但是，我很少在PUB上发表什么，因为我自己的功力尚不足，怕写出错误的东西，耽心影响大家。但看了哪么多好帖，从来没有回过帖，现在想来，也让我心中不安。于是从去年开始，我开始将这些年的积累逐步总结出来。我相信一个道理，有一个农场主，得到了一种优良小麦种子，但他不懂得分享，只在自家的地里种这上了这种优质小麦。收获季节到来时，结果他的优质小麦表现并不如何的好。他很不理解，就去请教一位专家。专家了解了情况好告诉他，只他自己种优质小麦，面积太小，旁边别人普通小麦的花粉，会被传播到他的优质小麦中，结果，影响了他的优质小麦的质量。第二年，这位农场主将自己的优质小麦种子分享给旁边其他的农场主。由于有了足够大面积优质小麦的花粉，到了收获季节，大家都获得了大丰收。现在时间已经成熟，我会慢慢将一些心得分享出来，希望和大家一起研究、一起进步、一起丰收。
在乙方工作哪段时间，对于工作，我只有一点感触。每天，我并不是为了单位而工作，我是为了自己而工作。只有自己的技能获得提升，才是关键。我会选择个别库做为观察对象，进行深入
、细致的分析，以此来煅炼技能。但人的精力是有限的，再加上单位给的福利待遇也不高，所以大部分库，只要客户不找我，我也不去找他们。
从07年开始，单位成立专门的数据库运维团队，决定让我作为团队的Leader。我的工作重点，从单纯的技术，慢慢变成了开会，参加各种会议。有些人对此乐此不疲，但我很不习惯。大家把活推来推去，把功劳争来争去。不单要开会，还要培养新人。慢慢的，一些库分给其他人管理，使我可以专心去"开会"。很长时间里，我无心从事技术，脑子中之想着明天要参加已经开了好多天的某项目架构大会、要最终确定下来的某事故改进会议、......。我心目中的管理会议是这样：

（图4）
实际上的会议是这样：

（图5）
哈哈，我承认图有点夸张。我实在不适合做扯皮这样的事。或许随着我年龄的进一步增长、技术实力的进一步加强。技术上已经没什么可学的了，活也干不动了。每天开开会，扯扯皮，还有
点意义。现在，这绝不是我想要的生活。古人都说，"学而优则仕"，我学还没有优呢，如何去入"仕"呢。
07年我技术进步缓慢，如果一直这样下去，我不知道，如果有一天单位辞掉我了，我该何去何从。没有了技术优势，一个单位的中下层管理人员，你到51JOB上搜索一下，有招聘"技术团队管理者"这样岗位的吗。而且，计算中心是事业单位，从05年开始，我就一直谋求可以转成正式的"在编制"人员。为此，我、包括我们全家人，使用了很多方法。但是，我们的希望最后都落空了。
其实，我本来也没抱太大希望。
08年初，为了将来的发展，我决定辞职。这个决定或许已经有点晚了，但是，如果不马上行动，将来只会更晚。

在阿里巴巴遇见最好的DBA团队

我不喜欢飘泊的生活，也不喜欢新鲜的城市。只想在我家乡哪座著名古都中，像被固化在虎珀中一样去生活。但我的人生却注定要去飘泊，而且，是在三十而立之年，才刚刚开始。千万不要
刻意去选择自己的生活，因为你只能猜到开头，却猜不到结果。
我的第一站是北京，因为有朋友说可以为我介绍工作，但这份工作是Oracle讲师。我的技术还没有达到一定水平，还需要提高。这时候去做讲师，实在非我所愿。我的内心的理想目标，是去
阿里系的公司：阿里巴巴、淘宝、支付宝。这些公司"大师"级的人物层出不穷，我想也应该是很多DBA的目标。但自己投简历过去，成功可能很小，我一向不喜欢自已投简历过去。所以，在09年初，考完OCM之后，我就一直想做点东西出来。正好一个朋友找过来，于是我们合作，很快就有了"Oracle日志挖掘研究版"这个程序。也很快的，阿里巴巴就给我打了电话。
到阿里面试是很爽的，来回的机票、酒店全部都已经订好，就好像到杭州来了个一日游。我是中午到的创业大厦，先被HR领到一个大厅里，做了一份笔试卷子，说是60分钟，但其实没有人在旁边计时，晚一会儿也无所谓。笔试题难度不高，和网上流传的阿里巴巴笔试题差不多。做完笔试题，就是著名大师Biti的面试了。这是第一次见到Biti，个子不高，但人很精神，说话极有条理。
Biti面试时的难度也不高，大家聊的很好，就像朋友闲聊一样。所以，这趟杭州之行，让我觉得很完美，即来杭州旅了一次游，又和一些朋友聊了聊技术。
本来我计划当天晚上就回去，Biti面试完，被告知阿里巴巴B2B的技术部老大Andy想见见我，如果我时间上没有问题，HR会退掉当天的订好的机票再重新订，当晚住宿的酒店也已经安排好了。
当时很是受宠若惊，马上告诉HR没有问题。
第二天其实还是有点紧张的，不知道Andy会问我什么问题。见到Andy后才感觉，Andy人也很随合。Andy问了两个问题给我留下很深的印象，一是建立一个数据库层和应用层之间的统一中间层，对下可以支持各种数据库是否有必要。还有一个，是如何拆分一个大数据库为多个数据库。
第一个问题，我的回答的很中庸，一个可以忽略下层数据库是什么的中间层，对性能会有影响，对开发效率、代码重用率会有提升，搞一个是有必要的，对于特别要求效率地方，仍可以使用
老的方式，一般情况下，使用中间层就可以了。我估计这是Andy当时正在考虑的问题，但后来阿里巴巴并没有大张旗鼓的搞这么个东西，我想Andy最终还是认为搞这个东西意义不大。
第二个问题，拆分数据库的方法，我曾经主导过一个大库的拆分，要求应用的每张表，都有主键。然后就像HASH分区一样，以每个表的主键为准，将数据做个HASH运算，分布到多个库中，我直接把我做过这个项目详细说了一下。也是后来我才知道，原来阿里巴巴这边刚刚做过一个大表的拆分，拆分方法和我说的类似。
上午的面试很快就过去了，我专门让HR帮我订晚点的机票，这样，下午有时间去西湖游览一下。
这次杭州之行，给我的感觉是，杭州不错，面试很愉快，但打车很难。下午在西湖边打车，用了好久。后来才知道，在哪个时间点打车，能打到已经是运气了。
两个月后，我告别待了10个月的北京，来到杭州，入职阿里巴巴。

中国的大型互联网企业，有很多相似之处。比如说一样有入职培训，一样每年有年会，一样的有Outting，一样的嘴上说一套、底下做一套。比如公司一直在讲诚信，但在出了一些事情之后，从公司发给我们员工的邮件来看，没有看到诚信二字。但这很正常，在我们国家，到我这个年龄，如果还相信公司说的什么或老板说的什么，哪脑袋就真有点问题了。
阿里的入职培训和其他公司一样，讲一讲企业文化，再把人拉到户外做做拓展运动，结束，没有持续性。和我一起参加入职培训的有几十人，半年内有差不多三分一离开公司，一年内大概只
剩三分之一留在公司。我和另外两个入职培训时认识的朋友合租一套三室两厅，一年后，他们都走了，只剩我自己独住一大套房子。大家来阿里的目的很简单，渡金。我的室友之一，半年后顺利跳到了teradata。另一个是做客服的，一年后跳到另一个规模略小的互联网公司，做了客服经理。当然，我到阿里，最大的目的并不是渡金，而是学习。我的目标是成为Oracle大师，阿里孕育了哪么多Oracle大师，到了阿里，我就和目标接近了。
但可能是我在面试时忽悠的有点过了头，阿里给了我一个很高的级别：高级数据库专家。这既让我兴奋，又让我感到无比大的压力。在我入职时的09年，整个集团的技术人员，达到这个级别、和这个级别之上的，不过几十人而已。在B2B，高级专家之上的，只有十几个人。我们DBA团队中，只有一个人比我级别高，就是Biti。这让我的压力，稍微小了点，有什么大事，我前面至少还有Biti在扛着。但是，一个月后，Biti就调到支付宝。我成了阿里巴巴B2B级别最高的DBA。一下子变成了"首席DBA"，我内心深入无比激动，但是，这也让我无比害怕。
来到阿里，我对自己的定位是学习、经历，我的目标，是成为技术大师，我从不会改变这个目标。但公司对我的期望，显然不是这样的。但这没有关系，这并不会防碍我学习。
在阿里的日子过的很快，好像回到了上学时代。每天三点一线，上班、到食堂、下班。DBA团队是我见过的最好的团队，几位领导对每个人都很负责，诚心实意的为每个人着想，努力为每个人提供发展机会。大家之间没有争抢，没有钩心斗角，只有努力的做好事情。很高兴在这里渡过了快乐的近三年时光。在此，对领导、对团队中每个兄弟表示感谢。阿里的数据库维护水平，自然是没得说的，用一句通俗的话来形容，我就像掉到了水中的海绵，如痴似渴的吸收着养份。
我到公司时，MySQL刚刚在公司有第一例非常成功的案例。之后的几年间，公司的MySQL团队从无到有，迅速壮大，MySQL的应用也是遍地开花。再之后NoSQL如同凄美的昙花，匆匆一现，却也给公司内Oracle的应用带来不小的震动。对于开发，Oracle有如过街之鼠，几乎人人喊打。之后，一切又都归于平静和理性。NoSQL出局，MySQL重点发展，去Oracle已成必然。从11年开始，我也面临艰难转型，根据公司情况，我决定转型到GreePlum数据仓库。但转型是困难的，几本大部头的书，一看就困。Oracle是越学越精神，一看GreePlum就瞌睡。数次不眠之夜的深思，我决定放弃转型。我知道这对我来说意味着什么，放弃转型，也意味着要放弃这份工作。虽然我很喜欢团队的氛围，我对团队恋恋不舍，但我仍将坚持我的方向。11年夏天，我开始筹备我的下一份工作，并计划在12年春节的时候离开。

阿里巴巴二三事

在阿里，我见识到了Biti留下来的管理制度与管理水平。我们的数据库，很少出莫名其妙的问题。按照托尔斯泰的说法，好的数据库个个相似，差的数据库各有各的不同。好的数据库，无外
乎性能尚可，有完善的备份恢复和高可用机制、并定期测试，很少奇奇怪怪的问题，绝大多数报错、性能曲线的波动都可以找到原因，等等。差的数据库总有千奇百怪的问题、林林总总的报错、莫明其妙的当机。
其实，达到阿里数据库的管理水平，DBA只做了一间事，就是更加关心自己负责的库。
每次性能曲线的波动，都要找到原因，甚至定位到SQL。对于新上线的SQL语句，进行严格的审查。对于大操作，格外小心。Statspack、AWR报告，要观注、观注、再观注。基本上也就这些了吧。我把这种管理模式，叫做精细化管理。
说到这里，我想起了一件事，姥姥家住在一条古老的小巷里，在小巷南口，相隔不远有两家买锅葵（一种面饼）的，但一家门庭冷落，另一家则客流不断。很多人宁愿多花点时间排队，也要
买另外一家店的锅葵。有一次，我跟一位住在这块的老表谈起这事，为啥一家店生意清冷，另一家店生意兴隆。我老表很郑重的告诉我，"这就是用的功夫不一样。"我霎时间明白了。
当然，我见到过很多乙方公司的DBA，每个人要管几十个库，在这种情况下，根本无暇顾及什么性能指标、AWR报告，只要数据库不当、只要客户不主动来找就行了。不出事情，哪有什么功夫去看AWR报告什么的。至于乙方的这种管理方式，我先称之为粗犷化管理。
这种粗犷化管理试，也是国情所定，我们无法改变环境，但我们可以改变的，是我们自己。我有一个朋友，初中同学。初中时学习不好，技校毕业。毕业后在工程公司做技工，其实干的活和
民工没有差别。在体验到现实的残酷后，他没有被生活磨平楞角，反而越战越勇，真正的奋斗起来。他的目标是考取注册监理师认证，很自然的，这个目标成了很多人茶余饭后的笑料。不是说这个目标多不现实，而是，就算你考上了注册监理师，又能怎样呢？你怎么才能找到第一份监理师的工作呢？就算有证书，谁肯要一个民工做监理师呢？
面对嘲笑，我们唯一能做的事，就是努力坚持自己的方向，不要去做无谓的争辨。在干完一天烦重的工作后，他回去还要挑灯夜读。几年的坚持，他终于考上了注册监理师。就在为第一份监
理师工作发愁时，机会不期然而至，工程公司的一个朋友将他推荐到另一个公司。虽然干的活和民工没区别，但他是技校毕业，算是技工，底层实践经验丰富，又有了注册监理师证书，他成功的跳到另一个工程公司，成为监理师。轻松完成了从民工到工程师这个华丽的脱变。而且，一切又都是如此的自然而然。两年后，他又跳到北京一家更大规模的公司。公司将他派到新Jiang，在工地上，他巧遇以前的同事，他们还在顶着风沙，在工地上辛苦的工作。目前，他正在自学英语，他的计划是希望跳到外企。我相信他一定可以成功。
自助者天必助之，古人的经验之谈，难道都是骗人的吗。
相信有些乙方的DBA也在痛苦中迷茫，如何在粗犷化管理中，实现自己职业生涯的突围。我建议呢，可以选一两个库，以提升自己水平为目标，进行精细化管理。关注这一两个库的细节，你会发现，水平可以更快的增加。
在阿里，我的第一次事故，让我记忆深刻。那是一次加节点操作，前期操作已经成功，最后一步在执行rootaddnode.sh脚本时，中途出错，导致OCR信息被损坏，所有节点全HANG。进行OCR恢复后，才恢复正常。原因非常奇怪，rootaddnode.sh要调用srvctl向OCR中写入新节点信息，而srvctl因为缺少个包，执行失败异常退出了，OCR信息也被写坏了。
在进行这次加节点操作前，我在虚拟机中反反复复测试，做了大量的准备工作，但没想到，最终还是出了大事故。
从这件事后，我再做其他操作都更加仔细，特别是RAC。RAC下操作总会调用这个哪个一堆的脚本，我会先把脚本看一下，大概了解这些脚本都干点啥。就像加节点，我会先调用Srvctl config命令，显示一下配置信息。如果可以显示成功，再进行加节点操作。
"不要在周五做重要的事情，这会让你整个周未都没有好心情"，这是这次加节点操作给我留下的另一个忠告。
在阿里最深刻的，还是职场之道给我的震撼。在此，引用一位PUBER的发帖：
A同学，遇到问题，召集会议写报告搞风险评估，凤凤火火，完事后到处汇报心得，各部门都知道了数据部的功劳。
B同学，遇到问题，默默一个人搞定。

这B同学确实厉害，很多问题都独立搞定，A同学连Oracle的PGA是啥都不知道，但他就是跟公司的高手们关系好，会求助，会推动。
当你有一天听到领导们背后议论A和B的时候，你会发现，他们一致都比较欣赏A。为什么他们会欣赏A呢？不是B是高手么？因为领导们已经长期不做技术了，观察人更喜欢观察人的沟通协调能力，像B默默搞定问题，谁也不知道是咋回事，还以为这问题很简单呢。结果呢？B郁闷离职。。。职场故事无新鲜事，类似故事每天都在发生。
以前一直以为是故事，直到见到一个活生生的、传奇般的"A同学"。除了这位Puber提到的，我觉得"A同学"一般还要有一个特长，就是会起名字。一个普普通通的架构，起个好名字，简值
是有化腐朽为神奇的作用啊。
看一些中央领导的简历，升迁之迅速，往往让我惊叹。很多人不惑之年，都做到了高级领导，拥有数套房子和无数个情人，成功进级高帅富他爹。我一直很奇怪，人家都是怎么玩的。自从见
过"A同学"后，我了然了。"A同学们"的成功是很迅速的，他们身轻如燕，稍有青风拂过，便能乘风而起，一飞冲天。
"A同学们"也要有一定的能力，这是基础。但是，和他们的综合实力相比，他们的能力可以忽略不记。
他们可以把GDP搞的很高，但不会把国家搞的很强。
如果一个集体、一个部门甚至一个国家，越来越弱，那一定是"A同学们"太多了。
"A同学"后来跳到另一巨头民企担任很高的职位，依旧是风声水起、威风八面，于是我就知道，哪家民企的发展是到头了。如果以释伽"成、住、坏"三阶段发展论来讲，个人认为哪家民企
的"成"阶段已经过去，进入"住"阶段，如果没有"B同学"大量加入，数年之后，或许就是"坏"阶段了。
个人认为，单以职场发展来论，"A同学"值的效仿。现在的职场，好像春秋战国，即使你所待的"国家"，已经进入"坏"的阶段了，没关系，换一个国家就是。就像春秋战国时一位"士"
人的言论，是当大王、诸候好呢，还是做大臣好呢。当然还是大臣好。一个国亡了，王的结局只有死，但大臣呢，换个地方再做大臣就行了。"A同学们"，永远会受到市场追捧的。他们就像漆黑中的萤火虫，那样的鲜明，那样的出众，那样的拉轰。
但我向来没有"A同学"的能耐，只能向"B同学"学习了。
将来做企么无所谓，有一点很关键，就是要认清自己的方向，这很重要。做管理？做技术？都行，这世界上有靠管理成功的，也有靠技术发家致富的。
你的目标可以是成为管理者、领导，但不能是"成为好逸无劳又挣钱"的人。不要幻想着每天什么活都不干，上班喝喝茶、扯扯蛋，每月工资高的让我们这些矮穷丑听到都吓的尿裤子。这样
的境界，是要有上一代打下基础才行。如果你进了ITPUB这个论坛，又看到我这篇文章，这足以证明你上一代没什么基础，就不要再做梦了，赶快起来跟我一起用DTrace+GDB研究Oracle原理才是正事。
要想成为管理人员，或是领导，无外乎三种途径：
1、在公司混久了，跟着上级、甚至公司创业者一起打天下，有资历。走这条路，要看运气，跟对了人就行。
2、潜心研究技术细节，深入钻究技术，成为大牛，转而成为领导。这就是学而优则仕了。
3、有关系，家人在有关部门任职。

如果你发现自己没有跟对人，也没有关系，要想成为领导，哪就走第二条路吧。我知道很多优秀的领导，都是这样走过来的。比如我们团队的头，还有Biti，都是如此。其实，就连我所提到
的"A同学"，现在的某互联网巨头企业中高级管理人员，也是如此走过来的。
大多数离职的人对以前待过的公司都是颇有微词的。也是啊，如果不是因为待着不爽，谁愿意走呢。但我对阿里，感觉还是非常好的。因为阿里，我来到了杭州，在钱江之畔，生活了近3年时光。在阿里，我终于实现了我的目标----让技术更上一层楼。三年时光匆匆而过，正如一部电影所说，年华就是如此，当你不再拥有，你唯一可以做的，就是令自己不要忘记。

尾声

站在远处，最后看了一眼雨中阿里巴巴园区漂亮的大楼，我生命的这一阶段已经过去。这是我生命中目前为止收获最多的一个阶段，感谢阿里、感谢我们的团队。

吕海波（Vage）- 漂泊的技术人生 - ITPUB访谈录

2013-07-31T04:05:40Z

本文引自ITPUB论坛，是Vage - 吕海波的技术感悟，很有借鉴和学习意义，供参考。

原文链接：http://www.itpub.net/thread-1806151-1-1.html

----------------------------------------------------------------------------------------------------------------

arron刘：
大师您好，今天很高兴采访您，您先自我介绍一下? 分享一下您的职业经历? 您目前从事的工作?
VAGE：
我的ID VAGE，相信大家都知道了，经常发一些深奥、晦涩的文章，骗几篇精华赚赚人气。
其实并不是我总是发晦涩的文章。Oracle基本的原理啊、运行机制啊等等，这些年来大家都讨论的差不多了。现在不是流行"产业升级"这一说吗，这么多年了，我们研究Oracle的方法，也要"与时俱进"、"产业升级"吗。不能老是内部资料+各种DUMP。
我相信下一代专职DBA一定要掌握些软件调试技能，我的深奥文章，也就是调试技术在Oracle中的简单应用而已。就像N年前搞个10046就属于高精尖了，我相信N年后我的文章只是入门级水平。就像现在的10046一样，如果现在你不懂得10046怎么用，还好意思说自己是DBA吗。
这次的OOW大会，很高兴看到Oracle将Solaris下优秀的调试工具Dtrace，移植到Oracle Linux下。其实几个月前我就已经得到这个消息，也第一时间试用了一下Oracle Linux下的Dtrace，功能当然没的说，但一些重要的探针（比如PID探针）Oracle Linux Dtrace下还没有，总的来说它还比较简单，期待以后版本中它进一步完善。
我的职业经历，这里就不详说了，在"35岁"那篇文章中：突然35岁：捡点我的职业生涯，已经有详细的介绍。
我目前在杭州博学负责Oracle的培训，同时还提供Oracle咨询服务。有需求可以联系我哦。除了这些表面上的工作，我在做的还有一件事，就是推广调试技术。我相信软件调试技术，将成为以后DBA的重要技能。

arron刘：
ORACLE最近发布了12C版本，相信您已经尝鲜试用过了吧，能不能分享一下你的安装经验，谈谈12C和以前版本在安装上有什么不同的地方？

VAGE：
12C从安装上步骤上看，和11GR2基本类似，连安装界面都差不多，相信安装上不会有什么难题。我分享过一篇Solaris下12C安装问题的解决思路。
因为缺包，安装完成后Oracle可执行文件是0字界，解决方法很简单，relink all了一下，重新编译生成Oracle的可执行文件，问题解决。可以参见：12C安装历险记----ORA-12560和ORA-12537的解决方案。
安装其实很简单，从这个安例中，我更想分享的是一种解决问题的思路。希望对大家、特别是初级DBA有帮助。

arron刘：ORACLE 12C 应该是甲骨文公司的重量级产品，据说有500多项的更新，您能不能给我们讲讲Oracle 12c最主要的变化是什么？给我们分享一下你的使用感受呗。

VAGE：
变化，我觉得可以从两方面来说，一是功能，二是内部原理。
先说功能上的变化，12C新功能的确很多，最大的亮点就是"Pluggable Database"，PDB，"可插拔数据库"。网上已经有很多相关的文章，每一个PDB都是一个单独的小数据库，若干个PDB组合在一个大的CBD中，共同构成一个大数据库。需要迁移数据的时候，可以将某个PDB拔出，插入进另外的CBD。这个特性，将使未来的数据迁移、数据流动更加方便。
还有ASM方面，ASM和数据库实例可以分别放在两台主机上。ASM和数据库实例的分离，至少说明Oracle以后有可能要为ASM添加更多的功能，如果ASM和数据库实例挤在同一机器，ASM功能太多，占用资源太多，势必会影响数据库实例的运行。
而且，分离之后，ASM就有点像存储的控制器了。存储控制器通过网络把LUN输送给主机，ASM通过网络，把DiskGroup输送给数据库。
还有，至得一提的时，12C中Oracle开始对EM做减法，推出了轻量级EM，安装简单、占用资源少，问题也更少。使用轻量级EM，将大大方便DBA们的操作。但同时，图形化、智能化工具的普及，也必将提高DBA的要求。未来DBA必将向"一专多能"方向发展，但要注意，千万不能只"多能"。有"一专" 为基础的"多能"，是如虎添翼。我还是哪句话，当水涨上来时，我们只有爬的更高。

另外，从内部原理、运行机制上说，Oracle也有不小的变动。Oracle从来没有停止精益求精的步伐。比如，12C下LGWR已经可以有多个，多 LGWR无疑将大大提高并发事务量。为达到这个目的，Oracle必然对Redo这块的机制有很大的变动，Redo这块的调优、排故，方法必然会有变化，以往的经验有可能不再适合。
还有，以前在9i时代，我就觉得Buffer Cache池、共享池已经非常完善了，这一块原理基本不会发生变化了。到了10G，Buffer Busy Waits就发生了变化。还有，Mutex的出现，对共享池的锁机制做了很大的改动。12C后，Mutex、IMU等技术继续优化、完善。举个简单的例子，Oracle获得共享Mutex的函数是kgxShared（已验证在Linux和Solaris下都是这个函数），在Oracle的可执行文件中，11.2.0.1下，这个函数的大小是1496字节。而在12C中，这个函数大小缩减到393字节。（注：只需要在gdb或mdb中，反汇编一下这个函数，就能获得函数大小）。
共享Mutex缩小了三分之二左右，代码量大大减小，CPU的消耗也将更加少。当然，Mutex的变化主要体现在内部，对我们维护人员来说无所谓。但还有些变化是和我们相关的，比如log file sync与log file parallel write的关系等，后面我会找时间写篇文章和大家分享下。

arron刘：
现在云计算和大数据是时代的宠儿，ORACLE也不能置身世外Oracle 12c这个C是不是代表着云计算呢？新的数据库版本在云计算中有哪些应用呢？

VAGE：
其实我理解云就是前些年SAAS的延伸，软件就是服务。以后使用软件，就像电源插座一样，无论到哪里，接上插头就可以使用。Oracle DataBase本身是系统软件，系统软件不必是云。就好像Linux一样，我暂时还无法想像Linux怎么变成云。但系统软件要能很好的支持上层的"云应用"。我觉得12C中的C，是指Oracle将更好的支持上层的"云应用"。
在"云应用"的背景下，数据要有更好的流动性，接上插头、或打开水管，数据就流出来了，"可插拔数据库"，是Oracle在这方面的尝试。另外还且个不得不提的东西，就是OGG，虽然它不是在12C中新推出的，但它无疑可以增加数据的流动性。

除了让数据"流"起来之外，应用程序升级到"云应用"后，对数据的规模要求一定越来越大，因此大数据是不可避免的趋势了。其实使用Oracle RAC和ASM，也可以方便的搭建大数据计算平台。
大数据通常都要数据分布化存储，这样才能有更好的扩展性，才能更好的支持大规模数据。
ASM也能实现数据的分布化存储，扩展也可以很方便。而RAC则可以实现分布式计算，也就是多台主机一起进行计算。

比如，先看一张RAC的图：

图比较简单，大家凑合着看就行。上面是N个RAC节点，下面是一台共享存储，其中有N块硬盘。这是RAC的传统架构。我主要想通过这幅图表达一个问题，先不说RAC节点数多对性能的影响，单说RAC的共享存储，一直是RAC的一大限制。共享存储限制了数据的分布性。像GreenPlum和Hadoop等等都是Nothing Shared的全分布式架构，扩展更方便，能力更强。
其实使用iSCSI+ASM，做一个类似分布式的架构也并非难事，看下图：

下面的存储节点可以是有很多硬盘的PC Server，每个PC Server的盘用iSCSI技术输送到所有计算节点，然后用这些盘创建ASM的DiskGroup。
以后随着数据空间规模的扩大，只要再接入更多的PC Server，就可以扩展空间了，扩容也很方便。
不过，很多时候，这张图被画成这样：

看这张图，还是集中式的架构。一套ASM，集中存放所有数据。其实数据是分布式的。假设在ASM中建一个表，在AU大小1M的情况，这个表的数据会以1M为单位，分布到所有磁盘中。如下图：

假设在节点1，发起一条命令，对这个表进行全扫描并排序。我们知道，在RAC下，并行操作是会被传播到其他节点的。如上图，也就是说，上图的每个计算节点会一起完成扫描、排序。
在协调节点的控制下，全扫描、排序将按如下图方式完成：

节点1从存储节点1、2中读取第1、2M。同时节点2从存储点3中读第3M，等等。每个计算节点会同时从多个存储节点一起读数据。
多个计算节点，每个都在对一部分数据作操作。每个存储节点，都在为不同计算节点输送数据。简单点说，就像这张图：

数据分散存储在多台PC Server中，这不就是一套分布式的系统吗！但同时，它又是一套集中式的数据库系统。
试想一下，如果下面的存储节点使用了SSD技术，网络使用和光纤有一比的InfiniBand，这套系统可以提供超大的IOPS，和超高IO吞吐量。
并不一定只有GreenPlum、Hadoop等才是大数据，ASM、RAC也可以实现分布化、大数据。而且，由于对外这还是一个统一的、集中的数据库，这样的方案还有纯分布式不能提供的好处。
还有一个问题：RAC节点数太多的影响。其实RAC节点多少，对整体性能影响不大。节点太多，主要影响稳定性。但Oracle一直在改善多节点的稳定性，相信未来多节点不会是RAC稳定性的瓶颈。
arron刘：
能不能谈谈您在工作中遇见印象比较深的的难题，您是怎么解决的？谈谈您在工作中解决问题的思路？

VAGE：
留给我印象最深刻的难题，说来很搞笑，其实是一个简单的问题。每次提到这个"难题"，总让我联想起一个小故事。
说是一家医院，有一段时间总是在凌厚5、6点钟有人病人死亡。经过多方调查，多位专家、牛医汇诊，始终无法找出原因，最后院方重金聘请国内外数位专家学者，组成调查团，入驻医院调查病人死亡原因。最后结果，大大出人意料。
又一天凌晨5点左右，专家已经在病房中开始忙碌起来，检查这个、检查哪个等等的情况，一切都在有条不絮的进行着。这时只见门一开，打扫卫生的阿姨推门进来，开始打扫卫生。阿姨拔掉电源上的插头，收拾一下零乱的线头，开始拖地、扫地、......。众人过去一看，被拔掉的，赫然有呼吸器的插头。问题终于找到了。

好了，说说我这个案例。这是阿里非常重要的一套核心库，从某天开始，总在11：20分连接数爆涨，偶而有超过processes参数的趋势，不得不手动 Kill掉一些相对不太重要的连接，避免连接数超出。通常两、三分钟后正常。经过调查，发现在11：20分，数据库的各项性能指标（如逻辑读、物理读、解析次数、执行次数等）先降后升，如下图：

这张图上三项资料的值，执行次数、调用次数、解析次数，在11：19分50秒左右，突然下降，然后在不到一分钟的时间中，又大幅上升。然后，又不到一分钟时间，一切都恢复正常。
黄线是执行次数，在大幅上升的顶点，执行次数有可能超过每秒2.4万次。正是在这个峰值时刻，连接数也达到顶峰。
看到这个图，我当时的判断是，在下降阶段，一定是有什么锁之类的东西，将大家都阻塞了，因此执行次数、逻辑读都大幅下降。之后，"某种锁"释放了，被阻塞的进程一齐要求执行，结果各项性能指标突升。
就好像将河水拦起来，下游没水了，突然将水放开，下游顿时巨浪滔天。然后，蓄的水流完，一切恢复正常。
如何确定问题呢？很简单，既然是某种锁阻塞了大家，只在看等待事件即可。
由于这是9i的库，查不了历史等待事件，只有等第二天再说了。
第二天到了，11：20，情况出现，各项资料先降后升，连接数猛然冲高，然后恢复正常。整个过程，我一直在不停的查看等待事件。但是，什么都没有查到。没有发现所谓的"某种锁"。
哪底是什么问题呢？经过多方调查，DBA、开发、架构、......，各种人员会诊下，问题依旧不明。
第三天11：20分，大家正聚在一起会诊情况，一名开发悠悠的打开电脑、登录VPN、连接应用，开始从一批MySQL集群中拖数据到DW，问题终于找到了，......。
呵呵，当然最后这段有"戏说"的成份，事实情况是，经过分析，根据Oracle没有等待事件判断，性能资料的下降不是由Oracle自身造成的。既然不是 Oracle自身的问题，最大的怀疑对象是网络。经过几天的调查，发现同一机房、同一交换机还连接了一批MySQL。本来MySQL中的数据分阶段向DW 中同步，但可能开发考虑这样一天同步几次太麻烦了，将同步时间改成了每天同步一次，具体时是中午11：20。

这个案例，我想说明的是，当需要网络、MySQL等其他部分同事配合调查问题时，一定要足够的知识、数据，告诉其他部门的同事、领导，"问题不是Oracle"，才能获得帮助。
当你向领导汇报说："问题不是Oracle"。
领导一定会问："为什么？"。
你回答："因为没有等待事件。"
这时候，十有八九的领导都会再问："为什么？"
后面就是发挥的时候了，用简短的语言，解释清楚为什么没有等待事件就说明问题不是Oracle。交流、沟通，永远是我们DBA必不可少的技能。但交流、沟通，并不是全部，还要有过硬的技术作基础。

还有一个案例，有一个RAC，版本是10G的，有一个节点有一段时间经常因为ORA-07445重启，找不到原因。打开当机节点的Trace文件，发现有如下的调用堆栈：
----- Call Stack Trace -----
calling             call    entry             argument values in hex
location          type    point             (? means dubious value)
-------------------- -------- -------------------- ----------------------------
skdstdst()+64       call    kgdsdst()          000000032 ? 000000004 ?
ksedst1()+432       call    skdstdst()          00000001E ?
ksedst()+128       call    ksedst1()          C00000123065F668 ?
dbkedDefDump()+1456  call    ksedst()          9FFFFFFFFFFFB710 ?
ksedmp()+80       call    dbkedDefDump()    000000003 ?
ssexhd()+2672       call    ksedmp()          9FFFFFFFFFFFC640 ?
         call    ssexhd()          9FFFFFFFFD54CB68 ?
skgxpdmpmem()+52481  call               9FFFFFFFFD54CB68 ?
skgxpgetimd()+51808  call    skgxpdmpmem()+48656  C0000017212BC1B9 ?
skgxppost()+27808 call    skgxpgetimd()+51104  6000000000043FA0 ?
skgxpvsnd()+11696 call    skgxppost()+23936 9FFFFFFFFFFFD340 ?
skgxpwait()+512    call    skgxpvsnd()+7104    9FFFFFFFFFFFECB0 ?
ksxpwait()+2928    call    skgxpwait()       000000032 ? 000000004 ?
$cold_ksliwat()+203  call    ksxpwait()          00000001E ?
kslwaitctx()+240    call    $cold_ksliwat()    C00000123065F668 ?
kslwait()+192       call    kslwaitctx()       9FFFFFFFFFFFB710 ?  000000003 ?
ksxprcvimd()+1120 call    kslwait()          000000003 ?
........................
正好哪段时间我一直在研究Oracle的等待事件机制。Kslwait、skgxpwai等等这些函数正是Oracle产生等待事件的函数。Trace文件是Lms进程的，看问题是lms产生了某个等待事件，在登记等待事件后出的问题。如果能知道lms当时产生的等待事件是什么，问题应该就有了方向。
但是查看了相关的Trace文件，找不到当时的等待事件。最后的方法很简单，使用oradebug中的call命令，调节ksxpwait函数，参数是 000000032，000000004等。然后查询oradebug的会话在等待什么，发现它在等一个不常见的I/O类等待事件（具体事件名记不太清楚了）。由此判断，是I/O导致的问题。最终发现是存储多路径软件版本的问题。

综合这两个案例，解决Oracle问题，无外乎也就技术、沟通这两点而已。

arron刘：
现在数据库技术更新换代的速度越来越快了，您觉得从业者该怎么选择自己的学习方向？比如说应该学习什么数据库之类的问题。

VAGE：
我觉得这个要看个人爱好了，有兴趣研究源码的，我觉得去研究一下MySQL、PostGreSQL等等，是个不错的选择。如果对代码不感兴趣，那就选择Oracle好了。
当然，还有Hadoop类的NoSQL类方面，也是值得考虑的。如果年龄还不算大、还有时间的话，可以都接触下，看一下兴趣点在哪里。毕竟，学习是很苦的事情，如果不能发掘点兴趣出来，是很难坚持的。
另外，虽然现在是个一专多能的时代，但在选择方式时最好还是要有所选择。有些专业，加在一起可以起到双剑合璧的效果，威力翻倍。但有些专业，多会一样，可能只代表工作量会翻倍。比如开发和美工。美工设计出的界面有可能脱离程序，开发设计出的界面有可能脱离用户。开发+美工，等于界面设计师。好的界面要由界面设计师设计。界面设计师编码能力一般，美工能力也不要求多高。界面设计师如果单纯从事开发的工作，或美工的工作，收入都比较低。但将开发、美工二者结合后，收入将会提高很多。选择方向的时候，其实不仿考虑一下，哪个方向和自己现在的工作结合度更高。哪个方向可以和自己现在的专业"双剑合璧"。

arron刘：
您作为行业的老人，不知道有没有遇见过学习瓶颈的问题？您面对这种问题是怎么解决的呢？有没有什么好的方法分享一下。

VAGE：
学习瓶颈啊，我已经遇到过好几次了。第一次瓶颈是在学习编程7年之后，大概是2003年。我个人比较偏爱C语言，公司有些项目是SDK开发的，使用的是C语言。但更多项目是使用的5花八门的语言。
就像现在很多人苦恼一样，公司里用Oracle，就学Oracle。业务上有MySQL，就再学MySQL，还有SQL Server等等，结果会了一大堆数据库。
我当时是事业单位的临时工，为了不被辞掉，我甘当一颗革命的螺丝钉，哪里需要哪里拧。为了单位需要，我学习了C++、Visual FoxPro、Java、VBScript、JavaScript，还有Oracle的Form/Report。更离谱的还有Flash中的脚本编程。
这样广泛涉猎多年之后，我发现很多专一的人已经比我牛B太多，牛B的我连想去超越的勇气都没有了。我觉得编程上自己很难再有成果，很难再前进。决定换个方向，这个新的方向就是Oracle了。正好单位也需要Oracle方面的人，我又一次充当了革命的螺丝钉。不过，痛定思痛，这一次我决定专一点，只搞 Oracle。
这样又过了8年，在我到阿里后第二年，当时觉得Oracle真没什么可学的了。雾里看花的研究内部原理，如同隔靴搔痒，很多地方总感觉没办法研究透。只能在网上搜各程各样的文章，讨论起原理总是说谁谁的文章中提到过，某篇内部资料说了，这个地方应该怎么怎么样。感觉DBA有点像考据学家了，整天查这个资料、翻哪个资料，一开口就是，史记第几章提到什么什么，汉书第部分讲了什么什么，因此怎样怎样。
关键是这样的研究，由于无法了解透某些技术的原理，在真出问题的时候，意义不大。所以当时我非常同意一个观点：内部原理的研究，应当适可而止，再深入下去只是满足好奇心，对于调优排故帮助不大。
我觉得是时候"适可而止"了。这是我第二次遇到瓶颈。
当是也迷茫了好久，本来计划另选新的方向，比如MySQL、Hadoop等等。但偶然的机制发现Dtrace后，用这东西研究原理，发现很多原来无法搞清楚的东西，可以搞的比较透了。再后来又结合gdb/mdb，可以将内部机制了解的更加清楚。
一旦可以通透的了解机制，对于DBA帮助还是非常巨大的。最明显的一个好处，一些等待事件、v$sysstat中的资料，其根本意义将更加清楚的展现在你眼前。
举个简单例子，Oracle有两个简单的网络相关等待事件，"SQL*Net message to client"和"SQL*Net more data to client"，一个是Message to Client，一个是More data to client。这二者有什么区别？
我们都知道Oracle有一个"预读取"，或叫"批量读"的功能，在SQL*Plus中可以用set arraysize 设置批量读的批大小。在SQLPLUS中默认值是15，也就是一次逻辑读默认读15行。
逻辑读的数据是发何发送给客户端的呢？这些数据要先被读取出来，暂时存入PGA的一块名叫Session Data Unit（简称SDU）的空间，再从SDU中通过网络发送给客户端。
SDU默认大小是8K，如果一次逻辑读读出的数据小于SDU大小，等待事件是"SQL*Net message to client"。如果一次逻辑读的数据大于SDU，数据将被分多次发送，这时将会有等待事件"SQL*Net more data to client"。具体来说，比如一次逻辑读的数据共10K，而SDU是8K，这将会产生一次"SQL*Net more data to client"，一次"SQL*Net message to client"。
关键问题是，数据已经占满SDU，这时加在数据块对应Buffer上的Buffer Pin锁不会释放，因为一次逻辑读还没有完成。数据通过网络发送，同时进程注册等待事件"SQL*Net more data to client"。发送完数据，继续逻辑读。直到这个块Buffer中的数据被读完、或者达到一个批大小，Buffer Pin锁才释放。
也就是说，Buffer Pin锁的持有，在有等待事件"SQL*Net more data to client"时，包含了网络的传输。这将导致Buffer Pin锁持有时间加长，有可能触发Buffer Busy Waits相关等待。
简单点说，批量读批大小超过SDU，将会有"SQL*Net more data to client"。没超过是"SQL*Net message to client"。而有"SQL*Net more data to client"，则说明进程将在块Buffer上持有更长时间的Buffer Pin锁。
SDU的大小，虽然默认是8K，但它是可调的。关于它，在文档"Net Services Reference"，第5章中，和文档"Net Services Administrator's Guide"第7章中，都有介绍。我将"Net Services Administrator's Guide"第7章中的粘下来，这一段还比较详细：

Session Data Unit (SDU) Size
Before sending data across the network, Oracle Net buffers and encapsulates data into the session data unit (SDU). Oracle Net sends the data stored in this buffer when the buffer is full, flushed, or when database server tries to read data. When large amounts of data are being transmitted or when the message size is consistent, adjusting the size of the SDU buffers can improve performance, network utilization, or memory consumption. You can deploy SDU at the client, the application Web server, and the database server.

说实话，这段英文看的我莫明其妙。很早之前我看这段话的时候，完全无法理解SDU的真正影响与作用。
SDU到底控制着什么，调节它的大小可以影响性能，影响什么性能？影响有多大？......，有N多的问题，文档中都没有提到。
没有提的原因无外乎有两个：一是信息垄断。只有内部人士可以掌握更多的信息，现代社会，信息就是金钱啊，相信Oracle有理由这么做的。
不过，这个调节参数是在sqlnet.ora等监听配置文件中调的，如果真是为了限藏它，干脆在文档中不提多好。
如果文档不提，用户用show parameter或查隐藏参数的视图，又找不有这么个东西。这样多好，除了内部人，其他人断无可能知道有这么个东西。
文档即然提了，又没讲清楚，我想还有另一个原因，就是写的文档的人也不知道这东西是干吗的，从以前版本的文档中直接照抄过来完事。

我原来在网上也了解过这个参数。一些个老外也有提到过这个东西，但都没有说清楚。
说白了SDU很简单，加大SDU大小，可以将"SQL*Net more data to client"等待事件变成"SQL*Net message to client"事件，减少Buffer Pin锁的持有时间，节省CPU。
使用gdb/mdb和Dtrace，非常简单就可以将SDU的意义发觉出来。我就是在一次调试Oracle时，发现进程运行代码中，一会注册 "SQL*Net more data to client"等待事件，一会注册"SQL*Net message to client"等待事件。进一步分析，发现读取数据量超过8K时，就会有"SQL*Net more data to client"等待事件。然后在文档中查了一下，SDU的默认值是8K，修改了这个值，果然可以去掉"SQL*Net more data to client"等待事件。因此发现SDU的作用，过程也很简单。
有时间再和大家详细分享这个结果吧。继续讨论"瓶颈"的问题。我的第二次瓶颈，就是在发现调试工具可以用于Oracle后打破的。软件调试+Oracle，这是我给自己设定的一个新方向。
软件调试也是一个大方向，需要了解很多东西。比如，操作系统原理，这是必不可少的。《深入理解Linux内核》，《深入理解Solaris内核》，这些书是要大概翻翻看的。
就像现在流行的量子物理一样，人类的一憋，确定了量子的位置。作为观测者的人娄，对被观测对象亚原子，是有影响的。计算机也一样，调试也会影响到调试对象。但影响到底在哪里，这些只有在对操作系统原理有基本的了解后，才能明白。
Linux下还有一个调试利器：Ptrace，Gdb就是用这东东实现的。还有CPU的一些相关知识，这些都要去学。
学好调试这块，真的要进入底层了。
不过，这样的学习收获是很大的。对计算机底层有基本的了解，这是每个IT技术人员的基本要求。如果我们对CPU、内存等等的了解，只停留在频率、型号上，这样的话我们和电脑城买电脑的也差不多了。但人家是销售，我们好歹也是技术人员。你说一技术人员对内部的了解和销售差不多，有点说不过去吧。而且，基础知识不足的话，也很容易有一些让开发笑话的观点。
曾有人不太理解一种CPU负载的计算方式：逻辑读块数乘以块大小。
逻辑读的确是消耗CPU的操作，但一个复杂的数据库可不只逻辑读消耗CPU。而且，一个逻辑读可不一定都是读8K，有可能只是从8K中只读几十个字节。逻辑读块数乘8K，这样的统计方式的确有点莫明其妙了。如果对计算机底层基础知识有些了解的话，对于这样的错误结论是很容易理解的。
调试+Oracle估计够我再学个一、两年的了，哪天瓶颈再到了，我计划自己写写数据库玩玩，最近看了老虎的帖子：用数据库的称为大师，写数据库的笑了......^_^，心痒难耐，等我的书稿完成后，下半年我也响应虎皇号召，去搞搞这块。

Oracle群英录 - 2013上海OOW名人录

2013-07-26T07:38:47Z

以下是出席2013上海Oracle Open World（甲骨文全球技术大会）的官方重要人名名单及履历，在这次大会上马克赫德因飞机故障最终未能出席。

马克·赫德
甲骨文公司总裁
马克·赫德先生目前担任甲骨文公司总裁及董事会成员。他于2010年加入甲骨文，拥有超过30年与领先技术行业、计算机硬件以及执行管理相关的丰富经验。作为总裁，赫德负责甲骨文公司全球市场运营的企业发展方向和战略，包括市场、销售、咨询、联盟与渠道以及支持。他主要关注战略、管理、创新和客户。赫德先生说："作为一个企业，我们的任务就是帮助客户节省成本并进行创新。"

在加入甲骨文之前，赫德先生曾担任惠普公司的董事会主席、首席执行官以及总裁，负责客户、创新、提高运营效率及执行管理，在其领导下，公司业务取得显著增长。在此之前，他在NCR公司工作了25年，并在该公司担任过包括管理、运营、销售、市场等多项职位，最终成为该公司的首席执行官和总裁，成功带领该公司提升运营效率、增强产品线并促进业务增长。

赫德被《福布斯》（Forbes）评为2009年"最佳管理者"之一。2007年，赫德入选《财富》杂志25位年度最有影响力的商业人士。他也曾多次入选《Business 2.0杂志》的50位最重要人物（Who Matter Now）以及《巴伦周刊》的最佳CEO名单。《旧金山纪事报》将其评为2008年年度CEO。他曾3年入选CRN的25位最有影响力的管理人员名单，两次成功入选最佳25强管理人员。

John Fowler
甲骨文公司系统事业部执行副总裁
John Fowler现任甲骨文公司系统事业部执行副总裁，在公司战略、系统以及软件开发方面拥有深厚的从业经验。

John Fowler于2010年加入甲骨文，此前，Fowler先生已供职Sun公司超过14年，并相继担任过一些重要职务，包括Sun系统集团执行副总裁、Sun软件事业部首席技术官、以及Sun x64系统集团执行副总裁等，主要负责为Solaris、Linux和Windows开发行业标准的网络计算系统。

在甲骨文，John Fowler继续负责所有Sun系统产品的开发工作，包括SPARC和基于x64的服务器，以及网络和磁盘与磁带存储产品等。此外，他还负责系统软件工作，包括Oracle Solaris等。

Steve Miranda
甲骨文公司应用产品开发执行副总裁
作为甲骨文公司应用产品开发执行副总裁，Steve Miranda负责全面领导Oracle应用产品和相关云服务的产品政策、产品发展和产品交付。这些产品包括Oracle Fusion Applications和Oracle针对顾客服务与支持、商业和人才管理所设计的最新产品。

Miranda先生于1992年加入Oracle，担任过多项领导职务。2007年，他曾经出任Oracle新一代软件应用套件和Oracle Fusion Applications 的主要负责人。在Miranda先生的领导下，Oracle不断履行着帮助应用软件客户赢得创新、保持竞争力的承诺，并且利用Oracle新产品与服务帮助客户优化其IT投资的价值。在加入Oracle之前，Miranda先生曾就职于GE Aerospace。他拥有斯坦福大学的数学和计算科学学位。

Andrew Mendelsohn
甲骨文公司数据库技术产品高级副总裁
Andrew Mendelsohn现任甲骨文公司数据库技术产品高级副总裁，主要负责开发和管理甲骨文的各类数据库产品，包括软件类产品中的Oracle数据库、Oracle TimesTen 内存数据库、Oracle Berkeley数据库、 Oracle NoSQL 数据库，以及 Oracle Exadata 数据库云服务器、 Oracle数据库机和Oracle大数据机等集成设计系统。

Mendelsohn先生于1984年5月加入甲骨文，曾担任过甲骨文数据库5.1版本的开发者。在加入甲骨文之前，他曾在惠普和ESVEL公司供职。Mendelsohn先生拥有普林斯顿大学电子工程和计算机科学的工程学理学位，并在麻省理工学院完成计算机科学的研究生学习。

David Vap
甲骨文公司应用开发集团副总裁
David Vap目前担任甲骨文公司应用开发集团副总裁，负责基于云的甲骨文用户服务产品系列的战略及管理，并协同包括销售、服务、市场营销及商业应用在内的整个甲骨文用户体验产品线的战略。

作为拥有20年经验的科技领域资深从业者，Vap先生在2012年因RightNow公司的收购而加入甲骨文。在RightNow时，他担任产品副总裁，负责产品战略、产品管理及市场营销。

加入RightNow之前，Vap先生担任Software AG的销售及市场营销副总裁。任职期间，他定义并推广了领先的商务流程SOA套件Software AG Crossvision，同时主导其销售工作。他还曾担任内容管理厂商Artesia Technologies产品副总裁，负责产品管理、开发及质量控制。在加入Artesia前，他成立了一家专注于基于CASE工具环境的包装解决方案的专业服务公司并成功将其出售。他在华盛顿的PwC开始他的职业生涯。

Nandini Ramani
甲骨文公司Java客户开发副总裁
Nandini Ramani是甲骨文公司Java客户开发副总裁。她负责Java客户平台业务，长久以来为Sun公司的创新和未来发展做出了很大贡献。

Nandini发起了JavaFX平台及工具的开发，自2007年5月JavaFX平台的开发启动以来，一直积极参与其中。加入客户机部门之前，Ramani女士在"软件首席技术官办公室"工作，负责推动实施孵化项目的新技术部门的工作。她在硬件和软件领域都拥有丰富经验，一直参与"图形加速（Accelerated Graphics）"部门的硬件架构和仿真团队以及JavaME部门的图形和媒体团队的工作。她参加了XML标准的开发，是W3C"可缩放矢量图形（Scalable Vector Graphics）"工作组的联合主席，也是W3C"复合文件格式（Compound Document Formats）"工作组的成员。她还是JCP的几个图形及UI相关专家组的成员。

Peter Utzschneider
甲骨文公司Java产品管理副总裁
Peter Utzschneider现任甲骨文公司产品管理副总裁。Utzschneider先生现在负责Java产品的市场策略，包括Java SE、JavaFX、Java ME 以及Java 嵌入式产品等，以持续推动Java产品的商业成功、Java社区的振兴以及甲骨文公司对Java语言和技术的持续承诺。

Utzschneider先生曾在欧洲和美国工作超过20年。通过将早期的市场需求转换为广泛的市场部署能力，他在市场营销和销售行业领先软件解决方案方面取得了很大的成功。在加入Oracle之前，Utzschneider先生曾担任Tangosol公司市场副总裁。加入Oracle之后，他进一步推动Cohenrence产品的发展，使其成为业界领先的数据网格解决方案，并成为Oracle融合中间件的一个重要组成部分。

Cameron Purdy
甲骨文公司云应用基础副总裁
Cameron Purdy现任甲骨文公司开发副总裁，主要负责Java EE平台、Web服务器和应用服务器等产品的研发工作。

在加入甲骨文之前，Purdy先生曾担任数据网格软件公司Tangosol的首席执行官，该公司具有创新性的Coherence数据网格（Coherence Data Grid）产品, 可为企业提供可靠的和可扩展的数据管理。自1996年起，Purdy先生开始从事Java和Java相关技术的工作，他还是JCP（Java Community Process）组织的规范领导者。

作为一位软件专家和行业领袖，Purdy先生经常在行业大会中发表演讲，并因其对Java社区发展的特殊贡献而多次获得嘉奖，其中包括三次被授予"JavaOne RockStar"奖并入选TheServerSide的"企业Java名人堂（Who's Who in Enterprise Java）"。

Amit Zavery
甲骨文公司融合中间件集团副总裁
Amit Zavery先生是甲骨文公司融合中间件集团副总裁，目前负责融合中间件产品的产品策略、发展线路图、产品定位以及上市推广计划，包括云应用基础、服务整合、业务流程管理、数据整合、商务智能、内容管理、企业门户、身份认证与访问管理以及开发工具等。

自从1995年加入甲骨文公司以来，Zavery先生曾在产品开发、产品管理、产品战略和咨询等领域担任要职。在负责Oracle应用服务器之前，他主要负责Oracle电子商务应用软件的产品开发和管理，包括Oracle iStore, iPayment, 以及iMarketing。Zavery先生还负责在印度创建了甲骨文CRM研发中心。

Zavery先生最早在甲骨文视频服务器产品团队担任解决方案架构师。随后，他在甲骨文咨询部门工作，负责实施大量的互动电视应用以及随着Web的普及为客户创建互联网应用。他还曾服务于Oracle数据库集团，负责规划和定义Oracle 9i数据库。Zavery先生拥有奥斯汀得克萨斯大学的电气和计算机工程理科学士学位，同时还持有美国的卡内基梅隆大学计算机科学和商业硕士学位。

Neil de Crescenzo
甲骨文公司健康科学事业部高级副总裁兼总经理
Neil de Crescenzo现任甲骨文公司健康科学高级副总裁兼总经理，负责甲骨文全球范围内的健康和生命科学市场业务，全面管理该行业解决方案团队、战略规划、产品开发、销售及服务支持。Neil de Crescenzo在健康和生命科学领域拥有超过25年的丰富经验及全球客户和合作伙伴资源，他在工作中充分展示了杰出运营能力及IT领导力。

加入甲骨文前，Neil de Crescenzo曾作为高层领导在IBM效力十年，负责该公司在全球的健康和生命科学客户管理。深耕IT行业之前，他曾在医药中心和健康保险公司领导层任职。Neil de Crescenzo多次以主题演讲者的身份出席众多全球性的行业大会，并在相关领域话题上广受推崇。Neil de Crescenzo毕业于耶鲁大学拥有政治学学士学位，并随后在美国东北大学取得高科技工商管理学硕士学位。

Chris Baker
甲骨文公司全球ISV/OEM/JAVA销售高级副总裁
Chris Baker任甲骨文公司全球ISV/OEM/JAVA销售部门主管，负责与ISV/OEM伙伴合作，同时最大化甲骨文的业务价值，进一步为合作伙伴的终端用户提供优质服务。在担任此职务前，Chris是Oracle EMEA管理组的成员之一，并担任甲骨文公司高级副总裁，负责核心技术业务。

Chris于1997年1月加入Oracle，曾担任一系列高级管理职务，包括负责英国、爱尔兰及以色列地区的技术许可业务高级副总裁，英国、爱尔兰及南非地区的咨询副总裁兼部门主管，以及英国、爱尔兰和南非地区的应用与技术产品副总裁。此外，他还担任过Oracle支持部门的英国区总监。

在加入Oracle之前，Baker曾在Digital Equipment工作13年，曾担任英国区销售总监，负责公司的外包业务。Baker是一名资深的土木工程师，获有邓迪大学的土木工程学士学位，并在IT领域拥有超过25年的丰富经验。

Lyle Ekdahl
甲骨文公司集团副总裁兼JD Edwards总经理
Ekdahl 先生自2009年开始担任甲骨文公司集团副总裁兼JD Edwards产品总经理，包括JD Edwards EnterpriseOne及JD Edwards World系列。此前，在2005年至2009年，他曾任JD Edwards全产品线的产品策略及管理副总裁。

Ekadah先生于2003年加入JD Edwards EnterpriseOne团队。在此之前，他先后于Siebel Systems、Scopus Technology、Platinum Software和Channelpoint等公司担任高层管理职务。同时，Ekdahl先生在一系列国际高科技企业拥有超过20年的从业经历，对产品研发、管理、市场营销、分析及运营等领域均有丰富的经验。

Robert K. Weiler
甲骨文公司全球行业事业部执行副总裁
Robert K. Weiler现任甲骨文公司全球行业事业部执行副总裁。此前，他曾在临床试验与医药安全领域数据管理解决方案领先供应商Phase Forward担任董事长和首席执行官。Weiler先生在科技领域拥有30余年的领导经验，比如曾在Giga Information Group过担任董事长、总裁和首席执行官。在他的事业生涯早期，Weiler先生曾在Eastman Software（原名Wang Software）公司担任过总裁和首席执行官，也曾在Lotus Development Corporation担任过全球市场销售高级副总裁，对公司Lotus Notes的业务拓展发挥了至关重要的作用。

Weiler先生目前是SADD（青少年毒品及犯罪防治组织）董事会成员之一，也曾是Waterville Valley Company、Saint Anselm's College、Corporate Software、Distributed Management Systems、Cullinet Software Interleaf、DataLogix和Giga Information Group的董事会成员。Weiler先生拥有Saint Anselm's College的学士学位，并于2000年获得荣誉博士称号。他曾荣获美国新英格兰区2010年度安永医疗IT领域企业家荣誉称号；2006年，他名列PharmaVOICE 100强；Weiler先生也因其在商业及科技领域优秀的领导才能获得麻州科技领导协会的认可，荣获2006年度首席执行官的奖项。

Barry Clark
甲骨文公司集团副总裁兼全球零售事业部销售负责人
Barry Clark拥有30年的销售和综合管理经验, 于2011年3月甲骨文收购ATG时加入甲骨文。Barry Clark先生于2011年3月至2013年6月期间出任甲骨文集团副总裁，负责公司全球商业销售业务。在加入甲骨文之前，Barry Clark先生曾在Schoolkidz Inc., Domino Printing Sciences, AM Multigraphics 和 Digital Equipment等公司担任多项重要的销售以及管理工作。

Chet Kamat
甲骨文金融服务软件有限公司首席执行官兼董事总经理
Chet Kamat现担任甲骨文金融服务软件有限公司首席执行官兼董事总经理。该公司是一家甲骨文控股子公司和甲骨文金融服务全球事业部的重要组成部分。凭借着25年多深厚的金融服务、咨询和业务转型经验，Chet Kamat在Oracle金融服务软件领域发挥了重要作用。

在加入甲骨文之前，Chet Kamat是一家领先的私人股权投资公司STG的董事总经理，该公司主营投资软件和企业服务公司。在STG，其负责投资组合公司的转型和运作，并特别关注这些公司在全球经营模式上的运用。

在这之前，Chet曾在埃森哲及一家零售金融创业公司担任CEO。其1986年加入埃森哲，曾在印度、美国、瑞典、匈牙利和菲律宾等多国，从事广泛业务咨询和大范围的系统整合工作。离开埃森哲前，Chet掌管埃森哲印度交付中心网络的合作伙伴，负责从无到有，建立并发展到拥有13000多个员工，服务于200多个全球客户的事业部。

Gregory Midtbo
甲骨文公司全球金融服务事业部行业副总裁兼全球负责人
作为甲骨文公司金融服务事业部全球负责人，Gregory Midtbo先生带领着一支行业专家团队，管理着甲骨文在全球金融服务行业领域的Go-to-market活动。

此前，Gregory Midtbo先生曾在甲骨文公司负责过纽约地区管理应用软件的销售以及亚太区域金融行业应用软件的销售。1995年加入甲骨文前，Gregory Midtbo先生曾在Treasury Services Corporation担任亚太区运营负责人，也曾在NCR和AT&T担任过多项销售和管理工作。他28年的工作经验无论是与市场信息技术还是金融服务产业都密切相关。Gregory Midtbo先生毕业于美国明尼苏达大学（University of Minnesota）并荣获金融本科学位。

Sonny Singh
甲骨文公司金融服务事业部高级副总裁兼总经理
Sonny Singh先生现在担任甲骨文金融服务行业事业部高级副总裁兼总经理，管理着甲骨文银行、保险及资本市场等行业相关产品的销售、咨询、工程以及支持等领域。

在甲骨文工作23年期间，Sonny Singh先生在公司及业务的创新执行方面以及新市场策略方面展示了其卓越领导力，不断推动着甲骨文硬件、软件和服务产品线在业界的影响力。

此前，Sonny Singh先生担任甲骨文行业事业部高级副总裁，负责甲骨文的上市策略，比如跨越甲骨文整个产品线和服务线的产品市场推广，竞争分析，市场培训，销售推动以及收购整合。此外，Sonny Singh先生负责提升甲骨文策略性客户的关系维护能力，比如针对所有行业的解决方案和专业技能计划，不断提升甲骨文品牌价值引擎竞争力的甲骨文洞察力计划以及甲骨文解决方案中心。在领导甲骨文行业事业部之前，Sonny Singh先生担任甲骨文咨询事业部的集团副总裁，领导着针对北美策略客户的甲骨文服务领域。

邹晓兵
甲骨文公司融合中间件产品管理副总裁
邹晓兵先生目前在甲骨文公司主要负责甲骨文市场领导融合中间件产品的上市策略，特别是合作伙伴计划以及跨平台解决方案。邹晓兵同时也负责基于整个Oracle融合中间件堆栈创建解决方案和策划上市方案，比如针对融合应用的甲骨文中间件。

邹晓兵先生因甲骨文收购身份管理软件领导者Bridgestream公司而加入甲骨文公司。他在Bridgestream公司负责市场、产品管理以及策略合作伙伴。在加入Bridgestream公司之前，邹晓兵先生曾担任TIBCO软件公司商业整合部总经理。他同时拥有南加州大学电机工程学硕士学位以及加州大学洛杉矶分校安德森商学院MBA学位。

Mark C. Lewis
甲骨文公司亚太区联盟与渠道部高级副总裁
Mark Lewis现任甲骨文公司亚太区联盟与渠道部高级副总裁，也是公司亚太区管理团队的成员之一。

Lewis先生常驻新加坡，主要负责制定和推动所有Oracle产品的渠道销售、市场和合作伙伴发展战略。其中包括与战略合作伙伴联盟、分销商以及平台合作伙伴发展成功的长期合作关系，并将所有渠道整合入亚太合作伙伴的生态系统之中。
在甲骨文工作的十年时间里，Lewis先生担任过销售、市场和企业并购等多项高层职务。在出任现职务之前，他负责甲骨文公司亚太区的运营工作，包括销售、市场发展、活动推广和企业内部沟通。Lewis先生于2001年加入甲骨文，此前他曾在Arthur Andersen和IBM供职，担任过泛亚地区销售、市场和咨询方面的职务。
Lewis先生拥有悉尼科技大学的数学学士学位，以及麦考瑞大学研究生管理学院的工商管理学硕士学位。他也拥有商业和市场推广方面广泛的专业背景和会员资格。

潘少海
甲骨文公司高级副总裁及大中华区董事总经理
潘少海于2012年出任甲骨文高级副总裁及大中华区董事总经理一职，负责公司在大中华地区的整体业务，其主要职责包括推动甲骨文在中国的增长计划，加速甲骨文全线产品的市场渗透，提升市场占有率和市场领导力，致力于兑现对大客户及核心合作伙伴的承诺，进一步扩展甲骨文的业务领域。

潘少海从2008年起，出任甲骨文亚太咨询服务（OCS）高级副总裁，全面负责甲骨文在亚太地区的咨询业务，这些业务包括市场进入模式，跨行业、跨地域解决方案组合、市场竞争力建立，为关键客户提供转型服务以兑现甲骨文的承诺。

潘少海在2007上半年加入甲骨文，主要负责提升甲骨文ERP咨询服务能力，加强甲骨文在大中华地区和韩国的ERP服务市场进入。凭借其在地区性咨询管理专业的广度和深度，成功帮助甲骨文建立了策略性的目标，确保了甲骨文对北亚市场潜力的挖掘和掌握。

在加入甲骨文以前，潘少海在惠普公司工作20年，曾担任该公司在亚太地区的多项高层管理角色，包括亚太及日本地区惠普服务公共部门总经理，亚洲和澳大利亚地区惠普咨询总经理，以及大中华区惠普咨询总经理等要职。

喻思成
甲骨文公司副总裁兼大中华区技术总经理
喻思成先生现任甲骨文公司副总裁兼大中华区技术总经理，负责管理售前技术团队。喻思成先生于2008年6月随甲骨文收购BEA而加入甲骨文公司。在BEA期间，曾任职于BEA公司北美研发部门，负责BEA的系统整合产品WebLogic Integration（WLI）的开发。2001年，喻思成先生从BEA美国总部调任中国，负责对BEA中国区售前技术团队的组建和管理，参与了BEA在中国的迅猛发展。

喻思成先生拥有加拿大Lakehead University工程硕士学位，并获得北京大学光华管理学院EMBA学位。1997年始担任美国西雅图FactoryMall 公司的CTO，专攻网上电子商务领域的创新。

潘杰君
甲骨文公司全球副总裁及大中华区应用软件总经理
潘杰君于2010年出任甲骨文全球副总裁及大中华区应用软件总经理一职，负责公司在大中华地区的应用软件的整体业务，其主要职责包括推动甲骨文在中国大陆，香港以及台湾的应用软件的业务增长，加强甲骨文应用软件产品的市场渗透，占有率和市场领导地位，并为客户带来完整的端到端的业务解决方案。

潘杰君从2007年起加入甲骨文，出任甲骨文亚太咨询服务全球副总裁，负责甲骨文在亚太地区的金融/电信/媒体/电力等的咨询业务，为关键客户提供转型服务，实施咨询并兑现甲骨文的承诺。潘杰君加入甲骨文前，也曾担任过仁科PeopleSoft大中国区总经理， JD Edwards北亚区总经理，也曾担任大型咨询公司在亚太地区的多项高层管理角色，并取得优异的业务成绩。

刘松
甲骨文公司大中华区技术战略部总经理
刘松先生现任甲骨文公司大中华区技术战略部总经理，负责甲骨文中国战略性产品方向的规划与执行，新技术与解决方案的推广，并担任公司技术发展趋势的主要发言人；通过众多大型IT项目的实际介入，与国内各个行业信息主管的深入沟通，结合国内客户与合作伙伴的具体情况，他的工作重点是帮助国内企业的信息主管在理解技术趋势的基础上更好的使用IT技术，用于行业应用。作为几个软件行业媒体的专栏作者，他的许多言论被国内的知名IT媒体作为行业技术趋势方面的内容来源之一。

刘松先生在中国IT市场拥有15年的工作经验，在加入甲骨文公司之前分别在IBM、BEA等公司担任多种技术与市场职位。

谢鹏
甲骨文公司大中华区企业应用咨询总经理
谢鹏先生现任甲骨文大中华区应用产品解决方案咨询总经理，负责大中华区应用产品解决方案的销售支持和业务咨询，包括ERP、SCM、CRM、HCM 和Application Cloud等应用产品和方案。其主要职责是领导顾问团队在理解和洞察客户需求的基础上为客户提供引领创新及业务驱动的信息化解决方案，并帮助其导入业务运营之中。同时他还专注不断地向市场和企业传递沟通新的管理理念和方法，以及甲骨文新的产品方向和策略，致力于建立企业基于IT的核心竞争力并使总体拥有成本最低。

谢鹏先生是甲骨文公司首席应用架构师，擅长信息技术和业务变革的融合创新。在不同类型的大中小企业都有成功咨询和项目导入的经验，包括国企、民企和跨国企业等。谢鹏先生在企业应用领域有超过20年的工作经验，曾担任凯捷咨询副总裁等高层管理角色。

何伟信
甲骨文公司中国区管理软件--中型企业市场总经理
何伟信现任甲骨文公司中国区管理软件--中型企业市场总经理，负责中国区高增长城市的应用软件业务,包括ERP, HCM, CRM, 专有软件, 商业分析软件以及SaaS云解决方案等的推广和销售, 为不同行业的客户提供完整的端到端的业务解决方案。

在担任此职之前，何伟信曾先后担任甲骨文香港区董事总经理和甲骨文公司华南区董事总经理，负责领导该地区的整体业务，以及掌管策略和管理运营。何伟信在甲骨文香港及大中华区拥有超过20年的丰富管理经验。

加盟甲骨文前，何伟信在IT及互联网公司担任多项要职，汲取了宝贵的销售和合作伙伴管理经验，并取得了卓越的业务佳绩。他曾出任雅虎香港搜索营销总监，并在此前担任BEA系统香港有限公司区域总经理，成功赢得金融服务行业、通讯行业及政府重大项目中的多项中间件解决方案业务。何伟信于1998年至2005年期间在Sun先后担任多个要职。

Digest Net

阿里云李飞飞：云数据库战争下半场的数据库格局

透露两条信息：

部分精彩观点摘录：

NewSQL系统综述-NewSQL到底New在哪里

尚若水之品，怀君子之德 - 北京东城区分司厅小学

2019 Oracle的战略变化 和 Don Johson 的裁员邮件

2019年Oracle 大举裁减工程师团队，或涉及上万人

2016年中国数据库市场销售规模超过100亿元

Oracle跟踪和诊断的利器: ORADEBUG 手册

Percona最新发布XtraBackup for MySQL 8.0

对话李飞飞：在谷歌听得见炮火 回斯坦福看下个方向

文：本刊记者 谢丽容 刘以秦 引自:https://news.cnblogs.com/n/606943/

数据库流行度排行榜

解析 vcard规范 二维码名片的格式

3.1 vcard格式简介

3.2 vcard标准通信薄基本格式

3.2.1 VCard 数据格式的标识符 - VCARD

3.2.2 vCard数据格式行: 类型 [;参数]:值

3.2.3 预定义类型的用法

3.2.3.1 BEGIN 和 END 类型

3.2.3.2 标识类型

3.2.3.3 联系方式

3.2.3.4 地理类型

3.2.3.5 组织类型

3.2.3.6 解释类型

3.2.3.7 Security 类型

3.2.3.8 扩展类型

Jonathan Lewis：我很为DBA们的未来担心（图灵访谈）

吕海波（Vage）- 突然35岁：捡点我的职业生涯

吕海波（Vage）- 漂泊的技术人生 - ITPUB访谈录

Oracle群英录 - 2013上海OOW名人录

2019 Oracle的战略变化和 Don Johson 的裁员邮件

对话李飞飞：在谷歌听得见炮火回斯坦福看下个方向

文：本刊记者谢丽容刘以秦引自:https://news.cnblogs.com/n/606943/

解析 vcard规范二维码名片的格式

3.2.3 预定义类型的用法　　