Заранее прошу прощение если что не так опишу. с SQL в первый раз сталкиваюсь.
сделал переход на SQL.
по инструкции http://infostart.ru/public/173494/
настроил резервное копирование.

сегодня в 12 часов выгрузился Журнал транзакций. он весит 19 Гб. это нормально?
размер базы Base1c.mdf - 10 Гб
Размер лога Base1c_log.LDF - 19 Гб

может быть есть такая задание по обрезанию лога?

или что-то другое?

нормально, обрезание лога есть, тема обсосона со всех сторон где только можно 100500 раз.

http://www.sql.ru/forum/128516/top-10-samyh-populyarnyh-voprosov#1017441

(0) Размер лога - нормальный. Если речь о бэкапе лога - то это, скорее всего, начальная заливка базы попала в бэкап лога, т.к. ты не сделал полный бэкап перед этим. Можно его убить. Следующие бэкапы лога должны быть небольшими.

(3)
если начальная заливка = загрузка из dt файла
начальная заливка идет в режиме bulk logged

(0) форум должен угадать релиз сиквела и модель бэкапа ?

(5) Опять тупишь. Рост журнала транзакций не зависит от размера. Если у него лог 19 гиго то уж точно не симпл.
Ну ты маразматик.

Рост журнала транзакций не зависит от размера - читать не зависит от релиза.

(4) Ну не сама заливка, а всякие там пересчеты регистров и т.п. после заливки.

(0) в свойствах базы поставь режим восстановлений Simple. Один хрен ты им пользоваться не умеешь. Ну и быстрее будет.

(8) + Хотя тогда совпадение размера лога и его бэкапа очень странно. Подозреваю, что ТС как-то нетривиально бэкапит лог :)

(8)
начиная c 14 релиза регистры не персчитываются, тк сохраняются в dt.

(11) О как. Буду знать.

(0) 1. Первая резервная копия журнала транзакций может быть заметно больше последующих. Это и в статье упомянуто (каюсь - лишь вскользь)
2. Резервная копия журнала транзакций может быть достаточно большой, если в период от предыдущей выполнялись перестроения индексов или какие-то массовые изменения.

(0) опосля бекапа лога воткни инструкцию t-sql в план обслуживания, которая порежет лог.
делов то

тип того:

USE [databasename]
GO
DBCC SHRINKFILE (N'databasename_log' , 0, TRUNCATEONLY)
--ну там имя файла и базы своё воткнешь и стрелочкой последовательность действий укажешь

(16) а бекап лог?

(16) За такие советы надобно канделябром.

Как обрезать лог файл в SQL базе

(18) а чего не так с советом?

(17)
(18)
shrink  лога без бекапа не сработает.

(21) а он в 15 написал, это я только конец прочитал.

(20) Сервер его будет опять расширять (при этом подтормаживать), плодить VLF, фрагментировать. И так после каждого бэкапа лога? Отлично, да. Ладно б база была терабайтная, а то ж меньше 30 ГБ вместе с пустым, но большим файлом журнала.
Если файл стал большим, то один раз имеет смысл DBCC SHRINKFILE выполнить до какого-то разумного размера (0,25-1 размер базы, в зависимости от условий использования), но не каждый бэкап лога же. Лучше бэкапы лога делать почаще (раз в 10-30 минут самое то).

Благодарю всех! буду разбираться=)