數據庫經典筆試題總結

1，范式

7大范式：1NF, 2NF,3NF,BCNF,4NF,5NF,6NF

什么叫normalization？Denormalization?

Normalization是數據庫規范化，denormalization是數據庫逆規范化。

在設計和操作維護數據庫時，關鍵的步驟就是要確保數據正確地分布到數據庫的表中。數據分析師使用正確的數據結構，不僅便于對數據庫進行相應的存取操作，而且可以極大地簡化應用程序的其他內容（查詢、窗體、報表、代碼等）。正確進行表設計的正式名稱就是”數據庫規范化”。目的：減少數據庫中數據冗余，增進數據的一致性。

范式概念：

1）1NF：目標就是表中每列都不可分割；
2）2NF：目標就是表中的每行都是有標識的。前提是滿足了1NF. 當關鍵字為單field時，一定滿足2NF。當關鍵字為組合field時（即超過一個field）,不能存在組合關鍵字中有某個字段能夠決定非關鍵字段的某部分。非主field非部分依賴于主field，即非關鍵字段必須完全依賴于一組 組合關鍵字，而不是組合關鍵字的某一部分。
3）3NF：目標是一個table里面所有的列不依賴于另外一個table里面非關鍵的列。前提是滿足了2NF，不存在某個非關鍵字段決定另外一個非關鍵字段。即：不存在傳遞依賴（關鍵字x->非關鍵屬性y->非關鍵屬性z）
4）BCNF：前提是滿足了2NF，不存在某個非關鍵字段決定另外一個非關鍵字段。也不存在某個關鍵字段決定另外一個關鍵字段。即：在3NF基礎上，加上約束：不存在某個關鍵字段決定另外一個關鍵字段。
1 第一范式（1NF）
在任何一個關系數據庫中，第一范式（1NF）是對關系模式的基本要求，不滿足第一范式（1NF）的數據庫就不是關系數據庫。所謂第一范式（1NF）是指數據庫表的每一列都是不可分割的基本數據項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重復的屬性。如果出現重復的屬性，就可能需要定義一個新的實體，新的實體由重復的屬性構成，新實體與原實體之間為一對多關系。在第一范式（1NF）中表的每一行只包含一個實例的信息。例如，對于圖3-2 中的員工信息表，不能將員工信息都放在一列中顯示，也不能將其中的兩列或多列在一列中顯示；員工信息表的每一行只表示一個員工的信息，一個員工的信息在表中只出現一次。簡而言之，第一范式就是無重復的列。
2 第二范式（2NF）
第二范式（2NF）是在第一范式（1NF）的基礎上建立起來的，即滿足第二范式（2NF）必須先滿足第一范式（1NF）。第二范式（2NF）要求數據庫表中的每個實例或行必須可以被惟一地區分。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。如圖3-2 員工信息表中加上了員工編號（emp_id）列，因為每個員工的員工編號是惟一的，因此每個員工可以被惟一區分。這個惟一屬性列被稱為主關鍵字或主鍵、主碼。第二范式（2NF）要求實體的屬性完全依賴于主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那么這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。簡而言之，第二范式就是非主屬性非部分依賴于主關鍵字。
3 第三范式（3NF）
滿足第三范式（3NF）必須先滿足第二范式（2NF）。簡而言之，第三范式（3NF）要求一個數據庫表中不包含已在其它表中已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那么在圖3-2的員工信息表中列出部門編號后就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三范式（3NF）也應該構建它，否則就會有大量的數據冗余。簡而言之，第三范式就是屬性不依賴于其它非主屬性。
例子：
第一范式（1NF）：數據庫表中的字段都是單一屬性的，不可再分。這個單一屬性由基本類型構成，包括整型、實數、字符型、邏輯型、日期型等。
例如，如下的數據庫表是符合第一范式的：字段1 字段2 字段3 字段4
而這樣的數據庫表是不符合第一范式的：字段1 字段2 字段3 字段4 字段31字段32
很顯然，在當前的任何關系數據庫管理系統（S）中，傻瓜也不可能做出不符合第一范式的數據庫，因為這些S不允許你把數據庫表的一列再分成二列或多列。因此，你想在現有的S中設計出不符合第一范式的數據庫都是不可能的。
第二范式（2NF）：數據庫表中不存在非關鍵字段對任一候選關鍵字段的部分函數依賴（部分函數依賴指的是存在組合關鍵字中的某些字段決定非關鍵字段的情況），也即所有非關鍵字段都完全依賴于任意一組候選關鍵字。
假定選課關系表為Ss(學號, 姓名, 年齡, 課程名稱, 成績, 學分)，關鍵字為組合關鍵字(學號, 課程名稱)，因為存在如下決定關系：
　　(學號, 課程名稱) → (姓名, 年齡, 成績, 學分)
　　這個數據庫表不滿足第二范式，因為存在如下決定關系：
　　(課程名稱) → (學分)
　　(學號) → (姓名, 年齡)
　　即存在組合關鍵字中的字段決定非關鍵字的情況。
由于不符合2NF，這個選課關系表會存在如下問題：1) 數據冗余：同一門課程由n個學生選修，”學分”就重復n-1次；同一個學生選修了門課程，姓名和年齡就重復了-1次。2) 更新異常：若調整了某門課程的學分，數據表中所有行的”學分”值都要更新，否則會出現同一門課程學分不同的情況。3) 插入異常：假設要開設一門新的課程，暫時還沒有人選修。由于還沒有”學號”關鍵字，課程名稱和學分也無法記錄入數據庫。4) 刪除異常：假設一批學生已經完成課程的選修，這些選修記錄就應該從數據庫表中刪除。但是，與此同時，課程名稱和學分信息也被刪除了。很顯然，這也會導致插入異常。
　　把選課關系表Ss改為如下三個表：
　　學生：Sn(學號, 姓名, 年齡)；
　　課程：s(課程名稱, 學分)；
　　選課關系：Ss(學號, 課程名稱, 成績)。
　　這樣的數據庫表是符合第二范式的，消除了數據冗余、更新異常、插入異常和刪除異常。
　　另外，所有單關鍵字的數據庫表都符合第二范式，因為不可能存在組合關鍵字。
第三范式（3NF）：在第二范式的基礎上，數據表中如果不存在非關鍵字段對任一候選關鍵字段的傳遞函數依賴則符合第三范式。所謂傳遞函數依賴，指的是如果存在”A → → “的決定關系，則傳遞函數依賴于A。因此，滿足第三范式的數據庫表應該不存在如下依賴關系：關鍵字段 → 非關鍵字段x → 非關鍵字段y
　　假定學生關系表為Sn(學號, 姓名, 年齡, 所在[]學院[], 學院地點, 學院電話)，關鍵字為單一關鍵字”學號”，因為存在如下決定關系：
　　(學號) → (姓名, 年齡, 所在[]學院[], 學院[]地點, []學院[]電話)
　　這個數據庫是符合2NF的，但是不符合3NF，因為存在如下決定關系：
　　(學號) → (所在[]學院[]) → ([]學院[]地點, []學院[]電話)
　　即存在非關鍵字段”[]學院[]地點”、”[]學院[]電話”對關鍵字段”學號”的傳遞函數依賴。
　　它也會存在數據冗余、更新異常、插入異常和刪除異常的情況，讀者可自行分析得知。
　　把學生關系表分為如下兩個表：
　　學生：(學號, 姓名, 年齡, 所在[]學院[])；
　　[]學院[]：([]學院[], 地點, 電話)。
　　這樣的數據庫表是符合第三范式的，消除了數據冗余、更新異常、插入異常和刪除異常。
鮑依斯-科得范式（BCNF）：在第三范式的基礎上，數據庫表中如果不存在任何字段對任一候選關鍵字段的傳遞函數依賴則符合BCNF.
假設倉庫管理關系表為Ssanag(倉庫, 存儲物品, 管理員, 數量)，且有一個管理員只在一個倉庫工作；一個倉庫可以存儲多種物品。這個數據庫表中存在如下決定關系：
　　(倉庫, 存儲物品) →(管理員, 數量)
　　(管理員, 存儲物品) → (倉庫, 數量)
　　所以，(倉庫, 存儲物品)和(管理員, 存儲物品)都是Ssanag的候選關鍵字，表中的唯一非關鍵字段為數量，它是符合第三范式的。但是，由于存在如下決定關系：
　　(倉庫) → (管理員)
　　(管理員) → (倉庫)
　　即存在關鍵字段決定關鍵字段的情況，所以其不符合BCNF范式。它會出現如下異常情況：1) 刪除異常：當倉庫被清空后，所有”存儲物品”和”數量”信息被刪除的同時，”倉庫”和”管理員”信息也被刪除了。2) 插入異常：當倉庫沒有存儲任何物品時，無法給倉庫分配管理員。3) 更新異常：如果倉庫換了管理員，則表中所有行的管理員都要修改。
　　把倉庫管理關系表分解為二個關系表：
　　倉庫管理：Ssanag(倉庫, 管理員)；
　　倉庫：Ss(倉庫, 存儲物品, 數量)。
　　這樣的數據庫表是符合BCNF范式的，消除了刪除異常、插入異常和更新異常。
簡言之數據庫五大范式：
第一范式：對于表中的每一行，必須且僅僅有唯一的行值.在一行中的每一列僅有唯一的值并且具有原子性.
（第一范式是通過把重復的組放到每個獨立的表中，把這些表通過一對多關聯聯系起來這種方式來消除重復組的）
第二范式：第二范式要求非主鍵列是主鍵的子集，非主鍵列活動必須完全依賴整個主鍵。主鍵必須有唯一性的元素,一個主鍵可以由一個或更多的組成唯一值的列組成。一旦創建，主鍵無法改變，外鍵關聯一個表的主鍵。主外鍵關聯意味著一對多的關系.（第二范式處理冗余數據的刪除問題。當某張表中的信息依賴于該表中其它的不是主鍵部分的列的時候，通常會違反第二范式）
第三范式：第三范式要求非主鍵列互不依賴.（第三范式規則查找以消除沒有直接依賴于第一范式和第二范式形成的表的主鍵的屬性。我們為沒有與表的主鍵關聯的所有信息建立了一張新表。每張新表保存了來自源表的信息和它們所依賴的主鍵）
第四范式：第四范式禁止主鍵列和非主鍵列一對多關系不受約束
第五范式：第五范式將表分割成盡可能小的塊，為了排除在表中所有的冗余。

