巡检工具涉及脚本注解

1.使用echo “ ”|sqlplus -S ‘/as sysdba’的方法无法设置列宽

所以在chk_ora这个函数中

2.表空间使用率脚本

SELECT total.tablespace_name,

       Round(( 1 - free.MB / total.MB ) * 100, 2)

       || '%'                       AS Used_Pct

FROM   (SELECT tablespace_name,

               Sum(bytes) / 1024 / 1024 AS MB

        FROM   dba_free_space

        GROUP  BY tablespace_name) free,

       (SELECT tablespace_name,

               Sum(bytes) / 1024 / 1024 AS MB

        FROM   dba_data_files

        GROUP  BY tablespace_name) total

WHERE  free.tablespace_name = total.tablespace_name;

12c中上面的sql可能会由于回收站或者执行计划导致很卡，建议用下面的sql

SELECT d.TABLESPACE_name,dt.STATUS,used_space*8/1024/1024 USED_GB,tablespace_size*8/1024/1024 TOTAL_GB,used_percent FROM DBA_TABLESPACE_USAGE_METRICS d ,dba_tablespaces dt

      where d.TABLESPACE_NAME = dt.TABLESPACE_NAME

      ORDER BY d.used_percent DESC;

3.从dba_segments中找出占用SYSTEM表空间中排名前10位的大对象：

 SELECT * FROM (SELECT SEGMENT_NAME, SUM(BYTES) / 1024 / 1024 MB FROM DBA_SEGMENTS WHERE TABLESPACE_NAME = 'SYSTEM' GROUP BY SEGMENT_NAME ORDER BY 2 DESC) WHERE ROWNUM < 10;

4.#Check redo buffer allocation retries and redo entries

关于log buffer的注意

a.    MAX(0.5M, (128K * number of cpus))

b.    On most systems, sizing the log buffer larger than 1M does not provide any

　　performance benefit.It merely uses extra memory.

c.    查看redo buffer allocation retries，当值为0的时候比较合适，否则就要重设redo log

 buffer

select name,value from v$sysstat where name='redo entries' or name='redo buffer allocation retries' order by NAME;

d.    log buffer space wait even 如果这个等待事件是主要的event 之一，说明log buffer 大小需要考虑下调整下大小了

　　----log_buffer 参数的修改需要重启服务器才能生效

　　show parameter log_buffer

　　alter system set log_buffer=xxx scope=spfile;

5.enqueue deadlocks

发生过的死锁次数

oracle提供两种lock，一种是latch，一种是enqueue。

6.libary cache（命中率）

Library cache是Shared pool的一部分

Library cache需要解决三个问题：

a.    快速定位的问题：Library cache中对象众多，Oracle如何管理这些对象，以便服务进程可以迅速找到他们需要的信息。比如某个服务进程需要迅速定位某个SQL是否存在于Library cache中。

b.    关系依赖的问题：Library cache中的对象存在复杂的依赖关系，当某个objec失效时，可以迅速将依赖其的对象也置为失效状态。比如某个表发生了结构变化，依赖其的SQL语句需要重新解析。

c.    并发控制的问题：Library cache中必须有一个并发控制的机构，比如锁机制，来管理大量共享对象的并发访问和修改的问题，比如某个SQL在重新编译的同时，其所依赖的对象不能被修改。

lc的命中率通常在98%以上，否则，需要要考虑加大共享池，绑定变量，修改cursor_sharing等参数。

7.  DB buffer cache 命中率

命中率计算公式

Hit Radio=1-physical reads/(db block gets+consistent gets)

先查询db block gets、physical reads、consistent gets

select name,value from v$sysstat where name in('db block gets','consistent gets','physical reads');

然后根据公式计算出结果

SQL> show parameter db_block_buffers

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_block_buffers                     integer     0

由于10G中引入了SGA自动管理，所以show parameter 查出来的db_block_buffers为 0

查看当前buffer cache size

SQL> select name ,bytes/1024/1024 Mb from v$sgainfo where name ='Buffer Cache Size';

NAME                                     MB
-------------------------------- ----------

Buffer Cache Size                       288     这个buffer cache size 指的是 default + keep +recycle 的和

如果一个长期运行的database 长期的 Hit Radio<90%,那么就应该考虑多分配点内存给buffer cache ,同时增加物理内存，或者SQL调优

汇总命令是

select (1-(sum(decode(name,'physical reads',value,0))/(sum(decode(name,'db block gets',value,0))+sum(decode(name,'consistent gets',value,0)))))*100 "Hit_Ratio" from v$sysstat;

理想的hit radio 应该在 95%以上

8. v$log_history

 V$LOG_HISTORY

这个视图包含来自控制文件的历史信息。 

 列                                                 数据类型                      说明

 

THREAD#	NUMBER	归档日志线程号
SEQUENCE#	NUMBER	归档日志序列号
FIRST_TIME	NUMBER	归档日志中的第一项的时间（最低SCN）。此列以前名为TIME
FIRST_CHANGE#	NUMBER	日志中最低SCN。这个列以前名为FIRST_CHANGE#
NEXT_CHANGE#	NUMBER	日志中最高SCN。这个列以前名为HOGH_CHANGE#
RECID	NUMBER	控制文件记录ID
STAMP	NUMBER	控制文件记录时间戳