backup

[JKDB] BACKUP AND RESTORE

May 11, 2017 Architect, backup, hardware, IDC, maintain, MYSQL, rdbms, replication, system No comments

JKDB PLATFORM – our company’s data management platform

In this post, we introduce backup-restore module,focus on automatic backup and restore in a huge MySQL database environment.

Read this PDF: JKDB:BACKUP-RESTORE

Facebook WDT Test

March 17, 2017 Architect, backup, hardware, IDC, network, system No comments

We test Facebook WDT tool:https://github.com/facebook/wdt

Read this PDD: WDT-TEST

Fractured blocks when Rman backup is running

February 20, 2012 backup, oracle, replication No comments

系统alert在主库出现下面错误 OS为linux 5.5


Stopping background process CJQ0
Sat Feb 11 03:41:07 2012
Hex dump of (file 9, block 561424) in trace file /data/oracle/diag/rdbms/yhdstd/yhddb1/trace/yhddb1_ora_11327.trc
Corrupt block relative dba: 0x02489110 (file 9, block 561424)
Fractured block found during backing up datafile
Data in bad block:
type: 6 format: 2 rdba: 0x02489110
last change scn: 0x0007.a9d2831f seq: 0x1 flg: 0x06
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0xe6b90601
check value in block header: 0x8c60
computed block checksum: 0x82af
Reread of blocknum=561424, file=/data/oracle/oradata/yhddb1/md_data01.dbf. found valid data

这个情况在9i比较常见,rman备份时datafile 正在处在剧烈的io操作,如大批量的写入等等,oracle判断此块为Fractured,但是这并不是真正意义上的Corrupt

oracle会再次check这个块 ‘Reread of blocknum=561424, file=/data/oracle/oradata/yhddb1/md_data01.dbf. found valid data’ 发现这个块是valid的,数据库版本是11.2.0.3

[oracle@rac03 ~]$ crontab -l
0 03 * * 2 sh /home/oracle/monitor/script/rman_level0.sh >> /home/oracle/monitor/script/rman_level0.log
0 03 * * 0,1,3,4,5,6 sh /home/oracle/monitor/script/rman_level1.sh >> /home/oracle/monitor/script/rman_level1.log

rman备份确实是放在3点左右,和alert log 中的时间相吻合

由此发现在11g中我们还是建议rman备份尽量不要放在数据库繁忙的阶段

reference:

fact: Oracle Server – Enterprise Edition 8
fact: Oracle Server – Enterprise Edition 9
fact: Recovery Manager (RMAN)
symptom: Fractured block found during backup up datafile
symptom: Reread of blocknum found some corrupt data
symptom: Analyze table validate structure cascade returns no errors
change: NOTE ROLE:

The messages are of the form

Reread of blocknum=36256, file=/pdscdata/pdsclive/data1/dispatch_data_large2.
dbf. found same corrupt data
***
Corrupt block relative dba: 0xfc008dc0 (file 63, block 36288)
Fractured block found during backing up datafile
Data in bad block –
type: 0 format: 0 rdba: 0x00000000
last change scn: 0x0000.00000000 seq: 0x0 flg: 0x00
consistency value in tail: 0x53494e53
check value in block header: 0x0, block checksum disabled
spare1: 0x0, spare2: 0x0, spare3: 0x0
cause: RMAN backups of datafile are being performed while the datafile is
involved in heavy I/O.

RMAN reads Oracle blocks from disk. If it finds that the block is fractured,
which means it is being actively used, it performs a reread of the block. If
that fails again then the block is assumed to be corrupt.

By identifying the object that these blocks belong to by following
Handling Oracle Block Corruptions in Oracle7/8/8i and
performing an analyze .. validate structure cascade on the object involved you
can confirm that
the object is not corrupt.

fix:

Run the backups when the tablespace has less I/O activity.

[转] 11g Release 2 RMAN Backup Compression

December 16, 2011 11g, backup, oracle No comments

11g Release 2 RMAN Backup Compression
Oracle 11g Release 2 introduced compression algorithm levels which can be used for compressing table data, Data Pump exports and RMAN backups as well.

The compression levels are BASIC, LOW, MEDIUM and HIGH and each affords a trade off related to backup througput and the degree of compression afforded.

To use this option, we can run the following RMAN commands

RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;

followed by ..

