分类目录归档:Internal

使用DUL和ODU抽取Exadata上的oracle数据库(抽取磁盘上的数据文件)

之前研究过dul和odu,发现不能识别磁盘,当时犯了一个错误,因为普通环境(非exadata环境),都是在主机上运行扫描磁盘的工作,因此我之前也在exadata的主机上扫描磁盘,发现不行,具体参见: 在Exadata上,为什么 DUL 和 ODU不能读取ASM数据库的数据,但是Kfed却可以? 今天在exadata的存储节点(cell节点)上配置了一下,发现dul和odu都可以直接扫描磁盘,以后有exadata上oracle数据库损坏时,请联系我,O(∩_∩)O哈哈 具体测试如下: 这里我使用control+C终止了,因为磁盘太大了,扫描时间太久,上面的信息已经可以证明,至少可以扫描 至于normal external等其他问题,以后再说。 扫描文件具体如下: 这里 IDX_DATA1.dat 就是dul扫描出来的一些信息,之后使用命令抽成文件就依据这些。 再看看ODU: 这里报错是因为cell上磁盘空间很小,稍微一折腾就满了(存放ODU抽取文件的是根,100%了): 先别急删除,进去看看数据; 可以看到,odu也抽出了数据, 并且,可以看到,已经抽取了几个dbf的数据文件。

发表在 ASM, backup&recovery, DUL ODU, Exadata | 标签为 , , , | 留下评论

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

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拷贝块的方式)

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的数据)

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修复

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$对象介绍

有朋友遇到一个老问题,将数据库 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简介

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 | 标签为 | 留下评论

根据块号查看块内数据和修改时间的例子(普通表和压缩表)

今天微信群里有个朋友问起一个问题,顺手做了个测试。 问题是这样的: 1,怎么根据file# block#来判断这个block中有多少数据? 2,启用了高级压缩后,如何查看? 3,怎么判断这些数据插入的时间? 4,不适用dump block的形式,可以怎么观察? 最后一个问题不用测试了,不用dump的话,可以使用类似bbed等一堆工具,还可以使用event 10046跟踪来观察。 本次始终压缩相关的脚本可以参考blog: Exadata上的HCC测试(EHCC)——1 Exadata上的HCC测试(EHCC)—2—:DBMS_COMPRESSION.GET_COMPRESSION_RATIO Exadata上的HCC测试(EHCC)—3—分区表的压缩 关于HCC压缩的块结构参见: Exadata上HCC表的数据块结构—1-非压缩数据块结构 Exadata上HCC表的数据块结构—2-BASIC Compress和OLTP Compress Exadata上HCC表的数据块结构—3-HCC块(compress for query low) 前三个问题,一次测试如下: 因为朋友问到ASM的情况,这个需求实际上跟是否使用ASM无关,是ORACLE DB的原理,测试环境如下: 随便找一个block,或者指定一个block都可以: 查看这个block中有多少条数据: 这里看到,目前这个block中存储了88行记录。 查看这88行数据是什么时间插入的,以及他们的ROWID: 这里看到有88行,跟前面的结果是一致的。 看看这个表中有多少个block,以及他们的块号: 因为要测试压缩,那么先看看现在该表的压缩状态,这里我的LUNAR表是没有压缩的: 这里的查询方法,参考: 现在启用压缩(HCC只能在exadata上,否则会报错): 再次查询,可以看到,已经是高级压缩了: 这里可以看到,rowid已经改变了,这是因为块的存储格式已经变化了: 看下现在这个LUNAR表使用了哪些block: 这里看到比刚才已经减少了17-12=5个block。 查询每个block中的记录数: … 继续阅读

发表在 Internal, 内部机制 | 标签为 , | 一条评论

通过修改控制文件来修改SCN

之前有一些简单介绍SCN的文章: 浅谈SCN_1–从oracle7至今,如何获取scn 浅谈SCN_2–_kcmgas_函数 使用ORACDEBUG 修改 数据库SCN 这个测试是接着上次的使用oradebug修改SCN的,这里使用修改控制文件SCN和相关标示位的方法: 这个测试,我们把SCN增加100万,即从 2726293 修改为 3726293。 查看当前控制文件的位置: 将控制文件拿到本地,进行修改,修改过程如下: 首先找到数据库SCN: 修改SCN和相关标示位: 讲数据库shutdown,然后将修改后的控制文件copy到ASM中,并使用这个控制文件启动数据库: Mount数据库,并查看数据库SCN: 这里我们看到,数据库的SCN已经修改为我们指定的 3726296了。

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

使用ORACDEBUG 修改 数据库SCN

之前有一些简单介绍SCN的文章: 浅谈SCN_1–从oracle7至今,如何获取scn 浅谈SCN_2–_kcmgas_函数 通过修改控制文件来修改SCN 1988年Oracle发布了Oracle V6,这一版本中Oracle引入了热备的操作,同时SCN使用48位存储的算法写死在代码中,一直沿用至12c以前(12c开始使用8个bytes存储SCN)。由于ORACLE的SCN是由48位来表示的,因此最大值不能超过2的48次方 Oracle为了确保48位的SCN能够用足够长的时间(500年),于是对SCN做出了一个限制,就是每秒钟SCN最大增长不能超过16K,Oracle从1988年1月1日0点0分0秒为基准时间,到当前的秒钟数乘以16K,就是当前SCN的最大允许值这就是SCN HEADROOM。 因此SCN天花板 的计算公式就类似于: (当前时间-19880101 000000)*16384–(current_scn),其中 16384是SCN的内部增长速度16k,这是代码中的硬限制。 这个限制在11.2.0.2版本之前,scn 的最大增长频率是16k,在11.2.0.2版本开始,为32k。 此行为是受到下面参数_max_reasonable_scn_rate控制的: 在11.2中,Oracle除了将SCN 每秒最大的增长量从16K加大为32K,还引入了一个阀值,用于阻断有SCN HEADROOM问题的系统将故障传播到其他系统。 这些修复包含在下列补丁中: 如果SCN发生突增的情况,alert中就会出现类似下面的告警: 因此,打了这上面这些补丁后,就不能使用以前的参数直接修改SCN了。 然后,有时候数据库遇到一些异常错误,还是需要将SCN推进的到一个合适的值,例如,常见一些错误造成数据库的部分block跟数据库SCN不一致,或者一些有undo$数据库启动时引导失败: ORA-600 [2256] ORA-600 [2662] ORA-600 [4000] ORA-600 [kcsadjn1] 在以前我们使用参数来修改SCN,例如: event=”10015 trace name adjust_scn level x” 或者使用 _minimum_giga_scn … 继续阅读

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