發展到SQL Server 2014應該是適應社會的需求，也是技術的不斷更新。不同的數據庫語句有不同的特點和新功能。技術上的改進會帶來一些新功能。就如想要實現云虛擬技術不是一件簡單的事。鴻蒙系統的問世是需要似梅花要經歷寒冷的冬季才能讓人聞道它獨特的香味。SQL Server 2014L的出現給用戶帶來了便利。提高了效率和節約了用戶在辦公上的時間。為用戶帶來了技術上的支持。

新功能

1、內存技術改進

SQL Server 2014中最吸引人關注的特性就是內存在線事務處理(OLTP)引擎，項目代號為“Hekaton”。內存OLTP整合到SQL Server的核心數據庫管理組件中，它不需要特殊的硬件或軟件，就能夠無縫整合現有的事務過程。一旦將表聲明為內存最優化，那么內存OLTP引擎就將在內存中管理表和保存數據。當它們需要其他表數據時，它們就可以使用查詢訪問數據。事實上，一個查詢會同時引用內存優化表和常規表。

SQL Server 2014增強內存相關功能的另一個方面是允許將SQL Server內存緩沖池擴展到固態硬盤(SSD)或SSD陣列上。擴展緩沖池能夠實現更快的分頁速度，但是又降低了數據風險，因為只有整理過的頁才會存儲在SSD上。這一點對于支持繁重讀負載的OLTP操作特別有好處。LSI Nytro閃存卡與最新SQL Server 2014協同工作，降低延遲、提高吞吐量和可靠性，消除IO瓶頸。

在SQL Server 2014中，列存儲索引功能也得到更新。列存儲索引最初是在SQL Server 2012引入的，目的是支持高度聚合數據倉庫查詢。基于xVelocity存儲技術，這些索引以列的格式存儲數據，同時又利用xVelocity的內存管理功能和高級壓縮算法。然而，SQL Server 2012的列存儲索引不能使用集群，也不能更新。

SQL Server 2014引入了另一種列存儲索引，它既支持集群也支持更新。此外，它還支持更高效的數據壓縮，允許將更多的數據保存到內存中，以減少昂貴的I/O操作。

2、云整合

微軟一直將SQL Server 2014定位為混合云平臺，這意味著SQL Server數據庫更容易整合Windows Azure。例如，從SQL Server 2012 Cumulative Update 2開始，您就能夠將數據庫備份到Windows Azure BLOB存儲服務上。SQL Server 2014引入了智能備份(Smart Backups)概念，其中SQL Server將自動決定要執行完全備份還是差異備份，以及何時執行備份。SQL Server 2014還允許將本地數據庫的數據和日志文件存儲到Azure存儲上。此外，SQL Server Management Studio提供了一個部署向導，它可以幫助您輕松地將現有本地數據庫遷移到Azure虛擬機上。

SQL Server 2014還增加了一個功能，允許將Azure虛擬機作為一個Always On可用性組副本。可用性組(Availability Groups)特性最初在SQL Server 2012引入，提供了支持高可用性數據庫的故障恢復服務。它由1個主副本和1~4個次副本(SQL Server 2014增加到8個)構成。主副本可以運行一個或多個數據庫;次副本則包含多個數據庫副本。Windows Azure基礎架構服務支持在運行SQL Server的Azure虛擬機中使用可用性組。這意味著您用一個虛擬機作為次副本，然后支持自動故障恢復。

愿景

Microsoft SQL Server的愿景

許多因素致使產生了信息存儲爆炸。有了新的信息類型，例如圖片和視頻的數字化，和從RFID標簽獲得的傳感器信息，公司的數字信息的數量在急劇增長。遵守規范和全球化的發展要求信息存儲的安全性和在任何時候都可用。同時，磁盤存儲的成本顯著地降低了，使得公司投資的每一美元可以存儲更多的數據。用戶必須快速的在大量的數據中找到相關的信息。此外，他們想在任何設備上使用這個信息，并且計劃每天使用，例如Microsoft Office系統應用程序。對數據爆炸和用戶期望值的增加的管理為公司制造了許多挑戰。

