MS SQL Server: สำรองข้อมูลบนเตียรอยด์

รอ! รอ! จริงอยู่นี่ไม่ใช่บทความอื่นเกี่ยวกับประเภทของการสำรองข้อมูล SQL Server ฉันจะไม่พูดถึงความแตกต่างระหว่างโมเดลการกู้คืนและวิธีจัดการกับบันทึกที่รกเกินไปด้วยซ้ำ

บางที (อาจจะ) หลังจากอ่านโพสต์นี้แล้ว คุณจะสามารถมั่นใจได้ว่าข้อมูลสำรองที่ถูกลบออกจากคุณโดยใช้วิธีการมาตรฐานจะถูกลบออกในคืนวันพรุ่งนี้ เร็วขึ้น 1.5 เท่า และเนื่องจากคุณใช้พารามิเตอร์ฐานข้อมูลสำรองเพิ่มขึ้นเล็กน้อยเท่านั้น

หากเนื้อหาในโพสต์ชัดเจนสำหรับคุณ ฉันขอโทษ ฉันอ่านทุกสิ่งที่ Google ได้รับสำหรับวลี "การสำรองข้อมูลเซิร์ฟเวอร์ habr sql" และฉันไม่พบการกล่าวถึงข้อเท็จจริงที่ว่าเวลาในการสำรองข้อมูลอาจได้รับอิทธิพลจากการใช้พารามิเตอร์ในทางใดทางหนึ่ง

ฉันจะดึงความสนใจของคุณไปที่ความคิดเห็นของ Alexander Gladchenko ทันที (@mssqlhelp):

อย่าเปลี่ยนพารามิเตอร์ BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE ในการผลิต ทำขึ้นเพื่อการเขียนบทความดังกล่าวเท่านั้น ในทางปฏิบัติ คุณจะกำจัดปัญหาความจำได้ในเวลาอันรวดเร็ว

แน่นอนว่าคงจะเจ๋งมากถ้าเป็นคนที่ฉลาดที่สุดและโพสต์เนื้อหาพิเศษ แต่น่าเสียดายที่มันไม่เป็นเช่นนั้น มีบทความ/โพสต์ทั้งภาษาอังกฤษและภาษารัสเซีย (ฉันมักจะสับสนว่าจะเรียกอย่างถูกต้องว่าอะไร) สำหรับหัวข้อนี้ นี่คือบางส่วนที่ฉันเจอ: เวลา, สอง, สาม (บน sql.ru).

อันดับแรก ฉันจะแนบไวยากรณ์การสำรองข้อมูลที่ถูกตัดทอนลงเล็กน้อย MSDN (โดยวิธีการที่ฉันเขียนไว้ข้างต้นเกี่ยวกับฐานข้อมูลสำรอง แต่ทั้งหมดนี้ใช้กับทั้งการสำรองข้อมูลบันทึกธุรกรรมและการสำรองข้อมูลส่วนต่าง แต่อาจมีผลที่ชัดเจนน้อยกว่า):

BACKUP DATABASE { database_name | @database_name_var }
  TO <backup_device> [ ,...n ]
  <...>
  [ WITH { <...>
           | <general_WITH_options> [ ,...n ] } ]
[;]

<general_WITH_options> [ ,...n ]::=
<...>
--Media Set Options
 <...>
 | BLOCKSIZE = { blocksize | @blocksize_variable }

--Data Transfer Options
   BUFFERCOUNT = { buffercount | @buffercount_variable }
 | MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }
<...>

<…> - หมายความว่ามีบางอย่างอยู่ที่นั่น แต่ฉันลบมันออกเพราะตอนนี้มันไม่เกี่ยวข้องกับหัวข้อแล้ว

ปกติคุณสำรองข้อมูลอย่างไร? พวกเขา “สอน” วิธีการสำรองข้อมูลในบทความนับพันล้านได้อย่างไร โดยทั่วไป หากฉันต้องการสำรองข้อมูลครั้งเดียวของฐานข้อมูลที่มีขนาดไม่ใหญ่มาก ฉันจะเขียนสิ่งนี้โดยอัตโนมัติ:

BACKUP DATABASE smth
TO DISK = 'D:Backupsmth.bak'
WITH STATS = 10, CHECKSUM, COMPRESSION, COPY_ONLY;
--ладно, CHECKSUM я написал только чтобы казаться умнее

และโดยทั่วไปแล้ว พารามิเตอร์ทั้งหมดที่มักกล่าวถึงในบทความเกี่ยวกับการสำรองข้อมูลอาจแสดงอยู่ที่นี่ 75-90% นอกจากนี้ยังมี INIT, SKIP คุณเคยเยี่ยมชม MSDN หรือไม่? คุณเคยเห็นไหมว่ามีตัวเลือกสำหรับหนึ่งหน้าจอครึ่ง? ฉันยังเห็น...

คุณคงทราบแล้วว่าต่อไปเราจะพูดถึงพารามิเตอร์สามตัวที่ยังคงอยู่ในบล็อกแรกของโค้ด - BLOCKSIZE, BUFFERCOUNT และ MAXTRANSFERSIZE นี่คือคำอธิบายจาก MSDN:

ขนาดบล็อคS = { ขนาดบล็อก | @ blockize_variable } - ระบุขนาดฟิสิคัลบล็อกเป็นไบต์ ขนาดที่รองรับคือ 512, 1024, 2048, 4096, 8192, 16, 384 และ 32 ไบต์ (768 KB) ค่าดีฟอลต์คือ 65 สำหรับอุปกรณ์เทปและ 536 สำหรับอุปกรณ์อื่นๆ โดยทั่วไปพารามิเตอร์นี้ไม่จำเป็นเนื่องจากคำสั่ง BACKUP จะเลือกขนาดบล็อกที่เหมาะสมสำหรับอุปกรณ์โดยอัตโนมัติ การตั้งค่าขนาดบล็อกจะแทนที่การเลือกขนาดบล็อกอัตโนมัติอย่างชัดเจน

บัฟเฟอร์ = { จำนวนบัฟเฟอร์ | @ buffercount_variable } - กำหนดจำนวนบัฟเฟอร์ I/O ทั้งหมดที่จะใช้สำหรับการดำเนินการสำรองข้อมูล คุณสามารถระบุค่าจำนวนเต็มบวกใดๆ ได้ แต่บัฟเฟอร์จำนวนมากอาจทำให้เกิดข้อผิดพลาดหน่วยความจำไม่เพียงพอเนื่องจากพื้นที่ที่อยู่เสมือนมากเกินไปในกระบวนการ Sqlservr.exe

จำนวนพื้นที่ทั้งหมดที่ใช้โดยบัฟเฟอร์ถูกกำหนดโดยสูตรต่อไปนี้: BUFFERCOUNT * MAXTRANSFERSIZE.

ขนาดการโอนสูงสุด = { การถ่ายโอนสูงสุด | @ ขนาดการถ่ายโอนสูงสุด_ตัวแปร } ระบุขนาดแพ็กเก็ตข้อมูลที่ใหญ่ที่สุดในหน่วยไบต์ เพื่อแลกเปลี่ยนระหว่าง SQL Server และสื่อชุดการสำรองข้อมูล รองรับหลายรายการตั้งแต่ 65 ไบต์ (536 KB) จนถึง 64 ไบต์ (4 MB)

