《MS SQL Server 2000管理員手冊》系列——11. Microsoft SQL Server 的網路設定

11. Microsoft SQL Server 的網路設定
網路服務概觀
SQL Server 應用程式介面
網路連結庫
網路組件與 SQL Server 效能
網路監控
本章總結
在您安裝了 Microsoft SQL Server 之後，您必須設定其網路相關設定。到現在為止，您或是您的 Microsoft Windows NT 或 Windows 2000 系統管理員可能已經設定了需要的網路通訊協議。如果還沒有設定的話，您可以簡單的利用控制台來設定網路通訊協議。您所選擇的通訊協議通常是根據公司的原則或網路上已經設定的其它系統來決定。儘管不同的通訊協議之間，在效能和功能性上存在一些差異，但是絕大部分都能滿足您的需求。
在本章中，您會學習如何設定 SQL Server 中的各種組件，包括網路硬體層、網路通訊協定層和 SQL Server 網路連結庫層。此外，還將介紹資料庫的串連組件，例如 DB-LIB、Open Database Connectivity（ODBC）及 ODBC 聯機集區（ODBC connection-pooling）功能，並且判斷 SQL Server 是否存在網路聯機的瓶頸。
網路服務概觀
　
SQL Server 用戶端和伺服器端的通訊需要多種的軟體和硬體層。讓我們簡要的看一下這些層級；它們的功能在本章稍後將有更詳盡的說明。
頂層是 SQL Server 應用程式開發介面（Application Programming Interface，API）。API層由下面其中一種服務來構成：
•  DB-LIB（舊式的 SQL Server API）
　
•  ODBC（能串連 SQL Server 或其它資料庫產品）
　
•  OLE DB（ActiveX 程式設計師使用）
　
•  ODS（Open Data Service）
　
API 位於網路連結庫的頂層，網路連結庫通常簡寫為 net-library 或 net-libs 。網路連結庫可將 SQL Server 指令和資料轉譯成系統呼叫，由系統呼叫與網路通訊協定層進行通訊。網路連結庫是 SQL Server 元件，而網路通訊協定層是作業系統組件。您可從下列清單中選擇一或多個網路連結庫：
•  具名管道（Named pipes）
　
•  TCP/IP
　
•  多重通訊協議（Multiprotocol）
　
•  NWLink IPX/SPX
　
•  AppleTalk
　
•  Banyan VINES
　
網路連結庫層可以包含一個以上的網路連結庫，網路通訊協定層也可包含一個以上的網路通訊協議，並且每個網路連結庫與一個或多個網路通訊協定通訊。網路通訊協定層是使用網路通訊協定語言的作業系統組件。SQL Server 的呼叫請求與資料被封裝在網路呼叫中，如此才能透過網路在協議層上傳送。除了 多重通訊協議 （multiprotocol）之外，每種網路通訊協議支援特定的網路連結庫。多重通訊協議選項使用 Windows 2000 與 Windows NT 的 遠端程序呼叫 （remote procedure call，RPC）功能。它同時支援 TPC/IP 通訊端、NWLink IPX/SPX，以及具名管道。
對於 Windows NT 或 Windows 2000 伺服器來說，同時使用幾種不同的網路通訊協議是相當常見的。這些通訊協議將在本章稍後的 〈網路連結庫〉 一節裡有更詳細的說明。
通訊底層由網路硬體和驅動裝置組成。該層通常是獨立於網路通訊協定層，但仍存在著一些相關性。例如，某些裝置僅支援某組特定的網路通訊協議。可用的網路技術很多，且新技術也正在不斷的被開發出來。網路硬體層由許多不同的技術組成，包括以下的內容：
•  乙太網路絡（Ethernet）
　
•  記號環（Token ring）
　
•  非同步傳輸模式（Asynchronous Transfer Mode，ATM）
　
•  光纖技術（Fiber optics）
　
•  數據機（Modem）
　
這些通訊層同時位於用戶端和伺服端，11-1所示。如您所見，從 ODBC 呼叫到實際的傳輸需要很多的處理步驟。在本章中，我們不僅要介紹各種通訊層如何運作，也會討論疑難排除等相關問題。

　
 
