沈阳凯文数据恢复中心 服务器数据恢复 勒索病毒数据库修复 小型机数据恢复 13386848847 024-31065488 地址:沈阳市和平区三好街同方广场A座10楼1012写字间

EMC光纤非标硬盘数据恢复技术

2014.1.15,沈阳凯文数据恢复呼叫中心13386848847接到一位金融界的客户电话,EMC的存储,八块光纤硬盘组的RAID5,在国家某数据恢复中心进行过数据恢复操作,但遗憾的是被告知数据无法恢复。问其原因,说是所有的硬盘都不能正常识别。凯文数据恢复技术服务工程师立刻就意识到很可能是EMC的光纤硬盘算法不同导致的不认盘,下面我们看看这个案例。


图一:EMC存储8块450GB光纤硬盘的RAID5

客户类型:某金融财团

存储设备:EMC CX500

EMC CX700 MirrorViewS 实施文档 数据恢复

 

1.EMC MirrorView介绍
MirrorView是基于盘阵之间,以LUN为单位的远程复制软件.适于与CX,CX3系列(CX200,CX300除外),MirrorView分为MirrorView/S(同步),MirrorView/A(异步).enabler分别为MirrorViewEnabler_01.xx.5.yyy.ena, MVAEnabler_01.xx.5.yyy.ena.
2.EMC MirrorView/S实施路线图
- 确认生产盘阵和镜像盘阵之间FLARE版本是否一致(至少大版本要一致).
- 建立生产盘阵和镜像盘阵之间的物理连接,不同型号的盘阵镜像端口(用于做MirrorView的port口)略有不同:
      Port 5 for a CX3-20c or CX3-40c SP

      Port 3 for a CX600, CX700, or CX3-80 SP
      Port 1 for a CX400, CX500, CX3-20, or CX3-40 SP
-启用MirrorView enabler
启用MirrorView enabler需要盘阵无I/O操作
-分配write intent log
  EMC官方建议分配两个128MB的LUN做为write intent log使用.如果不分配write intent log,系统会占用SP的MEM做为write intent log.
-建立MirrorView connection
  由于CX700的SP port口是短波模块,适用与短距离传输,如果要做MirrorView的距离很长,需要通过交换机(交换机之间通过长波模块做级联)用单模光纤线连接(黄色).
-创建remote mirror
  创建MirrorView的源LUN.
-添加secondary image
  关联MirrorView的源LUN和镜像LUN.
-创建consistency group
   如果源LUN之间有关联关系,需要一起添加到consistency group中来保证源LUN间数据的一致性.
-测试MirrorView
   通过promote来转化primary image和secondary image的角色.
   通过fracture来断开primary image和secondary image的同步.

EMC损坏硬盘更换及恢复过程

 更换EMC损坏的磁盘以后,盘阵会自动开始把hot spare备份的数据恢复过来。
然后把启用的hot spare盘恢复到初始备用状态。

我们可以通过命令来观察这一过程,首先看新换上来的硬盘,注意此时的状态为Equalizing,也就是正在进行平衡的过程:

# navicli -h 172.16.9.5 getdisk 1_0_1
Bus 1 Enclosure 0  Disk 1
Vendor Id:               SEAGATE 
Product Id:              ST373307 CLAR72 
Product Revision:        7A0A
Lun:                     6 
Type:                    6: RAID5 
State:                   EqualizingHot Spare:               6: NO 
Prct Rebuilt:            6: 100 
Prct Bound:              6: 100 
Serial Number:           3HZ6TL7F
Sectors:                 139681792 (68204)
Capacity:                68238
Private:                 6: 69704 
Bind Signature:          0x5cf2, 0, 1
Hard Read Errors:        0
Hard Write Errors:       0
Soft Read Errors:        0
Soft Write Errors:       0
Read Retries:     N/A
Write Retries:    N/A
Remapped Sectors:        N/A
Number of Reads:         980562
Number of Writes:        1107168
Number of Luns:          1
Raid Group ID:           3
Clariion Part Number:    DG118032459  
Request Service Time:    N/A
Read Requests:           980562
Write Requests:          1107168
Kbytes Read:             99788880
Kbytes Written:          70098518
Stripe Boundary Crossing: 2704586


