Oracle 19c 性能参数排查:ACS 未开启引发的执行计划突变案例分析
先说背景实在没想通这个默认打开的参数为什么关闭了。从来没去考虑过会关闭。而且大部分都是打开的。实在不巧遇到这个数据库是关闭的一、问题背景前几天在客户现场排查一个性能问题发现Oracle 19c 数据库中 ACSAdaptive Cursor Sharing自适应游标共享居然没有开启。按照 Oracle 的官方文档ACS 从 11gR2 开始默认是开启的但客户的 19c 环境却意外关闭了。这导致了一个典型的性能问题现象一条核心业务 SQL 在当天早上 8 点突然变慢之后一直使用次优执行计划影响业务响应时间总之变慢了排查发现该 SQL 的执行计划发生了突变且固化了错误的计划解决清除该 SQL 的所有游标按 SQL_ID 清除强制重新解析后恢复正常这引发了一个思考为什么 ACS 关闭后SQL 会突然在某天早上崩掉由于这是第一次遇到这么奇怪的所以也是推论。可能推论的不对可以纠正我的想法。二、原理分析ACS 关闭后的执行计划稳定性问题2.1 ACS 的作用机制自适应游标共享ACS是 Oracle 11g 引入的重要特性用于解决绑定变量窥探Bind Peeking带来的问题。传统绑定变量窥探的问题-- 假设有一个查询 SELECT * FROM orders WHERE status :bind1; -- 如果第一次执行时 :bind1 ACTIVE返回 1000 行 -- 优化器会生成一个适合返回大量数据的执行计划比如 FULL SCAN -- 后续如果 :bind1 CLOSED只返回 10 行 -- 但 Oracle 仍然使用之前的执行计划不会重新优化ACS 的解决方案监控绑定变量的实际值分布根据绑定变量的选择性生成多个子游标child cursor不同绑定变量值可以选择不同的执行计划2.2 ACS 关闭后的风险场景当 ACS 关闭时Oracle 退回到传统的绑定变量窥探模式第一次硬解析基于第一次执行的绑定变量值生成执行计划后续执行无论绑定变量值如何变化都复用同一个执行计划风险点如果第一次硬解析时碰巧遇到非典型的绑定变量值就会生成一个次优计划并长期固化2.3 为什么会在当天早上 8 点突然出问题可能原因游标被清除触发了重新解析。因为我列出了一些可能的原因然后排除了一些没有发生的情况那么剩下的是可能性较高的因为可能的原因包括1共享池空间压力-- 查看共享池使用情况 SELECT * FROM v$sgastat WHERE name free memory AND pool shared pool; -- 查看游标失效情况 SELECT sql_id, child_number, executions, loads, invalidations FROM v$sql WHERE sql_id your_sql_id;共享池空间不足时LRU 算法会淘汰旧的游标如果淘汰了该 SQL 的游标下次执行时会触发硬解析这次硬解析如果碰巧遇到一个非典型的绑定变量值就会生成次优计划2统计信息自动收集-- 查看统计信息收集历史 SELECT table_name, last_analyzed, num_rows FROM dba_tables WHERE table_name IN (YOUR_TABLES) ORDER BY last_analyzed DESC;Oracle 默认在夜间通常 22:00-06:00自动收集统计信息统计信息更新后相关的游标会被标记为INVALID下次执行时触发硬解析可能生成新的执行计划因为这个表没有数量级的变化变化程度也没有超过10%。所以没有被收集过。而且如果因为是这个原因的话那早就出问题了。3对象结构变更索引重建、表分析、DDL 操作等都会导致游标失效这个也问了相关的人没有做过DDL和索引重建4实例重启或共享池刷新当然很明显这个数据库没有重启过。-- 查看实例启动时间 SELECT startup_time FROM v$instance; -- 查看是否有人手动刷新共享池 SELECT * FROM dba_audit_trail WHERE obj_name FLUSH SHARED_POOL;2.4 问题复现路径基于以上分析问题的完整路径应该是1. ACS 关闭隐藏参数 _optimizer_adaptive_cursor_sharing FALSE ↓ 2. SQL 游标因某种原因被清除共享池压力/统计信息更新等 ↓ 3. 早上 8 点业务高峰该 SQL 第一次执行 ↓ 4. 硬解析时碰巧遇到一个非典型的绑定变量值 ↓ 5. 生成了一个次优的执行计划比如全表扫描 ↓ 6. 由于 ACS 关闭后续所有执行都复用这个次优计划 ↓ 7. 性能急剧下降且问题持续存在2.5 解决方案验证采用的方案是-- 清除该 SQL 的所有游标 ALTER SYSTEM FLUSH SHARED_POOL; -- 方法1清空整个共享池影响大 这种方案一般来说是不用的。 -- 所以采用下面的 SELECT address, hash_value FROM v$sqlarea WHERE sql_id your_sql_id; -- 然后逐个清除这个方案是正确的因为清除了次优计划的游标下次执行时触发硬解析如果此时绑定变量值是典型的值就会生成正确的执行计划由于 ACS 关闭这个正确计划会被固化下来但治本的方案是-- 开启 ACS需要重启 ALTER SYSTEM SET _optimizer_adaptive_cursor_sharing TRUE SCOPESPFILE; ALTER SYSTEM SET _optimizer_extended_cursor_sharing UDO SCOPESPFILE; ALTER SYSTEM SET _optimizer_extended_cursor_sharing_rel NONE SCOPESPFILE; -- 然后重启数据库三、Oracle 11g-19c 性能相关参数清单基于这次排查经验我整理了Oracle 11g 到 19c 所有与性能相关的参数包括默认值和查询方式。3.1 自适应游标共享ACS相关参数名默认值作用影响查询方式_optimizer_adaptive_cursor_sharingTRUE (11gR2)启用 ACS避免绑定变量导致的次优计划SELECT ksppinm, ksppstvl FROM x$ksppi x, x$ksppcv y WHERE x.indx y.indx AND ksppinm _optimizer_adaptive_cursor_sharing;_optimizer_extended_cursor_sharingUDO (11gR2)控制扩展游标共享行为与 ACS 配合使用同上替换参数名_optimizer_extended_cursor_sharing_relNONE (11gR2)关联查询的扩展游标共享影响复杂查询稳定性同上替换参数名注意这三个参数都是隐藏参数修改需要重启实例。3.2 自适应优化器特性参数名默认值作用影响查询方式_optimizer_adaptive_featuresTRUE (12cR1)启用自适应优化器运行时调整执行策略隐藏参数查询optimizer_adaptive_plansTRUE (12cR2)启用自适应执行计划改善复杂查询增加 CPU 开销SHOW PARAMETER optimizer_adaptive_plansoptimizer_adaptive_statisticsFALSE (12cR2)启用自适应统计信息动态收集统计信息SHOW PARAMETER optimizer_adaptive_statistics3.3 基数反馈Cardinality Feedback参数名默认值作用影响查询方式_optimizer_use_feedbackTRUE (11gR2)启用基数反馈自动纠正错误基数估算隐藏参数查询_optimizer_cardinality_feedbackTRUE (12c)基数反馈详细行为与上一参数配合隐藏参数查询3.4 动态采样参数名默认值作用影响查询方式optimizer_dynamic_sampling2 (11g)动态采样级别 (0-11)改善统计信息缺失表的查询SHOW PARAMETER optimizer_dynamic_sampling3.5 自动内存管理参数名默认值作用影响查询方式memory_target0 (需手动设)启用 AMM简化内存管理但可能不稳定SHOW PARAMETER memory_targetmemory_max_target0AMM 最大限制限制最大内存使用SHOW PARAMETER memory_max_targetsga_target0 (需手动设)启用 ASMM自动调整 SGA 组件SHOW PARAMETER sga_targetpga_aggregate_target10M 或 SGA 20%PGA 总大小影响排序、哈希操作SHOW PARAMETER pga_aggregate_target3.6 并行执行参数名默认值作用影响查询方式parallel_degree_policyMANUAL (11gR2)并行度策略AUTO/ADAPTIVE 自动决定并行度SHOW PARAMETER parallel_degree_policyparallel_degree_limitCPU (11gR2)并行度最大值防止过度并行SHOW PARAMETER parallel_degree_limitparallel_min_time_threshold10 (秒)并行最小时间阈值避免短查询并行SHOW PARAMETER parallel_min_time_threshold3.7 结果集缓存参数名默认值作用影响查询方式result_cache_modeMANUAL (11g)结果缓存模式AUTO 自动决定是否缓存SHOW PARAMETER result_cache_moderesult_cache_max_size0 或 sga*0.25%缓存最大大小限制内存使用SHOW PARAMETER result_cache_max_sizeresult_cache_max_result5 (%)单结果最大占比防止单个结果占满缓存SHOW PARAMETER result_cache_max_result3.8 SQL 计划管理SPM参数名默认值作用影响查询方式optimizer_use_sql_plan_baselinesTRUE (11g)启用 SQL 计划基线防止执行计划退化SHOW PARAMETER optimizer_use_sql_plan_baselinesoptimizer_capture_sql_plan_baselinesFALSE自动捕获基线自动维护计划稳定性SHOW PARAMETER optimizer_capture_sql_plan_baselines3.9 统计信息相关参数名默认值作用影响查询方式optimizer_use_pending_statisticsFALSE (11g)使用待定统计信息验证统计信息后再发布SHOW PARAMETER optimizer_use_pending_statistics_optimizer_gather_stats_on_loadTRUE (11g)加载时自动收集统计保持统计信息新鲜隐藏参数查询3.10 其他重要性能参数参数名默认值作用影响查询方式_optimizer_cost_based_transformationTRUE基于成本的查询转换改善复杂查询优化隐藏参数查询_optimizer_null_aware_antijoinTRUE (11g)NULL 感知反连接改善 NOT IN 性能隐藏参数查询_optimizer_use_histogramsTRUE使用直方图改善数据倾斜列估算隐藏参数查询_optimizer_system_stats_usageTRUE使用系统统计信息基于硬件成本的优化隐藏参数查询四、快速检查脚本4.1 检查 ACS 状态SELECT ksppinm AS parameter_name, ksppstvl AS current_value, ksppdesc AS description FROM x$ksppi x, x$ksppcv y WHERE x.indx y.indx AND ksppinm IN ( _optimizer_adaptive_cursor_sharing, _optimizer_extended_cursor_sharing, _optimizer_extended_cursor_sharing_rel );4.2 检查所有优化器相关参数SELECT name, value, description FROM v$parameter WHERE name LIKE optimizer% ORDER BY name;4.3 检查隐藏参数谨慎使用-- 查询所有 _optimizer 开头的隐藏参数 SELECT ksppinm AS parameter_name, ksppstvl AS current_value, ksppdesc AS description FROM x$ksppi x, x$ksppcv y WHERE x.indx y.indx AND ksppinm LIKE _optimizer% ORDER BY ksppinm;五、最佳实践建议5.1 生产环境参数配置建议ACS 相关参数保持默认值开启-- 验证 ACS 是否开启 SELECT ksppinm, ksppstvl FROM x$ksppi x, x$ksppcv y WHERE x.indx y.indx AND ksppinm _optimizer_adaptive_cursor_sharing;自适应优化器12cR2 建议开启ALTER SYSTEM SET optimizer_adaptive_plans TRUE SCOPEBOTH;SQL 计划管理建议开启基线保护ALTER SYSTEM SET optimizer_use_sql_plan_baselines TRUE SCOPEBOTH;5.2 问题排查流程当遇到执行计划突变问题时检查 ACS 状态- 是否意外关闭检查游标状态- 是否有 invalidations检查统计信息- 最近是否更新检查共享池- 是否有空间压力清除游标测试-ALTER SYSTEM FLUSH SHARED_POOL谨慎使用5.3 预防措施定期监控设置定时任务检查关键参数变更管理任何参数修改都应在测试环境验证基线保护对核心 SQL 使用 SPM 基线统计信息避免在业务高峰期自动收集统计信息六、总结这次排查揭示了一个重要问题Oracle 19c 虽然默认开启 ACS但在某些情况下安装时候特意去关闭。自己想当然觉得这个是默认的就没去关注。也许我也没分析对有人如果有更好的分析可以告诉我。

