eygle.com   eygle.com
eygle.com  
 

« February 2007 | Blog首页 | April 2007 »

上一页 1 2 3 下一页


March 18, 2007

ntoskrnl.exe文件丢失或损坏的问题解决

作者:eygle

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

周末实在是被微软恶心了一把。

Julia的电脑在一次开机后无法启动,XP提示:

Windows could not start because the following file is missing or corrupt:

\system32\ntoskrnl.exe.
Please reinstall a copy of the above file.

ntoskrnl.exe文件找不到了,那么这个文件是干什么的?哪里去了呢?

ntoskrnl.exe是winows的一个进程文件,在系统经过预启动和启动阶段后进入内核调用阶段时由Ntldr调用Ntoskrnl.exe, 在WINXP系统中存储了WIN XP的启动LOGO画面。
调用Ntoskrnl.exe文件时将由Ntdetect.com收集的硬件信息传递给它,同时被调用的还有hal.dll文件.

关于这个进程的官方描述是:

ntoskrnl - ntoskrnl.exe - 进程信息
进程文件: ntoskrnl 或者 ntoskrnl.exe
进程名称: Microsoft Boot Up Kernel

描述:
ntoskrnl.exe是保护性的进程,在你计算机反复启动的情况下出现。在正常情况下,在任务管理器是不会有该进程的。注意:ntoskrnl.exe也可能是w32.bolzano病毒。请使用杀毒软件进行查杀。
出品者: Microsoft
属于: Microsoft Windows Operating System

也就是说,如果这个文件丢失或损坏,Windows Xp启动时那个Logo都出不来,也就没有下一步可以看了。

昨天尝试了很多方法,光盘上的copy、解压覆盖,系统上的备份覆盖还是不管用。
最后放弃了,修复安装,结果今天打补丁到某次重起后,问题再次出现。

现在我不能忍受再次重装了,于是反复研究,终于还是找到了一个合适的版本。
在 "c:\windows\driver cache\i386"目录下有sp2.cab和sp1.cab文件,存放了不同补丁包的一些驱动文件,我将sp2.cab中的ntoskrnl.exe解压缩出来,终于恢复了系统:

expand sp2.cab -F:ntoskrnl.exe c:\windows\system32

当然首先要用光盘启动到修复模式,进入命令行进行操作。
看来是微软的某个Patch有问题,覆盖之后会导致系统无法启动。
目前的怀疑对象是:KB890859

网友提供了另外一个更简便的方法
遇到这个问题,实际上只要取消启动画面就可以了。
在系统中打开'开始-运行',输入MSCONFIG点击'确定'后即打开了系统配置实用程序。
点击切换到BOOT.INI选项页,在'启动选项'功能区域中选中'/NOGUIBOOT.INI'复选项。
这个选项使得启动时不显示启动画面,从而可以跳过这个错误。但是一个问题是,如果你的系统已经无法启动,是无法来使用MSCONFIG的。
那么我们可以将计算机通过光盘启动到命令行修复模式,编辑boot.ini文件,加入该选项:

[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect /noguiboot

这个方法值得尝试。

当然,这个错误还可能和启动列表损坏或者硬件有关。
有网友遇到的是内存问题,通过清洁、重新插拔或更换内存得以解决

关于Windows 2000上的问题,可以参考微软的支持文章:
http://support.microsoft.com/kb/124550/
关于Xp的参考文章:
http://support.microsoft.com/kb/314477/

-The End-

Posted by eygle at 6:19 PM | Comments (57)


March 17, 2007

新书最后章节框架性定稿

作者:eygle

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

今早,完成了新书最后一章的框架性写作,最后一章初步定名为《故障诊断及分析》,将自己总结的故障分析法展现出来。

完成了这一章的内容,这本新书的框架就基本确定了下来,主体结构也基本具备。
那么剩下来的工作就是对部分章节进行进一步的补充、完善直至最终定稿,还有很多事情要做,但是好在架构已经搭起来了。

这本书中最重要也最艰难的部分是备份恢复章节,Statspack和AWR章节,这些章节的写作花费了我大量的时间和精力,其中很多东西绝对是值得阅读的,我希望我的读者朋友们能够从这些阅读中有所收获。对于Statspack是曾经一度打算放弃的内容,可是一直有很多朋友关心、询问相关的内容,这一次重写改写了以前的文章,将Statspack提高到另外一个层次上进行解析,使得这部分内容更多的具备了可以跨越版本存在的价值。

今天下午在IT168和博文视点的朋友有了一个下午的聚会和讨论,他们有很多很好的策划,期望和ITPUB进行合作,不过也许出版社的想法和我的个人想法会有所不同,我一直对写作非常谨慎,构思不成熟就几乎不会动笔,而一旦构思成熟就可能通宵达旦写个不停,这一本书中很多重要章节都是这样写成的,整个过程非常具有写作的冲动,我相信这些作品的价值。我最关注的是写作的质量。

希望接下来的工作不要太艰难,希望这本书值得期待。

-The End-

Posted by eygle at 9:15 PM | Comments (17)


March 16, 2007

这几天来...

作者:eygle

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

这几天来,一直在埋头写书,所以Blog也没有更新了。

写作进行的非常顺利,而且在写作过程中,不断有新的、有趣的发现,在这个过程中,自己学到了很多新的东西。

现在每天的状态就是把脑子里的东西不停的写出来,内容没有问题、架构没有问题,只是时间和打字的速度有点问题。

现在写到倒数第二章,当然还只是第一稿,有很多地方需要修改,但是框架已经打好,欠的只是时间和火候而已。

现在是和时间赛跑,因为很多事情就要等着我去办了....
这期间收到很多朋友的邮件和提问,几乎没什么时间回答,也许过一段时间就好了。

-The End-

Posted by eygle at 10:02 AM | Comments (6)


March 13, 2007

雅虎中国Oracle DBA职位虚席以待

作者:eygle

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

Che Dong发布一则招聘信息(这则信息可能已经在ITPUB上发布过了),但是现在仍然空缺:

北京--Oracle DBA--雅虎中国

职位描述:
维护业务核心数据库的7*24运行;
参与和协助业务逻辑的开发级设计和规划;
支持和辅导中级DBA;

任职资格:
本科以上学历,5年以上专职Oracle DBA经验。 团队合作精神较强;性格乐观;具备创新精神;热爱技术;

1.有TB级,7*24数据库维护经验最佳;
2.很强的SQL调优以及应用调优经验;
3.熟悉常用的Oracle debug工具并具备较多的故障诊断经历;
4.熟悉RAC/Data guard,能对每种HA技术扬长避短;
5.较好的驾驭SQL;
6.具备前瞻的知识和眼光;

备注:
具备良好的价值观;
能承受较大的压力;
较好的进取心;
待遇根据具体能力定,至少10k以上

如果在ITPUB上注册,请大家发出简历的同时给出自己在论坛上的ID。
联系人: zhaojuan@alibaba-inc.com

估计这个DBA的面试也是由Biti他们进行的:)
看来DBA的春天也来到了,最近看到的关于DBA的职位越来越多了。

-The End-

Posted by eygle at 5:08 PM | Comments (6)


March 12, 2007

今天将成为一个纪念日

作者:eygle

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

今天将成为一个纪念日,不是植树节,是我和Julia的结婚登记纪念日。

虽然婚礼已经举行过了,可是法律上的手续今天才履行,原因是Julia的户口迁入北京刚刚办妥。
从2006年11月我开始奔波户口的事情,到2007年3月终于搞定,彻底为伟大祖国的户口制度所折服。

今天下午先跑Fesco借出了Julia的户口卡,然后开始去找朝阳区的婚姻登记处,从网上找到这个地址:
朝阳区民政局婚姻登记处 朝阳区劲松中街四区405楼甲 电话:67785618

看网上说这个地方很难找,坐在出租车上看司机一无所知的样子,我只好拿出手机来Google一把,还别说得出的信息很有用,原来婚姻登记处就在劲松电影院旁边,当然司机还是不知道,还好我们选择了最好的下车地点,几步路就找到了。
然后发现居然曾经路过那里,713路公共汽车正好经过登记处的门前。

