MS SQL সার্ভার: স্টেরয়েডগুলিতে ব্যাকআপ

অপেক্ষা করুন! অপেক্ষা করুন! সত্য, এটি SQL সার্ভার ব্যাকআপের ধরন সম্পর্কে অন্য নিবন্ধ নয়। আমি এমনকি পুনরুদ্ধারের মডেলগুলির মধ্যে পার্থক্য এবং কীভাবে একটি অতিবৃদ্ধ লগ মোকাবেলা করতে হবে সে সম্পর্কেও কথা বলব না।

সম্ভবত (শুধু সম্ভবত), এই পোস্টটি পড়ার পরে, আপনি নিশ্চিত করতে সক্ষম হবেন যে স্ট্যান্ডার্ড উপায়গুলি ব্যবহার করে আপনার থেকে যে ব্যাকআপটি সরানো হয়েছে তা আগামীকাল রাতে, ভাল, 1.5 গুণ দ্রুত সরানো হবে। এবং শুধুমাত্র এই কারণে যে আপনি একটু বেশি ব্যাকআপ ডেটাবেস প্যারামিটার ব্যবহার করেন।

পোস্টের বিষয়বস্তু আপনার কাছে সুস্পষ্ট হলে, আমি দুঃখিত। আমি "habr sql সার্ভার ব্যাকআপ" শব্দগুচ্ছের জন্য Google যা পেয়েছি তার সবকিছুই আমি পড়েছি, এবং একটিও নিবন্ধে আমি এই বিষয়টির কোনো উল্লেখ পাইনি যে ব্যাকআপের সময়টি প্যারামিটার ব্যবহার করে কোনোভাবে প্রভাবিত হতে পারে।

আমি অবিলম্বে আলেকজান্ডার গ্ল্যাডচেঙ্কোর মন্তব্যের প্রতি আপনার দৃষ্টি আকর্ষণ করব (@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 পরিদর্শন করেছেন? আপনি কি এক এবং একটি অর্ধ পর্দা জন্য বিকল্প আছে দেখেছেন? আমিও দেখেছি...

আপনি সম্ভবত ইতিমধ্যে বুঝতে পেরেছেন যে আমরা কোডের প্রথম ব্লকে থাকা তিনটি পরামিতি সম্পর্কে কথা বলব - BLOCKSIZE, BUFFERCOUNT এবং MAXTRANSFERSIZE। এখানে MSDN থেকে তাদের বিবরণ আছে:

ব্লক আকার = { ব্লক আকার | @ ব্লকসাইজ_ভেরিয়েবল } - বাইটে শারীরিক ব্লকের আকার নির্দেশ করে। সমর্থিত আকারগুলি হল 512, 1024, 2048, 4096, 8192, 16, 384, এবং 32 বাইট (768 KB)। টেপ ডিভাইসের জন্য ডিফল্ট মান হল 65 এবং অন্যান্য ডিভাইসের জন্য 536। সাধারণত এই প্যারামিটারটি প্রয়োজনীয় নয় কারণ ব্যাকআপ বিবৃতি স্বয়ংক্রিয়ভাবে ডিভাইসের জন্য উপযুক্ত ব্লক আকার নির্বাচন করে। ব্লকের আকার সেট করা স্পষ্টভাবে স্বয়ংক্রিয় ব্লক আকার নির্বাচনকে ওভাররাইড করে।

বাফারকাউন্ট = { বাফার কাউন্ট | @ buffercount_variable } - ব্যাকআপ অপারেশনের জন্য ব্যবহৃত I/O বাফারের মোট সংখ্যা নির্ধারণ করে। আপনি যেকোন ধনাত্মক পূর্ণসংখ্যার মান নির্দিষ্ট করতে পারেন, কিন্তু Sqlservr.exe প্রক্রিয়ায় অত্যধিক ভার্চুয়াল অ্যাড্রেস স্পেসের কারণে প্রচুর সংখ্যক বাফার মেমরির বাইরের ত্রুটির কারণ হতে পারে।

বাফার দ্বারা ব্যবহৃত মোট স্থানের পরিমাণ নিম্নলিখিত সূত্র দ্বারা নির্ধারিত হয়: BUFFERCOUNT * MAXTRANSFERSIZE.

ম্যাক্সট্রান্সফারাইজ = { maxtransfersize | @ maxtransfersize_variable } এসকিউএল সার্ভার এবং ব্যাকআপ সেট মিডিয়ার মধ্যে বিনিময় করার জন্য বাইটে বৃহত্তম ডেটা প্যাকেটের আকার নির্দিষ্ট করে। 65 বাইট (536 MB) পর্যন্ত 64 বাইট (4 KB) এর একাধিক সমর্থিত।

আমি শপথ করি - আমি এটি আগেও পড়েছি, কিন্তু তারা উত্পাদনশীলতার উপর কতটা প্রভাব ফেলতে পারে তা আমার কাছে কখনও আসেনি। তদুপরি, দৃশ্যত, আমাকে এক ধরণের "আউট হওয়া" করতে হবে এবং স্বীকার করতে হবে যে তারা ঠিক কী করছে তা এখনও আমি পুরোপুরি বুঝতে পারছি না। আমার সম্ভবত বাফার করা I/O সম্পর্কে আরও পড়তে হবে এবং একটি হার্ড ড্রাইভের সাথে কাজ করতে হবে। কোনও দিন আমি এটি করব, তবে আপাতত আমি একটি স্ক্রিপ্ট লিখতে পারি যা এই মানগুলি ব্যাকআপ নেওয়ার গতিকে কীভাবে প্রভাবিত করে তা পরীক্ষা করবে।

আমি একটি ছোট ডাটাবেস তৈরি করেছি, প্রায় 10 গিগাবাইট আকারের, এটিকে 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 এমবি/সেকেন্ড) 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 এমবি/সেকেন্ড) 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% দ্রুত (সত্যি কথা বলতে, আমি পুনরুদ্ধারের জন্য খুব বেশি সময় ব্যয় করিনি, আমি বেশ কয়েকটি "দ্রুত" ব্যাকআপের মাধ্যমে দৌড়েছি এবং নিশ্চিত করেছি যে কোনও অবনতি হয়নি).

