Поставил ограничение для лог-файла в 8 Гиг, а он вырастает до этих размеров за 2 дня упирается и приходиться чистить в ноль. Как сделать что бы он "самоочищался".

simple mode
или backup базы ежедневный

>backup базы ежедневный

не базы а лога + шринк

use [base_1c]
BACKUP LOG base_1c WITH TRUNCATE_ONLY
GO
DUMP TRANSACTION base_1c WITH no_log
GO
CHECKPOINT
GO
DBCC SHRINKFILE(base_1c_log,2)
GO
DBCC SQLPERF (logspace)

Где "base_1c" - имя базы на SQL сервере. Скрипт ставим в шедулер и запускаем каждую ночь.

(3) Note:  
The BACKUP LOG WITH NO_LOG and WITH TRUNCATE_ONLY options have been discontinued

WITH TRUNCATE_ONLY нету с 2008

мне не понять а зачем тогда, есть возможность определить макс. размер лога?

Тогда надо поменять модель восстановления с Full на Simple и обратно.

(7) для фиксации максимального размера.

(7) если не ограничить он звонко шлепнется, когда место кончится. плюс операция приращения файла лога тяжелая, выкусить сразу дает прирост производительности

use [EB_Test]

DECLARE @pathName NVARCHAR(max) ;
DECLARE @dbName NVARCHAR(128) ;
DECLARE @bkName NVARCHAR(128) ;

SET @dbName = 'EB_Test'
SET @pathName = 'G:\1C\EB_Test\daily.bak'
SET @bkName = @dbName + N'_full_backup'

BACKUP DATABASE @dbName TO DISK = @dbName WITH  FORMAT, INIT,  NAME = @bkName, COMPRESSION
GO
DUMP TRANSACTION @dbName WITH no_log
GO
CHECKPOINT
GO
DBCC SHRINKFILE(EB_Test_log,2)
GO
DBCC SQLPERF (logspace)

Сообщение 156, уровень 15, состояние 1, строка 1
Неправильный синтаксис около ключевого слова "TRANSACTION".
Сообщение 8985, уровень 16, состояние 1, строка 1
Не удалось найти файл "EB_Test_log" для базы данных "EB_Test" в sys.database_files. Файл не существует или был удален.

Как правильно определить имя лог файла?

тебе написали где посмотреть можно

С именем лог файла разобрался, теперь осталось разобраться с ошибкой: - "Неправильный синтаксис около ключевого слова "TRANSACTION"."

удали его, разницы никакой

строку всю

(13) его выпилили в 2008 серваке

все хорошо, но вот почему то не создается бак-файл - G:\1C\EB_Test\daily.bak

Через запрос отрабатывает, через План обслуживание пишет (Этот шаг определен неверно и не может быть выполнен (необходимо указать допустимую команду). Шаг завершился с ошибкой.).
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE EB
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (EB_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE EB
SET RECOVERY FULL;
GO

(18) бедная база

ты ее так каждый день насилуешь?

1-2 раза в неделю.

ни (3), ни (11) не работает.

После Реорганизации индексов и Обновлении статистики, лог разбухает до 20-30 Гиг.

(22) Вот и оставь его в таком состоянии и не насилуй сервер совершенно бесполезными действиями.

(23) а каким объемом ограничить лог файл, а резать я так понимаю в любом случае надо будет лог.

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

(24) Ты неправильно понимаешь. НЕ НАДО резать лог, НЕ НАДО считать себя умнее разработчиков сервера. Если лог растет, то это нужно серверу. Но не по прихоти своей его увеличивает. И увеличивать выше того, что ему нужно он не будет. Дай размеру лога устаканиться, не забывай бэкапы лога или переведи базу в режим симпл и забудь про него.

Вывод: Бэкапим лог каждый день после бэкапа базы и смотрим на размер базы.

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

(28) ЗАЧЕМ? Что вы все так зациклились на размере файла? Что даст его уменьшение? На каком основании вы так решили?

(28) сначала бэкап лога, потом Шринк. он не зашринкуется без бэкапа. переведи в симпл и не парь мозг, всё равно не используете возможности журнала транзакций

(27) сохранится часть лога, нужная для восстановления после последнего бэкапа. чему равна нужная часть лога сразу после бэкапа?

(30) делал все, поэтому и пишу сюда
(29) размер лога в 350 гигов грозит заполнить под завязку отдельный SSD на 500 гигов

(32) Если скуль периодически увеличивает размер лога до 320 гиг, то значит периодически есть операции, которые вызывают такой рост лога. Значит надо разбираться с ними.
А размер лога уменьшать имеет смысл одноразово после каких-либо существенных действий.
Имхо

(33) это потихоньку, в течение недели

а наоборот нельзя? перед такими операциями переводить в симпл, а потом в фул?

(35) хм... интересно, а восстановление на любую минуту все еще будет работать?

(36) наструя оно нужно при реорганизации? 1с в этот момент все равно no responded. То что кто-то будет восстанавливать посредине процесса тоже не уверен.

просто надо снизить число журналируемых операций раз все так пухнет, второй момент - получить представление в чем причина