相关新闻

0722 LLM及其科研进展

0722 LLM及其科研进展

大模型不能直接自由生成设备控制命令 7月19日前后公开的研究 Schema-Bound LLM Control of Scientific Instrumentation,针对LLM控制科研仪器时容易生成非法参数、遗漏安全条件或调用不存在命令的问题,提出使用严格Schema约束模型输出。 https://arxiv…

2026/7/23 23:02:41 阅读更多 →
炸裂!Python布尔数组内存压缩到极致:比numpy省90%内存,性能还快30%

炸裂!Python布尔数组内存压缩到极致:比numpy省90%内存,性能还快30%

前言 做大数据、机器学习特征工程、位图索引的同学应该都遇到过布尔数组内存爆炸的问题:- 1亿个用户标记,用Python list存要800MB,GC直接卡爆- 用numpy bool数组,也要100MB,数据量再大一点还是顶不住- 用普通位数组&am…

2026/7/23 23:01:40 阅读更多 →
nomachine画面显示分辨率不对设置方法

nomachine画面显示分辨率不对设置方法

连接后鼠标移到画面的右上角,等页面卷成三角形:

2026/7/23 23:01:40 阅读更多 →

最新新闻

AI会议纪要不是“转录完事”:2024最新Gartner评估报告显示,仅12%企业实现行动项自动追踪闭环

