月归档：2013 年十一月

exadata HC-检查是否有硬盘需要更换

发表于 2013 年 11 月 24 日 由 Lunar

在做exadata的检查的时候，我们通常收集如下信息： 1，exachk 2，sundiag 3，diagcollect（GI版本从11.2.0.4.x开始， 可以使用TFA Collector） 4，awr 5，db节点和cell节点的alert 6，osw 根据上述检查内容是否存在异常可能还需要 CheckHWnFWProfile等等。。。。 本文主要分析如何识别磁盘损坏的内容。 ++++++++++++++++++++++++++查看cell 的alert，检查是否有磁盘需要更换的信息： 检查cell的alert告警信息： dcli -g cell_group -l root “cellcli -e list alerthistory” 查看关键内容： 例如： +++++++++++++++++++++++++++看sundiag的信息： 收集sundiag信息后，你会发现，每个db节点和cell节点的文件非常多，包括RAID，HCA, Infiniband，。。。等等 例如： 针对磁盘损坏信息，主要检查如下内容： —————–检查坏盘： ———————检查报告了“先兆失效”的盘： ———-检查告警的磁盘信息： 使用cellcli查看磁盘的错误信息： 检查ASM的日志是否有类似如下的告警： 1. WARNING: failed to … 继续阅读 →

发表在 日常运维 | 标签为 , , | 留下评论

如何看待exadata的cell节点出现的writethrough/wirteback模式更换或者控制器充放电信息

发表于 2013 年 11 月 24 日 由 Lunar

Exadata使用的是LSI的disk driver，在定期进行的HC中，如果cell上出现类似下面的信息，需要考虑是否需要更换或者bug： 这个信息意味着disk controller写cache的策略从”write-back” 更改为 “write-through” 了，原因是电池学习周期（battery learn cycle）正在进行。 这个学习周期一年回周期性的执行4次，这个操作主要是每次执行一次控制器电池的充电和放电（discharge and charge）操作。 在Image 11.2.1.3之前，每个月执行一次 从Image 11.2.1.3开始，每3个月执行一次： 每年的1月/4月/7月/10月 的17日凌晨2点 这个缺省的时间(下一次学习的时间)可以使用命令修改，例如： cellcli> alter cell bbuLearnCycleTime=”2013-01-22T02:00:00-08:00″ Oracle推荐所有cell磁盘的电源学习周期是同一个时间。 众所周知，Write-through 的性能比 write-back 差。但是当存储crash或者电源丢失（looses power）发生时，write back有丢数据的风险。 因此，在电池学习周期中，会自动将写策略从写回模式（write-back）修改为写模式（Write-through） 如果在cell 的alert上看到类似下面的信息： 需要连接到cell节点，查看一下电池充电的百分比： 当充电完成后，可以在cell的alert上看到如下信息： 连接到cell节点，查看磁盘的写模式（writethrough/writeback）的状态，可以发现： 同样在 上面信息显示了10月17日凌晨:02:00cell01上有一个逻辑盘开始学习，完成时间是10月17日早上7:33。充电完成后，磁盘驱动器已经改回了writeback模式。 通常电池充电（Learning state）可能需要几个小时，如果充电完成后没有自动改回wirteback模式，可能是控制器电源出现问题，需要联系support … 继续阅读 →

发表在 体系架构, 安装和升级, 硬件配置 | 标签为 , , , | 留下评论

如何查看你的环境是否是RAC环境？ 如何判断你有哪些option？如何enable或者disable他们？

发表于 2013 年 11 月 23 日 由 Lunar

前几天一个老同事问我，客户不想买RAC 的license了，怎么办？ 因为当时他们有其他机器安装新环境，因此，我当时就说，直接装一个单机库，把数据库迁移过去，cluster_database改成false，再清理掉thread，undo，redo就ok了。。。 今天忽然想起来，如果客户不买partition选项了，想关闭这个怎么办？或者客户没有新机器再装一个ORACLE_HOME了，怎么办？ 后面的我们就研究下： 首先我们可以使用OUI或者opatch去看已经安装了哪些选项（当然，还可以看数据库视图） 方法1： 使用OUI去review ./runInstaller 里面有一个 “Installed Products”，这个是你已经安装的产品 方法2：使用OPATCH [oracle@lunar lib]$ opatch lsinventory -detail Invoking OPatch 11.2.0.1.7 Oracle Interim Patch Installer version 11.2.0.1.7 Copyright (c) 2011, Oracle Corporation. All rights reserved. Oracle Home : /u01/app/oracle/product/11.2.0.3/dbhome_1 Central … 继续阅读 →

