Помогите с проблемой, есть база на MSSQL, mdf - 12ГБ, LDF 55ГБ. Перевел базу в "простую" модель восстановления,сделал шринк, размер лога уменьшился на 1МБ.Повторил - лог не изменился.

База была создана, как восстановление из другой базы. Начальный размер файла mdf -12ГБ, начальный размер LOG -55ГБ.

log_reuse_wait
6
log_reuse_wait_desc
REPLICATION

DBCC OPENTRAN
Сведения о транзакциях для базы данных

Сведения о реплицированных транзакциях:
Самый старый номер LSN : (0:0:0)
Самый старый нераспределенный номер LSN : (63546:40212:1)
Выполнение DBCC завершено. Если DBCC выдает сообщения об ошибках, обратитесь к системному администратору.

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

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

Лог не уменьшился после этой процедуры

Не удалось сжать файл журнала 2 , так как все логические файлы журналов, расположенные в конце файла, находятся в использовании.

(строк обработано: 1)
Выполнение DBCC завершено. Если DBCC выдает сообщения об ошибках, обратитесь к системному администратору.

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

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

(0)
BACKUP LOG
+DBCC SHRINKFILE
спасут тебя.

MS SQL 2008 там нет такой команды

BACKUP LOG MyBase WITH TRUNCATE_ONLY
go

Сообщение 155, уровень 15, состояние 1, строка 24
TRUNCATE_ONLY не является известным параметром BACKUP.

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

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

все простые действия я делал:
1) создать бэкап
2) перевести в simple
3) сделать шринк
4) повторить шринк

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

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

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

(10) пробовал тупо уменьшить размер лога - ошибок не выдает, но и результата нет

(12) в симпле однозначно должно было порезать базу - но тут почему-то не хочет. У меня еще с десяток баз, и в тех что я проверил - подобной проблемы не наблюдается - спокойно шринкуются

(13) И ?

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

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

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

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

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

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

0. BackUp полный при полном резервировании
1. exec sp_removedbreplication 'MyDB';
2. Шринк при полном резервирование (возможно лишнее действие)
3. Шринк при simple
помогло, спасибо

(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) забыл упомянуть, что инструкция найдена где то на просторах интернета и под ней было довольно много благодарных отзывов, так что ситуация не такая уж редкая.

а что значит "включена репликация", может кто пояснить?
Это не бэкапы по регламенту FULL и ЖТ, а что-то другое?

(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 в регулярный план обслуживания скрипт, убирающий ошибочную репликацию для БД. А без этого все советы в теме бесполезны.