AI会议纪要不是“转录完事”:2024最新Gartner评估报告显示,仅12%企业实现行动项自动追踪闭环

更多请点击: https://kaifayun.com 第一章:AI会议纪要不是“转录完事”:从Gartner报告看智能纪要的本质跃迁 Gartner在2024年《Emerging Technologies for Digital Workplace》报告中明确指出:“智能会议纪要已跨越语音转文字&am…

2026/7/23 23:12:49 阅读更多 →
三星扩产2倍背后的半导体设备采购逻辑与技术选型框架

三星扩产2倍背后的半导体设备采购逻辑与技术选型框架

7月22日,三星电子正评估将美国泰勒厂的初期生产规模扩大至原计划的2倍。这一事件是半导体设备“超级周期”持续强化的又一信号。一、半导体设备高景气周期的多重确认三星泰勒厂扩产至2倍:美国最大半导体投资项目之一,已锁定客户订单台积电资本…

2026/7/23 23:12:49 阅读更多 →
经营 35-45 岁黄金十年:IT 人的破局之道与路径选择一、行业现状:35 岁现象的现实困境与机遇在数字化浪潮席卷全球的当下,IT 行业正经历着前所未有的变革。根据 CSDN 2024 年数据显

经营 35-45 岁黄金十年:IT 人的破局之道与路径选择一、行业现状:35 岁现象的现实困境与机遇在数字化浪潮席卷全球的当下,IT 行业正经历着前所未有的变革。根据 CSDN 2024 年数据显