ฉันสาบาน - ฉันเคยอ่านข้อความนี้มาก่อน แต่ก็ไม่เคยเกิดขึ้นกับฉันเลยว่าสิ่งเหล่านี้จะส่งผลต่อประสิทธิภาพการทำงานมากน้อยเพียงใด ยิ่งกว่านั้นเห็นได้ชัดว่าฉันต้อง "เปิดเผย" และยอมรับว่าแม้ตอนนี้ฉันยังไม่เข้าใจสิ่งที่พวกเขากำลังทำอยู่ ฉันอาจต้องอ่านเพิ่มเติมเกี่ยวกับบัฟเฟอร์ I/O และการทำงานกับฮาร์ดไดรฟ์ สักวันหนึ่งฉันจะทำเช่นนี้ แต่ตอนนี้ฉันสามารถเขียนสคริปต์ที่จะตรวจสอบว่าค่าเหล่านี้ส่งผลต่อความเร็วในการสำรองข้อมูลอย่างไร

ฉันสร้างฐานข้อมูลขนาดเล็กขนาดประมาณ 10 GB วางไว้บน SSD และใส่ไดเร็กทอรีสำหรับการสำรองข้อมูลบน HDD

ฉันสร้างตารางชั่วคราวเพื่อจัดเก็บผลลัพธ์ (ฉันไม่มีตารางชั่วคราว ดังนั้นฉันจึงสามารถเจาะลึกผลลัพธ์ได้โดยละเอียดมากขึ้น แต่คุณเป็นผู้ตัดสินใจเอง):

DROP TABLE IF EXISTS ##bt_results; 

CREATE TABLE ##bt_results (
    id              int IDENTITY (1, 1) PRIMARY KEY,
    start_date      datetime NOT NULL,
    finish_date     datetime NOT NULL,
    backup_size     bigint NOT NULL,
    compressed_size bigint,
    block_size      int,
    buffer_count    int,
    transfer_size   int
);

หลักการของสคริปต์นั้นง่าย - ลูปซ้อนซึ่งแต่ละลูปจะเปลี่ยนค่าของพารามิเตอร์หนึ่งตัวแทรกพารามิเตอร์เหล่านี้ลงในคำสั่ง BACKUP บันทึกบันทึกล่าสุดด้วยประวัติจาก msdb.dbo.backupset ลบไฟล์สำรองและการวนซ้ำครั้งถัดไป . เนื่องจากข้อมูลการดำเนินการสำรองข้อมูลถูกนำมาจากชุดข้อมูลสำรอง ความถูกต้องจึงหายไปบ้าง (ไม่มีเสี้ยววินาที) แต่เราจะอยู่รอดได้

ก่อนอื่นคุณต้องเปิดใช้งาน xp_cmdshell เพื่อลบข้อมูลสำรอง (จากนั้นอย่าลืมปิดการใช้งานหากคุณไม่ต้องการ):

EXEC sp_configure 'show advanced options', 1;  
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;
EXEC sp_configure 'show advanced options', 0;  
GO

จริงๆแล้ว:

DECLARE @tmplt AS nvarchar(max) = N'
BACKUP DATABASE [bt]
TO DISK = ''D:SQLServerbackupbt.bak''
WITH 
    COMPRESSION,
    BLOCKSIZE = {bs},
    BUFFERCOUNT = {bc},
    MAXTRANSFERSIZE = {ts}';

DECLARE @sql AS nvarchar(max);

/* BLOCKSIZE values */
DECLARE @bs     int = 4096, 
        @max_bs int = 65536;

/* BUFFERCOUNT values */
DECLARE @bc     int = 7,
        @min_bc int = 7,
        @max_bc int = 800;

/* MAXTRANSFERSIZE values */
DECLARE @ts     int = 524288,   --512KB, default = 1024KB
        @min_ts int = 524288,
        @max_ts int = 4194304;  --4MB

SELECT TOP 1 
    @bs = COALESCE (block_size, 4096), 
    @bc = COALESCE (buffer_count, 7), 
    @ts = COALESCE (transfer_size, 524288)
FROM ##bt_results
ORDER BY id DESC;

