Java性能调优工具

Java性能调优工具（共5篇）

1.Java性能调优工具 篇一

性能是苹果审核的一个很重要的部分，CPU，内存，图形绘制，存储空间和网络性能都是应用的重要的评估和组成部分，不管是作为个人应用开发者还是企业的开发人员，都需要遵循的一个原则是站在用户的角度去思考问题，比如说常见的适配问题，不能因为不同的机型导致最终出现的UI效果差异很大，用户在使用的过程的中最好不要表现出明显的卡顿现象，或者更严重的是出现App闪退，出现闪退的结果就是应用被删，这是属于比较严重的问题。Instruments是目前最强大的性能调试工具之一，有助于我们解决应用存在的性能问题。Instruments是里面包括了内存管理工作，I/O以及网络过去，本文主要讲述的是Allocation和Time Profle。

Allocations（内存分配）

就是动态的将文字输出在视图上，下面贴出代码你会发现开始还好运行到慢的简直跟蜗牛有的一拼，不要运行太久，否则内存不够用，代码如下:

@implementation FETextView- (id)initWithFrame.:(CGRect)frame. text:(NSString *)text { self = [super initWithFrame.:frame]; if (self) { [NSTimer scheduledTimerWithTimeInterval:0.01 target:self selector:@selector(appendNextCharacter) userInfo:nil repeats:YES]; _text = [text copy]; self.backgroundColor = [UIColor whiteColor]; } return self;}//原文地址www.2cto.com- (void)appendNextCharacter { for (NSUInteger i = 0; i <= self.index; i++) { if (i < self.text.length) {UILabel *label = [[UILabel alloc] init];label.text = [self.text substringWithRange:NSMakeRange(i,1)];label.opaque = NO;[label sizeToFit];CGRect frame. = label.frame;frame.origin = [self originAtIndex:i fontSize:label.font.pointSize];label.frame=frame;[self addSubview:label]; } } self.index++;}- (CGPoint)originAtIndex:(NSUInteger)index fontSize:(CGFloat)fontSize { if (index == 0) { return CGPointZero; } else { CGPoint rigin = [self originAtIndex:index-1 fontSize:fontSize]; NSString * prevCharacter = [self.text substringWithRange:NSMakeRange(index-1,1)]; CGSize prevCharacterSize = [prevCharacter sizeWithAttributes:@{ NSFontAttributeName: [UIFont systemFontOfSize:fontSize] }]; origin.x += prevCharacterSize.width; if (origin.x >CGRectGetWidth(self.bounds)) {origin.x = 0;origin.y += prevCharacterSize.height; } return origin; }}@end

主视图控制器的调用代码:

NSString *path = [[NSBundle mainBundle] pathForResource:@“FlyElephant” ofType:@“txt”];FETextView *textView = [[FETextView alloc] initWithFrame.:CGRectMake(0, 64, CGRectGetWidth(self.view.bounds), CGRectGetHeight(self.view.bounds)) text:[NSString stringWithContentsOfFile:pathencoding:NSUTF8StringEncoding error:nil]];[self.view addSubview:textView];

2.Java性能调优工具 篇二

美国国家技术和标准研究院 (NIST, National Institute of Standards and Technology) 对云计算的定义[1]为:“云计算是一个提供便捷的可通过网络访问一个可定制的计算资源共享池能力的模式 (计算资源包括网络、服务器、存储、应用和服务) ;这些资源能够快速部署, 并只需要很少的管理工作或与服务供应商很少的交互。”随着云计算的不断成熟, 越来越多的企业通过私有云的部署解决企业信息化进程中面临的问题。云平台的构建能够解决企业信息系统之间存在的资源无法共享, 资源利用率不足等问题, 并且能够保障业务的连续性。

随着私有云平台应用的不断深入, 由于应用压力大, 资源分配不当等原因, 云平台会出现资源竞争的情况, 可能会导致虚拟机性能下降, 如果云平台管理员不能够及时地发现并处理, 将会影响虚拟机的正常运行, 甚至影响信息系统业务的连续性。

针对企业私有云平台运行中可能出现的问题, 本文以VMware v Sphere虚拟化平台为例, 介绍了采用v Center Operations Manager (下文简称v COps) 进行云平台监控及性能调优的方法, 并结合实际运维过程中虚拟机性能调优需求, 给出了相应的解决方案。通过对虚拟机性能的调优, 进一步保障了系统的稳定性。

一、v Center Operations Manager简介