此时hot spare盘的状态为Enabled,其替代的硬盘为:1_0_1

Mysql数据库恢复(修复)服务

 

本公司是一家专业从事数据库修复的公司,经过多年对Mysql数据库的修复及研究,已对Mysql数据库的结构研究清楚,自主开发的Mysql数据库修复和Mysql数据库恢复公司,可以直接读取数据库文件提取记录。
 
Mysql数据库修复主要故障有:
 
1.Myisam引擎中丢失MYI文件的数据库修复。
2.Myisam引擎中Myd数据文件损坏的数据库修复。
3.Myisam引擎误删除、Truncate清除表后的数据恢复(由于Myisam引擎机制,数据无法100%恢复)。
4.Myisam引擎误Drop及误删除数据库文件的数据库恢复。
5.Innodb引擎误删除、Truncate清除表后的数据恢复(可做到100%恢复)
6.Innodb引擎中ibdata1数据文件丢失的数据库恢复。
7.由于硬盘坏道造成数据库坏块的数据库修复。
8.由于突然断电造成Mysql数据库错误的修复。
 

其它数据库恢复(修复)服务

 

其它数据库恢复(修复)服务

 本公司是国内专业从事数据恢复公司,多年来,积累了大量案例来研究各种数据库的结构,并开发的许多数据库修复及数据库恢复工具,可对以下数据库进行修复及恢复操作
1、Interbase数据库修复 (.GDB,.IB)7.X
2、FireBird数据库修复(.FDB)2.x
3、Access数据库修复 97,2000.2003,2007,2010,2012
4、MS SQL Server数据库修复 6.5,7.0,2000,2005,2008,2008R2,2012
5、Oracle数据库修复 8I,9I,10G,11G
6、Sybase数据库修复 ASE,ASA,IQ
7、DB2数据库修复 8,9
8、Mysql数据库修复 4.X,5.X
9、PostgreSQL数据库修复
10、Paradox数据库修复
 
此外还可以修复邮件类的数据库,如:Exchange EDB数据库修复,Lotus Notes NSF数据库修复等

SQL Anywhere数据库恢复(修复)服务

 

Sql Anywhere(ASA)数据库是Sybase公司旗下的一款数据库软件,数据库小巧、灵活、方便等特点,使其应用及其广泛。本公司经过多年的研究,对其数据库文件结构了解清楚,并开发了Repair For Sybase Sql Anywher数据库修复工具,可以脱离Sybase环境,对数据库文件进行数据提取。
 
 
可修复Sybase SQL Anywhere(ASA)数据库的故障:
 
1、无日志,只有数据文件的恢复
2、误Delete、Drop、Truncate操作的数据库修复。
3、由于坏块无法启动或无法使用的数据库修复。
4、由于突然断电造成数据库无法启的修复。
5、软件提示“无法连接数据库”的修复 
6、误删除数据文件的数据库恢复。
9、SQL Anywhere各种Assertion failed错误的修复。
    *** ERROR *** Assertion failed: 51901
  Page for requested record not a table page or record not present on page
  *** ERROR *** Assertion failed:201819 (8.0.1.2600)
  Checkpoint log: invalid bitmap page -- transaction rolled back
  *** ERROR *** Assertion failed:201819 (8.0.1.2600)
  Page number on page does not match page requested -- transaction rolled back
  *** ERROR *** Assertion failed:200502 (9.0.2.2451)
  Checksum failure on page 23 -- transaction rolled back。

Sybase数据库恢复(修复)服务

 

Sybase有三大系列数据库,包括Sybase ASE、Sybase Sql Anywhere(Sybase ASA)、Sybase IQ。公司经过大量案例的研究,已掌握了Sybase数据库文件(.dat,.db)内容结构,并相对就的开发的Sybase数据库修复及Sybase数据库恢复工具,可以解决大量Sybase数据库故障。
 
 
可修复Sybase数据库的故障:
 