শুধু ক্ষেত্রে, আমি স্পষ্ট করে দিই যে এগুলি এমন কিছু প্যারামিটার নয় যা সবার জন্য সর্বোত্তম। আপনি শুধুমাত্র পরীক্ষার মাধ্যমে নিজের জন্য সর্বোত্তম পরামিতি পেতে পারেন। আমি এই ফলাফল পেয়েছি, আপনি বিভিন্ন পেতে হবে. কিন্তু আপনি দেখতে পাচ্ছেন যে আপনি আপনার ব্যাকআপগুলিকে "টিউন" করতে পারেন এবং তারা আসলে দ্রুত গঠন এবং স্থাপন করতে পারে।

আমি দৃঢ়ভাবে সুপারিশ করছি যে আপনি ডকুমেন্টেশনটি সম্পূর্ণভাবে পড়বেন, কারণ আপনার সিস্টেমে নির্দিষ্ট সূক্ষ্মতা থাকতে পারে।

যেহেতু আমি ব্যাকআপ সম্পর্কে লিখতে শুরু করেছি, আমি অবিলম্বে আরও একটি "অপ্টিমাইজেশন" সম্পর্কে লিখতে চাই, যা "টিউনিং" প্যারামিটারের চেয়ে বেশি সাধারণ (যতদূর আমি বুঝি, এটি অন্তত কিছু ব্যাকআপ ইউটিলিটি দ্বারা ব্যবহৃত হয়, সম্ভবত প্যারামিটারগুলির সাথে পূর্বে বর্ণিত), কিন্তু এটি এখনও Habré-তেও বর্ণনা করা হয়নি।

আমরা যদি ডকুমেন্টেশনের দ্বিতীয় লাইনটি দেখি, ব্যাকআপ ডেটাবেসের অধীনে, সেখানে আমরা দেখতে পাই:

TO <backup_device> [ ,...n ]

আপনি যদি বেশ কয়েকটি ব্যাকআপ_ডিভাইস নির্দিষ্ট করেন তবে কী ঘটবে বলে আপনি মনে করেন? সিনট্যাক্স এটি অনুমতি দেয়. এবং একটি খুব আকর্ষণীয় জিনিস ঘটবে - ব্যাকআপটি বেশ কয়েকটি ডিভাইসে "প্রসারিত" হবে। সেগুলো. প্রতিটি "ডিভাইস" স্বতন্ত্রভাবে অকেজো হবে, একটি হারিয়ে যাবে, সম্পূর্ণ ব্যাকআপ হারিয়ে যাবে। কিন্তু কিভাবে এই ধরনের smearing ব্যাকআপ গতি প্রভাবিত করবে?

আসুন একই ফোল্ডারে পাশাপাশি অবস্থিত দুটি "ডিভাইস"-এ একটি ব্যাকআপ করার চেষ্টা করি:

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 এমবি/সেকেন্ড) 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, BLOCKSIZE, MAXTRANSFERSIZE-এর জন্য আরও সর্বোত্তম পরামিতি নির্বাচন করার চেষ্টা করতে পারেন, কিন্তু আমি এখনই সফল হইনি, এবং আমি আবার এই ধরনের পরীক্ষা চালানোর জন্য খুব অলস ছিলাম, কিন্তু বিভিন্ন সংখ্যক ফাইলের জন্য। এবং এটি চাকার সম্পর্কে লজ্জাজনক। আপনি যদি বাড়িতে এই জাতীয় পরীক্ষার আয়োজন করতে চান তবে স্ক্রিপ্টটি রিমেক করা কঠিন নয়।

অবশেষে, দাম সম্পর্কে কথা বলা যাক। যদি ব্যাকআপটি ব্যবহারকারীদের কাজের সাথে সমান্তরালভাবে সরানো হয় তবে আপনাকে পরীক্ষার জন্য একটি খুব দায়িত্বশীল পদ্ধতি অবলম্বন করতে হবে, কারণ যদি ব্যাকআপটি দ্রুত সরানো হয় তবে ডিস্কগুলি আরও চাপা পড়ে যায়, প্রসেসরের লোড বৃদ্ধি পায় (আপনাকে এখনও সংকুচিত করতে হবে এটি উড়ে যায়), এবং সেই অনুযায়ী, সিস্টেমের সামগ্রিক প্রতিক্রিয়াশীলতা হ্রাস পায়।

শুধু মজা করছি, কিন্তু আমি পুরোপুরি বুঝতে পারি যে আমি কোন প্রকাশ করিনি। উপরে যা লেখা হয়েছে তা হল ব্যাকআপ নেওয়ার জন্য আপনি কীভাবে সর্বোত্তম পরামিতি নির্বাচন করতে পারেন তার একটি প্রদর্শন।

মনে রাখবেন যে আপনি যা করেন তা আপনার নিজের বিপদ এবং ঝুঁকিতে করা হয়। আপনার ব্যাকআপ পরীক্ষা করুন এবং DBCC CHECKDB সম্পর্কে ভুলবেন না।

উত্স: www.habr.com