Oracle数据库 ORA-00273 错误分析和解决

📋 ORA-00273错误全面解析

1️⃣ 错误基本信息

• 错误代码：ORA-00273
• 错误消息：未记录介质恢复的登录信息
• 英文消息：media recovery not logged into database
• 错误类型：数据库恢复日志记录错误
• 影响范围：影响数据库恢复操作的跟踪和记录

2️⃣ 错误信息结构分析

ORA-00273错误信息组成：

• ORA-00273：错误代码标识
• 未记录介质恢复的登录信息：错误描述，表明介质恢复操作没有被正确记录到数据库日志中

3️⃣ 官方正式说明

错误原因

根据Oracle官方文档，ORA-00273错误在以下情况发生：

主要原因：

• 在介质恢复过程中，恢复会话的信息未能正确记录到数据库的控制文件或数据字典中
• 恢复操作与数据库实例之间的会话跟踪信息丢失或损坏
• 在恢复过程中发生了会话中断或实例异常
• 控制文件与数据文件之间的恢复状态信息不一致

技术背景：
Oracle数据库在介质恢复过程中会维护详细的恢复会话信息，包括恢复进度、应用的归档日志序列、恢复时间点等。这些信息被记录在控制文件和相关的数据字典视图中，用于跟踪恢复进度和确保恢复的完整性。

4️⃣ 通俗易懂的讲解

简单比喻

想象你在读一本很长的书，需要记录阅读进度：

• 介质恢复 = 从书的中断处继续阅读
• 恢复日志记录 = 在书签上记录你读到了哪一页
• ORA-00273 = 你发现书签不见了，不知道上次读到了哪里

虽然你记得大概的情节，但没有了精确的进度记录，无法确定从哪一页开始继续阅读。

实际含义

当数据库进行恢复操作时，需要精确记录恢复到了哪个时间点、应用了哪些日志文件。如果这个"进度记录"丢失或损坏了，数据库就无法确定恢复的状态，从而产生ORA-00273错误。

5️⃣ 相关原理深度解析

介质恢复的记录机制

恢复信息存储位置

• 控制文件：存储恢复的物理进度信息
• 数据文件头：包含检查点信息和恢复状态
• 内存结构：维护当前恢复会话的运行时信息
• 警报日志：记录恢复操作的详细日志

6️⃣ 错误触发场景

常见场景示例

1. 恢复过程中实例异常终止：

   -- 开始恢复操作
   RECOVER DATABASE;
   -- 在恢复过程中实例崩溃或服务器重启
   -- 重新启动后出现 ORA-00273
   

2. 恢复会话被意外中断：

   -- 在一个会话中开始恢复
   RECOVER DATABASE UNTIL TIME '2024-01-15 10:00:00';
   -- 会话被意外断开或取消
   -- 新会话中继续恢复时出现错误
   

3. 控制文件恢复后信息不一致：

   -- 使用备份的控制文件进行恢复
   RECOVER DATABASE USING BACKUP CONTROLFILE;
   -- 恢复信息与当前数据库状态不匹配
   -- ORA-00273: 未记录介质恢复的登录信息
   

4. Data Guard环境中的恢复问题：

   -- 在备用数据库上执行恢复
   ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;
   -- 网络中断或日志传输问题导致恢复状态丢失
   

7️⃣ 诊断与定位方法

检查恢复状态信息

-- 查看数据库恢复状态
SELECT * FROM v$recovery_status;

-- 检查数据文件恢复状态
SELECT file#, error, change#, time 
FROM v$recovery_file;

-- 查看恢复进度
SELECT * FROM v$recovery_progress;

-- 检查归档日志应用情况
SELECT thread#, sequence#, first_change#, next_change#
FROM v$archived_log 
WHERE applied = 'YES'
ORDER BY sequence# DESC;

检查控制文件和数据文件状态

-- 检查控制文件信息
SELECT type, records_total, records_used 
FROM v$controlfile_record_section 
WHERE type IN ('DATAFILE', 'LOG HISTORY');

-- 检查数据文件头信息
SELECT file#, checkpoint_change#, checkpoint_time, fuzzy
FROM v$datafile_header;

-- 查看数据库当前状态
SELECT name, open_mode, database_role, log_mode 
FROM v$database;

检查警报日志信息

