Tag Archive for 'ORACLE'

Oracle Exadata技术浅析

Published
by
jacky
on 2010-02-01
in 大话技术
. 11 Comments

自从Oracle和HP推出Exadata之后，我就很关注这个产品，之前也写了一篇Oracle database machine介绍它。去年，Oracle和SUN合并后，推出了Oracle Exadata V2，相比较上一代产品有几个变化：第一，使用SUN的硬件；第二，宣称支持OLTP应用；第三，Oracle 11g R2提供了更多的新特性。

Exadata Smart Flash Cache

Exadata V2整体架构并没有太多改变，换用了SUN的硬件，除了采用intel最新的nehalem CPU以外，每台storage cell更是配置了384GB的flash，这也是为什么V2可以支持OLTP应用的关键。

Flash cache完全是自动管理，Oracle会根据数据的访问情况，决定哪些数据放在flash cache中。所有的数据都是先被写到普通磁盘上，再根据访问情况读入flash cache的，所以如果flash card发生故障，数据不会丢失。当然，Oracle提供了方式，可以让用户手动将表或者索引pin在flash cache中。

在自动管理的方式之外，Oracle还允许用户人工创建flash disks，和普通磁盘一样，这些flash disks通过ASM输出给数据库使用，用户可以把一些访问非常频繁的数据文件放在上面。这些flash disks不仅仅是cache了，所以ASM会在cell和cell之间做镜像。如果某块卡发生故障，那么整个storage cell上的flash disks会offline，保证数据不会丢失。

Smart scan

Smart scan是Exadata最重要的一个功能，它的作用就是把SQL放在每个cell上去运行，然后每个cell只返回符合条件的数据给数据库，这样就极大的降低了数据库服务器的负载和网络流量，并充分利用了cell的计算资源和IO资源。

传统方式：所有的数据都需要返回给数据库服务器，网络带宽要求高，所有的计算在数据库服务器上完成。

Smart scan：只返回符合条件的数据，减少网络带宽，并充分利用了cell上的计算和IO资源。

这里有一点要注意，在使用smart scan时，每个cell返回给DB server的是结果集，而不再是传统的block，DB server完成结果集的处理，并返回给客户端。

Smart scan如何处理join？是我一直想要搞清楚的问题。事实上，smart scan只能处理join filtering，而真正join的工作必须在DB Server上完成，而且smart scan仅适合于处理DSS环境的复杂join，对于OLTP类型的简单join，smart scan并不能发挥其优势。设想下面的查询：

select e.ename,d.dname from emp e, dept d where and e.ename=’Jacky’ and e.deptno=d.deptno;

假设采用nested loops join，smart scan只能完成e.ename=’Jacky’这个条件的过滤，然后将符合条件的emp表的数据返回到DB server，然后由DB Server完成join的工作，逐条查询dept表(e.deptno=d.deptno)的数据。所以smart scan并不适合nested loop join（我认为smart scan只有在适合的条件下才会启用），只有DSS环境的大数据量复杂join才会发挥出优势。而且smart scan只能完成filtering的工作，而不能真正完成join的工作，这个与Greenplum数据库是不同的（有兴趣可以看我的文章，Greenplum技术浅析）。设想下面的查询（emp和dept都是大表）：

select e.ename,d.dname from emp e, dept d where e.deptno=d.deptno;

假设采用hash join，由于没有任何过滤条件，smart scan只能把两个表的数据全部返回到DB Server上进行join操作，不过smart scan也不是一点用都没有，至少还可以进行column的过滤，只返回需要的字段就可以了。

Oracle的文档中，曾经提到对于一个大表和小表join时，smart scan会采用bloom filter来快速定位（可以看我以前的文章，有趣的bloom filter）。方法是把小表build成为bloom filter，然后在每个storage cell上对大表做scan，利用bloom filter快速定位符合条件的结果，并返回给DB Server作join。

Storage index

存储索引，顾名思义是在存储级别建立的索引，简单的说就是为表中的每一列数据建立一个索引，每个index entry记录一段数据区间的最大值，最小值以及它们的物理位置，文档上说1MB数据对应一条index entry，见下图：