1、只有数据文件(.dat,.db)的恢复。
2、误Delete、Drop、Truncate操作的数据库修复。
3、Sybase ASE数据库变为suspect(置疑),无法使用的恢复。
4、由于坏块无法启动或无法使用的数据库修复。
5、软件提示“无法连接数据库”的修复 
6、数据库提示“Database 'xx' cannot be opened - it has been marked SUSPECT by recover Explanation”的修复
7、误删除数据文件的数据库恢复。
8、 sybase ASE 各种错误,如823,692,695,697,806等错误修复
9、SQL Anywhere各种Assertion failed错误的修复。
10、Sybase IQ各种IO错误的数据库修复

SQL Server数据库恢复(修复)服务

 

 
本公司经过多年案例及研究,对SQL Server各版本的数据库文件结构研究透彻,成功开始了Recovery For SQL Server数据库修复工具及Rebuild For Sql Server数据库恢复工具,可对SQL Server数据库底层进行数据提取及碎片重组。
 
本公司可解决以下数据库故障:
1. 由于误删除、误格式化、误分区、误Ghost及重装系统导致SQL Server数据库文件丢失
2. 由于日志文件损坏或丢失,只有Sql Server数据文件的恢复
3. 由于坏道造成SQL Server数据库页损坏情况下的恢复。
4. Sql Server数据库由于误操作(Drop Table、Delete、Truncate)删除数据的恢复。
5. SQL Server无法附加,出现823错误等的数据库恢复。
6. Sql Server数据库被标记为“置疑”,无法使用的数据库修复.
7. SQL Server数据库由于系统表操作导致出现“并闩锁页”错误的数据库修复。
8. 由于突然断电造成SQL Server数据库错误,如:系统表损坏、通讯中断、一致性错误、页撕裂、索引断裂、并闩锁页等数据库修复
9. 修复无法还原的SQL Server数据库备份BAK文件
10.SQL Server数据库只有日志数据恢复,即无数据文件的数据恢复。
11.可恢复各种ERP财务软件的数据库,如:用友、金蝶、速达、浪潮、管家婆等SQL Server数据库的修复 。
 
以上故障数据库修复支持SQL Server6.5、SQL Server7.0、SQL Server2000、SQL Server2005、SQL Server6.5、SQL Server2008、SQL Server2008R2、SQL Server2012

Oracle数据库恢复修复服务

 

 本公司专业从事数据库修复,致力于ORACLE数据库修复技术的研究。擅长修复各种版本的ORACLE数据库恢复。经过多年研究完全掌握了ORACLE(8、9、10G、11G)的内部结构。公司自主开发了相关ORACLE数据库恢复及Oracle数据库修复工具,可以恢复误删除的Oracle数据库和修复损坏的oracle数据库文件。
 
oracle数据库修复,主要包括以下故障
 
(1)系统崩溃只剩下数据文件的情况下的恢复。
 
(2) undo system 表空间损坏数据恢复 .
 
(3) 误 delete 数据的恢复、误删除表空间的恢复、 drop 、truncate 表的恢复 .
 
(4) 数据库无法启动,出现的各种ora-错误的修复.
 
(5) DMP文件损坏导致文件不能导入数据库的数据库恢复
 
(6) oracle数据库中数据文件出现坏块情况下的恢复.
 
(7) oracle数据库只有日志的情况下的恢复.
 
(8) UNIX、Linux、WINDOWS下ORACLE数据文件被误删除情况下的数据库恢复.
 
(9) Oracle10G、Oracle11G 的ASM损坏的数据库恢复.
 
(10) Oracle10G、Oracle11G BIFGILE TABLESPACE大文件表空间损坏数据恢复
 
(11) Oracle9i、Oracle10G、Oracle11G压缩表 压缩表空间损坏数据恢复
 
(12)Oracle10G Oracle11G Expdp导出 Impdp导入 DMP文件错误数据恢复
 
本公司可跨平台、快速度、兼容全系列ORACLE数据库版本、可以恢复各种数据表(普通表、压缩表、索引表、簇表、分区表)数据、可以恢复各种数据类型、可以恢复各种数据对象、代码。

incremental backup恢复错误一例

incremental backup恢复错误一例

