利用BCV备份恢复SAP 的Oracle DB步骤

hailai

　　有个server每天进行BCV备份，再把BCV数据备份到磁带。
这里讲的是从磁带restore数据到测试机之后进行recovery的步骤。
　　※ 构成环境的说明
　　▶ 一般情况下，在利用BCV恢复DB的时候，使用的control file是 snap shot control file（即进行Business Copy的时候直接拷贝过来的control file）。但是在数据量多的时候，进行Business Copy的control file之间会有时间差，因此为了以防万一，可以考虑现生成control file的方式进行DB恢复的方法。
　　▶ BCV backup涉及到的 file system有：datafile, online redolog, oracle home, archive directory, interf 等 NFS 共享目录
　　1．BCV file system mount
　　用bdf 命令确认 file system 是否被mount 上。
　　2．检查用户信息以及环境文件
　　- Ora用户以及adm用户使用的shell为/usr/bin/csh。
　　- 检查$ORACLE_HOME目录下的文件所属owner和group。
　　- 检查sap相关目录下的文件所属owner和group。（这里可以省略）
　　- 检查ora和adm下的环境文件，主要是修改文件名的hostname，.dbenv_.csh， .sapenv_.csh 等。
　　- 最后用env命令查看oracle、sap相关环境变量配置是否正确。
　　- 修改listener.Log ， tnsnames.Ora, protocol.ora 中的hostname。
　　3. archive file restore
　　确认Business Copy时候begin backup到end backup的alertlog，并从磁带restore archive file到disk。
　　4．恢复并启动oracle
　　4-1．各Control file的版本（即control file之间无时间差）一致时的恢复,此时的恢复比较简单，只要有截止end backup的archive log全就可以直接进行恢复。
:ora 36> sqlplus internal
SQL> startup
ORACLE instance star.
Total System Global Area 1570585064 bytes
Fixed Size 104936 bytes
Variable Size 815497216 bytes
Database Buffers 734003200 bytes
Redo Buffers 20979712 bytes
Database moun.
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/oracle//sapdata1/system_1/system.data1'
SQL> recover database [oracle自己适用刚好能open的archive logfile]
Media recovery complete.
SQL> alter database open;
Database altered.
　　4-2．Control file的版本不一致时的DB恢复
　　$ ora> sqlplus internal
　　SQL> startup nomount (snapshot controlfile )
　　出现control file版本不一致的错误，如下:
　　ex) ORA-00214: controlfile '/oracle//817_64/dbs/cntrl.dbf' version 14572430
　　inconsistent with file '/oracle//sapdata1/cntrl/cntrl.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 &quot;&quot; NORESETLOGS ARCHIVELOG
MAXLOGFILES 255
MAXLOGMEMBERS 3
MAXDATAFILES 800
MAXINSTANCES 50
MAXLOGHISTORY 36756LOGFILE
GROUP 1 (
'/oracle//origlogA/log_g1m1.dbf',
'/oracle//mirrlogA/log_g1m2.dbf'
) SIZE 350M,
...
　　
　　# 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无问题。