oracle查询备份路径,Oracle备份与恢复案例

爱被打了一巴掌 2023-01-18 09:10 888阅读 0赞

完全恢复：

前提条件：所需要的归档日志文件和online redolog都在

方式一、数据库在打开的情况下进行恢复

适合的环境：普通数据文件损坏(非system、undo的表空间的数据文件)

环境准备：

1、以scott用户登入，往test表当中插入数据，并导致日志切换至少3组以上。

SQL> select count(\*) from test;

COUNT(\*)

\----------

112

2、最后再进行insert操作，但是没有提交：

SQL> select count(\*) from test;

COUNT(\*)

\----------

112

3、主机断电，导致users表空间的某个数据文件损坏。

SQL> shutdown abort

ORACLE instance shut down.

rm -rf /u01/app/oracle/oradata/cuug/cuug/users\*

4、主机加电，尝试打开数据库

\[oracle@cuug95 ~\]$ sqlplus '/as sysdba'

SQL\*Plus: Release 10.2.0.1.0 - Production on Sun Aug 21 06:39:55

2011

Connected to an idle instance.

SQL> startup

ORACLE instance started.

Total System Global Area 167772160 bytes

Fixed Size 1218316 bytes

Variable Size 67111156 bytes

Database Buffers 96468992 bytes

Redo Buffers 2973696 bytes

Database mounted.

ORA-01157: cannot identify/lock data file 4 - see DBWR trace

file

ORA-01110: data file 4:

'/u01/app/oracle/oradata/cuug/cuug/users01.dbf'

数据库打开失败，提示某个数据文件无法识别，查看警告日志文件，获得更加详细的信息。

5、从最近的备份中转储(restore)所需的数据文件到目标位置：

RMAN> restore tablespace users;

6、尝试打开数据库

SQL> alter database open;

alter database open

ERROR at line 1:

ORA-01113: file 4 needs media recovery

ORA-01110: data file 4:

'/u01/app/oracle/oradata/cuug/cuug/users01.dbf'

7、oracle判断某个数据文件需要做recovery的依据是检查点号，

查看控制文件中各个数据文件所应该有的检查点号：

select name,CHECKPOINT\_CHANGE\# from v$datafile

NAME CHECKPOINT\_CHANGE\#

\--------------------------------------------------

\------------------

/u01/app/oracle/oradata/cuug/cuug/system01.dbf 1285655

/u01/app/oracle/oradata/cuug/cuug/undotbs01.dbf 1285655

/u01/app/oracle/oradata/cuug/cuug/sysaux01.dbf 1285655

/u01/app/oracle/oradata/cuug/cuug/users01.dbf 1285655

/u01/app/oracle/oradata/cuug/cuug/example01.dbf 1285655

/u01/app/oracle/oradata/cuug/cuug/users02.dbf 1285655

查看数据文件头实际的检查点号：

SQL> select name,CHECKPOINT\_CHANGE\# from

v$datafile\_header;

NAME CHECKPOINT\_CHANGE\#

\--------------------------------------------------

\------------------

/u01/app/oracle/oradata/cuug/cuug/system01.dbf 1285655

/u01/app/oracle/oradata/cuug/cuug/undotbs01.dbf 1285655

/u01/app/oracle/oradata/cuug/cuug/sysaux01.dbf 1285655

/u01/app/oracle/oradata/cuug/cuug/users01.dbf 1284481

/u01/app/oracle/oradata/cuug/cuug/example01.dbf 1285655

/u01/app/oracle/oradata/cuug/cuug/users02.dbf 1284481

注意：通过比较，我们发现控制文件中记录的检查点号跟实际的数据文件头的检查点号不一致，由此判断需要做介质恢复。

8、为了提供数据库的可用性，我们可以先把数据库打开，然后再恢复损坏的数据文件，要先把损坏的数据文件offline：

SQL> alter database datafile

'/u01/app/oracle/oradata/cuug/cuug/users01.dbf' offline;

Database altered.

SQL> alter database datafile

'/u01/app/oracle/oradata/cuug/cuug/users02.dbf' offline;

9、尝试打开数据库：

SQL> alter database open;

Database altered.

