Oracle Database 10g Release 2: Online Limit Changes

This feature is pretty useful as we don't have to re-create the controlfile to make the changes any more. Previously, taking such an action is critical and dangerous. You must be very careful to rebuild the controlfile. Moreover, the database must be opened in RESETLOG mode and a lot of information will be lost during the process.

Oracle Database 10g Release 2: Top Features for DBAs: "Online Limit Changes


When you want change parameters defined during the creation of the database, such as MAXDATAFILES, MAXLOGFILES, and so on, what are your options? Prior to Oracle Database 10g Release 2, the only option is to follow these steps:

1. Take a backup of controlfile to trace.
2. Modify the parameter you want to change in that trace file.
3. Shut the database down.
4. Startup Mount.
5. Recreate the control file.
6. Open the database in RESETLOGS mode.

Needless to say, this approach degrades availability. In addition, because RMAN keeps the metadata about backups in the control file as well as in the catalog, that information is lost during this process. The controlfile is created in RESETLOGS mode, so some backup information may be lost too.

In Oracle Database 10g Release 2, you needn't recreate the control file to change these parameters. Thus, you do not have to lose the RMAN information stored there."

My first time to see a group of Tibetan Antelope

In the morning on Sep. 16, 2005, it's the first time in my life to see wild life, a group of Tibetan Antelope. They are such amazing animals, slim, alert and active. All the group members I encountered are male with long horns on their heads. Doubtlessly, three of us, meimei, my wife and I all felt very excited at the time. We were trying to get closer to them but without success. They were so alert and always sprung away when we still were 200 or 300m away from them. The electrical poles in the background are not harmonized with the whole natural environment but truly exist there. Do they feel strange about the poles or already get used to such civilization products? Who knows? This is reality, anyway. The conflicts and collissions between the nature and our civilization progress! Let's pray they will live a safe life forever on their own land! 

Google's New Service

个人一直都比较喜欢Google推出的各种新服务，不仅方便，而且实用。可以看出，Google一直在努力地提升着自己的服务，仍然是一家朝气蓬勃的公司，发展潜力依旧是巨大的！公司的竞争力也还在不断增强！昨天，继前一阶段推出了Google Talk之后，Google又在Google Lab里面推出了一个新服务的测试，名字叫Google Reader。大家看到这里，也许已经猜到了这项新服务的用处。对，它就是一个新闻阅读器，也是时下非常流行的RSS阅读器。那么，它和其它类似的RSS新闻阅读器差别又在哪里呢？又有什么特别之处呢？
第一，最大的差别我想就是无需再安装软件或者插件，它是一个完全基于WEB的服务，只要你能够上网，任何一个浏览器都可以用到这个服务。由于所有订购的新闻都存储在Google服务器中，在何时何地我们都可以浏览自己感兴趣的新闻！省去了用OPML在软件之间来回导入导出的麻烦，而且，有些RSS阅读器还不支持OPML。
第二，仍然是Google在这项新服务中集成了搜索功能，这也是Google的一贯宗旨。我们可以对自己感兴趣的话题进行查找，Google可以把相关的新闻源列出来，我们可以再从中选择然后进行订购。省去了自己在网上大海捞针式查找的麻烦。
第三，标签功能也是必不可少的，这一概念也被其它的公司所逐渐采用，如Yahoo。具体应用在这项服务中，是对所订购的新闻源进行标签，一个新闻源可能与科学有关，同时又是关心健康的一些话题。这样，我们可以把这个新闻源同时标以科学和健康，便于准确定位。当然，只有在订购的新闻源数量特别多的时候才会体会到这项功能的方便性，道理和Gmail是一样的。
此外的功能还有将自己感兴趣的某一具体话题用Starred标注起来。可以将话题直接Gmail给自己的朋友，也可以对话题直接进行博客等等。
因为现阶段只是测试版本，相信Google还会对一些功能进行改良，并逐渐加入一些更加好的新的功能进来。
大家可以到以下这个网址试用这个服务：

http://reader.google.com/

万事具备,只欠东风

