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 სხვა მოწყობილობებისთვის. როგორც წესი, ეს პარამეტრი არ არის საჭირო, რადგან BACKUP განცხადება ავტომატურად ირჩევს მოწყობილობის შესაბამის ბლოკის ზომას. ბლოკის ზომის დაყენება აშკარად უგულებელყოფს ბლოკის ზომის ავტომატურ შერჩევას.

BUFFERCOUNT = { ბუფერული რაოდენობა | @ buffercount_variable } - განსაზღვრავს I/O ბუფერების საერთო რაოდენობას, რომლებიც გამოყენებული იქნება სარეზერვო ოპერაციისთვის. თქვენ შეგიძლიათ მიუთითოთ ნებისმიერი დადებითი მთელი რიცხვი, მაგრამ ბუფერების დიდმა რაოდენობამ შეიძლება გამოიწვიოს მეხსიერების ამოწურვის შეცდომა Sqlservr.exe პროცესში გადაჭარბებული ვირტუალური მისამართის სივრცის გამო.

ბუფერების მიერ გამოყენებული სივრცის მთლიანი რაოდენობა განისაზღვრება შემდეგი ფორმულით: BUFFERCOUNT * MAXTRANSFERSIZE.

MAXTRANSFERSIZE = { maxtransfersize | @ maxtransfersize_variable } განსაზღვრავს მონაცემთა პაკეტის უდიდეს ზომას, ბაიტებში, რათა გაცვალონ SQL სერვერსა და სარეზერვო კომპლექტის მედიას შორის. მხარდაჭერილია 65 ბაიტი (536 KB) 64 ბაიტი (4 მბ) მრავლობითი.

ვფიცავ - ეს ადრეც წავიკითხე, მაგრამ აზრადაც არ მომსვლია, რამდენად დიდი გავლენა შეიძლება მოახდინონ მათ პროდუქტიულობაზე. უფრო მეტიც, როგორც ჩანს, უნდა გავაკეთო ერთგვარი „კამინგ აუტი“ და ვაღიარო, რომ ახლაც არ მესმის, კონკრეტულად რას აკეთებენ. ალბათ მჭირდება მეტი წაკითხვა ბუფერული 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-ით. MAXTRANSFERSIZE ნებისმიერი რიცხვი, რომელიც არის 64KB-ის ჯერადი - 64KB-დან 4MB-მდე. ჩემს სისტემაზე ნაგულისხმევი არის 1024KB, მე ავიღე 512 - 1024 - 2048 - 4096.

BUFFERCOUNT-ით უფრო რთული იყო - ეს შეიძლება იყოს ნებისმიერი დადებითი რიცხვი, მაგრამ ლინკზე წერია როგორ გამოითვლება ის სარეზერვო მონაცემთა ბაზაში და რატომ არის საშიში დიდი მნიშვნელობები?. ასევე ნათქვამია, თუ როგორ მივიღოთ ინფორმაცია იმის შესახებ, თუ რომელი BUFFERCOUNT-ით არის გაკეთებული სარეზერვო ასლი - ჩემთვის ეს არის 7. მის შემცირებას აზრი არ ჰქონდა და ზედა ზღვარი ექსპერიმენტულად იქნა აღმოჩენილი - BUFFERCOUNT = 896 და MAXTRANSFERSIZE = 4194304 სარეზერვო ასლი დაეცა. შეცდომა (რომლის შესახებაც ზემოთ ბმულზე წერია):

Msg 3013, დონე 16, მდგომარეობა 1, ხაზი 7 სარეზერვო მონაცემთა ბაზა არანორმალურად მთავრდება.

Msg 701, დონე 17, მდგომარეობა 123, ხაზი 7 არ არის საკმარისი სისტემის მეხსიერება რესურსების აუზში "ნაგულისხმევი" ამ მოთხოვნის გასაშვებად.

შედარებისთვის, მე პირველ რიგში გაჩვენებთ სარეზერვო ასლის გაშვების შედეგებს რაიმე პარამეტრის მითითების გარეშე:

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

ისე, სარეზერვო და სარეზერვო:

დამუშავებული 1070072 გვერდი მონაცემთა ბაზისთვის 'bt', ფაილი 'bt' ფაილში 1.

დამუშავებულია 2 გვერდი მონაცემთა ბაზისთვის 'bt', ფაილი 'bt_log' ფაილში 1.

BACKUP DATABASE-მა წარმატებით დაამუშავა 1070074 გვერდი 53.171 წამში (157.227 მბ/წმ).

თავად სკრიპტი, პარამეტრების ტესტირება, მუშაობდა რამდენიმე საათში, ყველა გაზომვა იყო google ცხრილი. და აქ არის შედეგების შერჩევა სამი საუკეთესო შესრულების დროით (მე ვცადე ლამაზი გრაფიკის გაკეთება, მაგრამ პოსტში უნდა დავკმაყოფილდე ცხრილით და კომენტარებით @ mixsture დამატებული ძალიან მაგარი გრაფიკა).

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;

