数据库修复中心

关于数据库修复

如果你已经尝试多家公司，请不妨再交给我们看看，我们已经多次挽救过类似的数据库， SQL、Oracle数据库我们无论在什么环境下，无论数据库文件破坏或丢失，我们都有很强的信心恢复。自主研发的MDF数据库碎片恢复技术，恢复那些被认为无法恢复的MDF数据库文件，当FAT32删除或者格式化文件或者NTFS分区 里面删除文件后文件长度变成0字节，一般的数据恢复技术手段就无法完成的找回原来数据库文件的碎片数据，恢复的文件往往无法附加到数据库中。MDF数据库文件一般都比较大，在磁盘中往往 被存放到不连续的逻辑簇中，就形成了文件碎片，当删除或者格式化后，这些分散在磁盘中的碎片数据很难恢复，2年来处理了无数起各种因格式化删除或其他原因导致文件无法通过数据恢复软件找到的情况，并对其成功修复。

国内大部分关于数据库修复技术，基于网上下载资料。这些公司都对数据库了解甚少却蒙蔽客户。 比 　如SQL Server 异常不能启动或者缺少日志文件，都可以用基本办法(数据库置疑附加解决)解决。不过建议为了保护数据，请 备份数据库文件，并在其他设备上做修复测试，切记不要在丢失数据机器上测试。

SQL Server 修复

• 如完全丢失数据库mdf文件，用一般数据恢复方式不能恢复
• 数据库中表被删除，甚至被重写数据，或记录删除又无log日志文件
• 索引错误，或者IAM断裂，以及各种错误提示如823错误、系统表出错
• 数据库大面损坏，可以指定任意表提取其数据。
• 格式化或删除后恢复mdf，无法附加提示不是有效的sql文件

ORACLE 修复

• 误delete数据的恢复、误删除表空间drop、truncate表的恢复
• undo、system表空间损坏的恢复
• 各种ora- 错误的修复
• DMP文件不能导入数据库以及LOB数据恢复等情况
• oracle数据库中数据文件出现坏块情况下的恢复
• oracle数据库无数据文件但有有日志的情况下的恢复
• 能够在系统表和表空间文件丢失，变成0字节下完整的恢复数据
• 只要没有覆盖表空间文件，我们有信心恢复数据。无论你是什么系统（Windows、UNIX等），无论什么存储设备（硬盘、磁盘阵列）

请按步骤进行,未进行前面的步骤时,请不要做后面的步骤，以免损坏你的数据库.

一般不建议做第4,6两步，第4步不安全,有可能损坏数据库或丢失数据。第6步如果日志达到上限,则以后的数据库处理会失败,在清理日志后才能恢复。

1.清空日志

DUMP TRANSACTION 库名 WITH NO_LOG
Continue reading…

客户公司里的sql服务器系统故障，当时系统还是能运行的，于是it人员将sql数据库备份到f盘分区里，然后重新安装了系统。 Continue reading…

客户是当地某集团公司，使用易安财务软件，不慎删除数据库文件。客户通过r-studio数据恢复软件将180mb的mdf文件找回，但是无法附加，提示不是有效的sql数据库文件。 Continue reading…

最近接了个sybase单子 ， 客户的数据库文件在坏道上， 强行拷贝出来但文件已经损坏。 Continue reading…

1. 只有在master数据库中才能有的系统表
系统表名 表中的内容
Sysconfigures 一行记录了用户可设置的配置参数
Syscurconfigs 有关SQL Server当前正使用的配置参数情况
Sysdatabases 一行记录了SQL Server中的一个数据库
Sysdevices 一行记录了数据库的每一磁带转储设备，磁盘转储设备，数据库设备和磁盘分区
设备和磁盘分区
Syslocks 有关动态锁的情况 Continue reading…

客户公司内部的信息管理系统使用sql server 2000数据库，数据库文件存放在d盘（格式FAT32）， 网管在维护过程中不慎选中“初始化数据库” ， 里面的记录都变成空了。 原先mdf文件有1.9G ,现在文件变成只有8mb 大小。 Continue reading…

1.首先确认已经备份了.mdf和.ldf文件。
2. 在SQL Server中新建一个同名的数据库，然后停止SQL Server服务。
3. 用原有的.mdf和.ldf文件覆盖新建数据库对应的.mdf和.ldf文件。
4. 重新启动SQL Server服务，这是应该会看到这个数据库处于置疑（Suspect）状态。
5. 在SQL查询分析器中执行以下命令，以允许更新系统表： Continue reading…

sql server数据库中三张重要的系统表

• sysobjects：在数据库内创建的每个对象（约束、默认值、日志、规则、存储过程等）在表中占一行。
• sysindexes：数据库中的每个索引和表在表中各占一行。
• syscolumns：每个表和视图中的每列在表中占一行，存储过程中的每个参数在表中也占一行。

这三张表用ID（表ID）字段关联。这三张系统表一旦损坏，与之对应数据库对象将无法访问，其作用相当于DOS中的“文件分配表” 。

系统表损坏的症状
用 DBCC CHECKDB 携带任何参数都无法修复数据库，也就是说：DBCC CHECKDB对这个帐套根本不起作用；
无法执行如下操作：

select * from sysobjects 或select * from sysindexes 或select * from syscolumns ；

无法用SQL server DTS或其他SQL 脚本导库工具进行导库，导库的中途失败，报告：连接中断；未能读取并闩锁页；在企业管理器或查询分析器中，部分用户数据表无法访问。 Continue reading…

错误 602未能在 sysindexes 中找到数据库 ID %1! 中对象 ID %2! 的索引 ID %3! 对应的行。请对 sysindexes 运行 DBCC CHECKTABLE。
疑难解答
错误 602
严重级别 21
消息正文
未能在 sysindexes 中找到数据库 ID %1! 中对象 ID %2! 的索引 ID %3! 对应的行。请对 sysindexes 运行 DBCC CHECKTABLE。

解释
当 Microsoft? SQL Server? 无法在 sysindexes 表中找到需要的表或索引所对应的行时（例如，当执行引用已除去的表的存储过程时），发生该错误。

对策
如果该错误因为存储过程引用某个已除去的表而发生，则除去并重新创建该存储过程。该错误还可能和其它错误信息一起发生，而这些消息更好地指出问题的根本原因。在 sysindexes 上执行 DBCC CHECKTABLE；同样执行 DBCC CHECKDB。

如果问题仍然存在，请与您的主要支持提供者联系。使 DBCC CHECKDB 语句的输出可查阅

Transact-SQL 参考
DBCC CHECKTABLE Continue reading…

06年时的案例，客户在上海九院 ，有一台服务器raid5信息丢失，然后找了家数据恢复公司，恢复出来的文件，但是好几个数据库都无法附加。当时我判断应该是那个公司恢复过程有问题，导致数据不一致，于是问客户原盘是否还在，客户称原服务器已经重做raid5 ，晕倒，想通过原盘恢复mdf文件这途径是不可能了，只能修复现有的文件。 Continue reading…