2，索引：

什么叫 revised key index?

反鍵索引是B*Tree索引的一個分支，它的設計是為了運用在某些特定的環境下的。Oracle推出它的主要目的就是為了降低在并行服務器（Oracle Parallel Server）環境下索引葉塊的爭用。當B*Tree索引中有一列是由遞增的序列號產生的話，那么這些索引信息基本上分布在同一個葉塊，當用戶修改或訪問相似的列時，索引塊很容易產生爭用。反向索引中的索引碼將會被分布到各個索引塊中，減少了爭用.

例子：有一個字段id，他的值落在一個很小的區間，比如從9000-9999，如果建b-tree索引，那么值過于緊密，反鍵的原理是把值取反，那么id的區間就從0009-9999，區間就被放大，這個時候通過索引來查找數據效率會比較高（oracle這么說的）。  

好處是:解決了樹的傾斜問題，而且可以解決在大量IO操作的情況下,防止硬盤在某個區域操作過于頻繁,引起”熱點”問題。

樹的分支：因為索引一般是按樹這個數據結構來組織，所以有很多分支，把不同類別或范圍的數據存放在分支里，在符合條件的分支里查詢比在全表查詢效率高很多。

樹的傾斜：樹的某個分支過與龐大,而其他分支內容卻很少，這樣的索引非常不健康的，查詢速度也很慢，如上面的示例數據，都在10000-20000 的分支，而20000-30000或者以上的分支是空的。反轉后把這些數據均勻分布到不同的分支，可以使索引更加健康，也更有效率。

