MS SQL Server: BackUP ກ່ຽວກັບ steroids

ລໍຖ້າ! ລໍຖ້າ! ແທ້ຈິງແລ້ວ, ນີ້ບໍ່ແມ່ນບົດຄວາມອື່ນກ່ຽວກັບປະເພດຂອງການສໍາຮອງຂໍ້ມູນ SQL Server. ຂ້າ​ພະ​ເຈົ້າ​ຈະ​ບໍ່​ແມ່ນ​ແຕ່​ເວົ້າ​ກ່ຽວ​ກັບ​ຄວາມ​ແຕກ​ຕ່າງ​ລະ​ຫວ່າງ​ຮູບ​ແບບ​ການ​ຟື້ນ​ຕົວ​ແລະ​ວິ​ທີ​ການ​ທີ່​ຈະ​ແກ້​ໄຂ​ບັນ​ທຶກ overgrown​.

ບາງທີ (ບາງທີ), ຫຼັງຈາກອ່ານຂໍ້ຄວາມນີ້, ທ່ານຈະສາມາດເຮັດໃຫ້ແນ່ໃຈວ່າການສໍາຮອງຂໍ້ມູນທີ່ຖືກລຶບອອກຈາກເຈົ້າໂດຍໃຊ້ວິທີການມາດຕະຖານຈະຖືກລຶບອອກໃນຄືນມື້ອື່ນ, ດີ, ໄວກວ່າ 1.5 ເທົ່າ. ແລະພຽງແຕ່ຍ້ອນຄວາມຈິງທີ່ວ່າທ່ານໃຊ້ຕົວກໍານົດການ BACKUP DATABASE ເລັກນ້ອຍ.

ຖ້າເນື້ອໃນຂອງຂໍ້ຄວາມຈະແຈ້ງຕໍ່ເຈົ້າ, ຂ້ອຍຂໍໂທດ. ຂ້າພະເຈົ້າໄດ້ອ່ານທຸກສິ່ງທຸກຢ່າງທີ່ Google ໄດ້ຮັບສໍາລັບຄໍາວ່າ "habr sql server backup", ແລະໃນບົດຄວາມດຽວບໍ່ໄດ້ພົບເຫັນການກ່າວເຖິງໃດໆກ່ຽວກັບຄວາມຈິງທີ່ວ່າເວລາສໍາຮອງຂໍ້ມູນສາມາດມີອິດທິພົນບາງຢ່າງໂດຍໃຊ້ຕົວກໍານົດການ.

ຂ້າ​ພະ​ເຈົ້າ​ທັນ​ທີ​ທັນ​ໃດ​ຈະ​ດຶງ​ດູດ​ຄວາມ​ສົນ​ໃຈ​ຂອງ​ທ່ານ​ກັບ​ຄໍາ​ເຫັນ​ຂອງ Alexander Gladchenko (@mssqlhelp):

ຢ່າປ່ຽນພາລາມິເຕີ BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE ໃນການຜະລິດ. ເຂົາເຈົ້າໄດ້ຖືກສ້າງຂື້ນພຽງແຕ່ສໍາລັບການຂຽນບົດຄວາມດັ່ງກ່າວ. ໃນ​ການ​ປະ​ຕິ​ບັດ​, ທ່ານ​ຈະ​ໄດ້​ຮັບ​ການ​ກໍາ​ຈັດ​ຂອງ​ບັນ​ຫາ​ຄວາມ​ຊົງ​ຈໍາ​ໃນ​ເວ​ລາ​ທີ່​ບໍ່​ມີ​.