错误现象:关闭standby数据库,将restore standby controlfile to '/u01/rmanbak/fordg/control01.ctl'恢复出来的控制文件覆盖现有的控制文件,重新启动后出现以下问题:
Sat Mar 23 06:42:37 CST 2013
alter database recover managed standby database disconnect from session using current logfile
Sat Mar 23 06:42:37 CST 2013
Attempt to start background Managed Standby Recovery process (stdby)
MRP0 started with pid=29, OS id=11519
Sat Mar 23 06:42:37 CST 2013
MRP0: Background Managed Standby Recovery process started (stdby)
Sat Mar 23 06:42:37 CST 2013
RFS[2]: Archived Log: '/u01/archivelog/stdby/arc_2_9373_789583539.dbf'
RFS[2]: Archived Log: '/u01/archivelog/stdby/arc_2_9374_789583539.dbf'
RFS[2]: Archived Log: '/u01/archivelog/stdby/arc_2_9375_789583539.dbf'
RFS[2]: Archived Log: '/u01/archivelog/stdby/arc_2_9376_789583539.dbf'
RFS[2]: Archived Log: '/u01/archivelog/stdby/arc_2_9377_789583539.dbf'
RFS[2]: Archived Log: '/u01/archivelog/stdby/arc_2_9378_789583539.dbf'
RFS[2]: Archived Log: '/u01/archivelog/stdby/arc_2_9379_789583539.dbf'
RFS[2]: Archived Log: '/u01/archivelog/stdby/arc_2_9380_789583539.dbf'
Sat Mar 23 06:42:41 CST 2013
RFS[1]: Archived Log: '/u01/archivelog/stdby/arc_1_7751_789583539.dbf'
Sat Mar 23 06:42:42 CST 2013
RFS[2]: Archived Log: '/u01/archivelog/stdby/arc_2_9381_789583539.dbf'
Sat Mar 23 06:42:42 CST 2013
Managed Standby Recovery starting Real Time Apply
Sat Mar 23 06:42:42 CST 2013
Errors in file /u01/app/oracle/admin/stdby/bdump/stdby_dbw0_11458.trc:
ORA-01157: cannot identify/lock data file 24 - see DBWR trace file
ORA-01110: data file 24: '+DATA/in_sz_data'
ORA-17503: ksfdopn:2 Failed to open file +DATA/in_sz_data
ORA-15001: diskgroup "DATA" does not exist or is not mounted
ORA-15077: could not locate ASM instance serving a required diskgroup
ORA-29701: unable to connect to Cluster Manager
Sat Mar 23 06:42:42 CST 2013
Errors in file /u01/app/oracle/admin/stdby/bdump/stdby_dbw0_11458.trc:
ORA-01157: cannot identify/lock data file 25 - see DBWR trace file
ORA-01110: data file 25: '/u01/oradata/stdby/in_sz_data'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
Sat Mar 23 06:42:42 CST 2013
Errors in file /u01/app/oracle/admin/stdby/bdump/stdby_dbw0_11458.trc:
ORA-01157: cannot identify/lock data file 26 - see DBWR trace file
ORA-01110: data file 26: '/u01/oradata/stdby/in_sz_data.9154.810742355'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
Sat Mar 23 06:42:42 CST 2013
Errors in file /u01/app/oracle/admin/stdby/bdump/stdby_dbw0_11458.trc:
ORA-01157: cannot identify/lock data file 27 - see DBWR trace file
ORA-01110: data file 27: '/u01/oradata/stdby/in_ac_data.9090.810742665'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
MRP0: Background Media Recovery terminated with error 1110
Sat Mar 23 06:42:43 CST 2013
Errors in file /u01/app/oracle/admin/stdby/bdump/stdby_mrp0_11519.trc:
ORA-01110: data file 24: '+DATA/in_sz_data'
ORA-01157: cannot identify/lock data file 24 - see DBWR trace file
ORA-01110: data file 24: '+DATA/in_sz_data'
Managed Standby Recovery not using Real Time Apply
Sat Mar 23 06:42:43 CST 2013
Errors in file /u01/app/oracle/admin/stdby/bdump/stdby_mrp0_11519.trc:
ORA-01110: data file 24: '+DATA/in_sz_data'
ORA-01157: cannot identify/lock data file 24 - see DBWR trace file
ORA-01110: data file 24: '+DATA/in_sz_data'
Sat Mar 23 06:42:43 CST 2013
MRP0: Background Media Recovery process shutdown (stdby)
Sat Mar 23 06:42:43 CST 2013
RFS[2]: Archived Log: '/u01/archivelog/stdby/arc_2_9382_789583539.dbf'
分析:因为主库新建过数据文件,从主库恢复过来的控制文件中中包含了这些文件,而从库却没有这些文件。