圖11-1 SQL Server通訊層
SQL Server 應用程式介面
　
要與 SQL Server 通訊，您的應用程式必須使用 SQL Server 語言。其中一種方法是使用 SQL Server 提供的工具，諸如命令列的 OSQL 或 SQL Server Query Analyzer（ISQLW）。這些工具對於簡單查詢是很有用的，但對於日常的應用程式卻無能為力。例如，對於存貨處理、應付帳款和應收帳款，使用 GUI 程式就比鍵入很長的 SQL 陳述式效率更高。事實上，絕大多數這種應用程式的使用者都不知道 SQL 語言。通常，開發人員是使用 API 編寫可與 SQL Server 連線應用程式程式。API 提供能執行很多資料庫功能的呼叫。
SQL 提供幾種 API，包括 DB-LIB、ODBC 及 OLE DB。DB-LIB 是最原始的SQL Server API，它在 Microsoft SQL Server 與 Sybase 產品中都可使用。而 ODBC 是較新、也較具彈性的語言，可用來與各種關係型資料庫管理系統（RDBMS）的產品通訊。程式設計師也可利用 OLE DB 和其它的 API 來使用 SQL Server。本節將說明各種不同的 API。
DB-LIB 連結
　
自從 DB-LIB 在1988年首次公布，就已經成為 SQL Server 的一部分，它也是SQL Server 程式最原始的 API。儘管 DB-LIB 已經成為 SQL Server 的固有部分，但 ODBC 卻逐漸成為最主要的 API。C 與 C++ 語言以及 Microsoft Visual Basic 都支援 DB-LIB。DB-LIB 呼叫由應用程式代碼產生，然後透過網路連結庫傳輸到網路通訊協定層，然後到網路硬體層。
ODBC 連結
　
ODBC 是 Microsoft 開發的標準 API，用來便於 Windows PC 與各種不同的RDBMS 串連。透過 ODBC API 的程式，您可以使用相同的應用程式與多種不同的系統通訊。儘管 ODBC 是通用的，但它不見得對所有的 RDBMS 都是最有效率的 API。通常，對特定的 RDBMS 使用其內建的 API 會支援許多額外的功能，並且能最佳化。
透過在網際網路上使用 動態伺服器網頁 （Active Server Page，ASP），ODBC可用來支援其它的串連。支援包括 ActiveX 和 Microsoft Foundation Classes （MFC）以及 延伸標記語言 （Extensible Markup Language，XML）。在最近幾年中，ODBC 的支援層級急速增加，使得它成為支援多種 RDBMS 的 API。
不管您要串連的 RDBMS 是什麼系統，ODBC API 都有相同的形式，但是 ODBC 驅動程式就各有不同。對於每一個您要使用的 RDBMS，必須有一個唯一的 ODBC 驅動程式。此驅動程式把 ODBC 轉換成原生 RDBMS 網路通訊協定。更新版本的 RDBMS 通常都需要一個新的 ODBC 驅動程式以使功能最佳化，但兩個版本之間經常有相容性問題。因此，DB-LIB 通常使用一個特定的網路連結庫，而 ODBC 則使用多種協議的網路連結庫。網路連結庫有利於 ODBC 應用程式與伺服器的串連，而不需要選擇特定的協議。
ODBC 聯機集區
　
在應用程式中共用聯機的能力是由 ODBC 2.x 開始的。通常，每當一個不同的使用者登入應用程式時，應用程式將建立一個從應用程式層到資料庫的額外聯機。由於建立與維護這些連結到資料庫的聯機會佔用不少系統資源，因此這一過程的效率就變得很低。
一個聯機集區應用程式中其它的執行緒使用現存的ODBC聯機，而不需要一個不同的聯機。這個功能對於需要重複連結的 Internet 應用程式特別有用。若應用程式需要聯機集區，則在啟動時必須註冊該應用程式本身。
當應用程式要求一個 ODBC 聯機時，ODBC Connection Manager 會決定是使用新的聯機還是已經存在的聯機。應用程式並不知道這個決定，執行緒將繼續依照平常的方式工作。
一旦執行緒完成了 ODBC 連結，應用程式就會產生一個釋放連結的呼叫，這時，ODBC Connection Manager 將再度控管連結。如果連結在一定的時間內處於閑置狀態，它就會被關閉。
________________________________________
相關資訊
有關 ODBC 聯機集區的其它資訊，請參看 Microsoft ODBC Software Development Kit（SDK）。
________________________________________
其它API
　
您也可以使用其它的 API 來與 SQL Server 通訊。這些 API 包括 OLE DB、ODS（Open Data Serves，開放式資料服務）和其它諸如 SQL-DMF（SQL Distributed Management Framework，SQL分布式管理架構）、SQL-DMO（SQL Distributed Management Objects，SQL分散式管理物件）和 SQL-NS（SQL Namespace，SQL名稱空間）。通常，每一種協議支援一個特定的功能或佔一定的市場比例，並且都需要自訂的程式介面。
________________________________________
相關資訊
有關這些專門的API的相關訊息，請參考 SQL Server 2000 線上叢書。
________________________________________
網路連結庫
　
SQL Server 網路連結庫層，將 API 呼叫轉換成特定協議的呼叫，然後傳輸到網路通訊協定層。網路連結庫層在用戶端使用 用戶端網路公用程式（Client Network Utility） 來設定，在伺服器端則使用 伺服器網路公用程式（Server Network Utility） 。使用這些工具就能設定伺服器端的一個或多個 SQL Server 網路連結庫，或是用戶端系統的一個網路連結庫。用戶端設定的網路連結庫和伺服器端的相同，SQL Server 才能正常通訊。單一的網路可以同時容納數種通訊協議。舉例來說，同一個網路上，某些用戶端系統可能透過具名管道與 SQL Server 通訊，其它用戶端系統則可能透過 TCP/IP 與 SQL Server 通訊。
________________________________________
譯註
參考上例讀者可以瞭解，該 SQL Server 必須同時安裝具名管道和 TCP/IP，才能與使用者端正常通訊。
________________________________________
SQL Server 2000 伺服器網路公用程式
　
在伺服端系統上設定數種通訊協議是很常見的事。伺服器預設安裝的是具名管道與 TCP/IP 兩種網路連結庫。要在伺服器上設定更多的網路連結庫，可依下列步驟：
1. 從 開始 / 程式集 / Microsoft SQL Server 中，選擇 伺服器網路公用程式 ，顯示 SQL Server網路公用程式 對話方塊，11-2。
　
 
