3 XX网Oracle数据库SYSTEM表空间文件坏块的解决办法
故障现象:
NetBackup备份出错,日志如下:
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03009: failure of backup command on ch01 channel at 06/15/2005 02:28:44 ORA-19566: 超出损坏块限制 0 (文件 /u01/app/oradata/unicom/system01.dbf) |
故障分析:
由于事前发生过别的表空间(cookdbs:/u01/app/oradata/unicom/cokdbs.dbf)也有坏块的情况,根据李智他们的建议,使用迁移数据后删除表空间的办法解决(仅适用于普通表空间)。
这是查询该表空间上的表和索引对象的一个脚本:
GXdb% more query.sql conn /as sysdba col owner for a25 col segment_name for a40 spool table.log select distinct OWNER,SEGMENT_NAME from dba_extents where TABLESPACE_NAME=’COOKDB’ and SEGMENT_TYPE=’TABLE’; spool off spool index.log select distinct OWNER,SEGMENT_NAME from dba_extents where TABLESPACE_NAME=’COOKDB’ and SEGMENT_TYPE=’INDEX’; spool off exit |
查询完毕后,使用一个迁移的脚本迁移到新的表空间:
GXdb% more move.sh #!/bin/ksh sqlplus /nolog @query.sql NEWTBS=”cookdbs1″ echo “conn /as sysdba” > move.sql for TNAME in `cat table.log | awk ’ /^COOKDB/ {print $2} ’` do echo “alter table cookdb.$TNAME move tablespace $NEWTBS;” >>move.sql done for INAME in `cat index.log | awk ’ /^COOKDB/ {print $2} ’` do echo “alter INDEX cookdb.$INAME REBUILD TABLESPACE $NEWTBS;” >>move.sql done echo “exit” >>move.sql sqlplus /nolog @move.sql |
本次经过检查,发现包括有System在内的四个表空间的四个数据文件有坏块。为了能使用NetBackup备份,对NetBackup脚本做以下修改(对相应的数据文件设置maxcorrupt):
run { allocate channel ch00 type ’sbt_tape’; set maxcorrupt for datafile 1,27,28,44 to 10; backup 。。。。。。 release channel ch00; } |
如果有归档日志没有丢失,都备份过,可以使用rman的blockrecover来修复文件的坏块,例如:
run { allocate channel ch00 type ’sbt_tape’; blockrecover datafile 27 block 302089,302090,332823,332824,332825,332826; blockrecover datafile 28 block 340846,340847,340848,340849; blockrecover datafile 44 block 380381,380382,380383,380384,380405,380406,380407,380408; blockrecover datafile 1 block 1703064,1703065,1703066,1703067,1703088,1703089,1703090,1703091; release channel ch00; } |
但是中间由于备份失败,本地维护删除过归档日志。此方法不适用。
本次由于有SYSTEM表空间,不同于普通用户表空间,它有自己的特殊性。所以有些问题的解决方法也不尽相同。经多方探讨协商(Oracle India engineer、项目经理、本地维护、开发部门和系统工程部经理),总结了以下处理办法:
解决SYSTEM表空间文件坏块的方法是导出全库数据,删除数据库,重建数据库,导入全库数据。具体的操纵步骤,经过讨论,见如下:主要是考虑到优化可以在线进行,也需要在线进行,还考虑到优化的万一出错性,既便出错至少还可以恢复到原始状态,如果优化没有成功,再做导出导入也不能恢复到初始状态。所以就先做导出导入工作再做优化处理。步骤是:
1. 导出整个数据库(数据库在线),参考命令:exp system/manager
file=/oraclebak/unicomdbfull.dmp full=Y log=/oraclebak/unicomfull.log
2. 备份配置文件 cp $ORACLE_HOME/dbs/* /Oraclebak,记录数据库名及实例名,参考字典视图V$DATABASE,V$INSTANCE
3. 删除数据库DBCA(/u02/app/oracle/product/9.2.0.1/bin/dbca)图形化配置工具。注意:建议不要删除数据文件、重做日志文件和控制文件以及归档日志文件,处理方法是:一)就数据文件、重做日志文件和控制文件分别改名为xxx.bak.xxx文件,例如mv datafile001.dbf datafile001.bak.dbf ;二)就归档日志文件,只改名归档日志文件所在的目录名即可,例如mv archivedir archivedirbak。要参考的数据字典视图有V$DATAFILE、V$LOGFILE、V$CONTROLFILE和archive log list 参数
4. 重建数据库DBCA(/u02/app/oracle/product/9.2.0.1/bin/dbca)图形化配置工具,
5. 导入整个数据库,imp system/unicom@unicom full=y ignore=y file=xxx.dmp log=yyy.log
6. 启动数据库,严格测试。
dbv file= /u02/app/oracle/oradata/unicom/system01.dbf blocksize=8192检查还有没有坏块。
7. 使用3.2SQL脚本检查表空间情况.
4 一个使用Oracle归档日志恢复数据库的案例
案例环境:XX网Oracle 816数据库。
需求描述:
备份主机(装有oracle)上备份了7月13日的数据,但是主数据库服务器当前日期是7月15日。为了把备份主机上的库跟主数据库服务器同步,使用归档日志把7月13日的库前滚到7月15日。
处理步骤:
a) 备份备份主机上的控制文件,然后把主用数据库的最新控制文件备份并拷贝到备份主机相应目录
备份控制文件的方法:
sqlplus /nolog<<EOF connect internal alter database backup controlfile to ’${BACKUP_DIR}/controlfile.bkp’; alter database backup controlfile to trace; EOF |
b) 拷贝主库的归档日志到备份数据库的归档日志目录(这个前滚操作需要从13号到15号的归档日志完整,若备份数据库的归档日志目录不知道,可以从参数文件中看
c) 启动数据库到mount状态,使用recover database前滚数据库
SQL> startup restrict mount pfile=”${ORACLE_BASE}/admin/sdh21/pfile/init${service_names}.ora” SQL> recover database using backup controlfile: |
选择AUTO模式
d) 如果到了最后一个日志它还需要前滚,此时可以在主库上把当前redolog切换,然后把产生的归档继续拷贝到备份主机,继续前滚。
e) 前滚完成之后,它可能还继续要求下一个归档日志,此时可以CANCEL
f) 使用reselogs选项打开数据库
SQL> alter database open resetlogs; |
注意:如果打开时报错可能是还需要把日志继续前滚,可重复使用recover database命令
5 Oracle 补丁p3948480_9206_SOLARIS64.zip的安装步骤
升级说明:
是从Oracle 9.2.0.1.0升级到9.2.0.6.0,解决一系列bug问题。
安装步骤:
解压文件包 %unzip p3948480_9206_SOLARIS64.zip %cd Disk1 停掉数据库 sql>shutdown immediate 启动安装程序 %./runInstaller 执行catpatch.sql脚本 %sqlplus /nolog SQL>conn / as sysdba SQL> SPOOL patch.log SQL> startup migrate; SQL>@?/rdbms/admin/catpatch.sql //执行catpatch.sql脚本 SQL> SPOOL OFF 执行utlrp.sql脚本 SQL> shutdown SQL>startup SQL>@?/rdbms/admin/utlrp.sql //执行utlrp.sql脚本 验证 select comp_name,version from dba_registry; |
注意事项:
若不是在本地安装,指定X应用程序的所在主机。
Bourne, Bash, or Korn shell:
$ DISPLAY=local_host:0.0 ; export DISPLAY
C shell:
% setenv DISPLAY local_host:0.0
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号

TechTarget
官方微博

TechTarget中国
作者
相关推荐
-
控制合约 不再畏惧Oracle
许多公司都与Oracle有无限制授权协议,他们害怕离开这个协议,所以就证明他们在使用Oracle的软件,即使因为需求单独购买部分授权许可也可能总体是省钱的。
-
如何应对Oracle EBS实施中的六个挑战?
在18个月的时间里,Vitamix启动运行了Oracle电子商务套件(E-Business Suite,EBS),而且Vitamix还对诸如Oracle ATG Web Commerce等所有页面属性进行了重新整理,并实现了全球数据中心。
-
DBA支招:如何实现Oracle EBS 12.2.5升级
那些对于是否要将EBS进行升级持观望态度的Oracle数据库管理员们可以从一家研究公司获得一些启示。
-
Oracle的云产品“砸了自己脚”?
Sparc和Solaris都是Oracle云计划的一部分,但是硬件和支持人员的减少意味着本地Solaris和Sparc将变得更加稀少。