ORACEL 培訓教程(2)
2024-07-21 02:41:07
供稿：網友
數據庫的安全性、完整性、并發控制和恢復
為了保證數據庫數據的安全可靠性和正確有效，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． 數據庫后備和恢復
當我們使用一個數據庫時，總希望數據庫的內容是可靠的、正確的，但由于計算機系統的故障（硬件故障、軟件故障、網絡故障、進程故障和系統故障）影響數據庫系統的操作，影響數據庫中數據的正確性，甚至破壞數據庫，使數據庫中全部或部分數據丟失。因此當發生上述故障后，希望能重新建立一個完整的數據庫，該處理稱為數據庫恢復?；謴妥酉到y是數據庫治理系統的一個重要組成部分。恢復處理隨所發生的故障類型所影響的結構而變化。
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）來指定。
