🥇MS SQL سرور: BACKUP on steroids

انتظار ڪريو! انتظار ڪريو! سچ، هي ٻيو مضمون ناهي SQL سرور جي بيڪ اپ جي قسمن بابت. مان بحالي جي ماڊل جي وچ ۾ فرق جي باري ۾ به نه ڳالهائيندس ۽ ڪيئن ڊيل ڪرڻ لاءِ هڪ وڏي لاگ سان.

شايد (بس شايد)، هن پوسٽ پڙهڻ کان پوء، توهان کي پڪ ڪرڻ جي قابل هوندو ته بيڪ اپ جيڪو توهان کان هٽايو ويو آهي معياري مطلب استعمال ڪندي، سڀاڻي رات، چڱي طرح، 1.5 ڀيرا تيز ٿي ويندي. ۽ صرف ان حقيقت جي ڪري ته توهان استعمال ڪريو ٿا ٿورڙو وڌيڪ بيڪ اپ ڊيٽابيس پيٽرولر.

جيڪڏهن پوسٽ جو مواد توهان ڏانهن واضح هو، مون کي معاف ڪجو. مون اهو سڀ ڪجهه پڙهيو آهي جيڪو گوگل جي جملي لاءِ حاصل ڪيو ”habr sql سرور بيڪ اپ“، ۽ هڪ به مضمون ۾ مون کي ان حقيقت جو ڪو به ذڪر نه مليو ته بيڪ اپ وقت ڪنهن به طريقي سان پيٽرول استعمال ڪندي متاثر ٿي سگهي ٿو.

مان توهان جو ڌيان فوري طور تي اليگزينڊر Gladchenko جي تبصري ڏانهن ڏيندس (@mssqlhelp):

پيداوار ۾ BUFFERCOUNT، BLOCKSIZE، MAXTRANSFERSIZE پيٽرول ڪڏهن به تبديل نه ڪريو. اهي صرف اهڙا مضمون لکڻ لاءِ ٺاهيا ويا آهن. عملي طور تي، توهان ڪنهن به وقت ۾ ياداشت جي مسئلن کان نجات حاصل ڪندا.

اهو، يقينا، بهترين هوندو هوشيار ۽ پوسٽ خاص مواد، پر، بدقسمتي سان، اهو معاملو ناهي. اتي ٻئي انگريزي ٻولي ۽ روسي ٻولي جا مضمون/ تحريرون آهن (مان هميشه پريشان آهيان ته انهن کي صحيح ڇا چئجي) هن موضوع لاءِ وقف ٿيل آهن. ھتي ڪجھ آھن جيڪي مون کي مليا آھن: ڀيرا, два, ٽي (sql.ru تي).

تنهن ڪري، شروع ڪرڻ سان، مان هڪ ٿورڙي پٽي-ڊائون بيڪ اپ نحو ڳنڍيندس MSDN (انهي سان، مون مٿي لکيو BACKUP DATABASE بابت، پر اهو سڀ ڪجهه ٻنهي ٽرانزيڪشن لاگ بيڪ اپ ۽ فرق واري بيڪ اپ تي لاڳو ٿئي ٿو، پر شايد گهٽ واضح اثر سان):

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، ۽ 65،536 بائيٽ (64 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
);

اسڪرپٽ جو اصول سادو آهي - nested loops، جن مان هر هڪ هڪ پيٽرولر جي قدر کي تبديل ڪري ٿو، انهن پيرا ميٽرز کي 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 سان وڌيڪ ڏکيو هو - اهو ڪنهن به مثبت نمبر ٿي سگهي ٿو، پر لنڪ چوي ٿو BACKUP DATABASE ۾ اهو ڪيئن ڳڻيو ويندو آهي ۽ وڏا قدر ڇو خطرناڪ آهن؟. اهو پڻ چوي ٿو ته ڪيئن ڄاڻ حاصل ڪجي ته ڪهڙي BUFFERCOUNT سان بيڪ اپ اصل ۾ ٺاهيو ويو آهي - منهنجي لاء اهو 7 آهي. ان کي گهٽائڻ ۾ ڪو به مقصد نه هو، ۽ مٿين حد تجرباتي طور تي دريافت ڪيو ويو - BUFFERCOUNT = 896 ۽ MAXTRANSFERSIZE = 4194304 سان گڏ بيڪ اپ ٿي ويو. هڪ غلطي (جنهن بابت مٿي ڏنل لنڪ ۾ لکيل آهي):

Msg 3013, Level 16, State 1, Line 7 BACKUP DATABASE غير معمولي طور تي ختم ٿي رهيو آهي.

Msg 701, Level 17, State 123, Line 7 هن سوال کي هلائڻ لاءِ ريسورس پول 'ڊفالٽ' ۾ ڪافي سسٽم ميموري نه آهي.

مقابلي لاءِ، مان پهريان ڏيکاريندس بيڪ اپ هلائڻ جا نتيجا ڪنهن به پيٽرول جي وضاحت ڪرڻ کان سواءِ:

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

خير، بيڪ اپ ۽ بيڪ اپ:

ڊيٽابيس لاءِ پروسيس ٿيل 1070072 صفحا 'bt'، فائل 'bt' فائل 1 تي.

ڊيٽابيس لاءِ پروسيس ٿيل 2 صفحا 'bt'، فائل 'bt_log' فائل 1 تي.

بيڪ اپ ڊيٽابيس 1070074 سيڪنڊن ۾ 53.171 صفحن تي ڪاميابيءَ سان عمل ڪيو (157.227 MB/sec).

اسڪرپٽ پاڻ، پيٽرولر جي جانچ ڪندي، ڪجهه ڪلاڪن ۾ ڪم ڪيو، سڀ ماپ اندر هئا گوگل اسپريڊ شيٽ. ۽ هتي نتيجن جو هڪ انتخاب آهي ٽن بهترين عمل جي وقتن سان (مون هڪ سٺو گراف ٺاهڻ جي ڪوشش ڪئي، پر پوسٽ ۾ مون کي هڪ ٽيبل سان ڪرڻو پوندو، ۽ تبصرن ۾ @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 تي.

ريسٽور ڊيٽابيس 1070074 سيڪنڊن ۾ 40.752 صفحن تي ڪاميابي سان عمل ڪيو (205.141 MB/sec).

ھاڻي مان ڪوشش ڪندس ته بدليل BLOCKSIZE، BUFFERCOUNT ۽ MAXTRANSFERSIZE سان گڏ ڪيل بيڪ اپ بحال ڪريو.

BLOCKSIZE = 16384, BUFFERCOUNT = 224, MAXTRANSFERSIZE = 4194304

ريسٽور ڊيٽابيس 1070074 سيڪنڊن ۾ 32.283 صفحن تي ڪاميابي سان عمل ڪيو (258.958 MB/sec).

BLOCKSIZE = 4096, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 4194304

ريسٽور ڊيٽابيس 1070074 سيڪنڊن ۾ 32.682 صفحن تي ڪاميابي سان عمل ڪيو (255.796 MB/sec).

BLOCKSIZE = 16384, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 2097152

ريسٽور ڊيٽابيس 1070074 سيڪنڊن ۾ 32.091 صفحن تي ڪاميابي سان عمل ڪيو (260.507 MB/sec).

BLOCKSIZE = 4096, BUFFERCOUNT = 56, MAXTRANSFERSIZE = 4194304

ريسٽور ڊيٽابيس 1070074 سيڪنڊن ۾ 32.401 صفحن تي ڪاميابي سان عمل ڪيو (258.015 MB/sec).

ريسٽور ڊيٽابيس جو بيان بحالي دوران تبديل نٿو ٿئي؛ اهي پيرا ميٽر ان ۾ بيان نه ڪيا ويا آهن؛ SQL سرور پاڻ انهن کي بيڪ اپ مان طئي ڪري ٿو. ۽ اهو واضح آهي ته وصولي سان گڏ هڪ فائدو ٿي سگهي ٿو - تقريبا 20٪ تيز (ايماندار ٿيڻ لاء، مون وصولي تي گهڻو وقت نه گذاريو، مون ڪيترن ئي "تيز ترين" بيڪ اپ ذريعي ڀڄايو ۽ پڪ ڪيو ته ڪا به خرابي نه هئي.).

بس صورت ۾، مون کي واضح ڪرڻ ڏيو ته اهي ڪجهه پيٽرولر نه آهن جيڪي هر ڪنهن لاء بهتر آهن. توھان حاصل ڪري سگھوٿا صرف پنھنجي لاءِ بھترين پيٽرول ٽيسٽ ذريعي. مون کي اهي نتيجا مليا، توهان مختلف حاصل ڪندا. پر توهان ڏسو ٿا ته توهان پنهنجي بيڪ اپ کي "ٽيون" ڪري سگهو ٿا ۽ اهي اصل ۾ ٺاهي سگهن ٿا ۽ تيزيءَ سان ترتيب ڏئي سگهن ٿا.

مان پڻ سختي سان صلاح ڏيان ٿو ته توهان دستاويز کي مڪمل طور تي پڙهو، ڇو ته شايد توهان جي سسٽم لاء مخصوص نونسز هوندا.

جڏهن کان مون بيڪ اپ جي باري ۾ لکڻ شروع ڪيو آهي، مان فوري طور تي هڪ وڌيڪ ”اصلاح“ جي باري ۾ لکڻ چاهيان ٿو، جيڪو ”ٽوننگ“ پيرا ميٽرز کان وڌيڪ عام آهي (جيستائين مان سمجهان ٿو، اهو گهٽ ۾ گهٽ ڪجهه بيڪ اپ يوٽيلٽيز استعمال ڪيو ويندو آهي، شايد ان سان گڏ پيرا ميٽرز اڳ بيان ڪيو ويو آهي)، پر اهو اڃا تائين Habré تي بيان نه ڪيو ويو آهي.

جيڪڏهن اسان دستاويزن ۾ ٻئي لڪير تي نظر رکون ٿا، صحيح طور تي بيڪ اپ ڊيٽابيس جي تحت، اتي اسان ڏسون ٿا:

TO <backup_device> [ ,...n ]

توهان ڇا ٿا سوچيو جيڪڏهن توهان ڪيترن ئي بيڪ اپ_ڊيوائسز جي وضاحت ڪندا؟ نحو ان جي اجازت ڏئي ٿو. ۽ هڪ تمام دلچسپ شيء ٿيندو - بيڪ اپ صرف ڪيترن ئي ڊوائيسز تي "پکڙيل" ٿيندو. اهي. هر ”ڊوائيس“ انفرادي طور تي بيڪار ٿي ويندي، هڪ گم ٿي، سڄو بيڪ اپ وڃائي ويٺي. پر ڪيئن اهڙي smearing بيڪ اپ رفتار متاثر ڪندو؟

اچو ته ٻن "ڊوائيسز" تي بيڪ اپ ڪرڻ جي ڪوشش ڪريو جيڪي ساڳئي فولڊر ۾ پاسي سان واقع آهن:

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

دنيا جا پيءُ، ائين ڇو ڪيو پيو وڃي؟

ڊيٽابيس لاءِ پروسيس ٿيل 1070072 صفحا 'bt'، فائل 'bt' فائل 1 تي.

ڊيٽابيس لاءِ پروسيس ٿيل 2 صفحا 'bt'، فائل 'bt'لاگ ان فائل 1.

بيڪ اپ ڊيٽابيس 1070074 سيڪنڊن ۾ 40.092 صفحن تي ڪاميابيءَ سان عمل ڪيو (208.519 MB/sec).

ڇا بيڪ اپ صرف نيري مان 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 MB/sec).

