備份數據庫的時候設置 BufferCount 選項不正確致使 out of memory 的狀況

備份數據庫的時候設置 BufferCount 選項不正確致使 out of memory 的狀況

今天羣裏面的東輝兄跟我說備份生產數據庫的時候報錯

環境：

32位的SQLSERVER2008

機器有16G內存

數據庫大小差很少60G

數據庫已經打開了AWE功能

 

由於是生產庫，暫時不能升級到64位SQL2008，那麼還有沒有其餘辦法能夠解決這個問題呢？？

 

---

上網搜索了一下就找到了這篇文章：

Incorrect BufferCount data transfer option can lead to OOM condition

http://blogs.msdn.com/b/sqlserverfaq/archive/2010/05/06/incorrect-buffercount-data-transfer-option-can-lead-to-oom-condition.aspx

 

譯文：

今天介紹兩個DBA在作數據庫備份的時候通常都不會去指定的備份參數。通常備份數據庫你們會用下面的方法：

一、使用SSMS或者TSQL腳原本備份數據庫

二、使用第三方的備份軟件，這些第三方軟件利用 SQLVDI.DLL暴露出來的編程接口或者使用快照備份

 

當你寫好備份命令併發送到服務器端的時候，你能夠在你的備份命令裏添加以下兩個參數：

MAXTRANSFERSIZE 

BUFFERCOUNT

 

聯機叢書對於這兩個參數的解釋是：

http://technet.microsoft.com/zh-cn/library/ms186865(SQL.105).aspx

數據傳輸選項
BUFFERCOUNT = { buffercount | @buffercount_variable }
指定用於備份操做的 I/O 緩衝區總數。能夠指定任何正整數；可是，較大的緩衝區數可能致使因爲 Sqlservr.exe 進程中的虛擬地址空間（VAS）不足而發生「內存不足」錯誤。
緩衝區使用的總空間由下面的公式肯定：buffercount * maxtransfersize。
注意
有關使用 BUFFERCOUNT 選項的重要信息，請參閱不正確的 BufferCount 數據傳輸選項能夠致使 OOM 狀況博客。

MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }
指定要在 SQL Server 和備份介質之間使用的最大傳輸單元（字節）。

可能的值是 65536 字節 (64 KB) 的倍數，最多可到 4194304 字節 (4 MB)。

 

根據你是否提供這兩個參數值，SQLSERVER會指定用於備份的連續的緩衝區大小。

這是對於32位系統中大量的連續的內存分配的 non-Buffer pool區域的虛擬地址空間是相當重要的。這會令備份失敗（言下之意，備份使用的是non buffer pool）。

當使用SQLVDI，重要的是在VDI配置已經完成以後，咱們不能改變MAXTRANSFERSIZE 。大量的連續的內存分配決定於備份設備的數量和數據庫文件存放的磁盤的數量

 

當你進行備份或者還原數據庫的時候能夠經過跟蹤標誌3213來查看你的備份/還原 配置參數。

具體能夠參考我這篇文章：《SQLSERVER數據庫備份操做和還原操做作了什麼》

我會給大家演示指定不正確的BUFFERCOUNT 參數或者不指定這個參數出現的致命錯誤

 

 

Trace Flag 3213

我使用下面的SQL命令來備份SQLSERVER數據庫

backup database dbBackup

to disk = 'C:\dbBackup1.bak',

disk = 'C:\dbBackup2.bak',

disk = 'C:\dbBackup3.bak',

disk = 'C:\dbBackup4.bak',

disk = 'C:\dbBackup5.bak',

disk = 'C:\dbBackup6.bak'

with stats = 1, format, buffercount = 10, maxtransfersize = 4194304

我特地指定了buffercount參數的值爲10 和maxtransfersize爲4MB

跟蹤標誌3213的輸出顯示了下面的信息

 

最後使用了 40MB  buffer 空間去完成備份

Backup/Restore buffer configuration parameters

Memory limit: 3954MB

Buffer count:               10

Max transfer size:          4096 KB

Min MaxTransfer size:       64 KB

Total buffer space:         40 MB

 

上面的內容在SQLSERVER聯機叢書上已經提到過。

咱們如今須要知道buffer count不指定的狀況下會發生什麼。若是咱們不指定buffer count，那麼buffer count 會比以前指定的時候大

Backup/Restore buffer configuration parameters


Memory limit: 3954MB


Buffer count:               26


Max transfer size:          4096 KB


Min MaxTransfer size:       64 KB


Total buffer space:         104 MB

 

若是你看到上面的輸出會發現不指定的狀況下buffer space已經飆升到104MB，這是由於buffer count已經增加到26

 

---

默認的數據庫備份的Buffer Count的計算

 

SQL Server 2005 或以上

(NumberofBackupDevices * GetSuggestedIoDepth) + NumberofBackupDevices + (2*DatabaseDeviceCount)

 

SQL Server 2000

(NumberofBackupDevices * GetSuggestedIoDepth) + NumberofBackupDevices + (DatabaseDeviceCount)  

 

 

注意：若是使用的是磁盤，那麼備份時候GetSuggestedIoDepth的默認值是3

上面的公式運算完畢以後會返回一個返回值給SQLSERVER,根據備份介質的不一樣，例如磁盤、tape磁帶 、VDI返回不一樣的值

 

