數(shù)據(jù)庫Standby中的幾個(gè)概念分別是什么

本篇文章為大家展示了數(shù)據(jù)庫Standby中的幾個(gè)概念分別是什么，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細(xì)介紹希望你能有所收獲。

一 . 雙機(jī)熱備

　 從廣義上講，雙機(jī)熱備（雙機(jī)容錯(cuò)）就是對于重要的服務(wù)，使用兩臺(tái)服務(wù)器，互相備份，共同執(zhí)行同一服務(wù)。當(dāng)一臺(tái)服務(wù)器出現(xiàn)故障時(shí)，可以由另一臺(tái)服務(wù)器承擔(dān)服務(wù)任務(wù)，從而在不需要人工干預(yù)的情況下，自動(dòng)保證系統(tǒng)能持續(xù)提供服務(wù)　 雙機(jī)熱備由備用的服務(wù)器解決了在主服務(wù)器故障時(shí)服務(wù)不中斷的問題。但在實(shí)際應(yīng)用中，可能會(huì)出現(xiàn)多臺(tái)服務(wù)器的情況，即服務(wù)器集群　 雙機(jī)熱備一般情況下需要有共享的存儲(chǔ)設(shè)備。但某些情況下也可以使用兩臺(tái)獨(dú)立的服務(wù)器　 實(shí)現(xiàn)雙機(jī)熱備，需要通過專業(yè)的集群軟件或雙機(jī)軟件

　 從狹義上講，雙機(jī)熱備特指基于active/standby方式的服務(wù)器熱備。服務(wù)器數(shù)據(jù)包括數(shù)據(jù)庫數(shù)據(jù)同時(shí)往兩臺(tái)或多臺(tái)服務(wù)器寫，或者使用一個(gè)共享的存儲(chǔ)設(shè)備。在同一時(shí)間內(nèi)只有一臺(tái)服務(wù)器運(yùn)行。當(dāng)其中運(yùn)行著的一臺(tái)服務(wù)器出現(xiàn)故障無法啟動(dòng)時(shí)，另一臺(tái)備份服務(wù)器會(huì)通過雙機(jī)軟件的診測（一般是通過心跳診斷）將standby機(jī)器激活，保證應(yīng)用在短時(shí)間內(nèi)完全恢復(fù)正常使用 .

所以，像VCS (VERITAS Cluster Manager)等軟件實(shí)現(xiàn)的Oracle Cluster Server 以及Oracle Standby ,Oracle RAC(Real Application Cluster),高級(jí)復(fù)制(Advanced Replication), Streams 等技術(shù)都能認(rèn)為是雙機(jī)熱備。

二． Physical Standby ，Logical Standby (物理Standby及邏輯Standby)

Physical standby直接從主庫接受archived log，然后直接做基于block的物理恢復(fù)（更新或調(diào)整變化的block），所以physical standby在物理文件一級(jí)完全都等同于主庫。 physical standby 恢復(fù)只是底層的block apply, OS層面的工作, 數(shù)據(jù)庫SCHEMA，包括索引都是一樣的。它是直接應(yīng)用REDO或歸檔實(shí)現(xiàn)同步的 。不會(huì)涉及temp ,undo 等。 物理STANDBY可能的模式：只讀模式（OPEN READONLY）和恢復(fù)模式（MANANGED RECOVERY）。

在邏輯STANDBY中，邏輯信息是相同的，但物理組織和數(shù)據(jù)結(jié)構(gòu)可以不同，它和主庫保持同步的方法是將接收的REDO轉(zhuǎn)換成SQL語句，然后在STANDBY上執(zhí)行SQL語句（SQL Apply）。邏輯STANDBY除災(zāi)難恢復(fù)外還有其它用途，比如用于用戶進(jìn)行查詢和報(bào)表。

在9i R2之前，data guard的服務(wù)器只能運(yùn)行在read only或者recover 模式， 一個(gè)physical standby database 在物理上完全等同主庫，當(dāng)physical standby database正在做恢復(fù)的時(shí)候，不能打開用作其他用途。 而logical standby database只是在logical上等同需要恢復(fù)的schema， 所以在恢復(fù)的時(shí)候，可以同時(shí)打開做report(做查詢動(dòng)作)，也可以用戶和主庫不一樣的 數(shù)據(jù)對象等等，極大了提高了備用庫的利用率。

三． Dataguard

都是Standby 。 在Oracle 9i之前稱為Standby，9i或之后的Standby被改名為Data guard 。不過功能上也有了很多的改進(jìn)和區(qū)別 。

