Entries tagged with “Database” from DBA notes

RAID(Redundant Array of Independent Disks)，是现在 SAN 存储的非常核心的概念，可能很多朋友都熟悉的。这里介绍一个比较旧的新词：RAIDb 。所谓 RAIDb 也就是 Redundant Arrays of Inexpensive Databases (Db)。

RAIDb 其实是和 Sharding 技术概念有些地方是相通的。如果看概念上的验证还可以看 MySQL DRBD 的解决方案。 这个概念似乎较早见于 C-JDBC 的设计说明，不过近年来也被一些新的解决方案所引用。(比如sequoia）。

RAIDb-0

表级别. 类似数据库的分区，但 RAIDb-0 是不同表之间，RAIDb-0 不提供容错机制。RAIDb 控制器是整个 RAIDb 的核心。这一组件决定 RAIDb 的可靠性、可用性。

RAIDb-1

DB 的镜像或者复制。也是至少需要两个后端 DB 节点。具备容错机制。和 RAID-1 类似，写操作会慢一点。因为是全复制或者镜像，所以对存储空间的需求是比较大的。

RAIDb-2

部分复制，算是前两种方式的折衷。

RAIDb-1-0

RAIDb-0-1

示意图乍看起来是一样的，RAIDb-1-0 与 RAIDb-0-1 的主要差异在控制器(controller)上。

RAIDb 概念把数据库水平切分的思想抽象出来一个很好的模型。旧瓶装新酒，只要调制合理。

--EOF--

连续看到几个和 Oracle 优化器隐含参数 _sort_elimination_cost_ratio 相关的优化案例(Refer Refer )。

如果用 _SORT_ELIMINATION_COST_RATIO 作为关键字在 Metalink 上查询，会发现很多和该参数有关的 Bug ，执行计划的出错特征是也走了索引，但是走了索引全扫描(INDEX FULL SCAN)，如果做 10053 Trace ，会发现有个烦人的 Recost for ORDER BY 步骤，然后就会引到错误的执行计划上。

在 9i 升级到 10g 最容易遇到这个问题(原来好好的，到了 10g 发现执行计划有问题了). 出问题的 SQL 一般是走 INDEX RANGE SCAN 然后有个 ORDER BY 会触发，更多的时候优化器模式是 FIRST ROWS -- 这样 Oracle 会尽量消除排序，默认认为排序是开销昂贵的操作。通过控制 _SORT_ELIMINATION_COST_RATIO 隐含参数的值 (默认是0) 能够解决这个问题：

ALTER SESSION SET "_SORT_ELIMINATION_COST_RATIO"=5 

其它可能的解决办法：对索引里面的排序保持和 SQL 里的 ORDER by 一致。

其实说白了，很多 Oracle 隐含参数就是为了解决 Oracle 特定情况下的 Bug 的，因为不具备普遍性，所以在某些版本中作为隐含参数出现。在生产数据库上，个别的时候启用隐含参数倒也不是不行的，只要明白了相应的隐含参数到底是干啥的就成了。

题外话：_SORT_ELIMINATION_COST_RATIO 相关的 Bug 频繁出现，倒是感觉和 Oracle 内部代码管理有关，本来应该消除掉的，怎么后面的版本又跑了出来?

目前关于 CBO 最好的书籍应该是Jonathan Lewis 的 Cost-Based Oracle Fundamentals ，有中文译本：《基于成本的Oracle优化法则》。是 DBA 不可错过的一本书。

--EOF--

偶然发现三年前的一个技术问题。当时比较匆忙，避免掉即过去了。现在 Metalink 上其实已经把这个问题作为一个 Bug 处理了。

问题描述：通过 JDBC 上来的 Java 查询应用，SQL 表现异常。表字段使用了 DATE 类型，针对该字段时间区域很小的范围查询(预期应该是走 INDEX RANGE SCAN)，在 SQL Map 上指定索引，发现无效。仍然是 FULL TABLE SCAN (FTS)。

罪魁祸首：setTimestamp() 把值绑定为 TIMESTAMP 类型，这样和 DATE 类型比较的时候，CBO 就会选择全表扫描。

通过 Trace 能观察到该异常行为。TIMESTAMP 在 Oracle 的 JDBC 9.2.0.1 上就有了，连续几个版本其实都有类似的问题。

解决办法：使用 setString() 而不是 setTimestamp() 方法。

这个故事告诉我们，Oracle 的 JDBC 驱动程序其实问题挺多的。同样，TIMESTAMP 潜在的问题也不少，尽管这个数据类型已经出现多时。

--EOF--

偶然看到 Tanel Poder 提到的一个 Metalink Note (438452.1): Performance Tools Quick Reference Guide 。这文档倒的确挺新，其中有几个工具值得关注一下。

LTOM：The Lite Onboard Monitor

Java 程序，定位是"实时诊断平台"。具有自动 Session 跟踪特性。另外具备自动 Hang 检测，自动数据收集等功能。该工具应该对于 Oracle 技能不太强的中小用户有比较大的帮助。但对于比较关键的系统，恐怕都不太放心跑一个 Java 程序在数据库上。

OPDG：Oracle Performance Diagnostic Guide

类似决策树的一个工具，访问的时候要打开个 Java 虚拟机，以我这样的网速根本访问不到(到了 22% 就停掉了) 。不知道等着着用这个工具的用户会急成什么样。

TRCANLZR：Trace Analyzer

格式化原始的 SQL Trace 数据，以 HTML 形式展现给用户。

HANGFG ：Hang file generator

用以收集系统 Hang 住时的状态信息。看来，Oracle 出问题比较多的时候还是系统 Hang 啊 :)

