MS SQL സെർവർ: സ്റ്റിറോയിഡുകളിൽ ബാക്കപ്പ്

കാത്തിരിക്കൂ! കാത്തിരിക്കൂ! ശരിയാണ്, ഇത് SQL സെർവർ ബാക്കപ്പുകളുടെ തരങ്ങളെക്കുറിച്ചുള്ള മറ്റൊരു ലേഖനമല്ല. വീണ്ടെടുക്കൽ മോഡലുകൾ തമ്മിലുള്ള വ്യത്യാസങ്ങളെക്കുറിച്ചും പടർന്ന് പിടിച്ച ലോഗ് എങ്ങനെ കൈകാര്യം ചെയ്യാമെന്നതിനെക്കുറിച്ചും ഞാൻ സംസാരിക്കില്ല.

ഒരുപക്ഷേ (ഒരുപക്ഷേ), ഈ പോസ്റ്റ് വായിച്ചതിനുശേഷം, സ്റ്റാൻഡേർഡ് മാർഗങ്ങൾ ഉപയോഗിച്ച് നിങ്ങളിൽ നിന്ന് നീക്കം ചെയ്ത ബാക്കപ്പ് നാളെ രാത്രി 1.5 മടങ്ങ് വേഗത്തിൽ നീക്കംചെയ്യുമെന്ന് നിങ്ങൾക്ക് ഉറപ്പാക്കാൻ കഴിയും. നിങ്ങൾ കുറച്ചുകൂടി ബാക്കപ്പ് ഡാറ്റാബേസ് പാരാമീറ്ററുകൾ ഉപയോഗിക്കുന്നതിനാൽ മാത്രം.

പോസ്റ്റിന്റെ ഉള്ളടക്കം നിങ്ങൾക്ക് വ്യക്തമാണെങ്കിൽ, ക്ഷമിക്കണം. "habr sql സെർവർ ബാക്കപ്പ്" എന്ന വാക്യത്തിനായി Google-ന് ലഭിച്ചതെല്ലാം ഞാൻ വായിച്ചു, കൂടാതെ ഒരു ലേഖനത്തിൽ പോലും പാരാമീറ്ററുകൾ ഉപയോഗിച്ച് ബാക്കപ്പ് സമയം എങ്ങനെയെങ്കിലും സ്വാധീനിക്കാമെന്ന വസ്തുതയെക്കുറിച്ച് ഞാൻ പരാമർശിച്ചിട്ടില്ല.

അലക്സാണ്ടർ ഗ്ലാഡ്ചെങ്കോയുടെ അഭിപ്രായത്തിലേക്ക് ഞാൻ ഉടൻ തന്നെ നിങ്ങളുടെ ശ്രദ്ധ ആകർഷിക്കും (@mssqlhelp):

പ്രൊഡക്‌ഷനിലെ ബഫർകൗണ്ട്, ബ്ലോക്ക്‌സൈസ്, മാക്‌സ്‌ട്രാൻസ്‌ഫർസൈസ് പാരാമീറ്ററുകൾ ഒരിക്കലും മാറ്റരുത്. അത്തരം ലേഖനങ്ങൾ എഴുതാൻ വേണ്ടി മാത്രമാണ് അവ നിർമ്മിച്ചിരിക്കുന്നത്. പ്രായോഗികമായി, ചുരുങ്ങിയ സമയത്തിനുള്ളിൽ നിങ്ങൾക്ക് മെമ്മറി പ്രശ്നങ്ങൾ ഒഴിവാക്കാനാകും.

