rman 备份出现ORA-00245/RMAN-08132

rman备份出现如下错误

RMAN> backup full  tag 'dbfull' format '/jfkdata1/rman_bak/full_%d_%u' database 
 2>   include current controlfile  plus archivelog  format '/jfkdata1/rman_bak/arch_%d_%u'; 


Starting backup at 13-MAR-12
current log archived
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=297 instance=ykcdb2 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=29 RECID=43 STAMP=777808820
input archived log thread=1 sequence=30 RECID=46 STAMP=777816035
input archived log thread=2 sequence=21 RECID=45 STAMP=777816033
channel ORA_DISK_1: starting piece 1 at 13-MAR-12
channel ORA_DISK_1: finished piece 1 at 13-MAR-12
piece handle=/jfkdata1/rman_bak/arch_YKCDB_01n5p1vf tag=DBFULL comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:25
Finished backup at 13-MAR-12

Starting backup at 13-MAR-12
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00002 name=/jfkdata1/oradata/ykcdb/sysaux01.dbf
input datafile file number=00001 name=/jfkdata1/oradata/ykcdb/system01.dbf
input datafile file number=00003 name=/jfkdata1/oradata/ykcdb/undotbs01.dbf
input datafile file number=00005 name=/jfkdata1/oradata/ykcdb/undotbs02.dbf
input datafile file number=00004 name=/jfkdata1/oradata/ykcdb/users01.dbf
channel ORA_DISK_1: starting piece 1 at 13-MAR-12
channel ORA_DISK_1: finished piece 1 at 13-MAR-12
piece handle=/jfkdata1/rman_bak/full_YKCDB_02n5p209 tag=DBFULL comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:25
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 13-MAR-12
channel ORA_DISK_1: finished piece 1 at 13-MAR-12
piece handle=/jfkdata1/rman_bak/full_YKCDB_03n5p213 tag=DBFULL comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 13-MAR-12

Starting backup at 13-MAR-12
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=2 sequence=22 RECID=48 STAMP=777816102
input archived log thread=1 sequence=31 RECID=47 STAMP=777816101
channel ORA_DISK_1: starting piece 1 at 13-MAR-12
channel ORA_DISK_1: finished piece 1 at 13-MAR-12
piece handle=/jfkdata1/rman_bak/arch_YKCDB_04n5p217 tag=DBFULL comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 13-MAR-12
ORA-00245: control file backup operation failed

RMAN-08132: WARNING: cannot update recovery area reclaimable file list

RMAN> 

从这里可以看出数据库文件,归档日志,spfile和controlfile都备份完成,后面又出现一个controlfile失败,应该是控制文件快照备份失败。

错误原因

RMAN creates a copy of the control file for read consistency, this is the snapshot controlfile. 
Due to the changes made to the controlfile backup mechanism in 11gR2 any instances 
in the cluster may write to the snapshot controlfile. Therefore, 
the snapshot controlfile file needs to be visible to all instances.

The same happens when a backup of the controlfile is created directly from 
sqlplus any instance in the cluster may write to the backup controfile file.

In 11gR2 onwards, the controlfile backup happens without holding the control file enqueue. 
For non-RAC database, this doesn't change anything. 

But, for RAC database, the snapshot controlfile location 
must be in a shared file system that will be accessible from all the nodes.

The snapshot controlfile MUST be  accessible by all nodes of a RAC database. 

大致意思就是rman的snapshot controlfile必须放在共享存储之上。

解决方法

The snapshot controlfile MUST be accessible by all nodes of a RAC database, 
if the snapshot controlfile does not reside in on a shared device this error will raise.

1. Check the snapshot controlfile location:
RMAN> show all;

2. Configure the snapshot controlfile to a shared disk:
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '<shared_disk>/snapcf_<DBNAME>.f';

TimesTen c/s模式配置

一、linux/unix环境配置
1.相关IP配置
客户端:192.168.1.105
服务端:192.168.1.10

