🥇MS SQL சர்வர்: ஸ்டெராய்டுகளில் காப்புப்பிரதி

காத்திரு! காத்திரு! உண்மை, இது SQL சர்வர் காப்புப்பிரதிகளின் வகைகளைப் பற்றிய மற்றொரு கட்டுரை அல்ல. மீட்டெடுப்பு மாதிரிகள் மற்றும் அதிகப்படியான பதிவை எவ்வாறு சமாளிப்பது ஆகியவற்றுக்கு இடையேயான வேறுபாடுகளைப் பற்றி கூட நான் பேசமாட்டேன்.

ஒருவேளை (ஒருவேளை), இந்த இடுகையைப் படித்த பிறகு, நிலையான வழிமுறைகளைப் பயன்படுத்தி உங்களிடமிருந்து அகற்றப்பட்ட காப்புப்பிரதி நாளை இரவு 1.5 மடங்கு வேகமாக அகற்றப்படும் என்பதை நீங்கள் உறுதிசெய்ய முடியும். நீங்கள் இன்னும் கொஞ்சம் BACKUP DATABASE அளவுருக்களைப் பயன்படுத்துவதால் மட்டுமே.

இடுகையின் உள்ளடக்கம் உங்களுக்குத் தெளிவாக இருந்தால், மன்னிக்கவும். "habr sql சர்வர் காப்புப்பிரதி" என்ற சொற்றொடருக்காக கூகிள் பெற்ற அனைத்தையும் நான் படித்தேன், மேலும் ஒரு கட்டுரையில் கூட அளவுருக்களைப் பயன்படுத்தி காப்பு நேரத்தை எப்படியாவது பாதிக்கலாம் என்ற உண்மையைப் பற்றி எதுவும் குறிப்பிடவில்லை.

அலெக்சாண்டர் கிளாட்செங்கோவின் கருத்துக்கு நான் உடனடியாக உங்கள் கவனத்தை ஈர்க்கிறேன் (@mssqlhelp):

உற்பத்தியில் BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE அளவுருக்களை மாற்ற வேண்டாம். அவை அத்தகைய கட்டுரைகளை எழுதுவதற்காக மட்டுமே உருவாக்கப்பட்டவை. நடைமுறையில், நீங்கள் எந்த நேரத்திலும் நினைவாற்றல் பிரச்சனைகளில் இருந்து விடுபடுவீர்கள்.

நிச்சயமாக, புத்திசாலித்தனமான மற்றும் பிரத்தியேக உள்ளடக்கத்தை இடுகையிடுவது மகிழ்ச்சியாக இருக்கும், ஆனால், துரதிர்ஷ்டவசமாக, இது அவ்வாறு இல்லை. இந்த தலைப்புக்கு அர்ப்பணிக்கப்பட்ட ஆங்கில மொழி மற்றும் ரஷ்ய மொழி கட்டுரைகள்/பதிவுகள் இரண்டும் உள்ளன (எதைச் சரியாக அழைப்பது என்பதில் எனக்கு எப்போதும் குழப்பம் உள்ளது). நான் கண்டவைகளில் சில இங்கே: நேரம், два, மூன்று (sql.ru இல்).

எனவே, தொடங்குவதற்கு, இதிலிருந்து சற்று அகற்றப்பட்ட BACKUP தொடரியல் இணைக்கிறேன் எம்.எஸ்.டி.என் (இதன் மூலம், காப்புப் பிரதி தரவுத்தளத்தைப் பற்றி நான் மேலே எழுதினேன், ஆனால் இவை அனைத்தும் பரிவர்த்தனை பதிவு காப்புப்பிரதி மற்றும் வேறுபட்ட காப்புப்பிரதி ஆகிய இரண்டிற்கும் பொருந்தும், ஆனால் குறைவான வெளிப்படையான விளைவுடன் இருக்கலாம்):

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 இலிருந்து அவர்களின் விளக்கங்கள் இங்கே:

பிளாக்சைஸ் = { தொகுதி அளவு | @ blocksize_variable } - பைட்டுகளில் இயற்பியல் தொகுதி அளவைக் குறிக்கிறது. ஆதரிக்கப்படும் அளவுகள் 512, 1024, 2048, 4096, 8192, 16, 384 மற்றும் 32 பைட்டுகள் (768 KB). டேப் சாதனங்களுக்கு இயல்புநிலை மதிப்பு 65 மற்றும் பிற சாதனங்களுக்கு 536 ஆகும். பொதுவாக இந்த அளவுரு அவசியமில்லை, ஏனெனில் BACKUP அறிக்கை தானாகவே சாதனத்திற்கான பொருத்தமான தொகுதி அளவைத் தேர்ந்தெடுக்கும். தொகுதி அளவை அமைப்பது தானியங்கி தொகுதி அளவு தேர்வை வெளிப்படையாக மீறுகிறது.

பஃபர்கவுண்ட் = { இடையக எண்ணிக்கை | @ இடையக எண்ணிக்கை_மாறி } - காப்புப் பிரதி செயல்பாட்டிற்குப் பயன்படுத்தப்படும் I/O இடையகங்களின் மொத்த எண்ணிக்கையை வரையறுக்கிறது. நீங்கள் எந்த நேர்மறை முழு எண் மதிப்பையும் குறிப்பிடலாம், ஆனால் Sqlservr.exe செயல்பாட்டில் அதிகப்படியான மெய்நிகர் முகவரி இடம் இருப்பதால் அதிக எண்ணிக்கையிலான இடையகங்கள் நினைவகத்தில் இல்லாத பிழையை ஏற்படுத்தலாம்.

இடையகங்கள் பயன்படுத்தும் இடத்தின் மொத்த அளவு பின்வரும் சூத்திரத்தால் தீர்மானிக்கப்படுகிறது: BUFFERCOUNT * MAXTRANSFERSIZE.

மேக்ஸ்ட்ரான்ஸ்ஃபர்சைஸ் = { அதிகபட்ச பரிமாற்றம் | @ maxtransfersize_variable } SQL சர்வர் மற்றும் பேக்கப் செட் மீடியா இடையே பரிமாற்றம் செய்ய, பைட்டுகளில் மிகப்பெரிய தரவு பாக்கெட் அளவைக் குறிப்பிடுகிறது. 65 பைட்டுகள் (536 KB) 64 பைட்டுகள் (4 MB) வரை பல மடங்குகள் ஆதரிக்கப்படுகின்றன.

நான் சத்தியம் செய்கிறேன் - நான் இதை முன்பே படித்திருக்கிறேன், ஆனால் அவை உற்பத்தித்திறனில் எவ்வளவு தாக்கத்தை ஏற்படுத்தும் என்று எனக்கு ஒருபோதும் தோன்றவில்லை. மேலும், வெளிப்படையாக, நான் ஒரு வகையான "வெளியே வருவதை" செய்ய வேண்டும், இப்போது கூட அவர்கள் என்ன செய்கிறார்கள் என்பது எனக்கு முழுமையாக புரியவில்லை என்பதை ஒப்புக்கொள்கிறேன். பஃபர் செய்யப்பட்ட I/O மற்றும் ஹார்ட் டிரைவில் வேலை செய்வது பற்றி நான் அதிகம் படிக்க வேண்டும். ஒரு நாள் நான் இதைச் செய்வேன், ஆனால் இப்போது நான் ஒரு ஸ்கிரிப்டை எழுத முடியும், இது காப்புப்பிரதி எடுக்கப்பட்ட வேகத்தை இந்த மதிப்புகள் எவ்வாறு பாதிக்கின்றன என்பதை சரிபார்க்கும்.

நான் ஒரு சிறிய தரவுத்தளத்தை உருவாக்கினேன், சுமார் 10 ஜிபி அளவு, அதை 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 இல் எழுதவும். தற்போதைக்கு, BACKUP DATABASE இல் நான் வைத்துள்ள அளவுருக்கள் பற்றி மட்டுமே கூறுகிறேன்.

