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

За да се сведе до минимум появата на такива ситуации се създадат планове за поддръжка на целите за осигуряване на стабилност и оптимална работа на базата данни.

Сред тези задачи са следните:

Помислете за реда на автоматизиране на всяка една от тези задачи.

Така че, първата точка ...

В допълнение към файловата система разпокъсаност и лог файл, значителен ефект върху производителността на базата данни, има фрагментацията в рамките на файлове с данни:

1. Фрагментация в рамките на отделните страници индексни

След вмъкване, обновяване и изтриване на записи са длъжни да възникнат празно място в страниците. Нищо лошо в това, защото ситуацията е съвсем нормално, ако не една, а ...

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

За да се справят с този вид фрагментация стои на сцената на проектирането на веригата, т.е.. Е. За да изберете тези типове данни, които биха се поберат на компактни страници.

2. Фрагментация в рамките индексни структури

Основната причина за този тип фрагментация - страница операция разделяне. Така например, в зависимост от структурата на първичния ключ, нов ред трябва да се включат в определен индекс страница, но тази страница не е достатъчно пространство за настаняване на въведените данни.

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

Във всеки случай, фрагментация води до увеличаване на броя на страниците, за съхраняване на едно и също количество информация. Това автоматично увеличава размера на базата данни и да се увеличи неизползваното пространство.

Когато стартирате заявка в които има позоваване на индексите на фрагментация, тя изисква повече операции IO. В допълнение, фрагментация налага допълнителни разходи за много памет на сървъра, който трябва да се съхранява в допълнителни страници за кеш.

За да се избегне фрагментирането на арсенала на команда SQL Server-условие да се реорганизират и възстановяване на индексите.

Преструктурирането включва отстраняването на стария индекс и създаването на нов екземпляр на индекса, при които данните на страниците леко сгъстен и организирана, колкото е възможно непрекъснато, колкото е възможно. Трябва да се отбележи, че операцията за възстановяване на индекса е много скъпо.

Ето защо, когато фрагментация е ниска, за предпочитане е да се реорганизира съществуващата индекса. Тази операция изисква по-малко системни ресурси, отколкото индекс възстановяване и оздравяване е страници листа на ниво. Освен това, ако е възможно реорганизация компресира индекс страница.

Степента на фрагментация на конкретен индекс може да бъде получена от динамичната система представяния sys.dm_db_index_physical_stats:

В тази заявка, последния параметър определя режим, стойността на които може да бъде бързо, но не съвсем точно определяне на нивото на индекса на фрагментация (ограничен / NULL режими). Затова е препоръчително да попитам ИЗВАДКА / ПОДРОБНИ режими.

Ние знаем как да получите списък с разпокъсани индекси. Сега е необходимо за всеки от тях, за да генерира съответен ALTER INDEX команда. Традиционно, това е направено с помощта на курсора:

За да се ускори процеса на възстановяване на индекс, се препоръчва да се допълнително да посочите опции SORT_IN_TEMPDB и онлайн.

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

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

В допълнение, по-горе заявка може да бъде пренаписана, без използването на курсора:

В резултат на това двете заявки ще генерират, когато исканията за дефрагментиране индекси проблематично:

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

Това се дължи на факта, че може да има (и трябва да бъде) тригери, които се задействат чрез промяна на някои таблетки. Например, има маса с ръчен - SPR, в много области директория. Как мога да следите този конкретен потребител точно какво се е променило? Направи спусъка, което би spr_his маса за написването на всички промени.

1) Е, и тук възстанови индексите? Кой спря да възстанови индекси в присъствието на спусъка, не мисля, че това ще бъде задействано в същото време? )
2) предизвиква трябва нищо на никого. Е, с изключение, че имате 2-Zvenkov. И аз имам всички промени на данните в базата от данни преминават през слой от сървъра на приложения, както и излезли (заявка), ако е необходимо.

С онлайн = ON. Втората опция ви позволява да създадете отново индекса не блокира заявките до обекта, за който е създаден на индекса. Тук са предназначени само SELECT запитвания.
2) Това е въпрос на вкус. За мен, логиката на централизирано съхранение е много по-удобно / практически / по-бързо обслужване и т.н. и т.н. Само едно и също ", hranimki" не трябва да се прилага навсякъде, но само там, където това е необходимо / необходимо / по-лесно.

Не мога да понасям. Ти извади тази фраза от контекста в параграфа за изпълнение. Там току-що каза, че ресурсите UPDATE / INSERT / изтриване прекарва много повече. Знаеш ли защо? Тъй като всички тези искания са наредени на опашка в буфер и едва тогава индекса наново, тези промени са направени в базата данни. Следователно, използването на тази опция може значително натоварването на сървъра.

позволете ми да попитам: при какви проект е взел толкова справят база и какво е неговото тегло на диска?
PS: в кабинета си даде максимален ефект на нормален диск инсталация рафтове (партиди на вретена, чифт контролери, кеш паметта на батерията от нападението.). Всеки дефрагментиране индекси и статистика пречистване даде увеличение на производителността на стойност годни за рамка грешки. MSSQL сървър за 1C

Вероятно не е важно размер база, както и размерът на отделните таблици. които са големи и неприятна особеност - данните, често ги променят. Тя е за тези таблици - това е препоръчително да се направи дефрагментирате индекси.

Времето, посочено в часовата зона, която е монтирана в устройството.