資料庫常見問題

A. 資料庫老師會問哪些問題

1.Mysql 主鍵與索引的聯系與區別

主鍵是為了標識資料庫記錄唯一性，不允許記錄重復，且鍵值不能為空，主鍵也是一個特殊索引。

數據表中只允許有一個主鍵，但是可以有多個索引。

使用主鍵會資料庫會自動創建主索引，也可以在非主鍵上創建索引，方便查詢效率。

索引可以提高查詢速度，它就相當於字典的目錄，可以通過它很快查詢到想要的結果，而不需要進行全表掃描。

主鍵索引外索引的值可以為空。

主鍵也可以由多個欄位組成，組成復合主鍵，同時主鍵肯定也是唯一索引。

唯一索引則表示該索引值唯一，可以由一個或幾個欄位組成，一個表可以有多個唯一索引。

2.資料庫索引是怎麼回事？用的啥數據結構 為什麼B+樹比B樹更合適

一個索引是存儲的表中一個特定列的值數據結構（最常見的是B-Tree）。索引是在表的列上創建。所以，要記住的關鍵點是索引包含一個表中列的值，並且這些值存儲在一個數據結構中。請記住記住這一點：索引是一種數據結構 。

什麼樣的數據結構可以作為索引？

B-Tree 是最常用的用於索引的數據結構。因為它們是時間復雜度低， 查找、刪除、插入操作都可以可以在對數時間內完成。另外一個重要原因存儲在B-Tree中的數據是有序的。資料庫管理系統（RDBMS）通常決定索引應該用哪些數據結構。但是，在某些情況下，你在創建索引時可以指定索引要使用的數據結構。

當我們利用索引查詢的時候，不可能把整個索引全部載入到內存，只能逐一載入每個磁碟頁，磁碟頁對應索引樹的節點。那麼Mysql衡量查詢效率的標准就是磁碟IO次數。如果我們利用二叉樹作為索引結構，那麼磁碟的IO次數和索引樹的高度是相關的。

那麼為了提高查詢效率，就需要減少磁碟IO數。為了減少磁碟IO的次數，就需要盡量降低樹的高度，需要把原來「瘦高」的樹結構變的「矮胖」，樹的每層的分叉越多越好，因此B樹正好符合我們的要求，這也是B-樹的特徵之一。

B樹 B樹的節點為關鍵字和相應的數據（索引等）

B+樹 B+樹是B樹的一個變形，非葉子節點只保存索引，不保存實際的數據，數據都保存在葉子節點中，B+樹的葉子節點為鏈表，鏈表放數據，非葉子節點是索引。

對比：

• B樹和B+樹同樣適用於高度越低，查詢越快。

• B樹查找節點，B+樹只需要查詢所有節點（索引），B樹查詢索引和數據。雖然可能第一個就找到，但在極端情況下，需要全查詢索引和數據，不如B+樹穩定。

• B+樹和B樹比，B+樹的硬碟空間更少，io的讀寫代價更低。因為B+樹節點只有索引，佔位更少。在查詢的情況下硬碟指針移動更低

哈希表索引是怎麼工作的？

哈希表是另外一種你可能看到用作索引的數據結構-這些索引通常被稱為哈希索引。使用哈希索引的原因是，在尋找值時哈希表效率極高。所以，如果使用哈希索引，對於比較字元串是否相等的查詢能夠極快的檢索出的值。例如之前我們討論過的這個查詢(SELECT * FROM Employee WHERE Employee_Name = 『Jesus』) 就可以受益於創建在Employee_Name 列上的哈希索引。哈系索引的工作方式是將列的值作為索引的鍵值（key），和鍵值相對應實際的值（value）是指向該表中相應行的指針。因為哈希表基本上可以看作是關聯數組，一個典型的數據項就像「Jesus => 0x28939″，而0x28939是對內存中表中包含Jesus這一行的引用。在哈系索引的中查詢一個像「Jesus」這樣的值，並得到對應行的在內存中的引用，明顯要比掃描全表獲得值為「Jesus」的行的方式快很多。

哈希索引的缺點

哈希表是無順的數據結構，對於很多類型的查詢語句哈希索引都無能為力。舉例來說，假如你想要找出所有小於40歲的員工。你怎麼使用使用哈希索引進行查詢？這不可行，因為哈希表只適合查詢鍵值對-也就是說查詢相等的查詢（例：like 「WHERE name = 『Jesus』）。哈希表的鍵值映射也暗示其鍵的存儲是無序的。這就是為什麼哈希索引通常不是資料庫索引的默認數據結構-因為在作為索引的數據結構時，其不像B-Tree那麼靈活

