Экономика стран

К сожалению, большинство людей, которые будут ими затронуты почти весь мир, не будут иметь никакого влияния на результат. Вести Экономика Дайджест иностранной прессы за 14 августа.
Вести Экономика Греции снова придется списывать долги Греция не сможет самостоятельно расплатиться по долгам, и понадобится новая реструктуризация долгов, чтобы спасти страну от банкротства.

Паскарэнне рэзервовага капіявання БД

  1. Скарачэнне часу рэзервовага капіявання
  2. Паралельнае выкарыстанне некалькіх дыскаў і файлаў.
  3. Выкарыстанне некалькіх сеткавых плат
  4. Рэкамендацыі па агульнай колькасці выкарыстоўваюцца файлаў
  5. Дадатковыя спосабы аптымізацыі і рэкамендацыі
  6. вялікія фрэймы
  7. BLOCKSIZE
  8. BUFFERCOUNT і MAXTRANSFERSIZE
  9. Сціск рэзервовай копіі
  10. Рэкамендацыі па апаратных сродках файлавых сервераў, прызначаных для захоўвання копій
  11. Настройка RAID-кантролера
  12. Настройка HBA
  13. Сістэмы на аснове NUMA
  14. Вылічэнне часу, неабходнага для рэзервовага капіявання і аднаўлення базы дадзеных
  15. заключэнне

Капіяванне двухтерабайтных базы дадзеных на лакальныя жорсткія дыскі і затым яе аднаўленне задавальняе часовым патрабаванням на аднаўленне нашай сістэмы SQL Server Капіяванне двухтерабайтных базы дадзеных на лакальныя жорсткія дыскі і затым яе аднаўленне задавальняе часовым патрабаванням на аднаўленне нашай сістэмы SQL Server. Аднак, гэты просты працэс не можа забяспечыць адэкватную абарону ад сцэнарыяў поўнага адмовы, фармалізаваных ў пагадненні SLA. З іншага боку, капіраванне базы дадзеных па сетцы ў выдаленае сховішча абарону ад поўнага адмовы забяспечыць можа. Праблему можа стварыць абмежаванні, што накладаюцца паласой прапускання сеткі, якое звычайна не перавышае звычайна 1 гігабіту у секунду (Gbps). Калі мы вывучалі дадзеную сітуацыю, асноўным крытэрыем для параўнання прадукцыйнасці было капіяванне дадзеных па сетцы 1-Gbps на адлегласць у 10 міль у іншы цэнтр дадзеных. Гэты працэс займаў больш за 24-х гадзін, што было цалкам непрымальна. Неабходна было знайсці такое рашэнне, якое давала б магчымасць выконваць рэзервовае капіраванне ў рамках таго вокны часу аднаўлення, які быў пазначаны ў SLA.
Усебакова пераасэнсаваўшы усе грані праблемы рэзервавання па сетцы і правёўшы мноства выпрабаванняў, мы змаглі скараціць рэзервовае капіраванне базы ў 2ТБ да 36 хвілін. Рашэнне, якое мы назвалі "Шматструменная рэзерваваннем па сетцы" (у арыгінале: "multistreamed backups over the network"), выкарыстоўвала восем сеткавых падлучэнняў, па 1-Gbps кожнае. Павялічаны да гіганцкага памер фрэйма быў паказаны ў наладах кожнай сеткавай платы, і кожная сеткавая плата была злучаная з задублированным па другім узроўні камутатарам лініяй 10GE (10Gbit Ethernet), якая працягнулася да другога сайта. Само рэзервовае капіраванне заняло 2 гадзіны 25 хвілін. Якое з'явілася ў SQL Server 2008 сціск рэзервовых копій дазволіла яшчэ скараціць гэты час да 36 хвілін. База дадзеных складалася з 32 файлаў дадзеных і аднаго файла часопіса транзакцый, якія займалі прыблізна 2,5 тэрабайта на 9 лагічных дысках (файлы дадзеных размяшчаліся на дыскавай сховішча карпаратыўнага класа - SAN, а часопіс транзакцый на лакальных дысках - DAS). У табліцы ніжэй паказана працягласць рэзервовага капіявання звычайным спосабам і два найбольш хуткіх падыходу да рэзерваванні па сетцы. Падрабязнае апісанне кожнай з рэалізацый прыведзена ніжэй.

Спроба Сетка Працягласць Звычайным спосабам Адна 1Gbps сеткавая плата, канфігурацыя па змаўчанні> 24 гадзін Шматструменнае рэзерваванне па сетцы 8x1Gbps сеткавых плат, гіганцкі фрэйм ​​2 гадзіны 25 хвілін Шматструменнае рэзерваванне па сетцы з выкарыстаннем кампрэсіі 8x1Gbps сеткавых плат, гіганцкі фрэйм ​​36 хвілін

Табліца 1: Працягласць рэзервавання 2Tб на сервер у 10 мілях па сетцы

Скарачэнне часу рэзервовага капіявання

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

Паралельнае выкарыстанне некалькіх дыскаў і файлаў.

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

Ніжэй паказаная каманда, якая выконвае рэзервовае капіраванне ў два файла.

BACKUP DATABASE MyVLDB

TO DISK = '\\ BAK01 \ backup \ MyVLDB00000001_1.bak',

DISK = '\\ BAK01 \ backup \ MyVLDB00000001_2.bak'

WITH CHECKSUM, INIT;

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

Выкарыстанне некалькіх сеткавых плат

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

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

Сеткавая плата Сервер SQL01 Сервер BAK01 Access 192.168.1.1 МАСКА 255.255.255.0 192.168.1.2 МАСКА 255.255.255.0 Backup 01 192.168.2.1 МАСКА 255.255.255.0 192.168.2.2 МАСКА 255.255.255.0 Backup 02 192.168.3.1 МАСКА 255.255.255.0 192.168.3.2 МАСКА 255.255.255.0

Табліца 2: падсеткі

Кожная сеткавая плата знаходзіцца ў сваёй падсеткі (192.168.1.0/24, 192.168.3. 0/24). Цяпер можна ўнесці невялікія змены ў каманду рэзервовага капіявання, паказаўшы там IP - адрасы замест імёнаў сервераў. Такім спосабам становіцца лёгка кіраваць тым, якая падсеткі, а, такім чынам, і якая сеткавая плата будзе выкарыстоўвацца для транспарціроўкі дадзеных. Той факт, што ўсе лагічныя падсеткі будуць знаходзіцца на адным і тым жа другім фізічным узроўні сеткі, не будзе мець ніякага адмоўнага ўплыву на гэтае рашэнне.

BACKUP DATABASE MyVLDB

TO DISK = '\\ 192.168.2.2 \ backup \ MyVLDB00000001_1.bak',

DISK = '\\ 192.168.3.2 \ backup \ MyVLDB00000001_2.bak'

WITH CHECKSUM, INIT;

У выпадку аднаўлення, гэта працуе па той жа схеме.

RESTORE DATABASE MyVLDB

FROM DISK = '\\ 192.168.2.2 \ backup \ MyVLDB00000001_1.bak',

DISK = '\\ 192.168.3.2 \ backup \ MyVLDB00000001_2.bak'

WITH CHECKSUM, NORECOVERY;

Сапраўды таксама ўсё будзе працаваць і з вялікім лікам сеткавых плат. У апісваных у артыкуле эксперыментах правяралася паралельная праца 16 сеткавых плат.

Павелічэнне прадукцыйнасці будзе назірацца і ад перадачы па сетцы некалькіх файлаў адначасова з дапамогай адной сеткавай платы.

BACKUP DATABASE MyVLDB

TO DISK = '\\ 192.168.2.2 \ backup \ MyVLDB00000001_1.bak',

DISK = '\\ 192.168.3.2 \ backup \ MyVLDB00000001_2.bak',

DISK = '\\ 192.168.2.2 \ backup \ MyVLDB00000001_3.bak',

DISK = '\\ 192.168.3.2 \ backup \ MyVLDB00000001_4.bak'

WITH CHECKSUM, INIT;

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

Рэкамендацыі па агульнай колькасці выкарыстоўваюцца файлаў

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

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

працэсам,
пустазельныя
ядра Лагічныя
дыскі
для
файлаў
дадзеных Сеткавыя
платы
для
рэзервовага
капіявання Файлы
дадзеных Файлы
рэзервовых
копій 2 1 1 2 2 4 2 2 2 4 4 4 2 4 4 8 2 2 2 8 8 4 2 4 8 16 2 2 8 8 16 4 4 8 8 16 4 4 16 16 16 8 4 16 16 32 8 4 16 16 32 8 8 16 32 32 16 8 16 32 64 16 8 32 32 64 32 16 32 64

Табліца 3: Збалансаванае размеркаванне файлаў па дыскам

Дадатковыя спосабы аптымізацыі і рэкамендацыі

Падзел сетак для рэзервовага капіявання і агульнага доступу

Заўсёды можна разлічваць на добры эфект ад падзелу сеткі агульнага доступу і сеткі для рэзервовага капіявання па фізічна незалежным, розным сетках. З-за рознай прыроды трафіку сетак агульнага доступу і сеткі рэзервовага капіявання, камутатары не заўсёды могуць аптымальна абслугоўваць адначасова два гэтых выгляду трафіку. Акрамя таго, для дасягнення высокай прапускной здольнасці трафіку рэзервовага капіявання часта патрабуецца вялікая частка рэсурсаў камутатара.
Наогул, заўсёды было добрай практыкай ня выпускаць вялікі трафік за межы аднаго камутатара (калі камутатар мае некалькі модуляў, не выпускайце трафік за межы аднаго модуля, калі гэта магчыма).

вялікія фрэймы

Максімальны памер пакета сеткі Ethernet у нармальных умовах складае 15000 байт (роўны памеру фрэйма). Гэта азначае тое, што для перадачы па сетцы 1 мегабайт, яго давядзецца разбіць на 700 пакетаў, якія будуць перададзены адзін за адным.
Сёння можна набыць такія сеткавыя платы і камутатары, якія падтрымліваюць пакеты Ethernet з вялікімі памерамі фрэйма. Для такіх фрэймаў сеткавых плат і камутатараў нават існуе адмысловая назва - "jumbo frames".
Чым больш памер фрэйма, тым хутчэй перадача дадзеных, таму што для абмену паміж серверамі спатрэбіцца менш ітэрацый.
Найбольш распаўсюджанымі памерамі вялікіх фрэймаў з'яўляюцца велічыні каля 4088 і 9016 Байт (уключаючы загалоўкі Ethernet і вялікага фрэйма). Напрыклад, калі памер фрэйма будзе 9016 Байт, тады для перадачы 1 мегабайт спатрэбіцца ўсяго 117 пакетаў.
Эмпірычныя даследаванні паказалі, што пры павелічэнні памеру фрэйма да 9016 Байт, прадукцыйнасць сеткі практычна падвойваецца.

BLOCKSIZE

Параметр, які задае які выкарыстоўваецца камандай BACKUP памер блока, павінен адпавядаць памеру блока запісу прылад доўгачасовага захоўвання. Калі запіс ажыццяўляецца на асобны дыск, будзе працаваць досыць добра нават якое выкарыстоўваецца па змаўчанні для памеру блока значэнне роўнае 512. Калі ж запіс накіравана на RAID - масіў або на SAN, варта пераканацца ў тым, што якое выкарыстоўваецца па змаўчанні значэнне не апынецца менш, чым, напрыклад, 65536.
Пры рэзервовым капіяванні па сетцы трэба падабраць такое значэнне, якое б дазволіла запаўняць сеткавыя пакеты найбольш шчыльна. Майце таксама на ўвазе, што разбіццё дадзеных на пакеты працуе ў абодвух напрамках. Выбар у якасці памеру блока 512 Байт прывядзе да таго, што ў сеткавай пакет будзе змяшчацца два блокі (беручы пад увагу тое, што памер фрэйма Ethernet роўны 1500 Байт). Т.ч. для перадачы адной старонкі базы дадзеных спатрэбіцца 8 сеткавых пакетаў. З іншага боку, запіс блокамі па 4096 Байт будзе змяшчацца ў 3 сеткавых пакета, а для перадачы адной старонкі базы дадзеных спатрэбіцца 6 сеткавых пакетаў.
Можна прывесці яшчэ дадатковыя прыклады, атрыманыя ў выніку праводзяцца пры напісанні гэтага артыкула тэстаў; пры выкарыстанні вялікіх фрэймаў памерам 9016 Байт найлепшыя вынікі атрымліваліся пры памеры блока 8192 Байт, а пры выкарыстанні вялікіх фрэймаў памерам 4088 Байт, найлепшыя вынікі атрымліваліся пры памеры блока 65536 Байт.

BUFFERCOUNT і MAXTRANSFERSIZE

З параметраў каманды BACKUP можна вылучыць такія, якія таксама вельмі моцна ўплываюць на прадукцыйнасць рэзервовага капіявання, гэта параметры BUFFERCOUNT і MAXTRANSFERSIZE. На жаль, нават тыдня тэстаў не змаглі дапамагчы скласці правіла падбору аптымальных значэнняў для гэтых параметраў, таму Вам таксама неабходна будзе высвятляць аптымальныя значэння тэсцiраваннем на Вашай асяроддзі. У якасці савета. для значэння параметру MAXTRANSFERSIZE калі ў Вас сістэма x64 або IA64 з дастатковай аб'ёмам аператыўнай памяці, можна пачаць тэставанне са значэння максімальнага памеру буфера 4 Мб (4.194.304). Для атрымання больш падрабязнай інфармацыі аб параметры BUFFERCOUNT і пра іншыя аптымізуюць параметрах, звярніцеся да рэкамендацый па наладзе прадукцыйнасці сціску рэзервовых копій у тэхнічнай артыкуле: Tuning the Performance of Backup Compression in SQL Server 2008
У некаторых выпадках, пры правядзенні тэстаў для гэтага артыкула, лепшыя вынікі атрымліваліся пры істотна меншых значэннях параметраў, але выбар значэнняў быў непрадказальны. Для прамысловага прымянення варта выканаць ўсебаковае тэставанне розных варыянтаў, і пераканацца, што лепшыя вынікі добра прайграваюцца. Калі ж няма магчымасці правесці такую ​​працу - лепш захаваць параметры па змаўчанні.

Сціск рэзервовай копіі

Сціск рэзервовых копій (новая функцыя, якая з'явілася ў SQL Server 2008) дае магчымасць павялічыць прадукцыйнасць рэзервавання і ў той жа час істотна скараціць спажыванае копіяй дыскавая прастора, якое вызначана для захоўвання рэзервовых копій. Для ўключэння сціску рэзервовай копіі, у камандзе BACKUP трэба дадаць опцыю WITH COMPRESSION.
У прадстаўленым ніжэй прыкладзе запыту паказана, як уключыць сціск рэзервовай копіі.

BACKUP DATABASE MyVLDB

TO DISK = '\\ BAK01 \ backup \ MyVLDB.bak'

WITH CHECKSUM, INIT, COMPRESSION;

Ступень сціску на самай справе залежыць ад дадзеных, якія захоўваюцца ў базе. Для большасці баз дадзеных (лічбавая інфармацыя, грашова-крэдытныя аперацыі, дата і час, просты тэкст), каэфіцыент сціску будзе знаходзіцца паміж 1: 4 і 1: 6. Для баз дадзеных змяшчаюць некаторыя іншыя тыпы дадзеных, напрыклад, карцінкі, якія ўжо ў сціснутым фармаце, можна чакаць вынікі горай. Для атрымання больш падрабязнай інфармацыі аб выкарыстанні сціску з рознымі тыпамі дадзеных, глядзіце артыкул у SQL Server Books Online: Сціск рэзервовых копій .

У якія праводзяцца для гэтага артыкула тэстах, назіралася скарачэнне часу рэзервовага капіявання з 125 да 36 хвілін, пры сціску файла на 20 адсоткаў ад першапачатковага памеру.
У сціску дадзеных ёсць адзін недостаток- павышэнне ўтылізацыі працэсарных рэсурсаў.
SQL Server производитт сціск ў адным патоку, які піша дадзеныя ў файл рэзервовай копіі, так што колькасць файлаў рэзервовых копій вызначаецца лікам працэсарных ядраў, якія будуць выконваць сціск паралельна. Каб абмежаваць выкарыстанне працэсараў для рэзервовага капіявання, можна выкарыстоўваць Рэгулятар Рэсурсаў (Resource Governor), з дапамогай якога можна аддаваць іншым падлучэння больш рэсурсаў.
Калі выкарыстоўваецца празрыстае шыфраванне базы дадзеных (TDE), ня варта спрабаваць выкарыстоўваць для шыфраваных базы яшчэ і сціск, таму што зашыфраваныя дадзеныя сціскацца дастаткова дрэнна. Калі ўказанне магчымасці сціскання пры фарміраванні кожнай каманды рэзервовага капіявання нязручна, можна з дапамогай сістэмнай захоўваемай працэдуры sp_configure ўсталяваць аўтаматычнае сціск пры стварэнні ўсіх рэзервовых копій на сэрвэры:

sp _ configure 'backup compression default', 1

reconfigure

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

Рэкамендацыі па апаратных сродках файлавых сервераў, прызначаных для захоўвання копій

дыскавыя прылады

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

Настройка RAID-кантролера

Для стварэння масіваў лагічных дыскаў, на якіх вырашана захоўваць файлы рэзервовых копій, Варта выбраць Вялікі Памер сегмента (64 Кб, 128 Кб, 256 Кб І вышэй). Таксама, Варта ўсталяваць поўнае кэшаванне запісу, а кэшаванне чытання можна Цалкам адключыць. Можна Яшчэ актывізаваць кэш запісу Асобны шпіндзеляў, так як калі падчас рэзервовага капіявання адбудзецца збой па харчаванню, рэзервовая копія так і так табары непрыдатнай, І Ў такім выпадку ня траўні значэння, ці былі страчаныя Якія-небудзь байты Ў кэшы запісу ці ня.
Для тых лагічных дыскаў, Якія будуць задзейнічаны Ў выпрабавальным аднаўленні базы в е копіі, Памер сегмента усталёўваецца Ў 64 Кб, прымяняецца палітыка 100-адсоткавага кэшавання запісу, а кэшаванне чытання выстаўляецца на 0 адсоткаў.
Выбар ўзроўню RAID (1, 10, 5, 6 ...) залежыць ад магчымасцяў выкарыстоўванага RAID-кантролера або выкарыстоўванай сістэмы сховішчы. Паколькі нагрузка на файлавым серверы пры рэзервовым капіяванні / аднаўленні з'яўляецца паслядоўнай запісам і чытаннем дадзеных, кантролер будзе кэшаваць дадзеныя, пакуль ён не скончыць запіс усяго страйпа цалкам, у гэтым выпадку можна выкарыстоўваць любы ўзровень RAID. Калі кантролер паводзіць сябе па-іншаму, і прадукцыйнасць з'яўляецца крытычным параметрам, масівы RAID1 ці RAID10 будуць адзіным магчымым варыянтам.

Настройка HBA

Калі ў якасці дыскаў для файлаў рэзервовых копій выкарыстоўваецца дыскавая падсістэма тыпу SAN, максімальную глыбіню чарзе для адаптараў, якія выкарыстоўваюцца ў падключэнні SAN, трэба павялічыць настолькі, наколькі гэта магчыма. Значэнне па змаўчанні складае 32, але рэзервовае капіяванне і аднаўленне будуць працаваць нашмат лепш пры значэннях блізкіх да 256. Больш падрабязную інфармацыю можна знайсці ў артыкуле Налада Windows Server 2008/2003 x64 для абслугоўвання SQL Server 2008 , У раздзеле "NumberOfRequests і MaximumSGList".

сеткавыя платы

Варта вельмі разборліва падыходзіць да выбару сеткавых плат, якія будуць выкарыстоўвацца на серверах. Лік партоў яшчэ не гарантуе адэкватную прадукцыйнасць ўводу-высновы для ўсіх гэтых партоў ў адно і тое ж час. Бывае так, што два четырехпортовый адаптара могуць апынуцца больш прадукцыйнымі, чым адзін адаптар з чатырма партамі. Колькасць працэсарнага часу, які выкарыстоўваецца драйверам сеткавага інтэрфейсу, таксама вельмі важна. Бываюць такія сеткавыя платы, якія выкарыстоўваюць да 50 адсоткаў рэсурсаў аднаго працэсара, і ў той жа час ёсць іншыя, якія выкарыстоўваюць ўсяго 3 - 5 працэнтаў.
Калі для рэзервовага капіявання выкарыстоўваецца некалькі сеткавых плат, вельмі важна, каб яны выкарыстоўвалі розныя працэсары, г.зн. каб іх перапынення былі прывязаныя да розных процессорным ядрам.

Сістэмы на аснове NUMA

Калі сервер выкарыстоўвае архітэктуру з неаднародным доступам да памяці (NUMA), неабходна пераканацца ў тым, што ўсе адаптары ўводу-высновы (напрыклад, NIC, RAID і HBA) размеркаваны паміж усімі NUMA - вузламі сістэмы.

Вылічэнне часу, неабходнага для рэзервовага капіявання і аднаўлення базы дадзеных

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

Далей, трэба вызначыць максімальную працягласць паралельнага, паслядоўнага чытання і запісы выкарыстоўваюцца дыскавых падсістэм. Для таго каб вымераць гэтыя значэння пры тэставанні рэзервовага капіявання і аднаўлення, можна выкарыстоўваць сістэмную ўтыліту Performance Monitor (вядомую яшчэ ў некаторых версіях аперацыйнай сістэмы Windows як System Monitor).
У выніку, павінна атрымацца 5 значэнняў. Калі маецца некалькі лагічных дыскаў і сеткавых плат, гэтыя значэнні могуць адрознівацца, і заўсёды трэба выкарыстоўваць самыя горшыя вынікі вылічэнняў.

    1. Прадукцыйнасць сеткавага адаптара (МБ / сек);
    2. Прадукцыйнасць лагічнага дыска сховішчы копій пры паслядоўным чытанні (МБ / сек);
    3. Прадукцыйнасць лагічнага дыска сховішчы копій пры паслядоўнага запісу (МБ / сек);
    4. Прадукцыйнасць лагічнага дыска файла базы дадзеных пры паслядоўным чытанні (МБ / сек);
    5. Прадукцыйнасць лагічнага дыска файла базы дадзеных пры паслядоўнага запісу (МБ / сек).

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

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

Вылічэнні для разліку часу аднаўлення будуць больш складана. Спачатку трэба даведацца, ці падтрымлівае выкарыстоўваная сістэма імгненную ініцыялізацыю файлаў. Гэтая магчымасць дазваляе SQL Server ствараць файлы дадзеных на тамах NTFS без абнулення займанага файламі месца падчас стварэння або пашырэння файла. Паколькі ў гэтага механізму існуюць звязаныя з бяспекай рызыкі, такой магчымасцю можна скарыстацца, толькі калі ўліковага запісу, пад якой запушчана служба SQL Server прадаставіць у лакальных палітыках права "Perform Volume Maintenance". Калі уліковы запіс карыстальніка уваходзіць у групу лакальных адміністратараў, гэта права ёй будзе прадастаўлена па змаўчанні (Заўвага: час ініцыялізацыі файла часопіса транзакцый можа абмяжоўваць прадукцыйнасць, так як займанае гэтым файлам месца не можа не запаўняцца нулямі).

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

Звярніце ўвагу: на выкананне каманды CHECKBD можа спатрэбіцца больш часу, чым час, якое неабходна для чытання з дыска. Яно залежыць ад складанасці схемы базы дадзеных, і яно сапраўды не будзе менш часу чытання.

заключэнне

Microsoft і, непасрэдна каманда SQL Server пастаянна ўдасканальваюць тэхналогіі забеспячэння жывучасці сістэм, якія закліканы дапамагчы кліентам і партнёрам вырашаць задачы рэзервовага капіявання і аднаўлення ў маштабах прадпрыемства. SQL Server 2008 забяспечаны для гэтых задач ўсім неабходным функцыяналам, на які могуць разлічваць спецыялісты і які дапамагае паспяхова спраўляцца з уласцівымі сённяшняга дня патрабаваннямі па кіраванні і абароне дадзеных. За кошт удасканаленняў ў ключавых галінах, SQL Server 2008 стаў надзейнай платформай для абслугоўвання вельмі вялікіх баз дадзеных.
Гэтая тэхнічная артыкул падае толькі кароткі агляд магчымасцяў рэзервовага капіявання і аднаўлення, а таксама некаторых функцыянальных магчымасцяў SQL Server 2008.

Навигация сайта
Реклама
Панель управления
Календарь новостей
Популярные новости
Информация
Экономика стран www.mp3area.ru © 2005-2016
При копировании материала, ссылка на сайт обязательна.