分类归档: Database

Google 助力 MySQL

MySQL 应该给 Google 发感谢信: Google 在 Google Code 上发布的 Google Mysql Tools 使得 MySQL 在性能、可管理性、稳定性上都增色不少。

在该项目的首页将这个工具集分为三部分:

* mypgrep.py - a tool, similar to pgrep, for managing mysql connections
* compact_innodb.py - compacts innodb datafiles
by dumping and reloading all tables
* patches - patches to add features to MySQL 4.0.26 and MySQL 5.0.37

这份介绍似乎已经不能完全概括 Google Mysql Tools 了。现在的重点似乎是补丁包部分。根据版本号分为 MySQL4 与 MySQL 5,MySQL 5 的 Patch 现在很少,而 MySQL 4 部分内容真的比较丰富,关键改进列表:

* SemiSyncReplication – block commit on a master until at least one slave acknowledges receipt of all replication events.
* MirroredBinlogs – maintain a copy of the master’s binlog on a slave
* TransactionalReplication – make InnoDB and slave replication state consistent during crash recovery
* UserTableMonitoring – monitor and report database activity per account and table
* InnodbAsyncIo – support multiple background IO threads for InnoDB InnoDB 异步IO的支持相信对性能会有很明显的提升
* FastMasterPromotion – promote a slave to a master without restart

MySQL 在联机备份方面是弱势,倒是期待 Google 也能在这个方面做出改进(我非常好奇对于 Google Checkout 数据库是如何备份的).

在 Code 上的另外一个 关键项目 Google Perftools 中的 TCMalloc 对 MySQL 的性能也有很大的改进,相信国内很多出色的 Web 2.0 公司都已经用到这个东西了吧。TCMalloc : Thread-Caching Malloc 号称是目前最快的 Malloc ,对于解决 MySQL 遇到的 Malloc 扩展问题有很大的影响。

没有 Google 的支持,相信 Firefox 不会有现在这么大的影响力。有了 Google 的支持, MySQL 会发展多快 ?

EOF

Updated: 2008 年 9 月,Google又发布了一系列的新 Patch

导致 Oracle 10gR2 出现 ORA-39095 的另一种原因

Oracle 10g R2 的 Data Pump 是一个好工具,弥补了传统 export/import 工具的很多不足。相关信息可以参考一下我以前对 Data Pump 的介绍
最近在 Linux 平台上经常遇到 ORA-39095 错误。这个错误。这个错误号,文档的解释:

ORA-39095:Dump file space has been exhausted: Unable to allocate string bytes
Cause: The Export job ran out of dump file space before the job was completed.
Action: Reattach to the job and add additional dump files to the job restarting the job.

这个解释只针对一般情况。我遇到的这个案例,目录的空间还有很多,可是也一样报错了。而且,一般在第 100 个 导出文件出错(更正:%U参数是2位,定长的,最大99)。开始以为是 Bug,可是遍查 Metalink,发现和 ORA-39095 错误有关只有两条信息,和我遇到的情况不符。
偶然在阅读 Oracle Database Utilities 手册的时候,发现了这一段话:

Because each active worker process or I/O server process writes exclusively to one file at a time, an insufficient number of files can have adverse effects. Some of the worker processes will be idle while waiting for files, thereby degrading the overall performance of the job. More importantly, if any member of a cooperating group of parallel I/O server processes cannot obtain a file for output, then the export operation will be stopped with an ORA-39095 error. Both situations can be corrected by attaching to the job using the Data Pump Export utility, adding more files using the ADD_FILE command while in interactive mode, and in the case of a stopped job, restarting the job.

真是孤陋寡闻了,我的并行度用的是 4 ,减小这个并行度,该错误不再出现。

You can supply multiple file_name specifications as a comma-delimited list or in separate DUMPFILE parameter specifications. If no extension is given for the filename, then Export uses the default file extension of .dmp. The filenames can contain a substitution variable (%U), which implies that multiple files may be generated. The substitution variable is expanded in the resulting filenames into a 2-digit, fixed-width, incrementing integer starting at 01 and ending at 99. If a file specification contains two substitution variables, both are incremented at the same time. For example, exp%Uaa%U.dmp would resolve to exp01aa01.dmp, exp02aa02.dmp, and so forth.

EOF