除了这几个，还有 STACKX ，用以分析 Core 文件的内容；还有以前大家都知道的 OS Watcher ，现在也做了一些改进。这个软件包基本上是 Unix 的那些传统的性能工具加上比较有好的图表展现脚本。

应该说随着 Oracle 开发、开放更多的性能相关的工具出来，对于有一定经验的 DBA 来说，会有个很好的辅助作用。对于经验不够丰富的用户来说，不是缺少工具，而是即使有性能数据，也不知道如何分析，如何定位。

--EOF--

偶然发现，Metalink 对于文档的关键字也是用 Hint 的方式, 哈

微软对 Yahoo! 的收购持久战可能让很多人都新闻疲劳了。但今天看到的这个关于 Yahoo！ 的技术新闻还是值得看一下的：Size matters: Yahoo claims 2-petabyte database is world's biggest, busiest 。Yahoo! 的 VP Waqar Hasan 在文中披露 Yahoo！的数据仓库当前容量为 2PB。用于分析每月5亿的用户访问行为，每天处理 240 亿次的事件，号称世界上单个最大、最忙的数据库。

尽管有的数据仓库容量要比雅虎的大。但那些 DB 或是存储非关系性数据，或是存储的压缩后的原始数据，不能进行即时分析，雅虎之前的也有数百 T 这样的数据。眼下 Yahoo！数据仓库存储的是结构化、可分析的数据。预计下一年可能膨胀到数十 PB 。eBay 号称数据总量有 6PB ， 不过根据一些消息来看，单个最大的 DB 只有 1.4 PB。

Yahoo! 在 2005 年买了一家叫 Mahat Technologies 的初创公司（就是 Waqar Hasan 操刀的)，这家公司以 PostgreSQL 数据库为基础，开发了一个新型 DB，其特点是 基于列 的而不是 基于行 的模式。不难理解，这样数据写入的速度会慢下来，但是读取的速度会快很多【去年的侠客行上，雷鸣在演讲的时候讲过他在百度的时候做的一个优化的例子。和这个思想非常相似，所以当时我说对我"有启发"】。Yahoo! 买了之后，对该产品进行了持续性的改进(内部代号: ELCARO ?) ，比如压缩，并行处理能力加强、优化查询等等特性的添加改进。而针对使用者的接口仍是 PostgreSQL 。这应该也算 PostgreSQL 在顶级企业又一个成功案例。

这么大的数据库并没有采用传统的 SMP 架构构建，而是采用普通 PC 作集群(用了不到 1000 台) 。很明显这是 Share Nothing 而不是 Share Storage 的 DB 集群。通过上述独特的设计方式，能够对此海量数据进行有效的分析，这是个不小的技术革新，也是与 Google Map Reduce 完全不同的计算模式。

让人感慨的是 关于世界上的超大数据库 一文中罗列的数据，现在看起来已经并不惊人了。以前总说信息爆炸，这个时代刚刚来临。

--EOF--

MySQL 爱好者关注的 2008 MySQL Conference & Expo 落幕后，很多文档都能看到了。今天读了一下这篇 Scaling Out MySQL: Hardware Today and Tomorrow。感兴趣的朋友也不防下载下来研究一下。

