Наша команда-партнер Artmisto
Ключавой індыкатар прадукцыйнасці (далей KPI) базы дадзеных з'яўляецца адзіным паўнавартасным паказчыкам, здольным ацаніць агульную прадукцыйнасць базы на ўзроўні кіравання на працягу часу.
Аднастайнасць з'яўляецца крытычным фактарам у ацэнцы любога KPI. Вызначэнне базавага ўзроўню, а затым пастаяннае паўтарэнне абсалютна таго ж вымярэння з'яўляецца адзіным спосабам выяўлення тэндэнцый і ацэнкі вынікаў аптымізацыі. Пры гэтым тэсты павінны паўтарацца праз рэгулярныя прамежкі часу.
Ключавой індыкатар прадукцыйнасці павінен параўноўваць дадзеныя, атрыманыя ў "чыстай" тэставай асяроддзі, а таксама фактычныя дадзеныя, прымаючы пад увагу эфект маштабавання сістэмы. Каб атрымаць рэальны індыкатар KPI, каманда распрацоўшчыкаў павінна прад'явіць асаблівыя патрабаванні да тэстаў і метадам вылічэнні. Я рэкамендую маштабаваць вынікі трох паслядоўных тэстаў, каб атрымаць у выніку кожнага адну траціну і каб іх сума, г.зн. першапачатковая паўнавартасная метрыка, складала адзінку, як паказана на працоўным аркушы і дыяграме мал. 49.7.
Puc. 49.7. Ключавой індыкатар прадукцыйнасці вылічаецца на аснове трох тэстаў у праграме Excel
Паўнавартасная метрыка прадукцыйнасці базы дадзеных у выглядзе рабочай кнігі Excel даступная на сайце кнігі.
Перыядычнае тэставанне прадукцыйнасці
Пры перыядычным тэставанні вымяраецца прадукцыйнасць базы дадзеных у рэальных умовах на аснове сцэнарыя і базы дадзеных, створаных на этапе тэставання. Час выканання можа рэгістравацца ў зменных Т-SQL, а таксама ў праграме SQL Server Profiler.
Калі архітэктура выкарыстоўвае ўзровень абстракцыі дадзеных, то ўсе выклікі тэстаў павінны выконвацца менавіта да яго. Калі ж база дадзеных выкарыстоўвае больш незвычайны падыход з дапамогай мадэлі "кліент / сервер", то пры тэставанні прыйдзецца змешваць розныя запыты. Калі база дадзеных выкарыстоўвае архітэктуру, арыентаваную на Web-службы, натуральна, спатрэбяцца запыты менавіта да гэтых службам. Для балансавання аперацый здабывання і абнаўлення дадзеных для табліц спатрэбіцца стварыць досыць прадстаўнічую выбарку, якая ўлічвае асаблівасці кліенцкіх прыкладанняў і пакетных працэсаў.
Першапачатковае выкананне паўтаральнага тэсту прадукцыйнасці ўсталёўвае базавую лінію вымярэння. Пры кожным наступным выкананні тэсту зыходная база дадзеных аднаўляецца і запускаецца зыходны сцэнар. Паўтаральны тэст прадукцыйнасці найбольш карысны для ацэнкі вынікаў аптымізацыі ў "чыстай" асяроддзі - г.зн. неподверженность іншым працэсам, недаступнай іншым карыстальнікам і зменам дадзеных.
На хуткасць водгуку сістэмы ўплываюць шматлікія фактары. Каб ацаніць, які з іх ўплывае на канкрэтнае змяненне прадукцыйнасці, варта ў кожным тэсце змяняць толькі адзін з іх, пасля чаго вымяраць час водгуку некаторым аднолькавым метадам. Кожны запуск тэсту прадукцыйнасці павінен пачынацца з адных і тых жа дадзеных, а сервер, які выкарыстоўваецца для тэставання, павінен быць вольны ад якіх-небудзь іншых працэсаў, падлучэнняў і карыстальнікаў.
Вы можаце запускаць два тэсту: адзін для аднакарыстальніцкай, а іншы для шматкарыстальніцкай асяроддзя пры наяўнасці канкурэнцыі, пры гэтым адначасова запускаючы некалькі асобнікаў выдатных тэстаў. Гэтыя тэсты павінны ўяўляць сабой камбінацыю аперацыі чытання і запісы, генерацыі даных для справаздач і масавых абнаўленняў, як мага бліжэй імітуюць рэальную сераду эксплуатацыі базы дадзеных.
Для тэставання сцэнара шматкарыстальніцкага рэжыму лепш напісаць прыкладанне .NET, якое стварае мноства падлучэнняў і зваротаў да базы дадзеных і такім чынам якое імітуе інтэнсіўную загрузку. Чым дакладней гэтая нагрузка (колькасна і якасна) адлюстроўвае запыты рэальных карыстальнікаў, тым лепш тэставанне. Не забывайце, што не ўсе канкурэнтныя карыстальнікі загружаюць базу дадзеных у кожны момант часу. Вынікам гэтага тэсту павінна стаць колькасць транзакцый, якія здольная падтрымліваць база дадзеных.
Каб ацаніць неабходную колькасць транзакцый, я некаторы час прысвячаў назіраннях і даследаваннях (шпацыраваў па арганізацыі і запісваў, якое колькасць карыстальнікаў і які тып задач яны выконваюць, а таксама як часта гэтыя задачы выконваюцца).
Збор дадзеных прадукцыйнасці
Вымераючы рэальны час водгуку захоўваемых працэдур ўзроўню абстракцыі дадзеных, тэст прадукцыйнасці ў вытворчай асяроддзі збірае інфармацыю аб дзейнасці карыстальнікаў.
Дадзеныя аб прадукцыйнасці ў вытворчай асяроддзі можна збіраць некалькімі спосабамі.
? SQL Server Profiler можа ажыццяўляць трасіроўку на боку сервера і збіраць час выканання ўсіх захоўваемых працэдур. Трасіроўкі могуць запісвацца ў базу дадзеных і аналізавацца для тонкай налады прадукцыйнасці або атрымання дадзеных аб рэальнай загрузцы. Такую трасіроўку лёгка запусціць і спыніць, што дае вам поўную свабоду ў выбары часу правядзення вымярэнняў.
? Праграмны код у канцы кожнай захоўваемай працэдуры можа вылічаць працягласць яе выканання і запісваць вынік у часопіс для далейшага аналізу. У залежнасці ад канфігурацыі трасіроўкі у праграме Profiler, гэты метад, хутчэй за ўсё, дасць вам менш дэталяў, чым сам SQL Server Profiler. У залежнасці ад складанасці кода пратакалявання, узнікае яшчэ адна праблема, звязаная з гэтым метадам: такое пратакаляванне досыць складана адключыць, калі вы вырашылі праводзіць вымярэння толькі на працягу некалькіх гадзін або дзён.
? Праграмны код прыкладання можа пратакаліраваць інфармацыю ад часу пстрычкі карыстальнікам на кнопцы адпраўкі формы да завяршэння абнаўлення формы. Нягледзячы на тое што гэты метад дае поўную карціну рэальнай дзейнасці карыстальнікаў, ён прадастаўляе найменшы аб'ём інфармацыі, неабходнай для налады.
У той час як усе прадстаўленыя метады накладваюць на базу дадзеных дадатковую нагрузку і існуе мноства зменных велічынь, я лічу, што SQL Server Profiler забяспечыць вас лепшай інфармацыяй з мінімальнымі выдаткамі.
Тэставанне ўплыву маштабавання на прадукцыйнасць
Гэты выгляд тэсту з'яўляецца ўсяго толькі варыяцыяй рэгулярнага тэсту эфектыўнасці. Яго мэтай з'яўляецца праверка межаў маштабавання і карыснасці базы дадзеных у будучыні. Магчымасці маштабаванасці базы дадзеных вымяраюцца шляхам вымярэння часу водгуку пры поўнай чаканай загрузцы і паловай загрузцы. Для пашырэння першапачатковых працоўных табліц генеруюцца новыя дадзеныя, каб падвоіць бягучы працоўнае колькасць радкоў. Колькасць канкурэнтных карыстальнікаў можна таксама падвоіць у дадатку .NET. Пасля таго як база дадзеных была пашырана, выконваецца паўтаральны тэст.
У SQL Server схема базы дадзеных і запыты могуць тэставацца на загрузку толькі тады, калі аб'ём дадзеных пераўзыходзіць ёмістасць памяці сервера ў некалькі разоў. Паводзіны індэксаў адрозніваецца, калі SQL Server мае магчымасць загрузіць усе неабходныя старонкі дадзеных і індэксаў ў памяць. Калі ўсе гэтыя старонкі знаходзяцца ў памяці, лагічныя чытання становяцца адзіным істотным фактарам. Бо пры гэтым не выкарыстоўваюцца фізічныя звароту да дыска, прадукцыйнасць саміх індэксаў становіцца практычна неістотнай.
СКБД SQL Server аптымізавана для інтэлектуальнага кэшавання дадзеных
На нататку ў памяці, што ўплывае на наступныя тэсты. Памяць можа быць папоўненая з дапамогай прыпынку і перазапуску сервера, а таксама з дапамогай каманд dbcc DropCleanBuffersИ DBCC FreeProcCache.
У пакет абнаўленняў SP1 былі дададзены новыя дынамічныя прадстаўлення Увага! кіравання, якія выконваюць маніторынг вылучэння памяці для запытаў, -
sys.dm_exec_query_memory_grants і sys.dm_exec_query_resource_ semaphores.
У прыкладах стварэння ключавых індыкатараў прадукцыйнасці базы дадзеных вы можаце выкарыстоўваць базу PerfTest, даступную на сайце кнігі.
рэзюмэ
Вымярэнне прадукцыйнасці з'яўляецца галоўным аспектам налады і аптымізацыі базы дадзеных. Для вымярэння агульнай прадукцыйнасці базы дадзеных ваша арганізацыя можа выкарыстоўваць ключавыя індыкатары прадукцыйнасці (KPI), а для яе аптымізацыі спатрэбяцца дэталёвыя паказчыкі эфектыўнасці, здольныя дапамагчы ідэнтыфікаваць праблему і ліквідаваць яе. Праграмы SQL Server Profiler і System Monitor, разам з новымі дынамічнымі ўяўленнямі кіравання, дае вам дэталёвую інфармацыю аб прадукцыйнасці базы дадзеных.
Асвоіўшы метады назірання за эфектыўнасцю аптымізацыі, у наступным раздзеле мы вывучым наладу ключавых сродкаў SQL Server - запытаў і індэксаў. Дзякуючы сродкам вымярэння і ўменню наладжваць запыты і індэксы вы зможаце ствараць высокапрадукцыйныя базы дадзеных.
Аналіз запытаў і налада індэксаў
Асноўныя прынцыпы інфармацыйнай архітэктуры, выкладзеныя ў главе 1, абвяшчаюць, што галоўная перадумова да планавання любых сховішчаў дадзеных - гэта азнаямленне з патрабаваннямі да прадукцыйнасці.
Тэорыя аптымізацыі праклала шлях да дасягнення гэтай мэты і заклала падмурак для праектавання высокапрадукцыйных баз дадзеных, выявіўшы залежнасці паміж рознымі ўзроўнямі аптымізацыі.
Індэксах тэорыя аптымізацыі адводзіць сярэдні ўзровень. Яны залежаць ад якасці праектавання нармалізаваць схемы і запытаў. Без гэтых двух складнікаў складана чакаць ад індэксацыі добрых вынікаў.
Няма ніякіх сумневаў, што індэксацыя жыццёва важная для высокай прадукцыйнасці базы дадзеных. На індэксы варта глядзець з перспектывы агульнай мадэлі базы. Яны залежаць ад узроўняў схемы і запытаў і ў той жа час забяспечваюць наладу маштабаванасці і канкурэнцыі сервера.
Аналіз запытаў і налада індэксаў з'яўляюцца вобласцю, у якой СКБД SQL Server 2005 атрымала поспех. Сервер дае шырокую інфармацыю аб плане выканання запыту, яго індэксы хуткія, будуюцца па алгарытме збалансаванага дрэва, іх лёгка наладжваць, і нават без усялякай налады яны выдатна працуюць.
Крыніца: Нільсэн, Пол. Microsoft SQL Server 2005. Біблія карыстальніка. : Пер. з англ. - М.: ТАА "І.Д. Вільямс ", 2008. - 1232 с. : Іл. - пару. Ціт. англ.
