本次测试环境

OEL 5.2 ：VTL（Vistor）2.1.1 + TSM Server 5.5.3 + Client 5.5.3 + Administrator Center（AC）6.2

OEL 4.8：Tsm Client 5.5.3 + Storage Agent 5.5.3+ TDPO 5.5.2 + Oracle 9208

这里下载。

对于TSM Server、Client、Storage Agent、TDPO的安装、配置就不说了，但有一个地方得注意一下，下载的TDPO里不包含license文件（agent.lic），有tdpoerror.log日志文件里会有提示：

05/13/2011 11:26:30 TID<8556> ==> ANU2512E Could not open license file: /opt/tivoli/tsm/client/oracle/bin/agent.lic

可从其它地方拷贝过来测试使用。

lan-free测试：

[oracle@db92 ~]$ cat test.sh

rman target / log=test.log <<EOF

run {

allocate channel ‘dev_0′  type ‘sbt_tape’ parms ‘ENV=(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin/tdpo.opt)’;

backup format ‘db_%t’ database;

}

EOF

using target database controlfile instead of recovery catalog

allocated channel: dev_0

channel dev_0: sid=17 devtype=SBT_TAPE

channel dev_0: Data Protection for Oracle: version 5.5.2.0

Starting backup at 13-MAY-11

channel dev_0: starting full datafile backupset

channel dev_0: specifying datafile(s) in backupset

including current SPFILE in backupset

including current controlfile in backupset

input datafile fno=00001 name=/u01/app/oracle/oradata/db92/system01.dbf

input datafile fno=00002 name=/u01/app/oracle/oradata/db92/undotbs01.dbf

input datafile fno=00004 name=/u01/app/oracle/oradata/db92/indx01.dbf

input datafile fno=00006 name=/u01/app/oracle/oradata/db92/users01.dbf

input datafile fno=00003 name=/u01/app/oracle/oradata/db92/cwmlite01.dbf

input datafile fno=00005 name=/u01/app/oracle/oradata/db92/tools01.dbf

channel dev_0: starting piece 1 at 13-MAY-11

channel dev_0: finished piece 1 at 13-MAY-11

piece handle=db_751048255 comment=API Version 2.0,MMS Version 5.5.2.0

channel dev_0: backup set complete, elapsed time: 00:01:36

Finished backup at 13-MAY-11

released channel: dev_0

RMAN>

如果备份是走LAN‐FREE ，备份结束后LanFree Data bytes: 应该大于0 。

[oracle@db92 ~]$ dsmc selective “/home/oracle/test.sh”

IBM Tivoli Storage Manager

Command Line Backup/Archive Client Interface

Client Version 5, Release 5, Level 3.0

Client date/time: 05/13/2011 16:43:35

(c) Copyright by IBM Corporation and other(s) 1990, 2010. All Rights Reserved.

Node Name: DB92

Please enter your user id <DB92>:

Please enter password for user id “DB92″:

Session established with server TSM_SVR1: Linux/i386

Server Version 5, Release 5, Level 3.0

Server date/time: 05/13/2011 10:47:01  Last access: 05/13/2011 10:46:42

Selective Backup function invoked.

Normal File–>               191 /home/oracle/test.sh  ** Unsuccessful **

ANS1114I Waiting for mount of offline media.

Retry # 1  Normal File–>               191 /home/oracle/test.sh [Sent]

Selective Backup processing of ‘/home/oracle/test.sh’ finished without failure.

Total number of objects inspected:        1

Total number of objects backed up:        1

Total number of objects updated:          0

Total number of objects rebound:          0

Total number of objects deleted:          0

Total number of objects expired:          0

Total number of objects failed:           0

Total number of bytes transferred:     446  B

LanFree data bytes:                     211  B

Data transfer time:                    0.00 sec

Network data transfer rate:        33,503.60 KB/sec

Aggregate data transfer rate:          0.38 KB/sec

Objects compressed by:                    0%

Elapsed processing time:           00:00:01

如果你有很多TSM Server的可以安装：Integrated Solutions Console (ISC) and Administrative Center，类似IBM的HMC管理小型机，不太适合像我这样的字符控。AC6.2已经集成了ISC，不用再单独安装了，如下命令可以启动AC：

[root@TSMSRV bin]# cd /opt/ibm/ac/profiles/TIPProfile/bin

[root@TSMSRV bin]# ./startServer.sh server1 -username tipadmin -password tipadmin

http://192.168.248.134:16310

 
-The End-

您可能也喜欢：

客户培训

AIX下使用 raw 创建 non-rac 的ASM

CRS、CSS、clusterware的概念

新手拍微距

无觅

Updated  @ 2010-12-07

一、系统背景：

硬件：    P690_1和P670_1

操作系统：A IX 5.2 ML04

数据库：  Oracle 9.2.0.1.0  2 Nodes RAC  HA

备库P570（非DG）： 与DG原理类似，利用生产库的归档日志在P570上恢复

故障时间：2010-11-23  13:20

二、故障现象：

数据库系统在13：19报告SYSTEM表空间空间不够无法自动扩展，因为系统使用RAW设备所以无法自动扩展，需要管理员手工增加RAW设备文件。