WHILE (@bs <= @max_bs)
BEGIN
    WHILE (@bc <= @max_bc)
    BEGIN       
        WHILE (@ts <= @max_ts)
        BEGIN
            SET @sql = REPLACE (REPLACE (REPLACE(@tmplt, N'{bs}', CAST(@bs AS nvarchar(50))), N'{bc}', CAST (@bc AS nvarchar(50))), N'{ts}', CAST (@ts AS nvarchar(50)));

            EXEC (@sql);

            INSERT INTO ##bt_results (start_date, finish_date, backup_size, compressed_size, block_size, buffer_count, transfer_size)
            SELECT TOP 1 backup_start_date, backup_finish_date, backup_size, compressed_backup_size,  @bs, @bc, @ts 
            FROM msdb.dbo.backupset
            ORDER BY backup_set_id DESC;

            EXEC xp_cmdshell 'del "D:SQLServerbackupbt.bak"', no_output;

            SET @ts += @ts;
        END
        
        SET @bc += @bc;
        SET @ts = @min_ts;

        WAITFOR DELAY '00:00:05';
    END

    SET @bs += @bs;
    SET @bc = @min_bc;
    SET @ts = @min_ts;
END

หากคุณต้องการคำชี้แจงอย่างกะทันหันเกี่ยวกับสิ่งที่เกิดขึ้นที่นี่ โปรดเขียนความคิดเห็นหรือ PM สำหรับตอนนี้ ฉันจะบอกคุณเกี่ยวกับพารามิเตอร์ที่ฉันใส่ไว้ในฐานข้อมูลสำรองเท่านั้น

สำหรับ BLOCKSIZE เรามีรายการค่า "ปิด" และฉันไม่ได้สำรองข้อมูลด้วย BLOCKSIZE < 4KB MAXTRANSFERSIZE หมายเลขใด ๆ ที่เป็นทวีคูณของ 64KB - ตั้งแต่ 64KB ถึง 4MB ค่าเริ่มต้นในระบบของฉันคือ 1024KB ฉันใช้ 512 - 1024 - 2048 - 4096

มันยากกว่าด้วย BUFFERCOUNT - อาจเป็นจำนวนบวกก็ได้ แต่ลิงก์บอกว่า มีการคำนวณใน BACKUP DATABASE อย่างไร และเหตุใดค่าขนาดใหญ่จึงเป็นอันตราย. นอกจากนี้ยังระบุวิธีรับข้อมูลเกี่ยวกับ BUFFERCOUNT ที่ทำการสำรองข้อมูลจริง ๆ - สำหรับฉันมันคือ 7 ไม่มีประเด็นใดที่จะลดมันลงและค้นพบขีดจำกัดสูงสุดจากการทดลอง - โดยที่ BUFFERCOUNT = 896 และ MAXTRANSFERSIZE = 4194304 การสำรองข้อมูลล้มลงด้วย ข้อผิดพลาด (ซึ่งเขียนไว้ในลิงก์ด้านบน):

ข่าวสารเกี่ยวกับ 3013 ระดับ 16 สถานะ 1 บรรทัด 7 ฐานข้อมูลสำรองกำลังยุติการทำงานอย่างผิดปกติ

ข่าวสารเกี่ยวกับ 701 ระดับ 17 สถานะ 123 บรรทัด 7 มีหน่วยความจำระบบไม่เพียงพอในกลุ่มทรัพยากร 'ค่าเริ่มต้น' เพื่อเรียกใช้แบบสอบถามนี้

เพื่อการเปรียบเทียบ ก่อนอื่นฉันจะแสดงผลลัพธ์ของการสำรองข้อมูลโดยไม่ต้องระบุพารามิเตอร์ใดๆ เลย:

BACKUP DATABASE [bt]
TO DISK = 'D:SQLServerbackupbt.bak'
WITH COMPRESSION;

สำรองและสำรองข้อมูล:

ประมวลผล 1070072 หน้าสำหรับฐานข้อมูล 'bt', ไฟล์ 'bt' ในไฟล์ 1

ประมวลผล 2 หน้าสำหรับฐานข้อมูล 'bt' ไฟล์ 'bt_log' ในไฟล์ 1

