ProHoster > بلاګ > اداره > د MS SQL سرور: په سټرایډونو کې بیک اپ

د MS SQL سرور: په سټرایډونو کې بیک اپ

صبر وکړه! صبر وکړه! ریښتیا، دا د SQL سرور بیک اپ ډولونو په اړه بله مقاله نه ده. زه به حتی د بیا رغونې موډلونو او د لوی شوي لاګ سره څنګه معامله کولو تر مینځ د توپیرونو په اړه وغږیږم.

شاید (یوازې شاید) ، د دې پوسټ لوستلو وروسته ، تاسو به وکولی شئ ډاډ ترلاسه کړئ چې هغه بیک اپ چې ستاسو څخه د معیاري وسیلو په کارولو سره لرې شوی وي به سبا شپه لرې شي ، ښه ، 1.5 ځله ګړندی. او یوازې د دې حقیقت له امله چې تاسو یو څه ډیر د بیک اپ ډیټابیس پیرامیټونه کاروئ.

که د پوسټ مینځپانګه تاسو ته څرګنده وه ، زه بخښنه غواړم. ما هر هغه څه ولوستل چې ګوګل د "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 bytes (768 KB) دي. ډیفالټ ارزښت د ټیپ وسیلو لپاره 65 او د نورو وسیلو لپاره 536 دی. معمولا دا پیرامیټر اړین ندي ځکه چې د بیک اپ بیان په اوتومات ډول د آلې لپاره مناسب بلاک اندازه غوره کوي. د بلاک اندازې تنظیم کول په ښکاره ډول د اتوماتیک بلاک اندازې انتخاب له پامه غورځوي.

BUFFERCOUNT = { بفر شمیره | @ buffercount_variable } - د I/O بفرونو ټولیز شمیر تعریفوي چې د بیک اپ عملیاتو لپاره به کارول کیږي. تاسو کولی شئ کوم مثبت انټیجر ارزښت مشخص کړئ ، مګر د بفرونو لوی شمیر ممکن د Sqlservr.exe پروسې کې د ډیر مجازی پته ځای له امله د حافظې څخه بهر غلطی رامینځته کړي.

د بفرونو لخوا کارول شوي ټول ځای د لاندې فورمول لخوا ټاکل کیږي: BUFFERCOUNT * MAXTRANSFERSIZE.

MAXTRANSFERSIZE = { 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
);

د سکریپټ اصول ساده دي - نیسټ شوي لوپونه، چې هر یو یې د یو پیرامیټر ارزښت بدلوي، دا پیرامیټونه د 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 د دې پوښتنې د چلولو لپاره د سرچینې پول 'default' کې کافي سیسټم حافظه شتون نلري.

د پرتله کولو لپاره ، زه به لومړی د بیک اپ چلولو پایلې وښیم پرته لدې چې هیڅ پیرامیټر مشخص کړي:

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

ښه، بیک اپ او بیک اپ:

د ډیټابیس 'bt' لپاره 1070072 پاڼې پروسس شوي، په 1 فایل کې 'bt' فایل.

د ډیټابیس 'bt' لپاره 2 پاڼې پروسس شوي، په فایل 1 کې د 'bt_log' فایل.

بیک اپ ډیټابیس په بریالیتوب سره 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;

د MS SQL سرور: په سټرایډونو کې بیک اپ

پاملرنه، یو ډیر مهم یادونه @mixsture د تبصره:

موږ کولی شو په ډاډ سره ووایو چې د دې ارزښتونو سلسله کې د پیرامیټونو او بیک اپ سرعت تر مینځ اړیکه تصادفي ده ، هیڅ نمونه شتون نلري. مګر د جوړ شوي پیرامیټونو څخه لیرې کول په څرګنده توګه په پایله کې ښه اغیزه درلوده

هغوی. یوازې د معیاري بیک اپ پیرامیټونو اداره کولو سره د بیک اپ لرې کولو وخت کې دوه چنده ګټه وه: 2 ثانیې ، په پیل کې د 26 په پرتله. دا بد نه دی، سمه ده؟ مګر موږ باید وګورو چې د بیا رغونې سره څه پیښیږي. څه که چیرې اوس د رغیدو لپاره 53 ځله نور وخت ونیسي؟

لومړی، راځئ چې اندازه وکړو چې د ډیفالټ ترتیباتو سره د بیک اپ بحالولو لپاره څومره وخت نیسي:

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 MB/sec).

اوس زه به هڅه وکړم چې د بدل شوي بلاکسائز، بفرکاونټ او 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٪ ګړندی (د ریښتیني کیدو لپاره ، ما په رغیدو کې ډیر وخت نه دی لګولی ، ما د ډیری "ګړندی" بیک اپونو څخه تیر کړ او ډاډ یې ورکړ چې هیڅ خرابی نشته).