RMAN> CONFIGURE COMPRESSION ALGORITHM ‘HIGH’;
or
RMAN> CONFIGURE COMPRESSION ALGORITHM ‘MEDIUM’;
or
RMAN> CONFIGURE COMPRESSION ALGORITHM ‘LOW’;
or
RMAN> CONFIGURE COMPRESSION ALGORITHM ‘BASIC’;

Tests carried out on a small 1.5 GB database returned compression ratios of about 4.7 at best case. However, it should be noted that use of LOW, MEDIUM and HIGH requires the Advanced Compression license. The backupset size and backup durations are shown below.

Compression Level ‘HIGH’

backupset size: 226.18M
time: 00:02:21

Compression Level ‘Medium’

backupset size: 293.80M
time: 00:00:30

Compression Level ‘Low’

backupset size: 352.59M
time: 00:00:20

Compression Level ‘Basic’

backupset size: 276.55M
time: 00:00:50

To summarise we can conclude:

LOW – corresponds to LZO (11gR2) – smallest compression ratio, fastest
MEDIUM – corresponds to ZLIB (11gR1) – good compression ratio, slower than LOW
HIGH – corresponds to unmodified BZIP2 (11gR2) – highest compression ratio, slowest
BASIC (which is free) – corresponds to BZIP2 (10g style compression) – compression ratio in the range of MEDIUM, but slower

reference:http://gavinsoorma.com/2009/12/11g-release-2-rman-backup-compression/

NBU 异机恢复测试

October 19, 2011 backup 8 comments

一、搭建恢复测试环境

安装操作系统
操作系统安装,过程略

硬件配置:
# hostname
nbutest
#prtconf
System Model: IBM,7026-B80
Machine Serial Number: 10960AF
Processor Type: PowerPC_POWER3
Number Of Processors: 1
Processor Clock Speed: 375 MHz
CPU Type: 64-bit
Kernel Type: 64-bit
LPAR Info: -1 NULL
Memory Size: 4096 MB
Good Memory Size: 4096 MB
Firmware Version: IBM,NAN02254
Console Login: enable
Auto Restart: true
Full Core: false

连接好带机,保证在OS上看到带机
# cfgmgr -v
# lsdev -Cc tape
rmt0 Available 10-89-00-0,0 Other SCSI Tape Drive
安装oracle软件
仅安装oracle软件即可,安装过程略
安装NBU软件
此次恢复测试,Master Server和Media Server在同一台机器上,也作为恢复的的Client,Hostname:nbutest

安装PBX组建,过程略
安装Master Server,过程略
允许异机恢复,手动创建如下文件:

# mkdir –p /usr/openv/netbackup/db/altnames
# touch /usr/openv/netbackup/db/altnames/No.Restrictions

二、在Master Server上导入磁带信息

Initiate Import
a)安装NBU并配置好磁带库后,将需要恢复的磁带装入带机,用如下命令找出MediaID,(黄底红字突出部分):
# vmoprcmd -d
PENDING REQUESTS

DRIVE STATUS
Drv Type Control User Label RecMID ExtMID Ready Wr.Enbl. ReqId
0 hcart3 AVR Yes A00003 A00003 Yes Yes 0
ADDITIONAL DRIVE STATUS
Drv DriveName Shared Assigned Comment
0 IBM.ULT3580-TD3.000 No nbutest
b)进入NBU图形管理界面(定义好图形显示后,命令行输入:jnbSA)点击catalogactionsinitialize import,选择media server和media server名称,都是nbutest,,media id为上一步所看到的点击A00003,点击OK:

c)在results界面可看到如下输出,表示initialzie import成功完成

Import for phase2

a)完成initialzie import后,进入NBU管理界面,进入CatalogSearch界面,Media ID:A00003,Media Host:nbutest,点击Search Now,即可看到磁带上所列出的备份集,可以看出备份集ID号,备份日期,Policy名称等信息。通过以上信息可看出数据库SID为“ganso”,客户端hostname为“ncdb”

b)选择需要导入的备份集,点击ActionImport,执行import for phase 2

c)在result内可以看到如下输出,表示第二阶段import成功

配置Master Server

根据上述信息更改Master Server文件$INSTALL_PATH/netbackup/bp.conf加入CLIENT_NAME
# more /usr/openv/netbackup/bp.conf
SERVER = nbutest
#CLIENT_NAME = nbutest
EMMSERVER = nbutest
VXDBMS_NB_DATA = /usr/openv/db/data
FORCE_RESTORE_MEDIA_SERVER = ncdb nbutest
KEEP_JOBS_SUCCESSFUL_HOURS = 720
KEEP_JOBS_HOURS = 720
CLIENT_NAME = ncdb