朝思暮想的，魂牵梦萦的西藏之行终于就要实现了。四年，整整想了它四年，中间都因为种种因素而放弃。其中有个人的原因，也有工作的原因。今年想怎么着也得趁着新婚之喜，和老婆一起同游西藏，那一片对于我来说仍旧陌生，仍旧神秘的土地。
在过去的四年中，不知有多少次就在它的旁边经过，在从那片土地上孕育出来的江河上穿过，在从那里延伸出来的山脉上走过，可就是无法踏足它。无奈，遗憾的同 时，想去的欲望也就越来越强烈。眼前总是不时出现它的影像，有从照片上获得的，也有自己的想象。甚至于，繁忙都市中偶尔一次晴朗的天，偶尔一丝凉爽的风都 能勾起我对西藏的遐想。
终于，无法再忍受这种煎熬，和老婆商量决定了出行日期之后，于7月初便请了9月中的长假。搞得同事们都说用得着这么早请嘛，提前快3个月。可是要知道，请 3个星期，15个工作日的长假对于我来说是怎样的困难。我是做IT的，自从2000年IT不景之后，能生存下来已经很不容易了。可是，生存的代价便是无休 止的工作，一个人做以前几个人的活儿。而且这个职位上只有自己一个人，我离开了公司，就意味着没有人能够继续我的工作。所以，3个星期的长假能够获得批准 是非常难得的。这恐怕是我第一次请这么长时间的假期，也将会成为我最后一次，起码在这间公司。前几天，收到上级的邮件，说我这次是例外，以后最长只能请 10个工作天。也就是说，以后最多请17天假期。17天，怎么能够来得及走川藏？除非走马观花。所以，这一次的出行对我显得尤其重要。为了成行，我拼命地 工作，尽量减低在我离开公司期间出问题的可能性，尽量给领导好的印象，争取在成行之前完成今年设定的项目。总之，不惜一切来保证这次出行。可是，总有你计 划不到的情况出现，一个同事被通知成为陪审团的候选人，就在今天去报到！一旦被正式选为陪审团，就要上庭履行义务。如果开庭时间和我的放假时间有冲突，那 上级就很有可能取消我的假期，尽管已经批准了。毕竟，一个是社会责任，一个是私人理由。这就是为什么只欠东风的原因。大部分人，一生可能也不会被通知成为 陪审团候选人。可这个同事就偏偏在这个节骨眼上收到通知。虽然自己的工作他不能承担，但是监视服务器，报告问题他还是可以的，而这也是我不在公司期间能够 让他代为执行的一切，以前我放假也是此人代替我的职务。我想，现在我的心情一定比他本人还紧张（或许他丝毫不紧张）。我反而象是一个站在被告席上的被告， 已经完成了结案陈词，等着还没有成为陪审员的他履行着陪审员的义务，等着他口中Guilty或者Not Guilty的宣判。天知道，我是无罪的！

Response time analysis for tuning Oracle SQL query

Jul. 21, 2005, Last Thursday I received a request from my manager to tune a SQL query statement. At the time, this SQL always take around 4 hours to finish. It's really an unacceptable response time!

After receiving this request, the first thing came in my mind is the methodology, response time analysis. Throughout these years, the methods about how to tune the Oracle performance comes and goes. It has been being developed and revised.

As the 1st generation, DBAs liked to use so-called ratio analysis. As the name indicated, people usually collect the hit ration of the various database SGA area from those statistics tables. After collecting people try to maximize the hit-ratio by enlarging the corresponding memory area and so forth. It's somewhat effective but most of time it's not. It does have it's own limitation as well.

Afterwards, the wait analysis emerged. It measures what the database is really waiting for at the time. This improved much in tuning Oracle performance. Many DBAs including me are still using this method to tune SQL, most of time. It can tell you immediately what a running SQL is waiting. By concentrating on what caused the waits and reduce/eliminate them, most of time you can efficiently and effectively improve the SQL performance. However, it can only tell you what the DB is waiting for, it can NOT tell you where the majority of time is being consumed. That's why the response time analysis comes in place and take the role!