Microsoft® 數據平臺愿景提供了一個解決方案來滿足這些需求，這個解決方案就是公司可以使用存儲和管理許多數據類型，包括XML(標準通用標記語言的子集)、電子郵件、時間/日歷、文件、文檔、地理等等，同時提供一個豐富的服務集合來與數據交互作用：搜索、查詢、數據分析、報表、數據整合，和強大的同步功能。用戶可以訪問從創建到存檔于任何設備的信息，從桌面到移動設備的信息

語音

Microsoft按照客戶/服務器體系結構的分布進行操作。這種方法產生不必要的代價和復雜性。在Internet中，Oracle已經發現了一個較好的答案。在Internet Computing的多層(multi-tiered)體系結構中，集中(centralization)可以簡化應用的部署和維護，數據的管理和備份，并向客戶提供了高級的性能、安全性與可靠性，結果使總的操作成本更低。Oracle具有使所有數據和文檔存儲在少數幾個高性能數據庫的能力，這種能力使客戶可以集中管理他們所有的數據，并且信息管理和訪問更加容易、可靠且價格更加便宜。

開放

SQL Server只在Windows上運行，MicroSoft這種專有策略的目標是將客戶鎖定到Windows環境中，限制客戶通過選擇一個開放的基于標準的解決方案來獲取革新和價格競爭帶來的好處。此外，人們也都知道，Windows平臺本身的可靠性、安全性和可伸縮性也是有限的。Oracle能在所有主要的平臺(其中包括Windows)上運行，并且完全支持所有的工業標準，所以，客戶可以利用很多種第三方應用程序、工具、網關和管理實用程序。Oracle采用開放策略，它使得客戶可以選擇一種最適合他們特定需要的解決方案。利用Oracle8i，操作系統實質上將變得無關緊要。Oracle8i的Internet文件系統(iFS)是一種突破，這種突破性給所有數據類型提供了一種易于使用的數據管理接口，這樣減少了客戶對Windows之類的專用操作系統。

可伸縮性

由于SQLServer7.0的并行實施和共存模型并不成熟，這使得人們更加關心該產品處理日益增多的用戶數和數據卷mes)的能力。Oracle在下列兩個方面提供了一個優越的可伸　簇：Oracle并行服務器通過使一組節點共享同一簇中的工作負載來擴展Windows NT的能力，Oracle提供具有高可用性和高伸縮性的簇解決方案，而Microsoft只提供克服錯誤的簇。根據Gartner Group的一份報告(10/97)，Microsoft在2001年以前將不會有一個可伸縮的簇解決方案。Oracle自從1997年以來就已經有這種能力。伸縮到其他操作系統：因為Oracle是一個開放的解決方案，客戶可以從他們的系統移到Unix或另一個操作系統，當Windows NT不能滿足他們的需要。SQL Server與單個平臺的結合意味著，當一個客戶達到Windows NT的限制時，除了放棄他們的系統并移到一個新平臺上的一個新數據庫以外??一個最能節省時間和金錢的建議，他們再也沒有其他選擇。

安全性

由于Internet的出現而帶來的全球數據訪問也同時增加了潛在的安全危險。對于數據庫的安全要求決不會比以前更高，而SQL Server7.0還沒有獲得任何類型的安全證書。相比之下，Oracle是唯一獲得最高認證級別的ISO標準認證的數據庫。Oracle高級的安全特性考慮了強制實施的細小權限，先進的審查，增強的訪問控制，安全的分布是處理與復制，以及使用附加的外部簽發機制的能力。SQL Server7.0沒有這些特性。

可擴展性