用什么样的硬件做 MySQL ，真不是三言两语能说清楚的。不过该讲座中还是能总结出来几点关键点的。

CPU 选择

首先如有可能就选择 64 位CPU，这样才可以安装 64 位操作系统，有了 64 位操作系统才能利用好更大的内存。如果非要抬杠的话，不是 64 位芯片也可以安装 64 位操作系统，也就是 Intel 的 EM64T 的解决方案(这也是文档中没提及的) 。

我个人倒是比较喜欢 AMD 64 位 CPU 的，物美价廉，性能也不错。

注意： MySQL 在多核上的 Bug 问题。

内存，来者不拒

第二点是尽可能配置比较大的内存，当然，只配置内存如果 MySQL 参数配置有问题，还是摆设，如何设置各个引擎的 Cache 相关参数，够写一本书的了。

现在市场上内存是越来越便宜了。我个人的感觉内存降价的程度比 CPU 和硬盘都夸张很多。所以，考虑到人力越来越贵，内存越来越便宜，配置服务器的时候就别太吝啬了。

硬盘--唯快不破

国内用 MySQL ，绝大多数都是直接仍在本机磁盘上的。这个磁盘的选择要慎重一点点。尽量选择 15K 而不要 10K 慢速磁盘，大多数数据库的磁盘问题都在速度上，如果只在磁盘上多花费 30%的钱而能得到总体性能的 30％收益，那么还是值得的，而容量多数情况下不会出现问题，现在的硬盘容量就是一个大。

至于选择什么类型的磁盘，SCSI 与 SAS 都可选，SATA 倒是够便宜，特定的应用再考虑吧。

这三板斧看是简单活，但是实际的应用场景下可未必就能做出更优的选择。最简单的东西也有人不知道不是?

--EOF--

一个很有意思的技术嫁接。Pythian 发布了一个 MySQL 插件，通过该插件，Oracle 10g 的 Enterprise Manager Grid Control 能够用来管理 MySQL 。

在 Oracle 10g 刚发布那会儿，EM 的地位在整个链条中倒是挺重要的，几年下来，似乎并没有占领多少市场。我个人觉得这个工具挺"重"的，倒是很少看到有 DBA 用这个工具。

尽管这个 MySQL 插件应用场景可能不多，但这还是第一次看到第三方给 Oracle EM 带来扩展能力。

比较关注即将召开的 The 2008 MySQL Conference & Expo，Sun 收购 MySQL 之后第一次大规模亮相，能带来什么? 新版本的特性基本了解了，还有呢?

Updated: InnoDB Plugin 1.0 for MySQL 5.1 也需要关注一下。

--EOF--

今天在无聊的售前演示中看完了一篇技术文档 All About Oracle's In-Memory Undo，关于 Oracle 的 In-Memory Undo (IMU)，记得几年前讨论过，大部分基于猜测，这算是看到的第一篇比较细致的东西。

Oracle 公司在 10g 推出 IMU 这个特性（已经申请了专利）。Undo 作为最重要的组成部分之一，其高效与否直接关系到整个 DB 的能力。Undo 旧有的基于 Block 的段(Segment，指存储层的概念)管理模式方式，UNDO 本身的变化要记录到 Redo Log Buffer 里，而 IMU 避免了这个操作(因为是内存而不是存储)，从而减小了生成的 Redo 量。

另外，因为读一致性开销直接到了内存里而不再依赖存储段, 整体也大大降低，CPU 的负荷也会有效降低。其应用模式应该说是适合一致读的需求量比较大的 OLTP。

Oracle 10g 默认是使用 IMU 这个特性的。通过隐含参数 _in_memory_undo 可以关闭这个特性。因为是隐含参数，也侧面反映出该特性并非那么成熟。搜索一下 Metalink，有不少关于 IMU 的 Bug，而 UNOD 的 Bug 一旦遇到，不停 DB 恐怕都很难解决。所以，对于可用性要求比较高的系统，现在起用该特性还是需要三思。

附: 全部机制在专利全文里。谁有兴趣仔细读一下吧.

--EOF--

从 Laurent Schneider 的 Blog 看到信息，Oracle 10gR2 的第三个 PatchSet 10.2.0.4 已经出来了。虽然还没有正式宣布，但是在 Metalink 上已经能够看到 Linux 平台的了。PatchSet 号码为：6810189 。