根據上面的公式，第一個例子裏面個人備份設備是6，磁盤數是1，所以： 在個人例子裏buffer count是[(6*3) + 6 + (2*1)]=26

 

我將上面的SQL運行在64位SQLSERVER實例上。當我把上面的SQL運行在32位SQLSERVER實例上，

這將佔近三分之一的可用的  non-Buffer  Pool內存 SQL Server(MemToLeave)區域。

當我使用下面的SQL，從原來的6個備份設備增長到12個，SQLSERVER就會報錯

backup database dbBackup
to disk = 'C:\dbBackup1.bak',
disk = 'C:\dbBackup2.bak',
disk = 'C:\dbBackup3.bak',
disk = 'C:\dbBackup4.bak',
disk = 'C:\dbBackup5.bak',
disk = 'C:\dbBackup6.bak'
disk = 'C:\dbBackup7.bak'
disk = 'C:\dbBackup8.bak'
disk = 'C:\dbBackup9.bak'
disk = 'C:\dbBackup10.bak'
disk = 'C:\dbBackup11.bak'
disk = 'C:\dbBackup12.bak'
with stats = 1, format, buffercount = 10, maxtransfersize = 4194304

 

報錯信息

Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.
Msg 701, Level 17, State 17, Line 1
There is insufficient system memory to run this query.
Backup/Restore buffer configuration parameters

 

Backup/Restore buffer configuration parameters

 
Memory limit: 4029MB


Buffer count:               50


Max transfer size:          4096 KB
 

Min MaxTransfer size:       64 KB


Total buffer space:         200 MB

 

個人32位SQLSERVER 的最大的可用連續塊在NON BUFFER POOL (MemToLeave)裏面只有157MB,所以， 就會報OOM（out of memory）錯誤

 

大多數第三方備份軟件會使用一個 Max Transfer Size值可是不會指定Buffer Count 的大小。若是你在作備份的時候，遇到OOM錯誤，你應該下意識的檢查一下

Total Buffer Space的使用量在你備份的時候。 

在這種狀況下，你應該減小備份設備的數目或者減小buffer count經過指定buffer count的值在書寫備份命令的時候

下面的表格指出了默認的buffer count值對於不一樣的備份/還原操做

 

 

若是你在數據庫完整備份到磁盤的時候想大概估計 Buffer memory的用量，下面的SQL腳本可以計算出來

DECLARE @MaxTransferSize FLOAT ,
    @BufferCount BIGINT ,
    @DBName VARCHAR(255) ,
    @BackupDevices BIGINT

-- Default value is zero. Value to be provided in MB.
SET @MaxTransferSize = 0

-- Default value is zero
SET @BufferCount = 0

-- Provide the name of the database to be backed up
SET @DBName = 'dbBackup'

-- Number of disk devices that you are writing the backup to
SET @BackupDevices = 1

DECLARE @DatabaseDeviceCount INT

SELECT  @DatabaseDeviceCount = COUNT(DISTINCT ( SUBSTRING(physical_name, 1,
                                                          CHARINDEX(physical_name,
                                                              ':') + 1) ))
FROM    sys.master_files
WHERE   database_id = DB_ID(@DBName)
        AND type_desc <> 'LOG'

 

IF @BufferCount = 0
    SET @BufferCount = ( @BackupDevices * 3 ) + @BackupDevices + ( 2
                                                              * @DatabaseDeviceCount )


IF @MaxTransferSize = 0
    SET @MaxTransferSize = 1


SELECT  'Total buffer space (MB): '
        + CAST (( @Buffercount * @MaxTransferSize ) AS VARCHAR(10))

 

 

---

至於更詳細的參數能夠參考我這篇文章：《SQLSERVER數據庫備份操做和還原操做作了什麼》

 

 

---

 

實驗

我在電腦上安裝了一個SQL2005 express版本 32位

使用下面的SQL語句進行備份就會報OOM錯誤

BACKUP DATABASE [test] TO DISK ='E:\test1FULLBACKUP.BAK' ,
disk = 'E:\test2FULLBACKUP.bak',
disk = 'E:\test3FULLBACKUP.bak',
disk = 'E:\test4FULLBACKUP.bak',
disk = 'E:\test5FULLBACKUP.bak',
disk = 'E:\test6FULLBACKUP.bak'
WITH BUFFERCOUNT=999999999,FORMAT

 

消息 3013，級別 16，狀態 1，第 1 行
BACKUP DATABASE 正在異常終止。
消息 701，級別 17，狀態 123，第 1 行
沒有足夠的系統內存來運行此查詢。

可是指定 BUFFERCOUNT=1就不會

BACKUP DATABASE [test] TO DISK ='E:\test1FULLBACKUP.BAK' 
WITH BUFFERCOUNT=1

 

 

---

東輝兄的狀況

下午的時候我叫他指定  BUFFERCOUNT=1  試試

結果沒有報OOM錯誤

使用了17分鐘備份完差很少60G的數據庫

 

雖然指定  BUFFERCOUNT=1  備份速度會慢一點，可是non buffer pool的內存佔用不會那麼多

 

感謝東輝兄提供這麼鮮明的例子o(∩_∩)o  

 

若有不對的地方，歡迎你們拍磚o(∩_∩)o