ყურადღება, ძალიან მნიშვნელოვანი შენიშვნა @ mixsture საქართველოს კომენტარი:

თამამად შეგვიძლია ვთქვათ, რომ პარამეტრებსა და სარეზერვო სიჩქარეს შორის ურთიერთობა მნიშვნელობების ამ დიაპაზონში შემთხვევითია, არ არსებობს ნიმუში. მაგრამ ჩაშენებული პარამეტრებისგან დაშორება აშკარად კარგად იმოქმედა შედეგზე

იმათ. მხოლოდ სტანდარტული BACKUP პარამეტრების მართვით იყო 2-ჯერადი მომატება სარეზერვო ასლის ამოღების დროს: 26 წამი, დასაწყისში 53-ის წინააღმდეგ. ეს არ არის ცუდი, არა? მაგრამ ჩვენ უნდა ვნახოთ, რა მოხდება აღდგენით. რა მოხდება, თუ ახლა 4-ჯერ მეტი დრო დასჭირდება აღდგენას?

პირველი, მოდით გავზომოთ რამდენი დრო სჭირდება სარეზერვო ასლის აღდგენას ნაგულისხმევი პარამეტრებით:

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

თქვენ თვითონ იცით, რომ გზები არსებობს, ჩანაცვლება არ არის ჩანაცვლება, აღდგენა არ არის აღდგენა. და მე ვაკეთებ ასე:

დამუშავებული 1070072 გვერდი მონაცემთა ბაზისთვის 'bt', ფაილი 'bt' ფაილში 1.

დამუშავებულია 2 გვერდი მონაცემთა ბაზისთვის 'bt', ფაილი 'bt_log' ფაილში 1.

RESTORE DATABASE-მა წარმატებით დაამუშავა 1070074 გვერდი 40.752 წამში (205.141 მბ/წმ).

ახლა ვეცდები აღვადგინო შეცვლილი BLOCKSIZE, BUFFERCOUNT და MAXTRANSFERSIZE-ით გადაღებული სარეზერვო ასლები.

BLOCKSIZE = 16384, BUFFERCOUNT = 224, MAXTRANSFERSIZE = 4194304

RESTORE DATABASE-მა წარმატებით დაამუშავა 1070074 გვერდი 32.283 წამში (258.958 მბ/წმ).

BLOCKSIZE = 4096, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 4194304

RESTORE DATABASE-მა წარმატებით დაამუშავა 1070074 გვერდი 32.682 წამში (255.796 მბ/წმ).

BLOCKSIZE = 16384, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 2097152

RESTORE DATABASE-მა წარმატებით დაამუშავა 1070074 გვერდი 32.091 წამში (260.507 მბ/წმ).

BLOCKSIZE = 4096, BUFFERCOUNT = 56, MAXTRANSFERSIZE = 4194304

RESTORE DATABASE-მა წარმატებით დაამუშავა 1070074 გვერდი 32.401 წამში (258.015 მბ/წმ).

RESTORE DATABASE განცხადება არ იცვლება აღდგენის დროს; ეს პარამეტრები მასში არ არის მითითებული; SQL Server თავად განსაზღვრავს მათ სარეზერვოდან. და გასაგებია, რომ გამოჯანმრთელების შემთხვევაშიც კი შეიძლება იყოს მომატება - თითქმის 20% უფრო სწრაფად (მართალი გითხრათ, დიდი დრო არ დავხარჯე გამოჯანმრთელებაზე, გავიარე რამდენიმე „ყველაზე სწრაფი“ სარეზერვო საშუალება და დავრწმუნდი, რომ გაუარესება არ მომხდარა).

ყოველ შემთხვევაში, ნება მომეცით განვმარტო, რომ ეს არ არის ზოგიერთი პარამეტრი, რომელიც ყველასთვის ოპტიმალურია. თქვენ შეგიძლიათ მიიღოთ თქვენთვის ოპტიმალური პარამეტრები მხოლოდ ტესტირებით. მე მივიღე ეს შედეგები, თქვენ მიიღებთ სხვადასხვას. მაგრამ თქვენ ხედავთ, რომ შეგიძლიათ თქვენი სარეზერვო ასლების „მორგება“ და ისინი რეალურად უფრო სწრაფად ჩამოყალიბდებიან და განლაგდებიან.

ასევე მკაცრად გირჩევთ, რომ წაიკითხოთ დოკუმენტაცია მთლიანად, რადგან შეიძლება იყოს თქვენი სისტემის სპეციფიკური ნიუანსი.