-- 查找警报日志中的恢复相关错误
-- 在警报日志中搜索以下内容：
-- ORA-00273
-- Media Recovery Start
-- Media Recovery Complete
-- Media Recovery Failed

诊断步骤

1. 确认恢复上下文：检查是在什么操作中出现的错误
2. 验证恢复状态：查看当前的恢复进度和状态信息
3. 检查文件一致性：确认控制文件和数据文件的一致性
4. 分析会话信息：检查是否有恢复会话信息丢失
5. 查看错误日志：分析警报日志获取详细错误信息

8️⃣ 完整解决方案

方案一：重新启动恢复过程

-- 1. 取消当前可能存在的恢复会话
RECOVER CANCEL;

-- 2. 重新启动数据库到MOUNT状态（如果尚未挂载）
STARTUP MOUNT;

-- 3. 开始新的恢复会话
RECOVER DATABASE;

-- 4. 应用所有可用的归档日志
-- 当提示输入日志文件时，可以输入AUTO或直接按回车自动应用

-- 5. 恢复完成后打开数据库
ALTER DATABASE OPEN;

-- 6. 对于不完全恢复，可能需要RESETLOGS
ALTER DATABASE OPEN RESETLOGS;

方案二：基于时间点的不完全恢复

-- 1. 启动到MOUNT状态
STARTUP MOUNT;

-- 2. 执行基于时间点的恢复
RECOVER DATABASE UNTIL TIME '2024-01-15 10:00:00';

-- 3. 使用RESETLOGS打开数据库
ALTER DATABASE OPEN RESETLOGS;

-- 4. 立即执行完整备份
-- 不完全恢复后必须进行完整备份

方案三：使用备份控制文件的恢复

-- 1. 启动实例但不挂载数据库
STARTUP NOMOUNT;

-- 2. 还原备份的控制文件
-- 从备份中恢复控制文件

-- 3. 挂载数据库
ALTER DATABASE MOUNT;

-- 4. 开始恢复并指定使用备份的控制文件
RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;

-- 5. 当提示时，提供所需的归档日志
-- 输入AUTO尝试自动应用可用日志

-- 6. 取消恢复并使用RESETLOGS打开
ALTER DATABASE OPEN RESETLOGS;

方案四：Data Guard环境中的恢复

-- 1. 在备用数据库上取消当前恢复（如果存在）
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

-- 2. 检查归档日志差距
SELECT thread#, low_sequence#, high_sequence# 
FROM v$archive_gap;

-- 3. 从主数据库复制缺失的归档日志

-- 4. 在备用数据库上注册归档日志
ALTER DATABASE REGISTER PHYSICAL LOGFILE '/path/to/archive_log.rdo';

-- 5. 重新启动托管恢复
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

9️⃣ 实际案例演示

案例1：恢复会话中断后的处理

-- 场景：恢复过程中会话断开，重新连接后出现ORA-00273

-- 1. 检查当前数据库状态
SELECT name, open_mode FROM v$database;
-- 返回：MOUNTED

-- 2. 检查恢复状态
SELECT * FROM v$recovery_status;
-- 可能显示恢复状态异常或为空

-- 3. 取消任何挂起的恢复操作
RECOVER CANCEL;

-- 4. 重新开始恢复
RECOVER DATABASE;

-- 5. 自动应用可用归档日志
-- 在提示时输入 AUTO

-- 6. 恢复完成后打开数据库
ALTER DATABASE OPEN;

-- 如果是不完全恢复，使用：
-- ALTER DATABASE OPEN RESETLOGS;

案例2：使用RMAN进行恢复

-- 使用RMAN处理ORA-00273错误
-- 1. 连接到目标数据库
RMAN TARGET /

-- 2. 启动数据库到MOUNT状态
STARTUP MOUNT;

-- 3. 检查恢复所需的信息
LIST FAILURE;
ADVISE FAILURE;

-- 4. 执行恢复
RECOVER DATABASE;

-- 5. 验证恢复结果
VALIDATE DATABASE;

-- 6. 打开数据库
ALTER DATABASE OPEN;

案例3：处理控制文件不一致

-- 场景：控制文件与数据文件恢复状态不一致

-- 1. 检查数据文件头信息
SELECT file#, checkpoint_change#, fuzzy, error
FROM v$datafile_header;

-- 2. 如果发现不一致，可能需要还原数据文件
-- 使用RMAN还原所需的数据文件
RMAN> RESTORE DATAFILE 1,2,3;

