การตั้งค่า BUFFERCOUNT, BLOCKSIZE และ MAXTRANSFERSIZE สำหรับคำสั่ง BACKUP

ฉันกำลังมองหาการปฏิบัติคำแนะนำสำหรับการตั้งค่าสำหรับBUFFERCOUNT, BLOCKSIZEและMAXTRANSFERSIZEของBACKUPคำสั่ง ฉันได้ทำการวิจัยนิดหน่อย (ดูด้านล่าง) ฉันได้ทำการทดสอบแล้วและฉันก็ตระหนักดีว่าคำตอบที่มีค่าอย่างแท้จริงจะเริ่มต้นด้วย "ดีขึ้นอยู่กับ ... " ความกังวลของฉันเกี่ยวกับการทดสอบที่ฉันได้ทำและการทดสอบที่แสดงในแหล่งข้อมูลใด ๆ ที่ฉันได้พบ (ดูวิธีด้านล่าง) คือการทดสอบจะทำในสุญญากาศซึ่งเป็นไปได้มากที่สุดในระบบที่ไม่มีโหลดอื่น ๆ

ฉันอยากรู้เกี่ยวกับแนวทางที่ถูกต้อง / แนวปฏิบัติที่ดีที่สุดเกี่ยวกับสามตัวเลือกเหล่านี้ซึ่งยึดตามประสบการณ์ระยะยาว: มีจุดข้อมูลจำนวนมากในช่วงสัปดาห์หรือเป็นเดือน และฉันไม่ได้มองหาค่าที่เฉพาะเจาะจงเนื่องจากส่วนใหญ่เป็นฟังก์ชั่นของฮาร์ดแวร์ที่มีอยู่ แต่ฉันต้องการที่จะรู้ว่า:

• ปัจจัยฮาร์ดแวร์ / โหลดที่หลากหลายมีผลต่อสิ่งที่ควรทำ
• มีสถานการณ์ใดบ้างที่ไม่ควรแทนที่ค่าเหล่านี้?
• มีข้อผิดพลาดในการเอาชนะสิ่งเหล่านี้ที่ไม่ชัดเจนในทันทีหรือไม่? ใช้หน่วยความจำและ / หรือดิสก์ I / O มากเกินไปหรือไม่ มีความซับซ้อนในการกู้คืนการดำเนินการ?
• ถ้าฉันมีเซิร์ฟเวอร์ที่มีหลายอินสแตนซ์ของ SQL Server ทำงาน (เป็นค่าเริ่มต้นอินสแตนซ์และสองอินสแตนซ์ที่มีชื่อ) และหากฉันใช้การสำรองข้อมูลของทั้ง 3 อินสแตนซ์พร้อม ๆ กันไม่ว่าส่งผลกระทบต่อวิธีการที่ฉันตั้งค่าเหล่านี้เกินกว่าการทำให้แน่ใจว่าส่วนรวม ( BUFFERCOUNT* MAXTRANSFERSIZE) ไม่เกิน RAM ที่มีอยู่หรือไม่ การต่อสู้ I / O เป็นไปได้หรือไม่
• ในสถานการณ์เดียวกันนี้ที่มีอินสแตนซ์สามตัวบนเซิร์ฟเวอร์เดียวและเรียกใช้การสำรองข้อมูลอีกครั้งในทั้งสามพร้อมกันอีกครั้งจะรันการสำรองข้อมูลสำหรับฐานข้อมูลหลายฐานพร้อมกันภายในแต่ละอินสแตนซ์ได้อย่างไร หมายความว่าหากแต่ละอินสแตนซ์ทั้งสามมี 100 ฐานข้อมูลแต่ละตัวรันการสำรองข้อมูล 2 หรือ 3 ต่อแต่ละอินสแตนซ์พร้อมกันเพื่อให้มีการสำรองข้อมูลระหว่าง 6 และ 9 พร้อมกัน (ในสถานการณ์นี้ฉันมีฐานข้อมูลขนาดเล็กถึงขนาดกลางมากกว่าฐานข้อมูลขนาดใหญ่บางส่วน)

