数据库不完全恢复:

1.清空归档日志

RMAN> crosscheck archivelog all;

RMAN> delete achivelog all;

2.清空数据文件。

select name from v$datafile;

rm v$datafile

3.恢复数据

Solution


How to restore a complete database from an RMAN backup

This note assumes an RMAN catalog is not available. The use of a
catalog is optional in this scenario as the backup information is
available in the controlfile.

Prior to restoring a database you must ensure you have a valid RMAN backup.

In this example we will assume all files are required to be restored:

* Datafiles
* Controlfiles
* Archivelogs (In order to perform recovery)

Online redo logs and temp files are recreated automatically by RMAN
when a resetlogs is issued. Online redo logs and temp files are not
backed up by RMAN

Step 1:  Identify controlfile backup to restore

Note: If  you do not need to restore a controlfile proceed to step 3.

* Locate the RMAN backup you wish to restore.
* These files should be located in the directory where they were backed up to.
* If you have the RMAN backup log available this will also be of assistance.

Within the RMAN backup log you will see the controlfile is backed up last the the piece handle is shown.

....
including current control file in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 2009/01/01 12:00:00
channel ORA_DISK_1: finished piece 1 at 2009/01/01 12:00:02
piece handle=/recovery_area/V11/backupset/2009_05_0 /o1_mf_ncsnf_TAG20090506T11_501tr0h7_.bkp tag=TAG20090506T11 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02

If you do not have an RMAN backup log simply locate the last file RMAN backed up.  This should contain the controlfile backup.

Step 2:  Restore the controlfile

2a) If you DO NOT have a spfile.

If you do have an spfile or init.ora move to Step 2b

If you do not have a valid spfile or init.ora
RMAN has the ability to nomount an instance without the requirement of a
spfile. This will allow you to restore your spfile from a valid backup.

% rman target /

RMAN> startup nomount force;

You will see this message:

..
starting Oracle instance without parameter file for retrieval of spfile
..

At this point you can restore the spfile:

RMAN> restore spfile from ‘/recovery_area/V11/backupset/2009_05_05/o1_mf_ncsnf_TAG20_501tr0h7_.bkp‘;

RMAN> shutdown immediate;

Once the spfile has been successfully restored proceed to Step 2b.

2b)

SQL> startup nomount;

Following the successful nomount of the instance you are ready to restore the
controlfile;

NOTE: The controlfile will be restored to the following location:

SQL> show parameter control_files

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
control_files string /oradata/V11/control01.ctl

% rman target /

You will see the message:

connected to target database: V11 (not mounted)

RMAN> restore controlfile from ‘/recovery_area/V11/backupset/2009_05_06/o1_mf_ncsnf_TAG20090506T113947_501tr0h7_.bkp‘;

Starting restore at 2009/05/11 11:01:26
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=151 device type=DISK

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/oradata/V11/control01.ctl
Finished restore at 2009/05/11 11:01:27

In this example the controlfile has been restored to ‘/oradata/V11/control01.ctl‘

Step 3:  Restore and recover the database

Your next task is to restore the database and perform recovery.  Mount the database now that the controlfile has been restored:

RMAN> alter database mount;

Now you have two options for recovery.

1) Full/Complete recovery.
2) Point In Time Recovery (PIT)

In both examples it is assumed that all archivelogs are available to perform the recovery.

Full recovery
==========

To Perform a full restore and recovery.

run{
restore database;
recover database;
alter database open resetlogs;
}

If you performed a complete recovery with current controlfile
and online redologs in place, you might get below error when opening the
database with resetlogs:

ORA-01139: RESET LOGS option only valid after an incomplete database recovery

At this point simply open the database without resetlogs option.

PITR Recovery
===========

Point-In-Time Recovery (PITR) would be used if you have decided to
restore a database to a particular point in time. This may be warranted
for a hardware fault or if you are aware of a database corruption that
occured at a certain date/time.

run{
set until time "to_date(‘Aug 16 2014 10:30:00‘,‘Mon DD YYYY HH24:MI:SS‘)";
restore database;
recover database;
sql ‘alter database open resetlogs‘;
}


NOTE: The above scripts may be altered to allocate more
channels. Good practice would be to review the backup log and use the
same number of channels for restore as that used by the backup. 

时间: 2024-12-17 18:14:36

数据库不完全恢复:的相关文章

[网络课摘抄]8.1模拟控制文件丢失后的数据库恢复(完全恢复)

1.环境准备 1.1确认数据库版本 1.2确认数据库归档 1.3备份数据库文件 2模拟控制文件丢失后的数据库恢复(完全恢复). 2.1查看控制文件位置 2.2执行操作后删除控制文件 2.3启动数据库 启动数据库的时候发现数据库发生了报错,提示无法确认控制文件,检查告警文件,我们现在检查一下告警文件里的信息: 2.4重建控制文件 对于日志和数据文件都完整的情况下,如果只是控制文件丢失,那么重建控制文件是最好的一种解决方式,一般重建控制文件能够解决99%的问题,现在我们就重建控制文件. 2.5尝试打

