姿姿霸霸~~!
贵在坚持!
posts - 106,  comments - 50,  trackbacks - 0
这两天遇到客户因为误操作,将RAC环境下的所有共享存储格式化掉了,客户只有一个最近的RMAN的0级全备(无数据文件,无控制文件,无归档日志,无redo日志),需要帮忙恢复。将大致的恢复过程记录一下。

0.恢复共享存储是第一步,给存储原厂打电话,原厂推是os的问题,让给os打电话,结果只能初始化了,最后只能恢复到被识别的状态,一切从头开始。

1.因为集群软件是装在本地的,所以恢复rac的集群环境,只需要将ocr和vdisk重新配置一下,就可以了。可以执行root.sh脚本来进行重新的配置,如果中间报一个已经被配置过的提示,那就先用dd清除ocr和vdisk的信息,并删除相应的目录文件,如下:
rm -rf /usr/tmp/.oracle /var/tmp/.oracle /tmp/.oracle /etc/oracle/* /var/opt/oracle/*  
rm -rf /etc/init.cssd /etc/init.crs* /etc/init.evmd /etc/init.d/init.cssd /etc/init.d/init.crs  
rm -rf /etc/init.d/init.crsd /etc/init.d/init.evmd /etc/rc3.d/K96init.crs /etc/rc3.d/S96init.crs  
rm -rf /etc/rc.d/rc2.d/K96init.crs /etc/rc.d/rc2.d/S96init.crs

2.恢复完集群环境之后,开始恢复数据库。因为询问到客户有去年年底的一个RMAN的0级全备,以及控制文件的快照没有放到共享存储上,故可以采用重建控制文件+restore备份的方法来恢复。中途遇到很多问题,因为所有的日志备份均放到共享存储下的,故这次恢复在recover的步骤时是没有日志用来补充的。所以restore databse until 时间后,再recover,再alter database open resetlogs后,会报一个需要恢复数据文件的错误提示,操作的时候运气不好,刚好遇到的是需要恢复datafile 1,再折腾了几个小时候,终于发现按照正常的手段是行不通的.

3.因为没有日志,无法使得数据库达到一致性,所以只有采取修改隐藏参数的办法来忽略数据库的不一致,来强行打开数据库.先将数据库打到mount状态,在做完restore,recover之后,将隐藏参数修改 alter system set "_allow_resetlogs_corruption"=true scope=spfile;再shutdown数据库,启动到mount状态之后,alter database open resetlogs; resetlogs打开数据库后,运气仍然不是太好,又遇到了ORA-00600 2662号的错误.

4. 当使用修改_allow_resetlogs_corruption ,再打开数据库时遇到了ORA-00600 2662号的错误, 如果SCN相差不多,可以通过多次重起数据库解决 ,但是这次遇到的SCN相差很大(通过查v$datafile和v$datafile_header的CHECKPOINT_CHANGE#来判断),这个时候只有再修改另外一个隐藏参数 _minimum_giga_scn来解决问题._minimum_giga_scn的作用是推进SCN号,该参数值的单位是billion,也就是说设置了该参数后,SCN号会变成XX* (1024*1024*1024) ,XX可以通过2662的几个参数来确定. 2662后的参数[2662],[a],[b],[c],[d],[e]…[a] Current SCN WRAP,[b] Current SCN BASE,[c] dependent SCN WRAP,[d] dependent SCN BASE,[e] Where present this is the DBA where the dependent SCN came from.

5.当修改了2个隐藏参数之后,数据库终于能启动了,但是alert日志还是会报一些600的错误,暂时忽略.用exp(expdp可能会报错)将数据全部导出,重建新的实例,再用imp导入数据到新的库中.exp的时候需要注意一个参数compress,这个参数可以降低HWM,使的imp的时候,时间相对尽量少一些.
posted @ 2012-04-12 00:24 xrzp 阅读(380) | 评论 (0)编辑 收藏
早上做个实验,update数据的时候报错ora-30036:无法按8扩展段(在还原表空间‘undotbs_new’中)

1.查询了一下undo表空间的使用,发现已经超过了80%
SELECT a.tablespace_name as tablespace_name,
       to_char(b.total
/1024/1024,999999.99as Total,
       to_char((b.total
-a.free)/1024/1024,999999.99as Used,
       to_char(a.free
/1024/1024,999999.99as Free,
       to_char(
round((total-free)/total,4)*100,999.99as Used_Rate
FROM (SELECT tablespace_name, sum(bytes) free FROM DBA_FREE_SPACE GROUP BY tablespace_name) a,
     (
SELECT tablespace_name, sum(bytes) total FROM DBA_DATA_FILES GROUP BY tablespace_name ) b
WHERE a.tablespace_name=b.tablespace_name
  
AND a.tablespace_name='UNDOTBS_NEW'
ORDER BY a.tablespace_name;

2.将undo表空间大小重新加大点,解决问题~
alter database datafile 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\SUREDD\UNTOTBS_NEW_01.DBF' resize 2048M;
posted @ 2011-11-07 10:30 xrzp 阅读(17990) | 评论 (0)编辑 收藏
v$sqltext:存储的是完整的SQL,SQL被分割
v$sqlarea:存储的SQL 和一些相关的信息,比如累计的执行次数,逻辑读,物理读等统计信息.v$sqlarea 忽略了执行计划等差异,只是在形式上sql文本看起来一样.相当于做了个聚合,是多个不同执行计划的sql的聚合和累计信息 
v$sql:存储的是具体的SQL 和执行计划相关信息,v$sqlarea 可以看做 v$sql 根据 sqltext 等 做了 group by 之后的信息
v$sql_plan:代表了具体的sql的执行计划,通过下面3个字段做连接(与v$sql)
ADDRESS RAW(4),HASH_VALUE NUMBER,CHILD_NUMBER NUMBER
posted @ 2011-11-07 00:00 xrzp 阅读(334) | 评论 (0)编辑 收藏

<2011年11月>
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

常用链接

留言簿(4)

随笔分类

随笔档案

好友的blog

搜索

  •  

积分与排名

  • 积分 - 115106
  • 排名 - 505

最新评论

阅读排行榜

评论排行榜