如果我们查询B<2，或者B>8的数据，根据存储索引，我们就可以跳过这些不在min和max之间的数据块，极大的提高了扫描的速度，这就是存储索引的意义。

Hybrid Columnar Compressed

首先我们要搞清楚，什么是行压缩，什么叫列压缩。我们熟悉的数据库，如Oracle，MySQL等都是基于行的数据库，就是行的不同字段物理上存放在一起，还有一种是基于列的数据库，就是每个字段的不同行物理上存放在一起。他们的优缺点同样突出：

基于行的数据库，访问一行非常方便，但是由于同一列的数据是分开存放的，如果要针对某一列进行查询时，几乎要扫描整个表才能得到结果。基于行数据库的压缩，称为行压缩。

基于列的数据库，因为同一列的数据物理上放在一起，所以访问一列非常方便，也就是说如果针对某一列进行查询时，不需要扫描整个表，只需要扫描这一列的数据就可以了，但是访问一行的全部字段非常不方便（又是废话）。基于列数据库的压缩，称为列压缩。

Oracle通常说的compress功能（包括11g R2的Advanced compress），都是行压缩，因为Oracle是个基于行的数据库。大概的方法就是在block头部存放一个symbol table，然后将相同的值放在那里，每行上相同的数据指向symbol table，以此来达到压缩的目的。行压缩的效果通常不好，因为我们知道行与行之间，其实相同的数据并不多。但是列压缩则不同，因为相同列的数据类型相同，很容易达到很好的压缩效果。

行压缩和列压缩都有其优缺点，而Oracle的混合列压缩技术，实际上是融合了列压缩的高压缩比和行数据库的访问特性，将两者的优点结合起来。Oracle提出了CU的概念（compress unit），在一个CU内，是一个基于列的存储方式，采用列压缩，但是一个CU内保存了行的所有字段信息，所以在CU与CU之间，Oracle还是一个基于行的数据库，访问某一行，总是只在一个CU内。每个CU由一些连续的block组成，CU header中记录了每一行的各个列在CU中的分布情况，在混合列压缩模式下，一行通常是跨多个block的。

所以说混合列压缩，结合了列压缩和行访问的特点，即可以提供非常高的压缩率，又很好的保证了基于行类型的访问。

Exadata的另一个重要功能是IO resource management，如果我们在一个Exadata上部署了很多个数据库，可以用它来管理IO资源，这里就不作阐述了。

目前，我还没有了解到在国内有Exadata的应用，而且资料也是比较少的。希望有机会可以真实的测试一下它的性能，我不怀疑他在DSS环境下的表现，但是对于OLTP类型的应用，是否真的象Oracle说的那么强劲，还有待于验证。

–EOF–

如何控制SQL执行计划之9i篇

Published
by
jacky
on 2010-01-28
in 大话技术
. 6 Comments

对于一个高并发的OLTP系统，SQL执行计划的改变往往意味着灾难。很多因素都可能导致执行计划发生不可预期的改变，比如表结构，索引，统计信息等变化，甚至我们发生过一个小小的grant操作，导致执行计划失效，重新解析后生成了一个不正确的执行计，让整个系统Crash的案例。最近，我们对一个分区表增加分区后，导致了执行计划发生改变，故障再次重演。

如何控制SQL的执行计划就成为了一个课题，之前我曾经写过一篇关于调整SQL执行计划的文章，但是内容比较粗略。因为Oracle提供了很多手段去控制执行计划，所以我打算为每个版本都整理一个最佳实践。

我们设想一个场景，一个SQL本来应该走nested loop join，但是由于某种原因，突然变成了hash join，调整统计信息无效，数据库load不断升高，只留给你很少的时间，怎么办？最直接有效的方法是在SQL上加hints，但是需要程序发布，或者程序根本无法修改。

9i为我们提供了Stored outline，大家都非常熟悉，但是对于上面的场景，还是需要点技巧。方法是：生成两个stored outline，一条是错误的，一条是正确的（加hints），两个然后将其执行计划交换。看下面的步骤：

1.创建两个public stroed outline，第一个是目前运行的，第二个是加了hints.

create or replace outline OUTLN1 on select e.ename from emp e, dept d where e.deptno=d.deptno;
create or replace outline OUTLN2 on select /*+ use_nl(e d)*/ e.ename from emp e, dept d
where e.deptno=d.deptno;