ແນ່ນອນ, ມັນຈະເປັນການດີທີ່ຈະເປັນເນື້ອຫາທີ່ສະຫຼາດທີ່ສຸດແລະປະກາດເນື້ອຫາສະເພາະ, ແຕ່ຫນ້າເສຍດາຍ, ນີ້ບໍ່ແມ່ນກໍລະນີ. ມີທັງບົດຄວາມ/ບົດຄວາມທີ່ເປັນພາສາອັງກິດ ແລະ ພາສາລັດເຊຍ (ຂ້າພະເຈົ້າຮູ້ສຶກສັບສົນສະເໝີກ່ຽວກັບສິ່ງທີ່ຈະເອີ້ນໃຫ້ຖືກຕ້ອງ) ທີ່ອຸທິດໃຫ້ກັບຫົວຂໍ້ນີ້. ນີ້ແມ່ນບາງອັນທີ່ຂ້ອຍພົບ: ເວລາ, два, ສາມ (ໃນ sql.ru).

ດັ່ງນັ້ນ, ເພື່ອເລີ່ມຕົ້ນດ້ວຍ, ຂ້ອຍຈະຄັດຕິດ syntax BACKUP ທີ່ຖືກຖອດອອກເລັກນ້ອຍຈາກ MSDN (ໂດຍວິທີທາງການ, ຂ້າພະເຈົ້າໄດ້ຂຽນຂ້າງເທິງກ່ຽວກັບ BACKUP DATABASE, ແຕ່ທັງຫມົດນີ້ໃຊ້ກັບທັງການສໍາຮອງຂໍ້ມູນບັນທຶກການເຮັດທຸລະກໍາແລະການສໍາຮອງຂໍ້ມູນທີ່ແຕກຕ່າງກັນ, ແຕ່ບາງທີອາດມີຜົນກະທົບທີ່ຊັດເຈນຫນ້ອຍ):

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, ຂ້າມ. ທ່ານໄດ້ໄປຢ້ຽມຢາມ MSDN ບໍ? ທ່ານເຫັນວ່າມີທາງເລືອກສໍາລັບຫນ້າຈໍຫນຶ່ງແລະເຄິ່ງຫນຶ່ງບໍ? ຂ້າ​ພະ​ເຈົ້າ​ຍັງ​ໄດ້​ເຫັນ ...

ທ່ານອາດຈະຮູ້ແລ້ວວ່າຕໍ່ໄປພວກເຮົາຈະເວົ້າກ່ຽວກັບສາມຕົວກໍານົດການທີ່ຍັງຄົງຢູ່ໃນລະຫັດທໍາອິດ - BLOCKSIZE, BUFFERCOUNT ແລະ MAXTRANSFERSIZE. ນີ້ແມ່ນຄໍາອະທິບາຍຂອງເຂົາເຈົ້າຈາກ MSDN:

BLOCKSIZE = { ຂະໜາດ | @ blocksize_variable } - ຊີ້ບອກຂະໜາດບຼັອກທາງກາຍະພາບໃນໄບຕ໌. ຂະໜາດທີ່ຮອງຮັບແມ່ນ 512, 1024, 2048, 4096, 8192, 16, 384, ແລະ 32 bytes (768 KB). ຄ່າເລີ່ມຕົ້ນແມ່ນ 65 ສໍາລັບອຸປະກອນ tape ແລະ 536 ສໍາລັບອຸປະກອນອື່ນໆ. ໂດຍປົກກະຕິພາລາມິເຕີນີ້ບໍ່ຈໍາເປັນເພາະວ່າຄໍາຖະແຫຼງການ BACKUP ຈະເລືອກຂະຫນາດບລັອກທີ່ເຫມາະສົມສໍາລັບອຸປະກອນໂດຍອັດຕະໂນມັດ. ການຕັ້ງຄ່າຂະໜາດບລັອກຈະລົບລ້າງການເລືອກຂະໜາດບລັອກອັດຕະໂນມັດຢ່າງຈະແຈ້ງ.

