分类归档: Database

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 的方式, 哈

Linux 的 Out-of-Memory (OOM) Killer

同事在 Linux 服务器上遇到点小问题，我也上去折腾半天。这还是第一次注意到 Linux 这个多年来就存在的特性：OOM Killer 。说白了 OOM Killer 就是一层保护机制，用于避免 Linux 在内存不足的时候不至于出太严重的问题，把无关紧要的进程杀掉，有些壮士断腕的意思。

先要学习点老知识，在 32 位CPU 架构下寻址是有限制的。Linux 内核定义了三个区域：

# DMA: 0x00000000 -  0x00999999 (0 - 16 MB) 
# LowMem: 0x01000000 - 0x037999999 (16 - 896 MB) - size: 880MB
# HighMem: 0x038000000 - <硬件特定>

LowMem 区 (也叫 NORMAL ZONE ) 一共 880 MB，而且不能改变(除非用 hugemem 内核)。对于高负载的系统，就可能因为 LowMem 利用不好而引发 OOM Killer 。一个可能原因是 LowFree 太少了，另外一个原因是 LowMem 里都是碎片，请求不到连续的内存区域【根据我遇到的一个案例，一个猜想是有些应用一次性请求比较大的内存，恰恰又是 880M 之内的，空闲的(LowFree)不够大，就会触发 OOM Killer 出来干活】。检查当前 LowFree 的值：

# cat /proc/meminfo |grep LowFree

检查LowMem内存碎片：

# cat /proc/buddyinfo

上面这条命令要在 2.6 Kernel 环境下有效。据说使用 SysRq 的方式更好，不过 Hang 的时候再用吧。参见 Metalink Note:228203.1 。

根据一些文档描述，OOM Killer 在 2.4 与 2.6 上表现是不一样的。2.4 的版本中是把新进来(新申请内存)的进程杀掉。而 2.6 上是杀掉占用内存最厉害的进程(这是很危险的，很容易导致系统应用瘫痪)。

对于 RHEL 4 ，新增了一个参数： vm.lower_zone_protection 。这个参数默认的单位为 MB，默认 0 的时候，LowMem 为 16MB。建议设置 vm.lower_zone_protection = 200 甚至更大以避免 LowMem 区域的碎片，是绝对能解决这个问题的(这参数就是解决这个问题出来的)。

而对于 RHEL 3 (Kernel 2.4) 似乎没什么好办法，一个是用 Hugemem 内核(天知道会不会引入新的毛病)，一个是升级到 2.4.21-47 并且使用新的核心参数 vm.vm-defragment 控制碎片的数量。再就是使用 RHEL 4 (Kernel 2.6)，这又绕回去了。说白了，如果遇到 OOM Killer ，基本上是低版本 Kernel 设计上有点缺陷。

其它，如果去查询 RedHat 的 Bug 库，会发现不少 Kernel 版本也有 Bug 的。尤其在使用 NFS 的场景。

Tip: OOM Killer 的关闭与激活方式：

# echo "0" > /proc/sys/vm/oom-kill 
# echo "1" > /proc/sys/vm/oom-kill

更多参考信息:

1) OOM killer “Out of Memory: Killed process” SOLUTIONS / SUMMARY【对我遇到的案例没鸟用】
2) Metalink Notes : Linux Kernel Lowmem Pressure Issues and Kernel Structures
3) Respite from the OOM killer

–EOF–

头疼欲裂，零散记录点东西，备查。

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–