MS SQL 磁碟空間不足 - 可以使用 FileGroups 來釋放一些空間嗎？

問題

我們有一個帶有 1TB 附加磁碟（在 Azure 上）的 Sql Server 2014，磁碟空間不足。我們還剩下大約 20GB（可能還有幾週的空間）。因此，我們需要將一些數據從 CURRENT 磁碟移到 NEW 磁碟上。

細節

伺服器：

Microsoft SQL Server 2014 - 12.0.2548.0 (X64) 
   Jun  8 2015 11:08:03 
   Copyright (c) Microsoft Corporation
   Web Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: ) (Hypervisor)

MS-SQL 2014 安裝在經典Azure VM 上。此 VM 位於經典VNET 中。儲存檔也很經典。因此，我們不能只擴展現有磁碟。MS-Support 表示，如果我們希望利用現代 Azure 儲存允許調整磁碟大小、使用更新的 SSD 磁碟等，我們需要更新所有這些。TL;DR; 我們不能讓這個離線幾個小時，包括通過 IP 地址與 VM 通信的所有其他子系統。現在，不要把這變成一場盛大的狂歡……這是我們被賦予的工作，並且需要稍後解決所有這些問題。

所以現在，一個想法嘗試和利用 FILEGROUPS 並將一個或多個表移動到 FILEGROUP 並將這個 FILEGROUP 推送到我們附加的另一個 DISK 上。

所以這裡的問題是：

• 首先，這真的是一個非常瘋狂和蹩腳的想法嗎？
• 如果它是廢話但沒問題，那麼使用 FILEGROUPS 實際上會將數據從目前磁碟移動到新磁碟（這會釋放幾乎已滿的目前磁碟上的一些磁碟空間）？
• 如果這仍然可能，移動這些表是否意味著數據被鎖定/不可用……這意味著仍然回到我們最初的問題:(
• 日誌呢？移動這些數據意味著日誌只是得到這個的副本？（我相信我們正在做每小時和每週的備份）。

如果數據很小也沒關係，但這裡快速瀏覽一下我們的一些表……

第一個表很大（相對於其餘數據）。750GB左右。

我正在考慮在結果圖像中移動第 4 行的第 2 行、第 3 行。還記得我說過的基礎設施都是舊經典的東西嗎？這意味著 HD 既舊又慢，因此複製數據也可能需要一些時間。

例如，我只是嘗試將.mdf‘s（此數據庫有 1 個主 mdf 和 2 個其他小 mdf）從 OLD 複製到新磁碟。有一個 24 小時的快速 ETA。

讓網站離線幾個小時是完全可以接受的。當我們的客戶睡著時，我們可以將東西離線。但是…… 24小時……那很痛。24 小時的想法是一個簡單的測試：

• 創建新的 2TB 磁碟（如果可能）
• 關閉sql伺服器。
• 將 mdf + 日誌文件複製到新磁碟。（24小時左右）
• 將文件組從舊位置指向新位置
• 再次啟動sql server。

現在，我們對想法持開放態度，我知道堆棧交換不是“意見”的網站，所以我試圖通過建議的答案來保持目標並獲得回饋……但我們是開放的其他解決方案以減少離線時間。

所以 - 任何人都可以幫忙嗎？

更新 1

這是此數據庫的目前文件的螢幕截圖。

雖然它可以工作，但沒有必要將表移動到新的文件組。

如果您只是將文件添加到數據庫的現有文件組中，SQL Server 將開始使用新文件。

當文件組有多個文件時，SQL Server 使用“比例填充算法”。因此，如果您將新文件（可能在不同的捲上）添加到文件組，SQL Server 會將新數據寫入該文件組，直到它與目前文件的填充百分比相同。

您將表移動到新文件組的想法應該可行。它將在移動期間使這些表離線，但隨後它們將再次可用於查詢。您可以通過策略性地一次一個地執行它們來潛在地限制停機時間。

請注意，如果您使用的是 Enterprise Edition，則可以利用此版本的ONLINE索引操作版本來保持表可用於查詢。由於您使用的是網路版，所以這不是一個選項。

在這裡，我將創建一個數據庫，其中包含一個 1GB 的表：

USE [master];
GO
CREATE DATABASE [257236];
GO
USE [257236];
GO

CREATE TABLE dbo.OneGigTable
(
   Id int IDENTITY(1,1) NOT NULL,
   [BigColumn] nvarchar(max) NOT NULL,

   CONSTRAINT PK_OneGigTable PRIMARY KEY (Id)
);
GO

INSERT INTO dbo.OneGigTable
SELECT TOP (16777216) 
   N'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
FROM master.dbo.spt_values v1
CROSS JOIN master.dbo.spt_values v2
CROSS JOIN master.dbo.spt_values v3;
GO

你可以看到這個數據文件（在預設的主文件組上）大部分都是滿的：

接下來，我將添加一個新文件組，並將一個文件添加到該組。請注意，您需要將 設置為FILENAME新磁碟上的路徑。您還應該根據您希望移入其中的數據量適當調整其大小：

ALTER DATABASE [257236]
ADD FILEGROUP NewFileGroup;
GO

ALTER DATABASE [257236]
ADD FILE
(
   NAME = NewFile_1,
   FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL12.SQL2014\MSSQL\DATA\NewFile_1.ndf',
   SIZE = 1024MB
)
TO FILEGROUP NewFileGroup;
GO

現在，在 SSMS 中執行“磁碟使用情況”報告，我可以看到新文件大部分是空的：

現在我將在新文件組上重建表：

CREATE UNIQUE CLUSTERED INDEX PK_OneGigTable
ON dbo.OneGigTable (Id)
WITH (DROP_EXISTING = ON)
ON NewFileGroup;

現在您可以看到主文件組大部分是空的，並且所有數據都已移動到新文件組：

引用自：https://dba.stackexchange.com/questions/257236