丢失归档日志文件后数据库应当如何恢复[1]

本文主要介绍了如何从一个不能正常打开的数据库(由于一个/多个数据库文件与其他文件不一致)中提取数据的具体示例 详细内容请大家参考下文

具体案例

一个磁盘损坏了并且丢失了一个数据库文件 从一周前的热备转储数据文件 可是丢失了几个归档日志文件 但是有问题的数据文件包含了最重要的表 采用什么办法才能挽救数据呢

解决方法

每个数据库管理员都知道这是有问题的 一定会丢失数据 因为某些事务丢失了 问题是会丢失多少数据Oracle使用硬线路位置并且由于存在完整性约束问题 因此不允许正常打开数据 但是如果使用非常规的方法让Oracle删除其硬线路属性 那么应该能够提取尽可能多的数据 而通常这会比损失全部数据要好很多

通常假如仅仅丢失了堆表的索引 或者某些能够很容易重建的数据 那么最好的方法应该是删除表空间并重建这些对象然后重新输入 但是如果丢失的数据文件包含了重要数据并且很难恢复 而且只有前一次的备份却又丢失了某些归档日志 那么用户可能希望能够尽可能多的从有问题的表空间恢复数据并且删除和重建表空间

具体步骤如下

对当前拥有的数据进行一个冷备;

转储丢失的数据库文件备份并应用可以应用的日志;

设置未文档化的初始化参数 其允许你在当前状态打开数据库;

执行exp并提取全部可以从有问题的表空间提取的数据;

从先前的冷备转储数据库;

使毁坏的数据文件offline;

执行exp并提取第 步没有提取的额外数据;

在一次从冷备转储;

删除有问题的表空间;

重建有问题的表空间;

使用第四步和第七步提取的数据重建数据;

使用案例描述 ORDTAB表空间的一个数据文件ordtab dbf毁坏 其包含很多

ORDERS表的分区 数据文件热备于July July —至今的某些归档日志丢失

第 步 备份数据库

第 步的任务是冷备当前拥有的任何数据文件 在线重做日志 和控制文件 如果丢失了一个/多个数据文件但是数据库仍然是open的 那么对每个剩余的数据文件进行热备并确保备份期间/之后的归档被安全保存

创建备份后 在关闭数据库之前 备份一下控制文件

ALTER DATABASE BACKUP CONTROLFILE TO TRACE RESETLOGS;

然后打开备份的控制文件 删除第一个#之上的所有行 并删除 RECOVER DATABASE… 到文件结尾的全部

第 步 转储丢失的数据库文件备份并应用日志;

这一步应该转储备份 并应用日志到直到无法在前向滚动 此时如果尝试正常打开数据库 将会得到ORA : must use RESETLOGS or NORESETLOGS option for database open错误

如果尝试执行ALTER DATABASE OPEN RESETLOGS 将会得到ORA 错误 ORA : online backup of file %s needs more recovery to be consistent

lishixinzhi/Article/program/SQL/201311/16189

1 NOARCHIVELOG模式

如果在NOARCHIVELOG模式下丢失数据库中的任何数据文件，则需要完全恢复数据库，包括控制文件和所有数据文件。

如果数据库处于NOARCHIVELOG模式，则只能在最后一次备份之前恢复。因此，用户必须重新输入自备份以来所做的所有更改。

使用Enterprise Manager Cloud Control来执行这种类型的恢复:

如果还没有关闭实例，则关闭它。

选择可用性>备份和恢复>执行恢复。

选择整个数据库作为恢复类型。

如果有一个处于NOARCHIVELOG模式、具有增量备份策略的数据库，则RMAN首先还原最近的0级，然后RMAN恢复应用增量备份

2 ARCHIVELOG模式

如果数据库处于ARCHIVELOG模式，那么丢失不属于系统或UNDO表空间的任何数据文件只会影响丢失文件中的对象。数据库的其余部分仍然可供用户继续工作。

3 关键文件损坏

属于系统表空间或包含撤消数据的数据文件被认为是系统关键文件。丢失其中一个文件需要从挂载状态恢复数据库(不像其他数据文件可以在数据库打开时恢复)。

使用Enterprise Manager Cloud Control执行此恢复:

如果实例还没有关闭，请关闭它。

挂载数据库。

选择可用性>备份和恢复>执行恢复。

在用户定向恢复部分，在恢复范围菜单中选择Datafiles，然后选择“恢复到当前时间”。

单击“添加”以选择需要恢复的所有数据文件。

指定是否要将文件恢复到默认位置，或者(如果缺少磁盘或控制器)恢复到新位置。

