ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 跨平台还原、恢复数据库(Windows->Linux)

跨平台还原、恢复数据库(Windows->Linux)

原创 Linux操作系统 作者:尛样儿 时间:2012-07-29 09:50:25 0 删除 编辑
        这篇文章讨论刚在客户现场完成的一个跨平台的数据库还原与恢复。生产环境是Windows平台的11.2.0.3的单机数据库,新装了一套Linux平台的11.2.0.3单机数据库。由于数据库版本是相同的,且用于测试,所以直接拷贝最新的数据库RMAN备份及部分归档Redo日志恢复到Linux平台即可。下面是完成的还原与恢复步骤:

1.还原数据库:
1).拷贝必要的控制文件、数据文件、归档Redo日志文件备份到Linux服务器。

2).新建或拷贝参数文件,启动到nomount状态。
        参数文件跟数据库的还原与恢复没有太大关系。所以新建或者拷贝,确保参数文件的内容符合Linux平台即可。 

3).还原控制文件:
RMAN > restore controlfile from '/u02/backup/CONTROL_C-1313645298-20120727-00';
RMAN > sql 'alter database mount';

4).编制备份文件目录:
a).删除现有控制文件中的备份目录:
RMAN > delete noprompt backup;

b).新编控制文件备份目录:
RMAN> catalog start with '/u02/backup';

using target database control file instead of recovery catalog
searching for all files that match the pattern /u02/backup

List of Files Unknown to the Database
=====================================
File Name: /u02/backup/ARCH_ORCL_20120727_185
File Name: /u02/backup/CONTROL_C-1313645298-20120727-00
File Name: /u02/backup/ARCH_ORCL_20120727_183
File Name: /u02/backup/ORCL_20120727_184

Do you really want to catalog the above files (enter YES or NO)? yes
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: /u02/backup/ARCH_ORCL_20120727_185
File Name: /u02/backup/CONTROL_C-1313645298-20120727-00
File Name: /u02/backup/ARCH_ORCL_20120727_183
File Name: /u02/backup/ORCL_20120727_184

5).还原数据库:
执行类似下面的命令还原数据库:
RMAN> run{
allocate channel c1 type disk;
allocate channel c2 type disk;
allocate channel c3 type disk;
allocate channel c4 type disk;
set newname for datafile 1   to '/u02/oradata/orcl/SYSTEM01.DBF';
set newname for datafile 2         to '/u02/oradata/orcl/SYSAUX01.DBF';
set newname for datafile 3        to '/u02/oradata/orcl/UNDOTBS01.DBF';
set newname for datafile 4         to '/u02/oradata/orcl/USERS01.DBF';
set newname for datafile 5         to '/u02/oradata/orcl/APACCT.DBF';
set newname for datafile 6         to '/u02/oradata/orcl/APAPPM.DBF';
set newname for datafile 7        to '/u02/oradata/orcl/APBLDBANK.DBF';
set newname for datafile 8         to '/u02/oradata/orcl/APCOMM.DBF';
......
restore database;
release channel c1;
release channel c2;
release channel c3;
release channel c4;
}

6).恢复数据库:
       由于这里只有部分归档Redo日志,只能执行不完全恢复,这里使用RMAN工具完成数据库的恢复操作。

a).查看归档Redo日志情况:
RMAN> list backup of archivelog all;


List of Backup Sets
===================


BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ -------------------
184     2.32M      DISK        00:00:00     2012-07-27 02:01:07
        BP Key: 184   Status: AVAILABLE  Compressed: NO  Tag: TAG20120727T020106
        Piece Name: /u02/backup/ARCH_ORCL_20120727_185

  List of Archived Logs in backup set 184
  Thrd Seq     Low SCN    Low Time            Next SCN   Next Time
  ---- ------- ---------- ------------------- ---------- ---------
  1    353     10145048   2012-07-27 02:00:03 10145836   2012-07-27 02:01:06

BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ -------------------
185     556.91M    DISK        00:00:00     2012-07-27 02:00:03
        BP Key: 185   Status: AVAILABLE  Compressed: NO  Tag: TAG20120727T020003
        Piece Name: /u02/backup/ARCH_ORCL_20120727_183

  List of Archived Logs in backup set 185
  Thrd Seq     Low SCN    Low Time            Next SCN   Next Time
  ---- ------- ---------- ------------------- ---------- ---------
  1    346     9918930    2012-07-26 02:01:06 9973935    2012-07-26 09:20:58
  1    347     9973935    2012-07-26 09:20:58 10024381   2012-07-26 12:48:10
  1    348     10024381   2012-07-26 12:48:10 10073180   2012-07-26 18:00:42
  1    349     10073180   2012-07-26 18:00:42 10100578   2012-07-26 22:00:11
  1    350     10100578   2012-07-26 22:00:11 10114265   2012-07-26 22:01:08
  1    351     10114265   2012-07-26 22:01:08 10136125   2012-07-27 00:18:45
  1    352     10136125   2012-07-27 00:18:45 10145048   2012-07-27 02:00:03

        归档Redo日志中最大的序列号是353。

b).查看现有数据库的状态:

SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
------------------
          10145048

SQL> select checkpoint_change# from v$datafile;

CHECKPOINT_CHANGE#
------------------
          10145599
          10145599
          10145599
          10145599
          10145599
          10145599
          10145599
          10145599
......
36 rows selected.

SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
------------------
          10145048

SQL> select checkpoint_change# from v$datafile_header;

CHECKPOINT_CHANGE#
------------------
                 0
                 0
                 0
                 0
                 0
                 0
                 0
                 0
......
36 rows selected.

         该值是存储在数据文件头中,由于控制文件中保留的还是Windows环境的数据文件位置,所以并不能读取到数据文件头中保存的checkpoint_change#值。

SQL> select checkpoint_change# from v$thread;

CHECKPOINT_CHANGE#
------------------
          10145048

c).恢复数据库:
RMAN> run{
allocate channel c1 type disk;
allocate channel c2 type disk;
set until sequence 354;
recover database;
release channel c1;
release channel c2;
}
      这里我们为了能恢复数据库到一致性的状态,选用sequence的方式,归档Redo日志最大的sequence是353,所以set until sequence需要指定到353+1。

allocated channel: c1
channel c1: SID=1473 device type=DISK

allocated channel: c2
channel c2: SID=1 device type=DISK

executing command: SET until clause

Starting recover at 2012-07-27 18:27:40
released channel: c1
released channel: c2
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 07/27/2012 18:27:40
RMAN-06094: datafile 1 must be restored

        这是由于在控制文件中的数据文件的位置还是Windows环境的位置,所以我们要重建一下控制文件。

d).重建控制文件:
[oracle@dbser1 dbs]$ sql

SQL*Plus: Release 11.2.0.3.0 Production on Fri Jul 27 18:28:04 2012

Copyright (c) 1982, 2011, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
D:\DATA\ORCL\SYSTEM01.DBF
D:\DATA\ORCL\SYSAUX01.DBF
D:\DATA\ORCL\UNDOTBS01.DBF
D:\DATA\ORCL\USERS01.DBF
D:\DATA\ORCL\APACCT.DBF
D:\DATA\ORCL\APAPPM.DBF
D:\DATA\ORCL\APBLDBANK.DBF
D:\DATA\ORCL\APCOMM.DBF
......
36 rows selected.


SQL> alter database  backup controlfile to trace as '/u02/control.txt';

Database altered.

SQL> shutdown immediate
ORA-01109: database not open


Database dismounted.
ORACLE instance shut down.
SQL>
SQL> startup nomount
ORACLE instance started.

Total System Global Area 2.1379E+10 bytes
Fixed Size                  2237776 bytes
Variable Size            2080377520 bytes
Database Buffers         1.9260E+10 bytes
Redo Buffers               36098048 bytes
SQL> CREATE CONTROLFILE REUSE DATABASE "ORCL" RESETLOGS FORCE LOGGING ARCHIVELOG
  2      MAXLOGFILES 16
  3      MAXLOGMEMBERS 3
  4      MAXDATAFILES 1000
  5      MAXINSTANCES 8
  6      MAXLOGHISTORY 292
  7  LOGFILE
  8    GROUP 1 '/u02/oradata/orcl/REDO01.LOG'  SIZE 128M BLOCKSIZE 512,
  9    GROUP 2 '/u02/oradata/orcl/REDO02.LOG'  SIZE 128M BLOCKSIZE 512,
 10    GROUP 3 '/u02/oradata/orcl/REDO03.LOG'  SIZE 128M BLOCKSIZE 512
 11  -- STANDBY LOGFILE
 12  DATAFILE
 13    '/u02/oradata/orcl/SYSTEM01.DBF',
 14    '/u02/oradata/orcl/SYSAUX01.DBF',
 15    '/u02/oradata/orcl/UNDOTBS01.DBF',
 16    '/u02/oradata/orcl/USERS01.DBF',
  '/u02/oradata/orcl/APACCT.DBF',
 17    '/u02/oradata/orcl/APAPPM.DBF',
 18   19    '/u02/oradata/orcl/APBLDBANK.DBF',
 20    '/u02/oradata/orcl/APCOMM.DBF',