圖11-2 SQL Server網路公用程式對話方塊的「一般」卷標頁
2.  SQL Server網路公用程式 對話方塊有兩個卷標頁： 一般 及 通訊協議網路連結庫 。 一般 標籤頁用來 啟用 及 停用 網路通訊協議。啟用的通訊協議會排列在右手邊的清單內，SQL Server 會以其排列的順序來嘗試使用這些通訊協議。 一般 標籤頁允許下列操作：
o 要啟用額外的通訊協議，先在 停用通訊協議 的清單中選取一個或多個通訊協議，然後按一下 啟用 。
　
o 要停用通訊協議，先在 啟用通訊協議 的清單中選取一個或多個通訊協議，然後按一下 停用 。
　
o 要修改啟用通訊協議的屬性，選取通訊協議名稱然後按 屬性 。
　
o 可經由 SSL（Secure Sockets Layer，安全通道層）來啟用 強制通訊協議加密 。
　
o 可啟用 WinSock proxy 支援。
　
 通訊協議網路連結庫 卷標頁只用來顯示資訊。從這個標籤頁裡，您可以看到最進一次更改的網路連結庫的版本號碼及更改日期，11-3。

　
 
圖11-3 「SQL Server網路公用程式」對話方塊的「通訊協議網路連結庫」卷標頁
SQL Server 2000 用戶端網路公用程式
　
網路聯機的另一邊是用戶端系統，其設定方法與伺服器端相當類似。要設定用戶端系統，可於用戶端系統執行下列步驟：
1. 從 開始 / 程式集 / Microsoft SQL Server 裡，選擇 用戶端網路公用程式 ，顯示 SQL Server用戶端設定公用程式 對話方塊，11-4。其中大部分的功能跟 SQL Server網路公用程式 對話方塊一樣，不過用戶端公用程式提供更多的選項。
　
 