List Backupset

Import完成后,在OS命令行列出备份集,找出最新的控制文件备份时间,控制文件备份集以CNTRL命名,如下所示,最新的控制文件为“/cntrl_2820_1_737084401”
# bplist -C ncdb -t 4 -l -R / |more
-rw-rw—- oracle dba 11534336 Dec 07 01:41 /c-3123115829-20101207-02
-rw-rw—- oracle dba 11534336 Dec 07 01:40 /cntrl_2820_1_737084401
-rw-rw—- oracle dba 11534336 Dec 07 01:39 /c-3123115829-20101207-01
-rw-rw—- oracle dba 1099008K Dec 07 01:38 /al_2818_1_737084249
-rw-rw—- oracle dba 1839360K Dec 07 01:36 /al_2817_1_737084171
-rw-rw—- oracle dba 1842944K Dec 07 01:35 /al_2816_1_737084093
-rw-rw—- oracle dba 1846528K Dec 07 01:34 /al_2815_1_737084015
-rw-rw—- oracle dba 1847552K Dec 07 01:32 /al_2814_1_737083938
-rw-rw—- oracle dba 1847552K Dec 07 01:31 /al_2813_1_737083860
-rw-rw—- oracle dba 1848320K Dec 07 01:30 /al_2812_1_737083782
-rw-rw—- oracle dba 1860096K Dec 07 01:29 /al_2811_1_737083704
-rw-rw—- oracle dba 1863424K Dec 07 01:27 /al_2810_1_737083626
-rw-rw—- oracle dba 1864448K Dec 07 01:26 /al_2809_1_737083548
-rw-rw—- oracle dba 1873408K Dec 07 01:25 /al_2808_1_737083471
-rw-rw—- oracle dba 1873920K Dec 07 01:23 /al_2807_1_737083393
-rw-rw—- oracle dba 1874944K Dec 07 01:22 /al_2806_1_737083315
-rw-rw—- oracle dba 1878272K Dec 07 01:21 /al_2805_1_737083236
-rw-rw—- oracle dba 11534336 Dec 07 01:20 /c-3123115829-20101207-00
-rw-rw—- oracle dba 11299328K Dec 07 01:16 /bk_2803_1_737082953
-rw-rw—- oracle dba 16299520K Dec 07 01:12 /bk_2802_1_737082717
-rw-rw—- oracle dba 12037632K Dec 07 01:09 /bk_2801_1_737082512
-rw-rw—- oracle dba 15558400K Dec 07 01:05 /bk_2800_1_737082287
-rw-rw—- oracle dba 21886208K Dec 07 01:01 /bk_2799_1_737082041
-rw-rw—- oracle dba 22318592K Dec 07 00:57 /bk_2798_1_737081796
-rw-rw—- oracle dba 22435584K Dec 07 00:53 /bk_2797_1_737081551
-rw-rw—- oracle dba 22507520K Dec 07 00:49 /bk_2796_1_737081305
-rw-rw—- oracle dba 20962048K Dec 07 00:44 /bk_2795_1_737081060
-rw-rw—- oracle dba 21911296K Dec 07 00:40 /bk_2794_1_737080815
-rw-rw—- oracle dba 15301632K Dec 07 00:36 /bk_2793_1_737080560
-rw-rw—- oracle dba 10469120K Dec 07 00:33 /bk_2792_1_737080364
-rw-rw—- oracle dba 19256576K Dec 07 00:29 /bk_2791_1_737080129
-rw-rw—- oracle dba 19493632K Dec 07 00:25 /bk_2790_1_737079904
-rw-rw—- oracle dba 14061824K Dec 07 00:22 /bk_2789_1_737079688
-rw-rw—- oracle dba 18097920K Dec 07 00:17 /bk_2788_1_737079443
-rw-rw—- oracle dba 17497088K Dec 07 00:14 /bk_2787_1_737079208
-rw-rw—- oracle dba 20541184K Dec 07 00:10 /bk_2786_1_737078973
-rw-rw—- oracle dba 20864000K Dec 07 00:06 /bk_2785_1_737078727
-rw-rw—- oracle dba 21061888K Dec 07 00:02 /bk_2784_1_737078492
-rw-rw—- oracle dba 17445120K Dec 06 23:58 /bk_2783_1_737078277
-rw-rw—- oracle dba 16711168K Dec 06 23:54 /bk_2782_1_737078052
-rw-rw—- oracle dba 23290368K Dec 06 23:50 /bk_2781_1_737077806
-rw-rw—- oracle dba 20784640K Dec 06 23:46 /bk_2780_1_737077571
—————————–以下输出截断—————————————————

