支援武汉抗疫公益培训-oracle性能优化工具与实战

本次公益培训实际报名人数203人(报名时间截止后仍有将近100人报名),学员来自国内各大知名厂商,主要有海量数据、海天起点、中亦安图、oracle原厂、瀚高软件、H3C、云和恩墨、东方龙马、朗新科技、万达信息、沃趣、华资、新炬、浪潮、神州数码、东软、美创、亚信、华为、太极、新大陆、天玑、用友、埃森哲、富士康等,其他行业客户包括ICBC、HSBC、城商行、农商行、通信运营商、保险、证券、物流等。

本次培训共募得善款40600元,已经全部捐给武汉市红十字会,捐赠公示链接如下:http://www.wuhanrc.org.cn/info/1003/2914.htm

培训内容:

通过演示,掌握以下oracle性能优化核心技术:

1、如何快速找到TOP SQL

  •     多个维度(CPU、read、time等)

2、sql 优化诊断与调试方法

  •     得到真实的执行计划
  •     得到执行计划各步骤真实的行数(A-rows、A-time、buffer gets、reads)等信息
  •     得到执行计划的执行先后顺序
  •     生成sqlhc
  •     生成sql monitor

3、找到应用行锁的进程信息及产生锁的SQL

4、如何找到硬解析高的SQL

5、如何找到执行计划发生改变的SQL

6、快速生成AWR(特别是RAC多节点环境)

7、如何使用sql profile固定sql执行计划,两种情况(比coe_xfr_sql_profile.sql方法更高效,尤其是第二种情况的时候)

  •     SQL有多个执行计划,选择其中最适合的一个,并固定
  •     SQL没有好的执行计划,通过hint等方法生成一个好的执行计划,并固定

 

南京某客户重要业务数据库优化前后对比

2020年第二周,应南京某客户邀请,前往客户现场进行优化,通过几天的分析,给出优化建议,并对其中一部分建议做了实施。

优化建议主要分两大部分:
1、不需要开发人员介入的,比如索引调整、执行计划调整、参数调整等
2、需要开发人员完成的,比如修改业务逻辑,改写SQL等

因为需要开发介入部分没有那么快完成,下面只是在完成了第一部分建议后的一个阶段性成果对比:

优化前,physical reads/秒:53061

优化后,physical reads/秒:15426 (如果SQL也能按优化建议修改,应该能降到5000/秒)

经过优化,大大减轻了存储的压力(优化后磁盘读次数不到优化前的1/3)。如果不做优化,这样的系统只能通过更换更高级的SSD闪存存储来缓解存储压力,这个费用至少也要百万以上,而且随着数据量的增长还会继续恶化。现在只需要几万块钱做个优化,就能解决大问题。如果开发人员也能根据优化建议作出调整,那就更加完美了。

关于开发部分建议,请参考下面公众号文章:

https://mp.weixin.qq.com/s/3jkdA8xL41DdClF0san8JA

 

庆祝广州研库信息技术有限公司与浙江泰隆银行签订服务合同

广州研库信息技术有限公司与浙江泰隆银行签订了为期一年的oracle数据库维保合同。 泰隆银行本身是oracle的SSC客户(SSC是oracle原厂高级客户支持的顶级服务),此次为了保障数据库性能,又与广州研库签订维保合同。这是对研库公司性能优化保障服务水平的认可,再次感谢泰隆银行选择研库。

2-严格区间检索最佳处理方法

这是《老虎刘谈Oracle性能优化》的第二篇文章,这篇文章给出的方法有点复杂,需要用函数来实现,后来在第49篇做了更新,这里做个整合。

原文+更新:

2013年,有朋友让我帮忙优化一个SQL:根据IP地址查询对应的国家/地区(根据号码查询归属地也属类似业务),这个就属于严格区间检索。

所谓严格区间,就是区间不重叠,给定一个值最多只匹配一个区间。

业务SQL代码如下:

Select country_code

From COUNTRY_IP_RANGE IP

WHERE

IP.Start_Ip1 <= ip_to_number1(:ip)

AND

IP.End_Ip1   >= ip_to_number1(:ip);

说明:

其中ip_to_number1是一个将ip地址转换成整数的函数。COUNTRY_IP_RANGE表记录数大概有12万条。存在一个start_ip1和end_ip1字段上的联合索引。SQL每次最多只返回一条记录。

当前的性能问题:

查询一个小IP(如:1.0.0.1)时,只需要几个buffer gets;查询一个较大的IP时(如:222.252.0.123),buffer gets要400多。

传统优化方法:

第一步、根据业务规则,增加一个rownum=1的谓词条件,SQL变成:

Select country_code

From COUNTRY_IP_RANGE IP

WHERE

IP.Start_Ip1 <= ip_to_number1(:ip)

AND

IP.End_Ip1   >= ip_to_number1(:ip)

and ROWNUM=1;

加了这个条件后,性能只有一点点的改善,每次的buffer gets会少一个