现在 Oracle 的 PatchSet 出来的顺序基本上还是 Linux 是第一个，也反应了某种趋势。若干年前都是 Solaris 平台 上最早出来的，现在都变成 Linux 了，操作系统的流行变迁可见一斑。原来传言说 2007 年年底会发布的 ，还是拖到了现在才看到，难道 Oracle 的开发力量都投入 11g 上面去了?

有意思的是，10.2.0.4 Patch Set - List of Bug Fixes by Problem Type 这个列表下仍然写着 “Please note that 10.2.0.4 has not been released on any platform , and does not have release dates available" 。可见 Oracle 内部对文档的更新也是比较乱的。

期待这个版本在修复众多 Bug 的同时不要引入新的 Bug 了，Oracle 10g 在稳定性上还是不能让人放心，淘宝的兄弟们最近就因为 ASM 的 Bug 而折腾了一回。。11g 会好一些么?

对于 DBA ，尤其是 Oracle DBA 来说，厂商发布一个新的 PatchSet 要比发布一个新的版本来的更为实惠一些，因为前者面向解决现有存在的 Bug 问题。新的版本只会引入更多的问题。

--EOF--

有句俗话说的好，”当你手里拿着锤子的时候，整个世界都成了钉子“，数据库理论专家 David DeWitt 也闹这毛病，他的这篇 MapReduce: A major step backwards 差不多快成最近几天技术圈子的一个笑料了，连久不更新的汪海都来了兴致写了一篇评论。

有的时候我怀疑是不是国外这些学院派的教授也和国内这些老学究差不多，固步自封? 估计 David DeWitt 被一群实践派的后生小子当作笑话消遣肯定很恼火，期待他后续的回击。其实话说回来，RDBMS 理论这么多年来基本上也就是搞些"老树成精"的研究，真正转入实际应用的理论怕是真不多，VLDB、BI 方面貌似繁荣，其实也就那么回事。就拿 Oracle 来说（汪海说了：千万不要对自己不熟悉的东西妄加评论），在这几年的 VLDB Endowment 上，发布的论文寥寥。实际在产品中起用的技术就更少了。

2008 年 IT 业第一个大收购: Sun 宣布 10 亿美元收购 MySQL AB, 8 亿现金加上 2 亿股票，MySQL 把自己卖掉了。

MySQL 最近几年一直喊着要 IPO 来着，谁知道突然甩手把自己卖掉了。难道 MySQL 就这么大一点志向么? 还是投资者急于套现? "LAMP" 的 "M" 以后是 Sun 家的了，Sun 能否把 “LAMP" 变成 "SAMP" ? S-Solaris，这恐怕只能是个假设而已, Solaris 在开放上慢了一步，这一步可就被 Linux 甩的太远了。

话说回来, Sun 这几年可真的是日薄西山。这笔买卖恐怕也是“驴粪蛋--表面光”，真正能带来多少收益恐怕天知道，要知道 MySQL 07 年的收入恐怕也就是 5 千万上下。Sun 一向是活雷锋, Java 造福了这么多公司，就自己不赚钱。希望能继续发扬该精神，让 MySQL 能够继续为 Web 2.0 公司提供数据支撑，要知道现在的 Web 2.0 公司至少有 9 成都在大量使用 MySQL 啊。哦，难不成 Sun 是看中了这块的硬件市场?

Sun 会继续保持 MySQL 开源，这是毫无疑问的。但我也相信众多 MySQL 用户这下子要考虑一下使用策略了。

MengYan 提醒我说 "别忘了 Sun 要做 .com 中的那个 Dot "，的确，当年的 .com 大潮中，Sun 风头无两；这么一说，Sun 的意图就比较明显了，这回Sun 要做 Web 2.0 中的这个 Dot.

--EOF--

Amazon 真是酷到家了。在 S3 和 EC2 之后又搞出来一个 SimpleDB™ 。Amazon 一手构造的计算环境中现在又加上了数据库，真是很有想象力的项目。

在 Web Service 上，Amazon 可以说是身体力行，领跑多年。S3 解决海量数据(非结构化)托管问题(虽然当下也是赔本赚吆喝)，EC2 解决企业计算问题，SimpleDB™ 则针对结构化数据查询的解决方案，目前已经能够提供数据库的一些核心功能。对用户来说，你不再需要针对数据库的复杂的维护工作，也就是可以不用数据库管理员( DBA ) 了 。当然，DBA 也不用担心，这个工种不会消失，SimpleDB™ 针对的买方是那些只需用简单的关系型数据的 Web 项目，传统的 RDBMS 功能复杂，但是很多小项目其实只是用到一些核心的功能而已，如大家常说的增、删、改、查，这或许也是帕累托法则的运用吧。

