手工恢复

1、恢复过程查看的试图:

1)v$recovery_file:查看需要恢复的datafile

2)v$recovery_log:查看recover需要的redo日志

3)v$archived_log:查看已经归档的日志

2、手工完全恢复

实验一:所有数据文件和控制文件都丢失

1)先将控制文件dump到trace中

SQL> alter database backup controlfile to trace as ‘/u01/app/oracle/admin/EMREP/udump/haha.trc‘;

2)创建实验表

SQL> create table emp1 as select * from scott.emp;

插入数据提交并归档

SQL> insert into emp1 select * from scott.emp;
SQL> commit;
SQL> alter system archive log current;

插入数据只提交
SQL> insert into emp1 select * from scott.emp;
SQL> commit;

不提交不归档
SQL> insert into emp1 select * from scott.emp;

3)模拟断电,破会数据文件和控制文件

SQL> shutdown abort

[[email protected] hot_bak]$ cd /u01/app/oracle/oradata/EMREP/
[[email protected] EMREP]$ ls
control01.ctl  example01.dbf     redo01.log  sysaux01.dbf  undotbs01.dbf
control02.ctl  gguser.dbf        redo02.log  system01.dbf  users01.dbf
control03.ctl  goldengate01.dbf  redo03.log  temp01.dbf
[[email protected] EMREP]$ rm *.dbf
[[email protected] EMREP]$ rm *.ctl

4)启动数据库失败

SQL> startup
ORACLE instance started.
Total System Global Area  608174080 bytes
Fixed Size                  1220844 bytes
Variable Size             197136148 bytes
Database Buffers          406847488 bytes
Redo Buffers                2969600 bytes
ORA-00205: error in identifying control file, check alert log for more info

5)恢复解决:

(1)重建控制文件,因为日志没有丢失,所以这里用NORESETLOGS

[[email protected] udump]$ more haha.trc

CREATE CONTROLFILE REUSE DATABASE "EMREP" NORESETLOGS FORCE LOGGING ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 ‘/u01/app/oracle/oradata/EMREP/redo01.log‘  SIZE 50M,
  GROUP 2 ‘/u01/app/oracle/oradata/EMREP/redo02.log‘  SIZE 50M,
  GROUP 3 ‘/u01/app/oracle/oradata/EMREP/redo03.log‘  SIZE 50M
-- STANDBY LOGFILE

DATAFILE
  ‘/u01/app/oracle/oradata/EMREP/system01.dbf‘,
  ‘/u01/app/oracle/oradata/EMREP/undotbs01.dbf‘,
  ‘/u01/app/oracle/oradata/EMREP/sysaux01.dbf‘,
  ‘/u01/app/oracle/oradata/EMREP/users01.dbf‘,
  ‘/u01/app/oracle/oradata/EMREP/example01.dbf‘,
  ‘/u01/app/oracle/oradata/EMREP/goldengate01.dbf‘,
  ‘/u01/app/oracle/oradata/EMREP/gguser.dbf‘
CHARACTER SET WE8ISO8859P1
;

重建报错,我们需要先转储备份的数据文件

[[email protected] hot_bak]$ cp * /u01/app/oracle/oradata/EMREP/

[[email protected] hot_bak]$ cp control01.ctl /u01/app/oracle/oradata/EMREP/control01.ctl
[[email protected] hot_bak]$ cp control01.ctl /u01/app/oracle/oradata/EMREP/control02.ctl
[[email protected] hot_bak]$ cp control01.ctl /u01/app/oracle/oradata/EMREP/control03.ctl

再次重建成功;

查看scn号发现不一致

SQL> select file#,checkpoint_change# from v$datafile;
         1             998993
         2             998993
         3             998993
         4             998993
         5             998993
         6             998993
         7             998993
SQL> select file#,checkpoint_change# from v$datafile_header;
         1             998253
         2             998289
         3             998313
         4             998340
         5             998360
         6             998384
         7             998410

需要恢复数据库

