作者归档：Lunar

解决Exadata上IB检查脚本infinicheck的报错过程

发表于 2015 年 4 月 5 日 由 Lunar

今天检查Exadata的IB网络时，使用 infinicheck 检查，发现db节点有报错，cell节点正常。 当前主机是Exadata X5-2： infinicheck的执行结果（该命令可以有很丰富的参数，但是也可以不带任何参数，缺省就可以）： 从这里我们看到，凡是到db节点的都报错。 infinicheck命令底层是调用的rds-stress命令，例如： rds-stress -r 192.168.10.1 -p 10584 当然，除了infinicheck意外，还有其他很多检查方法，比如rds-ping(ExaWatcher和OSWatcher中调用的这个命令)。 很奇怪，为什么就db节点报错？ 于是，使用infinicheck 带参数-b -g 来检查和配置一下DB节点的IB的SSH连通性： 这里我犯了个错误：这个命令需要配置IB的基于IP的SSH(root)，而不是主机名 这里很清晰的告诉我们，ping不通，O(∩_∩)O哈哈~，这个就好办了。 接下来，我们手工ping看看： 那么ping第2个节点的主机名试试看，证实一下是不是解析的问题： 这里我们看到，果然是解析的问题。 由于IB网络是Exadata内部互联用的，因此没有在DNS解析，只在/etc/hosts中解析。 而/etc/hosts文件是由onecommand配置的（除非手工安装，否则使用了onecommand后，所有配置文件都由onecommand根据配置xml文件自动生成） 从这里我们看到，IB网络的IP配置格式是错误的，正确的是： 127.0.0.1 localhost.localdomain localhost 错误的是： 192.168.10.1 dm01db01-priv1.lunar.com dm01db01-priv1 修改了上述hosts文件后， 纠正hosts文件后，发现ping主机名的问题解决了： 这里还有个问题很奇怪，cell节点的hosts文件也是错误的，但是却可以ping通，怀疑跟DNS缓存有关系： 现在，再次使用infinicheck 带参数-b -g … 继续阅读 →

发表在 故障诊断 | 标签为 , | 留下评论

CPU E5 / E5 v2 / E7 v2的运行超过208天后，热重启后系统异常

发表于 2015 年 3 月 14 日 由 Lunar

昨天朋友（感谢bbq和很多热心朋友）告知一个Linux的bug: E5 / E5 v2 / E7 v2的运行超过208天后，热重启后（比如 shutdown -r），TSC时钟不能被clearout，因此在重启后TSC会继续之前的计数，造成系统异常。 （涉及的Linux内核版本列举在最下面红帽说明中） . 红帽的官方说明： https://access.redhat.com/solutions/433883 . 由于Linux时钟机制引起的bug很多， Linux中有3种timer： 1、Real Time Clock(RTC)：RTC是位于CMOS中的 2、Programmalbe Interval Timer(PIT)：PIT主要由8254时钟芯片实现的 3、Time Stamp Counter.(TSC)：TSC的主体是位于CPU里面的一个64位的TSC寄存器。每个CPU时钟周期其值加一 类似的时间引起宕机的问题很多跟Linux的TSC时钟机制有关系，比如： . 今天看见飞总也在讨论， 具体参见： http://www.xifenfei.com/5760.html . Exadata X5目前没有发现这个问题： Exadata的db node： CPU E5 2699 v3； … 继续阅读 →

发表在 Linux | 留下评论

Exadata X5 软件和硬件的新特性概览

发表于 2015 年 2 月 10 日 由 Lunar

Exadata X5的新特性，很有意思，软硬件都有很多改变，个人感觉最突出的硬件改变是X5只有两种磁盘配置： 1，全闪配置（EF） 2，SSD(Flash F160 NVMe PCIe card with 1.6 TB)+4T（HC DISK） 然后就是内存增加，CPU升级等等。。。 下面的信息来源于强大的MOS： Oracle Exadata Database Machine X5-2 Support ……New Exadata X5-2 Database Server . Exadata X5-2 updates the 2-socket database servers to use the latest and fastest Intel … 继续阅读 →

发表在 性能指标 | 标签为 | 留下评论

oracle一些块损坏和常见数据库损坏的相关概念和处理

发表于 2015 年 1 月 29 日 由 Lunar

