沈阳数据恢复中心

16
2014
01

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错误的数据库修复

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

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

发布:admin | 分类:数据库修复 | 评论:0 | 浏览:
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 | 浏览:
«1234567891011121314»
<#articlelist/category/meta/title#>-<#ZC_BLOG_TITLE#>