Ошибка:
Microsoft SQL Server Native Client 10.0: The transaction log for database 'production' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases
HRESULT=80040E14, SQLSrvr: SQLSTATE=42000, state=2, Severity=11, native=9002, line=1

SQL 2008
Сам лог подвергнут транкейту.
Размер лога - 5 Mb
Места на диске полно.
Ограничение по логу - 4 Gb.
Кто что посоветует?

Забухать на пару дней - может само рассосется..

админа пнуть

а ты сделал что просили от тебя?
see the log_reuse_wait_desc column in sys.databases

(3) доступа нет туда
Ко мне за помощью идут только.
Думаешь, там что-то важное будет?
Сейчас гляну.

(3)>The transaction log for database 'production' is full.
этого вполне достаточно, но сейчас в патовой ситуации любые варианты смотрим.

(0) select log_reuse_wait_desc from sys.databases where name = 'production'

что покажет?
-
Размер приращения лога не больше свободного места?
-
Попробуй перезапустить службу SQL Server'а

(3) CHECKPOINT
типа, не было резервной точки после усечения.
И когда она будет в журнале?? Что получается - со вчера все наши транзакции в журнал не писались, а трутся в памяти и никак не могут оттуда попасть на диск?

(6)>Размер приращения лога не больше свободного места?
мест полно на диске. сотни гигов.
>Попробуй перезапустить службу SQL Server'а
пока пользователи в базе

поставь режим симпл

(9) это не зависит от режима. Отсутствие КТ для любого режима может быть.

выполни

use production
go
CHECKPOINT

ограничивать размер Лога зачем вобще?

(11) выгонять пользюков надо? или точка поверх рабочих транзакций создастся?

(12) где сказано, что ограничичать нальзя? лог ограничен вполне лоялными 4 Гб. Мало - увеличим до 15-20. Транкэйт каждый день делается.

(14) зачем ограничения, транкейт??? тогда уж симпл

>лог ограничен вполне лоялными 4 Гб

этого может нехватить - длинная операция без checkpoint и скидывания из журнала в базу

(14) я не говорю нельзя, я спрашиваю - зачем. ИМХО - это бред.
Массовое перепроведение или расчет себестоимости или реструктуризация или много чего ещё - тупо завалит базу. Пока не почистишь - не зарабоатет.

(15) не знаю.
Хотят FULL.
До того и транкейт 2008 SQL не делали.
Не знали, как.

а в чем лояльность? на fat32 влезает?

(19) лояльными к обрезанному логу. Больше за день не нужно было.

(11) так что там с точкой? надо выгонять или не обязательно?

(21) если станет плохо - он тебе сам скажет.

(20) вы меня извините, но местный одмин невменяем

(23) вобще-то автор сказал что он настраивал, раньше вобще ничо не настроено было...

(21) Используй простую модель и не ипи моск
Фулл и настройки надо использовать осознанно

зачем транкейт тоже не понял.

(26) скорее обозвал так шринкфайл... ну я надеюсь)

(24) FULL не я делал ))

сами базы вообще не я создавал и натсраивал первоначально.

(26) ранее это транкейт был. Сейчас - перевод в симпл и шринк базы.
Транкейт - лога, шринк - базы, а не лога.

(27) так что все верно )

(25)>Используй простую модель и не ипи моск
угу.
Мне то ведь - я с боку. Помогаю вот в меру сил.

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

(33)>или фулл или симпл
это обрезка лога в 2008 SQL.

+ способ обрезки, только лишь.

База возвращается в FULL потом.
Сейчас - обрезка при бэкапе журнала.

(21) Выгонять не надо

(37) после CHECKPOINT заработало сохранение
Почему КТ не выполнилась - не понятно.

(38) http://msdn.microsoft.com/ru-ru/library/ms345414(v=sql.105).aspx
http://msdn.microsoft.com/ru-ru/library/ms189573(v=sql.105).aspx
http://msdn.microsoft.com/ru-ru/library/ms188748(v=sql.105).aspx

(39) "Факторы, могущие вызвать задержку усечения журнала"
а могущие не вызвать ))
Определить нельзя в данном случае, из-за чего не создалась КТ.