Oracle 19c引入的SQL Quarantine（SQL隔离）是一项面向数据库自愈与稳定运行的实用特性。当某条SQL语句因为并行执行消耗过多资源、触发资源管理器限制而被终止时，数据库可以自动将该SQL的执行签名放入隔离区，后续相同特征的SQL在尝试以类似高消耗方式运行时会被直接拒绝或降级，从而防止个别失控语句反复拖垮整个实例。这项能力特别适合多租户、报表混合负载以及无法立即修改业务代码的遗留系统。
SQL Quarantine的工作原理与触发条件
SQL Quarantine的核心思路是“记住失控语句并提前拦截”。在Oracle 19c中，当一条SQL由于违反资源管理器（Resource Manager）设定的指令，例如并行度超过阈值、运行时间超时、或消耗I/O与CPU超出计划限制而被取消时，系统会生成一个隔离条目。该条目主要基于SQL_ID、SQL执行计划哈希值（SQL_PLAN_HASH_VALUE）以及导致终止的资源限制类型来唯一标识“危险执行方式”。
需要注意的是，SQL Quarantine并不是对所有慢SQL都生效，它通常依赖Resource Manager的干预动作。例如，当使用DBMS_RESOURCE_MANAGER创建的计划在directive中定义了parallel_server_limit或switch_time，且语句因这些规则被切换或杀掉，才可能被隔离。这种机制保证了只有那些确实造成资源事故的语句才会进入隔离名单，避免误伤正常查询。
从内部看，隔离信息存储在数据字典中，可通过DBA_SQL_QUARANTINE视图查询。每条记录包含是否被启用的标志、适用模块、触发原因等。数据库在硬解析或执行前会比对当前SQL的执行环境与隔离规则，若匹配且处于启用状态，则按照规则拒绝执行或强制降低并行度，而不是等它再次把系统跑挂。
如何配置与查看SQL Quarantine规则
在实际运维中，DBA往往需要先确认环境是否已开启相关自动化。Oracle 19c默认在部分管理选项中提供自动隔离，但也可通过包DBMS_SQL_QUARANTINE手动创建规则。例如，针对某个已知危险的SQL_ID，可以显式将其加入隔离并限制并行度：
BEGIN
DBMS_SQL_QUARANTINE.CREATE_QUARANTINE(
sql_id => 'abc123def456',
plan_hash_value => 1234567890,
quarantine_name => 'Q_LARGE_REPORT',
enabled => TRUE
);
END;
/
上述代码通过CREATE_QUARANTINE过程将指定SQL_ID与计划哈希组合成隔离对象。如果后续该语句试图以原方式运行，数据库会读取此规则并进行拦截。管理员可以使用如下语句检查当前生效的隔离条目：
SELECT quarantine_name,
sql_id,
plan_hash_value,
enabled,
creator
FROM dba_sql_quarantine
ORDER BY created DESC;
除了手动创建，自动隔离会在Resource Manager终止语句后由后台任务完成。DBA应定期审查DBA_SQL_QUARANTINE，将已优化或误报的条目停用或删除，防止规则堆积影响正常发布。停用可使用DBMS_SQL_QUARANTINE.DISABLE_QUARANTINE，删除则使用DROP_QUARANTINE。合理的生命周期管理是发挥该特性价值的关键。
SQL Quarantine与手动拦截方案的对比优势
在传统运维中，面对失控SQL，常见的做法是DBA通过V$SESSION定位SID后执行ALTER SYSTEM KILL SESSION，或者修改应用代码、创建 Profile 限制资源。这类方式响应慢、依赖人工，且无法阻止同一语句在下一个业务周期再次爆发。SQL Quarantine则将“识别危险”与“拦截动作”固化到数据库内核层，实现闭环。
从资源控制粒度看，手动Kill只能中断当前会话，新会话仍可重发相同SQL；而隔离规则绑定SQL_ID与执行计划，即使应用重连也会在解析阶段被拦下。相比使用SQL Profile或SQL Plan Baseline来引导优化器走不同计划，Quarantine更偏向“保护性拒绝”，适合优化方案尚未就绪、但系统必须存活的过渡期。它也能和Resource Manager配合，形成“超限即终止、终止即隔离”的自动防抖链条。
当然，这项特性也有边界。它不能替代索引优化、统计信息更新等根本手段；若业务SQL必须那样执行且资源充足，应调整Resource Manager计划而非长期隔离。但在突发故障、灰度发布异常、报表语句误用hint等场景下，SQL Quarantine提供了低成本、可回退的安全网，显著降低MTTR。
典型应用场景与注意事项
在多租户PDB环境中，某个报表租户在月初跑批时发出并行度64的聚合SQL，导致其他PDB响应变慢。Resource Manager依据PDB指令限制其并行服务器数量，语句因超限被终止，随后自动进入Quarantine。次日该租户再次提交同样语句，数据库直接拒绝或以并行度1运行，保障了整体SLA。这就是最典型的应用画像。
使用时应注意，隔离规则是基于“SQL_ID + 计划哈希”的，如果优化器因统计信息变化生成了新计划，原隔离可能不再命中，需要重新评估。另外，在升级或迁移数据库前，建议导出DBA_SQL_QUARANTINE内容，避免目标库因缺失上下文而重复踩坑。对于使用绑定变量的语句，SQL_ID相对稳定，隔离命中率较高；而对于每次字面量不同的SQL，则可能需要借助其他手段辅助识别。
最后，SQL Quarantine是Oracle 19c企业版中值得纳入标准运维手册的特性。它不改变业务代码，不要求开发介入，却能在系统最脆弱的时刻自动止血。将其与监控告警、AWR分析结合，可构建从发现问题、隔离危险到根治优化的完整链路。
Oracle_19cSQL_QuarantineSQL隔离修改时间：2026-08-14 13:54:35