某客户给sysaux表空间添加了数据文件，但有在操作系统层rm删除了数据文件，更悲催的的是之前归档所在的磁盘损坏，恢复所需要的归档那是没指望了，也一年多没进行
某客户给sysaux表空间添加了数据文件，但有在操作系统层rm 删除了数据文件，更悲催的的是之前归档所在的磁盘损坏，恢复所需要的归档那是没指望了，也一年多没进行过数据库备份了，
现记录恢复过程如下：（虚拟机上重新模拟该恢复过程）
1 数据文件状态如下
SQL> select file#,name,status from v$datafile;
FILE# NAME STATUS
———- —————————————- ——-
1 /oracle/CRM/ZBCRM/system01.dbf SYSTEM
2 /oracle/CRM/ZBCRM/sysaux01.dbf ONLINE
3 /oracle/CRM/ZBCRM/undotbs01.dbf ONLINE
4 /oracle/CRM/ZBCRM/users01.dbf ONLINE
5 /oracle/CRM/ZBCRM/sysaux02.dbf RECOVER
话袋AI笔记
话袋AI笔记, 像聊天一样随时随地记录每一个想法，打造属于你的个人知识库，成为你的外挂大脑
47 查看详情 
2 重新生成操作系统层删除的数据文件
SQL> alter database create datafile ‘/oracle/CRM/ZBCRM/sysaux02.dbf’;
Database altered.
注意，香港服务器，当我们用 alter database create datafile 创建数据文件时，数据文件头部scn以及rba.seq号均取自于该数据文件创建时控制文件中记录的scn和rba.seq号.
3 此刻数据文件头部信息如下：
SQL> select hxfil,fhscn,fhrba_seq from x$kcvfh;
HXFIL FHSCN FHRBA_SEQ
———- —————- ———-
1 1047892 18
2 1047892 18
3 1047892 18
4 1047892 18
5 1026926 1
这里可以明确看出5号数据文件恢复需要从seq号为1的归档开始恢复，香港空间，但实际上seq#=1及其之后的归档已经不存在了，虚拟主机，所以如下恢复失败：
SQL> recover datafile 5;
ORA-00283: recovery session canceled due to errors
ORA-01110: data file 5: ‘/oracle/CRM/ZBCRM/sysaux02.dbf’
ORA-01157: cannot identify/lock data file 5 – see DBWR trace file
ORA-01110: data file 5: ‘/oracle/CRM/ZBCRM/sysaux02.dbf’
4 用bbed调整5号数据文件如下几个偏移量
ub4 kcvfhcpc @140 ——检查点计数
ub4 kcvfhccc @148 ——总是比检查点计数少1
ub4 kcvcptim @492 ——检查点时间
ub4 kscnbas @484 ——scn的低位
ub2 kscnwrp @488 ——scn的高位
[oracle@oracle ~]$ bbed parfile=bbed.par
Password:
BBED: Release 2.0.0.0.0 – Limited Production on Thu Jul 25 14:26:45 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
************* !!! For Oracle Internal Use only !!! ***************
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/530089.html
微信扫一扫 
支付宝扫一扫 
