ProHoster >> Blog >> Administrimi >> MS SQL Server: BACKUP në steroide

MS SQL Server: BACKUP në steroide

Prisni! Prisni! Në të vërtetë, kjo nuk është një tjetër artikull mbi llojet e rezervave të SQL Server. Nuk do të flas për dallimet në modelet e rikuperimit dhe si të përballoni me «logun» që është zgjeruar.

Ndoshta (vetëm ndoshta), pas leximit të këtij postimi, do të jeni në gjendje të bëni që rezervimi, që merret me mjetet standarde, nesër natën të bëhet rreth 1.5 herë më shpejt. Dhe vetëm për shkak se po përdorni pak më shumë parametra BACKUP DATABASE.

Nëse për ju përmbajtja e postimit ishte e qartë - më vjen keq. Kam lexuar gjithçka që kam gjetur në google me frazën «habr sql server backup», dhe në asnjë artikull nuk kam gjetur përmendje që ndonjëherë mund të ndikoni në kohën e rezervimit në njëfarë mënyre me parametrat.

Menjëherë do të tërheq vëmendjen tuaj për komentarin e Aleksandër Gladçenko (@mssqlhelp):

Mos ndryshoni kurrë parametrat BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE në prodhim. Ata janë bërë vetëm për të shkruar artikuj të tillë. Në praktikë do të përballeni me probleme me memorie në mënyrë të plotë.

Sigurisht, do të ishte e mrekullueshme të ishim më të zgjuar dhe të ndanim përmbajtje ekskluzive, por fatkeqësisht, nuk është kështu. Ka artikuj / postime në anglisht dhe rusisht (përherë konfuz me si t'i quaj ato) të dedikuara kësaj teme. Ja disa nga ato që kam gjetur: një herë, dy herë, tre (në sql.ru).

Pra, në fillim do të bashkëngjis një sintaksë të shkurtuar BACKUP nga MSDN (me rasht, përmenda më lart BACKUP DATABASE, por gjithçka kjo është e aplikueshme edhe për backup-in e regjistrit të transaksioneve dhe për backup-in diferencial, ndoshta me efekte më pak të dukshme):

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

 [ ,...n ]::=

--Mundësi të Setit të Medias
 
 | BLOCKSIZE = { blocksize | @blocksize_variable }

--Mundësi të Transferimit të Të Dhënave
   BUFFERCOUNT = { buffercount | @buffercount_variable }
 | MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }

— do tĂ« thotĂ« se aty kishte diçka, por unĂ« e heq atĂ«, sepse aktualisht nuk i pĂ«rket temĂ«s.

Si e bëni zakonisht backup-in? Si "mësojnë" të bëjnë backup në miliarda artikuj? Nëse do të duhet të bëj një backup të një baze jo shumë të madhe, automatikisht do të shkruaj diçka si kjo:

BASHKUP DATABAZA smth
TE DISK = 'D:Backupsmth.bak'
ME STATISTIKAT = 10, CHECKSUM, KOMPREMIM, KOPJIM_VETËM;
-- mir, CHECKSUM është shkruar vetëm për të dukur më i zgjuar

Dhe, në përgjithësi, këtu janë përmendur ndoshta 75-90% e të gjitha parametërve që zakonisht përmenden në artikujt mbi backup. Aty është INIT, SKIP dhe të tjerë. A keni shkuar në MSDN? E keni parë se sa shumë opsione ka atje? Edhe unë e kam parë...

Besoj se tashmĂ« e keni kuptuar se mĂ« poshtĂ« do tĂ« flasĂ« pĂ«r tre parametra qĂ« kanĂ« mbetur nĂ« bllokun e parĂ« tĂ« kodit — BLOCKSIZE, BUFFERCOUNT dhe MAXTRANSFERSIZE. Ja pĂ«rshkrimet e tyre nga MSDN:

BLOCKSIZE = { blocksize | @ blocksize_variable } — pĂ«rcakton madhĂ«sinĂ« fizike tĂ« bllokut nĂ« byte. MadhĂ«sitĂ« 512, 1024, 2048, 4096, 8192, 16 384, 32 768 dhe 65 536 byte (64 KB) mbĂ«shteten. Vlera e parazgjedhur Ă«shtĂ« 65 536 pĂ«r pajisjet me kaseta dhe 512 pĂ«r pajisje tĂ« tjera. Zakonisht, nuk Ă«shtĂ« nevoja pĂ«r kĂ«tĂ« parametĂ«r, pasi instruksioni BACKUP automatikisht zgjidh madhĂ«sinĂ« e bllokut qĂ« i pĂ«rshtatet pajisjes. Vendosja e njĂ« madhĂ«sie blloku tĂ« qartĂ« tejkalon zgjedhjen automatike tĂ« madhĂ«sisĂ« sĂ« bllokut.

