Skip to content

Oracle

关于升级至12cR2版本的Optimizer 自适应特性的设置建议

优化器自适应特性的设置是需要考虑比较慎重的一个点,oracle的产品经理 Nigel Bayliss 也公布了几篇关于此方面的设置参考,具体如下(建议看下参考文档):

情景1

从Oracle Database 11g(或更早版本)升级

将数据库升级到Oracle Database 12c第2版后,建议使用默认的自适应功能设置。为此,只需在数据库的初始化参数文件中不包含任何自适应功能参数。换句话说,不需要设置optimizer_adaptive_plansoptimizer_adaptive_statistics

把事情简单化!

 

场景2

从Oracle Database 12c第1版升级,其中应用了21171382和22652097的修补程序。

这两个补丁使Oracle Database 12c第1版数据库能够使用与Oracle Database 12c第2版相同的自适应功能设置。

可以升级带有这些补丁的Oracle Database 12c第1版数据库,而无需更改任何自适应功能设置。

或者,如果没有使用推荐的默认值预升级,并且希望在升级后使用,那么建议如下设置:

  • 从数据库初始化参数文件中删除对optimizer_adaptive_plansoptimizer_adaptive_statistics的引用。
  • 确保使用DBMS_STATS.SET_GLOBAL_PREFS将DBMS_STATS首选项
  • AUTO_STAT_EXTENSIONS设置为OFF

场景3

尚未应用从Oracle Database 12c第1版升级以及21171382和22652097的修补程序。

如果在Oracle数据库12c的第1版禁用了自适应功能(通过设置,例如,optimizer_adaptive_features到FALSE),那么而是使用Oracle数据库12c的第2版默认设置。为此,需要检查初始化参数文件,如下所示:

  • 删除对optimizer_adaptive_features参数的引用(它在Oracle Database 12c第2版中已过时)。
  • 删除用于禁用各种自适应功能的任何修复控件和隐藏参数设置。固定控制像12914055,12914055和7452863以隐藏参数等一起被典型地使用_optimizer_dsdir_usage_control_sql_plan_directive_mgmt_control
  • 无需设置optimizer_adaptive_plansoptimizer_adaptive_statistics,因为默认值是建议值。

如果在Oracle Database 12c第1版数据库中启用了自适应功能,并且想在数据库升级后以相同方式继续使用这些功能,则:

  • 从 初始化文件中删除对optimizer_adaptive_features的引用
    (在Oracle Database 12c第2版中已过时)。
  • optimizer_adaptive_statistics = TRUE添加到初始化参数文件中(并且不需要设置optimizer_adaptive_plans,因为默认值为TRUE)。
  • 使用DBMS_STATS.SET_GLOBAL_PREFS将DBMS_STATS首选项
  • AUTO_STAT_EXTENSIONS设置为ON

 

参考文档:

https://blogs.oracle.com/optimizer/optimizer-adaptive-features-and-upgrading-to-oracle-database-12c-release-2

https://blogs.oracle.com/optimizer/the-oracle-12102-october-2017-bp-and-the-adaptive-optimizer

https://mikedietrichde.com/2017/07/06/adpative-features-patches-oracle-peoplesoft/

oracle 12c/18c 关于升级和迁移的几种常见场景详细执行步骤

 

如下为可能会碰到的涵盖非CDB和PDB / CDB互相升级迁移的场景,针对11g,12c和18c适用,对应官方的详细执行步骤:

(11.2.0.3之后的版本适用)

 

  • 将非CDB迁移和转换为具有不同Endian操作系统的PDB 
    HTML 
    PDF 
  • 使用不同的Endian操作系统将非CDB迁移到新服务器,同版本
    HTML 
    PDF 
  • 使用不同的Endian操作系统和相同版本
    HTML 
    PDF 
  • 使用相同的操作系统将非CDB迁移到新服务器并升级(跨版本)
    HTML 
    PDF 
  • 使用相同的操作系统将非CDB迁移到新服务器并使用
    HTML 
    PDF 
  • 将PDB拔出,插入和升级到新的CDB 
    HTML 
    PDF 
  • 使用相同的操作系统将非CDB升级和转换为PDB 
    HTML 
    PDF 
  • 在同一系统上升级非CDB 
    HTML 
    PDF 
  • 在同一系统上并行升级PDB 
    HTML 
    PDF 

