服务器突然断电,导致raid数据库数据全部丢失怎么办!数据怎么恢复

服务器突然断电,导致raid数据库数据全部丢失怎么办!数据怎么恢复,第1张

这个时候我要看你做的是哪一类型的阵列,如果是1系列这恢复的可能性不是特别大,只能通过扫盘。但如果你做的是阵列5,那么可以通过读取阵列的形式交数据重新恢复,但是需要整理。和少盘的这个速度数据是差不多的。在网上有详细的这个恢复教程和详细的过程,建议对你的服务器配备一个UPS。防止下一次出现同类型的问题。

当服务器运维人员发现服务器数据丢失问题时,很多人会在紧急情况下会失去判断能力,盲目的 *** 作,这样只会让数据库的情况继续恶化,恢复就很难了。这里有一些服务器数据丢失的紧急处理办法,希望可以帮助到大家。
一、服务器存储系统非常重要,大家都知道,硬盘作为服务器数据存储的主要设备,同时也是一种技术含量高、制造精密的设备,服务器硬盘的发展目前已达到每秒10000转或15000转,普通的SATA硬盘也非常接近这个转速,在运行当中,一点细小的故障都有可能造成硬盘物理损坏,所以一般服务器都采用Raid磁盘阵列存储,加强服务器硬盘的容错功能。
二、除了Raid硬盘容错外,对于一些非常重要的数据要使用其它设备时时进行备份,推荐企业用户、商务用户架构的网络服务器,选用磁带机配合专业备份软件(VeritasNetbackup、CAArcserver),定期定时做相对完善的备份方案。如果是个人用户的话,建议采用经济的CD-ROM/DVD光盘做为备份方式。
三、对于一些简单的误删除或格式化,针对文件不多,个人技术不错的情况下,可在网上下载一些恢复软件尝试来进行恢得,当然,做之前可以先用Ghost软件做个磁盘全备份,同时在恢复时最好是接从盘。当然,如果你个人恢复的结果不满意,请需要寻求专业的数据恢复公司进行 *** 作了。
四、如果发现服务器数据丢失,千成不要再盲目 *** 作,减小数据恢复机率。可通过电话寻找正规的数据恢复公司技术支持,听取专有建议或请专业技术人员检查。此时,你可以关机停止硬盘读写数据。不再往丢失数据的分区或硬盘里写入数据。减少二次破坏。
五、时刻注意服务器硬盘的运行状况,对于服务器硬盘指示灯多多观察。一般来讲,服务器外观都有每一块硬盘指示灯,正常情况下一般会是绿色,指示灯出现特殊情况时,就需要采用相关措施,仔细检查硬盘设备是否正常。一旦硬盘受损或数据丢失,请不要惊谎,一定要保持冷静的头脑。以下是关于计算机常见硬盘故障情况与用户采用的建议措施:
六、当然,如果确认服务器数据硬盘存在特理故障时,需要进行开盘处理时!这个时候,选择一家专业的数据恢复公司变得非常重要。目前,数据恢复由于技术门槛含量高,相对于一般的计算机维修公司来讲要少,但少并不代表没有。一些技术实力差、环境有限、甚至一些只管接单再转其它公司 *** 作的JS随处可见!这个时候,请需要仔细识别。避免上当受骗,造成无法估算的后期损失。

oracle服务器mb故障
1、检查Oracle服务器的硬件状态,检查服务器的CPU、内存、硬盘等是否正常;
2、检查Oracle服务器的网络状态,检查服务器的网卡、网络线路是否正常;
3、检查Oracle服务器的 *** 作系统状态,检查服务器的 *** 作系统是否正常;
4、检查Oracle服务器上的Oracle数据库状态,检查Oracle数据库的实例是否正常,检查Oracle数据库的数据文件是否正常;
5、检查Oracle服务器上的其他服务状态,检查服务器上的其他服务是否正常;
6、检查Oracle服务器上的监控状态,检查服务器上的监控系统是否正常;
7、根据上述检查结果,如果发现Oracle服务器上的硬件、网络、 *** 作系统、Oracle数据库、其他服务、监控等状态都正常,则可能是Oracle服务器上的MB故障导致的,此时需要对服务器上的MB进行更换。

题主是否想询问“勤哲系统无法打开数据库的原因”?数据库服务器故障,数据库连接字符串出错。
1、 数据库服务器故障。数据库服务器宕机、网络问题等原因导致无法连接数据库。解决方法是可以检查数据库服务器的状态以及服务器密码,咨询相关技术人员帮忙处理。
2、数据库连接字符串出错。勤哲系统的数据库连接字符串中包含了数据库地址、用户名、密码等信息,这些信息填写错误,系统就无法连接数据库。解决方法是可以检查连接字符串,并且确保数据库服务器正常开启。