10、再对损坏的数据文件进行recovery，在recovery 过程中，观察警告日志文件：

SQL> recover tablespace users;

通过观察警告日志文件，可以看出，oracle做recovery的时候是采用archivelog ＋ online

redolog的方式进行。

11、把表空间改变成online状态。

SQL> alter tablespace users online;

Tablespace altered.

12、验证数据文件是否正确：

SQL> select count(\*) from scott.test;

COUNT(\*)

\----------

112

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

方式二、数据库在mount状态下恢复

适合环境：所有类型的数据文件损坏

1、主机断电，导致所有的数据文件损坏(控制文件没有损坏)

SQL> shutdown abort

ORACLE instance shut down.

rm -rf /u01/app/oracle/oradata/cuug/cuug/\*.dbf

2、尝试打开数据库：

SQL> startup

ORACLE instance started.

Total System Global Area 167772160 bytes

Fixed Size 1218316 bytes

Variable Size 67111156 bytes

Database Buffers 96468992 bytes

Redo Buffers 2973696 bytes

Database mounted.

ORA-01157: cannot identify/lock data file 1 - see DBWR trace

file

ORA-01110: data file 1:

'/u01/app/oracle/oradata/cuug/cuug/system01.dbf'

3、从最近的备份中restore数据文件：

RMAN> restore database;

4、尝试打开数据库：

SQL> alter database open;

alter database open

ERROR at line 1:

ORA-01113: file 1 needs media recovery

ORA-01110: data file 1:

'/u01/app/oracle/oradata/cuug/cuug/system01.dbf'

5、对数据库进行recovery：

SQL> recover database;

注意：recovery 结束后，应该查看数据文件头的检查点号是否同步了。

6、打开数据库，检查数据的正确性。

＝＝＝＝＝＝＝＝＝＝＝＝＝

方式三、控制文件和所有的数据文件损坏

1、主机断电，导致所有的数据文件和控制文件损坏：

2、主机加电，尝试打开数据库：

SQL> startup

ORACLE instance started.

Total System Global Area 167772160 bytes

Fixed Size 1218316 bytes

Variable Size 67111156 bytes

Database Buffers 96468992 bytes

Redo Buffers 2973696 bytes

ORA-00205: error in identifying control file, check alert log for

more info

打开失败，数据库启动的nomount状态。

3、把备份的控制文件restore到目标位置：

cp /tmp/cotrol01.bk

/u01/app/oracle/oradata/cuug/cuug/control01.ctl

4、把数据库启动到mount状态：

5、使用rman restore所有的数据文件：

RMAN> restore database;

6、尝试打开数据库：

SQL> alter database open;

alter database open

ERROR at line 1:

ORA-01113: file 1 needs media recovery

ORA-01110: data file 1:

'/u01/app/oracle/oradata/cuug/cuug/system01.dbf'

7、对数据库进行recovery：

SQL> recover database;

ORA-00283: recovery session canceled due to errors

ORA-00314: log 3 of thread 1, expected sequence\# 46 doesn't match

ORA-00312: online log 3 thread 1:

'/u01/app/oracle/oradata/cuug/cuug/redo03.log'

恢复失败，因为使用的控制文件是旧的，无法识别最新的online redolog的序列号，无法做完全恢复。

8、重建控制文件，重建过程中，oracle会扫描redolog，获得最新的信息来更新当前的数据。

9、获得重建控制文件的语句：

SQL> alter database backup controlfile to

trace;

该语句被放在user\_dump\_dest参数指定的目录下。

10、重新启动实例到nomount状态：

11、执行重建控制文件的语句：

12、重建结束后，查看v$log视图，看当前的序列号是否更新：

SQL> select \* from v$Log;

13、再次对数据库进行完全恢复：

14、恢复结束后，打开数据库，验证数据正确性。

＝＝＝＝＝＝＝＝＝＝＝

方式四：未备份数据文件损坏

适合环境：要求从创建该数据文件开始，所有的归档日志都在

1、创建一个新的表空间：

SQL> create tablespace test datafile

'/u01/app/oracle/oradata/cuug/cuug/test01.dbf' size 20m;