发表在 FAQ, RAC | 标签为 , , | 留下评论

无法解释的ORA-12537

发表于 2013 年 11 月 22 日 由 Lunar

今天忽然想看下12c的一个小东东，结果遇到ORA-12537： 我这个VM当初装的很别扭，前一段又折腾了一下，更加别扭了，主要问题如下： 1，初始加盘的时候整的太小了，只给了12G，结果装了grid后，再装oracle软件就很困难，这里grid的所在的盘mount在/u01这个目录下 2，然后增加了一块盘，结果没吸取教训，继续折腾太小了，还是12G，不过12c可以装上玩了，这个oracle的软件所在的盘mount在 /u01/app/oracle目录下 3，前一段时间觉得磁盘空间不够了，于是把一个11.2的vm的软件使用root用户tar过来，解压后，ORACLE_BASE和ORACLE_HOME目录是：/u01/app/oracle（这个跟12c的oracle软件是同一个ORACLE_BASE）和/u01/app/oracle/product/11.2.0.3/dbhome_1 够乱了吧，O(∩_∩)O哈哈~ 检查listener.log： 发现报错：TNS-12518: TNS:listener could not hand off client connection 于是google，mos，设置一堆乱七八糟参数，并设置了trace： trace中最后出问题的信息如下，貌似是某些文件找不到或者权限问题： 使用strace sqlplus sys/oracle@lunarbb as sysdba进行跟踪，发现了如下可以信息： 貌似写什么东西时报错了 MOS了一下，Troubleshooting ORA-12537 / TNS-12537 TNS:Connection Closed (Doc ID 555609.1) 发现，我的这个文件没啥问题，权限都对： 这时候，看见刚刚修改过的oracle文件权限不对了，再重新修改回去： 重启下ORACLE，再测试，居然好了，O(∩_∩)O哈哈~：

发表在 network, ORA-XXXXX, ORACLE 12C | 标签为 , | 留下评论

随心所欲的指定RAC中的节点号

发表于 2013 年 11 月 21 日 由 Lunar

考虑到节点逐出的规则，其中有一个跟节点号有关系，即缺省节点号小的被保留，大的被逐出（还有很多其他条件，比如分组等，这里不细说） 那天群里有人说了希望修改节点号的需求，今天忽然想起来试试看，结论如下： 1，可以使用ocrpatch任意指定任一个节点的节点号 2，不指定的情况，安装的节点为节点1，其余的顺次往下排 备份下当前OCR和VOT的信息： 这里，我们可以看见，节点1（rac1）的节点号是1，节点2（rac2）的节点号是2。。。 我打算把它修改为节点1（rac1）的节点号是2，节点2（rac2）的节点号是1 只读模式使用ocrpatch： 好了，现在我们来修改下 再开2个会话，分别用于停止节点1和节点2的crs： 注意这里，节点1，貌似hang住了。。 节点2已经clear shutdown了 于是想起来了，还有一个ocrpatch的窗口，退出后，大概几秒钟，继续shutdown： 在节点1以独占模式启动cluster： 把voting disk放到文件系统上： 以write read方式访问ocr： SYSTEM.css.nodenum_hint ，这个表示他们的 “preferred” node number ，这个是节点1，我们看到设置为1，现在，我们把它设置为2，然后观察下： 已经修改成功了。 ocrpatch> exit [OK] Exiting due to user request … [root@RAC1 tmp]# 现在，使用独占模式启动crs： 检查状态，都正常： 初始化votdisk： … 继续阅读 →

发表在 ASM, RAC | 标签为 , , | 留下评论

4种查询vot的方法和4种查询ocr的方法

发表于 2013 年 11 月 21 日 由 Lunar

