DBCC CHECKDB: MS SQL Server Өгөгдлийн сангийн эрүүл мэндийн гарын авлага

DBCC CHECKDB нь SQL Serverөгөгдлийн сангийн бүрэн бүтэн байдлын үндсэн хэрэгсэл. Үүнийг хэрхэн жишээн дээр ашиглах, авлигыг засах, гүйцэтгэлийг оновчтой болгох талаар суралц.

1. -ийн ач холбогдол SQL Server Өгөгдлийн сангийн эрүүл мэнд

1.1 Ямар мэдээллийн сангийн авлига Вosts Бизнесүүд

Өнөөдөр Мost аж ахуйн нэгжүүд өөрсдийн чухал мэдээллээ мэдээллийн санд хадгалдаг. Өгөгдлийн сангийн эвдрэл гарсан тохиолдолд үр дагавар нь сүйрлийн шинж чанартай байдаг:

Санхүүгийн алдагдал Мэдээллийн алдагдлаас болж жилд дунджаар 2.3 сая доллар, техник хангамжийн доголдол, авлига гол шалтгаан болдог (EMC Corporation)
Бизнесийн хаалтын хувь хэмжээ Техник хангамжийн доголдлоос болж өгөгдөл алддаг жижиг бизнесүүдийн 50% нь хоёр жилийн дотор үйл ажиллагаагаа зогсоодог бол гамшигт мэдээлэл алдсан бизнесүүдийн 94% нь огт оршин тогтнож чадахгүй байгааг харуулж байна.
Өгөгдлийн эвдрэлийн давтамж Энэ нь жил бүр чухал ач холбогдолтой програмуудын 20% -д нөлөөлж, бизнесийн тасралтгүй ажиллагаанд саад учруулдаг (Gartner судалгаа)
Техник хангамжтай холбоотой авлига Хатуу дискний эвдрэл, системийн доголдлоос үүдэлтэй нийт өгөгдөл алдагдах тохиолдлын 67%-ийг эзэлж байгаа бөгөөд өгөгдлийн алдагдлын 40%-ийг техник хангамжийн эвдрэлээс шууд шалтгаалдаг.
Програм хангамжийн эвдрэл costs ноцтой байдал, хамрах хүрээнээс хамааран хэдэн мянгаас сая доллар хүртэл хэлбэлздэг бөгөөд аж ахуйн нэгжүүдийн 82% нь авлига гол шалтгаан болсон төлөвлөгдөөгүй тасалдалтай тулгардаг.

1.2 Эрүүл мэндийн тогтмол үзлэг яагаад чухал байдаг вэ?

Хүмүүс болзошгүй өвчнийг эрт илрүүлэхийн тулд эрүүл мэндийн үзлэгт тогтмол хамрагдах шаардлагатай байдаг. Үүний нэгэн адил мэдээллийн сан нь эрүүл мэндийн үзлэгт тогтмол хамрагдах шаардлагатай.

Болзошгүй авлигыг эрт илрүүлж, цаг алдалгүй шийдвэрлэснээр бизнест гамшигт үр дагаварт хүргэж болзошгүй асуудал хүндэрч, өргөн тархахаас сэргийлнэ.
Өгөгдлийн сангийн оновчтой гүйцэтгэлийг хангах.
Вost Өгөгдлийн сангийн эрүүл мэндийг шалгах нь мэдээллийн сангийн гамшгийн дараа реактив өгөгдлийг сэргээхээс хамаагүй бага байна.

1.3 Өгөгдлийн сангийн бүрэн бүтэн байдлын командуудын танилцуулга

SQL Server өгөгдлийн сангийн эрүүл мэндийг хадгалах хэд хэдэн суурилуулсан тушаалуудыг өгдөг DBCC CHECKDB м-ээр үйлчилж байнаost бүрэн бүтэн байдлыг шалгах иж бүрэн хэрэгсэл боломжтой. Эдгээр командууд нь өгөгдлийн сангийн бүтцийн өөр өөр талуудыг шалгахын тулд хамтран ажиллаж, нэг хүснэгтээс эхлээд өгөгдлийн сангийн бүхэл бүтэн тогтвортой байдлыг хангаж, таны өгөгдлийг аюулгүй, хүртээмжтэй байлгах бүрэн засвар үйлчилгээний стратегийг бүрдүүлдэг.

2. DBCC CHECKDB гэж юу вэ

DBCC CHECKDB is SQL Serverөгөгдлийн сангийн бүрэн бүтэн байдлыг шалгах, авлигын асуудлыг илрүүлэх үндсэн хэрэгсэл юм.

Энэ нь GUI хэрэгсэл биш T-SQL мэдэгдэл юм.
Та үүнийг нийтлэг аргуудаар гүйцэтгэж болно, жишээ нь SQL Server Менежментийн студи (SSMS), SQL Server Агент, SQLCMD гэх мэт.

2.1 CHECKDB таны мэдээллийн санд яг юуг шалгадаг вэ

Таныг DBCC CHECKDB ажиллуулах үед тушаал нь таны мэдээллийн сангийн бүтцэд олон баталгаажуулалтын давхаргыг гүйцэтгэдэг:

Хуудасны шалгах нийлбэр баталгаажуулалт физик авлига, техник хангамжтай холбоотой асуудлыг илрүүлэх
Индекс тууштай байдлыг баталгаажуулах зөв мэдээлэл олж авах, асуулгын гүйцэтгэлийг хангах
Хуваарилалтын бүтцийг шалгах үнэн зөв зай ашиглалт, хуудасны хуваарилалтыг баталгаажуулах
Лавлагааны бүрэн бүтэн байдлын шалгалт холбогдох хүснэгтүүд болон гадаад түлхүүр харилцааны хооронд
Системийн хүснэгтийн нийцлийн баталгаажуулалт батлах SQL Server-ийн дотоод мета өгөгдөл найдвартай хэвээр байна
Өгөгдлийн хуудасны холболтын баталгаажуулалт хуудасны сүлжээний бүрэн бүтэн байдлыг баталгаажуулах
Өгөгдлийн сангийн схемийн тууштай байдал объектын тодорхойлолт, хамаарлыг баталгаажуулах

Эдгээр иж бүрэн шалгалтууд нь хэрэглэгчийн өгөгдөл болон системийн бүтцийг хоёуланг нь хамарч, таны мэдээллийн сангийн эрүүл мэндийн байдлыг бүрэн харуулах боломжийг олгодог.

3. DBCC CHECKDB-г ажиллуулж байна: Алхам алхмаар

3.1 Урьдчилсан нөхцөл

DBCC CHECKDB үйлдлийг гүйцэтгэхийн өмнөх хяналтын хуудсыг доор харуулав.