-- 3. 开始恢复
RMAN> RECOVER DATABASE;

-- 4. 打开数据库
RMAN> ALTER DATABASE OPEN;

🔟 相关联的其他ORA错误

ORA-00274：非法恢复选项

-- 恢复命令中包含了非法或不支持的选项

ORA-00275：已经开始介质恢复

-- 尝试开始新的恢复，但恢复已经在进行中

ORA-01547：警告：RECOVER成功但OPEN RESETLOGS时出现

-- 恢复成功但需要RESETLOGS打开数据库

ORA-01113：文件需要介质恢复

-- 数据文件需要介质恢复才能打开

ORA-01194：文件需要更多的恢复来保持一致性

-- 需要应用更多的重做日志来使文件一致

⓫ 预防措施与最佳实践

1. 规范的恢复操作流程

-- 在进行恢复操作时使用脚本记录步骤
-- 恢复操作记录脚本示例
SET ECHO ON
SET TIME ON
SPOOL recovery_operation.log

-- 记录开始时间
SELECT TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS start_time FROM DUAL;

-- 执行恢复操作
STARTUP MOUNT;
RECOVER DATABASE;
ALTER DATABASE OPEN;

-- 记录结束时间
SELECT TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS end_time FROM DUAL;

SPOOL OFF

2. 定期验证备份和恢复流程

-- 使用RMAN验证备份可恢复性
RMAN> VALIDATE RESTORE DATABASE;

-- 检查归档日志连续性
SELECT thread#, min(sequence#), max(sequence#), count(*) 
FROM v$archived_log 
GROUP BY thread#;

3. 监控恢复会话状态

-- 创建恢复监控视图
CREATE VIEW recovery_monitor AS
SELECT 
    rs.recovery_status,
    rs.operation,
    rs.object_type,
    rs.start_time,
    rs.elapsed_seconds
FROM v$recovery_status rs
WHERE rs.status = 'ACTIVE';

4. 实施会话管理最佳实践

• 使用持久性会话工具（如screen或tmux）进行长时间运行的恢复操作
• 定期检查恢复会话的活动状态
• 配置会话超时和重连机制

⓬ 相关SQL操作语句汇总

-- 检查恢复状态
SELECT * FROM v$recovery_status;
SELECT * FROM v$recovery_file;
SELECT * FROM v$recovery_progress;

-- 检查文件状态
SELECT file#, checkpoint_change#, fuzzy FROM v$datafile_header;
SELECT type, records_used, records_total FROM v$controlfile_record_section;

-- 恢复操作命令
STARTUP MOUNT;
RECOVER DATABASE;
RECOVER DATABASE UNTIL TIME 'time_string';
RECOVER DATABASE USING BACKUP CONTROLFILE;
RECOVER CANCEL;
ALTER DATABASE OPEN;
ALTER DATABASE OPEN RESETLOGS;

-- Data Guard恢复命令
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filename';

-- RMAN恢复命令
RMAN> RECOVER DATABASE;
RMAN> RESTORE DATABASE;
RMAN> VALIDATE DATABASE;

⓭ 总结

ORA-00273错误的本质是恢复会话状态信息丢失或损坏，导致数据库无法正确跟踪恢复进度。解决这个错误的关键在于：

1. 重新建立恢复会话：取消现有会话并开始新的恢复过程
2. 确保状态一致性：验证控制文件、数据文件和内存状态的一致性
3. 完整应用重做数据：确保所有必要的归档日志都被正确应用

核心解决策略：

• 恢复会话中断 → 重新开始恢复过程
• 状态信息不一致 → 验证并同步各个组件状态
• 控制文件问题 → 使用备份控制文件或重建控制文件

最佳实践提醒：

• 在进行重要的恢复操作前总是进行完整备份
• 使用持久性会话来执行长时间运行的恢复操作
• 详细记录所有恢复步骤和时间点
• 定期测试备份和恢复流程
• 在Data Guard环境中监控日志传输和应用状态

ORA-00273错误虽然令人困扰，但通过系统性的方法和正确的工具，通常可以成功解决。最重要的是保持冷静，按照既定的恢复流程操作，并在生产环境操作前在测试环境中进行充分的练习。

通过本文的详细解释和示例，您应该能够理解ORA-00273错误的本质，并掌握诊断和解决这个错误的有效方法。

欢迎关注我的公众号《IT小Chen》