The response time analysis measures how and where applications eat the time before the completion. It needs to turn on the Oracle trace feature. There is a lot of information in Oracle raw trace file as well as the TKPROF file produced from the raw file. By turn on TIME_STATISTICS parameter and enable the event 10046 trace, everything during the SQL execution could be recorded in raw trace file including CPU time, elapsed time, physical reads, consistent gets, db block gets and so on. You will be able to exactly know which part of a SQL consumes the time aggressively regardless the cache ratio and the waiting time. Hence you can focus on it and work against it!

Time to get back to the case! In this case, the wait analysis doesn't help much. There is always 'db file sequential read' in v$session_wait and a high CPU usage on OS level. Based on these facts, I really have no idea what's going on during the SQL execution. Even there is always 'db file sequential read' in v$session_wait, the total waited time is only a small portion of the total execution time told by v$session_event after finishing. So the root cause is neither an inefficient index nor the I/O problem. By turning on Oracle trace using 'oradebug' utility, I find out the root cause is there are too many consistent gets. The more the consistent gets, the longer elapsed time, the longer the CPU time. This also is the cause of the high CPU usage! This also bring another popular tuning topic out, minimizing the logical I/O. Once the logical I/O has been minimized, the physical ones will be minimized as well automatically. If you take care pennies, dollar will take care of itself! Following this clue, I also figure out the abnormal consistent gets are produced by the improper order of nested loops in the SQL execution plan generated by Oracle. By reversing the order, consistent gets dropped dramatically. From user's point of view, the response time dropped down by 87.5%, from original 80 minutes to 9 minutes! A big improvement!

--
Flyhorse@LonelyPlanet
=================================
Life can only be understood backwards,
but it must be lived forwards!
=================================

My Web BETA - Yahoo!

My Web BETA - Yahoo!

Yahoo! 最近退出了一个叫做My Web的服务,试用了一下,觉得想法相当不错!也许也是Internet发展的一个趋势!
先简单介绍一下什么是My Web.基本概念就是把你感兴趣的网站或者网页收藏起来.你也是会说,这有什么稀奇,不是早就有了吗,IE早就可以把网站收藏到收藏夹里了.可是你想过没有,浏览器所做的只是把那些网站收藏到你的本地电脑里面.当你随身没有携带那部电脑而又想不起来你感兴趣的一个网站的地址怎么办?只好通过搜索引擎查找了.你也许又会说,反正现在搜索引擎很强大,应该可以找得到.可是,往往事实并非如此,搜索的结果也许让你非常泄气.如果时间紧迫,更是如此.有了Yahoo! My Web,你就无需担心了.你可以把你感兴趣的网站存在属于你自己的Yahoo! 帐户里,是在Yahoo!的服务器里,而不是你本人的电脑里!这样,无论你在哪里,只要你可以上网,便能够立即找到你感兴趣的网站!
告诉你吧!还有一个更加强大,方便的功能,就是My Web不止可以存放你感兴趣的网页或者网站,而且还可以存放你当时浏览它们的拷贝,也就是一个Snapshot!这个有什么用?用处可大了!我们都知道,网页会不断地更新.你在之后通过一个网址看到的网页未必就是你之前在同一地址所看到的.原因就是内容被更新了.这时我们如果只对之前看到的内容感兴趣该怎么办?不要紧,My Web可以帮助你!在你将一个网址存到My Web的时候,可以选择同时也保存一份拷贝.同样,这份拷贝也是放在Yahoo的服务器里面的.这样一来,无论什么时候你需要看之前的内容的话,都可以通过My Web来办到.个人觉得这个功能非常有用!也是我喜欢My Web的最重要一点!
另外还有一个功能就是可以把你曾经通过Yahoo搜索引擎查找所用过的关键字存下来.Google也提供有相同的功能.

远期自助旅游 -- 05年春季西藏计划（阿里，珠峰，修订版）

远期自助旅游 -- 05年春季西藏计划（阿里，珠峰，修订版）
从绿野抄录的一个西藏阿里地区行程表，似乎还不错。可以借鉴一下！
行程中包括两天冈仁波齐神山的转山，第一天23公里需时9小时，第二天32公里需时12小时。平均时速不到3公里，但由于高海拔，估计还是比较辛苦。必须要有心理准备。