สิ่งที่ฉันได้รวบรวม:

• BLOCKSIZE:

  • ขนาดที่รองรับคือ 512, 1024, 2048, 4096, 8192, 16384, 32768 และ 65536 (64 KB) ไบต์ ^[1]
  • ค่าเริ่มต้นคือ 65536 สำหรับอุปกรณ์เทปและ 512 เป็นอย่างอื่น^[1]
  • หากคุณทำการสำรองข้อมูลที่คุณวางแผนที่จะคัดลอกและกู้คืนจากซีดีรอมให้ระบุ BLOCKSIZE = 2048 ^[1]
  • เมื่อคุณเขียนลงดิสก์เดียวค่าเริ่มต้นของ 512 ก็ใช้ได้ ถ้าคุณใช้ RAID arrays หรือ SAN คุณต้องทดสอบเพื่อดูว่าค่าเริ่มต้นหรือ 65536 นั้นดีกว่าหรือไม่ ^{[13 (หน้า 18)]}

  • หากการตั้งค่าด้วยตนเองค่าจะต้อง> = ขนาดบล็อกที่ใช้ในการสร้างไฟล์ข้อมูลมิฉะนั้นคุณจะได้รับข้อผิดพลาดต่อไปนี้:

    ข่าวสารเกี่ยวกับ 3272, ระดับ 16, สถานะ 0, บรรทัด 3 อุปกรณ์
    SQL Server \ MSSQL11.MSSQLSERVER \ MSSQL \ Backup \ BackupTest.bak 'C: \ Program Files \ Microsoft SQL มีขนาดเซกเตอร์ของฮาร์ดแวร์ 4096 แต่พารามิเตอร์ขนาดบล็อกระบุ ค่าการแทนที่ที่เข้ากันไม่ได้ของ 512 ออกคำสั่งอีกครั้งโดยใช้ขนาดบล็อกที่เข้ากันได้

• BUFFERCOUNT:

  • ค่าเริ่มต้น^{[2], [8]} :

    SQL Server 2005 และรุ่นที่ใหม่กว่า:
    (NumberofBackupDevices * [ลึกลับ_multiplier]) + NumberofBackupDevices + (2 * NumberofVolumesInvolved)

  • [ลึกลับ_multiplier]: มีความไม่สอดคล้องกันเกี่ยวกับคุณค่านี้ ฉันได้เห็นมันแสดงออกมาใน 3 รูปแบบ:

    • 3 ^[2]
    • GetSuggestedIoDepth ^[8]
    • GetSuggestedIoDepth + 1 ^[8]

    
    การทดสอบแสดงให้เห็นว่าตัวคูณที่จะ3ทำใน SQL Server 2005 SP2 [9]

    การทดสอบของฉันใน SQL Server 2008 R2 และ 2012 และแสดงความคิดเห็นเกี่ยวกับผู้ใช้ SQL Server 2014 ^[8]4แสดงตัวคูณที่จะ ความหมายให้ค่ารายงานสำหรับGetSuggestedIoDepth(ด้านล่างโดยตรง) อย่างใดอย่างหนึ่ง:

    • GetSuggestedIoDepthคือตอนนี้4หรือ
    • ตัวคูณคือตอนนี้ GetSuggestedIoDepth + 1
  • GetSuggestedIoDepthส่งคืน3สำหรับอุปกรณ์ DISK ^[9]
  • ไม่มีค่าสูงสุดที่ตั้งค่าได้ยาก แต่เนื่องจากหน่วยความจำที่ต้องการ = ( BUFFERCOUNT* MAXTRANSFERSIZE) ดูเหมือนว่าค่าสูงสุดที่ใช้งานได้จะเป็น: BUFFERCOUNT <= (available_memory / MAXTRANSFERSIZE)