3.創建索引的注意事項

索引可以提高數據的訪問速度，但同時也增加了插入、更新和刪除操作的處理時間，解決此問題就是分析應用程序的業務處理、數據使用，為經常被用作查詢條件、或者被要求排序的欄位建立索引。索引是建立在資料庫表中的某些列的上面。因此，在創建索引的時候，應該仔細考慮在哪些列上可以創建索引，在哪些列上不能創建索引。

創建規則：

• 表的主鍵、外鍵必須有索引；

• 數據量超過300的表應該有索引；

• 經常與其他表進行連接的表，在連接欄位上應該建立索引；

• 經常出現在Where子句中的欄位，特別是大表的欄位，應該建立索引；

• 索引應該建在選擇性高的欄位上；

• 索引應該建在小欄位上，對於大的文本欄位甚至超長欄位，不要建索引；

• 復合索引的建立需要進行仔細分析；盡量考慮用單欄位索引代替

• 頻繁進行數據操作的表，不要建立太多的索引；

• 刪除無用的索引，避免對執行計劃造成負面影響；

創建索引需要注意的地方：

• 限製表上的索引數目。對一個存在大量更新操作的表，所建索引的數目一般不要超過3個，最多不要超過5個。索引雖說提高了訪問速度，但太多索引會影響數據的更新操作。

• 避免在取值朝一個方向增長的欄位（例如：日期類型的欄位）上，建立索引；對復合索引，避免將這種類型的欄位放置在最前面

• 對復合索引，按照欄位在查詢條件中出現的頻度建立索引

• 刪除不再使用，或者很少被使用的索引。

4.MYSQL事務特性和實現原理

ACID表示原子性（atomicity）、一致性（consistency）、隔離性（isolation）和持久性（rability）。一個很好的事務處理系統，必須具備這些標准特性：

原子性（atomicity）

一個事務必須被視為一個不可分割的最小工作單元，整個事務中的所有操作要麼全部提交成功，要麼全部失敗回滾，對於一個事務來說，不可能只執行其中的一部分操作，這就是事務的原子性

是利用Innodb的undo log。undo log名為回滾日誌，是實現原子性的關鍵，當事務回滾時能夠撤銷所有已經成功執行的sql語句，他需要記錄你要回滾的相應日誌信息。

一致性（consistency）

資料庫總是從一個一致性的狀態轉換到另一個一致性的狀態。（在前面的例子中，一致性確保了，即使在執行第三、四條語句之間時系統崩潰，支票賬戶中也不會損失200美元，因為事務最終沒有提交，所以事務中所做的修改也不會保存到資料庫中。）

資料庫通過原子性、隔離性、持久性來保證一致性

隔離性（isolation）

通常來說，一個事務所做的修改在最終提交以前，對其他事務是不可見的。（在前面的例子中，當執行完第三條語句、第四條語句還未開始時，此時有另外的一個賬戶匯總程序開始運行，則其看到支票帳戶的余額並沒有被減去200美元。）

利用的是鎖和MVCC機制。MVCC,即多版本並發控制(Multi Version Concurrency Control),一個行記錄數據有多個版本對快照數據，這些快照數據在undo log中。如果一個事務讀取的行正在做DELELE或者UPDATE操作，讀取操作不會等行上的鎖釋放，而是讀取該行的快照版本。

持久性（rability）

一旦事務提交，則其所做的修改會永久保存到資料庫。（此時即使系統崩潰，修改的數據也不會丟失。持久性是個有占模糊的概念，因為實際上持久性也分很多不同的級別。有些持久性策略能夠提供非常強的安全保障，而有些則未必，而且不可能有能做到100%的持久性保證的策略。）

是利用Innodb的redo log。當做數據修改的時候，不僅在內存中操作，還會在redo log中記錄這次操作。當事務提交的時候，會將redo log日誌進行刷盤(redo log一部分在內存中，一部分在磁碟上)。當資料庫宕機重啟的時候，會將redo log中的內容恢復到資料庫中，再根據undo log和binlog內容決定回滾數據還是提交數據。redo log體積小，刷盤快。redo log是一直往末尾進行追加，屬於順序IO。效率顯然比隨機IO來的快

5.redis的原理和優點

redis是一個key-value存儲系統.和Memcached類似，它支持存儲的value類型相對更多，包括string(字元串)、list(鏈表)、set(集合)、zset(sorted set --有序集合)和hashs（哈希類型）

這些數據類型都支持push/pop、add/remove及取交集並集和差集及更豐富的操作，而且這些操作都是原子性的.

