MS SQL સર્વર: સ્ટેરોઇડ્સ પર બેકઅપ

રાહ જુઓ! રાહ જુઓ! સાચું, આ SQL સર્વર બેકઅપના પ્રકારો વિશેનો બીજો લેખ નથી. હું પુનઃપ્રાપ્તિ મોડલ વચ્ચેના તફાવતો અને વધુ પડતા લૉગ સાથે કેવી રીતે વ્યવહાર કરવો તે વિશે પણ વાત કરીશ નહીં.

કદાચ (ફક્ત કદાચ), આ પોસ્ટ વાંચ્યા પછી, તમે ખાતરી કરી શકશો કે પ્રમાણભૂત માધ્યમોનો ઉપયોગ કરીને તમારી પાસેથી જે બેકઅપ દૂર કરવામાં આવે છે તે આવતીકાલે રાત્રે, સારું, 1.5 ગણી ઝડપી દૂર કરવામાં આવશે. અને માત્ર એ હકીકતને કારણે કે તમે થોડા વધુ બેકઅપ ડેટાબેઝ પરિમાણોનો ઉપયોગ કરો છો.

જો પોસ્ટની સામગ્રી તમારા માટે સ્પષ્ટ હતી, તો મને માફ કરશો. "habr sql સર્વર બેકઅપ" વાક્ય માટે Google ને જે મળ્યું તે બધું મેં વાંચ્યું, અને એક પણ લેખમાં મને એ હકીકતનો કોઈ ઉલ્લેખ મળ્યો નથી કે બેકઅપ સમયને પરિમાણોનો ઉપયોગ કરીને કોઈક રીતે પ્રભાવિત કરી શકાય છે.

હું તરત જ તમારું ધ્યાન એલેક્ઝાંડર ગ્લેડચેન્કોની ટિપ્પણી તરફ દોરીશ (@mssqlhelp):

ઉત્પાદનમાં BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE પરિમાણોને ક્યારેય બદલશો નહીં. તેઓ આવા લેખો લખવા માટે જ બનાવવામાં આવ્યા છે. વ્યવહારમાં, તમે થોડા જ સમયમાં મેમરી સમસ્યાઓથી છુટકારો મેળવશો.

તે, અલબત્ત, સૌથી સ્માર્ટ અને પોસ્ટ વિશિષ્ટ સામગ્રી બનવું સરસ રહેશે, પરંતુ, કમનસીબે, આ કેસ નથી. આ વિષયને સમર્પિત અંગ્રેજી-ભાષા અને રશિયન-ભાષાના લેખો/પોસ્ટ બંને છે (તેને યોગ્ય રીતે શું કહેવું તે અંગે હું હંમેશા મૂંઝવણમાં છું). અહીં મારી પાસેના કેટલાક છે: વખત, два, ત્રણ (sql.ru પર).

તેથી, શરુઆત કરવા માટે, હું માંથી થોડો સ્ટ્રિપ-ડાઉન બેકઅપ સિન્ટેક્સ જોડીશ એમએસડીએન (માર્ગ દ્વારા, મેં ઉપર બેકઅપ ડેટાબેઝ વિશે લખ્યું છે, પરંતુ આ બધું ટ્રાન્ઝેક્શન લોગ બેકઅપ અને વિભેદક બેકઅપ બંનેને લાગુ પડે છે, પરંતુ કદાચ ઓછી સ્પષ્ટ અસર સાથે):

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 = { બ્લોકસાઇઝ | @ બ્લોકસાઇઝ_ચલ } - બાઇટ્સમાં ભૌતિક બ્લોકનું કદ સ્પષ્ટ કરે છે. સમર્થિત કદ 512, 1024, 2048, 4096, 8192, 16, 384 અને 32 બાઇટ્સ (768 KB) છે. ટેપ ઉપકરણો માટે ડિફોલ્ટ મૂલ્ય 65 અને અન્ય ઉપકરણો માટે 536 છે. સામાન્ય રીતે આ પરિમાણ જરૂરી નથી કારણ કે બેકઅપ સ્ટેટમેન્ટ આપમેળે ઉપકરણ માટે યોગ્ય બ્લોક માપ પસંદ કરે છે. બ્લોકનું કદ સુયોજિત કરવું સ્પષ્ટપણે સ્વયંસંચાલિત બ્લોક કદની પસંદગીને ઓવરરાઇડ કરે છે.

બફરકાઉન્ટ = { બફર ગણતરી | @ buffercount_variable } - I/O બફરની કુલ સંખ્યા વ્યાખ્યાયિત કરે છે જેનો ઉપયોગ બેકઅપ ઓપરેશન માટે કરવામાં આવશે. તમે કોઈપણ સકારાત્મક પૂર્ણાંક મૂલ્યનો ઉલ્લેખ કરી શકો છો, પરંતુ Sqlservr.exe પ્રક્રિયામાં વધુ પડતી વર્ચ્યુઅલ એડ્રેસ સ્પેસને કારણે મોટી સંખ્યામાં બફર્સ આઉટ-ઓફ-મેમરી ભૂલનું કારણ બની શકે છે.