തീർച്ചയായും, ഏറ്റവും മികച്ചതും എക്‌സ്‌ക്ലൂസീവ് ഉള്ളടക്കം പോസ്റ്റുചെയ്യുന്നതും രസകരമായിരിക്കും, പക്ഷേ, നിർഭാഗ്യവശാൽ, ഇത് അങ്ങനെയല്ല. ഇംഗ്ലീഷിലും റഷ്യൻ ഭാഷയിലും ഉള്ള ലേഖനങ്ങൾ/പോസ്‌റ്റുകൾ (അവയെ എങ്ങനെ ശരിയായി വിളിക്കണം എന്നറിയാതെ ഞാൻ എപ്പോഴും ആശയക്കുഴപ്പത്തിലാണ്) ഈ വിഷയത്തിനായി നീക്കിവച്ചിരിക്കുന്നു. ഞാൻ കണ്ടുമുട്ടിയ ചിലത് ഇതാ: തവണ, два, മൂന്ന് (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-ൽ നിന്നുള്ള അവരുടെ വിവരണങ്ങൾ ഇതാ:

ബ്ലോക്ക്‌സൈസ് = { ബ്ലോക്കുകളുടെ വലിപ്പം | @ blocksize_variable } - ബൈറ്റുകളിൽ ഫിസിക്കൽ ബ്ലോക്ക് സൈസ് സൂചിപ്പിക്കുന്നു. പിന്തുണയ്ക്കുന്ന വലുപ്പങ്ങൾ 512, 1024, 2048, 4096, 8192, 16, 384, 32 ബൈറ്റുകൾ (768 കെബി) എന്നിവയാണ്. ടേപ്പ് ഉപകരണങ്ങൾക്ക് 65 ഉം മറ്റ് ഉപകരണങ്ങൾക്ക് 536 ഉം ആണ് ഡിഫോൾട്ട് മൂല്യം. സാധാരണയായി ഈ പരാമീറ്റർ ആവശ്യമില്ല, കാരണം ബാക്കപ്പ് സ്റ്റേറ്റ്‌മെന്റ് ഉപകരണത്തിന് അനുയോജ്യമായ ബ്ലോക്ക് വലുപ്പം സ്വയമേവ തിരഞ്ഞെടുക്കുന്നു. ബ്ലോക്ക് വലുപ്പം ക്രമീകരിക്കുന്നത് ഓട്ടോമാറ്റിക് ബ്ലോക്ക് സൈസ് സെലക്ഷനെ വ്യക്തമായി അസാധുവാക്കുന്നു.

ബഫർകൌണ്ട് = { ബഫർ കൗണ്ട് | @ ബഫർ കൗണ്ട്_വേരിയബിൾ } - ബാക്കപ്പ് പ്രവർത്തനത്തിനായി ഉപയോഗിക്കുന്ന I/O ബഫറുകളുടെ ആകെ എണ്ണം നിർവചിക്കുന്നു. നിങ്ങൾക്ക് ഏതെങ്കിലും പോസിറ്റീവ് ഇന്റിജർ മൂല്യം വ്യക്തമാക്കാൻ കഴിയും, എന്നാൽ Sqlservr.exe പ്രോസസിലെ അമിതമായ വെർച്വൽ അഡ്രസ് സ്പേസ് കാരണം ധാരാളം ബഫറുകൾ മെമ്മറിക്ക് പുറത്തുള്ള പിശകിന് കാരണമായേക്കാം.

ബഫറുകൾ ഉപയോഗിക്കുന്ന മൊത്തം സ്ഥലത്തിന്റെ അളവ് ഇനിപ്പറയുന്ന ഫോർമുലയാൽ നിർണ്ണയിക്കപ്പെടുന്നു: BUFFERCOUNT * MAXTRANSFERSIZE.

പരമാവധി ട്രാൻസ്ഫർസൈസ് = { പരമാവധി കൈമാറ്റം ചെയ്യുക | @ maxtransfersize_variable } SQL സെർവറും ബാക്കപ്പ് സെറ്റ് മീഡിയയും തമ്മിൽ കൈമാറ്റം ചെയ്യുന്നതിനുള്ള ഏറ്റവും വലിയ ഡാറ്റ പാക്കറ്റ് വലുപ്പം, ബൈറ്റുകളിൽ വ്യക്തമാക്കുന്നു. 65 ബൈറ്റുകൾ (536 MB) വരെയുള്ള 64 ബൈറ്റുകളുടെ (4 KB) ഗുണിതങ്ങൾ പിന്തുണയ്ക്കുന്നു.

ഞാൻ സത്യം ചെയ്യുന്നു - ഞാൻ ഇത് മുമ്പ് വായിച്ചിട്ടുണ്ട്, പക്ഷേ അവ ഉൽപ്പാദനക്ഷമതയിൽ എത്രമാത്രം സ്വാധീനം ചെലുത്തുമെന്ന് എനിക്ക് ഒരിക്കലും തോന്നിയിട്ടില്ല. മാത്രമല്ല, പ്രത്യക്ഷത്തിൽ, എനിക്ക് ഒരുതരം "പുറത്തുവരുന്നത്" ചെയ്യേണ്ടതുണ്ട്, ഇപ്പോൾ പോലും അവർ കൃത്യമായി എന്താണ് ചെയ്യുന്നതെന്ന് എനിക്ക് പൂർണ്ണമായി മനസ്സിലാകുന്നില്ലെന്ന് സമ്മതിക്കുന്നു. ബഫർ ചെയ്ത 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
);

