使用BBED跳过归档进行恢复

最新推荐文章于 2021-04-06 11:26:00 发布
最新推荐文章于 2021-04-06 11:26:00 发布
阅读量1k 收藏
点赞数
分类专栏： Oracle-Backup/Recovery
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/gumengkai/article/details/53311390
版权

数据库启动异常，提示6号文件丢失

SQL> startup
ORACLE instance started.

Total System Global Area  776646656 bytes
Fixed Size                  2257272 bytes
Variable Size             490737288 bytes
Database Buffers          281018368 bytes
Redo Buffers                2633728 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: '/u01/app/oracle/oradata/orcl/t01.dbf'

分析过程：

1. 查看告警日志和trace

[oracle@centos6 trace]$ pwd
/u01/app/oracle/diag/rdbms/orcl/orcl/trace
[oracle@centos6 trace]$ cat alert_orcl.log
日志内容如下： 

ALTER DATABASE OPEN
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_dbw0_3020.trc:
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: '/u01/app/oracle/oradata/orcl/t01.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_3042.trc:
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: '/u01/app/oracle/oradata/orcl/t01.dbf'
ORA-1157 signalled during: ALTER DATABASE OPEN...
根据告警日志中的信息查看trace文件 

SQL> select * from v$diag_info;
[oracle@centos6 ~]$ vim /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_3042.trc
trace内容： 

DDE: Problem Key 'ORA 1110' was flood controlled (0x1) (no incident)
ORA-01110: data file 6: '/u01/app/oracle/oradata/orcl/t01.dbf'
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: '/u01/app/oracle/oradata/orcl/t01.dbf'
基本可以确认，是6号文件丢失

2. 使用rman还原6号文件

--查看数据库状态