ฐานข้อมูลสำรองประมวลผลเพจ 1070074 สำเร็จใน 53.171 วินาที (157.227 MB/วินาที)

สคริปต์เองกำลังทดสอบพารามิเตอร์ ทำงานได้ภายในสองสามชั่วโมง การวัดทั้งหมดเสร็จสิ้นแล้ว สเปรดชีตของ Google. และนี่คือตัวเลือกผลลัพธ์ที่มีเวลาดำเนินการที่ดีที่สุดสามครั้ง (ฉันพยายามสร้างกราฟที่ดี แต่ในโพสต์ฉันจะต้องทำตารางและในความคิดเห็น @มิกซ์เจอร์ เขาเสริม กราฟิกที่ยอดเยี่ยมมาก).

SELECT TOP 7 WITH TIES 
    compressed_size, 
    block_size, 
    buffer_count, 
    transfer_size,
    DATEDIFF(SECOND, start_date, finish_date) AS backup_time_sec
FROM ##bt_results
ORDER BY backup_time_sec ASC;

Attention, หมายเหตุที่สำคัญมากจาก @มิกซ์เจอร์ ของ แสดงความคิดเห็น:

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

เหล่านั้น. การจัดการพารามิเตอร์การสำรองข้อมูลมาตรฐานเท่านั้นที่ทำให้เวลาในการลบข้อมูลสำรองเพิ่มขึ้น 2 เท่า: 26 วินาที เทียบกับ 53 วินาทีในช่วงเริ่มต้น นั่นก็ไม่เลวใช่มั้ย? แต่เราต้องดูว่าจะเกิดอะไรขึ้นกับการฟื้นฟู จะเกิดอะไรขึ้นถ้าตอนนี้ใช้เวลาฟื้นตัวนานกว่า 4 เท่า?

ขั้นแรก มาวัดว่าต้องใช้เวลานานเท่าใดในการกู้คืนข้อมูลสำรองด้วยการตั้งค่าเริ่มต้น:

RESTORE DATABASE [bt]
FROM DISK = 'D:SQLServerbackupbt.bak'
WITH REPLACE, RECOVERY;

คุณเองก็รู้ดีว่ามีวิธีอยู่ การแทนที่ไม่ใช่การแทนที่ การฟื้นตัวไม่ใช่การฟื้นตัว และฉันก็ทำแบบนี้:

ประมวลผล 1070072 หน้าสำหรับฐานข้อมูล 'bt', ไฟล์ 'bt' ในไฟล์ 1

ประมวลผล 2 หน้าสำหรับฐานข้อมูล 'bt' ไฟล์ 'bt_log' ในไฟล์ 1

คืนค่าฐานข้อมูลประมวลผลเพจ 1070074 สำเร็จใน 40.752 วินาที (205.141 MB/วินาที)

ตอนนี้ฉันจะพยายามกู้คืนข้อมูลสำรองที่มีการเปลี่ยนแปลง BLOCKSIZE, BUFFERCOUNT และ MAXTRANSFERSIZE

BLOCKSIZE = 16384, BUFFERCOUNT = 224, MAXTRANSFERSIZE = 4194304

คืนค่าฐานข้อมูลประมวลผลเพจ 1070074 สำเร็จใน 32.283 วินาที (258.958 MB/วินาที)

BLOCKSIZE = 4096, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 4194304

คืนค่าฐานข้อมูลประมวลผลเพจ 1070074 สำเร็จใน 32.682 วินาที (255.796 MB/วินาที)

BLOCKSIZE = 16384, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 2097152

คืนค่าฐานข้อมูลประมวลผลเพจ 1070074 สำเร็จใน 32.091 วินาที (260.507 MB/วินาที)

BLOCKSIZE = 4096, BUFFERCOUNT = 56, MAXTRANSFERSIZE = 4194304

คืนค่าฐานข้อมูลประมวลผลเพจ 1070074 สำเร็จใน 32.401 วินาที (258.015 MB/วินาที)