مجموعي طور تي، بيڪ اپ وٺڻ جي وقت جي باري ۾ 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 MB/sec).

ٿورو تيز، پر ڪٿي ويجهو، اهم نه. عام طور تي، بيڪ اپ تيزيء سان هٽايو ويو آهي ۽ ساڳئي طريقي سان بحال ٿيو - ڪاميابي؟ منهنجي لاءِ، اها ڪافي ڪاميابي آهي. هي ضروري آهي، تنهنڪري مان ورجائي ٿو - جيڪڏهن توهان جيڪڏهن توهان انهن فائلن مان گهٽ ۾ گهٽ هڪ وڃائي ڇڏيو، توهان مڪمل بيڪ اپ وڃائي ڇڏيو.

جيڪڏهن توهان ٽريڪ فليگ 3213 ۽ 3605 استعمال ڪندي ڏيکاريل بيڪ اپ معلومات تي لاگ ان ۾ ڏسو، توهان کي خبر پوندي ته جڏهن ڪيترن ئي ڊوائيسن تي بيڪ اپ ڪيو وڃي ٿو، گهٽ ۾ گهٽ BUFFERCOUNT جو تعداد وڌي ٿو. شايد، توھان ڪوشش ڪري سگھوٿا BUFFERCOUNT، BLOCKSIZE، MAXTRANSFERSIZE لاءِ وڌيڪ بھترين پيٽرول، پر مان ھاڻي ڪامياب نه ٿي سگھيس، ۽ مان وري اھڙي ٽيسٽ ڪرڻ لاءِ ڏاڍو سست ھيس، پر فائلن جي مختلف تعداد لاءِ. ۽ ان جي ڦيٿي لاء افسوس آهي. جيڪڏهن توهان گهر ۾ اهڙي جاچ کي منظم ڪرڻ چاهيو ٿا، اهو اسڪرپٽ کي ٻيهر ٺاهڻ ڏکيو ناهي.

آخرڪار، اچو ته قيمت بابت ڳالهايو. جيڪڏهن بيڪ اپ استعمال ڪندڙن جي ڪم سان متوازي طور تي هٽايو ويو آهي، توهان کي جانچ ڪرڻ لاء تمام ذميوار طريقي سان وٺڻ جي ضرورت آهي، ڇاڪاڻ ته جيڪڏهن بيڪ اپ تيزيء سان هٽايو ويندو آهي، ڊسڪ وڌيڪ دٻايو ويندو آهي، پروسيسر تي لوڊ وڌندو آهي (توهان کي اڃا تائين دٻائڻو پوندو. اهو اڏامي تي)، ۽ ان جي مطابق، سسٽم جي مجموعي ردعمل گھٽائي ٿي.

بس مذاق، پر مان چڱيءَ طرح سمجهان ٿو ته مون ڪو به وحي نه ڪيو آهي. جيڪو مٿي لکيو ويو آهي اهو صرف هڪ مظاهرو آهي ته توهان بيڪ اپ وٺڻ لاءِ بهترين پيٽرولر ڪيئن چونڊي سگهو ٿا.

ياد رکو ته جيڪو ڪجهه توهان ڪندا آهيو اهو توهان جي پنهنجي خطري ۽ خطري تي ڪيو ويندو آهي. پنھنجا بيڪ اپ چيڪ ڪريو ۽ DBCC CHECKDB بابت نه وساريو.

جو ذريعو: www.habr.com

MS SQL سرور: بيڪ اپ اسٽيرائڊس تي

تبصرو شامل ڪريو جواب منسوخ