客户工程师在P670_1节点上新增RAW设备并增加到SYSTEM表空间：

RAW设备：/dev/rwwwdb_system04

SQL>alter tablespace system add ‘/dev/rwwwdb_system04’ reuse;

随后系统报错：

dbv检查数据文件，报文件坏块：

此时，由于系统表空间不足数据库系统被挂起，欲将增加失败的数据文件离线删除后重启数据库实例报错：

SQL>ALTER DATABASE DATAFILE ‘/dev/rwwwdb_system04′ offline drop;

不要受[ID 422031.1]ORA-01122, ORA-01251 or data blocks reported as corrupted影响，否则方向错了会花比较多的时间

时间：16：00

由于系统数据量大，在生产库不能短时间恢复情况下的

措施：启动P570备库

结果：启动备库P570失败

原因：在10月19增加数据库文件/dev/rphoto1026时出错，需要恢复。

时间：16：20

措施：利用生产系统RMAN备份来恢复

结果：无法恢复

原因：每晚8点的定时备份任务在14日由于备份空间不足备份失败，后续没有任务备份；系统归档日志保留策略为7天，若要恢复到14日备份前，缺少1天的归档日志文件。

时间：16：30

措施：向公司上级汇报情况，商议决策

结果：与Oracle原厂工程取得系统，商议决策如下：

1.      保护好生产系统现状

2.      使用操作系统级dd命令备份生产系统所有数据文件

3.      将备份的文件用dd命令恢复到备库P570

4.      在备库P570上做恢复测试

时间：24日2：30

措施：在P570备机上重建control file，剔除/dev/rwwwdb_system04数据文件，尝试打开数据库。

结果：open失败

原因：Oracle 9i 系统表空间数据文件不能真正删除（10g开始可以）。

再次如下恢复操作：

重新创建/dev/rwwwdb_system04文件

SQL> alter database create datafile ‘/dev/rwwwdb_system04′ as ‘/dev/rwwwdb_system04′;

结果：open成功

三、生产系统恢复过程：

1.      重建control file

获取重建控制文件的脚本，并修改相应部分

SQL> alter database backup controlfile to trace;

2.      修改启动参数文件，将控制文件存放路径临时指定到一个新位置，并启动数据库到 nomount状态

3.      执行重建控制文件的脚本，启动数据库mount状态

SQL>@bldctl.sql

SQL>alter database mount;

4.      创建数据文件/dev/rwwwdb_system04

SQL>alter database create datafile ‘/dev/rwwwdb_system04′ as ‘/dev/rwwwdb_system04′;

5.      重启数据库到mount状态,恢复/dev/rwwwdb_system04文件

SQL>startup mount;

SQL>ALTER DATABASE RECOVER  datafile ‘/dev/rwwwdb_system04′ ;

6.      尝试打开数据库

SQL>alter database open;

报错：ORA-1113 signalled during: alter database open…，数据库需要恢复

7.      恢复数据库

SQL>alter database recover database;

8.      重启数据库

SQL>shutdown  immediate;

SQL>startup;

9.      将控制文件恢复到RAW设备上

SQL>shutdown immediate;

$dd if= /dbbak/cntrl7 of= /dev/rwwwdb_cntrl3 bs=2m

$dd if= /dbbak/cntrl8 of= /dev/rwwwdb_cntrl4 bs=2m

$dd if= /dbbak/cntrl9 of= /dev/rwwwdb_cntrl5 bs=2m

修改启动参数文件initwwwdb1.ora，还原控制文件存放位置

SQL>startup  pfile=?/dbs/initwwwdb1.ora

SQL>create spfile from pfile;

SQL>shutdown immediate;

SQL>startup;

10.  执行在重建控制文件时没有执行的命令，并将数据库中只读表空间online

至此，生产系统数据库成功打开。

P670_1节点处理：

检查P670_1节点，发现主机访问DS4500存储系统上共享VG出现问题，为数据安全起见，先在P690_1节点备份数据库再处理P670_1节点。

四、故障分析：

在备份成功后，处理P670_1节点发现，DS4500存储系统B控制器坏掉，而引发了增加SYSTEM表空间失败。在更换存储系统控制器后，P670_1节点正常工作。

五、改进与预防措施：

1. 完善备份策略

2. 改善P570备库方式（采用rman备份归档日志，再恢复归档日志）

3. 每天检查生产系统的备份情况，及时发现问题及时处理。

-The End-

您可能也喜欢：

CONFIGURE BACKUP OPTIMIZATION

学习：AIX 5L网络性能优化(一)

Baby,we love you!

游记：遵义会议纪念馆

无觅

-The End-

您可能也喜欢：

TSM lan-free测试

DB2对比Oracle学习系列之:instance & database concepts

结婚一周年

Birthday Cake

无觅

—Coming from 《Effective Oracle by Design》

还可以看看Eygle的这篇文章《DBA警世录：备份重于一切》

您可能也喜欢：

Surprise!第一本《Oracle DBA手记》

Birthday Cake

AIX下使用 raw 创建 non-rac 的ASM

IBM DS4300微码升级失败解决办法

无觅