oracle RMAN备份FORMAT格式中%a的含义

今天三思问我一个问题：RMAN备份FORMAT格式中%a的含义。

其实Oracle的文档有这个表述：

%a

Specifies the activation ID of the database.

不过这个描述很不明确。其实junsansi的意思是，这个%a对应的信息在数据库中的哪里体现出来。

下面先看看备份信息里面的这个值：

[oracle@yans1 ~]$ rman target /

Recovery Manager: Release10.2.0.3.0 - Production on星期四7月16 14:18:14 2009

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

connected to target database: TEST08 (DBID=3812548755)

RMAN> backup tablespace users format '/data/backup/test08_%a';

Starting backup at 16-7月-09

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=100 devtype=DISK

channel ORA_DISK_1: starting full datafile backupset

channel ORA_DISK_1: specifying datafile(s) in backupset

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

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

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

RMAN-03009: failure of backup command on ORA_DISK_1 channel at 07/16/2009 14:18:38

ORA-19602: cannot backup or copy active file in NOARCHIVELOG mode

RMAN> sql 'alter tablespace users read only';

sql statement: alter tablespace users read only

RMAN> backup tablespace users format '/data/backup/test08_%a';

Starting backup at 16-7月-09

using channel ORA_DISK_1

channel ORA_DISK_1: starting full datafile backupset

channel ORA_DISK_1: specifying datafile(s) in backupset

input datafile fno=00004 name=/data/oradata/test08/users01.dbf

channel ORA_DISK_1: starting piece 1 at 16-7月-09

channel ORA_DISK_1: finished piece 1 at 16-7月-09

piece handle=/data/backup/test08_657125523 tag=TAG20090716T141924 comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01

Finished backup at 16-7月-09

RMAN> exit

Recovery Manager complete.

可以看到，对应的activation的ID是657125523。

而且根据文档的描述，这个属性是数据库的，但是在V$DATABASE视图中找不到这个对应的值。

SQL> SELECT VIEW_DEFINITION FROM V$FIXED_VIEW_DEFINITION

 2  WHERE VIEW_NAME = 'GV$DATABASE';

VIEW_DEFINITION

--------------------------------------------------------------------------------------------

select di.inst_id,di.didbi,di.didbn,to_date(di.dicts,'MM/DD/RR HH24:MI:SS','NLS_CALENDAR=Gregorian'),to_number(di.dirls)