提交RMAN作业以恢复和恢复丢失的文件。

打开数据库。恢复到最后一次提交时为止。

新增archives 时的状况：

条件和假设：自上次镜像备份以来已经生成新的archive log(s); Archivelog Mode; 有同步的datafile(s) 和control file(s) 的镜像（冷）拷贝；archive log(s) 可用。

恢复步骤：

1 如果数据库尚未关闭，则首先把它关闭： $ svrmgrl svrmgrl> connect internal

svrmgrl> shutdown abort

2 将备份文件抄送回原始地点： 所有Database Files

所有Control Files（没有archive(s) 或redo(s) 的情况下，control files 的更新无任何意义）

所有On-Line Redo Logs (Not archives) initora file（选项）

3 启动数据库： $ svrmgrl

svrmgrl> connect internal

svrmgrl> startup

数据文件, 重作日志和控制文件同时丢失或损坏：

条件和假设：Archivelog Mode; 有同步的所有所失文件的镜像（冷）拷贝；archive log(s) 可用

恢复步骤（必须采用不完全恢复的手法）：

1 如果数据库尚未关闭，则首先把它关闭： $ svrmgrl svrmgrl> connect internal

svrmgrl> shutdown abort

2 将备份文件抄送回原始地点：

所有Database Files

所有Control Files

所有On-Line Redo Logs(Not archives)

initora file（选项）

3 启动数据库然而并不打开：

svrmgrl>startup mount

4 做不完全数据库恢复，应用所有从上次镜像（冷）备份始积累起来的archives：

svrmgrl> recover database until cancel using backup controlfile;

cancel

5 Reset the logfiles （对启动而言不可省略）：

svrmgrl> alter database open resetlogs;

6 关闭数据库并做一次全库冷备份。

数据文件和控制文件同时丢失或损坏：

条件和假设：Archivelog Mode; 有同步的datafile(s) 和control file(s) 的冷拷贝；archive log(s) 可用

恢复步骤：

1 将冷拷贝的datafiles(s) 和control file(s) 抄送回原始地点:

$ cp /backup/good_onedbf /orig_loc/bad_onedbf

$ cp /backup/control1ctl /disk1/control1ctl

2 以mount 选项启动数据库：

$ svrmgrl

svrmgrl> connect internal

svrmgrl> startup mount

3 以旧的control file 来恢复数据库：

svrmgrl> recover database until cancel using backup controlfile;

介质恢复完成

（须在应用完最后一个archive log 后cancel ）

4 Reset the logfiles （对启动而言不可省略）：

svrmgrl> alter database open resetlogs;

重作日志和控制文件同时丢失或损坏时：

条件和假设：Control Files 全部丢失或损坏；Archivelog Mode; 有Control Files 的镜像（冷）拷贝

恢复步骤：

1 如果数据库尚未关闭，则首先把它关闭：

$ svrmgrl

svrmgrl> connect internal

svrmgrl> shutdown abort

svrmgrl>exit

2 以Control File 的镜像（冷）拷贝覆盖损坏了的Control File:

$ cp /backup/control1ctl /disk1/control1ctl

3 启动数据库然而并不打开：

$ svrmgrl

svrmgrl> connect internal

svrmgrl> startup mount

4 Drop 坏掉的redo log （排除硬件故障）：

svrmgrl> alter database drop logfile group 2;

5 重新创建redo log:

svrmgrl> alter database add logfile group 2 '/orig_loc/log2dbf' size 10M;

6 以旧的control file 来恢复数据库：

svrmgrl> recover database until cancel using backup controlfile;

（必须马上cancel ）

7 Reset the logfiles （对启动而言不可省略）：

svrmgrl> alter database open resetlogs;

8 关闭数据库并做一次全库冷备份

只发生归档重作日志丢失或损坏时：

根据不同环境和情况，选择下述手段之一：

a 马上backup 全部datafiles （如果系统采用一般热备份或RMAN 热备份）

b 马上正常关闭数据库并进行冷备份（如果系统采用冷备份）

c 冒险前进！不做备份而让数据库接着跑，直等到下一个备份周期再做备份。这是在赌数据库在下一个备份周期到来之前不会有需要恢复的错误发生。

注意:冒险前进的选择：如果发生错误而需要数据库恢复，则最多只能恢复到出问题archive log 之前的 *** 作现场。从另一个角度讲，archive log(s) 出现问题时，数据库若不需要恢复则其本身并没有任何问题。

Oracle逻辑结构故障的处理方法：

逻辑结构的故障一般指由于人为的误 *** 作而导致重要数据丢失的情况。在这种情况下数据库物理结构是完整的也是一致的。对于这种情况采取对原来数据库的全恢复是不合适的，我们一般采用三种方法来恢复用户数据。