拷贝成为private outline

create or replace private outline PRIV_OUTLN1 from OUTLN1;
create or replace private outline PRIV_OUTLN2 from OUTLN2;

交换两个stored outline的执行计划

update ol$ set ol_name=decode(ol_name,'PRIV_OUTLN1','PRIV_OUTLN2','PRIV_OUTLN2','PRIV_OUTLN1')
where ol_name in ('PRIV_OUTLN1','PRIV_OUTLN2');

设置本session生效，并测试结果

alter session set use_private_outlines=true;

刷新

execute dbms_outln_edit.refresh_private_outline('PRIV_OUTLN1');
execute dbms_outln_edit.refresh_private_outline('PRIV_OUTLN2');

发布到public outline

create or replace outline OUTLN1 from private PRIV_OUTLN1;
create or replace outline OUTLN2 from private PRIV_OUTLN2;

设置使用，调整完毕

alter system set use_stored_outlines=true;

这样操作的原因是因为stroed outline必须依赖SQL的文本匹配，所以，我们利用加hints之后的SQL产生正确的执行计划，并通过交换的方式，让SQL的执行计划变成我们想要的结果。当然，如果你愿意，也可以直接修改ol$hints表的内容，同样可以达到改变执行计划的目的。

–EOF–

online rebuild发生的问题

Published
by
jacky
on 2010-01-26
in 大话技术
. 6 Comments

朋友遇到一个问题，当建立一个包含varchar2(4000)的索引时，直接创建没有问题，但是如果加上online子句，则报错：

ORA-00604: error occurred at recursive SQL level 1
ORA-01450: maximum key length (3215) exceeded

这里实际上包含了两个问题：

1.索引的key到底可以有多大？因为索引的key是不可以跨越block的，所以最直接的决定因素是block size，Oracle的文档给出了一个计算公式：

DB_BLOCK_SIZE:                  Maximum Index Key Length:
==============                  =========================

2K  (2048)                       758  Bytes
4K  (4096)                       1578 Bytes
8K  (8192)                       3218 Bytes
16K (16384)                      6498 Bytes

文档中说：每个index leaf block至少有两行记录，考虑block header，PCTFREE，INITRANS等因素，每个index key最大可以为block size的40%。但是我测试了一下（8K block size），发现并不是如此。

create table test(id varchar2(4000),id2 varchar2(3000));
create index test_ind on test(id,id2);
ORA-01450: maximum key length (6398) exceeded

最大的长度是6398，而不是文档中提到的3218，后来我把block dump出来，发现每个index leaf block中只有一行，而不是文档中所说的至少有两行，这样index key的最大值就自然变大了，大约为block size的80%。为什么与文档上不一致，应该是版本的问题，文档描述的是在9i之前的情况，而9i之后Oracle作了改进（没有8i的环境，没法证实）。

2.为什么online无法创建，而直接创建没有问题呢？

因为online创建的过程中会生成一个中间表，用来记录创建过程中的变化，而这个表是IOT表。经过测试，发现IOT表的限制比较严格，8k的block size，最大长度只能有3215，所以普通创建可以成功，而online创建则不行，关键还在背后的IOT表上。

怎么解决这个问题，Oracle的官方说法是加大block size，但是对于IOT表，我们发现加大block size并没有太大作用，最大长度也只有3800。看来，对于INDEX每个block可以只存放一条，而IOT比较特殊，每个block需要至少存放两条记录。简单点说，IOT的限制比普通INDEX更严格一些，至于为什么，我想也许没什么特别的原因吧，也许只是版本改进过程中的代码问题。

我很奇怪，怎么会在varchar2(4000)的字段上建索引呢？一问才知道，原来这个字段实际内容并不长，但是当时设计时，可能是为了方便，直接设计成最大值了，才导致现在的问题。现在只能想办法，重新建一个适当长度的字段，把内容拷贝过去，然后再建立索引。

–EOF–

一种并行加载的方法

Published
by
jacky
on 2010-01-07
in 大话技术
. 11 Comments

