幾個(gè)星期前，SQL Server 2016的最新CTP版本已經(jīng)發(fā)布了：CTP 2.4(目前已經(jīng)是CTP 3.0)。這個(gè)預(yù)覽版相比以前的CTP包含了很多不同的提升。在這篇文章里我會(huì)談下對于SQL Server 2016，TempDb里的顯著提升。

TempDb定制

在SQL Server 2016安裝期間，第一個(gè)你會(huì)碰到的改變是在安裝過程中，現(xiàn)在你能配置TempDb的物理配置。我們可以詳細(xì)看下面的截屏。

微軟現(xiàn)在檢測幾個(gè)可用的CPU內(nèi)核，基于這個(gè)數(shù)字安裝程序自動(dòng)配置TempDb文件個(gè)數(shù)。這個(gè)對克服閂鎖競爭問題（Latch Contention problem）非常重要，通常當(dāng)你運(yùn)行TempDb時(shí)，只有一個(gè)數(shù)據(jù)文件會(huì)發(fā)生。這里安裝向?qū)褂孟铝泄剑?/p>

當(dāng)你有小于等于8個(gè)CPU內(nèi)核，你會(huì)獲得和你CPU內(nèi)核數(shù)一樣的TempDb數(shù)據(jù)文件數(shù)。如果你有超過8個(gè)CPU內(nèi)核，你會(huì)得到開箱即用的8個(gè)TempDb數(shù)據(jù)文件。

我在不同的配置上測試了安裝向?qū)?，下表總結(jié)了TempDb數(shù)據(jù)文件的不同個(gè)數(shù)。

CPU內(nèi)核　　　　TempDb數(shù)據(jù)文件

2　　　　　　　　2

4　　　　　　　　4

8　　　　　　　　8

32　　　　　　　 8

這是一個(gè)巨大的進(jìn)步！當(dāng)我進(jìn)行SQL Server健康檢查時(shí)，TempDb只有一個(gè)數(shù)據(jù)文件，會(huì)有一些閂鎖競爭問題（Latch Contention problem）是常見的。

如果在向?qū)Ю锬闾峁┒鄠€(gè)數(shù)據(jù)路徑，你可以在各個(gè)文件夾之間循環(huán)（round-robin）分配。有一點(diǎn)我不喜歡的是，新的配置8MB的初始大小和64MB的自動(dòng)增長率。

分配和自動(dòng)增長

在SQL Server 2016之前，很多人使用1117和1118跟蹤標(biāo)記來定義SQL Server在數(shù)據(jù)庫里如何分配頁，和如何在多個(gè)數(shù)據(jù)文件間處理自動(dòng)增長操作。在以前的SQL Server版本里，臨時(shí)表的數(shù)據(jù)頁總分配在所謂的混合區(qū)（Mixed Extends），它大小是64kb在多個(gè)數(shù)據(jù)庫對象（像表和索引）間共享。

使用這個(gè)方法微軟保證小表保持小，因?yàn)閿?shù)據(jù)庫的第1個(gè)8頁總在混合區(qū)分配。接下來的頁（第9頁開始）在所謂的統(tǒng)一區(qū)（也是64k大?。├锓峙洹Ｃ看文憬o數(shù)據(jù)庫對象分配一個(gè)統(tǒng)一區(qū)，對象本身立即增長64kb。

當(dāng)你啟用SQL Server的1118跟蹤標(biāo)記，對于整個(gè)SQL Server實(shí)例，只在統(tǒng)一區(qū)分配，混合區(qū)會(huì)被忽略。使用這個(gè)方法是可以減少在SGAM（共享全局分配映射（Shared Global Allocation Map）頁，管理混合區(qū)）頁上的閂鎖競爭問題（Latch Contention problem）。

在SQL Server 2016里TempDb分配總在統(tǒng)一區(qū)里發(fā)生，而不使用混合區(qū)——不需要啟用任何跟蹤標(biāo)記。除臨時(shí)表外的分配還是使用混合區(qū)。下面的例子展示了在臨時(shí)表7個(gè)分配的頁直接存儲(chǔ)在統(tǒng)一區(qū)，而完全不使用混合區(qū)。

USE tempdb
GO

CREATE TABLE #HelperTable
(
  Col1 INT IDENTITY(1, 1) PRIMARY KEY NOT NULL,
  Col2 CHAR(8000) NOT NULL
)
GO

-- Insert 7 records, this allocates 7 pages in tempdb
INSERT INTO #HelperTable VALUES (REPLICATE('a', 8000))
GO 7

-- Enable DBCC trace flag 3604
DBCC TRACEON(3604)
GO

-- Retrieve the temp table name from sys.tables
SELECT name FROM sys.tables
WHERE name LIKE '#HelperTable%'
GO

-- Retrieve the first data page for the specified table (columns PageFID and PagePID)
DBCC IND(tempdb, [#HelperTable________________________________________________________________________________________________________00000000000B], -1)
GO

-- Dump the IAM page of the table TestTable retrieved by DBCC IND previously
-- No pages are allocated in Mixed Extents, a complete Uniform Extent is allocated.
DBCC PAGE (tempdb, 5, 33, 3)
GO

-- Clean up
DROP TABLE #HelperTable
GO

在過去1117跟蹤標(biāo)記和TempDb結(jié)合進(jìn)行同時(shí)自動(dòng)增長操作。確保文件在同個(gè)區(qū)里同時(shí)增長非常重要。不然成比例的填充算法(proportional fill algorithm)不能發(fā)揮應(yīng)有的作用。使用SQL Server 2016，你就直接有1117跟蹤標(biāo)記的這個(gè)功能，而不需要啟用。

小結(jié)

花了很長時(shí)間后，微軟終于開始在SQL Server安裝向?qū)Ю镞M(jìn)行更好的默認(rèn)配置。根據(jù)可用CPU核心數(shù)配置TempDb是個(gè)巨大的進(jìn)步。我們來看看下個(gè)版本會(huì)提供根據(jù)實(shí)際情況能配置MAXDOP，并行開銷閾值和服務(wù)器最大內(nèi)存等等...