盘点 Oracle 11g 中新特性带来的10大性能影响(上)

Oracle的任何一个新版本,总是会带来大量引人瞩目的新特性,但是往往在这些新特性引入之初,首先引起的是一些麻烦,因为对于新技术的不了解、因为对于旧环境的不适应,从Oracle产品到技术服务运维,总是要走过一个磨合的长期过程。

请注意:我们并不推荐大家盲目的关闭和摒弃Oracle的新特性,我们建议大家在遇到问题时,做出适合自己的调整。

就此盘点一下 Oracle 11g 中,那些新特性带来的新烦恼,如果有用户准备或者刚刚踏入这个新版本,则可以作为借鉴。

1.Adaptive direct path read - 自适应的直接路径读

在Oracle Database 11g中有一个新特性,全表扫描可以通过直接路径读的方式来执行(Direct Path Read),这是一个合理的变化,如果全表扫描的大量数据读取是偶发性的,则直接路径读可以避免大量数据对于Buffer Cache的冲击。

可是现实往往是残酷的:在很多业务系统中,全表扫描是普遍存在的常态,将大表的全表扫描全部转化为直接路径读,反而不如Cache在Buffer Cache中效率高,Direct Path Read反而成为了一个严重的负担。

当然对于小表来说,Oracle允许通过Buffer Cache来进行全表扫描,因为这可能更快,也对性能影响不大。小表受到隐含参数:_small_table_threshold 影响。如果表大于 5 倍的小表限制,则自动会使用DPR替代FTS。

如果遇到这个特性的负面影响,可以设置初始化参数: _serial_direct_read 来禁用串行直接路径读,其默认值为AUTO,设置为NEVER时禁用 11g 的自动direct path read的特性。该参数可以动态在实例或会话级别修改,而无需重启实例(可以结合Event 10949设置)。

SQL> alter system set "_serial_direct_read"=auto; SQL> alter system set "_serial_direct_read"=never;

以下的AWR信息是典型的DPR症状,我们看到Direct Path Read在这个报告中处于最占用DB Time的部分:

如果结合ASH报告更加一目了然,显示全表扫描的SQL,都在以Direct Path Read的方式执行 Table Access Full:

2. Adaptive Log File Sync - 自适应的Log File Sync

关于 Log File Sync 等待的优化,在Oracle数据库中一直是常见问题,LOG FILE的写出性能一旦出现波动,该等待就可能十分突出。

在Oracle 11.2.0.3 版本中,Oracle 将隐含参数 _use_adaptive_log_file_sync 的初始值设置为 TRUE,由此带来了很多 Log File Sync 等待异常的情况,这个问题虽然由来已久,但是仍然有很多Oracle的用户并不知情。

当前台进程提交事务(commit)后,LGWR需要执行日志写出操作,而前台进程因此进入 Log File Sync 等待周期。

在以前版本中,LGWR 执行写入操作完成后,会通知前台进程,这也就是 Post/Wait 模式;在11gR2 中,为了优化这个过程,前台进程通知LGWR写之后,可以通过定时获取的方式来查询写出进度,这被称为 Poll 的模式,在11.2.0.3中,这个特性被默认开启。这个参数的含义是:数据库可以在自适应的在 post/wait 和 polling 模式间选择和切换。

_use_adaptive_log_file_sync 参数的解释就是: Adaptively switch between post/wait and polling ,正是由于这个原因,带来了很多Bug,反而使得 Log File Sync 的等待异常的高,如果你在 11.2.0.3 版本中观察到这样的表征,那就极有可能与此有关。

在遇到问题是,通常将 _use_adaptive_log_file_sync 参数设置为 False,回归以前的模式,将会有助于问题的解决。

3. Adaptive Cursor Sharing - 自适应游标共享

Oracle数据库的SQL使用的是共享机制,通过绑定变量可以使Oracle DB 可以为多条SQL 语句共享单个游标,以减少分析SQL 语句所使用的共享内存和CPU资源等。

然而一个执行计划并不总是适用于所有绑定值,为了尽可能生成准确的执行计划,Oracle Database 11g 引入了自适应游标共享的新特性,在执行共享SQL时考虑更多的因素,如果与资源开销相比,使用多个执行计划所带来的收益更重要,则会为使用绑定变量的每条SQL 语句生成多个执行计划。

Adaptive Cursor Sharing 通过自适应游标共享,可以仅针对使用绑定变量的语句智能地共享游标。但是有时候这个特性会使得确定的执行计划变得不稳定,如果你确定系统中无需额外自适应的分析和变更执行计划,或者可能被不稳定的执行计划影响。那么可能需要调整这个特性的使用。

关闭这个特性,可以设置隐含参数:

SQL> alter session set"_optimizer_extended_cursor_sharing_rel"=none; SQL> alter session set"_optimizer_extended_cursor_sharing"=none; SQL> alter session set"_optimizer_adaptive_cursor_sharing"=false;

4.Oracle 11g 密码延迟认证

在 Oracle 11g 中,为了提升安全性,Oracle 引入了『密码延迟验证』的新特性。这个特性的作用是,如果用户输入了错误的密码尝试登录,那么随着登录错误次数的增加,每次登录前验证的时间也会增加,以此减缓可能对于数据库重复的口令尝试攻击。

但是对于正常的系统,由于口令的更改,可能存在某些被遗漏的客户端,不断重复尝试,从而引起数据库内部长时间的 Library Cache Lock的等待,这种情形非常常见。