今天的Internet是一個令人激動的新世界，它具有鮮明的圖像，實時的視頻點播，高保真的語音和聲音，以及諸如金融數據趨勢和地理編碼之類的復雜信息。通過集中管理文本、圖像、音頻、視頻和地理信息，Oracle8i的interMedia使客戶能夠利用Web的多媒體特性。相比之下，Microsoft SQL Server 7.0對非傳統的數據類型缺乏內置的支持。作為一種替代的策略，Microsoft提倡將非傳統的數據存儲到單獨的服務器里的平面(flat)文件中，然后使用OLE-DB將它們鏈接在一起。使用這種策略，集成在Web中發現的各種數據類型，將會產生復雜的、不安全的、維護量大的數據包(mess)，這種數據包缺乏事物的完整性。

性能

低性能可能是很致命的(fatal)，因為雇員的生產能力被阻礙，客戶由于過多的等待時間而丟失。根據事物處理委員會(TPC)審查的標準與結果，Oracle提供了比SQL Server7.0更高級的性能。到1998年11月為止，Oracle一直是Windows NT中TPC-D和TPC-C標準的世界記錄保持者。實際上，Oracle的NT TPC-C結果幾乎比Microsoft的快兩倍。Microsoft 從來沒有宣布一個TPC-D結果，這就意味著盡管SQL Server7.0中有假定的環境，但它仍然不適合于數據倉庫應用。Oracle也保持了SAP,Baan和Peoplesoft標準的世界記錄。通過一貫地演示正式標準與實際情況之間的性能關系，acle已被證明，它可以處理最緊迫的數據倉庫和OLTP應用的工作負。

操作簡單

使數據庫易于安裝、使用和管理??組合在一起稱為“操作簡單“??是一個減少成本的關鍵因素。盡管Microsoft產品具有易于使用的美譽，但SQL Server7.0缺乏數據庫管理的特性，而這種特性是復雜的數據庫系統所必須的。例如，對于SQL Server6.5和SQL Server7.0.Microsoft需要使用單獨的管理工具。為了易于安裝，Oracle使用了一個基于Java的實用程序，該實用程序提供了安裝和運行一個預調整和預配置的Oracle8i數據庫所需要的一切內容。“操作簡單“的最重要部分是易管理性，Oracle Enterprise Manager(企業管理器)提供一個集成的管理控制臺來集中管理多個服務器。客戶也可以單獨購買所有三個或其中任何一個可選的管理包，這些管理包提供了高級的功能來調整和診斷數據庫，管理數據庫環PC Week已經說過，“SQL Server7.0并沒有向客戶提供其競爭對手尚未提供的任何新東西。”根據Information Week(9/14/98)，“即使在經濟的市場中：Windows NT環境，SQLServer7仍然不是OLTP數據庫競爭者的對手。”在SQL Server7.0中，許多關鍵任務數據庫應用所必需的功能(高可用性/可伸縮性、安全、性能等)仍然沒有。Microsoft正在努力地追趕Oracle又一個技術領先的傳統，新發布的Oracle8i也不例外。通過諸如iFS、數據庫Java、WebDB、interMedia和WebToGo之類的革新，Oracle帶頭使各個公司獲得Internet計算的好處。特別在Windows NT中，由于Oracle是第一個發布NT數據庫簇解決方案的廠商，第一次支持超過大內存(VLM)，第一次將高可用性和可伸縮性帶到安裝有Oacle并行服務器的NT中。

技術風險

SQL Server7.0是一個完全重寫的產品版本。該產品經歷了聯系的延遲，并且具有非常長的beta測試周期，這通常代表開發問題。一份Gartner報告(8/98)說，“引擎的重新設計時非常深的...我們建議在1999年中期以前，不要將該產品部署在規模比較大的產品應用中。”正如一份Giga報告(3/98)所說的那樣，“SQL Server仍有許多需要證明。可伸縮性、可靠性、多用戶的性能、簇的開發、對象特性的支持等都有問題。”一個特別危險的因素是重新加在數據庫問題。由于基本的數據結構發生變化，Microsoft將要求所有SQL Server6.0和6.5站點必須先卸載然后重新加載數據，這個過程需要好幾天的時間。Microsoft已經承認6.5和7.0之間存在后向兼容問題。利用SQL Server7.0.許多以前存在的基本的6.5代碼將必須重寫，以便利用象行級鎖定和分布聯合之類的新特性。公司在使它們的生產率和信息冒風險時必須非常謹慎。利用Oracle沒有任何風險。Oracle8已經發布一年多了，并被部署在成百上千個用戶站

