系统环境
硬件：ＰＣ Server
操作系统：windows
数据库版本：oracle10GR2 （single database）
１月23号早上11点做了一个10G大表的imp操作，由于数据量的增大加上imp导入所造成的lock等待，程序速度变慢，开发那边要求中断导入操作。在导入进行了近４个小时后，也就是说下午１５点，imp被强行中断。查看数据文件，增长了６个Ｇ，也就是说有６０％的数据已经导入。
imp语句如下
imp xxx/xxx file=G:\shanxie\mobile.dmp log=G:\shanxie\mobile_old.log ignore=y buffer=8192000 feedback=10000
这里，mobil.dmp的大小有６个Ｇ。由于我的失误在imp的时候没有加上commit=y，导致所有数据均没有被提交，也就是说有６Ｇ的数据全部需要被回滚。
原以为回滚很快就会结束，但是过了４个小时，到了下午１７点，数据库的速度还是很慢，查看会话的等待，发现有4个并发进程同时在等待db file sequential read事件。
SQL> select sid,event from v$session_wait where;
SID EVENT
---------- ----------------------------------------------------------------
538 db file sequential read
539 db file sequential read
540 db file sequential read
541 db file sequential read
这四个进程分别是P000,P001,P002,P003
一段时间后，这四个进程还会有一些回滚段的等待，于是怀疑imp的失败回滚还没有完成。
接下来查看回滚的统计信息
SQL> select * from v$rollstat where xacts >0;
USNLATCHEXTENTS RSSIZE WRITESXACTS GETSWAITSOPTSIZEHWMSIZESHRINKS
---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
WRAPSEXTENDSAVESHRINKAVEACTIVE STATUS
CUREXT CURBLK
---------- ---------- ---------- ---------- --------------- ---------- ----------
3
3 3571 2066300928
0 111236
0
2066300928
0
0
0
0
0 ONLINE
3569159
xacts：回滚段中活动的事务。
gets：从回滚段从中读多少次undo header
SQL> select *from undo$ where us#=3;
US# NAME
USER#FILE# BLOCK# SCNBAS SCNWRPXACTSQNUNDOSQN
---------- ------------------------------ ---------- ---------- ---------- ---------- ---------- ---------- ----------
INST#STATUS$TS#UGRP# KEEPOPTIMALFLAGS SPARE1 SPARE2 SPARE3
---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
SPARE4
------------------------------------------------------------------------------------------------------------------------
SPARE5
------------------------------------------------------------------------------------------------------------------------
SPARE6
-------------------
3 _SYSSMU3$
1
2 41109777882
09758110677
0
3
1
1
发现回滚段3在做回滚的操作，gets在不断的增长，因为oracle重新启动过，gets数据清０，原以为gets增长到了undo的大小就会停止，也就是25万。因为不想做不完全恢复，所以只能让数据库继续回滚。
第二天早上回来查看情况，发现
SQL> select * from v$rollstat where xacts >0;
USNLATCHEXTENTS RSSIZE WRITESXACTS GETS
---------- ---------- ---------- ---------- ---------- ---------- ----------
WAITSOPTSIZEHWMSIZESHRINKSWRAPSEXTENDSAVESHRINK
---------- ---------- ---------- ---------- ---------- ---------- ----------
AVEACTIVE STATUS
CUREXT CURBLK
---------- --------------- ---------- ----------
3
3 3571 2066300928
0
1 608595
126
2066300928
0
0
0
0
0 ONLINE
3569159
gets已经增长到了６６万，但恢复还是没有停止，这样就是说gets的次数会大于回滚段的block数。
查看bdump中的alert.log没有报任何错误，smon报了如下错误
*** 2007-01-23 15:35:27.437
Process P004 is dead (pid=5632, state=3):
kxfpg1srv
could not start local P004
*** 2007-01-23 16:59:20.777
Parallel Transaction recovery caught exception 30311
Parallel Transaction recovery caught error 30311
*** 2007-01-24 09:21:06.334
*** SERVICE NAME
SYS$BACKGROUND) 2007-01-24 09:21:06.318
*** SESSION ID
549.1) 2007-01-24 09:21:06.318
*** 2007-01-24 09:21:06.334
SMON: parallel recovery restart with degree=16 (!=8)
Parallel Transaction recovery caught exception 30312
*** 2007-01-24 09:21:18.553
Parallel Transaction recovery caught error 30312
*** 2007-01-24 09:21:18.553
SMON: Restarting fast_start parallel rollback
*** 2007-01-24 11:16:17.697
Parallel Transaction recovery caught exception 12801
Parallel Transaction recovery caught error 370
*** 2007-01-24 11:16:20.885
SMON: Restarting fast_start parallel rollback
Dead transaction 0x0003.028.00017d2a recovered by 1 server(s)
发现smon居然在不断的重启动并发进程。
接下来，我查看了导致并发的fast_start_parallel_rollback
SQL> show parameter fast_start_parallel_rollback
fast_start_parallel_rollback stringHIGH
fast_start_parallel_rollback 指在做回滚时的并发数量，属于事务型的恢复。它由smon进程检测系统状态，并调用和协调并发进程来进行回滚的恢复操作。
fast_start_parallel_rollback的参数设置和内容
FALSE indicates that parallel rollback is disabled
LOW limits the number of rollback processes to 2 * CPU_COUNT
HIGH limits the number of rollback processes to 4 * CPU_COUNT
昨天晚上我们曾经把fast_start_parallel_rollback 从默认值LOW，改成HIGH
并发进程从４个，变成了１６个。
我曾经把这个参数与recovery_parallelism混淆，这里也说明一两者的区别
recovery_parallelism 指定在做实例恢复的时候的并发数量，对介质恢复无效。如果要做并行的介质恢复，需要在recover database语句中指定parallel参数
到了中午11点16分，不知道是不是smon发现了不妙，它取消了P001到P015。只剩下P000继续进行恢复的操作。这个也可以从smon的trace中体现
*** 2007-01-24 11:16:20.885
SMON: Restarting fast_start parallel rollback
Dead transaction 0x0003.028.00017d2a recovered by 1 server(s)
11点半查看视图V$FAST_START_TRANSACTIONS，发现恢复的速度快多了。
SQL> select usn,undoblockdone,undoblockstotal,cputime from V$FAST_START_TRANSACTIONS;
USNUNDOBLOCKSDONEUNDOBLOCKSTOTALCPUTIME
---------- -----------------------------------------------------------------------------------
3
1036
203328
8208
SQL> select * from V$FAST_START_SERVERS;
STATE UNDOBLOCKSDONEPID XID
----------- -------------- ---------- ----------------
RECOVERING
1036 16 030028002A7D0100
UNDOBLOCKSDONE表示已经恢复的回滚段块
UNDOBLOCKSTOTAL表示需要恢复的回滚段块总量
可以看出，回滚段３在参与恢复的操作，203328中有150014块已经恢复，cpu占用了8208秒。而前面我们可以看到usn３的回滚段块是252234，而从v$rollstat中可以看到回缩次数为0,所以我判断从昨天下15点到今天早上１１点这20个小时已经恢复了５万个undo blocks。
直到14点00分，系统恢复完成。
这里，20万个undo block的恢复，只使用一个并发进程用了不到３个小时就完成了。使我不得不怀疑之前将近２０个小时，１６个并发进程的工作能力，感觉oracle10Ｇ的并行恢复机制并不成熟，这样，fast_start_parallel_rollback最好还是设置为false，以取消这种并行恢复的机制。 |
