Even if you are taking regular full backups, the log file will grow and grow until you perform a log backup - this is for your protection, not to needlessly eat away at your disk space. You should be performing these log backups quite frequently, according to your recovery objectives. For example, if you have a business rule that states you can afford to lose no more than 15 minutes of data in the event of a disaster, you should have a job that backs up the log every 15 minutes. Here is a script that will generate timestamped file names based on the current time (but you can also do this with maintenance plans etc., just don't choose any of the shrink options in maintenance plans, they're awful).

DECLARE @path NVARCHAR(255) = N'\backup_sharelog	estdb_' 
  + CONVERT(CHAR(8), GETDATE(), 112) + '_'
  + REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
  + '.trn';

BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;

请注意，\backup_share 应该位于代表不同底层存储设备的不同机器上.将这些备份到同一台机器(或使用相同底层磁盘的不同机器，或同一物理主机上的不同虚拟机)并没有真正帮助你，因为如果机器爆炸，你已经丢失了你的数据库和它的备份.根据您的网络基础设施，在本地备份然后将它们转移到幕后的不同位置可能更有意义；无论哪种情况，您都希望尽快将它们从主数据库计算机上删除.

USE [master];
GO
ALTER DATABASE Test1 
  MODIFY FILE
  (NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO

ALTER DATABASE testdb SET RECOVERY SIMPLE;

USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
DBCC SHRINKFILE(yourdb_log, 200); -- unit is set in MBs
GO