Өгөгдлийн сангийн бүрэн нөөцлөлт – Авлига илэрсэн эсвэл засвар хийх шаардлагатай бол аюулгүй байдлын сүлжээгээ шалгахын өмнө бүрэн нөөцлөлт үүсгэнэ үү.
Зөв зөвшөөрөл – DBCC CHECKDB командуудыг гүйцэтгэхийн тулд танд sysadmin эсвэл db_owner зөвшөөрөл хэрэгтэй
Системийн хангалттай нөөц:
- Санах ой: Өгөгдлийн сангийн хэмжээ 25%
- Tempdb зай: Өгөгдлийн сангийн 10-15%
- CPU: Засвар үйлчилгээний үед 50-70% бэлэн байна
- I/O: Хүнд унших үйлдлүүд хүлээж байна
Өгөгдлийн сангийн хүртээмж – CHECKDB нь мэдээллийн сангийн бүх хуудсанд унших хандалтыг шаарддаг тул таны мэдээллийн санд хандах боломжтой бөгөөд хязгаарлагдмал төлөвт байгаа эсэхийг шалгаарай.

3.2 Үндсэн тушаал

Most DBCC CHECKDB үндсэн тушаал нь гурван нийтлэг хувилбарыг агуулдаг:

(1) Одоогийн мэдээллийн санг шалгана уу (параметр байхгүй):

DBCC CHECKDB

(2) Мэдээллийн санг нэрээр нь шалгана уу:

DBCC CHECKDB ('YourDatabaseName')

(3) Өгөгдлийн санг ID-аар шалгана уу:

DBCC CHECKDB(5)  -- Replace 5 with your database ID

Энэхүү үндсэн команд нь заасан мэдээллийн сангийн бүрэн бүтэн байдлыг шалгаж, бүх хүснэгт, индекс, системийн бүтцийг шалгадаг. Хоосон зайгүй стандарт нэртэй мэдээллийн сангийн хувьд та ишлэлийг орхиж болно. Энэ тушаал дуусах хүртэл ажиллах бөгөөд явцын мэдээ болон эцсийн үр дүнг харуулна. Энэхүү үндсэн синтакс нь жижиг өгөгдлийн сангийн хувьд эсвэл танд хангалттай засвар үйлчилгээ хийх боломжтой үед төгс ажилладаг.

DBCC CHECKDB-г ажиллуулж байгаа дэлгэцийн агшинг доор харуулав SQL Server Менежментийн студи (SSMS):

3.3 Бүрэн сонголтууд

DBCC CHECKDB-ийн бүрэн сонголтуудыг доор харуулав.

Ангилал	сонголт	Тодорхойлолт	DBCC CHECKDB жишээ
Засварлах сонголтууд	`REPAIR_REBUILD`	Өгөгдлийн алдагдалгүйгээр засвар хийх (жишээ нь, индексийг дахин бүтээх)	`DBCC CHECKDB ('MyDB', REPAIR_REBUILD)`
	`REPAIR_FAST`	Засваргүй. Зөвхөн хойшоо нийцтэй	`DBCC CHECKDB ('MyDB', REPAIR_FAST)`
	`REPAIR_ALLOW_DATA_LOSS`	Бүх алдааг засдаг (өгөгдлийн алдагдалд хүргэж болзошгүй)	`DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)`
Хамрах хүрээний хяналт	`NOINDEX`	Бүлэггүй индексийн шалгалтыг алгасах	`DBCC CHECKDB ('LargeDB', NOINDEX)`
	`PHYSICAL_ONLY`	Зөвхөн физик хадгалах сангийн бүрэн бүтэн байдлыг шалгана (хуудас/бичлэг)	`DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)`
	`DATA_PURITY`	Логик баганын утгын алдааг шалгана (жишээ нь, хүчингүй огноо)	`DBCC CHECKDB ('OldDB', DATA_PURITY)`
	`EXTENDED_LOGICAL_CHECKS`	Гүн логик шалгалт (индексжүүлсэн харагдац, XML/орон зайн индекс)	`DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)`
Гаралтын хяналт	`ALL_ERRORMSGS`	Бүх алдааг харуулна (өгөгдмөл: объект бүрт 200)	`DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)`
Гаралтын хяналт	`NO_INFOMSGS`	Мэдээллийн мессежийг нууна	`DBCC CHECKDB ('MyDB', NO_INFOMSGS)`
Гүйцэтгэлийн	`TABLOCK`	Хүснэгтийн түгжээг ашигладаг (TempDB хэрэглээг багасгадаг боловч бичихийг блоклодог)	`DBCC CHECKDB ('BigDB', TABLOCK)`
Гүйцэтгэлийн	`MAXDOP = number`	Зэрэгцээ байдлын тохиргоог дарна	`DBCC CHECKDB ('MyDB', MAXDOP = 2)`
Хэрэгсэл	`ESTIMATEONLY`	Шаардлагатай TempDB зайг тооцоолно. (бодит шалгалт байхгүй)	`DBCC CHECKDB ('MyDB', ESTIMATEONLY)`

4. Үр дүнгээ ойлгох

DBCC CHECKDB нь гүйцэтгэл нь амжилттай дууссан эсэхээс хамаарч өөр өөр үр дүн гаргах болно. Тэдгээрийг нарийвчлан тайлбарлая.

4.1 CHECKDB гүйцэтгэл амжилттай дууслаа

Хэрэв DBCC CHECKDB гүйцэтгэл амжилттай болвол энэ нь таны мэдээллийн сангийн эрүүл мэндийн байдлаас хамааран өөр өөр төрлийн үр дүнг мэдээлэх болно.

4.1.1 Асуудал олдсонгүй

Хэрэв DBCC CHECKDB ямар ч асуудал олоогүй бол та дараахтай төстэй гаралтыг харах болно.

CHECKDB found 0 allocation errors and 0 consistency errors in database 'YourDatabase'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Энэ үр дүн нь таны мэдээллийн сан шалгагдсан бүх бүтцэд бүрэн бүтэн байдлыг хадгалж байгааг харуулж байна.

4.1.2 Авлигын алдаа илэрсэн

DBCC CHECKDB нь авлигын алдаа илрүүлэх бүрд дараах бүтэцтэй алдааны мэдэгдлийг мэдээлэх болно.
Хүнд байдлын түвшний гарын авлага:

Түвшин 16-19: Хэрэглэгчийн засч залруулж болох алдаа, ихэвчлэн бага зэргийн эвдрэл
Түвшин 20-24: Системийн алдаа, нэн даруй анхаарал хандуулах шаардлагатай ноцтой авлига
Түвшин 25 Гайхалтай алдаа, мэдээллийн санд хандах боломжгүй байж магадгүй

Нийтлэг алдаанууд нь:

Хуудасны шалгах нийлбэр алдаа (мессеж 824)
Хуваарилалтын алдаа (мессеж 8928)
Индекс тууштай холбоотой асуудлууд (мессеж 8964)

Мессежийн бүтцийг ойлгох нь хариу арга хэмжээг эрэмбэлэх, сэргээх зохистой стратегийг тодорхойлоход тусалдаг.

4.1.3 Нийтлэг мэдээлэл, сэрэмжлүүлэг

Бүх DBCC CHECKDB гаралт нь ноцтой асуудлуудыг илтгэдэггүй. Энэ нь мөн зарим мэдээллийн болон анхааруулах мессежийг гаргаж болно, үүнд:

Засварын мэдэгдэл – Жижиг асуудлуудыг засахын тулд засварын командыг санал болгож буй мессежүүд
Хуваарилалтын анхааруулга – Өгөгдлийн хандалтад нөлөөлөхгүй зайны хуваарилалтын тухай анхааруулга
Гүйцэтгэлийн зөвлөмжүүд – Индекс засвар үйлчилгээ, оновчтой болгох зөвлөмж
Мэдээллийн мэдэгдэл – Шууд арга хэмжээ авах шаардлагагүй ерөнхий төлөвийн мессежүүд

Эдгээр мессежүүд нь яаралтай арга хэмжээ авах шаардлагатай авлига болон байнгын засвар үйлчилгээний цонхны үед шийдвэрлэх боломжтой жижиг асуудлуудыг ялгахын зэрэгцээ засвар үйлчилгээний үнэ цэнэтэй удирдамжийг өгдөг.

Жишээ сэрэмжлүүлэг:

DBCC results for 'InventoryDatabase'.
Msg 2570, Level 16, State 3, Line 1
Page (2:8452), slot 17 in object ID 485577333, index ID 0, partition ID 72057594038845456, 
alloc unit ID 72057594042515968 (type "In-row data").
Column "ProductPrice" value is out of range for data type "decimal". Update column to a legal value.
There are 45892 rows in 1247 pages for object "Products".
CHECKDB found 0 allocation errors and 1 consistency errors in table 'Products' (object ID 485577333).
CHECKDB found 0 allocation errors and 1 consistency errors in database 'InventoryDatabase'.

4.2 CHECKDB гүйцэтгэлийг зогсооно

Хэрэв CHECKDB янз бүрийн шалтгааны улмаас гүйцэтгэлийн явцад цуцалвал алдааны мэдэгдлийг мэдээлэх ба доорх төлөвийн код бүхий алдааны бүртгэлийг нэмнэ.

Төрийн	Тодорхойлолт
`0`	Алдааны дугаар 8930 гарсан байна. Энэ нь DBCC командыг зогсоосон мета өгөгдлийн эвдрэлийг харуулж байна.
`1`	8967 дугаар алдаа гарлаа. Дотоод DBCC алдаа гарлаа.
`2`	Яаралтай горимын мэдээллийн санг засварлахад алдаа гарсан.
`3`	Энэ нь DBCC командыг зогсоосон мета өгөгдлийн эвдрэлийг харуулж байна.
`4`	Баталгаажуулалт эсвэл хандалтын зөрчил илэрсэн.
`5`	DBCC командыг зогсоосон үл мэдэгдэх алдаа гарлаа.

Алдааны мессежийн жишээ:

Failed:(-1073548784) Executing the query "DBCC CHECKDB('InventoryDB') WITH NO_INFOMSGS" failed with the following error: "There is insufficient system memory to run this query.Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.

2024-11-18 09:52:41.38 spid35 I/O error (bad page ID) detected during read at offset 0x00000024886000 in file 'C:\Data\MSSQL\DATA\SalesDatabase.mdf'.

Алдааны бүртгэлийн жишээ:

11/15/2024 09:23:17,spid52,Unknown,DBCC CHECKDB (SalesDatabase) WITH all_errormsgs no_infomsgs executed by CORP\dbadmin terminated abnormally due to error state 3. Elapsed time: 1 hours 32 minutes 18 seconds.

Ийм тохиолдолд та нарийвчилсан хувилбаруудыг туршиж үзэх боломжтой DataNumen SQL Recovery Таны мэдээллийн сан дахь эвдрэлийг засах.

5. Авлигын алдааг засах

5.1 Нөөцлөх, сэргээх: Хамгийн найдвартай засвар

DBCC CHECKDB авлигын алдааг тодорхойлох үед цэвэр нөөцөөс сэргээх нь хамгийн найдвартай бөгөөд most найдвартай шийдэл. Энэ арга нь авлигын үндсэн шалтгааныг арилгахын зэрэгцээ мэдээллийн бүрэн бүтэн байдлыг баталгаажуулдаг. Сэргээхээсээ өмнө нөөцлөлтийн бүрэн бүтэн байдлыг ашиглан шалгана уу ЗӨВХӨН БАТАЛГААЖУУЛНА тушаалууд болон өгөгдлийн алдагдлыг багасгахын тулд цаг алдалгүй сэргээх сонголтуудыг авч үзье. Техник хангамжийн асуудал эсвэл програм хангамжийн алдаа дахин гарахаас сэргийлэхийн тулд нэмэлт анхаарал шаарддаг тул үндсэн шалтгааны шинжилгээнд зориулж авлигын дэлгэрэнгүй мэдээллийг баримтжуулна уу.

5.2 Хуудасны түвшний авлигын шийдэл

Өгөгдлийн жижиг хэсгүүдэд нөлөөлж буй тусгаарлагдсан хуудасны эвдрэлийн хувьд, SQL Server Enterprise Edition нь мэдээллийн санг бүрэн сэргээхгүйгээр тодорхой гэмтсэн хуудсуудыг засах боломжийг олгодог. Энэхүү дэвшилтэт техник нь бүрэн сэргээх загвар болон одоогийн бүртгэлийн нөөцлөлтийг шаарддаг.

Хуудсыг алхам алхмаар сэргээх үйл явц:

Гэмтсэн хуудсыг тодорхойлох CHECKDB алдааны мессежээс (жишээ нь, хуудас 1:256)
Одоогийн бүртгэлийн нөөцлөлтийг аваарай Сүүлийн үеийн гүйлгээг авахын тулд:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Log.trn'

Гэмтсэн хуудсыг сэргээнэ үү м-ээсost саяхны бүрэн нөөцлөлт:

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Full.bak'

Дифференциал нөөцлөлтийг ашиглах (Хэрэв боломжтой бол):

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Diff.bak'

Бүх бүртгэлийн нөөцлөлтийг ашиглана уу дарааллаар, түүний дотор саяхан үүсгэсэн:

RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log1.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log2.trn'
-- Continue for all log backups in order
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log.trn'

Эцсийн бүртгэлийн нөөцлөлтийг аваад сэргээ хуудсыг одоогийн болгохын тулд:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Final.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Final.trn'

Чухал бус өгөгдлийн өөр хувилбар: Хэрэв авлига нь чухал бус өгөгдөлд нөлөөлж байвал эвдэрсэн бүтцийг сэргээхээс өмнө нөлөөлөөгүй мөрүүдийг шинэ хүснэгтэд экспортлох боломжтой.

-- Export good data to a new table
SELECT * INTO YourTable_Backup 
FROM YourTable 
WHERE NOT EXISTS (SELECT 1 FROM corrupt_page_list WHERE page_id = target_page)

-- Drop and recreate the corrupted table
DROP TABLE YourTable
-- Recreate table structure and reload clean data

5.3 Авлигын индексийн хурдан засварууд

Индексийн авлига нь үндсэн хүснэгтийн өгөгдөлд нөлөөлөхгүйгээр индексийн бүтцийг дахин бий болгох үйл ажиллагаанд сайн хариу үйлдэл үзүүлдэг.

ALTER INDEX ALL ON YourTable REBUILD

