DBCC SHRINKDATABASE
так, решил эту фигню записать, а то приходится это делать крайне редко и каждый раз роешься в хелпе до посинения, ибо забыл всё нафиг.
Итак, база данных или её лог выросли сверх всякой меры. Например, база обычно только на чтение, но таблицы скажем раз в полгода обновляются путём импорта немаленьких объемов данных. И вот БД плюс лог вместо 150 мегов занимают 2.5 гига.
Первый шаг - DBCC SHRINKDATABASE (Имя_базы_данных , 10). 10 - процент св. места, который может остаться после выбрасывания всего лишнего.
Второй шаг - если предыдущий не помог.
DBCC SQLPERF(LOGSPACE) - покажет статистику по всем базам, особенно интересны колонки [Log Size(MB)] и [Log Space Used (%)]. Находим наш гигантский лог, и видим, что все 100% используются. Значит нужно выкидывать старые протоколы.
Полезное -
SELECT FILE_IDEX((SELECT name FROM sys.database_files
WHERE type = 1))AS 'File ID' - можно получить ID лог-файла. Может понадобиться, если приходится пользоваться DBCC SHRINKFILE и есть сложности получить имя лог-файла.
Следующий шаг - SELECT * FROM sys.databases,
ищем в строке с нашей БД колонку log_reuse_wait_desc, там скорее всего стоит что угодно только не NOTHING, например LOG_BACKUP или ACTIVE_TRANSACTION. На самом деле неважно, что именно, важно, что вот оно то и блокирует DBCC SHRINKDATABASE.
Если нас не интересует реальный бэкап лога (а зачем он мне, если я знаю, что он такой большой из-за прошедшего импорта, а импорт был успешен), то выполняем
BACKUP LOG Имя_базы_данных WITH TRUNCATE_ONLY
Теперь можно повторить DBCC SQLPERF(LOGSPACE), чтобы убедиться, что не более чем какой-то минимальный процент лог-файла действительно занят. И если это так - повторяем DBCC SHRINKDATABASE (Имя_базы_данных , 10)