Ваша е отговорността като DBA, вероятно включва оптимизация на производителността, възстановяване, за определяне на правата за достъп, и така нататък. Но много от тях са склонни да забравят за такава важна работа като проверка на целостта на базата данни (DBCC CHECKDB). Можете да се реши този проблем, просто чрез създаване на план за поддръжка «» Проверете Database почтеност Task », но това е само checkdbox.
Както можете да видите, тук ние почти не може да се контролира всичко, но за тази операция, има много интересни ключове. Мисля, че трябва да се потопите в по-големи подробности в DBCC CHECKDB и да създадете свой собствен подходящ за вас, тази работа. Основното предимство на собствената работа ще бъде да се намали времето за работа и като следствие намаляване на ресурсите, необходими за операцията. Същото може да бъде предимства като гъвкавост, управляемост, обработка на грешки, и така нататък.
Намаляването на производството и събирането на всички грешки:
Без значение къде тече CHECKDB, винаги започват с вариант с NO_INFOMSGS. Тази проста опция потиска всички информационни съобщения, които просто ще ви покажат как много редове във всяка таблица, ако имате нужда от тази информация, можете да го получите от DMV, е CHECKDB команда.
Използвайте само физическата проверка на данните за производствената среда:
В повечето случаи, CHECKDB прекарва по-голямата част от времето на валидирането на логическата данни. Ако имате възможност за провеждане на този тест за надеждно копие на данни, можете да се съсредоточите само върху физическата структура на вашия продуктивна система. Под автентичен екземпляр на данните, аз разбирам, да възстановите само данни от резервно копие на друг сървър.
Такива методи като:
- AlwaysOn Наличност Групи
- Моментна снимка на върха на базата данни отразявайки
- влезете Доставка
- И така нататък.
не е надежден копие на данните и логическа проверка на тези технологии, няма да даде надеждни резултати по отношение на производствената среда. Просто точно едно и също копие на базата данни може да бъде точна.
Експерименти с следа знаме 2549, 2562 и 2566:
Открих, че знамената следи 2549 и 2562 могат да подобрят ефективността CHECKDB. Намери описанието на тези флагове могат да бъдат в KB # 2,634,571. но като цяло:
Трейс Flag 2549 (оптимизира процеса на проверка на изчисленията, че всеки файл с данни на базата данни е само по себе си диск. Знамето може да се използва, когато базата данни, има файл с данни или файл с данни е на вашето устройство, в противен случай тя може да намали производителността на CHECKDB)
Ако решите да използвате тези знамена, а след това аз силно препоръчвам да ги превръщат използване DBCC TRACEON, а не чрез стартиране на SQL Server параметри на. Това ви позволява да изключите знамената без рестартиране.
Намаляване на натоварването на дисковата подсистема (оптимизация tempdb):
DBCC CHECKDB може силно зареди tempdb, опитайте се да се разпределят за тази база данни има достатъчно ресурси (тестване).
Намаляване на натоварването на диск подсистема (снимка):
Стартиране DBCC CHECKDB, модерни версии на SQL Server създава скрита моментна снимка на вашата база данни на същото устройство (или на един и същи диск, ако използвате няколко tempdb файлове). Не можете да контролирате този механизъм, но ако искате да се уточни къде точно трябва да създадете моментна снимка, можете да направите своя снимка на всеки диск (достъпно само в Enterprise Edition) и стартирайте DBCC CHECKDB на моментна снимка. Най-добре е да използвате този метод в периода на минимална активност на пост-актуализация на базата данни.
Можете да се ускори DBCC CHECKDB тя работи в офлайн режим (с ключалки), като използвате опцията С TABLOCK. Горещо препоръчвам да не я използват, тъй като тя значително се влоши наличността на базата данни.
Намаляване на натоварването на процесора:
DBCC CHECKDB се провежда успоредно с режима по подразбиране, но само ако имате Enterprise Edition. Ако имате достатъчно ресурси на процесора, можете да намалите припокриване по няколко начина:
Чрез съжаление, Microsoft не планира да приложи използването MAXDOP да CHECKDB, въпреки че многократно е поискана.
Моите резултати:
CHECKDB води срещу 7 база данни GB
След това се увеличава размера на базата данни до 70 GB и отново се затича на изпитванията:
CHECKDB води срещу 70 GB данни
Основните мисли след тестовете:
- Когато стартирам DBCC CKECKDB логически тест за борба сървъра:
- На малка база данни NO_INFOMSGS опция може значително да намали времето за изпълнение, когато работи в SSMs. На големи бази данни ефект се намалява.
- И двете следа флаг имаше значителен ефект върху изпълнението на DBCC CHECKDB (40% -60%, когато се използва заедно)
- Когато стартирам DBCC CKECKDB логическата изпитанието на вторичната:
- Аз намалено време за пробег от 70-80% в борбата срещу системата.
Бих искал да покаже на натоварването на процесора по време на vremyaDBCC CHECKDB:
въздействие на процесора по време на CHECKDB - пробата режим
въздействие на процесора по време на CHECKDB - исторически режим
На големи резултати на базата данни може да са различни, така че трябва да проведе свой собствен тестване.
заключение:
DBCC CHECKDB е много важен и често се подценява DBA задача. Не правете грешката да друг DBA.
Свързани статии