圖11-4 「SQL Server 用戶端設定公用程式」對話方塊的「一般」卷標頁
 SQL Server網路公用程式 對話方塊只是簡單地列出了一些網路連結庫及它們的聯機參數，但在 SQL Server用戶端設定公用程式 中您可以指定用戶端預設啟用的通訊協議及伺服器別名。在 一般 標籤頁中，啟用的通訊協議是依照其被使用的順序來排列。以圖11-4為例，啟用通訊協議的順序是 具名管道 、 TCP/IP 。因此，用戶端在與伺服器聯機時會先嘗試使用 具名管道 ，如果不成功，用戶端會接著使用 TCP/IP 來與伺服器聯機。如果仍然無法聯機，用戶端會產生一個聯機錯誤訊息。
 伺服器別名 允許您只使用一個指定的通訊協議，並忽略 啟用通訊協議 清單的設定。當其所指定的通訊協議無法成功聯機，用戶端不會再嘗試使用其它的通訊協議。如果您有多個伺服器，而使用的並不是同一種常用的通訊協議，您應將最常用的通訊協議放在啟用通訊協議清單的最上方。如此才可讓您在建立聯機時，嘗試再聯機的時間可以減到最低。
您可以簡單的啟用或停用通訊協議。要啟用通訊協議，從 停用通訊協議 的清單中選取需要的通訊協議，然後按一下 啟用 。要停用通訊協議，從 啟用通訊協議 的清單中選取要停用通訊協議，然後按一下 停用 。
您可以修改啟用通訊協議的屬性，從 依下列順序啟用通訊協議 清單中點選通訊協議然後按 內容 。不過，預設值對大多數的網路來說已是最佳化的選擇。
從 一般 標籤頁中，您也可啟用 強制通訊協議加密 ，以保護透過網路傳輸的資料。這個選項只有在啟用 多重通訊協議 才是可用的。
2. 要定義一個伺服器別名，按一下 別名 標籤頁。這個標籤頁會列出任何已存在的伺服器別名。要增加別名，按一下 新增 ，顯示 新增網路連結庫設定 對話方塊，11-5。
　
 
圖11-5 「新增網路連結庫設定」對話方塊
3. 在這個對話方塊中，您可以新增一台 SQL Server，並且指定其別名，以及該 SQL Server 使用您所指定的通訊協議。該通訊定必須已經在用戶端設定完成，並且必須在這邊指定以供該用戶端使用該特定的通訊協議。當 SQL Server 用戶端嘗試使用別名聯機時，將會使用該網路連結庫以及您在此處設定的聯機參數。除非您的應用程式嘗試透過別名與伺服器聯機，否則將會使用預設的啟用通訊協議。
4. 圖11-6是 SQL Server用戶端設定公用程式 的 資料連結庫選項 卷標頁。此卷標頁顯示 DB-LIB 的相關資訊以及下列複選框： ANSI到OEM的自動轉換 與 使用國際設定 。第一個選項讓您在與 SQL Server 通訊時，啟用資料連結庫自動將字元集從 ANSI 轉換至 OEM。第二個選項讓您從系統取得日期，時間與貨幣格式，而不是使用硬體編碼值。
　
 
