沈阳数据恢复中心

16
2014
01

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数据库版本、可以恢复各种数据表（普通表、压缩表、索引表、簇表、分区表）数据、可以恢复各种数据类型、可以恢复各种数据对象、代码。

发布:admin | 分类:数据库修复 | 评论:0 | 浏览:
15
2014
01

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>


发布:admin | 分类:技术文章 | 评论:0 | 浏览:
15
2014
01

CLASSPATH没有设置Notes客户端无法连接到Domino服务器

   一些Lotus Notes® 7.x 客户端突然无法连接到Lotus® Domino® server，尽管您重新安装并配置客户端时，这些客户端可以连接到服务器并完成配置。您可能会看到类似下面的错误：

"Unable to find path to server. To trace this connection, use File - Preferences - User Preferences - Ports - Trace (Notes client) or Trace command (Domino server)"
"The remote server is not a known TCP/IP host."
"The TCP/IP protocol stack reported that it ran out of memory. Consult your network documentation to increase configured memory, or reduce Notes connections by limiting clients (see SERVER_MAXSESSIONS parameter in Notes Admin Guide)."

发布:admin | 分类:技术文章 | 评论:0 | 浏览:
15
2014
01

IBM DS4000/DS5000添加新硬盘的步骤与注意事项

    添加前的准备工作：

    1.对DS4000或DS5000系统中的数据进行完全备份
    2.确认备份已经成功
    3.确认当前的系统的控制器微码，NVSRAM和ESM的微码（参考11）
    注意：在升级微码前，请查看微码中的README文件，确认微码的升级步骤
    4.确认硬盘微码为最新版本
    5.确认当前DS4000或DS5000中的硬盘处于最佳(optimal)状态
    6.如果连接了扩展柜，通过Storage Manager的Read_Link_Status功能和Major Event Log(MEL)功能，确认扩展柜环路(drive loop)处于最佳(optimal)状态
    7.查看并解决Major Event Log(MEL)中的错误问题
    8.保存当前DS4000或DS5000的配置信息
    9.如果混插FC和SATA硬盘，请购买并激活混插许可
    10.添加硬盘前，请检查硬盘与当前DS4000或DS5000的系统的兼容性（参考11）
    11.更多详细工作请参考IBM System Storage DS4000 and DS5000 Hard Drive and Storage Expansion Enclosure Installation and Migration Guide文档中的第二章内容

发布:admin | 分类:技术文章 | 评论:0 | 浏览:
15
2014
01

IBM DS4000 DS5000电池保护原理与时间


   DS4000系列存储Cache电池保护时间标称为72小时。由于DS4000的Cache是一种易失性存储介质，需要持续供电才能存储数据，一旦失去供电Cache中的数据将丢失。如果DS4000打开Cache功能（尤其是write cache），应用端数据写到Cache中就会返回写成功，但此时数据并没有写到磁盘中（一般需要一定条件触发从cache写到磁盘，如：10秒以后或Cache容量达到80%等，该过程称作flush），若意外掉电，电池就会保护Cache中的数据，该电池为充电电池，可以保护72小时。

发布:admin | 分类:技术文章 | 评论:0 | 浏览:
15
2014
01

IBM DS4000 DS5000热备盘配置方法


  对于Stoarage Manager 10，定义热备盘有两种方法：自动分配(Automatic assign)和手工分配(Manual assign)。

    注意：
    1)从Storage Manager 10.10开始，全局热备盘不再有数量限制。
    2)热备盘的容量要大于或等于存储子系统中其他磁盘的容量
    3)在包含大量磁盘的配置中，由于重建时间较长，有必要定义多个热备盘
    4)如果DS4000中包含FC和SATA硬盘，需要考虑定义FC和SATA作为热备盘，因为FC硬盘不能保护SATA盘创建的Raid组，反之亦然。

发布:admin | 分类:技术文章 | 评论:0 | 浏览:
15
2014
01

ServerGuide 引导安装指南


  使用ServerGuide 设置和安装CD 时，您不需要安装软盘。可以使用CD 配置任何支持的IBM 服务器型号。安装程序提供了安装服务器型号所需要的任务列表。在装有ServeRAID 适配器或具有RAID 能力的集成SCSI 控制器的服务器上，您可以运行SCSIRAID 配置程序来创建逻辑驱动器。

  注：ServerGuide 程序的特征和功能可能随版本的不同而略有不同。要了解您现有版本的更多信息，请启动ServerGuide 设置和安装CD 并查看联机概述。并非所有的服务器型号都支持所有特点。ServerGuide 程序需要一台具有已启用的可启动（可引导）CD-ROM 驱动器的、受支持的IBM 服务器。除ServerGuide 设置和安装CD 外，您还必须准备好操作系统CD 以安装操作系统。

发布:admin | 分类:技术文章 | 评论:0 | 浏览:
15
2014
01

IBM刀片服务器宕机故障现象巧排除

   此排除IBM刀片服务器宕机故障所适用的机型仅限于BladeCenter所有8677机型; BladeCenter HS20所有8678机型; BladeCenter HS20所有8832机型; BladeCenter HS40所有8839机型; BladeCenter JS20所有8842机型; BladeCenter T所有8720机型; BladeCenter T所有8730机型。

　　IBM刀片服务器宕机故障现象

发布:admin | 分类:技术文章 | 评论:0 | 浏览:
15
2014
01

IBM服务器数据擦除销毁


    由于办公无纸化的普及，更多企业的机密将会以数据的形式存储在服务器上，一旦服务器因为故障或者老化需要更换，则硬盘上的机密数据如何处理是很多企业所面临的头疼问题，如果处理不当便会有可能造成企业机密外泄，对公司或者国家造成不可挽回的损失。作为提供专业的服务器维修及服务器数据安全服务的公司，我们将以我们雄厚的技术实力和丰富的经验为您提供国家安全保密级别的数据销毁服务。

发布:admin | 分类:存储业内新闻 | 评论:0 | 浏览:
15
2014
01

IBM服务器Raid卡维修

     RAID卡就是用来实现RAID功能的板卡，通常是由I/O处理器、硬盘控制器、硬盘连接器和缓存等一系列零组件构成的。不同的RAID卡支持的RAID功能不同。支持RAlD0、RAID1、RAID3、RAID4、RAID5、RAID10不等。RAID卡可以让很多磁盘驱动器同时传输数据，而这些磁盘驱动器在逻辑上又是一个磁盘驱动器，所以使用RAID可以达到单个的磁盘驱动器几倍、几十倍甚至上百倍的速率。

    RAID卡损坏不同于服务器别的部件损坏，由于它与硬盘都和服务器数据息息相关，所以一旦RIAD卡损坏，就就有可能造成服务器数据的丢失，特别是某些RAID卡，在其中存有部分RAID信息，一旦损坏，就算更换一块新的RAID卡，服务器的数据也无法正常使用。我中心的RAID卡维修则无此顾虑，公司自主研发的磁盘阵列恢复软件可以通过一系列的职能算法，恢复出存放在RAID卡中的RAID信息，保证在RAID卡维修或更换后服务器中的数据能够正常使用

发布:admin | 分类:服务器数据恢复 | 评论:0 | 浏览:
«1234567891011121314»
<#articlelist/category/meta/title#>-<#ZC_BLOG_TITLE#>