用备份控制文件做不完全恢复下的完全恢复(全备<老>--备份控制文件<次新>--新建表空间andy--日志文件<新>)

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介:

为什么会使用备份的控制文件? 实际工作中主要有两种情况:


第一种:当前控制文件全部损坏,而数据文件备份,控制文件备份及当前日志处于不同SCN版本,它们之间又增加过表空间(数据文件)。
第二种:当前控制文件没有损坏,但想要恢复被删除的表空间。


实验2 :全备<老>--备份控制文件<次新>--新建表空间andy--日志文件<新>


分析说明: 整个恢复过程中datafile结构有了变化,变化发生在备份控制文件之后,新增了表空间andy,控制文件备份里没有此表空间记录,但日志里有。


1)准备环境




--生成要备份的数据文件的命令
SQL>  select 'ho cp ' || name || ' /home/oracle/coldbak' from v$datafile;




'HOCP'||NAME||'/HOME/ORACLE/COLDBAK'
-------------------------------------------------------------------------
ho cp /home/oracle/app/oradata/orcl/system01.dbf /home/oracle/coldbak
ho cp /home/oracle/app/oradata/orcl/sysaux01.dbf /home/oracle/coldbak
ho cp /home/oracle/app/oradata/orcl/undotbs01.dbf /home/oracle/coldbak
ho cp /home/oracle/app/oradata/orcl/users01.dbf /home/oracle/coldbak
ho cp /home/oracle/app/oradata/orcl/tbtb01.dbf /home/oracle/coldbak
ho cp /home/oracle/app/oradata/orcl/ogg01.dbf /home/oracle/coldbak




6 rows selected.




SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.




SQL> ho cp /home/oracle/app/oradata/orcl/control01.ctl /home/oracle/coldbak
ho cp /home/oracle/app/flash_recovery_area/orcl/control02.ctl /home/oracle/coldbak
SQL> ho cp /home/oracle/app/oradata/orcl/system01.dbf /home/oracle/coldbak
ho cp /home/oracle/app/oradata/orcl/sysaux01.dbf /home/oracle/coldbak
ho cp /home/oracle/app/oradata/orcl/undotbs01.dbf /home/oracle/coldbak
ho cp /home/oracle/app/oradata/orcl/users01.dbf /home/oracle/coldbak
ho cp /home/oracle/app/oradata/orcl/tbtb01.dbf /home/oracle/coldbak
ho cp /home/oracle/app/oradata/orcl/ogg01.dbf /home/oracle/coldbak




SQL> startup;
ORACLE instance started.




Total System Global Area 1068937216 bytes
Fixed Size    2220200 bytes
Variable Size  729812824 bytes
Database Buffers  331350016 bytes
Redo Buffers    5554176 bytes
Database mounted.
Database opened.


SQL> alter database backup controlfile to '/home/oracle/coldbak/ctl01.bak';


Database altered.


SQL>  create tablespace andy datafile '/home/oracle/app/oradata/orcl/andy01.dbf' size 1m;


Tablespace created.


SQL>  create table andy.andy(id int) tablespace andy;


Table created.


SQL>  insert into andy.andy values (100);


1 row created.


SQL> commit;


Commit complete.


SQL> select * from andy.andy;


        ID
----------
       100


SQL> select * from v$log;


    GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE    MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- ---------- --- ----------------
         1          1          1   52428800        512          1 NO  CURRENT
         2          1          0   52428800        512          1 YES UNUSED
         3          1          0   52428800        512          1 YES UNUSED


2)模拟新建数据文件损坏


[oracle@11g orcl]$ rm -rf andy01.dbf


SQL> alter system flush buffer_cache;


System altered.


SQL> select * from andy.andy;
select * from andy.andy
*
ERROR at line 1:
ORA-01116: error in opening database file 7
ORA-01110: data file 7: '/home/oracle/app/oradata/orcl/andy01.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3


3) 关闭数据库


SQL> shutdown immediate;


4)还原所有数据文件,以老控制文件替换当前控制文件


[oracle@11g orcl]$ rm -rf *.dbf
[oracle@11g orcl]$ rm -rf /home/oracle/app/oradata/orcl/control01.ctl
[oracle@11g orcl]$ rm -rf /home/oracle/app/flash_recovery_area/orcl/control02.ctl
[oracle@11g coldbak]$ cp ctl01.bak /home/oracle/app/oradata/orcl/control01.ctl
[oracle@11g coldbak]$ cp ctl01.bak /home/oracle/app/flash_recovery_area/orcl/control02.ctl
[oracle@11g coldbak]$ cp *.dbf /home/oracle/app/oradata/orcl/


