日归档：2015 年 1 月 5 日

一些好玩的现象（表区分大小写，同一个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 | 标签为 | 留下评论

global_name为空导致的数据库不能open—–使用gdb修复(中断oracle启动的部分监测功能)

发表于 2015 年 1 月 5 日 由 Lunar

GLOBAL_NAME和props$对象介绍 global_name为空导致的数据库不能open—–使用dd修复(使用dd拷贝块的方式) global_name为空导致的数据库不能open—–使用DUL修复 global_name为空导致的数据库不能open—使用BBED修复（bbed恢复update的数据） 这篇为第1种方法，参考MOS文档，使用gdb中断后open数据库，再手工执行update语句保证 global_name 不为空。 首先了解一下，不同操作系统平台上的诊断工具有所不同，Linux和AIX上都可以使用gdb来诊断。 AIX（Big Endian）使用gdb诊断的例子请参考：一次体验N种报错的Oracle数据库恢复（ORA-704 ORA-604 ORA-600[25016] ORA-376） 我这里是Linux，即Little Endian 。 测试时，首先把global_name 置空： 此时，trace中显示 执行下SQL命令时，数据库报错： 下面使用gdb进行恢复： 然后，回到sqlplus的会话，直接执行alter database open： 回到gdb窗口： 回到sqlplus会话，看到数据库已经open： 此时alert.log显示： 现在修改global_name = ‘lunarbb’： 再次正常启动数据库，数据库已经open了，且GLOBAL_NAME显示为我们刚才修改的：lunarbb

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

global_name为空导致的数据库不能open—–使用dd修复(使用dd拷贝块的方式)

发表于 2015 年 1 月 5 日 由 Lunar

GLOBAL_NAME和props$对象介绍 global_name为空导致的数据库不能open—–使用gdb修复(中断oracle启动的部分监测功能) global_name为空导致的数据库不能open—–使用DUL修复 global_name为空导致的数据库不能open—使用BBED修复（bbed恢复update的数据） 这篇为第2种解决 global_name 为NULL导致数据库不能启动的方法。 即 从其他正常的11.2的数据库上使用dd命令克隆一个相同的block来替换现有system文件中的相同文件。 根据测试，猜测大版本一致即可，比如11.2.0.3和11.2.0.4的props$都存储在file 1 block 801上。 因此，我这里使用了11.2.0.4(基于ASM)的数据库上的file 1 block 801来替换 11.2.0.3（基于文件提醒）的数据库的file 1 block 801。 首先，props$在相同版本的数据库中，缺省的位置是固定的。知道了这个，就可以从其他数据库上检查相应的block，如果相同，直接dd过来。 首先备份当前的props$： 我们知道props$表中记录了数据库字符集，global_name等等关键信息，你可以使用strings来查看其他内容。 例如下面这样，在控制文件丢失，无备份，需要重建控制文件时下面的信息就很有用，主要是需要看字符集（NLS_CHARACTERSET），我这里是AL32UTF8： 查看props$这个表的具体位置： 这里可以看到是file 1 block 801 现在到其他一个可以open的11.2的数据库中复制这个block出来。 方法多的很，比如，你可以直接将asm文件复制到文件，然后直接使用bbed的copy命令将这个block 复制到当前损坏的库上。 也可以使用我这样dd的方法： 首先，将asm文件复制到文件系统（bbed不能直接读asm，一般采用这样的方法） 查看一下这个block的信息，可以看到，这个数据库版本(NLS_RDBMS_VERSION)是11.2.0.4，GLOBAL_DB_NAME的值是 LUNAR： 现在，将刚才dd出来块patch到11.2.0.3的数据库的相同位置 dd if=/home/oracle/test/lunar_11204.props.dd … 继续阅读 →

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

global_name为空导致的数据库不能open—使用BBED修复（bbed恢复update的数据）

发表于 2015 年 1 月 5 日 由 Lunar

GLOBAL_NAME和props$对象介绍 global_name为空导致的数据库不能open—–使用gdb修复(中断oracle启动的部分监测功能) global_name为空导致的数据库不能open—–使用dd修复(使用dd拷贝块的方式) global_name为空导致的数据库不能open—–使用DUL修复 这篇为第4种解决 global_name 为NULL导致数据库不能启动的方法—-本质是使用bbed来恢复update的值。 bbed的安装和配置，网上已经很多了，总的来说，就是12.1和11.2都使用10.2的bbed库进行编译，然后可以正常使用。 bbed的初始配置参考： BBED简介 即，使用BBED来直接修改一个block的数据的方法。这里将使用BBED将删除掉global_name值找回来。 注意： 这个方法实质就是使用BBED恢复一行被update的数据。 上次我们说过，很多方法都可以定位这个报错的数据块和global_name所在行的信息。 在中《global_name为空导致的数据库不能open—–使用DUL修复》，我们使用对比的方法。 这里，我们根据报错时生成的trace文件来定位这行报错的global_name在block中信息，然后使用bbed来修复。 首先，我们知道props$的数据存放在file 1 block 801中，那么转换存储地址为： 在bbed中验证一下，我们看到改块内共36行数据，这个信息在11.2的数据库中是固定的（缺省情况下，也就是没有手工修改时）： 那么，这行记录到底是第几行呢？ 使用bbed的find自然是可以search到，不过这个方法感觉不清晰。 下面，我们在trace中，搜索“0x00400321”关键字，找到“Block header dump: 0x00400321”相关部分： seg/obj: 0x62 转换成10进制是98，也就是对象号98(dba_objects.object_id=98)，这个正式props$对象的object_id： csc: 0x00.18c0ef –cleanoutSCN,块清除时的SCN itc: 2 —ITLcount, ITL的数量 flg: O —Block … 继续阅读 →

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