BUFFERCOUNT = { buffercount | @ buffercount_variable } — pĂ«rcakton numrin e pĂ«rgjithshĂ«m tĂ« bufeve tĂ« hyrjes-daljes qĂ« do tĂ« pĂ«rdoren pĂ«r operacionin e kopjimit rezervĂ«. Mund tĂ« tregoni çdo vlerĂ« tĂ« plotĂ« pozitive, megjithatĂ« njĂ« numĂ«r i madh bufeve mund tĂ« shkaktojĂ« njĂ« gabim mungese shkallĂ« memorie pĂ«r shkak tĂ« hapĂ«sirĂ«s sĂ« tepĂ«rt virtuale tĂ« adresĂ«s gjatĂ« procesit Sqlservr.exe.

Vëllimi i përgjithshëm i hapësirës që përdoret nga buferat përcaktohet sipas formulës së mëposhtme: BUFFERCOUNT * MAXTRANSFERSIZE.

MAXTRANSFERSIZE = { maxtransfersize | @ maxtransfersize_variable } tregon shumën maksimale të paketës së të dhënave në byte për shkëmbimin e të dhënave midis SQL Server dhe mediave të rezervës. Vlerat që mbështeten janë ato që janë shumëfish të 65 536 byte (64 KB), deri në 4 194 304 byte (4 MB).

Premtoj — e kam lexuar kĂ«tĂ« mĂ« parĂ«, por nuk mĂ« ka shkuar ndonjĂ«herĂ« nĂ« mendje se sa shumĂ« ndikim mund tĂ« kenĂ« nĂ« performancĂ«. PĂ«r mĂ« tepĂ«r, duket se duhet tĂ« bĂ«j njĂ« "dalje" dhe tĂ« pranoj se edhe tani nuk e kuptoj plotĂ«sisht se çfarĂ« bĂ«jnĂ« ato. Ndoshta duhet tĂ« lexoj mĂ« shumĂ« rreth futjes/faqes sĂ« informacionit dhe punĂ«s me diskun e ngurtĂ«. NjĂ« ditĂ« do ta bĂ«j kĂ«tĂ«, por tani thjesht mund tĂ« shkruaj njĂ« skenar qĂ« do tĂ« kontrollojĂ« si kĂ«to vlera ndikojnĂ« nĂ« shpejtĂ«sinĂ« me tĂ« cilĂ«n merret backup-i.

Kam krijuar një bazë të vogël, rreth 10 GB, e kam vendosur në SSD, dhe katalogun për backup-e e kam vendosur në HDD.

Po krijoj një tabelë për të ruajtur rezultatet (nuk është e përkohshme, për të pasur mundësinë të shqyrtoj rezultatet më në detaje, por ju vendosni vetë):

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
);

Parimi i funksionit tĂ« skriptĂ«s Ă«shtĂ« i thjeshtĂ« — cikle tĂ« ngulitura, secili prej tĂ« cilave ndryshon vlerĂ«n e njĂ« parametri, i japin komandĂ«s BACKUP kĂ«ta parametra, ruaj regjistrimin e fundit me historinĂ« nga msdb.dbo.backupset, fshij skedarin e bĂ«rjes sĂ« kopjes dhe iterimi i ardhshĂ«m. Duke qenĂ« se tĂ« dhĂ«nat mbi ekzekutimin e kopjes merret nga backupset, saktĂ«sia paksa humbet (atje nuk ka fraksione sekondash), por kĂ«tĂ« do ta pĂ«rballojmĂ«.

Së pari, duhet të lejohet përdorimi i xp_cmdshell, për të fshirë kopjet rezervë (pastaj mos harroni ta çaktivizoni, nëse nuk ju nevojitet):

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

Tani dhe, në të vërtetë:

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);

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

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

/* Vlerat e MAXTRANSFERSIZE */
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