• MAXTRANSFERSIZE:
  • ค่าที่เป็นไปได้คือทวีคูณของ 65536 ไบต์ (64 KB) ตั้งแต่ 4194304 ไบต์ (4 MB) ^[1]
  • ค่าเริ่มต้น: หากอุปกรณ์อยู่ในโหมดอ่าน (กู้คืน) หรือนี่คือ Desktop หรือ Express Edition ใช้ 64K มิฉะนั้นจะใช้ 1 MB ^[9]
• ทั่วไป / เบ็ดเตล็ด:
  • ขนาดสูงสุดที่สามารถใช้ได้คือ ( บัฟเฟอร์ของพูลหน่วยความจำกายภาพ / 16 ) ตามที่ส่งคืนจากการเรียก API GlobalMemoryStatusEx (ullTotalPhys) ^[9]
  • Trace แฟ3213ล็กเอาท์พุทพารามิเตอร์การสำรองข้อมูล / คืนค่าพารามิเตอร์ขณะดำเนินการสำรองข้อมูล / เรียกคืนและ3605ทิ้งเอาต์พุตไปที่ไฟล์ERRORLOG :DBCC TRACEON (3213, 3605, -1);
  • คุณสามารถใช้DISK = N'NUL:'(DOS / Windows เทียบเท่า/dev/nullใน UNIX) สำหรับการทดสอบตัวชี้วัดบางอย่างง่ายขึ้น (แต่จะไม่ได้รับความรู้สึกที่ดีของเวลากระบวนการทั้งหมดเพราะมันจะข้ามการเขียน I / O)

ทรัพยากร

1. หน้า MSDN สำหรับคำสั่งT-SQL BACKUP
2. KB904804: คุณประสบกับประสิทธิภาพการทำงานช้าเมื่อคุณสำรองฐานข้อมูลใน SQL Server 2000
3. ตัวเลือกเพื่อปรับปรุงประสิทธิภาพการสำรองข้อมูล SQL Server
4. สำรองและเรียกคืน
5. การเพิ่มประสิทธิภาพการสำรองและคืนค่าเซิร์ฟเวอร์ SQL
6. การเพิ่มประสิทธิภาพการสำรองข้อมูลให้เหมาะสม
7. วิธีเพิ่มความเร็วในการสำรองฐานข้อมูล SQL แบบเต็มโดยใช้การบีบอัดและโซลิดสเตตดิสก์
8. ตัวเลือกการถ่ายโอนข้อมูล BufferCount ไม่ถูกต้องสามารถนำไปสู่เงื่อนไข OOM
9. มันทำงานอย่างไร: SQL Server Backup and Restore เลือกขนาดการถ่ายโอนอย่างไร
10. มันทำงานอย่างไร: SQL Server Backup Buffer Exchange (VDI Focus)
11. SQL Backup ปรับฐานข้อมูลขนาดใหญ่
12. หน่วยความจำเซิร์ฟเวอร์ SQL สำหรับบัฟเฟอร์สำรอง
13. กรณีศึกษา: การสำรองและกู้คืนและกู้คืน VLDB ที่รวดเร็วและเชื่อถือได้ผ่านเครือข่าย (ไฟล์. docx)
14. แนะนำให้ใช้อุปกรณ์สำรองจำนวนเท่าใดเพื่อปรับปรุงประสิทธิภาพการสำรองข้อมูล

ฉันทดสอบด้วย:

--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);

UPDATE

ดูเหมือนว่าบางครั้งฉันลืมที่จะเพิ่มข้อมูลบางส่วนที่ฉันมักจะขอให้ผู้อื่นให้เมื่อฉันตอบคำถาม ;-) ฉันให้ข้อมูลข้างต้นเกี่ยวกับสถานการณ์ปัจจุบันของฉัน แต่ฉันสามารถให้รายละเอียดเพิ่มเติม:

ฉันทำงานให้กับลูกค้าที่ให้บริการแอปพลิเคชัน SaaS 24/7 / 365.25 ดังนั้นจึงมีความเป็นไปได้ที่ผู้ใช้จะอยู่ ณ จุดใดก็ได้ แต่ตามความเป็นจริงผู้ใช้ล้วน แต่อาศัยอยู่ในสหรัฐอเมริกา (ตอนนี้) และมีแนวโน้มที่จะทำงานส่วนใหญ่ "มาตรฐาน" ชั่วโมง: 7 AM Pacific (เช่น 10 AM Eastern) ถึง 7 PM Pacific (เช่น 22.00 น. ทางทิศตะวันออก) แต่ 7 วันต่อสัปดาห์ไม่ใช่แค่วันจันทร์ถึงวันศุกร์ แต่การโหลดวันหยุดสุดสัปดาห์จะเบากว่าเล็กน้อย

พวกเขาตั้งค่าให้ลูกค้าแต่ละรายมีฐานข้อมูลของตนเอง เป็นอุตสาหกรรมเฉพาะดังนั้นมีลูกค้าไม่มากถึงหมื่น (หรือมากกว่า) จำนวนของฐานข้อมูลลูกค้าแตกต่างกันไปตามอินสแตนซ์ที่มีอินสแตนซ์ที่ใหญ่ที่สุดถือลูกค้า 206 ฐานข้อมูลที่ใหญ่ที่สุดคือประมาณ 8 GB แต่มีเพียง 30 DB เท่านั้นที่มีมากกว่า 1 GB ดังนั้นฉันไม่ได้พยายามเพิ่มประสิทธิภาพของ VLDB โดยเฉพาะ

เมื่อฉันเริ่มต้นกับไคลเอนต์นี้การสำรองข้อมูลของพวกเขาจะเต็มเสมอทุกวันและไม่มีการสำรองข้อมูล LOG พวกเขาตั้งค่า MAXTRANSFERSIZE เป็น 4 MB และ BUFFERCOUNT เป็น 50 ฉันแทนที่การตั้งค่านั้นด้วยสคริปต์สำรองฐานข้อมูลของOla Hallengrenรุ่นที่กำหนดเองเล็กน้อย ส่วนที่กำหนดเองเล็กน้อยคือมันถูกเรียกใช้จากเครื่องมือมัลติเธรด (ที่ฉันเขียนและหวังว่าจะเริ่มขายเร็ว ๆ นี้) ที่ค้นพบฐานข้อมูลแบบไดนามิกในขณะที่มันเชื่อมต่อกับแต่ละอินสแตนซ์และอนุญาตการควบคุมปริมาณต่ออินสแตนซ์ สามอินสแตนซ์พร้อมกัน แต่ฐานข้อมูลต่อแต่ละอินสแตนซ์เรียงตามลำดับเนื่องจากฉันไม่แน่ใจว่าจะทำให้การทำงานของพวกเขาพร้อมกันได้หรือไม่)

การตั้งค่าคือการสำรองข้อมูลทั้งหมดในหนึ่งวันต่อสัปดาห์และสำรองข้อมูล DIFF ในวันอื่น ๆ การสำรองข้อมูล LOG จะดำเนินการทุก 10 นาที ฉันใช้ค่าเริ่มต้นสำหรับ 3 ตัวเลือกที่ฉันกำลังสอบถามเกี่ยวกับที่นี่ แต่เมื่อรู้วิธีที่ตั้งไว้ฉันต้องการตรวจสอบให้แน่ใจว่าฉันไม่ได้เลิกทำการเพิ่มประสิทธิภาพ (เพียงเพราะมีข้อบกพร่องที่สำคัญบางอย่างในระบบเก่าไม่ได้หมายความว่าทุกอย่างผิด) ปัจจุบันสำหรับฐานข้อมูล 206 จะใช้เวลาประมาณ 62 นาทีสำหรับการสำรองข้อมูลเต็มรูปแบบ (สัปดาห์ละครั้ง) และระหว่าง 7 และ 20 นาทีสำหรับการสำรองข้อมูล DIFF ในวันที่เหลือ (7 ในวันแรกหลังจาก FULL และ 20 ในวันสุดท้ายก่อน FULL ถัดไป) และที่กำลังเรียกใช้พวกเขาตามลำดับ (เธรดเดียว) กระบวนการสำรองข้อมูล LOG รวม (ฐานข้อมูลทั้งหมดใน 3 อินสแตนซ์ทั้งหมด) ใช้เวลาตั้งแต่ 50 ถึง 90 วินาทีในแต่ละครั้ง (อีกครั้งทุก 10 นาที)