global_name为空导致的数据库不能open—–使用DUL修复

发表于 2015 年 1 月 5 日 由 Lunar

GLOBAL_NAME和props$对象介绍 global_name为空导致的数据库不能open—–使用gdb修复(中断oracle启动的部分监测功能) global_name为空导致的数据库不能open—–使用dd修复(使用dd拷贝块的方式) global_name为空导致的数据库不能open—使用BBED修复（bbed恢复update的数据） 这篇为第3种解决 global_name 为NULL导致数据库不能启动的方法。 即，使用DUL来直接修改一个block内部的数据的方法。 模拟损坏，将global_name置空： 那么如何定位到是哪一个block呢？ 答案是N中方法： （1）使用ODU定位这行记录的dba地址 （2）对比其他大版本相同的正常库的相同行的数据 （3）查看报错的trace，找到改行数据的和block 。。。。。。 我们这里使用第二种，查看其他相同版本数据库的信息。具体的方法在第一篇《GLOBAL_NAME和props$对象介绍》 中已经介绍了，这里不再赘述。 首先报错的数据库的alert.log信息如下： 可以看到，当前global_name已经被置空了： 现在修改 修改后的数据如下： 直接启动数据库：

发表在 DUL ODU | 标签为 , , | 留下评论

GLOBAL_NAME和props$对象介绍

发表于 2015 年 1 月 5 日 由 Lunar

有朋友遇到一个老问题，将数据库 global_name 置空后，数据库不能open。 这类问题已经是几年前的老问题了，这里用4中方法解决。 这一篇先大概介绍一下GLOBAL_NAME对象的来龙去脉。 GLOBAL_NAME和props$对象介绍 global_name为空导致的数据库不能open—–使用gdb修复(中断oracle启动的部分监测功能) global_name为空导致的数据库不能open—–使用dd修复(使用dd拷贝块的方式) global_name为空导致的数据库不能open—–使用DUL修复 global_name为空导致的数据库不能open—使用BBED修复（bbed恢复update的数据） 我们知道，全局数据库名是在分布式数据库系统中用于标识数据库的唯一名称，默认为DB_NAME.DB_DOMAIN。 该默认值在数据库创建的时候被标记，如果数据库创建后手工修改了DB_NAME或者DB_DOMAIN，全局数据库名称仍然保持为数据库创建时候的DB_NAME.DB_DOMAIN。 我们查看一下GLOBAL_NAME是什么类型的对象，其定义是怎样的： 可以看到，GLOBAL_NAME实际上是已于sys.props$ where name = ‘GLOBAL_DB_NAME’的一张视图和同义词。 props$中总共多少行数据，在相同版本是固定的，我这里是11.2，因此共36行： props$的定义如下： 看一下props$对象存储了哪些内容： 当数据库正常启动时，会对PROPS$表进行全表扫描来获取PROPS$中是否含有错误信息。 一般升级的时候系统会将数据库引导对象的错误信息记录到该表的BOOTSTRAP_UPGRADE_ERROR中： 启动时10046跟踪的trace中： 从这里我们看到，读取了file#=1 block#=800和file#=1 block#=801，他们分别为props$的段头和第一个数据块的位置。 他们的对象号是obj#=98，也就是props$。 从数据库中，我们也可以证实这一点：

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

BBED简介

发表于 2015 年 1 月 5 日 由 Lunar

Oracle8i 的BBED在windows 平台下的$ORACLE_HOME/bin下可以找到 ORACLE9i数据库就自带bbed程序，就在%ORACLE_HOME%/bin目录下，在linux上面也有，需要自己编译。 9i/10g bbed： 11g和12.1需要10g的5个文件（bbedzhs.msb是可选的）： BBED的缺省口令是 blockedit： 一般使用bbed，都是将一些配置信息写入到一个参数文本里，在调用bbed时，指定该参数文件。如： 先从v$datafile中获取file#,name,bytes，然后组成filelist.lst BBED常用命令： set 设定当前的环境 show 查看当前的环境参数，跟sqlplus的同名命令类似。 dump 列出指定block的内容 find 在指定的block中查找指定的字符串，结果是显示出字符串，及其偏移量–offset，偏移量就是在block中的字节数 modify 修改指定block的指定偏移量的值，可以在线修改。 copy 把一个block的内容copy到另一个block中 verify 检查当前环境是否有坏块 sum 计算block的checksum，modify之后block就被标识为坏块，current checksum与reqired checksum不一致，sum命令可以计算出新的checksum并应用到当前块。 undo 回滚当前的修改操作，如果手误做错了，undo一下就ok了，回到原来的状态。 revert 回滚所有之前的修改操作，意思就是 undo all 可以使用help来查看bbed的命令语法：

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