oracle性能sql

⑴ sqlServer和Oracle数据库分析(oraclesql性能分析)

分析原则：

1、具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）

2、查找瓶颈时按以下顺序，由易到难。

服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。分段排除法很有效。

分析的信息来源：1、根据场景运行过程中的错误提示信息；

2、根据测试结果收集到的监控指标数据。

一、错误提示分析

分析实例：

1、Error:“10.10.10.30:8080〃:[10060]Connection

Error::Server“10.10.10.30〃

分析：

A、应用服务死掉（小用户时：程序上的问题。程序上处理数据库的问题）

B、应用服务没有死（应用服务参数设置问题）

例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AeptBacklog属性值设得过低。如果连接时收到消息，说明应提高该值，每次增加25%

C、数据库的连接（1、在应用服务的性能参数可能太小了；2、数据库启动的最大连接数（跟硬件的内存有关）。）

分析：可能是以下原因造成

A、誉丛应用服务参庆掘樱数设置太大导致服务器的瓶颈；B、页面中图片太多；C、在程序处理表的时候检查字段太大多。

二．监控指标数据分析

1、最大并发用户数：

应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么可行。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

2、业务操作响应时间：

分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。细分事务并分析每个页面组件的性能。如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题

3、服务器资源监控指标：内存：

1、UNIX资源监控中指标内存页交换速率（Pagingrate），如散衡果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

2、Windows资源监控中，如果Process计数器和ProcessWorkingSet计数器的值在长时间内持续升高，同时Memory计数器的值持续降低，则很可能存在内存泄漏。

内存资源成为系统性能的瓶颈的征兆：很高的换页率()；进程进入不活动状态；交换区所有磁盘的活动次数可高；可高的全局系统CPU利用率；内存不够出错()。

处理器：

1、UNIX资源监控（Windows操作系统同理）中指标CPU占用率（），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQLServer，可接受的最大上限是80-85%合理使用的范围在60%至70%。

2、Windows资源监控中，如果System大于2，而处理器利用率（）一直很低，则存在着处理器阻塞。

CPU资源成为系统性能的瓶颈的征兆：很慢的响应时间()；CPU空闲时间为零()；过高的用户占用CPU时间()；过高的系统占用CPU时间()；长时间的有很长的运行进程队列()。

磁盘I/O：

1、UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Diskrate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。

2、Windows资源监控中，如果DiskTime和Avg.DiskQueueLength的值很高，而PageReads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

I/O资源成为系统性能的瓶颈的征兆：过高的磁盘利用率(highdiskutilization)；

太长的磁盘等待队列(largediskqueuelength)；

等待磁盘I/O的时间所占的百分率太高(/O)；

太高的物理I/O速率：largephysicalI/Orate(notsufficientinitself)；

过低的缓存命中率(lowbuffercachehitratio(notsufficientinitself))；

太长的运行进程队列，但CPU却空闲(largerunqueuewithidleCPU)。

4、数据库服务器：

SQLServer数据库：

1、SQLServer资源监控中指标缓存点击率（CacheHitRatio），该值越高越好。如果持续低于80%，应考虑增加内存。

2、如果FullScans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。

3、NumberofDeadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。

4、LockRequests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。

Oracle数据库：

1、如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。

快存（共享SQL区）和数据字典快存的命中率：select(sum(pins-reloads))/sum(pins)fromv$librarycache；

select(sum(gets-getmisses))/sum(gets)fromv$rowcache；

自由内存：select*fromv$sgastatwherename=‘freememory’。

2、如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。

缓冲区高速缓存命中率：selectname,valuefromv$sysstatwherenamein(‘dbblockgets’，‘consistentgets’‘physicalreads’)HitRatio=1-(physicalreads/(dbblockgetsconsistentgets))。

3、如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。

日志缓冲区的申请情况：selectname，valuefromv$sysstatwherename=‘redologspacerequests’。

4、如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序。

内存排序命中率：selectround((100*b.value)/decode((a.valueb.value)，0，1，(a.valueb.value)),2)fromv$sysstata，v$sysstatbwherea.name=’sorts(disk)’andb.name=’sorts(memory)’

注：上述SQLServer和Oracle数据库分析，只是一些简单、基本的分析，特别是Oracle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。

