NBU HP UNIX RAC 恢复到HPUNIX单机

注意：本文档操作系统环境以HPUX为主，假设要恢复HPUX 上oracle RAC数据库到单机；

本文当主要以数据库恢复为主,操作系统安装、数据库安装配置和NBU客户端安装配置忽略；

要恢复的数据库信息：

1. 确定要恢复的数据库信息，如果数据库和操作系统可以正常访问，则可以登录数据库和操作系统查看和恢复信息相关的信息，如果数据库甚至是操作系统不可访问，则可以参考《oracle数据库信息收集》文档，里面记录了oracle数据库恢复的相关信息；

2. 为了确保恢复后的数据库可以尽快使用，尽量减少应用程序的修改，恢复完以后修改主机IP地址和原数据库地址保持一致；

准备环境：

1. 根据《oracle数据库信息收集》文档，安装操作系统和数据库软件，其中操作系统的版本尽量相同，数据库版本则需要一致；

2. 根据《oracle数据库信息收集》文档，挂载合适的存储，主要是存储的大小，所挂载的存储不可小于要恢复的数据库总容量大小，并配置合适的ASM磁盘组，磁盘组的大小和名称建议原来一样，磁盘组的容量可以大于原磁盘组；

3. 在客户端安装好NBU client，并保证通过NBU client可以正常访问备份文件；

恢复步骤：

恢复文件说明:

在操作系统上执行如下命令：

/usr/openv/netbackup/bin/bplist -C ZMDB -t 4 -l -R / ，列出数据库备份信息，此处列出信息忽律，详细信息可参看《oracle单实例恢复到单实例》文档。

恢复spfile文件：

本文档选取 c-1996633987-20140902-0e作为恢复对象，设置数据库DBID，并把数据库启动到nomount状态：

connected to target database (not started)

$ rman target /

Recovery Manager: Release 10.2.0.5.0 - Production on Tue Sep 2 10:05:38 2014

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

connected to target database (not started)

RMAN> set DBID=1996633954

executing command: SET DBID

RMAN>

（1）恢复spfile:

RMAN> startup nomount

startup failed: ORA-01078: failure in processing system parameters

LRM-00109: could not open parameter file '/app/oracle/product/10.2.0/db/dbs/initgbdb.ora'

starting Oracle instance without parameter file for retrival of spfile

Oracle instance started

Total System Global Area 159383552 bytes

Fixed Size 2066400 bytes

Variable Size 67110944 bytes

Database Buffers 83886080 bytes

Redo Buffers 6320128 bytes

run

{

allocate channel c1 type 'SBT_TAPE';

send 'NB_ORA_SERV=NBUServer,NB_ORA_CLIENT=bl890s1';

restore spfile from 'c-1996633987-20140902-0e';

release channel c1;

}

创建pfile 修改pfile文件：

create pfile='/app/oracle/product/10.2.0/db/dbs/initgbdb.ora' from spfile;

编辑pfile：

根据$ORACLE_BASE、$ORACLE_HOME创建相应的目录，并且删除掉RAC参数，修改后的pfile如下（仅作参考）：

*.audit_file_dest='/app/oracle/admin/gbdb/adump'

*.background_dump_dest='/app/oracle/admin/gbdb/bdump'

*.compatible='10.2.0.5.0'

*.control_files='+DATA/gbdb/controlfile/current.493.857233793'

*.core_dump_dest='/app/oracle/admin/gbdb/cdump'

*.db_block_size=8192

*.db_domain=''

*.db_file_multiblock_read_count=16

*.db_name='gbdb'

*.dispatchers='(PROTOCOL=TCP) (SERVICE=gbdbXDB)'

*.job_queue_processes=10

*.log_archive_dest_1='LOCATION=+DATA/gbdb/ARCHIVELOG/'

*.open_cursors=300

*.pga_aggregate_target=98283200

*.processes=300

*.remote_login_passwordfile='exclusive'

*.resource_limit=TRUE

*.sessions=335

*.sga_max_size=414748360

*.sga_target=414748360

*.LARGE_POOL_SIZE=214748360

*.undo_management='AUTO'

*.undo_tablespace='UNDOTBS1'

*.user_dump_dest='/app/oracle/admin/gbdb/udump'

用修改过的pfile 创建spfile：

关闭数据库：

SQL> shutdown immediate

ORA-01507: database not mounted

ORACLE instance shut down.

用新的pfile启动数据库到nomount

SQL> startup nomount pfile='/app/oracle/product/10.2.0/db/dbs/initgbdb.ora';

创建spfile：

SQL> create spfile from pfile='/app/oracle/product/10.2.0/db/dbs/initgbdb.ora';

File created.

关闭数据库并启动数据库到nomount状态：

SQL> shutdown immediate

ORA-01507: database not mounted

ORACLE instance shut down.

SQL> startup nomount

ORACLE instance started.

Total System Global Area 4.2446E+10 bytes

Fixed Size 2174824 bytes

Variable Size 3422552216 bytes

Database Buffers 3.9007E+10 bytes

Redo Buffers 14602240 bytes

SQL>

恢复控制文件：

[oracle@bridge ~]$ rman target /

Recovery Manager: Release 10.2.0.5.0 - Production on Wed Aug 27 14:40:44 2014

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

connected to target database: fxzmd (not mounted)

RMAN> run

{

allocate channel c1 type 'SBT_TAPE';

send 'NB_ORA_SERV=NBUServer,NB_ORA_CLIENT=bl890s1';

restore controlfile from 'cntrl_4923_1_857210701';

release channel c1;

}

