Произошла ошибка во время обработки журнала данных для базы данных

SQL Server 2012 Enterprise SQL Server 2008 R2 Enterprise SQL Server 2012 Developer SQL Server 2012 Standard SQL Server 2014 Developer SQL Server 2014 Enterprise SQL Server 2014 Standard Еще…Меньше

Если восстановление журнала с CONTINUE_AFTER_ERROR (либо со STOP_ON_ERROR)

RESTORE LOG [ka]
    FROM DISK = N'D:Tail.bak'
    WITH FILE = 1, CONTINUE_AFTER_ERROR, NORECOVERY
GO

завершается с ошибкой, после которой невозможно выполнить

RESTORE DATABASE [ka]
    WITH RECOVERY
GO

то можно попытаться восстановиться до какого-то LSN в журнале (максимально возможного), при котором RESTORE LOG ещё не вызывает ошибок.

Для этого читаем заголовки бэкапов БД и журнала

RESTORE HEADERONLY FROM DISK = N'C:2016.Bak'
RESTORE HEADERONLY FROM DISK = N'D:Tail.bak'

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

Допустим, получили:

C:2016.Bak
FirstLSN          LastLSN          
----------------- -----------------
64000000005600195 64000000017600001

D:Tail.bak
FirstLSN          LastLSN          
----------------- -----------------
64000000005600195 66000000025600001

сравниваем LSN: 64000000005600195 <= 64000000017600001 < 66000000025600001 — OK.

Значение LastLSN из заголовка БД (равное 64000000017600001) переводим из десятичного представления в двоичное (см. здесь, функция fn_convertnumericlsntobinary), получаем 00000040:000000B0:0001.

Теперь с помощью sys.fn_dump_dblog читаем последовательность LSN из дампа лога (можно отфильтровать только операции завершения транзакций Operation = 'LOP_COMMIT_XACT'):

select [Current LSN]
from sys.fn_dump_dblog(
    NULL, NULL, N'DISK', 1, N'D:Tail.bak',
    default, default, default, default, default, default, default,
    default, default, default, default, default, default, default,
    default, default, default, default, default, default, default,
    default, default, default, default, default, default, default,
    default, default, default, default, default, default, default,
    default, default, default, default, default, default, default,
    default, default, default, default, default, default, default,
    default, default, default, default, default, default, default,
    default, default, default, default, default, default, default)
where Operation = 'LOP_COMMIT_XACT';

Допустим, получили, следующий список:

Current LSN
-----------------------
00000040:000000a0:0002
00000040:000000b8:0001   <-- сначала восстанавливаем журнал к этой отметке
00000040:000000c8:000b   <-- потом к этой
00000040:000000d0:000a   <-- ...
00000040:000000d8:000a   <-- ...
00000040:000000e0:000a   <-- ...
00000040:000000e8:000a   <-- ...
00000040:000000f0:000b   <-- ...
00000040:000000f8:0010   <-- ...
00000040:000000f8:0021   <-- и т.д, пока не встретим ошибку
00000040:000000f8:0027   <-- ERROR
00000040:00000110:0017
00000040:00000130:001b
00000040:00000130:001d
00000040:00000140:000a

Заново инициализируем восстановление:

RESTORE DATABASE [ka]
    FROM DISK = N'D:2016.bak'
    WITH NORECOVERY, REPLACE
GO

Теперь берём из списка первое значение LSN, которое следует позднее, чем LastLSN в бэкапе БД (позднее чем 00000040:000000B0:0001) и делаем RESTORE LOG к этой отметке:

RESTORE LOG [ka]
    FROM DISK = N'D:Tail.bak'
    WITH FILE = 1, STOPATMARK = 'lsn:0x00000040:000000b8:0001', NORECOVERY
GO

Если операция прошла без ошибок, повторяем то же самое для следующей отметки, и т.д., пока не дойдём до отметки, восстановление к которой будет вызывать ошибку.

Если отметок много, то можно применить дихотомический поиск, учитывая, однако, что при движении вперёд достаточно выполнять лишь RESTORE LOG к новой отметке, но если необходимо вернуться назад, то цепочку восстановления нужно выполнять заново (RESTORE DATABASE ... WITH REPLACE ..., затем RESTORE LOG ... к нужной отметке).

После того как последняя не вызвавшая ошибку отметка определена, заново восстановим БД и журнал до этой отметки:

RESTORE DATABASE [ka]
    FROM DISK = N'D:2016.bak'
    WITH NORECOVERY, REPLACE