2.服务端ODBC配置

$ more sys.odbc.ini
[ODBC Data Sources]
TT_1122=TimesTen 11.2.2 Driver
[TT_1122]
Driver=/u01/TimesTen/tt1122/lib/libtten.so
DataStore=/u01/TimesTen/tt1122/info/TT_1122
DatabaseCharacterSet=ZHS16GBK
PermSize=64
OracleNetServiceName=XFF

3.服务端timesten监听端口

$ ttstatus|grep "TimesTen server"
TimesTen server pid 3792 started on port 53393

4.客户端配置

$ more sys.ttconnect.ini 
[tt_xifenfei_c_s]
Network_Address=192.168.1.10
TCP_PORT=53393

$ more sys.odbc.ini
[ODBC Data Sources]
tt_xifenfei_c=TimesTen 11.2.2 Client Driver
[tt_xifenfei_c]
TTC_SERVER=tt_xifenfei_c_s
TTC_SERVER_DSN=tt_1122
UID=chf
PWD=xifenfei

参考:在另一节点配置TT客户端的简明方法

二、win环境配置
1.在odbc中选择增加timesten client

2.点击services,增加ip和端口配置

3.配置关闭services,配置其他选项

三、补充说明
这里的配置,基本上都是最基础配置,在实际生产环境中,需要考虑其他相关环境变量

gzexe加密shell脚本

很多时候,我们的脚本中涉及的用户名/密码/ip等敏感信息,我们需要使用一些加密方面来屏蔽这些信息,确保我们的系统安全(主要防菜鸟),虽然shc可以实现强大的加密功能,但是他需要另外安装shc软件,比较麻烦,应对一般的加密,个人推荐直接喜用系统自带的gzexe(大部分Linux,unix都有)

[root@xifenfei tmp]# more xifenfei.sh 
#!/usr/bin/ksh
echo 'xifenfei--'`date`

[root@xifenfei tmp]# ./xifenfei.sh 
xifenfei--Tue Mar 6 13:31:35 CST 2012
[root@xifenfei tmp]# ls -l xifenfei.sh
-rwxr-xr-x 1 root root 40 Mar  6 13:30 xifenfei.sh

--加密操作
[root@xifenfei tmp]# gzexe xifenfei.sh 
xifenfei.sh:     -5.0%
[root@xifenfei tmp]# ls -l xifenfei.sh*
-rwxr-xr-x 1 root root 449 Mar  6 13:31 xifenfei.sh
-rwxr-xr-x 1 root root  40 Mar  6 13:30 xifenfei.sh~

--加密后文件内容
[root@xifenfei tmp]# strings xifenfei.sh
#!/bin/sh
skip=14
tmpdir=`/bin/mktemp -d ${TMPDIR:-/tmp}/gzexe.XXXXXXXXXX` || exit 1
prog="${tmpdir}/`echo \"$0\" | sed 's|^.*/||'`"
if /usr/bin/tail -n +$skip "$0" | "/bin"/gzip -cd > "$prog"; then
  /bin/chmod 700 "$prog"
  trap '/bin/rm -rf $tmpdir; exit $res' EXIT
  "$prog" ${1+"$@"}; res=$?
else
  echo "Cannot decompress $0"
  /bin/rm -rf $tmpdir
  exit 1
fi; exit $res
xifenfei.sh
UOHI,IM

这里的xifenfei.sh是加密后文件,xifenfei.sh~是源码文件(加密前文件),只需要运行xifenfie.sh即可实现原脚本功能
优点:在大部分系统上均可运行,不用安装额外软件
缺点:破解容易,放君子不防小人

Multiple-table cache group配置

1.准备测试表和数据

SQL> CREATE TABLE customer
  2  (cust_num NUMBER(6) NOT NULL PRIMARY KEY,
  3   name     VARCHAR2(50)
  4  );

Table created.

SQL> CREATE TABLE orders
  2  (ord_num      NUMBER(10) NOT NULL PRIMARY KEY,
  3   cust_num     NUMBER(6) NOT NULL
  4  );

