Поддръжка на системни бази данни на SQL Server

Инсталацията на SQL Server по подразбиране създава няколко системни бази данни на екземпляр, за да поддържа и администрира този екземпляр. В тази статия ще разгледаме тези системни бази данни и ще разберем техните отговорности.

Системни бази данни на SQL сървър

В SQL Server системните бази данни се създават по време на инсталационния процес, за да съхраняват подробностите за конфигурацията, специфични за SQL Server, за да функционират нормално. Всяка инсталация на SQL Server създава минимум 5 системни бази данни и 1 свързана с репликация системна база данни с име разпространителна база данни който ще бъде създаден от потребителите, ако репликацията е конфигурирана в този екземпляр. Всяка база данни на системата има своето предназначение и ние ще проучим това подробно по-късно в тази статия.

Системните бази данни са:

Основно – инсталирано по подразбиране
Msdb – Инсталиран по подразбиране
Модел – Инсталиран по подразбиране
Tempdb – Инсталиран по подразбиране
Ресурс – Инсталиран по подразбиране . Въведено в SQL Server 2005 и налично в по-късни версии на SQL Server и следователно не е налично в SQL Server 2000 и по-стари версии.
Разпространение – Създаден от действие на потребителя . Потребителите могат да създадат базата данни за разпространение, за да конфигурират репликацията.

За да прегледаме системната база данни, инсталирана в SQL Server, можем да използваме SSMS.

Свържете се с вашия екземпляр на SQL Server, разгънете Бази данни > Системни бази данни :

Забелязали ли сте, че Ресурсът липсва ли база данни в горния списък? Работата е там, че базата данни с ресурси е специална системна база данни, която не е посочена в SSMS Object Explorer. Въпреки това можем да потърсим данните за базата данни за ресурси от системен DMV с име sys.sysaltfiles и изпълнете заявката:

SELECT dbid, db_name(dbid) database_name, fileid, name, filename
FROM sys.sysaltfiles
WHERE dbid NOT BETWEEN 5 AND 11

В резултатите можем да видим системните бази данни в ред:master, tempdb, model, msdb, distribute , и накрая, dbid 32767 която е ресурсна база данни. Тази база данни с ресурси обаче не показва никакво име на база данни, тъй като няма запис в sys.databases . Изключих няколко потребителски бази данни между dbid 5 и 11 и включих AdventureWorks_REPL като пример, за да покаже, че DMV може да показва и потребителски бази данни. Ще разгледаме по-подробно за ресурсната база данни и други системни бази данни по-късно.

Ограничения за SQL системни бази данни

Тъй като системните бази данни съдържат критични подробности за системната конфигурация, трябва да има подходящи мерки за сигурност, за да се избегне случайно изтриване на данни. Следователно системните бази данни имат следните ограничения в сравнение с потребителските бази данни:

Системните бази данни не могат да бъдат изведени офлайн

Можем да изведем потребителска база данни офлайн с помощта на командата ALTER DATABASE, както е показано по-долу:

ALTER DATABASE AdventureWorks SET OFFLINE WITH ROLLBACK IMMEDIATE
GO

Ако обаче се опитаме да вземем някоя от системните бази данни ОФЛАЙН с помощта на горната команда, тогава ще получим грешка, както е показано по-долу:

Системните бази данни не могат да бъдат отхвърлени

Докато можем да изтрием потребителските бази данни, като изпълним командата DROP DATABASE

DROP DATABASE AdventureWorks

Ако се опитаме да ОТПУКНЕМ някоя от системните бази данни, ще получим грешката, както е показано по-долу:

Собственикът на системни бази данни не може да бъде променен

Собственикът на системната база данни е sa по подразбиране. Не може да се промени. Опитите за преименуване на собственика на системната база данни ще предизвикат грешки.

Има обаче изключение. Възможно е да промените собственика на msdb база данни.

use [master];
GO
ALTER AUTHORIZATION ON DATABASE::[master] TO [RRJ\RRJ]
GO

Име на база данни на системни бази данни не може да се променя

Ако се опитаме да преименуваме системните бази данни, ще получим съобщение за грешка, както е показано по-долу:

ALTER DATABASE master MODIFY NAME = RRJ_master;
GO

Съпоставянето на системните бази данни не може да бъде променено

Системните бази данни се създават с името на Collation, избрано по време на инсталацията на SQL Server. Веднъж инсталирана, съпоставянето на системните бази данни не може да бъде променено. Единственият начин да промените съпоставянето на системните бази данни е да преинсталирате екземпляра на SQL Server с правилното съпоставяне.

Основната файлова група от системни бази данни не може да бъде настроена в режим ЧЕТЕНЕ.

Тъй като системната база данни улавя критична информация, свързана с екземпляри на SQL Server, SQL Server не позволява на основните файлове с данни, намиращи се в основната файлова група, да бъдат зададени като само за четене .

Функцията за улавяне на промяна на данни не може да бъде активирана в системни бази данни

Тази функция се използва за проследяване на всяка промяна в DML, която се случва в база данни на проследяваните таблици. Ако се опитаме да активираме функцията Change Data Capture на която и да е системна база данни, грешката ще се случи:

use master
GO
exec sys.sp_cdc_enable_db

Сега, когато сме наясно с разликата между системните бази данни и потребителските бази данни, можем да разгледаме по-подробно целите на всяка системна база данни.

Основна база данни в SQL Server

Главната системна база данни съдържа ключови подробности за конфигурацията, свързани с екземпляра на SQL Server . SQL Server разчита на тях, когато стартира конкретен екземпляр. Ако е невъзможно да се стартира основната база данни по някаква причина, екземплярът на SQL Server също не може да стартира.

Тези ключови подробности, съхранявани в главната база данни, включват акаунти за влизане, данни за свързания сървър, крайни точки, настройки за системна конфигурация и подробности за всички потребителски бази данни.

Сега идва въпросът. Как услугата SQL Server знае къде са налични данните и регистрационните файлове на основната база данни? Отговорът се крие в конфигурационните параметри при стартиране на услугата SQL Server.

За да видите параметрите на конфигурацията при стартиране на екземпляр на SQL Server, първо трябва да знаем за вградения инструмент с име SQL Server Configuration Manager . Той помага да се управляват всички услуги, свързани с SQL Server, на всички екземпляри, налични на конкретния сървър. За да видите тези данни, отворете SQL Server Configuration Manager и той ще покаже списъка, както е показано по-долу:

Щракнете върху SQL Server Services за да видите списъка с услуги, налични на този сървър или компютър:

Изчакай за секунда! Изглежда познато на services.msc изброява всички услуги, налични в сървъра, но показва само услуги, свързани със SQL Server.

Нека отворим services.msc за да видите как изглежда и да проверите разликите между SQL Server Configuration Manager и services.msc да сравни кой е по-добър.

Мениджърът на конфигурацията на SQL Server показва идентификатора на процеса на услугите, които се изпълняват в момента. Не можахме да го намерим в services.msc . Разбира се, можем да получим тази информация от Windows Task Manager, но SQL Server Configuration Manager ни помогна да видим това на едно място.

Сега, нека разгледаме подробно. Щракнете с десния бутон върху услугата SQL Server от services.msc . Ще видите следните менюта:Общи , Влезте ,Възстановяване , и Зависимости .

От SQL Server Configuration Manager щракнете с десния бутон върху SQL Server(MSSQLSERVER) услуга> Свойства . Той изброява следните менюта – Вход, Сервиз. FileStream, Advanced, Alwayson OnHigh Availability , и Параметри при стартиране .

Параметри за стартиране на Услугата, която съхранява местоположението на главната база данни и регистрационните файлове беше достъпна само в SQL Server Configuration Manager .

Щракнете върху Параметри при стартиране за да видите подробностите – за Съществуващи Параметри . Ще видите следната информация:

Физическото местоположение на главната база данни Файл с данни
Физическото местоположение на главната база данни Регистрационен файл на транзакциите
Физическото местоположение на Папката ErrorLog където се намират грешки, свързани с SQL Server Service.

Можем да добавим още параметри за стартиране като Режим на един потребител (-m) , и т.н. За това трябва да посочим необходимите стойности в Задаване на параметър за стартиране и щракнете върху Добавяне .

