星期二 三月 25, 2014

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

     在做Support的这些年,我很大的收获是掌握了许多troubleshooting问题的方法和工具,对于每一类问题,都可以大体归类出一些诊断方法。无论问题多么复杂,像扒洋葱一样,一层层去掉无关的,留下关键的,同时借助于一些诊断工具,层层深入,最后找到问题的核心。

     在这篇文章中,我想介绍一下如何对RMAN的问题做debug。 我们借助于下面这个场景,说明如何Debug RMAN 问题


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

[oracle@test1 ~]$ 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:

[oracle@test1 ~]$ 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:

[oracle@test1 ~]$ 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 NAME:(0000018 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的性能的影响。


可以参考MOS文档:RMAN: Quick Debugging Guide (Doc ID 1198753.1)

星期五 八月 17, 2012

Oracle数据库支持通讯2012年8月版: Recovery Manager (RMAN) 提示, 窍门和误区



作为一名有经验的DBA,您可能对RMAN非常熟悉而且为您的数据库创建了RMAN脚本,并且运行了很多年。即便如此,或许您对以下的RMAN提示和窍门感兴趣,让您的DBA工作更加简单而且还能避免一些常见的误区。请继续阅读,获得更多关于RMAN ’Duplicate’命令,恢复,备份和坏块的提示和误区。


'Duplicate' 命令的误区


RMAN 11.2 Duplicate – 控制文件是还原的,而不是重新创建的
Oracle
数据库版本11.2, RMAN‘Duplicate’命令会还原备份的控制文件到目标主机而不是创建新的控制文件。所以,一定要确保有一个满足duplicate时间的控制文件备份存在。否则会遇到下面的错误。


RMAN-03002: failure of Duplicate Db command at 07/23/2012 10:09:08


RMAN-05501: aborting duplication of target database


RMAN-03015: error occurred in stored script Memory Script


RMAN-06026: some targets not found - aborting restore


RMAN-06024: no backup or copy of the control file found to restore


下面是一个简单的测试例子,可以在运行’Duplicate’命令之前验证是否存在有效的控制文件备份。


RMAN> run {


set until time "to_date('2012 MAY 18 07:37','YYYY MON DD HH24:MI')";


restore controlfile preview;


}


注意: 请修改 'SET UNTIL TIME' 中的时间来满足具体的要求。


RMAN 11.2 活动Duplicate 误区


活动Duplicate将已装载的或者在线的数据文件通过网络拷贝到目标实例。所以,并不需要对Duplicate作准备,不过,这意味着在进行活动Duplicate的时候会对源主机和网络产生一定的工作负载。


但是,我们可以使用RMAN’Rate’参数来对数据的流量进行限制。请注意如果使用活动Duplicate的话,需要安装补丁Patch 13483981 Throttle Network Consumption during Active Duplicate来启用RMAN‘Rate’参数。要了解更多的信息,请参考文档1436783.1 How to Throttle Network Consumption During Rman Active Duplicate


另外,目标数据库和源数据库都必须通过静态注册的方式注册到Oracle监听程序,而不能动态注册数据库服务。因此,配置一个能够连接到数据库的客户端并将数据库的服务信息添加到监听程序。目标实例和源实例需要相同的sys用户口令,所以,在进行duplicate之前,需要将源数据库的口令文件拷贝到目标主机。


数据块改变跟踪 (BCT) 文件


已经发现了一些数据库启用了BTCduplicate数据库时出现的问题。文档1098638.1 'ORA-19755 Using RMAN Duplicate, Tries Open The Block Change Tracking File of Source DB'列出了常见的问题。


大多数的绕开问题的方法是,确保在进行duplicate之前,由源数据库控制文件标识的BTC文件,事先存在于目标主机。您可以在指定的位置创建一个空的文件。由于BCT文件的位置保存在控制文件中,在执行基于时间点的duplicate时需要留意该文件的位置。如果源数据库的BCT文件位置或名称发生了改变,您可能会遇到错误。当BCT文件或者和它相当的空文件在目标主机上存在,能够被访问,并且符合控制文件备份中的信息,duplicate就会成功。


备份误区


默认数据库初始化参数


首先,我们强烈建议使用RMAN catalog来管理备份,请参考文档1362501.1 Demystifying the RMAN Recovery Catalog 获得更多信息。


如果您不准备使用RMAN catalog,就一定要注意数据库初始化参数'controlfile_record_keep_time'的默认值为7天,也就是说控制文件中超过这个保留期限的RMAN信息可能会被交换出去,所以需要根据您的备份策略修改这个参数的设置。请参考文档397269.1 Relation between RMAN retention period and control_file_record_keep_time 获得更多的信息。


对于BCT,默认oracle保证追踪8个级别为1的增量备份。如果您做了多于8个级别为1的增量备份,您必须调整数据库的隐含参数 _bct_bitmaps_per_file来满足您的要求并且重新启动数据库。


离线和丢失的数据文件


请注意,RMAN会备份离线的数据文件,而且在备份的过程中不会报错, RMAN只会对丢失的或者无法访问的文件报错,就像下面显示的内容:
channel ORA_DISK_1: starting piece 1 at 02 AUG 2012 12:31:13


RMAN-00571: ==========================================================


RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============


RMAN-00571: ==========================================================


RMAN-03009: failure of backup command on ORA_DISK_1 channel at 08/02/2012 12:31:14


ORA-01116: error in opening database file 9


ORA-01110: data file 9: '/opt/app/oracle/oradata/ORA112/datafile/o1_mf_lb_ts_81mpb4x8_.dbf'


ORA-27041: unable to open file


Linux-x86_64 Error: 2: No such file or directory


Additional information: 3


如果一个数据文件已经被离线了一段时间,在恢复的过程中oracle会查看从数据文件被离线的时间点开始的所有归档日志文件,才能把数据文件恢复到最新的状态。为了避免这样的惊喜,您或许需要编写额外的脚本来查看离线的数据文件信息:


select * from v$recover_file order by 1;
select distinct(status)from v$datafile;
select FILE#,TS# , status, NAME from v$datafile
where status not in ('SYSTEM','ONLINE')
order by 1;



在正常的情况下,您的数据库中不应该包含离线的,无法访问的或者需要恢复的数据文件,这些文件应该被还原并上线。只有当数据库的某些数据文件出现问题时,才应该考虑使用像'SKIP INACESSIBLE' 'SET MAXCORRUPT'这样的选项作为临时的办法。


最佳实践


作为一个生产数据库,备份是必要的,除非您能够通过其他的方式重建数据库。无论数据库的容量有多大,都需要为数据库备份分配存储或磁带空间。使用下面的RMAN命令可以列出需要备份的文件:


RMAN> report need backup;


另外,如果您需要将数据库通过备份前滚到一个特定的时间点,您需要启动归档模式,并且备份前滚所需要的归档日志文件。


备份的频率会决定还原和恢复所需的时间。例如,如果您只是每个星期进行备份,那么您不得不前滚一个星期的归档日志文件!


RMAN提供了很多辅助您制定备份策略的特性,例如增量备份合并,BCT和增量备份


Restore 陷阱


还原 oracle管理的数据文件 (OMF datafiles)


当使用OMF并且数据文件在磁盘上不存在的时候,restore操作会将数据文件还原到初始化参数'db_create_file_dest'所指定的位置,并且按照OMF的规范命名。这意味着您需要保证参数'db_create_file_dest'所指向的文件系统有足够的空闲空间存放所有的数据文件。(提示:使用视图V$DATAFILE确认数据文件尺寸)。


否则,如果需要将数据文件还原到原来的位置,您需要在进行还原时关闭OMF特性。


SQL> alter system set db_create_file_dest='';
SQL> show parameter create_file


NAME                     TYPE     VALUE
------------------------ ----------- ------------------------------
db_create_file_dest      string


表空间中的离线数据文件
如果一个数据文件需要还原,只离线这个数据文件,不要离线它所在的表空间,因为,如果表空间中的一个数据文件不能被恢复并上线,表空间就不能够上线,而且您会收到以下的错误:


RMAN> sql 'alter tablespace users online';


sql statement: alter tablespace users online
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of sql command on default channel at 08/02/2012 11:04:54
RMAN-11003: failure during parse/execution of SQL statement: alter tablespace users online
ORA-01113: file 4 needs media recovery
ORA-01110: data file 4: '/opt/app/oracle/oradata/ORA112/datafile/o1_mf_users_81mm41rn_.dbf'


丢失一个数据文件的数据或许没有丢失整个表空间的数据严重。


手动克隆


如果您需要将数据库恢复到一个新的主机作容灾或克隆,那么在整个过程的最后一步就是使用NID工具至少将数据库的ID更改。


不要使用RMAN catalog进行这种手动克隆操作。但是,如果您一定要这么做,将RMAN catalog导出,使用导出文件进行克隆。更多详细信息,请参考文档 1338193.1 How to Move/Restore DB to New Host and File System using RMAN


RMAN 和坏块


坏块可能只有当进程访问到它的时候才会被发现。即使一个成功的RMAN备份也不能保证一定不包含坏块,因为RMAN只检查物理坏块,否则,备份过程会很长并对系统产生非常大的性能影响。



默认情况下,RMAN不会检查逻辑坏块,所以,建议您定期运行RMAN命令'backup validate'以确保您能够建立一个已知的没有坏块的备份状态。由于这个命令是I/O密集操作,建议您不要在数据库忙碌时间运行。


即使您不使用RMAN对数据库进行备份,仍然可以使用它验证坏块。如果数据库处于非归档模式,那么需要将数据库启动到‘MOUNTED’状态。


$ rman target /


RMAN> backup validate check logical database;


RMAN验证过坏块后,请运行下面的查询语句确认坏块列表。


SQL> select * from v$database_block_corruption;


如果以上的查询显示多个坏块信息,请参考文档472231.1:How to Find All the Corrupted Objects in Your Database获得更多信息


如果您使用RMAN备份数据库,可以使用RMAN块恢复特性对物理坏块进行恢复。注意,RMAN不能对逻辑坏块进行恢复。


RMAN> blockrecover corruption list;


或者从Oracle 11.2开始,使用下面的命令:


RMAN> recover corruption list;


在数据库级别,请考虑打开参数'db_block_checking'' db_block_checksum',在数据被写入磁盘前,验证数据块的一致性。请参考文档 32969.1 TECH: Database Block Checking Features获取详细信息。


容灾(DR)


RMAN提供了很多命令预览和验证备份文件,例如:


RMAN> restore database preview;
RMAN> restore database validate;


但是,无论您如何预览和验证备份文件,都不如通过定期将备份文件还原到容灾站点的方法验证您的容灾策略。将数据库备份到次要的存储(例如灾备站点)或磁带以分担存储压力,避免磁盘损坏对备份产生影响也是个好主意。


更多信息


请参考以下的文档获得更多的信息:




星期二 一月 17, 2012

热备份(hot backup)和RMAN备份共存的系统问题




[Read More]
About

本博客由Oracle全球技术支持中国区的工程师维护。为中文用户提供数据库相关的技术支持信息,包括常用的诊断工具、诊断方法、产品新特性、案例分析等。此外,MOS也陆续推出各类中文内容:技术通讯统一发布在Note 1529795.1 中,中文文档列表更新在Note 1533057.1 中,网上讲座请查看MOS文档 1456176.1,在"Archived"中可以下载历史的录音和文档。

Search

Archives
« 四月 2014
星期日星期一星期二星期三星期四星期五星期六
  
1
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
今天