BUFFERCOUNT = { buffercount | @ buffercount_variable } - ກຳນົດຈຳນວນທັງໝົດຂອງ I/O buffers ທີ່ຈະໃຊ້ສຳລັບການດຳເນີນການສຳຮອງ. ທ່ານສາມາດກໍານົດຄ່າຈໍານວນບວກໃດໆ, ແຕ່ຈໍານວນ buffers ຈໍານວນຫຼວງຫຼາຍອາດຈະເຮັດໃຫ້ເກີດຄວາມຜິດພາດທີ່ຢູ່ນອກຫນ່ວຍຄວາມຈໍາເນື່ອງຈາກພື້ນທີ່ທີ່ຢູ່ virtual ຫຼາຍເກີນໄປໃນຂະບວນການ Sqlservr.exe.

ຈຳນວນພື້ນທີ່ທັງໝົດທີ່ໃຊ້ໂດຍ buffers ແມ່ນກຳນົດໂດຍສູດຕໍ່ໄປນີ້: BUFFERCOUNT * MAXTRANSFERSIZE.

ຂະຫຍາຍສູງສຸດ = { maxtransfersize | @ maxtransfersize_variable } ລະບຸຂະໜາດແພັກເກັດຂໍ້ມູນທີ່ໃຫຍ່ທີ່ສຸດ, ເປັນໄບຕ໌, ເພື່ອແລກປ່ຽນລະຫວ່າງ SQL Server ແລະສື່ຊຸດສຳຮອງ. ຮອງຮັບຫຼາຍ 65 bytes (536 KB) ສູງສຸດ 64 bytes (4 MB).

ຂ້າ​ພະ​ເຈົ້າ​ສາ​ບານ - ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ອ່ານ​ນີ້​ມາ​ກ່ອນ​, ແຕ່​ວ່າ​ມັນ​ບໍ່​ເຄີຍ​ເກີດ​ຂຶ້ນ​ກັບ​ຂ້າ​ພະ​ເຈົ້າ​ຫຼາຍ​ປານ​ໃດ​ຂອງ​ຜົນ​ກະ​ທົບ​ທີ່​ເຂົາ​ເຈົ້າ​ສາ​ມາດ​ມີ​ຕໍ່​ຜະ​ລິດ​ຕະ​ພັນ​. ຍິ່ງໄປກວ່ານັ້ນ, ເຫັນໄດ້ຊັດເຈນ, ຂ້ອຍຈໍາເປັນຕ້ອງສ້າງປະເພດຂອງ "ອອກມາ" ແລະຍອມຮັບວ່າເຖິງແມ່ນວ່າຕອນນີ້ຂ້ອຍບໍ່ເຂົ້າໃຈຢ່າງສົມບູນກ່ຽວກັບສິ່ງທີ່ພວກເຂົາເຮັດ. ຂ້ອຍອາດຈະຕ້ອງອ່ານເພີ່ມເຕີມກ່ຽວກັບ buffered 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
);

ຫຼັກການຂອງສະຄິບແມ່ນງ່າຍດາຍ - loops nested, ແຕ່ລະການປ່ຽນແປງຄ່າຂອງຫນຶ່ງພາລາມິເຕີ, ໃສ່ຕົວກໍານົດການເຫຼົ່ານີ້ເຂົ້າໄປໃນຄໍາສັ່ງ BACKUP, ບັນທຶກບັນທຶກສຸດທ້າຍທີ່ມີປະຫວັດສາດຈາກ msdb.dbo.backupset, ລຶບໄຟລ໌ສໍາຮອງຂໍ້ມູນແລະ iteration ຕໍ່ໄປ. . ນັບຕັ້ງແຕ່ຂໍ້ມູນການປະຕິບັດການສໍາຮອງຂໍ້ມູນໄດ້ຖືກເອົາມາຈາກຊຸດສໍາຮອງ, ຄວາມຖືກຕ້ອງແມ່ນສູນເສຍບາງຢ່າງ (ບໍ່ມີສ່ວນຫນຶ່ງຂອງວິນາທີ), ແຕ່ພວກເຮົາຈະຢູ່ລອດນີ້.

