Roby's profileblue_princePhotosBlogListsMore  |  Tools Help |
|
March 13 MSN 8.5去除广告栏和共享文件夹 这两天受不了MSN不断的提示有新版本升级，就升级到新版本8.5.1302.1018。升级过后发现原来可以单独去掉的广告栏再没有选项去掉，而且这个广告栏显示的是FLASH动画，鼠标一移至那边就变成大幅的动画，让我感觉很不爽。于是就上网找办法去掉广告栏，在经过多次不断的测试和重启后，终于搞定了这个问题。首先下载一个ResHacker，然后打开MSN安装目录下的msgsres.dll这个文件，先备份一下，然后对它进行更改：
1.去除界面上的广告： 打开msgsres.dll中的4004－923,查找里面的"ID=Atom(SSConstrainer)",不包括两头双引号,将前面的layoutpos=top改为layoutpos=none,编译保存,OK 2.去除对话框下面文字广告方法： 打开msgsres.dll，查找：<element id=atom(adbannercont) layout=filllayout()> 改为:<element layoutpos=none> 3.去除界面底部搜索栏： 在上边的文件中查找"idSearchContainer" 将上边的"layoutpos=bottom"改成"layoutpos=none" 4.去除MSN共享文件夹，打开MSN安装目录下的fsshext.8.5.1235.0517.dll，先备份一下，再找到registry，下面有一个102，删除，保存编译。然后，到注册表里删除下面的键值 HKEY_LOCAL_MACHINE＼SOFTWARE＼Microsoft＼Windows＼CurrentVersion＼Explorer＼MyComputer＼NameSpace＼{FC9FB64A-1EB2-4CCF-AF5E-1A497A9B5C2D} 这个键值里面有一条默认的内容设置是：Messenger Sharing Folders 注意：FC9FB64A-1EB2-4CCF-AF5E-1A497A9B5C2D可能不同机器是不一样的 将这个键值删除，重启后共享文件夹就去掉了。 March 12 晶晶小妹 从春节年后开始，ITPUB突然间冒出了个晶晶小妹，在ORACLE数据库管理版发了众多高质量的关于Oracle Internals的深入研究帖子，给日渐平淡的论坛吹来了一股清新之风。一时间关于此ID的种种猜测便不绝于耳，对于一个突然间冒出来的技术黑马，加上美女、DBA、初中毕业、20岁……等众多关键字，如果不受到这么多的关注便是奇怪了。据晶晶小妹自己说是15岁初中毕业，因为没考上重点高中便念了一所计算机培训学校，16岁开始工作，接触ORACLE 2年，今年不到20岁。尽管她在论坛上很诚挚的把自己的情况都公开了，不过还是不免引来一些怀疑，因为实在想像不出一个20岁不到的初中毕业的女孩子能够有这么深厚的技术功底。于是便有人怀疑这个ID的真实性，大家不约而同的猜测这可能是一个马甲，有人说是两个老爷们联合用的一个马甲。最后面ITPUB推出视频专访，才把这一切底细都弄清楚了，晶晶小妹之前说的种种都是真实的。看了她的一些帖子，技术总结确实很不错，不过感觉她的那些个人感悟更是值得一看，文笔甚佳，不论是不是搞技术的看了都会有所感慨。呵呵，想必你也对这个不到20岁的小女孩子感兴趣了吧，那么上她的BLOG去看看吧，里面有她的照片哦：http://space.itpub.net/13095417/ March 07 说说在Metalink上开SR这件事看到一个朋友的MSN签名是：“我不是在开SR，就是准备在开SR”。心里颇有感触，这个朋友是做ORACLE ERP的，听说ORACLE ERP非常复杂，需要经常上METALINK求助。做为一名ORACLE DBA，METALINK是非常重要的资料来源，很多案例查一下METALINK都会有比较好的解决方案。不过METALINK也不是万能的，碰到没有相似的方案，你只能开SR求助于ORACLE SUPPORT了。 我在去年以前从来没有在METALINK上开过SR，基本上日常工作碰到的问题都可以通过种种办法查出原因并解决。但是在采用了最新的Oracle 10g R2 RAC数据库后，碰到了一系列莫名其妙的问题，这时候便只好开SR求助了。从开第一个SR到现在一共开了有十几个SR，真正解决问题的没有几个，往往都是不了了之。最开始便是让你发一通文件，这些文件分布在RAC的好几台主机，我只好一台台主机去找他们要求的文件最后面再打包上传。这是一个非常烦琐的过程，OS日志、CRS日志、CSS日志、alert log、TRACE文件……结果我好不容易将一大堆文件打包上传了，格式是.rar格式的，他们只能打开.zip格式的压缩包，要求重新上传。重新上传完以后，他们说根据已经上传的这些文件还是找不出原因，让部署Oracle的OS Watcher这个工具，等以后出现类似问题时再找原因。于是费了一番精力再部署这东西上去，另外他们还要求部署RDA，也一并弄上去。结果有一次再出现类似问题后，又是一通地找文件，最后压缩文件居然有500MB之大。在自己机器上上传了一天传不上去，就在同事的机器上挂机传了一天。这次传上去了，结果SUPPORTER跟我说传上去的文件太大了，他们也无法打开，让我再传至METALINK的FTP，好，再折腾，又费了一天传至FTP。结果他们还是没有找到问题，给我来这么一句：Now it seems to be LMS are started in Real time mode.We can check if the problem is re-producing or not。只能关掉SR，等待问题重现时再让他们诊断。于是这个SR到现在一个半月了，中间交涉了好多次，今天我还在上传他们要求的文件。 还有另外一次我们生产库的ASM磁盘头损坏，我们之前都没碰到这一类的故障，METALINK上也没有相应案例。我开了1级紧急SR，本来指望他们响应快一些，结果他们还是慢吞吞地在处理，最多的一句话是：Thank you for your patience。而且Oracle Support技术水平不一，有些SUPPORT根据内部文档给出一个建议后也不说明为什么要这么做，下一步要做什么？我们碰到ASM磁盘头损坏后第一个SUPPORT一个劲地让我们清空前1M的内容。问他为什么要清空前1MB的内容他就是不说，就说对照着做把结果告诉他就行了？我们问那清空后下一步怎么办？他就是不说，最后面发现他找到一个错误的解决案例，假如我们按这个SUPPORT的建议来处理的话，那么有可能会丢失整个数据库的数据。还是这个案例，后面问题解决了，我们要找出原因，他们说根据ORACLE的策略，只能另外开一个SR。另外开了SR后，换了另外一个SUPPORT来支持了，结果这个SUPPORT又不清楚具体的情况，于是我又费了一番周折把情况说明清楚，英语本来就不好，好不容易憋出几句英文把情况说明清楚，结果响应又巨慢无比。只好通过销售来推动，这次倒好了，说是因为时区的关系，我的SR负责的工程师刚好是非洲的，而且又出去度假去了。给我换了个印度的工程师，又是不熟悉情况，又是从头介绍情况，结果现在还是在处理状态。 还有一些其他的问题，总之指望METALINK来解决问题你需要足够的耐心，也不能指望能够解决紧急的问题。话说回来，通过网络来解决问题，在对具体环境不熟悉的情况下，他们是需要调查清楚情况后再做出处理，或许他们在工作的同时也在处理其他的案例，毕竟不仅仅就你这么一个案例。ORACLE也有自己的流程和策略，不过这个流程对于用户来说实在是太繁琐了。 SR，你让我怎么说你才好？ March 06 解决STANDBY ASM添加数据文件失败故障今天凌晨STANDBY突然出错，导致数据库实例和ASM实例通信的ASMB进程宕掉，无法连接ASM实例，数据库直接宕掉。 Successfully added datafile 430 to media recovery 重启数据库以后，发现无法创建主库新添加的数据文件，显然是由于恢复过程中的突然宕机，现在控制文件无法识别新创建的数据文件： Thu Mar 6 04:55:32 2008 由于主库和备库都采用ASM做为存储方案，数据文件名在主库和备库上面都会不一样，那么是无法采用常规解决办法进行处理的。 正确的处理办法是首先将standby_file_management从原来的true改为false，然后手工创建出错的数据文件： alter database create datafile 432 as '+data' size 20g autoextend off; 记住这里面的size和autoextend特性都必须按主库添加数据文件时该文件的参数显式指定的，要不将会添加失败。 处理好后记得把standby_file_management改回到true，要不STANDBY数据库添加接下新增的数据文件又会出错。 March 05 不顺从2008的开始到现在一直很不顺，发生很多让自己失望的事情。很多东西你必须承担但是却无能为力，付出了不一定会有回报，结果是最重要的。想明白了一件事：当感到迷茫困惑的时候，不要想得太多，尽力先把手头的事做好。只要自己尽力了就行，结果不是自己所能左右的。 |
|
|