點上。在500家財團公司中，將近90%的公司使用Oracle產品和服務器。如此廣泛的支持是人們對Oracle信任的結果，這種信任來自于Oracle是一個安全和合理的選擇。客戶將詢問自己，在已經有可靠的、先進的Oracle8數據庫時，為什們還要冒險使用新的未被證明的SQL。

廠商風險

Microsoft的核心能力是在桌面和操作系統軟件的開發，該公司在企業級數據管理沒什么經驗。從技術和業務來看，Microsoft進入數據管理領域，到目前為止還沒有獲得信任。Microsoft的成功是由于依靠客戶軟件的連續廢棄與升級，以及硬件和操作系統盡可能的傳播。在企業范圍內若要獲得成功，則要求高效利用已有的數據資源，并合并服務器資源。在另一個方面，Oracle已有二十多年的向客戶解決方案的經驗。一個公司的數據是它們最有價值的資產，Microsoft不能指望涌進這個市場，然后一夜之間獲得信任。Oracle已經花費了幾年的艱苦努力才贏得其客戶群的信任以及它享受到的榮譽。每天成千上萬的客戶在Oracle上運行它們的業務所獲得的成功就是Oracle技術和業務模型完美的有利證明。

性能參數

語音

當您懷疑計算機硬件是影響SQL Server運行性能的主要原因時，可以通過SQL Server Performance Monitor監視相應硬件的負載，以便證實您的猜測并找出系統瓶頸。

Memory: Page Faults / sec如果該值偶爾走高，表明當時有線程競爭內存。如果持續很高，則內存可能是瓶頸。

Process: Working Set SQL Server的該參數應該非常接近分配給SQL Server的內存值。在SQL Server設定中，如果將"set working set size"置為0.則Windows NT會決定SQL Server的工作集的大小。如果將"set working set size"置為1.則強制工作集大小為SQLServer的分配內存大小。一般情況下，最好不要改變"set working set size"的缺省值。

一單位的統計服務器投入使用后，運行速度較慢，經排查原因，發現SQLServer中的內存選項(Memory)僅為安裝缺省值16MB(而服務器有128MB的物理內存)，在將內存值調整為100MB時卻誤將其改成了1000MB，使得SQL Server服務不能啟動，統計數據庫打不開，也就不能再次進入SQL Enterprise Manager修改內存設置了。由于未備份業務數據，不到萬不得已不能重裝SQLServer數據庫，就試圖用命令行參數命令來重新啟動SQL Server服務，但均不能奏，陷入了困境。我們經過仔細分析提出：既然SQL Server可用內存設置值遠遠大于物理內存，造成SQLServer服務不能啟動，何不擴充虛擬內存呢?經設法將機器虛擬內存擴充至1000MB并重新啟動，SQL Server數據庫成功啟動，問題迎刃而解。

機制結構

SQL Server 是一種客戶機/服務器系統

多年來，SQL Server 一直被認為是一種客戶機/服務器系統。事實上，Sybase DataServer(以此為基礎開發了原始的 SQL Server)正是第一個作為客戶機/服務器系統開發的商用關系數據庫系統。那這又說明了什么呢?這不只意味著 SQL Server 是一個雙層系統。從傳統上看，雙層系統意味著客戶機應用程序運行在一臺機器上，向另一臺計算機上的服務器發送請求。而對于 SQL Server，客戶機/服務器意味著 SQL Server 的組成部分，即客戶機 API 部分，駐留在處理結構中的遠端，與服務器組件本身是分開的。

