1. 1С не может чего-либо восстановить непосредственно из журнала транзакций. Также как и любая программа, работающая на уровне SQL-запросов, с SQL-сервером. Просто нет таких команд SQL, которые позволяли бы это делать (по крайней мере, после фиксации транзакции). :) Из всего ПО мне известна лишь одна спец.утилита, которая лезет на низком уровне в журнал транзакций, на уровне байтов разбирает его содержимое и что-то подобное может сделать. Но это не 1С... :)

2. "Отключить" журнал транзакций в MS SQL Server можно только вместе с базой данных, либо на худой конец, оставив БД в режиме дальнейшего восстановления, в котором она работать не может (остается недоступной).

3. Файлы журнала транзакций в MS SQL используются для поддержания механизма транзакций (двухступенчатой фиксации любых изменений данных) и механизмов репликации и используются только самим SQL-сервером, и только для этих целей, а более ни для каких. Поскольку любые операции с базой данных выполняются либо в явно объявленной, либо в неявной, но транзакции , то никакая модификация данных вообще не может производиться в принципе без журнала транзакций.

4. Таким образом, восстановление данных прошло из оставшейся в самой базе данных информации. Если только Вы не восстанавливали базу данных из архива.

5. Если нужно урезать размер файла журнала транзакций, для этих целей используется команда DBCC SHRINKFILE. Однако, урезать его можно только при соблюдении ряда условий. В частности, только после его очистки от транзакций (например, командой Backup Log).

P.S. А задача-то как стоит? Освободить место на диске? Избавиться от мешающей информации? Или ускорить реакцию системы?

P.P.S. Если у вас распухает до бесконечности размер журнала транзакций, скоре всего, выставленная в свойствах БД Recovery Model (модель восстановления) не соответствует фактически используемой практике архивирования данных.

Если Recovery Model установлена в Simple, то журнал транзакций будет очищаться регулярно сам. Но архивировать вы сможете не транзакции, а только содержимое базы данных уже в каком-то зафиксированном виде. Поэтому и восстановить сможете данные только на момент архивирования.

Если Recovery Model установлена в Full или в Bulk-Logged, то журнал транзакций сам не очищается. Ожидается, что DBA будет архивировать кроме самой БД еще и журнал транзакций - и он очищается именно после архивирования журнала транзакций (команда Backup Log). Если же DBA не настроил процедуру автоматической архивации лога, и не архивирует его руками, журнал транзакций может вырасти до таких размеров, что никаких дисков не хватит. И на многие порядки превысить размер файла БД.

Лично я предпочитаю использовать Recovery Model = Bulk-Logged. Это позволяет восстанавливать информацию в базе данных по состоянию на любой момент времени, а не только на момент архивирования. Более того, такая модель восстановления позволяет восстанавливать данные на момент непосредственно перед выполненной ошибочно операцией (например, после случайного удаления важной информации), даже если последнее архивирование производилось задолго до выполнения ошибочной операции, и между периодом архивирования и ошибочной операцией уже было введено много ценных данных, которые не хочется потерять. Эта особенность делает такую Recovery Model особо ценной. Нужно только не забывать архивировать журнал транзакций... :)

P.S. Поясню, почему Bulk-Logged предпочитаю Full. Большинство систем (как 1С, так и ИНФИН, которым мы тоже пользуемся) хранит часть информации в BLOB-полях, операции с которыми не во всех режимах попадают в журнал транзакций. Поэтому при восстановлении из архива с использованием бэкапа лога часть информации может не восстановиться при использовании RM=Full. А в BLOB-полях содержатся, например, шаблоны форм.