Одна из конфигураций на базе SQL при входе начала выдавать следующую ошибку:
Ошибка СУБД:
Microsoft SQL Server Native Client 11.0: The transaction log for database 'Base_Name' is full due to 'LOG_BACKUP'.
HRESULT=80040E14, SQLSrvr: SQLSTATE=42000, state=2, Severity=11, native=9002, line=1

Так так, очень интересно. А ты?

(1) Попытался урезать лог транзакций через SQL server, но вышла и там ошибка:

Backup, file manipulation operations (such as ALTER DATABASE ADD FILE) and encryption changes on a database must be serialized. Reissue the statement after the current backup or file manipulation operation is completed. (Microsoft SQL Server, Error: 3023)

(2) Очень интересно. Что думаешь делать?

(1) Тоже самое если делать это с помощью запроса:
Msg 3023, Level 16, State 2, Line 2
Backup, file manipulation operations (such as ALTER DATABASE ADD FILE) and encryption changes on a database must be serialized. Reissue the statement after the current backup or file manipulation operation is completed.
Msg 5069, Level 16, State 1, Line 2
ALTER DATABASE statement failed.
Msg 8985, Level 16, State 1, Line 3
Could not locate file 'acc_main' for database 'Base_Name' in sys.database_files. The file either does not exist, or was dropped.

(3) У Вас есть какие то идеи?

(5) Я уж думал не спросишь
Скуль перегружать пробовал?

(6) Перезагружал SQL server agent, но не помогло

(7) Причем здесь агент, просто скуль перегружал?

У базы стоит модель Full или Simple?

(8) Сейчас попробую. (9) Модль Фулл пытался сделать Симпл, но выдает ошибку которую я написал выше

(8) Кажись заработало! Ввел две команды net stop mssqlserver и net start mssqlserver и база запустилась! Спасибо большое)

Отлично

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

Теперь попробуй всё таки снять бекап лога транзакций и снять/увеличить ограничение по максимальному размеру лога транзакций.

Если тебе не нужен лог транзакций - переведи базы в simple.

Роман, а как часто тебя заказчики бьют за советы как в (6) не разбирающимся разработчикам?

(14) У меня такого не бывает, я базы сразу в Simple перевожу
Можно привести хоть один пример, где в 1С может пригодиться Full?

(14) Про бэкап речь зашла только после (0), а в (0) речь не о бэкапе, а о переполнении  лога

>>Можно привести хоть один пример, где в 1С может пригодиться Full?

ЛОЛ, да везде, где заказчики не готовы терять данные за период от предыдущего полного бэкапа до сбоя.

(17) Ты про ситуацию, когда клиент реально готов восстанавливать все максимально полно и ежечасные инкрементные бекапы по необъяснимой причине ему так же не подходят
А я про реальность
И в моей реальности полный бекап плюс ежечасные инкрементные полностью закрывают потребность в бекапах
В этом случае Full только жрет место и все

(18)
>>ежечасные инкрементные бекапы по необъяснимой причине ему так же не подходят

не по необъяснимой, а по причине что он готов потерять макс. 15 минут - именно такой интервал можно ставить для бэкапа лога, для дифф. бэкапа в конце дня у тебя дифф бэкап просто не будет успевать делаться за это время


>>В этом случае Full только жрет место и все

Ты просто не умеешь настраивать бэкап лога. Твои ежечасные диф. бэкапы точно так же жрут место, по сравнению с бэкапами лога.

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

>>А я про реальность

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

(19) В общем, я не понял, в чем проблема полных бекапов + дифференциальных, в случае ручного восстановления этого более чем достаточно

(21) Печенюшка, с таким уровнем понимания тебя нельзя до баз больше 15 Мб допускать, бгг

(19) > Насчет инкрементного, как ты говоришь, бэкапа (на самом деле он называется дифференциальный) - у него есть серьезный подводный камень - сделанный админом или сторонними средствами полный бэкап делает невалидной всю цепочку твоих бэкапов

COPY ONLY спасает, но кто про него вспоминает )

(22) Ой, Миша, дурачок, я и не признал тебя сразу, сорян :))

(17) >>ЛОЛ, да везде, где заказчики не готовы терять данные за период от предыдущего полного бэкапа до сбоя.

Раз заказчик такой нежный, пусть строит репликацию)))