熱點問題：由于系統在表數據的增刪改查的同時，同時要承擔索引開支，而這主要是硬盤的IO操作，如果樹是傾斜的，而且數據的增加是按一定順序增長的，這種情況會導致硬盤對某一固定區域操作頻繁，會出現熱點問題，而且出現瓶頸。

Oracle五種索引：

1）b*tree index：幾乎所有的關系型數據庫中都有b*tree類型索引，也是被最多使用的。其樹結構與二叉樹比較類似，根據rid快速定位所訪問的行。 B-Tree索引是基于二叉樹的，由分支塊（branch block）和葉塊（leaf block）組成。在樹結構中，位于最底層底塊被稱為葉塊，包含每個被索引列的值和行所對應的rowid。在葉節點的上面是分支塊，用來導航結構，包含了索引列（關鍵字）范圍和另一索引塊的地址。

2）反向索引：反轉了b*tree索引碼中的字節，是索引條目分配更均勻，多用于并行服務器環境下，用于減少索引葉的競爭。反向索引又一個缺點就是不能在所有使用常規索引的地方使用。在范圍搜索中其不能被使用。

3）降序索引：8i中新出現的索引類型，針對逆向排序的查詢。

4）位圖索引：使用位圖來管理與數據行的對應關系，多用于OLAP系統。位圖索引最好用于低cardinality列（即列的唯一值除以行數為一個很小的值，接近零），例如又一個“性別”列，列值有“Male”，“Female”，“Null”等3種，但一共有300萬條記錄，那么3/3000000約等于0，這種情況下最適合用位圖索引。位圖以一種壓縮格式存放，因此占用的磁盤空間比B-Tree索引要小得多。