GO
RESTORE LOG [ka]
    FROM DISK = N'D:Tail.bak'
    WITH STOPATMARK = 'lsn:0x00000040:000000f8:0021', NORECOVERY
GO

После чего завершаем восстановление:

RESTORE DATABASE [ka]
    WITH RECOVERY
GO

Если восстановление журнала с CONTINUE_AFTER_ERROR (либо со STOP_ON_ERROR)

RESTORE LOG [ka]
    FROM DISK = N'D:Tail.bak'
    WITH FILE = 1, CONTINUE_AFTER_ERROR, NORECOVERY
GO

завершается с ошибкой, после которой невозможно выполнить

RESTORE DATABASE [ka]
    WITH RECOVERY
GO

то можно попытаться восстановиться до какого-то LSN в журнале (максимально возможного), при котором RESTORE LOG ещё не вызывает ошибок.

Для этого читаем заголовки бэкапов БД и журнала

RESTORE HEADERONLY FROM DISK = N'C:2016.Bak'
RESTORE HEADERONLY FROM DISK = N'D:Tail.bak'

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

Допустим, получили:

C:2016.Bak
FirstLSN          LastLSN          
----------------- -----------------
64000000005600195 64000000017600001

D:Tail.bak
FirstLSN          LastLSN          
----------------- -----------------
64000000005600195 66000000025600001

сравниваем LSN: 64000000005600195 <= 64000000017600001 < 66000000025600001 — OK.

Значение LastLSN из заголовка БД (равное 64000000017600001) переводим из десятичного представления в двоичное (см. здесь, функция fn_convertnumericlsntobinary), получаем 00000040:000000B0:0001.

Теперь с помощью sys.fn_dump_dblog читаем последовательность LSN из дампа лога (можно отфильтровать только операции завершения транзакций Operation = 'LOP_COMMIT_XACT'):

select [Current LSN]
from sys.fn_dump_dblog(
    NULL, NULL, N'DISK', 1, N'D:Tail.bak',
    default, default, default, default, default, default, default,
    default, default, default, default, default, default, default,
    default, default, default, default, default, default, default,
    default, default, default, default, default, default, default,
    default, default, default, default, default, default, default,
    default, default, default, default, default, default, default,
    default, default, default, default, default, default, default,
    default, default, default, default, default, default, default,
    default, default, default, default, default, default, default)
where Operation = 'LOP_COMMIT_XACT';

Допустим, получили, следующий список:

Current LSN
-----------------------
00000040:000000a0:0002
00000040:000000b8:0001   <-- сначала восстанавливаем журнал к этой отметке
00000040:000000c8:000b   <-- потом к этой
00000040:000000d0:000a   <-- ...
00000040:000000d8:000a   <-- ...
00000040:000000e0:000a   <-- ...
00000040:000000e8:000a   <-- ...
00000040:000000f0:000b   <-- ...
00000040:000000f8:0010   <-- ...
00000040:000000f8:0021   <-- и т.д, пока не встретим ошибку
00000040:000000f8:0027   <-- ERROR
00000040:00000110:0017
00000040:00000130:001b
00000040:00000130:001d
00000040:00000140:000a

Заново инициализируем восстановление:

RESTORE DATABASE [ka]
    FROM DISK = N'D:2016.bak'
    WITH NORECOVERY, REPLACE
GO

Теперь берём из списка первое значение LSN, которое следует позднее, чем LastLSN в бэкапе БД (позднее чем 00000040:000000B0:0001) и делаем RESTORE LOG к этой отметке:

RESTORE LOG [ka]
    FROM DISK = N'D:Tail.bak'
    WITH FILE = 1, STOPATMARK = 'lsn:0x00000040:000000b8:0001', NORECOVERY
GO

Если операция прошла без ошибок, повторяем то же самое для следующей отметки, и т.д., пока не дойдём до отметки, восстановление к которой будет вызывать ошибку.

Если отметок много, то можно применить дихотомический поиск, учитывая, однако, что при движении вперёд достаточно выполнять лишь RESTORE LOG к новой отметке, но если необходимо вернуться назад, то цепочку восстановления нужно выполнять заново (RESTORE DATABASE ... WITH REPLACE ..., затем RESTORE LOG ... к нужной отметке).

После того как последняя не вызвавшая ошибку отметка определена, заново восстановим БД и журнал до этой отметки:

RESTORE DATABASE [ka]
    FROM DISK = N'D:2016.bak'
    WITH NORECOVERY, REPLACE
GO
RESTORE LOG [ka]
    FROM DISK = N'D:Tail.bak'
    WITH STOPATMARK = 'lsn:0x00000040:000000f8:0021', NORECOVERY
GO

После чего завершаем восстановление:

RESTORE DATABASE [ka]
    WITH RECOVERY
GO

BlackMak

06.07.10 — 12:50

BlackMak

1 — 06.07.10 — 13:02

ап

leshikkam

2 — 06.07.10 — 13:05

Umka2008

3 — 06.07.10 — 13:07

Восстанавливаться из резервной копии очень не хочется — теряем день. Это почему?
Загружал 23 гб — минут 15

Любитель XML

4 — 06.07.10 — 13:09

(3) данные за день потеряны будут.

Любитель XML

5 — 06.07.10 — 13:09

+(4) архив то вчерашний

Lionee

6 — 06.07.10 — 13:12

или есть что то , или ваще нет , нечего страшного бухам делать нечегозанового набьют докию(5)

Это_mike

7 — 06.07.10 — 13:13

ПОхоже, гикнулся только ldf. присоединюсь к (2)

BlackMak

8 — 06.07.10 — 13:13

Любитель XML

9 — 06.07.10 — 13:14

(8) отпишись о результатах

Это_mike

10 — 06.07.10 — 13:14

(6) хм. есть разные предприятия. На некоторых и тысячи документов в день бывают…

vde69

11 — 06.07.10 — 13:14

(0) есть спецы по востановление, если нужно напиши письмо вечером скину контакты.

BlackMak

12 — 06.07.10 — 13:19

Злой Бобр

13 — 06.07.10 — 13:22

BlackMak

14 — 06.07.10 — 13:22

(13) — неверно телепатируете — массив был на 4-х дисках.

Ёпрст

15 — 06.07.10 — 13:25

(14) жесть.. и кто вам советовал 5 рейд на 4 дисках ?

BlackMak

16 — 06.07.10 — 13:26

(15) — дела давно минувших дней. Все руки не доходят в RAID10 его превратить.

Это_mike

17 — 06.07.10 — 13:31

А в момент падения что с базой творилось?

BlackMak

18 — 06.07.10 — 13:32

(17) — точно не скажу, но думаю, что к ней был подключен 1 пользователь из 1С:Предприятия. Работы не велись (скорее всего).

МихаилМ

19 — 06.07.10 — 14:22

если делали архив раз в сутки  — значит готовы пожертвовать сутками.

BlackMak

20 — 06.07.10 — 18:23

leshikkam

21 — 06.07.10 — 18:31

(20) Рад что смог помочь. Буду в ваших краях обязательно воспользуюсь предложением

Любитель XML

22 — 06.07.10 — 18:38

(20) рад что получилось. А вот ссылочку пожалуй сохраню ))

BlackMak

23 — 06.07.10 — 18:45

(22) — да, ссылочка неплоха. Судя по комментариям, она уже у многих вызвала слезы счастья.

Мы используем доставку журналов и RESTORE WITH STANDBYна SQL Server 2012, чтобы восстановить базу данных в режиме только для чтения для целей отчетности. Однако настройка доставки журналов не работает после восстановления одной или двух резервных копий журналов. Доставка журналов прерывается только тогда, когда она работает как RESTORE WITH STANDBY; RESTORE WITH NORECOVERYне вызывает никаких проблем.

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

Есть идеи, известные исправления?

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

Спасибо за все ваши ответы.

PS: выдержка из нашего журнала

