27-Oracle 23 ai Automatic Rollback Quarantine（事务精准隔离）

远方1609

已于 2025-06-12 10:51:36 修改

阅读量347

点赞数 17

文章标签： oracle 数据库 sql database

于 2025-06-12 10:41:50 首次发布

本文链接：https://blog.csdn.net/sharpwt/article/details/148604405

版权

小伙伴们是不是大部分都已经迁移到19c了，10g、11g都慢慢进入了替换和主键开始养老阶段。12c~开始清新的CDB、PDB，

如果有那么一刻业务在PDB崩了，会不会一个PDB影响多个，甚至把CDB带崩。Oracle用了什么手段进行事务隔离，隔离到什么程度。

一、从前熟悉的配方

1. 崩溃恢复失败 = 实例级宕机

当数据库在崩溃恢复（Crash Recovery）阶段遇到事务回滚失败（如坏块、内存错误）时：

触发致命错误：抛出ORA-00600、ORA-07445等内部错误
强制终止实例：整个数据库实例立即中止（SHUTDOWN ABORT）
影响范围：单实例数据库全体宕机；RAC中单个节点故障可能蔓延至整个集群

2. 人工介入

事务崩溃，人工来凑：

若事务恢复遇到物理坏块（ORA-01578），直接引发实例崩溃，DBA必须人肉手敲执行：

# 1. 重启至mount状态
STARTUP MOUNT;
# 2. 尝试修复坏块（可能丢失数据）
RECOVER DATABASE USING BACKUP CONTROLFILE; 
--基于时间点
RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL TIME 'YYYY-MM-DD:HH24:MI:SS';
--使用备份控制文件进行不完全恢复，输入CANCEL或应用所有可用的归档日志和在线日志
RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;
--基于SCN的不完全恢复
RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CHANGE <scn_number>;
ALTER DATABASE OPEN RESETLOGS;


# 3. 强制打开数据库（隐含数据风险）
ALTER DATABASE OPEN RESETLOGS;

一、Rollback Quarantined特性：数据库的"隔离机制"

目标：解决崩溃恢复（Crash Recovery）过程中因事务恢复失败导致的实例级宕机问题。

工作流程

1.崩溃恢复阶段
- 数据库重启时需回滚未提交事务（Transaction Recovery）
- 若遇到以下故障，恢复过程会失败：
  - 物理损坏（例如ORA-01578坏块）
  - 逻辑错误（例如ORA-00600内部错误）
  - 内存/状态损坏（ORA-07445）
2.事务隔离触发

恢复失败时，Oracle 23 ai 将问题事务标记为隔离状态（Quarantined）

该事务持有的行锁持续存在，但数据库其他部分继续运行

3.持久化存储

隔离事务信息存入数据字典表（DBA_QUARANTINED_TRANSACTIONS）

支持RAC多节点访问

二、Quarantine技术特点：高可用性的"安全气囊"

1. 故障熔断

自动隔离：单个事务故障不扩散至整个实例
阈值保护：单PDB内隔离事务达默认阈值（3个）时，SHUTDOWN ABORT自动关闭该PDB（其他PDB不受影响）

2.其他数据库在事务恢复失败时同样面临硬中断问题：

MySQL：遇到崩溃恢复失败直接标记实例为CRASHED，innodb_force_recovery强制启动（可能丢数据）
SQL Server：通过DBCC CHECKDB修复坏块，无法隔离单个事务，修复期间数据库不可用
PostgreSQL：使用pg_resetwal重置事务日志，停机且丢失未提交事务
Oracle 23ai：实现事务级隔离恢复，在保证数据一致性的前提下最大化可用性。熔断机制 + 细粒度恢复控制

2. 查询管理

-- 查看隔离事务详情，正常情况下，无信息
SELECT usn, slt, sqn, reason, trace_file_name FROM dba_quarantined_transactions;
SYS@CDB$ROOT> SELECT usn, slt, sqn, reason, trace_file_name FROM dba_quarantined_transactions;
no rows selected

-- 异常输入输出示例：
USN  SLT  SQN  REASON              TRACE_FILE_NAME
6    18   10   ORA-00600[ktubko_1] /opt/oracle/diag/...trc

四、Oracle 23ai 实操脚本

S1：模拟事务隔离

-- 步骤1：制造无法回滚的事务（需SYSDBA权限）
ALTER SYSTEM SET TRANSACTION_RECOVERY=DISABLED;  -- 禁用自动恢复
SYS@CDB$ROOT> ALTER SYSTEM SET TRANSACTION_RECOVERY=DISABLED;

System altered.
CREATE TABLE employees (ID int PRIMARY KEY,NAME varchar2(100));
INSERT INTO employees  VALUES (999,'test999');    -- 插入数据不提交
SHUTDOWN ABORT;                                   -- 强制终止崩溃

-- 步骤2：重启后检查隔离事务
STARTUP;
SELECT usn, slt, sqn, reason FROM dba_quarantined_transactions;

S2：清除隔离事务

-- 根据查询结果清除隔离事务
ALTER DATABASE DROP TRANSACTION QUARANTINE;

-- 重新启用事务恢复
ALTER SYSTEM SET TRANSACTION_RECOVERY=ENABLED;

S3:隔离场景处理

-- 当PDB因隔离事务过多关闭时
ALTER PLUGGABLE DATABASE FREEPDB1 OPEN;
-- 重新打开PDB

-- 检查并逐个清除隔离事务
SELECT * FROM cdb_quarantined_transactions;
--生产环境需优先分析trace_file_name中的错误原因

其他使用物理和逻辑RMAN Block Media Recovery、逻辑上的Recreate the Data Segment，极端场景操作单独开一个记录。