RMAN> report schema;
using target database control file instead of recovery catalog
Report of database schema for database with db_unique_name ORCL
List of Permanent Datafiles
===========================
File Size(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1    760      SYSTEM               ***     /u01/app/oracle/oradata/orcl/system01.dbf
2    590      SYSAUX               ***     /u01/app/oracle/oradata/orcl/sysaux01.dbf
3    105      UNDOTBS1             ***     /u01/app/oracle/oradata/orcl/undotbs01.dbf
4    5        USERS                ***     /u01/app/oracle/oradata/orcl/users01.dbf
5    330      EXAMPLE              ***     /u01/app/oracle/oradata/orcl/example01.dbf
6    0        T                    ***     /u01/app/oracle/oradata/orcl/t01.dbf
7    100      TBS1                 ***     /u01/app/oracle/oradata/orcl/tbs_1.dbf
8    100      TBS2                 ***     /u01/app/oracle/oradata/orcl/tbs2.dbf
9    1        UNDO1                ***     /u01/app/oracle/oradata/orcl/undo01.dbf
List of Temporary Files
=======================
File Size(MB) Tablespace           Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1    29       TEMP                 32767       /u01/app/oracle/oradata/orcl/temp01.dbf

6号文件大小为0，说明该数据文件已经丢失。

--restore还原6号文件

RMAN> restore datafile 6;
Starting restore at 20-NOV-16
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=21 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00006 to /u01/app/oracle/oradata/orcl/t01.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/fast_recovery_area/ORCL/backupset/2016_10_23/o1_mf_nnndf_TAG20161023T102912_d0r83s29_.bkp
channel ORA_DISK_1: piece handle=/u01/app/oracle/fast_recovery_area/ORCL/backupset/2016_10_23/o1_mf_nnndf_TAG20161023T102912_d0r83s29_.bkp tag=TAG20161023T102912
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 20-NOV-16

3. 尝试打开数据库

SQL> select status from v$instance;
STATUS
------------
MOUNTED
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 6 needs media recovery
ORA-01110: data file 6: '/u01/app/oracle/oradata/orcl/t01.dbf'
提示需要介质恢复

4. 查看数据文件头部和控制文件记录的检查点信息

控制文件：

SQL> select FILE#,CHECKPOINT_CHANGE# from v$datafile;

     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1            2190210
         2            2190210
         3            2190210
         4            2190210
         5            2190210
         6            2190210
         7            2190210
         8            2190210
         9            2190210

9 rows selected. #可见控制文件中记录的检查点信息是一致的

数据文件头部：

SQL> select FILE# ,CHECKPOINT_CHANGE# from v$datafile_header;

     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1            2190210
         2            2190210
         3            2190210
         4            2190210
         5            2190210
         6            1301034  #此时oracle会取读6号文件1号块的信息
         7            2190210
         8            2190210
         9            2190210

9 rows selected.

对比控制文件记录的检查点信息和数据文件头部的检查点信息，看两者是否一致。

数据文件头部的scn要比控制文件记录的scn要小，所以要利用归档日志应用日志将数据文件恢复到2190210这个时间点。

5. 使用recover命令恢复6号文件

SQL> recover datafile 6;
ORA-00279: change 1301034 generated at 10/23/2016 10:29:13 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/ORCL/archivelog/2016_10_23/o1_mf_1_4_d0rb9tqo
_.arc
ORA-00280: change 1301034 for thread 1 is in sequence #4


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
提示要应用o1_mf_1_4_d0rb9tqo_.arc从1301034进行恢复

6号文件头部记录了检查点信息，包括时间(scn)和RBA，即日志地址，之前的日志就不需要再进行恢复。

--回车进行自动恢复 1322797

ORA-00279: change 1322797 generated at 10/23/2016 11:06:34 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/ORCL/archivelog/2016_10_24/o1_mf_1_5_d0vhzoyw
_.arc
ORA-00280: change 1322797 for thread 1 is in sequence #5


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

检查点信息已经到了1322797，还是要比控制文件记录的要小。再从1322797应用归档进行恢复。

--1344052
ORA-00279: change 1344052 generated at 10/24/2016 16:01:57 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/ORCL/archivelog/2016_10_24/o1_mf_1_6_d0vj3ffm
_.arc
ORA-00280: change 1344052 for thread 1 is in sequence #6


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

以下重复内容不再贴出来..

--恢复异常，25号归档日志文件丢失

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 1928225 generated at 11/13/2016 11:30:53 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/ORCL/archivelog/2016_11_13/o1_mf_1_25_d2htrdn
9_.arc
ORA-00280: change 1928225 for thread 1 is in sequence #25

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00308: cannot open archived log
'/u01/app/oracle/fast_recovery_area/ORCL/archivelog/2016_11_13/o1_mf_1_25_d2htrd
n9_.arc'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

6. 到指定目录下查看归档日志是否还在

[oracle@centos6 2016_11_13]$ ls
o1_mf_1_23_d2hqlxhy_.arc      o1_mf_1_26_d2hwpw1f_.arc
o1_mf_1_24_d2hqmflr_.arc      o1_mf_1_27_d2jcddcq_.arc

的确是缺少了25号归档日志文件

--再看此时数据文件头部的scn

SQL> select FILE# ,CHECKPOINT_CHANGE# from v$datafile_header;

     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1            2190210
         2            2190210
         3            2190210
         4            2190210
         5            2190210
         6            1928225
         7            2190210
         8            2190210
         9            2190210

9 rows selected.

还没有恢复到异常发生前的scn，如果此时直接打开数据库，后面的归档日志记录的信息就丢失了。

7. 修改数据文件头部的检查点信息，以跳过25号归档日志。将检查点信息指向26号日志。

--修改RBA，SCN

RBA(redo byte addres) à sequence number+block number+offset 61è62

SCN(system change number) 使数据文件头部的SCN从61号日志的开始SCN指向62号日志的开始SCN

8. 使用BBED修改6号文件头部的RBA，6号文件1号块

注：oracle11g offset 500-->RBA offset 484-->SCN

BBED> set file 6
        FILE#           6

BBED> map /v     --dump出1号块的结构
 File: /u01/app/oracle/oradata/orcl/t01.dbf (6)
 Block: 1                                     Dba:0x01800001
------------------------------------------------------------
 Data File Header

 struct kcvfh, 860 bytes                    @0       
    struct kcvfhbfh, 20 bytes               @0       
    struct kcvfhhdr, 76 bytes               @20      
    ub4 kcvfhrdb                            @96      
    struct kcvfhcrs, 8 bytes                @100     
    ub4 kcvfhcrt                            @108     
    ub4 kcvfhrlc                            @112     
    struct kcvfhrls, 8 bytes                @116     
    ub4 kcvfhbti                            @124     
    struct kcvfhbsc, 8 bytes                @128     
    ub2 kcvfhbth                            @136     
    ub2 kcvfhsta                            @138     
    struct kcvfhckp, 36 bytes               @484     
    ub4 kcvfhcpc                            @140     
    ub4 kcvfhrts                            @144     
    ub4 kcvfhccc                            @148     
    struct kcvfhbcp, 36 bytes               @152     
    ub4 kcvfhbhz                            @312     
    struct kcvfhxcd, 16 bytes               @316     
    sword kcvfhtsn                          @332     
    ub2 kcvfhtln                            @336     
    text kcvfhtnm[30]                       @338     
    ub4 kcvfhrfn                            @368     
    struct kcvfhrfs, 8 bytes                @372     
    ub4 kcvfhrft                            @380     
    struct kcvfhafs, 8 bytes                @384     
    ub4 kcvfhbbc                            @392     
    ub4 kcvfhncb                            @396     
    ub4 kcvfhmcb                            @400     
    ub4 kcvfhlcb                            @404     
    ub4 kcvfhbcs                            @408     
    ub2 kcvfhofb                            @412     
    ub2 kcvfhnfb                            @414     
    ub4 kcvfhprc                            @416     
    struct kcvfhprs, 8 bytes                @420     
    struct kcvfhprfs, 8 bytes               @428     
    ub4 kcvfhtrt                            @444     

 ub4 tailchk                                @8188   
 
BBED> p kcvfhckp   --484号检查点的结构
struct kcvfhckp, 36 bytes                   @484     
   struct kcvcpscn, 8 bytes                 @484     
      ub4 kscnbas                           @484      0x001d6c21 –低位4个字节
      ub2 kscnwrp                           @488      0x0000    --高位两个字节
   ub4 kcvcptim                             @492      0x374d2ced
   ub2 kcvcpthr                             @496      0x0001
   union u, 12 bytes                        @500     
      struct kcvcprba, 12 bytes             @500     
         ub4 kcrbaseq                       @500      0x00000019
         ub4 kcrbabno                       @504      0x00000002
         ub2 kcrbabof                       @508      0x0000
   ub1 kcvcpetb[0]                          @512      0x02
   ub1 kcvcpetb[1]                          @513      0x00
   ub1 kcvcpetb[2]                          @514      0x00
   ub1 kcvcpetb[3]                          @515      0x00
   ub1 kcvcpetb[4]                          @516      0x00
   ub1 kcvcpetb[5]                          @517      0x00
   ub1 kcvcpetb[6]                          @518      0x00
   ub1 kcvcpetb[7]                          @519      0x00


SQL> select to_number('19','xx') fromdual;  --25号文件
TO_NUMBER('19','XX')
--------------------
                  25

也就是从25号文件，2号块，偏移量为0的位置开始恢复。

只需要把25改为26即可，02不需修改，因为日志文件的第一个块是文件头，也就是从2号文件开始写日志的，恢复的时候也是从2号块开始恢复。

将19改为1a 
BBED> d /v offset 500 count 16
 File: /u01/app/oracle/oradata/orcl/t01.dbf (6)
 Block: 1       Offsets:  500 to  515  Dba:0x01800001
-------------------------------------------------------
 19000000 02000000 00009f98 02000000 l ................

BBED> modify /x 1a offset 500
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
 File: /u01/app/oracle/oradata/orcl/t01.dbf (6)
 Block: 1                Offsets:  500 to  515           Dba:0x01800001
------------------------------------------------------------------------
 1a000000 02000000 00009f98 02000000 

 <32 bytes per line>
BBED> sum apply
Check value for File 6, Block 1:
current = 0xea80, required = 0xea80

9. 修改SCN 6号文件1号块

 struct kcvcpscn, 8 bytes                 @484     
      ub4 kscnbas                           @484      0x001d6c21 #低位4个字节
      ub2 kscnwrp                           @488      0x0000     #高位2个字节

接下来要推测26号日志开始的SCN，可以从控制文件中记录的V$LOG_HISTORY查看

SQL> select SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE# from v$log_history;
SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ------------- ------------
        20       1700044      1721365
        21       1721365      1754090
        22       1754090      1791173
        23       1791173      1829681
        24       1829681      1928225
        25       1928225      2023273
        26       2023273      2046588

这样就可以去确定，将1028225改为2023273

1D6C21(21 6c 1d)---》à1edf69(69df 1e)  #此时可以用计算器转换，因为数据库未打开，不能使用函数转换

通过将6号文件头部的SCN转换也可以验证这一点。

SQL> select to_number('1d6c21','xxxxxx') from dual;

TO_NUMBER('1D6C21','XXXXXX')
----------------------------
                     1928225

BBED> d /v offset 484 count 16
 File: /u01/app/oracle/oradata/orcl/t01.dbf (6)
 Block: 1       Offsets:  484 to  499  Dba:0x01800001
-------------------------------------------------------
 216c1d00 00000000 ed2c4d37 01000000 l !l......?M7....

 <16 bytes per line>

注意，因为这里linux使用的是小端，number类型为倒置存储

BBED> modify  /x 69 offset 484
 File: /u01/app/oracle/oradata/orcl/t01.dbf (6)
 Block: 1                Offsets:  484 to  499           Dba:0x01800001
------------------------------------------------------------------------
 696c1d00 00000000 ed2c4d37 01000000 

 <32 bytes per line>

BBED> modify /x df offset 485
 File: /u01/app/oracle/oradata/orcl/t01.dbf (6)
 Block: 1                Offsets:  485 to  500           Dba:0x01800001
------------------------------------------------------------------------
 df1d0000 000000ed 2c4d3701 0000001a 

 <32 bytes per line>

BBED> modify /x 1e offset 486
 File: /u01/app/oracle/oradata/orcl/t01.dbf (6)
 Block: 1                Offsets:  486 to  501           Dba:0x01800001
------------------------------------------------------------------------
 1e000000 0000ed2c 4d370100 00001a00 

 <32 bytes per line>

BBED> sum apply;
Check value for File 6, Block 1:
current = 0x59cb, required = 0x59cb

10. 恢复6号文件，看是否能够恢复

SQL> recover datafile 6  
ORA-00279: change 2023273 generated at 11/13/2016 11:30:53 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/ORCL/archivelog/2016_11_13/o1_mf_1_26_d2hwpw1
f_.arc
ORA-00280: change 2023273 for thread 1 is in sequence #26


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
可以看到此时已经从26号日志开始恢复了 

SQL> recover datafile 6 
ORA-00279: change 2096676 generated at 11/16/2016 18:54:49 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/ORCL/archivelog/2016_11_19/o1_mf_1_29_d2zk84c
z_.arc
ORA-00280: change 2096676 for thread 1 is in sequence #29


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

Log applied.
Media recovery complete.
SQL> alter database open;

Database altered.
数据库可以打开了。此时最好尽快做一个全库备份


附上模拟故障的脚本：

1.	移除数据文件 t01.dbf
[oracle@centos6 orcl]$ ls
control01.ctl  redo01.log  redo03.log    system01.dbf  tbs_1.dbf  temp01.dbf  undotbs01.dbf
example01.dbf  redo02.log  sysaux01.dbf  t01.dbf       tbs2.dbf   undo01.dbf  users01.dbf
[oracle@centos6 orcl]$ mkdir bak
[oracle@centos6 orcl]$ mv t01.dbf bak/t01.dbf
2.	查看最近的备份文件
RMAN> list backup of database;
using target database control file instead of recovery catalog
List of Backup Sets
===================
BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
4       Full    1.12G      DISK        00:00:19     23-OCT-16      
        BP Key: 4   Status: AVAILABLE  Compressed: NO  Tag: TAG20161023T102912
        Piece Name: /u01/app/oracle/fast_recovery_area/ORCL/backupset/2016_10_23/o1_mf_nnndf_TAG20161023T102912_d0r83s29_.bkp
  List of Datafiles in backup set 4
  File LV Type Ckp SCN    Ckp Time  Name
  ---- -- ---- ---------- --------- ----
  1       Full 1301034    23-OCT-16 /u01/app/oracle/oradata/orcl/system01.dbf
  2       Full 1301034    23-OCT-16 /u01/app/oracle/oradata/orcl/sysaux01.dbf
  3       Full 1301034    23-OCT-16 /u01/app/oracle/oradata/orcl/undotbs01.dbf
  4       Full 1301034    23-OCT-16 /u01/app/oracle/oradata/orcl/users01.dbf
  5       Full 1301034    23-OCT-16 /u01/app/oracle/oradata/orcl/example01.dbf
  6       Full 1301034    23-OCT-16 /u01/app/oracle/oradata/orcl/t01.dbf
最新的备份为10月26号
3.	查看归档日志
[oracle@centos6 ~]$ cd /u01/app/oracle/fast_recovery_area/ORCL/archivelog
[oracle@centos6 archivelog]$ ls
2016_10_16  2016_10_24  2016_11_01  2016_11_03  2016_11_06  2016_11_12  2016_11_16  2016_11_20
2016_10_23  2016_10_29  2016_11_02  2016_11_05  2016_11_09  2016_11_13  2016_11_19
4.	移除2016_11_13的其中一个归档日志文件
[oracle@centos6 archivelog]$ cd 2016_11_13
[oracle@centos6 2016_11_13]$ ls
o1_mf_1_23_d2hqlxhy_.arc  o1_mf_1_25_d2htrdn9_.arc  o1_mf_1_27_d2jcddcq_.arc
o1_mf_1_24_d2hqmflr_.arc  o1_mf_1_26_d2hwpw1f_.arc
[oracle@centos6 2016_11_13]$ mv o1_mf_1_25_d2htrdn9_.arc o1_mf_1_25_d2htrdn9_.arc.bak
5.	关闭数据库，重新打开
SQL> startup
ORACLE instance started.

Total System Global Area  776646656 bytes
Fixed Size                  2257272 bytes
Variable Size             490737288 bytes
Database Buffers          281018368 bytes
Redo Buffers                2633728 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: '/u01/app/oracle/oradata/orcl/t01.dbf'



bitko
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
非常规恢复使用BBED跳过归档
12-17
非常规恢复使用BBED跳过归档
ORA-01111 ORA-01110 ORA-01157 in a physical standby database
Hehuyi_In的博客
04-23 1585
在主库添加数据文件后，主从同步突然中断，从库alter日志出现以下报错： ORA-10879: error signaled in parallel recovery slave ORA-00283: recovery session canceled due to errors ORA-01111: name for data file 6 is unknown - rename to co...
oracle恢复主键丢失,数据库冷备恢复及各种Oracle相关文件丢失下的异常现象
weixin_39830175的博客
04-06 193
数据库冷备恢复及各种Oracle相关文件丢失下的异常现象一、我的数据库当前是“活”的，正常的，证明如下[root@ora11 ~]# su -oracle[oracle@ora11 ~]$ sqlplus / assysdbaSQL*Plus: Release 11.2.0.3.0Production on Sat Nov 16 16:55:36 2013Copyright (c) 1982, 2...
坏块处理一
anddyhua's Cookbook
05-16 1956
查看oracle日 使用dbv工具检验数据文件是否有坏块  dbv工具可以用来验证数据文件的有效性，在数据库恢复之前可以使用该命令对备份文件进行有效性检查， 防止因备份文件本身的问题导致数据库无法恢复。 当然，dbv命令也可以对在线的数据文件进行检查。 注意，dbv工具只可以对数据文件进行检查，无法使用它完成控制文件和日志文件的检查。 1.dbv命令语法 dbve
解决ORA-01111, ORA-01110, ORA-01157
木苒的博客
12-11 6313
在备用数据库中创建文件为UNNAMED或MISSING的原因有很多，包括备用站点上的磁盘空间不足（或）与文件管理相关的不正确的参数设置。 STANDBY_FILE_MANAGEMENT启用或禁用自动备用文件管理。启用自动备用文件管理后，将在备用数据库上复制主数据库上的操作系统文件添加和删除。 例如，如果我们在主服务器上将参数STANDBY_FILE_MANAGEMENT设置为MANUAL时在主...
oracle数据存储底层恢复,oracle数据文件的一次恢复经历
weixin_33795542的博客
04-04 213
环境介绍：双机操作系统：solaris 10数据库版本：oracle 11g R1 64bit1、半夜接到电话，说数据库报大量错误，起来查看数据库，发现数据库已崩溃，查看alert日志，发现I/O报错：Wed Dec 18 00:36:57 2013KCF: write/open error block=0x98abe online=1file=89 /dev/raw/raw03error=270...
bbed工具（三个包）+bbed安装使用方法，详细的案例恢复：oracle非归档数据库offline的数据文件恢复。做完后可掌握bbed及故障恢复。值得推荐。
08-10
bbed工具（三个包，用于linux服务器）+bbed安装使用方法，详细的案例恢复：oracle非归档数据库offline的数据文件恢复。做完后可掌握bbed及故障恢复。值得推荐。
Oracle恢复利器，bbed源码
11-17
oracle11g之后不集成bbed了，此源码是从oracle10g提取的，可以在oralce10g以后的版本中使用，内附有使用教程，可以通过oracle中dbf的block进行数据恢复
Oracle BBED详解以及强制online数据文件修复数据文件头恢复truncate.md
12-19
使用bbed强制online数据文件，修复system头损坏，找回truncate数据
Oracle 11g下编译使用BBED的方法教程
09-09
主要给大家介绍了在Oracle 11g下编译使用BBED的方法教程，文中详细介绍了关于拷贝缺失文件、编译BBED以及BBED使用测试的相关资料，通过示例代码介绍的非常详细，需要的朋友们下面来一起看看吧。
undo损坏故障恢复（二）ORA-01092,ORA-00604,ORA-01110
weixin_33968104的博客
09-02 242
undo 故障诊断与恢复（二） 今天是2013-09-01，目前困扰我将近一周的问题，终于解决了，我非常感谢帮助我的朋友，也非常感谢管我要钱然后替我解决问题的朋友（我没采用）。这更激发了我一定要解决这个问题的斗志。 我写这篇笔记，就是为了帮助那些遇到同样困难的朋友，我觉得‘闻道有先后，术业有专攻’，没有人是无法被取代的。如果有朋友搜到我这篇文章，希望我能给你带来问题的解决办法。 先描述一下，我模...
05 使用bbed跳过归档恢复数据文件
weixin_30262255的博客
05-22 101
5 使用BBED跳过归档 在归档模式下，缺失了一部分的归档日志文件，对数据文件进行恢复 1 开启归档 --shutdown immediate --startup mount --alter database archivelog --alter database open SYS@ orcl >archive log list; Database log mode ...
【Oracle】表空间误删除导致startup启动时提示ORA-01110和ORA-01157错误
cizhanliang7973的博客
12-10 375
今天遇到一个比较神奇的问题，客户某套测试数据库断电重启了，重启时发现数据库提示 ORA-01157:cannotidentify/lockdatafile和ORA-01110的错误，经过检查发现是系...
Oracle 之利用BBED跳过归档日志实现恢复（二）
雨花石
02-22 927
oracle bbed 修复 bbed 跳过归档日志恢复
BBED跳过归档恢复
ZXY之路
06-25 951
我们知道恢复的时候需要归档日志，假如我恢复的数据库需要10个归档日志，当恢复到5个的时候发现归档日志丢了，那么这种情况只能进行不完全恢复了，也就是说5号归档日志以后的数据都丢失了，但是其他的归档日志还是完好的，这样看来是不是有点“可惜了”，其实我们可以通过bbed跳过5号归档进行恢复，下面是实验步骤：   1.建立测试表，切换日志产生归档。 create">ZXY@zxy>create ta
Oracle 之利用BBED跳过归档日志实现恢复
02-22 552
版权声明：本文为博主原创文章，如果有不对的地方还请指正，欢迎加入Oracle 技术分享群：425614362 本次实验和之前做的实验：Oracle 之利用BBED修改数据块SCN----没有备份数据文件的数据恢复差不多，本次实验将删除归档进行恢复 http://blog.csdn.NET/shiyu1157758655/article/details/56286018 使用BBED跳过丢失的...
【Oracle】使用bbed恢复update的数据
badly9的专栏
06-19 1467
使用bbed不仅仅可以找回已经delete的数据还可以恢复update的数据，当然过程要比恢复delete的数据复杂一些。 实验过程如下： SYS@ORCL>create table bbed_test(x int,y varchar2(20));   Table created.   SYS@ORCL>insert into bbed_test values(1,'BADLY9');
oracle存储过程报错 跳过,【Oracle】使用BBED跳过丢失的归档
weixin_28723171的博客
04-02 399
在recover datafile的过程当中如果丢失了需要的归档将使得recover无法进行，使用bbed工具可以跳过丢失的归档进行recover datafile。实验过程如下：SYS@ORCL>select * from v$version;BANNER----------------------------------------------------------------Orac...
rac把数据文件创建在不共享的地方
yangxueyong218的专栏
05-06 1215
oracle 11g 11.2.0.1 linux server 64位 5.4     node1： 上创建一个数据文件'/tmp/rman.dbf' 这个文件没有放在共享磁盘上   然后创建一个表 casd ，并添加数据，此时在node1上能查询casd的信息   然后到node2查询的时候会提示如下错误： SQL> select * from casd; sele
windows oracle bbed
最新发布
09-25
在Windows上使用BBED需要进行以下步骤： 1. 安装Oracle客户端软件，并设置环境变量ORACLE_HOME和PATH。 2. 下载BBED工具，然后将其复制到ORACLE_HOME/bin目录下。 3. 打开命令行窗口，进入ORACLE_HOME/bin目录。 ...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值