ກ່ອນອື່ນ ໝົດ ທ່ານຕ້ອງເປີດໃຊ້ 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. ສໍາລັບຕອນນີ້, ຂ້ອຍຈະບອກເຈົ້າກ່ຽວກັບພາລາມິເຕີທີ່ຂ້ອຍໃສ່ໃນ BACKUP DATABASE.

ສໍາລັບ BLOCKSIZE ພວກເຮົາມີລາຍການ "ປິດ" ຂອງຄ່າ, ແລະຂ້ອຍບໍ່ໄດ້ປະຕິບັດການສໍາຮອງຂໍ້ມູນກັບ BLOCKSIZE < 4KB. MAXTRANSFERSIZE ຕົວເລກໃດນຶ່ງທີ່ເປັນຄູນຂອງ 64KB - ຈາກ 64KB ຫາ 4MB. ຄ່າເລີ່ມຕົ້ນໃນລະບົບຂອງຂ້ອຍແມ່ນ 1024KB, ຂ້ອຍເອົາ 512 - 1024 - 2048 - 4096.

ມັນມີຄວາມຫຍຸ້ງຍາກຫຼາຍກັບ BUFFERCOUNT - ມັນສາມາດເປັນຕົວເລກບວກໃດໆ, ແຕ່ການເຊື່ອມຕໍ່ເວົ້າວ່າ ມັນຖືກຄິດໄລ່ແນວໃດໃນ BACKUP DATABASE ແລະເປັນຫຍັງຄ່າຂະຫນາດໃຫຍ່ຈຶ່ງເປັນອັນຕະລາຍ?. ມັນຍັງເວົ້າວ່າວິທີການໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບວ່າ BUFFERCOUNT ສໍາຮອງຂໍ້ມູນຕົວຈິງແມ່ນເຮັດດ້ວຍ - ສໍາລັບຂ້ອຍມັນແມ່ນ 7. ບໍ່ມີຈຸດໃດໃນການຫຼຸດຜ່ອນມັນ, ແລະຂອບເຂດຈໍາກັດເທິງໄດ້ຖືກຄົ້ນພົບໂດຍການທົດລອງ - ກັບ BUFFERCOUNT = 896 ແລະ MAXTRANSFERSIZE = 4194304 ການສໍາຮອງຂໍ້ມູນຫຼຸດລົງກັບ ຂໍ້ຜິດພາດ (ກ່ຽວກັບສິ່ງທີ່ຂຽນໄວ້ໃນການເຊື່ອມຕໍ່ຂ້າງເທິງ):

Msg 3013, Level 16, State 1, Line 7 BACKUP DATABASE ກໍາລັງຢຸດເຮັດວຽກຜິດປົກກະຕິ.

Msg 701, Level 17, State 123, Line 7 ມີຄວາມຈຳຂອງລະບົບບໍ່ພຽງພໍໃນ resource pool 'default' ເພື່ອດໍາເນີນການສອບຖາມນີ້.

ສໍາລັບການປຽບທຽບ, ທໍາອິດຂ້າພະເຈົ້າຈະສະແດງຜົນຂອງການດໍາເນີນການສໍາຮອງຂໍ້ມູນໂດຍບໍ່ມີການກໍານົດພາລາມິເຕີໃດໆທັງຫມົດ:

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

ດີ, ສໍາຮອງຂໍ້ມູນແລະສໍາຮອງຂໍ້ມູນ:

ປະມວນຜົນ 1070072 ໜ້າສຳລັບຖານຂໍ້ມູນ 'bt', ໄຟລ໌ 'bt' ໃນໄຟລ໌ 1.

ປະມວນຜົນ 2 ໜ້າສຳລັບຖານຂໍ້ມູນ 'bt', ໄຟລ໌ 'bt_log' ໃນໄຟລ໌ 1.