第二步、根据业务特点及索引默认扫描方式为升序扫描,改变索引扫描方式,使用索引降序扫描,用index_rs_desc的hint实现:

select /*+ INDEX_RS_DESC(ip  IDX_IP1) */

country_code

from COUNTRY_IP_RANGE IP

WHERE

IP.Start_Ip1 <= ip_to_number1(:ip)

AND

IP.End_Ip1   >= ip_to_number1(:ip)

And rownum=1;

其中IDX_IP1是start_ip1,end_ip1两字段联合索引。

做了这两步后,每次的buffer gets就只有3个了。

如果不用hint,可以通过改变联合索引的先后顺序也能实现相同优化效果,即联合索引的顺序是(end_ip1,start_ip1)

当时,优化到这一步就已经解决了朋友的大问题。

最近在整理这个案例的时候,发现还有个问题没有解决:在给定IP地址找不到对应区间的时候,仍需要大量的buffer gets。有外国优化大师给出的解决方案是通过plsql代码实现,需要创建一个函数。这个方案比较复杂,改动也比较大。

我给出了一个直接通过SQL就能完美解决上面问题的sql写法,代码如下:

改写SQL为:

SELECT

case when start_ip1<= :B1 then COUNTRY_CODE

else ‘no_match’ end

FROM

(SELECT COUNTRY_CODE, start_ip1,end_ip1

FROM COUNTRY_IP_RANGE

WHERE end_ip1 >= :B1 order by end_ip1

) WHERE ROWNUM = 1;

这个改写只需要配合 end_ip1 单字段索引即可。 这样,无论查询的IP地址是大是小,是否找得到对应区间,都只需要3个buffer,是最完美的解决方案。

1- 热身–隐式类型转换还是其他?

这个是《老虎刘谈oracle性能优化》微信公众号的第一篇文章,有一点小瑕疵,放在这里更正一下:

说隐式类型转换发生在变量上是“无害的”的说法是不妥的:如果绑定变量是number字段,而且字段上存在直方图,隐式类型转换相当于在变量上使用了函数。这种情况下,绑定变量窥视在第一次会通过直方图做出正确估值,但是如果绑定变量值发生巨大变化,也不再窥视(不再被标记绑定变量敏感),即使开启了ACS和bind_aware,也会一直沿用第一次硬解析时生成的执行计划,这也是一个比较大的问题。 当然,对于数据分布比较平均的字段来说,这种情况就没有问题。

 

以下是公众号原文:

前几天,有个给运营商做维护的DBA小陈问:

刘老师,我这个SQL不能使用索引,你帮我确认一下,是不是遇到了“隐式类型转换”?然后发了一个执行计划的最后部分给我看:

Peeked Binds (identified by position):

————————————–

1 – :V1 (VARCHAR2(30), CSID=852): ‘4000874’

2 – :V2 (VARCHAR2(30), CSID=852): ‘4000874’

Predicate Information (identified by operation id):

—————————————————

4 – filter((“RATABLE_RESOURCE_ID”=TO_NUMBER(:V1) OR “TRANSFER_RESOURCE_ID”=TO_NUMBER(:V2)))

我说没错,确实是有隐式类型转换。但是,这个隐式类型转换却是“无害”的,因为如果字段是number类型,绑定变量是varchar2类型,这种隐式类型转换是不会影响SQL执行计划的。而如果字段是varchar2类型,绑定变量是number类型,这种才是最危险的。

小陈接下来发了完整的SQL,并告知第一个谓词条件字段(红色)上有主键:

SELECT

……

FROM    hss.tb_bil_ratable_resource

WHERE   ratable_resource_id =  ‘4000874’ OR transfer_resource_id =  ‘4000874’;

我一看SQL,马上就明白是什么原因了:这个SQL如果要想使用索引,必须还要创建另一个谓词条件字段(transfer_resource_id)上的索引。

小陈创建完索引后很快就发消息说搞定了!

解释:

因为两个谓词条件之间的关系是OR,而不是通常见到的AND,如果是AND,不用创建另一个字段上的索引就可以使用已经存在的主键索引。

总结:

这个SQL虽然非常简单,但是如果没有理解OR和AND的区别,还是会比较迷惑。而且客户之前被隐式类型转换折腾过几次,这次发现一个,可惜却不是根因。​

公司简介

广州研库信息技术有限公司致力于提供Oracle数据库的高级技术支持,公司创始人曾为Oracle 工作6年,开始在深圳研发Real-World Performance (RWP) 担任高级程序员,后转到高级客户服务(ACS)部门的高端客户团队SSC,做优化组组长,专职性能优化工作。作品有译著《Oracle Database 12cR2 性能调整与优化》,个人公众号《老虎刘谈Oracle性能优化》。

公司业务: 提供Oracle数据库相关全方位高端技术服务,主要包括架构设计、高可用方案、开发顾问、培训、生产系统优化等。

联系方式:

电话:18620308065

微信:ora_service

邮件:oracle_tigerliu@qq.com