讲解数据库变慢的三种情况及具体处理方法(页 1) - 软件学习交流 - 我爱电脑技术论坛打造最好的电脑自学交流论坛

小迷糊 发表于 2008-6-4 09:31

讲解数据库变慢的三种情况及具体处理方法

数据库慢一般有三种情况： &CN$|UUR8NBf

1.逐渐变慢 %o.I+krzS"M*A

2.突然变慢

3.不定时变慢 c8st}yP0S
[|-D`e:Q
第一种情况 “逐渐变慢”，要建立一个长期的监控机制。比如，写个shell脚本每天的忙时(通常9~10 etc.)定时收集os,network,db的信息，每个星期出report对收集到的信息进行分析。这些数据的积累，可以决定后期的优化决策，并且可以是DBA说服manager采用自己决策的重要数据。DBA的价值，就在每个星期的report中体现。 %Z8DS6[9d&ek1B`u
WviE;zuVmc
第二种情况 “突然变慢”，也是最容易解决的。先从业务的角度看是DB的使用跟以前有何不同，然后做进一步判断。硬件/网络故障通常也会引起DB性能的突然下降。 d}7P9RSL:]
#C4]b'h'Jaq?.FF
第一步: 察看DB/OS/NETWORK的系统log, 排除硬件/网络问题

第二步：察看数据库的等待事件，根据等待事件来判断可能出问题的环节。如果, 没有等待事件, 可以排除数据库的问题. 如果有等待时间, 根据不同的等待事件, 来找引起这些事件的根源. s)[!P1\ w$X(o
cy#C5^~@5ak7Y
比如latch free等跟SQL parse有关系的等待事件，OS的表现是CPU 的占用率高 'h#K#In5V]
6ejeQ4w,Fjw
db file scattered read等跟SQL disk read有关系的等待时间， OS的表现是iostat可以看到磁盘读写量增加 OmF~j

第三步: 察看os的信息, CPU/IO/MEMORY等. 5o.RWI%~;If7W
1FruL4lD7uL\hff6r
a. Cpu 的占用率 *Cub-rw'K"DPu
7jaE#Tz j:@V(aS
CPU占用率与数据库性能不成反比. CPU占用率高, 不能说明数据库性能慢. 通常情况, 一个优化很好, 而且业务量确实很大的数据库, CPU的占用率都会高, 而且会平均分布在每个进程上. 反过来, CPU的占用率都会高也不代表数据库性能就好, 要结合数据库的等待事件来判断CPU占用率高是否合理.

如果某个进程的cpu占用高, 肯定是这个进程有问题. 如果,不是oracle的进程, 可以让application察看是否程序有死循环等漏洞. 如果,是oracle的进程, 可以根据pid查找oracle数据字典看看这个进程的发起程序, 正在执行的sql语句, 以及等待事件. 然后, 不同情况使用不同的方法来解决. /S Tn|'LK It/d"p

b. IO &w.Iz`I
Y!ALMNn7O.bE
排除硬件的IO问题, 数据库突然变慢, 一般来说, 都是一个或几个SQL语句引起的.

如果IO很频繁, 可以通过优化disk reads高的TOP SQL来解决. 当然这也是解决IO问题的最笨也是最有效的办法. ^rO)B'g @q

OS以及存储的配置也是影响IO的一个重要的原因. YSZ/|lj~8q
VS@J"`W
比如, 最常见的HP-unix下异步IO的问题, 如果DBA GROUP没有MLOCK的权限, ORACLE是不使用AIO的. 偏偏OS与DB的两方的admin如果配合不够好地话, 这个配置就很容易给漏掉了.

c. Memory
6NsI8Mj5Y)q Fhj5d
第二种情况与memory的关系比较小, 只要SGA区配置合理没有变化, 一般来说, 只要不是Application Memory leak, 不会引起突然变慢的现象. vEd;Y%Q+J2q
LFK c#XB6Hv/X&@
第三种情况 “不定时变慢”, 是最难解决的. 现场出现的问题原因也是五花八门千奇百怪, 最重要的是, 出现慢的现象时, 以最快的速度抓取到最多的信息以供分析. 先写好抓取数据的shell 脚本, 并在现象发生时及时按下回车键 )L)Vu9C&o"?
RaV,b%A*f
一个例子 a6D@0r-}'o&uED
-k f7wq8@
数据库突然变慢 u.| Lq-U^

背景: 一个新应用上线后, 数据库突然变慢
m0Fh8E Z.NE
第一步, 调查新应用 #cPdm)G*O+w!z~G
X2nV!`A
据开发人员讲新应用访问的都是新建立的表, 表的数据量很小, 没有复杂的SQL查询. J)Ilw!]?TiP

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

小迷糊 发表于 2008-6-4 09:31

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

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

OS log中没有错误信息 L0Pf$A*NXB8r
-\${gfk N/Ec
第三步, 察看statspack report
u#hjp,c#q
从wait events中看到,Top event是“buffer busy waits” “db file parallel write” 等于IO相关的等待事件. f)AO-f Tt+Z

从buffer busy waits 的统计信息来看, 是等待data block. Kt+\6QWta
XVa U\oM;i4l+|
还有些physical reads等信息与从前比没有太多的异常.
(w+e*\"n7w
Tablespace 的IO reads/writes也没有异常, 但是wait明显增加. #am8hj Y-r*L

初步确定是IO问题.

第四步, 察看OS的信息 ZQt2aI g,td RM
"p#@ l'H}'^d6?D
1. top 命令(输出为实验室数据，仅作格式参考) B6UMD8_
!`wnDO_qi
load averages: 0.05, 0.10, 0.09 10:18:32 :a-lL9JF#z%y

