如何利用RMAN Debug和10046 Trace来诊断RMAN问题?

　　学习转摘:https://blogs.oracle.com/Database4CN/entry/%E5%A6%82%E4%BD%95%E5%88%A9%E7%94%A8rman_debug%E5%92%8C10046_trace%E6%9D%A5%E8%AF%8A%E6%96%ADrman%E9%97%AE%E9%A2%98

　　介绍一下如何对RMAN的问题做debug。 我们借助于下面这个场景，说明如何Debug RMAN 问题。

　　在11.2.0.4上，物理备库上执行归档备份时，出现了下面的错误：

[[email protected] ~]$ rman target /

Recovery Manager: Release 11.2.0.4.0 - Production on Tue Mar 25 13:58:59 2014

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: R11204 (DBID=2001766638, not open)

RMAN> backup archivelog all;

Starting backup at 25-MAR-14
using target database control file instead of recovery catalog
RMAN-06820: WARNING: failed to archive current log at primary database<==============报错无法连接到主库
Connect identifier for DB_UNIQUE_NAME R11204 not configured
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1 device type=DISK
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=58 RECID=1 STAMP=842172838  <==============后面的归档备份还是成功的
input archived log thread=1 sequence=59 RECID=2 STAMP=842172838
input archived log thread=1 sequence=60 RECID=3 STAMP=842172928
input archived log thread=1 sequence=61 RECID=4 STAMP=842173275
input archived log thread=1 sequence=62 RECID=5 STAMP=842175748
input archived log thread=1 sequence=63 RECID=6 STAMP=842182033
input archived log thread=1 sequence=64 RECID=7 STAMP=842185463
input archived log thread=1 sequence=65 RECID=9 STAMP=842432288
input archived log thread=1 sequence=66 RECID=8 STAMP=842432286
input archived log thread=1 sequence=67 RECID=10 STAMP=842432291
input archived log thread=1 sequence=68 RECID=11 STAMP=842432322
channel ORA_DISK_1: starting piece 1 at 25-MAR-14
channel ORA_DISK_1: finished piece 1 at 25-MAR-14
piece handle=/u01/app/oracle/fast_recovery_area/SDY/backupset/2014_03_25/o1_mf_annnn_TAG20140325T135903_9m2hlj0p_.bkp tag=TAG20140325T135903 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 25-MAR-14

　　注：11.2.0.4有一个新的特性，就是备库上备份归档时，它会连接到主库上，让主库进行一次log switch，所以上面的错误是备库无法连接到主库进行log switch，上面最主要的错误是“Connect identifier for DB_UNIQUE_NAME R11204 not configured ”，看起来是备库要连接主库时需要用到的连接串没有配置正确。这时我们的疑问是这个连接串是在哪里设置的？

首先用一下Rman Debug：

[[email protected] ~]$ rman target / debug trace=/tmp/rman_debug
RMAN>  backup archivelog all;

RMAN-03090: Starting backup at 25-MAR-14
RMAN-06009: using target database control file instead of recovery catalog
RMAN-06820: WARNING: failed to archive current log at primary database
RMAN-06613: Connect identifier for DB_UNIQUE_NAME R11204 not configured
...

针对生成的/tmp/rman_debug，我们发现连接串用了为空“lprimary_db_cs = NULL”

DBGSQL:       TARGET> begin   :lprimary_db_cs :=     sys.dbms_backup_restore.get_connect_identifier       (dbuname=> :primary_dbunam
e); end;
DBGSQL:          sqlcode = 0
DBGSQL:           B :lprimary_db_cs = NULL《==========这是主库的连接串
DBGSQL:           B :primary_dbuname = R11204
  DBGRCVMAN: getConfig: configurations exists for this site
RMAN-06820: WARNING: failed to archive current log at primary database
DBGMISC:      ENTERED krmkursr [14:08:50.007]

　　也就是RMAN调用了一个内部的包 sys.dbms_backup_restore.get_connect_identifier来获得在备库连接主库时需要用到的串。这时我们需要知道这个串是在哪里设置的，为何为空。

接下来，针对RMAN进行10046 trace：