解决方法:
执行创建文件:
SQL> alter database create datafile '+DATA/in_sz_data' as '/u01/oradata/stdby/in_sz_data.312.789659222';
Database altered.
SQL> alter database create datafile '/u01/oradata/stdby/in_sz_data' as '/u01/oradata/stdby/in_sz_data.312.789659223';
Database altered.
SQL> alter database create datafile '/u01/oradata/stdby/in_sz_data.9154.810742355' as '/u01/oradata/stdby/in_sz_data.312.789659224';
Database altered.
SQL> alter database create datafile '/u01/oradata/stdby/in_ac_data.9090.810742665' as '/u01/oradata/stdby/in_ac_data.9090.810742665';


再次执行恢复:
RMAN> catalog start with '/u01/rmanbak/fordg/';

searching for all files that match the pattern /u01/rmanbak/fordg/

List of Files Unknown to the Database
=====================================
File Name: /u01/rmanbak/fordg/standby_STD_20130323_n9o57oao_1_1.bak
File Name: /u01/rmanbak/fordg/control01.ctl
File Name: /u01/rmanbak/fordg/standby_STD_20130323_nbo57oao_1_1.bak
File Name: /u01/rmanbak/fordg/standby_STD_20130323_nfo57p2c_1_1.bak
File Name: /u01/rmanbak/fordg/standby_STD_20130323_nco57oao_1_1.bak
File Name: /u01/rmanbak/fordg/standby_STD_20130323_nao57oao_1_1.bak
File Name: /u01/rmanbak/fordg/standby_STD_20130323_ngo57p2h_1_1.bak
File Name: /u01/rmanbak/fordg/standby_STD_20130323_ndo57ov7_1_1.bak
File Name: /u01/rmanbak/fordg/standby_STD_20130323_neo57p0b_1_1.bak

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

List of Cataloged Files
=======================
File Name: /u01/rmanbak/fordg/standby_STD_20130323_n9o57oao_1_1.bak
File Name: /u01/rmanbak/fordg/control01.ctl
File Name: /u01/rmanbak/fordg/standby_STD_20130323_nbo57oao_1_1.bak
File Name: /u01/rmanbak/fordg/standby_STD_20130323_nfo57p2c_1_1.bak
File Name: /u01/rmanbak/fordg/standby_STD_20130323_nco57oao_1_1.bak
File Name: /u01/rmanbak/fordg/standby_STD_20130323_nao57oao_1_1.bak
File Name: /u01/rmanbak/fordg/standby_STD_20130323_ngo57p2h_1_1.bak
File Name: /u01/rmanbak/fordg/standby_STD_20130323_ndo57ov7_1_1.bak
File Name: /u01/rmanbak/fordg/standby_STD_20130323_neo57p0b_1_1.bak

RMAN>


RMAN> RMAN> run {  
allocate channel dsk0 type disk;
allocate channel dsk1 type disk;
allocate channel dsk2 type disk;
restore standby controlfile to '/u01/rmanbak/fordg/control01.ctl';
recover database noredo;
}2> 3> 4> 5> 6> 7>

allocated channel: dsk0
channel dsk0: sid=1481 devtype=DISK

allocated channel: dsk1
channel dsk1: sid=1480 devtype=DISK

allocated channel: dsk2
channel dsk2: sid=1479 devtype=DISK

Starting restore at 28-MAR-13