圖11-6 SQL Server 用戶端設定公用程式的「資料連結庫選項」卷標頁
5.  SQL Server用戶端設定公用程式 也包括了一個 網路連結庫 卷標頁，11-7。與 SQL Server網路公用程式 的 網路連結庫 卷標頁一樣，此卷標頁僅顯示可用的網路連結庫及其版本號碼。
當用戶端系統上網路連結庫的順序設定不當時，就有可能發生許多聯機問題。在您遇到聯機問題的時候，請先檢查網路連結庫的設定。

　
 
圖11-7 SQL Server 用戶端設定公用程式的「網路連結庫」卷標頁
SQL Server 網路連結庫與通訊協議
　
之前已經提到，SQL Server 支援以下幾種網路連結庫： 具名管道 （Named pipes）、TCP/IP、 多重通訊協議 （Multiprotocol）、NWLink IPX/SPX、AppleTalk 以及 Banyan VINES。每種網路連結庫對應一個或一組不同的通訊協議。本節將簡單介紹每種網路連結庫。
在您的 SQL Server 上使用的網路通訊協議可能決定於企業標準或之前已經存在的系統。所有 SQL Server 命令與函數都支援全部的網路通訊協議，不過有些通訊協議的速度會比其它的要快一些。此外，有些通訊協議支援路由及名稱服務，有些則不支援。
具名管道
　
Microsoft 在幾年以前開發了具名管道通訊協議。具名管道支援兩種模式：本機和遠程。當用戶端和伺服器端在同一個系統中時，使用本機具名管道。當用戶端和伺服器端不在同一個系統中時，則使用遠程具名管道。經由具名管道建立聯機時，SQL Server 網路公用程式會決定使用本機具名管道或遠程具名管道。
具名管道是預設的用戶端通訊協議，也是 Windows NT 4.0 Server 和 Windows 2000 系統中預設的網路通訊協議。在 Windows95/98 系統中沒有具名管道。在這些系統中，伺服器端的網路連結庫是 TCP/IP、多重通訊協議和共用記憶體。儘管具名管道是一個很好的協議，但通常不用於大型網路，因為它不支援路由和網關器。比起其它的通訊協議，例如 TCP/IP，具名管道需要更多伺服器端與用戶端的互動性。
TCP/IP
　
TCP/IP 是最常用的網路通訊協議，因為它能於多種平台上運作，並已經被公認為網路標準，而且運作速度快。它也是 Internet 使用的網路通訊協定。TCP/IP 網路連結庫是 SQL Server 網路連結庫中效能最高的其中之一。TCP/IP 豐富的特色使它成為網路連結庫中一個不錯的選擇。
Multiprotocol
　
多重通訊協議是 SQL Server 7.0 所新增而保留至 SQL Server 2000。該網路連結庫實際上是幾個網路連結庫的組合。因此，它的效率不如單獨的特定網路連結庫，但它提供更大的彈性。多重通訊協議網路連結庫支援 TCP/IP、NWLink IPX/SPX 以及具名管道。使用多重通訊協議網路連結庫時，第一個使用的是用戶端和伺服器端均有的常用通訊協議。如果用戶端連結到運作不同通訊協議的伺服器上，多重通訊協議是一個理想的選擇。
NWLink IPX/SPX
　
當您將 SQL Server 2000 系統整合到 NetWare 網路中時，NWLink IPX/SPX是一個理想的通訊協議，因為它的運作可以完美的整合。IPX/SPX 已經存在一段很長的時間，並且是高效能和穩定的網路連結庫。
AppleTalk
　
AppleTalk 是 Apple Computers 開發的網路通訊協定，用於 Apple 系統。Windows NT 和 Windows 2000 支援 AppleTalk，並允許 Windows NT 和 Windows 2000 伺服器端能整合到 AppleTalk 環境的用戶端。
Banyan VINES
　
Banyan VINES 網路連結庫用於使用 VINES 的網路系統，允許將 Windows 用戶端和伺服器端與 VINES 環境整合。
VIA（Virtual Interface Architecture，虛擬介面架構）
　
此通訊協議來自兩個新趨勢：Giganet 與 ServerNet II。它對叢集伺服器來說是很好的選擇。
選擇網路連結庫
　
您所選擇的網路連結庫依您使用的網路通訊協議而定。當伺服器端和用戶端的網路連結庫不同步時，常常會發生聯機問題。如果您不能與伺服器聯機，請檢查兩端的網路連結庫定義。另外，使用另一個程式，例如 Ping 或 Microsoft Windows Explorer，來判斷問題是與 SQL Server 還是與網路本身有關。
網路組件與 SQL Server 效能
　
網路分成兩層：軟體層（包含網路通訊協議）和硬體層。以本書而言，硬體層包括必須的軟體驅動程式來驅動硬體。各層之間相互獨立，並且每一層可以有一個或多個組件。例如，可能在相同的網路卡上同時運作 TCP/IP 和 IPX/SPX，或者使用相同的協議來運作不同的網路卡。此結構11-8。

　
 
