Oracle資料庫備份、災備的23個常見問題

為了最大限度保障資料的安全性，同時能在不可預計災難的情況下保證資料的快速恢復，需要根據資料的型別和重要程度制定相應的備份和恢復方案。在這個過程中，DBA的職責就是要保證資料庫（其它資料由其它崗位負責）的高可用和高效能，比如：如何避免資料庫發生常規錯誤、如何增加MTBF、如何降低MTTR、使用使用哪些冗餘技術保護關鍵元件以及如何做到最小化資料丟失。

在社群最近的線上交流中集中討論了Oracle資料庫備份恢復相關的問題，同時也擴充到了其它方面，比如效能問題、案例分析、RAC相關的備份問題及生產環境中的經驗分享。非常感謝愛好者的參與，特別是ttkanni、fengshuai等會員的積極參與，由主要分享者royalwzy對所涉及的問題進行了整理和歸類，提供給大家參考，包括如下幾個部分：

一、資料庫備份恢復基本問題

二、資料庫備份恢復效能相關問題

三、資料庫備份恢復效能案例分析

四、資料庫備份恢復效能最佳化問題

五、資料庫備份恢復RAC相關問題

六、資料庫備份恢復經驗分享

 

 

一、資料庫備份恢復基本問題

 

1、問：Oracle11g資料庫資料量有50T，每天增量50g左右，該如何制定備份方案，如何驗證備份的有效性？

答：

50T的資料也不大，運營商的地市級市資料基本都在100T以上了，只要備份環境允許的話，也能在12h內備份完成。

以一次全備份來算，在12h內備份完成，那麼平均備份速度最低是

5010241024/12/3600=1210MB/S

按照LTO 5 drive的速度（140MB/S）來算，備份最低的drive數量：1210/140=9

為了保障dive儘量保持最大IO，建議額外關注幾點：

1，datafile較小的話，聚合成較大的bakcup piece

2，調整read/write blocksize減少讀寫次數，可酌情調整至MB大小

3，調整備份指令碼，一個channel對應一個backup session，每個channel儘量保障只有一個大塊backup piece寫入

4，關閉備份軟體和drive的多路複用功能，保證每個dive上只有一個session寫入

5，備份儘量走單獨的HBA卡，不要和業務或儲存共用

備份策略的話，一個完整的備份週期肯定是FULL+INCR+INCR比較符合實際情況，如果條件允許Synthetic Full也是一個很不錯的選擇。歸檔看需求，4h或者6h備份頻率都可以。

相關案例：

某地市資料庫，大概資料量90T，備份從4塊獨立的16 GB HBA走，每塊HBA綁2個LTO 5物理drive，備份起8個channel，每個channel對應一個bakcup piece，每個bakcup piece都聚合為500 GB，R/W blocksize為2MB，多路複用關閉。

 

2、問：Oracle的資料庫備份，一般採用資料泵將庫和資料備份，這樣安全嗎？一般是各一個周備份一次。

答：

安全這個詞在這裡的定義比較模糊。

1.expdp/impdp是邏輯備份，備份的過程中也可以使用加密從而保證資料的安全。

2.也正是因為這種方式是邏輯備份，不論你才用多久的時間間隔來備份，兩次備份過程中有資料丟失都無法透過這種方式恢復到資料丟失的那一刻。
想要保證資料可以恢復到任意時刻建議使用rman；如果每隔一段時間想要儲存一下資料某時間點的快照的話，使用資料泵和rman都行。

3、問：如何設計oracle資料庫的備份與恢復的時間視窗？都需要做都那些方面的考慮？系統環境越來越複雜，需要備份的資料庫也越來越多。在做資料庫的備份與恢復設計時，應如何設計oracle資料庫的備份與恢復的時間視窗？都需要做都那些方面的考慮？

答：

先說備份，需要著重考慮幾點：

1，備份方式：根據實際資料保護需要，確定備份方式，一般都是FULL+INCR。條件允許就全FULL。其次就是備份頻率，一個FULL後追加多少個INCR，歸檔多久備份一次。

2，備份時間視窗：備份的過程中對生產業務（資料庫）壓力是很大的，所以首先應該規劃備份的時間視窗，一般都在晚上。

3，備份流量路徑：確定了備份時間視窗，就想想備份的流量怎麼走。LAN-FREE備份好說，LAN備份就要特別留意了，備份前先拉著網路的哥們交流下感情，最終確定好流量路徑，不要影響其他業務。

