oracle rman丢失归档备份集的不完全恢复

最新推荐文章于 2024-01-25 20:51:53 发布
最新推荐文章于 2024-01-25 20:51:53 发布
阅读量1.6k 收藏 4
点赞数 1
分类专栏： Oracle 文章标签： oracle 数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/xingmuhai/article/details/125934879
版权

背景：只有rman备份出来的数据文件和控制文件，归档备份全部丢失。
1、原库DBID 
connected to target database: testdt (DBID=138268371)

RMAN 异机恢复的时候，db_name必须相同。 如果说要想改成其他的实例名，可以在恢复成功后，用nid命令修改。 实例名的信息会记录到

控制文件里，所以如果在恢复的时候，如果实例名不一致，恢复的时候会报错。
源环境的备份路径是/u01/backup/prod/data_bak
测试环境存放备份文件的路径是/rman_bak
/u01/app/oracle/data

2、测试环境

mkdir -p /u01/app/oracle/admin/testdt/adump
mkdir -p /u01/app/oracle/data/testdt
mkdir -p /u01/archivelog/prod
chown -R oracle:oinstall /u01/archivelog


提前做一个pfile
vi inittestdt.ora
testdt.__data_transfer_cache_size=0
testdt.__db_cache_size=3070230528
testdt.__inmemory_ext_roarea=0
testdt.__inmemory_ext_rwarea=0
testdt.__java_pool_size=16777216
testdt.__large_pool_size=33554432
testdt.__oracle_base='/u01/app/oracle'#ORACLE_BASE set from environment
testdt.__pga_aggregate_target=1358954496
testdt.__sga_target=4076863488
testdt.__shared_io_pool_size=201326592
testdt.__shared_pool_size=738197504
testdt.__streams_pool_size=0
*.audit_file_dest='/u01/app/oracle/admin/testdt/adump'
*.audit_trail='db'
*.compatible='12.2.0'
*.control_files='/u01/app/oracle/data/testdt/control01.ctl','/u01/app/oracle/data/testdt/control02.ctl'
*.db_block_size=8192
*.db_name='testdt'
*.diagnostic_dest='/u01/app/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=testdtXDB)'
*.log_archive_dest_1='location=/u01/archivelog/prod'
*.nls_language='AMERICAN'
*.nls_territory='AMERICA'
*.open_cursors=300
*.pga_aggregate_target=1292m
*.processes=320
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=3874m
*.undo_tablespace='UNDOTBS1'


export ORACLE_SID=testdt

rman target /

RMAN> startup nomount;

Oracle instance started

Total System Global Area    4076863488 bytes

Fixed Size                     8628304 bytes
Variable Size                922748848 bytes
Database Buffers            3137339392 bytes
Redo Buffers                   8146944 bytes

RMAN> restore controlfile from '/rman_bak/testdt_con_20220719_testdt_6.ctl';

Starting restore at 22-JUL-22
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=136 device type=DISK

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/u01/app/oracle/data/testdt/control01.ctl
output file name=/u01/app/oracle/data/testdt/control02.ctl
Finished restore at 22-JUL-22

RMAN> alter database mount;

Statement processed
released channel: ORA_DISK_1

RMAN> list backup of database;

List of Backup Sets
===================


BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
3       Full    541.66M    DISK        00:00:49     10-MAY-22      
        BP Key: 3   Status: AVAILABLE  Compressed: YES  Tag: TAG20220510T170349
        Piece Name: /u01/app/oracle/product/12.2.0/dbs/030t5orl_1_1
  List of Datafiles in backup set 3
  File LV Type Ckp SCN    Ckp Time  Abs Fuz SCN Sparse Name
  ---- -- ---- ---------- --------- ----------- ------ ----
  1       Full 2837389    10-MAY-22              NO    /u01/app/oracle/data/testdt/system01.dbf
  2       Full 2837389    10-MAY-22              NO    /u01/app/oracle/data/testdt_his_data.dbf
  3       Full 2837389    10-MAY-22              NO    /u01/app/oracle/data/testdt/sysaux01.dbf
  4       Full 2837389    10-MAY-22              NO    /u01/app/oracle/data/testdt/undotbs01.dbf
  5       Full 2837389    10-MAY-22              NO    /u01/app/oracle/data/testdt_data.dbf
  7       Full 2837389    10-MAY-22              NO    /u01/app/oracle/data/testdt/users01.dbf

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
5       Full    17.75G     DISK        00:22:13     19-JUL-22      
        BP Key: 5   Status: AVAILABLE  Compressed: YES  Tag: TAG20220719T100720
        Piece Name: /u01/backup/prod/data_bak/testdt_data_20220719_testdt_5_1.data
  List of Datafiles in backup set 5
  File LV Type Ckp SCN    Ckp Time  Abs Fuz SCN Sparse Name
  ---- -- ---- ---------- --------- ----------- ------ ----
  1       Full 234189095  19-JUL-22              NO    /u01/app/oracle/data/testdt/system01.dbf
  2       Full 234189095  19-JUL-22 234208555    NO    /u01/app/oracle/data/testdt_his_data.dbf
  3       Full 234189095  19-JUL-22              NO    /u01/app/oracle/data/testdt/sysaux01.dbf
  4       Full 234189095  19-JUL-22 234267006    NO    /u01/app/oracle/data/testdt/undotbs01.dbf
  5       Full 234189095  19-JUL-22 234262879    NO    /u01/app/oracle/data/testdt_data.dbf
  7       Full 234189095  19-JUL-22              NO    /u01/app/oracle/data/testdt/users01.dbf