在此基礎上，redis支持各種不同方式的排序.與memcached一樣，為了保證效率，數據都是緩存在內存中.區別的是redis會周期性的把更新的數據寫入磁碟或者把修改操作寫入追加的記錄文件，並且在此基礎上實現了master-slave(主從)同步.

Redis的優點:

• 性能極高 – Redis能支持超過 100K+ 每秒的讀寫頻率。

• 豐富的數據類型 – Redis支持二進制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 數據類型操作。

• 原子 – Redis的所有操作都是原子性的，同時Redis還支持對幾個操作全並後的原子性執行。

• 豐富的特性 – Redis還支持 publish/subscribe, 通知, key 過期等等特性。

6.Mysql中的鎖機制

Mysql用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。這些鎖統稱為悲觀鎖

MySQL的鎖機制比較簡單，其最 顯著的特點是不同的存儲引擎支持不同的鎖機制。比如，MyISAM和MEMORY存儲引擎採用的是表級鎖（table-level locking）；BDB存儲引擎採用的是頁面鎖（page-level locking），但也支持表級鎖；InnoDB存儲引擎既支持行級鎖（row-level locking），也支持表級鎖，但默認情況下是採用行級鎖。

• 表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖沖突的概率最高，並發度最低。

• 行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖沖突的概率最低，並發度也最高。

• 頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間；會出現死鎖；鎖定粒度界於表鎖和行鎖之間，並發度一般

從上述特點可見，很難籠統地說哪種鎖更好，只能就具體應用的特點來說哪種鎖更合適！僅從鎖的角度 來說：表級鎖更適合於以查詢為主，只有少量按索引條件更新數據的應用，如Web應用；而行級鎖則更適合於有大量按索引條件並發更新少量不同數據，同時又有 並發查詢的應用，如一些在線事務處理（OLTP）系統。

7.ABC聯合索引生效問題

對於復合索引：Mysql從左到右的使用索引中的欄位，一個查詢可以只使用索引中的一部份，但只能是最左側部分。例如索引是key index （a,b,c）。 可以支持a | a,b| a,b,c 3種組合進行查找，但不支持 b,c進行查找 .當最左側欄位是常量引用時，索引就十分有效。

對於復合索引：Mysql從左到右的使用索引中的欄位，一個查詢可以只使用索引中的一部份，但只能是最左側部分。例如索引是key index （a,b,c）。 可以支持a | a,b| a,b,c 3種組合進行查找，但不支持 b,c進行查找 .當最左側欄位是常量引用時，索引就十分有效。

B. 聽書寶資料庫連續錯誤怎麼辦

原因一：登錄賬號、密碼、伺服器名稱、資料庫名稱登錄錯誤導致不能連接，這個比較常見，仔細檢查好所填信息是否正確，填寫正確一般就可以解決。

解決方法：當正在使用的軟體出現資料庫不能連接時，一般就是伺服器名出現問題，更改伺服器名稱一般可以解決問題。資料庫如果是安裝在本機，伺服器名可以用「.」或「(local)」來代替 ；如果是安裝在區域網的其它計算機上，可以用IP地址作為伺服器名。

原因二：如果沒能正確安裝SQL伺服器，也會導致資料庫連接不上；安裝好資料庫後，如果SQL服務管理器沒有啟動，則要去服務那裡開啟。

解決方法：如果是SQL資料庫未能能成功安裝，再次重新安裝時，可能會無法安裝，提示是存在一個未完成的安裝掛起。解決就方法是：打開注冊表編輯器，在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager中找到並刪除PendingFileRenameOperations項目即可。

如果是更改了Windows的用戶名或者密碼，會導致SQL服務管理器不能啟動,解決辦法是去控製版面的服務那裡修改啟動。具體是：點擊開始-->設置-->控制面板-->管理工具-->服務-->找到MS SQL SERVER服務-->在上面右鍵-->屬性-->登陸-->修改啟動服務的帳戶和密碼。

原因三：因許可權問題導致資料庫不能連接，解決方法是檢測計算機的安全保護限制、SQL Server安全設置、操作系統的安全限。

解決方法：可以先暫時關閉防火牆或者殺毒軟體，看是否是這些軟體的安全設置所導致。

SQL Server安全設置：打開企業管理器-->展開SQ L Server組-->右擊伺服器名-->點擊屬性-->在SQL Server屬性-->安全性中，把「身份驗證」選擇為「在SQL Server和Windows」； 

如果SQL伺服器採用的是Windows XP系統，當工作站電腦出現不能連接資料庫的情況時，可以在伺服器和工作站各建立一個相同的WINDOWS用戶賬號和密碼

C. redis常見問題

