July 2005 Archives


Oracle 数据库性能优化
Originally uploaded by dbanotes.

我参与编辑的图书:《Oracle数据库性能优化》出版了。排版上我感觉不是很好。因为这个出版社喜欢用Word排版(这样降低了成本),但是从阅读的角度上来看,就不够太贴心了。

样书我只拿到了一本,在公司放着,不知道被谁拿走了。

--EOF--

CLUSTER CONSISTENT mode in AlertSID.log

前几天发生的事情.系统是 9iR2 的 DataGuard . 注意到 Data Guard 主库上有的时候会在$BDUMP 目录下产生包含如下内容的trace 文件:

......
Destination LOG_ARCHIVE_DEST_2 is in CLUSTER CONSISTENT mode
Destination LOG_ARCHIVE_DEST_2 is in MAXIMUM PERFORMANCE mode
Destination LOG_ARCHIVE_DEST_2 is in CLUSTER CONSISTENT mode
Destination LOG_ARCHIVE_DEST_2 is in MAXIMUM PERFORMANCE mode
Destination LOG_ARCHIVE_DEST_2 is in CLUSTER CONSISTENT mode
......

以前遇到过一次,当时忽略掉了.不过今天忽然感觉之所以产生这样的Log还是比 较奇怪的. 找了半天 Metalink ,发现还真有对这个现象的解释:

Flickr 测试

This is a test post from flickr, a fancy photo sharing thing.

YAPP 发布后的十年

因为某些原因,国外的很多 Blog 站点在国内都是看不到的,包括 Blogspot.BlogSpot 上有很多不错的 Oracle 专家的 Blog .比如 Thomas Kyte. 此外还有 Anjo KolkOraperf. Oraperf 的三位大牛Anjo Kolk、Shari Yamaguchi、Jim Viscusi曾经在10年前提出 Oracle 数据库优化的 YAPP(Yet Another Performance Profiling Method)方法。在这个Blog第一篇就是回顾YAPP发布后的十年(YAPP Ten years later: What has changed? ).以下内容为引用:

In 1995 I started to work on the wait events paper based on Oracle 7.3, and that formed the basis for the YAPP white paper. That in turn formed the basis for the wave of response time tuning books and presentations. Now it is funny to see how the same thing is rehashed over and over again and nothing really new is being added. In fact I believe that all the attention on wait events and response time or resource tuning in the Oracle RDBMS, is taking away the way the focus of performance problems that actually originate outside the database. The word "over exposure" comes to mind. Does this mean that wait events are no longer important? Well yes and no. Believe it or not, but most databases suffer from the same performance problems. They differ in the symptoms that they show. For example, many databases suffer from I/O performance problems and Oracle has quite a number of wait events that are directly and indirectly associated with I/O. So instead of approaching each of these events individualy, they could be grouped together to just show the symptom. In fact, Oracle 10g has finally done this and has introduced wait event classes (not new, a company Precise (now part of Veritas) did that first in their product back in 1998). So Oracle is still expanding the number of wait events, but at the same it is grouping them together again.

Before the response time tuning (and even today) people actually based on best practices (BP). Each best practice has a ratio associated with it. For example the Buffer Cache Hit Ratio, basically is the Best Practice that tells people to cache frequently used data (which is a good thing in principle). The problem with tuning today is that many Best Practices exists and they all have some kind of ratio associated with them. So if a performance problem occurs DBAs starting working on this list of Best Practices to check if something applies to their problem. There are a couple of problems with that:

1) Not every body may have the same list of Best Practices or the same threshold for the ratios.
2) The list of Best Practices may not be sorted in the same way for different people

The result is that the problem finding process takes a long time and is not really repeatable by different people (different lists, different ratios). So starting the problem finding process with Best Practices is like shooting a gun and hooping that you will hit some thing.

The Response Time tuning process is basically telling you what Best Practice to use. For example if the Response Time consists mostly of I/O relatated waits we should start looking at the Best Practices for I/O. If CPU is the most common resource consumption, we should start looking at the Logical I/Os .