在典型的雙層模型中，客戶機程序部分駐留在臺式機上，具有大量客戶機應用程序邏輯和業務邏輯，并且會直接向數據庫系統發出請求。然后，客戶機得到服務器響應這些請求所返回的數據。

三層系統也采用了同樣的模型。多年以來，SQL Server 一直用在事務處理監視系統中，例如 BEA 的 Tuxedo 以及 Compaq 的 ACMSxp，這些系統早在二、三十年前就采用了典型的三層模型。三層模型在今天基于 Web 的應用系統中占據了支配地位，這類系統以 Microsoft 的 MTS 以及新的 COM+ 1.0 為代表。從 SQL Server 的角度看，三層解決方案中的客戶機程序是放在中間層的。中間層直接與數據庫交互。實際的桌面，或瘦客戶機(Thin Client)，使用其他機制并通常直接與中間層交互，而不是直接與數據庫系統交互。

結構

從結構的角度看，SQL Server 關系服務器組件本身并不真正關心客戶機程序運行的位置。事實上，就 SQL Server 而言，即使在運行 SQL Server 的同一臺機器上運行應用程序，仍然還是客戶機/服務器模型。服務器運行一個單獨的多線程進程，為來自客戶機的請求提供服務，不管客戶機的位置在哪里。客戶機程序代碼本身是單獨的運行在客戶機應用程序內部的 DLL，與 SQL Server 的實際接口是在客戶機和服務器之間對話的“表格數據流”(Tabular Data Stream,TDS) 協議。一個常見的問題是“什么是 SQL Server 的本機接口呢?”很長時間以來，很多開發人員一直都不愿意使用 ODBC 這樣的接口，因為他們認為由 Sybase 開發的客戶機 API，也就是 DB-Library，是 SQL Server 的本機接口。實際上，SQL Server 關系服務器本身并沒有本機 API，它的接口就是在客戶機和服務器之間的通信流協議 TDS。TDS 把客戶機發送給服務器的 SQL 語句封裝起來，也把服務器返回給客戶機的處理結果封裝起來。任何直接處理 TDS 的 API 都是 SQL Server 的本機接口。

讓我們來看一下客戶機的組件，客戶機結構中的某些部分就不在這里討論了，因為它們不屬于 SQL Server 的范疇。但如果您在編寫應用程序的話，就必須了解這些部分。大家知道得最多的應該是各種對象模型，如果您正在編寫 ASP 或 Microsoft Visual Basic(R)應用程序，就需要通過 ADO 與數據庫系統交互，而不是直接調用底層的 API，例如 ODBC 或 OLE-DB。ADO 映射到 OLE-DB，而 RDO 映射到 ODBC。因此，作為這種最常用的編程模型的對象模型，并不是 SQL Server 客戶機結構中的嚴格意義上的組件。此外，還有另外一些組件可以插接到 SQL Server 基礎結構上面的這一層。OLE-DB 的“會話池服務提供程序 (Session Pooling Service Provider)”就是這種組件的一個例子。

接口

SQL Server 有兩個接口可以認為是 SQL Server 7.0 的本機接口，即 OLE-DB 和 ODBC。DB-Library 接口也是本機的，它與 TDS 通信，但是 DB-Library 使用的是 TDS 較老的版本，需要在服務器上進行一些轉換。現有的 DB-Library應用程序仍然可以繼續與 SQL Server 7.0 協同使用，但是很多新的功能和性能提高等好處只能通過 ODBC 和 OLE DB 才能利用。更新 DB-Library 使其支持 SQL Server 7.0 的新能力，將會導致與現有應用程序的很多不兼容性，因此需要修改應用程序。ODBC 在五年之前就替代了 DB-Library，是新的 SQL Server應用程序更理想的 API，因此引入不兼容的 DB-Library 新版本并不明智。從圖 2 可以看到，所有這些客戶機 API 都有三個部分。最上面的部分實現 API 的細節，例如行集和游標應該是什么樣等等。TDS 格式化程序負責處理實際請求，例如 SQL 語句，并將其封裝成 TDS 消息包，發送給 SQL Server，獲得返回的結果，然后再把結果反饋到接口實現。