მას შემდეგ რაც დავიწყე სარეზერვო ასლების წერა, მინდა დაუყოვნებლივ დავწერო კიდევ ერთი "ოპტიმიზაციის" შესახებ, რომელიც უფრო ხშირია ვიდრე "tuning" პარამეტრები (რამდენადაც მე მესმის, მას იყენებენ მინიმუმ რამდენიმე სარეზერვო პროგრამა, შესაძლოა პარამეტრებთან ერთად. ადრე აღწერილი), მაგრამ ჯერ კიდევ არ არის აღწერილი ჰაბრეზე.

თუ გადავხედავთ დოკუმენტაციის მეორე ხაზს, სარეზერვო მონაცემთა ბაზის ქვეშ, ჩვენ ვხედავთ:

TO <backup_device> [ ,...n ]

როგორ ფიქრობთ, რა მოხდება, თუ რამდენიმე სარეზერვო_მოწყობილობას მიუთითებთ? სინტაქსი ამის საშუალებას იძლევა. და ძალიან საინტერესო რამ მოხდება - სარეზერვო ასლი უბრალოდ "გავრცელდება" რამდენიმე მოწყობილობაზე. იმათ. თითოეული "მოწყობილობა" ინდივიდუალურად გამოუსადეგარი იქნება, დაკარგა ერთი, დაკარგა მთელი სარეზერვო საშუალება. მაგრამ როგორ იმოქმედებს ასეთი ნაცხი სარეზერვო ასლის სიჩქარეზე?

შევეცადოთ სარეზერვო ასლის გაკეთება ორ „მოწყობილობებზე“, რომლებიც განლაგებულია გვერდიგვერდ იმავე საქაღალდეში:

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

მსოფლიოს მამებო, რატომ კეთდება ეს?

დამუშავებული 1070072 გვერდი მონაცემთა ბაზისთვის 'bt', ფაილი 'bt' ფაილში 1.

დამუშავებული 2 გვერდი მონაცემთა ბაზისთვის 'bt', ფაილი 'bt'შესვლა ფაილში 1.

BACKUP DATABASE-მა წარმატებით დაამუშავა 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;

BACKUP DATABASE-მა წარმატებით დაამუშავა 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;

RESTORE DATABASE-მა წარმატებით დაამუშავა 1070074 გვერდი 38.027 წამში (219.842 მბ/წმ).

ცოტა უფრო სწრაფი, მაგრამ სადღაც ახლოს, არა მნიშვნელოვანი. ზოგადად, სარეზერვო ასლი უფრო სწრაფად იშლება და აღდგება იგივე გზით - წარმატება? რაც შემეხება მე, ეს საკმაოდ წარმატებულია. ეს მნიშვნელოვანია, ამიტომ ვიმეორებ - თუ თქვენ თუ დაკარგავთ ამ ფაილებიდან ერთს მაინც, დაკარგავთ მთელ სარეზერვო ასლს.

თუ ჟურნალში გადახედავთ Trace Flags 3213 და 3605-ის გამოყენებით გამოჩენილ სარეზერვო ინფორმაციას, შეამჩნევთ, რომ რამდენიმე მოწყობილობაზე სარეზერვო ასლის შექმნისას მინიმუმ BUFFERCOUNT-ის რაოდენობა იზრდება. ალბათ, შეგიძლიათ სცადოთ უფრო ოპტიმალური პარამეტრების არჩევა BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE-სთვის, მაგრამ მე მაშინვე ვერ მივაღწიე წარმატებას და ძალიან მეზარებოდა ასეთი ტესტირების ხელახლა ჩატარება, მაგრამ ფაილების განსხვავებული რაოდენობისთვის. და ბორბლების სირცხვილია. თუ გსურთ ასეთი ტესტირების ორგანიზება სახლში, არ არის რთული სცენარის გადაკეთება.

და ბოლოს, მოდით ვისაუბროთ ფასზე. თუ სარეზერვო ასლი ამოღებულია მომხმარებლების მუშაობის პარალელურად, ძალიან პასუხისმგებლობით უნდა მიდგომა ტესტირებას, რადგან თუ სარეზერვო ასლი უფრო სწრაფად მოიხსნება, დისკები უფრო იძაბება, პროცესორზე დატვირთვა იზრდება (თქვენ მაინც უნდა შეკუმშოთ ის ფრენის დროს) და შესაბამისად, სისტემის საერთო რეაგირება მცირდება.

უბრალოდ ვხუმრობ, მაგრამ მშვენივრად მესმის, რომ რაიმე გამოცხადება არ გამიკეთებია. რაც ზემოთ არის დაწერილი არის უბრალოდ დემონსტრირება იმისა, თუ როგორ შეგიძლიათ აირჩიოთ ოპტიმალური პარამეტრები სარეზერვო ასლების მისაღებად.

გახსოვდეთ, რომ ყველაფერი, რასაც აკეთებთ, კეთდება თქვენი საფრთხისა და რისკის ქვეშ. შეამოწმეთ თქვენი სარეზერვო ასლები და არ დაივიწყოთ DBCC CHECKDB.

წყარო: www.habr.com