May 31, 2007
个人网站之CPU超高负载
作者:eygle
出处:http://blog.eygle.com
今天网站的复杂达到了超高的水平:
[root@eygle ~]# uptime
09:59:02 up 23:43, 2 users, load average: 252.86, 414.80, 273.51[root@eygle ~]# uptime
10:02:15 up 23:46, 2 users, load average: 85.78, 252.07, 235.71
差一点点就崩溃了,重建了一下内容,将几个比较消耗资源的perl和php脚本去掉了,看看会不会有一些好转。
不过还是经不住搜索引擎的攻击,流量真实恐怖。
-The End-
Posted by eygle at 10:52 AM | Comments (6)
May 29, 2007
安装了Oracle10g 10.2.0.3 感受众多BUG
作者:eygle
出处:http://blog.eygle.com
今天,终于还是在笔记本上装上了Oracle,打过Patch之后的版本是10.2.0.3SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Prod
PL/SQL Release 10.2.0.3.0 - Production
CORE 10.2.0.3.0 Production
TNS for 32-bit Windows: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 - Production
看一下Bug修正列表,在关心的几个环节浏览了一下。
首先是ASSM的一堆Bug:
| Fixed in Release | Bug Number | Description |
|---|---|---|
| 10.2.0.3 | 3279497 | Interupted (Ctrl-C) TRUNCATE can corrupt ASSM table |
| 10.2.0.3 | 3610777 | Excessive CPU from INDEX insert into ASSM index segment |
| 10.2.0.3 | 4055634 | TRUNCATE table has to much overhead when operating on empty segments |
| 10.2.0.3 | 4188324 | Wasted space possible in ASSM segments |
| 10.2.0.3 | 4475314 | DELETE then INSERT without commit on ASSM segment can be slow |
| 10.2.0.3 | 4660718 | Allow choice between space / performance for ASSM segments |
| 10.2.0.3 | 4694312 | Index inserts to ASSM segments can be slow |
| 10.2.0.3 | 4887955 | Unnecessary extent allocated in locally managed ASSM tablespace in RAC |
| 10.2.0.3 | 5034679 | Hang / errors making ASSM tablespace read only with concurrent DML |
| 10.2.0.3 | 5349632 | Poor performance for ASSM insert after large DELETE |
| 10.2.0.2 | 4288876 | Excessive redo / undo generation from insert/update with ASSM indexes |
| 10.2.0.2 | 4486753 | DMLS contention with ASSM segments |
| 10.2.0.2 | 4517470 | Table corruption with RAC when ASSM managed and truncate used |
不看不知道,一看吓一跳吧,ASSM的Bug还真不少,而且还都是比较恐怖的Bug。
再看看10g的一大亮点ASM的BUG:
| Fixed in Release | Bug Number | Description |
|---|---|---|
| 10.2.0.3 | 3811904 | Rebalance can fail if there is one full disk |
| 10.2.0.3 | 3885499 | ASM hang possible |
| 10.2.0.3 | 4229751 | CONVERT TABLESPACE fails to create file with DB_FILE_NAME_CONVERT on ASM |
| 10.2.0.3 | 4450268 | ASM disk mounts are serialized |
| 10.2.0.3 | 4466433 | Restoring current controlfile on ASM creates a file with "backup" string |
| 10.2.0.3 | 4561867 | ASMB may exit prematurely causing OERI in client |
| 10.2.0.3 | 4671721 | OERI [kfcInitDlocn02] possible in ASM instance |
| 10.2.0.3 | 4691191 | Failure during file grow may leak ASM disk space |
| 10.2.0.3 | 4709210 | ASM LMS OERI[504] on [kfcl le freelist] latch |
| 10.2.0.3 | 4709214 | ASM may crash with OERI[kfclGetLock40] |
| 10.2.0.3 | 4752481 | Skewed ASM disk allocation when single file resized many times |
| 10.2.0.3 | 4865736 | ASM resource should not have dependency on VIP |
| 10.2.0.3 | 4872617 | Dump (kfclDumpLe) in ASM |
| 10.2.0.3 | 4883032 | ASM fails with ORA-15096 during crash or instance recovery |
| 10.2.0.3 | 4886660 | ASMB can fail with OERI:kffmAllocate_1 |
| 10.2.0.3 | 4907496 | Processes hang after adding disk back to ASM diskgroup using force option |
| 10.2.0.3 | 4943406 | LMON needs to message SMON to start recovery in ASM instance |
| 10.2.0.3 | 4960705 | ASM waits longer than necessary during reconfiguration |
| 10.2.0.3 | 4966352 | OERI[unsorted_pins_4] possible on ASM |
| 10.2.0.3 | 4967266 | DB recovery blocked by ASM recovery |
| 10.2.0.3 | 5012099 | ASM rebalance problems |
| 10.2.0.3 | 5024639 | ASM hangs if private interface down on a surviving node |
| 10.2.0.3 | 5039964 | ASM disks show as provisioned although kfed shows valid disk header |
| 10.2.0.3 | 5089630 | Dump (kfncInitSlavePool) / ORA-15012 from Log Miner / Streams against LOGs on ASM |
| 10.2.0.3 | 5090822 | OERI[17092] / ORA-10382 when ASM IO completes concurrently with DISKGROUP dismount |
| 10.2.0.3 | 5134663 | OERI[2103] with ASM |
| 10.2.0.3 | 5226903 | OERI:[kfcDeadlockAvoid01] when running "check all repair" |
| 10.2.0.3 | 5360719 | ASM and database instances hang when disk array gets disconnected |
| 10.2.0.3 | 5515492 | Data corruption when ASM failgroup removed |
| 10.2.0.2 | 4747535 * | A diskgroup cannot be mounted on both nodes at the same time. This bug is alerted in Note:353065.1 |
| 10.2.0.2 | 4237629 | OERI[kfdjoin5] on ASM instance with multiple diskgroups |
| 10.2.0.2 | 4362919 | CRS ASM failure recovery does not recover database instances |
| 10.2.0.2 | 4413010 | OERI[kffdmove01] selecting from V$ASM_ALIAS in ASM instance |
| 10.2.0.2 | 4455512 | ASM instance startup can be slow in RAC environments |
| 10.2.0.2 | 4478323 | OERI[kfcDeadlockAvoid01] on SQL against V$ASM_ALIAS |
| 10.2.0.2 | 4490933 | RMAN backup fails when backupsize > free on ASM but reclaimable space available |
| 10.2.0.2 | 4503419 | Cannot drop disk normal with less than 3 failgroups |
| 10.2.0.2 | 4550821 | OERI[kfklufsscannext] in ASM during disk discovery |
| 10.2.0.2 | 4666938 | OERI[kjbdowncvt:__l] can occur in ASM |
| 10.2.0.2 | 4671216 | ASM operations on a file are blocked while it is resized |
| 10.2.0.2 | 4693247 | Dump (kfcgetbuffer) while resizing a tablespace using ASM storage |
| 10.2.0.2 | 4700681 | ASM disk shrinkage can corrupt ASM metadata |
| 10.2.0.2 | 4772979 | OERI[kfdskAlloc0] in RDBMS instance when adding back a dropped disk |
建议大家看看Bug列表,还是有好处的,这就可以知道在自己的产品环境上可以去避免哪些问题。
这些Bug遇到的不多,不错CRS的Bug却是遇到了不少,BUG列表里关于CRS的BUG太多,不列了。
-The End-
Posted by eygle at 4:27 PM | Comments (13)
DBA警示录:Move数据表与索引重建
作者:eygle
出处:http://blog.eygle.com
昨天在ITPUB上再次看到一个由Move操作引发的故障。
导致故障的原因是:
对表做了move后,没有rebuild index,然后就关闭数据库了,导致数据库不能重新启动
此时Alert文件中记录了如下信息:
Errors in file /space/oracle/admin/test/udump/test_ora_22836.trc:
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01502: index 'SYS.I_ACCESS1' or partition of such index is in unusable state
Mon May 28 16:31:10 2007
Error 704 happened during db open, shutting down database
USER: terminating instance due to error 704
Instance terminated by USER, pid = 22836
ORA-1092 signalled during: ALTER DATABASE OPEN...
上一次见到类似的事故是在2005-11-18,已经快2年的时间,所以怎么说呢,应该说事故并非多发。
不过还是有必要提醒一下大家:
SYS的对象最好不要轻易Move,出于谨慎以及对于DBA的基本要求,如果真要操作SYS对象,一定要做好完备的测试。当然数据库的备份是必不可少的。
-The End-
Posted by eygle at 9:05 AM | Comments (0)
May 25, 2007
有多少最大-谷歌将建世界最大个人数据库
作者:eygle
出处:http://blog.eygle.com
今天看到的一则新闻是:谷歌将建世界最大个人数据库 专家担心侵犯隐私。
没有找到这则新闻的英文出处,也许这又是一条中文特色的"最大"新闻。
在一年之中,我们已经听到了太多个"最大",而这个最大也可能是记者冠给Google的。
新闻称:
谷歌宣布将着手建设世界上最大的个人资讯数据库,发展个性化特色服务,将搜索引擎发展成为人们生活不可或缺的助手。但有公众机构质疑,个人资讯数据库或将侵犯公民的个人隐私。
不记新闻来源的确切性,如果Google真的要构建用户个人资讯数据库,那么这个数据规模应当是相当惊人的;而毫无疑问,这样的服务必将更多的介入用户的个人隐私信息。
在上周召开的侠客行大会上,雅虎的两位专家吴炯和陆奇的一个共同观点也是,未来的搜索必将通过对用户的了解进行更精确的营销或服务。
Google和Yahoo!的看法是一致的,而这样的未来也的确是可以预期的。关于隐私的争论,我想并不会影响技术的进程,搜索引擎以及构建于起上的定向广告必将在未来更加深远的影响我们的生活。
那么Google在使用什么数据库呢?
Oracle在收购了Berkeley DB之后,终于可以说Google在使用Oracle的产品,当然这仅仅是用在用户认证机制上。至于这个"最大"的数据库将搭建在什么数据库或者根本来自Google的自行开发仍未可知。
-The End-
Posted by eygle at 8:41 PM | Comments (2)
DBA警示录:spfile是不能手工修改的
作者:eygle
出处:http://blog.eygle.com
spfile从Oracle9i开始引入,这个文件是二进制的,不能手工修改。
可是直到Oracle10g已经普及的年代,还有朋友在手工修改这个文件,这实在是不应该犯的一个错误。
刚才有个朋友在MSN上问这样一个错误:
Errors in file /u01/app/oracle/admin/orcl/bdump/orcl_mmon_5234.trc:
ORA-00600: internal error code, arguments: [kmgs_parameter_update_timeout_1], [1565], [], [], [], [], [], []
ORA-01565: error in identifying file '/u01/app/oracle/oracle/product/10.2.0/db_1/dbs/spfileorcl.ora'
ORA-27046: file size is not a multiple of logical block size
从后面一个错误号,我们明显能够看出这是一个参数文件损坏的问题。
那么前一个600错误呢?
我们知道Oracle在运行阶段是不锁定spfile的,所以spfile的问题要等到下一次修改或使用时才能发现。
那么这里MMON进程在修改参数文件的什么内容呢?
初学者可以思考和探索一下这个小问题。
-The End-
Posted by eygle at 5:11 PM | Comments (3)
May 24, 2007
DBA警示录:日志文件该如何命名?
作者:eygle
出处:http://blog.eygle.com
最近这3天,在MSN上已经有两个朋友问到关于Redo Log File的问题。
第一个朋友说:
同事用优化大师进行系统优化,结果把所有扩展名为log的文件都删除了,Oracle就此崩溃。
第二位朋友说:
同事为了释放空间,手工把所有log文件都清空了,Oracle就此崩溃。
其实这样的事故已经遇到过很多次了,这种情况的恢复可能简单,也可能非常复杂,如果没有备份,那么恢复真就是要看运气了,当然最后还会有DUL或AUL可以采用。
但是为什么不避免这样的故障呢?虽然这样的系统显然并不重要。
如果可能,我建议Oracle将日志文件的扩展名改为.dbf,这样就安全多了;曾经有很多朋友在MSN上问我,很多归档日志的扩展名是.dbf,能不能删除?
看来扩展名实在是害人不浅,而IT技术还应该继续深入普及。
-The End-
Posted by eygle at 3:51 PM | Comments (5)
怎么开始 又应该如何结束?
作者:eygle
出处:http://blog.eygle.com
昨天,和老板谈了一下自己的想法,正式提出辞呈。
剩下的就是继任人选的安排、工作的交接,然后收拾东西走人。
是不是每个结束都大致相同?
上一份工作还是在昆明,放弃一份工作也放弃了一个城市,然后来到了北京,在昆明积累了多年的书籍也是去年刚刚才运到北京;在北京,4年来都是在为这一家公司服务,现在终于也走到了结束的时候。有一份失落,同时也有一份期待。离开一个熟悉的环境需要勇气,对全新的生活则充满向往。
昨天和橘子聊了一会天,她也是刚刚换了公司,当然是走向了更好的方向,从IT转向广告业,只用了3年的时间就上升到了相当高的职位,在业内据说也是一个奇迹。看来只要付出更多的努力,这个世界就会回报给你绚烂的回报。
恭喜我的朋友们,也为自己暗暗祈祷!
说到祈祷,忽然想起从杭州回来的飞机上,一个黑人朋友在起飞前在胸前勾画十字,默默祈祷,那份真诚与自然让人感动,有信仰的人真好。
-The End-
Posted by eygle at 8:42 AM | Comments (29)
May 23, 2007
杭州景美 阿里情深 诺顿害人
作者:eygle
出处:http://blog.eygle.com
停顿了这么多天没有写Blog,一方面是因为杭州之行,一方面却是因为被Norton在5.18坑害了一把。
去杭州之前,发现计算机蓝屏,错误号触目惊心:unknown hard error
当时没时间仔细研究,之后顺手塞了一张光盘到背包里,心想,大不了我再重装一次吧。
于是就这样背着一堆废铁来到了杭州,好在之前已经将PPT发送给了主办方,心里也就没有了什么负担,于是就将电脑丢在了酒店。当我向朋友描述症状时,他们马上告诉我,这是Norton捣的鬼。于是,我晕了。在最后一天时,还是重装了一套操作系统,反正距离上次重装如此之近,以致软件都没有安装多少。回到北京之后,又将家里的电脑重装了一下,准备离开公司后使用。于是这个月成了装机最为频繁的一个月。
撇除电脑的困扰,个人的抉择,这次的杭州之行实在是一次快乐的旅行,见到了众多的朋友,欣赏了杭州的美景,陪着老婆在西湖边上闲散的漫步,轻松而又快乐。
阿里的"中国网络工程师侠客行"大会举办的非常成功,从接待、组织到会场,一切工作做得都相当完美。很多工作人员都是阿里的员工,Julia说,从这些人的面貌和行动上可以看出,他们真的是在全心全意的为大会服务。这就是阿里的力量,所有的人都在为一个理想而奋斗。
如果说还有什么遗憾的话,那就是时间太短,如果会议的时间不是在周末而是周四、周五,那么可能大家就可以利用周末的时间在杭州再做停留,继续感受一下杭州的美丽,另外,或者可以考虑安排一下参观阿里的活动,虽然我有那么多朋友在阿里工作,却没有到过阿里的办公室,总是一个遗憾。
-to be continued ....
Posted by eygle at 10:55 AM | Comments (12)
May 17, 2007
从开始的地方结束 期待明天
作者:eygle
出处:http://blog.eygle.com
今天找出公司的劳动合同,这一天是合同上的最后一天。
到今天为止,到这个公司工作已经有4年零一个月
从2003年4月1日来到北京,4月17日和公司签约,北京的这段生涯一直在为这家公司服务,想想时间已经不算短了。
忽然可以作出一个决定,离开这家公司,从开始的地方结束,也算是功德圆满了。
明天从什么地方开始,还没有想好,但是有一点是清晰的,结束必定会有一个更好的开始。
-The End-
Posted by eygle at 8:52 PM | Comments (51)
明天赴杭参加"中国网络工程师侠客行"大会
作者:eygle
出处:http://blog.eygle.com
这个周末,阿里巴巴的网络工程师侠客行大会将在杭州举办,明晚将乘飞机赶赴杭州。
承主办方邀请,在会议上还有一个小小的演讲,为了这个演讲还着实费了一番思量,因为不太了解参会人员的组成,也不好将内容讲的过于专业。
所以最后拟定了一个题目:
Oracle Database10g-开启全方位性能优化的时代
打算讲一讲自己在使用Oracle10g的几年来的一点感受,2006年Oracle能够以44.4%的占有率再次占有数据库市场的领先地位,很大程度上取决于Oracle10g的广泛使用和用户接受。
那么在Oracle11g即将来临之前,让自己的这个小小报告对Oracle10g做一点点总结吧。
会务组一直催促我的PPT讲稿,上周五赶了一个PPT出来,希望能够满足会议的需要。
据悉届时将有很多朋友齐聚一堂,而这次距离上一次杭州之行,转眼已经有两年的时光。
-The End-
Posted by eygle at 8:45 AM | Comments (17)
