Повредени база данни (от помощ, моята база данни е повреден

Повреден база данни - това е може би една от най-лошите кошмари на повечето администратори на бази данни. Резултатът е увреждане на ремонти, виковете на мениджъри и всякакви други неприятни неща.
В тази статия, аз ще обясня, че е невъзможно да се направи, ако е повредена база данни и да се опишат някои от това, което трябва да се направи, някои видове травми и как те могат да бъдат поправени.

Как да се открие, че базата данни е повреден

Обикновено повреди напълно открити, когато се опитвате да получите достъп до засегната страницата. Заявки на резервни копия или процедура Повторно не успее с високи нива на тежест.
Ето няколко примера за системни съобщения, когато установи увреждане на базата данни:
SQL Server открива логическа последователност въз основа на I / O грешка: неправилна контролна (очаква: 0xfdff74c9; действителната: 0xfdff74cb). Той се е появил при четене на страница (1: 69,965) в ID база данни 13 при офсетов 0x0000002229a000 във файла "D: \ Разработване \ Данни на Guide-Bulgaria.com \ Broken1.mdf".
Правят опити за извличане логично страница 1: 69 965 в база данни 13 не успя. Той принадлежи към дяловите разпределители 281474980642816 не 72057594049069056.

Какво да правя, ако базата данни е все още непокътнати

1. Не изпадайте в паника
2. Не изваждайте (отделят) го
3. Не рестартирайте SQL Server
4. Не се възстанови скоро
5. Направете проверка на целостта
6. намери причината

Не изпадайте в паника

Най-важното нещо, когато установи увреждане на базата данни - това е да не се паникьосвайте. Всички решения трябва да бъдат внимателно претеглени, предвид трябва да се вземат всички възможни фактори. По дяволите само влоши положението чрез приемане не е напълно информирано решение.

Не се отделят в базата данни

В повечето случаи, когато SQL Server obnarzhivaet база данни с корупцията, това означава, че базата данни всъщност са повредени страници. Опитвайки се да убеди SQL Server, че не е вярно, като изключите (откачване) и сглобите отново (да се приложи) на база данни, архивиране и възстановяване, SQL Server услугата се рестартира или сървърът се рестартира, не доведе до факта, че грешката ще изчезне.
Ако базата данни е повреден, и SQL Server ще открие това присъединяване, тя няма да бъде в състояние да го прикрепите. Има няколко начина да получите него, за да видите тази база данни, но тя е много по-добре просто да го изключите.

Не рестартирайте SQL Server

По същия начин, както когато го изключвате-присъединяване, рестартирайте услугата SQL Server няма да може да се определи грешки, открити (ако има такива).
Рестартирането на услугата може да влоши положението. Ако SQL Server открие грешка по време на фазата на възстановяване (възстановяване), след като се рестартира базата данни, тя ще го маркирате като "заподозрян", което значително усложни процеса на възстановяване на база данни.

Не се възстанови скоро

Вие може да се изкуши да просто стартирате DBCC CHECKDB с един от "възстановяване" на параметрите (обикновено загуба на данни) и да се надяваме, че всичко ще бъде по-добре (в моя опит - първото нещо, което се препоръчва в "второстепенни" форуми на SQL Server - стартирайте DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS - обърнете внимание на преводача) .. стартиране на това намаление не се препоръчва в много случаи. Той не гарантира правилно всички грешки и може да доведе до неприемлив загуба на данни.
Такова възстановяване - това е последната стъпка в коригиране на грешки. Тя трябва да започне само ако имате друг избор, но не и на първо място.

Направете проверка на целостта

намери причината

След грешките се поправят, работата не може да се смята за завършена. Ако причината за грешката не е била установена, те могат да бъдат отново. Обикновено, основната причина за грешката е проблем с входно-изходна подсистема, но те също могат да бъдат причинени от неправилна експлоатация на "софтуер на ниско ниво" (като антивирусен), човек на действието, или грешки на SQL Server.

какво следва

Неправилно информация за свободното място на страницата

Msg 2508, Level 16, 3 бала, Линия 1
страницата RSVD данни в ред брои за обект "Broken1", индекс ID 0, дял ID 76,911,687,695,381, Alloc единица ID 76,911,687,695,381 (тип В ред данни) е неправилна. Изпълнете DBCC UPDATEUSAGE.

Повреда на само не-клъстерирани индекси

В този случай, щетите могат да бъдат напълно коригирано чрез отстраняване на повредения не-клъстерирани индекс и пресъздайте тях. Възстановяването на индекс (ALTER INDEX REBUILD) в он-лайн (а понякога и оф-лайн) чете стария индекс страницата, за да създадете нов и, следователно, се провали. Ето защо, трябва да премахнете стария индекс и може да създаде отново.
Това е, което ще направи DBCC CHECKDB с параметър REPAIR_REBUILD, но базата данни в същото време да бъде в режим на единичен потребител. Ето защо обикновено по-добре да се извърши ръчно тези операции в базата данни може да продължи да работи, докато индексите са пресъздадени.
Ако имате достатъчно време, опитвайки се да пресъздадат желаното индекса и на разположение е "чист" (не съдържа самата грешка) пълно архивиране и резервни копия на регистър на транзакциите на непрекъсната верига от списания, можете да поправите повредени страници от тях.

Щети LOB-страници

Msg 8964, Level 16, членка 1, Линия 1
Таблица грешка: ID обект 181575685, индекс ID 1, дял ID 72057594145669120, Alloc единица ID 72057594087800832 (данни тип LOB). възел извън ред данни в страницата (1: 2444050), слот 0, текст ID 901891555328 не е посочен.

Грешката, показва, че има LOB-страница (голям обект), която не се отнася до една единствена страница с данни. Това може да се случи, ако преди това струпани индекс е повреден (или китка) и повредени страници са били премахнати.
Ако CheckDB се говори само на такива грешки, можете да стартирате DBCC CHECKDB с REPAIR_ALLOW_DATA_LOSS вариант - тези страници ще бъдат унищожени. Тъй като все още не разполагат страници с данни, които сочат към тези страници, голяма загуба на данни ще бъдат унищожени.

Грешки, свързани с освобождаването на гама

Msg 2570, Сев 16, 3 бала, ред 17
Page (1: 1103587), слот 24 в обект ID 34, индекс ID 1, дял ID 281,474,978,938,880, Alloc единица ID 281,474,978,938,880 (тип "В-ред данни"). Колона "модифициран" стойност е извън обхват за тип данни "дата и час". Актуализиране на колона, за да има правна стойност.

Увреждане на клъстери индекс или купчината

Ако се установи, че е повреден купчината страници или нивото на листа (листа страници) на клъстери индекс - това означава, че данните за тях се губят. Страници ниво листо групираната Индексът съдържа страници с данни директно и за тях се осигурява не съкращения.
Ако CheckDB съобщава повреди страниците на ниво листа на клъстери индекс, с необходимия "курс за възстановяване" за DBCC CHECKDB - REPAIR_ALLOW_DATA_LOSS.
Примери за такива грешки:
Сървър: Msg 8976, Level 16, членка 1, Линия 2
Таблица грешка: ID обект 181575685, индекс ID 1, дял ID 76,911,687,695,381, Alloc единица ID 76,911,687,695,381 (тип В ред данни). Page (1: 22,417) не е наблюдаван при сканирането, въпреки че неговата майка (1: 479) и предишната (1: 715 544) се отнасят към него. Сървър: Msg 8939, Level 16, членка 1, Линия 2
Таблица грешка: ID обект 181575685, индекс ID 0, страница (1: 168 576). Тест (m_freeData> = PAGEHEADSIZE m_freeData <= (UINT)PAGESIZE - m_slotCnt * sizeof (Slot)) failed. Values are 44 and 8028.

Трябва да се помни, че ако грешките върнати CheckDB, обърнете се към индекс ID = 0 или 1, което означава, че самите данни е повреден.
Този тип грешка се коригира, но корекцията е да унищожи линии или цели страници. Когато CheckDB изтрива данни, за да се коригира грешка, ограниченията, наложени от външни ключове, не са проверени и не тригери не се задействат. Line или страница просто изтрити. В резултат на това, данните не могат да бъдат договорени, или логическа цялост (LOB-на страница вече не може да се позовава нито един ред или не-клъстерирани индекс линия може да означава "никъде") може да бъде компрометирана. Поради тези ефекти, като възстановяване не се препоръчва.
Ако имате "чисти" архивиране, възстановяване от това обикновено е по-predpochitelnym да коригира тези грешки. Ако базата данни е в пълния модел на възстановяване, а вие имате резервни копия на регистъра на операциите, със здрав дневник верига (започвайки от последния "чист" пълен бекъп), можете да направите резервно копие на активната част на дневника и възстановяване на цялата база данни (или само на повредените страници), в при което данните няма да бъдат загубени изобщо.
Ако архивиране без никакви данни непокътнати, са останали само с един вариант - да тече DBCC CHECKDB с REPAIR_ALLOW_DATA_LOSS опция. Това ще изисква базата данни за превод на потребителски режим за продължителността на тази процедура.
Въпреки че не може да се предотврати загуба на данни, можете да видите какви данни ще бъдат премахнати от клъстерирани индекса. За да направите това, вижте тази публикация от Павел Renadala.

увреждане на метаданните

Msg 3853, Level 16, членка 1, Линия 1
Умение (на_обект = 181,575,685) на ред (на_обект = 181575685, column_id = 1) в sys.columns не са съвпадение ред (на_обект = 181575685) в sys.objects.

непоправими щети

CheckDB не може да се определи всичко. Всички грешки, като следните са непоправими, и единственият начин - е възстановяване на данни от резервно копие, че не разполага с тези лезии. Ако имате пълен архив и регистър на веригата не е прекъсната до настоящия момент, можете да zabekapit крайния фрагмент на регистъра на операциите и базата данни могат да бъдат възстановени, без загуба на данни.
Ако няма архиви, единственото нещо, което можеш да направиш - тези, сценарист обекти и качване на данни, които са все още на разположение. Много е вероятно, че в резултат на щетите, не са налични всички данни, и, най-вероятно, не всички обекти могат да бъдат сценарист без грешки.

Повреда на системните таблици,

Msg 7985, Level 16, държавен 2, Линия 1
Система за маса предварителни проверки: ID на обекта 4. Не може да се прочете и резе страница (1: 358) с резе тип SH.
Проверете изявление прекратено поради поправени грешки. Msg 8921, Level 16, членка 1, Линия 1
Проверете прекратено. Пропускът е бил открит, докато събирането на факти. Вероятно tempdb от космоса или маса система е в противоречие.

CheckDB зависи от няколко маси критични системни, за да получите представа за това какво трябва да бъде в базата данни. Ако все пак тези таблици са повредени, CheckDB не може дори да си представим това, което трябва да бъде в базата данни и нещо, което да се сравни настоящата ситуация, да не говорим за факта, за да се определи нещо.

Увреждане на "разпределението на карти"

Msg 8946, Level 16, членка 12, Линия 1
Таблица грешка: стр разпределение (1: 2264640) има невалидни стойности колекторни PFS_PAGE страница. Типът е 0. Проверете тип, Alloc единица ID и идентификационния номер на страницата на страницата. Msg 8998, Level 16, държавен 2, Линия 1
грешки на страниците на GAM, SGAM или PFS Page предотвратят проверки за разпределяне на интегритет в ID база данни 13 страници от (1: 2264640) (1: 2272727)

В този случай, една или повече страници, които определят местоположението на данните в база данни (карта разпределение -. Прибл преводачи) Повредени. Тези страници са използвани, за да се определи кои страници и степен се използват в базата данни, и които са безплатни. CheckDB не могат да се коригират тези грешки, защото това е практически невъзможно да се определи (без тези страници), който степен се използват за данни, както и кои не са. Лесно премахване на такова невъзможно "разпределение карта", тъй като отстраняването на който и да е от тях води до премахване на 4 GB на данни.

помощ при търсенето

Ако не сте сигурни, че трябва да направя - да помоли за помощ. Ако изведнъж получите съобщение за повреда на база данни, която не разбирате и което не е описано по-горе - помоли за помощ. Ако не сте сигурни какво да изберете най-добрият метод за възстановяване - помоли за помощ.
Ако имате Старши DBA, обърнете се към него. Ако имате "ментор" - го попита. Поискайте съвет във форумите, но не забравяйте, че не всички съвети, получени във форумите полезни. В действителност, тя е там от време на време публикува абсолютно погрешни и дори опасни решения.
Свържете се с Microsoft за поддръжка на клиенти най-сетне. Това не е безплатно, но те наистина знаят какво можете да направите, ако е повредена база данни, и е вероятно, че ако вашата база данни е от решаващо значение за компанията, цената на престой по време на разтвора за самостоятелно търсене, ще бъде много по-висока от цената на лечението в подкрепа.

заключение

В тази статия, аз дадох няколко примера за това какво можете да направите, когато открие повреден база данни, а още по-важното е, какво да не правим. Надяваме се до сега най-добре да разберем какви методи могат да бъдат използвани за решаване на проблемите, описани по-горе, и колко е важно да има добри резервни копия (и правилно да изберете модел на възстановяване -. Прибл интерпретатор).