oracle-SYSTEM表空间的备份与恢复

oracle-SYSTEM表空间的备份与恢复,第1张

概述oracle-SYSTEM表空间备份恢复 这一篇在介绍备份及恢复数据文件的方法时,以备份和重做日志(包括归档日志和在线日志)没有丢失为前提 所谓关键数据文件:system表空间的数据文件与参数undo_tablespace指向的自动撤销表空间的数据文件(undo_tablespace数据文件)。 它们的损坏(整体或局部)会导致SQL命令执行失败、用户session强制断开、sys用户无法登陆、

oracle-SYstem表空间的备份与恢复

这一篇在介绍备份及恢复数据文件的方法时,以备份和重做日志(包括归档日志和在线日志)没有丢失为前提

所谓关键数据文件:system表空间的数据文件与参数undo_tablespace指向的自动撤销表空间的数据文件(undo_tablespace数据文件)。

它们的损坏(整体或局部)会导致sql命令执行失败、用户session强制断开、sys用户无法登陆、甚至整个实例崩溃。

sql> select file_ID,file_name from dba_data_files where tablespace_name in (SYstem,(select value from v$parameter where name=undo_tablespace));   file_ID file_name---------- --------------------------------------------------3 /u01/app/oracle/oradata/orcl/undotbs01.dbf1 /u01/app/oracle/oradata/orcl/system01.dbf

9.1 关键数据文件损坏的后果

9.1.1 system表空间数据文件损坏

SYstem表空间内部保存两类重要数据:oracle数据库的系统表(数据字典),是数据库正常运行的基本保障:以及名为SYS.SYstem的撤销段(undo segment)系统回滚段。

讨论情况:文件丢失、文件头损坏、数据库字段损坏及SYS.SYstem撤销段损坏

--1 若system01.dbf文件丢失或无法访问,startup启动到mount状态--2 若system01.dbf文件头损坏,运行时检查点发起后实例崩溃,startup启动到mount状态--3 如果数据字典损坏,数据库内的对象定义系统、名称解析系统、用户账号系统及权限管理都将崩溃。若损坏发生在实例运行时,通常会导致sql命令产生ORA-00604的错误;若损坏发生在实例启动时,启动流程不一定会终止,但是alert log中会有ORA-01578和ORA-01110错误。--4 system01.dbf 文件名中为SYS.SYstem撤销段头部损坏,在启动时startup实例会强制关闭,必须使用startup mount才能进入mount状态。

以下是一些各种是system01.dbf文件损坏的场景

场景1:启动数据库是发现system01.dbf文件丢失,启动中断

sql> startupORA-01157: cannot IDentify/lock data file 1 -see DBWR trace fileORA-01110:data file 1 : ‘/u01/app/oracle/oradata/orcl/system01.dbf’

场景2:启动数据库发现system01.dbf文件头部损坏,启动中断

sql> startupORACLE instance started.Total System Global Area  784998400 bytesFixed Size            2257352 bytesVariable Size          511708728 bytesDatabase Buffers      264241152 bytesRedo Buffers            6791168 bytesDatabase mounted.ORA-01122: database file 1 Failed verification checkORA-01110: data file 1: /u01/app/oracle/oradata/orcl/system01.dbfORA-01210: data file header is media corrupt

场景3:数据库运行时,system01.dbf文件中保存用户账号信息的数据字典SYS.USER$的数据块损坏,使用后登录失败

