www.eygle.com

---

February 29, 2008

2008 我还能否呆在北京?

作者:eygle

出处:http://blog.eygle.com

今天，是2月29日，这一天4年才有一次，2008是久违的一个闰年。
一定要记录一下这一天我是如何度过的。

1.停电
今天一大早我在 北京·亚运村·小营 的住所醒来，发现居然停电，停电就没有了网络，我的任何工作都无法进行。
所以，只好出去跑一跑，继续去申请昨天未能就绪的电话

2.网通营业厅
今天我选择了 三元桥·发展大厦·网通营业厅 ，这个营业厅的人非常少，很快我就能够办理业务了。
不过很不幸，当那个心不在焉的营业员看到我的身份证时，问题出现了，他说，你这个外地的身份证，宽带不能包年、电话不能后付费，只能办理按月预付费。我当时晕倒，该死的网通那个10060今天死活打不进去，又害得我白跑了一趟。

身份证问题让我产生了另外一个担忧，奥运会来临的时候，我还能呆在北京么？
现在的小区也开始了普查外来租住户的行动，也许还真不好说。

3.新家
接下来跑去 青年路·甘露园 的新家，看了一下我之前买的花花草草，让我欣喜地是，她们全部恢复了过来。
之前一共买了6盆花草，两盆黑美人、两盆一帆风顺、两盆常青藤，最初一周差点死掉，在我的精心照料下，这一周她们全部恢复了生机。

这些花草能够有效的吸收甲醛、苯等有害气体，净化新家的空气，将来准备买更多的绿色植物在家里。

-The End-

Posted by eygle at 9:19 PM | Comments (12)

---

February 28, 2008

电话以及宽带，新家的选择

作者:eygle

出处:http://blog.eygle.com

今天下午去网通营业厅，打算申请为新家安装电话以及宽带。

结果到了亚运村的营业厅，看到了长长一条人龙，吓了我一跳，从来没去过网通的营业厅办理业务，没想到比银行还火爆。2008北京奥运会合作伙伴果然不同凡响。
结果我问了一下，又说我那片这边办不了，如果在这边办，可能分配不了正确号码，到时候还要回来办理退定和更改。

斟酌了麻烦程度和排队在前的75人，我选择了放弃。
看来装电话也要选择一个黄道吉日，明天我再去，去离新家近一点的地方。

搬家计划已经制定，下个月，准备搬到新的地方去，属于自己的地方。

-The End-

Posted by eygle at 10:13 PM | Comments (11)

---

February 27, 2008

Patchset 10.2.0.4中关于ASM的Buglist

作者:eygle

出处:http://blog.eygle.com

今天下载了10g Release 2 (10.2.0.4) Patch Set 3，这个Patch将近1G，是个大块头。
Oracle从10g开始，减小了安装包的大小，但是Patchset却是越来越大。

这个patch set的Buglist也有1.5M左右，我上传到网站上供大家参考。
最近在关注一些ASM方面的内容，所以将这个patch中和ASM相关的Bug列举出来，大家可以对照一下，甚至逐一研究一下这个Bug，看这些Bug有否可能在自己的环境中出现。

简单统计一下，ASM相关Bug中:

10.2.0.4中修正36个，
10.2.0.3中修正29个，
10.2.0.2中修正14个

以下是ASM的Bug列表，供参考:

 

Posted by eygle at 9:24 PM | Comments (1)

---

Oracle关于Patchset 10.2.0.4的提醒邮件

作者:eygle

出处:http://blog.eygle.com

昨天收到了Oracle发来的一封关于Patchset 10.2.0.4的提示邮件，邮件内容如下：

Dear Oracle Customer,

You are receiving this email because our records indicated you downloaded Oracle Database Patchset 10.2.0.4 (Patch 6810189) on the Linux x86 platform:

