Itxaron! Itxaron! Egia da, hau ez da SQL Server-en babeskopiei buruzko beste artikulu bat. Ez dut hitz egingo berreskuratze-ereduen arteko desberdintasunei eta hazitako erregistro bati nola aurre egin.
Beharbada (bakarrik agian), mezu hau irakurri ondoren, bitarteko estandarrak erabiliz kentzen zaizun babeskopia bihar gauean kenduko dela ziurtatu ahal izango duzu, tira, 1.5 aldiz azkarrago. Eta BACKUP DATABASE parametro apur bat gehiago erabiltzen duzulako bakarrik.
Argitalpenaren edukia begi-bistakoa bazaizu, barkatu. Google-k lortutako guztia irakurri nuen "habr sql server backup" esaldirako, eta artikulu bakar batean ere ez nuen aipamenik aurkitu babeskopia-denbora nolabait parametroak erabiliz eragin dezakeela.
Berehala atentzioa deituko dizut Alexander Gladchenkoren iruzkinera ():
Inoiz ez aldatu BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE parametroak ekoizpenean. Horrelako artikuluak idazteko bakarrik egiten dira. Praktikan, denbora gutxian memoria-arazoak kenduko dituzu.
Noski, polita izango litzateke adimentsuena izatea eta eduki esklusiboa argitaratzea, baina, zoritxarrez, ez da horrela. Ingelesezko eta errusierazko artikuluak/mezuak daude (beti nahastuta nago nola deitu behar den behar bezala) gai honi eskainita. Hona hemen aurkitu ditudan batzuk: , , .
Beraz, hasteko, BACKUP sintaxi txiki bat erantsiko dut (Bide batez, gorago idatzi nuen BACKUP DATABASEari buruz, baina hau guztia transakzioen erregistroaren babeskopiari eta babeskopia diferentzialari dagokio, baina agian efektu ez hain ageriko batekin):
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 }
<...><β¦> - esan nahi du hor bazegoela zerbait, baina kendu egin dut, orain gaiari dagokiona ez delako.
Nola hartu ohi duzu babeskopia? Nola "irakasten" dute milaka milioi artikulutan babeskopiak nola egin? Oro har, datu-base ez oso handi batzuen babeskopia bat egin behar badut, automatikoki honelako zerbait idatziko dut:
BACKUP DATABASE smth
TO DISK = 'D:Backupsmth.bak'
WITH STATS = 10, CHECKSUM, COMPRESSION, COPY_ONLY;
--Π»Π°Π΄Π½ΠΎ, CHECKSUM Ρ Π½Π°ΠΏΠΈΡΠ°Π» ΡΠΎΠ»ΡΠΊΠΎ ΡΡΠΎΠ±Ρ ΠΊΠ°Π·Π°ΡΡΡΡ ΡΠΌΠ½Π΅Π΅Eta, oro har, ziurrenik babeskopiei buruzko artikuluetan aipatu ohi diren parametro guztien % 75-90 hemen zerrendatzen dira. Tira, INIT, SKIP ere badago. MSDN bisitatu al duzu? Ikusi al duzu pantaila eta erdirako aukerak daudela? Nik ere ikusi nuen...
Seguruenik dagoeneko konturatu zara kodearen lehen blokean geratzen ziren hiru parametroei buruz hitz egingo dugula: BLOCKSIZE, BUFFERCOUNT eta MAXTRANSFERSIZE. Hona hemen MSDN-tik haien deskribapenak:
BLOKE TAMAINA = { bloke-tamaina | @ bloke-tamaina_aldagaia } - bloke fisikoaren tamaina bytetan adierazten du. Onartzen diren tamainak 512, 1024, 2048, 4096, 8192, 16, 384 eta 32 byte (768 KB) dira. Balio lehenetsia 65 da zinta-gailuetarako eta 536 beste gailuetarako. Normalean parametro hau ez da beharrezkoa BACKUP adierazpenak automatikoki hautatzen baitu gailurako bloke-tamaina egokia. Bloke-tamaina ezartzeak bloke-tamainaren hautaketa automatikoa gainidazten du esplizituki.
BUFFERCOUNT = { bufferzenbaketa | @ buffercount_variable } - Babeskopia eragiketarako erabiliko den I/O buffer kopuru osoa definitzen du. Zenbaki osoko edozein balio positibo zehaztu dezakezu, baina buffer-kopuru handi batek memoriarik gabeko errore bat sor dezake Sqlservr.exe prozesuan helbide birtualen espazio gehiegi dagoelako.
Buffer-ek erabiltzen duten espazio-kopurua, formula honen bidez zehazten da:
BUFFERCOUNT * MAXTRANSFERSIZE.
MAXTRANSFERSIZE = { gehienezko transferentzia | @ maxtransfersize_variable } datu-paketeen tamaina handiena zehazten du, bytetan, SQL Server eta babeskopia multzoko euskarriaren artean trukatzeko. 65 byte (536 KB) 64 byte (4 MB) arteko multiploak onartzen dira.
Zin dagizut, hau irakurri dudala lehenago, baina ez zait burutik bururatu zenbaterainoko eragina izan dezaketen produktibitatean. Gainera, itxuraz, βirteeraβ moduko bat egin behar dut eta aitortu orain ere ez dudala guztiz ulertzen zertan ari diren zehazki. Seguruenik, buffered I/O eta disko gogor batekin lan egiteari buruz gehiago irakurri beharko dut. Noizbait egingo dut hau, baina oraingoz balio hauek segurtasun kopia egiteko abiaduran nola eragiten duten egiaztatuko duen script bat idatzi dezaket.
Datu-base txiki bat egin nuen, 10 GB ingurukoa, SSDan jarri eta babeskopien direktorioa HDDean.
Emaitzak gordetzeko behin-behineko taula bat sortzen dut (ez daukat aldi baterako, emaitzak xehetasun gehiagorekin sakondu ahal izateko, baina zuk zeuk erabakitzen duzu):
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
);Scriptaren printzipioa sinplea da: habiaratutako begiztak, horietako bakoitzak parametro baten balioa aldatzen du, txertatu parametro hauek BACKUP komandoan, gorde azken erregistroa historiarekin msdb.dbo.backupset-etik, ezabatu babeskopia fitxategia eta hurrengo iterazioa. . Babeskopia exekutatzeko datuak babeskopia multzotik hartzen direnez, zehaztasuna zertxobait galdu egiten da (ez dago segundo zatirik), baina bizirik iraungo dugu.
Lehenik eta behin, xp_cmdshell gaitu behar duzu babeskopiak ezabatzeko (ondoren, ez ahaztu behar ez baduzu desgaitzea):
EXEC sp_configure 'show advanced options', 1;
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;
EXEC sp_configure 'show advanced options', 0;
GOBeno, egia esan:
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;
ENDHemen gertatzen ari denari buruz bat-batean argitu behar baduzu, idatzi iruzkinetan edo PM. Oraingoz, BACKUP DATABASEean jartzen ditudan parametroei buruz bakarrik esango dizut.
BLOCKSIZE-rako balioen zerrenda "itxita" dugu, eta ez dut babeskopiarik egin BLOCKSIZE < 4KB-rekin. MAXTRANSFERSIZE 64KB-ren multiploa den edozein zenbaki - 64KBtik 4MBra. Nire sistemako lehenetsia 1024KB da, 512 - 1024 - 2048 - 4096 hartu nuen.
BUFFERCOUNT-ekin zailagoa izan da - edozein zenbaki positiboa izan daiteke, baina estekak dio . Babeskopia benetan zein BUFFERCOUNTrekin egin den informazioa nola lortu ere esaten du - niretzat 7 da. Ez zen balio hura murrizteak, eta goiko muga esperimentalki aurkitu zen - BUFFERCOUNT = 896 eta MAXTRANSFERSIZE = 4194304rekin babeskopia erori zen. errore bat (goiko estekan idatzita dagoenari buruz):
3013. Mezua, 16. maila, 1. egoera, 7. lerroa BACKUP DATABASE modu anormalean amaitzen ari da.
701. Mezua, 17. maila, 123. egoera, 7. lerroa Ez dago sistema-memoria nahikoa baliabide-biltegian "lehenetsia" kontsulta hau exekutatzeko.
Konparazio baterako, lehenik babeskopia bat exekutatzeko emaitzak erakutsiko ditut parametrorik zehaztu gabe:
BACKUP DATABASE [bt]
TO DISK = 'D:SQLServerbackupbt.bak'
WITH COMPRESSION;Beno, babeskopia eta babeskopia:
1070072 orrialde prozesatu dira 'bt' datu-baserako, 1 fitxategiko 'bt' fitxategirako.
2 orri prozesatu dira 'bt' datu-baserako, 1 fitxategiko 'bt_log' fitxategirako.
BACKUP DATU-BASEAK 1070074 orrialde behar bezala prozesatu ditu 53.171 segundotan (157.227 MB/s).
Gidoia bera, parametroak probatzen, ordu pare batean funtzionatu zuen, neurketa guztiak sartuta zeuden . Eta hona hemen emaitzen aukeraketa bat hiru exekuzio-denbora hoberenekin (grafiko polit bat egiten saiatu naiz, baina argitalpenean taula batekin konformatu beharko dut, eta iruzkinetan gehitu zuen ).
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;
Kontuz, ohar oso garrantzitsua - :
Ziur esan dezakegu balio-tarte horien barruan parametroen eta babeskopia-abiaduraren arteko erlazioa ausazkoa dela, ez dagoela eredurik. Baina integratutako parametroetatik urruntzeak, jakina, eragin ona izan zuen emaitzan
Horiek. BACKUP parametro estandarrak kudeatuz soilik 2 aldiz irabazi zen babeskopia kentzeko denboran: 26 segundo, hasieran 53. Hori ez dago gaizki, ezta? Baina ikusi behar dugu zer gertatzen den zaharberritzearekin. Zer gertatzen da orain 4 aldiz gehiago behar bada berreskuratzeko?
Lehenik eta behin, neur dezagun zenbat denbora behar den babeskopia lehenetsitako ezarpenekin leheneratzeko:
RESTORE DATABASE [bt]
FROM DISK = 'D:SQLServerbackupbt.bak'
WITH REPLACE, RECOVERY;Beno, zuk zeuk badakizu, bideak hor daude, ordezkatzea ez da ordezkatzea, berreskuratzea ez da berreskuratzea. Eta honela egiten dut:
1070072 orrialde prozesatu dira 'bt' datu-baserako, 1 fitxategiko 'bt' fitxategirako.
2 orri prozesatu dira 'bt' datu-baserako, 1 fitxategiko 'bt_log' fitxategirako.
BERRESARRI DATU-BASEA 1070074 orrialde behar bezala prozesatu ditu 40.752 segundotan (205.141 MB/s).
Orain BLOCKSIZE, BUFFERCOUNT eta MAXTRANSFERSIZE aldatuekin egindako babeskopiak leheneratzen saiatuko naiz.
BLOCKSIZE = 16384, BUFFERCOUNT = 224, MAXTRANSFERSIZE = 4194304BERRESARRI DATU-BASEA 1070074 orrialde behar bezala prozesatu ditu 32.283 segundotan (258.958 MB/s).
BLOCKSIZE = 4096, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 4194304BERRESARRI DATU-BASEA 1070074 orrialde behar bezala prozesatu ditu 32.682 segundotan (255.796 MB/s).
BLOCKSIZE = 16384, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 2097152BERRESARRI DATU-BASEA 1070074 orrialde behar bezala prozesatu ditu 32.091 segundotan (260.507 MB/s).
BLOCKSIZE = 4096, BUFFERCOUNT = 56, MAXTRANSFERSIZE = 4194304BERRESARRI DATU-BASEA 1070074 orrialde behar bezala prozesatu ditu 32.401 segundotan (258.015 MB/s).
RESTORE DATABASE instrukzioa ez da aldatzen berreskuratzean; parametro hauek ez dira bertan zehazten; SQL Server-ek berak zehazten ditu babeskopiatik. Eta argi dago susperraldiarekin ere irabazia egon daitekeela - ia % 20 azkarrago (Egia esateko, ez nuen denbora asko eman berreskurapenean, babeskopia "azkarrenak" egin nituen eta hondatzerik ez zegoela ziurtatu nuen.).
Badaezpada, argitu dezadan hauek ez direla guztientzako optimoak diren parametro batzuk. Parametro optimoak bakarrik lor ditzakezu probak eginez. Emaitza hauek lortu ditut, desberdinak lortuko dituzu. Baina ikusten duzu zure babeskopiak "sintonizatu" ditzakezula eta benetan azkarrago eratu eta zabaldu daitezkeela.
Dokumentazioa osorik irakurtzea ere gomendatzen dizut, zure sistemari dagozkion Γ±abardurak egon daitezkeelako.
Babeskopiei buruz idazten hasi nintzenetik, berehala idatzi nahi dut "optimizazio" bati buruz, "tuning" parametroak baino ohikoagoa dena (ulertzen dudanez, babeskopia-utilitate batzuek erabiltzen dute, agian parametroekin batera). lehenago azaldu zen), baina oraindik ez da HabrΓ©-ri buruz deskribatu.
Dokumentazioko bigarren lerroari erreparatzen badiogu, BACKUP DATU-BASEaren azpian, hor ikusiko dugu:
TO <backup_device> [ ,...n ]Zer gertatuko dela uste duzu hainbat backup_device zehazten badituzu? Sintaxiak ahalbidetzen du. Eta oso gauza interesgarria gertatuko da: babeskopia hainbat gailutan "hedatuko" da. Horiek. "gailu" bakoitza banaka alferrikakoa izango da, bat galdu, babeskopia osoa galdu. Baina nola eragingo du halako zikinkeriak babeskopia abiadura?
Saia gaitezen babeskopia bat egiten karpeta berean elkarren ondoan dauden bi "gailu"tan:
BACKUP DATABASE [bt]
TO
DISK = 'D:SQLServerbackupbt1.bak',
DISK = 'D:SQLServerbackupbt2.bak'
WITH COMPRESSION;Munduko aitak, zergatik egiten da hau?
1070072 orrialde prozesatu dira 'bt' datu-baserako, 1 fitxategiko 'bt' fitxategirako.
2 orrialde prozesatu dira 'bt' datu-baserako, 'bt' fitxategirakosaioa' 1 fitxategian.
BACKUP DATU-BASEAK 1070074 orrialde behar bezala prozesatu ditu 40.092 segundotan (208.519 MB/s).
Babeskopia % 25 azkarrago bihurtu al da nolanahikoa? Zer gertatzen da pare bat gailu gehiago gehitzen baditugu?
BACKUP DATABASE [bt]
TO
DISK = 'D:SQLServerbackupbt1.bak',
DISK = 'D:SQLServerbackupbt2.bak',
DISK = 'D:SQLServerbackupbt3.bak',
DISK = 'D:SQLServerbackupbt4.bak'
WITH COMPRESSION;BACKUP DATU-BASEAK 1070074 orrialde behar bezala prozesatu ditu 34.234 segundotan (244.200 MB/s).
Guztira, irabazia babeskopia egiteko denboraren % 35 ingurukoa da, babeskopia disko batean 4 fitxategitan idazten delako aldi berean. Kopuru handiagoa egiaztatu nuen - nire ordenagailu eramangarrian ez dago irabazirik, hobekien - 4 gailu. Zuretzat - ez dakit, egiaztatu behar duzu. Beno, bide batez, gailu hauek badituzu - benetan disko desberdinak dira, zorionak, irabazia are esanguratsuagoa izan beharko litzateke.
Orain hitz egin dezagun nola berreskuratu zoriontasun hori. Horretarako, berreskuratzeko komandoa aldatu eta gailu guztiak zerrendatu beharko dituzu:
RESTORE DATABASE [bt]
FROM
DISK = 'D:SQLServerbackupbt1.bak',
DISK = 'D:SQLServerbackupbt2.bak',
DISK = 'D:SQLServerbackupbt3.bak',
DISK = 'D:SQLServerbackupbt4.bak'
WITH REPLACE, RECOVERY;BERRESARRI DATU-BASEA 1070074 orrialde behar bezala prozesatu ditu 38.027 segundotan (219.842 MB/s).
Pixka bat azkarrago, baina nonbait hurbil, ez da esanguratsua. Oro har, babeskopia azkarrago kentzen da eta modu berean leheneratzen da - arrakasta? Niri dagokionez, nahiko arrakastatsua da. Hau garrantzitsua da, beraz, errepikatzen dut - baduzu fitxategi horietako bat gutxienez galtzen baduzu, babeskopia osoa galduko duzu.
Erregistroan 3213 eta 3605 Trace Flags erabiliz bistaratzen den babeskopien informazioa aztertzen baduzu, ohartuko zara hainbat gailuren babeskopia egitean, gutxienez BUFFERCOUNT kopurua handitzen dela. Seguruenik, BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE parametro optimoagoak hautatzen saia zaitezke, baina ez nuen berehala lortu, eta alferra izan nintzen horrelako probak berriro egiteko, baina beste fitxategi kopuru baterako. Eta pena da gurpilak. Etxean horrelako probak antolatu nahi badituzu, ez da zaila gidoia berregitea.
Azkenik, hitz egin dezagun prezioaz. Babeskopia erabiltzaileen lanarekin paraleloan kentzen bada, probak egiteko ikuspegi oso arduratsua hartu behar duzu, izan ere, segurtasun kopia azkarrago kentzen bada, diskoak gehiago estutu egiten dira, prozesadorearen karga handitzen da (oraindik konprimitu behar duzu). hegan), eta horren arabera, sistemaren erantzun orokorra gutxitzen da.
Txantxetan, baina primeran ulertzen dut ez dudala errebelaziorik egin. Goian idatzitakoa babeskopiak egiteko parametro optimoak nola hauta ditzakezun erakusteko besterik ez da.
Gogoratu egiten duzun guztia zure arriskuan eta arriskuan egiten dela. Egiaztatu zure babeskopiak eta ez ahaztu DBCC CHECKDB buruz.
Iturria: www.habr.com