Table created.


SQL> insert into customer values(1,'wwww.orasos.com1');

1 row created.

SQL> insert into customer values(2,'wwww.orasos.com2');

1 row created.

SQL> insert into customer values(3,'wwww.orasos.com3');

1 row created.

SQL> insert into customer values(4,'wwww.orasos.com4');

1 row created.

SQL> insert into orders(cust_num,ord_num) values(1,1);

1 row created.

SQL> insert into orders (cust_num,ord_num) values(1,2);

1 row created.

SQL> insert into orders (cust_num,ord_num) values(3,5);

1 row created.

SQL> insert into orders (cust_num,ord_num) values(3,6);

1 row created.

SQL> commit;

Commit complete.

SQL> select * from customer;

  CUST_NUM NAME
---------- --------------------------------------------------
         1 wwww.orasos.com1
         2 wwww.orasos.com2
         3 wwww.orasos.com3
         4 wwww.orasos.com4

SQL> select * from orders;

   ORD_NUM   CUST_NUM
---------- ----------
         1          1
         2          1
         5          3
         6          3

SQL> grant select on oratt.customer to cacheuser;

Grant succeeded.

SQL> grant select on oratt.orders to cacheuser;

Grant succeeded.

2.创建cache group

[oracle@xifenfei ~]$ ttIsql "DSN=tt_1122;UID=cacheuser;PWD=timesten;OraclePWD=oracle"

Command>  drop cache group cacheuser.customer_orders;
Command> CREATE READONLY CACHE GROUP customer_orders
       > AUTOREFRESH INTERVAL 5 SECONDS
       > STATE ON
       > FROM oratt.customer
       >  (cust_num NUMBER(6) NOT NULL,
       >   name     VARCHAR2(50),
       >   PRIMARY KEY(cust_num)),
       > oratt.orders
       >  (ord_num      NUMBER(10) NOT NULL,
       >   cust_num     NUMBER(6) NOT NULL,
       >   PRIMARY KEY(ord_num),
       >   FOREIGN KEY(cust_num) REFERENCES oratt.customer(cust_num));

Command> cachegroups;

Cache Group CACHEUSER.CUSTOMER_ORDERS:

  Cache Group Type: Read Only
  Autorefresh: Yes
  Autorefresh Mode: Incremental
  Autorefresh State: On
  Autorefresh Interval: 5 Seconds
  Autorefresh Status: ok
  Aging: No aging defined

  Root Table: ORATT.CUSTOMER
  Table Type: Read Only


  Child Table: ORATT.ORDERS
  Table Type: Read Only

1 cache groups found.

3.TT中表访问授权

[oracle@xifenfei ~]$ ttisql tt_1122

Command> grant select on oratt.customer to cacheuser;
Command> grant select on oratt.orders to cacheuser;

4.测试数据初始化

[oracle@xifenfei ~]$ ttIsql "DSN=tt_1122;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> select * from oratt.customer;
< 1, wwww.orasos.com1 >
< 2, wwww.orasos.com2 >
< 3, wwww.orasos.com3 >
< 4, wwww.orasos.com4 >
4 rows found.
Command> select * from oratt.orders;
< 1, 1 >
< 2, 1 >
< 5, 3 >
< 6, 3 >
4 rows found.

5.ORACLE修改数据

SQL> update customer set name='xifenfei' where cust_num=2;

1 row updated.

SQL> insert into customer values(5,'wwww.orasos.com5');

1 row created.

SQL> delete from customer where cust_num=1;

1 row deleted.

SQL> commit;

Commit complete.

6.TT中验证数据

Command> select * from oratt.customer;
< 2, xifenfei >
< 3, wwww.orasos.com3 >
< 4, wwww.orasos.com4 >
< 5, wwww.orasos.com5 >
4 rows found.
Command> select * from oratt.orders;
< 5, 3 >
< 6, 3 >
2 rows found.