新增archives 时的状况:
条件和假设:自上次镜像备份以来已经生成新的archive log(s); Archivelog Mode; 有同步的datafile(s) 和control file(s) 的镜像(冷)拷贝;archive log(s) 可用。
恢复步骤:
1 如果数据库尚未关闭,则首先把它关闭: $ svrmgrl svrmgrl> connect internal
svrmgrl> shutdown abort
2 将备份文件抄送回原始地点: 所有Database Files
所有Control Files(没有archive(s) 或redo(s) 的情况下,control files 的更新无任何意义)
所有On-Line Redo Logs (Not archives) initora file(选项)
3 启动数据库: $ svrmgrl
svrmgrl> connect internal
svrmgrl> startup
数据文件, 重作日志和控制文件同时丢失或损坏:
条件和假设:Archivelog Mode; 有同步的所有所失文件的镜像(冷)拷贝;archive log(s) 可用
恢复步骤(必须采用不完全恢复的手法):
1 如果数据库尚未关闭,则首先把它关闭: $ svrmgrl svrmgrl> connect internal
svrmgrl> shutdown abort
2 将备份文件抄送回原始地点:
所有Database Files
所有Control Files
所有On-Line Redo Logs(Not archives)
initora file(选项)
3 启动数据库然而并不打开:
svrmgrl>startup mount
4 做不完全数据库恢复,应用所有从上次镜像(冷)备份始积累起来的archives:
svrmgrl> recover database until cancel using backup controlfile;