5)启动数据库


SQL> startup;
ORACLE instance started.


Total System Global Area 1068937216 bytes
Fixed Size    2220200 bytes
Variable Size  729812824 bytes
Database Buffers  331350016 bytes
Redo Buffers    5554176 bytes
Database mounted.
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open


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


     FILE# CHECKPOINT_CHANGE# NAME
---------- ------------------ ---------------------------------------------------
         1            2036796 /home/oracle/app/oradata/orcl/system01.dbf
         2            2036796 /home/oracle/app/oradata/orcl/sysaux01.dbf
         3            2036796 /home/oracle/app/oradata/orcl/undotbs01.dbf
         4            2036796 /home/oracle/app/oradata/orcl/users01.dbf
         5            2036796 /home/oracle/app/oradata/orcl/tbtb01.dbf
         6            2036796 /home/oracle/app/oradata/orcl/ogg01.dbf


6 rows selected.


SQL> select file#,checkpoint_change# from v$datafile_header;


     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1            2035583
         2            2035583
         3            2035583
         4            2035583
         5            2035583
         6            2035583


6 rows selected.


6)使用备份控制文件恢复数据库


SQL>  recover database using backup controlfile;
ORA-00279: change 2036793 generated at 12/12/2014 05:56:43 needed for thread 1
ORA-00289: suggestion : /home/oracle/archivelog/1_1_866095003.dbf
ORA-00280: change 2036793 for thread 1 is in sequence #1




Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/home/oracle/app/oradata/orcl/redo01.log
ORA-00283: recovery session canceled due to errors
ORA-01244: unnamed datafile(s) added to control file by media recovery
ORA-01110: data file 7: '/home/oracle/app/oradata/orcl/andy01.dbf'




ORA-01112: media recovery not started




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


     FILE# CHECKPOINT_CHANGE# NAME
---------- ------------------ ------------------------------------------------------------
         1            2036796 /home/oracle/app/oradata/orcl/system01.dbf
         2            2036796 /home/oracle/app/oradata/orcl/sysaux01.dbf
         3            2036796 /home/oracle/app/oradata/orcl/undotbs01.dbf
         4            2036796 /home/oracle/app/oradata/orcl/users01.dbf
         5            2036796 /home/oracle/app/oradata/orcl/tbtb01.dbf
         6            2036796 /home/oracle/app/oradata/orcl/ogg01.dbf
         7            2039190 /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/UNNAMED0    
                              0007            <-老控制文件不知道之后的andy01.dbf




7 rows selected.


说明:老控制文件不知道之后的andy01.dbf


SQL> select file#,checkpoint_change# from v$datafile_header;


     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1            2039192
         2            2039192
         3            2039192
         4            2039192
         5            2039192
         6            2039192
         7                  0


7 rows selected.


7)重命名数据文件


SQL> alter database create datafile '/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/UNNAMED00007' as '/home/oracle/app/oradata/orcl/andy01.dbf';


Database altered.


说明:上面自动完成了两个动作1)加了一个数据文件andy01.dbf,2)重命名控制文件UNNAMED00007为andy01.dbf


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


     FILE# CHECKPOINT_CHANGE# NAME
---------- ------------------ -----------------------------------------------
         1            2036796 /home/oracle/app/oradata/orcl/system01.dbf
         2            2036796 /home/oracle/app/oradata/orcl/sysaux01.dbf
         3            2036796 /home/oracle/app/oradata/orcl/undotbs01.dbf
         4            2036796 /home/oracle/app/oradata/orcl/users01.dbf
         5            2036796 /home/oracle/app/oradata/orcl/tbtb01.dbf
         6            2036796 /home/oracle/app/oradata/orcl/ogg01.dbf
         7            2039190 /home/oracle/app/oradata/orcl/andy01.dbf


7 rows selected.


SQL>  recover database using backup controlfile;
ORA-00279: change 2039190 generated at 12/12/2014 06:24:49 needed for thread 1
ORA-00289: suggestion : /home/oracle/archivelog/1_1_866095003.dbf
ORA-00280: change 2039190 for thread 1 is in sequence #1




Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/home/oracle/app/oradata/orcl/redo01.log
Log applied.
Media recovery complete.


8)resetlogs打开数据库


SQL> alter database open resetlogs;


Database altered.


9)验证


SQL> select * from andy.andy;


        ID
----------
       100


OK,结束。 转载请标明出处。

