数据库修复解决方案

，海运记录需要与信用额度相对应，等等。通常来说，不可能使用普通的记录文件来管理大量的、复杂的系列数据，如：银行的客户数据，或者生产厂商的的生产控制数据。普通记录文件没有系统结构来系统的反映数据间的复杂关系，它也不能强制定义个别数据对象。

数据库管理系统

    数据库管理系统 (DBMSs) ，或者数据库管理器已经发展了近二十年，来解决上面提到的这些需求。数据库管理器是近似于文件系统的软件系统，通过它应用程序和用户可以取得所需的数据。然而，它们又不像文件系统，它们定义了所管理的数据之间的结构和约束关系。并且，数据库管理器提供了一些基本的数据管理功能：

管理数据库日志

    对于容灾而言，数据库备份应当存贮在远离数据库的地方。为了达到最优容灾状态，在灾难发生后能够容易地获取数据库日志也是非常必要的。数据库归档日志通常保存在备份储存的地点。数据库管理员必须在数据库实时恢复和资源占用量两者之间找到平衡，从而决定进行数据库日志归档的频率。过多地进行归档可以降低数据损失的潜在危险，但是浪费了更多的进程和 I/O 资源，很有可能增加了处理的响应时间。过少地进行归档可以降低资源的平均占用量，但是延长了两次归档的间隔时间，很有可能导致不能做到精确的实时恢复。

    如果一个数据库和它的联机日志被损坏了，那么即使马上进行了严密的数据库备份和日志归档，数据也极有可能丢失。因此，一个完整的数据库融灾策略的一个重要部分就是对联机的数据库日志进行复制，这样在进行修复处理时就可以及时利用这些复制的内容准确无误地修复数据库。联机数据库日志可以通过有限的距离进行镜像。如果距离过长，数据库管理员可以通过多路转接技术或者通过企业网络同时进行本地和远处的日志拷贝。多路转接技术通常比镜像和低水平复制（如数据卷）的速度要慢一些，因此如果可以的话要尽量选择后一种方式。

    最高级别的数据库实时恢复是在每次事务提交的之前同步进行数据库日志的传输和归档。换句话说，必须要在日志已经被转移到另外地点后，才进行事务的提交。显而易见，这种选择执行起来的代价是非常昂贵的，因而在实践中较少采用。

被动式的数据库恢复

    在没有备份的情况下，一旦出现数据灾难，那么就只能通过修复关键数据库文件，再尝试修复文件结构，以这样的方式来恢复数据库。由于此时涉及到对硬件结构、文件系统、数据库结构的深入分析，因此要求服务商有极强的综合技术能力。

飞客最擅长 Oracle 和 SQL Server 数据库的恢复，主要包括以下数据库修复技术：

ORACLE 恢复修复

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

SQL Server 修复

1. 如完全丢失数据库文件，用一般数据恢复方式不能恢复
2. 表被删除，甚至被重写，表行被删除。
3. 索引错误，或者 IAM 断裂。
4. 数据库大面损坏，可以指定任意表或者字段提取数据。
5. 系统表损坏甚至完全损坏。可以提取指定数据。