SQL Server 2008 中對於 Database Engine 功能的行為變更

在 SQL Server 2008 中，資料分割資料表設計改良在資料分割資料表的查詢處理期間會提供優於舊版 SQL Server 2005 的平行處理原則。這項重新設計是依據個別產品所產生，只能配置雙向聯結。SQL Server 2008 中雙向配置聯結的查詢計畫看起來與 SQL Server 2005 中相同，而且效能也可與 SQL Server 2005 相比擬。如果聯結中包含具有對齊之資料分割的其他資料表，將會選取不同的計畫，例如與第三個資料表之雜湊聯結所跟隨的雙向配置聯結。兩個以上資料表之間的配置聯結並不常見，而且配置聯結不會因為 SQL Server 2008 中的平行處理原則改良而受益。但是，如果您有一個查詢，而 SQL Server 2005 針對此查詢執行三向 (或多向) 配置聯結，則如果記憶體數量相對於資料表大小而言很小，則此查詢在 SQL Server 2008 中的執行速度可能會比較慢。在此情況下提升效能的方式包括增加可用的記憶體數量及重新撰寫查詢，好讓個別資料分割單獨聯結，然後再將結果結合在一起。如需有關配置聯結的其他資訊，請參閱＜資料分割資料表和索引上的查詢處理增強功能＞。

SQL Server 具有用來處理查詢的全新最佳化功能，其中包含可使用雜湊聯結和點陣圖篩選的星型聯結。 當某個查詢處理大量資料 (來自於星狀結構描述中的聯結事實資料表到維度資料表) 時，使用全新最佳化功能的查詢計畫可以更快速地執行。 

因此，如果現有查詢適合星型聯結模式，您可以看到現有查詢的新查詢計畫。當這個計畫的預估指出查詢效能將會提高時，查詢最佳化工具會選擇這個計畫。但是，如果成本預估中使用的統計資料不正確，而當另一個計畫比較快速時，查詢最佳化工具可能會選擇星型聯結最佳化。

如果 max degree of parallelism 組態選項或 MAXDOP 索引選項設定為 1，查詢最佳化工具將不會使用星型聯結最佳化，而且您將不會得到全新星型聯結最佳化所提供的好處。如果查詢執行系統只利用一個執行緒來分派以平行計畫最佳化的查詢，則可能會從多重點陣圖篩選星型聯結計畫中移除某些點陣圖篩選。例如，當您從兩個執行緒減少到一個執行緒時，這項變更可能會降低執行速度，而超乎原本所預期的情況。

星型聯結最佳化只適用於 SQL Server Enterprise、Developer 和 Evaluation 版本。如需有關點陣圖篩選的詳細資訊，請參閱＜透過點陣圖篩選讓資料倉儲查詢效能最佳化＞。如需有關如何解譯包含點陣圖篩選之查詢計畫的詳細資訊，請參閱＜解譯包含點陣圖篩選的執行計畫＞。如需有關星型聯結最佳化的詳細資訊，請參閱 TechNet Magazine 文件＜資料倉儲查詢效能＞。

SQL Server 2008 會在聯結的外部端只有幾個資料列時，加速巢狀迴圈聯結的平行處理原則。 在 SQL Server 2005 中，當有多個執行緒可用時，會從聯結的外部端配置一頁的資料列給每一個執行緒。 如果只有幾個資料列，這些資料列可能位於相同的頁面。 在這類情況下，只會利用一個執行緒，而且會喪失平行處理原則的潛在好處。SQL Server 2008 會辨識這類案例，並導入「交換運算子」(Exchange Operator) 針對每一個執行緒各配置一個資料列，以便充分利用所有可用的 CPU。 平行處理原則增加表示 CPU 耗用量將會暫時提高 (相較於 SQL Server 2005)，但是查詢的執行速度會更快。 只有當外部資料列的數目很小而且預估查詢的成本夠大，而足以從額外的平行處理原則獲益時，才會看到這項新的行為。 如果預估查詢成本很小，或者外部端的基數預估值超過 1000，則 SQL Server 將會針對每一個執行緒各配置一頁，就如同 SQL Server 2005。 如需有關交換運算子與平行查詢處理的詳細資訊，請參閱＜平行查詢處理＞。

SQL Server 2008 改變了在資料分割資料表和索引上處理查詢的方式。在資料分割物件上，使用 USE PLAN 提示的查詢可能包含無效的計畫。我們建議您在升級到 SQL Server 2008 之後，最好使用以下程序。

在查詢中直接指定 USE PLAN 提示時：

1. 從查詢中移除 USE PLAN 提示。

2. 測試查詢。

3. 如果最佳化工具未選取適當的計畫，請微調查詢，然後使用所要的查詢計畫指定 USE PLAN 提示。

在計畫指南中指定 USE PLAN 提示時：

1. 使用 sys.fn_validate_plan_guide 函數檢查計畫指南是否有效。或者，您也可以使用 SQL Server Profiler 中的 Plan Guide Unsuccessful 事件來檢查是否有無效的計畫。

2. 如果此計畫指南無效，請捨棄此計畫指南。如果最佳化工具未選取適當的計畫，請微調查詢，然後使用所要的查詢計畫指定 USE PLAN 提示。

如需有關在資料分割物件上進行查詢處理的詳細資訊，請參閱＜資料分割資料表和索引上的查詢處理增強功能＞。

在 SQL Server 2005 中，Resource 資料庫的資料和記錄檔相依於 master 資料庫之資料檔的位置。因此，如果移動 master 資料庫，您也必須將 Resource 資料庫移到相同位置。在 SQL Server 2008 中，此相依性不存在。您可以在不移動 Resource 資料庫的情況下，移動 master 資料庫檔案。

在 SQL Server 2008 中，Resource 資料庫的預設位置是 <磁碟機>:\Program Files\Microsoft SQL Server\MSSQL10.<instance_name>\Binn\。此 Resource 資料庫無法移動。

在舊版 SQL Server 中，tempdb 資料庫的 PAGE_VERIFY 資料庫選項設定為 NONE 而且無法修改。在 SQL Server 2008 中，新安裝 SQL Server 之 tempdb 資料庫的預設值為 CHECKSUM。升級 SQL Server 安裝時，預設值仍然維持 NONE。您可以修改此選項。我們建議您針對 tempdb 資料庫使用 CHECKSUM。

SQL Server 2008 包含 XML 結構描述支援的幾項擴充，包括 lax 驗證的支援、改良式 xs:date、xs:time 和 xs:dateTime 執行個體資料的處理，並加入了 list 和 union 類型的支援。在大多數情況下，這些變更並不會影響升級的使用體驗。但是，如果您在 SQL Server 2005 中使用允許 xs:date、xs:time 或 xs:dateTime 類型 (或任何子類型) 值的 XML 結構描述集合，則當您將 SQL Server 2005 資料庫附加到 SQL Server 2008 時會發生下列升級步驟。

1. 對於每一個 xml 資料行而言，如果它在 XML 結構描述集合中具類型 (該集合包含的元素或屬性具有 xs:anyType、xs:anySimpleType、xs:date 類型或它的任何子類型、xs:time 或它的任何子類型或是 xs:dateTime 和它的任何子類型)，或是為包含這些類型之任何一項的 union 或 list 類型時，便會發生下列情況：

   1. 資料行上的所有 XML 索引都將會停用。

   2. 所有的 SQL Server 2005 值都將會繼續以 Z 時區來表示，因為這些值已經正規化成 Z 時區。

   3. 任何小於第一年一月一日的 xs:date 或 xs:dateTime 值將會導向執行階段錯誤的條件如下：當重建索引時，或是針對包含該值的 xml 資料類型執行 XQuery 或 XML-DML 陳述式時。

2. xs:date 或 xs:dateTime Facet 中的任何負數年份或是 XML 結構描述集合中的預設值，將會自動更新為基底 xs:date 或 xs:dateTime 類型所允許的最小值。例如，xs:dateTime 的 0001-01-01T00:00:00.0000000Z。

請注意，您仍然可以使用簡單 SQL SELECT 陳述式來擷取整個 xml 資料類型，即使它包含負數年份也是一樣。我們建議您使用新支援範圍中的年份來取代負數年份，或是將元素或屬性的類型變更為 xs:string。如需詳細資訊，請參閱＜比較不具類型的 XML 與具類型的 XML＞。

SQL Server 2005 中不支援 lax 驗證，因此會針對 anyType 類型的元素套用 Strict 驗證。在 SQL Server 2008 中，anyType 類型的元素內容將會使用 lax 驗證加以驗證。如需詳細資訊，請參閱＜萬用字元元件和內容驗證＞。