В предишната ми статия за системните бази данни на SQL Server научихме за всяка системна база данни, която идва като част от инсталацията на SQL Server. Настоящата статия ще се фокусира върху често срещани проблеми около базата данни tempdb и как да ги разрешите правилно.
SQL Server TempDB
Както показва името на тази системна база данни, tempdb държивременни обекти създаден от SQL Server. Те се отнасят до няколко операции и действат като глобална работна зона за всички потребители, свързващи се към екземпляри на SQL Server.
Базата данни Tempdb ще съдържа следните типове обекти, докато потребителите изпълняват своите операции:
- Временните обекти се създават изрично от потребителите. Те могат да бъдат както локални, така и глобални временни таблици и индекси, променливи в таблицата, таблици, използвани във функции с стойност на таблица, и курсори.
- Вътрешни обекти, създадени от механизма на базата данни, като
- Работни таблици, съхраняващи междинни резултати за буфери, курсори, сортиране и временни големи обекти (LOB).
- Работете файлове, докато извършвате операции за свързване на хеш или обобщаване на хеширане.
- Междинни резултати от сортиране при създаване или повторно изграждане на индекси, ако SORT_IN_TEMPDB е зададено на ON, и други операции като GROUP BY, ORDER BY или SQL UNION заявки.
- Магазините на версиите, които поддържат функцията за управление на версиите на редове, или Common Version store или Online Index build version store, използват файловете на базата данни tempdb.
Базата данни Tempdb се създава всеки път, когато SQL Server Service стартира. Следователно времето на създаване на базата данни tempdb може да се счита за приблизително време за стартиране на услугата на SQL Server. Можем да го идентифицираме от sys.databases DMV като използвате заявката, показана по-долу:
SELECT name, database_id, create_date
FROM sys.databases
WHERE name = 'tempdb'
Въпреки това, действителното стартиране на SQL Server Service включва стартиране на всички системни бази данни в определена последователност. Това може да се случи малко по-рано от времето за създаване на tempdb. Можем да получим стойността с помощта на sys.databases DMV като изпълните заявката по-долу в sys.dm_os_sys_info DMV .
SELECT ms_ticks, sqlserver_start_time_ms_ticks, sqlserver_start_time
FROM sys.dm_os_sys_info
ms_ticks колоната посочва броя милисекунди от стартирането на компютъра или сървъра. sqlserver_start_time_ms_ticks колоната посочва броя милисекунди от ms_ticks номер при стартиране на услугата SQL Server.
Можем да намерим повече информация за реда на базите данни, които са се стартирали при стартиране на услугите на SQL Server в регистъра за грешки на SQL Server.
В SSMS разгънете Управление > Регистъри за грешки в SQL сървъра > отворете текущия регистър на грешките. Приложете Стартиране нагоре база данни филтрирайте и кликнете върху Дата за да го сортирате във възходящ ред:
Можем да видим, че главната база данни е стартирала първа, докато стартира услугата SQL Server. След това последваха всички потребителски бази данни и всички други системни бази данни. Накрая tempdb стартира. Можете също да извлечете тази информация програмно, като изпълните xp_readerrorlog системна процедура:
Забележка :И двата по-горе подхода може да не покажат необходимата информация, ако услугата SQL Server не е била рестартирана наскоро и SQL Server Error Log е рециклиран, което може да е изтласкало по-старите регистрационни файлове за грешки към по-стари файлове. В този случай може да се наложи да сканираме данните в архивираните файлове с регистрационни файлове за грешки на SQL Server.
Често срещани проблеми в SQL TempDB база данни
Тъй като tempdb предоставя глобална работна област за всички потребителски сесии или дейности, тя може да се превърне в пречка за производителността за потребителските операции, ако не е внимателно конфигурирана. В предишната ми статия обсъдихме препоръчаните най-добри практики за внедряване в базата данни tempdb. Въпреки това, дори след като ги приложим, може да срещнем проблеми често:
- Неравномерно нарастване на файловете във tempdb файлове с данни.
- Tempdb файловете с данни нарастват до огромна стойност и трябва да се свият Tempdb.
Неравномерен растеж на файловете между TempDB файлове с данни
Започвайки от SQL Server 2000, препоръката по подразбиране е да имате множество файлове с данни въз основа на броя на наличните логически ядра в сървъра.
Когато имаме множество файлове с данни, например 4 tempdb файла с данни, както е показано на изображението по-долу, автоматичното нарастване на tempdb файлове с данни ще се случи с 64 MB по кръгов начин, започвайки от tempdev> temp2> temp3> temp4> tempdev> и така нататък.
Ако един от размерите на файловете не може да нарасне автоматично по някаква причина, това ще доведе до огромни размери на определени файлове в сравнение с други файлове. Това води до допълнително претоварване на огромни файлове и отрицателно въздействие върху производителността на базата данни tempdb.
Трябва ръчно да гарантираме, че всички tempdb файлове с данни са равномерно оразмерени по всяко време ръчно, за да избегнем проблемите с конкуренцията или производителността до SQL Server 2014. Microsoft промени това поведение, започвайки от SQL Server 2016 и по-нови версии, като внедри няколко функции, които ще бъдат обсъдени по-късно в тази статия.
За да преодолее горните проблеми с производителността, SQL Server въведе 2 флага за проследяване на име 1117 и1118 за да избегнете проблемите със споровете около tempdb.
- Флаг за проследяване 1117 – позволява автоматично нарастване на всички файлове в рамките на една файлова група
- Флаг за проследяване 1118 – активира UNIFORM FULL EXTENTS за tempdb
Флаг за проследяване 1117
Без активиран Trace Flag 1117, всеки път, когато tempdb е конфигуриран с множество файлове с данни, които са равномерно оразмерени и файловете с данни трябва да нарастват автоматично, SQL Server по подразбиране ще се опита да увеличи размерите на файловете по кръгов начин, ако всички файлове. Ако файловете с данни не са оразмерени равномерно, тогава SQL Server ще се опита да увеличи размера на най-големия файл с данни на tempdb и ще използва този по-голям файл за повечето потребителски операции, което води до проблеми с tempdb.
За да разреши този проблем, SQL Server въведе Trace Flag 1117. Веднъж активиран, ако един файл в рамките на файлова група трябва да нараства автоматично, той автоматично ще увеличи всички файлове в тази файлова група. Той решава проблемите със спора за tempdb. Уловката обаче е, че след като флагът за проследяване 1117 е активиран, автоматичното нарастване се конфигурира и за всички потребителски бази данни.
Флаг за проследяване 1118
Флаг за проследяване 1118 се използва за активиране на УНИФОРМНИ ПЪЛНИ ЕКСТРЕНТИ. Нека направим крачка назад, за да разберем как SQL Server съхранява данните от основния.
Страница е основната единица за съхранение в SQL Server с размер 8 килобайта (KB).
Обхват е набор от 8 физически последователни страници с размер 64KB(8*8KB). Въз основа на това колко обекта или собственици съхраняват данните в рамките на екстент, степента може да бъде класифицирана на:
- Единни размери са 8 последователни страници, използвани или достъпни от един обект или собственик;
- Смесено Обхвати – са 8 последователни страници, използвани или достъпни от минимум 2 и максимум 8 обекта или собственици
Активирането на Trace Flag 1118 ще позволи на tempdb да има еднакви екстенти, което води до по-добра производителност.
Как да активирате флагове за проследяване 1117 и 1118
Флаговете за проследяване могат да бъдат активирани чрез няколко подхода. Можете да определите подходящия начин от следните опции:
Параметри за стартиране на услугата SQL Server
Постоянно достъпен дори след рестартиране на SQL услугата. Препоръчителният начин е да активирате Trace Flags 1117 и 1118 чрез параметрите за стартиране на услугата на SQL Server .
Отворете SQL Server Configuration Manager и щракнете върху SQL Server Services за да изброите наличните услуги на този сървър:
- Щракнете с десния бутон върху SQL сървър (MSSQLSERVER) > Свойства > Параметри при стартиране .
- Тип –T в празното поле, за да посочите Флаг за проследяване .
- Посочете стойности 1117 и1118 както е показано по-долу.
- Щракнете върху Добавяне за да добавите флаговете за проследяване като параметри за стартиране.
След това щракнете върху OK за да се добавят трайно флаговете за проследяване за този екземпляр на SQL Server. Рестартирайте услугата SQL Server, за да бъдат отразени промените.
DBCC TRACEON (, -1)
Активирайте глобално флаг за проследяване. Услугата на SQL Server ще загуби флаговете за проследяване при рестартиране на услугата. За да активирате глобално флаг за проследяване, изпълнете скрипта по-долу в нов прозорец за заявка:
DBCC TRACEON(1117,-1);
DBCC TRACEON(1118,-1);
DBCC TRACEON ()
Активирайте флага за проследяване на ниво сесия. Прилага се само за текущата сесия, създадена от потребителя. За да активирате флаг за проследяване на ниво сесия, изпълнете скрипта по-долу в нов прозорец на заявка:
DBCC TRACEON(1117);
DBCC TRACEON(1118);
За да видите списъка с флагове за проследяване, активирани в екземпляр на SQL Server, можем да използваме DBCC TRACESTATUS команда:
DBCC TRACESTATUS();
Както виждаме, Флаговете за проследяване 1117 и 1118 са активирани глобално в моя екземпляр заедно със сесия .
За да изключим Trace Flag, можем да използваме команда DBCC TRACEOFF като:
DBCC TRACEOFF(1117,-1);
DBCC TRACEOFF(1118,-1);
Подобрения на TempDB на SQL Server 2016
Във версиите на SQL Server от SQL Server 2000 до SQL Server 2014, трябва да активираме Trace Flags 1117 и 1118 заедно с пълен мониторинг на tempdb, за да избегнем проблеми с конкуренцията с tempdb. Започвайки от SQL Server 2016 и по-нови версии, флаговете за проследяване 1117 и 1118 се изпълняват по подразбиране.
Въпреки това, въз основа на моя личен опит е по-добре предварително да увеличите tempdb до огромен размер, за да избегнете нуждата от автоматично нарастване многократно и да елиминирате неравномерните размери на файловете или единични файлове, използвани широко от SQL Server .
Можем да проверим как Trace Flag 1117 и 1118 са внедрени в SQL Server 2016:
Флаг за проследяване 1117 което задава автоматичното нарастване на всички файлове във файловата група вече е свойство на файловата група . Можем да го конфигурираме, докато създаваме нова файлова група или модифицираме съществуваща.
За проверка на свойството за автоматично нарастване на файловата група , изпълнете скрипта по-долу от sys.filegroups DMV :
SELECT name Filegroup_Name, is_autogrow_all_files
FROM sys.filegroups
За да промените свойството за автоматично нарастване на основната файлова група на базата данни на AdventureWorks , изпълняваме скрипта по-долу или с AUTOGROW_ALL_FILES, за да увеличим автоматично всички файлове еднакво, или с AUTOGROW_SINGLE_FILE, за да разрешим автоматично нарастване само на един файл с данни.
ALTER DATABASE Adventureworks MODIFY FILEGROUP [PRIMARY]
AUTOGROW_SINGLE_FILE
-- AUTOGROW_ALL_FILES is the default behavior
GO
Флаг за проследяване 1118 което задава свойството Uniform Extent на файловете с данни е активирано по подразбиране за tempdb и всички потребителски бази данни, започвайки от SQL Server 2016 . Не можем да променим свойствата на tempdb, тъй като вече поддържа само опцията Uniform Extent.
За потребителски бази данни можем да променим този параметър. Главният, моделът и msdb системните бази данни поддържат смесени екстенти по подразбиране и също не могат да бъдат променяни.
За да промените стойностите на свойството за разпределяне на смесени страници за потребителски бази данни, използвайте следния скрипт:
ALTER DATABASE Adventureworks SET MIXED_PAGE_ALLOCATION ON
-- OFF is the default behavior
GO
За да проверим свойството за разпределяне на смесена страница, можем да потърсим is_mixed_page_allocation_on колона от sys.databases DMV със стойност като 0, което показва разпределение на страници с еднакъв обхват, и 1 за указване на разпределение на страници със смесен обхват.
SELECT name, is_mixed_page_allocation_on
FROM sys.databases
TempDB файлове с данни нарастват до огромна стойност, изискваща свиване на TempDB
В SQL Server 2014 или по-стари версии, ако флаговете на Trace 1117 и 1118 не са конфигурирани правилно заедно с множество файлове с данни, създадени за базата данни tempdb, някои от тези файлове неизбежно ще нараснат огромни. Ако това се случи, DBA обикновено се опитва да свие файловете с данни tempdb. Но е неправилно подход за справяне с този сценарий.
Има и други налични опции за свиване на tempdb.
Нека разгледаме DBCC командите, достъпни за Shrink tempdb, и въздействието от извършването на тези операции.
DBCC СВИВАНА БАЗА ДАННИ
DBCC СКВИТАНА БАЗА ДАННИ конзолната команда работи чрез свиване на края на Data\Log Files .
За успешно свиване на база данни, командата се нуждае от свободно място в края на файла. Ако има активни транзакции в края на файла, файловете на базата данни не могат да бъдат свити.
Въздействието от изпълнението на DBCC SHRINKDATABASE е, че ще се опита да изчисти наличното свободно пространство в края на всеки файл с данни или регистрационен файл, който може да е бил запазен за бъдещо нарастване на табличните данни. Следователно, изпълнението на тази команда може да доведе до неравномерни размери на файловете, водещи до проблеми с tempdb.
Синтаксисът за свиване на потребителска база данни, например база данни на Adventureworks, би бил
DBCC SHRINKDATABASE (AdventureWorks, TRUNCATEONLY);DBCC SHRINKFILE
DBCC SHRINKFILE конзолната команда работи подобно на DBCC SHRINKDATABASE, но свива посочените данни от база данни или регистрационни файлове .
Ако установите, че конкретен tempdb файл с данни е огромен, можем да опитаме да свием този конкретен елемент с помощта на DBCC SHRINKFILE, както е показано по-долу.
Бъдете внимателни, докато използвате тази команда на tempdb, защото ако файлът се свие до стойност, по-ниска или по-висока от другите файлове с данни, този конкретен файл с данни няма да се използва ефективно. Или ще се използва по-често, което води до проблеми с tempdb.
Синтаксисът за изпълнение на операция DBCC SHRINKFILE върху файл с данни на AdventureWorks до 1GB (1024 MB) би бил:
DBCC SHRINKFILE (AdventureWorks, 1024);
GO
DBCC DROPCLEANBUFFERS
DBCC DROPCLEANBUFFERS командата console се използва за изчистване на всички чисти буфери от буферния пул и обектите columnstore от пула на columnstore .
Просто изпълнете следната команда:
DBCC DROPCLEANBUFFERSDBCC FREEPROCCACHE
DBCC FREEPROCCACHE командата изчиства целия кеш на плана за изпълнение на съхранените процедури .
Кешът на плана за изпълнение на процедурите се използва от SQL Server за по-бързо изпълнение на същите извиквания на процедури. След изпълнение на DBCC FREEPROCCACHE, кешът на плана се изчиства. По този начин SQL Server трябва да създаде този кеш отново, когато съхранената процедура се изпълни в екземпляра. Оставя сериозно отрицателно въздействие, когато се изпълнява в екземпляри на производствената БД.
Не се препоръчва да се изпълнява DBCC FREEPROCCACHE в екземпляр на производствената база данни!
Синтаксисът за изпълнение на DBCC FREEPROCCACHE е по-долу:
DBCC FREEPROCCACHEDBCC FREESESSIONCACHE
DBCC FREESESSIONCACHE командата изчиства кеша на връзката на заявката за разпространение от екземпляра на SQL Server . Ще бъде полезно, когато има много разпределени заявки, изпълнявани на конкретен екземпляр на SQL Server.
Синтаксисът за изпълнение на DBCC FREESESSIONCACHE би бил:
DBCC FREESESSIONCACHEDBCC FREESYSTEMCACHE
DBCC FREESYSTEMCACHE командата изчиства всички неизползвани записи в кеша от целия кеш . SQL Server прави това по подразбиране, за да предостави повече памет за нови операции. Въпреки това можем да го изпълним ръчно, като използваме командата по-долу:
DBCC FREESYSTEMCACHEКакто знаем, tempdb съхранява всички временни потребителски обекти или вътрешни обекти, включително кеш на план за изпълнение, данни за буферен пул, кешове на сесии и системни кешове. Следователно, изпълнението на горните 6 DBCC команди ще помогне за изчистването на файловете с данни tempdb, които предотвратяват нормалния процес на свиване.
Въпреки че сме преминали през стъпки за това как да свием tempdb чрез различни подходи, препоръчителните най-добри практики за работа с база данни tempdb са изброени по-долу:
а. Рестартирайте SQL Server Services, ако е възможно, за да пресъздадете равномерно tempdb файлове с данни. Потенциалното въздействие би било, ще загубим всички планове за изпълнение и друга информация за кеш паметта, обсъдена по-горе.
б. Предварително увеличете tempdb файлове с данни до огромен размер на файла, наличен в устройството, съдържащо файлове с данни tempdb. Това ще попречи на SQL Server да увеличава неравномерно размерите на файловете в SQL Server версии 2014 и по-стари.
в. Ако услугите на SQL Server не могат да бъдат рестартирани поради RTO или RPO, опитайте горните DBCC команди, след като разберете ясно въздействието.
г. Свиването на tempdb база данни или файлове с данни не е препоръчителен подход и следователно никога не правете това във вашата производствена среда, освен ако няма други опции.
Заключение
Научихме повече за вътрешните елементи на това как работи tempdb, така че да можем да конфигурираме tempdb за по-добра производителност, като избягваме проблеми със споровете в tempdb. Ние също така преминахме през често срещаните проблеми в tempdb, мерките, налични в SQL Server в различни версии и как да се справяме ефективно с него. В допълнение към това, ние проучихме защо свиването на база данни tempdb или файлове с данни не е препоръчителен подход при работа с база данни tempdb.