NĂ«se ndonjĂ«herĂ« ju nevojiten sqarime pĂ«r atĂ« qĂ« po ndodh kĂ«tu — shkruani nĂ« komentet, ose privatisht. Deri tani do tĂ« flas vetĂ«m pĂ«r parametrat qĂ« po i dĂ«rgoj nĂ« BACKUP DATABASE.

PĂ«r BLOCKSIZE kemi njĂ« listĂ« "tĂ« mbyllur" vlerash; siç ndodhi, nuk sigurova njĂ« backup me BLOCKSIZE < 4KB. MAXTRANSFERSIZE Ă«shtĂ« çdo numĂ«r qĂ« Ă«shtĂ« e shumĂ«fish i 64KB — nga 64KB deri nĂ« 4MB. Me default, nĂ« sistemin tim Ă«shtĂ« 1024KB, unĂ« zgjodha 512 — 1024 — 2048 — 4096.

Ishin mĂ« tĂ« komplikuara me BUFFERCOUNT — ai mund tĂ« jetĂ« çdo numĂ«r pozitiv, ndĂ«rsa nĂ« lidhje thuhet si llogaritet nĂ« BACKUP DATABASE dhe çfarĂ« rreziku sjellin vlerat e mĂ«dha. Aty vihet re se si tĂ« marrĂ«sh informacion mbi BUFFERCOUNT real me tĂ« cilin merret backup - pĂ«r mua kĂ«tu Ă«shtĂ« 7. Nuk kishte kuptim ta ulesha, ndĂ«rsa kufiri i sipĂ«rm u zbulua nĂ« mĂ«nyrĂ« eksperimentale - kur BUFFERCOUNT = 896 dhe MAXTRANSFERSIZE = 4194304 backup dĂ«shtoi me njĂ« gabim (pĂ«r tĂ« cilin flitet nĂ« lidhjen e sipĂ«rme):

Msg 3013, Level 16, State 1, Line 7 BACKUP DATABASE po përfundon në mënyrë anormale.

Msg 701, Level 17, State 123, Line 7 Ka kujtesĂ« tĂ« pamjaftueshme tĂ« sistemit nĂ« grupin e burimeve ‘default’ pĂ«r tĂ« pĂ«rfunduar kĂ«tĂ« pyetje.

Për krahasim, fillimisht do të tregoj rezultatet e ekzekutimit të backup-it pa treguar asnjë parametër:

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

Epo, backup dhe backup:

PĂ«rpunuar 1070072 faqe pĂ«r bazĂ«n e tĂ« dhĂ«nave ‘bt’, skedari ‘bt’ nĂ« skedarin 1.

PĂ«rpunuar 2 faqe pĂ«r bazĂ«n e tĂ« dhĂ«nave ‘bt’, skedari ‘bt_log’ nĂ« skedarin 1.

BACKUP DATABASE e përpunoi me sukses 1070074 faqe në 53.171 sekonda (157.227 MB/sec).

Skrypti vetë, i cili teston parametrat, punoi për disa orë, të gjitha matjet në tabelën Google. Kjo është një ekstrakt i rezultateve që kanë tre kohët më të mira të ekzekutimit (përpiqesha të bëja një grafik të bukur, por në këtë post, do të kemi një tabelë, ndërsa në komentet @mixsture shtuar grafika shumë të shkëlqyera).

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;

MS SQL Server: BACKUP në steroide

Kujdes, një shënim shumë të rëndësishëm nga @mixsture nga komenti:

mund të thuhet me siguri se lidhja midis parametrave dhe shpejtësisë së backup-it në këto kufij është e rastësishme, nuk ka asnjë rregullsi. Por largimi nga parametrat e ndërtuar, është e qartë se ka pasur një efekt pozitiv në rezultat

Pra, vetëm përmes menaxhimit të parametrave standardë të BACKUP-u arritëm një përfitim në kohën e marrjes së backup-it në 2 herë: 26 sekonda, krahasuar me 53 në fillim. Dhe nuk është keq, apo jo? Por duhet të shikojmë se çfarë ndodh me rikuperimin. Mos vallë tani do të marrë 4 herë më shumë kohë për t'u rikuperuar?

Për fillim, le të masim se sa zgjat rikuperimi i backup-it me parametrat e paracaktuar:

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

Epo, këtë e dini vetë, rrugët atje, replace-në ose jo, recovery-në ose jo. Dhe unë e kryej kështu:

PĂ«rpunuar 1070072 faqe pĂ«r bazĂ«n e tĂ« dhĂ«nave ‘bt’, skedari ‘bt’ nĂ« skedarin 1.

