您的位置:首页 >> 数据库修复
  • 由于操作系统错误,导致系统无法正常使用,把用友数据库做备份后,重新安装系统,系统安装好后,把用友软件备份的数据库还原的时候提示错误 “设备 'E:\\UFDATA.bak' 上的媒体簇的结构不正确。SQL Server 无法处理此媒体簇。 -2147217900” MDF 和LDF能创建出来,但无法附加。
  • SQL SERVER 2005数据库,在正常使用过程中,服务器突然断电,重新启动服务器后,数据库变为”置疑”,数据库无法附加,由于数据库在正常读写操作过,服务器突然断电,导致数据库无法把所有缓冲中的数据写入到数据库文件中,所以会使数据内部索引及数据区损坏。 为提升服务质量,北亚数据恢复中心允许用户全程参观。
  • 客户服务器操作系统及应用环境为redhat4.6+mysql,数据库用于存储教师及学生的注册信息,linux脚本每天会定时将数据库文件打包成tar.gz备份到本地其他数据分区,备份成功后删除前一天的备份文件,系统于某个周末遭到恶意入侵,所有数据库文件(包括备份)均被删除。历时三个小时,成功恢复全部数据。
  • 客户服务器操作系统及应用环境为HP-UX+ORACLE,数据库用于存储全校师生的排课选课信息,暑期机房施工,一天内意外断电数次,后故障主机重启自动fsck,导致ORACLE实例无法启动,部分数据库文件丢失。北亚数据恢复中心工程师加班加点,历时四个工作日恢复全部数据。
  • 客户是上海市一大型服装公司,自主开发了一套ERP系统,使用SQL Server 2008 R2 数据库。此ERP系统存储在一个Hyper-V R2 虚拟机上,OS为Windows 2008 R2。此ERP系统生产库约10G左右,但大量的数据库备份和其它虚拟机严重挤占磁盘空间,备份库和生产库虽在不同的分区,但物理上仍属同一块磁盘。宿主机存储空间紧张后,管理员备份出数据库,拷在一移动硬盘上,然后增大存储,开始用第三方软件扩容,不幸的是扩容失败,整个磁盘数据完全混乱。然后,管理员在另一虚拟机上还原数据库,更不幸的是还原失败,因是移动硬盘的原因,所拷入备份库数据仅前部分正常,中后部分均是0字节填充,已无一份有效数据,导致此公司直接停工,无法运作。
  • 9个多G的outlook pst邮件误删除以后,又在该分区写入300多M数据,通过北亚工程师研发的碎片提取程序成功将所有碎片提取出来然后合并成一个完整的pst邮件数据库,因为后来有数据写入,导致邮件部分被覆盖,pst文件无法正常挂载。继续使用自行研发的pst邮件修复程序将邮件修复,可以直接挂载。客户满意度99%以上。
  • 客户描述电脑装了还原卡,有重要access数据库文件没有备份出来重启电脑了。之后起了几回系统没有往里面考数据。根据客户描述还不能判断数据能不能恢复,需要拿到硬盘分析后才能确定。通过远程操作客户电脑,通过磁盘底层分析硬盘原来的文件存储结构,发现160G的硬盘实际只用了不到100G,其余空间均被还原卡保留,因为不确定数据库原来保存的位置,通过全盘查找数据库的信息将数据库恢复。
  • 北京交通大学:希捷320G台式机硬盘,邮件在D盘存放,突然丢失后利用outlook自动修复失败,并写入一部分数据。工程师尽力恢复,客户得到了满意的结果。
  • 户在升级Mysql数据时,在没有备份数据库的情况下,Drop掉表后重新生成相同结构的表,使用2天后,发现原数据没有备份。因为数据库使用的InnoDB引擎,对ibdata文件进行分析,发现原数据所点用的空间,没有被释放,所以数据可100%恢复。
  • 客户服务器操作系统及应用环境为redhat4.6 mysql,数据库用于存储教师及学生的注册信息,linux脚本每天会定时将数据库文件打包成tar.gz备份到本地其他数据分区,备份成功后删除前一天的备份文件,系统于某个周末遭到恶意入侵,所有数据库文件(包括备份)均被删除。数据恢复总共历时3小时,其中镜像原盘、初步检测花费1小时,数据库备份文件信息查找、恢复及验证花费2小时。数据恢复成功率为百分之百。
11 篇文章  首页 | 上一页 | 1 2 | 下一页 | 尾页  10篇文章/页  转到第