🥇MS SQL سرور: سٹیرائڈز پر بیک اپ

رکو! رکو! سچ ہے، یہ SQL سرور بیک اپ کی اقسام کے بارے میں کوئی دوسرا مضمون نہیں ہے۔ میں ریکوری ماڈلز کے درمیان فرق اور زیادہ بڑھے ہوئے لاگ سے نمٹنے کے طریقہ کے بارے میں بھی بات نہیں کروں گا۔

شاید (صرف شاید)، اس پوسٹ کو پڑھنے کے بعد، آپ اس بات کو یقینی بنانے کے قابل ہو جائیں گے کہ معیاری ذرائع کا استعمال کرتے ہوئے آپ سے جو بیک اپ ہٹایا گیا ہے، وہ کل رات، ٹھیک ہے، 1.5 گنا زیادہ تیزی سے ہٹا دیا جائے گا۔ اور صرف اس حقیقت کی وجہ سے کہ آپ کچھ زیادہ بیک اپ ڈیٹا بیس پیرامیٹرز استعمال کرتے ہیں۔

اگر پوسٹ کا مواد آپ کے لیے واضح تھا، تو میں معذرت خواہ ہوں۔ میں نے وہ سب کچھ پڑھا جو گوگل کو "habr sql server backup" کے فقرے کے لیے ملا، اور مجھے کسی ایک مضمون میں بھی اس حقیقت کا کوئی ذکر نہیں ملا کہ بیک اپ کے وقت کو پیرامیٹرز کے استعمال سے کسی طرح متاثر کیا جا سکتا ہے۔

میں فوری طور پر آپ کی توجہ الیگزینڈر گلاڈچینکو کے تبصرے کی طرف مبذول کروں گا (@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۔ ایم ایس ڈی این کی طرف سے ان کی تفصیل یہ ہیں:

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 } ایس کیو ایل سرور اور بیک اپ سیٹ میڈیا کے درمیان تبادلہ کرنے کے لیے بائٹس میں ڈیٹا پیکٹ کا سب سے بڑا سائز بتاتا ہے۔ 65 بائٹس (536 MB) تک 64 بائٹس (4 KB) کے ملٹیلز سپورٹ ہیں۔

میں قسم کھاتا ہوں - میں نے اسے پہلے بھی پڑھا ہے، لیکن یہ کبھی میرے ذہن میں نہیں آیا کہ وہ پیداواری صلاحیت پر کتنا اثر ڈال سکتے ہیں۔ مزید برآں، بظاہر، مجھے ایک قسم کا "باہر آنے" اور یہ تسلیم کرنے کی ضرورت ہے کہ اب بھی میں پوری طرح سے سمجھ نہیں پا رہا ہوں کہ وہ کیا کر رہے ہیں۔ مجھے شاید بفرڈ 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
);

اسکرپٹ کا اصول آسان ہے - نیسٹڈ لوپس، جن میں سے ہر ایک پیرامیٹر کی قدر کو تبدیل کرتا ہے، ان پیرامیٹرز کو 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 ہے، میں نے 1024 - 512 - 1024 - 2048 لیا۔

یہ 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' کے لیے 2 صفحات پر کارروائی کی گئی، فائل 1 پر فائل 'bt_log'۔

بیک اپ ڈیٹا بیس نے 1070074 سیکنڈ (53.171 MB/sec) میں 157.227 صفحات پر کامیابی سے کارروائی کی۔

اسکرپٹ نے خود، پیرامیٹرز کی جانچ کرتے ہوئے، چند گھنٹوں میں کام کیا، تمام پیمائشیں موجود تھیں۔ گوگل سپریڈ شیٹ. اور یہاں تین بہترین عملدرآمد کے اوقات کے ساتھ نتائج کا انتخاب ہے (میں نے ایک اچھا گراف بنانے کی کوشش کی، لیکن پوسٹ میں مجھے ایک ٹیبل کے ساتھ کرنا پڑے گا، اور تبصروں میں @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 کی تبصرہ:

ہم اعتماد سے کہہ سکتے ہیں کہ اقدار کی ان حدود میں پیرامیٹرز اور بیک اپ کی رفتار کے درمیان تعلق بے ترتیب ہے، کوئی نمونہ نہیں ہے۔ لیکن بلٹ ان پیرامیٹرز سے ہٹنے سے ظاہر ہے کہ نتیجہ پر اچھا اثر پڑا

وہ. صرف معیاری بیک اپ پیرامیٹرز کا انتظام کرنے سے بیک اپ ہٹانے کے وقت میں 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 MB/sec) میں 205.141 صفحات پر کامیابی سے کارروائی کی۔

اب میں تبدیل شدہ BLOCKSIZE، BUFFERCOUNT اور MAXTRANSFERSIZE کے ساتھ لیے گئے بیک اپ کو بحال کرنے کی کوشش کروں گا۔

BLOCKSIZE = 16384, BUFFERCOUNT = 224, MAXTRANSFERSIZE = 4194304