7.补充说明
7.1)在oracle中需要授权cacheuser有访问oratt中相关表权限,不然创建cache group失败
7.2)自动刷新数据需要设置AUTOREFRESH STATE ON,其他方法初始化关联表的数据暂未知
7.3)在TT中,关联表删除是级联的

记录一次ORA-600[13013]处理过程

在一次数据库的异常处理完成后,发现alert日志中出现ORA-600[13013]错误

Thu Mar 08 23:29:37 2012
Errors in file /opt/oracle/diag/rdbms/chf/chf/trace/chf_smon_24137.trc  (incident=38681):
ORA-00600: internal error code, arguments: [13013], [5001], [518], [4198427], [170], [4198427], [17], [], [], [], [], []
Incident details in: /opt/oracle/diag/rdbms/chf/chf/incident/incdir_38681/chf_smon_24137_i38681.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Non-fatal internal error happenned while SMON was doing flushing of monitored table stats.
SMON encountered 1 out of maximum 100 non-fatal internal errors.

trace文件中信息
从这里可以看出是对sys.col_usage$表进行update操作导致该错误发生

Dump continued from file: /opt/oracle/diag/rdbms/chf/chf/trace/chf_smon_24137.trc
ORA-00600: internal error code, arguments: [13013], [5001], [518], [4198427], [170], [4198427], [17], [], [], [], [], []

========= Dump for incident 38681 (ORA 600 [13013]) ========

*** 2012-03-08 23:29:37.400
dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)
----- Current SQL Statement for this session (sql_id=3c1kubcdjnppq) -----
update sys.col_usage$ set   equality_preds    = equality_preds    + decode(bitand(:flag,1),0,0,1),   equijoin_preds    = equijoin_preds    + decode(bitand(:flag,2),0,0
,1),   nonequijoin_preds = nonequijoin_preds + decode(bitand(:flag,4),0,0,1),   range_preds       = range_preds       + decode(bitand(:flag,8),0,0,1),   like_preds    
    = like_preds        + decode(bitand(:flag,16),0,0,1),   null_preds        = null_preds        + decode(bitand(:flag,32),0,0,1),  timestamp = :time where obj# = :ob
jn and intcol# = :coln

MOS中关于ORA-600 [13013]描述

Format: ORA-600 [13013] [a] [b] {c} [d] [e] [f]
Arg [a] Passcount
Arg [b] Data Object number
Arg {c} Tablespace Decimal Relative DBA (RDBA) of block containing the row to be updated
Arg [d] Row Slot number
Arg [e] Decimal RDBA of block being updated (Typically same as {c})
Arg [f] Code

验证MOS中描述

SQL> select dbms_utility.data_block_address_file(4198427) rfile,
  2  dbms_utility.data_block_address_block(4198427) blocks
  3  from dual;

     RFILE     BLOCKS
---------- ----------
         1       4123

SQL> SELECT OWNER, SEGMENT_NAME, SEGMENT_TYPE, TABLESPACE_NAME, A.PARTITION_NAME
  2    FROM DBA_EXTENTS A
  3   WHERE FILE_ID = &FILE_ID
  4     AND &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1;
Enter value for file_id: 1
old   3:  WHERE FILE_ID = &FILE_ID
new   3:  WHERE FILE_ID = 1
Enter value for block_id: 4123
old   4:    AND &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1
new   4:    AND 4123 BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1

OWNER SEGMENT_NAME SEGMENT_TY TABLESPACE PARTI
----- ------------ ---------- ---------- -----
SYS   COL_USAGE$   TABLE      SYSTEM
--和trace文件中异常表一致

SQL>  select object_type,object_name from dba_objects where object_id=518;

OBJECT_TYPE         OBJECT_NAME
------------------- ------------------------------
TABLE               COL_USAGE$
--也和trace文件中异常表一致

分析异常表