BLOCKSIZE க்கு எங்களிடம் "மூடிய" மதிப்புகள் பட்டியல் உள்ளது, மேலும் BLOCKSIZE < 4KB உடன் நான் காப்புப் பிரதி எடுக்கவில்லை. 64KB இன் பெருக்கல் - 64KB இலிருந்து 4MB வரை உள்ள எந்த எண்ணையும் அதிகபட்சமாக மாற்றவும். எனது கணினியில் இயல்புநிலை 1024KB ஆகும், நான் 512 - 1024 - 2048 - 4096 எடுத்தேன்.

BUFFERCOUNT இல் இது மிகவும் கடினமாக இருந்தது - இது எந்த நேர்மறை எண்ணாகவும் இருக்கலாம், ஆனால் இணைப்பு கூறுகிறது பேக்கப் டேட்டாபேஸில் இது எவ்வாறு கணக்கிடப்படுகிறது மற்றும் பெரிய மதிப்புகள் ஏன் ஆபத்தானவை?. உண்மையில் எந்த BUFFERCOUNTஐக் கொண்டு காப்புப் பிரதி எடுக்கப்பட்டது என்பது பற்றிய தகவலைப் பெறுவது எப்படி என்றும் கூறுகிறது - என்னைப் பொறுத்தவரை இது 7. அதைக் குறைப்பதில் எந்தப் பயனும் இல்லை, மேலும் மேல் வரம்பு சோதனை முறையில் கண்டுபிடிக்கப்பட்டது - BUFFERCOUNT = 896 மற்றும் MAXTRANSFERSIZE = 4194304 உடன் காப்புப் பிரதி விழுந்தது. ஒரு பிழை (மேலே உள்ள இணைப்பில் எழுதப்பட்டுள்ளது):

செய்தி 3013, நிலை 16, நிலை 1, வரி 7 காப்புப் பிரதி தரவுத்தளம் அசாதாரணமாக முடிவடைகிறது.

செய்தி 701, நிலை 17, நிலை 123, வரி 7 இந்த வினவலை இயக்க, ரிசோர்ஸ் பூல் 'இயல்புநிலை'யில் போதுமான கணினி நினைவகம் இல்லை.

ஒப்பிடுகையில், எந்த அளவுருக்களையும் குறிப்பிடாமல் காப்புப்பிரதியை இயக்குவதன் முடிவுகளை முதலில் காண்பிப்பேன்:

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

சரி, காப்பு மற்றும் காப்புப்பிரதி:

'bt' தரவுத்தளத்திற்காக 1070072 பக்கங்கள் செயலாக்கப்பட்டது, கோப்பு 1 இல் 'bt' கோப்பு.

'bt' தரவுத்தளத்திற்காக 2 பக்கங்கள் செயலாக்கப்பட்டது, கோப்பு 1 இல் 'bt_log' கோப்பு.

BACKUP DATABASE ஆனது 1070074 பக்கங்களை 53.171 வினாடிகளில் (157.227 MB/sec) வெற்றிகரமாக செயலாக்கியது.

ஸ்கிரிப்ட், அளவுருக்களை சோதித்து, இரண்டு மணி நேரத்தில் வேலை செய்தது, அனைத்து அளவீடுகளும் இருந்தன கூகுள் விரிதாள். மூன்று சிறந்த செயலாக்க நேரங்களைக் கொண்ட முடிவுகளின் தேர்வு இங்கே உள்ளது (நான் ஒரு நல்ல வரைபடத்தை உருவாக்க முயற்சித்தேன், ஆனால் இடுகையில் நான் ஒரு அட்டவணை மற்றும் கருத்துகளில் செய்ய வேண்டும் @கலவை அவர் மேலும் மிகவும் அருமையான கிராபிக்ஸ்).

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;

கவனம், ஒரு மிக முக்கியமான குறிப்பு @கலவை из கருத்துகள்:

இந்த மதிப்புகளின் வரம்புகளுக்குள் அளவுருக்கள் மற்றும் காப்பு வேகம் ஆகியவற்றுக்கு இடையேயான உறவு சீரற்றது, எந்த முறையும் இல்லை என்று நாம் நம்பிக்கையுடன் கூறலாம். ஆனால் உள்ளமைக்கப்பட்ட அளவுருக்களிலிருந்து விலகிச் செல்வது, முடிவில் நல்ல விளைவை ஏற்படுத்தியது

அந்த. நிலையான BACKUP அளவுருக்களை நிர்வகிப்பதன் மூலம் மட்டுமே காப்புப் பிரதி அகற்றும் நேரத்தில் 2 மடங்கு லாபம் கிடைத்தது: 26 வினாடிகள், தொடக்கத்தில் 53. அது மோசமானதல்ல, இல்லையா? ஆனால் மறுசீரமைப்பு என்ன நடக்கிறது என்பதை நாம் பார்க்க வேண்டும். இப்போது மீட்க 4 மடங்கு அதிக நேரம் எடுத்தால் என்ன செய்வது?

முதலில், இயல்புநிலை அமைப்புகளுடன் காப்புப்பிரதியை மீட்டமைக்க எவ்வளவு நேரம் ஆகும் என்பதை அளவிடுவோம்:

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

சரி, உங்களுக்குத் தெரியும், வழிகள் உள்ளன, மாற்றுவது பதிலாக இல்லை, மீட்பு என்பது மீட்பு அல்ல. நான் இதை இப்படி செய்கிறேன்:

'bt' தரவுத்தளத்திற்காக 1070072 பக்கங்கள் செயலாக்கப்பட்டது, கோப்பு 1 இல் 'bt' கோப்பு.

'bt' தரவுத்தளத்திற்காக 2 பக்கங்கள் செயலாக்கப்பட்டது, கோப்பு 1 இல் 'bt_log' கோப்பு.

மீட்டமை தரவுத்தளமானது 1070074 பக்கங்களை 40.752 வினாடிகளில் (205.141 MB/sec) வெற்றிகரமாகச் செயலாக்கியது.

இப்போது மாற்றப்பட்ட BLOCKSZE, BUFFERCOUNT மற்றும் MAXTRANSFERSIZE மூலம் எடுக்கப்பட்ட காப்புப்பிரதிகளை மீட்டெடுக்க முயற்சிக்கிறேன்.

BLOCKSIZE = 16384, BUFFERCOUNT = 224, MAXTRANSFERSIZE = 4194304

மீட்டமை தரவுத்தளமானது 1070074 பக்கங்களை 32.283 வினாடிகளில் (258.958 MB/sec) வெற்றிகரமாகச் செயலாக்கியது.

BLOCKSIZE = 4096, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 4194304

மீட்டமை தரவுத்தளமானது 1070074 பக்கங்களை 32.682 வினாடிகளில் (255.796 MB/sec) வெற்றிகரமாகச் செயலாக்கியது.

BLOCKSIZE = 16384, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 2097152

மீட்டமை தரவுத்தளமானது 1070074 பக்கங்களை 32.091 வினாடிகளில் (260.507 MB/sec) வெற்றிகரமாகச் செயலாக்கியது.

BLOCKSIZE = 4096, BUFFERCOUNT = 56, MAXTRANSFERSIZE = 4194304

மீட்டமை தரவுத்தளமானது 1070074 பக்கங்களை 32.401 வினாடிகளில் (258.015 MB/sec) வெற்றிகரமாகச் செயலாக்கியது.

மீட்டெடுப்பின் போது தரவுத்தளத்தை மீட்டமைத்தல் அறிக்கை மாறாது; இந்த அளவுருக்கள் அதில் குறிப்பிடப்படவில்லை; SQL சேவையகம் அவற்றை காப்புப்பிரதியிலிருந்து தீர்மானிக்கிறது. மீட்புடன் கூட ஒரு ஆதாயம் இருக்க முடியும் என்பது தெளிவாகிறது - கிட்டத்தட்ட 20% வேகமாக (உண்மையைச் சொல்வதென்றால், நான் மீட்புக்கு அதிக நேரம் செலவிடவில்லை, நான் பல "வேகமான" காப்புப்பிரதிகளை இயக்கி, எந்த சரிவுகளும் இல்லை என்பதை உறுதிசெய்தேன்.).