還有一些供所有提供程序使用的公共庫代碼。例如，BCP 設備就是 ODBC 和 OLE-DB 都可以調用的庫。DTC 也是這樣。第三個例子是 ODBC 規范的 SQL 語法，即帶有參數標記的 CALL 語法，這些對于所有提供程序都是通用的。

除了我們在前面已經提到的局限性，即 DB-Library 仍然只能使用 SQL Server 6.5 版，TDS 協議對于所有 API 都是相同的。ODBC 和 OLE-DB 在與 SQL Server 7.0 通信時使用 SQL Server 7.0 版，但也能夠與 6.5 或 6.0 服務器通信。另一個是 Net-Library，這是一個抽象層，客戶機和服務器都在此層上同網絡抽象接口通信，不必為 IPX 還是 TCP/IP 困擾。在這里我們將不討論 Net-Library 的工作細節;只要知道它們的工作基本上是將來自的網絡通信底層的細節隱藏起來不讓軟件的其他部分看到就可以了。

服務器

前面已經提到過，客戶機與 SQL Server 通信的主要方法就是通過使用 TDS 消息。TDS 是一種簡單協議。當 SQL Server 接收到一條消息時，可以認為是發生了一個事件。首先，客戶機在一個連接上發送登錄消息(或事件)，并得到返回的成功或失敗的響應。當您希望發送 SQL 語句時，客戶機可以把 SQL 語言消息打包發送給 SQL Server。另外，當您希望調用存儲過程、系統過程或虛擬系統存儲過程(我們后面還要詳細討論)時，客戶機可以發送 RPC 消息，這種消息相當于 SQL Server 上的一個 RPC 事件。對于上面的后兩種情況，服務器會以數據令牌流的形式送回結果。Microsoft 沒有把實際的 TDS 消息寫入文檔中，因為這被認為是 SQL Server 組件之間的私用契約。

目錄存儲過程是另一類關鍵的客戶機/服務器的交互部分。這些存儲過程首先在 ODBC 的 SQL Server 6.0 中出現，包括諸如 sp_tables 和 sp_columns 等存儲過程。ODBC 和 OLE-DB API 定義了描述有關數據庫對象的元數據的標準方法，這些標準需要適用于所有類型的 RDBMS 服務器，而不必調整為 SQL Server 自己的系統表。不是客戶機向服務器發送對系統表的多個查詢，并在客戶機端建立標準的元數據視圖，而是創建一組存儲在服務器上的系統存儲過程，并對 API 返回適當格式的信息。這種方法使得通過一次通信就可以完成很多重要的元數據請求。為 ODBC 編寫的過程已經寫入文檔，通常適合需要從系統表中獲取信息但其他機制沒有提供這種方法的情況。這使得Transact-SQL過程和 DB-Library應用程序可以訪問元數據，而不需要編寫對 SQL Server 系統表的復雜查詢，并且使應用程序不受今后 Microsoft 修改系統表的影響。OLE DB 定義了一組架構行集，它們類似于 ODBC 的元數據，但又和它不同。它創建了一組新的目錄存儲過程，以更有效地為這些架構行集植入數據。但是，這組新的存儲過程沒有寫入文檔，因為這些存儲過程重復了早先提供的功能。通過現有的若干種方法都可以得到元數據，因此 SQL Server 開發組決定不顯露這些并沒有為編程模型增加新內容的對象。

計數器

服務器上新建性能監控的日志，取所需計數器，設定計劃任務定時啟動或建立SQL JOB定時執行命令：logman start 計數器名

想要了解更多關于SQL Server 2014的信息，請繼續關注中培偉業。