एमएस एसक्यूएल सर्वर: स्टेरॉयड पर बैकअप

इंतज़ार! इंतज़ार! सच है, यह SQL सर्वर बैकअप के प्रकारों के बारे में कोई अन्य लेख नहीं है। मैं पुनर्प्राप्ति मॉडल के बीच अंतर और अत्यधिक बढ़े हुए लॉग से निपटने के तरीके के बारे में भी बात नहीं करूंगा।

शायद (बस शायद), इस पोस्ट को पढ़ने के बाद, आप यह सुनिश्चित कर पाएंगे कि मानक साधनों का उपयोग करके आपसे जो बैकअप हटाया गया है, वह कल रात को हटा दिया जाएगा, ठीक है, 1.5 गुना तेजी से। और केवल इस तथ्य के कारण कि आप थोड़े अधिक बैकअप डेटाबेस पैरामीटर का उपयोग करते हैं।

यदि पोस्ट की सामग्री आपके लिए स्पष्ट थी, तो मुझे खेद है। मैंने वह सब कुछ पढ़ा जो Google को "habr sql सर्वर बैकअप" वाक्यांश के लिए मिला, और एक भी लेख में मुझे इस तथ्य का कोई उल्लेख नहीं मिला कि पैरामीटर का उपयोग करके बैकअप समय को किसी तरह प्रभावित किया जा सकता है।