ฉันรู้ว่าฉันสามารถเรียกใช้หลายไฟล์ต่อ DB แต่ a) ฉันไม่แน่ใจว่าจะให้ multithreading และขนาดของ DBs ขนาดเล็กถึงขนาดกลางได้ดีกว่าและ b) ฉันไม่ต้องการทำให้กระบวนการกู้คืนซับซ้อน ( มีเหตุผลหลายประการว่าทำไมการจัดการกับไฟล์เดียวจึงเป็นที่ต้องการ)

ฉันก็ตระหนักว่าฉันสามารถเปิดใช้งานการบีบอัด (แบบสอบถามทดสอบของฉันปิดการใช้งานโดยเจตนา) และฉันได้แนะนำให้กับทีม แต่มันก็มาถึงความสนใจของฉันว่าการบีบอัดในตัวเป็นเรื่องจริง ส่วนหนึ่งของกระบวนการเก่าคือการบีบอัดไฟล์แต่ละไฟล์ให้เป็น RAR และฉันทำการทดสอบของตัวเองและพบว่าใช่รุ่น RAR เป็นอย่างน้อยมีขนาดเล็กกว่ารุ่นบีบอัด 50% ฉันลองใช้การบีบอัดแบบเนทีฟก่อนเพื่อเพิ่มความเร็วแล้ว RAR ไฟล์ แต่ไฟล์เหล่านั้นในขณะที่เล็กกว่าที่บีบอัดแบบดั้งเดิม แต่ก็ยังมีขนาดใหญ่กว่ารุ่นบีบอัด RAR เพียงอย่างเดียวเล็กน้อย ไม่ได้ใช้การบีบอัดแบบเนทีฟ กระบวนการบีบอัดข้อมูลสำรองนั้นไม่ตรงกันและทำงานทุก ๆ X นาที หากพบ.bakหรือ.trnไฟล์มันบีบอัดมัน วิธีนี้กระบวนการสำรองข้อมูลจะไม่ชะลอตัวลงตามเวลาที่ใช้ในการบีบอัดแต่ละไฟล์

คุณได้ระบุจำนวนเรือที่บรรทุกสินค้าไว้ในคำถามของคุณ ขอบคุณสำหรับการเป็นอย่างละเอียด!

สองสิ่งที่ฉันสังเกตเห็นมือ:

• ปัจจัยฮาร์ดแวร์ / โหลดที่หลากหลายมีผลต่อสิ่งที่ควรทำ

คุณกำลังใช้งานอินสแตนซ์ 24x7 หรือไม่? โหลดตลอดเวลาคืออะไร? ฉันสังเกตเห็นว่าคุณปิดใช้งานการบีบอัดข้อมูลสำรอง เป็นเพราะการออกแบบสำหรับการทดสอบหรือเป็นที่ต้องการด้วยเหตุผลบางอย่างที่จะปิดเมื่อคุณใส่สิ่งนี้ลงในการผลิต? หากคุณมีฮาร์ดแวร์จำนวนมาก (CPU / RAM) และการสำรองข้อมูลให้เสร็จภายในเวลาที่สั้นที่สุดนั้นมีความสำคัญอย่างยิ่งคุณต้องปรับพารามิเตอร์เหล่านี้สำหรับฮาร์ดแวร์เฉพาะที่คุณมีโดยคำนึงถึงเป้าหมายนั้น หากคุณต้องการให้แน่ใจว่าภาระงานของ OLTP นั้นได้รับการบริการตลอดเวลาและไม่ต้องการการสำรองข้อมูลเพื่อส่งผลกระทบนั้นคุณอาจต้องปรับพารามิเตอร์เหล่านี้ในลักษณะอื่น คุณไม่ได้ระบุเป้าหมายการออกแบบของคุณเนื่องจากคุณกำลังขอคำแนะนำทั่วไปอย่างไรก็ตามเนื่องจากคุณระบุอย่างชาญฉลาดว่า "มันขึ้นอยู่กับ™"

