Продължавайки поредицата си от статии за ключалките, този път ще обсъдя ключалката APPEND_ONLY_STORAGE_INSERT_POINT и ще покажа как тя може да бъде основно пречка за тежки натоварвания с актуализация, където се използва всяка форма на изолиране на моментни снимки.
Силно ви препоръчвам да прочетете първоначалната публикация от поредицата преди тази, за да имате всички основни основни познания за ключалките.
Какво представлява ключалката APPEND_ONLY_STORAGE_INSERT_POINT?
За да обясня това ключалка, трябва да обясня малко как работи изолирането на моментни снимки.
Когато активирате една от двете форми на управление на версии, SQL Server използва механизъм, наречен версиониране за да запазите предварителна промяна на версиите на запис в съхранението на версии в tempdb. Това се прави по следния начин:
- Записът е идентифициран като току що предстои да бъде променен.
- Текущият запис се копира в хранилището на версиите.
- Записът е променен.
- Ако записът все още няма 14-байтов маркер за версия , един се добавя в края на записа. Тагът съдържа времева марка (не реално време) и указател към предишната версия на записа в хранилището на версиите.
- Ако записът вече има маркер за версия, той се актуализира с новото времеви печат и указател за съхранение на версията.
Времевата марка за версия за целия екземпляр се увеличава всеки път, когато започва нов израз или партида или се създава нова версия на запис във всяка база данни, където е активирана която и да е форма на изолиране на моментни снимки. Това клеймо за време се използва, за да се гарантира, че заявката обработва правилната версия на запис.
Например, представете си база данни, която е активирала четене на извършена моментна снимка, така че всеки израз е гарантиран да вижда записите към момента на стартиране на оператора. Времевата клеймо на версията се задава за момента, в който операторът е стартирал, така че всеки запис, който срещне, който има по-високо времеви печат, е „грешната“ версия и така „правилната“ версия, с клеймо за време преди клеймото за време на изявлението, трябва да бъде извлечена от магазин за версии. Механиката на този процес не е от значение за целите на тази публикация.
И така, как версиите се съхраняват физически в магазина за версии? Целият запис за предварителна промяна, включително колони извън ред, се копира в хранилището на версиите, разбито на 8000-байтови парчета, които могат да обхващат две страници, ако е необходимо (напр. 2000 байта в края на една страница и 6000 байта в началото на следващия). Това съхранение със специално предназначение се състои от разпределителни единици само за добавяне и се използва само за операции за съхранение на версии. Нарича се така, защото нови данни могат да бъдат добавени само веднага след края на последната въведена версия. От време на време се създава нова единица за разпределение и това позволява почистването на редовното хранилище за версии да бъде много ефективно — тъй като ненужната единица за разпределение може просто да бъде изпусната. Отново, механиката на това е извън обхвата на тази публикация.
И сега стигаме до дефиницията на фиксатора:всяка нишка, която трябва да копира запис за предварителна промяна в хранилището на версиите, трябва да знае къде е точката на вмъкване в текущата единица за разпределение само за добавяне. Тази информация е защитена от ключалката APPEND_ONLY_STORAGE_INSERT_POINT.
Как резето се превръща в тесно място?
Тук е проблемът:има само един приемлив режим, в който може да се получи ключалката APPEND_ONLY_STORAGE_INSERT_POINT:EX режим (изключителен). И както ще разберете от четенето на въвеждащата публикация към поредицата, само една нишка в даден момент може да задържи ключа в режим EX.
Събиране на цялата тази информация заедно:когато една или повече бази данни имат активирана изолация на моментни снимки и има достатъчно голямо едновременно натоварване на актуализациите на тези бази данни, ще има много версии, генерирани от различните връзки, и това ключалка ще се превърне в малко затруднение, като размерът на тесното място се увеличава с увеличаването на работното натоварване на актуализацията, когато е включено версията.
Показване на тесното място
Можете лесно да възпроизведете тесното място за себе си. Направих го по следния начин:
- Създадена е таблица с набор от колони с цели числа, наречени cXXX, където XXX е число и клъстериран индекс в колона с int идентичност с име DocID
- Вмъкнати 100 000 записа със произволни стойности за всички колони
- Създаден е скрипт с безкраен цикъл за избор на произволен DocID в диапазона от 1 до 10 000, избор на произволно име на колона и увеличаване на стойността на колоната с 1 (следователно създаване на версия)
- Създадени са девет идентични скрипта, но всеки избира от различен диапазон от ключове на клъстер от 10 000 стойности
- Задайте DELAYED_DURABILITY на FORCED, за да намалите изчакванията в WRITELOG (признава се, че рядко бихте правили това, но това помага да се задълбочи затруднението за демонстрационни цели)
След това стартирах всичките десет скрипта едновременно и измерих методите за достъп:Индексни търсения/сек, за да проследя колко актуализации се случват. Не можех да използвам Databases:Batch Requests/sec, тъй като всеки скрипт имаше само една партида (безкраен цикъл) и не исках да използвам Transactions/sec, тъй като може да брои вътрешни транзакции, както и този, който обвива всяка актуализация.
Когато изолирането на моментни снимки не беше активирано, на моя лаптоп с Windows 10, работещ със SQL Server 2019, получавах около 80 000 актуализации в секунда в десетте връзки. След това, когато включих настройката READ_COMMMITED_SNAPSHOT на ON за базата данни и изпълних отново теста, пропускателната способност на работното натоварване спадна до около 60 000 актуализации в секунда (25% спад в пропускателната способност). От разглеждане на статистически данни за чакане, 85% от всички чакания бяха LATCH_EX, а от разглеждане на статистически данни за заключване, 100% бяха за APPEND_ONLY_STORAGE_INSERT_POINT.
Имайте предвид, че настроих сценария, за да покажа тесното място в най-лошия му вид. В реална среда със смесено работно натоварване, общоприетите указания за спад на пропускателната способност при използване на изолация на моментни снимки са 10-15%.
Резюме
Друга потенциална област, която може да бъде засегната от това тесно място, са четими вторични елементи на групата наличност. Ако реплика на база данни е настроена да бъде четлива, всички заявки към нея автоматично използват изолация на моментни снимки и цялото възпроизвеждане на регистрационни записи от основния ще генерира версии. С достатъчно голямо работно натоварване на актуализацията, идващо от основната и много бази данни, настроени за четене, и с паралелно повторение, което е норма за вторични групи за наличност, ключалката APPEND_ONLY_STORAGE_INSERT_POINT може да се превърне и в тесно място на четими вторични групи за наличност, което може да доведе до вторично изостава от първичното. Не съм тествал това, но това е точно същият механизъм, който описах по-горе, така че изглежда вероятно. В този случай е възможно да деактивирате паралелното повторение с помощта на флаг за проследяване 3459, но това може да доведе до по-лоша обща пропускателна способност на вторичния.
Оставянето на сценарий на групата наличност настрана, за съжаление, неизползването на изолация на моментни снимки е единственият начин да избегнете напълно това затруднение, което не е жизнеспособна опция, ако работното ви натоварване разчита на семантиката, предоставена от изолацията на моментни снимки, или имате нужда от нея, за да облекчите проблемите с блокирането (тъй като изолирането на моментна снимка означава, че заявките за четене не придобиват заключвания на споделяне, които блокират заявките за промяна).
Редактиране:от коментарите по-долу можете * можете* да премахнете тесното място на ключалката, като използвате ADR в SQL Server 2019, но тогава производителността е много по-лоша поради режийните разходи за ADR. Сценарият, при който ключалката се превръща в тесно място поради голямото работно натоварване при актуализация, абсолютно не е валиден случай на употреба за ADR.