BACKUP DATABASE ສຳເລັດການປະມວນຜົນ 1070074 ໜ້າພາຍໃນ 53.171 ວິນາທີ (157.227 MB/ວິນາທີ).

script ຕົວຂອງມັນເອງ, ການທົດສອບຕົວກໍານົດການ, ເຮັດວຽກໃນສອງສາມຊົ່ວໂມງ, ການວັດແທກທັງຫມົດແມ່ນຢູ່ໃນ google spreadsheet. ແລະນີ້ແມ່ນການຄັດເລືອກຜົນໄດ້ຮັບທີ່ມີສາມເວລາການປະຕິບັດທີ່ດີທີ່ສຸດ (ຂ້າພະເຈົ້າໄດ້ພະຍາຍາມສ້າງກາຟທີ່ສວຍງາມ, ແຕ່ໃນບົດຂຽນຂ້ອຍຈະຕ້ອງເຮັດກັບຕາຕະລາງ, ແລະໃນຄໍາເຫັນ. @mixsture ເພີ່ມ ຮູບພາບເຢັນຫຼາຍ).

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;

ເອົາ ໃຈ ໃສ່, ເປັນ ບັນ ທຶກ ທີ່ ສໍາ ຄັນ ຫຼາຍ ຈາກ @mixsture ຈາກນັ້ນ ຄຳ ເຫັນ:

ພວກເຮົາສາມາດເວົ້າໄດ້ຢ່າງຫມັ້ນໃຈວ່າການພົວພັນລະຫວ່າງຕົວກໍານົດການແລະຄວາມໄວສໍາຮອງຂໍ້ມູນພາຍໃນຂອບເຂດຂອງຄ່າເຫຼົ່ານີ້ແມ່ນແບບສຸ່ມ, ບໍ່ມີຮູບແບບ. ແຕ່ການເຄື່ອນຍ້າຍອອກຈາກຕົວກໍານົດການທີ່ສ້າງຂຶ້ນແນ່ນອນມີຜົນກະທົບທີ່ດີຕໍ່ຜົນໄດ້ຮັບ

ເຫຼົ່ານັ້ນ. ພຽງແຕ່ໂດຍການຈັດການຕົວກໍານົດການ BACKUP ມາດຕະຖານແມ່ນໄດ້ຮັບ 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​% ໄວ​ຂຶ້ນ (ດ້ວຍຄວາມຊື່ສັດ, ຂ້ອຍບໍ່ໄດ້ໃຊ້ເວລາຫຼາຍໃນການຟື້ນຕົວ, ຂ້ອຍແລ່ນຜ່ານການສໍາຮອງຂໍ້ມູນ "ໄວທີ່ສຸດ" ຫຼາຍໆຄັ້ງແລະໃຫ້ແນ່ໃຈວ່າບໍ່ມີການເສື່ອມໂຊມ.).

ໃນກໍລະນີໃດກໍ່ຕາມ, ຂ້າພະເຈົ້າຂໍຊີ້ແຈງວ່ານີ້ບໍ່ແມ່ນບາງຕົວກໍານົດທີ່ເຫມາະສົມທີ່ສຸດສໍາລັບທຸກຄົນ. ທ່ານພຽງແຕ່ສາມາດໄດ້ຮັບຕົວກໍານົດການທີ່ດີທີ່ສຸດສໍາລັບຕົວທ່ານເອງໂດຍການທົດສອບ. ຂ້າພະເຈົ້າໄດ້ຮັບຜົນໄດ້ຮັບເຫຼົ່ານີ້, ທ່ານຈະໄດ້ຮັບທີ່ແຕກຕ່າງກັນ. ແຕ່ທ່ານເຫັນວ່າທ່ານສາມາດ "ປັບ" ການສໍາຮອງຂໍ້ມູນຂອງທ່ານແລະຕົວຈິງແລ້ວພວກເຂົາສາມາດສ້າງແລະປະຕິບັດໄດ້ໄວຂຶ້ນ.

