Hello DBA

周末随老婆公司自驾游，东极岛，顾名思义，是中国有人居住的最东端的岛屿，从舟山沈家门出海，大约40多公里，坐船大约需要三个小时。

当天风浪很大，我晕船，吐得一塌糊涂，在岛上住在渔民家里，顿顿都是海鲜，不是鱼就是贝壳。岛上蚊子巨多，我们戏称是来献血的。岛上没什么象样的海滩，找了个能游泳的地方，水还算清澈，就是有些冷。回去的路上，继续吐了一路，下船后只想吃顿KFC，比海鲜好吃多了，我想我还是比较适应在陆地上生活。

只带了一个30mm的定焦头，也没怎么拍，凑合着看吧。

–EOF–

本文发表在《程序员》杂志2010年第6期

引 言
数据库的可用性和扩展性一直是数据库厂商和用户最关注的问题。过去我们采用高端的设备，比如使用小型机和大型存储来保证数据库的可用 性。而扩展性主要采用向上扩展(Scale up)的方式，通过增加CPU，内存，磁盘等方式提高处理能力。这种集中式数据库的架构，使得数据库成为了整个系统的瓶颈，已经越来越不适应海量数据对计 算能力的巨大需求。近些年来，分布式系统成为了一种趋势，我们希望用廉价的设备堆叠出具备高可用性和高扩展性的计算集群，从而摆脱对大型设备的依赖。数据 库作为系统架构中的重要组成部分，如何做到即提供高可用性，又具备向外扩展(Scale out)的能力，数据库厂商和用户都做了很多的探索。

Oracle RAC
几乎每个数据库产品都有集群解决方案，Oracle RAC是业界最流行的产品。其架构的最大特点是共享存储架构（Shared-disk），整个RAC集群是建立在一个共享的存储设备之上的，节点之间采用 高速网络互连。Oracle RAC提供了非常好的高可用特性，比如负载均衡和应用透明切换(TAF)，其最大优势在于对应用完全透明，应用无需修改便可以切换到RAC集群。但 是，RAC的扩展能力有限，首先因为整个集群都依赖于底层的共享存储，所以共享存储的IO能力和可用性决定了整个集群的可以提供的能力，其依然无法摆脱对 大型存储设备的依赖。Oracle显然也意识到了这个问题，在Oracle的MAA(Maximum Availability Architecture)架构中，采用ASM来整合多个存储设备的能力，使得RAC底层的共享存储也具备线性扩展的能力，整个集群不再依赖于大型存储的 处理能力和可用性。

RAC的另外一个问题是，随着节点数的不断增加，节点间通信的成本也会随之增加，当到达某个限度时，增加节点可能不会 再带来性能上的提高，甚至可能造成性能下降。这个问题的主要原因是Oracle RAC对应用透明，应用可以连接集群中的任意节点进行处理，当不同节点上的应用争用资源时，RAC节点间的通信开销会严重影响集群的处理能力。所以使用 Oracle RAC有两个建议：1.节点间通信使用高速互联网络；2.尽可能将不同的应用分布在不同的节点上。基于这个原因，Oracle RAC通常在DSS环境中可以做到很好的扩展性，因为DSS环境很容易将不同的任务分布在不同的计算节点上，而对于OLTP应用，Oracle RAC更多情况下是用来提高可用性，而不是为了提高扩展性。

MySQL Cluster
MySQL cluster和Oracle RAC完全不同，它采用Shared-nothing架构。整个集群由管理节点(ndb_mgmd)，处理节点(mysqld)和存储节点(ndbd)组 成，不存在一个共享的存储设备。MySQL cluster主要利用了NDB存储引擎来实现，NDB存储引擎是一个内存式存储引擎，要求数据必须全部加载到内存之中。数据被自动分布在集群中的不同存 储节点上，每个存储节点只保存完整数据的一个分片(fragment)。同时，用户可以设置同一份数据保存在多个不同的存储节点上，以保证单点故障不会造 成数据丢失。

MySQL cluster的优点在于其是一个分布式的数据库集群，处理节点和存储节点都可以线性增加，整个集群没有单点故障，可用性和扩展性都可以做到很高，更适合 OLTP应用。但是它的问题在于：1.NDB存储引擎必须要求数据全部加载到内存之中，限制比较大，但是目前NDB新版本对此做了改进，允许只在内存中加 载索引数据，数据可以保存在磁盘上。2.目前的MySQL cluster的性能还不理想，因为数据是按照主键hash分布到不同的存储节点上，如果应用不是通过主键去获取数据的话，必须在所有的存储节点上扫描， 返回结果到处理节点上去处理。而且，写操作需要同时写多份数据到不同的存储节点上，对节点间的网络要求很高。

虽然MySQL cluster目前性能还不理想，但是share nothing的架构一定是未来的趋势，Oracle接手MySQL之后，也在大力发展MySQL cluster，我对MySQL cluster的前景抱有很大的期待。

分布式数据库架构
目前，除了数据库厂商的 集群产品以外，解决数据库扩展能力的方法主要有两个：数据分片和读写分离。数据分片(Sharding)的原理就是将数据做水平切分，类似于hash分区 的原理，通过应用架构解决访问路由和数据合并的问题。Sharding架构的优势在于，集群扩展能力很强，几乎可以做到线性扩展，而且整个集群的可用性也 很高，部分节点故障，不会影响其他节点提供服务。Sharding原理简单，容易实现，是一种非常好的解决数据库扩展性的方案。但是Sharding对应 用场景的要求很高，因为一旦使用数据分片架构，如果需要跨不同的节点做join，或者统计类型的操作，将会变得非常困难，应该尽量避免。所以说 Sharding架构会损失部分关系型数据库的特性，比如join，从而使数据库退化为Key-Value store类型的存储。所以，并不是所有的应用都适合做Sharding，它可能会造成应用架构复杂或者限制系统的功能，这也是它的缺陷所在。

