Oracle备份失败处理，看这一篇就够了！

作者：IT邦德
中国DBA联盟(ACDU)成员，10余年DBA工作经验，
Oracle、PostgreSQL ACE
CSDN博客专家及B站知名UP主，全网粉丝10万+
擅长主流Oracle、MySQL、PG、高斯及Greenplum备份恢复，
安装迁移，性能优化、故障应急处理

前言

因为最近故障频发，这里带大家盘点生产运维中Oracle备份失败的一些原因

1.RMAN配置错误

1.1 故障现象

客户反馈备份失败，因为使用第三方的备份软件，从备份的报错信息来看，报ORA-00234: error in identifying or opening snapshot or copy control file

1.2 故障排查

首先排查是否是由于带库引起备份问题，
尝试直接在磁盘上备份，执行如下命令
run {
allocate channel c1 type disk;
backup current controlfile format '/tmp/db_ctl_%d_%T_%s_%p.bak'; 
release channel c1;
}

执行后发现报同样报错，该报错指向控制文件快照文件
查询 RMAN 相关文件快照路径
查看发现控制文件快照路径为ASM 磁盘组，
未写文件名，怀疑是未写文件名引起

1.3 故障处理

修改控制文件快照路径
RMAN> CONFIGURE SNAPSHOT
CONTROLFILE NAME TO ‘+oradata/snapcf_orcl.f’;
调整后发现备份恢复正常

注意:
1.控制文件的快照文件必须能够被所有节点的数据实例访问到，
并且必须放在共享的位置。否则，使用RMAN进行备份控制文件的时候会报错
2.建议对参数调整后，建议经各方面测试验证无误后再修改

2.物理删除归档

2.1 故障现象

根据客户反馈，因为岁修产生了大量的归档，手动物理删除归档后，备份就失败，
报错如下：ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory

2.2 故障处理

进行归档日志的校验；
RMAN>crosscheck archivelog all;
删除失效的归档日志；
RMAN>delete expired archivelog all;

2.3 故障分析

数据库的archivelog文件被手工删除，但是控制文件仍然记录了归档日志的备份信息，rman做归档备份时还是要备份被无意删除的文件，但文件已经被物理删除，磁盘上找不到就会报错，通过rman crosscheck archivelog all也可以看到文件已经失效，所以备份之前先将归档文件从控制文件中删除，然后备份就会成功；

–正确删除归档的命令应该是
1.删除指定日期前日志
delete archivelog all completed before ‘SYSDATE - 3’;
2.删除log sequence为36及36之前的所有归档日志
delete archivelog until sequence 36;
3.删除所有归档
delete noprompt archivelog all;

3.Oracle坏快

3.1 故障现象

使用的是第三方的备份软件，近期备份一直失败，造成归档无法删除，归档磁盘空间岌岌可危，从备份软件的日志来看，抛出了如下的报错
ORA-19566: exceeded limit of 0 corrupt blocks for file
+INDEX/ods_hist_idx_tbs_07.dbf

3.2 故障分析

ORA-19566报错来看，基本定位为坏快造成的，
确认当前使用的数据库为Oracle 11.2.0.4.0 RAC，
通过以下查询确认坏快信息

--1、查询oracle坏快
select * from v$database_block_corruption;

--2.分析Oracle坏块对应的对象内容
SELECT e.owner, e.segment_type, e.segment_name, e.partition_name, c.file#
       , greatest(e.block_id, c.block#) corr_start_block#
       , least(e.block_id+e.blocks-1, c.block#+c.blocks-1) corr_end_block#
       , least(e.block_id+e.blocks-1, c.block#+c.blocks-1)
         - greatest(e.block_id, c.block#) + 1 blocks_corrupted
       , null description
    FROM dba_extents e, v$database_block_corruption c
   WHERE e.file_id = c.file#
     AND e.block_id <= c.block# + c.blocks - 1
     AND e.block_id + e.blocks - 1 >= c.block#
  UNION
  SELECT s.owner, s.segment_type, s.segment_name, s.partition_name, c.file#
       , header_block corr_start_block#
       , header_block corr_end_block#
       , 1 blocks_corrupted
       , 'Segment Header' description
    FROM dba_segments s, v$database_block_corruption c
   WHERE s.header_file = c.file#
     AND s.header_block between c.block# and c.block# + c.blocks - 1
  UNION
  SELECT null owner, null segment_type, null segment_name, null partition_name, c.file#
       , greatest(f.block_id, c.block#) corr_start_block#
       , least(f.block_id+f.blocks-1, c.block#+c.blocks-1) corr_end_block#
       , least(f.block_id+f.blocks-1, c.block#+c.blocks-1)
         - greatest(f.block_id, c.block#) + 1 blocks_corrupted
       , 'Free Block' description
    FROM dba_free_space f, v$database_block_corruption c
   WHERE f.file_id = c.file#
     AND f.block_id <= c.block# + c.blocks - 1
     AND f.block_id + f.blocks - 1 >= c.block#
  order by file#, corr_start_block#;

3.3 故障处理

Oracle建议的一些最佳实践经验如下：
1.完整记录原始的坏块出错信息，以及遇到坏块的应用模块信息。
2.将首次遇到坏块的几小时至当前时间的log信息抽取出来，
单独保存为一个文件进行重点分析。
3.将log文件中涉及的trace 文件进行保存。
4.了解硬件和操作系统级是否存在报错信息。
5.查询硬件和存储是否采用异步I/O（ASYNC I/O），
磁盘快速写（Fast Write Disk）等技术。
6.查询当前Oracle备份信息，备份时间、备份类型、备份地点等。
7.查询数据库是否是归档或非归档模式。

坏块分类分为2种
物理坏块：也可以称为介质坏块,指的是块格式本身是坏的，块内的数据没有任何意义。
逻辑坏块：指的是块内的数据在逻辑是存在问题。比如说索引块的索引值没有按从小到大排列。
物理坏块一般是由于内存问题、OS问题、IO子系统问题和硬件引起，
逻辑坏块一般是是由于Oracle Bug等原因引起

4.数据库结构错误

4.1 故障现象

客户反馈备份一直失败，因为用的磁带库备份，
所以从alert日志中看到有如下报错
ERROR at line 1:
ORA-01157: cannot identify/lock data file 34 - see DBWR trace file
ORA-01110: data file 34: ‘/u01/app/oracle/product/19.0.0/dbhome_1/dbs/ptho_ts.dbf’

4.2 故障分析

select file_id,tablespace_name,file_name,status from dba_data_files;
通过查询发现，新建的一个表空间建到了本地磁盘，
导致节点2无法发问，备份校验不通过导致备份失败

4.3 故障处理

offline数据文件的方法
sql>alter database datafile 34 offline;
rman> backup as copy datafile 34 format ‘+data’;
rman> switch datafile 34 to copy;
sql>recover datafile 34;
sql>alter database datafile 34 online;

5.总结

数据库可能面临硬件故障、人为错误、恶意攻击、自然灾害等多种潜在风险。如果没有恰当的备份策略，这些事件可能导致数据丢失，从而对业务造成严重影响。所以一定要确保备份的成功，备份恢复演练也必不可少。