4，資料保留、克隆：對於重要的資料，不僅需要備份，最好克隆一份。出入庫看實際需求了。

恢復一般在單獨的恢復環境，所以沒什麼需要特別注意的。

4、問：RMAN備份和資料泵備份的比較，適用範圍？

答：

RMAN是oracle推薦的資料保護工具，在備份恢復上，RMAN能夠藉助備份資料恢復一段時間範圍內某個時間點資料庫的狀態。此外RMAN在備份恢復的校驗上更加嚴格，最大程度保護資料的完整性、一致性以及適用性，同時也方便備份恢復的統一管理。

EXP/EXPDB，在oracle的定位中，只是一個資料遷移的手段。在備份恢復上，資料泵只能利用備份資料來恢復一個時間點上的資料庫狀態，無法藉助備份資料在一段時間內自由選擇恢復點。在嚴格的意義說，資料泵備份並不能說是一種有效的資料保障措施，這更像是一種臨時的保底操作。

5、問：oracle資料庫備份及恢復那種方式更簡單！更快捷？exp/imp 還是rman或是其他方式？

答：

應該按照系統的RTO的要求上來看，邏輯匯出和RMAN配合使用，exp的方式因為要放到本地或者放到本地之後上傳到伺服器，這種比較佔用磁碟空間，但是在一些跨平臺恢復上exp又是可以的。rman主要還是防止邏輯錯誤，搭配備份軟體，進行資料的集中管理較多。

集中化備份管理來說，rman是最有效也是最可靠的方式。exp、expdb雖然操作簡單，對於資料的持續性保護太弱了~

6、問：ORACLE資料庫該如何設定防範邏輯錯誤的備份策略和備份方案？

答：

邏輯錯誤有很多中解決辦法，使用備份恢復是最有效的一種，但是大多時候並不是最優的一種方法。

如果要使用備份等話，那就建議保留所有的歸檔日誌，除了備份恢復，還可以使用Oracle資料庫的閃回功能，比如：閃回查詢，閃回表，閃回事務和閃回資料庫等操作。

7、問：很多時候Oracle備份或恢復都是由oracle結合第三方備份軟體完成，在備份恢復的過程當中時不時的會遇到備份恢復的速度比預想的要差很多，各位有哪些經驗？如何定位是oracle設定的問題還是備份軟體的方面的原因？

答：

效能排查無外乎源、路徑、目標這三點，第三方備份軟體可以看做在“路徑”上的管理員，排程資料從源到目標。

源端問題，儲存問題就從儲存讀直接寫到null看讀速度，寫就直接生產隨機資料寫儲存。

路徑問題，從源記憶體直接生產隨機大資料寫備份介質（drive一般不會有效能瓶頸）或者直接做rman的validate驗證恢復

目標端問題，drive一般只需檢查物理狀態。AFTD檔案型別裝置檢查其儲存效能問題，方法如上。

8、問：針對不同業務系統採用的資料庫備份策略是怎麼樣的？定期恢復驗證的週期為多久？

答：

備份方式無外乎FULL INCR Synthetic Full

備份環境極好，只用FULL備份，恢復速度最快。

備份環境稍好，FULL +INCR +Synthetic Full，恢復速度適中。

備份環境有限，FULL +INCR +INCR，恢復速度一般。

對於FULL+INCR（Synthetic Full）這種方式，INCR次數不建議太多（INCR較大的資料庫建議INCR次數不超過3），否則恢復速度會大打折扣。

現在廠商還宣傳一種特殊的備份方式：Virtual synthetic full backup

這種備份方式，利用傳統的FULL+INCR進行，Virtual synthetic full backup時在備份介質上將FULL +INCR整合成一個相當於實際的FULL對外提供恢復服務。

恢復驗證週期，一般一個季度內至少挑選各型別備份恢復一次。

恢復環境好，恢復驗證頻率可以為一個月一次，每次都真實恢復。

恢復環境稍好，適當降低恢復驗證頻率，挑選重要系統備份真實恢復，其餘做oracle validate恢復或者scan tape。

恢復環境一般，在連續的多個備份週期內至少能對一個完整週期的備份進行oracle validate恢復或者scan tape。