[[email protected] ~]$ rman target / debug trace=/tmp/rman_debug
Recovery Manager: Release 11.2.0.4.0 - Production on Mon Mar 17 09:00:00 2014
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
RMAN-06568: connected to target database: R11204 (DBID=2001766638, not open)
RMAN> sql "alter session set tracefile_identifier=‘‘rman_10046‘‘";
RMAN-06009: using target database control file instead of recovery catalog
RMAN-06162: sql statement: alter session set tracefile_identifier=‘‘rman_10046‘‘
RMAN> sql "alter session set events ‘‘10046 trace name context forever,level 12‘‘";
RMAN-06162: sql statement: alter session set events ‘‘10046 trace name context forever,level 12‘‘
RMAN> backup archivelog all;
RMAN-03090: Starting backup at 25-MAR-14
RMAN-06820: WARNING: failed to archive current log at primary database
RMAN-06613: Connect identifier for DB_UNIQUE_NAME R11204 not configured
...

查看生成的trace file，这个文件在udump下：
$cd /u01/app/diag/rdbms/sdy/SDY/trace
$ls -ltr
-rw-r----- 1 oracle oinstall 1037463 Mar 25 14:11 SDY_ora_3792_rman_10046.trc

PARSING IN CURSOR #140366085001120 len=119 dep=0 uid=0 oct=47 lid=0 tim=1395736859520777 hv=3388798669 ad=‘7ec65738‘ sqlid=‘7pwt2c34
ztxqd‘
begin   :lprimary_db_cs :=     sys.dbms_backup_restore.get_connect_identifier       (dbuname=> :primary_dbuname); end;
END OF STMT
PARSE #140366085001120:c=0,e=285,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=0,tim=1395736859520776
BINDS #140366085001120:
 Bind#0
  oacdty=01 mxl=2000(1536) mxlc=00 mal=00 scl=00 pre=00
  oacflg=01 fl2=1000000 frm=01 csi=873 siz=2128 off=0
  kxsbbbfp=7fa986a27f08  bln=2000  avl=00  flg=05
 Bind#1
  oacdty=01 mxl=128(90) mxlc=00 mal=00 scl=00 pre=00
  oacflg=01 fl2=1000000 frm=01 csi=873 siz=0 off=2000
  kxsbbbfp=7fa986a286d8  bln=128  avl=06  flg=01
  value="R11204"
*** ACTION NAME0000018 STARTED189) 2014-03-25 14:10:59.521

WAIT #140366085001120: nam=‘control file sequential read‘ ela= 10 file#=0 block#=1 blocks=1 obj#=-1 tim=1395736859521532
WAIT #140366085001120: nam=‘control file sequential read‘ ela= 4 file#=0 block#=16 blocks=1 obj#=-1 tim=1395736859521566
WAIT #140366085001120: nam=‘control file sequential read‘ ela= 4 file#=0 block#=18 blocks=1 obj#=-1 tim=1395736859521580
WAIT #140366085001120: nam=‘control file sequential read‘ ela= 4 file#=0 block#=281 blocks=1 obj#=-1 tim=1395736859521594
WAIT #140366085001120: nam=‘control file sequential read‘ ela= 4 file#=0 block#=1 blocks=1 obj#=-1 tim=1395736859521614
WAIT #140366085001120: nam=‘control file sequential read‘ ela= 3 file#=0 block#=16 blocks=1 obj#=-1 tim=1395736859521627
WAIT #140366085001120: nam=‘control file sequential read‘ ela= 2 file#=0 block#=18 blocks=1 obj#=-1 tim=1395736859521638
WAIT #140366085001120: nam=‘control file sequential read‘ ela= 3 file#=0 block#=281 blocks=1 obj#=-1 tim=1395736859521650
krsd_get_primary_connect_string: found pcs ‘‘ by FAL_SERVER lookup <====================用FAL_SERVER找到了连接串‘‘

　　所以这个10046 trace，很清楚地告诉我们它是从参数FAL_SERVER上获得了连接串‘‘。

这时，连接到备库，查看参数FAL_SERVER，它的值的确为空：
SQL> show parameter fal

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
fal_client                           string
fal_server                           string

　　到此，我们通过RMAN debug和10046 trace，获得了我们想要的信息。

总结一下：
　　如果在执行RMAN命令后，遇到了性能问题或者需要深入跟踪一个错误，那么可以考虑使用rman debug：

$ rman target <connection> catalog <connection> debug trace=/tmp/rmanDebug.trc log=/tmp/rmanLog.txt
run {
...Run your backup commands here
}