PĂ«rpunuar 2 faqe pĂ«r bazĂ«n e tĂ« dhĂ«nave ‘bt’, skedari ‘bt_log’ nĂ« skedarin 1.

RILINDI DATABASE e përpunoi me sukses 1070074 faqe në 40.752 sekonda (205.141 MB/sec).

Tani do të provoj të rikuperoj kopjet rezervë të bëra me parametra të ndryshuar BLOCKSIZE, BUFFERCOUNT dhe MAXTRANSFERSIZE.

BLOCKSIZE = 16384, BUFFERCOUNT = 224, MAXTRANSFERSIZE = 4194304

RILINDI DATABASE e përpunoi me sukses 1070074 faqe në 32.283 sekonda (258.958 MB/sec).

BLOCKSIZE = 4096, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 4194304

RILINDI DATABASE e përpunoi me sukses 1070074 faqe në 32.682 sekonda (255.796 MB/sec).

BLOCKSIZE = 16384, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 2097152

RILINDI DATABASE e përpunoi me sukses 1070074 faqe në 32.091 sekonda (260.507 MB/sec).

BLOCKSIZE = 4096, BUFFERCOUNT = 56, MAXTRANSFERSIZE = 4194304

RILINDI DATABASE e përpunoi me sukses 1070074 faqe në 32.401 sekonda (258.015 MB/sec).

Instruksioni RILINDI DATABASE gjatĂ« rikuperimit nuk ndryshon, kĂ«ta parametra nuk pĂ«rcaktohen, SQL Server i identifikon ato vetĂ« nga kopja rezervĂ«. Dhe Ă«shtĂ« e qartĂ« se edhe gjatĂ« rikuperimit mund tĂ« ketĂ« pĂ«rfitim — praktikisht deri nĂ« 20% mĂ« shpejt (sinqerisht, nuk kam kaluar shumĂ« kohĂ« nĂ« rikuperim, kam provuar disa nga kopjet rezervĂ« mĂ« "tĂ« shpejta" dhe u sigurua se nuk ka pĂ«rkeqĂ«sim).

PĂ«r çdo rast, do tĂ« sqaroj – kĂ«tu janĂ« pĂ«rshkruar parametra qĂ« nuk janĂ« optimale pĂ«r tĂ« gjithĂ«. Parametrat optimalĂ« pĂ«r ju mund t'i merrni vetĂ«m pĂ«rmes testimit. UnĂ« kam marrĂ« kĂ«to rezultate, ju do tĂ« merrni tĂ« tjera. Por shihni, se kopjet tuaja tĂ« sigurisĂ« mund tĂ« "tune" dhe ato vĂ«rtet mund tĂ« formohen dhe rikthehen mĂ« shpejt.

Po ashtu, është thelbësore të rekomandoj që ta lexoni dokumentacionin në tërësi, sepse për sistemin tuaj mund të ketë nuanca.

Pasi fillova të flas për kopjet e sigurisë, dua të përmend një tjetër "optimizim" që ndodh më shpesh se "tuning" i parametrave (këtë e përdorin, sa di unë, të paktën disa utilitare për kopje rezervë, ndoshta së bashku me parametrat e përshkruar më parë), por ende nuk është përshkruar në Habra.

Nëse shikoni rreshtin e dytë në dokumentacion, menjëherë poshtë BACKUP DATABASE, aty shohim:

TO  [ ,...n ]

ÇfarĂ« mendoni se do tĂ« ndodhĂ« nĂ«se tregoni disa backup_device? Sintaksa e lejon. NjĂ« gjĂ« interesante do tĂ« ndodhte — backup-i do tĂ« "spillej" nĂ« disa pajisje. KĂ«shtu, çdo "pajisje" e veçantĂ« do tĂ« ishte e padobishme; nĂ«se humbni njĂ«, humbni tĂ« gjithĂ« backup-in. Por si do tĂ« ndikojĂ« kjo spĂ«rkatur nĂ« shpejtĂ«sinĂ« e kopjimit rezervĂ«?

Le të përpiqemi të bëjmë një backup në dy "pajisje", që ndodhen pranë njëra-tjetrës në një dosje:

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

Oh, Zot, çfarë po ndodh këtu?

PĂ«rpunuar 1070072 faqe pĂ«r bazĂ«n e tĂ« dhĂ«nave ‘bt’, skedari ‘bt’ nĂ« skedarin 1.