RDBMS 当然不会消亡，SimpleDB™ 是 RDBMS 的竞争对手，也是 RDBMS 的一个补充(我非常奇怪为什么不叫做 WebDB，嘿)。从这一点上说，SimpleDB™ 还是开启了一片蓝海，只是海水比较深，没有足够技术船也过不去。

--EOF--

BTW: 虽然这个消息已经被很多人写了，我还是想写一下，毕竟这也是关于 DB 的事情

Updated: 小道消息，”SimpleDB stuff is Erlang on top BerkleyDB“，如果这么说，或许 Oracle 偷着乐呢

经常要对一些新存储系统进行 I/O Benchmark 测试，每次测试又有可能针对不同的目的，但基本也都是围绕数据库转悠，心血来潮，对几个常见的工具做个比较。

(点击查看全图)

要强调的几点: ORION --Oracle I/O Numbers Calibration Tool 还是比较全面的针对数据库应用的 IO 测试工具。现在 Oracle 发布了不少平台的移植版本。该工具也比较好用。

数据库应用必需要考虑异步 I/O 的因素，否则结果会有很大偏差，当然如果只测试存储能力的话，到可以忽略。AIO 压力测试可以考虑以下 AIO-Stress

Unix 命令 dd 虽然很土，但还是一个测试 I/O 的基本手段和方法.有的时候即使没别的工具只用它也能发现很多问题。另外一个需要注意的就是字符设备和块设备的差别啦。更新: 就当我说得是 GNU dd 吧，谢谢下面留言的朋友。

有些工具因为用过很久了，记忆难免有问题，表格中会有误导。仅供参考。今天太累，等有空继续补充内容。

--EOF--

BTW: 我收集的关于 Benchmark 的书签 内容。

尽管是世界上最大的图片服务网站, Fotolog.com 在国内的名气并不是很响亮, 每当提到图片服务, 很多人第一个会想起 Flickr. 但实际上 Fotolog 也的确是很猛的, Alexa 上的排名一直在 Flickr 前面, 目前注册用户超过 1100 万. 而前不久也卖了一个好价钱, 9000 万美金. 算下来的话, 1 个注册用户大约 9 美金. Yupoo 的刘平阳可以偷着算算自己的网站如果卖给老外是怎样一个价格了.

在前不久的 MySQL Con 2007 上, Fotolog 的 DBA Farhan Mashraqi 披露了一些技术信息.（PPT下载)

与其他大多数 Web 2.0 公司普遍用 Linux 不同的是, Fotolog 的操作系统用的是 Solaris . Solaris X86 也是免费的, 估计是维护人员更熟悉 Solaris 的操作系统而作出的选择吧.

数据库当然是使用 MySQL. 有32 台之多, 最开始的存储引擎是 MyISAM ,后来转向 InnoDB. 对于 DB HA , 使用 DRBD (介绍)，在 Solaris 上用 MySQL ,有个优化技巧是关于 time(2) 系统调用的，通过调用比 gethrestime() 更快的 gethrtime(3C) 来提高性能。可以通过设置 LD_PRELOAD (32位的平台) 或 LD_PRELOAD_64 来做到。详细信息可以参考Sun 站点上的这篇 MySQL 优化文章，很有参考价值。

存储也是值得一说的，Fotolog 用的是 SAN，还是比较贵的 SAN: 3Par. 这个产品可能绝大多数 DBA 是比较陌生的，该产品原来主打金融市场，现在也有很多 Web 公司使用，一个比较典型的客户代表是 MySpace。3Par 的最大的特点就是 Thin Provisioning。Thin Provisioning 这个词有的人翻译为"自动精简配置"，在维基百科的定义：

Thin provisioningis a mechanism that applies to large-scale centralized computer disk storage systems, SANs, and storage virtualization systems. Thin provisioning allows space to be easily allocated to servers, on a just-enough and just-in-time basis.

说白了就是对空间分配能够做到"按需分配"。有些扯远了。

--EOF--