സ്ക്രിപ്റ്റിന്റെ തത്വം ലളിതമാണ് - നെസ്റ്റഡ് ലൂപ്പുകൾ, അവയിൽ ഓരോന്നും ഒരു പാരാമീറ്ററിന്റെ മൂല്യം മാറ്റുന്നു, ഈ പാരാമീറ്ററുകൾ ബാക്കപ്പ് കമാൻഡിലേക്ക് തിരുകുക, 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 ഉപയോഗിച്ച് ഞാൻ ഒരു ബാക്കപ്പ് നടത്തിയില്ല. 64KB-ൽ നിന്ന് 64MB വരെ - 4KB-യുടെ ഗുണിതമുള്ള ഏത് സംഖ്യയും പരമാവധി ട്രാൻസ്ഫർസൈസ് ചെയ്യുക. എന്റെ സിസ്റ്റത്തിലെ ഡിഫോൾട്ട് 1024KB ആണ്, ഞാൻ 512 - 1024 - 2048 - 4096 എടുത്തു.

BUFFERCOUNT-ൽ ഇത് കൂടുതൽ ബുദ്ധിമുട്ടായിരുന്നു - ഇത് ഏത് പോസിറ്റീവ് നമ്പറും ആകാം, എന്നാൽ ലിങ്ക് പറയുന്നു ബാക്കപ്പ് ഡാറ്റാബേസിൽ ഇത് എങ്ങനെയാണ് കണക്കാക്കുന്നത്, വലിയ മൂല്യങ്ങൾ അപകടകരമാകുന്നത് എന്തുകൊണ്ട്?. യഥാർത്ഥത്തിൽ ഏത് ബഫർകൗണ്ട് ഉപയോഗിച്ചാണ് ബാക്കപ്പ് നിർമ്മിച്ചിരിക്കുന്നത് എന്നതിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ എങ്ങനെ നേടാമെന്നും ഇത് പറയുന്നു - എനിക്ക് ഇത് 7 ആണ്. അത് കുറയ്ക്കുന്നതിൽ അർത്ഥമില്ല, കൂടാതെ ഉയർന്ന പരിധി പരീക്ഷണാടിസ്ഥാനത്തിൽ കണ്ടെത്തി - BUFFERCOUNT = 896, MAXTRANSFERSIZE = 4194304 എന്നിവ ഉപയോഗിച്ച് ബാക്കപ്പ് വീണു. ഒരു പിശക് (മുകളിലുള്ള ലിങ്കിൽ എഴുതിയിരിക്കുന്നതിനെക്കുറിച്ച്):

Msg 3013, ലെവൽ 16, സ്റ്റേറ്റ് 1, ലൈൻ 7 ബാക്കപ്പ് ഡാറ്റാബേസ് അസാധാരണമായി അവസാനിക്കുന്നു.

Msg 701, ലെവൽ 17, സ്‌റ്റേറ്റ് 123, ലൈൻ 7 ഈ ചോദ്യം പ്രവർത്തിപ്പിക്കുന്നതിന് റിസോഴ്‌സ് പൂളിൽ 'ഡിഫോൾട്ട്' മതിയായ സിസ്റ്റം മെമ്മറിയില്ല.