v Center Server[2]能够提供一些基本的对于云平台中主机、虚拟机和存储的使用情况的统计, 但是无法满足云平台管理员对于虚拟机性能调优的深入需求。如某些重要指标仅能够实时显示, 不会长期保留;指标的显示不直观, 可读性较差。v COps[3]从v Center收集指标, 能够为管理员提供对IT基础架构的运行状况、风险和效率的全面分析。

v COps主界面如图1 所示, 可以通过主界面直观了解到整个虚拟化平台的运行状况、容量情况和效率。v COps通过从虚拟环境中的每个对象收集性能数据, 通过对相关信息的分析, 提供对于潜在问题的预警和解决方案建议。

使用v COps进行对象分析时, 可以通过点击某一对象查看其详细的性能指标, 以实现对其性能全面的掌控。在实际的运维过程中, 当面临虚拟机性能调优问题的时候, 需要着重关注CPU、内存及存储使用的相关信息, 通过v COps的指标显示能够帮助管理员进行性能调优。

二、虚拟机性能调优方案

当虚拟机面临性能瓶颈的时候, 用户反馈给管理员的现象通常就是“机器速度慢”, 但是导致虚拟机性能下降的原因有很多, 需要通过相关的分析确定问题所在。本文给出了几种虚拟机性能调优的常见场景, 并提出相应解决方案:

(1) 因主机资源不足导致虚拟机性能下降。在云平台中, 一台主机上通常需要部署多台虚拟机以提升资源的利用效率, 当某台主机上部署的虚拟机过多, 可能会出现主机CPU或内存不足的情况, 从而导致虚拟机性能的下降。当出现此问题时, 使用v Motion[2]迁移运行中的虚拟机和执行无中断的IT环境维护, 可以实现将虚拟机不停机的从一台服务器迁移到另一台。可以借助Distributed Resource Scheduler (DRS) 功能[2], 根据系统给出的迁移建议, 实现对资源按需动态的分配, 将性能下降的虚拟机迁移到负载较轻的主机上, 从而提升虚拟机的性能。

(2) 因存储资源不足导致虚拟机性能下降。当虚拟机所在存储容量接近饱和的时候, 也会导致虚拟机性能的下降, 当通过监控发现有存储LUN的使用率较高的情况, 需要将部分虚拟机迁入较空闲的存储LUN中, 可以通过Storage v Motion[2]实现此功能, 其相当于存储上的v Motion, 通过手动的方式在2 台数据存储之间平衡存储的利用, 通过此种方式进行虚拟机性能的调优。

(3) 因资源分配过剩导致虚拟机性能下降。当用户向云平台管理员申请虚拟机资源的时候, 通常会认为申请的CPU或内存资源越多, 虚拟机性能越高。在实际的应用中, 对于虚拟机资源的分配应本着“够用就好”的原则, 如果为一台虚拟机分配的资源过多, 而这台虚拟机实际使用不了这么多资源的话, 很可能导致虚拟机性能下降。在虚拟机使用一段时间后, 可以通过v COps的容量预估功能来对虚拟机的资源使用情况进行评价, 如果分配资源过多或过少应进行适当的调整。另外如果通过监控指标发现虚拟机CPU ready值较高的时候, 有些情况也是由于分配资源过多导致的, 当降低配置以后, 往往能够解决虚拟机性能下降的问题。

通过v COps对虚拟机使用状态的监控, 重点对CPU、内存这两项虚拟机核心指标的使用量和需求量进行分析, 参考表1 对相关参数进行调整:

三、总结

针对于企业云平台运维过程中出现的虚拟机性能下降的问题, 本文以VMware v Sphere平台为例, 介绍了采用v Center Operations Manager进行云平台监控及性能调优的方法, 并结合实际案例, 给出了主机、存储资源不足等场景下, 相应的虚拟机性能调优方案, 为云平台管理员解决相关问题提供了参考依据。通过虚拟机性能调优, 提升了云平台运维效率, 进一步保障了云平台中信息系统的业务连续性。

参考文献

[1]赵立威, 方国伟.让云触手可及微软云计算实践指南[M].电子工业出版社, 2010.

[2]Scott Lowe.精通VMware v Sphere5[M].曾少宁译.人民邮电出版社, 2014.

3.有效检查Java代码的三个工具 篇三

Java项目最枯燥的一部分，也是程序员总是避而不谈的一部分，就是检查代码。为了区块括号、代码缩进、Javadoc注释以及命名约定而检查其他人的上千行代码的确是一件痛苦的事。更糟糕的是，通常代码的检查还受限于紧迫的项目进度。没有足够的时间对代码的细节进行评估，因此代码检查经常变成了对代码的美化练习。不管检查者有多么好的意图，优化和逻辑检查都退居次席。

