天道酬勤

Oracle and My Life

Archive for the ‘Backup & Recover’ Category

TSM lan-free测试

leave a comment

为了能给客户提供更好的服务,一如继往尽可能的在自己的本本上搭建一个环境,做的越多看的越多,胆量却越来越小了,有了环境就多了一个选择,不至于在客户生产系统上去验证自己的推断。

本次测试环境

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

AC
 
-The End-

Written by ochef

May 18th, 2011 at 10:53 pm

Posted in Backup & Recover

Tagged with ,

无有效备份下恢复数据库一例

4 comments

昨天通宵恢复一个1T的数据库,早上6点成功恢复,立即开始备份。7点回家睡觉下午三点起床,也许这就是一个DBA的生活。本想现在写写恢复过程,不过又想睡觉了,明天好好写吧。

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设备文件。

Tue Nov 23 13:18:41 2010

Completed: alter database backup controlfile to ‘/p690_1_arch

Tue Nov 23 13:19:20 2010

ORA-1653: unable to extend table WWW.MLOG$_WWW_MONEY_T by 8192 in           tablespace SYSTEM

ORA-1653: unable to extend table WWW.MLOG$_WWW_MONEY_T by 8192 in           tablespace SYSTEM

ORA-1653: unable to extend table WWW.MLOG$_WWW_MONEY_T by 8192 in           tablespace SYSTEM

……

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

RAW设备:/dev/rwwwdb_system04

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

随后系统报错:

ORA-01157: cannot identify/lock data file 424 – see DBWR trace file

ORA-01110: data file 424: ‘/dev/rwwwdb_system04′

ORA-27037: unable to obtain file status

IBM AIX RISC System/6000 Error: 2: No such file or directory

Additional information: 3

Tue Nov 23 14:17:03 2010

Errors in file /oracle/ora92/admin/wwwdb/bdump/wwwdb1_dbw0_516116.trc:

ORA-01186: file 424 failed verification tests

ORA-01157: cannot identify/lock data file 424 – see DBWR trace file

ORA-01110: data file 424: ‘/dev/rwwwdb_system04′

Tue Nov 23 14:17:03 2010

File 424 not verified due to error ORA-01157

dbv检查数据文件,报文件坏块:

DBVERIFY – Verification starting : FILE = /dev/rwwwdb_system04

Page 1 is influx – most likely media corrupt

Corrupt block relative dba: 0×00000001 (file 0, block 1)

Fractured block found during dbv:

Data in bad block:

type: 0 format: 0 rdba: 0×00000000

last change scn: 0×0000.00000000 seq: 0×0 flg: 0×00

spare1: 0×0 spare2: 0×0 spare3: 0×0

consistency value in tail: 0×00000000

check value in block header: 0×0

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

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

Tue Nov 23 14:56:18 2010

ORA-1541 signalled during: ALTER DATABASE DATAFILE ‘/dev/rwwwdb_system04′ off…

This instance was first to open

ORA-1147 signalled during: alter database open…

ORA-01122: database file 424 failed verification check

ORA-01110: data file 424: ‘/dev/rwwwdb_system04′

ORA-01251: Unknown File Header Version read for file number 26

不要受[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天的归档日志文件。

Read the rest of this entry »

Written by ochef

November 24th, 2010 at 9:30 pm

Posted in Backup & Recover,Database

Tagged with ,

客户培训

leave a comment

22-23日连续三天,公司为客户培训Falconstor CDP容灾方案IBM TSM备份和恢复

-The End-

Written by ochef

November 23rd, 2010 at 10:36 am

Posted in Backup & Recover

Tagged with ,

DBA谨记

leave a comment

在数据库日常工作中凡是人人都知道的错误没什么了不起,但如果你把数据库的备份和恢复搞糟了,这就是不可饶恕的。数据缓慢,可以整理,但丢掉了数据,就没有什么办法了。DBA不能搞错的事就是备份与恢复。成为备份与恢复的专家,才能使工作的安全性有所保障。

—Coming from 《Effective Oracle by Design》

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

Written by ochef

March 16th, 2009 at 9:07 am

Posted in Backup & Recover,Database

Tagged with

无觅相关文章插件,快速提升流量