最近帮朋友做了一个公开课（大概2小时吧），大概介绍了一下oracle一些块损坏和常见数据库损坏的相关概念和处理。 这里谈到的东西很少，很多内容细讲都是一门学问，我这里介绍的只是大概的概念，冰山一角。对于oracle大牛们来说，不算是什么，O(∩_∩)O哈哈~ 下周打算给公司的同事们介绍一下。 目前pdf可以下载了Oracle常见错误处理-lunar 后续朋友整理好录音等东西，也会上传到这里，与你共勉，请多指教 ：）。 本次公开交流的内容已经放到优酷了：

发表在 backup&recovery, ORA-600/7445 | 标签为 , | 留下评论

ORA-00704 ORA-00604 ORA-01502: index ‘SYS.I_ACCESS1’ or partition of such index is in unusable state

发表于 2015 年 1 月 6 日 由 Lunar

如何处理下面的错误？ ORA-00704 ORA-00604 ORA-01502: index ‘SYS.I_ACCESS1’ or partition of such index is in unusable state 方法跟ORA-00704 ORA-00604 ORA-01502 SYS.I_DEPENDENCY1损坏或者不可用的是一样的，这里不赘述，简单模拟损坏并修复的过程如下： I_DEPENDENCY2损坏的处理 11.2中I_DEPENDENCY1损坏的处理 例如： 相应的trace如下： 解决问题： 然后将数据库启动到限制模式，rebuild该index：

发表在 backup&recovery, ORA-600 or ORA-7445 | 标签为 , | 留下评论

I_DEPENDENCY2损坏的处理

发表于 2015 年 1 月 6 日 由 Lunar

我们知道，在10.2中如果SYS.I_DEPENDENCY1损坏或者不可用时，数据库open时就会报如下类似错误： 10g中I_DEPENDENCY1损坏的处理 11.2中I_DEPENDENCY1损坏的处理 那么如果I_DEPENDENCY2有问题时，什么结果呢？ 我们还是在10.2.0.1中测试： 测试结果，数据库可以正常open，但是alert后报错，显示如下： 修复的方法很简单，直接将该索引的状态设置为失效，然后rebuild，具体操作，参考ORA-00704 ORA-00604 ORA-01502 SYS.I_DEPENDENCY1损坏或者不可用

发表在 backup&recovery, ORA-600 or ORA-7445 | 标签为 | 留下评论

11.2中I_DEPENDENCY1损坏的处理

发表于 2015 年 1 月 6 日 由 Lunar

上一篇，我们测试了10.2中，i_dependency1失效的过程和处理方法。 参考10g中I_DEPENDENCY1损坏的处理 I_DEPENDENCY2损坏的处理 这里，我们在11.2中模拟i_dependency1失效（测试环境使用11.2.0.3）： 11.2中：先看一下，数据库中跟依赖关系相关的表都有哪些： 可以看到，10g是18个，11.2是24个。 10g和11g中，DEPENDENCY$表都存在两个索引，这两个索引损坏时对数据库的影响是不同的，他们分别定义如下： 他们存储在哪些block中： 10g和11g的DEPENDENCY$ 和 I_DEPENDENCY1、I_DEPENDENCY2定义都一致的，只是处理方法不同。 现在我们在11.2.0.3模拟i_dependency1失效，看看什么效果： 相应的alert.log信息如下: 说明已经标示 SYS.I_DEPENDENCY1 为无效了。 现在启动数据库看看： 没错，就是这个结果，从11.2开始，类似I_DEPENDENCY1这样的index的失效不会数据库不能open了。 而在10.2中，需要open upgrade模式。 现在修复这个索引： 注意 ：11.2跟10.2还有一个小区别（感觉无关紧要）：11.2多取了一个字段“type#”： 那么11.2为什么可以直接open呢？ 首先，我们来看一下，当 I_DEPENDENCY1 正常时，数据库open的相关动作： 该语句执行7次，七次的执行计划都是上面这样的。 当I_DEPENDENCY1为UNUSABLE时，该语句仍然执行7次，但是7次的执行计划都类似下面的，走“TABLE ACCESS FULL DEPENDENCY$”。 这说明oracle 11.2的二进制代码多了一个判断的功能，当发现I_DEPENDENCY1为UNUSABLE时自动修改了执行计划（没有验证其他类似索引是否都是这样的）： 推测：11.2的代码里面写死了一个判断当open数据库时，如果遇到类似DEPENDENCY$这样的表的索引失效了，那么直接对DEPENDENCY$进行全表扫描。