Sharding架构图

读写分离架构利用了数据库的复制技术，将读和 写分布在不同的处理节点上，从而达到提高可用性和扩展性的目的。最通常的做法是利用MySQL Replication技术，Master DB承担写操作，将数据变化复制到多台Slave DB上，并承担读的操作。这种架构适合read-intensive类型的应用，通过增加Slave DB的数量，读的性能可以线性增长。为了避免Master DB的单点故障，集群一般都会采用两台Master DB做双机热备，所以整个集群的读和写的可用性都非常高。除了MySQL，Oracle从11g开始提供Active Standby的功能，也具备了实现读写分离架构的基础。读写分离架构的缺陷在于，不管是Master还是Slave，每个节点都必须保存完整的数据，如 果在数据量很大的情况下，集群的扩展能力还是受限于单个节点的存储能力，而且对于Write-intensive类型的应用，读写分离架构并不适合。

读写分离架构图

读写分离架构应用非常广泛，很多网站都采用cache+DB的读写分离架构，通 过cache层来承载大量的读访问。Memcached是一种广泛使用的Key-Value cache，它不具备持久化存储的功能，所以它通常和数据库一起组成读写分离的架构，由数据库承载数据持久化存储的功能，而Memcached则用来承载 大量的并发访问。通常的做法是：应用的读请求会首先访问Memcached，如果命中则返回，如果没有命中，则会去数据库中读取，并将数据加载到 Memcached中。关于新增，修改和删除操作，一般采用lazy load的策略，即新增时只写入数据库，并不会马上更新Memcached，而是等到再次读取时才会加载到Memcached中，修改和删除操作也是更新 数据库，然后将Memcached中的数据标记为失效，等待下次读取时再加载。Memcached支持数据分区，利用hash算法将数据分布到不同的服务 器，组成一个分布式的cache集群。

MySQL+Memcached读写分离架构

数据库与CAP理论
根据 CAP理论，一致性(C)，可用性(A)，分区容错性(P)，三者不可兼得，必须有所取舍。而传统数据库保证了强一致性(ACID模型)和高可用性，所以 要想实现一个分布式数据库集群非常困难，这也解释了为什么数据库的扩展能力十分有限。而近年来不断发展壮大的NoSQL运动，就是通过牺牲强一致性，采用 BASE模型，用最终一致性的思想来设计分布式系统，从而使得系统可以达到很高的可用性和扩展性。

但是，对于CAP理论也有一些不同的声 音，数据库大师Michael Stonebraker就撰文《Errors in Database Systems, Eventual Consistency, and the CAP Theorem》，表示为了P而牺牲C是不可取的。事实上，数据库系统最大的优势就对一致性的保证，如果我们放弃了一致性，也许NoSQL比数据库更有优 势。那么，有没有可能实现一套分布式数据库集群，即保证可用性和一致性，又可以提供很好的扩展能力呢？

目前，已经有很多分布式数据库的产 品，但是绝大部分是面向DSS类型的应用，因为相比较OLTP应用，DSS应用更容易做到分布式扩展，比如基于PostgreSQL发展的 Greenplum，就很好的解决了可用性和扩展性的问题，并且提供了很强大的并行计算能力。对于OLTP应用，业务特点决定其要求：高可用性，一致性， 响应时间短，支持事务和join等等。Michael Stonebraker提到了一种新的数据库产品VoltDB，它的定义是Next-Generation SQL Database for Fast-Scaling OLTP Applications。虽然产品还没有问世，但是从技术资料上来看，它有几个特点：
1.采用Share nothing架构，将物理服务器划分为以CPU core为单位的Virtual node，采用Sharding技术，将数据自动分布到不同的Virtual node，最大限度的利用机器的计算资源；
2.采用内存数据访问技 术，类似于内存数据库(In-memory database)，区别于传统的数据库(Disk-based database)，消除了传统数据库内存管理的开销，而且响应速度非常快；
3.每个Virtual node上的操作是自治的，利用队列技术将并发访问变为串行访问，消除了传统数据库串行控制的开销(比如Latch和Lock)；
4.数据同步写 多个副本，不存在单点故障，而且消除了传统数据库需要记录redo log的开销。

VoltDB不仅支持传统数据库的ACID模型和 SQL接口，而且提供类似NoSQL产品的高可用性和很强的扩展能力，可谓鱼肉熊掌兼得。CAP理论并不是神话，相信未来类似的数据库产品会不断涌现。

数 据库和NoSQL
当越来越多的NoSQL产品涌现出来，它们具备很多关系型数据库所不具备的特性，在可用性和扩展性方面都可以做到很好。 那么，未来传统的关系型数据库还有优势吗？NoSQL会取代数据库吗？我个人认为关系型数据库至少在相当长的一段时间内，依然是主流，而且还有很大的发展 空间。

