SqlBak добавил функцию контроля за сервером

Такие вещи, как проверка состояния сервера (health check) и резервное копирование данных напрямую не влияют на эффективность бизнес-процессов. И, в принципе, так оно и есть пока “петух не клюнет”. А когда “клюнет”, то кажется, что эти задачи и являются самыми важными, ведь если “упал” сервер или вы потеряли все данные, то ни о каких бизнес-процессах речь уже не идет.

Сервис SqlBak.com призван освободить голову администраторов баз данных, приняв на себя заботу о таких “второстепенных” задачах. Вот поэтому, в дополнение к резервному копированию здесь появилась возможность автоматического контроля за состоянием сервера (SQL Server Automatic Health Check).

В этой статье мы рассмотрим основные аспекты этого сервиса и покажем как они могут быть полезны при администрировании баз данных.

Контроль свободного места на диске

Вы когда-нибудь оказывались в ситуации, когда на вашем сервере закончилось свободное место на диске? Очень неприятная ситуация, надо сказать. Система тормозит, сыпятся ошибки, а некоторые программы вообще не запускаются.

Это может случиться из-за разрастания логов, неудаленных временных файлов, неудачном копировании большого количества информации и т.п. Но самое главное — такую ситуацию легко отследить и предупредить.

Для этого в разделе Health Check вам нужно указать нижнюю границу свободного места на диске (в процентах) и сервис автоматически уведомит вас, когда свободного места останется меньше этого уровня:

sqlbak health check

При этом, самое приятное то, что интерфейс SqlBak.com позволяет тут же определить что именно занимает так много места посредством указания размеров папок на сервере:

sqlbak disk check

Кроме этого, как видно из скриншота, также сохраняется история использования диска, что может помочь выявить тенденции и аномалии, предотвратив последующие сбои.

Контроль баз данных

Другим разделом SQL Server Automatic Health Check является отслеживание некоторых характеристик баз данных на каждом из подключенных серверов:

sqlbak database check

Здесь мы видим суммарные показатели по всем базам данных на сервере, информацию о каждой базе в отдельности, а также историю изменения размера каждой базы данных за последние 30 дней.
Давайте рассмотрим некоторые важные показатели в этом списке.

Размер журнала транзакций (Trx Log Size)

В журнале транзакций фиксируются все изменения данных, произведенные в каждой из транзакций. Он является важной составляющей базы данных и он может помочь вернуть базу данных в согласованное состояние в случае ошибки.

Однако, в некоторых случаях, журнал транзакций может быстро расти и его необходимо регулярно усекать, чтобы избежать его переполнения. При этом, по ряду причин его усечение может быть отложено, и поэтому очень важно следить за размером журнала.

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

Помимо разрастания количества записей, файл журнала транзакции может просто содержать значительное неиспользованное пространство. В этом случае его можно освободить, уменьшив размер файла. Это называется сжатием файла журнала и может быть выполнено следующей командой (обычно выполняется после операции усечения):

DBCC SHRINKFILE (MyDB_Log, 1);

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

Неиспользованное пространство (Unused Size)

В результате операций удаления в файлах базы данных может образоваться много неиспользованного пространства. Это значит, что база данных на диске будет занимать гораздо больше места, чем содержащиеся в ней данные. В этом случае нужно провести сжатие базы данных:

DBCC SHRINKDATABASE (MyDB, 10);

Первый параметр — имя базы данных, второй — количество свободного пространства выделяемого этой базе данных в процентном выражении.

Фрагментация индекса (Index Fragmentation)

Операции операций вставки, обновления или удаления могут привести к тому, что данные в индексе окажутся разбросанными по базе данных (фрагментированными). Кроме этого, фрагментация может появиться когда в индексах содержатся страницы, для которых логический порядок, основанный на значении ключа, не совпадает с физическим порядком в файле данных.

Значительно фрагментированные индексы могут серьезно снижать производительность запросов и, как следствие, привести к медленной работа приложения в целом. В этом случае нужно произвести перестроение индексов.

Это осуществляется с помощью команды ALTER INDEX. Например, перестроение всех индексов в таблице MyDB.MyTable можно произвести с помощью команды:

ALTER INDEX ALL ON MyDB.MyTable
REBUILD WITH (FILLFACTOR = 80, SORT_IN_TEMPDB = ON,
STATISTICS_NORECOMPUTE = ON);

Уведомление о превышении лимита размера базы данных

Подобно уведомлению о нехватке свободного места, SqlBak.com также может уведомлять вас о том, что размер базы данных превысил определенный лимит. Это особенно полезно если вы используете SQL Server Express Edition, который не позволяет работать с базами данных размером более 10 Гб.
Но даже если у вас полноценная версия SQL Server, то в некоторых проектах очень полезно контролировать рост базы данных. Особенно если он происходит из-за непомерно увеличивающегося лога транзакций, о чем мы говорили выше.

Заключение

Если вы используете SqlBak.com для резервного копирования своих баз данных, то вы несомненно получите уведомление о проблемах с резервными копиями или о том, что ваш сервер перестал работать. Но т.к. профилактика лучше лечения, то мы настоятельно рекомендуем также включить у себя опцию SQL Server Automatic Health Check дабы быть уведомленным заранее если что-то пойдет не так.