发表在 backup&recovery, ORA-600 or ORA-7445 | 标签为 , | 留下评论

一些好玩的现象（表区分大小写，同一个owner下有同名的表名存在等等）

发表于 2015 年 1 月 5 日 由 Lunar

一些好玩的现象： 1、谁说同一个用户下面不能有两个表是同名的，看看下面，O(∩_∩)O哈哈~： 2、再看下面，我的库没有引导表了，O(∩_∩)O哈哈~： 3、看这里，表名区分大小写了，你知道为什么么？——— O(∩_∩)O哈哈~： 4、你知道这是为什么么？————很好猜，O(∩_∩)O哈哈~ 5、被删除的表名被占用了，不能重用，这是为什么？ 这是整个玩耍过程中，最郁闷的问题了……………………………… 好了，不玩了，还原回来了，O(∩_∩)O哈哈~：

发表在 未分类 | 留下评论

ORA-00704 ORA-00604 ORA-01502 SYS.I_DEPENDENCY1损坏或者不可用

发表于 2015 年 1 月 5 日 由 Lunar

有朋友问起ORA-00704 ORA-00604 ORA-01502: index ‘SYS.I_DEPENDENCY1’ or partition of such index is in unusable state错误怎么处理。 11.2中I_DEPENDENCY1损坏的处理 I_DEPENDENCY2损坏的处理 当SYS.I_DEPENDENCY1损坏或者不可用时，就会报如下类似错误： 首先说一下，10g中的处理方式，有两种： 1，直接在10g中修复 2，使用11.2将数据库拉起来到upgrade模式，然后修复 先看一下，数据库中跟依赖关系相关的表都有哪些： 这里，我们关心的是DEPENDENCY$的索引信息，可以看到，DEPENDENCY$表存在两个索引。 这两个索引损坏时对数据库的影响是不同的，他们分别定义如下： 9i、10g、11.1以前，一些核心对象的定义就在$ORACLE_HOME/rdbms/admin/sql.bsq中。 比如tab$,obj$,ind$等等的定义都在其中。 从11.2开始，创建一些重要的核心基表的脚本仍然是sql.bsq，但是已经将各种对象的创建分类到不同的脚本： dependency$，i_dependency1和i_dependency1的定义如下（10.2和11.2没有区别）： 下面我们看一下他们使用了哪些block： 下面我们在10.2总模拟i_dependency1失效（测试环境使用10.2.0.1）： 执行alter index i_dependency1 unusable后，alert.log的信息如下： ind$的flags字段的定义（该定义可以查询基表定义，10.2中在sql.bsq，11.1以后，在dcore.bsq）： 通过对比，可以发现实际上对于ind$.flags的定义并没有改变，只是内部操作有所变化。 这些标示很有用，比如orcacle 9204有监控SYS的XXX索引的bug会导致数据库不能open，可以通过这个标示来修复。 再比如，10g以前online 创建索引中断后很麻烦，也可以通过修改这个来修复。 10.2以后可以通过dbms_repair.online_index_clean来清理索引状态。不过该功能没有记录在10.2的官方文档中（但是用desc … 继续阅读 →

发表在 backup&recovery, ORA-600 or ORA-7445 | 标签为 , , | 留下评论

根据一个给定的rowid手工推算他的file#,block#,obj#,row#

发表于 2015 年 1 月 5 日 由 Lunar

从Oracle 8i开始使用扩展rowid标识行物理地址，扩展rowid使用base64编码行的物理地址，编码字符包含A-Z, a-z, 0-9, +, 和/。 扩展rowid由四部分组成：OOOOOOOFFFBBBBBBRRR。其中： OOOOOO：数据对象编号（6位显示） FFF：相关数据文件编号（3位显示） BBBBBB：数据块编号（6位显示） RRR：数据块中行编号（3位显示） 8i以后，rowid采用base64编码（基于64位的编码）的扩展rowid. . 关于64bit编码表，可以搜索Google或者Baidu，关键字“Base64编码表”。 将64位编码转换为十进制： file#: AAB —–> 0 0 1 —–>0*64^2+0*64^1+1*64^0 =1 block#: AAAAMh —–> 0 0 0 0 12 33 —–>0*64^5+0*64^4+0*64^3+0*64^2+12*64^1+33*64^0 =801 obj#: AAAABi —–> 0 0 0 … 继续阅读 →

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