㈠ 怎么查找oracle比较慢的session和sql
可以查则喊看v$session_longops视图来查看当前运行较慢的session。
最好还是生成awr来查看时间段卜盯答内的数型慧据库运行情况。
㈡ oracle数据库系统视图查询慢
PB连接数据库右键打开一张表的时候要刷新挺多数据的，需要读取一些系统表，获取对象数据结构信息，并且生成一个数据窗口展现数据。这个过程消耗时间。
检查一下如下几个情况：
1、使用的Oracle驱动是否版本匹配，例如：你使用Oracle8的驱动连接Oracle10的数据库，从访问的优化性来将，是有差别的，可能会影响效率；
2、把视图在PL/SQL工具中进行执行计划的查询，检查其性能是否有问题，例如：索引使用不当等情况；
3、程序编译之后执行一下看看，性能是否依旧较低？开发模式下，编译器没有针对性的优化，可能影响到效率。
从开发阶段就开始关注效率，这个是很好的习惯。希望我的回答能对你有帮助。
㈢ oracle 中sql执行超慢几乎查询不出来
套这么多层，而羡历且用到DB LINK表那当然慢了
如果只执行一次最好把DB LINK的表创建一冲槐个中间表过来
再把这几个中间表联查速度兄判搜会快多了
㈣ oracle sql 用什么可以替代or，这样查询特别慢
可以用union，比如select 内容 from user where name='宏兆张稿绝州三' union select 内容 from user where name='李四'，相当于select 内容 from user where name='张三' or name='李四' ，因为union会用到索引，不知道你这键蔽个表有没有索引，表的数据多大？
㈤ Oracle 视图查询有的时候很慢,有的时候查询很快
这种情况有很多可能性，首先，你的服务器的负载情况会影响到你的数据读取速度的，如果数据库服务器执行的进程过多，会导致查询速度下降很多。
另外，第一次执行同一个SQL的时候，都会比较慢一些，再次执行的时候，由于数据等还在内存内，会速度快很多。
再者，在Oracle中，有共享SQL语句的机制，在第一次解析之后, ORACLE将SQL语句存放在内存中.这块位于系统全局区域SGA(system global area)的共享池(shared buffer pool)中的内存可以被所有的数据库用户共享. 因此,当你执行一个SQL语句(有时被称为一个游标)时,如果它 和之前的执行过的语句完全相同, ORACLE就能很快获得已经被解析的语句以及最好的执行路径. 这样也会大大的提高效率。
㈥ oracle 查询的sql语句特别慢，是什么原因，是or特别慢吗，用什么优化，急急急！！！
把查询计划的内容发出来，你这一大堆代码谁能看出来啥啊。看你的代码这么长，条件那么多，语句用了函数，很多低效的or,not in等操作，另外还用了group by，order by，左右连接等等，如果表数据量很大的话，你这个语句性能不好是预料中的事情。如果你这条语句无法优化，建议从调整表结构角度考虑
㈦ oracle sql 查询我使用自已写的函数查询很快，加了函数做条件就很慢是为什么
慢是因为
对于 几十万条记录左右,
你那个 test(a) 函数, 需要执行 很多次， 每行执行一次， 然后判断 LIKE '%123%'
至于：
select a,b, test(a) c from demo; --只这样查很快
我估计你使用的是 PLSQL Developer。
查询的时候， 默认是查询第一页， 因此很快。
因为只显示少部分行。
例如一页20行的话， 那么也就执行你那个函数 20次。
㈧ oracleSQL执行缓慢的分析
问题描述
oracle数据库中一张表的数据已经 亿多 而且此表创建了 个独立的索引 由于业务需要 每天需分两次向此表中插入 万条记录 由于数据量大 每次插入耗时 个小时以上 严重影响效率 因此 修改了系统的算法 将此表中只存储当天新增记录 将此表truncate后 第二天执行对此表的update操作时 非常耗时 表中有 亿多条数据的时候 此sql语句耗时 秒 表中有 万条数据的时候 此sql语句耗时几个小时 咨询DBA后 得出结论 需重建索引 重建后 秒完成此操作 但第三天问题依然出现 DBA正在查找原因 难道每次truncate表 都需要重建索引？
对于这个问题 DBA也没有给出合渣段理的解释 推测主要原因是oracle复杂的查询优化算法
最终备者 DBA给出的解决方案
truncate table
drop index
insert data
create index
*** yze table table_name pute statistics;//重仿梁薯新生成统计数据
lishixin/Article/program/Oracle/201311/16938