PĂ«rpunuar 2 faqe pĂ«r databazĂ«n ‘bt’, skedari ‘btlog’ nĂ« skedarin 1.

BACKUP DATABASE u përpunua me sukses 1070074 faqe në 40.092 sekonda (208.519 MB/sec).

Backup u bĂ« 25% mĂ« shpejt thjesht nga askund? ÇfarĂ« ndodh nĂ«se shtojmĂ« edhe disa pajisje?

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

BACKUP DATABASE u përpunua me sukses 1070074 faqe në 34.234 sekonda (244.200 MB/sec).

NĂ« total, kursimi Ă«shtĂ« rreth 35% kohĂ« pĂ«r tĂ« bĂ«rĂ« backup vetĂ«m nga fakti se backup-i shkruhet menjĂ«herĂ« nĂ« 4 skedarĂ« nĂ« njĂ« disk. Kam provuar mĂ« shumĂ«, dhe nĂ« laptopin tim kursimi mungon, optimalja Ă«shtĂ« 4 pajisje. PĂ«r ju – nuk e di, duhet provuar. Dhe, pĂ«r t'u thĂ«nĂ« tĂ« drejtĂ«n, nĂ«se kĂ«to pajisje janĂ« diskĂ« tĂ« ndryshĂ«m, urime, kursimi duhet tĂ« jetĂ« edhe mĂ« i dukshĂ«m.

Tani flasim si ta rikuperojmë këtë ndihmë. Për këtë do të duhet të ndryshoni komandën e rikuperimit dhe të enumeroni të gjitha pajisjet:

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

RESTORE DATABASE u përpunua me sukses 1070074 faqe në 38.027 sekonda (219.842 MB/sec).

Pak mĂ« shpejt, por diku afĂ«r, jo ndjeshĂ«m. NĂ« pĂ«rgjithĂ«si, backup-i merret mĂ« shpejt, dhe rikuperimi ndodh njĂ«soj – sukses? SipĂ«rmarr mĂ« duket se Ă«shtĂ« njĂ« sukses. Kjo Ă«shtĂ« e rĂ«ndĂ«sishme, prandaj po e pĂ«rsĂ«ris – nĂ«se ju humbeni edhe njĂ« nga kĂ«to skedarĂ« – humbni tĂ« gjithĂ« backup-in.

Nëse shihni informacionin në regjistrin e backup-it, i nxjerrë me ndihmën e Trace Flag 3213 dhe 3605, mund të vëreni se kur bëhet backup në disa pajisje, rritet, të paktën, numri i BUFFERCOUNT. Ndoshta mund të provoni të përcaktoni parametra më optimalë edhe për BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE, por unë nuk arrita ta bëj menjëherë, dhe të bëj një testim të tillë përsëri, por për një numër të ndryshëm skedarësh u ndjeva të ngarkuar. Dhe disqet janë të çmuara. Nëse dëshironi të organizoni një testim të tillë tek ju, skripti është i lehtë për t'u rregulluar.

NĂ« fund do tĂ« flasim pĂ«r çmimin. NĂ«se backup-i bĂ«het paralelisht me punĂ«n e pĂ«rdoruesve — duhet t'i qasemi testimit me shumĂ« pĂ«rgjegjĂ«si, sepse nĂ«se backup-i bĂ«het mĂ« shpejt — disqet ngarkohen mĂ« shumĂ«, ngarkesa nĂ« procesor rritet (duhet ta kompresosh kĂ«tĂ« gjithashtu nĂ« fluturim), pĂ«r pasojĂ«, pĂ«rgjigjshmĂ«ria e pĂ«rgjithshme e sistemit ulet.

Me shaka-shaka, por e kuptoj plotĂ«sisht se nuk kam bĂ«rĂ« ndonjĂ« zbulim. Ajo qĂ« u shkrua mĂ« lart — Ă«shtĂ« thjesht njĂ« demonstruar se si mund tĂ« pĂ«rcaktohen parametrat optimalĂ« pĂ«r tĂ« bĂ«rĂ« backup.

Mbani se kujtojme, se çdo gjĂ« qĂ« bĂ«ni – e bĂ«ni me rrezikun tuaj. Kontrolloni kopjet tuaja rezervĂ« dhe mos harroni pĂ«r DBCC CHECKDB.

Burimi: habr.com

Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« đŸ”„ Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« | ProHoster