🥇MS SQL सर्व्हर: स्टिरॉइड्सवर बॅकअप

थांबा! थांबा! खरे आहे, SQL सर्व्हर बॅकअपच्या प्रकारांबद्दल हा दुसरा लेख नाही. मी पुनर्प्राप्ती मॉडेलमधील फरक आणि अतिवृद्ध लॉगचा सामना कसा करावा याबद्दल देखील बोलणार नाही.

कदाचित (फक्त कदाचित), हे पोस्ट वाचल्यानंतर, आपण हे सुनिश्चित करण्यास सक्षम असाल की मानक माध्यमांचा वापर करून आपल्याकडून काढलेला बॅकअप उद्या रात्री, तसेच, 1.5 पट वेगाने काढला जाईल. आणि फक्त तुम्ही थोडे अधिक बॅकअप डेटाबेस पॅरामीटर्स वापरता या वस्तुस्थितीमुळे.

जर पोस्टची सामग्री तुमच्यासाठी स्पष्ट असेल तर मला माफ करा. “habr sql server backup” या वाक्यांशासाठी Google ला मिळालेली प्रत्येक गोष्ट मी वाचली आणि एकाही लेखात मला या वस्तुस्थितीचा उल्लेख आढळला नाही की बॅकअप वेळेवर पॅरामीटर्स वापरून कसा तरी प्रभाव टाकला जाऊ शकतो.

अलेक्झांडर ग्लॅडचेन्कोच्या टिप्पणीकडे मी ताबडतोब आपले लक्ष वेधून घेईन (@mssqlhelp):

उत्पादनातील BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE पॅरामीटर्स कधीही बदलू नका. ते असे लेख लिहिण्यासाठीच बनवले जातात. सराव मध्ये, आपण थोड्याच वेळात स्मरणशक्तीच्या समस्यांपासून मुक्त व्हाल.

अर्थातच, सर्वात हुशार आणि पोस्ट अनन्य सामग्री असणे छान होईल, परंतु, दुर्दैवाने, असे नाही. या विषयाला वाहिलेले इंग्रजी-भाषा आणि रशियन-भाषेतील दोन्ही लेख/पोस्ट आहेत (त्यांना नेमके काय म्हणायचे याबद्दल मी नेहमी संभ्रमात असतो). मला भेटलेल्यांपैकी काही येथे आहेत: वेळा, два, तीन (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 = { ब्लॉक आकार | @ blocksize_variable } - बाइट्समध्ये भौतिक ब्लॉक आकार दर्शवतो. समर्थित आकार 512, 1024, 2048, 4096, 8192, 16, 384 आणि 32 बाइट्स (768 KB) आहेत. टेप उपकरणांसाठी डीफॉल्ट मूल्य 65 आणि इतर उपकरणांसाठी 536 आहे. सामान्यतः हे पॅरामीटर आवश्यक नसते कारण बॅकअप स्टेटमेंट स्वयंचलितपणे डिव्हाइससाठी योग्य ब्लॉक आकार निवडते. ब्लॉक आकार सेट करणे स्पष्टपणे स्वयंचलित ब्लॉक आकार निवड ओव्हरराइड करते.

बफरकाउंट = { बफरगणना | @ buffercount_variable } - बॅकअप ऑपरेशनसाठी वापरल्या जाणार्‍या I/O बफरची एकूण संख्या परिभाषित करते. तुम्ही कोणतेही सकारात्मक पूर्णांक मूल्य निर्दिष्ट करू शकता, परंतु मोठ्या संख्येने बफरमुळे Sqlservr.exe प्रक्रियेमध्ये अत्याधिक व्हर्च्युअल अॅड्रेस स्पेसमुळे मेमरीबाहेर त्रुटी येऊ शकते.

बफरद्वारे वापरलेली एकूण जागा खालील सूत्राद्वारे निर्धारित केली जाते: BUFFERCOUNT * MAXTRANSFERSIZE.

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 चा गुणाकार असलेली कोणतीही संख्या MAXTRANSFERSIZE. माझ्या सिस्टमवर डीफॉल्ट 1024KB आहे, मी 512 - 1024 - 2048 - 4096 घेतले.

BUFFERCOUNT सह हे अधिक कठीण होते - ती कोणतीही सकारात्मक संख्या असू शकते, परंतु दुवा म्हणते बॅकअप डेटाबेसमध्ये त्याची गणना कशी केली जाते आणि मोठी मूल्ये धोकादायक का आहेत?. कोणत्या BUFFERCOUNT चा बॅकअप प्रत्यक्षात घेतला जातो याबद्दल माहिती कशी मिळवायची - माझ्यासाठी ते 7 आहे. ते कमी करण्यात काही अर्थ नव्हता आणि वरची मर्यादा प्रायोगिकरित्या शोधली गेली - BUFFERCOUNT = 896 आणि MAXTRANSFERSIZE = 4194304 सह बॅकअप कमी झाला. एक त्रुटी (ज्याबद्दल वरील लिंकमध्ये लिहिले आहे):

संदेश 3013, स्तर 16, राज्य 1, लाइन 7 बॅकअप डेटाबेस असामान्यपणे समाप्त होत आहे.

Msg 701, Level 17, State 123, Line 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/सेकंद) 205.141 पृष्ठांवर यशस्वीरित्या प्रक्रिया केली.