मैं तुरंत आपका ध्यान अलेक्जेंडर ग्लैडचेंको की टिप्पणी की ओर आकर्षित करूंगा (@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 से उनके विवरण दिए गए हैं:

ब्लॉक का आकार = { ब्लॉक का आकार | @ ब्लॉकसाइज़_वेरिएबल } - बाइट्स में भौतिक ब्लॉक आकार को इंगित करता है। समर्थित आकार 512, 1024, 2048, 4096, 8192, 16, 384, और 32 बाइट्स (768 केबी) हैं। टेप डिवाइस के लिए डिफ़ॉल्ट मान 65 और अन्य डिवाइस के लिए 536 है। आमतौर पर यह पैरामीटर आवश्यक नहीं है क्योंकि बैकअप स्टेटमेंट स्वचालित रूप से डिवाइस के लिए उचित ब्लॉक आकार का चयन करता है। ब्लॉक आकार सेट करना स्वचालित ब्लॉक आकार चयन को स्पष्ट रूप से ओवरराइड करता है।

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

बफ़र्स द्वारा उपयोग की जाने वाली जगह की कुल मात्रा निम्नलिखित सूत्र द्वारा निर्धारित की जाती है: BUFFERCOUNT * MAXTRANSFERSIZE.

अधिकतम स्थानान्तरण = { maxtransfersize | @ maxtransfersize_variable } SQL सर्वर और बैकअप सेट मीडिया के बीच आदान-प्रदान के लिए बाइट्स में सबसे बड़ा डेटा पैकेट आकार निर्दिष्ट करता है। 65 बाइट्स (536 केबी) से 64 बाइट्स (4 एमबी) तक के गुणक समर्थित हैं।

मैं कसम खाता हूँ - मैंने इसे पहले भी पढ़ा है, लेकिन मुझे कभी नहीं लगा कि इनका उत्पादकता पर कितना प्रभाव पड़ सकता है। इसके अलावा, जाहिरा तौर पर, मुझे एक तरह का "बाहर आना" बनाना होगा और स्वीकार करना होगा कि अब भी मैं पूरी तरह से समझ नहीं पा रहा हूं कि वे वास्तव में क्या कर रहे हैं। मुझे शायद बफ़र किए गए I/O और हार्ड ड्राइव के साथ काम करने के बारे में और अधिक पढ़ने की ज़रूरत है। किसी दिन मैं ऐसा करूंगा, लेकिन अभी मैं सिर्फ एक स्क्रिप्ट लिख सकता हूं जो जांच करेगी कि ये मान बैकअप लेने की गति को कैसे प्रभावित करते हैं।

मैंने लगभग 10 जीबी आकार का एक छोटा डेटाबेस बनाया, इसे एसएसडी पर रखा, और बैकअप के लिए निर्देशिका को एचडीडी पर रखा।

मैं परिणामों को संग्रहीत करने के लिए एक अस्थायी तालिका बनाता हूं (मेरे पास यह अस्थायी नहीं है, इसलिए मैं परिणामों को अधिक विस्तार से जान सकता हूं, लेकिन आप स्वयं निर्णय लेते हैं):

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

यदि आपको अचानक यहां क्या हो रहा है, इस पर स्पष्टीकरण की आवश्यकता है, तो टिप्पणियों या पीएम में लिखें। अभी के लिए, मैं आपको केवल उन मापदंडों के बारे में बताऊंगा जो मैंने बैकअप डेटाबेस में रखे हैं।

BLOCKSIZE के लिए हमारे पास मानों की एक "बंद" सूची है, और मैंने BLOCKSIZE <4KB के साथ बैकअप नहीं किया है। किसी भी संख्या को, जो 64KB का गुणज हो, अधिकतम ट्रांसफ़र आकार दें - 64KB से 4MB तक। मेरे सिस्टम पर डिफ़ॉल्ट 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;

खैर, बैकअप और बैकअप:

डेटाबेस 'बीटी' के लिए 1070072 पृष्ठ संसाधित, फ़ाइल 1 पर फ़ाइल 'बीटी'।

डेटाबेस 'बीटी' के लिए 2 पेज संसाधित, फ़ाइल 1 पर 'बीटी_लॉग' फ़ाइल।

बैकअप डेटाबेस ने 1070074 सेकंड (53.171 एमबी/सेकंड) में 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;

ठीक है, आप स्वयं जानते हैं कि, तरीके मौजूद हैं, रिप्लेस को रिप्लेस नहीं किया जाता है, रिकवरी को रिकवरी नहीं किया जाता है। और मैं इसे इस तरह करता हूं:

डेटाबेस 'बीटी' के लिए 1070072 पृष्ठ संसाधित, फ़ाइल 1 पर फ़ाइल 'बीटी'।

डेटाबेस 'बीटी' के लिए 2 पेज संसाधित, फ़ाइल 1 पर 'बीटी_लॉग' फ़ाइल।

रीस्टोर डेटाबेस ने 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;

दुनिया के पिताओं, ऐसा क्यों किया जा रहा है?

डेटाबेस 'बीटी' के लिए 1070072 पृष्ठ संसाधित, फ़ाइल 1 पर फ़ाइल 'बीटी'।

डेटाबेस 'बीटी', फ़ाइल 'बीटी' के लिए 2 पेज संसाधितफ़ाइल 1 पर लॉग इन करें।

बैकअप डेटाबेस ने 1070074 सेकंड (40.092 एमबी/सेकंड) में 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 एमबी/सेकंड) में 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 की संख्या बढ़ जाती है। संभवतः, आप BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE के लिए अधिक इष्टतम मापदंडों का चयन करने का प्रयास कर सकते हैं, लेकिन मैं तुरंत सफल नहीं हुआ, और मैं इस तरह के परीक्षण को दोबारा करने के लिए बहुत आलसी था, लेकिन फ़ाइलों की एक अलग संख्या के लिए। और यह पहियों के बारे में शर्म की बात है। यदि आप घर पर इस तरह के परीक्षण का आयोजन करना चाहते हैं, तो स्क्रिप्ट का रीमेक बनाना मुश्किल नहीं है।

अंत में बात करते हैं कीमत की। यदि बैकअप को उपयोगकर्ताओं के काम के समानांतर हटा दिया जाता है, तो आपको परीक्षण के लिए बहुत जिम्मेदार दृष्टिकोण अपनाने की आवश्यकता है, क्योंकि यदि बैकअप तेजी से हटा दिया जाता है, तो डिस्क अधिक तनावग्रस्त हो जाती है, प्रोसेसर पर लोड बढ़ जाता है (आपको अभी भी संपीड़ित करना होगा) यह तुरंत), और तदनुसार, सिस्टम की समग्र प्रतिक्रिया कम हो जाती है।

मैं बस मजाक कर रहा हूं, लेकिन मैं अच्छी तरह समझता हूं कि मैंने कोई खुलासा नहीं किया। ऊपर जो लिखा गया है वह केवल इस बात का प्रदर्शन है कि आप बैकअप लेने के लिए इष्टतम मापदंडों का चयन कैसे कर सकते हैं।

याद रखें कि आप जो कुछ भी करते हैं वह अपने जोखिम और जोखिम पर करते हैं। अपने बैकअप जांचें और DBCC CHECKDB के बारे में न भूलें।

स्रोत: www.habr.com