数据库数据完全丢失,恢复数据库过程

过程|恢复|数据|数据库

恢复测试,模拟数据库硬盘损坏数据丢失。
1、数据库全备份,
2、备份数据文件、控制文件、spfile、口令文件
3、删除数据库(用dbca删除),只留oracle程序。

4、启动数据库实例

HB130000 oracle$rman target / catalog rman/rman@omsora9

Recovery Manager: Release 9.2.0.1.0 - 64bit Production

Copyright (c) 1995, 2002, Oracle Corporation.  All rights reserved.

connected to target database (not started)
connected to recovery catalog database

RMAN> startup nomount

startup failed: ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/oracle/oracle/app/oracle/product/9.2.
0.1/dbs/inithb130000.ora'

trying to start the Oracle instance without parameter files ...
Oracle instance started

Total System Global Area     156729832 bytes

Fixed Size                      741864 bytes
Variable Size                104857600 bytes
Database Buffers              50331648 bytes
Redo Buffers                    798720 bytes

5、查询原数据库dbid,恢复spfile
RMAN> list incarnation;查询原数据库的dbid。

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            CUR Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
15936   131731  HB130000 2380174037       YES 23440815   25-AUG-05

RMAN> set dbid=2380174037;  设置dbid。

executing command: SET DBID
RMAN> restore spfile;

Starting restore at 13-SEP-05

using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
using channel ORA_DISK_4
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: restoring SPFILE
output filename=/oracle/oracle/app/oracle/product/9.2.0.1/dbs/spfilehb130000.ora
channel ORA_DISK_1: restored backup piece 1
piece handle=/oradata/rmanbackup/hb130000_ctl_c-2380174037-20050913-00.bak tag=n
ull params=NULL
channel ORA_DISK_1: restore complete
Finished restore at 13-SEP-05

6、关闭数据库,使用使用spfile文件启动

RMAN> shutdown immediate

Oracle instance shut down

RMAN> startup nomount;

connected to target database (not started)
Oracle instance started

Total System Global Area     303530016 bytes

Fixed Size                      741408 bytes
Variable Size                268435456 bytes
Database Buffers              33554432 bytes
Redo Buffers                    798720 bytes

7、恢复控制文件

RMAN> restore controlfile;

Starting restore at 13-SEP-05

allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=13 devtype=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: sid=14 devtype=DISK
allocated channel: ORA_DISK_3
channel ORA_DISK_3: sid=15 devtype=DISK
allocated channel: ORA_DISK_4
channel ORA_DISK_4: sid=16 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: restoring controlfile
output filename=/oracle/oracle/app/oracle/product/9.2.0.1/dbs/hb130000/control01
.ctl
channel ORA_DISK_1: restored backup piece 1
piece handle=/oradata/rmanbackup/hb130000_ctl_c-2380174037-20050913-00.bak tag=n
ull params=NULL
channel ORA_DISK_1: restore complete
replicating controlfile
input filename=/oracle/oracle/app/oracle/product/9.2.0.1/dbs/hb130000/control01.
ctl
output filename=/oracle/oracle/app/oracle/product/9.2.0.1/dbs/hb130000/control02
.ctl
output filename=/oradata/hb130000/control03.ctl
Finished restore at 13-SEP-05

8、数据库mount

RMAN> alter database mount;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 09/13/2005 14:13:42
ORA-01990: error opening password file '/oracle/oracle/app/oracle/product/9.2.0.
1/dbs/orapw'
ORA-27037: unable to obtain file status
IBM AIX RISC System/6000 Error: 2: No such file or directory
Additional information: 3
RMAN> alter database mount;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 09/13/2005 14:17:18
ORA-01100: database already mounted

9、数据库恢复。

RMAN> restore database;

Starting restore at 13-SEP-05