आता मी बदललेल्या BLOCKSIZE, BUFFERCOUNT आणि MAXTRANSFERSIZE सह घेतलेले बॅकअप पुनर्संचयित करण्याचा प्रयत्न करेन.

BLOCKSIZE = 16384, BUFFERCOUNT = 224, MAXTRANSFERSIZE = 4194304

डेटाबेस पुनर्संचयित करा 1070074 सेकंदात (32.283 MB/सेकंद) 258.958 पृष्ठांवर यशस्वीरित्या प्रक्रिया केली.

BLOCKSIZE = 4096, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 4194304

डेटाबेस पुनर्संचयित करा 1070074 सेकंदात (32.682 MB/सेकंद) 255.796 पृष्ठांवर यशस्वीरित्या प्रक्रिया केली.

BLOCKSIZE = 16384, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 2097152

डेटाबेस पुनर्संचयित करा 1070074 सेकंदात (32.091 MB/सेकंद) 260.507 पृष्ठांवर यशस्वीरित्या प्रक्रिया केली.

BLOCKSIZE = 4096, BUFFERCOUNT = 56, MAXTRANSFERSIZE = 4194304

डेटाबेस पुनर्संचयित करा 1070074 सेकंदात (32.401 MB/सेकंद) 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/सेकंद) 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/सेकंद) 219.842 पृष्ठांवर यशस्वीरित्या प्रक्रिया केली.

थोडे वेगवान, परंतु कुठेतरी जवळ, लक्षणीय नाही. सर्वसाधारणपणे, बॅकअप जलद काढला जातो आणि त्याच प्रकारे पुनर्संचयित केला जातो - यश? माझ्यासाठी, हे खूप यशस्वी आहे. या महत्वाचे आहे, म्हणून मी पुन्हा सांगतो - जर तुम्ही तुम्ही यापैकी किमान एक फाइल गमावल्यास, तुम्ही संपूर्ण बॅकअप गमावाल.

आपण ट्रेस फ्लॅग्स 3213 आणि 3605 वापरून प्रदर्शित केलेल्या बॅकअप माहितीच्या लॉगमध्ये पाहिल्यास, आपल्या लक्षात येईल की अनेक उपकरणांवर बॅकअप घेताना, कमीतकमी BUFFERCOUNT ची संख्या वाढते. कदाचित, तुम्ही BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE साठी अधिक इष्टतम पॅरामीटर्स निवडण्याचा प्रयत्न करू शकता, परंतु मी लगेच यशस्वी झालो नाही आणि मी अशी चाचणी पुन्हा करण्यास खूप आळशी होतो, परंतु भिन्न संख्येच्या फायलींसाठी. आणि चाकांची लाज वाटते. जर तुम्हाला घरच्या घरी अशी चाचणी आयोजित करायची असेल, तर स्क्रिप्टचा रीमेक करणे कठीण नाही.

शेवटी, किंमतीबद्दल बोलूया. जर वापरकर्त्यांच्या कामाच्या समांतर बॅकअप काढला गेला असेल, तर तुम्हाला चाचणीसाठी एक अतिशय जबाबदार दृष्टीकोन घेणे आवश्यक आहे, कारण जर बॅकअप जलद काढला गेला तर, डिस्क अधिक ताणल्या जातात, प्रोसेसरवरील भार वाढतो (तुम्हाला अद्याप संकुचित करावे लागेल. ते फ्लायवर), आणि त्यानुसार, सिस्टमची एकूण प्रतिक्रिया कमी होते.

फक्त गंमत करत आहे, पण मला चांगले समजले आहे की मी कोणताही खुलासा केलेला नाही. वर जे लिहिले आहे ते तुम्ही बॅकअप घेण्यासाठी इष्टतम पॅरामीटर्स कसे निवडू शकता याचे फक्त एक प्रात्यक्षिक आहे.

लक्षात ठेवा की तुम्ही जे काही करता ते तुमच्या स्वतःच्या जोखमीवर आणि जोखमीवर केले जाते. तुमचे बॅकअप तपासा आणि DBCC CHECKDB बद्दल विसरू नका.

स्त्रोत: www.habr.com

एमएस एसक्यूएल सर्व्हर: स्टिरॉइड्सवर बॅकअप

एक टिप्पणी जोडा Отменить ответ