一个数据库的同步系统，可以分为三部分：抓取变化，传输和加载。抓取数据库变化，最通常的做法是用trigger记录到表中，或者通过解析Oracle redo log中的信息来抓取。传输是将数据库变化记录到特定格式的文件中，通过网络推送到目标数据库上。加载则是指在目标数据库上应用这些变化（SQL），这里主要是讨论并行加载的实现思路。

我们通过trigger或者redo log得到了数据库变化的事务流，这个流是按照事务的提交顺序排列的，最简单的方法是在目标端按照这个事务流顺序执行，就是串行执行。这么做的最大优点是可以完全保证事务的一致性，但是缺点是性能很差。如果采用并行加载，就需要考虑事务相关性的问题，所谓事务相关性，是指两个或多个事务更新了同一条或者多条记录，他们之前存在时间上的依赖关系。如果将具有相关性的事务分在不同的并发进程上加载，可能出现后面的事务被前面的事务覆盖掉的情况，最终导致事务混乱。

我们设计一个并行加载的方法，目标是尽可能快的加载数据，保证不会产生数据混乱的情况，但是不能保证事务完全的一致性。这句话如何理解，假设两个事务不相关，A事务只更新A表，B事务只更新B表，如果在源库A事务先于B事务完成，那么在目标库可以让B事务先于A事务执行，或者两个事务并行执行，虽然事务的顺序与主库并不一致，但是数据是正确的，因为两个事务不相关。

我们如果按照事务去分拆并行的话，设计比较困难，因为涉及到事务的相关性分析。换个思路，我们可以按照数据来拆分并行，也就是把同一个事务拆分到不同的并发进程中，保证表的同一行记录的所有更改都由一个并发进程处理。按照这个思路，我们首先把事务流加载到一个队列或者一个内存结构中去，为了理解方便，我们可以认为放在了一张内存表中，这个表有以下几个字段，事务ID，表名，PK，SQL，时间序列号。首先按照不同的表分组，将不同的表的操作分配给不同的进程处理，每个并发进程按照事务提交的时间顺序来执行。比如：A事务更新A,B,C三张表的A1,B1,C1记录，B事务更新A,B,C三张表的A2,B2,C2记录，C事务更新A,B,C三张表的A3,B3,C3记录。三个事务的提交顺序是A,B,C，这时我们可以启动三个并发进程，分别处理A表，B表和C表的操作，顺序是A1,A2,A3……这样就实现了最简单的并行，虽然目标库的事务与主库并不一致，但是数据是完整和正确的。

按照表来做并行可能还不足够，如果某张表的更改量特别大，这时我们还可以进一步分组，针对同一张表中的操作再按照行（PK）分组，保证同一行的不同操作分配到同一个的并发进程处理。这里有一些小的技巧，在很多情况下，我们可以只关注某行的最后一个操作就可以了，比如某行的最后一个操作是delete，那么我们只需要执行delete，之前的操作就可以直接丢弃，如果是insert，那么我们可以在目标库先执行delete，然后再insert，针对我们自己的系统，有些表的update是全部字段更新，所以我们直接采用了merge操作，相当于对同一行的不同操作，我们做了合并处理。因为系统是自己开发的，所以可以针对我们自己的特性定制了功能。

有人说这个思路有些土，Oracle logical standby，Goldengate或者Shareplex这些商业软件是怎么做的？我之前也写过一篇文章探讨这个问题：Oracle Logical Standby SQL Apply Architecture，这些商业软件都声称自己分析了事务的相关性，可以做到并行加载，但是同样也存在事务不一致的问题，但是分析事务的相关性肯定要按照表或者行来分析，所以思路应该不会差太远，无非是他们包装得更好。

PS:这个方法并不是我想出来的，是团队的智慧。现在看起来思路挺简单，但是其实困扰了我们很长的时间。当然如果你有更好的方法，欢迎和我讨论。

–EOF–

Oracle排序算法

Published
by
jacky
on 2009-12-30
in 大话技术
. 6 Comments

大牛jonathan lewis在圣诞节出了一个小题目：Holiday Quiz

I have a table with one million rows, there are no indexes on the table. The table has a column called sortcode which has no nulls, and has been generated in a highly random way so that no value appears more than four times. Consider the following queries:

select sortcode
from t1
order by sortcode;

