SQL Server高可用的罕見成績剖析。本站提示廣大學習愛好者：（SQL Server高可用的罕見成績剖析）文章只能為提供參考，不一定能成為您想要的結果。以下是SQL Server高可用的罕見成績剖析正文
每次談到SQL Server的高可用，許多的DBA，特殊是SQL Server DBA心裡一痛：由於年夜家都以為SQL Server沒法或許很難完成SQL Server。也有許多的DBA同伙腦殼一拍，給出謎底“高可用不就是微軟的那幾個技巧嗎，如Replication, Failover Clustering”…
1.豈非SQL Server在高可用下面就顯得這麼的有力嗎？
答復：不是的，其實SQL Server很給力。
2.為何許多人老是埋怨SQL Server中高可用很難完成呢？
這裡從幾個方面來講。
起首，就所接觸到的許多的項目（歐美占多數），這些項目中不乏所謂的海量數據，也有許多的高機能運用，前面采取的都是SQL Server，並且還沒有采取第三方的數據庫幫助軟件。
其次，我們說說人的成績。人都有如許一個習氣：每次湧現成績以後，第一反響就是回避，然後找個好的來由或許替罪羊，最初弄來弄去，就開端怪技巧自己不可。這就有點相似，菜鳥用寶刀的時刻，殺不逝世人，不貴自己的才能不可，而是怪刀欠好。說到這裡，就想到之前的CSDN暗碼洩漏成績，許多人竟然年夜罵微軟的技巧不可，這讓那些曾經用微軟技巧完成高平安的運用的公司看笑話。
再次，以偏概全的概念！許多人認為Replication就是高可用了，因而就一股腦的期望Replication可以處理他們的成績，卻不知：Replication只是完成高可用中的一個主要的組件罷了，而不是全體。說到這裡，是我想起幾個相似誤會，“認為JQuery就是ajax技巧”，卻不知，jquery只是一個框架，可以用來完成ajax罷了。有人以為“架構設計就是設計形式和架構形式的應用”，其實架構設計就是一種思想，而那些形式僅僅只是一個小的手腕罷了，把架構設計比方為一個年夜樓，那些形式充其量就是一些磚頭，而不是全體。
同理，Replication也僅僅只是完成高可用中的“一塊磚”。
最初，關於技巧的控制水平不敷，招致許多人碰到成績時刻沒法處理。並且也不曉得找誰處理，去哪裡找等。
3.高可用是用一個軟件或許產物就弄定的嗎？
這裡許多人想到的就是Oracle的RAC，還有一些第三方的產物。分歧的產物，封裝的水平紛歧樣，有的產物把許多的器械都封裝了，只需應用人員進修若何應用對象就OK，不消控制細節。然則，應用這些產物的時刻，在停止安排和操作的時刻，現實上就是在依照產物設計人的思惟在搭建高可用罷了，只是我們以為這個進程是“應用手冊”罷了。
而SQL Server自己沒有供給如許的完整封裝的產物，然則高可用設計中須要的主要焦點技巧和組件都曾經有了，“釘子，螺絲，資料”都有了，就看你若何組裝起來。
異樣的做菜資料和對象，高超的廚師做出來的是厚味好菜，而普通的廚師僅僅只是把菜弄熟罷了。
4.高可用僅僅只是數據庫技巧嗎？
完成高可用，不只僅只是數據庫層面下面的內容，其實更多須要的是設計和架構才能。須要曉得，軟件，硬件，操作體系，收集，數據庫等技巧。
並且高可用也不是一個詳細的技巧，而是概念，完成的辦法就是千萬萬。有人說“高可用就是讀寫分別”，“高可用就是負載平衡”，對嗎？用腳指頭都可以答復這些成績。
5.沒有全能的產物和全能的計劃，一切都是“看情形而定”
許多人在爭辯“無同享磁盤（數據庫）”好，“程度拆分”好。這些說的直白一點：零丁的評論辯論，沒有任何的意義。不把技巧用在詳細的運用中，不帶來經濟價值，技巧甚麼都不是。
產物，技巧等自己都是有必定的應用規模和局限性的，許多社區的同伙在評論辯論的時刻，老是愛好一個全能的產物特征，例如，有人說“SQL Server 2012的AlwaysOn”可以完成高可用了。卻不知：技巧是人在應用，產物只是我們人在設計中應用的一個零件罷了，最初的設計照樣看人。早在十多年前，就有許多的公司的年夜型運用就是采取SQL 2000做的，那時刻，SQL Server還沒有這麼多的功效和組件。
