一条SQL语句的执行计划变化探究(r10笔记第9天)

继续上次分析的一个问题,一个简单的SQL语句执行计划有些奇怪,明明可以走唯一性索引但是却走了另外一个索引。
当然了,最后逐步定位,发现是在直方图的地方有一些差别。取消直方图之后,执行计划立刻恢复了正常。
当然问题来了,这个是为什么呢,收集统计信息中的auto选项是什么含义呢。为什么两个数据类型一样的(varchar2(64))的列,境遇却大大不同。
我们来看看一些统计信息的数据。

为了跟进一步验证数据的分布律和选取代价,我们查询它的直方图信息。
SQL>   select to_char(endpoint_value) value,endpoint_number,column_name from dba_tab_histograms where table_name = 'OP_ORDER' and column_name in ('ORDER_ID','USER_ID') ORDER BY endpoint_number;

可以这两条结果对应的查询结果有248行,ORDER_ID只有两行,而USER_ID却又246行,也就意味着USER_ID对应有246个bucket,对于数据的分布情况统计更为周密。
这又是为什么呢,两个字段都是varchar2,怎么会差别这么大呢。
我们取出几条数据来。
SQL> select order_id from ordermob.OP_ORDER where rownum<10;
ORDER_ID
----------------------------------------------------------------
160526163113314574
160526163122274152
160526163130777725
160526164612542552
160526172953321536
160526173306557175
160526173335364777
160526180054556153
160526180101316451
看得出来签名的很多位都是一样的,这种订单业务的数据,订单号都有一定的规范,签名的值还是有一定的规律可循。
SQL>  select to_char(endpoint_value) value,endpoint_number,column_name from dba_tab_histograms where table_name = 'OP_ORDER' and column_name in ('ORDER_ID','USER_ID') ORDER BY endpoint_number
VALUE                                    ENDPOINT_NUMBER COLUMN_NAME
---------------------------------------- --------------- ----------------------------------------
255521615291332000000000000000000000                   0 ORDER_ID
255521616530467000000000000000000000                   1 ORDER_ID
可以看到端点值(endpoint_value),endpoint_value就是列的值,非数字类型(VARCHAR2,CHAR,NVARCHAR2,NCHAR)必须进行转换,仅取前六个字节(不是字符)。从10g实测数据来看取前15个字节,前30个字符有效转换,其他都会忽略。也就是收集直方图相当于只对字段Bsubstr(B,1,30)收集桶信息。
这个信息怎么进行确认呢。我们取出一条数据来测试。
以max(order_id)为例,先取得dump的元数据信息。
SQL> select to_char(substrb(dump(max("ORDER_ID"),16,0,32),1,120))  from "ORDERMOB"."OP_ORDER" t ;
TO_CHAR(SUBSTRB(DUMP(MAX("ORDER_ID"),16,0,32),1,120))
------------------------------------------------------------------------------------------------------------------------
Typ=1 Len=18: 31,36,30,38,32,36,31,35,35,30,33,38,33,35,31,33,32,35
然后进行转换,转换进制。
SQL> select to_number('313630383236313535303338333531','xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx') aa from dual;
                                          AA
--------------------------------------------
        255521616530467185179705496063653169
看看这个转换后的值是否为 255521616530467,也就是转换进制后的前15位保留值。
SQL> select length('255521616530467') from dual;
LENGTH('255521616530467')
-------------------------
                       15
发现确实如此。
而整个串有36位。对于这类场景来看就很难去区分出数据的细粒度差别来。
SQL> select length('255521616530467000000000000000000000') from dual;
LENGTH('255521616530467000000000000000000000')
----------------------------------------------
                                            36
所以对于order_id的直方图信息就会只分配2个bucket,而这个过程如何验证,那就是使用经典的10046事件了。
里面的计算方式 to_char(substrb(dump(max("ORDER_ID"),16,0,32),1,120))  from "ORDERMOB"."OP_ORDER" 正式出自10046的trace文件。
当然可以自己找个环境继续验证一下。
>  create table test_stats (order_id varchar2(64),user_id varchar2(64),channel_id number);
Table created.

> insert into test_stats values('0000000000001241414','test',1);
1 row created.

> insert into test_stats values('0000000000001251414','test2',2);
1 row created.

> insert into test_stats values('0000000000001251514','test3',2);
1 row created.

> commit;
Commit complete.

生成10046事件来查看。
ALTER SESSION SET EVENTS '10046 trace name context forever, level 12'
exec dbms_stats.gather_table_stats(tabname => 'test_stats',ownname => 'TEST',method_opt => 'FOR ALL COLUMNS SIZE AUTO');
ALTER SESSION SET EVENTS '10046 trace name context off'