Энэ арга нь кластер бус индексийн эвдрэлд маш сайн ажилладаг, учир нь дахин бүтээх нь эх хүснэгтийн өгөгдлөөс индексийн хуудсыг сэргээж, бүх эх мэдээллийг хадгалахын зэрэгцээ авлигыг үр дүнтэй арилгадаг.

6. REPAIR_REBUILD болон REPAIR_ALLOW_DATA_LOSS ашиглана уу

Хэрэв өмнөх аргууд бүгд амжилтгүй болсон эсвэл боломжгүй бол та мэдээллийн санг засахын тулд REPAIR_REBUILD болон REPAIR_ALLOW_DATA_LOSS сонголтыг ашиглаж болно.

6.1 REPAIR_REBUILD (Аюулгүй сонголт):

ашиглах: Индексийн авлига, жижиг хуваарилалтын алдаа
Өгөгдлийн аюулгүй байдал: Өгөгдөл устгахгүйгээр авлигыг засах оролдлого
Эрсдлийн түвшин: Бага - өгөгдөл алдагдахгүй
Ердийн хувилбарууд: Кластерт бус индексийн авлига, мета өгөгдлийн жижиг асуудлууд
Тушаалын жишээ: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 ӨГӨГДЛИЙН_АЛДАГИЙГ_ЗӨВШӨӨРӨХ_ЗАСВАРЛАХ (Сүүлийн арга зам):

ашиглах: Нөөцлөх боломжгүй үед ноцтой авлига
Өгөгдлийн аюулгүй байдал: Өгөгдлийн сангийн үйл ажиллагааг сэргээхийн тулд гэмтсэн өгөгдлийг устгаж болзошгүй
Эрсдлийн түвшин: Өндөр - байнгын өгөгдөл алдагдах боломжтой
Ердийн хувилбарууд: Хуудасны эвдрэл, системийн хүснэгтийн гэмтэл, хуваарилалтын гинжин хэлхээний алдаа
Тушаалын жишээ: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Эдгээр сонголтуудын шилдэг туршлага:

Үргэлж туршиж үзээрэй боломжтой бол мэдээллийн сангийн хуулбар дээр засвар хийх
Үргэлж нөөцлөөрэй Эдгээр сонголтыг ажиллуулахын өмнө
Бүх өөрчлөлтийг баримтжуулах дагаж мөрдөх, алдааг олж засварлах зорилгоор
Өгөгдлийн санг нэг хэрэглэгчийн горимд тохируулна уу засварын үйл ажиллагаа явуулахын өмнө

Ер нь бид хичээх хэрэгтэй REPAIR_REBUILD эхлээд сонголт. Хэрэв бүтэлгүйтвэл оролдоод үзээрэй ӨГӨГДЛИЙН_АЛДАГ_ЗӨВШӨӨРӨХ_ЗАСАХ сонголт.

6.4 ӨГӨГДЛИЙН_АЛДАГ_ЗӨВШӨӨРӨХ_ҮРДҮҮЛЭГ

6.4.1 Өгөгдлийн алдагдлыг засах нь амжилттай болно

Заримдаа ӨГӨГДЛИЙН_АЛДАГ_ЗӨВШӨӨРӨХ_ЗАСАХ сонголт амжилттай болно, гэхдээ зарим өгөгдөл нь lost засварын дараа.

Доор зарим жишээ мессежүүд байна:

CHECKDB found 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
CHECKDB fixed 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Msg 8909, Level 16, State 1, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 45035996309880832 (type Unknown), page ID (1:553) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).
The error has been repaired.
Msg 8939, Level 16, State 98, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 111464090777419776 (type Unknown), page (0:0). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 2057 and -1.
Could not repair this error.

Учир нь DBCC CHECKDB нь зарим гэмтсэн бичлэгүүдийг орхиж мэдээллийн санг засдаг боловч үнэндээ most Тэдгээрийн заримыг нь дамжуулан сэргээх боломжтой хэвээр байна DataNumen SQL Recovery.

Жишээ файлууд:

SQL Server хувилбар	БСХС-ийн эвдэрсэн файл	БСХС-ийн файлыг DataNumen SQL Recovery
SQL Server 2014	Алдаа10_1.mdf (8909 мессеж, дараа нь 8939 мессеж) (600 бичлэг lost REPAIR_ALLOW_DATA_LOSS-тай)	Алдаа10_1_fixed.mdf (Тэмдэглэл байхгүй lost)
SQL Server 2014	Алдаа10_2.mdf (8909 мессеж, дараа нь 8939 мессеж) (6000 бичлэг(50%) lost REPAIR_ALLOW_DATA_LOSS-тай)	Алдаа10_2_fixed.mdf (Зөвхөн 100 бичлэг лost)
SQL Server 2014	Алдаа 7 .mdf (100 бичлэг лost REPAIR_ALLOW_DATA_LOSS-тай)	Алдаа7_fixed.mdf (Зөвхөн нэг бичлэг лost)

6.4.2 Засварын алдаа – Мэргэжлийн шийдлийг анхаарч үзээрэй

If ӨГӨГДЛИЙН_АЛДАГ_ЗӨВШӨӨРӨХ_ЗАСАХ амжилтгүй болбол нэг буюу хэд хэдэн алдааны мессежийг гаргана.

Зарим жишээг доор харуулав.

DBCC results for ‘MyDatabase’.
CHECKDB found 0 allocation errors and 0 consistency errors in database ‘MyDatabase’.
Msg 824, Level 24, State 2, Line 8
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xea8a9a2f; actual: 0x37adbff8). It occurred during a read of page (1:28) in database ID 39 at offset 0x00000000038000 in file ‘MyDatabase.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

Msg 7909, Level 20, State 1, Line 8
The emergency-mode repair failed.You must restore from backup.

Msg 8992, Level 16, State 1, Line 8
Check Catalog Msg 3852, State 1: Row (object_id=69) in sys.objects (type=S ) does not have a matching row (object_id=69,column_id=1) in sys.columns.

Msg 8945, Level 16, State 1, Line 8
Table error: Object ID 41, index ID 1 will be rebuilt.
Could not repair this error.

Msg 2510, Level 16, State 17, Line 8
DBCC checkdb error: This system table index cannot be recreated.
Repair: The Nonclustered index successfully rebuilt for the object “sysidxstats” in database “MyDatabase”.

Msg 8921, Level 16, State 1, Line 8
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
Msg 8998, Level 16, State 2, Line 8
Page errors on the GAM, SGAM, or PFS pages prevent allocation integrity checks in database ID 39 pages from (1:0) to (1:8087). See other errors for cause.
CHECKDB found 1 allocation errors and 0 consistency errors not associated with any single object.
Msg 2575, Level 16, State 1, Line 8
The Index Allocation Map (IAM) page (1:157) is pointed to by the next pointer of IAM page (0:0) in object ID 3, index ID 1, partition ID 196608, alloc unit ID 196608 (type In-row data), but it was not detected in the scan.
Could not repair this error.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘sys.sysrscols’ (object ID 3).