$ sqlplus test/***ERROR:ORA-00604: error occurred at recursive sql level 1ORA-01578: ORACLE data block corrupted (file # 1,block # 213)ORA-01110: data file 1: ‘/u01/app/oracle/oradata/orcl/system01.dbf‘

场景4:数据库运行时system01.dbf文件中的数据字典SYS.TAB$数据块损坏

sql> select * from test.t1;ERROR at line 1:ORA-00604: error occurred at recursive sql level 1ORA-01578: ORACLE data block corrupted (file # 1,block # 83226)ORA-01110: data file 1: /u01/app/oracle/oradata/orcl/system01.dbf

场景5:数据字典SYS.PROCEDURE$中数据块损坏,任何createdroprename都报错

sql> create table test.t2 (ID number,name varchar2(20)) tablespace test;ERROR at line 1:ORA-00604: error occurred at recursive sql level 1ORA-01578: ORACLE data block corrupted (file # 1,block # 89226)ORA-01110: data file 1: /u01/app/oracle/oradata/orcl/system01.dbf

场景6SYS.SYstem撤销段头部损坏,实例被强制中断

sql> startupORA-01092: ORACLE instance terminated,disconnection forcedORA-01578: ORACLE data block corrupted (file # 1,block # 128)ORA-01110: data file 1: /u01/app/oracle/oradata/orcl/system01.dbf

场景7SYS.SYstem撤销段与undo_tablespace表空间撤销段同时损坏,执行DDL时候报错

sql> drop table test.t1;ORA-00603 : ORACLE server session terminated by Fatal error

场景8:运行时,system01.dbfundo_tablespace数据文件头部损坏,检查点无法顺利完成,在alter log

ORA-01243: system tablespace file suffered media failureORA-01122: database file 1 Failed verification check

9.1.2 undo_tablespace数据文件损坏

undo_tablespace数据文件是undotbs01.dbf,它用来保存所有的变更类命令(DDL\DML)所产生的撤销数据(undo data

--1 undotbs01.dbf文件丢失无法访问,startup启动到mount状态--2 undotbs01.dbf文件头损坏,startup启动到mount,运行时检查点发起后实例崩溃--3 若表空间中的某些块损坏,DML可能失败,若全部损坏,DML肯定全部失败
sql> select name from v$rollname where name<> SYstem;name------------------------------_SYSSMU1_1925302723$_SYSSMU2_2273571325$_SYSSMU3_798971445$_SYSSMU4_2493343136$_SYSSMU5_44098047$_SYSSMU6_4194993272$_SYSSMU7_3978436573$_SYSSMU8_3643869769$_SYSSMU9_4157155965$_SYSSMU10_1224346732$10 rows selected.

场景1:运行时,undotbs01.dbf头损坏(3号文件,160号数据块)

sql> update test.t1 set name=’yhq’ where ID=1;ERROR at line 1:ORA-00603: ORACLE server session terminated by Fatal errorORA-01578: ORACLE data block corrupted (file # 3,block # 160)ORA-01110: data file 3: ‘/u01/app/oracle/oradata/orcl/undotbs01.dbf’

场景2:启动时,undotbs01.dbf文件头部损坏

sql> startupORA-01092: ORACLE instance terminated,disconnection forcedORA-01578: ORACLE data block corrupted (file # 3,block # 128)ORA-01110: data file 3: /u01/app/oracle/oradata/orcl/undotbs01.dbf
9.2 备份

使用RMANbackup databasebackup datafilebackup tablespace都可以备份数据文件

RMAN> backup as backupset tablespace system,undotbs1;Starting backup at 18-Jul-19using channel ORA_disK_1channel ORA_disK_1: starting full datafile backup setchannel ORA_disK_1: specifying datafile(s) in backup setinput datafile file number=00003 name=/u01/app/oracle/oradata/orcl/undotbs01.dbfinput datafile file number=00001 name=/u01/app/oracle/oradata/orcl/system01.dbfchannel ORA_disK_1: starting pIEce 1 at 18-Jul-19channel ORA_disK_1: finished pIEce 1 at 18-Jul-19pIEce handle=/u01/app/oracle/fra/ORCL/backupset/2019_07_18/o1_mf_nnndf_TAG20190718T111222_glzrwp9z_.bkp tag=TAG20190718T111222 comment=NONEchannel ORA_disK_1: backup set complete,elapsed time: 00:00:03Finished backup at 18-Jul-19Starting Control file and SPfile autobackup at 18-Jul-19pIEce handle=/u01/app/oracle/fra/ORCL/autobackup/2019_07_18/o1_mf_s_1013944345_glzrwsd5_.bkp comment=NONEFinished Control file and SPfile autobackup at 18-Jul-19

创建镜像复制

RMAN> run {allocate channel c1 device type disk;allocate channel c2 device type disk;backup as copy(datafile /u01/app/oracle/oradata/orcl/system01.dbf channel c1)(datafile /u01/app/oracle/oradata/orcl/undotbs01.dbf channel c2)}

备份所有的数据文件

RMAN> run {allocate channel c1 device type disk;allocate channel c2 device type disk;allocate channel c3 device type disk;backup as copy database;}

运行以上RMAN命令时,确保在mount状态或open状态,open状态还需要启动归档模式。

9.3 恢复

恢复关键数据文件的核心步骤:db进入mount状态、从备份还原(restoreswitch)、使用增量备份或重做日志恢复(recover)、打开db

在整个介质恢复流程中(restorerecover),db始终处于mount状态,而不是open状态,在恢复完成之前db不能接受应用的连接。

9.3.1 恢复前的准备

要恢复数据文件,先要启动到mount阶段,不然就需要搞定参数文件和控制文件。

显示启动到mount阶段:startup mount

如果发现问题时实例没有关闭,用:shutdown abort停止实例

也有可能数据字典的损坏甚至SYS不能通过sqlplusRMAN登录的情况

$ sqlplus / as sysdbaERROR:ORA-01075:you are currently logged on

登录不报错,连接到空闲实例,但实例还存在

sql> sqlplus / as sysdbasql> select * from v$database;ERROR at line 1 :ORA-01012: not logged onProcess ID: 0Session ID: 0 Serial number :0

使用RMAN登录也报错

$ rman target /RMAN-00554RMAN-04005: error from target databaseORA-00604: error occurred at recursive sql level 1ORA-01578: ORACLE data block corrupted (file # 1,block #857)ORA-01110: data file 1: /u01/app/oracle/oradata/orcl/system01.dbf

此时必须终止实例才能开始恢复 *** 作,比如将后台进程SMON 杀死,另一个后台进程PMON

$ kill -9 `ps aux |grep ora_smon_orcl |grep -v grep | awk {print }`

9.3.2 恢复流程

恢复 *** 作必须在mount下进行,具体步骤:

--1 如果实例尚未崩溃,使用shutdown abort或者 *** 作系统的kill将实例关闭--2 执行startup mount将实例启动到mount状态--3 使用RMAN执行restore或switch还原损坏的关键数据文件--4 使用RMAN执行recover database 利用归档日志和在线日志恢复数据文件--5 执行alter database open 打开数据库

第一步确保实例已经停止,可以通过RMAN的一个运行块完成,比如恢复undotbs1表空间的数据文件

RMAN> run {startup mount;restore tablespace undotbs1;recover database;alter database open;}

再比如恢复1号数据文件

RMAN> run {startup mount;restore datafile 1;recover database;alter database open;}

当数据文件的镜像复制处于磁盘上时,可用switch命令取代restore将控制文件中的数据文件名立即换成镜像复制名,文件越大,还原 *** 作节省的时间就越多。

首先启动到mount状态

RMAN> startup mount;

查看镜像复制信息和生成时间

RMAN> List datafilecopy all;RMAN> run {switch datafile 1 to datafilecopy/u01/app/oracle/fra/ORCL/autobackup/2019_07_18/o1_mf_s__glzrwsd5_.dbf;recover database;alter database open;}

现在查看1号数据文件的路径将是镜像复制

sql> select name from v$datafile where file#=1;name/u01/app/oracle/fra/ORCL/autobackup/2019_07_18/o1_mf_s__glzrwsd5_.dbf

而查看镜像复制的路径将是原来的数据文件

RMAN> List copy of tablespace system;/u01/app/oracle/oradata/orcl/system01.dbf

如果原来数据文件已经是损坏的,此镜像复制当然也是损坏的,dba需要考虑这样的复制是否有意义,所以在使用switch之后要执行valIDate

RMAN> valIDate datafilecopy all;

如有错误,可以删除

RMAN> delete noprompt datafilecopy 44;RMAN> backup as copy datafile 1 format ‘/u01/app/oracle/oradata/orcl/system01.dbf’;

将来不论是主动或被动,利用switchrecover都能再次切换回原路径  

总结

以上是内存溢出为你收集整理的oracle-SYSTEM表空间的备份与恢复全部内容,希望文章能够帮你解决oracle-SYSTEM表空间的备份与恢复所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/1161179.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-06-01
下一篇 2022-06-01

发表评论

登录后才能评论

评论列表(0条)

保存