第一，NoSQL的应用场景非常局限，某个类型的NoSQL仅仅针对特定类型的应用场景而设计。而关系型数据库则要通用的多，使用 NoSQL必须搞清楚自己的应用场景是否适合，所以说NoSQL对于很多人来说是“汝之蜜糖，彼之砒霜”。
第二，利用关系型数据库配合应用架构， 比如Sharding和读写分离技术，同样可以搭建出具备高可用和扩展性的分布式数据库集群。
第三，关系型数据库厂商依然很强大，全世界有大量的 用户，需求必然会推动新的产品问世。
第四，硬件的发展日新月异，比如闪存的技术的不断成熟，未来闪存可以作为磁盘与内存之间的cache，或者完 全替代磁盘。而内存价格越来越低，容量越来越大，In-memory cache或database的应用越来越广泛，可以给应用带来数量级的性能提升。数据库面临的IO问题将被极大改善，数据库也将随着这些新技术而焕发第 二春。

我并不担心关系型数据库的未来，但我们也不能忽视NoSQL的巨大力量。未来，各种产品和技术一定是百花齐放，关系型数据库依然有 很强的生命力，各种NoSQL产品也会层出不穷，所以完全不用担心谁将会替代谁，我们要做的就是找到最佳的解决方案。有人将NoSQL解释成为Not only SQL，我想也是这个原因吧。

结论
前面探讨了关于数据库可用性和扩展性方面的问题，我们看到每种产品和 架构都是有缺陷的，其实架构就是有所取舍的过程，目标是用最小的代价去解决问题。所以找到适合自己的产品和架构，这才是最重要的。

Library cache是Shared pool的一部分，它几乎是Oracle内存结构中最复杂的一部分，主要存放shared curosr（SQL）和PLSQL对象（function，procedure，trigger）的信息，以及这些对象所依赖的table，index，view等对象的信息。

Library cache需要解决三个问题：

1.快速定位的问题：Library cache中对象众多，Oracle如何管理这些对象，以便服务进程可以迅速找到他们需要的信息。比如某个服务进程需要迅速定位某个SQL是否存在于Library cache中。

2.关系依赖的问题：Library cache中的对象存在复杂的依赖关系，当某个objec失效时，可以迅速将依赖其的对象也置为失效状态。比如某个表发生了结构变化，依赖其的SQL语句需要重新解析。

3.并发控制的问题：Library cache中必须有一个并发控制的机构，比如锁机制，来管理大量共享对象的并发访问和修改的问题，比如某个SQL在重新编译的同时，其所依赖的对象不能被修改。

Library cache结构：

Oracle利用hash table结构来解决library cache中快速定位的问题，hash table就是很多hash bucket组成的数组：

原理与buffer cache中定位block的方式相同，将对象信息（比如SQL）hash定位到某个hash bucket中，然后顺序扫描bucket中的 List，实现快速定位对象的目的。

Library cache handle是对象的一个指针，其中的namespace属性表示其指向的对象的类型：比如CRSR(Cursor)，TABL(Table)，INDX(Index) ，PROD(Procedure)，TRIG(Trigger)等等。

LCO(Library cache object)是handel指向的对象，包含了以下几个部分的内容：

1.dependency table：

指向本对象所依赖的对象，比如：select * from emp这个cursor的对象，依赖emp这个表，这里指向了emp这个表的handle。

2.child table：

指向本对象的子对象，比如某个游标的子游标。子游标是指SQL文本相同，但是SQL的实际含义不同的情况，比如执行的用户不同，执行计划不同，执行的环境不同等等，我们一般称之为SQL的不同版本。一个SQL至少包含一个父游标和一个子游标。

3.authorization table：

对象的授权信息。

4.type

Library cache object的type，包括：shared cursor,index,table,cluster,view,synonym,sequence,procedure,function,package,table body,package body,trigger等等。

5.data blocks

data block是一个指针，指向了data heap，即存放真实数据的地方，主要包括：diana tree, p-code, source code, shared cursor context area等等，如下图：

Library cache对象依赖关系：

对象依赖关系是利用LCO中的dependency table来完成的，我们设想以下的情况，用来说明对象间的依赖关系：

两个共享游标：

SQL1: select * from emp;

SQL2: select * from emp和select a.name from emp a,dept b where a.dept_id=b.id and b.name=:1;

SQL1产生了两个子游标，也就是SQL文本相同的两个不同版本，他们同时依赖emp表。SQL2只有一个版本，因为每个游标最少有一个子游标，所以它只有一个子游标，并且同时依赖dept表和emp表。

Library cache中的并发控制：

Oracle利用Library cache lock和Library cache pin来实现并发控制，Library cache lock是在handle上获取的，而Library cache pin则是在data heap上获取。访问对象时，首先必须获取handle上的lock，然后将访问的数据pin在内存中。lock的作用是控制进程间的并发访问，而pin的作用是保证数据一致性，防止数据在访问时被交换出去。

Library cache lock有三种模式：null，share，exclusive，Library cache pin有两种模式：share，exclusive。下面详细解释在修改和访问对象时，lock和pin的作用：

修改对象：

编译SQL或PLSQL对象，获取该对象（cursor，procedure）handle上exclusive类型的lock，并且持有data heap上exclusive类型的pin，防止其他人读取和修改。同时，在该对象所依赖的对象（table）上，必须持有一个share类型的lock和pin，防止在修改的过程中，被其他进程所修改。

访问对象：

访问SQL或PLSQL对象，获取该对象（cursor，procedure）handle上NULL类型的lock，并且持有data heap上share类型的pin，同时，在其依赖的对象（table）上持有share类型的lock和pin。如果一个procedure依赖另外一个function，那么在被依赖的function上，也需要持有share类型的lock和pin。

NULL类型的lock比较特殊，它只存在于cursor和procedure等只读对象上，它并不起到任何并发控制的作用，它更象是一个trigger，当对象失效时，通知所有访问这个cursor的进程。比如：select * from emp这个SQL，依赖emp表，当emp表发生变化时，cursor上的NULL lock被打破，所有有访问这个cursor的进程都会知道该对象已经失效。

当持有对象的library cache pin时，会在row cache中对相应的对象加锁，就是row cache lock，阻止可能导致数据字典信息混乱的DDL发生。

lock和pin的实现类似于enqueue，在每个handle上都有lock和pin的holder list和waiter list，用来保存持有该资源和等待该资源的队列。

阻塞分析：

现实情况中，我们有一个数据库中存在被应用大量频繁访问的procedure，当依赖的表发生变更时，导致该procedure失效，这时会出现大量的library cache lock和library cache pin的等待，堵塞应用访问，造成了重大故障。出现这个问题的原因是：当procedure失效后，所有访问该对象的进程都尝试去编译，大量进程尝试获取exclusive类型的lock和pin，出现了大量的等待。后续的Oracle版本作出了改进，当出现这种情况时，只允许第一个进程尝试去编译该对象，编译通过后，所有的进程就可以并发访问，避免了大量进程同时尝试编译的情况出现。

Library cache中的Latch：

Library cache中相关的latch包括：shared pool latch，library cahce latch，library cache lock latch，library cache pin latch。

Share pool latch的主要作用是分配或释放空间时使用，从Oracle9i开始，sharedpool被分成了很多个subpool，由多个shared pool latch保护，Oracle开始支持更大的shared pool。

Library cache latch的主要作用是在hash bucket中定位handle时使用，library cache lock latch和library cache pin latch分别是获取lock和pin时，需要取得的latch。

shared pool大小不合理，大量的硬解析以及SQL版本过多都可能导致shared pool latch和library cache latch的争用。

从Oracle10g开始，Oracle正在逐步用mutex取代library cache中的latch，cursor：pin S和cursor：pin X相当于share和exclusive类型的library cache pin，cursor：pin S wait on X则表示share方式正在等待exclusive锁定。

–EOF–

我们都知道Latch是Oracle用来在内存中做串行控制的机构，从10g R2开始，Oracle引入了一个新的技术-Mutex。Mutex并不是Oracle的发明，而是系统提供的一个底层调用，Oracle只是利用它实现串行控制的功能，并替换部分Latch。

Mutex中有两个变量：分别是Holider identifer和Reference count，Holider identifer记录持有mutex的SID，而Reference count是一个计数，记录了当前正在以share方式访问mutex的数量，每当session以share方式持有mutex时，计数会加1，而释放时会减1。如果Reference count大于零，则表示该内存结构正在被Oracle pin住。

我们看一段伪代码，演示mutex的申请过程：

Function Mutex_get(mutex_name)
{
  if mutex.holder:=SID
    case mode:
    'exclusive':
      if mutex.ref_count=0
        return TRUE
      else
        mutex.holder.clear;
        reture FALSE
      end if
    'share':
      mutex.ref_count++
      mutex.holder.clear
      return TRUE
    end case
  else
    reture FALSE
  end if
}

Mutex是如何实现串行控制的，实际上它是利用了操作系统的一个原子操作CAS(compare-and-swap)实现的。我们看到函数的开始处：mutex.holder:=SID，将SID赋值给mutex的Holider Identifer，这里就是一个原子的CAS操作，首先比较mutex.holder是否为空，如果不为空则赋值session的SID。CAS操作由OS来保证其原子性，在同一时刻这个操所是串行的。如果这个赋值操作失败，整个申请过程失败。赋值成功后，如果是share方式，则mutex.ref_count加1，并清空mutex.holder，如果是exclusive方式，需要判断mutex.ref_count是否为零（是否被pin住），如果大于0，则失败，并清空mutex.holder，如果等于0，则成功，这时不清空mutex.holder，保持当前session对mutex的exclusive占用，直到释放为止。

Mutex相比latch带来了以下的好处：

1.更少的资源消耗，mutex与latch不同，它不是独立存在的，而是在每个内存结构中，并随着内存结构创建和释放，mutex同时也被创建和释放。mutex暂用的空间比latch小很多，创建和释放消耗更少的资源。

2.有效降低竞争，因为mutex是每个内存结构中的一部分，这样意味着mutex的数量可以有很多，而不同于latch，一个latch需要管理很多个内存结构，当你访问同一latch管理的不同内存结构时，也会发生竞争，而mutex则不会。另外，因为latch的数量有限，很多时候latch本身的竞争会很厉害，之前，我们只能增加latch数量或者减少latch持有的时间，而现在，mutex是一个更好的选择。

3.更快的pin，当block被访问时，它必须被pin在buffer cache中，当一个cursor执行时，它也必须被pin在library cache中，如果大量并发频繁执行同一个cursor，library cache pin会耗费大量的CPU资源。而mutex使用reference count来解决并发访问的问题，只要它大于零，就表示它已经被pin在了内存中，不能被交换出去。而且mutex.ref_count++这个操所是非常快的，只占用非常少的资源。

