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


#0 by MKFreeUser
Помогите с проблемой, есть база на 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 выдает сообщения об ошибках, обратитесь к системному администратору.
#1 by ptiz
alter database mydb set recovery simple go DBCC SHRINKFILE ('mydb_log', 0); go alter database mydb set recovery full go отлично работает
#2 by MKFreeUser
Лог не уменьшился после этой процедуры
#3 by MKFreeUser
Не удалось сжать файл журнала 2 , так как все логические файлы журналов, расположенные в конце файла, находятся в использовании. (строк обработано: 1) Выполнение DBCC завершено. Если DBCC выдает сообщения об ошибках, обратитесь к системному администратору.
#4 by ptiz
Странно. 1С с фоновыми заданиями не мешается в этой базе?
#5 by MKFreeUser
Фоновые отключены давно, база создана из рабочей базы. Я вычитал, что проблема может быть в этом log_reuse_wait_desc REPLICATION, но я не знаю как это изменить, да и мне не ясно что это такое, у меня небольшой опыт администрирования на уровне MSSQL
#6 by Ёпрст
спасут тебя.
#7 by MKFreeUser
MS SQL 2008 там нет такой команды
#8 by MKFreeUser
BACKUP LOG MyBase WITH TRUNCATE_ONLY go Сообщение 155, уровень 15, состояние 1, строка 24 TRUNCATE_ONLY не является известным параметром BACKUP.
#9 by timurhv
Сделайте полную резервную копию и шринкуйте.
#10 by Провинциальный 1сник
Тупо в свойствах базы уменьшаете размер ldf и нажимаете Ок. Не надо никаких команд писать. Шринкнется само.
#11 by MKFreeUser
все простые действия я делал: результат минимальный, ну не может лог быть больше в 4 раза самой базы после бэкапа
#12 by Ёпрст
переводить в симпл не надо
#13 by Провинциальный 1сник
Если не делать бэкап журнала транзакций - то смысла в фулл нет вообще никакого.
#14 by MKFreeUser
пробовал тупо уменьшить размер лога - ошибок не выдает, но и результата нет в симпле однозначно должно было порезать базу - но тут почему-то не хочет. У меня еще с десяток баз, и в тех что я проверил - подобной проблемы не наблюдается - спокойно шринкуются
#15 by Ёпрст
И ?
#16 by Ёпрст
еще раз, не надо делать симпл. Сделай бэкап лога и шринк.
#17 by Провинциальный 1сник
То есть. Сделали симпл, нажали Ок. Открыли еще раз - уменьшили файл до 1 мегабайта - нажали Ок. И что?
#18 by Ёпрст
А так. делаешь план обслуживания, в задачу пихаешь бэкап лога и стрелочкой - инструкцию t-sql на шринк лога. Всё
#19 by MKFreeUser
какой план обслуживания - если вручную не шринкуется. Может есть какие команды, чтобы посмотреть возможные причины?
#20 by Ёпрст
ну, если делаешь как в то ясен пень
#21 by Ёпрст
Если лень читать бол, то достаточно создать план обслуживания и посмотреть там скрипт выполнения от бэкапа лога
#22 by MKFreeUser
0. BackUp полный при полном резервировании 1. exec sp_removedbreplication 'MyDB'; 2. Шринк при полном резервирование (возможно лишнее действие) 3. Шринк при simple помогло, спасибо
#23 by Провинциальный 1сник
А, так у вас была репликация включена..
#24 by Seriy_Volk
как то наступали на эти грабли, диагностируется вот так: 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, хотя в базе репликации никогда не было. Т.е. сервер не будет очищать лог, пока не пройдет репликация, нужно принудительно ее очистить: go 4. проверяем еще раз select * from sys.databases where name='my_base'
#25 by Seriy_Volk
забыл упомянуть, что инструкция найдена где то на просторах интернета и под ней было довольно много благодарных отзывов, так что ситуация не такая уж редкая.
#26 by MKFreeUser
а что значит "включена репликация", может кто пояснить? Это не бэкапы по регламенту FULL и ЖТ, а что-то другое?
#27 by Мыш
Бэкап лог в нулл, шринк лог. Повторить два раза. Профит.
#28 by Seriy_Volk
включена репликация, значит сервер думает, что где то есть еще одна база, которую нужно поддерживать синхронизированной с текущей базой. Для этого, кроме всего прочего, используется журнал транзакций.
#29 by rphosts
у мну правда фул мода, поэтому для упыпырища шринк: ALTER DATABASE [upp] SET RECOVERY SIMPLE go DBCC SHRINKFILE ([upp_log], 1); ALTER DATABASE [upp] SET RECOVERY FULL go для простой моды достаточно будет:
#30 by Мыш
Зачем до 1 Мб резать?
#31 by rphosts
мне это приемлимо
#32 by alkorolev
базу с UPP82 переименовали, изверги!
#33 by alkorolev
полный бэкап сделайте. После этого всё отлично шринкуется
#34 by Мыш
См.
#35 by Tateossian
Можно еще детач-аттач сделать (но без лога) - тогда создастся новый лог.
#36 by Seriy_Volk
Редкий случай для любого форума - автор темы задал хорошо сформулированный, хотя и нетривиальный, вопрос. Затем сам нашел верное решение, не забыл его описать в 22, но продолжает получать бесполезные советы...
#37 by Tateossian
Тривиальнейший вопрос, вы не правы.
#38 by Tateossian
У меня коллега книжечка где-то валялась, «SQL сервер для самых маленьких», так там об этом неписано где-то в начале, как обслуживать СУБД с помощью конструкторов. Там еще текст можно сгенерить и картиночки двигать.
#39 by Seriy_Volk
у меня статистики маловато, но ни разу не встречал кого то, кто включал бы на MS SQL в регулярный план обслуживания скрипт, убирающий ошибочную репликацию для БД. А без этого все советы в теме бесполезны.
Тэги:
Ответить:
Комментарии доступны только авторизированным пользователям

В этой группе 1С