optimizer_相关参数

SQL> show parameter optimizer_


NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
optimizer_capture_sql_plan_baselines boolean     FALSE
optimizer_dynamic_sampling           integer     2
optimizer_features_enable            string      11.2.0.3
optimizer_index_caching              integer     0
optimizer_index_cost_adj             integer     100
optimizer_mode                       string      ALL_ROWS
optimizer_secure_view_merging        boolean     TRUE
optimizer_use_invisible_indexes      boolean     FALSE
optimizer_use_pending_statistics     boolean     FALSE
optimizer_use_sql_plan_baselines     boolean     TRUE
SQL> 


Thomas建议:
对于许多系统,应到考虑设置这两个参数为非默认值,至少测试一下两种极端情形:
1. optimizer_index_caching=0 和 optimizer_index_cost_adj=100的默认值. 他们一般适用于许多数据仓库/报表系统
2. optimizer_index_caching=90和 optimizer_index_cost_adj=25的设置,他们一般适用于许多事物处理系统/oltp系统.


alter system set optimizer_index_caching=90 scope=spfile;
alter system set optimizer_index_cost_adj=25  scope=spfile;


optimizer_index_cost_adj
这个初始化参数代表一个百分比,取值范围在1到10000之间.
该参数表示索引扫描和全表扫描成本的比较。缺省值100表示:索引扫描成本等价转换与全表扫描成本。


对于数据仓库和DSS系统要反复调整来取一个合理值。
Oracle在选择不同的访问路径时,会对全表扫描和索引扫描进行比较评估,在比较的时候,
Oracle会把索引扫描的成本转换为全表扫描的成本与全表扫描的COST进行比较。这个转换需要一个转换因子,
就是Optimizer_index_cost_adj;
Optimizer_index_cost_adj*(index scan cost)=等价的Full Scan cost


所以 optimizer_index_cost_adj = Full Scan Cost / Index Scan Cost


对于自己的系统到底optimizer_index_cost_adj 的值是多少才是最合适的还是要经过自己的反复测试才确定的,不能盲目的改。




SELECT isses_modifiable, issys_modifiable
  FROM v$parameter
 WHERE name = 'optimizer_index_cost_adj';


ISSES_MODIFIABLE ISSYS_MODIFIABLE
---------------- ----------------
TRUE             IMMEDIATE       
1 row selected.
 --说明该参数可以在session级别动态改变,但不能在system级别动态改变


alter session set optimizer_index_cost_adj=100;
alter session set optimizer_index_cost_adj=1000;


在oltp系统中,可以考虑将optimizer_index_cost_adj参数值设小,使系统倾向于使用索引;在dss系统中,则可以考虑适当将该参数调大,影响oracle的决策过程。


这两个参数,都可以影响CBO对执行计划的选择。
一 Optimizer_index_caching
   Optimizer_index_caching是一个百分比的值,取值范围是0到99(缺省值为0),表示能在内存中找到需要的索引数据的可能性。比如optimizer_index_caching的值为50,CBO就会认为,有50%的可能性能找到所需要的索引数据,并根据这一可能性,估算执行计划的成本,选择执行计划。
二 optimizer_index_cost_adj
   Optimizer_index_cost_adj(adj=adjust)表示索引扫描和全表扫描的比值,取值范围是1-10000,默认值是100。跟optimizer_index_caching一样,这个值也是CBO用来计算成本的,并根据计算出来的成本,选择执行计划。假设optimizer_index_cost_adj的值是60,CBO会认为,索引扫描的成本是全表扫描成本的60%,然后根据这个计算SQL的执行成本。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
`optimizer_trace` 是 PyTorch 中的一个调试工具,用于跟踪和记录优化器的状态和行为。它可以帮助我们更好地了解优化器在训练过程中的表现,识别问题并优化模型的训练速度和稳定性。 当我们在调试和优化深度学习模型时,`optimizer_trace` 可以帮助我们: - 监视和记录梯度的大小和方向,以及在优化过程中的变化; - 跟踪和记录优化器的学习率、动量等超参数的变化; - 观察和记录训练损失的下降情况以及训练精度的提高情况; - 识别潜在的训练问题,如梯度消失、梯度爆炸、欠拟合、过拟合等。 使用 `optimizer_trace` 可以通过以下步骤实现: 1. 创建一个 `Optimizer` 对象,并将其传递给 `optimizer_trace` 函数。 2. 在训练过程中,调用 `optimizer_trace` 函数,传递当前的 `loss` 和 `step`。 3. 在训练结束后,可以使用 `optimizer_trace` 记录的数据进行分析和调试。 示例代码如下: ```python import torch import torch.optim as optim from torch.utils.tensorboard import SummaryWriter # 创建模型和数据集 model = ... train_loader = ... # 定义优化器和学习率 optimizer = optim.SGD(model.parameters(), lr=0.01, momentum=0.9) # 创建 TensorBoard 日志记录器 log_dir = "logs" writer = SummaryWriter(log_dir=log_dir) # 使用 optimizer_trace 记录优化器状态 for epoch in range(num_epochs): for batch_idx, (data, target) in enumerate(train_loader): optimizer.zero_grad() output = model(data) loss = ... loss.backward() optimizer.step() # 使用 optimizer_trace 记录优化器状态 step = epoch * len(train_loader) + batch_idx optimizer_trace(writer, optimizer, loss, step) # 关闭 TensorBoard 日志记录器 writer.close() ``` 最后,我们可以使用 TensorBoard 来可视化 `optimizer_trace` 记录的数据,从而更好地理解优化器的行为和训练模型的表现。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值