Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

157

积分

0

好友

14

主题
1#
发表于 2012-8-9 11:07:49 | 查看: 6736| 回复: 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, 下载次数: 1110)

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

[ 本帖最后由 clevernby 于 2012-8-9 13:13 编辑 ]
2#
发表于 2012-8-9 13:30:31
当时smon进程的trace 还能找到吗?

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

回复 只看该作者 道具 举报

3#
发表于 2012-8-9 13:46:07
可以,稍后奉上

回复 只看该作者 道具 举报

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, 下载次数: 1090)

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

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

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

回复 只看该作者 道具 举报

5#
发表于 2012-8-9 14:47:35
就这个场景看 , 只能认为是smon并行大发神威了

回复 只看该作者 道具 举报

6#
发表于 2012-8-9 15:33:09
关于这个update语句的调优也请大家出出主意~
传送门
http://t.askmaclean.com/thread-1579-1-1.html

回复 只看该作者 道具 举报

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-12-25 01:37 , Processed in 0.054292 second(s), 24 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569