🥇MS SQL सर्भर: स्टेरोइडहरूमा ब्याकअप

पर्खनुहोस्! पर्खनुहोस्! साँचो, यो SQL Server ब्याकअप को प्रकार को बारे मा अर्को लेख छैन। म रिकभरी मोडेलहरू र कसरी बढेको लगसँग व्यवहार गर्ने बीचको भिन्नताहरूको बारेमा पनि कुरा गर्दिन।

सायद (केवल सायद), यो पोष्ट पढिसकेपछि, तपाइँ निश्चित गर्न सक्षम हुनुहुनेछ कि मानक माध्यमहरू प्रयोग गरेर तपाइँबाट हटाइएको ब्याकअप भोलि राती हटाइनेछ, ठीक छ, 1.5 गुणा छिटो। र केवल यस तथ्यको कारणले कि तपाइँ अलि बढी ब्याकअप डाटाबेस प्यारामिटरहरू प्रयोग गर्नुहुन्छ।

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

म तुरुन्तै अलेक्जेन्डर ग्लाडचेन्कोको टिप्पणीमा तपाईंको ध्यान आकर्षित गर्नेछु (@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 = { बफर गणना | @ buffercount_variable } - ब्याकअप सञ्चालनको लागि प्रयोग गरिने I/O बफरहरूको कुल संख्या परिभाषित गर्दछ। तपाईले कुनै पनि सकारात्मक पूर्णांक मान निर्दिष्ट गर्न सक्नुहुन्छ, तर Sqlservr.exe प्रक्रियामा अत्यधिक भर्चुअल ठेगाना स्पेसको कारणले ठूलो संख्यामा बफरहरूले मेमोरी आउटको त्रुटि निम्त्याउन सक्छ।

बफरहरू द्वारा प्रयोग गरिएको ठाउँको कुल मात्रा निम्न सूत्रद्वारा निर्धारण गरिन्छ: BUFFERCOUNT * MAXTRANSFERSIZE.

अधिकतम स्थानान्तरण = { अधिकतम स्थानान्तरण | @ maxtransfersize_variable } SQL सर्भर र ब्याकअप सेट मिडिया बीचको आदानप्रदान गर्न बाइटहरूमा, सबैभन्दा ठूलो डेटा प्याकेट आकार निर्दिष्ट गर्दछ। 65 बाइट्स (536 KB) 64 बाइट्स (4 MB) सम्मको बहुहरू समर्थित छन्।

म कसम खान्छु - मैले यो पहिले पढेको छु, तर यसले उत्पादकतामा कति प्रभाव पार्न सक्छ भन्ने कुरा मलाई कहिल्यै लागेन। यसबाहेक, स्पष्ट रूपमा, मैले एक प्रकारको "बाहिर आउँदै" बनाउनु आवश्यक छ र स्वीकार गर्नुहोस् कि अहिले पनि उनीहरूले के गरिरहेका छन् भनेर मैले पूर्ण रूपमा बुझिन। मलाई सम्भवतः बफर गरिएको 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
);

स्क्रिप्टको सिद्धान्त सरल छ - नेस्टेड लूपहरू, जसमध्ये प्रत्येकले एउटा प्यारामिटरको मान परिवर्तन गर्दछ, यी प्यारामिटरहरूलाई ब्याकअप आदेशमा घुसाउनुहोस्, 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 ब्याकअप डाटाबेस असामान्य रूपमा समाप्त हुँदैछ।

सन्देश 701, स्तर 17, राज्य 123, रेखा 7 यो क्वेरी चलाउनको लागि संसाधन पूल 'पूर्वनिर्धारित' मा अपर्याप्त प्रणाली मेमोरी छ।

तुलनाको लागि, म पहिले कुनै पनि प्यारामिटरहरू निर्दिष्ट नगरी ब्याकअप चलाउने परिणामहरू देखाउनेछु:

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

खैर, ब्याकअप र ब्याकअप:

डाटाबेस 'bt' को लागि 1070072 पृष्ठहरू प्रशोधन गरियो, फाइल 1 मा फाइल 'bt'।

डाटाबेस 'bt', फाइल १ मा फाइल '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 बनाम। त्यो नराम्रो होइन, हैन? तर हामीले पुनर्स्थापना संग के हुन्छ हेर्न आवश्यक छ। अब निको हुन ४ गुणा बढी लागेमा के हुन्छ?