Mutex申请的过程和latch类似，同样需要spin和sleep，不同的是Oracle硬编码了mutex spin的次数为255次（Latch spin的次数默认为2000，由隐含参数_spin_count控制）。latch sleep会随着等待次数的逐步增加，每次sleep的时间也会逐步增加。而mutex sleep则比较特别，它有三个选项，分别是yield CPU，sleep或者block other process，允许开发人员来决定采用哪种选项。

由于在某些RISC的操作系统中（HP-UNIX），由于系统不支持CAS操作，Oracle通过创建一个latch pool来模拟了CAS操作，被称为KGX latch，如果你发现系统中存在这种latch竞争，说明操作系统不支持CAS操作，可以通过_kks_use_mutex_pin关闭mutex。

mutex主要使用在library cache中，用来取代原来的library cache pin和library cache lock，关于library cache中锁的实现机制，我会在另外一篇文章中说明。

–EOF–

注：有关CAS，可以参考wiki上的说明。

最近一直在思考一个问题：如何为一个数据库建立性能模型？作为一名DBA来说，我们面临的一个巨大挑战是：如何保证数据库的性能可以满足快速变化的应用的需求，如何在数据量和访问量持续增长的情况下，保证应用的响应时间和数据库的负载处在合理的水平下。我们可能会经常面对以下的问题：某个SQL每秒要执行100次，响应时间是多少？某个应用发布后，对数据库的影响如何？所以，评估应用对数据库所产生的影响，优化应用并预测风险，保证数据库的可用性和稳定性，这是应用DBA真正有价值的地方。

响应时间为中心：

如果要选择一个评价系统优劣的性能指标，毫无疑问应该是响应时间。响应时间是客户体验的第一要素，所有的优化都应该为降低响应时间而努力。对于数据库系统也是如此，我们优化系统，优化SQL，最终目标都是为了降低响应时间，单位时间内可以处理更多的请求。

数据库时间模型：

响应时间一般分为服务时间(Service time)和等待时间(Wait time)，服务时间指进程占用CPU的时间，包括前台进程(Server process)和后台进程(Backgroud process)，我们一般只关注前台进程占用的CPU time。等待时间包括很多类型，一般最常见的是IO等待和并发等待，IO等待包括sequential read，scattered read和log file sync等等，而并发等待主要是latch和enqueue。SQL execute elapsed time指用户进程执行SQL的响应时间，包含CPU time和wait time。

以下是Oracle数据库的时间模型：

在Oracle系统中，我们可以利用AWR或Statspack报告，看到数据库的时间信息：

DB time是整个数据库用户进程消耗的总时间，是从第一项到第十项时间的总和（从sql execute elapsed time到PL/SQL compilation elapsed time），但是我们会发现这十项时间的总和比DB Time要大一些，这是因为部分时间信息有重叠的部分，比如SQL execute elapsed time就包括了很大一部分DB cpu的时间。而background elapsed time和background cpu time则是Oracle后台进程消耗的时间和cpu time。

数据库响应时间分析：

数据库系统的响应时间由四个要素决定：CPU，IO，内存和网络，其中CPU和IO是最重要的因素。与之相比，内存与网络则简单很多，因为通常情况下，对于一个调优的系统来说，内存访问的延迟时间非常小（100 ns以下，1 ms=1000000 ns）相比较CPU和IO几乎可以忽略。而网络延迟则通常是一个常数，比如在一个数据中心的情况下，网络的延迟一般在3ms以下，如果存在多数据中心的情况，网络延迟可能会超过20ms，所以对于一个分布式系统来说，网络延迟是必须要考虑的问题。

在这里，我们不考虑分布式系统，并且忽略内存的访问延迟，重点分析CPU和IO，我们看以下数据库的AWR片段：

我们看到这个系统中DB CPU占整个DB time的87.21%，User I/O占整个DB time的9.12%，commit相关的IO等待占2.35%（主要是log file sync），CPU和IO占用了整个DB time的96.68%。由于DB CPU所占的比例很高，所以这个数据库系统是CPU intensive类型，这里的DB CPU主要是执行SQL的服务时间。

我们再看另外的一个数据库的AWR片段：

我们看到，Commit和User I/O占DB time的81.46%，而DB CPU只占13.82%，所以这个数据库系统是IO instensive类型的。

Physical read

Physical read是指Oracle在buffer cache中没有找到相应的block，需要从IO子系统读取相应的block的过程，对应的IO称为物理IO，物理读数量代表物理IO读取的block数量。因为一般IO子系统都是慢速的磁盘，所以物理IO对整体响应时间的影响非常大，如果发生大量的物理IO，整个系统的响应时间会变得很差。系统的IO子系统可能是文件系统，裸设备或者ASM，底层硬件可能是SAN存储，NAS存储或者普通SAS磁盘等等。为了提高响应时间，通常在物理磁盘与Oracle之间增加cache层，对于Oracle来说，物理IO并不一定是真正访问磁盘，很可能是访问文件系统cache，存储的cache等等。

不管IO subsystem是什么，Oracle只关心物理IO的响应时间。通过AWR报告，我们可以看到物理IO的响应时间：

db file sequential read（单块读，随机IO）的平均响应时间为3ms，db file scattered read（多块读，连续IO）的平均响应时间是4ms，logfile file sync的平均响应时间是3ms，前两者的Wait class是User I/O，代表用户进程读操作的响应时间，logfile sync的wait class是Commit，代表lgwr进程写redo的响应时间，因为用户commit必须完成log file sync的操作，所以它也会直接影响用户进程写操作的响应时间。