ຂ້າພະເຈົ້າຍັງແນະນໍາໃຫ້ທ່ານອ່ານເອກະສານທັງຫມົດ, ເພາະວ່າມັນອາດຈະມີ nuances ສະເພາະກັບລະບົບຂອງທ່ານ.

ນັບຕັ້ງແຕ່ຂ້ອຍເລີ່ມຂຽນກ່ຽວກັບການສໍາຮອງຂໍ້ມູນ, ຂ້ອຍຕ້ອງການຂຽນທັນທີກ່ຽວກັບ "ການເພີ່ມປະສິດທິພາບ", ເຊິ່ງແມ່ນທົ່ວໄປຫຼາຍກ່ວາຕົວກໍານົດການ "ປັບ" (ເທົ່າທີ່ຂ້ອຍເຂົ້າໃຈ, ມັນຖືກນໍາໃຊ້ໂດຍຢ່າງຫນ້ອຍບາງສິ່ງອໍານວຍຄວາມສະດວກສໍາຮອງ, ບາງທີອາດມີຕົວກໍານົດການ. ໄດ້ອະທິບາຍໄວ້ກ່ອນໜ້ານີ້), ແຕ່ມັນຍັງບໍ່ທັນໄດ້ອະທິບາຍກ່ຽວກັບ Habre ຄືກັນ.

ຖ້າພວກເຮົາເບິ່ງແຖວທີສອງໃນເອກະສານ, ພາຍໃຕ້ BACKUP DATABASE, ພວກເຮົາເຫັນ:

TO <backup_device> [ ,...n ]

ເຈົ້າຄິດວ່າຈະເກີດຫຍັງຂຶ້ນຫາກເຈົ້າລະບຸອຸປະກອນສຳຮອງຫຼາຍອັນ? syntax ອະນຸຍາດໃຫ້ມັນ. ແລະສິ່ງທີ່ຫນ້າສົນໃຈຫຼາຍຈະເກີດຂຶ້ນ - ການສໍາຮອງຂໍ້ມູນພຽງແຕ່ຈະ "ແຜ່ຂະຫຍາຍ" ໃນໄລຍະອຸປະກອນຈໍານວນຫນຶ່ງ. ເຫຼົ່ານັ້ນ. ແຕ່ລະ "ອຸປະກອນ" ສ່ວນບຸກຄົນຈະບໍ່ມີປະໂຫຍດ, ສູນເສຍຫນຶ່ງ, ສູນເສຍການສໍາຮອງຂໍ້ມູນທັງຫມົດ. ແຕ່ການ smearing ດັ່ງກ່າວຈະມີຜົນກະທົບຄວາມໄວການສໍາຮອງຂໍ້ມູນແນວໃດ?

ໃຫ້ພະຍາຍາມເຮັດການສໍາຮອງຂໍ້ມູນໃນສອງ "ອຸປະກອນ" ທີ່ຕັ້ງຢູ່ຂ້າງຄຽງຢູ່ໃນໂຟນເດີດຽວກັນ:

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

ພໍ່​ຂອງ​ໂລກ, ເປັນ​ຫຍັງ​ຈຶ່ງ​ຖືກ​ເຮັດ​ແບບ​ນີ້?

ປະມວນຜົນ 1070072 ໜ້າສຳລັບຖານຂໍ້ມູນ 'bt', ໄຟລ໌ 'bt' ໃນໄຟລ໌ 1.

ປະມວນຜົນ 2 ໜ້າສຳລັບຖານຂໍ້ມູນ 'bt', ໄຟລ໌ 'bt'ເຂົ້າ​ສູ່​ລະ​ບົບ 1.

BACKUP DATABASE ສຳເລັດການປະມວນຜົນ 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;

BACKUP DATABASE ສຳເລັດການປະມວນຜົນ 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.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com