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.介質故障