⑵ 如何查询oracle 数据库性能，sql资源占用

作为一个开发/测试人员，或多或少都得和数据库打交道，而对数据库的操作归根到底都是SQL语句，所有操作到最后都是操作数据，那么对sql性能的掌控又成了我们工作中一件非常重要的工作。下面简单介绍下一些查看oracle性能的一些实用方法：

1、查询每台机器的连接数

selectt.MACHINE,count(*)fromv$sessiontgroupbyt.MACHINE

这里所说的每台机器是指每个连接oracle数据库的服务器，每个服务器都有配置连接数据库的连接数，以websphere为例，在数据源中，每个数据源都有配置其最大/最小连接数。

执行SQL后，可以看到每个服务器连接oracle数据库的连接数，若某个服务器的连接数非常大，或者已经达到其最大连接数，那么这台服务器上的应用可能有问题导致其连接不能正常释放。

2、查询每个连接数的sql_text

v$session表里存在的连接不是一直都在执行操作，如果sql_hash_value为空或者0，则该连接是空闲的，可以查询哪些连接非空闲，web3是机器名，就是WebSphereApplicationServer的主机名。

selectt.sql_hash_value,t.*fromv$sessiontwheret.MACHINE='web3'andt.sql_hash_value!=0

这个SQL查询出来的结果不能看到具体的SQL语句，需要看具体SQL语句的执行下面的方法。

3、查询每个活动的连接执行什么sql

selectsid,username,sql_hash_value,b.sql_text

fromv$sessiona,v$sqltextb

wherea.sql_hash_value=b.HASH_VALUEanda.MACHINE='web3'

orderbysid,username,sql_hash_value,b.piece

orderby这句话的作用在于，sql_text每条记录不是保存一个完整的sql,需要以sql_hash_value为关键id,以piece排序，如图

Username是执行SQL的数据库用户名，一个sql_hash_value下的SQL_TEXT组合成一个完整的SQL语句。这样就可以看到一个连接执行了哪些SQL。

4、.从V$SQLAREA中查询最占用资源的查询

selectb.usernameusername,a.disk_readsreads,a.executionsexec,

a.disk_reads/decode(a.executions,0,1,a.executions)rds_exec_ratio,

a.sql_textStatement

fromv$sqlareaa,dba_usersb

wherea.parsing_user_id=b.user_id

anda.disk_reads>100000

orderbya.disk_readsdesc;

用buffer_gets列来替换disk_reads列可以得到占用最多内存的sql语句的相关信息。

V$SQL是内存共享SQL区域中已经解析的SQL语句。

该表在SQL性能查看操作中用的比较频繁的一张表，关于这个表的详细信息大家可以去http://apps.hi..com/share/detail/299920#上学习，介绍得比较详细。我这里主要就将该表的常用几个操作简单介绍一下：

1、列出使用频率最高的5个查询：

selectsql_text,executions

from(selectsql_text,executions,

rank()over

(orderbyexecutionsdesc)exec_rank

fromv$sql)

whereexec_rank<=5;

该查询结果列出的是执行最频繁的5个SQL语句。对于这种实用非常频繁的SQL语句，我们需要对其进行持续的优化以达到最佳执行性能。

2、找出需要大量缓冲读取（逻辑读）操作的查询：

selectbuffer_gets,sql_text

from(selectsql_text,buffer_gets,

dense_rank()over

(orderbybuffer_getsdesc)buffer_gets_rank

fromv$sql)

wherebuffer_gets_rank<=5;

这种需要大量缓冲读取（逻辑读）操作的SQL基本是大数据量且逻辑复杂的查询中会遇到，对于这样的大数据量查询SQL语句更加需要持续的关注，并进行优化。

3、持续跟踪有性能影响的SQL。

SELECT*FROM(

SELECTPARSING_USER_ID,EXECUTIONS,SORTS,

COMMAND_TYPE,DISK_READS,sql_textFROMv$sqlarea

ORDERBYdisk_readsDESC

)

WHEREROWNUM<10

这个语句在SQL性能查看中用的比较多，可以明显的看出哪些SQL会影响到数据库性能。