整个登记的过程很简单,登记,领号,如同在银行排队一样,听见喊名字的时候走进去,一切都是那么迅速,我数了一下,在我们前面一共只有11对登记。

晚上看了一场电影《痴男怨女-A Good Women》,轻松愉悦的片子,整个放映室里,除了我们俩就只有一个似乎在睡觉的老大爷,时间缓慢,心情放松,一切都是那么的美好:)

放一张周末拍的花朵,春天的气息已经来到北京:
春的气息

祝愿大家都有一个美好的心情和美好的春天!

-No End-

Posted by eygle at 8:12 PM | Comments (22)


March 11, 2007

Oracle与Linux/Unix下的时间处理

作者:eygle

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

在Linux/Unix上,Oracle在很多地方都从系统取得时间。

记录一下Linux/Unix上的时间处理:

UNIX及Linux的时间系统是由「新纪元时间」Epoch开始计算起,单位为秒,Epoch则是指定为1970年一月一日凌晨零点零分零秒,格林威治时间。
目前大部份的UNIX系统都是用32位元来记录时间,正值表示为1970以后,负值则表示1970年以前。我们可以很简单地计算出其时间领域:

2^31/86400(s) = 24855.13481(天) ~ 68.0958(年)

1970+68.0958 = 2038.0958
1970-68.0958 = 1901.9042

时间领域为[1901.9042,2038.0958]。

准确的时间为2038年一月十八日星期一晚上十点十四分七秒。那一刻,时间将会转为负数,变成1901年十二月十三日黑色星期五下午三点四十五分五十二秒,然後Jason就会跑出来用斧头砸掉您的电脑。

这就是所谓的UNIX 2038 BUG,或者您也可戏称为Jason hatchet bug。在大部份的UNIX上,并没有所谓Y2K问题,不过都有2038年问题。

在一些64位元的平台上,例如Digital Alpha、SGI、Sparc等等,则用64位元来表示时间。

2^63/86400 ~ 1E14(天) ~ 2.92E11(年)

大约是292亿年。

因此,使用64位元的电脑可能会有Armageddon bug的问题。届时位於猎户座旋臂的太阳,已经是黑矮星或暗黑物质,猎户座旋臂大概也已经被重力波震断,银河系大概则已经变成小型似星体了。

虽然许多人认为UNIX的2038年问题会随着科技的进步,而将电脑逐步汰换成64位元电脑,因此无须担心。但我个人相信,在2038年,依然会有许多状况出现。因为,就事实而言,目前许多UNIX系统都有足够的能力服役到2038年而毫无问题。因此,如果有意添购电脑主机,而且有预期会使用到那个时候,最好是选购64位元电脑,确认只有世界末日问题(除非您想要把资料流传给下一个宇宙,那就要另当别论了)。

以上资料转引自网络

-The End-

Posted by eygle at 7:24 PM | Comments (6)


March 8, 2007

Windows还能删什么-ServicePackFiles or dllcache

作者:eygle

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

晚上帮Julia整理电脑,删除了很多备份的系统文件,最后停在了ServicePackFiles 和 dllcache两个目录前。

以前刚工作时电脑的硬盘很小,只有4G,所以整天研究要释放空间出来,几乎所有的目录都琢磨过,以前这两个目录是一定干掉的,现在就止步于此,手下留情了。

这两个文件夹一个位于:
C:\WINDOWS\ServicePackFiles\i386
一个位于:
C:\WINDOWS\system32\dllcache(具有隐藏系统属性)

其中的部分文件是重复的,主要是用于Windows的文件系统保护。

Windows有很多动态链接库(.dll )和可执行文件(.exe )等系统文件对于系统的稳定运行至关紧要,如果这些文件被删除和替换,就可能会造成系统运行不稳定,实际上,很多病毒就经常篡改和伪装成系统文件或程序,而在安装软件时,覆盖一些共享系统文件是极为常见的。

