A. 数据库系统的故障有哪些类型恢复系统的主要功能是什么
可从三个方面去考虑：
1、硬件故障--主机硬件部分的损坏使数据库无法使用或部分数据丢失。
2、网络故障--线路故障、通信协议等森磨故障使客户无法访问数据库。
3、软件故障--操作系统、数据库系统软件故障使数据库无法启动，或者运行不正常。
恢复的主要功能有两个：恢复丢失此蚂斗物盯的数据和使数据库正常运行。
B. 系统有哪些可能的故障类型（来源），故障的处理策略是什么
不知道你问的是哪类系统故障？
下面以数据库为例介绍说明，希望对你有点参考价值。
在数据库运行过程中，可能会出现各种各样的故障，这些故障可分为以下三类：事务故障、系统故障和介质故障。应该根据故障类型的不同，采取不同的恢复策略。
1，事务故障及其恢复：
事务故障表示由非预期的、不正常的程序结束所造成的故障。
造成程序非正常结束的原因包括输人数据错误、运算溢出、违反存储保护、并行事务发生死锁等。
发生事务故障时，被迫中断的事务可能已对数据库进行丁修改，为了消除该事务对数据库的影响，要利用日志文件中所记载的信息，强行回滚（RoLLBAcK）该事务，将数据库恢复到修改前的初始状态。
为此，要检查日志文件中由这些事务所引起的发生变化的记录，取消这些没有完成的事务所做的一切改变。
这类恢复操作称为事务撤销（uNDo），具体做法如下。
（1）反向扫描日志文件，查找该事务的更新操作。
（2）对该事务的更新操作执行反操作，即对已经插入的新记录进行删除操作，对己删除的记录进行插入操作，对修改的数据恢复旧值，用旧值代替新值。这样由后向前逐个扫描该事务已做的所有更新操作，并做同样处理，直到扫描到此事务的开始标记，事务故障恢复完毕为止。
因此，一个事务是一个工作单位，也是一个恢复单位。一个事务越短，越便于对它进行UNDO操作。如果一个应用程序运行时间较长，则应该把该应用程序分成多个事务，用明确的coMMIT语句来结束各个事务。
腔中皮2，系统故障及其恢复系统故障是指系统在运行过程中，由于某种原因，造成系统停止运转，致使所有正在运行的事务都以非正常方式终止，要求系统重新启动。引起系统故障的原因可能有硬件错误（如CPu故障、操作系统）或DBMS代码错误、突然断电等。
这时，内存中数据库缓冲区的内容全部丢失，虽然存储在外部存储设备上的数据库并未破坏，但其内容不可靠了。系统故障发生后，对数据库的影响有以下两种情况。
一种情况是一些未完成事务对数据库的更新已写入数据库，这样在系统重新启动后，要强行撤销（uNDo）所有未完成的事务，清除这些事务对数据库所做的修改。这些末完成事务在日志文件中只有BEGIN TRANsLATl0N标记，而无COMMIT标记。
另一种情况是有些已提交的事务对数据库的更新结果还保留在缓冲区中，尚未写到磁盘上的物理数据库中，这也使数据库处于不一致状态，因此应将这些事务已提交的结果重新写入数据库。这类恢复操作称为事务的重做（REDo）。这种巳提交事务在日志文件中既有BGIN TRANSCATION标记，也有COMMIT标记。
因此，系统故障的恢复要完伍差成两方面的工作，既要撤销所有末完成的事务，还要重做所有已提交的事务，这样才能将数据库真正恢复到一致的状态。具体做法如下。
（1）正向扫描日志文件，查找尚未提交的事务，将其事务标识记人撤销队列。同时查找已经提交的事务，将其事务标识记入重做队列。
（2）对撤销队列中的各个事务进行撤销处理。方法同事务故障中所介绍的撤销方法。
（3）对重做队列中的各个事务进行重做处理。进行重做处理的方法是正向扫描日志文件，按照日志文件中所登记的操作内容，重新执行操作，使数据库恢复到最近某个可用状态。
系统发生故障后，由于无法确定哪些末完成培陵的事务已更新过数据库，哪些事务的提交结果尚未写入数据库，因此系统重新启动后，就要撤销所有的末完成的事务，重做所有的已经提交的事务。
但是，在故障发生前已经运行完毕的事务有些是正常结束的，有些是异常结束的。所以无须把它们全部撤销或重做。
通常采用设立检查点（checkPoint）的方法来判断事务是否正常结束。每隔一段时间，比如说5分钟，系统就产生一个检查点，做下面一些事情：a,把仍保留在日志缓冲区中的内容写到日志文件中；b,在日志文件中写一个“检查点记录”；c,把数据库缓冲区中的内容写到数据库中，即把更新的内容写到物理数据库中；d,把日志文件中检查点记录的地址写到“重新启动文件”中。
每个检查点记录包含的信息有在检查点时间的所有活动事务一览表、每个事务最近日志记录的地址。
在重新启动时，恢复管理程序先从“重新启动文件”中获得检查点记录的地址，从日志文件中找到该检查点记录的内容，通过日志往回找，就能决定哪些事务需要撤销，恢复到初始的状态，哪些事务需要重做。为此利用检查点信息能做到及时、有效、正确地完成恢复工作。
3，介质故障及其恢复介质故障是指系统在运行过程中，由于辅助存储器介质受到破坏，使存储在外存中的数据部分或全部丢失。
这类故障比事务故障和系统故障发生的可能性要小，但这是最严重的一种故障，破坏性很大，磁盘上的物理数据和日志文件可能被破坏，这需要装入发生介质故障前最新的后备数据库副本，然后利用日志文件重做该副本后所运行的所有事务。
具体方法如下。
（1）装入最新的数据库副本，使数据库恢复到最近一次转储时的可用状态。
（2）装入最新的日志文件副本，根据日志文件中的内容重做已完成的事务。首先扫描日志文件，找出故障发生时己提交的事务，将其记入重做队列。然后正向扫描日志文件，对重做队列中的各个事务进行重做处理，方法是正向扫描日志文件，对每个重做事务重新执行登记的操作，即将日志记录中“更新后的值”写入数据库。
这样就可以将数据库恢复至故障前某一时刻的一致状态了。
C. 数据库故障可分为哪几类
数据库系统中故障可以分为：事务故障、系统故障、介质故障。
一、事务故障
某个事咐启弯务在运行过程中由于种种原因未运行至正常终止点，事务故障的常见原因，输入数据有误
运算溢出，违反了某些完整性限制发生锁死。
二、系统故障
由于某种原因造成整个系统的正常运行突然停止，致使所有正在运行的事务都以非正常方式终止。
发旁型生系统故障时，内存中数据库缓冲区的信息全部丢失，但存储在外部存储设备上的数据未受影响 。
三、介质故障
硬件故障使存储在外存中的数据部分丢失或全部丢失 ，介质故障比前衡闷两类故障的可能性小得多，但破坏性最大。
D. 数据库运行中可能产生的故障有哪几类
数据库系统中的故障可以分以下几稿知贺类：（1）事务内部的故障；（2）系统故障；（键派3）介质故障；（4）计算机猛迟病毒。事务故障、系统故障和介质故障影响事务的正常执行；介质故障和计算机病毒破坏数据库数据
E. 数据库系统中的常见故障有哪些
新增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) init.ora 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)
init.ora 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_one.dbf /orig_loc/bad_one.dbf
$ cp /backup/control1.ctl /disk1/control1.ctl
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/control1.ctl /disk1/control1.ctl
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/log2.dbf' 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所需要的数据字典信息，假设生成的数据字典文本文件为dict.ora：
svrmgrl>execute dbms_logmnr_d.build(dictionary_filename=>'dict.ora'， dictionary_location=>'/opt/oracle/db01’);
3. 确定所需要分析的日志或者归档日志的范围。这可以根据用户误操作的时间来确定大概的日志范围。假设用户误操作时可能的日志文件为/opt/oracle/db02/oradata/ORCL/redo3.log和归档日志’/opt/oracle/arch/orcl/orclarc_1_113.ora’。
4. 创建要分析的日志文件列表，按日志文件的先后顺序依次加入：
svrmgrl>execute dbms_logmnr.add_logfile(logfilename=>’/opt/oracle/arch/orcl/orclarc_1_113.ora’，options=>dbms_logmnr.NEW);
svrmgrl> execute dbms_logmnr.add_logfile(logfilename=>’ /opt/oracle/db02/oradata/ORCL/redo3.log’，options=>dbms_logmnr.ADDFILE);
5. 开始日志分析，假设需要分析的时间在’2003-06-28 12:00:00’和’2003-06-28 13:00:00’之间：
svrmgrl>execute dbms_logmnr.start_logmnr(dictfilename=>’ /opt/oracle/db01/dict.ora’，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_logmnr.end_logmnr;
9. 用适当的方法对原数据库进行数据库全备份。
利用备份恢复用户数据：
采用这种方法时并不是在原数据库进行恢复，而是利用数据库备份在新的机器上重新建立一个新的数据库。通过备份恢复在新机器上将数据库恢复到用户误操作前，这样就可以获得丢失的数据将其恢复到原数据库。
1. 在新的机器上安装数据库软件。
2. 对于采用带库备份的现场，需要在新的数据库服务器上安装调试相应的备份管软件。
3. 根据用户误操作的时间点进行基于时间点的数据库恢复操作。对于没有采用带库备份的现场，可以选取用户误操作前最近的备份磁带进行恢复；对于才用带库备份的点可以通过基于时间恢复点恢复的rman脚本来进行恢复。
4.重新打开数据库：
svrmgrl>alter database open resetlogs;
5. 从新的数据库中获取丢失的用户数据，通过DML操作将其恢复到原数据库中。
6. 用适当的方法对原数据库进行数据库全备份。
F. 数据库系统的故障有哪些类型
事务故障
系统故障
介质故障
一、事务故障
什么是事务故障
某个事务在运行过程中由于种种原因未运行至正常终止点
事务故障的常见原因
输入数据有误
运算溢出
违反了某些完整性限制
某些应用程序出错
并行事务发生死锁
事务故障（续）
事务故障的恢复
事务故障的恢复：事务撤消（UND）
恢复程序要在不影响其它事务运行的情况下，强行回滚（RBACK）该事务，即清除该事务对数据库的所有修改，使得这个事务象根本没有启动过一样
二、系统故障
什么是系统故障
由于某种原因造成整个系统的正常运行突然停止，致使所有正在运行的事务都以非正常方式终止。
发生系统故障时，内存中数据库缓冲区的信息全部丢失，但存储在外部存储设备上的数据未受影响
系统故障（续）
系统故障的常见原因
操作系统或DBMS 代码错误
操作员操作失误
特定类型的硬件错误（如CPU 故障）
突然停电
系统故障（续）
系统故障的恢复
1. 清除尚未完成的事务对数据库的所有修改
如果DBMS 无法确定哪些事务已更新过数据库，则系统重新启动后，恢复程序要强行撤消（UND ） 所有未完成事务，使这些事务象没有运行过一样。
2. 将已完成事务提交的结果写入数据库
如果DBMS 无法确定哪些事务的提交结果尚未写入物理数据库，则系统睁虚重新启动后，恢复程序需要重做（RED ） 所有已提交的事务。
三、介质故障
什么是介质故障
硬件故障使存储在外存中的数据部分丢失或全部丢失
介质故高裂障比前两类故障的可能性小得多，但破坏性最大。
介质故障(续)
介质故障的常见原因
硬件故障
磁盘损坏
磁头碰撞
操作系统的某种潜在错误
瞬时强磁场干扰
介质故障（续）
介质故障的恢复
装入 数据库发生介质故障前某个时刻的数据副本
重做自此时始的所有成功悉念燃事务 ，将这些事务已提交的结果重新记入数据库
故障的种类小结
数据库系统中各类故障对数据库的影响
数据库本身被破坏 （介质故障）
数据库处于不一致状态
数据库中包含了未完成事务对数据库的修改（事务故障、系统故障）
数据库中丢失了已提交事务对数据库的修改（系统故障）
不同类型的故障应采用不同的恢复操作
故障的种类小结（续）
恢复操作的基本原理：简单
原理：利用 存储在系统其它地方的冗余数据 来重建 数据库中已经被破坏或已经不正确的那部分数据
恢复的实现技术：复杂
一般一个大型数据库产品，恢复子系统的代码要占全部代码的10% 以上
G. 请说明造成数据库故障的可能的原因都有哪些每种情况下的应对措施是什么
一、事务内部的故障；
二、系型烂洞统故卜枯障；
三、介质故障历袭；
四、计算机病毒。
H. 数据库系统可能发生的故障种类有哪些
一、事务内部的故障；
二、系统故障；
三、介质故障；
四、计算机病毒。
大致就这四个故障，希望对你有所帮助。
I. 数据库运行中可能产生的故障有哪几类哪些故障影响事务的正常执行哪些破坏数据库数据
在我上的“数据库系统实现”课程中是分为一下四类：
错晌孙误数据输入
介质故障
灾难性故障
系统故障
但是有些书上给出的是：
一、事务内部信此的故障; 二、系统故障; 三、介质故障; 四、计算机病毒；五、用户操作错误
这个很难说谁的匪类对错，比如计算机病毒，这个可以算作系统故障，错误数据输入可以分为事务内部和用户操作
按照我自己课程的分类，错误数据输入和系统故障是影响事物正常执行的，而介质故障和灾难性故障是破坏数据库数据的
具体要看你们用什宴坦链么教材，毕竟不是我判卷:)
J. 数据库系统中故障可以分为哪几类
可以分为三类：
1.事务故障
2.系统故障
3.介质故障