这篇外传之前有这么几篇文章: 《一个执行计划异常变更的案例 - 前传》 《一个执行计划异常变更的案例 - 外传之绑定变量窥探》
我们知道,由于绑定变量窥视(Bind Peeking)功能,SQL文在进行硬解析(Hard Parse)时,会代入绑定变量的值来估算选择基数(cardinality )并做成执行计划,而相同的SQL文以后在执行过程中,都会共享初次执行时做成的执行计划。
上一篇文章《一个执行计划异常变更的案例 - 前传》(http://blog.csdn.net/bisal/article/details/53750586),介绍了一次执行计划异常变更的案例现象,这两天经过运行同事,以及罗大师的介绍,基本了解了其中的原因和处理方法,这个案例其实比较典型,涉及的知识点很多,有数据库新特性,有SQL相关的,还有应用数据质量问题,对于大师来说,是信手拈来的一次问题排查和处理,但至少对我这个仍旧艰难前行的初学者来说,值得回味的地方很丰富,所以有必要针对其中涉及的知识点做一下梳理,其中一些知识我之前了解的并不全面和深入,就自身来讲,整理学习一次,也是对自己的锻炼。
本文为自适应游标共享(Adaptive Cursor Sharing)功能的第二部分,主要介绍ACS有效时的状况例子,以及ACS处理流程。
作者简介: 刘晨,网名bisal,Oracle 10g/11g OCM,并国内首批Oracle YEP成员, 博客:blog.itpub.net/bisal 案例介绍 今天快下班的时候,几位兄弟来聊一
前文回顾: 一个执行计划异常变更的案例(上) 上篇文章我们说了,绑定变量实际是一些占位符,可以让仅查询条件不同的SQL语句可以重用解析树和执行计划,避免硬解析。绑定变量窥探则是第一次执行SQL硬解析时,会窥探使用的绑定变量值,根据该值的分布特征,选择更合适的执行计划, 其缺点在于如果绑定变量列值分布不均匀,由于只有第一次硬解析才会窥探,所以可能接下来的SQL执行会选择错误的执行计划。 有时可能我们需要查看某条SQL使用了什么绑定变量值,导致执行计划未用我们认为最佳的一种。 方法一:10046 使用level
本文作者系流浪的金鱼(花名),甲骨文数据库工程师。个人主页:https://blog.csdn.net/rishairu1,经其本人授权发布。
绑定变量分级(Bind Graduation)是指Oracle在PL/SQL代码中会根据文本型绑定变量的定义长度而将这些文本型绑定变量分为四个等级,不同等级分配的内存大小不同,如下表所示:
今天快下班的时候,几位兄弟来聊一个问题,大致是昨天应用使用的数据库突然出现性能问题,DBA发现有一些delete语句执行时间骤长,消耗大量系统资源,导致应用响应时间变长积Q。目前掌握的信息如下: (1) 应用已经很久未做过更新上线了。 (2) 据开发人员反馈,从之前的应用日志看,未出现处理时间逐步变长的现象。 (3) 这是一套RAC+DG的环境,版本未知,猜测至少应该是11g的版本。 (4) 这次突然出现大量执行时间超长的SQL语句,是一系列delete语句,例如delete from table where key=:1or key=:2 … key=:13这种SQL,应用正常的处理逻辑中都会使用这条语句,因此并发较高,使用了绑定变量,key字段不是主键,但有索引。目前尚不知晓字段是否存在直方图。 (5) 表的数据量大约5000万,初步反馈得知key=0的记录大约1500万,执行时间超长的SQL语句都使用了key=0的条件,至于key=0的真实数据量,以及出现问题的SQL语句使用的绑定变量具体值,这些还需要开发再次确认。 (6) DBA反馈SQL语句执行计划发生了变化,从数据库层面做了一些操作后,问题解决,目前尚不知晓做了什么具体的操作。
编辑手记:在SQL执行的过程中,选择不同的执行计划所产生的性能差异非常大,因此能够符合业务地选择正确的执行计划非常重要。但在真实环境中,总会受到一些因素的影响,今天我们来分析谓词越界和绑定变量窥探对SQL执行计划的影响。 案例场景 最近有一客户晚上新导入了一批数据到数据库中,第二天发现业务变慢,主要是其中有一条核心业务SQL执行计划走错导致。 结果排查发现客户在导入数据后并未重新收集统计信息,SQL使用绑定变量,窥探的变量刚好是越界,导致SQL第一次硬解析生成的执行计划走错。再加上10G的库导致接下
使用Oracle数据库的应用系统,有时出现SQL性能突然变差,特别是对于OLTP类型系统执行频繁的核心SQL,如果出现性能问题,通常会影响整个数据库的性能,进而影响整个系统的正常运行。这是常常遇到的问题,也是一些DBA的挑战。 SQL性能变差原因分析 SQL的性能变差,通常是在SQL语句重新进行了解析,解析时使用了错误的执行计划出现的。 下列情况是SQL会重新解析的原因: SQL语句没有使用绑定变量,这样SQL每次执行都要解析。 SQL长时间没有执行,被刷出SHARED POOL,再次执行时需要重新解析。
之前的几篇文章: 《一个执行计划异常变更的案例 - 前传》 《一个执行计划异常变更的案例 - 外传之绑定变量窥探》 《一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法》 《一个执行计划异常变更的案例 - 外传之rolling invalidation》 《一个执行计划异常变更的案例 - 外传之聚簇因子(Clustering Factor)》 《一个执行计划异常变更的案例 - 外传之查询执行计划的几种方法》 《一个执行计划异常变更的案例 - 外传之AWR》 《一个执行计划异常变更的案例 - 外传之ASH》 《一个执行计划异常变更的案例 - 外传之SQL AWR》 《一个执行计划异常变更的案例 - 外传之直方图》 《一个执行计划异常变更的案例 - 外传之SQL Profile(上)》 《一个执行计划异常变更的案例 - 外传之SQL Profile(下)》
当我们需要找到某条使用绑定变量的SQL语句中具体用到的参数值时,通常会使用v$sql_bind_capture视图,如果是字符串类型的变量,直接检索即可,
客户新业务上线(数据库版本为 10.2.0.5)一段时间后,系统CPU都在20%左右。19日,系统CPU使用率突然接近100%,交易处理速度也严重下降。20日凌晨1:15分之后,系统CPU突然又降到20%左右,交易速度也有大幅提高(只有几毫秒);
我们知道,Oracle在传统的OLTP(在线事务处理)类系统中,强烈推荐使用绑定变量,这样可以有效的减少硬解析从而增加系统的并发处理能力。甚至在有些老旧系统,由于在开始开发阶段缺乏认识没有使用到绑定变量,后期并发量增长且无法改造程序时,运维DBA还会不得已去设置cursor_sharing=force来强制使用系统的绑定变量(这是一个万不得已的方案,并不是最佳实践)。
今天查看awr报告的时候,发现一条sql语句异常。 Elapsed Time (s) Executions Elapsed Time per Exec (s) %Total %CPU %IO SQL Id SQL Module SQL Text 6,621.0523,310.522.3510.0993.140cdthzpx2jn4qJDBC Thin ClientSELECT MEMO_ID FROM MEMO W... sql语句很简单。 SELECT MEMO_ID FROM MO1_MEMO WH
自适应游标共享Adaptive Cursor Sharing或扩展的游标共享(Extended Cursor Sharing)是Oracle 11g的新特性之一,主要用于解决以前版 本中由于绑定变量窥探导致SQL语句无法获得最佳执行计划的缺陷,即能够对效率低下的游标(子游标)进行自动识别而选择最佳的执行计划。本 文详细描述了自适应游标共享并给出示例。 有关绑定变量窥探请参考:Oracle 绑定变量窥探
编辑手记:library cache lock 大家都并不陌生,在MOS上对该阻塞的一般成因描述为:一般可以理解的是alter table或者alter package/procedure会以X模式持有library cache lock,造成阻塞(444560.1)。但针对具体问题仍要具体分析,今天分享一则因SQL绑定变量出现空值,导致大量子游标产生并引发library cache lock 的故障,供大家参考借鉴。 请故障现象及影响 某数据库为Oracle 11.2.0.3.9 RAC Linux 64
优化器(Optimizer )是Oracle数据库最重要的部件之一,随着Oracle数据库每个新版本的发布,优化器都会得到增强并追加一些新功能,本文将针对各个版本出现的新特性背景和发展进行简单介绍.
通常在高并发的OLTP系统中,可能会出现这样的现象,单个SQL的写法、执行计划、性能都是没问题的,但整个系统的性能就是很差,这表现在当系统并发的数量增加时,整个系统负载很高,CPU占用率接近100%。其实,这种系统性能随着并发量的递增而显著降低的现象,往往是因为这些系统没有使用绑定变量而产生了大量的硬解析所致。因为同一条SQL语句仅仅由于谓词部分变量的不同而在执行的时候就需要重新进行一次硬解析,造成SQL执行计划不能共享,这极大地耗费了系统时间和系统CPU资源。那么怎样才能降低OLTP应用系统的硬解析的数量呢?答案就是使用绑定变量。高并发的OLTP系统若没有使用绑定变量则会导致硬解析很大,这在AWR中的Load Profile部分可以很容易的看出来。
作者简介 刘晨,网名bisal,Oracle 10g/11g OCM,并国内首批Oracle YEP成员,博客:blog.itpub.net/bisal 很多人在做一些表设计时会留出几个reverse
如果说性能优化是数据库技术中的明珠,那么索引无疑是其中最耀眼的一颗,特别是OLTP业务数据库。掌握了索引技术,基本上性能就不会有太大的问题。
以上只是列举了一部分索引(B-Tree索引)不能被使用的一些情况,应该还有一些不常见的情形,比如在字符串字段上创建了desc 降序索引,like 'xxxx%'这种sql就无法使用这个降序索引,加hint也不行;reverse key反向键索引在范围查询无法使用等,欢迎大家留言补充。同时也欢迎有识之士批评指正。
最近单位搬家,从国家会议中心,搬往空气清新的顺义后沙峪,搬迁之前的完结上线中,碰见了一些棘手的问题,有一些值得借鉴的地方。
绑定变量窥探的副作用就在于,使用了绑定变量的目标SQL只会沿用之前硬解析时所产生的解析树和执行计划,即使这种沿用完全不适合于当前的情形。在Oracle 10g及其后续的版本中,Oracle会自动收集直方图统计信息,这意味着与之前的版本相比,在Oracle 10g及其后续的版本中Oracle有更大的概率会知道目标列实际数据的分布情况,也就是说绑定变量窥探的副作用将会更加明显。当Oracle执行绑定变量窥探操作时绑定变量所对应的输入值是否具有代表性就至关重要了(这里“代表性”是指该输入值所对应的执行计划和该SQL在大多数情况下的执行计划相同),因为这会直接决定此目标SQL在硬解析时所选择的执行计划,进而决定后续以软解析/软软解析重复执行时所沿用的执行计划。
Python中的延迟绑定是指在嵌套函数中,内部函数在被调用时才会绑定外部函数的变量,而不是在定义内部函数时就绑定。这种绑定方式可以导致一些出乎意料的行为,因为变量的值是在函数调用时决定的,而不是在函数定义时。
现在我们经常可以看到一些网站会有类似暗黑模式/白天模式的主题切换功能,效果也是十分炫酷,在平时的开发场景中也有越来越多这样的需求,这里大致罗列一些常见的主题切换方案并分析其优劣,大家可根据需求综合分析得出一套适用的方案。
以上列出了当前系统所支持的shell类型。查看shell的历史我们可以知道,我们通常所说的bash shell(bash)全称为GNU Bourne-Again SHell。在目前的发行版中,sh已经成为bash的一个软连接。在man sh的时候大家都会发现,其实man出来的手册时bash的内容。
-多年互联网运维工作经验,曾负责过大规模集群架构自动化运维管理工作。 -擅长Web集群架构与自动化运维,曾负责国内某大型金融公司运维工作。 -devops项目经理兼DBA。 -开发过一套自动化运维平台(功能如下): 1)整合了各个公有云API,自主创建云主机。 2)ELK自动化收集日志功能。 3)Saltstack自动化运维统一配置管理工具。 4)Git、Jenkins自动化代码上线及自动化测试平台。 5)堡垒机,连接Linux、Windows平台及日志审计。 6)SQL执行及审批流程。 7)慢查询日志分析web界面。
在 Oracle 数据库中,LIKE 操作是一种常用的模糊匹配方式,用于在字符串中查找符合指定模式的数据。然而,当处理大量数据时,使用 LIKE 操作可能导致查询性能下降。为了提高数据库的效率,本文将重点介绍如何优化使用 LIKE 操作的查询。
版权声明:本文为耕耘实录原创文章,各大自媒体平台同步更新。欢迎转载,转载请注明出处,谢谢
从如下查询结果可以看到目标SQL对应的列VERSION_COUNT的值从之前的5变为了现在的6,列EXECUTIONS的值为7,说明Oracle在第7次执行目标SQL时依然用的是硬解析。从查询结果可以看到,Oracle此时新生成了一个CHILD_NUMBER为5的Child Cursor,并且把存储相同执行计划的CHILD_NUMBER为4的原有Child Cursor标记为非共享。
之前的几篇文章: 《一个执行计划异常变更的案例 - 前传》 《一个执行计划异常变更的案例 - 外传之绑定变量窥探》 《一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法》 《一个执行计划异常变更的案例 - 外传之rolling invalidation》 《一个执行计划异常变更的案例 - 外传之聚簇因子(Clustering Factor)》 《一个执行计划异常变更的案例 - 外传之查询执行计划的几种方法》 《一个执行计划异常变更的案例 - 外传之AWR》
之前的几篇文章: 《一个执行计划异常变更的案例 - 前传》 《一个执行计划异常变更的案例 - 外传之绑定变量窥探》 《一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法》 《一个执行计划异常变更的案例 - 外传之rolling invalidation》 《一个执行计划异常变更的案例 - 外传之聚簇因子(Clustering Factor)》 《一个执行计划异常变更的案例 - 外传之查询执行计划的几种方法》
namespace,称之为命名空间,是名称和对象之间的映射,通常以字典的形式保存变量名和其所指代的变量值之间的映射关系。
在Oracle中存在两种类型的SQL语句: 一类为 DDL语句(数据定义语言)CREATE,DROP,ALTER,他们是从来不会共享使用的,也就是每次执行都需要进行硬解析。 一类就是DML语句(数据操纵语言)INSERT,UPDATE,DELETE,SELECT,他们会根据情况选择要么进行硬解析,要么进行软解析。
1、绑定变量是会话级别,因此连接间不能共用绑定变量句柄。同样,如果连接断裂,原来的句柄就不能再使用了。(连接池和持续连接可以在一定程度上缓解这个问题)
对同一个 SQL 语句的 ExplainPlan 里显示的预估执行计划与通过 V$SQL_PLAN 视图获取的 Runtime Plan 真实执行计划,偶尔会发现两边有不一致的情况,为什么呢?为什么预估执行计划会不准确?怎样才能避免这种情况的发生?
刚做完一次网络切换支持,得空写一篇,其实今儿取了巧,这篇文章是之前写过的,碰巧又是这次“执行计划异常变更”案例涉及的一个知识点,所以再次翻出来。
Oracle 硬解析与软解析是我们经常遇到的问题,什么情况会产生硬解析,什么情况产生软解析,又当如何避免硬解析?下面的描述将给出
之前的几篇文章: 《一个执行计划异常变更的案例 - 前传》 《一个执行计划异常变更的案例 - 外传之绑定变量窥探》 《一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法》 《一个执行计划异常变更的案例 - 外传之rolling invalidation》 《一个执行计划异常变更的案例 - 外传之聚簇因子(Clustering Factor)》 《一个执行计划异常变更的案例 - 外传之查询执行计划的几种方法》 《一个执行计划异常变更的案例 - 外传之AWR》 《一个执行计划异常变更的案例 - 外传之ASH》 《一个执行计划异常变更的案例 - 外传之SQL AWR》 《一个执行计划异常变更的案例 - 外传之直方图》 《一个执行计划异常变更的案例 - 外传之SQL Profile(上)》
一 问题概要 对同一个 SQL 语句的 ExplainPlan 里显示的预估执行计划与通过 V$SQL_PLAN 视图获取的 Runtime Plan 真实执行计划,偶尔会发现两边有不一致的情况,为什么呢?为什么预估执行计划会不准确?怎样才能避免这种情况的发生? 二 问题解答 这是执行计划相关中会被经常问道的问题,也是困扰自己很长时间的问题。希望通过下面的分析能解释一部分原因。 对同一个 SQL 语句的 ExplainPlan 里显示的预估执行计划与通过 V$SQL_PLAN 视图获取的真实执行计划不
某一客户单位的网站首页被篡改,并收到网监的通知说是网站有漏洞,接到上级部门的信息安全整改通报,贵单位网站被植入木马文件,导致网站首页篡改跳转到caipiao网站,根据中华人民共和国计算机信息系统安全保护条例以及信息安全等级保护管理办法的规定,请贵单位尽快对网站漏洞进行修复,核实网站发生的实际安全问题,对发生的问题进行全面的整改与处理,避免网站事态扩大。我们SINE安全公司第一时间应急响应处理,对客户的网站进行安全检测,消除网站安全隐患。
通过调用SQL修复顾问(SQL Repair Advisor),能够诊断和修复SQL相关的问题。
题记:这是某移动运营商在SQL线下审核项目中,协助开发商完善数据库性能的过程。以往开发商遇到此问题总是怀疑是数据库的Bug,试图尝试重启Tuxedo、Weblogic,严重时甚至重启实例来缓解问题。经过下面的详细分析,你会发现事实并非如此。 详细诊断过程 背景:这是对于两个节点的RAC环境,数据库版本为11.2.0.4 for HP-UX IA(64-bit)。在2014年11月5日16点至18点间,节点一的CPU使用率从平时的40%增长到60%左右,部分业务办理缓慢甚至超时。经过详细分析,发现是一个低效
一、标准的流程控制 if: 将一个判断表达式作为它的第一个参数进行求值。如果求值为true,那么就返回它的第二个参数(相当于“then”子句)的求值结果。如果结果为false(包括nil)就返回第三个参数的求值结果(相当于“else”子句),前提是有提供第三个参数并且不为空。
SQL的处理主要包括解析(parse)、执行(execute)、提取(fetch)几个步骤。
近年来,越来越多的AR草图绘制工具使用户能够在现实世界中绘制和嵌入草图。比如像SymbiosisSketch,这些工具使用户可以绘制数字元素并将其嵌入到现实世界中。
之前的几篇文章: 《一个执行计划异常变更的案例 - 前传》 《一个执行计划异常变更的案例 - 外传之绑定变量窥探》 《一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法》 《一个执行计划异常变更的案例 - 外传之rolling invalidation》 《一个执行计划异常变更的案例 - 外传之聚簇因子(Clustering Factor)》 《一个执行计划异常变更的案例 - 外传之查询执行计划的几种方法》 《一个执行计划异常变更的案例 - 外传之AWR》 《一个执行计划异常变更的案例 - 外传之ASH》 《一个执行计划异常变更的案例 - 外传之SQL AWR》 《一个执行计划异常变更的案例 - 外传之直方图》
讲师简介: 罗海雄 云和恩墨性能优化总监 ITPUB论坛数据库管理版版主,2012 ITPUB全国SQL大赛冠军得主,他还是资深的架构师和性能优化专家,对 SQL 优化和理解尤其深入;从开发到性能管理
领取专属 10元无门槛券
手把手带您无忧上云