размер на база данни, индекс фрагментация и наличност след срив - това е, което има значение, заинтересованите администратори този месец.
Пол С. Рандъл
Бъдете внимателни, не до фрагментация
Въпрос: Аз прочетох няколко публикации в блога, което изглежда да се предполага, че ние не трябва да се грижи за индекса на фрагментация в бази данни, хоствани на твърдотелни (SSD) дискове, тъй като те са много по-бързо в сравнение с конвенционалните твърди дискове. Правилно ли съм разбрал, че спадът на изпълнението е спряно, но ако можех да се игнорира индекс фрагментация?
Независимо от отговора дискове - конвенционален или твърдо състояние, трябва да се наблюдава много внимателно фрагментацията. Фрагментация индекси, свързани с две явления - неподредени страници индекс и проблеми страници плътност. Първият феномен намалява ефективността на четене напред при сканиране диапазони, а вторият намалява плътността на данни.
Вярно е, че забавянето на SSD дискове за четене и писане е много малък. Следователно, необходимостта от по-чести и по-малки входно / изходни операции, причинени от индекс фрагментация, не са толкова силен ефект върху производителността, като в конвенционалните твърди дискове.
Въпреки това, намаляването на плътността на данните поради разпокъсаността на индекса все още може да бъде проблем. фрагментация индекс се дължи най-вече по отношение на операциите, които се наричат "разчупване на страницата." Фактът, че новият свободно пространство на страницата, се формира чрез прехвърляне половина редовете на индекса към нова страница. В този случай, стари и нови страници са пълни до около половината. В случай на високо фрагментацията на индекса е много често се случва, че средната страница плътност от 70% или по-малко (т.е., страница 30% от свободното пространство).
Това означава, че ако имате голям брой индекси вашите бази данни, скъпи SSD дискове за съхранение на големи обеми от празно пространство, то е ясно, че тази ситуация е далеч от оптималното. Също така, въпреки че допълнително входно / изходни операции, необходими на страниците на ниска плътност, не представляват значителен проблем в SSD дискове, те заемат повече място в буферния пул SQL Server на (файлове от кеша в паметта). Това също така означава, че паметта на скъпоценен сървър не е оптимално.
Освен кодовете за индексиране трябва да вземат под внимание на причината: страница разделя. Тя е по-скъпите операции, които генерират много данни за транзакции в списанието (в следващата ми публикация в блога да кажа колко често тя може да влоши ситуацията: блог пост тези допълнителни вписвания в дневниците, показват необходимостта от по-нататъшна преработка в който и да е компонент, прочетете регистър на транзакциите (например, транзакциите репликация, архивиране, огледални бази от данни, влезте доставка). Това може да доведе до намаляване на ефективността на тези процеси. Затова не бива да се пренебрегват фрагментация, дори ако използвате ЕТЕ бързи SSD дискове.
Не гледам в огледалото
В механизма на дублиране на база данни не поддържа абонамент за базата данни на огледало (от отразявайки публикувани база данни съществува Вход Reader агент). Въпреки това, можете да използвате "инициализира от LSN» метод, за да се гарантира бърза повторна инициализация след преминаване към системата за дублиране.
Тази техника се основава на определянето на регистрационния номер на най-скорошната сделка, операции за репликация се прилагат към базата данни на абонат, преди да продължите огледало. Ние ще наричаме това LSN2.
Някои операции са отразени в огледало база данни, преди да продължите. Това може, например, да създаде редица LSN3, което е малко по-нататък във времето, отколкото LSN2. Има и сделки, които не се отнасят за база данни на потребителите. Те са по-рано от LSN2 или LSN3. Наричаме ги LSN1.
Всички операции до LSN2 приложени към основната база данни, абонамент. Всички операции месо да LSN3 прилага към основната база данни, абонамент и копира в базата данни на огледало. За да извършите операцията инициализация на LSN за нов абонамент след прехода към огледалото като аргумент в sp_addsubscription трябва да преминат през LSN3.
твърде много
Размерът на издаване на нашия господар на базата данни е достигнал 9 TB. Оказа се, че ние просто не разполагат с достатъчно мощност, за да изпълнява редовна поддръжка, така че тя няма да се отрази текущата работа на предприятието. Преди всичко ние сме загрижени за архивиране на база данни, за да се даде възможност на възстановяване в случай на инцидент. Какво бихте посъветвали в тази ситуация?
Във всеки случай, основният въпрос е да се създадат множество файлови групи в базата данни. Разделяне на големи индивидуални секции на таблици или индекси са разположени в отделен файл групи. В ръчен дял всяка голяма маса се намира в отделен файл група (евентуално всички индекси).
При тези обстоятелства, възстановяването в случай на повреда също е по-бързо (ако редакция Enterprise Edition). Трябва само да се възстанови бързо от filegroups, които са необходими за OLTP системи. Можете да използвате частична реставрация, след което се използва частично достъпна база данни, за да се върнете в базата данни в интерактивен режим. Възстановяване на файлове групи, съдържащи по-стари данни могат по-късно, използвайки частично намаляване когато OLTP-операции, които вече са на разположение в файлови групи.
В условия на претоварване
Сама по себе си една стойност PLE малко информация. Трябва да погледнем стойностите на тенденцията. Възможно е, че тя е легитимна операция SQL Server ще доведе до значително намаляване на PLE свидетелство. четения често се връщат към нормалното. Ако четете PLE спада и остава ниско, а след това се притеснявате.
Прагът, в която искате да се отговори, а не фиксирана стойност, колко често пиша за това. Стойността на 300 означава, че цялата буферния пул се подменя на всеки 300 секунди. Ако имате група от 100 GB по размер, това означава, че 100 GB на нови данни се чете в памет на всеки пет минути. Има проблем с производителността. Въпреки това, тя се превръща в огромен проблем с производителността много преди PLE достига 300. Това е възможно да се изчисли по-разумна стойност (<размер буферного пула в ГБ> / 4) х 300, както е описано в следващите вписвания запис:
PLE е на тезгяха, за които трябва да се следват, но изявленията си имат значение, ако паднат значително под нормата и да остане дълго време в това положение. Това е обща препоръка, и то е, за съжаление, не е подходящо във всички ситуации.
Свързани статии