oracle 查询单表很慢是什么原因

数据量大的话会很慢,可以建个索引。

现象： 表查询了半天也没出结果，表里大概有几十条数据

配置： Oracle 10G RAC 、Aix Unix *** 作系统

处理过程：

我的第一反应数据库问题不大，因为只有这张表查询慢，而数据库里其它表数据的查询速度正常，但是按照流程还是先查看了alert日志，看了看临时表空间和系统表空间状况，结果两个节点都很正常没有问题；

然后我就怀疑可能是表锁的问题

select sid,seq#,event from v$session_wait

SID SEQ# EVENT

729 30819 cursor: pin S wait on X

730 55091 cursor: pin S wait on X

731 64627 cursor: pin S wait on X

733 13616 cursor: pin S wait on X

734 3754 cursor: pin S wait on X

735 49828 cursor: pin S wait on X

736 39022 cursor: pin S wait on X

737 44358 cursor: pin S wait on X

738 17548 cursor: pin S wait on X

739 54959 cursor: pin S wait on X

740 26186 cursor: pin S wait on X

741 4140 cursor: pin S wait on X

743 5668 cursor: pin S wait on X

747 54012 cursor: pin S wait on X

看到了很多 cursor: pin S wait on X 事件

然后根据这些SID找到SESSION

select from v$session where sid in(

'908','923','949','984','1034','1012','1015',

'1049','969','936','950','902','954','905',

'924','929','1018','967','993','920','945','1048')

把这些session杀掉

alter system kill session '902,44335';

alter system kill session '905,45229';

alter system kill session '908,5869';

alter system kill session '920,17125';

alter system kill session '923,43172';

alter system kill session '924,614';

alter system kill session '929,669';

alter system kill session '936,1092';

alter system kill session '945,48687';

alter system kill session '949,61466';

alter system kill session '950,50965';

alter system kill session '954,24688';

alter system kill session '967,61065';

alter system kill session '969,63579';

alter system kill session '984,57651';

alter system kill session '993,65365';

alter system kill session '1012,47090';

alter system kill session '1015,59755';

alter system kill session '1018,52751';

alter system kill session '1034,36331';

alter system kill session '1048,13283';

alter system kill session '1049,58233';

但是结果并不理想，执行上面语句后去查询表依然还是长时间不能出来结果，

且在v$session里查这些session都标记为killed了，然后就想到了到 *** 作系统

级别将这些session进程占用的资源彻底的给释放掉，如下

# kill -9 700924

# kill -9 835748

# kill -9 798908

# kill -9 696720

# kill -9 635236

# kill -9 872802

# kill -9 856554

# kill -9 679966

# kill -9 786648

# kill -9 676248

# kill -9 774198

# kill -9 782442

# kill -9 319908

# kill -9 778586

# kill -9 794812

# kill -9 331788

# kill -9 676090

# kill -9 123228

# kill -9 893198

# kill -9 585828

# kill -9 340378

# kill -9 565494

#

经kill -9 以后，再去查询表，结果很快就出来了

现已证实，是此表被锁住的原因，已经让开发去查表设计和使用问题了

0现象

1原因：新建连接时，需要根据/etc/resolvconf去解析，当解析失败达到超时时间后才可以连接

注释点对应的nameserver即可

cat /etc/resolvconf

2注释后带来的问题

3延伸拓展

在oracle中

不关是执行sql还是存储过程，当你第一次执行的时候需要对相关语句进行相关权限、对象等分析，这个过程会产生执行计划,叫做硬解析,如果分析通过,之后将语句转化成ascii等效数字码，再通过hash算法得到散列值,然后检查库缓存中是否存在同样hash值的语句。

如果存在,就是软解析然后就执行语句得出结果所以第一次执行的时候要是硬解析,速度较慢,而第二次已经以后多次执行的时候是软解析,速度较快大概就这样

如果要详细说

这东西几个钟头都说不完的

方法如下：

Oracle中建立索引，会提高查询速度： create index 索引名 on 表名(列名);

例如：

create index index_userid on tbl_detail(userid);

如何找数据库表的主键字段的名称

SELECT FROM user_constraints WHERE CONSTRAINT_TYPE='P' and table_name='AAA'; select from dba_cons_columns where CONSTRAINT_NAME='SYS_AAA';

Oracle 在创建主键（可以不加constraint SYS_AAA），会为库表自动创建索引，

索引的列为主键列。 并且当库表某些列名或者库表名改变时候，

Oracle自动创建的索引SYS_AAA,中的索引列也会自动更新（类似于视图），并且SYS_AAA会与名字更改后的库表还是保持索引关系。 关键系统库表： desc dba_constraints desc dba_cons_columns

desc dba_indexes desc dba_ind_columns desc DBA_TAB_COLUMNS

例子1：更改库表的列名

ALTER TABLE AAA RENAME COLUMN ID TO AAA_ID; create table AAA ( ID NUMBER(8), NAME CHAR(20),

constraint SYS_AAA primary key(ID) );

//查找约束名字

select cCONSTRAINT_NAME,ctable_name,ccCOLUMN_NAME from user_constraints c, user_cons_columns cc

where cconstraint_name=ccconstraint_name and ctable_name ='AAA' AND CCONSTRAINT_TYPE='P';

CONSTRAINT_NAME TABLE_NAME COLUMN_NAME ------------------------------ ------------ ------------- SYS_AAA AAA ID

//查找索引

select index_name,index_type,uniqueness from user_indexes where table_name='AAA'; INDEX_NAME INDEX_TYPE UNIQUENES

cursor: mutex events等待事件

cursor: mutex events等待事件用于Cursor Parent 和 Cursor stats类型的 *** 作：

‘Cursor: Mutex S’ ， 某个进程以SHRD S mode申请一个Mutex， 而该Mutex要么被其他进程已EXCL X mode所持有，要么其他进程正在更新mutex 上的Ref Count。

相关类型的 *** 作一般是检测父游标或者CURSOR统计信息数据， 此外查询V$SQLSTATS也会造成CURSOR statistics被查询

如果自己搞不定可以找ASKMACLEAN专业ORACLE数据库修复团队成员帮您恢复!

以上就是关于oracle 查询单表很慢是什么原因全部的内容，包括:oracle 查询单表很慢是什么原因、oracle 数据库新开连接慢（连上后速度正常）、oracle数据库存储过程执行慢时如何优化等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！