In this approach the different wait event groups play an important role, because each group is basically assoicated with one or more Best Practices. We still do care about what wait events are actually in the group, but for selecting the right Best Practice it doesn't matter. For solving the problem, it may be important.

I believe that people should start thinking this way instead of worrying about the individual events. I am not saying that the individual events are not important, but keep an eye on the complete picture before diving into the indivual events.

So one of these days (may this year) I should write an update to the YAPP paper and hopefully it can be basisses for a wave in the response time tuning. Oh yeah, I don't see my self as the inventor of all this. As far as I am concerned, Response time Tuning has always been there, it was just not really accepted in the Oracle world as the way of tuning your Oracle database. So may be I started that, but I just wrote the paper(s) and other people like Mogens Norgaard made it popular. It is kind of funny that I actually still use the same method(s) almost 10 years later (and it doesn't matter if they are on instance, session or SQL statement level it is the same methodology, with different result but still solving the same problems; think about that one .....)

提到了所谓的 BP(best practices) 方法.想到曾经在一个站点上看到所谓的 HP 专家最欣赏"最佳实践"之类的说法不由得有点好笑.

还在 Oraperf 上看到了一则关于 Outer Edge of Disk 的帖子。 Oraperf's Blog: Outer Edge of Disk

The question is why one should place data on the outside of the disk and if that helps performance. I just like to add my view on that discussion. The number of physical I/Os per Disk is limited by the (full/average) seek time. The seek time is the biggest component of the I/O time (with normal Oracle blocksize). The Full Seek Time (seeking from the outermost track to the innermost track or vice versa) can be greatly reduced by only using the outermost tracks on a disk. Why the outermost tracks? Well there is this statistic that on the 1/3 of the outermost tracks there is around 50 percent of the disk capacity stored. If I only have to seek 1/3 of the distance to reach 50 percent of the data all the time, the average seek time will be greatly reduced. If the Seek time is greatly reduced, the total I/O time is greatly reduced and we can do more random I/O operations per second. So to summarize: 1) Use around 50 percent of the disk capacity (outer 1/3 of the tracks) 2) That will increase the number of random I/Os greatly.

了解一下Apache 软件基金会结构

了解一点关于Apache软件基金会的组织结构.CSDN - 技术访谈:Apache 软件基金会背后.

ASF 由哪些部分和哪几块组成?
有好几块。他们被组织成项目管理委员会,简称为 PMC 。每个 PMC 负责一个特定的代码基址、 web 服务器项目和 Jakarta 项目; XML Beans 是一个新的 PMC 管理项目; Geronimo ,即 J2EE 服务器项目,也是一个 PMC 管理项目。所以每个 PMC 都要负责某一类日常代码开发监督,以确保一切运转良好、社区在运转、代码得到正确的开发、测试和发布,等等。除了这些 PMC ,还有理事会和一些其他的非 PMC 委员会,如公共关系委员会、资金筹集委员会,等等。理事会有 9 个人,每年 5 月在年度会员会议上选出,选出理事会后,再由理事会指定干事、主席、会长、财务总管和秘书长。

还有一个关于 Jakarta 的问题我也挺感兴趣的.

Mark Rittman 的 Blog 上看到,IBM 与 Hyperion "分手"了. 而以前,IBM 把 DB2 OLAP Server (OEM 版本的 Hyperion Essbase)作为自己 BI 解决方案中的重要一环.这下子估计有不少中国 Essbase 用户要面临迁移的问题了.

前不久,IBM 刚刚 收购 Ascential,当时我还说:

不过我倒是觉得 IBM 更应该收购的公司是 Hyperion ,把 Hyperion Essbase 变成真正的 IBM 产品才有意思一些

Direct I/O 与正常高速缓存的 I/O

阅读AIX的手册,看到关于 Direct I/O 的一些描述:

直接 I/O 与正常高速缓存的 I/O

通常,JFS 或 JFS2 将文件页面高速缓存在内核存储器中。当应用程序执行文件读取请求时,如果文件页面不在内存中,则 JFS 或 JFS2 将数据从磁盘读取到文件高速缓存,然后将数据从文件高速缓存复制到用户缓冲区。对于应用程序的写操作,仅将数据从用户的缓冲区复制到高速缓存。以后执行对磁盘的实际写入。