圖11-8 網路層級
每一個網路層級都有自己的特色和效能考慮。如上所述，選擇網路通訊協定或網路硬體組件有不同的理由；通常，選擇是基於商業原則和網路如何與別的系統串連而進行。本書並不想指定您一定要使用特定的協議或網路硬體。在本節，我們將從軟體和硬體的角度介紹影響 SQL Server 功能和效能的因素。
軟體層－網路通訊協定
　
如上所述，網路通訊協定包括具名管道、TCP/IP、NWLink IPX/SPX、AppleTalk 和Banyan VINES。基本上，所有的網路通訊協議與 SQL Server 的相關部分有相同的運作方式。如果出現引起功能性或運作上的網路問題，絕大多數發生在硬體層。另一方面，聯機問題也常常發生在網路連結庫層或網路通訊協議層。如果您在連結 SQL Server 用戶端到 SQL Server 2000 伺服器系統時出現了問題，試一試別的方式。例如，使用 Windows Explorer。如果您能透過 Explorer 連結到系統，但不能使用 SQL Server，那麼您的問題可能與 SQL Server 有關。請確定您嘗試聯機所使用的是適當的網路通訊協議。如果設定使用的是多重通訊協議，有時很難正確地指出您正在使用哪一個通訊協議。如果您能透過 Ping、Internet Explorer 或其它的外部程式來與伺服器聯機，那麼問題很可能發生在選擇了不當的網路連結庫。
無論您使用哪一個網路通訊協定，在硬體層都會出現許多運作問題。如果在網路限制的範圍內設定系統，以後碰到的問題將大大減少。
硬體層
　
您必須對硬體層有所瞭解才能判斷是否發生了網路運作問題。實體硬體層和通訊協議層是各自獨立的，亦即在不同的硬體網路裝置上可以使用各種不同的網路通訊協議。您所選擇的網路硬體決定了網路的效能，網路能處理的流量依網路的類型和速度而定。
網路頻寬
　
 網路頻寬 是指在一定的時間內透過網路傳輸的資料量。網路頻寬有時以網路硬體名稱來定義，例如 10baseT 或 100baseT，表示 10-Mbit/sec 或 100-Mbps。