如果用关键字 "MySQL 迁移 Oracle" 在网上搜索，基本上得到的内容都是关于从 Oracle 如何迁移到 MySQL 的，而从 MySQL 迁移到 Oracle 的信息则少之又少。

抛开那些手工一点点做的方法不谈，网络上也可以找到一些第三方工具来做这个事情，免费的? 我只找到了一个，那就是 Oracle SQL Developer 了。如果采用比较傻瓜化的方法，不妨考虑这个工具。在这个工具之前，Oracle 提供了单独的 Migration Workbench 工具。在 SQL Developer 1.2 版中，Oracle 干脆把这个功能集成进来。

数据流示意图:

Source Database(MySQL/DB2 etc.) --->SQL Developer (ETL)-->Target Database (Oracle)

MySQL JDBC 下载地址：

http://dev.mysql.com/downloads/connector/j/5.0.html

配置 MySQL JDBC:

还需要注意一点就是需要调整一下迁移时候的参数:

剩下的事情就简单了，配置到不同数据库以及准备存放 Metadata 数据库的信息。然后就可以迁移了。不赘述。

这个方法只是够傻瓜化，由于运行机制的限制，速度不是非常好。对于迁移过程中产生的变化数据，也无能为力。

--EOF--

今天参加 AIX 的技术培训，听了一些关于 CPU 调度的算法，倒也都是些基本知识，回想讲课内容的时候倒让我想起 Linux Kernel 的 I/O Scheduler 来。

这篇 Choosing an I/O Scheduler for Red Hat Enterprise Linux 4 and the 2.6 Kernel 是必须的参考资料。相比 Linux 2.4 Kernel 的一种 IO 调度器，2.6 做了很多改进，共有四种 IO 调度器。

Deadline scheduler

Deadline scheduler 用 deadline 算法保证对于既定的 IO 请求以最小的延迟时间，从这一点理解，对于 DSS 应用应该会是很适合的。

Anticipatory scheduler

Anticipatory scheduler（as) 曾经一度是 Linux 2.6 Kernel 的 IO scheduler 。Anticipatory 的中文含义是"预料的, 预想的", 这个词的确揭示了这个算法的特点，简单的说，有个 IO 发生的时候，如果又有进程请求 IO 操作，则将产生一个默认的 6 毫秒猜测时间，猜测下一个 进程请求 IO 是要干什么的。这对于随即读取会造成比较大的延时，对数据库应用很糟糕，而对于 Web Server 等则会表现的不错。这个算法也可以简单理解为面向低速磁盘的，因为那个"猜测"实际上的目的是为了减少磁头移动时间。

Completely Fair Queuing

虽然这世界上没有完全公平的事情，但是并不妨碍开源爱好者们设计一个完全公平的 IO 调度算法。Completely Fair Queuing （cfq, 完全公平队列) 在 2.6.18 取代了 Anticipatory scheduler 成为 Linux Kernel 默认的 IO scheduler 。cfq 对每个进程维护一个 IO 队列，各个进程发来的 IO 请求会被 cfq 以轮循方式处理。也就是对每一个 IO 请求都是公平的。这使得 cfq 很适合离散读的应用(eg: OLTP DB)。我所知道的企业级 Linux 发行版中，SuSE Linux 好像是最先默认用 cfq 的.

NOOP

Noop 对于 IO 不那么操心，对所有的 IO请求都用 FIFO 队列形式处理，默认认为 IO 不会存在性能问题。这也使得 CPU 也不用那么操心。当然，对于复杂一点的应用类型，使用这个调度器，用户自己就会非常操心。

那么如果跑数据库应用，那个更好一些呢? 我们看Choosing an I/O Scheduler for Red Hat Enterprise Linux 4 and the 2.6 Kernel一文中的测试结果:

对于数据库应用, Anticipatory scheduler 的表现是最差的。Deadline 在 DSS 环境表现比 cfq 更好一点，而 cfq 综合来看表现更好一些。这也难怪 RHEL 4 默认的 IO 调度器设置为 cfq. 而 RHEL 4 比 RHEL 3，整体 IO 改进还是不小的。

哪一种方式更好? 很难说，每一种方式都有特定的应用对它是最适合的。就像上面的 as 好像表现比较差，如果是 CPU 密集型的应用呢?

Tip:
Q:如何确认当前用什么 IO 调度器?
A: 过滤 /var/log/boot.msg 文件, 查找 "io scheduler", 看到了么?

