sql性能分析oracle

❶ Oracle 11g最有特点的五大特性都有哪些

与无压缩格式下存储数据相比，新的Oracle数据压缩技术能够确保以较小的开销节省三倍以上的磁盘存储空间。这一点比仅节省磁盘空间要具有更大的优势，因为它能够使企业节约更多的开支，以便有更多的资金来巩固自己的地位。
自动诊断知识库（Automatic Diagnostic Repository，ADR）是专门针对严重错误的知识库。该知识库基本上能够自动完成一些以往需要由数据库管理员来手动完成的操作。
作为ADR的一部分，sql性能分析器（SQL Performance Analyzer，SPA）是最让人惊喜的特性之一。SQL性能分析器是一个整体调整工具，管理员可以通过该工具在数据库上定义和重演(replay) 一个典型的工作负载，之后管理员可以调节整体参数来使数据库尽快的达到最佳性能——而这一任务同样也是许多年以来由数据库管理员手动完成的。
由于获得了最优的初始参数，数据库管理员就不需要调整数以万计的SQL语句。管理员需要做的就是给定一个典型的负载 ，由SAP根据历史记录来决定SQL的最终设置，而不用管理员来检测哪一个SQL设置是最合理的。
多年以来，甲骨文公司一直在努力完成地另一个新特性便是“联机更新”(在不down机的情况下更新软件)。实际上，很难从软件工程的角度来设计一个运行时能自动升级的软件。由于真正的应用集群（Real Application Clusters ，RAC）特性，甲骨文公司再一次对其他的数据库供应商造成了更大的压力。在实际的使用过程中，数据库产品的用户总是希望产品有持续的高可用性，这并不是说只需满足下次补丁更新之前的3年的时间就够了。
自动内存管理特性可以追根溯源至Oracle 9i，那时甲骨文公司推出首款自动调节存储池的工具。AMM工具其实就是一种探测机制。实际上，Oracle 11g 有很多随机访问存储池，当AMM探测到某个存储池中已满时，它将整个RAM从一个区域分配到其他相对合适的区域。

❷ 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

❸ oracle awr报告怎么分析一个sql的性能好坏

awr里面只能初步判断，判断标准包括，执行次数，执行时间等。还要根据报告的等待事件等来确定是否要对sql进行调整。再往下就要自己对sql进行执行计划分析，10046,10053事件的追踪了。

❹ 如何查询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性能优化需注意哪些

1，sql的写法，有很多资料，不一一列举
比如 >= , <= 在一起的时候，直接用between and 等等。。。
2，加index

❻ 如何对Oracle sql 进行性能优化的调整

在SQL查询中，为了提高查询的效率，我们常常采取一些措施对查询语句进行SQL性能优化。本文我们总结了一些优化措施，接下来我们就一一介绍。
1.查询的模糊匹配
尽量避免在一个复杂查询里面使用 LIKE '%parm1%'—— 红色标识位置的百分号会导致相关列的索引无法使用，最好不要用。
解决办法:
其实只需要对该脚本略做改进，查询速度便会提高近百倍。改进方法如下：
a、修改前台程序——把查询条件的供应商名称一栏由原来的文本输入改为下拉列表，用户模糊输入供应商名称时，直接在前台就帮忙定位到具体的供应商，这样在调用后台程序时，这列就可以直接用等于来关联了。
b、直接修改后台——根据输入条件，先查出符合条件的供应商，并把相关记录保存在一个临时表里头，然后再用临时表去做复杂关联。
2.索引问题
在做性能跟踪分析过程中，经常发现有不少后台程序的性能问题是因为缺少合适索引造成的，有些表甚至一个索引都没有。这种情况往往都是因为在设计表时，没去定义索引，而开发初期，由于表记录很少，索引创建与否，可能对性能没啥影响，开发人员因此也未多加重视。然一旦程序发布到生产环境，随着时间的推移，表记录越来越多。这时缺少索引，对性能的影响便会越来越大了。
法则：不要在建立的索引的数据列上进行下列操作:
避免对索引字段进行计算操作
避免在索引字段上使用not，>，!=
避免在索引列上使用IS NULL和IS NOT NULL
避免在索引列上出现数据类型转换
避免在索引字段上使用函数
避免建立索引的列中使用空值
3.复杂操作
部分UPDATE、SELECT 语句 写得很复杂（经常嵌套多级子查询）——可以考虑适当拆成几步，先生成一些临时数据表，再进行关联操作。
4.update
同一个表的修改在一个过程里出现好几十次，如：