2、创建新的表，并且放在新建的表空间：

SQL> create table scott.test22 tablespace test as

select \* from scott.emp;

3、主机断电，导致新建的数据文件损坏：

4、主机加电，尝试打开数据库：

SQL> startup

ORACLE instance started.

Total System Global Area 167772160 bytes

Fixed Size 1218316 bytes

Variable Size 67111156 bytes

Database Buffers 96468992 bytes

Redo Buffers 2973696 bytes

Database mounted.

ORA-01157: cannot identify/lock data file 7 - see DBWR trace

file

ORA-01110: data file 7:

'/u01/app/oracle/oradata/cuug/cuug/test01.dbf'

5、由于该数据文件没有备份，我们可以使用重建数据文件的方式进行：

SQL> alter database create datafile

'/u01/app/oracle/oradata/cuug/cuug/test01.dbf';

6、对数据文件进行recovery：

SQL> recover datafile

'/u01/app/oracle/oradata/cuug/cuug/test01.dbf';

7、尝试打开数据库：

SQL> alter database open;

Database altered.

8、检查数据的完整性：

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

不完全恢复方式：

1、基于cancel的不完全恢复

环境准备：

1、以scott用户对表进行insert操作，并且人为切换日志：

SQL> select count(\*) from test;

COUNT(\*)

\----------

1792

2、再次insert，并且commit，但是日志没有切换：

SQL> select count(\*) from test;

COUNT(\*)

\----------

3584

3、主机断电，导致所有的online redo log损坏：

SQL> shutdown abort

ORACLE instance shut down

rm -f /u01/app/oracle/oradata/cuug/cuug/\*.log

4、尝试打开数据库：

SQL> startup

ORACLE instance started.

Total System Global Area 167772160 bytes

Fixed Size 1218316 bytes

Variable Size 67111156 bytes

Database Buffers 96468992 bytes

Redo Buffers 2973696 bytes

Database mounted.

ORA-00313: open failed for members of log group 3 of thread 1

ORA-00312: online log 3 thread 1:

'/u01/app/oracle/oradata/cuug/cuug/redo03.log'

ORA-27037: unable to obtain file status

Linux Error: 2: No such file or directory

Additional information: 3

此时，数据库无法打开，因为无法进行实例恢复。

5、对数据库进行不完全恢复，把所有的数据文件，restore到以前的某个状态：

RMAN> restore database;

6、对数据库进行不完全recovery：

SQL> recover database until cancel;

7、使用resetlogs打开数据库：

SQL> alter database open RESETLOGS;

8、验证数据的完整性：

总结：从oracle

10g开始，用resetlog打开数据库后，不需要全库备份，以前的备份加上现在的归档日志，还可以做完全恢复。

＝＝＝

2、基于时间点的不完全恢复：

适合环境：某个关键的表被意外删除。

1、记录一下表被删除的时间点

SQL> select to\_char(sysdate,'yyyy-mm-dd hh24:mi:ss')

from dual;

TO\_CHAR(SYSDATE,'YY

\-------------------

2011-08-21 08:50:10

2、把test表给drop掉，新建立一个表：

SQL> drop table test purge;

Table dropped.

SQL>

SQL> create table test\_after as select \* from

emp;

Table created.

3、把所有的数据文件restore到以前的某个状态，然后做时间点恢复：

SQL> recover database until time '2011-08-21

08:50:10';

4、打开数据库，验证test表是否恢复成功：

SQL> alter database open resetlogs;

Database altered.

oracle查询备份路径,Oracle备份与恢复案例

发表评论取消回复

还没有评论，来说两句吧...

相关阅读

相关 Oracle备份恢复：数据丢失与应急恢复案例

相关 Oracle数据库备份恢复难题：完整备份、增量备份与恢复

相关 Oracle数据库备份恢复失败：案例与对策

相关 Oracle数据库备份恢复失败案例

相关 oracle 冷备份恢复

相关 Oracle数据库备份与恢复 - 增量备份

相关 oracle查询备份路径,Oracle备份与恢复案例

相关 oracle数据备份与恢复

相关 Oracle 备份恢复详

相关 oracle逻辑备份与恢复