数据库异常缓慢的解决 - FAST_START_PARALLEL_ROLLBACK

最新推荐文章于 2023-09-03 15:55:53 发布

congyi3835

最新推荐文章于 2023-09-03 15:55:53 发布

阅读量614

点赞数

文章标签：数据库

现象：

1. 应用连接数据异常缓慢。

2，数据库主机cpu占用率居高不下， io 写入居高不下。

分析：

1 首先，怀疑应用有问题。

因为多个应用连接数据库，所以一个个应用停止后，查看其他应用的数据库执行速度。

经过测试。只剩下最后一个应用后，执行速度仍然很慢，数据库cpu仍然占用很高。

2 接着怀疑是数据库的问题。

接着怀疑是数据库的问题，把最后一个应用也停止，把监听器停止。重启数据库，发现主机的io, cpu仍然是居高不下。把数据库关闭后，io,cpu马上就到了清闲状态。

重启主机，启动数据库，数据库open很慢.

shutdown immediate 数据库很慢，关闭期间观察alert日志。发现redo日志从第一个切换到最后一个，然后又开始一伦的切换。

为什么没有任何应用接入的情况下，数据库又大量的日志产生呢？

在观察后台的进程，发现有ora_p001,ora_p002........ora_p009.的后台。比较其他生产数据库，并没有这些进程。看来真的是数据库自己再做大量的操作。

那么数据库究竟在做什么操作呢？

首先观察一下IO

$ iostat 5 3 -- ----5秒收集一次io,收集3次

avg-cpu: %user %nice %sys %iowait %idle
9.48 0.00 2.30 31.16 57.06

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 12.03 85.00 6006.35 1030538 72817516
sda1 0.05 0.11 0.00 1332 4

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 146.09 2327.86 25.65 11616 128 ---------- sda是数据文件所在的位置。
sda1 0.00 0.00 0.00 0 0
sda2 0.00 0.00 0.00 0 0
sda3 148

tps 意义: 平均每秒钟的IO请求次数.

生产系统最繁忙的时候 tps 也就等于30左右，而这个空转的数据库居然有146次。

观察一下数据库又那些等待
SQL> select SID ,SEQ# ,EVENT from v$session_wait;

SID SEQ# EVENT
---------- ---------- --------------------------------------------------
189 2 Streams AQ: qmn slave idle wait
192 2 Streams AQ: waiting for time management or cleanup
tasks

197 1 jobq slave wait
201 6 Streams AQ: qmn coordinator idl
---------- ---------- --------------------------------------------------
208 4763 wait for a undo record
209 4442 wait for a undo record
211 15696 db file sequential read
214 134 SQL*Net message to client
215 6 rdbms ipc message
216 1065 rdbms ipc message
217 109 rdbms ipc mes
SID SEQ# EVENT
---------- ---------- --------------------------------------------------
222 280 rdbms ipc message
223 20 rdbms ipc message
224 68 rdbms ipc message
225 7 pmon timer

哪来的undo呢？

最后在google上根据ora_p001, wait for a undo record 的关键字，找到了一些信息，以下信息引起了我的注意：

Oracle工程师首先怀疑是临时表空间空间不足导致，经检查临时表空间没有空间不足的情况，仔细观察日志发现重做日志文件不断切换，分析应该是有较多的事务没有完成提交或者有较多没有提交的事务完成回滚。现在面临的问题是我们没有很多时间去等待所有的事务去完成回滚或提交。解决问题的思路就是如何尽快结束这些事务的回滚或提交。

根据文章提到的一个加快回滚的参数，fast_start_parallel_rollback 。试着修改一下。

sqlplus > shutdown immediate

sqlplus > startup

sqlplus > alter system set fast_start_parallel_rollback = FALSE scope=spfile

sqlplus > alter database open;

启动后，过了不久，发现IO,CPU恢复到正常水平。

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb 0.00 2.67 0.00 0.67 0.00 26.67 0.00 13.33 40.00 0.01 9.50 9.50 0.63
sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

重启应用，发现应用连接数据库的速度也达到了正常水平。

自此，调优结束。

载录一下相关信息：

　　1) 查看spfile文件中是否有fast_start_parallel_rollback参数的设置，检查结果G网数据库没有设置该参数。如果没有显式设置，则该参数的默认值为low。修改该参数值为false

　　2) 将数据库启动到nomount状态：startup nomount

　　3) 修改改参数值：alter system set fast_start_parallel_rollback = FALSE scope=spfile

　　4) shutdown immediate关闭数据库

　　5) startup启动

　　6) 查看该参数是否生效：show parameter fast_start_parallel_rollback

　　7) 等待一段时间

　　8) shutdown immediate数据库可以关闭

　　分析：FAST_START_PARALLEL_ROLLBACK是用来控制事务并行回滚最大进程数的参数。该参数有三个可设值，low，high，false。当设置为false时并行回滚被禁止，由于禁止了并行回滚，在数据库关闭时，需要回滚的事务将被取消。

并行实例恢复

　　如果 DML 操作是并行操作，则列 QCSID 显示并行查询服务器会话的 SID。在并行回滚事件中，如实例恢复以及随后的故障事务恢复期间，经常用到该信息经常。

　　例如，假设在大型的更新期间，实例异常关闭。当实例启动时，发生故障的事务被回滚。如果启用了用于并行恢复的初始化参数值，则回滚并行地而不是串行地发生，如同它发生在常规事务回滚中一样。下一步的任务是评估回滚进程的完成时间。

　　视图 V$FAST_START_TRANSACTIONS 显示为回滚故障事务所产生的事务。类似的视图 V$FAST_START_SERVERS 显示对回滚进行处理的并行查询服务器的数量。这两个视图都在以前的版本中提供，但显示事务标识符的新列 XID 使得联接更方便了。在 Oracle9i Database 以及更低的版本中，您必须通过三列(USN — 重做段号，SLT — 重做段中的存储区号，SEQ — 序列号)来联接视图。其父集显示在 PARENTUSN、PARENTSLT 和 PARENTSEQ 中。在 Oracle Database 10g 中，您只需将其联接到 XID 列，其父 XID 由直观的名称表示：PXID。

　　最有用的信息部分来自于 V$FAST_START_TRANSACTIONS 视图中的列 RCVSERVERS。如果发生并行回滚，则该列中显示并行查询服务器的数量。您可以查看该列，了解启动了多少并行查询进程：

select rcvservers from v$fast_start_transactions;

　　如果输出是 1，则事务正在由 SMON 进程进行串行回滚 — 显然这是完成工作的一种不充分的方法。您可以将初始化参数 RECOVERY_PARALLELISM 的值改为除 0 或 1 以外的值，重新启动实例进行并行回滚。随后您可以执行 ALTER SYSTEM SET FAST_START_PARALLEL_ROLLBACK = HIGH，按 CPU 数量的 4 倍创建并行服务器。

　　如果上述查询的输出显示不是 1，则正在进行并行回滚。您可以查询同一视图 (V$FAST_START_TRANSACTIONS) 来获得父事务和子事务(父事务 id — PXID，而子事务 id — XID)。XID 还可用于联接此视图与 V$FAST_START_SERVERS，以获得其他详细信息。

　　结论

　　总之，当在 Oracle Database 10g 中回滚长期运行的事务时 — 无论是并行实例恢复会话还是用户执行的回滚语句 — 您所需做的一切就是查看视图 V$SESSION_LONGOPS 并评估还需要多少时间。

[@more@]

现象：

1. 应用连接数据异常缓慢。

2，数据库主机cpu占用率居高不下， io 写入居高不下。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/20887841/viewspace-1029435/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/20887841/viewspace-1029435/