RMAN> catalog start with '/rman_bak';  --指定新的备份集存放位置

searching for all files that match the pattern /rman_bak

List of Files Unknown to the Database
=====================================
File Name: /rman_bak/testdt_data_20220719_testdt_5_1.data
File Name: /rman_bak/testdt_con_20220719_testdt_6.ctl

Do you really want to catalog the above files (enter YES or NO)? YES
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: /rman_bak/testdt_data_20220719_testdt_5_1.data
File Name: /rman_bak/testdt_con_20220719_testdt_6.ctl


-----如果是路径不一致要用下面的脚本指定新路径---------------
vi restore.sh
rman nocatalog target / <<EOF
run
{
set newname for datafile 1 to "/app/u01/oradata/DTw2/system01.dbf";
set newname for datafile 2 to "/app/u01/oradata/DTw2/sysaux01.dbf";
set newname for datafile 3 to "/app/u01/oradata/DTw2/undotbs01.dbf";
set newname for datafile 4 to "/app/u01/oradata/DTw2/users01.dbf";
set newname for datafile 5 to "/app/u01/oradata/DTw2/example01.dbf";
restore database;
switch datafile all;
}
exit
EOF 
-----如果是路径相同直接恢复---------------


RMAN> restore database;

Starting restore at 22-JUL-22
using channel ORA_DISK_1

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 00001 to /u01/app/oracle/data/testdt/system01.dbf
channel ORA_DISK_1: restoring datafile 00002 to /u01/app/oracle/data/testdt_his_data.dbf
channel ORA_DISK_1: restoring datafile 00003 to /u01/app/oracle/data/testdt/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00004 to /u01/app/oracle/data/testdt/undotbs01.dbf
channel ORA_DISK_1: restoring datafile 00005 to /u01/app/oracle/data/testdt_data.dbf
channel ORA_DISK_1: restoring datafile 00007 to /u01/app/oracle/data/testdt/users01.dbf
channel ORA_DISK_1: reading from backup piece /u01/backup/prod/data_bak/testdt_data_20220719_testdt_5_1.data
channel ORA_DISK_1: errors found reading piece handle=/u01/backup/prod/data_bak/testdt_data_20220719_testdt_5_1.data
channel ORA_DISK_1: failover to piece handle=/rman_bak/testdt_data_20220719_testdt_5_1.data tag=TAG20220719T100720
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:31:36
Finished restore at 22-JUL-22

RMAN> recover database;

Starting recover at 22-JUL-22
using channel ORA_DISK_1

starting media recovery

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 07/22/2022 01:46:04
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of archived log for thread 1 with sequence 28293 and starting SCN of 234263405 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 28292 and starting SCN of 234255131 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 28291 and starting SCN of 234246397 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 28290 and starting SCN of 234237313 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 28289 and starting SCN of 234228911 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 28288 and starting SCN of 234220788 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 28287 and starting SCN of 234213744 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 28286 and starting SCN of 234205219 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 28285 and starting SCN of 234196736 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 28284 and starting SCN of 234189079 found to restore

RMAN> list backup of database;


List of Backup Sets
===================


BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
3       Full    541.66M    DISK        00:00:49     10-MAY-22      
        BP Key: 3   Status: AVAILABLE  Compressed: YES  Tag: TAG20220510T170349
        Piece Name: /u01/app/oracle/product/12.2.0/dbs/030t5orl_1_1
  List of Datafiles in backup set 3
  File LV Type Ckp SCN    Ckp Time  Abs Fuz SCN Sparse Name
  ---- -- ---- ---------- --------- ----------- ------ ----
  1       Full 2837389    10-MAY-22              NO    /u01/app/oracle/data/testdt/system01.dbf
  2       Full 2837389    10-MAY-22              NO    /u01/app/oracle/data/testdt_his_data.dbf
  3       Full 2837389    10-MAY-22              NO    /u01/app/oracle/data/testdt/sysaux01.dbf
  4       Full 2837389    10-MAY-22              NO    /u01/app/oracle/data/testdt/undotbs01.dbf
  5       Full 2837389    10-MAY-22              NO    /u01/app/oracle/data/testdt_data.dbf
  7       Full 2837389    10-MAY-22              NO    /u01/app/oracle/data/testdt/users01.dbf

BS Key  Type LV Size
------- ---- -- ----------
5       Full    17.75G
  List of Datafiles in backup set 5
  File LV Type Ckp SCN    Ckp Time  Abs Fuz SCN Sparse Name
  ---- -- ---- ---------- --------- ----------- ------ ----
  1       Full 234189095  19-JUL-22              NO    /u01/app/oracle/data/testdt/system01.dbf
  2       Full 234189095  19-JUL-22 234208555    NO    /u01/app/oracle/data/testdt_his_data.dbf
  3       Full 234189095  19-JUL-22              NO    /u01/app/oracle/data/testdt/sysaux01.dbf
  4       Full 234189095  19-JUL-22 234267006    NO    /u01/app/oracle/data/testdt/undotbs01.dbf
  5       Full 234189095  19-JUL-22 234262879    NO    /u01/app/oracle/data/testdt_data.dbf
  7       Full 234189095  19-JUL-22              NO    /u01/app/oracle/data/testdt/users01.dbf

  Backup Set Copy #1 of backup set 5
  Device Type Elapsed Time Completion Time Compressed Tag
  ----------- ------------ --------------- ---------- ---
  DISK        00:22:13     19-JUL-22       YES        TAG20220719T100720

    List of Backup Pieces for backup set 5 Copy #1
    BP Key  Pc# Status      Piece Name
    ------- --- ----------- ----------
    5       1   AVAILABLE   /u01/backup/prod/data_bak/testdt_data_20220719_testdt_5_1.data

  Backup Set Copy #2 of backup set 5
  Device Type Elapsed Time Completion Time Compressed Tag
  ----------- ------------ --------------- ---------- ---
  DISK        00:22:13     19-JUL-22       YES        TAG20220719T100720

    List of Backup Pieces for backup set 5 Copy #2
    BP Key  Pc# Status      Piece Name
    ------- --- ----------- ----------
    6       1   AVAILABLE   /rman_bak/testdt_data_20220719_testdt_5_1.data
    
上面看到备份集的SCN是234189095，因为归档备份丢失，所以只能恢复到这个SCN
RMAN> recover database until scn 234189095;

Starting recover at 22-JUL-22
using channel ORA_DISK_1

starting media recovery
Oracle Error: 
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 2 needs more recovery to be consistent
ORA-01110: data file 2: '/u01/app/oracle/data/testdt_his_data.dbf'

media recovery complete, elapsed time: 00:00:00

Finished recover at 22-JUL-22


RECOVER DATABASE  backupset  USING CONTROLFILE UNTIL CANCEL ;


RMAN> alter database open resetlogs;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of sql statement command at 07/22/2022 02:09:07
ORA-01194: file 2 needs more recovery to be consistent
ORA-01110: data file 2: '/u01/app/oracle/data/testdt_his_data.dbf'

关闭数据库
SQL> shutdown immediate;
ORA-01109: database not open


Database dismounted.
ORACLE instance shut down.

在init.ora中加入如下参数 
　　 _allow_resetlogs_corruption=TRUE

系统recover到这个文件后找不到下一次SCN，就会报这个错，这是正常的。
如不想出现这个错误的话，则需要用recover database until scn 1117236 来不完全恢复。
SET UNTIL SCN 234189079;
recover database until scn 234189095;