താരതമ്യത്തിനായി, പാരാമീറ്ററുകളൊന്നും വ്യക്തമാക്കാതെ ഒരു ബാക്കപ്പ് പ്രവർത്തിപ്പിക്കുന്നതിന്റെ ഫലങ്ങൾ ഞാൻ ആദ്യം കാണിക്കും:

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

ശരി, ബാക്കപ്പും ബാക്കപ്പും:

'bt' ഡാറ്റാബേസിനായി 1070072 പേജുകൾ പ്രോസസ്സ് ചെയ്തു, ഫയൽ 1-ൽ 'bt' ഫയൽ.

'bt' ഡാറ്റാബേസിനായി 2 പേജുകൾ പ്രോസസ്സ് ചെയ്തു, ഫയൽ 1-ൽ 'bt_log' ഫയൽ.

ബാക്കപ്പ് ഡാറ്റാബേസ് 1070074 സെക്കൻഡിൽ (53.171 MB/സെക്കൻഡ്) 157.227 പേജുകൾ വിജയകരമായി പ്രോസസ്സ് ചെയ്തു.

സ്ക്രിപ്റ്റ് തന്നെ, പാരാമീറ്ററുകൾ പരീക്ഷിച്ചു, രണ്ട് മണിക്കൂറിനുള്ളിൽ പ്രവർത്തിച്ചു, എല്ലാ അളവുകളും ഉണ്ടായിരുന്നു ഗൂഗിൾ സ്പ്രെഡ്ഷീറ്റ്. മൂന്ന് മികച്ച എക്‌സിക്യൂഷൻ സമയങ്ങളുള്ള ഫലങ്ങളുടെ ഒരു തിരഞ്ഞെടുപ്പ് ഇതാ (ഞാൻ ഒരു നല്ല ഗ്രാഫ് നിർമ്മിക്കാൻ ശ്രമിച്ചു, പക്ഷേ പോസ്റ്റിൽ എനിക്ക് ഒരു പട്ടികയും കമന്റുകളും ഉപയോഗിക്കേണ്ടി വരും. @മിശ്രണം ചേർത്തു വളരെ രസകരമായ ഗ്രാഫിക്സ്).

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;

ശ്രദ്ധിക്കുക, വളരെ പ്രധാനപ്പെട്ട ഒരു കുറിപ്പ് @മിശ്രണം നിന്ന് വ്യാഖ്യാനം:

ഈ മൂല്യങ്ങളുടെ പരിധിക്കുള്ളിലെ പാരാമീറ്ററുകളും ബാക്കപ്പ് വേഗതയും തമ്മിലുള്ള ബന്ധം ക്രമരഹിതമാണെന്ന് നമുക്ക് ആത്മവിശ്വാസത്തോടെ പറയാൻ കഴിയും, ഒരു പാറ്റേൺ ഇല്ല. എന്നാൽ അന്തർനിർമ്മിത പാരാമീറ്ററുകളിൽ നിന്ന് അകന്നുപോകുന്നത് ഫലത്തിൽ നല്ല സ്വാധീനം ചെലുത്തി

ആ. സ്റ്റാൻഡേർഡ് ബാക്കപ്പ് പാരാമീറ്ററുകൾ കൈകാര്യം ചെയ്യുന്നതിലൂടെ മാത്രമേ ബാക്കപ്പ് നീക്കംചെയ്യൽ സമയത്തിൽ 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 MB/sec) 205.141 പേജുകൾ വിജയകരമായി പ്രോസസ്സ് ചെയ്തു.

മാറ്റിയ BLOCKSIZE, BUFFERCOUNT, MAXTRANSFERSIZE എന്നിവ ഉപയോഗിച്ച് എടുത്ത ബാക്കപ്പുകൾ പുനഃസ്ഥാപിക്കാൻ ഞാൻ ഇപ്പോൾ ശ്രമിക്കും.

BLOCKSIZE = 16384, BUFFERCOUNT = 224, MAXTRANSFERSIZE = 4194304

ഡാറ്റാബേസ് പുനഃസ്ഥാപിക്കുക 1070074 സെക്കൻഡിൽ (32.283 MB/sec) 258.958 പേജുകൾ വിജയകരമായി പ്രോസസ്സ് ചെയ്തു.

BLOCKSIZE = 4096, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 4194304