คำสั่ง RESTORE DATABASE จะไม่เปลี่ยนแปลงระหว่างการกู้คืน ไม่ได้ระบุพารามิเตอร์เหล่านี้ในนั้น SQL Server จะกำหนดพารามิเตอร์เหล่านั้นจากการสำรองข้อมูล และเป็นที่ชัดเจนว่าแม้จะฟื้นตัวก็ยังสามารถได้รับกำไร - เร็วขึ้นเกือบ 20% (พูดตามตรง ฉันไม่ได้ใช้เวลามากนักในการกู้คืน ฉันลองใช้การสำรองข้อมูลที่ "เร็วที่สุด" หลายครั้งและทำให้แน่ใจว่าไม่มีการเสื่อมสภาพ).

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

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

ตั้งแต่ฉันเริ่มเขียนเกี่ยวกับการสำรองข้อมูลฉันต้องการเขียนเกี่ยวกับ "การเพิ่มประสิทธิภาพ" อีกหนึ่งรายการทันทีซึ่งเป็นเรื่องปกติมากกว่าพารามิเตอร์ "การปรับแต่ง" (เท่าที่ฉันเข้าใจมันถูกใช้โดยยูทิลิตี้สำรองข้อมูลอย่างน้อยบางตัวอาจใช้ร่วมกับพารามิเตอร์ อธิบายไว้ก่อนหน้านี้) แต่ยังไม่ได้อธิบายไว้ในHabréเช่นกัน

หากเราดูบรรทัดที่สองในเอกสารประกอบ ใต้ฐานข้อมูลสำรอง เราจะเห็น:

TO <backup_device> [ ,...n ]

คุณคิดว่าจะเกิดอะไรขึ้นหากคุณระบุ backup_device หลายเครื่อง ไวยากรณ์อนุญาต และสิ่งที่น่าสนใจมากจะเกิดขึ้น - การสำรองข้อมูลจะ "กระจาย" ไปยังอุปกรณ์ต่างๆ เหล่านั้น. “อุปกรณ์” แต่ละเครื่องจะไม่มีประโยชน์ สูญหายไปหนึ่งเครื่อง สูญเสียข้อมูลสำรองทั้งหมด แต่การละเลงดังกล่าวจะส่งผลต่อความเร็วในการสำรองข้อมูลอย่างไร

มาลองสำรองข้อมูลใน “อุปกรณ์” สองเครื่องที่อยู่เคียงข้างกันในโฟลเดอร์เดียวกัน:

BACKUP DATABASE [bt]
TO 
    DISK = 'D:SQLServerbackupbt1.bak',
    DISK = 'D:SQLServerbackupbt2.bak'   
WITH COMPRESSION;

บิดาแห่งโลก ทำไมจึงทำเช่นนี้?

ประมวลผล 1070072 หน้าสำหรับฐานข้อมูล 'bt', ไฟล์ 'bt' ในไฟล์ 1

ประมวลผล 2 หน้าสำหรับฐานข้อมูล 'bt' ไฟล์ 'bt'เข้าสู่ระบบ' ในไฟล์ 1.

ฐานข้อมูลสำรองประมวลผลเพจ 1070074 สำเร็จใน 40.092 วินาที (208.519 MB/วินาที)

การสำรองข้อมูลเร็วขึ้น 25% ทันทีหรือไม่? จะเกิดอะไรขึ้นถ้าเราเพิ่มอุปกรณ์อีกสองสามเครื่อง?

BACKUP DATABASE [bt]
TO 
    DISK = 'D:SQLServerbackupbt1.bak',
    DISK = 'D:SQLServerbackupbt2.bak',
    DISK = 'D:SQLServerbackupbt3.bak',
    DISK = 'D:SQLServerbackupbt4.bak'
WITH COMPRESSION;

ฐานข้อมูลสำรองประมวลผลเพจ 1070074 สำเร็จใน 34.234 วินาที (244.200 MB/วินาที)