三、Oracle数据库恢复

创建以ganso为SID的库
可以用DBCA以ORACLE_SID=ganso建一个数据库,以获取pfile文件,或者以其他方式获得pfile均可,方法很多。
并将数据库启动至nomount状态
$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.1.0 – Production on Fri Apr 8 21:52:59 2011
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup nomount
ORACLE instance started.
Total System Global Area 1258291200 bytes
Fixed Size 2020552 bytes
Variable Size 318769976 bytes
Database Buffers 922746880 bytes
Redo Buffers 14753792 bytes
恢复控制文件
以oracle用户登录,进入rman,恢复后将控制文件/tmp目录
$ rman target /
Recovery Manager: Release 10.2.0.4.0 – Production on Wed Apr 6 13:19:05 2011
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: BILLDB (DBID=1672191889, not open)
RMAN> run{
2> allocate channel ch1 type sbt;
3> send ‘NB_ORA_CLIENT=ncdb;
4> send ‘NB_ORA_SERV=nbutest;
5> restore controlfile to ‘/tmp/controlfile_ganso.ctl’ from ‘/cntrl_2820_1_737084401’;
6> release channel ch1;
7> }
copy至pfile里定义的目录和名称
$ cp /tmp/controlfile_ganso.ctl /oracle/ganso/control01.ctl
$ cp /tmp/controlfile_ganso.ctl /oracle/ganso/control02.ctl
$ cp /tmp/controlfile_ganso.ctl /oracle/ganso/control03.ctl
建立好oracle目录结构
将oracle启动至mount状态,利用report schema查看数据库目录结构
RMAN>sql ‘alter database mount’;
RMAN> report schema;

using target database control file instead of recovery catalog
RMAN-06139: WARNING: control file is not current for REPORT SCHEMA
Report of database schema
List of Permanent Datafiles
===========================
File Size(MB) Tablespace RB segs Datafile Name
—- ——– ——————– ——- ————————
1 800 SYSTEM *** /oradata/oradata/system01.dbf
2 5120 NNC_DATA03 *** /oradata/oradata/nnc_data03m.dbf
3 1560 SYSAUX *** /oradata/oradata/sysaux01.dbf
4 0 USERS *** /oradata/oradata/users01.dbf
5 3072 NNC_DATA01 *** /oradata/oradata/nnc_data01.dbf
6 0 NNC_DATA02 *** /oradata/oradata/nnc_data02.dbf
7 3072 NNC_DATA03 *** /oradata/oradata/nnc_data03.dbf
8 2000 NNC_INDEX01 *** /oracle/oradata/nnc_index01.dbf
9 5120 NNC_INDEX02 *** /oracle/oradata/nnc_index02.dbf
10 3072 NNC_INDEX03 *** /oracle/oradata/nnc_index03.dbf
11 500 IUFO50 *** /oradata/oradata/IUFO50
12 3072 NNC_INDEX03 *** /oracle/oradata/nnc_index0301.dbf
13 3072 NNC_DATA01 *** /oradata/oradata/nnc_data01a.dbf
14 1000 NNC_INDEX01 *** /oracle/oradata/nnc_index01a.dbf
15 3072 NNC_DATA01 *** /oradata/oradata/nnc_data01b.dbf
16 3072 NNC_DATA03 *** /oracle/oradata/nnc_data03a.dbf
17 3872 NNC_DATA01 *** /oradata/oradata/nnc_data01c.dbf
18 0 NNC_DATA01 *** /oradata/oradata/nnc_data01d.dbf
19 5372 NNC_DATA03 *** /oradata/oradata/nnc_data03b.dbf
—————————–以下输出截断———————————————————————