5）函數索引：這種索引中保存了數據列基于function返回的值，在select * from table where function(column)=value這種類型的語句中起作用?；诤瘮档乃饕彩?i以來的新產物，它有索引計算列的能力，它易于使用并且提供計算好的值，在不修改應用程序的邏輯上提高了查詢性能。使用基于函數的索引有幾個先決條件：

（1）必須擁有QUERY REWRITE（本模式下）或GLOBAL QUERY REWRITE（其他模式下）權限。

（2）必須使用基于成本的優化器，基于規則的優化器將被忽略。

（3）必須設置以下兩個系統參數：

QUERY_REWRITE_ENABLED=TRUE

QUERY_REWRITE_INTEGRITY=TRUSTED

可以通過alter system set,alter session set在系統級或線程級設置，也可以通過在init.ora添 加實現。

五種索引的創建：

（1）*Tree索引。

Create index indexname on tablename(columnname[columnname...])

（2）反向索引。

Create index indexname on tablename(columnname[columnname...]) reverse

（3）降序索引。

Create index indexname on tablename(columnname DESC[columnname...])

（4）位圖索引。

Create BITMAP index indexname on tablename(columnname[columnname...])

（5）函數索引。

Create index indexname on tablename(functionname(columnname))

注意：創建索引后分析要索引才能起作用。

五種索引的使用場所：

（1）B*Tree索引。

常規索引，多用于oltp系統，快速定位行，應建立于高cardinality列（即列的唯一值除以行數為一個很大的值，存在很少的相同值）。

（2）反向索引。

B*Tree的衍生產物，應用于特殊場合，在ops環境加序列增加的列上建立，不適合做區域掃描。

（3）降序索引。

B*Tree的衍生產物，應用于有降序排列的搜索語句中，索引中儲存了降序排列的索引碼，提供了快速的降序搜索。

（4）位圖索引。

位圖方式管理的索引，適用于OLAP（在線分析）和DSS（決策處理）系統，應建立于低cardinality列，適合集中讀取，不適合插入和修改，提供比B*Tree索引更節省的空間。

（5）函數索引。

B*Tree的衍生產物，應用于查詢語句條件列上包含函數的情況，索引中儲存了經過函數計算的索引碼值?？梢栽诓恍薷膽贸绦虻幕A上能提高查詢效率。

索引不管用的時候：

（1）RBO&CBO。

Oracle有兩種執行優化器，一種是RBO(Rule Based Optimizer)基于規則的優化器，這種優化器是基于sql語句寫法選擇執行路徑的；另一種是CBO（Cost Based Optimizer）基于規則的優化器，這種優化器是Oracle根據統計分析信息來選擇執行路徑，如果表和索引沒有進行分析，Oracle將會使用RBO代替CBO；如果表和索引很久未分析，CBO也有可能選擇錯誤執行路徑，不過CBO是Oracle發展的方向，自8i版本來已經逐漸取代RBO.

（2）AUTOTRACE。

要看索引是否被使用我們要借助Oracle的一個叫做AUTOTRACE功能,它顯示了sql語句的執行路徑，我們能看到Oracle內部是怎么執行sql的，這是一個非常好的輔助工具，在sql調優里廣泛被運用。我們來看一下怎么運用AUTOTRACE：

① 由于AUTOTRACE自動為用戶指定了Execution Plan,因此該用戶使用AUTOTRACE前必須已經建立了PLAN_TABLE。如果沒有的話，請運行utlxplan.sql腳本（它在$ORACLE_HOME/rdbms/admin目錄中）。

