【DataGuard】OracleDataguard三種保護(hù)模式特點(diǎn)總結(jié)
Oracle Dataguard提供了三種數(shù)據(jù)保護(hù)模式，在此分別總結(jié)一下三種數(shù)據(jù)保護(hù)模式的特點(diǎn)。
1.最大保護(hù)模式
1）這種模式提供了最高級別的數(shù)據(jù)保護(hù)能力；
2）要求至少一個物理備庫收到重做日志后，主庫的事務(wù)才能夠提交；
3）主庫找不到合適的備庫寫入時，主庫會自動關(guān)閉，防止未受保護(hù)的數(shù)據(jù)出現(xiàn)；
4）優(yōu)點(diǎn)：該模式可以保證備庫沒有數(shù)據(jù)丟失；
5）缺點(diǎn)：主庫的自動關(guān)閉會影響到主庫的可用性，同時需要備庫恢復(fù)后才能提交，對網(wǎng)絡(luò)等客觀條件要求非常的高，主庫的性能會因此受到非常大的沖擊。
2.最大可用性模式
1）該模式提供了僅次于“最大保護(hù)模式”的數(shù)據(jù)保護(hù)能力；
2）要求至少一個物理備庫收到重做日志后，主庫的事務(wù)才能夠提交；
3）主庫找不到合適的備庫寫入時，主庫不會關(guān)閉，而是臨時降低到“最大性能模式”模式，直到問題得到處理；
4）優(yōu)點(diǎn)：該模式可以在沒有問題出現(xiàn)的情況下，保證備庫沒有數(shù)據(jù)丟失，是一種折中的方法；
5）缺點(diǎn)：在正常運(yùn)行的過程中缺點(diǎn)是主庫的性能受到諸多因素的影響。
3.最大性能模式
1）該模式是默認(rèn)模式，可以保證主數(shù)據(jù)庫的最高可用性；
2）保證主庫運(yùn)行過程中不受備庫的影響，主庫事務(wù)正常提交，不因備庫的任何問題影響到主庫的運(yùn)行；
4）優(yōu)點(diǎn)：避免了備庫對主數(shù)據(jù)庫的性能和可用性影響；
5）缺點(diǎn)：如果與主庫提交的事務(wù)相關(guān)的恢復(fù)數(shù)據(jù)沒有發(fā)送到備庫，這些事務(wù)數(shù)據(jù)將被丟失，不能保證數(shù)據(jù)無損失；
4.oracle官方文檔中關(guān)于以上三種模式的描述
http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/log_transport.htm#sthref553
內(nèi)容引用在此，供參考。
5.6.1.1 Maximum Protection Mode
This protection mode ensures that no data loss will occur if the primary database fails. To provide this level of protection, the redo data needed to recover each transaction must be written to both the local online redo log and to the standby redo log on at least one standby database before the transaction commits. To ensure data loss cannot occur, the primary database shuts down if a fault prevents it from writing its redo stream to at least one remote standby redo log. For multiple-instance RAC databases, Data Guard shuts down the primary database if it is unable to write the redo records to at least one properly configured database instance. The maximum protection mode requires that at least one standby instance has a standby redo log and the LGWR, SYNC, and AFFIRM attributes be used on the LOG_ARCHIVE_DEST_n parameter for this destination.
5.6.1.2 Maximum Availability Mode
This protection mode provides the highest level of data protection that is possible without compromising the availability of the primary database. Like maximum protection mode, a transaction will not commit until the redo needed to recover that transaction is written to the local online redo log and to at least one remote standby redo log. Unlike maximum protection mode, the primary database does not shut down if a fault prevents it from writing its redo stream to a remote standby redo log. Instead, the primary database operates in maximum performance mode until the fault is corrected and all gaps in redo log files are resolved. When all gaps are resolved, the primary database automatically resumes operating in maximum availability mode.
This mode ensures that no data loss will occur if the primary database fails, but only if a second fault does not prevent a complete set of redo data from being sent from the primary database to at least one standby database.
Like maximum protection mode, the maximum availability mode requires that you:
* Configure standby redo log files on at least one standby database.
* Set the SYNC, LGWR, and AFFIRM attributes of the LOG_ARCHIVE_DEST_n parameter for at least 1 standby database.
5.6.1.3 Maximum Performance Mode
This protection mode (the default) provides the highest level of data protection that is possible without affecting the performance of the primary database. This is accomplished by allowing a transaction to commit as soon as the redo data needed to recover that transaction is written to the local online redo log. The primary database's redo data stream is also written to at least one standby database, but that redo stream is written asynchronously with respect to the commitment of the transactions that create the redo data.
When network links with sufficient bandwidth are used, this mode provides a level of data protection that approaches that of maximum availability mode with minimal impact on primary database performance.
The maximum performance mode enables you to either set the LGWR and ASYNC attributes, or set the ARCH attribute on the LOG_ARCHIVE_DEST_n parameter for the standby database destination. If the primary database fails, you can reduce the amount of data that is not received on the standby destination by setting the LGWR and ASYNC attributes.
5.小結(jié)
在部署Oracle Dataguard時，需要充分考慮三種保護(hù)模式下對數(shù)據(jù)和性能的影響，以便趨利避害。具體環(huán)境具體分析，每一種數(shù)據(jù)保護(hù)模式都有其應(yīng)用場合。默認(rèn)的最大性能模式較常見，運(yùn)行在該模式下的系統(tǒng)需要時刻注意備庫是否有日志丟失，通常可以考慮“一主帶多備”（一套主庫對應(yīng)多個備庫）的方法來保證日志的完整性。
Good luck.
secooler
10.10.12
-- The End --
1.最大保護(hù)模式
1）這種模式提供了最高級別的數(shù)據(jù)保護(hù)能力；
2）要求至少一個物理備庫收到重做日志后，主庫的事務(wù)才能夠提交；
3）主庫找不到合適的備庫寫入時，主庫會自動關(guān)閉，防止未受保護(hù)的數(shù)據(jù)出現(xiàn)；
4）優(yōu)點(diǎn)：該模式可以保證備庫沒有數(shù)據(jù)丟失；
5）缺點(diǎn)：主庫的自動關(guān)閉會影響到主庫的可用性，同時需要備庫恢復(fù)后才能提交，對網(wǎng)絡(luò)等客觀條件要求非常的高，主庫的性能會因此受到非常大的沖擊。
2.最大可用性模式
1）該模式提供了僅次于“最大保護(hù)模式”的數(shù)據(jù)保護(hù)能力；
2）要求至少一個物理備庫收到重做日志后，主庫的事務(wù)才能夠提交；
3）主庫找不到合適的備庫寫入時，主庫不會關(guān)閉，而是臨時降低到“最大性能模式”模式，直到問題得到處理；
4）優(yōu)點(diǎn)：該模式可以在沒有問題出現(xiàn)的情況下，保證備庫沒有數(shù)據(jù)丟失，是一種折中的方法；
5）缺點(diǎn)：在正常運(yùn)行的過程中缺點(diǎn)是主庫的性能受到諸多因素的影響。
3.最大性能模式
1）該模式是默認(rèn)模式，可以保證主數(shù)據(jù)庫的最高可用性；
2）保證主庫運(yùn)行過程中不受備庫的影響，主庫事務(wù)正常提交，不因備庫的任何問題影響到主庫的運(yùn)行；
4）優(yōu)點(diǎn)：避免了備庫對主數(shù)據(jù)庫的性能和可用性影響；
5）缺點(diǎn)：如果與主庫提交的事務(wù)相關(guān)的恢復(fù)數(shù)據(jù)沒有發(fā)送到備庫，這些事務(wù)數(shù)據(jù)將被丟失，不能保證數(shù)據(jù)無損失；
4.oracle官方文檔中關(guān)于以上三種模式的描述
http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/log_transport.htm#sthref553
內(nèi)容引用在此，供參考。
5.6.1.1 Maximum Protection Mode
This protection mode ensures that no data loss will occur if the primary database fails. To provide this level of protection, the redo data needed to recover each transaction must be written to both the local online redo log and to the standby redo log on at least one standby database before the transaction commits. To ensure data loss cannot occur, the primary database shuts down if a fault prevents it from writing its redo stream to at least one remote standby redo log. For multiple-instance RAC databases, Data Guard shuts down the primary database if it is unable to write the redo records to at least one properly configured database instance. The maximum protection mode requires that at least one standby instance has a standby redo log and the LGWR, SYNC, and AFFIRM attributes be used on the LOG_ARCHIVE_DEST_n parameter for this destination.
5.6.1.2 Maximum Availability Mode
This protection mode provides the highest level of data protection that is possible without compromising the availability of the primary database. Like maximum protection mode, a transaction will not commit until the redo needed to recover that transaction is written to the local online redo log and to at least one remote standby redo log. Unlike maximum protection mode, the primary database does not shut down if a fault prevents it from writing its redo stream to a remote standby redo log. Instead, the primary database operates in maximum performance mode until the fault is corrected and all gaps in redo log files are resolved. When all gaps are resolved, the primary database automatically resumes operating in maximum availability mode.
This mode ensures that no data loss will occur if the primary database fails, but only if a second fault does not prevent a complete set of redo data from being sent from the primary database to at least one standby database.
Like maximum protection mode, the maximum availability mode requires that you:
* Configure standby redo log files on at least one standby database.
* Set the SYNC, LGWR, and AFFIRM attributes of the LOG_ARCHIVE_DEST_n parameter for at least 1 standby database.
5.6.1.3 Maximum Performance Mode
This protection mode (the default) provides the highest level of data protection that is possible without affecting the performance of the primary database. This is accomplished by allowing a transaction to commit as soon as the redo data needed to recover that transaction is written to the local online redo log. The primary database's redo data stream is also written to at least one standby database, but that redo stream is written asynchronously with respect to the commitment of the transactions that create the redo data.
When network links with sufficient bandwidth are used, this mode provides a level of data protection that approaches that of maximum availability mode with minimal impact on primary database performance.
The maximum performance mode enables you to either set the LGWR and ASYNC attributes, or set the ARCH attribute on the LOG_ARCHIVE_DEST_n parameter for the standby database destination. If the primary database fails, you can reduce the amount of data that is not received on the standby destination by setting the LGWR and ASYNC attributes.
5.小結(jié)
在部署Oracle Dataguard時，需要充分考慮三種保護(hù)模式下對數(shù)據(jù)和性能的影響，以便趨利避害。具體環(huán)境具體分析，每一種數(shù)據(jù)保護(hù)模式都有其應(yīng)用場合。默認(rèn)的最大性能模式較常見，運(yùn)行在該模式下的系統(tǒng)需要時刻注意備庫是否有日志丟失，通常可以考慮“一主帶多備”（一套主庫對應(yīng)多個備庫）的方法來保證日志的完整性。
Good luck.
secooler
10.10.12
-- The End --
網(wǎng)站題目：【DataGuard】OracleDataguard三種保護(hù)模式特點(diǎn)總結(jié)
網(wǎng)頁網(wǎng)址：http://www.chinadenli.net/article8/jcoeop.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供商城網(wǎng)站、App開發(fā)、動態(tài)網(wǎng)站、外貿(mào)網(wǎng)站建設(shè)、網(wǎng)站內(nèi)鏈、云服務(wù)器
聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)
- 服務(wù)器環(huán)境配置 2022-05-25
- idc服務(wù)器托管價格有哪些影響因素？ 2022-10-05
- 什么是服務(wù)器托管?服務(wù)器托管有什么用 2022-10-07
- 網(wǎng)站服務(wù)器托管是什么意思？ 2022-10-04
- 什么是服務(wù)器托管？為何選擇服務(wù)器托管？ 2022-10-06
- 武漢服務(wù)器托管費(fèi)用要多少錢？武漢服務(wù)器托管時長有哪些？ 2022-10-05
- 云服務(wù)器租用與服務(wù)器托管相比有什么優(yōu)勢 2021-02-21
- 服務(wù)器之家淺談選擇服務(wù)器托管的三大優(yōu)勢 2022-10-03
- 服務(wù)器托管和服務(wù)器租用的相關(guān)介紹 2016-11-02
- 服務(wù)器托管時需做好數(shù)據(jù)備份 2022-10-03
- 服務(wù)器托管與虛擬主機(jī)的區(qū)別—深圳網(wǎng)站設(shè)計(jì) 2022-06-06
- 云服務(wù)器托管需要注意哪些問題？ 2022-10-09