А. Отговорът винаги ще бъдеш мой любим: това зависи! Позволете ми да обясня причината за някои основни данни.
Ключовият момент, който трябва да се вземе предвид и степента на компресия, която всеки ще имате резервно копие на базата данни, когато е активен, за компресиране на архиви. Степента на сгъстяване, като се използва алгоритъм се определя от какъв вид данни се компресира.
Случайни данни (малка целочислени стойности, например) ще се свие не много добри, така че е възможно степента на сгъстяване ще определи основно на съдържанието на таблиците и индексите в рамките на базата данни.
Ето няколко примера за това, кога за компресиране на архиви, не може да се осигури висока степен на компресия:
- Ако базата данни е активиран за прозрачно криптиране на данните, а след това степента на сгъстяване ще бъде много ниска, тъй като данните ще бъдат компресирани в малки произволни стойности.
- Ако по-голямата част от данните в базата данни се компресира на ниво колона, а след това степента на сгъстяване ще бъде ниска отново като компресия колони, всъщност, се смесва данни.
- Ако компресиране на данни е активиран за по-голямата част от таблиците в базата данни, а след това степента на сгъстяване ще бъде ниска; компресиране на данни, която вече е най-вече компресиран, обикновено има малък ефект.
В случаите, когато степента на сгъстяване е ниска, проблемът не е в най-ниското ниво, както и че на процесора и ресурси, използвани за извършване на алгоритъм за компресиране, са безполезни. Независимо от това колко добре можете да компресирате частта с данни от ресурсите на процесора винаги се използва за извършване на компресия и декомпресия алгоритми.
Това означава, че преди да вземете решение за трайно използване на компресия за тази база данни, за да проверите колко добре всяка база данни компресира в архив. В противен случай е възможно загуба на ресурси на процесора. Това е в основата на това, което сте чули.
С една дума, ако по-голямата част от базите данни, ще се възползват от резервната компресия, че има смисъл да се даде възможност за компресиране на архиви на ниво сървър и ръчно да промените няколко резервни работни места да се използва специално С NO_COMPRESSION. Алтернативно, ако по-голямата част от базите данни, няма да получи обезщетение от резервно копие компресия, че има смисъл да деактивирате архивиране компресия на ниво сървър и ръчно да промените няколко резервни работни места да се използва специално при компресирането.
Въпрос: Миналата година се обновява нашата база данни, за да добавите към тях, отразявайки, което позволява в случай на повреда да отидете на огледално копие, и да продължат да работят. При разработването на системата, ние извършват тези трансфери за базата данни, и тя работи добре. В сме изправени пред един истински провал и прехода на базата данни се изпълняват през миналата седмица, но всички приложения са спрели сделката и прилагането не е свързан със сървъра на срив. Как мога да инсталирате SQL Server в бъдеще, така че да не се пуска за кандидатстване връзки по време на прехода към дадена операция може да продължи?
А. Да разделим отговорът на две части: как приложенията могат да се справят с отказоустойчивост и как да управлявате пренасочване на клиентите, ползващи огледални бази от данни.
Когато един срив използвате някой от високите технологии наличие на разположение в SQL Server, клиент връзката към сървъра е нагласена на жертвата не се осъществи, и всички, които са били изгубени в сделката. Прехвърляне намира в пътеките на сделката между сървъри не е възможно (като в случай на повреда трансфер и всяка друга). В зависимост от използваната технология за висока надеждност намира в някоя сделка няма да съществува изобщо в сървъра при срив, или ще съществува като в сделката, но ще изнудвач обратно като ефективността на възстановяване на базата данни на процеса на сървъра на срив.
По отношение на огледални бази от данни, непрекъснато изпращане на журналните записи сделка от първичния сървър на огледало сървъра, той обикновено се случва, а вторият - са сделките са хвърлени обратно в процеса на възстановяване огледални данни за ефективността на базата данни към нов безопасност участник.
Следователно, има две неща, че молбата трябва да бъде в състояние да направи правилно, когато работи на сървър с възможност за превключване на друг сървър в случай на повреда:
- Тя трябва да бъде в състояние да реагират адекватно на връзката със сървъра се рестартира и да се опита да възстанови връзката след кратък период от време.
- Тя трябва да бъде в състояние да обработва правилно анулиране на транзакция последващ опит за възобновяване на сделката, след като връзката със сървъра за възстановяване след срив (евентуално с помощта на междинно ниво транзакция Manager).
само висока наличност технология тук, който не изисква специфични промени на клиента, за да се позволи пренасочване на връзки с клиенти след прехода - е срив групиране. Клиентите се свързват с името на виртуалния сървър и са прозрачно пренасочени към активното възел на физическото клъстера.
В случай на наличие на високи технологии, като например дневник корабоплаването и репликация, име срив на сървъра е различна, което означава, че след преминаването към този сървър, което трябва да се пренасочи връзки с клиенти и ръчно. Това пренасочване може да се направи по няколко начина:
- Можете да кодирате твърдо името на срив на сървъра на клиента, за да се свържете отново опити са били насочени към този сървър.
- Можете да използвате Network Load Balancing с настройката, 100 / 0-0 / 100, който след това ще се включи връзката със сървъра за възстановяване след срив.
- Можете да използвате нещо като сървъра псевдоним или превключване на записи в таблица DNS.
С огледални бази от данни работа някоя от тези опции. Но огледало база данни също така има вграден посока възможности на клиента. низ свързване на клиента може лесно да укажете името на огледало сървър, който автоматично ще се опита да се свърже, ако това не е възможно до мозъка на костите. Този процес е известен като прякото препращане.
Ако низа за свързване на клиент не може да се промени, а след това може да е възможно индиректно пренасочване, ако жертвата не успее сървърът вече е стартирал като огледало сървъра. Всяка връзка с него, ще бъдете автоматично пренасочени към новия директор сигурност - но това работи само ако огледало сървърът се изпълнява.
Фиг. 1. Проучване на ключалки на масата, разделена на секции
О. Наблюдаваните проблем, причинен от механизма, наречен заключване ескалация. SQL Server придобива брави на данни, за да ги защити, докато искането чете или записва данни. Тя може да се получи блокиране на цели маси, файлови данни страници или отделни редове на таблици / индекси и всяка брава заема малко място в паметта.
Ако искането е става прекалено голям брой брави, SQL Server може да реши да замени всички ключалки на масата за линия или страница в един заключване за цялата таблица (праг, където това се случи, е приблизително 5000 брави сложен, но точен алгоритъм и да се създаде). Този процес се нарича заключване ескалация.
След това искане Б да работите в друг раздел, без да бъде блокиран. Запитване Б, може да предизвика дори самата брава ескалация, която блокира само дяла, който заявка B работи, вместо цялата таблица.
Този модел на заключване ескалация може да се настрои с помощта на следния синтаксис:
Този синтаксис определя управителя на заключване да се използва за заключване ескалацията на SQL Server за нивото на дял, ако таблицата е разделен на тях, както и обичайните консолидацията на ниво таблица, ако не. Поведението по подразбиране е да се използва за заключване ескалация на нивото на масата. трябва да зададете този режим с повишено внимание, тъй като в зависимост от поведението на заявките може да доведе до мъртвите зони.
Например, ако всеки от искания А и Б причинява ескалацията за заключване на различни секции в таблицата, но след това се опитва да получи достъп до секцията блокиран от още един от исканията е прекъснат мъртвите зони монитора.
Цифрата показва пример за заявка система представяне на стоките sys.partitions (първият ред на резултатите) и динамични вижте управление sys.dm_os_locks (втора серия от резултати) за разследване на брави, държани за заявки за търсене в таблицата разделени на секции, на което е станало ескалацията за заключване на ниво раздел , В този случай, има два изключителни брави ниво раздел (НОВТ ключалки в продукцията), но се заключва маса (Lock обект в изхода) не са изключителни, така че няколко заявки могат да получат достъп дялове макар заключване ескалация. Забележете, че идентификационните номера на ресурси за тези две преградни брави съответстват на идентификационните номера на преградни за първите две секции в таблицата с изход за sys.partitions.
А. Краткият отговор е, че възстановяването на сделка влезете което можех да мисля само при възстановяване от резервно копие не е възможно. Въпреки че са известни опасност възстанови регистър на транзакциите (читателите могат да виждат публикацията в блога си, да научите повече за тях "крайни мерки, прилагани на първо място."), Фактът, че базата данни е станала ненадеждни, което означава, че възстановяването не се допуска; - всяко възстановяване недостатъчност, или когато сделката намаление на цените. Това означава, че реалната възможност за подправяне на данните в базата данни.
Въпреки, че проблема и е имало време на спокойствие, да не си мислил за планирано и фонови задачи? По време на дневника е повредена би могло да се работи задача по техническото обслужване, възстановяване или струпани индекс реорганизира. Предистория задача би могла да доведе фантом почистване на страници в купчина или струпани индекс. Всеки един от тези проблеми, например, може да прави промени в клъстерни структури индекса, че неуспехът да се коригира намаление на цените ще доведе до повреда в базата данни и възможна загуба на данни.
Като цяло, възстановяването на регистъра на операциите винаги трябва да бъде съвсем последното, и на последна инстанция във всяка опция за възстановяване след бедствие, защото на големи възможности за по-нататъшно увреждане и загуба на данни. Най-малкото, въз основа на данните, трябва да се извърши пълна DBCC CHECKDB, за да проверите за всички щети.
След това трябва да се промени своята резервна стратегия, за да бъде в състояние да изпълнява своевременно възстановяване, а не да отида до драстични мерки като възстановяване на регистър на транзакциите. Действия за развитието на тази стратегия са извън обхвата на тази статия, но смятам да покрие тази тема в специална висококачествена хартия в тази година. Така че очаквайте!
Свързани статии