SQL SERVER定期轉移海量資料方案

sql server定期轉移海量資料方案

【背景】

有個表比較巨大，每天新增約500萬條記錄。只保留最新7天資料，每天定期移走過期記錄，歸併到歷史庫。採用insert，delete的方法，消耗時間越來越長，平均達到45分鐘，期間該錶和歷史庫根本無法訪問。

【方案】

1、採用分割槽切換，快速清除舊資料

將表按日進行分割槽，每日乙個區。

比如今天是2023年8月8日，有

--分割槽函式

create partition function[crpfn](smalldatetime) as range left for values (n'2010-08-01t00:00:00.000', n'2010-08-02t00:00:00.000', n'2010-08-03t00:00:00.000', n'2010-08-04t00:00:00.000', n'2010-08-05t00:00:00.000', n'2010-08-06t00:00:00.000', n'2010-08-07t00:00:00.000', n'2010-08-08t00:00:00.000', n'2010-08-09t00:00:00.000')

go--分割槽方案

create partition scheme[crscm]as partition [crpfn] to ([cr0], [cr1], [cr2], [cr3], [cr4], [cr5], [cr6], [cr7], [cr8], [cr9])

go巨大表應用此分割槽方案，資料按天劃分，分布於[cr0]……[cr9]這10個檔案組。另外，按照巨大表相同的結構，分別在這10個檔案組中建立乙個不分割槽的表：

[temp_0]……[temp_9]，每個檔案組上有乙個。

分割槽切換步驟：

1）分割槽切換，將最老分割槽資料切換到同一檔案組的單錶（秒殺，幾百萬條記錄瞬時完成，不用1秒）

@day7ago smalldatetime--當前日期的7天前

@day2later smalldatetime--當前日期的2天後

alter table[bigtable]switch partition $partition.crpfn(@day7ago) to[temp_0];

2）將最老分割槽與次老分割槽合併，也就是8天前分割槽與7天前分割槽合併。由於8天前分割槽的資料已經切換掉，為空，所以合併也瞬時完成。

alter partition functioncrpfn()merge range (convert(varchar(10),@day7ago,120));

3）修改分割槽方案，將原先最老分割槽對應的檔案組插入到分割槽佇列末尾，以重新使用。

alter partition scheme[crscm] next used[cr0];

4）拆分最新日期的分割槽，邊界值推進到當前日期的2天後

alter partition functioncrpfn()split range (convert(varchar(10),@day2later,120));

因為最新日期所在分割槽還沒有資料（因為是未來日期），所以拆分起來也是瞬間完成。這也正是我不只設定7個分割槽，而是10個分割槽，永遠將邊界值往未來移兩天的原因。

5）將移到單錶的資料歸併入歷史庫

如何歸併，是下面乙個話題。

6）清空單錶

truncate table[temp_0];

總結：1）永遠只有10個分割槽，迴圈使用。最老的分割槽被合併出局後，馬上又插到分割槽佇列末尾。

2）關鍵是如何找出分割槽位於哪個檔案組，然後才能知道應該切換給哪個單錶，才能放在作業裡自動執行。這個方法詳見拙作：

3）源表與單錶的結構一定要一致。比如字段型別、是否可以為null，索引是否一致，等等。分割槽表的索引要與表對齊。是否壓縮倒不用一致。

2、 bcp + bulk insert，將資料匯入歷史庫

用bcp將資料庫匯出到文字檔案，然後用bulk insert。

declare @shell varchar(500);

set @shell = 'bcp [mydb].dbo.[' + @table + '] out c:/data.txt -t -n';

exec xp_cmdshell @shell;

bulk insert [history].dbo.[table1] from 'c:/data.txt';

exec xp_cmdshell 'del c:/data.txt';

總結：1） bcp匯出很快。400百萬條記錄20秒內完成。

2） bulk insert號稱匯入資料很快，但在我這裡卻沒有見到效果。如果目標表是空表，400百萬條資料可在1分半鐘內匯入成功。但我的歷史表超過5億條記錄，裡面兩個索引，超過20分鐘不見反應，比直接insert還要慢（insert大約17分鐘），我失去了耐心，直接按取消了。

3）其實bulk insert執行的這20分鐘裡，已經插入了100多萬條，但這樣的速度比直接用insert還要慢，讓人無法接受。我估計是索引的緣故，如果將索引全部刪掉，應該會快吧？但重建的時間會更長。究竟這個bulk insert是個什麼機制，在這裡會比insert更慢？有個網友說它會在tempdb裡處理，然後再插進源表，但我在執行期間，觀察了一下系統的tempdb，發現它的檔案沒有變化。

SQL SERVER定期轉移海量資料方案

SQL SERVER定期轉移海量資料方案

ORACLE海量資料轉移方案

SQL Server定期自動備份

SQL SERVER定期轉移海量資料方案

SQL SERVER定期轉移海量資料方案

ORACLE海量資料轉移方案

SQL Server定期自動備份

相關推薦