ORACLE 管理,SQL 篇--监控

监控事例的等待

selectevent,sum    (decode(wait_Time,0,0,1))"Prev", sum(decode(wait_Time,0,1,0)) "Curr",count(*)"Tot" from v$session_Wait   group by event order by 4;


回滚段的争用情况

selectname, waits, gets, waits/gets "Ratio"    fromv$rollstat C, v$rollname D   where C.usn= D.usn;


监控表空间的 I/O 比例

selectB.tablespace_name nam,

        A.phyblkrd pbr,

        A.phywrts pyw,

        B.file_name "file",

        A.phyrds pyr,

        A.PHYBLKWRTpbw

fromv$filestat A, dba_data_files B  

whereA.file# = B.file_id   order byB.tablespace_name;    


监控文件系统的 I/O 比例

selectsubstr(C.file#,1,2) "#",substr(C.name,1,30) "Name",C.bytes, D.phyrds, D.PHYWRTS, C.status from v$datafile C, v$filestat D          

whereC.file# = D.file#;


监控 SGA 的命中率

selecta.value +    b.value"logical_reads", c. value"phys_reads", round(100 * ((a.value+b.value)-c.value) / (a.value+b.value))"BUFFER HIT RATIO"

fromv$sysstat a, v$sysstat b, v$sysstat c

wherea.statistic# = 38 and b.statistic# = 39and c.statistic# = 40;


监控 SGA 中字典缓冲区的命中率

selectparameter, gets,Getmisses , getmisses/(gets+getmisses)*100 "missratio",

(1-(sum(getmisses)/(sum(getmisses)+sum(getmisses))))*100 "Hit ratio"

fromv$rowcache

wheregets+getmisses <>0

groupby parameter, gets, getmisses;


监控 SGA 中共享缓存区的命中率,应该小于1%

selectsum(pins)    "Total Pins", sum(reloads) "Total Reloads",

sum(reloads)/sum(pins)*100 libcache

fromv$librarycache;                    


selectsum(pinhits-reloads)/sum(pins) "hit radio",sum(reloads)/sum(pins)"reload percent" from v$librarycache;


监控 SGA 中重做日志缓存区的命中率,应该小于1%

SELECTname, gets, misses, immediate_gets, immediate_misses, Decode(gets,0,0,   misses/gets*100) ratio1,

Decode(immediate_gets+immediate_misses,0,0,immediate_misses/(immediate_gets+immediate_misses)*100) ratio2

FROMv$latch WHERE name IN ('redo allocation    ','redo copy');



数据库表空间使用情况监控(字典管理表空间)

数据库运行了一段时间后,由于不断的在表空间上创建和删除对象,会在表空间上产生大量的碎片,DBA应该及时了解表空间的碎片和可用空间情况,以决定是否要对碎片进行整理或为表空间增加数据文件。以下为引用的内容:

selecttablespace_name,

count(*)chunks ,

max(bytes/1024/1024)max_chunk

fromdba_free_space

groupby tablespace_name;

上面的SQL列出了数据库中每个表空间的空闲块情况,如下所示:

以下为引用的内容:

TABLESPACE_NAME         CHUNKS     MAX_CHUNK

-------------------- ----------   ----------

INDX                 1          57.9921875

RBS                  3          490.992188

RMAN_TS             1           16.515625

SYSTEM              1          207.296875

TEMP                20         70.8046875

TOOLS                1          11.8359375

USERS               67         71.3671875

其中,CHUNKS列表示表空间中有多少可用的空闲块(每个空闲块是由一些连续的Oracle数据块组成),如果这样的空闲块过多,比如平均到每个数据文件上超过了100个,那么该表空间的碎片状况就比较严重了,可以尝试用以下的SQL命令进行表空间相邻碎片的接合:

alter tablespace 表空间名coalesce;

然后再执行查看表空间碎片的SQL语句,看表空间的碎片有没有减少。如果没有效果,并且表空间的碎片已经严重影响到了数据库的运行,则考虑对该表空间进行重建。

MAX_CHUNK列的结果是表空间上最大的可用块大小,如果该表空间上的对象所需分配的空间(NEXT值)大于可用块的大小的话,就会提示ORA-1652、ORA-1653、ORA-1654的错误信息,DBA应该及时对表空间的空间进行扩充,以避免这些错误发生。


查看数据库的连接情况

DBA要定时对数据库的连接情况进行检查,看与数据库建立的会话数目是不是正常,如果建立了过多的连接,会消耗数据库的资源。同时,对一些“挂死”的连接,可能会需要DBA手工进行清理。

以下的SQL语句列出当前数据库建立的会话情况:以下为引用的内容:

selectsid,serial#,username,program,machine,status

fromv$session;

输出结果为:以下为引用的内容:


SID  SERIAL#   USERNAME    PROGRAM   MACHINE   STATUS

---- ------- ---------- ----------- --------------- --------

1      1                   ORACLE.EXE  WORK3     ACTIVE

2      1                    ORACLE.EXE  WORK3      ACTIVE

3       1                   ORACLE.EXE  WORK3     ACTIVE

4       1                    ORACLE.EXE  WORK3     ACTIVE

5       3                    ORACLE.EXE  WORK3     ACTIVE

6       1                   ORACLE.EXE  WORK3     ACTIVE

7       1                   ORACLE.EXE   WORK3      ACTIVE

8      27        SYS       SQLPLUS.EXE WORKGROUP\WORK3 ACTIVE

11     5        DBSNMP   dbsnmp.exe  WORKGROUP\WORK3   INACTIVE

注:

SID会话(session)的ID号;

SERIAL#会话的序列号,和SID一起用来唯一标识一个会话;

USERNAME建立该会话的用户名;

PROGRAM这个会话是用什么工具连接到数据库的;

STATUS当前这个会话的状态,ACTIVE表示会话正在执行某些任务,INACTIVE表示当前会话没有执行任何操作。

如果DBA要手工断开某个会话,则执行:

altersystem kill session 'SID,SERIAL#';

注意,上例中SID17(USERNAME列为空)的会话,是Oracle的后台进程,不要对这些会话进行任何操作


查看undo回滚率

SELECT NAME, VALUE

FROM v$sysstat WHERE NAME IN ('user commits', 'transaction rollbacks');

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,390评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,821评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,632评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,170评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,033评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,098评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,511评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,204评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,479评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,572评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,341评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,213评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,576评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,893评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,171评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,486评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,676评论 2 335

推荐阅读更多精彩内容