用open resetlogs打开数据库
RMAN> alter database open resetlogs;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00601: fatal error in recovery manager
RMAN-03004: fatal error during execution of command
ORA-01092: ORACLE instance terminated. Disconnection forced
RMAN-03002: failure of sql statement command at 07/22/2022 05:41:21
ORA-00603: ORACLE server session terminated by fatal error
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [kcbzib_kcrsds_1], [], [], [], [], [], [], [], [], [], [], []
Process ID: 24344
Session ID: 9 Serial number: 6740
ORACLE error from target database: 
ORA-03114: not connected to ORACLE

这里直接数据库宕机了

从sqlplus进入启动数据库
[oracle@oracle12c ~]$ sqlplus / as sysdba

SQL*Plus: Release 12.2.0.1.0 Production on Fri Jul 22 05:41:59 2022

Copyright (c) 1982, 2016, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area 4076863488 bytes
Fixed Size            8628304 bytes
Variable Size          922748848 bytes
Database Buffers     3137339392 bytes
Redo Buffers            8146944 bytes
Database mounted.
ORA-00603: ORACLE server session terminated by fatal error
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [4194], [79], [26], [], [], [], [],
[], [], [], [], []
Process ID: 24520
Session ID: 9 Serial number: 46450


查找Ora-600报错：
https://blog.51cto.com/lhrbest/2698447

4193：表示undo和redo不一致（Arg [a] Undo record seq number，Arg [b] Redo record seq number ）；
4194：表示也是undo和redo不一致（Arg [a] Maximum Undo record number in Undo block，Arg [b] Undo record number from Redo block）

故障解决：
1、修改inittestdt.ora 里面参数
undo_management= MANUAL
undo_tablespace= SYSTEM
顺便注释
#_allow_resetlogs_corruption=true

2、OPEN数据库
SQL> startup
ORACLE instance started.

Total System Global Area 4076863488 bytes
Fixed Size            8628304 bytes
Variable Size          922748848 bytes
Database Buffers     3137339392 bytes
Redo Buffers            8146944 bytes
Database mounted.
Database opened.
SQL> create spfile from pfile;
SQL> shutdown immediate;
SQL> startup;

4、删除当前undo空间，重建新的undo空间
TABLESPACE_NAME     TS_SIZE FREE_SPACE USAGE_SPACE USAGE_RATE
-------------------- ---------- ---------- ----------- ----------
TESTDT_HIS_DATA        7200        241.625        6958.375        96.64
SYSAUX                   2550           562.0625       1987.9375        77.96
UNDOTBS1            32767.9844    34.125      32733.8594         99.9
USERS                5              4             1                   20
TESTDT_DATA            25000        499.75        24500.25          98
SYSTEM                950         4.375         945.625            99.54


删除旧undo
SQL> drop tablespace undotbs1 including contents and datafiles;   
drop tablespace undotbs1 including contents and datafiles
*
ERROR at line 1:
ORA-01548: active rollback segment '_SYSSMU48_3977065699$' found, terminate dropping tablespace

添加隐藏参数：
*._offline_rollback_segments=('_SYSSMU48_3977065699$')

shutdown immediate
startup

drop tablespace undotbs1 including contents and datafiles;
SQL> drop tablespace undotbs1 including contents and datafiles;

Tablespace dropped.
新建undo
create undo tablespace undotbs1 datafile '/u01/app/oracle/data/testdt/undotbs01.dbf' size 5G autoextend off; 
SQL> create undo tablespace undotbs1 datafile '/u01/app/oracle/data/testdt/undotbs01.dbf' size 5G autoextend off; 

Tablespace created.

TABLESPACE_NAME     TS_SIZE FREE_SPACE USAGE_SPACE USAGE_RATE
-------------------- ---------- ---------- ----------- ----------
TESTDT_HIS_DATA       7200    241.625      6958.375        96.64
SYSAUX               2550    566.375        1983.625        77.79
UNDOTBS1           5120    5117.75        2.25              .04
USERS                  5          4          1                   20
TESTDT_DATA          25000     499.75        24500.25          98
SYSTEM                950      4.375         945.625            99.54
UNDOTBS001           5120    5117.75          2.25              .04


3、修改pfile参数
undo_management= AUTO
undo_tablespace= UNDOTBS1
注释掉隐藏参数
#*._offline_rollback_segments=('_SYSSMU48_3977065699$')

4、重新启动数据库
shutdown immediate
startup
成功启动数据库，且启动过程中alert日志无报错

----------------分割线-------------------------

参考文章：