本文主要介绍了使用SQL查询方式查看oracle数据库SQL性能的部分常用方法。此外还有许多工具也能实现SQL性能监控，大家可以在网上搜索相关知识进行学习。

转载仅供参考，版权属于原作者

⑶ oracle中怎么确定性能差的SQL语句

oracle中怎么确定性能差的SQL语句,当涉及 SQL 时，性能不佳有两方面：CPU 密集型语句（CPU-intensive statements）和 I/O 密集型语句（I/O-intensive statements）。



oracle中怎么确定性能差的SQL语句,当涉及 SQL 时，性能不佳有两方面：CPU 密集型语句（CPU-intensive statements）和 I/O 密集型语句（I/O-intensive statements）。

前者很容易定位。所有的操作系统都可以让我们查看 CPU 密集型任务。这些任务可以追溯到一个特定用户，一个特定应用程序模块。 CPU 密集型模块一般都是由较差的代码和/或结构造成，而不是性能差的 SQL。一旦确定模块，你必须试图使之更有效率。一个可能的解决方案是将把某些处理移除程序，让数据库处理（高明点的 SQL，存储对象，内联函数，数组处理等）。

第二个是 I/O 密集型的 SQL 语句。这些语句会导致大量的数据库 I/O（全表扫描，排序，更新等），并以很高代价运行几个小时。从 Oracle 7 开始，解决了 SQL 识别问题。通过查询数据库共享池区域，我们可以很容易确定大多数 I/O 密集型 SQL 语句。

下面 SQL 语句演示了如何确定 I/O 命中率低于 80%的 SQL 语句。这个命中率是，自从 SQL 语句第一次被解析到共享池，通过所有执行的语句反应整体 I/O。下面可能是最近几分钟或几天的结果：


代码如下




sql> SELECT executions,

2 disk_reads,

3 buffer_gets,

4 ROUND((buffer_gets - disk_reads) / buffer_gets, 2) hit_ratio,

5 sql_text

6 FROM v$sqlarea

7 WHERE executions > 0

8 AND buffer_gets > 0

9 AND (buffer_gets - disk_reads) / buffer_gets < 0.80

10 order by 4 desc ;

EXECUTIONS DISK_READS BUFFER_GETS HIT_RATIO SQL_TEXT

---------- ---------- ----------- ---------- -----------------------------------------------------------------------

16 180 369 .51 SELECT SKU,PREPACK_IND,CASE_ID,TRANSFER_QTY,UNIT_COST,UNIT_RETAIL,ROWID

FROM TSF_DETAIL WHERE transfer = :1 order by sku

16 30 63 .52 SELECT TRANSFER,TO_STORE,TO_WH FROM TSFHEAD WHERE TRANSFER = :b1 AND

TRANSFER_STATUS = 'A'

2 3 7 .57 SELECT SKU FROM UPC_EAN WHERE UPC = :b1

12 14 35 .60 SELECT SUBSTR(DESC_UP,1,30),DEPT,SYSTEM_IND FROM DESC_LOOK WHERE

SKU = :b1

14 13 35 .63 SELECT UNIT_COST,UNIT_RETAIL,SUBCLASS FROM WIN_SKUS WHERE SKU = :b1

事实上，我们发现对特定的 SQL，上面的数据有些误导，其实语句没有问题。考虑下面 v$sqlarea 输出：

Executions Disk_Reads Buffer_Gets Hit_Ratio Sql_Text

---------- ---------- ----------- --------- --------------------

2 6 19 0.68 SELECT A.EMP_NO, ...



该语句的命中率很低，但事实上它很有效。因为，SQL 是通过 UNIQUE 索引操作的，物理磁盘读取的数量几乎与逻辑读取一样。UNIQUE 索引显着减少了整体的物理和逻辑磁盘 I/O 数量，导致了一个令人误解的低命中率。

下面例子，命中率很好。但是真的很好吗？


代码如下




Executions Disk_Reads Buffer_Gets Hit_Ratio Sql_Text

---------- ---------- ----------- --------- --------------------

2 3625 178777 0.98 SELECT A.EMP_NO, ...