25.02.2013 13: 00: 00, LSRestore_DBDB01-A_BulldogDB, Выполняется, 1, DBREPORTS, LSRestore_DBDB01-A_BulldogDB, шаг задания журнала восстановления доставки журналов. ,, 2013-02-25 13: 00: 12.31 *** Ошибка: Не удалось применить файл резервной копии журнала ' dbsan01  DBBackups  LSBackup_BulldogDB  BulldogDB_20130225180000.trn' к вторичной базе данных "BulldogDB". (Microsoft.SqlServer.Management.LogShipping) ***
2013-02-25 13: 00: 12.31 *** Ошибка: произошла ошибка при обработке журнала для базы данных «BulldogDB». Если возможно восстановить из резервной копии. Если резервная копия недоступна, может потребоваться перестроить журнал.
Во время восстановления произошла ошибка, препятствующая перезапуску базы данных BulldogDB (8: 0). Диагностируйте ошибки восстановления и исправляйте их или восстанавливайте из заведомо исправной резервной копии. Если ошибки не исправлены или ожидаются, обратитесь в службу технической поддержки.
RESTORE LOG завершается ненормально.
Обработано 0 страниц для базы данных «BulldogDB», файла «BulldogDB» для файла 1.
Обработано 1 страниц для базы данных «BulldogDB», файла «BulldogDB_log» в файле 1. (. Net SqlClient Data Provider) ***
2013-02-25 13: 00: 12.32 *** Ошибка: не удалось записать историю / сообщение об ошибке. (Microsoft.SqlServer.Management.LogShipping) ***
2013-02-25 13: 00: 12.32 *** Ошибка: ExecuteNonQuery требует открытого и доступного соединения. Текущее состояние соединения закрыто. (System.Data) ***
2013-02-25 13: 00: 12.32 Пропуск файла резервной копии журнала ' dbsan01  DBBackups  LSBackup_BulldogDB  BulldogDB_20130225180000.trn' для вторичной базы данных BulldogDB, так как файл не может быть проверен.
2013-02-25 13: 00: 12.32 *** Ошибка: не удалось записать историю / сообщение об ошибке. (Microsoft.SqlServer.Management.LogShipping) ***
2013-02-25 13: 00: 12.32 *** Ошибка: ExecuteNonQuery требует открытого и доступного соединения. Текущее состояние соединения закрыто. (System.Data) ***
2013-02-25 13: 00: 12.33 *** Ошибка: при восстановлении режима доступа к базе данных произошла ошибка (Microsoft.SqlServer.Management.LogShipping) ***
2013-02-25 13: 00: 12.33 *** Ошибка: ExecuteScalar требует открытого и доступного соединения. Текущее состояние соединения закрыто. (System.Data) ***
2013-02-25 13: 00: 12.33 *** Ошибка: не удалось записать историю / сообщение об ошибке (Microsoft.SqlServer.Management.LogShipping) ***
2013-02-25 13: 00: 12.33 *** Ошибка: ExecuteNonQuery требует открытого и доступного соединения. Текущее состояние соединения закрыто. (System.Data) ***
2013-02-25 13: 00: 12.33 *** Ошибка: при восстановлении режима доступа к базе данных произошла ошибка (Microsoft.SqlServer.Management.LogShipping) ***
2013-02-25 13: 00: 12.33 *** Ошибка: ExecuteScalar требует открытого и доступного соединения. Текущее состояние соединения закрыто. (System.Data) ***
2013-02-25 13: 00: 12.33 *** Ошибка: не удалось записать историю / сообщение об ошибке (Microsoft.SqlServer.Management.LogShipping) ***
2013-02-25 13: 00: 12.33 *** Ошибка: ExecuteNonQuery требует открытого и доступного соединения. Текущее состояние соединения закрыто. (System.Data) ***
2013-02-25 13: 00: 12.33 Удаление старых файлов резервных копий журнала. Основная база данных: 'BulldogDB'
2013-02-25 13: 00: 12.33 *** Ошибка: не удалось записать историю / сообщение об ошибке (Microsoft.SqlServer.Management.LogShipping) ***
2013-02-25 13: 00: 12.33 *** Ошибка: ExecuteNonQuery требует открытого и доступного соединения. Текущее состояние соединения закрыто. (System.Data) ***, 00: 00: 12,0,0 ,,,, 0

Содержание:

1.       Журнал транзакций в 1С

2.       Ошибка Журнал транзакций переполнен  

1.    Журнал транзакций в 1С

В данной статье будет описана возможная ошибка в системе 1С, а именно – в СУБД, которая связана с переполнением журнала транзакций в 1С. Далее будут приведены возможные методы устранения данной неполадки, среди которых уменьшение журнала транзакций для базы данных.

Сначала следует выяснить, что такое журнал транзакций в 1С. Журнал транзакций является одной из основных составляющих в базе данных. При помощи журнала транзакций для базы данных создаётся резервная копия, которая в случае сбоя системы вернёт базу в нужное состояние, которое изначально было согласовано.

При помощи журнала транзакций можно выполнить такие действия:

1.     Восстановление транзакций;

2.     Восстановление транзакций, которые не были окончены;

3.     Поддерживать повторения транзакций;

4.     Производить восстановление базы данных, из-за системного сбоя.  

2.    Ошибка Журнал транзакций переполнен

