С изтичането на 2014 г. започвам поредица от публикации за проактивни проверки на здравето на SQL Server, въз основа на една, която написах обратно в началото на тази година – Проблеми с производителността:Първата среща. В тази публикация обсъдих какво търся първо, когато отстранявам проблем с производителността в непозната среда. В тази серия от публикации искам да говоря за това, което търся, когато се регистрирам с моите дългогодишни клиенти. Ние предоставяме услуга за отдалечен DBA и една от редовните ни задачи е ежемесечен „мини“ одит на здравето на тяхната среда. Имаме мониторинг и обикновено работя по проекти, така че съм в средата редовно. Но като допълнителна стъпка, за да сме сигурни, че не пропускаме нищо, веднъж месечно преминаваме през същите данни, които събираме в нашия стандартен здравен одит, и търсим нещо необикновено. Това може да са много неща, нали? Да! И така, нека започнем с пространството.
Уау, космос? Да, пространство. Не се притеснявай, ще премина към други теми. ☺
Какво да проверя
Защо да започна с пространството? Тъй като това е нещо, което често виждам пренебрегвано и ако ви свърши дисково пространство за вашите файлове на база данни, вие ставате изключително ограничени в това, което можете да правите във вашата база данни. Трябва да добавите данни, но не можете да увеличите файла, защото дискът е пълен? За съжаление, сега потребителите не могат да добавят данни. Не правите резервни копия на регистрационни файлове по някаква причина, така че регистърът на транзакциите запълва устройството? За съжаление, сега не можете да променяте никакви данни. Пространството е критично. Имаме задачи, които следят свободното място на диска и във файловете, но аз все пак проверявам следното за всеки одит и сравнявам стойностите с тези от предходния месец:
- Размер на всеки регистрационен файл
- Размер на всеки файл с данни
- Свободно място във всеки файл с данни
- Свободно място на всяко устройство с файлове от база данни
- Свободно място на всяко устройство с архивни файлове
Разрастване на регистрационните файлове
Повечето проблеми, които виждам, свързани с дисковото пространство, се дължат на растежа на регистрационните файлове. Растежът обикновено се случва по една от двете причини:
- Базата данни е в ПЪЛНО възстановяване и по някаква причина не се правят резервни копия на регистрационните файлове на транзакциите
- Някой изпълнява една, много голяма транзакция, която консумира цялото съществуващо лог пространство, принуждавайки файла да нараства
Също така видях как регистрационният файл нараства като част от поддръжката на индекса. За повторно изграждане всяко разпределение се регистрира, а за големи индекси, които могат да генерират значително количество журнал. Дори и при редовно архивиране на регистрационните файлове на транзакциите, регистрационният файл все още може да расте по-бързо, отколкото архивирането може да се случи. За да управлявате дневника, трябва да коригирате честотата на архивиране или да промените методологията си за поддръжка на индекса.
Трябва да определите защо регистрационният файл е нараснал, което може да бъде сложно, освен ако не го проследявате. Имам задание, което се изпълнява на всеки час за размер и използване на регистрационния файл за моментна снимка:
USE [Baselines];
GO
IF (NOT EXISTS (SELECT *
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'dbo'
AND TABLE_NAME = 'SQLskills_TrackLogSpace'))
BEGIN
CREATE TABLE [dbo].[SQLskills_TrackLogSpace](
[DatabaseName] [VARCHAR](250) NULL,
[LogSizeMB] [DECIMAL](38, 0) NULL,
[LogSpaceUsed] [DECIMAL](38, 0) NULL,
[LogStatus] [TINYINT] NULL,
[CaptureDate] [DATETIME2](7) NULL
) ON [PRIMARY];
ALTER TABLE [dbo].[SQLskills_TrackLogSpace] ADD DEFAULT (SYSDATETIME()) FOR [CaptureDate];
END
CREATE TABLE #LogSpace_Temp (
DatabaseName VARCHAR(100),
LogSizeMB DECIMAL(10,2),
LogSpaceUsed DECIMAL(10,2),
LogStatus VARCHAR(1)
);
INSERT INTO #LogSpace_Temp EXEC('dbcc sqlperf(logspace)');
INSERT INTO Baselines.dbo.SQLskills_TrackLogSpace
(DatabaseName, LogSizeMB, LogSpaceUsed, LogStatus)
SELECT DatabaseName, LogSizeMB, LogSpaceUsed, LogStatus
FROM #LogSpace_Temp;
DROP TABLE #LogSpace_Temp; Използвам тази информация, за да определя кога регистрационният файл е започнал да нараства и започвам да преглеждам регистрационните файлове и историята на заданията, за да видя каква допълнителна информация мога да намеря. Разрастването на регистрационните файлове трябва да е статично – дневникът трябва да е с подходящ размер и да се управлява чрез архивиране (ако работи в ПЪЛНО възстановяване), а ако файлът трябва да е по-голям, трябва да разбера защо и да го преоразмеря съответно.
Ако се занимавате с този проблем и все още не сте проследявали проактивно събитията за растеж на файлове, все още може да успеете да разберете какво се е случило. Събитията за автоматично нарастване се улавят от SQL Server; Аарон Бертран от SQL Sentry публикува блог за това през 2007 г., където показва как да откриете кога са се случили тези събития (стига да са били достатъчно скорошни, за да съществуват в следата по подразбиране).
Размер и свободно място във файловете с данни
Вероятно вече сте чували, че вашите файлове с данни трябва да бъдат предварително оразмерени, за да не се налага да нарастват автоматично. Ако следвате това ръководство, вероятно не сте преживели събитието, при което файлът с данни нараства неочаквано. Но ако не управлявате файловете си с данни, тогава вероятно имате растеж, който се случва редовно – независимо дали го осъзнавате или не (особено с настройките за растеж по подразбиране от 10% и 1 MB).
Има трик за предварително оразмеряване на файлове с данни – не искате да оразмерявате база данни твърде голяма, защото не забравяйте, че ако възстановявате, да речем, среда за разработка или QA, файловете са с еднакъв размер, дори ако са не са пълни с данни. Но все пак искате да управлявате ръчно растежа. Намирам, че DBA имат най-трудно време с новите бази данни. Бизнес потребителите нямат представа за темповете на растеж и колко данни се добавят, а тази база данни е малко хлабав оръдие във вашата среда. Трябва да обърнете голямо внимание на тези файлове, докато не разберете размера и очаквания растеж. Използвам заявка, която дава информация за размера и свободното пространство:
SELECT
[file_id] AS [File ID],
[type] AS [File Type],
substring([physical_name],1,1) AS [Drive],
[name] AS [Logical Name],
[physical_name] AS [Physical Name],
CAST([size] as DECIMAL(38,0))/128. AS [File Size MB],
CAST(FILEPROPERTY([name],'SpaceUsed') AS DECIMAL(38,0))/128. AS [Space Used MB],
(CAST([size] AS DECIMAL(38,0))/128) - (CAST(FILEPROPERTY([name],'SpaceUsed') AS DECIMAL(38,0))/128.) AS [Free Space],
[max_size] AS [Max Size],
[is_percent_growth] AS [Percent Growth Enabled],
[growth] AS [Growth Rate],
SYSDATETIME() AS [Current Date]
FROM sys.database_files; Всеки месец проверявам размера на файловете с данни и използваното пространство, след което решавам дали размерът трябва да бъде увеличен. Също така наблюдавам проследяването по подразбиране за събития на растеж, тъй като това ми казва точно кога настъпва растеж. С изключение на новите бази данни, винаги мога да изпреварвам автоматичното нарастване на файловете и да го обработвам ръчно. Добре, почти винаги. Точно преди празниците миналата година бях уведомен от ИТ отдела на клиента за малко свободно място на устройството (задръжте тази мисъл за следващия раздел). Сега известието се основава на праг от по-малко от 20% безплатно. Това устройство беше над 1TB, така че имаше около 150GB свободни, когато проверих устройството. Все още не беше спешен случай, но трябваше да разбера къде е отишло мястото.
При проверка на файловете на базата данни за една база данни, можех да видя, че те са пълни – а предишния месец всеки файл имаше над 50 GB безплатни. След това се разрових в размерите на таблиците и открих, че в една таблица са добавени над 270 милиона реда през последните 16 дни – общо над 100 GB данни. Оказа се, че е имало модификация на кода и новият код записва повече информация от предвиденото. Бързо настроихме работа за прочистване на редовете и възстановяване на свободното място във файловете (и те поправиха кода). Въпреки това не можах да възстановя дисково пространство - трябваше да свия файловете, а това не беше опция. След това трябваше да определя колко място е останало на диска и да реша дали това е количество, което ми е удобно или не. Моето ниво на комфорт зависи от това колко данни се добавят на месец – типичният темп на растеж. И знам само колко данни се добавят, защото следя използването на файлове и мога да преценя колко място ще е необходимо за този месец, за тази година и за следващите две години.
Пространство за диск
Споменах по-рано, че имаме задачи за наблюдение на свободното място на диска. Това се основава на процент, а не на фиксирана сума. Моето общо правило е да изпращам известия, когато по-малко от 10% от диска е свободен, но за някои устройства може да се наложи да зададете това по-високо. Например, с 1 TB устройство, получавам известие, когато има по-малко от 100 GB свободни. С диск от 100 GB получавам известие, когато има по-малко от 10 GB свободни. С 20GB устройство... добре, виждате накъде отивам с това. Този праг трябва да ви предупреди, преди да има проблем. Ако имам само 10 GB свободно на устройство, което хоства лог файл, може да нямам достатъчно време да реагирам, преди да се появи като проблем за потребителите – в зависимост от това колко често проверявам свободното пространство за размер и какъв е проблемът е.
Много е лесно да използвате xp_fixeddrives за проверка на свободното пространство, но не бих препоръчал това, тъй като е недокументирано и използването на разширени съхранени процедури като цяло е отхвърлено. Той също така не отчита общия размер на всяко устройство и може да не отчита всички типове устройства, които може да използват вашите бази данни. Докато използвате SQL Server 2008R2 SP1 или по-нова версия, можете да използвате много по-удобния sys.dm_os_volume_stats, за да получите информацията, от която се нуждаете, поне за устройствата, където съществуват файлове с база данни:
SELECT DISTINCT vs.volume_mount_point AS [Drive], vs.logical_volume_name AS [Drive Name], vs.total_bytes/1024/1024 AS [Drive Size MB], vs.available_bytes/1024/1024 AS [Drive Free Space MB] FROM sys.master_files AS f CROSS APPLY sys.dm_os_volume_stats(f.database_id, f.file_id) AS vs ORDER BY vs.volume_mount_point;
Често виждам проблем с дисковото пространство на томове, които хостват tempdb. Изгубих броя на случаите, когато съм имал клиенти с необясним растеж на tempdb. Понякога това са само няколко GB; последно беше 200GB. Tempdb е сложен звяр – няма формула, която да следвате, когато го оразмерявате, и твърде често се поставя на устройство с малко свободно пространство, което не може да се справи с безумното събитие, причинено от начинаещия разработчик или DBA. Оразмеряването на файловете с данни tempdb изисква да изпълните работното си натоварване за „нормален“ бизнес цикъл, за да определите колко използва tempdb, и след това да го оразмерите съответно.
Наскоро чух предложение за начин да избегнете изчерпването на място на устройство:създайте база данни без данни и оразмерете файловете, така че да заемат колкото пространството искате да „оставите настрана“. След това, ако срещнете проблем, просто пуснете базата данни и виола, отново имате свободно място. Лично аз мисля, че това създава всякакви други проблеми и не бих го препоръчал. Но ако имате администратори за съхранение, които не обичат да виждат стотици неизползвани GB на устройство, това би бил един от начините да накарате устройството да „изглежда“ пълно. Това ми напомня нещо, което чух мой добър приятел да казва:„Ако не мога да работя с теб, ще работя около теб.“
Резервни копия
Една от основните задачи на DBA е да защитава данните. Архивите са един метод, използван за защитата му и като такива устройствата, които съхраняват тези архиви, са неразделна част от живота на DBA. Предполага се, че съхранявате едно или повече резервни копия онлайн, за да ги възстановите незабавно, ако е необходимо. Вашата книга за SLA и DR помага да диктува колко резервни копия съхранявате онлайн и трябва да сте сигурни, че разполагате с това пространство. Препоръчвам също така да не изтривате стари архиви, докато текущото архивиране не завърши успешно. Твърде лесно е да попаднете в капана на изтриване на стари архиви, след което стартиране на текущото архивиране. Но какво се случва, ако текущото архивиране не успее? И какво се случва, ако използвате компресия? Изчакайте малко... компресираните архиви са по-малки, нали? В крайна сметка са по-малки. Но знаете ли, че размерът на файла .bak обикновено започва по-голям от крайния размер? Можете да използвате флаг за проследяване 3042, за да промените това поведение, но трябва да мислите, че с архивиране се нуждаете от много място. Ако резервното ви копие е 100GB и поддържате онлайн стойност за 3 дни, имате нужда от 300GB за 3-те дни на архивиране и след това вероятно здравословно количество (2X текущия размер на базата данни) безплатно за следващото архивиране. Да, това означава, че във всеки един момент ще имате много повече от 100 GB свободни на това устройство. Това е добре. Това е по-добре, отколкото задачата за изтриване да бъде успешна и задачата за архивиране да се провали и три дни по-късно да разберете, че изобщо нямате резервни копия (това се случи на клиент на предишната ми работа).
Повечето бази данни просто стават все по-големи с течение на времето, което означава, че архивите също стават по-големи. Не забравяйте редовно да проверявате размера на архивните файлове и да заделяте допълнително пространство, ако е необходимо – да имате политика „200GB безплатно“ за база данни, която е нараснала до 350GB, няма да бъде много полезна. Ако изискванията за пространство се променят, не забравяйте да промените и всички свързани сигнали.
Използване на съветника за производителност
Има няколко заявки, включени в тази публикация, които можете да използвате за наблюдение на пространството, ако трябва да завъртите свой собствен процес. Но ако имате SQL Sentry Performance Advisor във вашата среда, това става много по-лесно с персонализирани условия. Има няколко условия за наличност, включени по подразбиране, но можете също да създадете свои собствени.
В клиента SQL Sentry отворете Навигатора, щракнете с десния бутон върху Споделени групи (глобални) и изберете Добавяне на персонализирано условие → SQL Sentry. Предоставете име и описание за условието, след което добавете числово сравнение и променете типа на Заявка за хранилище. Въведете заявката:
SELECT MIN(FreeSpace*100.0/Size) FROM SQLSentry.dbo.PerformanceAnalysisDeviceLogicalDisk;
Променете Равно на По-малко от и задайте изрична стойност от 10. Накрая променете честотата на оценка по подразбиране на нещо по-рядко от на всеки 10 секунди. Веднъж на ден или веднъж на всеки 12 часа вероятно е добра стойност – не трябва да проверявате свободното пространство по-често от веднъж на ден, но можете да го проверявате толкова често, колкото искате. Екранната снимка по-долу показва окончателната конфигурация:
След като щракнете върху запазване за условието, ще бъдете попитани дали искате да зададете действия за персонализираното условие. Опцията за изпращане до канали за предупреждение е избрана по подразбиране, но може да искате да изпълнявате други задачи, като например Изпълнение на задание – да речем, да копирате стари архиви на друго място (ако това е устройството с малко място).
Както споменах по-рано, 10% свободно пространство по подразбиране за всички дискове вероятно не е подходящо за всяко устройство във вашата среда. Можете да персонализирате заявката за различни екземпляри и устройства, например:
SELECT Alert = MAX(CASE WHEN Name = N'C:' AND [FreeSpace%] < 10 THEN 1 WHEN Name = N'S:' AND [FreeSpace%] < 25 THEN 1 WHEN Name = N'T:' AND [FreeSpace%] < 20 THEN 1 ELSE 0 END) FROM ( SELECT d.Name, d.FreeSpace * 100.0/d.Size AS [FreeSpace%] FROM SQLSentry.dbo.PerformanceAnalysisDeviceLogicalDisk AS d INNER JOIN SQLSentry.dbo.EventSourceConnection AS c ON d.DeviceID = c.DeviceID WHERE c.ObjectName = N'HANK\SQL2012' -- replace with your server/instance ) AS s;
Можете да промените и разширите тази заявка, както е необходимо за вашата среда, и след това да промените съответно сравнението в условието (основно оценявайки на вярно, ако резултатът някога е 1):
Ако искате да видите Performance Advisor в действие, не се колебайте да изтеглите пробна версия.
Имайте предвид, че и за двете от тези условия ще бъдете предупредени само веднъж, дори ако няколко устройства паднат под прага ви. В сложни среди може да искате да се наклоните към по-голям брой по-специфични условия, за да осигурите по-гъвкаво и персонализирано предупреждение, вместо по-малко „обхватни“ условия.
Резюме
Има много критични компоненти в среда на SQL Server и дисковото пространство е това, което трябва да бъде проактивно наблюдавано и поддържано. Само с малко планиране това е лесно за изпълнение и облекчава много неизвестни и реактивно решаване на проблеми. Независимо дали използвате свои собствени скриптове или инструмент на трета страна, осигуряването на достатъчно свободно място за файлове на база данни и архивни копия е проблем, който е лесно разрешим и си струва усилията.
