数据库IO阻塞一般有哪些原因，比如说硬盘问题什么，求指导

因数据库存储在硬盤内，硬盤的读写速度是远远落後于CPU和内存的。所以较容易形成瓶颈导致IO阻塞。有些公司会通过升级硬件、上存储(SAN)来缓解，不过涉及不小的投入。

其实这类问题，很大比重会是因系统架构及编程不规范，导致程序执行效能低下而引发的问题。比如程序员如果查询数据，直接用select * 这样会取出数据表内所有字段的数据，最好程序员形成习惯，select *** 作时只取需要的字段，这让会减少访问的数据量。

此外，还有很多相关的原因和处理方式，这个多去搜索下，就能有所收获。

转： oracle session通常具有三个特征： （1）一个session可能阻塞多个session； （2）一个session最多被一个session阻塞； （3）session阻塞关系不会形成环路。（环路即死锁，oracle能自动解除）因此session的阻塞关系为一棵树，进而DB系统所有session的BLOCK阻塞关系是一个由若干session阻塞关系树构成的森林，而异常session一定会在故障爆发时成为根（root）。 因此，找寻异常锁表session的过程就是找出异常的root。一般认为异常root有两个特征： （1）block树的规模过大，阻塞树规模即被root层层阻塞的session总数； （2）阻塞的平均等待时间过长。 查找异常session的方法一： OEM—>performance—>Blocking Sessions 查找异常session的方法二： select r.root_sid, s.serial#, r.blocked_num, r.avg_wait_seconds, s.username,s.status,s.event,s.MACHINE, s.PROGRAM,s.sql_id,s.prev_sql_id from (select root_sid, avg(seconds_in_wait) as avg_wait_seconds, count(*) - 1 as blocked_num from (select CONNECT_BY_ROOT sid as root_sid, seconds_in_wait from v$session start with blocking_session is null connect by prior sid = blocking_session) group by root_sid having count(*) >1) r, v$session s where r.root_sid = s.sid order by r.blocked_num desc, r.avg_wait_seconds desc该SQL语句即是根据v$session的字段blocking_session统计阻塞树根阻塞session的计数以及平均阻塞时间、并进行排序，排名最前的往往是异常session。

死锁的定位方法

通过检查数据库表，能够检查出是哪一条语句被死锁，产生死锁的机器是哪一台。

1）用dba用户执行以下语句

select username,lockwait,status,machine,program from v$session where sid in

 (select session_id from v$locked_object)

如果有输出的结果，则说明有死锁，且能看到死锁的机器是哪一台。字段说明：

Username：死锁语句所用的数据库用户；

Lockwait：死锁的状态，如果有内容表示被死锁。

Status： 状态，active表示被死锁

Machine： 死锁语句所在的机器。

Program： 产生死锁的语句主要来自哪个应用程序。

2）用dba用户执行以下语句，可以查看到被死锁的语句。

select sql_text from v$sql where hash_value in 

 (select sql_hash_value from v$session where sid in

 (select session_id from v$locked_object))

---