为保护系统的可靠及稳定性,windows有一个“文件保护”的后台服务,默认情况下,该服务一直处于启用状态,监视着所有受保护的系统文件,如果发现替换或移动受保护的系统文件企图,它能直接阻止,在文件被异常替换后,Windows会自动恢复这些文件。

ServicePackFiles 文件夹,对 Service Pack 文件提供保护,同时也提供对于一些系统组件的安装维护服务;而dllcache主要对system32下的dll文件进行防护。

我最初玩Windows的时候,当删除了扫雷游戏后,发现转眼又回来了一个,再删除又回来,最后才发现了dllcache这个目录。

即然Windows对这些文件委以重任,在空间不太紧缺的今天,我们还是留下他们吧。

处理ServicePackFiles文件夹的一个可选方法是:移动。
转移位置后,可以通过修改注册表的键值来告知系统,注册表位置位于:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\ServicePackSourcePath

-The End-

Posted by eygle at 9:38 PM | Comments (5)


2007我的新书写作计划及进度

作者:eygle

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

最近比较忙一点,所以Blog也很少更新。

今天将新书计划包含的内容发布出来,听取一下大家的意见。
这本书的名称还没确定,所以暂时沿用了最初的《Oracle初学者指南》这个名字。

这本书仍然不是一本基本的书,所有的讲解都是由点及面、由浅入深,但是增加了一些Windows平台上的内容,虽然Oracle的数据库知识基本上和平台无关,但是为了照顾一下这个最广泛的应用平台仍然兼顾了一下。

现在本书的内容已经完成了50%以上,最近正在写备份恢复一章,这部分内容写的有点多,已经接近了100页,现在只是想着一路写下去,可能最后再作一些删减和压缩。

下图是本书计划包含的一些内容,部分已经完成。
这本书和《深入浅出Oracle》结合起来,将是较为完善和完整的Oracle体系结构参考:

欢迎大家对本书多提意见。

顺祝天下所有的女同胞节日快乐,尤其是身为DBA的女同志们!

-The End-

Posted by eygle at 10:05 AM | Comments (17)


March 7, 2007

Oracle Peeking绑定变量的控制

作者:eygle

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

我们知道从Oracle9i开始,Oracle引入了Peeking of User-Defined Bind Variables的特性,这个特性可以用来在存在数据倾斜时对执行计划纠偏。
然而这一特性也可能带来一些副作用,所以Oracle同时引入了一个内部参数用于控制这一特性:

SQL> SELECT x.ksppinm NAME, y.ksppstvl VALUE, x.ksppdesc describ
2 FROM SYS.x$ksppi x, SYS.x$ksppcv y
3 WHERE x.inst_id = USERENV ('Instance')
4 AND y.inst_id = USERENV ('Instance')
5 AND x.indx = y.indx
6 AND x.ksppinm LIKE '%&par%'
7 /
Enter value for par: peek
old 6: AND x.ksppinm LIKE '%&par%'
new 6: AND x.ksppinm LIKE '%peek%'

NAME VALUE DESCRIB
------------------------------ -------------------- ------------------------------
_optim_peek_user_binds TRUE enable peeking of user binds

这个参数缺省值为True,当设置为False时将禁用peeking of user binds.

-The End-

Posted by eygle at 3:13 PM | Comments (7)


March 6, 2007

Oracle ACE更新 发布中国ACE信息

作者:eygle

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

Fenng提醒我,Oracle官方网站的ACE信息已经更新,大量ACE信息被加入进来,这其中也包括中国的一批ACE们。

我的个人信息也被加入进去,纪念一下:

Oracle.Ace.Eygle

Fenng的另外一个发现是,Kamus被误作女士:

Lori started her career at Oracle as a DBA and now transitioned into a technical consultant role. She has worked on many Oracle Database projects and is most familiar with High Availabilty Technology. She is an Oracle Certified Professional for Oracle8i and Oracle9i

难道Lori这个词像女孩的名字?

而且这一次,Steve Adams被加入到ACE的行列,这位大师终于出现。

-The End-

Posted by eygle at 2:33 PM | Comments (5)


上一页 1 2 3 下一页


CopyRight © 2004-2008 eygle.com, All rights reserved.