یوازې په قضیه کې، اجازه راکړئ روښانه کړم چې دا ځینې پیرامیټونه ندي چې د هرچا لپاره غوره دي. تاسو کولی شئ یوازې د ازموینې له لارې د ځان لپاره غوره پیرامیټونه ترلاسه کړئ. ما دا پایلې ترلاسه کړې، تاسو به مختلف ترلاسه کړئ. مګر تاسو ګورئ چې تاسو کولی شئ خپل بیک اپ "ټیون" کړئ او دوی واقعیا کولی شي ګړندي جوړ او ځای په ځای کړي.

زه دا هم په کلکه وړاندیز کوم چې تاسو اسناد په بشپړ ډول ولولئ ، ځکه چې ممکن ستاسو سیسټم ته ځانګړي لنډیزونه شتون ولري.

له هغه وخته چې ما د بیک اپ په اړه لیکل پیل کړل، زه غواړم سمدلاسه د یو بل "اصلاح" په اړه ولیکم، کوم چې د "ټیوننګ" پیرامیټونو څخه ډیر عام دی (تر هغه ځایه چې زه پوهیږم، دا لږترلږه د ځینې بیک اپ اسانتیاوو لخوا کارول کیږي، شاید د پیرامیټونو سره یوځای مخکې تشریح شوی)، مګر دا لا تر اوسه په هابری کې هم نه دی بیان شوی.

که موږ په اسنادو کې دویمه کرښه وګورو، د بیک اپ ډیټابیس لاندې، هلته موږ ګورو:

TO <backup_device> [ ,...n ]

تاسو څه فکر کوئ که چیرې تاسو څو بیک اپ_وایلونه مشخص کړئ نو څه به پیښ شي؟ ترکیب دې ته اجازه ورکوي. او یو ډیر په زړه پوری شی به پیښ شي - بیک اپ به په ساده ډول په ډیری وسیلو کې "پراخه" وي. هغوی. هر "وسیله" به په انفرادي ډول بې ګټې وي، یو له لاسه ورکړي، ټول بیک اپ له لاسه ورکړي. مګر دا ډول بوی به څنګه د بیک اپ سرعت اغیزه وکړي؟

راځئ هڅه وکړو چې په دوه "وسیلو" کې بیک اپ جوړ کړو چې په ورته فولډر کې څنګ په څنګ موقعیت لري:

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

د نړۍ پلرونو، دا ولې کیږي؟

د ډیټابیس 'bt' لپاره 1070072 پاڼې پروسس شوي، په 1 فایل کې 'bt' فایل.

د ډیټابیس 'bt' لپاره پروسس شوي 2 پاڼې، فایل '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).

یو څه ګړندی ، مګر په کوم ځای کې نږدې ، مهم ندی. په عموم کې، بیک اپ په چټکۍ سره لیرې شوی او په ورته ډول بیرته راستانه شوی - بریالیتوب؟ زما لپاره، دا خورا بریالیتوب دی. دا مهم دی، نو زه تکراروم - که تاسو که تاسو لږترلږه یو له دې فایلونو څخه له لاسه ورکړئ، تاسو ټول بیک اپ له لاسه ورکوئ.

که تاسو د Trace Flags 3213 او 3605 په کارولو سره ښودل شوي د بیک اپ معلوماتو په لاګ کې وګورئ ، نو تاسو به وګورئ چې کله چې ډیری وسیلو ته بیک اپ کول ، لږترلږه د BUFFERCOUNT شمیر ډیریږي. شاید، تاسو هڅه کولی شئ د BUFFERCOUNT، BLOCKSIZE، MAXTRANSFERSIZE لپاره نور غوره پیرامیټونه وټاکئ، مګر زه سمدلاسه بریالی نه شوم، او زه ډیر سست وم چې دا ډول ازموینې بیا ترسره کړم، مګر د مختلف فایلونو لپاره. او دا د ویلو په اړه د شرم خبره ده. که تاسو غواړئ دا ډول ازموینې په کور کې تنظیم کړئ ، نو د سکریپټ بیا جوړ کول ستونزمن ندي.

په نهایت کې ، راځئ چې د نرخ په اړه وغږیږو. که بیک اپ د کاروونکو کار سره موازي لرې شي ، نو تاسو اړتیا لرئ د ازموینې لپاره خورا مسؤل چلند وکړئ ، ځکه چې که بیک اپ ګړندی لرې شي ، ډیسکونه ډیر فشار لري ، په پروسیسر باندې بار ډیریږي (تاسو لاهم باید فشار ولرئ. دا په الوتنه کې)، او په دې اساس، د سیسټم عمومي غبرګون کمیږي.

یوازې ټوکې کول، مګر زه په بشپړ ډول پوهیږم چې ما هیڅ ښکاره نه دی کړی. هغه څه چې پورته لیکل شوي په ساده ډول یوه مظاهره ده چې تاسو څنګه کولی شئ د بیک اپ اخیستلو لپاره غوره پیرامیټونه غوره کړئ.

په یاد ولرئ چې هرڅه چې تاسو یې کوئ ستاسو په خطر او خطر کې ترسره کیږي. خپل بیک اپ چیک کړئ او د DBCC CHECKDB په اړه مه هیروئ.

سرچینه: www.habr.com

Add a comment