• มีสถานการณ์ใดบ้างที่ไม่ควรแทนที่ค่าเหล่านี้?

คุณต้องการคงการตั้งค่าเริ่มต้นไว้หากคุณกังวลเกี่ยวกับความสามารถในการรองรับหลังถนนหลังจากที่คุณไม่ได้ดูแลอินสแตนซ์อีกต่อไปและไม่แน่ใจเกี่ยวกับความสามารถในการเปลี่ยนของคุณ คุณอาจต้องการออกจากค่าเริ่มต้นเว้นแต่คุณมีความต้องการเฉพาะในการปรับแต่ง ปล่อยให้สุนัขนอนหลับตามที่พวกเขาพูด

• มีข้อผิดพลาดในการเอาชนะสิ่งเหล่านี้ที่ไม่ชัดเจนในทันทีหรือไม่? ใช้หน่วยความจำและ / หรือดิสก์ I / O มากเกินไปหรือไม่ มีความซับซ้อนในการกู้คืนการดำเนินการ?

ในฐานะที่เป็นเอกสารที่คุณอ้างอิงอย่างชัดเจนการเพิ่มพารามิเตอร์เหล่านี้มากเกินไปอาจส่งผลเสียต่อสถานะการออนไลน์ เช่นเดียวกับทุกอย่างที่เกี่ยวกับการผลิตคุณจำเป็นต้องทดสอบสิ่งนี้อย่างถี่ถ้วนก่อนที่จะนำไปใช้งานและออกจากการตั้งค่าเพียงอย่างเดียวเว้นแต่จำเป็นจริงๆ

• ถ้าฉันมีเซิร์ฟเวอร์ที่มีอินสแตนซ์หลายตัวของ SQL Server ทำงานอยู่ (อินสแตนซ์ที่เริ่มต้นและอินสแตนซ์ที่มีชื่อสองรายการ) และถ้าฉันเรียกใช้การสำรองข้อมูลของอินสแตนซ์ทั้ง 3 รายการในเวลาเดียวกัน * MAXTRANSFERSIZE) มี RAM ไม่เกิน? การต่อสู้ I / O เป็นไปได้หรือไม่

คุณจะต้องการให้แน่ใจว่าคุณออกจาก RAM มากมายสำหรับสถานการณ์ที่ไม่คาดฝัน แน่นอนฉันจะต้องกังวลเกี่ยวกับการใช้ ram มากกว่า 60% หรือ 70% ของ ram สำหรับการสำรองข้อมูลเว้นแต่ว่าฉันรู้ด้วยความมั่นใจ 100% ว่าจะไม่มีอะไรเกิดขึ้นระหว่างหน้าต่างสำรองข้อมูลอีกต่อไป

ฉันเขียนบล็อกโพสต์พร้อมรหัสบางส่วนที่แสดงวิธีการทดสอบประสิทธิภาพการสำรองข้อมูลที่SQLServerScience.com

^{นี่อาจไม่ใช่คำตอบที่ดีที่สุดที่ฉันเคยเขียน แต่ในขณะที่ The Great One ™เคยพูดไว้ว่า "คุณพลาด 100% ของภาพที่คุณไม่ได้ถ่าย"}