经营 35-45 岁黄金十年:IT 人的破局之道与路径选择一、行业现状:35 岁现象的现实困境与机遇在数字化浪潮席卷全球的当下,IT 行业正经历着前所未有的变革。根据 CSDN 2024 年数据显示,国内 35 岁以上程序员占比仅 9.4%,…

2026/7/23 23:12:49 阅读更多 →
下一代企业智能基座:为什么说「LLM 规划 + MCP 调度 + Agent 执行」= 未来标配?一、引言:从工具到系统的智能化跃迁在企业数字化转型的深水区,传统 IT 架构正面临决策滞后、资源割

下一代企业智能基座:为什么说「LLM 规划 + MCP 调度 + Agent 执行」= 未来标配?一、引言:从工具到系统的智能化跃迁在企业数字化转型的深水区,传统 IT 架构正面临决策滞后、资源割

下一代企业智能基座:为什么说「LLM 规划 MCP 调度 Agent 执行」 未来标配?一、引言:从工具到系统的智能化跃迁在企业数字化转型的深水区,传统 IT 架构正面临决策滞后、资源割裂、执行僵化三大核心痛点。例如,某制造业…

2026/7/23 23:12:49 阅读更多 →
AI会说安慰的话,就等于有情商吗?

AI会说安慰的话,就等于有情商吗?