使用rman的level0的备份文件迁移oracle数据库-不完全恢复

使用rman的level0的备份文件迁移oracle数据库-不完全恢复-20160811 将oracle数据库从一台机器A迁移到另外的一台机器B(同为linux平台),设置为不同的路径,不同的实例名 源端: ORACLE_BASE=/u01/app/oracle ORACLE_HOME=/u01/app/oracle/product/12.1.0.2/db_1 ORACLE_SID=SCPDB 数据文件位置:/u01/app/oracle/oradata/SCPDB/datafile/ 目标端:

总结Oracle8i 的UNDO表空间损坏(ORA-01092及ORA-00600【4193】)情况下的数据库不完全恢复的经历

服务器断电重启导致备份生产环境的恢复目录库无法进行启动,提示Ora-01092例程终止.强行断开连接 查看跟踪日志: Wed Jan 10 08:41:37 2018 Errors in file d:\Oracle\admin\l3bckdb\bdump\l3bckdbSMON.TRC: ORA-00600: internal error code, arguments: [4193], [1836], [1844], [], [], [], [], [] Wed Jan 10 08:41:3

oracle数据库完全恢复和不完全恢复以及执行用户管理辈分恢复

比较完全恢复和不完全恢复: 一.完全恢复:将数据库恢复到当前最新状态,包括直至请求恢复时进行的所有已提交的数据更改 二.不完全恢复:将数据库恢复到请求恢复操作之前指定的过去时间点 一.完全恢复过程 下面的步骤说明了执行完全恢复期间要采取的操作: 1. 通过备份还原损坏或丢失的文件. 2. 根据需要应用增量备份.归档重做日志文件和联机重做日志文件中的更改.将重做日志更改应用于数据文件,直到到达当前联机日志,并且重新输入了最新的事务处理.在整个过程中会生成还原块.这称为前滚或高速缓存恢复. 3. 此

oracle(创建数据库对象)

1 --创建数据库 2 --1.SYSDBA系统权限 3 startup:--启动数据库. 4 shutdown:--关闭数据库. 5 alter database[mount]|[open]|[backup]|[character set]:--修改数据库到加载状态.打开状态,备份数据库,修改数据库字符集. 6 create database:--创建数据库. 7 drop database:--删除数据库. 8 create spfile:--创建服务器初始化参数文件. 9 alter da

oracle学习笔记----数据库导入导出

一.导入和导出 Oracle的备份是oracle操作中常见的工作,常见的备份方案包括有: 1.逻辑备份(IMP&EXP命令进行备份) 有如下四种模式: (1)表空间备份(tablespace) (2)表备份(table) (3)用户备份(user) (4)完全备份(full) 2.物理文件备份(脱机及联机备份 3.利用RMAN(Recovery Manager)的增量物理文件系统备份 oracle的逻辑备份是使用IMP&EXP命令进行数据导入导出操作.使用EXP命令导出或者使用IMP命令导

Oracle数据库在线重做日志被删除的几种恢复方法

Oracle数据库的在线重做日志中包含了数据库中所有数据的操作记录,我们可以利用重做日志做很多的操作,例如日志挖掘. 有时候,因为种种原因,我们的在线日志被人误删除或者意外损坏掉,我们应该如何进行恢复呢,其实很简单,看下面内容: 我们通过删除在线日志模拟日志被误删除的情况: [[email protected] orcl]$ rm redo* [[email protected] orcl]$ ls -l redo* ls: 无法访问redo*: 没有那个文件或目录 [[email protec

如何Oracle 数据库备份与恢复

转自一位大神的笔记. 一. 理解什么是数据库恢复  当我们使用一个数据库时,总希望数据库的内容是可靠的.正确的,但由于计算机系统的故障(硬件故障.软件故障.网络故障.进程故障和系统故障)影响数据库系统的操作,影响数据库中数据的正确性,甚至破坏数据库,使数据库中全部或部分数据丢失.因此当发生上述故障后,希望能重构这个完整的数据库,该处理称为数据库恢复.恢复过程大致可以分为复原(Restore)与恢复(Recover)过程. 数据库恢复可以分为以下两类: 1.1实例故障的一致性恢复 当实例意外地(如

Oracle 10g数据库备份与恢复操作手册

Oracle 10g数据库备份与恢复操作手册 前言 文档目的 备份与恢复是数据库管理中最重要的方面之一.如果数据库崩溃却没有办法恢复它,那么对企业造成的毁灭性结果可能会是数据丢失.收入减少.客户不满等.不管公司是使用单个数据库还是多个数据库来存储数百  GB或    TB的数据,它们都有一个共同点,即需要制订一个备份与恢复方案来备份重要数据并使自身免于灾难.要制定一个适合自己公司情况的合理的备份与恢复方案,就必须熟悉备份与恢复的方法和操作. 为了给 Oracle DBA和相关技术人员提供一个参考