SQL> recover database;
Media recovery complete.
SQL> alter database open;

SQL> select count(*) from emp1;
        42

数据恢复到最后一次提交。

实验二:只有数据文件丢失了

1)创建实验环境

SQL> create table emp2 as select * from scott.emp;
SQL> insert into emp2 select * from scott.emp;
SQL> commit;
SQL> alter system archive log current;
SQL> insert into emp2 select * from scott.emp;
SQL> commit;
SQL> insert into emp2 select * from scott.emp;
SQL> select count(*) from emp2;
        56

2)模拟断电,破坏试验

SQL> shutdown abort
ORACLE instance shut down.

删除所有的数据文件

[[email protected] EMREP]$ ls
control01.ctl  example01.dbf     redo01.log  sysaux01.dbf   users01.dbf
control02.ctl  gguser.dbf        redo02.log  system01.dbf
control03.ctl  goldengate01.dbf  redo03.log  undotbs01.dbf
[[email protected] EMREP]$ rm *.dbf

3)启动失败

SQL> startup
ORACLE instance started.
Total System Global Area  608174080 bytes
Fixed Size                  1220844 bytes
Variable Size             197136148 bytes
Database Buffers          406847488 bytes
Redo Buffers                2969600 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1: ‘/u01/app/oracle/oradata/EMREP/system01.dbf‘

查看需要恢复的数据文件

SQL> select file#,error from v$recover_file;
         1 FILE NOT FOUND
         2 FILE NOT FOUND
         3 FILE NOT FOUND
         4 FILE NOT FOUND
         5 FILE NOT FOUND
         6 FILE NOT FOUND
         7 FILE NOT FOUND

SQL> select file#,name from v$datafile;

1 /u01/app/oracle/oradata/EMREP/system01.dbf
         2 /u01/app/oracle/oradata/EMREP/undotbs01.dbf
         3 /u01/app/oracle/oradata/EMREP/sysaux01.dbf
         4 /u01/app/oracle/oradata/EMREP/users01.dbf
         5 /u01/app/oracle/oradata/EMREP/example01.dbf
         6 /u01/app/oracle/oradata/EMREP/goldengate01.dbf
         7 /u01/app/oracle/oradata/EMREP/gguser.dbf

转储备份:

[[email protected] hot_bak]$ cp *.dbf /u01/app/oracle/oradata/EMREP/

恢复:

SQL> recover database;
ORA-00279: change 998253 generated at 07/27/2014 13:20:11 needed for thread 1
ORA-00289: suggestion : /home/oracle/EMREP/1_23_839513627.dbf
ORA-00280: change 998253 for thread 1 is in sequence #23

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto            ---让系统自己找需要的日志
Log applied.
Media recovery complete.
SQL> alter database open;
SQL> select count(*) from emp2;
        42

数据恢复到最后一次的提交。

手工恢复

时间: 2024-12-15 05:57:50

手工恢复的相关文章

使用winhex手工恢复Linux Ext4 GPT分区表案例

Linux Ext4 GPT分区表恢复案例 一:故障现象 硬盘分区位置有坏道,导致分区丢失.  恢复详细步骤如下图:1:分区起始扇区和结束扇区描述字节位置.  2:分区表CRC校验值所在字节位置,扇区1(第二个扇区)  3:分区表CRC校验值计算方法,从扇区2到扇区33选择上然后做CRC校验(计算哈希值)  跳到33扇区  打开"工具"-"计算哈希值"   选择"CRC32(32bit)"  得到我们要的CRC校验值       恢复完成后,分区

控制文件手工恢复

所有的控制文件坏了,有备份进行恢复 (1)备份control fileSQL> alter database backup controlfile to '/orcl_backup/hot/control.bin'; Database altered. 查看 检查点情况SQL> col name for a35SQL> select file#,name ,checkpoint_change# from v$datafile; FILE# NAME CHECKPOINT_CHANGE#-

Openstack虚机实例状态错误手工恢复vm_state:error