https://blog.51cto.com/lhrbest/2698447
https://blog.csdn.net/weixin_36488954/article/details/116447082
 

冰蓝冰冷
关注
  • 1
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
rman中的不完整恢复
龙神add-走向数据架构师的路
08-05 1119
rman中的不完整恢复: 不完整恢复表示会丢失数据。通过还原所有数据文件将整个数据库回退，然后执行不完全恢复。不是应用自备 份后生成的所有重做，而是故意在某个点停止应用重做，生成一个不是最新的数据库版本， 自该点后做的所有工作丢失，执行不完整恢复只有两个原因：完整恢复不可行或是故意要丢失数据。     完整恢复将是不可能的，除非自备份后生成的所有归档日志以及联机重做日志可用。如果归档日志缺
rman恢复－不完全恢复
ruilin215
08-29 175
rman不完全恢复只适用于archivelog模式，只能在mount状态下完成。基于时间恢复 基于时间恢复是指当出现用户错误（例如误删除表、误截断表）时，恢复到指定时间点的恢复。 示例： 模拟误截断表t_user。 在终端设置环境变量nls_date_format指定日期时间格式。 执行rman,启动数据库到mount状态。 使用set until time命令指定要恢复到的时间点。转...
RMAN备份恢复之不完全恢复
weixin_30555515的博客
12-04 166
ORACLE不完全恢复 基于时间的不完全恢复 恢复要求：a、数据库开启归档切要有最近的有效rman全备。b、要有需要恢复到的准确时间点。 1、 做一个rman全备 RMAN>backup database; 2、 构建几个状态 在数据库里创建scott.t1并插入数据记录状态为a，记录时间t1。 在数据库里创建scott.t2并插入数据记录状态为b，记录时间t2。 进入数据库删除s...
RMAN基于表空间的不完全恢复（TSPITR)
weixin_34235105的博客
06-24 221
RMAN基于表空间的不完全恢复（TSPITR)表空间时间点恢复(TSPITR)：概念 通过执行TSPITR 可将一个或多个表空间快速恢复到以前的某个时间。 执行TSPITR 不会影响数据库中其它表空间或对象的状态。使用RMAN 自动表空间时间点恢复(TSPITR) 可将Oracle DB 中的一个或多个表空间快速恢复到以前的某个时间，而不会影响数据库中其它表空间和对象的状态。...
RMAN1：不完全恢复
weixin_47745154的博客
08-20 148
【场景一、不完全恢复】 阶段1：模拟基础数据 1.1 新建表空间和用户 create tablespace TBS_TEST1 datafile '+DATA/orcl/datafile/test1.dbf' size 100M; create user test1 identified by test1 default tablespace TBS_TEST1 quota unlimited on TBS_TEST1; grant connect,resource to test1; 1.2
oracle 11g rman 备份与恢复
09-29
Oracle 11g的RMAN（Recovery Manager）是Oracle数据库管理系统中不可或缺的一部分，它提供了全面的数据保护功能，包括数据库的备份、恢复、归档日志管理以及性能优化。本书《Oracle Database 11g RMAN备份与恢复》由...
Oracle Rman全能备份脚本 DBA必备
最新发布
06-02
同时，为了确保数据安全，应定期验证备份的完整性和可恢复性，通过RMAN的`validate`命令检查备份集是否有效。此外，配合Oracle的闪回技术，可以进一步提高恢复的灵活性和速度。 综上所述，这套“Oracle Rman全能...
Centos7.6下Oracle开启归档日志和Rman恢复.docx
03-06
要进行RMAN恢复，首先需要确保有有效的备份集。使用RMAN的`backup`命令创建备份，然后在需要恢复时，使用`restore`和`recover`命令。例如，恢复到特定时间点可能涉及使用`recover database until time`语句。 总的...
oracle RMAN 备份恢复总结
08-29
Oracle Recovery Manager（RMAN）是Oracle数据库管理系统中的一个重要组件，专为数据库的备份、恢复和维护设计。RMAN 自从Oracle 8版本开始引入，并在后续版本中不断加强和完善，尤其在Oracle 9i中展现出更为强大的...
oracle的rman数据库备份方案.doc
06-03
RMAN还支持使用Catalog数据库来管理和跟踪备份集，提供更高级的管理和恢复能力。 **CATALOG数据库** RMAN Catalog是一个中央数据库，用于存储所有备份和归档日志的相关信息。使用Catalog可以跨多个备份位置管理和...
Oracle RMAN -不完全恢复
小楼一夜听春雨，深巷明朝卖杏花
12-21 474
在所有的文件都丢失后，即删除下面的所有的文件，做一个全库的恢复，这里没有丢失参数文件，如果丢失了参数文件先要手工创建参数文件启动到nomount，之后恢复控制文件，启动到mount状态，最后恢复数据库，打开数据库。 看到resetlogs都是不完全恢复，在不完全恢复之后要做一个full backup。 至于你想要回到哪个SCN可以通过在rman里面通过list back
RMAN 备份与恢复 实例
热门推荐
David Dai -- Focus on Oracle
10-19 8万+
1. 检查数据库模式：   sqlplus /nolog    conn /as sysdba   archive log list (查看数据库是否处于归档模式中)   若为非归档,则修改数据库归档模式。   startup mount   alter database archivelog   alter database open2.连接到target数据库命令： connect
手动——rman 不完全恢复
u012461550的专栏
01-11 485
如果出现了日志断点就要进行不完全恢复不完全恢复可以用手动，也可以用rman，当然最好用flashback。不管用那种方式，都需要用控制文件。无论控制文件是新的还是旧的都可以用来恢复。如果是控制文件时最新的，则不完全恢复后，不能recover database，不然就将数据文件恢复到控制文件记录的scn的地方，直接到最新了。如果用旧的控制文件恢复，数据文件和控制文件一起恢复到指定的scn或时间点。因
rman 恢复---归档丢失and数据文件损坏
cixian3473的博客
07-05 296
在归档日志有丢失的情况下并且数据文件损坏，恢复数据库。 用rman恢复，归档有丢失，恢复到指定的sequence 1、在数据库open的情况下，做一些操作，确定这些操作所在的归档日志文件 SQL> select...
Oracle--RMAN Recover 缺失的归档操作
Z14523299999的博客
05-14 489
一，环境简介 　　Oracle RMAN 备份的恢复分2个步骤：RESTRE 和 RECOVER。在这里回复的时候是依赖者归档文件的，当周一完成数据全备，保留归档的情况下，后期数据有问题，恢复的时候发现少了一个归档文件，理论上我们只能恢复到确实归档之前。如果我们跳过这个归档的话，让数据库继续恢复，但是数据会有所丢失 　　测试： 创建测试表并且刷写归档SQL> select...
rman不完全备份恢复_归档模式
qq961573863的博客
01-25 872
rman不完全备份恢复_归档模式
oracle 不完整恢复,Oracle——不完全恢复
weixin_36057741的博客
04-06 1419
不完全恢复分为用户不完全恢复和RMAN不完全恢复。若联机重做日志文件或者归档日志文件有丢失，则只能进行不完全恢复。一．不完全恢复的分类1.timerecover选项，指定恢复到某个时间点，常用。2.cancelrecover选项，停止在某个日志切换序列号处，通常只在归档日志文件受损或丢失的情况下使用，从而无法进一步恢复。3.change-baserecover选项，指定到某个SCN号。4.在...
RMAN完全恢复与不完全恢复测试
Kay的博客
02-08 5135
RMAN完全恢复与不完全恢复测试一、完全恢复二、不完全恢复2.1 基于时间点2.2 基于日志序列号2.3 基于SCN 恢复2.4 通过INCARNATION不完全恢复2.5 基于表空间时间点的不完全恢复(TSPITR)2.6 12c RMAN 表级恢复三、总结 一、完全恢复 场景：在T0时间点存在RMAN全备，在T1时间点由于介质损坏，数据文件丢失。redo以及归档文件完整。 解决方法： 可用RM...
rman基于时间点的不完全恢复及相关错误问题
qq_40881607的博客
03-24 466
由于某种原因误删除某些表并且回收站已没有相关的表，但rman恢复是只能恢复到最新的状态，所以，采取了基于时间点或scn号来恢复到指定状态 本操作采用的是模拟基于时间点的恢复操作。 1.利用rman进行一次备份 2.查看原先的状态 3.查看系统时间，并记住该时间 select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') from dual; 4....
Oracle RMAN备份与恢复深度解析
不完全恢复则允许恢复到某个特定时间点或交易，适用于部分数据丢失的情况。 目录库（Catalog Database）是RMAN备份管理的关键组件，用于存储备份元数据。创建目录库后，DBA可以通过多种方式连接，并使用虚拟专用...

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

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值