307 processes: 304 sleeping, 1 zombie, 1 stopped, 1 on cpu TYYyyg3u1A.e

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 h#?Y9U/b1H*w+e$e
PjL1R5_
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
+~R-ID4Dq\
14965 mpgj76 4 59 0 10M 3696K sleep 3:09 0.18% view_server +\,SK+W6fiT^

当时现场数据显示：iowait 值与以前相比大很多，没有异常进程
F%@6e,zB6[#X@+r2L
2. sar –d (输出为实验室数据，仅作格式参考)

SunOS sc19 5.7 Generic_106541-42 sun4u 03/20/08
]2uHP3k
00:00:00 device %busy avque r+w/s blks/s avwait avserv )~!m;N H7JgC
3sh)Yp"h"t9~m-F
sd410 17 0.4 50 1628 0.1 7.1
-\$^B)@,TnD2g
sd410,a 0 0.0 0 0 0.0 0.0 4~C0I5J7Ch h

sd410,b 0 0.0 0 0 0.0 0.0 6B u7[Vl5B
z$|*}-i;SM
sd410,c 0 0.0 0 0 0.0 0.0

sd410,g 17 0.4 50 1628 0.1 7.1 n%bu;sDDZ|;yQ
f6i/yk2eCA
当时现场数据显示，放数据文件的设备 avwait, avque, blks/s值偏大

小迷糊 发表于 2008-6-4 09:31

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

一个大业务量的数据库如果性能不好的话, 一般来说都会有大量的等待事件, 上百个等待事件很常见, 我通常会按照EVENT进行group.
%F.OAD)w-N(z g
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; }p%N%r7rf*W`
_2h0a-t6Stk7p
输出结果显示最多的等待事件是buffer busy waits。
*o0I4Y)~ytVkd
进一步分析，找出等待的原因

Select count(*), p1, p2, p3 from v$session_wait where event = ‘buffer busy waits’ group by p1,p2,p3; 0K7}1?8D"G

在buffer busy waits等待事件中 &cE m3BF z
2|;PaWHn G
P1 = file#
7R:O `7EE&V)T4^
P2 = block#
B)~:k9M!PP?1h
P3 = id ( 此id对应为等待的原因) :L7cy}{._;}o
J2Hu?8cpF
按照p1,p2,p3 group是为了明确buffer busy waits的等待集中在哪些对象上。 ;B EW(\U6X

Metalink对buffer busy waits等待事件的描述有如下一段话： n-C0@+hjZT m.Y7U\$`
H9ow^^:NT3C{\
“If P3 shows that the "buffer busy wait" is waiting for a block read to complete then the blocking session is likely to be waiting on an IO wait (eg: "db file sequential read" or "db file scattered read" for the same file# and block#.” Zh8F[+{aE

输出结果显示，等待分布在多个不同的对象上，等待原因为 “waiting for a block read to complete”，进一步分析为IO的问题。 Y9\.XV\mP:{
c!n u1Eg!hq`
如果，buffer busy waits等待集中在某个对象上，说明有hot block, 通过重新rebuild这个对象增加freelist来解决,RAC环境增加freelist group. "}#M'c4}*Z"Py!~

通过以下SQL可以找到具体的object.

Select owner, segment_name, segment_type from dba_extents where file_id=P1 and P2 between block_id and block_id+blocks;
y:|l X/P-V;N I
P1,P2是上面v$session_wait查出的具体的值
z}8B{!~}"wh1u'e6Y
第六步, 明确原因，找出解决步骤
H6Y1j(sw0J4tI xEV
分析：

1.磁盘的IO流量增加 5m)vtTd3EJ
&KMkZ? J"B7s8FNW7I
2.磁盘的IO等待增加 ,?t q8M*v Q7rfv
;pz5ZdxD5T$g hU0a%D
3.DB的IO流量没有增加

4.DB的IO等待增加 *Y(fPX7J.v
Jr-Tp/[E}
由1，2，3，4可以推出，有数据库以外的IO访问磁盘。 (o$_-aqj.xT

察看磁盘配置，该VG只存放了数据库数据文件和数据库系统文件。排除数据文件，产生IO的是数据库系统文件。

数据库系统文件一般来说不会产生IO, 有IO读写的地方只有log和dump文件。

结论：ora-7445产生的大量core dump文件堵塞IO

解决办法：
J7G2`x&G#I
1.消除ora-7445. (应用不改的情况下，无法解决) 4a iDo-~x2c
i+elW!u.t)yL,N
2.把dump目录指向别的VG
5J#sSw'K*Fd
3.让oracle尽量少的去写core dump文件 a3|"DxbZ

background_core_dump = partial

shadow_core_dump = partial

页: [1]

我爱电脑技术论坛's Archiver

讲解数据库变慢的三种情况及具体处理方法