NBU HP UNIX RAC 恢復到HPUNIX單機

注意:本文檔操做系統環境以HPUX爲主,假設要恢復HPUX 上oracle RAC數據庫到單機; 數據庫

本文當主要以數據庫恢復爲主,操做系統安裝、數據庫安裝配置和NBU客戶端安裝配置忽略; session

要恢復的數據庫信息:

1. 肯定要恢復的數據庫信息,若是數據庫和操做系統能夠正常訪問,則能夠登陸數據庫和操做系統查看和恢復信息相關的信息,若是數據庫甚至是操做系統不可訪問,則能夠參考oracle數據庫信息收集》文檔,裏面記錄了oracle數據庫恢復的相關信息; oracle

2. 爲了確保恢復後的數據庫能夠儘快使用,儘可能減小應用程序的修改,恢復完之後修改主機IP地址和原數據庫地址保持一致; app

準備環境:

1. 根據《oracle數據庫信息收集》文檔,安裝操做系統和數據庫軟件,其中操做系統的版本儘可能相同,數據庫版本則須要一致; less

2. 根據《oracle數據庫信息收集》文檔,掛載合適的存儲,主要是存儲的大小,所掛載的存儲不可小於要恢復的數據庫總容量大小,並配置合適的ASM磁盤組,磁盤組的大小和名稱建議原來同樣,磁盤組的容量能夠大於原磁盤組; dom

3. 在客戶端安裝好NBU client,並保證經過NBU client能夠正常訪問備份文件; ide

恢復步驟:

恢復文件說明:

在操做系統上執行以下命令: spa

/usr/openv/netbackup/bin/bplist -C ZMDB -t 4 -l -R / ,列出數據庫備份信息,此處列出信息忽律,詳細信息可參看《oracle單實例恢復到單實例》文檔。 操作系統

恢復spfile文件:

本文檔選取 c-1996633987-20140902-0e做爲恢復對象,設置數據庫DBID,並把數據庫啓動到nomount狀態: rest

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結束#######################

相關文章
相關標籤/搜索