Забелязахме, че SQL Server Configuration Manager не само показва разширени подробности, но също така ни позволява да правим много разширени конфигурации, свързани с услугата на SQL Server. Следователно аз лично бих препоръчал използването на SQL Server Configuration Manager за спиране/стартиране на услуги, свързани с SQL Server, в сравнение с опцията Services.msc по подразбиране.

Препоръчани практики за основна база данни

Тъй като основната база данни съхранява критични подробности за екземпляра на SQL Server, се препоръчва да следвате най-добрите практики, докато боравите с тази база данни.

Всяка промяна в конфигурацията на екземпляр на SQL Server ще се съхранява в главната база данни. По този начин винаги трябва да правите пълно архивиране на главната база данни, за да се възстанови до най-новото състояние, в случай че възстановяваме главната база данни от пълното архивиране, както е необходимо.

Въпреки че SQL Server позволява на потребителите да създават потребителски таблици или други обекти в главната база данни, не се препоръчва да правите това. Основната база данни трябва да остане проста и чиста. Ако трябва да създадете потребителски обекти в главната база данни, трябва да правите Пълни архиви на главната база данни по-често.

SQL Server поддържа опцията за процедура при стартиране за изпълнение на определени Съхранени процедури при стартиране на екземпляр на SQL Server. Той използва sp_procoption процедура. Бъдете внимателни, докато използвате тази опция, защото наличието на неоптимален код или рекурсивна логика може да повлияе на времето за стартиране на екземпляра на SQL Server.

Ако SQL Server не може да се стартира поради проблеми с главната база данни, трябва да възстановим главната база данни от последното известно добро архивиране.

Моделна база данни в SQL Server

Както показва името, Моделна системна база данни действа като модел или шаблон за създаване на всяка потребителска база данни по отношение на пътя на файла, първоначалния размер, настройките за автоматично нарастване и модела за възстановяване и други опции за конфигурация .

Всички потребителски обекти като таблици, процедури и т.н., които са създадени в базите данни на модела, също ще бъдат създадени автоматично в нови потребителски бази данни в този екземпляр на SQL Server.

Нека проверим това, като направим нова таблица в базата данни на модела:

Нека проверим дали тази таблица присъства в базата данни на модела:

Базата данни на модела също така съхранява по подразбиране файловия път на потребителските бази данни, както е показано по-долу в Свойства на базата данни на msdb база данни.

Според текущата конфигурация, Началният размер на файла от двете Данни и Регистрационни файлове е настроен на 8 MB с автоматично нарастване и за двете е зададено на 64 MB.

Ако трябва да създадете потребителска база данни в различен път на файла вместо местоположението на файла на базата данни на модела, можем да я променим в Свойства на сървъра на този екземпляр на SQL Server.

В SSMS щракнете с десния бутон върху Сървър > Свойства > Настройки на базата данни . Вижте местоположенията по подразбиране в базата данни:

Променете пътя на файла към желания път и щракнете върху OK . Потребителската база данни Данни и Регистър файловете ще бъдат създадени по новия път, който сте посочили.

Нека създадем нова база данни с име model_test и проверете пътеките на новата база данни и регистрационните файлове заедно със свойствата на файла за първоначален и автоматичен растеж и model_verify таблица в новата база данни.

Нека проверим model_test Пътища за данни и регистрационни файлове. Щракнете с десния бутон върху model_test база данни> Свойства > Файлове :

Както виждаме, Данните и Регистър файлове на model_test база данни се създават според пътя, наличен в базата данни на модела. Стойността на първоначалния размер на файла на данните и регистрационните файлове е 8 MB. Стойността на Autogrowth е 64 MB. Тези стойности съответстват на конфигурацията на базата данни на модела.

Сега ще проверим дали model_verify таблицата се създава в model_test база данни. Можем да видим тази нова база данни.

Освен таблици, това се отнася за изгледи, съхранени процедури, функции и всякакви обекти, създадени в базите данни на модела.

Препоръчани практики за база данни за модели