,to_date(di.dirlc,'MM/DD/RR HH24:MI:SS','NLS_CALENDAR=Gregorian'),to_number(di.diprs),to_date(di.diprc,'MM/DD/RR HH24:MI

:SS','NLS_CALENDAR=Gregorian'),decode(di.dimla,0,'NOARCHIVELOG',1,'ARCHIVELOG','MANUAL'),to_number(di.discn),to_number(d

i.difas),decode(bitand(di.diflg,256),256,'CREATED',decode(bitand(di.diflg,1024),1024,'STANDBY',decode(bitand(di.diflg,32

768),32768,'CLONE',decode(bitand(di.diflg,4096),4096,'BACKUP','CURRENT')))),to_date(di.dicct,'MM/DD/RR HH24:MI:SS','NLS_

CALENDAR=Gregorian'),di.dicsq,to_number(di.dickp_scn),to_date(di.dickp_tim,'MM/DD/RR HH24:MI:SS','NLS_CALENDAR=Gregorian

'),decode(bitand(di.diflg,4),4,'REQUIRED',decode(di.diirs,0,'NOT ALLOWED','ALLOWED')),to_date(di.divts,'MM/DD/RR HH24:MI

:SS','NLS_CALENDAR=Gregorian'),decode(di.didor,0,'MOUNTED',decode(di.didor,1,'READ WRITE','READ ONLY')),decode(bitand(di

.diflg,65536),65536,'MAXIMUM PROTECTION',decode(bitand(di.diflg,128),128,'MAXIMUM AVAILABILITY',decode(bitand(di.diflg,1

34217728),134217728,'RESYNCHRONIZATION',decode(bitand(di.diflg,8),8,'UNPROTECTED','MAXIMUM PERFORMANCE')))),decode(di.di

prt,1,'MAXIMUM PROTECTION',2,'MAXIMUM AVAILABILITY',3,'RESYNCHRONIZATION',4,'MAXIMUM PERFORMANCE',5,'UNPROTECTED',  'UNK

NOWN'),decode(di.dirae,0,'DISABLED',1,'SEND',2,'RECEIVE',3,'ENABLED','UNKNOWN'),to_number(di.diacid),to_number(di.diacid

),decode(bitand(di.diflg,33554432),33554432,'LOGICAL STANDBY',decode(bitand(di.diflg,1024),1024,'PHYSICAL STANDBY','PRIM

ARY')),to_number(di.diars),decode(bitand(difl2,1),1,'ENABLED','DISABLED'),decode(di.disos,0,'IMPOSSIBLE',1,'NOT ALLOWED'

,2,'SWITCHOVER LATENT',3,'SWITCHOVER PENDING',4,'TO PRIMARY',5,'TO STANDBY',6,'RECOVERY NEEDED',7,'SESSIONS ACTIVE',8,'P

REPARING SWITCHOVER',9,'PREPARING DICTIONARY',10,'TO LOGICAL STANDBY','UNKNOWN'),decode(di.didgd,0,'DISABLED','ENABLED')

,decode(bitand(di.diflg,1048576),1048576,'ALL',decode(bitand(di.diflg,2097152),2097152,'STANDBY','NONE')),decode(bitand(

diflg,1073741824),1073741824, 'YES',               decode(bitand(diflg, 131072 + 262144 + 524288),0,

 decode(bitand(difl2,2), 0,'NO','IMPLICIT'),                     'IMPLICIT')),decode(bitand(di.diflg,131072),131072,'YE

S','NO'),decode(bitand(di.diflg,262144),262144,'YES','NO'),decode(bitand(di.diflg,268435456),268435456,'YES','NO'),di.di

plid, di.dipln, di2.di2rdi, di2.di2inc,to_number(di.dicur_scn),decode(bitand(di2.di2flag,1),1,'YES',               decod

e(di2.di2rsp_oldest,0,'NO','RESTORE POINT ONLY')),decode(bitand(diflg,524288),524288,'YES','NO'),decode(bitand(difl2,2),

2,'YES','NO'),di.didbun, to_number(di2.di2actiscn), decode(di.difsts,0,'DISABLED',1,'BYSTANDER',2,'SYNCHRONIZED',3,'UNSY

NCHRONIZED',4,'SUSPENDED',5,'STALLED',6,'LOADING DICTIONARY',7,'PRIMARY UNOBSERVED',8,'REINSTATE REQUIRED',9,'REINSTATE

IN PROGRESS',10,'REINSTATE FAILED',''), di.diftgt, di.difths,decode(di.difopr,1,'YES',2,'NO',3,'UNKNOWN',''), di.difobs

from x$kccdi di, x$kccdi2 di2

检查X$KCCDI视图，发现DIRLC_I列对应的数值就是format中%a对应的数值：

SQL> SELECT DIDBN, DIRLC, DIRLC_I

 2  FROM X$KCCDI;

DIDBN     DIRLC                   DIRLC_I

--------- -------------------- ----------

TEST08    06/11/2008 14:52:03   657125523

DIRLC列对应的是RESETLOG的时间，而这个DIRLC_I实际上RESETLOG时间对应的数值。

当然这个数值是通过比较备份结果和X$KCCDI视图的查询结果得到的。下面分析一下RMAN是如何获取这个值的：

[oracle@yans1 ~]$ rman target /

Recovery Manager: Release10.2.0.3.0 - Production on星期四7月16 17:23:41 2009

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

connected to target database: TEST08 (DBID=3812548755)

RMAN> backup spfile;

Starting backup at 16-7月-09

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=69 devtype=DISK

channel ORA_DISK_1: starting full datafile backupset

channel ORA_DISK_1: specifying datafile(s) in backupset

including current SPFILE in backupset

channel ORA_DISK_1: starting piece 1 at 16-7月-09

channel ORA_DISK_1: finished piece 1 at 16-7月-09

piece handle=/opt/ora10g/product/10.2.0/db_1/dbs/05kk9u17_1_1 tag=TAG20090716T172351 comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02

Finished backup at 16-7月-09

首先登陆RMAN，并执行一个备份，确保RMAN进程都已经启动。后台检查RMAN对应的会话：

SQL> SELECT SID, SERIAL#, PROGRAM,

 2  (SELECT SPID FROM V$PROCESS WHERE ADDR = PADDR) SPID

 3  FROM V$SESSION

 4  WHERE USERNAME = 'SYS'

 5  AND PROGRAM LIKE 'rman%';

      SID    SERIAL# PROGRAM                                          SPID

---------- ---------- ------------------------------------------------ ------------

       69       1056 rman@yans1 (TNS V1-V3)                           3104

      104       1043 rman@yans1 (TNS V1-V3)                           3103

      111       1644 rman@yans1 (TNS V1-V3)                           3101

设置会话的TRACE：

SQL> EXEC DBMS_MONITOR.SESSION_TRACE_ENABLE(69, 1056, FALSE, TRUE)

PL/SQL procedure successfully completed.

SQL> EXEC DBMS_MONITOR.SESSION_TRACE_ENABLE(104, 1043, FALSE, TRUE)

PL/SQL procedure successfully completed.

SQL> EXEC DBMS_MONITOR.SESSION_TRACE_ENABLE(111, 1644, FALSE, TRUE)

PL/SQL procedure successfully completed.

在RMAN中备份，并退出：

RMAN> backup tablespace users format '/data/backup/%a_users';

Starting backup at 16-7月-09

using channel ORA_DISK_1

channel ORA_DISK_1: starting full datafile backupset

channel ORA_DISK_1: specifying datafile(s) in backupset

input datafile fno=00004 name=/data/oradata/test08/users01.dbf

channel ORA_DISK_1: starting piece 1 at 16-7月-09

channel ORA_DISK_1: finished piece 1 at 16-7月-09

piece handle=/data/backup/657125523_users tag=TAG20090716T173721 comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01

Finished backup at 16-7月-09

RMAN> exit

Recovery Manager complete.

检查对应的trace信息：

[oracle@yans1 ~]$ more /opt/ora10g/admin/test08/udump/test08_ora_3104.trc

/opt/ora10g/admin/test08/udump/test08_ora_3104.trc

Oracle Database10gEnterprise Edition Release10.2.0.3.0 - 64bit Production

With the Partitioning, OLAP and Data Mining options

ORACLE_HOME = /opt/ora10g/product/10.2.0/db_1

System name:    Linux

Node name:      yans1

Release:        2.6.9-42.0.0.0.1.ELsmp

Version:        #1 SMP Sun Oct 15 15:13:57 PDT 2006

Machine:        x86_64

Instance name: test08

Redo thread mounted by this instance: 1

Oracle process number: 33

Unix process pid: 3104, image: oracle@yans1 (TNS V1-V3)

*** 2009-07-16 17:37:21.447

*** ACTION NAME:(0000027 FINISHED129) 2009-07-16 17:37:21.447

*** MODULE NAME:(backup full datafile) 2009-07-16 17:37:21.447

*** SERVICE NAME:(SYS$USERS) 2009-07-16 17:37:21.447

*** SESSION ID:(69.1056) 2009-07-16 17:37:21.447

RPC CALL:PROCEDURE SYS.DBMS_BACKUP_RESTORE.SETLIMIT(NAME IN BINARY_INTEGER, VALUE IN NUMBER);

RPC BINDS:

bind 0: dty=3 bfp=2a9732bfe8 flg=00 avl=04 mxl=04 val=06

bind 1: dty=6 bfp=2a9732c010 flg=00 avl=01 mxl=22 val=0

*** ACTION NAME:(0000028 FINISHED6) 2009-07-16 17:37:21.448

.

.

.

=====================

PARSING IN CURSOR #3 len=189 dep=0 uid=0 ct=3 lid=0 tim=1218493204547834 hv=3039982291 ad='f552eef0'

SELECT TO_CHAR(SYSDATE  , 'YYYY' , 'NLS_CALENDAR=Gregorian' )  , TO_CHAR(SYSDATE  , 'MM' , 'NLS_CALENDAR=Gregorian' )  , TO_CHAR(SYS

DATE  , 'DD' , 'NLS_CALENDAR=Gregorian' )  FROM X$DUAL  

END OF STMT

PARSE #3:c=1000,e=674,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1218493204547832

BINDS #3:

EXEC #3:c=0,e=28,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1218493204547907

FETCH #3:c=0,e=27,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,tim=1218493204547952

STAT #3 id=1 cnt=1 pid=0 pos=1 bj=0 p='FIXED TABLE FULL X$DUAL (cr=0 pr=0 pw=0 time=22 us)'

RPC CALL:FUNCTION SYS.DBMS_BACKUP_RESTORE.GENPIECENAME(PNO IN NUMBER, SET_COUNT IN NUMBER, SET_STAMP IN NUMBER, FORMAT IN VARCHAR2,

COPYNO IN NUMBER, DEVTYPE IN VARCHAR2, YEAR IN BINARY_INTEGER, MONTH IN BINARY_INTEGER, DAY IN BINARY_INTEGER, DBID IN NUMBER

, NDBNAME IN VARCHAR2, CFSEQ IN NUMBER, FILENO IN NUMBER, TSNAME IN VARCHAR2, LOGSEQ IN VARCHAR2, LOGTHR IN NUMBER, IMAGCP IN BOOLEA

N, SAVEPNAME IN BOOLEAN) RETURN VARCHAR2;

RPC BINDS:

bind 0: dty=6 bfp=2a9732bfe8 flg=00 avl=02 mxl=22 val=1

bind 1: dty=6 bfp=2a9732c020 flg=00 avl=02 mxl=22 val=6

bind 2: dty=6 bfp=2a9732c058 flg=00 avl=06 mxl=22 val=692386641

bind 3: dty=1 bfp=2a9732c0a0 flg=08 avl=21 mxl=512 val="/data/backup/%a_users"

bind 4: dty=6 bfp=2a9732c2c0 flg=00 avl=02 mxl=22 val=1

bind 5: dty=1 bfp=2a9732c308 flg=08 avl=04 mxl=16 val="DISK"

bind 6: dty=3 bfp=2a9732c338 flg=00 avl=04 mxl=04 val=2009

bind 7: dty=3 bfp=2a9732c360 flg=00 avl=04 mxl=04 val=07

bind 8: dty=3 bfp=2a9732c388 flg=00 avl=04 mxl=04 val=16

bind 9: dty=6 bfp=2a9732c3b0 flg=02 avl=00 mxl=22 val=00

bind 10: dty=1 bfp=2a9732c3f8 flg=0aavl=00 mxl=08 val=""

bind 11: dty=6 bfp=2a9732c420 flg=02 avl=00 mxl=22 val=00

bind 12: dty=6 bfp=2a9732c458 flg=00 avl=02 mxl=22 val=4

bind 13: dty=1 bfp=2a9732c4a0 flg=08 avl=05 mxl=30 val="USERS"

bind 14: dty=1 bfp=2a9735cff8 flg=0aavl=00 mxl=32767 val=""

bind 15: dty=6 bfp=2a97380b80 flg=02 avl=00 mxl=22 val=00

bind 16: dty=3 bfp=2a97380bb8 flg=00 avl=04 mxl=04 val=00

bind 17: dty=3 bfp=2a97380be0 flg=00 avl=04 mxl=04 val=00

bind 18: dty=1 bfp=2a9736cff8 flg=0aavl=00 mxl=32767 val=""

*** ACTION NAME:(0000037 FINISHED91) 2009-07-16 17:37:21.457

RPC EXEC:c=0,e=475

RPC CALL:PROCEDURE SYS.DBMS_BACKUP_RESTORE.ISFILENAMEOMF(FNAME IN VARCHAR2, ISOMF OUT BOOLEAN, ISASM OUT BOOLEAN, ISTMPLT OUT BOOLEA

N);

RPC BINDS:

bind 0: dty=1 bfp=2a9732bff8 flg=08 avl=28 mxl=512 val="/data/backup/657125523_users"

bind 1: dty=3 bfp=2a9732c218 flg=02 avl=04 mxl=04 val=00

bind 2: dty=3 bfp=2a9732c240 flg=02 avl=04 mxl=04 val=00

bind 3: dty=3 bfp=2a9732c268 flg=02 avl=04 mxl=04 val=00

*** ACTION NAME:(0000038 FINISHED142) 2009-07-16 17:37:21.458

.

.

.

*** ACTION NAME:(0000046 FINISHED5) 2009-07-16 17:37:22.516

RPC EXEC:c=0,e=150

RPC CALL:PROCEDURE SYS.DBMS_BACKUP_RESTORE.BMRCANCEL();

RPC BINDS:

*** ACTION NAME:(0000047 FINISHED101) 2009-07-16 17:37:22.517

RPC EXEC:c=0,e=74

RPC CALL:PROCEDURE SYS.DBMS_BACKUP_RESTORE.FLASHBACKCANCEL();

RPC BINDS:

*** ACTION NAME:(0000048 FINISHED118) 2009-07-16 17:37:22.517

RPC EXEC:c=1000,e=79

=====================

PARSING IN CURSOR #3 len=32 dep=0 uid=0 ct=3 lid=0 tim=1218493205583311 hv=708194795 ad='f7893f18'

select count(*) from sys.x$kcrmx

END OF STMT

PARSE #3:c=0,e=32,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1218493205583309

BINDS #3:

EXEC #3:c=0,e=36,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1218493205583425

FETCH #3:c=0,e=10,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,tim=1218493205583448

STAT #3 id=1 cnt=1 pid=0 pos=1 bj=0 p='SORT AGGREGATE (cr=0 pr=0 pw=0 time=19 us)'

STAT #3 id=2 cnt=0 pid=1 pos=1 bj=0 p='FIXED TABLE FULL X$KCRMX (cr=0 pr=0 pw=0 time=8 us)'

RPC CALL:PROCEDURE SYS.DBMS_BACKUP_RESTORE.SETRMANSTATUSROWID(RSID IN NUMBER, RSTS IN NUMBER);

RPC BINDS:

bind 0: dty=6 bfp=2a9732bfe8 flg=00 avl=01 mxl=22 val=0

bind 1: dty=6 bfp=2a9732c020 flg=00 avl=01 mxl=22 val=0

*** ACTION NAME:(0000049 FINISHED129) 2009-07-16 17:37:22.517

RPC EXEC:c=0,e=112

可以看到，Oracle通过调用函数DBMS_BACKUP_RESTORE.GENPIECENAME获取的BACKUP段名称，也就是说%a对应的值，是通过这个函数调用获取的。

而且这个函数调用的内部SQL语句Oracle没有跟踪到。说明这个包的实现可能不是在数据库的SQL层实现的。

不过分析RMAN的trace信息还是有一定意义的，在分析RMAN访问视图时，找到了对应的信息：

SQL> alter session set nls_date_format = 'yyyy-mm-dd hh24:mi:ss';

Session altered.

SQL> select incarnation#, resetlogs_change#, resetlogs_time, resetlogs_id, status

 2  from v$database_incarnation;

INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME      RESETLOGS_ID STATUS

------------ ----------------- ------------------- ------------ -------

          1                 1 2008-06-11 14:52:03    657125523 CURRENT

其实这个RESETLOGS_ID的值在V$ARCHIVED_LOG视图中也可以找到。而且这个值对应的就是归档日志格式中的%r。只不过Oracle在不同的地方采用了不同的表示方式，而且描述上也有所区别。

另外这个RESETLOGS_ID显然是由RESETLOGS_TIME决定的，看一个有趣的现象：

SQL> select resetlogs_time - resetlogs_id/86400 from v$database_incarnation;

RESETLOGS_TIME-RESE

-------------------

1987-08-16 00:00:00

测试了很多数据库，得到的结果都是1987年8月的某一日。显然Oracle在记录这个RESETLOGS_ID的时候有一定的规则。

oracle视频教程请关注:http://u.youku.com/user_video/id_UMzAzMjkxMjE2.html