9、問：最近veritas的來做技術交流，據他說NBU的備份一體機在生產庫出問題的情況下，可以透過rename一系列操作將庫從備份一體機中拉起來直接用。有用過的嗎？

答：

在其他廠商的產品裡有VM_RECOVERY可以實現這樣一種恢復。直接從備份介質讀備份資料，在前端虛擬出一臺虛擬機器。

但在資料庫上，我記得還是要恢復的，廠商吹噓的直接拉起庫？只要你用RMAN rename就是有恢復，因為備份資料從備份軟體還原到RMAN識別、rename就是恢復的過程。

10、問：一個資料庫例項下面有十幾個使用者，如何實現分使用者備份各自的資料，不用一個一個exp?各使用者如何實現併發備份？

答：

Oracle Rman無法實現分使用者備份，但可以折中處理：備份使用者對應的所有表空間資料。

Oracle Rman是透過channel和複用來實現併發備份的，具體語法參考RMAN手冊。

11、問：在三地兩中心的雙活結構中，oracle的資料庫雙活如何進行安裝部署，在這種情況下還需要有資料庫備份的必要性呢？ODG和ADG在這種資料庫備份環境中該如何操作呢？

答：

資料庫雙活了更需要資料庫備份，否則資料庫邏輯錯誤，一損俱損，都沒得恢復了。。ORACLE備份不就是RMAN或者資料泵，備到儲存或磁帶，保持一份最新的資料，防治資料庫邏輯錯誤。

多活只能保障單邊故障下業務還可以online（高可用），但對於資料邏輯錯、歷史資料審查、歷史資料分析等問題，多中心多活的結構框架依舊無法克服。

的確，從另外一方面，資料庫雙活了，應用同樣需要雙活。切換時還需要考慮是直接切換到異地的機房，還是在原機房進行恢復。

12、問：Oracle 備份保留引數主要是兩個：一個是保留的天數，另一個是保留的副本數。那麼這兩種情況具體有什麼區別，在什麼場景下使用什麼樣的引數設定呢？

答：

前者主要考慮的方面是：想要把資料庫恢復到歷史的哪一個時間點；後者主要考慮的方面是：要針對備份如何做冗餘

Configure retention policy to recovery window of N days;

表示備份保留N天，即表示oracle可以保證還原到N天內的任意時間點。

CONFIGURE RETENTION POLICY TO REDUNDANCY n

表示備份保留N份。

區別就是基於恢復視窗的保留策略緯度不同，看你的具體需求 磁碟窨 備份策略 來選擇不同的引數設定

13、問：oracle資料庫的exp備份方式是否能否恢復儲存過程和觸發器？是否支援跨版本？RMAN方式呢？

答：

exp和expdp都能滿足你的需求 rman更能滿足。不過注意千萬不要在平時用exp來做容災備份 用rman來做 exp的定位還是資料遷移工具。

14、問：大家的Oracle備份環境中，是否建設有Catalog資料庫用於存放備份記錄啊？還是直接使用的控制檔案？

在備份和恢復中，Catalog的主要優勢在哪？哪些是必要因素說明必須要建設Catalog資料庫？

答：

1.rman的備份資訊預設是存放在目標資料庫的控制檔案中的,存放時間由control_file_record_keep_time引數控制,預設是7天;同時,也可以把rman的備份資訊儲存到一個獨立的資料庫中,叫做recovery catalog;

2.使用recovery catalog可以儲存更長時間的備份資訊,當目標資料庫的控制檔案丟失時非常有用;

3.recovery catalog可以儲存多個目標資料庫的備份資訊,可以儲存RMAN stored scripts(類似於儲存過程,就是一系列rman指令碼);另外如果想要試用永久保留備份的話,必須使用catalog;

4.如果只是簡單的備份管理需求的話,建議使用控制檔案即可,因為如果使用recovery catalog的話,意味著還要對其它的資料庫做備份管理,Licence費用;所以,只有在使用recovery catalog帶來的好處比較大時才使用。

 

 

二、資料庫備份恢復效能相關問題

 

15、問：Oracle 強大之處之一在於有很多表和檢視用於效能分析和故障診斷，哪些表可以用於備份恢復異常時的效能診斷，有無經驗分享？

答：

select s.status as "備份狀態",

b.INPUT_TYPE as "備份型別",

to_char(b.START_TIME,'yyyy-mm-dd hh24:mi:ss') as 總的開始時間,