Тъй като моделната база данни действа като шаблон за създаване на всяка нова потребителска база данни, трябва да приложим следните практики, когато работим с нея:

Всеки път, когато искате да приложите промени в конфигурацията на базата данни на модела (напр. начален размер на файла, размер на автоматично нарастване, създаване, модифициране или изтриване на потребителски обекти), незабавно направете пълно архивиране на базата данни на модела.

Тъй като всички потребителски обекти, създадени в базите данни на модела, се създават във всякакви потребителски бази данни, внимавайте да добавяте само задължителните обекти. В противен случай във всички потребителски бази данни ще бъдат създадени много ненужни обекти и ще прекарате много време в сортирането им и почистването на вашите бази данни.

Конфигурирайте първоначалния размер на файла и параметрите за автоматично нарастване за данните и регистрационните файлове. Той помага да се управляват по-добре размерите на данните и регистрационните файлове в потребителските бази данни и да се подобри производителността.

База данни MSDB

Системната база данни msdb съхранява следната критична информация в системните таблици:

Елементи, свързани с агента на SQL Server, като работни места, хронология на работни места, сигнали, оператори, прокси сървъри и др.
Функции на SQL Server като Service Broker и Database Mail с подробности за конфигурацията и историята.
Подробностите за архивиране и възстановяване на SQL Server се съхраняват в таблиците на базата данни msdb.
Конфигурации за доставка на регистрационни файлове, профили на агент за репликация и конфигурации на колектора на данни.
Планове за поддръжка, SSIS пакети и някои други подробности.

С други думи, системната база данни msdb съхранява цялата критична информация, свързана с SQL Server Agent Services и някои други свързани услуги.

Препоръчани практики за msdb база данни

База данни msdb съхранява много критична информация за конфигурацията, свързана с SQL Server агенти, работни места и поща на база данни. Той също така съхранява исторически подробности. Следователно, трябва да приложим следните практики, когато работим с базата данни msdb:

В екземпляр на SQL Server с много конфигурирани бази данни или задания, размерът на базата данни msdb ще се увеличава непрекъснато през известно време. Следователно пълните архиви трябва да се прилагат за базите данни msdb ежедневно заедно с други потребителски бази данни. Ако msdb получи много критична информация, тогава можем да променим модела за възстановяване на базата данни msdb на пълен и след това да приложим и архивиране на журнала на транзакциите.

Въпреки че SQL Server позволява на потребителите да създават потребителски обекти в базата данни msdb, се препоръчва да не създавате никакви потребителски таблици или обекти в базата данни msdb и да увеличавате допълнително размера на базата данни msdb.

Извършвайте редовно почистване на системните таблици msdb, за да поддържате размера на базата данни msdb под контрол и да избегнете въздействието върху производителността от наличието на огромни данни в няколко таблици.

Tempdb база данни

Системната база данни tempdb може да се разглежда като глобална работна област, достъпна за всички потребители, свързани към екземпляра на SQL Server, за да изпълнят своите SELECT или други операции .

Базата данни Tempdb ще съдържа следните типове обекти, докато потребителите изпълняват своите операции:

Временните обекти, създадени изрично от потребителите, могат да бъдат или локални, или глобални временни таблици и индекси, променливи на таблици, таблици, използвани във функции с стойност на таблица, и курсори.
Вътрешни обекти, създадени от механизма на базата данни, като:
- Работни таблици, използвани за междинни резултати за макари, курсори, сортиране и временни големи обекти (LOB)
- Работни файлове за операции за свързване на хеш или обобщаване на хеш
- Междинни резултати от сортиране, докато се занимавате със създаване или повторно изграждане на индекси, ако SORT_IN_TEMPDB е настроен на ON и други операции като заявки GROUP BY, ORDER BY или UNION
Съхранения на версии, които поддържат функцията за управление на версиите на редове или общо съхранение на версии, или онлайн съхранение на версии за компилиране на индекс.

Всеки път, когато услугата SQL Server се стартира или рестартира, базата данни tempdb ще бъде създадена наново с помощта на базата данни на модела. По този начин tempdb е единствената системна база данни, която не може да бъде архивирана .

Ако се опитаме да го архивираме, ще получим грешки:

Тъй като използваме tempdb в почти всички потребителски операции, тази база данни представлява значително затруднение в производителността в няколко версии на SQL Server. Започвайки от SQL Server 2016, имаше няколко техники за оптимизация, внедрени от Microsoft – ще ги обсъдим по-късно.

Преди да преминем към препоръчителните практики за базата данни tempdb, нека разгледаме бързо нейните файлове с данни под конфигурацията по подразбиране, както е показано по-долу:

За моя текущ екземпляр на SQL Server имаме 4 файла с данни и един регистрационен файл за базата данни tempdb.

Започвайки от SQL Server 2016, имаме инсталационна програма на SQL Server, която ни позволява да добавяме множество файлове към tempdb. Горните 4 файла с първоначален размер от 8 MB и размер на автоматичен растеж от 64 MB бяха създадени с помощта на опциите по подразбиране, показани по-долу.

Ако имаме един файл с данни в базата данни tempdb, всички налични логически ядра в сървъра се опитват да осъществят достъп до същия файл с данни на tempdb, което води до затруднение в производителността.

Наличието на множество файлове с данни логически ще асоциира определени ядра с един файл. По този начин имаме по-малко спорове относно tempdb файлове с данни. Това ще подобри въздействието върху производителността върху tempdb файловете с данни.

Препоръчани практики за база данни tempdb

Тъй като базата данни tempdb е като глобална работна област за всички потребителски дейности, размерът на tempdb се увеличава в зависимост от дейностите на потребителите. Това може да бъде затруднено място в производителността за целия екземпляр на SQL Server.

Следователно трябва да приложим следните практики:

Поставете tempdb данни и регистрационни файлове във високопроизводително хранилище, за да получите по-високи IOPS за по-добра производителност.
Уверете се, че базата данни tempdb е разделена на множество файлове с данни, за да намалите споровете и да избегнете затруднения в производителността на базата данни tempdb.
- Ако броят на логическите ядра е по-малък от 8, можем да имаме един файл с данни tempdb на логическо ядро. В нашия тестов екземпляр имахме 4 логически ядра. Следователно 4 файла с данни в tempdb трябва да са достатъчни.
- Ако броят на логическите ядра е повече от 8, започнете с 8 файла с данни и увеличете с 4 файла с данни, ако се наблюдават проблеми с конкуренцията и производителността в базата данни tempdb.
- Ако броят на логическите ядра в сървъра е 32 или 64, можем да започнем с 8 файла с данни. Това означава, че 4 ядра или 8 ядра са свързани логически за един файл с данни.
  
  За повече яснота относно множество tempdb файлове с данни, бих ви препоръчал отличната статия на Пол Рандал.
Уверете се, че файловете с данни tempdb са конфигурирани с оптимален първоначален размер на файла. В идеалния случай това трябва да бъде постигнато чрез подход на проба и грешка. Tempdb с оптимален първоначален размер на файла има тенденция да расте по-малко пъти в сравнение с tempdb, конфигуриран с по-малък първоначален размер на файла, който има тенденция да нараства няколко пъти, което води до фрагментация. Например, в текущата конфигурация всички файлове са конфигурирани с първоначален размер на файла от 8 MB, който е твърде малък за обработка на SQL работни натоварвания. По този начин приложете подхода „проба и грешка“ и задайте първоначалния размер на файла на 512 MB или 1 GB или някаква друга стойност.
Уверете се, че всички tempdb файлове с данни са настроени на еднакъв размер на файла. Свойствата за автоматичен растеж трябва да бъдат дефинирани еднакво. В нашия сценарий всички файлове са настроени на 64 MB автоматично нарастване. Задаването на размера на Autogrowth на 512 MB или 1 GB или всяка друга подходяща стойност помага да се намали честото автоматично нарастване на tempdb файлове с данни.
Уверете се, че първоначалният размер на файла и автоматичният растеж за tempdb регистрационния файл са конфигурирани на оптимална стойност, подобна на tempdb файловете с данни. Тъй като моделът за възстановяване на tempdb е настроен на Simple по подразбиране и не може да бъде променен, конфигурирането на първоначалния размер на файла и свойството за автоматично нарастване на регистрационния файл на tempdb трябва да е достатъчно.