② AUTOTRACE可以通過運行plustrce.sql腳本(它在$ORACLE_HOME/sqlplus/admin目錄中)來設置，用sys用戶登陸然后運行plustrce.sql后會建立一個PLUSTRACE角色，然后給相關用戶授予PLUSTRACE角色，然后這些用戶就可以使用AUTOTRACE功能了。

③ AUTOTRACE的默認使用方法是set autotrace on，但是這方法不總是適合各種場合，特別當返回行數很多的時候。Set autotrace traceonly提供了只查看統計信息而不查詢數據的功能。

３，死鎖

是指兩個或兩個以上的進程在執行過程中,因爭奪資源而造成的一種互相等待的現象,若無外力作用,它們都將無法推進下去.此時稱系統處于死鎖狀態或系統產生了死鎖,這些永遠在互相等待的進程稱為死鎖進程.由于資源占用是互斥的，當某個進程提出申請資源后，使得有關進程在無外力協助下，永遠分配不到必需的資源而無法繼續運行，這就產生了一種特殊現象死鎖。

產生死鎖的原因主要是：

（1） 因為系統資源不足。

（2） 進程運行推進的順序不合適。

（3） 資源分配不當等。

如果系統資源充足，進程的資源請求都能夠得到滿足，死鎖出現的可能性就很低，否則就會因爭奪有限的資源而陷入死鎖。其次，進程運行推進順序與速度不同，也可能產生死鎖。

產生死鎖的四個必要條件：

（1） 互斥條件：一個資源每次只能被一個進程使用。

（2） 請求與保持條件：一個進程因請求資源而阻塞時，對已獲得的資源保持不放。

（3） 不剝奪條件:進程已獲得的資源，在末使用完之前，不能強行剝奪。

（4） 循環等待條件:若干進程之間形成一種頭尾相接的循環等待資源關系。

這四個條件是死鎖的必要條件，只要系統發生死鎖，這些條件必然成立，而只要上述條件之一不滿足，就不會發生死鎖。

例子：

運行事務 1 的線程 T1 具有學生基本信息表上的排它鎖。運行事務2的線程 T2 具有系部表上的排它鎖，并且之后需要學生基本信息表上的鎖。事務2 無法獲得這一鎖，因為事務 1 已擁有它。事務2 被阻塞，等待事務 1。然后，事務1 需要系部表的鎖，但無法獲得鎖，因為事務 2 將它鎖定了。事務在提交或回滾之前不能釋放持有的鎖。因為事務需要對方控制的鎖才能繼續操作，所以它們不能提交或回滾。

4，BYTE[] buf = BYTE[1024];in.read(buf)；

in是一個接收圖像數據的網絡IO流，請指出這段代碼有什么問題，并請用java代碼改進它。

答：流操作都可能會跑出IOException，應該對該異常進行捕獲處理。且當buf沒有被初始化的時候使用會拋出NullPointerException。

byte [] buf = new byte[1024];

try {

         System.in.read(buf);

} catch (IOException e) {           

         e.printStackTrace();

}

5，設計模式：Facade

你正在分析一個子系統的接口，發現接口很多。然后你同事勸你用Fecade, 問你用Fecade有什么好處？

Facade（外觀）模式為子系統中的各類（或結構與方法）提供一個簡明一致的界面，隱藏子系統的復雜性，使子系統更加容易使用。Facade模式正是這樣一個“門面”：我們本來需要與后臺的多個類或者接口打交道，而Facade模式是客戶端和后臺之間插入一個中間層——門面，這個門面跟后臺的多個類或接口打交道，而客戶端只需要跟門面打交道即可。使用Facade模式可以說是后臺設計和編碼人員的一個必備素質。我不止碰到過一個這樣的后臺開發人員，他們認為只要把后臺功能完成了就萬事大吉，而沒有站在后臺使用者的角度來看一看自己寫出來的代碼。其實，我們寫出來的后臺代碼是要給別人使用的，所以我們提供給使用者的接口要越簡單越好，這不單是對使用者好，同時對開發者也是好處多多的，至少你的接口簡單了，你和使用者的交流就容易了。

區分Fa?ade模式、Adapter模式、Bridge模式與Decorator模式。Fa?ade模式注重簡化接口，Adapter模式注重轉換接口，Bridge模式注重分離接口（抽象）與其實現，Decorator模式注重穩定接口的前提下為對象擴展功能