channel dsk0: starting datafile backupset restore
channel dsk0: restoring control file
output filename=/u01/rmanbak/fordg/control01.ctl
channel dsk0: reading from backup piece /u01/rmanbak/fordg/standby_STD_20130323_nfo57p2c_1_1.bak
channel dsk0: restored backup piece 1
piece handle=/u01/rmanbak/fordg/standby_STD_20130323_nfo57p2c_1_1.bak tag=FOR STANDBY
channel dsk0: restore complete, elapsed time: 00:00:05
Finished restore at 28-MAR-13

Starting recover at 28-MAR-13
channel dsk0: starting incremental datafile backupset restore
channel dsk0: specifying datafile(s) to restore from backup set
destination for restore of datafile 00024: /u01/oradata/stdby/in_sz_data.312.789659222
destination for restore of datafile 00025: /u01/oradata/stdby/in_sz_data.312.789659223
destination for restore of datafile 00026: /u01/oradata/stdby/in_sz_data.312.789659224
destination for restore of datafile 00027: /u01/oradata/stdby/in_ac_data.9090.810742665
channel dsk0: reading from backup piece /u01/rmanbak/inc2_STD_n2o572go_1_1
released channel: dsk0
released channel: dsk1
released channel: dsk2
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 03/28/2013 15:37:14
ORA-19870: error reading backup piece /u01/rmanbak/inc2_STD_n2o572go_1_1
ORA-19505: failed to identify file "/u01/rmanbak/inc2_STD_n2o572go_1_1"
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

分析:通过WINDOWS系统FTP上传下载后文件发生了变化,改用NFS传输后恢复正常
顺带下NFS的设置
服务器端:
[root@dgserver stdby]# vi /etc/exports

[1]+  Stopped                 vi /etc/exports
[root@dgserver stdby]# vi /etc/exports
[root@dgserver stdby]# /etc/rc.d/init.d/portmap start
Starting portmap:                                          [  OK  ]
[root@dgserver stdby]# /etc/rc.d/init.d/nfs start
Starting NFS services:                                     [  OK  ]
Starting NFS quotas:                                       [  OK  ]
Starting NFS daemon:                                       [  OK  ]
Starting NFS mountd:                                       [  OK  ]
[root@dgserver stdby]# exportfs -rv
exporting *:/u01/rmanbak
[root@dgserver stdby]#

客户端
[root@oracle1 ~]# showmount -e 192.168.13.109
Export list for 192.168.13.109:
/u01/rmanbak *
[root@oracle1 ~]#




RMAN> run {  
allocate channel dsk0 type disk;
allocate channel dsk1 type disk;
allocate channel dsk2 type disk;
restore standby controlfile to '/u01/rmanbak/fordg/control01.ctl';
recover database noredo;
}2> 3> 4> 5> 6> 7>

allocated channel: dsk0
channel dsk0: sid=1481 devtype=DISK

allocated channel: dsk1
channel dsk1: sid=1480 devtype=DISK

allocated channel: dsk2
channel dsk2: sid=1479 devtype=DISK

Starting restore at 28-MAR-13

control file is already restored to file /u01/rmanbak/fordg/control01.ctl
restore not done; all files readonly, offline, or already restored
Finished restore at 28-MAR-13

Starting recover at 28-MAR-13
channel dsk0: starting incremental datafile backupset restore
channel dsk0: specifying datafile(s) to restore from backup set
destination for restore of datafile 00024: /u01/oradata/stdby/in_sz_data.312.789659222
destination for restore of datafile 00025: /u01/oradata/stdby/in_sz_data.312.789659223
destination for restore of datafile 00026: /u01/oradata/stdby/in_sz_data.312.789659224
destination for restore of datafile 00027: /u01/oradata/stdby/in_ac_data.9090.810742665
channel dsk0: reading from backup piece /u01/rmanbak/inc2_STD_n2o572go_1_1
released channel: dsk0
released channel: dsk1
released channel: dsk2
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 03/28/2013 16:32:26
ORA-19870: error reading backup piece /u01/rmanbak/inc2_STD_n2o572go_1_1
ORA-19573: cannot obtain exclusive enqueue for datafile 26

查询该FILE
SQL> select name from v$datafile where file#=26;

NAME
--------------------------------------------------------------------------------
/u01/oradata/stdby/in_sz_data.312.789659224