一、查找voting disk 的4种方法 方法1： 方法2： 方法3： 方法4： 这里可以看到au是1M，voting disk从AU 192开始，到AU 224结束，共32个AU ： 跳过了头上的192M，dump了后面的32M内容，也就是我们需要的VOTING DISK的32个AU的内容 二、查找ocr的方法 方法1： 方法2： 方法3： ocrdump 方法4： 这里看到ocr的文件号是255，可以根据文件号查询AU:

发表在 ASM, RAC | 标签为 , , | 留下评论

今天玩vm的收获-1,LVM管理真方便-2,ip地址改完了别忘了修改listener和local_listener

发表于 2013 年 11 月 11 日 由 Lunar

今天继续整合vm，遇到两个问题，一个是，空间和一两句话说不清楚的目录问题，一个是ip地址问题，都是小蚂蚁问题，记录一下，好玩，O(∩_∩)O哈哈~ 这个是空间问题： 你可以看到，我的这个有2个盘分别存放了grid软件和oracle软件，分别用了两个盘，分别挂载到两个目录: /u01 和 /u01/app/oracle 于是，我就想到应该扩展根目录，然后把tar文件放到根目录下，在解压，应该就自动合并到/u01/app/oracle了。 我的一个11.2.0.3的vm也是/u01/app/oracle目录。 我们都知道，使用root用户tar一个目录，解tar时，直接按照原有目录解压，但是今天测试了好几个参数，都不行 我怀疑就是因为不同的盘上有了相同的目录，比如/dev/sde1 挂载到了 /u01/app/oracle，跟不够大，我把tar过来的11.2.0.3.tar放到了新建的盘/dev/sdf1上 挂载到/other上，因此解压的时候，目录就变成/other/u01/app/oracle了 这样我的这套11.2的环境就有问题，需要修改一些东西，比较麻烦。。。 弄好后，测试下两个环境，一个oracle 12.1，一个是oracle 11.2.0.3 这里启动数据库，遇到另一个小问题： 找不到spfile，检查下，果然没有spfile和init： 弄个pfile出来看看，把这个“鸡肋”LOCAL_LISTENER注释掉试试看，然后果然可以了，没有报其他错误了，说明我的vm还是好的 （最近每天折腾vm，都是从活动硬盘上copy回来的，总是有各种妖怪问题）： 我这个人养成了一种习惯，不找原因，先琢磨workround，但是回过头来，还是要看看怎么弄的 怀疑ip地址有问题，检查/etc/hosts，果然，这里的ip地址不对，从活动硬盘copy来的，里面ip沿用的以前的vm的配置： 检查tnsnames.ora，发现问题了: 这里 LISTENER_LUNARBB 使用的是机器名，而 oracle在启动的时候会根据local_listener参数的设置去找检查相应的主机名和端口号，我这里有两个错误： 1，主机名，很可能这里的HOST = lunar本身就有问题，因为我以前的老ip对应着现在的新ip的主机名，都是lunar 2，端口号写成了主机名（这个错误很奇怪，这东西按说都是自动生成的。。。。。。） 今天还学习了一个，使用LVM管理，很方便的扩展一个目录，今天是扩展的根目录，感谢bbq同学O(∩_∩)O哈哈~ 逻辑卷真方便，这里顺便记录一下： 假设你新加的硬盘是sdf 在vm上新建一个盘，使用fdisk -l找出这个盘，比如我这里是 /dev/sdf（比如，大小30g），然后创建pv： pvcreate /dev/sdf … 继续阅读 →

发表在 FAQ | 留下评论

不同版本客户端连接服务器的问题

发表于 2013 年 11 月 10 日 由 Lunar

可以看到，从10.2开始，还支持连接oracle 817的数据库，但是已经不支持连接到oracle 816的数据库了，查了下文档，内容如下： 今天连接时遇到 TNS-12560: TNS:protocol adapter error，顺便说一下，这个问题比较常见，常见原因有几种： 1，防火墙设置问题，关闭防火墙（service iptables stop） 2，修改了/etc/hosts的ip地址后，需要重启listener 3，listener.log过大（新版本中这个问题好多了） 4，10g中有一个注明的bug，listener会启动一个子监听造成listener hang 5，tnsnames.ora中配置的ip地址等不对 。。。。。。。。。。。。。。。

发表在 FAQ | 留下评论

解除部分exadata上的“强安全策略”

发表于 2013 年 11 月 9 日 由 Lunar

