SQL Server On Linux（23）—— SQL Server On Linux性能（9）——性能進階簡介——分區（3）

本人新書上市，請多多關照：《SQL Server On Linux運維實戰 2017版從入門到精通》

小結：

1. 分區方案是把分區函數映射到物理文件組的過程。
2. 可以使用ALL關鍵字把所有分區映射到一個文件組中。
3. 可以使用Primary關鍵字把分區映射到數據庫的主文件組中。
4. 修改分區方案意味着指定哪個文件組爲NEXT USED。
5. 使用SPLIT和MERGE管理分區的文件組時，要注意哪些文件組受到影響。
6. 對於PaaS（SQL Azure）而言，分區方案只能使用Primary文件組。

分區方案

創建分區方案

本文的內容對於Linux上的SQL Server是通用的。因爲文件組還是一個邏輯概念，底層的文件比如.mdf/.ndf/.ldf纔是物理文件，纔是需要考慮Windows/Linux和PaaS環境下的不同，所以你可以看到這裏沒有出現文件路徑的信息。

  當配置好分區函數之後，接下來就是分區方案的配置，分區方案（Partition scheme，注意是scheme不是schema）是把分區映射到具體的文件組上，至於文件組裏面有多少個文件，則不是它關心的內容，不過不管是否做了分區，當需要大容量載入的時候，多個文件分佈在不同的物理驅動器上時，性能通常會比單文件更好。這也是爲什麼常規建議是使用多個數據文件（注意日誌文件並沒性能方面的提升）來提高並行讀寫。
  下面是創建分區方案並綁定對應分區函數（PF_RIGHT）的例子，它使用兩個文件組來映射。

CREATE PARTITION SCHEME PS_RIGHT AS PARTITION PF_RIGHT TO (FileGroup1, FileGroup2);

  技術上並沒有強制文件組一定要與分區函數中的邊界值一一對應，不過在理想情況下，單一文件組對應一個分區是最好的。如果爲了省事或者對於SQL Azure這類PaaS平臺，可以使用ALL關鍵字來把分區放到單一文件組或者使用PRIMARY關鍵字把所有分區放到數據庫的主文件組中。
比如:

CREATE PARTITION SCHEME PS_HASH_BY_VALUE 
AS PARTITION PF_HASH_BY_VALUE
ALL TO ([PRIMARY]);
GO

-- Show the scheme
SELECT * FROM sys.partition_schemes
GO

修改分區方案

  和分區函數對比，分區方案的可調整性不強，你可以修改的就是指定哪個文件組會被用於下一個分區，比如把FileGroup5作爲下一個分區對應的文件組，可以這樣：

ALTER PARTITION SCHEME PS_RIGHT NEXT USED FileGroup5;

  如果你預先指定了非常多的文件組，然後後來你不想用它們了，可以刪除這些文件組（分區層面上），只需要不指定文件組名即可：

ALTER PARTITION SCHEME PS_RIGHT NEXT USED;

  使用ALTER PARTITION FUNCTION拆出來的新分區會映射到標誌爲NEXT USED的文件組上。

SPLIT/MERGE

  分區方案也有SPLIT關鍵字，當分區函數使用SPLIT或者MERGE來添加或刪除邊界值時，SQL Server自動調整分區方案中的文件組。但是前提需要有一個文件組被標記爲NEXT USED。
  比如上面的把FileGroup5設爲NEXT USED，那麼後續的新分區都會全部落到FileGroup5中。所以在這種場景下，我們首先需要瞭解到底哪個文件組被標記爲NEXT USED。
  Merge的行爲也是類似的，會把分區合併到其他文件組中，處於性能考慮，在MERGE時，應該指定合併到鄰近的文件組中。

管理文件組

  基於文件組備份和還原的考慮，通常會建議使用多個文件組來支持分區（SQL Azure只使用Primary）。當使用多文件組時，每個文件組最少要有一個數據文件，並且每個文件組對應一個分區。如果要提升性能，對於本地版的SQL Server，可以把文件組分佈在物理驅動器上。
  SPLIT選項假設已經有一些文件組被設爲NEXT USED，在MERGE的時候，文件組也會被清理，所以在SPLIT和MERGE的時候，要注意並跟蹤哪些分區受到了影響。這是其中一個使用分區功能帶來的“壞處”，加大了運維的工作量。下面的一些腳本可以用來幫助你瞭解當前分區情況：

SELECT 
	OBJECT_NAME(SI.object_id) AS PartitionedTable
	, DS.name AS PartitionScheme
	, PF.name AS PartitionFunction
	, P.partition_number
	, P.rows
FROM sys.partitions AS P
JOIN sys.indexes AS SI
	ON P.object_id = SI.object_id AND P.index_id = SI.index_id 
JOIN sys.data_spaces AS DS
	ON DS.data_space_id = SI.

data_space_id
JOIN sys.partition_schemes AS PS
ON PS.data_space_id = SI.data_space_id
JOIN sys.partition_functions AS PF
ON PF.function_id = PS.function_id
WHERE DS.type = ‘PS’
AND OBJECTPROPERTYEX(SI.object_id, ‘BaseType’) = ‘U’
AND SI.type IN(0,1);

SELECT
OBJECT_NAME(SI.object_id) AS PartitionedTable
, DS.name AS PartitionScheme
, PF.name AS PartitionFunction
FROM sys.indexes AS SI
JOIN sys.data_spaces AS DS
ON DS.data_space_id = SI.data_space_id
JOIN sys.partition_schemes AS PS
ON PS.data_space_id = SI.data_space_id
JOIN sys.partition_functions AS PF
ON PF.function_id = PS.function_id
WHERE DS.type = ‘PS’
AND OBJECTPROPERTYEX(SI.object_id, ‘BaseType’) = ‘U’
AND SI.index_id IN(0,1);

SELECT
OBJECT_NAME(SI.object_id) AS PartitionedTable
, DS.name AS PartitionScheme
FROM sys.indexes AS SI
JOIN sys.data_spaces AS DS
ON DS.data_space_id = SI.data_space_id
WHERE DS.type = ‘PS’
AND OBJECTPROPERTYEX(SI.object_id, ‘BaseType’) = ‘U’
AND SI.index_id IN(0,1);

  前面提到的主要是針對本地版的SQL Server，當使用雲數據庫（SQL Azure）時，有一些小細節會有所不一樣。這裏簡單列一下以便讀者在後續使用時引起注意：

1. 最重要的是在雲環境下我們只能使用Primary文件組。
2. SPLIT RANGE函數用來完成NEXT USED時分區號的計算。

後面我會在Azure上做一個完整的演示，這裏先介紹基礎信息。