There was a minor error in the zip file name mentioned in the README.
Section "7.4 Download and Extract the Installation Software" in the README incorrectly mentioned p6810189_10204_LINUX.zip as the file to be downloaded and unzipped. This has now been modified to reflect the correct file name, p6810189_10204_Linux-x86.zip. Apart from this minor change to the README, there is no other change to the patch set content.

Please accept our apologies for any inconvenience you may have experienced, and we thank you for your patience and cooperation in securing your Oracle server products.

Regards,
Oracle Global Product Support

我的第一感觉是，Oracle对于客户的跟踪目前做的是相当及时，我访问了这个Patch，Oracle就已经跟踪在案。

邮件的内容是说，补丁中的README文档中存在一个小的瑕疵，原本Patch的名称为p6810189_10204_Linux-x86.zip，文档中误写为p6810189_10204_LINUX.zip，现在作了修正。

比较了一下下载Patch中的README.html文件和patch_note.htm文件，发现只是README.html文件中存在错误，而patch_not.htm文件中的描述是正确的:

G:\Oracle\Linux>diff README.html patch_note.htm
5c5
< <!-- Run date = February 25, 2008 11:28:55 -->
---
> <!-- Run date = February 22, 2008 16:35:29 -->
893c893
< <p>Download the <code>p6810189_10204_Linux-x86.zip</code> patch set installation archive to a dire
ctory that is not the Oracle home directory or under the Oracle home directory.</p>
---
> <p>Download the <code>p6810189_10204_LINUX.zip</code> patch set installation archive to a director
y that is not the Oracle home directory or under the Oracle home directory.</p>
898c898
< $ unzip p6810189_10204_Linux-x86.zip
---
> $ unzip p6810189_10204_LINUX.zip

看来Oracle的文档管理也是极其混乱的。这样自相矛盾的错误也会出现。

这是一个小问题，我们可以顺便了解一下Oracle补丁集的命名规则，那就是：
p<patch number>_<release number>_<os>.zip

根据这个规则，我们可以很容易获得Metalink ftp站点上的文件名称：

oracle 9208patch:
ftp://updates.oracle.com/4547809/p4547809_92080_AIX64-5L.zip
ftp://updates.oracle.com/4547809/p4547809_92080_HP64.zip
ftp://updates.oracle.com/4547809/p4547809_92080_HPUX-IA64.zip
ftp://updates.oracle.com/4547809/p4547809_92080_LINUX.zip
ftp://updates.oracle.com/4547809/p4547809_92080_Linux-IA64.zip
ftp://updates.oracle.com/4547809/p4547809_92080_Linux-x86-64.zip
ftp://updates.oracle.com/4547809/p4547809_92080_MVS.zip
ftp://updates.oracle.com/4547809/p4547809_92080_SOLARIS.zip
ftp://updates.oracle.com/4547809/p4547809_92080_SOLARIS64.zip
ftp://updates.oracle.com/4547809/p4547809_92080_WINNT.zip
ftp://updates.oracle.com/4547809/p4547809_92080_WINNT64.zip

oracle 10.2.0.4
ftp://updates.oracle.com/6810189/p6810189_10204_Linux-x86.zip

结合你的Metalink帐号，我们就可以使用flashget从Metalink上快速Download补丁了。

-The End-

Posted by eygle at 12:32 PM | Comments (3)

---

February 25, 2008

Oracle10g 10.2.0.4 PatchSet发布

作者:eygle

出处:http://blog.eygle.com

今天上午还在和客户讨论Oracle Database 10g可能的最后发布版本，那时候我猜测这个最终版本可能将是:10.2.0.6。

现在Oracle朝着这个方向迈进了一步，刚刚看到NinGoo在论坛上说，Oracle的10.2.0.4 Patchset已经发布了Linux版本。这个Patch的Patch号为6810189。
在Oracle的下载站点确认了一下，这个Patch的大小为:1053748379，又是一个庞大的家伙：

C:\Documents and Settings\gqgai>ftp updates.oracle.com
Connected to bigip-updates-test-adc.oracle.com.
220 FTP server ready.
User (bigip-updates-test-adc.oracle.com:(none)): metalink@eygle.com
331 Username OK, please send password.
Password:
230-
230- Welcome to the Oracle Patch Download FTP Server
230-
230- For detailed help, use command "quote site help".
230
ftp> cd 6810189
250 Changed directory OK.
ftp> ls -al
200 PORT command OK.
150 Opening data connection for file listing.
total 1
-r--r--r-- 1 root other 1053748379 Feb 22 18:58 p6810189_10204_Linux-x86.zip
226 Listing complete. Data connection has been closed.
ftp: 收到 96 字节，用时 0.00Seconds 96000.00Kbytes/sec.

前几天Oracle发布了一个CPU，现在看来如果还计划打CPU的客户可以考虑直接应用这个新的patchset了。

-The End-

Posted by eygle at 10:10 PM | Comments (6)

---

February 24, 2008

《深度解析Oracle》之《循序渐进Oracle》

作者:eygle

出处:http://blog.eygle.com

今天下午2:00~4:00，在东方标准完成了《深度解析Oracle》的第一次课程《循序渐进Oracle-数据库的创建与迁移》。

这次课程是《深度解析Oracle》系列课程的第一节，也是我第一次尝试通过卫星直播方式进行全国统一的视频教学。
开始时很不适应，当面对的不是直接的听众时，你完全把握不到别人的反应和感受，这是一种不好的授课体验。
就像以前为OTN制作视频，当我面对电脑进行录制时，完全找不到感觉，其实我更喜欢的是直接面对大家进行面对面的交流。

不过，既然说远程教育是未来的趋势，那么还是让我学习和尝试一下这种方式吧。
今天东方标准的教室投影出了些问题，效果没有周五那天测试时好，不过，既然开始了，一切已经无法改变。

在这次课程中所讲的内容其实是我新书《循序渐进Oracle》中第一章的内容，我一直期望通过这样一部分内容，将我由点及面、由浅入深的学习方法传达出去，只是这是我的所愿，能传达多少，对多少人有益就不是我能够把握的了。

北京的现场很火爆，大约来了200～300人，外地的效果不知道如何，我只能知道我面对的直播室中的20个人。

演讲的PPT我上传到网站，大家可以自由下载:
http://www.eygle.com/pdf/StepByStepOracle-DatabaseCreation.pdf

有朋友想看一下更详细的内容，其实我书中是最为详细的，第一章内容全文已经公布，大家可以下载一下，如果细致的看一下，我想会有一点收获的。
其网页版本和PDF版本可以从以下链接获得:
http://www.eygle.com/archives/2008/08/stepbs_oracle_info.html

感谢一些熟悉的朋友到现场给我捧场加油，也感谢众多新朋友能够支持我的活动。
最后，欢迎大家对我的演讲提出批评和建议，希望能够在以后的日子里继续和大家分享我的一点知识和经验。
我希望能够构建一个本次活动的通讯录，并且希望以后的日子里能和大家保持沟通和联系，如果你参加了今天的活动，可以发送邮件到 oracle@eygle.com ，请注明你的姓名以及常用邮件地址，希望我们的缘分不仅仅只是止于这一次活动。

谢谢大家！

-The End-

Posted by eygle at 6:32 PM | Comments (11)

---

DBA警世录:使用ASM应当具备充分认识

作者:eygle

出处:http://blog.eygle.com

本周五，淘宝网的DBA们遇到了ASM的故障，产品环境的故障对于DBA的考验是巨大的(同日我的一个客户也经历了一次ASM故障)。

故障症状就是ASM磁盘的Header信息丢失，导致磁盘组无法加载相应磁盘。
通过kfed工具可以查看ASM磁盘头信息。

出问题的磁盘信息显示：