1. 緩存擊穿

緩存擊穿是指一個請求要訪問的數據，緩存中沒有，但資料庫中有的情況。這種情況一般都是緩存過期了。

但是這時由於並發訪問這個緩存的用戶特別多，這是一個熱點 key，這么多用戶的請求同時過來，在緩存裡面沒有取到數據，所以又同時去訪問資料庫取數據，引起資料庫流量激增，壓力瞬間增大，直接崩潰給你看。

所以一個數據有緩存，每次請求都從緩存中快速的返回了數據，但是某個時間點緩存失效了，某個請求在緩存中沒有請求到數據，這時候我們就說這個請求就"擊穿"了緩存。

針對這個場景，對應的解決方案一般來說有三種。

藉助Redis setNX命令設置一個標志位就行。設置成功的放行，設置失敗的就輪詢等待。就是在更新緩存時加把鎖

後台開一個定時任務，專門主動更新過期數據

比如程序中設置 why 這個熱點 key 的時候，同時設置了過期時間為 10 分鍾，那後台程序在第 8 分鍾的時候，會去資料庫查詢數據並重新放到緩存中，同時再次設置緩存為 10 分鍾。

其實上面的後台續命思想的最終體現是也是永不過期。

只是後台續命的思想，會主動更新緩存，適用於緩存會變的場景。會出現緩存不一致的情況，取決於你的業務場景能接受多長時間的緩存不一致。

2. 緩存穿透

緩存穿透是指一個請求要訪問的數據，緩存和資料庫中都沒有，而用戶短時間、高密度的發起這樣的請求，每次都打到資料庫服務上，給資料庫造成了壓力。一般來說這樣的請求屬於惡意請求。

解決方案有兩種：

就是在資料庫即使沒有查詢到數據，我們也把這次請求當做 key 緩存起來，value 可以是 NULL。下次同樣請求就會命中這個 NULL，緩存層就處理了這個請求，不會對資料庫產生壓力。這樣實現起來簡單，開發成本很低。

3. 緩存雪崩

緩存雪崩是指緩存中大多數的數據在同一時間到達過期時間，而查詢數據量巨大，這時候，又是緩存中沒有，資料庫中有的情況了。

防止雪崩的方案簡單來說就是錯峰過期。

在設置 key 過期時間的時候，在加上一個短的隨機過期時間，這樣就能避免大量緩存在同一時間過期，引起的緩存雪崩。

如果發了雪崩，我們可以有服務降級、熔斷、限流手段來拒絕一些請求，保證服務的正常。但是，這些對用戶體驗是有一定影響的。

4. Redis 高可用架構

Redis 高可用架構，大家基本上都能想到主從、哨兵、集群這三種模式。

哨兵模式：

它主要執行三種類型的任務：

哨兵其實也是一個分布式系統，我們可以運行多個哨兵。

然後這些哨兵之間需要相互通氣，交流信息，通過投票來決定是否執行自動故障遷移，以及選擇哪個從伺服器作為新的主伺服器。

哨兵之間採用的協議是 gossip，是一種去中心化的協議，達成的是最終一致性。

選舉規則：

D. 一般資料庫中容易存在哪些問題可以通過什麼途徑來解決這些問題

一般資料庫中容易存在四種問題，分別是：語句錯誤；用戶進程錯誤；網路故障；用戶錯誤。
語句錯誤：單個資料庫操作（選擇、插入、更新或刪除）失敗。可以嘗試在表中輸入無效的數據，與用戶合作來驗證並更改數據。
用戶進程錯誤：用戶非登出的異常退出用戶會話異常終止程序錯誤導致會話結束，對於上述錯誤，實例後台進程 PMON 會自動回滾未提交的事務，並釋放相關鎖資源。
網路故障：與資料庫的連接斷開。通過備份監聽程序、網路連接和網路介面卡可降低出現網路故障時影響系統可用性的可能性。
用戶錯誤：用戶成功完成了操作，但是操作不正確（刪除了表，或輸入了錯誤數據）。用戶可能會無意刪除或修改數據。如果發生這種情況， DBA 可能需要幫助用戶從錯誤中恢，如果用戶尚未提交或退出程序，則只可以回退操作。

E. 資料庫為什麼會損壞呢

資料庫損壞常見的原因有以下幾種：
1、事務日誌問題。比如事務日誌文件丟失；事務日誌文件在操作過程中被誤刪；事務日誌文件被損壞以及事務日誌文件過大，導致硬碟的空間不足等；
2、意外掉電或異常強制關機，造成數據文件損壞，主要資料庫正在被讀寫過程中異常關機；
3、資料庫的表被破壞或索引等被破壞，或者資料庫的其他對象被破壞或丟失等；
4、刪除了數據文件，或者更改了它的名字；
5、硬碟損壞，造成數據和日誌文件讀寫錯誤：
(1)感染病毒或者其他人為因素破壞；
(2)其他文件讀寫、存儲等原因

