推薦：關(guān)于SQL Server 2008中報(bào)表服務(wù)的詳解
一、導(dǎo)言 盡管公司經(jīng)常采集和存儲(chǔ)大量的數(shù)據(jù)，但是有時(shí)還是難以詳盡地顯示數(shù)據(jù)，而且也很難提供對(duì)商業(yè)中將發(fā)生什么的洞察以使商業(yè)決策者為公司作出相應(yīng)的和及時(shí)的決策。 為了能作

不過遠(yuǎn)程故障轉(zhuǎn)移集群就不僅僅是SQL Server一個(gè)人就能完成的了，這個(gè)方案要依賴于SQL Server，Windows Server這些基礎(chǔ)軟件，還要依賴于存儲(chǔ)設(shè)備、交換機(jī)、服務(wù)器這些硬件。

因?yàn)樵谶h(yuǎn)程故障轉(zhuǎn)移集群中，共享儲(chǔ)存不再存在于一個(gè)數(shù)據(jù)中心，而是可能相距數(shù)十公里，甚至數(shù)千公里，因此中長(zhǎng)距的底層存儲(chǔ)同步往往是這一解決方案的關(guān)鍵。對(duì)于中長(zhǎng)距的底層存儲(chǔ)同步，通常分為兩種，一種是在30公里內(nèi)的，通過單模光纖可以實(shí)現(xiàn)兩個(gè)數(shù)據(jù)中心存儲(chǔ)設(shè)備間的同步復(fù)制，而另外一種則是在30公里之外了，而這種情況通常都是通過租用ICP的線路來實(shí)現(xiàn)兩地間的異步復(fù)制。

聽上去好像很復(fù)雜，不過不用擔(dān)心，EMC這樣的廠商有非常成熟的硬件設(shè)備以及相關(guān)軟件。這就是為什么在SQL Server的Always On中會(huì)出現(xiàn)EMC這樣第三方廠商名字的原因。

遠(yuǎn)程故障轉(zhuǎn)移集群的替代方案

哦，天哪！我們討論的解決方案似乎越來越貴。我可不希望這樣結(jié)束。

其實(shí)對(duì)于遠(yuǎn)程故障轉(zhuǎn)移集群來說，主要解決的問題是站點(diǎn)失效的問題，因此單純使用SQL Server的功能也可以解決這個(gè)問題。盡管沒有基于硬件的那么高效和穩(wěn)定。

那么怎么構(gòu)建一個(gè)相對(duì)廉價(jià)的遠(yuǎn)程容災(zāi)方案呢？我們的答案是故障轉(zhuǎn)移集群 日志傳送/復(fù)制。在不提到這兩項(xiàng)技術(shù)的話，他們兩個(gè)一定會(huì)有意見的。

日志傳送依賴于日志備份以及還原來實(shí)現(xiàn)數(shù)據(jù)同步的，而復(fù)制呢，除了日志外多了一個(gè)快照(注意：復(fù)制中使用日志的方式與日志傳送是不一樣的)。因此我們只要確保主服務(wù)器的日志能夠以一個(gè)合理的頻率傳送給遠(yuǎn)端的后備服務(wù)器，我們就可以提供一定程度上遠(yuǎn)程容災(zāi)能力了。

可是在SQL Server 2005之前，復(fù)制和日志傳送都有一些小問題，日志傳送是依賴于日志備份作業(yè)、日志傳送作業(yè)和日志還原作業(yè)，因此日志傳送無法做到連續(xù)性，他的嘴短同步間隔是一分鐘，無法再短了。事務(wù)復(fù)制盡管能做連續(xù)，但是事務(wù)復(fù)制有主從之分，如果是多站點(diǎn)這項(xiàng)技術(shù)會(huì)嚴(yán)重限制后備服務(wù)器的自治能力。

不過從SQL Server 2005開始，事務(wù)復(fù)制有了一種新的模式，叫做對(duì)等事務(wù)復(fù)制。對(duì)等事務(wù)復(fù)制平等看待參與復(fù)制的所有節(jié)點(diǎn)，而取消了主從之分。這就給我們的多站點(diǎn)數(shù)據(jù)服務(wù)規(guī)劃指出了一條新的道路。

