达州做网站
大橙子网站建设，新征程启航
为企业提供网站建设、域名注册、服务器等服务
NBUHPUNIXRAC恢复到HPUNIX单机
注意：本文档操作系统环境以HPUX为主，假设要恢复HPUX 上oracle RAC数据库到单机；
漳县网站制作公司哪家好，找创新互联建站！从网页设计、网站建设、微信开发、APP开发、成都响应式网站建设公司等网站项目制作，到程序开发，运营维护。创新互联建站成立与2013年到现在10年的时间，我们拥有了丰富的建站经验和运维经验，来保证我们的工作的顺利进行。专注于网站建设就选创新互联建站。
本文当主要以数据库恢复为主,操作系统安装、数据库安装配置和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结束#######################
本文名称：NBUHPUNIXRAC恢复到HPUNIX单机
当前网址：http://dzwzjz.com/article/gpjhee.html