数据库的简单监控

原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://oxiaobai.blog.51cto.com/3369332/622991

庄老师曾经推荐我们有机会的话去写点数据库监控的脚本，这样可以帮助我们了解数据库，正好这两天上班比较空，于是下载了别人的脚本，拜读了一下，有些体会，和大家分享。

（笔者tmd用得是512的内存跑虚拟机和oracle啊，桑不起）

首先是Instance Health

语句：

select instance_name, status, database_status, archiver, log_switch_wait from v$instance;

解释：

instance_name：实例名称

status： 实例状态，分为started（startup nomount），mounted（startup mount和alter database close），open（alter database open），open migrate（迁移的时候使用的，笔者对这个也不太清楚）

database_status：数据库状态，active（最正常的状态，大多情况下应该是这个状态），suspended（被挂起了），可能还有别的状态，oracle的v$instance的文档也没有贴出哪些可能，所有小白也就捣捣浆糊了

archiver:归档模块的状态，(STOPPED | STARTED | FAILED)，stopped和started就不解释了，failed表示上次归档的时候失败了，将在失败后的5分钟内再次尝试归档

log_switch_wait： 正在等待ARCHIVELOG/CLEAR LOG/ CHECKPOINT事件日志切换.注意:如果ALTER SYSTEM SWITCH LOGFILE挂起,但在当前联机重做日志中还有空间则值为NULL。笔者不太明白这个字段的原理，笔者自己的电脑上这列是空的，网上大多数是 allowed，等待高手指点。

笔者感想：instance是万万不能出问题的，所以对instance监控自是不必说了。

 

 然后是归档目录信息

语句：

select destination,status,error from  v$archive_dest_status where status<>'INACTIVE';

解释：

destination：归档的目录位置

status： 归档目录的状态，valid（正常，表示可用），inactive（不可用），deferred（被用户设置成不可用），error（试图打开或使用时发 现失败），disabled（error之后的状态），bad param（参数设置错误），alternate（指定的归档目录位置是可选择的），full（空间不够）（细读的话可以发现笔者在这里的很多解释都很牵强，比如full和error，但是本文核心主要是在监控，笔者也非常详细的测试，所以在这里就不展开了，以后有机会对这块进行单独测似成文）

error:错误信息

笔者感想：归档的重要性也不用多说了，完全恢复的时候归档是关键，甚至在备份丢失的情况下，数据文件损坏，也可以利用完整的归档拿回来，笔者这里就不展开了

然后是表空间使用情况

语 句：select total.tablespace_name name, MaxFrag, MinFrag, FreeSize, TotalSize, round((1-replace(FreeSize,'M')/replace(TotalSize,'M'))*100,2) PctUsd from
(select tablespace_name,round(nvl(max(bytes)/1024/1024,0),2)||'M' MaxFrag,
round(nvl(min(bytes)/1024/1024,0),2)||'M' MinFrag,
round(nvl(sum(bytes)/1024/1024,0),2)||'M' FreeSize
from dba_free_space
group by tablespace_name) free,
(select tablespace_name,sum(bytes)/1024/1024||'M' TotalSize
from dba_data_files
group by tablespace_name) total
where free.tablespace_name=total.tablespace_name;

解释：虽然很长，但是其实很好懂，很多都是为了显示方便，笔者不逐一解释了，给大家看下结果把

NAME            MAXFRAG    MINFRAG    FREESIZE   TOTALSIZE      PCTUSD
--------------- ---------- ---------- ---------- ---------- ----------
UNDOTBS1        2.31M      .06M       11.38M     30M         62.070000
SYSAUX          .19M       .19M       .19M       230M        99.920000
USERS           2M         2M         2M         5M          60.000000
SYSTEM          6.94M      .63M       7.56M      480M        98.430000
EXAMPLE         31.31M     .44M       31.75M     100M        68.250000

笔者感想：非常实用，sky说过，dba最低级的错误之一就是表空间空间不够- -

然后是buffer cache的命中率，这个监控可以帮助调整buffer cache的大小

语句：

select a.value as "Logical Reads", b.value as "Physical Reads", 100*(1-b.value/a.value) as
"Buffer Hit Ratio" from v$sysstat a, v$sysstat b where a.statistic#=9 and b.statistic#=42;

解释：

这个写的不是很直观，稍微解释一下，a.statistic#=9 是逻辑读的值，b.statistic#=42是物理读的值，这句语句简单的用1-物理读/逻辑读来计算命中率，事实上没这么简单，君三思大侠对于这个部分是这样计算的