根据上面输出建立好oracle目录
$mkdir –p /oradata/oradata
$mkdir –p /oracle/oradata
$mkdir –p /fooddata/oradata
$mkdir –p /middata/oradata
恢复数据文件
进行数据库restore:
RMAN> run{
2> allocate channel ch0 type sbt_tape;
3> send ‘NB_ORA_CLIENT=ncdb;
4> send ‘NB_ORA_SERV=nbutest;
5> restore database;
6> recover database;
7> release channel ch0;
8> }
数据文件恢复没有报错,但是由于文件系统空间不够,无法完成全部数据文件的恢复
Set newname方式恢复数据文件
由于nbutest空间不够,在另外一台机器上隐射一个NFS文件系统至nbutest,将剩余的数据文件恢复至NFS目录/u03,并在/u03目录下建立好对应目录以便于区分
$ df –g
Filesystem GB blocks Free %Used Iused %Iused Mounted on
/dev/hd4 4.00 2.18 46% 18337 4% /
/dev/hd2 2.12 1.09 49% 26093 10% /usr
/dev/hd9var 0.50 0.02 97% 428 9% /var
/dev/hd3 0.44 0.21 52% 3721 7% /tmp
/dev/hd1 0.06 0.06 1% 8 1% /home
/proc – – – – – /proc
/dev/hd10opt 0.50 0.16 68% 923 3% /opt
/dev/nbulv 16.88 11.90 30% 5597 1% /usr/openv
/dev/oralv02 103.00 3.09 97% 17115 3% /oracle
/dev/oralv03 3.00 2.22 27% 12 1% /oralog
/dev/oralv01 425.00 6.88 99% 89 1% /oradata
/dev/oralv04 93.12 5.59 94% 33 1% /orapdata
/dev/oralv05 15.00 11.00 27% 5 1% /fooddata
/dev/oralv06 15.00 4.00 74% 8 1% /middata
/dev/oralv07 35.00 4.99 86% 5 1% /orapidx
55a:/u02 118.00 6.12 95% 37 1% /u03
55a:/u01/NFStoNBU 136.56 102.31 26% 28333 1% /u04

根据V$datafile_header视图找出没有完成恢复的数据文件,如下看出还有27个数据文件需要恢复
SQL> select file# from v$datafile_header where CHECKPOINT_CHANGE#=0;
FILE#
4
6
18
23
24
27
31
39
46
53
54
63
69
77
79
83
84
89
123
124
127
128
158
159
160
161
167
27 rows selected.