关于物理IO的响应时间，我们有一个经验值。对于Sequential read和Scattered read，我们认为小于10ms属于正常状态，而大于10ms则认为IO subsystem的响应延迟过大。所以我们在衡量存储系统的性能时，只有响应时间在10ms以下的IO我们认为是有效的。这里有一个有趣的现象，就是sequential read和scattered read的响应时间几乎相差无几，也就是说随机IO读取8K数据和连续IO读取128K数据，响应时间差别很小，这是由磁盘的机械特性造成的，延迟时间=寻道时间+

对于log file sync的响应时间，因为用户commit必须完成log file sync，所以整个系统的写操作的响应时间都取决于它的响应时间，而且从整个数据库系统的角度去看，log file sync几乎是串行的，所以这个响应时间对写操作影响非常大，我们的经验值是必须保证在5ms以下，如果超过5ms整个系统的写操作都会受到严重的影响。

Logical read

Logical read是Oracle从buffer cache中读取block的过程，对应的IO称为逻辑IO，逻辑读数量代表逻辑IO读取的block数量。因为Oracle必须首先将block读入buffer cache中(direct path read除外)，所以逻辑读数量包含了物理读数量。对于一个SQL来说，逻辑读数量是衡量其性能的标准，而不是物理读。虽然物理IO的响应延迟比逻辑IO大很多，但是物理读数量会随着执行次数而变化（频繁读取导致block被缓存在buffer cache中）。对于一个系统也是如此，逻辑读应该是数据库性能评估模型的核心，我们需要建立逻辑读与响应时间的对应关系。

每个逻辑读的响应时间是多少，这是一个巨大的挑战。因为每个逻辑读背后隐藏了很多动作，可能包括物理读，等待事件，CPU time等等。我对很多数据库的AWR报告做了分析，期望根据经验值建立一个简化的模型。我们假设一个数据库如果是充分调优的，除CPU time和IO以外的等待时间应该尽可能少（应小于DB time 10%）。在这个前提下，我们只关心CPU time和IO的影响，并将系统分为三类：CPU密集型，IO密集型和混合型：

1.IO密集型

User IO     85%
DB CPU        5%
每逻辑读响应时间0.1-0.5ms

2.CPU密集型

DB CPU         85%
User IO        10%
每逻辑读响应时间小于0.01ms

3.混合型

User I/O     60%
DB CPU         20%
每逻辑读响应时间0.05-0.1ms

以上数据是根据很多个典型数据库的AWR报告计算出来的经验值，计算公式很简单：DB time/逻辑读=每逻辑读响应时间。因为并没有考虑硬件和OS上的差异，所以这个数值并不是特别准确，但我们还是可以发现一些规律：随着IO所占比例从10%增加到85%，响应时间也从小于0.01ms到0.5ms。

预测系统瓶颈

对于数据库来说，IO子系统对性能影响非常大，必须保证在一定的IO的压力下，响应延迟控制在合理的范围内（前面说的10ms和5ms）。因为每块磁盘可以承受的IOPS是基本确定的，比如15K的SAS磁盘，在响应延迟不超过10ms的前提下，可以提供150个IOPS，如果不考虑cache的影响，整个存储子系统的IOPS是比较容易计算的。我们可以在系统上线前，进行大量充分的测试，建立存储IOPS与响应延迟的模型，这样我们就可以预测出性能出现拐点的风险，提前做出扩容的判断。在AWR报告中，我们可以得到每秒的物理IO的数量和响应时间，可以方便的实现性能监控和趋势预警。

评估CPU的容量瓶颈相对简单，Oracle中CPU time的计算是每个CPU耗费时间的总和，如果有16颗(核)CPU，1个小时理论上可以提供3600×16=57600s CPU time，不超过57600s CPU time我们可以认为不会在CPU上排队，系统不会出现CPU瓶颈。但是需要注意的是，除了用户进程使用CPU以外，操作系统也需要占用CPU资源，用来管理内存和进程调度等。我们在OS上看到的CPU使用率中的sys部分就是系统占用的CPU资源，所以应该考虑至少保留10-20%的CPU资源给OS使用。

并发访问对数据库的影响

Oracle是一个Disk-based database，设计的出发点就是大部分数据在外部存储中，而只有小部分数据被cache在buffer中，它既不同于Memcache这类KV cache，也不同于timesten这类In-memory database。所以，就算是所有的数据都可以被cache在buffer中，在高并发访问的情况下，也可能会出现大量的latch等待，最常见的情况就是cache buffer chain。当大量并发访问同一块数据时，就很可能会出现cache buffer chain的latch争用，也就是我们常说的“热点”。

需要注意的是：Oracle中的latch等待分为spin和sleep两个部分，spin消耗cpu time，而sleep则是等待时间。所以大量的latch等待不仅仅会产生大量的等待时间，而且会消耗大量的CPU time。

Oracle是一个为并发操作而设计的数据库，大量的并发读写请求，可能会带来额外的性能消耗。比如读取一部分频繁修改的数据，Oracle为了保证一致性读的需要，会利用undo信息构造产生大量CR block，同时会产生大量的逻辑读，这样会消耗额外的CPU和响应时间。

存储也可能存在热点的问题，需要前期对存储系统充分的优化，常见的手段是利用RAID技术，将数据分散在不同的磁盘上，防止出现“热点”盘。Oracle ASM提供了Rebalance的功能，允许DBA将存储中的的数据重新分布，达到消除热点的目的。

