Roby's profileblue_princePhotosBlogListsMore  |  Tools Help |
|
|
February 16 淘宝网招Oracle&MYSQL DBA、监控开发&值班工程师、数据仓库前端工程师Oracle 产品DBA July 22 Linux下如何迁移VG及文件系统在LINUX下，如果需要将一台主机上的文件系统迁移至另外一台主机上，并且文件系统是基于LVM创建的，那么可以使用VG导入导出功能将VG和LV在不同主机上迁移。
源主机上操作：
首先在源主机上将文件系统umount：
umount /u05
再将LV和VG inactive：
lvchange -an /dev/vg_u05/lv_u05
vgchange -an vg_u05 最后导出VG：
vgexport vg_u05
目标主机上操作：
导入VG：
vgimport vg_u05
激活VG，MOUNT 文件系统：
vgchange -ay vg_u05
mkdir /u05 mount /dev/vg_u05/lv_u05 /u05 May 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编号，这个对于使用还是有些麻烦的。 August 22 祸不单行本来今天挺高兴的，因为搞定了虚拟带库的备份配置，先说一下吧。 在第一台主机安装好Veritas NetBackup软件后，停止NBU的时候主机就宕机了，出现了黑屏，然后一直死在那边。只好重启，不想重启后依然如故。OK，这台不行，那就换另外一台吧。再重新安装配置好，测试停止的时候还是一样，死机了。折腾了很长一段时间还是没有搞定，由于是测试，出于节约时间的考虑，那就先不测试停止NBU服务了，反正能够启动就行。然后就是配置虚拟带库，光纤交换机上配置好了以后，主机死活认不到带库。带库厂商在一边想办法，Veritas的工程师说先测试磁盘备份吧，至少先把Veritas配置好。VERITAS磁盘备份测试完成以后，带库厂商还是没有找到问题所在。看到VERITAS工程师在这边等也不是办法，让她简单介绍了一下操作步骤，就先回去了。接下又是我一个人在无止境的折腾，存储厂商的人在边上看着，看到没啥进展就准备撤了，说回去再问问同事，下星期再过来配置。问题是他们下周有时间，我没时间呀！让他们暂留一小会儿，我再继续折腾下来，终于在一台主机重启后发现了带库。接下又是开始NBU的配置，不想这次是主机可以认到磁带，NBU怎么整都无法认到磁带。后悔让Veritas的人走得太早了，既然人都走了，那么只好自己来整了。在几次反复不同的尝试之后，终于NBU可以认到带库了，赶紧配置好。接下开始测试ORACLE备份，又报错了：Ora-27211 "Failed to load Media Management Library"。又开始折腾了，不停尝试，不停地找解决办法，终于确认应该是/nbu/openv/netbackup/bin/libobk.so64这个库文件需要LINK一下的。问题是我找不到这个文件呀，突然想起另外一台机器也安装了，过去一看，果然有这文件在，赶紧COPY过来，LINK一下，可以了！ 好不容易整好回家，心情难得高兴一下。短信报错了，这次是因为空间不够，读写打开的备用库的RESTORE POINT又没创建起来，这样数据库又无法FLASHBACK回去了。那一刻我异常绝望，在经历这么多天高压力的辛劳后，好不容易整起来的东西说出问题就出问题。说啥都没用，上帝有时候就是这样，好在我早已习惯了他老人家的脾气。无论怎样的压力对我来说都是微不足道的，我知道这点。 August 14 我只是很平静和以往一样，无论在碰到什么样疑难的技术问题之前，我都坚信问题一定能够解决的。只是在好奇着接下到底会碰到什么样的困难，自己会采用什么样的方式进行处理，这次也不例外。 就在上周末，运行稳定长达7个月之久的备用库读写打开出现600[krff_create_fb_log-4]错误，导致restore point没有创建成功，接下就把STANDBY激活读写打开了。由于RESTORE POINT没有创建，这样数据库再也无法FLASHBACK回去了（写到这个时候，我突然间想起来就算是RESTORE POINT没有创建成功，FALSHBACK功能打开的话，其实只要FLASHBACK到STANDBY数据库激活打开之前的时间点，然后重新进行恢复即可，用不着费了我这么多天的辛劳。当然这个还需要测试验证，毕竟现在已经无法这么做了。只恨自己前几天在想着各种各样不同的解决办法，唯独没有想到这种办法，而在我坐下来平静总结的时候却闪出来了）。当时想起来唯一的解决办法只能是重新配置STANDBY。问题是这个数据库已经有近5个T之大，每天大概产生300G的归档日志，配置STANDBY的工作量可想而知。虽然磁带上有每周一次的全库备份和每天的归档备份，不过如果从磁带恢复的话，那么估计没有十天半个月数据库是无法RESTORE出来的。这样只能重新备份主库到磁盘上了，问题是存储没有这么大的空间。于是开始规划备份的空间，想到的办法就是先备份数据库到一个目录/u02/backup下，然后通过NFS再MOVE不同备份文件到不同机器的存储上面，最后再通过LINK的方式把备份文件LINK到STANDBY相应的/u02/backup上，这样STANDBY进行恢复的时候什么都不用更改，可以直接恢复。说干就干，第一个问题出来了，本来我是想主库上的备份mount point /u02做为NFS MOUNT给备用库的/u02，结果由于之前一个子目录/u02/test/已经MOUNT成NFS供多台服务器使用，父目录要想再做成NFS是不行的，于是只好在父目录下子文件夹backup单独MOUNT给STANDBY使用。第一个问题解决完后便是丢在那边让数据库慢慢备份了。 主库从中午11点到晚上11点半左右终于全库备份完了，于是重新配置STANDBY，RESTORE DATABASE的时候出问题了，死活无法RESTORE。由于数据库是采用祼设备，为了管理维护的方便，把祼设备LINK成文件系统上的虚拟数据文件。于是怀疑是祼设备的问题，先把600多个祼设备的全部DD清空掉（其实这个DD没弄好，今天才发现问题，不过没有影响），再次RESTORE，还是不行。OK，全库RESTORE不行，那就单独一个表空间吧：
RMAN> restore tablespace system;
Starting restore at 12-AUG-07 using channel ORA_DISK_1
creating datafile fno=1 name=/u01/oracle/oradata/test/system01.dbf RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of restore command at 08/12/2007 2:20:20 ORA-01180: can not create datafile 1 ORA-01110: data file 1: '/u01/oracle/oradata/test/system01.dbf'
系统表空间不行，那就试试其他表空间吧：
RMAN> restore tablespace sysaux; Starting restore at 12-AUG-07 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=1094 devtype=DISK creating datafile fno=3 name=/u01/oracle/oradata/test/sysaux01.dbf restore not done; all files readonly, offline, or already restored Finished restore at 12-AUG-07 折腾了N遍之后，结果死活都是restore not done，看看都凌晨2点半了，先睡觉吧，等第二天再问同事看看之前有没碰过类似的问题。 周日早上一醒来便打电话问piner之前有没碰到类似的问题，结果他也没碰到过，他折腾了几下发现问题比较怪异，也没有好的解决办法。这样只好再试不同的办法了，怀疑是LV的问题，于是把LV删掉重建并重新LINK好，再RESTORE，还是不行（刚才测试后才发现LV重建的话，只要建的方式跟之前的一样，里面内容都不会丢失）。怀疑是RMAN备份不能通过LINK的方式RESTORE，于是将对应的备份集COPY到/u01/backup目录，restore还是不行。实在没辙了，上集团DBA群问在线的同事，不过也都没有好的解决办法，BITI后面说实在不行就用dbms_backup_restore包一个个数据文件整好了。我晕，一共有600多个数据文件，2600多个备份文件呀！还是先再想想有没别的办法，既然RESTORE到祼设备不行，那么试着RESTORE到文件系统行不。发现RESTORE到文件系统是可以的，虽然信息还是跟之前的一样:restore not done，不过文件系统上确实是有数据文件了（后面发现其实是不行的）。不过总不能一个个数据文件RESTORE到文件系统然后再DD到祼设备吧。 家里网络环境不好，跑到公司去整，结果到公司折腾了几下还是没有找到好的办法。由于没有休息好，实在困得不行，只好先回家休息。回到家也没休息好，眯了一下突然间想起来既然SYSTEM表空间用RMAN无法RESTORE，那么可以先使用dbms_backup_restore包RESTORE到文件系统，再从文件系统DD到祼设备。费了九牛二虎之力终于整好SYSTEM表空间。接下便想起来早上RESTORE SYSAUX到文件系统的时候，虽然说restore not done，但是确实是在文件系统上产生了数据文件，而且大小一样。这样看来虽然RMAN提示说restore not done，但是应该是已经RESTORE好了，这个提示可以忽略不计。这样想之后就开始分头写脚本RESTORE不同的表空间，一开始是把RESTORE所有剩余表空间的语句放在一个脚本里面运行。跑了一会想起效率太低，应该并行跑不同脚本RESTORE不同的表空间，杀掉重跑，以使RESTORE最快。运行了很长很长时间后又发现其他表空间都RESTORE好了，一个最大有着300个数据文件的表空间还在慢慢的RESTORE，于是中止重来，把这个表空间剩余未RESTORE好的数据文件分配到不同的进程再次RESTORE。RESTORE一半时发现有些RESTORE失败了，由于周日正好是对备用库进行全库备份，结果控制文件RESTORE的时候跑去磁带找备份集了。分配的通道是DISK的，这样当然不行了。只能是重新在主库上生成控制文件，再DD进去。我不知道这几天重复着多少次这样DD的过程。在RESTORE的过程中心情异常地平静，我想这次如果成功了我不会像以往每次解决疑难问题后那么欣喜，我只会很平静地告诉自己算是折腾好了。实在是太累了！ 脚本跑起来之后人也没闲着，总不能把希望全部寄托在这上面吧，万一这样RESTORE不行咋办？只能想到最后的办法：用dbms_backup_restore包进行手工RESTORE，于是在边上准备好脚本，一共将近3000多行，壮观！RESTORE还在慢慢的运行过程中，看到都凌晨2点多了，想着放在那边慢慢RESTORE，第二天早上再起来整。结果躺在床上虽然很累却是睡不着，起来看了一下发现只剩下不多的数据文件需要RESTORE了，干脆折腾好吧。在3点半左右的时候终于全部数据文件RESTORE好了，于是开始recover managed standby，命令一下来就出错： ORA-19909: datafile 1 belongs to an orphan incarnation。百思不得其解，SYSTEM我可是RESTORE到文件系统上并且DD到祼设备的，再怎么着出问题也不可能会是SYSTEM出问题呀！想想可能还是restore not done的原因，可能没RESTORE好吧。既然脚本都准备好了，就用dbms_backup_restore来整吧，发现一个脚本太多行数无法执行。OK，那分脚本来执行吧，由于不知道哪些数据文件在哪些备份集上，只能把所有备份集都选上，还是由于太多行不能执行。这样我实在没辙了，总不能让我一个个数据文件对应的备份集找出来弄好脚本再去执行吧。看看都凌晨4点了，第二天就周一，到公司上班后再整吧。 周一中午到公司后发现汪海已经在折腾了。这次他RESTORE完一次就是去DUMP数据文件头看看，发现昨天那样RESTORE是压根都没成功的，数据文件头的状态全部不对。更奇怪的是我SYSTEM表空间是DD到祼设备的，居然还是不行。我们在不停地尝试不同的方法，方方面面可能的问题都想过了，不停地RESTORE不停地DUMP查看，还是没有找到可行的办法。最后面还是发现用dbms_backup_restore是可行的，RESTORE完后DUMP数据文件头出来的状态是正确的。这样只能用到最后这一招了，到时候写个SHELL脚本去生成RESTORE的脚本吧。这时候归档已经积累快3天了，估计恢复也够呛。而且之前的控制文件由于测试的过程中不断地备份，可能备份信息都乱了。于是决定重头开始备份，RMAN既然出问题，就等备份完后把主库的rman可执行文件COPY到备用库试试吧。备份速度比预想中的要快很多，昨晚又是不停地移动备份集到不同的目录，中间又是出这个问题那个问题，整到凌晨3点多才好。 今天到公司后先把主库的rman程序COPY到备用库，然后调用起来RESTORE SYSAUX表空间，乖乖，居然可以了！于是赶紧全库RESTORE。看着RMAN在慢慢的RESTORE，一下子舒了一口气，连续折腾了4天3夜终于有结果了。我没有太多的惊喜，只是终于解决了这个问题而已。现在这样看来应该是备库上RMAN程序的问题，不过我还是认为应该不是这个问题，因为这个RMAN程序备份了一年都没问题，不可能RESTORE就出错。不过事实确实就是这样，那么应该就是这个问题吧。 October 25 我承认是人品问题记录一下接手这个数据库后硬件出故障的记录吧（写工作周报的好处这时候体现出来了，想知道什么时候做过什么事情都可以查）： 6月份：备用库存储SP报错损坏，去机房更换备用库SP。 8.15：备用库存储另外一个SP损坏，厂商拿着新换的SP过来，结果居然新拿的SP也是坏的，厂商不得不当天从上海再调一个SP过来，上下午各往返一次机房把SP换好。 8.29：备用库存储上一个硬盘损坏，再次机房更换硬盘。 9.1：去机房测试备用库网卡出错。这个备用库原来是做为主库用的，结果在使用过程中经常出现莫名其妙的数据传输乱码，比如你传的数据是“12345”，接收后会变成“ABCDE”，这个数据库原先是piner负责的，他当时怀疑网络原因，怀疑存储原因，怀疑OS……经过N久的测试后，最终才定位到是网卡问题，估计是主芯片问题，把数据传输成乱码。这块网卡是由两块网卡绑定而成的，把绑定网卡解开，一块网卡一块网卡测试，定位出出错的网卡。 9.6：主库一块光纤卡损坏，去机房更换，把存储停掉，费了不少周折。其实这时候主库也报了个同备用库后面报的同样的电源错误，不过只是启动后报了一次，没当回事。 9.7：经销商过来更换备用库损坏的网卡，拿来的一块网卡居然也是坏的，这次还好，经销商在杭州有办事处，不用从上海调货了，在机房等着新网卡更换，网卡最终顺利更换完成。不过服务器启动后报了一个莫名其妙的错误: sysplanar0 UNDETERMINED ERROR，具体出错信息如下： Diagnostic Log sequence number: 11252 Resource tested: sysplanar0 Resource Description: System Planar Location: SRC: 11001520 Description: Power/Cooling subsystem Unrecovered Error, bypassed with loss of redundancy. Refer to the system service documentation for more information. Additional Words: 2-003C0001 3-00000000 4-00000000 5-00000000 6-00000000 7-00000000 8-00000000 9-00000000 Possible FRUs: Priority: L FRU: PWRSPLY Location: U787B.001.DNW764F Priority: L FRU: 03N6961 S/N: YL10HA5C609L CCIN: 28D9 Location: U787B.001.DNW764F-P1
打IBM800电话说有可能是主板或者电源的问题，说由于服务器的信息跟他们的服务中心没有同步好，IBM不负责保修。只好联系经销商，经销商答应换电源。还有一项任务是把备用库上的CPU和内存各拔一半到主库上用。结果服务器拆下来后发现服务器是较早买的型号，两块板都只有2个CPU插槽，已经插满了，无法升级，早就预定的升级最终无法完成。 9.21：经销商另外派了一个资深的工程师来机房查看错误，把备用库的服务器拆下来一个零件一个零件查看一遍，再装上去错误依旧，那哥们说看来是主板有问题。问经销商服务器信息同步好了没有，说已经同步好，现在IBM可以保修了。回去以后打800电话说还是没同步好，不受理保修。 10.10：经销商工程师过来备用库配件，原先以为会过来换主板，结果居然是拿了8根内存过来换。他们的解释说现在也不知道到底问题出在哪里，那个报错信息只是说可能是主板或电源有问题，电源已经换了一个，现在把配件一个个换掉试试看有没问题，还会不会报错。由于更换主板需要从国外调货，他们一时还无法更换。他们还要更换网卡，我不让换，说现在网卡好好的，没必要再换了。服务器一个板上的8根内存全部更换完毕后报错依旧，经销商工程师说看来只能更换主板了。回公司后发现居然网卡也报错了。 10.11：去机房检查备用库网卡出错信息，搞定。 10.18：经销商这次终于过来换主板了，连着把全部16根内存和2块网卡再换了个遍。本来以为很顺利的更换过程换了将近3个小时才换好，将近3点才吃午饭。本来想这样大换血后总不会出问题了吧，结果错误依旧。其中换硬件过程中接了个USB鼠标没有驱动程序无法使用，服务器不时接到短信报警，半夜被短信吵醒。经销商确认现在服务器配置已经和IBM同步完成，可以原厂保修了。 10.19：联系IBM 800报修，终于答应派一个本地工程师上门服务。 10.20：同IBM工程师去机房诊断备用库错误信息。IBM工程师经过多次诊断后得出结论是第一个电源有问题，也就是左边的那个电源。理由是报错信息中的Location: U787B.001.DNW764F-P1中的这个001是表示第一个位置。得出结论后回来跟TEAM里面的人说，大家都笑了，想不到经过这么多次折腾，把机器的配件换了个遍，假如最早那次经销商换电源时换的是左边那个电源就好了，也就不会折腾到现在。问题找到原因，终于可以舒一口气了。 10.23：IBM工程师拿着新电源过来换，把左边那个电源更换重启后发现报错居然依旧。这次真TMD是活见鬼了，IBM的工程师用手在电源背面板不断地试，还和主库上比较，接下决定一个电源一个电源来测试，测试发现有一路电源是无法启动的，既然两个电源都已经换过了，电源出问题的可能性太小了，会不会是电源线或者其他问题？把电源线换了一个插座插好后启动了。靠TMD！原来是机柜上插电源的那个插头坏了，因此始终报错。亏我们还一共换了24根内存、3块网卡、1块主板、2个电源，就是换一台全新的机器也还是会报错！也就是说之前折腾了那么久，换了那么多配件做的都是无用功！换了个电源插头插上去，终于好了！搞定一个大问题后长舒了一口气。结果在启动后发现绑定网卡又出问题了，只好取消绑定，用单块网卡使用。 10.24：由于前一天更换电源后接了个USB键盘没能认出，备用库又不时报USB驱动错误，为了避免半夜被监控短信吵醒，只好到机房把备用库断电重启以消除报错顺便解决一下网卡问题。处理过程中犯了大错。网卡换线换端口还是有问题，实在经不起折腾了，只好继续用单网卡使用。测试了一下插头电源，发现机柜左边一排插头中居然有两个插头是坏的！这垃圾工程！ 现在：主库的冗余电源需要确认到底是电源问题还是像以前那样的插头没电引起的；主库存储又开始报错了，原因不明，需要进一步跟踪；备库网卡还需要挑个时间过去看一下具体出错所在…… Wanghai和piner开玩笑说是我人品不好，因此服务器硬件才会三天两头出问题。好吧，我承认是我人品不行，只是求求我的好服务器千万不要再出问题了，机房的地板已经被我坐得厚度都少了几毫米了。千万千万不要再半夜收到监控短信了，你知道我睡眠不好的，你知道我长期失眠的，你就让我睡个安稳觉吧！10月是我的滑铁卢，快过去了，都会好起来的！ 昨天犯大错了昨天下午去机房解决备用库报错的问题。在处理过程中，监控主库的错误信息发现居然之前报过同备用库一模一样的电源错误：
Description: Power/Cooling subsystem Unrecovered Error, bypassedwith loss of redundancy. Refer to the system service documentation for more information. Additional Words: 2-003C0001 3-00000000 4-00000000 5-00000000 6-00000000 7-00000000 8-00000000 9-00000000 Possible FRUs: Priority: L FRU: PWRSPLY Location: U787B.001.DNW764F Priority: L FRU: 03N6961 S/N: YL10HA5C609L CCIN: 28D9 Location: U787B.001.DNW764F-P1 这个错误之前备用库也曾出现过，并花了将近两个多月的时间才知道具体症结所在。location 001 上次IBM的工程师介绍说（这个错误的说法害死人！）是表示第一个电源出问题，于是我用手去摸主库和备用库共4个电源比较，发现主库第一个电源背板明显热量比其他电源大，当时和拖雷联系认为是主库的第一个电源出现问题了，根据机器报错信息（IBM工程师提供的信息）和我现场实际检测（热量明显比其他电源大）都说明了这个问题。由于服务器的两个电源是互相冗余的，既然这个电源有问题，那么当时和拖雷一起肯定另外一个电源是正常工作的，可以把这个电源拔下来看看到底故障出在哪里。接下来的事情就玩大了：我拔了这根电源线，运行中的主库马上断电宕机……看了后面板的灯全灭了，我当时立马傻了，愣在那边！幸好这个数据库是内部使用的数据库，幸好当时用户很少，幸好当时没有什么事务，服务器重启动后数据库也很顺利地起来了。虽然这个数据库对可靠性要求不像生产数据库要求那么高，不过对于一个DBA来说那一个时刻绝对是难于忘怀的。我想我一辈子都不会忘记拔掉服务器电源后背板灯全灭的那一刻！ 事后回想，要么就是IBM工程师说的这个location 001指的是第一个电源有误，要么就是IBM的冗余电源无法真正做到热故障切换。早上联系了一下IBM的800果然说这个location 001并不是指第一个电源，根据当时现场诊断发热量过大的判断，那个电源应该是正常工作的，而另一个没什么发热的电源基本上可以肯定没有正常工作的，或者就是服务器的冗余电源无法真正实现热切换。 在去年十月也曾经犯过错误，十月是我的滑铁卢。 |
|
|
