• 博客访问: 74402
  • 博文数量: 18
  • 用 户 组: 普通用户
  • 注册时间: 2011-01-01 19:05
个人简介

暂无介绍

文章分类

全部博文(18)

文章存档

2012年(1)

2011年(17)

我的朋友

分类: Linux操作系统

2011-07-06 15:49:23

有个server每天进行BCV备份,再把BCV数据备份到磁带。
这里讲的是从磁带restore数据到测试机之后进行recovery的步骤。

构成环境的说明

一般情况下,在利用BCV恢复DB的时候,使用的control file snap shot control file(即进行Business Copy的时候直接拷贝过来的control file)。但是在数据量多的时候,进行Business Copycontrol file之间会有时间差,因此为了以防万一,可以考虑现生成control file的方式进行DB恢复的方法。

BCV backup涉及到的 file system有:datafile, online redolog, oracle home, archive directory, interf NFS 共享目录

1BCV file system mount

bdf 命令确认 file system 是否被mount 上。

2.检查用户信息以及环境文件

- Ora<SID>用户以及<SID>adm用户使用的shell/usr/bin/csh

- 检查$ORACLE_HOME目录下的文件所属ownergroup

- 检查sap相关目录下的文件所属ownergroup。(这里可以省略)

- 检查ora<SID><SID>adm下的环境文件,主要是修改文件名的hostname.dbenv_<hostname>.csh .sapenv_<hostname>.csh 等。

- 最后用env命令查看oraclesap相关环境变量配置是否正确。

- 修改listener.Log tnsnames.Ora, protocol.ora 中的hostname

3. archive file restore

确认Business Copy时候begin backupend backupalertlog,并从磁带restore archive filedisk

4.恢复并启动oracle

4-1.各Control file的版本(即control file之间无时间差)一致时的恢复,此时的恢复比较简单,只要有截止end backuparchive log全就可以直接进行恢复。

<hostname>:ora<SID> 36> sqlplus internal

SQL> startup

ORACLE instance star<SID>.

Total System Global Area 1570585064 bytes

Fixed Size 104936 bytes

Variable Size 815497216 bytes

Database Buffers 734003200 bytes

Redo Buffers 20979712 bytes

Database moun<SID>.

ORA-01113: file 1 needs media recovery

ORA-01110: data file 1: '/oracle/<SID>/sapdata1/system_1/system.data1'

SQL> recover database [oracle自己适用刚好能openarchive logfile]

Media recovery complete.

SQL> alter database open;

Database altered.

4-2Control file的版本不一致时的DB恢复

$ ora<SID>> sqlplus internal

SQL> startup nomount (snapshot controlfile )

出现control file版本不一致的错误,如下:

ex) ORA-00214: controlfile '/oracle/<SID>/817_64/dbs/cntrl<SID>.dbf' version 14572430

inconsistent with file '/oracle/<SID>/sapdata1/cntrl/cntrl<SID>.dbf' version 14572425

解决方法:利用最新的 control file进行恢复。出现这个错误的原因是由于数据量大,导致Business copy的时候备份的control file之间有版本差异。

SQL> recover database [nomount 状态][auto recovery]

alter database open; [正常启动]

不需要resetlogs option,

如果在mount状态下不能自动进行recovery的时候用以下方法

SQL> recover database until cancel;

适用end backup 之后的几个archive file [可以适用多个archive file]

SQL> alter database open resetlogs;

→ database open

4-3.现备份control file进行恢复

SQL> startup mount

SQL> alter database backup controlfile to trace;

SQL> @controlfile_backup.sql (利用backup controlfile )

SQL> recover database using backup controlfile until cancel;

适用end backup 之后的几个archive fileSQL> alter database open resetlogs;

→ database open

< 备份 control file 的内容 >

# trace file头部的 version 信息部分的内容不需要。

STARTUP NOMOUNTCREATE CONTROLFILE REUSE DATABASE "<SID>" NORESETLOGS ARCHIVELOG

MAXLOGFILES 255

MAXLOGMEMBERS 3

MAXDATAFILES 800

MAXINSTANCES 50

MAXLOGHISTORY 36756LOGFILE

GROUP 1 (

'/oracle/<SID>/origlogA/log_g1m1.dbf',

'/oracle/<SID>/mirrlogA/log_g1m2.dbf'

) SIZE 350M,

... <>

<以下部分也要删除,但是temp file相关部分要保留,此例中没有对temp file的操作 >

# Recovery is required if any of the datafiles are restored backups,

# or if the last shutdown was not normal or immediate.

RECOVER DATABASE

# All logs need archiving and a log switch is needed.

ALTER SYSTEM ARCHIVE LOG ALL;

# Database can now be opened normally.

ALTER DATABASE OPEN;

# No tempfile entries found to add.

#

5. 确认DB是否正常

SQL> select count(*) from dba_users;

COUNT(*)

----------

28

SQL> select count(*) from dba_data_files;

COUNT(*)

----------

545

SQL> select count(*) from dba_data_files;

COUNT(*)

----------

255

SQL> select count(*) from dba_data_files where status NOT LIKE 'AVAILABLE';

COUNT(*)

----------

0

确认DB无问题。



Link URL: http://happyland.itpub.net/post/4163/270096

阅读(2532) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册