Изпълнението на DBCC Shrink команди е доста спорен проблем в общността на SQL Server. В тази статия ще прегледаме подробности за тази команда и ще предоставим кратък преглед на нейното използване, както и ще ви предупредим за рисковете от изпълнението на тази команда. Като DBA, редица бази данни бяха предадени на други екипи или доставчици и не винаги успяваме да управляваме базите данни, които създадохме. Като администратори на база данни, винаги когато участваме в миграции или нови проекти, ние трябва да гарантираме, че внимателно планираме плавен преход на базата данни към производство и редовна употреба. Именно на този етап трябва да вземем предвид размера на базата данни. Можете ли да си представите, че настройвате приложение за база данни, без да вземете предвид прогнозата за растеж за първата година. Какво ще кажете да създадете база данни на SQL Server с толкова малък размер, че трябва да нараства всеки ден, увеличавайки капацитета на дисковите сигнали посред нощ? Може да звучи глупаво, но в действителност истината е, че това се случва и понякога това може да не е във вашия контрол.
Няколко точки, които трябва да имате предвид за Proactive DBA
Преди да поемете поддръжката на производствените бази данни, не забравяйте да проверите с вашия предшественик какви са прогнозите по отношение на растежа на базата данни. Първоначалният размер на базите данни, които ще управлявате, подходящ ли е? Не се притеснявайте твърде много, ако текущият размер на базата данни е много по-голям от данните, които има в момента. Не забравяйте, че не искате тези обаждания за капацитет на диска в 3:00 сутринта, когато бихте могли напълно да го избегнете, като имате база данни с правилния размер. Обща тенденция е администраторите на бази данни в цялата индустрия да жертват живота си късно през нощта по ежедневни проблеми, които не би трябвало да се случват на първо място. Освен това, заедно с размера на базата данни, имайте предвид и капацитета на диска на сървъра. Не искате размерът на диска да е твърде малък от това, което базата данни може да побере. Всичко това са прости неща, които са полезни по време на планирането. Въпреки това, както знаете, не винаги специалист по база данни инсталира или конфигурира бази данни на първо място. Важният момент, който трябва да се отбележи, е да разберете основите с вашата база данни по отношение на оразмеряването и може да не се налага да изпълнявате тази команда. Въпреки това, както винаги, като DBA, има моменти, когато нещата може да не са под вашия контрол и през това време можете да използвате команди на DBCC Shrink file за ефективно използване.
Кога мога да използвам DBCC ShrinkFile?
Току-що получихте сигнал за дисково пространство точно по средата на съня си и имате стриктни SLA, които трябва да изпълните. Нивото на приоритет е P2 и SLA може да наруши много скоро. И разбирате, че разширяването на диска няма да се случи скоро, добре, в такъв случай дръжте вашите DBCC ShrinkFile команди под ръка, за да можете да ги използвате, за да си върнете пространството. Както подсказва името, той свива файла с данните или регистрационния файл на базата данни. Но преди да започнете да изпълнявате командите DBCC ShrinkFile, опитайте се да проверите защо файлът на базата данни се разраства на първо място.
- Файлът нарасна ли поради някаква продължителна транзакция?
- Има ли някакъв вид блокиране на сървъра?
- Случва ли се някаква голяма версия на приложението, за която не сте били информирани? (Това се случва през повечето време)
- Има ли някакъв вид репликация на база данни или проблем с огледално отразяване, причиняващ растеж на базата данни?
Важно е да получите отговори на тези въпроси възможно най-бързо. Като цяло има един отговор на всички тези въпроси и това е страхотен безплатен инструмент, наречен sp_whoisactive. Няма думи, които да опишат огромното използване на този инструмент и съм го използвал многократно, за да коригирам множество проблеми, свързани с производството. Можете да изтеглите най-новия код от тази връзка:http://whoisactive.com/. Той е лесен и лесен за използване и връща изхода за нула време. Ако сте опитен DBA, вече ще имате това на ваше разположение.
DBCC ShrinkFile с примери
Синтаксисът за DBCC ShrinkFile е прост и ясен, вижте този пример по-долу.
use YOURDATABASE go DBCC Shrinkfile(FileName,1024)
Горният пример свива FileName, принадлежащ на YOURDATABASE до 1024 MB. Можете да извършите същата операция с помощта на SQL Server Management Studio (SSMS). Щракнете с десния бутон върху базата данни, отидете на Задачи , изберете Свиване , а след това Файлове .
След като щракнете върху Файлове , ще получите този прозорец.
Тук имате възможност да изберете типа на файла:Данни, Регистрационен файл или Данни за файлов поток и да извършите „Действие за свиване“, както е необходимо. По-лесно е да използвате самата команда DBCC за целите на свиването.
Използване на DBCC ShrinkFile с допълнителни опции
Можете да изпълните командата DBCC ShrinkFile с допълнителни опции – emptyfile, notruncate или truncateonly.
Празен файл
Можете да използвате командата за празен файл, както е по-долу.
use YOURDATABASE go dbcc shrinkfile(FileName,emptyfile)
Това ще ви помогне да преместите данните в други файлове в рамките на същата файлова група. След като приключите, ще можете да изтриете файл с база данни, ако той вече не е необходим. Има обаче няколко неща, които трябва да се отбележат с тази опция за празен файл, тъй като не бихте могли да направите много, за да изпразните съдържанието на основния файл с данни с идентификатор на файл 1. За да получите идентификационния номер на файла, изпълнете този скрипт.
select file_id, name,physical_name from sys.database_files
Тук, в този пример, името на файла е „mo“, а file_id е 1. Когато се опитате да изпразните файла mo, който има file_id 1, ще срещнете това съобщение за грешка.
Това е така, защото в оригиналния файл има системна информация, която не може да бъде изпразнена. Но ако опитате същата команда с другия файл с данни „mo2data“, командата за празен файл ще успее.
Не отрязване
Както подсказва името, няма място, освободено обратно към ОС. Това е по-скоро като вътрешна операция във файла, при която страниците се преразпределят в самия файл, без да се променя общият размер на файла на базата данни. Поради това съществува огромна възможност за въвеждане на фрагментация. Вижте примера по-долу.
-- Example only Use YourDatabase go DBCC SHRINKFILE (filename,notruncate); GO
Само отрязване
Както подсказва името, свободното пространство ще бъде освободено обратно в операционната система от края на файла. Това е най-сигурната операция, която можете да изпълните с помощта на DBCC ShrinkFile. Вижте примера по-долу.
-- Example only Use YourDatabase go DBCC SHRINKFILE (filename,truncateonly); GO
Какво да направите, когато DBCC ShrinkFile в регистъра на транзакциите не работи според очакванията? Вижте този безопасен метод, за да отстраните проблемата
Има моменти, когато тази команда може да не работи според очакванията. Ако приемем, че имате ситуация, в която се опитвате да свиете регистрационния файл на база данни и изглежда не работи. По-долу са няколко от стъпките, които може да предприемете, за да разберете защо свиването не работи според очакванията. Ще забележите, че свиващият файл ще се покаже като успешен, но няма намаляване на размера на регистрационния файл. В такъв случай изпълнете тази команда, за да проверите няколко неща за използването на регистрационния файл.
select name,log_reuse_wait_desc,* from sys.databases
От екранната снимка можете да видите, че колоната log_reuse_wait_desc изчаква архивиране на регистрационни файлове.
Тук можете да видите, че архивирането на регистрационните файлове за базата данни трябва да се извърши, преди да можете наистина да свиете регистрационния файл. Ако това е в производствена база данни, опитайте да изпълните архивирането на журнала на друго устройство, където има налично място. За да извършите архивирането на журнала, използвайте примерната команда по-долу.
backup log DBName to disk='C:\Program Files\Microsoft SQL Server\MSSQL15.A1\MSSQL\Backup\DBName.trn' with init,stats,compression
След като изпълните командата за архивиране, изпълнете отново командата по-долу, за да видите състоянието на колоната log_reuse_wait_desc.
select name,log_reuse_wait_desc,* from sys.databases
От екранната снимка можете да видите, че състоянието на колоната log_reuse_wait_desc се е променило на „Нищо“.
Тук можете да видите, че състоянието на колоната „log_reuse_wait_desc“ се е променило на „Нищо“. Във вашия случай все още може да се показва като „LOG_BACKUP“. Продължете да извършвате архивиране на регистрационните файлове за базата данни, докато състоянието се промени на „Нищо“. Причината, поради която все още може да виждате състоянието „LOG_BACKUP“ дори след извършване на архивиране на регистрационните файлове на транзакциите, е, че може да не са били изчистени VLF, след като сте изпълнили архивирането на регистрационния файл на транзакциите. VLF означава виртуални регистрационни файлове и е част от вътрешната архитектура на регистъра на транзакциите. Регистрационните файлове на транзакциите са съставени от тези VLF. Можете да получите информация за VLF, като изпълните тази команда.
select * from sys.dm_db_log_info(5)
Тук 5 представлява database_id. Показва се екранната снимка на изхода. Броят на върнатите редове представлява действителния брой виртуални регистрационни файлове (VLF) в базата данни. Можете да проверите колоната „vlf_status“, за да проверите състоянието на виртуалния регистрационен файл. Стойност 2 означава, че е активен. С тази команда можете да проверите вътрешните флагове в регистрационния файл на транзакциите, за да разберете защо регистърът на транзакциите не се освобождава дори след извършване на архивиране на регистрационни файлове.
Преди това използваната команда беше DBCC LOGINFO, която предоставяше подобна информация.
Какво да направите, когато DBCC ShrinkFile в регистъра на транзакциите не работи според очакванията? Нещо, което можете да изпълнявате в непродукционна среда. Не се препоръчва обаче в производствена средата
Бихте срещнали на множество уебсайтове хора, които препоръчват да промените модела за възстановяване на прост и след това да стартирате свиващ файл, за да освободите място обратно към операционната система. Имайте предвид, че промяната на модела за възстановяване на прост ще повлияе на възстановяването на вашата база данни, тъй като няма да можете да възстановите до определен момент от време. Това отново зависи от вашия бизнес SLA. Можете да промените модела за възстановяване, като използвате T-SQL (по-долу) или с помощта на GUI.
alter database DB_NAME set recovery simple
С помощта на GUI променете модела за възстановяване, както е показано. Щракнете с десния бутон върху базата данни, отидете на „Свойства“, щракнете върху „Опции“. Под „Опции“ изберете „Модел за възстановяване“.
Ще забележите, че само промяната на модела за възстановяване на Simple няма да освободи пространството обратно към ОС. Ще трябва изрично да изпълните командата DBCC ShrinkFile, за да свиете файла и да възстановите пространството. Вижте примерния скрипт по-долу. Тази команда ще свие вашето FileName до 1024 MB.
use YOURDATABASE go DBCC Shrinkfile(FileName,1024)
Опция за автоматично свиване на базата данни
Ще забележите, че има опция, известна като „Автоматично свиване“ в свойствата на базата данни. Просто щракнете с десния бутон върху базата данни, за да видите свойството на базата данни. Под секцията с опции ще видите тази опция, както е показано. От настройката на базата данни на модела можете да видите, че опцията „Автоматично свиване“ е деактивирана по подразбиране. Така че, когато се създава нова база данни, тази опция също е в деактивирано състояние. Може да има някои случаи, в които специалистите по бази данни може несъзнателно да оставят тази опция активирана, без да са наясно с негативните последици от оставянето й включена.
Изпълнете тази команда, за да проверите състоянието на тази опция за базите данни на сървъра.
select name,is_auto_shrink_on,* from sys.databases
Ще видите този изход.
Ако случайно видите, че е активиран, можете да го деактивирате или като използвате графичния интерфейс, или можете да изпълните командата по-долу срещу базата данни.
ALTER DATABASE YOUR_DATABASE set AUTO_SHRINK OFF
Други предложения за поддръжка
Вижте тези няколко допълнителни съвета, за да избегнете проблема с нарастването на базата данни, поради което трябва да изпълнявате команди DBCC ShrinkFile.
- Уверете се, че моделът за възстановяване на вашите бази данни е в съответствие с бизнес SLA. Ако вашият бизнес не изисква възстановяване в даден момент за тестови бази данни, просто ги оставете в прост модел за възстановяване. Виждал съм няколко пъти, когато моделът за възстановяване на базите данни е завършен, когато нещата са наред с възстановяването с помощта на последното пълно архивиране
- Осигурете подходящо наблюдение, особено с нарастването на базата данни. Трябва да бъдете предупредени, когато използването на регистрационния файл достигне 85 %. Това ще ви даде известно време да разрешите проблема с пространството
- Уверете се, че се правят редовни архивни копия на регистрационни файлове, ако базата данни е в модел на пълно възстановяване и трябва да бъдете предупредени, ако някое от архивирането на регистрационни файлове не успее.
- Уверете се, че има достатъчно място на дисковете на базата данни, за да избегнете проблеми с недостига на място
- За бази данни, които могат да се архивират, разработете някои стратегии за архивиране, така че да можете да преместите по-стари данни в друга база данни, за да създадете отчети и да направите тази база данни само за четене. Това ще ви даде повече контрол по отношение на оразмеряването на базата данни
- Уверете се, че извършвате редовно проверки на целостта на вашата база данни с помощта на DBCC CheckDB. За повече информация вижте тази статия:https://codingsight.com/dbcc-checkdb-overview/
Заключение
- От тази статия сте разбрали добре използването на командата DBCC ShrinkFile
- Научихте за рисковете от изпълнението на командите DBCC ShrinkFile
- Научихте различните опции, които можем да предоставим с помощта на командите DBCC ShrinkFile
- Видяхте опциите, които можем да опитаме, ако регистърът на транзакциите не се свива с помощта на командите DBCC ShrinkFile
- Научихте за настройката за автоматично свиване по подразбиране в свойството на базата данни
- Научихте и други предложения за поддръжка на база данни, за да поддържате базите си здрави
- Накрая, уверете се, че сте готови във всеки случай за онези дни OFF, които може да не са под вашия контрол
