Reporting Service中專為數據探測及虛擬化添加了一款名為Power VIEw的網絡前端。Analysis Service則引入了一套全新的語義模型，為商務智能專家在構建解決方案時提供更多靈活性。此外，列式存儲索引機制的出現令查詢性能更上一層樓；再加上新的Data Quality Service以及對原有Master Data Service的加強，SQL Server 2012無疑將在處理企業數據方面更加得心應手。
當然，SQL Server 2012中還包含了大量專為數據庫管理員們准備的新功能，旨在幫助他們在管理工作中更加高效地處理問題。這些內容我在本點評文章中也會談到，不過首先從大家最關心的、能夠幫助系統可用性達到新水平的功能開始。
錦上添花的可用性
讓咱們首先聊聊新版本中最大的進化內容之一——AlwaysOn。AlwaysOn是一種新的HA技術，它的出現將傳統數據庫鏡像徹底扔進垃圾桶。由於鏡像備份機制已然啟動，因此鏡像被局限在某台單一目標服務器上顯然並不理想。另外，除非我們關閉自己的主數據庫，否則這些鏡像目標根本毫無用處，甚至連內容讀取都無法實現。針對以上兩點問題，AlwaysOn交出了令人滿意的答卷。我們完全可以為自己的主數據庫輕松配置多套只讀副本，並在系統運行狀態良好時將其作為報告機制使用。當然，與鏡像備份類似，我們也可以對AlwaysOn進行設置，指示其與目標主數據庫實時同步或者延時同步。
鏡像可讀性本身已經解決了備份機制中的一個老大難問題，但AlwaysOn最大的貢獻還不僅限於此——它實現了多套相關數據庫之間的故障切換。在通常情況下，兩套或兩套以上數據庫的正常運行往往需要彼此之間的相互支持；也就是說只要其中某一套出了問題，僅憑鏡像根本不足以支撐起全局業務。而AlwaysOn利用Availability Group（可用性群組）解決了數據庫之間相互依賴的問題。該功能允許我們將那些必須同時失效的數據庫指定為一個群組，這樣一旦某套關鍵性數據庫失效，相關數據庫也將一並失效。通過這種方式，數據庫的整體切換終於成為可能。
數據庫的彼此依賴性是數據庫管理員們最為頭痛的另一大課題。當我們將數據庫恢復到不同的運行環境中時，需要考慮到各種不同的情況，例如連入服務器、用戶賬戶以及跨數據庫規程與視圖等等。這一切都必須通過同步與現有工作狀態相匹配方能達到目的。而在SQL Server 2012中，我們發現了一項名為ContainedDB的功能，在它的幫助下我們能夠將一套數據庫轉化為獨立體系，也就是不與任何外部因素相關聯。在這項功能啟用時，我們無法向目標數據庫寫入任何將對其它數據庫產生依賴性的內容，也不允許該數據庫中包含任何將被外部系統所調用的對象。事實上，ContainedDB中的用戶賬戶甚至根本沒有服務器級別的登錄選項，這樣大家就不必擔心自己在將數據庫移動到新設備中時需要進行麻煩的賬戶信息同步了。當然，這還只是ContainedDB功能的首個版本，其中必然存在著一些問題與局限性；但它的意義非常重大，至少為我們帶來了一個良好的開端。
另一大重大改進來自事件日志與追蹤系統。SQL Profiler已經被正式捨棄，新的XEvents（即擴展事件）GUI取而代之。XEvents在最新版本中得到了極大擴展，新的追蹤機制也將完全以它為核心運作。對於大多數用慣了老版本的用戶來說，這次大刀闊斧的改動可能會帶來些許不適，但我可以保證一旦上手，各位絕對會對新方案贊不絕口。XEvents比過去的SQL Trace更為靈活，也就是說如今追蹤活動給設備帶來的性能影響已經變得微乎其微。不僅追蹤機制發生變革，重播功能也以Distributed Replay（分布式重播）之名改頭換面。顧名思義，它讓用戶得以從多台設備重播那些受到追蹤的工作負載，這樣我們就能更好地模擬所在企業的日常生產活動。如果大家正打算進行更新測試或者考察自己的設備能否應對突如其來的數據爆發，那麼這些功能的出現實在是既貼心又實用。
索引體系改進
索引體系迎來兩大改進——在線重新索引與列式存儲索引。相對於大多數企業針對數據庫管理員們所做的管理簡易化宣傳，少數幾項功能似乎一直並未受到多少重視，而在線重新索引正是其中最被忽視的項目之一。相信大家跟我一樣，都曾為SQL Server 2005中的在線重新索引功能而感到興奮不已；然而事實證明那套東西根本無法作用全部數據類型。在實際操作中，我們很快發現任何包含可變長字符、n長度可變長字符、可變二進制以及XML列數的索引都無法被在線重新索引功能接受。因此，我們不得不為自己的重新索引規范添加定制邏輯，以其使理解這兩種不同類型的索引內容。現在，革命終於迎來新的進展，各種數據類型都可以為在線重新索引所支持，而我們也真正對全天候運行的應用程序提供在線索引維護。只要我們能夠對在分區表進行在線重新索引處理，這項新功能也就真正服務於業務流程了。
SQL Server 2012還引入了一套新型索引機制，名為列式存儲索引。傳統的索引會將數據以行為單位進行存儲，並將這些行添加到索引當中以完成索引任務。列式存儲索引則是以列為單位存儲數據，並將這些列添加到索引中以完成索引任務。根據微軟公司的說法，這種新機制能夠在相同情況下帶來十倍於傳統索引的性能表現。然而，這一次微軟似乎有些過謙：根據我本人的實際體驗，性能提升遠遠不止十倍。列式存儲索引的出現主要是為了迎合大數據集倉儲所帶來的需求。但我相信大家可能不會在OLTP（即聯機事務處理）方面使用這套新機制，因為列式存儲具有只讀屬性。
除了顯著的性能提升之外，SQL Server 2012還能夠被安裝在Windows Server內核之中。這不僅增加了服務器的全局處理能力，而且強化了安全性。在服務器內核中運行的服務項目相比較少，這意味著其中的安全漏洞也會相應減少，同時可能導致性能低下的軟件bug也會得到有效扼制。
T-SQL強化
T-SQL倒沒有太多新功能，但目前的這些已經足以應對業務需求。我個人最喜歡的是新的LAG與EOMonth窗口化功能。LAG為我們結果集中的每一行配備了訪問前一行中列數據的接口，也就是說只要我們擁有給定列，就能隨心所欲地顯示同一行當中的當前值與過去值。說完了LAG，再來看看EOMonth。它的功能在於幫助我們直接訪問每月最後一天發生的賦值變化。以上二者只是新功能中的一部分，其它的就請各位讀者在使用中親自發掘吧。
在所有T-SQL強化項目當中，FileTable可能算是最引人注目的功能了。從根本上說，它可以直接從文件系統中訪問文件流數據。這裡我需要解釋一下，文件流允許我們將文檔保存在文件系統當中，但這些文檔必須與數據庫同步備份，這樣我們才能確保資料的安全性。FileTable則更進一步，將數據庫與文件系統之間的交互關系透明化。首先，我們要將指定列表定義為FileTable，並為其分配一個文件系統中的目錄。接下來，我們要做的是從Windows資源管理器中將要管理的文件拖動到該目錄中。整個過程就是這麼簡單，如此一來我們不僅能夠像以前那樣在文件系統層面管理這些資料並保存到數據庫中，也可以直接從T-SQL或者Windows系統層面對這些文件直接加以改動。
說了這麼多優點，咱們再來談談SQL Server 2012中不盡人意的地方。就我個人而言，感到最失望的一點在於PowerShell在這個版本中所蒙受的冷落。比起AlwaysOn以及備份/恢復等功能所獲得的大幅度強化，SQL Server 2012中的PowerShell似乎沒有得到任何實質性提升。至少在當初微軟無比倚重PowerShell的那些年，一個全新的版本中絕不會只為其配備這麼一丁點改進。另一點讓人失望之處在於幾乎原封不動的SSMS（即SQL Server管理器）。微軟已經把SSMS移植到Visual Studio 2010當中，但相對於這一改動的影響力（比起Team Foundation Server中對片段管理與整合效果的提升），數據庫管理員幾乎沒能從中獲得任何實質性的工作能力強化。其實在我看來，這方面的改進空間還是滿大的，比如更好的多服務器管理及報告功能、將PowerShell與SSMS嚴密整合等都是不錯的主意。可惜，一條也沒實現。
在數據庫升級方面，我一直抱持著所謂“滿五原則”。也就是說，至少得有五大顯著的功能提升才能讓我們真正有興趣對自己的數據庫進行大規模升級。不過在這裡我只要從某些方面對SQL Server 2012做出點評，還有很多方面是目前還不適合拿出來討論的。SQL Server Integration Services得到大幅修整，SQL Server Analysis Services與SQL Server Reporting Services也有令人驚艷的強化，這一切倒已經足夠令人滿意了。相信在大家拿到正式版之後，一定不難從中找到說服自己升級到SQL Server 2012的五條理由。
