标签归档：gdb

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

艰难的修复数据库过程，却发现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 | 标签为 , | 留下评论