oracle数据库归档日志丢失,丢失数据文件的恢复归档和非归档日志模式下

最新推荐文章于 2021-05-20 10:30:35 发布

古怪小姐爱喝酒

最新推荐文章于 2021-05-20 10:30:35 发布

阅读量1.4k

点赞数

文章标签： oracle数据库归档日志丢失

本文详细介绍了在Oracle数据库中，关键和非关键数据文件丢失后的恢复流程。关键文件如SYSTEM和撤销表空间的数据文件，其丢失会导致数据库立即终止，需要在加载模式下进行恢复。非关键文件的恢复可以通过RMAN自动完成，但如果归档日志丢失，可能会导致数据丢失。文章还提供了模拟和恢复非关键数据文件的步骤，以及如何处理丢失归档日志的情况。重点讨论了完整恢复、不完整恢复的策略和应用场景。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

在Oracle数据库中，构成SYSTEM表空间和当前活动的撤销表空间(由UNDO_TABLESPACE参数指定)的数据文件被认为是"关键的"。这类文件受损将导致实例立即终止。而且，在通过还原和恢复操作修复损坏之前，数据库无法再次打开。构成用户数据表空间的其他文件受损通常不会导致实例崩溃。Oracle将使受损的文件脱机，使其内容不可访问，但数据库的其余部分仍保持打开。您的应用程序对此的反应将取决于其构造和编写方式。

提示：

在部分数据库不可用的情况下运行应用程序安全吗？这是一个要与开发人员和业务分析师讨论的问题，并且也是在决定如何跨表空间扩展段时要考虑的重要一点。

如果备份是用RMAN完成的，那么受损文件的还原和恢复操作将完全自动。RMAN将以最有效的方式执行还原，智能地使用完整和增量备份，然后应用必要的归档日志。如果RMAN通过SBT通道链接至磁带库，它将自动加载磁带来提取所需的文件。

数据文件的还原和完整恢复只有在自数据文件上一次备份后生成的所有归档日志文件可用的情况下才能成功。它们必须仍在磁盘的归档日志目标目录中，或者如果它们已被迁移到磁带，则必须在恢复操作期间还原。RMAN将自动从备份集中提取并还原到磁盘。如果归档日志文件因为某个原因缺失或受损，恢复将失败，但由于归档日志目标和RMAN备份集可以且应多路复用，因此一般不会出现这种情况。如果出现这种情况，唯一的选择是完整还原，不完整恢复至缺失的归档，这意味着会丢失所有后续工作。

练习16-3

在丢失不关键数据文件时，使用Database Control进行恢复

首先，创建一个表空间并在其中创建段，然后进行备份。接着模拟数据文件受损。诊断问题并解决它。数据库在整个练习期间将保持打开供使用。在各个点，您将被要求提供主机操作系统凭证(如果在之前的练习中未保存)：提供一个合适的Windows或Unix登录名，如Oracle所有者。

(1) 使用SQL*Plus以SYSTEM用户身份连接数据库并创建一个表空间。例如，在Windows上是：

SQL>create tablespace noncrit

datafile 'C:\APP\ORACLE\ORADATA\ORCL\noncrit.dbf' size 2m;

或在Unix上为：

SQL>create tablespace noncrit

datafile '/app/oracle/oradata/orcl/noncrit.dbf' size 2m;

(2) 在这个新的表空间中创建表，并向其中插入一行：

SQL>create table ex16 (c1 date) tablespace noncrit;

SQL>insert into ex16 values(sysdate);

SQL>commit;

(3) 使用Database Control，以SYSTEM用户身份连接数据库。

(4) 从数据库主页中，选择Availability选项卡，然后选择Manage部分的Schedule Backup链接。

(5) 在Schedule Backup窗口中，选择Customize

Backup部分中的Tablespaces单选按钮。单击Schedule Customized Backup按钮。

(6) 在Schedule Backup: Tablespaces窗口中，单击Add按钮。

(7) 在Tablespaces: Available

Tablespaces窗口中，选择新的NONCRIT表空间的单选按钮，然后单击Select按钮。

(8) 在Schedule Customized Backup: Tablespaces窗口中，单击Next按钮。

(9) 在Schedule Customized Backup: Options窗口中，保持默认值并单击Next按钮。

(10) 在Schedule Customized Backup: Settings窗口中，保持默认值并单击Next按钮。

(11) 在Schedule Customized Backup: Schedule窗口中，选择One

Time(Immediately)单选按钮，并单击Next按钮。