......
 49  CHARACTER SET ZHS16GBK
 50  ;

Control file created.

SQL>

e).重新编制控制文件中的备份目录:
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@dbser1 dbs]$ rman target /

Recovery Manager: Release 11.2.0.3.0 - Production on Fri Jul 27 18:32:11 2012

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: ORCL (DBID=1313645298, not open)

RMAN> catalog start with '/u02/backup';

using target database control file instead of recovery catalog
searching for all files that match the pattern /u02/backup

List of Files Unknown to the Database
=====================================
File Name: /u02/backup/ARCH_ORCL_20120727_185
File Name: /u02/backup/CONTROL_C-1313645298-20120727-00
File Name: /u02/backup/ARCH_ORCL_20120727_183
File Name: /u02/backup/ORCL_20120727_184

Do you really want to catalog the above files (enter YES or NO)? yes
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: /u02/backup/ARCH_ORCL_20120727_185
File Name: /u02/backup/CONTROL_C-1313645298-20120727-00
File Name: /u02/backup/ARCH_ORCL_20120727_183
File Name: /u02/backup/ORCL_20120727_184

f).恢复数据库:
RMAN> run{
2> set until sequence 354;
3> recover database;
4> }

executing command: SET until clause

Starting recover at 2012-07-27 18:32:51
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1473 device type=DISK

starting media recovery

channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=353
channel ORA_DISK_1: reading from backup piece /u02/backup/ARCH_ORCL_20120727_185
channel ORA_DISK_1: piece handle=/u02/backup/ARCH_ORCL_20120727_185 tag=TAG20120727T020106
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archived log file name=/u02/fast_recovery_area/ORCL/archivelog/2012_07_27/o1_mf_1_353_814vlr4f_.arc thread=1 sequence=353
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 07/27/2012 18:33:03
RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile '/u02/fast_recovery_area/ORCL/archivelog/2012_07_27/o1_mf_1_353_814vlr4f_.arc'
ORA-10562: Error occurred while applying redo to data block (file# 2, block# 124805)
ORA-10564: tablespace SYSAUX
ORA-01110: data file 2: '/u02/oradata/orcl/SYSAUX01.DBF'
ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 84284
ORA-00600: internal error code, arguments: [ktbair2_0], [154], [64], [], [], [], [], [], [], [], [], []

g).查看恢复后的数据库状态:
SQL> select checkpoint_change# from v$datafile_header;

CHECKPOINT_CHANGE#
------------------
          10145603
          10145603
          10145603
          10145603
          10145603
          10145603
          10145603
          10145603
......
36 rows selected.

        序列号353的归档Redo日志的SCN号在10145048~10145836之间,现在数据文件头中的信息在此范围内,说明数据文件已经应用了353的归档Redo日志。

SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
------------------
                 0

SQL> select last_change# from v$datafile;

LAST_CHANGE#
------------








........
36 rows selected.

        由于控制文件被重建,存储在其中的checkpoint_change#信息全部都没了。

h).打开数据库:
SQL> alter database open resetlogs;

Database altered.

SQL> select status from v$instance;

STATUS
------------
OPEN

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/23135684/viewspace-738088/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
Oracle数据库管理员,Oracle数据库系统构架员;2012年7月出版《构建最高可用Oracle数据库系统:Oracle 11gR2 RAC管理、维护与性能优化》一书;Oracle 10g OCM。

注册时间:2010-01-05

  • 博文量
    483
  • 访问量
    5259511