如果还需要跟进一步的跟踪可以再使用10046 trace：

$ rman target <connection> catalog <connection> debug trace=/tmp/rmanDebug.trc log=/tmp/rmanLog.txt
RMAN> sql "alter session set tracefile_identifier=‘‘rman_10046‘‘";
RMAN> sql "alter session set events ‘‘10046 trace name context forever,level 12‘‘";
RMAN> run-your-commands;
RMAN> exit;

需要注意的是，上面的这些方法可能会生成大量文件，需要考虑对磁盘空间的压力以及对RMAN的性能的影响。

时间： 2024-10-01 05:49:07

如何利用RMAN Debug和10046 Trace来诊断RMAN问题?的相关文章

debug类和trace类的区别

在 .net 类库中有一个 system.diagnostics 命名空间,该命名空间提供了一些与系统进程.事件日志.和性能计数器进行交互的类库.当中包括了两个对开发人员而言十分有用的类——debug类和trace类.本文介绍了这两个类的一些基本用途,旨在提高广大开发人员的开发效率. 使用debug类来帮助调试 调试程序对每个程序员来说是家常便饭.可是我们会经常遇到一些情况让我们头疼,例如: 当我们在开发一个界面控件的时候,简单的设断点会增加paint事件的响应次数,而造成的环境参数改变. 断点

10046 trace详解(1)

10046 trace帮助我们解析一条/多条SQL.PL/SQL语句的运行状态,这些状态包括:Parse/Fetch/Execute三个阶段中遇到的等待事件.消耗的物理和逻辑读.CPU时间.执行计划等,它为我们揭示了一条.多条SQL的运行情况,对SQL调优是一个非常好的辅助工具,同时还能帮我们分析一些DDL维护命令的内部工作原理,RMAN.Data Pump Expdp/impdp等工具缓慢问题. 记得进公司面试时提到这个一样问题,查看SQL执行计划有哪此方法,10046.PL/SQL F5快捷

10046 trace文件分析

SQL> create table t10046 as select * from dba_objects; Table created. SQL> select file_id,block_id,blocks from dba_extents where segment_name='T10046'; FILE_ID BLOCK_ID BLOCKS ---------- ---------- ---------- 1 94664 8 1 94672 8 1 94680 8 1 94688 8

android debug：stack trace

使用 ps 命令查看 目标进程的 pid,比如说是 1200,然后 kill -3 1200 在 /data/anr/traces.txt 中就能找到 进程 1200 中各线程的 stack trace android debug:stack trace,布布扣,bubuko.com

Oracle 10046 trace文件分析

生成10046 trace文件: SQL> create table t10046 as select * from dba_objects; Table created. SQL> select file_id,block_id,blocks from dba_extents where segment_name='T10046'; FILE_ID BLOCK_ID BLOCKS ---------- ---------- ---------- 1 94664 8 1 94672 8 1 9

[Oracle]如何查看 10046 trace 中的 tim= ... 的具体时刻

可以在  Linux 下,用下列方式: 如10046 trace 文件中如果有如下的内容:... tim = 1503032923 可以用 date 命令加 option 来看它的时刻: date -u -d '@1503032923' 显示为: 2017年  8月 18日 星期五 05:08:43 UTC

如何启动JDBC Debug模式，打印JDBC诊断日志

1.下载Debug版本jar包 首先要下载一个Debug版本的JDBC jar包,Debug版本的jar包命名形式为jdbcX_g.jar(如下图所示),如Oracle11g的Debug版本的jar包为jdbc6_g.jar.点击这里下载:http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-112010-090769.html 2.启动Logging模式 第一种方式:设置运行环境变量java -Doracle.jd

转 RMAN: RAC Backup, Restore and Recovery using RMAN

PURPOSE The purpose of this document is to give a quick guide for using RMAN on RAC databases. We will follow this points: 1. Verify the database mode and archive destination.2. Verify connectivity using sqlnet for target and catalog.3. Determine the

转 怎样解读10046 trace (tkprof 的结果 )

TKProf Structure TKProf output for an individual cursor has the following structure: SELECT NULL FROM DUAL call     count       cpu    elapsed       disk      query    current        rows------- ------  -------- ---------- ---------- ---------- -----