http://www.alidba.net 这里记录着阿里巴巴数据库团队成员的点点滴滴 Thu, 11 Mar 2010 15:55:43 +0000 http://backend.userland.com/rss092 en 图片是网站上很重要的资源，用户发布的产品图片，用户的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 本文翻译自Jonathan Lewis的文章. Plan Stability in Oracle 8i/9i, 可以到此下载这篇文章的word版本. Stored Outlines in Oracle 8 Oracle 8i/9i中的执行计划稳定性 找出如何使用"存储概要"来提高应用的性能的方法,即使你无法修改源代码,调整索引或者胡乱摆弄配置.. by Jonathan Lewis (jonathan@jlcomp.demon.co.uk) 工具箱: 为了测试需要,这篇文章将仅仅涉及可在一个SQL*Plus会话中运行的简单SQL与PL/SQL代码. 读者将需要拥有一些特别的权限(典型的终端用户一般没有这些权限),另外,还需要熟悉一些基本SQL的技能. 本文从Oracle8i开始讲起, 接着讨论Oracle9i, 在9i部分将提供多个针对存储概要的生成与处理的改进. 针对黑盒的后门 如果你是这样一个DBA,在你负责维护的Oracle数据库上运行的是一个第三方应用程序, 你一定曾经遇到这样的困惑, 库缓存(Library Cache)中有一些运行的异常缓慢并且代价高昂的SQL,但是只能在源代码中添加提示才能解决问题. 从Oracle8.1开始,你不再需要重写SQL以添加提示了,可以在不调整代码的情况下使得提示生效.这个特性就是存储概要,也即执行计划稳定性,它的原理也很简单:存储信息到数据库中,告诉数据库"如果发现一条SQL语句与XXX长得像,就将这些提示放到如下这些位置". 实际上,这将给你如下三种可能的好处.首先,可以优化那部分代价昂贵的语句.其次,如果存在一些Oracle需要花费很长时间进行优化(而不是执行)的其他语句,可以利用它来节约时间并降低优化阶段的争用.最后,它为了提供了一个使用新的cusror_sharing参数的机会同时又不用付出失去最优执行路径的损失. 在Oracle8中让它起作用有几个问题需要处理(在Oracle9中大部分哦都去掉了), 但是,通常都可以很容易的利用这个特性. 背景/概述 为了展示如何善用存储概要,我们将从一个包含无法修改源代码的存储过程开始, 显然, 这个存储过程会包含一个运行异常无效的SQL. 我们将看到,我们可以如何捕捉SQL语句以及它在数据库中的当前执行路径的细节,发现一些提示来提高这个SQL的性能,然后, 并且使得这条语句在将来的任何时候运行的时候都使用我们指定的提示. 在下面的展示中, 我们将创建一个用户,在这个用户的Schema中 一张表,并且创建一个存储过程来访问这张表-但是仅仅为了有趣-我们将在这个存储过程上使用工具wrap, 以致我们无法对这段代码做逆向工程. 这个演示将默认存储概要框架已经在数据库创建是自动安装了. 初步配置 创建一个用户并使其拥有如下权限:create session,create table,create procedure,create any outline,以及alter session. 以此用户登录并运行以下脚本来创建表. create table so_demo ( n1 number, n2 number, v1 varchar2(10) ) ; insert into so_demo values (1,1,'One'); create index sd_i1 on so_demo(n1); create ... http://www.alidba.net/index.php/archives/367