Как сокращение файла журнала SQL Server влияет на производительность?

У меня есть база данных SQL Server 2008, у которой есть файл данных размером около 2 ГБ, но размер файла журнала превышает 8 ГБ. С базами данных до 2008 года я мог использовать «Журнал резервного копирования» и TRUNCATE_ONLYопцию, но это больше не доступно для баз данных 2008 года и более поздних.

У меня есть скрипт, который усекает файл журнала:

USE [MyDatabase]
GO
ALTER DATABASE [MyDatabase] SET RECOVERY SIMPLE WITH NO_WAIT
DBCC shrinkfile('MyDatabase_log', 1)
ALTER DATABASE [MyDatabase] SET RECOVERY FULL WITH NO_WAIT
GO

Это усекает файл журнала полностью, но мой вопрос: это влияет на производительность?

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

Я действительно рекомендую прочитать « Важность правильного управления размером журнала транзакций » Пола С. Рэндала.

Квинтэссенция состоит в том, что есть только два действительно хороших способа сделать обработку журнала транзакций :

1. Либо используйте обычные резервные копии файлов LOG, и файл LOG будет повторно использовать свое пространство после каждой резервной копии LOG и не будет расти бесконечно, либо

2. Используйте модель восстановления SIMPLE, и вам не нужно заботиться о размере вашего LOG-файла, так как вы делаете регулярные полные резервные копии.

Что касается усечения и производительности LOG-файла, так это то, что при увеличении LOG-файла вы всегда получите снижение производительности (цитата из вышеупомянутого поста в блоге):

Если вы сократите журнал, он снова будет расти - возможно, это приведет к фрагментации VLF и определенно приведет к приостановке рабочей нагрузки по мере роста журнала, поскольку журнал не может использовать мгновенную инициализацию [...]

Обновление: не путайте усечение файла LOG с уменьшением размера файла DATA. Сжатие файла данных действительно плохо. См. Почему вы не должны сжимать ваши файлы данных для деталей.

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

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

Что касается влияния на производительность, ну, не зная деталей аппаратного обеспечения и использования вашей системы, было бы сложно сказать.

Насколько быстро растет журнал транзакций? Если он достаточно быстрый, вы будете влиять на производительность, уменьшая его практически до нуля, так как он должен тратить время на его восстановление. Это не означает, что вы не должны время от времени сокращать его, но вы должны думать о размере, а не просто уменьшать его до минимума. Удар огромен? Вероятно, нет, но это зависит от нагрузки на сервер (количество транзакций и т. Д.).

Одна вещь, которую я нахожу проблематичной, - «я выполняю 2 полных резервных копии в день, поэтому в действительности нет необходимости в журнале, если речь идет о возврате данных». Журнал чрезвычайно важен для точек между вашими полными резервными копиями. Даже два раза в день не устраняется необходимость в файле журнала для аварийного восстановления, если только это не база данных, доступная только для чтения (если бы она не была, вы бы не увидели огромного увеличения файла журнала).