博客首页
注册
建议与交流
排行榜
加入友情链接
推荐
投诉
搜索：
帮助
好好学习,天天向SUN
联系方式: leiyu530@163.com
penguinstorm.cublog.cn
管理博客
发表文章
留言
收藏夹
博客圈
音乐
相册
· N4000拆卸过程
· Solaris8安装过程截图
· Veritas
}
· 建立VOLUME
· 其他
· 证书
· ORACLE_FOR_Solaris9i
· HACMP_FOR_AIX 4.3.3
}
· 准备工作
· 配置过程
· 配置共享卷组
· 配置应用脚本
· 同步过程
· 启动双机
· 错误大观
· 路由交换
· ruby专用文件夹
· sun_cluster
· FASTT系列存储
· 7133换盘操作
· HACMP_FOR_AIX 5.1
· 地震纪实
文章
· AIX
}
· 实践操作
· 双机配置
· 系统认证
· 基础知识
· 故障处理
· 共享精神
· HPUX
}
· 学逻辑卷
· 双机相关
· 考试认证
}
· CSE
· CSA
· 基础知识
· 动手实践
· 存储备份
· CISCO
}
· 交换相关
· 路由相关
· 认证考试
}
· CCNA
· CCNP
· CCIE
· 心情日记
· 动手实践
· Linux
· Oracle
}
· 基础知识
· 实践操作
· 考试认证
· 实验操作
· English
· Solaris
}
· 读书笔记
}
· SA239
· SA299
· SA399
· ES222
· SM240
· ES255
· ES310
· Solaris高级系统管理员指南
· 基础知识
· 实践操作
}
· ST350
· 认证计划
· 系统安装
· Veritas
}
· 基础知识
· 实践操作
· Program
}
· Rails
}
· 基础知识
· 实践操作
· 语法掌握
· Dynamips
· 荣誉勋章
· 过关总结
· 闲言碎语
· 熬夜签到
· 好文收录
· 人在职场
· 热点关注
首页
关于作者
姓名：雷宇 昵称：storm 职业：IT 年龄：26 位置：北京 个性介绍：没啥个性 不聊MSN/QQ 本着资源共享的精神，所有文章欢迎转载
||
<<
>>
||
我的分类
文章列表 - 实践操作
oracle9i for solaris8错误一观
<DIV><IMG src="http://blog.chinaunix.net/photo/6589_080104144450.jpg"></DIV> <DIV>以前碰到过，今天又碰到了，重装了好几次，ORACLE安装成功，到建库的时候始终报这个错误。点击“OK”之后，之前生成的所有数据文件自动退回，建库失败。</DIV> <DIV>从这个错误来分析，是在参数文件pfile里面的参数“user_dump_dest”找不到“oracle/admin/ora/udump”的路径所致。所谓乱花渐欲迷人眼，这里不仔细观察还发现不了错误。在这个错误提示下，我做了一次手工生成目录admin的操作，然后赋予相应权限：</DIV> <DIV># mkdir -p /oracle/admin/ora/udump</DIV> <DIV># mkdir -p /oracle/admin/ora/bdump</DIV> <DIV># mkdir -p /oracle/admin/ora/create</DIV> <DIV># mkdir -p /oracle/admin/ora/pfile</DIV> <DIV># chown -R oracle:oinstall /oracle</DIV> <DIV>重试建库的操作，还是停在这里。</DIV> <DIV>经过几次观察发现，问题出在oracle用户的.profile文件的设置，最关键之处在于ORACLE_HOME以及ORACLE_BASE的定义，没有修改之前我的定义是这样的：</DIV> <DIV>ORACLE_BASE=oracle; export ORACLE_BASE<BR>ORACLE_HOME=oracle/product/9.2.0; export ORACLE_HOME</DIV> <DIV>错误之处在“oracle”字样前少了“/”，这样在系统自动生成admin目录的时候就没问题，也不存在上述报错现象。</DIV> <DIV>再观察一下这个报错信息，ORA-07446:sdnfy:bad value 'oracle/admin/ora/udump' for parameter user_dump_dest。如果不细心，很容易忽略是绝对路径的设置出了问题，如果是“/oracle/admin/ora/udump”就没有问题了。</DIV> <DIV>参考人家在solaris8下安装oracle9i的时候提到手工生成admin目录以及赋权限的操作其实是完全没有必要的，只要路径正确，系统就自动生成。正所谓差之毫厘，谬以千里，看来此话是不无道理的。</DIV> <DIV></DIV>
查看全文
发表于:2008-01-04 ┆
阅读(239)
┆
评论(0)
记Solaris8下硬盘扩容
<DIV>情况说明：</DIV> <DIV>一用户那儿两台SUN E3500，用软件lotus做双机。正常情况下，两台机器对应用负载均衡，如果一台机器宕机，所有应用自动切换到另一台机器上面去。</DIV> <DIV>两台机器都只有一块36G硬盘，20G作为应用，16G作为系统。应用挂载在名为"/data"的文件系统上，/data下两个目录，一个是en0v，一个是mail，分别软链接到/lotus/notesdata目录下的en0v和mail下。应用对应的帐号是notes,就像数据库对应的帐号是oracle一样，通过用户notes执行脚本命令来驱动。</DIV> <DIV>现在的情况是，两台机器上/data使用率分别为99%，93%，但里面的内容都不能删除，唯一的方法只能是扩充硬盘，在现在36G硬盘的基础上再扩充一块73G硬盘。</DIV> <DIV>扩盘思路：</DIV> <DIV>在36G硬盘基础上扩充一块73G硬盘，意味着要将/data扩大，以最大限度容纳应用所生成的文件。方案是在新插入的73G硬盘上建立一个73G大小的文件系统，然后以新文件系统来替代原来的/data文件系统，这样一来，就起到了扩容的目的，但原有/data文件系统就此无效（也可理解为起到备份作用）。</DIV> <DIV>实施过程：</DIV> <DIV>1，停应用；</DIV> <DIV>2，在备机硬盘插槽中插入73G全新硬盘一块；</DIV> <DIV>3，devfsadm进行设备重新识别过程；</DIV> <DIV>4，format确认新加盘已经识别到；</DIV> <DIV>5，选择新加盘的4号分区进行文件系统的创建(# newfs /dev/rdsk/c0t1d0s4)；</DIV> <DIV>6，cd / </DIV> <DIV> mkdir /data2</DIV> <DIV> mount /dev/dsk/c0t1d0s4 /data2；</DIV> <DIV> df -k查看/data2是否已经存在；</DIV> <DIV>7，cp -rp /data/en0v /data2/</DIV> <DIV> cp -rp /data/mail /data2/（带权限拷贝过程）;</DIV> <DIV>8，待拷贝过程完成，umount /data, umount /data2;</DIV> <DIV>9，狸猫换太子过程：</DIV> <DIV> mv /data /data2</DIV> <DIV> mv /data2 /data</DIV> <DIV> cp /etc/vfstab /etc/vfstab.old</DIV> <DIV> vi /etc/vfstab将文件中涉及到/data的统统改为/data2，同时增加一行：</DIV> <DIV>/dev/dsk/c0t1d0s4 /dev/rdsk/c0t1d0s4 /data ufs 2 yes -</DIV> <DIV>10，mount /dev/dsk/c0t0d0s3 /data2</DIV> <DIV> mount /dev/dsk/c0t1d0s4 /data</DIV> <DIV> df -k进行确认；</DIV> <DIV>11，init 6；</DIV> <DIV>12，待系统起来后，以notes用户登陆到系统并启动应用，测试应用是否可用。经测试，应用正常。</DIV> <DIV>13，df -k查看/data使用率由原来的99%变为现在的32%,/data2的使用率依旧为99%，应用现在已经正常跟/data挂钩，/data2作为/data的一个前期备份。</DIV> <DIV>14，在另一台机器上作相同修改，经测，应用同样正常运行。</DIV> <DIV>至此，所有操作顺利进行，收工。</DIV>
查看全文
发表于:2007-12-10 ┆
阅读(267)
┆
评论(2)
剖析E3500部分结构：有关硬盘显示数的问题
<DIV><IMG style="WIDTH: 527px; HEIGHT: 409px" height=409 src="http://blog.chinaunix.net/photo/6589_071120120143.gif" width=497></DIV> <DIV>一台E3500的机器，前面板有八个硬盘插槽，总共插了五块硬盘，分别对应插槽号0、1、2、3、4。在系统里用命令format查看显示有八块硬盘。按常理，应该只显示五块硬盘才对：</DIV> <DIV># format<BR>Searching for disks...done</DIV> <DIV><BR>AVAILABLE DISK SELECTIONS:<BR> 0. c0t0d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133><BR> <A>/sbus@2,0/SUNW,socal@d,10000/sf@0,0/ssd@w21000020374fcbb8,0</A><BR> 1. c0t1d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133><BR> <A>/sbus@2,0/SUNW,socal@d,10000/sf@0,0/ssd@w21000020374fb127,0</A><BR> 2. c0t2d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133><BR> <A>/sbus@2,0/SUNW,socal@d,10000/sf@0,0/ssd@w21000020376fac33,0</A><BR> 3. c0t3d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133><BR> <A>/sbus@2,0/SUNW,socal@d,10000/sf@0,0/ssd@w21000020374fab0c,0</A><BR> 4. c3t5d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133><BR> <A>/sbus@2,0/SUNW,socal@d,10000/sf@1,0/ssd@w210000203787c584,0</A></DIV> <DIV>观察一下机器后面板接线。为了识别E3500的硬盘，需要用SCSI线将FC-AL Interface Board与IO Board板对应的接口连接起来，每四块硬盘对应一个SCSI通道。也就意味着如果要识别到所有八块硬盘，那么必须用两条SCSI线将FC-AL Interface Board与IO Board连接起来。</DIV> <DIV>FC-AL Interface Board从上到下四个接口分别是UB/UA/LB/LA，这里的连接有讲究。如果要想显示所有的硬盘，那么要么选择UB/LB，要么选择UA/LA。如果按照UB/UA或者LB/LA搭配的连接方式，那代表双通道。按照前面插入了五块硬盘但是系统中显示出来是八块硬盘的结果，接线是LB/LA，为双通道方式，这就不难理解其中缘由：</DIV> <DIV>UB、LB分别对应四块硬盘，同理，UA、LA也对应四块硬盘，这里只选择了“L”方式，那么只能识别最多四块硬盘，在这里将插槽0－3的四块硬盘显示了出来。然后因为既接了LB又接了LA，为双通道，那么自然在原来四块硬盘的基础上又多了四块硬盘的映射。</DIV>
查看全文
发表于:2007-11-20 ┆
阅读(483)
┆
评论(2)
E3500故障处理：机器重启时好时坏
<DIV> 上次提到客户那儿一台E3500机器出现故障，故障经过是客户通过远程控制台对机器reboot之后发现机器启不来了，观察之后发现机器停留在ok提示符下，不过任何操作均告失败。无奈之下，只好把机器做断电处理然后重新开机，这样才重新进入到系统。</DIV> <DIV> 在观察机器的启动过程中发现有报时钟板和IO板不匹配的问题，但这并不是阻碍机器启动的主要原因，通过命令“copy-clock-tod-to-io-boards“在ok提示符下同步时钟板和IO板后，机器开机自检时显示时钟板与IO板状态均为“normal”，启动系统时也不再报之前的问题，但实际隐患仍然存在。</DIV> <DIV> 通过eeprom命令观察系统里设置的启动列表，如下：</DIV> <DIV><A href="mailto:bootdevice=/sbus@2,0/SUNW,socal@d,10000/sf@0,0/ssd@w22000004cf2f40aa,0:a">bootdevice=/sbus@2,0/SUNW,socal@d,10000/sf@0,0/ssd@w22000004cf2f40aa,0:a</A> <A>/sbus@2,0/SUNW,socal@d,10000/sf@0,0/ssd@w2100002037c85499,0</A></DIV> <DIV>nvramrc=devalias disk <A>/sbus@2,0/SUNW,socal@d,10000/sf@0,0/ssd@w</A>*</DIV> <DIV> 可见在nvramrc里别名disk对应的物理路径并没有确定到具体设备，而boot device里出现两个物理路径，也没有使用别名方式来启动系统，而是通过直接指定物理路径的方式。查找这两条物理路径，一条正是启动盘c0t0d0正确路径，而另一条路径却遍寻不到。根据常规，boot device中设定的物理路径应该有先后顺序，也就是说系统默认按物理路径的先后顺序来启动系统，也就是每次启动应该都是从系统盘c0t0d0启动，但是否有时候也莫名其妙的从第二条物理路径<A>/sbus@2,0/SUNW,socal@d,10000/sf@0,0/ssd@w2100002037c85499,0</A>启动，这个不得而知。</DIV> <DIV> 基于这种情况，所考虑的操作便是除去多余的物理路径，并通过别名的方式指定唯一的启动路径，操作如下：</DIV> <DIV>1，# eeprom "<A href="mailto:nvramrc=devalias/sbus@2,0/SUNW,socal@d,10000/sf@0,0/ssd@w22000004cf2f40aa,0:a">nvramrc=devalias mydisk /sbus@2,0/SUNW,socal@d,10000/sf@0,0/ssd@w22000004cf2f40aa,0:a</A>"</DIV> <DIV>2，# eeprom boot device=mydisk</DIV> <DIV>通过远程控制台“reboot”测试，成功。</DIV>
查看全文
发表于:2007-11-02 ┆
阅读(299)
┆
评论(0)
E3500故障处理：时钟板与IO板不匹配
<DIV> 昨天接到客户的电话，说一台SUN E3500宕机，重启不能进入到系统。到达现场之后看到系统停留在控制台也就是ok模式下，无论boot启动、boot -s进入单用户，抑或是boot cdrom通过光驱引导都不成功。情急之下只能断电先，等待几分钟后加电引导，自检通过，到达ok模式下，报了一个错：</DIV> <DIV>Clock board TOD does not match TOD on any IO board.</DIV> <DIV>按照提示，应该是时钟板和IO板不匹配的问题。第一次处理SUN方面的故障，所以根据错误提示认定是时钟板的问题，但通过观察E3500背板，时钟板状态正常，故障灯未亮，电源灯以及运行灯都显示绿色，说明问题还不太严重。</DIV> <DIV> 基于这个判断，自做主张的给用户更换了时钟板，但居然连系统都启不来了，错误信息如下：</DIV> <DIV>Invalid wwn number 21000020 374fcbb8</DIV> <DIV> 断电之后，查了一下E3500的服务手册，在介绍时钟板部分提到一句非常重要的话：</DIV> <DIV>Note – If you are replacing the clock+ board, the TOD NVRAM from the old<BR>board must be removed and placed on the new board. Note also that if a system<BR>is replaced, then the TOD NVRAM on the clock+ board must also be changed.</DIV> <DIV>根据字面意思理解，就是说在更换时钟板的时候一定注意要将原来的NVRAM给替换到新加的时钟板上，否则就白换。观察了时钟板上的NVRAM，一块麻将1/2般大小，用手拔了拔，没用，拔不下来，死死的固定在板子上。咨询了一下专家有关更换时钟板的注意事项，专家说这个东西要拿镊子给撬起来，否则就只有使劲拔。没有镊子，但又害怕给拔坏了，所以放弃了这样的操作。</DIV> <DIV> 之后采取了一种行之有效的办法，那就是在ok模式下敲一个命令"copy-clock-tod-to-io-boards"，这样做的目的就是将时钟板上的信息同步到IO板上，除此之外还有一个命令"copy-io-board-tod-to-clock-tod"，目的都是一样的。这样做了之后再断电重启，进入到ok模式之前果然就没有之前的报错信息了。但之前客户提到的不能启动系统实际与另一个问题相关，欲知后事如何，且听下回分解。</DIV> <DIV> </DIV>
查看全文
发表于:2007-10-25 ┆
阅读(471)
┆
评论(2)
35截图诠释ORACLE9i for Solaris9安装过程（下）
查看全文
发表于:2007-09-18 ┆
阅读(454)
┆
评论(0)
35截图诠释ORACLE9i for Solaris9安装过程（中）
查看全文
发表于:2007-09-18 ┆
阅读(438)
┆
评论(0)
35截图诠释ORACLE9i for Solaris9安装过程（上）
查看全文
发表于:2007-09-18 ┆
阅读(614)
┆
评论(2)
DistSuite小故障解决
<DIV>系统平台：E3500</DIV> <DIV>操作系统：Solaris9</DIV> <DIV>数据库类型：ORACLE9i</DIV> <DIV>今天在E3500上做镜像实验，做完“/”、“swap“、“/opt”，到做“/export/home”的时候出现问题。这里有区别的是，一般对“/”文件系统做镜像需要重启系统，而对其他文件系统做镜像不需要重启。在对/etc/vfstab文件进行编辑的时候，“/”可以通过命令metaroot d**来自动替换/etc/vfstab里“/”文件系统的信息，其他像swap、/opt等都需要手工编辑/etc/vfstab文件。</DIV> <DIV>在执行df -k查看文件系统使用情况的时候，例如：</DIV> <DIV># df -k<BR>Filesystem kbytes used avail capacity Mounted on<BR>/dev/md/dsk/d30 3009594 2466587 482816 84% /<BR>/proc 0 0 0 0% /proc<BR>mnttab 0 0 0 0% /etc/mnttab<BR>fd 0 0 0 0% /dev/fd<BR>swap 5467728 40 5467688 1% /var/run<BR>/dev/dsk/c0t2d0s0 8261430 3781568 4397248 47% /oracle<BR>/dev/dsk/c0t3d0s0 8261430 2452239 5726577 30% /oradata<BR>/dev/md/dsk/d34 1986439 3901 1922945 1% /opt<BR>/dev/md/dsk/d33 482824 1452 433090 1% /tmp<BR>/dev/md/dsk/d35 963869 1120 904917 1% /export/home</DIV> <DIV>通常做完镜像如果不重启的话，“Filesystem”这一栏下的内容不会变化，只有通过重启之后才能将镜像前“/dev/dsk/cxtxdxsx”这样的格式转化成为“/dev/md/dsk/dxx”这样的格式。</DIV> <DIV>我对“/export/home”文件系统做完镜像后重启，不能登陆系统，下面是故障现象和解决过程：</DIV> <DIV>1，连串口线启动到单用户模式，fsck对文件系统进行检查，出现下面的信息：</DIV> <DIV># fsck <BR>** /dev/md/rdsk/d30<BR>** Currently Mounted on /<BR>** Phase 1 - Check Blocks and Sizes<BR>** Phase 2 - Check Pathnames<BR>** Phase 3 - Check Connectivity<BR>** Phase 4 - Check Reference Counts<BR>** Phase 5 - Check Cyl groups<BR>105566 files, 2463510 used, 543076 free (34324 frags, 63594 blocks, 1.1% fragmentation)<BR><STRONG>Can't stat /dev/md/rdsk/d35（从这里可以看到对“/export/home”文件系统的镜像是有问题的，从而导致系统不能启动）</STRONG></DIV> <DIV>2，查看镜像状态：</DIV> <DIV>d35: Mirror<BR> Submirror 0: d15<BR> State: <STRONG>Needs maintenance（这里表示有问题）<BR></STRONG> Submirror 1: d25<BR> State: <STRONG>Needs maintenance（这里表示有问题）</STRONG><BR> Pass: 1<BR> Read option: roundrobin (default)<BR> Write option: parallel (default)<BR> Size: 2050461 blocks (1001 MB)</DIV> <DIV>d15: Submirror of d35<BR> State: <STRONG>Needs maintenance（这里表示有问题）</STRONG> <BR> Invoke: metasync d35<BR> Size: 2050461 blocks (1001 MB)<BR> Stripe 0:<BR> Device Start Block Dbase State Reloc Hot Spare<BR> c0t0d0s5 0 No Okay Yes </DIV> <DIV><BR>d25: Submirror of d35<BR> State: Needs maintenance <BR> Invoke: metasync d35<BR> Size: 2050461 blocks (1001 MB)<BR> Stripe 0:<BR> Device Start Block Dbase State Reloc Hot Spare<BR> c0t1d0s5 0 No Okay Yes </DIV> <DIV>3，检查/etc/vfstab文件：</DIV> <DIV># cat /etc/vfstab</DIV> <DIV>#device device mount FS fsck mount mount<BR>#to mount to fsck point type pass at boot options<BR>#<BR>fd - /dev/fd fd - no -<BR>/proc - /proc proc - no -<BR>/dev/md/dsk/d31 - - swap - no -<BR>/dev/md/dsk/d30 /dev/md/rdsk/d30 / ufs 1 no -<BR><STRONG>/dev/md/dev/d35</STRONG> /dev/md/rdsk/d35 /export/home ufs 2 yes -<BR>/dev/md/dsk/d34 /dev/md/rdsk/d34 /opt ufs 2 yes -<BR>/dev/dsk/c0t0d0s3 /dev/rdsk/c0t0d0s3 /tmp ufs 2 yes -<BR>/dev/dsk/c0t2d0s0 /dev/rdsk/c0t2d0s0 /oracle ufs 2 yes -<BR>/dev/dsk/c0t3d0s0 /dev/rdsk/c0t3d0s0 /oradata ufs 2 yes -</DIV> <DIV>这里可以看到，问题出现在“/export/home”前面的设备名称出现了问题，是“/dev/md/dsk/d35”，而不应该是“/dev/md/dev/d35”，通过vi编辑器修改/etc/vfstab文件中错误的内容，重启系统，问题解决</DIV>
查看全文
发表于:2007-09-13 ┆
阅读(445)
┆
评论(0)
52截图诠释Solaris8安装过程（五）
查看全文
发表于:2007-08-07 ┆
阅读(458)
┆
评论(0)
