1 、故障描述

某医疗机构在进行例行数据库维护时，意外地在  `SYSTEM`  表空间添加了一个新的数据文件。然而，操作系统管理员将此新增的 `SYSTEM` 数据文件删除，致使数据库宕机。由于该数据库处于非归档模式，数据恢复变得更加复杂和紧迫。

2 、根因分析

`SYSTEM` 表空间是 Oracle 数据库中最为核心的表空间，所有数据文件必须处于 `ONLINE` 状态以确保数据库正常运行。然而，删除了新增的 `SYSTEM` 数据文件后，致使数据库无法正常打开，因为数据库需要所有的 `SYSTEM` 表空间数据文件来维持其一致性和完整性。

在接到故障通知后，我们迅速采取了一系列措施，成功恢复了数据库功能。以下是详细的恢复步骤：

1. 挂载数据库：

   首先，我们将数据库挂载，以便进行进一步的恢复操作。

   ```sql

   ALTER DATABASE MOUNT;

   ```

2. 创建缺失的数据文件：

    接着，我们使用 `ALTER DATABASE CREATE DATAFILE` 命令重新创建了丢失的 `SYSTEM` 数据文件。

   ```sql

   ALTER DATABASE CREATE DATAFILE 9;

   ```

3. 恢复数据文件：

   使用 `RECOVER DATAFILE` 命令对新的数据文件进行恢复操作。

   ```sql

   RECOVER DATAFILE 9;

   ```

4. 打开数据库：

   最后，通过 `ALTER DATABASE OPEN` 命令成功打开数据库。

   ```sql

   ALTER DATABASE OPEN;

我们之所以能够成功恢复数据库，主要是因为从 9 号文件被创建到出现故障这段时间的 `REDO` 日志没有被覆盖。这意味着创建出的文件的 `SCN` 是正确的，数据文件中的内容也都完整无误。

在处理过程中，我们发现了两种复杂情况，这些情况需要不同的处理方法。

  场景 1 ： `REDO` 日志有缺失

如果在故障发生期间，关键的 `REDO` 日志已经被覆盖，我们可以使用 `BBED` 工具对比其他文件的 `SCN` 以恢复数据文件。

  使用 `BBED` 工具进行恢复

`BBED` 是一个强大的工具，可以直接编辑 Oracle 数据块。使用它可以恢复错误的 `SCN` 和 `DBA` 数据。

1. 设置 `DBA` ：

   ```sql

   BBED> set dba 2,1

          DBA 0x00800001 (8388609 2,1)

   ```

2. 转储偏移量并提取 `SCN` 信息：

   ```sql

   BBED> dump offset 484 count 10

   File: /u01/app/oradata/localdb/sysaux01.dbf (2)

   Block: 1 Offsets: 484 to 493 Dba:0x00800001

   -------------------------------------------------------

   6dd15100 00007009 5c1a

   BBED> dump offset 500 count 10

   File: /u01/app/oradata/localdb/sysaux01.dbf (2)

   Block: 1 Offsets: 500 to 509 Dba:0x00800001

   -------------------------------------------------------

   d7000000 02000000 1000

   ```

3. 设置新的 `DBA` 并修改偏移量：

   ```sql

   BBED> set dba 9,1

          DBA 0x02400001 (37748737 9,1)

   BBED> m /x 6dd15100 offset 484

   Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) Y

   File: /u01/app/oradata/localdb/system02.dbf (9)

   Block: 1 Offsets: 484 to 493 Dba:0x02400001

   -------------------------------------------------------

   6dd15100 00000000 4a15

   BBED> m /x d7 offset 500

   File: /u01/app/oradata/localdb/system02.dbf (9)

   Block: 1 Offsets: 500 to 509 Dba:0x02400001

   -------------------------------------------------------

   d7000000 02000000 0000

   ```

4. 应用校验：

   ```sql

   BBED> sum apply

   Check value for File 9, Block 1:

   current = 0x4bb6, required = 0x4bb6

   ```

通过以上步骤，我们成功恢复了丢失的 `SCN` 信息，使得数据文件能够再次被识别。

  场景 2 ：新添加的数据文件中有对象创建

如果在故障之前，有新对象在被删除的数据文件中创建，我们可以通过手动清理基表或使用 `DBMS_SPACE_ADMIN` 包进行恢复。

1 、手动清理基表

1.1 删除 `tab$` 表中的记录：

   ```sql

   SQL> delete from tab$ where file=9;

   1 row deleted.

   ```

1.2 删除 `seg$` 表中的记录：

   ```sql

   SQL> delete from seg$ where file=9;

   0 rows deleted.

   ```

1.3 删除 `ind$` 表中的记录：

   ```sql

   SQL> delete from ind$ where file=9;

   1 row deleted.

   ```

1.4 删除 `obj$` 表中的记录：

   ```sql

   SQL> delete from obj$ where xxx=yyy;

   2 rows deleted.

   ```

1.5 提交更改：

   ```sql

   SQL> commit;

   Commit complete.

   ```

1.6 清空回收站

1.7 重启数据库。

2 、使用 `DBMS_SPACE_ADMIN` 包处理

2.1 查询 `seg$` 表：

   ```sql

   SQL> select file,block,type,ts from seg$ where file=9;

   FILE     BLOCK      TYPE        TS

   ---------- ---------- ---------- ----------

   9         10          5          7

   9         18          6          7

   ```

2.3 标记和删除损坏的段：

   ```sql

   exec dbms_space_admin.segment_corrupt('<TSNAME>', <FILE_ID>, <BLOCK_ID>, DBMS_SPACE_ADMIN.SEGMENT_MARK_CORRUPT);

   exec dbms_space_admin.segment_drop_corrupt('<TSNAME>', <FILE_ID>, <BLOCK_ID>);

   exec dbms_space_admin.tablespace_rebuild_bitmaps('<TSNAME>');

   ```

2.3 重启数据库。

3 、解决方案

通过上述详细的恢复步骤和解决方法，我们成功地解决了因为 `SYSTEM` 表空间数据文件删除引起的数据库故障问题。在面对此类数据库故障时，理解 `SCN` 和 `REDO` 日志的作用，灵活运用各种数据库管理工具，是确保数据完整性和快速恢复的关键。