F. Mysql常見的幾個錯誤問題及解決方法

一、Can』t connect to MySQL server on 『localhost』 (10061)
翻譯：不能連接到 localhost 上的mysql
分析：這說明「localhost」計算機是存在的，但在這台機器上卻沒提供MySQL服務。
需要啟動這台機器上的MySQL服務,如果機子負載太高沒空相應請求也會產生這個錯誤。
解決:既然沒有啟動那就去啟動這台機子的mysql。如果啟動不成功，多數是因為你的my.ini配置的有問題。重新配置其即可。
如果覺得mysql負載異常，可以到mysql/bin 的目錄下執行mysqladmin -uroot -p123 processlist來查看mysql當前的進程。

二、Unknown MySQL Server Host 『localhosadst』 (11001)
翻譯：未知的MySQL伺服器 localhosadst
分析：伺服器 localhosasdst 不存在。或者根本無法連接
解決：仔細檢查自己論壇下面的 ./config.inc.php 找到$dbhost重新設置為正確的mysql 伺服器地址。

三、Access denied for user: 『roota@localhost』 (Using password: YES)
翻譯：用戶 roota 訪問 localhost 被拒絕（沒有允許通過）
分析：造成這個錯誤一般資料庫用戶名和密碼相對mysql伺服器不正確
解決：仔細檢查自己論壇下面的 ./config.inc.php 找到$dbuser、$dbpw核實後重新設置保存即可。

四、Access denied for user: 『red@localhost』 to database 『newbbs』
翻譯：用戶 red 在localhost 伺服器上沒有許可權操作資料庫newbbs
分析：這個提示和問題三是不同的。那個是在連接資料庫的時候就被阻止了，而這個錯誤是在對資料庫進行操作時引起的。比如在select update等等。這個是因為該用戶沒有操作資料庫相應的權力。比如select 這個操作在mysql.user.Select_priv里記錄 Y 可以操作N 不可以操作。
解決：如果是自己的獨立主機那麼更新mysql.user 的相應用戶記錄，比如這里要更新的用戶為red 。或者直接修改 ./config.inc.php 為其配置一個具有對資料庫操作許可權的用戶
或者通過如下的命令來更新授權grant all privileges on dbname.* to 『user』@』localhost』 identified by 『password』
提示：更新了mysql庫中的記錄一定要重啟mysql伺服器才能使更新生效
FLUSH PRIVILEGES;

五、No Database Selected
翻譯：沒有資料庫被選擇上
分析：產生的原因有兩種
config.inc.php 裡面$dbname設置的不對。致使資料庫根本不存在，所以在 $db->select_db($dbname); 時返回了false
和上面問題四是一樣的，資料庫用戶沒有select許可權，同樣會導致這樣的錯誤。當你發現config.inc.php的設置沒有任何問題，但還是提示這個錯誤，那一定就是這種情況了。
解決：對症下葯
打開config.inc.php 找到$dbname核實重新配置並保存
同問題四的解決方法

六、Can』t open file: 『xxx_forums.MYI』. (errno: 145)
翻譯：不能打開xxx_forums.MYI
問題分析：
這種情況是不能打開 cdb_forums.MYI 造成的，引起這種情況可能的原因有：
1、伺服器非正常關機，資料庫所在空間已滿，或一些其它未知的原因，對資料庫表造成了損壞。
2、類 unix 操作系統下直接將資料庫文件拷貝移動會因為文件的屬組問題而產生這個錯誤。
解決方法：
1、修復數據表
可以使用下面的兩種方式修復數據表：（第一種方法僅適合獨立主機用戶）
1）使用 myisamchk ，MySQL 自帶了專門用戶數據表檢查和修復的工具 —— myisamchk 。更改當前目錄到 MySQL/bin 下面，一般情況下只有在這個下面才能運行 myisamchk 命令。常用的修復命令為：myisamchk -r 數據文件目錄/數據表名.MYI；
2）通過 phpMyAdmin 修復， phpMyAdmin 帶有修復數據表的功能，進入到某一個表中後，點擊「操作」，在下方的「表維護」中點擊「修復表」即可。
注意：以上兩種修復方式在執行前一定要備份資料庫。

G. 資料庫系統中的常見故障有哪些

新增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. 用適當的方法對原資料庫進行資料庫全備份。