这个 SQL 语句看上去很有效。但是， 当我们仔细看时，事情就不是那么回事了。命中率并没有透露出，该语句存在五个表连接，并且每次执行进行了超过 3600 个物理磁盘读取。这是否太多了？是否有效？若不进一步研究，无法回答这两个问题。事实上，这个实例中，五个表的中其一个错误地执行了全表扫描。通过重新构造 SQL，我们可以减少物理磁盘 I/O 到小于 50，同时，也显着减少逻辑磁盘 I/O。巧合的是，命中率也下降到不到 70％。

我们首选 V$SQLAREA 查询是每个语句执行的物理磁盘 I/O 的真实报告。命中率是信息性的，但有时会产生误导。逻辑 I/O 相关的很少。如果语句执行 1,000,000 个逻辑 I/O，但只用了不到十分之一秒，这就没人在乎了。这是总的物理 I/O，几乎消耗了所有的时间，和确定潜在不正确的 SQL。例如：


代码如下




sql> SELECT sql_text, executions,

ROUND(disk_reads / executions, 2) reads_per_run,

disk_reads, buffer_gets,

ROUND((buffer_gets - disk_reads)

/ buffer_gets, 2) hit_ratio,

sql_text

FROM v$sqlarea

WHERE executions > 0

AND buffer_gets > 0

AND (buffer_gets - disk_reads) / buffer_gets < 0.80

ORDER by 3 desc ;



前两个语句会报告更具启发性的结果：


代码如下




Executions Reads_Per_Run Disk_Reads Buffer_Gets Hit_Ratio Sql_Text

---------- ------------- ---------- ----------- --------- ------------

2 3 6 19 0.68 SELECT ...

2 1812.5 3625 178777 0.98 SELECT ...



从视图 V$SQLAREA 中，我们可以立即隔离所有具有高物理读取的语句。这些语句可能并不一定低效或写得不好，但恰恰是它们需要进一步调查或调整。

⑷ Oracle SQL条件顺序对性能的影响有哪些

在实际操作中有人会问到关于Oracle数据库中的Where子句的条件书写顺序的正确与否是否会对SQL性能有影响，我的直觉是没有影响。 因为如果这个顺序有影响，Oracle应该早就能够做到自动优化，但一直没有关于这方面的确凿证据。在网上查到的文章，一般认为在RBO优化器模式下无影响（10G开始，缺省为RBO优化器模式），而在CBO优化器模式下有影响，主要有两种观点： a.能使结果最少的条件放在最右边，SQL执行是按从右到左进行结果集的筛选的； b.有人试验表明，能使结果最少的条件放在最左边，SQL性能更高。 查过oracle8到11G的在线文档，关于SQL优化相关章节，没有任何文档说过where子句中的条件对SQL性能有影响，到底哪种观点是对的，没有一种确切的结论，只好自己来做实验证明。结果表明，我们大家都知道Oracle SQL条件的相关执行是从右到左的，但条件的顺序对SQL性能没有影响。 实验一：证明了SQL的语法分析是从右到左的 下面的试验在9i和10G都可以得到相同的结果: 第1条语句执行不会出错，第2条语句会提示除数不能为零。 Select'ok'FromDualWhere1/0=1And1=2;Select'ok'FromDualWhere1=2And1/0=1;证明了SQL的语法分析是从右到左的。 实验二：证明了SQL条件的执行是从右到左的 droptabletemp; createtabletemp(t1varchar2(10),t2varchar2(10)); insertintotempvalues('zm','abcde'); insertintotempvalues('sz','1'); insertintotempvalues('sz','2');commit;select*fromtempwhereto_number(t2)1andt1='sz';select*fromtempwheret1='sz'andto_number(t2)1;在9i上执行, 第1条语句执行不会出错，第2条语句会提示无效的数字 在10G上执行，两条语句都不会出错。 说明：9i上源码天空 实验三：证明了在10g上SQL条件的执行是从右到左的 CreateOrReplaceFunctionF1(v_InVarchar2)ReturnVarchar2IsBeginDbms_Output.Put_Line('execF1'); Returnv_In;EndF1;/CreateOrReplaceFunctionF2(v_InVarchar2)ReturnVarchar2IsBeginDbms_Output.Put_Line('execF2'); Returnv_In;EndF2;/SQL setserverouton;SQL