update table1 set col1=... where col2=...; update table1 set col1=... where col2=... ...

这类脚本其实可以很简单就整合在一个UPDATE语句来完成（前些时候在协助xxx项目做性能问题分析时就发现存在这种情况）
5.在可以使用UNION ALL的语句里，使用了UNION
UNION 因为会将各查询子集的记录做比较，故比起UNION ALL ，通常速度都会慢上许多。一般来说，如果使用UNION ALL能满足要求的话，务必使用UNION ALL。还有一种情况大家可能会忽略掉，就是虽然要求几个子集的并集需要过滤掉重复记录，但由于脚本的特殊性，不可能存在重复记录，这时便应该使用 UNION ALL，如xx模块的某个查询程序就曾经存在这种情况，见，由于语句的特殊性，在这个脚本中几个子集的记录绝对不可能重复，故可以改用UNION ALL）。
6.在WHERE 语句中，尽量避免对索引字段进行计算操作
这个常识相信绝大部分开发人员都应该知道，但仍有不少人这么使用，我想其中一个最主要的原因可能是为了编写写简单而损害了性能，那就不可取了。9月份在对XX系统做性能分析时发现，有大量的后台程序存在类似用法，如：where trunc(create_date)=trunc(:date1)，虽然已对create_date 字段建了索引，但由于加了TRUNC，使得索引无法用上。此处正确的写法应该是where create_date>=trunc(:date1) and create_date pre="">>或者是where create_date between trunc(:date1) and trunc(:date1)+1-1/(24*60*60)。
注意：因between 的范围是个闭区间（greater than or equal to low value and less than or equal to high value.），故严格意义上应该再减去一个趋于0的小数，这里暂且设置成减去1秒（1/(24*60*60)），如果不要求这么精确的话，可以略掉这步。

❼ 如何测试oracle sql的执行效率

要分析SQL的效能，最好是看看执行计划什么怎么走的，根据你具体业务逻辑以及表中数据量来具体分析.在pl/sql developer 里是按f5

❽ SQL和Oracle性能比较

在处理几十级的查询时，SQL速度比ORA慢，SQL在处理多用户时速度会变的比较慢，这个并发多用户大概数值是100

❾ 如何检查oracle数据库性能

这种问题要回答好要求知识比较全面。
1 从操作系统层次上看
看CPU 内存 swqp（交换分区）等使用率
2 从磁盘上看
主要看磁盘读写。可以用dd测磁盘读写的速度 也可以在业务高峰期检测磁盘的速率。
3 从数据库本身来看。
先要看数据库各个参数的值 。 如sga的大小，process的大小，redo日志的个数与大小等这些关系到性能的参数是否设置合理。
长期观察的方式就是看各个时期的AWR报告。里面有各种性能指标，以及按执行时间或资源排列的sql ，以及各种等待时间的排名。从这里面可以掌握数据库的长期的性能变化。
即时观察的方式就是利用各种sql 查询 数据库在当前时间的各个性能指标(AWR报告里面的各种指标也都是通过sql查询出来的)
还有对数据库整体的一个检查：
如 表的大小，表是否需要分区而没有分区，索引是否创建，索引是否失效，开发人员写的sql是否正确使用到了索引，频繁使用的sql是否有绑定变量，有频繁大批量增删改的表是否存在高水位。。。
额 总之，这个话题涉及的知识非常多，尽可能多的学习一些东西，祝你好运。