В СУБД 1С может появляться ошибка, которая содержит следующий текст: «Журнал транзакций для базы данных «zup» заполнен». Также, в тексте ошибки может приводиться столбец и таблица, к которым следует обратиться.

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

Рассмотрим два возможных способа для устранения ошибки «Журнал транзакций для базы данных переполнен»:

·        В первом способе будем следовать такому алгоритму:

1.     Проверить наличие и величину свободного места на дисках, в случае, когда места нет – соответственно, нет места и для записи лога;

2.     Если место есть, то ошибка «Журнал транзакций для базы переполнен» является ошибкой MicrosoftSQLServer, то есть – лог с транзакциями был полностью заполнен, но не очищен. Это можно исправить при помощи очистки, которая является стандартной, но эта опция не всегда может помочь устранить неполадку. В случае, если она не сработала – стоит использовать следующий код SQLServer:

код SQLServer

В данном коде: 20 – это величина лога в Мб, а «myDataBase» — название нужной базы с данными.

·        Следующий способ – это сразу приступить к уменьшению размера журнала с транзакциями.

Так как с журналом транзакций в SQLServer часто проводится много довольно весомых манипуляций, которые связаны с модификацией данных в СУБД, то такие действия приводят к увеличению размеров файловых данных внутри журнала с транзакциями. В данном случае очень важно вовремя удалять не нужные записи из журнала транзакций SQL, в связи с созданием более актуальных. Если не проводить удаления вовремя, то прошлые файлы в журнале транзакций начинают заполнять всё место на диске и далее станет невозможно работать с СУБД.

Так что, в своём роде, данный способ – это предотвращение ошибки «Журнал транзакций переполнен» в 1С.

В таком случае, удаляем те записи, которые больше не нужны, при помощи команды «BACKUPLOG», следующий шаг – это сделать меньше файл из журнала транзакций MSSQL– при помощи команды «DBCCSHRINKFILE». Таким образом, нужный нам код, для предотвращения ошибки, будет выглядеть таким образом:

Предотвращение ошибки Журнал транзакций переполнен

В данной статье были приведены общие данные о том, что такое журнал транзакций, а также проведена диагностика ошибки «Журнал транзакций переполнен» в 1С. Далее было описано, как устранить данную ошибку и дан способ для предотвращения данной неполадки.

Специалист компании «Кодерлайн»

Айдар Фархутдинов

Описание ошибки

Описание ошибки: журнал транзакций базы данных заполнен. Чтобы выяснить, почему пространство в журнале нельзя использовать повторно, см. Столбец log_reuse_wait_desc в sys.databases.

Причина ошибки

Введение в журналы транзакций

Официальная документация имеет следующие инструкции:

Особенности журнала транзакций ядра СУБД SQL Server:
Журнал транзакций реализован в виде отдельного файла или группы файлов в базе данных. Кэш журналов управляется отдельно от буферного кэша страниц данных, поэтому простой, быстрый и мощный код может быть сгенерирован в ядре базы данных SQL Server. Для получения дополнительной информации см. Физическая архитектура журнала транзакций.
Формат записей журнала и страниц не обязательно должен соответствовать формату страницы данных.
Журнал транзакций может быть реализован в нескольких файлах. Эти файлы могут быть определены для автоматического расширения путем установки значения FILEGROWTH журнала. Это уменьшает вероятность нехватки места в журнале транзакций и снижает административные издержки. Для получения дополнительной информации см. Параметры файла ALTER DATABASE (Transact-SQL) и файловой группы.
Механизм повторного использования пространства в файлах журналов быстр и оказывает минимальное влияние на пропускную способность транзакций.

Усечение журнала освобождает место в файле журнала для повторного использования журналом транзакций. Журнал транзакций должен периодически обрезаться, чтобы предотвратить выделение выделенного пространства. Несколько факторов могут задержать усечение журнала, поэтому важно следить за размером журнала. Некоторые операции могут быть записаны с минимальным количеством журналов, чтобы уменьшить их влияние на размер журнала транзакций.
Усечение журнала удаляет неактивные файлы виртуального журнала (VLF) из журнала логических транзакций базы данных SQL Server, освобождая пространство в логическом журнале, чтобы журнал физических транзакций мог повторно использовать это пространство. Если журнал транзакций никогда не усекается, он в конечном итоге заполнит все дисковое пространство, выделенное для физического файла журнала.
Чтобы избежать нехватки места, если усечение журнала по какой-либо причине не отложено, оно будет усечено автоматически после следующих событий:
В простом режиме восстановления происходит после контрольной точки.
В режиме полного восстановления или в режиме массового восстановления журнала, если с момента последнего резервного копирования была создана контрольная точка, усечение выполняется после резервного копирования журнала (если только это не резервная копия только для журнала).

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