โดยรวมแล้วจะได้รับประมาณ 35% ของเวลาในการสำรองข้อมูลเนื่องจากการสำรองข้อมูลถูกเขียนไปยังไฟล์ 4 ไฟล์ในดิสก์เดียวในคราวเดียว ฉันตรวจสอบจำนวนที่มากขึ้น - แล็ปท็อปของฉันไม่ได้รับผลกำไรอย่างเหมาะสมที่สุด - อุปกรณ์ 4 เครื่อง สำหรับคุณ - ฉันไม่รู้ คุณต้องตรวจสอบ อย่างไรก็ตามหากคุณมีอุปกรณ์เหล่านี้ - ดิสก์เหล่านี้เป็นดิสก์ที่แตกต่างกันมากขอแสดงความยินดีการได้รับควรมีความสำคัญมากยิ่งขึ้น

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

RESTORE DATABASE [bt]
FROM 
    DISK = 'D:SQLServerbackupbt1.bak',
    DISK = 'D:SQLServerbackupbt2.bak',
    DISK = 'D:SQLServerbackupbt3.bak',
    DISK = 'D:SQLServerbackupbt4.bak'
WITH REPLACE, RECOVERY;

คืนค่าฐานข้อมูลประมวลผลเพจ 1070074 สำเร็จใน 38.027 วินาที (219.842 MB/วินาที)

เร็วขึ้นเล็กน้อย แต่อยู่ใกล้ๆ ไม่มีนัยสำคัญ โดยทั่วไปการสำรองข้อมูลจะถูกลบออกเร็วขึ้นและกู้คืนในลักษณะเดียวกัน - สำเร็จหรือไม่ สำหรับฉันมันค่อนข้างประสบความสำเร็จ นี้ มันเป็นสิ่งสำคัญฉันจึงขอย้ำอีกครั้ง - ถ้าคุณ หากคุณสูญเสียไฟล์เหล่านี้อย่างน้อยหนึ่งไฟล์ คุณจะสูญเสียข้อมูลสำรองทั้งหมด.

หากคุณดูในบันทึกข้อมูลการสำรองข้อมูลที่แสดงโดยใช้ Trace Flags 3213 และ 3605 คุณจะสังเกตเห็นว่าเมื่อสำรองข้อมูลไปยังอุปกรณ์หลายเครื่อง จำนวน BUFFERCOUNT จะเพิ่มขึ้นเป็นอย่างน้อย อาจเป็นไปได้ว่าคุณสามารถลองเลือกพารามิเตอร์ที่เหมาะสมที่สุดสำหรับ BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE ได้ แต่ฉันไม่ประสบความสำเร็จในทันทีและฉันขี้เกียจเกินไปที่จะดำเนินการทดสอบดังกล่าวอีกครั้ง แต่สำหรับไฟล์จำนวนอื่น และมันก็น่าเสียดายเรื่องล้อ หากคุณต้องการจัดการการทดสอบดังกล่าวที่บ้าน การสร้างสคริปต์ใหม่ไม่ใช่เรื่องยาก

สุดท้ายนี้เรามาพูดถึงเรื่องราคากันดีกว่า หากการสำรองข้อมูลถูกลบควบคู่ไปกับงานของผู้ใช้ คุณจะต้องใช้แนวทางการทดสอบที่มีความรับผิดชอบสูง เพราะหากการสำรองข้อมูลถูกลบเร็วกว่า ดิสก์จะถูกตึงมากขึ้น โหลดบนโปรเซสเซอร์จะเพิ่มขึ้น (คุณยังต้องบีบอัด ได้ทันที) และการตอบสนองโดยรวมของระบบก็ลดลงตามไปด้วย

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

โปรดจำไว้ว่าทุกสิ่งที่คุณทำนั้นทำด้วยความเสี่ยงและอันตรายของคุณเอง ตรวจสอบข้อมูลสำรองของคุณและอย่าลืม DBCC CHECKDB

ที่มา: will.com