select  sortcode
from (
select sortcode
from t1
order by sortcode
) where rownum <= 10;

How many rows are sorted in each of these two queries – and roughly how much memory would you expect Oracle to use ?

从表面上看，两个SQL仅仅是返回数量的不同，因为没有索引，所以就算只返回10行，但是也必须完成整个排序过程，所以从排序的资源消耗上，两者应该没有太大差异。

Jonathan公布了答案：Short sort，主要是Oracle引入了一个针对sort的改进，即version 1 sort，大致原理是用一个二叉树来保存最终需要返回的记录，并且记录这个二叉树中最大的值，针对每个值逐一与这个最大值比较，如果大于这个最大值就直接丢弃（因为这里要寻找最小的10条记录），如果小于最大值，则插入到这个二叉树中去，最终返回这10条记录。因为普通的排序要返回所有记录，如果也采用这个存储方式，即用二叉树来存储排序的结果，可能非常耗费内存，所以这个改进只针对返回结果集比较少的情况。另外用二叉树，可以迅速的找到插入的位置，减少比较的次数。最后Jonathan还用三个极端情况来证明了这个排序算法的效果，正序，反序和随机，正序和随机时，因为大部分值都在第一次比较就被丢弃，所以占用内存和比较次数都很少；相反，如果是反序的情况，因为几乎所有的值都需要插入到这个二叉树中，占用内存和比较次数都大幅度增加，关于这个话题大家可以看Jonathan的博客，这里不再赘述。

我这里想讨论另外一个话题，Oracle到底采用什么排序算法？我查阅了很多资料，都没有提及。学过计算机的人都知道排序算法是一个古老而又有趣的话题，我们熟知的有：冒泡排序，选择排序和插入排序，这三种排序算法比较简单，但是效率不高。高效率的排序算法有：快速排序，堆排序和归并排序，我们下来大致介绍下这三个排序算法。

快速排序是采用分治法的策略，即分而治之，首选选取一个中枢值（一般选序列中的第一个数），每次规划将序列按照这个中枢值分成两个序列，左边的序列都比中枢值小，而右边的序列都比中枢值大，一次规划完成后，中枢值找到了其最终的位置，并且将原有序列分为两个部分，然后再用同样的方法分别处理这两个序列，直到排序全部完成。快速排序是一种效率很高的排序算法，如果采用原地分割的算法，快速排序占用很少的额外空间。

堆排序有点类似于插入排序，但是他利用了堆积树（堆）这种数据结构，堆积树其实就是一棵完全二叉树，但是又满足堆属性：子节点的属性总是大于或者小于其父节点，即所谓的大根堆和小根堆。排序的过程实际上就是把数据不断插入到堆积树上，而返回排序结果的过程就是不断取堆的最大（大根堆）或者最小值（小根堆），并不断缩小堆的过程。

归并排序就是将两个或多个有序的序列合并为一个有序序列的排序过程，称为两路归并排序和多路归并排序。归并排序的算法是在每个有序队列上设置一个指针，通过不断移动指针，在每个序列上取出元素进行比较，并合并的过程。归并排序通常使用在外部排序中。

内排序和外排序，内排序指在内存中完成的排序过程，外排序指排序内容无法在内存中一次完成，而需要借助外部存储来完成排序的过程。

根据Jonathan的实验，我们可以看到上面这个排序优化的例子，实际上利用了堆排序的特性，但是由于堆积树本身需要额外的空间，在返回记录数很多的情况下，并不适合，实验也证明，如果采用堆积树来保存所有记录，需要占用更多的空间。关于Oracle的排序算法，虽然不是很明确，但是很可能是快速排序的一种，因为快速排序占用稳定的空间，通常情况下可以提供很好的效率。如果排序无法在内存中一次完成，Oracle需要借助Temp空间，这就是外排序，Oracle使用多路归并排序算法，按照排序区大小把结果集切分成多个子集，每个子集在内存中完成排序，然后将他们合并起来。排序区大小对归并排序的性能影响很大，排序区应该能至少容纳每个子集中的一条记录，否则性能会急剧下降。

Oracle的排序算法我们并不了解，以上内容很多也是基于Jonathan的实验的猜测，所以大家别较真。对于排序算法本身，我的描述并不一定正确，欢迎大家批评指正。