Java代码分析器减轻了这样的痛苦

在面对这种情况的时候，Java代码分析器正是对症良药。这些工具尽可能地将代码检查过程自动化。留给人工来做的就只有检查类的缺陷以及核心逻辑并确定可能的优化方法。优化（去除不必要的实例化对象、检查数据库连接是否合理、确保数据在可能的情况下被缓存）对于任何代码通常会带来性能上的极大改进。

最近我接触了各种代码分析器。我觉得一个基本的最重要的功能是与常用IDE（如NetBeans、Eclipse、jEdit以及JDeveloper）的集成。有一些代码检查工具在查找错误方面很有效，但是它们需要你根据给出的错误行的行号手工来追踪错误。这样的工具使用起来太累人了。与IDE环境集成了的工具可以大大简化这个过程，因为代码检查的结果是由所使用的IDE显示的。你只需在错误上双击就可以在Java编辑器中到达错误代码所在的行

我的试用心得

在我试用过的工具中，我发现其中三个工具十分强大并合乎与IDE集成的标准，它们是： PMD、Checkstyle 和 Jalopy。

PMD和Checkstyle

根据PMD的文档，它会对代码中的如下部分进行检查：

未使用的本地变量

空的catch块

未使用参数

空if语句

重复的import语句

未使用的私有方法

可能是Singletons的类

短/长变量及方法名字

Checkstyle检查如下部分：

Javadoc注释

命名约定

标题

Import语句

体积大小

空白

修饰符

块

混合检查（包活一些有用的比如非必须的System.out和printstackTrace）

它们的作用

不像PMD，Checkstyle能够检查Javadoc注释；但是PMD提供了一项叫作CPD的很有用的功能，它检查代码的拷贝粘贴部分。我使用PMD找到的最频繁的错误是未使用的import语句，未使用的私有变量以及意外重复拼写。Checkstyle可以发现更多的错误。包括漏掉的Javadoc注释，超过80个字符的行、不合约定的变量名、用tab来代替空格等等。两个工具都允许创建自定义的规则。

如果想在你的组织中使用它们中的一个，Checkstyle似乎更好一些：它检查公司编码约定的大多数项目。如果增强代码质量是主要目标，那PMD是一个好的选择。但是如果你想要更多的功能并真正使用工具来修改代码，应该试试Jalopy。

Jalopy

Jalopy是一个易于配置的源代码格式程序，它能检测并修补Java代码中大量的习惯性缺陷。Jalopy更像一个代码整理器而不是检查器。Jalopy的插件现在已经支持大多数IDE，而且多数是无缝集成。我发现Jalopy特别强大，能够干许多很酷的事情。例如，它可以修改代码缩进、对齐括号、使行宽符合某个字符长度、插入相关的Javadoc注释以及对import语句排序。Jalopy最好的地方是超级自定义功能。一个简单的用户界面就可以让你选择Jalopy的所有功能的开关，不需要XML配置文件。

不要浪费资源

4.浅析ERP中数据库性能调优技术 篇四

1 优化的目标和步骤流程

1.1 优化的目标

1)缩短系统的响应时间

系统响应的时间的长短对用户来说非常重要。漫长的响应时间意味着用户只能在线等待,同时阻碍了其他的用户使用系统。对响应时间有严格要求的系统,必须采取不同的方法对系统进行调整。缩短系统响应时间可以采用使系统以低于其实际吞吐能力的吞吐量运行或者将需要进行批处理的作业放在空闲时间段运行。

2)提高系统的吞吐量

系统的吞吐量是指单位时间内系统处理用户的请求数,提高系统的吞吐量可通过在同样的资源下做更多的工作或通过减少总的响应时间使工作做的更快。一般而言,调优的目的与应用的需求密切相关,在联机事务处理(OLTP)应用中,主要关注系统的吞吐量,因为OLTP应用每天要处理大量的交易,而在决策支持系统(DSS)中,主要关注的是系统的响应时间。因此需要根据不同的需求对系统进行相应的优化。

3)增强系统容错能力

所谓容错是指在故障存在的情况下系统不失效,仍然能够正常工作的特性。对一些ERP系统来说,任何时候出现的停机都是灾难性的,因此对这些系统来说,容错能力是非常重要的。提高容错能力可以考虑采用独立冗余磁盘阵列来保证系统不会因为磁盘故障而停止工作,对于要求更高的系统,可以考虑建立一个备用系统,以便在主系统出现故障的时候切换至备用系统上,确保系统不停止工作。