ஒரு வேளை, இவை அனைவருக்கும் உகந்த சில அளவுருக்கள் அல்ல என்பதை தெளிவுபடுத்துகிறேன். சோதனை மூலம் மட்டுமே உங்களுக்கான உகந்த அளவுருக்களை நீங்கள் பெற முடியும். நான் இந்த முடிவுகளைப் பெற்றேன், நீங்கள் வெவ்வேறு முடிவுகளைப் பெறுவீர்கள். ஆனால் உங்கள் காப்புப்பிரதிகளை "டியூன்" செய்ய முடியும் என்பதை நீங்கள் காண்கிறீர்கள், மேலும் அவை உண்மையில் உருவாக்கி வேகமாக வரிசைப்படுத்தலாம்.

உங்கள் கணினியில் குறிப்பிட்ட நுணுக்கங்கள் இருக்கலாம் என்பதால், ஆவணங்களை முழுமையாகப் படிக்குமாறு நான் கடுமையாக பரிந்துரைக்கிறேன்.

நான் காப்புப்பிரதிகளைப் பற்றி எழுதத் தொடங்கியதிலிருந்து, "டியூனிங்" அளவுருக்களை விட மிகவும் பொதுவான ஒரு "உகப்பாக்கம்" பற்றி உடனடியாக எழுத விரும்புகிறேன் (நான் புரிந்து கொண்டவரை, இது குறைந்தபட்சம் சில காப்புப் பயன்பாடுகளால் பயன்படுத்தப்படுகிறது, ஒருவேளை அளவுருக்களுடன் சேர்ந்து இருக்கலாம். முன்பு விவரிக்கப்பட்டது), ஆனால் அது ஹப்ரேயிலும் இன்னும் விவரிக்கப்படவில்லை.

ஆவணத்தில் இரண்டாவது வரியைப் பார்த்தால், BACKUP DATABASE இன் கீழ், நாம் பார்க்கிறோம்:

TO <backup_device> [ ,...n ]

நீங்கள் பல காப்பு_சாதனங்களைக் குறிப்பிட்டால் என்ன நடக்கும் என்று நினைக்கிறீர்கள்? தொடரியல் அதை அனுமதிக்கிறது. மிகவும் சுவாரஸ்யமான விஷயம் நடக்கும் - காப்புப்பிரதி பல சாதனங்களில் "பரவப்படும்". அந்த. ஒவ்வொரு "சாதனமும்" தனித்தனியாக பயனற்றதாக இருக்கும், ஒன்றை இழக்கும், முழு காப்புப்பிரதியையும் இழக்கும். ஆனால் அத்தகைய ஸ்மியர் காப்பு வேகத்தை எவ்வாறு பாதிக்கும்?

ஒரே கோப்புறையில் அருகருகே அமைந்துள்ள இரண்டு “சாதனங்களில்” காப்புப் பிரதி எடுக்க முயற்சிப்போம்:

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

உலக பிதாக்களே, இது ஏன் செய்யப்படுகிறது?

'bt' தரவுத்தளத்திற்காக 1070072 பக்கங்கள் செயலாக்கப்பட்டது, கோப்பு 1 இல் 'bt' கோப்பு.

தரவுத்தளமான 'bt', கோப்பு 'bt' க்கான 2 பக்கங்கள் செயலாக்கப்பட்டனகோப்பு 1 இல் உள்நுழைக.

BACKUP DATABASE ஆனது 1070074 பக்கங்களை 40.092 வினாடிகளில் (208.519 MB/sec) வெற்றிகரமாக செயலாக்கியது.

காப்புப் பிரதி 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/sec) வெற்றிகரமாக செயலாக்கியது.

