Archive for March, 2010
Oracle高可用架构
Friday, March 19th, 2010
今天在Uwe Hesse的Blog上看到这篇文章,感觉很不错,简要地描述Oracle MAA架构的所有相关产品,虽然之前就有接触所有这些解决方案,但解释的如此清楚明了的还是第一次看到,特将其翻译如下. 原文: Oracle Database HA Architecture
Oracle高可用架构
作者: Uwe Hesse, 译者: Jametong
Oracle高可用架构是我所讲课程里的一个热门话题.本文尝试对此话题做一个总体的说明,内容涵盖”普通的”单实例数据库,DataGuard,RAC以及扩展RAC(有时也被称为”伸展集群”).Rac与Dataguard组合在一起就是Oracle公司推广的最大可用性架构(Maximum Availability Architecture,MAA).除这些Oracle的HA解决方案外,我还会简单介绍一个第三方的HA解决方案(远程镜像,Remote Mirroring).我不准备深入介绍所有这些解决方案的细节,而只是想做出一点区分的工作,并简要介绍它们各自的优势以及可能的缺陷.
首先,我们将考察目前为止仍然是应用最为广泛的Oracle数据库架构:单实例数据库.一个Oracle数据库总是由一个数据库(由数据文件,在线重做日志控制文件组成)与一个实例(有内存结构,比如数据库高速缓冲区;以及后台进程,例如数据库写进程)组成.如果我们有一个数据库以及多个访问这个数据库的实例,这就是一个RAC.如果只有一个实例访问这个数据库,就是单实例数据库.下图是一个所有组件都存储在一个服务器上的简单安装版本:
将数据库文件放置在SAN(存储区域网络)的配置也是目前比较常见的配置,如下图所示:
从高可用的角度来看,这个架构是非常脆弱的:服务器A与服务器B都是单点故障,数据库A与数据库B也都是单点故障.从而这些服务器所在的站点也是单点故障.这样,只要其中一个单点发生故障,整个数据库将不可用.一个”普通的”RAC就是为了解决其中的服务器单点故障的,如下图所示:
如果两个服务器的其中一个发生故障,数据库C将仍然可用.当然,使用RAC并不仅仅是为了实现HA.在使用RAC的其它的理由中,一个比较可靠的理由是为了实现伸缩性(Scalability):如果应用需求在将来出现增长,我们可以通过添加新的节点(Node)到集群中来解决.另外,通过使用RAC我们还可以选择使用服务管理(Service-Management)与负载均衡(Load Balance).简言之,RAC不仅仅是HA,在此详述其它原因已经超出本文的范畴了.从HA的视角看,使用RAC的缺陷是:数据库C以及相应的站点C是单点.如果站点C发生故障(比如火灾),数据库C将不可用.因此,将数据库伸展到两个站点就成为我们的选择了,这也是通常所说的扩展RAC.
现在,这两个站点就不再是单点了.数据库D是在两个站点之间做镜像的.这个架构的缺陷是两个站点之间的网络连接的成本,如果两个站点之间的距离比较远的话.这很关键,因为需要镜像的数据量会非常大.实际上,这使得两个站点之间的距离局限于几公里以内,而这与想要实现的灾难保护目标之间有冲突.这时,Dataguard就隆重登场了:利用DataGuard,我们很容易就可以实现长距离的灾难保护,因为,此时我们不再需要传输所有的数据量,而仅仅需要传输(相对小)的重做日志.在下图中,每个服务器都像上面的服务器A与服务器B一样,只有一个实例:
备用数据库由来自主数据库的重做日志. 当主库发生故障时,我们可以失败切换(Failover)到备库上并继续有效工作.这个失败切换工作可以由一个Observer(观察员程序,通常称为快速启动失败切换,Fast-Start Failover)自动实现.两个站点之间的距离达到几千公里(依赖于重做日志的传输策略与保护级别(protection level)).如果我们将RAC与Dataguard集合起来,我们就实现了MAA.显然,MAA是一个昂贵的解决方案,不过它也同时享有RAC与Dataguard的所有好处.
远程镜像是一个广受欢迎的第三方HA解决方案.总体上,它的架构与下图类似:
这时,也没有哪个站点是单点的,类似于使用扩展RAC架构.这个解决方案的缺陷是:站点间的距离也是严格受限制的,理由与扩展RAC架构类似.同时,在镜像进行的时候,第二个站点是无法提供服务的,这一点与上述的Oracle提供的HA解决方案不同.使用RAC时,所有的服务器与相应的站点都可以提供服务.哪怕是使用Dataguard,备用数据库也不仅仅是等待主库发生故障.除此之外,它还可以提供只读访问服务,这将可以有效降低主库的负载.
上图展示了Oracle 11g的新特性”物理备用数据库上的实时查询”.在恢复过程中时,备用数据库也在同时提供只读访问.另外,还可以在物理备库(Physical Standby)上做离线备份(OffLoad Backup).
附注:
其实还有另外一种可选择的架构. 基于Data Guard与单实例的一个结合.
类似于上面介绍的远程Data Guard方案, 做了一点修正: 将当前主库的一组Redo 日志放到远程(当然也受限于距离所产生的San 访问延时).
使用数据库存图片
Thursday, March 11th, 2010
图片是网站上很重要的资源，用户发布的产品图片，用户的logo，AV男，兽兽女，犀利哥等等等等，一个稍具规模的网站，图片的数量可能是千万级，这种资源的特点就是文件小，数量大，每个文件在几字节到几K不等，所以针对图片的访问，基本是非常离散的IO，考验的是系统的磁盘并发和CPU处理能力
一般网站，图片都是存放专门的图片服务器，可集中也可以分布式，比如有条件的可以购买昂贵的NAS存储，由主机拖着，以NFS或者HTTP的方式，供前面的应用访问，或者使用多台廉价PC，图片分布打散到每个机器，前台应用解决图片存取和访问策略，以便充分利用所有资源，在应用与图片服务器中间还可能加一层cache，来缓冲前台的访问压力
上面所说的方法，弊端是有很多的
1.文件系统一定是要使用的，为了管理数千万的图片，必须进行目录分层，因为一个目录下不可能存放太多的文件，前期的目录规划要考虑后期的扩展，还有图片分布均匀，这样做下来，往往目录的深度会达到5层甚至7层
2.数据迁移，备份怎么做？高级的NAS存储，有自己的卷复制，但这个粒度太粗，如果要细分到底层或中间层，会有点力不从心，对于这种大数据量的小文件拷贝，PC也是非常吃力
3.每一个图片的访问，基本会做5-7次的目录跳转，转换到磁盘，也可能有10次物理IO了，在并发量上来的时候，磁盘会是个瓶颈，当然，分布式是个方向
这里想到了另外一种方法，利用数据库来存放图片，存储的方式就是现在最流行的key-value
create table mypic
(
key number not null,
pic blob
);
create index ind_picid on mypic(key);
key是图片名称，事先最好统一规划一下，使用number数字来命名，并针对key建立索引
VALUE就是图片内容，用blob来保存
访问一个图片的方式就是：
获取图片名称 数据key
走key上的索引，定位到记录表记录
根据表记录，定位到图片的blob，并读取
这个方法的优点：
1.单个图片的访问路径缩短，数字索引比较小，分区做的好的话可能小到两层，从索引到表，到blob段，大概是4-5跳
并且KEY是区分度非常高的数据类型，在索引每层的横向检索中，不会超过1个数据块，而文件目录结构中，子目录繁多，
要遍历这层的inode后，才知道具体跳转的下层位置
2.备份方式比较灵活，可以基于整个数据库，或者单独的表，数据的迁移，删除，都是基于表级别的，比较直观，方便
3.可以在数据库层面，考虑图片的水平拆分，垂直拆分，分表，分库，都不错
4.数据库的复制技术可以派上用场，读写分离
这里数据库完全是当成一个KEY-VALUE的存储在用，我们可以考虑将一些廉价的PC堆在一起，做成一个picdb的群集，
大致画了一个草图，当然在WEB与picdb间应该还有层cache的,这个方法是YY出来的，可能很多地方不成熟，但SY强身，YY强国，没有想法，哪来的动力？欢迎各位专业人士拍砖
不平衡的索引?
Tuesday, March 2nd, 2010
本文翻译自Jonathan Lewis早年写在dbazine上的文章unbalanced indexes? 本文的word版本可以到此处下载
原文参见: 不平衡的索引?
不平衡的索引?
by Jonathan Lewis
网络上有多篇介绍Oracle索引实现机制的文章,都提及需要经常重建索引.在这些文章中的某处,总是会出现这样一段简短的描述,索引会如何变的不平衡,以及可能导致的后果.很不幸,它们好像忽视了这样一个事实,Oracle使用的B-tree机制是一种”平衡B-tree”索引,也就是说,索引无法变得不平衡.
“平衡”到底意味着什么?
既然Oracle的索引使用的是平衡B-tree,为什么还有如此多的人相信他们的索引会变得不平衡呢?
另外,平衡B-tree到底又是什么呢?
第二个问题的答案可能能够帮助我们得到第一个问题的答案.
从技术角度讲,平衡B-tree的显要特性是,在任意时间点,任何叶子节点(leaf block)到根节点(root block)的距离都相等,平衡是指从顶部到底部的平衡.
就Oracle来说,执行一个treedump命令就可以很容易发现这一点,如图-1所示:
select object_id
from user_objects
where object_type = ‘INDEX’
and object_name = ‘T1_IDX1′
– and subobject_name = . . .
;
alter session set events ‘
‘immediate trace name treedump level N’;
图-1: 一次索引树转储涉及到的步骤
首先,需要找到你想要转储(dump)索引或者索引分区(index partition)的object_id;接着,将object_id作为level的参数来调用treedump事件. 如果检查这个索引树(tree dump)转储生成的跟踪文件,你将发现类似于图-2中所示的结果.
branch: 0×14001aa 20971946 (.. level 2)
branch: 0×14003ef 20972527 (.. level 1)
leaf: 0×14001ab 20971947 (..)
leaf: [...]
为什么Oracle不使用我的索引?!
Tuesday, March 2nd, 2010
本文翻译自Jonathan Lewis发表在DBAZine上的文章:Why Isn’t Oracle Using My Index?!,可以从此处下载本文的Word版本.
原文参见: 为什么Oracle不使用我的索引?!
为什么Oracle不使用我的索引?!
by Jonathan Lewis
标题的这个问题可能是在Metalink论坛与Usenet新闻组出现的最频繁的问题了.这篇文章使用一个测试用例(可以在你自己的系统来重现的)来演示基于成本的优化器的基本工作原理.在看完这篇文章之后,当再次遇到这个令人讨厌的问题时,你应该就可以自信的解答了.
由于在安装Oracle的时候存在大量的选项,因此当某人执行一条你口授的脚本时,通常很难精确的预测即将出现什么结果. 当时我想要尝试一下,希望你的数据库选择了一个相对普通的安装选项,并且最常用的关键的参数是取得默认值. 这个例子是在Oracle 8.1.7下创建并测试的,参数db_block_size被设置成最常用的值(8k),参数db_file_multiblock_read_count也设置了一个很常用的值(8).在Oracle 9.2下跑图-1中的这个脚本(创建了一组表,在表上添加索引并分些表与索引),结果可能出现部分差异.
create table t1 as
select trunc((rownum-1)/15) n1, trunc((rownum-1)/15) n2, rpad(’x', 215) v1
from all_objects
where rownum <= 3000;
create table t2 as
select
mod(rownum,200) n1,
mod(rownum,200) n2,
rpad(’x',215) v1
from all_objects
where rownum [...]