四． Standby下LGWR / ARCH 傳輸

查看數(shù)據(jù)庫保護(hù)模式：

SQL> select DATABASE_ROLE,PROTECTION_MODE,PROTECTION_LEVEL from v$database;

1. 最大性能(maximize performance): 這是data guard默認(rèn)的保護(hù)模式。primay上的事務(wù)commit前不需要從standby上收到反饋信息（主數(shù)據(jù)庫的提交操作不等待STANDBY），該模式在primary故障時(shí)可能丟失數(shù)據(jù)，但standby對primary的性能影響最小。 可以使用LGWR ASYNC 或者ARCH 兩種傳輸模式。

ARCH 傳輸模式： Primary DB上的online redo log 寫滿或其他條件引起redo log寫歸檔的時(shí)候，redo log 生成的archived log file寫到本地歸檔目錄的同時(shí)，寫入了Standby歸檔目錄。只是Primary db上的online redo log 切換不必等Standby上的寫歸檔動(dòng)作結(jié)束。

2. 最大可用(maximize availability): 在正常情況下，最大可用模式和最大保護(hù)模式一樣；在standby不可用時(shí)，最大可用模式會(huì)自動(dòng)降低成最大性能模式，所以standby故障不會(huì)導(dǎo)致primay不可用。在問題糾正之后，Standby和主數(shù)據(jù)庫進(jìn)行再同步，至少有一個(gè)standby可用的情況下，即使primary down機(jī)，也能保證不丟失數(shù)據(jù)。(不過當(dāng)問題修復(fù)，再同步之前有必要FAILOVER,那么有些數(shù)據(jù)可能會(huì)丟失)。最大可用性模式Standby必須配置Standby Redo log ， Oracle推薦最大可用模式使用LGWR ASYNC （異步）模式傳輸。

采用最大可用的data guard 模式，主庫往備庫傳遞在線日志(online redo log)信息，在線日志信息寫入備用庫的standby redo log,這些standby redo log歸檔后，備用庫應(yīng)用歸檔日志。

LGWR還分為LGWR ASYNC(異步)和LGWR SYNC(同步)兩種。

最大保護(hù)(maximize protection): 最高級(jí)別的保護(hù)模式。primay上的事務(wù)在commit前必須確認(rèn)redo已經(jīng)傳遞到至少一個(gè)standby上，如果所有standby不可用，則primary會(huì)掛起。該模式能保證零數(shù)據(jù)丟失。 對于最大保護(hù)和最高可用性模式，Standby數(shù)據(jù)庫必須配置standby redo log，并且oracle推薦所有數(shù)據(jù)庫都使用LGWR ASYNC模式傳輸。

LGWR ASYNC: ------------

Asynchronously archiving with the LGWR process in
conjunction with SSH port forwarding showed the following characteristics when
compared to the baseline: - Significant reduction in network traffic -
Slight increase in primary database throughput - Minimal increase in cpu usage
When using LGWR to remotely archive in ASYNC mode, the LGWR process does not
wait for each network I/O to complete before proceeding. This behavior. is made
possible by the use of an intermediate process, known as a LGWR network server
process (LNS), that performs the actual network I/O and waits for each network
I/O to complete. Each LNS has a user configurable buffer that is used to
accept outbound redo data from the LGWR. This is configured by specifying the
size in 512 byte blocks on the ASYNC attribute in the archivelog destination
parameter. For example ASYNC=2048 indicates a 1Mb buffer. As long as the
LNS process is able to empty this buffer faster than the LGWR can fill it, the
LGWR will never stall. If the LNS cannot keep up, then the buffer will become
full and the LGWR will stall until either sufficient buffer space is freed up
by a successful network transmission or a timeout occurs. Reducing network
traffic in a network with high round trip times (RTT) reduces network server
timeouts due to buffer full conditions, thus reducing the impact to the
primary database throughput. ASYNC can improve the primary database throughput
due to the fact that by compressing the redo traffic, the transfer (in 1 MB
chunks) is quicker and thus the ASYNC buffer doesn't reach full capacity as
often, thereby avoiding the wait that can occur when the buffer is full.

上述內(nèi)容就是數(shù)據(jù)庫Standby中的幾個(gè)概念分別是什么，你們學(xué)到知識(shí)或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識(shí)儲(chǔ)備，歡迎關(guān)注億速云行業(yè)資訊頻道。