மொத்தத்தில், ஒரு வட்டில் 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/sec) வெற்றிகரமாகச் செயலாக்கியது.

கொஞ்சம் வேகமாக, ஆனால் எங்காவது நெருக்கமாக, குறிப்பிடத்தக்கதாக இல்லை. பொதுவாக, காப்புப்பிரதி வேகமாக அகற்றப்பட்டு அதே வழியில் மீட்டமைக்கப்படுகிறது - வெற்றியா? என்னைப் பொறுத்தவரை, இது ஒரு வெற்றி. இது முக்கியமானது, அதனால் நான் மீண்டும் சொல்கிறேன் - நீங்கள் என்றால் இந்த கோப்புகளில் ஏதேனும் ஒன்றை நீங்கள் இழந்தால், முழு காப்புப்பிரதியையும் இழக்கிறீர்கள்.

ட்ரேஸ் ஃபிளாக்ஸ் 3213 மற்றும் 3605ஐப் பயன்படுத்திக் காட்டப்படும் காப்புப் பிரதித் தகவலைப் பதிவில் பார்த்தால், பல சாதனங்களுக்கு காப்புப் பிரதி எடுக்கும்போது, குறைந்தபட்சம் BUFFERCOUNT எண்ணிக்கை அதிகரிப்பதை நீங்கள் கவனிப்பீர்கள். ஒருவேளை, நீங்கள் BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE ஆகியவற்றிற்கான மிகவும் உகந்த அளவுருக்களைத் தேர்ந்தெடுக்க முயற்சி செய்யலாம், ஆனால் நான் இப்போதே வெற்றிபெறவில்லை, மேலும் இதுபோன்ற சோதனைகளை மீண்டும் செய்ய நான் மிகவும் சோம்பேறியாக இருந்தேன், ஆனால் வேறு எண்ணிக்கையிலான கோப்புகளுக்கு. அது சக்கரங்களைப் பற்றி ஒரு அவமானம். நீங்கள் வீட்டிலேயே அத்தகைய சோதனையை ஒழுங்கமைக்க விரும்பினால், ஸ்கிரிப்டை ரீமேக் செய்வது கடினம் அல்ல.

இறுதியாக, விலை பற்றி பேசலாம். பயனர்களின் பணிக்கு இணையாக காப்புப்பிரதி அகற்றப்பட்டால், நீங்கள் சோதனைக்கு மிகவும் பொறுப்பான அணுகுமுறையை எடுக்க வேண்டும், ஏனெனில் காப்புப்பிரதி வேகமாக அகற்றப்பட்டால், வட்டுகள் மேலும் சிரமப்படுகின்றன, செயலியின் சுமை அதிகரிக்கிறது (நீங்கள் இன்னும் சுருக்க வேண்டும். அது பறக்கும் போது), மற்றும் அதன்படி, அமைப்பின் ஒட்டுமொத்த வினைத்திறன் குறைகிறது.

வேடிக்கையாக உள்ளது, ஆனால் நான் எந்த வெளிப்பாடும் செய்யவில்லை என்பதை நான் நன்றாக புரிந்துகொள்கிறேன். மேலே எழுதப்பட்டவை காப்புப்பிரதிகளை எடுப்பதற்கான உகந்த அளவுருக்களை எவ்வாறு தேர்ந்தெடுக்கலாம் என்பதற்கான ஒரு விளக்கமாகும்.

நீங்கள் செய்யும் அனைத்தும் உங்கள் சொந்த ஆபத்து மற்றும் ஆபத்தில் செய்யப்படுகின்றன என்பதை நினைவில் கொள்ளுங்கள். உங்கள் காப்புப்பிரதிகளைச் சரிபார்த்து, DBCC CHECKDB பற்றி மறந்துவிடாதீர்கள்.

ஆதாரம்: www.habr.com

MS SQL சர்வர்: ஸ்டெராய்டுகளில் காப்புப்பிரதி

கருத்தைச் சேர் Отменить ответ