SQL>
分析:由于是MOUNT STANDBY方式启动的,决定重启到普通MOUNT状态
SQL> shutdown immediate;
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.

Total System Global Area 1.9327E+10 bytes
Fixed Size                  2130592 bytes
Variable Size            4362079584 bytes
Database Buffers         1.4948E+10 bytes
Redo Buffers               14643200 bytes
Database mounted.
SQL>



[oracle@dgserver ~]$ rman target /

Recovery Manager: Release 10.2.0.5.0 - Production on Thu Mar 28 16:49:28 2013

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

connected to target database: STD (DBID=1656746419, not open)


RMAN> run {  
allocate channel dsk0 type disk;
allocate channel dsk1 type disk;
allocate channel dsk2 type disk;
restore standby controlfile to '/u01/rmanbak/fordg/control01.ctl';
recover database noredo;
}2> 3> 4> 5> 6> 7>

using target database control file instead of recovery catalog
allocated channel: dsk0
channel dsk0: sid=1481 devtype=DISK

allocated channel: dsk1
channel dsk1: sid=1480 devtype=DISK

allocated channel: dsk2
channel dsk2: sid=1479 devtype=DISK

Starting restore at 28-MAR-13

control file is already restored to file /u01/rmanbak/fordg/control01.ctl
restore not done; all files readonly, offline, or already restored
Finished restore at 28-MAR-13

Starting recover at 28-MAR-13
channel dsk0: starting incremental datafile backupset restore
channel dsk0: specifying datafile(s) to restore from backup set
destination for restore of datafile 00024: /u01/oradata/stdby/in_sz_data.312.789659222
destination for restore of datafile 00025: /u01/oradata/stdby/in_sz_data.312.789659223
destination for restore of datafile 00026: /u01/oradata/stdby/in_sz_data.312.789659224
destination for restore of datafile 00027: /u01/oradata/stdby/in_ac_data.9090.810742665
channel dsk0: reading from backup piece /u01/rmanbak/inc2_STD_n2o572go_1_1
channel dsk0: restored backup piece 1
piece handle=/u01/rmanbak/inc2_STD_n2o572go_1_1 tag=INC2
channel dsk0: restore complete, elapsed time: 00:24:27
channel dsk0: starting incremental datafile backupset restore
channel dsk0: specifying datafile(s) to restore from backup set
destination for restore of datafile 00024: /u01/oradata/stdby/in_sz_data.312.789659222
destination for restore of datafile 00025: /u01/oradata/stdby/in_sz_data.312.789659223
channel dsk0: reading from backup piece /u01/rmanbak/fordg/standby_STD_20130323_nbo57oao_1_1.bak
channel dsk1: starting incremental datafile backupset restore
channel dsk1: specifying datafile(s) to restore from backup set
destination for restore of datafile 00026: /u01/oradata/stdby/in_sz_data.312.789659224
channel dsk1: reading from backup piece /u01/rmanbak/fordg/standby_STD_20130323_nco57oao_1_1.bak
channel dsk2: starting incremental datafile backupset restore
channel dsk2: specifying datafile(s) to restore from backup set
destination for restore of datafile 00027: /u01/oradata/stdby/in_ac_data.9090.810742665
channel dsk2: reading from backup piece /u01/rmanbak/fordg/standby_STD_20130323_neo57p0b_1_1.bak
channel dsk0: restored backup piece 1
piece handle=/u01/rmanbak/fordg/standby_STD_20130323_nbo57oao_1_1.bak tag=FOR STANDBY
channel dsk0: restore complete, elapsed time: 00:00:03
channel dsk1: restored backup piece 1
piece handle=/u01/rmanbak/fordg/standby_STD_20130323_nco57oao_1_1.bak tag=FOR STANDBY
channel dsk1: restore complete, elapsed time: 00:00:10
channel dsk2: restored backup piece 1
piece handle=/u01/rmanbak/fordg/standby_STD_20130323_neo57p0b_1_1.bak tag=FOR STANDBY
channel dsk2: restore complete, elapsed time: 00:10:35

Finished recover at 28-MAR-13
released channel: dsk0
released channel: dsk1
released channel: dsk2

RMAN>