当高速缓存的使用率比较高时,这种高速缓存策略可以发挥完全的效用。它还启用从头读取、从后写入的策略。最后,它使文件写操作异步,允许应用程序继续处理,而不是等待 I/O 请求完成。

直接 I/O 是一种可选的高速缓存策略,它使得文件数据直接在磁盘和用户缓冲区之间传送。文件的直接 I/O 在功能上等同于设备的原始 I/O。应用程序可以在 JFS 或 JFS2 上使用直接 I/O。

邮件列表中有人提到Oracle 为什么不研发自己的操作系统?。可能很多人都不知道.Oracle 曾经有个操作系统开发计划.1998 年,在Comdex 展会上,CEO Oracle Larry Ellison 宣布了Oracle 公司的 Raw Iron 计划,随后的1999年 ,HP 和 Dell 也宣布助阵 Oracle ,准备为 Oracle 的操作系统推出相应的硬件平台.不过随后的15个月过后,在一片质疑声中,Oracle 不得不草草收兵。

世上本无事,庸人自扰之

几天前发生的一件事情:因为一个小失误,折腾了一个下午.

事情开始是这样的:收到邮件被告知要 HDS 9970 Web 控制台加个 Monitor 的用户.想到缺省密码还没有修改.嗯,有安全问题,须改之.系统管理员要我用 Remote Administrator 这个垃圾工具登陆.不爽得很.这软件一个人登陆,其他登陆的人也能看到他的操作,就和远程会议一样.我修改密码,我拷贝,我粘贴,哎呀,给我报告了一个 http 500 的错误.尝试重新登陆,上不去了!用旧密码,不行,试着各种可能,不行,晕倒

问题都出在这个 Copy + Paste 上,但是现在后悔也晚了,当时真是想这不是没事找抽么......

打电话,联系厂家的支持人员,他们也没么好办法,到了机房,说要重新安装微码的软件盘,我找,我找,我找找找--找不到.

抱着试试看的态度在系统里找密码可能的存储位置,嘿,别说,还真的..........................................找到了

又折腾了一会儿,总算是恢复了

有漏洞的新闻以及其他

今天看到了一则新闻《谁是下一个Google:中国IT公司IPO热点分析》,其中说到阿里巴巴的一段是这样的:

从资本市场角度来看,1999年,高盛牵头进行的银团投资,软银注入成长基金至今也有5年,2004年2月,日本软银牵头,包括富达、TDF和Granite Global Ventures在内的四家风险投资公司再度注资8200万美元,基本上市框架已经成行。阿里巴巴并购的淘宝网也通过强悍的广告攻势,掀起了B2C旋风,其电子商务体系框架已经成型,上市难度不会太大。

众所周知,淘宝网是阿里巴巴一手创建的,谈不到“并购”之说;淘宝网是 C2C 的,而不是什么B2C .看了一下,编辑居然是 Keso,不会 Keso 根本没看这篇文章吧? 作者没常识,转贴者没看清,编辑一马虎,这样的 IT 新闻就放行了.

说起这种让人哭笑不得的错误,前几天也看到一个:

Blog,热力学第二定律及其他

作了好一段时间的 Blog 观察者,也身体力行写了了一段时间,发现还是被 Blog 大潮吞没了.现在似乎到了为 Blog 而 Blog 的时代了.

刚开始的时候,自己完全是为了新奇而写Blog.但是这样很难坚持下去的--必须要有读者的反馈才好.Blog 如果缺乏互动就变成了一个人的喃喃自语,一潭死水.如果只是写技术内容的话,的确太闷了.所以说 Blog 也可能需要炒作,必须弄些桃色元素--有些网站这样一举成名,当然,收益者可能也会耸耸肩说到:这也是给广大网民扫扫盲,告诉你Blog都有什么呀.