AIX RAW LVM 的 4k Offset 问题

这可能是 Oracle 在 AIX 平台上最重要的一个潜在问题。

一般情况下,AIX 的逻辑卷前 4k 用于存储 control block (LVCB),在 Oracle 9iR2 之前,Oracle 软件自动跳过这 4k 而不用。这带来了一个潜在的问题,当 Oracle 的 db_block_size 大于 4k 的时候,一个 Block 可能跨在两个 PV/LUN/磁盘 上(如果做了条带化,那么将总有数据块跨在两个条带上–其实也还是将跨在不同的 PV/LUN/磁盘上。这样当系统崩溃的时候,很有可能造成大量的 IO 不完整,一个 PV 上 IO 写入,另一边可能未完成,启动 Oracle 的时候将会看到 ORA-1578 错误,这几乎是致命的。

为了解决这个问题,AIX 推出了 Big Volume Groups 作为应对。建立 Big VG 后,创建 LV 的时候可以通过 -T O 的参数强制征用 LV 的前 4K 空间, LVCB 的信息保存在 VGDA(volume group describe area) 里面。前 4k 空间被使用的 LV 有了一个新的设备子类型(devsubtype)标记: DS_LVZ,通过 lslv 可以看到。(Oracle 也在 9.2.0.3 之后自动识别 AIX 的新 LV 类型,直接开始使用 LV 的前 4K 空间)

对于 AIX 的可扩展性 VG,则默认创建的 LV 就会 DS_LVZ 类型,不使用 -T O 也是这样子。Big VG 可能只是一个过度类型。

在 IBM 的系统手册中可以看到:

The IOCINFO ioctl operation returns the devinfo structure, as defined in the /usr/include/sys/devinfo.h file

如何知道当前裸设备创建的时候使用了 -TO ? Oracle 10g 的文档中说 $ORACLE_HOME/bin/offset 工具可以做到。可是我居然找不到这个工具。莫非是忽悠人来着? 通过另一个工具可以看到相关信息:

$ dbfsize /dev/rfoo01_pay
Database file: /dev/rfoo01_pay
Database file type: raw device without 4K starting offset
Database file size: 920 8192 byte blocks

要想得到完美的东西太难了, AIX 在 BIG VG 上仍然还有很多问题,目前已知的当属这个“MKLV -TO ON BIG VOLUME GROUPS FAILS TO PUT SOME LV INFORMATION”最为严重–得不到正确的devsubtype 类型,Oracle 则会报告读取数据文件头错误,这个更要人命。
DBA 这个工作,还真是脑袋悬在腰带上,风险莫测。
EOF
Updated: offset 命令工具需要安装 RAC 组件才可用,Oracle 另外提供了一个补丁来弥补这个问题,在 Patch 3242957 中可以找到,直接解压缩,把工具提取出来即可用。

SI Object Browser 尝试进入中国,正在寻找合作伙伴

前几天收到了一封来自 SI Object Browser 公司人员的一封电子邮件,说这款来自日本的数据库工具正在中国寻找商业合作伙伴。(邮件里说是通过 ACE 的页面找到的我)
要不是收到这封邮件可能我还不知道 SI Object Browser 这款数据库工具。据说这个工具在日本市场”very popular”:

SI Object Browser is a development tool for Oracle database, providing
all required functions, SQL creation, Object creation, removal of
stored program’s bugs in the operation by GUI(Graphical User
Interface), which can contribute to your database development
productivity. And it prepares functions for DBA, data export, user
monitoring and tracing. SI Object Browser provides and prepares any
other many functions for Oracle development, and we’ve already
distributed 90,000 licenses over in Japan since released in 1997.

以前倒是对来自日本的另外一个数据库性能优化工具 Performance Insight(PI) 挺有兴趣的,不过据我所知,这个 PI 在国内也没什么市场。还不如卖服务更容易让用户接受。
这些第三方 Oracle 开发工具,包括 Quest 的 Toad,国内的用户群体还是不小的,但是掏钱买 License 的寥寥无几,抛开国内用盗版的一贯习性,另外一个主要原因还是和价格策略有关吧。我们的收入毕竟和欧美的还有很大差距。
话说回来,如果国内有哪家代理商愿意与 SI Object Browser 合作,可以直接着他们联系,或者我代为转达。
EOF