數據庫的安全性、完整性、併發控制和恢復
爲了保證數據庫數據的安全可靠性和正確有效，DBMS必須提供統一的數據保護功能。數據保護也爲數據控制，主要包括數據庫的安全性、完整性、併發控制和恢復。
一、 數據庫的安全性
數據庫的安全性是指保護數據庫以防止不合法的使用所造成的數據泄露、更改或破壞。計算機系統都有這個問題，在數據庫系統中大量數據集中存放，爲許多用戶共享，使安全問題更爲突出。
在一般的計算機系統中，安全措施是一級一級設置的。
在DB存儲這一級可採用密碼技術，當物理存儲設備失竊後，它起到保密作用。在數據庫系統這一級中提供兩種控制：用戶標識和鑑定，數據存取控制。
在ORACLE多用戶數據庫系統中，安全機制作下列工作：
l 防止非授權的數據庫存取；
l 防止非授權的對模式對象的存取；
l 控制磁盤使用；
l 控制系統資源使用；
l 審計用戶動作。
數據庫安全可分爲二類：系統安全性和數據安全性。
系統安全性是指在系統級控制數據庫的存取和使用的機制，包含：
l 有效的用戶名/口令的組合；
l 一個用戶是否授權可連接數據庫；
l 用戶對象可用的磁盤空間的數量；
l 用戶的資源限制；
l 數據庫審計是否是有效的；
l 用戶可執行哪些系統操作。
數據安全性是指在對象級控制數據庫的存取和使用的機制，包含：
l 哪些用戶可存取一指定的模式對象及在對象上允許作哪些操作類型。
在ORACLE服務器上提供了一種任意存取控制，是一種基於特權限制信息存取的方法。用戶要存取一對象必須有相應的特權授給該用戶。已授權的用戶可任意地可將它授權給其它用戶，由於這個原因，這種安全性類型叫做任意型。
ORACLE利用下列機制管理數據庫安全性：
l 數據庫用戶和模式；
l 特權；
l 角色；
l 存儲設置和空間份額；
l 資源限制；
l 審計。
1． 數據庫的存取控制
ORACLE保護信息的方法採用任意存取控制來控制全部用戶對命名對象的存取。用戶對對象的存取受特權控制。一種特權是存取一命名對象的許可，爲一種規定格式。
ORACLE使用多種不同的機制管理數據庫安全性，其中有兩種機制：模式和用戶。模式爲模式對象的集合，模式對象如表、視圖、過程和包等。第一數據庫有一組模式。
每一ORACLE數據庫有一組合法的用戶，可存取一數據庫，可運行一數據庫應用和使用該用戶各連接到定義該用戶的數據庫。當建立一數據庫用戶時，對該用戶建立一個相應的模式，模式名與用戶名相同。一旦用戶連接一數據庫，該用戶就可存取相應模式中的全部對象，一個用戶僅與同名的模式相聯繫，所以用戶和模式是類似的。
用戶的存取權利受用戶安全域的設置所控制，在建立一個數據庫的新用戶或更改一已有用戶時，安全管理員對用戶安全域有下列決策：
l 是由數據庫系統還是由操作系統維護用戶授權信息。
l 設置用戶的缺省表空間和臨時表空間。
l 列出用戶可存的表空間和在表空間中可使用空間份額。
l 設置用戶資源限制的環境文件，該限制規定了用戶可用的系統資源的總量。
l 規定用戶具有的特權和角色，可存取相應的對象。
每一個用戶有一個安全域，它是一組特性，可決定下列內容：
l 用戶可用的特權和角色；
l 用戶可用的表空間的份額；
l 用戶的系統資源限制。
1） 用戶鑑別：
爲了防止非授權的數據庫用戶的使用，ORACLE提供二種確認方法
操作系統確認和相應的ORACLE數據庫確認。
如果操作系統允許，ORACLE可使用操作系統所維護的信息來鑑定用戶。由操作系統鑑定用戶的優點是：
l 用戶可更方便地連接到ORACLE，不需要指定用戶名和口令。
l 對用戶授權的控制集中在操作系統，ORACLE不需要存儲和管理用戶口令。然而用戶名在數據庫中仍然要維護。
l 在數據庫中的用戶名項和操作系統審計跟蹤相對應。
ORACLE數據庫方式的用戶確認：ORACLE利用存儲在數據庫中的信息可鑑定試圖接到數據庫的一用戶，這種鑑別方法僅當操作系統不能用於數據庫用戶鑑別時才使用。當用戶使用一ORACLE數據庫時執行用戶鑑別。每個用戶在建立時有一個口令，用戶口令在建立對數據庫連接時使用，以防止對數據庫非授權的使用。用戶的口令以密碼的格式存儲在數據庫數據字典中，用戶可隨時修改其口令。
2） 用戶的表空間設置和定額
關於表空間的使用有幾種設置選擇：
l 用戶的缺省表空間；
l 用戶的臨時表空間；
l 數據庫表空間的空間使用定額。
3） 用戶資源限制和環境文件
用戶可用的各種系統資源總量的限制是用戶安全域的部分。利用顯式地設置資源限制；安全管理員可防止用戶無控制地消耗寶貴的系統資源。資源限制是由環境文件管理。一個環境文件是命名的一組賦給用戶的資源限制。另外ORACLE爲安全管理員在數據庫級提供使能或使不能實施環境文件資源限制的選擇。
ORACLE可限制幾種類型的系統資源的使用，每種資源可在會話級、調用級或兩者上控制。在會話級：每一次用戶連接到一數據庫，建立一會話。每一個會話在執行SQL語句的計算機上耗費CPU時間和內存量進行限制。對ORACLE的幾種資源限制可在會話級上設置。如果會話級資源限制被超過，當前語句被中止（回滾），並返回指明會話限制已達到的信息。此時，當前事務中所有之前執行的語句不受影響，此時僅可作COMMIT、ROLLBACK或刪除對數據庫的連接等操作，進行其它操作都將出錯。
在調用級：在SQL語句執行時，處理該語句有好幾步，爲了防止過多地調用系統，ORACLE在調用級可設置幾種資源限制。如果調用級的資源限制被超過，語句處理被停止，該語句被回滾，並返回一錯誤。然而當前事務的已執行所用語句不受影響，用戶會話繼續連接。
有下列資源限制：
l 爲了防止無控制地使用CPU時間，ORACLE可限制每次ORACLE調用的CPU時間和在一次會話期間ORACLE調用所使用的CPU的時間，以0.01秒爲單位。
l 爲了防止過多的I/O，ORACLE可限制每次調用和每次會話的邏輯數據塊讀的數目。
l ORACLE在會話級還提供其它幾種資源限制。
每個用戶的並行會話數的限制；
會話空閒時間的限制，如果一次會話的ORACLE調用之間時間達到該空閒時間，當前事務被回滾，會話被中止，會話資源返回給系統；
每次會話可消逝時間的限制，如果一次會話期間超過可消逝時間的限制，當前事務被回滾，會話被刪除，該會話的資源被釋放；
每次會話的專用SGA空間量的限制。
用戶環境文件：
用戶環境文件是指定資源限制的命名集，可賦給ORACLE數據庫的有效的用戶。利用用戶環境文件可容易地管理資源限制。要使用用戶環境文件，首先應將數據庫中的用戶分類，決定在數據庫中全部用戶類型需要多少種用戶環境文件。在建立環境文件之前，要決定每一種資源限制的值。例如一類用戶通常不執行大量邏輯數據塊讀，那就可將LOGICAL-READS-PER-SESSION和LOGICAL-READS-PER-CALL設置相應的值。在許多情況中決定一用戶的環境文件的合適資源限制的最好的方法是收集每種資源使用的歷史信息。
2． 特權和角色
1） 特權：特權是執行一種特殊類型的SQL語句或存取另一用戶的對象的權力。有兩類特權：系統特權和對象特權。
系統特權：是執行一處特殊動作或者在對象類型上執行一種特殊動作的權利。ORACLE有60多種不同系統特權,每一種系統允許用戶執行一種特殊的數據庫操作或一類數據庫操作.
系統特權可授權給用戶或角色,一般,系統特權全管理人員和應用開發人員,終端用戶不需要這些相關功能.授權給一用戶的系統特權並具有該 系統特權授權給其他用戶或角色.反之,可從那些被授權的用戶或角色回收系統特權.
對象特權：在指定的表、視圖、序列、過程、函數或包上執行特殊動作的權利。對於不同類型的對象,有不同類型的對象特權。對於有些模式對象，如聚集、索引、觸發器、數據庫鏈沒有相關的對象特權，它們由系統特權控制。
對於包含在某用戶名的模式中的對象，該用戶對這些對象自動地具有全部對象特權，即模式的持有者對模式中的對象具有全部對象特權。這些對象的持有者可將這些對象上的任何對象特權可授權給其他用戶。如果被授者包含有GRANT OPTION 授權，那麼該被授者也可將其權利再授權給其他用戶。
2） 角色：爲相關特權的命名組，可授權給用戶和角色。ORACEL利用角色更容易地進行特權管理。有下列優點：
l 減少特權管理，不要顯式地將同一特權組授權給幾個用戶，只需將這特權組授給角色，然後將角色授權給每一用戶。
l 動態特權管理，如果一組特權需要改變，只需修改角色的特權，所有授給該角色的全部用戶的安全域將自動地反映對角色所作的修改。
l 特權的選擇可用性，授權給用戶的角色可選擇地使其使能（可用）或使不能（不可用）。
l 應用可知性，當一用戶經一用戶名執行應用時，該數據庫應用可查詢字典，將自動地選擇使角色使能或不能。
l 專門的應用安全性，角色使用可由口令保護，應用可提供正確的口令使用權角色使能，達到專用的應用安全性。因用戶不知其口令，不能使角色使能。
一般，建立角色服務於兩個目的：爲數據庫應用管理特權和爲用戶組管理特權。相應的角色稱爲應用角色和用戶角色。
應用角色是授予的運行一數據庫應用所需的全部特權。一個應用角色可授給其它角色或指定用戶。一個應用可有幾種不同角色，具有不同特權組的每一個角色在使用應用時可進行不同的數據存取。
用戶角色是爲具有公開特權需求的一組數據庫用戶而建立的。用戶特權管理是受應用角色或特權授權給用戶角色所控制，然後將用戶角色授權給相應的用戶。
數據庫角色包含下列功能：
l 一個角色可授予系統特權或對象特權。
l 一個角色可授權給其它角色，但不能循環授權。
l 任何角色可授權給任何數據庫用戶。
l 授權給一用戶的每一角色可以是使能的或者使不能的。一個用戶的安全域僅包含當前對該用戶使能的全部角色的特權。
l 一個間接授權角色（授權給另一角色的角色）對一用戶可顯式地使其能或使不能。
在一個數據庫中，每一個角色名必須唯一。角色名與用戶不同，角色不包含在任何模式中，所以建立一角色的用戶被刪除時不影響該角色。
ORACLE爲了提供與以前版本的兼容性，預定義下列角色：CONNENT、RESOURCE、DBA、EXP-FULL-DATABASE和IMP-FULL-DATABASE。
3． 審計
審計是對選定的用戶動作的監控和記錄，通常用於：
l 審查可疑的活動。例如：數據被非授權用戶所刪除，此時安全管理員可決定對該 數據庫的所有連接進行審計，以及對數據庫的所有表的成功地或不成功地刪除進行審計。
l 監視和收集關於指定數據庫活動的數據。例如：DBA可收集哪些被修改、執行了多少次邏輯的I/O等統計數據。
ORACLE支持三種審計類型：
l 語句審計，對某種類型的SQL語句審計，不指定結構或對象。
l 特權審計，對執行相應動作的系統特權的使用審計。
l 對象審計，對一特殊模式對象上的指定語句的審計。
ORACLE所允許的審計選擇限於下列方面：
l 審計語句的成功執行、不成功執行，或者其兩者。
l 對每一用戶會話審計語句執行一次或者對語句每次執行審計一次。
l 對全部用戶或指定用戶的活動的審計。
當數據庫的審計是使能的，在語句執行階段產生審計記錄。審計記錄包含有審計的操作、用戶執行的操作、操作的日期和時間等信息。審計記錄可存在數據字典表（稱爲審計記錄）或操作系統審計記錄中。數據庫審計記錄是在SYS模式的AUD$表中。
二、 數據完整性
它是指數據的正確性和相容性。數據的完整性是爲了防止數據庫存在不符合主義的數據，防止錯誤信息輸入和輸出，即數據要遵守由DBA或應用開發者所決定的一組預定義的規則。ORACLE應用於關係數據庫的表的數據完整性有下列類型：
l 在插入或修改表的行時允許不允許包含有空值的列，稱爲空與非空規則。
l 唯一列值規則，允許插入或修改的錶行在該列上的值唯一。
l 引用完整性規則，同關係模型定義
l 用戶對定義的規則，爲複雜性完整性檢查。
ORACLE允許定義和實施上述每一種類型的數據完整性規則，這些規則可用完整性約束和數據庫觸發器定義。
完整性約束，是對錶的列定義一規則的說明性方法。
數據庫觸發器，是使用非說明方法實施完整性規則，利用數據庫觸發器（存儲的數據庫過程）可定義和實施任何類型的完整性規則。
1． 完整性約束
ORACLE利用完整性約束機制防止無效的數據進入數據庫的基表，如果任何DML執行結果破壞完整性約束，該語句被回滾並返回一上個錯誤。ORACLE實現的完整性約束完全遵守ANSI X3。135-1989和ISO9075-1989標準。
利用完整性約束實施數據完整性規則有下列優點：
l 定義或更改表時，不需要程序設計，便很容易地編寫程序並可消除程序性錯誤，其功能是由ORACLE控制。所以說明性完整性約束優於應用代碼和數據庫觸發器。
l 對錶所定義的完整性約束是存儲在數據字典中，所以由任何應用進入的數據都必須遵守與表相關聯的完整性約束。
l 具有最大的開發能力。當由完整性約束所實施的事務規則改變時，管理員只需改變完整性約束的定義，所有應用自動地遵守所修改的約束。
l 由於完整性約束存儲在數據字典中，數據庫應用可利用這些信息，在SQL語句執行之前或由ORACLE檢查之前，就可立即反饋信息。
l 由於完整性約束說明的語義是清楚地定義，對於每一指定說明規則可實現性能優化。
l 由於完整性約束可臨時地使不能，以致在裝入大量數據時可避免約束檢索的開銷。當數據庫裝入完成時，完整性約束可容易地使其能，任何破壞完整性約束的任何新行在例外表中列出。
ORACLE的DBA和應用開始者對列的值輸入可使用的完整性約束有下列類型：
l NOT NULL約束:如果在表的一列的值不允許爲空，則需在該列指定NOT NULL約束。
l UNIQUE碼約束：在表指定的列或組列上不允許兩行是具有重複值時，則需要該列或組列上指定UNIQUE碼完整性約束。在UNIQUE碼約束定義中的列或組列稱爲唯一碼。所有唯一完整性約束是用索引方法實施。
l PRIMARY KEY約束：在數據庫中每一個表可有一個PRIMARY KEY約束。包含在PRIMARY KEY完整性約束的列或組列稱爲主碼，每個表可有一個主碼。ORACLE使用索引實施PRIMARY KEY約束。
l FOREIGN KEY約束（可稱引用約束）：在關係數據庫中表可通過公共列相關聯，該規則控制必須維護的列之間的關係。包含在引用完整性約束定義的列或組列稱爲外來碼。由外來碼所引用的表中的唯一碼或方碼，稱爲引用碼。包含有外來碼的表稱爲子表或從屬表。由子表的外來碼所引用的表稱爲雙親表或引用表。如果對錶的每一行，其外來碼的值必須與主碼中一值相匹配，則需指定引用完整性約束。
l CHECK約束：表的每行對一指定的條件必須是TRUE或未知，則需在一列或列組上指定CHECK完整性約束。如果在發出一個DML語句時，CHECK約束的條件計算得FALSE時，該語句被回滾。
2． 數據庫觸發器
ORACLE允許定義過程，當對相關的表作INSERT、UPDATE或DELETE語句時，這些過程被隱式地執行。這些過程稱爲數據庫觸發器。觸發器類似於存儲的過程，可包含SQL語句和PL/SQL語句，可調用其它的存儲過程。過程與觸發器差別在於調用方法：過程由用戶或應用顯式執行；而觸發器是爲一激發語句（INSERT、UPDATE、DELETE）發出進由ORACLE隱式地觸發。一個數據庫應用可隱式地觸發存儲在數據庫中多個觸發器。
在許多情況中觸發器補充ORACLE的標準功能，提供高度專用的數據庫管理系統。一般觸發器用於：
l 自動地生成導出列值。
l 防止無效事務。
l 實施複雜的安全審覈。
l 在分佈式數據庫中實施跨結點的引用完整性。
l 實施複雜的事務規則。
l 提供透明的事件記錄。
l 提供高級的審計。
l 維護同步的表副本。
l 收集表存取的統計信息。
注意：在ORACLE環境中利用ORACLE工具SQL*FORMS也可定義、存儲和執行觸發器，它作爲由SQL*FORMS所開發有應用的一部分，它與在表上定義的數據庫觸發器有差別。數據庫觸發器在表上定義，存儲在相關的數據庫中，在對該表發出IMSERT、UPDATE、DELETE語句時將引起數據庫觸發器的執行，不管是哪些用戶或應用發出這些語句。而SQL*FORMS的觸發器是SQL*FORMS應用的組成，僅當在指定SQL*FORMS應用中執行指定觸發器點時才激發該觸發器。
一個觸發器由三部分組成：觸發事件或語句、觸發限制和觸發器動作。觸發事件或語句是指引起激發觸發器的SQL語句，可爲對一指定表的INSERT、UNPDATE或DELETE語句。觸發限制是指定一個布爾表達式，當觸發器激以時該布爾表達式是必須爲真。觸發器作爲過程，是PL/SQL塊，當觸發語句發出、觸發限制計算爲真時該過程被執行。
3． 併發控制
數據庫是一個共享資源，可爲多個應用程序所共享。這些程序可串行運行，但在許多情況下，由於應用程序涉及的數據量可能很大，常常會涉及輸入/輸出的交換。爲了有效地利用數據庫資源，可能多個程序或一個程序的多個進程並行地運行，這就是數據庫的並行操作。在多用戶數據庫環境中，多個用戶程序可並行地存取數據庫，如果不對併發操作進行控制，會存取不正確的數據，或破壞數據庫數據的一致性。
例：在飛機票售票中，有兩個訂票員（T1，T2）對某航線（A）的機動性票作事務處理，操作過程如圖所示：
|
數據庫中的A |
1 |
1 |
1 |
1 |
0 |
0 |
|
T1 |
READ A |
|
A：=A-1 |
|
WRITE A |
|
|
T2 |
|
READ A |
|
A：=A-1 |
|
WRITE A |
|
T1工作區中的A |
1 |
1 |
0 |
0 |
0 |
0 |
|
T2工作區中的A |
|
1 |
1 |
0 |
0 |
0 |
首先T1讀A，接着T2也讀A。然後T1將其工作區中的A減1，T2也採取同樣動作，它們都得0值，最後分別將0值寫回數據庫。在這過程中沒有任何非法操作，但實際上多出一張機票。這種情況稱爲數據庫的不一致性，這種不一致性是由於並行操作而產生的。所謂不一致，實際上是由於處理程序工作區中的數據與數據庫中的數據不一致所造成的。如果處理程序不對數據庫中的數據進行修改，則決不會造成任何不一致。另一方面，如果沒有並行操作發生，則這種臨時的不一致也不會造成什麼問題。數據不一致總是是由兩個因素造成：一是對數據的修改，二是並行操作的發生。因此爲了保持數據庫的一致性，必須對並行操作進行控制。最常用的措施是對數據進行封鎖。
1） 數據庫不一致的類型
l 不一致性
在一事務期間，其它提交的或未提交事務的修改是顯然的，以致由查詢所返回的數據集不與任何點相一致。
l 不可重複讀
在一個事務範圍內，兩個相同查詢將返回不同數據，由於查詢注意到其它提交事務的修改而引起。
l 讀髒數據
如果事務T1將一值（A）修改，然後事務T2讀該值，在這之後T1由於某種原因撤銷對該值的修改，這樣造成T2讀取的值是髒的。
l 丟失更改
在一事務中一修改重寫另一事務的修改，如上述飛機票售票例子。
l 破壞性的DDL操作
在一用戶修改一表的數據時，另一用戶同時更改或刪除該表。
1) 封鎖
在多用戶數據庫中一般採用某些數據封鎖來解決併發操作中的數據一致性和完整性問題。封鎖是防止存取同一資源的用戶之間破壞性的干擾的機制，該干擾是指不正確地修改數據或不正確地更改數據結構。
在多用戶數據庫中使用兩種封鎖：排它（專用）封鎖和共享封鎖。排它封鎖禁止相關資源的共享，如果一事務以排它方式封鎖一資源，僅僅該事務可更改該資源，直至釋放排它封鎖。共享封鎖允許相關資源可以共享，幾個用戶可同時讀同一數據，幾個事務可在同一資源上獲取共享封鎖。共享封鎖比排它封鎖具有更高的數據並行性。
在多用戶系統中使用封鎖後會出現死鎖，引起一些事務不能繼續工作。當兩個或多個用戶彼此等待所封鎖數據時可發生死鎖。
2) ORACLE多種一致性模型。
ORACLE利用事務和封鎖機制提供數據併發存取和數據完整性。在一事務內由語句獲取的全部封鎖在事務期間被保持，防止其它並行事務的破壞性干擾。一個事務的SQL語句所作的修改在它提交之後所啓動的事務中才是可見的。在一事務中由語句所獲取的全部封鎖在該事務提交或回滾時被釋放。
ORACLE在兩個不同級上提供讀一致性：語句級讀一致性和事務級一致性。ORCLE總是實施語句級讀一致性，保證單個查詢所返回的數據與該查詢開始時刻相一致。所以一個查詢從不會看到在查詢執行過程中提交的其它事務所作的任何修改。爲了實現語句級讀一致性，在查詢進入執行階段時，在注視SCN的時候爲止所提交的數據是有效的，而在語句執行開始之後其它事務提交的任何修改，查詢將是看不到的。
ORACLE允許選擇實施事務級讀一致性，它保證在同一事務內所有查詢的數據
4) 封鎖機制
ORACLE自動地使用不同封鎖類型來控制數據的並行存取，防止用戶之間的破壞性干擾。ORACLE爲一事務自動地封鎖一資源以防止其它事務對同一資源的排它封鎖。在某種事件出現或事務不再需要該資源時自動地釋放。
ORACLE將封鎖分爲下列類：
l 數據封鎖：數據封鎖保護表數據，在多個用戶並行存取數據時保證數據的完整性。數據封鎖防止相沖突的DML和DDL操作的破壞性干擾。DML操作可在兩個級獲取數據封鎖：指定行封鎖和整個表封鎖，在防止衝突的DDL操作時也需表封鎖。當行要被修改時，事務在該行獲取排它數據封鎖。表封鎖可以有下列方式：行共享、行排它、共享封鎖、共享行排它和排它封鎖。
l DDL封鎖（字典封鎖）
DDL封鎖保護模式對象（如表）的定義，DDL操作將影響對象，一個DDL語句隱式地提交一個事務。當任何DDL事務需要時由ORACLE自動獲取字典封鎖，用戶不能顯式地請求DDL封鎖。在DDL操作期間，被修改或引用的模式對象被封鎖。
l 內部封鎖：保護內部數據庫和內存結構，這些結構對用戶是不可見的。
5) 手工的數據封鎖
下列情況允許使用選擇代替ORACLE缺省的封鎖機制：
l 應用需要事務級讀一致或可重複讀。
l 應用需要一事務對一資源可排它存取，爲了繼續它的語句，具有對資源排它存取的事務不必等待其它事務完成。
ORACLE自動封鎖可在二級被替代：事務級各系統級。
l 事務級：包含下列SQL語句的事務替代ORACLE缺省封鎖：LOCK TABLE命令、SELECT…FOR UPDATE命令、具有READ ONLY選項的SET TRANSACTIN命令。由這些語句所獲得的封鎖在事務提交或回滾後所釋放。
l 系統級：通過調整初始化參數SERIALIZABLE和REO-LOCKING，實例可用非缺省封鎖啓動。該兩參數據的缺省值爲：
SERIALIZABLE=FALSE
ORW-LOCKING=ALWAYS
4． 數據庫後備和恢復
當我們使用一個數據庫時，總希望數據庫的內容是可靠的、正確的，但由於計算機系統的故障（硬件故障、軟件故障、網絡故障、進程故障和系統故障）影響數據庫系統的操作，影響數據庫中數據的正確性，甚至破壞數據庫，使數據庫中全部或部分數據丟失。因此當發生上述故障後，希望能重新建立一個完整的數據庫，該處理稱爲數據庫恢復。恢復子系統是數據庫管理系統的一個重要組成部分。恢復處理隨所發生的故障類型所影響的結構而變化。
1） 恢復數據庫所使用的結構
ORACLE數據庫使用幾種結構對可能故障來保護數據：數據庫後備、日誌、回滾段和控制文件。
數據庫後備是由構成ORACLE數據庫的物理文件的操作系統後備所組成。當介質故障時進行數據庫恢復，利用後備文件恢復毀壞的數據文件或控制文件。
日誌，每一個ORACLE數據庫實例都提供，記錄數據庫中所作的全部修改。一個實例的日誌至少由兩個日誌文件組成，當實例故障或介質故障時進行數據庫部分恢復，利用數據庫日誌中的改變應用於數據文件，修改數據庫數據到故障出現的時刻。數據庫日誌由兩部分組成：在線日誌和歸檔日誌。
每一個運行的ORACLE數據庫實例相應地有一個在線日誌，它與ORACLE後臺進程LGWR一起工作，立即記錄該實例所作的全部修改。在線日誌由兩個或多個預期分配的文件組成，以循環方式使用。
歸檔日誌是可選擇的，一個ORACLE數據庫實例一旦在線日誌填滿後，可形成在線日誌的歸檔文件。歸檔的在線日誌文件被唯一標識併合成歸檔日誌。
回滾段用於存儲正在進行的事務（爲未提交的事務）所修改值的老值，該信息在數據庫恢復過程中用於撤消任何非提交的修改。
控制文件，一般用於存儲數據庫的物理結構的狀態。控制文件中某些狀態信息在實例恢復和介質恢復期間用於引導ORACLE。
2） 在線日誌
一個ORACLE數據庫的每一實例有一個相關聯的在線日誌。一個在線日誌由多個在線日誌文件組成。在線日誌文件填入日誌項，日誌項記錄的數據用於重構對數據庫所作的全部修改。後臺進程LGWR以循環方式寫入在線日誌文件。噹噹前的在線日誌文件寫滿後，LGWR寫入到下一可用在線日誌文件當最後一個可用的在線日誌文件的檢查點已完成時即可使用。如果歸檔不實施，一個已填滿的在線日誌文件一當包含該在線日誌文件的檢查點完成，該文件已被歸檔後即可使用。在任何時候，僅有一個在線日誌文件被寫入存儲日誌項，它被稱爲活動的或當前在線日誌文件，其它的在線日誌文件爲不活動的在線日誌文件。
ORCLE結束寫入一在線日誌文件並開始寫入到另一個在線日誌文件的點稱爲日誌開關。日誌開關在當前在線日誌文件完全填滿，必須繼續寫入到下一個在線日誌文件時總出現，也可由DBA強制日誌開關。每一日誌開關出現時，每一在線日誌文件賦給一個新的日誌序列號。如果在線日誌文件被歸檔，在歸檔日誌文件中包含有它的日誌序列號。
ORACLE後臺進程DBWR（數據庫寫）將SGA中所有被修改的數據庫緩衝區（包含提交和未提交的）寫入到數據文件，這樣的事件稱爲出現一個檢查點。因下列原因實現檢查點：
l 檢查點確保將內存中經常改變的數據段塊每隔一定時間寫入到數據文件。由於DBWR使用最近最少使用算法，經常修改的數據段塊從不會作爲最近最少使用塊，如果檢查點不出現，它從不會寫入磁盤。
l 由於直至檢查點時所有的數據庫修改已記錄到數據文件，先於檢查點的日誌項在實例恢復時不再需要應用於數據文件，所以檢查點可加快實例恢復。
雖然檢查點有一些開銷，但ORACLE既不停止活動又不影響當前事務。由於DBWR不斷地將數據庫緩衝區寫入到磁盤，所以一個檢查點一次不必寫許多數據塊。一個檢查點保證自前一個檢查點以來的全部修改數據塊寫入到磁盤。檢查點不管填滿的在線日誌文件是否正在歸檔，它總是出現。如果實施歸檔，在LGWR重用在線日誌文件之前，檢查點必須完成並且所填滿的在線日誌文件必須被歸檔。
檢查點可對數據庫的全部數據文件出現（稱爲數據庫檢查點），也可對指定的數據文件出現。下面說明一下什麼時候出現檢查點及出現什麼情況：
l 在每一個日誌開關處自動地出現一數據庫檢查點。如果前一個數據庫檢查點正在處理，由日誌開關實施的檢查點優於當前檢查點。
l 初始化參數據LOG-CHECKPOINT-INTERVAL設置所實施的數據庫檢查點，當預定的日誌塊數被填滿後（自最後一個數據庫檢查點以來），實施一數據庫檢查點。另一個參數LOG-CHECKPOINT-TIMEOUT可設置自上一個數據庫檢查點開始之後指定秒數後實施一數據庫檢查點。這種選擇對使用非常大的日誌文件時有用，它在日誌開頭之間增加檢查點。由初始化參數所啓動的數據庫檢查點只有在前一個檢查點完成後才能啓動。
l 當一在線表空間開始後備時，僅對構成該空間的數據文件實施一檢查點，該檢查點壓倒仍在進行中的任何檢查點。
l 當DBA使一表空間離線時，僅對構成該表空間的在線文件實施一檢查點。
l 當DBA以正常或立即方式關閉一實例時，ORACLE在實例關閉之前實施一數據庫檢查點，該檢查點壓倒任何運行檢查點。
l DBA可要求實施一數據庫檢查點，該檢查點壓倒任何運行檢查點。
檢查點機制：當檢查點出現時，檢查點後臺進程記住寫入在線文件的下一日誌行的位置，並通知數據庫寫後臺進程將SGA中修改的數據庫緩衝區寫入到磁盤上的數據文件。然後由CKPT修改全部控制文件和數據文件的標頭，反映該最後檢查點。當檢查點不發生，DBWR當需要時僅將最近最少使用的數據庫緩衝區寫入磁盤，爲新數據準備緩衝區。
鏡象在線日誌文件：爲了安全將實例的在線日誌文件鏡象到它的在線日誌文件ORACLE提供鏡象功能。當具有鏡象在線日誌文件時，LGWR同時將同一日誌信息寫入到多個同樣的在線日誌文件。日誌文件分成組，每個組中的日誌文件稱爲成員，每個組中的全部成員同時活動，由LGWR賦給相同的日誌序列號。如果使用鏡象在線日誌，則可建立在線日誌文件組，在組中的每一成員要求是同一大小。
鏡象在線日誌的機制：LGWR總是尋找組的全部成員，對一組的全部成員並行地寫，然後轉換到下一組的全部成員，並行地寫。
每個數據庫實例有自己的在線日誌組，這些在線日誌組可以是鏡象的或不是，稱爲實例的在線日誌線索。在典型配置中，一個數據庫實例存取一個ORACLE數據庫，於是僅一個線索存在。然而在運行ORACLE並行服務器中，兩個或多個實例並行地存取單個數據庫，在這種情況下，每個實例有自己的線索。
3） 歸檔日誌
ORACLE要將填滿的在線日誌文件組歸檔時，則要建立歸檔日誌，或稱離線日誌。其對數據庫後備和恢復有下列用處：
l 數據庫後備以及在線和歸檔日誌文件，在操作系統或磁盤故障中可保證全部提交的事務可被恢復。
l 在數據庫打開時和正常系統使用下，如果歸檔日誌是永久保持，在線後備可以進行和使用。
如果用戶數據庫要求在任何磁盤故障的事件中不丟失任何數據，那麼歸檔日誌必須要存在。歸檔已填滿的在線日誌文件可能需要DBA執行額外的管理操作。
歸檔機制：決定於歸檔設置，歸檔已填滿的在線日誌組的機制可由ORACLE後臺進程ARCH自動歸檔或由用戶進程發出語句手工地歸檔。當日志組變爲不活動、日誌開關指向下一組已完成時，ARCH可歸檔一組，可存取該組的任何或全部成員，完成歸檔組。在線日誌文件歸檔之後纔可爲LGWR重用。當使用歸檔時，必須指定歸檔目標指向一存儲設備，它不同於個有數據文件、在線日誌文件和控制文件的設備，理想的是將歸檔日誌文件永久地移到離線存儲設備、如磁帶。
數據庫可運行在兩種不同方式下：NOARCHIVELOG方式或ARCHIVELOG方式。數據庫在NOARCHIVELOG方式下使用時，不能進行在線日誌的歸檔。在該數據庫控制文件指明填滿的組不需要歸檔，所以一當填滿的組成爲活動，在日誌開關的檢查點完成，該組即可被LGWR重用。在該方式下僅能保護數據庫實例故障，不能保護介質（磁盤）故障。利用存儲在在線日誌中的信息，可實現實例故障恢復。
如果數據庫在ARCHIVELOG方式下,可實施在線日誌的歸檔。在控制文件中指明填滿的日誌文件組在歸檔之前不能重用。一旦組成爲不活動，執行歸檔的進程立即可使用該組。
在實例起動時，通過參數LOG-ARCHIVE-START設置，可啓動ARCH進程，否則ARCH進程在實例啓動時不能被啓動。然而DBA在憑藉時候可交互地啓動或停止自動歸檔。一旦在線日誌文件組變爲不活動時，ARCH進程自動對它歸檔。
如果數據庫在ARCHIVELOG方式下運行，DBA可手工歸檔填滿的不活動的日誌文件組，不管自動歸檔是可以還是不可以。
4） 數據庫後備
不管爲ORACLE數據庫設計成什麼樣的後備或恢復模式，數據庫數據文件、日誌文件和控制文件的操作系統後備是絕對需要的，它是保護介質故障的策略部分。操作系統後備有完全後備和部分後備
l 完全後備：一個完全後備將構成ORACLE數據庫的全部數據庫文件、在線日誌文件和控制文件的一個操作系統後備。一個完全後備在數據庫正常關閉之後進行，不能在實例故障後進行。在此時，所有構成數據庫的全部文件是關閉的，並與當前點相一致。在數據庫打開時不能進行完全後備。由完全後備得到的數據文件在任何類型的介質恢復模式中是有用的。
l 部分後備
部分後備爲除完全後備外的任何操作系統後備，可在數據庫打開或關閉下進行。如單個表空間中全部數據文件後備、單個數據文件後備和控制文件後備。部分後備僅對在ARCHIVELOG方式下運行數據庫有用，因爲存在的歸檔日誌，數據文件可由部分後備恢復。在恢復過程中與數據庫其它部分一致。
5） 數據庫恢復
l 實例故障的恢復
當實例意外地（如掉電、後臺進程故障等）或預料地（發出SHUTDOUM ABORT語句）中止時出現實例故障，此時需要實例恢復。實例恢復將數據庫恢復一故障之前的事務一致狀態。如果在在線後備發現實例故障，則需介質恢復。在其它情況ORACLE在下次數據庫起動時（對新實例裝配和打開），自動地執行實例恢復。如果需要，從裝配狀態變爲打開狀態，自動地激發實例恢復，由下列處理：
（1） 爲了解恢復數據文件中沒有記錄的數據，進行向前滾。該數據記錄在在線日誌，包括對回滾段的內容恢復。
（2） 回滾未提交的事務，按步1重新生成回滾段所指定的操作。
（3） 釋放在故障時正在處理事務所持有的資源。
（4） 解決在故障時正經歷一階段提交的任何懸而未決的分佈事務。
l 介質故障的恢復
介質故障是當一個文件、一個文件的部分或一磁盤不能讀或不能寫時出現的故障。介質故障的恢復有兩種形式，決定於數據庫運行的歸檔方式。
l 如果數據庫是可運行的，以致它的在線日誌僅可重用但不能歸檔，此時介質恢復爲使用最新的完全後備的簡單恢復。在完全後備執行的工作必須手工地重作。
l 如果數據庫可運行，其在線日誌是被歸檔的，該介質故障的恢復是一個實際恢復過程，重構受損的數據庫恢復到介質故障前的一個指定事務一致狀態。
不管哪種形式，介質故障的恢復總是將整個數據庫恢復到故障之前的一個事務一致狀態。如果數據庫是在ARCHIVELOG方式運行，可有不同類型的介質恢復：完全介質恢復和不完全介質恢復。
完全介質恢復可恢復全部丟失的修改。僅當所有必要的日誌可用時纔可能。有不同類型的完全介質恢復可使用，其決定於毀壞文件和數據庫的可用性。例：
l 關閉數據庫的恢復。當數據庫可被裝配卻是關閉的，完全不能正常使用，此時可進行全部的或單個毀壞數據文件的完全介質恢復。
l 打開數據庫的離線表空間的恢復。當數據庫是打開的，完全介質恢復可以處理。未損的數據庫表空間是在線的可以使用，而受損耗捕空間是離線的，其所有數據文件作爲恢復的單位。
l 打開數據庫的離線表間的單個數據文件的恢復。當數據庫是打開的，完全介質恢復可以處理。未損的數據庫表空間是在線的可以使用，而所損的表空間是離線的，該表空間的指定所損的數據文件可被恢復。
l 使用後備的控制文件的完全介質恢復。當控制文件所有拷貝由於磁盤故障而受損時，可進行介質恢復而不丟失數據。
不完全介質恢復是在完全介質恢復不可能或不要求時進行的介質恢復。重構受損的數據庫，使其恢復介質故障前或用戶出錯之前的一個事務一致性狀態。不完全介質恢復有不同類型的使用，決定於需要不完全介質恢復的情況，有下列類型：基於撤消、基於時間和基於修改的不完全恢復。
基於撤消恢復：在某種情況，不完全介質恢復必須被控制，DBA可撤消在指定點的操作。基於撤消的恢復地在一個或多個日誌組（在線的或歸檔的）已被介質故障所破壞，不能用於恢復過程時使用，所以介質恢復必須控制，以致在使用最近的、未損的日誌組於數據文件後中止恢復操作。
基於時間和基於修改的恢復：如果DBA希望恢復到過去的某個指定點，不完全介質恢復地理想的。可在下列情況下使用：
l 當用戶意外地刪除一表，並注意到錯誤提交的估計時間，DBA可立即關閉數據庫，恢復它到用戶錯誤之前時刻。
l 由於系統故障，一個在線日誌文件的部分被破壞，所以活動的日誌文件突然不可使用，實例被中止，此時需要介質恢復。在恢復中可使用當前在線日誌文件的未損部分，DBA利用基於時間的恢復，一旦有將效的在線日誌已應用於數據文件後停止恢復過程。
在這兩種情況下，不完全介質恢復的終點可由時間點或系統修改號（SCN）來指定。