4)改善磁盘I/O性能

读/写磁头和相关的磁盘取数臂需要移动才能在SQL Server和Windows所要求的硬盘盘片的位置上进行查找和操作。如果数据所在的硬盘盘片的位置不连续,硬盘驱动器要花多得多的时间才能将磁盘取数臂和读/写磁头移动到所有需要的硬盘盘片位置。如果所需要的数据全部位于硬盘盘片上的连续物理扇区,情况则相反,磁盘取数臂和读/写磁头只需进行很小的移动就能完成所需磁盘I/O操作。连续和不连续的情况下所花的时间有很大的差异,每个不连续的数据查找大约要花50毫秒,而连续的数据查找则只需大约2-3毫秒。具体将取决于不连续的数据在磁盘上分布的疏密、硬盘盘片的旋转速度(RPM)以及硬盘的其它物理属性。连续I/O有益于提高SQL Server性能。

1.2 优化的步骤流程-DETECT

数据库性能优化的工作千头万绪,最怕的就是像无头苍蝇一样盲目地错误尝试,不但旷日费时,还无法累积经验,团队与个人都难以成长,到下一次碰到性能问题时,还是像无头苍蝇一样,毫无目的地乱试一通。正确的优化方法应该是拟定步骤分阶段执行,这样才能循序渐进,一步步朝目标前进[2]。根据微软的研究结果,其过程应该分为六个阶段:

1)Discover the problem:发现问题

2)Explore the conditions:探究原因,为问题提供明确的定义与定位

3)Track down possible approaches:提供可能的解决方案

4)Execute the most 1 ikely approach:执行最有可能的解决方案

5)Check for success:确认解决方案成功与否

6)Tie up loose ends:完成收尾的工作

这虽然不一定适用在每一个优化的情境,但它是一个可供参考的方法论。当然,可以据此修正成自己的方法。有固定的准则后,才可以累积经验并加以分门别类。以下对阶段简要说明。

1.3 发现问题

这可能是支持数据库性能优化的专家们花时间最少的一个阶段,因为大部分的工作可能都是用户在做,他们可能已经有大量的观察经验,因此用户不会希望你再重复一遍他们已经做过多次的事情,他们希望看到你马上采取一些行动,并希望立竿见影。这个阶段用来评断专业与否就是看你是否可以立刻问到重点,掌握住各个细节,而不是在整个优化的过程中,来来回回地问相同的问题。这个阶段最重要的就是发现问题,详述问题,并且正确而详细地记录下来。在进入下一步骤之前,进行以下两个方面的判断:

1)对于问题是否已经有简明的描述。若无法简明地描述问题,说明还不了解问题,或者尚未抓住重点。这是常发生的问题,因为用户常常说了半天,但是并没有多少实际上有用的信息,只是让数据库管理人员晕头转向,信息虽然多,但起不到实质的作用。调优人员可以尝试将自己听到的,重新有序地整理一遍再说给用户听,看看是否符合大家共通的观点,若没有异议,那就有了一个大致正确的开始。

2)用户的基线与期待在哪。用户的基线很重要,它让你可以比较成果,并有前进的目标。例如,当用户抱怨“SQL Server跑的太慢了”,这时就要理清他们的“慢”是这么定义的,而什么样的速度是可以接受的。若他们没有基线,则需要你为他们建立。

数据库性能调优可能是一再循环的过程,除了时间难以掌握外,还不一定所有的问题都能解决。不要让用户有错误的或过高的期待,因为那样除了让你有完成不可能完成的任务之压力外,还要承受长时间调优后,达不到用户期待的结果而招致的愤怒。在搜寻的过程中尽量不要急躁和恐慌,贸然进入到下一个步骤,那样只会让你再一次回到原点,重新定义问题。

2 结束语

数据库系统调优是一项复杂的系统工程,是一个复杂、牵扯面很广的问题,没有固定的解决模式,并且调优涉及到数据库系统的各个方面,需要权衡系统的整体情况进行调优。该文根据SQL Server数据库产品的特点,结合实际的ERP数据库系统对其性能优化进行详细的研究,并优化的步骤流程进行详细分析。

参考文献

[1]刘君尧,秦文,王辉静.Linux上SYBASE大型数据库优化的研究[J].深圳信息职业技术学院学报,2008,6(4).

5.Java性能调优工具 篇五