पहिले, पूर्वनिर्धारित सेटिङहरूको साथ ब्याकअप पुनर्स्थापना गर्न कति समय लाग्छ मापन गरौं:

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

ठिक छ, तपाई आफैलाई थाहा छ, त्यहाँ तरिकाहरू छन्, प्रतिस्थापन प्रतिस्थापन होइन, रिकभरी रिकभरी होइन। र म यो गर्छु:

डाटाबेस 'bt' को लागि 1070072 पृष्ठहरू प्रशोधन गरियो, फाइल 1 मा फाइल 'bt'।

डाटाबेस 'bt', फाइल १ मा फाइल '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% छिटो (इमानदारीपूर्वक भन्नुपर्दा, मैले रिकभरीमा धेरै समय खर्च गरिन, मैले धेरै "छिटो" ब्याकअपहरू मार्फत दौडें र निश्चित गरें कि त्यहाँ कुनै खराबी छैन।).

केवल के मामला मा, मलाई स्पष्ट गरौं कि यी केहि प्यारामिटरहरू छैनन् जुन सबैका लागि इष्टतम छन्। तपाईं परीक्षण गरेर मात्र आफ्नो लागि इष्टतम प्यारामिटरहरू प्राप्त गर्न सक्नुहुन्छ। मैले यी नतिजाहरू पाएँ, तपाईंले फरक पाउनुहुनेछ। तर तपाईंले देख्नुहुन्छ कि तपाईंले आफ्नो ब्याकअपहरू "ट्यून" गर्न सक्नुहुन्छ र तिनीहरूले वास्तवमा फारम बनाउन र छिटो विस्तार गर्न सक्छन्।

म पनि दृढताका साथ सिफारिस गर्दछु कि तपाइँ सम्पूर्ण कागजातहरू पढ्नुहोस्, किनकि तपाइँको प्रणालीमा विशिष्टताहरू हुन सक्छ।

मैले ब्याकअपको बारेमा लेख्न सुरु गरेदेखि, म तुरुन्तै अर्को "अप्टिमाइजेसन" को बारेमा लेख्न चाहन्छु, जुन "ट्युनिङ" प्यारामिटरहरू भन्दा धेरै सामान्य छ (जहाँसम्म मैले बुझेको छु, यो कम्तिमा केही ब्याकअप उपयोगिताहरूद्वारा प्रयोग गरिन्छ, सायद प्यारामिटरहरूसँग। पहिले वर्णन गरिएको छ), तर यो अझै Habré मा पनि वर्णन गरिएको छैन।

यदि हामीले ब्याकअप डाटाबेस अन्तर्गत कागजातमा दोस्रो लाइन हेर्‍यौं भने, हामी त्यहाँ देख्छौं:

TO <backup_device> [ ,...n ]

यदि तपाईंले धेरै ब्याकअप_उपकरणहरू निर्दिष्ट गर्नुभयो भने के हुनेछ भन्ने तपाईंलाई लाग्छ? सिन्ट्याक्सले यसलाई अनुमति दिन्छ। र एक धेरै चाखलाग्दो कुरा हुनेछ - जगेडा मात्र धेरै उपकरणहरूमा "फैलिएको" हुनेछ। ती। प्रत्येक "उपकरण" व्यक्तिगत रूपमा बेकार हुनेछ, एउटा हराएको छ, सम्पूर्ण ब्याकअप गुमाएको छ। तर यस्तो स्मीयरिङले ब्याकअप गतिलाई कसरी असर गर्छ?

एउटै फोल्डरमा छेउमा अवस्थित दुई "उपकरणहरू" मा ब्याकअप गर्ने प्रयास गरौं:

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

संसारका पिता, किन यस्तो भइरहेको छ ?

डाटाबेस 'bt' को लागि 1070072 पृष्ठहरू प्रशोधन गरियो, फाइल 1 मा फाइल 'bt'।

डाटाबेस 'bt', फाइल 'bt' को लागि २ पृष्ठहरू प्रशोधन गरियोलग' फाइल 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

MS SQL सर्भर: स्टेरोइडहरूमा ब्याकअप

एक टिप्पणी थप्न Отменить ответ