准备restore datafile脚本
$ cat restore_setnewname.sh
run{
allocate channel ch1 type sbt;
send ‘NB_ORA_CLIENT=ncdb’;
send ‘NB_ORA_SERV=nbutest’;
set newname for datafile 4 to ‘/u03/ganso/oradata/oradata/users01.dbf’;
set newname for datafile 6 to ‘/u03/ganso/oradata/oradata/nnc_data02.dbf’;
set newname for datafile 18 to ‘/u03/ganso/oradata/oradata/nnc_data01d.dbf’;
set newname for datafile 23 to ‘/u03/ganso/oradata/oradata/nnc_data01e.dbf’;
set newname for datafile 24 to ‘/u03/ganso/oracle/oradata/oraindex/nnc_index0301a.dbf’;
set newname for datafile 27 to ‘/u03/ganso/oradata/oradata/sys01.dbf’;
set newname for datafile 31 to ‘/u03/ganso/oracle/oradata/oraindex/nnc_index0301b.dbf’;
set newname for datafile 39 to ‘/u03/ganso/oradata/oradata/nnc_data01k.dbf’;
set newname for datafile 46 to ‘/u03/ganso/oradata/oradata/nnc_index0301s.dbf’;
set newname for datafile 53 to ‘/u03/ganso/oradata/oradata/nnc_data0101s.dbf’;
set newname for datafile 54 to ‘/u03/ganso/fooddata/anfod1.ora’;
set newname for datafile 63 to ‘/u03/ganso/oradata/oradata/nnc_index0301k.dbf’;
set newname for datafile 69 to ‘/u03/ganso/oracle/oradata/nnc_index0201.dbf’;
set newname for datafile 77 to ‘/u03/ganso/oradata/oradata/nnc_data01x.dbf’;
set newname for datafile 79 to ‘/u03/ganso/oradata/oradata/nnc_data01y.dbf’;
set newname for datafile 83 to ‘/u03/ganso/oradata/oradata/nnc_data01ab.dbf’;
set newname for datafile 84 to ‘/u03/ganso/oradata/oradata/nnc_data01ac.dbf’;
set newname for datafile 89 to ‘/u03/ganso/orapdata/pdat_301.dbf’;
set newname for datafile 123 to ‘/u03/ganso/oracle/oradata/oraindex/nnc_index01k.dbf’;
set newname for datafile 124 to ‘/u03/ganso/oracle/oradata/oraindex/nnc_index01l.dbf’;
set newname for datafile 127 to ‘/u03/ganso/oradata/oradata/nnc_data03l.dbf’;
set newname for datafile 128 to ‘/u03/ganso/oradata/oradata/nnc_data01ae.dbf’;
set newname for datafile 158 to ‘/u03/ganso/oradata/oradata/nnc_index0301y.dbf’;
set newname for datafile 159 to ‘/u03/ganso/oradata/oradata/nnc_index0301z.dbf’;
set newname for datafile 160 to ‘/u03/ganso/oradata/oradata/nnc_data0101x.dbf’;
set newname for datafile 161 to ‘/u03/ganso/oradata/oradata/nnc_data0101y.dbf’;
set newname for datafile 167 to ‘/u03/ganso/oradata/oradata/nnc_data03r.dbf’;
restore datafile 4;
restore datafile 6;
restore datafile 18;
restore datafile 23;
restore datafile 24;
restore datafile 27;
restore datafile 31;
restore datafile 39;
restore datafile 46;
restore datafile 53;
restore datafile 54;
restore datafile 63;
restore datafile 69;
restore datafile 77;
restore datafile 79;
restore datafile 83;
restore datafile 84;
restore datafile 89;
restore datafile 123;
restore datafile 124;
restore datafile 127;
restore datafile 128;
restore datafile 158;
restore datafile 159;
restore datafile 160;
restore datafile 161;
restore datafile 167;
switch datafile all;
release channel ch1;
}
恢复archive log
因为空间不足,无法全部恢复archivelog,只能做一下恢复测试,recover database看看最先需要的archivelog
RMAN> recover database;
Starting recover at 08-APR-11
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=155 devtype=DISK
starting media recovery
Oracle Error:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: ‘/oradata/oradata/system01.dbf’
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 04/08/2011 19:04:03
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06102: no channel to restore a backup or copy of log thread 1 seq 178601 lowscn 3967049746
RMAN-06102: no channel to restore a backup or copy of log thread 1 seq 178600 lowscn 3967008680
RMAN-06102: no channel to restore a backup or copy of log thread 1 seq 178599 lowscn 3966963833
RMAN-06102: no channel to restore a backup or copy of log thread 1 seq 178598 lowscn 3966910961

恢复sequence号178598至178601的archivelog
RMAN> run{
2> allocate channel ch0 device type sbt;
3> send ‘NB_ORA_CLIENT=ncdb’;
4> send ‘NB_ORA_SERV=nbutest’;
5> restore archivelog sequence between 178598 and 178601;
6> release channel ch0;
7> }
released channel: ORA_DISK_1
allocated channel: ch0
channel ch0: sid=155 devtype=SBT_TAPE
channel ch0: VERITAS NetBackup for Oracle – Release 6.0 (2005090703)
sent command to channel: ch0
sent command to channel: ch0
channel ch0: starting archive log restore to default destination
channel ch0: restoring archive log
archive log thread=1 sequence=178598
channel ch0: restoring archive log
archive log thread=1 sequence=178599
channel ch0: restoring archive log
archive log thread=1 sequence=178600
channel ch0: restoring archive log
archive log thread=1 sequence=178601
channel ch0: reading from backup piece al_2818_1_737084249
channel ch0: restored backup piece 1
piece handle=al_2818_1_737084249 tag=TAG20101207T012034
channel ch0: restore complete, elapsed time: 00:03:47
Finished restore at 08-APR-11
released channel: ch0

archivelog恢复完成后再执行recover database,显示应用archivelog,并需求sequence号为178602的archivelog。表示archivelog恢复成功,因空间不够,没有继续恢复archivelog。
启动oracle
利用resetlogs参数打开数据库时报错。根据alter日志和trc文件提示,错误为redolog不能打开和undo表空间不存在,重建redo,修改pfile文件里undo信息后再次open数据库,提示需用upgrade选项打开(原因是因为备份的数据库版本是10.2.0.3,而测试库版本是10.2.0.1),使用upgrade选项打开数据库
$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.1.0 – Production on Fri Apr 8 23:17:52 2011
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup upgrade
ORACLE instance started.
Total System Global Area 1258291200 bytes
Fixed Size 2020552 bytes
Variable Size 318769976 bytes
Database Buffers 922746880 bytes
Redo Buffers 14753792 bytes
Database mounted.
Database opened.
验证数据
查看数据库大小
SQL> select sum(bytes)/1024/1024 from dba_segments;