to_char(b.end_time, 'yyyy-mm-dd hh24:mi:ss') as 總的結束時間,

trunc(b.ELAPSED_SECONDS/60,0) as 耗時多少分鐘,

b.INPUT_BYTES_PER_SEC_DISPLAY "in_sec/s",

b.OUTPUT_BYTES_PER_SEC_DISPLAY "out_sec/s",

trunc((s.END_TIME-s.START_TIME)2460,0) "單個檔案備份用時(分)",

to_char(s.START_TIME, 'yyyy-mm-dd hh24:mi:ss') as "開始備份時間",

to_char(s.END_TIME, 'yyyy-mm-dd hh24:mi:ss') as "結束備份時間",

s.OPERATION as "命令",

trunc(s.INPUT_BYTES/1024/1024,2) as "INPUT-M",

trunc(s.OUTPUT_BYTES/1024/1024,2) as "OUTPUT-M",

s.OBJECT_TYPE as "物件型別",

s.MBYTES_PROCESSED as "百分比",

s.OUTPUT_DEVICE_TYPE as "裝置型別"

from v$rman_status s,v$rman_backup_job_details b

where to_char(s.START_TIME, 'yyyy-mm-dd hh24:mi:ss') < to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') 

and to_char(s.END_TIME, 'yyyy-mm-dd hh24:mi:ss') > to_char(sysdate-7,'yyyy-mm-dd hh24:mi:ss')

and s.COMMAND_ID=b.COMMAND_ID

order by s.START_TIME desc ;

select s.status as 備份狀態,

trunc((s.END_TIME-s.START_TIME)2460,0) "備份用時(分鐘)",

to_char(s.START_TIME, 'yyyy-mm-dd hh24:mi:ss') as 開始備份時間,

to_char(s.END_TIME, 'yyyy-mm-dd hh24:mi:ss') as 結束備份時間,

s.OPERATION as 命令,

trunc(s.INPUT_BYTES/1024/1024,2) as "INPUT/M",

trunc(s.OUTPUT_BYTES/1024/1024,2) as "OUTPUT/M",

s.OBJECT_TYPE as "物件型別",

s.MBYTES_PROCESSED as 百分比,

s.OUTPUT_DEVICE_TYPE as "裝置型別"

from v$rman_status s

where to_char(s.START_TIME, 'yyyy-mm-dd hh24:mi:ss') < to_char(sysdate,'yyyy-mm-dd hh24:mi:ss')

and to_char(s.END_TIME, 'yyyy-mm-dd hh24:mi:ss') > to_char(sysdate-7,'yyyy-mm-dd hh24:mi:ss')

order by s.START_TIME desc ;

16、問：請問各位在生產環境中遇到哪些備份恢復的問題？

答：

源庫和恢復的目標庫 資料庫編碼格式不一樣，導致一直提示找不到bakcup piece。

備份時遇到壞塊

備份時檔案被誤刪除

17、問：資料庫從9版本遷移到12c 資料表結構都變了，怎麼遷移資料呢？

答：

可以使用kettel等etl工具來幫忙，當然你也可以先升10再升11再升12 一步一步的升上去；同是oracle資料匯出再匯入也簡單。

 

 

三、資料庫備份恢復效能案例分析

 

18、問：oracle用rman做recover和用sqlplus做recover有什麼區別？

我曾經遇到過這樣一個問題，生產的儲存卡壞了（生產是2個節點的ＲＡＣ），需要在另一臺伺服器恢復資料庫（非ＲＡＣ），幸好我把歸檔日誌儲存了一份在本地磁碟。在還原旱，用 rman 做 restore 正常完成，但在做 recover 的時候，報錯了（具體的錯誤號我忘了，但大概意思是找不到所需要的歸檔日誌，但在新的伺服器上的歸檔路徑下有這歸檔日誌檔案），整了半天，就是不得行，後來，我用　sqlplus recover 成功了，命令如下：
sql> recover database using backup controlfile until cancel;

為什麼為這樣，我至今沒有搞明白，請高手們分析一下。

答：

如果你的oracle rman恢復是沒有catalog，且在rman中的恢復僅僅是“recover database”的話，會出現你說的這個問題。

要想明白問題的原因，還得從這兩句恢復命令出發：

recover database using backup controlfile until cancel;

