window.location.reload()会掉参数吗_Exadata设置隐参吗？优化器自动化参数打开吗？...

最新推荐文章于 2023-02-28 14:23:02 发布

weixin_39540271

最新推荐文章于 2023-02-28 14:23:02 发布

阅读量94

点赞数

文章标签： window.location.reload()会掉参数吗打开dbf时自动打开fxp 第二次打开不是最大

今天统一回答两个经常被问到的问题，

Exadata设不设隐参？

虽然有说法在一体机是上建议不要设置任何隐藏参数，但是在实践中我们发现一体机仍然会遇到数据库的bug。这是必然的，一体机的DB和GI大体上和普通平台是没有区别的，所以绝大多数普通平台的bug，在一体机也会有此风险。我们在mos上看到的一体机的问题case，在规避bug的建议中，同样会见到设置隐参来作为临时的解决方案或者最佳实践。

那么有的人为什么说不要设置?

个人认为：

是指的 “不要在没有oracle原厂的支持的指导下设置”

2. 另外一层意思是，bug的触发几率小，而新特性带来的收益大，从总体效应来看，可以接受一点风险，同时一体机的可用性和可靠性也为故障快速恢复，bug快速汇报分析解决提供了保障，总体利大于弊。

但是，如果是已知的critical bug都还强忍着装看不见，不规避，那就是不负责了。所以最终建议还是要在原厂支持的指导下，根据一体机critical issue文档，参考全球案例，了解已知风险和bug，进行分析后，再决定是否配置。

当然，如果只是不重要的业务的DB，随心随性~。

优化器自动化参数打开吗？

首先这些参数目的都是好的，都是为了在第二次执行，甚至“本次执行中”，就纠正不正确的执行计划。

NAME TYPE VALUE

------------------------------------ ----------- ----------------

_optimizer_adaptive_cursor_sharing boolean FALSE

_optimizer_extended_cursor_sharing string NONE

_optimizer_extended_cursor_sharing_r string NONE

_optimizer_use_feedback boolean FALSE

optimizer_adaptive_plans boolean FALSE

optimizer_adaptive_statistics boolean FALSE

_optim_peek_user_binds boolean FALSE

它们都是为了解决过去SQL的历史老大难的问题而生，但是“自动化”，就意味着“自动变化”。但是它们在早期版本的bug，导致dba对自动化的执行计划变化产生了忧虑。

比如说12.2里面的

Bug 28794230 - 12.2 CURSOR MUTEX X DUE TO SQL NOT SHARED BECAUSE OF BIND_EQUIV_FAILURE

它的临时workround就导致“自动化”全家桶被彻底关闭

alter system set "_optimizer_use_feedback"=false scope=spfile;

alter system set "_optimizer_adaptive_cursor_sharing"=false scope=spfile;

alter system set "_optimizer_extended_cursor_sharing_rel"=none scope=spfile;

alter system set "_optimizer_use_feedback"=false;

alter system set "_optimizer_adaptive_cursor_sharing"=false;

alter system set "_optimizer_extended_cursor_sharing_rel"=none;

那么现在打开or不打开?

对于非核心库，小负载库，不要怀疑，全部都开启。随心随性~

对于核心数据库? 什么是核心，即我们几乎无法忍受任何一个sql的性能突变和降级。

那么在11g 的时代，几乎所有的核心库都被DBA改造为执行计划固若金汤，完全不会改变的铁碉堡。那么在升入19c 20c后，能放心打开吗?

答案是很复杂的，即使在完成了多轮spa测试后，我也不能完全保证这些新特性在带来大量好处的同时也带来偶尔一次性能问题，而且业务是在快速的变化。由于历史原因，导致了在11g，10g时代，大量核心系统的执行计划被固定，比如使用大量hint，不收集/改变统计，人工导入/修改统计，设置非常极端multiblock_read_count 或者index_cost_adj(最大可能走索引)，等等都是为了稳定。

那么在新版本下，你可以继续玩这套东西，至少不会给你带来降级。稳定压倒一切。

如果你敢于承受短期的风险，同时有专业人士协助你监控和解决性能问题，那么可以打开，同时把风险降到最小。最佳的场景，如果有sql优化专家长期支持你的核心数据(充分了解业务特点)，在进行多次spa测试，专门的业务测试，那么可以相对顺滑的进入cbo全面自动化时代。