using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
using channel ORA_DISK_4
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00006 to /oradata/hb130000/indx01.dbf
restoring datafile 00008 to /oradata/hb130000/tools01.dbf
restoring datafile 00013 to /oradata/hb130000/CA.dbf
restoring datafile 00015 to /oradata/hb130000/FOGLIGHT.dbf
restoring datafile 00017 to /oradata/hb130000/GDSS.dbf
channel ORA_DISK_2: starting datafile backupset restore
channel ORA_DISK_2: specifying datafile(s) to restore from backup set
restoring datafile 00002 to /oradata/hb130000/undotbs01.dbf
restoring datafile 00004 to /oradata/hb130000/drsys01.dbf
restoring datafile 00007 to /oradata/hb130000/odm01.dbf
restoring datafile 00014 to /oradata/hb130000/QUEST.dbf
restoring datafile 00021 to /oradata/hb130000/oem_repository.dbf
channel ORA_DISK_3: starting datafile backupset restore
channel ORA_DISK_3: specifying datafile(s) to restore from backup set
restoring datafile 00003 to /oradata/hb130000/cwmlite01.dbf
restoring datafile 00005 to /oradata/hb130000/example01.dbf
restoring datafile 00010 to /oradata/hb130000/xdb01.dbf
restoring datafile 00016 to /oradata/hb130000/gwd.dbf
restoring datafile 00020 to /oradata/hb130000/catalog_rman.dbf
channel ORA_DISK_4: starting datafile backupset restore
channel ORA_DISK_4: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /oradata/hb130000/system01.dbf
restoring datafile 00009 to /oradata/hb130000/users01.dbf
restoring datafile 00012 to /oradata/hb130000/GFB.DBF
restoring datafile 00019 to /oradata/hb130000/tgggg.dbf
channel ORA_DISK_1: restored backup piece 1
piece handle=/oradata/rmanbackup/df_HB130000_568897697_175_1.bak tag=TAG20050913
T110814 params=NULL
channel ORA_DISK_1: restore complete
channel ORA_DISK_2: restored backup piece 1
piece handle=/oradata/rmanbackup/df_HB130000_568897694_173_1.bak tag=TAG20050913
T110814 params=NULL
channel ORA_DISK_2: restore complete
channel ORA_DISK_3: restored backup piece 1
piece handle=/oradata/rmanbackup/df_HB130000_568897694_172_1.bak tag=TAG20050913
T110814 params=NULL
channel ORA_DISK_3: restore complete
channel ORA_DISK_4: restored backup piece 1
piece handle=/oradata/rmanbackup/df_HB130000_568897695_174_1.bak tag=TAG20050913
T110814 params=NULL
channel ORA_DISK_4: restore complete
Finished restore at 13-SEP-05

RMAN>

RMAN> recover database;

Starting recover at 13-SEP-05
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
using channel ORA_DISK_4

starting media recovery

channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=32
channel ORA_DISK_1: restored backup piece 1
piece handle=/oradata/rmanbackup/df_HB130000_568897755_179_1.bak tag=TAG20050913
T110915 params=NULL
channel ORA_DISK_1: restore complete
archive log filename=/oradata/rmanbackup/archive/hb130000_1_32.dbf thread=1 sequ
ence=32
unable to find archive log
archive log thread=1 sequence=33
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 09/13/2005 14:20:50
RMAN-06054: media recovery requesting unknown log: thread 1 scn 26146497

RMAN> recover database;

Starting recover at 13-SEP-05
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
using channel ORA_DISK_4

starting media recovery

unable to find archive log
archive log thread=1 sequence=33
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 09/13/2005 14:26:33
RMAN-06054: media recovery requesting unknown log: thread 1 scn 26146497

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

database opened
new incarnation of database registered in recovery catalog
starting full resync of recovery catalog
full resync complete

RMAN>

11、完全备份数据库。

时间: 2024-12-28 04:00:51

数据库数据完全丢失,恢复数据库过程的相关文章

oracle数据库oracleasm createdisk重新创建asm disk后数据0丢失恢复案例

有客户反馈他们重启系统之后,发现asmlib创建的asmdisk丢失了,然后又使用oracleasm deletedisk和createdisk重新创建的asm disk,最后发现asm diskgroup无法mount.让客户通过dd 备份5m数据,然后使用kfed分析 kefd分析结果 E:\OneDrive\ORACLE\recover\no_backup\asm\kfedwin>kfed read H:\temp\asmlib\xx.img kfbh.endian:           