文章可以转载,必须以链接形式标明出处。


本文转自 张冲andy 博客园博客,原文链接:http://www.cnblogs.com/andy6/p/6277791.html    ,如需转载请自行联系原作者
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
7天前
|
存储 Oracle 关系型数据库
【赵渝强老师】MySQL InnoDB的数据文件与重做日志文件
本文介绍了MySQL InnoDB存储引擎中的数据文件和重做日志文件。数据文件包括`.ibd`和`ibdata`文件,用于存放InnoDB数据和索引。重做日志文件(redo log)确保数据的可靠性和事务的持久性,其大小和路径可由相关参数配置。文章还提供了视频讲解和示例代码。
113 11
【赵渝强老师】MySQL InnoDB的数据文件与重做日志文件
|
7天前
|
SQL Oracle 关系型数据库
【赵渝强老师】Oracle的控制文件与归档日志文件
本文介绍了Oracle数据库中的控制文件和归档日志文件。控制文件记录了数据库的物理结构信息,如数据库名、数据文件和联机日志文件的位置等。为了保护数据库,通常会进行控制文件的多路复用。归档日志文件是联机重做日志文件的副本,用于记录数据库的变更历史。文章还提供了相关SQL语句,帮助查看和设置数据库的日志模式。
【赵渝强老师】Oracle的控制文件与归档日志文件
|
5天前
|
Windows Python
如何反向读取Windows系统日志EVTX文件?
以下是如何反向读取Windows系统日志EVTX文件
15 2
|
7天前
|
Oracle 关系型数据库 数据库
【赵渝强老师】Oracle的参数文件与告警日志文件
本文介绍了Oracle数据库的参数文件和告警日志文件。参数文件分为初始化参数文件(PFile)和服务器端参数文件(SPFile),在数据库启动时读取并分配资源。告警日志文件记录了数据库的重要活动、错误和警告信息,帮助诊断问题。文中还提供了相关视频讲解和示例代码。
|
1月前
|
监控 Linux 应用服务中间件
系统监控:使用日志文件 journalctl的使用
本文介绍了如何使用`journalctl`命令来监控和查看Linux系统的日志文件,包括查看特定行数、过滤日志级别、实时跟踪日志、按时间段查询日志以及日志轮换和压缩的配置。
40 2
系统监控:使用日志文件 journalctl的使用
|
1月前
|
SQL 数据库
为什么 SQL 日志文件很大,我应该如何处理?
为什么 SQL 日志文件很大,我应该如何处理?
|
1月前
|
SQL 数据库
为什么SQL日志文件很大,该如何处理?
为什么SQL日志文件很大,该如何处理?
|
11天前
|
XML 安全 Java
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
本文介绍了Java日志框架的基本概念和使用方法,重点讨论了SLF4J、Log4j、Logback和Log4j2之间的关系及其性能对比。SLF4J作为一个日志抽象层,允许开发者使用统一的日志接口,而Log4j、Logback和Log4j2则是具体的日志实现框架。Log4j2在性能上优于Logback,推荐在新项目中使用。文章还详细说明了如何在Spring Boot项目中配置Log4j2和Logback,以及如何使用Lombok简化日志记录。最后,提供了一些日志配置的最佳实践,包括滚动日志、统一日志格式和提高日志性能的方法。
117 30
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
|
1月前
|
XML JSON Java
Logback 与 log4j2 性能对比:谁才是日志框架的性能王者?
【10月更文挑战第5天】在Java开发中,日志框架是不可或缺的工具,它们帮助我们记录系统运行时的信息、警告和错误,对于开发人员来说至关重要。在众多日志框架中,Logback和log4j2以其卓越的性能和丰富的功能脱颖而出,成为开发者们的首选。本文将深入探讨Logback与log4j2在性能方面的对比,通过详细的分析和实例,帮助大家理解两者之间的性能差异,以便在实际项目中做出更明智的选择。
218 3
|
1月前
|
存储 缓存 关系型数据库
MySQL事务日志-Redo Log工作原理分析
事务的隔离性和原子性分别通过锁和事务日志实现,而持久性则依赖于事务日志中的`Redo Log`。在MySQL中,`Redo Log`确保已提交事务的数据能持久保存,即使系统崩溃也能通过重做日志恢复数据。其工作原理是记录数据在内存中的更改,待事务提交时写入磁盘。此外,`Redo Log`采用简单的物理日志格式和高效的顺序IO,确保快速提交。通过不同的落盘策略,可在性能和安全性之间做出权衡。
1627 14