① 資料庫為什麼會損壞呢
資料庫損壞常見的原因有以下幾種：
1、事務日誌問題。比如事務日誌文件丟失；事務日誌文件在操作過程中被誤刪；事務日誌文件被損壞以及事務日誌文件過大，導致硬碟的空間不足等；
2、意外掉電或異常強制關機，造成數據文件損壞，主要資料庫正在被讀寫過程中異常關機；
3、資料庫的表被破壞或索引等被破壞，或者資料庫的其他對象被破壞或丟失等；
4、刪除了數據文件，或者更改了它的名字；
5、硬碟損壞，造成數據和日誌文件讀寫錯誤：
(1)感染病毒或者其他人為因素破壞；
(2)其他文件讀寫、存儲等原因
② 資料庫系統運行過程中的故障對資料庫影響起來有哪兩類
分為：事務故障、 系統故障、 介質故障
一、事務故障
什麼是事務故障？
某個事務在運行過程中由於種種原因未運行至正常終止點 事務故障的常見原因 輸入數據有誤 運算溢出 違反了某些完整性限制 某些應用程序出錯 並行事務發生死鎖事務故障（續） 事務故障的恢復
事務故障的恢復：事務撤消（UND） 恢復程序要在不影響其它事務運行的情況下，強行回滾（RBACK）該事務，即清除該事務對資料庫的所有修改，使得這個事務象根本沒有啟動過一樣 二、系統故障
什麼是系統故障 ？
由於某種原因造成整個系統的正常運行突然停止，致使所有正在運行的事務都以非正常方式終止。 發生系統故障時，內存中資料庫緩沖區的信息全部丟失，但存儲在外部存儲設備上的數據未受影響 系統故障（續） 系統故障的常見原因 操作系統或DBMS 代碼錯誤 操作員操作失誤 特定類型的硬體錯誤（如CPU 故障） 突然停電 系統故障（續）
系統故障的恢復 1. 清除尚未完成的事務對資料庫的所有修改 如果DBMS 無法確定哪些事務已更新過資料庫，則系統重新啟動後，恢復程序要強行撤消（UND ） 所有未完成事務，使這些事務象沒有運行過一樣。2. 將已完成事務提交的結果寫入資料庫 如果DBMS 無法確定哪些事務的提交結果尚未寫入物理資料庫，則系統重新啟動後，恢復程序需要重做（RED ） 所有已提交的事務。
三、介質故障
什麼是介質故障？
硬體故障使存儲在外存中的數據部分丟失或全部丟失 介質故障比前兩類故障的可能性小得多，但破壞性最大。 介質故障(續) 介質故障的常見原因 硬體故障 磁碟損壞 磁頭碰撞 操作系統的某種潛在錯誤 瞬時強磁場干擾 介質故障（續） 介質故障的恢復 裝入 資料庫發生介質故障前某個時刻的數據副本 重做自此時始的所有成功事務 ，將這些事務已提交的結果重新記入資料庫 故障的種類小結 資料庫系統中各類故障對資料庫的影響 資料庫本身被破壞 （介質故障） 資料庫處於不一致狀態 資料庫中包含了未完成事務對資料庫的修改（事務故障、系統故障） 資料庫中丟失了已提交事務對資料庫的修改（系統故障）不同類型的故障應採用不同的恢復操作 故障的種類小結（續）
恢復操作的基本原理：簡單 原理：利用 存儲在系統其它地方的冗餘數據 來重建 資料庫中已經被破壞或已經不正確的那部分數據 恢復的實現技術：復雜 一般一個大型資料庫產品，恢復子系統的代碼要佔全部代碼的10% 以上。
希望能幫到樓主~~~也希望能成為最佳答案~~~要不都枉費了我打這么多字了啊
③ 怎麼修復資料庫 修復資料庫壞塊方法
修復資料庫壞塊
dbv
你也可以用dbv工具看一下你現在其他的數據文件有沒有還有壞塊的
dbv file='yourfilename'
恢復方法：
當Oracle資料庫出現壞塊時，Oracle會在警告日誌文件（alert_SID.log）中記錄壞塊的信息：
ORA-01578: ORACLE data block corrupted (file # 7, block # )
ORA-01110: data file : '/oracle1/oradata/V920/oradata/V816/users01.dbf'
其中，＜AFN＞代表壞塊所在數據文件的絕對文件號，代表壞塊是數據文件上的第幾個數據塊
出現這種情況時，應該首先檢查是否是硬體及操作系統上的故障導致Oracle資料庫出現壞塊。在排除了資料庫以外的原因後，再對發生壞塊的資料庫對象進行處理。
1．確定發生壞塊的資料庫對象
SELECT tablespace_name,
segment_type,
owner,
segment_name
FROM dba_extents
WHERE file_id =
AND between block_id AND block_id+blocks-1;
2．決定修復方法
如果發生壞塊的對象是一個索引，那麼可以直接把索引DROP掉後，再根據表裡的記錄進行重建；
如果發生壞塊的表的記錄可以根據其它表的記錄生成的話，那麼顫中可以直接把這個表DROP掉後重建；
如果有資料庫的備份，則恢復資料庫的方法來進行修復；
如果表裡的記錄沒有其它辦法恢復，那麼壞塊上的記錄就丟失了，只能把表中其它數據壞上的記錄取出來，然後對這個表進行重建。
3．用Oracle提供的DBMS_REPAIR包標記出壞塊
exec DBMS_REPAIR.SKIP_CORRUPT_BLOCKS('','');
4．使用Create table as select命令將表中其它塊上的記錄保存到另一張表上
create table corrupt_table_bak
as
select * from corrupt_table;
5．用DROP TABLE命令刪除有壞塊的表
drop table corrupt_table;
6．用alter table rename命令恢復原來的表
alter table corrupt_table_bak
rename to corrupt_table;
7．如果表上存在耐洞伍索引，則要重建表上的索引
PART2
2014.7.22研究恢復資料庫壞塊：
Oracle調用標准C的系統函數，對數據塊進行讀寫操作，因此，壞塊是有可能由以下幾種原因產生：
硬體的I/O錯誤
操作系統的I/O錯誤或緩沖問題
內存或paging問題
磁碟修復工具
一個數據文件的一部分正在被覆蓋
Oracle試圖訪問一個未被格式化的系統塊失敗
數據文件部分溢出
Oracle或者操作系統的bug
遇到「ORA-01578:ORACLE data block corrupted」錯誤
處理方法：1.rman的recover命令可以在資料庫保持open狀態下只恢復受損的數據塊
2.如果沒有備份，萬不得已之下也可以採用DBMS_REPAIR包的存儲過程將受損壞塊隔離，同時盡可能地挽救部分數據。
rman backup命令也是檢查壞數據塊的好工具 一旦讀取ORA-19566 即可有問題
此時可用backup validate tablespace user觀察詳細的信息，可查看到壞塊數與跟蹤文件
grep『corrupt』/u01/app/oracle/diag/rdbms/br/br/trace/**.trc
恢復數據塊：rman》recover datafile 5 block 203；
批量恢復受損的數據塊：recover corruption list;
數據塊壞塊昌或一號壞塊，需要做：
run{
sql 'alter database datafile 5 offline';
restore datafile 5;
recover datafile 5;
sql'alter database datafile 5 online'
}
使用exp/imp恢復
在這種情況下肯定會造成數據的丟失，在這種情況下應採取將數據導出然後重建表再進行導入的方法，來盡量恢復損壞數據塊中的數據，但是在有壞塊的情況下是不允許導出的，如下命令：Exp test/test file=t.dmp tables=t;
導出命令在執行中會報ORA-01578錯誤，在這錯誤提示中會提示那個文件號的文件以及這個文件中的哪個塊被損壞，如：ORA—01578：ORACLE 數據塊損壞（文件號 4，塊號 35）
針對以上的提示首先查詢那些對象被損壞：
Select tablespace_name,segment_type,owner,segment_name From dba_extents Where file_id=4 and 35 between block_id and block_id+blocks-1;
如果被損壞的塊是索引，通常可以通過索引重建來解決，如果損壞的是數據（segment_type為table），那麼通過設置如下內部事件使得Exp操作跳過壞塊。
Alter session set events=』10231 trace name context forever,level 10』;
然後重新執行導出命令，導出相關的表，然後執行Drop Table命令刪除相關表，之後重建表最後導入數據。
使用DBMS_REPAIR恢復
用DBMS_REPAIR當然也會丟失數據。這里不做詳細的介紹，有興趣的可以查看oracle的在線文
3、使用dbms_repair包進行壞塊處理
1）首先建立repair_table,用於存放dbms_repair.check_object檢測出來的壞塊信息
SQL> declare
2begin
3dbms_repair.admin_tables
4(table_name => 'REPAIR_TABLE',--表名
5table_type => dbms_repair.repair_table,
6action => dbms_repair.create_action,
7tablespace => 'USERS');--用於指定該表存放的表空間
8end;
9/
PL/SQL 過程已成功完成。
SQL> col owner format a10
SQL> col object_name format a20
SQL> col object_type format a20
SQL> select owner, object_name, object_type
2from dba_objects
3where object_name like '%REPAIR_TABLE';
OWNEROBJECT_NAMEOBJECT_TYPE
---------- -------------------- --------------------
SYSREPAIR_TABLETABLE
SYSDBA_REPAIR_TABLEVIEW
Oracle自動創建了一個DBA_REPAIR_TABLE視圖。
2）使用dbms_repair.check_object進行壞塊檢測
SQL> set serveroutput on size 100000;
SQL> declare
2rpr_count int;
3begin
4rpr_count := 0;
5dbms_repair.check_object(
6schema_name => 'SYS',--指定對象模式，也就是對象的所有者
7object_name => 'TEST',--指定對象名，也就是表名
8repair_table_name => 'REPAIR_TABLE',
9corrupt_count => rpr_count);
10dbms_output.put_line('repair block count: '
11||to_char(rpr_count));
12end;
13/
repair block count: 4
PL/SQL 過程已成功完成。
SQL> select object_name, block_id, corrupt_type, marked_corrupt,
2corrupt_description, repair_description
3from repair_table;
OBJECT_NAMEBLOCK_ID CORRUPT_TYPE MARKED_COR
-------------------- ---------- ------------ ----------
CORRUPT_DESCRIPTION
-------------------------------------------------------------------------------
REPAIR_DESCRIPTION
-------------------------------------------------------------------------------
TEST196148 TRUE
mark block software corrupt
TEST206148 TRUE
mark block software corrupt
TEST236148 TRUE
mark block software corrupt
TEST316148 TRUE
mark block software corrupt
通過運行dbms_repair.check_object，將壞塊信息存放到了repair_table表中，其中有個欄位marked_corrupt，用於標識該塊是否被標識為壞塊，當被標識為true時，即該塊被標識為壞塊。其中這一步跟oracle文檔中的描述有點進入，根據oracle文檔，當執行完dbms_repair.check_object時，並不會進行壞塊標識，也就是marked_corrupt列的值應該為false，而只有當執行dbms_repair.fix_corrupt_blocks過程後才會進行壞塊標識。
3）使用dbms_repair.fix_corrupt_blocks進行壞塊標識
SQL> declare
2fix_block_count int;
3begin
4fix_block_count := 0;
5dbms_repair.fix_corrupt_blocks (
6schema_name => 'SYS',
7object_name => 'TEST',
8object_type => dbms_repair.table_object,
9repair_table_name => 'REPAIR_TABLE',
10fix_count => fix_block_count);
11dbms_output.put_line('fix blocks count: ' ||
12to_char(fix_block_count));
13end;
14/
fix blocks count: 0
PL/SQL 過程已成功完成。
我們可以見到到fix blocks count=0，即在上一步進行check_object時已經進行了壞塊標識了，這一步其實可以省略。（不過沒有測試過！）
④ 資料庫文件損壞了，還可以恢復嗎
關於這個問題,要看損壞的是什麼文件，以ORACLE資料庫為例1控制文件，每個資料庫默認有三個控制文件內容一樣（比如CTRL01.DBF,CTRL02.DBF,CTRL03.DBF)，損壞其中兩個，只需把好的那個拷貝成另外兩個的名稱即可。如果所有控制文件都壞了，需要啟動實例到nomount狀態重建控制文件，前提是之前最好做過;會得到一個重建控制文件的腳本2在線日誌（redolog），如果每個日誌組（group）的member（成員）不止一個，同一組內的在線日誌只要有一個完好，同樣可以通過拷貝方式（停止資料庫後）恢復。3TEMP表空間數據文件，可以理解為資料庫用的臨時文件，損壞後基本無數據損失，可以通過重建temp表空間恢復4.SYSTEM系統表空間，這個掛了基本上必須靠恢復了，前提是要有備份4.其它數據表空間4.1.有備份，可以恢復，但可能丟失數據4.2.未備份，無法恢復該表空間數據，可以選擇使該表空間離線（offline），恢復其它數據
⑤ 一般情況下是什麼原因導致資料庫數據丟失的呢
硬碟是計算機中所常用的一種存儲設備，主要也就是用來存儲一些重要的數據文件，而電腦也是我們日常生活和學習中所常用的重要工具之一，很多人也都經常拿它來做一些PPT，Word，以及各種工作文檔文件，給我們的生活也都提供了很大的便利。那麼作為電腦的重要組成部分的硬碟來說，當我們在使用過程中，隨著使用時間的延長，對硬碟的損壞也都是越來越大的。那麼如果在使用過程中，不小心誤刪除，或者誤清空硬碟中數據文件的話，我們又該如何恢復呢？怎樣才能找回丟失的文件呢？下面就為大家介紹下，相關硬碟文件恢復的豐富，主要分為以下幾點：
硬碟打不開的原因：
1、硬碟系統驅動出現問題，如果是驅動出現問題的話，在插入硬碟時會有所提示，此時也就需要重新安裝對應的 USB3.0 驅動程序。
2、硬碟內部設備供電不足，導致硬碟無法打開。
3、人為因素導致介面出現問題，很多人在使用 USB 設備時，往往沒有對硬碟進行定期的保養和維護，導致它內部的 USB 介面出現斷針的現象。
4、文件或目錄損壞，如果將硬碟插入電腦中，界面提示是否需要對硬碟進行格式化，此時也就說明硬碟的目錄文件有損壞的現象，
以上就是移動硬碟打不開的幾種原因介紹，相信大家也都有了一定的了解， 為了能夠找回我們所丟失的文件，當硬碟數據丟失後，也就需要結合丟失文件類型選擇不同的方法進行數據的修復。以」嗨格式數據恢復大師「為例，可修復誤刪除，誤清空，誤格式化等多種情景下丟失的文件，在操作過程中也都比較簡單方便。
希望以上內容對大家有所幫助，不管是哪種原因造成數據丟失或損壞，首先也就需要及時停止對都是數據的硬碟進行掃描和讀寫，避免文件出現覆蓋丟失的現象。
⑥ 資料庫運行中可能產生的故障有哪幾類哪些故障影響事務的正常執行哪些破壞資料庫數據
在我上的「資料庫系統實現」課程中是分為一下四類：
錯晌孫誤數據輸入
介質故障
災難性故障
系統故障
但是有些書上給出的是：
一、事務內部信此的故障; 二、系統故障; 三、介質故障; 四、計算機病毒；五、用戶操作錯誤
這個很難說誰的匪類對錯，比如計算機病毒，這個可以算作系統故障，錯誤數據輸入可以分為事務內部和用戶操作
按照我自己課程的分類，錯誤數據輸入和系統故障是影響事物正常執行的，而介質故障和災難性故障是破壞資料庫數據的
具體要看你們用什宴坦鏈么教材，畢竟不是我判卷:)