ریسٹور ڈیٹا بیس نے 1070074 سیکنڈ (32.283 MB/sec) میں 258.958 صفحات پر کامیابی سے کارروائی کی۔

BLOCKSIZE = 4096, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 4194304

ریسٹور ڈیٹا بیس نے 1070074 سیکنڈ (32.682 MB/sec) میں 255.796 صفحات پر کامیابی سے کارروائی کی۔

BLOCKSIZE = 16384, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 2097152

ریسٹور ڈیٹا بیس نے 1070074 سیکنڈ (32.091 MB/sec) میں 260.507 صفحات پر کامیابی سے کارروائی کی۔

BLOCKSIZE = 4096, BUFFERCOUNT = 56, MAXTRANSFERSIZE = 4194304

ریسٹور ڈیٹا بیس نے 1070074 سیکنڈ (32.401 MB/sec) میں 258.015 صفحات پر کامیابی سے کارروائی کی۔

ریسٹور ڈیٹا بیس کا بیان ریکوری کے دوران تبدیل نہیں ہوتا؛ یہ پیرامیٹرز اس میں بیان نہیں کیے گئے؛ ایس کیو ایل سرور خود بیک اپ سے ان کا تعین کرتا ہے۔ اور یہ واضح ہے کہ صحت یابی کے ساتھ بھی فائدہ ہو سکتا ہے - تقریباً 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' کے لیے 2 صفحات پر کارروائی کی گئیفائل 1 پر لاگ ان کریں۔

بیک اپ ڈیٹا بیس نے 1070074 سیکنڈ (40.092 MB/sec) میں 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/sec) میں 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/sec) میں 219.842 صفحات پر کامیابی سے کارروائی کی۔

تھوڑا تیز، لیکن کہیں قریب، اہم نہیں۔ عام طور پر، بیک اپ تیزی سے ہٹا دیا جاتا ہے اور اسی طرح بحال کیا جاتا ہے - کامیابی؟ میرے لئے، یہ کافی کامیابی ہے. یہ اہم ہے، تو میں دہراتا ہوں - اگر آپ اگر آپ ان فائلوں میں سے کم از کم ایک کھو دیتے ہیں، تو آپ پورا بیک اپ کھو دیتے ہیں۔.

اگر آپ ٹریس فلیگس 3213 اور 3605 کا استعمال کرتے ہوئے دکھائے جانے والے بیک اپ کی معلومات کے لاگ میں دیکھیں گے، تو آپ دیکھیں گے کہ جب کئی ڈیوائسز کا بیک اپ لیا جاتا ہے تو کم از کم BUFFERCOUNT کی تعداد بڑھ جاتی ہے۔ شاید، آپ BUFFERCOUNT، BLOCKSIZE، MAXTRANSFERSIZE کے لیے زیادہ سے زیادہ بہترین پیرامیٹرز کو منتخب کرنے کی کوشش کر سکتے ہیں، لیکن میں ابھی کامیاب نہیں ہوا، اور میں اس طرح کی جانچ دوبارہ کرنے میں بہت سست تھا، لیکن فائلوں کی ایک مختلف تعداد کے لیے۔ اور یہ پہیوں کے بارے میں شرم کی بات ہے۔ اگر آپ گھر پر اس طرح کی جانچ کو منظم کرنا چاہتے ہیں، تو اسکرپٹ کو دوبارہ بنانا مشکل نہیں ہے۔

آخر میں، قیمت کے بارے میں بات کرتے ہیں. اگر بیک اپ کو صارفین کے کام کے متوازی طور پر ہٹا دیا جاتا ہے، تو آپ کو جانچ کے لیے بہت ذمہ دارانہ انداز اختیار کرنے کی ضرورت ہے، کیونکہ اگر بیک اپ کو تیزی سے ہٹایا جاتا ہے، تو ڈسکیں زیادہ تناؤ کا شکار ہو جاتی ہیں، پروسیسر پر بوجھ بڑھ جاتا ہے (آپ کو پھر بھی کمپریس کرنا پڑتا ہے۔ یہ مکھی پر)، اور اس کے مطابق، نظام کی مجموعی ردعمل کم ہو جاتی ہے۔

صرف مذاق کر رہا ہوں، لیکن میں اچھی طرح سمجھتا ہوں کہ میں نے کوئی انکشاف نہیں کیا۔ اوپر جو کچھ لکھا گیا ہے وہ صرف اس بات کا مظاہرہ ہے کہ آپ بیک اپ لینے کے لیے بہترین پیرامیٹرز کا انتخاب کیسے کر سکتے ہیں۔

یاد رکھیں کہ آپ جو کچھ بھی کرتے ہیں وہ آپ کے اپنے خطرے اور خطرے پر ہوتا ہے۔ اپنے بیک اپ کو چیک کریں اور DBCC CHECKDB کے بارے میں مت بھولیں۔

ماخذ: www.habr.com

MS SQL سرور: سٹیرائڈز پر بیک اپ

نیا تبصرہ شامل کریں جواب منسوخ کریں