热力学第二定律告诉我们,随着时间无限推移...封闭系统中的状态是逐渐倾向于无秩序,熵趋于无限大...最终归于熵寂死的混沌...Blog 会不会这样?

AIX 5.3: 几个命令的改进

测试了三个命令改进。

第一个是关于 EXTENDED_HISTORY 环境变量的。AIX 5.3 新增了一个环境变量。export EXTENDED_HISTORY=ON 设定之后,fc 等命令(用 -t 参数)可以查看历史命令的时间戳了.

第二个是关于 find 命令的. -mtime -atime 等参数时间粒度现在是分钟了.

第三个 nohup 可以对一个既有的进程操作.而不是一定要在程序启动时.

升级了 Lilina

| 1 TrackBack
Lilina 是一个很好用的web news aggregator.现在有了新的空间,终于可以对这个小工具调整一下了.目前 Lilina 已经到了 0.7 版本.明显感觉在性能上也有了很大的提升.目前只是对 Lilina 进行了一下简单的定制. 同时决定把新的 Lilina 命名为 Oracle Security News Aggregator 更有针对性一些. Pete Finnigan's Oracle security weblog 的时间问题似乎还没修正.所有的Blog 主题又会跑到最前面.有时间需要告诉他一下.

0.7 版本把 Source 移到了页面的下方,而不是旧有的在右边的那种形式.很方便.

这里有个针对 0.7 的 hack,今天不早了,改日试用一下效率如何.

我早起 试用 Lilina 的一则Blog .

2005-07-17 更正一下.Pete 的站点的 RSS 时间是没有问题的. ,

MT UTF-8 显示的问题

| 1 TrackBack

在新的Web 服务器上遇到了 UTF-8 的页面乱码问题.

问题是这样的: 迁移到新的Web服务器上之后,发现我的 MT 发布之后(包含中文)从浏览器查看是乱码.必须要从浏览器端手工指定一下编码为 UTF-8 才可以正常显示.而我的主页面 页面代码是用的 GB2312.不存在这个问题. 另外一个比较奇怪的是我的 MT 后台管理显示的中文都是正常的.而 Blog 前台页面都不正常.

我开始以为是 mt.cfg 设置的问题.于是修改 mt.cfg 的发布编码为 gb2312.可这样后台显示就有问题了.真是一波未平一波又起.于是我恢复到以前的状态,开始对比后台的页面和前端的页面差异并反复测试没有结果.接着查看 Apache 的 httpd.conf(我登陆不到主机上,这个是 cometrue 给我的参考).发现 其中的全局设定了 default charset 为gb2312 . 这个时候找 cometrue 又找不到.对 Apache 又不是非常熟悉,郁闷的睡去.

第二天一早看到 车东 在线,赶紧问问他.车东告诉了我一个小技巧:wget -S 来获取响应 code.自己虽然也常用wget ,不过对这个参数倒是第一次用.果真,从服务器端来的响应代码告诉我默认编码是 GB2312 .

Blog 归来记

| 1 Comment

这个Blog offline 了足足有一个多月.

站点原来是放在我所在的上一家公司的主机上.因为一些变动,接替我的DBA告诉我空间不能继续用了.当时我正忙得一塌糊涂,根本没时间顾及,好在是把数据备份了出来.

有一段时间都不想继续写了,也是工作比较忙的缘故吧. 幸好 Tigerfish 答应给我一点空间.后来麻烦了 cometrue 不少次,不支持Perl,配置CGI-BIN,配置 Apache,安装DB_File 模块,解决 UTF-8 的显示问题, 总算是把 Blog 重新搭建了起来.其实ITpub本身也提供Blog功能的.可是我自己非常不喜欢这种 Blog 大集中的方式.加上其他种种原因,就放弃了在 ITpub 的那个Blog.

参加了两周培训

这一段时间参加 AIX 操作系统的技术培训.先是一周的初级班,基本没怎么听课.初级班的老师讲的不够生动,也可能是没有针对性.加上我这边 IM 信息过来的请求不少.基本上都是在笔记本上忙活自己的事情.所以效果不是很好.