不過大家在這張有些夸張的圖里面也許可以看出些端倪。通過對(duì)等事務(wù)復(fù)制，我們確實(shí)可以設(shè)計(jì)出一個(gè)非常復(fù)雜的數(shù)據(jù)復(fù)制拓?fù)洌�利用高�?低速線路，優(yōu)質(zhì)/常規(guī)線路，我們可以在分布于多個(gè)站點(diǎn)的服務(wù)器之間構(gòu)建出一個(gè)復(fù)制拓?fù)�。說上面這張圖是開玩笑，原因是通常復(fù)制拓?fù)洳粫?huì)這么混亂，但是對(duì)等復(fù)制一定可以制成這張圖上出現(xiàn)的服務(wù)器數(shù)量，關(guān)鍵是要良好規(guī)劃和設(shè)計(jì)。

算了，給張清楚點(diǎn)的吧。這是一個(gè)比較真實(shí)地對(duì)等復(fù)制拓?fù)�，我們有兩個(gè)站點(diǎn)。站點(diǎn)內(nèi)擁有高速的鏈接，而站點(diǎn)間則是相對(duì)低速的租用鏈路。A、B、C分別是三個(gè)應(yīng)用的數(shù)據(jù)庫，A和C是本地性應(yīng)用，因此僅在單個(gè)站點(diǎn)內(nèi)進(jìn)行了復(fù)制，保證其容災(zāi)能力，而B是一個(gè)集團(tuán)性的應(yīng)用，為了確保其數(shù)據(jù)的可用性，因此在站點(diǎn)內(nèi)和站點(diǎn)間分別實(shí)現(xiàn)了復(fù)制冗余，同時(shí)站點(diǎn)A和站點(diǎn)B可以互不干擾對(duì)數(shù)據(jù)的使用(當(dāng)然這要依賴于數(shù)據(jù)庫的設(shè)計(jì)和對(duì)等復(fù)制鏈路的配置)。

SQL Server 2008在對(duì)等復(fù)制方面也有一個(gè)小小的改進(jìn)，那就是沖突檢測(cè)。在SQL Server 2005的對(duì)等事務(wù)復(fù)制中，沖突是一個(gè)非常頭疼的事情，因此才會(huì)要求非常嚴(yán)格的數(shù)據(jù)訪問隔離設(shè)計(jì)。SQL Server 2008會(huì)在發(fā)生沖突的時(shí)候暫停復(fù)制，既保證了兩個(gè)站點(diǎn)間的正常數(shù)據(jù)訪問，也保證了在數(shù)據(jù)沖突時(shí)不會(huì)錯(cuò)誤覆蓋正確的數(shù)據(jù)版本。

結(jié)束語

其實(shí)SQL Server的可用性和數(shù)據(jù)應(yīng)用的可用性完全是兩個(gè)層面的事情，SQL Server僅僅是數(shù)據(jù)應(yīng)用中的一個(gè)組成部分，因此如何達(dá)到真正的系統(tǒng)可用性，還要考慮更多的問題，通訊(交換機(jī)、路由器之類)、網(wǎng)絡(luò)服務(wù)(DNS、DHCP之類)、操作系統(tǒng)、應(yīng)用服務(wù)(IIS、中間件服務(wù)器)，還有很多很多的問題。
美國人遭遇了911，我們?cè)庥隽?12，除了沉重的傷痛之外也留給我們?cè)S多需要思考的問題。盡管對(duì)于很多IT來說，911和512似乎很遙遠(yuǎn)，不過我們也討論到了IT系統(tǒng)需要面對(duì)的不僅僅是這些巨大的災(zāi)難，還有颶風(fēng)、火災(zāi)、硬件故障、軟件缺陷、人為破壞，甚至是例行維護(hù)。因此規(guī)劃和實(shí)施有效的可用性方案算是未雨綢繆，當(dāng)遇到真正的突發(fā)事件時(shí)，才能避免花費(fèi)成百數(shù)千倍的代價(jià)去彌補(bǔ)。

分享：如何使用SQL Server代理運(yùn)行CmdExec命令
需求：調(diào)用網(wǎng)服務(wù)器(SMS SQL Server)上的短信發(fā)送接口(是一個(gè)存儲(chǔ)過程)來發(fā)送(Stage SQL Server)上的數(shù)據(jù)內(nèi)容到本Team 成員的手機(jī)上。這兩臺(tái)服務(wù)器，本地在撥VPN后可以訪問。要求以本