然而，網路傳輸量的測量有時並不準確。在絕大多數的網路硬體中，當傳輸規模減小時，網路卡能傳輸的資料量也會減少，因為每一次網路傳輸的負荷是一定的。例如，傳輸 64 KB 資料所需要的負荷大約與傳輸 2KB 資料需要的負荷相同。RDBMS（包括 SQL Server）經常處理少量資料的傳輸。因此，您的伺服器能處理的資料量將可能少於網路硬體的頻寬。
乙太網路絡
　
儘管有許多種選擇，但最常見的網路硬體仍可能是乙太網路絡。最近幾年，乙太網路絡的速度大大地增加，並且在未來將持續上升。Xerox、DEC 和 Intel 在1976年開發了乙太網路絡。早期使用的是同軸電纜，乙太網路絡的頻寬為3 Mbps。在 10baseT 技術問世後，網路頻寬增加到 10 Mbps。隨後 100baseT 技術使網路頻寬增加到 100 Mbps。不久的將來，當 Gigabit 乙太網路絡成熟後，網路頻寬將可增加到 1-Gbps。下面列出了各種頻寬之間的比較。
網路類型  頻寬
同軸電纜乙太網路絡 3 Mbps
10BaseT 10 Mbps
100BaseT 100 Mbps
Gigabit乙太網路絡 1000 Mbps
雖然乙太網路絡的頻寬狂飆猛漲，但乙太網路絡仍有一些問題：多個乙太網路絡卡可能會同時傳輸資料，而兩個或多個網路卡若正好同時傳輸資料，就會發生 碰撞 （collision）。發生碰撞的每個網路卡將會等待一段時間，然後試著重新傳輸資料。儘管時間很短，但它會不斷累加。發生的碰撞越多，等待重新傳輸的時間也越長。
網路流量增加時，碰撞發生的機率也會增加。如果流量已接近網路的容量，發生碰撞的機率將會陡升，11-9所示。碰撞的發生會導致效能的降低。因此，監控網路流量並注意碰撞是非常重要的事。例如，您可以遵循一個概略的法則：傳輸串流量不要超過網路頻寬的 75%。當然，在尖峰時刻會超過此值，但不應超過此值太長的時間。

　
 