ഡാറ്റാബേസ് പുനഃസ്ഥാപിക്കുക 1070074 സെക്കൻഡിൽ (32.682 MB/sec) 255.796 പേജുകൾ വിജയകരമായി പ്രോസസ്സ് ചെയ്തു.

BLOCKSIZE = 16384, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 2097152

ഡാറ്റാബേസ് പുനഃസ്ഥാപിക്കുക 1070074 സെക്കൻഡിൽ (32.091 MB/sec) 260.507 പേജുകൾ വിജയകരമായി പ്രോസസ്സ് ചെയ്തു.

BLOCKSIZE = 4096, BUFFERCOUNT = 56, MAXTRANSFERSIZE = 4194304

ഡാറ്റാബേസ് പുനഃസ്ഥാപിക്കുക 1070074 സെക്കൻഡിൽ (32.401 MB/sec) 258.015 പേജുകൾ വിജയകരമായി പ്രോസസ്സ് ചെയ്തു.

വീണ്ടെടുക്കൽ സമയത്ത് റിസ്റ്റോർ ഡാറ്റാബേസ് പ്രസ്താവന മാറില്ല; ഈ പാരാമീറ്ററുകൾ അതിൽ വ്യക്തമാക്കിയിട്ടില്ല; SQL സെർവർ തന്നെ ബാക്കപ്പിൽ നിന്ന് അവയെ നിർണ്ണയിക്കുന്നു. വീണ്ടെടുക്കലിനൊപ്പം പോലും ഒരു നേട്ടമുണ്ടാകുമെന്ന് വ്യക്തമാണ് - ഏകദേശം 20% വേഗത്തിൽ (സത്യം പറഞ്ഞാൽ, വീണ്ടെടുക്കലിനായി ഞാൻ കൂടുതൽ സമയം ചെലവഴിച്ചില്ല, "വേഗതയുള്ള" ബാക്കപ്പുകളിൽ പലതും ഞാൻ ഓടിച്ചു, ഒരു തകർച്ചയും ഇല്ലെന്ന് ഉറപ്പുവരുത്തി.).

അങ്ങനെയെങ്കിൽ, എല്ലാവർക്കും അനുയോജ്യമായ ചില പാരാമീറ്ററുകളല്ല ഇവയെന്ന് ഞാൻ വ്യക്തമാക്കട്ടെ. പരിശോധനയിലൂടെ മാത്രമേ നിങ്ങൾക്ക് ഒപ്റ്റിമൽ പാരാമീറ്ററുകൾ ലഭിക്കൂ. എനിക്ക് ഈ ഫലങ്ങൾ ലഭിച്ചു, നിങ്ങൾക്ക് വ്യത്യസ്തമായവ ലഭിക്കും. എന്നാൽ നിങ്ങളുടെ ബാക്കപ്പുകൾ "ട്യൂൺ" ചെയ്യാനും അവ യഥാർത്ഥത്തിൽ രൂപപ്പെടുത്താനും വേഗത്തിൽ വിന്യസിക്കാനും കഴിയുമെന്ന് നിങ്ങൾ കാണുന്നു.

ഡോക്യുമെന്റേഷൻ മുഴുവനായി വായിക്കാനും ഞാൻ ശക്തമായി ശുപാർശ ചെയ്യുന്നു, കാരണം നിങ്ങളുടെ സിസ്റ്റത്തിന് പ്രത്യേകമായ സൂക്ഷ്മതകൾ ഉണ്ടായിരിക്കാം.

ഞാൻ ബാക്കപ്പുകളെ കുറിച്ച് എഴുതാൻ തുടങ്ങിയത് മുതൽ, "ട്യൂണിംഗ്" പാരാമീറ്ററുകളേക്കാൾ സാധാരണമായ ഒരു "ഒപ്റ്റിമൈസേഷൻ" കൂടി എഴുതാൻ ഞാൻ ആഗ്രഹിക്കുന്നു (ഞാൻ മനസ്സിലാക്കിയിടത്തോളം, ഇത് കുറഞ്ഞത് ചില ബാക്കപ്പ് യൂട്ടിലിറ്റികളെങ്കിലും ഉപയോഗിക്കുന്നു, ഒരുപക്ഷേ പാരാമീറ്ററുകൾക്കൊപ്പം. നേരത്തെ വിവരിച്ചത്), പക്ഷേ അത് ഇതുവരെ ഹബ്രെയിലും വിവരിച്ചിട്ടില്ല.