在單一的recover database 或者 recover tablespace, recover datafile時，Oracle會以當前controlfile所記錄的SCN為準，利用archive log和 redo log的redo entry, 把相關的datafile 的 block恢復到“當前controlfile所紀錄的SCN”
而當前controlfile和current/active redo都丟失的情況下，你就需要使用你在SQLPLUS裡輸入的那句恢復命令，在很多情況下，由於datafile資料的不一致性，Oracle需要把資料恢復到比當前controlfile所紀錄的SCN還要靠後的位置，簡單的說，就是需要更多的歸檔。

如果你還能復現這個恢復場景，你查詢下你報錯的所需的歸檔，利用原來的controlfile進rman裡list backup看一下就能知道了。

 

 

四、資料庫備份恢復效能最佳化問題

 

19、問：隨著資料庫體量的增大，有時每天全備已經不能滿足需要了，考慮使用增量備份。各位專家有沒有遇到過實施增量備份過程中的問題呢？還有就是對於OLTP系統，每天大量資料塊是被更新了的，這樣的話block change tracking即使開啟了，也很難提高備份速度（因為大部分塊都被修改過，仍然需要備份），這類問題同行朋友有沒有比較好的建議？

答：

首先確認一下資料庫大小有多大，使用的lan備份還是光纖，使用的幾個通道，平均一個通道io有多大？如果使用的lan 是否網路卡已經飽和等等？
如果你的狀況是每天變化的資料能影響到幾乎所有的資料塊的話，那麼考慮使用backup as copy。

 

 

五、資料庫備份恢復RAC相關問題

 

20、問：Oracle 10gr2 RAC因為需要更換儲存，資料庫遷移有什麼特別的方案嗎？系統Oracle Linux 5.7，DB：10.2.0.5。

答：

具體看停機視窗時間跟資料量，可以採用集中方式：1）匯入匯出；2）備份恢復；3）使用新的儲存做一個DG的備機，然後切換過去。

21、問：現有資料庫為oracle rac，想搭建一套完全實時互備的資料庫，能做DataGuard嗎？如果可以那麼scanip 和VIP、sid和原庫能保持一致嗎？如不行那麼有什麼能實現以上功能？

答：

完全可以在現有環境下搭建adg。

scanip，VIP，sid都不能一致，但是資料庫唯一名必須一致，這是adg的配置條件。

22、問：一個oracle資料庫的RAC環境，在日常運維管理中應重點關注那些方面的具體內容？

在對oracle資料庫進行日常運維管理中，我們都應該重點關注那些方面的具體內容？

我們目前能夠關注的，如：ORA-告警資訊，一些表空間的的告警。這個也是主要從監控系統（如TIVOLI監控系統）中獲得，除此之外，我們還應該重點關注那些具體方面的內容?

答：

除了監控，也需要關注RAC環境的效能調優，Service的管理，負載均衡等方面吧

23、問：如果Orace資料庫的RAC在建設的時候，歸檔沒有放在共享或者ASM上，只是在單邊存放，那麼這種的Oracle資料庫備份大家一般都怎麼做？兩邊都備份？還是mount NFS？哪種更好些？

答：

歸檔還是建議放在共享儲存上，不太建議單邊存放。一是方便管理，二是簡化備份流程。

若是單邊存放，只能在每個節點上單獨備份各自的歸檔。

對於歸檔資料量較大的場景，不太建議NFS。如果允許，能共享盡量共享

 

 

六、資料庫備份恢復經驗分享

 

（一）、Oracle 備份和恢復的一點體會

架構

Oracle的備份一般來說還是基於第三方備份軟體來完成日常備份的，諸如NBU，TSM等

那麼在設計架構方面應該多考慮一下是集中的方式來做還是分開來做，主要考慮有幾點：

1.公司需要備份的節點數量和位置

2.目前公司網路情況（是否有分支機構走專線備份，備份網段和生產網段的連通性等，是否有專用備份網路）

3.是否使用catalog

4.備份裝置是否分層或異地同步

5.是否有出庫異地存放需求。

資料量

1.資料量小，基本上可以考慮使用lan方式配合備份視窗來完成

2.資料量大，考慮配合高速乙太網和lanfree方式完成，備份方式（全備+曾備+歸檔備份完成）

配置

1.選用較高配置X86 伺服器+linux 完成備份環境搭建

2.備份server和節點session和資源限制不要使用預設，看情況修改