SQL> ANALYZE TABLE sys.COL_USAGE$ VALIDATE STRUCTURE CASCADE;
ANALYZE TABLE sys.COL_USAGE$ VALIDATE STRUCTURE CASCADE
*
ERROR at line 1:
ORA-01499: table/index cross reference failure - see trace file

SQL> select index_name,COLUMN_NAME,COLUMN_POSITION FROM DBA_IND_COLUMNS 
2    WHERE TABLE_NAME='COL_USAGE$';

INDEX_NAME      COLUMN_NAM COLUMN_POSITION
--------------- ---------- ---------------
I_COL_USAGE$    OBJ#                     1
I_COL_USAGE$    INTCOL#                  2

SQL> set autot trace exp
SQL>  SELECT /*+ FULL(t1) */ OBJ#,INTCOL#
  2   FROM sys.COL_USAGE$ t1
  3   MINUS
  4   SELECT /*+ index(t I_COL_USAGE$) */ OBJ#,INTCOL#
  5   FROM sys.COL_USAGE$ t where OBJ# is not null or INTCOL# is not null;

no rows selected
--无记录返回

Execution Plan
----------------------------------------------------------
Plan hash value: 399371572

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

| Id  | Operation           | Name         | Rows  | Bytes | Cost (%CPU)| Time
   |

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

|   0 | SELECT STATEMENT    |              |  4262 | 76716 |    27  (71)| 00:00:01 |
|   1 |  MINUS              |              |       |       |            |          |
|   2 |   SORT UNIQUE       |              |  4262 | 38358 |     9  (12)| 00:00:01 |
|   3 |    TABLE ACCESS FULL| COL_USAGE$   |  4262 | 38358 |     8   (0)| 00:00:01 |
|   4 |   SORT UNIQUE NOSORT|              |  4262 | 38358 |    18   (6)| 00:00:01 |
|*  5 |    INDEX FULL SCAN  | I_COL_USAGE$ |  4262 | 38358 |    17   (0)| 00:00:01 |

------------------------------------------------------------------------------------
--验证表两个sql是否正确(一个全表扫描,另个index 快速扫描)


SQL>  SELECT /*+ index(t I_COL_USAGE$) */ OBJ#,INTCOL#
  2   FROM sys.COL_USAGE$ t where OBJ# is not null or INTCOL# is not null
  3   MINUS
  4  SELECT /*+ FULL(t1) */ OBJ#,INTCOL#
  5   FROM sys.COL_USAGE$ t1;

      OBJ#    INTCOL#
---------- ----------
4294951004          2
4294951004          3
4294951004          4
4294951004         26
4294951004         27
4294951037          4
4294951037          5
4294951037          6
4294951037          9
4294951037         10
4294951840         11

      OBJ#    INTCOL#
---------- ----------
4294951840         12
4294951906          4
4294952709          3
4294952867          4
4294952867          9

16 rows selected.
--证明index中的记录比表中多了16条

解决问题并验证

SQL> alter index sys.I_COL_USAGE$ rebuild online;

Index altered.

SQL>  SELECT /*+ FULL(t1) */ OBJ#,INTCOL#
 FROM sys.COL_USAGE$ t1
  2    3   MINUS
  4   SELECT /*+ index(t I_COL_USAGE$) */ OBJ#,INTCOL#
  5   FROM sys.COL_USAGE$ t where OBJ# is not null or INTCOL# is not null
  6  ;

no rows selected

SQL>  SELECT /*+ index(t I_COL_USAGE$) */ OBJ#,INTCOL#
  2   FROM sys.COL_USAGE$ t where OBJ# is not null or INTCOL# is not null
  3   MINUS
  4  SELECT /*+ FULL(t1) */ OBJ#,INTCOL#
  5   FROM sys.COL_USAGE$ t1;

no rows selected

这次出现此问题的原因是因为在更新语句中使用索引找到一条记录,然后到表中去查询时该记录不存在,出现此错误,一般解决方法是重建索引
官方关于ORA-600[13013]说明