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

        这篇文章讨论刚在客户现场完成的一个跨平台的数据库还原与恢复。生产环境是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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23135684/viewspace-738088/