A. Oracle資料庫的常見問題有哪些
網站資料庫的安全問題主要是由哪些因素引起的呢？這一個問題其實和資料庫存的安全問題差不多， 據CVE的數據安全漏洞統計，Oracle、sql Server、MySQL等主流資料庫的漏洞逐年上升，以Oracle為例，當前漏洞總數已經超過了1200多個。
B. 資料庫老師會問哪些問題
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+樹節點只有索引，佔位更少。在查詢的情況下硬碟指針移動更低
表的主鍵、外鍵必須有索引；
數據量超過300的表應該有索引；
經常與其他表進行連接的表，在連接欄位上應該建立索引；
經常出現在Where子句中的欄位，特別是大表的欄位，應該建立索引；
索引應該建在選擇性高的欄位上；
索引應該建在小欄位上，對於大的文本欄位甚至超長欄位，不要建索引；
復合索引的建立需要進行仔細分析；盡量考慮用單欄位索引代替
頻繁進行數據操作的表，不要建立太多的索引；
刪除無用的索引，避免對執行計劃造成負面影響；
限製表上的索引數目。對一個存在大量更新操作的表，所建索引的數目一般不要超過3個，最多不要超過5個。索引雖說提高了訪問速度，但太多索引會影響數據的更新操作。
避免在取值朝一個方向增長的欄位（例如：日期類型的欄位）上，建立索引；對復合索引，避免將這種類型的欄位放置在最前面
對復合索引，按照欄位在查詢條件中出現的頻度建立索引
刪除不再使用，或者很少被使用的索引。
性能極高 – Redis能支持超過 100K+ 每秒的讀寫頻率。
豐富的數據類型 – Redis支持二進制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 數據類型操作。
原子 – Redis的所有操作都是原子性的，同時Redis還支持對幾個操作全並後的原子性執行。
豐富的特性 – Redis還支持 publish/subscribe, 通知, key 過期等等特性。
表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖沖突的概率最高，並發度最低。
行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖沖突的概率最低，並發度也最高。
頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間；會出現死鎖；鎖定粒度界於表鎖和行鎖之間，並發度一般
哈希表索引是怎麼工作的？
哈希表是另外一種你可能看到用作索引的數據結構-這些索引通常被稱為哈希索引。使用哈希索引的原因是，在尋找值時哈希表效率極高。所以，如果使用哈希索引，對於比較字元串是否相等的查詢能夠極快的檢索出的值。例如之前我們討論過的這個查詢(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.創建索引的注意事項
索引可以提高數據的訪問速度，但同時也增加了插入、更新和刪除操作的處理時間，解決此問題就是分析應用程序的業務處理、數據使用，為經常被用作查詢條件、或者被要求排序的欄位建立索引。索引是建立在資料庫表中的某些列的上面。因此，在創建索引的時候，應該仔細考慮在哪些列上可以創建索引，在哪些列上不能創建索引。
創建規則：
創建索引需要注意的地方：
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的優點:
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進行查找 .當最左側欄位是常量引用時，索引就十分有效。
C. 資料庫系統中故障可以分為哪幾類
可以分為三類：
1.事務故障
2.系統故障
3.介質故障
D. 資料庫問題有哪些
資料庫並不是直接存儲文件的。 資料庫依照某種數據模型組織起來並存放二級存儲器中的數據集合。這種數據集合具有如下特點:盡可能不重復,以最優方式為某個特定組織的多種應用服務,其數據結構獨立於使用它的應用程序,對數據的增、刪、改和檢索由統一軟體進行管理和控制。
E. 哪些因素影響了資料庫性能
網路寬頻，磁碟IO，查詢速度都會影響到資料庫的性能。
具體問題具體分析，舉例來說明為什麼磁碟IO成瓶頸資料庫的性能急速下降了。
為什麼當磁碟IO成瓶頸之後, 資料庫的性能不是達到飽和的平衡狀態，而是急劇下降。為什麼資料庫的性能有非常明顯的分界點，原因是什麼？
相信大部分做資料庫運維的朋友，都遇到這種情況。 資料庫在前一天性能表現的相當穩定，資料庫的響應時間也很正常，但就在今天，在業務人員反饋業務流量沒有任何上升的情況下，資料庫的變得不穩定了，有時候一個最簡單的insert操作， 需要幾十秒，但99%的insert卻又可以在幾毫秒完成，這又是為什麼了？
dba此時心中有無限的疑惑，到底是什麼原因呢? 磁碟IO性能變差了？還是業務運維人員反饋的流量壓根就不對？ 還是資料庫內部出問題？昨天不是還好好的嗎？
當資料庫出現響應時間不穩定的時候，我們在操作系統上會看到磁碟的利用率會比較高，如果觀察仔細一點，還可以看到，存在一些讀的IO. 資料庫伺服器如果存在大量的寫IO,性能一般都是正常跟穩定的，但只要存在少量的讀IO,則性能開始出現抖動，存在大量的讀IO時（排除配備非常高速磁碟的機器），對於在線交易的資料庫系統來說，大概性能就雪崩了。為什麼操作系統上看到的磁碟讀IO跟寫IO所帶來的性能差距這么大呢？
如果親之前沒有注意到上述的現象，親對上述的結論也是懷疑。但請看下面的分解。
在寫這個文章之前，作者閱讀了大量跟的IO相關的代碼，如非同步IO線程的相關的，innodb_buffer池相關的，以及跟讀數據塊最相關的核心函數buf_page_get_gen函數以及其調用的相關子函數。為了將文章寫得通俗點，看起來不那麼累，因此不再一行一行的將代碼解析寫出來。
咱們先來提問題。buf_page_get_gen函數的作用是從Buffer bool裡面讀數據頁，可能存在以下幾種情況。
提問. 數據頁不在buffer bool 裡面該怎麼辦？
回答：去讀文件，將文件中的數據頁載入到buffer pool裡面。下面是函數buffer_read_page的函數，作用是將物理數據頁載入到buffer pool, 圖片中顯示
buffer_read_page函數棧的頂層是pread64(),調用了操作系統的讀函數。
通過解析buf_wait_for_read函數的下層函數，我們知道其實通過首先自旋加鎖pin的方式，超過設定的自旋次數之後，進入等待，等待IO完成被喚醒。這樣節省不停自旋pin時消耗的cpu,但需要付出被喚起時的開銷。
再繼續擴展問題： 如果會話線程A 經過物理IO將數據頁1001讀入buffer之後，他需要修改這個頁，而在會話線程A之後的其他的同樣需要訪問數據頁1001的會話線程，即使在數據頁1001被入讀buffer pool之後，將仍然處於等待中。因為在數據頁上讀取或者更新的時候，同樣需要上鎖，這樣才能保證數據頁並發讀取/更新的一致性。
由此可見，當一個高並發的系統，出現了熱點數據頁需要從磁碟上載入到buffer pool中時，造成的延遲，是難以想像的。因此排在等待熱點頁隊列最後的會話線程最後才得到需要的頁，響應時間也就越長，這就是造成了一個簡單的sql需要執行幾十秒的原因。
再回頭來看上面的問題，mysql資料庫出現性能下降時，可以看到操作系統有讀IO。 原因是，在資料庫對數據頁的更改，是在內存中的，然後通過檢查點線程進行非同步寫盤，這個非同步的寫操作是不堵塞執行sql的會話線程的。所以，即使看到操作系統上有大量的寫IO，資料庫的性能也是很平穩的。但當用戶線程需要查找的數據頁不在buffer pool中時，則會從磁碟上讀取，在一個熱點數據頁不是非常多的情況下，我們設置足夠大的innodb_buffer_pool的size, 基本可以緩存所有的數據頁，因此一般都不會出現缺頁的情況，也就是在操作系統上基本看不到讀的IO。 當出現讀的IO時，原因時在執行buf_read_page_low函數，從磁碟上讀取數據頁到buffer pool, 則資料庫的性能則開始下降，當出現大量的讀IO，資料庫的性能會非常差。
F. 資料庫系統中的常見故障有哪些
新增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. 用適當的方法對原資料庫進行資料庫全備份。
G. ORACLE資料庫常見問題匯總
提交事務的時候提示(資料庫被一個用戶鎖住的解決方法)
select
object_id,session_id,locked_mode
from
v$locked_object;
select
t2.username,t2.sid,t2.serial#,t2.logon_time
from
v$locked_object
t1,v$session
t2
where
t1.session_id=t2.sid
order
by
t2.logon_time;
alter
system
kill
session
'sid,serial#';
alter
system
kill
session
'7,10839'
H. 資料庫安全的安全問題
據Verizon2012年的數據泄露調查分析報告 和對發生的信息安全事件技術分析，總結出信息泄露呈現兩個趨勢：
（1）黑客通過B/S應用，以Web伺服器為跳板，竊取資料庫中數據；傳統解決方案對應用訪問和資料庫訪問協議沒有任何控制能力，比如:SQL注入就是一個典型的資料庫黑客攻擊手段。
（2）數據泄露常常發生在內部，大量的運維人員直接接觸敏感數據，傳統以防外為主的網路安全解決方案失去了用武之地。
資料庫在這些泄露事件成為了主角，這與我們在傳統的安全建設中忽略了資料庫安全問題有關，在傳統的信息安全防護體系中資料庫處於被保護的核心位置，不易被外部黑客攻擊，同時資料庫自身已經具備強大安全措施，表面上看足夠安全，但這種傳統安全防禦的思路，存在致命的缺陷。
I. 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 帶有修復數據表的功能，進入到某一個表中後，點擊「操作」，在下方的「表維護」中點擊「修復表」即可。
注意：以上兩種修復方式在執行前一定要備份資料庫。
J. 企業資料庫一般存在哪些安全問題
在企業的經營發展過程當中，資料庫安全問題始終是一個重大問題。如果企業想要順利發展，對這方面的問題進行防範和控制是非常有必要的。在實際的工作中，想要防範和控制問題，就必須先對這部分的內容有所了解，那麼，企業資料庫一般存在哪些安全問題呢?今天小編就為大家做個詳細介紹。
企業資料庫安全問題很多，具體有不良的口令政策、SQL注入等，這些問題中，有來自企業員工本身的操作失誤，也有資料庫自帶的一些安全隱患。比如說口令政策，這就是由於人員的偷懶。很多企業的管理人員在工作過程中的疏忽大意，使得企業員工還在選擇一些被淘汰的加密方式，這種工作方式很容易就會導致企業資料庫被入侵，另外，有的企業雖然資料庫加密系統已經非常完善了，但是操作者為了省事，讓系統自動記錄密碼，或者直接將一些密鑰等加密工具長時間插在電腦主機上，也會為企業數據安全埋藏隱患。
如果說不良的口令政策是員工工作上的問題，那麼SQL注入就是資料庫層面的問題了。資料庫本身的安全性不是非常高，因此如果資料庫接受了用戶提供的不幹凈的，或者沒有經過驗證的數據所產生的SQL注入，就會為SQL注入攻擊敞開大門。比如說，通過修改從基於網路的格式收到的信息，攻擊者能夠提供惡意的SQL請求並且直接把指令發送到資料庫中。
這上邊就是企業在日常工作過程當中常見的一些資料庫安全問題介紹了，那麼，對於這部分的問題，我們還是應該具體問題具體分析，比如說對於不良的口令政策，企業一方面應該加強自己企業內部的一些密鑰管理。一方面可以提供一些較為安全的登錄方式。另外一方面，還應該在平時的工作過程中對員工進行定期的培訓，提高他們的安全意識。
而對於資料庫安全問題中的SQL注入，最好的辦法還是在企業中購買一款高質量的安全防護軟體。在這里，小編為大家推薦的是上訊信息的WEB安全網關(WAF)，這款產品的專業性強，安全度高，能夠有效減少企業資料庫受到SQL注入攻擊的可能性，如果大家想要購買一款高質量的安全防護軟體，選擇上訊信息的WEB安全網關(WAF)准沒錯的。