Мислите ли за нещо, когато създавате нова база данни? Предполагам, че повечето от вас биха казали не, тъй като всички използваме параметри по подразбиране, въпреки че те далеч не са оптимални. Въпреки това, има куп настройки на диска и те наистина помагат за повишаване на надеждността и производителността на системата.
Няма да говорим за значението на файловата система NTFS за надеждността на данните, въпреки че тази файлова система позволява на MS SQL Server да използва диска по най-ефективния начин.
Ако ви липсват ресурси и нещо започне да работи бавно, първото нещо, което ви идва на ум, е надграждането. Но не във всеки случай се изисква надграждане. Можете да се разминете с настройката, макар че това трябва да се прави не когато сървърът започне да работи бавно, а на етапа на проектиране и инсталиране.
Оптимизирането е сложен процес и често е свързан не само с определена програма (в нашия случай с определена база данни), но и с ОС и хардуер. Въпреки че ще говорим предимно за бази данни, не можем да пренебрегнем външните неща.
Архитектура на данните
SQL Server съхранява, чете и записва данни чрез блокове по 8 KB всеки. Тези блокове се наричат страници. Базата данни може да съхранява 128 страници на мегабайт (1 мегабайт или 1048576 байта, разделени на 8 килобайта или 8192 байта). Всички страници се съхраняват в определена степен. Екстентът е последните 8 последователни страници или 64 KB. По този начин 1 мегабайт съхранява 16 екстента.
Страниците и екстентите са основата на структурата на физическата база данни на SQL Server. MS SQL Server използва различни типове страници, някои от тях проследяват разпределено пространство, други съдържат потребителски данни и индекси. Страниците, които проследяват разпределеното пространство, съдържат плътно компресираните данни. Тя позволява на MS SQL Server ефективно да ги съхранява в паметта за лесно четене.
SQL Server използва два вида екстенти:
- Екстенти, които съхраняват страници от два до много обекта, се наричат смесени екстенти. Всяка таблица започва като смесена степен. Използвате смесена степен главно за страниците, които съхраняват място и съдържат малки обекти.
- Екстенти, които имат всички 8 страници, разпределени към един обект, се наричат униформени екстенти. Те се използват, когато таблица или индекс изискват повече от 64 KB.
Първият екстент за всеки файл е единен и съдържа страници от заглавката на файла, следващите екстенти съдържат по 3 разпределени страници. Сървърът разпределя тези смесени екстенти, когато създавате основен файл с данни и използва тези страници за своите вътрешни задачи. Заглавната страница на файла съдържа атрибути на файла, като името на базата данни, съхранена във файла, файлова група, минимален размер, размер на нарастване. Това е първата страница на всеки файл (страница 0).
План за изпълнение на заявка в SQL Query Analyzer
Свободно пространство за страница (PFS ) в разпределена страница, която съдържа информация за свободното пространство, налично във файла. Тази информация се съхранява на страница 1. Всяка такава страница може да се разшири до 8000 последователни страници, което е приблизително 64 Mb данни.
Регистърът на транзакциите събира цялата информация за промените, извършвани на сървъра, за да възстанови базата данни в момента на системна грешка и да осигури целостта на данните.
Имайте предвид, че всички числа са кратни на 8 или 16. Това е така, защото контролерът на твърдия диск чете данни с този размер по-лесно. Данните се четат от диска по страници, тоест по 8 килобайта, което е доста оптимална стойност.
Защита на страницата
От MS SQL Server 2005 сървърът на базата данни разполага с нова опция – контрол на данните на ниво страница. Ако AGE_VERIFY_CHECKSUM параметърът е активиран (по подразбиране е активиран), сървърът ще контролира контролните суми на страниците. Ако погледнем в ръководството за този параметър, ще видим, че контролната сума позволява проследяване на входно/изходните грешки, които ОС не може да проследи. Какви са грешките? Изглежда, че това са вътрешни проблеми на сървъра на базата данни.
Проверката на целостта на данните никога не се проваля, така че е по-добре да я активирате. За това трябва да изпълним следната команда:
ALTER DATABASE имя базы SET PAGE_VERIFY
Ако има грешка на страницата, сървърът ще ни уведоми за това. Но как да го поправим бързо? За това има опция за възстановяване на данни на ниво страница.
Графичен план за изпълнение
Разрастване на файла
Когато създаваме база данни, ще бъдем подканени да изберем първоначалния размер и метода на увеличение. Когато не ни достига текущото пространство, сървърът го разширява в съответствие с предварително зададения метод на увеличение.
Има три метода за увеличаване на файловете:
- Растеж в мегабайти.
- Ръст с проценти.
- Ръчен растеж.
Първите два метода се изпълняват автоматично, но се препоръчват само за тестови бази данни, тъй като администраторът няма контрол върху размера на файла.
Ако файлът се увеличи с определено количество мегабайти, в даден момент скоростта на вмъкване на данни може да се увеличи и нарастването на файла може да стане твърде често, а това е допълнителни разходи. Нарастването на файловете в проценти също е нерентабилно. Препоръчително е да използвате 10% ръст на файла и това е ОК за малки и средни бази данни. Но когато достигне 1000 гигабайта, ще изисква 100 гигабайта при всеки растеж. Това ще доведе до безсмислена загуба на дисково пространство.
Винаги контролирайте промените в размера на файловете и регистрационните файлове на транзакциите. Това ще ви позволи да използвате ресурсите на диска по най-ефективния начин.
Свойства на базата данни на MS SQL Server
Компресиране на данни
Твърдият диск остава разумно място на компютъра. Производителността на процесорите расте стремително, докато твърдите дискове не могат да предложат нещо ново. За да запазите броя на входно/изходните операции и да намалите данните, съхранявани на твърдия диск, можете да използвате дискове с компресия. Само такива дискове са добри за съхраняване на файлови групи само за четене. Може би, защото е необходима компресия за писане и изисква допълнителни разходи за процесор.
Компресирането на данни и състоянието само за четене са добри за архивните данни. Например счетоводните данни за последните години не са необходими за писане и могат да заемат твърде много място. Като поставите данни в архивния раздел на диска, ще спестите значително място.
Дискове за надеждност
Следният метод позволява едновременно повишаване на надеждността и производителността и отново е свързан с твърдите дискове. Е, ето го, механиката е не само най-бавната, но и най-ненадеждна. Що се отнася до надеждността, аз не събирах статистика, но и вкъщи, и на работа се занимавам предимно с твърди дискове.
Така че, за да увеличите производителността и надеждността, можете просто да използвате два или повече твърди диска вместо един. Още по-добре ще бъде, ако те ще бъдат свързани към отделни контролери. Можете да съхранявате базата данни на един диск, а регистрационните файлове за транзакции на друг. Ако има трети диск, той може да съхранява системата.
Съхраняването на данни и лог на отделни дискове ви позволява значително да увеличите надеждността. Да предположим, че имате всичко на един диск и то се срива. Какво да правя? Можете да стигнете до компания, която ще се опита да възстанови всичко или да опитате да направите същото сами, но шансът за възстановяване е далеч от 100%. Освен това връщането на сървъра обратно към работа може да отнеме значително време. Бързото възстановяване може да се извърши само до момента на последното архивно копие. Останалото е под въпрос.
И сега, да предположим, че имате данни и регистър на транзакциите на различни дискове. Ако дискът с регистрационния файл изгасне, данните все още ще бъдат там. Единственото нещо е, че не можете да добавяте нови данни, но ако създадете нов журнал, можете да продължите да работите.
Ако дискът с данни изгасне, ние все още можем да запазим дневника на транзакциите, за да предотвратим и най-малката загуба на данни. След това възстановяваме данните от пълното архивиране (това винаги трябва да се прави предварително, добър администратор го прави поне веднъж на ден) и добавяме промени от резервното копие на дневника.
Дискове за производителност
Ако данните и дневникът са разположени на отделни дискове, това означава не само безопасност, но и растеж на производителността. Работата е там, че сървърът на базата данни може едновременно да записва данни в дневника и файла с данни.
Можем да отидем по-далеч и да разпределим един твърд диск към регистъра на транзакциите и няколко твърди диска към данните. Сървърът работи по-често с данни, поради което изисква няколко хранилища, с които можете да работите едновременно. И ако тези хранилища са свързани към различни контролери, едновременната работа е гарантирана.
Най-бързият и надежден вариант е да използвате RAID . Въпреки това, не всеки RAID е надежден и бърз в същото време. За файловите групи се препоръчва да изберете RAID10 , тъй като съдържа добре балансирани функции, но в зависимост от данните от базата данни, можете да изберете друг вариант.
Можете да използвате софтуерно или хардуерно решение като RAID . Софтуерното решение е по-евтино, но изисква допълнителни ресурси на процесора. А процесорът няма резервни ресурси. Ето защо е по-добре да използвате хардуерни решения, при които специален чип отговаря за RAID .
Индекси
Всеки знае, че индексите помагат за увеличаване на скоростта на търсене на данни. Повечето от нас разбират, че индексите влияят негативно на вмъкването и актуализирането на данни, така че колкото повече индекси имате, толкова по-трудно е сървърът да ги поддържа. При това не много хора дори смятат, че индексите изискват поддръжка. Страниците на базата данни, съдържащи индексни данни, могат да препълнят и в крайна сметка да станат небалансирани.
Да, можем да игнорираме различни параметри и просто да пресъздаваме индекси веднъж месечно, което е подобно на поддръжката. SQL Server включва два параметъра, които предотвратяват остаряването на индекси половин час след създаването им:FILLFACTOR и PAD_INDEX .
Можете да използвате опцията FILLFACTOR, за да оптимизирате производителността на операциите за вмъкване и актуализиране, които съдържат клъстериран или неклъстериран индекс. Индексните данни могат да се съхраняват в много страници с данни. Както споменах по-горе, всяка страница се състои от 8 KB. Когато една индексна страница е пълна, сървърът създава нова страница и разделя страницата за вмъкване на данни на две.
Сървърът изисква време за разделяне на страницата и създаване на нова страница. За да оптимизирате разделянето на страницата, използвайте FILLFACTOR опция за определяне на процента свободно място на всички листа на индексната страница. Колкото по-голямо дисково пространство имат страниците на ниво лист, толкова по-рядко ще трябва да разделяте индексните страници. При това индексното дърво ще бъде твърде голямо и заобикалянето му ще отнеме допълнително време.
PAD_INDEX опцията показва процента на запълване на страниците без лист. Можете да използвате PAD_INDEX само когато FILLFACTOR опцията е посочена, тъй като процентната стойност на PAD_INDEX зависи от процента, посочен в FILLFACTOR .
Статистика
Статистиката позволява на сървъра да вземе правилното решение между използването на индекса и пълното сканиране на таблицата. Да предположим, че имате списък със служители на леярски цех. Такъв списък ще бъде съставен от приблизително 90% от мъжете.
Да предположим, че трябва да намерим всички жени. Тъй като няма много от тях, най-ефективният вариант ще бъде използването на индекса. Но ако трябва да намерим всички мъже, ефективността на индекса се забавя. Броят на избраните записи е твърде голям и заобикалянето на индексното дърво за всеки от тях ще бъде излишно. Много по-лесно е да се сканира цялата таблица – изпълнението ще бъде много по-бързо, тъй като сървърът ще трябва да прочете всички листа от ниско ниво на индекса веднъж, без да е необходимо многократно четене на всички нива.
SQL Server събира статистически данни, като чете всички стойности на полета или с шаблон за създаване на равномерно разпределен и сортиран списък със стойности. SQL Server динамично открива процента на редовете, които трябва да бъдат тествани въз основа на броя на редовете в таблицата. Когато събира статистически данни, оптимизаторът на заявки ще изпълни или пълно сканиране, или шаблони на редове.
За да работи статистиката, тя трябва да бъде създадена. В случай на масивна актуализация на данните статистиката може да съдържа неверни данни и сървърът ще вземе погрешно решение. Но всичко може да се оправи - трябва да следите статистиката. За по-подробна информация вижте книгите за Transact-SQL или MS SQL Server.
Резюме
Настройките по подразбиране не позволяват използване на целия потенциал на хардуера и работа с цялото разнообразие от сървъри. Отговорността за настройките е на администраторите. Фактът, че продуктите на Microsoft имат прости инсталационни програми, помощни програми за графично администриране и възможност за работа офлайн, не означава, че това е оптимален вариант.
Ние не разглеждаме такива опции за настройка на базата данни като хардуерно ускорение. Ако всички опции за настройка са изчерпани, по-добре е да помислите за надстройката, тъй като хардуерното ускорение се отразява негативно на надеждността на системата.
Най-важното е, че всяка оптимизация на сървъра на база данни или надграждане няма да помогне, ако заявките не са оптимизирани.