在 操作系统上可以查到的相关文档：
/usr/src/linux/Documentation/block/as-iosched.txt
/usr/src/linux/Documentation/block/deadline-iosched.txt

这篇文章应该只是一篇草稿...

--EOF--

这是我的 Oracle 11g 系列的文章之一.

Oracle 11g SQL*Plus 也有不少新功能，这个 Error Logging 的新功能很有趣，也比较实用。当激活该功能后，可以记录 SQL*Plus 操作相关错误信息到具体的数据库表里面，对于以后追查很方便。激活的语法如下：

SQL> set ERRORLOG ON
SQL> desc SPERRORLOG
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 USERNAME                                           VARCHAR2(256)
 TIMESTAMP                                          TIMESTAMP(6)
 SCRIPT                                             VARCHAR2(1024)
 IDENTIFIER                                         VARCHAR2(256)
 MESSAGE                                            CLOB
 STATEMENT                                          CLOB

激活的时候会自动创建这个表。然后即可存储 ORA、PLS 与 SP2 类型的错误信息。

SQL> drop ttt ;
drop ttt
 *
ERROR at line 1:
ORA-00950: invalid DROP option
SQL> select username,timestamp,message from SPERRORLOG;
USERNAME   TIMESTAMP                      MESSAGE
---------- ------------------------------ ----------------------------------------
SCOTT      25-AUG-07 02.22.09.000000 PM   ORA-00950: invalid DROP option

除此之外，亦可自行定制表，进一步定制存储错误信息。

默认情况下该选项是关闭的。另外，为避免递归调用错误记录, internal 错误不被记录.

--EOF--

在西雅图扩展性的技术研讨会上，YouTube 的 Cuong Do 做了关于 YouTube Scalability 的报告。视频内容在 Google Video 上有(地址)，可惜国内用户看不到。

Kyle Cordes 对这个视频中的内容做了介绍。里面有不少技术性的内容。值得分享一下。(Kyle Cordes 的介绍是本文的主要来源)

简单的说 YouTube 的数据流量, "一天的YouTube流量相当于发送750亿封电子邮件.", 2006 年中就有消息说每日 PV 超过 1 亿,现在? 更夸张了,"每天有10亿次下载以及6,5000次上传", 真假姑且不论, 的确是超乎寻常的海量. 国内的互联网应用,但从数据量来看,怕是只有 51.com 有这个规模. 但技术上和 YouTube 就没法子比了.

Web 服务器

YouTube 出于开发速度的考虑，大部分代码都是 Python 开发的。Web 服务器有部分是 Apache， 用 FastCGI 模式。对于视频内容则用 Lighttpd 。据我所知，MySpace 也有部分服务器用 Lighttpd ，但量不大。YouTube 是 Lighttpd 最成功的案例。(国内用 Lighttpd 站点不多，豆瓣用的比较舒服。by Fenng)

视频

视频的缩略图(Thumbnails)给服务器带来了很大的挑战。每个视频平均有4个缩略图，而每个 Web 页面上更是有多个，每秒钟因为这个带来的磁盘 IO 请求太大。YouTube 技术人员启用了单独的服务器群组来承担这个压力，并且针对 Cache 和 OS 做了部分优化。另一方面，缩略图请求的压力导致 Lighttpd 性能下降。通过 Hack Lighttpd 增加更多的 worker 线程很大程度解决了问题。而最新的解决方案是起用了 Google 的 BigTable， 这下子从性能、容错、缓存上都有更好表现。看人家这收购的，好钢用在了刀刃上。

出于冗余的考虑，每个视频文件放在一组迷你 Cluster 上，所谓 "迷你 Cluster" 就是一组具有相同内容的服务器。最火的视频放在 CDN 上，这样自己的服务器只需要承担一些"漏网"的随即访问即可。YouTube 使用简单、廉价、通用的硬件，这一点和 Google 风格倒是一致。至于维护手段，也都是常见的工具，如 rsync, SSH 等，只不过人家更手熟罢了。

数据库

YouTube 用 MySQL 存储元数据--用户信息、视频信息什么的。数据库服务器曾经一度遇到 SWAP 颠簸的问题，解决办法是删掉了 SWAP 分区! 管用。

最初的 DB 只有 10 块硬盘，RAID 10 ，后来追加了一组 RAID 1。够省的。这一波 Web 2.0 公司很少有用 Oracle 的(我知道的只有 Bebo,参见这里). 在扩展性方面，路线也是和其他站点类似，复制，分散 IO。最终的解决之道是"分区",这个不是数据库层面的表分区，而是业务层面的分区(在用户名字或者 ID 上做文章,应用程序控制查找机制)

