数据库高手请进

答案选B

介质故障指的“硬故障”，也就是外存发生的故障，显然瞬间的强磁场干扰会导致内存故障

在题中：

A：中央处理器（CPU）故障、C：突然停电、还有D：操作系统故障都是造成的数据库系统停止运转，并不损坏外存中以存好的数据，都属于系统故障

其实，只要了解了介质故障是使外存发生故障，是“硬件故障”就很容易判断了

希望可以帮你o(∩_∩)o

数据库系统运行过程中的故障对数据库影响起来有哪两类

答案：C

系统可能发生的主要故障类型如下：①事务故障；②系统故障；③磁盘故障。硬件故障或者是数据库软件或操作系统的漏洞，导致系统停止运行。主存储器内容丢失，而外存储器仍完好无缺。这类故障称为系统故障。

请具体解释在数据库中什么是事务的内部故障

分为：事务故障、 系统故障、 介质故障

一、事务故障

什么是事务故障？

某个事务在运行过程中由于种种原因未运行至正常终止点 事务故障的常见原因 输入数据有误 运算溢出 违反了某些完整性限制 某些应用程序出错 并行事务发生死锁事务故障（续） 事务故障的恢复

事务故障的恢复：事务撤消（UND） 恢复程序要在不影响其它事务运行的情况下，强行回滚（RBACK）该事务，即清除该事务对数据库的所有修改，使得这个事务象根本没有启动过一样 二、系统故障

什么是系统故障 ？

由于某种原因造成整个系统的正常运行突然停止，致使所有正在运行的事务都以非正常方式终止。 发生系统故障时，内存中数据库缓冲区的信息全部丢失，但存储在外部存储设备上的数据未受影响 系统故障（续） 系统故障的常见原因 操作系统或DBMS 代码错误 操作员操作失误 特定类型的硬件错误（如CPU 故障） 突然停电 系统故障（续）

系统故障的恢复 1 清除尚未完成的事务对数据库的所有修改 如果DBMS 无法确定哪些事务已更新过数据库，则系统重新启动后，恢复程序要强行撤消（UND ） 所有未完成事务，使这些事务象没有运行过一样。2 将已完成事务提交的结果写入数据库 如果DBMS 无法确定哪些事务的提交结果尚未写入物理数据库，则系统重新启动后，恢复程序需要重做（RED ） 所有已提交的事务。

三、介质故障

什么是介质故障？

硬件故障使存储在外存中的数据部分丢失或全部丢失 介质故障比前两类故障的可能性小得多，但破坏性最大。 介质故障(续) 介质故障的常见原因 硬件故障 磁盘损坏 磁头碰撞 操作系统的某种潜在错误 瞬时强磁场干扰 介质故障（续） 介质故障的恢复 装入 数据库发生介质故障前某个时刻的数据副本 重做自此时始的所有成功事务 ，将这些事务已提交的结果重新记入数据库 故障的种类小结 数据库系统中各类故障对数据库的影响 数据库本身被破坏 （介质故障） 数据库处于不一致状态 数据库中包含了未完成事务对数据库的修改（事务故障、系统故障） 数据库中丢失了已提交事务对数据库的修改（系统故障）不同类型的故障应采用不同的恢复操作 故障的种类小结（续）

恢复操作的基本原理：简单 原理：利用 存储在系统其它地方的冗余数据 来重建 数据库中已经被破坏或已经不正确的那部分数据 恢复的实现技术：复杂 一般一个大型数据库产品，恢复子系统的代码要占全部代码的10% 以上。

希望能帮到楼主~~~也希望能成为最佳答案~~~要不都枉费了我打这么多字了啊

数据库系统中的常见故障有哪些

数据库系统故障可分为：事务内部故障、系统范围内故障、介质故障和计算机病毒四类。

１．事务内部故障

事务内部故障是指事务运行没有达到预期的终点，未能成功地提交事务，使数据库处于不正确状态。事务内部故障有的可以通过事务程序本身发现，是可预期的故障，但更多的是不可预期的故障，如数据溢出等。当发生事务内部故障时，可强行回滚（ROLLBACK）该事务，这类恢复操作称为撤消（UNDO）。

２．系统范围的故障

造成系统停止运行的任何事件都称为系统故障，如停电、操作系统故障。这类故障造成正在运行的事务非正常终止，数据库缓冲区中数据的丢失。若发生系统范围的故障，恢复子系统必须在系统重新启动时让所有非正常终止的事务回滚，若事务只作一半便发生故障，必须先撤消该事务，然后重做。

３．存储介质故障

系统故障又称软故障，存储介质故障称为硬故障。硬故障发生的可能性小，但破坏性极大。如硬盘损坏等。

４．计算机病毒

计算机病毒主要破坏计算机软件系统，由计算机病毒引起的故障属于系统范围的故障。

新增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 用适当的方法对原数据库进行数据库全备份。