Tôi đang tìm kiếm thực tế hướng dẫn để thiết lập các giá trị cho BUFFERCOUNT, BLOCKSIZEvà MAXTRANSFERSIZEcác BACKUPlệnh. Tôi đã thực hiện một chút nghiên cứu (xem bên dưới), tôi đã thực hiện một chút thử nghiệm và tôi hoàn toàn biết rằng bất kỳ câu trả lời thực sự có giá trị nào cũng sẽ bắt đầu bằng "Chà, điều đó phụ thuộc ...". Mối quan tâm của tôi về thử nghiệm mà tôi đã thực hiện và thử nghiệm được thể hiện trong bất kỳ tài nguyên nào tôi đã tìm thấy (xem cách bên dưới) là thử nghiệm được thực hiện trong chân không, rất có thể là trên một hệ thống không có tải khác.
Tôi tò mò về hướng dẫn phù hợp / thực tiễn tốt nhất liên quan đến ba tùy chọn này dựa trên kinh nghiệm lâu dài: nhiều điểm dữ liệu trong nhiều tuần hoặc nhiều tháng. Và tôi không tìm kiếm các giá trị cụ thể vì đó chủ yếu là một chức năng của phần cứng có sẵn, nhưng tôi muốn biết:
- Làm thế nào các yếu tố phần cứng / tải khác nhau ảnh hưởng đến những gì nên được thực hiện.
- Có những trường hợp trong đó không có giá trị nào trong số những giá trị này nên được ghi đè?
- Có những cạm bẫy để ghi đè bất kỳ trong số này không rõ ràng ngay lập tức? Sử dụng quá nhiều bộ nhớ và / hoặc đĩa I / O? Hoạt động khôi phục phức tạp?
- Nếu tôi có một máy chủ có nhiều Phiên bản SQL Server đang chạy (Trường hợp mặc định và hai Trường hợp được đặt tên) và nếu tôi chạy các bản sao lưu của cả 3 Trường hợp đồng thời, điều đó có ảnh hưởng đến cách tôi đặt các giá trị này ngoài việc đảm bảo rằng tập thể (
BUFFERCOUNT*MAXTRANSFERSIZE) không vượt quá RAM có sẵn? Có thể tranh chấp I / O? - Trong cùng một kịch bản có ba Trường hợp trên một máy chủ và chạy lại các bản sao lưu trên cả ba đồng thời, làm thế nào để chạy các bản sao lưu cho nhiều Cơ sở dữ liệu đồng thời trong mỗi Trường hợp ảnh hưởng đến việc thiết lập các giá trị này? Có nghĩa là, nếu mỗi một trong ba Trường hợp có 100 Cơ sở dữ liệu mỗi cơ sở, thì chạy 2 hoặc 3 bản sao lưu cho mỗi Trường hợp đồng thời sao cho có từ 6 đến 9 bản sao lưu chạy đồng thời. (Trong tình huống này, tôi có nhiều cơ sở dữ liệu vừa và nhỏ thay vì một vài cơ sở dữ liệu lớn.)
Những gì tôi đã thu thập được cho đến nay:
BLOCKSIZE:- Các kích thước được hỗ trợ là 512, 1024, 2048, 4096, 8192, 16384, 32768 và 65536 (64 KB) byte. [1]
- Mặc định là 65536 cho các thiết bị băng và 512 nếu không [1]
- Nếu bạn đang thực hiện một bản sao lưu mà bạn dự định sao chép vào và khôi phục từ đĩa CD-ROM, hãy chỉ định BLOCKSIZE = 2048 [1]
- Khi bạn ghi vào các đĩa đơn, mặc định của 512 là tốt; nếu bạn sử dụng mảng RAID hoặc SAN, bạn phải kiểm tra xem liệu mặc định hay 65536 là tốt hơn. [13 (trang 18)]
Nếu cài đặt thủ công, giá trị cần phải> = Kích thước khối được sử dụng để tạo (các) tệp dữ liệu, nếu không bạn sẽ gặp lỗi sau:
Msg 3272, Cấp 16, Trạng thái 0, Dòng 3
Thiết bị 'C: \ Chương trình \ Microsoft SQL Server \ MSSQL11.MSQuerySERVER \ MSSQL \ Backup \ BackupTest.bak' có kích thước khu vực phần cứng là 4096, nhưng tham số kích thước khối chỉ định giá trị ghi đè không tương thích là 512. Phát hành lại câu lệnh bằng kích thước khối tương thích.
BUFFERCOUNT:Mặc định [2], [8] :
SQL Server 2005 và các phiên bản mới hơn:
(NumberofBackupDevices * [myst_multiplier]) + NumberofBackupDevices + (2 * NumberofVolumeInvolve)[myst_multiplier]: Có một số điểm không nhất quán liên quan đến giá trị này. Tôi đã thấy nó được thể hiện dưới 3 hình thức:
3[2]GetSuggestedIoDepth[số 8]GetSuggestedIoDepth + 1[số 8]
Kiểm tra cho thấy hệ số nhân sẽ3được thực hiện trên SQL Server 2005 SP2 [9] .Thử nghiệm của tôi trên SQL Server 2008 R2 và 2012 và nhận xét của người dùng về SQL Server 2014 [8] , cho thấy hệ số nhân là
4. Có nghĩa là, đưa ra giá trị được báo cáo choGetSuggestedIoDepth(ngay bên dưới), hoặc:GetSuggestedIoDepthbây giờ4, hoặc- số nhân bây giờ
GetSuggestedIoDepth + 1
GetSuggestedIoDepthtrả về3cho các thiết bị DISK [9]- Không có giá trị tối đa được đặt cứng, nhưng với yêu cầu bộ nhớ = (
BUFFERCOUNT*MAXTRANSFERSIZE), có vẻ như giá trị tối đa thực tế sẽ là:BUFFERCOUNT <= (available_memory / MAXTRANSFERSIZE)
MAXTRANSFERSIZE:- Các giá trị có thể là bội số của 65536 byte (64 KB), dao động lên đến 4194304 byte (4 MB). [1]
- Giá trị mặc định: Nếu thiết bị ở chế độ đọc (khôi phục) hoặc đây là Máy tính để bàn hoặc Phiên bản nhanh, hãy sử dụng 64K, nếu không thì sử dụng 1 MB. [9]
- Chung / Khác:
- Kích thước tối đa có thể được sử dụng là ( Bộ nhớ đệm của bộ nhớ vật lý / 16 ). Như được trả về từ lệnh gọi API GlobalMemoryStatusEx (ullTotalPhys). [9]
- Trace Flag
3213xuất các tham số cấu hình sao lưu / khôi phục trong khi thực hiện các hoạt động sao lưu / khôi phục và chuyển3605đầu ra sang tệp ERRORLOG :DBCC TRACEON (3213, 3605, -1); - Bạn có thể sử dụng
DISK = N'NUL:'(tương đương với DOS / Windows/dev/nulltrong UNIX) để kiểm tra dễ dàng hơn một số số liệu (nhưng sẽ không có ý thức tốt về tổng thời gian xử lý vì nó bỏ qua I / O ghi)
Tài nguyên
- MSDN trang cho T-SQL BACKUP lệnh
- KB904804: Bạn gặp hiệu suất chậm khi sao lưu cơ sở dữ liệu trong SQL Server 2000
- Tùy chọn để cải thiện hiệu suất sao lưu của máy chủ SQL
- Sao lưu và khôi phục
- Tối ưu hóa Sao lưu và Khôi phục Máy chủ SQL
- Tối ưu hóa hiệu suất sao lưu
- Cách tăng tốc độ sao lưu toàn bộ cơ sở dữ liệu SQL bằng cách sử dụng nén và đĩa trạng thái rắn
- Tùy chọn truyền dữ liệu BufferCount không chính xác có thể dẫn đến tình trạng OOM
- Cách thức hoạt động: SQL Server Sao lưu và khôi phục chọn kích thước chuyển
- Cách thức hoạt động: Trao đổi bộ đệm sao lưu SQL Server (tiêu điểm VDI)
- SQL Backup điều chỉnh cơ sở dữ liệu lớn
- Bộ nhớ máy chủ SQL cho bộ đệm sao lưu
- Một trường hợp nghiên cứu: Sao lưu và khôi phục nhanh chóng và đáng tin cậy của VLDB qua mạng (tệp .docx)
- Có bao nhiêu thiết bị sao lưu được khuyến nghị để cải thiện hiệu suất sao lưu?
Tôi đã thử nghiệm với:
--DBCC TRACEON (3213, 3605, -1);
BACKUP DATABASE [Test] TO
DISK = 'NUL:'
--,DISK = 'NUL:'
-- DISK = 'BackupTest1.bak'
-- ,DISK = 'BackupTest2.bak'
WITH
STATS = 5,
FORMAT,
CHECKSUM,
NO_COMPRESSION,
COPY_ONLY
--,BUFFERCOUNT = 40
--,MAXTRANSFERSIZE = 4194304--2097152,
--,BLOCKSIZE = 16384
--DBCC TRACEOFF (3213, 3605, -1);CẬP NHẬT
Có vẻ như đôi khi tôi quên thêm một số thông tin mà tôi luôn yêu cầu người khác cung cấp khi tôi trả lời Câu hỏi ;-). Tôi đã cung cấp một số thông tin ở trên về tình hình hiện tại của tôi, nhưng tôi có thể cung cấp thêm chi tiết:
Tôi đang làm việc cho một khách hàng cung cấp ứng dụng SaaS 24/7. Vì vậy, có khả năng người dùng sẽ tham gia bất cứ lúc nào, nhưng thực tế, người dùng đều ở Hoa Kỳ (hiện tại) và có xu hướng làm việc chủ yếu là giờ "tiêu chuẩn": 7 giờ sáng Thái Bình Dương (tức là 10 giờ sáng Đông) đến 7 giờ tối Thái Bình Dương (tức là 10 giờ tối Miền Đông), nhưng 7 ngày một tuần, không chỉ Thứ Hai - Thứ Sáu, mặc dù tải cuối tuần nhẹ hơn một chút.
Chúng được thiết lập sao cho mỗi máy khách có DB riêng. Đó là một ngành công nghiệp thích hợp nên không có hàng chục ngàn (hoặc nhiều hơn) khách hàng tiềm năng. Số lượng DB khách hàng thay đổi theo Instance, với Instance lớn nhất chứa 206 client. DB lớn nhất là khoảng. 8 GB, nhưng chỉ có khoảng 30 DB là hơn 1 GB. Do đó, tôi không đặc biệt cố gắng tối đa hóa hiệu suất của VLDB.
Khi tôi bắt đầu với khách hàng này, các bản sao lưu của họ luôn ĐẦY ĐỦ, một lần mỗi ngày và không có bản sao lưu LOG. Họ cũng đã đặt MAXTRANSFERSIZE thành 4 MB và BUFFERCOUNT thành 50. Tôi đã thay thế thiết lập đó bằng một phiên bản kịch bản sao lưu cơ sở dữ liệu của Ola Hallengren . Phần được tùy chỉnh một chút là nó được chạy từ một công cụ đa luồng (tôi đã viết và hy vọng sẽ sớm bán), nó tự động phát hiện ra các DB khi nó kết nối với từng Instance và cho phép điều chỉnh theo Instance (do đó tôi hiện đang chạy ba trường hợp đồng thời, nhưng DB mỗi lần xuất hiện liên tục vì tôi không chắc chắn về sự phân nhánh của việc chạy chúng đồng thời).
Việc thiết lập bây giờ là thực hiện sao lưu ĐẦY ĐỦ một ngày mỗi tuần và sao lưu DIFF vào các ngày khác; Sao lưu LOG được thực hiện cứ sau 10 phút. Tôi đang sử dụng các giá trị mặc định cho 3 tùy chọn mà tôi đang tìm hiểu ở đây. Nhưng, biết cách chúng được thiết lập, tôi muốn chắc chắn rằng tôi không hoàn thành việc tối ưu hóa (chỉ vì có một số lỗ hổng lớn trong hệ thống cũ không có nghĩa là mọi thứđã sai). Hiện tại, đối với cơ sở dữ liệu 206, phải mất khoảng 62 phút để sao lưu FULL (mỗi tuần một lần) và từ 7 đến 20 phút để sao lưu DIFF vào các ngày còn lại (7 vào ngày đầu tiên sau FULL và 20 vào ngày cuối cùng trước ĐẦY ĐỦ tiếp theo). Và đó là chạy chúng tuần tự (chủ đề duy nhất). Quá trình sao lưu LOG, tổng cộng (tất cả các DB trên cả 3 Trường hợp), mất từ 50 đến 90 giây mỗi lần (một lần nữa, cứ sau 10 phút).
Tôi nhận ra rằng tôi có thể chạy nhiều tệp trên mỗi DB, nhưng a) Tôi không chắc sẽ cung cấp đa luồng tốt hơn và kích thước nhỏ đến trung bình của DB và b) Tôi không muốn làm phức tạp quá trình khôi phục ( có nhiều lý do tại sao xử lý một tệp duy nhất được ưa thích).
Tôi cũng nhận ra rằng tôi có thể kích hoạt tính năng nén (truy vấn thử nghiệm của tôi đã vô tình bị vô hiệu hóa) và tôi đã khuyến nghị điều đó với nhóm, nhưng tôi đã nhận thấy rằng việc nén tích hợp là khá may mắn. Một phần của quy trình cũ là nén từng tệp vào RAR và tôi đã tự kiểm tra và thấy rằng có, phiên bản RAR nhỏ hơn ít nhất 50% so với phiên bản nén nguyên bản. Trước tiên tôi đã thử sử dụng nén riêng để tăng tốc mọi thứ và sau đó RAR các tệp, nhưng các tệp đó, dù nhỏ hơn so với nén đơn thuần, vẫn lớn hơn một chút so với phiên bản nén chỉ RAR và đủ khác biệt để chứng minh không sử dụng nén riêng. Quá trình nén các bản sao lưu không đồng bộ và chạy cứ sau X phút. Nếu nó tìm thấy một .bakhoặc.trntập tin, nó nén nó. Bằng cách này, quá trình sao lưu không bị chậm lại bởi thời gian cần thiết để nén từng tệp.