(12) 在Schedule Customized Backup: Review窗口中，研究脚本并单击Submit

Job按钮运行备份。

(13) 通过破坏新的数据文件模似磁盘失败。在Windows上，用Windows

Notepad打开文件，删除文件开始部分的几行并保存；使用Notepad很重要，因为它是少数几个会忽略Oracle置于数据文件上的文件锁的Windows实用程序之一。在Unix上，可使用任意编辑器，如Vi。确保删除的字符在文件开头，确保文件头受损。

(14) "冲刷"高速缓存区，这样ex16的下一次读取将需要从磁盘中读取：

alter system flush buffer_cache;

(15) 试着查询该表，确认文件已受损：

SQL>select * from ex16;

select * from ex16

ERROR at line 1:

ORA-01578: ORACLE data block corrupted (file # 7, block # 9)

ORA-01110: data file 7: 'C:\APP\ORACLE\ORADATA\ORCL\NONCRIT.DBF'

(16) 在Database

Control会话中，从数据库主页中选择Availability选项卡，然后选择Manage部分的Perform

Recovery链接。

(17) 在Perform Recovery: Type窗口中，选择Datafiles With Error链接。

(18) 在Perform Object Level Recovery:

Datafiles窗口中，将列出新的数据文件。选择它并单击Next按钮。

(19) 在Perform Object Level Recovery: Rename窗口中，单击Next按钮。

(20) 在Perform Object Level Recovery: Review窗口中，单击Submit按钮。

(21) 在Perform Recovery: Result窗口中，研究操作的输出，如图16-4所示。

(点击查看大图)图16-4 演示图

(22) 确认表空间及其中的表现在是可用的，没有数据丢失。

SQL>select * from ex16;

21-OCT-08

对于完整恢复的4个步骤来说，如果文件是非关键的，第一步(使受损文件脱机)将是自动的。之后两个步骤(还原和恢复)可用RMAN命令完成，最后一步(使数据文件联机)可用SQL*Plus或RMAN完成。Database

Control生成的脚本自动化整个过程。

如果已使用增量备份策略，还原和恢复操作将利用级别0增量备份，然后应用可用的任意增量级别1备份，之后应用重做数据完成恢复。这一方法(使对重做的使用最小化)背后的逻辑是应用增量备份总是比应用重做要快，因为增量备份可在单次有序通过数据文件时应用，而应用重做(由年月顺序排列的变更向量构成)将会随机访问数据文件。增量备份存在与否并不会导致使用RECOVER命令时的语法差别；RMAN通过询问其存储库，将计算出执行操作的最好方式。

考点：

RMAN将总是优先于应用重做数据来应用增量备份(如果可用)。

3)在丢失关键数据文件时恢复

组成SYSTEM和当前活动撤销表空间的数据文件被Oracle视为是关键的，这意味着如果它们受损，则不可能使数据库处于打开状态。如果SYSTEM表空间的任一部分不可用，部分数据目录将缺失。在没有完整的数据目录情况下，Oracle不能起作用。如果部分撤销表空间不可用，则维护事务完整性和隔离性所需的撤销数据可能也不可用，Oracle同样不能起作用。因此，这些数据文件受损将导致实例立即终止。

提示：

关键数据文件应放在提供硬件冗余的磁盘系统上，如RAID级别1磁盘镜像，这样如果介质失败，文件将幸存并且数据库将保持打开状态。

如果数据库因为关键数据文件损坏而崩溃，那么第一行动就是试着启动它。这将在加载模式下停止，同时将错误消息写入警报日志，表明受损程度。要进行恢复，可以采取和非关键文件一样的例程，然后打开数据库。还原和恢复过程与对非关键文件所采取的过程相同，但必须在加载模式下进行。对于完整恢复的4个步骤，如果受损的文件是关键文件，则只需要第二、三步：因为数据库不能打开，所以不需要使受损文件脱机并且之后又使它联机。

考点：

关键数据文件的丢失并不意味着数据丢失，但意味着时间的丢失。

不完整恢复

不完整意味着丢失数据。通过还原所有数据文件将整个数据库回退，然后执行不完整恢复。不是应用自备份后生成的所有重做，而是故意在某个点停止应用重做，生成一个不是最新的数据库版本。自该点后做的所有工作丢失。执行不完整恢复只有两个原因：完整恢复不可行或是故意要丢失数据。