–EOF–

用ASM和iSCSI实现的另类HA方案

Published
by
jacky
on 2009-12-10
in 大话技术
. 6 Comments

普通PC本地磁盘，没有共享存储，如何实现HA？Dataguard挺好，但是存在数据丢失的可能性，而且很难做到应用透明切换。我们用ASM,Heartbeat和iSCSI可以实现一个廉价的HA方案，如下图：

用iSCSI将本地磁盘输出到对方的机器上，利用ASM的failgroup做mirror，保证数据mirror在两台不同的机器上，就算一台机器完全损坏，数据可以做到百分之百不丢失。用Heartbeat作HA探测，如果发现主机故障，则强行关闭DB和ASM，并在备机启动ASM和DB。如果使用Oracle 11g R2，还可以利用Preferred mirror read的特性，保证主库读自己的本地磁盘，而不是通过iSCSI读备机磁盘，这样可以达到更好的性能。

缺点：Heartbeat作为HA软件，我们并不是十分了解其探测机制，可能出现误判或者无法切换的情况。但是其实IBM hacmp这种HA软件一样有问题，比如Oracle hang住时，现在的hacmp根本无法探测，因为hacmp只是判断Oracle的进程在不在，而不管数据库是否活着。

我想不管什么HA软件，都无法处理所有的异常情况，我们只要有完善的监控和应对措施就可以了。比如我们现在所有的DB都有一个监控，就是定时模拟应用去更新数据库中的数据，如果发现超时或者报错，就认为数据库出现hang的情况，并发出报警。

–EOF–

另：之前我有一篇文章介绍用ASM和iSCSI搭建RAC的文章，在实际测试过程中，发现存在一些问题，因为在11g R2之前，voting disk和OCR都必须放在RAW devices上。因为没有共享存储，如果发生某台机器全部宕机，voting disk可能会丢失一部分，造成RAC的cluster机制发生误判。所以在11g R2之前，这个方案是有问题的，在11g R2中，Oracle几乎所有的东西都可以放在ASM中，这个方案也许可行，我还没有测试过。

在我写完这篇博文后，发现这个方案存在一些问题，通过iscsi将online redo输出到另外一个主机后，log file sync的响应时间需要40-60ms，这个响应时间肯定是无法接受的。现在两台主机的互连是四块千兆网卡直连，通过Linux的Multipath来管理多路径，为什么响应时间这么久，我们还在进一步查找问题。

Oracle hash分区的秘密

Published
by
jacky
on 2009-12-04
in 大话技术
. 3 Comments

在面试时经常会问一个问题，请列举出hash在数据库内部的应用，hash的原理虽然简单，但是它在数据库中可以说是无处不在。其中hash partition是hash在数据库中一个简单的应用，虽然它没有range partition那么常用，但是我们在做数据库水平拆分时，其实就是利用了hash partition的原理，利用hash函数对某个key进行运算，然后将其分布到不同的主机上，原理很简单。

我们在设计时遇到了一个问题，当分区的数量需要变化时，基于hash的原理，数据可能会从一个分区移动到另外一个分区，因为某个key在4个分区时，可能被分布在分区3，而在8个分区时，可能被分布在分区5。这样每当分区数量变化时，就需要全部重新分布数据，代价很高。

那么Oracle是怎么做的？首先可以肯定的是Oracle的hash partition在分区增加时，不需要做全部数据的重新分布。有人告诉我Oracle的hash函数比较牛，可以保证分区数量增加时，这个hash函数可以让原来的数据还在旧的分区中，而新的数据可以分布在新的分区。Oracle的函数无非就是get_hash_value或ora_hash(10g)，从hash的原理上来说，这也是不可能做到的。

我们对hash partition都有一个常识，就是partition的数量最好是2的次方，也就是2，4，8，16……，否则分区会出现不分区均衡的现象，按照hash的原理，不管是几个分区，都可以做到完全均衡的，为什么会不均衡，其实答案已经出来了，Oracle为了能够增加分区，为你预留了几个看不到的分区。

假设我们有6个分区，一共8000条数据，数据的分布如下图：

hash partition不能直接增加分区，而是split当前分区，当需要增加到8个分区时，实际上是分区3和分区4分别split产生新的分区7和分区8，如下图：