oracle数据文件,恢复数据库问题

问题描述 oracle数据文件,恢复数据库问题 一直用的mysql,今天老板突然给我一个oracle的文件,说让我恢复oracle数据库,表示搞不定请教诸位.

探索ORACLE之RMAN_07单个数据文件丢失恢复

探索ORACLE之RMAN_07单个数据文件丢失恢复 作者:吴伟龙   Name:Prodence Woo QQ:286507175  msn:hapy-wuweilong@hotmail.com   备份的终极目的是为了更好的将数据恢复和还原过来,在前面的章节中我们已经重点谈完了RMAN的备份,实际上也穿插的谈了些复杂的完整恢复.当然在这节当中我们将会由浅入深的详细谈谈在几种不同情况下的数据库恢复. 1.     数据文件的丢失恢复 1.1    在wwl表空间上创建5张表,并添加数据. SQ

Oracle报错ORA-00604 ORA-00376 数据库redo undo丢失恢复例子

运维DBA反映数据库存储故障,导致redo undo两个表空间数据文件丢失,数据库无法open启动 某集团的ebs系统因磁盘空间不足把redo和undo存放到raid 0之上,而且该库无任何备份.最终悲剧发生了,raid 0异常导致redo undo全部丢失,数据库无法正常启动(我接手之时数据库已经resetlogs过,但是未成功) 1.Oracle报错ORA-00604 ORA-00376 Sun Jul 27 11:31:27 2014 SMON: enabling cache recove

MySQL对数据库数据进行复制的基本过程详解_Mysql

复制      复制是从一个MySQL服务器(master)将数据拷贝到另外一台或多台MySQL服务器(slaves)的过程.复制是异步进行的--slaves服务器不需要持续地保持连接来接收master的数据.依据配置的不同,可以复制所有数据库,或指定的数据库,甚至是某一数据库指定的表.      使用复制功能的目的在于: 向外扩展的解决方案 -- 通过在多台服务器之间分散负载来提高性能.在这种环境下,所有写和更新操作都在master服务器上进行,而读操作则发生在一台或多台slaves服务器上.

oracle中alter database create datafile 导致数据文件丢失恢复

alter database create datafile导致原始数据文件丢失 有客户一个小系统找我们恢复,通过Oracle Database Recovery Check 检测之后我们红框部分发现一奇怪现象 1.文件头fuzzy为NO,不符合数据库异常crash常识,也和其他文件该状态不匹配 2.文件的创建时间,scn均和checkpoint时间,scn一致(也就是说该文件是创建之后就checkpoint,然后就没有其他操作) 3.文件开始应用的归档为5,110和其他数据文件要求的3115相

Sql Server数据库数据导入到SQLite数据库中

背景:Sql Serve数据库中有个表格A,想把数据导入到SQLite数据库中 工具下载地址:点击打开链接 用法: 原作者地址及下载地址:点击打开链接

SQLServer2005 没有日志文件(*.ldf) 只有数据文件(*.mdf) 恢复数据库的方法_mssql2005

复制代码 代码如下: exec sp_attach_db exun,'d:\exun2.mdf' 一句话就可以了. 网上看了那些比较繁琐的,都是sql server 2000版本的. (可能执行一次不能成功,测试了下,有时候需要执行2次以上命令才行) 执行了之后,记得刷新数据库,不然是不会显示的

mysql二进制日志文件恢复数据库_Mysql

二进制日志的文件的作用     mysql二进制日志文件用来记录所有用户对数据库操作,即记录用户对数据库操作的sql语句.如果有此文件,当数据库发生意外时,可以通过此文件查看到用户在此文件记录的时间段内用户所做的操作,再和数据库备份配合使用,即可再现用户操作,使数据库恢复. 二进制日志文件的弊端 二进制日志文件开启后,所有对数据库操作的记录均会被记录到此文件, 所以,当长时间开启之后,日志文件会变得很大,占用磁盘空间. 使用二进制日志文件恢复数据库 开启日志文件 mysql默认是不开启日志文件的