Tempdb е жизненоважен за производителността на екземпляра на SQL Server. Ще разгледаме подробно често срещаните проблеми при tempdb и как да го свием оптимално в следващите ни статии.

Ресурсна база данни в SQL Server

База данни на ресурсната система е единствената системна база данни само за четене, която не е изброена в системните бази данни в SSMS, както се вижда по-рано.

Идентификаторът на базата данни (dbid) от ресурсните бази данни във всички екземпляри ще бъде 32767, което също е максималният брой бази данни, поддържани в екземпляр на SQL Server. Може да бъде поискано от sys.sysaltfiles система DMV. Изпълнение на заявката SELECT по-долу на sys.sysaltfiles ще върне набора от резултати показва къде се намират файловете с данни и журнал на ресурсната база данни:

Можем да видим физически файлове на ресурсната база данни, налични в гореспоменатия път. Датата на промяна показва часа на инсталиране на екземпляр на SQL Server или последния път, когато към този екземпляр се прилагат сервизни пакети (SP) или сборна актуализация (CU).

Ресурсната база данни съдържа всички системни обекти, като sys.objects , sys.databases , sys.sysaltfiles , и т. физически вътре в него. Тази база данни изброява логически всички тези обекти под схемата на sys във всички налични бази данни в екземпляра . Тъй като ресурсната база данни е само за четене, в нея не могат да се създават потребителски обекти или данни.

Базата данни на системата за ресурси беше въведена, започвайки от SQL Server 2005, за да направи надстройката на SQL Server до нова версия на SP или CU по-бърза. Преди въвеждането на тази опция, всички подобни надстройки и актуализации означаваха, че промените ще се прилагат във всички бази данни, което прави процеса на надстройка по-сложен и отнема много време. Сега всяка надстройка на версията на SQL Server или актуализацията на SP или CU просто надгражда или заменя ресурсната база данни.

Тъй като ресурсната база данни е само за четене и не се вижда от потребителите, тя не изисква никаква намеса на потребителя. Ако искате да включите резервно копие на база данни с ресурси във вашето планиране за висока наличност или възстановяване след бедствие, просто направете резервно копие на файловете mssqlsystemresource.mdf и mssqlsystemresource.ldf след спиране на услугите на SQL Server (услугата SQL Server няма да позволи копиране на файловете, докато Услугата SQL Server е стартирана и работи) и я запазете на сигурно място. Внимавайте да не го актуализирате на който и да е екземпляр на SQL Server, работещ с различна версия на SP или CU нива, тъй като това може да причини неочаквани проблеми.

База данни за разпространение в SQL Server

Базата данни на системата за разпространение е сърцето на репликацията. Потребителите могат да създават или конфигурират база данни за разпространение като част от настройката за репликация с помощта на съветника за конфигуриране на разпространение или съветника за създаване на публикация. Описахме подробно стъпките за създаване на база данни за дистрибуция като част от предишната ми статия за вътрешните елементи на транзакционната репликация на SQL Server.

Препоръчани практики за база данни за разпространение

Тъй като базата данни за разпространение е от съществено значение за функционалността на репликацията, трябва да приложим следните практики:

Преместете данните и регистрационните файлове на базата данни за разпространение на устройството с добри IOPS, за да избегнете проблеми с производителността на разпространението.

Конфигурирайте свойствата на началния размер на файла и Autogrowth на базата данни за разпространение на по-добра стойност, за да избегнете проблеми с фрагментацията.

Включете база данни за разпространение към заданията за поддръжка на пълната база данни.

Включете бази данни за разпространение към заданията за поддръжка на индекса, за да избегнете проблеми с фрагментацията и производителността.

В моята статия за вътрешните елементи на репликацията на транзакции на SQL Server ще намерите и препоръки за други ефективни практики.

Заключение

Благодарим ви, че разгледахте още една богата статия!

Надявам се, че ви помогна да изясните същността и целите на системните бази данни на SQL Server и да научите най-добрите практики за избягване на проблеми с производителността на тези бази данни.