快捷搜索:

【Oracle备份恢复】3、数据库恢复案例(2)

案例2:非归档模式下一个或多个数据文件毁坏,其它文件都齐全

备份规划: OS冷备份

l开启数据库&改为非归档模式

第二篇已经先容了归档和非归档包括若何开启和关闭归档,什么?忘了?算了,照样在小复习下吧!!!更具体的还请同砚们回首第二篇内容。

SQL> startup mount;

ORACLE instance started.

Total System Global Area845348864 bytes

Fixed Size1339796 bytes

Variable Size494931564 bytes

Database Buffers343932928 bytes

Redo Buffers5144576 bytes

Database mounted.

SQL> alter database noarchivelog;

Database altered.

SQL> archive log list;

Database log modeNo Archive Mode

Automatic archivalDisabled

Archive destinationUSE_DB_RECOVERY_FILE_DEST

Oldest online log sequence6

Current log sequence8

l关闭数据库&备份文件

SQL> shutdown immediate

[oracle@elvis elvis]$ cp users01.dbf bak/

由于模拟的数据都是存储在users表空间中,所以为了方便起见,这备份这一个数据文件

l开启数据库&模拟数据

与上一个案例相同,在做一遍吧!一路加深印象

SQL> startup

ORACLE instance started.

Total System Global Area845348864 bytes

Fixed Size1339796 bytes

Variable Size494931564 bytes

Database Buffers343932928 bytes

Redo Buffers5144576 bytes

Database mounted.

Database opened.

SQL> select * from test;

no rows selected

SQL> insert into test values(1,dbms_flashback.get_system_change_number);

1 row created.

SQL> commit;

Commit complete.

SQL> alter system switch logfile;

System altered.

重复上述步骤,终极插入数据如下:

SQL> select * from test

IDSCN

---------- ----------

1947010

2947042

3947054

4947063

5947071--没commit

l模拟毁坏users数据文件

[oracle@elvis elvis]$ rm -f users01.dbf

[oracle@elvis elvis]$ ll

total 1911316

drwxr-xr-x 2 oracle oinstall4096 Oct2 19:32 bak

-rw-r----- 1 oracle oinstall9748480 Oct2 19:39 control01.ctl

drwxr-x--- 4 oracle oinstall4096 Oct1 13:49 ELVIS

-rw-r----- 1 oracle oinstall52429312 Oct2 19:39 redo01.log

-rw-r----- 1 oracle oinstall52429312 Oct2 19:36 redo02.log

-rw-r----- 1 oracle oinstall52429312 Oct2 19:36 redo03.log

-rw-r----- 1 oracle oinstall 629153792 Oct2 19:36 sysaux01.dbf

-rw-r----- 1 oracle oinstall 734011392 Oct2 19:36 system01.dbf

-rw-r----- 1 oracle oinstall71311360 Sep 30 11:06 temp01.dbf

-rw-r----- 1 oracle oinstall 408952832 Oct2 19:36 undotbs01.dbf

然后关闭数据库

SQL> shutdown abort

ORACLE instance shut down.

l开启数据库

SQL> startup

ORACLE instance started.

Total System Global Area845348864 bytes

Fixed Size1339796 bytes

Variable Size494931564 bytes

Database Buffers343932928 bytes

Redo Buffers5144576 bytes

Database mounted.

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

ORA-01110: data file 4: '/u01/app/oracle/oradata/elvis/users01.dbf'

l数据文件的规复

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

FILE# CHECKPOINT_CHANGE#

---------- ------------------

1947062

2947062

3947062

4947062

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

FILE# CHECKPOINT_CHANGE#

---------- ------------------

1947062

2947062

3947062

40

[oracle@elvis bak]$ cp users01.dbf ..

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

FILE# CHECKPOINT_CHANGE#

---------- ------------------

1947062

2947062

3947062

4946879--这个便是刚还原回来的数据文件的文件头

由于是在非归档模式,以是规复只能是不完全规复

还有这个参数必然要留意,这个参数是个暗藏参数,之前我就由于这个参数困扰了我好长光阴

SQL> show parameter _allow_

NAMETYPEVALUE

------------------------------------ ----------- ------------------------------

_allow_resetlogs_corruptionbooleanTRUE

设置这个参数

--alter system _allow_resetlogs_corruption=true scope=spfile;

重启后生效。

这个参数必然要设置为true,据君三思先容,这个参数可以在resetlogs的时刻跳过一些同等性的反省。

SQL> recover database until cancel;

ORA-00279: change 946879 generated at 10/02/2012 19:31:02 needed for thread 1

ORA-00289: suggestion :

/u01/app/oracle/flash_recovery_area/ELVIS/archivelog/2012_10_02/o1_mf_1_9_%u_.ar

c

ORA-00280: change 946879 for thread 1 is in sequence #9

Specify log: {=suggested | filename | AUTO | CANCEL}

cancel

ORA-10879: error signaled in parallel recovery slave

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below

ORA-01194: file 1 needs more recovery to be consistent

ORA-01110: data file 1: '/u01/app/oracle/oradata/elvis/system01.dbf'

SQL> alter database open resetlogs;

alter database open resetlogs

*

ERROR at line 1:

ORA-01092: ORACLE instance terminated. Disconnection forced

ORA-00600: internal error code, arguments: [2662], [0], [946887], [0],

[946906], [4194432], [], [], [], [], [], []

Process ID: 5744

Session ID: 125 Serial number: 5

但你会发明报了一个ora-00600差错,先不管这个,先退出sqlplus然后从新连接在正常开启数据库

SQL> startup

ORACLE instance started.

Total System Global Area845348864 bytes

Fixed Size1339796 bytes

Variable Size494931564 bytes

Database Buffers343932928 bytes

Redo Buffers5144576 bytes

Database mounted.

Database opened.

SQL> select * from test;--数据整个损掉

no rows selected

总结:这种非归档的模式在OLTP中是异常罕有,在我认知里可能只有在OLAP中因为数据量异常宏大年夜,归档的数据文件也异常可不雅,为了削减空间的压力,会选择非归档,但有几个条件前提:

1.数据不是分外紧张,容许少量损掉

2.表空间都只为只读表空间,只为报表所用

。。。。。。。。

可能处于这些环境之下,这个模式可用,也便是说详细环境得详细阐发,根据营业的需求而架设规划。

在来谈谈刚才的ora-00600差错,有关这差错请参考eygle大年夜师的文章:

http://www.eygle.com/archives/2005/10/ora00600_2262ii.html

对付这个模式下的规复的善后处置惩罚,以下内容引自“君三思《涂抹三思》一书”:

这种规复要领(非归档为了维持scn同等只能resetlogs了)是没有法子中的法子,经由过程这种要领规复,有可能会导致数据库中数据的不同等,如已提交的数据未写入数据文件,而未提交的数据倒是被写入了数据文件。纵然数据库被打开,也能够造访此中的表和数据,也只是看起来正常,假如你留意关注数据库的Alert文件(我的11g不用找告警文件内容,直接就报出来差错了,这预计便是版本不合结果也不合吧!!!)ORA-00600差错。是以,假如数据库能够顺利打开,强烈建议顿时经由过程EXPORT逻辑导出的要领履行一次FULL EXPORT。然后新建数据库,再经由过程IMPORT导入之前导出的二进制文件。

转:http://blog.csdn.net/elvis_dataguru/article/details/8045002

您可能还会对下面的文章感兴趣: