Тэорыя аптымізацыі і SQL Server

Спытаеце дваццаць адміністратараў баз дадзеных аб іх любімых метадах і стратэгіях аптымізацыі, і яны вам раскажуць аб індэксацыі, даданні дадатковай памяці і многае іншае. Ці можна упарадкаваць масу разнастайных падыходаў да аптымізацыі? Хутчэй за ўсё, няма. Ці можна скласці некаторую мазаіку з разнастайных стратэгій, правяраючы пры гэтым, як адна з іх суадносіцца з другога?

Першае, што можна сказаць, - не варта ўжываць усе вядомыя стратэгіі, таму што многія з іх маюць ўнутраныя і абыдзеных увагай залежнасці. Напрыклад, выкарыстанне індэксацыі для павышэння хуткасці вымання дадзеных павялічыць час выканання транзакцый, што звязана з канкурэнцыяй. Такім чынам, мы бачым непасрэдную сувязь паміж індэксацыяй і канкурэнцыяй. Можна знайсці значна больш перасячэнняў. Адны стратэгіі павышэння прадукцыйнасці можна ўжываць непасрэдна, а эфектыўнасць іншых наўпрост залежыць ад таго, ці былі перад гэтым ужытыя іншыя.

Тэорыя аптымізацыі даследуе гэтыя залежнасці і прапануе сераду планавання і распрацоўкі аптымізаванага сховішчы дадзеных (мал. 1.3). Кожная з гэтых стратэгій мае некалькі канкрэтных методык і актывізуецца з дапамогай якая падтрымлівае яе стратэгіі, але ні адна стратэгія не здольная пераадолець недахопаў якія падтрымліваюць яе стратэгій.

мадэль схемы

Маёй галоўнай стратэгіяй павышэння прадукцыйнасці з'яўляецца дбайная распрацоўка схемы. Добрая схема дазволіць прымяняць пакетныя запыты і аблегчыць планаванне індэксаў.

Каб стварыць эфектыўную схему, прытрымлівайцеся наступным радам:

? пазбягайце празмернай складанасці;

? старанна выбірайце ключы;

? сочыце за неабавязковымі дадзенымі;

? выкарыстоўвайце некаторы ўзровень абстракцыі.

Я ўпэўнены, што дрэнная мадэль дадзеных - галоўная прычына дрэнны прадукцыйнасці; гэтыя праблемы каскадам спараджаюць іншыя. У выніку базу дадзеных можна лічыць "мёртванароджаных".

Мал. 1.3. Тэорыя аптымізацыі абвяшчае, што кожная стратэгія залежыць ад іншай і актывізуецца ёю

запыты

SQL з'яўляецца пакетнай сістэмай запытаў, і итеративные парадковай аперацыі на самай справе функцыянуюць, як маса маленькіх однострочный пакетаў. Калі итеративный метад рэалізаваны з дапамогай сервернага курсора або цыклаў ADO, паслядоўны код будзе даволі затратны. Мая другая стратэгія павышэння прадукцыйнасці - выкарыстанне пакетных рашэнняў. У той жа час нават пакетная апрацоўка не зможа пераадолець недахопы дрэнны або залішне складанай мадэлі схемы.

Пры прыняцці рашэння адносна выкарыстання паслядоўнага кода або пакетных запытаў азнаёмцеся з табл. 1.4 - яна паслужыць добрым кіраўніцтвам да дзеяння.

Табліца 1.4. метады праграмавання

задача

лепшае рашэнне

Складаная бізнес-логіка

Запыты, подзапросов, сце

Дынамічнае генераванне DDL Курсоры

перабудова спісу

Пераменныя або курсор

перакрыжаваная табліца

Запыт з прапановай pivot або case

Праходжанне па іерархіі

Карыстацкая функцыя або сце

назапашвальныя сумы

курсор

Дадатковая У разьдзеле 20 вы даведаецеся, як істотна павысіць прадукцыйнасць, преоб- | інфармацыя разу складаныя лагічныя курсоры ў пакетныя запыты.

індэксацыя

Індэксацыя ў пытаннях прадукцыйнасці з'яўляецца мостам паміж запытамі і дадзенымі і адначасова ключавой стратэгіяй павышэння прадукцыйнасці. Стратэгія, выкарыстоўваная ў кластеризованных азначніках для скарачэння выпадковага пошуку і групоўкі радкоў у адну старонку дадзеных, выкарыстоўвае некластеризованные індэксы для забеспячэння работы запытаў і актывізацыі пошуку і пры гэтым пазбягае залішніх індэксаў, што можа істотна паскорыць выкананне пакетаў. Аднак нават добрыя індэксы не змогуць выратаваць ад немасштабируемых праграм.

Дадатковая Стварэнне кластеризованных, некластеризованных і іншых індэксаў дэталёва інфармацыя апісана ў раздзеле 50.

канкурэнцыя

Блакіроўка - гэта больш складаная праблема, чым думаюць большасць распрацоўнікаў, і большасць адміністратараў баз дадзеных вымушаныя вырашаць яе шляхам паніжэння ўзроўню ізаляцыі транзакцый да no lock, што вельмі небяспечна.

Канкурэнцыю можна параўнаць з крыніцай вады. Калі людзі, важна шпацыруючы, чакаюць сваёй чаргі напоўніць шкляначкі, сітуацыя стабільная. Ўстаноўка параметру nolock раўнасільная прызыву: "Усё кідайцеся да крыніцы!" Натуральна, у гэтым выпадку сітуацыя выйдзе з-пад кантролю і цісканіна непазбежная. У такой сітуацыі лепш паслядоўна наліваць ваду ў шкляначкі, пры гэтым скарачаючы час свайго знаходжання ў крынiцы. Аналагічная сітуацыя і ў базах дадзеных: лепш абмежавацца невялікімі запытамі або скараціць час выканання транзакцый. А для стварэння эфектыўных транзакцый трэба распрацаваць эфектыўную схему, выкарыстоўваць пакетны код і індэксы.

Пасля таго як схема, запыты і індэксы скарацілі час выканання транзакцый, пакіньце ў лагічных транзакцыях толькі сапраўды неабходную логіку і будзьце асцярожныя з логікай у трыгера, так як яна ўсё роўна будзе задзейнічана ў транзакцыях. У той жа час скарачэнне блакіраваных рэсурсаў не зможа прадухіліць залішняя сканаванне табліц.

пашыраная маштабаванасць

Калі схема, запыты, індэксы і транзакцыі працуюць на славу, вы можаце скарыстацца палепшанымі сродкамі маштабаванасці SQL Server:

? ізаляцыяй імгненных здымкаў;

? падзелам табліц;

? індэксавацца ўяўленнямі;

? брокерам службаў.

Вам здаецца, што вы дамагліся добрай прадукцыйнасці без выкарыстання гэтых тэхналогій? Магчыма. Аднак найлепшых вынікаў вы даможацеся, выкарыстоўваючы тэхналогіі кожнага з гэтых кампанентаў.

Тэорыя аптымізацыі, у якой раскрытыя залежнасці паміж рознымі тэхналогіямі аптымізацыі, з'яўляецца рэвалюцыйнай канцэпцыяй. Самую свежую інфармацыю аб тэорыі аптымізацыі, а таксама мае прэзентацыі рашэнняў павышэння прадукцыйнасці вы знойдзеце на сайце www. SQLServer Bible. com.

рэзюмэ

Прынцыпы інфармацыйнай архітэктуры з'яўляюцца асновай распрацоўкі баз дадзеных. Гэтыя прынцыпы раскрываюць сем ўзаемазалежных правілаў арганізацыі сховішчаў дадзеных: прастата, карыснасць, цэласнасць дадзеных, прадукцыйнасць, даступнасць, маштабаванасць і бяспека. Кожнае з гэтых правілаў выключна важна пры праектаванні любой базы дадзеных.

Такім чынам, у частцы I кнігі працягваецца выклад асноўных канцэпцый баз дадзеных. У наступным раздзеле мы разгледзім структуру рэляцыйных баз дадзеных.

Крыніца: Нільсэн, Пол. Microsoft SQL Server 2005. Біблія карыстальніка. : Пер. з англ. - М.: ТАА "І.Д. Вільямс ", 2008. - 1232 с. : Іл. - пару. Ціт. англ.