Oracle 12.2.0.1 and 18c 的原厂支持周期

一般我们确认oracle 数据库某个版本的支持周期都是通过mos 742060.1的文档来获悉,

MOS Note: 742060.1.: Release Schedule of Current Database Releases

但目前在该文档中目前并未提及oracle 18c的支持周期。如下图:

Clarification: Support Periods for Oracle 12.2.0.1 and 18c

 

20187月23日,Oracle在内部发布了Oracle Database 18c 18.3.0。从此日期开始,已确定上一版本的 Oracle数据库12.2.0.1支持(如下图),Oracle 12.2.0.1的修补结束日期定在2020年7月23日,据mike dietrich 描述Oracle 18c也会发生同样的事情,一旦Oracle 19c在内部可用,将确定并公布Oracle 18c的修补结束日期。从特定日期算起至少两年 – 而不是从Oracle 18c发布之日起。

 

澄清:Oracle 12.2.0.1和18c的支持期

 

在这里需要提到的是 可以通过Oracle lifetime support的手册来获取更多关于支持周期的信息

http://www.oracle.com/us/support/library/lifetime-support-technology-069183.pdf

 

How to recreate idl_ub1$,idl_char$,idl_ub2$,idl_sb4$.

近期遭遇一个客户误truncate idl_ub1$表,导致数据库关闭后无法启动,在受到支援请求后在1小时内解决了此问题,遭遇了此类问题的处理方式主要如下,

以upgrade方式打开数据库,并截断相关表

startup upgrade
truncate table idl_ub1$;
truncate table idl_char$;
truncate table idl_ub2$;
truncate table idl_sb4$;

接着执行utlirp和rmjvm两个脚本,并关闭数据库

@c:\oracle\product\10.2.0\db_1\rdbms\admin\utlirp
shutdown immediate
startup upgrade
@c:\oracle\product\10.2.0\db_1\javavm\install\rmjvm
shutdown immediate
exit

 

再次启动数据库后,设置监听为临时不可用状态并依据数据库组件状态运行相关脚本

startup upgrade
alter system set "_system_trig_enabled"=false scope=memory;

@c:\oracle\product\10.2.0\db_1\javavm\install\initjvm.sql
-- 如果xml已经安装执行此脚本
@c:\oracle\product\10.2.0\db_1\xdk\admin\initxml.sql
@c:\oracle\product\10.2.0\db_1\xdk\admin\xmlja.sql
@c:\oracle\product\10.2.0\db_1\rdbms\admin\catjava.sql
--

shutdown immediate
exit

 

启动数据库并执行ultrp修复失效对象,运行编译修复后,修复完成。

startup upgrade
@c:\oracle\product\10.2.0\db_1\rdbms\admin\utlrp
exit

SQLPLUS / AS SYSDBA
shutdown immediate
startup
execute utl_recomp.recomp_serial();
exit

Adaptive Log File Sync Optimization in 12c

参数“_use_adaptive_log_file_sync”在11gR2中引入,用于控制是在线日志相关进程自适应同步的开启和关闭。
在11.2.0.1和11.2.0.2中,参数的默认值为false。从11.2.0.3开始,默认值已更改为true,“_use_adaptive_log_file_sync”是一个动态参数,可以在系统级别更改。

ALTER SYSTEM SET“_use_adaptive_log_file_sync”= <FALSE / TRUE> scope = <both / spfile / memory>;

该特性的原理可以参考MOS 1541136.1。当此特性被开启后,可以在awr中的other instance activity stats中的redo synch poll writes,redo synch polls观察到。

在12.1.0.2版本之前建议关闭该特性,项目中遇到不少关于此特性造成的性能问题。

 

已知的bug:

13707904

13074706

25178179