cancel
5 Reset the logfiles (对启动而言不可省略):
svrmgrl> alter database open resetlogs;
6 关闭数据库并做一次全库冷备份。
数据文件和控制文件同时丢失或损坏:
条件和假设:Archivelog Mode; 有同步的datafile(s) 和control file(s) 的冷拷贝;archive log(s) 可用
恢复步骤:
1 将冷拷贝的datafiles(s) 和control file(s) 抄送回原始地点:
$ cp /backup/good_onedbf /orig_loc/bad_onedbf
$ cp /backup/control1ctl /disk1/control1ctl
2 以mount 选项启动数据库:
$ svrmgrl
svrmgrl> connect internal
svrmgrl> startup mount
3 以旧的control file 来恢复数据库:
svrmgrl> recover database until cancel using backup controlfile;
介质恢复完成
(须在应用完最后一个archive log 后cancel )
4 Reset the logfiles (对启动而言不可省略):
svrmgrl> alter database open resetlogs;
重作日志和控制文件同时丢失或损坏时:
条件和假设:Control Files 全部丢失或损坏;Archivelog Mode; 有Control Files 的镜像(冷)拷贝
恢复步骤:
1 如果数据库尚未关闭,则首先把它关闭:
$ svrmgrl
svrmgrl> connect internal
svrmgrl> shutdown abort
svrmgrl>exit
2 以Control File 的镜像(冷)拷贝覆盖损坏了的Control File:
$ cp /backup/control1ctl /disk1/control1ctl
3 启动数据库然而并不打开:
$ svrmgrl
svrmgrl> connect internal
svrmgrl> startup mount
4 Drop 坏掉的redo log (排除硬件故障):
svrmgrl> alter database drop logfile group 2;
5 重新创建redo log:
svrmgrl> alter database add logfile group 2 '/orig_loc/log2dbf' size 10M;
6 以旧的control file 来恢复数据库:
svrmgrl> recover database until cancel using backup controlfile;
(必须马上cancel )
7 Reset the logfiles (对启动而言不可省略):
svrmgrl> alter database open resetlogs;
8 关闭数据库并做一次全库冷备份
只发生归档重作日志丢失或损坏时:
根据不同环境和情况,选择下述手段之一:
a 马上backup 全部datafiles (如果系统采用一般热备份或RMAN 热备份)
b 马上正常关闭数据库并进行冷备份(如果系统采用冷备份)
c 冒险前进!不做备份而让数据库接着跑,直等到下一个备份周期再做备份。这是在赌数据库在下一个备份周期到来之前不会有需要恢复的错误发生。
注意:冒险前进的选择:如果发生错误而需要数据库恢复,则最多只能恢复到出问题archive log 之前的 *** 作现场。从另一个角度讲,archive log(s) 出现问题时,数据库若不需要恢复则其本身并没有任何问题。
Oracle逻辑结构故障的处理方法:
逻辑结构的故障一般指由于人为的误 *** 作而导致重要数据丢失的情况。在这种情况下数据库物理结构是完整的也是一致的。对于这种情况采取对原来数据库的全恢复是不合适的,我们一般采用三种方法来恢复用户数据。
采用exp/imp工具来恢复用户数据:
如果丢失的数据存在一个以前用exp命令的备份,则可以才用这种方式。
1 在数据库内创建一个临时用户:
svrmgrl>create user test_user identified by test;
svrmgrl>grant connect,resource to test_user;
2 从以前exp命令备份的文件中把丢失数据的表按照用户方式倒入测试用户:
$imp system/manager file=export_file_name tables=(lost_data_table_name…) fromuser=lost_data_table_owner touser=test_user constraint=n;
3 用相应的DML语句将丢失的数据从测试用户恢复到原用户。
4 将测试用户删除:
svrmgrl>drop user test_user cascede;
采用logminer来恢复用户数据:
Logminer是oracle提供的一个日志分析工具。它可以根据数据字典对在线联机日志、归档日志进行分析,从而可以获得数据库的各种DML *** 作的历史记录以及各种DML *** 作的回退信息。根据这些用户就可以将由于误 *** 作而丢失的数据重新加入数据库内。
1 确认数据库的utl_file_dir参数已经设置,如果没有则需要把这个参数加入oracle的初始化参数文件,然后重新启动数据库。下面例子中假设utl_file_dir=’/opt/oracle/db01’;
2 创建logminer所需要的数据字典信息,假设生成的数据字典文本文件为dictora:
svrmgrl>execute dbms_logmnr_dbuild(dictionary_filename=>'dictora', dictionary_location=>'/opt/oracle/db01’);
3 确定所需要分析的日志或者归档日志的范围。这可以根据用户误 *** 作的时间来确定大概的日志范围。假设用户误 *** 作时可能的日志文件为/opt/oracle/db02/oradata/ORCL/redo3log和归档日志’/opt/oracle/arch/orcl/orclarc_1_113ora’。
4 创建要分析的日志文件列表,按日志文件的先后顺序依次加入:
svrmgrl>execute dbms_logmnradd_logfile(logfilename=>’/opt/oracle/arch/orcl/orclarc_1_113ora’,options=>dbms_logmnrNEW);
svrmgrl> execute dbms_logmnradd_logfile(logfilename=>’ /opt/oracle/db02/oradata/ORCL/redo3log’,options=>dbms_logmnrADDFILE);
5 开始日志分析,假设需要分析的时间在’2003-06-28 12:00:00’和’2003-06-28 13:00:00’之间:
svrmgrl>execute dbms_logmnrstart_logmnr(dictfilename=>’ /opt/oracle/db01/dictora’,starttime=>to_date(’ 2003-06-28 12:00:00’,’YYYY-MM-DD HH:MI:SS’),endtime=>to_date(to_date(‘2003-06-28 13:00:00’,’YYYY-MM-DD HH:MI:SS’));
6 获取分析结果:
svrmgrl>select operation,sql_redo,sql_undo from v$logmnr_contents;
7 根据分析结果修复数据。
8结束logmnr:
svrmgrl>dbms_logmnrend_logmnr;
9 用适当的方法对原数据库进行数据库全备份。
利用备份恢复用户数据:
采用这种方法时并不是在原数据库进行恢复,而是利用数据库备份在新的机器上重新建立一个新的数据库。通过备份恢复在新机器上将数据库恢复到用户误 *** 作前,这样就可以获得丢失的数据将其恢复到原数据库。
1 在新的机器上安装数据库软件。
2 对于采用带库备份的现场,需要在新的数据库服务器上安装调试相应的备份管软件。
3 根据用户误 *** 作的时间点进行基于时间点的数据库恢复 *** 作。对于没有采用带库备份的现场,可以选取用户误 *** 作前最近的备份磁带进行恢复;对于才用带库备份的点可以通过基于时间恢复点恢复的rman脚本来进行恢复。
4重新打开数据库:
svrmgrl>alter database open resetlogs;
5 从新的数据库中获取丢失的用户数据,通过DML *** 作将其恢复到原数据库中。
6 用适当的方法对原数据库进行数据库全备份。

怎么排除服务器中RAID5故障

但是,对HP的一些老服务器(如HP LH6000)数据的恢复与新服务器(如HP ProLian系列服务器)的数据恢复是不同的。所以不同的服务器对RAID 5故障的处理也是不同的。曾接触过两台服务器因意外断电而造成的RAID 5阵列卡数据故障,由于采用了不同的策略而解决了问题。

故障修复

一台是HP LH6000的服务器,4块18GB的硬盘做成RAID 5磁盘阵列,其阵列卡是NetRaid;另一台是HP ProLian ML370服务器,4块146GB的硬盘做成RAID 5磁盘阵列,其阵列卡是Smart Array 642并带有热备份硬盘(Hot Spare)。两者 *** 作系统都为Window 2000,数据库是Server 2000。

HP LH6000的故障如下: 一块硬盘红灯闪亮,机器还在正常运行,但没有多久,系统就不能正常运行,这时才发现另一块硬盘的红灯也在闪亮。

解决办法如下:

1启动服务器,自检至阵列时按Ctrl+M进入NetRaid管理程序。查看阵列信息,发现硬盘状态为Failed,运用修改配置将一硬盘强行设置成OnLine。重新启动服务器,在进入系统前的硬件自检时无效,启动失败。

2启动服务器,自检至阵列时按Ctrl+M进入NetRaid管理程序。选择磁盘阵列,将原来OnLine挂起来的硬盘手工Fail掉,然后再把另一块Failed的硬盘手工设置成OnLine,重新启动服务器就可以进入系统了。

3查看系统及数据库都运行正常后,再进阵列配置工具把Failed的硬盘手工设置成Rebuild,100%完成重建后再重启服务器,所有的阵列及系统都恢复原状了。

另一台运行ERP系统的服务器(HP ProLiant ML370),由4块146GB热插拔硬盘通过RAID卡(Smart array阵列卡)配置成一台具有RAID 5级的磁盘阵列。其中一块硬盘在运行过程中突然出现故障。服务器RAID 5自动启用热备份硬盘(Hot Spare),对损坏硬盘进行逻辑替代。整个硬盘的数据访问任务仍然完整地运行在原来的读写进程序列中,应用程序和数据库没有发生影响。

通过HP自带的ACU工具查看硬盘状态进行检查,发现红灯示警的硬盘处于脱机状态。如果HP ProLiant服务器中的Raid 5有两块硬盘出现亮红灯时,表明系统已经崩溃,数据库也就不能访问,但系统不会自动关机。当第二块硬盘亮红灯后,用常规的手段是不能恢复数据的,只有付费找专业的第三方数据恢复公司恢复数据。

因此,对惠普老型号HP LH6000系列服务器来说,阵列的设计方面与现在HP ProLiant系列服务器的阵列有很多不同。就 *** 作方法看,HP LH6000服务器的阵列 *** 作方法有很多可选项,包括阵列失败后可以重新删除阵列并重建等,初始化也是手工选择的。但是HP ProLiant系列服务器阵列的初始化是在配置阵列后自动在后台执行的,所以ProLiant系列服务器在阵列出错后是不能重配阵列的。

HP LH6000服务器会因其他意外的原因导致阵列中的磁盘出现掉线现象,可让维护人员手工选择用Online或Offline、Rebuild等来恢复数据。但是现在的HP ProLiant系列服务器在阵列中不会再出现像老的服务器那样有磁盘掉线的现象,所以硬盘亮红灯的时候,这块硬盘基本上是损坏了需要更换。当然可以选择热插拔硬盘来重建(Rebuild),看硬盘还能不能再用一段时间。

做好技术后备

从以上两个例子可以看出,同一品牌、不同系列的服务器因其内含技术的不同,其Raid 5磁盘故障的排除也是不同的。但经过重建(Rebuild)数据后,数据被拯救了,从中可以得出以下经验:

我们认为任何先进的技术手段都不是万无一失的。如果要确保数据安全,就一定要做好备份工作,最好每天做一次数据库的异地备份。至少备用一块新硬盘。需要指出的是,加入阵列的硬盘必须大于或等于故障硬盘的容量。

如果条件允许,推荐“RAID 5+热备盘”的阵列创建方案。这样在数据丢失前,我们有两次更换硬盘的机会。对于一般的应用,只用RAID 5即可,可以同时提供数据的存取性能、可靠性和最大的磁盘空间。

管理员必须经常观察阵列的状态,包括查看磁盘阵列的**警告灯和管理软件里的驱动器状态。出现故障,及时排除。无论是什么级别的阵列,在排除故障前,都应做好数据备份。

;


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zz/12940507.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-29
下一篇 2023-05-29

发表评论

登录后才能评论

评论列表(0条)

保存