ഡോക്യുമെന്റേഷനിലെ രണ്ടാമത്തെ വരി നോക്കുകയാണെങ്കിൽ, ബാക്കപ്പ് ഡാറ്റാബേസിന് താഴെ, അവിടെ നമ്മൾ കാണുന്നത്:

TO <backup_device> [ ,...n ]

നിങ്ങൾ നിരവധി backup_devices വ്യക്തമാക്കിയാൽ എന്ത് സംഭവിക്കുമെന്ന് നിങ്ങൾ കരുതുന്നു? വാക്യഘടന അത് അനുവദിക്കുന്നു. വളരെ രസകരമായ ഒരു കാര്യം സംഭവിക്കും - ബാക്കപ്പ് നിരവധി ഉപകരണങ്ങളിൽ "പ്രചരിക്കും". ആ. ഓരോ "ഉപകരണവും" വ്യക്തിഗതമായി ഉപയോഗശൂന്യമാകും, ഒന്ന് നഷ്‌ടപ്പെടും, മുഴുവൻ ബാക്കപ്പും നഷ്‌ടമാകും. എന്നാൽ അത്തരം സ്മിയറിങ് ബാക്കപ്പ് വേഗതയെ എങ്ങനെ ബാധിക്കും?

ഒരേ ഫോൾഡറിൽ വശങ്ങളിലായി സ്ഥിതി ചെയ്യുന്ന രണ്ട് "ഉപകരണങ്ങളിൽ" ഒരു ബാക്കപ്പ് ഉണ്ടാക്കാൻ ശ്രമിക്കാം:

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

ലോകപിതാക്കന്മാരേ, എന്തിനാണ് ഇങ്ങനെ ചെയ്യുന്നത്?

'bt' ഡാറ്റാബേസിനായി 1070072 പേജുകൾ പ്രോസസ്സ് ചെയ്തു, ഫയൽ 1-ൽ 'bt' ഫയൽ.

ഡാറ്റാബേസ് 'bt', ഫയൽ 'bt' എന്നിവയ്ക്കായി 2 പേജുകൾ പ്രോസസ്സ് ചെയ്തുഫയൽ 1-ൽ ലോഗിൻ ചെയ്യുക.

ബാക്കപ്പ് ഡാറ്റാബേസ് 1070074 സെക്കൻഡിൽ (40.092 MB/സെക്കൻഡ്) 208.519 പേജുകൾ വിജയകരമായി പ്രോസസ്സ് ചെയ്തു.

ബാക്കപ്പ് 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 MB/സെക്കൻഡ്) 244.200 പേജുകൾ വിജയകരമായി പ്രോസസ്സ് ചെയ്തു.

മൊത്തത്തിൽ, ഒരു ബാക്കപ്പ് എടുക്കുന്ന സമയത്തിന്റെ ഏകദേശം 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 MB/sec) 219.842 പേജുകൾ വിജയകരമായി പ്രോസസ്സ് ചെയ്തു.

കുറച്ച് വേഗത്തിൽ, പക്ഷേ എവിടെയോ അടുത്ത്, പ്രാധാന്യമില്ല. പൊതുവേ, ബാക്കപ്പ് വേഗത്തിൽ നീക്കംചെയ്യുകയും അതേ രീതിയിൽ പുനഃസ്ഥാപിക്കുകയും ചെയ്യുന്നു - വിജയം? എന്നെ സംബന്ധിച്ചിടത്തോളം ഇത് തികച്ചും വിജയമാണ്. ഈ പ്രധാനമാണ്, അതിനാൽ ഞാൻ ആവർത്തിക്കുന്നു - നിങ്ങളാണെങ്കിൽ ഈ ഫയലുകളിൽ ഒരെണ്ണമെങ്കിലും നഷ്‌ടപ്പെടുകയാണെങ്കിൽ, നിങ്ങൾക്ക് മുഴുവൻ ബാക്കപ്പും നഷ്‌ടപ്പെടും.

