http://www.alidba.net 这里记录着阿里巴巴数据库团队成员的点点滴滴 Fri, 19 Mar 2010 08:10:27 +0000 http://backend.userland.com/rss092 en 今天在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 访问延时). http://www.alidba.net/index.php/archives/406 图片是网站上很重要的资源，用户发布的产品图片，用户的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强国，没有想法，哪来的动力？欢迎各位专业人士拍砖 http://www.alidba.net/index.php/archives/400 本文翻译自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: 0x14001aa 20971946 (.. level 2) branch: 0x14003ef 20972527 (.. level 1) leaf: 0x14001ab 20971947 ... http://www.alidba.net/index.php/archives/394 本文翻译自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 ... http://www.alidba.net/index.php/archives/392 本文翻译自Guy Harrison的blog: Flash tablespace vs. DB Flash Cache, 这是他写的关于Flash Cache系列文章的最后一篇,另外还会翻译两篇Kevin Closson写的关于Flash Cache的相关文章. 之前两篇关于Flash Cache的文章如下: 数据库Flash Cache(II) 使用Oracle 11GR2 数据库Flash Cache 原文链接: 闪存表空间 VS 数据库Flash Cache 闪存表空间 VS 数据库Flash Cache 在这篇文章中,我将根据我最近针对使用SSD作为数据文件的存储以及使用Oracle 11GR2数据库Flash Cache所做的测试,给出一份两者的性能对比. 有时,我的整个职业生涯看上去都是在等待旋转磁盘的终结.这项技术是如此古老,能力限制如此明确,如此机械.因此,SSD作为一种数据库存储介质越来越可行(Oracle 11GR2已经直接支持这一点),这个事实令人振奋. 使用SSD作为数据库存储的一部分确实会产生很大的问题,但是,理解闪存SSD的性能特征却是非常重要的,它可以帮助我们确保不会不当地使用它. SSD有以下两个特征: 基于闪存的SSD使用与常见的USB盘相似的闪存技术,这种USB盘已经在小容量移动数据存储领域替代软盘.闪存RAM比较便宜,提供不需要电池备份的持久存储,因此其耗电量也很低. 基于DDR RAM的SSD使用本质上与服务器核心内存差别不大的内存模块.这种RAM需要有持久存储(如磁盘或闪存RAM)和内部电池来支撑.在发生电力故障的时候,电池可以提供足够的电力来保证可以将RAM内存中的内容写到持久存储. DDR SSD非常昂贵(以及$$/GB这个级别),以致于目前无法作为专业的数据库设备使用.但是,基于闪存的SSD磁盘越来越称为机械磁盘的一个可行的替代选项. 读,写以及擦写操作 闪存盘存储是按照页(一般为4K)以及块(一般为256K)来组织的.对于读操作来讲,闪存盘可以从单个页(page)快速返回结果.往一个页中写数据要慢很多(可能要慢10倍).然而,只有在块中刚好有一个空闲的页的往页写才能达到这个速度.如果我们需要往整个块写数据,必须先清除块内的内容才可以.维基百科关于SSD的条目给出了下面这个关于查找/写以及擦写的时间: 当一个闪存SSD盘渐渐填满数据时,需要清除操作的块级别的写操作的比例逐渐增加,闪存SSD的写性能也相应下降. TRIM API函数 高端的闪存SSD支持一种叫做TRIM的API,这个功能使得OS可以主动提前清除整个块,从而写操作可以在只有一个页级别的IO内完成.大部分高端的SSD盘还支持一种防磨损算法,这种算法可以在设备上移动热点页以避免块级别出现故障的风险.闪存盘在块变得不可靠之前只支持一定次数的擦写操作,加入磁盘可以自动将热点页在物理存储上移动时,这个缺陷就可以得到缓解. MLC vs SLC 廉价的闪存盘一般都使用MLC(Multi-Level-Cell)技术,它可以实现在一个单元中存储两位的数据,而使用SLC时一个单元中只能保存一位数据.MLC的效果是以牺牲性能的代价来提高数据密度,特别是写性能.从数据丢失的角度讲,MLC也是更加不可靠的.如果你关心写性能,那么或许你应该避免使用基于MLC的SSD. 通常,如果你想要一个高性能的闪存SSD的话(如果它不是高性能的,干嘛还要它呢?),你就应该选择基于SLC的闪存SSD,并且是支持TRIM API以及有着好的防磨损能力的SSD.在我的测试中,我使用一个Intel X-25 E 32GB的SSD盘.它大概需要600澳元(大概534美元). 读写速度差异的问题 假设大部分数据库都是读比写多,我们还需要担心闪存SSD在查找时间与写时间方面的差异吗?毫无疑问答案是YES.对于一个Oracle数据库来讲,当通过Buffer Cache处理事务活动时,一个设备的读能力与往这个设备的写能力之间有很大的不匹配会非常有害. 这个问题与Buffer Cache中的数据的缓存有关.如果往Buffer Cache中放入数据块比从里面写出简单很多,那么Buffer Cache就很可能会被脏块填满,从而出现free buffer waits等待.下图展示了free buffer waits是如何出现的: 如果使用的是廉价的闪存盘,那么写速度就会比读速度慢更多,最终free buffer waits等待将成为事务活动高峰时期的限制因素. Oracle数据库Flash ... http://www.alidba.net/index.php/archives/390 本文翻译自Guy Harrison的blog: More on the database flash cache, 这是他写的关于Flash Cache系列文章的第二篇, 后面还有一篇对比测试Flash Database与Flash Cache的文章, 我也将翻译出来放到此处, 另外还会翻译两篇Kevin Closson写的关于Flash Cache的相关文章. 原文地址: 数据库Flash Cache(II) 数据库Flash Cache(II) 我非常期待我的高性能Flash SSD(一个Intel X-25E),但同时,我已经在一套便宜的硬件设备上(我的前一篇文章中对此做了说明)做了很多数据库Flash Cache的测试. 有时,在较差的硬件上测试新特性也非常有用,因为你可以观察到一些在高速运行的环境下不会发生的现象. 最初,我天真地认为数据块会被Oracle的服务进程拷贝到Flash Cache中.比如,当我从磁盘读取的时候,同时将数据块放到Buffer Cache与Flash Cache中.然而,通过观察,实际情形可能是, 当数据块将要被刷出Buffer Cache的时候, 由DBWR进程将此数据块从Buffer Cache移入到Flash Cache中. 当然,这是一种更好的处理方式.DBWR可以异步的将数据块写入Flash Cache中,从而用户会话可以获得好处,在数据块写入Flash Cache中的时候不需要进行等待(比从磁盘读取耗费更少的时间). 因此,一个数据块可能有一个如下图的生命周期: Oracle服务进程从磁盘读取文件的一个数据块,并将其放到Buffer Cache中 如果一个会话在稍后需要访问这个数据块,并且这个数据块仍然在Buffer Cache中,就可以直接从Buffer Cache中读取这个数据块 在这个数据块离开Buffer Cache之前,DBWR将它写入Flash Cache(如果DBWR不是太忙的话) 如果一个会话稍后需要访问这个数据块,并且它还在Flash Cache中的话,就可以从Flash Cache中读取这个数据块(有可能会将这个数据块放回到Buffer Cache中) 如果这个数据块被修改了,DBWR进程最终会将这个数据块写回磁盘.(问题:Flash Cache中那些没有被修改过的数据块会发生什么呢?) DBWR 与 Flash Cache 从闪存上读取的速度是非常快的,但是往闪存上写就要慢很多了.因此,为了避免性能问题,DBWR进程应该: 1. 不要去写闪存, 除非不得不写,并且 2. ... http://www.alidba.net/index.php/archives/388 不少Google的G1,G2手机用户无法连接802.1X无线网络，我查阅了下网上资料，说是在设计的时候UI。所以无法出现输入USERID，PASSWORD的登录框的缘故。但是可以通过修改配置文件实现。 进入终端,su到root。然后修改 /data/misc/wifi/wpa_supplicant.conf  文件。 在配置文件的末端增加一段： network={ ssid="xxx" proto=RSN key_mgmt=WPA-EAP eap=PEAP identity="xxxx" password="xxxx" phase1="peapver=0" phase2="auth=MSCHAPV2" priority=203 } 把XXXX替换成你的变量即可。然后开启无线网络，那么就OK了。 btw: 谢谢sky友情提供手机，给我参考。谢谢！ http://www.alidba.net/index.php/archives/386 主要的测试代码以及测试方法都依赖于之前翻译的两篇Jonathan Lewis的关于stored outlines的两篇文章: Oracle 8i/9i中的执行计划稳定性 在Oracle 9中伪造存储概要 此文的原文为 针对stored outline做得几个测试 1. 测试场景 os : Red Hat Enterprise Linux AS release 4 (Nahant Update 6) Db Version: Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production 2. 初始化环境. sys@test>@tmp sys@test>create user james identified by james default tablespace users temporary tablespace temp; User created. Elapsed: 00:00:00.00 sys@test>grant create session,create table,create procedure,create any outline,alter session to ... http://www.alidba.net/index.php/archives/382 本文翻译自Guy Harrison的blog: Using the Oracle 11GR2 database flash cache, 这是他写的关于Flash Cache系列文章的第一篇, 后面还有两篇, 我也将陆续翻译出来放到此处, 另外还会翻译两篇Kevin Closson写的关于Flash Cache的相关文章. 原文参见 使用Oracle 11GR2 数据库Flash Cache 使用Oracle 11GR2 数据库Flash Cache Oracle最近发布了一个补丁程序,使得你可以在Oracle Enterprise Linux中使用数据库Flash Cache,即使你并没有使用Exadata存储.这个补丁的名字有点隐晦: 8974084:META BUG FOR FLASH CACHE 11.2PL BUGS TO BACKPORT TO 11.2.0.1 OEL 只要安装好这个补丁,你就可以使用任何已存在的flash 设备作为数据库的Flash Cache.下面是我在一个非常旧的服务器与一个非常便宜的usb flash设备上做的初步尝试.相对于更优质的硬件来讲, 测试结果并不具有代表性,但是我认为,它仍然是很有趣的. 安装与配置 如果你也像我一样想在一个USB flash设备上做试验,那么也必须先挂载这个设备.在我的机器上,我创建了一个目录"/mnt/usbflash",接着在/etc/fstab文件新增了一个如下的条目: /dev/sda1 /mnt/usbflash vfat noauto,users,rw,umask=0 0 0 在你的系统中,你可能需要将"/dev/sda1"改成其他的设备,这依赖于你如何配置磁盘.然后就可以通过输入"mount /dev/sda1"来挂载这个闪存盘(flash drive). 一旦挂载完毕,就可以通过设置系统书db_flash_cache_files与db_flash_cache_size来配置flash ... http://www.alidba.net/index.php/archives/376 译者注: 本文翻译自Jonathan Lewis的文章Faking Stored Outlines in Oracle 9, 可以从此处下载原文的word版本: Stored Outlines in Oracle 9. 本文与前一篇Oracle 8i/9i中的执行计划稳定性是Jonathan Lewis先生写的关于stored outline具体使用以及其中可能涉及到的风险系列文章,也是我所见到的关于stored outline介绍的最详细的文档了. 关于stored outline还有以下相关资料可以对照阅读下: Oracle Outlines - aka Plan Stability By Kerry Osborne Plan stability in 10g - using existing cursors to create Stored Outlines and SQL profiles By Randolf Geist Stored Outlines and Plan Stability By ... http://www.alidba.net/index.php/archives/374