在安装Exadata时，执行onecommand的后面几步ResecureMachine相关的内容后，安全性会得到增强，我们戏称为“强安全步骤”，不同的onecommand版本的step稍有差别，但是可以从deploy脚步的执行步骤的名称中识别出来，例如onecommand p14210449 （对应image 11.2.3.1.1）的如下（其中setp24~setp26）： 在onecommand p16383189（对应 image 11.2.3.2.0，image 11.2.3.2.1的步骤跟这个一样的）中是如下步骤，其中step25~step28是“强安全”： 在执行了上述步骤后，一些客户使用一段时间后对于其中的“强安全”感觉很不方便，希望我们修改其中的部分限制，比如90天必须修改口令等等，下面就类似问题给出解决方案。 本文的方法来自于内部exadata的一个文档，且在多个客户都已经实施过了： 1， 解除口令限制和复杂度： 使用root用户修改/etc/pam.d/system-auth，这是一个password的的入口文件（老一点的linux系统一般用/etc/pam.d/passwd），将其中的”min=disabled,disabled,16,12,8″ ，使用这个规则建立的口令很难被破解，修改为”min=1,1,1,1,1″，大大降低了口令的复杂程度（容易被破解，例如“oracle”，或者exadata上的缺省的welcome等等，都是常用词汇。。。） 然后重置root口令即可（exadata上大部分缺省口令是welcome） 2， 解除90修改口令的限制： 执行下面的命令修改用户口令修改策略： 当然，你需要在所有节点依次执行，exadata上的dcli可以很方便的完成： 然后使用上述用户登录的缺省口令就可以登录了（缺省口令都是welcome） 3， 重新配置各个节点的SSH信任关系（因为执行了ResecureMachine以后，SSH信任关系操作就不可以了）： 也可以参考我之前的一篇blog（其中的脚本在11.2.0.1的除windows平台外的任何一个安装包中都可以找到）： 使用Oracle安装包的ssh配置机器互信 注意： 如果有问题可以参考bug 12389246 4， 解除SSH连接超时的限制： 顺便多说一下，由于某些原因用户可能会出现密码尝试次数过多账号被锁定的问题，具体的设置在/etc/pam.d/system-auth文件，例如，exadata上的： 清除某个用户的登陆失败次数，让改用户可以重新登陆的命令： pam_tally2 -r -u username 例如， 清除 oracle用户的失败登录次数：pam_tally2 -r … 继续阅读 →

发表在 FAQ, 日常运维 | 标签为 | 留下评论

一个老系统的老问题：ORA-01031: insufficient privileges

发表于 2013 年 11 月 9 日 由 Lunar

今天打算整合一下所有的vm（除了12c），把他们都放到一个vm中，结果发现遇到郁闷问题： –第一反应是口令文件有问题，于是检查，发现果然缺少口令文件： –还是不行，是否因为大小写的关系（因为之前的那个vm已经迁移到活动硬盘了，懒得打开查看SID了），因此修改为大写试试看： –使用密码文件的认证方式测试本地登录是可以的： –怀疑是sqlnet.ora的设置有问题，结果居然没有，这个vm是7,8年前的，不知道什么原因，居然没有这个文件，创建一个吧： –这里居然冒出来ORACLE_HOME设置不对，郁闷了。。。。。。 –重新执行环境设置脚本： –这是，怀疑是oracle用户本身的问题，于是检查oracle用户的属组： –经过小伙伴的提醒，发现这个VM居然使用了破烂SELinux，sigh。。。。。 –SELinux系统比起通常的Linux系统来，安全性能要高的多，它通过对于用户，进程权限的最小化，即使受到攻击，进程或者用户权限被夺去，也不会对整个系统造成重大影响。 –但是往往有些应用的使用也会受到限制，比如有时候tar一个大目录的时候可能会失败，有时候ftp东西的时候有问题，等等 –其实一般ORACLE的文档上也是明确说明要关闭SELinux的，例如： –5.11 Error While Loading Shared Library When SELinux is Enabled on Red Hat Enterprise Linux 5 –SQL*Plus and Oracle Call Interface (OCI) program calls fail when selinux is … 继续阅读 →

发表在 FAQ, ORA-XXXXX | 留下评论