Oracle如何做到分区数量增加后，其他分区的数据不受影响呢，其实很简单，Oracle在做hash运算时，预留了分区，比如6个分区，实际上是用8个分区的hash来运算的，只不过把缺少的分区的数据合并到其他分区，这样就会出现数据不均衡的情况。Oracle的公式是这样的，用等于或者大于当前分区数量的最小的一个2的N次方，比如6个分区做8个hash bucket。我们再来考虑一下2，4，8，16（2的N次方）的情况，比如要把4个分区加为5个分区，因为已经是2的N次方，所以数据会均匀分布，而且Oracle还是使用4个hash bucket。这时新增的分区5实际上把分区1 split后产生的，这时因为有5个分区了，所以会使用8个hash bucket。这时Oracle的hash函数就比较牛了，它可以保证2，4，8，16个分区时，同一个键值分布在相同的分区或者是对应可以合并的分区，看下面的SQL：

select ora_hash(’hellodba’,1)+1 par2,ora_hash(’hellodba’,3)+1 par4,ora_hash(’hellodba’,7)+1 par8,ora_hash(’hellodba’,15)+1 par16 from dual;

      PAR2       PAR4       PAR8      PAR16
---------- ---------- ---------- ----------
         2          4          4         12

上面的SQL我们看到分区的数量在2，4，8，16时，hellodba这个key分别落在在2，4，4，12号分区，虽然落在不同的分区上，但是分区4和分区12是对应可合并的，这样就保证了数据是不需要移动的。一句话总结就是hash bucket总是2的N次方，如果分区数不足，则会合并数据，产生不均衡的情况，这样增加分区时，只需要对应分区的数据做split即可。同理，减少分区也不是简单的drop，而是合并分区。

再回到我们的项目中，我们为了解决这个问题，采用了更简单的处理方案，直接就做了1024个分区，我们有8个物理数据库，每个数据库中有128个表，以后再分拆时，只要移动这些表，并修改应用中的对应关系就可以了。其实和Oracle合并再拆分的思路是一样的。

这个问题其实在大牛lewis的Practical Oracle8i中讲过，当时我并没有仔细想清楚，现在想清楚了，特此记录。有些东西，明白了就觉得它挺简单的，希望对大家有帮助。

–EOF–

数据库HA方案

Published
by
jacky
on 2009-12-02
in 大话技术
. 3 Comments

我们常用的HA方案有几种：一是用小型机和HA软件作双机热备，这种方案始终有一台设备处于空闲状态，设备利用率很低，而且必须用IBM，HP等厂商的硬件，代价昂贵。二是用Oracle的RAC来做HA，在Linux环境下，Oracle提供了全套的解决方案，是个不错的选择，不过最低也需要一套共享的存储设备。三是用Oracle DG，这种方案成本最低，但是无法做到故障时应用透明切换，我们也曾经尝试过用heartbeat配合DG failover来作一些尝试，但是在测试中发现，在极端情况下，可能存在丢失数据或者无法切换的可能性。

自从使用MySQL数据库以来，我们就一直探索MySQL的HA方案，目前应用最广泛的是用heartbeat作HA，利用MySQL双向复制技术，达到透明切换的目的。但是heartbeat并不是十分的稳定，而且切换的过程也比较长。

是否有更好的解决方案？首先要解决故障探测的问题，如果应用可以自己探测数据库状态，发现数据库出现问题时，可以切换到另外一台备机；其二主备库之间的数据同步问题，如果我们可以解析Oracle或者MySQL的日志，还原成SQL信息并应用到备机，这样就实现了logical standby或者MySQL复制的功能。利用这两个功能，我们可以实现一个更廉价更灵活的HA方案。

目前我们正在做三个工具，第一是日志解析工具，包括Oracle和MySQL，日志解析是将日志文件中的变化还原为SQL或者日志信息；第二是数据同步工具，主要负责将日志信息打包传输，并应用到目标数据库上；第三是数据库探测与路由工具，主要负责探测数据库状态，对应用做透明故障切换。