总之，Oracle是一个可以提供大量并发读写访问的数据库系统，但是在很多地方，Oracle又不得采用一些串行的控制手段，比如latch，enqueue和mutex，我们要做的就是尽量降低这些串行控制对数据库整体性能的影响。

数据库优化原则

基于响应时间的Oracle优化原则：尽量减少等待时间（Wait time），提高服务时间（Service time）。这也是基于Oracle等待事件的分析方法的基本原则：尽量消除各种等待事件对系统的影响，从而提高系统性能和响应时间。

如果数据库系统除了CPU和IO以外的等待时间超过DB time的5%以上的话，可能存在某些性能问题，需要DBA采用等待事件的分析方法，对系统或应用进行优化。

–EOF–

后记：为什么要写这么一个主题，因为最近和一位同事探讨机器自动审核SQL的问题，就想建立一个简单的模型，用来开发一个SQL审核工具，开发人员通过工具和预先建立好的模型，就可以确定这个SQL是否存在性能风险。之前我们在做SQL优化的时候，只是关注这个SQL本身是否优化，逻辑读是多少。但是，很少有人把逻辑读和响应时间之间的关系建立起来，我试图想回答这个问题。

关于容量规划和风险预测其实是一个很有意义的命题，但是我们很多时候都局限在一些具体的技术细节中，而忽略了对整个系统容量的把握，事实上，这也是非常难的一件事。也许到目前为止，我根本没有达到建立“模型”的程度，但是我试图将这些方方面面的因素联系起来，提供一些有用的经验值给大家，我觉得这个挺有意义。

在这篇文章中，我提到了几个有意义的经验值，这是我根据很多数据库AWR中的信息计算出来的，虽然不保证完全准确，但是我觉得基本是靠谱的。建议每个DBA都应该从AWR中找到这些信息，并判断自己的数据库属于哪种类型，瓶颈在哪里，是否存在性能风险。当面对诸如“硬件是否能够满足性能需求”，“系统明年是否需要扩容”，“应用是否会对系统产生影响”此类问题时，我们可以用这些经验值给出一个判断。

关于这个命题，目前只是一个阶段性的结果，我还会继续思考。如果大家有兴趣，欢迎和我一起探讨这个话题。

建立数据库性能模型，这是我最近一直在思考的一个问题。这个命题还是非常有意义的，因为我们在很多情况下都需要对数据库做性能评估，容量规划和风险预测。很多DBA的优化经验都局限在一个很小的数据库技术领域内，而对整个系统的性能容量并不十分了解。我希望能够给大家一些简单的模型和经验数据，帮助大家对系统的整体性能有一个更深层次的了解。

这篇PPT可能还达不到模型的理论高度，甚至很多数据还不是十分准确，只是我个人思考的一个结果，希望能抛砖引玉，大家一起思考和进步。

之前，我对Sequential和Scattered的理解是Oracle读取IO的顺序不同，今天又讨论起这个问题，另外一种解释是两者在内存中的保存方式有差异，Sequential read在内存中是连续的，而Scattered read是离散的。以下解释来自于Oracle文档：

Scattered read：

This event signifies that the user process is reading buffers into the SGA buffer cache and is waiting for a physical I/O call to return. A db file scattered read issues a scatter-read to read the data into multiple discontinuous memory locations. A scattered read is usually a multiblock read. It can occur for a fast full scan (of an index) in addition to a full table scan.

Sequential read：

This event signifies that the user process is reading buffers into the SGA buffer cache and is waiting for a physical I/O call to return. This call differs from a scattered read, because a sequential read is reading data into contiguous memory space. A sequential read is usually a single-block read.

这也从另外一个方面解释了Sequential和Scattered的含义。

–EOF–

最近整理了一些关于数据库架构方面的技术专题，并整理成为PPT，准备拿出来和大家一起分享。

为什么要这么做，并不是要为了证明我自己，更不是为了其他什么目的。因为最近一直有一种强烈的执着，想要做成一些事情，在这之前，必须找到很多志同道合的人一起来努力，所以需要先布道。我并不是为了分享而分享，而是希望这些东西能够改变大家对现在一些架构的理解，真正了解我们现在面对的问题和未来的挑战。

蔡学镛说：大多數的工程師並不是「做了五年的系統開發」，而是「做了一年的系統開發，然後重複五次」。我不希望我和周围的同事们都是如此，所以我分享，帮助别人，也帮助我自己。

下面是第一个专题，《数据库高可用架构》，PPT写的很一般，关键看讲的人了。如果哪个部门有兴趣，可以联系我。

分布式系统的hash策略，决定了数据的分布。传统的方式采用mod n的算法，非常简单，但是一旦节点发生变化，所有的数据都需要重组，代价非常大。一致性哈希(Consistent hash)很好的解决了这个问题，当节点发生变化时，只会影响到部分数据，而且永远可以找到一个提供服务的节点。

对于数据库Sharding的架构，Consistent hash并不十分适合，我们采用了一种新的hash策略，我将其称之为“Virtual Partition Hash”策略。

为了解决节点数量变化时，全部数据需要重组的问题，我们采用了预分区的策略，将整个系统分为很多个Virtual Partition，每个物理节点由多个Virtual Partition组成。比如整个系统分为128个VP，共有8个物理的服务器，每个服务器包含16个VP的数据，只要整个系统的物理节点小于128个，增加节点只需要移动部分VP就可以了，避免了数据重组的问题。另外，为了提高可用性，每个物理节点都有一套备机，如果节点失效则切换至备用节点。

