一、案例概述
某医疗机构在进行例行数据库维护时，意外地在 `SYSTEM` 表空间添加了一个新的数据文件。然而，操作系统管理员将此新增的 `SYSTEM` 数据文件删除，致使数据库宕机。由于该数据库处于非归档模式，数据恢复变得更加复杂和紧迫。
二、故障原因分析
`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` 是正确的，数据文件中的内容也都完整无误。
四、内容扩展
在处理过程中，我们发现了两种复杂情况，这些情况需要不同的处理方法。 问题一： `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` 信息，使得数据文件能够再次被识别。 问题二：新添加的数据文件中有对象创建 如果在故障 之前 ，有新对象在被删除的数据文件中创建，我们可以通过手动清理基表或使用 `DBMS_SPACE_ADMIN` 包进行恢复。 手动清理基表 1. 删除 `tab$` 表中的记录： ```sql SQL> delete from tab$ where file=9; 1 row deleted. ``` 2. 删除 `seg$` 表中的记录： ```sql SQL> delete from seg$ where file=9; 0 rows deleted. ``` 3. 删除 `ind$` 表中的记录： ```sql SQL> delete from ind$ where file=9; 1 row deleted. ``` 4. 删除 `obj$` 表中的记录： ```sql SQL> delete from obj$ where owner=9; 2 rows deleted. ``` 5. 提交更改： ```sql SQL> commit; Commit complete. ``` 使用 `DBMS_SPACE_ADMIN` 包处理 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. 标记和删除损坏的段： ```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>'); ``` 3. 重启数据库。
五、结论
通过上述详细的恢复步骤和解决方法，我们成功地解决了因为 `SYSTEM` 表空间数据文件删除引起的数据库故障问题。这次事件不仅展示了我们在处理紧急情况时的技术能力和应变能力，也强调了数据库维护过程中每一步操作的重要性。我们的经验表明，在面对数据库故障时，理解 `SCN` 和 `REDO` 日志的作用，灵活运用各种数据库管理工具，是确保数据完整性和快速恢复的关键。未来，我们将继续提升数据库管理和维护的能力，确保业务系统的稳定运行。