这个方案中，由于数据库不再有primary和standby之分，仅仅是应用端来作判断连接哪个数据库，所以故障切换的时间非常快，我们测试大概只需要10秒。但是数据同步可能存在一定的延时，也就是说数据库切换后，数据可能存在一定程度的丢失，但是我们可以在切换后再对数据进行补全，这个我们是可以接受的。利用这些工具，我们可以搭建出很多灵活的解决方案，并不一定要依赖IBM，Oracle的解决方案，毕竟适合我们的才是最好的方案。

目前这个方案还在开发与验证中，欢迎大家和我探讨HA这方面的问题。

–EOF–

11g ASM新特性

Published
by
jacky
on 2009-11-05
in 大话技术
. 0 Comments
.!.

Oracle 11g的ASM有两个有意思的特性，我们看看他们能带给我们什么？

1.Fast mirror resync

原来当diskgroup中的盘发生故障时，Oracle会将这个盘标记为offline状态，并在一定的时间内从diskgroup中drop掉这块磁盘。如果disk只是临时性的故障，那么当故障恢复时，需要同步这块盘的全部内容，尤其是当某个failure group的全部磁盘都出现问题，比如我们的存储某个节点临时性断电，这时要重新build整个failure group中的所有磁盘，这个操作会非常耗费系统的资源，而是同步的过程会很长。

fast mirror resync这个特性在发生故障时，记录数据变化，然后当磁盘恢复时，只需要同步这些变化内容，让同步的时间变得很短。DISK_REPAIR_TIME这个参数控制可以恢复的时间长短，如果故障超过这个时间，Oracle将从diskgroup中drop这块盘。

比较有意思的问题，第一个是Oracle如何记录这些变化？文档中并没有明确说明，但是我猜测是用位图方式来实现，即用位图来标识哪个extent发生了变化，然后当故障恢复时同步这个extent即可，因为位图占用的空间很小，这样就可以记录很长时间的变化。第二个是如果整个磁盘都坏掉，换了一块新的磁盘，这时必须同步这个磁盘的所有内容，fast mirror resync就失效了。

2.Preferred mirror read

ASM中mirror有primary copy和secondary copy，ASM总是读primary copy的内容，但是ASM会将不同extent的primary和secondary copy放在不同的failure group中，比如extent 1的primary在failgroup1，secondary在failgroup2，而extent2则刚好相反，用这种方式来实现负载均衡。

Preferred mirror read可以控制Oracle优先读取某个failure group上的copy，这个特性在RAC上很有用，我们可以控制RAC的节点优先读取离自己最“近”的存储，我突发奇想，设计一个两节点的RAC系统，利用iscsi来共享自己的磁盘给对方，然后利用这个特性，控制每个节点去读自己的本地磁盘。

下图这个方案，我们选用两台PC server，没有共享的存储，每台PC24块盘，如果追求吞吐量，用SAS/SATA盘，如果追求IOPS，可以用ssd盘。用iscsi将本地磁盘输出给地方节点，形成共享存储，RAC节点间互连可以用直连或交换方式。ASM中分别将两个PC的磁盘定位为单独的failgroup，利用preferred mirror read，让每个节点优先读取自己的本地failgroup中的extent copy.

以上方案未经测试，纯属虚构，如果谁有兴趣，可以搭一个验证是否可行。

将山寨进行到底。

–EOF–

Oracle ACFS

Published
by
jacky
on 2009-08-27
in 大话技术
. 2 Comments

Oracle 11g rR2发布在即，我最关注的是Oracle ACFS(Oracle ASM cluster file system)。它将ASM扩展为cluster file system，这样ASM就不仅仅可以为Oracle数据库提供服务，而且成为了一个通用的存储解决方案。

最让人兴奋的是ACFS终于提供了snapshot功能，采用copy-on-write技术（还有一种snapshot的技术是write-on-redirect，Netapp采用这个技术，在写的性能上要比copy-on-write好），最多可以提供63份snapshot。利用这个功能，我们可以搭建出很多有意思的解决方案。

我现在的主要工作就是用Oracle，MySQL和其他技术搭建解决方案，用最低廉的成本解决现实工作中的问题。另外的工作是研究Oracle各种机制的实现原理，并且用最简单的语言描述出来，其实好多原理都可以应用在我们自己的项目中。

期待Oracle 11g R2.

–EOF–