本页内容版权归属为原作者,如有侵犯您的权益,请通知我们删除。
首先说明_fairness_threshold参数仅在RAC环境下才有意义,让我对这个参数引起关注是在某一次查询v$cr_block_server时,发现该视图有一个名为FAIRNESS_DOWN_CONVERTS的字段,官方文档里将其解释为:Number of times an instance receiving a request has down-converted an X lock on a block because it was not modifying the block 该参数相关性
    今天看到有一个网友提了一个问题,描述很简短     测试DG时,主库不能宕机,如何测试failover?     其实这个需求从业务层面来说是合理的,一个数据量很大的核心数据库,如果需要做灾难演练,就希望在备库上做一下演练工作,而这个演练其实又不想影响到目前的主库,而且又希望能够尽可能模拟真实的情况,我想这样对于运维部门来说是最具有考核力度,而对于开发业务部门来说是最受欢迎的,因为他们什么都不需要改动。 而从技术角度来看,似乎有一些地方需要考量,如果备库Failover为主库,那么这个主库肯定是可以

简单分析percona-zabbix-templates - 2016-09-01 04:09:15

    当Zabbix和Percona两者相遇,会擦出不少的开源火花来,众人拾柴火焰高,最终受益的还是大部分运维人员。     我很早就用过Percona提供的MySQL监控模板,但是却没有刨根问底,只是简单使用而已,自从定制了Orabbix之后,我还是信心满满,MySQL的数据字典相对要少很多,监控起来可能想必Oracle要少很多,不过关于Percona的这个插件,我还是带着好奇之心,内部是否有很多独门秘籍,我想好好学学那些监控项对应的SQL,好好弥补我对于MySQL监控的一些空缺,所以简单分析这个模板就
问题描述 : 近期的 rman 备份中,归档日志的备份没有被删除, rman 的脚本和策略都没变过,归档的备份一直保留,每过一段时间就要物理删除备份,很是奇怪。 rman的 configure 如下 RMAN show all; RMAN configuration parameters for database withdb_unique_name HUBSRAC are: CONFIGURE RETENTION POLICY TO REDUNDANCY 2; CONFIGURE BACKUP OPTI
一 前言  纳西姆.尼古拉斯.塔勒布的经典著作《黑天鹅》中对“黑天鹅现象”的定义是 - 不可预测,人们事前往往低估其发生的可能性 - 造成极大影响 - 事后回头再看,又觉得此事发生的有理 二 分析   稳定性 是一项衡量基础系统是否永续服务的绝对指标,作为资深DBA从业人员,相信大多数公司运维团队都会制定稳定性的SLA指标达到N个9,为用户提供Full-Time 服务。然而前一段时间各种"黑天鹅”式的因素导致一系列的系统故障,严重影响了C端B端的用户的使用体验。 故 障 是数据库系统或者说业务系统的“脆弱
最近有个同事碰到一个问题,想让我给点思路。我大体了解了一下,是一个系统目前在做压力测试,但是经业务反馈发现某个环节的处理时间有些长,排查了一圈,最后这件事情就落在了DB这边,希望DB能够给点意见,是否存在一些性能瓶颈。     我们从开发同学那里得到的一个基本的SQL语句,根据关键字从v$sql中做了提取,发现对应的SQL语句的执行时间还是OK的。 得到的SQL语句如下: SQL_ID        SQL_FULLTEXT ------------- ---------------------------

Oracle之不可见索引 - 2016-08-27 17:08:09

Oracle 之不可见索引 1    BLOG 文档结构图   2    前言部分 2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识, ~O(∩_∩)O~ : ①  Oracle 不可见索引的使用   Tips: ① 本文在 ITpub ( http://blog.itpub.net/26736162 )、博客园 ( http://www.cnblogs.com/lhrbest )和微信公众号( xiaomaimiaolhr )有同步更新
【故障处理】序列 cache 值过小导致 CPU 利用率过高 1    BLOG 文档结构图       2    前言部分 2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~ : ① enq: SQ - contention 等待事件的解决 ② 一般等待事件的解决办法 ③  DFS lock handle 等待事件 ④ 与序列有关的等待事件   Tips: ① 本文在 ITpub ( http://blog.itpub.
这两天做性能测试碰见一个问题,比较有意思。 一条SQL,使用了绑定变量,查看V$SQLAREA发现version_count是2,  查看V$SQL,发现有两条记录,分别对应了0和1两个child cursor:  再查看这两个child cursor对应的执行计划:  child cursor:0 -----------------------------------------------------------------------------------------------------| I

OCP如何查看历史成绩(2) - 2016-08-25 14:08:08

OCP如何查看历史成绩( 2 ) 之前写过一篇文章 OCP如何查看历史成绩: http://blog.itpub.net/26736162/viewspace-1624996/  , 但是现在界面好像有所变动,而且有的连接也找不见了,今天有朋友问如何查询历史的成绩,晚上小麦苗就抽了点时间来找找,顺便记录下来。最近心情不好,不想写技术文章了。       首先登陆网址: https://education.oracle.com/ https://education.oracle.com/pls/eval-e