બફર્સ દ્વારા ઉપયોગમાં લેવાતી જગ્યાની કુલ રકમ નીચેના સૂત્ર દ્વારા નક્કી કરવામાં આવે છે: BUFFERCOUNT * MAXTRANSFERSIZE.

મહત્તમ ટ્રાન્સફરસાઇઝ = { maxtransfersize | @ maxtransfersize_variable } એસક્યુએલ સર્વર અને બેકઅપ સેટ મીડિયા વચ્ચે વિનિમય કરવા માટે બાઇટ્સમાં સૌથી મોટા ડેટા પેકેટ કદનો ઉલ્લેખ કરે છે. 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
);

સ્ક્રિપ્ટનો સિદ્ધાંત સરળ છે - નેસ્ટેડ લૂપ્સ, જેમાંથી દરેક એક પરિમાણની કિંમતમાં ફેરફાર કરે છે, આ પરિમાણોને 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 સાથે બેકઅપ કર્યું નથી. 64KB થી 64MB સુધી - 4KB નો ગુણાંક ધરાવતી કોઈપણ સંખ્યાને મહત્તમ ટ્રાન્સફર કરો. મારી સિસ્ટમ પર ડિફોલ્ટ 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' ફાઇલ.

બેકઅપ ડેટાબેસે 1070074 સેકન્ડ (53.171 MB/sec) માં 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 એમબી/સેકંડ) માં 205.141 પૃષ્ઠોની સફળતાપૂર્વક પ્રક્રિયા કરી.

હવે હું બદલાયેલ BLOCKSIZE, BUFFERCOUNT અને MAXTRANSFERSIZE સાથે લીધેલા બેકઅપને પુનઃસ્થાપિત કરવાનો પ્રયાસ કરીશ.

BLOCKSIZE = 16384, BUFFERCOUNT = 224, MAXTRANSFERSIZE = 4194304

રીસ્ટોર ડેટાબેઝ એ 1070074 સેકન્ડ (32.283 એમબી/સેકંડ) માં 258.958 પૃષ્ઠોની સફળતાપૂર્વક પ્રક્રિયા કરી.

BLOCKSIZE = 4096, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 4194304

રીસ્ટોર ડેટાબેઝ એ 1070074 સેકન્ડ (32.682 એમબી/સેકંડ) માં 255.796 પૃષ્ઠોની સફળતાપૂર્વક પ્રક્રિયા કરી.

BLOCKSIZE = 16384, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 2097152

રીસ્ટોર ડેટાબેઝ એ 1070074 સેકન્ડ (32.091 એમબી/સેકંડ) માં 260.507 પૃષ્ઠોની સફળતાપૂર્વક પ્રક્રિયા કરી.

BLOCKSIZE = 4096, BUFFERCOUNT = 56, MAXTRANSFERSIZE = 4194304

રીસ્ટોર ડેટાબેઝ એ 1070074 સેકન્ડ (32.401 એમબી/સેકંડ) માં 258.015 પૃષ્ઠોની સફળતાપૂર્વક પ્રક્રિયા કરી.

રીસ્ટોર ડેટાબેઝ સ્ટેટમેન્ટ પુનઃપ્રાપ્તિ દરમિયાન બદલાતું નથી; આ પરિમાણો તેમાં ઉલ્લેખિત નથી; SQL સર્વર પોતે જ બેકઅપમાંથી તેમને નિર્ધારિત કરે છે. અને તે સ્પષ્ટ છે કે પુનઃપ્રાપ્તિ સાથે પણ ફાયદો થઈ શકે છે - લગભગ 20% ઝડપી (પ્રામાણિકપણે, મેં પુનઃપ્રાપ્તિ માટે વધુ સમય વિતાવ્યો નથી, મેં ઘણા બધા "ઝડપી" બેકઅપ્સમાંથી ભાગ લીધો અને ખાતરી કરી કે ત્યાં કોઈ બગાડ નથી.).

ફક્ત કિસ્સામાં, મને સ્પષ્ટ કરવા દો કે આ કેટલાક પરિમાણો નથી જે દરેક માટે શ્રેષ્ઠ છે. તમે ફક્ત પરીક્ષણ દ્વારા તમારા માટે શ્રેષ્ઠ પરિમાણો મેળવી શકો છો. મને આ પરિણામો મળ્યા છે, તમને અલગ અલગ મળશે. પરંતુ તમે જુઓ છો કે તમે તમારા બેકઅપને "ટ્યુન" કરી શકો છો અને તે ખરેખર ઝડપથી રચના અને જમાવટ કરી શકે છે.

