① 資料庫運行過程中常見的故障有哪幾類試述對各類故障的恢復策略。
資料庫運行過程中常見的故障有3類：事物故障、系統故障、介質故障。
恢復策略：
1、事物故障：
發生事務故障時，被迫中斷的事務可能已對資料庫進行丁修改，為了消除該事務對資料庫的影響，要利用日誌文件中所記載的信息，強行回滾該事務，將資料庫恢復到修改前的初始狀態。
為此，要檢查日誌文件中由這些事務所引起的發生變化的記錄，取消這些沒有完成的事務所做的一切改變，這類恢復操作稱為事務撤銷。
2、系統故障：
系統故障的恢復要完成兩方面的工作，既要撤銷所有末完成的事務，還要重做所有已提交的事務，這樣才能將資料庫真正恢復到一致的狀態。
3、介質故障：
介質故障比事務故障和系統故障發生的可能性要小，但這是最嚴重的一種故障，破壞性很大，磁碟上的物理數據和日誌文件可能被破壞，這需要裝入發生介質故障前最新的後備資料庫副本，然後利用日誌文件重做該副本後所運行的所有事務。
(1)資料庫事務提交時宕機了怎麼解決擴展閱讀：
「數據故障恢復」和「完整性約束」、「並發控制」一樣，都是資料庫數據保護機制中的一種完整性控制。所有的系統都免不了會發生故障，有可能是硬體失靈，有可能是軟體系統崩潰，也有可能是其他外界的原因，比如斷電等等。
資料庫運行的突然中斷會使資料庫處在一個錯誤的狀態，而且故障排除後沒有辦法讓系統精確地從斷點繼續執行下去。這就要求DBMS要有一套故障後的數據恢復機構，保證資料庫能夠回復到一致的、正確地狀態去。
參考資料來源：網路-事務故障
參考資料來源：網路-系統故障
參考資料來源：網路-介質故障
② 伺服器宕機了，應該怎麼辦
造成伺服器宕機（死機）的原因是什麼呢？那麼他解決方法有哪些呢？壹基比來告訴你
引發伺服器宕機原因大概有：運行環境問題、伺服器性能問題、伺服器硬體問題、數據丟失或損壞問題。下面我們對以上幾個問題詳情描述並提供解決辦法：
一、運行環境問題導致伺服器宕機
伺服器運行環境包括操作系統，資料庫，應用程序，應用程序bug，網路數據等，以上軟體系統故障會引起伺服器宕機現象。解決辦法：需要我們查找分析系統、應用程序相關日誌來找出真正的原因。一般都能發現問題，根據日誌提供的錯誤信息修改相關設置來解決此類宕機故障，由於系統原因可以重裝系統，或重啟一下伺服器就可以了。
二、伺服器性能問題導致伺服器宕機
伺服器性能好壞也是引發宕機的一個因素，因為IDC提供商的伺服器有些不是品牌伺服器，是組裝型的伺服器，采購的硬體也不是品牌的，多用於雜牌硬體，難免會因硬體兼容性，CPU，內存等性能不好，導致宕機。解決辦法：查看伺服器硬體信息，在租用或選購時盡量用品牌伺服器，品牌伺服器在穩定性方面是沒得說的。
三、伺服器硬體問題導致伺服器宕機
如伺服器主板，電源，CPU，內存，磁碟有問題也會導致伺服器宕機故障，解決辦法：使用工具測試相關硬體配件，或更換配件測試伺服器硬體問題。
四、數據丟失或損壞問題導致伺服器宕機
數據丟失包括人為錯刪除數據，磁碟壞道導致數據丟失，磁碟寫滿等原因可導致伺服器系統崩潰宕機，解決辦法：做好數據備份，監控磁碟空間大小。
③ 伺服器宕機怎麼辦
解決方法：
對於伺服器頻繁出現宕機情況就要注意了檢查伺服器是否存在負載量過大，伺服器散熱存在問題等等情況。再針對這樣的情況一項一項來解決，這樣才能保證伺服器盡可能長時間正常運行。
對於一般伺服器宕機，我們可以採用重啟伺服器的方式來解決。正常重啟伺服器可以清除內存碎片，重新優化應用軟體，中斷無用的埠，緩解CPU壓力，加快伺服器運行速度等等。
對於伺服器租用用戶來說，伺服器宕機是非常值得重視的問題，如果租用的伺服器經常出現宕機情況的話，一定要及時通知服務商，讓伺服器查明具體情況，問題過於嚴重甚至可以要求跟換伺服器或者更換伺服器供應商。
④ 網站宕機 伺服器宕機 資料庫宕機 宕機怎麼辦
最近遇到個比較有意思的問題，伺服器宕掉後無法啟動，想了好多辦法，雖然解決了問題，數據沒有丟失，但是沒有按照自已的思路來，未免還是有些不甘。遇到問題不能慌，尤其是線上的環境，更不能緊張，心理素質對DBA來說也是一項挑戰，可能你的手一抖就會導致多少人無法正常使用業務，如果你沒有把握，請先把現場環境備份後再進行操作，避免數據的二次損壞，下面壹基比小喻說一下大概的思路吧。
1.檢查是否有備份，如果備份存在，binlog存在，那麼萬事大吉，一切都有挽回的餘地，慢慢來搞，只要你基礎扎實，數據還原只是時間的問題。
2.對於沒有備份的，那處理這個問題就有些棘手了，還得一步一步的來。
在my.cnf中[mysqld]下加上以下配置，採用強制恢復機制，看是否能夠啟動
[mysqld]
innodb_force_recovery=1
如果設置成1不能啟動，可以逐漸的將數據增大到6，下文會詳細說下1-6是什麼意思，如果在1-6之間啟動成功了，那麼你運氣還不錯，這時候不要恢復業務，趕緊把數據用邏輯方式導出來，再啟個新的實例把數據還原，有人會問，為什麼mysql已經啟動了，還要導出數據呢，原因在這：
當innodb_force_recovery被設置為大於0的時候 ，會阻止用戶insert,update,delete也就是你啟動的mysql不是一個正常的mysql服務，類似於windows系統下的安全模式。以下這段引於其它地方，具體地址不太清楚了，也可以從官方文檔中找到。
innodb_force_recovery被允許的非零值如下。一個更大的數字包含所有更小數字的預防措施。如果你能夠用一個多數是4的選項值來轉儲你的表，那麼你是比較安全的，只有一些在損壞的單獨頁面上的數據會丟失。一個為6的值更誇張，因為資料庫頁被留在一個陳舊的狀態，這個狀態反過來可以引發對B樹和其它資料庫結構的更多破壞。
innodb_force_recovery=1 (SRV_FORCE_IGNORE_CORRUPT)
即使伺服器檢測到一個損壞的頁，也讓伺服器運行著；試著讓SELECT * FROM tbl_name 跳過損壞的索引記錄和頁，這樣有助於轉儲表。
innodb_force_recovery=2 (SRV_FORCE_NO_BACKGROUND)
阻止主線程運行，如果崩潰可能在凈化操作過程中發生，這將阻止它。
innodb_force_recovery=3 (SRV_FORCE_NO_TRX_UNDO)
恢復後不運行事務回滾。
innodb_force_recovery=4 (SRV_FORCE_NO_IBUF_MERGE)
也阻止插入緩沖合並操作。如果你可能會導致一個崩潰。最好不要做這些操作，不要計算表統計表。
innodb_force_recovery=5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
啟動資料庫之時不查看未完成日誌：InnoDB把未完成的事務視為已提交的。
innodb_force_recovery=6 (SRV_FORCE_NO_LOG_REDO)
不要在恢復連接中做日誌前滾。
資料庫不能另外地帶著這些選項中被允許的選項來使用。作為一個安全措施，當innodb_force_recovery被設置為大於0的值時，InnoDB阻止用戶執行INSERT, UPDATE或DELETE操作.
即使強制恢復被使用，你也可以DROP或CREATE表。如果你知道一個給定的表正在導致回滾崩潰，你可以移除它。你也可以用這個來停止由失敗的大宗導入或失敗的ALTER TABLE導致的失控回滾。你可以殺掉mysqld進程，然後設置innodb_force_recovery為3，使得資料庫被掛起而不需要回滾，然後舍棄導致失控回滾的表。
關於上面進行邏輯備份也可能會遇到問題，可能會備份失敗，如果出錯，建議先按庫一個一個的備份，到哪個庫出錯後，再按照當前庫的表一個一個備份，表出錯根據表中主鍵一點一點備份，最終將大部分數據導出。如果你的數據不重要，可以容忍丟失，那麼可以當我說的都是廢話了。
3.如果還是不可以啟動，那麼恭喜你，你遇到挑戰了。
查看錯誤日誌，看沒有提示因為某個表的原因而導致啟動不了，可以先把損壞的表的ibd文件先從數據目錄mv走，再試著啟動，在數據已經恢復後，我把當時錯誤的文件拿到本地，做了測試，把幾個報錯的ibd文件mv走後，資料庫就可以正常啟動了，但是mv走的這幾個表數據會丟失。怎麼把這個表的數據弄回來呢，曾想過用在線表空間傳輸，但是.cfg文件卻沒有，這種方法沒有行通。後來用Percona Data Recovery Tool for InnoDB工具進行數據恢復，關於這個工具的介紹與操作，網上一大堆，我就不詳細說明了。
⑤ MySQL一主多從的環境下，如果主宕機了怎麼辦如何把損失降到最小
1、需要對MYSQL定時備份
2、應用中交換數據時，要判斷是否聯網，如果不聯網就把信息先保存在本地，等聯網後再
與MYSQL數據同步。
3、應用中注意使用事務
⑥ 資料庫宕機怎麼解決
a、是否是應用程序導致內存溢出或者泄露，out of memory導致
b、是否是進程過多或者不斷創建，耗盡資源導致
c、是否是資料庫程序死鎖，連接數過多導致
d、是否是應用程序異常導致
e、是否是流量負載過大導致
f、 是否是遭受黑客入侵攻擊導致
g、是否是誤操作導致
⑦ 如何有效防止數據中心系統宕機
當啟動Binlog後，事務會產生Binlog Event，這些Event被看做事務數據的一部分。因此要保證事務的Binlog Event和InnoDB引擎中的數據的一致性。所以帶Binlog的CrashSafe要求MySQL宕機重啟後能夠保證：
- 所有已經提交的事務的數據仍然存在。
- 所有沒有提交的事務的數據自動回滾。
- 所有已經提交了的事務的Binlog Event也仍然存在。
- 所有沒有提交事務沒有記錄Binlog Event。
這些要求很好理解，如果重啟後數據還在，但是Binlog Event沒有了，就沒辦法復制到其他節點上了。如果重啟後，數據沒了，但是Binlog Event還在，那麼不存在的數據就會被復制到其他節點上，從而導致主從的不一致。
為了保證帶Binlog的CrashSafe，MySQL內部使用的兩階段提交(Two Phase Commit)。
⑧ mysql資料庫宕機怎麼分析原因
可以手動將應用的資料庫配置修改為從機的配置（ip、port、資料庫名），然後重啟服務。
⑨ 我的oracle宕機了怎麼處理
1、案例現象
在root用戶下，su切換到一個普通用戶oracle下，卻發生了如下錯誤：
oracle資料庫意外宕機的分析處理案例
於是，嘗試直接通過oracle用戶登錄系統，發現此時的oracle用戶也無法登錄了，出現與上面同樣的錯誤。
2、解決思路
從上面錯誤提示可知是許可權出現了問題，那麼可以從許可權入手進行排查，基本思路如下：
用戶目錄/home/oracle許可權問題；
su程序執行許可權問題；
程序依賴的共享許可權問題；
selinux問題導致；
系統根空間問題。
3、排查問題
根據上面的思路，我們進行逐一檢查，考慮到su在切換到oracle用戶時會讀取oracle目錄下的環境變數配置文件，因此，首先檢查/home/oralce目錄的許可權是否存在問題，
[root@loaclhost home]# ls -al/home|grep oracle
drwx---- 4 oralce oinstall 4096 01-31 10:45 oracle
從輸出可知，/home/oracle目錄的屬主是oracle用戶，oracle用戶對這個目錄有「rwx」許可權，因此，oracle用戶目錄的許可權設置是正確的，可以排除掉這個問題了。
接著檢查su執行許可權問題：
[root@loaclhost home]# 11 /bin/su
-rwsr-xr-x 1 root root 24120 2007-11-30 /bin/su
可見su命令執行許可權也沒有問題，這個也排除了。
繼續檢查su依賴的共享庫許可權，使用ldd命令檢查su命令依賴的共享庫文件，如下圖
oracle資料庫意外宕機的分析處理案例
根據上面的操作，依次檢查su命令依賴的每個庫文件的許可權，發現也都是正常的，因此，共享庫的問題也排除了。
根據上面的思路，績效檢查SELinux的設置。
oracle資料庫意外宕機的分析處理案例
由輸出可知，SELinux處於關閉狀態，這個原因也排除了。
到這來為止，問題變得樸素迷離，到底是哪裡出現問題了呢？作為Linux運維，例行檢查系統根分區狀態是非常必要的，那麼首先檢查一個根分區的磁碟空間大小，發現剩餘空間還有很多，空間問題也排除了。既然報的錯誤是許可權有問題，那麼只要以許可權為線索，不偏離這個核心就沒錯，於是繼續嘗試檢查/home目錄下各個用戶的許可權，如下圖。
oracle資料庫意外宕機的分析處理案例
從輸出看每個用戶的目錄許可權，都是「rwx----」,即「700」，完全沒有問題，可是我發現我錯了，我的目光一直在用戶對應的目錄上，而忽略了其他輸出信息，而問題就藏在我沒有關注的信息中。在這個命令輸出的前兩行中，第一行許可權對應的目錄是「.」，代表當前目錄，也就是/home目錄，許可權為「rwxr-xr-x」，第二行許可權對應的目錄是「..」，也就是根目錄，許可權卻為「rw-rw-rw-」，即「666」，此時，問題終於查找到了，原來是根目錄許可權問題。
4、解決問題
知道了問題產生的原因，解決問題就非常簡單，執行如下命令：
[root@localhost~]#chmod 755 /
然後就可順利執行su切換命令。
經驗分享
這個問題主要是由於根目錄沒有執行許可權，而Linux下所有的操作都是在根目錄下進行的，進而導致/home/oralce目錄沒有執行許可權。其實根目錄許可權的丟失對於系統中運行的每個用戶存在同樣的影響。因此，在許可權出現問題時，一定要注意根目錄的許可權。