关键词：优化器,数据库,性能调优

1 Oracle优化器及优化模式

Oracle优化器 (Optimizer) 是Oracle在执行SQL之前分析语句的工具。Oracle的优化器有两种优化方式, 即基于规则的优化方式 (Rule-Based Optimization, 简称为RBO) 和基于代价的优化方式 (Cost-Based Optimization, 简称为CBO) , 在Oracle8及以后的版本, Oracle强列推荐用CBO的方式。在此两种优化方式下, Oracle优化器主要有4种优化模式:

Rule:基于规则。

Choose:默认模式。根据表或索引的统计信息, 如果有统计信息, 则使用CBO方式;如果没有统计信息, 相应列有索引, 则使用RBO方式。

First rows:与Choose类似。不同的是如果表有统计信息, 它将以最快的方式返回查询的前几行, 以获得最佳响应时间;

All rows:即完全基于Cost的模式。当一个表有统计信息时, 以最快方式返回表所有行, 以获得最大吞吐量。没有统计信息则使用RBO方式。

Oracle优化器RBO方式, 是优化器在分析SQL语句时, 所遵循的是Oracle内部预定的一些规则。比如常见的, 当一个where子句中的一列有索引时去走索引。Oracle优化器CBO方式, 则是依据语句执行的代价, 主要指对CPU和内存的占用。优化器在判断是否使用CBO时, 要参照表和索引的统计信息。统计信息要在对表做analyze后才会有。统计信息给出表的大小、行数、块数、每行的长度等信息。很多的时候, 过期的统计信息比没有统计信息更会令优化器对SQL执行计划做出一个错误的选择, 因此, 要及时更新这些信息。但是在实际的应用中, 我们发现, 不仅仅是统计信息要及时更新, 表的数据分布也会对执行计划的选择造成影响。

2 CBO中几个最基本的概念

在研究表的数据分布对执行计划的影响之前, 需要对CBO中几个最基本的概念做个说明。主要有选择率、基数和直方图。选择率是目标结果集占全部数据的百分比, 基数则是目标结果集的大小, 直方图是列上的统计信息, 主要用于倾斜度很高的列。选择率和基数的意义基本一致, 都是为了描述目标结果集的大小的。CBO选择执行计划主要参考每一步结果的选择率和基数大小。比如说:

对于查询select*from test where object_id=5来说, 是选择索引扫描还是选择全表扫描, CBO会根据表和列上的统计信息得知这个查询大概会返回1行记录, 在几万条记录中选择一条, 那么基数就是1, 使用索引的效果会更好, 这样大概几个IO就可以得到数据集。对于查询select*from test where owner=‘SYS’来说, 这个查询会返回几万条记录, 那么自然而然就会想到全表扫描会更快。所以说选择率和基数对于执行计划的选择有着相当重要的影响。

直方图的存在主要是统计列的数据分布的情况, 使CBO查询时做出更好的判断。尤其是在表的数据分布不均衡的情况下, 用来帮助CBO计算选择率和基数。Oracle里面主要有两种直方图, 一种是在distinct key比较少的时候 (少于255) , Oracle会以一种叫做频率直方图的方式来存储直方图信息, 另外一种就是当表里的distinct key比较多的时候 (多于等于255) , Oracle会以一种叫做高度均衡直方图的方式来存储直方图信息。

在有了表, 索引和列上的统计信息之后, CBO就会根据这些统计信息, 去估计查询的选择率和基数, 确定SQL执行的执行计划。在比较完善的统计信息下, CBO就可以知道大概的数据分布, 就可以做出相对来说更加正确的选择。但是如果使用了绑定变量, 那么情况总会有所改变。

在Oracle9i里面新引入了绑定变量窥视的功能, 绑定变量窥视是一个带绑定变量的SQL第一次解析的时候, CBO会根据绑定的具体值来决定所要使用的执行计划, 而以后如果遇到同样的SQL, 即使绑定变量的值不一样, 也不会再重新考虑绑定变量的值, 而是使用已经解析好的执行计划。这样造成的潜在风险就是在列的直方图统计信息存在的情况下, 如果列上的数据倾斜度很高, 绑定变量窥视很不幸运地带入了那一小部分的倾斜数据, 就会导致以后所有同样的SQL都使用了不恰当的执行计划, 从而引起整个数据库性能问题。

3 基于代价的Oracle优化器的性能调优案例及分析

某一数据库在某天夜晚22:00自动做完分析之后, CPU开始跳高, 如图1所示。

