#sql-server
Вопрос:
Я использовал следующий запрос для просмотра файла журнала базы данных.
declare @templTable as table
( DatabaseName nvarchar(50),
LogSizeMB nvarchar(50),
LogSpaceUsedPersent nvarchar(50),
Statusee bit
)
INSERT INTO @templTable
EXEC('DBCC SQLPERF(LOGSPACE)')
SELECT * FROM @templTable ORDER BY convert(float , LogSizeMB) desc
DatabaseName LogSizeMB LogSpaceUsedPersent
===============================================
MainDB 6579.93 65.8095
Я также использовал следующий код для просмотра объема пространства, используемого основным файлом базы данных.
with CteDbSizes
as
(
select database_id, type, size * 8.0 / 1024 size , f.physical_name
from sys.master_files f
)
select
dbFileSizes.[name] AS DatabaseName,
(select sum(size) from CteDbSizes where type = 1 and CteDbSizes.database_id = dbFileSizes.database_id) LogFileSizeMB,
(select sum(size) from CteDbSizes where type = 0 and CteDbSizes.database_id = dbFileSizes.database_id) DataFileSizeMB
--, (select physical_name from CteDbSizes where type = 0 and CteDbSizes.database_id = dbFileSizes.database_id) as PathPfFile
from sys.databases dbFileSizes ORDER BY DataFileSizeMB DESC
DatabaseName LogFileSizeMB DataFileSizeMB
===============================================
MainDB 6579.937500 7668.250000
Но что бы я ни делал, объем пространства журнала базы данных составляет не менее 6 ГБ. Как вы думаете, есть ли причина, по которой журнал базы данных не менялся более месяца? Есть ли решение уменьшить эту сумму или нет? Я также использовал различные методы и запросы, чтобы уменьшить размер файла журнала. Я получил хорошие ответы по другим базам данных. Например, folow:
use [master];
GO
USE [master]
GO
ALTER DATABASE [MainDB] SET RECOVERY SIMPLE WITH NO_WAIT
GO
USE [MainDB]
GO
DBCC SHRINKDATABASE(N'MainDB')
GO
DBCC SHRINKFILE (N'MainDB_log' , EMPTYFILE)
GO
ALTER DATABASE [MainDB] SET RECOVERY FULL WITH NO_WAIT
GO
Но в этой конкретной базе данных объем журнала базы данных по-прежнему составляет не менее 6 ГБ. Пожалуйста, помогите. Спасибо.
Комментарии:
1. Какую именно версию и выпуск SQL Server вы используете?
2.
.ldf
Файл состоит из фрагментов, называемых «страницами», и при сжатии файла освобождается только неиспользуемое пространство, расположенное после последней выделенной страницы. Если у вас есть.ldf
файл с 1 использованной страницей в самом конце (со смещением 6 ГБ в файле), то сжатие файла ничего не даст. Сначала вам нужно реорганизовать страницы, затем будет работать сокращение. (Я согласен, что SQL Server должен сделать это более очевидным, и это такжеDBCC SHRINKFILE
должно привести к реорганизации страниц, но это не так, ну и ладно)3. Кроме того, почему вы сокращаете свои файлы? Вы уверены, что вам действительно это нужно? Вы читали эту статью? brentozar.com/archive/2009/08/…
4. Возможно, размер по умолчанию в настройках был установлен на 6 ГБ?
5. Это говорит о том, что у вас все еще есть
632776
используемые страницы — они, вероятно, еще не могут быть перемещены. Кроме того, вы выполнили полное резервное копирование своей базы данных? При выполнении правильного резервного копирования журнал транзакций очищается (обратите внимание, что не все типы резервных копий очищают журнал транзакций).
Ответ №1:
Как я сообщил в главном посте, через некоторое время размер журнала файлов нашей базы данных достиг примерно 25 гигабайт, и мы больше не могли даже сжимать файлы базы данных. После некоторых поисков я пришел к выводу, что мне следует создать резервную копию файла журнала, а затем сжать файл журнала. Для этой цели я определил задание, которое подготавливает файл из резервной копии журнала почти каждые 30 минут, и размер этих файлов обычно не превышает 150 МБ. Затем, после каждой резервной копии файла журнала, я один раз запускаю команду сжатия журнала. С помощью этого метода размер файла журнала значительно уменьшается, и теперь у нас есть около 500 МБ файла журнала. Конечно, из-за большого количества транзакций в базе данных указанное задание всегда должно быть активным. Если задание неактивно, я снова увеличу объем журнала.