Когда записи журнала активны в течение длительного времени, усечение журнала транзакций задерживается, и журнал транзакций может заполниться.
На самом деле усечение журнала может быть отложено по ряду причин. Запросите столбцы log_reuse_wait и log_reuse_wait_desc в представлении каталога sys.databases, чтобы увидеть, какие факторы, если таковые имеются, препятствуют усечению журнала. В следующей таблице описаны значения этих столбцов.

Устранить неполадки журнала полны

Официальная документация:Разрешение полного журнала транзакций (ошибка SQL Server 9002)

Решения

В SQL 2008 очистка журнала должна выполняться в простом режиме, а после завершения операции очистки она переводится обратно в полный режим (в противном случае база данных не поддерживает резервное копирование на определенный момент времени)

- Просмотр статуса файла журнала
 use dbname
 dbcc shrinkfile('logname')  --like  XXXX_log

Способ 1: сжать логи в режиме интерфейса

Шаг первый: Настройте модель восстановления

Выберите База данных-Свойства-Параметры-Режим восстановления-Простой выбор

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

Шаг 2: Уменьшите файл журнала

Выберите файл базы данных задач

Описание варианта

«База данных»
отображает имя выбранной базы данных.

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

Файловая группа
Выберите файловую группу в списке файловых групп, связанных с выбранным выше «типом файла». Выберите другую группу файлов, и параметры в других полях изменятся соответственно.

Имя файла
Выберите файл из списка доступных файлов для выбранной файловой группы и типа файла.

расположение
отображает полный путь к выбранному в данный момент файлу. Этот путь не может быть отредактирован, но может быть скопирован в буфер обмена.

В настоящее время выделено пространство
Для файлов данных отображается текущее выделенное пространство. Для файлов журнала отображается выделенное в настоящее время пространство, рассчитанное на основе вывода DBCC SQLPERF (LOGSPACE).

Свободное пространство
Для файлов данных отображается текущее свободное пространство, рассчитанное на основе вывода SHOWFILESTATS (fileid). Для файлов журнала отображается текущее свободное пространство, рассчитанное на основе выходных данных DBCC SQLPERF (LOGSPACE).

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

Реорганизовать страницы перед освобождением неиспользуемого пространства
эквивалентно выполнению DBCC SHRINKFILE, который определяет размер целевого файла. Если выбран этот параметр, пользователь должен указать размер файла назначения в поле «Сжать файл в».

«Сжать файл до»
Укажите размер файла назначения для операции сжатия. Это значение размера не должно быть меньше текущего выделенного пространства или больше размера всего экстента, выделенного для файла. Если введенное значение превышает минимальное или максимальное значение, оно вернется к минимальному или максимальному значению после изменения фокуса или нажатия кнопки на панели инструментов.

Очистите файлы, перенеся данные в другие файлы в той же файловой группе
Перенос всех данных из указанного файла. Эта опция позволяет удалять файлы с помощью оператора ALTER DATABASE. Эта опция эквивалентна выполнению DBCC SHRINKFILE с опцией EMPTYFILE.

Шаг 3: Настройте режим восстановления

Выберите База данных-Свойства-Параметры-Режим восстановления-Простой выбор

Способ второй: сжать журнал из командной строки

Этот метод не практичен

USE [master]
	GO 
	ALTER DATABASE DNName SET RECOVERY SIMPLE WITH NO_WAIT
	GO
	ALTER DATABASE DNName SET RECOVERY SIMPLE- простой режим
	GO
	USE DNName
	GO
	DBCC SHRINKFILE(N'DNName_Log',11,TRUNCATEONLY)
	GO
	USE [master]
	GO
	ALTER DATABASE DNName SET RECOVERY FULL WITH NO_WAIT
	GO
	ALTER DATABASE DNName SET RECOVERY FULL- вернуться в полный режим
	GO

Смотрите также

Руководство по архитектуре и управлению журналом транзакций SQL Server
Управление размером файлов журнала транзакций
Журнал транзакций
Сжать файл
Исследование в файлах виртуального журнала SQL Server
Sql2008r2 файл журнала проблем сокращения базы данных не становится меньше