庄老师曾经推荐我们有机会的话去写点数据库监控的脚本,这样可以帮助我们了解数据库,正好这两天上班比较空,于是下载了别人的脚本,拜读了一下,有些体会,和大家分享。
(笔者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版主和君三思大侠~
转载于:https://blog.51cto.com/oxiaobai/622991