Хүлээгээрэй! Хүлээгээрэй! Энэ нь SQL серверийн нөөцлөлтийн төрлүүдийн талаархи өөр нийтлэл биш юм. Сэргээх загваруудын ялгаа, хэт ургасан модтой хэрхэн харьцах талаар би ярихгүй.
Магадгүй (магадгүй ч байж магадгүй) энэ нийтлэлийг уншсаны дараа та стандарт хэрэгслээр устгасан нөөцлөлтийг маргааш шөнө, 1.5 дахин хурдан устгах болно гэдэгт итгэлтэй байх болно. Мөн та бага зэрэг илүү НӨӨЦЛӨЛТИЙН ӨГӨГДЛИЙН САНГИЙН параметрүүдийг ашигладагтай холбоотой.
Хэрэв нийтлэлийн агуулга танд ойлгомжтой байсан бол уучлаарай. Би "habr sql server backup" гэсэн хэллэгийн төлөө Google-ийн олж мэдсэн бүх зүйлийг уншсан бөгөөд нэг ч нийтлэлээс нөөцлөх хугацаа нь параметрүүдийг ашиглан ямар нэгэн байдлаар нөлөөлж болох талаар дурдаагүй.
Би тэр даруй Александр Гладченкогийн тайлбарт анхаарлаа хандуулах болно.):
Үйлдвэрлэлд BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE параметрүүдийг хэзээ ч бүү өөрчил. Эдгээр нь зөвхөн ийм нийтлэл бичихэд зориулагдсан байдаг. Практик дээр та санах ойн асуудлаас богино хугацаанд ангижрах болно.
Мэдээжийн хэрэг, хамгийн ухаалаг, онцгой контент нийтлэх нь сайхан байх болно, гэхдээ харамсалтай нь энэ нь тийм биш юм. Энэ сэдэвт зориулагдсан англи хэл болон орос хэл дээрх нийтлэлүүд / нийтлэлүүд байдаг (би тэдгээрийг юу гэж зөв нэрлэхээ мэдэхгүй үргэлж эргэлздэг). Миний тааралдсан зарим нь энд байна: , , .
Тиймээс эхлээд би бага зэрэг хасагдсан НӨӨЦЛӨЛТИЙН синтаксийг хавсаргах болно (Дашрамд хэлэхэд, би НӨӨЦЛӨЛТИЙН ӨГӨГДЛИЙН САНГИЙН талаар дээр бичсэн, гэхдээ энэ бүхэн гүйлгээний бүртгэлийн нөөц болон дифференциал нөөцлөлтийн аль алинд нь хамаатай боловч үр дүн багатай байж магадгүй):
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 = { буферийн тоо | @ буферын_хувьсагч } - Нөөцлөх үйл ажиллагаанд ашиглагдах оролт/гаралтын буферийн нийт тоог тодорхойлно. Та ямар ч эерэг бүхэл тоон утгыг зааж өгч болно, гэхдээ олон тооны буфер нь Sqlservr.exe процесс дахь хэт их виртуал хаягийн зайнаас болж санах ойгүй алдаа үүсгэж болзошгүй.
Буферийн ашигласан нийт зайг дараах томъёогоор тодорхойлно.
BUFFERCOUNT * MAXTRANSFERSIZE.
MAXTRANSFERSIZE = { maxtransfersize | @ maxtransfersize_variable } нь SQL сервер болон нөөцлөлтийн медиа хооронд солилцох хамгийн том өгөгдлийн багцын хэмжээг байтаар тодорхойлдог. 65 байт (536 КБ)-аас 64 байт (4 МБ) хүртэлх олон тооны файлуудыг дэмждэг.
Тангараглая - Би үүнийг өмнө нь уншиж байсан, гэхдээ тэдгээр нь бүтээмжид хэр их нөлөөлнө гэж бодож байгаагүй. Түүгээр ч барахгүй би нэг төрлийн "гарч" гаргаж, яг юу хийж байгааг нь одоо ч бүрэн ойлгохгүй байгаагаа хүлээн зөвшөөрөх хэрэгтэй бололтой. Би буферт оролт гаралт болон хатуу дисктэй ажиллах талаар илүү ихийг унших хэрэгтэй байх. Хэзээ нэгэн цагт би үүнийг хийх болно, гэхдээ одоогоор би эдгээр утгууд нөөцлөлт хийх хурдад хэрхэн нөлөөлж байгааг шалгах скрипт бичиж болно.
Би 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 НӨӨЦЛӨЛТИЙН МЭДЭЭЛЛИЙН САН хэвийн бусаар дуусгавар болж байна.
Мессеж 701, Түвшин 17, Төлөв 123, Мөр 7 Энэ асуулгыг ажиллуулахын тулд нөөцийн санд "өгөгдмөл" системийн санах ой хангалтгүй байна.
Харьцуулахын тулд би эхлээд ямар ч параметр заахгүйгээр нөөцлөлтийг ажиллуулсны үр дүнг харуулах болно:
BACKUP DATABASE [bt]
TO DISK = 'D:SQLServerbackupbt.bak'
WITH COMPRESSION;За, нөөцлөлт ба нөөцлөлт:
'bt' мэдээллийн сан, 1070072-р файлын 'bt' файлд зориулж 1 хуудсыг боловсруулсан.
'bt' мэдээллийн сан, 2-р файлын 'bt_log' файлд зориулж 1 хуудсыг боловсруулсан.
НӨӨЦЛӨЛТИЙН МЭДЭЭЛЛИЙН САН 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-р файлын 'bt' файлд зориулж 1 хуудсыг боловсруулсан.
'bt' мэдээллийн сан, 2-р файлын 'bt_log' файлд зориулж 1 хуудсыг боловсруулсан.
ӨГӨГДЛИЙН САНГ СЭРГЭЭХ 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 МБ/сек) амжилттай боловсруулав.
Сэргээх үед RESTORE DATABASE мэдэгдэл өөрчлөгдөөгүй, эдгээр параметрүүдийг үүн дотор заагаагүй; SQL Server өөрөө тэдгээрийг нөөцлөлтөөс тодорхойлдог. Эдгэрэх үед ч гэсэн ашиг олох боломжтой нь тодорхой байна - бараг 20% хурдан (Үнэнийг хэлэхэд, би сэргээхэд тийм ч их цаг зарцуулаагүй, би хэд хэдэн "хамгийн хурдан" нөөцлөлтийг гүйлгэж, ямар ч муудаагүй эсэхийг шалгасан.).
Ямар ч тохиолдолд эдгээр нь хүн бүрт оновчтой параметр биш гэдгийг тодруулъя. Та зөвхөн туршилт хийх замаар өөртөө оновчтой параметрүүдийг авах боломжтой. Би эдгээр үр дүнг авсан, та өөр үр дүнг авах болно. Гэхдээ та нөөц хуулбаруудаа "тохируулж" чадах бөгөөд тэд илүү хурдан үүсгэж, байршуулах боломжтой гэдгийг та харж байна.
Би бас таны системд тодорхой нюансууд байж болох тул баримт бичгийг бүхэлд нь уншихыг зөвлөж байна.
Нөөцлөлтийн талаар бичиж эхэлснээс хойш би "тохируулгын" параметрээс илүү түгээмэл байдаг өөр нэг "оновчлолын" талаар даруй бичихийг хүсч байна (миний ойлгож байгаагаар үүнийг ядаж зарим нөөцлөх хэрэгслүүд, магадгүй параметрүүдийн хамт ашигладаг. Өмнө нь тайлбарласан), гэхдээ Habré дээр хараахан тайлбарлаагүй байна.
Хэрэв бид баримт бичгийн хоёр дахь мөрийг НӨӨЦЛӨЛТИЙН өгөгдлийн сангаас харвал дараах зүйлийг харна.
TO <backup_device> [ ,...n ]Хэрэв та хэд хэдэн нөөц_төхөөрөмжийг зааж өгвөл юу болно гэж та бодож байна вэ? Синтакс үүнийг зөвшөөрдөг. Маш сонирхолтой зүйл тохиолдох болно - нөөцлөлт нь хэд хэдэн төхөөрөмж дээр "тархагдах" болно. Тэдгээр. "төхөөрөмж" тус бүр нь ашиггүй, нэг нь алдагдсан, нөөцлөлтийг бүхэлд нь алдах болно. Гэхдээ ийм түрхэц нь нөөцлөх хурдад хэрхэн нөлөөлөх вэ?
Нэг хавтсанд зэрэгцэн байрлах хоёр "төхөөрөмж" дээр нөөцлөлт хийхийг оролдъё.
BACKUP DATABASE [bt]
TO
DISK = 'D:SQLServerbackupbt1.bak',
DISK = 'D:SQLServerbackupbt2.bak'
WITH COMPRESSION;Дэлхийн эцгүүд ээ, яагаад үүнийг хийж байна вэ?
'bt' мэдээллийн сан, 1070072-р файлын 'bt' файлд зориулж 1 хуудсыг боловсруулсан.
'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 МБ/сек) амжилттай боловсруулав.
Бага зэрэг хурдан, гэхдээ хаа нэгтээ ойрхон, тийм ч чухал биш. Ерөнхийдөө нөөцлөлтийг илүү хурдан устгаж, ижил аргаар сэргээдэг - амжилт уу? Миний хувьд энэ бол маш амжилттай. Энэ чухал юм, тиймээс би давтан - хэрэв та Хэрэв та эдгээр файлуудын ядаж нэгийг нь алдвал нөөцлөлтийг бүхэлд нь алдана.
Хэрэв та Trace Flags 3213 болон 3605 ашиглан харуулсан нөөц мэдээллийн бүртгэлийг харвал хэд хэдэн төхөөрөмжид нөөцлөх үед ядаж BUFFERCOUNT-ийн тоо нэмэгдэхийг анзаарах болно. Магадгүй та BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE-ийн хувьд илүү оновчтой параметрүүдийг сонгохыг оролдож болох ч би тэр даруй амжилтад хүрээгүй тул би дахин ийм туршилт хийхээс залхуу байсан, гэхдээ өөр тооны файлуудын хувьд. Мөн дугуйны хувьд ичмээр юм. Хэрэв та гэртээ ийм туршилтыг зохион байгуулахыг хүсвэл скриптийг дахин хийх нь тийм ч хэцүү биш юм.
Эцэст нь үнийн талаар ярилцъя. Хэрэв нөөцлөлтийг хэрэглэгчдийн ажилтай зэрэгцүүлэн устгасан бол та туршилтанд маш хариуцлагатай хандах хэрэгтэй, учир нь нөөцлөлтийг хурдан устгавал дискүүд илүү ачаалалтай болж, процессорын ачаалал нэмэгддэг (та шахах шаардлагатай хэвээр байна). энэ нь нисч байна), үүний дагуу системийн ерөнхий хариу үйлдэл буурдаг.
Зүгээр л тоглож байна, гэхдээ би ямар ч илчлэлт хийгээгүй гэдгээ маш сайн ойлгож байна. Дээр бичсэн зүйл бол нөөцлөлт хийх хамгийн оновчтой параметрүүдийг хэрхэн сонгохыг харуулсан жишээ юм.
Таны хийж буй бүх зүйл таны эрсдэл, эрсдэлд ордог гэдгийг санаарай. Нөөцөө шалгаад DBCC CHECKDB-ийн талаар бүү мартаарай.
Эх сурвалж: www.habr.com