常用sql巡检语句

1.查表空间占用率：

SELECT a.tablespace_name,
a.total || 'M' total_space,
(a.total - b.free) || 'M' used_space,
to_char((a.total - b.free) / a.total * 100, '99.99') || '%' pct_free
FROM (SELECT tablespace_name, SUM(bytes) / 1024 / 1024 total
FROM dba_data_files
GROUP BY tablespace_name) a,
(SELECT tablespace_name, SUM(bytes) / 1024 / 1024 free
FROM dba_free_space
GROUP BY tablespace_name) b
WHERE a.tablespace_name = b.tablespace_name;

select * from(select segment_name,bytes/1024/1024/1024 gb from dba_segments where tablespace_name='WORKFLOW' order by gb desc) where rownum<100;

2.查是否有锁表

SELECT object_name, s.sid, s.serial#
FROM v$locked_object o, v$session s, dba_objects c
WHERE o.session_id = s.sid
AND o.object_id = c.object_id;

select l.session_id sid,
s.serial#,
l.locked_mode,
l.oracle_username,
s.user#,
l.os_user_name,
s.machine,
s.terminal,
a.sql_text,
a.action
from v$sqlarea a, v$session s, v$locked_object l
where l.session_id = s.sid
and s.prev_sql_addr = a.address
order by sid, s.serial#;

SELECT s.username,

decode(l.type, 'TM', 'TABLE LOCK', 'TX', 'ROW LOCK', NULL) LOCK_LEVEL,

o.owner,

o.object_name,

o.object_type,

s.sid,

s.serial#,

s.terminal,

s.machine,

s.program,

s.osuser
FROM v$session s, v$lock l, dba_objects o
WHERE l.sid = s.sid
AND l.id1 = o.object_id(+)
AND s.username ='WORKFLOW'
----此条件看是不是有人为使用plsql锁表，去掉可查看是不是有程序在锁表---
and program='plsqldev.exe'

----解锁语句（需要dba权限）--
--- alter system kill session '1599,10005'

3.查是否有失效索引

SELECT index_name, table_name, tablespace_name, status, owner
FROM dba_indexes
WHERE owner = 'WORKFLOW'
AND status <> 'VALID'

4.查是否有失效约束

SELECT constraint_type,
constraint_name,
table_name,
r_owner,
r_constraint_name,
status
FROM dba_constraints
WHERE owner = 'WORKFLOW'
AND status <> 'ENABLED'

5.查是否有失效触发器

SELECT trigger_name, table_name, status
FROM dba_triggers
WHERE owner = 'WORKFLOW'
AND status <> 'ENABLED'

6.查共享池

-- 如果命中率低于 90% 则需加大数据库参数 db_cache_size
SELECT NAME,
1 - (physical_reads / (db_block_gets + consistent_gets)) hit_ratio
FROM v$buffer_pool_statistics
WHERE db_block_gets + consistent_gets > 0;

-- 如低于 95%，则需要调整应用程序使用绑定变量，或者调整数据库参数 shared pool 的大小
SELECT SUM(pinhits) / SUM(pins) * 100 hit_radio FROM v$librarycache;

--共享SQL区的使用率,这个使用率应该在90％以上，否则需要增加共享池的大小
select(sum(pins-reloads))/sum(pins) "Library cache" from v$librarycache

--其中: &TSP_IN_M是你的总的共享池的SIZE(M)
SELECT (1 - round(bytes / (&tsp_in_m * 1024 * 1024), 2)) * 100 || '%'
FROM v$sgastat
WHERE NAME = 'free memory'
AND pool = 'shared pool';

--查询空闲的共享池内存
SELECT *
FROM v$sgastat
WHERE NAME = 'free memory'
AND pool = 'shared pool';
--共享池内存使用率，应该稳定在75%-90%间，太小浪费内存，太大则内存不足。

S
3ff0
ELECT NAME,
physical_reads,
db_block_gets,
consistent_gets,
1 - (physical_reads / (db_block_gets + consistent_gets)) "Hit Ratio"
FROM v$buffer_pool_statistics
WHERE NAME = 'DEFAULT';
---通常应在90%以上，否则，需要调整,加大DB_CACHE_SIZE

7.几个常用的检查语句

--查找排序最多的SQL:
SELECT HASH_VALUE, SQL_TEXT, SORTS, EXECUTIONS
FROM V$SQLAREA
ORDER BY SORTS DESC;

--查找磁盘读写最多的SQL:
SELECT *
FROM (SELECT sql_text,
disk_reads "total disk",
executions "total exec",
disk_reads / executions "disk/exec"
FROM v$sql
WHERE executions > 0
AND is_obsolete = 'N'
ORDER BY 4 DESC)
WHERE rownum < 11;

--查找工作量最大的SQL(实际上也是按磁盘读写来排序的):
SELECT substr(to_char(s.pct, '99.00'), 2) || '%' load,
s.executions executes,
p.sql_text
FROM (SELECT address,
disk_reads,
executions,
pct,
rank() over(ORDER BY disk_reads DESC) ranking
FROM (SELECT address,
disk_reads,
executions,
100 * ratio_to_report(disk_reads) over() pct
FROM sys.v_$sql
WHERE command_type != 47)
WHERE disk_reads > 50 * executions) s,
sys.v_$sqltext p
WHERE s.ranking <= 5
AND p.address = s.address
ORDER BY 1, s.address, p.piece;

