Както подсказва името, TempDB е временно работно пространство, изисквано от SQL Server за създаване и задържане на междинни и временни обекти.
TempDB е важно зъбно колело в цялостния апарат на SQL Server и като временно работно пространство – данните, които съхранява, са преходни по природа. С други думи, вашият екземпляр на SQL Server пресъздава TempDB всеки път, когато се рестартира – като си дава чиста поле за изтриване, с която може да работи.
- временни обекти, задействани от потребителски заявки
- обекти, изисквани от вътрешните системни процеси
- информация за версията на реда
Излишно е да казвам, че ако TempDB не е конфигуриран оптимално, това може да доведе до оперативни тесни места и влошаване на производителността. Може да ви накара да се чудите защо вашите заявки със сложни обединявания и операции за сортиране не дават резултати толкова бързо, колкото се очаква.
Няма лесен начин за обобщаване на най-добрите практики за оптимизиране на TempDB, сценариите са твърде разнообразни и това, което работи в дадена ситуация, може да не работи в друга. Дори ако вашата база данни е влязла в производство, винаги е добра идея да продължите да преглеждате настройката на TempDB, за да се уверите, че е конфигурирана както трябва.
Един от най-сериозните проблеми в производителността на базата данни е спорът за TempDB. Това се случва, когато множество ресурси изискват TempDB, но има само един файл с данни TempDB за достъп.
Конфликтът с TempDB може да причини сериозни проблеми с производителността и често се разбира погрешно като нормално блокиране поради заключвания на база данни. Много пъти това всъщност е задържан спор на страниците за разпределение от едновременни процеси. Това може да доведе до тесни места, тъй като всеки процес чака своя ред. Тъй като редът не идва достатъчно бързо, времето за изчакване на основните връзки и процесите трябва да бъдат освободени.
Какво получаваш? Виртуално задръстване от блокирани процеси.
Как да разрешите споровете за TempDB и да оптимизирате производителността на SQL Server? Нека да разгледаме основите и да продължим по пътя си оттам.
Брой файлове с данни – колко трябва да имам?
Когато настроите SQL Server и запазите конфигурацията по подразбиране, имате само един файл с данни за TempDB. Не се задоволявайте с тази конфигурация.
Едно от често рекламираните основни правила е един файл с данни на ядро. Но продължете с повишено внимание в този случай, ако вашият сървър има 12 ядра, тогава не използвайте 12 TempDB файла с данни, освен ако това не е оправдано от изискванията на приложението и зареждането.
Най-добрият вариант, като се имат предвид днешните хардуерни конфигурации, е да започнете с 8 основни файла с еднакъв размер и да видите дали проблемът със спора е разрешен. Продължете нагоре и добавете още четири файла, ако е необходимо. Помощникът за инсталиране и настройка на SQL Server 2016 има вградена функция, която гарантира, че имате достатъчен брой TempDB файлове с данни, като открива броя на процесорните ядра и автоматично създава подходящия брой TempDB файлове с данни.
Размерът има значение – Как трябва да се конфигурират файловете с данни за размер?
След като покрихме броя на файловете, нека да разгледаме препоръчителния размер на всеки файл. Размерът по подразбиране е 8 MB, което осигурява на SQL Server общо 64 MB пространство TempDB, недостатъчно за повечето производствени среди. Поддържането на Autogrowth също е опция, но SQL Server ще трябва да направи пауза и да задели повече дисково пространство за TempDB файловете, когато е необходимо – добавяне на значителни допълнителни разходи към SQL Server по време на производствено изпълнение.
Препоръчителната практика е да съхранявате файловете и първоначалното пространство, необходимо за всеки файл, да бъде приблизително 80 до 90% от обема, на който се съхранява TempDB. 10 до 20% дисково пространство остава за виртуална памет, базирана на ОС.
С други думи, предварително оразмерете файловете с данни по време на настройката или променете размера на файловете в производствената среда. Това ще гарантира, че е разпределено достатъчно дисково пространство за TempDB. Винаги се препоръчва да поддържате опцията Autogrowth включена в този момент, но в идеалния случай опитайте се да се уверите, че SQL Server не трябва да заделя допълнително дисково пространство в движение твърде често.
Интересен факт, преди SQL Server 2017 не беше възможно да се разпределят повече от 1 GB на TempDB файл с данни по време на настройката. С най-новата версия е възможно да се разпределят до 256 GB за TempDB файл с данни по време на настройката.
Което ни води до следващия въпрос:
Къде да съхранявам TempDB файловете с данни?
Преди SQL Server 2012, в случай на клъстерирана среда, TempDB трябваше да бъде разположен на дискове, споделени между клъстерираната среда, като мрежа за съхранение (SAN). Започвайки със SQL Server 2012, е възможно да се съхраняват файловете с данни TempDB на базирано на SSD локално хранилище. Това намалява това, което би било много трафик между споделената SAN и екземпляра на SQL Server.
В повечето случаи най-добрият вариант за местоположение на TempDB е специален локален SSD. Ако това не е възможно, поддържането му на отделен собствен обем с достатъчно предварително разпределено дисково пространство би трябвало да реши вероятните проблеми с производителността. Уверете се, че постоянно наблюдавате здравето на диска, така че четенето и записването на диска да се извършват на оптимално ниво.
В идеалния случай носителят трябва да бъде възможно най-бърз предвид конфигурацията на сървъра, изискванията на приложението и не на последно място, разпределения бюджет.
Сега, след като разгледахме основите, нека разгледаме подходящи и добре дошли допълнения към различни допълнения към SQL Server след SQL Server 2012.
Какво още има ново?
SQL Server 2016
Специален раздел по време на настройка
- С това издание SQL Server има специален раздел за конфигуриране на TempDB по време на работния процес за настройка
- Помощникът за инсталиране и настройка на SQL Server 2016 има вградена функция, която гарантира, че имате достатъчен брой TempDB файлове с данни към момента на инсталиране на SQL Server. Той открива броя на ядрата на процесора и автоматично създава TempDB файлове с данни, като максимум 8. Можете да увеличите този брой след настройка на SQL Server.
Незабавна инициализация на файл
- SQL сървърът трябва да разпредели дисково пространство за TempDB по време на първоначалната настройка, както и когато размерът на файла расте в производствен цикъл. Това разпределение може да бъде възможно по два начина. Първият начин е чрез инициализиране на неизползваното дисково пространство чрез записване на нули, преди да се разпредели пространството. Вторият начин е чрез незабавно разпределяне на файлово пространство за растеж на TempDB.
- При първия метод SQL Server трябва да извърши интензивна операция, като инициализира всеки логически дисков клъстер. При този метод процесите, изпълнявани на сървъра, които се нуждаят от TempDB, може да трябва да изчакат, създавайки пречка.
- Ако вместо това изберете незабавно да разпределите файлово пространство, SQL сървърът незабавно разпределя пространство за Autogrowth, без да инициализира дисковото пространство. Това намалява дисковото I/O всеки път, когато има изискване за Autogrowth и гарантира по-добра пропускателна способност и производителност. Въпреки че беше възможно да се включи IFI в предишни издания, това беше тромав процес. В това издание на SQL Server е по-лесно да настроите IFI по време на настройката на сървъра.
- Флаговете за проследяване 1117 и 1118 са излишни
SQL Server 2017
- Преди SQL Server 2017 не беше възможно да се разпределят повече от 1 GB на TempDB файл с данни по време на настройката, което означава, че размерът на TempDB файла трябваше да бъде увеличен след завършване на настройката. С тази версия е възможно да се разпределят до 256 GB за TempDB файл с данни по време на настройката.
Наблюдение на TempDB
Проследяването на TempDB може да бъде трудно. Как можете да разберете дали имате спор за TempDB? Какво се разпределя на потребителски обекти, хранилище на версии или вътрешни обекти? Как се развиват тези тенденции във времето? Какви сесии консумират TempDB и до каква степен? Spotlight Cloud прави отговорите на тези въпроси лесни. Той следи всички аспекти на производителността на вашия SQL сървър 24/7 и осигурява дълбоки аналитични работни потоци за справяне с всеки проблем с производителността. Проследявайте TempDB във времето и получете автоматизирани експертни съвети относно конфигурацията.
Като SaaS решение, Spotlight Cloud е лесен за настройка и конфигуриране. Той запазва данни за производителността на стойност до една година, давайки ненадмината информация за настройката. Проблемите с производителността могат да бъдат разрешени за секунди с анализ на основната причина. Не губете повече време в ровене в сложни скриптове – започнете своя 30-дневен пробен период сега. Първокласният мониторинг на производителността на SQL Server започва сега.