通过分析Oracle statspack性能分析指标, 得到了造成数据库性能变差的TOP SQL, 此SQL上线时间很长了, 由于问题发生的时间点和数据库做自动分析的时间点吻合, 所以初步断定是数据库统计信息变化引起的SQL性能变差, 那么到底是不是统计信息的变化引起了CBO执行计划的性能变化呢, 我们做了以下的验证测试。

项目组从实际应用数据库克隆了一个测试数据库, 由于知道Oracle会将统计信息的备份保留在dba_tab_stats_history中, 默认保留31天。通过使用dbms_stats.restore_table_stats存储过程进行表统计信息的还原, 将统计信息还原到数据库性能发生变化的时间点前后, 然后比较在两个不同时间点的统计信息下, 此SQL的执行计划和性能到底有什么不一样。

将数据库的统计信息还原到8/1 10:00, 也就是性能变差的时间点之后。

在这里需要提一下, 此SQL查询条件里面表A有一个栏位带绑定变量Name, 从表A中选择3个记录数不同的Name值如表1所示。

进行3组测试, 每一组都以不同顺序代入这3个Name值。并且在每组测试后重启数据库来清空SQL的执行计划。

第一轮顺序:大, 中, 小

第二轮顺序:中, 大, 小

第三轮顺序:小, 大, 中

测试结果表明在同一测试组中, SQL的执行计划都是相同的。但在不同的测试组的SQL执行计划是不同的。每组的执行计划都由第一个代入的Name值来确定。

3 组测试SQL的性能数据如表2~4所示。

第一轮:

第二轮:

第三轮:

从OS的CPU来看, 第一组和第二组测试中的所有SQL在运行时都耗费了>20%的CPU资源。不论代入什么Name值, CPU跳起的值都是差不多的。只是SQL运行时间不同, Name值越大, 运行时间越长。

将数据库的统计信息还原到7/31 10:00, 也就是性能变差的时间点之前。

同样进行3组测试, 每一组都以不同顺序代入这3个Name值。并且在每组测试后重启数据库来清空SQL execution plan。

3 组测试SQL的性能数据如表5~7所示。

第一轮:

第二轮:

第三轮:

从以上测试结果整体上来讲, 7/31的执行计划要比8/1的好很多。这个应该跟数据库当时的统计值密切相关。在相同的统计信息下, SQL执行计划的性能又和绑定变量窥视的值相关, CBO会根据绑定的具体值来决定所要使用的执行计划, 而以后如果遇到同样的SQL, 即使绑定变量的值不一样, 也不会再重新考虑绑定变量的值, 而是使用已经解析好的执行计划。

为什么在8/1的统计信息下, 不同的绑定变量都会有比较差的执行性能。将数据库的统计信息还原到8/1, 执行此句SQL, 得到10053和10046跟踪文件。从10053跟踪文件中我们可以看出来, SQL中有一个B表中有64 757行数据, 但是从10046跟踪文件中, 发现执行计划的“1998968 TABLE ACCESSFULL B (cr=4074843 pr=0 pw=0 time=63804344 us) ”可以看出在这个表中有1 998 968行记录被查询出来, 并且此时B表被全表搜索。通过进一步分析SQLT输出, 我们得到列上的统计信息, 如, high_value, low_value, histogram等信息, 终于发现SQL执行计划中的第20步是这样的access (“FL”.“STATE”=“E”.“ID”) , SQLT输出结果表明“E”.“ID”上没有直方图, 取值处于“00000e2e.4e28d192.00001”~“00000e2e.4ff2faaf.00072”之间。而“FL”.“STATE”上有直方图, “00000000.00000000.00000”点了整个表值近90%, 数据严重不均衡, 并且“00000000.00000000.00000”不在“E”.“ID”的数值范围内。以上原因导致CBO认为, 连接后的行数为2行。而从10046 trace里我们可以看到真正返回的结果为1 108行。这个连接产生的错误结果, 直接导致CBO误认为, 与B等表用nested loop连接时, 内层表可循环访问一次。从而导致了整个连接次序的变化, 造成差的执行计划的产生。

4 结论

在本案例数据库性能变差的情况下, 通过使用outline固化执行计划将数据库CPU得到恢复, 长远角度来讲, 表“FL”.“STATE”列数据分布不均衡是根本原因, 可以通过删除一些陈旧的行数, 来得到一个比较均衡的数据分布, 从而从根本上解决这个问题。

参考文献

[1]盖国强.Oracle数据库性能优化[M].北京:人民邮电出版社, 2005.