Модель восстановления полная

Вот это vv делал,

BACKUP LOG [KA] TO  DISK = N'D:\mssql_backup\KA\Еще одна копия лога.trn' WITH NOFORMAT, NOINIT,  NAME = N'KA-Журнал транзакций  Резервное копирование', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

Размер файла полученной резервной копии 400кб

Размер лога 8Гб. Свободное место в файле 98%. Первая операция сжатия выдала что все успешно сжато, файл остался как был. Вторая и последующие уже ничего не пишут, просто молча отрабатывают и ничего не меняется

Если выполнять скриптом, то пишут что

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

http://1c-esse.buter.ru/faq.php?pg=2

sp_dboption 'ИмяБазы', 'trunc. log on chkpt.', 'ON'
пробовал?

(0) дык шринкани лог, делов то..опосля бекапа он никак не ужмётся.

(3)
Starting with SQL Server 2000, setting the trunc. log on chkpt. option to true sets the recovery model of the database to SIMPLE. Setting the option to false sets the recovery model to FULL

Спасибо, не надо

(4) Он как раз и не шринкается, в этом и проблема

(2)
Спасибо! Помогло CHECKPOINT, лог ужался до 130 мб. Дальше не хочет по тем же отмазкам что там типо в конце используемые логические файлы логов

(0) документацию читать не модно? http://msdn.microsoft.com/ru-ru/library/ms178037.aspx
подожди час и снова сделай бэкап лога + шринкфайл

USE BaseName
GO
BACKUP LOG BaseName WITH TRUNCATE_ONLY
GO
DBCC SHRINKFILE ('BaseName_Log', 1)
GO

(8)
Что изменится через час? В базе никто не работает, открытых транзакций нет, лог бекапится каждые 15 минут, кроме того, я уже написал что помогло CHECKPOINT, и проблема стало быть была именно в этом

>> документацию читать не модно?
А, ну извините, задал вопрос предварительно не прорубив все статьи MSDN по теме, криво переведенные на русский при этом. Я правда так и не понял чего там в приведенной вами ссылке имеет отношение к моему вопросу

(9)
WITH TRUNCATE_ONLY не поддерживается с 2008, да и бекап с усечением, как я писал в исходном посте сделан был

(11) дык у тя ж  2000, разве нет ?

(10) не нравится русский перевод, читай по англицки, кто мешает?
по ссылке написано в каком случае лог не может шринкануться меньше определенного размера, твое "Не удалось сжать файл журнала 2 (КА_log), так как все логические файлы журналов, расположенные в конце файла, находятся в использовании" из (1) разжевано по самое не могу, с картинками.
чекпойнт в полной модели восстановления помочь не мог, ты делал что-то кроме него

(13)
>> чекпойнт в полной модели восстановления помочь не мог, ты делал что-то кроме него

Мог, дружище, мог. Если б не мог, то не помогло бы, учи матан

(10) Как раз по вопросам журналов транзакций, модели восстановления, резервного копирования в MSDN практически идеально и очень аккуратно переведено.

(0) Самое простое средство для однократного (но не для регулярного) уменьшения "нечаянно" выросшего лога транзакций: прочтитать документацию, сделать резервную копию базы, перевести в SIMPLE, шринкнуть файл лога в 0, увеличить файл лога до 0,25-0,5 размера базы, включить FULL, следать резервную копию, настроить резервное копирование регулярное для данных и для журнала транзакций, забыть об этой проблеме.

(14) лол. а как, если не секрет?
и заодно посчитай сколько бэкапов журнала транзакций (если верить (10)) было между (0) и чудесным "исцелением" в (7) и подумай - не было ли это как-то связано

(16)
Дружище, бекапов было... дай подумать... это... ноль? да, где-то в районе того

И как же это связано-то с исцелением?... Чорт, ничего в голову не лезет

(17) "лог бекапится каждые 15 минут"
"бекапов было... дай подумать... это... ноль"
адью

(18) Слив защитан