Oracle 10gR2 新特性浮光掠影

今天听 10g 的 Podcast ,提及 10gR2 对 PHP 提供进一步的支持.只是细节没听清楚--还需要锻炼听力.10gR1 对 php 已经提供了不错的支持.10gR2 居然还有增强,可见 Oracle 对 OpenSource 还是很有信心.

翻看 PDF 手册,看到了如下比较感兴趣的内容(10gR2的文档结构和以前有了很大变化):

控制文件的特性有了一些增强.在修改 MAXLOGFILES、 MAXLOGMEMBERS、 MAXLOGHISTORY和MAXINSTANCES这几个参数的时候,已经不用重新创建了。可用性有了一定提高。

表空间监控 表空间达到定义的临界值的时候可以自动告警。当然,这个是和 EM 结合在一起的.

Online segment shrink 功能进一步改进.现在可以支持Lob对象和IOT segment.

猫扑获得风投

早就知道有猫扑这个比较 BT 的网站.

这两年的网民,没看过从猫扑出来的变态帖子的人怕是不多.猫扑这个站点这个存在也造就了互联网以来的 BT 一族.(这个 BT 不是 Bittorrent ).不过似乎很少有人关注到猫扑的商业价值.如果两年前有VC把美金抛给猫扑的话,我估计很多 IT 评论家会笑掉大牙.可是,当前一段时间微软宣布 MSN 将和国内淘宝网、 联众、等六大站点合作时候,猫扑赫然在列。感到惊奇的人已经不多了。

也说周鸿祎

| 1 Comment

最早听说周鸿祎是在林锐的《大学十年》的那篇妙文里。应该是 2001 年。

第一次看完林锐的回忆,觉得这个家伙是个人物,可他居然对周鸿祎服贴得不得了,可见周的确不是一个一般人。

没过多久,有媒体开始关注 3721 了。那个时候,3721 还没到过街老鼠人人喊打的时候,一度攻城掠地,风管无限。记得 3721 最开始吸引眼球的就是和 Realname 的一场口水大战。3721 当时是作为弱者的姿态出现的。因为 Realname 是和微软联系在一起的。彼时博客方正在呐喊起来反抗微软的霸权,3721 活了下来。再到后来,3721 似乎麻烦也不断,可每次都能以胜利者的姿态在风口浪尖上叫嚷。不管怎么说,周鸿祎对媒体真是摸透了。而这也是一个公司成功的一个关键因素。有的时候偶想,周的这个宝贝产品 3721 虽然很烦人,可这个家伙的确非常有趣的。

归辛树--笨蛋神拳失败教育家

实在搞不懂,金庸怎么让这麽无趣的一个归辛树在两部书中都出来了,而且戏份儿还都不少。

早在《碧血剑》我就感觉这个归老二算不上啥好汉子,首先这家伙是个怕老婆,自己没主见。另外,夫妻俩还是个失败的教育家,教出来的徒弟居然动不动就砍人家胳膊,这不是成了女流氓了?居然最后全身而退,要我说阿,起码判她面壁十年八年的。

这夫妇俩弄个傻乎乎的儿子到处找药,为了药根本不分青红皂白,哎呀,神拳无敌,有拳无脑。

就这么一家三口活宝,在《鹿鼎记》里面居然又跑出来了,而且,还要去大内杀康熙。不明白,为啥他们不早点进皇宫杀皇帝,这都几十年了,才想起来行刺?对了,这一家三口和吴三桂关系还挺密切。人家给了一块老虎皮,儿子披在身上挺舒服,就感恩戴德的,哪里有神拳无敌的气概?

--EOF--

周芷若-初恋情人反目成仇

金庸写周芷若,完全是写初恋情人的感觉。

汉水舟中喂饭之德,是张无忌心底抹不去的回忆。可之后,多年杳无音讯。后来见面,周已然从一个渔家女儿成为名门大教的弟子。多年跟随灭绝老尼是不是也传染上了一些变态的行为?

