标签归档:bbed

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

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

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

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

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

oracle数据块如何定位到ASM中?在exadata定位block的思路是什么?

前几天有个朋友提出一个“老问题”,数据库上的block能否对应到EXADATA的block上,我答应做个demo,一直没时间,今天闲了,玩了一下: 对于EXADATA来说,这个需求设计两个问题: 1,数据库的block如何对应到asm中 2,exadata上的block如何对应到cell上的物理盘(griddisk,celldisk都是逻辑概念) 首先创建测试表: create table lunartest as select * from dba_users; –查找里面用户名为LUNAR的ROWID: 记录一下这个表的username=’LUNAR’的数据的rowid,便于验证数据。 然后找到该表的第一个block,也就是segment header,方法至少有3种 1,通过dbms_rowid 2,通过dba_extents 3,通过dba_segments 这里我们随便选一种,找到了该block的位置: 查看当前ASM的AU尺寸和BLOCK尺寸(通常是缺省的,不排除特殊客户自己设定的或者exadata的情况,因此还是找一下): exadata上使用KEFED的例子可以参考《Exadata上验证ASM磁盘头备份的位置》 我的数据库为8k的数据块(db_block_size),那么计算一下对应到ASM是哪一个extent: lunartest表在DATA DG的asm file 1755上: 如果是exadata,那么输出类似下面的,这里并没有本质区别(区别在通信方式上,后面会讲……): 根据上面的计算,查找这个表的第一个数据块在哪一个ASM的diskgroup,disk和AU的信息: 如果是exadata环境,那么查询到的信息,对应到这里的/dev/lunarlun02可能就是类似下面的:o/192.168.10.3/DATA_DM01_CD_00_dm01cel01: 这里也就对应到cell01(IP为:192.168.10.3) 具体例子可以参考:Exadata更换硬盘的操作过程和解释 使用dd 我们用dd验证一下数据,: 验证数据:这个LUNARTEST是根据DBA_USERS做的CTAS,因此上面我们有一行测试数据,这里可以找到: 因为是别人的生产库,不能使用bbed等工具瞎折腾,因此,我这里使用UltraEdit查看这个块来验证数据: 可以看到数据是吻合的。至此,上面将oracle的block对应到ASM是没问题的。 另外,如果要想观察asm的具体操作,还可以使用strace,比如 read64(15, … 继续阅读

发表在 ASM, 内部机制 | 标签为 , , | 留下评论

浅谈Oracle非常规恢复

一直以来,类似非归档无备份的数据库损坏,或者备份不可用,或者用备份恢复因为时间太长或者空间限制等等原因制约,非常规恢复一直是我们不能扔掉的救命稻草,在这个方面我并不擅长,但是一直都很喜欢。 记得2001年前后,我第一次有兴趣想要认真学习一下Oracle(以前做开发相关比较多,菜鸟dba),在还没有了解Oracle备份恢复的机制时,忘记为什么首先接触了Oracle 817的Standby,一周内完整的读了一遍文档,动手搭建了两个,并记录在ITPUB和我自己的blog上,很有成就感,而那时,我还没有意识到,其实Standby 的本质就是数据库的备份和恢复的完美结合。 后来有机会作为dba参加一个公司(在当时没觉得公司小,但是只有我一个菜鸟dba,O(∩_∩)O哈哈~)的一个海外项目,是做一个3节点Oracle 817 OPS 克隆数据库的事情,当时我还不熟悉RMAN,使用dd裸设备的方式完成了任务。这个项目之后,我开始迷上Oracle的备份和恢复,并且开始玩rman了。 迄今为止,我还是认为数据库备份恢复是学习Oracle的最佳入口,因为很多时候你可以方便的模拟场景,并研究恢复,在一个个案例中,学习和了解更多internal的原理。当然,任何时候官方文档都是第一步,没有这个基础,很多都如同空中楼阁。 还有一点,一个好的架构设计、备份恢复策略和灾备设计都是最好的选择,这个是毋庸置疑的。 但是中国大量D版客户,尤其是小客户中太多情况下是没有专业的设计,出了问题,非常规恢复的手段就是救命稻草了。 下面的ppt就是去年一个客户在备份不可用的情况下,花“巨资”请人做了非常规恢复后,找我们去做的一次交流,客户要求的主题就是“非常规恢复”: 浅谈Oracle非常规恢复-lunar

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

艰难的修复数据库过程,却发现Oracle 11.2果然强大

具体参见: http://t.askmaclean.com/thread-3790-1-1.html http://www.itpub.net/thread-1839128-1-1.html 纯属自娱自乐,没有实际意义的,顺便说下我的发现和测试中的发现(虽然到现在为止数据库还没有open,我还会继续鼓捣他,毕竟还有些方法还没用上,O(∩_∩)O哈哈~。。。); 首先就是11.2太强大了,很多时候以往的错误都可以fixed,数据库可以open后,做很多跟损坏先关的check 1, 从11.2开始,控制文件自动备份完成的信息由m000完成,且他还完成很多其余工作,当然,只在别的进程触发的时候,他才会去工作 2,DBA_TABLESPACE和V$TABLESPACE的来源不同,一个来源于控制文件,一个来源于基表ts$ 3,ts$和file$不能跳号 4,DBMS_HM很强大(Health Manager),他会定期检查数据库的很多东西,然后让m000进程写trace 。。。 主要的测试步骤已经不太都记得了,但是主要模拟步骤如下: 我的环境: db 11.2.0.3 OEL 5.8 1,创建2个表空间(其实1个也可以,几个都行,为了看得更加清晰),然后切换日志,然后在OS上讲包括UNDOTBS在内的这些数据文件(普通的数据文件和undo的数据文件就可以) 2,启动数据库的时候,你会发现,报错说文件丢失或者损坏,这时你offline drop掉这个报错的文件,数据库应该就可以打开,当然后台有m000生成的trace,HealthManager会不断的触发m000把所有其余随坏的信息都写入trace 3,想办法清理undo$中的问题回滚段 4,创建新的普通数据的表空间,例如“UNDTBS333”,但是设置UNDO_TABLESPACE=这个普通的表空间(scope=spfile),然后启动数据库————–这时我当时的第一个误操作 5,数据库报错,具体忘记了,怎么解决的也忘记了,印象中无非就是undo的隐含参数等等,然后创建正确的undo表空间(create undo tablespace …)给数据库使用 6,解决后,数据库可以正常open,delete from fs$ where name=‘你曾经误操作的那个普通数据表空间 UNDTBS333’,这么做是因为当时我没有仔细考虑风险,因此,手工清理了 其实如果全部都是手工做的话,也可以的,后面发现了需要手工清理什么,但是当时确实么有想太多,误操作了。。。 7,其实这样数据库也还是可以open的,没有太大问题,我用DBMS_HM.RUN_CHECK(‘Dictionary Integrity Check’, ‘lunar-ck-Dict’)检查,其实这时数据库只有undo$, ts$ 和file$数据不一致,没有影响其他数据对象(因为测试过程没有添加用户测试数据) … 继续阅读

发表在 backup&recovery, Internal, Oracle 11.1 & Oracle11.2 | 标签为 , | 留下评论

模拟ORA-600 [4000] 并修复

我没有测试,但是我感觉,从一个好的库上直接dd一个file 1 block 520,可能也可以的,O(∩_∩)O哈哈~ 我这里使用了bbed去修改文件,生产库请勿效仿,后果自负 :) 模拟ORA-600 [4000]: 查看alert: 查看trace: trace中其他有用的信息如下: 摘要上面的信息,有用的如下: 下面清除锁标识: 成功打开数据库:

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