--用下列SQL工具找出低效SQL:
SELECT executions,
disk_reads,
buffer_gets,
round((buffer_gets - disk_reads) / buffer_gets, 2) hit_radio,
round(disk_reads / executions, 2) reads_per_run,
sql_text
FROM v$sqlarea
WHERE executions > 0
AND buffer_gets > 0
AND (buffer_gets - disk_reads) / buffer_gets < 0.8
ORDER BY 4 DESC;

引用

***************Oracle 缓冲区命中率低的分析及解决办法******************

首先确定下面的查询结果:

1,缓冲区命中率的查询(是否低于90%):

select round((1 - sum(decode(name,'physical reads',value,0)) /

(sum(decode(name,'db block gets',value,0)) + sum(decode(name,'consistent gets',value,0))) ),4) *100 || '%' chitrati

from v$sysstat;

2,使用率的查询(有无free状态的数据快.):

select count(*), status from v$bh group by status ;

3,相关等待事件的查询(是否有相关等待事件)

select event,total_waits from v$system_event where event in ('free buffer waits');

4,当前大小(是否已经很大)

select value/1024/1024 cache_size from v$parameter where name='db_cache_size'

5,top等待事件分析(Db file scatered read的比率是否大)

select event ,total_waits,suml

from

(select event,total_waits,round(total_waits/sumt*100,2)||'%' suml

from

(select event,total_waits from v$system_event ),

(select sum(total_waits) sumt from v$system_event)

order by total_waits desc)

where rownum<6

and event not like 'rdbms%'

and event not like 'pmon%'

and event not like 'SQL*Net%'

and event not like 'smon%';

6,db_cache_advice建议值（9i后的新特性,可以根据他更好的调整cache_size）

select block_size,size_for_estimate,size_factor,estd_physical_reads from v$db_cache_advice;

说明分析:

缓冲区命中率(低于90的命中率就算比较低的).

没有free不一定说明需要增加,还要结合当前cache_size的大小(我们是否还可以再增大,是否有需要增加硬件,增加开销),

空闲缓冲区等待说明进程找不到空闲缓冲区，并通过写出灰缓冲区，来加速数据库写入器生成空闲缓冲区，当DBWn将块写入磁盘后，灰数据缓冲区将被释放，以便重新使用.产生这种原因主要是:

1，DBWn可能跟不上写入灰缓冲区：i/0系统较慢，尽量将文件均匀的分布于所有设备，

2，缓冲区过小或过大。

3，可以增加db_writer_processes数量。

4,可能有很大的一个事物，或者连续的大事物

我们需要长期观察这个事件是否长期存在并数值一直在增大,如果一直在增大,则说明需要增大db_cache大小.或优化sql.

数据分散读等待,通常表现存在着与全表扫描相关的等待，逻辑读时，在内存中进行的全表扫描一般是零散地，而并非连续的被分散到缓冲区的各个部分，可能有索引丢失，或被仰制索引的存在。该等待时间在数据库会话等待多块io读取结束的时候产生，并把指定的块数离散的分布在数据缓冲区。这意味这全表扫描过多，或者io不足或争用，

存在这个事件,多数都是问题的,这说明大量的全部扫描而未采用索引.

db_cache_advice对我们调整db_cache_size大小有一定的帮助,但这只是一个参考，不一定很精确。

通过上面6种情况的综合分析,判断是否需要增加大cache_size. 或者把常用的（小）表放到keep区。

但多数的时候做这些不会解决质的问题,

而真正的问题主要是对sql语句的优化(如:是否存在大量的全表扫描等)

索引是在不需要改变程序的情况下,对数据库性能，sql语句提高的最实用的方法.

我在生产中遇到过类似的问题,200M的cache_size,命中率很低21%,但通过对sql语句的优化(添加索引,避免全表扫描),命中率增加到96%,程序运行时间由原来的2小时减少到不到10分钟.

这就提到了怎么定位高消耗的sql问题.全表扫描的问题,在这里不做细致的解说,这里只说明方法,我会在相关的章节专门介绍怎么使用这些工具

1,sql_trace跟踪session.用tkprof 分别输出磁盘读,逻辑读,运行时间长的sql进行优化.这些高消耗的sql一般都伴随着全表扫描.

2,statspack分析.在系统繁忙时期进行时间点的统计分析,产看TOP事件是否有Db file scatered read.并查看TOP sql语句是否存在问题等.

注：电脑学习网首发。

还要说一句：当然在硬件允许的情况下，尽量增大db_cache_size 减少磁盘读，但并不是越大越好，一定要根据自己的库数据量的程度来调节，因为大的db_cache_size同样会增大数据库管理的开销，当然可能开销并不会明显的影响数据库的性能，硬件价格也越来越低，这就需要我们具体问题具体分析了，在我看来物尽其用就最好了，尽量不要浪费，找到问题的本质。调优是一件很艺术的事。