如果遇到这一类问题,可以通过Event 28401关闭这个特性,从而消除此类影响,以下命令将修改设置在参数文件中:

ALTER SYSTEM SET EVENT = '28401 TRACE NAME CONTEXT FOREVER, LEVEL 1' SCOPE = SPFILE;

出现这类问题非常典型的AWR报告呈现如下,首先在 TOP 5 中,你可能看到显著的 Library Cache Lock 的等待,以下范例来自11.2.0.3.0版本的真实情况:

在这类情况下,时间模型 - Time Model 中会显示如下指标,其中 connection management call elapsed time 占据了主要的DB Time,这个等待直接表明是在建立数据库连接时产生的:

这类问题,在Oracle的11g中是常见和确定的,在MOS上可以找到相应的记录:High 'library cache lock' Wait Time Due to Invalid Login Attempts(1309738.1)此外Oracle 11g开启了密码大小写验证,如果从Oracle 10g升级过来,需要特别的当心这个变化,通过初始化参数SEC_CASE_SENSITIVE_LOGON 可以来控制这个特性。

5. _datafile_write_errors_crash_instance - 文件写错误终止实例

从Oracle 11.2.0.2版本开始,一个新的隐含参数 - _datafile_write_errors_crash_instance 被引入到数据库中,通过这个参数名就可以了解到其含义:当发生数据文件写错误时,Crash数据库实例。

为什么要引入这个参数呢?这个参数后台解决的是什么问题呢?

我在《数据安全警示录》一书上曾经写过多个案例,在归档模式下当发生文件(非SYSTEM文件)写错误时,Oracle会自动将数据文件离线,这造成了很多灾难,类似的错误日志可能是这样的:

Fri Jan 13 19:32:21 2013 KCF: write/open error block=0xf1fa6 online=1 file=73 /dev/rods_gm05 error=27063 txt: 'IBM AIX RISC System/6000 Error: 22: Invalid argument Additional information: -1 Additional information: 557056' Automatic datafile offline due to write error on file 73: /dev/rods_gm05

鉴于很多用户遇到的困境,Oracle做出了修正,这一修正在MOS上以BUG形式被提交,其内容为:Bug 7691270 Crash the DB in case of write errors (rather than just offline files) 。

在11.2.0.2之前,如果数据库运行在归档模式下,并且写错误发生在非SYSTEM表空间文件,则数据库会将发生错误的文件离线,在从11.2.0.2开始,数据库会Crash实例以替代Offline。注意:在非归档模式下或者SYSTEM遭受错误时,数据库会直接崩溃。

好了,现在答案清楚了:为了解决数据文件损失,离线控制存在的不确定性风险,Oracle引入的 _datafile_write_errors_crash_instance 控制数据库实例直接崩溃。

如果你不能接受这一选择,那么设置参数 _datafile_write_errors_crash_instance 为False。


原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2017-08-02

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Jed的技术阶梯

Confluent 入门

Confluent平台是一个可靠的,高性能的流处理平台,你可以通过这个平台组织和管理各式各样的数据源中的数据。

2076
来自专栏杨建荣的学习笔记

Data Guard高级玩法:通过闪回恢复switchover主库 (r10笔记第13天)

最近又试了下Data Guard的新玩法,可以通过闪回恢复switchover的主库,这种场景听起来比较特别,但是Oracle依旧支持。 我们的...

3167
来自专栏北京马哥教育

两大Linux发行版迎来大幅更新 Debian 9及Fedora 26 Beta终于发布

Debian 9终于发布 Debian 发行版宣布正式释出代号为 Stretch 的 Debian 9,该版本将提供五年的支持。Stretch 将专门献给于 2...

2844
来自专栏数据和云

故障分析:一则library cache lock问题处理

编辑手记:library cache lock 大家都并不陌生,在MOS上对该阻塞的一般成因描述为:一般可以理解的是alter table或者alter pac...

3435
来自专栏后端之路

mybatis 批量更新

此前的方案在做批量时使用mybatis提供的batch model,该模式下将推迟所有的update(包括insert和delete)语句直到提交事务或者遇到一...

4309
来自专栏文渊之博

关于tempdb的一些注意事项

    由于数据库的文件的位置对于I/O性能如此重要,以至于在创建主数据文件的文职时,需要考虑tempdb性能对系统性的影响,因为它是最动态的数据库,速度还需要...

1846
来自专栏杨建荣的学习笔记

关于oracle中session跟踪的总结(56天)

数据库中的session在操作中可能会有各种各样的问题,比如一条sql语句执行失败,某一个应用在一些特定的场景下就会有一些性能问题等等,有时候在代码层去做一些d...

2773
来自专栏数据和云

【动手实践】Oracle 12.2 新特性:自动的列表分区创建

2017年来了,我们要启动新的学习征程了。在过去我们一直思考,什么样的内容能够更帮助大家了解和学习到有用的知识? 这个『动手实践』栏目就是这样一个改进和尝试吧,...

2706
来自专栏数据和云

时过境迁:Oracle跨平台迁移之XTTS方案与实践

作者简介 ? 谢金融 云和恩墨东区交付部 Oracle 工程师,多年来从事 Oracle 第三方服务,曾服务过金融、制造业、物流、政府等许多行业的客户,精通数据...

43010
来自专栏Jackson0714

【T-SQL性能优化】01.TempDB的使用和性能问题

33813

扫码关注云+社区