 | | |
| | |
|
Spaces home  blue_princePhotosProfileFriendsMore |  Tools   |
|
blue_princeMay 07 Qlogic Infiniband RDS高速互联驱动程序安装及配置在配置基于RDS协议的Infiniband高速内部互联的RAC数据库方案时，第一步必须是安装好驱动程序并配置好内部互联的IP地址，保证内部互联配置完成，才能进行下一步的RAC数据库安装和创建。下面简要介绍一下Infiniband安装配置的过程：
这里面的2.6.9-55.Ellargesmp是LINUX的内核版本号，根据安装机器的OS内核而定。重启服务器，执行lsmod 去检查OFED是否还在运行。
编译完成后，该OS上的Ininiband安装文件即可生成，对应安装文件在/u01/InfiniServ.4.1.0.2.2/ALL_HOST/release/redhat/X86_64/InfiniServ.4.1.0.2.2G里面。
屏幕显示如下画面：
选择“1”，屏幕显示如下画面：
上图中显示，P：执行选择的项
提示需要配置多少个ip，默认为1个，如果我们只需设置1个IP地址，直接回车或输入“1”回车，屏幕出现如下画面：
根据屏幕提示输入： 敲入任何键，继续：
在提示 Enable xxx to autostart? [y]: 键入 Y或N 回车,屏幕显示如下图：
提示是否更新HCA firmware 版本，输入 n , 回车，屏幕出现最初画面：
敲入“x”退出安装。 5) 重新启动系统
至此，此节点的Infiniserv软件安装完成。 May 06 Linux上如何不重启识别新存储上周在一台生产机器上添加了一台新存储，并且成功不重启就识别了新添加的LUN。关于如何LINUX不重启如何识别新的LUN，Fenng有过一篇文章介绍过了：Linux 如何不重启而识别新增的 LUN，除了QLogic FC HBA LUN Scan Utility这个脚本，还有其他方式可以也可以识别，具体可以看Fenng BLOG中的回复。这里面简要介绍一下存储的配置过程，我添加的存储是EMC CX700，以此为例。在布好光纤线，配置好光纤交换机的ZONE之后，需要把主机的/etc/Navisphere/agent.config文件里面添加新存储的IP地址，然后重启Naviagent。Naviagent重启的话对于主机现有的存储访问是没有影响的，如果不重启，那么在存储端也是可以看到主机信息的，不过并不会有主机名等详细信息的，需要用户手工添加注册信息。然后就在存储里面配置storage group，把要访问的LUN和主机设置好，按Fenng BLOG中步骤运行QLogic FC HBA LUN Scan Utility，主机上powermt config一下，就识别到新的存储了。值得一提的是，在我的环境中，新添加的LUN没有具体的LUN编号，这个对于使用还是有些麻烦的。 April 22 最近杭州的春天周末老是下雨，上个周末再次印证了我的推测。来杭州快2年了，去年开始发现杭州春季时工作日的天气都出奇的好，但一到周末就下雨。好不容易有个休息日，想出去走走都不成。 最近迷上了HP新推出的迷你小本本HP 2133。一直以来都只喜欢小本本，以前SONY的SRX系列是我了最爱。不过那时候是穷学生，买不起，现在还想收个成色好的二手收藏来着，不过PIII时代的配置到现在确实是过时了。用过DELL的X300，那个本本离我心目中的完美本本已经非常接近了，轻、薄，香槟银镁铝合金外壳，当时由于过于轻薄，后面屏幕被压出了一圈白斑，不得不出掉了。12寸的屏幕我认为还是大了些，10寸左右的正好，这样键盘也不至于太小，要是键盘太小打字就不方便了，为了轻薄牺牲了易用性也是我所不能容忍的。HP2133的配置离我心目中的超轻薄本本的要求已经非常接近了，当然8.9寸的屏幕是小了些，不过上盖多出的空间用于音箱，这样本本的音质就会好些。况且键盘基本上达到95%的标准键盘大小。当然用VIA的CPU是比较不爽的，不过进入迅驰时代以后我对CPU的要求便越来越低了。不玩游戏，只是用电脑看看碟，上上网啥的，现在主流的硬件配置已经足够了。当然还有很重要的一点便是价格便宜，VIA 1.2G CPU、1G内存、120G硬盘的配置卖549美刀，和众多超轻薄本本高不可攀的价格相比，这个价格是够平易近人了。当然外观也是我所注重的，铝合金银色外观是我所喜欢的。嗯，准备到时候整一台，这样外出的时候我就可以只背着这个1.2KG的本本了。 把《24小时》的第一季看完了。继《越狱》之后，最近疯狂地迷恋上了美剧，最疯狂的便是前段时间看《LOST》，一口气看到最新的第四季第8集。看完《LOST》后，以后坐飞机是会担心的，还有对里面时不时出现的一些恐怖场景比较不爽，我胆子还是小的。看美剧我喜欢下载中英文双字幕的版本，这样看的时候尽量看英文字幕，碰到不懂的单词时再看中文字幕。这样对学英语还是有挺大帮助的，明显感觉自己语感好了不少。发现美剧里面的对话都是很简单的，大部分都能看得懂，就是速度太快，有时候来不及只好看中文字幕。以前下载电影时都特地下AVI格式的，然后下载中英文字幕，先看英文，碰到不懂的时候就停下来翻金山词霸，那样看起来怪累人的，最后便都看中文了。现在有些RMVB会有字幕组把中英文字幕都整合起来，看起来就方便多了。我是懒人，这样子学英语对于目前的我来说是个最好的办法。 朋友来杭州工作，周末陪他一起四处找房子。发现现在的房东大部分都是跟自己年龄相仿的80后，想想自己都快租不起房子，人家都在出租房子，差距啊！ ORACLE 10.2.0.4上BUG的补丁好不容易推出了，结果我一装上就报错了。昨天折腾了一下午，昨晚上下班都走到门口了，结果又报错了，只好回来再整。后面不得不把这个PATCH回滚，数据库才恢复正常。对ORACLE的SR已经彻底失望了，不断地跟你来回折腾，耗到你没有心思再跟为止。 April 15 洗了个冷水澡 已经好久没洗冷水澡了，有印象上一次洗冷水澡应该还是05年在苏州的时候。 记得在学校的时候冬天比较经常洗冷水澡，那时候心情大都比较阴郁，冷水澡可以短暂冷却不平静的心。那时候和舍友经常在冬天洗澡的时候狂吼：“我是一个混蛋！”，不为什么，仅仅是内心的宣泄而已。有一次踢完球后冷了个冷水澡，接着去上课，牙齿咯吱咯吱打了一节课，福州的冬天温度差不多在5度左右，还是比较冷的。
晚上回来后看了下热水器，显示水温57度，这个温度洗澡问题是不大的。结果进了卫生间后，出水一直都没出热水。本来想等等再烧一下水，后面等不及了，就直接冲冷水了。洗头发的时候感觉还好，冲身体的时候就感觉到冷了。杭州这时候温度在12度左右，还是有点寒意的。跟以前一样，洗到后面就不冷了。什么时候在冬天最冷的时候试着洗个热水澡吧。 April 10 牌运不佳 上周末和这周二接连打了两次牌。没想到两次都是惨败，是打牌以来输得最惨的两次。打杭州这边流行的双扣，这两次都是第一把就双扣别人，结果后面就一直输下去，看来打牌是不能赢头把的。上个周末还坚持着一小段时间，这周二输得可就惨了。牌抓得好吧，别人抓得更好，手上好几幅炸弹，炸都炸死你；牌抓得不好吧，人家的牌还是比你好，硬生生地把你堵死。有一盘居然有一个人抓了2幅6张牌的炸弹，另外一个人抓了1幅6张牌的炸弹，加上被双扣，一把就输了6个。还有人抓7张牌炸弹的，有人抓4个鬼的，从-3到-23只用了5把，NNGX。输了点小钱，哈哈。本来打牌有个原则是坚决不赌钱，后面被gytyl拉下水，赌了点小钱，发现赌点小钱挺好玩的。小赌怡情啊！NinGoo也是打牌从不赌钱的，不过现在也被我拉下水了，哈哈，不过这小子一赌钱基本上都是小输或者平。 April 07 的士司机的诚信半夜打车到机房换硬盘，由于下雨，加上机房所在的地方比较偏，在那边很难打到车，于是跟司机商量让他在机房楼下等我。因为我上去换个硬盘前后也就10分钟时间，再说半夜那地方也不会有什么客人，司机也答应了。为了表示诚意，我还特地先把过去的钱给结了。没想到我一进去还没登记，司机就开车走人了。NND！ April 02 RAC升级到10.2.0.4碰到的几个问题及处理办法
上周末将10.2.0.3的RAC数据库升级到10.2.0.4。在升级过程中碰到了几个问题，记录一下解决办法。 第一个是在CRS打完Patch之后运行root102.sh脚本时报：
Preparing to recopy patched init and RC scripts. Recopying init and RC scripts. ocrcheck failed. Check /u01/oracle/product/10g/crs/srvm/log for more details
这一步事实上是这时候CRS无法启动，而且在/u01/oracle/product/10g/crs/srvm/log这个目录下面没有记录任何东西。尝试着手工启动CRS，报：
/u01/oracle/product/10g/crs/bin/crsctl.bin: error while loading shared libraries: /u01/oracle/product/10g/crs/lib/libclntsh.so.10.1: file too short
查看一下libclntsh.so.10.1，文件大小居然为0。查看该目录下的其他文件的大小和更改时间和备份的目录相比都没变化，解决办法便是将报错的libclntsh.so.10.1文件从升级之前备份的CRS目录COPY回来，再运行脚本就可以了。可见在升级之前做好备份有多重要。 第二个问题是打完PATCH，准备用DBUA升级数据库时将所有节点启动至MOUNT状态，DBUA运行下一步时报错：
DBUA thinks this is a Rerun operation and is trying to connect to the database with oracle home /u01/oracle/product/10g/db. If you believe this is not a Rerun operation, remove the below file and invoke DBUA again. /u01/oracle/product/10g/db/cfgtoollogs/dbua/logs/Welcome_dwdb.txt
但是Welcome_dwdb.txt这个文件压根不存在。这时候只好抛弃DBUA了，手工运行升级脚本，这样数据库才能正常升级成功。 第三个问题是发现发现我们原来RAC内部互联采用的是Infiniband RDS协议变成普通的UDP协议互联了：
Fri Mar 28 21:12:14 2008 cluster interconnect IPC version:Oracle UDP/IP (generic) IPC Vendor 1 proto 2
这个问题是由于在升级过程中ORACLE又重新将内部互联的方案更改为默认的UDP方式。需要重新配置一下RDS内部互联，在配置之前需要把ASM和数据库都停掉，然后重新RELINK成RDS互联：
$ cd $ORACLE_HOME/rdbms/lib $ make -f ins_rdbms.mk ipc_rds ioracle
这样以后，内部互联就恢复成正常的RDS了：
Fri Mar 28 21:25:39 2008 cluster interconnect IPC version:Oracle RDS/IP (generic)
在升级之后我们碰到了一个新的BUG，数据库会报：
ORA-00600: internal error code, arguments: [kddummy_blkchk], [47], [935468], [18038], [], [], [], []
解决办法是将db_block_checksum这个参数改为FALSE，不过这样做会有较大的风险，目前这个BUG ORACLE已经提交BUG开发部门进行开发了。 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的开始到现在一直很不顺，发生很多让自己失望的事情。很多东西你必须承担但是却无能为力，付出了不一定会有回报，结果是最重要的。想明白了一件事：当感到迷茫困惑的时候，不要想得太多，尽力先把手头的事做好。只要自己尽力了就行，结果不是自己所能左右的。 February 01 漫漫回家路今天杭州飘了一整天的茫茫大雪，比起今年的前几场雪要大得多，整天都在下。现在路面的积雪已经有十多厘米厚了，而我将乘座明天上午10点从杭州南站到福州的长途汽车，现在还不知道到底能不能顺利成行。长途车站的电话一整天都在占线，压根不能指望打通。看杭州长运网站的消息，到温州方向的车目前还能正常通行，但愿明天也能够通行，只要温州能走，那么福建的路应该就能走，毕竟福建的天气和和路况都比较好。但愿能够顺利回家！ January 22 PUB年会记忆年会回来已经1个星期多了。我一直在提醒自己应该记录一下年会上发生的一些事情，奈何总是挤不出一整块可以让自己平静思考的时间。从刚回来时的略感失落到现在的平静，时间总会带走许多东西，但是平静的时候正是适合回忆的时候。 1 | ||||||||||||||||||||||
Invite as friend