ട്രേസ് ഫ്ലാഗുകൾ 3213, 3605 എന്നിവ ഉപയോഗിച്ച് പ്രദർശിപ്പിച്ചിരിക്കുന്ന ബാക്കപ്പ് വിവരങ്ങളുടെ ലോഗിൽ നിങ്ങൾ നോക്കുകയാണെങ്കിൽ, നിരവധി ഉപകരണങ്ങളിലേക്ക് ബാക്കപ്പ് ചെയ്യുമ്പോൾ, കുറഞ്ഞത് BUFFERCOUNT എണ്ണം വർദ്ധിക്കുന്നത് നിങ്ങൾ ശ്രദ്ധിക്കും. ഒരുപക്ഷേ, BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE എന്നിവയ്‌ക്കായി നിങ്ങൾക്ക് കൂടുതൽ ഒപ്റ്റിമൽ പാരാമീറ്ററുകൾ തിരഞ്ഞെടുക്കാൻ ശ്രമിക്കാം, പക്ഷേ ഞാൻ ഉടൻ വിജയിച്ചില്ല, അത്തരം പരിശോധന വീണ്ടും നടത്താൻ എനിക്ക് മടിയനായിരുന്നു, പക്ഷേ വ്യത്യസ്ത എണ്ണം ഫയലുകൾക്കായി. ചക്രങ്ങളുടെ കാര്യത്തിലും ഇത് ലജ്ജാകരമാണ്. വീട്ടിൽ അത്തരം പരിശോധന സംഘടിപ്പിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, സ്ക്രിപ്റ്റ് റീമേക്ക് ചെയ്യുന്നത് ബുദ്ധിമുട്ടുള്ള കാര്യമല്ല.

അവസാനമായി, നമുക്ക് വിലയെക്കുറിച്ച് സംസാരിക്കാം. ഉപയോക്താക്കളുടെ പ്രവർത്തനത്തിന് സമാന്തരമായി ബാക്കപ്പ് നീക്കംചെയ്യുകയാണെങ്കിൽ, പരിശോധനയ്ക്ക് നിങ്ങൾ വളരെ ഉത്തരവാദിത്തമുള്ള സമീപനം സ്വീകരിക്കേണ്ടതുണ്ട്, കാരണം ബാക്കപ്പ് വേഗത്തിൽ നീക്കംചെയ്യുകയാണെങ്കിൽ, ഡിസ്കുകൾ കൂടുതൽ ബുദ്ധിമുട്ടുന്നു, പ്രോസസറിലെ ലോഡ് വർദ്ധിക്കുന്നു (നിങ്ങൾ ഇപ്പോഴും കംപ്രസ് ചെയ്യണം. അത് ഈച്ചയിൽ), അതനുസരിച്ച്, സിസ്റ്റത്തിന്റെ മൊത്തത്തിലുള്ള പ്രതികരണശേഷി കുറയുന്നു.

തമാശയാണ്, പക്ഷേ ഞാൻ വെളിപ്പെടുത്തലുകളൊന്നും നടത്തിയിട്ടില്ലെന്ന് ഞാൻ നന്നായി മനസ്സിലാക്കുന്നു. മുകളിൽ എഴുതിയത് ബാക്കപ്പുകൾ എടുക്കുന്നതിനുള്ള ഒപ്റ്റിമൽ പാരാമീറ്ററുകൾ എങ്ങനെ തിരഞ്ഞെടുക്കാം എന്നതിന്റെ ഒരു പ്രകടനമാണ്.

നിങ്ങൾ ചെയ്യുന്നതെല്ലാം നിങ്ങളുടെ സ്വന്തം അപകടത്തിലും അപകടസാധ്യതയിലും ചെയ്തതാണെന്ന് ഓർമ്മിക്കുക. നിങ്ങളുടെ ബാക്കപ്പുകൾ പരിശോധിക്കുക, DBCC CHECKDB-യെ കുറിച്ച് മറക്കരുത്.

അവലംബം: www.habr.com