select 1-((a.value-b.value-c.value)/d.value)

  from v$sysstat a,v$sysstat b,v$sysstat c,v$sysstat d

  where a.name='physical reads' and

         b.name='physical reads direct' and

         c.name='physical reads direct (lob)' and

         d.name='session logical reads';

意思是，1-（物理读-物理直接读-物理直接读lob类型）/ 逻辑读

笔者感想：这个看上去比前面的要专业一点……

然后是library cache的命中率，从中可以调整shared pool的大小

语句：

select namespace,gets,gethits,gethitratio,reloads from v$librarycache;

解释：

这 里需要解释的是get系列和pin系列，如果读者去自己查看文档的话会发现这个视图中还有pins，pinhits等等，那gets系列和pins系列的 差别在哪里呢？根据笔者粗浅的理解，简单来说，get系列反应的是对对象的请求，而pin是对对象内容的请求。打个比方，有很多蛋糕，对某个蛋糕的请求就 是get系列，而对申请到的蛋糕具体的哪一块就是pin系列了。宏观看的话应该是get系列更能满足我们的需求。这里reload的意思是自从对象被创建 以后需要去磁盘重新读取的次数，那当然是越低越好。

笔者感想：这里的东西挖深下去的话可以挖得很深，以后得空一定要在这个地方好好研究一下。

然后是wait_event，这个应该是排障的时候非常常用的吧

语句：

select * from (select event,total_waits,time_waited, average_wait from v$system_event where
event not like 'SQL*Net%' and event not like '%ipc%' order by total_waits desc) where
rownum<11;

解释：

top 10的等待事件，统计的信息包括等待次数，等待时间，平均时间等

这里，脚本的原作者屏蔽掉了sql*net和ipc两个event，笔者做了实验，也做了相关查询，结果如下

不屏蔽：

EVENT                          TOTAL_WAITS TIME_WAITED AVERAGE_WAIT
------------------------------ ----------- ----------- ------------
rdbms ipc message                    11837     7059865       596.42
db file sequential read               5055       26649         5.27
control file sequential read          2849         911          .32
control file parallel write           1264       12736        10.08
pmon timer                            1220      694990       569.66
jobq slave wait                       1167      646269       553.79
undo segment extension                 778         129          .17
log file parallel write                601        6803        11.32
SQL*Net message to client              326           3          .01
SQL*Net message from client            322      584115      1814.02

屏蔽：

EVENT                          TOTAL_WAITS TIME_WAITED AVERAGE_WAIT
------------------------------ ----------- ----------- ------------
db file sequential read               5052       26646         5.27
control file sequential read          2790         910          .33
control file parallel write           1187       12644        10.65
pmon timer                            1140      650673       570.77
jobq slave wait                       1087      602028       553.84
undo segment extension                 778         129          .17
log file parallel write                564        6712         11.9
db file scattered read                 259        6523        25.19
Streams AQ: qmn slave idle wai         218     1000632      4590.05
t

log file sync                          201        1459         7.26

可以看到，主要是屏蔽了rdbms ipc message和SQL*Net message to/from client事件，这3个事件都属于idle事件，一般情况下对性能不会有太大的影响，请注意是一般情况下 ，分别是后台进程表示自己闲置，以及client对接收和发送信息的一个闲置（后两个通常由网络造成）

笔者感想：owe（oracle wait event）绝对可以单独拿出来好好研究的，这里只是一个简单的监控而已

最后了！是sql语句的一个监控

语句：

select * from (select sql_text,buffer_gets/executions buffer_gets from v$sqlarea where executions<>0 order by buffer_gets desc) where rownum<6;

解释：

top 5耗资源的sql语句，这里的资源主要还是指buffer_gets，仔细研究视图的话可以发现还有很多其他指标可以根据需求自己定制（例如cpu运行时间啦，内存使用啦等很多）

笔者感想：sql语句的性能查询啊，包括调优啊这些都是dba实力的体现，这里也埋下伏笔，以后sql调优肯定是必不可少的研究题目。

总结：其实看似简单的数据库监控面很广，这里都是比较浅的点到为止而已，其中涉及到的任何一点都可以单独成为甚至可以写成书籍，三言两语只能说个大概，希望能对各位有用。最后，感谢分享脚本的itpub版主和君三思大侠～

本文出自 “oracle小白前进之路” 博客，请务必保留此出处http://oxiaobai.blog.51cto.com/3369332/622991