一句“我理解你”正在变得廉价,真正的情感智能必须经得起误判、沉默与长期关系 今天几乎所有聊天机器人都会说:“听起来你经历了很多”“我能理解你的感受”“你愿意多说一点吗?”这些句子柔和、礼貌,也符合人们对共情的想象。问…

2026/7/23 23:12:49 阅读更多 →
Kimi K3 发布当天,我拿它和 GPT-5.6-Luna、Claude Sonnet 5 跑了 5 轮硬核编程题——有一类多步推理任务排名和官方宣传完全反过来

Kimi K3 发布当天,我拿它和 GPT-5.6-Luna、Claude Sonnet 5 跑了 5 轮硬核编程题——有一类多步推理任务排名和官方宣传完全反过来

上周三 Kimi K3 发布,朋友圈被刷屏了。Moonshot 官方宣传说"推理能力大幅跃升",我当天晚上就把 moonshotai/kimi-k3、openai/gpt-5.6-luna、anthropic/claude-sonnet-5 三个模型拉到同一套测试框架里跑了一遍。结论先放这儿:在单步…

2026/7/23 23:11:44 阅读更多 →

日新闻

从单点好评到指数级传播:AI副业主理人必须掌握的4层口碑渗透模型(含ROI测算表)

从单点好评到指数级传播:AI副业主理人必须掌握的4层口碑渗透模型(含ROI测算表)

更多请点击: https://intelliparadigm.com 第一章:从单点好评到指数级传播:AI副业主理人必须掌握的4层口碑渗透模型(含ROI测算表) 当AI副业主理人不再仅满足于单次服务交付,而是主动构建可复用、可裂变、可…

2026/7/23 0:00:25 阅读更多 →
AI写作开头钩子设计:为什么你的AI文案完读率不足18%?——基于2,346篇A/B测试报告的归因分析

AI写作开头钩子设计:为什么你的AI文案完读率不足18%?——基于2,346篇A/B测试报告的归因分析

更多请点击: https://codechina.net 第一章:AI写作开头钩子设计:为什么你的AI文案完读率不足18%?——基于2,346篇A/B测试报告的归因分析 在对2,346篇跨行业AI生成文案的A/B测试数据进行聚类分析后,我们发现&#xff1…

2026/7/23 0:01:26 阅读更多 →
Chitchatter完整指南:免费开源的终极点对点安全聊天工具

Chitchatter完整指南:免费开源的终极点对点安全聊天工具

Chitchatter完整指南:免费开源的终极点对点安全聊天工具 【免费下载链接】chitchatter Secure peer-to-peer chat that is serverless, decentralized, and ephemeral 项目地址: https://gitcode.com/gh_mirrors/ch/chitchatter Chitchatter是一款革命性的安…

2026/7/23 0:01:26 阅读更多 →

周新闻

Go语言静态资源打包方案对比与实践指南

Go语言静态资源打包方案对比与实践指南

1. 项目背景与核心需求在Go语言开发中,我们经常需要处理静态资源文件的打包问题。无论是Web应用的模板文件、前端资源,还是配置文件、证书等,都需要随程序一起分发。传统做法是将这些文件与编译后的二进制文件放在同一目录下,但这…

2026/7/22 8:58:19 阅读更多 →
Go语言实现高性能LDAP认证服务的架构与实践

Go语言实现高性能LDAP认证服务的架构与实践

1. 项目背景与核心价值LDAP(轻量级目录访问协议)作为企业级身份认证的黄金标准,已经服务了超过80%的财富500强公司。我在金融科技领域实施统一认证体系时,发现传统Java方案存在启动慢、内存占用高等痛点。而Go语言凭借其协程并发模…

2026/7/22 19:43:43 阅读更多 →
【AI面试官实战指南】:用ChatGPT模拟10类高频技术岗面试,3天提升应答精准度92%

【AI面试官实战指南】:用ChatGPT模拟10类高频技术岗面试,3天提升应答精准度92%

更多请点击: https://intelliparadigm.com 第一章:AI面试官实战指南的核心价值与适用场景 AI面试官并非替代人类HR的“黑箱工具”,而是以可解释、可审计、可迭代的方式,赋能招聘全链路的关键基础设施。其核心价值在于将主观经验沉…

2026/7/23 17:49:47 阅读更多 →

月新闻