Tag Archives: Database

Oracle CBO 的 _sort_elimination_cost_ratio 参数

连续看到几个和 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

JDBC 的 setTimestamp 性能问题

偶然发现三年前的一个技术问题。当时比较匆忙,避免掉即过去了。现在 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

这么多的 Oracle 性能工具

偶然看到 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! 的收购持久战可能让很多人都新闻疲劳了。但今天看到的这个关于 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