157 积分	0 好友	14 主题

发消息

服务器进程rollback和smon rollback在实现上有多大区别？

1^#

发表于 2012-8-9 11:07:49 | 查看: 6658| 回复: 5

数据库版本 11.2.0.2.0 Linux x86-64
GI版本 11.2.0.2.0 Linux x86-64
OS版本 RHEL 5.5
这是一个2节点集群数据库
数据库启用归档日志、force logging、主键级别补充日志、fast_start_parallel_rollback=low
硬件配置：Dell R710 (Xeon E5620 2.4G 4核超线程 * 2颗) + 140G内存 + ps6000

2012-8-8 18:24在实例1执行如下update语句
update table1 set col2=col1
其中Col1和Col2均为CHAR(8)
table1表共有4亿记录，大小约100G。该语句执行约2个半小时仍未结束，于20:50 kill了会话(alter system kill session)。
2012-8-9早上8:00发现会话回滚仍未结束，于是kill os 进程(kill -9 nnn)，smon开始恢复死事务，5分钟不到便完成了。
顺便补充一下，kill os进程前，实例1和2均无法在x$ktuxe中查询到死事务，但在kill之后实例1和2都可以在x$ktuxe中查询到死事务，ktuxesiz分别为14万和14万。

回滚块中数据部分我觉得可以错略计算得到，4亿*8/8192=390625个undo block，经过11小时的rollback居然还有28万多个块没有恢复掉？而剩下的28万个块却只需5分钟就回滚完了？什么原因导致了如此大的差距呢？

附件为执行update语句会话的dba_active_sess_history结果

ash.rar (186.63 KB, 下载次数: 1065)

在附件中可以看到服务器进程回滚时遭遇大量db file sequential read事件，涉及的数据块均为undo block

[ 本帖最后由 clevernby 于 2012-8-9 13:13 编辑 ]

分享0

收藏0 回复只看该作者道具举报

Maclean Liu(刘相兵

2^#

发表于 2012-8-9 13:30:31

当时smon进程的trace 还能找到吗？

x$ktuxe视图的信息不能保证 smon真的需要recover 那么多undo

回复只看该作者道具举报

clevernby

3^#

发表于 2012-8-9 13:46:07

可以，稍后奉上

回复只看该作者道具举报

clevernby

4^#

发表于 2012-8-9 14:40:07

执行update的实例的smon trace文件已经到达dump_max_size 20M了，其中的内容无价值，可惜了。

附件提供了事发时段2个实例的alert日志和实例2的smon trace

alert log and smon trace.rar (23.72 KB, 下载次数: 1044)

其中分析实例1的alert日志发现

Wed Aug 08 18:25:01 2012
Thread 1 advanced to log sequence 9641 (LGWR switch)
Current log# 1 seq# 9641 mem# 0: +DATA/h2db/redo01.log
.......
Wed Aug 08 20:51:15 2012
Thread 1 advanced to log sequence 9875 (LGWR switch)
Current log# 5 seq# 9875 mem# 0: +DATA/h2db/redo05.log
......
Thu Aug 09 08:08:11 2012
Thread 1 advanced to log sequence 10081 (LGWR switch)
Current log# 1 seq# 10081 mem# 0: +DATA/h2db/redo01.log
Thu Aug 09 08:08:12 2012
LNS: Standby redo logfile selected for thread 1 sequence 10081 for destination LOG_ARCHIVE_DEST_2
Thu Aug 09 08:08:25 2012
Archived Log entry 49439 added for thread 1 sequence 10080 ID 0x5fde9d30 dest 1:
Thu Aug 09 08:08:26 2012
ARC0: Standby redo logfile selected for thread 1 sequence 10080 for destination LOG_ARCHIVE_DEST_3
Thu Aug 09 08:08:36 2012
SMON: Parallel transaction recovery tried
Thu Aug 09 08:09:47 2012
LNS: Standby redo logfile selected for thread 1 sequence 10081 for destination LOG_ARCHIVE_DEST_3
Thu Aug 09 09:22:08 2012
ALTER SYSTEM SET service_names='h2db','SYS$SYS.KUPC$C_1_20120809092207.H2DB' SCOPE=MEMORY SID='h2db1';
ALTER SYSTEM SET service_names='SYS$SYS.KUPC$C_1_20120809092207.H2DB','h2db','SYS$SYS.KUPC$S_1_20120809092207.H2DB' SCOPE=MEMORY SID='h2db1';
Thu Aug 09 09:22:09 2012
DM00 started with pid=99, OS id=27750, job SYSTEM.SYS_EXPORT_SCHEMA_01
Thu Aug 09 09:22:12 2012
DW00 started with pid=100, OS id=27753, wid=1, job SYSTEM.SYS_EXPORT_SCHEMA_01
Thu Aug 09 09:22:34 2012
ALTER SYSTEM SET service_names='SYS$SYS.KUPC$S_1_20120809092207.H2DB','h2db' SCOPE=MEMORY SID='h2db1';
ALTER SYSTEM SET service_names='h2db' SCOPE=MEMORY SID='h2db1';

复制代码

在该数据库中每个日志文件有500M，那么
9641 ~ 9875 （约2个半小时）有114G
9876 ~ 10081 （近11个小时）有100G
10082日志文件直到09:22也还未切换

回复只看该作者道具举报

Maclean Liu(刘相兵

5^#

发表于 2012-8-9 14:47:35

就这个场景看，只能认为是smon并行大发神威了

回复只看该作者道具举报

clevernby

6^#

发表于 2012-8-9 15:33:09

关于这个update语句的调优也请大家出出主意~
传送门
http://t.askmaclean.com/thread-1579-1-1.html

回复只看该作者道具举报

返回列表

		自动登录	找回密码
密码			注册