1.找到状态为出错状态的VM.在数据库里面表现Status为ERROR而非ACTIVE. 2.找到出错状态VM的UUID. 3.使用MYSQL 客户端工具连接到MySQL数据库. 4.连接到MYSQL数据库后,执行use nova;使用nova数据库. 5.select * from instances where uuid='实例的ID '\G;可以查看到字段vm_state值为error. 6.执行语句:UPDATE instances SET vm_state = 'active' and

手工恢复OSSIM数据库密码

1,现象 今天需要远程连接ossim的mysql数据库读取些东西,于是登录ossim的终端,发现这个mysql客户端无法直接登录,使用自己安装时候那些口令都不行 alienvault:~# mysql -uroot -p Enter password: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES) alienvault:~# mysql -uroot -p Enter pas

手工备份恢复oracle数据库

 手工备份恢复oracle数据库: 虽然已经有了rman工具 但是手工恢复oracle能够让你对oracle数据库有更加深入的了解 数据库一致性开机条件: 数据文件 scn,控制文件 scn,redo scn一致 控制文件记录: 数据文件应该到达的scn 当前redo 数据的物理结构信息 归档信息 前提条件: 归档日志开启 数据文件有备份 控制文件有备份 备份数据: 数据文件备份: 数据文件进入备份模式: select 'alter tablespace '|| tablespace_name|

【恢复】Redo日志文件丢失的恢复

第一章 Redo文件丢失的恢复 1.1  online redolog file 丢失 联机Redo日志是Oracle数据库中比较核心的文件,当Redo日志文件异常之后,数据库就无法正常启动,而且有丢失据的风险,强烈建议在条件允许的情况下,对Redo日志进行多路镜像.需要注意的是,RMAN不能备份联机Redo日志文件.所以,联机Redo日志一旦出现故障,则只能进行清除日志了.清除日志文件即表明可以重用该文件. 1.1.1  数据库归档/非归档模式下inactive redo异常ORA-00316

WORD文档误删除、误清空等恢复的几种方法

前因:word中保存了近一个星期的读书笔记,设置了自动保存,也会习惯性的CTRL+S手动保存,但前天word不知怎么就挂了,再打开时写的文档已经不在本地文件夹了,当时就傻眼了,刚开始只好认栽就打算重新录一遍吧,但越想越觉得浪费时间,觉得肯定有快捷简便的恢复方法(觉得这是读研养成的一个好习惯,有不懂的就baidu或者Google),林子大了啥鸟都有,这句话真不假啊,要想到你遇到的问题在亿万网友中总会有重现的吧(根据概率统计分析可得^|^),果然在网上找到了,综合几种方法也把文档找回来了! WORD

Cisco PT模拟实验(20) 通过TFTP协议备份、恢复配置或系统升级

Cisco PT模拟实验(20) 通过TFTP协议备份.恢复配置或系统升级 实验目的: 掌握TFTP方式备份.恢复配置文件的基本命令 掌握TFTP上传IOS文件并升级系统的方法 熟悉TFTP协议文件传输的原理 实验背景: 交换机.路由器等网络设备内的用户配置是网络得以正常运行的重要保证,也是网络维护管理的重要内容,在复杂的网络中,网络设备配置往往比较复杂,一旦用户配置丢失,要用手工恢复不仅工作量相当大,而且容易出错.现在要求利用TFTP协议在完成路由器配置后进行配置备份,并向一台路由器上传IOS

恢复 Postman 中误删除的 Collection 的方法

先说下误删除的原因. 我在 Postman 中建了 2 个 workspace,我把其中一个 workspace 中的 collection 分享到另一个 workspace 了,按我正常的理解,这两个已经是独立的了,但是当我从第二个 workspace 删除这个分享的 collection 后,才发现原来 workspace 的 collection 也没了,囧. 这件事的教训: **1. 从别的 workspace share 过来的 collection 如果被删除,会同步删除源 coll