YouTube 也用 Memcached.

很想了解一下国内 Web 2.0 网站的数据信息,有谁可以提供一点 ?

--EOF--

Oracle 10g 的 ASM (自动存储管理) 真是一把双刃剑，对于存储的管理给 DBA 带来了不少便利，可也存在无穷多的问题。

ASM_POWER_LIMIT 参数

这个参数 ASM_POWER_LIMIT 参数控制 ASM 后台进程 ARBx 的数量。ARBx 进程用来进行 ASM 磁盘数据重新分布打散。ASM_POWER_LIMIT 取值 从 0 到 11(据说从 10gR2 开始可以设置为 0 ). 当新添加磁盘或者删除磁盘后，ASM 会启动 ARBx 进行 IO 分散操作，这是个非常消耗资源的动作，所以一定要选择系统空闲的时候进行。

关于 ASM 的条带与分配单元

ASM 默认的 Stripe Size 为 128K。 (一般操作系统的一个 IO 最大是 1M，对于 Block Size 为 8K 的系统，一般来说，db_file_multiblock_read_count 设置为 16 即可)。分配单元（ Allocation Unit ） 是 1M，这个 AU 对应 extent 。在一些 DW 环境，随着数据量增大，AU 会非常的多，会产生性能影响。Stripe Size 和 AU 是可以通过 ASM 实例上的两个隐含参数调整的：

• _asm_ausize
• _asm_stripesize(注意最大1M，否则会有负面影响)

磁盘组不能 mount

ORA-15063: ASM discovered an insufficient number of disks for diskgroup "FOO"

• 对磁盘组中的设备进行 dd 操作抹去磁盘 0 块的内容
• 用 FORCE 选项把磁盘添加到其他磁盘组中。
• 用 FORCE 选项用所有这些磁盘创建新的磁盘组。

--EOF--

在过去的 Blog 中, 我(插一嘴：这里的"我" 如果替换成 "Fenng" 似乎有些自恋, 也不是我喜欢的行文语气, 可发现转贴不留名的行为太多了,他大爷的)曾经介绍过 《eBay 的应用服务器规模》 , 也介绍过 《eBay 的数据量》，在这篇文章中提到过 "eBay 购买了 Quest Share Plex 全球 Licence 用于数据复制"，这个地方其实没有说开来。

对于 eBay 这样超大规模的站点来说，瓶颈往往最容易在数据库服务器上产生，必定有一部分数据(比如交易记录这样不容易水平分割的数据)容易带来大量的读操作，而不管用什么存储，能承担的 IO 能力是有限的。所以，如果有效的分散 IO 的承载能力就是一个很有意义的事情。

经过互联网考古学不断挖掘，路路续续又现了一些蛛丝马迹能够多少说明一些问题。客观事实加上主观想象，简单的描述一下。见下图：

通过 Quest 公司的 Share Plex 近乎实时的复制数据到其他数据库节点，F5 通过特定的模块检查数据库状态，并进行负载均衡，IO 成功的做到了分布，读写分离，而且极大的提高了可用性。F5 真是一家很有创新性的公司，虽然从这个案例来说，技术并无高深之处，但方法巧妙，整个方案浑然一体。

F5公司专门为Oracle 9i 数据库开发了专用的健康检查模块，通过调用F5专有的扩展应用校验(EAV)进程，F5能够随时得到Oracle 9i数据库的应用层服务能力而不是其他的负载均衡设备所采用的 ICMP/TCP 层进行健康检查。

这个图来自一篇《F5助力eBay数据库服务器负载均衡》的软文，真是一篇很好的软文，国外恐怕不会出现这样"含金量"极高的东西。

当然，这个技术架构可不算便宜。Quest 的 Share Plex License 很贵，而且，对于每个结点来说，都需要数据库 License 与硬件费用。但优点也很多：节省了维护成本; 数据库层面的访问也能做到 SOA; 高可用性。

国内的一些厂商比较喜欢给客户推存储级别的解决方案。通过存储底层复制来解决数据分布以及灾备问题。这个思路似乎太传统了，对于互联网企业来说多少有点过时。

BTW: 对 Amazon 的存储架构非常感兴趣，谁/哪里能提供点线索呢?

--EOF--