હું ભારપૂર્વક ભલામણ કરું છું કે તમે દસ્તાવેજીકરણને સંપૂર્ણ રીતે વાંચો, કારણ કે તમારી સિસ્ટમ માટે વિશિષ્ટ ઘોંઘાટ હોઈ શકે છે.

મેં બેકઅપ વિશે લખવાનું શરૂ કર્યું ત્યારથી, હું તરત જ વધુ એક "ઓપ્ટિમાઇઝેશન" વિશે લખવા માંગુ છું, જે "ટ્યુનિંગ" પરિમાણો કરતાં વધુ સામાન્ય છે (જ્યાં સુધી હું સમજું છું, તે ઓછામાં ઓછી કેટલીક બેકઅપ ઉપયોગિતાઓ દ્વારા ઉપયોગમાં લેવાય છે, કદાચ પરિમાણો સાથે. અગાઉ વર્ણવેલ), પરંતુ તે હજી સુધી હેબ્રે પર વર્ણવવામાં આવ્યું નથી.

જો આપણે બેકઅપ ડેટાબેઝ હેઠળ, દસ્તાવેજીકરણમાં બીજી લાઇન જોઈએ, તો ત્યાં આપણે જોશું:

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 પર લોગ કરો.

બેકઅપ ડેટાબેસે 1070074 સેકન્ડ (40.092 MB/sec) માં 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/sec) માં 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 એમબી/સેકંડ) માં 219.842 પૃષ્ઠોની સફળતાપૂર્વક પ્રક્રિયા કરી.

થોડી ઝડપી, પરંતુ ક્યાંક નજીક, નોંધપાત્ર નથી. સામાન્ય રીતે, બેકઅપ ઝડપથી દૂર કરવામાં આવે છે અને તે જ રીતે પુનઃસ્થાપિત થાય છે - સફળતા? મારા માટે, તે એકદમ સફળ છે. આ મહત્વપૂર્ણ છે, તેથી હું પુનરાવર્તન કરું છું - જો તમે જો તમે આમાંથી ઓછામાં ઓછી એક ફાઇલ ગુમાવો છો, તો તમે સંપૂર્ણ બેકઅપ ગુમાવશો.

જો તમે ટ્રેસ ફ્લેગ્સ 3213 અને 3605 નો ઉપયોગ કરીને પ્રદર્શિત બેકઅપ માહિતીના લોગમાં જોશો, તો તમે જોશો કે જ્યારે કેટલાક ઉપકરણો પર બેકઅપ લેવામાં આવે છે, ત્યારે ઓછામાં ઓછા બફરકાઉન્ટની સંખ્યા વધે છે. સંભવતઃ, તમે BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE માટે વધુ શ્રેષ્ઠ પરિમાણો પસંદ કરવાનો પ્રયાસ કરી શકો છો, પરંતુ હું તરત જ સફળ થયો નથી, અને હું ફરીથી આવા પરીક્ષણ હાથ ધરવા માટે ખૂબ આળસુ હતો, પરંતુ ફાઇલોની અલગ સંખ્યા માટે. અને તે વ્હીલ્સ વિશે શરમજનક છે. જો તમે ઘરે આવા પરીક્ષણનું આયોજન કરવા માંગતા હો, તો સ્ક્રિપ્ટને રીમેક કરવી મુશ્કેલ નથી.

છેલ્લે, ચાલો કિંમત વિશે વાત કરીએ. જો બેકઅપ વપરાશકર્તાઓના કાર્ય સાથે સમાંતર રીતે દૂર કરવામાં આવે છે, તો તમારે પરીક્ષણ માટે ખૂબ જ જવાબદાર અભિગમ અપનાવવાની જરૂર છે, કારણ કે જો બેકઅપ ઝડપથી દૂર કરવામાં આવે છે, તો ડિસ્ક વધુ તાણમાં આવે છે, પ્રોસેસર પરનો ભાર વધે છે (તમારે હજી પણ સંકુચિત કરવું પડશે. તે ફ્લાય પર), અને તે મુજબ, સિસ્ટમની એકંદર પ્રતિભાવ ઘટે છે.

માત્ર મજાક કરું છું, પણ હું સારી રીતે સમજું છું કે મેં કોઈ ખુલાસો કર્યો નથી. ઉપર જે લખ્યું છે તે ફક્ત એક નિદર્શન છે કે તમે બેકઅપ લેવા માટે શ્રેષ્ઠ પરિમાણો કેવી રીતે પસંદ કરી શકો છો.

યાદ રાખો કે તમે જે કરો છો તે તમારા પોતાના જોખમે અને જોખમે કરો છો. તમારા બેકઅપ્સ તપાસો અને DBCC CHECKDB વિશે ભૂલશો નહીં.

સોર્સ: www.habr.com