初恋情人反目成仇。对于周芷若的杀殷离、夺经、嫁给(利用?)宋青书、杀司徒千钟,甚至要以霹雳雷火弹杀武当七侠的俞莲舟(未遂),都是一个女人因爱生恨而变态的不正常反应。可惜的是,张无忌最后似乎原谅了她,不知道金庸是否也会原谅他。不过可以确定的是,读者很少会原谅他。爱情是爱情,和道义无关。

--EOF--

任我行-大独裁者

大独裁者任我行最后死在权力巅峰上,算是死得其所。

纵看任我行的权力路线:

受到暗害,被二把手把他从权利巅峰赶下来,颠沛流离(囚禁湖底),好在东方不败念在他干革命有功,没取他的性命。也没有全国范围内广播他的罪行。

不过,领袖就是领袖,有衷心的老部下(向问天等)暗中为他奔走,营救他。不明真相的热讯青年也来相救(令狐冲)。最后二次革命成功,领袖重回权力宝座。千秋万载,一统江湖!

--EOF--

鸠摩智在最后居然成了得道高僧。成功转型。

佛教中对好人恶人的定义大致是这样的;一个人做了一辈子好事,可是在最后做了一件坏事。那他就是恶人一个。一个人做了一辈子坏事,临死的时候良心发现做了一件好事,那么就是一个大善人了。典型的只看结果,不看过程。所以说佛教在中国式微。

小说中说鸠摩智在枯井地污泥处,被段誉吸去内功之后才顿悟,从此人间多了一个得道高僧。金庸自己也是佛教徒,这样的处理方式也是可以理解的。不过,鸠摩智的转变过程有些令人怀疑。既然鸠摩智是得道高僧,为什么少林无名老僧的佛法仍然未能点醒他?既然萧远山和慕容博这样作恶多端的人都能搞定,大轮明王咋就这麽顽固?

谢烟客是《侠客行》中最虚伪的家伙!

首先,谢烟客是个死要面子活受罪的人。既然自己放出了三枚玄铁令,还处心积虑不让江湖中人得到,这不是瞎装潇洒么? 别人的虚伪可能是对别人的,但是谢烟客的虚伪是连自己也不放过。石破天拿到了他的玄铁令,但是并没有什么求助于他,谢烟客居然恶意传授石破天武功,暗中带着他往鬼门关走。且看:

[谢烟客]臉上露出笑容,緩步走開,走得幾步,突然心念一動:「這娃娃玩泥人玩得高興,我何不乘機將泥人上所繪的內功教他,故意引得他走火入魔,內力沖心而死?我當年誓言只說決不以一指之力加於此人,他練內功自己練得岔氣,卻不能算是我殺的。就算是我立心害他性命,可也不是『以一指之力加於其身』,不算違了誓言。對了,就是這個主意。」

如果说白自在是《侠客行》中最自大的人,那么谢烟客无疑是最虚伪的.

--EOF--

购书小记

杭州天这个热呀!我的 Firefox 上订了杭州的天气预报。这几天的图标居然是个点燃的火柴,说是"Very Hot"!

好不容易找到了自行车,大街上飞奔! 骑慢了没有风, 骑快了汗更多。心里盘算着怎么计算一个公式出来,好在这两者之间找个平衡。胡思乱想间,"枫林晚" 书店在眼前了。

据公司内网上的热心同事介绍说,这个书店是"见过的杭州最大的特色书店了"。而且,据小道消息说,目前店庆,75折呀。

推门进,凉快! 门口的座位上坐着一个读者,挺小资的样子。放眼望去,书店似乎不大,人也不多,有个小朋友一边唱歌一边玩耍。哦,还有个楼梯,楼上是商务印书馆的专卖。 刚走到楼梯口,感觉上面很吵, 原来书架旁边是个小咖啡厅,有几个中年文学男子和几个艺术女青年在那里讨论什么哲学话题,竖起耳朵听了一下,哎呀妈呀,内容太艰深,心里惴然。

关于这篇归档

This page is an archive of entries from July 2005 listed from newest to oldest.

June 2005 is the previous archive.

August 2005 is the next archive.

Find recent content on the main index or look in the archives to find all content.