kfbh.endian:                        83 ; 0x000: 0x53
kfbh.hard:                            0 ; 0x001: 0x00
kfbh.type:                            0 ; 0x002: KFBTYP_INVALID
kfbh.datfmt:                          0 ; 0x003: 0x00
kfbh.block.blk:              4294967293 ; 0x004: T=1 NUMB=0x7ffffffd
kfbh.block.obj:                  65286 ; 0x008: TYPE=0x0 NUMB=0xff06
kfbh.check:                        144 ; 0x00c: 0x00000090
kfbh.fcn.base:                136903976 ; 0x010: 0x0828fd28
kfbh.fcn.wrap:              4294953840 ; 0x014: 0xffffcb70
kfbh.spare1:                  136905029 ; 0x018: 0x08290145
kfbh.spare2:                      30000 ; 0x01c: 0x00007530

由于ASM是个封装的磁盘管理工具，我们很难窥探其内部原理，所以遇到问题时常常就会手足无措。
这就要求我们在使用ASM时要有充分的认识，ASM也可能出现严重的故障。不可对此掉以轻心

所以，做好数据库的备份是最基本的要求，除此之外，定期保存一下ASM Disk Header信息（通过kfed read来记录）以备不时之需也许是必要的。
有一点也许要引起注意：数据库总是会在你毫无准备的地方出现问题。仔细想想，你在哪些地方缺乏考虑?
此外我们需要谨记：当问题没有定位之前，不要贸然关闭运行中的节点。
-The End-

Posted by eygle at 10:53 AM | Comments (7)

---

February 22, 2008

What's Mean "reliable message"?

作者:eygle

出处:http://blog.eygle.com

今天客户的一套RAC环境出现问题
双节点RAC环境中，一个节点因为锁竞争而挂起，shutdown之后无法启动。


故障出现时我正在路上，匆匆回到家中，处理故障。
解决之后查找故障原因。

检查当时的AWR信息发现Top 5 Timed Events显示如下信息：

Top 5 Timed Events                                        Avg %Total
~~~~~~~~~~~~~~~~~~                                        wait  Call
Event                                Waits    Time (s)  (ms)  Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
reliable message                        354          89    251  219.4      Other
CPU time                                            32          78.3
db file sequential read              2,223          12      6  30.3  User I/O
control file sequential read        29,151          8      0  20.9 System I/O
db file scattered read                  36          2    62    5.5  User I/O
          -------------------------------------------------------------

这里最显著的事件是reliable message，这个事件Metalink的解释为:

    When you send a message using the 'KSR' intra-instance broadcast
    service, the message publisher waits on this wait-event until
    all subscribers have consumed the 'reliable message' just sent.
    The publisher waits on this wait-event for three seconds and
    then re-tests if all subscribers have consumed the message, or
    until posted.

也就是说当跨实例发送消息时，发送者期望收到订阅者的回复信息，如果得不到可信回复，就会一直处于等待。等待以3秒为周期进行反复尝试，知道收到所有订阅者的回复或者被唤醒。

那么在这个环境中，也就是说两个节点的通讯已经出现问题，一个节点得不到另外一个节点的回复。
这是一个可怕的故障，reliable message也是一个让人头疼的事件。

-The End-

Posted by eygle at 10:58 PM | Comments (10)

---

DMT之后SMON还需要coalesce么?

作者:eygle

出处:http://blog.eygle.com

在LMT之前，也就是说在DMT中，SMON的一个经常性工作是去合并（coalesce ）相邻的自由空间。
那么在LMT之后，这个工作还需要么?

如果表空间创建是Extent的设置使用的是Uniform Size选项，那么显然在使用过程中自由空间不再需要被合并，因为请求的Extent将和现存的大小一致。

但是即使如此，在Oracle9i的某些版本中，仍然会存在Coalesce所带来的困然。
已知在Oracle 9.2.0.6数据库版本中，你可能会看到如下语句在Top SQL列表中出现：

