NBU HP UNIX RAC 恢复到HPUNIX单机
admin
2023-04-17 14:02:18
0

注意:本文档操作系统环境以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结束#######################

相关内容

热门资讯

缺油!日本快撑不住了 日本零食巨头卡乐比为节省油墨竟将原本漂亮的包装改成了黑白两色,从“喜食”变得看上去像“丧食”。日本石...
英国首相斯塔默再遭逼宫,在内阁... 【文/观察者网 熊超然】在上周经历地方选举惨败后,作为执政党领袖的英国首相斯塔默于当地时间5月11日...
日防相声称:新西兰考虑进口日本... 据凤凰卫视报道,5月12日,日本防卫大臣小泉进次郎在记者会上表示,新西兰已将日本海上自卫队最上型改良...
小米YU7 GT“车厘子红”无... 5 月 12 日消息,博主 @王的男人、昨日晒出了小米 YU7 GT「车厘子红」实车照片。画面显示,...
中关村论坛重磅发布!大兴机场临... 3月27日,在中关村论坛数据跨境流动创新发展论坛上,北京大兴国际机场临空经济区(大兴)正式发布跨境可...
白宫公布随特朗普访华16位商界... 白宫11日公布了将随特朗普一同访华的商界领袖名单。据多家美媒报道,总共将有16位美国商界代表来到北京...
荣耀申请代码生成方法专利,提高... 国家知识产权局信息显示,南京荣耀软件技术有限公司申请一项名为“代码生成方法、电子设备及存储介质”的专...
凤凰连线:中美新一轮经贸磋商,... 中美双方将在韩国举行第七轮经贸磋商。美方的阵容和日程安排如何?在这轮磋商中有哪些关切?凤凰卫视驻韩国...
知情人士:阿联酋秘密打击伊朗,... 据参考消息援引美国《华尔街日报》网站5月11日报道,多名知情人士透露,阿联酋已对伊朗发动军事打击,令...
美防长称美伊停火协议依然有效 △赫格塞思(资料图)当地时间5月12日,美国国防部长赫格塞思表示,他们针对伊朗问题的所有情况都制定了...