新增一个物理节点：

只需要移动部分VP至新节点，不需要数据重组。

Virtual partition hash策略非常简单，实现也很容易，实际上它是Consistent hash策略的一个简化版本，Oracle hash分区也是类似的做法，尽可能的减少数据重组的代价，可以参考我以前的文章《Oracle hash分区的秘密》。

这个策略的另外一个好处是非常灵活，可以根据服务器压力的情况，通过移动VP的来达到负载均衡的目的。利用MySQL数据库复制的特性，移动VP是非常容易的，而且配合我们的分布式数据库架构，可以做到对应用透明。

这个方案的缺点是：每个节点都准备一台备机，硬件资源比较浪费。但是如果可以和读写分离架构配合起来，备机可以承担部分读的服务，那么这个缺点就不存在了。

“Simple but Incomplete Solutions Win！”

—EOF—

最近一直在为招聘而苦恼，一方面很多朋友觉得找份工作非常困难，另一方面我们却苦于找不到合适的人才。就想写一篇文章说说我们到底需要什么样的人， 同时也谈谈我对职业规划的一些看法，也许对朋友们有帮助。

招聘或者找工作，偶然性是非常大的。因为人的能力是很多方面构成的，不管是通过简历，笔试还是面试，其实都只能反映出很小的一部分。对于求职者来说，找工作就是展现自己能力的过程，必须在整个过程中充分表现出自己的能力和潜力，而对于招聘者，如何在短短的面试中识别出一个人的潜在能力，更是一个巨大的挑 战，所谓千里马常有，伯乐不常有。个人觉得，找工作和相亲差不多，“能力”很重要，但是”感觉“同样重要，因为每个组织和团队都有自己的文化，现代的组织 都要求每个人能够融入到团队中，在阿里这种感觉叫做”味道“，面试的过程中有个角色是”闻味官“，闻闻味道看看我们是不是一路人。

我相信看过《非诚勿扰》的人都知道，美女的要求是很高的，一份好工作其实就如同一位美女，要想获得美女芳心，你必须有房有车（当前的能力），或者虽然现在没有，但是具备在一定时间内买房买车的能力（潜力）。除了能力以外，感觉也是很重要的，最好年轻又有上进心，找工作同样如此。 我们可以分析下美女喜欢哪类人，就知道我们需要怎么样的你：第一类是你有豪宅和宝马车（能力很强），就算丑一点老一点，脾气稍微差一点，美女还是会主动投怀送抱的，毕竟就算“坐在宝马车里哭，也比坐自行车强”。现实中，这类人通常具备某个特别强的能力，比如某个领域内的技术大师，可 以给我们团队带来巨大的价值，这类人往往不需要找工作，而是工作主动投怀送抱的，毕竟，能力还是第一位的。

第二类人是虽然暂时没有车也没房，但是具备很大提升的潜力，买车买房只是个时间问题，有理想，有上进心，当然一定要比上一类人年轻些，性格要温柔些。现实中，大多数人求职时都是这个状态，如果能力暂时不能符合我们的要求，我们会从很多方面去评估是否具备发展的潜力，最重要的手段就是通过以往的工 作经验来判断，如果是应届生也可以通过学校和社会实践的经历来判断。我们需要的人是目标明确，学习能力强，加入团队就可以迅速成长和提高，在阿里这个特性被称为“要”性，只要非常想“要”的人，才会成功。如果你能力暂时还不够，那么一定要有两样东西：巨大的潜力和很强的“要”性。

第三类人是有房有车，可能房子小点车子破点，但是足够满足日常的需要，不希望生活有什么改变，平平稳稳就好，他们找女朋友，也许只是为了满足婚姻的需要而已。对于这类人就比较纠结了，他们虽然没什么上进心，但是吃老本就可以满足工作的需要了，他们往往只是把工作看成是一种谋生的手段而已，没什么激情但是也能做好。这类人在现实生活中还是非常多的，如果仅仅是招一个人去完成某个工作，这类人还是很适合的，但是很可能时间长了，如果没有什么发展，这类人可能会被团队淘汰。我对工作的看法是，工作不仅仅是谋生的手段，通过工作我们要提高自己的能力，获得周围的人的信任，进而提高自己的社会地位。仅仅是为了工资而工作的人，注定不会有很大的成功。

另外一个话题是：如果成为大师？成为大师是很多技术人的梦想，最近也和很多年轻人聊过，他们的目标很明确，就是成为象 biti_rainy，eygle，fenng，piner，wanghai这样的大师。在我看来，要想从技术高手成为大师，不仅仅是技术上要有所突破，更重要的是要具备开放和分享的心态，持续不断的突破自我的勇气，以及领导团队不断向前的能力。其实，我的目标也是成为象他们一样的大师，追随大师，学习大师，超越大师。

李嘉诚说过，“只要勤奋，肯去求知，肯去创新，对自己节俭，对别人慷慨，对朋友讲义气，再加上自己的 努力，迟早会有所成就，生活无忧”。 祝愿大家都能找到自己的位置，为了梦想而努力吧。

—EOF—

顺便做下广告，阿里巴巴诚聘Oracle DBA和MySQL DBA，如果有梦想在数据库领域成为大师，那么加入我们吧。发邮件到freezr@gmail.com