3.Oracle 備份片和通道要做適當設定

4.專有備份lan或光纖卡

效能定位

1.本地io

2.網路io

3.備份軟體相容性，已經版本bug

4.備份軟體trace跟蹤

5.oracle備份引數設定：備份片和備份方式，是否壓縮，塊跟蹤等

（二）、結合實際做備份恢復設計才能最大限度的滿意要求

備份恢復的方法和種類很多，為啥有的時候客戶還不滿意？因為你不對他路子。

舉個例子，開發人員不小心刪錯了資料。你說有flash back呀一看undo retention不夠。

那開始備份恢復吧，結果system或者user表空間巨大，哇資料全在system裡面是不是原來設計好的想法都沒用啦?

如果可以依照先有的資料庫結構做些適當的引導那麼會好很多。

且國內客戶和國外客戶處理的方式太不一樣。特別是韓國和日本客戶。針對細節問題到了無以復加的地步，那麼這個時候備份和恢復設計就不能有自己解釋不通的地方。

說了那麼多具體談下怎麼做事吧。

最重要的一點，備份的東西可以吐出來。

那麼要給自己留後路，備份的東西要異與恢復。

那麼如果錢足，上硬體級別備份。例如emc timefinder，SRDF等等。條件好的可以做個備份的colne。

一定要建議購買專業的備份恢復軟體，關鍵時刻可以用來頂包。

那麼最好做物理備份，用於防止物理的損壞。

如果既要防止物理損壞又要很快的把人為的錯誤資料找回來就可以設定一個standby那麼防止物理損壞的備份直接在原庫備份，用於防止人為損壞的備份在standby節點備份，延時個一天吧。應該可以滿足要求。

以上是大致的經驗，我的意思是備份手段多種多樣，怎麼搞成最適合的場景可是個大學問。

（三）、Oracle 11.2.0.3版本以上的RAC資料庫備份時，偶爾出現ORA-00245的報錯。

問題現象：ORA-00245: control file backup failed; target is likely on a local file system

解決辦法：

1. Check the snapshot controlfile location:
RMAN> show snapshot controlfile name;

2. Configure the snapshot controlfile to a shared disk:

RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/snapcf_.f';
Or in case of ASM use

RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+/snapcf_.f';

---

---

About Me

........................................................................................................................ ● 本文作者：小麥苗，部分內容整理自網路，若有侵權請聯絡小麥苗刪除 ● 本文在itpub、部落格園、CSDN和個人微 信公眾號（ xiaomaimiaolhr ）上有同步更新 ● 本文itpub地址： http://blog.itpub.net/26736162 ● 本文部落格園地址： http://www.cnblogs.com/lhrbest ● 本文CSDN地址： https://blog.csdn.net/lihuarongaini ● 本文pdf版、個人簡介及小麥苗雲盤地址： http://blog.itpub.net/26736162/viewspace-1624453/ ● 資料庫筆試面試題庫及解答： http://blog.itpub.net/26736162/viewspace-2134706/ ● DBA寶典今日頭條號地址： ........................................................................................................................ ● QQ群號： 230161599 （滿） 、618766405 ● 微 信群：可加我微 信，我拉大家進群，非誠勿擾 ● 聯絡我請加QQ好友 （ 646634621 ） ，註明新增緣由 ● 於 2019-07-01 06:00 ~ 2019-07-31 24:00 在西安完成 ● 最新修改時間：2019-07-01 06:00 ~ 2019-07-31 24:00 ● 文章內容來源於小麥苗的學習筆記，部分整理自網路，若有侵權或不當之處還請諒解 ● 版權所有，歡迎分享本文，轉載請保留出處 ........................................................................................................................ ● 小麥苗的微店 ： ● 小麥苗出版的資料庫類叢書 ： http://blog.itpub.net/26736162/viewspace-2142121/ ● 小麥苗OCP、OCM、高可用網路班 ： http://blog.itpub.net/26736162/viewspace-2148098/ ● 小麥苗騰訊課堂主頁 ： https://lhr.ke.qq.com/ ........................................................................................................................ 使用 微 信客戶端 掃描下面的二維碼來關注小麥苗的微 信公眾號（ xiaomaimiaolhr ）及QQ群（DBA寶典）、新增小麥苗微 信， 學習最實用的資料庫技術。 ........................................................................................................................