SUM(BYTES)/1024/1024
——————–
653583.75

查看表数量
SQL> select count(*) from dba_tables;
COUNT(*)
8138

查看用户数量
SQL> set pagesize 1000
SQL> select USERNAME from dba_users;
USERNAME
——————————
ANMIDEX
ANMID
ANFOOD
IUFO
TEST
TEMP11
NC5011
SCOTT
MDDATA
TSMSYS
DIP
DBSNMP
SYSMAN
EXFSYS
DMSYS
WMSYS
ORDSYS
XDB
OLAPSYS
SI_INFORMTN_SCHEMA
ORDPLUGINS
MDSYS
CTXSYS
ANONYMOUS
MGMT_VIEW
SYS
SYSTEM
OUTLN
28 rows selected.

统计部分表的count数
SQL> select count(*) from NC5011. SCM_BATCHCODE;
COUNT(*)
———-
529143

Ovpass 创建步骤

October 17, 2011 backup No comments

ovpass创建步骤
1、找出对应的光纤卡(粗体字),此处为fscsi1:
[21:58:27 root@billdg /]# lsdev -C |grep I/O
fscsi0 Available 03-00-02 FC SCSI I/O Controller Protocol Device
fscsi1 Available 05-00-02 FC SCSI I/O Controller Protocol Device
vio0 Available Virtual I/O Bus
[22:00:10 root@billdg /]# lsdev -Cs fcp
rmt0 Available 05-00-02 Other FC SCSI Tape Drive
rmt1 Available 05-00-02 Other FC SCSI Tape Drive
rmt2 Available 05-00-02 Other FC SCSI Tape Drive
rmt3 Available 05-00-02 Other FC SCSI Tape Drive
2、找出scsi_ID和lun_ID(粗体字),此处可多查看几个rmt,可以找到规律。一般机械手的lun_id为0:
[22:00:22 root@billdg /]# odmget -q “name=rmt2” CuAt
CuAt:
name = “rmt2”
attribute = “scsi_id”
value = “0x11000”
type = “R”
generic = “D”
rep = “s”
nls_index = 6

CuAt:
name = “rmt2”
attribute = “lun_id”
value = “0x3000000000000”
type = “R”
generic = “D”
rep = “s”
nls_index = 7
3、以下为billdg和billdb机器的ovpass创建命令
mkdev -c media_changer -s fcp -t ovpass -p fscsi1 -w 0x11000,0
mkdev -c media_changer -s fcp -t ovpass -p fscsi3 -w 0x11000,0

4、/usr/openv/volmgr/bin/driver/mkdev_ovpass
将该命令放在系统启动脚本中,以确保在系统每次启动后都可访问 ovpass 驱动程序设
备文件。

exchange 备份错误

October 17, 2011 backup 2 comments

错误状态:

之前备份都正常,日志正常清除,NBU配置都正常,找不出可更改选项。
备份时报如下错误,且日志不能清除,造成系统空间报警:
2010-9-3 18:32:41 – Error bpbrm(pid=876580) 从客户端 SHHQ-Mail13: 出错 – failure reading file:
Microsoft Information Store:\First Storage Group\Log files (BEDS 0xE000FE7C: )
2010-9-3 18:33:14 – Error bpbrm(pid=876580) 从客户端 SHHQ-Mail13: 出错 – failure reading file:
Microsoft Information Store:\Hua Dong Area\Log files (BEDS 0xE000FEA9: )
2010-9-3 18:38:43 – Error bpbrm(pid=876580) 从客户端 SHHQ-Mail13: 出错 – failure reading file:
Microsoft Information Store:\Manager\Log files (BEDS 0xE000FEA9: )
2010-9-3 18:39:24 – Error bpbrm(pid=876580) 从客户端 SHHQ-Mail13: 出错 – failure reading file:
Microsoft Information Store:\Xi Bei Area\Log files (BEDS 0xE000FEA9: )
2010-9-3 18:39:29 – end writing; write time: 00:06:55
解决方法:

1、用NBU做一次完整独立的Exchange IS的备份
2、用Exchange工具做一次完整的IS的备份。
结果:

对其中一个数据库进行脱机整理后单独备份,成功无报错,日志清除
用exchange自带eseutil工具进行脱机整理后重启服务器,备份恢复正常,日志清除。