标签归档：bbed

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

发表于 2015 年 1 月 29 日 由 Lunar

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

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

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

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

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

发表于 2014 年 11 月 28 日 由 Lunar

前几天有个朋友提出一个“老问题”，数据库上的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非常规恢复

发表于 2014 年 4 月 27 日 由 Lunar

一直以来，类似非归档无备份的数据库损坏，或者备份不可用，或者用备份恢复因为时间太长或者空间限制等等原因制约，非常规恢复一直是我们不能扔掉的救命稻草，在这个方面我并不擅长，但是一直都很喜欢。 记得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果然强大

发表于 2014 年 1 月 5 日 由 Lunar

具体参见: 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] 并修复

发表于 2013 年 10 月 29 日 由 Lunar

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

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