采用exp/imp工具来恢复用户数据：

如果丢失的数据存在一个以前用exp命令的备份，则可以才用这种方式。

1 在数据库内创建一个临时用户：

svrmgrl>create user test_user identified by test;

svrmgrl>grant connect，resource to test_user;

2 从以前exp命令备份的文件中把丢失数据的表按照用户方式倒入测试用户：

$imp system/manager file=export_file_name tables=(lost_data_table_name…) fromuser=lost_data_table_owner touser=test_user constraint=n;

3 用相应的DML语句将丢失的数据从测试用户恢复到原用户。

4 将测试用户删除：

svrmgrl>drop user test_user cascede;

采用logminer来恢复用户数据：

Logminer是oracle提供的一个日志分析工具。它可以根据数据字典对在线联机日志、归档日志进行分析，从而可以获得数据库的各种DML *** 作的历史记录以及各种DML *** 作的回退信息。根据这些用户就可以将由于误 *** 作而丢失的数据重新加入数据库内。

1 确认数据库的utl_file_dir参数已经设置，如果没有则需要把这个参数加入oracle的初始化参数文件，然后重新启动数据库。下面例子中假设utl_file_dir=’/opt/oracle/db01’；

2 创建logminer所需要的数据字典信息，假设生成的数据字典文本文件为dictora：

