首页新闻资讯管理维护网络安全机房管理部署集成网管工具网管资料专题论坛 杂志
当前位置:首页 >> 管理维护 >> 数据库 >> Oracle >> 数据库慢该如何着手?
数据库慢该如何着手?
来源: 作者: 发布时间:2008-04-30

  c. Memory

  第二种情况与memory的关系比较小, 只要SGA区配置合理没有变化, 一般来说, 只要不是Application Memory leak, 不会引起突然变慢的现象.

  第三种情况 “不定时变慢”, 是最难解决的. 现场出现的问题原因也是五花八门千奇百怪, 最重要的是, 出现慢的现象时, 以最快的速度抓取到最多的信息以供分析. 先写好抓取数据的shell 脚本, 并在现象发生时及时按下回车键

  一个例子

  数据库突然变慢

  背景: 一个新应用上线后, 数据库突然变慢

  第一步, 调查新应用

  据开发人员讲新应用访问的都是新建立的表, 表的数据量很小, 没有复杂的SQL查询.

  查询 v$sqlarea 分别按照disk_reads / buffer_gets / executions 排序, TOP SQL 中没有新应用的SQL. 排除新应用数据库访问照成的性能问题.

  第二步, 察看数据库log/ OS log

  数据库log中可以看到大量的ORA-7445错误, 以及大量的dump文件. 分析dump文件(时间久了,没有dump文件可参考, 具体细节没法描述下来. ), 发现是新应用通过dblink访问remote DB时生成的dump文件, 应用开发人说没法修改, Oracle也没有相应的patch解决.

  OS log中没有错误信息

  第三步, 察看statspack report

  从wait events中看到,Top event是“buffer busy waits” “db file parallel write” 等于IO相关的等待事件.

  从buffer busy waits 的统计信息来看, 是等待data block.

  还有些physical reads等信息与从前比没有太多的异常.

  Tablespace 的IO reads/writes也没有异常, 但是wait明显增加.

  初步确定是IO问题.

  第四步, 察看OS的信息

  1. top 命令(输出为实验室数据,仅作格式参考)

  load averages: 0.05, 0.10, 0.09 10:18:32

  307 processes: 304 sleeping, 1 zombie, 1 stopped, 1 on cpu

  CPU states: 96.0% idle, 0.3% user, 2.6% kernel, 1.1% iowait, 0.0% swap

  Memory: 4096M real, 2660M free, 1396M swap in use, 3013M swap free

  PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND

  11928 a21562 1 0 0 3008K 2496K cpu/1 0:02 1.12% top

  14965 mpgj76 4 59 0 10M 3696K sleep 3:09 0.18% view_server

  当时现场数据显示:iowait 值与以前相比大很多, 没有异常进程

  2. sar –d (输出为实验室数据,仅作格式参考)

  SunOS sc19 5.7 Generic_106541-42 sun4u 03/20/08

  00:00:00 device %busy avque r+w/s blks/s avwait avserv

  sd410 17 0.4 50 1628 0.1 7.1

  sd410,a 0 0.0 0 0 0.0 0.0

  sd410,b 0 0.0 0 0 0.0 0.0

  sd410,c 0 0.0 0 0 0.0 0.0

  sd410,g 17 0.4 50 1628 0.1 7.1

  当时现场数据显示,放数据文件的设备 avwait, avque, blks/s值偏大

  第五步, 察看数据库的等待事件

  一个大业务量的数据库如果性能不好的话, 一般来说都会有大量的等待事件, 上百个等待事件很常见, 我通常会按照EVENT进行group.

  Select count(*), event from v$session_wait where event not in ('smon timer','pmon timer','rdbms ipc message','SQL*Net message from client') group by event order by 1 desc;

  输出结果显示最多的等待事件是buffer busy waits。

  进一步分析,找出等待的原因

  Select count(*), p1, p2, p3 from v$session_wait where event = ‘buffer busy waits’ group by p1,p2,p3;

  在buffer busy waits等待事件中

  

(责任编辑:天空)
阅读次数:
网友评论
评论加载中…
 
友情链接 | 欢迎投稿 | 杂志发行 | 广告报价 | 人才招聘 | 服务条款 | 免责声明 | 隐私保护 | 关于网管员世界
CopyRight © 2001-2008 [网管员世界 www.365master.com] All Rights Reserved.
《网管员世界》杂志,专为网管服务的刊物!