为了不错过每一期干货,强烈建议关注我
写技术文章,纯属"为爱发电";更新不易,希望大家能够多多支持
1️⃣ 点赞的人,今年都升职加薪了
2️⃣ 点在看人,今年一定会发财
3️⃣ 评论区交流技术,每条留言都会回复
一、隐藏参数(Underscore Parameters)概述
- 定义:以 "**_" (一个下划线)开头的初始化参数被称为"隐含参数"或"隐藏参数"。
- 官方态度:Oracle通常不建议直接修改这些参数。文档原文指出:"这些以"_"开头的初始化参数通常被称为隐含参数,Oracle 通常不建议修改这些参数。"
- 存在意义 :它们主要供内部开发、调试或在Oracle技术支持指导下解决特定问题使用。部分参数因其特殊功能(如
_allow_resetlogs_corruption用于紧急恢复)而被资深DBA所知。 - 风险 :
- 无官方文档:意味着行为可能随版本变化,且无稳定性保证。
- 可能导致不稳定:不当修改可能引发性能下降、功能异常甚至数据库崩溃。
- 绕开官方修复:可能无意中关闭了重要的bug修复或安全补丁。
二、_fix_control 参数详解
1. 核心定义
根据官方文档 《Info About Hidden Parameter _fix_control (Doc ID 782926.1)》:
- 引入版本:Oracle Database 10.2.0.2。
- 功能 :它是一个通用服务,主要用于允许用户禁用(或启用)特定的Bug修复。虽然可用于所有代码层,但其最主要的应用场景是控制优化器(CBO) 相关的修复。
- 用途:当某个官方修复(尤其是优化器相关的修复)在特定环境中引发了性能回退(Regression)、错误结果或新的问题时,可以临时禁用该修复,作为权宜之计(Workaround)。
2. 语法与示例
该参数值采用 'bug_number:action' 的格式。
sql
-- 禁用特定Bug修复(最常见用法)
ALTER SESSION SET "_fix_control" = '7356191:OFF';
-- 启用特定Bug修复
ALTER SESSION SET "_fix_control" = '9301862:ON';
-- 同时控制多个修复,用逗号分隔
ALTER SESSION SET "_fix_control" = '7356191:OFF, 12587690:OFF, 30195773:OFF';
3. 典型应用场景(来自文档案例)
- 解决性能回退:如《High Waits for 'cursor pin S wait on X'...》文档中,关闭修复 7452863 以解决并行查询动态采样导致的严重等待事件。
- 绕过功能错误:如《ORA-01417 During 'INSERT INTO SELECT' Over Dblink From 12c》文档中,关闭修复 12587690 以禁用12c的多表外连接新特性,解决跨库插入报错。
- 控制新特性行为 :如《Oracle 12.1 Readme》中,使用
'6748058:0'来调整 UNION ALL 并发执行的约束条件。 - 诊断工具(SQLT XPLORE) :在《SQLT 使用指南》中,XPLORE模块会系统地切换包括
_fix_control在内的参数,以定位是哪个特定的优化器功能或修复导致了升级后的不良执行计划。 - 已知问题规避 :在多个"已知问题(Known Issues)"文档(如19c RU)中,Oracle会直接提供通过
_fix_control禁用特定修复的临时解决方案。
4. 严重警告
- 数据泵故障 :文档《How to resolve the Data Pump error ORA-31623...》明确指出,如果设置了
_fix_control='6167716:OFF',Data Pump作业将会失败。这印证了随意修改此参数可能导致核心功能异常。 - Oracle的建议:官方文档强调应 "谨慎使用(use cautiously)" 并 "参考文档进行正确实施(refers to documentation for proper implementation)"。
三、_optimizer_improve_selectivity 参数解析
1. 功能推断(基于"选择性"核心概念)
多篇文档(如《Oracle Data Cartridge Developer's Guide》多个版本)都强调 选择性(Selectivity) 是优化器计算成本、选择访问路径和决定连接顺序的最关键因素之一。选择性估计不准是导致糟糕执行计划的主要原因。
_optimizer_improve_selectivity从名称上看,其设计初衷应是 "改进优化器的选择性计算",可能引入了更复杂或更精确的估计算法。- 将其设置为
FALSE,意味着禁用这种"改进的"选择性计算,很可能使优化器回退到更简单、更保守(或更老旧)的选择性估计模型。
2. 关联问题与使用场景
- 与游标共享的关联 :在《Adaptive Cursor Sharing Overview》中,检查列表提到"Certain parameters like ("_optim_peek_user_binds" = false) are set"会禁用自适应游标共享。这表明,以
_optimizer和_optim开头的隐藏参数常用来控制优化器在绑定变量、选择性估算等方面的微观行为。 - 可能的用例 :当优化器由于新的选择性算法在某些复杂查询(尤其是涉及多列条件、函数、自定义类型时)上产生严重误判,导致执行计划极度劣化时,禁用此改进(=
false)可能迫使优化器使用更稳定的旧逻辑,从而获得可接受的计划。这是一种针对特定SQL的紧急干预手段。
四、小结
| 参数类别 | 主要目的 | 典型使用场景 | 风险与建议 |
|---|---|---|---|
| _fix_control | Bug修复开关 | 精确控制单个或多个Bug修复的启用/禁用。 1. 解决因特定优化器修复导致的性能回退。 2. 绕过新功能引入的错误(如ORA-01417)。 3. 诊断工具(如SQLT XPLORE)用于定位问题根源。 | 高风险。可能关闭重要的安全或稳定性修复。必须在Oracle支持或明确文档指导下使用,并记录原因。 |
| _optimizer_improve_selectivity | 优化器算法开关 | 启用或禁用优化器在选择性估算方面的某种改进算法。 当怀疑优化器因"改进"的选择性计算模型产生严重误判,导致错误执行计划时,尝试回退到旧逻辑。 | 高风险。行为无官方保证,可能影响所有SQL。仅在针对特定问题SQL进行深入诊断后,作为会话级临时测试手段。 |