Помогите усечь и сжать log MSSQL, перевод в Simple и шринк не дает результата

alter database mydb set recovery simple
go
DBCC SHRINKFILE ('mydb_log', 0);
go
alter database mydb set recovery full
go

отлично работает

(3) Странно. 1С с фоновыми заданиями не мешается в этой базе?

(0)

BACKUP LOG
+DBCC SHRINKFILE

спасут тебя.

(7) Сделайте полную резервную копию и шринкуйте.

Тупо в свойствах базы уменьшаете размер ldf и нажимаете Ок. Не надо никаких команд писать. Шринкнется само.

(11) переводить в симпл не надо

(12) Если не делать бэкап журнала транзакций - то смысла в фулл нет вообще никакого.

(13) И ?

(14) еще раз, не надо делать симпл.
Сделай бэкап лога и шринк.

(14) То есть. Сделали симпл, нажали Ок. Открыли еще раз - уменьшили файл до 1 мегабайта - нажали Ок. И что?

А так. делаешь план обслуживания, в задачу пихаешь бэкап лога и стрелочкой - инструкцию t-sql на шринк лога. Всё

(19) ну, если делаешь как в (8) то ясен пень

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

(22) А, так у вас была репликация включена..

(22) как то наступали на эти грабли, диагностируется вот так:

1. определяем степень использования лог файла
dbcc sqlperf(logspace)

2. видим, что лог используется почти целиком, выясняем причину, глядя на колонки log_reuse_wait и log_reuse_wait_desc запроса
select * from sys.databases where name='my_base'
3. в log_reuse_wait_desc стоит REPLICATION, хотя в базе репликации никогда не было. Т.е. сервер не будет очищать лог, пока не пройдет репликация, нужно принудительно ее очистить:

use master
exec sp_removedbreplication
@dbname = 'my_base'

go
4. проверяем еще раз select * from sys.databases where name='my_base'

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

(0) Бэкап лог в нулл, шринк лог. Повторить два раза. Профит.

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

(0)у мну правда фул мода, поэтому для упыпырища шринк:

USE [upp]
ALTER DATABASE [upp] SET RECOVERY SIMPLE

go 

DBCC SHRINKFILE ([upp_log], 1);
ALTER DATABASE [upp] SET RECOVERY FULL
go

для простой моды достаточно будет:

USE [upp] 
DBCC SHRINKFILE ([upp_log], 1);

(29) Зачем до 1 Мб резать?

(30) мне это приемлимо

(29) базу с UPP82 переименовали, изверги!

(0) полный бэкап сделайте. После этого всё отлично шринкуется

(33) См. (27)

Можно еще детач-аттач сделать (но без лога) - тогда создастся новый лог.

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

(36) Тривиальнейший вопрос, вы не правы.

(36) У меня коллега книжечка где-то валялась, «SQL сервер для самых маленьких», так там об этом неписано где-то в начале, как обслуживать СУБД с помощью конструкторов. Там еще текст можно сгенерить и картиночки двигать.

(38) у меня статистики маловато, но ни разу не встречал кого то, кто включал бы на MS SQL в регулярный план обслуживания скрипт, убирающий ошибочную репликацию для БД. А без этого все советы в теме бесполезны.