Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

NBU HPUNIX RAC reverts to HPUNIX stand-alone

2025-02-24 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >

Share

Shulou(Shulou.com)06/01 Report--

Note: the operating system environment of this document is mainly HPUX. Suppose you want to restore the oracle RAC database on HPUX to a stand-alone machine.

This article mainly focuses on database recovery, while operating system installation, database installation configuration and NBU client installation configuration are ignored.

Database information to recover:

1. Determine the database information to recover. If the database and the operating system can be accessed normally, you can log in to the database and the operating system to view the information related to the recovery information. If the database or even the operating system is not accessible, you can refer to the "oracle database information collection" document, which records the information related to the recovery of the oracle database.

two。 In order to ensure that the restored database can be used as soon as possible and minimize the modification of the application program, the modified host IP address is consistent with the original database address after recovery.

Prepare the environment:

1. According to the "oracle Database Information Collection" document, install the operating system and database software, in which the version of the operating system should be the same as possible, and the database version should be consistent.

two。 According to the "oracle Database Information Collection" document, mount the appropriate storage, mainly the storage size, the mounted storage must not be less than the total capacity of the database to be recovered, and configure the appropriate ASM disk group. The size and name of the disk group are the same, and the capacity of the disk group can be larger than that of the original disk group.

3. Install NBU client on the client side and ensure that backup files can be accessed properly through NBU client

Restore steps: restore file instructions:

Execute the following command on the operating system:

/ usr/openv/netbackup/bin/bplist-C ZMDB-t 4-l-R /, lists the backup information of the database. The information is listed here. For more information, please see the document "oracle single instance recovery to single instance".

Restore the spfile file:

This document selects cmur1996633987-20140902-0e as the recovery object, sets the database DBID, and starts the database to nomount state:

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) restore 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 'cMur1996633987-20140902-0e'

Release channel c1

}

Create a pfile and modify the pfile file:

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

Edit pfile:

Create the corresponding directory according to $ORACLE_BASE and $ORACLE_HOME, and delete the RAC parameter. The modified pfile is as follows (for reference only):

* .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'

Create a spfile with the modified pfile:

Shut down the database:

SQL > shutdown immediate

ORA-01507: database not mounted

ORACLE instance shut down.

Start the database to nomount with the new pfile

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

Create a spfile:

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

File created.

Close the database and start the database to the nomount state:

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 >

Restore the control file:

[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

}

Restore database files:

Start the database to the mount status:

RMAN > alter database mount

Database mounted

Restore the data file:

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

}

The following information is for reference only at the end of the recovery:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Archivelog 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.

Open the database:

RMAN > alter database open resetlogs

Database opened

Modify the redo log:

Delete the redo log for thread 2, leaving only the thread1 log group:

Delete the thread 2 log group:

Alter database drop logfile group 4

Alter database drop logfile group 5

Alter database drop logfile group 6

Alter database drop logfile group 8

Add a log group:

Alter database add logfile group 4 ('+ data','data1') size 200m

Note:

If the deletion occurs the following error:

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: onlinelog 8 thread 2:'+ DATA/gbdb/onlinelog/group_8.340.857294711'

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

Disable thread2 and then delete:

Alter database disable thread 2

Finally, the redo log is modified as follows (for reference only):

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

Delete undo tablespaces:

View the undo tablespace:

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

Delete UNDOTBS2, tablespace:

Drop tablespace UNDOTBS2

SQL > drop tablespace UNDOTBS2

Tablespace dropped.

Confirm that the deletion is true:

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

Finally, confirm the database status:

SQL > select open_mode from v$database

OPEN_MODE

-

READ WRITE

Configuration after normal recovery of the database:

Please refer to the "oracle single instance restore to single instance" document

# # end of recovery 20140902 #

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Database

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report