svrmgrl>execute dbms_logmnr_dbuild(dictionary_filename=>'dictora'， dictionary_location=>'/opt/oracle/db01’);

3 确定所需要分析的日志或者归档日志的范围。这可以根据用户误 *** 作的时间来确定大概的日志范围。假设用户误 *** 作时可能的日志文件为/opt/oracle/db02/oradata/ORCL/redo3log和归档日志’/opt/oracle/arch/orcl/orclarc_1_113ora’。

4 创建要分析的日志文件列表，按日志文件的先后顺序依次加入：

svrmgrl>execute dbms_logmnradd_logfile(logfilename=>’/opt/oracle/arch/orcl/orclarc_1_113ora’，options=>dbms_logmnrNEW);

svrmgrl> execute dbms_logmnradd_logfile(logfilename=>’ /opt/oracle/db02/oradata/ORCL/redo3log’，options=>dbms_logmnrADDFILE);

5 开始日志分析，假设需要分析的时间在’2003-06-28 12:00:00’和’2003-06-28 13:00:00’之间：

svrmgrl>execute dbms_logmnrstart_logmnr(dictfilename=>’ /opt/oracle/db01/dictora’，starttime=>to_date(’ 2003-06-28 12:00:00’，’YYYY-MM-DD HH:MI:SS’)，endtime=>to_date(to_date(‘2003-06-28 13:00:00’，’YYYY-MM-DD HH:MI:SS’));

6 获取分析结果：

svrmgrl>select operation，sql_redo，sql_undo from v$logmnr_contents;

7 根据分析结果修复数据。

8结束logmnr:

svrmgrl>dbms_logmnrend_logmnr;

9 用适当的方法对原数据库进行数据库全备份。

利用备份恢复用户数据：

采用这种方法时并不是在原数据库进行恢复，而是利用数据库备份在新的机器上重新建立一个新的数据库。通过备份恢复在新机器上将数据库恢复到用户误 *** 作前，这样就可以获得丢失的数据将其恢复到原数据库。

1 在新的机器上安装数据库软件。

2 对于采用带库备份的现场，需要在新的数据库服务器上安装调试相应的备份管软件。

3 根据用户误 *** 作的时间点进行基于时间点的数据库恢复 *** 作。对于没有采用带库备份的现场，可以选取用户误 *** 作前最近的备份磁带进行恢复；对于才用带库备份的点可以通过基于时间恢复点恢复的rman脚本来进行恢复。

4重新打开数据库：

svrmgrl>alter database open resetlogs;

5 从新的数据库中获取丢失的用户数据，通过DML *** 作将其恢复到原数据库中。

6 用适当的方法对原数据库进行数据库全备份。

使用高级恢复，然后选中保存自动恢复信息，最后点击“确定”完成设置，表现为在“文件”菜单下增添一项“Recovery”命令，并在该窗口中列出已自动恢复的所有文件。

一般出现文件丢失的原因是：杀毒造成错误删除系统文件、安装卸载某些软件造成、病毒或木马原因、用一些优化系统的工具优化等原因系统造成。不是硬件的问题，硬件只能与安装的软件不兼容，造成死机等现象，而不会使系统文件丢失。

性质相同的记录组成的集合。按记录的类型不同，分 *** 作系统文件和数据库文件两类。 *** 作系统中的文件仅是一维的连续的字符序列，其中的记录仅是一个字符组。数据库中的文件是带有结构的记录的集合，由一个或多个数据项组成。

1、 ORACLE 实例――包括内存结构与后台进程 2、 ORACLE 数据库――物理 *** 作系统文件的集合 3、 了解内存结构的组成 4、 了解后台进程的作用

1、 Oracle 实例――包括内存结构与后台进程

2、 Oracle 数据库――物理 *** 作系统文件的集合

3、 了解内存结构的组成

4、 了解后台进程的作用

5、 了解数据库的物理文件

6、 解释各种逻辑结构

一、Oracle实例

1、Oracle 实例

System Global Area(SGA) 和 Background Process 称为数据库的实例。

2、Oracle 数据库

一系列物理文件的集合（数据文件，控制文件，联机日志，参数文件等）

3、系统全局共享区System Global Area(SGA)

System Global Area 是一块巨大的共享内存区域，他被看做是Oracle 数据库的一个大缓冲池，这里的数据可以被Oracle的各个进程共用。其大小可以通过如下语句查看：

SQL> select from v$sga;

NAME VALUE

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

Fixed Size 39816

Variable Size 259812784

Database Buffers 1049E+09

Redo Buffers 327680

更详细的信息可以参考V$sgastat、V$buffer_pool

主要包括以下几个部分：

a、 共享池(Shared pool)

共享池是SGA中最关键的内存片段，特别是在性能和可伸缩性上。一个太小的共享池会扼杀性能，使系统停止，太大的共享池也会有同样的效果，将会消耗大量的CPU来管理这个共享池。不正确的使用共享池只会带来灾难。共享池主要又可以分为以下两个部分：

SQL语句缓冲(Library Cache)

当一个用户提交一个SQL语句，Oracle会将这句SQL进行分析(parse)，这个过程类似于编译，会耗费相对较多的时间。在分析完这个SQL，Oracle会把他的分析结果给保存在Shared pool的Library Cache中，当数据库第二次执行该SQL时，Oracle自动跳过这个分析过程，从而减少了系统运行的时间。这也是为什么第一次运行的SQL 比第二次运行的SQL要慢一点的原因。

下面举例说明parse的时间

SQL> select count() fromscpass ;

COUNT()

----------

243

Elapsed: 00:00:0008

这是在Share_pool 和Data buffer 都没有数据缓冲区的情况下所用的时间

SQL> alter system flush SHARED_POOL;

System altered

清空Share_pool，保留Data buffer

SQL> select count() from scpass ;

COUNT()

----------

243

Elapsed: 00:00:0002

SQL> select count() from scpass ;

COUNT()

----------

243

Elapsed: 00:00:0000

从两句SQL 的时间差上可以看出该SQL 的Parse 时间约为00:00:0002

对于保存在共享池中的SQL语句，可以从V$Sqltext、v$Sqlarea中查询到，对于编程者来说，要尽量提高语句的重用率，减少语句的分析时间。一个设计的差的应用程序可以毁掉整个数据库的Share pool，提高SQL语句的重用率必须先养成良好的变成习惯，尽量使用Bind变量。

数据字典缓冲区(Data Dictionary Cache)

显而易见，数据字典缓冲区是Oracle特地为数据字典准备的一块缓冲池，供Oracle内部使用，没有什么可以说的。

b、块缓冲区高速缓存(Database Buffer Cache)

这些缓冲是对应所有数据文件中的一些被使用到的数据块。让他们能够在内存中进行 *** 作。在这个级别里没有系统文件,，户数据文件，临时数据文件，回滚段文件之分。也就是任何文件的数据块都有可能被缓冲。数据库的任何修改都在该缓冲里完成，并由DBWR进程将修改后的数据写入磁盘。

这个缓冲区的块基本上在两个不同的列表中管理。一个是块的“脏”表(Dirty List)，需要用数据库块的

书写器(DBWR)来写入，另外一个是不脏的块的列表(Free List)，一般的情况下，是使用最近最少使用 (Least Recently Used,LRU)算法来管理。块缓冲区高速缓存又可以细分为以下三个部分（Default pool,Keep pool,Recycle pool）。如果不是人为设置初始化参数(Initora)，Oracle将默认为Default pool。由于 *** 作系统寻址能力的限制，不通过特殊设置，在32位的系统上，块缓冲区高速缓存最大可以达到17G，在64位系统上，块缓冲区高速缓存最大可以达到10G。

c、重做日志缓冲区(Redo log buffer)

重做日志文件的缓冲区，对数据库的任何修改都按顺序被记录在该缓冲，然后由LGWR进程将它写入磁盘。这些修改信息可能是DML语句，如(Insert,Update,Delete)，或DDL语句，如(Create,Alter,Drop等)。 重做日志缓冲区的存在是因为内存到内存的 *** 作比较内存到硬盘的速度快很多，所以重作日志缓冲区可以加快数据库的 *** 作速度，但是考虑的数据库的一致性与可恢复性，数据在重做日志缓冲区中的滞留时间不会很长。所以重作日志缓冲区一般都很小，大于3M之后的重作日志缓冲区已经没有太大的实际意义。

d、Java程序缓冲区(Java Pool)

Java 的程序区，Oracle 8I 以后，Oracle 在内核中加入了对Java的支持。该程序缓冲区就是为Java 程序保留的。如果不用Java程序没有必要改变该缓冲区的默认大小。

e、大池(Large Pool)

大池的得名不是因为大，而是因为它用来分配大块的内存，处理比共享池更大的内存，在80开始引入。

下面对象使用大池：

MTS――在SGA的Large Pool中分配UGA

语句的并行查询(Parallel Executeion of Statements)――允许进程间消息缓冲区的分配，用来协调 并行查询服务器

备份(Backup)――用于RMAN磁盘I/O缓存

4、后台进程(Background process)

后台进程是Oracle的程序，用来管理数据库的读写，恢复和监视等工作。Server Process主要是通过他和user process进行联系和沟通，并由他和user process进行数据的交换。在Unix机器上，Oracle后台进程相对于 *** 作系统进程，也就是说，一个Oracle后台进程将启动一个 *** 作系统进程；在Windows机器上， Oracle后台进程相对于 *** 作系统线程，打开任务管理器，我们只能看到一个OracleEXE的进程，但是通过另外的工具，就可以看到包含在这里进程中的线程。

在Unix上可以通过如下方法查看后台进程：

ps ef | grep ora_

# ps -ef | grep ora_ | grep XCLUAT

Oracle 29431 1 0 Sep 02 2:02 ora_dbwr_SID

Oracle 29444 1 0 Sep 02 0:03 ora_ckpt_SID

Oracle 29448 1 0 Sep 02 2:42 ora_smon_SID

Oracle 29442 1 0 Sep 02 3:25 ora_lgwr_SID

Oracle 29427 1 0 Sep 02 0:01 ora_pmon_SID

a、Oracle系统有5 个基本进程他们是

DBWR(数据文件写入进程)

LGWR(日志文件写入进程)

SMON(系统监护进程)

PMON(用户进程监护进程)

CKPT(检查点进程,同步数据文件, 日志文件,控制文件)

b、DBWR

将修改过的数据缓冲区的数据写入对应数据文件

维护系统内的空缓冲区

这里指出几个容易错误的概念:

当一个更新提交后,DBWR把数据写到磁盘并返回给用户提交完成

DBWR会触发CKPT 后台进程

DBWR不会触发LGWR 进程

上面的概念都是错误的

DBWR是一个很底层的工作进程，他批量的把缓冲区的数据写入磁盘。和任何前台用户的进程几乎没有什么关系，也不受他们的控制。至于DBWR会不会触发LGWR和CKPT进程，我们将在下面几节里讨论。

DBWR工作的主要条件如下

DBWR 超时

系统中没有多的空缓冲区用来存放数据

CKPT 进程触发DBWR 等

c、LGWR

将重做日志缓冲区的数据写入重做日志文件，LGWR是一个必须和前台用户进程通信的进程。当数据被修改的时候，系统会产生一个重做日志并记录在重做日志缓冲区内。这个重做日志可以类似的认为是以下的一个结构:

SCN=000000001000

数据块ID

对象ID=0801

数据行=02

修改后的数据=0011

提交的时候，LGWR必须将被修改的数据的重做日志缓冲区内数据写入日志数据文件，然后再通知前台进程提交成功，并由前台进程通知用户。从这点可以看出LGWR承担了维护系统数据完整性的任务。

LGWR 工作的主要条件如下

用户提交

有1/3 重做日志缓冲区未被写入磁盘

有大于1M 重做日志缓冲区未被写入磁盘

超时

DBWR需要写入的数据的SCN号大于LGWR 记录的SCN号，DBWR 触发LGWR写入

d、SMON

工作主要包含

清除临时空间

在系统启动时，完成系统实例恢复

聚结空闲空间

从不可用的文件中恢复事务的活动

OPS中失败节点的实例恢复

清除OBJ$表

缩减回滚段

使回滚段脱机

e、PMON

主要用于清除失效的用户进程，释放用户进程所用的资源。如PMON将回滚未提交的工作，释放锁，释放分配给失败进程的SGA资源。

f、CKPT

同步数据文件，日志文件和控制文件，由于DBWR/LGWR的工作原理，造成了数据文件，日志文件，控制文件的不一至，这就需要CKPT进程来同步。CKPT会更新数据文件/控制文件的头信息。

CKPT工作的主要条件如下

在日志切换的时候

数据库用immediate ,transaction , normal 选项shutdown 数据库的时候

根据初始话文件LOG_CHECKPOINT_INTERVAL、LOG_CHECKPOINT_TIMEOUT、FAST_START_IO_TARGET 的设置的数值来确定

用户触发

以下进程的启动需要手工配置

g、ARCH

当数据库以归档方式运行的时候，Oracle会启动ARCH进程，当重做日志文件被写满时，日志文件进行切换，旧的重做日志文件就被ARCH进程复制到一个/多个特定的目录/远程机器。这些被复制的重做日志文件被叫做归档日志文件。

h、RECO

负责解决分布事物中的故障。Oracle可以连接远程的多个数据库，当由于网络问题，有些事物处于悬而未决的状态。RECO进程试图建立与远程服务器的通信，当故障消除后，RECO进程自动解决所有悬而未决的会话。

i、服务进程Server Process

服务进程的分类

专用服务进程(Dedicated Server Process)

一个服务进程对应一个用户进程

共享服务进程(MultiTreaded Server Process)

一个服务进程对应多个用户进程，轮流为用户进程服务。

PGA & UGA

PGA = Process Global Area

UGA = User Global Area

他保存了用户的变量、权限、堆栈、排序空间等用户信息，对于专用服务器进程，UGA在PGA中分配。对于多线程进程，UGA在Large pool中分配。

j、用户进程User Process

在客户端，将用户的SQL 语句传递给服务进程

5、一个贯穿数据库全局的概念----系统改变号SCN(System Change Number)

系统改变号，一个由系统内部维护的序列号。当系统需要更新的时候自动增加，他是系统中维持数据的一致性和顺序恢复的重要标志。

a 查询语句不会使SCN增加，就算是同时发生的更新，数据库内部对应的SCN也是不同的。这样一来就保证了数据恢复时候的顺序。

b 维持数据的一致性，当一

二、Oracle 数据库

Oracle数据库的组成――物理 *** 作系统文件的集合。主要包括以下几种。

1、控制文件（参数文件initora记录了控制文件的位置）

控制文件包括如下主要信息

数据库的名字，检查点信息，数据库创建的时间戳

所有的数据文件，联机日志文件，归档日志文件信息

备份信息等

有了这些信息，Oracle就知道那些文件是数据文件，现在的重做日志文件是哪些，这些都是系统启动和运行的基本条件，所以他是Oracle运行的根本。如果没有控制文件系统是不可能启动的。控制文件是非常重要的，一般采用多个镜相复制来保护控制文件，或采用RAID来保护控制文件。控制文件的丢失，将使数据库的恢复变的很复杂。

控制文件信息可以从V$Controlfile中查询获得

2、数据文件（数据文件的详细信息记载在控制文件中）

可以通过如下方式查看数据文件

SQL> select name from v$datafile;

NAME

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

/u05/dbf/PROD/system_01dbf

/u06/dbf/PROD/temp_01dbf

/u04/dbf/PROD/users_01dbf

/u09/dbf/PROD/rbs_01dbf

/u06/dbf/PROD/applsys_indx_01dbf

/u05/dbf/PROD/applsys_data_01dbf

从以上可以看出，数据文件大致可以分为以下几类：

i 系统数据文件(system_01dbf)

存放系统表和数据字典，一般不放用户的数据，但是用户脚本，如过程，函数，包等却是保存在数据字典中的。

名词解释：数据字典 数据字典是一些系统表或视图，他存放系统的信息，他包括数据库版本，数据文件信息，表与索引等段信息，系统的运行状态等各种和系统有关的信息和用户脚本信息。数据库管理员可以通过对数据字典的查询，就可以了解到Oracle的运行状态。

ii 回滚段文件(rbs_01dbf)

如果数据库进行对数据的修改，那么就必须使用回滚段，回滚段是用来临时存放修改前的数据(Before Image)。回滚段通常都放在一个单独的表空间上（回滚表空间），避免表空间碎片化，这个表空间包含的数据文件就是回滚数据文件。

iii 临时数据文件(temp_01dbf)

主要存放用户的排序等临时数据，与回滚段相似，临时段也容易引起表空间碎片化，而且没有办法在一个永久表空间上开辟临时段，所以就必须有一个临时表空间，它所包含的数据文件就是临时数据文件，主要用于不能在内存上进行的排序 *** 作。我们必须为用户指定一个临时表空间。

iv 用户数据文件(/applsys_data_01dbf ,applsys_indx_01dbf)

存放用户数据，这里列举了两类常见的用户型数据，一般数据和索引数据，一般来说，如果条件许可的话，可以考虑放在不同的磁盘上。

3、重做日志文件（联机重做日志）

用户对数据库进行的任何 *** 作都会记录在重做日志文件。在了解重做日志之前必须了解重做日志的两个概念，重做日志组和重做日志组成员(Member)，一个数据库中至少要有两个日志组文件，一组写完后再写另一组，即轮流写。每个日志组中至少有一个日志成员，一个日志组中的多个日志成员是镜相关系，有利于日志文件的保护，因为日志文件的损坏，特别是当前联机日志的损坏，对数据库的影响是巨大的。

联机日志组的交换过程叫做切换，需要特别注意的是，日志切换在一个优化效果不好的数据库中会引起临时的“挂起”。挂起大致有两种情况：

在归档情况下，需要归档的日志来不及归档，而联机日志又需要被重新利用

检查点事件还没有完成（日志切换引起检查点），而联机日志需要被重新利用

解决这种问题的常用手段是：

i增加日志组

ii增大日志文件成员大小

通过v$log可以查看日志组，v$logfile可以查看具体的成员文件。

4、归档日志文件

Oracle可以运行在两种模式之中，归档模式和不归档模式。如果不用归档模式，当然，你就不会有归档日志，但是，你的系统将不会是一个实用系统，特别是不能用于生产系统，因为你可能会丢失数据。但是在归档模式中，为了保存用户的所有修改，在重做日志文件切换后和被覆盖之间系统将他们另外保存成一组连续的文件系列，该文件系列就是归档日志文件。

有人或许会说，归档日志文件占领我大量的硬盘空间，其实，具体想一想，你是愿意浪费一点磁盘空间来保护你的数据，还是愿意丢失你的数据呢？显而义见，我们需要保证我们的数据的安全性。其实，归档并不是一直占领你的磁盘空间，你可以把她备份到磁带上，或则删除上一次完整备份前的所有日志文件。

5、初始化参数文件

initSIDora或initora文件，因为版本的不一样，其位置也可能会不一样。在8i中，通常位于$Oracle_HOME/admin//Pfile下，初始化文件记载了许多数据库的启动参数，如内存，控制文件，进程数等，在数据库启动的时候加载（Nomount时加载），初始化文件记录了很多重要参数，对数据库的性能影响很大，如果不是很了解，不要轻易乱改写，否则会引起数据库性能下降。

6、其他文件

i 密码文件

用于Oracle 的具有sysdba权限用户的认证

ii 日志文件

报警日志文件（alertlog或alrtora）

记录数据库启动，关闭和一些重要的出错信息。数据库管理员应该经常检查这个文件，并对出现的问题作出即使的反应。你可以通过以下SQL 找到他的路径select value from v$PARAMETER where name ="background_dump_dest";

后台或用户跟踪文件

系统进程或用户进程出错前写入的信息，一般不可能读懂，可以通过Oracle的TKPROF工具转化为可以读懂的格式。对于系统进程产生的跟踪文件与报警日志文件的路径一样，用户跟踪文件的路径，你可以通过以下SQL找到他的路径select value from v$PARAMETER where name ="user_dump_dest";

三、Oracle逻辑结构

1、 表空间(tablespace)

表空间是数据库中的基本逻辑结构，一系列数据文件的集合。一个表空间可以包含多个数据文件，但是一个数据文件只能属于一个表空间。

2、 段(Segment)

段是对象在数据库中占用的空间，虽然段和数据库对象是一一对应的，但段是从数据库存储的角度来看的。一个段只能属于一个表空间，当然一个表空间可以有多个段。

表空间和数据文件是物理存储上的一对多的关系，表空间和段是逻辑存储上的一对多的关系，段不直接和数据文件发生关系。一个段可以属于多个数据文件，关于段可以指定扩展到哪个数据文件上面。

段基本可以分为以下四种

数据段(Data Segment)

索引段(Index Segment)

回滚段(Rollback Segment)

临时段(Temporary Segment)

3、区间(Extent)

关于Extent的翻译有多种解释，有的译作扩展，有的译作盘区，我这里通常译为区间。在一个段中可以存在多个区间，区间是为数据一次性预留的一个较大的存储空间，直到那个区间被用满，数据库会继续申请一个新的预留存储空间，即新的区间，一直到段的最大区间数(Max Extent)或没有可用的磁盘空间可以申请。 在Oracle8i以上版本，理论上一个段可以无穷个区间，但是多个区间对Oracle却是有性能影响的，Oracle建议把数据分布在尽量少的区间上，以减少Oracle的管理与磁头的移动。

4、Oracle数据块(Block)

Oracle最基本的存储单位，他是OS数据块的整数倍。Oracle的 *** 作都是以块为基本单位，一个区间可以包含多个块（如果区间大小不是块大小的整数倍，Oracle实际也扩展到块的整数倍）。

5、基本表空间介绍

a 系统表空间

主要存放数据字典和内部系统表基表

查看数据数据字典的SQL

select from dict

查看内部系统表的SQL

select from v$fixed_view_definition

DBA对系统的系统表中的数据字典必须有一个很深刻的了解，他们必须准备一些基础的SQL语句，通过这些SQL可以立即了解系统的状况和数据库的状态，这些基本的SQL包括

系统的剩余空间

系统的SGA

状态系统的等待

用户的权限

当前的用户锁

缓冲区的使用状况等

在成为DBA 的道路上我们不建议你过分的依赖于OEM/Quest 等优秀的数据库管理工具，因为他们不利于你对数据数据字典的理解，SQL语句可以完成几乎全部的数据库管理工作。

大量的读少量的写是该表空间的一个显著的特点。

b 临时表空间

临时表空间顾名思义是用来存放临时数据的，例如排序 *** 作的临时空间，他的空间会在下次系统启动的时候全部被释放。

c 回滚段表空间

i 回滚段在系统中的作用

当数据库进行更新插入删除等 *** 作的时候，新的数据被更新到原来的数据文件，而旧的数据(Before Image)就被放到回滚段中，如果数据需要回滚，那么可以从回滚段将数据再复制到数据文件中。来完成数据的回滚。在系统恢复的时候， 回滚段可以用来回滚没有被commit 的数据，解决系统的一至性。

回滚段在什么情况下都是大量的写，一般是少量读，因此建议把回滚段单独出来放在一个单独的设备（如单独的磁盘或RAID），以减少磁盘的IO争用。

ii 回滚段的工作方式

一个回滚表空间可以被划分成多个回滚段

一个回滚段可以保存多个会话的数据

回滚段是一个圆形的数据模型

假设回滚段由4 个区间组成，他们的使用顺序就是区间1à区间2à区间3à区间4à区间1。也就是说，区间是可以循环使用的，当区间4到区间1的时候，区间1里面的会话还没有结束, 区间4用完后就不能再用区间1,这时系统必须分配区间5，来继续为其他会话服务服务。

我们分析一个Update 语句的完成

① 用户提交一个Update 语句

② Server Process 检查内存缓冲

如果没有该数据块的缓冲，则从磁盘读入

i 如果没有内存的有效空间，DBWR被启动将未写入磁盘的脏缓冲写入磁盘

ii 如果有有效空间，则读入

③ 在缓冲内更新数据

i 申请一个回滚段入口，将旧数据写如回滚段

ii 加锁并更新数据

iii 并在同时将修改记录在Redo log buffer中

另外,站长团上有产品团购,便宜有保证

在sql

server

2005

数据库中，一次误 *** 作，分离数据库后，直接将日志文件删除掉了，后进行附加出错，无法附加上去，经过如下解决方案，数据库附加成功， *** 作如下：

第一步：先建立一个同名数据库，停止sql

server2005，将原来的mdf数据库文件覆盖刚新建的mdf数据库文件，重新启动数据库。

第三步：在查询分析器中运行如下代码：

alter

database

你的mdf文件名

set

emergency

'--将数据库设置为紧急状态use

masterdeclare

@databasename

varchar(255)

set

@databasename='你的mdf文件名'

'--你的mdf文件文件名

exec

sp_dboption

@databasename,

n'single',

n'true'

--将目标数据库置为单用户状态

dbcc

checkdb(@databasename,repair_allow_data_loss)

dbcc

checkdb(@databasename,repair_rebuild)

exec

sp_dboption

@databasename,

n'single',

n'false'--将目标数据库置为多用户状态

以上就是关于丢失归档日志文件后数据库应当如何恢复[1]全部的内容，包括:丢失归档日志文件后数据库应当如何恢复[1]、wps表格数据丢失怎么恢复、数据库系统中的常见故障有哪些等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！