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

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

5

积分

1

好友

4

主题
1#
发表于 2013-1-8 19:15:14 | 查看: 7367| 回复: 6
本帖最后由 dexter 于 2013-1-9 14:49 编辑

今天碰到了一个奇怪的现象
三节点 AIX+CFS+OracleDatabase11.1.0.6 RAC

使用rman测试备份一个控制文件的时候
卡在这里一直没有反应
Starting backup at 08-JAN-13
using channel ORA_DISK_1

看v$session_wait视图
只有 db file sequential read 并且 wait_time=-1


不知道下一步应该怎样监控

2#
发表于 2013-1-8 19:19:27
run
{
debug on
YOUR SCRIPT;
debug off;}



or  


10046 trace your rman session


or

v$session_longops

回复 只看该作者 道具 举报

3#
发表于 2013-1-8 22:09:24
挺好,再复习一遍

回复 只看该作者 道具 举报

4#
发表于 2013-1-9 10:37:34
Maclean Liu(刘相兵 发表于 2013-1-8 19:19
run
{
debug on

第一个节点执行,使用debug方式:
  1. bash-3.00$ rman target / trace rman.trc debug

  2. Recovery Manager: Release 11.1.0.6.0 - Production on Tue Jan 8 19:50:12 2013

  3. Copyright (c) 1982, 2007, Oracle.  All rights reserved.

  4. RMAN-06005: connected to target database: LANDDB (DBID=3198567539)

  5. RMAN> run{
  6. 2> debug on
  7. 3> backup current controlfile format '/ysysdata/ctl_test.bkp' ;
  8. 4> debug off
  9. 5> }

  10. RMAN-03036: Debugging set to level=9, types=ALL

  11. RMAN-03090: Starting backup at 08-JAN-13
  12. RMAN-06009: using target database control file instead of recovery catalog
  13. RMAN-08030: allocated channel: ORA_DISK_1
  14. RMAN-08605: channel ORA_DISK_1: SID=283 instance=landdb1 device type=DISK
复制代码
第二个使用10046事件监控:
  1. bash-3.2$ rman target / trace rman46.trc debug

  2. Recovery Manager: Release 11.1.0.6.0 - Production on Tue Jan 8 20:13:41 2013

  3. Copyright (c) 1982, 2007, Oracle.  All rights reserved.

  4. RMAN-06005: connected to target database: LANDDB (DBID=3198567539)

  5. RMAN> run{
  6. 2> sql "alter session set events ''10046 trace name context forever , level 12 ''" ;
  7. 3> set command id to 'rman' ;
  8. 4> backup current controlfile format '/home/oracle/ctltest.bkp' ;
  9. 5> }

  10. RMAN-06009: using target database control file instead of recovery catalog
  11. RMAN-06162: sql statement: alter session set events ''10046 trace name context forever , level 12 ''

  12. RMAN-03023: executing command: SET COMMAND ID

  13. RMAN-03090: Starting backup at 08-JAN-13
  14. RMAN-08030: allocated channel: ORA_DISK_1
  15. RMAN-08605: channel ORA_DISK_1: SID=285 instance=landdb2 device type=DISK
复制代码
详细trace文件见附件
rman_trace.rar (39.48 KB, 下载次数: 2008)
请帮忙分析。

回复 只看该作者 道具 举报

5#
发表于 2013-1-9 14:51:39
请求帮助

回复 只看该作者 道具 举报

6#
发表于 2013-1-9 21:13:57
这个问题可能与你相关:

RMAN BACKUPS CAN TAKE A LONG TIME IN 11.1.0.6 [ID 605557.1]




                RMAN BACKUPS CAN TAKE A LONG TIME IN 11.1.0.6 [ID 605557.1]        To Bottom       
Modified:27-Dec-2011Type:PROBLEMStatus:PUBLISHEDPriority:3       
Comments (0)                               

In this Document
  Symptoms
  Cause
  Solution
  References

Applies to:

Oracle Server - Enterprise Edition - Version: 11.1.0.6 to 11.1.0.6 - Release: 11.1 to 11.1
Information in this document applies to any platform.
***Checked for relevance on 27-Dec-2011***
Symptoms

RMAN backups can take a long time in 11.1.0.6.

An increase in memory used by logminer may also be noticed. In once case, the ORA-4030 errors were reported, and lead to a database crash

This problem can affect all platforms. Additionally, 3 of the reports have been for customers with PeopleSoft installed.
Cause

This is caused by bug <<6412947>>.
Solution

To workaround the problem, switch off the logminer setup for DRA by setting:

  _dra_enable_offline_dictionary = FALSE


建议你升级到11.1.0.7

回复 只看该作者 道具 举报

7#
发表于 2013-1-10 16:35:12
Maclean Liu(刘相兵 发表于 2013-1-9 21:13
这个问题可能与你相关:

RMAN BACKUPS CAN TAKE A LONG TIME IN 11.1.0.6

正是这个问题,感谢maclean!

回复 只看该作者 道具 举报

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

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

GMT+8, 2024-11-16 06:43 , Processed in 0.052193 second(s), 23 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

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