select f.file#, f.block#, f.ts#, f.length from fet$ f, ts$ t whe    re t.ts#=f.ts# and t.dflextpct!=0 and t.bitmapped=0

这个语句就是用于空间管理的，t.dflextpct!=0是查找那些pct_increase不等于0的表空间，t.bitmapped=0是查找那些非本地管理表空间的。
虽然在很多9i之后的数据库中，这个查询的返回值统统是0，但是查询仍然在消耗资源。

虽然这个语句的返回值为0，但是执行计划并不简单：

PARSING IN CURSOR #1 len=115 dep=1 uid=0 oct=3 lid=0 tim=13490086563004 hv=2095543314 ad='54e34f24'
select f.file#, f.block#, f.ts#, f.length from fet$ f, ts$ t where t.ts#=f.ts# and t.dflextpct!=0 and t.bitmapped=0
END OF STMT
PARSE #1:c=0,e=220,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=13490086562995
BINDS #1:
EXEC #1:c=0,e=95,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=13490086563299
FETCH #1:c=0,e=2591,p=0,cr=236,cu=0,mis=0,r=0,dep=1,og=4,tim=13490086565948
STAT #1 id=1 cnt=0 pid=0 pos=1 obj=0 op='NESTED LOOPS '
STAT #1 id=2 cnt=0 pid=1 pos=1 obj=16 op='TABLE ACCESS FULL TS$ '
STAT #1 id=3 cnt=0 pid=1 pos=2 obj=12 op='TABLE ACCESS CLUSTER FET$ '

对于LMT的UNIFORM SIZE和AUTOALLOCATE，两者的区别还是明显的。
在Oracle9i、10g中，可以通过DBA_FREE_SPACE_COALESCED视图来查看各表空间的空间合并情况：

SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
PL/SQL Release 9.2.0.4.0 - Production
CORE    9.2.0.3.0      Production
TNS for Linux: Version 9.2.0.4.0 - Production
NLSRTL Version 9.2.0.4.0 - Production

SQL> select tablespace_name,extents_coalesced,blocks_coalesced from dba_free_space_coalesced;

TABLESPACE_NAME                EXTENTS_COALESCED BLOCKS_COALESCED
------------------------------ ----------------- ----------------
SYSTEM                                        2              448
UNDOTBS1                                      15            4312
USERS                                          1            26416
EYGLE                                          1            12464

SQL> select tablespace_name,EXTENT_MANAGEMENT,ALLOCATION_TYPE from dba_tablespaces;

TABLESPACE_NAME                EXTENT_MAN ALLOCATIO
------------------------------ ---------- ---------
SYSTEM                        LOCAL      SYSTEM
UNDOTBS1                      LOCAL      SYSTEM
TEMP                          LOCAL      UNIFORM
USERS                          LOCAL      SYSTEM
EYGLE                          LOCAL      SYSTEM
TEMP2                          LOCAL      UNIFORM

6 rows selected.

-The End-

Posted by eygle at 12:04 AM | Comments (2)

---

February 21, 2008

IBM ThinkPad-如何激活和关闭数字小键盘

作者:eygle

出处:http://blog.eygle.com

刚刚打开笔记本，发现不知道什么时候打开了数字小键盘。

补充：后来发现，在演讲使用过终端登陆笔记本后，数字小键盘被自动启用。

也就是说，uiojklm等字母键不再显示字母，而是输出数字，一直没注意怎么打开和关闭Thinkpad的小键盘。
一时还有点手足无措，打算Google一下，却连IBM也输入不了，汗。

无奈调出软件盘，搜索一下，找到了解决方案：
按Shift+NumLk/ScrLk就可以激活或关闭数字键盘

知与不知，一字之差难坏人啊:)

祝大家元宵节快乐！

-The End-

Posted by eygle at 9:37 PM | Comments (13)

---