Msg 8948, Level 16, State 3, Line 8
Database error: Page (1:295) is marked with the wrong type in PFS page (1:1). PFS status 0x70 expected 0x60.
The error has been repaired.
Msg 8905, Level 16, State 1, Line 8
Extent (1:296) in database ID 39 is marked allocated in the GAM, but no SGAM or IAM has allocated it.
The error has been repaired.

Msg 5028, Level 16, State 4, Line 4
The system could not activate enough of the database to rebuild the log.

Msg 5125, Level 24, State 2, Line 2
File ‘C:Program FilesMicrosoft SQL ServerMSSQL12.SQL2014MSSQLDATASalesDatabase.mdf’ appears to have been truncated by the operating system. Expected size is 5120 KB but actual size is 5112 KB.
Msg 3414, Level 21, State 1, Line 2
An error occurred during recovery, preventing the database ‘SalesDatabase’ (39:0) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.

Msg 3313, Level 21, State 1, Line 2
During redoing of a logged operation in database ‘SalesDatabase’, an error occurred at log record ID (135:752:2). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.

Эдгээр хувилбаруудад та мэргэжлийн шийдлийг ашиглах хэрэгтэй DataNumen SQL Recovery өгөгдлийн санг засахын тулд.

Жишээ файлууд

SQL Server хувилбар	БСХС-ийн эвдэрсэн файл	БСХС-ийн файлыг DataNumen SQL Recovery
SQL Server 2014	Алдаа1_3.mdf (Нэг мессеж 824)	Алдаа1_3_fixed.mdf
SQL Server 2014	Алдаа1_1.mdf (Тасралтгүй мессеж 824 алдаа)	Алдаа1_1 _fixed.mdf
SQL Server 2014	Алдаа1_2.mdf ((824 мессеж, дараа нь 7909 мессеж)	Алдаа1_2_fixed.mdf
SQL Server 2014	Алдаа4_1.mdf (8992 мессеж, дараа нь 3852 мессеж)	Алдаа4_1_fixed.mdf
SQL Server 2014	Алдаа4_2.mdf (8992 мессеж, дараа нь 3852 мессеж)	Алдаа4_2_fixed.mdf
SQL Server 2014	Алдаа5.mdf (Мессеж 8945)	Алдаа5_fixed.mdf
SQL Server 2014	Алдаа6.mdf (Мессеж 2510)	Алдаа6_fixed.mdf
SQL Server 2014	Алдаа2.mdf (Мессеж 2575)	Алдаа2_fixed.mdf
SQL Server 2014	Алдаа11.mdf (Мессеж 8905)	Алдаа11_fixed.mdf
SQL Server 2014	Алдаа3.mdf (Мессеж 5028)	Алдаа3_fixed.mdf
SQL Server 2014	Алдаа 8 .mdf (Мессеж 5125)	Алдаа 8 _fixed.mdf
SQL Server 2014	Алдаа9.mdf (Мессеж 3313)	Алдаа9_fixed.mdf

7. Шилдэг туршлага

7.1 CHECKDB-ийн тогтмол үйл ажиллагааны хуваарь гаргах

Өндөр гүйлгээтэй системийг өдөр бүр шалгаж, үйлдвэрлэлийн чухал мэдээллийн сангуудад долоо хоног бүр DBCC CHECKDB гүйцэтгэлийг хэрэгжүүл. Гүйцэтгэлд үзүүлэх нөлөөллийг багасгахын тулд ашиглалт багатай хугацаанд үйлдлүүдийг төлөвлөх ба мэдээллийн сангийн хэмжээ болон засвар үйлчилгээний цонхонд тулгуурлан бүрэн шалгалт болон ЗӨВХӨН ЗӨВХӨН ЗӨВХӨН физиологийн сонголтуудын хооронд сэлгэх талаар бодож үзээрэй. дамжуулан автоматжуулсан хуваарь SQL Server Агент нь төвлөрсөн хяналт-шинжилгээ, сэрэмжлүүлгийн чадавхийг хангахын зэрэгцээ тогтвортой гүйцэтгэлийг баталгаажуулдаг.

7.2 Гүйцэтгэлийн нөлөөллийн удирдлага

DBCC CHECKDB үйл ажиллагаа нь системийн ихээхэн нөөцийг зарцуулж, хэрэглэгчийн нэгэн зэрэг үйл ажиллагаанд нөлөөлж болзошгүй. Гүйцэтгэлийн нөлөөллийн хэв маягийг ойлгохын тулд шалгалтын явцад CPU-ийн ашиглалт, санах ойн зарцуулалт, дискний оролт гаралтыг хянах. Сар бүрийн засвар үйлчилгээний цонхонд бүрэн баталгаажуулалтыг нөөцөлж, ердийн шалгалтанд NOINDEX сонголтуудыг ашиглах талаар бодож үзээрэй. Бүрэн бүтэн байдлыг шалгах хугацаанд хүлээлтийг удирдахын тулд асуулгын хугацаа дуусах өргөтгөл болон хэрэглэгчийн харилцааны стратегийг хэрэгжүүлээрэй.

7.3 Засвар үйлчилгээний цонхны төлөвлөлт

DBCC CHECKDB хуваарийг нөөцлөх үйл ажиллагаа, индексийг сэргээх, статистикийн шинэчлэлт зэрэг бусад засвар үйлчилгээний үйл ажиллагаатай уялдуулна. Гүйцэтгэлийн бууралт эсвэл хугацаа хэтрэх асуудал үүсгэж болзошгүй нөөц их шаардсан үйлдлүүдийг давхцуулахаас зайлсхий. Мэдээллийн сангийн хэмжээ нэмэгдэхийн хэрээр бүрэн бүтэн байдлыг баталгаажуулахад хангалттай цагийг өгөгдлийн сангийн хэмжээг нэмэгдүүлэх төсөөлөлд үндэслэн засвар үйлчилгээний цонхыг төлөвлө.

7.4 Автоматжуулсан хяналт, дохиолол

тохируулна SQL Server DBCC CHECKDB нь авлигыг илрүүлэх үед админуудад нэн даруй мэдэгдэхийн тулд агент анхааруулга өгдөг. Бүрэн бүтэн байдлыг шалгах үр дүнг гаргаж, ангилах бүртгэлийн задлан шинжлэх шийдлүүдийг хэрэгжүүлснээр чиг хандлагын дүн шинжилгээ хийх, асуудлыг идэвхтэй тодорхойлох боломжтой болно. Авлигын ноцтой байдлын янз бүрийн түвшинд хариу арга хэмжээ авах хугацаа, хариуцлагатай боловсон хүчнийг тодорхойлсон эрчимжүүлэх журмыг бий болгох.

8. DBCC CHECKTABLE: The Lightweight Alternative

8.1 CHECKDB-ийн оронд CHECKTABLE-г хэзээ ашиглах вэ

DBCC CHECKTABLE нь хүснэгтийн бүрэн бүтэн байдлыг шалгах боломжийг олгодог бөгөөд үүнийг хийхэд тохиромжтой tarөгөгдлийн сангийн тодорхой объектуудын алдааг олж засварлах, засвар үйлчилгээ хийх. CHECKTABLE-г тодорхой хүснэгтүүдийн гүйцэтгэлийн асуудлыг судлах, мэдээллийн баазын бүрэн шалгалтын хооронд бизнесийн чухал хүснэгтүүдийг баталгаажуулах, эсвэл цагийн хязгаарлалт нь мэдээллийн санг бүрэн баталгаажуулахад саад болох үед ашиглана. Энэ арга нь CHECKDB-ийн бүрэн ажиллагаа нь засвар үйлчилгээний цонхноос давсан томоохон мэдээллийн санд онцгой ач холбогдолтой болохыг баталж байна.

8.2 DBCC CHECKTABLE Синтакс ба жишээнүүд

CHECKTABLE үндсэн команд tarтодорхой хүснэгтүүдийг авдаг:

DBCC CHECKTABLE('YourTable')

CHECKDB-ийн нэгэн адил CHECKTABLE нь гүйцэтгэлийг оновчтой болгох NOINDEX, авлигыг шийдвэрлэх параметрүүдийг засах зэрэг янз бүрийн сонголтыг дэмждэг. Та мөн хүснэгтийг нарийн тодорхойлохын тулд схемийн нэрийг зааж өгч болно:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

энэ нь tarавсан арга нь ажлын цагаар системийн гүйцэтгэлийг хадгалахын зэрэгцээ бүрэн бүтэн байдлыг шалгах боломжийг олгодог.

8.3 Том өгөгдлийн сангийн гүйцэтгэлийн ашиг тус

CHECKTABLE үйлдлүүд нь мэдээллийн санг бүрэн шалгахаас хамаагүй хурдан дуусч, чухал хүснэгтүүдийн бүрэн бүтэн байдлыг илүү олон удаа шалгах боломжийг олгодог. Энэ арга нь CHECKDB-ийн иж бүрэн үйл ажиллагааг долоо хоног эсвэл сарын хуваарийн дагуу нөөцлөхийн зэрэгцээ чухал бизнесийн хүснэгтүүдийг өдөр бүр баталгаажуулах боломжийг олгодог. Нөөцийн хэрэглээ багассан нь CHECKTABLE-г хэрэглэгчийн нөлөөлөл багатайгаар үйлдвэрлэлийн орчинд ашиглахад тохиромжтой болгодог.

9. CHECKDB амжилтгүй болсон үед

DBCC CHECKDB нь янз бүрийн хувилбаруудад амжилтгүй болно, үүнд:

DBCC CHECKDB гүйцэтгэл хэвийн бусаар төгсдөг
DBCC CHECKDB гүйцэтгэл амжилттай дууссан боловч засварын сонголтууд мэдээллийн баазыг засварлаж чадахгүй.

Эдгээр тохиолдолд мэдээллийн сан дахь эвдрэлийг засахад туслах илүү мэргэжлийн хэрэгсэл хэрэгтэй байна.

9.1 Танилцуулга DataNumen SQL Recovery

DataNumen SQL Recovery илүү дэвшилтэт боломжуудыг олгодог:

Хамгийн сайн нөхөн сэргээх түвшин Энэ салбарт.
Өгөгдлийн сангийн ноцтой гэмтсэн файлуудыг сэргээх.
Хүснэгт, индекс, харагдац, триггер, дүрэм, өгөгдмөл зэрэг бүх мэдээллийн сангийн объектыг сэргээх.
Хадгалагдсан процедурууд, скаляр функцууд, доторлогоотой хүснэгтийн үнэ цэнэтэй функцууд, олон төлөвт хүснэгтийн үнэ цэнэтэй функцуудыг сэргээ.
Бүрмөсөн устгасан бичлэгүүдийг сэргээх.
Шифрлэгдсэн объектуудын шифрийг тайлах SQL Server өгөгдлийн сан.
БСХС файлуудыг багцаар засна.
Засварын цогц сонголтууд.
Нарийвчилсан бүртгэл, тайлагнах.
Бүгдийг дэмжих SQL Server хувилбарууд.
Техникийн дэмжлэг авах боломжтой
Тогтмол шинэчлэлт, сайжруулалт

9.2 Амжилтын түвшний харьцуулалт

Сэргээх амжилтын түвшин эрс ялгаатай:

DBCC CHECKDB & CHECKTABLE: 1.27% нөхөн сэргээх дундаж түвшин
DataNumen: 92.6% нөхөн сэргээх түвшин

Доорх нь бүрэн өрсөлдөөний харьцуулалт юм:

9.3 Ноцтой авлигаас гарах

Хүнд тохиолдолд дэвшилтэт боломжууд:

Бие махбодийн хувьд гэмтсэн хадгалалтаас сэргээх
Форматлагдсан хөтчүүд эсвэл эвдэрсэн системээс сэргээх
Дискний зураг, нөөц файлууд, виртуал машины дискний файлууд, хэмнэлээс сэргээхrary файлууд гэх мэт.

9.4 Мэргэжлийн шийдлүүдийг хэзээ авч үзэх вэ

Саяхан нөөцлөх боломжгүй
DBCC CHECKDB амжилтгүй боллоо
Авлигын ноцтой хувилбарууд
Бизнесийн чухал өгөгдөлтэй харьцах
Цаг хугацаа эгзэгтэй үед
Хамгийн их нөхөн сэргээх шаардлагатай үед

10. Түгээмэл асуултууд

10.1 Хэрэглээний үндсэн асуултууд

А: Би DBCC CHECKDB-г хэр олон удаа ажиллуулах ёстой вэ?

A: Үйлдвэрлэлийн чухал мэдээллийн сангийн хувьд CHECKDB-г долоо хоног бүр ажиллуул. Өндөр гүйлгээтэй системүүдийн хувьд PHYSICAL_ONLY сонголтыг ашиглан өдөр бүр шалгах, долоо хоног бүр бүрэн шалгалт хийнэ. Хөгжлийн мэдээллийн санг сар бүр шалгаж болно.

А: Би шууд үйлдвэрлэлийн мэдээллийн сан дээр DBCC CHECKDB ажиллуулж болох уу?

A: Тийм ээ, DBCC CHECKDB нь хэрэглэгчдийг блоклохгүйгээр онлайн мэдээллийн сан дээр ажиллах боломжтой. Гэсэн хэдий ч энэ нь ихээхэн хэмжээний нөөцийг зарцуулдаг тул бага ачаалалтай үед үүнийг төлөвлөж, системийн гүйцэтгэлийг хянах хэрэгтэй.

А: CHECKDB болон CHECKTABLE хоёрын ялгаа юу вэ?

A: CHECKDB нь мэдээллийн баазыг бүхэлд нь шалгадаг бол CHECKTABLE нь тус тусдаа хүснэгтэд анхаарлаа хандуулдаг. CHECKTABLE-г ашиглана уу tarалдааг олж засварлах эсвэл мэдээллийн санг бүхэлд нь скан хийлгүйгээр тодорхой хүснэгтүүдийг шалгах шаардлагатай үед.

10.2 Гүйцэтгэлийн болон нөөцийн асуултууд

Асуулт: DBCC CHECKDB яагаад миний том мэдээллийн санд удаан хугацаа зарцуулдаг вэ?

A: CHECKDB үргэлжлэх хугацаа нь өгөгдлийн сангийн хэмжээ, техник хангамжийн гүйцэтгэл, ашигласан сонголтуудаас хамаарна. Илүү хурдан шалгахын тулд ЗӨВХӨН PHYSICAL_, эсвэл кластерт бус индексийг алгасах бол NOINDEX-ийг ашиглана уу. Зориулалтын нөөцөөр засвар үйлчилгээний цонхыг ажиллуулах талаар бодож үзээрэй.

А: CHECKDB-д хэр хэмжээний tempdb зай хэрэгтэй вэ?

A: Ерөнхийдөө CHECKDB үйл ажиллагааны явцад өгөгдлийн сангийнхаа 10-15%-ийг tempdb-д хуваарилаарай. Нарийвчилсан тооцоолол авахын тулд ESTIMATEONLY сонголтыг ашиглана уу: DBCC CHECKDB('YourDB') WITH ESTIMATEONLY

А: Би ажиллаж байгаа CHECKDB үйлдлийг цуцалж болох уу?

A: Тийм ээ, та сесс ID дээрх KILL командыг ашиглан CHECKDB-г цуцалж болно. Гэсэн хэдий ч, цуцлах нь өгөгдлийн сангийн бүрэн бүтэн байдлын талаар мэдээлэл өгөхгүй бөгөөд та үүнийг дараа дахин ажиллуулах шаардлагатай болно.

10.3 Асуултуудыг шийдвэрлэх алдаа

А: CHECKDB алдаа олсон - би сандрах ёстой юу?

A: Бүү сандар, гэхдээ хурдан ажилла. Нэгдүгээрт, CHECKDB амжилттай дууссан боловч эвдрэл илэрсэн эсэх, эсвэл CHECKDB өөрөө ажиллаж чадаагүй эсэхийг тодорхойлно. Алдаа нь зөвхөн кластерт бус индекс (бага чухал) эсвэл хүснэгтийн өгөгдөлд (илүү ноцтой) нөлөөлж байгаа эсэхийг шалгана уу.

А: Би хэзээ REPAIR_ALLOW_DATA_LOSS ашиглах ёстой вэ?

A: Өгөгдлийн сангийн нийт алдагдалтай харьцуулахад ашиглах боломжтой нөөцлөлт байхгүй, өгөгдлийн алдагдлыг хүлээн зөвшөөрч байгаа тохиолдолд л эцсийн арга хэмжээ болно. Засварлах ажиллагаа нь мэдээллийн байнгын алдагдалд хүргэж болзошгүй тул эхлээд нөөцлөлтөөс сэргээхийг оролдоорой.

А: "Мэдээллийн сангийн тууштай байдлын алдаа" ба "хуваарилалтын алдаа" гэдэг нь юу гэсэн үг вэ?

A: Хуваарилалтын алдаа нь хэрхэн нөлөөлдөг SQL Server дискний зай ашиглалтыг хянадаг бол тууштай байдлын алдаа нь өгөгдөл эсвэл индексийн бүтэцтэй холбоотой асуудлуудыг илэрхийлдэг. Аль аль нь анхаарал шаарддаг боловч тогтмол байдлын алдаа нь мэдээллийн хүртээмжид шууд нөлөөлдөг.

10.4 Нөөцлөх болон сэргээх асуултууд

А: Би нөөцлөлт дээрээ CHECKDB ажиллуулах ёстой юу?

A: Мэдээжийн хэрэг! Туршилтын серверүүдэд нөөцлөлтийг сэргээсний дараа CHECKDB-г ажиллуулна уу. Энэ нь нөөцлөлтийн бүрэн бүтэн байдлыг баталгаажуулж, авлигаас үнэхээр сэргэж чадна гэдгийг баталгаажуулдаг. Боломжтой бол энэ үйл явцыг автоматжуулах.

А: Миний нөөцлөлт бас гэмтсэн - одоо яах вэ?

A: Цэвэр нөөц олтлоо хуучин нөөцлөлтийг туршиж үзээрэй. Хэрэв цэвэр нөөц байхгүй бол мэргэжлийн сэргээх шийдлүүдийг анхаарч үзээрэй DataNumen SQL Recovery. Ирээдүйд гарахаас урьдчилан сэргийлэхийн тулд авлигын цаг хугацааны хуваарийг баримтжуулах.

Асуулт: Мэдээллийн санг бүрэн сэргээхгүйгээр хуудсыг сэргээх боломжтой юу?

A: Тийм ээ, гэхдээ зөвхөн дотор SQL Server Бүрэн сэргээх загвар болон одоогийн бүртгэлийн нөөцлөлт бүхий Enterprise Edition. Хуудас сэргээх нь тусгаарлагдсан хуудасны эвдрэлд зориулагдсан боловч зохих журмын дагуу болгоомжтой гүйцэтгэх шаардлагатай.

10.5 Алдааг олж засварлах асуултууд

Асуулт: CHECKDB нь "зай дутуу" алдаатай байна - би юу хийж чадах вэ?

A: tempdb зай гаргах, tempdb-г илүү хурдан хадгалах сан руу зөөх эсвэл tempdb ашиглалтыг багасгахын тулд TABLOCK сонголтыг ашиглана уу. Нөөцийн хэрэгцээг багасгахын тулд CHECKDB-г NOINDEX эсвэл ЗӨВХӨН PHYSICAL_-ээр ажиллуулна уу.

Асуулт: CHECKDB гаралтаас ямар хүснэгтэд гэмтэл байгааг би хэрхэн тодорхойлох вэ?

A: Алдааны мэдэгдлээс "объект ID" дугаарыг хайж олоод дараахыг ашиглана уу: SELECT OBJECT_NAME(object_id) хүснэгтийн нэрийг олох. Алдааны мэдэгдлүүд нь байршлыг нарийн тодорхойлох хуудас, үүрний дугаарыг агуулдаг.

Асуулт: Техник хангамжийн асуудал CHECKDB-г худал эерэг мэдээлэхэд хүргэж болох уу?

A: Тиймээ, эвдэрсэн техник хангамж (ялангуяа хадгалах сан) нь CHECKDB ажиллуулах хооронд гарч ирэх, алга болох үе үе эвдрэлд хүргэж болзошгүй. Хэрэв алдаа зөрчилтэй байвал оролт/гаралтын дэд системээ судалж, хэв маягийг баталгаажуулахын тулд олон шалгалт явуулна уу.

10.6 Нарийвчилсан тохиргооны асуултууд

Асуулт: Ямар ул мөрийн туг нь CHECKDB гүйцэтгэлийг сайжруулж чадах вэ?

A: Trace flag 2562 нь CHECKDB-г нэг багц болгон ажиллуулснаар гүйцэтгэлийг сайжруулж чадна. Өгөгдлийн сангийн файлууд тусдаа дискэн дээр байх үед Trace flag 2549 тусалдаг. Эдгээрийг болгоомжтой ашиглаж, эхлээд үйлдвэрлэлийн бус газарт туршиж үзээрэй.

А: Би CHECKDB хяналт, сэрэмжлүүлгийг хэрхэн автоматжуулах вэ?

A: ашиглах SQL Server 8930, 8939 болон бусад алдааны дугаарын агент анхааруулга. CHECKDB-ийн үр дүнг задлахын тулд бүртгэлийн задлан шинжилгээг хийж, аливаа авлигын илрүүлэлтэд мэдэгдэл үүсгэнэ үү. Ола Халленгренийн скриптүүд шиг засвар үйлчилгээний шийдлийн хүрээг ашиглах талаар бодож үзээрэй.

А: Би EXTENDED_LOGICAL_CHECKS сонголтыг ашиглах ёстой юу?

A: Хэрэв та нарийн төвөгтэй логик авлигыг сэжиглэж, хангалттай гүйцэтгэлтэй байх тохиолдолд л. Энэ сонголт нь индексжүүлсэн харагдац, XML индекс, орон зайн индекс дээр нэмэлт шалгалт хийх боловч гүйцэтгэлийн хугацааг ихээхэн нэмэгдүүлдэг.

11. дүгнэлт

11.1 Гол санаануудын хураангуй

11.1.1 DBCC CHECKDB-н чухал командуудын тойм

Өгөгдлийн сангийн иж бүрэн шалгалтын үндсэн DBCC CHECKDB синтаксийг эзэмшиж, гүйцэтгэлийг оновчтой болгохын тулд NOINDEX болон ЗӨВХӨН PHYSICAL_Options-г ашиглаж, CHECKTABLE-г ойлгоорой. tarхүснэгтийн баталгаажуулалтыг авсан. Эдгээр үндсэн командууд нь мэдээллийн сангийн идэвхтэй засвар үйлчилгээний үндэс суурь болж, авлигыг эрт илрүүлэх, бүрэн бүтэн байдлыг системтэйгээр хянах боломжийг олгодог.

11.1.2 Чухал шилдэг туршлагын сануулга

Бүрэн бүтэн байдлыг шалгахын өмнө одоогийн нөөцлөлтүүдийг үргэлж хадгалж, мэдээллийн баазын чухал байдалд үндэслэн CHECKDB-ийн тогтмол үйл ажиллагааг төлөвлөх, авлигын яаралтай сэрэмжлүүлгийг автоматаар хянах. Тогтмол хяналт тавих замаар урьдчилан сэргийлэх нь реактив хандлагыг давж, стандарт хэрэгсэл хангалтгүй болох үед мэргэжлийн нөхөн сэргээх шийдэл нь үнэ цэнэтэй нөөцлөлтийг өгдөг гэдгийг санаарай.

11.2 DBCC CHECKDB болон Нарийвчилсан шийдлүүдийг хэзээ ашиглах вэ

DBCC CHECKDB-ийг байнгын бүрэн бүтэн байдлыг хянах, бага зэргийн авлигын асуудлыг шийдвэрлэхэд ашиглахын зэрэгцээ, засварлах чадвараас хэтэрсэн ноцтой авлигын хувилбаруудад мэргэжлийн нөхөн сэргээх хэрэгслийг нөөцөлж аваарай. Шийдвэрийн тогтолцоо нь нөөц нөөцлөх боломж, өгөгдлийн чухал байдал, цаг хугацааны хязгаарлалт, авлигын ноцтой байдлыг харгалзан үзэх ёстой. Амжилттай өгөгдлийн сангийн администраторууд CHECKDB-ийн байнгын хяналтыг иж бүрэн нөөцлөх стратегитай хослуулж, стандарт арга барил хангалтгүй байгаа тохиолдолд сэргээх дэвшилтэт сонголтуудыг мэддэг.

11.3 DBA-д зориулсан өдөр тутмын эрүүл мэндийн хурдан шалгах хуудас

DBCC CHECKDB-г ажиллуулахаас гадна эдгээр өдөр тутмын чухал дадал зуршлуудыг ашиглан өгөгдлийн сангийн оновчтой эрүүл мэндийг хадгалах:

1. Нөөцлөлтийн бүрэн бүтэн байдлыг шалгана уу

Төлөвлөсөн нөөцлөлт амжилттай дууссаныг баталгаажуулна уу
Нөөц унших боломжтой эсэхийг шалгахын тулд ЗӨВХӨН RESTORE VERIFYON-г ашиглана уу
Сайтаас гадуурх хуулбарууд синхрончлогдсон, хүртээмжтэй байгаа эсэхийг шалгаарай

Мөн эндээс дэлгэрэнгүй мэдээлэл авах боломжтой бидний дэлгэрэнгүй гарын авлага SQL Server нөөц.

2. Тогтвортой байдлын байдлыг хянана

Шөнийн гүйлтийн автоматжуулсан DBCC CHECKDB үр дүнг шалгана уу
Хяналт SQL Server авлигын сэрэмжлүүлгийн алдааны бүртгэл
Аливаа бүрэн бүтэн байдлын доголдлыг нэн даруй шалгаж үзээрэй

3. Серверийн эрүүл мэндийг хянах

CPU, санах ой болон дискний оролт гаралтын үзүүлэлтүүдийг шалгана уу
tempdb зай байгаа эсэхийг шалгана уу
Хаагдсан процессууд болон удаан үргэлжилсэн асуулгыг тодорхойлох

4. Түгжээний үйл ажиллагааг хянах

Системийн эрүүл мэндийн үйл явдлуудаас гацсан графикуудыг шалгана уу
Асуудалтай асуултуудыг тодорхойлж, хөгжүүлэлтийн багуудаар оновчтой болгох
Гацааны хохирогчдын тоо болон бизнесийн нөлөөллийг хянах

Чухал сануулагч

Өгөгдлийн сангийн байнга хумигдахаас зайлсхий - энэ нь хуваагдлыг нэмэгдүүлж, гүйцэтгэлийг бууруулдаг. Зөвхөн шаардлагатай үед их хэмжээний өгөгдлийг устгасны дараа багасгана.
Хяналтын ажлыг автоматжуулах ашиглах SQL Server Асуудлын талаар анхааруулга бүхий агентын ажил эсвэл засвар үйлчилгээний төлөвлөгөө.
Гамшгаас сэргээн босгох журмыг турших Нөөцлөлтийг сэргээж, сэргээх зорилтуудыг биелүүлэх боломжтой хэвээр байлгахын тулд долоо хоног бүр.

Энэхүү өдөр тутмын хяналтын хуудсыг DBCC CHECKDB-ийн байнгын ажиллагаатай хослуулснаар та идэвхтэй хяналт, асуудалд шуурхай хариу өгөх замаар мэдээллийн баазын орчныг цогц хамгаалалтыг бий болгоно.

12. Ашигласан материал

Microsoft Learn. "DBCC CHECKDB (Transact-SQL)." SQL Server Бичиг баримт. Microsoft корпораци.
https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
Microsoft Learn. "DBCC CHECKDB-ийн мэдээлсэн мэдээллийн сангийн тогтвортой байдлын алдааг олж засварлах." SQL Server Бичиг баримт. Microsoft корпораци.
https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors

DBCC CHECKDB: MS-ийн бүрэн гарын авлага SQL Server Өгөгдлийн сангийн эрүүл мэнд (2026)