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

新功能

1、內(nèi)存技術改進

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

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

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

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

2、云整合

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

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

愿景

Microsoft SQL Server的愿景

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

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

語音

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

開放

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

可伸縮性

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

安全性

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

可擴展性

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

性能

低性能可能是很致命的(fatal)，因為雇員的生產(chǎn)能力被阻礙，客戶由于過多的等待時間而丟失。根據(jù)事物處理委員會(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中有假定的環(huán)境，但它仍然不適合于數(shù)據(jù)倉庫應用。Oracle也保持了SAP,Baan和Peoplesoft標準的世界記錄。通過一貫地演示正式標準與實際情況之間的性能關系，acle已被證明，它可以處理最緊迫的數(shù)據(jù)倉庫和OLTP應用的工作負。

操作簡單

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

技術風險

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

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

廠商風險

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

性能參數(shù)

語音

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

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

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

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

機制結構

SQL Server 是一種客戶機/服務器系統(tǒng)

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

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

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

結構

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

讓我們來看一下客戶機的組件，客戶機結構中的某些部分就不在這里討論了，因為它們不屬于 SQL Server 的范疇。但如果您在編寫應用程序的話，就必須了解這些部分。大家知道得最多的應該是各種對象模型，如果您正在編寫 ASP 或 Microsoft Visual Basic(R)應用程序，就需要通過 ADO 與數(shù)據(jù)庫系統(tǒng)交互，而不是直接調(diào)用底層的 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 較老的版本，需要在服務器上進行一些轉(zhuǎn)換。現(xiàn)有的 DB-Library應用程序仍然可以繼續(xù)與 SQL Server 7.0 協(xié)同使用，但是很多新的功能和性能提高等好處只能通過 ODBC 和 OLE DB 才能利用。更新 DB-Library 使其支持 SQL Server 7.0 的新能力，將會導致與現(xiàn)有應用程序的很多不兼容性，因此需要修改應用程序。ODBC 在五年之前就替代了 DB-Library，是新的 SQL Server應用程序更理想的 API，因此引入不兼容的 DB-Library 新版本并不明智。從圖 2 可以看到，所有這些客戶機 API 都有三個部分。最上面的部分實現(xiàn) API 的細節(jié)，例如行集和游標應該是什么樣等等。TDS 格式化程序負責處理實際請求，例如 SQL 語句，并將其封裝成 TDS 消息包，發(fā)送給 SQL Server，獲得返回的結果，然后再把結果反饋到接口實現(xiàn)。

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

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

服務器

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

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

計數(shù)器

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

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