圖11-9 碰撞機率與網路使用率的比較
記號環
　
記號環網路透過記號傳遞的機制，使環中的每一個成員都有機會與別的成員通訊。記號每次僅允許網路中的一個系統進行資料轉送。由於這種體繫結構，您可以利用網路的整個頻寬，而不會在通訊中引起過度的延遲時間。
記號環網路像乙太網路絡一樣，不同的技術提供了不同的網路頻寬，如下表所示。但由於記號環網路是一連串的點對點聯機，不會發生碰撞，因此幾乎能使用整個頻寬。如同乙太網路絡技術，記號環網路技術也在持續不斷地改進。
網路類型  頻寬
IEEE 802.3 記號環 1, 4, or 16 Mbps
IEEE 802.5 100 Mbps
Gigabit 記號環 1000 Mbps
還有許多別的網路硬體可供選擇，包括ATM及光纖等。
網路監控
　
例如我們之前所看到的，使用的網路硬體類型和速度可能會影響資料庫系統的整體效能。如果超過了網路頻寬，資料轉送就會出現瓶頸而使得傳輸發生延遲。延遲則會降低整個系統的效能。
您可以安裝的硬體為基礎來推算一下網路的最大效能，並可對效能問題的癥結有個概念。使用這份資訊，通常您只要新增網路卡就能解決問題。尋找網路問題的首要步驟是周期性地監控網路，您可以使用收集的資料來判斷是否有網路問題，進而發展可行的解決方案。
監控效能
　
監控網路不如想象中容易。通常需要購買額外的網路監控硬體或軟體才能有效地監控網路。下面討論的幾個因素，可讓您判斷是否有必要購置這些監控裝置。
首先，在您實體網路上所有的資料庫伺服器端和用戶端並不一定使用相同的通訊協議。例如，在乙太網路絡上執行 TCP/IP 的系統實際上只能（在作業系統層級上）看到 TCP/IP 的流量，IPX/SPX 封包將在裝置驅動程式層上被過濾掉。通常，網路監視軟體需要自訂的裝置驅動程式和網路層級。
再者，網路卡將過濾掉不適合您特定機器的資料；因此，不是所有的網路資料都會被傳輸到驅動程式或作業系統。為觀察所有的網路活動，應該使用自訂的裝置驅動程式和網路層級。如果不作修改，一般的工作站就不能監控實體網路上所有的流量。
安裝了網路監控硬體、軟體或兩者都安裝之後，您就能清楚地瞭解您的網路處理的傳輸串流量。此流量可能導因於您的系統，但有時也可能是由路由或設定問題所引起的網路流量。網路硬體問題的疑難排解已在本書的範圍之外。安裝了網路監控系統之後，我們來檢查下面各項：
•   利用率 透過網路傳輸的資料量是多少？這個資料量與網路硬體的最大頻寬相比如何？
　
•   封包大小 網路傳輸的封包有多大？是大型封包效率較高，還是小型封包呢？
　
•   碰撞（如果發生） 正在發生大量的碰撞嗎？如果是，為什嗎？
　
•   錯誤 是否有很多未完成的傳輸需要重傳？這可能是有問題的網路卡或串連裝置的警示。
　
判斷是否有問題
　
在您搜集了相關的效能資訊之後，您必須判斷網路是否有問題，這並不容易。網路效能問題通常不會顯示出錯誤訊息，而直接使整體效能降低。為了判斷是否有問題發生，您應該比較由監控得到的資料與原先提供的設定資訊。
不要超過網路頻寬的 75% 是一個好辦法。如果大多數的網路傳輸量都很小，您可能想進一步減少傳輸量的百分比，因為大量的小型傳輸比少量的大型傳輸量需要更多的負荷。在乙太網路絡中，減少傳輸次數也會減少碰撞，因此降低了網路請求的回應時間，使整個網路加快。
有些問題也許比頻寬問題更嚴重。您應該檢查高比率的碰撞和錯誤。如果您在75% 的臨界值附近，而且碰撞很多，那麼您可能已經接近網路的瓶頸。相對地，如果網路流量小而碰撞又很多，您很可能有硬體的錯誤發生。
您也應該檢查傳輸錯誤，傳輸錯誤暗示著硬體可能有問題。有問題的硬體可能是網路中的任何部分，從網路卡、電纜、路由器或橋接器等等。一旦確定有問題，就應該請教網路專家。
找出網路問題的解決方案
　
根據特定的情況，有幾種方法來解決頻寬問題。您可以購買更多或不同的硬體，將網路分段，甚至重新設計應用程式等。
一種減少網路使用百分比的方法是增加頻寬。從 10 baseT 升級到 100 baseT 可以增加十倍的頻寬。這個方法很簡單，而且容易，但它很昂貴。可以試試其它的替換辦法。
如果網路流量太大，就應該以部門或工作群組為基礎，把網路分成若干個子網路。透過子網路，您可以在每一個辦公室或部門建立自己的網路，而不是整個公司都在同一個網路上。這個方法可以降低單一網路上的系統數量，因此可減少流量。有時候是網路已經變慢一段時間了，但在發生問題之前您一直未曾注意到增加的流量。對於減少網路壅塞的問題，使用子網路或許是最好的辦法。
另一個解決辦法是從功能的角度來觀察網路的使用方式。網路是否合理地使用呢？應用程式是否傳回了太多的資料？檢查一下 SQL Server 用戶端程式，確保它們沒有請求多於需要的資料列。如果使用者很多，那麼使用目標明確的查詢，傳回最少資料列數的資料以減少網路流量是最簡單的方法。
如您所見，可能有各式各樣的問題，也有各種不同的解決方案。不要擔心這些可能出現的問題。應用程式的邏輯錯誤有時會顯示成網路頻寬的問題，排程也可能會出現問題，例如，不要在一天中最忙的時候備份網路。
本章總結
　
在本章中，學習了 SQL Server 網路的基本概念以及如何設定網路上的 SQL Server。瞭解了 SQL Server 使用的分層系統，從 API 到網路連結庫、網路通訊協定，最後是網路硬體。這些層級彼此相互獨立，但它們透過各種設定組合在一起。在選擇 API、網路連結庫、網路通訊協定，甚至網路硬體時，有很大的彈性。記住在發生運作問題之前，定期檢查網路流量以避免運作問題發生。我們將在 第36章 討論一般的運作問題；在 第12章 ，我們將轉換主題：學習如何使用 Microsoft Cluster Server Services 來設定 SQL Server 以獲得高效能的系統。