恢复数据库文件：

启动数据库到mount状态：

RMAN> alter database mount;

database mounted

恢复数据文件：

RMAN> run

{

allocate channel c1 type 'SBT_TAPE';

allocate channel c2 type 'SBT_TAPE';

allocate channel c3 type 'SBT_TAPE';

allocate channel c4 type 'SBT_TAPE';

send 'NB_ORA_SERV=NBUServer,NB_ORA_CLIENT=bl890s1';

restore database;

recover database;

release channel c1;

release channel c2;

release channel c3;

release channel c4;

}

以下信息为恢复结束时候的信息，仅作参考：

archive log filename=+DATA/gbdb/archivelog/1_171159_766064650.dbf thread=1 sequence=171159

archive log filename=+DATA/gbdb/archivelog/1_171160_766064650.dbf thread=1 sequence=171160

archive log filename=+DATA/gbdb/archivelog/2_177002_766064650.dbf thread=2 sequence=177002

archive log filename=+DATA/gbdb/archivelog/1_171161_766064650.dbf thread=1 sequence=171161

archive log filename=+DATA/gbdb/archivelog/2_177003_766064650.dbf thread=2 sequence=177003

archive log filename=+DATA/gbdb/archivelog/1_171162_766064650.dbf thread=1 sequence=171162

archive log filename=+DATA/gbdb/archivelog/2_177004_766064650.dbf thread=2 sequence=177004

archive log filename=+DATA/gbdb/archivelog/1_171163_766064650.dbf thread=1 sequence=171163

archive log filename=+DATA/gbdb/archivelog/2_177005_766064650.dbf thread=2 sequence=177005

archive log filename=+DATA/gbdb/archivelog/1_171164_766064650.dbf thread=1 sequence=171164

archive log filename=+DATA/gbdb/archivelog/2_177006_766064650.dbf thread=2 sequence=177006

archive log filename=+DATA/gbdb/archivelog/1_171165_766064650.dbf thread=1 sequence=171165

archive log filename=+DATA/gbdb/archivelog/2_177007_766064650.dbf thread=2 sequence=177007

archive log filename=+DATA/gbdb/archivelog/1_171166_766064650.dbf thread=1 sequence=171166

archive log filename=+DATA/gbdb/archivelog/2_177008_766064650.dbf thread=2 sequence=177008

archive log filename=+DATA/gbdb/archivelog/1_171167_766064650.dbf thread=1 sequence=171167

unable to find archive log

archive log thread=1 sequence=171168

released channel: c1

released channel: c2

released channel: c3

released channel: c4

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

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

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

RMAN-03002: failure of recover command at 09/02/2014 23:24:04

RMAN-06054: media recovery requesting unknown log: thread 1 seq 171168 lowscn 66130782491

Recovery Manager complete.

打开数据库：

RMAN> alter database open resetlogs;

database opened

修改redo 日志：

删除thread 2的redo日志，只保留thread1日志组：

删除thread 2 日志组：

alter database drop logfile group 4;

alter database drop logfile group 5;

alter database drop logfile group 6;

alter database drop logfile group 8;

添加日志组：

alter database add logfile group 4 ('+data','data1') size 200M;

注意：

如果删除出现如下错误：

SQL> alter database drop logfile group 8;

alter database drop logfile group 8

*

ERROR at line 1:

ORA-01567: dropping log 8 would leave less than 2 log files for instance gbdb2

(thread 2)

ORA-00312: online log 8 thread 2: '+DATA/gbdb/onlinelog/group_8.340.857294711'

ORA-00312: online log 8 thread 2: '+DATA1/gbdb/onlinelog/group_8.269.857294713'

先disable thread2 然后再删除：

alter database disable thread 2;

最后redo日志修改如下（仅作参考）：

SQL> select GROUP#,THREAD#,status,ARCHIVED from v$log;

GROUP# THREAD# STATUS ARC

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

1 1 INACTIVE YES

2 1 INACTIVE YES

3 1 ACTIVE YES

4 1 ACTIVE YES

5 1 CURRENT NO

删除undo表空间：

查看undo表空间：

SQL> select tablespace_name,contents from dba_tablespaces;

TABLESPACE_NAME CONTENTS

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

SYSTEM PERMANENT

UNDOTBS1 UNDO

SYSAUX PERMANENT

TEMP TEMPORARY

USERS PERMANENT

UNDOTBS2 UNDO

ZBWMSD PERMANENT

ZBWMSX PERMANENT

删除UNDOTBS2，表空间：

drop tablespace UNDOTBS2;

SQL> drop tablespace UNDOTBS2;

Tablespace dropped.

确认是否真实删除：

SQL> select tablespace_name,contents from dba_tablespaces;

TABLESPACE_NAME CONTENTS

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

SYSTEM PERMANENT

UNDOTBS1 UNDO

SYSAUX PERMANENT

TEMP TEMPORARY

USERS PERMANENT

ZBWMSD PERMANENT

ZBWMSX PERMANENT

JXSWMSX PERMANENT

JXSWMSD PERMANENT

GROUPREPORT PERMANENT

ZBWMSTEST PERMANENT

最后确认数据库状态：

SQL> select open_mode from v$database;

OPEN_MODE

----------

READ WRITE

数据库正常恢复后配置：

可参考《oracle单实例恢复到单实例》文档；

###############################恢复20140902结束#######################