完整恢复将是不可能的，除非自备份后生成的所有归档日志以及联机重做日志可用。如果归档日志缺失或是被破坏，那恢复将在该点停止。完整恢复不会因为缺失归档或联机日志文件而失败，因为这两种文件类型都可以且应多路复用到不同设备，使得它们完全丢失是不可能的，但也是会发生的。如果发生这种情况，则不完整恢复至缺失或损坏的重做数据发生的点是唯一选择。

考点：

如果缺失归档日志或当前联机重做日志文件组的所有副本缺失，那么必须执行不完整恢复。

决定故意丢失数据是在用户错误发生后采取的行动。可能是用户提交了一个不适合业务需求的事务。这类错误可能包括非常普通的错误--在使用程序包软件时，我们都会犯错，但更常见的是使用像SQL*Plus这样的工具时犯的错。在发出UPDATE或DELETE语句时遗漏WHERE子句将导致整个表受影响，而不只是一行；如果提交了这一更改(可能是通过退出工具)，那么更改不可逆。对Oracle来说，它是个已提交的事务，不能回滚。更糟的是发出DDL命令的情况。这些命令包括隐式COMMIT语句。例如，您很容易会在认为自己是连接开发数据库而实际是连接生产数据库时，删除一个表甚至一个模式。

对于用户错误，可以还原整个数据库并将它恢复至错误发生前的点，从而生成没有错误的数据库版本，当然也不包括自那之后做的所有正确的工作。

提示：

有一些闪回技术可帮助从用户错误中恢复，而不一定要执行不完整恢复。

考点：

跳过坏事务的恢复而恢复所有其他工作是不可能的。

不完整恢复的特例是控件文件的恢复。在理想情况下，所有恢复操作将使用当前控制文件来引导，但有时是不可能的，并且必须还原控制文件的备份。可能的原因有两个：当前控制文件的所有副本已丢失，不能运行CREATE

CONTROLFILE命令重新创建它，或者当前控制文件不能准确描述想要还原的数据库版本，通常因为像删除表空间这样的更改在备份后已发生。

不完整恢复分成4步骤：

加载数据库

还原所有数据文件

恢复数据库至某个点

用重置日志打开数据库

与完整恢复形成对照的第一点是完整恢复可在数据库打开时进行，除非受损文件是关键的。不完整恢复只能在加载模式下进行。

其次，对于完整恢复，只还原受损的数据文件；不完整恢复操作还原所有数据文件。数据文件不必从相同备份中还原，但它们必须都早于想恢复到的点。如果当前数据库的物理结构与被还原的版本的结构不同，则不必还原控件文件以及数据文件。例如，如果表空间被无意间删除，当前控制文件将对此一无所知。还原构成表空间的数据文件则没有帮助：当前控制文件将忽略它们，不在恢复中包括它们。在必要时才还原控制文件；如果这样做的话，将是复杂的事情。

第三步是将归档和(如果必要)联机日志的重做数据应用到所需的点。这与完整恢复不同，在完整恢复中是应用所有重做使数据库保持最新；对于不完整恢复，是在最近时间前的任意一点停止恢复。有几个选项可用于指定想恢复到的点。

最后，用RESETLOGS打开数据库。这将重新初始化联机重做日志文件，创建数据库的一个新化身(incarnation)。数据库的化身是带有新的重做线程(日志序列号从1开始)的数据库版本。这是与完整恢复的最后一个不同点。在完整恢复后，数据库与问题发生前一样，但在不完整恢复后，它是个不同的化身。备份和归档日志是特定于一个化身的，由一个化身生成的备份和归档日志必须与前一化身生成的备份和归档日志相分离。

考点：

必须以SYSDBA身份连接进行不完整恢复。普通用户和SYSOPER用户都不行。

加载数据库并还原所有数据文件和(如果必要)控制文件后，对于不完整恢复操作有三个选项：

UNTIL TIME

UNTIL SCN(system change number)

UNTIL SEQUENCE

UNTIL

TIME选项将应用重做前滚数据文件至一个特定时间。精度为秒。该选项通常用于纠正用户错误。如果用户犯了不可逆的错误，但知道犯错误的时间，那么基于时间恢复至错误发生之前是最好的选择。

如果已知错误发生时的确切的系统变更号，那么可使用UNTIL SCN选项。通过使用像Log

Miner实用程序这样的高级工具或是使用第19章将详述的闪回功能，可以确定提交事务时的SCN。这可以准确地将恢复停在错误发生之前，从而尽可能少地丢失数据。

如果归档日志文件或联机日志文件组缺失，则使用UNTIL

SEQUENCE选项；它会将至日志切换前的所有工作恢复到缺失的文件或组中。