共计 3853 个字符，预计需要花费 10 分钟才能阅读完成。
自动写代码机器人，免费开通
这篇文章主要介绍“怎么解决数据库变慢问题”，在日常操作中，相信很多人在怎么解决数据库变慢问题问题上存在疑惑，丸趣 TV 小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”怎么解决数据库变慢问题”的疑惑有所帮助！接下来，请跟着丸趣 TV 小编一起来学习吧！
第一章 检查系统的状态
1.1 使用 sar 来检查操作系统是否存在 IO 问题
1.2 关注内存 vmstat
1.3 找到使用资源特别大的 Oracle 的 session 及其执行的语句
1.4 查找前十条性能差的 sql 语句
第二章 检查会话状态
当数据库变慢时，我们应如何入手
当应用管理员通告现在应用很慢、数据库很慢时，当 Oracle DBA 在数据库上做几个示例的 Select 也发现同样的问题时，有些时侯就会无从下手，因为 DBA 认为数据库的各种命种率都是满足 Oracle 文档的建议。实际上如今的优化己经向优化等待 (waits) 转型了，实际中性能优化最根本的出现点也都集中在 I /O，这是影响性能最主要的方面，由系统中的等待去发现 Oracle 库中的不足、操作系统某些资源利用的不合理是一个比较好的办法。下面把一些实践经验与大家分享，本文测重于 Unix 环境。
第一章 检查系统的状态
通过操作系统的一些工具检查系统的状态，比如 CPU、内存、交换、磁盘的利用率，根据经验或与系统正常时的状态相比对，有时系统表面上看起来看空闲，这也可能不是一个正常的状态，因为 cpu 可能正等待 IO 的完成。除此之外，还应观注那些占用系统资源 (cpu、内存) 的进程。
1.1 使用 sar 来检查操作系统是否存在 IO 问题
#sar -u 2 10 — 即每隔 2 秒检察一次，共执行 20 次。
结果示例：
注：在 redhat 下，%system 就是所谓的 %wio。
Linux 2.4.21-20.ELsmp (YY075) 05/19/2005
10:36:07 AM CPU %user %nice %system %idle
10:36:09 AM all 0.00 0.00 0.13 99.87
10:36:11 AM all 0.00 0.00 0.00 100.00
10:36:13 AM all 0.25 0.00 0.25 99.49
10:36:15 AM all 0.13 0.00 0.13 99.75
10:36:17 AM all 0.00 0.00 0.00 100.00
其中：
Oslash; %usr 指的是用户进程使用的 cpu 资源的百分比；
Oslash; %sys 指的是系统资源使用 cpu 资源的百分比；
Oslash; %wio 指的是等待 io 完成的百分比，这是值得观注的一项；
Oslash; %idle 即空闲的百分比。
如果 wio 列的值很大，如在 35% 以上，说明系统的 IO 存在瓶颈，CPU 花费了很大的时间去等待 I / O 的完成。Idle 很小说明系统 CPU 很忙。像以上的示例，可以看到 wio 平均值为 11，说明 I / O 没什么特别的问题，而 idle 值为零，说明 cpu 已经满负荷运行了。
当系统存在 IO 问题时，可以从以下几个方面解决：
Oslash; 联系相应的操作系统的技术支持对这方面进行优化，比如 hp-ux 在划定卷组时的条带化等方面。
Oslash; 查找 Oracle 中不合理的 sql 语句，对其进行优化；
Oslash; 对 Oracle 中访问量频繁的表除合理建索引外，再就是把这些表分表空间存放以免访问上产生热点，再有就是对表合理分区。
1.2 关注内存
常用的工具便是 vmstat，对于 hp-unix 来说，可以用 glance。Aix 来说可以用 topas。当发现 vmstat 中 pi 列非零，memory 中的 free 列的值很小，glance、topas 中内存的利用率多于 80% 时，这时说明内存方面应该调节一下。方法大体有以下几项：
Oslash; 划给 Oracle 使用的内存不要超过系统内存的 1 /2，一般保在系统内存的 40% 为益。
Oslash; 为系统增加内存；
Oslash; 如果你的连接特别多，可以使用 MTS 的方式；
Oslash; 打全补丁，防止内存漏洞。
1.3 找到使用资源特别大的 Oracle 的 session 及其执行的语句
Hp-unix 可以用 glance 或 top。IBM AIX 可以用 topas。此外可以使用 ps 的命令。
通过这些程序可以找到点用系统资源特别大的这些进程的进程号，就可以通过以下的 sql 语句发现这个 pid 正在执行哪个 sql，这个 sql 最好在 pl/sql developer、toad 等软件中执行：
SELECT a.username, a.machine, a.program, a.sid, a.serial#, a.status,
c.piece, c.sql_text
FROM v$session a, v$process b, v$sqltext c
WHERE b.spid = ORCL
AND b.addr = a.paddr
AND a.sql_address = c.address(+)
ORDER BY c.piece;
可以把得到的这个 sql 分析一下，看一下它的执行计划是否走索引。对其优化避免全表扫描，以减少 IO 等待，从而加快语句的执行速度。
提示：在做优化 sql 时，经常碰到使用 in 的语句，这时一定要用 exists 把它给换掉，因为 Oracle 在处理 In 时是按 Or 的方式做的，即使使用了索引也会很慢。比如：
SELECT col1, col2, col3 FROM table1 a
WHERE a.col1 NOT IN (SELECT col1 FROM table2)
可以换成：
SELECT col1, col2, col3 FROM table1 a
WHERE NOT EXISTS
(SELECT x FROM table2 b WHERE a.col1=b.col1)
1.4 查找前十条性能差的 sql 语句
SELECT * FROM (SELECT parsing_user_id, executions, sorts, command_type,
disk_reads, sql_text FROM v$sqlarea
ORDER BY disk_reads DESC)
WHERE ROWNUM
第二章 检查会话状态
要快速发现 Oracle Server 的性能问题的原因，可以求助于 v$session_wait 视图，看系统的这些 session 在等什么，使用了多少的 IO。以下是参考脚本：
— 脚本说明：查看占 I / O 较大的正在运行的 session：
SELECT se.sid, se.serial#, pr.spid, se.username, se.status, se.terminal,
se.program, se.module, se.sql_address, st.event, st.p1text,
si.physical_reads, si.block_changes
FROM v$session se, v$session_wait st, v$sess_io si, v$process pr
WHERE st.sid=se.sid AND st.sid=si.sid
AND se.PADDR=pr.ADDR
AND se.sid 6
AND st.wait_time=0
AND st.event NOT LIKE %SQL%
ORDER BY physical_reads DESC;
对检索出的结果的几点说明：
1． 以上是按每个正在等待的 session 已经发生的物理读排的序，因为它与实际的 I / O 相关。
2． 可以看一下这些等待的进程都在忙什么，语句是否合理？
SELECT sql_address FROM v$session WHERE sid=;
SELECT * FROM v$sqltext WHERE address=;
执行以上两个语句便可以得到这个 session 的语句。
也以用 alter system kill session sid, serial# 把这个 session 杀掉。
3． 应观注一下 event 列，这是调优的关键一列，下面对常出现的 event 做以简要的说明：
1）buffer busy waits，free buffer waits 这两个参数所标识是 dbwr 是否够用的问题，与 IO 很大相关的，当 v$session_wait 中的 free buffer wait 的条目很小或没有时，说明系统的 dbwr 进程决对够用，不用调整；free buffer wait 的条目很多，系统感觉起来一定很慢，这时说明 dbwr 已经不够用了，它产生的 wio 已经成为数据库性能的瓶颈，这时的解决办法如下：
Oslash; 增加写进程，同时要调整 db_block_lru_latches 参数：
示例：修改或添加如下两个参数
db_writer_processes=4
db_block_lru_latches=8
Oslash; 开异步 IO。IBM 这方面简单得多，hp 则麻烦一些，可以与 Hp 工程师联系。
2）db file sequential read，指的是顺序读，即全表扫描，这也是应尽量减少的部分，解决方法就是使用索引、sql 调优，同时可以增大 db_file_multiblock_read_count 这个参数。
3）db file scattered read 参数指的是通过索引来读取，同样可以通过增加 db_file_multiblock_read_count 这个参数来提高性能。
4）latch free 与栓相关，需要专门调节。
5）其他参数可以不特别观注
到此，关于“怎么解决数据库变慢问题”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注丸趣 TV 网站，丸趣 TV 小编会继续努力为大家带来更多实用的文章！
向 AI 问一下细节