在遇到以下情況使用Facade模式：

1）當你要為一個復雜子系統提供一個簡單接口時。子系統往往因為不斷演化而變得越來越復雜。大多數模式使用時都會產生更多更小的類。這使得子系統更具可重用性，也更容易對子系統進行定制，但這也給那些不需要定制子系統的用戶帶來一些使用上的困難?！acade可以提供一個簡單的缺省視圖，這一視圖對大多數用戶來說已經足夠，而那些需要更多的可定制性的用戶可以越過Facade層。

2）客戶程序與抽象類的實現部分之間存在著很大的依賴性。引入Facade將這個子系統與客戶以及其他的子系統分離，可以提高子系統的獨立性和可移植性。

3）當你需要構建一個層次結構的子系統時，使用Facade模式定義子系統中每層的入口點，如果子系統之間是相互依賴的，你可以讓它們僅通過Facade進行通訊，從而簡化了它們之間的依賴關系。

優缺點：

1）它對客戶屏蔽子系統組件，因而減少了客戶處理的對象的數目并使得子系統使用起來更加方便。

2）它實現了子系統與客戶之間的松耦合關系，而子系統內部的功能組件往往是緊耦合的。

松耦合關系使得子系統的組件變化不會影響到它的客戶。Facade模式有助于建立層次結構系統，也有助于對對象之間的依賴關系分層。Facade模式可以消除復雜的循環依賴關系。這一點在客戶程序與子系統是分別實現的時候尤為重要。在大型軟件系統中降低編譯依賴性至關重要。在子系統類改變時，希望盡量減少重編譯工作以節省時間。用Facade可以降低編譯依賴性，限制重要系統中較小的變化所需的重編譯工作。Facade模式同樣也有利于簡化系統在不同平臺之間的移植過程，因為編譯一個子系統一般不需要編譯所有其他的子系統。數據分析師認證

6，冷備份與熱備份

冷備份：

冷備份發生在數據庫已經正常關閉的情況下，當正常關閉時會提供給我們一個完整的數據庫。冷備份是將關鍵性文件拷貝到另外位置的一種說法。對于備份Oracle信息而言，冷備份是最快和最安全的方法。

冷備份的優點是：

1．是非?？焖俚膫浞莘椒ǎㄖ恍杩截愇募?/span>

2．容易歸檔（簡單拷貝即可）

3．容易恢復到某個時間點上（只需將文件再拷貝回去）

4．能與歸檔方法相結合，作數據庫“最新狀態”的恢復。

5．低度維護，高度安全。

冷備份也有如下不足：

1．單獨使用時，只能提供到“某一時間點上”的恢復。

2．在實施備份的全過程中，數據庫必須要作備份而不能作其它工作。也就是說，在冷備份過程中，數據庫必須是關閉狀態。

3．若磁盤空間有限，只能拷貝到磁帶等其它外部存儲設備上，速度會很慢。

4．不能按表或按用戶恢復。

如果可能的話（主要看效率），應將信息備份到磁盤上，然后啟動數據庫（使用戶可以工作）并將所備份的信息拷貝到磁帶上（拷貝的同時，數據庫也可以工作）。

冷備份中必須拷貝的文件包括：

1．所有數據文件

2．所有控制文件

3．所有聯機REDO LOG文件

4．Init.ora文件（可選）。

下面是做冷備份的完整例子：

（1） 關閉數據庫＄sqldba lmode=y

SQLDBA >connect internal;

SQLDBA >shutdown normal;

（2） 用拷貝命令備份全部的時間文件、重做日志文件、控制文件、初始化參數文件

SQLDBA >! cp < file > < backup directory >

（3） 重啟Oracle數據庫

＄sqldba lmode=y

SQLDBA >connect internal;

SQLDBA >startup;

熱備份

熱備份是在數據庫運行的情況下，采用archivelog mode方式備份數據的方法。所以，如果你有昨天夜里的一個冷備份而且又有今天的熱備份文件，在發生問題時，就可以利用這些資料恢復更多的信息。

熱備份的要求是：

1. 熱備份工作必需要求數據庫在Archivelog 方式下操作,在SQLDBA狀態下用alter database archivelog|noarchivelog命令可改變備份的模式。數據分析師培訓