Hello DBA

东极岛

jacky — Wed, 28 Jul 2010 21:27:19 +0800

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

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

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

–EOF–

可扩展的分布式数据库架构

jacky — Thu, 15 Jul 2010 20:05:09 +0800

本文发表在《程序员》杂志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内部机制详解

jacky — Sun, 04 Jul 2010 16:32:57 +0800

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–

shared cursor (SQL cursor or PL/SQL anonymous block), index,
table, cluster, view, synonym, sequence, procedure, function, package, table body, package body, and trigger

Oracle Mutex实现机制

jacky — Thu, 17 Jun 2010 18:48:13 +0800

我们都知道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上的说明。

Oracle数据库性能模型

jacky — Wed, 16 Jun 2010 22:50:04 +0800

最近一直在思考一个问题：如何为一个数据库建立性能模型？作为一名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报告，看到数据库的时间信息：

Statistic Name	Time (s)	% of DB Time
sql execute elapsed time	3,062.17	91.52
DB CPU	2,842.08	84.95
parse time elapsed	25.87	0.77
PL/SQL execution elapsed time	11.75	0.35
sequence load elapsed time	7.55	0.23
hard parse elapsed time	5.06	0.15
connection management call elapsed time	3.13	0.09
hard parse (sharing criteria) elapsed time	0.04	0.00
repeated bind elapsed time	0.01	0.00
PL/SQL compilation elapsed time	0.00	0.00
DB time	3,345.74
background elapsed time	204.91
background cpu time	72.30

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片段：

Wait Class	Waits	%Time -outs	Total Wait Time (s)	Avg wait (ms)	%DB time
DB CPU			3,351		87.21
User I/O	257,450	0	350	1	9.12
Commit	127,672	0	90	1	2.35
Cluster	53,770	0	10	0	0.27
Concurrency	25,652	7	9	0	0.24
System I/O	3,623	0	6	2	0.15
Network	2,069,001	0	5	0	0.14
Application	679	0	5	7	0.13
Other	20,828	78	4	0	0.10
Configuration	2,353	0	2	1	0.06

我们看到这个系统中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片段：

Wait Class	Waits	%Time -outs	Total Wait Time (s)	Avg wait (ms)	%DB time
Commit	817,470	0	5,232	6	67.49
User I/O	238,850	0	1,083	5	13.97
DB CPU			1,071		13.82
Configuration	4,150	1	403	97	5.20
Concurrency	42,626	27	31	1	0.40
System I/O	23,742	0	6	0	0.07
Network	1,838,062	0	2	0	0.03
Application	125	0	0	2	0.00
Other	2,026	82	0	0	0.00

我们看到，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的响应时间：

Event	Waits	Total Wait Time (s)	Avg wait (ms)	Waits /txn	% DB time
db file sequential read	4,315,803	11,202	3	29.65	53.06
db file scattered read	320,148	1,434	4	2.20	6.79
direct path read	683,707	1,239	2	4.70	5.87
SQL*Net more data from client	145,678	791	5	1.00	3.75
log file sync	145,656	439	3	1.00	2.08

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中找到这些信息，并判断自己的数据库属于哪种类型，瓶颈在哪里，是否存在性能风险。当面对诸如“硬件是否能够满足性能需求”，“系统明年是否需要扩容”，“应用是否会对系统产生影响”此类问题时，我们可以用这些经验值给出一个判断。

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

Statistic Name	Time (s)	% of DB Time
sql execute elapsed time	3,547.99	92.34
DB CPU	3,350.65	87.21
parse time elapsed	27.42	0.71
sequence load elapsed time	11.16	0.29
PL/SQL execution elapsed time	7.61	0.20
hard parse elapsed time	5.50	0.14
connection management call elapsed time	3.02	0.08
repeated bind elapsed time	0.02	0.00
failed parse elapsed time	0.00	0.00
PL/SQL compilation elapsed time	0.00	0.00
hard parse (sharing criteria) elapsed time	0.00	0.00
DB time	3,842.21

Oracle数据库性能模型

jacky — Sun, 13 Jun 2010 19:52:46 +0800

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

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

Oracle数据库性能模型

View more presentations from freezr.

Sequential和Scattered的含义

jacky — Thu, 03 Jun 2010 18:30:31 +0800

之前，我对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–

《数据库高可用架构》分享

jacky — Thu, 27 May 2010 21:04:10 +0800

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

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

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

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

数据库高可用架构

View more presentations from freezr.

分布式系统hash策略

jacky — Wed, 26 May 2010 00:34:33 +0800

分布式系统的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—

我们需要怎么样的你

jacky — Sat, 22 May 2010 16:33:41 +0800

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

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

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

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

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

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

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

—EOF—

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